Anyone who has followed my modest blog will be familiar with the various frameworks and databases I have tried using for singleforest.com. Well, I have finally come to a conclusion. A real conclusion this time. Since August 2010 I have been working with Rails 3 using SQLite3 as a database backend. For anyone on Hacker News that has met me in Chicago, this is the version I demoed on my iPad at the Publican.

I would like to review the frameworks and database previous iterations of singleforest.com used and why I am not using them today.

Frameworks

Rails 2

I originally started coding with rails 2. It was an easy decision to make since I had learned rails during my internship and I had continued to use it after the end of my internship. The first rails 3 beta was released early in my development process. I found rails 3 to be cleaner than earlier versions. The routing api was elegant instead of clunky. (Yes, specifying :controller and :action for every route is clunky even if you can scope them.) The addition of AREL to active record was also important once I started using sql databases, my current code base relies on it for automatic sorting and pagination. As a result I made several attempts to use rails 3 which resulted in enormous amount of pain. During the betas several key gems such as authlogic, formtastic, and various active record gems were either not compatible or buggy. I was forced back to rails 2 until rails 3 was out of beta. Once 3 was out of beta I switched back to it.

Django

I had given Django some thought initially. I had played around with Django before and found it to be at least as large of a framework as Rails. I went with rails because of ruby. I hadn’t used python for almost a year when I started singleforest.com and I was looking at the start of a new semester in a few weeks.

Pylons

During my fights over whether to use Rails 2 or Rails 3, I decided to give a python framework a try. I dismissed Django for the same reasons as before, it’s too large of a framework to learn quickly. I figured I would be up to relearning python since I had enough free time between classes. Turns out relearning python wasn’t the problem, the documentation on pylons was. At the time I was learning pylons, the available documentation on the internet was out of date and pydoc refused to build the documentation for the version I was using. The only decent tutorial I could find was a half finished book on the previous version. I quickly ran into issues with the book. A quick trip to irc revealed to me there was no authoritative documentation, no tutorials for the current version, and no one had any idea how to actually build a pylons project from scratch. I was told to download a sample application (the pylon’s project website) and modify that. Upon doing that I found out I now had three different version of pylons on my system and all of them hated each other. I also had issues with python’s tooling. (Pydoc, virtualenv, and multiple package managers) In the end I went back to rails because I didn’t have the patience or time to deal with a pylons.

Databases

CouchDB

What’s not to love about CouchDB? From a system administrative perspective it’s the most awesome database ever. It’s crash-only, you can back it up with rsync, and it scales like nuts. From a programming perspective it’s a little more work. You need to define every query you will ever do before you do it. It’s not as bad as you think. CouchDB has a development mode that will run any query you want without an index. Slow as hell but flexible, you just have to define the indexes before you deploy. I can live with that. Data is stored as json documents in a single silo. I can live with that. For an old version of my application it would work fine. I would have loved to use it.

Why didn’t I? I need joins in the future. CouchDB could work if I was willing to make trade offs on future design. I plan to add groups to singleforest. The queries I would need can’t run on couchdb without a lot of denormalization. Adding and removing users from groups and calculating activity on groups would be expensive and require cron jobs. Ironically, groups wouldn’t be able to scale on CouchDB.

MongoDB

I liked using mongodb but the tradeoffs make me uncomfortable from a system administration perspective. MongoDB plays fast and loose with data to get high speeds as a result, it requires two servers for data safety. I don’t currently have the resources to deploy two database servers. I did not feel comfortable trying to maintain a single server against strong recommendations not to. Later I found another reason not to use MongoDB: I need joins.

In Conclusion

Since rails 3 has matured it has been an absolute joy to work with. I do not regret having spent so much time switching between databases and frameworks. It’s given me a better appreciation for the tools I’m using now. Learning to model data in json has allowed me to model data better in sql. Fighting with python’s toolset has made me thankful for ruby version manager and bundler.

Project Update

Screenshots of the current version available on my deviantArt account.

I’ve been getting a lot of work done on singleforest.com. I’ve got a week left to add features before I start tracking down bugs and getting my server ready for an August 30th deployment.

Today I finished creating polls. I wasn’t going to have polls as a feature to start with but they where so easy to create I figured, why not? (Still took two days…)

This is what a poll looks like.

Nothing too fancy. It works though. One design note: I wanted people to be able to see what the current votes are before they decide what to vote.

Here’s what it looks like when you click vote!

The asterisk tells you what you voted on and the green bar below the main navigation tells you that your vote has been saved.

And for a bonus, you can optionally make polls that allow people to vote on multiple answers!

As you can see, there are two asterisks on this one. You also get a preview of fully functioning editable comments.

Here’s a bonus screen shot of that comment’s edits.

I’ve been very busy. :)

I was playing around with markdown and I discovered attempting to submit indented text breaks things rather nicely.

This is what indented text looks like when viewed.

With a black background you have no hope of reading the submission. Editing is even worse.

The text box for editing has completely disappeared… wait, there is a horizontal scrollbar!

Ah, there it is. That’s going to be a pain to edit.

I didn’t plan on breaking indented text this badly but it certainly works. I don’t want any user-submitted content to have indentation. I have a very specific reason for this. I want to present every submission in the same, readable format. If you want indented text, I would be happy to use css to properly indent it for you! I want the text on singleforest to be readable and consistent when submitted. Using markdown enforces some level of standardization. Restricting allowed html helps even more. (CSS may work in the preview but you ain’t getting colored fonts in your literature. Yeah, I remove the tag too.)