RFC: Limiting grant duration

I am thinking about adding this to the grants operation rules:

If the grant does not finish within three times of the proposed duration or within two years, the grant will be considered a failure.

First of all, it should be noted that it won't affect most grants (see the reason 2).

Reason 1: Budget structure & allocation to new grants

TPF does not allow over-allocation of the budget. If we have 3 x $3,000 grants running and our budget is $9,000, no more grants can be funded.

If a grant worth $3,000 is running for five years, this $3,000 is stuck in the TPF safe. Even if we get good proposal, we cannot fund it using this money.

The aim is to increase liquidity of the fund.

Reason 2: If a grant runs more than a year, chance of failure increases

During 2009-2013, we managed 17 grants. Here is the breakdown:

CPAN.io, yearly boards and gamification

The CPAN once-a-week has been running for more than three years now, with several active leaderboards. NEILB introduced the monthly and daily releases competitions, and the notion of NeoCPANisms. CPAN.io extended the game to seven different contests, over more release types and periodicities.

Note: The CPAN.io Pulse also has [a post about what follows]((http://cpan.io/pulse/2015/02/new-cpan-board-and-all-yearly-boards.html).

Analysing CPAN Testers' Reports

The task

In the second round of the Pull Request Challenge, I was assigned Olson::Abbreviations. At work, we've been bitten by the ambiguity of the EST timezone, so I liked the general idea of the module. Moreover, there were some test failures reported at CPAN Testers Reports, so the task was clear: Make all the tests pass!

Always make_immutable (unless you have a very good reason not to)

One hears that __PACKAGE__->meta->make_immutable is a must all your Moose classes. ( edit, ht ribusushi: never immutate your moo classes, it'll inflate them into Moose classes automatically thus defeating the point). Here's a stark reminder of why.

I was doing some benchmarks on a web application that I've been moving from mod_perl to plack. Here's the performance of 350 requests forking off in batches of 7 before I remembered to make_immutable:

$ time perl 002-hammer_lightly.t 
# Total number of requests = 350
real    1m11.095s
user    0m3.003s
sys 0m1.336s

And after:

$ time perl 002-hammer_lightly.t 
# Total number of requests = 350

real    0m17.075s
user    0m2.202s
sys 0m1.160s

One line of code, nearly 5-fold performance improvement. And despite the shim upon shim I had to make to move the thing off mod_perl, it seems to be two to three times faster than the mod_perl app (using an apples to pears comparison method anyway).

Looking for YAPC::NA News?

It is very frustrating when there is a conference you want to attend and you can't get any information about it. It is even more frustrating when you are a conference organizer receiving complaints about no news despite all your efforts to keep people informed. Here is a guide to finding out what's going on inside YAPC.

Starting with the official channels:

The first and foremost way to find out what's happening with YAPC is yapcna.org. The home page of the conference site contains a news banner that will take you to recent announcements. It also has a list of links to places you might want to subscribe to receive information.

But wait, there's more...

New Djet blog entry

Moved to a new blog

Using Perl Dancer and Docker to create simple monitoring system

I needed a simple system to monitor events. I wanted to have a system where I can specify that object with some name is 'ok' or 'fail'. And I wanted the system to be able to expire statuses. In case there is no data for the object for a long time then the status should be automaticly changed to 'unknown' — to handle situations when script that sends data breaks.

I looked for several systems, but none suited me well, so I've written my own very simple solution with the name 'curry' (it is named after delicious indian dish, not after Haskell Curry =)

Here is the source code — https://github.com/bessarabov/curry

The system is a web server that is powered by Dancer and the system is bundled into an image with Docker.

I really like this way of creating web apps with Dancer & Docker. Every time there is a new commit in git report Docker Hub automatically builds new image.

Today’s bit of black perl

use 5.010;
{
    package F;
    sub new { bless {}, shift }
    sub me { $_[0] = 'surprise!' }
}
my $f = F->new;
say $f;
$f->me;
say $f;

Output:

F=HASH(0x7f9daa025c80)
surprise!

Teehee…

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl and offering the modern features you’ve come to expect in blog platforms, the site is run by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.