Seven members attended the New Hampshire Ruby / Rails group meeting held on 17-January-2011 at the New Hampshire Innovation Commercialization Center (NH-ICC). We had two presentations: Brian Turnbull talked about OmniAuth and Nick Plante showed a project he’s doing with Mirah on the Android platform.
Brian Turnbull is an engineer working for ARRIS and injects Ruby into his build tools whenever he gets the chance. A recent project required authentication against multiple providers and he did some research on OmniAuth. Brian presented a slideshow explaining the basic concepts of authentication and how they’re implemented in OmniAuth. Apparently, OmniAuth was the authentication method of choice during the most recent RailsRumble, used by most of the contestants. Brian outlined the process needed for working with an existing provider and demonstrated it with clear and simple code. He followed that up by showing how to build your own custom provider and authentication strategy. Brian’s sample code can be found on his github account.
Nick Plante has been working on an Android rich client app as part of a web-based social application that’s soon to launch. Nick told us that working on Java for Android has reinforced his love of Ruby. There’s not yet a good port of Ruby to the Android platform, but he has been impressed with the Mirah language, a hybrid solution that compiles to bytecode and runs natively on the JVM. He has developed a Ruby generator called protoform to construct the skeletons of a Mirah app. He gave us a tour of the components and built a simple “Hello, World” app, deployed and ran it on his Android VM.
Thanks to Brian for organizing the meeting and for the OmniAuth presentation, to Nick for talking about his Mirah project and to the NH-ICC for providing the fine facilities.
Tag Archives | rack
Notes from NH Ruby/Rails Group, 20-May-2008
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 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.