Perl

Once in a while someone looks up some numbers regarding Perl and other languages, sees a downward graph, ring the warning bells and then others start proving that yes, but there are more modules on CPAN. As I have a lot of other urgent things to do, I decided a good way to procrastinate would be to look at some data. Some people and companies think that number of pages having the term <b>programming perl</b> is a good indication. That certainly has some value, but I think seeing how many people are actually searching for a term has better indication for the interest in that term.... So I looked at the <a href="http://www.google.com/trends/explore#q=perl%2C%20php%2C%20python%20-monty%2C%20ruby%20-pokemon%2C%20html5&cmpt=q">Google Trends</a> for the above 5 terms and tried to understand what's there. <p>For the full article visit <a href="http://szabgab.com/perl-python-ruby-php-and-html5-on-google-trends.html">Perl, Python, Ruby, PHP and HTML5 on Google trends</a></p>

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com. Mojolicious 4.0 is coming soon (blogs.perl.org) Update on Rakudo Perl 6 on the JVM (6guts.wordpress.com) Perl tokens you should know (perltricks.com) Parallel forking & process management in Perl (blogs.perl.org) What is the state of testing in Perl 6? (blogs.perl.org) A roundup of Markdown parsing modules (neilb.org) How to capture and save warnings (perlmaven.com) Perl is for people who use it at least two hours/week (johndcook.com) POP3 with TLS in Perl (blogs.perl.org) Perl 5.18.0 now available (nntp.perl.org) Advice to a new Perl user (learning-perl.com)

We have received the following grant application, under the Perl 5 Core Maintenance Fund, from Tony Cook. Before we vote on this proposal we would like to get feedback and endorsements from the Perl community. Please leave feedback in the comments or send email with your comments to karen at perlfoundation.org. Project Title: Maintaining Perl 5 Name: Tony Cook Synopsis Free up one of the Perl 5 core's contributors to work non-stop on making Perl 5 better. Benefits to Perl 5 Core Maintenance This grant provides the pumpking with a development resource to target as he or she wills, while still providing for more general bug fixes and other improvements to the perl core. Deliverables I propose to adopt the same model as Dave and Nicholas's successful ongoing grants. Like their grants, there are intentionally no pre-defined deliverables for this project. I intend to devote around 260 hours (about 20 hours a week) over the next 3 months to work on improving the core, paid by the hour at the same below-commercial rate as Dave and Nicholas. Some weeks I may be able to more than 20 hours, if acceptable this will consume more hours and end the grant earlier. Like them, I would post a weekly summary on the p5p mailing list detailing activity for the week, allowing the grant managers and active core developers to verify that the claimed hours tally with actual activity, and thus allow early flagging of any concerns. Likewise, missing two weekly reports in a row without prior notice would be grounds for one of my grant managers to terminate this grant. Exactly as Nicholas and Dave do, once per calendar month I would claim an amount equal to $50 x hours worked. I would issue a report similar to the weekly ones, but summarising the whole month. The report would need to be signed off by one of the grant managers before I get paid. Note that this means I am paid entirely in arrears. At the time of my final claim, I would also produce a report summarising the activity across the whole project period. Also, (the "nuclear option"), the grant managers would be allowed, at any time, to inform the board that in their opinion the project is failing, and that the TPF board may then, after allowing me to present my side of things, to decide whether to terminate the project at that point (i.e. to not pay me for any hours worked after I was first informed that a manager had "raised the alarm"). I view this grant as a proof of concept - if it goes well for everyone involved, I expect to apply to extend it. Project Details I think that the work that I would do to improve Perl 5 would mostly fall into one of four main classes: code reviews, bug fixing, helping other contributors, and adding features - with bug fixes the most prominent and adding features the least. In one major sense what I'm offering is different to Nicholas's or Dave's grant: the current pumpking would be able to assign tasks directly. Ideally this would be done with some consultation with myself, so a large complex task involving parts of the core I'm unfamiliar with isn't assigned (or is assigned with reasonable expectations on time). Of course, if too many tasks are negotiated into non-existence, the grant can be terminated. Some possible tasks, based on discussions over the last several months: readpipe(@list) core exception objects a git hook to prevent changes in the left of a merge Success metric: completion of tasks assigned. Otherwise I'd work on: Reviews of patches submitted to perlbug, possibly committing them This will improve my core knowledge, and provide more timely feedback to non-committers using their time to help perl. Metric: number and complexity of patches applied or commented on. Fixing bugs I select from the perl5 Request Tracker queue. While I wouldn't necessarily be working on the the harder bugs that Dave targets, this would help bring the total bug count down, and reduce the noise in the Request Tracker queue. Metr

