2018 Media Reviews
Life: , , ,
No comments

I’ve appreciated when people take the time to write reviews and highlight connections to other good works. This is an in-progress list that I’ll update over the course of the year. Previously: 2014 2015 2016 2017

Continue this post

One Fine Git Book: Pro Git
Code: , , ,
1 comment

As long as I’m reading too much, let me suggest that you can skip the couple dozen blog posts and half-dozen books about Git. Read this one introductory blog post and, if git sounds like a good tool for you, you can read one fine book about Git and be thoroughly informed.

I was reading through the blog of one of the GitHub cofounders and an article caught my eye because it described a process very similar to the one that I’ve heard from people who don’t use any version control:

You start your project in a directory named working. As you code, you try to write one feature at a time. When you complete a self-contained portion of a feature, you make sure that all your files are saved and then make a copy of the entire working directory, giving it the name snapshot-0. After you perform this copy operation, you make sure to never again change the code files in the new directory. After the next chunk of work, you perform another copy, only this time the new directory gets the name snapshot-1, and so on.

I like this because doesn’t insult anyone for using a process like this (as I’m occasionally tempted to do). Instead, he sees it as the first step toward the design of a distributed version control system (DVCS) to manage the process. He explains how a version control system encapsulates all the best practices people have learned from decades of coding and collaborating into a reliable software tool.

The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you.

For anybody still on the fence about whether version control is worthwhile, give The Git Parable a read to find out why most developers consider it a necessity. And even if you’re already familiar with version control it’s worth a read to get the basic concepts behind git (like that a commit it not a changeset, as in svn).

