Merb Presentation at Austin on Rails

Last tuesday (it’s been a busy week) Ben and I gave a presentation on Merb to the Austin on Rails group.  I was kind of surprised that everyone had heard of Merb and most have played with it.  Overall I think it went pretty well. We gave a quick overview on the layout of Merb, then focused on what Merb “does right”: the cool features that don’t exist in any other Ruby web frameworks, and the clever implementation that make Merb really shine.  There were a few things we missed or could have explained better, so hopefully this will clear things up a bit more.

merb-action-args

merb-action-args is a gem that allows actions to add parameters to thier method signature, which are filled in with request parameters when the action is called.  This is accomplished by some clever use of the ParseTree gem.  When a controller is first loaded, merb-action-args uses ParseTree to extract the arity of each action, which is stored in the controller.  The _call_action method, who dispatches requests to actions, has been rewritten in merb-action-args.  Instead of a simple send to the action name, the actions argument list is constructed by matching the parameter names in the arity list to the parameter names in the request’s params hash.  Finally, send is called on the action name with the newly built argument list.  merb-action-args is an optional gem in merb-more.  It is not part of merb-core because it is dependent on the ParseTree gem.

run_later

The run_later method is a recent addition to merb-core.  It’s usefull for delaying the execution of code until after the response has been served.  For example, if you need to send a confirmation email, but you don’t want the response to wait for the smtp chatter, you can wrap the email code in a run_later block.  The run_later block is pushed onto a worker queue which is always executed after the request has finished.  Because the block is essentially a proc, it keeps the same context it was called in, allowing you to access controller variables if called from within a controller.  So run_later can used instead of BackgrounDRb in some circumstances.  However, if you have very long running or CPU intensive work, it’s probably best to stick with a BackgrounDRb type solution, because the mongrel instance is consumed durring the run_later work just like during a request. It will not prioritize new requests over run_later work.

thanks

Thanks again to Damon Clinkscales and the rest of the folks over at Austin on Rails.  We had an absolute blast. Though being the first time we presented, we seemed to have a good back and forth. Hopefully they’ll have us back soon to talk more about DataMapper.