Perl career progression (Was: Perl work at Monash)

[Scott Penrose]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Tuesday, Sep 9, 2003, at 10:42 Australia/Melbourne, Nathan Bailey 
wrote:

> Okay, so the common theme appears to be "too narrow" which is good 
> feedback,
> except not specific enough to move forward/improve :-)
>
> I do think SQL stands on its own, in the sense that you are unlikely to
> write perl *applications* without some kind of database interaction,
> regardless of the webness of it.  And the intention of the progression
> is more towards perl *programming* than perl *scripting*, the later
> which could equally well be done in a combination of sed, awk and grep,
> for example (and would usually not involve writing a new perl module).

It is funny you say that, because I am finding myself moving further 
away from SQL.
I am really only using SQL now if I have a relational database - not if 
I have non relational data.

I am finding more and more I am leaning towards hierarchical and object 
databases - although non formal, mostly involved with storing XML in a 
directory structure etc.

> I suspect that paragraph will result in a lot of contention, but
> presuming agreement for the sake of clarity in the current
> discussion...  Would adding another column or two about other relevant
> technologies frequently used in perl be sufficient?  Two good examples
> from David were messaging (IMAP, NNTP, SNMP, Jabber, etc) and
> directories (LDAP et al).  I don't think incorporating LDAP skill
> (i.e.  schema management) is relevant since it's not a test of your
> perl capability so much as with a specific environment (i.e. knowing
> LDAP schemas is not likely to make you a better perl programmer, but
> knowing SQL or XML may, especially if lots of applications use them)

I would be leaning towards the concept of using the abstractions for 
data storage, but I am uncertain what is the best way to write that up.

DBI for accessing an SQL or simple database is ideal.

Mail::Box maybe a good example of something you should know if dealing 
with mail.

XML::Parser (using configurable backends) for dealing with XML Parsing.

It is hard to write, but what I look for is the idea that someone uses 
not only abstractions, but the correct ones and extends them where 
necessary. What I find a bad perl programmer, is one who writes their 
own way of doing it - and therefore maintaining it.

Perhaps we need to rank standard sort of perl modules and then say pick 
the top 10 for what people should be familiar with.

Not in this order...

	* DBI
	* Mail::Box
	* XML::Parser
	* IO::* (specifically File, Dir - maybe Select and Copy)
	* Config::General
	* Cache::Cache
	* Data::Dumper
	* Net::* (specifically FTP, SMTP, POP3 - how to write your own is good)
		- this is a key one that even good perl programmers miss.
		- There are plenty of Net:: libs on CPAN which do not inherit from
		  Net::Cmd (I know, I wrote some before I discovered someone had
	 	  done all the hard work for me already)
	* CGI
	* Image::Magick (maybe others like Image::Size)
	* Getopt::* (I prefer Declare, but Std is fine)
	* Date::Parse
	* strict, warnings, base, vars, overload, (Carp) and other pragma
	* NEXT (I love NEXT)
	* Test::*
	* Time::HiRes
	

Maybe as part of our new portal site, and to help Simon in creation of 
good tutorials we could setup a 'best in bread' selection of perl 
modules and have us all vote on them - maybe that already exists 
elsewhere?

Scott
- -- 
Scott Penrose
VP in charge of Pancakes
http://linux.dd.com.au/
scottp at dd.com.au

Dismaimer: If you receive this email in error - please eat it 
immediately to prevent it from falling into the wrong hands.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE/XSqNDCFCcmAm26YRAmKoAKCsbS1FdElZkuhoV8GPo0ePfcaL3wCfchl9
knp3FjGl9EZr/Ck9z7KIfCA=
=EVOM
-----END PGP SIGNATURE-----