blogs.perl.org

Nagios is probably the most famous and used monitoring program on the market. It's free, GPL and has nice features such as object representation of data, inheritance, plugin systems, passive testing, built-in Perl interpreter, result caching, pipe interface, alert delegations and so on and so on.

I was looking over my old notes recently - I have a file where I keep ideas for projects among other things. These notes are really of any kind: implementation details, user requirements that should be met, project naming ideas. Among the potential projects for some later day is a Twitter client, for which I kept some naming notes. The thought process behind them was to somehow combine “Twitter” with “Perl” (not necessarily in an obvious fashion). I had even arrived at a conclusion.

With the benefit of retrospect, I have no idea what I was thinking.

I had decided that the right name would be “Twipple”.

This is a follow up, or rather extension to xSawyerxs Marketing the Entire Box (including the wrapper)

I completely agree, design is the first thing people notice about a project. If you do not put effort into the look of your projects web page then whether you like it or not it will have an affect on the perception of your project (and indirectly on Perl).

If someone (my list of projects is way too large at the moment unfortunately) has time I think there are two projects which would make a massive difference.

• Provide a Creative Commons licensed design(s) that anyone can use for a Perl project. Lots of us are not designers, so even if we'd like to make our projects look better we don't know how!
• See if it is possible to get CPAN redesigned, this is already the home to thousands of Perl projects, so improving this will have a massive impact.

Many of the Apple applications websites have a similar feeling (simple and clean), this is because they all use iWeb. Good design does not mean lots of design. It just means a clean page, and separating content under headings (rather than having a single page with everything just listed).

Though 1: Test::Class::Most fails on Perl 5.010001 -- but only on Linux. Not on FreeBSD, OS X or Solaris. I've already emailed the testers and hopefully someone can track down what's going on. I don't want to say "bug in Perl", but this is not platform-specific code, so it looks suspicious.

Thought 2: Can anyone please explain to me why anyone would want to buy a whyPad?

Thought 3: What does the following print and why? Results are the same for 5.10.1 and 5.8.9, in case you're wondering. Try and figure out the output before you run the code. I now know why it does this, but I was confused by the behavior.

For a long while now I've been wondering about some observations I've made of Perl, Ruby, Python and PHP in marketing terms. I'm going to discuss them here in detail, and I hope it will gain us some insight into better marketing understanding or at least not bore anyone.

I've understood through the years that projects with beautiful websites have a better chance of getting picked up by users (even when the project itself is purely command-line) and definitely gives much more credit to the encompassing layer (like the programming language itself).

I've also noticed that a rather large portion of Ruby-related projects have very beautiful websites. You might have noticed this yourself as well. I tried to understand how this situation occurred and had a few discussions at $work with people whose opinion I appreciate, one being a Python and PHP programmer (or, as I like to see him, a programmer who knows PHP) and the other being a Ruby, RoR and overall Javascript whiz.

Over the past year or so, I've been working on a project called Cil. It's a distributed issue tracker and if you don't know what that means, let me explain.

Cil is currently a command line tool. It saves it's issues, comments and attachments as plain text files inside your project in an issues/ directory. Some settings are read from .cil and also you may set some personal preferences in ~/.cilrc.

Due to the fact that all data associated with issues (bugs, feature requests, tasks) are saved as text files, it's really easy to check them in to Git and, if required, fix conflicts.

Aha, conflicts, that's gotta be painful. Well, it's not and here's why.

This subject really requires a whole series of posts, but for the moment I'd just like to lay out the basics of what's needed to integrate your Perl development process and Hudson.

First and foremost, you must be using some source control system. Doesn't matter if it's CVS, Subversion, Git, Mercurial, or Bazaar (Hudson supports all these), but you need to have this set up so that Hudson can both consistently check out your software and so that it can notice when to do another build.

Second, you need a test suite. It doesn't have to be perfect, or have 100% test coverage, but you need something that Hudson can run to verify your builds.

After uploading Test::Class::Most, I kept thinking and thinking about the fact that you automatically get strict and warnings with it. I started to think about my annoyance with test suites in general and am now thinking about doing this with Test::Most. I proposed this to Perl-QA and received three positive responses (two offlist) and no negative. It won't import "features" of 5.10, but instead of this:

use strict;
use warnings;
use Test::Most tests => 34;

You can just write:

use Test::Most tests => 34;

I like dispatch tables. Which means I use this kind of thing quite a bit:

$dispatch{$pieces_of_state}->(@args)

if exists $dispatch{$pieces_of_state};

Does that sub-routine call look ugly? I suspect it does. It would look nicer in javascript for sure:

dispatch[pieces_of_state](args)
vs
$dispatch{$pieces_of_state}->(@args)

But how much difference does the syntax really make? I understand the impulse to make perl look more like Haskell but I doubt very much that the extra noise from the sigils makes a lasting difference to the readability/maintainability of the code.

Which is not to say that notation is not important - it is - but it can only get you so far. You still have to understand the concepts behind the notation. I could use source filters and come up this something like:

dispatch :
pieces_of_state
args

Free of sigils and arrows but - well - so what? I still have to mentally reconstruct the text into "table", "condition", and "inputs" clauses.

What is more important in this case is why I'd use a dispatch table in the first place. I can
ruthlessly weed out:

* Irritating if-else clauses
* Obfuscating unless's
* Stupefying switch's.

In short the code becomes more concise. And more beautiful, at least to my eyes.

While you won't notice any changes, there have been biiiig upgrades at CPANdeps. Here's the diff.

