Submit a talk for YAPC::NA 2012. We’re especially interested in talks on real-world Perl apps and quintessential Perl 101 talks, but we’re open to any ideas you have. 

[From the YAPC::NA Blog.]

I've been working on a document engine called Mojito. It supports a subset of the MojoMojo formatters. I was thinking it might be cool to see how my MojoMojo documents look like through the eye of Mojito. The idea being that I tap the documents in a MojoMojo store and render them with Mojiito::Page::Render. Further, I put the pieces together by making a Web::Simple application of it.

For App::fooapp type distributions then you might want the README etc generated from a specific file. Add this to dist.ini:

main_module = bin/fooapp
; btw, semicolon leads a comment, in case you forgot how to do that

Any Module::Install converts reading this should note the bin directory, not script.

In bin/fooapp itself you also provide an additional metadata hint (next to ABSTRACT):

# PODNAME: fooapp

Which results in nifty Metacpan links such as:

• https://metacpan.org/module/nfflowd

Finally this hint to the POD munger will allow a section to be pinned in place above the SYNOPSIS:

=begin :prelude

# POD here...

=end :prelude

I hope these tips are helpful to some…

Here are some of the techniques I use to minimize startup overhead. Due to the nature of our application (command-line tools), we would like quick responses everytime a script is called from the shell.

1) Avoid Moose. Mouse used to be a bit too heavy for my taste too, so we always use Moo, but nowadays I guess Mouse is okay, especially since Mouse provides much more feature. But in general I still avoid OO-style or use bare Perl5 OO for simpler apps.

2) Avoid heavy modules and use lighter variants. I usually run this script when trying out modules, and take its result into consideration. I used to choose CGI::Lite over CGI for this reason, though nowadays I very seldom have to resort to CGI directly (thanks to PSGI/Plack).

3) Delay loading of modules as much as possible. Some modules are only needed by a subroutine in a using-module, so instead of:

use Foo;
use Bar;

I usually write:

Jeffrey Thalhammer will be giving a talk at YAPC::NA 2012 described as:

The CPAN provides a wealth of open source software for Perl developers. But the CPAN model can be used for distributing proprietary software as well.

In this talk, we will explore some of the challenges and benefits of creating private CPANs.  In particular, we’ll show how to use the Pinto tool suite to create and manage a private CPAN, and how to incorporate a private CPAN into the typical development cycle.

Along the way, we will also survey some of the other tools that are available, such as CPAN::Mini, OrePAN, MyCPAN::App::DPAN, and Carton.

[From the YAPC::NA Blog.]

Last weekend, a local group around Nuremberg had their annual convention, called the KNF Kongress. I talked about some collected tricks around using perl. The key points were perlbrew, cpanm, minicpan and Dist::Zilla. All slides (in german language) collected from the speakers are online now:

KNF Kongress 2011

clang

LLVM's clang (at least 3.1) can be easily used via -Dcc=clang.

The benefit is that your generated code will be faster on DEBUGGING (optimized not so far), compile + link times are much faster and use much less memory, the diagnostics are better and because its AST does not simplify the code beyond repair (as with gcc) it is easy to add various code check passes and diagnostics such as ASan.

I found several warnings which I previously ignored in my code.

Imagine you are working on a smallish Catalyst project with an DBIx::Class model. You have been a good citizen and adhered to the principal of separation of concerns. Now you would like to extract the schema to use it anywhere else (in my case a monitoring interface that is in place and allows simple plugins). Creating a whole distribution with the related infrastructure out of the schema classes is just to much work for this one-off task. Dist::Zilla to the rescue.

Mike Schilli will be giving a talk at YAPC::NA 2012 described as:

Deploying releases to tens of thousands of hosts reliably while only disrupting a limited number of busy production servers at a time in different colocations is impossible to manage manually.

Pogo is a distributed deployment engine written in Perl that solves this problem. It’s an open source project on Github, written by Yahoo’s deployment tools engineering group. It enables one-button deployments in large infrastructures at Yahoo! every day.

The talk offers a glimpse at how large-scale deployments are done at Yahoo! and how Pogo manages these tasks. We’ll also cover the Pogo distributed architecture, how to configure and use it for your needs and how to get involved with the project.

[From the YAPC::NA Blog.]

Which distribution of Marpa should you use? Marpa::XS or Marpa::PP or the "bare name" Marpa? Use Marpa::XS if you can, Marpa::PP otherwise. The "bare name" Marpa is a legacy distribution, and should be avoided by new users and in new implementations.

Marpa::XS

Marpa::XS DOES require a C compiler, as well as glib and a few other GNU prerequisites. To run and install Marpa::XS and its documentation, you DO NOT need POSIX, glibc, gcc or TeX.

Marpa::PP

The Google Code-in 2011 is open and I'm one of the mentors for The Perl Foundation's projects. If you are or know a 13- to 17-year-old budding open source developer, check out the site and start knocking down tasks!

I've been checking the latest developments in the new C++ standard, C++11, and noticed that it now has support for thread local storage.

