As the careful reader might have noticed, we have added another RSS feed to the blog sidebar. Under the keiala product blog you can now see our commits to all our open source repositories on github. To make this possible I have used yahoo pipes for the first time. The pipe consumes the RSS feeds of all our open source projects on github, merges these into one, prefixes the titles with the project names and also truncates them, before wordpress consumes that pipe’s output and displays it in a sidebar widget. That’s what I call a real mashup. If anyone is interested, here’s the pipe.

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.

class Project
has_one :project_photo
end

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:

class ProjectsController
def new
@project = Project.new
@project.build_project_photo
end

def create
@project = Project.new params[:project]
@project.project_photo = @project.build_project_photo params[:project_photo]

end
end

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:

class Project
has_one :project_photo, :dependent => :destroy # the attachment_fu model

# a virtual attribute that saves a new photo in the photo model only when there’s a new file uploaded
def photo=(photo)
self.project_photo = build_project_photo :uploaded_data => photo unless photo.to_s.blank?
end
end

Now you can use a standard view:

< %- form_for(:project) do |f| -%>
< %= f.file_field :photo %>
< %- end -%>

And a standard controller:

class ProjectsController
def new
@project = Project.new
end

def create
@project = Project.new params[:project]
@project.save
end
end

(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):

#!/usr/bin/env ruby

# load rails
RAILS_ENV = ‘production’
require File.dirname(__FILE__) + ‘/../config/environment’

# print out a warning if the queue has 10, critical when 20 entries
warn_count = 10
fatal_count = 20
actual_count = PhotosUpload.count
error = 0

print “photo_uploads ”

if actual_count < warn_count
print "OK"
elsif actual_count >= fatal_count
print “CRITICAL”
error = 2
elsif actual_count >= warn_count
print ‘WARNING’
error = 1
end

puts ” #{actual_count} uploads in queue”
exit error # exit with the error code that is then interpreted by nagios

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):

command[check_photo_uploads]=/usr/bin/ruby /var/www/production/current/lib/check_photo_uploads.rb

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

define service {
host jobs1
service_description photo_uploads
check_command check_nrpe_1arg!check_photo_uploads
use generic-service
}

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)