Surgical Words

A few years ago when I was learning XML, I struggled to understand the distinction between tags and attributes. I knew what they were, but couldn’t figure out when to use which one. In some instances, both seem appropriate. For example, take a customer record:

<customer>
  <id>4222</id>
  <name>John A. Doe</name>
  <address>123 Beech St., Anytown, USA</address>
</customer>

This is the type and structure of examples given in XML tutorials. However, one could also mark up the data like this:

<customer id="4222" name="John A. Doe" address="123 Anytown, USA"/>

So what, exactly, is the distinction? I realized the obvious after a day of thinking:

Can you have more than one of the item?

This means the first example is wrong. A customer can’t have more than one id, and this is the fatal flaw of the tutorials.

Depending on the complexity of our application, a customer could possibly have more than one name or address, but for the majority of basic database-structured applications, the all-attribute example above is more appropriate.

Regardless of how you go and write XML, be sure not to commit the mistake of differentiating between tags and attributes purely by how deep, or nested, the tag is.

In an application with multiple names and addresss, here’s how I would structure the XML:

<customer id="4442">
  <name first="John" middle="A" last="Calvin" />
  <address title="Home" street="123 Beech St." city="Anytown" country="USA" />
<customer>

Even while writing this example, I automatically started to break the address into tags for street and city. After a second, I realized: an address can only have one street and city.

It’s a hard habit to break.

Average time to complete a task: 3 days, 17 hours, 12 minutes.
36 out of 438 tasks were overdue when completed.
36 out of 438 tasks were completed ahead of schedule by more than a day.
366 out of 438 tasks were completed the day they were due.

I started using iGTD this summer. Blake, one of my co-workers, recommended it, and I’m glad he did. After half a year of use, I am immersed in the GTD philosophy — I can enter a task, get it off my mind, and complete it when I can.

iGTD has the added advantage of keeping an archive of all my tasks. I have wanted to do some data mining with this stored data for while, and I finally wrote an analysis tool that will open your iGTD database and give you some statistics about how you’ve done completing tasks. I have posted my results inside the cut. Hopefully, these numbers will be even better next year.

To use the tool, unzip it, make sure you have sqlite3-ruby installed, and find this line:

# Load the tasks from the database file
gtd = Gtd::Database.new('iGTD.sql')

Change 'iGTD.sql' so it points to the location of your iGTD database. Typically, this is in /Users/yourname/Library/Application Support/iGTD/iGTD.sql.

(more…)

The past two releases of the rspec_on_rails plugin in tarball form have been corrupt, affecting 1.0.5 and 1.0.8. Unzipping using the OS X unzipper gives you the error message “Folder does not exist,” and using tar vxzf yields the following error:

[trimmed]
rspec_on_rails-1.0.8/tasks/
rspec_on_rails-1.0.8/tasks/rspec.rake
tar: Child returned status 2
tar: Error exit delayed from previous errors


RSpec on Rails requires the same revision as the RSpec plugin, so not having a working released version of the plugin pretty much makes the whole thing useless to Rails developers.
A reasonable workaround until the next release occurs is to navigate to your vendor/plugin directory and run the following command (for RSpec-1.0.8):

$ svn export --revision 2338 http://rspec.rubyforge.org/svn/trunk/rspec_on_rails