Should We Call It Mails, or Rurb? Yahuda Katz Clears Things Up At The LA Ruby Meetup

We just had a fun time at the latest LA Ruby Meetup, once again at UCLA. This time, we had presentations by James Foster from Gemstone, and Yehuda Katz from Engine Yard.

James Foster was showing MagLev, which is a Ruby VM based on top of the Gemstone Smalltalk VM. Not much to see here, just some Ruby code benchmarks running at about 4-5X faster than Ruby 1.8.6. That is, of course, not a very fair comparison, but no question that this is another Ruby VM to watch. His talk ended with the ever popular demo showing how Seaside does continuations, plus running the Smalltalk class browser right in the web browser and editing some code. Yes, this does kick serious butt, but it would be nice to see something new from the SmallTalk universe. I've seen all this from them two years ago, thanks to Avi Bryant.

The second presentation was where things got a lot more interesting. Yehuda Katz is well known to hard-core developers, thanks to his work on jQuery and Merb. He has also been very vocal about his differences of philosophy with the Rails way of doing things. Given the fairly recent announcement of the Merb project merging with the Ruby on Rails project, we all wanted to know, like, what's up?

As explanation, Yehuda gave a really complete history of Ruby on Rails. He showed slides of DHH's first Mac, he had dates and times of the first SVN commits for Rails. He explained the back story of what was going on in DHH's life while he was creating the first version of Rails. This was all ostensibly to justify that Ruby on Rails and Merb started with the same sort of motivations.

OK, great. That was fun. But what about the real dirt? He did not say anything directly, but my take on it was: when you really look at it, Merb was already turning into Rails++ so why not just merge all that effort into Rails itself? Putting too much emphasis into a separate framework also did not help sell services to the million Rails users out there, which is what Engine Yard's investors need them to be doing.

Yehuda was obviously comfortable with it, even thou he quipped about how many times he said "No!" when first presented with the concept of the great merge. But Merb seems to have the implementation, and Rails the sugar, plus the momentum, so your peanut butter is now in my chocolate. And the big winner? Has to be Rack, or the "Unix of web servers" as Yehuda called it.

Personally, I think it sounds great. Adding some API rigor to Rails will make it a lot more stable of platform for long-term development. And let us not forget that ezmobius has been contributing performance improvements back into Rails for a long time, so nothing shocking there. Just more good stuff for the Ruby web development community.

Merb On The Virge

Merb, the mighty challenger to the current Rails domination of the Ruby web framework conversation, races towards "getting very close to being stable api wise". That sounds like a 1.0 release to me!

Ezra says that the 0.9.1 developer release is ready to take thru its paces. One area where Merb really differs from Ruby on Rails is how Merb is based off of RubyGems. The refactored Merb architecture takes the Merb modularity to a massive 16 gems. You can really pick and choose what you want to include in your application.

Luckily for the very lazy, or the undecided, there is a Merb gem that will install everything for you. All you have to do is:

sudo gem install merb -y --source http://merbivore.com

And away you go! Unfortunately, "you should uninstall all of your old Merb gems before you install the new version" but that is not so bad. If you have been Merbing for while, you are not afraid to get your hands a little dirty. And if not, Merb 1.0 (dare I say it?) is right around the corner.

Beware Of The Merb

Apparently the Merb team was not yet satisfied with just having created a better Rails than Rails itself. Now, they are going after even more conceptual high ground, and creating an even more flexible web development paradigm that incorporates many of the great ideas percolating around the mongrel community.

According to Yahuda Katz, the next version of Merb will completely revise the existing Merb framework, in order to provide for many more ways to utilize it. He has an excellent writeup about what they are up to, and it sounds really cool.

The upcoming Merb 0.9 will break Merb into two parts: merb-core, and merb-more. merb-core will be a separate gem based on Rack, and as such will be able to plug into any web server like mongrel, evented_mogrel, thin, or even the venerable WebBrick. With this stripped down merb-core, you could create mini one file applications like those that you might been thinking of doing with Sinatra or Camping. Back to the Merb roots, if you will.

The other part of the new Merb, is the merb-more gem, which supports a more complete application structure like Rails or the current Merb. Combine this with a bunch of plugins, and the new Merb sounds to be an excellent way to really recombine elements to create an application.

I will be checking it out as soon as practical... stay tuned for more Merb.

And Here Comes The Money...

I read with great excitement that Engine Yard, my favorite of the Ruby-centric hosting companies, was taking in a round of $3.5 million from Benchmark Capital. I am a big fan of Ezra, and the rest of the crew, and the whole waiting list thing for getting a new slice setup has been a big inhibitor of their growth.