I'd heard that MooseX::Method::Signatures incurred a substantial runtime performance hit. I wanted to test if that was true so I tried converting Hailo to use it. The result: Yes, it's slow:

Here's how long it takes (real time) to train Hailo with a new brain, the command is:

time hailo --brain megahal.brn --train /tmp/fortune.trn --no-progress

The results:

• Without MX::MS: 11.37s
• With MX::MS: 52.09s
• With MX::MS + no type checking: 52.84s

Interestingly If I don't do any type checking, I.e. just:

method foo ($one, $two) { ... }

Instead of just:

method foo (Str $one, Str $two) { ... }

MX::MS doesn't become any faster, even though it looks like it also has to check that the argument list is of a certain length and that none of the arguments are undef.

These tests can be reproduced by going to hailo's repository on github and checking out either the master, mx-ms and mx-ms-no-validate branches. Check out version f9786122a08 of master for the most accurate comparison.

I'm really tired of boilerplate. In fact, I hate it so much that I can't stand when I write this:

package Some::Test::Class;
use strict;
use warnings;
use base 'My::Test::Class';
use Test::More;
use Test::Exception;

Of course, you already know about Test::Most and Modern::Perl, so you could reduce it to this:

package Some::Test::Class;
use base 'My::Test::Class';
use Modern::Perl;
use Test::Most;

But that's still boilerplate. So here's what I've just uploaded:

It came to my attention via brian d foy's blog post that the next Nordic Perl Workshop will take place in Iceland - which sounds very interesting. At the same time I decided that I need to take a longish break after working very hard for the last two years. So I will combine my holiday with NPW!

My current plan is bike from Vienna via Prague to Berlin, spend a few days there to visit some friends, take a plane to Rekjavik, attend NPW, and then either cycle a bit more through Iceland or treck a bit (probably combined with public transport). Then take the plane back to Berlin and a train back to Vienna.

The plan still has some issues:

• Is it totally insane to cycle through Iceland in May (if any Icelandic person could comment on this, I'd appreciate that..).
• Maybe cycling from Vienna to Berlin takes to long or is boring. Then I could take the train to Berlin, and cycle from there to Copenhagen, fly to Iceland, and go back to Berlin.

Anyway, I'm really looking forward to this!

Hinrik and I have been creating a replacement for the well-known MegaHAL conversation simulator in Perl. The result is already on the CPAN as Hailo and the source code is available on Github.

MegaHAL has numerous problems that we sought to solve:

I've been working on a personal project lately and I decided that, amongst other things, I was going to use PostgreSQL. Some of you may recall that I had an interesting testing strategy for MySQL. The basic idea is that I don't want to teardown and rebuild the database for every test. Truncating a table is generally much faster than dropping and recreating it. However, if I leave the database up, how do I guarantee it's always in a pristine state? One way is to use transactions and always roll them back at the end of a test. That means, amongst other things, that I can't easily test "commit". You can make it work with nested transactions (if your database supports them), but "rollback" can cause issues.

There's also the problem that by breaking "commit", you're altering the behavior of your code somewhat. Plus, if you have more than one process, unless you can share the database handle, separate processes can't see what's happening in another's transaction.

San_Francisco.pm (SF.pm) started off 2009 with a bang! Fred Moyer took on the daunting role of President, and Joe Brenner stepped up to the unforgiving role of Speakers Co-Chair. Both leaders relieved X-President Quinn Weaver, who sheperded SF.pm for 6 years leading up to 2009.

A Meetup web portal was created at http://www.meetup.com/San-Francisco-Perl-Mongers/ which served to facilitate organizing meetings. Six Apart generously donated a conference space for monthly meetings on the 4th Tuesday of the month (as has been a tradition for the last 10 years). Matt Lanier, the founder of SF.pm, liasoned with Six Apart to obtain this arrangement. We started off the year with a 35 person meeting on how not to use memcached - http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/9432356/

The Perl QA Hackathon 2010 will take place in the lovely MetaLab, a grass-root non-profit hack-space in the middle of Vienna (more on Wikipedia). There will be lots of space, workplaces, sofas, wireless and wired network and a big fridge full of drinks.

Vienna.pm has also proud to announce that we will sponsor the hackathon with 10.500 Euro. We will reserve a small part for catering during the event, but most of the money will go into paying for transport and hotel of invited guests.

If you want to hack on a QA / Toolchain project, please add yourself to the Attendees page of the wiki.

Thomas Klausner,
on behalf of Vienna.pm and the Perl QA Hackathon 2010 team

I'm currently working at Blekko, Inc.; we're still in stealth mode, so I can't really say anything about what we're doing, except that it's really cool, and it's all in Perl.

Working for a startup is wildly different from anything that I've done before; there's an incredible amount of freedom, coupled with an equal amount of responsibility. I love working here.

I'm currently doing a lot of work on our build process, streamlining it and automating it. I'm running things under Hudson with a lot of support stuff to get Perl integrated into Hudson's very Java-y workflow. I'm holding back on details for the moment until I've submitted my proposal to OSCON, but once I've done that I'll talk more about what I've been doing.

I'm on a new team at the BBC. On the previous team, PIPs, we gathered BBC programme data for television and radio. The rest of the BBC could use PIPs to pull schedules, get information about Doctor Who (note, that's "Doctor", not "Dr."!) or understand how a radio programme is broken down into segments which might be rebroadcast on a different programme. The work was complex, but fun. If our system went down, large parts of the BBC wouldn't be able to update their programme data.