Community

Perlbuzz news roundup for 2012-06-18

June 18, 2012 Community, Conferences, CPAN, Perl 5, Perl 6 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

  • Perl for Big Data: “Hadoop is overrated. Come see what modern Perl can do.” (blog.yapcna.org)
  • Why I use Perl: Reliability (modernperlbooks.com)
  • Any language would be improved if it had Perl’s testing and library culture. (news.ycombinator.com)
  • YAPC::NA 2012’s legacy for future organizers (blogs.perl.org)
  • Evolving tests and code in small steps (modernperlbooks.com)
  • mod_perl 2.07 released, works w/Perl 5.16 (blogs.perl.org)
  • HTML::Tree 5.00 fixes memory leak problems (blogs.perl.org)
  • “Our meritocracy is broken.” — @schwern at #yapcna
  • “The people who want to use Perl are those we should be building the community for.” — @schwern at #yapcna
  • Larry Wall had to hack a 25-year Perl ribbon at #yapcna. (twitter.com)
  • perlybook.org generates epub/mobi ebooks of Perl module documentation.
  • Ovid’s “Beginning Perl” available online for free (blogs.perl.org)
  • “There are no stupid questions” says Mojolicious’ @tempire. “Nobody will be mean to you in #mojo IRC channel.” Bravo for publicly stating.
  • When subgroups of your community find it necessary to say “We will not be mean to you,” your community has a Big Problem.
  • Arduino/Dancer-enabled mobile-enhanced door (blogs.perl.org)
  • Boston Ruby works to be beginner-friendly (openhatch.org)
  • Reflections on YAPC::NA 2012 (blogs.perl.org)
  • How @mithaldu put the YAPC videos on YouTube (blogs.perl.org)
  • Rakudo Perl 6 on Android (blogs.perl.org)
  • YAPC::NA recap from Sawyer_X (blogs.perl.org)
  • Calculating technical debt with Perl::Critic (elliotlovesperl.com)

Before you write a patch, write an email

April 27, 2012 Community 3 comments

(Originally posted to my non-Perl blog)

I often get surprise patches in my projects from people I’ve never heard from. I’m not talking about things like fixing typos, or fixing a bug in the bug tracker. I’m talking about new features, handed over fully-formed. Unfortunately, it’s sometimes the case that the patch doesn’t fit the project, or where the project is going. I feel bad turning down these changes, but it’s what I have to do.

Sometimes it feels like they’re trying to do their best to make the patch a surprise, sort of like working hard to buy your mom an awesome birthday present without her knowing about it. But in the case of contributing to a project, surprise isn’t a good thing. Talking to the project first doesn’t take away from the value of what you’re trying to do. This talking up front may even turn up a better way to do what you want.

There’s nothing wrong with collaborating with others to plan work to be done. In our day-to-day jobs, when management, clients and users push us to start construction of a project before requirements are complete, it’s called WISCY, or Why Isn’t Someone Coding Yet? As programmers, it’s our job to push back against this tendency to avoid wasted work. Sometimes this means pushing back against users, and sometimes it means pushing back against ourselves.

I’m not suggesting that would-be contributors go through some sort of annoying process, filling out online forms to justify their wants. I’m just talking about a simple email. I know that we want to get to the fun part of coding, but it makes sense to spend a few minutes to drop a quick note: “Hey, I love project Foo, and I was thinking about adding a switch to do X.” You’re sure to get back a “Sounds great! Love to have it!” or a “No, thanks, we’ve thought about that and decided not to do that”. Maybe you’ll find that what you’re suggesting is already done and ready for the next release. Or maybe you’ll get no reply to your email at all, which tells you your work will probably be ignored anyway.

I’m not suggesting that you shouldn’t modify code for your own purposes. That’s part of the beauty of using open source. If you need to add a feature for yourself, go ahead. But if your goal is to contribute to the project as well as scratching your own itch, it only makes sense to start with communication.

Communication starts with understanding how the project works. The docs probably include something about the development process the project uses. While you’re at it, join the project’s mailing list and read the last few dozen messages in the archive. I can’t tell you how many times I’ve answered a question or patch from someone when I’ve said the same thing to someone else a week earlier.