It adopts a "hybrid" approach; sharing by default but also using TLS slots for storing globals with thread scope
This reminded me that the last .NET version has an option like that
"New in .NET 4.5: ThreadLocal.Values"
as well as the "It's Not Always Nice To Share" article which concludes that it is better to share nothing by default but share explicitly

Now, I know that Perl's threading model takes TLS one step further down and that it has been heavily criticized as being "not true threading"
but all this makes me think that it is not that bad after all, but rather simplifies things and mirrors Perl's philosophy of "just getting things done"

So what's after that ? The next .NET version or C++ standard fully embracing Perl's threading model in a "back to the future" fashion ? (active since version 5.8)
Would love to see that !

Daisuke Maki will be giving a talk at YAPC::NA 2012 described as:

STF is a distributed object store that is used in Livedoor (NHN Japan) 

The idea is the same as mogilefs, but it was built with open protocols (HTTP, PSGI) and commodity tools like Apache/Nginx, MySQL, and Q4M.

It serves several hundred million files (mainly image files) and a few million b/sec for our blog, photo share, geo-location, and other services.

In this talk I will describe what STF is, and how we set it up how we operate it.

[From the YAPC::NA Blog.]

What do you think about the code below?
I have a file containing information about people, where the fifth element of the tab separated line contains the mail address.
Each mail address appears multiple times, I need to print them unique.

my %mails;
open my $csv, '<', 'my.csv' or die $!;
while (<$csv>){
    my  $mail = ( split(/\t/) )[4]; 
    $mails{$mail} = 1
}
say foreach sort keys %mails;

(and how do I indent code on blogs.perl.org?)
thx @Aristotle

I use Dist::Zilla for managing my distributions. It's awesome and useful, although it lacks some bits of documentation every now and then; this lack is compensated in other ways, e.g. IRC.

I also use the PodWeaver plugin to automatically generate boilerplate POD stuff in the modules. Some time ago I needed to add some programs to a distribution of mine (which I also managed to forget at the moment, but this is another story), and this is where I got hit by all the voodoo.

The first program was actually a Perl program, consisting of a minimal script to call the appropriate run() method in one of the modules of the distro:

$ cat bin/perl-program 
#!/usr/bin/env perl
use prova;
prova->run();

This led Dist::Zilla to complain like this:

(The Hebrew text will be followed by an English one).

I’m happy to announce that ActiveState has decided to sponsor YAPC::NA 2012.

ActiveState empowers innovation from code to cloud smarter, safer, and faster. ActiveState’s cutting-edge solutions give developers and enterprises the power and flexibility to develop in Java, Ruby, Python, Perl, Node.js, PHP, Tcl, and more. Stackato is ActiveState’s groundbreaking cloud platform for creating a private platform as a service (PaaS), and is the cost-effective, secure, and portable way to develop and deploy apps to the cloud. ActiveState is proven for the enterprise: More than two million developers and 97% of Fortune-1000 companies use ActiveState’s end-to-end solutions to develop, distribute, and manage their software applications. Global customers like Cisco, CA, HP, Bank of America, Siemens, and Lockheed Martin look to ActiveState to save time, save money, minimize risk, ensure compliance, and reduce time to market.

For more information, visit www.activestate.com.

[From the YAPC::NA Blog.]

For some reason that I have not bothered to investigate yet (but probably due to my screwed up perlbrew installation), AutoLoader fails to work with 'prove' and 'dzil test'. I just need to separate a couple of heavy routines off the main module, to shave startup time. So here's what I did:

1) Manually split the heavy routines to My/Module/al_method1.pm and My/Module/al_method2.pm.

2) In My/Module.pm, add:

use vars qw($AUTOLOAD);
sub AUTOLOAD {
my ($pkg, $sub) = $AUTOLOAD =~ /(.+)::(.+)/;
die "Undefined subroutine" unless $sub =~ /^(method1|method2)$/;
$pkg =~ s!::!/!g;
require "$pkg/al_$sub.pm";
goto &$AUTOLOAD;
}

So far it works (some tweak might be needed under -T). And I don't have to deal with AutoSplit. I just hope there's no gaping hole somewhere.

While I'm writing my beginning Perl book, I've developed several tools to make my life easier. However, I've encountered a problem. I've often found that I am using iTerm2 in full-screen and this obscures my battery indicator. If I'm not plugged in, my battery can get dangerously low. I've fixed that.

use Benchmark is not good enough. At all. - you can specify -2 as count which means 2 seconds. Good. - if you specify the test code as string not coderef means that you bench also the parsing time for all counts, and not plain run-time. coderefs should be used. The result is entirely unrealistic as you compile once and run often. - the iteration results are not used at all to check the statistical test quality. - without using :hireswallclock you get time(2) precision which is integer seconds.

benchmark-perlformance is too good and too slow. It"s good to have a single special and reliable machine for this, but I see no useful results. And I miss simple tests with good op coverage. I even do not see op coverage at all.

How fast is my perl, how good is my test and how good is my test result?

Dumpbench reports at least some statistical quality, but needs too many args. initial_runs and target_precision should not be mandatory.