Funny, however, the press coverage has called EY a "Ruby on Rails hosting company". Yeah, sure, they are expert in RoR, no question. But the REAL stories there are Merb and Rubinius, and the press has not even caught a clue yet. Obviously Benchmark got it.

Congratulations, guys!

Sinatra, a Ruby web framework, and Why It Matters

As followers of this blog know, I am very interested in the Ruby language itself, not just web development. But it is undeniable that Ruby has become popular largely due to web development powered by Ruby on Rails. However amazing Rails is, however, it is not the final web framework to be developed in Ruby.

When Ari Lerner first told me of the Sinatra project, I was interested to see where he was going with it. Now that I have seen it, I totally get it, and I am more interested than ever. Let's compare it to Rails, Camping, and Merb, to better understand where Sinatra fits in, and why Ruby programmers should take a look at it.

Unlike Ruby on Rails, Sinatra is not a Model-View-Controller (MVC) based framework for creating websites. If you want helper functions that help you create forms, connect to databases, or any of the other myriad of functions that Rails provides, you will not find them. Instead, Sinatra is a very simple, yet powerful, Domain Specific Language (DSL) for defining RESTful HTTP actions, and then defining how the application is going to respond to them.

Rails requires a separate routes file to define how the web application is going to respond to requests, which hooks up to the appropriate controllers/models. Sinatra defines the simplest thing that could possibly work. When you declare a new "get" or "post" action, Sinatra will automatically add the route, and simply start responding to requests that match.

Here is a simple example of a Sinatra application:

require 'rubygems'
require 'sinatra'

get '/' do
   "Hello world"
end

As you can see, a Sinatra application's code is tiny, similar to Camping in that you can easily create an entire web application deployed as a single file. Unlike Camping, Sinatra does not have such a "crazy meta magic" feel to it... why's coding style is not for the faint of heart.

Like Merb, Sinatra is implemented as a Mongrel handler. Also, like Merb it is both thread-safe and has better performance than Rails. However, where Merb tries to be a "Rails-lite" for devs who are already familiar with Rails, but want a more bare-metal approach, Sinatra unabashedly takes an entirely different direction with its very minimal DSL-syntax.

Not to say that you cannot use ActiveRecord or whatever other Ruby gems you want to create your application. But unlike Rails, Sinatra's base core is incrediby minimal, and it puts the onus on the developer to decide what to include, instead of adding a bunch of things that may not be appropriate for the type of application that Sinatra would be good for.

So what would it be good for? API implmentations, quick minimal applications, and web development that does not want or need things that are included in Rails, like ActiveRecord. Control panel mini-applications, or perhaps widgets. I am looking forward to really getting into some fun with Sinatra... check back soon here for more.

Yesterday, the Ruby Inside blog mentioned Sinatra, and some of us have been digging it for the last few days. Take a look, and you will enjoy the appeal of a simplicity and elegance in development you haven't felt from Ruby for a long time... a very long time.

More Developer Fun In Los Angeles

Last night was the always entertaining Los Angeles Application Developer Meetup. L.A. is not known for the same massive quantity of developers as the bay area, for example, but having joined forces with the LA Ruby on Rails Meetup crew some time back, the monthly event is still growing.

This month's was held at the impressive new digs of YellowPages.com, who have been busy building out a huge Ruby on Rails based local search replacement for their venerable 100K+ lines of Java code. Thanks for the great sandwiches, boys... next time, buy beer!

