By far my most popular module on CPAN has to be Facebook::Graph, and this is an interesting week for Facebook::Graph, so I thought I'd post a little blog about it.

For anyone who may have been affacted by the upgrade to LWP, the situation should now be resolved. David has put in place a 3rd party verified SSL certificate on the Metabase server, so all submissions should now be able to resolve certificate authenticity.

If you have implemented any short term fixes, you may need to remove them, before accepting the new certificate.

We now return you to your scheduled programming :)

Cross-posted from the CPAN Testers Blog

Version 0.84 of Padre, the Perl IDE, has just been uploaded to PAUSE.

This release continues down the path of improvements, bug fixes and translations. The changed release process seems to have improved the translations committed to Padre prior to release, which is a big win for Padre in the multilingual stakes. The efforts of the translators are greatly appreciated by the Padre team, and I'm sure all speakers of a language other than English when they see their Perl IDE of choice in their native language.

Working on a large project, and Padre is certainly that, you appreciate the efforts of those who contribute a lot and those who contribute a little, it all makes a big difference. What we don't always see is the persistence of some of the contributors to actually make a big difference in the ultimate release that makes it to CPAN.

I've had the pleasure of exchanging several emails with Dave Rolsky, author of a new OO tutorial on the subject of whether to introduce treating objects as the underlying hash reference.

He says he won't include even one example because "it really doesn't send the right message. My revisions to perlobj will explain how to implement accessors using the object as a hash reference."

I was shocked, because I find I need to visualize my object's data structures. Also, in several cases, reading or writing attributes directly allows me to implement some needed functionality.

I gave one example of this in a previous post..

Dave suggested the reason I needed to break encapsulation this way is that

1. I haven't designed my objects properly or

2. I haven't taken advantage of a full OO framework.

He concludes that I'm using the same coarse hammer to solve all my programming problems, because I'm simply not aware of better solutions.

Those are interesting criticisms.

I spent a good few hours today attempting to use the MailboxGUID returned from the WMI Exchange provider to search for the associated Active Directory account, using the msExchMailboxGuid attribute.

Here's two functions I came up with in the end. One to convert MailboxGUID to something that a search on msExchMailboxGuid will like:

We've decided we're gonna start releasing Dancer under codenames that relate to people who've worked on the release.

This release (1.3020) we've seen the continued (and blessed!) involvement of a one "Michael G. Schwern". To some of you he might just be a "mike" or "michael" (or perhaps "the schwern"), but none of us in the core knew Schwern personally before his involvement with Dancer, and this came as a very welcomed and pleasant surprise.

Considering the storm of issues and pull requests done by Schwern, we decided the next version should be named after him, hence "The Schwern Cometh". :)

• 6 contributors
• 6 bug fixes
• 12 features and enhancements
• 10+ issues closed

I really do see this as exceptional work. Other than Schwern I also want to thank Naveed Massjouni and Maurice Mengel for their contributions to this release (and any previous release!).

In the near future we'll also unveil the most elaborate hooks subsystem in the micro web framework world. I already know whose names will be splashes on that release. :)

If you're an existing CPAN Tester, and have recently upgraded LWP, you may have noticed that your report submissions have been failing. The reason being that LWP::UserAgent now requires that any https protocol request, needs to verify the certificate associated with it. With the Metabase having a self-signed certificate, this doesn't provide enough verification and so fails.

In the short term if you don't need to update LWP (libwww-perl), refrain from doing so for the time being. For those that have already done so, or have recently built test machines from a clean starting point, you will either need to wait until we have put a long term solution in place, or may wish to look at a solution from Douglas Wilson. Douglas has created a "hypothetical distribution", which you can see via a gist.

Others have also blogged about the problem, and have suggests and insights as to how to overcome this for the short term:

• CPAN::Reporter, Transport::Metabase, and libwww-lwp 6 by Douglas Wilson
• CPAN::Reporter fails to send through Metabase with new LWP 6 by Randy Stauner
• SSL host checking and LWP::UserAgent by Colin Newell

We will have more details of the longer term solution soon.

Cross-posted from the CPAN Testers Blog

Paul Weller once sang of "a new direction. We want a reaction. Inflate creation." All three could be attributed to why two major events in the Perl event calendar started in 1999, and now happen all around the world today. The two events, The German Perl Workshop and YAPC::NA, both were a new direction for Perl events and specifically a reaction to more commercial events. They both also brought a new creativity to the Perl community.

In 2011 we now have YAPCs, Workshops and Hackathons happening on a monthly basis somewhere in the world. They are still very much organised by members of the Perl Community, and bring together a diverse group of people to each event. They often inspire some to create Perl events themselves. However, that initial enthusiasm is often quickly followed by panic, when the organisers start to figure out what they need to do to make a great event. Which is where a book might help.

In the first and second part of this post we looked at how I used Perl's Test Driven Development to help port Spreadsheet::WriteExcel to Excel::Writer::XLSX.

The first two posts dealt with tests at the unit and class level. At the package/module level I was able to test the output of Excel::Writer::XLSX against files generated by Excel.

The "Whatever-Star" was at first alarming to me! I first noticed it when I learned how to shuffle an entire list. The Whatever-Star can do some other stuff, too. But that's ok, we'll start with this.

my @shuffled = < alice bob carol dave erik frank >.pick(*);

Now... in the past I've tried ".pick(1)" which gets me one name at random. Then ".pick(2)" will give me two, and not repeat. If I put in too many then it'll only give me back what it can, in this case all six names. But ".pick(*)" ... that doesn't even look valid! The documentation says (though I can't recall where) that it is the same as ".pick(Inf)". When I picked more than there were, it stopped when there was nothing to pick. So this makes sense... try to pick an infinite number and we'll just get them all. Nice. Still kinda weird about the '*' though.

In the p5p discussions of Dave Rolsky's new Perl OO tutorial and OO recommendations, Johan Vromans and others have mentioned that in good OO programming, one should not violate encapsulation by directly accessing an objects underlying data structure.

$self->{foo} = "Look Ma! No encapsulation"; # don't do this, they say

In general that is true, but not always, We should avoid absolutist language, especially in tutorials. I'll come to an example of that.

For Nama, I generally use a setter with this syntax:

$self->set(foo => "bar");

The set method (inherited from a parent class based on Object::Tiny) makes sure the key is a legal one.

Because it looks distinct, I'm not likely to use it unless I want really write access to that attribute.

This simple approach allows me to manage object attributes culturally, i.e. without specifying them as read-only or read-write. In an app of 13k lines, the 'set' method appears just 110 times.

Анонс выпуска №1
Тема: Интервью с Андреем Шитовым

В следующем выпуске YAPP наших слушателей ожидает интервью с Андреем Шитовым - Perl программистом, автором perl6.ru, организатором Московской группы Perl программистов (Moscow.PM), организатором всевозможных Perl мероприятий в нашей стране и за ее пределами.
Мы поговорим с Андреем о будущем языка Perl и его шестой реинкарнация, о перспективах языка, о месте perl-программистов в обществе, о проектах Андрея, его увлечениях, обо все что покажется нам интересным. Если и у вас есть какие-то вопросы к Андрею Шитову, то отправляйте их нам и мы постараемся задать их во время нашего интервью.
Свои вопросы Вы можете писать в twitter: twitter.com/yapp_ru, по почте: yapp_ru@gmail.com, в jabber: yapp@demond.org или в комментариях к данному анонсу на blogs.perl.org по адресу: https://blogs.perl.org/users/perl_demon

The SF Perl Mongers next meeting will be on Tuesday March 22nd, at 7pm. Jonathan Swartz will be introducing Mason 2.0.

Mason is a Perl-based templating framework for generating web pages and other dynamic content. Over the past decade it has been used to generate thousands of web sites large and small, including Amazon.com, Target.com, Salon.com and del.icio.us.

Version 2.0 of Mason was released last month, twelve years after its initial incarnation. It has been rearchitected and reimplemented from the ground up, to take advantage of modern Perl techniques (Moose, Plack/PSGI) and to add long-desired features and syntax.

Jonathan Swartz, the original author of both Mason 1 and 2, will present Mason 2's new architecture and improvements and show how it fits into the modern Perl web development universe.

