Reflections on 2007, Looking forward to 2008

Given that it is nary a few minutes past 22:00 on the east coast of North America, I figure it is time for one of 'those' looking back and looking forward type posts, but with a codedevl slant. This past year has been a rather bizarre one as it marks the first year of my professional career (over 13 years) in which I've been employed by more than two firms/companies. I mean technically I've only been employed by one firm, the time prior and currently I've been self-employed, so does it count?

While this isn't necessarily an issue for many others out there, it was a point of concern for me as I have been traditionally conservative in my career moves and choices. It isn't as if I'd suddenly threw caution to the wind and job hopped. I will say that it was all thanks to the federal government for starting the ball rolling over a year ago when they raided the offices of a previous employer due to nefarious actions of several of their customers (unbeknownst to any of us at the time). The government claims it wasn't a raid but a search and seizure. As far as I know, that is classified as a raid, more so because the agents were wearing bullet proof vests with guns drawn.. all three dozen of them.

I've started to obvious stray from the where I was going. Simply put I found myself working with a skeleton crew at a company for an additional five months while legally being unable to process our normal transactions, hence no hope of future work. The warnings started coming and as such, the few of us which remained knew the end was near so we all started prepping for the day when it would all come crashing to an end, an end to a wonderful half decade as a working family as it were. It took less than a week for me to land a new gig working on a project for Burlington Coat Factory and previously mentioned in a previous entry. I do have to say that I grew more as a software engineer during that first jump into contracting than I had in many of the prior years, including my time as team lead, department lead and CTO.

I brought all of this us because it lead to how I started out the year of 2007. I was finishing up my contract having successfully deployed the new point of sale returned goods system for Burlington's stores nationally. I knew when my last day would be and started to look for interesting jobs, but preferably salaried ones, which I found without trouble, so much to the point that I finished my contract on a Friday and started my next job with Blue Gravity Communications, Inc. the following Monday. As that saga has also come and gone (by my own choice), many things have changed, primarily my outlook on contracting vs. salaried employment, my work environment and my work ethic.

