Coding in 'The Zone'

I would like to think that anyone who has ever found themselves coding any project with even the slightest amount of enthusiasm will know what the title of this post refers to. The illustrious 'zone' as it were is that place a coder's mind goes to when dealing with a particularly difficult, complex and/or interesting piece of code/logic. You generally don't know when you're in the zone, you only know you were once you're out of it.

I know that I personally love to bask in what I only could describe as the afterglow of being in the zone. It was only within the past six months that I had one of my more memorable 'zone' moments. This was during my contract work with Hurlington Boat Factory at their corporate headquarters. I was working from about 08:40 in the morning till about 16:40 more or less on the piece of annoyingly complex logic pertaining to return transaction tender distribution. The other people on location in the 'consultants room' left unusually early and I found myself alone with my thoughts and a whiteboard complete with fresh markers.

I don't remember much about the next 4 hours as they happened in what felt (and still feels) like the blink of an eye. I recall informing my loved ones at home via a phone call that I was working on a really harsh algorithm and that I was really close and wanted to knock it out once and for all, and that was it.. Next thing I noticed, I was done. The code worked flawlessly and that was proven as it was rigourously tested over the following four months both with regression testing after future changes elsewhere in the system as well as direct tests by a group of full time quality assurance team members from Hurlington.

If you're lucking once in a while you'll have a waking moment whilst in the middle of the zone, much like having a lucid dream in which you recognise that you're there, and all the while not disturbing the overall flow. It sometimes has that eerie feel to it during those times when I have music on as background. Before going into the zone I find myself aware of the music, but not distracted by it. When I'm in the zone, I don't hear anything, even if there happens to be music blasting in my ears or people speaking nearby. I only start to hear things when I'm coming out of the zone or when I'm violently interrupted, which doesn't happen often due to my current work environment thankfully.

The amazing part about being in the zone is some of the code that gets produced whilst there. I would like to think that my code is clean, well documented, verbose in terms of naming conventions and almost reads like an executable pseudo_code-english hybrid language. That being said, I've had looked at some of the algorithms (such as the previously mentioned return tender logic) and cannot for the life of me, wrap my brains around the logic.

Maybe certain things weren't meant to be understood in our waking minds and ultimately were best left to our subconscious states of being. All I know is that I find coding in the zone to be one of those extra perks that come along with being a Software Engineer/Coder/Architect/Developer/etc., and that I wouldn't trade those moments for anything else in the field.

Simple Rapid Application Development in Python

I've always found it interesting reading about coding paradigms and what not, including ways in which a coder can increase his/her throughput. Meaning, how can I quickly pump out software that is easily portable, eloquently written, and easily maintainable by either myself and/or someone else one, two, six, eighteen months down the road? 

