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.