Month: October 2008

Is learning Perl the hard way the easy way?

October 5, 2008 Advocacy 2 comments

Bruce Momjian, guru of PostgreSQL, has discovered the joys of Perl.

I have converted two of my most complex shell scripts to Perl; as shell scripts, they were slow and hard to maintain. The rewritten Perl scripts are 200-400 lines long (about the same length the original shell scripts) and 15-25 times faster because of the improved algorithms possible in Perl and reduced subprocess creation.

What was surprising to me was how he’d learned, via a book I’d never heard of before, Learning Perl The Hard Way. Has anyone in the Perl Buzz readership read it? Comments?

Please enjoy the new design

October 4, 2008 Uncategorized 5 comments

I like the new design so much more. Less yellowy and blocky. Thanks to Kelli Forbes for doing the logo. If you need design stuff, email her at kjfwsd-hotmail-com. Thanks also to Chris Larkee here at Barcamp Milwaukee 3 for helping me override the Movable Type templates, and showing me slick stuff in Firebug that I didn’t know it could do.

Hidden features of Perl

October 2, 2008 Perl 5 No comments

There’s an interesting little thread at Stack Overflow on Hidden features of Perl. Go on over and add your favorites.

Developer optimization redux

October 1, 2008 Community 1 comment

Users are crucial to open source projects. Without them we have no reason to release publicly, and without refreshing the ranks of developers with users who join the fold,
our projects die. Users are our customers, and we can’t afford to treat them poorly. When
a user wants to go the extra mile to help us as developers, turning him or her away is a grave misstep.

Here’s an example. Andrea discovers a problem in PHP’s
database handling, where calling a certain function incorrectly causes
a segfault. The bug isn’t a work-stopper for her, and the fix is simple: Call the function correctly.
Still, it’s a segfault, and she figures
the PHP folks will want to know about it. It also
doesn’t help her confidence in the tool that calling a
function incorrectly segfaults. Being a good
open source citizen, she decides to report the bug.

She’s already spent the time figuring out the problem, and she
reduces the code to a single, repeatable example, that
shows exactly how to make the code segfault. “This should
help them track it down,” she thinks. She’s spent an hour
on this detour in the middle of a project for work, but
knows that open source relies on bug reports to get things
fixed.

She dutifully checks bugs.php.net, and finds nothing that
matches, so she goes to submit the bug. Unfortunately, the
PHP site will only accept bugs against 5.2.6, instead of
5.2.5 that she is running. This leaves her with three
choices:

  • Upgrade to 5.2.6 on a test machine, and test out her problem. She knows not to upgrade a production
    box so cavalierly.
  • Find someone using a similar install to see if that person will test it for her.
  • Submit the bug against 5.2.6, effectively lying but not spending any more of her time.
  • Throw up her hands and say “Screw it, I’ve got work to do.”

That’s what happened to me, “Andrea”, the other day. I wrote about it in
a frothier Perlbuzz article the other day.
I wish that my frustrations with PHP hadn’t overshadowed my point about community building, so I’m trying again here.

What about the users?

My frustration in PHP’s approach, and they’re certainly not the only community to do this, is that the emphasis
is in optimizing the time of the PHP developer who has to deal with bugs. “Who wants to deal with bugs that
have already been fixed?” goes the logic. I imagine someone setting up the PHP bug database saying “We need to put something
up to make sure that we don’t get annoyed by bugs that have already been fixed.” I can understand that motivation.
As someone who answers questions in #perl about WWW::Mechanize all day, I can certainly empathize with not wanting
to deal with pointless comments.

And yet…

Nowhere do I see any discussion of how the user sees the interaction. I doubt anyone considered the reaction
of the user who is told “Sorry, you’re not able to submit your bug report that you worked to get together to send to us.”
Instead, debate about the original article is
from the point of view
of the beleaguered developer, having to deal with those darn users, contributing their bug fixes.

Yes, I understand that plenty of people submit bugs that aren’t bugs, or that have already been fixed. Perl’s bug reporting
system is wide open, and I’ve closed my share of tickets in RT that weren’t really bugs. But I’m OK with that.

How long does it take to close tickets that aren’t right? Compare that cost to the cost of
losing a valid bug report.
Or worse, alienating a potential friend of your project.

In everything we do when working on projects, we need to remember there are real users, real people at the other
end that are the core of what we do.