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