Programming, Ruby, Scripting, Web Applications

Sinatra example

Since the Sinatra Project website currently seems to have been hijacked and directed to spam (the RubyForge page seems to be fine and is still a good introduction in its own right) I wanted to post an example of how to get going with Sinatra and also to highlight what makes it such a different approach to web frameworks. Here’s the example code on CodeDumper.

I wrote this with JRuby (for the cross-platform win). You’ll need to install the Sinatra, Haml and Mongrel Gems to get it to run.

It uses two styles, first there is the REST-ful extraction of parameters from the url and then there is the form POST submission. In both cases the code is pretty much the same as Sinatra extracts all parameters into the params hash.

I’ve inlined the Haml to make the example simple but normally the view templates would be extracted out of the code into separate files.

Sinatra is sometimes described as being as a web DSL rather than a web framework, it seems apt as it eschews MVC separation but instead by attaching code to routes directly it allows Controller code to be tiny and to delegate appropriately rather than putting in a heavyweight structure that might result in more frameworking code than actual “doing” code.

However one of the things I really like is something you can’t show in a code fragment and that is the ability to dynamically interact with your web application on the fly. Start up Sinatra, change the code of the file you’re running and your changes are reflected immediately. End the compile, deploy, view cycle! It kind of makes web programming fun again.

Ruby, Web Applications

Haml: Round Deux

So, with a comment on an earlier post about Haml, saying that it had had a major update I decided to give it another go. This time in conjunction with the web framework Ramaze.

While Haml has definitely improved but there was a definite sensation of returning to an abusive relationship. Haml is very cool but it can also be a colossol bitch to use. Mostly because of its whitespace lovin’ ways. Care to punt as to what the root cause of this issue was:

Illegal nesting: content can’t be both given on the same line as %form and nested within it.

I’d put a space character between my attribute curly braces and the form tag declaration:

%form {:action => 'url'}

when I should have put:

%form{:action => 'url'}

Do I really need this level grief just to avoid writing closing tags?

Haml does, as its advocates say, bring a clean and clear syntax to the table but it also brings a bundle of its own issues along the way. Particularly time consuming is having to adjust indents when placing content at different layers. The strict two spaces rule means you have to adjust blocks and even if you set up your browser to do soft tabs at two spaces (just for one syntax) it is still easier to play around with markup than Haml.

One feature I did like a lot since last time is that variable interpolation is a lot easier now:

%p== My variable goes #{@here}

Inline tags are still hopeless but that’s true of mostly of the lightweight templating systems.

Groovy, Java, Programming, Scripting

A Groovy Dice Roller DSL Solution

I’ve been looking at Ruby Quiz 61 for a while and I decided to take a look at solving it in Groovy as well.

Here’s a rough draft of what a solution might look like. So what did I learn about doing DSL in Groovy?

Well overall I think the Ruby solution is probably more elegant but Groovy’s Categories make meta-programming easy for meta village idiots like myself. I really struggled at first though because the documentation is so poor. I had to refer to Groovy in Action to sort myself out.

The key issue was that a category must consist of static methods which have at least one parameter, the first parameter should be of the type you want to “attach” the method to (so in this example I want to add the method d to Integer). You then effectively form a closure on the block of code to be executed with the method use which takes a list of categories you want to have active in the block.

The Eval object acts as a kind of synonym for GroovyShell but is meant to remove the boilerplate. invokes the block with no pass-in parameters.

I think that Groovy does a decent job of providing solutions to problems like this but if you had a choice to make would you choose JRuby or Groovy? It ain’t easy. What I am convinced off is that both should be part of the library mix in any Java shop that is looking to the future.

Software, Work

The cruel young men and their DSLs

When faced with the question about how people are meant to learn more and more languages some pundits say that perhaps people shouldn’t be programmers if they cannot learn new languages. When you’re young, bright and brilliant that may seem a reasonable answer. However the truth is that no matter how high you try to set the bar on programming, the amount of programming to be done is far in excess of the capacity of the relatively small number of brilliant people in the world who are inclined to do it. Telling the people who make a living trying to answer this demand, with less stellar qualifications perhaps, that they should shape up or ship out isn’t going to win any friends.

It’s also pointlessly antagonistic. Getting to learn many languages should be seen as a chance to broaden and enhance skills. However that is not going to be attractive if organisations continue to provide incentives in terms of pay and opportunities to specialists. To respond negatively to the suggestion that you discard your hard-won investment in your language of choice is both natural and rational if you run the risk of earning less than the single-focus individual. DSLs will die a death unless they can be incorporated within the scope of an existing big beast language or employers adopt a capability rather than knowledge-based metric for pay rewards.

I also think that DSL aficionados often fail to point out to the broader audience of programmers that learning a DSL or even a variety of languages (most probably meaning at least one functional, dynamic and object-orientated language) will not be the same experience as the current depth learning of languages. Since a DSL should be for a specific purpose and have a small syntax or grammar customised to a particular problem or domain it will not be the same as being able to answer trivia such as what the problems with the Date API are in Java and what the Calendar class sets out to address and whether it succeeds or not. Interview questions may have to revolve around applying a new syntax for dealing with a particular problem instead of the usual language pop quiz.

Advocating languages as solutions should also involve advocating changes in employer priorities. If you don’t link the two then threatening someone’s livelihood actually makes it harder to achieve the DSL’ers joyful Babel of languages that matches tool to problem.