Online Chat

Use the window below to chat with me (if I'm online ...)

Use the edit nick field above to let me see your name.

cazh1: on Business, Information, and Technology

Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...

Sunday, November 06, 2005

Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies

Code Mover / Transport: Managing source, environments, and deep-diving into multiple technologies

I remember a meeting from earlier this year, at my old employer. We were reviewing a custom-built "Code Mover" that managed a fairly complex number of environments (Development, Test/QC, Simulated Production/Volume Test, Training, and Production), all on multiple servers (we implemented a middle tier of load-balanced telnet servers so we could insulate the database processes from the Really Big Memory demands of the client).

I understood all of the things they were doing at a global level, but thought we had overcomplicated some things at a micro level. Part of this was different programmers thinking differently; also, I realized the "architecture" was built to support how the developers were going through their debug / problem resolution cycle, and how they managed versions of the source code. We (developers) all tend to emphasize different areas / processes, and we all clearly understand our way as The Best Way.

Now that I'm ramping up for a series of new projects, I am empathizing a bit more with the "complexity", and as I create my own super-flexible, multi-platform Code Mover, I am actually stealing some of the design ideas and features. My favorite is the automatic archive of previous versions of source / code / files before the move; slightly different than using a source code repository, this is more like an automated snapshot for disaster fallback (those "oops" moments).

Of course, I've seen multiple methods for doing "transports", as my current employer calls them. None really right, and I know some of the scripting I am doing could be accomplished with other means. The key is that I am using this problem set as an opportunity to learn Apache, PHP, Perl, MySQL, and possibly even Ajax; the code will be complex and meaty enough to be interesting, common enough that it will be relatively easy to find reference material, and personal enough that I won't feel compelled to share the whole thing with the world.

<aside>This site is definitely excellent reading for the thinking developer. Two great posts that really show how he gets it - both about mental laziness in the programming set. I've never seen programming by intellisense called out before, and I have had enough hands-on with Visual Studio to get used to it. Also, Try It and See solutions - another concpet that you get immediately when you've been there.</aside>

The key for me - I need to automate a number of relatively complex, yet repetitive and tedious, processes so I can turn over higher-quality stuff in less time. Plus, I'll have a significantly deeper understanding of these tools; not that they are anything stunningly different than stuff I've seen in the past (PHP brings me back to my C days - I haven't had to worry about ; at the end of every line for years!).

<< blog home