Robin Smidsrød

First make sure you activate the multiverse repository for apt.

Then install the required modules (if you don't already have them enabled)

sudo aptitude install libapache2-mod-fastcgi apache2-suexec

Enable the fastcgi and rewrite modules:

sudo a2enmod fastcgi
sudo a2enmod rewrite

Edit /etc/apache2/mods-enabled/fastcgi.conf and enable the FastCgiWrapper so that the .fcgi script is run as the owner of the script. This is why apache2-suexec above is needed.

Then add the following to the file if you like to be able to just touch the psgi.fcgi file to get it to reload your app.

FastCgiConfig -autoUpdate

My /etc/apache2/mods-enabled/fastcgi.conf is like this:

<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi
  FastCgiWrapper /usr/lib/apache2/suexec
  FastCgiIpcDir /var/lib/apache2/fastcgi
  FastCgiConfig -autoUpdate
</IfModule>

Then you need a small wrapper script to actually run your PSGI app. I call it psgi.fcgi:

#!/usr/bin/perl
use strict;
use warnings;
# For CPAN modules in your home-dir (see local::lib)
use lib "/home/robin/perl5/lib/perl5";
use lib "/home/robin/perl5/lib/perl5/i486-linux-gnu-thread-multi";
use Plack::Server::FCGI;
Plack::Server::FCGI->new->run(do "app.psgi");

The use lib statements are there because I use local::lib. I just grabbed them from the PERL5LIB environment variable. If someone has a better solution on how to write this wrapper with support for local::lib, I'd like to hear it.

The next thing is to add a nice .htaccess file so that you can make flexible apps that use PATH_INFO and other nice things (this is where mod_rewrite comes in).

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ psgi.fcgi/$1 [QSA,L]

Change this one if you'd like Apache to handle static files by itself instead of forwarding the requests to your application.

Finally I just made a small app.psgi that prints the environment as you try out different paths below your base folder. Pay close attention to how PATH_INFO changes as you try it out.

#!/usr/bin/perl

use strict;
use warnings;

sub {
    my ($env) = @_;
    my @out = ( "Your \$env hash:\n\n" );
    foreach my $key ( sort keys %{ $env } ) {
        push @out, $key, ' = ', $env->{$key}, "\n";
    }
    return [
        200,
        [ 'Content-Type' => 'text/plain' ],
        \@out,
    ];
};

I'm using Plack 0.9006 from CPAN for this little experiment.

I think this will be my quick-and-easy way to deploy PSGI apps from now on.

Update: It seems the suexec wrapper doesn't do its job properly. The FastCGI script, psgi.fcgi, is apparently still running as www-data(33). If you know how to fix this problem please shout out in the comments.

I just wanted to inform you about a talk I'll be making on my local college about the differences in philosophy of the Free Software movement and the Open Source movement.

Feedback about content, accuracy etc. most wanted.

The talk is mostly about summarizing the content of Dave Yeats writings in the book The Handbook of Research on Open Source Software: Technological, Economic, and Social Perspectives (Chapter 3).

Thanks to the Dave Rolsky, Ricardo Signes, Florian Ragwitz and others in #moose@irc.perl.org for valuable input on the subject matter.

This is a somewhat simple query that identifies CPAN authors that use modules from the Test namespace in their runtime phase, according to the data from CPANDB.


SELECT d.author, count(r.module) AS test_namespace_used_in_runtime_phase
FROM requires r JOIN distribution d ON r.distribution = d.distribution
WHERE r.module LIKE 'Test::%'
AND r.phase = 'runtime'
GROUP BY d.author
ORDER BY test_namespace_used_in_runtime_phase DESC
LIMIT 20


d.author	test_namespace_used_in_runtime_phase
NUFFIN	122
BDFOY	84
LUSHE	78
ANDYA	75
LBROCARD	67
RJBS	66
MARKOV	62
MIYAGAWA	54
ISHIGAKI	53
PETDANCE	46
SIMONW	45
TOKUHIROM	40
MCMAHON	39
NKH	36
APOCAL	35
DAVEBAIRD	34
LEOCHARRE	34
KARMAN	31
SHLOMIF	31
BARBIE	29

Some modules might actually require modules from the Test namespace in their runtime phase, but this many?

I would think that this is an indicator that some authors mark their test requirements in the wrong way (or CPANDB is wrong). Maybe some Makefile.PL cleanup should done?

After reading NPEREZ's blog article DarkPAN SchmarkPAN -- STOP THE MEME, it suddenly comes to me:

We need a tool that enable users to profile their codebase to verify if they are using any removed, deprecated or changed features of a new version of the perl interpreter.

This would make the task of identifying troublesome constructs in code much easier for your average perl programmer. I, for one, do not know when a particular feature of perl was introduced, or when another particaluar construct was deprecated (or removed). And if I read the perl changelog I'm not always aware of how to test if any particular code construct is in use in my code or not.

Wouldn't it be possible to make a tool (could possibly be named perldelta or perllint) that scans a piece of code (but doesn't run it) and gives out information about removed and deprecated constructs. To me this seems like a mix between warnings and Perl::Critic, but focused on identifying removed or deprecated constructs in just the perl interpreter instead of advocating general code style (as Perl::Critic does).

