It is with profound sadness that the University learned yesterday of the passing of Associate Dean of Science Randy Kobes. Dr. Kobes passed away after a recent battle with lung cancer.

Randy was an excellent academic, physicist and educator of young people. He was fully dedicated to public engagement in science. His contributions to community learning at The University of Winnipeg went far beyond the classroom.

Randy was a primary driver of the University's Let's Talk Science and was also keenly involved in the Eco-Kids programs, and numerous other outreach activities that involved inner-city children and youth. He was also the leader of numerous new degree programs in science, including Radiation Health and Safety; Science, Environment and Indigenous Knowledge; and pre-professional programs.

Randy was truly dedicated to student success. Almost all of his work efforts were directed to encouraging student success in one way or another. Along with the many initiatives mentioned above, he volunteered his time in the summer with the CSI (Community School Investigators), an inner city summer learning enrichment program and was very involved in the homework club at the Wii Chiiwaakanak Learning Centre. He also personally drove students to Sisler High School, where the University had established an off-campus homework club.

Randy obtained a B. Eng. degree in Engineering Physics from the University of Saskatchewan in 1978 and a Ph.D. in theoretical physics from the University of Alberta in 1983. He held postdoctoral fellowships at the University of British Columbia and at Memorial University of Newfoundland before joining the University of Winnipeg in 1987.

His research interests included the application of quantum field theoretic methods to topics in theoretical particle physics and investigating non-linear effects using numerical techniques. He held an NSERC Discovery Grant since joining the University of Winnipeg, and most recently served as the University’s Associate Dean of Science.

In June 2005 Randy was awarded the Marsha Hanen Award for Excellence in Creating Community Awareness. He founded the Manitoba chapter of Let’s Talk Science, which promotes scientific literacy by having University of Winnipeg volunteer scientists visit classrooms, present interactive experiments and raise awareness of science. In October 1999 he won the Erica and Arnold Rogers Award for Excellence in Research and Scholarship.

The big advantage of Git::Wrapper is that it wraps the binary version of git, which keeps your perl and git independent. Upgrade perl and not git? Add Git::Wrapper and you're done. Upgrade git while keeping your existing perl? No problem. If you get your git from an OS distribution package, but roll your own perl, then Git::Wrapper is for you!

Git::Wrapper just makes it really easy to pass git commands and get back useful data. It really shines on "git log" commands, as it parses each commit message into Git::Wrapper::Log objects with accessors for id, author, date, and message. For everything else, it's not much more than a wrapper around qx(), but it returns arrays of lines and throws exceptions when things go wrong, which just saves a little time and code.

Here is a short example that I whipped up recently to automate the process of adding a github repository remote for someone when they send me a pull request. (It also uses my Getopt::Lucid module, but as the name suggests, it should be clear what that does.)

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use autodie;
use Git::Wrapper;
use Getopt::Lucid qw/:all/;

# USAGE: github-remote [-r REPO] [NAME]
#     NAME -- a github user name (or defaults to 'dagolden')
#     REPO -- a github repository path (or is parsed out of my private origin repo)

my $opts = Getopt::Lucid->getopt([
  Param('repo|r'),
]);

my $who = shift @ARGV;

# Get a wrapper for the current directory
my $git = Git::Wrapper->new(".");

