I'm still blogging five days a week, but obviously not here. That's largely because my new daughter is forcing me to choose where I spend my time and I can't blog too much about what I do lest I reveal trade secrets. So, just to keep my hand in, here's an ugly little "80% hack" that lets me find bugs like mad in OO code. I should really combine this with my warnings::unused hack and start building up a tool find find issues in legacy code.

A goal of the MyCPAN work was to start with an existing Perl distribution and work backward to the MiniCPAN that would re-install the same thing. I hadn't had time to work on that part of the project until this month.

The first step I've had for awhile. I've created a database of any information I can collect about a file in the 150,000 distributions on BackPAN. There are about 3,000,000 candidate Perl module or script files. That includes basics such as MD5 digest of the file, the file size, the Perl packages declared in the file, and the package versions.

The next step is what I've been doing this week: collect the same information on the files in a Perl installation, which is much easier to do. There's not wacky distribution stuff involved.

I had always been interested in writing a simple LISP interpreter. Well, had some free time today, and thought, why not create a parser that can return the results of mathematical expressions that are entered as LISP expressions. Nothing fancy, but here is a class that can take in a file containing math expressions and return the results of each line as an array.

From article Carmack: Direct3D is now better than OpenGL.

John Carmack, co-founder of id Software: "I actually think that Direct3D is a rather better API today. ... Microsoft had the courage to continue making significant incompatible changes to improve the API, while OpenGL has been held back by compatibility concerns. Direct3D handles multi-threading better, and newer versions manage state better."

Also from article: "While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, they usually have to be implemented via extensions, rather than the main API.".

Following up Stupid Unix Tricks: Workflow Control with GNU Make -- this trick works on any platform with a make(1) program, including Windows, QNX, VMS, and z/OS.

It also serves to de-couple dependency checking and the workflow execution engine from the rest of your program (with the caveat that your program may need to interpret the output from make(1).)

(And if you squint hard enough, make(1) appears to have the sequencing property of a monad.)

Seth Godin has an interesting take on "____ is dead" in his blog post, "Bring me stuff that's dead, please". To paraphrase him, no real work is done until an innovation is dead. So the next time you hear that Perl is dead, just laugh it off and get back to work. I know that I will.

I've written a couple articles on encapsulation issues in perl OO, especially with regards to home-grown versus full-framework OO.

I am told that finding my own solutions to get the behavior I want may lead to poor (dirty, unreliable) code when a better solution could come through a framework such as Moose.

I rolled my own perl OO for Nama, a multitrack audio recording app I've written. However, I'm ready to consider introducing an OO framework for the sake of learning, code quality, testing and maintenance. Provided that I can find satisfactory ways to solve my problems.

Here's a laundry list of (just two) OO features that I'd need or want to implement in a Mooselike framework. One is short and simple to describe, the other will take several paragraphs.

Inheriting field definitions

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/