This post originated from an RSS feed registered with Ruby Buzz by Nathaniel Brown. Original Post: RubyCamp Notes - Rack, Merb, and Rubinius Feed Title: Nathaniel Brown Feed URL: http://feeds.feedburner.com/nshb Feed Description: Insight as a professional Technology Consltant and Photographer. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Nathaniel Brown Latest Posts From Nathaniel Brown

I managed to get to a few hours of the RubyCamp event here on Saturday and it was interesting to see the few talks I did.

Rack - ability to handle multi threaded image processing
Merb - multi threaded "rails", but better
Rubinium - the new "RVM", a Ruby Virtual Machine heading on track to run Rails in the next 6 months or so (totally random guess based on the feedback at the talk, but this sounds like a fair estimate).

Out of these three talks, the least interesting but maybe the most important was the Rubinium talk. Due to the infancy of the project, you really can't do much with it other than run Webrick and a few other things, but none of which has shown to prove any use to me at this time. When it does come to fruition, Rubinius promises to be faster than Ruby core, and with the inherent virtual machine interoperability, you will see some great reactionary products come out of this market space. Something to watch for, but not of immediate importance as of yet.

The Rack and Merb talks were quite interesting, but after about 5 minutes or so I found myself realizing the value, but really needing to dig in and basically implement a project or two to see the real results. Both of these new options in the Rails/Ruby space had a far greater impact on my future decisions towards project technologies than I expected. The results can be quite astounding.

Such is the case with Rack. The presenter went on to say that they setup the multi threaded environment only to find out that his server infrastructure basically came to a halt when they didn't have a throttle on the image processing that was going on. With the potential of having infinite threads now entirely feasible with what was demonstrated, you now can cause your server to come to an instant halt without care. So, plan for this.

Merb uses gems as plugins. That was one of the coolest features I heard of the framework. I don't like the fact that I can't immediately use my Rails plugins inside of Merb, but regardless - the reasons I plan to use Merb in the future, don't entirely include my existing codebase anyways. So not much of a concern there. I asked the presenter during his talk about a Rails Plugin to Merb Plugin conversion utility, but he knew of none yet in existence. Whether it's me or someone else, this is a likely development that will encourage wider adoption and faster transition to Merb in the future, unless of course Rails does what Merb did and fixes itself up to the new standard Merb has drawn.

All in all, a well spent 3 hours or so of my time. Learned a few tricks and can't wait to try them out on a near future project. Expect to see some new plugins based on these technologies in the future.