The YAPC North America Perl Conferences of the past couple of years have held an event I like quite a bit. It's the first time attendees mixer. As of a couple of years ago, YAPC::NA organizers and attendees realized that about half of the attendees of each conference had never attended a YAPC before. That's between one and two hundred people whose main face to face involvement with the larger Perl community may have been limited to a local Perl Mongers meeting. Yes, these attendees have almost certainly used the CPAN, very likely participated in a discussion on a Perl web site, mostly used a Perl mailing list (and not just the YAPC mailing list), and have probably been on a Perl IRC channel, but they probably aren't the people you think of when you think "Who are the best connected people in the Perl community?" As far back as I can remember (which, admittedly, is one of the YAPC::NAs in Chicago), an early morning talk has served as an introduction to YAPC, specifically intended to help new attendees understand the conference and its quirks and norms. That talk invites these attendees to the novice welcome meeting. The organizers also grab as many of the well connected people in the community&mdash;pumpkings, core developers, CPAN contributors, authors, project leaders, anyone whose name you might recognize&mdash;and ask them to show up and be willing to talk to people. That's it. What I like about this system is that it welcomes people in two ways. First, it acknowledges that it's okay to be new to YAPC or the Perl community in person. If that's you, you're not alone. Half of everyone you're going to see at the conference is like you in that sense. Not only that, but you have permission to participate. You're welcome to attend this little meetup that has an explicit place in the schedule&mdash;it's an official part of the conference&mdash;and you're encouraged to talk to people you might know only by reputation. They're there to meet and talk to you. They're not there to hang out in little groups by themselves. They're there to talk to you. I've heard good things about this event. I've enjoyed it every time I've gone. (As an introvert myself, I like having permission to talk to people with a limit of a couple of hours.) I feel the same way about a YAPC Code of Conduct. I don't see it as a warning that "straying from a straight and narrow path of arbitrariness will not be tolerated, so if you're not sure if you might accidentally say or do something someone else doesn't like, stay away!" I see it as giving people who aren't necessarily well versed in the norms and ideals and messy politics of dealing with the Perl community every day virtually and in person permission to believe that they should feel welcome and important in the community. It's about empathy. I understand people disagree about the wording and even need for a code of conduct, and I don't mean to suggest that such concerns come from robots who lack empathy. By no means. Yet put yourself in the shoes of someone who feels like he might not quite fit in in a talk, because it's full of inside jokes and jargon and the kinds of comfortable banter you only get after you've idled on a handful of Perl IRC channels for months or years. (Imagine that person's an introvert, or at least not as stubborn as I am.) Now imagine the speaker or someone else says or does something that reminds that person that he doesn't belong there, that he doesn't fit in, that he's different. That's not necessarily assault. That's not necessarily a criminal act. But it's probably unnecessary and hopefully unintentional. (The best silly example I can come up with is a speaker saying "... and of course, if you're a Windows user, no one cares about you until you man up and get a real operating system." and half of the audience laughs.) Sure, there are good legal reasons to have a code of conduct that suggests that criminal activities such as assault, battery, and sexual assault are int

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com. Porting a module to Perl 6 (blog.brentlaabs.com) Running named Perl tests from prove (modernperlbooks.com) How Perl can help local hackathons (blogs.perl.org) How to start hacking on Rakudo Perl 6 (blog.brentlaabs.com) Ludic Perl (blogs.perl.org) Perl actually doesn't suck (blogs.perl.org) The Pinto crowdfunding campaign has reached its goal (blogs.perl.org)

Organizing Perl Test Files showed the basic framework I use for individual test files written to work with Perl's testing tools. While I gladly take advantage of frameworks such as Test::Class and Test::Routine, sometimes I need something a little simpler. The discipline of the organization method I explained in the previous article offers the benefit of simplicity and some discoverability. It also allows my team to run only a portion of the test suite as needed. One of our products has a web interface. We have quite a few tests for this, but because they run through the whole web stack, they're quite a bit slower than tests for the business model API directly. (We want to make sure the web site always works, so we have some exhaustive tests.) We've divided many of these tests up into discrete files based on controllers and subsets of controllers. The administrative section has a few test files. The data sharing section has a few test files. The public section has a few test files. Some of these tests tak

a section listing contributors

Manipulate Mac OS X pasteboards

L<ElasticSearch> based session engine for Dancer

Parse regular expressions