Dec 21

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”

I fired up a terminal, created a news rails application and generated a new model:

$ script/generate model Contact name:string email:string - yes you can do this in rails 2.0, and these fields get into your model’s migration!

Now the I have a new model, it’s time for a controller to manage it:

$ script/generate controller Contacts

So your controller would look something like this huh?

class ContactsController < ApplicationController
scaffold :contact
end

Well, too bad! The method scaffold is gone from ActionController::Base! And I’m not lying this time!

Now that the dynamic scaffold is gone, we’re left with the static one.
Ok, let’s try it then:

$ script/generate scaffold contact

And it won’t work again! ;) At the end of the output, you will get something like this:

Another migration is already named create_contacts: db/migrate/001_create_contacts.rb

It really means that if your model is meant to be used by a scaffold, you better generate it in the same line. It will fail, afaik, if the model previously existed. Destroy yout model and controller, and execute the following:

$ script/generate scaffold Contact name:string email:string

Done! Just run your migrations, startup your server and your new scaffold in rails 2.0 will be working gracefully!

It took me a while to discover this changes because I didn’t find it well documented. But maybe I was not looking in the right places. :)

Tagged with:
Dec 07

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.

Continue reading »

Tagged with:
Dec 01

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%.

Continue reading »

Tagged with:
preload preload preload