PyCon 2010

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

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

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

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

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.

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

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

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.  Such heavy use of PHP in this specific application has raised some concern.  I know it was a great idea that filled a niche when it was created, but in its current iteration, it has grown to be something potentially problematic: 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. I will however point out that PHP has been making non-stop strides towards a feature rich set of functionalities of its peer languages, though the battle has been uphill since it entered the ring having only the web server integration has a core plus.

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