The tool could by default run against the release it is packaged with, but optionally also against older releases (with a --version option) so that you could test which version of perl really would cause problems for your app.

I'm not sure if all of the features that are deprecated/removed can (easily) be tested with this approach, but I'm fairly certain that it would go a long way towards enabling deprecation cycles in core perl development.

Another useful function this tool could have was to determine the minimum (or possibly maximum) useful version of the perl interpreter that your code can use.

Example:

• Let's say that your code uses pseudo-hashes (I don't even know how to identify those). They were removed somewhere in the 5.9.x-series.
• This means that your code is incompatible with 5.9 or newer.
• Let's also assume that you use some useful UTF-8 construct that makes you require 5.8.x.
• That means that as long as you have that pseudo-hash code in there your limited to running your code on perl 5.8.x.
• Let us then assume that a new (junior) programmer enters the stage and has heard about this fancy given/when thingy in perl 5.10 and starts using that in the same codebase.
• Suddenly you have a codebase that is in fact completely incompatible with any single perl version, but each of the parts are perfectly compatible with some perl version.

With a tool like what I have described it would be easy to determine a specific version requirement for your codebase (or CPAN module), and it would be even easier to pinpoint things that bites you now, or could possibly come and bite you in the near future.

This tool would also benefit distribution packagers in determining incompatibilities when they plan on upgrading to a new version of perl (which we should hope they would do frequently).

What I like about Ubuntu, as Gabor Szabo wrote about, compared to e.g. Debian, is that it has regular releases every 6 months. It makes me certain that if a certain feature comes along in some popular package, it is never more than 6 months away. Imagine if we could have this kind of predictability with perl. It would be almost like Christmas, only twice a year.

I'm not saying that this tool necessarily needs to be bundled with perl, but it should be trivial to get it to run on your machine so that you could profile your code and give you the necessary advice. Chromatic says that the pumpkings need more help, and I believe this is a way to help them.

If the tool could also be made to output some kind of structured output (somewhat similar in concept to Debian popularity-contest) we could harness statistics from both CPAN and the DarkPAN (I really dislike that name) to figure out what features of the language are actually in use without divulging any actual copyrighted/restricted code. Imagine, for a second, that you run this tool against your code and then you upload a set of structured data that identifies what kind of code constructs you use in that code (this could happen automatically if you have it set to do that). If any of those constructs become deprecated or removed in the future you would get an email that says so (based on your opt-in/out settings).

If you want to go all out you could even store checksums (SHA1) of the files it is run against and store that value in the structured data, that way you could look up reports against a specific file without actually running it. Imagine running something like this recursively on a big project and have it generate a report of your entire codebase (including CPAN deps) and then with very little effort be able to see the obvious blockers towards upgrading to the next version of perl.

I also see that this could be used to better determine Kwalitee of a CPAN module.

If we actually implement those last parts about uploading structured data to a central repository it is absolutely vital that it contains no trace of either code or the identity of the owner of that piece of code. Because, if it does, no company would (probably) be willing to submit data into the repository. Identification of a particular report/datadump to a company, individual or named code should be completely optional. Anonymization is a vital key here.

I'm not exactly sure how we would be able to handle foreign code (C, C++, Java, etc.), or how XS ties into the picture, but I have a feeling it should be doable.

Please let me (and others) hear what you have to say about this subject in the comments.

This is a response to John Napiorkowski's article: Why All the Hate?

Matt S. Trout was talking about the fact that we need to become better with marketing. I second that.

One of the tools of marketeers is the survey.

My suggestion is this: Why don't we publish a survey about perl and get it answered by as many people as possible, even the nay-sayers, reddits and diggers? At least this way the perl community as a whole could better grasp what parts we really need to focus on, based on user feedback? And we'd even include people outside the core community.

I believe that some of the questions should be like this (some alternatives in parenthesis):

• How much do you like perl?
• What are perl's biggest strengths? (we need to make a list here)
• How much do you dislike perl?
• What are perl's biggest weaknesses? (same here)
• How long have you been using perl?
• How are you using perl? (scripter, sysadmin, non-user, cpan dev)
• Are you a member of the perl community? (current, former, never, left)
• What is your age?
• Are you excited about perl6? (yes/no/neutral)
• Do you think the CPAN install process requires improvement? (yes/no/neutral)
• Do you follow perl-related websites? (yes/no/neutral)

It would be wonderful if either EPO, P5P or the Perl Foundation would find the means to issue a survey like this. If it comes from either of these organisations it would probably be taken seriously. This way we could really find out what matters to people, instead of just "guessing" what it is.

I know that something like this was done in the past, and it was what ignited the whole perl6 process. Isn't it about time we do something again?

If you have more suggestions for questions/options to the survey, please state so in the comments. Other comments are also most welcome.