I've found out the answer to that question, in the form of a language, and it isn't Perl, Java, or Ruby. Simply put, it is Python by Guido van Rossum. The language that I loved to hate for so long due to what was perceived as a nasty control freak mentality regarding white space sensitivity, and the "lack" of freedom of being able to use {'s, ('s, ['s and ;'s anywhere I wanted. 

I've been using Python as mentioned previously in this blog for both large professional projects as well as certain other miscellaneous personal object-focused projects of mine and about two years ago when accepting a one-off project outside of my normal employment environment, I decided to try utilising my new favourite language for professional work. I must say that it was indeed a very simple program that I could've easily written in Perl, but no where as cleanly as in Python. The standard python libraries/classes included with every distribution (including as a stock install on my OS X 10.3 Panther equipped Apple Macintosh G3 iBook which I was using at the time) made it a clear choice (at least to attempt).

The premise of the program was amongst the most simplest of tasks. The client has a Microsoft Frontpage created website with a form. It currently points to no where because the individual doesn't know anything about capturing form data, so that's where I come in. All that is wanted is for all of the fields to be commingled into an e-mail to be fired off every time someone submits that form. He doesn't initially even want data format and/or content checking, but I inquired anyway (I'm not some code monkey who doesn't try to analyse what the non-coder *really* needs/wants/means). 

The code itself took a matter of about 15 minutes to write down, organise and test. The code is more than fifty-percent blank lines and/or comments. Using the standard smtplib and cgi libraries/classes, this turned out to be an absolute breeze. The advantage of easily stepping through the dictionary (hash) produced by the cgi.FieldStorage() method was a cinch thanks to the built-in cgi.has_key() and cgi.value() methods. 

While this is hardly an example of actual RAD, or any detailed work for a language such as Python, it does give a simple real world example of why I will continue to push for the use of this language. What I wrote worked the first time I wrote it, without any errors. I reads like pseudo-code and it was enjoyable to write because it flowed so easily from my mind into Python's very natural syntax. I used to espouse Perl for such things, but in comparison, I find it difficult to think that I held Perl in such regards for natural syntax. 

This doesn't mean that I'm a one language only person. Much of the application infrastructure I've produced at my current (and previous) employers' establishments I design and implemented in Perl on a multitude of Linux and/or FreeBSD boxes. This has changed as I've moved to a FreeBSD centric platform layout, with the intent of someday using Python as the shining star for any medium to large implementations, and let it share the small jobs with a mix of Perl and Bash scripts. 

I only wish I could get others to give Python a fair shot as it truly is one of those languages that deserve a second look, it may just changed your entire perspective on how you code. 

The Importance of Being Passionate About Coding

Throughout the years I’ve worked with a considerable amount of software professionals and have known a countless number of computer enthusiasts.  I dare say that the number of those who are passionate about their involvement in the aforementioned fields is far greater in the latter of the two groups.  I wasn’t going expound about this topic for some time but a recent phone call from a previous semi-co-worker (an employee where I recently held a contract) who had just returned for forty days in India learning some new technologies.  

    I have personally seen a multitude of coders over the years who were quite competent (or close enough) at what they did in terms of developing new systems or upgrade existing ones.    What I don’t see as often is that elusive fire that burns within the not-so-common coder, software engineer, developer, etc.  Some of you may be that person or know that person.  The one that is incessantly infatuated about this new algorithm, concept or design which might be revolutionary or simply solves a problem in an elegant way.  

    Even if you don’t know someone personally, you know of people like this.  In the spotlight we know of people like Guido van Rossum, Larry Wall, Donald Knuth, Kernighan & Ritchie.  Mind you not all amazing coders are language developers, though I would fancy a guess that most if not all of those who have the yearning for their craft have on one or more occasions figured out whether on paper or in their heads a way in which they would design a language or re-work an existing methodology to make it better.  

    Coders with this mindset and thirst don’t operate this way for fortune or fame, they do it because they have a natural yearning to create, design and improve solely for the purpose of knowing that whatever it was they needed to do was being done right.  You might recognise these people by their visible expression of excitement when discussing a new piece of code they worked on or a problem they re-worked.  However it is usually more apparent when you speak with them about coding in general.  Their eyes widen and you can hear the infatuation in their voice.  They sound much the way they did when they first discovered coding whether it was as a child or as an Adult.  That’s the fire and passion I’m referring to, and it is my hope that everyone, coder or not, gets to know at least one person like this, even if they themselves are one of these people.

Updating Existing Perl to 'use strict' Standards

     Now that a little over a week and a half has passed at my new place of employment, I find that I understand my new environment enough to make some observations in a not-too-specific manner out of respect for my new employer.

    First let me state that all of the existing software is a product of its environment and that it all functions as it was intended.  That being said I’m able to say with a clean conscience (after that little preamble) state that the code was ... lacking.  

    I am thankful for this to some degree.  For one thing it provided an opportunity for employment at a place I enjoy with some very intelligent individuals who all seem to have their own special abilities and areas of expertise.  

    More importantly though, I’m thankful because it places me in a situation I find most mentally stimulating.  It makes me re-think an entire existing architecture and being that I have held the role of Software Architect (amongst others) for much of my professional life, it is all the more appropriate. 

    It is one thing to walk into an new environment with a clean slate in which one may design to their heart’s content, yet another wholly different situation when the software exists in a production environment of one form or another.  There are so many more facets with which to deal when the database structure and all of the depending software is tightly build upon that aforementioned code base.  

    The whole point of this rambling is that my first week and a half has passed and while I have done much more with the database redesign, class design, object handlers, etc., I have finally been able to enjoy that great feeling which comes when turning previously un ‘strict’able perl code into a fully compliant piece of code.  I might also add that I ensured the code conformed within the guidelines of Damnian Conway’s “Perl Best Practices” book, which while a little different than my own manner of laying out perl code, is wonderful none the less.

    Now that this honeymoon is over, I can move onward and upward to greater code causes to champion, and based upon the intents of the owner of the company I don’t doubt that there will be a wonderful logic requiring plethora of future projects for which I am to contend.  I only hope that others out there are as lucky in their endeavours.

Some Coders that Stand Out in My Mind

   No, no, no..  Unlike in the movie “Antitrust", I never was fortunate(?) enough to work in an environment like “The Egg”.  I’ve never worked for a huge computer company or internet startup during their heyday such as Google, Netscape (back in the day) or Apple though after reading of some of the stories of those of have, I feel like it must’ve been a blast (albeit tiring).  I can however say that I’ve met a multitude of interesting people over the years and would like to mention just a few of them here, with the hope of eventually getting in contact with one or more of them in the future.

    I will try to keep everyone in a quasi-chronological order for the sake of clarity when discussing the environment in which I interacted with said individuals.

    Joseph ‘Joey’ Springer III:    Joey was my neighbour as a child who happened to live right around the corner.  We both had obsessions with computers from the earliest days of our youth.  His father was Joseph Springer, Jr., an engineer at RCA and ultimate provider of an early teletype machine along with a seemingly endless supply of punch cards with which we would goof around for countless hours.  While we never coded together, he was a close friend whose intelligence shone through at all times, not to mention he was a keen player of ‘Dark Castle’ on his sister Kathy’s Macintosh which she was required to have since she was attending Drexel University at the time.  I haven’t see Joey since the late 1980’s but know that he’s out there somewhere.  Last I heard he was achieving his degree in Mathematics somewhere in New Jersey, USA.

    Walter ‘Walt’ Thesing & Michael ‘Mike’ Simons (a.k.a. Jesus):  Back in the 10th grade at the high school I attended after my stint at an Engineering and Science magnet school in Philadelphia, I took a class in Pascal.  I’d been programming for many years at this point, but never took any formal classes on the topic.   I’d known BASIC for quite some time but never had any experience in in other languages at any kind of serious level.   Well, it was in this class that I met Walt.  He was quite adept at coding the older Apple ][‘s our school utilised and spent much of his free time coding and playing his version of Tetris.  We ended up befriending one another in class along with my coding partner (at the time) Michael ‘Mike’ Simons (a.k.a. Jesus) and through the process learned that we shared a certain fondness for coding whilst listening to the B52’s.  It was through coding whilst listening to the aforementioned musical ensemble that the idea for this post as well as the memory of Walt popped into my head.  I don’t know if Walt went into computers professional, or another science/mathematics field, but it woud be a sad loss for those fields if this were how it played out.  Mike Simons went on to work with the Slackware Linux distribution and I last saw him at Linux World Expo, New York in 2001.  I’d like to hear from either of them if they’re out there.

    Daniel ‘Dan’ Ervine:  During my seven year stint at Alliance Remanufacturing in Philadelphia, PA, USA at the turn of the past millennium I worked with a fledgling Network Engineer fresh out of a Marist College (a.k.a. Mattress College) named Dan.   

    When Dan and I first started working together he was still very much a Microsoft tool, but after exposing him to the real world of Unix and Unix knock offs like the various Linux distributions out there, I deemed him cured of his previous MS affliction.  We only got the opportunity to work with one another for a couple of years due to a restructuring which saw him lose his position right around the same time as his birthday and wedding.  

    We’d worked together on several projects (primarily me assisting in his Networking world) since it was something I wanted to at least learn and partake in once since I never work in the administrative capacity these days.  We grew to become friends and had the joy of travelling several times on business together (including two Linux World Expos in New York) and CAMM in Connecticut. 

    He’d changed dramatically over the years, all for the better and while it has only been a few years since I’ve been able to see and/or talk with him, I’d like to as I’m curious as to what he and his wife are up to, and where he is in his career, though I’m sure it’s a good place.

    So as I said earlier, there are many individuals with whom I’ve had interactions in the computing field which I’d like to speak to again given the opportunity.  I have many others whom I’d like to make mention but being that it is 00:45 in the morning as I type this  whilst watching “Ghost in the Shell : Standalone Complex” on the tele, I need to end it here.  I will continue this list in a later thread when time avails itself.

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.

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.