blogs.perl.org

YAPC::NA now has a permanent Facebook page with a shorter URL:

http://www.facebook.com/yapcna

If you're a Facebook user, this is an easy way to keep up with everything going on at YAPC::NA 2012 and beyond.

In addition to our new Facebook page, you can also keep up to the minute by following our Blog, our RSS feed, our LinkedIn Group, or our Twitter feed.

Tom Christiansen's slides for Unicode Support Shootout "The Good, the Bad, & the (mostly) Ugly" should be required reading for anyone working in Unicode in my (unfortunately arrogant) opinion.

Recently I found some spare tuits and decided to spend them on MetaCPAN::API.

My main problem with the old MetaCPAN::API was that I had made a wrong design decision, and failed to take into account the flexibility of MetaCPAN. It really is flexible.

The second time around I decided I'll write it correctly, and test it thoroughly. I've moved to version 'v0' of the API (what was referred to as 'Beta API') and this helped clean up quite a bit. I was able to write it the way I wanted.

Tim Bunce (who I actually had the pleasure of meeting last YAPC::EU) had opened a ticket asking for complex POST requests. This got me thinking and that day I implemented complex GET requests, paving the way to the aforementioned POST requests.

So what's in MetaCPAN::API right now?

Last week I posted an article on how CPAN authors could expand their profiles on metacpan.org. Since then there has been so much activity that I thought a quick recap would be in order. I'm not covering all activity, so my apologies to anyone whose efforts have not been replayed here.

At the time of the article, 91 authors had logged in to MetaCPAN and updated their profiles. That number after one week is 240. That's still a very small fraction of total CPAN authors, but it's also an amazing start.

On or just after the day of my post, Mo added +1 to metacpan.org. So, if you haven't already, log yourself in and start upvoting your favourite distributions. There will be more info on +1 to come, but this is a first step in making CPAN a friendlier place.

The NNTP injection host that I use to feed comp.lang.perl.announce had moved, and for some reason I had hardwired the old IP address into my posting script. Once I got that sorted out, it looks like it'll be business as usual for CLPA once again.

Given HTML with certain "empty" tags that you wanted to manipulate via something like:


my $html = '<p><iframe src="..."></iframe></p>';
my $doc = XML::LibXML->new->parse_html_string($html);
# do stuff with $doc
$doc->toString();


You would end up with:

<p><iframe src="..."/></p>';

Namely, the "empty" iframe tag is going to get output as a single, self-closing tag.

But that's not valid HTML. Not even valid HTML5.

XML::LibXML::Parser has the setTagCompression option but this is no good here.

<hr/>, <br/> and <img src="..." alt="..."/>

cannot be written as:

<hr></hr>, <br></br> and <img src="..." alt="..."></img>

at least, not if you want valid HTML.

I hit upon the idea of appending a single space:

for ($root->findnodes('//iframe')) {
    $_->appendChild(XML::LibXML::Text->new(' '))
        if !$_->hasChildNodes;
}

which works, because an extra space inside a previously "empty" iframe, script or canvas tag would be harmless. However this approach will cause problems when you come across "empty" <textarea> tags.

<textarea></textarea>

is not the same as:

<textarea> </textarea>

We've been using Dist::Zilla at $work quite some time now.

For a while I feared the possible mistake of running "dzil release" on one of our modules or applications (we have quite a bit!) and thus releasing it to CPAN. We try to remove all generic parts of our code and push it as regular modules on CPAN so everyone can enjoy it (and we get feedback and patches and so on). This means that the rest of our code, what we keep on local repositories, are very specific to us. This cannot be released, obviously.

First job was fixing that. Easy enough. In your dist.ini:

[@Filter]
-bundle = @Basic
-remove = UploadToCPAN


Now if someone tries to release, it fails. Yay!

Next one was a feature I wanted for a while: to be able to get notified by email when a new release it out. I've searched CPAN and could not find anything that emails. So I wrote Dist::Zilla::Plugin::EmailNotify.

When watching videos at Tudou or Youku, both Chinese YouTube-like video sites, you'll often get one/two 15- or 30-second video ads at the beginning. Since I download lots of videos recently, my Opera browser cache contains a bunch of these video ads files, each usually ranging from around 500k to a little over 1MB. But there are also duplicates.

I thought I'd collect these ads, for learning Chinese, but I don't want the duplicates, only one file per different ad. The result: App::UniqFiles, which contains a command-line script called uniq-files. Now all I need to do is just type mkdir .save; mv `uniq-files *` .save/ and delete the duplicate videos, which are files not moved to .save/.

Hi Folks

I've written an article on the considerations accounted for in the process of re-writing a module, here Graph::Easy being recast as Graph::Easy::Marpa.

It's a separate docuemnt (the output of pod2html) so I could preserve the formatting to my satisfaction.

My GF recently published a book, The Girl in the Bunker, which has a ebook version and a physical version. This caused me to think about the future of books (also, given the fact that I will probably never get my thesis published as a monograph, I had cause to ponder). So my basic premise is that ebooks will be the larger market than physical books. The difference between the two will be that ebooks will be more like renting a book, see The Right To Read, while a physical book will be a true ownership position.

