I’ve tagged the version 0.1.2 a few days ago and time has come to announce this :) .

A cool new feature made it’s way in this release which gives you the ability of concurrent jobs. In addition to this we’ve added a first, rough spec so it’s definitively a good one to check out.

But that’s not all. Together with the 0.1.2 release Stupid Background got it’s own webpage! Ok, I’ve to admit that it’s nothing special, just a drag&drop page made with iWeb, but this means it looks fine ;) . So have a look at the new pages, which you can find at: http://stupid.fetmab.net .

So long!

Thorben
FEtMab-Team

Bookmarks to:

Ok boys,

the last two nights I spent on an issue which seems soooooo weird to me, that I have to write about it. I don’t know if it’s because I’m, even after a year of Ruby development, still too much Java-minded and just don’t get the idea of Ruby’s class variables or if they are totally screwed up them self… Anyway, here is my story:

I tried to enhance the StupidBackground plugin a little. It should be possible to assign workers to a certain “runner”, so that it would be easy to have more than one background runner. Maybe one for your quick running tasks and one for the ones that take eons to finish.

Until tonight we stored the list of tasks a runner should run in a class variable of that runner. That worked out fairly good until I made the changes described above. After these changes the code runs somehow like this:

• Run “main runner”
• Check all Worker classes
• If a worker uses a different worker than the default one, start another worker and fork it away (via Daemonized)
• This forked away runner checks all workers again for the ones, using it
• After the fork the “main runner” continues with the worker checking and maybe forks away more runners, when needed.

That means there is a process which forks away more and more processes and there are class variables. To make a long story short: An awful idea! All the processes shared the class variables! Which led to a state where every runner ran every task. As I said before, it took me quite a while to debug this, but finally the guys from #ruby-de on irc.freenode.org bailed me out.

So if class variables are the problem, was is the solution? Instance variables! Pretty good idea, but what to do in a class context like:

1
2
3
4
5

  class Blah
    def self.foo
      #what to do here?
    end
  end

As I said before my mind is still polluted with Java so I forgot about an important fact at this point: Class is a full-fledged object. So there would be no problem with using instance variables in this context. Ok, you have to understand that those instance variables are not accessible as an instance variable in the instance context of this class but I think this is comprehensible.

But I’m still astonished that the following is possible:

1
2
3
4
5
6
7
8
9
10

  class Blah
    def self.foo
      @test_var ||= Array.new
      @test_var << @test_var.size
    end
  end
 
  p Blah.foo # [0]
  p Blah.foo # [0,1]
  p Blah.foo # [0,1,2]

This might be not new to you if you really know Ruby, but if you’re just slowly getting to it from some other language such concepts might be hard to remember when you need them. But I hope with this post I can jog your memory :) .

Kudos to the guys at #ruby-de for the nice and quick help!

Yours,

Thorben
FEtMab-Team

Bookmarks to:

Today we realized that the project is evolved enough to take some time and think about how we can cache things efficiently.

One of the actions we were in doubt of most seriously is the action that responds to an AJAX call and returns you the position of the trucks that are rolling all over the map.

Some heave stuff going around in the background of this and even if anyone requests it only once in a minute, we wanted a caching solution for that, so that 100 users don’t do 100 requests that are handled by our application in a minute, but 99 requests that are fulfilled by Apache and just 1 which our application has to take care about.

The solution is pretty simple: Page Caching. Ok, this is not a big deal in Rails, but we had to expire the cache with a TTL of 1 minute or maybe 58 seconds. That is not included in the Rails caching mechanisms and even if there are plugins out there that can do exactly that, we decided not to get into them, because we would like to stay as closest as possible to the Rails “core” to keep the way for future colleagues, joining us with the project, very straightforward and not full of third-party-plugin-obstacles.

So: How can we expire the Rails page cache every minute? Hm… just delete the file that it has generated every minute! Cool! Ok, cool for one file whose name we know very well, but not so cool if we want to expire the whole cache. Why? Rails keeps all the generated pages of the page cache just in your public directory.

So public/controller/action.html might be the path to a cached page. This is ok, but wouldn’t it be nice to have something like public/cache/controller/action.html? It definitely would be much clearer and the expiration of the whole cache would be very easy, too.

And it’s really easy to achieve this! Most of the way you have to go is described here and here. But for us there was a little, tricky pitfall: Basically Josh Susser’s howto is great with all it’s Capistrano recipes etc. But as we’re using Apache as the frontend webserver the Rails Envy guy’s article fills the gap for the mod_rewrite modifications that had to be done. Ok, I must admit these changes (if you have a rewrite rule for the normal public/anything/else behavior already) are so minor that you can figure them out by yourself, so did we. But we made a dumb mistake:

This is the rule from the Rails Envy article:

1

  RewriteRule ^([^.]+)$ cache/$1.html [QSA]

But this assumes that your of the virtual host is like this:

1

  <Directory "/var/www/application/current/public/">

Our entry looked like this:

1

  <Directory "/var/www/application/current/public">

Aaaaarg! Just one daft, missing slash at the end ruined us the show with 400 - Bad Request errors whose source we could not determine. Sometimes the problem’s solution is as simple as just change the rewrite rule (or the directory entry in the way showed above) to this:

1

  RewriteRule ^([^.]+)$ /cache/$1.html [QSA]

Ok, pretty simple ;) . And now enjoy your moved cache and thank Josh and Gregg a lot for their posts!

One last thing to add: How do we delete the cache every 58 seconds? With StupidBackground of course ;) !

Yours,

Thorben
FEtMab-Team

Bookmarks to: