The Importance of Being Challenged

In this most recent engineering, architecting and development endeavour which I simply refer to as my "job" or "contract", I have come to some conclusions which I feel require sharing.  I'll be very straightforward so as to not waste certain readers' time.  Many of the more seasoned lifetime coders will know (and have experienced many times over) that which I am writing about, which can be summed up as such:  If you are not being constantly challenged, you are atrophying as a developer.

I often write about my own experiences as I know them better than any single other developers experience(s).  This is not because I feel that I'm the end all be all of coders.  Far from it, I do feel that I'm good at what I do, however I prefer to look at my writings as a form of navel gazing, a self-reflective ascertaining how I can better grow in my art and profession.  It is exactly the same manner in which I'm going to proceed regarding today's message.

As I have mentioned, I have most recently jumped into a contract situation at the personal request of a rather successful life-long entrepreneur and given that the opportunity sounded rather interesting, I turned down a salaried position worth almost double because the challenge that was proposed.  Please don't get me wrong, I took a position fixing a half-assed php open-source hot or not style rating system because the employee responsible by no fault of his own necessarily, and due to a lack of a sense of urgency was unable to get a system such as that prescribed, in place by a contractual client deadline.  This was not the reason I took the contract, whilst simultaneously being precisely why I took the contract. 

I'm not a fan of php, and most definitely not a fan of a vast majority of already written php applications open source or otherwise.  What I am referring to more so is that I was brough into an environment where it wasn't the same old same old.  Now I wouldn't have stayed were the job going to continually require php specifically just out of my distaste of said language.   I did know that while I don't consider myself a web developer, I would be required on more than one occasion to work on web applications.  

These weren't to all be simple ones either, any moderately proficient web developer and non-web developer alike could figure a good many of these solutions out.   What really did it for me was that I would be required to not only work under a fairly frequent set of short deadlines due to the nature of the publishing industry as well as the time frame required to keep the site and features current.

The importance of all off these ramblings is this simple point.  Being experienced and disciplined as a Software Engineer/Developer/Architect, etc. ad nauseam helps me to know 'what' I need to do, and gives me insight as to how I might go about solving an issue.  It is however, the actual specifics which put those tidbits of understanding and knowledge into play which go outside a given comfort zone.  It is only then, when we find ourselves in unfamiliar territory, under threat of tight deadlines coupled with our own personal desires to do our best and produce code to which we are proud to associate our name.  

I know that earlier in my career there were times (albeit very few, which I can honestly say) that I too fell into this 'comfort zone'.  I found out though, that this comfort zone is boring and causes one to stagnate.  We code because we love it.  Coding and problem solving is in our blood, and in our hearts.  It is how we look at the world and as such isn't something from which we can remove ourselves.  

If you only know low-level languages, learn a high level language.  If you only work in functional programming paradigms, learn object or aspect oriented ones.  If you only work with interpreted languages, learn compiled langauges, etc.  I'm not saying give up your current lingua franca, I'm simply saying expand your horizons.  The more ways you have of looking at, describing and ultimately understanding a given problem, the more ways you have to solve said problem.  This doesn't solely benefit you, it benefits everyone for whom your code will be written and utilised. 

You knowledge needs to be a living, dynamic pool of information, not a static, never changing one and the way to ensure that is to aggressively fight off the status quo.  Be aggressive, absorb all that you can.  The best way to do this isn't by dipping your toes into the shallow end of the kiddie pool, it is accomplished by putting on your goggles and climbing that high dive, plunging in head first.  

Take a chance for once, you might just learn something.  

Till next time..

The New Django Powered Inked Magazine Website is Up!

This will be rather brief as it is more of an announcement than one of my more traditional journal entries. 

After a  short two or so months from start to finish, I have successfully setup my first Django powered website.  Inked Magazine has been relaunched effective January 2nd, 2008.  This replaces the Joomla powered site which existed prior to both myself and the current ownership of the magazine were involved in the project.  

Phase one has been completed, with extras.  The customer photo galleries, the cover photo application, the user profile system as well as the main magazine feature areas have been established and are active.  As of today, I will have available for all registered users the ability to host a blog on our site (using our software which I wrote in a few days), mind you it is still early in the feature process, though it without doubt serves most blog authors needs.  

I will be adding features as time progresses, but until mid-January 2008, I'm on a tight schedule to build the entire forum application so that the beginning of the "New and Improved" Inked Network can go live.  

I don't think one needs Ruby on Rails when you have Django.  Much of the same great functionality and without having to use Ruby all the while using Python.  [Update: After having revisited Ruby as a language on its own, sans Rails notoriety, I've found that my previous assertions regarding Rails specifically was unwarranted.  It simply took my experiences with Django and Python to make Ruby and Rails far clearer to me.]

I will return to my normal posting after the Forum application is up and running.  

Till then, keep on coding.

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 don’t particularly care for it.  I’m talking about code that unless run in absolutely perfect conditions (a.k.a. the developer’s box), 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, even more so capable, though it has its faults, 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 as I don’t feel compelled by the language as a whole.  

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.