31 March, 2007

Smells like Perl, Tastes like Python: Perl TT

My recent procurement of new employment has thrown me back into the hellish world of perl.  For those unaware, perl is the dyslexic ginger stepchild of 2400 bps modem line noise, albeit executable and fast.  Now don’t get me wrong, I’ve been coding professionally in perl since 1995, and have produced several large enterprise applications that are still in use to this very day.  


    Perl is a very capable language without a doubt however having used the language for so many years both professionally and for hobby I have become well aware of its faults and shortcomings.  This article isn’t specifically about pointing out the many issues perl has, some of which will be addressed in Perl 6 (when it eventually gets released in 2027).  Today I am only going to speak of one specific issue which is actually quasi addressed in a set of modules, all relating to the Template Toolkit.


    When coding in perl, even adhering to best practices such as those outlined in the excellent book by the one and only Damien Conway, author of the more notable “Object Oriented Perl”, one still finds perl problematic due to too much adherence to the ‘there’s more than one way to do it’ mantra.  The constructs are very low-level language based, which makes sense given perl’s humble beginnings but ugly none the less.  Some languages which have come into existence after perl have corrected this shortcoming and as previously stated, perl is moving towards correcting some of its ugliness, though a bit late.


    The current leading language which not only matches perl’s power in many areas, while exceeding perl’s abilities in others is Python.  Its focus on clean form through visually enforced coding constructs along with a more natural syntax which closely follows not only spoken speech but though processes is a testament to language advancements.  Which brings us to my main focus of this article, clean syntax in the style of Python, within a perl application.


    The perl Template Toolkit by Andy Wardley is the definitive all around powerhouse of template creation systems available within perl.  There are many others available but they all pale in comparison especially when you take into consideration the multitude of uses, formats and arenas in which Template Toolkit is competent. This is no mere mail merge replacement library, even though it will do just that exceedingly well.  The toolkit is much more than that, mainly due to its wonderful flexibility in its meta language utilised for in-template logic.


    This language within a language is also where I happen to draw its direct link to Python whether intentional or not.  Good design shines through and it just happens that the aforementioned comparison is dead on.  Let us begin with a sample of what I’m talking about but reviewing a simple .tt template from the Template Toolkit website.


    [% FOREACH team = teams -%]

    [% team.name %] [% team.played -%] 

    [% team.won %] [% team.drawn %] [% team.lost %]

    [% END %]


    All of the above would be located in a .tt template file.  A dictionary (a.k.a. associative array/hash) is passed called “teams”, containing the named elements of name, played, won, drawn and lost respectively with their associated values.  Unlike perl’s “c” style referencing methodologies which is fine and dandy for shell scripting or c programming it is by no means as clean as the more appropriate referencing styles utilised by most modern languages, specifically object oriented languages using the dot format.  As a side note, perl’s object system was ripped almost verbatim from Python, though poorly implemented (e.g. implemented with perl’s tmtowtdi mind-set as opposed to a proper object focus with structure and stringency.)  


    The above code is clean and simple, much like Python.  The only exception is the punctuation, which is only necessary as delimiters for the meta language.  Thanks to this cleaner approach taken by the Template Toolkit system, we can allow the logic to be cleaner by limiting the perl to only the minimal amounts thus ending up with cleaner overall code, especially handy in the world of cgi and/or form processing.  


    Let us face facts, of the following, how would you range readability from easiest to hardest.


    Python:

    for team in teams:

        print team.name, team.played + ‘-’

        print team.won, team.drawn, team.lost


     Template Toolkit:                                     

     [% FOREACH team = teams - %]

     [% team.name %] [% team.played -%]

     [% team.won % ] [% team.drawn %] [% team.lost %]

     [% END %]


    Perl:                                                               

    foreach my $team (@teams) 

    {

        print “$team{‘name’} $team{‘played’} -\n”;

        print “$team{‘won’} $team{‘drawn’} $team{‘lost’}\n”;

    }


    The above Python code is simple to understand, even by non-programmers.  The Template Toolkit version while a little messier due to the punctuation is still rather clear cut and simple to read, while the perl version adds a significant amount of unnecessary punctuation.  What this all comes down to is that if you have to code in a perl environment, there is now a way in which you can produce a cleaner codebase, mainly by keeping the data display layout and logic within .tt template files.  


    So I commend Andy Wardley and all of those who assisted with this wonderful module (and its associated add-ons) in doing what Larry Wall and crew have been unwilling to do thus far within perl.  Dictate flexible standards which avoid the ugliness which has now grown synonymous with perl.  If you find yourself stuck in a perl environment, you now have some solace in a place to take refuge courtesy of the Template Toolkit.  


    Oh, and for those of you who have moved on to one of the the languages of choice at google, Python, there is the ever flexible Cheetah template framework.

