September 11, 2014


I see these over and over again in debates on Hacker News. Time to write’m down!

ACID Principle

4 letters describing transactions in a database.

Atomicity (like an atom, each transaction can’t be divided into smaller operations. A failed transaction will not partially write to the database)

Consistency (transactions can not leave data in the DB in an invalid state, data is consistent with the rules. Different than the C in CAP)

Isolation (transactions happen in isolation, even if processed concurrently)

Durability (the result of a completed transaction sticks, no matter what)

These become important when thinking about servers losing power or HDs failing while processing transactions with important data. A server going down while you update your login and password on website should not leave your account partially updated with the new login but old password (Atomicity), with an invalid blank password (Consistency) or with a corrupted values for either field(Durability).

The InnoDB storage engine for MySQL follows the ACID model. MySQL running on MyISAM does not. MongoDB does not follow the ACID model either (See Question on StackExchange for discussion). Also a nice description here

SOLID Object Oriented Design Principle

5 letters describing Bob Martin’s first 5 principles of Object Oriented Programming

Single responsibility principle

Open/closed principle

Liskov Substitution principle

Interface Segregation principle

Dependency inversion principle

I think about S, D daily. What does that make me? Dive deep into this one Wikipedia

DRY Principle

3 letters describing a principle of programming (and many other things in life).




I think about this a lot when I work, and it’s probably the strongest force that drives me to refactor code.

CAP Theorem

3 letters outlining a theory about databases. The theory states that database (or cluster of databases) can have only 2 of the following qualities.

Consistency (all nodes in a network of servers see the same data at the same time. Eventual consistency doesn’t count

Availability (a node in the network will always respond to a request)

Partition Tolerance (the network of nodes will continue to work, even if some of the nodes crash or go down)

When I work with simple database deployments, this stuff doesn’t cross my mind. When I think about scaling up, this stuff matters more. Wikipedia has more info on the CAP Theorem

LRU cache algorithm

3 letters describing which objects inside a full cache are disposed of first.




When an LRU cache (like Memcached) fills up, it will keep objects that were read or written recently, and delete the ones that haven’t been read or written in the longest amount of time (or least recently).


Coding guidelines from John Papa’s Angular Style Guide:

Locating our code is easy

Identify code at a glance

Flat structure as long as we can

Try to stay DRY (Don’t Repeat Yourself) or T-DRY