Perl Dancer Conference 2015 - Call for Papers

The Call for Papers for the Perl Dancer Conference 2015 in Vienna is now open!

We are accepting presentations in a wide range of topics, for example Dancer, Modern Perl, DBIx::Class, Perl "products" and security. Of course, we are open for any idea and submission.

The submission deadline is August 31th, midnight CET. Talks are reviewed and possibly accepted as we receive them.

Please use the online form for submitting your talk.

Questions? Feel free to ask! Either put a comment here or send an email to

MakeMaker among the stars

It is part of our solar system now.

Now that’s legacy.

Maybe the fault is, indeed, not in our stars.

Benchmark your failures

Ever given any thought as to what the expense of catching exceptions with Try::Tiny or even eval might be?

Recently a colleague was having some issues with a legacy codebase that was having requests exceed their nginx proxy timeouts. We discussed increasing those timeouts, but considered that a last resort.

One block of code being executed was along the lines of

eval { do_this() };
if (! $@) {
} else {
which may not cause your spider sense to tingle. Note that the exception that is caught is not used in further calculations, or even reported or logged. Any tingles yet?

There are several great tools available on the CPAN to help identify slow parts of your codebase, such as the Devel::NYTProf profiler, and packages to benchmark changes such as Dumbbench. Any attempts at optimisation without first profiling your code is certainly going to be premature.

Alien::Base 0.020 and #native

This week we rolled out the latest version of Alien::Base which includes a new feature and a bug fix. The most important change in this version are the two new avenues of communication that we have adopted, so I will discuss that first.

The first is that we have established the #native channel on to discuss interactions with native interfaces. This includes Alien in general, Alien::Base specifically, and we also intend it to be a place to discuss FFI (Foreign Function Interface or NativeCall), as there is a degree of overlap for the people involved. You can now click on a big red button from the metacpan page for the project that will log you into IRC and allow you to start asking questions (or complain at us if that is what needs doing).

Add a LICENSE file to your distribution - it's easy!

Every distribution should have a LICENSE file, that corresponds to the licensing information contained in your Makefile.PL.

You can create this file from the command line by installing App::Software::License - e.g. cpanm App::Software::License. Then, just invoke the software-license command.

More about YAPC::BR

So we have a new fresh face to our site.

Also there is still time to get a cheap plane ticket to come :).

The system that we are using to make the payment only works on Brazil but you can just drop an email to the organization and we will arrange everything to you.

I have to share with you that just changing the layout of the website the visits grow three times. Kind of obvious but the ugly site works ok with us from the community but not for "outsiders". Even to reach perl programmers that usually does not participate of the groups the "beautiful site" works way better.

Testing your sqitch changes

When you work on larger projects, you'll often find that database changes are hard. Multiple developers, working on the same project, changing the same tables, can be difficult. Database migration tools often (but not always), come with one or more standard flaws:

  • Reliance on migration numbers (in other words, two or more developers commit migration number 6 and get a conflict)
  • Reliance on an ORM, such as DBIx::Class (sucks for the Python devs)
  • Reliance on something other than the Data Definition Language, or DDL (sucks when your custom tool can't represent the stored procedure you want to define)

There are plenty of other ways database migration tools fail, but the best standard tool I've worked with so far is sqitch. Its documentation needs some work, including more explanations of how to deal with common failure modes, but it avoids the above problems and provides you with a rich set of tools to make database migrations easier for large teams.

However, its common failure modes include:

Grants for applications (vs. Perl infrastructure)?

Somebody asked me:

Is the Foundation mainly interested in grants to help fund work on Perl's own infrastructure -- the language itself, key modules, and other community projects -- or would it also be open to considering funding open-source applications created with Perl, but which don't primarily exist to support Perl itself? (And which, perhaps, might help further Perl's reputation, and provide the world with more high-quality example code?)

Our grants program does not specify such scope. So our official answer is: "just send a proposal for review". I also went through the historical grants, both approved and rejected, and found no grant proposals in this area.

Anyway, even without specific grant proposals, I thought it would be interesting to ask this question to the public. Should we fund application development Perl?

About 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 hosted by Dave Cross and Aaron Crane, with a design donated by Six Apart, Ltd.