It has almost been a week since I got my iPhone and the novelty still hasn't worn off; the device is just too useful .

Just the other night I was getting coffee with Kristen and some friends when we were wondering where the term Spider (as in the drink) came from. Out came the iPhone and Wikipedia with it. Curiosity quenched.

Few things compare in everyday utility to having the Internet in your pocket.

I got a brand new 16GB iPhone this afternoon (this message was posted from the iPhone).

A couple of weeks ago I deployed my first Rails app; The Claptrap site .

Firstly, a bit about Claptrap: Claptrap is a radio show in Brisbane, Australia airing Sunday mornings on 4ZzZ 102.1FM. It's funny as hell and I recommend it to anyone who lives in Brisbane and/or has the internet (anyone reading this would have to fall into at least one of those categories).

As I said before, the Claptrap site was developed using Ruby on Rails and was a great project to give me something practical with which to learn the framework. There is still much to learn but Claptrap gave me a good start.

I was also trialling a new tool that was only pointed out to me recently: Unfuddle. Unfuddle is a project manager suite that let me keep track of every part of the project. The site tracks my tickets and milestones as well as giving me a central Git repository to keep my code in.

If you are in need of a laugh then check out Claptrap.com.au.

Nigel McBryde, a graphic designer friend of mine, has thrown his new design blog up on the net.

Nigels site will be an ever growing collection of designs and design tools. Whether you are into Photoshop, Illustrator, Inkscape, or whatever, it will be a site to keep an eye on .

I just read a very good article over on Coding Horror that included a rather insightful anecdote (originally from the book 'Art & Fear' by David Bayles and Ted Orland).

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Although it may be obvious, I think it needs saying again; Quantity always trumps Quality. Why? That's easy. Everybody Most people learn from their mistakes so the more you make the more you learn. Quality comes from quantity.

Some writers/designers/programmers/whatevers might say that they don't need the process or the iterative approach but this is garbage (and more than a bit lazy). If you had a design that you thought was perfect in it's first iteration then think how much more perfect it could be after applying what you learned from the first draft. Ernest Hemingway rewrote the ending to 'A Farewell to Arms' 39 times. When he was asked about how he achieved such great works, he replied with "I write 99 pages of crap for every one page of masterpiece".

You can think long and hard about whether your way is the right way - whether or not it will work - but until you actually do something, you won't know. And even if it doesn't work, who cares? You can keep trying until it does. I think it was Edison who said "I never failed once. It just happened to be a 2000 step process".

In the end it comes down to the age old saying: practice makes perfect .

It's that time of year again and A List Apart is running it's survey for all website makers. Whether you are a designer, developer, information architect, project manager, writer, editor, marketer, or anyone else who dabbles in the web you should definitely participate.

I just added another wallpaper to my Deviant Art profile. It is a vector piece titled 'Winter Glow' and was drawn using Inkscape.



I'm not sure where the inspiration for this one came from; It is winter here but it isn't snowing and it certainly isn't glowing .

While having a chat with Keith about the meaning of the term 'syntactic sugar', he pointed out that my examples weren't strictly that. The methods times and each for numbers and arrays aren't technically syntax of Ruby, just things you can do with Ruby.

A more accurate example of 'syntactic sugar' would be something like this:

# this:
blah = Blah.new({:arg1 => 'something', :p => 'something else'})
# could be written like this:
blah = Blah.new :arg1 => 'something', :p => 'something else'

Braces and parenthesis are generally optional for method arguments and are normally only used to resolve which argument belongs to which method when passing methods as arguments to other methods. The syntax is so much cleaner when not having to include operators where their use is unnecessary.

Recently I started learning Ruby and I have to say: I can easily see it becoming my favourite language . Firstly, I would like to thank Keith Rowell for getting me to give Ruby a go and for helping me unlearn some tendencies learnt from other languages (ocassionally referred to as PHPisms and Pythonisms ).

Ruby is full of what many describe as 'syntactic sugar' and makes writing in the language a dream. For example, every number is an object and has methods:

# Will print out the word "hello" five times
5.times { puts "hello" }

Arrays (as with pretty much everything in Ruby) are also objects and have their own methods:

# Will print out the numbers one to five
[1,2,3,4,5].each { |n| puts n }

Ruby also comes with an interactive Ruby shell that you can test things out in. Just open a command prompt and enter 'irb'. You can then try out the two examples above and see what they do for yourself.

To learn more about Ruby stay tuned because I have a feeling that you will be hearing (or reading as the case clearly is) a lot more about Ruby from me. Until next time, you can read up on Ruby at ruby-lang.org and ruby-doc.org.

Are you using Git in Ubuntu and want to use an external visual diff viewer? It's easy! I will be using Meld for this example but most visual diff tools should be similar. If you don't already have Meld, then install it:

sudo apt-get install meld

Ok. Now let's begin by breaking it. Enter this into a terminal:

git config --global diff.external meld

Then navigate to a Git tracked directory and enter this (with an actual filename):

git diff filename

Meld will open but it will complain about bad parameters. The problem is that Git sends its external diff viewer seven parameters when Meld only needs two of them; two filenames of files to compare. One way to fix it is to write a script to format the parameters before sending them to Meld. Let's do that.

Create a new python script in your home directory (or wherever, it doesn't matter) and call it diff.py.

#!/usr/bin/python

import sys
import os

os.system('meld "%s" "%s"' % (sys.argv[2], sys.argv[5]))

Now we can set Git to perform it's diff on our new script (replacing the path with yours):

git config --global diff.external /home/nathan/diff.py
git diff filename

This time when we do a diff it will launch Meld with the right parameters and we will see our visual diff.