The Perl QA Hackathon 2013 started yesterday in Lancaster. About 30 people hacking to fix bugs in the Perl toolchain and all our tools we use daily to publish stuff on the CPAN. Thanks to all our sponsors that make this event possible and to all the benevolent hackers that came from all over the world.

Follow our news on the Twitter feed: @perlqah.

Some of you already know that I like optimizing things (modules, applications), regarding speed and scalability. For optimizing, you typically benchmark and profile. Regarding web applications, what I find very helpful also is observing request duration over time.

I've been doing this for quite a while now, and I found out, that this is not very common, so I would like to give an example and explain why it can be helpful. I'm also interested in other examples and typical values. (The only post about something like this I found was https://blogs.perl.org/users/mo/2011/07/exciting-updates-to-metacpan.html)

I worked on a new perl11 vm, p2, in the last months. In some perl11 meetings we identified several problems with the current architecture, and came to similar results as the parrot discussions a decade before.

Not only is the VM (the bytecode interpreter) horribly designed as previously observed by Gregg & Ertl 2003, also the parser is an untangable and not maintainable beast. And since any future VM should be able to parse and run perl5 and perl6 together, that's why we reserved use v6; and use v5;

Any new perl vm such as parrot, nqp with the jvm or other backends, niecza or p2 need to be able to parse both. perl6 cannot afford to leave perl5 aside, even if it's a much nicer language. That's why parrot came up first with the PGE based parser framework, which made it super easy for other language to target parrot in the first years.

Previous reports: 2012 year-end, Apr-Jul 2012, ...

Data::Sah. All through January I mostly worked on Data::Sah. In the second week of February, I completed what I call the first stage: some core set of clauses which I use regularly and a working Perl and JavaScript compiler. I can already compile most of the schemas which I use in my programs. It's been deployed in several productions already, e.g. an API service for a license server and report email processing system. There are obviously many things missing, the usual 10% hard part. But I haven't seen the need for another rewrite so far, which means the current implementation (the second, or third IIRC) is not so hackish after all.

What's a bug?

Fair warning: if you're someone who has the shining light of the converted in your eyes and you've discovered the One True Way of writing software, you might feel a bit challenged by this post.

Your newest developer just pushed some code, but it has a bug. They screwed up the CSS and one of the links is a bright, glaring red instead of the muted blue that your company requires. While you're sitting with her, counseling her on the importance of testing, you get a call from marketing congratulating you on the last release. Sales have jumped 50%.

You know that the only change is the link color.

Was that code really a bug? Are you honestly going to roll it back?

More importantly, and this is the question that many people get wrong: what are you going to learn from this?

Last night, I went shopping for a service to monitor servers and API performance. So I looked at New Relic, AppDynamics, and a few others. From what I saw, none of them supported Perl.

That seems like a golden opportunity to me. Those companies are making some serious money (New Relic is likely to do an IPO this year). I think an enterprising Perl developer could get a piece of that pie.

If you put together the right hooks to support one of their monitoring agents from Perl, I am certain those companies would be happy to license you work from you. Or at least offer you a good job.

Individually, those companies may not feel the Perl market is worth the effort, or perhaps they just can't find the expertise to support Perl (good Perl devs are not easy to find). But if you find a way to leverage code across all those companies, then I think you would be sitting pretty.

At the Bank we have a home-grown ETL framework that we've been using for quite some time. We recently completed a total rewrite, but unfortunately we left out a few changes. Had I gotten those changes in 5 months ago, I would have only had to break the API of about 10 modules. Today, in order to make those changes, I have to break the API of 122 modules.

What follows is an account of this ordeal, provided for entertainment value only. There will be a future post that explains some of the things I did to make this task surmountable.

I wrote one this morning: Number::Closest::NonOO is the non-OO version of Number::Closest (plus with some additional features).

Is there an existing convention for this? Or can you suggest a better candidate? Can't seem to find or be able to come up with any. ::Simple is too vague (and a bit misleading). ::Functional? ::Function? ::Procedural? ::NonMoose implies an OO version but without using Moose. NOO is not immediately obvious.

new version perl will lose weight. that's what I want to see for long time. but cleanning package size is not an ultimate target to me. cleanning internal code and attract developers to improve bizatine define is.

I've been using perl for years. and I love it, because of its expression, its cpan, and its community. But its weakness is also apparent, its implementation and its history which have to be compatible backward. Every time I am frustrated in some deficiencies of perl, which ambition of improving perl failed by it’s internal makes me more frustrated. In other word, perl has been evolving thirty years. Which makes perl burden too much history, mistakes, inconsistence etc. Ie. It can call c function by win32::api without a compiler, but you end up dealing with xs. Why You can find many wrap of c library on cpan? just because xs is an weird and obsruced, and nobody want to learn it.

While I enjoy reading the presentations people post here, I've never been that happy with their using Slideshare. What's wrong with just putting a PDF somewhere? As it turns out, Slideshare is actually somewhat slimy -- they got caught using ETags to force tracking cookies on people who explicitly block them. (Do a search for "slideshare kissmetrics" and you'll see that they were proud of it.)

They're welcome to whatever business model they choose, as long as they're open and honest about it. But really, you're better off uploading your slides elsewhere.

The YAPC::NA schedule has now been posted. This will be my first YAPC in the US and it looks like it's going to be great. Curiously, my last YAPC was in Frankfurt, Germany about half an hour away from where my father lives, and this YAPC is in Austin, a couple of hours from where my mother (and many other relatives) live. Thus, Perl is bringing me closer to my family :)

I have two talks accepted. The first is Testing with Test::Class::Moose. That one's a bit of a risk because I'm presenting what is effectively alpha code. However, I've been doing testing long enough that I'm fairly comfortable with what's being put forward. Target audience: if you've ever wanted to use Test::Class + Moose, Test::Class::Moose is the module for you. Plus, due to the reporting and extensibility, this module is probably a great choice for companies with larger test suites who want to better control and information over what's happening in their tests.

Can the Perl community directly fund a major project? I think we can, and we're 15% of the way there to funding Specify module version ranges in Pinto. There are some developers who are so valuable that I think the community should step up to release them from the shackles of the day job.

I've been playing with crowd funding tools, in Perl and in other areas. I posted a note to Twitter looking for volunteers, and Jeff suggested a particular Pinto feature which he needs for Stratopan, a hosted Pinto service that manages private CPAN with exactly the versions of distros that you want. I set up on Crowdtilt, a funding platform on top of Perl's Dancer framework. Jeff made the video to introduce himself. Crowdtilt waived their fee because they love Perl.

Pinto is Jeffrey Thalhammer's private CPAN management tool. If you don't recognize the name, think "The guy who invented Perl::Critic", which he gave the world for free.

A lot of things mentioned about Emacs in this short essay (via Reddit) also ring true about Perl to me.

Good tools are investments. Learning Perl to a sufficiently advanced level is not easy. Like any aged tool, Perl has quite a bit of idiosyncrasies and quirks that still exist due to maintaining backward compatibility. But there's not a single working day that I don't benefit from knowing Perl. Learning Perl has also introduced me to regexes (to a level deeper than it would have been if I had learned other languages) and various other technologies.

Good tools give confidence. I certainly feel that whenever it comes to most text manipulation or automation tasks, I can rely on Perl and CPAN.

Good tools are timeless. Sometimes I can't believe that it has been 17 years since I first knew Perl. Other languages come and go, and other tools even more so, but Perl sticks. Virtually all of the Perl scripts that I wrote back then can still run on my current system's Perl. The same cannot be said with some other languages (even shells). Isn't that amazing?

Good tools grow with you. Perl still surprises and amazes me to this day. CPAN delights me constantly.

Give the original article a read. You'll probably enjoy it (and perhaps be intrigued to learn Perl and/or Emacs).

As part of my work on Stratopan, I've setup a spankin' new CPAN mirror located at http://cpan.stratopan.com. It is an "instant mirror", so it should get new releases almost immediately after they ship to PAUSE. It also has everything from BackPAN too.

Other than that, it's not anything special. It's a mid-sized Linode server located in Texas with 8000 gigabytes/month of traffic. I get a warm and fuzzy feeling from hosting a CPAN mirror. It makes me feel like a more useful part of the community.

Feel free to point cpanm or pinto at http://cpan.stratopan.com. We'll see if my hosting bill goes through the roof :)

I haven't found any guidance on developing for LOCKSS with Eclipse, so here are the steps I followed to load the lockss-daemon code into Eclipse after checking it out from the anonymous CVS repository:

• Create a new project (I named it lockss-daemon).
• Select Use project folder as root for source and class files to make your life easier in the next step.
• This will bring up the dialog Java Settings. You will want to use the Link additional source link with parameters like these:
  • Linked folder location: – Use something like LOCKSSDAEMON/src (my folder was C:\cygwin\home\lockss-daemon\src).
  • Folder name: – use org. This helps Eclipse put all of the files in Eclipse's idea of the right location (i.e. starting at the beginning of the package name). (Figuring out this step is where I had the most trouble.)
• Select your project in Project Explorer, then use Build Path -> Configure Build Path with the External JARs button to get the lockss-daemon JAR files – my JAR files were at C:\cygwin\home\lockss-daemon\lib\*.jar.
• Use Build Path -> Configure Build Path to remove, then re-add the JRE System Library to restore the correct dependency order (a fix found via http://stackoverflow.com/questions/860187/access-restriction-on-class-due-to-restriction-on-required-library-rt-jar).

First, the reason for this post: There was this answer in the recent survey:
"None - I refuse to acknowledge the term man hours, you patriarchical pig. But I have many person-hours. And let me tell you..."

You can discuss if this is discriminating feminists or not. It's a matter of perception, if you know the author or not. It seems that there are people who find this offensive. And I also think that it shouldn't be on a perlmonks poll, while in a group of friends it might be funny.

Hi,

We are proud to announce that we will have the full-time three-day Partner Programme for the partners of the conference attendees.

Our idea is that both the attendee and their partner come together to the venue in the morning, then split, and in the evening they meet again at the venue. Partners participating in the Programme pay only for the tickets to museums etc, or food they consume during their day. No additional fees.

More details and a draft schedule have been just published in this week's newsletter. Feel free to let us your thoughts either by e-mailing to mail@yapcrussia.org or leaving a comment below the news.

I'm going freelance next month in a company that my wife and I are starting. Part of what I've been doing is consulting on various issues companies have and part of that is this whole notion of "agility". I fear that the term "agile" is becoming a meaningless buzzword because, while the core principles are sound, companies are just using the word to say "we have no process." It's a fine line between a process so lightweight that you don't even notice it and a process that doesn't exist and it's understandable that some companies will incorporate "agile" into their buzzword bingo without understanding what it really means. This is sad because it not only dilutes the utility of agile, but it creates a perfect straw man for agile detractors.

Notes from a Newbie document the creation and deployment of yardbirdfanclub.org with Perl Catalyst on shared hosting. They are intended for a Perl Catalyst Newbie who would like to study the creation and deployment of a simple Perl Catalyst application.

• Edit and Delete Comments
• Summary
• Yardbird/lib/Yardbird/Controller/Blog/Entries.pm
• Yardbird/root/src/blog/entries/edit_comments.tt
• Yardbird/root/src/blog/entries/index.tt

Get it?

(Meant to post this to perlmonks, but the site's submission form is missing the [Add] button right now).

Anyway, as a long time user of File::Slurp who utilizes both idioms below often:

# slurp into a scalar
$content = slurp("file.txt");

# slurp into an array
@lines = slurp("file.txt");

I'm willing to switch to IO::All's:

# slurp into a scalar
io("file.txt") > $content;

But there's no array counterpart:

# slurp into an array
io("file.txt") > @lines;

I've hopelessly tried several variants: