This is our latest and also largest plugin for ruby on rails so far. After the installation it adds a social feed as seen in the picture to your rails application. The sources have been extracted from autoki which has had a social feed for a couple of months now, so rest assured we have put some thoughts into it over time.

Features so far: As a user I can decide what kinds of events I want to see on my social feed and also wether I want to be sent an email when an event occurs. I can also decide wether others will receive a notification on their social feed concerning my own actions.

The plugin includes model extensions for the user, a controller and views for viewing the feed and editing settings as well as a generator to easily create new event types so, getting started only takes a couple of minutes. For more info check out the README or get the sources from github.

Yesterday I was using attachment_fu to attach photos to a couple of models. Since attachment_fu requires you to create an extra model for the photo, you usually have a one to one relationship between the model and the photo.

But now that you have two models you also have to deal with these in your controller and views, something along the lines of this:

Sort of ugly if all you want is to add a photo to the Project model. But fear not, after adding the following piece of code to your model, you can transparently assign the photo to your project model in the view:

The tweaked model:

Now you can use a standard view:

And a standard controller:

(credits to this railscast for the idea of using a virtual attribute, I only added a bit of sugar for attachment_fu)

dead simple reports is a Ruby on Rails plugin that allows you to create reports from your application data within minutes. As of now it can not only generate HTML tables and CSV files but also M$ Excel spreadsheets. This is possible through the use of the spreadsheet-excel gem. You can grab a copy from the git repository or just download it from there.

autoki has recently grown into a more and more complex application. Besides two clusters of mongrels and the mysql database we have a memcached server, ferret and starling plus clients for asynchronous processing. WIth so many services running (and sometimes not running) the need to monitor all these grew. We decided to set up nagios on one of the servers - it’s ugly but it lets you monitor all sorts of stuff pretty easily via remote agents that run on each monitored server.

With nagios we have access to quite a number of monitoring plugins, e.g. for monitoring TCP ports (e.g. for checking memcached is still alive), HTTP, server load, free disk space etc. Yesterday I came to a point where I wanted to monitor something nagios couldn’t: When a user uploads a bunch of photos, the task of creating copies of the photos in different sizes is put in a starling queue for asycnhronous processing. If something with that processing goes wrong and the queue gets too big I want nagios to pick this up and notify me. Time for my own nagios plugin.

Nagios plugins are actually very simple. All you have to provide is something that can be executed in a shell and that returns either 0, 1 or 2 for an OK, Warning or Critical state of the monitored service. So here’s the source code for monitoring the number of photo uploads in the queue (RAILS_ROOT/lib/check_photo_uploads.rb):

At autoki the server that runs the asynchronous processes is called jobs1 and this is also where the queue should be checked, so I added this to the /etc/nagios/nrpe.cfg file (the config file for the remote nagios agent):

Then I had to add the service to the nagios configuration on the monitoring server:

Well, that was it, and this is how it looks - ugly but it works

(I recently signup with scout - looks much prettier and the setup is much easier than nagios, plugins are written as ruby classes and it comes as a ruby gem - sweet concept so far, could have been my idea, more on that later)

Na endlich. Nach all den Jahren des nur-Geldverdienens und Open Source-Ausnutzens haben wir es geschafft, ein paar erste Zeilen Code in die Freiheit zu entlassen: dead simple reports, ein Rails-Plugin, das Reports generieren kann. Mehr dazu im neuen Bereich Open Source

We just encountered a bug in one of our rails applications where we had accidentally used some_mode.delete instead of some_model.destroy. I think delete should not be a public method on ActiveRecord. After all it’s just some evil means to circumvent all those rails callbacks and stuff to gain some more performance when deleting objects. It should be a protected method or something so that requires some effort (i.e. model.send(:delete)) to call it so you don’t use it accidentally when you actually want to call destroy.

In a previous post I wrote about how we wanted to pregenerate our packed assets simply by firing up a mongrel on deployemnt and request a page so it would generate the assets by calling the stylesheet_link_tag ... :cache => true and javascript_include_tag ... :cache => true methods in our application.rhtml.

It turned out starting and stopping a mongrel during development wasn’t really a good idea. We ran into all sorts of problems with deployemnts not shutting down the mongrel or not deleting its pid file which made the next deployemnt fails and stuff like that. Plus, to be honest, this really felt like a hack from the beginning.

So what we ended up doing was this: Write a small class that calls the methods to generate the all.js/all.css files and simply call that from our capistrano script. This is how it looks (config/assets.rb):
(more…)

We have been using haproxy as a load balancer for autoki (rails) for a while. The setup was relatively simple. We had two servers full of mongrels and one haproxy was simply throwing requests at them using round robin.

Now our requirements have gotten bigger. We have extracted the game into a separate application that is being deployed on its own server independently. The problem that we want to solve with this is that while we want to deploy changes to our servers whenever we want to, the game application has to keep running all the time without interruptions by a deployment and the problems that might be caused by it. Oh, and at the same time we didn’t want to change any urls. The game has been sitting in the external_games controller, so the url was autoki.com/external_games and since we have given this url to people we wanted it to stay the same.

So now we have a new server called external_games.autoki.com with 10 mongrels running on it and we want all requests to /external_games go there and everything else still go to the old servers. The solution to this is to let the load balancer decide which servers to forward the requests to. Since version 1.3 haproxy has implemented exactly this - and calls it content switching. To get thsi to work you have to tweak the haproxy.cfg file a bit. This is the old listen section with one pool of mongrels:

First we have split up our single proxy configuration into a frontend and a backend. We will actually be using two backends - one for gaming and one for the rest, and the frontend will decide which backend to use.

The rule to decide which backend to use is implemented using an acl. The following line creates a rule with the name game that evaluates to tue, if the url contains the string external_games. The haproxy documentation has a whole list of keywords you can use to match against all the contents of a http packet.

Now all we have to do is tell the frontend when to use which backend. We do this by defining a rule for the gaming backend and set a default backend for all requests not matching our acl.

That’s it. Now when we go to http://autoki.com/haproxy?stats we’ll see the two backends up and running. (only after adding stats enable to both backends actually)

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.