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.

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

August 25, 2017

Notes On Android Notification

This post is my notes drawn from Official Android Docs and Android O: How to Use Notification Channels.

A notification is a message you display to the user outside of your apps UI.

When you tell the system to issue a notification, it first appears as an icon in the notification area like below:

To see the details of the notification, the user opens the notification drawer like below:

Both the notification area and the notification drawer are system-controlled areas that the user can view at any time.

August 21, 2017

Book Review - The Checklist Manifesto



It's a well written book shedding light on the importance of Checklists at work even if it is very critical with regards to time, cost, size of team/project etc. The author shares stories and anecdotes on how right kind of checklists can avert serious damages/mistakes.

I particularly like the way the author catches the attention of the reader in the beginning of the book. As the book gets to the later chapters, it gets dense in the domain that may or may not interest the reader.

I would recommend you get your copy from Amazon for cheaper price. Have fun reading it..

When do you use map vs flatMap in RxJava?

 Learning RxJava is an overwhelming exercise because it is a paradigm shift in the way you solve your coding problems. During this learning process, of the many doubts you'll have, one such would be, "When do you use map vs flatMap in RxJava?".

ProTip : Get used to understanding the Marble Diagram for understanding the basic concepts of Reactive Extensions.


Here is a simple thumb-rule that I use help me decide as when to use flatMap() over map() in Rx's Observable.

Once you come to a decision that you're going to employ a map transformation, you'd write your transformation code to return some Object right? If what you're returning as end result of your transformation is:
  • a non-observable object then you'd use just map(). And map() wraps that object in an Observable and emits it.
  • an Observable object, then you'd use flatMap(). And flatMap() unwraps the Observable, picks the returned object, wraps it with its own Observable and emits it.

Say for example we've a method titleCase(String inputParam) that returns Titled Cased String object of the input param. The return type of this method can be String or Observable<String>.
  • If the return type of titleCase(..) were to be mere String, then you'd use map(s -> titleCase(s))
  • If the return type of titleCase(..) were to be Observable<String>, then you'd use flatMap(s -> titleCase(s))

Hope that clarifies. And if this post helped you pick the concept, I'd appreciate you share the post and upvote this answer in StackOverflow.

August 20, 2017

Book Review - Scalability Rules

 Scalability Rules

A book for Scalability enthusiasts

A good book that should serve as ready reference or guidance for anyone interested in the topic of availability and scaleability. Even though, the guidance/rules that this book mentions, seem  simple and seemingly intuitive, in the real-world situations you'll find violating these giving whatever excuse it be. Reading books like this re-affirms our own intuition and awakens you of risks the next time you come across situations that warrants you to apply these rules where appropriate.

The later chapters could have been better explained with examples. For instance, in the chapter on "Avoid or distribute scale", the author could have explained situations where these rules can be applied and where it does not. In the absence situational examples or use-cases, the reader might likely remain confused or worse with false sense of knowledge. The same applies in the chapter on async communication with Message Buseses, where the author talks about cost of data. Some real-world examples/use-cases would really make this book a rich resource for the reader. 

All said, this book deserves a place in the book-shelf of a developer, manager, architect or a CTO.

August 5, 2017

Book Review - Reactive Android programming


I read this book from SafariOnline. The book is a fantastic read, ridden with examples. The reader typically learns by example. It's a no fluff, just stuff to the point that saves you a lot of time. The book covers employing contemporary 3rd-party libraries where required depending on the use-cases, all blending well with the respective topic/situation.

I'd say this book is from one pragmatic programmer to a busy, impatient and hungry programmer wanting to get his hands dirty.

July 11, 2017

Android Development ProTips To Prevent Memory Leaks

Memory Leaks are not apparent during development
This post is for those impatient Android developers who are seeking a checklist of tips to remember during development, in order to avoid the nasty Memory Leaks in the app thus leading to poor app performance. Poor app performance results in bad user experience that leads to poor ratings in the Play Store.

Let's get the basics right. As much as we'd like to think of Java's Garbage Collector as our reliable agent to cleanse heap of stale objects, it's not hundred percent fool-proof, in that some of the overlooked coding gotchas can trip its reliability. For instance, a WeakReferenced object gets garbage collected quickly over its Strongly Referenced object. But that said, using WeakReferenced object comes in the way of elegant coding. So, typically you look for for areas where you can introduce WeakReference.

ProTip #1: Where possible, use the context-application instead of a context-activity. Look for opportunities where the Application-context is sufficient, instead of the Activity-context.

ProTip #2: Have ImageViews in Activity/Fragment? Use WeakReference to hold the ImageView, so that when the Activity/Fragment is destroyed, the ImageView is readily Garbage Collected.

