|
Disclaimer: I am a hardcore perl programmer who wears the disguise of a Sr. Systems Engineer (I've also come around and agree with the earlier thread - I am a far better system programmer when I'm not also trying to be a system administrator). There are two key factors: Programmer Experience and Complexity of the Problem. An experienced programmer can compartmentalize (i.e. write modules) to manage the complexity of a given problem, and present a nice API down to those with less experience to work with. I try to keep those learning how to program away from complicated problems, as they tend to eventually succeed at writing the program, but it tends to be a tangled unmaintainable mess that is easier to rewrite than it is to patch. (This line isn't always obvious until it's been long crossed however) I also can't say enough about documentation. I'm a huge fan of compartmentalizing complex problems into modules and making sure those modules have clear documentation included with them (pod) that detail out how to utilize them. What you get at the end of this process are a whole bunch of well isolated code pieces that individually are not that difficult for even a novice programmer to maintain. With all of this said, I'd like to leave off with a quick (and incomplete) list of modules every perl programming system administrator should know so they can stop reinventing these wheels. Getopt::Long - Parse command line options (Stop reinventing this wheel) Config::General - Read in a configuration file (Maintenance should require editing a config file, not the code) Template::Toolkit - Build Templates for your output (Modifying output should require modifying a template, not the code) Sys::Syslog - Log to syslog (errors to STDERR are of marginal utility) DBI - Store persistent data to a database (MySQL is a good thing) Data::Serializer - If you need simple persistent data storage to a file (Shameless self plug for my module - but it is quite handy) On Apr 9, 2008, at 7:22 PM, Eric Wannemacher wrote:
|