Tuesday, January 24, 2012

On Programming Languages

I know several/many programming languages.  I've written code in C, C++, Java, Python, Perl, TCL, fp, bash, ksh, Pascal, FORTRAN, Lisp and PHP.  I have "extensive experience" in perhaps three of those languages - PHP, Perl and Python.  Overall, I've got over 15 years of Software Engineering experience.  Not "scripting"; Software Engineering.

At every job I've taken, I've exceeded the expectations that the people hiring me had for me.  At my last group at Sprint, I got hired as the "script writer".  Within four months, I was the technical team lead.  I was hired to do TCL and Perl scripting.  Within a month I was trying to teach "Java Programmers" how to write Java code.  Oh, they knew how to construct an if-then-else block.  They knew how to connect to a database.  They knew how to write a class and fill it with methods and member variables.  But they had no idea how to design an application.  They had no idea how to build components.  They were forever re-inventing the wheel.  I became the technical lead on that team because I was the strongest software engineer they had.  And I was the script writer.

After a year or so of working on my projects and helping out where I could, I started to tackle some of the fundamental issues the team was facing.  When we deployed an application it required a rebuild.  There were hard-coded references to servers and URIs and file locations that had to be changed when we took code from development and put it into production.  For Java applications, this required a recompile.  So we never tested the code that went into production.  Deployment was always fraught with peril.  So I decided to fix it.  I wrote a set of comparable classes in Perl, PHP, TCL and Java that would all read in information from the same server specific configuration files.  A series of overlays would allow config files to be layer on top of one anther to achieve a state where you could deploy the same code to any development or production machine and it would pick up the right configs - no recompile was necessary.  And all four languages we used could use the same set of config files.  All of a sudden, deployment was a non-issue. 

I didn't write much Java.  A couple of classes.  Hack some method calls into places where we previously had hard coded strings.  But I knew WHAT Java code to write.  I knew how to write it.  And I was able to integrate that code into a diverse environment so that it lived and played well with the rest of what we were doing.  Which was more indicative of a fundamental understanding of Java and an ability to write good code?  The couple of classes that I wrote?  Or the 25 Java servlets that had to be recompiled when it was time to migrate from development to production?  Who would claim "extensive Java experience"?  Who do you want on your team?

Yes.  There is a point to this.  I want to work for Google.  I think I would fit in well.  But they've got this bullet item front and center:

  • Extensive programming experience in C/C++ and/or Java
I don't have it.  I have extensive programming experience.  But I don't have extensive C/C++ or Java experience.

Thursday, January 5, 2012

Housekeeping

Before I get down to the nitty-gritty that is the main focus of this blog, there's stuff I have to do.

First and foremost is to try to organize my life's work.  Over time, I've accumulated code - lots of it.  And over time that code has found its way onto this server or that one... onto this hardrive or that website or this USB keyfob.  I've come to the conclusion that I don't want to try to manage that crap anymore - I want my stuff around when I want it and I want it safe.  Lord knows I've already lost of a crapton of code thanks to various hard drives dying on me.  So I'm done with that.  I want it hosted somewhere where I can always get at it.

Unfortunately, that's not the hard part - thanks to Dropbox.com.

The hard part is finding it; gathering it; extracting it; deduplicating it; evaluating it; and only keeping what's useful and weeding out any proprietary information.  I only want to keep tools and techniques, not business logic.

So... when I left this one particular company, our team had all of our projects stored in a CVS repository that I maintained.  When I left, I jumped onto the CVS server and tar'd up the CVSROOT and brought that with me.  All well and good, I figured.  Now that I'm interested in organizing and evaluating all that code, I find that having it in CVS files isn't the easiest thing in the world to deal with.  I'd prefer to just do a 'cvs export' and be done with it.  Unfortunately for me, the server where the code is now is NOT one that I control and it doesn't have CVS running on it and I don't have the privs to start an instance up.  What's a poor boy to do?

Well, the answer is that you can do a 'cvs co' and tell cvs to look in a particular directory for your CVS files.  That's easy enough:

cvs -d /home/helver/repo co MyProject1

The problem, though, is that cvs expects to find a cvs server running and a lock file present in /var/lock/cvs - and because a cvs server ISN'T running, the lock file isn't present so the command fails.  Fortunately, there's a way around this and it's not particularly intuitive: use the -R switch which tells cvs to assume that the repository is read-only.

When you turn the -R switch on, cvs doesn't try to lock anything and just does what I want it to in this case - extract the latest version of the files from the rcs formatted files.

cvs -R -d /home/helver/repo co MyProject1

And yes, I know I should be using github or at the very least subversion - but that CVS repository is one that I started using almost 12 years ago and it was still CVS when I left that company.  What it is now, I'm not sure.  But I'm pretty sure that none of the code I've got is in use in its current for anymore... such is the march of time...