April 2008 Archives

Follow Perlbuzz on Twitter

| 1 Comment

I've created a Twitter feed for Perlbuzz. I'm going to start posting links there on cool things I find throughout the day, but that don't merit a full-blown Perlbuzz or Mechanix story.

Eventually I'll have all Perlbuzz and Mechanix stories posted there automagically, too.

YAPC::NA 2008 offers something for everyone

| No Comments

The schedule for YAPC::NA just got published, and there's plenty of good stuff this year. If you haven't decided to make the trip out to Chicago June 16-18 yet, this should help.

Cool stuff that jumps out at me as I peruse the grid: JT Smith talking about the premade application stack that WebGUI uses, Schwern on testing data with The Sims, and Kevin Falcone on timezone handling.

For the beginners, Kent Cowgill's intro to testing is a great way to get introduced to the topic, and I'm sure that Leonard Miller talking about Perl::Tidy and Perl::Critic will help instill good coding practices.

New this year, on Wednesday there will be workshops. Stevan Little will host a 2-hour Moose tutorial, and Jim Keenan will help you get started building and working with Parrot and Rakudo Perl.

Do you have recommendations on must-see talks? Let your fellow Perlbuzz readers know in the comments below.

Vienna.pm funds Jonathan Worthington to work on Rakudo Perl

| No Comments

From Thomas Klausner:

At the Oslo QA Hackathon 2008, during one evening meal, it became evident that Jonathan Worthington would be able to spend even more time hacking on Rakudo Perl if he would get paid a little money for it. As Vienna.pm still has some money earmarked for Perl development, we encouraged Jonathan to send us a proposal for funding him. Which he did. And which we accepted.

So starting next week, Jonathan will work on Rakudo one full day a week (minimum of 8 hours of work), post about the work on the rakudo.org blog / use.perl.org. He will recieve € 150 per day spend working on Rakudo. We estimate that on average he will work 4 days per month. We agreed on funding three months (~ €1,800) and evalute the grant after that time. If everybody is happy, we will continue the grant until the end of 2008, where we will evaluate again (and check if we still have money left).

More info available in the WoC Wiki.

Looking after your bugs with Request Tracker


Linux Magazine has a big introductory article called Looking after your bugs with Request Tracker. RT is the bug tracking system used for Perl 5, Parrot, Perl 6 and all the CPAN modules, at least by default.

WebGUI Users Conference announced for August 26-29, 2008

| No Comments

Plain Black has announced the WebGUI Users Conference this summer in Madison, WI. WebGUI is a GPLed CMS written in Perl with thousands of customers around the world, and gets 5,000 downloads each day.

Asciio lets you create ASCII charts graphically


Nadim has released Asciio, a Perl/GTK application that lets you draw ASCII charts using a GUI. Objects on the screen are sizable and have all the properties you'd expect in a drawing tool (titles for the boxes, bullets, etc), but the end result is plain text that's embeddable in your code.

Here's the first of two screencasts that give you a feel for its capabilities.

Nadim says "I find myself starting it quite often just to draw a little diagram that helps me write better Perl code. Then I can keep it in the code itself."

I wish I could use smart matching


We're nowhere near ready to switch to Perl 5.10 at work, even with the release of mod_perl to support it. I'd like to use smart matching all the time. Perltraining.au's put out an article about smart matching in its series of Perl tips that just makes me cry for what I can't use.

mod_perl now supports Perl 5.10

| No Comments

mod_perl 2.04 has been released and it supports Perl 5.10. If mod_perl has been a barrier to your uptake of Perl 5.10, there's no longer a reason to wait.

Perl is not going away


Sterling Hanenkamp wrote a great response to the now-infamous TIOBE Index article about how Perl is on its way out. This article is the sort of thing I wish I'd done when I was doing PR for The Perl Foundation. Sterling's given me permission to republish it here. Here's a link to the original. -- Andy (Lester)

I've been taking DDJ for a couple years now. It's cheap and occasionally has something interesting in it, but it's been less interesting than I remember it being when I read it in college. I've been much more enamored with the Communciations of the ACM. Today, I received my issue and there's an interview with Paul Jansen of TIOBE Software. In the article, he's quoted saying:

Another language that has had its day is Perl. It was once the standard language for every system administrator and build manager, but now everyone has been waiting on a new major release for more than seven years. That is considered far too long.

Note: This is such a cowardly use of the passive voice. "That is considered far too long"? BY WHO exactly? He's expecting us to swallow his unattributed assertion as if everyone considers seven years "far too long". -- Andy (Lester)

While I am biased, I have to admit that I disagree pretty strongly with Jansen's assessment. First, let me go into the problems with how he came to this conclusion and then explain why I think I'm justified trusting that Perl is in it for the long haul despite my bias that would have me think so anyway.

I want to first evaluate the way Jansen has collected the data he's used to make this statement. TIOBE puts together what they call the TIOBE Index. This is a rating of the popularity of various programming languages. The TIOBE web site claims, "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." How do they measure this? By performing a search for:

+"<language> programming" 

