blogs.perl.org

Thanks to all for the wonderful response rate. At this point we're a little over the 3,000 mark. I'm going to close the survey down at 7:00 am UTC on Thursday the 3rd of June, so if there are people you think still need to answer the survey, please point them at http://survey.perlfoundation.org.

I'll process the data file to make it useful over the weekend, and have a preliminary report ready early next week.

I've only recently taken on the tremendous task of learning Perl (with the aide of O'Reilly's Learning Perl). I have a little background in programming as I am a Computer Engineering & Computer Science student at the Florida Institute of Technology. Actually, I was a student there. I can't quite afford it at this point, and I'm going to attempt to transfer elsewhere (UCF, USF, UF? Something with a U and an F, I'd suppose).

Well, on to something a bit more on-topic. I'm midway through Chapter 5 in Learning Perl and I felt the need to create something that the book didn't explicitly tell me to. I eventually want to build my own forums software, but this small 'Journal' or 'Diary' script will have to do for now.

#! /usr/bin/perl

print "Press CTRL-D to end journal entry.\n";
my $success = open LOG, ">>logfile";
if ( ! $success) {
die "Cannot create logfile: $!";
}

select LOG;
print "\n\n", scalar localtime(), "\n";
print <STDIN>;

Seems like Padre (the Perl IDE, ya know...) got some heat for using a Trac bug tracking system instead of the default CPAN RT system.

Dancer, as mentioned in Gabor's post, prefers to use the Github Issues ticket system to keep track of bugs, wishes, expected features, etc.

I agree there's a certain barrier to provide bugs for Padre and Dancer or any other project that uses a non-CPAN-RT ticket system. I personally hate registering for websites and have decided not to file a bug more than once because I had to register. (case in point: notifying Yahoo! someone is abusing their mailing list system for SPAM.)

Some days are just big buckets of fail. So far I've not been able to get any code to successfully publish anything to blogger.com. I've failed with both Net::Blogger and Atompub and am seriously tempted to just create a bunch of damned HEREDOCs and push them straight to the Google Blogger API.

Didn't we use to own the Web? Or maybe I'm just having a really off day. I've successfully written a custom CMS in just a few hours and I'm stuck on one last, little stumbling block.

Anyone have working code they care to share? I mean real, live working code, not examples. I've seen more failed examples than I care to admit :)

• Can it be compared with J2EE?
• CGI? That's even older than ASP, you cannot write my webapp in it!
• Does Perl support session?
• I can let you try to code at most 20% of my webapp(you can't code the whole site with Perl, apparently), but make sure it can share session with ASP.NET.
• What's needed to run your Perl?
• Is there anything Perl can do better than Java?
• Does Perl have business value?

Like Damian said in this interview: "Selling Perl to your manager is about explaining Perl in terms that your manager cares about: stable, reliable, powerful, efficient, cheap, maintainable, well-supported, and future-proof."

Are we sharing the same situation here?

I previously wrote about trying out MooseX::Method::Signatures. That module is neat, but incurs a significant runtime penalty per subroutine call.

Now I've tested out Method::Signatures::Simple. It's powered by Devel::Declare and doesn't seem to incur a any runtime penalty. However, since it needs to do some work when the subroutines are compiled, there's a 3-4% compilation hit for my tests:

But on runtime there's no hit at all:

Here's what I needed to do to convert Hailo to it. Unfortunately using it breaks interaction with Devel::NYTProf. When I generate profiling output with nytprofhtml what were previously links to my subroutines aren't links at all.

That's a big price to pay for just turning this:

Into this:

So unless I can figure out a workaround for that I won't be merging that branch.

I've been noticing more and more attention being given to environment testing. That is, part of your testing would be to check the environment you're on. Many Perl developers would probably hear this and say "yeah, well, that makes sense" - that is because many Perl developers already do it. Apparently the other developers are starting to catch on. :)

Test::SFTP was written to make sure my environment is okay. By "okay", I mean "consistent." Also, I really wanted to write a test module.

Originally I wrote Test::SFTP when Net::SFTP::Foreign either didn't exist or was in its very very early days. Point is, I didn't know it. I used Net::SFTP which uses in turn Net::SSH::Perl which - for those that do not know it - is a pure-Perl implementation of the SSH protocol. It's actually a pretty cool thing, except that the dependency is a complete nightmare (including GMP and half of Crypt::* namespace) and it's rather slow.

I'm getting married on June 20th. Leïla and I chose this date because it's my birthday. It's my birthday because I was born on Dies Martis xx Junius MCMLXVII, as calculated by:

I think I started to reinvent XPath. I hate when that happens.

It started simply enough. I had a directory with 12,000 YAML files in it. I wanted to grep them, but I can't do that from the command line:

 -bash: /usr/bin/grep: Argument list too long

Although slightly annoying this isn't a big deal. I can write a Perl script to do the job and get the files through opendir. I hardcoded the bits that I wanted to get out, and when I needed something else, I just changed the source.

I made a couple of these quick scripts before I realized I was going to be doing this a lot. I refactored it so I could specify on the command line the path to the YAML thingy I wanted, and called it, well, it was called extract, but I renamed it ypath to put it on Github.

 % ypath dist_info/dist_file *.yml