I used to worry, now, not so much. Here is my journey to less stress and worry.

Sometimes programmers have to develop applications for production environments that are less than ideal. By less than ideal I mean things like having a Perl version that was End of Life (EOL) December 16 2008, I am looking at you RHEL/CentOS 5.x. Add to that not being able to install CPAN modules or make other changes to the system. The setup I just described is far too common for developers (think shared hosting) and it is frustrating every time you run into it.

Getopt::Long has a Configure() function to let you customize its parsing behaviour, e.g. whether or not to be case-sensitive, whether or not unknown options are passed unmodified or generate an error, etc. However, this customization is global: it affects every piece of code using Getopt::Long.

Since I use Getopt::Long in a utility module, which might conflict with the module user using Getopt::Long along with my module, I need to localize my Configure() effect. I was about to submit an RT wishlist ticket pertaining to this, but some quick checking revealed that Configure() already has this feature.

Configure() returns an arrayref containing all the current options. If you pass this arrayref to it, it will set all the options. This way, you can save and restore options.

Thanks to the Getopt::Long author, Johan Vromans, who apparently has maintained this module since 1990!

Hi Folks

At the email thread you can see there have been no modules reported as released this month.

Anyone know what's happening? The precise reason doesn't worry me - it's just that I'm confused....

Ron

Anyone else having dreams of a four arg open?

open FILEHANDLE,MODE,REFERENCE,GIT COMMIT MESSAGE

Having spent many years working jobs that involved no Perl programming I felt I was getting rusty so I re-read "Perl Best Practices". It is 2011 now, I should checkout what new things have developed in the Perl world. I was pointed towards Task::Kensho .

Task::Kensho is a glimpse at an enlightened Perl. After reading that I decide to see what it could do for me right now.

I was writing a script and I need to slurp a few files. Under Task::Kensho::Hackery I see "IO:All combines all of the best Perl IO modules into a single nifty object oriented interface to greatly simplify your everyday Perl IO idioms." With boasting like that I expected a fast and simple solution. I was not disappointed.

use warnings; use strict; use IO::All qw(slurp); my @rcfile = io('rcfile')->slurp; my @delta_data = io('delta_data')->slurp; my @log_data = io('log-488')->slurp;

That little work and I was on my way to getting things done. I look forward to seeing what else Task::Kensho can help me with.

A heads up and last call for people using WWW::Mechanize::Firefox with Firefox 3.0.

I plan on discontinuing support for Firefox 3.0 due to moving to the native JSON encoder that exists starting with Firefox 3.5.

If you are a Firefox 3.0 user (for compatibility testing?), and really, /really/ need the support, please talk to me so that we can work on a solution that keeps the code small and maintainable for me. If nobody speaks up, I'll interpret that as nobody using Firefox 3.0 anymore, which is fine by me as well.

In other news, I now got several "portable" Firefox instances installed and modified the test files to test against all installed instances. This now tests Firefox versions 3.5, 4.0, 5.0 and 6.0 Beta.

Just after Sawyer X gave a quick review on my chapter 2, on Modern OO programming, I am making the second chapter PDF file available on the book website.

Before leaving you reading the document, I would like to make it clear that i really want to make this chapter this way, presenting first Moo, then Mouse, and finally Moose. I know that the order is not cronological. It is just the order of presenting, each time, a more complex module. I didn't know Moo, Mouse or Moose. I had to learn them all from scratch, and I did it in this order. And I liked it.

Other than that, please, comment and suggest any correction you find relevant.

Over the years I have been trying to get the perl community excited about hardware hacking, physical computing and the like.

I am encouraged by the feedback I have received and am excited to say that we are having a Hardware Hackathon at Pittsburgh Perl Workshop 2011.

While I have great support from Hans Scharler of ThinksSpeak and ioBridge I still need more help.

We need your ideas, dreams, coding, etc to help seed a great Hackathon. What would you do if only you knew ....

Come and help make it easy for perl stitch together the world of physical computing.

Hope to see you there.

We are still looking for more attendees, speakers and sponsors.

Oh and did I mention ... we have great coffee!

Gisle split out HTTPS support from libwww-perl into LWP::Protocol::https earlier this year when I wasn't paying attention. I needed HTTPS support for one of my Perl 5.14 applications and I wasn't reading the error message closely because I assumed it was business as usual with Crypt::SSLeay. Previously, I just installed that module and everything worked. Now I have to install LWP::Protocol::https to get everything to work. If I haven't done that, I get the error:

 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) <URL:https://www.example.com>

That's not the end of the story though, because the fancy new stuff is a bit more strict with the SSL stuff. For libwww-perl-5.837 and earlier, hostname checking was off by default. Now it's on by default. I can't just connect to any HTTPS server. By default, LWP::UserAgent wants to verify the certificates and so on. That can be a problem if the Certificate Authority root certificate isn't around:

I've moved all my code to Github, including cpXXXan and CPANdeps. I also split the monolithic repo that used to contain all my perl modules into 41 separate repos, one per distribution, using a recipe provided by Paul Johnson.