Recently in Community Category

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

• Famous Perl One-Liners Explained, Part IV: String and Array Creation (catonmat.net)
• Run invdividual Test::Class methods in vim (blogs.perl.org)
• A regular expression tip every day from @regextip (and not just Perl regexes)
• A few resources for women in open source (itworld.com)
• The next QA hackathon: What do you need? (blogs.perl.org)
• YAPC::NA 2010 dates announced: June 21-23, 2010 (news.perlfoundation.org)
• Pod: Now with sane web links (justatheory.com)
• Creating mailing labels with PostScript::MailLabels (blog.worldlabel.com)
• Ten ways to destroy your community (coffee.geek.nz)
• Conferences on the cheap (blogs.stpcollaborative.com)
• Perl 5.11.4 available (xray.mpe.mpg.de)
• Using Perl to find best Wii bundle pricing (blogs.perl.org)
• Now's the chance for North Americans to easily get to a Nordic Perl Workshop (blogs.perl.org)
• What is Moose? (perltraining.com.au)
• Pretty Perl (blogs.perl.org)

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

• Decoding climate change with Perl, gnuplot and Google Earth (radar.oreilly.com)
• Musical chord analysis with CPAN (use.perl.org)
• Schwern on a pet peeve of mine: Numbered test file abuse (use.perl.org)
• eumm-migrate - easy way to migrate to Module::Build (use.perl.org)
• Readable Perl (blogs.perl.org)
• CPAN's greatest hits: Path::Class (use.perl.org)
• Spreadsheet::WriteExcel now supports embedding charts (blogs.perl.org)
• Cool things in Perl 6: Subsets (blogs.perl.org)
• Ovid has written an INI file parser in Perl 6 (blogs.perl.org)
• Schedule for Perl Oasis 2010 in Florida posted (perloasis.org)
• Movable Type 5 released (movabletype.com)
• YAPC Europe Foundation has published its financials (use.perl.org)

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

• blogs.perl.org is a new, modern blogging platform for the Perl community (blogs.perl.org)
• Michael Peters gives thanks for some special folks in the Perl community (use.perl.org)
• Peteris Krumins explores secret Perl 5 operators (catonmat.net)
• Dave Rolsky talks about his Markdown parser, Markdent: (blog.urth.org)
• Using PUT and DELETE methods in web apps (blogs.perl.org)
• Tests are divine (blogs.perl.org)
• Perl advent calendars galore (perlbuzz.com)
• mirod releases a new version of xml_grep2 (blogs.perl.org)
• Introducing gitalist, a modern Git browser written in Perl (blogs.perl.org)
• Posting to CPAN from Github (blogs.perl.org)
• GitPAN's first success: Recreating the history for Pod::Simple (use.perl.org)
• Why use Kephra? (use.perl.org)
• Recap of Eric Whilhelm's Perl Foundation grant to overhaul learn.perl.org (news.perlfoundation.org)
• Using Perl to scrape the web (ssscripting.blogspot.com)
• Peteris Krumins publishes 30 projects on github (catonmat.net)
• cope, a command-line program colorizer in Perl (stuff.cytzol.org)
• The Perl way of avoiding repeated code: (blogs.perl.org)

In a move of unparalleled beauty, Dave Cross and Aaron Crane have announced blogs.perl.org, a modern blogging platform for the Perl community.

Go look. Enjoy the non-ugly color scheme. Marvel at the code syntax highlighting and ability to embed images. Navigate posts using thoughtful categories.

A million thanks to Dave and Aaron for putting this together, and to Six Apart for the design. Links to feeds will be going up here on Perlbuzz as soon as I have time.

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

• Pod::Simple 3.09 hits the CPAN (justatheory.com)
• Strawberry Perl and the nightmare of installing Padre (use.perl.org)
• A busy month for masak in Perl 6 (use.perl.org)
• A productive week in Rakudo-land (use.perl.org)
• Perl one-liners explained part III: Calculations (catonmat.net)
• Handy one-liner to lowercase all filenames in a directory: ls | perl -lne'$x=lc;print qq{mv $_ $x}' | sh -x
• Use CPAN's toolchain to improve your code (use.perl.org)
• Future Perl snuck up on me (headrattle.blogspot.com)
• Find the stupid bug in my progress indicator: say "$n so far" if ( $n % 100000 )";
• I maeked u a shell: lolshell, written in Perl 6 (theintersect.org)
• The horrible bug your command line Perl program probably has (perlbuzz.com)
• Frozen Perl 2010 looking for speakers (news.perlfoundation.org)
• apache2rest is a new framework for REST APIs under mod_perl2 (code.google.com)
• Putting MySQL on a ramdisk to speed up tests (use.perl.org)
• Generating Feedburner graphs (catonmat.net)

