The next two days in Prague the things went more like they should :) . We had a nice first day with interesting talks. Unfortunately most of the talks were in a little bit “philosophical” direction. This IS interesting too, but it seemed to us, that nothing really new was said during that talks, so that the technical ones were more “innovative”.

Koichi’s topic was VERY interesting. Maybe it would’ve been cool, if he had the opportunity to speak something like the Netbeans tutorial. A longer, less philosophical, more detailed explanation of his work.

A very interesting talk of the first day was the lightning introduction to the “Agile Whiteboard” by Kingsley Hendrickse and his companion. This is actually a white board web application where you can pin notes (story cards) to a virtual whiteboard, drag and group them into categories. It may sound very simple but their implementation looked nice and really usable! So as far as we’ve understood there is no public version of this one now, but they will release it’s source in the near future. Maybe they should consider to make a “white board service” from that, too. There likely will be users who would pay for such a service.

Davids talk via Skype was nice, but philosophical, too. But what he said perfectly fitted into a Ruby conference! We thought it might be a little bit misplaced, beforehand. What turned out to be somewhat true during the Q&A session after his talk. As it wasn’t a talk about “hard facts” not many questions regarding the talk arose and it seemed, that the people didn’t really know what to ask him. Maybe this is a little bit surprising, as a quick poll during Matz’s talk showed, that around 90% of the participants come from a Rails background.

The day ended with a nice party.

I had a beer and Goulash (thanks again, Carsten) with the person who taught me the Rails basics, a professor at the University of Bremen, and we talked a while about the conference day, a Rails/Ruby user group in Bremen and many other things.

Sunday morning I delayed our arrival at the conference with my strong feelings against getting up on time. So we missed the first talk which, accordingly to Carsten, was a very interesting one. So if you feel like testing if your mocks represent the mocked objects correctly, you should have a look at Synthesis by George Malamidis.

Tomasz Stachewicz held an interesting talk about running things in background (mostly) in Rails. His solution is far superior to our StupidBackground, but the reason why he and we built our solutions seems to be the same: BackgrounDRB is too complex to use and run. So if you’re looking for accurate timed, background operations have a look at his project (no link, we’ve to wait till the slides get released). But if you just need a real simple solution with a nice, little DSL to define when things should run you definitively should have a look at StupidBackground ;) .

My favorite talk of the whole conference was the “Building Rails Playground” one by Petr Krontorád. They built a system, similar to Heroku but (different to what Jürgen suggested in his moderation of the Q&A session after the talk) we think that this system is better than Heroku! It has a nicer editor, access to the hosted projects via WebDAV and nice statistics. And: It’s a non-commercial project! They see themselves as a platform for beginners to start working with Rails. I’ve requested an invite to the system just after 2 minutes of the talk. Can’t wait to be accepted! A lot of kudos to this Petr and the rest of the team!

Unfortunately we had to leave after this talk and missed the last two talks which sounded really interesting, too (”Aspect Oriented Programming in Ruby” and “Lessons Learned Writing Native Extensions”). And maybe even more unfortunately we missed the rest of the lighting talks :/ .

But we should stop moaning! It was a great weekend and the organisators of the event did a GREAT job! We should say thank you to all the sponsors: SUN, ataxo, brightbox, CODE GEAR, Engine Yard, Unicorn College, Bit Nami, Dr Nic Academy, iQuest, Kraxnet, Nodeta and Skvělý.cz to help making such a great experience possible!

See you all next year somewhere in Europe :) .

Bookmarks to:

Hey folks,

we’ve just returned, after an adventurous journey over Geneva, from Prague and brought a lot of impressions back, to Germany.
After the Euruko 2007 in Vienna, last year, this was the second Euruko we attended and we think that it was a great success! The familiar spirit couldn’t be washed away by a quadrupled number of participants and so we had two days full of fun and information, a great combination. I’ve splitted our report up into two parts. This one is a narrative summary of what happened, before the conference has even begun and the second part will be a less narrative summary of our favorite talks and comments on the conference.

It shouldn’t take too long, till the first curious thing happened to us: Just arrived at the Prague airport, we took our luggage, and wanted to take the next taxi to our hotel. But as we were just checking how long the transfer to the hotel would take by bus or tram, Peter and Marianna asked if we are attending Euruko… It took a while, but I can’t imagine anything that roughly sound like Euruko so I had to believe that they really said “Euruko”. After he explained, that he remembered our faces from the last conference the situation was little bit more clear ;) . But then that: They were at the airport with Karel and waited for… *drum roll* Matz :) . Woah! Alright, we changed our plan: No more taxi, instead a public transportation ride with Matz to the city. Nice start of this weekend! But actually the plan was changed once again. Sebastian was hit by a nasty virus last week and still struggled a little, so after waiting for about 30 minutes we left, without Matz and the his reception committee by taxi. Strange first hour in Prague :) .

