www.codedevl.com

Theorising vs. Doing

2012-01-08T20:44:00.000-05:00

Over the past many years I've found myself slowly moving (in my personal projects) from the realm of actually implementing code about which I've been curious to spending my overwhelming majority of my free time to theorising about various concepts and/or interests, primarily in the field of human language parsing, simulation and simplification of generic real-world object modelling. Several of these have been mentioned and explored in previous posts over the last 7 years.

I believe a great reason for this change in focus is partially age, and primarily due to the extent that my days are focused on building the next great startup application. We recently (as of the New Year) pushed the past eleven months worth of work into existence as our new primary (Python/Django) product replacing the previous multiple iterations of our legacy (Java) product. The focus and scope of the project limited my ability to go off on tangents wherein I could code my personal projects freely. This was by no legal hand binding, it was simply a matter of wanting to focus my writing to building our product to the level it needs to be, to the high standards we require (and rightfully so).

This leave one (me, namely) with little actual time to thunk down in front of my primary workstation to commit theory to codebase, hence I've found myself working it out on handheld whiteboards, sketchpads, napkins, chalk on the ground whilst playing with my daughter or even simply working these theories out in my head. While I would like in many cases to put my thoughts into actual runnable logic, I've found that the exercise of stepping through theoretical code in my mind has kept me sharper regarding my thought processes. True, I cannot share this as easily with friends afar, but given that many of my personal friends are also senior level engineers, discussing (when we do) casually my theories and ideas, they get the gist quickly.

The point I'm trying to get across here is that while today is perceived as one wherein a bunch of 20 year olds either in or fresh-out-of college spend an obscene amount of hours in incubators or at startups killing themselves churning out ridiculous amounts of code, there is most definitely no slow down in the thinking processes of the more senior of us out there. We just don't find a necessity it raw churning out of code as it is the concepts that drive the field and aid in future innovation. Let those who wish to "do" continue to run their path, but lets not overlook the value of those who've moved their focus (whether by situation or by intention) to the more abstract realm of theory as the two are inextricably bound. We need ensure that these two distinct groups of people are in contact with one another because it will ultimately lead to the newer advances, bettering our field for all involved.

New environments (mentally) as it were... (a.k.a. something old, something new)

2011-03-24T08:41:00.000-04:00

