February 2008

A fellow writer on Associated Content by the name of Jennifer Eblin recently published a story entitled Staley Road: A Local Haunting. It has the makings of a great ghost story: a bleeding barn, satanic cults, lights and electrical systems malfunctioning – you know, things that make local legends like this one fun.

Jennifer is careful to point out that the legends surrounding the supposedly haunted area have little basis in history. The farmer and miller who legend says killed his family, did not. She also cautions readers that the property owner is not happy about the tresspassers who park on his property and make nuisances of themselves, particularly in the middle of the night. He has gone so far as to file a lawsuit against a publisher for including his barn in a collection of wierd places in Ohio.

Well, he’s at it again, only this time the subject of the lawsuit is Jennifer herself. Even though she clearly informs readers that the legends are false, and that the property owner has little patience with ghost hunters, the law firm representing him has written her twice, notifying Jennifer that she is being named in a new suit, and demanding that she “take down” the website where her article is published.

The demands are absurd. For one thing, Associated Content owns the site, not Jennifer, who has no authority to remove the article, much less take down the site. For another, I find it very difficult to believe that her article has led to any measurable increase in property damage. Incidentally, the man lost the previous suit.

Judge for yourself. Read the article, and leave your thoughts either there (AC allows anonymous comments), or here if you prefer.

I first wrote this article as a submission to Helium’s Marketplace. It was not chosen, so my loss is your gain, as I’m posting it here in it’s entirety. Note that I received no compensation for this article, but since I was hoping WinRAR would choose to publish it, I can’t say it is completely unbiased. That being said, every point in the article is absolutely true, and the benchmarks referenced are available for anyone to view.

*** Original Article Below ***

Two of the most popular file compression programs on the market today are WinZIP and WinRAR. The question that inevitably arises is, which is a better buy? The answer can be found by comparing the performance, price, and features of each.

Compression – the whole purpose behind using compression software is to shrink the size of files for more efficient storage and faster transmission over a network. Thus, how well a utility compresses files should be of primary concern to those needing to choose one. Many independent sites on the Internet consistently show that WinRAR compresses files more than WinZIP. There are a few exceptions with specific file types, particularly those that are already compressed in their native format, like mp3 files. These do not compress very much in any case by either WinRAR or WinZIP. WinRAR comes out the clear winner among most other, highly compressible file types, and the aggregate or overall measures generally show WinRAR on top. Supporting data can be found on wikipedia (Comparison_of_file_archivers), techarp.com (Compression Comparison Guide Rev. 2.0), and maximumcompression.com. [click to continue...]

About 18 months ago I bought a SimpleTech 160 Gigabyte external USB hard drive for storing media files and backing up other data. I reformatted the drive so it would be writable from linux (using the reiserfs file system type). It worked great until about a month ago. At that time, whenever I rebooted, I had to power the drive off and on several times before linux would recognize it. Finally it stopped working altogether.

I tried moving it to another computer, but it wasn’t recognized there, either. The warranty on these drives is only 12 months, so I had no recourse with the company. With little to lose, I took the drive out of the enclosure to see what was under the cover. It was a Seagate Barracuda 160 Gigabyte Ultra IDE internal drive, with some circuitry to convert USB signals to IDE.

I removed the drive from the enclosure and installed it directly into the linux file server. Once I configured the mount point, it now works like a charm. I gave up the convenience of moving the drive from machine to machine, but I gained quite a bit of performance, and – more importantly – retained the data that had accumulated on the drive.

I have since read in various forums that this type of failure of external drives is fairly common. Most people fix it by buying a generic external enclosure to replace the original one. If you really need the portability, this is a better way to go. If you’re like me however, who just bought the external drive for ease of installation and because it was on sale, removing the drive from it’s enclosure and mounting it inside your computer might be a good way to recover a failing device.

One final note: I find it interesting that SimpleTech only warrants the product for 12 months, but according to Seagate’s web site, the Barracuda carries a 5 year warranty. It’s almost as if SimpleTech is admitting that the most likely point of failure is in the enclosure they provide.

As a Configuration Manager, I’m always looking for ways to improve the automation of the builds and deployments of my company’s applications. We use scripts to compile the apps, replace certain token strings with environment-specific values, and copy the new executable code out to the production servers. Ideally, we should not have to use seperate scripts when deploying to different run-time environments (development, integration test, production, etc.). We want instead to pass the target environment into these scripts, and use logic to determine environment-specific values. So I set out to create a Lookup Table to set the values according to the target environment.

I wanted to keep it simple so maintenance would be easy. I wanted it to run in a basic command shell (I use ‘bash’, but most other shells would work as well). UNIX and linux utilities like ‘sed’ and ‘awk,’ and xml parsers would have done the job, but they added complexity so I stayed away from them (although I do use ‘grep’). The listing below is a simplified version of what I came up with. It takes one parameter representing the target environment, and sets 3 variables: the target server, the target database, and a process user ID. It then prints the new values to the screen for verification (an optional step). The script we actually use at work also sets target directories, service names, and website urls, but this is enough to give you the idea:

Listing 1

#!/bin/bash

# Sets environment variables based on lookup string

# Environments: DEV = Development, QA = Quality Assurance,

# UAT = User Acceptance Test, PROD = Production

ENVIRONMENT=$1

# Set server addresses, database names, and user IDs.

line=`grep ^$ENVIRONMENT <<EOF

Env Server Database User ID

— ———————— ——— ———-

DEV dev.myapp.mybusiness.com myappdev devappuser

QA qa.myapp.mybusiness.com myappqa qaappuser

UAT uat.myapp.mybusiness.com myappuat uatappuser

PROD prod.myapp.mybusiness.com myappprod prodappuser

EOF`

set — $line

export AppServer=$2

export DataBase=$3

export UserID=$4

#

# Show environment settings:

echo “AppServer = $AppServer”

echo “DataBase = $DataBase”

echo “UserID = $UserID”

Sample run:

$ ./Lookup.sh DEV

AppServer = dev.myapp.mybusiness.com

DataBase = myappdev

UserID = devappuser

$

Using the Technique

Knowing how this script works is not essential to using the technique, as long as you realize that you can expand it by adding more values to the ends of the input lines, and creating enough values with the ‘export’ statements to accomodate the new values.

>>Read explanation and rest of article >>