Buy @ Amazon

Search This Blog

September 29, 2017

Book Review - The Subtle Art of Not Giving A F*UK

Eastern Philosophy In Western Package

The author subtly evangelises a very eastern philosophy or spiritual values, by presenting it all in the very western way and that too in a very casual and conversational style. This presentation style is new and refreshing.

The author spews a lot of "f*cks" in the first chapter giving the reader the highs required for him to keep the page turning. Post the first chapter the author continues his conversational style of presenting his gripping views making the reader think about it all by reflecting on his/her past experience.

The need for simple but hard to practice values are reminded time and again throughout the book. And you ask what is this philosophy or values? Go grab your copy now and get enlightened!

September 28, 2017

Talk - Myth of Genius Programmer

This talk revolves around the myth that goes around in the corporate world of software development of force-identifying Heroic Geeks at varied levels starting from team to programmes to the entire company. Okay, okay, the startup world of software development is as well plagued by this myth.

In this talk Brian Fitzpatrick and Ben Collins-Sussman, sets the context very mildly and jumps into a set of guiding principles that an individual in a team has to abide by in building successful GEEK TEAM. That brings me to also point out that they together have also authored a wonderful book titled, Team Geek. Get your copy, for it's worth your time.

Guiding Principles to becoming that Golden Geek Team
  • Lose Your Ego: Lose your personal ego. Having team ego is perhaps okay. Don't try to be a genius in the team.
  • Criticism Is Not Evil: Feedback often is more about how you look like a nice person in conveying your thoughts to someone - crap! Code is not about a person; don't make it personal.
  • Embrace Failure: Failing repeatedly for the same dumb reason is embarrassing and definitely bad. Collaborate early and often.
  • Iterate Quickly: Its about - "Fail fast. Learn fast".
  • Practice Is The Key: Veritable indeed is the statement, "Practice maketh a man perfect". Pay attention to your tools and techniques as well.
  • Be Influenced: Be open to being influenced.
If you know me, I've always cherished and evangelised these. There are occasions and places, I've been crucified for these. Know your environment. If it isn't congenial, be patient and hunt for one that demonstrates these in their culture. Good luck!

Recommending Reading

September 17, 2017

Rob Pike's 5 Rules of Programming

Rule 1: You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

Rule 2: Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3: Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4: Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5: Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

August 27, 2017

Android Activity's onDestroy() Ain't Your Reliable Friend

Look at the Android Activity life-cycle events in the picture beside.

The lifecycle isn't something new. You're familiar with it right? You're also that good Android developer that writes clean code, wherein you consciously override onDestroy() method to include resources clean-up code and save some state, right?

Per Android doc, it is okay and usually the practice to write cleanup code in this method but not anything beyond that.

So if you are to write code to persist state in this method, or anything else beyond resource clean-up (like threads associated with an activity), you're better off to push it up the life-cycle, either in onStop() or onPause() method.

That is how I settled in the first iteration of new learning but wasn't happy. Why? To quote Android Doc:

August 26, 2017

Android - Don't Keep Activities - Developer Options

"Don't Keep Activities" - are you aware of this must turn-on developer setting in your Android device?

Not sure about you. The first time I saw this in the developer setting, I laughed out wondering why on earth a developer would want to do this, assuming that this would hide the app performance issues.

I was so damn wrong. Contrary to my assumption, turning on this developer setting actually helps you identify performance issues. It helps you identify memory leaks of an activity.

Where do I find this? See picture attached.

How it works? When the developer option - Don't Keep Activities - is checked-on, in the device, all activities that are stopped will be destroyed almost immediately. It simulates the Android Operating System behaviour when your app is in the background and the system is short on memory; because of which it will destroy your background activities.

How is it useful? It is intended to help developers debug their apps for testing saved instance states and detecting memory leaks.

When to use it? Turn it on - always. If you find any unexpected behaviour of your app like freezes and force closures, it is a sign of bad code that requires fix.

1. Knowledge boost for junior Android developers — Part I
2. Don't keep activities - What is it for?