Notes from RubySIG, 20-May-2008

[Ted Roche]

Five members attended the May meeting of the New Hampshire Ruby / Rails
group, held as usual at the offices of RMC Research in Portsmouth.

Nick Plante entertained and educated the group on Rack, a foundation
layer that interfaces between the web application _handler_ (like
Mongrel or FastCGI) and the actual web application framework _adaptor_
(like merb or Camping or Halcyon or Sinatra) in a manner similar to the
Python WSGI layer. It allows for the creation of custom web frameworks
while removing a lot of the grunt work. Nick had a sample application
whipped up where a few lines of code could define the routing of various
requests and cleverly answered "Hello, World" to the correct RESTful query.

For those for whom Rails isn't the complete answer or those who want to
build their own web functions with components other than those used by
the Rails framework, Rack is a foundation on which you should be
plugging together your building blocks.

Brian Turnbull volunteered to fill in a bit for Scott Garman, who had to
cancel at the last minute. Brian had been using NetBeans only a brief
while, but had a great story to tell on using the built-in debugger to
trace out a problem with Rails-generated CSS meta tags always getting a
cache-breaking URL. While a feature in development, when the CSS was
being served from a caching store like Amazon's S3, the ever-changing
URL defeated the point of caching. Brian showed how breakpoints could be
applied to the code and step-by-step tracing (why is it that all
debuggers have Step-In, Step-Once, Step-Over, Step-Out icons that all
look the same and can't be told apart?) and walked from his code into
the Rails framework down to the mis-behaving component.

Having identified the problem, our discussion took a tangent into a
discussion about monkey-patching, and how this 'feature' was a bug
deserving of an optional switch to disable, and ought to be submitted
upstream to the Rails maintainers. To confirm, we went through the steps
to grab the latest version of rails as a plug-in (gem? I'm not sure.) so
that we were working with the latest 'edge' code to confirm the problem
hadn't already been fixed. By installing this way, we were overriding
the Rails framework only for this application, and could easily revert
to the stable version, without disturbing the main shared code on the
machine. We talked about how this was a Best Practice when bringing an
app under development up to production, so it was isolated from changes
outside of the app's control.

Plenty of time was available for discussion, and we talked with Tim a
bit about configuring a new machine with all the tools he'd need to
develop a Rails app with NetBeans: Ruby, Rails, a couple good gems, the
Java runtime. Nick and Brian noted that the default Rails environment
within NetBeans is JRuby not MRI (Matz' Ruby Interpreter)  and how you
might want to reconfigure NetBeans to use MRI instead if you weren't
planning on deploying to a JRuby environment.

Thanks to Nick and Brian for their presentations, to Scott for arranging
the meeting, to Tim and RMC for providing the great facilities and to
all for attending the meetings.

Discussion is ongoing now on the topics for the June meeting; join the
mailing lists at http://mail.nhruby.org/mailman/listinfo/ and keep an
eye on the new meeting plans at
http://wiki.nhruby.org/index.php/Upcoming_meetings.

-- 

Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com