Blogs

The first MerbCamp went down in San Diego this past weekend and Nitobi joined the fray in force by sending four Ruby hackers and as an awesome sponsor.

Sprint!

Brock Whitten (aka sintaxi), Rob Ellis (aka silentrob), Joe Bowser (aka infil00p) and I (aka brianleroux) arrived in sunny San Diego on thursday evening. After a good nights sleep, we dispatched to the Merb Sprint to help the guys get Merb 1.0RC ready for prime time.

I’m not entirely sure I personally was much help; but we did uncover bugs and tested for new ones. First impression: the Merb core is a solid group of guys. They care about a quality release before anything else and a quality release is bug free and simple for anyone to get up and running quickly.

What I do know is that I learned a tonne. I was a real treat to pick up Merb from the guys who are authoring it. Not so much about Ruby, how to or anything. I learned about the motives and philosphy behind Merb. The Merb opinion, if you will.

In Merb’s opinion you should have an opinion of your own

Merb is the evolution of opinionated software popularized by Rails. While Merb does possess very strong opinions they remain weakly held. Its about optional opinion and future proofing technology. Sure, you can be up and running with a default Merb stack in couple of minutes (and build yourself a shitty blog in another three). If you don’t share an opinion about the choice of ORM, templating or JavaScript technology (or any aspect of Merb actually) it is easily customized, extracted or supplanted.

Opinion, practice and technology change. The variability of change is the only constant in technology development we can depend on. The flaw with the Ruby on Rails framework is that opinions do not scale. Choosing a technology or approach and prescribing to it wholly is choosing maintenance hell if not historical obscurity. Enabling software for change and evolution is future proofing it. This is not about convention over configuration. We can have convention, less configuration and options at the same time. Merb is on the path to achieving a Ruby web framework that does this.

The first key architectural choice in Merb is that absolutely everything is a gem. This enables some rather obvious benefits of package, dependency management and of course a unified distribution model. Merb is innovating here utilizing the concept of a meta-gem which is just an empty gem with dependencies for merb-core, merb-more, etc. I’m expecting this concept will influence future versions of RubyGems.

The second critical architectural choice is a supported Public API and event hooks for extending and integrating directly into Merb. Adding functionality via monkey patching is powerful and utilized extensively by Rails. However, monkey patching (and alias_method_chain) is a slippery slope that falls into the dark pit of unexpected consequences; It leads to mysterious behavior violating the principle of least surprise and, as an effect, collaborative extension and maintainability becomes increasingly difficult. Having a supported public api that the core development team is committed to maintaining enables extension and integration in a sane and maintainable way.

Read the code

Having absorbed all this. I promptly returned to our hotel and started pouring over Merb’s code. Well, I might have had a few beers first, but seriously: read that code. Merb’s codebase chooses clarity over cleverness. No fucked up metaprogramming backflip nijitsu (perhaps a little bit but its well documented: mime.rb for example). Well documented. Clearly organized. It is some of the very best Ruby code I’ve had the pleasure of looking through. I came to Merb largely at Brock’s encouragement and its internalized attention to performance. I’m staying for the readable code and philosophy.

The actual Camp

Others have done the blow by blow blogging and, I personally twittered the shit out of each session, so I’ll spare you the nitty gritty details of everything. On a higher level: this was one of the very best organized events I’ve attended. The wifi was strong but if that wasn’t enough the venue had drops for power and ethernet (and of course Joe had a lan cable) in every single seat. Each presentation was streamed live. IRC was packed. The lunches where great. The swag kicked ass (tshirt, flipflops AND a frisbee). The content of each session was meaty and everyone speaking was candid, open and genuine. Awesome? Yeah man. Awesome.

Thanks MerbCamp. We’ll see you next year.

At the Shebeen Room. Be there!

Keeping with the rich client times, I was having a quick look at the brand new JavaFX scripting language and came across some really interesting additions.

JavaFX is declarative and statically typed but from the examples feels very terse. It reads quite naturally. I like it.

Creating guis with swing for example:

Frame {
    content: Button {
        text: "Press Me"
        action: operation() {
            System.out.println("You pressed me");
        }
    }
    visible: true
}

Neat. Clean, and dare I say, easier to read than markup. I remember a really smart guy I know proposing a similar approach for declaritive user interfaces recently. Eh Dave? =)

It gets better, Arrays get some much needed love in the form of XPath and XQuery syntax additions. I love how this reads:

var nums = [1,2,3,4]; // just a regular array
insert 5 into nums; // yields [1,2,3,4,5] woah!
var numsGreaterThanTwo = nums[. > 2]; // yields [3, 4, 5]

Beautiful!

Great things happening for user experience focused developers with more options than ever before. Things are heating up with Flex, JavaFX and possibly Silverlight seeking to rule the next web. I’ll be sticking with Ajax for the time being but I’m really enjoying how this is all playing out. XPath and XQuery treatment for non xml structures, eh.. hmmm.