Wednesday, July 13, 2011

Sabbatical == Coding 10hrs/day == pure joy

After a nine year sprint, I decided to take a restful break from Tamale. What's more relaxing than building a new piece of software?  I'm a few weeks away from a preview release, but I'm having a dandy time building. I had forgotten the sheer pleasure of focusing on one idea for hours on end. The daily routine is pretty terrific - wake up with the kids, a family breakfast, and then I head to the public library. In addition to the free wifi, and the surprisingly robust internet speeds, the library is the perfect level of quiet but not boring. I can fit in plenty of quality people watching (mostly moms corralling kids, but there are a lot of retirees too) while my unit tests run. In the past, I relied on starbucks for working on these pet projects. But I have to suggest using your public library. Not only is it free, but I don't overdose on coffee and baked goods (though the library does have a keurig for $1/cup). Best of all, I can walk to the library from my house. I think this is key for productivity - leaving the kids and homelife at home for a few hours lets me really immerse myself in my project. Of course, I do walk home for lunch and sneak in some playtime with the kids, but again, the walk back and forth is a great way to mentally transition from play to work and back again. Likewise, walking home makes me leave all the coding problems at the library, so I can really enjoy my time at home.

If you are thinking of a web application, before you get started, here is one page you have to read. My friend and Tamale co-founder Nader started Kapost a year and half ago or thereabouts. He took the time to carefully document the best technologies he found during the setup of his new product development team. For my current project, I found his notes invaluable. My personal favorites are:

  • Heroku. After a decade of wrestling with deployment, I bow in awe of Heroku's git push deployment. Rails ain't too shabby either, but I think Heroku is a bigger deal than Rails itself.
  • MongoHQ. Despite the ribbing I'll receive for saying this, I'm a fan of mongodb, which is webscale. MongoHQ  does a great job with provisioning new instances on AWS.
  • AWS and RightScale. I've done hobby work on the google app engine, but this is the first time I've used amazon. In addition to the infrastructure I'm using that runs on top of AWS, (web application via heroku, and the mongodb instances via mongohq), I needed to run some custom python applications as well as a third-party windows application (I know, I know). RightScale makes the most sense if you want to run infrastructure on multiple clouds (e.g. Rackspace and AWS), which I am not doing. But, the organization of all your scripts and templates in RightScale is so nice I'm using it for a pure AWS deployment. My favorite concept from RightScale is the "roll forward" approach to deployment and the inherent versioning of all your system config and data. I also love Elastic Block Storage. It is amazingly useful to be able to move a hard drive between machines, or use it to hold state as you update a machine config.  

I actually wrote a slim version of my new application on google app engine. I was pretty happy with the experience, except that I wanted to be able to access the data store from a web application environment and a standalone application environment. GAE was excellent for the web app, putting aside whatever you think of django vs rails of course, but it wasn't possible to share the data storage with non-GAE applications. My biggest hesitation was learning Ruby and Rails. I was excited to be coding, and I feel pretty comfortable in python. However, I didn't know the first thing about Ruby or the Rails framework. Precursory searches left me thinking that I was missing out on something, but that it would be difficult to catch up with the RoR community. In my experience, it is much more effective to keep current on a technology from its inception, than it is to ramp up and stay current with a more mature ecosystem. Rails is roaring along, growing in many directions at once, so it is a bit of a bear to learn on your own. Luckily, I found a tremendous book - Ruby On Rails Tutorial. One thing about this book set it apart from every other technology tutorial I've read - the author urges you to read all the chapters, in order, and to really code as you read. I found it was the perfect way to catch up on RoR - the book explains how the major parts of the community work, what the current best practices are (e.g. he explains how to use github), and how to do more research. Best of all, I was able to use the tutorial as a baseline for my own application. By the final chapters of the book, he has you working out many to many and self-referential data models. Rather than implement the twitter clone that is the basis of the tutorial, I just mapped the ideas to my own problem. For seasoned developers, I think this is the ideal approach. You have example code and explanation of the concepts in the tutorial, and you can be productive and minimize the tedium by translating the examples to your own domain.


  1. Does MonogoDB sharde?

    You knew I was going to ask that. :)

  2. Anonymous11:55 AM

    I like the idea of Sabbatical coding at the library to give you a break from the routine!

    Regarding Mongo:

    From a high level, there are 2 usual reasons for scaling your mongodb replicat set:
    1) increase write capacity
    2) increase data stores (distribution)

    MongoDB typically suggests using replica sets over the older master/slave setup. MongoDB also supports auto sharding