michael galero

About 2 months ago, I switched from QWERTY to using the Dvorak keyboard layout. As an aside, the layout is called Dvorak because it was patented by Dr. August Dvorak - the upper left keys are NOT replaced with D, V, O, R, A, and K as some people have clarified with me (see Wikipedia article). The Dvorak layout was suggested to me by a friend who switched months earlier and I agreed after some serious deliberation. But this article is not about the deliberation, rather how well it is going so far…

Last weekend, I reached over 60 wpm in a typing test. This is still below my QWERTY stats of an average speed of 65 wpm and a burst speed of 95 wpm. But it is going surprisingly well and generally pleasant.

To learn Dvorak, the process I followed was quite simple. For 2 weeks, I trained for about an hour a night by working on the exercises in A Basic Course on Dvorak. I just ran each lesson there twice. Outside the training, I still used QWERTY. After finishing the course, I made the full switch and avoided QWERTY almost entirely. I no longer used training tools, except every weekend to track my improvement.

My typing speed improved steadily until about 50 wpm. At the end of the 2-week training, it was a little over 20 wpm. I reached 30 after a week, 40 after another, and then 48 wpm. It slowed down significantly since then. With 60 wpm today, I improved only by 12 wpm after 4 weeks. But I’ve reached my targets so far by improving by 10 wpm until 40 wpm, the minimum required typing speed for clerk-typists. I target to reach my old QWERTY average of 65 wpm by the end of the year.

It was only difficult in the beginning, and only frustrating when participating in chat conferences. For some strange reason, I had more chat conferences than usual (more than the 1st 9 months of the year). I also noticed that typing punctuations needed to be exercised to get used to them. Fortunately, punctuations are used regularly in programming. Also, it’s useful to have the Dvorak keyboard layout wallpaper to cheat.

I have very recently started practicing Behaviour-Driven Development (BDD) using RSpec on Rails. RSpec is a framework “to describe the behaviour of Ruby code with readable, executable examples that guide you in the design process and serve well as both documentation and tests” (definition taken from the RSpec project home page). A programmer practicing BDD goes through cycles of describing a behaviour, writing the test for it, before finally writing the code to implement it. If you need more introduction to BDD and using RSpec, head over to Rails Envy for a good presentation on this.

In that presentation, Gregg Pollack mentioned that it’s good to have tests for every line of code. I’ve been thinking about that and while writing a particular RSpec example, I realized I just wrote something that tests… well… a code I should not write. Please consider this case I’ll describe.

Let’s say there’s a time-box called Foobar where a team needs to work on a list of tasks. Since it’s a definite period of time, the team has a limited number of manhours. The tasks defined in the list have estimated hours needed to finish it. That means tasks can only fit in the Foobar if their total estimated hours are within the limited number of manhours, right? Initially, this was thought to be the case. But it was later specified that the tasks’ estimated hours are only estimates, and so a requirement was added that the Foobar should be allowed to have a list of tasks where the total estimated hours exceed the total manhours available.

The RSpec example code could look something like this:

describe Foobar do
  fixtures :foobars
  ...
  # Testing for code you should not write
  it "should be allowed to have tasks where the total estimated hours exceed the Foobar period's total manhours" do
    foobars(:thirty_day_foobar).tasks<<(Task.new(:desc => "Task 1", :estimated_hours => 10))
    # This 2nd task has an estimate of 1 million hours.
    # You'd need about 1400 people working 24 hours-a-day for 30 days to do this.
    foobars(:thirty_day_foobar).tasks<<(Task.new(:desc => "Task 2", :estimated_hours => 1000000))
    foobars(:thirty_day_foobar).save.should be_true
  end
end

OK, I know I need to work on my RSpec writing skills but I hope you get the point. The behaviour example above doesn’t need any implementation code to work. It just works, and it prevents the web developer from writing validation code that will prohibit tasks from being added to the Foobar. It looks fine to me, but it would be good to get some feedback.

Slicehost, for the great VPS hosting. If you are currently in their waiting list, I suggest you get the 24-month prepayment. I got my slice in about a week. I think it’s better to pay for the long term than go to other hosting and pay about 3x more.

Wordpress, for the blogging platform. I planned on using Mephisto but… maybe in another post.

And Scribbish, for the theme. I wasn’t able to access Kenny Pitt’s blog for the Wordpress version (I only get a blank page), but thanks to Google’s cache, I got the download link: http://pittcrew.net/projects/scribbishwp/scribbishwp-1.0-3.0.tar.gz