DrupalCon Post-Mortem: Snapskit, our DrupalCon App

While at DrupalCon, Treehouse released a mobile application called Snapskit. The app was a social photography experience focused around DrupalCon and Chicago. Our goal was to provide a fun way for attendees visiting Chicago to explore DrupalCon exhibitor booths and sessions while taking in the sights of the city.

For Treehouse, it was an experiment in mobile development, non-Drupal technology, and lots of patience.

We used Appcelerator Titanium as the mobile framework, Ruby on Rails as the API, and MongoDB for data storage

While at DrupalCon, Treehouse released a mobile application called Snapskit. The app was a social photography experience focused around DrupalCon and Chicago. Our goal was to provide a fun way for attendees visiting Chicago to explore DrupalCon exhibitor booths and sessions while taking in the sights of the city. For Treehouse, it was an experiment in mobile development, non-Drupal technology, and lots of patience. We used Appcelerator Titanium as the mobile framework, Ruby on Rails as the API, and MongoDB for data storage

Why Rails?

As a premiere development agency, we are continually looking at new technologies. Experimentation, evaluation, and assessment of other technological strengths ultimately make us better Drupal developers. Days rarely go by when we aren't constantly coming up with play projects outside of client work to explore the vast technological ecosystem. Several of our engineers have explored Rails as a valid development platform and Snapskit seemed like a logical test. Since Titanium was going to handle the mobile user interface, Rails slotted in nicely for our API. When Drupal is bootstrapped, a lot of functionality is loaded that is not needed for an API whose primary purpose is to return JSON. Although its main job was to return JSON, we learned that Rails proved to be an entirely different development thought process than Drupal.

Active Record

There were many take aways from our Rails development experience, some of which that we are now using in Drupal. The standout, however, was but the Active Record concept. Active Record is the primary Object Relational Mapper (ORM) in Rails. The realization of this in Drupal was in a simple ORM (documentation) solution without our roots project. We also found a php implementation of active record in the PHP Active Project and are working on a D7 implementation.

Ruby Console

My favorite Rails concept was the Ruby console. Imagine having access to your entire code base via the command line. We all know and love Drush, but this full interactive experience showcases the viewing and manipulation of data. Just this week, Roger Lopez implemented phpsh for Drupal. PHPSH is an interactive shell for php created by Facebook. Here is a teaser: drupal command line At the moment, you will have to launch a custom index.php file that is within your Drupal root directory.

Autotest

The Test Driven Development (TDD) philosophy is really taken to heart in the Rails community. At Treehouse, we use the TDD process to ensure quality code. Admittedly, it is time consuming to run tests. In Rails, there is an autotest gem which runs tests automatically for files as they are updated. In this spirit, I created a wrapper around the run-test.sh script in Pressflow for Drupal 6 to monitor tests that need to be run. By checking for project updates, tests are queued to run via the command line. This code can be found in our Bit Bucket Repository. Learning and developing in other programming languages makes you a better developer. All you have to do is open your eyes to the goodness that is out there.

 

Neil Hastings