Deployment – If It Hurts, Do It Again

If deployment hurts, do it again.

Frequent painful deployments force you to automate and improve the process.

Your development environment may be wonderful. Your test coverage may be high. But your code has to go live. If that’s an infrequent process of giant merges and close-your-eyes-and-hope code pushes you risk bugs. “Little and often” reduces risk and decreases pain.

The logical conclusion: continuous deployment.

git add -p

I tell people to use git add -p not git add FILE or git add .

The benefits are huge:

  1. You decide exactly what’s in your commit. Any later inspection of your commit is improved — code review, git blame, git log, git bisect — everything. No more “Changed WidgetManager to use Widgets not Sprockets, corrected docs for SprocketManager, deleted four unnecessary files and added a new log image.”
  2. You review your changes before committing. Another chance to spot bugs or realize that your documentation doesn’t make sense or that you left in a TODO or a debug statement.
  3. You won’t accidentally commit work in progress.

You aren’t welcome on my project if you don’t use git add -p! And git add ., frankly, should be an error!

Recruitment Emails

Recruiter emails are getting better.

This was where we used to be:

I wanted to shoot you a quick note on hot new Silicon Valley startup
MonkeyLab. MonkeyLab is x months old, has y million dollars in funding
and is going to transform the home monkey-rearing market.

When can we talk on the phone?

Now the low bar is a mention of my linkedin profile and some skill I have that they need.

The high bar is an email that isn’t from the recruiter but from the hiring manager. Mentioning specific things that are only true about me. These get a response at least.


My name is Bob and I’m not a recruiter. I run the Advanced Something group
at MonkeyLabs.

I see from your LinkedIn profile that you are a ruby programmer and that you
have some experience of Erlang. We’re building an Erlang program with
ruby web app interface and we’d love to add you to the team.

I’m building for the future so even if you aren’t looking for an opportunity
now perhaps we can have a chat?

Does this represent a newfound earnestness on the part of those in charge of recruitment in Silicon Valley? Or is it just an arms race between my personal filter and the content of their emails? An arms race they can win because of the increasing amount of personal information available about me on the internet. In some sense it doesn’t matter. Forcing this kind of more sophisticated personal email that explains why I might be interested makes the initial interaction much more valuable either way.

Now I’m just waiting for this email:

Hi Tom,

My name is Paul Graham. I’m not a recruiter.

We’re looking for a tall developer with blue eyes who wants to
simultaneously build the next generation Magic: the Gathering app and do
something worthy-yet-technical like Kiva while being fabulously

The app is going to be written entirely in Haskell. You will work alongside
Simon Peyton-Jones, Steve Yegge and Aaron Swartz.

In your spacious private offices in London, San Francisco and Tokyo there
will be live music from the Decemberists and Amanda Palmer.

Here’s my personal cell number, call any time of day or night.



PS Spectrum BASIC > Lisp

Exactly What You Write Makes a Lot of Difference

I wrote a blog post in 2003 about a not-very-useful error message I got while working on a .NET SOAP web service*: Server did not recognize the value of HTTP Header SOAPAction.

I wrote at the end of the blog post: “If you’re having a similar problem but can’t work what I’m saying here, feel free to mail me on”.

Although this is an obscure blog post on an obscure blog over the nine years since I wrote it I’ve received 159 emails asking for help. I think I’ve received a total of about 2 emails about other blog posts of mine.

I suppose if I added my email address to the bottom of each of my posts and exhorted the reader to email me I’d have a lot more emails. This reminds me of Dustin Curtis’ article about following him on Twitter.

* = I’m not proud of this chapter in my programming history!

Painless Social Sign In with Oneall

I had a need for social sign in recently in a project that I needed to complete in a weekend. Rather than build something using Facebook/Google/Twitter/etc. APIs I used oneall. A small amount of javascript and a backend call later and I have pretty good social sign in integration with a bunch of providers. Your control over the look of the div they supply is limited (at least in the free version) but the integration is good. Recommended.

Move Fast and Break Things

I had lunch at the Facebook campus yesterday. They have transported all their motivational posters to their new(ish) location in Menlo Park (which is really, really nice). “Move Fast and Break Things”, “What Would You Do If You Weren’t Afraid?”, etc.

This led to a short conversation about how, exactly, you move fast and still produce good code. Facebook don’t have QA instead they have systems designed to automatically catch errors before they hit production. D thought that if you had good tests you didn’t need documentation or QA or code review. I’m a bit more cynical about tests and I love code review for sharing knowledge and style as well as finding bugs.

Also saw two Facebookers with “Fix More, Whine Less” tshirts.  It’s the slogan of the Site Reliability team. They do seem to be scaling their startup-ish culture to a larger scale than most companies manage.

Things You Can’t Do With CSS

We spent some time looking at this yesterday and found it surprising.

We wanted to create a set of three divs where the size of none is of a fixed width. The left and the right should expand to match the size of the content. And the middle div should pick up the slack and make the whole thing as wide as the page. The middle div needs to also contain a search box (input) that stretches out to fill the div.

<div class="left">Some variable content here</div>
<div class="middle">
    <input type="text" class="text">
<div class="right">Some other variable content here</div>

Apparently it can’t be done without tables (which messes up our responsive design). We tried floats and relative positioning.

It was interesting to me that this literally couldn’t be done. Or can it? curl Billboard Billboard

I just don’t understand who could know enough to come up with this but not enough to know how flagrantly wrong it is and how it would read to someone who just even knows what curl is. Is the idea the programmers will become so incensed by the mess that is this commandline that they write in angrily and then you offer them a job? It completely baffles me. I’d love to hear an explanation.

Web App Checklist

  • It is more important to have a standard than what the standard is.
  • ‘use strict’ in JavaScript.
  • jslint
  • jQuery
  • Throw objects not strings as exceptions in JavaScript:
    throw {
        'name': 'MyException',
        'message': 'Something went wrong',
        'code': 500,
        'previous': e // Nested exception.
  • Controllers should be super-skinny (because they are hard to test).
  • HTML5
  • Only read querystring and post body in the controller.
  • Say *why* you did something in the commit message, don’t just describe what you did.
  • The first line of a commit message should be a short standalone message.
  • Err on the side of verbosity in commit messages.
  • Don’t form HTML in JavaScript strings.
  • Good internationalization is hard (ICU?).
  • Run the tests before pushing.
  • Automate deployment.
  • Keep markup as semantic as possible.
  • Code review is a priority.
  • LESS
  • Responsive Design
  • Backbone
  • Automatically pull dependencies in, don’t add them to the repo.
  • Don’t store artifacts generated by the build process alongside the source code.
  • git
  • Unit tests
  • The unit tests should run *fast* and offline.
  • Send the right HTTP response code.
  • JSON