December 2007 Archives
Liz Cortell writes in with important updates to your time modules:
Whether travelling, calling overseas or maintaining software, time zones are always a headache. DateTime::TimeZone has seen a couple of changes this month.
0.70, released December 3, was changed to incorporate Hugo Chavez's declaration of a new time zone for Venezuela.
0.71, released today, "Fixes a major bug in the generation of time zone data. This bug affected any time zone that has more than one rule (most of them) and currently has no DST changes (many of them). An example would be America/Caracas. The symptom would either be mistakes about the current time zone or bogus exceptions when trying to create a local date."
The new say function isn't supported by the perl.vim file that ships with vim. Nick Hibma, the maintainer, tells me it will be updated in the next version of vim. In the meantime, you can hack your local vim files by adding the following line to your ~/.vim/syntax/perl.vim file:
syn keyword perlStatementFiledesc \ binmode close closedir eof fileno getc \ lstat print printf readdir readline readpipe rewinddir \ say select stat tell telldir write \ nextgroup=perlFiledescStatementNocomma skipwhite
Even if you haven't upgraded to Perl 5.10, you can use Jim Keenan's Perl6::Say module to add the say function.
My baby, ack, broke under Perl 5.10.0, because of a fix in regex behavior that I had been using unknowingly. See, I had always used my regex objects like this:
my $re = qr/^blah blah/; if ( $string =~ /$re/sm )...
when I should have been using it like this:
my $re = qr/^blah blah/sm; if ( $string =~ /$re/ )...
The bug in 5.8.x is that the /$re/sm would incorrectly apply the /sm modifiers to $re. This made the code happen to work, but for the wrong reason. What was especially tricky about finding my bug was that in 5.10.0, the call to /$re/sm ignores the /sm, but doesn't tell you that.
After some back and forth on p5p, a patch was submitted that gave the warning about the ignored /sm flags, but alas, Perl 5.10 was already out. It wouldn't have been so bad if it hadn't been the day AFTER it was released.
So, lesson learned: Test your code against new release candidates of Perl, both for your code's sake, AND for Perl's sake.
And y'know, now that I think of it, this is probably a great policy for Perl::Critic just waiting to happen. I wonder how many other people are doing their regexes the wrong way, too.
The first century starts at 0001-01-01 00:00:00 AD, although they did not know it at the time. This definition applies to all Gregorian calendar countries. There is no century number 0, you go from -1 to 1. If you disagree with this, please write your complaint to: Pope, Cathedral Saint-Peter of Roma, Vatican.
Users will inevitably complain that their items aren't sorting properly, and file bugs on these "errors".... [W]e programmers produce a weary sigh, and try to keep any obvious eye-rolling in check as we patiently inform our users that this isn't an error. Items are sorting in proper order. Proper ASCII order, that is. As we're walking away, hopefully you won't hear us mutter under our breath what we're actually thinking-- "Stupid users! They don't even understand how sorting works!"
Bravo for poking more holes in the tendency programmers have to think they know best.
dotfiles.org is a site that collects dotfiles for various shells and editors. If you've ever read someone else's .bashrc and said "Oh, THAT'S a cool trick", this is the site for you. If you haven't, now's the time to start. If you don't know what a dotfile is, or haven't modified the dotfile for your editor and shell, now is definitely the time to start.
Popular dotfiles include:
Leon Brocard posted this minimalist Apache configuration that covers Catalyst and FastCGI.
I keep seeing more people not using mod_perl. Leon calls mod_perl "very bloated." Thoughts?
If you're a programmer, you're writing programs for your users. You are there performing a service for your users, not the other way around. Here's an excellent way to insult your users by letting them know that they are not worth one minute of your time:
print "Now showing $n item(s)";
The parenthetical (s) as a shorthand for saying "This could be singular or plural and still let me off the hook" is a throwback to times before computers, when people worked on paper forms. It is now unacceptable.
my $s = ($n == 1) ? '' : 's'; print "Now showing $n item$s";
Is it a pain to write that out? Hardly. Maybe a twinge of discomfort at worst. However, to take the shortcut of (s) says that you are so lazy as a programmer that you don't care about the user, and it says that every single time the user sees that message.
I have one rule to documenting code:
- Why, not what: Explain why the code is doing what it's doing, not what it is doing.
Clearly this doesn't apply to code that is an API of some kind, where the code is the interface. Everywhere else, though, where the code is a mechanism to get the front-facing work done, explain the decisions that went into making the code do what it is.
Some hypothetical examples:
# Use port 3000 instead of 80 because that's what # Corporate is allowing us to use through the firewall. # Force this column to be a bigger font for Stan in Accounting. # Use Imager instead of Image::Magick because of # incompatibilities with frongdoodle mode in PNG images. # Can't use a JOIN here because MySQL 5.0's optmizer # makes a bad plan. This is supposed to get fixed in 5.1. See # http://wiki.mycompany/MySQL_optimization_problems for the details
Note how all these examples explain something that may be out of the ordinary, or make the next reader (maybe even you) think "What the hell was this guy thinking?" A well-placed, well-written, well-thought-out comment will make the reader say "Aaaah, THAT'S why it's like that!"