Manage GitHub Issues milestones in Trello

In doing product management on an engineering-led project, GitHub Issues rock. The killer features are that it’s a) really simple, b) tightly integrated with code (you can reference/close issues via commit messages), and c) facilitates discussion of issues just like it does of code.

What GitHub Issues suck at is being able to get a high-level view, where you can see more than 30 issues at a time, and broken out by milestone or by person. (You can only filter to see issues for one milestone or one person, but not easily move multiple issues between them.)

I’d really like to see a Trello-style interface for managing GitHub Issues. Some very limited integrations exist, but what I’m looking for would let you quickly move issues around between milestones. This would help plan a product roadmap and be able to visualize what the upcoming milestones look like in one place.

Read the rest of this entry »

Comments (6)

How to unit test AJAX Requests with QUnit and Sinon.JS

We write QUnit tests for, a big Backbone.js app, to help avoid introducing bugs. Pretty quickly when testing front-end JavaScript code you’ll have to deal with how to test asynchronous callbacks and especially code related to AJAX/XHR requests and how their responses are handled. Here are some basic examples of how to use Sinon.JS to handle this.
Read the rest of this entry »

Comments (3)

How to allow direct file uploads from JavaScript to Amazon S3 signed by Python

On we originally implemented to allow for file uploads while sending emails. While it was a quick way to get started with file uploading initially, after several minutes of downtime of their API and then an unannounced change in their JSON response format, I was reminded once again that you shouldn’t to rely on small startups for critical parts of your tech infrastructure.

There’s nothing wrong with if you want to use a lot of their features, but in our case we just needed to allow simple uploading of files to our own AWS S3 bucket. Here’s how:
Read the rest of this entry »

Comments (11)

Guest post on TechCrunch: Full-Stack Web Team

I had my first guest post on TechCrunch last week! Here’s an excerpt:

There is often confusion about the various roles of a web engineering team. I have had to explain, even to technical recruiters, the differences between these roles and that the lines that separate them are often fuzzy. I thought I’d share the framework I like to use to evaluate whether someone is a good fit for a startup’s technical team.

In a startup, you can’t afford to have people who are only able to do one thing. Someone could be adept at writing HTML/CSS, but if they don’t have a great eye for design or know JavaScript well, it’s just not worth having them on the core team. Similarly, somebody who knows a little bit of everything but isn’t advanced in anything will just drag the team down.

The size of the company or startup will determine how many different hats each engineer must wear. Many startups get off the ground with a single founder who does a little bit of everything until he or she can grow the team. It’s also possible to outsource some roles completely. Just as cloud-hosting providers such as Amazon Web Services have drastically reduced the need for hardware/network engineers in web startups, platforms like Heroku take it further and (for a price) can reduce sysadmin and DevOps work almost entirely in the beginning.

In pretty much every case, when a startup grows, people will inevitably start specializing. Even those rare gems, who in the early days can spend the first half of the day in Photoshop and the second half scaling a database, will eventually specialize at least somewhat. If you’re hiring well, you’ll always find someone who can outperform you in at least one area.

I’m a big fan of “full stack” people and think specializing too much, too early, is a bad sign for startups. At Elastic, each of our engineers has written CSS and done database/server management. It’s good when a problem arises for there to be more than one person capable of fixing it. That said, I’m spending the bulk of my day writing in JavaScript/Backbone.js because I enjoy it much more than a coworker who’d rather be in Python as much as possible. That’s healthy and it works.

You can read the rest over there.

Comments off

Launched – sales communication software

I just launched a website for, the product we’ve been working on at Elastic for the past few months.

Go check it out:

We’ve built this as “sales communication software”, which we believe didn’t really exist before. CRMs (, I’m looking at you!) are inadequate because they are more like databases of contacts than software that really helps you do the selling. We’ve trying to change that by making your sales phone calling and sales emailing experience tightly coupled with your lead data (CRM).

Would love to hear any feedback you have about the product!

Comments off

Mac Software I Use

I just got a sweet new MacBook Pro Retina – way faster than my old MBP. I wanted to do a clean install rather than restoring from a TimeMachine backup, which meant reinstalling software and manually transferring stuff over that I really needed. I kept a list…

Read the rest of this entry »

Comments off

Quick notes from Startup School 2012

I got to go to Y Combinator’s Startup School this year and had a great time. Between the reception dinner the night before and the day of event I got to meet a lot of great people and reconnect with some I’d met in the past or only talked to online. Most of the speakers were really good.

I took some very brief notes during some of the talks of the 1 or 2 things that stuck out to me as either surprising, motivational, or instructional.

Read the rest of this entry »

Comments (1)

Stripe CTF 2.0 – Web Security

I did Stripe’s Capture the Flag 2.0 this year, “a security contest where you can try your hand at discovering and exploiting vulnerabilities in mock web applications”.

It was a lot of fun. Some of the levels were quite challenging and I had to figure out how to actually implement an exploit vulnerability that I’d only read about in passing before. Each level makes you both a) figure out what the vulnerability is, and b) actually exploit it. One thing that the Stripe guys did a nice job at was spreading out the challenges between PHP, browser JavaScript, node.js, Python, and Ruby, so that developers from any one language wouldn’t have an advantage.
Read the rest of this entry »

Comments off

Objective Process for Product Reviews

I watched Jeff Veen’s “Designing for Disaster” talk (below) and took away a couple of parts that I thought were really good. Some notes:

How to do Product Reviews (can be design, product, process, anything) — making an objective process out of something that is very subjective.

  • Optional attendance, but mandatory participation (keeps everyone focused)
  • Not a forum for expressing opinions
  • Rather, a place to solve problems.
  • Define in the beginning if session is supposed to be divergent or convergent.
    • Divergent -  I want as many ideas to solve this problem as possible – let’s talk about everything; brainstorming
    • Convergent - Evaluating feasibility, acknowledge constrains. Drive towards consensus.
Driven by Purpose
  • Measure momentum in days (weekly checkup of progress)
  • Measure projects in weeks (figure out pace, when we will go out with the next thing)
  • Measure priorities in months (“we’re going to focus on performance and distribution in Q2″)
  • Measure vision in years (“organize the world’s information and make it universally accessible”)


Comments off

Uploading static assets (CSS/JS) to S3 for CloudFront CDN

For a new Backbone.js + Flask project I’m using grunt + grunt-contrib, RequireJS’s r.js, Flask-Assets / webassets for static file (LESS/CSS, JS) compilation. But I needed a good way to get my nicely optimized static files onto a CDN and serving proper HTTP headers.

Using the excellent s3cmd tool, here’s what I came up with.

This example will break for browsers/proxies that don’t support gzip, but this is fine for my needs. Any other solution would either require a custom origin web server or writing different filenames in HTML depending on the request coming in. But since I want to use S3 as my origin this is the easiest/simplest solution.

Since all assets are “built” with a md5 version number hash in the file name, I want far futures headers to cache permanently.

Comments off

« Previous Page« Previous entries « Previous Page · Next Page » Next entries »Next Page »