Shell access to $NOT_MY_ENVIRONMENT for development?

I'm a self employed hacker. My development (actually, my total) infrastructure consists of a six-year old laptop running Linux with a full disk and a noisy fan, and a rented virtual server, also Linux. I have a few modules up on CPAN, which occasionally receive reports from cpantesters or the odd individual user with a build/test failure on a platform I don't have access to. Blinding attempting fixes and waiting for reports is tedious and inefficient.

There are a few no-cost BSD shell providers around, which has allowed me to develop and test directly on that platform. However I haven…

Bash function for directory-dependent local::lib

On my laptop I use perlbrew to keep my system perl separate from my development perl. But I also develop various Perl projects with different dependencies, and would like to keep those dependencies separate if possible. Using a separate perlbrew perl for each project as well would be overkill in terms of diskspace, CPU energy and time so I thought local::lib might be useful.

If I install dependencies for a particular project using "cpanm -l extlib $MODULE" in the top level directory, the function below will automatically setup local::lib for that location when I change into that direc…

githook-perltidy update

Last year I wrote script to automatically tidy up your Perl code as it is commited by Git. I just ironed out a final issue that had been bugging me: partially indexed files. That change plus a few documentation cleanups are now available as version 0.04 from my Github repository or as a .zip file.

I also uploaded a distribution (App-git…

Running perltidy in a Git commit hook (githook-perltidy)

I have found a couple of attempts at integrating perltidy into Git commit hooks, but nothing yet that I considered robust enough. The scripts ignore the state of the index, modify the working tree, and then forget to update the index before the commit. They didn't…

Introducing App::Dispatcher

I have an issue somewhat related to Steven Haryanto's concern about bloated apps. I can live with a command taking a second longer to run when performing work, but I absolutely detest waiting that long for the usage message to be generated. I am constantly running commands without arguments (eg Git) to get an overview of sub-commands and/or their options. A slow Perl command line app (eg dzil) is a pain in comparison. It is sometimes quicker to load the manpage.

But it doesn't necessarily have to be that way. App::Dispatcher is a tool for constructing command line applications written in Perl. It is specifically designed to handle applications with multiple sub-commands and will generate code to display usage text, validate options and arguments, and dispatch commands. Its main strength is that the usage and validation does not load any command classes with their possibly heavy startup dependencies.