Thursday, 31 October, 2002
Monday, 28 October, 2002
The things they don't tell you about Linux. Ever since I started working with Linux, I've been hoping for some kind of reference book or site that would tell me what program to use in order to perform some task. Unix commands are pretty cryptic to the uninitiated, and I find myself fumbling around trying to find the right command to do a particular job. Today, while exploring my shiny new Linux From Scratch system (see September 7), I ran across the command apropos. Curious, I looked up the man page, and found what I've been wanting all this time. apropos (and a companion program, whatis) scan man page descriptions for matches to keywords that you supply on the command line. whatis will tell you what a particular command does (i.e. "whatis ls" will display the man page description of the ls command). apropos searches command names and descriptions for keywords. So "apropos 'list directory'" will display the man page descriptions of all commands that contain the phrase "list directory". Yes, it's a small victory. But I'll take what I can get.
Saturday, 26 October, 2002
Bicycle safety is more than just wearing a helmet and obeying the law. That statement might win the "duh" award, but it's amazing how many people think that the law is going to prevent them from getting creamed. And although a helmet might just save your brain housing group in the event of a crash, it's much better not to get hit at all. To that end, local Austin cyclist Michael Bluejay has created BicycleSafe.com. His article How to Not Get Hit By Cars is the best practical advice I've seen for cyclists. In it, he describes 10 common ways that cyclists get creamed, and gives very good advice on how to avoid each one. His links page has an impressive array of links to cycling resources and advocacy. If you're a cyclist, visit this site.
Wednesday, 23 October, 2002
I drove up to Fort Worth, Texas yesterday with a co-worker to attend the Human Resources Southwest Conference and Exhibit, where we have a booth. We set up the booth yesterday afternoon, and spent today talking to people as they came by: handing out literature and demonstrating our product. Trade shows are fun in small doses, but I was quite happy when 6:00 rolled around. Tomorrow is going to be painful.
But every cloud has a silver lining. Just across the street from the convention center (more importantly, just two blocks from my hotel) is a little place called Malone's Pub. It's not much as far as pubs go, but they have quite a variety of beers in the cooler. Last night I had the pleasure of trying two new (to me) beers, both from the Unibroue brewery. La Fin Du Monde is a blond, flavorful beer with a whopping 9% alcohol content. Fellow brewers understand how difficult it is to get a 9% beer that tastes that good. The other beer I tried was the strong red Maudite, only slightly less potent at 8% alcohol, and just as tasty. I highly recommend both beers, and will be looking for some of Unibroue's other selections at the local beer outlet.
Tuesday, 22 October, 2002
Visual Studio Magazine ran an interview with Alan Cooper, author of About Face: The Essentials of User Interface Design, and The Inmates Are Running the Asylum. The interview focuses on the topic of software construction, which I've been pondering recently (see October 14). I don't agree with everything that Cooper says in the article, but he does make some very good points, and validates what I and some of my co-workers have been thinking for some time. Software construction (Cooper doesn't like using the word "development"—see the article for the reasons) can be approached as a craft, or as an engineering discipline. The way you approach it depends on the type and size of the project. Who would have thought that it comes down to "use the right tool for the job"? And there's no magic all-around hammer.
There's a lot of food for thought in that article. I highly recommend reading it. I've also read his About Face book, and recommend it as well.
Monday, 21 October, 2002
I read a lot of crime novels and true crime stories several years ago, and noted that what gets killers caught are patterns that they either fail to notice or insist upon repeating despite the risk. If there's no pattern in the victims, or the timing or manner of killing, there's very little for investigators to go on. I had plotted a story in which the killer picks random people in random cities, and using many different methods to kill them. Besides being a depressing thought, I decided not to go ahead with the story for two reasons: 1) I didn't want to give anybody any ideas (a groundless fear—people already get wacky ideas); and 2) I couldn't think of any realistic way that the killer could have been caught or even how an investigator could tie the killings together. I'd have to add some brilliant deduction or unbelievable stroke of luck for "The Hero" to get anywhere. I'm not too concerned anymore about giving people ideas-I'm sure there are plenty of nutcases out there who have thought up even more frightening things. Heck, there might even be people out there already doing random killings. I couldn't come up with a plausible way to get around my second objection, though, without making the story seem contrived. What little I've learned about crime scene investigation over the past few years still hasn't changed my mind. Somebody who just wanted to kill random people could get away with it for quite some time, despite the best efforts of our law enforcement community. It's a frightening thought.
As you might imagine, it's the D.C. area sniper who got me to thinking about this again. That one probably would have remained free had he stopped after the 7th or 8th attack. But he's gotten careless, and will undoubtedly be caught if he continues.
Sunday, 20 October, 2002
I've mentioned before the problems we have with deer in the neighborhood. When we moved here seven years ago we often saw deer, but rarely more than a few at a time. The population has grown steadily over the years (in no small part because our neighbors feed the silly things) to the point where it's common for us to see a dozen or more deer bedded down in our yard at night. The population is totally out of control.
I mentioned this to my friend Chris last April, and said that I was considering letting some bow hunters onto the property when hunting season rolled around. Imagine my surprise when Chris contacted me and said that he'd bought a bow and had been practicing, and asked if I was serious. He came down last month to scout the place, and arrived this weekend ready to hunt. Yesterday was a bit frustrating for him because, although he's able to hit a stationary target at 50 yards, the target doesn't duck, jump, or back up when it hears the arrow coming. Today he got a deer with his second shot. We field dressed it in the front yard, and he packed it in ice for the ride back to Dallas where he and his friend will process it into venison steaks and other such delicacies.
Yes, it's perfectly legal to hunt deer in my yard. It is hunting season, after all, he had a valid license, and we're not in the city limits. And although I wouldn't let somebody hunt with a rifle on my little 1.75 acres, that's probably legal, too.
Oh, and don't worry about the deer. There are plenty more.
Saturday, 19 October, 2002
Today is the 15th annual Round Rock Outlaw Trail 100. As has been the case for the previous three years, it's raining today. I'm a bit obsessive about my cycling, but I draw the line at riding 100 miles in a downpour. Have fun, folks, if you decide to ride.
Friday, 18 October, 2002
Attached to the wall above the toilet in the aircraft lavatory are two signs. The first reads:
Discarding anything other than toilet tissue may
cause external leaks and create a safety hazard.
The other reads:
Please use the wastebasket for
anything other than toilet tissue.
It's probably a good thing that people don't interpret those signs literally.
Thursday, 17 October, 2002
One benefit of traveling on business is that sometimes I get to visit friends. In that regard, this week's trip to Seattle was the best ever. After today's meeting, my friend Dennis came to get me at the hotel, and we headed out east to Carnation where we met Mike for a couple of hours of mountain biking followed by an evening of burgers and beer at a pub in Sammamish. The weather in the Seattle area has been uncharacteristically mild, which made for near perfect trail conditions. I haven't been mountain biking much recently so my bike handling skills are a bit rusty, but all that road conditioning has left me in reasonably good shape and I was able to keep up with the guys on the trail. Days like today remind me of why I got into mountain biking in the first place. I'd be hard pressed to find better friends than Dennis and Mike. It's too bad they had to move up to Seattle.
The picture, by the way, is just a bit of goofiness I concocted at the top. You're looking at a 300 foot vertical drop. I'm standing on a ledge that's just a few feet below the lip. No, I didn't climb that, and I didn't wreck the bike right there.
Tuesday, 15 October, 2002
Perhaps the lexicographers can shed some light on this one. When discussing ways to create software, the most common term used in the literature to describe one way is "methodology." I've long held that the proper term is "method," but now I'm not so sure. My American Heritage dictionary provides a little guidance, the relevant definitions being:
method: A means or manner of procedure; especially, a regular and systematic way of accomplishing anything.
methodology: The system of principles, practices, and procedures applied to any specific branch of knowledge
Given those two definitions, I'm inclined to believe that I've been wrong all these years, as methodology seems to include method. That is, whereas method is "a means or manner of procedure," methodology includes "principles, practices, and procedure." [emphasis mine] Anybody?
Monday, 14 October, 2002
Is software development a craft, or an engineering discipline? As with so many such questions, the answer is the ever annoying "It depends." It depends on two things: the complexity of the project, and the skill of the implementers. Unfortunately, defining complexity and skill turns out to be quite difficult. Not to worry, as I'll come back to those two issues at a later time.
I postulate that the amount of engineering (up-front design work) required for a particular software project is determined by an inverse relationship between the project's complexity and the skill of the implementers. That is, a simple project being constructed by a very skilled implementer will require minimal up-front design. The theory is that the implementer is a skilled craftsman who has constructed similar projects in the past, and is capable of building this project with a minimum of outside help. Conversely, a complex project being built by a team of relatively inexperienced developers will require much more up-front design work. The relationship, however, is not linear. A very complex project will require a large amount of up-front engineering, regardless of the implementers' skills. And regardless of how much up-front engineering goes into a project, a certain minimum skill level is required on the part of the implementers. It's simply not true that sufficient design will enable any group of monkeys to bolt a system together. That was the theory behind offshore development which, last I checked, hasn't reduced the demand in this country for skilled developers.
Now, I'm not claiming to be breaking any new ground here. Practitioners of the various agile development methods have hinted at this relationship, as have various authors of "best practices" books over the years. I'm just laying this stuff out in simple terms in an attempt to wrap my head around the problem. After over 20 years of developing software for a living, I've come to the conclusion that there is no single "best" way to develop software. The "best" way is highly dependent on the project's size, complexity, and development team. But it seems that there is no efficient and effective method for dealing with the types of systems that are being contemplated today. The problem is that the software systems we are being asked to create, the systems on which they are implemented, and the user base they are expected to serve are becoming increasingly complex. Our tool set—the development tools and methods—have improved, but have not kept pace with the demands.
As I said, I don't expect to come up with "the answer," but I do hope to identify and understand the factors that determine the most appropriate development method for a particular class and size of development project. As always, audience participation is encouraged.
Sunday, 13 October, 2002
Now that I'm not on a rigorously prescribed training schedule, I try to ride to the office and back twice a week, with Tuesday and Friday being the days of choice. Not that the commute is a walk in the park. Depending on the route I take, the ride is between 25 and 30 miles each way. Typically I push hard the first half of the ride in, and then make the rest of the ride at a leisurely pace along with a co-worker who lives near the halfway point. On the way home it's just the opposite: a leisurely ride for the first hour, and then pushing a bit the rest of the way home.
A friend mentioned the other day that I must save a lot of money by commuting to work. I'd never really considered that before. Let's see, my truck gets about 22 miles per gallon so each day that I take the bike I save about 2.5 gallons of gas. Figure 5 gallons saved per week. In a year, I would save 130 gallons of gas, or about $200 at a buck and a half a gallon. If I figure an average of 110 miles per week, that's 5,720 miles in a year. I have to put the bike in the shop for a $70 tune-up about every 2,000 miles, so the cost of the tune-ups pretty much negates the savings in gas. However, I am driving 5,700 fewer miles per year, so those $200 truck tune-ups every 15,000 miles are postponed. Rather than one tune-up every year or so, it's more like one every 18 months. Factor in the per-mile savings on oil changes and other maintenance and, yeah, I'm saving a couple hundred bucks a year. Maybe. If you don't factor in the cost of the bike, helmet, gloves, jerseys, shoes, shorts, cold weather gear, lights, batteries, spare tubes, etc. My bicycling outfit cost almost as much as my tuxedo! If I could commute on the bicycle every day, perhaps I would see a difference. Although the extra food cost (have to fuel the machine) would certainly eat into any cost savings. Face it, cycling is not a poor man's sport, and I don't do it to save money.
Friday, 11 October, 2002
You have to think about the oddest things when you're developing software. Part of our software generates random user identification keys. We recently had to change the code to eliminate vowels, because some customers were complaining about the product creating "obscene" keys. In retrospect, we should have thought of that, I guess, and either removed the vowels or had the program alternate letters and numbers. Even eliminating vowels, though, won't prevent somebody getting upset if a key contains a three-letter, vowel-less version of some four-letter word. I suspect that no matter what we do, we'll offend somebody.
Thursday, 10 October, 2002
You often here "Congress just doesn't respond to the people anymore. Unless you have a pile of money to donate to a re-election campaign, you might just as well not exist."
Somehow, I suspect that this has always been the case. Back before our Congresscritters were paid a real salary, they had to be somewhat better off than average in order to afford being away from their farms or businesses for extended periods. As with any other normal person, they would listen to, take advice from, and try to help their friends. If anything, I'd venture to guess that Congress today is more responsive to "the people" than it was 200 years ago. I don't know how to go about proving that, though. Any suggestions?
Wednesday, 09 October, 2002
Remember returnable soda pop bottles? My friends and I would search empty lots, dumpsters, and other likely places for discarded soda bottles that we could return for a nickel. If we were really lucky, we'd find a quart bottle that would bring in a dime or more. An hour spent searching for bottles often would result in two or three dollars that we could spend on pinball, sodas, and candy down at the local bowling center. (Not my dad's center, though. He didn't like me playing pinball.) The soda delivery guys would pick up the bottles from the stores and take them back to the bottling plant, where they'd be cleaned and reused. Breweries, too, often accepted bottles. I remember stacks of empty beer bottles lined up outside the lounge at Dad's bowling center.
So what happened? By the time I was old enough to order beer in a bar, they were breaking the bottles in the trash can (can't have kids sifting through the trash, drinking the dregs), and my last recollection of a returnable soda bottle (at least in the U.S., I see them all the time in Mexico) is from 1985. It turns out that the push to non-returnable soda bottles was started by Pepsi in the early 1960's. Bottlers found that it was cheaper to buy new bottles than to reuse existing bottles. Consumers, too, liked not having to return the bottles. So the bottles (glass and plastic) end up in landfills. I still don't see how using new glass or plastic can be more economical than cleaning and reusing existing bottles. It's certainly not very environmentally friendly. Reuse is a much better solution than is recycling. Not that I can recycle my glass around here. The closest place that'll take any kind of glass is 30 miles away.
If you've read this page for any length of time, you probably know that I have a very healthy distrust of government in general, and government "programs" even more. But sometimes I wonder if government mandated recycling could be a good thing. By all reports, it's helped decrease the number of containers that end up in landfills in California, Michigan, and other states with bottle return laws, but the efficiency of the programs is hotly debated. But, dang, I feel guilty every time I throw out a bottle.
Tuesday, 08 October, 2002
My latest educational experience: learning PHP—a Web scripting language widely used on Linux. I'm experimenting with some Web stuff on my Linux From Scratch system and, since there's obviously no VBScript available (fortunately), I'm forced to use something else. Given the choice between Perl (which I've played with briefly) and learning something new, I chose to try my hand at PHP. I picked up Sam's "Learn PHP in 24 Hours", (which isn't a bad book, although it's not very good) and started going through the tutorials. The first 8 chapters introduce basic language concepts, reinforcing the explanations with little examples that you can run on your web server. The remainder of the chapters show you how to use the language for many common tasks. The descriptions in the first 8 chapters are adequate. As I'm currently on Chapter 9, I can't say anything about the rest of the book.
The best way I can describe PHP is "C for the Web." The language looks very much like C would look if you took away basic data types (all variables are untyped) and then added a few object-oriented features. When I first saw the language, it looked reasonable. But digging in, I'm not so sure. The language has evolved rather than having been designed, and it shows. There's some serious wonkiness there. For example:
- When passing parameters to functions, you enclose the parameters in parentheses. Except for the print function. It's special, and you don't have to parenthesize its arguments. Weird. Special cases make a language more difficult to use.
- All variable names begin with a dollar-sign '$' character. I know this is popular in some languages, but it's always struck me as some kind of weird syntactic sugar. Function names and constants don't need special identifying characters. What's so special about variables that they need to be flagged?
- The operators && and and do the same thing: they perform a logical and of the two operands. The only difference is that && has higher precedence than and. Why? It makes absolutely no sense to have two different logical and operators, and giving them different precedence is just wrong. The operators || and or (logical or) have the same weird relationship. The problem of precedence is much more easily solved by using parenthesis to specify evaluation order.
- The language defines an "else-if" construct that I wish was in every language. In PHP, the "else-if" can be written as a single word, elseif, or as two words, else if. Why clutter up the syntax like that? It makes the language harder to parse, and provides no real benefit. Throw out the two-word else if, and save yourself some headaches.
I can understand that PHP is intended as an interpreted scripting language rather than a compiled language. It's common for scripting languages not to require pre-declaration of variables (although an option would be nice). But not printing an error when you try to reference an undefined variable is weird. If I write print ("$x"); when x hasn't been defined, PHP just prints nothing. (Update 10/13 - my PHP configuration prints a warning.) I would have expected it to print an error message instead. I just know that referencing undefined variables is a huge source of bugs in PHP programs.
I won't even get into the strange array semantics, or the odd object model. Both are usable, I think, but very weird. I'm still learning about the language, and I likely will write some small web applications with it, but I'm also looking for something a bit less odd. Unfortunately, the only real options I see are Python, Perl, and Java. The other two P's look to be stranger than PHP, and Java, well... Is there really no decent web programming language? What I wouldn't give for Web Pascal.
Sunday, 06 October, 2002
I've almost decided to ride the Round Rock Outlaw Trail Century on the 19th. The start/finish line is at a park about 8 miles from the house. I could ride there, do the ride, and then ride home. It would give me the chance to redeem myself after last weekend's stupidity during the Waco ride. I've continued my training throughout this week, although not following the strict schedule of previous weeks. Sunday, Monday, and Thursday were short and easy recovery rides with Debra. Tuesday and Friday I did the commute to the office and back, and Saturday Debra and I went for 15 miles at her pace. I had planned to get up and ride this morning, but I stayed up too late last night, and instead spent the day working on the computer and finishing the lawn. I don't think it'll affect my training too much, and I really needed the break.
Saturday, 05 October, 2002
Charlie graduated from obedience school today, so now Debra and I are fully trained in basic dog obedience. We took the 8-week Basic class at PetsMart, where we learned simple commands like "sit," "down," and "stay," along with a bit about dog psychology (such that it is) and the basics about canine health and treatment. As far as we're concerned, the class is well worth the cost (about $90), because we learned a lot of good techniques for controlling Charlie. And Charlie got to learn a bit about socializing with other people and dogs, something that we need to continue working with him on. He's a very energetic puppy, and an enthusiastic greeter. The techniques for calming him down have been well worth the cost of the class. We're considering the Advanced training class, where they concentrate on teaching the dog to behave despite distractions. As Charlie seems to be afflicted with a stubborn streak, and is quite easily distracted, it's probably a good idea.
Friday, 04 October, 2002
This Auto Generated message is being sent to the contacts in my address book.
It is to notify you that I have installed a SPAM | BAR Anti Spam & Virus filter, on my incoming mail.
As long as you write to me using this particular address, your messages will come straight through to my mail inbox.
If, however, at any time you should write to me using a different email address to this one, the SPAM | BAR program will reply to you asking you to confirm you are a real person.
That's nice to know, and I'll be happy to give this person the honor of receiving mail that I decide to send to random people. This is an obvious pitch for Spambar, which needs to re-think their approach. You'd think they'd at least include the person's real name in the mail message. Not that I'm going to sign up for Spambar any time soon. Their broken approach to filtering is the same as MailCircuit, and a few others that have popped up recently.
Thursday, 03 October, 2002
Email scams. I got one today that's chock full of interesting "facts" like "Medical care is the #3 cause of death," "Cardiovascular disease is reversible," and "Cancer is preventable." The thing is a poorly worded come on for a "Life & Health Seminar" that supposedly will be held locally, somewhere. The location isn't terribly specific as to what town it's in. I can call a local number (local to where?) and use my credit card, or register online. I can even go to the web site and see much the same information. Somehow, though, the email neglects to mention the actual city location (the web site indicates that it's in Chattanooga). Direct sales of goods (?) and services are one thing, tasteless as those might be. But these email scams are getting entirely out of hand. Why would somebody email me an invitation to a seminar to be held in Chattanooga?
Tuesday, 01 October, 2002
Crypto, by Steven Levy, is the story of the development of public key cryptography and its eventual release to the masses. It's the story of a handful of amateur cryptographers, mathematicians, and others who defied the government's (particularly the NSA's) attempts to keep cryptographic information secret and under tight control, and finally made strong cryptography available to the public. Well written, non-technical, and a delightful read. Recommended.