Mental Models

I have known a few but while reading through a long list of mental models the post’s author finds repeatedly useful, I came to know that I use following models very frequently. The use is sometimes conscious, at other times I fall prey to these. But since these concepts have names, I can very easily spot when I am in proximity of any such model. Giving wikipedia links only for those which, I think, are possibly are new to you.

A bunch of cognitive biases

Power Law

Normal Distribution

Thought experiment

Critical mass

Activation energy

Observer effect

Straw Man

Trade offs

Prisoner’s dilemma

Peter principle

All models mentioned under category developing


Paradox of choice

Imposter Syndrome

Dunning-Kruger Effect

Murphy’s law

Hygiene factor

Broken Window






Client-side caching: the client stores the cached result and refresh when it wants. Reduced network calls. Cache invalidation is difficult. For example, if your client side cache never expires.

Proxy caching: proxy placed between client and server which caches the responses. Reverse proxies like Squid or Varnish cache HTTP traffic. Comparatively simpler.

Server-side caching: server uses something like in-memory cache, Redis or Memcache. Clients has no idea and don’t worry about data freshness. Somewhat easier cache invalidation (with things like TTL-Time to live and TTI – time to idle) although as Jeff Atwood says there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors

Which data structure would you use for creating your own cache product? How would the API look like? How would you store dates in cache if the date objects are created in different timezones?


A review of GoF Deign Patterns Book

Nowadays, in the world of functional programming, object oriented design patterns are probably not fashionable. But here is a short review of Design Patterns book written by the Gang Of Four.

I started reading this book, left it because I felt bored, tried some other design pattern books and then returned to the GoF book. And it was an eye opener seeing what depth and width this book covered compared to other design pattern books. I understood why everyone in the industry so praised this book and why everyone said understanding and using patterns was difficult. It was like reading about OOP from Grady Booch’s book after reading from some learn OOP in 21 hours book.

Nowadays, when I need a quick reference about a pattern, I go to the patterns wikipedia entry and if I need to understand it better and in depth, I go to this book. Every paragraph talks about some core concept (like what is an object’s type, really). And page after page there are some core concepts being discussed, so the book demands attention, but it is more than worth the effort.

I have read criticism from Lisp people like Paul Graham about the necessity of patterns. I have tried my hand at lisp. So I understand the criticism to a certain extent. But I think that criticism by functional programmers is mainly directed at OOP. When you are using OOP, the patterns are great help. And this book explains patterns so fundamentally. The book with examples of Window tool-kits, etc. certainly appears to be speaking from the past. But the book is so well written that I could not think of single page where I did not find some fundamental idea. For example, in the quoted section below the authors are talking about object’s interface. It is a perfect, complete and yet very concise discussion. Give it a try and see if you can remove a sentence or two from the discussion.

Every operation declared by an object specifies the operation’s name, the objects it takes as parameters, and the operation’s return value.This is known as the operation’s signature.The set of all signatures defined by an object’s operations is called the interface to the object. An object’s interface characterizes the complete set of requests that can be sent to the object. Any request that matches a signature in the object’s interface may be sent to the object.

A type is a name used to denote a particular interface. We speak of an object as having the type “Window” if it accepts all requests for the operations defined in the interface named “Window.”

An object may have many types, and widely different objects can share a type.Part of an object’s interface may be characterized by one type, and other parts by other types.Two objects of the same type need only share parts of their interfaces.

Interfaces can contain other interfaces as subsets. We say that a type is a subtype of another if its interface contains the interface of its supertype. Often we speak of a subtype inheriting the interface of its supertype.

Interfaces are fundamental in object-oriented systems.

Objects are known only through their interfaces.There is no way to know any thing about an object or to ask it to do anything without going through its interface. An object’s interface says nothing about its implementation-different objects are free to implement requests differently.


Exploring Bash And Terminal

Let me mention that probably because of Mac I have started appreciating unix. Unix was sort of arcane land for me. I used it only when required on projects. And even now I don’t use it much. But I liked MacOS.

And posts like Mastering Bash And Terminal help. I loved that post. Possibly, I would have liked to read comments. Of course, HN comes to help with some additional useful tips.

The original post mentions following sequence.

cd ~/go/
cd ~/tmp/
cd - # <- this puts you back to ~/go/
cd - # <- this puts you back to ~/tmp/

Isn’t that good?

I did not know that following command will take you to your home directory.

cd --


Notes: Design Patterns

Gang Of Four Book



Abstract Factory- Families of Objects (Factory of factories)

 Abstract Factory Pattern


Factory Method Pattern: Delegate Object Creation to specific base classes

 Factory Method Pattern



Builder Pattern:  Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.

Builder Pattern

Prototype: Has Clone method

Prototype Pattern



Chain Of Responsibility: Client has no direct reference to the object that ultimately fulfills it. For example Print Button.

Chain Of Responsibility


Adapter Pattern:

Adaptor Pattern


Command Pattern:

 Command Pattern




Bridge Pattern

Mediator – Object Behavioral


Mediator Pattern



Proxy Pattern




Decorator Pattern


 Strategy: Different strategies for different Implementations

 Strategy Pattern


State: State Of an Object

 State Pattern


Observer: Subscribe, Observe state change, unsubscribe

Observer Pattern


Pattern Classification

Pattern Classification


Notes: Spring AOP: 2: Proxying Mechanisms

Ref: Spring documentation
If the target object to be proxied implements at least one interface then a JDK dynamic proxy will be used. All of the interfaces implemented by the target type will be proxied. If the target object does not implement any interfaces then a CGLIB proxy will be created.

If you want to force the use of CGLIB proxying (for example, to proxy every method defined for the target object, not just those implemented by its interfaces) you can do so. However, there are some issues to consider:

○ final methods cannot be advised, as they cannot be overriden.
○ You will need the CGLIB 2 binaries on your classpath, whereas dynamic proxies are available with the JDK.
○ The constructor of your proxied object will be called twice. This is a natural consequence of the CGLIB proxy model whereby a subclass is generated for each proxied object. For each proxied instance, two objects are created: the actual proxied object and an instance of the subclass that implements the advice. This behavior is not exhibited when using JDK proxies. Usually, calling the constructor of the proxied type twice, is not an issue, as there are usually only assignments taking place and no real logic is implemented in the constructor.

To force the use of CGLIB proxies set the value of the proxy-target-class attribute of the element to true:

	<aop:config proxy-target-class="true">
		    <!-- other beans defined here... -->

To force CGLIB proxying when using the @AspectJ autoproxy support, set the ‘proxy-target-class’ attribute of the element to true:

<aop:aspectj-autoproxy proxy-target-class="true"/>