Warbler 1.3.1 is here!

Finally the fix that I mentioned here has found its way to the next release! What this means is that when you install Warbler now and you get the version 1.3.1 then you're again capable of using the config.gems option to bundle gems with your web application using Warbler configuration file alone.

Here's an ultra simplistic example to show how it works:

config.ru (the Rack application):

run lambda { |env| [ 200, [ "Content-Type" => "text/plain" ], "Hello, world!" }

Warbler::Config.new do |config|
  config.gems = ["sinatra"] # this is just an example here...
end

With that in place you can now run

jruby -S warble

and have the .war file created for you in a matter of seconds.

And live is good again :)

String + String = Problems

This is just a quick note to everyone not knowing it.

If for whatever reason you do have in your code something that concatenates strings using the + (plus) operator and it's going on in any form of loop or other that means executing this part regularly you might want to rethink what you've become over the years.

Man I never thought I'll see this thing again but I did! One of the developers was (again) producing a CVS line using a + b + c + d + shit load of other stuff. I mean come on! There have been books written about it already! :)

So if you're a Java developer choose one of either String.format, StringBuilder or StringBuffer classes to do the concatenation for you. If you're a .NET use either String.Format or StringBuilder to do it efficiently.

If you're a lucky Groovy developer your string concatenation will not be efficient anyway so you're free to use string interpolation - you can't get any worse than that :) At least it's damn good readable!

