The process went fairly smoothly (all things considered, when 5 people all write a book at once, mostly over a weekend). There were some challenges with timezones and schedules, but overall the team did a great job getting it done.

We started by building our sample project, Hubbub (a GitHub Issues tracker in a Kanban format), upon which we’d base the book. We wanted to build an app that was more complex / real-world than the typical localstorage Todo list example apps out there. You can see the final project live here.

You can read more about the book on the publisher’s site here: Developing a Backbone.js Edge, or buy it from one of these locations:

• Gumroad ($5 cheaper!)
• Safari Books
• Amazon (Kindle)

Thanks to Casey Foster, Aidan Feldman, David Tonge, and Tim Branyen for co-writing it with me, and for Troy Mott for organizing the book sprint.

And now for some SEO love… I hope this book will become one of the best selling Backbone.js tutorial books out there!

Take this view, for instance:

Sure, these 3 lines look fine — there are valid Python code and don’t contain any obviously flawed logic. And I can see which file it’s in (app/resources.py), and even the method name (‘validate_request’). But this very often isn’t enough for me to really review what’s going on. Do these lines make sense here? I have no idea from this view.

One reason is that seeing 2 lines of code above a change doesn’t really give me enough context even within a method. Another reason is that it’s not uncommon (especially in Python apps) to have a bunch of similar classes in the same file, that may all implement the same method names. In this case, how do I know which Resource class this code was added to?

Now, GitHub is just showing “git diff” which includes 3 lines (including whitespace) of context by default. But between git-diff’s additional options like –unified/-U (which allow you to show more than 3 lines of context) and  –function-context/-W, as well as the ability for them to combine AJAX-ey goodness, there’s a lot of opportunity for improvement.

Here are some ideas:

• No UI Approach: For starters, add a querystring feature like ?u=7, which would show me 7 lines of context instead of 3. They already do this with ?w=1 to show a diff that ignores whitespace changes and it comes in handy. This “no UI” approach is a no brainer, in my opinion.
• Get fancy with JavaScript: See the little “…” above line 422 which represents all the extra code? This is the web… I should be able to click on the ellipses to expand the context. It could load in and display several extra lines of code when I click this to let me see additional context about the code I’m reviewing.
• Get fancy with git: I’m not sure exactly how git-diff shows the function (def validate_request(self, obj=None): in this case) at the top of each chunk, but some intelligence could be added so that showed the class/object name in addition to the function/method names.

Can you think of a better way to solve this problem?

The startups and services behind Close.io

• GigOm: Close.io is a social context for sales communications
• PandoDaily: Elastic launches Close.io, sales software designed by salespeople
• Forbes: Y Combinator-Backed Close.io Launches Sales Software

They’ve got a couple good quotes from me in the PandoDaily article.

Company

I started 2012 in a new role at ElasticSales to lead the product/engineering team, working on software to make better software for sales people. It’s been a great year and I’ve gotten to learn a lot of stuff and work with a great team.

ElasticSales.com – Designed a company website to show credibility for our sales as a service business, help with hiring, etc.

Close.io – Launched the sales application we’ve been working on for months (and I launched this website for it). Designed completely different from traditional CRMs like Salesforce, Pipedrive, etc. it’s focused on helping with sales communication rather than just being a database. It does this by automatically logging all calls and emails (incoming and outgoing) in one place to remove the typical data entry associated with CRMs. Also making it much more beautiful and fast than those legacy sales apps.

A big goal for 2013 is to make Close.io a huge success as a profitable SaaS service that people love.

Design

I added 12 shots on Dribbble in 2012. Though most of my “design” work was simply trying to make good user experience in Close.io.

Front-end Development

Backbone.js – I had significant experience working on big JavaScript projects before 2012 (using vanilla JS, jQuery, MooTools, etc.), but hadn’t used a higher level framework like Backbone.js. In the past 12 months I’ve been primarily doing front-end development and built two large apps using Backbone. I’ve also been able to contribute a few patches, features, and unit tests to the project. I love the framework because it seems to provide just enough structure to be useful everywhere without too much bloat. It’d be hard to imagine making another client-heavy web app without using something like Backbone.

