Wednesday, March 26, 2008

Decades of Spam

I have some contact-the-author email accounts that are provided in README files that accompany some open source software I've released, and which I knew would sooner or later get scraped up by spambots. They were, and now I get anywhere from 20-100 spams a day on them. The Gmail filter is pretty good so I rarely see more than one every couple weeks that gets through. Still, because every now and then a legitimate email comes in and sometimes gets marked as spam I have to take a quick look at the spam jail pretty much daily and make sure that nothing got caught that should have gotten through.

And I wonder, how long is this going to go on? Is this something I and every other email user that needs to provide a publicly accessible email address going to have to deal with...for decades?? Geeze that's depressing.

About the only thing more depressing in this matter is the poor slob whose job it is to write those ridiculously lame come-on one-liners for "enlargement" products. That's a soul-killing job if there ever was one.

Monday, March 24, 2008

The Toilevator

One thing I've noticed over the last decade or so is the increasing likelihood that some mundane item that one thinks ought to exist, more often than not does exist. At least in the areas of household items, tools, and home improvement type stuff.

That said, I give you...the Toilevator.

No, it's not for me. But thanks for asking.

Monday, March 17, 2008

Thursday, March 13, 2008

Otters Should Not Be Allowed to Design Software

I got nothing against otters.

They're cute, playful, inquisitive, and so on. We should take joy in their simple life, and protect their habitat.

Neither they nor their human analogues, however, should be allowed to design software.

When you're porting a large software system from one platform to another you spend a lot of time dealing with the design and implementation..uh..quirks of the original builders. Sometimes it's just stylistic stuff like typedef'ing (C) or renaming (Ada) every single freakin' standard type name. Other times, though, you'd swear that otters had been tasked with coming up with the design.

So the part I'm porting now has a central control process and a GUI process that communicates via sockets. All well and fine.

The latest issue I've been dealing with has to do with the operator clicking on a field in a table to change it, which pops up a menu of valid entries, one of which is selected and then the "Done" button is clicked. Somewhere, though, in the update processing chain the value was getting trashed, causing the update to fail.

In other words, run-of-the-mill porting issues.

So I traced through the code and verified that the operator's selection was getting properly packaged up into a message and sent out through the socket. I followed it right up to the socket write, so there was no doubt.

I then went to the recipient of the message, the central control process, and verified that the message was being properly received and decoded.

The next thing that's done after receiving the message is calling a function called Update_Table(). The invalid data error is being detected inside this function. However, the data from the message I just read in is not being passed into Update_Table. WTF? Why is it failing then?

So I dig down into Update_Table and see that what it's doing is going out to query for the data in the table row that's about to be updated. But it's not getting this data from a database. Nor is it accessing some internal data structure model. It's sending out a message.

To the GUI process.

And so now I go back to the GUI process and start tracing from where that message is received. So is the GUI process maintaining some data store itself that it maintains and both displays to the operator and keeps for queries from the controlling process? Why, no, no it doesn't. Instead it goes and gets the data out of the graphical widget that's displaying it. If the value is a number, it converts the displayed string representation of the number back to a number, otherwise it passes it back as a string.

So not only does the central controlling process not have control of the data, it's outsourced that responsibility to the GUI, and that in turn is using the display widget as its data store.

Whoever came up with this bright idea is a complete, raving, ... otter.

Imagine, in a distributed system that does in fact utilize a database for data storage you can lose all your active data if the GUI crashes.

(Oh, the problem turned out to be a data alignment mismatch due to the change in word sizes between the different platforms.)

Tuesday, March 11, 2008

Solve the First Problem, and Don't Keep Going After It Breaks!

I cannot emphasize enough the truth and importance of Tilton's Law: Solve the First Problem:
Normally Tilton's Law refers to two or three observed issues that seem to be in the same ballpark. The law says pick out the one that seems most firstish and work on that and only that until it is solved. There is a terrific chance the other problems will just go away, and even if not the last thing we need to do while working on one problem is be looking over our shoulders at possible collateral damage from some other problem.
What I've experienced and expressed over my career is that once a bug has acted, you can no longer trust anything the software is doing. You've busted the state of the program, and everything that happens from that point on is suspect.

It drives me nuts when a tester has experienced a problem in the system being tested, logs it, and then keeps on going, writing error reports for every bit of collateral damage that is now cropping up. All of which have to be analyzed, dispositioned, and closed, and other than the first, none of which should have been written at all.

It's a waste of time, effort, and money for developers trying to uncover and fix bugs that are the after-effects of the "first" bug, or testers logging reports of the after-effects of a bug.

Report the first bug, fix the first bug, and move on.

Primordial Program Porting Perils

Porting old code can be a pain.

I'm currently working on porting a large (well over a million SLOC of Ada and C) wargaming simulation system from a Silicon Graphics/IRIX platform to PC/Linux.

98.3% of the porting effort has gone pretty smoothly, but there have occasionally been some real showstoppers.

The latest issues I've been working with on the port have to do with the Xbae widget set. The developers of the original SG version of this app had grabbed a version of Xbae source code and frozen it to be evermore part of the code base.

Well, there were serious problems with that version of Xbae versus the Motif distribution that was installed on the designated Linux platform. Those have pretty much been taken care of, but there's been one thing left: When a particular text edit box is updated, it's supposed to automatically update the corresponding cell in an Xbae-provided matrix table, and that wasn't happening.

Since I'd grabbed all the source code for this stuff I was able to walk through what was going on in the debugger, and I discovered that when calling XmTextFieldSetString() to update the matrix cell, a check made in that function was rejecting the update. The check? Well, a quite reasonable one to make sure that the widget being updated was an XmText widget, so as to ensure that one was actually updating what one thought was being updated.

Okay, waitaminnit. It's checking that the widget is an XmText widget, but the code is expecting it to be an XmTextField widget. And isn't the latter what the XbaeMatrixWidget says is actually used? Or yes. Um, it depends on what you read.

The "What is it?" Xbae Matrix Widget page says: "While XbaeMatrix looks and acts like a grid of XmTextField widgets, it actually contains only one XmTextField."

But the Xbae Matrix Documentation page says: "While XbaeMatrix looks and acts like a grid of XmText widgets, it actually contains only one XmText".

So, the source code says it's an XmText widget. When did that happen?

Spelunking on Google we find:
* Swapped out the XmTextField widget to use the XmText
widget to enable multi line rows and the like.
When did this happen? Version 4.7, from mid-1999. What version of Xbae am I using? 4.60. And this portion of the app was written in early 1997, well prior to the Xbae's conversion from the XmTextField to the XmText widget.

So, I can't say the information wasn't out there, it was properly published in the release notes back then.

But because this is an old application, a "Mines of Moria" project, much of the code hasn't been looked at in years, and so there was never any incentive, hell, any reason, to keep it current with evolving utilities. I expect I'm going to run into this sort of thing again, but what I've got to get onto right now is locating and fixing any additional expectations of XmTextField widgets being used when interacting with the Xbae matrix.

This is gonna be so cool when it's done!