We lost 3-1 tonight as we were four regulars short and against a tough opponent. Our reserves played admirably but ultimately the other team was better. A personal highlight for me as goalie was stopping a penalty kick in the 2nd half to preserve the tie, though I eventually gave up two more goals.

Our efforts last night were not enough to put us in the win column, as we gave up three first-half goals in a 3-0 loss. We did play our best half of the season in the second half, with numerous just-misses on the opposition's goal. In knee-related news, I blew past somebody for the first time in about a year during a dribble-and-run down the sideline. Not quite full speed, but encouraging nonetheless!

This is the first of what I hope will be several blog posts on all things I encounter developing software at IBM.

I spent a good part of this week debugging a particularly nasty software bug on an internal-use application at work. On day one I intuitively felt that a foreign key linked EJB was the correct way to go. When I could not get it to work within the application's custom framework, I assumed my solution was incorrect, since I have not used EJBs often. After two days with very little progress, I was ready to say the heck with the whole bug, the heck with EJBs, and throw a big pity party. But then I realized I needed to take a step back, reevaluate the situation and my assumptions.

My first assumption was that the framework was correct. Indeed, it had been in production for several years. On the other hand, it did not have many foreign key relationships like the one I was trying to add -- perhaps it did not have any. I decided to dive into the bowels of the custom framework. Lo and behold, it had incorrect behavior for certain classes of foreign keys, mine included. A little patching and I was on my way.

There are a couple good software development lessons in here. The first is to frequently revisit your assumptions, especially when you are going nowhere fast. Changing your assumptions allows you to explore more of the possible solution space quickly.

Another lesson is to be cautious in adding new framework layers over top of established standards like EJB. While EJB development can be complex, matters are complicated when you deal with an unfamiliar extra layer.

Finally there is a lesson to keep your abstractions simple. An entity EJB is ultimately an abstraction of a database row, yet the implementation is complex enough that some developers feel compelled to add another layer to abstract away the EJB abstraction!

Regular readers of this blog might recognize tonight's soccer opponent, "Lions", who have regularly won the IBM soccer league while beating team Yuengling like a gong. We faced off against our nemesis again tonight, and it was a game for the ages.

Early in the first half, we capitalized on a Lions mistake and scored an easy goal. 1-0, the first lead I can remember us taking against them, and one of the few goals we've scored on them in years. They quickly struck back twice. In another first half breakaway we added a second goal, and took a 2-2 tie into halftime. Could this be the time we finally beat them?

The second half was hard fought, with strong attacks and counterattacks from both teams. A tie seemed inevitable as the clock wound down to the final minutes. In the last minute, a Lions breakaway found paydirt as they squeaked away a 3-2 victory. Still, this was quite a strong effort for a Yuengling team where half the roster was new from the year before. I think we can run with any team in this league and be a force to be reckoned with!

In a complete reverse of last year, our co-ed soccer team started out this season 0-2 on the year with a pair of 5-0 losses. Of course, playing the #1 and #2 teams for our first games, rather than last year's bottomfeeder-opening, was a factor. Here's to hoping things get turned around soon, and that the men's team can start better, though they too open the season against a defending champ!

Many students, especially those who are poor, intuitively know what the schools do for them. They school them to confuse process and substance. Once these become blurred, a new logic is assumed: the more treatment there is, the better are the results; or, escalation leads to success. The pupil is thereby "schooled" to confuse teaching with learning, grade advancement with education, a diploma with competence, and fluency with the ability to say something new. His imagination is "schooled" to accept service in place of value. Medical treatment is mistaken for health care, social work for the improvement of community life, police protection for safety, military poise for national security, the rat race for productive work. Health, learning, dignity, independence, and creative endeavor are defined as little more than the performance of the institutions which claim to serve these ends, and their improvement is made to depend on allocating more resources to the management of hospitals, schools, and other agencies in question.

From a 1970 essay by Ivan Illich entitled Deschooling Society. I'm not convinced schools intentionally mislead, but I do agree that many people confuse process and substance.

Bruce Schneier writes about The Eternal Value of Privacy. It's a retort to the question "If you aren't doing anything wrong what do you have to hide?", a question I've never cared for.

Last night we had our first men's soccer practice, and I must say that I'm excited about our chances. Though we have some key departures from last year, we've reloaded with some talented players. We have a healthy stable of midfielders and an embarassing wealth of forwards - maybe our strong point will be our offense! Key additions and returning players mean the defense will be no slouch either. Let's see what this team can do!

With many things though, people have this strange tendency to avoid knowing them, and instead ask someone else unfortunate enough to already know them. Say, Makefiles. Is it just my experience or do people worldwide pretend to be incapable of dealing with a hairy Makefile, and leave its regularly scheduled tweaking to a small set of knowledgeable victims?

From The cardinal programming jokes (PG-13). By the way, this quote is incredibly true in my profession, and I think in all of life as well.

A great illustration by Jessica Hagy at indexed: I tried to care, but you would not shut up.