Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ddick (5726)

ddick
  (email not shown publicly)

I'm based out of Melbourne, Australia. I attend the excellent melbourne.pm.org meetings whenever i get the chance, which is not often enough.

Journal of ddick (5726)

Friday June 29, 2007
01:26 AM

So which language is the weirdest of them all?

Amusing result for people who like bashing my favourite language... when i google for "Weird perl problem", i get back 1,880,000 results... could be bad... except that ruby (2,000,000), python (2,030,000) and php (3,490,000) seem to be doing worse. perl may have weird bits in it, but it seems to have less than the competition... :)
Sunday June 17, 2007
07:39 AM

fun with taint and Getopt::Long

save following code as test.pl

#! /usr/bin/perl -wT

use Getopt::Long();
use strict;

$ENV{'PATH'} = '/bin:/usr/bin:/sbin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};

MAIN: {
        my ($file);
        Getopt::Long::GetOptions('file:s', \$file);
        system("echo $file");
}

run the following commands

$ test.pl --file blah
Insecure dependency in system while running with -T switch at test.pl line 12.
$ test.pl --file=blah
blah
$ perl -e 'print "Wtf???\n";'

Monday June 04, 2007
09:16 PM

When to automate business functions

Managers should (and mostly do) love automating stuff via computer programs. Less human intervention means less potential screw ups. This means more accurate reporting, which makes the managers life much easier. They can then drive a business with confidence. Unfortunately, whether to automate needs some consideration.

This entry serves as a temporary spot for some thoughts on how to decide that automation is the thing to do.

Firstly, if the ideal program was available tomorrow (off the shelf purchase), how much work would it save and how much work would it create upfront and on-going?

  • Does the manager have a really accurate view of what the staff do (New automation could slow them down)
  • Training requirements (support && operations)

This should produce the first rough number to help with purchase/development costs.

Off the shelf tech?

  • Hostage to vendors whims, release cycles and priorities (have to make do with what you have, and what you are going to discover)

In-House Development?

  • Time taken to produce a non-trivial program
  • Eliminating the edge cases

Secondly, automation can be a straight jacket. Once you are committed to a piece of tech, it's hard to move away. If the tech contains your business processes, changing anything will have another cost associated with it.

If business/legal requirements are liable to change (australian superannunation for example) every piece of automation will require work when a change comes through. If a vendor goes bust or retires the piece of tech, there is big trouble. Introducing new systems or retiring old ones also means data migration and systems integration, neither of which are famous for being cheap.

So the cost of migrating to and from the new technology need to be evaluated. A common line of thought is that buying from microsoft/ibm/sun means that the vendor will not go under, so this "futureproofs" the technology. Three words. Visual Basic 6.

Finally, the technology needs to have some sort of end of life timeframe associated with it. This may well be forever, but it's a good thing to keep in mind. Historically, how often has the company radically changed course? Introduction of computers, entirely new legal/business frameworks due to overseas expansion, business is bought/sold, etc. Most businesses have these sort of events happen a few times.

So, now, hopefully, you know what it would cost to procure the tech, install it, mantain it, remove it, how long you're planning on getting a benefit and how much that benefit is.

Monday May 21, 2007
06:32 AM

complied perl in sarge - etch upgrade

recently had a bit of a unexpected issue with perl daemons refusing to come back up after a debian sarge -> etch upgrade. It seems that any compiled modules are stuffed after the upgrade as the perl in etch has a completely different $Config{archname} than sarge. This resulted in a few interesting surprises. I'm sure i remember something somewhere talking about the reasons, but i can't remember where. I can't see it in the debian release notes, but i could just be blind. at any rate, i would hope no-one else needs to suffer through this issue.