use Perl

My big news today is that Version 3.0 of bcvi is now available on CPAN. If you have no idea what bcvi is then you'll be pleased to know I've written this article to answer all your questions - it even has pictures!

I've never been a big fan of heredocs - mainly because they break indentation. When I put SQL in code, I tend to use the single quote operator with curly braces for delimiters:

$sql = q{
    SELECT
            *
    FROM foo
    WHERE
          id = $1
};

I've been a heavy user of Linux vservers (see also: OpenVZ and the other one whose name I forget; and BSD 'jails') for a number of years. They are similar in concept to your chroot solution except much more convenient to use. They are lightweight because the virtual servers don't run their own kernels - they share the host kernel but with key structures like the process table partitioned into separate namespaces.

I've found this type of virtualisation to be invaluable in the 'staging' or 'User Acceptance Test' environment. If an application will be split across multiple servers in production (eg: DB server, app server, frontend web server), then you really want your staging environment to be configured the same way. Doing it with virtual servers is a cheap and effective solution.

Another advantage of using CPAN packagaing standards for code that's not going to CPAN is that it's really easy to create packages for deploying the code on Debian/Ubuntu (and presumably RPM-based distros' too - I don't know). The dh-make-perl utility takes a CPAN tarball and creates a .deb package.

Is the space actually 'magic' or it simply that you have no filenames that end with a space?

Personally, I'd just pipe those things through Encoding::FixLatin and enjoy the utf8ness it emits :-)

If your project was in Git then you could use Gource to visualise the commit history.

Gource is written by Andrew Caudwell - a colleague and sometime Wellington Perl Monger. He loves playing with graphics and interesting visualisations. If you're running Ubuntu/Debian you can even grab a .deb from the project 'Downloads' page, install it, cd into your git project and run gource - then sick back and what history.

It looks like SourceForge have fixed this problem and now projects can have multiple git repos. Unfortunately at this moment all git URLs on their site are broken as what was git://project.git.sourceforge.net/gitroot/project should now be: git://project.git.sourceforge.net/gitroot/project/project

These are the experiences that life is made of.

By the way I don't think you need worry about the dangers of having a credit card. It would only get you into trouble if you used it to spend money you don't have and it doesn't sound like you're the sort of person who would do that. As long as you make sure to pay off the full balance every month then a credit card will be nothing more or less than a useful tool.

Of course this would have been a much shorter story if you'd had a credit card :-)

Yes, Git support was added to Sourceforge recently, but the support is very minimal - one repository per project. I like to use one repo for the project itself and another for the web site. Some projects (e.g.: Perl-XML) use the CVS modules facility to have one repository per distribution. Subversion kind of supports this through its "tag-isa-branch-isa-module-isa-directory" model. In Git you could have completely independent branches for different purposes but that just seems wrong.

For that type of problem, I find that using XML::LibXML and XPath leads to code with even less syntax.

I'm interested in your reasoning for running "Perl without threads". I've done a lot of work with developing and deploying Perl and mod_perl apps on Debian and have yet to find a reason to build my own perl executable. Does building a Perl without threading support have some advantage over the core build?

Another example that people may be able to relate to, is scanning an Apache log file and using the hash to count which pages were visited.

It might help to answer your question if we knew what you want to do with the tree.

One of the disadvantages of a complex tree structure is the tedium of navigating it to access the data you want. In the XML world, the XPath query language is great for pulling data out of the DOM tree. So having a parser that uses a generic tree module without XPath support doesn't sound particularly appealing.

The most popular XML module is probably XML::LibXML. Its tree nodes and XPath query engine are implemented in the libxml2 C library. This has a huge performance advantage over modules that implement their tree with Perl data structures since Perl has more overheads.

Wellington Perl Mongers had a fun evening last week - our annual Lightning Talk meeting. As usual the talk schedule was looking pretty thin in the days leading up to the event but with a bit of encouragement people did step up and the evening went well. The talks covered a range of Perl modules; a bit on Erlang and CouchDB (thanks Lenz); mountain biking and mapping (Donovan); and Perl on the iPhone (Tob