rc3.org

Strong opinions, weakly held

Month: February 2003 (page 2 of 9)

Projecting civilian casualties

I’ve been trying to get myself not to post about Iraq any more, but as you can see, I can’t help it. Slate’s Fred Kaplan has written a story dismissing some projections of civilian casualties in Iraq when we invade. He makes the valid point that there’s no real way to tell how many casualties there will be, but then he provides a bunch of reasons why there will be fewer casualties than are specified in the projections.

One of his main reasons for predicting fewer casualties is that infrastructure will not be treated as a military target in this war, because we plan on rebuilding the country once we’re done. That, to me, seems very optimistic. I can believe that we won’t target infrastructure if we waltz through Iraq with little resistance (and if we do go to war, I hope that’s the case), but if we get bogged down at all and Iraq’s ability to resupply its army comes into play, you can bet that we’ll bomb any targets that will prevent supplies from getting to Iraq’s soldiers. It would be dumb to fight a war in any way other than that — holding back to preserve infrastructure when troops are dying and the war is not progressing would be foolish.

The other point is that our previous war with Iraq, a lot of the action took place in the middle of the desert. In this war, if things tilt toward the worst case scenario, we’re going to be doing a ton of fighting in urban areas. Needless to say, doing so could lead to a lot of civilian casualties, some of whom will die during the fighting, and other s who will die in refugee camps after fleeing ahead of advancing US forces.

Anyway, like he said, you can’t predict civilian casualties.

Readers come first

At the request of a reader, I’ve added the ability to subscribe to an RSS feed with full posts in addition to the default feed, which provides excerpts of longer posts.

RSS feed with full posts

I figure this provides maximum flexibility for you, the readers. To me, the important part of this site is the words, and I want to make them as easy to get as possible.

How to Interview a Programmer

How to Interview a Programmer is a link that’s making the rounds. It’s of interest to me because hiring and getting hired is a huge part of a programmer’s career. If I’m going to work with someone, I always want to be part of the interview process so that I can make sure we don’t wind up with someone that will be challenging to work with due to lack of skills or personality fit. Besides, I’m egotistical to think that I do a good job at interviewing, and often assume that other people will screw it up. I was pleased to see that my interviewing technique was described almost perfectly by one of the roundtable participants:

Chuck Allison: I talk to them. I get a feel for them. I always ask about what they’ve done. I have found that by discovering what a person is excited about technically, you can learn a lot of important things about them. In the past I’ve asked people to describe a project that was especially interesting to them, or that was challenging and successful. On occasion I’ve asked what they’ve done that they’re the most proud of. This usually reveals the depth of one’s understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.

He gets right at what I go for. I want to know what the applicant is passionate about. If they aren’t passionate about writing good software, then they probably won’t get the job. I’m sure there are plenty of people out there who just do the computer thing for the money that do a good job, but I take a pass on them. The odds are just so much lower that you’ll get someone good going that route than if you go with the person that can’t imagine themselves doing anything else.

Another thing I’ve resolved to do in the future is always ask people to bring code to interviews. I’ve seen too much nightmare inducing code produced by people who I would have guessed to be good developers to skip this step. I want to see a coding standard, internal consistency in design, and an acceptable level of attention to detail in a person’s code.

IDE Mini-rant

I’m still trying to figure out my log4j problem from the other day, but I’ve been derailed by my attempts to debug servlets in an IDE. For whatever reason, I have been unable to get debugging to work properly in the IDEs that I’ve tried, and I have to say that I find it incredibly frustrating. That’s compounded by the fact that every IDE has its own scheme for how you should set up your Web applications as projects within the IDE, and all of them are different than the way I’ve set up every single one of my projects. (Mine are set up basically the same way as the Struts examples in the distribution.)

I won’t disparage the particular IDEs that I’ve tried, but suffice it to say that it ought to be simpler to set up your projects in IDEs and get the stupid debugger to work proeprly. Wasting half a week trying to get your tools to behave is just not fun.

Media responsibility

