Tom Pierce: Misc Code

Sun, 02 Mar 2003 22:48:29 GMT

Kenneth Dickey on a successful software project [via CLiki]:

Imagine this. You need to build a complex, highly reliable software product that works at high speed on multiple networked server platforms and integrates with many kinds of server environments and databases. You have a working prototype but no production code and want product install CD-ROMs in under a year. The product is not totally defined, but you know that your business will change and you will have to feature evolve very fast in a highly competitive market. You are selling to Fortune 1000 companies, which demand 24/7 reliability.

And they did it in lisp.

This was the best code quality and the lowest development cost I have seen in 20 years of commercial software development.

Well, alright!

[lemonodor]

This is a great story and well worth the read if you are interested in eXtreme Programming, Lisp, or neither. It's just good to read about a well run project enjoying a huge success and how they pulled it off.

How not to name your source files

Mon, 24 Feb 2003 23:48:38 GMT

Ever wonder what an extremely bad naming convention for your source files (.java, .jsp, etc.) would be? Well here's one. Name them after the use case (or step of the use case) whose functionality that the source is designed to represent. (ex. UC10_02.java) You might think it's clever or it might save you from having to be clever with naming your files, but it's a bad idea.

Why is this so bad? Well, just imagine the maintenance nightmare that you are creating. In this scenario the names of the source files do not give the code maintainer a hint about what they do without the list of use cases. So, there can be no educated guessing as to where the problem the maintainer is trying to fix might be lurking. She will have to cross-reference the list of use cases with the file names to try to figure out what every source file is doing. BAD! Imagine having to do that yourself.

A second reason this is bad is because it implies that every file only incorporates functionality from a single use case. I'm sure I'm getting ready to tread on someone's holy ground here, but I think this is BAD! It is not uncommon for more than one use case to be represented in a single class. Consider the use cases of "log in" and "log out". I believe that the functionality in both of those use cases could be represented in a single servlet and that it may make sense to.

I have actually witnessed an application that has followed the naming convention above. I cringe when I think of having to maintain it. Fortunately I don't have to.

If this still sounds like a good idea to you, please see How to Write Unmaintainable Code. Roedy Green has compiled several tips that you can follow to further obfuscate your source code.

Thu, 16 Jan 2003 19:24:10 GMT

A colleague of mine just sent me a link to a great article called Printing the Web. It offers good arugments for making printer-friendly views of your web pages, and presents suggestions for presentation.

Bash Script: md5dir.sh

Mon, 06 Jan 2003 16:34:31 GMT

Here's a bash script that I wrote to calculate the MD5 hash of all files in the specified directory and below. It's quick and dirty, but I've found it useful to compare files in 2 directories to see if anything has changed. I can pipe the results out to a file for each directory and then diff them. OR, even better, you can compare them with md5sum itself by:

cd <dir-to-compare> md5sum -c <file-contatining-sums>

Here's the script:

#!/bin/bash # Script that calculates an MD5 hash for each file in the specified directory # and all directories below that. # # Author: Tom Pierce # Date: 10/31/02 export IFS=$'t\n' # a quick check to see if any files were given # if none then its better not to do anything than rename some non-existent # files!! if [ "$1" == "" ] then echo "Usage: md5dir " exit 0 fi # For each file in the specified directory, get the md5 for file in $(find $1 -type f) do md5sum "$file" done