September 2009 Archives

Perlbuzz news roundup for 2009-09-24

| 1 Comment

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

  • Perl described in five sentences (blog.timbunce.org)
  • RT @chromatic_x perl 6 is some 6% faster today. You're welcome.
  • "Perl is full of odd, and they like it like that." (twitter.com)
  • Why Users Dumped Your Open Source App for Proprietary Software (itworld.com)
  • Book review of The Definitive Guide to Catalyst (dave.org.uk)
  • YAPC::NA 2009 survey results available (use.perl.org)
  • RT chromatic_x Rakudo Perl 6 passes 26% more spectests (and the test suite has grown by 19%) since the August 2009 release.
  • Learn Github (learn.github.com)
  • Submitted with eye-rolling: The $case_insensitive flag on PHP define() (us.php.net)
  • Porting a non-Moose object to Moose (kentcowgill.org)
  • Seven signs your interface came from a programmer (voyce.com)
  • Curtis "Ovid" Poe added to Board of Directors of the Perl Foundation (news.perlfoundation.org)
  • How not to restart mod-perl servers (openswartz.com)

Perlbuzz news roundup for 2009-09-09

| 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.

Mentoring in open source communities: What works? What doesn't?

| No Comments

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

ack 1.90 released

| 3 Comments

I just released ack version 1.90 to CPAN. If you don't know about ack, it's a text searching tool for programmers aimed specifically at searching large trees of code. Find out more at betterthangrep.com.

Here's the changelog for this version:

1.90        Mon Sep  7 23:24:24 CDT 2009
[ENHANCEMENTS]
Added Ada support.  Thanks to Shaun Patterson.

Added -r, -R and --recurse options as in grep.  They have no
effect because directory recursion is on by default.  Also added
--no-recurse for orthoganality. Thanks to Mark Stosberg and
Ryan Niebur.

Version in --version is prettier.  Thanks, Ori Avtalion.

Added an updated ack.bash_completion.sh from Adam James.

[FIXES]
Expanded --files-without-match to --files-without-matches.

Removed all the hi-bit characters, so we don't have any encoding
problems.  It's all entities now.

Fixed capture-stderr to localize some globals that were obscuring
errors.  Thanks very much to Christopher Madsen.

Fixed uninitialized errors in tickets #138 and #159.

[DOCUMENTATION]
Fixed an incorrect command line in the docs for -f.

Added notes on --pager.  Thanks to Mike Morearty.

[BUILD]
Made the squash program more robust when handling POD.  Thanks
to Kent Fredric.


1.89_02     Wed May 13 16:20:21 CDT 2009
[DISTRIBUTION]
Updated Makefile.PL to use new ExtUtils::MakeMaker features.
Thanks, Schwern.

[FEATURES]
--version now shows the version of Perl that ack is running
under, and the full path to the Perl executable.

Added new switches --color-match and --color-filename, which
let you define ACK_COLOR_MATCH and ACK_COLOR_FILENAME from the
command line.

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

Added .ss to --scheme.

[FIXES]
No longer die if you have a .tar.gz file in your tree.

More tweaks to get the detection of input and output pipes
working.

Fixed an amazingly bad call to cmp_ok() in t/ack-passthru.t.

[DOCUMENTATION]
Started an ack FAQ.

Don't optimize for yourself in communities

| 21 Comments

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.

Perlbuzz news roundup for 2009-09-02

| 5 Comments

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

« August 2009 | Main Index | Archives | October 2009 »