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.
[Edit again: Waffle.io and Gitlo look like more recent tools that would do a good job of this]
Zapier has some existing hooks for both GitHub Issues and Trello, but they seem to all be around creation, rather than a 2 way sync of moving around and editing. It’s possible that some improvements to the Zapier Apps would make the integration possible.
I’m thinking it would make a cool side project to use the Trello API and GitHub API to do this. Basically:
Look for all GH issues from a repo with specific labels (whether that be “trello”, “feature”, etc.) – but on big projects you likely don’t want to see every little bug in Trello.
To “link” a Trello card to a GH Issue to allow 2-way sync, you could just use the GH Issue # in the card name, like “Add Twitter integration (#187)”, unless Trello support saving some custom source key field.
If new cards are created in Trello, their titles should get updated with the GH Issue #, once saved.
If new issues are created in GitHub, have them show up in the Trello board in the list corresponding to the milestone or else “No Milestone”.
Moving a card from one list to another should change the GH issue milestone, and vice versa.
Creating a new list in the board would create a new milestone. Same renaming strategy for milestones as we have for cards/issues.
2-way sync is always tricky and open to conflicts, but we should be able to just take whichever action had a later updated date.
Anyone have a better idea? Or something I’m missing?
For completeness, there are two other semi-related projects. Hubboard (GitHub, site) seems inactive and also has the same limitation as Huboard. Also 280 North has a very nice looking GitHub Issues viewer (site, GitHub, blog post) but it looks to be completely abandoned and no longer working.
We write QUnit tests for Close.io, 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.
Mocking Responses
Have some code that relies on an API response coming back that you want to test? Here’s an example of mocking out the HTTP response to test a Backbone.js Model#fetch() method.
Testing Requests
But what about testing the actual request side of things? A lot of basic tutorials leave this side of the XHR out. When dealing with complicated code it can be non-trivial to determine how the AJAX request is formed, so of course you should test it!
Here’s an example testing that a Backbone.js Model#save() method produces the HTTP request that’s expected. In the real world, the Model would be much less trivial. It relies on the useFakeXMLHttpRequest feature of sinon.
To get more advanced, you can learn about mocks, stubs, and spys in the Sinon.JS documentation.
On Close.io we originally implemented Filepicker.io 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 filepicker.io 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:
Setup S3 Bucket with CORS Policy
Create an S3 bucket from the AWS Console (if you haven’t already). In its properties, click to Edit CORS Configuration:
This will allow cross-domain posting from the client.
Setup an IAM user
You can use your main AWS credentials, but I recommend generating keys with only the permissions that are necessary. In AWS, setup an IAM user with the following permissions policy.
Add the JavaScript
First grab the code and then implement it on your site:
Server endpoint for signing requests
To protect your AWS user credentials, we keep them on the server and then “sign” each upload right before sending it to S3. Here’s the endpoint in Python / Flask:
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.
We’ve built this as “sales communication software”, which we believe didn’t really exist before. CRMs (salesforce.com, 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!