I could do it for multiple values:

For some time now I have been promising to publish the list of CPAN Authors who for one reason or another, appear to be uncontactable. These are authors, who when using their PAUSEID @ cpan.org address, generates a rejection of some form. Typically this appears to be for addresses which are set up to be used in redirection, which have since been made obsolete (perhaps from changing jobs or personal domain), but there are a few that are just not setup to receive emails.

I have now created a Missing In Action page, which I will keep updated as I receive bounce backs from the CPAN Testers daily summaries. In some cases bounce backs require verification from a real person, and I do eventually get round to those, but the ones listed are specifically for emails that are outright rejected. If you have not been receiving any CPAN Testers summaries or reports and have been expecting some, please first check this list to ensure that you haven't had your preferences disabled.

If you are on the list, please read the instruction on the page, to learn how to enable your PAUSE email, and to get your CPAN Tester preferences re-enabled.

Cross-posted from the CPAN Testers Blog.

If there is one thing that is more abundant than Hello World programs, it is password generators. Yet, one of the things I could never get right when working on my system administration job (all of them) was comfortable password generation.

I really haven't done a huge amount of work on Test::Harness since it was released as core, so I decided to take a look at how it is now. I was reading a blog post where someone commented that Perl's Test::Class doesn't offer a progress bar and I thought, that should be easy to hack into prove.

First, a very very big thank you to people who have filled in the survey and spread the word. After a little less than a week, we have 2500 responses. For this kind of survey, that kind of response is incredible, and many researchers will be envious of obtaining a sample that large, that easily.

The rate of responses is about double that of the 2007 survey which stayed open for about two months to obtain 4000 completed questionnaires. In all likelihood I'll close this survey down at the end of the first week of June (after 2.5 weeks), so to get more interesting data I'd like your help.

Please can you pass on details about the survey to less committed Perl programmers that you know - we don't just want to know about the core of the community, but also more casual users. This group are clearly more difficult to reach, so it's important to spread the word. Just point them to the link http://survey.perlfoundation.org and let them know that the work is sponsored by The Perl Foundation.

Event:   Birmingham.pm Technical Meeting
Date:    Wednesday 26th May 2010
Times:   from 7pm onwards (see below)
Venue:   The Victoria, 48 John Bright Street, Birmingham, B1 1BN.
Details: http://birmingham.pm.org/tech/next

Talks:

• Accelerated web development with Catalyst [Richard Wallman]
• CPAN Testers 2.0 - "I love it when a plan comes together" [Barbie]

Details

This month we welcome a returning guest speaker, Richard Wallman, who will be taking a look at how Catalyst has eased the development lifcycle of websites, from his own experiences. In addition I'll be looking at the progress of the CPAN Testers 2.0, and looking at some of the near future plans for CPAN Testers.

We are a few days away from the Portuguese Perl Workshop. We still have some spots left for the training sessions and are still accepting presentations submissions. Workshop official website here.

Just a quick note: if you can legally work in the UK and you're near London, drop me a line every once in a while if you're looking for work. I'll treat it with confidence. I keep getting contacted by recruiters and sometimes I want to pass leads on to others.

Actually, if you need to be sponsored for a work permit and you're really good at what you do, still let me know. Sometimes the recruiters tell me their company will sponsor permits.

Last Sunday, my brother and I had a discussion about Israel not allowing Noam Chomsky to enter the country because he is "a satanist nazi demon out to get Israel wiped off the map". It was mostly absurd but one point is worth mentioning: my brother claimed that Chomsky is doing a disservice to his goal of further expanding people's understanding of politics by lecturing where people already know oppression (Palestine) instead of where people are relatively oblivious to it (Israel).

While I know this is a touchy subject for most people, it still resounds in my head as the "I think you're wrong because you're not doing what I think you should do" claim which we're so used to in open source.

Recently Leo Lapworth updated several of the perl.org sites he's been working on to list the current stats for CPAN, as was previously seen in the footer of each search.cpan.org page. It's good to remind people (even subconsciously) just how big CPAN is. In his post Leo also wondered what the 20,000th distribution was. With the CPAN Testers database holding lots of stats about CPAN, as well as the CPAN Testers reports, it was fairly straightforward to extract some numbers. In fact it proved so straightforward I promised to include it in the CPAN Testers Statistics website.

I'm pleased to say I finally found some time to do just that, and have revamped the CPAN Statistics page to include the CPAN Milestones. Now you can keep up to date with what distributions are hitting some significant milestones.

Cross-posted from the CPAN Testers Blog.

Good advice for both building a house and performing a database update.

So you're writing an IRC script for irssi and you want to strip formatting codes (including colors, bold, underline, etc) from some variable. This is possible with s///, and google will show many (usually not very readable) examples.

But there's an easier way: irssi has an undocumented function called Irssi::strip_codes that does all the work for you. And since irssi exports all functions into your script's namespace unconditionally, you don't even need to type the Irssi:: part:

my $clean = strip_codes($dirrrty);

This will remove so-called “mIRC colors”, irssi's internal formatting codes, and ANSI color sequences.