projects | github | twitter | rss | contact

full tilt boogie

posted to writings on apr 9th, 2008 with tags activerecord, corduroy, quickbooks, rails, ruby, superblock, and work

"we" have been working pretty hard lately on corduroy, a web-based billing system for small businesses. the live demo site is available showing off its features and functionality and the signup system will be ready shortly to start taking subscriptions.

i started writing corduroy years ago out of a personal need for a billing system for superblock. i tried quickbooks and hated it; all i wanted was a simple system for making professional-looking invoices and keeping tabs on my accounts. so, i quickly ditched quickbooks and started writing a web-based system in ruby on rails which i have been using ever since.

recently i decided to go public with corduroy and release it as a hosted service for other small businesses like mine, but there was quite a bit of work to do. here is a timeline showing the rate of commits:

2006 to january 2008 was me using the system for myself, making small changes along the way and adding small features as i needed them. the jump in march 2007 was the addition of customer login support so my customers could login and see their invoices. in early 2008 i added online payment of invoices and then decided to go all out and add multiple company support.

for rarely-taken actions like adding new transaction categories, i had always just created them through the backend. obviously that's not acceptable for customers, so proper interfaces had to be created for these kinds of things.

there was also the issue of multiple companies using the same database. the first change attempt involved adding private id fields to most of the tables and extending activerecord to work with them. each company would have its own set of private id's (instead of just using the auto incremented id's on each table) so that every customer could have customers and invoices with a public-looking id's of 1. while this is mostly just for aesthetics, it also prevents disclosure of private information like customer counts.

i soon scrapped this idea and went with a much simpler method: keeping every customer in his own database. i won't go into the details here of what it takes to make rails/activerecord do this, but it's not that complicated. this solution gives proper id's, speed, security, and an easy migration path when customers need to be partitioned into separate servers.

Comments? Contact me via Twitter or e-mail.