Wednesday, May 28, 2008

A Day With Heroku: Building a Simple Color Crowdsourcing App

I recently signed up for the Heroku private beta and decided to build a simple application to test out this free Ruby on Rails Hosting solution.

Firstly, Heroku is an awesome idea and very well executed from what I can tell. The service is perfect for prototyping webapp ideas. I only used the minimal feature set, so I cant comment regarding the more advanced (premium) features (domain names, no ad banner?, scaling). I will continue to use it to prototype ideas for web applications even if/when there is a small fee after the end of the private beta. I hope the guys go the freemium route as they will be a powerful force and rails-centric alternative to Google's App Engine.

From a technical perspective I'd like to know a little more about what automation occurs under the covers, like session cleanup, database/environment versions, etc. If this information is already available it wasn't obvious to me during development.

I chose to hack together a simple rails application called Pigment to try out the in-browser development interface (I went with the American spelling on the site: 'color'). The idea for the application is to crowdsource the mapping for color names to their decimal values and provide services to exploit this information in aggregate, specifically: names-to-numbers and numbers-to-names. It was was inspired by and elaborated on the Mechanical Turk driven Dolores Labs Color Survey. The application is raw, simple, and took me about a day (mostly cowboy-style generate and test UI iterations). Natural extensions include probabilist name/number assignment, cool visualisations of the data, and an API (REST-friendly). Try it out at pigment.heroku.com

Anyway, the development interface is pretty slick, and it generally did all the things I wanted to do in terms of script execution and source file manipulation. I loved the simplicity of the editor - it would be very tempting to overload the interface with a suite of developer-friendly features, an option the guys have thankfully resisted.

I quickly got over the difference in response-speed with the online editor, and started to enjoy the idea of in-browser development. The site is awesome, and as a user I'm sold, but I did have some problems, and in my usual style I documented them as I experienced them:

  • Crashes: I'm using Firefox (2.0.0.14), and I experienced five crashes over the course of the day's work. I am unsure of the underlying cause, although I think it is related to rapid context switching between applications on my desktop and the influence this has with initialising/sleeping the Heroku development environment (AJAX in rails would be my first guess). The first crash occurred whilst flipping between tabs (code/view) to see changes, other crashes occurred while flicking between Firefox instances, and the last couple occurred whilst flicking between IE and Firefox. A "crash" involved 100% CPU utilisation, and required me to kill the process. Some crashes also seemed to correlate with changes to the routes and (I presume) subsequent automatic restarts to the mongrel instance.
  • Editor is Sometimes Screwy: Lots of control-c/v/x/z/etc caused me problems. The evens would occur at random places in the code, or random stuff would happen - like large slabs of code disappearing. Not sure if it was a focus thing or a speed of commands thing. The biggest offender was the command not occurring at the location I wanted - such as not picking up my mouse clicks and repeated re-clicks to code locations. I typically resorted to moving with arrows and retyping code.
  • Lost file: As mentioned, sometimes a control-x or control-v would do crazy stuff. Sometimes I would loose a lot of code or even the entire file (thank god for control-z). Anyway, onetime I switched to my other browser and the view was blank. Checking back in the editor showed my view file (50 or so lines of html/rails code) gone. More messing around, and the file no longer showed in the file tree. Logging out, then back in re-showed the file, but empty. I had to retype the lot - I was pissed, but wrote it off as my fault in doing a control-v control-s without looking at the editor before the context switch. I mention it because of the pain it caused, and because my assumption may have been wrong, and some other bug caused the data loss.
  • Indenting and Formatting: I like clean looking code. Selecting slabs of code should indent and inverse-indent when I tab/inverse-tab. Instead, they are deleted (again, thank god for control-z). I want a control-shift-f format command or a format code button, or at the very least tab-handing on selected code.
  • Syntax Error: The code editor has syntax error checking functionality. Nice. I noticed with some of my views and models with regex validation, the syntax error notification would stay on even though my code was valid syntactically. I only want to know when my code is wrong, which typically involves bad calls or names (hard to check in ruby) rather than a missing brace or something.
  • Javascript Error: Using IE6 for a view-checker (independent for the crashing problem) highlighted a persistent javascript error with the Heroku banner. The result was an indication to the user on the browser, and the lack of the Heroku banner being displayed. I can understand the user needs a bleeding-edge browser to use the development center, but to view my page (the Heroku ad) the user should be able to hit it anything, including an antiquated Microsoft browser.
Some additional features I would like include:
  • Preview Mode: The current preview mechanism is modal, meaning I loose my code view, and any current organisations of the directory tree (a pain!). When I develop for the web, I iterate the view A LOT. As such I need both code and preview mode active at the same time. I resorted to making my application public (too early) and using two tabs, then instances, then browsers. The solution could be a pop-up option, and must be light and fast (not know about my Heroku status). I'm thinking something light like a post preview in a blog or forum.
  • Recently Changed: I want a list of recently changed files or "open" files. I flick between model/view/controller when adding functionality, and I want to flick between these contexts faster if I worked on them recently. Like control-tab functionality. A "recent document" list would be a big improvement!
  • Query Tester: The data view for the database is nice and simple, but I longed for a query tester. I had to mess around with an inner query and a fussy 'like' query (ruby was being a bitch) and this feature would have saved a lot of screwing around with trial and error queries in the view. (I could have used a test if i thought about it a little harder)
Again, Heroku is awesome, all love and praise!

As I mentioned, the service is in private beta, and so will naturally iterate features, changing a lot between now and being open to the wild web. If I were learning rails or wanted a free (for now) platform for prototyping and small apps, I couldn't advocate Heroku enough.

1 comments:

friarminor said...

Hello, Jason!

There's so much good stuff going with Ruby on Rails (notwithstanding the Twitter issues) that there's hardly time for startups to present their solutions much like Heroku.

Anyway, you might also want to check out mor.ph and test how their rails deployment measures up with your standards.

Best.
alain