mod_perlite is a very interesting project which aims to create a lightweight Perl module for Apache which can compete in the market range where PHP dominates.
The project already has something which actually works, but which needs to be polished. If you can and want to help, take a look at the web site!
Italian: per gli italiani, qui c'è un articolo in merito.
After looking at the open source alternatives, I decided the price was worth to buy the MCIMageManager plugin for TinyMCE. This open source (LGPL) Rich Text Editor is probably the best out there: the great image upload plugin, developed by the same folks, is however not free - but definitely worth its money.
The backend of MCImageManger is in PHP or .NET: I decided to stick with the PHP version, as my web server is on Unix, but still had to find out how to integrate it with my web application (which is in Perl) making sure only logged in users would be allowed to upload files. There are code examples for JSP, ASP Classic and several PHP configurations, but nothing related to Perl. So, I ported the authentication script - it was easy enough and here's the result.
If you use Perl and you want to integrate authentication with the one of your system, you need to use ExternalAuthenticator in order to share sessions between Perl and PHP/.NET. It's not that difficult: since the Perl ExternalAuthenticator script is not provided, you can find one I wrote myself here.
MCImageManager configuration
File to edit is likely ''config.php''. If you use ''Web.config'', these instructions still apply.
First of all, you need to enable the ''ExternalAuthenticator'':
$mcImageManagerConfig['authenticator'] = "ExternalAuthenticator";Scroll down a bit and you'll find the relevant configuration options for ''ExternalAuthenticator'':
// ExternalAuthenticator config
$mcImageManagerConfig['ExternalAuthenticator.external_auth_url'] = "/manage/tinymce_auth.pl";
$mcImageManagerConfig['ExternalAuthenticator.secret_key'] = "TheKey";tinymce_auth.pl
Put this file at the location you specified in ''config.php''. You need to edit some parth: the secret key and, of course, the part which verifies the user is authenticated.
#!/usr/bin/perl
use strict;
use warnings;
use CGI::Carp qw/fatalsToBrowser/;
use CGI::Simple;
use CGI::Session;
use HTML::Entities;
use Digest::MD5 qw/md5_hex/;
# Must match the one in config.php
my $secretKey = "TheKey";
my $q = CGI::Simple->new();
print $q->header(
-type => 'text/html; charset=UTF-8',
);
my $session = CGI::Session->new();
# See if session-id is OK
if ( !$session->param('idadmin') =~ /^\d+$/ ) {
print "Not logged in";
exit;
}
# Come configuration variables can be overridden here
my %configuration = (
#'filesystem.rootpath' => '/some/path',
#'filesystem.path' => '/some/path',
);
my $data = '';
for my $cv (values %configuration) {
$data .= $cv;
}
my $key = md5_hex($data . $secretKey);
print '<html>';
print '<body onload="document.forms[0].submit();">';
print '<form method="post" action="' . encode_entities($q->param('return_url')) . '">';
print '<input type="hidden" name="key" value="'. encode_entities($key) . '" />';
for my $ck (keys %configuration) {
my $enc_ck = $ck; $enc_ck =~ s/\./_/g;
print '<input type="hidden" name="'
. encode_entities($enc_ck)
. '" value="'
. encode_entities($configuration{$ck})
. '" />'
;
}
print '</form></body></html>';
This work is free software, by , and is provided as-is. If you need support, ask in the TinyMCE forums.
[This is a translation of my article in Italian language on Perl.it]
Sometimes things happen when few are still left to believe in them, nevertheless they are able to bring new enthusiasm and life to projects which seemed to be sentenced to a never ending gestational status. OK, I'm now going to come out of this "Barack Obama mode", but I hope I gave an idea of how much March 17, 2009, the date of the release of Parrot 1.0.0 is important for the Perl community (and not just for it).
Anyone who's got something to with Perl likely knows what Parrot is, but this moment deserves a brief refreshing about its main features. First of all, it's a virtual machine which aims at becoming the virtual machine. Even though its development started out from the Perl community, the goal is that other dynamic languages should be able - or even want - to use it as well, as Parrot will grant superior performance.
For other technical information, please read the Parrot Wikipedia page, as I'd like to write something about the second reason for which Parrot is important. It's maturation is fundamental to give a boost to Perl 6 development, in order to reach the much awaited first major release of our favourite language, an event we've been waiting for years: yt's current implementation, Rakudo, is being developed upon Parrot.
Many more steps still have to be performed, and maybe many folks will continue to state, as a joke or seriously, that Perl 6 will never see the light. However, as Parrot did, Perl 6 could surprise you as well.
Using the Dojo loader to include your own JavaScript module is very handy, and also works around several problems related to loading JavaScript code directly via the <script> tag. Often, however, you want to be able to load your modules across domains, so you need to write them in xd fashion. In itself, it's not a big issue as, with Dojo 1.2.0, a non-xd code such as this:
(function(){
dojo.provide("cryo.Tree");
dojo.provide("cryo.ForestStoreModel");
dojo.require("dijit.Tree");
dojo.declare("cryo.ForestStoreModel", dijit.tree.ForestStoreModel, {
// class definition
});
dojo.declare("cryo.Tree", dijit.Tree, {
// class definition
});
})();
just needs to become as follows to work with the Dojo cross-domain loader:
dojo._xdResourceLoaded(function(){ return {
depends: [
["provide", "cryo.Tree"],
["provide", "cryo.ForestStoreModel"],
["require", "dijit.Tree"]
],
defineResource: function(dojo) {
dojo.provide("cryo.Tree");
dojo.provide("cryo.ForestStoreModel");
dojo.require("dijit.Tree");
dojo.declare("cryo.ForestStoreModel", dijit.tree.ForestStoreModel, {
// class definition
});
dojo.declare("cryo.Tree", dijit.Tree, {
// class definition
});
})();
Easy enough, but what usually happens is that you work with non-xd files while developing, while using the cross-domain features in production. Or maybe the opposite. Or something similar. Anyhow, in this case you most likely don't want to maintain two copies of the same JavaScript module where only header and footer are different. For sure I don't, so I wrote a small Perl script which converts non-xd modules to xd-enabled ones automatically by performing the following tasks:
dojo.require and dojo.provide statements in order to create the xd header.OK, I know, there's also the Dojo Build System, but I didn't want to install Ant and a ton of Java-related dependencies for a task which requires 20 lines of code.
This script is a quick hack so it has caveats:
On the other hand, using it makes no harm to your existing code: it will either work and produce (possibly broken) output files, or produce no files at all. So, I would say it is safe to try it.
Usage:
make_xd.pl file1.js file2.js ... filen.js
You can pass one or more files on the command line: the script will produce filename.xd.js starting from filename.js, which is left untouched.
Click here to download the script.
If you improve this script, please let me know.
It looks like we'll have at least 4 international speakers at this year's Italian Perl Workshop:
Of course, besides these names, there are also many great Italian speakers. You can take a look at the workshop schedule.
So, don't miss Italian Perl Workshop 2008!!!
Rating: 4/5 (very good)
There's been a lof of fuss about Agile Development lately. Many folks see it like the cool new thing, the way you must code from now on, but most don't actually know what all of this is about. Fact is agile development isn't simply a new way to code software, but comprises a series of different ways to do the normal activities. These new methods, grouped together, make up a new way of work.
Were my words clear? No? Great, I thought so. This is the moment for The Art of Agile Development to come in. It's a deep and quite complex work from authors James Shore and Shane Warden: the first is one of the original signers of the Agile Manifesto, which practically invented Agile Development. The books is complex because it needs to be such: you can't "migrate to Agile" in one day, your team has to practice - as the cover image shows, you need to grow.
First of all, the books tries to make you understand why you need (or simply want) Agile Development: since the path is not straight, but more like a forest, you must - as a team leader - convinced of what you are doing. In some cases, it might also make you understand that you don't need Agile Development, which is a good thing anyhow - and the book remains useful in any case, as it's full of suggestions and practices which can be applied to any working team.
The Art of Agile Development unveils its concepts by teaching the most famous example of Agile Development: Extreme Programming. This particular case of is actually so well-known that most people tend to identify Agile Development with it. The book assumes your positions allows you to make decisions for a team - that's because Agile Development requires a lot of changes in the way your team works. It also assumes you are willing to risk some of your and your team's time and resources in practicing Agile Development: improvement needs some sacrifice.
The books offers and in-depth exploration of each of the covered topics, which you can read by browsing through its table of contents. You are step-by-step taught about what you need to, what results you can expect, and when you can expect them. I believe the last two aspects are very important, as they help you evaluate if you're doing things properly, and they allow you to make changes down the road without losing days and weeks in incorrect work behaviours.
Although there's a main "line", alternatives are always explored by the authors. for instance chapter 6, which is about Planning, in a certain place supports the adoption of adaptive release planning; it, however, explains the differences with other possible choices such as predictive release planning, and tries to make you understand where one approach can work better than the other. You find a lot of other goodies in any chapter: answers to FAQs, pointers to external resources, and especially great Contraindications paragraphs. These will prove to be quite useful, as you'll be able to know beforehand how the adoption of what is explained in a chapter might create problems to your working environment, and therefore be able to avoid troubles.
All in all, The Art of Agile Development is a great book, but it's demanding. It requires you to study it beforehand, then make important decisions, and then try to convince your team about those decision - some of them, at first glance, might seem a bit awkward to team members. You'll then need to apply what you learned in an effective manner. It's not an easy reading, but one things I like most about this book are the "internal links", which simplify the learning process: there are gray text boxes named Allies spread everywhere, which point you to other sections of the book which are related to what you are reading.
If you're a team manager and want to try to move towards Agile Development, this is definitely the book for you. If you don't feel you want this, but still want to improve the productivity of your team, this book is for you as well, as it offers tons of tips on how to organize work in a modern and efficient way.