Anyhow, four presentations took place on various fun topics of technical interest. First, Jeff Yamada and his associate (sorry I didn't catch your name) showed AIR. I then did a short presentation on Continuous Integration and CruiseControl.rb. Olmo Maldonado talked about his impressive JavaScript library MooTools, and then Ari Lerner showed his just-relased Ruby web development framework, Sinatra.

AIR
Long, long ago, I used to work with Flash and ActionScript. Most of us more "serious" programmers were always very frustrated with the language, the programming environment, pretty much everything except for the final product. Since then Adobe has introduced technologies like Flex and AIR to try to address the shortcomings of using Flash as a "real" development tool. Yamada and friend are the authors of the upcoming book "AIR Bible". AIR nee Apollo is designed to provide a way to create native OS applications, while using the toolset that Flash/Flex developers are used to. If you are into Flash/Flex already, then this is probably great for you, but I am not overly in love with so many angle brackets mixed in my code... let's just say that "it ain't Ruby". One small thing I will suggest to the boys: please try to find some relevant application to show for a demo a of a new technology. Between this, and what all of the Microsofties were show a few months back for Silverlight, no one is going to take this new desktop app paradigm seriously!

How To Get Your Code Together and Keep It That Way
Then I did a presentation myself, called "How To Get Your Code Together and Keep It That Way". It was really an exhortation to use the best practice of Continuous Integration, while showing how easy it is to get started with the ultra-cool CI tool CruiseControl.rb. If you are a Rails dev, and you are not using CruiseControl.rb yet, you should be. If you have a development project with greater than zero developers, it is worth it to setup a CI system, even just to keep yourself in check. You can get a copy of my presentation here. But don't just believe me, it is in yesterday's O'Reilly Radar too.

As I was demoing the CC.rb project page, where they are doing CI builds of both CruiseControl.rb itself and the Ruby on Rails project, I noticed that the Rails build has had failing unit tests since Oct. 3. What is up with that? Let's get on it boys!

MooTools
Next up was Olmo Maldonado, once of the authors of MooTools. MooTools is a JavaScript framework for web development along the lines of Prototype or jQuery. I had been hearing about MooTools, but hadn't really checked it out. Naturally, since both of those other JS frameworks already exist, and with Prototype really having dominated in the acceptance wars, MooTools does have a different approach on several levels to justify its existence.

Heavily optimized for speed, according to Maldonado, Moo performs much faster than either Prototype or jQuery on the slickspeed benchmark test at performing DOM selects, which is the core convenience provided by any JS framework.

Another difference is that MooTools libs are completely orthogonal. As such, the developer only needs to incorporate the specific libs that contain the functionality that is required for that application, unlike both Prototype and jQuery which require downloading the entire framework to use any part of it.

MooTools seems to have a more serious emphasis on good software devlopment practices than the othe JS framework projects. One example of this is that MooTools was developed using JSSpec, which is a Behavior Driven Development framework for JavaScript.

Already up to version 1.2, MooTools has been adopted in some very interesting places. The three demos that Maldonado showed were the iPhone version of the Pop-Cap game Bejeweled, the Ubuntu.com website, and then most curious of all, the Microsoft Expression website! What, M$ couldn't use Silverlight? Oh yeah, everyone already has Javascript... no additional download required. Whatever happened to that famous dogfooding?

MooTools is realy designed for the developer who wants to work in pure JavaScript. Most Rails devs like to use the Ruby on Rails Prototype helpers to do nice AJAX-y things like edit in-place and auto-complete functionality. MooTools does all that, plus has a bunch of UI gadgetry too, but having no inline functions, is not really compatible with the way the Rails helpers work. Perhaps someone will create a Rails plug-in that can collect up all of the MooTools Javascript, kida like what the Unobtrusive Javascript plugin does... for those Rails people who want to take advanatge of the DSL-like syntax, instead of dropping all the way into JavaScript.

Sinatra
Speaking of DSLs, the final presentation of the evening was by Ari Lerner, showing his incredibly cool new little Ruby web framework called Sinatra. In fact, I was so impressed by Sinatra, that I decided to give it its own posting. I suggest you go check it out right now!

Merb Is The Word

I have been playing around with Merb, which is a very cool project from Ezra Zygmuntowicz. Merb combines the Mongrel web server with a lightweight Ruby web framework. It has way less stuff in it than Rails, but is somewhat more than Camping.
Where this all started, was that I was looking for some way to use Mongrel to create a new REST web service for a client. This service has no UI, and basically just needs to front end a Ruby DSL that I have been working on. Another need was that I had to have something that can easily handle multithreading. Rails will block on a single thread, and also I do not need all of the Rails AJAXy goodness. So Rails seemed like a bit too much, and Camping not quite enough.
It was at this point that I discovered Merb. Merb handles threading very simply, by dispatching each new request to a new controller created on a new thread. It also has a very clean and simple support for rendering of HTML, JavaScript, and XML views. In my case, I only really cared about returning XML, so Merb seemed ideal for my needs on this project.
Starting a new Merb project requires some hand copying of files. There is a sample application included, which helps see some of what Merb can do, as well as showing how to setup your own project. At this point, Merb is very early in its lifecycle, so if you want to use it, prepare for a hands-on experience. The Merb code is very simple and clear, however, so it is not hard to see what is going on under the hood.
One of the main problems that Merb was designed to solve is better handling of long running server processes. One example of this is uploading files to your web server. Rails will block on each file upload until the upload is completed, which is a recipe for poor performance (read server unresponsive) if you will have a lot of requests to upload big files. The Merb sample app shows how to use Merb to deal with file uploads. And since Merb supports ActiveRecord, you could easily integrate a Rails app with a small Merb app or two to handle some performance bottlenecks.
Merb is much newer than Rails or Camping, but despite it not being even quite half-baked yet, the parts that are finished are delicious! Looks like it will be a really nice option for an alternative/adjunct to Rails. Now someone just needs to create a generator that lets you start a new Merb project...and some documentation/tutorials.