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..

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.