Since my last update made a little over a month and a half ago, much has changed. I've accepted a position as Lead Software Engineer for Yorn, LLC located in Conshohocken, PA. I haven't abandoned my prior position with the publishing house in NYC, merely time-shifted those hours elsewhere. Taking this new venture (on top of my previous work, plus the other tech-startup of which I'm a co-founder, Ecquire has proven to be a necessity for my sanity.

Working primarily for the past many years as the sole Software Engineer for a half dozen magazines in a Django/Python/Javascript/CSS/HTML/FreeBSD Unix environment whilst also wearing the SysAdmin hat has been... draining. This wasn't due to having nothing to do, this was more to do with having very little room for innovation as the end product wasn't the new SaaS website or Outlook plugin, it was simply repetition with the only real variances being that as dictated by wet-behind the ears designers and graphic artists whose concerns about a given site was more about look than UX. Don't get me wrong, some of the designs have been gorgeous, but not without the pendantic whining common with individuals who only knowing Adobe Photoshop aren't happy when you explain to them that there is a different methodology at work in producing like-layouts im a web framework.

Either way, back on topic. I feel for the first time in quite a while that not only am I solving real problems that pertain to a large scale of individuals and companies (as opposed to readership by fashion and/or tattooing enthusiasts) but I am finally in a position in which I have a cohort in crime, a partner, a colleague. Best of all, he's brilliant. A proper individual for the field, something when I've been trying to find for ages. A PhD in computer science and a quarter century in the field along with all of the traditionally odd hobbies and sense of humour found more commonly in those with very intellectual professions. Even though we've only met face to face on three occasions, we've shared many phone calls and Skype sessions whilst working out our designs and product development and it has simply been a breath of fresh air for me. I have someone off of whom I can bounce complex ideas knowing full well that I'm understood, as well as presenting me the opportunity to expand my own learning horizons.

Excitement stirs ones involvement in a given project and considering that this is what has (and is) happening to me, it is paying off in not only a clearer mind and what I believe are more robust ideas emminating from my thoughts but it has reduced my stress allowing me to be more productive all around whether in the publishing work, my own startup and more importantly in my family life. It all comes back to ensuring that whatever one does, they need to sometimes step of a comfort zone in pursuit of that which provides incentive and drive in ones given interests and/or profession(s). I was too conservative earlier on in my professional career and I believe I would've benefited greatly had I stepped out of my cocoon years earlier rather than (as most introverted engineering types do) not think highly enough of myself to be worth more than an abysmal income and working environments to which I was subjected for over seven years.

Times have changed and the future is looking brighter and brighter. Ecquire & Yorn have paved the way to a better future. I stepped past my initial nervous/worried leanings and jumped into the world of proper tech startups finding that the grass truly has shown to indeed be greener on the other side. Now, onto another exciting and challenging day of practising my craft.

2011 and my prospects...

2011-02-03T14:35:00.001-05:00

Having recently entered the new year, I find it fitting to share some recent happenings and thoughts on how they might apply to not only my situation but those of others with a penchant for software engineering and/or administrative careers.

The past year has been one of making connections. I have met some great people including several combinations of Angel Investors, Venture Capitalists, Software Engineers and Computer Scientists. My experiences with our startup, Ecquire (http://www.ecquire.com) has proven quite enlightening as well as fun. In fact it was through my co-founders I was introduced to so many others in the field, such as Rick Rasansky and Trip Denton of Yorn (yorn.com), and Gabriel Weinberg of the amazing search engine DuckDuckGo (duckduckgo.com) which protects our privacy.

What I have come to realise is that while I have been working with software behind the scenes of a considerable number of websites on their various frameworks, the technology doesn't challenge me and has proven to be quite repetitive. There are still some challenges, but there is far more aesthetic issues than technical ingenuity involved. The issue of technical seclusion is also an issue at hand. With my primary client for whom I have a special relationship due to past employment in the earlier half of the previous decade, there is a loneliness on two levels.

The first being that I am not only the only Software Engineer, but the only technical person period. I wear many hats including CTO and Systems admin. I handle all technical contracts for servers and what not, at least related to any only presence. I'm more than capable of handling these roles though it can be rather isolated and not because I'm physically in a different location.

Which leads me to the second reason, that being one of no technical peers with whom I can discuss, debate and/or share views on projects. The owner of the various entities is more understand on technical issues that many with whom I've dealt over the years but there are still limitations of understanding. Again, I do highly commend him for intelligence, trust and understanding though there are limits of which no one other than a peer would quite grasp simply because it is something that needs to be experienced for commiserating to be legitimate.

As a means of striving for more in not only personal life, but my professional one as the combination of both affect my happiness and general stress levels, I've been partaking a re-design/porting job with a technical group which is more up my alley. I am still delivering the service and quality to which I have committed myself with my primary clientele, let that be stated for the record. It is just that I need this to keep my mind from atrophying. I need to be challenged in my field, not to mention be given the opportunity to innovate without having to wear every hat and focus so much on outward aesthetics. I like beautiful design and beautiful code, much so less visuals as that is truly the realm of designers.

Where I'm coming to for the sake of others is the following: Push to keep yourself challenged and happy in your field. For a long time we allow ourselves (especially as we have more people depending upon us in our personal lives such as our families) to become complacent with the idea of security and daily consistencies in our work. The problem with this is that we start to stress over the rut in which we find ourselves. We internalise the urge to snap at others when for the millionth time (exaggeration of course) we painfully banal question or task is asked of us. Though inside, we die just a little bit more each time, in spirit at least.

The solution (or at least one solution) is to not let fear or complacency hold a firm grasp on us. It is one thing to allow for short term bursts of such ideals for the sake of a greater good but to allow it to trap us long term in what is almost definitely a downward spiral is unbecoming of our abilities and intelligences both as individuals and collectively as the technical backbone of our industries respectively. Push to find new challenges and if they are drying up as a lake in a newfound desert, look elsewhere over the horizon as our abilities only go so far when our outlook and prospects of change seemingly whither into nothingness which ultimately leave us a shell of our former glorious selves.

I'm not taking this new year lying down. I'm feeling reinvigorated with new purpose, prospects and challenges not only for the betterment of my familial situation but for my peace of mind now and into the foreseeable future. I wish the same to all of you whom finding yourself in a similar situation might find my words useful and/or inspirational.

Romanticisation, Research & Reality

2010-09-27T00:37:00.000-04:00

As I've now hit that point in my mid-late 30's, I've had some internal conflicts recently see resolution. This won't be one my traditionally long winded/verbose entries, though it won't be short enough for a micro-blog post either but here it goes...

Over roughly the past two decades I've been torn by issue of not attending university, especially one such as MIT, Stanford, Virginia Tech or UC Berkeley in pursuit of a Masters/PhD in computer science. I feel that I missed out on the social aspect (aside from the excellent environment for furthering myself in a group setting in my field of interest/passion/expertise. This is simply a recurring romanticised view I have over my regret. I only envision the good parts, not the tedious drawn out study periods, the painfully boring pre-requisite programs/classes and lecture in mundane subjects solely to satisfy the higher education machine. I am an autodidact and a fairly effective one at that. University would have most likely quickly become the bane of my existence. I experimented with higher education and within the first semester found the pace horribly slow and in the case of required classes, a horrible waste of my time and money (I paid the tuition with my own cold hard cash). I opted to leave before wasting any additional money and simply continue to do what I had always done, educate myself for a variety or sources, as well as getting my hands dirty in my field of interest (amongst others for well-roundedness).

This brings me to one of the reasons which fed the romanticised ideal as prescribed in the previous paragraph(s); my research in the field of immersive virtual environments. I have spent a considerable amount of time since my childhood in the areas of researching virtual environment simulations (e.g. simulations of real-world objects and scenarios). This could entail human interaction with every day objects to be used for gaming or habit studies or to simulate atoms at the molecular level or even the macroscopic planets, interstellar bodies and galaxies in our and other places of the universe. This is the kind of research which would have either lent itself towards achievement of my PhD or conversely, the focus of my post-doctoral research under a grant.

Finally, the reality (hint: it isn't all that bad). Working in an academic environment in professorial/research dual/split roles would've been a wonderful way to go, though it wouldn't allow me the flexibility I currently have in terms of working from my home whilst raising a toddler, and being home for my elementary school aged child as well. Do I get funding to pay for my personal pursuit/continuance researching simulations and their many facets? No. Do I have a surplus of time to allow me to pursue said interests after my family and work related endeavours are satisfied? Not much at this point in time. Do I feel that the overall balance of what could have been versus what truly is and what still may come my way is reasonable, fair and not worth feelings of regret? Yes. I'm rather happy with where I am as a Software Engineer for the past 15+ years and while I'd still love grant money to further fund my research, I can't say that I don't enjoy some of the daily challenges of my already existing present-time workload.

Just because we might find ourselves in a situation that isn't exactly as we'd initially thought we would want doesn't mean that there aren't equivalent outcomes that still satisfy our initial hopes and aspirations. I suggest that those of you who have dealt with the aforementioned conundrum, take a good long look at how you might still achieve the equivalent that fits best into your existing life plan and stop worrying so much about such exactness in realisation of ones dreams, otherwise they might never materialise in any recognisable form.

The Usefulness & Addictive Nature of Multiple Displays

2010-08-13T00:27:00.001-04:00

It seems to be a divisive issue when dealing with developers, engineers and programmers alike... The usefulness or annoyance of multiple displays. Recently having upgraded to my fifth display, I felt it was about time that I weigh in on the issue/share my opinions.

Five displays : One 1920x1080, Two 1920x1200, One 1280x1024 and One 480x800 :: 8.4 Mega Pixels in All

Back in 2001 at an interview with Health Market Science in Conshohocken, PA (now in King of Prussia, PA I believe), I had witnessed a key benefit of new up and coming startups for their developers... multiple displays for each workstation/desktop. Flash forward a few more years and one Mac Book Pro later and I find that ever company at which I would work, I would attach a secondary display so as to provide more desktop real estate. Whether this was to provide a shell or two in which to run emacs while accessing a db frontend or browser preview window, it proved beneficial in terms of productivity with less switching between screens, windows and what not.

Ever since my first exposure to such setups (which were astronomical in price to setup back in the 90's and the beginning of the newest millennium), I was rather enamoured by them. Now in 2010 I find myself working not on laptops, but full blown 64 bit Unix workstations. A major benefit of such setups is the ability to run a considerable number of graphic cards and their associated displays. Some wonder what could I possibly have running that dictates so many displays.

I personally like to keep a web browser open at all times so using the picture above, I will explain as best as possible. So, as I was stating in the previous line, the left most display is running a full height copy of Google Chrome, flanked by three separate terminal windows running a mix of local and remote shells on various servers. The middle large display is running my current favourite IDE for python development in fullscreen (in this case, NetBeans 6.8). The right hand most screen is used for additional remote shells used more so for large rsync'ing and process monitoring. The upper left screen (a great displaylink/USB powered 480x800 (or 800x480) from Mimo) is used for Skype & Adium (and both are pinned to all spaces/virtual desktops due to content), and the upper rightmost monitor is a free for all to display whatever is needed in addition to all of the aforementioned items (pdf viewing, techtalk viewing, the occasional movie, db schemas or gui, etc.).

The biggest issue I currently have with the setup is physical layout. A table roughly 144 cm (60 in) wide can only handle three widescreen displays (between 23" & 24" diagonally) when in a concave configuration. Having to position the additional displays above the lower displays does cause the occasional confusion regarding pointer location. A better layout would be an array of identical displays, preferably with VESA mounts in a 5 wide portrait layout or a two rows of three in landscape layout.

I highly recommend that others who haven't had the opportunity to work in multiple display setups to try it out as soon as possible. Those simple keyboard shortcuts used to swap from window to window and/or virtual desktop to other virtual desktop do take up time and can interrupt one's flow. Is it really worth it when displays are so cheap these days?

Caveat emptor: The use of multiple displays causes varying ranges of discomfort when penned/cornered/shackled into a single screen machine, not to mention there is desire to acquire more screens after getting acclimated to the first addition, second addition, etc.

Till next time...

The Romanticism of Internet Startups. My experiences, part I.

2010-04-16T23:34:00.000-04:00

I wasn't sure what drove me to this point, that of writing about startups (of all things). I believe it has much to do with the recent launch of the newest startup of which I am a founder as well as the Software Engineer behind the technology in said venture, Ecquire. In the past months during which the project has progressed to our recent launch at the end of March, my own fascination with startups and my own experience in dealing with them came back into focus.

Back during the dot com boom in 2000, I was starting my 6th year as the lead developer for a manufacturing firm in Philadelphia, Pennsylvania. The realisation that I was growing rather weary at what I felt would become a dead end job well below my desires and capabilities would later come true for the individual(s) that came later to replace me once I'd left. I recently found out via a visit, the software I had authored in the 20th century for said company is still being utilised during every one of their 6 production days a week, year round. I figured authoring a critical application that as been running for over 10 years a full production environment without failure is one point of pride I happily take away from that point in my professional career.

Moving on, both with this post and what I was getting at after all of those years at what was becoming a job with no real future, unless I wanted a full frontal lobotomy. I started to look around at my potential opportunities and having at the time been rather conservative in the kinds of companies in which I would allow myself to envision employment, only one of which I was aware of it being a startup. I had interviewed in a new industry as an attempt at something new with a company at the time located in a new office complex in Conshohocken, Pennsylvania, called Health+Market+Science. It was the epitome of dot com culture from the very casual attire, dual flat screens (15"-17"ers at the time) to the fully stocked kitchen with both Mountain Dew and Jolt colas and of course the obligatory ridiculous hours kept by the early twenty-somethings.

I ended up not taking that job as the hours just weren't conducive to me, having been married with a home to which I preferred to return to during daylight hours. I did however find myself in an awkward situation as a friend happened to be working for a financial startup as a contractor and try as he may, they never offered him a salaried position. After suggesting the position for which I interviewed to him, he found it a more compatible match both in terms of age range, distance from his rented home and preferred environment. He gave appropriate notice at his soon-to-be-former contract and suggested to the CTO to have me in for an interview. To make a really long story short, I interviewed and was offered a full time position at a considerable increase over my previous place of employ for the prior seven years.

The new environment was definitely a relief from the previous mid-size company dynamic, though it didn't come without its own oddities and personalities. The projects cam quickly and were fairly varied. Our niche in the market and in terms of financial companies was breaking new ground in an area of the industry that was too new to have many established competitors or applications which could simply be purchased and utilised for daily goings on. The environment code wise was simple, replace the existing PHP documents with something better, and at that time and in that case, perl was the solution.

I'm not going into the whole rundown of the years at the company and its daily goings on however I was state that true to its nature we worked some late evenings, the odd weekend and had a blast all the while. It ultimately changed as the company grew and due to certain situations with some of the legacy code's lack of efficiency with our increased activity (i.e. it wasn't scaling), my boss (the CTO) was removed and I took his place. It would be several more years that I would be at this company which would end six months after the new owners completely destroyed the client relationships and staff morale. I ended with the obligatory hire-a-thug escorting me from the facility (though I am a considerably larger individual and therefore felt no threat), and a decent severance package. The new CEO hated me from day one because while promising to continue to provide the high quality of work my team and I output on a regular basis, I also made it clear that we were not 'yes men', nor would I or any of my team kiss anyones ass because of self-imposed importance via titles or roles. You earned respect, you never gained it by your business card or past. He was never understanding of that mindset and as such I was given a nice severance pay while other people were just thrown to the street.

Ultimately my first foray into an internet based startup was a fun adventure that definitely provided lots of learning opportunities and allowed me the environment to grow and expand my comfort zone. All in all, I wasn't unemployed for more than thirty or so minutes as on my way away from the office on that fateful friday afternoon for the last time, I made a phone call and found myself employed starting the upcoming week... at another startup. More about that in another post!

What's In Your Dead-Tree-Format Library?

2010-03-19T01:42:00.001-04:00

Whilst cleaning and reorganising my home office, I came to the realisation that I have accumulated quite a decent amount of books on the various topics in my trade & hobby, software engineering. After placing my various titles properly in groups on the shelves, I took a photo and it is shown below. What follows is a breakdown on each book, my thoughts and the source of how it was attained (where remembered/applicable). Note: Not included are three books currently in transit via Amazon. One is on ajax, and two are FreeBSD server administration related.

Top shelf first, going left to right:

The Linux Database Bible :: This was a $50.00 book received as a freebie when I attended Linuxworld 2002 at the Jacob Javits Center in NYC. I can't say that I've used this book much for anything other than the occasional reading fodder when nothing else was within reach. I'm sure it would be of more use to newbies to both Linux and databases, even now.

Python Essential Reference, 2nd Edition :: I picked this up back in 2003 whilst doing work for a financial company at which I was both senior developer as well as newly appointed (reluctant) CTO. This is a David Beazley book, and I highly recommend any version of it (there are several newer than my copy) as he is clearly full of expert level knowledge on all things Pythonic.

Python Cookbook :: This was another 2003 or 2004 purchase mainly out of curiosity to see what crafty, yet elegant solutions other Pythonistas has designed and/or implemented. Definitely a wealth of information on a multitude of topics be it recursively traversing b trees or working with simple CSV files.

Python Pocket Reference :: A simple reference mostly useful for the "batteries included" libraries.

Python Programming Patterns :: This book has shown me why we generally don't rely heavily upon patterns such as those overly used in Java software. I purchased this along with the Python Cookbook, and quite frankly if I had only acquired this book, my disappointment would have be far greater as I would've had nothing to take my mind off of it.

Perl to Python Migration :: Picked this up at the Micro Center in St. Davids, PA in the early 2000's when I started to migrate some of our perl applications over to Python in the financial world. Highly recommended, especially for heavy, long-term perl hackers.

Pro Django :: Picked this up in early 2009 as further reference and idea material for the 4 websites I write and maintain for a series of internationally published magazines. I'm torn on the value of this book, but at least it goes beyond beginner level.

The Definitive Guide to Django, 1st Edition :: Purchased as a reference as soon as it came out, references version .96 of the framework, so if a person is using v1.xx or higher, there are going to be quite a few caveats in the examples, otherwise a wonderful reference, especially when it comes to the appendices.

Practical Django Projects :: A bit of a disappointment as it focuses on blog creation for which a series of examples of this ilk already can be found online for free, not to mention in the Pinax project.

PHP and MySQL Web Development :: I just received this book from a business partner and whist I generally avoid PHP like the plague, I am glad to have references which are a bit more current these days for when I do need to venture into such environments.

Setting up LAMP :: Same as above.

PHP Solutions :: Ditto for this book as well.

Pro Drupal Development :: ibid on this one too. I don't think I'll ever end up using Drupal, but at least I have a reference if I ever need tit.

Programming PHP :: I inherited this from the previous CTO at the financial firm at which I worked back in 2002/2003 and it has served me well as a reference book.

PHP Pocket Reference :: This also was provided to me with the Programming PHP book.

Programming Ruby, 1st Edition :: The Pick Axe book as it is more fondly referenced by Rubyists. I picked this book up in 2007 so as to further my own understanding of perl's successor. I was, in fact, reading it early this evening, though I still find it considerably less useful professionally for me than Python and other solutions.

Programmers at Work, 1st Edition :: This was left to me by a business associate from Ecquire prior to relocated elsewhere. It is the predecessor of "Coder's at Work", and contains some early Apple, Microsoft, Adobe, Xerox and HP developers and views on the industry.

HTML 3 :: Truth be told, this was bequeathed to me by the surviving relatives of my ex-wife when her younger brother died in an untimely manner. It is rather outdated, though kept solely as a remembrance of a young life that had potential in several areas of his life.

The Pragmatic Programmer :: I might not like a lot of the most recently branched out Pragmatic series be it books or podcasts, but this book is gold in my eyes. I made this a company purchased, required reading for all developers from Junior to Senior level everywhere I've worked. It most recently was recommended to an Intern I mentored during the 2009 summer season. It has also proven valuable to other associates, even those not directly involved in the Software Engineering field(s).

OOP Demystified :: I purchased this book as a means of helping to teach others the basics of Object Oriented Programming. It is a rather basic book, and uses the transitional OOP examples cases of registering for a class and doing payroll, like umpteen other books on the topic.

Middle shelf second, again from left to right:

Open Source Development with CVS :: Picked this book up on an departmental outing back in 2000 when moving into the Lead Developer role at a Manufacturing company which didnt have an existing source control system in place, and it wasn't yet time to use Subversion and the company was too cheap to acquire Perforce licensing.

Practical C Programming :: Every developer has at least one reference book for C, many have more. I'm not a big C guy myself, though I find this O'Reilly reference book a wonderful additional to any library, maybe short of the K&R tome.

Teach Yourself C++ :: This book by Al Stevens was something I'd picked up as the desire to torture myself with C++ a.k.a. Bjarne's plague upon the coding world. I sooner should've picked up a book on Smalltalk or Objective-C. Note, the book is written well, my comments are mainly aimed at the abomination which is C++.

Learning Java :: I didn't buy this book as a Java reference in as much as I did for its first four chapters, which by and far the single best example laden object oriented chapters of any book, bar none. Oh, and they are quite humorous as well.

Head First Java :: When recently wanting to get back into the Java world a bit more than in the past (with my playful experimenting), this was ordered on the recommendation of a good long term friend of mine, himself a Senior Software Engineer focused heavily in Java environments.

Java in a Nutshell :: Standard fare O'Reilly reference book, though drier than others and while laid out clearly, something felt amiss.

Core Java :: Sun's own sanctioned Java tome. Massive, and packed full of information (and for the price is had to be). Heavy examples on applets and AWT, which as of this writing is a decade out of date. Makes a great bookend due to its size.

Java2 : A Beginner's Guide :: Probably one of the nicest Java2 introductory manuals. This one has been loaned out to newbies to Java more than any other Java book in my library. Clearly written and never dull.

Javascript, The Missing Manual :: Recently purchased and while full of information spends too much effort on jQuery, so much to the point that the book might've been more aptly named "jQuery", and subtitled "with a chapter or two on non-jQuery javascript".

Linux Programming :: Also bequeathed by my ex-wife's famliy.

Linux in 10 Minutes :: ibid. See above.

Turbo Pascal, 3rd Edition :: Pascal, while originally a teaching language is also an imperative, procedural language good for systems programming much like C and only slighly slower. Having moved to Pascal from various versions of Basic and ML, I was happy to take this off of my wife's friend after he completed his Pascal course at university. The section on algorithms is still one which I reference routinely, hence the reason isn't packed away in a box.

Perl 5 Programmer's Reference :: A $4.99 special at a Banes & Noble in Abington, PA back in 2001. Only covered version 5.004 of perl, but was so well laid out that it beat anything that O'Reilly could muster for perl references. Quite possibly out of circulation/print as of this article's writing.

Learning Perl Object, References and Modules :: Essential reading for any non-purely functional code to get written when subjected to perl environments.

Programming with CGI.pm :: Nothing says well engineered than written by an engineer at Jet Propulsion Laboratories.

Programming the Perl DBI :: Anyone doing anything with databases in perl, will benfit from this thin yes most definitely useful book.

Perl Best Practices :: I pick this up after reviewing another copy at an Internet Hosting firm for which I did someork..

Object Oriented Perl :: Damien Conway's opus for Perl and Object Orientation. Explains limitations and information for making robust Django.

Practical PostgreSQL :: Acquired when the original plans for some of my publishers dontnet

Bottom shelf lastly, contains my spoken language reference library which contains books on:

Dutch, French, Japanese, Welsh, German, Korean, Russian and Spanish. The majority being in Dutch including several novels and grammer books, followed in a distant second by Welsh grammar books (mostly picked up in Waterstones in London surprisingly), then in a close third, Japanese. I like languages and I do not limit myself to simply one or two. Anyone who follows looks at the list of people whom I follow on twitter will easily see all of the above languages utilised, sans Welsh (quick, somebody contact Alan Cox!).

Bonus: Some of my die-cast cars including my highly favoured Peugeot 206 WRC model that I picked up for £2.99 at Hamley's in London back in '03. I collect the occasional model car here and there, mainly German, French, English and Italian based, but that is fodder for another blog.

The Greying of an Engineer

2010-03-09T23:59:00.001-05:00

My birthday is upon me once again, this time in 11 minutes from the time that I compose this brief entry. As I contemplate what the next year holds for me I find myself having certain realisations floating around my head. I will attempt to share these with little fanfare and leave interpretations to the reader.

1. Throughout my entire life thus far, one item has remained a constant: I love to design software and have since I was in the single digit age range.

2. The reason I'm not a horribly rich coder is simply because my goal has never been that of becoming rich, whereas it has been that of writing great code.

3. There are is a lot of talent out there, but it has nothing to do with youth vs. older coders.

4. New methodologies come and go all of the time. Functional vs. Object Oriented paradigms, Low Level vs. High Level languages, Waterfall vs. Agile development. All are capable, all can be utilised in effective manners, it simply comes down to competence and compatibility of those involved.

5. You can teach an old dog new tricks, though after having learned said new trick(s), one might still prefer the original. (e.g. I think that jQuery is a wonderful invention, but don't expect me to use it as I feel it isn't explicitly clear. I'll take document.getElementById('idname') anyday over perl/rubyesque tokens.

Given that my goal was to post this before my birthday comes, I'm ending it abruptly here. Till my next post.. -Eric

You kids get off my lawn! (oh, and the Apple iPad)

2010-01-28T23:19:00.007-05:00

Lately I've been rather busy with work, primarily my main client as well as with the newer work I've been doing with a soon-to-be unveiled startup of which I'm a partner. Our product is launching by the end of the first quarter 2010 and I will be sure to update the site with all the details.

What is really on my mind lately is the annoyances I've been feeling more and more lately regarding what I feel is a loss of substance in the field of computing, interfaces and the sector of artificial intelligence research. Though just recently with the launch of the newly unveiled Apple iPad did I start to feel some alleviation. I will address several of the aforementioned items, but will leave the AI discussion for another post as it will be a lengthy one at best.

Firstly, as 2010 has rolled upon us I started reflecting on how it must be for kids these days and their constant exposure to computers. Primarily how difficult it must be for future programmers and software engineers to get started programming on machines so complex with operating systems so complex that to do even the simplest task requires learning what potentially are complex API's. When I was starting out with computers back in 1979-1980 one could buy a computer (which came with at least BASIC) as well as general instruction books explaining how to program in said language. Within 15-30 minutes any kid would be able to draw bitmapped graphics on screen and possibly even animate and/or add sound as well.

Given that the machine in question on which I first started (a 16-bit machine no less), the TI-994/a, was a 1.067mHz speed daemon, there is much to be said for its overall capabilities. This blog post is larger in size than that machine had RAM (a whole 16k's worth). So, it is true that with all of the amazing capabilities and speed of our newer machines (such as my primary machine with its 8 hyperthreaded cores over two physical quad-core Nehalem Xeon's and 6gb of RAM (of a possible 64gb)) it would be expected. Still, something is lost in the overall simplicity.

Furthermore, my recent curmudgeonly slanted mindset spread to thoughts about how access for all destroyed the quality of the average computer user, especially those networked users (which nowadays includes virtually everyone). When I first started online, there was no AOL, there was no web, there was the internet, but it was limited to Academia, Science Research facilities and the Government. We had modems primarily running at 110/300/440 and later 1200 baud and up. We had acoustic coupler RS232 interfaces (they while novel, are not something which I find myself longing for once again) and we were happy as can be. We knew that getting online and/or running into other computer programmers/enthusiasts (they were usually one in the same back in the day) would lead to interesting conversations/exchanges of a higher intellectual level as opposed to nowadays where the overwhelming majority of computer users are simply that, users who couldn't code their way out of a cardboard box.

Enter the Apple iPad. A machine designed for everyone BUT programmers/software engineers & developers. It provides the mundanes with the functionality to go on about their daily online existences and I'm truly hoping that such devices as this catch on. I hope that items such as this replace the majority of those users' computers. This would give us a kind of return back to the day when the technorati and intellectually gifted were the only ones with machines capable of creating new software. It will help like minded people easily be able to pick out those of similar ilk simply by their possessing an actual computer.

Now I realise that there are people complaining about the iPad specifically those under the spell of Stallman (RMS) and his free software foundation but it is time for them to be grown ups about the situation. If someone creates software, it is their right to keep the source closed, just as it is Stallman's right not to run it on his machine(s). He can be an idealist with cramming such a non-sensical mindset on everyone. Most people really could care less because there are those sources which provide for the applications people want and use, and have no desire (or capability) to modify them anyway, hence the iPad and future devices of similar type are perfect as end users are consumers of the fruits borne of software engineers, not producers of such software.

Now I realise that as usual, I'm diverging from my original topic by going off on a mildly related tangent, so i'll wrap this up by simply stating that it is my hope that with the newer type of device designed solely for the everyday user that we will see a reduction in actual programmable computer sales indicative of a clear divide between producers and consumers once again making a clear distinction between those with the mental prowess and logic abilities/desire to create software and utilise machines to their fullest, and those who are simply consumers of said labour.

Thoughts?

PyCon 2010

2009-09-30T23:39:00.002-04:00

I just made my submission to give a 30 minute talk at PyCon (US) 2010 in late February of the upcoming year. I was contacted by PyCon staff with the suggestion that I present a talk sharing my various Python based experiences at various places of employ. I made sure to get the submission in earlier this evening before the ability to do so was shutdown as the window for submisions closed for the 2010 event. Now I must wait until sometime in November to hear as to whether or not I'll be presenting. I will keep everyone posted either way.

Update to Post Regarding Hacking & Ruby

2009-08-28T02:08:00.005-04:00

This will be a very short entry as it is rather late and I'm looking forward to sleep. I would do but I do feel that I have to get some observations off of my chest after the past 6 hours of exploring ruby (for the third time).

#1. Ruby isn't as intuitive as one might suspect. Maybe python and others of similar influence (groovy) have raised the bar too high in terms of dynamic language syntax and expectations. The standard ruby idioms are inconsistent and ill-named in several cases, mostly involving native data sets.

#2. Namespaces in Ruby are an even bigger mess than perl. To some degree, perl's system seemed to make sense yet from what I've read, seen and with which I experimented, I find the namespace setup for Ruby to be subpar and dare I saw far from fluid in implementation details.

#3. Ruby is indeed very slow, especially when working with the Array types in combination with large datasets and continual pre-requisite 'include?' method calls for each datum in said set. I did find that I was able to achieve the same results wanted via Hash population followed by a dump of keys to an Array with a noticable speedup, removing the need for the very slow 'include?' method. Membership tests are a joy of high level languages, but a drain on some resources, ruby more than others though without a doubt.

#4. The novelty of mutable and immutable version of method calls (collect! vs. collect, slice! vs. slice) is just that. A novelty. This is an ambiguity which I believe does not help to further ease of readability and usability. It further necessitates that non-standard library code implement similar idioms and 'practices' for uniformity's sake with the downside being a snowball effect in this area.

#5. Ruby isn't sure if it wants to be perl, c, smalltalk or itself as can be determined by the mix and match of terms, keywords and standard method names. It doesn't feel like a concrete language that was purpose built, but more like an object system with various sources for tacking on the remaining pieces of the language so as to round out the feature range.

These experiences with Ruby (for the third time) may have been different had I not been spoiled by Python (most notably), or were I not coding in the field for the past 15 years. This is not the case nonetheless. I couldn't see myself coding in this language for anything mission critical or heavy duty and after looking at the problems many of the ruby back-ended software systems and/or websites vs. the other high-level dynamic languages have suffered, it becomes quite clear when industry giants such as Google and IBM throw their weight behind Python.

This isn't meant to be an argument starting post about Ruby vs. Python as they can be found elsewhere, though if the shoe fits...

Ruby & Project Realisations

2009-08-26T00:18:00.004-04:00

This isn't going to be a long post as it is rather late in the evening (morning) and not only am I trying to rest my leg (hyperextended my knee playing football (soccer for the Americans out there) on Monday evening), but I'm also in need of greater amounts of sleep having a four month old daughter for whom I am the primary care giver starting tomorrow given that my wife works in the academic world.

Short and to the point (for me at least) is that I'm delving back into Ruby (for the third time chronologically), but for the second time on a 'serious' level (i.e. with the intent to actually produce usable code and not simply proof-of-concept understanding code). I'm realising that while I love python which has been part of my daily work for the past five plus years, moreso Django/python in the past two, that it is becoming my 'Java/C#' if you will. By that I mean that it is my work language. It is a clean and elegant language which allows me to focus on getting what I wish completed, completed with minimal fuss and easy maintainability due to its explicit albeit brief and neatly aligned syntax. I feel though that something is missing.

If I can go back a little (and long time readers from previous versions of this blog circa 2002-2006 would remember me discussing this before) and bring up what eventually became my professional lingua of frustration: perl. Larry Wall's masterpiece which I utilised professionally from as far back as 1995 albeit I was working with rexx and pascal(!) more so then. I used perl and was attracted to it because of its expressive hacker roots, but was eventually disgusted by the lack of a decent enforceable object model for doing any kind of OOP work, not to mention maintainability was not its strong suit regardless of how meticulous one might be as a software engineer/coder, etc. This is what ultimately lead me to look at ruby but only briefly as it had residual taste of perl all over it. I found python shortly thereafter and have been happy ever since, until recently.

Sure I've looked and learned other languages in the meantime (as well as used them for personal and professional purposes), but just for the past three weeks or so I've realised that some of python's strong suit do indeed take some of the more guttural joy out of hacking out code. In my line of work I find formality and structure do wonders at getting solid code and meeting my clients' needs, which is the whole point. I'm at the point professionally where I don't get calls or emails saying that "something broke". It is much akin to Apple computers. Things just work without fail, as should be expected.

This ties into my other piece of the recent puzzle. I'm doing web framework design and implementation (amongst other custom software components) for primarily lifestyle, art and fashion magazines. It does pay the bills and it is at least involved with a creative branch of what can be a boring industry (publishing), though I find myself pining for more intellectually/scientific/theoretical research based projects/content. This isn't going to be happening anytime soon where I'm currently spending my efforts (professionally as it were). I have no design to stop doing what I'm doing and for whom I'm doing said work. I enjoy the relationship I have with my clients and there isn't anything wrong there. I'm being kept busy with new work so that's nothing about which to complain.

What I am looking to do is start working on some more experimental/theoretical designs and codebases/classes/packages in Ruby so that I can further explore the language and enjoy the more 'hack' mindedness which I find comes with such an expressive language. I will most definitely share my results with all the CodeDEVL readership (as well as podcast subscribers). I may even post a screen-cast soon as my copy of Snow Leopard for my Octo-Mac Pro (8-Core) should be here on Friday and includes new screen-cast capturing built-in to Quicktime X.

If anyone is in the Doylestown region of Pennsylvania and would like to meet up to talk code, please drop me a line. My email is simply 'eric' at this domain (assuming you're not reading this from the source blogger domain but the domain for which the header image at the top of the page states clearly.

I'll keep everyone informed. Until next time..

-Eric

New Development Machine Ordered

2009-07-25T22:39:00.003-04:00

After years of working primarily on laptops, I finally decided that it was time to move to a desktop. A brief history is in order so as to show the road travelled (for posterity). All machines were purchased new and the prices include necessary manufacturers extended warranties, etc.

April 2002 : Whilst getting prepared for an upwardly vertical move in my field after working at Alliance Remanufacturing as their Lead Software Developer for internal applications for the production, procurement, quality assurance and management divisions, I purchased an Apple 14" iBook G3 @ 700 MHz w/768 MB of memory for $2,500. This unfortunately was plagued with a flaky motherboard (logic board) issue causing video issues. The machine had 4 logic boards in 3 years under full warranty. I learned the value of AppleCare very quickly, as well as the quality and speed of Apple's customer service.

June 2005 : At this time I was working for Payment Processing Center, LLC writing cheque/bank draft processing backend software as well as managing a real time financial reporting web portal. The logic board in the iBook G3 gave up its ghost yet again and now being out of warranty, it wasn't worth fixing. The replacement came in the form of an Apple 12" iBook G4 @ 1.2 GHz w/1.25 GB of memory for approximately $1,550.

February 2006 : Due to a Federal Raid (later proven to be due to certain clientele and not my place of employ nor its directors), the iBook G4 was seized by the Federal Government for a period of many months with no promised return date. During the next few months I was forced to work on a Windows machine and it was like being a fish out of water. I'm a Unix person through and through and while I took solace in one of our FreeBSD boxes, it wasn't enough.

April 2006 : Still at Payment Processing Center though still without word regarding the seized iBook the decision to buy a professional level Intel based (Core Duo, 1st Generation) replacement. I ordered an Apple 15.3" Widescreen MacBook Pro @ 1.83 GHz w/1 GB of memory for approximately $2,700. The machine which would take me through several large projects for a multitude of clientele including but not limited to: a national retailer with 400 locations in the United States as well as an international magazine publishing group hosting several publications. It would ultimately be maxed out at the 2 GB of memory to which it was limited, being a first version Core Duo (NOT Core 2 Duo), and only 32 bit.

This brings us to today, with the MacBook Pro being out of Apple Care and currently being used as a desktop for over 1.5 years (hooked up to two external displays, two printers, one scanner, 3 external USB Hubs (4, 4 & 7), several external hard drives and an external Firewire Raid Array, it is time to move on to a more appropriate development machine capable of handling the newer software, operating system(s) and expansions needs as dictated by my work demands. Due for pickup later this week is an Apple Mac Pro workstations with dual quad-core xenon "Nehalem" hyperthreaded processors (effectively 16 cores) at 2.26 GHz each, with 6 GB of memory by default for approximately $3200. This provides the expansion abilities I need not to mention the fastest performing Unix workstation anywhere near that price range with the ability to handle 4 TB of storage internally as well as 64 GB of memory.

The end of this upcoming week can't come soon enough for me. It is amazing to think how far technology has come in just the past 7 years. From a fast Risc based G3 @ 700 MHz to what amounts to 16 64 bit cores at 2.26 GHz Intel Xenon "Nehalem" (Risc like design and performance customised for Apple by Intel).

More on the new workstation forthcoming.

Eric

Enforcing the Software Engineer Archetype & Related Principles

2009-06-13T01:46:00.006-04:00

It is hard to believe I've been engineering software for the past 14 years, mainly because that isn't reality. I started off like most others, as a programmer/developer and grew personally and professionally over time. As time progresses in our studies and experiences in design, development and deployment we change. This change is more oft than not, for the best.

When I was growing up, I looked towards getting a CS degree so as to become the aptly named "Computer Scientist". What I've found over the years via practical and situational based circumstances is that Computer Science isn't my primary interest. While it is true that there are pieces of the CS realm which have always garnered my attention, such as Artificial Intelligence, it doesn't ring true as a whole.

Today reminded me just how much I would like to think I have changed both in my focus, overall goals and discipline pertaining to the whole process of building software systems. Now the example I'm going to loosely reference is centered around phase one of a much larger long term project. This first phase was somewhat of a rush job as per the client due to botched (i.e. prematurely advertised) promotions for said application's 'live-date'.

I knew that taking this on such short notice would require a very strict set of time guidelines and clearly defined checkpoints and milestones if all was going to be implemented in a proper manner, one supporting a proper holistic software lifecycle approach. This of course required the initial overview of the phase being clarified, the requirements gathering phase, the initial layout with timeline estimates and expectations being put forth and finally said estimates being agreed upon with a little 'wiggle' room so as to allow for human error in the previous steps.

Well, here's what happened today which precipitated this posting. This project has a launch date of 15-Jun-09 and today being the last business day prior to that date, one could say that the end was almost upon me/us at the time. Weekends are out because as an adult and a family person with children, I value my personal and family time very highly, much higher than that of my professional work. That being said, I am indeed an experience professional and know how to accurately plan work into a give time frame clearly stating what can and cannot be realistically expected within a given time schema.

Today approximately one hour before the weekend officially arrived thus signaling the end of this phase of the project, both the designer and the overall project coordinator (not on the Software Engineer side mind you) started throwing out 'new' items for this existing phase almost completed. It is at moments such as these where the undisciplined and junior level individuals panic and ultimately sacrifice their own time for the sake of someone else's lack of professionalism by agreeing to make the changes.

I did the opposite. I made the correct move by stated clearly to all parties that we had agreed upon timelines and that they have been kept. The idea of introducing new components not part of the original design at such a late stage of the phase was outright idiocy. I pride myself in my completeness of the whole process and will not let a failure to plan on someone else's behalf negatively affect the quality work I strive so hard to ensure. Any changes need to be reviewed to ascertain what side-effects might be caused by their inclusion (especially into a more mature codebase at this point) and not to mention the quality/testing cycle which obviously wouldn't be possible due to time constraints.

What I am trying to get at is that I learned that for the sake of professionalism, quality and ethics, one must have the ability to say "No" when others fail in their planning/design. After all, the requirements gathering phase is when a competent Software Engineer brings to light questions that would hopefully coax such ideas from the requirements 'givers' if you will. It is our duty and creed to help our clients both internal and external to bring clarity to their actual needs as many times they are unsure of the specifics until discussed with others.

So I say unto aspiring Software Engineers of the future: People look to us for accountability, and part of that equation is keeping the other variables in the equation (team members, requirement providers, planners, designers and what not) accountable to the process, even if it means telling someone 'No'. Provide your reasons, and hold steadfast as these software engineering processes exist for the benefit of our projects' quality and overall success, not for the sake of being friendly or 'helping out' someone who failed to do their part in the overall planning and execution of a project and/phase thereof.

New Projects, and how to handle the juggling act that ensues.

2009-03-10T22:48:00.005-04:00

Today marks yet another year in which I've been aboard this mortal coil as it circles our solar system's centre point. So as I sit here watching to see if the remake of 'The Day the Earth Stood Still" is a much of a car wreck as has been stated and re-stated for the past few months, or if it will end up being one of those guilty pleasures. More so on to the point of this most recent update:

We in the United States of America are currently experiencing a rather nasty economic downturn/recession due to unregulated mismanagement of the country over the past many years and as such are having (as a country) to deal with roughly one in every nine persons of working age being unemployed. Yet in all of this unfortunate turmoil as brought about by the economic calamity, I find myself inundated with more simultaneous clients and projects than ever.

While I have managed multiple projects before, it was usually with the benefit of a staff. In this instance I find myself as the sole Engineer on the job. I enjoy being the centre of a given project, especially focused projects with clear requirements as they encompass the most fluidity in terms of project and process flow beginning to end. In this case however, due to a recent spate of decisions by several key individuals in charge of my various client entities, there has been an influx of new projects, primarily new ventures and re-launched (and recently acquired) web entities.

These are all primarily fashion and lifestyle media groups and magazines and while they all have a similar bent to them, the amount of design behind the scenes differs greatly from one entity to another. I find that the sites in which there is a solid plan are to most enjoyable on which to work because this is a start, middle and end whereas projects lacking any real direction simply waste a considerable amount of time, effort and never seem to measure up to properly designed sites.

There are several major concerns here when juggling this many projects, but thankfully there are just as many solutions:

Problem #1: Keeping focused on a specific code base.

Solution #1: Thanks to the beauty of multi-windowed environments, comments and code versioning systems such as Mercurial (Hg), Subversion or Git, we can save our place, with comments and safely return to them at a later time with notes on where we left off. A bigger part of the solution here is a proper code editor that focuses on all elements of a project in a shelf or sub window. By utilising an editor of this type (such as TextMate for OS X), we can keep one window open for each contracted project, each with its own attached drawer and as such simply minimising a given window completely puts a specific project out of sight and out of mind.

Problem #2: Estimations and management of many projects for multiple clients.

Solution #2: Give only rough estimates and keep in mind any potential work which may or may not come into the fray. There is also an amazing tool which only requires a writing surface and the appropriate complimentary writing implement (paper & pencil, whiteboard and a dry erase marker, etc.) The infamous GANTT chart, which allows for a wonderful representation of project portions/phases and time phases. One should not be afraid to over-estimate their time frames for a given project and/or portion of a project. One bit of wisdom which was learned after having it repeatedly played out by both myself and others is that men (not as much as on the women's side of the equation) generally underestimate by a factor of 3. If it is assume that a guy honestly believes that a project with take x minutes, in reality the time frame would be closer to x³ minutes. Gauge oneself over time and projects and adjust the factor accordingly, however start with the aforementioned suggestion as it has proven accurate in my experiences and that of others whom I know personally and professionally.

Problem #3: How should one handle priority requests and/or 'must dos' such as time sensitive changes or additions necessary to client business function regardless of assumed actual worth/priority.

Solution #3: This is much simpler than one would expect. When discussing the issue with the client (wether internal (if a salaried employee and dealing with internal 'customers') or external) point out that this will be shifting the entire project timeline by the time required to complete this unscheduled emergency. Now this isn't always practical or appropriate such as in situations in which a previously scheduled change was turned into a 'must do'. In situations such as these that portion of the scheduled project can be removed from ones GANTT (or other scheduling) chart(s) it their entirety.

There is one caveat with this approach; when removing a project portion due to unexpected/unplanned rushed completion, always add in additional time when shifting the remaining pieces of the project(s). The primary reason for this is simply because additional time should be made available regression testing and/or additional testing due to the reduced time frame and unscheduled manner in which said changes were made, one in which a great possibility for error introduction was more likely. The other major reason for doing as such is simply to protect oneself when another one of these situations occur. It would be foolish for anyone to think that if this happens once, that it is unlikely to occur again. Generally there are those who have little emergencies all the time, and those who 'suffer' from such events rarely if ever. If it happens once, be sure to assume it will occur again as it is usually the result of bad planning or communication somewhere between the engineer and the end customer though more oft than not it is a middle-manager or a sales person making promises which had they been honest and/or considerate of others, they wouldn't have made in the first place.

Handling multiple projects can be easy if one enforces certain rules (albeit with a willingness to bend as long as attention is paid to making adjustments so as to not allow oneself to be run into the ground by continually pushing more amounts of work into a time frame never intended for said work as such.). The importance of communication is key in this instance as expressing realistic time frames in the first place would resolve many of the ugly situation which sadly arise in real world environments on an ongoing basis.

Guiding the Future Generation...

2009-02-13T14:51:00.002-05:00

This is more of an announcement than a standard codedevl.com content update, of where there will be one in the upcoming week.

On 09 March, 2009, I will be partaking of the 'Career Week' activities at Central Bucks East High School by serving on a panel along with other professional in various fields of Engineering, Mathematics and Technology as a means of not only sharing what it is we do but also answering posed questions by the future minds of our respective fields.

I feel it is a very important responsibility of experienced professionals to better server their community (both locally and the whole world in the large scheme of things) by passing on what knowledge one possesses to the following generation(s) to ensure that the gain wisdom proliferates through the ages. I hope other readers of codedevl.com take an active role in this endeavour as well, and if so please feel free to post about it either here or on your respective sites.

Dealing with Horrible Legacy Code

2009-01-22T16:05:00.004-05:00

I know, I know.. it has indeed been a while. What can I say, I've been busy with work. Even though the US is deep in a recession so bad that Microsoft and IBM are executing mass layoffs (Microsoft's ever), there are those of us; especially on the Unix side of things (I gather Linux users as well) who are swamped with new projects.

As many readers would know, I have for the past year and a half been offering my software engineering services to an international publishing firm based out of New York with branches in Pennsylvania and Japan. Yesterday I was in Manhattan for a meeting of introductions to the individuals with whom I would be coordinating on not one, nor two nor even three projects, but four new magazine entities. This now brings my overall responsibility in terms of publications I handle to a clean half dozen.

I'm glad I'm not in the Microsoft world (for multiple reasons not to mention primarily because I refuse to work with junk and this includes any MS OS), but for the reason that with all of these layoffs, a mass amount will be MCSE's and VB/.NET programmers, architects and engineers. This does however segue into my first point (trust me, there is a relation).

In my most recent project, a sister publication of it actually needed some work done to their rss feeds. Apparently this was first and foremost to fix a broken rss subscription page (where one could select which 'feeds' to follow). This problem had been present for over a year from what I've told, and it was so bad that the page itself was throwing a PHP debug page when accessed. This is wrong on many levels, most immediately that the debug mode was still on in the server configuration (the other errors being that they were using PHP, and allowed something to go on for over a year, broken.)

Not wanted to reinvent the wheel as well as having a sense of right and wrong I contacted the original developers of the software and let them know that since they were the only individuals with write access to the entire group of applications involved (not to mention this was custom built by them), that it was their fault 100%, and their responsibility to fix it, and quickly at that. As a side note, I had been informed by my client that they had made repeated requests to said developers about this problem for over the past year and were informed that it would take 'a lot of time', and that they would be billed accordingly. Long story short, I got in the developers faces about professionalism, the fact that had they any procedures in place for regression testing when changes were made and a proper set of document and qa tests, this problem would have been squashed the moment it was introduced. Three hours after sending my well crafted letter, I received an email back from said development house that the problem was rectified, all is working and that there was no charge. No charge indeed, I wouldn't accept one if they tried as it was entirely on them.

This brings me on to point number two as I could rant about the prior issue if left to my own devices. My continued disdain for the overwhelming use of PHP. I know it was a great idea that filled a niche when it was created, but it truly has grown to be something rather heinous: the sucessor to visual basic. I say this because as with VB, the purpose was to make creating software in said language possible, even 'easy' for the 'non-programmer'. This is a simple point to remember so I won't waste additional time stating it. Non-programmers shouldn't be programming, period. You either are a programmer, or you aren't. If you aren't, you have no business behind the keyboard writing code for anything that ever goes into use in a company by anyone, including yourself. Engineering isn't a child's game and it requires discipline and continual study and exercising of one's skills. We won't pretend to do your job, you don't pretend to do ours as you are only making things worse.

This came about because while looking at the code to find the original rss problem (which was fixed without having to write any code in that monstrosity), I became disgusted at how hackish the whole application was. It was guilty of all of the following and more:

- ambiguous variable names

- includes of code snippets where objects should have been

- nested structures 4+ levels deep

- very few if any comments in the code

- very little meaning in those few comments that actually pass as informative.

- non-sensical file hierarchy for modules, includes, etc.

- hardcoding of parameters in both equality tests and branch based if statements.

& much, much more.

It is enough to make one partake in an involuntary protein spill reflexively. The good news of it all is that this old code base (I use the term code VERY loosely) will be redesigned and re-implemented by me and I can guarantee (because I DO guarantee my work) that it will be faster, cleaner, easier-to-use, easier-to-upgrade (including maintenance) than the existing system and will be constructed in a considerably shorter period of time.

It is times like these where I'm glad that these other places exist. It is hard to not look good when everyone else is so hideously bad. I just feel bad for the poor companies and individuals who utilise these companies' services.

recent job, nasty code built hackish bit by bit, quickly

no comments

php (*the open source equivalent of Visual Basic*)

New Projects & Version Control Systems

2008-12-05T20:34:00.007-05:00

It has been over a month and a half since my last entry and I apologise for the delay. I have been working tirelessly to finish up my primary design, development, implementation and maintenance functions on what has been my primary project for the past thirteen months. I've been doing this so that I may jump head first into my next project, which while not being a 'huge' undertaking is big enough. By big enough I mean that doing well at the project will land me the role of redesigning a major site from the ground up into the Django framework.

For the past 13 months I've been working heavily in the world of Django and find myself absolutely enamoured with it. I have designed a considerable amount of applications for Django, though none of them are released to the world because they are the product of a contract. My field of expertise was never in that of online applications and/or frameworks so it is stil a new world for me (if we exclude the nine years running a twelve line bulletin board system on a heavily modified Amiga).

I've always been happiest working in middleware and engineering backend systems, though I have to say that I'm finding a certain level of pleasure from the results of my front-end work. When i wrote backend systems, the only others who could appreciate said system(s) other than myself, were developers privy to the project. On frontend systems, there are actual users who I would like to think 'benefit' from my designs and implementations. It is nice to know from actual users that your work is appreciated. Call it ego stroking, or call it what you will but I find that it does inspire one to keep pressing on regardless. I happy to be doing these projects and as soon as it is launched, I'll be happy to post about it here.

This brings me onto the second purpose of this entry, my new favourite version control system. In the beginning of my experience using version control systems back in the 1990's, I simply used CVS like the rest of the world (sans those lucky enough to use Perforce). As time and technologies advanced to newer and better systems, I followed along and moved up to Subversion. Subversion was a well done upgrade for CVS users and easy enough for the uninitiated to learn. I used this most recently when I did work for Curlington Boat Factory (name changed to project myself) writing their point-of-sale returns authorisation/queue system in Python for four hundred some odd cash registers. This worked our quite well despite the fact that the software house for whom my partner (at the time) and I were contracting weren't able to provide the subversion server on their machines until we were ⁷/₈^ths of the way through said project. We ended up (very early on mind you) taking matters into our own hands and setting up on my partner's server at his apartment. This wasn't looked upon highly by said software house, but any CVS on any server regardless of not being in control of the software house was far better than no source control at all.

Next we come to my brief stint working for a OCD kid who started his business at the right time with mom and dad's money, but due to poor decisions on his behalf watched it dwindle in popularity, further plagued by poor management and attempts to treat a small business as if it were a conglomerate thereby sealing its fate with a tender kiss on its cheek. I thankfully left the company before the owner went psycho and let go of all the talent in a horribly vicious manner. Before all of that ugliness transpired, I went forward with trying the newest and brightest trend in distributed version control. I am speaking of the one and only 'Git', championed by a certain arrogant (albeit brilliant) Finnish kernel programmer. There was an immediate joy in using Git and I have to say that most striking feature is the blazing speed when dealing with a large quantity of files. I established all of the existing software base for said company (over ten years worth) into its first repository, utilising Git. Yes, for over ten years, there was no VCS in place. Git really did shine in this role, though I am pretty sure that due to myself and the system administrator not longer being there, cob webs must be forming in the places where Git once speedily did its work.

Let us fast forward to my newest discovery (if you can actually call it one as such). On this newest project which I just started today full time, I have been doing administrative setup work for the past few weeks on and off in small gaps of time as they availed themselves to me. The normal deal of establishing a dedicated server on a FreeBSD host (as Linux just will not cut it for me even though I've been using it since kernel v0.99d), along with all the necessary bits. Once the development languages, utilities, database and web servers were in place the issue of VCS came into play. For this time around I decided that Git, while great for many projects doesn't seem as pythonic a package as I'd like. Using Python long enough really makes one desire beauty, power, simplicity and consistency in all of their tools. This brings us to the most pythonic vcs of them all, Mercurial (known simply by its periodic table element, Hg). Mercurial, like Git is also a distributed version (revision) control system. Easy to setup, easy to use and highly recommended. I'm not going to wax poetic about the differences between these systems as they all serve a purpose. What I will do is state very clearly that Mercurial feels the most natural, works rather well and is quick at what it does. Your mileage may vary.

Until next time...

Django Projects Galore and Vile Ethics of other Coding Firms..

2008-10-16T19:51:00.006-04:00

It has happened yet again. I've been brought on for another Django project. This time it is about taking an existing site for yet another magazine publisher and converting their Wordpress driven site into a real full-blown site complete with blogs, forums, user profiles, dynamic main page content, complete customisation from within the framework and included applications and ultimately a site in which a developer is not needed for day to day changes.

As it exists, this publication is an off shoot of their primary magazine. A magazine whose website was written and managed by an outside from that I believe coded the entire site so as to require additional invoicing and servicing for all but the most minute changes. This is a disgusting business model and one with which I've had the misfortune of experiencing whilst working as a sub-contractor to a sub-contractor for Burlington Coat Factory.

The H-1B Visa Project Manager who wasn't too fond of me because I don't believe that coding in dress attire and/or a tie makes someone a better worker (to the contrary, i will NOT wear dress attire for day to day work as it is a pointless expression of old brick-and-mortar mindsets). He also was the first time that I was reprimanded for having an eloquent solution that adapted automatically to the growth needs of the end-clients database/system. I wrote the software to handle dynamically gathering and sequencing additional 'like' fields as they were added to Burlington's transaction schema. The way I designed and wrote the software, the MOMENT the schema changed, my software contributions would immediately include relevant changes, without a restart of any of the daemons I engineered. I was told that the reason why i shouldn't have done this is because the sub-contractor for which i was writing this code could then go back and charge an exorbitant amount of money each time minor changes were made. This disgusts me, and I find it ethically wrong.

I am an engineer and work independently by choice as I can first and foremost hold myself and solutions I produce, to higher standards; delivering what my clients want and need, not solely based upon what they say they want and most definitely not building them into a corner for profit over common decency and professional standards.

Once the project has been completed, I will be quite happy to share the url(s) with CodeDEVL readers.

Django 1.0 has been Released, Film at 23:00.

2008-09-10T11:14:00.002-04:00

I know that it has been a while since I have last posted, but I'm not one to post meaningless empty ramblings on a regular basis. I just want people to know that I'm still alive and will still be posting when I have something worthy of your time.

I will mention in brief that Django v1.0 has been released and we are all thankful to BDFL's Adrian Holovaty and Jacob Kaplan-Moss for their amazing efforts in making this release come to fruition. I would also like to add that the biggest 'gotcha' between .96.x and 1.0 is in the standardisation of certain db api arguments. maxlength has become (more aptly) max_length. There is also now a DecimalField type which can be used rather than the less accurate (for monentary purposes) FloatField. Read all about it at the Django Website.

Finally, for those interested, I have also started another non-computer related blog over at Bucks Bicycling, a site related to vehicular, commuter, recreational and sport cycling. I'm currently working on a fixed gear conversion of an old cheapie AMF Roadmaster Scorcher as well as a 1985 Schwinn Sprint road bike.

I will be posting shortly pending upon the official status of the newest Django 1.0 based project on which I've been secretly working.

Till then..

In defence of the lone coder archetype

2008-07-18T12:46:00.004-04:00

All too often these days we see companies and methodology evangelists touting the system du jour whether it be Extreme Programming (XP/Pair Programming), or Agile as being the "One True Path" to coding enlightenment. All other be damned is roughly what said mantra translates to in common speak. We're told to beware the engineer who works alone in a dark back room for weeks on end. We're told to such a thing is heresy against the gods of modern application development.

We're being lied to by the methodology evangelists. I'm not here to down speak any of the other methodologies currently in use for software development. I am here, however to point out the benefits of the 'lone engineer' (not to be confused with the lone gunman). Lets set a few things straight though.

A coder with little to no professional experience in the field is not the optimal individual for this kind of setup. This is more for a seasoned professional who has at least been a team lead on several projects from conception through maintenance phases. I'm not saying it isn't possible to pull it off without significant experience, but I wouldn't place bets on such an individual succeeding at the whole task at hand in said company.

This kind of environment requires a disciplined engineer. We're talking about someone who knows the questions to ask, and how to dig deep to find the true needs of the client(s). This also means that the engineer needs to stand his/her ground when it comes to setting a solid schedule for phases of the project(s). There is room for variability in terms of time frames for each phase, but that the plan must be laid out in a linear fashion. This is engineering after all, and one doesn't plan to build the rooms before the foundation is laid.

Agile methodologies are more akin (though not parallel to) modular housing construction. Individual sections or units can be build simultaneous and changed (to a certain extent) by separate sub-teams. Whereas the lone engineer mentality is more akin to traditional construction in which the design is finalised, the foundation is laid and construction occurs in layers from the bottom up with customisations being generally last.

This isn't to imply that software built in this manner cannot change or adapt in a timely manner, far from it. Seasoned engineers/developers understand that the only true constant is change. We constantly work on new ways in which to design flexibility and mutability into our systems regardless of the specifics. This however just goes back to one of my earlier points in that this requires someone who isn't wet behind their ears. You can only know and plan for the unexpected via flexible designs after having cut your teeth in real world projects, and by faltering. Everyone makes mistakes, and it is through these mistakes that we grow and better ourselves. I'm not implying that senior level engineers don't make mistakes, I'm just pointing out that their success to failure ratio is pretty strong in favour of the success side.

One of the key benefits of the lone engineer methodology is that focus can remain solid with no deviation due to intra-coder/intra-team conflicts. And while this can at teams be a negative, overall it proves itself beneficial towards the ultimate goal, a finished software package/eco-system designed from the ground up to benefit the requisitioner(s)/client(s).

The issues of coding standards still must be kept, however there is definite consistency when only one individual is involved. This is also a liability as said engineer must have strict standards, commentary and documentation from beginning to end so that in case of any situation rending the engineer on the project incapacitated in any form, another could come in and continue with minimal delay. These are issues which affect other methodologies, some more than others.

There are downsides as well though. There are no direct peers upon which one can depend in times of need or collaboration. There are no peers to assist in code review sessions, meaning that the QA of any project must be proficient at testing, and enforce strict recursion testing when any changes are made to a product in production as QA becomes that final line of defence against human error. The reality is, no usable (as in serves a real purpose) piece of software is bug free and to think otherwise is the sign of a fool. What is realistic is having a system robust to handle errors when they occur, even if that is infinitesimally infrequent.

I'm getting off track here. My point is that in this newer, more extreme era in which coding fundamentalists believe they possess the one-true-way of coding and all others be damned, we must step back and realise the grave miscalculation they are making so boldly. After all, those methodologies weren't what were utilised to get us where we are today, nor were they even thought of when some of the staples of our art were invented. This doesn't mean that the next great piece of software or language won't be produced in such a manner, as it/they may. It means that we as professionals shouldn't be so narrow minded with tunnel vision when approaching different methodologies in an attempt to find which works best for the project/company/industry at hand.

SimulaE Cartography Program - simulae-kaart.py

2008-06-26T21:37:00.004-04:00

As a quick follow up to the previous entry regarding rooms being a void and not an object, I can happily announce that the first working alpha of simulae-kaart has been committed to code this evening.

The function of this bit of code is simple: Produce the necessary wall/barrier objects needed to create the voidspaces we call rooms.

The current working codebase does the following already:

* Allow graphical design in a 2d environment utilising unicode representative tokens.

* Returns Multidimensional Lists designating literal start & end points of wall objects

* Allows for walls in traditional cardinal orientation (north-south, east-west, nw-se & ne-sw)

* Also allows for arbitrary wall/barrier positioning at any angle (true 360 degrees).

* Default scale based on cubic decimetres, variable scaling coming soon.

Upcoming functionality to be added:

- Auto population of a given map grid

- Auto insertion of portal objects inside any giveen barrier/wall object.

- Automatic map scaling down to the smallest micro and largest macro levels

Stay tuned for further information. If anyone else is interested in signing up for future beta

testing, I can be reached at this domain, under the email account of eric.

-e

Simulae3 Update: Room Object? What ever do you mean?

2008-06-05T22:50:00.003-04:00

This is just a simple, quick update to let it be known that the issue pertaining to how to accurately represent a room in Simulae3 has been resolved. I spent about an hour with a blank book of graph paper and pen poised in my hand and thought about the problem till the following realisation hit me:

Rooms are an abstract, a void. They only exist as a concept without substance to us. They are the empty space created by barriers, some of those barriers contain portal objects (e.g. windows, doors, openings). It is using this logic that the next piece of Simulae3 can be designed.

SimulaeKaart.py

A simple cartography-based program (kaart) being the word for map in Nederlands (Dutch). Physical space will be represented in 10 centimeter square grids (though variable map design may be possible). The whole point of this is that in the real world, we use GPS and surveying to accurately place physical locations, Simulae3 will be no different.

The other quick note is that the concept of rooms are also knocked out in that a room knows not of its purpose, it is only by human reasoning and deduction that a particular enclosure/void/"room"'s purpose can be ascertained. If you take an empty house with two rooms near the room with the stove and dishwasher, how does one know which is the dining room (if either). One doesn't, one chooses to assign that role by the placement of the appropriate objects (appropriate to a dining room that is) within said void.

Simply put, this conundrum has been resolved and the next phase of design and coding can continue.

Migraines: A common misunderstanding

2008-05-28T00:22:00.004-04:00

Mi - graine: (n)
A headache characterized by throbbing head pain, often greater on one side; may be preceded by a warning (aura) and accompanied by nausea, vomiting, and sensitivity to light and sound; in rare cases, weakness, language problems, or other neurologic disorders are associated with migraine.

Over my years of coding I've endured what I thought were migraine headaches, not uncommon to those of us who spend waking moment after waking moment staring at multiple screens as part of both work and hobby. I say "thought" because up until this past weekend, I was sure that the harsher headaches I had endured qualified as the infamous 'migraine' variety. I was wrong.

On this past Saturday, I had the pleasure of seeing one of my best friends (and also my best man at my wedding) tie the knot with his sweetheart (both are coders by trade as a sidenote). The day was perfect, the weather was wonderful (as it was an outdoor ceremony) and all was well in general. I on the other hand aside from coping with sciatica down both sides of my body (a relapse of a previous L4/L5 left disc rotation), awoke with what I thought, was one of my annoying 'migraine' headaches. I took Excedrin Migraine along with Vicodin for my other-pain and proceeded onto the wedding with my wife. The headache didn't subside, regardless of a second round of 'migraine' strength medication.

The first lesson to be learned here is that Excedrin Migraine (I'm pretty sure any over the counter "migraine" medication as well) , while great for 'bad' headaches, is lightweight against 'textbook' migraines (more on this later).

After the wedding was over and we made the drive home (hellish for me as my headache seems to have grown from annoyance to throbbing), I started to feel dizzy with a bit of nausea, yet did not succumb to an involuntary protein spill thankfully. I ended up retiring fairly early figuring that my 'migraine' was just particularly bad and was exacerbated by the fact that our table at the reception was next to the live band.

Sunday morning arrived and that horrible headache was still present. I took two vicodin and several aspirin in the hopes that it would finally kill the beast within but it was all for naught as much to my dismay, the headache only soldiered on. I spent much of the day in a narcotic (vicodin) induced stopor in an attempt to mask the pain which was at this point pressing heavily on my head, and would remain this way the rest of the day into the evening when I retired early in an attempt to once again let tomorrow come without the now 36 hour headache. Little did I know that this was about to get worse, much worse.

Memorial Day arrived, complete with plans to go to my in-laws for a barbeque and family goodness. 04:00 on the clock and I arose from my sleep to the udder shock that the pain was not only existant, but worse. I quickly (well, as quickly as I could) went downstairs to take three Advil (I was now out of Excedrin Migraine), and then return to bed, hoping this was finally the end. The time was 08:00 according to the clock and I was expected to rise. Problems. The headache was still there, and it was rather angry with me. Outside of glancing to see that it indeed was 08:00, I had to keep my eyes shut, the dizzy feelings, nausea and pain from the light (through the blinds, mind you) was unbearable. It felt as if my head had been mounted between the the grips on a vise. I at this point, took the decidedly un-male action and asked my lovely wife (and child) to get me to the Doylestown Hospital Emergency Room. Something was obviously wrong and I was quite worried, not to mention blinded by the pain.

After what seemed like an hour (when in reality it was half of that), I entered the ER and was promptly thrown in a wheelchair, tagged and admitted to ER room #5. At this point the pain caused me to writhe in pain in my open-backed hospital gown in my new metal bed. Another 10 minutes came and went, along with an increase in the pain until one of the nice ER nurses (and a doctor I believe) tapped my arm to place an IV line, which was utilised shortly thereafter to inject a medication (a narcotic of which I'd never heard) that immediately overpowered the pain with a feeling of numbness. This enabled me to speak somewhat lucidly to several nurses as well as a doctor about all of the aforementioned backstory leading up to this point.

First comes the catscan at this point to check for abnormalities. None found. Then the blood tests, no oddities either. ER Doctor then comes to the conclusion that a LP (Lumbar Puncture) was the next logical step. I consented, though it was not to be, after a considerable number of jabs and sharp pains, said doctor gave up and contacted a Neurologist who would come in later to do said LP.

The pain started to return and I was given another dose of said magic narcotic. All remained well for another 90 minutes or so (at this point, I've been in ER room #5 for approximately 6 hours). During this time the Neurologist arrived and I spoke with him and allow him to have a crack at a lumbar puncture. Needless to say he was an expert at this procedure and was able to withdrawal 4 vials of the clear cerebrospinal fluid from my spinal column. He then surreptitiously disappeared for what seemed like hours.

It was at this point, my pain surprisingly started to return, first on the right side of my head, but then started to migrate over to my left side as well. The pain became so severe that I could tell that the lights were on in the next room over (separated by a curtain), even though I had a folded over pillow case upon my eyes, with my hand over that. The lights in my room had been out since my arrival as they were painful, even with my eyes shut. I felt as if I were going to tear the metal sides of my bed clear off. I suffered like this for another 60 or so minutes as we were awaiting the results of the spinal fluid from the lumbar puncture, and it was already stated that I was given an extraordinarily large amount of narcotics already and they worried about providing anymore until they knew more about the cause of my pain.

After all was said and done, I was told that this whole episode of the worst head pain in my life, was a 'real' migraine. I was told that they would provide me some additional medication intravenously before being discharged which would 'kill the headache' this time. I was also being given more subscriptions, one for vicodin (as if I didn't have enough for my back pain, which I already try to avoid using), but a medication which i had never heard of before, specifically meant to stop migraines at their onset. That final migraine killing injection came, along with a complimentary spewing of my stomach contents shortly thereafter and I was on my way to being released. I was informed by the doctors that there were a few things I could do to keep migraines at bay aside from the medication provided.

"Caffeine, Caffeine, Lots of Fluids, and of course, more Caffeine."

I'm thankful to all of the wonderful nurses, doctors and specialists who provided help to me after suffering what ultimately will be remembered and hereafter referenced by me as the 60-hour migraine. I will never use the term "migraine" mistakenly to mean a "severe" or "bad" headache as they not only aren't in the same ballpark, they're not in the same league, region or country.

I decided to share this with everyone in the coding community because I'm sadly sure that this will happen (if it hasn't already happened to some of you) again, and to others. I hope that having read this, those who find themselves suffering one of these 16 tonne behemoths will not wait an exorbitante amount of time before doing exactly that which I did, contact professional medical help as quickly as possible. No one should have to suffer that kind of pain any longer than it takes to realise what said pain was; that being a 'real' migraine.

Wishing everyone good health.

Eric

Simulae3: A Testament to Socratic Design.

2008-05-21T00:34:00.004-04:00

Socratic Method: the pedagogical technique of asking leading questions to stimulate rational thinking and illuminate ideas.

When I first started working on SimulaE (long before it was even referred to by the aforementioned name), it was a solo project. This isn't to say that I haven't written all of the code from day one to this very moment, because I have. I can however say that the design portion of its various incarnations wouldn't have evolved in the manner which they did were it not for the diligent use of the Socratic Method.

My earliest versions of designing the Simulae virtual world simulation suite of libraries and what not were designed and written by me in response to the original interactive fiction/text adventure engines, then consequentially MUDs (Multi User Dungeons). The proof of concept of building a better designed mousetrap was simple enough to bring to fruition. This took place over years, dependent upon my free time and interest in furthering what was simply a flight of fancy for me from my programming youth and Zork playing escapades.

What really became apparent was when I worked for another company and had the pleasure to work with a very intelligent individual by the name of Tim. He is a systems/network administrator as well as a capable coder though the latter is not his primary goal, nor role professionally.

Tim was interested in my Simulae project and as such I found a kindred spirit through whom I could interact by applying the aforementioned Socratic Method. Through a constant back and forth barrage of theories and examples along with postulates about the hows and why virtual components modeled after reality need to be viewed in a certain light, we would come up with a whole new understanding about the direction of the project.

It was during this time initially working together that the present tense English Parser component (parser.py) came to be realised and produced. It took a total of seven point-releases to go from simple noun verb understanding to parsing complex compound sentences with a massive understanding of 45,000 adjectives, 9,500 verbs and multitudes on various parts of English speech. This series of productive success if anything re-enforced the validity of this methodology in the realm of software design.

It is now though, with this in mind that I have taken utilising this method to the next level and enacting it with completely uninvolved individuals (uninvolved in the sense of the projects topic and internals). In the past several days Simulae3 has emerged from the bowels of my TextMate application. The code is simple, shorter and far more capable than any previous incarnation and things are moving forward at a great clip.

This brings me to the current point of interest and a call for assistance for anyone willing to get into sometimes heated dialogue about object models. The object model system is based around the three basic SimulaeObject types. The only piece of the puzzle still causing an issue is the matter of Portal Objects (entranceways between other container type objects.)

For the sake of argument, just look at it this way: A room is a container, that leads from one room to other rooms of 'greater' building enclosure. A set of lips in a Mobile Object (hereafter MOB) (e.g. 'actor' in OO/UML terminology) is simply a Portal Object to the mouth of said MOB. A window is simply a portal between the outside 'container' object (in this case a root SimulaeObject), and the room in which our Actor/MOB would be in (to see said POB destination from said perspective).

I need others with whom I would be able to work out ideas so that this conundrum can be resolved and the next phase of Simulae can come about for code release and testing. If anyone is interested, contact me at this domain via my email address: eric

I am going to finish on that note being that due to medical reasons dealing with my sciatica, I ingested a full dosage of two Vicodin tablets (as per my primary physician), and as such I'm getting ready to crash hard. I hope to hear from some of you in the hopes of moving forward, but I'd like for Tim to give me a call in any case so that I we can bounce some ideas back and forth on these issues.

SimulaE - Model Update

2008-04-27T22:10:00.003-04:00

I've made mention of my virtual world simulation project on multiple blog entries, most recently related to Ruby and making a rewrite of the existing engine in said language to test out its applicability (the language not the simulation), which by the way I found to be the lesser language for this kind of application, but I'm not saying anything about the language as a whole. Either way, onto SimulaE, which after all is what this post is about today.

I have been rattling my brains (and occasionally those of my friends) regarding the basic SimulaE Object model, which up to this point has served its purpose. Though the time has come for it to evolve. It can implemented in a simpler manner and I have known this in my mind all along though it hasn't been an issue in the process of designing the parser which has for the most part been satisfactorily completed. Now that my focus has returned to the object model, I feel it a fine time to share that update thus far. Comments are always welcome and most are appreciated.

The fault before was that I broke the objects into the wrong sub classes. Originally I had the parent Object class, and subclasses for Room objects, Exist Objects and Person Objects. This is a horrible idea and leads to unnecessary complexity.

The newest model:

Object (super class)

MovableObject (isa Object)

PortalObject (isa Object, isnota MovableObject)

PortalObjects, hereafter POB are a much more dynamic version of the previous "room" objects. A POB behaves in the following manner(s):

1. Object(s) enter into the object containing said portal.

2. Exits an object when contained therein.

3. Can exit (when specified) to a specific object, though by default exists to the parent container object.

If a MovableObject, hereafter MOB, is not contained within the same container as the POB, POB leads into the container.

If the MOB is contained within the same container as the POB, POB leads out of the container.

By working in this manner, we ensure that the simulation object model more closely mimics the real world, whilst still allowing for exceptions to transpire for non-real world based applications of this group of models as well as anything they may be working on at CERN in Switzerland which breaks our current understanding of physics.

I haven't had time to implement this new set of models yet, but as I write that code, I will be posting the revised Python source.

Quick Django Tip: Dynamic Application Object Retrieval

2008-02-24T23:44:00.004-05:00

In my recent django adventures I needed to introduce site-wide search functionality and in the process of doing so, encountered a small roadblock towards doing so. Apparently due to the nature of Django's API for db interaction (as of the last stable release version), there is a limitation as to the use of python variables in API calls. I found this to be a hinderance, but only for so long.

The follow code snippet was something I whipped together which by utilising Python's 'eval' built-in, overcame the aforementioned limitation regarding the API's ability to interpolate native Python (e.g. non-django explicit) varaibles.

Things to know to understand the following example:

search_input is a list of cleaned and pre-processed user-driven terms, split into separate expressions, (e.g. ["dynamic langauge", "agile", "programming", "paradigm"]).

search_schema is a dictionary in which the key is the django model/class through whose objects we are attempting to search, and the value is a list of specific model attributes to attempt said search. (e.g. User_Profile : ['firstname' , 'lastname', 'address_1', 'bio_info', 'favourite_books'])

container_xref is a simple alias mapping for the actual django application names to our internal references inside this search code base. Obviously this whole bit could be written without said setup, but for readability given the scope of the actual application involved, and the fact that I was not searching simply a few static fields in one django application, but several dozen fields through about two dozen separate applications, this container_xref dict was appropriate. It is through this mapping dict which we place any matched object results (so as to not waste any additional space via unnecessary list initialisations.) for eventual results generation.

Note: the key "total_results" in the container_xref was a simple means of keeping track of overall search matches, rather than relying upon the Django templating engine (view) from doing work responsible from the processing (controller) perspective. In retrospect, there are better ways this could have been handled, and in future point revisions, this will be addressed.

------


for search_string in search_input:
  for application in search_schema.keys():
    for attribute in search_schema[application]:
      code_to_eval = "%s.objects.filter( %s__icontains='%s' ).order_by('-id')" %       
                     (str(application), str(attribute), str(search_string))
        try:
          eval_results = eval(code_to_eval)
          for eval_result in eval_results:
            if eval_result not in container_xref[application]:
              container_xref[application].append(eval_result)
              container_xref['total_results'] += 1
        except Exception:
          ### Case specific exception handler types, assignments and resultant actions 
          ### specific to each application in which the above is implemented, go here.

-----

As can be seen from the above, simple inline substitution proceeded by evaluation of said string results in post-compilation dynamic search functionalities within django, addressing simple problems one might run into with the existing API which will most likely be addressed in future versions.

Your results may vary.

Eric

Ruby: Somehow I overlooked this Gem of a Language

2008-02-19T13:51:00.006-05:00

About 5 years ago I started looking into a language that prior to it's "Rails" fame, was lesser known and even lesser utilised. I tried it a bit and found it leaving me wanting more. I've kept tabs on it over the years, reading the tutorials and writing several quasi-AI experimental applications for my SimulaE research, but I ended up being enticed by Python, a language which I stand by, including the wonderful (but until recently unused by me) framework Django (Python's Rail's equivalent, focused on Publishing).

I've programmed professionally using Python for several contracts/years now and find it quite enjoyable. In fact, I'm currently coding specifically in Python for Inkedmagonline.com, but that doesn't mean that I don't continue my personal exploration and education for both personal and professional reasons. I decided to re-experience Ruby by picking up the hallowed PickAxe book and giving it another honest chance. I'm glad I did.

I believe that Python, and the values espoused in Tim Peter's "De Zen van Python" (The Zen of Python) (my copy just happens to be in Dutch, otherwise I'd post it for others) have helped me to look at Ruby in a different light. There are some key differences in the two languages, but I can see now the inherent power in Ruby that I was overlooking before. In fact, some of those key pieces, syntactically as they were which make Ruby so enticing this time around are the very same 'features' I feel are missing in Python. It only took me working in an environment with situations where said language features would prove the best solution to the problem(s) on hand for me to realise it.

I am not going to spend time detailing all of the specifics, though I may mention one or two nonetheless. I'm more so bringing this point up so that others might be reminded that giving something new a single chance might be to your own disadvantage. After all, I didn't like Python the first time I tried it either. I think it is partially a matter of how we grow as developers that allow us to know what we're missing, that same spark of realisation that gives us the "a ha" of relief when we find it hiding in a new language, programming methodology, etc.

What brought me back to looking into Ruby a second time is of all things, Smalltalk. The whole "everything is an object" concept is nothing new to me, or to programming languages. However in dynamic strongly typed languages, it is. More importantly is manner of how even rudimentary objects such as integers, floats and strings are treated in Ruby. They have methods which can be both called using the standard instance.methodname call format, and have their standard methods overridden. The second being something far more wonky and kludgy in Python (and a non-option in perl).

The fact that key methods are instance based such as "len" or "length" for example makes a world of difference for consistency. It speaks to the overall design that "Matz" (Yukihiro Matsumoto creator of Ruby) had in mind during the planning phase. In Python, a language in which everything is truly an object as well, this starts to get rather confusing. While Python does treat every integer and string as an object, it mixes the traditional functional paradigm for calling items such as 'len' so that to find the value of 'a', one would type len(a), as opposed to the more object based a.len .. This seems counter-intuitive and quite frankly a real surprise when you look at the overall design of Python.

I'm not ripping on Python as I do wholeheartedly enjoy the language, I'm just starting to feel aches and pains over decisions which are ingrained into the language, as well as not being seen as an issue or being addressed in py3k (or Python 3000/Python v3.0) as it were. I just think that my eyes have been opened to Ruby again and I like what I'm seeing. I am actively looking to find a future professionally as it were utilising it as nothing beats having fun while accomplishing what one would hope accounts to 'great' things. We'll see what the future holds.

Next Step: Migrate my SimulaE virtual world/real model object simulation from Python into Ruby as a test run. Lather, rinse, repeat and then see what the side-by-side comparison's look like.

Until next time...

The Importance of Being Challenged

2008-02-05T21:02:00.000-05:00

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

Arc: An evolution of Lisp/Scheme, or a outdated implementation at launch.

2008-01-29T22:55:00.001-05:00

So the day has finally come in which prolific geek & insightful essayist Paul Graham along with Robert Morris released Arc, their evolutionary love child of Lisp & Scheme. I think it is safe to say that many of us have (and will continue to) read Paul's wonderful essays on a multitude of geek and coder centric topics, and generally with much joy and agreement. Many of us have been following the work that Graham and Morris have been undertaking with the new baby "Arc".

Now that this day has arrived, we can see that it wasn't as deserving of all the pomp and circumstance to which we were planning for it to be attributed. Seems that there are a considerable amount of deficiencies and intentional short comings to the language. Normally this wouldn't be seen as anything out of the ordinary for a 'new' language, and would be generally a non-issue.

The problem is that this is the year 2008 and people have come to expect more from their languages. Ignoring established standards along with ignoring the need for designing to meet the needs of developers globally all the while using the cop-out of it being purely for exploratory programming is just bad form.

The world doesn't need another Lisp, the original is wonderful just as it is, that's part of its beauty. I don't see anything in Arc that couldn't be done as functions and/or macros in Lisp that required the entire 'creation' of a new language. The way I see it is this; for prototyping as well as production usage we already have several languages that excel in those domains, specifically Lisp and Python.

Generally the idea of rewriting existing languages with little difference from their predecessor(s) is a waste of time and effort which could've been better spent elsewhere. There are exceptions to this scenario such as that of Ruby. It is a language that in the past I used to dislike because of certain key flexibilities much akin to the reasons for spaghetti perl, but it successfully fixes many of perl's wrongs, and corrects some of Pythons short comings as well. It serves serves enough of a purpose as that of supplanting perl with a better thought out design, and thanks to Rails, its future looks solid.

Arc on the other hand is like a still born fetus. Much was expected and there was potential to be just like its parent(s), but death was announced during a delayed delivery and upon further examination, it was discovered that it wasn't a proper offspring, but a clone in fetal form. My advice to Paul and Robert is the following: recall the release, and make it truly something worthy of release, with proper compatibility and compliance with modern norms. Make it usable to others as opposed to just a few tinkerers interested more in lisp and scheme basics.

An on a more pleasant note to Paul; Please keep on writing your essays and providing your viewpoints as they are appreciated, I just wish that your judgement call in the case of 'Arc' was as well thought out as your writings have proven to be over time.

The New Django Powered Inked Magazine Website is Up!

2008-01-04T14:13:00.001-05:00

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.

Reflections on 2007, Looking forward to 2008

2007-12-31T21:43:00.000-05:00

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

2007-11-26T23:03:00.002-05:00

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.

2007-11-12T16:52:00.001-05:00

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

2007-11-07T20:46:00.000-05:00

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

2007-10-31T22:40:00.000-04:00

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

2007-10-28T17:55:00.000-04:00

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.

2007-10-13T20:05:00.000-04:00

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

2007-10-10T20:01:00.000-04:00

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.

Perspectives: Moving On to Greener Pastures, with Perks.

2007-10-07T20:00:00.000-04:00

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.

2007-09-25T19:58:00.000-04:00

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.

2007-09-15T19:57:00.000-04:00

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.

2007-09-11T19:47:00.000-04:00

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.

Announcing the CodeDevl.com Podcast

2007-08-21T19:45:00.000-04:00

I’ve been writing on matters of a computer centric theme on and off for roughly 18 years, I figured it was time to compliment my ramblings via a different medium. First and foremost, I do this knowing full well that I post these words more so as an act for myself as a personal journal pertaining to my primary field of interest. Secondly, I post with the hope that a few others may find humour, warnings and/or lessons to learn in what I have experienced.

That being said, I’ll give a basic rundown of what a listener to the codedevl.com podcast can expect. The first dozen or so podcasts will be slightly more verbose variations of the existing codedevl.com journal entries, with the eventual hopes that I will have guest software engineers whom i’ve come to know over the years. I am also making it known that while this site doesn’t currently allow for interactive comments, audio responses are welcome via email addressed simply to eric at codedevl.com.

I appreciate those of you who continue to follow the various happenings and writings (and lack thereof) at codedevl.com, and just want to let everyone know that I do have several things waiting for future release dates.

Future Aspirations.

2007-08-12T19:37:00.000-04:00

I recently had dinner with a previous pseudo-co-worker from my previous contract to catch up on things since parting ways. I say "pseudo-co-worker" because ultimately when one is a contractor, he/she has no co-workers with only the exception of other contractors on the same project for which they were contracted. He works for a software production firm primarily in Java, and that little tidbit of information started me thinking. What I have wanted for all of these years in the profession was to work for a software house.

I know that some of the open source crowd are going to say "why not contribute to new and/or existing open source project?" to which I simply point out that is isn't the same. I have written and distributed code under both the artistic license as well as the BSD license, but ultimately it isn't solely about the code, it is about the environment. Right now, I work in an environment in which there is really one person with whom I can speak and joke regarding code and geekdom in general, and I enjoy that. I do know however, that much like my previous work associate, I want the whole environment, surrounded by other coders of varying capabilities and disciplines.

I'm sure some might imply that I have a sort of fantasy view of these environments, but I beg to differ based upon the opinions of others that I know personally. There is a certain camaraderie in highly skilled engineering/creative homogeneous work place environments which just isn't found elsewhere. If anyone reading this has ever had the opportunity to read any blogs from the original coding group at Netscape or Apple, you'll know full well as to what I'm referring.

I know full well that there are high stress time periods at those companies and that more so those environments are more conducive to non-family-life encumbered employees, but there are definitely exceptions as such.

Either way, back to my friend. I think he pointed out something to me that I feel would me help with my, dare I say, professional environmental depression, that being -- attending programming/tech conferences. Back in 2000, I attended Linux World in New York at the Jacob Javits Center, and then again in 2001. It was a blast, by and far. I do have to say that 2000 was a much better event than 2001 not only because of the IBM sponsored rave, BattleBots, and free (as-in "beer") bar, but because of the people there. It seemed to go quite a bit more corporate in one single year. I met many interesting people during those conventions, and even received several job offerings as well, though I didn't take any, as much as I should've since a few were at software houses. Either way, I've lost my focus of this post, but I can say that I've made it a personal resolution to start heading to more developer related cons, now the questions are, which ones? PyCon? JavaOne? LUG Radio Live (US or UK)? I guess time will tell.

Python's 'Pickle' Module

2007-07-10T19:22:00.000-04:00

Recent changes to the SimulaeObject class have proven to be a big leap forwards in regards to flexible object manipulation for both testing and live environments. The issue at hand was in regards to how to load and/or save object 'types' as it were. Initial thoughts were to go with a simple configuration file which contained each and every object a la something akin to the httpd.conf file from Apache 1.3 (& 2.x?) for handling virtual hosts. Then it dawned on me that this was a mistake which I personally made once before, and was almost about to fall victim to once more.

The solution was sitting right in front of me all along, the standard library's 'pickle' module (or alternatively the 'cpickle' variation for speed's sake). Due to the issues presented in a virtual world simulation the topic of object blueprints and simulation population ease come to mind rather quickly. The best environment for manipulating these new objects will ultimately be via the methods provided by both the the SimulaE package (SimulaE.loadObject(filename_to_load, [optional_load_path]) as well as at the code level in the parent class in SimulaE.SimulaeObject.saveObject(filename_to_save_as, [optional_save_path]).

By going this route it has been realised that a simple loop and/or script-like routine could be used to create all the generic object templates needed for design platforms, and for customisation all one need do is use the loadObject routine, make the necessary alterations and re-save said item as a more concrete, concise and specialised object, named appropriately of course.

Let us take an example of a room type object (more simply put, a larger container object). We'll use simple constructor information here for the sake of staying on focus. We're going to make a 4 metre x 5.5 metre dining room, with a 2.75 metre ceiling, simple called "Dining Room". It will be empty sans an already pickled to storage butler object we've created for the sake of this example (whose filename is simply "butler_jeeves"), though future discussions on SimulaE's container and stack loading methods are forthcoming.

import SimulaE

generic_dr = SimulaE.SimulaeObject(name='Dining Room', width=4.0, length=5.5, height=2.75)

generic_butler = SimulaE.loadObject('butler_jeeves')

generic_dr.addToContents(generic_butler)

generic_dr.saveObject('diningroom4x5.5x2.75wButler')

We now have a pickled version of this generic dining room of the aforementioned dimensions, sporting its own copy of Jeeves the butler, saved to a physical file on whatever storage device we're set to utilise. We can overwrite said object by simply saving the item with the filename as it exists on whatever storage device is in use. There is also the flexibility of specifying alternative file save and load paths with allow for multiple parallel simulations and/or individuals to work in safe separate but equal spaces, very much along the lines of a Unix mentality. Another advantage by working in this manner is being able to create a path full of simulation objects and copy said path en masse for alternative and/or backup purposes.

Either way you slice the pickle (module), it proves to be quite (ful)filling, making one feel quite (programmatically) satisfied.

Java Redux. Redux.

2007-07-07T19:24:00.000-04:00

I was perusing the internet last evening to pass the time before getting into a vicious round of Champions of Norrath : Return to Arms with my lovely wife. I had Java on my mind for a bit of the commute home and as such decided to do a bit of googling. For whatever reason, I decided to lookup “Java for Python Programmers" much along the lines of a great "Perl to Python Migration" book I'd acquired years back. To my utter shock, results were actually returned.

This whole 'ordeal' with Java has been going on with me for something over 7 years. I started teaching myself Java way back when, but found it to be utterly too verbose for productivity, opting for perl in its place. Then perl very quickly proved to be lacking when it came to large projects, and code cleanliness (by design mind you, I have written production code which after 7 years upon seeing it again, was very easy to follow in spite of its 7,000+ line codebase), and utter hackishness about it, regardless of the raw power. I moved to Python both personally and then shortly thereafter, professionally where I enjoy myself most.

However, there are certain things I've come to realise over the past many years, more so over the past few specifically. One is that I should force myself to code in one of the behemoth languages to the point of solid fluency regardless of how dreadfully painful it can be. Two is that most jobs are hybrid these days and require a wider set of disciplines in terms of technologies, languages and toolsets than in the past, and whilst I don't have any need for Java in my current work endeavours, it doesn't negate said need in the future. Three is that Java makes the most sense being that C/C++ are for all purposes outside of hardware tied code (such as operating systems, device drivers, compilers), dead for application creation, period.

And so it is that I venture forth again into the wonderful realm of re-re-learning the evil behemoth formerly known as oak. May she not be as cruel a mistress as in the past as my understandings of her workings have been greatly enhanced thanks to python sharing so many of those conceptual designs and paradigms coupled with my adoration for the latter language.

Wish me luck.

Check External Data/Configurations First.

2007-07-05T19:21:00.001-04:00

I was recently on holiday with my family visiting other members of my family as well as friends. It was at this time I pulled out my trusty MacBook Pro, fired up TextMate, pulled down the newest subversion repository of my simulation software 'SimulaE' and attempted to show my friend the crafty english parser component I wrote. I showed him the test suite with all of its various scenarios and then suggested he throw an attempt at it so that he may be amazed at its crafty logic.

He did, and it failed, and I was surprised to say the last. So given that I was on vacation, I wasn't going to focus must time on this issue other than updating the subversion repository so that I could look into the issue at a later time. Well, two days ago I finally did so, and found out after careful checking that one of the datafiles utilised for cross checking and sub classifications of parts of speech of english lacked the necessary word (also the culprit of the mis-parse). After making a quick addition to the aforementioned lookup file, the test ran just fine, and passed with flying colours.

Lesson learned (for what feels like the millionth time); check your support configuration and/or data files, because your code isn't broken, just doing what it is supposed to, based upon the information it has available (data files) to it.

Present Tense English Parser : Part I

2007-05-26T19:17:00.000-04:00

As part of an ongoing project during which I have been designing, building and testing in one way or another over the past decade and a half, I have arrived as the parser phase. Well, I will correct that statement. I have tinkered with creating parsers before, but thanks to the expressive nature of the Python language, I was finally ready to make a serious attempt at writing an English present tense command based parser. I'm not going to make a massive post about this, though I am going to post the test results.

Note, all the tests pass. What a passing result actually means is this; The parsers job as of version 0.5.4 is to break apart the sentence(s) properly into their components via identification of verbs, conjunctions, prepositions, articles, conjunctions, pronouns and punctuation.

Creating Parser Instance: : Passed

Loading Configuration for Instance: : Passed

Testing for version: 0.5.0

paint the gold bucket black : Passed

get the big , heavy hammer and kill Bob with it ! : Passed

get hammer and squirrel from Bob and then hammer squirrel into the wall . : Passed

get the gold gold : Passed

kill elf and get gold : Passed

paint the bucket gold : Passed

paint the gold bucket black ! : Passed

get gold : Passed

kill elf , get gold : Passed

get the large gold brick . : Passed

paint the bucket gold . : Passed

get the large , gold brick . : Passed

Testing for version: 0.5.1

get rock , pliers , hammer and squirrel and hammer squirrel into the wall . : Passed

Testing for version: 0.5.2

kill the trite little elf with my sword , then wipe the blood off of it ! : Passed

destroy the cantankerous creature before you eat your dessert : Passed

kill the trite little elf with my sword , then wipe the blood off of my sword ! : Passed

kill the trite little elf with my sword . : Passed

Testing for version: 0.5.3

hammer the hammer into the big hammer : Passed

hammer the hammer into the hammer : Passed

Testing for version: 0.5.4

kill the trite little elf with my lavacious sword , then wipe the blood off it ! : Passed

go to the store and buy a new cellphone : Passed

slit Fred's throat and capture the warm , red blood in a cup ! : Passed

play with my toys and listen to my music . : Passed

play with my toys and listen to music . : Passed

As can be seen, the variety of possible inputs for the parser vary from simple to complex, from grammatically perfect to questionable fragments. Being that the purpose of this parse is first and foremost for use in a command environment in which interaction is needed, thus the present tense only requirement. This is a massive relief on the demands of the parser, but even still, it can be see from the above that the system can differentiate key words which can be used in both noun and adjective forms. The system also handle post adjective usage.

The system currently most notably recognises over 9,000 verbs (regular and irregular), 50 prepositions, and a whopping 46,000+ adjectives. A call for test case phrases is hereby announced. I am satisfied enough with the stage one parse process that I hereby am moving on to the second parse stage, that is the creation and order of individual statements (as dictated by their prepositions), in preparation for the third and final stage, in which the parser sends the results from stage two to the action engine. Both those phases will be the subjects of new posts, accordingly.

Thinking in Lisp (with respect to Bruce Eckel)

2007-05-08T19:12:00.000-04:00

It isn't what you might think based solely on the title of this post. Bruce Eckel of www.mindview.net isn't coming out with yet another book prefixed with "Thinking in"... or maybe he is. As far as I know though, he has yet to, nor is he expected to write one on Lisp.

On a quasi-regular basis I make the effort to learn something new in the realm of computing whether a concept, paradigm, and/or language. I decided that given my past experience and interest (since I was considerably younger) in artificial intelligence programming concepts coupled to early leanings towards Prolog, a French born AI/logic language created around the same time as I was back in the early seventies, that it was time to return to my roots. This time around I decided that after being an emacs junkie for so long, that the obviously choice for me this time around would be the Lisp functional programming language.

Now the point of this post is not to go into the semantics of the Lisp language but to stress a more important point which I feel would be of greater value to any and all who might stumble across these pages. Learning to think in Lisp changes the way you think about code logic. I'm a fairly big proponent of OO design and programming, though I ultimately believe in using the right tool for any given job/project. Lisp has a wonderful simplicity about it, a simplicity with a considerable amount of power behind it.

The concept is not unlike Unix methodologies. Simple, small programs which do one thing, but do it exceedingly well, which can then be piped to one another to do larger tasks. Mind you this is slightly different but not by much. Lisp works dealing with functions (and lots of parentheses). You string together multiple simplistic functions together to produce more complex functionality. A simple example might be finding the average of two numbers.

(defun AVERAGE (x y) (/ (+ x y) 2.0))

defun is used to define the function with the given name "AVERAGE", followed by its parameter requirements. The actual body of said function consists of doing a division operation (/) by 2, against the results of an addition function (+) of the two provided parameter.

I feel that this example while a little simplistic does at least point out the basic mindset of Lisp programming, which still hold consistent with my above statement on its likeness to Unix shell mannerisms. While I don't see myself coding entire systems (on a regular basis at least) in Lisp, I do have admit that I'm going to continue my studies on this language as I have been finding that my perspective has shifted thanks to learning this new and different programming paradigm, which ironically isn't new when it comes down to it. It was just pushed aside to make way for the 'next great thing™.'

I heavily recommend some of the freely available books and information on learning Lisp and its concepts as listed below (Note: All items are PDF formatted for convenience):

Practical Common Lisp

Common Lisp: The Language

Common Lisp: A Gentle Introduction to Symbolic Computation

Coding in 'The Zone'

2007-04-26T19:09:00.000-04:00

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

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

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

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

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

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

Simple Rapid Application Development in Python

2007-04-20T19:08:00.000-04:00

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

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

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

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

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

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

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

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

The Importance of Being Passionate About Coding

2007-04-15T19:06:00.000-04:00

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

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

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

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

Updating Existing Perl to 'use strict' Standards

2007-04-04T19:03:00.000-04:00

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

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

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

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

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

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

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

Some Coders that Stand Out in My Mind

2007-04-02T18:56:00.000-04:00

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

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

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

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

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

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

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

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

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

Smells like Perl, Tastes like Python: Perl TT

2007-03-31T17:43:00.000-04:00

My recent procurement of new employment has thrown me back into the hellish world of perl. For those unaware, perl is the dyslexic ginger stepchild of 2400 bps modem line noise, albeit executable and fast. Now don’t get me wrong, I’ve been coding professionally in perl since 1995, and have produced several large enterprise applications that are still in use to this very day.

Perl is a very capable language without a doubt however having used the language for so many years both professionally and for hobby I have become well aware of its faults and shortcomings. This article isn’t specifically about pointing out the many issues perl has, some of which will be addressed in Perl 6 (when it eventually gets released in 2027). Today I am only going to speak of one specific issue which is actually quasi addressed in a set of modules, all relating to the Template Toolkit.

When coding in perl, even adhering to best practices such as those outlined in the excellent book by the one and only Damien Conway, author of the more notable “Object Oriented Perl”, one still finds perl problematic due to too much adherence to the ‘there’s more than one way to do it’ mantra. The constructs are very low-level language based, which makes sense given perl’s humble beginnings but ugly none the less. Some languages which have come into existence after perl have corrected this shortcoming and as previously stated, perl is moving towards correcting some of its ugliness, though a bit late.

The current leading language which not only matches perl’s power in many areas, while exceeding perl’s abilities in others is Python. Its focus on clean form through visually enforced coding constructs along with a more natural syntax which closely follows not only spoken speech but though processes is a testament to language advancements. Which brings us to my main focus of this article, clean syntax in the style of Python, within a perl application.

The perl Template Toolkit by Andy Wardley is the definitive all around powerhouse of template creation systems available within perl. There are many others available but they all pale in comparison especially when you take into consideration the multitude of uses, formats and arenas in which Template Toolkit is competent. This is no mere mail merge replacement library, even though it will do just that exceedingly well. The toolkit is much more than that, mainly due to its wonderful flexibility in its meta language utilised for in-template logic.

This language within a language is also where I happen to draw its direct link to Python whether intentional or not. Good design shines through and it just happens that the aforementioned comparison is dead on. Let us begin with a sample of what I’m talking about but reviewing a simple .tt template from the Template Toolkit website.

[% FOREACH team = teams -%]

[% team.name %] [% team.played -%]

[% team.won %] [% team.drawn %] [% team.lost %]

[% END %]

All of the above would be located in a .tt template file. A dictionary (a.k.a. associative array/hash) is passed called “teams”, containing the named elements of name, played, won, drawn and lost respectively with their associated values. Unlike perl’s “c” style referencing methodologies which is fine and dandy for shell scripting or c programming it is by no means as clean as the more appropriate referencing styles utilised by most modern languages, specifically object oriented languages using the dot format. As a side note, perl’s object system was ripped almost verbatim from Python, though poorly implemented (e.g. implemented with perl’s tmtowtdi mind-set as opposed to a proper object focus with structure and stringency.)

The above code is clean and simple, much like Python. The only exception is the punctuation, which is only necessary as delimiters for the meta language. Thanks to this cleaner approach taken by the Template Toolkit system, we can allow the logic to be cleaner by limiting the perl to only the minimal amounts thus ending up with cleaner overall code, especially handy in the world of cgi and/or form processing.

Let us face facts, of the following, how would you range readability from easiest to hardest.

Python:

for team in teams:

print team.name, team.played + ‘-’

print team.won, team.drawn, team.lost

Template Toolkit:

[% FOREACH team = teams - %]

[% team.name %] [% team.played -%]

[% team.won % ] [% team.drawn %] [% team.lost %]

[% END %]

Perl:

foreach my $team (@teams)

{

print “$team{‘name’} $team{‘played’} -\n”;

print “$team{‘won’} $team{‘drawn’} $team{‘lost’}\n”;

}

The above Python code is simple to understand, even by non-programmers. The Template Toolkit version while a little messier due to the punctuation is still rather clear cut and simple to read, while the perl version adds a significant amount of unnecessary punctuation. What this all comes down to is that if you have to code in a perl environment, there is now a way in which you can produce a cleaner codebase, mainly by keeping the data display layout and logic within .tt template files.

So I commend Andy Wardley and all of those who assisted with this wonderful module (and its associated add-ons) in doing what Larry Wall and crew have been unwilling to do thus far within perl. Dictate flexible standards which avoid the ugliness which has now grown synonymous with perl. If you find yourself stuck in a perl environment, you now have some solace in a place to take refuge courtesy of the Template Toolkit.

Oh, and for those of you who have moved on to one of the the languages of choice at google, Python, there is the ever flexible Cheetah template framework.