Next time you have an idea to contribute a change to an open source project, let someone know what you’re thinking first. Find out if your patch is something the project wants. Find out what the preferred process for submitting changes is. Save yourself from wasted time.

We want your collaboration! We want you your help! Just talk to us first.

Perlbuzz news roundup for 2012-04-16

April 16, 2012 Community, CPAN, Perl 5 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

  • K=R=P (Kindness = Repeat business = Profit) says @tom_peters. I say that for open source, K=U=G+S, Kindness = Users = Growth+Success.
  • You probably don’t want to be using use_ok() (modernperlbooks.com)
  • Interpolate, concatenate or join? (perlmonks.org)
  • Quick-n-dirty tool to send messages to HipChat (blogs.perl.org)
  • Painless RSS processing with Mojo (blogs.perl.org)
  • RT @chromatic_x If you use SQLite for your CPAN distribution’s tests, consider an in-memory database. Helps parallelism/Reduces disk IO.
  • Explaining web programming via Plack (blogs.perl.org)
  • Common Perl pitfalls (perlmonks.org)
  • Test::WWW::Mechanize adds scraping functions (perlbuzz.com)

Perlbuzz news roundup for 2012-04-09

April 9, 2012 Code craft, Community, CPAN, Perl 5, Perl 6 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

  • The Perl Unicode cookbook (perl.com)
  • bdfoy’s got some ideas for code (blogs.perl.org)
  • How @rjbs spent his Perl QA Hackathon (rjbs.manxome.org)
  • The homepage for ack is completely redesigned. Hooray for open source, making up for my lack of design skillz. (betterthangrep.com)
  • Tricks to compiling mod_perl 2 to OS X Lion (blogs.perl.org)
  • Have you seen perl-reversion? (blogs.perl.org)
  • Using WWW::Mechanize and mech-dump to get my scratchy 45s (perlbuzz.com)
  • DBD::Firebird releases v1.0 (firebirdnews.org)
  • Recap of the Perl QA Hackathon (dagolden.com)
  • Reading about what people are working on = happy. (blogs.perl.org)
  • Whatever task you have, it’s probably already on CPAN (blogs.perl.org)
  • The Perl Foundation wants to give you money to work on Perl (news.perlfoundation.org)
  • More niche modules, “incredibly useful for about 5 people on earth”: (github.com)
  • Did you know prove has –shuffle to run tests in random order? Has randomizing tests uncovered bugs for you?
  • MetaCPAN has a new logo (perlnews.org)
  • RT @dukeleto This is a huge step forward in #perl dependency management: “carton bundle” support! (github.com)
  • RT @aaronlerch Some devs think “I’ll just copy and paste this code block.” Now you have two problems. Now you have two problems.
  • Would love to see this Perl::Critic talk (blogs.perl.org)
  • “The Python site talks about the value the reader gets out of Python, while the Perl site talks about Perl” (modernperlbooks.com)
  • How to get ahead in open source: Wear sunscreen. (blog.nerdchic.net)
  • Help Open Source Bridge select session proposals (plus.google.com)
  • MetaCPAN at the QA hackathon (blogs.perl.org)
  • Perl Foundation helps fund critical Perl 5 dev (news.perlfoundation.org)

On being a snot

February 14, 2012 Community No comments

