tag:blogger.com,1999:blog-65699535963187055762024-02-18T23:02:14.729-05:00CodeDEVL BlogSoftware Engineering Perspectives of Eric G. Elinow :: Miscellaneous personal and professional ramblings about software throughout its lifecycle with a slant towards Python, Ruby, Scala, Unix Environments, Intelligent Agents and Real-World Simulations.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.comBlogger66125tag:blogger.com,1999:blog-6569953596318705576.post-53384837860205822152014-03-17T00:08:00.002-04:002014-06-11T22:35:46.887-04:00In Defense of the Lone Code Archetype - Part 2 (The followup)Roughly half a decade ago I expounded upon the virtues of the lone coder archetype, which was in response to a flurry of "______ is the one-true way<sup>tm</sup>" where said blank could have been XP, Agile, Hierarchically Big-Team Structured Environment, etc. <br />
<div>
<br /></div>
<div>
I feel it necessary to further discuss the situation by pointing out the environments where the aforementioned 'mindsets' (as it were) just do not cut it. I'm not saying that these various means and methodologies don't have their place or purpose. I'm saying that there is no magic solution that fits every environment. </div>
<div>
<br /></div>
<div>
First and foremost let me point out that while I currently find myself working for the corporate behemoth that is Comcast, I have primarily functioned in extremely lean staffed companies/start-ups and I do enjoy the environments regardless of all of the negatives resultant from their miniscule size(s). Many of the methodologies against which I argue as not being the end-all-be-all or one-true-way just simply wouldn't be a great fit for these smaller, faster environments. I'm talking about companies in which there is no QA department. There are no "project managers" outside of those coding individuals doing the coding. There are no dedicated "scrum masters" to keep focus and direction. Turn around time for a project can be anywhere from 18 months for a massive project to as little as 30 minutes for a last minute 'big money deal' directly arranged by the owner of the company. </div>
<div>
<br /></div>
<div>
I can't say that I love all of those really hair-raising tight-deadlined projects, but I can say that I do find myself thriving in such environments while I've watched others come and go, not being able to make the cut in such an unstructured (comparative to textbook scenarios and larger companies) work space. </div>
<div>
<br /></div>
<div>
I don't want to send the wrong idea here though. Proper design, implementation and testing methods need to be utilised, though in many cases the specific type will vary dependant upon the various variables (time until deadline, technical requirements (formal or otherwise), availability of those requesting said application(s) and/or change(s). All I am stating is that talk of scrum methodologies, stand up meetings (even if only for 5-10 minutes tops daily), etc. just don't cut it in these environments. Entire projects sometimes need to be not only designed, but put into production in less than an hour's time while all of the normal daily actions take place.</div>
<div>
<br /></div>
<div>
Before anyone starts to think that "these tiny companies aren't worth it", I will clearly state that with rare exception, all of the aforementioned companies (if only by reference and not by name) have been and/or are rather profitable, more than worth the effort. I will state that I have both seen individuals who whilst highly capable in their own right fail miserably as well as those who happen to be incapable of coping with the frustrations of not doing daily work in a manner conducive to that which they learned in college. </div>
<div>
<br /></div>
<div>
There is ultimately a place for everyone, but for the truly cutting edge companies such luxuries as what would seemingly be order, structure and time frames simply don't exist. It is also a world in which competency pays/paid off for those willing to cope with things during those really hectic moments.</div>
<div>
Now before anyone starts the tirade of "these environments aren't sustainable" responses, I will state that as the companies each find their own groove, the hopes are that there'd be a bit more consistency, planning and structure to what can otherwise seem a bit of guided chaos, though more oft than not, this isn't the case. <br />
<br />
Lone coders fit these environments but are of a specific mould. Those constantly needing direction or looking for hand holding need not apply as these are the kinds of environments where learning the process as well as what are deal makers and deal breakers must be done swiftly because the calls made in all areas from architecture to one-off applications need to be done unapologetically and with the future in mind by said lone-coders. Luxuries such as access to others capable of having half of the answers remains just that, a luxury. It takes individuals of a certain mindset which brings to mind the commercials for the US Marines, which can be equally applied (for different reasons). <br />
<br />
"The few, the proud (albeit questionably mentally unstable though surprisingly effective), the lone coders."<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-53873613806410612352013-08-28T23:03:00.000-04:002013-08-29T11:05:19.631-04:00A Rebuttal to Keeping the Source to Everything One Writes Publicly Available...<div class="tr_bq">
A little over three years ago, I chimed in with my views to an absolutely wonderful article by <a href="http://www.twitter.com/nathanmarz" target="_blank">Nathan Marz</a> on his blog, <a href="http://nathanmarz.com/" target="_blank">"thoughts from the red planet"</a>. It was entitled "<a href="http://nathanmarz.com/blog/how-to-get-a-job-at-a-kick-ass-startup-for-programmers.html" target="_blank">How to get a job at a kick-ass startup (for programmers)</a>" and I do recommend reading this if you have any interest at all with following and/or joining a startup.</div>
<div class="tr_bq">
<br /></div>
One of the points he brought up was regarding maximizing one's personal brand, which included making a website with one's projects listed, links to GitHub repositories, etc. to which I responded in kind:<br />
<blockquote>
<span style="font-family: Verdana, sans-serif; font-size: x-small;"><br /></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">The whole concept of having tons of publicly accessible side projects and/or one is able to just whip them up on a moments notice simply for filler to show abilities is fine and dandy if you're 20 years old. If you've been in the field working for private firms and/or clients for the better part of two decades, raising a family and what not, that isn't going to be your top priority.</span> </blockquote>
<blockquote>
<span style="font-family: Verdana, sans-serif; font-size: x-small;"></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">Much of the code I write on the side is for me and I have released some software here and there, but executables. I share code when I choose to, after all, my creation, my choice. I'm happy to discuss and go over bits and pieces of some of my larger side projects as an example of my capabilities and passion for my art however making the source available just isn't always in the cards and we have seen a very unfortunate change no thanks to people like Richard Stallman who think they have a right to touch someone else's work simply because it exists.</span> </blockquote>
<blockquote>
<span style="font-family: Verdana, sans-serif; font-size: x-small;"></span><span style="font-family: Verdana, sans-serif; font-size: x-small;">In my roughly 16 professional years as a Software Engineer I have worked in companies of all sizes both as an employee and as a contractor. I'm actively part of a startup as well as contracting long term with a group of media companies and in all of that time, I've never had a problem attaining great positions with wonderfully talented people despite not having a git hub account or dumping all of my projects source trees and repositories to the four winds.</span> </blockquote>
<blockquote>
<span style="font-family: Verdana, sans-serif; font-size: x-small;">People need to consider that there are many of us for whom personal time is limited by responsibilities other than code and as much as we might want to dedicate the rest of our breathing moments to making great software for ourselves, we have to settle for doing so on someone else's time. Which is just fine for me, as coding makes me happy even if it isn't my own idea or time on which I'm doing so.</span></blockquote>
<br />
All too often there is this assumption that everything one writes is free for everyone else to see. Just because one codes for themselves does not implicitly mean that they want to give away what they've written, nor does it mean that they want everyone (or anyone else's) assistance and/or input. Many of the personal projects I've written have been lifelong experiments/challenges for my own personal joy and growth. Sometimes it is merely re-inventing the wheel because I feel there is a better way to do so, and sometimes this proves to be correct. While I'm quite glad that there are others out there sharing their creations, primarily those writing languages free for all to use, I do not feel beholden to share everything I create. <br />
<br />
I'm also an artist having sold many paintings in several mediums. This doesn't mean that I want others to take my work and 'mess' with my vision. The personal concept of "mine" seems to be less prevalent with the younger coding crowd these days. This is a matter of personal preference, though when it becomes an expectation, one of communal works and their derivations, I take offense at that assertion. <br />
<br />
I have also been responsible for scouting out, mentoring, interviewing and hiring a number of developers over the years, and while seeing examples of projects they've done can be pleasant, it was never a requirement or of any real factor in my decision making. I've been of the mentality that I don't want someone who knows everything, I want someone who knows how to figure out what they don't know when needed. I'm fairly fond of the method of assessment based on requesting a simple program be provided by the following day in two languages that I choose, that I am sure the applicant has had no exposure, but I digress.<br />
<br />
My primary point deals with this being a generational issue, one that needs to be made more apparent. Passionate developers young and old have a thirst in them, though how that thirst is quenched varies from person to person, situation to situation. Many of the younger developers I know spend much of their personal time coding, which is wonderful, especially in their early careers wherein their experience is less polished. The majority of my friends are hovering around their forties and have families which take priority. That doesn't make the thirst any less present, it simply means that the means by which satisfaction takes place is handled via their paid contracts and/or salaried work. This is all the more reason to find jobs of interest and not simply accepting 'any' position for which one is qualified as there are multiple purposes now being served due to the lack of personal time for such activities.<br />
<br />
As an aside, this does not mean that there aren't those out there balancing family lives and open personal project repositories. It simply means that when assessing potentials for positions, to borrow from <a href="http://www.wall.org/~larry/" target="_blank">Larry Wall</a>'s <a href="http://www.perl.org/" target="_blank">Perl</a> mantra (TMTOWTDI): "There's more than one way to do it." Please keep that in mind next time you're in charge of talent acquisition for any company startup or otherwise.<br />
<br />
<br />
Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-56959976341645467462013-08-19T11:23:00.000-04:002013-08-20T09:23:34.507-04:00The Allure of Small... When I first started out professionally in the ever growing realm of software development, I'd taken a position with a mid-sized company of roughly three hundred and fifty employees. Given that it was my first grown-up gig, I had the common misconception that all companies functioned in a similar manner whether minute or enterprise just at a micro or macro level respectively. I stayed with that company for close to eight years making a multitude of personal and professional relationships along the way. It was only when I'd learned the inevitable fact regarding first jobs, especially applicable to software development in that the pay scale will never equal the amount of information, skills and experience attained even if one were to be at said company for two decades. This being said, I made my exit when I was offered a position a small (less than 10 employees) financial startup in the suburbs of Philadelphia, Pennsylvania. <br />
<br />
The first thing I noticed was that the pace was definitely quicker. This wasn't as glitzy a startup as another at which I'd interviewed (a company called Health Market Science which at the time was in Conshohocken, Pennsylvania) which was far more geek couture. I was brought in to replace the existing PHP infrastructure with perl.cgi at the time (as well as the primary back-end processing scripts critical to meeting banking and fed. regulations in a timely (read daily) manner. The first task with which I was charged was an ETL (Extract, Transform, Load) process from client content to our proprietary Goldleaf accounting software for ACH transactions. This was a good first test and I passed with flying colours. No sooner had I completed that task (in days) did I have a new project for one of the largest online Canadian gambling sites (solely a client, before the days of the prohibition against online gambling in the United States) to write an API for handling client verification via Lexus Nexus (which at the time had a different name which i forget) in XML. <br />
<br />
This had been the first time I'd been required to do anything with XML outside of a parse here or there, once or twice at my former employer for a one off project. This is where I noticed one of the biggest differences between larger companies and leaner, smaller companies. Had this project been part of my tasks at my former employer there would've been dozens of hours of meetings and the project would be measured in a timeline of many months, unlike the three or so weeks it ultimately took from conception through testing to production. It was in this manner that subsequent projects continued for the next four or so years, even with the company being sold and my transition to CTO somewhere in the middle of all the work, and the building of a solid team of mostly college graduates though I was glad to have a slightly more experienced embedded systems developer which while not part of our required skill set definitely had his own approach to issues thanks to his more diverse experiences prior.<br />
<br />
Ultimately, the position ended when the company ran afoul of the US Government due to several of its clients causing issues for the US Postal Inspector and was ultimately shut down. I was quickly snatched up to work on a contract with a Massachusetts anti-fraud retail software house called Retail Expert Inc. (eventually consumed by Tyco's Fire & Safety division.) I was again in a very small, agile environment working with a single other developer building Python (non-web) real-time returns authentication systems for Burlington Coat Factory nationally. This of course was in the context of being part of a larger company ecosystem but the project of allowing for tendered currency refunds on returns as opposed to store credit was really down to a small team outside of both my cohort and myself. This was a contract and it was successfully implemented in time for Boxing Day (December 26th in the US) as expected with great results. <br />
<br />
Having enjoyed working with the smaller companies and their associated dynamic I moved on to another contract with an internet hosting provider with a total of three empoyees (not including myself) in New Jersey working on developing an aging, poorly written Perl codebase. I established best practices, implementing Git version control and a system to push updates to all two hundred and twenty eight servers (at the time) in Python, long before tools like puppet and chef existed. <br />
<br />
I'm not going to continue with my past history at this point because this is about the allure of small, not my entire work history. I would eventually delve back into the world of larger and even enterprise companies (as well as being a co-founder and lead engineer of other startups respectively) as I was testing the waters of what it would be like. To stress my point there were quite a few observations which I have now solidified in my mind, based on my experience. <br />
<br />
Small teams, and small companies while lacking the raw capital (and operating costs) are far more capable of accomplishing tasks at hand. This of course requires a more thoroughly vetted group of seasoned generalists (unlike the specialists more common in enterprise environments) as the importance and value on each individual in these smaller, more tightly knit ventures is much higher. The one bus rule is very much applicable, more so than when the number of employees increases. <br />
<br />
Larger companies have considerably more red tape and seemingly superfluous meetings. I say seemingly solely because it does vary from group to group, company to company. When lack of understanding exists whether of ability, functionality and/or scope, the number of meetings will naturally increase. This is further complicated by logistics of individuals involved from various departments and teams to the point that it can be debilitating. The use of carved-in-stone technologies and the lack of ability to move outside of that realm seems to diminish as the size of an organization grows, primarily due to client contract requirements established early on and the maintenance nightmare which ensues. However this does mean that while a company is firmly built using flat head screwdrivers and hammers, it is very difficult to implement the use of philips head screwdrivers and reciprocating saws when the tasks at hand are much better suited to said technologies. <br />
<br />
It was based on these earliest exposures to what smaller groups were capable of accomplishing, the speed at which they were able to adapt and the focus possible in direct contrast with my personal experiences at larger organizations, coupled with latter experiences whilst dipping my experiential toes into the bigger ponds of enterprise scale that I'd ultimately decided to only approach and work with the former type of companies barring few exceptions.<br />
<br />
The good news is that thanks to the ever growing market and need for the next-big thing, the proliferation of startups and the relatively low cost of entry into emerging markets for crack teams of agile generalists, the future looks pretty bright for myself and my brethren and sistren (yes, that is indeed the correct though fallen-out-of-use word) in the field of software development.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0Southampton, PA 18966, USA40.191911999999988 -75.026066740.094869999999986 -75.1874282 40.28895399999999 -74.8647052tag:blogger.com,1999:blog-6569953596318705576.post-78564877692607400262013-06-26T22:30:00.000-04:002013-06-26T22:47:57.524-04:00The seemingly separate world of tiered development enclaves.I realise the subject of this post is a bit of a mouthful but it was the best I could do to summarise what I'm thinking. In the world of software development there are often a series of cliques based on languages and/or platforms. In other words, we have our Java/C#/Python/Ruby/Erlang/Scala/etc. running on Solaris/Linux/FreeBSD/Windows platforms. There are tight knit groups fervently gathered around almost any combination of those two collections. <br />
<div>
<br /></div>
<div>
The impetus for this rambling is that there are expectations that each group places upon everyone regardless of group. For the Java/C# crowd, as an example, there is an expectation of certain protocols and mannerisms of doing things such as the use of SOAP and XML for webservices or the Python/Ruby/Node.js equivalent crowd touting heavy use of JSON and ReST based systems. </div>
<div>
<br /></div>
<div>
What amazes me is that the more closed in a group, the greater the expectation that the world does everything the same way seems to grow, not shrink. Note that this doesn't imply everyone, just a surprisingly larger number than anticipated (by a long shot). I don't mean to imply this is across the board with no exceptions. People used to working with web services in Java utilizing SOAP and XML seemingly care little (and know less of) the more current alternatives such as JSON and the various frameworks and standards. This is a problem because it leads to an adversarial misunderstanding which I think holds back collaborative situations as well as opportunities to expose individuals into a more cross environment manner of function. </div>
<div>
<br /></div>
<div>
I know that with my near-two decades of professional experience that I have worked in a core of languages (Perl, PHP, Python, Javascript, Ruby, ARexx, Pascal, etc.) with a series of acronym based technologies and formats (JSON, XML, PostScript, YAML, etc.) but that there are people out there flabbergasted to find that I've never had to work with CORBA, SOAP, XSLT, COM or even something as innocuous as certain frameworks whether Cake, Struts, Catalyst, .Net or Seaside. </div>
<div>
<br /></div>
<div>
The reaction is often one of shock and confusion because for so many, the entire world revolves around a solid set of standards, practices, protocols and languages which without, so many would feel like a fish out of water. In reality there are only so many ways to write an 'If loop', or an iteration over objects in an array/list/hash/tuple/set, etc. There are only so many ways to re-implement MVC frameworks or 3rd party libraries. </div>
<div>
<br /></div>
<div>
I often make it a practice to keep current with the langauges, frameworks and protcols of my not-so-close (codebase wise) friends so my familiarity is there, and has actually benefitted me during technical interviews over the years. This ties into what I'm saying, I will come back off of this slight detour. I was at an interview for a perl position at a large development company in the King of Prussia, PA area back in the early 2000's and it involved a 6 hour interview process on-site. I will spare most of those hours but there were two 45-60 minute interviews that stood out. The first was on 'C' followed by 'Java', neither of which I've coded professionally (or personally for any non-learning period of time). Keeping current did help me muster my way through the concepts and what not, albeit barely. <br />
<br />
This is where I bring it back to my original point for this post. A couple of years later down the road during a technical interview for a job in a language/environment which does not have the concept of 'interfaces' (as in the C#/Java sense (to name a couple)), I was asked such a question. I first pointed out that interfaces don't exist in the target environment as it does in C#/Java, and then proceeded to give a crude explanation on how those are used in Java. The sound on the other end of the interview table was subtle but noticeable; One of confusion as to how someone doesn't use such constructs (or the fact that not all languages/platforms uniformly implement the same exact concepts). <br />
<br />
It really comes down to education, in both directions (and I'm not implying academia to be clear). Engineers should be able to keep their familiarity with other languages/platforms current enough to be able to understand those difference between both their local toolsets and those of everyone else (to a reasonable degree). Just because I don't code in Scala professionally doesn't mean that I shouldn't read articles about Scala's 'traits', or that I should ignore a different write-up on Groovy on Grails despite not using Groovy or Grails. <br />
<br />
This also means that those engineers of the Microsoft stack should at least familiarise themselves with what Django is, a bit of Rails, maybe some PHP and Perl, a little bit of Lua and Lisp/Clojure/Scheme, etc. In a former situation I ended up taking the development lead in a Microsoft heavy envioronment writing Classic ASP for the first (and preferably last) time, so I've practiced that which I preach. Knowing some of the pieces that differentiate the languages also give insight into work and processes that may be missing from our own stack(s). Our corpus of knowledge collectively shouldn't have such extreme gaps from discipline to discipline because it as a whole divides us from possibly creating the next big thing as well as (maybe more importantly so) fulfilling our individual potentials as developers/engineers/creators.<br />
<br />
So take this as an opportunity to visit that neighboring x/y/z technology users group, maybe even a smaller convention/conference to get uncomfortable yet ultimately expand one's own horizon and knowledge-base. Only good things can come of this. Continuous improvement doesn't solely refer to processes and applications but people as well.<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-41842355433128202132013-05-28T00:58:00.001-04:002013-05-28T00:58:07.654-04:00They Say That Time Will Tell.. Ruby Revisited - Part IVI've written on multiple occasions regarding my flirtations with Ruby (the language) and my ultimate feelings of it falling short of the mark. I first experimented with Matz's creation in 2003, some 8 years after his initial release. My first foray was not for professional purposes, but exploratory as a means to best express what would eventually become the SimulaE project which I ultimately crafted in Python. I did end up writing a machine learning/route optimisation experiment mimicking hospital utilized medicine delivery robots I'd seen at Abington Memorial Hospital in the prior months. <div>
<br /></div>
<div>
My conclusions were that Ruby was still too TMTOWTDI than I'd liked. It all smelled heavily of Perl, which after using for almost ten years (at that point) was less than desirable. This was long before Rails existed, and it would be another five years before I took another serious look at the language (post Rail's introduction and the famous screencasts which accompanied it). </div>
<div>
<br /></div>
<div>
Yet here I am five years further down the road from my last foray with the language named fondly after a gemstone. At this point, I've been coding professionally for over eighteen years, and in general for well over three decades. I've grown up quite a bit and realised that it was my own issues and pig headedness along with some errant expectations which led to me ignoring Ruby and embracing Python at being closer to the hypothetical "one-true-language."</div>
<div>
<br /></div>
<div>
Years of writing in the BDFL's (Guido van Rossum) creation stemming from the ABC language has done wonders to clarify my deeper understanding of engineering principles, clean code design as well as inconsistencies and even MVC frameworks (Django from v.96-v1.4+). I believe that it was actually through my understanding of Python interspersed with larger monolithic projects in Perl that drove to my moment of clarity regarding Ruby. </div>
<div>
<br /></div>
<div>
Don't get me wrong, it wasn't solely the above which led to this epiphany though. What really finalised it for me was the wonderful <a href="http://www.rubyrogues.com/" target="_blank">Ruby Rogues</a>, <a href="http://www.freelancersshow.com/" target="_blank">the Ruby Freelancer's Podcast</a> and various other podcasts involving <a href="https://twitter.com/cmaxw" target="_blank">Charles Max Wood</a>. The sheer vastness, diversity and information, knowledge and experience sharing within the Ruby community caught me... hook, line and sinker. Note: This is a different community (from my own observations) than the Ruby community of Christmas Past as 'eloquently' espoused by the always-blatantly-honest-with-words <a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDEQFjAA&url=http%3A%2F%2Fzedshaw.com%2F&ei=pTekUZbODab84AOA2IHgDQ&usg=AFQjCNERykxxnPaHkrYq6mOwjapKxeo3Lw&sig2=rOCFH-BghnDWCyrSla4XXg&bvm=bv.47008514,d.dmg" target="_blank">Zed A. Shaw</a>.</div>
<div>
<br /></div>
<div>
I won't go into the details about what it is in general that made me finally get Ruby this time around but I will say that the recent improvements in the language as a whole and the more natural flow of constructs and method chaining resonate with me as a engineer and polyglot. The efficiency of :symbols, the consistent smalltalk based mannerisms regarding method invocation and lest we forget the flexibility of code blocks. I simply leave the reader with this. Check out the links I've provided. Listen to the podcasts, try some of the exercises and give an honest assessment of what Ruby has to offer. I'm really glad I did and now wholeheartedly look forward attending the next Ruby convention which avails itself to my schedule. </div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-27624568215905470882013-05-06T04:30:00.000-04:002013-05-06T11:48:08.531-04:00Invoking the inner Howard Roark, for the Sake of one's sanity.I was listening to episode 059 of the Freelancer's Podcast (formerly the Ruby Freelancer's Podcast) during which the discussion of handling burn-out arose. That issue in itself hasn't been a matter for me for many years as I've learned how to balance work/personal/familial/etc time quite a few eons back. It has even been referenced from other associates and one fairly recently (see: Tal S. Raviv's "Customer's Over Code" blog from the founder of Ecquire.com at http://talsraviv.com/2012/10/21/burning-out-startup-founder/), but it did get me thinking.<br />
<br />
What really stood out about this podcast was how on-the-ball the hosts seemed to be regarding controlling expectations and ensuring a balance in one's life vs. work. You are not your job, though that's not to say you cannot be passionate about it, or that it doesn't play a role in who you are as that would be a blatant lie. In our profession (I cannot speak to others' professions) I have seen time and time again the level of life breathed into both companies and projects alike with all the eagerness to continue efforts with a constantly renewed sense of vim and vigor. Again, this is not a problem. The problem is when factors take all that is good in these delicate balanced recipes and throw the odd spanner in them, messing up the works.<br />
<br />
For sake of argument, I'm going to give two examples of environments non-conducive to keeping that balance of personal/work and ultimately happiness and what it takes on the personal level of the engineer/developer/insert-professional-role-here to make it work.<br />
<br />
Firstly we start with the bad: company F. This company is a large established corporation with a half-billion dollar annual revenue and a considerable amount invested in technological infrastructure. The core problem? At it's core a system that was written by a non-developer some two decades ago that served its purpose in smaller scale but when retrofitted to grow to the demands of a huge system against its design required a staff of fire-fighters. Sometimes this happens but it usually involves a means of correcting the core issues not just throwing more fire-retardent chemical upon its base. <br />
<br />
Company F is further harmed by sentimentality and assumed-correctness by the original developer, now a executive member, which has caused questioning of said codebase to be verboten. Compound this furthermore by developers, many on the team who are quite capable and talented not knowing how to say no. This lead to an expectation of 60-80 hours a week being the norm which is contrary to all of the known credible studies which show effectiveness diminishes substantially and error-creep rising sharply after a certain amount of hours in a given day be applied directly to development functions. Self respecting developers who are worth their résumés' contents don't fear for their jobs as if it is the only one available to them. They don't stay in situations where this is such an unwillingness to make the necessary changes to a core system is present due to one individual's sense of emotional connection to what they feel embodies their greatness/mental superiority from days long past. Good developers and engineers recognize the situation for what it is and leave for greener pastures or they self-immolate trying to play role of code martyr/firefighter.<br />
<br />
Secondly we come to a whole different beast: company E. This is a much smaller company but of the same age as Company F albeit with an annual revenue at a dwarfed 2.5% of the former. Company E was a brick and mortar business which traded hands via acquisition through the years and despite having a technology infrastructure, it lacks any actual capability in its development department's management. A tar-pit that many older company's have falling into has been similar to this: Making a conservative move into development in-house but re-positioning unqualified individuals into decision making roles and leaving them there for so long that they have no only garnered an unwarranted reputation for having skills they never acquired, but they start to believe they are on-the-ball and a player in the field.<br />
<br />
This is one of the most dangerous scenarios one usually encounters (in most any field). Someone who knows just enough of the bare minimum to be horribly dangerous because they can sound like they know what they're doing to the higher levels of management that are clueless on matters such as this. This leads to some very large sins in the industry, over promising product and providing timelines which have no basis in reality. These are company relationship killers. This is a scenario where the individual making the decisions think they know when in reality they are the least knowledgable, yet their wield a title (and that air of knowledge wrongly attained over time via entropy of concern by those around not directly in the field). <br />
<br />
The solution that mentality leads to is similar to company F's perpetual firefighting, but worse on several points, primarily being a smaller player in the field therefore being more fragile if deadlines are missed and secondly, though equally as important is an expectation of the all-hands-on-deck (lack of) work ethic also in perpetuity. This leads to low morale, a complete lack of trust and a decline in productivity overall. Software developers/engineers are smart individuals and some of the largest technical companies have realized this so far to the point of letting the animals run the zoo (removing managers) with generally greater success. <br />
<br />
Where am I going with all of this? Expectations work both ways, and they must be managed. This is where the Howard Roark reference comes in (for those not familiar with "The Fountainhead" by Ayn Rand from their high school or college days). In this profession there is oft times a dichotomy between managers and engineers who are ultimately trying to accomplish the same end goal. All too often it is at the expense of the creator/engineer/developer by those who gain their positions of prominence through abuse of that relationship and a one-sided over-bearing controlling of expectations. <br />
<br />
How did I get here from where I started this post? In the Freelancers podcast, it was stated something along the lines of "I inform my team members/company with whom I'm contracting that I have obligations and will be leaving at 6pm sharp." I too have these obligations and have made it very clear over the years (especially as I grew in my abilities and experiences) that while I have a love of building great product, and that I am paid to make money for those to whom I've contracted, that I also have other responsibilities that I hold of equal or greater value and will not allow those to be intruded upon. I am also not saying that there isn't any flexibility, and I say this as someone who worked for three startups simultaneously whilst raising a new born, I can personally attest to having slept consistently under four hours nightly for over a year's time. I put in the necessary time, but I have a heavy say & input on when that additional time is implemented due to my other highly valued responsibilities.<br />
<br />
On a related note, every time I hear a junior developer offering their own personal time (on a regular basis) to finish a project or start a new one I get frustrated. They're being played for a fool and those doing the playing (the managers, etc.) will reap rewards for the other's 'dedication' and uncompensated offering of time and energy. A pat on the back or a $10 gift card for what in billable hours would total something closer to $750.00 is an insult. Atta-boys are nice, but not at the expensive of dignity lost due to failure to accompany said praises through proper reimbursement financially.<br />
<br />
We must hold steadfast to principles that guide us for our own health's sake, our sanity and our livelihoods respectively. This requires being willing to turn down the great sounding contract, or resigning from a role wherein that kind of abuse of working relationship has been introduced. When we're younger with less of a portfolio, knowledge base and considerably more naïve, we see this as a rather scary suggestion. It is only once time has passed, that many of us realize that we're the ones with the power as we have the skill set that solves the problems, produces the great product and ultimately wins accolade's for & from our client(s). We need to continue to demand the compensation for the fruits of our labours and not let that compensation be seen as a benevolent gift, guilting us into indenturing ourselves to do further uncompensated works out of some emotional bondage. <br />
<br />
We need to see ourselves as the professionals we are. This does not come without us as individuals demanding the respect for our roles and capabilities that we indubitably possess. We can do great things and overcome seemingly insurmountable tasks/projects but for the sake of our respective individual health, sanity and our art, we must do it on equal footing, not someone else's unrealistic dictated terms. We are all business people forming contracts with one another, it is simply up to us to ensure that we're not getting the short end of the stick and even more so important to ensure that the individuals on the other end of those contracts know this as well so as to end this abusive cycle of unrealistic expectation and abusive of professional relationships.<br />
<br />Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-6190962865397364012013-03-22T13:14:00.000-04:002013-04-16T16:45:43.150-04:00Why Defined Coding/Operational Standards Matter in Modern Software Engineering Environments<span style="font-size: large;">A</span>fter a brief stint in the hellish 1990's world of programming in Perl for a half-billion dollar company for a few months before the realisation that it was indeed a living code base designed and maintained (I used the word loosely) as if it were still two decades prior, I accepted a new client in the position of Lead Software Engineer & Architect at a local company in Montgomery County, PA, USA. <br />
<br />
<span style="font-size: large;">M</span>uch akin to what I experienced at the aforementioned company, I found myself in a microcosmic variant of my former employer save for the fact that the system I am to replace is written in ASP Classic on an older IIS windows centric system. <br />
<br />
<span style="font-size: large;">T</span>hese situations are not at all uncommon in the real-world, and hopefully they are diminishing at an increasing rate. This is not me condoning the carte blanche manner of always re-writing an existing system from scratch whether than includes changing the existing infrastructure (for better or worse). Each instance/environment must be assessed individually along with company goals, available budgeting and forecast to ascertain whether or not such an approach is viable. <br />
<br />
<span style="font-size: large;">B</span>ringing this back to the core reason for this post is that a well defined coding standard didn't exist for either environment, not to mention a revolving door of people assigned and/or employed which had a hand in touch either system. Both environments differed in that one was a fairly modern agile approach with daily scrums, open communal work spaces and solid department leads for projects and that the other was very much waterfall design based, separated (officed) individuals with little communication and a lack of leadership in terms of working environment understanding (though a solid understanding of the business logic and customer relations carried this disconnect for without it, all would have faltered). Neither environment possessed nor utilized any semblance of coding standards.<br />
<br />
<span style="font-size: large;">W</span>hat kind of standards are we talking about here. The whole gamut is my best response. How are function names derived, how are attributes accessed, how are constants, classes, variables, methods, etc. named (verbs for methods, ambiguous/nonsensically, etc), typed (cAmElCaSe, alllowercasewithoutbreaks, properly_divided_with_underscores, ALLUPERCASE, MixTUREoFMeans, wthtvwls, etc.). No set rules for braces or brackets (K&R vs same line), indentations (2, 4, tabs, spaces?). Lengths of lines, length of method calls before being broken down. Use of native data constructs. Rampant string concatenation and massive use of type casting instead of a well kept control of expected content. Complete lack of logging and little if any use of exception handling (where available). Poor hiring practices which allowed for a single point of decision to be made either based on a inconsequential question about the language du jour at a given company or because the hiring manager lacks any breadth regarding software engineering both in practice and theory and does not do group interviews with potentials as a precautionary measure. Lack of enforcement (or implementation at all) of code versioning systems/controls, proper QA practices, etc.<br />
<br />
<span style="font-size: large;">A</span>ll of those situations were (and still are) prevalent in the existing systems, as well as many more which I will not get into now (solely because there isn't enough brain bleach to forget that they still exist.) What I can do is point out that because of the lack of all of the above, both companies (while still in existence):<br />
<br />
- Find themselves over the years running into longer lead times for changes which would otherwise be quick and simple. <br />
- Experience bug fixes which require lead times of weeks due to lack of documentation, version control, communication amongst peers and of course proper reviews up front before production pushes. - Struggle to keep current due to lack of faith in the infrastructure of existing systems that any new code would cause massive breakage and production down time.<br />
<br />
<span style="font-size: large;">T</span>his is never the way to run a company and after roughly two decades in the field professionally, it is disheartening to have to endure. There is a light at the end of the tunnel. The former company mentioned has a few good remaining people that provide a glimmer of hope for change in the right direction if they can convince the powers that be (ego and all) through all the crimson coloured tape that these changes are necessary which could lead to the arduous process of modernizing. The latter company referenced has already made that investment both with full ownership backing down the entire hierarchy of the org chart, and in that case, influenced heavily by yours truly. I see much greater things for that latter company because it has done the realistic self assessment and see that much is lacking, ultimately choosing to do something aggressive to resolve the situation with a great outlook towards future business. <br />
<span style="font-size: large;"><br /></span>
<span style="font-size: large;">H</span>opefully we can see more and more existing companies learn from these examples before they find their up and coming competitors who embrace a method to their madness soaring by and taking their bread and butter in the process.<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-33388105638112598572012-06-15T17:29:00.000-04:002013-04-16T16:44:24.163-04:00Rediscovering an old friend, Perl.It has been over half a decade since I was paid to code in Perl, having since moved on to Python amongst other languages. I use the past tense because this is all changing once again. Due to circumstances that are almost entirely personal-life related, I find myself moving on from <a href="http://www.yorn.com/" target="_blank">Yorn</a> after the past fifteen months of doing great things with wonderful, intelligent and foward-thinking people. <br />
<br />
After months over two months of screenings, phone interviews and an on-site meeting, I have accepted an offer as Production Lead Engineer at <a href="http://www.fanatics.com/" rel="nofollow" target="_blank">Fanatics, LLC</a> at their Conshohocken, PA facility. I'm going from working in a Python/Django environment for the past half decade plus into a more systems/internal middle-tier/core environment based on an old friend, Perl. And despite some of the issues which led to this change, I'm wholeheartedly looking forward to it, and here's why.<br />
<br />
As we grown our personal knowledge in a specific discipline, in this case programming languages, our perspectives and approaches mature. When we step away from our comfort zone into some new experience (or language in this case) as I did professional when I moved on to Python as a requirement of Retail Expert Inc, CTO (at the time) Andrew Sernekos, I shifted mentally and learned the way of the Pythonista. As the years progressed it became the 'one true way' of thinking, which was fine given that my language dictates were in-line with my choices and professional tasks. I had put aside my TMTOWTDI (there's more than one way to do it) mantra from my Perl Monger/Perl Monkish days of yore. <br />
<br />
Refreshing my skills back into the primary language through which more than half of my professional career was built, Perl, has opened my eyes in a way not previously possible. The memories I had of Perl with its heavily flexible manner/varieties of expression had originally left a negative taste in my mouth but now having disciplined myself cutting through Python, Groovy, Scala and others has proven to expand my view of what Perl truly holds in terms of power. With great power comes great responsibility and now with the modules from CPAN such as Moose and its derivatives (as an example), the future is looking quite fascinating again for me with a language that has been around now for 35 years. <br />
<br />
Here's to the joys of the future and best wishes for the incredible team at Yorn as a sail on to my next contractual adventure.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-85195385044931784562012-01-08T20:44:00.000-05:002012-01-08T20:44:10.625-05:00Theorising vs. Doing<span style="font-size: x-large;">O</span>ver 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. <div>
<br /></div>
<div>
<span style="font-size: x-large;">I</span> 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). </div>
<div>
<br /></div>
<div>
<span style="font-size: x-large;">T</span>his 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. </div>
<div>
<br /></div>
<div>
<span style="font-size: x-large;">T</span>he 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.</div>
<div>
<br /></div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-73677324559622986002011-03-24T08:41:00.000-04:002011-03-24T08:41:32.720-04:00New environments (mentally) as it were... (a.k.a. something old, something new)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 <a href="http://www.yorn.com/">Yorn, LLC</a> 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, <a href="http://www.ecquire.com/">Ecquire</a> has proven to be a necessity for my sanity. <br />
<br />
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 <a href="http://www.yorn.com/">website</a> or <a href="http://www.ecquire.com/">Outlook plugin</a>, 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Times have changed and the future is looking brighter and brighter. <a href="http://www.ecquire.com/">Ecquire</a> & <a href="http://www.yorn.com/">Yorn</a> 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.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-69633092665397252472011-02-03T14:35:00.001-05:002011-02-03T14:35:26.971-05:002011 and my prospects... 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.<br />
<div><br />
</div><div> 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 (<a href="http://www.yorn.com/">yorn.com</a>), and Gabriel Weinberg of the amazing search engine DuckDuckGo (<a href="https://www.duckduckgo.com/">duckduckgo.com</a>) which protects our privacy.</div><div><br />
</div><div> 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. </div><div><br />
</div><div> 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.</div><div><br />
</div><div> 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. </div><div><br />
</div><div> 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. </div><div><br />
</div><div> 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.</div><div><br />
</div><div> 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. </div><div><br />
</div><div> 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.</div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-69453596148999743022010-09-27T00:37:00.000-04:002010-09-27T00:37:33.948-04:00Romanticisation, Research & RealityAs 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...<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-28864230721652729542010-08-13T00:27:00.001-04:002010-08-13T00:28:29.198-04:00The Usefulness & Addictive Nature of Multiple DisplaysIt 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.<br />
<div><br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJy8uI_6HXhaI0REJXYMx6Ybb1nCgEr5rHNyiYc3Nb4_8tOo_hWvCEKBb4POZoKJbc7ISvMcAgM3jg0NhbqeR9ttmnbafD63M5wxHjJ2qe4BnN_MfbzHzl7lHqJIcUAuTboswrqeNDDufV/s1600/five_displays_ege_640x480.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="476" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJy8uI_6HXhaI0REJXYMx6Ybb1nCgEr5rHNyiYc3Nb4_8tOo_hWvCEKBb4POZoKJbc7ISvMcAgM3jg0NhbqeR9ttmnbafD63M5wxHjJ2qe4BnN_MfbzHzl7lHqJIcUAuTboswrqeNDDufV/s640/five_displays_ege_640x480.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Five displays : One 1920x1080, Two 1920x1200, One 1280x1024 and One 480x800 :: 8.4 Mega Pixels in All</td></tr>
</tbody></table>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.<br />
<br />
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.<br />
<br />
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.). <br />
<br />
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. <br />
<br />
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?<br />
<br />
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.<br />
<br />
Till next time...</div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com4tag:blogger.com,1999:blog-6569953596318705576.post-31769846173445289122010-04-16T23:34:00.000-04:002010-04-16T23:34:24.458-04:00The Romanticism of Internet Startups. My experiences, part I.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, <a href="http://www.ecquire.com/">Ecquire</a>. 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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.<br />
<br />
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. <br />
<br />
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. <br />
<br />
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!Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-20489262388864844482010-03-19T01:42:00.001-04:002010-03-19T01:55:12.492-04:00What's In Your Dead-Tree-Format Library?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.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj54vFxg2IY_-z80DPKW9GJ9RN6NikaJvtP3NMOlihEcZaWlG_o2SiRYKuq0xUmTge3GRTEnG0AiiFiYvaCknlS0JPDdsEs-XF4FBcK57h5IW8RN6vFy_vM4rnn4v_LJQqYM1_CEVNNov4u/s1600-h/bookshelfx600w.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="540" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj54vFxg2IY_-z80DPKW9GJ9RN6NikaJvtP3NMOlihEcZaWlG_o2SiRYKuq0xUmTge3GRTEnG0AiiFiYvaCknlS0JPDdsEs-XF4FBcK57h5IW8RN6vFy_vM4rnn4v_LJQqYM1_CEVNNov4u/s640/bookshelfx600w.jpg" width="640" /></a></div><br />
Top shelf first, going left to right:<br />
<br />
<u>The Linux Database Bible</u> :: 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.<br />
<br />
<u>Python Essential Reference, 2nd Edition</u> <i>::</i> 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.<br />
<br />
<u>Python Cookbook</u> <i>::</i> 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.<br />
<br />
<u>Python Pocket Reference</u> <i>::</i> A simple reference mostly useful for the "batteries included" libraries.<br />
<br />
<u>Python Programming Patterns</u> <i>::</i> 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.<br />
<br />
<u>Perl to Python Migration</u> <i>::</i> 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.<br />
<br />
<u>Pro Django</u> <i>::</i> 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.<br />
<br />
<u>The Definitive Guide to Django, 1st Edition</u> <i>::</i> 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.<br />
<br />
<u>Practical Django Projects</u> <i>::</i> 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.<br />
<br />
<u>PHP and MySQL Web Development</u><i> ::</i> 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.<br />
<br />
<u>Setting up LAMP</u> <i>::</i> Same as above. <br />
<br />
<u>PHP Solutions</u> <i>::</i> Ditto for this book as well.<br />
<br />
<u>Pro Drupal Development</u> <i>::</i> 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.<br />
<br />
<u>Programming PHP</u> <i>::</i> 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.<br />
<br />
<u>PHP Pocket Reference</u> <i>::</i> This also was provided to me with the Programming PHP book.<br />
<br />
<u>Programming Ruby, 1st Edition</u> <i>::</i> 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.<br />
<br />
<u>Programmers at Work, 1st Edition</u> <i>::</i> 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.<br />
<br />
<u>HTML 3</u> <i>::</i> 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.<br />
<br />
<u>The Pragmatic Programmer</u> <i>::</i> 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).<br />
<br />
<u>OOP Demystified</u> <i>::</i> 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.<br />
<br />
Middle shelf second, again from left to right:<br />
<br />
<u>Open Source Development with CVS</u> <i>::</i> 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.<br />
<br />
<u>Practical C Programming</u> <i>::</i> 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.<br />
<br />
<u>Teach Yourself C++</u> <i>::</i> 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++.<br />
<br />
<u>Learning Java</u> <i>::</i> 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.<br />
<br />
<u>Head First Java</u> <i>::</i> 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.<br />
<br />
<u>Java in a Nutshell</u> <i>::</i> Standard fare O'Reilly reference book, though drier than others and while laid out clearly, something felt amiss.<br />
<br />
<u>Core Java</u><i> ::</i> 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.<br />
<br />
<u>Java2</u> : A Beginner's Guide <i>::</i> 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.<br />
<br />
<u>Javascript, The Missing Manual</u> <i>::</i> 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".<br />
<br />
<u>Linux Programming</u> <i>::</i> Also bequeathed by my ex-wife's famliy.<br />
<br />
<u>Linux in 10 Minutes</u> <i>::</i> ibid. See above.<br />
<br />
<u>Turbo Pascal, 3rd Edition</u> <i>::</i> 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.<br />
<br />
<u>Perl 5 Programmer's Reference</u> <i>::</i> 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.<br />
<br />
<u>Learning Perl Object, References and Modules</u> <i>::</i> Essential reading for any non-purely functional code to get written when subjected to perl environments.<br />
<br />
<u>Programming with CGI.pm</u> <i>:: </i>Nothing says well engineered than written by an engineer at Jet Propulsion Laboratories.<br />
<br />
<u>Programming the Perl DBI</u> <i>::</i> Anyone doing anything with databases in perl, will benfit from this thin yes most definitely useful book.<br />
<br />
<u>Perl Best Practices</u> <i>::</i> I pick this up after reviewing another copy at an Internet Hosting firm for which I did someork..<br />
<br />
<u>Object Oriented Perl</u> <i>:: </i>Damien Conway's opus for Perl and Object Orientation. Explains limitations and information for making robust Django.<br />
<br />
<u>Practical PostgreSQL</u> <i>::</i> Acquired when the original plans for some of my publishers dontnet<br />
<br />
Bottom shelf lastly, contains my spoken language reference library which contains books on:<br />
<br />
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!). <br />
<br />
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.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com3tag:blogger.com,1999:blog-6569953596318705576.post-4054383028485292492010-03-09T23:59:00.001-05:002010-03-10T00:00:32.336-05:00The Greying of an EngineerMy 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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
3. There are is a lot of talent out there, but it has nothing to do with youth vs. older coders. <br />
<br />
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.<br />
<br />
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.<br />
<br />
Given that my goal was to post this before my birthday comes, I'm ending it abruptly here. Till my next post.. -EricAnonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-67216967223948204982010-01-28T23:19:00.007-05:002010-01-30T01:17:09.876-05:00You kids get off my lawn! (oh, and the Apple iPad)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. <div><br /></div><div>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.</div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>Thoughts?</div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-43613312491023493982009-09-30T23:39:00.002-04:002009-10-01T00:29:18.584-04:00PyCon 2010I 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.Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-64166206686605180272009-08-28T02:08:00.005-04:002009-08-28T02:52:34.622-04:00Update to Post Regarding Hacking & Ruby<span class="Apple-tab-span" style="white-space:pre"> </span>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). <div><br /></div><div>#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.</div><div><br /></div><div>#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.</div><div><br /></div><div>#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.</div><div><br /></div><div>#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.</div><div><br /></div><div>#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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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. </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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...</div><div><br /></div><div><br /></div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com1tag:blogger.com,1999:blog-6569953596318705576.post-66446500533478515972009-08-26T00:18:00.004-04:002009-08-26T00:47:34.345-04:00Ruby & Project Realisations<span class="Apple-tab-span" style="white-space:pre"> </span>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. <div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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. </div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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. </div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I'll keep everyone informed. Until next time..</div><div><br /></div><div> -Eric</div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-35717731138638914352009-07-25T22:39:00.003-04:002009-07-25T23:18:41.688-04:00New Development Machine OrderedAfter 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. <div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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). </div><div><br /></div><div>More on the new workstation forthcoming.</div><div><br /></div><div>Eric</div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-88128442431872793212009-06-13T01:46:00.006-04:002009-06-13T02:46:32.563-04:00Enforcing the Software Engineer Archetype & Related PrinciplesIt 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. <div><br /></div><div>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. </div><div><br /></div><div>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'. </div><div><br /></div><div>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.</div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-82376086948039993002009-03-10T22:48:00.005-04:002009-03-13T22:25:15.226-04:00New 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:<div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div>There are several major concerns here when juggling this many projects, but thankfully there are just as many solutions:</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Problem #1: Keeping focused on a specific code base.<br /></div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.<br /></div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Problem #2: Estimations and management of many projects for multiple clients.<br /></div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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 <i>x</i> minutes, in reality the time frame would be closer to <i>x</i><sup>3</sup> 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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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. </div><div><span class="Apple-tab-span" style="white-space:pre"> </span> 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.</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.<br /></div><div><br /></div><div><br /></div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-15245222742796278462009-02-13T14:51:00.002-05:002009-02-13T15:13:49.659-05:00Guiding 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.<div><br /></div><div>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. </div><div><br /></div><div>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. </div><div><br /></div><div><br /></div>Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0tag:blogger.com,1999:blog-6569953596318705576.post-4751524531295715202009-01-22T16:05:00.004-05:002014-07-16T00:39:36.494-04:00Dealing with Horrible Legacy Code<div>
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. </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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). </div>
<div>
<br /></div>
<div>
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.) </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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.</div>
<div>
<br /></div>
<div>
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:</div>
<div>
<br /></div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- ambiguous variable names</div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- includes of code snippets where objects should have been </div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- nested structures 4+ levels deep</div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- very few if any comments in the code</div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- very little meaning in those few comments that actually pass as informative. </div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- non-sensical file hierarchy for modules, includes, etc.</div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>- hardcoding of parameters in both equality tests and branch based if statements. </div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>& much, much more.</div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
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. </div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
recent job, nasty code built hackish bit by bit, quickly<br />
<div>
<br /></div>
<div>
no comments</div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16451622453051895259noreply@blogger.com0