Chris brings nearly 10 years of experience in a variety of aspects of user-centric design and interactive development, with specific areas of focus in e-learning and Rich Internet Application (RIA) design and development.

Both Matt and I have worked alongside Chris in the past, during consulting engagements at Molecular as well as a variety of side projects over the years. We’re thrilled to have Chris a partner as Cantina continues to grow.

Feel free to read Chris’ bio in the About section.

Of particular interest to me was the ability to spawn (fork) worker threads from user actions, or in this case, ActiveRecord callbacks which were called when the user action caused my model object to be saved. The basic order of operations is this:

1. User uploads an audio file
2. Uploaded file data is loaded into an attachment_fu model object
3. Model object is saved
4. Model object’s after_save callback is called
5. The after_save callback determines whether the uploaded file requires encoding, and spawns a BackgrounDRb worker process if it does

In this process lay many issues. I’ve attempted to describe some of them below.

Close your connections

This may be obvious to many, but I figured with all that ActiveRecord does for you, that if I do some work with ActiveRecord in a BackgrounDRB worker process, my database connections would be closed automatically. This was not the case, however it can be quickly remedied by adding the following after all your code is done doing what it needs to do:

ActiveRecord::Base.connection.disconnect!

Don’t try to pass entire ActiveRecord objects to workers from Rails

I started building a simple call to spawn a new BackgrounDRb worker from an ActiveRecord lifecycle callback method (see below), and starting running into errors like these:

