michael galero

I’m not going to list down “improve Ruby skills” on my New Year’s resolution. With the newly released Ruby 1.9.0 (a development release) and beta book Programming Ruby 3 by Dave Thomas (or simply Pickaxe 3), what better time to dig deeper into Ruby than now?

When I setup Rails on my mac a few months back (before Leopard and Rails 2.0), I followed Building Ruby, Rails, Subversion, Mongrel, and MySQL on Mac OS X by Hivelogic. Following the Ruby part of that but updated for Ruby 1.9:

  cd /usr/local
  sudo curl -O  ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz
  sudo tar xzvf ruby-1.9.0-0.tar.gz
  cd ruby-1.9.0-0
  sudo ./configure --prefix=/usr/local/ruby-1.9.0 --enable-pthread --with-readline-dir=/usr/local
  sudo make
  sudo make install

I didn’t have to run ‘make install-doc’ because ‘make install’ already installed the documentation. Since I haven’t upgraded to Leopard yet, this has only been verified on Tiger. Running ‘/usr/local/ruby-1.9.0/bin/ruby -v’, I got

  ruby 1.9.0 (2007-12-25 revision 14709) [i686-darwin8.11.1]

Cool! And I just bought Pickaxe 3 (right after installing). Looking for the first 1.9 feature I can find in the book… a new hash syntax:

  $ /usr/local/ruby-1.9.0/bin/irb
  irb(main):001:0> inst_section = { cello: 'string', clarinet: 'woodwind' }
  => {:cello=>"string", :clarinet=>"woodwind"}
  irb(main):002:0> inst_section[:clarinet]
  => "woodwind"

It works! And let me just add that new hash syntax looks gorgeous. Now I have to end this article and try a 1.9 feature beyond mere syntax updates. Chapter 11: Fibers, Threads, and Processes looks like a good place to start…

Update 12/26/2007: I initially installed Ruby 1.9 on /usr/local. It installed rubygems 1.0.1 with it and messed up my gem installation for 1.8.6. I had to reinstall 1.8.6, and then reinstall ruby 1.9 in an isolated directory, /usr/local/ruby-1.9.0. I updated the article to use this directory. For now, I only use 1.9 to try the new features. If you need to work with multiple versions of Ruby, you might want to check out Dan Manges’ article.

From Toolman Tim’s blog entry Setting up a new Rails app with Git (with a few changes, and summarized for personal reference).

$ git init
$ mate .gitignore

Add in .gitignore:

log/*.log
tmp/**/*
.DS_Store
doc/api
doc/app
config/database.yml
db/schema.rb

Back to the command line:

$ cp config/database.yml config/database.yml.example
$ touch log/.gitignore
$ touch tmp/.gitignore
$ git add .
$ git commit -m "Initial commit"

Additional Notes:

• Git Tutorial Intro
• Git User’s Manual
• Everyday GIT with 20 Commands or so
• SourceMage’s Git Guide
• To manage edge rails, use Giston or just delete and re-export (taken from the comments of the blog entry).
• Touch empty dirs (thanks to Nick Poulden’s comment):

  find . \( -type d -empty \) -and \( -not -regex ./\.git.* \) -exec touch {}/.gitignore \;

This is a test post following an old TextMate screencast demonstrating the blogging bundle.

Continue reading…

Last Wednesday, I attended the 2nd Rails Coding Session of the Philippine Ruby Users Group (PHRUG). The small, informal gathering was planned for writing Rails apps with plugins like acts_as_solr, memcached, etc. None of us wrote a single line of code. Instead, we discussed several Rails and Ruby topics and gathered ideas for future Rails events.

Some of the topics discussed were:

• RESTful Rails
  
• DataMapper
• Rails and Legacy Databases
• BDD and RSpec
• Sinatra
• favorite gems and plugins
• Rails hosting experiences, particularly with Slicehost and Engine Yard
• teaching Rails to college students

The future Rails events planned are coding sessions (hopefully with actual coding involved), monthly meetups (with the next meetup probably in January and to be held at either the Ateneo de Manila University campus or Stratpoint Technologies office), and possibly a Philippine Rails Conference. Some notable issues covered were the challenges of organizing a large conference (including problems involved with having closed source companies as sponsors), and  problems with matching the level of explanation in your presentations with the knowledge of your audience.

The Rails community in the Philippines is only starting to grow. But I’m glad that the local Rails events are increasing in both frequency and number of participants. Previous Rails events I’ve attended are the First PHRUG Meetup last January, Rails Happy Hour last September, Rails Talk with the presentation by Guy Naor last October, and most recently this “coding session” (I missed the 1st Rails Coding Session 2 weeks ago).

Before I end this post, I’d like to thank Rad and the Development Executive Group for accommodating us for the session.

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