i18n gem for mongoid

I have just released my first gem!

It tries to leverage the pain in the ass that is model localization. It's for mongoid in this case, and its a pleasure to use (supposing that it works fine, since it hasn't been tested in a real environment yet).

I won't bother you with the details, since you can see a readme or even check the kind of announcement I made in the mongoid google group.

If you apps uses mongoid and you need to localize your fields, please check it out and test as much as you can. I need feedback to fix broken stuff and add new features.

Start anew

I have just lost my job.

A lot of people collapse because of this very same reason. Maybe it has something to do with times of crisis, I don't know. I see this as an opportunity to explore new ways of working, try my very own ideas, and invest time in research, reading and learning in general.

In Spain you can request part of the unemployment benefit as an unique payment if you are going to be either entrepreneur or self-employed. The latter is my case.

This money can only be spent as an investment for your new endeavour. I requested it, and I will update my computer to a brand new iMac quadcore, and that's pretty fine. I will even buy a new and ergonomic chair, but that's not the point of this entry.

I bought books. "How many?", you might think. Well... I bought 78.

I bought 78 books at amazon.co.uk, mainly technical ones, some about project management or productivity. Web design is present as well, as is Javascript, Erlang, Lua, Blender or iPhone development, among others. The bulk are C++ and game development books. That's because I want to design and develop games, or at least I want to try. And I know that I am good at trying.

So far in my life, I have learned how to program in several languages, doing magic tricks, dancing popping, playing the guitar and lately I started playing the piano. I am self-taught, as many developers are, but I self teach me in many, many areas as you can see. I don't even know where my knowledge about the English language comes from. I think that I taught that to myself too.

It's all about attitude and will. If you think... no, I'll rephrase that: If you know that you can do it, you will be able to do it. It takes some time to get to this point, though. Even I have some breakdowns and I think that I won't be able to do or learn something. But I end up being able to do it. Always. It's about perseverance and self-confidence. The good thing about this, is that when you become proficient at learning by yourself, it becomes second nature. Well, kind of.

I already read one of the books, it's Pragmatic Thinking and Learning: Refactor Your Wetware. I really liked it, it has lots of interesting ideas that I am eager to try. But one of the interesting things I noted was that I already apply some of the practices that Andy recommends on his book. And I think that somehow they just came out of the blue, because of my bias towards embracing change and learning new things.

I don't know if I am going to blog more often, but I should, and I think I will. It would be nice to use my blog as a real log of the changes to come. I think that I should rename it to Papipo 3.0, though.

Congo-cms, a content management framework in rails and mongodb

I've started a project in github, which is a prototype of something that I've been searching for years: a flexible content management system/framework that makes sense.

I've looked into ez publish and similar stuff, recently I've met expression engine, and I have even considered the drupal model. What all these systems have in common is one --in my opinion-- bad constraint: they store their data in a relational database.

Those CMS or CMF basically "simulate" a documental database on top of a relational one. I can't see how that can be good.

My aim with congo-cms (a name which comes from content+mongo -- yeah, I know, pretty smart name xD) is to offer a framework to define flexible datatypes, as ez publish and its companions do, but with the actual data stored in the proper way. If you create a blog using congo-cms, the blog post documents stored in mongodb, won't differ from those that you could store if the application was a plain weblog made with rails as in the old fashion.

I'm using MongoMapper mainly because it really fits my idea of using embedded datatypes. For example a User could have Addresses, and those should be stored in the User document itself. With MongoMapper this feature comes straight out of the box.

I hope to improve development a bit in the next weeks, and hopefully we will use something similar in my company's next project.

unit vs. functional tests

Sometimes I find myself thinking about unit tests being useless. Not that really useless, but bothering, at least when compared to functional tests.

In the end, you should really rely on functional tests to check the health of your application, since those are the only tests that are really checking that all your stack works perfectly, top to bottom, that the database schema is ok, and that permissions and data are handled correctly.

You can even add functional tests to an existing (legacy?) system to use them as regression tests, and to be able to refactor parts of the application while knowing that everything is still right, while adding unit tests could be a pain in the ass, and not that useful, really.

Why are unit tests bothering? They are harder to maintain. You usually can change the implementation of some functionality without touching functionals, but you usually have to make changes to your unit tests. I recommend you to abuse stubs to keep the coupling to a minimum, though.

Anyway, when it al comes down to the development itself, it's when unit tests really shine. They allow you to start coding any class without worrying about other classes, thanks to mocks and stubs. They help you to think about communication between your objects or processes or whatever, because you should create your methods or functions simple enough that they can be easily tested. And finally, they are your api documentation. They allow any other developer to learn your application by example.

Rails 2.0 released

