Sociable
Sociable is a software development house based in Devonport, Auckland. We specialise in high quality Ruby on Rails and JavaScript development.
Contact us: +64-22-680-3869 or james@sociable.co.nz
Sociable is a software development house based in Devonport, Auckland. We specialise in high quality Ruby on Rails and JavaScript development.
Contact us: +64-22-680-3869 or james@sociable.co.nz
Delayed::Job comes out of the box with a startup script that relies on the daemons gem. to start and stop worker processes. Problem is, I’ve never actually had it work. After browsing around my options I decided to give daemonizer a go. The main advantage I saw to daemonizer is that you simply define a single “Daemonfile” in your project’s root (similar to a Gemfile or Rakefile) explaining how to set up each processes environment.
My Daemonfile looks like this:
The only minor problem I had was with daemonizer’s gem dependencies clashing with my apps. I have submitted a patch to make sure that daemonizer uses bundle if the project has a Gemfile present.
I love HAML. I love SASS. They’ve both saved me a heap of time writing view code in Rails, but what if you’re throwing together some static HTML and CSS to mock out an interface? This is where the Travis Tilley’s excellent file system state monitor gem comes in:
Boom!
If you’ve perused the source of any moderately complicated Rails application you are likely to have come across the Single Table Inheritance (STI) pattern. STI allows you to have polymorphic models all stored in the same table or collection. It may be best to give you an example:
As you can see from the example, we have three models, Meat, Bacon and ChunkyBacon all using the “meats” table for storage. This is really great, especially if there is common model logic (attributes, validations, life-cycle callbacks, etc) needed for all three models, and extra logic on the child models (imagine ChunkyBacon has a season).
Kimono makes extensive use of STI behaviour throughout it’s model graph, although built upon the Mongoid ORM. I kept running into problems where I needed to have routes for every new subclass I created and it didn’t really fit the way I wanted the application to work. The problem is not actually the router (a simple map.resources :meats) works perfectly, but with the route helpers. A call to url_for or link_to when passed in a model instance would throw an exception because there were no routes defined for Bacon or ChunkyBacon. I started with overriding the helpers (link_to, et al) but soon discovered this didn’t work well enough because the assumptions Rails makes about routing your models go deep. How deep? To ActionDispatch::Routing::PolymorphicRoutes as it turns out.
In order to create the behaviour I wanted I needed to add a reusable method to climb up a model’s superclass chain checking if the parent is a Mongoid document until it reaches the top of the inheritance tree, then I needed to patch “build_named_route_call” to use this instead of just using the class of the model being routed. Enter lib/kimono/routing.rb:
Once that’s done, I simply add an initialiser to patch in the behaviour I want:
Now when I call url_for(@bacon) I get “/meats/1” back. Thanks Ruby.
I’ve been busy over the last while switching a Rails 3 application over from ActiveRecord to Mongoid. In a lot of ways it has gone a lot less painfully than I expected, however one of the main problems I ran into was the common use of dynamic finders in controllers:
Mongoid (at the time of this writing) doesn’t officially support dynamic finders, so I have done one of my “minimum viable implementation” versions, available on Github. Please feel free to fork and send patches.
Teaser for Kimono welcome page.
“Ask me what is the greatest thing in the world, I will reply; It is people, it is people, it is people!”