Sure thing is that depending on which platform you use concatenating might be more efficient if you use (for example in C#) the String.Concat method. But overall if you're concatenating a large number of strings (say in a loop or so) use the builder things at your disposal - they're a safe bet.

Simple design as product architecture

Disclaimer

What I'm about to express in this post is going to turn your world upside down, make you cry for help or worse.

A bit of history...

Since some late 1999 I've been creating what's called Enterprise applications. On some point they have been highly complex calculations of central heating and other pipe-related networks alongside with some flight planning system in Delphi and on the other end web sites (because that's what they really are) but with some huge backend in Java. And then some desktop applications in C#. All applications had one thing in common: they were unsustainable by a small group of people (say 3 smart guys) and needed a "team" of analysts, developers and (God forbid) configuration managers (I still don't know what the hell his role was!). They needed to work in "iterations", have defined "stories", maintain existing "system" and all that kind of s...tuff (damn, that was close).

Some thoughts to spice it up

During this more/less stupid time I've learned one thing and one thing alone: There's no such system that can't be decomposed, chopped with a master axe into pieces that are maintainable by hundreds of developers all around the damn world.
In one of my previous positions (which I hated so much I can't even begin to describe) I was forced to create database diagrams, then create domain classes (manually because this damn tool was not clever enough to generate Java code at all) and later on to keep them in sync (what was the guy that came up with this stupid idea thinking about?!?!?!), then to implement GUI in Java Server Faces (with no instant reloading of any fricken sort (JRebel did exist at that time if you wanna know) and - here's the damn best part of it - as a single, monolithic Java EE all go no quit application including in its beast's belly a CRM, Admin module, Shop, custom communication module, some master data editing.. pretty much everything in one big ball of mud. So here's how it went:

1. Code, code, code... code some more and then some.
2. Build, get a coffee in the mean time cuz it takes so damn long...
3. Ok - build is done - with errors - rebuild - next coffee (I'm becoming addicted to coffee at this point)
4. Build passed, deploy to Tomcat - and have a cigarette or two

Ok, so with JRebel this idiotic cycle is down to Ctrl+S and that's cool but our master of disaster (read: manager and architect in one person) didn't like the idea to spend extra bugs on software so we were stuck with this shitty workflow. Very frustrating indeed.

This was the first time I was writing an enterprise-grade application that I thought went completely haywire. In fact I was so convinced I couldn't work with this project no more and I decided to quit. As far as news go the team didn't have a release as of last week so after about 4 years of development the project didn't begun to earn money. CRAZY!!!

Sanity revealed

If creating enterprise-grade applications looks this way oh why would anybody do stuff like this at all??? The answer is simple and so painful: money! Some people even say that making such complex systems is fun. For the purpose of this blog entry I'm going to call them (quoting after Linus Torvalds) ugly and stupid. They should not be in the business - they should be in some mental institution taking their medication regularly.

Learning how to chop things to pieces is one of the most fundamental principles one learns when doing object-oriented programming. Somehow we forget that this same principle applies to the whole as well. It might be hard (hey, nobody said it's going to be easy!) to find the right balance between infancy and complication. But somewhere out there lies the right spot towards which all roads should lead.

Examples are what I like the most so I'm going to describe my idea by means of a project that most of us are familiar with - the blog :P

A blogging engine starts easy: a controller with a couple of methods (list, post), 2 or 3 views to display the data, one or two models to store this damn thing in a database - yeah! We've got a blog engine!
Then the real world kicks in and requirements start to pop up. We should probably be capable of administering the site, so we create a separate controller, do all the magic behind it and life is good again. And new requirements come in to be able to measure the popularity of the page so we create a filter to do the hard work for us. The adventure continues...

STOP! Isn't there something that we could extract and make it a separate module? As a OO developer you recognize the fact at once: there's a program that does more than one thing so the single responsibility principle is flushed down the toilet. Can't we do better?

As it turns out we can. Having a modular architecture for our application (be it OSGi or better yet Grails with plugins) can help us split the problem into pieces, implement them individually, have them tested to the bone and described so that when a newbie comes in he can take the docs and start coding right away. And before you say anything: since a module is doing one thing only the docs aren't that big. I mean, how much can you write about storing data in the database and then displaying them on a page, right? And if the blog engine turns into a full-blown CMS can't we have the management as a separate application? Will this hurt our feelings?

The same thing goes for calculations, statistics and god knows what else comes to that little screwed mind of ours.

Scalability === Maintainability

In the sense that things you can't chop you can't scale you can say the exact same thing about software products. If you can't split the problem into smaller problems you can't scale it to have many developers working efficiently on a product as a whole. But if you do you can hire hundreds of programmers, split them into really small teams and have them implement any system in a matter of (almost) weeks.

So you say you can't..

One thing I hear over and over again is "we can't split this up because.." and at this point I stop listening. The reason why is not important and is always the same: things depend on each other in a way they should never have.
We do have fantastic architectures like CQRS, CQS (being its predecessor), RESTful design and all that kind of belt of tools we can employ to make things chop-able (in a matter of speaking). The sky is the limit!

Reality is a bitch

Sure thing I'd love to live in a perfect world with requirements known up front that don't change till the end of time (meaning next version), perfectly feasible to code at all levels of abstraction developers and high quality standards met every day. The reality however means you have to get your hands dirty till elbows in some serious shit just to get the simplest things to work/fix (there you go - I've finally said it)

Live would be so ridiculously easy if we all wrote simple software.

Explorative Programming

Recently I've been struggling with a friend of mine about the actual meaning of Explorative Programming (or short ExP). The term Explorative is used here so that the pressure is put on the "exploring" part of it. I actually know it's not a proper English word but who cares :D

Anyways... Explorative programming - what is it all about?

Let's say you need to write the infamous "Calculator" class with the (also infamous) "add" method. In this particular case there's little to explore, right? You know (hopefully) that 1+3 equals 4 and there's nothing in the whole universe that will convince you otherwise :)
Let's explore this simple case in a little more TDD/ExP way. In TDD you'd write a class called (let's say) CalculatorTest. In that class you'd write a method with a @Test annotation (if you're using JUnit). That method would then instantiate your Calculator class (which does not exist yet) and call the method "add" (which does not exist yet) with some well known parameters that produce a well known output.

All good so far, meaning your test does not compile :).

So what you do next is that you add your class (preferably by means of some IDE's refactoring or what have you), then add the method (same as before - you actually can do this manually but who would do that when Eclipse and all the others are there to help you), fix the parameters (didn't you just write "def" to declare your variable to state that you don't really care what the fricken type is?) and finally after all those IDE-enabled steps (which let's be honest didn't take all that long) your test is compiling but failing. Great success!!!
The next obvious thing is to add the simplest thing possible which is to return the proper value from your function, then to add next test, see it failing, add the proper logic to satisfy both test cases.... you get the idea. This is TDD in its purest form as described by many mentors out there.

Where ExP is different is where the IDE needs to come in. Why for the love of god do you need a sophisticated tool to create a file for you when you actually don't need it? What you need is a class - not a separate file!

In ExP I propose that what you do is you do have the class (or method) you're testing but in the same file as your assertions. So for example:

def add(a, b) {
//the actuall implementation whatever it is goes here
}

assert add(1, 2) == 3
assert add(4, 5) == 9

Ain't that nice? You can sort of "explore" your domain "in place" without the need to have a sophisticated IDE to create unnecessary files for you (you're just creating a method for all you'd care at this point).

Let's examine a slightly more proper example for the actual "explorative" part of the thing, shall we?

Let's assume you're not alone in the world, which is a pretty good assumption in my personal opinion. Next let's assume you didn't write the code you're working on all by yourself (which in my personal experience is more than likely, or actually it's taken for granted if you add to the fact that you didn't write Spring or Hibernate all by yourself).

What you can't do at this point is to wave a magic wand and say "let it do what the client wants!". Instead what you can do is the next good thing which is to say "let's see what the user actually wants". And in the spirit of ExP what you'd do is to spawn a console of some sort within the currently latest version of your application (hello rails and grails!), sit down either alone (with tons of useless documentation trying to make your way thorough it) or with your actual customer, code 5 or 10 lines, write the assertions when the user says that it is the desired result.

Once you have it all figured out there's tons of knowledge that you better store for posterity! To do that you move the necessary bits and pieces where they belong, cutting your assertions in oh so many places into separate methods that'd satisfy your good taste for testing a single thing at a time and of course moving the class you just wrote to a separate file. From this moment on it's TDD only, my friend. You've got to keep'em separated.

Oh, and before I forget: the best thing in all this is you can actually use your eyes and brain to interpret the imperfect results before writing any assertions. Let's be hones: the computer (or the assertions rather) are only as good as you wrote them. If you already know what the actual outcome is (like in the case of some tests you might find on the net) it's fine to do it the old fashion way with separate tests and all that. What you do have to take into consideration while working with real life stuff is mostly the imperfect steps in between and how you can first spot them with sort of debuglets (I love this term!) or other means like the outcome of your script which is a debuglet all along.

I hope I've shed some light into this ridiculous term that I've tried to coin. Just as a word of caution: it might make no sense whatsoever when applied to your situation. What I strongly believe in is that it gives you the possibility to use simple text editor to do the TDD kind of thing with more freedom and options to choose from. That being said I officially declare that I don't use an IDE for anything and I mean it. IDE is bad for oh so many reasons I won't even go there. They make you a cripple when you need to actually come up with an idea of your own!

Oh! and before I forget: Once you've moved stuff back to where they belong you need to "integrate" your class with the rest of the system. That's where the regular TDD, IDEs and all kind of stuff that's floating around comes in.

Would you believe this all came to be from a single conversation with a supervisor that didn't actually end up being my supervisor at all? Funny how things play out...

There's a number of people that have advocated this style of programming. Recently on the 33rd degree conference Dierk Koenig showed how you'd go about writing your quicksort implementation. Previously Luca Bolognese showed the same kind of approach while presenting F# to the audience. It's all about learning, exploring and happiness :)

Have fun!

The easy but you have to know it...

Yeah, this is the one that is probably make me look like a complete newbie. I've been developing apps in Ruby mostly on Ubuntu but lately I've turned back to Windows and found out that on this platform not everything is taken for granted like it was on Ubuntu. So for that reason I'm making this note so that I don't forget.

If you're installing Ruby gems on Windows and they require compilation of some native extensions (like the JSON thing or Thin) then you need a C compiler to do that. In fact you can do that in multiple ways but there's one easy one that'll take the pain out of your neck in seconds.

What you do is you download the DevKit package, un-7zip it (it's actually a self-extracting archive so that's easy), cd to the directory where you unzipped it and execute the following 3 commands:

ruby dk.rb init
ruby dk.rb review (and make sure your Ruby installation is at correct place)
ruby dk.rb install

With that in place test it by issuing for example:

gem install json

and you should see the following

Fetching: json-1.5.1.gem (100%)
Temporarily enhancing PATH to include DevKit...
Building native extensions.  This could take a while...
Successfully installed json-1.5.1
1 gem installed

Have fun!

Cross-origin resource sharing

Today I've stumbled upon quite an interesting topic while watching this video from MIX11. Around 40th minute Giorgio Sardo brought up the topic of cross-site Ajax calls. At first I thought "OK, yet another proprietary extension in IE9" but then I started googling and what I found (and subsequently here) has exceeded my wildest expectations. As it turns out it is implemented in all modern browsers. There's a catch to it: the server needs to be aware that such a request will come and attach a specific HTTP header in response.

Since I don't do well with plain text explanations I've put together a Sinatra client and a Rack server to demonstrate this feature.

Client

This is the client code using jQuery's load method to do the Ajax heavy lifting:

$("body").load("http://localhost:9292/"); 

No surprise there, right? It looks like a regular Ajax request. The difference here is that it queries localhost on a different port (9292 - default Rack port) than the one that the request originated from (4567 - default Sinatra port).

Server

Let's see how we can respond to such a request using a pure Rack application.

run lambda { |env| [ 
200, 
{ 
  'Content-Type'=>'text/html', 
  'Access-Control-Allow-Origin' => env['HTTP_ORIGIN'] || '*',
  'Access-Control-Allow-Headers' => 'X-Requested-With'
}, 
env.inspect 
] }

The key here is the line that defines the Access-Control-Allow-Origin response header. When it's set to * it means that everyone can access this resource from everywhere. It's a sort of catch-all if you will. The value of env['HTTP_ORIGIN'] is the value sent by the browser to the server saying "Hey, I'm calling from here. Can I access your resource please?" And if the server agrees (which it does from everywhere at this point) the browser will honor the response and return the data back to the script. The Access-Control-Allow-Headers header is sometimes required for example by ExtJS' Ajax calls.

Here's the example for your convenience. You can start it by issuing the following commands:

cd server
start ruby -S rackup
cd ..\client
start ruby client.rb

After that open your favorite browser (I sure hope it's not IE < 8), navigate to http://localhost:4567 and observe the environment string from the server dumped onto your screen.
The client is obviously written in Sinatra, the best micro web framework ever and the server is a pure Rack application.

Going ultra simple with JRuby, Tomcat and Rack

This one is for those that don't believe that web applications can be written in a single line :D With Rack and Warbler it is actually possible :D

First install the prerequisites and required gems as described in this post.

Create a file called config.ru with the following content

run lambda { |env| [ 200, { 'Content-Type'=>'text/plain' }, "Hello World!\n" ] }

Then run warbler like this:

jruby -S warble

... and deploy the resulting war file to tomcat. DONE!

Oh! And in case you were wondering: the performance of this application is just incredible! On a virtual machine with 2 cores at 2.19GHz each and 512MB RAM (Dell D830 laptop) it delivers around 2000 requests per second!

Ruby rocks!

Running Sinatra application on Tomcat

My recent fascination with the Sinatra framework has made me look for viable deployment options. At first I started with JRuby and Tomcat6.

So what do I need (top-to-bottom with only JDK installed) to successfully deploy a hello-world style application on Tomcat?

Installing prerequisites.

First you need a copy of JRuby and Tomcat6. Unzip both of them some place you'll have easy access to. In this tutorial I'll be using the root of drive C: because this is a folder everyone will have.
After doing so you should have 2 folders on your disk with the appropriate applications:

C:\apache-tomcat-6.0.29
C:\jruby-1.6.1

Installing required gems:

  C:\jruby-1.6.1\bin\jruby -S gem install sinatra sinatra-reloader warbler bundler

Creating the application.

Creating the hello-world style application (a bit extended version) is really simple. First you create a folder in a place of your choosing. In that folder you just need to create 2 files:

hello.rb:

  require 'rubygems'
  require 'sinatra'
  require 'sinatra/reloader' if development?

  get '/' do
    @message = "Hello, world! from Sinatra running JRuby on Tomcat"
    erb :index
  end

views/index.erb

  <h1><%= @message %></h1>

The hello.rb is the main application file and views/index.erb is the supporting view.
All further command line commands must be executed from the folder you've just created!

Testing if everything works as expected.

To test if the application performs as expected issue the following command inside the folder you have created:

  C:\jruby-1.6.1\bin\jruby hello.rb

and if there are no errors you'll have the application available on port 4567 right away. Test it with your favorite browser navigating to http://localhost:4567

Creating deployment files.

This is a little bit more involving. We'll create 3 files now:

Gemfile:

  source :rubygems
  gem "sinatra"

config.ru:

  require 'rubygems'
  require 'hello'

  set :run, false

  run Sinatra::Application

config/warble.rb:

  Warbler::Config.new do |config|
    config.dirs     = %w(views)
    config.includes = FileList["hello.rb"]
    config.jar_name = "hello"
  end

The Gemfile is just the definition which gems are required by the application. The config.ru file defines how rack application is supposed to start. config/warble.rb is to tell the warbler tool which files go into the actual WAR file and what the output file name should be.

Create hello.war

To create the output hello.war file issue the following command:

C:\jruby-1.6.1\bin\jruby -S warble

At this point you should have the hello.war file ready for deployment.

Deploying to Tomcat.

This is the easy part. Simply copy the file hello.war to C:\apache-tomcat-6.0.29\webapps and start Tomcat.

Conclusion

It wasn't that hard, was it? Next time we'll see how we can do exactly the same with Apache HTTP Server and Passenger (a.k.a. mod_rails) running on a freshly installed Ubuntu 10.04.1.

And last but not least (because I know you've been waiting for it): the source code is obviously here for your entertainment :)

Have fun!

Edit on May 9th, 2011
I found out why specifying gem dependencies in config/warbler.rb doesn't work as it should and why the workaround with Gemfile is needed. Obviously for any bigger project it is better to use Gemfile and bundler as it solves the problem when another developer jumps in and wants to start hacking the application. For simple projects the config/warbler.rb should be enough though. Up until now specifying gems didn't work as expected due to an obvious bug in warbler. Here's a fix that I proposed to solve the problem:

https://github.com/padcom/warbler/commit/b4b24e17dee5bb98525203c82519a8901874ef81

With that in place the config/warbler.rb would look like this:

Warbler::Config.new do |config|
  config.jar_name = "hello"
  config.dirs     = %w(views)
  config.includes = FileList["hello.rb"]
  config.gems     = ["sinatra"]
end

and naturally the Gemfile would go away (one file less to keep track of :D in such a simple application)

Sinatra - the power is back!

I honestly don't know what I've been doing for the past 5 years. Really. I've been trying to solve simple problems by learning "corporate" bullshit allowing the really good stuff go unnoticed. But that has changed. I'm a new person now. I'm changed, changed forever.

Today I've been working on my json-rest-api plugin to allow for excluding some properties if you really wanted to. Ok I admit, I needed that in the application I'm writing for the corporate. And so I've been browsing, looking, searching because I somehow knew that something is wrong with the world around me. I couldn't quite tell what it was but it felt like a splinter in my mind that I just couldn't get rid of.

I've stumbled upon Graffiti micro-framework for building web applications in Groovy. I was so amazed with the immediate results it gave me that I started digging deeper and deeper into the roots of where this damn thing came from. And so I found Sinatra...

And the world will never be the same...

Sinatra is a micro-framework giving a DSL style to create simple web applications. Since I'm a windows addict (don't shoot me please!) I needed to find something else than shotgun to do the hot reloading of my app. And so I found sinatra/reloader...

And the world will never be the same...

Fortunately Sinatra is not married with any ORM so I could find a tool that's equally simple and does the heavy lifting of moving data from and to the database for me. And so I found DataMapper...

And the world will never be the same...

At this point I'm after re-writing the ihatejsf.com application (34 lines of Ruby code!!!) using Sinatra and DataMapper and after deployment on Heroku. It was an experience I'll never forget. It has changed me forever and ever.

I'm a changed man.