Although there is no info about this in the rails blog, I did a gem update this morning, anv voilà:

papipo$ sudo gem update
Updating installed gems...
Bulk updating Gem source index for: http://gems.rubyforge.org
Attempting remote update of actionmailer
Install required dependency actionpack? [Yn]
Install required dependency activesupport? [Yn]
Successfully installed actionmailer-2.0.0
Successfully installed actionpack-2.0.0
Successfully installed activesupport-2.0.0

And it keeps going with all 2.0 libs.

Greetings for the rails team.

Enjoy 2.0.

UnitRecord and rails 2.0 PR

I've been reading about another way of testing, and I thought that I should give it a try.
The problem is that when you setup all the needed steps, UnitRecord complains about ActiveRecord trying to connect to the database:

[...]
RuntimeError: ActiveRecord is disconnected; database access is unavailable in unit tests.
[...]

This is due to some changes in rails trunk, that added a "reset_cache" method that checks for an ActiveRecord connection.

In order to avoid this, you can change your unit_test_helper.rb from this (as shown in UnitRecord documentation):

require File.dirname(__FILE__) + "/../test_helper"
require "unit_record"
ActiveRecord::Base.disconnect!

to this:

require File.dirname(__FILE__) + '/../test_helper.rb'
require 'unit_record'

module UnitRecord
  module DisconnectedFixtures
    def disconnect!
      (class << self; self; end).class_eval do
        def create_fixtures(*args); end
        def reset_cache(*args); end
      end
    end
  end
end

ActiveRecord::Base.disconnect!

That will take care of errors.
Happy testing!

BDD, isolation, integration

I have been reading a lot of posts about skinny controllers, isolation and good behaviour-driven development. Let me explain from the beginning:

The typical approach to spec a 'create' action looks like this (Taken from rspec documentation):

describe PeopleController do
  it "with a valid person should redirect to index on successful POST to create" do
    @person.should_receive(:new_record?).and_return(false)
    Person.should_receive(:create).with({"name" => 'Aslak'}).and_return(@person)

    post 'create', {:person => {:name => 'Aslak'}}

    response.should redirect_to(:action => 'index')
  end
end

That is too tied to the implementation. What if I want to use the 'create' method in my controller? And what about assigning attributes in a block?
What you are spec-ing here, is how your controller should look, not how it should behave.

Then I saw this in one of the blogs that I linked above:

it "should create a new thing" do
  lambda { do_post }.should change { Thing.count }.by(1)
end

This is really testing behaviour. The main problem with this (although I really liked it the first time I saw it) is, of course, that interacts with the database and the models. I don't want to hit the database from my controller specs at all, I want full isolation.

Add a pair of helpers in spec_helper.rb:

def mock_valid_model(klass)
  mock_model(klass, :save => true, :save! => true)
end

def mock_invalid_model(klass)
  m = mock_model(klass, :save => false)
  m.stub!(:save!).and_raise(ActiveRecord::RecordNotSaved)
  m
end

Then stub Model.new to return the mock you want. Spec your controller 'create' action in order to redirect in case that the mock is valid, and to render a template if it is not valid (of course you can add specs for flash or whatever):

describe ThingsController, '"create" a valid model by POST' do
  before do
    @thing = mock_valid_model(Thing)
    Thing.stub!(:new).and_return(@thing)
  end

  it 'should redirect to model show' do
    post :create
    response.should redirect_to(thing_url(@thing))
  end
end

describe ThingsController, '"create" an invalid model by POST' do
  before do
    @thing = mock_invalid_model(Thing)
    Thing.stub!(:new).and_return(@thing)
  end

  it 'should render "create" template' do
    post :create
    response.should render_template('things/create')
  end
end

There are various interesting things here:

1. You don't need to keep adding expectations to your mocks. Expectations couple your specs with the implementation. With my approach you can use create, new + save, new + block assignement, whatever. And the spec still passes.
2. The database isn't touched at all. That's good stuff, I guess.
3. You are really testing the behaviour. You know that the only way your controller will know if it should redirect or render, is to create a new instance of Thing, and call save or save!. That is actually an implied expectation, but without the need of should_receive(), just stubs.

Some of you may have noticed that I don't need to use the params() hash in the controller in order to make the specs pass. Right. But you know, that your controller is creating a new instance of Thing, and calling save, save!, create or whatever. That's when integration/acceptance tests come in

The only moment that you want your controller mess with params, is when you are not isolating. Because, if you are isolating, you can't validate parameters, since you stubbed save and save!.

With this approach, you keep your specs to a minimum amount of lines, you isolate, you test just behaviour.

Anyway, let me know of any issues you find with this.

Thanks for reading and sorry about the syntax non-highlighting.