A frontend UI for the Spreedly Core API

Spreedly is one of my favorite companies because they’ve solved the problem of payment processor lock-in for my business. Their service is a very affordable, independent payment information “vault” — a secure, PCI-DSS compliant place to store customers’ data, and later charge it using whatever payment processor I want.

Spreedly is built for developers — it is a set of APIs that my software can communicate with to store payment information or tell Spreedly to do things with it, like charging some amount or deleting some information when a customer cancels their subscription. There’s no way to look at what’s been stored in an account other than writing code. That’s why I created Vault Viewer, a small PHP application that lets you look into your account and see, search and delete your stored payment gateways, payment methods and transactions.

Vault Viewer

The code is open source and free to use, and installation is typically just a matter of dropping the whole thing into a web server document root configured to serve PHP. There’s a Live Demo Here if you’d like to try before installing. I recommend only using the demo if your account only contains test data, as it’s not on an SSL-secured domain.

Download the code at GitHub

Date & Time Range Picker for Twitter Bootstrap

My date range picker component for Twitter Bootstrap has been updated with the much-requested ability to choose times as well. You could use it in an app to schedule meetings, choose flight departure/arrival times, etc.


The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: 50 pounds of pots rated an “A”, 40 pounds a “B”, and so on.

Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”.

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

It seems that while the “quantity” group was busily churning out piles of work-and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Art & Fear: Observations On the Perils (and Rewards) of Artmaking via Derek Sivers

What’s the shrewdest, smartest maneuver you’ve ever seen in business?

Unhappy Truckers and Other Algorithmic Problems

Parsing User Agents

For many, many years, Gary Keith maintained a set of files (“the files”) as part of the Browser Capabilities Project. These files contained thousands of entries mapping regular expressions to browser families, versions, platforms and capabilities, and these files were used by parsers written in a dozen languages to turn website visitors’ user-agent strings into structured data about their system. I’m truly thankful for the hard work Gary put in maintaining those files single-handedly for so many years.

At the end of 2012, after many months of warnings about his health and declining ability to run the project, it was closed with no new maintainer. Nobody’s stepped up to provide the same level of support he provided, and it’s no longer a reliable source of information about browsers and their capabilities.

If, like me, you need the ability to parse user agents for browser and platform information, I recommend the ua-parser project. It’s up-to-date, with a team of contributors, takes pull requests on github and provides libraries in 10 languages. It’s also much simpler to maintain, with only 1000 lines of YAML rather than 28,000 lines of INI files.

I’ll be using ua-parser as the basis of W3Counter’s browser and platform reports going forward.

Summer Workspace


Sunroom, wall-to-wall sliding windows, fold-up table. The Surface Pro comes with me when I go out for server emergencies..

A reader lives a thousand lives before he dies, said Jojen. The man who never reads lives only one.

— George R.R. Martin, A Dance With Dragons

What startups need to know about the “internet sales tax bill”

This week, there is a good possibility the Senate will pass the Marketplace Fairness Act, often called the “internet sales tax bill”. Here’s what this bill will do:

  • Online sellers will be required to collect, report and pay sales taxes in all of the states (once the states meet certain requirements), rather than only the states the seller has a physical presence in.
  • Each state that wants “remote sellers” to collect sales tax must establish a single entity to manage tax collection and audits for the entire state. Sellers won’t have to deal with all 5,900+ separate taxing municipalities in the country, just 50.
  • Each state must provide a database indicating the types of products and services taxed, and at what rates and with what boundaries. If this is implemented like previous “internet sales tax” proposals, that means the database should map 5- and 9-digit zip codes to tax rates for each category of product or service to be taxed.
  • Each state must provide free software for both the calculation of sales taxes due at the time a transaction is being completed, and software to prepare sales tax returns.
  • There is a “small seller exemption”. If you collect less than $1,000,000 a year from out-of-state customers (based on the previous year), you will have no new obligations under this bill.
  • Many startups are exempt from collecting sales tax in their home states as they only sell services rather than tangible goods. Even if you’re exempt in your home state, you may not be exempt in others. Several states charge sales tax on all services, others charge sales tax on certain categories of service, and any of them could change their taxable classifications as part of opting in to the new systems this bill creates.
  • It’s very likely states will be providing APIs for computing sales tax; the bill requires their software be able to provide a tax rate for a specific online transaction as it’s taking place.
  • These APIs will all have to follow the same rules for determining whose tax applies to a specific customer: based on the delivery address provided by the customer; if not provided, then based on the customer’s address; if not provided, then the address of the customer’s payment instrument; if not provided, then the tax will be based on the location of the seller.
  • The bill encourages a new type of business into existence: “certified software providers”. These new software businesses can become certified by each state in computing and filing sales tax using that state’s APIs.
  • The bill creates a benefit for businesses to use these new certified services rather than integrate with all 50 states on their own. A business will not be liable for errors in its tax returns if they were prepared by a certified provider. That means no penalties or fees for mistakes.
  • The providers in turn have no liability for errors in the taxes they calculate and returns they prepare if the errors are a result of inaccurate information from a seller (i.e. miscategorized products or services), or inaccurate information from a state (i.e. the state’s API returning the wrong rate).

There’s little else contained in this relatively straightforward bill. Should it pass, online sellers will eventually be collecting sales tax for most of their US customers.

Since integrating 50 different software packages into every online store, filing 50 different sales tax returns, cutting 50 checks, and getting audited by 50 states is not an appealing idea to most small businesses, they’re almost guaranteed to pay a certified software provider to handle it.