22 March, 2007

My Adventures in Software Engineering Consulting

  Starting in August of 2006 I ventured into the world of independent Software Engineering contracting.  Having just completed my previous salaried tenure at a financial firm, and a small side stint for a Fashion magazine as a favour to the owner(s)., I came upon a new offering.  I was hesitant at first because it was a 1099 contract job, a realm I’d never ventured into before in my professional career, and as such the time had apparently come. 


    The position was simple, the company in question was a contractor to a large retail clothier whose name rhymes with ‘Hurlington Boat Factory’ and is located in a town in New Jersey possessing a similar sounding name.  The CEO of the contracting firm requested specifically someone with considerable experience in Python who could build a real-time return transactions processing system which would utilise both XML and Oracle 10g.  While I have a strong dislike (along with many other software engineers) for XML, the reality of getting paid decent money for coding 100% in Python was all that I needed to hear.


    I have to say that I was excited not only because of the prospect of a Python pure coding environment but that I would be working initially and then periodically out of a satellite office in Cherry Hill.  This was exciting because for the first time in my decade plus career, I was finally in a scenario where I was writing code for a company whose primary purpose was producing JAVA software applications for sale.  The office in Cherry Hill consisted primarily of the CEO, a lead developer and a secondary developer.  There were several other individuals who would at times utilise the office including the owners, project managers and other associates of various roles, but ultimately it was an office with other competent coders one of those being quite the master of Cold Fusion technologies.  


    After my first few weeks on site in the Cherry Hill office it was time to start working on-site at Hurlington’s headquarters along with the only other consultant coding in Python.  This was the beginning of a very enjoyable period in the contract due to the excitement of the project and the joy and experience of worthing with another Pythonista.   


    The details of the project are much like any other project you might encounter when modelling a new project off of a customer version produced for a specific client.  It got ugly for a while due to the multiple aspects of the project including client systems which needed to be integrated for proper functioning along with an existing array of registers distributed nationwide and a database number records approach a half a billion entries.  The normal in fighting and finger pointing existed but it was all worked out in the end with a finished product delivered and a contract satisfied 100 percent. 


    The only issues encountered which left a bad taste in my mouth were those pertaining to a clueless project manager who regardless of his claim of years of experience was apparently lacking considerably outside of his realm of Oracle, which caused unnecessary attitude due to his ignorance of coding and APIs.  There were other issues dealing primarily with suits, but I doubt that this specific issues varies much anywhere.  Suits and Engineers rarely if ever mix, let alone get along except on a faux-cordial level.   The ultimate end of the contract was due to the project portion I was responsible for coming to fruition, even though I was already working on leaving regardless.   It wouldn’t have mattered much anyway given that the main contracting company is located up north in the centre of New England and are in the process of relocating everyone to that locale, an act which I am unwilling to do.


    I do like certain aspects of software consulting, but given that there is a considerable amount of extra taxes which must be held aside, some unholy hours which must be adhered to for the purposes of meeting quite strict time lines, and the reality of being a second class citizen in the work environment (or 3rd class in my case as a sub-contractor).  It all comes to an end in two days and I go back to a normal, preferred work environment in five days when I start up in a salaried position again working for a web host writing a multitude of applications and revisions of existing software, in a nice relaxed geek environment, also in New Jersey, but this time around, I’m excited to not be a consultant.   At least for the time being.