On February 13, the Washington Post reported that US special forces were already on the ground in Iraq, doing special forces type stuff. The article brought in a lot of flack and the newspaper’s ombudsman has responded. While I’m not in favor of the media putting the lives of US soldiers at risk, I think that this was an important story that was worth reporting. There’s a big difference between massing troops on Iraq’s border and secretly inserting our troops into the country to prepare for an invasion. The source for the story was the Pentagon — if they’re leaking this information to reporters, then we have to assume they have a reason for doing so. The bottom line for me is that I’m going to assume that the Pentagon and the Washington Post have a better sense of what’s OK to report (in terms of risk to our troops) than I do. If nothing else, the editors of the WaPo don’t want to read an article in the Washington Times next week with the headline, “Soldiers Exposed by WaPo Captured In Iraq.”

The future of instant messaging

A Microsoft product manager says that the future of IM is all companies managing the identities of people inside their organization, and the usage of a clearinghouse to broker connections between organizations. That certainly seems like a more reasonable approach than what we have today — people using public IM (totally insecure) or internal systems that don’t offer connectivity to external organizations. These days I’m amazed at any company, especially those that have remote offices, that don’t have a company standard IM system that people can use. IM is just too useful for getting work done and asking quick questions not to be used more widely in a corporate setting. I can’t think of too many circumstances where I’d prefer getting a phone call to an IM conversation.

Too much thinking about Iraq

Last night I dreamt that the war with Iraq had begun. For some reason an Iraqi plane (at first it was a jet fighter, but later turned out to be a cargo plane that was suspected to be carrying chemical weapons or something) had left Iraqi airspace, and because it was deemed a threat that violated something or other, we shot it down and the war began. The odd thing was that US aircraft ordered the plane to land and it was landing when we went ahead and shot it down. I don’t think that this dream really has any meaning other than that Iraq has been too much on my mind of late.

Loving and hating log4j

First, log4j is a logging library for Java, and a very popular one at that. Basically, rather than just putting a bunch of print statements in your code, you can use log4j to handle logging in a highly structured and configurable way. The best thing about it is that you can sprinkle all sorts of logging statements in your code, and then turn most of them off when you have the bugs fixed and it’s time to deploy the application.

For a year now, my relationship with log4j has been completely harmonious. I’ve basically just used it to send all of its log messages to the console, and the only settings I’ve tweaked have been the log format (more detailed in the dev environment than in production) and what level of logging is turned on for various parts of my application. For example, I want to see every message for code I wrote, but only errors from external code that uses log4j (many Jakarta packages).

For about a week, I’ve been trying to take log4j to the next level. I’m trying to use the SMTP logger to have log4j send error messages from production to me via email, so I can find out things are broken before people start complaining about them. This ought to be relatively straightforward, but it has turned out to be a huge struggle, and frankly I’m a bit tired of it. log4j works like you’d expect it to — it’s easy to configure to do simple stuff, but your configuration can grow complex fairly rapidly. The problem is that the docs for log4j are poor, so it requires tons of trial and error work to figure out what’s going on. Then there’s the part where log4j seems to be behaving erratically, so I’m not sure whether the problems are due to my misconfiguration of log4j or something else.

I think that this may be the final straw that forces me to figure out how to run Tomcat within a debugger so that I can step through the log4j code and determine exactly what’s going wrong. I could abandon the whole project and leave things as they are, but that’s not my nature. One side benefit is that I’m strongly considering writing and posting my own guide to log4j just so I don’t forget everything I have managed to figure out.

Appeasement, a first hand account

As a followup to my earlier post on appeasement, I followed a trail to the thoughts of Alistair Cooke, who actually bore witness to the policy of appeasement and can compare it to today’s events. Cooke offers a compelling account of the events that led to World War II, and sums up with this:

I have to say I have written elsewhere with much conviction that most historical analogies are false because, however strikingly similar a new situation may be to an old one, there’s usually one element that is different and it turns out to be the crucial one. It may well be so here. All I know is that all the voices of the 30s are echoing through 2003.

Even so, you have to judge for yourself whether the events Cooke describes are similar enough to today’s events to make accusations of appeasement an automatic debate ender when we discuss how to resolve the situation we find ourselves in.

The dangerous Bush Doctrine

Here’s a must-read op-ed from the Jamaica Gleaner (unearthed by stonefishspine) that makes a great argument against the doctrine of pre-emptive war that the Bush administration has espoused. One tasty bite:

<

blockquote> This Doctrine, which proclaims the right of the United States to intervene in any country it deems a threat, is one which can be used by any country to intervene in the sovereign affairs of any other state it subjectively deems a threat. No recourse to the United Nations or any external authority

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