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.

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.

Javascript has two string methods (substr and substring) that appear to be identical at first glance; they both return a substring from a given string. So what's the difference? Their second parameters, while both numbers, are expecting two different things.

When using substring the second parameter is the first index not to include:

var s = "string";
s.substring(1, 3); // would return 'tr'

var s = "another example";
s.substring(3, 7); // would return 'ther'

When using substr the second parameter is the number of characters to include in the substring:

var s = "string";
s.substr(1, 3); // would return 'tri'

var s = "another example";
s.substr(3, 7); // would return 'ther ex'

For more information on string functions, checkout Quirksmode's guide.

A while ago when I was hacking around with working on an Event System I wrote a simple Javascript date formating script. The script translated something like '11-02-2008' to something like 'Monday, 2 February 2008' using the Javascript Date object and a few parseInts.

After a while, something seemingly random started happening: any date in September or October displayed the wrong day name. I soon traced my problem back to a call to parseInt().

var m = parseInt(month); // would fail if month was '08' or '09'

For some reason it was causing the months index to become 0. After a bit of Googling I found an answer. The function parseInt tries to be clever and guess which base you are using to convert your string to an integer. Although it usually defaults to base 10, when given strings starting with '0', it assumes that you are parsing an octal number (strings starting with '0x', it assumes hexadecimal).

parseInt('07'); // 7
parseInt('08'); // 0
parseInt('09'); // 0
parseInt('10'); // 10

A workaround is to always pass the radix to parseInt:

parseInt('08', 10);
parseInt('09', 10);

For more information, check out Mozilla's Developer Center.