Angular Directive Isolated Scope binding cheatsheet

1. "@"   (  Text binding / one-way binding )
2. "="   ( Direct model binding / two-way binding )
3. "&"   ( Behaviour binding / Method binding  )
4. "=?"  ( Optional model binding, outer scope does not have to have the corresponding scope variable )
5. "@", then add observe/watch in the directive  ( Text / one-way binding, but will update inner scope whenever the value changes, as opposed to passing it into directive like a parameter once )

http://www.undefinednull.com/2014/02/11/mastering-the-scope-of-a-directive-in-angularjs/

How to hide "You May Know" section in Google+

Unlike many others, I do like G+, I use hangouts a lot, both for work and with friends. Of course, it is not used for the same purpose as Facebook, and I have no need to connect and share stuff with friends here.

But this annoying "You May Know" section would keep suggesting personal contacts to me, heck, I'm not going to go through my extended contact list (which google has, from my phone contacts) and add everyone to my G+ circles. That is madness, and there is no setting to make it go away.

Anyways, I finally had enough today, and found a lot of people were recommending Adblock Plus, which seems to be the easiest way to get rid of this unwanted feature. It's quite simple, once Adblock Plus is installed, go to its options tab -> Add your own filters, and add following filter:

plus.google.com##div[guidedhelpid="friendsuggestions"]

Then you are good! The damned "You may know" box is gone from google plus... for now.

OOP vs Functional Programming

I have been in several discussions with friends and colleagues about the limitation of OOP and virtues of functional programming. It seems as we push harder for code testability and lower bug rates, it's inevitable that everyone will eventually find the ideas of side impact-less, perfectly enclosed functional programming appealing.

Yet you rarely see business/web applications written in functional languages, and it's not because developers are all lazy.

See, the ultimate goal of almost all software is to solve a problem, it's never about making the most architecturally elegant solution and the most beautiful code in history. And when you focus on how to solve the problem, without worrying about the language, framework, or the programming paradigm you are gonna use, the solution you discover will make most of those technical decisions for you.

When you decide up front that you are gonna use a certain set of tools to a problem you don't have solution yet, you are essentially handicapping yourself, and in many cases will end up with wrapping functional logic with an OOP layer or vice versa.

In short, when you are solving a Sudoku, focus on the god damn Sudoku, worry about unit tests later.