on 5 popular search engines, including: Google, Google Blogs, MSN, Yahoo!, and YouTube. That's it.

What they are measuring is not actual popularity, but the amount of hype surrounding each one. Not only are they measuring hype, but only hype that discusses "programming". What if everyone prefers to say "programming Perl is fun!" That wouldn't get picked up by the search they use. What about "Perl scripting"? Nope. Missed. (Here I should point out that Andy Lester appears to have been on to something when he gave his lightning talk about Perl programs versus scripts at OSCON last year.) In essence, this is, if they're disclosing the complete metric, incomplete. It's a shortcut that might be 90% right or 50% right. This is just poor statistics.

The second aspect of Jansen's comments I take issue with is the statement that there has not been a major release in seven years. That's not strictly true. Perl 5.10 has just been released and it includes new features like the new smart match operator. Beyond that, there has been some very active development on a closely related project, Parrot, and language development toward a huge milestone, Perl 6. Furthermore, where Perl truly shines is in all the development on CPAN. CPAN is getting large and complex enough now that we're having to rethink how it works just so we can find anything on it. This is a good problem to have.

This comment by Jansen does, however, serve to indicate a certain perception gap caused by the long wait for Perl 6. It's even been considered that the name of Perl 6 is harmful to Perl 5. This has been discussed out by others for some time.

In my opinion, Jansen is on shaky ground with his claims and probably only because he's not well informed by anything but his own metrics. I should think that he'd at least research the trends and issues facing the top 10 languages listed by his survey as to provide some better justification for it's accuracy.

As for the reasons I still have warm and fuzzy feelings toward Perl's future, I can list them off rather easily.

  1. I am participating in a number of growing projects that depend on Perl's future. Jifty and rethinking-cpan are just a couple I'm involved in. I can point you to several other vital projects that I use or am familiar with.
  2. I know of several companies actively pursuing Perl to develop core projects and continuing to train developers. This includes imdb.com, Socialtext, Best Practical, Six Apart, and several others.
  3. Recently, Google launched Google App Engine. This tool provides services to Python developers as part of the initial release. The top most voted for issues are first to add support for Ruby and second to add support for Perl, as of this writing.
  4. There's an average of 50 new and updated modules being posted to CPAN every day. That's not a small number.

I can probably come up with more, but now it's getting late, so I'd better end this thing. If Perl is going to die, it's got some years left before it happens. I think there will be enough activity to keep it going and increasing during those years rather than dying.

Oslo QA hackathon wrap-up

| 1 Comment

I'd been meaning to write up a summary of blog posts that people had written about the QA hackathon that happened in Oslo a few days ago. Fortunately, Adam Kennedy did it for me, summarizing what the QA thinkers decided, and didn't decide, in those few days in Norway.

[M]y main desire for the Oslo QA Hackathon was to sit a large percentage of the CPAN movers and shakers down in one place and try to iron out some of the inconsistencies around certain metadata issues. I'm happy to report that we managed to obtain either consensus or an agreement to not make a decision and take a "wait and see" approach on a number of issues.

Bonus points for him actually having been there, unlike me. Thanks to all of you for putting your heads together to forge some direction.

David Golden points out there's a much larger writeup of other activities from the hackathon on the Perl QA wiki.

The problem with "same terms as Perl" licensing


Shlomi Fish brought up an angle to the problem with slapping a boilerplate "same terms as Perl itself" at the bottom of your modules when you distribute them: Which version of Perl do you mean?

For me, I've used that line out of laziness, because I didn't care to think too much about specifics of the details. Now I'll be going back and specifying in my modules.

Open source is not piracy


Jeff Atwood's blog Coding Horror is one of my favorites. Until yesterday, I'd been recommending it unreservedly.

Jeff's made a big stumble, and I hope he corrects it soon, publicly. In his latest article, We Don't Use Software That Costs Money Here, he talks about how the free software alternatives to non-free software are getting better all the time. Unfortunately, he claims that

It's tempting to ascribe this to the "cult of no-pay", programmers and users who simply won't pay for software no matter how good it is, or how inexpensive it may be. These people used to be called pirates. Now they're open source enthusiasts.

He couldn't be more wrong. There is no equating software piracy, the theft and misuse of copyrighted software, with using open source, where the license specifically allows and encourages the redistribution of the software. Piracy violates the terms of the copyright and license. It's possible to do this with open source software as well, by not following the terms of the license.

In fact, there's no difference between open source software creators protecting their freely-licensed software from owners of non-open licensed software, such as the unfairly reviled Metallica, from protecting their works as well. When we applaud the Software Freedom Law Center for suing companies that violate the GPL, we should also recognize that owners of commercial software licenses should enjoy the same rights to protect their licensing terms as well.

I'm urging Jeff Atwood to correct his mistake. Open source software is nothing at all like piracy. Open source is about the license, not the financial cost.

Searching CPAN from Firefox


David Filmer posted a snazzy Firefox trick that puts a CPAN search in the search dropdown in Firefox. Works wonderfully.

Rethinking the interface to CPAN