# Locate the origin repository URL
my ($origin) = grep { /origin/ } $git->remote("-v");
die "Couldn't determine origin\n" unless $origin;
$origin =~ s/^origin\s+//;
$origin =~ s/\s+\(.*$//;

# Parse out the repository path
my $repo = $opts->get_repo;
unless ( $repo ) {
  # me@git.example.com:my-repo-name.git
  ($repo) = $origin =~ m/^[^:]+:(.+)$/;
}

# Set up someone else's github repo
if ( $who ) {
  $git->remote("add", $who, "git://github.com/${who}/${repo}");
}
# Or set up my own github mirror
else {
  $git->remote("add", "github", "git\@github.com:dagolden/${repo}");
}

That's it. I admit the program is a little crufty because of how I manage my repositories with a private origin that I mirror to a github repository, but there's almost no cruft around interactions with git. Consider this:

  $git->remote("add", $who, "git://github.com/${who}/${repo}");

If the command fails (if there's already $who as a remote name), an exception will be thrown. That means I don't have to write any error handling myself, which is perfect for a simple automation program like this one.

Before the first edition of Programming perl, people commonly referred to the language as "perl", and its name appeared that way in the title because it referred to the interpreter. In the book, Randal Schwartz capitalised the language's name to make it stand out better when typeset. This convention was adopted by the community, and the second edition became Programming Perl, using the capitalized version of the name to refer to the language.

You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look good, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.

Those post-facto expansions are "Practical Expansion and Reporting Language" and "Pathologically Eclectic Rubbish Lister." Both are bacryonms, created after the language was named.

use List::Util qw( shuffle );
my @files = glob( '*' );
@files = grep { -f } @files;
@files = shuffle @files;

Of course you can combine that into one expression:

use List::Util qw( shuffle );
my @files = shuffle grep { -f } glob( '*' );

Or from the command line:

perl -MList::Util=shuffle -le'print for shuffle grep {-f} glob("*")'

Don't worry that List::Util is a module, because it's a core module that's been included with Perl since 5.7.3

$ corelist List::Util

List::Util was first released with perl 5.007003

The shuffle function is extremely simple, and how here's a little article that explains why it works.

Consider your privacy. Consider whether a company whose sole business purpose is to sell targeted advertising by extracting, sharing, and mining personal information from millions of people. (Do I mean Google or Facebook?) A fan of free markets and free information might say "Whether any individual finds that objectionable, an informed citizen should have the right to decide whether to participate."

The assumption is that citizens should be able to know what information the business shares, with whom, and why. It's easy to understand why. Even though it's funny to laugh at a petty criminal caught by posting a stupid update which gives the authorities reasonable suspicion of a crime, it's unsettling to imagine an abused and estranged spouse who's dutifully followed the guidelines for not allowing personal information to escape a hand-vetted circle of trustworthy family and friends fall victim to an unannounced, opt-out rule change which allows the abuser to perpetuate the abuse.

The parallel to Perl is subtle, but important. If you want to improve your software, sometimes you have to make incompatible changes (or learn how to predict the future, or write software so trivial that you always get it right the first time), but changing the world out from under users is irresponsible and unethical.

The difference between managing your privacy and safety in a world where mass communication is cheap and easy and between having to change the use of a long deprecated feature is vast, but in both cases there's a simple ethical concern: retroactive and arbitrary and unannounced and forced changes are wrong.

That's why My Contrarian Stance on Facebook and Privacy is very, very wrong:

[Let's] not make privacy a third rail issue, pillorying any company that makes a mistake on the privacy front. If we do that, we'll never get the innovation we need to solve the thorny nest of issues around privacy and data ownership that are intrinsic to the network era.

Don't let the shiny of the Internet hero de jure fool you. The technical world needs less "innovation". (I'll take less of the kind of "innovation" which suggests that if I didn't want to share information publicly last month, I suddenly want to this month without you even asking.) The technical world needs more grownups who don't get distracted by multibillion market caps, the inherent sexiness of enterprise software, and whatever His Jobs announces next week. The technical world needs people who treat other people ethically. If that means pillorying entities which act unethically, then so be it.

• CPAN Meta Spec version 2 — I released the final spec and will soon be looking to rally toolchain developers to implement it.
• CPAN Testers 2.0 — I launched CPAN Testers 2.0 Beta site, the eventual replacement for the current practice of sending CPAN Testers reports over email and I’m continuing to monitor it, tweak it and fix little bugs
• Perl 5 core development — I’m scheduled to be the release-engineer for Perl 5.13.3 in July. In addition, my goals for Perl 5.13 include getting HTTP support for CPAN clients into the core, simplifying CPAN configuration further and implementing CPAN Meta.
• Drafting a formal description of the expectations for Perl build systems that use Build.PL. Right now it’s only Module::Build, but it could be other things in the future. I’ve started a very rough draft of what cpan clients should expect Build.PL (and the resulting Build) to support.
• Dist::Zilla — I’ve been converting my distributions over to Dist::Zilla as I work on them. It’s a huge time saver for me (something I hope to blog about more later). I’ve also implemented some plugins recently: DZP::CheckExtraTests, DZP::BumpVersionFromGit and DZP::Twitter
• I converted the Module::Build repository to git to encourage more contributions and to make it easier to apply them. I released a development version, 0.36_08, with some recent additions.

Here are several other things released to CPAN in the last couple months not mentioned above:

• File-chdir-0.1003 — maintenance release for 5.13.X
• Acme-Module-Build-Tiny-0.04 — a half-serious replacement for Module::Build
• Version-Next-0.001 – increment module version numbers simply and correctly
• ExtUtils-CBuilder-0.2703 — better Windows support for MSVC
• Net-Amazon-Config-0.001 — simple utility to manage Amazon Web Services credentials
• CPAN-Visitor-0.001 — generic traversal of distributions in a local CPAN or minicpan repository
• Capture-Tiny-0.07 — the only output capturing program you should ever need

I unsurprising news, the default Perl 5 object system shows its limits in that you have to think about Perl 5 reference syntax and objects and encapsulation, genericity, abstraction, and polymorphism all at once. Moose encourages people to do the right thing by providing abstractions that encapsulate the concerns of other levels of abstraction. Inside-out objects did something similar.

I realized this yesterday when writing about the state feature introduced in Perl 5.10. If you're a fan of minimalist languages which provide one and only one obvious way to do things, you'll hate this explanation, but at least you'll know why you're wrong.

state declares a lexical variable which maintains its state even after control flow leaves its lexical scope. In other words, these two snippets of code are almost entirely equivalent:

# the closure approach
{
    my $count = 0;

    sub add_user
    {
        my ($user, %data) = @_;
        $data{user_id}    = $count++;
        ...
    }
}

# the state approach
use feature 'state';

sub add_user
{
    state $count      = 0;

    my ($user, %data) = @_;
    $data{user_id}    = $count++;
    ...
}

The one potential difference is that the initialization of $count in the first example must take place before the first call to add_user().

If you're careful to avoid that tiny potential trap, you can achieve the same effect with the closure code. Scheme and Python and even Java fans rejoice for a moment. Okay, that's long enough.

The problem is that—just as with arguing that you don't need fold because you have a for loop with iteration—that line of thinking ignores the fact that the syntactic overhead necessary to make the former example work is too high. Adding a single keyword to achieve the same semantics and avoid that tiny little trap also makes the resulting code more expressive. It's more declarative.

There's nothing wrong with the goal of a language with a minimal feature set. That's a fine goal, but it can't be the most important goal, and it can't be a goal in isolation. That's because sometimes adding a feature lets you remove unnecessary scaffolding.

I believe that it's better to pursue concision than artificial simplicity in program and language design.

The thing about volunteers writing software is that they don't have to do it. The same goes for volunteers writing documentation or reporting bugs or asking questions about how to use or install or configure that software.

The thing about the Perl community is that almost no one gets paid solely for participating in the Perl community. Sure, you can volunteer for a while to earn the cachet and the right to apply for a TPF grant at a fraction of the going consulting rate to justify continuing to work on the unpleasant parts of a project, but you're still effectively a volunteer.

The thing about volunteers is if it's not worth their time or energy or health or sanity or happiness to keep volunteering, they can walk away whenever they want. They have no obligation to continue to do what they do. Not even their sense of devotion or duty or guilt or community camaraderie should compel them to continue on projects that aren't worth their investment of time, and that's more than okay.

The thing about volunteers is that you can't force them to do anything. You can't force them to have your priorities. You can't force them to work to your schedule. You can't force them to work on your project and you can't force them to care about what you care about. They'll do what they want to do when they want to do it and you either deal with it or you don't.

The thing about volunteers is that it's rare to have too many and it's far too common to have far too few. Thus healthy projects spend time and effort recruiting volunteers and keeping volunteers around and guiding the interests and energy and time of volunteers in productive ways, not only by making their projects pleasant and useful but by removing distractions and unpleasantness from their communitites.

The thing about volunteers is that for every one willing to take the abuse and hostility from a few people, you can't tell how many orders of magnitude more potential volunteers find that hostility and abuse so distasteful that they refuse to consider the possibility that it's worth their time to contribute.

The thing about volunteers is that if you allow certain parts of the community to fester and to grow toxic, you're well on your way to having fewer and fewer volunteers who grow more bitter and eventually become a tiny little cluster of angry, angry people who can't do anything productive.

The thing about volunteers is that it doesn't have to be this way.

Certain Perl IRC channels don't have to be seething cauldrons of rage from burned out system administrators who castigate anyone who doesn't know the secret rituals and wordings of arcane rituals to identify themselves as insiders.

Certain Perl forums don't have to devolve into arguments over whose web framework stole which idea from some other place, or whether it's clear that anyone who does or does not use one CPAN dependency or another has parents with specific unpleasant characteristics.

Certain Perl mailing lists don't have to debate whether people who work on one version of Perl or another are hateful fools whose only goal in life is to destroy everything good and sunshiney and organic.

Certain Perl blogs don't have to have comments accusing other volunteers of being liars or thieves or people of negotiable affection because said volunteers disagree on project management styles.

I suppose it's easier to destroy than to create, and it's easier to prove that you're right by demonstrating your scathing verbal wit with a keyboard, and it's easier to believe that you've won an argument if you reduce the other person to a cardboard cutout of simplistic, ridiculous beliefs. It's also easy to justify your decision to spread hostility if you can overlook the fact that the person you're castigating is a human being with complex motivations, goals, dreams, aspirations, beliefs, and emotions.

The thing about volunteers is that they don't owe you a thing.

If you want a Perl community full of hostile people who jump to hasty conclusions, who are willing to nitpick and debate the specific meaning of words than to understand what other people mean, and who are willing to throw wild accusations of crazy, hateful motives around, then you have an easy task. Just say nothing. Let it fester.

Me, I don't think that's the way to encourage a healthy community. After all, how silly is it to argue over how some other volunteer spends his or her time? Yet isn't that what we're doing?

Maybe if more of us speak up when we see this abuse and hostility, maybe we can discourage it. Maybe we can encourage people to try to understand and listen more, or at least to disagree politely if they must disagree. Maybe we can help people unwilling to be civil to find better hobbies than abusing other volunteers. Maybe we can make the Perl community and our IRC channels and our mailing lists and our forums and our comment sections places where potential volunteers want to participate because they know that we appreciate novices and we appreciate volunteers and we don't all have to do the same things or want the same things or agree on the same things to treat each other with respect.

After all, we're all trying to build great software to solve problems. Why should we borrow trouble?

If modern Perl is safer or easier or clearer or simpler or cleaner to write than legacy Perl, then it should be possible to explain how and why to use modern features in lieu of older features.

For example....

Three-argument open()

There are two forms of the open() function in Perl 5. The modern version takes three arguments: the filehandle to open or vivify, the mode of the filehandle, and the name of the file.

The legacy version has two arguments, only the filehandle and the name of the file. The mode of the file comes from the filename; if the filename starts (or ends) with any of several special characters, open() parses them off and uses them.

If you accidentally use a filename with those special characters with the two-arg form of open(), your code will not behave as you expect. This is especially a problem if you're not careful about sanitizing user input, and if any user input ever becomes part of a filename. Consider:

open my $fh, ">$filename" # INSECURE CODE; do not use
    or die "Can't write to '$filename': $!\n";

While this code appears to open $filename for writing, an insecure $filename could start with > to force appending mode, or - to open STDOUT (though I suspect you have to work really hard to force this). Likewise, code without any explicit mode in the second and final parameter is susceptible to any special mode characters.

Extracting file modes into a separate parameter to this function prevents Perl from parsing the filename at all and removes the possibility for this unintentional behavior. As Damian Conway has mentioned, using a separate file mode parameter also makes the intention of the code clearer:

open my $fh, '>', $filename # safer and clearer
    or die "Can't write to '$filename': $!\n";

The modern version of this code is safer and clearer, and it's been available since Perl 5.6.0, released on 22 March 2000. There's no reason not to use the modern version. (If you need your code to run on Perl 5.005, try a core module such as IO::Handle. If you need your code to run on older versions of Perl 5, you have my sympathy.)