Code Syntax-Highlighting on Blogger

Any self-respecting coder will not blog about programming without proper code syntax-highlighting. If you use Blogger, I'll save you the trouble of googling... Good results here and here.

As mentioned in the above blog links, I too am using TextMate on OS X which has a nifty built-in 'export to HTML' which, when combined with TextMate's themed CSS, gives very nice looking code blocks. You simply select the code you want highlighted, export it from TextMate, and paste into the HTML editor in Blogger.

I saved the TextMate CSS into my blogger template, so now any <pre> tag will produce a pretty code block, and any pasted HTML code from TextMate will be blocked and colorized.

UPDATE:
Yet another (perhaps better) approach which also works quite well is a JavaScript project cleverly named syntaxhighlighter. I stumbled across this code when viewing RubyTips.org which uses this library. The feature that I really liked is that it puts some nifty links at the top of each code block that allow copy to clipboard, and options to view the code in a separate window. The only downside is that because it is implemented with RegEx's in JavaScript, for large blocks of code, it will likely slow things down too much to be useful. But for short blocks of code, it is really a nice solution! Next time I post some code to this blog, I think I will give it a try!

Ruby method return values

There is a generalization in ruby that the last expression evaluated will be the return value from a method if no explicit return is specified. The Ruby Pickaxe states in Chapter 6, "The return value of a method is the value of the last expression executed or the result of an explicit return expression."

Although this is generally true, it can bite you as this is not exactly the case.

For example, consider the following:

>> def test1
>>   a=5 if true
>> end
=> nil

>> test1
=> 5

That looks ok, and the return value of 5 shouldn't surprise you as that was the last expression evaluated. Now how about this (below)? What is the last expression evaluated here?

>> def test2
>>   a=5 if false
>> end
=> nil

>> test2
=> nil

Did you expect that result? I didn't. I would say 'false' is the last expression evaluated, so I would expect the return value to be false. But instead of false, I get nil.

Why? It would seem that expressions evaluated as the controlling expression of a conditional statement (if, unless, etc.) don't count as an implied return value.

Let's simplify this even more:

>> def test3
>>  if 2 > 3
>>  end
>> end
=> nil

>> test3
=> nil

So it would appear it doesn't matter. And again...

>> def test4
>>   if 3 > 2
>>   end
>> end
=> nil

>> test4
=> nil

Yep, ruby doesn't care about conditional statement controlling expressions with respect to return values.

Happy ruby'ing!

How to downgrade part of a yum repository

Backstory
(skip down to avoid the rambling...)

I've been running Zimbra 4.0.x/4.5.x on CentOS 4.x for over a year now on a couple different servers without a hiccup, although Zimbra will tell you that CentOS is NOT a supported platform. Of course, RHEL4/5 are officially supported. I dutifully ran each Zimbra upgrade (with full backup prior) and never had a problem, but for Zimbra 5.0, I decided to be cautious. Zimbra 5.0 was released on 12/31/2007 (really trying to be able to say it was released in Q4 '07). Clearly, Zimbra was in a bit of a hurry to get it out the door, and as it was a rather substantial upgrade, I decided to wait until at least 5.0.1.

Sure enough, shortly after the 5.0 release, the Zimbra forums started popping with upgrade problems, which was finally tracked down to a bad interaction with Zimbra and the version of perl (5.8.8) that comes with Red Hat Application Server and CentOS Plus. The stock version of perl is 5.8.5. After checking my Zimbra servers, sure enough, I had the CentOS Plus version of perl installed (not sure why I had done that, but the machines were installed a couple of years ago...)

Several people on the forums were using the following to force install, but that didn't pass the sniff test and would break the first time perl RPM was updated:

$ perl -MCPAN -e shell
force install Scalar::Util

Useful part of story (--nodeps is your friend)

My first pass at this, I thought I'd just remove the perl rpm, fixup the CentOS Plus repository to ignore perl and install the correct version of perl for Zimbra. So, I wanted to see what kind of dependency hell I'd be in if I didn't force anything:

$ perl -v
This is perl, v5.8.8 built for i386-linux-thread-multi
$ sudo yum remove perl
...
Transaction Summary
======================================
Install      0 Package(s)
Update       0 Package(s)
Remove     223 Package(s)

Hmm, plan B? Using 'rpm -e --force' is the quickest way to trash your RPM database, so I wasn't doing that. Fortunately, a more experienced user on the forums suggested just using rpm to uninstall perl with the --nodeps flag.

$ sudo rpm -e --nodeps perl

Nice, that got rid of perl-5.8.8 (also uninstall perl-suid if installed).

Then edit the CentOS Plus repository config to permanently ignore it's version of perl.

$ sudo vi /etc/yum.repos.d/CentOS-Base.repo
(insert 'exclude=perl*' under the [centosplus] section)

Now reinstall perl, and you are good to go.

$ sudo yum install perl
$ perl -v
This is perl, v5.8.5 built for i386-linux-thread-multi

Cleanup

Check for /usr/lib/perl5/5.8.8/ directory. It shouldn't exist, but if it does, you probably installed code from CPAN and need to reinstall the appropriate 5.8.5 code.