Software, Technology, Business & Life

If Yogi Berra thought about software and testing, maybe he’d say:

Unless you know it’s right, you don’t know it’s right.

To ponder…

A very interesting question–with very interesting answers–on StackOverflow.com:

What’s your most controversial programming opinion?

(Via Gadgetopia.)

Step away from the computer.

I get some of my best ideas when I step away from the computer for a few hours and carry on with life (letting the problem mull over in the back of my mind). Maybe you’ve experienced this, too.

If software is much more about good ideas than BFI (and I’m convinced that it is), then stepping away from the computer is a wonderful thing all around.

When I was in college, I rented a friend’s computer for a year. It had an amazing ten megabyte hard drive, and I loved it! I didn’t have to boot it with two single-sided single-density 360KB floppy disks. It was great!

And ten whole megabytes! I figured I could type non-stop for decades before I filled it up. How cool was that?

Times have changed, haven’t they?

Update, 3/18 – Full disclosure, FYI: 105 GB of the disk space you see are consumed by virtual hard disks across 14 VMWare virtual machines.

Now that screens are wide, I find vertical space more precious. So I put my XP task bar on the left side of the screen.

It’s interesting how many programs now come up underneath it. Commercial packages with large user bases. I’m sure they mind the task bar when it’s at the bottom of the screen, but not here.

While it’s not a big deal (to me at least–just a tiny annoyance), it shows how we make implicit assumptions about our world. Sometimes those assumptions are fine. Sometimes not.

I’ve made plenty myself.

Also, I’ve not encountered a program that refuses to run or throws itself off the top or bottom of the screen because of this. That’s a possibility. (I need to keep this in mind if I find a program behaving badly with its screen position.)

Twice in the last three weeks I’ve had software I’m developing crash badly before main() even gets control. Though completely separate situations, each had to do with a third-party package.

Fortunately we were able to work through each in reasonably short order, still using the package without the problem.

One was a proprietary package, and the vendor was willing (and able) to work with us. I wound up iterating to the problem’s source: an issue between Microsoft’s managed and non-managed C++. When this package included Microsoft’s ATLComTime.h, my managed C++/CLI app wouldn’t start. Otherwise it would. (Visual Studio’s “Use of ATL” and “Minimize CRT Use in ATL” had no effect.) We worked around it.

The other package was boost’s serialization. Using the same templated serialize() function in two different compilation modules under CygWin would cause a SIGSEGV on startup. Gdb showed the problem to be in

boost::serialization::extended_type_info::extended_type_info ()

The production environment (FreeBSD) worked fine, but the convenience of CygWin drove me to look for a solution. Here it is:

BOOST_CLASS_TYPE_INFO(MyClass, extended_type_info_no_rtti<MyClass>)

This solution should work on all platforms.

Very disconcerting when something crashes even before main() starts, and more so when it’s a third-party package. Common components are necessary and worth this trouble, but I expect more of it as time marches on.

The very useful CastleCops web-site seems to be defunct as of late December, for “an as yet undetermined reason.”

Fare thee well.

Their databases can now be found on SystemLookup.com.

Regarding Microsoft’s .NET OdbcConnection Class:

You should always explicitly close any open OdbcConnection objects by calling Close or Dispose before the OdbcConnection object goes out of scope, or by placing the connection within a Using statement. Not doing this leaves the freeing of these native resources to garbage collection. It might not free them immediately. This, in turn, can eventually cause the underlying driver to run out of resources or reach a maximum limit. This has resulted in intermittent failures. … Explicitly closing the connections allows for a more efficient use of native resources, enhancing scalability and improving overall application performance.

Good to know.

.NET has cool things about it, but this philosophy of “don’t worry about cleaning up after yourself–we’ve gotcha covered” still sticks in my craw.

You can’t save me from managing my own resources, no matter how hard you try. And I’m pretty convinced that having to be constantly mindful of a non-deterministic garbage-collector isn’t any better than just doing it all myself. (Call me old-school, I guess.)

See also Who Manages the Managed Language?

I got a huge kick out of this line from Sunday’s Dilbert:

I’ve seen a lot of C and C++ source-code in my career.

I’ve never seen anyone write a do while loop without using curly braces. Until now:

do cin.ignore(1024); while (cin.gcount() == 1024);

It’s one of those unconscious things, I guess. If you asked me if you could write it that way, I would have supposed so.

I don’t mean any criticism: it’s fine. It’s clear. Just amused (at myself) that I’ve never seen it.