Testing is hard. Writing tests takes a lot of time, and running them can also be a pain in the ass. However, we have a few new tools in Rails toolbox, that can make it simplier and more fun. Much simplier and much more fun!

Let's start with Capybara

Capybara is a Webrat replacement. It does well what Webrat tried to do: gives you nice DSL for writing your Cucumber feature steps, without being tightnly bound to particular backend. With Capybara you can switch between Selenium and Culerity easily and painlessly. To install Cucumber with Capybara support, run the following from within your Rails project:

the last step will install Capybara itself, with a few additional libraries. You can now write your tests using nice Capybara DSL, for example:

and switch backends with simple configuration change in features/support/env.rb:

In fact you can switch between backends for different tasks, so it's perfectly possible to test part of your application which is web service with Webrat, and rest with Selenium or Culerity.

it's worth mentioning that Capybara works by default with Selenium 2.0 (not Selenium RC), a.k.a WebDriver, and will work right out of the box with it, provided you have Firefox installed.

Clearing database with DatabaseCleaner

Nice addition that Capybara includes by default is use of DatabaseCleaner. This nice gem, will clear your database, and what is cool, it works with MongoMapper as well as ActiveRecord and DataMapper.

To use it with MongoMapper, add the following to your features/support/env.rb:

Getting rid of annoying Firefox window

Cucumber with Selenium RC used to show and hide 2 Firefox windows at every scenario. Now, Capybara creates one window and is re-using it for all the scenarios. This is already better, but if you don't want to be annoyed with Firefox popping up on your desktop at all, you can hide it, if by some chance, you're on Unix-like system.

First, you'll need a Xvfb server:

Now, you can run your tests "headless":

Why is that so cool?

The setup described above works great with Ruby 1.8 and also with Ruby 1.9. Using WebDriver instead of Selenium RC brings nice performance improvements. DatabaseCleaner provides "transactional fixtures" to applications that use MongoMapper or databases that don't support transactions. Running your scenarios in Xvfb has the additional advantage, that you can do it on your server, integrate with CI server (say, Integrity) and do some cool stuff like creating a screenshot after every step... but let's leave that for next post!

Amazon SimpleDB is schema-free, non-relational database engine developed by Amazon and available as paid service as one of Amazon Web Services. It’s simple to use, fast and, combined with EC2 gives you great scalability out of the box.

One of biggest problems I had to face, when developing applications that use SimpleDB backend, is that I couldn’t run SimpleDB locally. No one can. It’s not available to purchase or download, you can’t do “apt-get install amazon-simpledb”. Using remote database for development is not a thing you want to do. It’s slow when used from outside of EC2 network. You probably need separate account for each of your developers. This sucks even more if you realize that you pay for running your tests… Hey, we want to run them as much as we can in BDD style – don’t want to be bothered by CPU usage it generates.

Solution to my troubles appeared to be M/Gateway’s M/DB. This is free and open source database, compatible with most recent (2009-04) API of SimpleDB, and you can run it on your own hardware. While it is possible to compile it from source, you probably need to pay developers for support on info how to do it ;). You won’t find also any packages for Ubuntu or Debian on the Internet (but if you do, please let me know!). The easiest way to get it up and running locally is to grab VMWare image and run it locally. Images and documentation how to set it up can be found on M/DB’s site. I run it on VirtualBox, which is my favourite among desktop virtualisation technologies, and have customized image a bit, but it’s equally easy to use it it VMWare. I’ll try to write detailed instructions on how to set up M/DB in VirtualBox some time next week on this blog. You also need to create 2 databases on your M/DB instance, and save access key id an secret access keys of those.

When you have M/DB installed locally, you need M/DB adapter for Ruby. Hey, didn’t I say it’s compatible with Amazon SimpleDB? So, existing adapters should work. Sort of.

The one I am using is Appoxy’s AWS combined with Appoxy’s SimpleRecord. First library is fork of abandoned RightScale’s AWS. I have made simple modifications to it, and now, you get M/DB support out of the box in master Git branch. You’ll need to manually build and install gem until nev version is released (which I show below). Second library is ActiveRecord pattern implemented on top of SimpleDB. Not as big, powerful and famous as Rails’ ActiveRecord, but good enough to provide object-oriented abstraction for your data for daily use.

To get started with these, install required gems:

# Until we have appoxy-aws version 1.11.36, we need to build gem manually:

$ git clone git://github.com/appoxy/aws.git
Initialized empty Git repository in /home/hubert/aws/.git/
remote: Counting objects: 377, done.
remote: Compressing objects: 100% (296/296), done.
remote: Total 377 (delta 198), reused 116 (delta 53)
Receiving objects: 100% (377/377), 167.74 KiB | 108 KiB/s, done.
Resolving deltas: 100% (198/198), done.
$ cd aws
$ gem build aws.gemspec 
WARNING:  no rubyforge_project specified
WARNING:  description and summary are identical
  Successfully built RubyGem
  Name: aws
  Version: 1.11.36
  File: aws-1.11.36.gem
