I’m working on invoice/receipt generation for Close.io and wanted to create simple PDFs using nothing but HTML.

Using Flask, mimerender, and xhtml2pdf, here’s how:

My blog post on the Close.io blog was pretty popular (18,000 pageviews & lots of HN comments) so I wanted to cross-post it here:

Sweating the UI & UX details in Close.io: Emails & Email Addresses

We like to think of our sales software, Close.io, as having a lot of magic under the hood. When we do our jobs successfully, our users may not even notice, but their lives will be made a little easier. We try to make features just work without requiring users to think too much, even if that adds complexity in code.

Here are a few examples:

1) Entering contact details

Most CRM and address book software make you enter your contacts’ phone numbers, email addresses, and URLs in specifically chosen separate fields per data type.

We realized this sucked and now give you a contact form like this:

You shouldn’t have to make a choice for each phone number, email address, or URL you enter for a contact. We just give you one place to enter all their contact information and we figure out what type of data is what. (Then you can 1-click call or email this person).

Is taking a string and deciding if it’s either a phone number, email address, or URL particularly hard? No, but it’s “hard enough” that most CRMs and address books don’t do it, and we wanted to take the extra time to make our users’ lives easier, even if they don’t notice it.

2) Pasting contact email address

A recent iteration on the contact form was improving a fairly common scenario where you had email from somebody and wanted to save their email address onto a contact. Many email clients give you a string like: “John Smith” <john@example.com> when you copy the address. Originally if you tried to enter that as an email address in Close.io it would complain about it not being in the simple email format like john@example.com.

Now, when you paste that text into the email field we’ll automatically pull out the email address part and fill in the contact’s name field if it’s blank:

Again — not particularly difficult, but something most software doesn’t do. This is the type of magic that many users won’t even notice or think twice about, but helping users avoid validation error messages is as much of a benefit as any new feature you could make.

3) Zero configuration email sending

The first few times you try to send email in Close.io, it’s as simple as clicking the big “Email” button on a sales lead, typing a message or choosing a template, and clicking send. We already know your email address when you signed up, and we use our own Mailgun account to send email as/from you, so that it just works.

We do put a cap on the number of emails you can send without entering your own SMTP credentials (which will also give you better email deliverability), but for users just checking out Close.io, it’s one less configuration step in the beginning.

4) Magic email tracking from all your email clients

Forget having to BCC/Foward all emails with sales prospects to some random CRM email address. Plug your IMAP credentials once into Close.io and we automatically track your sent and received sales emails regardless of how/where you send them.

Much more to do…

We have a long list of other little UI/UX improvements we need to make, but hopefully this was enough to encourage you to think twice about the tools you’re using and discover opportunities for improvement.

And if you’re a software developer… be sure to sweat the details – it takes more time, but it makes for happier users!

We’d love to hear your reactions… follow @closeio and @philfreo

– Phil Freo

On my goals list for 2013 was to write an eBook of some sort. When I was approached to join some other Backbone.js contributors in a “book sprint” to write a book on developing a Backbone.js application, I happily accepted!

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!

We use git and GitHub’s Pull Requests fairly heavily in developing Close.io sales software. My main problem with pull requests as code review is that it focuses my attention too much on the specific lines of code added/removed/modified, but not enough on the context of where they were added/removed.

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?

Originally published on the Close.io blog.

The startups and services behind Close.io

In creating Close.io software for salespeople, we rely on a number of other startups and services to do what we do. While there are alternatives to using each of the following, we have chosen them for specific reasons because we think they’re the best.

The common theme is that these services allow us to move faster and have better insight into our business. We could live without any of them, but it would mean slower iteration and less innovation.

Powers our app

Plivo – Powers the backend telephony behind Close.io. We chose them over others like Twilio because of their low level sip telephony support, as well as their commitment to call quality.

AWS (EC2, ELB, S3, CloudFront) – Let the big guys handle our server infrastructure. Best AWS decision we’ve made is to host out of Oregon instead of the east coast, since almost all of the significant downtime AWS has had in the last year has been in Virginia.

Heroku – Used to host our static Close.io homepage because there’s really no simpler way to get a Flask/Python app deployed.

Technical insight & debugging

New Relic – Great way to monitor app server performance and server health. Expensive but worth it.

Errorception – JavaScript error reporting. It’s not fancy, but JS error collection/reporting is an art and they know what’s up.

HockeyApp – Mac app crash reporting

User analytics & retention

Customer.io – Used for automatic drip marketing emails. By plugging in our Google SMTP credentials to send from, our marketing emails automatically get logged into Close.io so we can see all emails sent/received to our contacts.

Mixpanel – Used for user + event tracking within our app

Google Analytics – Used for overall traffic analysis

Tip: best decision here was to use Analytics.js which allows us to easily try out different analytics services with only a single line of code changed.

Development

GitHub – Best UI out there for code reviewing. Also heavily use GitHub Issues. Check out our open source contributions.

CircleCI – Upon every code push to GitHub, Circle automatically runs all our Python and JavaScript unit tests. If something fails, our engineering chat room is pinged. If tests pass in master, the latest code is automatically deployed to our production servers. Circle definitely beats running your own Jenkins CI server.

Communication

Campfire – Used for both internal team communication (and integrated with GitHub, New Relic, CircleCI, Close.io, etc.) as well as the “Live Help Chat” link from within our app where we provide technical support and get feedback from customers. While it’s been neglected, we like using the Propane app compared to the web client.

Olark – Used for “Live Help” on the Close.io homepage. Pops up in the team’s IM client when someone needs help.

Google Apps – Easiest way to get a team going with email, calendar, etc.

Money

Stripe – A modern API for credit card processing.

Integrations

Zapier – We can’t integrate Close.io with every possible service, so we’ve created a Close.io Zapier App that allows our customers (and ourselves) to integrate with other services across the web.

Sales (& Telephony)

Last but not least, we eat our own dogfood by using Close.io for our sales process of keeping track of all customers and prospect data, and calls / emails with them.

What’s Needed?

The section that I think is missing from other similar blog posts as this is “what’s missing?”. Here are some areas that I think need more startup effort.

• Better user analytics. Mixpanel (and others we’ve tried) are good for some simple analytics but just don’t allow us to easily answer many of the higher-level questions we’d like to answer about usage (“which users fit X usage patterns”, “how many people fit Y criteria over time”, etc.). The data could be there, but the backend intelligence isn’t. Improvements in this space could really help both the sales process as well as product development processes.
• Better web integrations. We’d love to plugin a service that helps us help our users get their existing data into Close.io from many of the existing services out there.
• Better financial software. Stripe is great, but it’s pretty low level. For anything slightly complicated you still have to build your own system of database+code to manage subscriptions and invoices. Perhaps a combination of an open source library + an accounting/reporting service is needed.
• A non-Google email/calendar solution. There seems to be a lack of great alternatives for startups.

Any other great services we should be using? Tweet us at @closeio

– Phil Freo (@philfreo)

We’ve been getting some great press and feedback since launching Close.io software for salespeople.

• 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.

At the end of a year I like looking back and seeing what I’ve accomplished and what new technologies I started working with in the year. Here’s a little summary.

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!

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.

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

[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:

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.