Five years of HipChat

Last week marked the 4th anniversary of HipChat‘s launch. We started prototyping it about a year before that which means that I’ve been focused on HipChat for about five years. That’s longer than college or any previous jobs I’ve had, though it certainly doesn’t feel like it. We’ve grown tremendously as a product and team since joining Atlassian almost two years ago and 2014 is shaping up to be our most exciting yet!

Our tiny office in 2010 (Sunnyvale, CA)

Steve Jobs on the bottom line

Jobs: We’ve been having record quarter after record quarter, so we’re very pleased with how the company’s doing. And, uh, you know, Wall Street, I’ve never been able to figure out Wall Street. But someone once told me manage the top line, which is, your strategy, your talented people, and your execution, and the bottom line will take care of itself. And I’ve always found that to be the case. So, we’re turning in record quarter after record quarter, and Wall Street eventually comes out in the right place.

Formatting JSON on the command line

If you ever work with JSON on the command line, try out the json_reformat tool included in yajl-tools package (or install from source).

Without json_reformat

$ curl
"name":"Garret Heaton","created_at":"2009/04/04 08:36:09 -0700",
"location":"Sunnyvale, CA","public_repo_count":18,"public_gist_count":67,

With json_reformat

$ curl -s | json_reformat
  "user": {
    "gravatar_id": "d5894734b9f67c07b276319fdc2e5d88",
    "company": "HipChat",
    "name": "Garret Heaton",
    "created_at": "2009/04/04 08:36:09 -0700",
    "location": "Sunnyvale, CA",
    "public_repo_count": 18,
    "public_gist_count": 67,
    "blog": "",
    "following_count": 8,
    "id": 70472,
    "type": "User",
    "permission": null,
    "followers_count": 7,
    "login": "powdahound",
    "email": ""

So much nicer!

It will even tell you if there are syntax syntax errors (as will json_verify).

Hosting a static site on Amazon S3:

Amazon added the ability to host static sites on S3 recently so to try it out I made a small site comparing the different types of EC2 instances: It’s not much of a site but it was the only thing in my ideas list that didn’t require some sort of database backend.

The setup was very simple:

  1. Buy the domain ( is so much nicer than GoDaddy by the way).
  2. Point domain’s nameservers at my slicehost account.
  3. Add a new DNS domain in slicehost and add a single CNAME record with a name of ‘www’ and data of ‘’
  4. Install the latest Cyberduck (Mac). Windows users can use one of the tools here.
  5. Create a new S3 bucket called ‘’ and configure it for static site hosting.
  6. Upload all my files and change their permissions to make them readable by everyone.
  7. Done!

Updating the site is easy – just select the file in Cyberduck and click the ‘Edit’ icon in the toolbar (or hit ⌘K) and it will automatically upload the file whenever you save. If I needed a real deploy system it’d be pretty easy to whip up something with Fabric and Boto.

Overall it seems like a great way to host a static site on the cheap (~$1.50/year for this). The only real downside is that you can’t have your root domain hit the bucket because a CNAME must be used. This means that does not resolve properly. More details here.

Note: I tried to use Amazon’s new Route 53 DNS service instead of my slicehost account but the configuration is still a bit more involved than I’d like. Hopefully they’ll add it to the AWS web console soon.

Use git-hooks to make sure you never check in ugly code again

The git-hooks project provides a way to run git hooks locally before you check in your code. This is especially useful if your code is hosted on GitHub because you don’t have access to install server side hooks.

From the README:

Hooks can be very powerful and useful. Some common hooks include:

- Spell check the commit message.
- Check that the code builds.
- Verify that any new files contain a copyright with the current year in it.

Hooks can be very project specific such as:

- Verify that the project still builds
- Verify that autotests matching the modified files still pass with no errors.
- Pre-populate the commit message with the ‘standard’ format.
- Verify that any new code follows the ‘standard’ coding style.

or very specific to one person such as:

- Don’t allow a push to a remote repository after 1am in case I break something and will be asleep.
- Don’t let me commit between 9-5 for projects in ~/personal/ as I shouldn’t be working on them during work hours.

I wrote some hooks for checking PHP syntax and checking Python files using PEP-8 and PyFlakes.

Hopefully they’ll integrate this functionality into the git core at some point.