After we had checked in at the hotel, I discovered Prague on my own. After a delicious meal near the hotel it was already somewhat around midnight, but I thought that tough Rubyists would doubtlessly partying till the early morning, so it would be worth go to the party, even if I would be a little late. A long story short: There is a club in Prague called “Farbique” or somewhat like that. I was confused, that it isn’t possible to buy a tram ticket IN the tram and then walked all the way down town, where this club is located. I found it… but it wasn’t “La Frabika” ;) . So this was my party-night at Friday. I found a ticket machine in a metro station, took the tram back to our hotel.

Bookmarks to:

Hi,

we’ve been working on a Rails tutorial series in the last couple of weeks and the first of those articles has now been published.
Take a moment and head over to the guys from galaxy-news.net. We’re proud being asked for this tutorial by Galaxy-News and hope you like it! Please leave any comments, regarding this article, at the Galaxy-News comment section.

To the article!

Yours,

Thorben
FEtMab-Team

Bookmarks to:

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:

Hello there,

it’s late in Bremen, so I will keep this thing as short as possible: I just wasted the complete day’s work at Tansporter due to a bad preparation… dumb me! (Remember: Benchmark before any optimization!)

I tried to optimize some of our ActiveRecord find statements, installed a whole new column on a table solely for that reason, changed the model to fill this new column right and then changed the actual method I would like to spice up.

It was a 70 line monster of very ugly code. After refactoring it, there were just 40 lines left and it was very cool, clean and beautiful code. The main change: I replaced a find statement which returned a very huuuuge result set, which I had to iterate and do some computing on every element, with 4 very cool queries with just one result, each.

Sounds cool, but unfortunately it isn’t.

After I had a short “wow, that’s great stuff!” experience, I thought it might not be unclever to benchmark the new method and compare it to the old one.
And here comes the trouble: The old method finished in about 0.018 seconds, the new one needed somewhat between 0.54 and 0.4 seconds… What a pitty!

So I switched back to the ugly version, to my rescue the added column could be used elsewhere so my effort was not completely useless.

What I’ve learned: One query with a large result set apparently performs MUCH better than 4 (not absolute trivial) queries with a very small result set, even if you have to iterate through the whole big result set.

Anyway I stumbled upon two cool, small things today that are worth mentioning them:

1st: Get a random “thing” out of the database.

Until today we managed this with a method at the particular model looking somehow like this:

1
2
3
4
5
6
7
8
9
10

  def self.random_good
    good = nil
    while (!good)
      begin
        good = Good.find(rand(Good.maximum(:id)))
        rescue ActiveRecord::RecordNotFound => e
      end
    end
    good
  end

Today I received my copy of The Rails Way and one of the first things I found was the native, MySQL “ORDER BY RAND()” function. Pretty cool. Because database portability doesn’t really matter for us, the same function as above now looks like this:

1
2
3

  def self.random_good
    Good.find(:first, :order => 'RAND()')
  end

2nd: Don’t forget about the power of ActiveRecord’s :include option!

The :include option of a find statement is very powerful! I read about this maybe a year ago, never needed it again and forgot about it. Today I rediscovered the veeeeery nice nesting capability:

1
2

  tickets = Ticket.find(:all, :include => [:user,
      {:operator => {:open_tickets => :user}}])

I can’t really believe it, but after this find statement you can do this:

1

  tickets.first.operator.open_tickets.last.user.nickname

…without ANY extra query! It’s all joined together in the one find query and still runs at a reasonable pace.

Ok, now it’s really time for me to go to bed.

Stay tuned,

Thorben
FEtMab-Team

Bookmarks to:

Hey folks,

just a short update on my Flock usage, I already posted about Flock in late December.

Even after some weeks of browsing Flock seems to be a good companion: Rare crashes on my Mac Book and the memory usage is at least remarkable better than with Firefox 2.x.

I recently gave Firefox 3 Beta 2 a try, too and it was ok. But without any really benchmarking it feels as if Flock is still more reliable and has less memory leaks than Firefox 3, so I decided to switch back to Flock.

This suits my plans very well, as I just gave up my “social network antipathy” and registered a profile on Facebook. Flock is definitely the browser of choice for all this  Flickr, Facebook, delicious stuff. I’m no heavy user of all of that but it’s nice that you can easily share links on delicious, even if you do it only once a day.

So, give Flock a chance, it’s worth it!

Yours,

Thorben
FEtMab-Team

Bookmarks to:

Hi again,

the time has come to “release” our first Rails plugin! *wooooooooah*