Along with writing a bunch of code specific to Close.io, I’ve become deeply familiar with several Backbone add-ons:

• Backbone-Forms – Auto-generate HTML forms that sync with Backbone models. I’ve been able to contribute significantly and help triage pull requests and issues for this project.
• Backbone-Relational – Adds relations between Models & Collections. I contributed significantly to this project as well.
• Backbone.Declarative – Adds a declarative syntax (similar to how Backbone DOM events work) for binding Model/Collection events to Backbone Views. I helped rewrite this project to work better with Backbone 0.9.9.
• Backbone-Super – Nice syntax for calling “super” for friendly OOP-like functionality
• Backbone.Stickit – 2 way DOM <-> Model binding
• Backbone.InfiniScroll – Infinity scrolling in Backbone Views
• Backbone.Mousetrap – I wrote this as a better integration of Mousetrap (JS keyboard library) in Backbone Views.
• Backbone.Mutators – Provide getter/setter support on Backbone Models. Started with this project though ended up writing my own implementation that I thought was better.

Grunt – Useful command line / JavaScript-based tool for creating tasks for minifying, concatenating, compiling JS/CoffeeScript, etc. Used heavily in our deploy process.

RequireJS – I’m using RequireJS heavily to keep our application nicely organized into modules, with dependencies declared explicitly.

LESS – extends CSS with a better syntax, mixins, variables, etc.

QUnit – I got much more serious about front-end / JavaScript unit testing this year, as well as better at testing in general.

Bootstrap – used as a base set of styles and core mixins. Great when using LESS

Several other front-end JavaScript projects, jQuery plugins, etc. Most of my open source work is done via Elastic’s GitHub.

Back-end Development

Python – In 2012 I went from only know a touch of Python to feeling comfortable writing significant amounts of code in it. I added plenty of features and fixed plenty of bugs. I’d definitely use Python instead of PHP now for new projects and am a big fan of its simplicity and syntax.

Django – I spent several months working on a Django project. I got deep into Django and used various add-ons for it. For any significant traditional web app written in Python, I’d still recommend using Django.

Flask – I’ve written 4 or 5 projects using Flask now and love it for its simplicity. We’re using Flask for Close.io and are using several extensions (that we wrote and 3rd party). My team wrote Flask-Mongorest which especially has made writing a MongoDB-backed JSON REST API super convenient.

MongoDB – I’ve learned a good bit about using MongoDB, and some of its best practices, as well as its gotchas.

AWS – I’ve used several AWS services before 2012, but this past year led to much more significant experience using EC2, S3, RDS, Route 53, ELBs, etc. I’ve deployed several different services using both raw AWS as well as Heroku now, and love the flexibility and ease for creating scalable systems.

Blogging

I redesigned my personal website/blog this year for the first time in 6 years! I also had 13 blogs posts this year, which is pretty good for me, as well as a guest post on TechCrunch. Here are my 2012 blog posts:

• Two Years at Quizlet
• Why is this so hard… Apple
• How to upgrade MacPorts to OS X 10.8 Mountain Lion
• PhilFreo.com v3 (and past versions)
• Uploading static assets (CSS/JS) to S3 for CloudFront CDN
• Objective Process for Product Reviews
• Stripe CTF 2.0 – Web Security
• Quick notes from Startup School 2012
• Mac Software I Use
• Launched Close.io – sales communication software
• Guest post on TechCrunch: Full-Stack Web Team
• How to allow direct file uploads from JavaScript to Amazon S3 signed by Python
• How to unit test AJAX Requests with QUnit and Sinon.JS
• Manage GitHub Issues milestones in Trello

I’d like to do shoot for at least 13 posts in 2013 as well.

Personal

It was a big year for me. I started a new job at Elastic, started a life with Kristin after getting married on New Years Eve, moved to a new apartment in a new town, and started attending a new church! Let’s hope 2013 is as exciting!

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.

The closest thing I’ve seen is Huboard (GitHub, site, blog post), but it doesn’t do milestones currently [edit: now it does!].

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.

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.

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.

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:

Here’s the gist with all the embedded code.

Thanks to CodeArtists for the original tutorial. I improved their code some and converted it to Python.

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.

Go check it out: http://close.io/

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!