by Jason Gilman

I just attended the Ruby Nation conference last weekend. It was the first time I had gone to this particular conference and it ranks up there with some of the best conferences I’ve attended. It was two days on Friday and Saturday and had two different rooms available for sessions. I measure the success of a conference by how I feel afterward. How many new technologies or techniques have I heard about that I need to go research? How excited do I feel about getting back to work and putting these new things into use? I had a ton of new things to think about and research. I was pumped to put these into use after Ruby Nation.

One of the things I heard about in Peter Bell’s session “Lean Startups With Ruby and Rails” was ThoughtWork’s Technology Radar. ThoughtWorks is a well known consulting company that employs many highly regarded individuals.  Their Technology Radar covers the topics and trends in technology that they think others should be paying attention to.  It’s only about 6 pages long but I highly recommend it.  Almost every paragraph contains some topic or technology trend that’s worthwhile investigating.  I’m stealing their format to touch on things that I think we should focus on.


TorqueBox is a “Ruby Application Platform” built on the JBoss application server. It uses JRuby to run your Ruby applications. There was a presentation on the TorqueBox application server that detailed converting a typical rails app with background jobs and caching to use TorqueBox.  I’ve been doing some research on TorqueBox and I’m really impressed.  One of the projects I work on that runs on JRuby has been using a home rolled solution with Tomcat. It has a lot of features that would solve pain points both operationally and in development.  Most of its great features are due to JBoss AS and its ability to cluster. Here’s a quick list of features that stood out

  • Caching is built in and is shared across clustered instances of TorqueBox using JBoss’s Infinispan technology.
  • Deploy, redeploy, undeploy applications without restarting TorqueBox. This is big for us because our custom Tomcat solution requires restarting Tomcat on every deploy. That takes 10 minutes in some cases to do a quick redeploy with a bug fix.
  • Backgroundable tasks and services that get distributed across the cluster
  • Includes HA Singleton Services: This is a single instance of a service always running in the cluster even if you shutdown a node it’s running on.
  • Lots of rake tasks and capistrano support for deployments
  • WebSockets support – An HTML5 technology that allows an open TCP/IP socket between browser and server for realtime clients.  It’s not possible to build this sort of thing in Rack or Rails. This would require an instance of something like EventMachine.
  • Easy configuration as a startup process so TorqueBox starts when the machine boots
  • Apache mod_cluster plugin that makes it an “intelligent” load balancer
  • Lots of documentation

The documentation is an important aspect for me. Trinidad looks like the next best option after TorqueBox for JRuby deployments but it’s a little lean in the documentation. The one downside/limitation I could find of TorqueBox was that it requires all of your applications deployed to be on a single JRuby version.  Right now we have the flexibility to have applications on multiple versions of JRuby but I’m not sure this is a big downside.  We should keep our tool versions consistent. We wouldn’t deploy applications on different versions of Java for example.

Test at the Appropriate Level

ThoughtWorks’ Technology Radar deserves credit for pointing me to this issue. There’s one particular application that has been a pain to keep our cucumber test suite running and passing. ThoughtWorks advises to test at the “appropriate level”. After Googling I found two blog posts with more details. Reading these is like having an intervention for overuse of Cucumber Rails integration tests.  Cucumber is great but we’ve had a lot of issues with the capybara and celerity gems that we use as page drivers.  The tests take forever, they break and it’s hard to figure out what’s wrong.  Don’t get me wrong. I love the ability that Cucumber provides for fully testing our application stack. We need to be fully testing our applications but we need to choose the appropriate level of testing. We’ve been inverting the testing pyramid and putting too much emphasis on integration testing. Our JavaScript unit tests are somewhat light. Beefing up on the JS testing might provide better coverage and find bugs without some of the pains of integration tests.

Page Object Gem

One gem that’s new to me is the page-object gem. You create a class per page in your application. The page then encapsulates all access to elements within the page.  This makes your cucumber steps less brittle to changes and more readable.

Mountable Rails Engines

Mountable Rails Engines allow you to essentially put Rails applications inside of another Rails application. You can take assets, views, controllers, models, database migrations, and anything else you can think of in a normal rails application and put that in a gem.  The gem is then ‘mounted’ inside the hosting application at a specific path. Some examples of this are the Devise gem, Spree, and RailsAdmin. I’ve been looking for something like this for a while that would let us break up a large application.  Rails Engines is EXACTLY what I’ve been looking for.