See John Read...

In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.

The interview is very interesting especially for the discussion of GitHub’s architecture.

He mentions the following Ruby and Erlang libraries:

• grit / gitr (git libraries) {Ruby}
• fuzed {Erlang}
• egitd (git daemon) {Erlang}
• bj (background job processor) {Ruby}
• god (process monitoring) {Ruby}

His reasoning for writing egitd in Erlang is eye-opening. I’ll paraphrase his reasons as follows:

• Erlang is a functional programming language, which means it disallows side effects. This provides for referential transparency, which makes it easier to parallelize programs.
• For server applications, this means that each incoming connection can be spawned off into a lightweight ‘process’ and executed in parallel on separate cores. You get this parallelization without having to create actual OS processes, which would take more memory, allowing your server to be very memory-efficient.

In this talk Robert C. Martin outlines the practices used by software craftsmen to maintain their professional ethics. He resolves the dilemma of speed vs. quality, and mess vs schedule. He provides a set of principles and simple Dos and Don’ts for teams who want to be counted as professional craftsmen.

Lecture Notes
1) Discipline
2) Short Iterations
3) Don’t wait for Definition
4) Abstract away volatility
5) Commission > Omission
6) Decouple from others
7) Never be Blocked
8) Avoid Turgid Viscous Architectures
9) Incremental Improvement (always checkin code a little bit better than when it was checked out)
10) No Grand Redesigns
11) Progressive Widening (add a small feature top-to-bottom (called a “slice”, or “spike”), from the gui to the database, and then widen as needed on each architectural layer)
12) Progressive Deepening (start with something that works, and then pull it through the architectural layers. ex: if you’re adding a login feature, get it working from the login page and then refactor into proper architectural layers)
“First, make it work, then make it light, then make it fast.”
13) Don’t write Bad Code (the only way to go fast, is to go well)
14) Clean Code (our product is code. if the code is a mess, the product is a mess. the only way to go fast is to go well)
clean code:
1. it takes you 5 minutes to understand.
2. “when code reads in such a way that every line of code is what you expect it to be” —Ward Cunningham
15) TDD
three laws : you are not allowed to…
1. write a line of production code until you have written a failing unit test.
2. write more of a unit test than is sufficient to fail (including failure to compile)
3. write more production code than is sufficient to pass the failing test.
15) QA Should Find Nothing (some developers use QA to find their bugs—this is unprofessional.)
16) 100% Code Coverage (you’ll never achieve 100%, but strive to get as close as you can)
17) Avoid Debugging (don’t leap into the debugger. stop. think. it’s usually something simple)
18) Manual Test Scripts are Immoral (a human should never do what a machine can)
19) Definition of Done (there’s one definition: all tests pass)
20) Test through right interface (test each layer independently. don’t couple business logic acceptance tests to the gui)
21) Apprenticeship (the knowledge of our profession lives in us, it’s not in the schools. take the responsibility to grow new hires)
22) Use Good Tools (the best tools out there seem to be the free ones)