Important Name Thingies in CS

Nov 14, 2015 · 7 minute read · Comments
Cheatsheet

Note: this is just getting started, I’m missing A LOT of stuff. Give me a shout if something stands out

I’m a bit of an oddball - my mnemonic memory is sometimes quite poor and in computer science we have lots of law’s and rules which are referred to. It’s good we do, it gives us a more Ubiquitous Language. However it also has some downsides, if you suck at remembering names then it’s easy to mix these up.

I figured I’d create a cheatsheet of sorts, besides you might find something here which you’ve never seen before. If you’re new it’s OK to follow these dogmatically, if you are getting more experienced it’s good to think about when these are and aren’t good things to do.

Uncategorized

Clockwise/Spiral Rule - David Anderson Parsing any C expression

Occam’s Razor or in latin: Lex parsimoniae: The simplest explanation is usually the best.

KISS: Keep it simple, stupid - Kelly Johnson

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.” Antoine de St. Exupery, Terre des Hommes, 1939, chap.3.

Uncle Bob quotes: “And yet all developers feel the pressure to make messes in order to meet deadlines. In short, they don’t take the time to go fast.”

First Law of Programmer Creativity: Caveat Emptor: The cost of software maintenance increases with the square of the programmer’s creativity. Robert D. Bliss

Software Managment

Brooks’s Law: “adding manpower to a late software project makes it later.”
-Brooks, Mythical Man Month

LeBlanc’s law: Later equals never.

Possibly my favorite since you can’t beat a recursive law in CS
Hofstadter’s Law: It always takes longer than you expect, even when you take into consideration Hofstadter’s law.

Conway’s Law (Congruence): the structure of a software system will reflect the structure of the organization that builds it.
A great talk given by @rachellaycock of ThoughtWorks talks about how Conway’s law will limit or destroy your chances of success when moving to Continuous Delivery.

Software Engineering

Ward’s principle: “You know you are working on clean code when each routine turns out to be pretty much what you expected.”

DRY: Do not repeat yourself. In other words copy and pasting code can be bad. SOLID principles

• Single Responsibility Principle: Every method, class, and module - should have one obvious¹responsibility²
• Open/Close Principle: A class should be open for extension and closed for change
• Liskov Substitution principle: A subclass should ‘just work’ anywhere the super class worked, with no changes in code. More formally when talking about any subclass, it’s method’s preconditions should be at A least as broad as it’s super class, and it’s postconditions should be less than or equal to it’s super class.
  
• Iterface Segregation Principle: Having a bunch of specific client facing interfaces³ is better then one general purpose one
• Dependancy Injection Principle: Depend upon abstractions, and not concrete implementations.⁴

the programmer thinks in terms of (genenerally) real life objects and their responbilities. See Steve Jobs explain it here

YAGNI: You ain’t gonna need it - don’t add functionality until it’s absolutely necessary.
This is closely tied to a quote from Donald Knuth:

Premature optimization is the root of all evil

Law of Demeter: this is the principle of least knowledge, it’s foundational to good OOP⁵. It says that an object should have the least amount of knowledge possible about how another class does it’s work. This is Steve Jobs explaining OOP, and this idea of not knowing is the law of demeter:

Objects are like people. They’re living, breathing things that have knowledge inside them about how to do things and have memory inside them so they can remember things. And rather than interacting with them at a very low level, you interact with them at a very high level of abstraction, like we’re doing right here.

Here’s an example: If I’m your laundry object, you can give me your dirty clothes and send me a message that says, “Can you get my clothes laundered, please.” I happen to know where the best laundry place in San Francisco is. And I speak English, and I have dollars in my pockets. So I go out and hail a taxicab and tell the driver to take me to this place in San Francisco. I go get your clothes laundered, I jump back in the cab, I get back here. I give you your clean clothes and say, “Here are your clean clothes.”

You have no idea how I did that. You have no knowledge of the laundry place. Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one, you don’t have dollars in your pocket. Yet I knew how to do all of that. And you didn’t have to know any of it. All that complexity was hidden inside of me, and we were able to interact at a very high level of abstraction. That’s what objects are. They encapsulate complexity, and the interfaces to that complexity are high level.

Databases and System

ACID:

• Atomicity: When doing a set of operations, they should be able to either all complete, or all fail. No in between (this can lead to an inconsistent state of the database)
• Consitency: The database as a whole should be able to maintain it’s contraints. A contraint is a rule, or limitation imposed on your system. Something like: all email addresses must be unique, or all names must include less than 3 double-barrelled names :-D
• Isolation: A guarantee that transactions will not interfere with each other. In other words if Bob and Jeff both try to register for the email totally-aweseme@gmail.com, we must be able to guarantee that at most one of them is told they get it.
• Durability: Once something is said to be saved or ‘committed’ we guarantee it will persist. So if a server restarts at any time after Jeff gets the email “totally-awesome@gmail.com” we guarantee he still has that email after a restart.

BASE Read more here

• Basic Availability: There should always be some response to any request. People should be able to use the system - even with issues arise.
• Soft State: The state of the system can change over time, even when no new transactions are happening - this is because of the fact that eventual consistency may be propagating through the system.
• Eventual Consistency: As long as we can guarantee that it will at one point become consistent, that’s good enough.

ACID and BASE are a continuum. ACID is pessimistic about what might happen, BASE is optimistic and accepts the risks.

CAP:
The CAP theorem states that any networked shared-data system can have at most two of three desirable properties:

• Consistency: Any user cannot make an inconsistent change to the database. Similar to the isolation example above.
• High Availability: When someone is on the system (usually around the world) they can use it. Period. It doesn’t mean mistakes can’t be made when errors occur, just that it’s available to be used.
• Partition Tolerance: Even if different (usually geographical) parts of your system are unable to communicate - or some break - the system still ‘works’. When all the servers that communicate with Europe stop connecting, the system will still be usable.

It is traditionally said that you must choose 2 out of 3 for your system, because we believe that’s the best you can do. Here is a great article from the man who came up with the CAP Theorum and he talks about how thats not quite true, and how all these three theorums relate.