It’s mission is really simple: Do things “in” a Rails application periodically, in the background. Ok, sounds like a perfect job for cronjobs? Yes, it is. But let me explain this:

We are just two guys, coding all day long. Server administration is not our favorite sport and we do not have a cool admin guy to keep things going. Due to that, we once had a cronjob running which we didn’t monitor as we should’ve. The end of the story is, that our job was not executed for 2 weeks until we recognized it.

So, cronjobs may be just perfect, but we really don’t want the extra pain of monitoring an extra tool and keep the crontables up to date with every deployment and so on. Our solution:

StupidBackground

Ohhh yes my dear, there are plenty of Ruby and/or Rails tools out there that do that background job thing very well: BackgrounDRb, BackgroundFu and much more cool tools. But while some of these tools just are too much for our needs (BackgrounDRb), the other tools, which are simple enough, do not cover exactly what we wanted to do (BackgroundFu): Periodically call some methods which calculates things and then stores them to the database.

So that’s when StupidBackground comes into play.

It’s sooo stupid, that even 5 year olds should immediately know how to use it. But just in case your mind is somehow different to that of a 5 year old, I’ll try to explain it for you anyway:

1. Install it

script/plugin install \ http://svn.fetmab.net/svn/plugins/stupid_background/tags/0.1.1

2. Code your worker

Just create a new class in “lib/workers” which inherits from “StupidBackground::Worker” like this:

1
2

  class FiveYearOldFighter < StupidBackground::Worker
  end

Now just add some methods to this. When these methods are called by StupidBackground they are in a complete Rails environment created by “script/runner“. So feel free to use any models or whatever classes you like to use within your application. Like this:

1
2
3
4
5
6
7
8
9

  class FiveYearOldFighter < StupidBackground::Worker
    def fight(quantity, victory_chant)
      puts victory_chant if FiveYearOld.find(
          :all, :limit => quantity, 
          :order => "badass_rank DESC").all? {|five_year_old|
              five_year_old.fight
          }
    end
  end

Last open question: How can we configure how often we would like to fight 5 year olds? It’s easy:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  class FiveYearOldFighter < StupidBackground::Worker
 
    #THE NEXT TWO LINES ARE THE MAGIC!
    call(:fight).every(1.hour).with(20, "What a fight!")
    call(:fight).every(10.minutes).with(5, "Eaaasy one!")
 
    def fight(quantity, victory_chant)
      puts victory_chant if FiveYearOld.find(
          :all, :limit => quantity, 
          :order => "badass_rank DESC").all? {|five_year_old|
              five_year_old.fight
          }
    end
  end

To stay trained we now fight five 5 year olds every ten minutes and every hour we’re in the mood to fight 20 of them at the same time! Cool.

3. Start the background magic

Just one last thing to do:

rake background:start

And if you fought enough 5 year olds:

rake background:stop

Oh, and if you’ve forgotten if you’re right now fighting some 5 year olds try this:

rake background:status

That’s it. Pretty simple, but it is enough for our needs. Maybe this plugin is of some use for you.

Behind the scenes

StupidBackground uses the Daemonize library from Travis Whitton, tiny but great! This fact also means, that StupidBackground will not work on Windows machines.

The background behavior is realized via a stupid script/runner call, it’s not high sophisticated but again: it fits our needs.

The execution of the tasks happens in an non sophisticated way, too: StupidBackground just determines how long it is until the next task needs to be run, then sleeps this periods and then runs the job.

So if you have one job which should run in 5 seconds and another job which should run in 6 seconds, the first job runs in 5 seconds and when it’s finished the second job runs. So the intervals which you specify in a worker are not accurate enough for brain surgery… You have to see them as rough intervals which works, you guessed it already: great for us.

Any worker is just instantiated once! So if you would like to share informations between two jobs in the same worker you easily can. But be aware of unattended side effects, when one method saves information in an instance variable and another job reads it, even if it should not! The simplest way to get around this is to outsource any logic from your worker and then write two workers which both use the outsourced code.

If you would like to overwrite the initializer of the worker ensure that your initialize method takes one argument and passes this to the super initializer:

1
2
3
4

  def initialize(method)
    #your stuff
    super(method)
  end

Somehow like this.

Summary

• Periodically, task execution in a Rails application, in the background.
• No gems needed.
• No extra YAML or any other configuration. Anything is configured within your workers.
• One instance per worker, NOT per job.
• No threading if two jobs should run at the same time! Just waiting for one to finish, then starting the other.

Ok, I hope this is of some help for some of you. Feel free to add comments.

Yours,

Thorben
FEtMab-Team

Bookmarks to:

Hey folks,

