Steve Trefethen just posted this little tidbit on how to have Windows Search find your Delphi files. While I seem to recall seeing this behavior some time ago, I didn't dig into it and kept using my trusty grep to find text in files. Maybe this is what I needed to start using a GUI instead!

I'm not sure which entry in Anders Ohlsson's blog is more interesting: Bill Gates stops by the Borland booth or C#Builder wins "Best Development Tool

Some posts in the Borland newsgroups have got me thinking about what a professional programmer's responsibility is when a bug occurs in code that is not theirs. The result is this list of guidelines and principles. The main thrust of this list assumes that a programmer is a technical person by nature. They do not need to be coddled and led by the hand.

• Most bugs that are perceived to be bugs in a vendor's codebase, are usually not the vendor's fault. The first Maxim of Debugging is: The bug is most likely in your code.
• Make the effort to work with the vendor of the bug to provide a clear, minimized, reproducible test case that demonstrates the bug. Expecting the vendor to fix a bug that they don't know about is just silly. If the bug is important to you, report it in a thorough manner.
• If the bug is a true show-stopper (a term that is much over-used, in my opinion), then find a work-around. There are always other ways to express what a program should do. Rarely is a bug so serious that you can - in good faith - throw your hands up in the air and claim defeat. A professional programmer looks at this as an opportunity to distinguish themselves. If you code the work-around in a non-intrusive way, you can remove it easily when the vendor does fix the problem.
• If you have source code for the library, debug it. It will help you understand exactly what the bug is, and hopefully, help you down the road by preventing you from making the same mistake. This can also help in bug reporting and finding a work around.
• If you don't have source code, you can still make assumptions about what part of the black box isn't working and write a test case to prove that. If your assumptions are wrong, modify the test case.

While bugs are an inevitable fact of life, it's how you deal with them that truly defines what kind of programmer you are. Everyone has deadlines, but taking time out of your schedule to work with your vendors to resolve problems is part of your responsibility as a professional programmer.

I've been playing with ObjectSpaces (OS) lately. I like the idea and the implementation is pretty good. The main limitations I see are:

• For the foreseeable future, it will only talk to MSSQL (and it's various flavors). If they're writing an Object Persistence Framework (OPF), shouldn't someone have mentioned that they should probably abstract out the DB-specific stuff? I understand this is 1.0, but please, that is so limiting that it almost makes OS unusable. Do I really want to have DB lock-in to MSSQL? I don't think so.
• It is tied to Whidbey. With the delay shipping Whidbey, this means that we won't see a production-capable version of ObjectSpaces until Q1 of 2005! That is a long time to wait to get OPF. Microsoft should find a way to unbundle certain pieces of the PDC preview - such as ASP.NET 2.0 and OS - and deliver them on a schedule that is independent of an IDE release.

At any rate, here is some good material to help get up to speed on OS:

• PDC presentation
• Matt Warren's Blog
• Gopalan Suresh Raj
• Getting Started with ObjectSpaces
• Overview of the ObjectSpaces Architecture

I plan on writing some articles detailing my experiences (good and bad!) with OS, discuss alternative OPFs, including ECO (available in C#Builder and Delphi 8), and flesh out some best practices when using this kind of technology.

Scott Nonnenberg published some details on How to write custom visualizers for Whidbey. This seems like a very powerful capability for debugging.

Here is another open source project worth checking out. If you want to do some VNC development using Delphi, check this project out.

MidEss is still alive and kicking. Not much has happened with it lately, but that's due to it being rather stable. Be sure to leave a comment here or on SourceForge if you have bugs and/or features that you want to see incroporated into this project.

Also, in case you didn't know, SourceForge has RSS feeds for each project. For example, to subscribe to an RSS feed of MidEss releases, click here. Check out all of the RSS feeds out for MidEss.

This is a rather good overview of different traits that developers possess as they go through the levels of proficiency.