Linode has blown my mind again by increasing their sponsorship of YAPC::NA 2012 to the Platinum level. I can’t say enough good about them, not only as a sponsor of YAPC, but also as a great hosting company. Thank you Linode!

Recently named by Inc. magazine as one of the top 500 fastest growing private companies in America, Linode delivers virtualized cloud services from six regions across the U.S., Europe, and Asia to some of the most innovative companies in the world, such as The Onion and Creative Commons. The company’s proven IaaS (Infrastructure as a Service) offering enables customers to deploy and manage Linux virtual servers in the Linode Cloud with the ability to scale deployments to meet business demands - paying only for what they use with no long-term commitments. For more information, visit http://www.linode.com/.

[From the YAPC::NA Blog.]

The YAPC Conference Surveys site has now been updated with the results of the Pittsburgh Perl Workshop and the German Perl Workshop.

The site has also been update to provide a tabbed display of the different types of event, to make it a little easier to find results. Over the next month or so I am looking to get more of the past data online, as well as the feedback that I normally send to just the organisers. I have lots of data waiting in the wings, and its only been my lack of free time that has prevented me from finishing off the sanity checks.

This is a reminder for the upcoming meeting.

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

So I thought I’d kick off my inaugural Perl blog post by answering the question I’m sure you’re asking right about now: who am I, and why should you care?

Of course, the short answer is: “you shouldn’t.” I have another blog whose title sums up how I feel about blogs.  The short version is, they’re crystallizations of other people’s opinions, and, as we used to say in grade school, opinions are like assholes: everybody’s got one, they’re all different, and they all stink.

But notice how that didn’t keep me from starting a blog myself.  Also note that there are 83 posts on said blog.  So obviously I’m a big ol’ hypocrite.

I’m grateful that Liquid Web Inc. has become a sponsor of YAPC::NA 2012. They’re a great hosting company with reasonable prices. They do a full range of both dedicated servers and VPS.

Liquid Web Inc. is a managed hosting company operating out of two regions in the Central and Western US. Having been named to INC 5000’s fastest growing companies five years running, we’re in the midst of a rapid ascent to a position of prominence and recognition amongst the Hosting field.

At least in my Mac OS X (Leopard) the perllocale and the perl collations that DBD::SQLite make available do not work to properly sort UTF. Or that, or I am doing something wrong.

Nevertheless, I found a simple way to do that, thanks to the Unicode::Collate module. Just add a few lines of code after you open your database connection:

my $collator = Unicode::Collate->new();
$DBD::SQLite::COLLATION{mine} = sub { $collator->cmp(@_) };

and then use the mine collation:

$sth = $dbh->prepare("SELECT * FROM somewhere ORDER BY key COLLATE mine");

Now I just need a way to make Perl not complain about the usage of DBD::SQLite::COLLATION just once. I can set no warnings around it, but I would prefer a cleaner solution. Maybe suggest a define_collation method for DBD::SQLite.

I recently came across a link to an old article by MJD. The sections "On Forking", "New Versions", "NP Complete Problems", and "Why I Hate strict" are particularly worth reading. His basic point in each section is that you should think about the problem you're trying to solve when you write code, and stay mindful of why you are doing certain things. I wish there were more smart, thoughtful people like MJD in the Perl community nowadays, and fewer dogmatists.

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.

Andy Lester will give a talk at YAPC::NA 2012 described as:

We all love open source software, but to many it seems you have to be a rock star programmer to contribute to your favorite projects. In reality, most projects are easy to join, if you know where to look.

In this presentation, I’ll deal with the common questions and problems of those looking to help out on projects:

• “I wouldn’t know where to start!”
• “What’s a good project to start on?”
• “How good a programmer do I have to be?” 
• “I’m just a nobody, they won’t be able to use me.”
• “They probably have enough people already.”

You’ll learn about different ways people of all experience levels can pitch in. From coding and documentation to devops and project management to publicity and community, there’s a place for everyone in the open source ecosystem.

If you’ve never had the joy of improving the software you use every day, seeing your work published for the world to see and use, this is the session for you.

[From the YAPC::NA Blog.]

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:

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

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.]

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.

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

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.]

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.

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 !