I’m back from vacations. It was great, even if there was some snow shortage. We nearly all managed to get over the icy, artificial snow… nearly. On our third day’s last run my girlfriend felt unlucky and hurt her knee so bad she might needs an surgery. But she’s alright so this sounds a little bit more scary as it actually is.

Nevertheless our development is gaining some momentum this week as I get more and more back to work. The weeks before Christmas were awful. I missed no chance to get distracted from work and did not really made some progress.

But now things seems to go smoother and it is as the fun would come back to my work. Don’t know why, but it’s definitively a good thing.

I promised you some tech is coming back to this block with the presentation of our first two Rails plugins but this has to wait for some more days, but it’s coming… I promise you.

For now I can tell you something about where we are right now with the game:

I’m really looking forward to finish all of the pathfinding code this week, which means we’re really done with all of the “heavy” code. All what comes up next is not that heavy but not less important interface and minor gameplay work. That said, I hope to start the first private beta testing in February.. wow. It’s really exciting to see the project grow, even more with such a small team as we are.

Ok, before I spent anymore time telling you how cool we are, I should get back to Textmate and get this last pathfinding issues ultimately out of the door.

See you later!

Thorben
FEtMab-Team

Bookmarks to:

Ok ok … it’s time for some excuses! We’ve really neglected this blog for quite a long time but I promise to be back in the game starting in the early days of 2008!

Before we get back to blog business I’ll enjoy a ski holiday in Jasna (Slovakia) with my girlfriend and two friends of us.

Some general update: The game is doing some progress, it’s harder than we thought to fight this fight with such a small team that Sebastian and I are. But expect some more detailed news on this at the end of january.

Now to the main reason why I’m writing this (to less time to go in depth with all the progress we made since october): Flock.

I’m using a Mac now for quite some time and (like Duncan Riley) see Firefox wasting memory on a grand scale! After reading the post of Duncan in early november I installed Flock but soon went back to Firefox as I can’t find any of my beloved plugins like Firebug in the Flock Addon Repository.

Today I stumbled onto Flock again and thought: Hey, why did I never tried out the regular Firefox Repository?! So started Flock again, surfed to https://addons.mozilla.org/en-US/firefox/ and without any problem installed Firebug, GreaseMonkey and Co. I’m using a default of not accepting any cookies in Firefox and I’m using CookieSafe to allow cookies on a per site basis. It’s a pity that neither this plugin nor the Permit Cookies plugin are working with Flock out of the box. But after a while I found a plugin called Cookie Monster doing mainly the same as the two others mentioned before and this could be installed in Flock with no hassle at all. Cool thing.

So even if I’m quite the opposite of a heavy “Web 2.0″ user, not engaged in any social platform like Facebook, MySpace and so on, I really like some of Flocks features. The direct access to del.icio.us bookmarks, the integrated blog editor (where this post is written in) or the integration of Twitter and Flickr right into the browser are very promising to make my browsing experience a better one.

Ok, that’s all I want to say so long. Now time has to proof if Flock can keep this promises or if all these tools are just looking nice but deliver nothing more then their original web interfaces do. In addition to this I’ll have a look at the memory usage of this little beast.

Right now I switched my default browser setting to Flock. Let’s see how long this lasts.

Yours,

Thorben
FEtMab-Team

Update:
See this post for further experiences.

Bookmarks to:

While it is always good to have attr_accessible or attr_protected set in a ActiveRecord model class to protect it from abuse when updating any object of that class from the params of a Rails controller.

But what to do when you have that attr_accessible but you won’t let a certain action in your controller even edit all of those accessible fields. Maybe because you’re paranoid or just a think that an action should only be allowed to edit what they was invented for, there might be some good reasons.

We faced this problem lately and came up with that solution:

1
2
3
4
5
6
7
8
9
10
11
12

class ActiveRecord::Base
  def update_by_params(params, *fields)
    self.attributes = params.reject
        {|key,value| !fields.index key.to_sym}
    self.save
  end
  def update_by_params!(params, *fields)
    self.attributes = params.reject
        {|key,value| !fields.index key.to_sym}
    self.save!
  end
end

The update_by_params instance method on the ActiveRecord::Base class let you do something like this:

1
2
3
4
5
6

# ... in a controller ...
def change_password
  @current_user.update_by_params(params[:user],
      :password, :password_confirmation)
  redirect_to frontpage_url
end

And then the user won’t be able to edit his address with a hacked password change form, even if he is allowed to do so in his profile.

The method will save the object after the update. To handle errors on saving there are (as usual in Rails) two specifications of this method available, one with a ! at the end which just uses save! to save the object and one without the ! which uses save. So update_by_params! will throw an error if the save fails while update_by_params just returns false.

Have fun with that.

Yours,

Thorben
FEtMab-Team

Bookmarks to: