blogs.perl.org

One of my problems related to Perl is that I'm not aware of a lot of things going on in the perl world, and there isn't a single place I can go to try and keep up. I suspect I'm not the only one. This post outlines an idea for a "perl community home page", where you could go to "keep up". I've whipped up a prototype, which is just a static page with a mashup of various feeds and static data.

So I noticed that CPAN is no longer king of the hill when it comes to sheer number of packages - rubygems took that title mid 2011 (when exactly depends on whether you include dev version and backpan which it lacks).

Rubygems had previously claimed the title based on dodgy numbers, but by the start of 2012 there really wasn't any doubt - that's a hell of a lot of uploaded code.

At first I was a little downhearted and disappointed, luckily I remembered a well timed piece by chromatic_x on why these sort of charts don't matter.

I looked into rubygems a bit to see just what was behind the massive explosion (admittedly still a bit in denial and looking for a smoking gun to explain), and found that it's a very very different kettle of fish.

That's a good thing for both ruby and perl - there's a lot that can be learnt from comparing and finding (and stealing, something both ruby and perl communities are both happy to do) good ideas.

[ This is cross-posted from the Ocean of Awareness blog. ]

In 1980, George Copeland wrote an article titled "What if Mass Storage were Free?". Costs of mass storage were showing signs that they might fall dramatically. Copeland, as a thought exercise, took this trend to its extreme. Among other things, he predicted that deletion would become unnecessary, and in fact, undesirable.

Copeland's thought experiment has proved prophetic. For many purposes, mass storage is treated as if it were free. For example, you probably retrieved this blog post from a server provided to me at no charge, in the hope that I might write and upload something interesting.

Until now languages were high-cost efforts. Worse, language projects ran a high risk of disappointment, up to and including total failure. I believe those days are coming to an end.

Small languages, shaped to the problem domain

1: Reversing camera switch. - That is, a switch to lie to the display unit, telling it we are reversing, so the reversing camera displays without the car actually moving backward.

1.1: Disassemble dash to be able to get at the display unit’s wiring. DONE.

1.2: Put a connector inline to the existing wiring. Should hold wires securely, have no visible changes to the car when external things aren’t connected.

1.2.1: Decide upon, and buy connector: DONE. Have gone with a Molex Mini-Fit Jr, 20-pin. This is the same connector as ATX power supplies (without the extra 4-pin connector), so are reasonably easy to find in general-commercial-availablity.

1.2.2: Figure out how to connect the connector, in the car, without major disasembly, or melting bits of the car.

1.2.3: Do so, at least for 12 V (accessory or always-on?) and REV. Other lines can come later.

I've completed the cpan(1) fastest mirror enhancement I described in Perl in Catincan, an open source crowd funding proposal. I wanted to test this new crowd-funding system on something small. Everything worked out and "Perl" is the first project to have a fully funded feature implemented. There were some bumps because I was the first, but once I sent in my bank details, I had the money in a day. The code stuff is done, and once CPAN.pm releases a few things in my pull request, cpan(1) will have the new feature.

I specifically choose to work on my cpan script because it's part of core Perl, and I'd like to see other people who contribute directly to core try out some of their own features under "Perl". For those who aren't a contributor, I'm also interested in what you'd pay and how much you'd pay for a feature to be improved, implemented or whatever. Maybe you'd only pay $10, but maybe 1,000 other people would pay $10 too.

I'm also thinking of what I'd like to try next. I have a list of things I'd like to do, but I don't have any idea of the things that many other people would like me to do.

I'll be doing a live webcast about Pinto with Randal Schwartz for FLOSS Weekly. Tune in to http://live.twit.tv next Wednesday, March 27 at 08:30 (Pacific Time) to the see the show. Your can send in your questions in real-time via the #twitlive channel on irc.twit.tv.

Pinto is a robust tool for creating custom CPAN-like repositories of Perl modules. You can fill your repository with any combination of private and public modules, and then build/test/install them using the standard tools (e.g. cpan, cpanm, cpanp). Since you control the repository, you'll get exactly the same modules every time. Pinto also has some novel tools for tracking and managing changes, so you can upgrade modules with confidence and control.

The Milwaukee Perl Mongers just held their second meeting and had another great turnout. JT from the MadMongers came to visit and presented two fantastic talks.

To help everyone know where to go when they arrived last night, we laid down some raptor tracks to follow :)

More pictures from the event can be seen on our Meetup site.

If you're curious about Perl and in the greater Milwaukee area, please join us!

It's a snow day and time to play. I have a cow orker who prefers to write all the business logic in SQL because he hasn't moved on from what he learnt in the 80's. Nice guy, but I suspect he has a hearing deficiency because he never listens to what I have to say (or he's got a nasty case of NIH). Yesterday, he happened to be getting on my last nerve, but that no longer matters for I will have sweet, sweet Revenge.

Today I started playing with dbic.

It's very poorly documented, but Test::Class::Moose also has reporting built in.

Here's how diag() all test classes from slowest to fastest, with time information:

Hi All

OK. After a bit of pain I've set up an empty database for the
MusicBrainz database.

In particular, where they say 'sudo cpan Carton' you probably want 'cpanm Carton'.

This exercise was because, astonishingly, one of the users of my module GraphViz2 had doubts about it handling 149 tables spread over 4 schema.

The version of dbi.schema.pl shipped with GraphViz2 V 2.07 needed a patch to handle multiple schema, but after fixing that, you can view the SVG in all its ghastly glory.

Firstly, set up you env vars thusly:
env | grep DBI
DBI_PASS=musicbrainz
DBI_DSN=dbi:Pg:dbname=musicbrainz_db
DBI_SCHEMA=musicbrainz,cover_art_archive,report,statistics
DBI_USER=musicbrainz

Then the command is:
dbi.schema.pl svg musicbrainz.svg > musicbrainz.log

Further, you can download this set of files:
o musicbrainz.svg (size: 257,156 bytes)
o musicbrainz.log (output of dbi.schema.pl, containing the DOT file)
o dbi.schema.pl (patched)
o tables.log (the list of 149 tables as output by Pg's psql)
here.

I'll release a new GraphViz2 shortly.

[ This is cross-posted from the Ocean of Awareness blog. ]

The influential Design Patterns book lays out 23 patterns for programming. One of them, the Interpreter Pattern, is rarely used. Steve Yegge puts it a bit more strikingly -- he says that the book contains 22 patterns and a practical joke.

That sounds (and in fact is) negative, but elsewhere Yegge says that "[t]ragically, the only [Go4] pattern that can help code get smaller (Interpreter) is utterly ignored by programmers". (The Design Patterns book has four authors, and is often called the Gang of Four book, or Go4.)

In fact, under various names and definitions, the Interpreter Pattern and its close relatives and/or identical twins are widely cited, much argued and highly praised [1].

I adopted PDF::Report a couple of weeks ago after contacting the authors, who were happy to provide me with the privs I needed on pause, since then I've created a github repo but not had a chance to do any of the work I've been planning.

Before I start messing around with PDF::Report too much though, I'm doing housekeeping.

- so first task is to apply the patches in the current rt.cpan.org bug queue and close them (2 down, 1 to go).
- also, now that it's on github I've added the metadata for that and the perl license to the Makefile.PL so that it's a bit nicer.
- I've also updated the pod so that it's got more of what you expect - a SYNOPSIS and more detailed pod will follow in the next release (and/or possibly the next one)

Deplyoing Dancer under debian using apache2 is really easy:

• libapache2-mod-fcgid
• libplack-perl
• libfcgi-perl

Alias / /usr/share/myapp/public/dispatch.fcgi/

And you're done! :)

Often when deploying application one may face the risk of divergence between testing and production environment. Even though you have a stage servers `like production one', it'd be reasonable to check distributive in production environment before release is happened. I would call it `early` testing. Yes, of course, some subtle bugs will arise only in runtime phase, and unit test cannot cover it all, I say here about prerequisite unmet issues. In perl world unit tests and prerequisites checks are executed in standart way. One follows standard procedure, when installing things.

I put here example for Module::Build based project, but with ExtUtils::MakeMaker it's almost the same:

perl Build.PL # check dependencies and generate build file
./Build 
./Build test # run unit tests

So, why not to automate this process in continues integration approach, like for example Jenkins does?

Note: this post assumes you have Test::Class::Moose version 0.06 or higher (on its way to the CPAN now).

By now you may have heard of Test::Class::Moose. I wrote this to solve a need that many people have: they want the awesomeness of Test::Class, but the modern OO facilities of Moose.

Test::Class::Moose isn't for testing Moose classes, it's for testing anything you would have previously used Test::Class for, except that now you get Moosy (Moosee? Moosey?) goodness to go with it. I'll be attending YAPC::NA 2013 in Austin and I've pitched a Test::Class::Moose talk and, even if it doesn't get accepted, I figured I should at least write the slides. One of my most common uses cases (and and itch I always rescratch whenever I use Test::Class, Test::Class::Most or, now, Test::Class::Moose) caused one of my slides to have too much code.

So now it's fixed, released to the CPAN, and available for everyone to tell me it's "too magical" (a complaint I've heard in the past). Here's the problem and how I solved it.

Perlnews.org has been going for about 2 years now and keeps going well, but we want to ramp it up... a bit... (we want a couple of stories a week really). We are now feeds www.perl.org homepage as well.

So if you have a big event in your Perl project, new major release, or you hear of Perl being used for something that warrants publicity - please let us know.

http://perlnews.org/about/ lets you know about our rough submission policy - but if in doubt please submit and we'll let you know from there.

We are also on the look out for editors - let us know if you are interested.

You can find us on irc.perl.org #perlnews

Slowly, but the Perl Maven site is gaining popularity among people looking for information about Perl. I'll write about the stats later.

Last week Felipe Leprevost asked me if I'd agree for him to translate the Perl Tutorial to Portuguese. I was happy to say yes as I believe having a decent introduction to Perl in your native language can make a big difference, even if later on you'll need to improve your English.
He made the translation and we already made the first article public: Instalando o Perl, imprimindo "Olá Mundo".

There were also several people who offered their help. This is awesome!
Thanks Felipe for your initiative!

The source of Perl Maven on Github

In order to make it easier for us to collaborate I set up Github repository for the Brazilian Portuguese files, and I also made the source of Perl 5 Maven available to make it easier for him to fetch the original English sources. The format is the horrific result of combining PODish with XMLish.

One of the most challenging aspects of website design is presenting information to users in such a way that appeals to the majority. But when advertisers are also part of the equation, a balance needs to be made between the end user's experience and the needs of advertisers. Because of this, we decided to use Perl for our image rotation needs.

Although in the past we used Perl on a variety of websites to rotate images, this task was a bit more complex. We needed a lightweight solution to serve rotated banners to tens of thousands of visitors daily. With an overhaul of our previous rotation code, now written for 5.16.3, we were able to develop a server friendly image rotator that works well in a shared hosting environment.

Again a lovely bike ride to the venue, this time with some air pressure trouble in the front wheel. Then a great day with talks, chatting and again excellent food.

And then it was already over.

THANK YOU ORGANISERS!

Thank you Wendy for the photo.

And thank you sponsors.

See you in Bern next week,
:m)

chris fedde asks How do we know when a CORE module is deprecated?. I don't know what was there originally, but it set off a lot of fingerpointing and posturing, and nobody answered the Perl question for the rest of the universe that finds it that post through Google!

perlpolicy says

As of Perl 5.12, deprecated features and modules warn the user as they're used.

There's the deprecate module which provides this warning. A module is deprecated for at least one cycle before it's actually removed. That doesn't help much if you skip over several perl versions.

Module::CoreList tracks deprecated modules too.

And, as one commenter, mentioned, the fallback is for people to read the perldelta pages to find the changes between the version they are using and the version they want to upgrade too.

The information is out there, and as programmers, we have everything we need to play with it however we like. :)