$ sudo gem install aws
Successfully installed aws-1.11.36
1 gem installed
Installing ri documentation for aws-1.11.36...
Installing RDoc documentation for aws-1.11.36...

# in in future we'll just do:
# gem install appoxy-aws --source http://gems.github.com

# install simple-record
$ gem install appoxy-simple_record --source http://gems.github.com

Create your new M/DB Rails project:

$ rails mdb && cd mdb

Put these two lines in your config/environment.rb:

  config.gem "aws", :lib => "right_aws"
  # uncomment line below when version 1.11.36 is ready on github, and remove line above
  # config.gem "appoxy-aws", :lib => "right_aws", :source => "http://gems.github.com"
  config.gem "appoxy-simple_record", :lib => "simple_record", :source => "http://gems.github.com"

Now, you need to connect to your local M/DB instance when starting Rails. Edit your config/environment.rb to contain:

SimpleRecord.establish_connection(
  YOUR_KEY_ID_HERE,
  YOUR_SECRET_ACCESS_KEY_HERE,
  :mode => :per_thread,
  :server => IP_OF_YOUR_VIRTUAL_MACHINE,
  :protocol => "http",
  :port => 80,
  :signature_version => 2,
  :service => "/mdb/request.mgswi"
)

I advise you use app_config or AmberBit Config to use different keys for development and test environments, which will result in using different databases.

In order to check if your database is set up properly, let’s create a model “Brick”:

class Brick < SimpleRecord::Base
  has_attributes :weight, :color
end

There’s no migrations. To create table, for bricks, start up console and type:

$ ./script/console

Loading development environment (Rails 2.3.4)
>> Brick.create_domain
=> {:box_usage=>"0.0010000000", :request_id=>"eb4e3424-6371-89c4-330c-0c808d09ec52"}
>>

Hooray! Now, let’s see some more operations:

>> Brick.create(:weight => "1kg", :color => "red")
=> #, @attributes={"weight"=>["1kg"], "id"=>"1a9d944c-afaa-11de-9808-00a0d1a202b3", "color"=>["red"], "updated"=>[Sat, 03 Oct 2009 01:19:59 +0200], "created"=>[Sat, 03 Oct 2009 01:19:59 +0200]}, @new_record=false>
>> Brick.create(:weight => "0.5kg", :color => "brown")
=> #, @attributes={"weight"=>["0.5kg"], "id"=>"23111360-afaa-11de-9808-00a0d1a202b3", "color"=>["brown"], "updated"=>[Sat, 03 Oct 2009 01:20:13 +0200], "created"=>[Sat, 03 Oct 2009 01:20:13 +0200]}, @new_record=false>
>> Brick.find(:all).first.color
=> "red"
>> Brick.find(:all).last.weight
=> "0.5kg"

Cool, huh?

References

• Appoxy’s AWS
• Appoxy’s SimpleRecord
• M/DB
• Amazon SimpleDB

I have had some horrible time trying to get ffmpeg (and VLC) to output MP4 encoded with h264 video and AAC audio on plain Ubuntu 9.10. Problem is that FFMPEG doesn't have AAC encoders compiled in on this platform.

I started off with removing ffmpeg and installing it from source. Yeah. Don't try that unless you want to fuck up your whole multimedia system on Ubuntu. This is endless story, reqiures you to compile from source more and more libraries (x264dec, a52something...) and even then VLC couldn't compile from source as it was incompatible with these versions of libraries (x264 in particular).

What you (and I) should do is to re-compile only ffmpeg package and related. Thanks to Debian's great package manager, it is easy! Go check out my post on VLC forums to find out more: http://forum.videolan.org/viewtopic.php?f=2&t=65851

It’s not uncommon that you need to install multiple Rails applications on the same host. They all might use different versions of Rails, and you need to install all of them in order to keep your applications running. One of solutions is to install multiple Rails gem versions globally in the system. However, if you don’t have root access to the server, you are forced to install gems in your ~/.gems directory. This works perfectly well with mongrel, but it fails with Passenger.

Passenger can’t find Rails installed locally in user’s home directory. The only workaround I have found is to freeze rails gems.

Say you have Rails installed in: /home/hubert/.gems and your application sits in: /home/hubert/app

All you need to do is:

$ cd /home/hubert/app
$ rake rails:freeze:gems
$ touch tmp/restart.txt

Voila!

I have been using Ruby on Rails since the 1.1 release, and there have been more and less successful releases since. Rails 1.2 was amazing and brought us REST - most of us never looked back. However, the 1.2 series was still very buggy and was breaking backward compatibility several times between minor releases.

I wasn’t too much excited about Rails 2.0, particularly because it wasn’t backward-compatible and most of plugins had to wait for several months to be rewritten to work with 2.0. However, since then, Rails is evolving quite nicely and version 2.3 seems to be best you could ever get in Ruby web applications development. And here is why:

• nested model mass-assignment significantly simplifies building complicated forms. At the time of writing, it’s still a bit buggy when it comes to validation (in RC1), but that is about to change before final release.

• http digest authentication which is great news for everyone who build web services and need a bit more security in place.

• metal, using which we can finally bypass routing monster and save some milliseconds for “mission-critical” requests.

• overall performance boost, as pointed out by one of my friends. I didn’t see any benchmarks yet but overall feeling, especially with environment startup and running rake tasks is astonishing.

Now, let’s just wait for 3.0 revolution to come…

Using GPG

Alice wants to send encrypted message to Bob. Bob needs to generate key pair and send public key to Alice.

Bob:

# first generate key
bob$ gpg --gen-key

# then see if your key was added to keyring
bob$ gpg --list-keys
/home/bob/.gnupg/pubring.gpg
------------------------------
pub  1024A/BBE5BA2A 2009-01-14 Bob (Bob's GPG key pair) 
sub  1024g/38681206 2001-01-14

# now, export your public key and send it via email to Alice
bob$ gpg --armor --export bob@bob.com > bobs_public.key 

Alice reads her email, and saves bobs_public.key to disk. Alice:

# import Bob's public key
alice$ gpg --import bobs_public.key

# optionally see fingerprint and add to trusted keys
alice$ gpg --edit-key bob@bob.com
> fpr
> sign
> quit

 # let's encrypt some secrets
alice$ gpg --out secrets_for_bob.pgp --encrypt secrets.txt 

Now Bob when receives secretsforbob.pgp can do:

bob$ gpg --out secrets.txt --decrypt secrets_for_bob.pgp

bob$ cat secrets.txt
I love you!

Encrypting hard disks / pendrives / SD cards

Excelent example here

Zgodnie z obietnic?, kr�tka notatka jak za?o?y? Subversion na serwerze KWI z dost?pem przez SSH.

# zalogowanie sie na serwer
$ ssh username@kwi.pb.bialystok.pl

$ mkdir repos
$ cd repos

# stworzenie repozytorium
$ svnadmin create repo1

$ logout
Connection to kwi.pb.bialystok.pl closed.

I teraz mo?emy stworzy? podstawow? struktur? katalog�w repozytorium:

$ svn mkdir svn+ssh://username@kwi.pb.bialystok.pl/home/username/repos/project1/trunk -m "Tworze trunk"
$ svn mkdir svn+ssh://username@kwi.pb.bialystok.pl/home/username/repos/project1/tags -m "Tworze tags"
$ svn mkdir svn+ssh://username@kwi.pb.bialystok.pl/home/username/repos/project1/branches -m "Tworze branches"

Stworzmy jakis przykladowy projekt w C:

$ mkdir projekt
$ cd projekt
$ vim main.c 
# i wpisz jakas tresc
$ touch README.txt 
# pusty plik readme

Import projektu do repozytorium:

# b?d?c w katalogu projektu:
$ svn import . svn+ssh://username@kwi.pb.bialystok.pl/home/username/repos/project1/trunk -m "Poczatkowy import projektu"
Dodawanie       main.c
Dodawanie       README.txt
Zatwierdzona wersja 4.

$ cd ..
# usuwamy niepotrzebna poczatkowy katalog z projektem:
$ rm -rf projekt

# i pobieramy projekt z repozytorium
$ svn checkout svn+ssh://username@kwi.pb.bialystok.pl/home/username/repos/project1/trunk projekt
A    projekt/main.c
A    projekt/README.txt
Pobrano wersj? 4.

Voila! Mamy dzia?aj?ce repozytorium. Kilka komend do obs?ugi:

$ svn commit  .  -m "Wysylanie do repozytorium"
# pobieranie z repozytorium: 
$ svn up . 
# log:
$ svn log
# Dodawanie plik�w/katalog�? do repozytorium
$ svn add nowykatalog
# podobnie jak add mamy "rm"  do usuwania, "mv" do przenoszenia itd.

Rails 2.2 recently entered RC1 with loads of exciting features. Among built-in internationalization and bunch of other improvements, long awaited thread safety arrived. This was something that we (RoR users) were jealous when looking at Merb framework for quite a long time now.

Even if you are not using threaded server for your applications, and still use traditional mongrel/thin/whatever cluster, it’s good news for you. It’s even better if you use JRuby… but back to topic now.

Now, it’s easy to run long lasting tasks in your models for excellent description, look at Pratik Naik blog. It’s perfectly safe to write following code in your controllers now:

...

def create
  @post = Post.create(params[:post])
  Thread.new do
    @post.republish_content_on_some_slow_responding_sites
  end
end

...

However, I found thread safety even more useful for my recent project, with dRuby server running in the background. Now I can get rid of global mutex in my background process and enjoy one dRuby server shared among multiple server instances. I am running 5 instances of mongrel, each of them using heavily drb daemon which processes ActiveRecord objects - now I get 5x boost in speed with thread safe Rails :)

This might be useful for these present at today’s BGUL meeting, but not only. Basically, I have demonstrated how to develop simple script useful for sysadmins, that checks if web pages are up and running, and stores results in MySQL database.

Additional cleanup, error handling and comments added (in Polish, sorry).

Full code is here