Derek’s Diary

Last night, a small group of Ruby Montreal members met for the second Ruby Montreal Minga. Though there were just three of us in attendence compared with the eight who attended the first meeting, it was a more personal and focused meeting. We reviewed chapter 4 of the book Agile Web Development with Rails, Second Edition and started chapter 5. We plan to meet again in about two weeks to continue where we left off.

In case you don’t know, Ruby Minga is group of Ruby enthusiasts in Montreal who meet regularly to study Ruby programming related topics.

I just installed the Typo blog engine on my website in about 45 minutes, which included the time it took to configure the Apache proxy, but did not included content customization or migration from my existing blogs. Even though the installation includes an example Apache proxy configuration template, the proxy configuration took about 80% to 90% of the total installation time. However, installing Typo itself was practically a no-brainer:

$ sudo gem install typo
(answer a few yes/no prompts)
$ sudo typo install /var/www/typo

These two commands install Ruby on Rails (if it’s not already installed), Mongrel, Typo, SQLite3, and some additional Rails plugins. Starting Typo was equally painless:

$ sudo typo start
$ sudo typo start /var/www/typo
Starting Typo on port 4231
$ ps -eaf --width=2000 | grep typo
root 15286 1 5 15:41 ? 00:00:01 /usr/bin/ruby /usr/bin/mongrel_rails start /var/www/typo -d false -e production -P /var/www/typo/tmp/pid.txt -p 4231

The first time that you load the Typo blog URL into your web browser, Typo asks you to enter a user name and password, and then promptly takes you to the Administration page. The Typo Administration page looks pretty slick and provides options similar to those that Wordpress offers, but it’s far more responsive than Wordpress at Blogsome. I’m not sure whether this is because Typo is more performant than Wordpress or because Blogsome has misconfigured Wordpress or their web servers. In any case, my Typo is snappy!

Interestingly, this post took me about 45 minutes to write, or same amount of time that it took me to install Typo. Wow, that’s fast!

In Language Wars, Joel Spolsky advises development managers to heed the masses and build their next Web application using an industry proven programming language with which his or her team is most familiar.

I find two ironies in Joel’s argument. The most contradictory and amusing irony is that Joel does not follow his own advice: he developed FogBugz, his company’s flagship product, using Wasabi, a language that one of his developers invented in-house. Wikipedia knows the Wasabi GUI application framework in Winamp, but not the programming language. If Wikipedia has never heard of Wasabi, would you expect any programmers to know about the language?

The second and more subtle irony in Joel’s article is that despite calling the programming language debate a waste of time, Joel goes ahead anyway and adds to the debate! By denouncing the debate in advance, Joel vainly tries to shield himself from the criticism that he is wasting his readers’ time. However, if Joel truly felt that the programming language issue was a waste of time, after saying so, he would written no more. Instead, he fires the language war torpedoes.

So is the programming language debate just a waste of time? No way. After correctly specifying software requirements, making the right choice of programming language(s) in a project can lead to significant gains in productivity. This gain may be due to the strengths of the language itself, but more often, it is a result of the runtime environment, frameworks, toolset, mindset, support, and community that accompanies a language. So, discussing the merits of existing programming languages will lead to the development of new languages with unique features that more effectively help programmers solve new or exisitng problems.

Joel should have advised his friend to evaluate several languages and environments, compare them using custom criteria, and choose the one that best matched those criteria. Sadly, I find that most development managers, like Joel, are quick to dismiss alternative programming languages in favour of the market dominant or most popular programming environment. Often, this is not because the language is better, but because those managers have no experience or knowledge of any other programming language. We see IT managers exhibit this same behaviour when they choose the familiar and market dominant Windows to run on their computers while rarely even considering the alternatives. The solution? Teach IT students how to use many programming languages and operating systems. That way, when they become managers, they’ll be better equipped to choose the one that best suits a given project or task.

Further reading:

• Loudthinking: Fear, Uncertain, and Doubt by Joel Spolsky
• Loudthinking: Was Joel’s Wasabi a joke? (Update: Nope!)
• Readers on comp.lang.ruby respond to Joel’s article in Joel Spolsky on languages for web programming.
• In From Java to Ruby: Risk, Bruce Tate discusses the risks of using Ruby instead of Java.

Very early this morning, inspired by an article on the Philippines Ruby Users Group mailing list, I started experimenting with RMagick, a Ruby programming interface to Imagemagick, an open source image manipulation toolkit. Using a slightly modified version of the image scaling script from the article, I was able to reduce all of my bloated Philippines travel photos to one quarter of their original size.

I encountered two minor obstacles in trying to run the script:

• Installing the RMagick gem before Imagemagick. I used RubyGems to install the RMagick gem, but after my first attempt, I quickly learned that RMagick requires the Imagemagick package and its various library dependencies. Without these, the RMagick native extensions fail to compile. After successfully installing Imagemagick, my second attempt to install RMagick again failed because, as the RMagick configuration log file (config.log) reported, I was missing the freetype font library. After installing freetype, my RMagick installation completed successfully.
• Loading the RMagick gem. To get the Ruby interpreter to load the gem, the script must include the line requires 'rubygems'; you must specify -r rubygems on the Ruby command line, or you must assign string rubygems to environment variable RUBYOPT. The RubyGems User Guide explains in detail how to use one of these three environment options.

Once I managed to overcome these obstacles, I wrote a one line Bash script to apply the image scaling Ruby script to my images:

for file in Photos/Travel/Philippines/*.JPG; do sudo -u apache ./reduce_photo.rb $file; done

Et voila! Smaller Philippines photos!