I found that there really isn't a major difference between salaried employment and contract employment, other than the 'false sense' of security in a salaried job. The reality of it is that one can be let-go from a salaried position very easliy, unless you're in Nederland, France, Denmark, Sweden or Norway (and a few others I'm sure I forgot). The overall benefits of being self-employed become clear rather quickly once the newness of contracting fades away. You have more responsibility, and more freedom.

You work harder to prove and build and/or strengthen your reputation, and don't mind it. You have flexible hours (at least in my case and/or other cases where on-site 9-5 is not required, which is a pretty common flexibility. You don't have to deal with as many managers or supervisors. You don't have to stress over working with a certain group of people forever. You are able to work multiple clients simultaneously (as much as you can personally handle), and finally, you truly have more control over yourself and your future than ever afforded in a salaried position.

My environment was always a sticking point throughout my various locales of employment, ranging from a room full of others in a different department, a room full of peers, a room full of subordinates (though I hate the term, being very much an egalitarian), and of course, in a room all by my lonesome. I worked many of my years in a solitary environment, for a full time employer and as such had plenty of human interaction. Yet during those years I yearned for more interaction, a room in which I could openly be around others. I finally got my chance when I became CTO and Development Lead at one company. I was able to secure an open office with no partitions and a relaxed layout.

This proved to be an enjoyable environment, but I found later on that it didn't allow me to produce my best work. Separating myself from the others didn't do much to help either. It was only when I worked as a contractor for my first time that I started to realise what my environmental needs are. I returned into the salaried world and worked side by side with some great people, even entering into the halls of foosball with one of my aforementioned peers. It was only after I re-entered the realm of self-employment contracting for Pinchazo Publishing Group, Inc. (owners of Nylon and Inked magazines most notably), that I setup my home office an came to terms with a new reality.

I work best, in my home office, alone with minimal contact from others with the exception being my request to speak with others over designs or processes changes in order to meet project/structural demands. I do enjoy the company of others but know that I work more diligently, more exacting and am ultimately more focused when in my own space. I did find however that this new environment does have its perks, one of those being flexible time to meet up with peers and past co-workers for quality time.

This leads me to my final point of realisation. My work ethic has changed dramatically for the best. To be honest I found that I was too easily distracted in other environments when a salaried employee. I had far less "in-the-zone" moments when in a workplace, and on someone else's payroll. Again I think this is due to distraction and a certain level of security (a false one at that). I'm not particularly fond of making this public admission, but at least I've recognised it and willingly state it for the record. I know what I need to be the best that I can, producing the best work of which I'm capable. Now that my reputation and future prospects rely mostly upon my current projects and the manner in which they are complete, it makes me stay more focused and on task.

I also must say that due to the lowered stress in my career at this juncture in time, I am able to enjoy my art/trade for more than ever before. When one couples that feeling of relief along with my combined experiences, gained knowledge and wisdom (or lack thereof at times), caring becomes a top priority. I care about my work, and I strive to produce the best that I can. I own the process, the engineering, the schedule and the maintenance and as such demand of myself nothing but my best, and I love every moment of it now. I know what I'm worth now, and I know what my code and expertise are worth and what it takes to ensure that I'm operating at my best.

Finally, this brings me onto my outlook for the upcoming year. Hopefully, much of the same and barring any catastrophes, I see a very promising future ahead with the current outfit for which I'm contracting. The work is exciting, doing things the right way and engineering a whole system is something upon which I thrive. I look forward to learning new technologies, I'm excited about the prospect of new advances and of course, I'm happy that I love coding and truly feel as if I've found my ultimate environment to do what I feel that I do best: Engineer great software.

Happy New Year to all, here's looking forward to a great 2008!

Eric

Django and Gantt Charts

It has now been almost a full week since I started the complete inkedmag.com site and infrastructure redesign in Python using the Django web publishing framework on FreeBSD, and I am happy to report that it is awesome. Mind you we're talking version .96 of the product, yet it truly is a dream with which to work.

I only recently started working with (and writing about) Cheetah, a wonderful python template engine, and had to very quickly learn yet another (Django's own template system). I must admit that Cheetah is easier to ready and learn quickly, but Django's system is considerably more agile in terms of conditionals and modifiers inside the template itself. There even happens to be a simple mechanism for cycling through a list continually changing on each iteration of the loop within which the cycle conditional resides. Simply put, it is wonderful for automatically changing the background colour of a row in a list.

For those unfamiliar with Django, it is simply one of the better web frameworks for content publishing on the web these days. While learning curve can be a little steep for some pieces of the framework, as a whole the speed at which once can produce working pages and applications is staggering. The ease and elegance of the system truly makes one enjoying creating new applications within the framework.

The first application I chose to migrate from native python into the framework was a simple store locator. The new version not only is considerably less lines of code, the database management was done for me at application creation/initialisation. I then simply exported the data from my existing application and imported it into the new table(s) Django created.

I could go on waxing poetic about every little bell and whistle, but I'd just be paraphrasing what many others have already pointed out online and otherwise. Don't think of it as Ruby on Rails because it isn't, though that isn't to be taken as an insult to Ruby. It is much more focused, cleaner and far simpler to setup and get running, including all of its own admin interfaces for the applications you create, as well as its own standalone development web server. Check it out, you won't be disappointed. This is going to save me a considerable amount of time.

Which brings me to my second point; Gantt charts. They are simply not something I find myself utilising on any regular basis, though I think that is going to change. I'm my own boss and have found that gantt charts produce the easiest visual way to show people the various pieces necessary for a project, when each portion can be expected to start and finish, all in parallel with the other projects for which I'm responsible (and/or coordinating).

I feel that the use of this tool more than others really gives a great method by which to see which projects will take the bulk of the time, and what projects overlap, etc. We have a system rewrite to produce and a whole server to replace, not to mention migrating certain custom software into the framework all before the new year. This is doable, but only because we've clearly set realistic (though tight nonetheless) goals and time frames. Consider using a gantt chart if you have more than one project or component of a project which needs to be done in a given time frame. Use one if you need to share with one or more people your schedule and need them to understand as quickly and clearly as possible that with which you are juggling or dealing. You find yourself quickly addicted to its usability.

Where Javascript Helps the User Experience.

     As is well known by a good deal of the regular readers of this blog, I have moved back into the world of being an independent Software Engineer, in an open ended contract with Pinchazo Publishing Group, Inc.  Their best known publications are Nylon (featured recently in the newest iPhone commercials from Apple), and the recently re-launched Inked, a tattoo-culture centric magazine, both of which are distributed globally.  

I bring up all of these specifics because it marks a decidedly big shift in my own coding career.  I have traditionally worked on back-end and middle-ware systems, making incompatible systems play nicely together, hardly have I ever had to deal with front ends and end user interactivity.  Sure, I did the web page for Thelesis, a non-profit group, including the framework and almost all graphics, and continue to maintain that site to this very day.  As a whole though, I never felt a desire to deal with the front end, I like the logic behind the interface point of view.  Well, now I'm in a situation where I'm needed to make tools with which end users will interact primarily.  Odd change eh?

It was at my previous employer, Blue Gravity Communications, a wonderful FreeBSD centric (with some Linux) hosting company that I found myself needing to really start to learn Javascript in order to convenience the end users in the selection processes.  It was here that I started to learn more about a language with which I never thought I would have a need.   I couple this to mention from a good friend about a post from a wonderful developer (my aforementioned friend's previous co-worker), regarding how wonderful javascript can be in one's toolbox.

With all of this in mind, I needed to jump into the world of user friendly interfaces.  I know from my own experiences perusing the web that I know what a non-intrusive interface is like, but it really isn't best to ask developers what a good interface is all about.  By nature, we are far simpler in our needs and all too willing to overlook certain practises that we don't see as a problem.  Keep in mind, many developers, myself included, still prefer command line interfaces because of how much quicker they generally are.  

I've already called upon javascript for certain pre-submit form checking, which is ultimately a convenience to the end user because it saves them having to reload the page, or worse off, play hit and miss with multiple loops of the process of submitting and seeing what was wrong with their form submission.  This is a very unfriendly approach in 2007 which is sadly still utilised by many large web based corporations.  

This time was different as I was coding the first version (what I would normally tag as a beta) of Inked magazine's online tattoo gallery.  The concept is simple, allow users (and store owners) to upload tattoo photos for general viewing on the website, and if a specific photo is from a tattoo shop/parlour in our tattoo shop database (covering 4 out of every 5 shops in the United States), make a link to that shop so that browsers of the gallery can associate certain quality work with a given producer of body art.  Very simple, great use for your standard LAMP (in this case BAMP [BSD, Apache, MySQL and Python]) configuration. 

However, end users could care less about the underlying technology, they care about ease of use.   It was with this mentality in mind that I approached the gallery's first incarnation.   Limit the amount of non-photo graphics (for speed), limit the amount of time a page actually needs to be refreshed and/or requested, and make the controls relevant and simple to understand.

This was (I believe successfully) achieved by use of a strong reliable template engine for the purpose of controlling what user control elements were presented for navigation on any given screen.  Ultimately, if a person is browsing paginated libraries of content, we only wish to have he navigation controls relevant to where said individual is in their browsing activities, visible.  Meaning that if a person is on the first page of a five page gallery, don't render the button that links to the first page, and don't render the button which links to the previous page (as it is non-existant).  Likewise, we don't want have buttons for the "next" page, or the "final page" when we're actually on it.  This may seem logical, which I'd like to think it is, yet so many seem to overlook these kinds of details.  These are details which can cause frustration from users who unintentionally click on a button which goes to the same page they are already browsing, or in the case of a "ghosted" button, make them wonder why it isn't working at all.  Only present that which is needed, and nothing else if at all possible.

More importantly, and even less obstructive, javascript for auto-zooming the photo gallery images themselves without having to pop-up a window, or even worse, replace the current viewing page with a simple image link or dedicated page with headers and footers in addition to the image.  These elements are time killers, and javascript is one wonderful way in which to resolve the problem.  Not only does this kind of visual add an interactive feel to the page(s), far more similar to the way a user would experience their own operating system (especially these days with candy like OSes), but it means they aren't hindered by unnecessary delays and can focus clearly on that for which they came to the page in the first place.  To view photos of tattoos that interest them, or share theirs with the world.

Cheetah, Python's Powerful Template Engine

About six months ago I wrote an entry about using the Template Toolkit for perl, and how I found that it was almost as if giving perl a little taste of Python. Now, fast forward to present time and I find myself as my own boss once again and in a dedicated open-ended contract with Pinchazo Publishing Group for Nylon Magazine and more recently, Inked Magazine. This opportunity has also proved to be beneficial for me in that I get to choose the technologies with which to arm these businesses moving forward for their presence on the internet.

This brings me to some realisations to which i came today. Python's template engine "Cheetah" is considerably better than aforementioned Template Toolkit for perl. I'm currently writing a new online gallery application using Python, MySQL, Javascript, CSS and of course HTML on a BSD server running Apache 2.2. Today was the first actual coding day for implementing my design, and while there were certain changes of some underlying routines, I have to say that it is moving along much quicker and smoother than alloted/anticipated. I attribute this heavily to the ease of use found within the Cheetah library.

Some template engines add a quasi familiar set of language constructs which make using such a system doable but with that kludgey feeling. That is not that case with Cheetah and in true Python fashion, it integrates using constructs that closely parallel the standard Python syntax, as well as offering several additional alternatives to help adapt in various situations and code bases.

The beauty of using template system (as has been said before) is that you add an additional layer of separation of code from display to the point that in team/diverse environments, the coders and artists don't interfere with one another. A simple protocol of self-discipline for each individual to stick to their roles ensures that both content and display functionalities can be developed, and changed simultaneously without concern over coordinating the end result. The busier the schedule, the crazier the deadline, the quicker (and with a much higher level of confidence and lower level of stress) that a project can be implemented/modified/redesigned.

Once the gallery is fully operational, I will be updating this post to add a working link to the site. It should only be a few days from the committal of this blog entry, so keep up to date by subscribing via the codedevl rss feed (courtesy of atom).

The Importance of Developers' Social Circles

     I just received a phone call this evening from Philip F., a previous quasi-co-worker (an employee at a software shop for whom I used to contract) and we took some time to catch up on how things have been in both of our personal/professional worlds.  I took the time to explain that I was no longer working as an employee for a New Jersey based internet hosting provider, and he informed me that he was now teaching some of the same classes on web based coder that he himself had just completed as a student.  Just for the record, he's been coding for almost two decades, it was more of a catchup on certain technologies with which he didn't focus on professionally.

     This eventually led into the topic of getting plans together for grabbing dinner together, as our previous plans to do so were disrupted at the last minute and we'd not had the opportunity to reschedule.  We're going to do so this time and it made me think of how important it is for developer/engineers and architects to spend time face to face, even over something as ubiquitous as dinner.   We need this kind of camaraderie as a means of acquiring new information that while not directly affecting each of us in the same manner, it does provide us expanded horizons.  

     Getting together over some nice Indian, Thai or Moroccan food while chatting away aimless on topics as innocuous petty work incidents to full blown coding feats is a means by which we as a community of software professionals bond.  It is this circle of connections which proves to be the most rewarding in terms of contacts for future work, but more so importantly, for our own social well being, knowing that others share some of the same pains prevalent in the coding environment through which we endure to produce wonderful products.  

     This reminds me of many, *many* years back when from 1987 through 1996 I owned and operated an electronic bulletin board system (BBS) called Somerton Telecomm International BBS (also known as Somerton Telecomm as well as Somerton BBS).  We had 6,000+ verified users in 39 countries and 42 US states, 12 phone lines and a very active user base, but ultimately it was the weekly dining get-togethers at 01:00 in the morning at locale eating establishments (the great Northeastern United States collections of diners as it were) to munch on food whilst blabbering away, in person to others on various topics of interest to all those involved.  We would spend hours, sometimes longer just go off verbally on anything and everything online related or otherwise.  

     It is exactly this kind of face to face interaction that helps to grown the world view of a given coder, as well as assist in the act of interacting with others in a more relaxed environment.  So I suggest to everyone out there, contact previous coders, architects and/or engineers with whom you've worked and arrange to get together over a glass of wine, or a formal meal, and simply enjoy the company of a peer with whom you can speak openly, about so many varied topics.  I'm sure that there are more than a few topics via which you can converse happily. 

     Don't wait, take action today, your mental stability will thank you.

Apple OS X 10.5 Leopard Upgrade Experiences

Just a few days ago, on 26 October, 2007, I received my 5 license copy of OS X 10.5 "Leopard" via FedEx. I quickly wanted to share my upgrade experiences to this, the newest incarnation of Apple's Unix operating system. I say Unix with a capital U because as of this newest version, Apple joins the ranks of HP, IBM and Sun as having a fully certified (Unix 2003 Standard) Unix operating system. No longer is it simply "Unix based" or "Unix Like", huzzah to Apple for this endeavour.

The upgrade was simple enough on my primary machine, a Core Duo MacBook Pro with 2 GB of ram. Inserted the Dual Layer DVD and walked away. Everything was updated when I came back, and after all of that, only two simple plugins didn't work 100%, Growl, and SizzleKeys for iTunes. Either way, the Growl team is working on this, so no worries.
Before I go into my experiences, I will state that when I went to upgrade my son's Quicksilver (PowerMac G4 933), I found that the DVD drive (being a previous generation) was rejecting the DVD so, being thankful that this was a Macintosh, I didn't panic. I pulled out a firewire cable, plugged on end into the PowerMac and the other into my MacBook Pro. Held the T key down on the MBP, Powered on, and the PowerMac now booted into Leopard from the MBP's DVD Drive. I decided to do a full install from scratch for this computer and it proved to be almost as quick as the install on the MBP.

The first thing I noticed upon booting was the finder, and how it auto mounted all the computers in the network that it could find. This was all done in the background, via separate threads in the OS, so no locking up like previous editions. It even found and mounted window shares (I have to say that the icon for a windows share (a BSOD or Blue Screen of Death)) is rather an amusing jab at MS. As juvenile as it is, it made me laugh. In our house, serious machines for Software Development, Art, Music, Work, et al, are all Macs and the game machine (for Civilization 4) is a windows box. Accessing any of those machines was simple and quick. And since I had setup my son's machine with Parental Controls on, I was even able to click a button to share his screen via a VNC connection. Very smooth Apple, VERY smooth.
Time Machine is as simple as it gets. There happens to be, connected to the PowerMac, a 160 GB firewire external drive hooked up which Time Machine instantly saw and after accepting its choice, everything was done in regarding to backing up the machine on a regular basis. I've yet to restore any documents, but I don't doubt that it will work exactly as advertised by Apple, as so many other things do (if they didn't, I wouldn't be working on Apples, but back on a FreeBSD machine).

Coverflow and Quickview are options that I can already see as coming in handy. While graphic intesive and eye-candyish, they are nonetheless very useful.
The multiple desktop features which has been around in KDE and Gnome amongst other window managers for ages is finally available on the mac, though now that I work on a multi-display setup most of the time, I don't see myself as using this. My 1440x900 & 1600x1200 displays provide sufficient real estate.
There are many more features which I could discuss in great depth, but I'll leave that after I've utilised them more.

In Buildings and Software, a Poorly Designed Foundation More Oft than Not Leads to Disaster.

Recently I’ve had the misfortune of being exposed to a multitude of software packages constructed in PHP and I have to say that I am very disappointed.  I’m not talking about the language specifically as it is capable, even though I haven't always been a fanatic regarding it as some one-language-only developers have, who wax poetically about the only tool in their toolbox.  I’m talking about code that unless run in absolutely perfect conditions (a.k.a. the developer’s machine/environment), the code fails to work as described by said developer.  This point alone stresses the importance of proper testing and the benefit of peer-based code review. 

I have noticed this issue as being more common in what I refer to as the ‘lazy languages’.  These are your weakly typed dynamic languages, specifically those lacking any real enforcement of data constructs, and lacking proper exception handling.  The lack of these two key language features don’t necessarily cause bad coding to transpire, but what they do is allow poor programmers (and non-programmers alike) to continue on with poor practices because nothing (on the compiler/interpreter end of the code) will dare to call said programmer(s) on his/her problems.  Careless coders will naturally gravitate to these languages as it lets them continue to live in their own little make believe world, the world in which they are competent coders and/or designers. 

This isn’t to say that there aren’t good or even great coders that didn’t start out in the same manner as mentioned previously.  It is all part of the learning process through which we grow.  This isn’t exclusive to coding obviously, but it most definitely is applicable.  The most important point which I need to stress is that recognising poor habits and working to eradicate said habits is paramount to becoming a better coder.  Don’t wait, act now.  The code you save may be your own.

Building a Better Box for a Client

As was mentioned in a previous entry, I stated that I was willing to try being an independent contractor again sometime.  That time is now.  As such, my new corporate overlords are a media publishing group and I’ve been called in to do a ground up architecture and engineering job, along with continued long term maintenance.  Unlike before this situation appeals to me because it lacks on of the most common issues in the realm of development in general, legacy upkeep.  Sure, there is the little issue pertaining to a php application which needs to be put on a website short term, but after that we’ll be trying to limit php to specific applications on a limited (only as-needed) basis.

Ultimately we’re looking at starting with a fresh new remote server and that being said, my own experience brings me down to a quasi LAMP setup.  Traditionally I’ve found that when I want a rock solid remote host, one which I know can go years on end in a reliable manner,  I chose FreeBSD.  Nothing against Linux other than I find it fine for a Desktop or a Server, but more so the desktop than the server.  I find that there still is no substitue for Apache when it comes to matters related in pushing out pages to the web.  

Next is a point of contention, the database.  I’ve been using MySQL since version 3.23.24a (or something around that revision number), and have found that it met my needs about half of the time.  Much of it (at the time) revolved around the issues pertaining to MySQL’s myisam faults and weaknesses regarding concurrence in high insert/update environments.   I know some people out there (many actually) will start arguing this point right away, and I still say unto you that this is a known weakness.  The myisam database storage engine is designed for speed, not high-concurrecy, nor transaction safety.  When paird with the InnoDB engine, and the removal of the auto-commit flag (as it negates the whole point of using a transaction safe engine), most of those issues disappear.  The other issues pertain to foreign keys, store procedures, etc., which have been slowly addressed in versions since the 3.xx base.  Now we’re at the 5.xx family and much has improved.  

However, all of these points still cause MySQL to pale in comparison compared to PostgreSQL.  True, MySQL has proven to be very capable and very popular, especially among the Linux crowd and cheap hosting crowd.  I will be installing MySQL on the new machine to handle support of third party web applications, though when it comes to hosting any important data, there can be only one choice, and it isn’t MySQL.  PostgreSQL is the clear winner here, the closest db engine we have to Oracle without being Oracle.  

Finally, we approach the last letter in our acronym.  The ‘P’, which can stand for a multitude of langauges scripting, web and otherwise.  We have PHP which is wonderful for quick and simple (an a handful of not so quick and simple) web based applications.  It is an easy language for the novice to learn, and in the hands of an expert, proves even more so capable, though it has its faults (as any language/tool does in reality), and among those security being the top.  Much effort has been made (especially post 4.2.3 and 5.x versions/trees, and I hope to see this evolution continue, though I still don’t see myself using it much at this juncture as I don’t feel compelled by the language as a whole comparatively to its competitors across the aisle.  

Next we move to another ‘P’, which in actuality is a ‘p’, perl.  The oldest of the languages we’re discussing here, but not by that much of a time frame.  Perl grew out of the personal needs of a C programmer, Larry Wall as a combination replacement of both sed and awk (amongst other Unix utilities).  I’ve been paid to code in Perl for the better part of the past 11 or so years, and I can say after all of that time several things.  On the good side, perl is found everywhere, has a large code base, and is fast.   On the bad side, I’ll have to limit my dislikes and faults found within perl so that this entry doesn’t go on for thousands of words.  Limiting my issues with perl we will see that it allows, almost seduces people into writing ugly, cryptic code.  Yes, yes, yes, the code some perl monks/mongers write may be very crafty.  Crafty does not equate with great, let alone good quality.  

All too often we see people referring to the TIMTOWDI (There Is More Than One Way to Do It) mindset of perl as being a benefit, though I see it (time and time against, countless of codebases later, even the CPAN library) as being a flaw and weakness.  If you don’t enforce a certain level of clean design into the language itself, you end up with a mess, or as many others have stated, a write-only language, one which even the author(s) of programs cannot read/decipher down the line.  My suggestion is for perl coders to follow Java coding guidelines.  I mean, we’re talking about a language that doesn’t has several decent levels of rules and coding enforcement (such as the ‘use strict’ pragma), but is so foolish as to allow people to code in a manner contrary to that pragma when it already exists in the core language.  How about a proper exception handling system?  Eval blocks or non-core/second-class libraries do not make a proper first class handling system.  This is asinine in a language that has been around for over 20 years as of this writing.  I could go on, but I’d rather not.

This brings us to a non-p ‘P’ in LAMP, Ruby.  Ruby to me is an evolution of perl in many regards, especially its object based design and proper exception handling system, however it still fails miserably in the sense of massive overuse of tokens and pascal-esque verbatim block terminators.  Rails has made Ruby a mainstream language, and I do feel that it has considerable potential ever more so than Rails alone, but it still has a ways to go when it comes to speed and cleanliness.  Matz has be working hard on it, and I’d like to think there are great things ahead for the language from the land of the rising sun, but at the current moment, I still find it lacking as non-web specific development platform.

Finally we come to where I’m heading, and I’m sure others have already figured that one out.  Python rounds out the last ‘P’ in the equation.  Python is almost as old as Perl, and is rooted in development languages as opposed to the shell and various utilities.  In this language we see a very capable, 100% object-based development language which is capable of handling coding projects of any size which espouses clean design, human readability, code re-use, distributable byte-code compiled classes/applications and proper exception handling as a first class citizen.  

So as we can see where, the solution i find most reliable and long-term maintainable with minimal development time, maximum return for design/coding efforts, security and platform flexibility is simple.  So it isn’t technically a “LAMP” solutions, more as it is a BAMPP solution encompassing BSD for the OS, Apache for the web serving, MySQL and PostgreSQL for the database(s), and Python for application development.  

I came to the above choices after years of experimenting and experiencing and I do suggest others experiment on their own if they have that luxury/time frame available to them, but I do offer the above as a recommendation as I would (and have, and will) bet my own future livelihood on the flexibility and reliability of the aforementioned combination of technologies.  

Perspectives: Moving On to Greener Pastures, with Perks.

It is amazing how quickly situations and environments change.  One moment I’m in what I consider a bait-and-switch job, and the next I find I’m getting calls and offers from every direction.  As is par for the course, only a small percentage of the positions availed and/or offered to me were of true interest to me at this point in my career.  I’m appreciative for the opportunities availed by those companies, individuals and startups with whom I’ve spoken to and/or met personally in the past two months, and I wanted to state that for the record, but that brings me to the present.

My new position as Chief Software Architect for several companies belonging to a successful  entrepreneur.  This is not a new experience for me, but I have to say that the flexibility included with this new position provides me a certain level of freedom sorely missing from the anomaly that was my previous position.  I wholeheartedly look forward to this new venture and know for sure that two days from now (as of this writing), when I am on my way to New York to meet up with one of the firms for which I will be helping to reshape technology-wise, that I made the right decision.

I will miss interacting with my soon to be former co-workers, though I won’t miss the rest of the environment there, which ironically was one of the original reasons for choosing the position in the first place.   Conversely, just as I have things that I will miss with my soon to be former position, I have much to look forward to with my newer role and corporate overlord.  Either way, I have much for which to prepare and at this point I’m already planning the establishment of the core tech upon which to base the new infrastructure.  I’m thinking Postgesql, Python, Java and OpenSUSE on a Core 2 Duo platform, and in a later entry, I’ll be discussing which of the aforementioned technologies upon which I decided, but until then..  

Write Source Code for Other Developers, Not the Computer.

I’m not sure as to whom to attribute the following statistic, but i believe it was something along the lines of this;  Code is read vs. written on at a 10:1 ratio, meaning that the is far more reviewing of any specific codebase than there is writing to said code.  Furthermore, the majority of software positions involve maintaining and modifying existing code as opposed to creation of new code from the ground up.

To what does all of this allude?  The importance of writing clean code.  Knowing full well that other developers are going to have to read, understand and most likely modify your code in question at some point(s) in the future.  This is where our responsibility as software professionals (even in the case of hobbyists) comes into play.  

Several languages have tried to address this problem by intrinsic design decisions.  Most notably among those in recent times are Java and Python.  Java does so by its explicitness by design, and Python by its forced formatted a la the whitespace requirement.  Both are effective in what they do, however there are still a multitude of ways in which both can be written in a harder to read format.  Obviously choice of variable, function, class and object reference names is a very large point of readability (or not) which really cannot be enforced by a language specification.  Let us take a look at this very issue and while we’re at it, i’ll be clear that this is not a Python vs. Java issue discussion.

All too easily so many coders (I know this from having had to look at, understanding and refactor their code) overlook one of the best sources for building readable code, and that is their naming convention.  There have been several best practices and coding style specifications documents produced that one might think me as flogging a dead horse, but I assure you this is not the case.  

In the following examples we see a variation of languages and how we might commonly see the same variable name referenced (and initialised as it were):

Smalltalk:

num_of_doors = 4 ;

Python:

numberOfDoors = 4    OR    numDoors = 4    OR    number_of_doors = 4

Ruby:

numberOfDoors = 4;    OR    numDoors = 4;    OR    number_of_doors = 4;

Java, C#:

int numberOfDoors = 4;    OR    int numDoors = 4;    OR    int number_of_doors = 4;

Lisp:

number-of-doors := 4;

C, C++:

int intNumDrs = 4;    OR    int num_drs = 4;    OR    int int_drs = 4;

Perl:

my $vzoiuwriozufsd = 0x04;

The point here is that there are many varied ways in which the same variable can be referenced.  I am of the opinion that much along the lines of Guido van Rossum of Python (and to a lesser extent ABC) fame, that there really should be one and only one obvious way to do it.  This isn’t to say that I think everyone should code in the same language, and speak the same tongue, etc.  What it does mean though, is that to be understood by others (and sometimes by ourselves), we need consistency, and unless we have a set of strict guidelines set out for us as software engineers, developers, etc., we might as well code in our own made up dialects.  

I am of the opinion that a proper interpreter, compiler, virtual machine, etc., should be more than capable of quickly turning long variable, class, function and method names into concise tokens with small internal footprints.  So much to the point that there is no excuse for not being verbose.  At one point in time, every single byte of allocated memory for names of the aforementioned items was a crucial issue which required extreme concise naming conventions to be followed.  Those times are gone in this day and age, allowing us to be clearer and more expressive.  

I can see using single letter counter variable names, but never could I imagine naming a class, method or function in such a sparse manner.  I like to think that clean code reads somewhat like a choose your own adventure book, were it to have a greater variety of options available.  Functional or Object Oriented is immaterial here, as cleanly written code isn’t tied to a specific construct or paradigm.  I think most of the following rules are applicable to pretty much every language out there.  Emphasis below pertains to items that I feel are not language specific guidelines.

As can be seen, most of the above are applicable to languages other than Python.  I find myself at my current place of employment having to deal with the problems for which this list addresses.  Much of what I’m doing is updating a legacy code base that is literally plagued with dozens of individual programs and modules that are blatant attacks on decent code.  They (collectively) single-handedly break most of the above guidelines.  

First off it is almost entirely written in perl, which instantly shoots down the Readability counts factor (and no, it wasn’t done with the strict pragma, and yes it uses a bunch of requires and plenty of global variables).  

Secondly, errors don’t pass silently because there is no built-in exception handling in perl.  Evals of code blocks does not equate to a proper exception system, nor does an add-in module.  Exceptions are something which need to be a core part of the design of the language, and perl falls far short of the bottom of the heap on this issue alone.  

Thirdly, when one is expected to maintain code in an environment wherein the expectation is to follow the existing coding schema as it were, with global variables, no exception handling, etc., it truly becomes a daunting task because one must force his/herself to think ‘wrong’.  The logical and/or proper solution that is naturally though of as a solution would only lead to reprimand, simply because trying to think in such a manner will produce mistakes, primarily because trained seasoned professionals don’t think in the same manner as the less experienced coder(s) responsible for the legacy code int eh first place.

Finally, (I’ll leave it to three to be nice to those few perl hackers who’ve read this far), after ten plus years of coding in perl, I’ve come to learn that the TIMTOWDI (There Is More Than One Way to Do It) mantra of perl is one of the biggest problems that arise from the language.  It is this careless and dare I say reckless mindset which has led to so many atrocities in the professional coding world.  

My point is simple enough to follow.  Write readable code, as it is a defining factor as to how far you’ve matured in the field of software development.  It doesn’t necessarily mean you are even that good at what you do, but what it does do is show how you understand a rudimentary problem that so many others have failed to realise.  Readability Counts, and without it, we are truly lost.  

Why projects fail, or more appropriately why QA cannot be an afterthought in the software cycle.

Over the years I have been in a multitude of software development environments, and bar none, the biggest reason as to why software projects fail can be overwhelmingly attributed to quality assurance.  More precisely it is either the complete and utter lack of a QA process (let alone a team), or simply the absence of sufficient testing procedures. 

Quality of software isn’t simply the fit, finish and packaging.  It is a whole encompassing methodology through which the program(s) involved are designed, revised, (when the time comes) patched, and upgraded.  It has been a long held observation of mine that coders in general don’t think of QA for several reasons.

    ◊    They feel that their programs were well designed and that they’ve accounted for all scenarios.

    ◊    The program(s) is/are too short to possibly have any error(s).

    ◊    They can be their own quality/testing department.

    ◊    They can/have figure(d) out all the necessary permutations of possible interactions that user(s) would possibly consider entering.

    ◊    There is no budget, nor push for a proper QA department and/or QA procedures.

While the above is a very, very small subset of all the possible reasons that I’ve seen/heard, the reality of it is that these are being given as actual excuses when confronted about what QA processes are in place.  The reality of it is that there are a lot of substandard, unprofessional software developers out there, who despite all the best practices of established community acknowledged developers and software engineers, continue to believe that it isn’t worth their time.

The outlook is sadly very grim from where I stand.  All too often there is considerable resistance from management, and more so from other coders when the topic of writing tests first, something we have been reminded of recently from (most notably) XP and Agile development circles.  Managers don’t want to waste time on a tight deadlined project writing code that will never make it out of the door and to the customer(s), and other coders in so many situations feel it is boring and unnecessary.  

The reality of it all is that those mentalities doom its transgressors to a endless of cycle of bug chasing and failure.  The impression that the end-user/client receives of a given software firm/group/coder is based almost entirely on the quality of their work, but there simply doesn’t seem to be the necessary forethought by those responsible to make the decisions toward quality.  

Quality isn’t simply a department which points out and/all flaws in a product, and quite frankly shouldn’t be taken as such.  Coders, particularly bad ones despise a proper quality arrangement because it points out all of their flaws without ever really providing an equal amount of praise.  Developers as a whole like to hear positive affirmation about their work.  The code produced as, such as an artists, an extension of their being, and thus hearing about problems with their work, they all too often take it personally.  They see it as an attack on their character, and that which makes them who they are.  This is something I would expect of a child, but not a professional.  

It doesn’t have to be this way.  We as a collective group of software developers, engineers and architects are the ones responsible for ensuring that quality of not an afterthought.  We have to make it a priority to build quality into ever facet of not only our software, but every facet of our varied processes.  The size of the application is immaterial.  Whether a simple shell script, or a half-billion lines of code suite, the same level of attention to quality is a pre-requisite for success.  

This includes the planning process as well.  Writing tests before actual code is produced is wonderful, and needs to always occur.  This requires discipline, which many seem to lack and/or overlook as a legitimate need.  It goes further than that though, all the way to the planning stages.  What is the point of having a high quality-focused mindset at the code level, if the project itself is lacking the same on so many other levels. 

We need to demand this mindset from the get go.  It is our responsibility to ensure that the necessary practises are put into place from the beginning, because no one else is going to care, let alone take the initiative.  If you take pride in your work, you need to ensure that it does as it is/was requested, and that requires the right methodology as well as mindset.  Not to imply that our lives depend upon this, but in reality it does.  

It isn’t as if all of this effort isn’t without reward.  We need to teach the next generation of coders to start with quality as their foundation, and it will simply become a ubiquitous piece of the process.  The benefits of this holistic view are many, and among them are:

    ◊    Stable code

    ◊    No surprises

    ◊    Happy clients

    ◊    Time to work on the next big thing (tm)

    ◊    Less stress

    ◊    Future business

    ◊    Peer appreciation

Quality is everyone’s responsibility, and that means it has to start with each individual, no exceptions.  So if you, or others which fit the bill as prescribed above have hangups on this issue, then it is time to think long and hard about it and either hangup your coding chaps, or take that next step and better yourself in your field, kicking your credentials up a notch, by having a quality centric mindset.

In future editions of the codedevl.com journal, I will be taking a more detailed look at each of the phases of the quality aspects of the software life-cycle.

It’s been a while... I’ve been busy coding away. Here’s an update.

    I’ve been rather busy recently now that our beta version of software where I am employed has made its way to production.  Since that has transpired, all of our Trac entries can be attacked in a more systematic manner.  Here’s a little rundown of what I’ve been doing.

    Handling my son’s integration into his newest school year endeavour, as well as my wife’s into hers.  She just completed her masters degree and is starting her second year (first full year) as a teacher of Biology..  to kids born the year that she and I graduated (together) from high school.

    Creating the backlog of CodeDevl.com podcasts, and editing.  I never realised exactly how much time it takes to edit a podcast recording.  For every five minutes spoken, there are ten minutes spent editing and cleaning up.

    Learning and implementing GIT version control/repository software at our place of employ, as well as my local network as a replacement for Subversion (SVN).  

    Wrote a python (base classes pure) application which handles all migration of beta software to both the GIT repository paths as well as handling moves to production (including automated changes to certain header includes).  I’m rather happy with this application as it has saved many issue from transpiring.  Due to the haphazard manner in which some of the code base is arranged (particularly the beta vs. live paths), problems can and have occurred, hence my reasons for taking the initiative to create said program.  

    Additional work with re-learning Java, and keeping current with other technologies (Python 3K/3000/3.0), Javascript, Ruby, Smalltalk concepts and to a lesser degree Lisp (not including additional emacs functionalities).

    I do promise that I will be continuing to update both this written journal as well as the podcast site, and just wanted to let those reading that I have not dropped off the face of the earth, just immersed myself back into the changing flow at my workplace.