This is quite funny. A friend, Perl addicted, is now learning Ruby. He really enjoys the language but made a interesting observation: Ruby is a language for lazy programmers! Well, I have to agree... You know, I love saving keystrokes and achieving more by writing less. And this is so true with Ruby. Let me give a really simple example, comparing with java - don't get me wrong... I love java, specially the platform, but it fits well here since I've always been a Java guy.

On friday I'll be heading Prague for the European RubyConf. Anyone is going? :) Almost 300 attendees already registered for the event. And a few very interesting people will be speaking there like Matz and DHH (this one, through skype). Besides that, the organization staff is scheduling 2 parties, friday and saturday, for the attendees. Networking comes to mind, doesn't it? I think it will be a great opportunity to meet interesting and bright people.

Today was the first day of the conference and it started with a tutorial about DSL's with Martin Fowler, Neal Ford and Rebecca Parsons. We also had as attendants Ola Bini, core developer of JRuby, and others. My expectations were pretty high and the presentation didn't let me down. I'll try to put here toghether my impressions and some notes I took while I was there. Marting Fowler started discussing what DSL's are and giving some examples that many of us use in our day to day Job.

Next week I'll be at QCon, in London, so if any of you are going to the conference and would like meet up for a couple of beers and a tech talk, please don't hesitate to drop a message. For those of you who have never heard of QCon before, it is a really nice event to play along with some of the most popular names in the software engineering community.

I think I've been really lucky lately. In my new job I'm getting to work with many interesting things and OpenID is just one of them. We are investing high in Ruby on Rails and we have now a few internal applications in development stages. Our manager wanted the ability to let people log in to our rails applications(for now) using their OpenID accounts. It was a funny task, as I knew very little about OpenID.

I never paid too much attention on testing database stuff. While working with java, the closest I got to something workable was using the test case abstractions provided by the Spring framework. It ensures that each test method runs in its own transaction that is rolled back after the test's execution.

Fair enough. I used the setUp() method on my TestCase to configure some records so I could work with them, removing all of them in the tearDown() method. It was quite simple and worked.

But I always felt something strange with this solution. First of all, I had to add another framework just for that. - Actually I was using spring for dependency injection, but if I wasn't, it wouldn't be a nice option. And another thing that bothered me, is that you cannot guarantee that your database is in a known state.

After I started to work with Ruby - and Rails - I discovered the testing fixtures. It is a really nice way to set up your testing data without having to worry about your database state. - If you don't know what I'm talking about, follow the above link first.

Then I received a message from a co-worker saying he was having some trouble in using DBUnit with Hibernate, and asked for some help. I've heard of DBUnit before but never tried it myself. It was a very good opportunity to take a better look into it.

The basic idea after all is very similar to that of the Rails Fixtures: You have some sort of external file - XML in this case - where you set up the testing data. So the framework takes care of erasing the database, inserting your test data and returning it to its original state.

So far so good, DBUnit's default Classes works with JDBC, DataSources and JNDIDatasources, but not with Hibernate. The effort to put them working together is minimal and is documented in their web site.

I decided to share how this can be done with hibernate and in the end, you would have a test case similar to this one:

[2008/04/30] Update: The ibm_db gem has been updated to support the new Rails 2.0 style migration. Now you can just use t.xml and it will work. Look here for more info. Thanks to Mario Briggs for pointing me to the update. --- In my new job we work with XML data natively stored on DB2. I have done some test with Rails and DB2 a few weeks ago and it's pretty interesting, specially the easiness that Rails deals with XML.

Following the Rails 2.0 hype, I've been playing around with it and decided to share a first impression: Scaffolding is gone! But wait, before you knock your head against the wall, let me tell you something: I lied :) Scaffolding is not really gone. It's just changed a bit. How can I tell? Well, as a good developer I thought: "I'll just create a scaffold with the new version and see what's different"

Dependency injection - DI -  is a great thing. Really. The hability to tweak implementations without touching your code is awesome and the DI frameworks, like spring, saves you a lot of coding. No more service locators stuff.

But, and there is always a but, you're left with a bunch of XML configuration. And I hate it. Not that XML files are bad... the thing is that everything nowadays has its own set of XML configurarion files. And Spring is not different.

Well, we all know how hard, or at least cumbersome, it can be to set up a production environment to deploy your applications. Besides all the hardware stuff like storages, links, routers you are still left with a huge amount of software configuration to handle. This often includes configuring things like clusters, load balancing and services monitoring - Including notification of interested parts in case of any failure. Pieces of software you have to tie up and make them work together.

But hey, ruby lovers, you may have a better way to get this going! Released by ThoughtWorks, RubyWorks is, as quoted from their website, a production application stack for Ruby On Rails applications. I decided to give it a try and I really enjoyed it.

First of all I didn't want to mess with my actual configuration so I installed a new vm with Virtual Box. It has Ubuntu 7.10 on it, with 256MB of memory.

After installing RubyWorks - instructions on their website -, you get a new skeleton rails app up and running, being served by 4 mongrels that defaults to production environment! Impressed? There is more. A HAProxy is also set up in front of your mongrel servers acting as a load balancer.

Well, you probably want to monitor all that stuff huh? A monit web interface is waiting for your call on port 2812! It monitors all your mongrel servers - four by default - and your HAProxy, allowing you to measure CPU and Memory usage, among other things.

The coolest thing here is that all these softwares you would have to setup by hand are already working together, ready for production! Well, is it?

Going a little deeper, I deployed a database backed application to test this stack's performance.

I used Siege to stress the app and I am very happy with the results! I compared it with a single mongrel running on production env and no proxy at all.

It is worth mentioning that having 4 mongrels running took my vm to 77% of memory usage, while a single mongrel took it to 38%.