crossposting to SDRuby, some impressions from MerbCamp that I wrote up to share with OCRuby
(merbcamp was well worth spending a weekend on, our SDRuby crew did a great job putting this together - thanks especially to Patrick, Rob, Ryan, and Matt, as well as everyone else who volunteered or presented) ~ Deb ----- Begin forwarded message ----- From: Deb Lewis <[EMAIL PROTECTED]> Date: Thu, 23 Oct 2008 06:07:37 -0700 To: [EMAIL PROTECTED] Subject: [ocruby] MerbCamp report Reply-To: [EMAIL PROTECTED] On Wed, 22 Oct 2008 11:06:23 -0700, Scott Hodson wrote: > We will be having an OC Ruby meeting this Thursday night > ... We're hoping those of you that attended MerbCamp can come > and contribute some quick things you liked about MerbCamp. Regrets, I'm on the road this week and can't make the meeting tonight, so I'll have to contribute remotely through this email. Background: I've worked with Rails and Ruby for several years, but haven't actually used Merb. What I'd heard at RailsConf made me interested enough to spend the weekend at MerbCamp to get a better sense for what they're doing and why. So going in I was interested, but also somewhat skeptical about whether the world needs Yet Another Web Framework. (Or at any rate: experimentation and diversity is a fine thing, but given the constant churn of technology and the plethora of web stacks is this one worth my time?) I came away convinced that there are indeed some interesting things happening with Merb and that it will be useful to try working with it. There are some fundamental differences in point of view that lead to some different choices than Rails. * Modular architecture: merb has a strong focus on performance, memory, and modularity. Part of the modular design is an explicit commitment to define and support a public API, so that users and plugin developers know how to play nice. You can still break the rules and go into internals if you want/need to, using Ruby features of open classes and dynamic modification, but it's discouraged and at least now you know when you cross the line. In contrast, the focus in Rails is providing a complete stack with a point of view. While it's true that the decisions of the standard facilities in Rails work well for most people, it gets much messier when you want to do something different or make certain kinds of extensions. It's inevitable that when a software system isn't built from finer-grained components that the system becomes tangled with interdependencies - even the best-intentioned developers can degrade the structural integrity of the system when the boundaries between elements aren't clear. * MerbAuth: merb includes an extensible authentication framework. Thank you!!!! To my thinking, this was a really annoying barrier in rails. Almost anything I want to build needs authentication and authorization facilities and I'd prefer that the framework provide... a framework. Standardize on some protocol and conventions so every developer doesn't start from scratch and there's some hope for sharing solutions. The Rails community seems to have generally settled on the acts_as_authenticated/restful_authentication solution, but I find the characterization on the Rails wiki of this aspect of working with Rails both accurate and discouraging: "There are about over nine thousand ways to do authentication..." (http://wiki.rubyonrails.com/rails/pages/Authentication) * slices (reusable components): the merb folks have an approach for building reusable chunks of functionality that can be composed as parts of a larger application, with the ability to extend and override a merb-slice when used. This is a really compelling capability if it works well. Ok, so I'm a software architecture junkie and passionate about software structure that allows for component composition and extension. I really, really do not like the prevalence of generated code that seems to widely accepted by many Rails developers. Less code is good; I want to work by composing and extending, building customized modules as needed, not have to work with large quantities of boilerplate generated code that has to be understand and maintained. So MerbCamp was a weekend well-spent, I came away convinced that merb is interesting and worth exploring. And props to the SDRuby crew for putting together a really good event: Patrick, Rob, Ryan, and Matt, along with the merb developers and presenters who put together material for the sessions. ~ Deb --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