If it gets you curious to learn git, the free book Pro Git is the one book you should read. It combines straightforward, readable prose with clear diagrams:

Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their master branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into master. It’s used to pull in topic branches (short-lived branches, like your earlier iss53 branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.

This book is the best because Chacon finds the right balance between day-to-day interaction examples and exposing the underlying data model. It finds the right balance between “Don’t worry about this magic here” and “and now a discourse on directed acyclic graphs”.

And once you’ve read it, stop. You don’t need to read anything more about git, go forth and code.

Also Considered

The most common negative here is that a work is out of date: Git went from having almost nothing besides man pages from 2005-2007 to an explosion of introductory stuff in 2008 and early 2009. There were also a few significant UI improvements to git in late 2008 and through 2009 — so anything from before then will have a few confusing odds and ends, which is a problem when learning a system that’s already somewhat complex and opaque.

Git Community Book
A close second, the Git Community Book is only slightly less well-structured.
Version Control With Git
A little disorganized (there’s a lot of “X will be explained a few chapters from now”), but the O’Reilly house style you know well.
Git user Manual
Comprehensive and official, but no handholding, this is largely composed of man pages (“which read like the terse mutterings of pilots wrestling with the controls of damaged airplanes”).
Pragmatic Version Control Using Git
Well-written and includes a nice reference to git-svn. There’s nothing wrong with this book, but Pro Git is newer and has great diagrams.
Learn Git
Well-written (it’s also largely by the indefatigable Chacon) but incomplete.
Git Internals
Scott Chacon’s first excellent introduction, great but less complete than Pro Git. I haven’t seen the screencast.
Git Magic
Fairly comprehensive, but it feels a bit too conversational and doesn’t explain behind-the-scenes fundamentals.
Git for Computer Scientists
“And now a discourse on directed acyclic graphs.” A short article on git’s data structures.
Git Ready
A friendly blog with bite-sized topics, appears defunct.
Randal Schwartz on Git
For too long this was the only beginner intro to git; by the Hooter’s guy.
Linus Torvalds on Git
A fun hour of Torvalds being rude and occasionally awesome, but not any real introduction.
Using Git Without Feeling Stupid One Two
Brief pair of blog posts giving a basic introduction
Git with Rails Tutorial
Outdated and only about deployment.
Understanding Git Conceptually
Basic info on branching, merging, remote repositories, but that’s all.
An outdated and defunct screencast blog.
Git the basics
A good 130m talk on git, but it’s all the data structures before the hands-on.

…and a few dozen other brief blog posts and talks that aren’t worth linking to.

JavaScript: The Good Parts
Code: , ,

In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders. The best nature of JavaScript is so effectively hidden that for many years the prevailing opinion of JS was that it was an unsightly, incompetent toy. p2

I disliked JavaScript until I read some of Douglas Crockford’s articles arguing that it is the world’s most misunderstood programming language. I pieced together a vision of a nice language burdened by misfeatures and poor implementations. In JavaScript: The Good Parts, Crockford fully realizes that vision in a dense, enjoyable book.

If you find yourself writing in JavaScript and not enjoying it, you need to stop and read this book. (Or even if you’ve just wondered why Steve Yegge obliquely goes on about it.) The book feels a bit like Kernighan and Ritchie in that it tersely defines the language and lets the reader work through the implications. I especially appreciate that Crockford assumes a competent reader and rewards patient and thoughtful reading rather than bulking up on exposition and screenshots. It’s very uncommon in modern writing.

The book opens by defining the syntax of JavaScript with a series of railroad diagrams that are far more enjoyable and readable than BNF:

JavaScript whitespace

Next it defines objects and functions and derives useful patterns for working in JavaScript. The Module pattern he gives on p41 “…can eliminate the use of global variables. It promotes information hiding and other good design practices.” It’s a nice piece of code to deal with a personal pet peeve.

After the sections on recursion, scope, closures, currying, and memoization I was surprised not to see a section on the Y combinator, which allows creating recursive anonymous functions. There’s a blog post with a nice derivation, but it seems oddly absent from the book.

More glaringly missing, though, is code to copy JavaScript objects and arrays. On p22 he writes “Objects are passed around by reference. They are never copied.” and a code comment on p64 explains how some code avoids a related bug, but Crockford never talks about how to create shallow or deep copies of objects and arrays. It is flatly bizarre to see the topic raised and warned about without any giving a solution to an interesting and common JavaScript problem. (I personally use jQuery.extend.)

After dealing with objects and functions, Crockford combines them to talk about JavaScript’s unusual prototypical inheritance, then moves on to a nice explanation of working with arrays and regexps. After talking about the standard library and giving style notes, there are a couple nice appendicies explaining what he left out and why and presenting JSLint for automated detection of common pitfalls.

There are a few odd notes like an imprecation against continue (indeed, none of his code tries to “fail fast”) that feels like it must be based on old scars inflicted by manual memory management in C/C++. The only really puzzling oddity was in the chapter surveying the standard types. He gives JavaScript reimplementations of Array’s pop, push, shift, splice, and unshift methods (but not concat, join, reverse, slice, or sort) for no discernable reason other than a mention on p98 that he’d wanted to write a self-parser in JavaScript for a chapter he contributed to another book.

I don’t think too much about these few oddities, though, it takes a certain amount of chutzpah to distill a beautiful language from a clunky, heavily-abused language and it’s harmless to see that manifest a bit of quirky style. Mostly I spent my time reading, pondering, and tinkering with the example code. There are some great examples for creating objects and working with the prototypical inheritance, and the array sorting code (p80) is an especially inspiring bit of useful code.

The only serious negative of the book is the incessant and distracting typos. There are countless small code layout issues, bad line breaks in comments (p39), weird indentation (p40), added line breaks in code (p41), occasional camelCase. There are also a few typos in the code segments that will cause weird exceptions or, worse, silent failures. If the book didn’t have so damn much useful content I’d suggest waiting for a third printing to correct these errors (I read the Sept 2008 printing, look for a [9/08] or later in the lower-right corner of the copyright page). The poor copyediting is compounded by O’Reilly’s awful errata page; you can’t filter by printing and it includes many duplicates, making for a frustrating slog through clutter to track down why a particular sample doesn’t run.

Front cover of JavaScript: The Good Parts In spite of the flaws, I strongly recommend JavaScript: The Good Parts to anyone who regularly works with JavaScript. If it seems that I’m not making a good case for it, it’s because the power of the book is the enrichment gained from working through its examples and the negatives are easy to diagnose and explain. Read it. You’ll gain a new perspective of the language and refresh your toolbox with new techniques. Most importantly, you’ll stop being annoyed at writing JavaScript.