In response to all the kerfuffle about [Why I Left Perl](http://www.leancrew.com/all-this/2012/02/why-i-left-perl/) because of strict dogma about strict, Chris Prather wrote a [well-reasoned discussion](http://chris.prather.org/starry-headed-hipsters.md.html) about how there are no standards for what “best practices” is in Perl. One of his key points was:
> *The big reason for leaving Perl, though, was people in the Perl community, who had become annoying scolds.*
I agree 100%, and I’ve long been frustrated with people who do that, who take a dump on others for not doing it the right way. I’ve tried to get people to see why that’s so damaging to community, and along the way there have been times I’ve been that annoying scold. And for that I apologize. If you’ve ever felt that I talked down to you, or scolded you for something, I’m sorry. Nobody deserves that.
I try to keep the [words of the wise Larry Wall](http://en.wikiquote.org/wiki/Larry_Wall) in mind at all times:
> *There ain’t nothin’ in this world that’s worth being a snot over.*
As far as I’m concerned, there is no person, no matter if he’s a newbie or been around for years, that deserves to be insulted. It doesn’t matter if it’s “for his own good” or “the good of the community”, it’s never the right answer to insult or degrade someone. That’s why I apologize if you’ve ever felt talked down to. Nobody deserves it, even if the cause is right, and I thank Chris’s post for reminding me.
A while back [I posted about the acronym THINK](http://perlbuzz.com/2010/11/think-for-perls-sake.html) that asks if what I’m about to say is:

Thoughtful
Honest
Intelligent
Necessary
Kind

Unfortunately, it’s always the Kind that falls first online. It gets left behind in the pursuit of Intelligent. Maybe I should write something that makes “THINK” pop up whenever a blog comment box opens up.
For more on the whole “how poorly we treat newbies”, I also suggest reading “use strict ‘answers'”.

Perlbuzz news roundup for 2011-12-19

December 19, 2011 Code craft, Community, CPAN, Perl 5, Perl Foundation No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

Perlbuzz news roundup for 2011-11-21

November 21, 2011 Advocacy, Community, CPAN, Perl 5 No comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

Perlbuzz news roundup for 2011-11-07

November 7, 2011 Code craft, Community, CPAN, Perl 5, Perl 6 2 comments

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.

Mark Jason Dominus on giving fish

November 2, 2011 Community, Opinion 4 comments

By Mark Jason Dominus, from a talk in 2003, reprinted here with permission. Sadly, it’s still relevant today.

The #perl IRC channel has a big problem. People come in asking questions, say, “How do I remove the first character from a string?” And the answer they get from the regulars on the channel is something like “perldoc perlre“.

This isn’t particularly helpful, since perlre is a very large reference manual, and even I have trouble reading it. It’s sort of like telling someone to read the Camel book when what they want to know is how to get the integer part of a number. Sure, the answer is in there somewhere, but it might take you a year to find it.

The channel regulars have this idiotic saying about how if you give a man a fish he can eat for one day, but if you teach him to fish, he can eat for his whole life. Apparently “perldoc perlre” is what passes for “teaching a man to fish” in this channel.

I’m more likely to just answer the question (you use $string =~ s/.//s) and someone once asked me why. I had to think about that a while. Two easy reasons are that it’s helpful and kind, and if you’re not in the channel to be helpful and kind, then what’s the point of answering questions at all? It’s also easy to give the answer, so why not? I’ve seen people write long treatises on why the querent should be looking in the manual instead of asking on-channel, which it would have been a lot shorter to just answer the question. That’s a puzzle all right.

The channel regulars say that answering people’s questions will make them dependent on you for assistance, which I think is bullshit. Apparently they’re worried that the same people will come back and ask more and more and more questions. They seem to have forgotten that if that did happen (and I don’t think it does) they could stop answering; problem solved.

The channel regulars also have this fantasy that saying perldoc perlre is somehow more helpful than simply answering the question, which I also think is bullshit. Something they apparently haven’t figured out is that if you really want someone to look in the manual, saying perldoc perlre is not the way to do it. A much more effective way to get them to look in the manual is to answer the question first, and then, after they thank you, say “You could have found the answer to that in the such-and-so section of the manual.” People are a lot more willing to take your advice once you have established that you are a helpful person. Saying perldoc perlre seems to me to be most effective as a way to get people to decide that Perl programmers are assholes and to quit Perl for some other language.

After I wrote the slides for this talk I found an old Usenet discussion in which I expressed many of the same views. One of the Usenet regulars went so far as to say that he didn’t answer people’s questions because he didn’t want to insult their intelligence by suggesting that they would be unable to look in the documentation, and that if he came into a newsgroup with a question and received a straightforward answer to it, he would be offended. I told him that I thought if he really believed that he needed a vacation, because it was totally warped.

Mark Jason Dominus has been doing Perl forever. He is the author of Higher Order Perl which belongs on the shelf of every Perl programmer. Follow him on Twitter at @mjdominus.

Perlbuzz news roundup for 2011-10-31

October 31, 2011 Community, Conferences, CPAN

These links are collected from the
Perlbuzz Twitter feed.
If you have suggestions for news bits, please mail me at
andy@perlbuzz.com.