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.

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)

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)

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.