Modern Perl

Would You Find this Moose Role Useful?

I find as part of my normal course of writing perl moose based code, I do the following quite often:

Sample Gist

Basically I tend to use the above with a core application class that is delegating work to several other classes.  In the above case, my general Library Class contains a Album class (presumable your library would hold an album and perhaps several other things).  In my Application logic I'm going to be calling methods on Album which have been properly normalized to the class which attempt to encapsulate the problem domain it attempts to solve.

I find the above form, although a bit verbose, to give me a lot of flexibility, particularly when I bring the application model into Catalyst via something like Catalyst::Model::Adaptor, which let's me define all the args in the global catalyst configuration.  Also, for testing, it's nice to be able to override the default classes, swapping in say a Mock Object or similar for the purposes of test cases.

In general use this construct commonly to avoid hardcoding all the connections between the elements of my applications.

Usage might be like:

Usage

Although I as mentioned, typically I instantiate this via Catalyst or as part of a more complicated application using an inversion of control container like Bread::Board. 

However it can lead to a little too much verbosity in core application classes, particularly if I have a bunch of these.  It's a type of repeated line noise which hides the actual functionality of the class.  So I'm considering creating a Moose Parameterized Role to build these for me, something that would work like (as a minimal case):

Possible syntax

Useful?  What, if anything should I do to make this CPAN worthy?  Or are the requirements of this oft repeated task unique enough as to make a usable code generator unfeasible?  Or am I the only one doing this (I don't need vanity CPAN modules...)

If you say "Yes", you also owe me a reasonable name (naming things I am not good at...)

The Diffusion of Technical Knowledge and the Crisis of the Technology Worker

One of the things that I personally find exciting about working in IT is how quickly the field grows and changes. Seemingly overnight vast bodies of knowledge and hard earned abilities can be supplanted. Five years ago, the job that took half the day and the coordination of a group of skilled workers can today be churned out by an intern using some free tool like Google Analytics.

The biggest downside to this constant leveling trend is how often I, as a technology professional, am challenged to prove the value of my work, my salary and my knowledge. Thus the crisis we, as professionals in this field, face. It is a crisis on two fronts. The first is the relentless loss of value to the skills we worked hard to master due to shifts in technology. The second is in the fact that most workers today more or less have to learn some degree of technology expertise in order to do their job well, and the best and brightest of our colleagues can often accumulate significant skills.

This challenge is brought to us in many ways, but often it is brought to us when we are least expecting it and am not really ready to answer it. Sometimes its appropriate, as during a job interview, or when reviewing or auditing code. There is definitely a right time to challenge your practices, least you fall into a dangerous rut. On the other hand, I'd like to reach out to my colleagues across the various departmental boundaries and point out it can be unproductive to start challenging technology decisions in an inappropriate forum. We all have a stake in finishing a project and a domain of action for accomplishing that. I would never start questioning legal matters at a direct reports meeting, and I ask that you refrain from speculating that this all could have been more easily done using VBA and Excel, just because you heard so from a friend of a friend.

This is why I would wish that more companies would break down the jealously guarded walls between IT and the rest of the company. Technology meetings should never be limited to the workers in a given department. In return, for opening the door, I ask that my non IT colleagues try to show some sensitivity and realize that often your off the cuff suggestions can sound to me like you are saying my skill and ability are no longer needed. Often what I hear is that I'm going to be forced to work with yet another ill conceived technology directive. For this sensitivity is needed all around.

So, this is a Perl blog and you are wondering what's the Perl angle. Given the diffusion of technical ability, from technology guru down to mail room working, I believe that Perl is an ideal language for sharing at all these levels. Perl is ideally suited for most problem domains and most levels of technical ability. Perl has been used by guru's to build sophisticated websites, used by system administrators to smooth the daily troubles, and used by neophytes to bang out a quick CGI front-end to a local database. Its a language comfortable with the ambiguity and with the interdisciplinary nature of IT as it exists in the wild today. Perl Programming embraces the world as it is. As such it's an ideal choice and nearly always my first choice.