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.

GitHub is out of beta so now we have moved our open source projects there. Actually they already have been there for a while but we have now split them into their own repositories. The upstream subversion will still be online for a while but new commits will only go to git. Apart from being hyped alot these days git can do some pretty cool things like committing only parts of a file or changing previous commits - well worth checking it out I’d say.

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)

Das klingt so gut, das machen wir auch: 37signals haben beschlossen, im Sommer nur 4 Tage die Woche zu arbeiten - nach 3 Tagen Wochenende ist man einfach entspannter, glücklicher ergo produktiver. Kreditkarten für alle und finanzielle Beteiligung an den Hobbys der Mitarbeiter - klingt auch nicht schlecht, aber so richtige Mitarbeiter haben wir ja gar nicht, da müssen wir uns was anderes überlegen.

Nach kurzer Wartezeit habe ich heute meine Einladung zum Betatest von GitHub bekommen und das erst gestern eröffnete public upstream subversion ins public upstream git repository kopiert. Man kann unser großartiges dead simple reports plugin jetzt also auch über git ziehen.

Der Einstieg in github war schonmal sehr angenehm. Um das erste Repository anzulegen bekam ich erstmal die benötigten Kommandos angezeigt und konnte die gleich in mein Terminal kopieren. Von den diversen git tutorials und screencasts ist bei mir leider nicht viel hängen geblieben, sodass ich git wohl erst im Laufe des Praxiseinsatzes richtig kapieren werden. Ein sehr spannender Ansatz bei github ist auf jeden Fall die Möglichkeit, bestehende Repositories zu forken und dann darin zu entwickeln. Statt also irgendwelche Patches an Open Source-Projekte zu senden, forkt man einfach nur noch deren Repository, werkelt darauf herum und kann dann ggf. die Änderungen in das Main-Repository hochladen.

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.

Es ist super wenn die Werkzeuge, die man verwendet mit einem wachsen. Deshalb bin ich von Ruby und TextMate begeistert.

Für die, die TextMate nicht kennen: TextMate ist ein TextEditor für OS X, der sich in meinen Augen durch zwei Besonderheiten als Entwicklungswerkzeug hervortut. Erstens die leistungsfähige Live-Suche, die alle Mausklicks zum Navigieren im Projekt überflüssig macht. Zweitens die wirklich mächtigen Skriptingmöglichkeiten, die ich wohl noch lange nicht erfasst habe.

Jedenfalls musste ich Rahmen der Internationalisierung eines Projekts alle Strings in eine Übersetzungsmethode von gettext wrappen. Also ggf. Texte in den Views in Inline tags und in doppelte Anführungszeichen zu packen. Das gewünschte Ergebnis sieht etwa so aus: <%= _("Zu übersetzender Text") %>. Die ganze Arbeit ist ziemlich stupide, ließ sich aber mit TextMate auf simples Markieren des entsprechenden Textes und das Drücken des Tastenkürzels ctrl+alt+t reduzieren.
Read the rest of this entry »