Archive for 2008

Ruby-on-Rails on Ubuntu 8.04

Friday, October 31st, 2008

Every time I build an Ubuntu machine I have to figure out all over again how to get it to work – so this time I’ll write the steps down!

Install the packages: postgresql, rake, ruby, rubygems, rcov, git-core

Update the RubgyGems distribution by running

sudo gem update --system

If you run gem now you’ll get the nasty looking error:

/usr/bin/gem:10:Warning: Gem::manage_gems is deprecated and will be removed on or after March 2009
/usr/bin/gem:23: uninitialized constant Gem::GemRunner (NameError)

You need to edit /usr/bin/gem and add an extra require:

require 'rubygems/gem_runner'

Install the Postgres driver:

sudo gem install postgres-pr

You’ll need to change where Postgres writes it’s socket file, if you leave things unchanged you’ll see the error:

No such file or directory - /tmp/.s.PGSQL.5432

when attempting to connect to the database.

Edit /etc/postgresql/8.3/main/postgresql.conf and alter the unix_socket_directory parameter:

unix_socket_directory = '/tmp'

Restart Postgres using the init script /etc/init.d/postgresql-8.3

You should be able to leave your pg_hba.conf file unchanged – it should already look like:


# Database administrative login by UNIX sockets
local all postgres ident sameuser
# "local" is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5

You need to create a database user, and give that user a password and create a database. As the postgres user:

createuser -lqs db_username
createdb -O db_username db_name
psql -c "alter user db_username with password 'db_password';"

In the last command above make sure you don’t miss the ‘;’ character, if you miss it the statement isn’t actually executed, you should see the command confirmed with ALTER ROLE.

In you Rails application database.yml you need to specify the database name, database username and password and the host (even if it’s localhost)

development:
adapter: postgresql
encoding: unicode
database: db_name
host: localhost
username: db_username
password: db_password

Posted in Linux, Ruby-on-Rails, Ubuntu | 2 Comments »

White screen after login to X on Linux (Ubuntu)

Friday, October 31st, 2008

Given it’s taken me a while to sort this I thought I’d write down what I did in case it helps someone else (it might help me again in the future too, I’m sure if it happens again I won’t remember what I did to fix it)

So yesterday I installed VirtualBox 2.0, removed VirtualBox 1.5.x OSE and its related dependencies, and probably installed a whole load of updates too – I really can’t remember exactly what I did – at the time it all worked fine but after I switched the machine back on today and logged in I don’t see my desktop just a white screen and the mouse cursor.

Hitting ctrl-alt-F1 gets me to a command shell, so the machine hasn’t locked up.

From struggling to get my ATI based card to work in the past I know that dpkg-reconfigure xserver-org reverts X to a very basic configuration so I tried that from the shell and then rebooted. dpkg-reconfigure xserver-org obviously had an effect as the screen resolution of the login screen dropped down but I still got the white screen.

Rebooting again and choosing the recovery option from the bootloader prompt I chose the “Try to fix X server” menu option – *try* to fix X – I like that although I didn’t find it funny at the time. Reboot, login in – still a white screen.

A Google search from another machine threw up suggestions to remove the likes of

~/.config/compiz
~/.gconf/apps/compiz

This didn’t help either, but thinking about it it may have done if I’d gone about things differently. X obviously isn’t completely broken as you can get the login screen and a safe session (see later) also works fully. I think only removing the above directories (i.e. not doing any of the above dpkg-reconfigure etc stuff) may have worked if I’d been in safe mode when I removed them, as it was X was running and I used ctrl-alt-F1 to get a shell. I suspect that when I issued the reboot command and X shut down it just rewrote the files with the same values in them.

Finally I stumbled on a blog post. I did something similar, logged in using a “Gnome FailSafe” session, reinstalled the ATI drivers – I just downloaded them from http://ati.amd.com/support/drivers/linux/linux-radeon.html rather than using EnvyNG – and re-enabled the proprietary drivers under “System -> Administration -> Hardware Drivers” menu (which if I hadn’t run dpkg-reconfigure xserver-org in the first place I might not have needed to do), rebooted and everything was ok.

If nothing else a “Gnome FailSafe” session is your friend, at least you can get online to find answers.

Posted in Linux, Ubuntu | 2 Comments »

Don’t write tests to test your code

Tuesday, April 22nd, 2008

Wisdom tells us what we should do, experience tells us what we should never do again

The theory goes that you should write tests to check the functionality of your code, then when you refactor your code or add new features you’ve got a safety net to check that what you’ve done hasn’t broken existing functionality.

The theory is good, but in practice it doesn’t work.*

If you write tests to test your code you won’t write your tests, at least you won’t write all of them and you’ll cut corners. Writing tests to test a piece of code you already have is tedious. You’ll end up compromising your tests. You won’t test the simple stuff, because, well it’s simple, what could go wrong? It may be simple, but that’s just the sort of thing you’ll change without a moments thought but somewhere that’ll have a consequence you didn’t think of. You might skip testing the obvious stuff, but what’s obvious to you isn’t obvious to the next person to look at the code. You won’t test the difficult stuff, because that’s too time consuming and you’ve tested most of the other stuff so you figure you’re fairly safe. You won’t test the stuff that’s ‘impossible’ to test. That safety net that makes you feel secure, the holes are too big – just when you really need it you’ll fall straight through it.

So don’t write tests to test your code, write the tests before you write the code. Write tests to drive the design of your code (TDD/BDD), write tests so you know when you’re done. Only write code to fix a failing test. Yes you’ll still find your tests becoming complicated and stuff that’s difficult or ‘impossible’ to test. Listen to your tests – they are telling you something about your design. And the great thing is at the end of it, a side effect almost, you end with that safety net that really does allow you to refactor or add functionality to your code.

I think TDD/BDD and automated acceptance testing has the potential to significantly change not only how we initially produce a piece of software but also more importantly how it is enhanced and maintained throughout its ‘working life’ and it’s that which is radically going to change the value the software can deliver to the business and so the test become crucial to the success of your business. More on that later.

* when blogging you’re suppose to go for big bold controversial statements aren’t you? ;-)

Posted in Agile, Behaviour-Driven Development, Test Driven Development, Unit Testing | 1 Comment »

Baby Steps

Wednesday, March 12th, 2008

Taking baby steps is often advocated for peoples adoption of Agile.

If you’re coming from a waterfall background there is a lot to take on when becoming Agile. To truly become Agile you cannot just blindly follow certain practices, you need to understand them so you can apply them appropriately, if you try to adopt all at once you’ll overload yourself, you won’t understand what’s having what effect, so yes, start by taking some baby steps but….

A few things I’d like to point out about babies:

  1. they grow up
  2. within a couple of years they’ll be walking, indeed running
  3. when learning to walk they are bold, almost reckless
  4. yes, sometimes they fall over, sometime they even hurt themselves, but they learn from it, stand up and try again

I also worry that by just constantly taking small steps you loose your point of reference, that every small step moves you such a short distance you cannot tell whether it’s moving you to success or to failure. Don’t be a frog in a slowly warmed pan of water, be the frog who is thrown in, you’ll be able to tell if it’s boiling and jump straight back out.

Posted in Agile | No Comments »