Uncategorized

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

MVP

Paradox of choice

Imposter Syndrome

Dunning-Kruger Effect

Murphy’s law

Hygiene factor

Broken Window

 

 

 

Uncategorized

Caching

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?

Uncategorized

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.

Uncategorized

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 --

Uncategorized

Is TDD Dead?

Is TDD dead? I don’t think so.

Is TDD a replacement for good design? No, in that a bad or an inexperienced designer can come up with very bad system even though he follows TDD.

What did DHH achieve by writing that (Is TDD Dead) piece? A discussion. Even good developers get stuck up with methodology and forget that those (TDD, craftsmanship, agile, RoR, Spring framework as a war on EJB’s complexity) are just methodologies to better achieve something. Well, the processes are equally important as results. But they get so smitten by the ideas that they become sort of closed minded. You know the phase everyone goes through some time or other. An idea possesses your mind and you take pleasure in it. But trouble starts when leaders from the industry do that and they start shutting out or suppressing non conformity. To quote from Bertrand Russel, “All movements go too far.”

This is when some other leaders have to come forward to open up a forum for discussion. 

Thankfully, there are some leaders like Martin Fowler(he takes balanced views), DHH , Dan North (Programming Is Not A Craft) to help us.

Uncategorized

JPA2 @ManyToMany – A simple Standalone application

The many to many relationship is between Authors and Books. There could be many authos for a given book. And an author can write many books.
The book class looks something like this:

@Entity

@Table(name = "BOOKS")
public class Book {

@Id

@GeneratedValue(strategy = GenerationType.IDENTITY)

@Column(name = "BOOK_ID")

private int id;

@Column(name = "BOOK_NAME")

private String name;

@ManyToMany(cascade = CascadeType.PERSIST)

@JoinTable(name = "BOOKS_AND_AUTHORS",

joinColumns = @JoinColumn(name = "BOOK_ID"),

inverseJoinColumns = @JoinColumn(name = "AUTHOR_ID"))

public List<Author> bookAuthors;