We just switched autoki over to Rails 2.0.2 in the last days. While the transition we replaced the asset_packager plugin with the new Rails 2.0 :cache => true option in stylesheet_link_tag/javascript_include_tag.

As our assets (public/*) are served from an apache webserver that has its own checkout of the project, we can’t let Rails generate the all.css/all.js files on the fly when the first request comes in. Instead we have to pre-generate them at deployment. For asset_packager we had a capistrano task that did just that. Rails doesn’t have that. Instead the logic to generate the files is built right into the link/include methods in the AssetTagHelper(!). So now we are simply doing this in our capistrano recipe:

Fire up a mongrel, curl the start page, bring it back down. Feels a bit overkill but it works. (at least I hope it will when I’ll first try it later today)

Sometimes it happens that you skip a migration. Imagine you were working on a branch and are now merging back into trunk. In the meantime someone committed the migration 303 into trunk but you also had a few migrations in your branch. Now your development database is on 306 and you missed 303. Instead of migrating back to 302 and then again up to 306 you can also do the following in your rails console:

There goes your migration.

We recently introduced a new feature in autoki called the social feed. It’s basically a yellow box displaying any events on the platform relevant to the current user, like a friend has posted a new photo, or a new interesting car was uploaded. The data model behind this is pretty straightforward, we have a FeedEvent class and all kinds of subclasses, e.g. a MessageReceivedEvent. Each event belongs to a user and an event source, in this example the user would be the user who received the message and the event source would be the message itself. For each user, we simply display all the events that belong to him or her.

Now the question was this: How do we create these events? The most straightforward way would probably have been to create them in the models, so the Message model would have an after_create callback that created the event. What we didn’t like about this solution was that we would put a whole bunch of logic into the models that didn’t really belong there. Why would a Message care if there was some kind of event feed? Plus these events would be all around in our unit tests and make the bloated and probably sloooow (again). So we wanted to use the observer pattern to remove the creation of the event from the models.

(more…)

rubyworks is a full rails stack put together also by thoughtworks. this time it’s all open source. it features haproxy (supposed to be much faster and light weight than apache_mod_balancer) as load balancer, mongrel as application server, monit and runit for monitoring and controlling mongrel, mysql/postgrs/oracle ruby bindings for database connectivity and also bindings for ferret, libxml, hpricot and rmagick.

everything is nicely packaged as rpms and debian packages so it can easily be installed within 5 minutes (it really works). even better, the packages at the same time pretend to be ruby gems, so you can safely install other debian packages *and* gems that depend on one of the libraries provided by rubyworks.

now we had already set up a cluster of 6 servers for autoki with everything set up more or less perfectly so why would we need rubyworks? answer: to steal the config files for runit/monit and haproxy. our mongrel setup has always been a bit shaky, especially when it came to restarting the mongrels after a deployment. after using the rubyworks setup with runit now everything is stable. (btw runit can run and supervise any process in *nix and is ready to be the successor of the old init which is used by most linux distros to start up all the processes. one advantage is that it starts all processes at once instead of piece by piece, plus runit handles putting a process in the background and keeping it alive there, something mongrel is especially bad at).

Mingle is the new agile project management tool from thoughtworks studios. it’s not open source but it’s free for up to five users - sounds like a fair offer to me. for everyone who thinks differently - it’s written in ruby and deployed using jruby, but the class file decompiler is part of the jdk. i wonder how long they can actually make people pay for it. hello open source business models?

anyway, when thilo installed mingle from one of the cds given out to all conference attendees we first were a bit disappointed. after the installation you basically get a nice looking but totally empty screen leaving you with not much more than a big question mark over your head. we didn’t have much time then so that was it for mingle until i attended the corresponding session where things got a bit clearer: mingle is a completely customizable tool. the only thing that’s hard coded are users and cards/stories/tickets/you-name-it and that everything is a wiki page - the rest is up to you. the main features are these:

• define your own attributes for your cards: you can add new attributes to your cards and in place edit all of them - auto complete shows you a list of values that have been entered into that field before
• filter cards by any combination of attributes and save the filter, after which you can add it as a tab on the top
• card transitions - create a set of transitions where a card with a specific state can be transitioned to another state, e.g. from status open to status accepted and assigned to a person. this enables the project team to map their work flows into mingle
• create graphs and tables from the cards - multiple graph types are supported for easy tracking of iteration progress or number of bugs etc.
• project templates - so you don’t have to sit in front of a blank screen as we did

mingle looks like it could become a really cool tool. after all, trac is getting a bit boring after all these years(?) and we’ve actually stopped using its ticketing system, because it wasn’t easy enough to change it to our needs.

Last week was RailsConf 2007 in Berlin. Only a couple of days have passed and it already seems so far away. Time for some blogging before everybody forgets that it even took place and nobody’s going to read this So here’s the interesting part of the sessions I attended:

A Half-day of Behavior-driven Development on Rails (rspec)

This was the first session on tutorial day and for me one of the most interesting. It basically gave a looong introduction to behavior driven design, how it evolved from things like TDD and who realized what while enganged in which project back in the good old times. One of the interesting parts for me was when they talked about the whole story writing/specification process. I had heard most of it before but it was a good refreshment. The central statement was to write “Software that matters”, and to achieve this, you’d have to get the specs right - as we XPers know this should be done by collecting user stories. The suggested format for such a story was this:

(more…)

On autoki.com we have this “Tell-a-friend” functionality, where people can enter the email addresses of their friends and have the link to a cool photo or car sent to them. Until recently this was only accessible to logged in users because we were afraid of spam bots using it to send emails to everyone using our servers. At some point we realized that this function could be much more useful if everyone would be able to use it - member or not. The solution we chose to fight the spam bots was pretty standard: Captchas - Completely Automated Public Turing tests to tell Computers and Humans Apart. (I just love this name)

(more…)

If you change the images dimensions or introduce a new version for models using file column you need a way to update the existing ones.
Here is a script that will regenerate all file column images and its version. We still look for a way to generate only new versions.

For aprox. 3 months we have been using mocha now. And we promised to get back to this subject when we passed our 2000th revision.

In this post I’d like to share some expirence we made while using mocha. But first a short introduction to mocha taken from the rubyforge page.

Mocha is a library for mocking and stubbing using a syntax like that of JMock, and SchMock. One of its main advantages is that it allows you to mock and stub methods on real (non-mock) classes and instances.

We started to use mocha on an existing test suite and changed our test code in place when we wrote a new test or had to update old ones. The transition was mostly painless, there were three things where we stumbled.
(more…)

Tadaaa, weltexklusiv nur für Besucher dieses Blogs, das nagelneue autoki-online-Autoquartett - ab Montag auch für alle anderen, dieses Wochenende nur hier:

Viel Spaß beim Spielen.