blogs.perl.org

I recently moved to a new BBC team (if we go down, iPlayer goes down too) and am getting used to working in a different environment with different tools. One issue is that certain tools I'm used to working with are not available (Test::Most being the most noticeable) and getting them added to all environments is a bit bureaucratic (all things considered, shipping new tools should be treated with more caution at many shops than it tends to be). Thus, when I accidentally merged to trunk with a test which contained Test::Most, I was embarrassed.

That's when the rather obvious answer occurred to me. I don't want to accidentally commit use of that module, but it's easy to do. Thus, here's how I do it safely:

Yesterday I gave a talk on Moose (the post-modern metaclass-based object system for Perl 5) in TelAviv.pm. The slides are available on slideshare. They aren't a lot of slides because I mainly wanted to give an introduction to Moose for beginners and the gist of the lecture is me speaking, so the slides can't really express that.

Now, regarding the talk. There were few people present, which was a bit unfortunate but I'm assuming it's somewhat due to the change in location in the university. It was difficult to find, I have to admit. However, it's a new place, bigger and more comfortable.

If I could do it over again, I would definitely want more people and more participation so we could give some live examples instead of trying to squeeze it out of people. But overall, I'm happy with it.

I scheduled with Gabor to do the lecture on March in Rehovot.pm. If you're near Rehovot, stop by, say hello and learn how to use Moose!

I want to thank Shlomi Fish for organizing TelAviv.pm, the lectures (including this one), the promotion, receiving a free guest room from the university and all the other annoying/difficult things most people don't feel like doing.

I've released a new version of Cantella::Store::UUID. (git) It features one incompatible change, but I figured it was OK since I'm pretty sure nobody is using it and it is reasonably new. I just couldn't live with having one lone method named so awkwardly. The POD was all updated and improved and two new methods were added, which allow the user to search for files in the storage directory and perform some action on these files. I don't really intend for these methods to be used a lot, since they will take minutes to run on most systems and be incredibly IO-intensive (depth-first search of the entire storage tree, which could be hundreds of thousands of nodes). I use them mainly for maintenance operations and you should probably too.

Spreadsheet::WriteExcel now supports Area, Bar, Column, Line, Pie, Scatter and Stock chart types. I think that I'll leave it at that for now and concentrate on the sub-types within those charts. Bubbles and Doughnuts and Radar will have to wait untill later. Anyone use those?

Here are some example programs with screenshots and here is the output from the Stock example:

You know, I really would love to have a heart-to-knife conversation with developers who use complex unless conditions. While trying to tease apart some code, I came across this gem:

unless ( $blocklist->has_block_with_id( $db_obj->id )
      || ( ! $allow_duplicates 
        && exists $episode_ids->{$db_obj->version->episode_id} ) ) {

To be fair, code grows over time and it's easy to understand how issues like this crop up (and this is a fairly old bit of code), but it took me a while to make sure I understood this. My naive conversion of this to an if statement failed. I had to reduce it down to its simplest components and do a truth table:

For two weeks we've been working hard on defining a rather complex construct of DNS zone files, using multiple servers for multiple domains with cross referencing them and a lot of other complex-sounding terms.

We wrote DNS tests for the zones to make sure all the servers are configured correctly and the general DNS fetching provides correct information. This turned out to be quite difficult.

The original script is 130 lines. This is without taking into account even more testing we wanted. There was a lot of analyzing done which was rather repetitive and the overall code was ugly and not fun to read (to put it in mild terms). I decided to write a testing module for DNS zones - Test::DNS.

Using Test::DNS, we rewrote the script with a lot more options, which we wanted. The resulting script (with the addons) is 20 lines. It's clean and readable.

I started with what I thought would be a simple Module::Starter subclass. I wanted to modify Module::Starter::Smart, which knows how to add a new module to an existing distribution, to properly handle an existing MANIFEST and MANIFEST.SKIP. I thought I could just override create_MANIFEST (RT 53339). Once I overrode that, however, I wanted to make a couple of additional tweaks, things weren't so easy.

Although I'm using Module::Starter as an example in this post, I could just as easily use one of my own modules to illustrate the same thing. I've just been hacking on Module::Starter for the past week so I can get it into shape for use in the next edition of Intermediate Perl. I'm not a particular fan of the module, but its the best place to start if you don't know you want to use something else.

My problem started when I also wanted to handle some DWIMery in the --dist command-line parameter:

You have another option for GUIs with Perl.

Find it on CPAN.

To any and all recruiters who might stumble across this blog entry, here's a useful tip: be courteous.

I'm not looking for work, but I certainly understand why you contact me on LinkedIn or via referrals. That's how you make your money and while some people I know loathe any contact from you, I shrug it off as a fact of life. I am contacted by enough recruiters that I don't remember all of you, but there is one group of you I strive to remember. The email exchange almost always go like this:

You: I have a great opportunity that I think is perfect for you.
Me: I'm not looking for work, but if I were, here are my minimum requirements.
You: ... crickets chirping ...

Excuse me? I admit the fact that I'm not looking for work is not appealing to you. I also admit the fact that the "great opportunity" as a junior developer doesn't fit me. I don't, however, accept that you can initiate a conversation and then not so much as acknowledge my reply once you realize that the huge pay cut you tried to entice me with isn't enticing.

I do remember your name and when you contact me again, I'll remind you why I won't do business with you.

So, last blog entry I mentioned Dancer and that I want to use it as CGI (since it's Plack-aware) but I don't know how.

Nick Spacek commented on my entry saying that if it supports Plack/PSGI, there should be an easy way to run it as CGI.

Later that evening I sat down for hummus with my girlfriend (hummus is awesome, ok?). After talking to her about it, I decided to take a minute to check online on my phone if anyone has any explanations on it. In the first 5 results, I found a post Alexis Sukriah (who wrote Dancer!) wrote that same day, regarding my post, showing how to use Plack to run a Dancer app under CGI!

Case in point:

use Plack::Server::CGI;
use Plack::Util;

my $psgi = '/path/to/your/app/app.psgi';
my $app = Plack::Util::load_psgi($psgi);
Plack::Server::CGI->new->run($app);

... and the web server configuration to use it.
(example shown on Alexis' post)

Problem:

I've been upgrading some systems at work recently. Using local::lib so I can test it first without worrying about rolling back being a pain (which it could be with our current build system).

We've had most of our CPAN modules installed for several years and haven't had the need/time to upgrade them. But with the advent of Catalyst 5.8 using Moose and other great projects we'd like to get involved in, such as Gitalist I bit the bullet and started installing into my local::lib so I could then run our tests against it, but then I hit a few problems....

Now remember when I said we had old module? - I'm talking some that haven't been upgraded in 4+ years (they only get upgraded when a newer version is set at a prerequisite).

Our current project at my job is based solely on rather sophisticated object model, we've chosen MooseX::Declare as one of our main helpers. We are very happy with compiletime argument checks, I guess it saves us a lot of debugging time. Unfortunately our app performance was far from satisfying; the profiling showed it was MXD's fault. Also, we found an enlightening benchmark .

The problem was solved by implementing a tool that allowed us to have two variants of our codebase: development and release. Release is prepared by translating method declarations with method signatures into plain perl subs with parameters parsing. This job is done by undeclare.pl , it uses PPI to parse and transform .pm files.

Some of our domain-specific tests now run more than 10 times faster.

So I hear that the next Perl QA Hackathon will be in Vienna. What should we accomplish? The following is not complete as I was so focused on the areas I was working on that I really didn't follow the other areas.

In the first QA Hackathon, in Oslo, we nailed down a bunch of issues we'd like to see in TAP. We clarified part of the spec and started work on tests for TAP itself. (And convinced Nadim Khemir to release App::Asciio).

The second QA Hackathon, in Birmingham, UK, saw the creation of nested TAP (i.e., subtests).

The third one, I think, should result in either better parsing of nested TAP or shoe-horning structured diagnostics into TAP.

Sometimes a good time means relaxing with CPAN, reading a POD of something and trying to learn it. At least for me.

Last weekend I treated myself to playing with KiokuDB and Dancer. I'll write on KiokuDB later, this post is on Dancer.

Dancer is a Plack-aware web application framework written by Alexis Sukrieh. It has a built-in simple templating system, but supports Template::Toolkit (a must for me), routes handlers (named matching, regex matching, wildcard matching), simple rapid prototyping and support for multiple configurations and allows separate configurations for separate environments and stages of the software.

After playing with it for a rather short time, I already implemented CRUD. The code comes out clean (which I love), understandable and simple. Pure joy. You should totally check it out!

The only problem is that I want to write an interface which will be hosted on someone else's computer, which only supports CGI. I have no idea how to run it as CGI. Any ideas?

Update: Alexis Sukrieh wrote on how to do this here. Next post will reflect this!

Cross-posted from the CPAN Testers Blog.

Last month CPAN Testers was finally given a deadline to complete the move away from SMTP to HTTP submissions for reports. Or perhaps more accurately to move away from the perl.org servers, as the amount of report submissions has been affecting support of other services to the Perl eco-system. The deadline is 1st March 2010, which leaves just under 2 months for us to move to the CPAN Testers 2.0 infrastructure. Not very long.

Two ago I began writing the beginnings of what was to be the first Cantella::Data::Tabular renderer class. The idea was to render a Cantella::Data::Tabular::Table object into a plain text table. I failed miserably. Within 5 seconds I got wrapped up on issues of formatting and how to render data and data-types. Eventually I resorted to #moose for ideas and rafl pointed me towards some code of his. We agreed that it would be mutually beneficial to use if I got to use his code as long as I separated it from its original package, and packaged it separately so it could stand alone.

A couple of years ago I had a simplistic way to run Test::Class methods on my use.perl blog. Unfortunately, it littered the test class with $ENV{TEST_METHOD} assignments. I should have fixed that. Here's a better version:

noremap <buffer> <leader>tm ?^sub.*:.*Test<cr>w"zye:!TEST_METHOD='<c-r>z' prove -v %<cr>

With that, if your cursor is inside of a test method, typing ",tm" (without the quotes and assuming that a comma is your leader), will run just that test method.

If you can't run your Test::Class classes directly, see my in-depth tutorial on Test::Class.

Ringo Starr:

I didn't play drums to make money. I played drums because I loved them. [...] It was a conscious moment in my life when I said the rest of things were getting in the way. I didn't do it to be [be]come rich and famous, I did it because it was the love of my life.

When asked why he robbed banks, Willy Sutton is purported to have said he did so because "that is where the money is". Mr Sutton set the record straight for his biographer:

I never said it. [...] Why did I rob banks? Because I enjoyed it. I loved it. I was more alive when I was inside a bank, robbing it, than at any other time in my life.

Money moves job indexes. But where the following for a language is only cash-driven, that following may become as broad as the ocean, but it will never be more than a millimeter deep. And it will dry up the moment the cash disappears.

Working on a book about something is one of the best ways to discover issues with interfaces. When I have to explain some process and think about all the ways that things can go wrong so I can make the explanation as bulletproof as possible, all sorts of issues pop up.

I'm working on the distributions part of the next edition of Intermediate Perl. All of the h2xs stuff is being shoved into a couple of paragraphs and everything else now uses Module::Starter. I'm not a particular fan of the module (I have my own: Distribution::Cooker), but I do think it's the best thing to use if you don't know what you want to use.

When just registering to use.perl.org, I started using RSS feeds. Currently I have roughly 25 or so subscriptions, which is lightweight, I know. Mostly are specific Perl programmers (mst, nothingmuch, elliotjs, dagolden, drolsky), some are aggregators, a few friends' personal/political blogs, etc.

Work-wise, the best feed I've had was the "use.perl.org generated feeds", which shows me on a daily basis which modules/distros were released. It helps me by:

• Keeping me up to date with modules I use.
• Keeping me up to date with modules I want to use.
• Keeping me up to date with modules I intend to use (once they go stable).
• Keeping me up to date with modules I don't even know that could benefit my work.