• fix a specific bug
• add a test for a specific feature
• improve test coverage by 5%
• write a tutorial
• create a screencast for beginners
• write an example program
• create a homepage for the module

?

If so, you could be in luck. These are all potential tasks for students in this year's Google Code-In.

Following on from our success last year, The Perl Foundation is hoping to take part in the Google Code-In again this year. GCI is a programme similar to the Google Summer of Code, but aimed at students between the ages of 13 and 17. Students complete short well defined tasks for open source projects, and the two top students from each organisation will be invited to visit Google's headquarters in Mountain View, California for a five-day trip.

This is a wonderful opportunity that we have to get young students involved in open source software in general and Perl in particular. One of the aims of the GCI programme is to find those who will become long-term contributors and ensure the future of open source projects. So if you want to help ensure the long-term viability of Perl, or find a new developer for your project, then please get involved with GCI.

This year only ten organisations will take part in GCI. To back up our application we need to prepare some tasks for the students. If you are a module author, or you are involved in a Perl project, WE NEED YOUR HELP! But you can also benefit, so this is a win-win proposition.

We need a set of tasks to make available to students, along with mentors willing to help students with the tasks. We need tasks in the following five categories:

• Code: Tasks related to writing or refactoring code
• Documentation/Training: Tasks related to creating/editing documents and helping others learn more
• Outreach/Research Tasks related to community management, outreach/marketing or studying problems and recommending solutions
• Quality Assurance: Tasks related to testing and ensuring code is of high quality
• User Interface: Tasks related to user experience research or user interface design and interaction

Please take a look at the wiki for more information and take ten minutes to sign up as a mentor or add one or more tasks to the list. We need these lists populated as soon as possible to support our application.

Thank you!

Whilst nice, and somewhat useful, this was very much a proof of concept. It only worked for statement coverage, it wasn't particularly clever, nor was it particularly pretty.

I've just released Devel::Cover version 0.86 which solves a number of these problems. It shows all types of coverage data (that Devel::Cover knows about), it seems to be pretty usable (at least in the way I use vim), and it provides a way to customise it to make it pretty (I'm fairly happy with the way mine looks).

In this image you can see some of the features. The column on the left-hand side shows the coverage information. Five coverage criteria are displayed as:

P - Pod coverage
S - Statement coverage
R - Subroutine coverage
B - Branch coverage
C - Condition coverage

Successfully covered criteria are displayed in green, uncovered criteria in red. Since only one criterion can be displayed, the most important is chosen. In the list above, lower criteria are more important. Any uncovered criterion is displayed in preference to a covered criterion.

Thus, in line 69, although the statement is covered, as is the subroutine, there is is no pod coverage and so we see a red P. Lines 70, 72 and 73 are covered statements, hence the green S. Line 74 is a covered statement too, but it is also a covered branch, so we see a green B. Line 77 is an uncovered condition resulting in a red C. You get the idea.

If you are editing a file, coverage information can get out of date. Vim does its best to move signs appropriately when you are editing, but in the image above you can see a file being edited with out of date coverage data and the left hand coverage column has a red hue to make this more apparent.

Since I don't know your colour scheme, this is all customisable by adding an appropriate devel-cover.vim file somewhere under your ~/.vim directory. I use the dark solarized theme (http://ethanschoonover.com/solarized) and have included my cutomised devel-cover.vim file in the docs so you can copy from it.

I can see this becoming a standard tool that I use during my development. I'm really thankful to Miyagawa for pointing me in the right direction at the QA Hackathon.

And on that note, many, many thanks to Laurent Boivin (elbeho), Philippe Bruhat (BooK) and the Les Mongueurs de Perl for the organisation, which was just about perfect. Additionally, the event would not have been possible without sponsors: The City of Science and Industry, Diabolo.com, Dijkmat, DuckDuckGo, Dyn, Freeside Internet Services, Hedera Technology, Jaguar Network, Mongueurs de Perl, Shadowcat Systems Limited, SPLIO, TECLIB', Weborama, and $foo Magazine and individual donations from Martin Evans, Mark Keating, Prakash Kailasa, Neil Bowers, 加藤 敦 (Ktat), Karen Pauley, Chad Davis, Franck Cuny, 近藤嘉雪, Tomohiro Hosaka, Syohei Yoshida, 牧 大輔 (lestrrat), and Laurent Boivin.

The effects of those few days in Paris will be felt for weeks and months to come, so thanks again to all the sponsors and individuals who made it happen.

Finally, I am applying for a grant from TPF to help push Devel::Cover work forward. The time for feedback is drawing to a close, so if you have any comments you'd like to make about that, please leave them at http://news.perlfoundation.org/2012/04/grant-application-improving-de.html