I've started a group, rethinking-cpan, for discussing the ideas I've posted here. -- Andy

Every few months, someone comes up with a modest proposal to improve CPAN and its public face. Usually it'll be about "how to make CPAN easier to search". It may be about adding reviews to search.cpan.org, or reorganizing the categories, or any number of relatively easy-to-implement tasks. It'll be a good idea, but it's focused too tightly.

We don't want to "make CPAN easier to search." What we're really trying to do is help with the selection process. We want to help the user find and select the best tool for the job.

It might involve showing the user the bug queue; or a list of reviews; or an average star rating. But ultimately, the goal is to let any person with a given problem find and select a solution.

"I want to parse XML, what should I use?" is a common question. XML::Parser? XML::Simple? XML::Twig? If "parse XML" really means "find a single tag out of a big order file my boss gave me", the answer might well be a regex, no? Perl's mighty CPAN is both blessing and curse. We have 14,966 distributions as I write this, but people say "I can't find what I want." Searching for "XML" is barely a useful exercise.

Success in the real world

Let's take a look at an example outside of the programming world. In my day job, I work for Follett Library Resources and Book Wholesalers, Inc. We are basically the Amazon.com for the school & public library markets, respectively. The key feature to the website is not ordering, but in helping librarians decide what books they should buy for their libraries. Imagine you have an elementary school library, and $10,000 in book budget for the year. What books do you buy? Our website is geared to making that happen.

Part of this is technical solutions. We have effective keyword searching, so you can search for "horses" and get books about horses. Part of it is filtering, like "I want books for this grade level, and that have been positively reviewed in at least two journals," in addition to plain ol' keyword searching. Part of it is showing book covers, and reprinting reviews from journals. (If anyone's interested in specifics, let me know and I can probably get you some screenshots and/or guest access.)

BWI takes it even farther. There's an entire department called Collection Development where librarians select books, CDs & DVDs to recommend to the librarians. The recommendations could be based on choices made by the CollDev staff directly. They could be compiled from awards lists (Caldecott, Newbery) or state lists (the Texas Bluebonnet Awards, for example). Whatever the source, they help solve the customer's problem of "I need to buy some books, what's good?"

This is no small part of the business. The websites for the two companies are key differentiators in the marketplace. Specifically, they raise the company's level of service from simply providing an item to purchase to actually helping the customer do her/his job. There's no point in providing access to hundreds of thousands of books, CDs and DVDs if the librarian can't decide what to buy. FLR is the #1 vendor in the market, in large part because of the effectiveness of the website.

Relentless focus on finding the right thing

Take a look at the front of the FLR website. As I write this, the page first thing a user sees is "Looking for lists of top titles?" That link leads to a page of lists for users to browse. Award lists, popular series grouped by grade level, top video choices, a list called "Too good to miss," and so on. The entire focus that the user sees is "How can I help you find what you want?"

Compare that with the front page of search.cpan.org. Twenty-six links to the categories that link to modules in the archaic Module List. Go on, tell me what's in "Control Flow Utilities," I dare you. Where do I find my XML modules? Seriously, read through all 26 categories without laughing and/or crying. Where would someone find Template Toolkit? Catalyst? ack? Class::Accessor? That one module that I heard about somewhere that lets me access my Lloyd's bank account programtically?

Even if you can navigate the categories, it hardly matters. Clicking through to the category list leads to a one-line description like "Another way of exporting symbols." Plus, the majority of modules on CPAN are not registered in the Module List. The Module List is an artifact a decade old that has far outlived its original usefulness.

What can we do?

There have been attempts, some implemented, some not, to do many of these things that FLR & BWI do very effectively. We have CPAN ratings and keyword searching, for example. BWI selects lists of top books, and Shlomi Fish has recently suggested having reviews of categories of modules, which sounds like a great idea. I made a very tentative start on this on perl101.org. But it's not enough.

We need to stop thinking tactical ("Let's have reviews") and start thinking ("How do we get the proper modules/solutions in the hands of the users that want them.") Nothing short of a complete overhaul of the front end of the CPAN will make a dent in this problem. We need a revolution, not evolution, to solve the problem.

Call for grant proposals, 2008 Q2

| No Comments

The Perl Foundation is calling for grant proposals for Perl-related projects. This can be a great way to get funding a project you're working on, or would like to see worked on. TPF has funded Strawberry Perl, Perl::Critic, pVoice and dozens of other projects in the past. Maybe yours can be the next.

Perl is back at OSCON 2008

| No Comments

The schedule for OSCON 2008 has just been announced, and the Perl track is back with a vengeance. Last year, our favorite language seemed to be falling out of favor with five tutorials and nine sessions. This year, it's five tutorials and fifteen sessions. Tim Bunce's DashProfiler and Eric Wilhelm's Stick a fork() in It: Parallel and Distributed Perl are the two that jump out at me.

I won't be speaking about Perl. Instead, I'll be talking about Just enough C for open source projects and part of Michael Schwern's tutorial-length People For Geeks extravaganza.

« March 2008 | Main Index | Archives | May 2008 »