[Goldeye]

To get a very accurate reading of speed from encoders requires interrupts, as you're very likely to be recieving more than one click per 26.
You could count the number of clicks per a known time period, or time period per click. In both cases, you need to have an interrupt fire when the encoder sends a signal. Kevin Watson's interrupts package at kevin.org gives an amazing example of how to do this.
Once you know clicks/time or time/click, you can make a ratio of distance/click (d = 2 pi * wheel_radius / clicks_per_rotation) and compute it.

If you want to do clicks/time, the simplest way is have an interrupt increment a counter for each side, and then use the default loop for timing. The default loop runs approximately every 26.2 ms, so the speed for each side would be counter/.026 in clicks/second. (You probably want to use milliseconds to avoid decimals.) However, that 26.2 milliseconds is not always accurate, so you may instead want to use a timer that is guaranteed to run at a certain rate. See Kevin Watson's interrupts example for how to use timers. Using a timer, you can instead take readings over some arbitrary time period, say, 25ms, and be almost guaranteed of the 25ms.

This year, we chose to do it a bit differently, we only had about 4 clicks per 26.2ms loop, giving us an awful precision. We considered computing every 2-4 loops, but instead settled on measuring the time between clicks. To do this, set up a timer considerably faster than your encoder will send values. (We chose .5ms or 1ms, I believe) and incremement a "clock" for each encoder every time the timer fires. Then, when the encoder sends a value, save that time to an array. 1/that time is the clicks/time, which again derives to the velocity.
However, this method has some problems. Firstly, if you don't get a reading for a long time, you're stuck with your old ones. To avoid this, simply assume that you're going at least as slow as 1/clock if the clock is considerably bigger than the past few readings. Also, this method can give somewhat inaccurate, noisy readings. We found it necessary to average a few readings, and discard ones that are very far off from the last one. In the end, it all worked out and we ended up with a solid PID controller functioning off of this velocity reading. (However, this controller was not set up to go backwards. To drive backwards, we just switched the sides of the sensors and outputs.