Robert Spier writes

To match the massive advances in Perl over the last few years, www.perl.org has been brought into the modern era. www.perl.org has been completely redesigned, making it clearer and easier to use. All the content has been reviewed and brought up-to-date to provide links and other helpful resources for both new and experienced Perl programmers.

Thanks to www.foxtons.co.uk for donating time from Leo Lapworth, Stephen Morgan, and Cameron Richmond!

Holy cow is it pretty. Thanks to those who made it happen! The download page is especially handy.

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

• Perl projects for newbies (szabgab.com)
• On Moose and speed (blog.afoolishmanifesto.com)
• perldoc.perl.org updated with Perl 5.10.1 docs (use.perl.org)
• From user to contributor (use.perl.org)
• Hash JavaScript with Template::Toolkit for improved caching (blog.greenfelt.net)
• Dave Rolsky teaching a one-day Moose class (blog.urth.org)
• Why I love Perl already (thejoysofcomputing.wordpress.com)
• Is your Perl community visible? (blog.timbunce.org)
• Don't optimize for yourself in communities (perlbuzz.com)
• Releasing Your Company's Software as Open Source (itworld.com)
• What is the Right Way to do OO in Perl 5? (chris.prather.org)
• How to write apps in Rakudo http://groups.google.com/group/de.comp.lang.perl.misc/browse_thread/thread/abbf6e06c0b3b253# (Oh yeah, it's in German)
• What's new in Perl 5.10.1 (perltraining.com.au)
• More changes in the Perl Foundation (news.perlfoundation.org)

By Esther Schindler

Open source offers amazing opportunities. There are almost no barriers to entry. If you want to try creating a new-to-you kind of application, or to learn how to write bright-shiny documentation, or to use the latest technology that your Day Job doesn't give you access to -- you can just barrel right in with an open source project and get involved. Once you become proficient (or demonstrate that you already are), you can apply those skills in the next phase of your career. Even better, you can choose which community you want to be a part of, and find a comfortable culture where your contributions matter.

However, because open source is so personally driven and self-motivated, there aren't always a lot of opportunities to consciously improve your skills -- except on your own. While that's certainly valuable, it relies on you recognizing what needs improvement and then knowing what to do about it. In a regular office, you might be lucky enough to work with someone who'll take you under her wing, and give you specific advice about how to improve your code. Or someone senior to you will let you talk his ear off about the hard choices you have to make, and suggest solutions you didn't think of. The distinction I'm making here is between "learn on your own" (such as examining the changes others make to the code you contributed) and somebody offering specific, individual advice (e.g. "It might run faster if you did THIS..."), particularly in an ongoing personal relationship.

Many open source communities do actual mentoring (even if they don't think of it with that label); others don't. Some make a concerted effort to connect newbies with more experienced people. They provide opportunities for people to work together in smaller teams (not just a gang hanging out in an IRC channel, however useful that is), such as in sprints and code-a-thons. (Tops on the list of "encourage mentorship" is, of course, the Google Summer of Code. But I know there are other less-public endeavors.)

For a feature article at ITWorld.com, I want to interview people from several open source communities about the mentoring experiences. I want to hear what they do right, and how they go about encouraging mentoring relationships. I'd also like to hear from open source participants who have yearned for a bit more one-on-one attention... and what (if anything) they've done about it.

My goal here is to explore what's involved in a successful mentoring effort, and also find out what doesn't work. I like to think that this can help all sorts of open source communities that want to attract more participants.

How you can help

Think you can help? Please email your thoughts on the topic to esther@bitranch.com. Here are some of the questions you could address:

• What have been your mentoring experiences in open source communities? How well or how poorly have they worked? Why do you have that opinion?
• If you developed mentoring relationships in an open source community, how did they come about? Was there a deliberate effort to connect people (how did that work?) or did it evolve on its own (how did it happen?)?
• What did you learn? What did you hope to learn?
• Knowing what you do now, what would you do differently?
• What advice would you give to open source communities in regard to mentoring?
• I'm also particularly interested in hearing from people in communities where mentoring doesn't exist or where it doesn't come as naturally -- opportunities may exist, but they're harder to find.

Be sure to identify:

• the project(s) you're involved in. Include the URL for the project if you like, as well as how you contribute (I write code, or I've led locally-run code-a-thons, etc.)
• your name, role/title, and company in the way you prefer me to refer to you ("Esther Schindler, a programmer at the Groovy Corporation, and also a frequent contributor to the Blahblah open source project").

I'll accept input on this topic until Monday, September 14th. After that I have to write the article. :-)