I am happy to announce that the application of The Perl Foundation has been officially accepted and Perl will be taking part in GCI 2011. This is due in large measure to the wonderful reaction to our appeals which has lead to numerous high quality tasks being added to the ideas page and many selfless developers volunteering to be mentors. Without your assistance our application would not have been successful, so thank you very much to everyone involved.

But the tasks are only part of the story. Undoubtedly the track record that Perl has in GSOC as well as last year's GCI was a contributing factor, as was the leadership of Florian Ragwitz and Mark Keating. So many thanks to everyone who has brought us to this point.

Of course, we're now just at the start of the programme though. We have tasks and mentors, but it's not too late to add more. So please continue to add tasks and sign up as a mentors. Look at my previous post if you need ideas.

But we also need students! Mark Keating has provided information on The Perl Foundation's website including two flyers to post in appropriate locations. Remember that GCI is for students aged between 13 and 17 who do not attend university. They do not necessarily have to be studying a computing course. Students have to opportunity of earning up to $500 and the chance of a trip to visit Google's headquarters. Students will be able to start working on tasks on 21st November 2011.

So yes, this is another appeal for help. Please spread the word and help us find students for this programme. We often hear about the need to attract new people into the Perl community. If you would like to do more than just talk about it, this is a perfect opportunity.

This is a wonderful opportunity that we have to get young students involved in open source software in general and Perl in particular. One of the aims of the GCI programme is to find those who will become long-term contributors and ensure the future of open source projects. So if you want to help ensure the long-term viability of Perl, then please get involved with GCI.

If you are a module author, or you are involved in a Perl project, WE NEED YOUR HELP! But you can also benefit, so this is a win-win proposition.

We need a set of tasks to make available to students, along with mentors willing to help students complete the tasks, if necessary. We need tasks in the following eight categories:

Code: Tasks related to writing or refactoring code
Documentation: Tasks related to creating/editing documents
Outreach: Tasks related to community management and outreach/marketing
Quality Assurance: Tasks related to testing and ensuring code is of high quality
Research: Tasks related to studying a problem and recommending solutions
Training: Tasks related to helping others learn more
Translation: Tasks related to localization
User Interface: Tasks related to user experience research or user interface design and interaction

WE NEED YOUR HELP NOW!

We need to submit our application by 1st November 2011 supported by a list of tasks. Ideally we should have at least eighty tasks covering all the categories above. Half of the tasks will be for the first phase of the programme, and the remainder for the second phase.

So, we need at least eighty tasks in the next five days. If every module author or project member were to provide just one task we could easily do that. Please take ten minutes to read up on GCI, select a task and add it to the wiki today.

Tasks might include such items as fixing bugs (check your RT queue), adding tests for specific areas or to improve code coverage in general, writing a tutorial, translating documentation, making a video promoting the project or demonstrating its use, adding new features, researching potential new areas, or anything else which could help the project.

Please take a look at the wiki for more information and add your tasks to the ideas page.

Please help! Every module author and project member can make a difference in helping to ensure the future of open source, Perl and your own project. Add a task now. Really, Just do it. Then add another one tomorrow. And the next day. We can't have too many. We already know that you are generous and happy to give back to the Perl community. Please consider this new way of doing so. If you don't think you would be able to act as a mentor, please add the task anyway, and we will find someone else to mentor. Thank-you for your help.

Oh, and it's great for the students too, so if you have any way of publicising this to appropriate students too, please do that. But add a task first!

My own take on variable names is that naming is one of the hardest problems in software development, and that the length of a variable name should reflect the length of the scope in which it is visible. A single letter variable name is fine in a small loop, for example. A larger scope would call for a correspondingly larger variable name.

The rationale for this is that our short-term memory can store only a small amount of information; 7 ± 2 items according to Miller, but more recently thought to be 3 or 4 "chunks". When reading or writing code, additional text such as unnecessary comments, excessive punctuation and even long names can obscure the meaning of the code making it harder to reason about. If a common variable in a small scope can be given a short name, that variable and its purpose can be stored in our short-term memory for the duration of our concentration on that scope. For larger scopes, where there are more names, this would overflow our short-term memory requiring us to go back and check what the short name actually referred to, negating the benefit of having less cluttered code.

Naturally, this is also the reason why the name must be descriptive rather than merely long, and certainly shouldn't be misleading.

And as with other names, a single letter variable name should reflect its purpose as much as possible, to further aid our understanding; $q for a queue, $c for a customer, $n for a count and so forth. The problems start to occur when we have a customer and a context, for example, and at that point having a variable named $c is more of a hindrance than a help. That's when you would want $cust and $cxt, or $customer and $context depending on the size of their scopes.