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!

The R/evolution Will Not Be On Television

The medium of video is better than ever, thanks to YouTube. Video content is a lot improved by splitting video into smaller pieces, making the videos searchable, and most importantly, allowing for self-publishing. Helping for niche content authors to get their message out, has as a natural effect, a large proportion of idiocratic nonsense, but there are gems buried in the muck.

Nothing to me is more emblematic of this, than the brilliant videos put together by Michael Wesch of Kansas State University. His latest work Information R/evolution continues the themes in his famous Web 2.0 - The Machine Is Us/ing Us video, which you must have seen by now. The real genius of Wesch's videos, is not just that they explore such interesting ideas, but that they break complex concepts down into very easily digested pieces, while also being fun to watch.

R/evolution expands on ideas about decentralized organization of information. For example, groups of people tagging videos, or digging a new blog post. What this does is allow us to look/find information in more than one way. This is quite different than the top-down categorization typical in physical systems like file cabinets, and just as they are quite necessary there, they get in the way in the virtual information space. Information stored electronically, instead of on paper, allows us to look at that information in a whole different way, but Wesch points out how we constantly tend to confine our views based on the preconceived notions built up in a physical world.

As it just so happens. Gord Hotchkiss has an interesting new posting about some of the implications of these ideas. Hotchkiss's premise is that we are evolving in the ways that we actually perceive information, due to the changes in how we access it.

I have been seeing this lately firsthand in my son's use of his web browser. He was recently unconvinced by my explanation about why he might want to type a web address into the address bar, instead of just typing it into Google and clicking on the first link, as he has taught himself to do...

Is Your Database Getting Tired?

Is your database getting old and tired? Mike Stonebraker thinks so. Stonebraker is a database guru and long-time researcher, and when I say database guru I mean one of the founders of Ingres, and former CTO of Informix, not just some guy who knows how to debug a stored procedure.

Here is a juicy quote from a recent article published by MIT of which he is one of the authors:

We conclude that the current RDBMS code lines, while attempting to be a "one size fits all" solution, in fact, excel at nothing. Hence, they are 25 year old legacy code lines that should be retired in favor of a collection of "from scratch" specialized engines. The DBMS vendors (and the research community) should start with a clean sheet of paper and design systems for tomorrow's requirements, not continue to push code lines and architectures designed for the yesterday's requirements.

Strong stuff! Especially for a generation of programmers for whom the relational database is just another ubiquitous part of their standard solution architecture. So is SQL the new HTML as some have claimed? Or are we heading to a new generation of database engines that are created individually for each solution space, perhaps created on the fly and defined in a domain specific language.

Carpe Emporium

I was wading thru my daily ration of VC blogs just now, when something caught my eye. Or I perhaps I should say, I was "submerged, weightless, suspended in the tepid depths of the thing... in a state of perfect sensory deprivation, when all at once an extraordinary thing happened: I noticed something!"

(Thank you Mr. Wolfe)

There is the midst of Fred (A VC)'s 30 thoughts at 30,000 feet, it was:

Should the CEO of every technology company be a technologist? It seems like it’s easier to teach a technologist finance, marketing, sales, and management than it is to teach a good manager technology. And it seems that key business drivers are increasingly technical. It was true in the past, when Novell beat Banyan with marketing over technology, or when Oracle beat a host of relational database companies with sales over technology, that technology alone didn’t win the day. But let’s look at Facebook versus MySpace, Google versus Yahoo!, Skype versus Net2Phone, and Apple versus the entire music business. The companies with strong technologists as leaders seem to win more often these days.

I could hardly believe my eyes! Back when my associates and I used to do silly things like meet endlessly with VC's (and you know who you are) I often heard about how "we would need to hire a CEO cause, ahem, everyone knows technologists cannot run a company."

Now that we are entering the commodity period for software startups, these people must be getting desperate. "Sure, we'll let you be CEO..."

Pretty pretty pretty pretty... good

Yet more wisdom about user experience and interface design from the Signal Vs. Noise blog, this time debunking the mistaken idea that a good user interface has anything to do with just drawing a pretty picture, and handing it over to someone to implement.

One phrase in particular really caught my attention, "our designers apply their talents to the native materials of the web."

Now, I am not trying to pick on Photoshop people here, but how can you design an interface that is interactive, without using interactive tools to do so? DHH really has this right, since the web is built with HTML and CSS, a good web interaction designer needs to work with these "materials".

Likewise, a web interaction designer, might not be good at videogame design. Both the web, and console games, have their own set of standard use metaphors. Even each console has its own language, consider the vast difference between UI for the XBox 360 vs. UI on the Wii. Each has its own selection of native materials, and choosing to ignore these elements by inventing your own, makes it more difficult for users to anticipate what the software is going to do, based on their previous experience.

As such, working with the native materials of the web means conforming to a very small set of options, an exercise in constraints. This does not mean there should not be aesthetic to web UI design, quite the opposite. But it is an aesthetic based on sticking to certain forms, and the further you move away from these forms, the harder for users to adjust.

The realm of "graphic" design is only indirectly related to "user interface" design. Both require design, but each also requires certain distinct skills and knowledge from the other. A user interaction designer may work in the visual realm like an artist, but has to have an engineer's discipline, at least it they are going to be good, and not just pretty.

The Proper Use Of Color

Really cool article here from of all places NASA (go figure) courtesy of the Signal Vs. Noise blog. Entitled "DESIGNING A COLOR GRAPHICS PAGE", it really breaks down a process of utilizing color to maximize user understanding of information.

Color for its own sake is better kept to the domain of art. Functional design, like that of software user interfaces, need to be much better thought out, reaching for both utility and aesthetic qualities. Not an easy goal to achieve. The NASA article is a very good, if erudite, treatment of the subject.

UI wonks and wonkettes always mention Jakob Nielsen. Myself, I have never been a big fan of his. Sorry, I know all user interface snobs are supposed to be, but Nielsen's own website has famously ugly design and (gasp) poor usability. I am not making this up! Plus his big famous book was really boring.

I am much more a fan of Steve Krug and his fantastic "Don't Make Me Think". Now THAT is a book on usability. It probably took a really long time to write such a short book.