ProTip #3: Replace non-static anonymous inner-classes (whose life-cycle is not in your control) with static inner-classes. In Java, the non-static inner-classes, hold an implicit reference to its containing class. So imagine you use a non-static inner class inside of your activity. Even after the activity is past the onDestroy life-cycle, it wouldn't be garbage collected, because the non-static inner class holds an implicit reference to it.

ProTip #4: Using Handler? Then don't forget to call removeCallbacksAndMessages(null) or removeCallbacks(mRunnable) in the onDestroy() lifecycle method of the class containing it.

ProTip #5: Using any Listeners? Remember to unregister those listeners.

ProTip #6: Using Eventbus? If you cared to use register(this) then also do care to use unregister(this) in the appropriate lifecycle method definition.

ProTip #7: Employed MVP design-pattern for your code-structure? Passing View implementation as constructor argument to your Presenter implementation? Then ensure to wrap your View in WeakReference.

ProTip #8: Using Threads? Then double-check to see if you have control over its death and are in-fact stopping it at some point in time. Threads in Java are GC roots. Therefore, the Dalvik Virtual Machine (or the DVM) keeps hard references to all active threads in the runtime system, and as a result, threads that are left running will never be eligible for garbage collection.

For detailed and informative reading do care to refer the following posts/articles/books


July 9, 2017

Notes from TED Talk - Why do ambitious women have flat heads?


Watch it in TED

Speaker Profile
In 1962, Dame Stephanie "Steve" Shirley founded Freelance Programmers, a software firm with innovative work practices -- and (mainly) women employees. 
She is a successful million-dollar entrepreneur, Philanthropist and a business-woman in technology. 
She is author of the book (memoir) titled, "Let it Go: The Entrepreneur Turned Ardent Philanthropist"


Secrets to success
  • Surround yourself with first-class people and people that you like. 
  • And choose your partner very very carefully.

Startup Entrepreneurship
It's one thing to have an idea for an enterprise. Making it happen is a very difficult thing. It demands:
  • extra-ordinary energy, self-belief, and determination 
  • the courage to risk family and home 
  • a 24/7 commitment that borders on the obsessive.

Work : "So it's just as well, I'm a workaholic. I believe in the beauty of work when we do it properly and in humility. Work is not just something I do when I'd rather be doing something else."

Life Lesson : We live our life forward. So what has all that taught me? I learned that tomorrow is never going to be like today, and certainly nothing like yesterday. And that made me able to cope with change, indeed eventually to welcome change, though I'm told I'm still very difficult. (Laughter)

July 5, 2017

Colorful Android Logs for Better Productivity

This post assumes you're using Android Studio, if not you better do ;)

It's very common to keep an eye on the logs in Android Studio, every time we deploy the app-under-development into a device/emulator. And it hurts our eyes and our peace for the increased attention we tend to keep on the rolling logs in the Android Studio hunting for the required pieces of information.

Is there a better way to be a little productive so that you can quickly focus on required logs? There is. By simply color styling your logs based on the log's severity level.

This way, you don't miss on that error log or important debug log amongst the continuously rolling logs since your app is deployed.

The good news is, it's a simple configuration change that you'll have to make in your Android Studio Editor like below and you're done.

Android Studio Preferences -> Search for 'logcat' in the search bar



Define your own color coding for different log severity levels or alternatively feel free to use the one that I ended up copying from.

Assert: 9C27B0
Debug: 2196F3
Error: F44336
Info: 4CAF50
Warning: FFC107

Confession: I've shamelessly copied this technique from one of the StackOverflow answers.

Book Recommendation: If you're a beginner Android developer, don't miss out in grabbing a copy of Android Programming: The Big Nerd Ranch Guide. The authors have done justice in teaching stuff with care wearing the hat of a beginner Android developer. It's worth your time. Happy learning!

June 12, 2017

Book Review - Agile Android by Godfrey Nolan


Agile Android by Godfrey Nolan

This blog post is a candid review of the book titled, "Agile Android", authored by Godfrey Nolan

This book is very concise and is a very high level overview of writing tests for native Android development project. It gives you a taste of the tools that you can use to write tests and aid writing more tests.

Who does this help? If you're a novice developer wondering what tools to use and how to get started using those, then this book is for you. You could perhaps be that curious Manager who is wanting to wrap his/her head on the tools that your Android development teams use.

March 15, 2017

Book Review - The One Minute Negotiator


Book Cover - The One Minute Negotiator

This is a good book that gives real, practical and genuine advice on negotiating - starting from the very definition of what a negotiation is.

While the content it less, the author made it enjoyable to read, pause and ponder about his advices as the book progresses. 

Read this book, and you might likely want to attend a workshop on this topic by this author.

Get your copy from Amazon now.