A long-time technology evangelist and community instigator, Esther Schindler has been in the computer press since 1992. Her primary journalistic focus for the last decade has been software development and open source, and she's contributed as writer or editor to Software Test & Performance, InformIT.com, DevSource.com, and dozens of other publications. She's currently on assignment for ITWorld.com -- where she writes the open source blog Great Wide Open

It drives me nuts every time I connect to an IRC channel, Perl-related or not, and the first thing I'm greeted with is "Don't ask to ask, just ask!" (Over in #perl on freenode, the greeting is "No pasting, at all". BAD USER!)

The problem that the keepers of the channel are trying to solve is when new users come in and ask "I have a problem with arrays, can someone help me?" The regulars of the channel would prefer it if the person seeking help would simply ask the question: "How can I delete an element from the middle of the array." So they put up that chastisement, "Don't ask to ask!"

How incredibly short-sighted!

First, is it really a problem that people ask an introductory "Can someone help me?" Wait, don't answer yet. Don't say "Well, they can just say..." That's not what I asked. Is it a problem? No? Then don't try to fix it.

Second, why not have a more welcoming message to those who you're ostensibly looking to help, and who you'd like to have as part of the community? Why scold people before they've even said anything? How about "Thanks for joining us in #vim! We're glad to answer questions as best we can!" instead?

Third, stop optimizing for your own convenience. Try to consider what your messages are saying to those around you. You just might find the communities you're in to be a nicer place.

People's behaviors are not code that can be optimized by careful code tuning. You can't eke out every last second of efficiency in human interactions.

Addendum: I wrote the welcome for #perl-help on freenode. It says "Welcome to #perl-help. We're glad to help with your questions, but you may need to wait a bit for a response. Posting your code will likely help, please see here: http://paste.scsys.co.uk/" It tells the same things, about how to post your code, and encouraging users to ask questions.

GCC 4.3.4 was released recently. Here's the announcement:

GCC 4.3.4 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.3.3. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html

...

As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

"Too many to thank individually?" How many is "too many"? Would the list of GCC contributors have caused multi-megabyte email messages to swamp the mail servers across the Internet?

What this message really says is "I do not want to take the time to thank people individually. Your contributions are not worth a few minutes of my time." What a fantastic way to poop on your contributors. They would have been better off just not mentioning the contributors at all, rather than saying "You're not worth enumerating."

When someone contributes to your project, the least you can do, quite literally, is to include his or her name in a list of credits. Here are the acknowledgements from WWW::Mechanize.

Thanks to the numerous people who have helped out on WWW::Mechanize in one way or another, including Kirrily Robert for the original WWW::Automate, Gisle Aas, Jeremy Ary, Hilary Holz, Rafael Kitover, Norbert Buchmuller, Dave Page, David Sainty, H.Merijn Brand, Matt Lawrence, Michael Schwern, Adriano Ferreira, Miyagawa, Peteris Krumins, Rafael Kitover, David Steinbrunner, Kevin Falcone, Mike O'Regan, Mark Stosberg, Uri Guttman, Peter Scott, Phillipe Bruhat, Ian Langworth, John Beppu, Gavin Estey, Jim Brandt, Ask Bjoern Hansen, Greg Davies, Ed Silva, Mark-Jason Dominus, Autrijus Tang, Mark Fowler, Stuart Children, Max Maischein, Meng Wong, Prakash Kailasa, Abigail, Jan Pazdziora, Dominique Quatravaux, Scott Lanning, Rob Casey, Leland Johnson, Joshua Gatcomb, Julien Beasley, Abe Timmerman, Peter Stevens, Pete Krawczyk, Tad McClellan, and the late great Iain Truskett.

That's everyone who has contributed such that I was able to get their name (e.g. not an anonymous bug in RT).

And whenever I update a change log, which I release as part of release announcements, I put the person's name in there, too, as in this from ack:

Added new switch --column to display the column of the first hit on the row. Thanks to Eric Van Dewoestine.

One of my favorite Miss Manners letters went like this:

Dear Miss Manners, when is a thank you note not required?

Gentle Reader, when no gift is received.

All project coordinators would do well to remember the lesson.

Addendum: Pete Krawczyk took me task this morning, rightly, for not mentioning that GCC does have a huge contributor list, and they do publish it: http://gcc.gnu.org/onlinedocs/gcc/Contributors.html. My frustration is not in the lack of collection of names, but in the face slap of "There are too many of you too mention." If you get 100 wedding presents, you don't say "That's too many thank you notes to write, so I'm just going to handwave them." I optimize my projects for making sure that everyone's contribution is mentioned at the very least in the Changelog so that people can see their contributions acknowledged in a visible time at the time of release.