undefined method `[]‘ for #<DRb::DRbUnknown:0×2501bd4>

I found a number of postings online indicating that simply adding the following to my model objects would clear this up:

include DRbUndumped

Doing so did not fix my undefined method problems, so when I came across this on another blog, I decided to cut my losses and just pass the database ID.

When passing arguments from Rails to BackgrounDRb workers, don’t pass huge ActiveRecord objects. Its asking for trouble. You can easily circumvent the situation by passing id of AR objects.

From: BackgrounDRb best practises

One thing that I didn’t think I’d be dealing with in coming to Rails from a Java background is serialization issues, but there we have it.

Don’t create new workers from new record callbacks

This may have been common knowledge, but I had to discover this the hard way. The after_save callback in ActiveRecord model objects is called before the save transaction has been committed. The implication this has is that if I pass an ID of an ActiveRecord object to BackgrounDRb for further processing, strange things can happen.

In the case of my after_save callback being called on a newly created object, I found that most of the time, by the time the BackrounDRb process starts working and tries to retrieve the object using the ID I have passed, my original object.save() transaction has not yet committed, so I get errors indicating the record could not be found, even though I check the database no more than a second later and the record is there and intact.
It seems that I’m not the only one that was looking for a post-commit callback:

• Proper cache expiry with after_commit
• A good thing to know: after_save sits inside the transaction

The Grails release in particular is significant as the framework has finally emerged from "in development" status which removes one more barrier for web project teams and IT departments to using the framework.  We’ve had success with the Grails framework particularly due to the fact that it sits very well in the Java enterprise ecosystem, including the relatively straightforward integration of existing Java-based Hibernate models.  This integration with Hibernate, which is a key factor in Grails’ ability to be a contender for new IT projects with teams that are Java EE and Spring/Hibernate-oriented, is a fairly straightorward process that involves dropping in your existing mapping XML and Java POJOs.  As if by some magic, you get all the benefits of GORM on your existing Java POJO data model, including dynamic search methods and the criteria builder DSL.

• Groovy on Grails 1.0: http://grails.org/1.0+Release+Notes
• Groovy/Grails Zone on DZone: http://groovy.dzone.com/
• Ruby on Rails 2.0: http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

• EC2 instances are very quick to setup
• They are not charged for data transfer to S3
• They are presumably the closest you can be to your S3 storage in terms of network latency

Setting up our initial EC2 instance was incredibly easy.  There’s a wealth of pre-built Amazon Machine Images, or AMIs, out there with various configurations for different application servers, including Apache, MySQL, JBoss, Tomcat, and, our new favourite, Red5.  I was able to get one up and running fairly quickly with the packages I needed (I love yum). 

Actually, I was floored by how fast I had a brand new server up and running, considering I’ve had requests submitted to fairly large enterprise grade hosting companies for such intensely complicated things as, say opening a new port in the firewall, take over a week.  I guess the landscape is changing, but I digress…

In order to use Amazon S3 as the backing store for our new EC2 instance, we seemed to have a few options:

1. Code our application to manage the transfer and synchronization of files to S3, perhaps via our Amazon S3 Grails Plugin
2. Utilize an S3-aware file synchronization tool such as the jets3t Synchronize tool, or the Ruby s3sync tool
3. Mount S3 as a filesystem in the EC2 instance

Since we’ve already been doing #1, and #2 isn’t exactly real-time, we decided to give #3 a go.  To do so, we enlisted the help of a couple of tools:

• JungleDisk: A multi-platform tool that provides a local WebDAV interface to S3, suitable for mounting as a filesystem from the Mac OS X Finder, or from Linux using…
• davfs2: Linux filesystem driver that will mount a WebDAV URL to a mount point in the local filesystem

JungleDisk is a great tool in general for interacting with an S3 account, and I’ve been using it for a little while now for my own backup purposes on my Mac development laptop.  The Linux version provides a standalone command line program (in addition to the GUI that comes on all platforms) which can be run as a daemon and scripted to startup on boot. 

The setup was surprisingly simple.  To get JungleDisk running from the command line client, you need to provide a configuration file, commonly called jungledisk-settings.ini.  The documentation says that you should run the GUI first to generate the file before running the command line version, but I was able to copy over the file from my Mac laptop and update the values for the EC2 instance.  Here’s an example of the configuration file:

LoginUsername=
LoginPassword=PROTECTED:
AccessKeyID=XXXXXXXXXXXXXXXXXXXXX
SecretKey=PROTECTED:XXXXXXXXXXXXXXXXXXXXX
Bucket=default
CacheDirectory=/var/cache/jungledisk
ListenPort=2667
CacheCheckInterval=120
AsyncOperations=1
Encrypt=0
ProxyServer=
EncryptionKey=PROTECTED:
DecryptionKeys=PROTECTED:
MaxCacheSize=1000
MapDrive=
UseSSL=0
RetryCount=3
FastCopy=1
WebAccess=0
LogDuration=30
ArchiveFlag=5
ArchiveDuration=60
PasswordPrompt=0

I setup jungledisk to startup on boot using a really handy /etc/init.d script from the JungleDisk forums found here.

Once JungleDisk was configured and running, I had a local WebDAV server running at http://localhost:2667.  This could be used in the KDE to browse the filesystem, but since I’d like my web application to be able to access it via the filesystem, the next step was to get davfs2 running.

The EC2 instance did not have davfs2 installed by default (at least not the AMI I chose, which was based on the default AMI), so I simply downloaded the source distribution and compiled locally on the EC2 instance.  The base AMI I was using did not have gcc or the neon development libraries (Neon is a WebDAV library that davfs2 uses for communicating with WebDAV servers).  Luckily yum was installed on the EC2 instance so getting these dependencies was pretty straightforward.

davfs2 can be configured to run by non-root users, or by root.  The configuration of davfs2 depends on your choice here as some configuration options are intended only for system wide davfs2 configuration started from root.  I opted to take this approach, setup my /usr/local/etc/davfs2.conf file with the following configuration options:

dav_user        mydavuser
dav_group       mydavgroup
kernel_fs       fuse
ask_auth        0

Since JungleDisk provides WebDAV access to localhost only, and does not require authentication, setting ask_auth to 0 is useful to prevent davfs2 from prompting for a password when mounting the WebDAV URL.  Last but not least, I added an entry to /etc/fstab to configure the mount:

http://localhost:2667 /mountpoint davfs nolocks,noaskauth,rw

Voila!  Now my S3 instance is mounted to the local Linux filesystem on my EC2 instance.  I have not done any performance testing or cache tuning, but this article over at Right Scale looks promising.  Once we have our application and up and running, I’ll post back with some more information on how this configuration is working.

You can check get the latest and greatest, as always, at grails.org.

In short, we wanted to build something that would manage static file assets such as images, movies, audio, Flash, and perhaps down the road, site backups, on the Amazon Simple Storage Service (S3). 

This is a very preliminary version of the plugin, and we’re hoping to get some good feedback from the Grails Community and you on what we can do better.  However, there may be some bugs that we haven’t quite gotten to yet. 

Feel free to leave comments regarding the plugin on this posting.  We know we have a lot more testing to do and features to add, so any feedback is most welcome.

We’ve used Java here at Cantina on innumerable projects with a great deal of success. The toolset is very complete and Spring and Hibernate have been a godsend for allowing us to focus on the intellectual "meat" of a project. Then, in an effort to explore some new technology for a couple prototypes we were working on we found Grails.

I think the first thing that drew us (me) to Grails was the mantra that I heard over and over again at a talk given by Venkat Subramaniam at Sun a while ago regarding Groovy on Grails have more "signal to noise". Less syntactical noise, more code signal (i.e., the "meat"). In his talk he threw together an AJAX enabled form in about 10-15 minutes with all the CRUD and validation you need.

Once we started using Grails in house, it quickly became apparent how deep the mantra of having a greater "signal to noise" went. We love Spring and Hibernate but we hate XML configuration. Yes, XML is ubiquitous, very readable, and supported everywhere, but, as technologies like Spring and Hibernate put more of our application structure into XML, it makes it very hard to debug all of our application when some of the structure sits in very static XML.

Grails provides a great approach to this. Through the Grails BeanBuilder, you specify all of that lovely Spring configuration within a very readable and debuggable Groovy syntax. This makes for a much more powerful way to configure the structure of your application as well as allows you to actually step through parts of your configuration with a debugger.

Of course, Grails does a whole lot more than that (including a lot of the auto-wiring in Spring so that you don’t have to do any configuration), and here are just some of the things that caught our eye:

• GORM (Grails Object Relational Mapper): as if Hibernate wasn’t powerful enough, Grails adds some useful methods of querying and mapping your object model that go above and beyond Hibernate. With dynamic methods, you can query against properties of your object model classes (domain classes) via methods that you never have to write, like this:
  
  // Assuming you have a domain class called "Person"
  // with a name property and a type property that
  // can be "employee" or "customer"  

  def allPeople = Person.findAll() 
  def onlyEmployees = Person.findByType("employee") 
  def howManyEmployees = Person.countByType("employee")

  I didn’t have to write any of these find* or count* methods, they come free of charge with GORM which makes the simple queries a lot easier to manage.

• Auto-reloading: one thing that has always plagued us as Java developers is the development cycle of fix -> deploy -> start -> test. There are certainly ways to reduce this cycle in Java, but sometimes the project just doesn’t allow for it. Grails is built with the mindset that changes to most code assets should be reflected instantly in the running application, thus reducing the time it takes to test code changes
• TagLibs: Creating GSP (analogous to JSP) tag libraries requires much less code and no configuration to get your tags and and running
• Intellij IDEA Integration: I love TextMate as much as the next guy, but code completion and debugging are things I’ve just gotten too used to (call me lazy). The Groovy/Grails plugin for Intellij IDEA has come a long way towards making Grails a first class IDE citizen.
• Legacy Integration: A lot of the projects we work on involves an existing Java application and SQL database. There is often business logic already implemented in Java classes (Spring or otherwise) that really don’t need to be rewritten. Since, at the end of the day, Grails is Java, we can make use of the existing codebase in a way that is much more seamless than if we were to introduce another web technology. Also, the fact that it’s all Hibernate under the hood makes it easier to adapt a set of domain classes to an existing database schema. This makes Grails an easier sell on those technical re-architecture projects in the Java world.

Beyond the technology, there’s just a lot of momentum in the Grails community. Within the last year that I’ve been watching, Grails has gone from a 0.4 to just about 1.0 (I’ve been using PHP frameworks that haven’t bumped the minor version number in over 2 years). There’s a healthy and growing list of plugins (grails.org/Plugins) that seem to be addressing the core needs of new application development.  We’re really looking forward to the next Grails project and experiencing a lot more signal and a lot less noise.

First things are always first, and in the spirit of blogging as a new form of journalism (not http://en.wikipedia.org/wiki/New_Journalism) let’s get the main questions that any reporter would ask out of the way:

Who

We’re a new boutique internet technology shop specializing in whatever it takes to effectively produce web things (see About section).

What

What do we do? Well, sometimes it involes banging our heads against the wall, but at the end of the day we make great web sites and applications using best of breed practices and technologies (yes, you can read Web 2.0 in there).

When

We’ve been doing this for over 15+ years combined, but the blog starts today.

Why

We often ask ourselves that same question, but in the end, we love what we do!

How

Using some of these: agile methodologies, iterative design and development, rapid development frameworks and lots of testing.

In the process of doing what we do, we end up figuring some things out, and as part of the open source credo of “share what you know” (which sometimes comes in the form of “patch it if it’s broken”), we decided to start blogging about our little victories against buggy code. We hope that you find at least something that we’ve written here useful, and who knows, maybe someday we can do business together.