For a summary of what's new, see

http://www.openswartz.com/2011/02/21/announcing-mason-2/

and for documentation and download, see

http://search.cpan.org/perldoc?Mason

Announcement posted via App::PM::Announce

RSVP at Meetup - http://www.meetup.com/San-Francisco-Perl-Mongers/events/16408904/

Stupid Unix Tricks: Workflow Control with GNU Make. So simple -- it's brilliant! (And so brilliant, it is simple.)

Having read commentary about coding practices, meditated, contemplated, posted a blog entry about my app and begged for constructive criticism, I found my way into a significant refactoring.

I haven't seen much about the step-by-step process of dividing and modularizing code. Here how I am approching it.

The app already uses OO, but suffers from some 260 global variables and about 6k lines of code in the main namespace.

I broke that code into about 30 different modules, testing after creating each new module, with the help of git for source control, and a couple scripts showing which files and in which subs each variable appears

Most modules still occupy the same namespace, however have access to only the minimum necessary subset of global variables. I did this using a structure like this:

[Audio_engine_setup.pm]

 package main;
 our ( $sampling_frequency,.... )
 sub configure_freq { say "configuring soundcard at $sampling_frequency" }

We have a non-Moose class but want to make a Moose subclass of it. In the first post, "Subclassing Tricky Non-Moose Classes: Don't Do It", we looked at a way to extend non-Moose classes without actually subclassing them. It is pretty straight-forward, and typically will cause less headaches.

Sometimes that method might not meet your needs, and you might really want to make a Moose subclass of a non-Moose class. This tutorial will get you started with a couple modules that will help you do just that: MooseX::NonMoose and MooseX::NonMoose::InsideOut.

The nitty-gritty

If you're looking to get your hands dirty and find out how this really works, your first stop should be Recipe 11 in the Moose Cookbook. It is optional reading for our purposes, though. It does a great job explaining how to subclass a common, blessed hash, non-Moose class "by hand," and points us to MooseX::NonMoose which handles those details for us.

Yesterday I booked my flights to/from YAPC::Europe 2011 in Riga. Yay!

I also started the traditional TravelTeams Wiki page, which you can find here. If you're planning to come, please consider adding your travel info to this page. Maybe you can meet up with some fellow Perl hacker at your departing airport, or meet somebody in Riga (and maybe share a cab to the hotel...)

Anyway, I'm very much looking forward to this years YAPC, especially since I missed the last one...

Next step: Submit talks...

So we launched the new look moonfruit portal site today:

http://www.moonfruit.com/

It got some coverage in techcrunch.

It uses the rather awesome Dancer.

I mentioned it on the Dancer-users list, who seemed to like it, and wanted to know more. Below is reproduced from a post to the dancer-users.

The main Moonfruit service allows users to create sites in flash in a handy draggy droppy way (it being flash).

To do this we have a sprawling, slightly legacy, (but getting much better) Plack based set of API's.

The plan was to upgrade the portal from this (which was basically completely static html).

To a shiny web 2.<whatever we're on now> dynamic system.

MF-Portal/lib/MF/Portal.pm MF-Portal/lib/MF/Portal/API.pm MF-Portal/lib/MF/Portal/Support.pm

1: Serving the HTML

I tweeted something last night knowing full well that few people see my tweets and most of those that do aren't programmers. So I decided to post here in case anyone else experienced the same problem.

I installed the new LWP (v6) last night via cpan.

The next time I tried to install a module my cpan client barfed red errors (see below). CPAN::Reporter was erroring when trying to send test results via Metabase.

I updated all SSL modules (cpan> upgrade /SSL/) and installed Mozilla::CA as suggested in the LWP Changes (and a tweet by miyagawa).

No luck.

I noticed something else in the LWP Changes file:

For https://... default to verified connections with require IO::Socket::SSL
and Mozilla::CA modules to be installed.  Old behaviour can be requested by
setting the PERL_LWP_SSL_VERIFY_HOSTNAME environment variable to 0.  The
LWP::UserAgent got new ssl_opts method to control this as well.

so I added this to my .bashrc and all is well again: