Ariejan.net

The best IT books hand-picked for you!

Are you ready to dive into Rails? Want to familiarize yourself with the deeper dungeons of Ruby? Are you an aspiring game developer? Or maybe you just want to learn how to use Git or Subversion effectively?

In any case, I’ve opened up a little book shop with a hand-picked selection of books on a variety of subjects, included Ruby and Rails, Game Development (with Java) and Version Control.

Please, feel free to take a look around. All books are priced the same as Amazon.com, and you’d be supporting Ariejan.net in the process.

I’m also open to suggestions for other categories with some hand-picked books. I’m already planning on Java and Databases categories. Feel free to post a comment with your tips.

Thanks for shopping a Ariejan’s Book Shop!

The migration that cannot be undone: Irreversible Migration

Migrations have up and down methods, as we all know. But in some cases, your up method does things you can’t undo in your down method.

For example:

def self.up
  # Change the zipcode from the current :integer to a :string type.
  change_column :address, :zipcode, :string
end

Now, converting integers to strings will always work. But, you feel it coming, converting a string into an integer will not always be possible. In other words, we can’t reverse this migration.

That’s why we should raise ActiveRecord::IrreversibleMigration in the down method.

def self.down
  raise ActiveRecord::IrreversibleMigration
end

Now, if you run your migration (upwards), you’ll see it being applied like it shoud. However, if you try to go back, you’ll see rake aborting with ActiveRecord::IrreversibleMigration.

$ rake db:migrate VERSION=4
-- Database is migrated
$ rake db:migrate VERSION=3
-- Rake aborted!
-- ActiveRecord::IrreversibleMigration

So, if you have things you can’t undo, raise ActiveRecord::IrreversibleMigration in your migration’s down method.

How to: Compile packages on Debian/Ubuntu by hand

In some very rare situations you may find yourself in the need to recompile a Debian (or Ubuntu) package. Luckily for all of use, the great Debian packaging system makes this a piece of cake.

Let’s say we want to recompile mod_python for apache 2 to hook in to python 2.5, instead of the default 2.4.

First, get every thing installed you may need to build the libapache2-mod-python package.

$ apt-get build-dep libapache2-mod-python

Okay, next let’s grab the source for the package. The source will be unpacked to your current working directory, so it may be a good idea to create a seperate directory for this.

$ mkdir src
$ cd src
$ apt-get source libapache2-mod-python

In the case of this example, you don’t need to do anything special to get python 2.5 linked. Just install the python2.5 and python2.5-dev packages.

If you need to apply patches to the source or need to make any other modifications, this is the time!

Okay, now go to the source directory and build the package. This is the tricky command here:

$ dpkg-buildpackage -rfakeroot -b

This will build the package. You will get some warnings and errors about missing GPG keys. This is okay. You are not the package maintainer, so your packages should not be marked as ‘original’.

You’re now ready to install your compiled package.

dpkg -i ../libapache2-mod-python-3.3.1-3-i386.deb

That’s all! You compiled and installed a package from source!

GIT: Using the stash

I bet the following has happened to you: you are happily working on a project and are in the middle of something. You are not ready to commit your changes, because you your tests don’t pass yet. Then your client calls with a bug report that needs to be fixed right now. (You know how clients can be.)

So, what do you do? Throw away your current changes to make the patch? Checkout a clean copy of your project to make the changes? No! You just stash your changes away, and make the patch! Afterward you grab your changes back and continue work.

Git features The Stash, which is as much as a good place to store uncommitted changes. When you stash you changes, the will be stored, and your working copy will be reverted to HEAD (the last commit revision) of your code.

When you restore your stash, you changes are reapplied and you continue working on your code.

Stash your current changes

$ git stash save <optional message for later reference>
Saved "WIP on master: e71813e..."

List current stashes

Yes, you can have more than one!!

$ git stash list
stash@{0}: WIP on master: e71813e..."

Note the {0} part? That’s your stash ID, you’ll need it to restore it later on. Let’s do that right now.

Apply a stash

$ git stash apply 0

You may notice the stash is still there after you have applied it. You can drop it if you don’t need it any more.

$ git stash drop 0

Or, you could apply and drop the stash in one motion:

$ git stash pop 0

If you want to wipe all your stashes away, run the ‘clear’ command:

$ git stash clear

It may very well be that you don’t use stashes that often. If you just want to quickly stash your changes to restore them later, you can leave out the stash ID.

$ git stash
...
$ git stash apply

Feel free to experiment with the stash before using it on some really important work.

Please leave a comment if you like this article, and would like to see more Git related stuff here on Ariejan.net.

Permanently redirect WordPress pages

After my trip to Mephisto some time back, I noticed that some pages were accessible from different URLs. After moving back to WordPress, these permalinks no longer work.

I’m running WordPress with Apache2, so it shouldn’t be too hard redirect those old permalinks to their new locations. (That’s what rewriting is all about anyway).

Here is the default .htaccess file generated by WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
 
# END WordPress

As I said, it’s generated by WordPress. It would be very unwise to edit this, because our changes might get lost in the future.

The solution is simple. Add another block above the generated one that does permanent redirects. In this example I rewrite pages/svnsheet to http://ariejan.net/svncheatsheet.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^pages/svnsheet$ http://ariejan.net/svncheatsheet [R=301,L]
</IfModule>
 
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
 
# END WordPress

FYI, the R=301 means the browser (or search bot) receives a “Moved Permanently” message. L means this is the last rewrite rule to read.

Of course, you can go nuts and add all sorts of funky regular expressions to rewrite URLs.

The nice thing is that WordPress will only replaces the block between the BEGIN and END tags, keeping your rewrites in tact.

Note: don’t forget to restart apache if your rewrites don’t seem to work.

Debian Etch: RMagick LoadError

If you’re on Debian Etch, you may encounter the following error

libMagickWand.so.1: cannot open shared object file: No such file or directory - /usr/lib/ruby/gems/1.8/gems/rmagick-2.3.0/lib/RMagick2.so

This basically means that the libMagickWand.so.1 file cannot be found. However, it is available on your system. All you need to do to fix it, is tell your box to look in the right place for the file.

To fix this issue once and for all, open up /etc/ld.so.conf.d/whatever_file_is_here. The whatever_file_is_here is named after the kernel you have installed.

In this file, add the following line at the bottom

/usr/local/lib

Save the file and next run the ‘ldconfig’ command. This will reread the configuration file you just edited. Now, restart your Rails app and you’ll notice the error is gone and all is good again.

ldconfig

This change will be kept after you reboot, so you won’t encounter this error any time soon again.

Enabling Trac Email notifications

If you’ve ever reported a but to Ruby on Rails, you’ll have noticed that their Trac has nice email notification feature. And I bet you want that in your Trac as well!

Now, email notification are nothing exotic. You don’t need any plugins, just an outgoing SMTP server and access to your trac.ini file.

In your trac directory open up conf/trac.ini and look for the [notification] header. Make sure you have at least the following settings. Of course, make sure you enter valid values for your situation.

always_notify_owner = true
always_notify_reporter = true
always_notify_updater = true
smtp_always_cc = trac-updates@mailinglist # Optional if you want to archive outgoing emails
smtp_enabled = true
smtp_from = trac@ariejan.net
smtp_from_name = Ariejan.net Trac
smtp_replyto = noreply@ariejan.net
smtp_user = 
smtp_password =
smtp_server = localhost
smtp_port = 25

There are a few more options like ‘ignore_domains’ if you don’t want to send emails to certain domains.

Update: good news for you GMail users! There is a ‘use_tls’ attribute. I think that if you set it to true, you can then specify GMail’s SMTP server to send out mails. Of course, a better solution would be to setup Postfix to relay mail to GMail, and just leave Trac to it’s default ‘localhost’ settings.

Rails Snippet: Caching expensive calls

In Rails, from time to time, you may encounter you have a method you call several times, but which returns always the same result. For example, have the following:

class Person < ActiveRecord::Base
  has_many :articles
 
  def get_approved_articles
    self.articles.find(:all, :conditions => {:approved => true}, :order => 'approved_on DESC')
  end
end

A query is fired every time you call Person#get_approved_articles. To cache the result of the query during this request, just add a bit of magic

class Person < ActiveRecord::Base
  has_many :articles
 
  def get_approved_articles
    @approved_articles ||= self.articles.find(:all, :conditions => {:approved => true}, :order => 'approved_on DESC')
  end
end

This will return the @approved_articles value if it exists. If it doesn’t, which is the first time you access the method, the query is run and stored in @approved_articles for later use.

Note: I know it’s much easier to define this kind of behaviour, but it’s just an illustration.

class Person < ActiveRecord::Base
  has_many :articles
  has_many :approved_articles, :class_name => "Article", :conditions => {:approved => true}, :order => 'approved_on DESC'
end

Here we go again: WordPress 2.5

Okay, here we go then. I’ve managed to drop Mephisto after only a few weeks of service.

As a Rails developer, I liked the idea of running my own blog on something Rails. However, Mephisto was a big disappointment. Especially compared to WordPress 2.5. Mephisto has been on life support for quite a while now, and it’s just too complex to be easy to hack. Now, don’t get me wrong. I love hacking Ruby, but not too much on my blog. It “should just work”.

The reason I skipped to Mephisto in the first place was that my Wordpress 2.3 blog was very slow. I managed to track down the problem to the Twitter plugin, which was next to useless anyway.

Now, with all the new funky stuff in 2.5, I switched back. I haven’t managed to write anything substantial in the past weeks anyway, so it wasn’t a problem to loose one post.

There are many reasons for my not posting substantial stuff lately. One of them being my new hobby: photography (link). Check out my Flickr page and let me know what you think of my more recent photos.

So long for now. Expect more from me soon.

Ruby on Rails plugin: Throttler

For those of you who have missed it: I’ve released a plugin yesterday that allows you to throttle your Rails app.

Read the original announcement and installation/usage instructions
Read how you can put Throttler to good use in your app