Notes Error - Cannot locate field

I've just launched into another enjoyable spate of Lotus Notes design and development work, for a new customer, and my enthusiasm for Notes is on the boil again!

It has reinforced to me the enormously valuable functionality and flexibility of the basic Lotus Notes platform. Many of the features that having been available since Notes Release 3 or earlier make it ever so easy to develop really powerful workflow and collaboration applications in a flash (compared with most other application development products). It must never be forgotten that the "vintage" capabilities of Notes are still world-beating, while having been augmented by all of the other major features added over recent years.

HOWEVER ...
As with other development environments that haves been around for a while -- and Notes' 15 years is quite ancient compared with some other products -- there are parts of the Notes product that still need some cobwebs cleaned away.

I'm using Domino Designer 6.5.4, and was surprised to see another stupid error message pop up: "Notes Error - Cannot locate field" when I went to open a document. What an inane error message. (You'll find a similar comment in my earlier post: "Note Item not found".) Where were the Lotus quality controllers when this little beast escaped?

If Notes was looking [by name] for a the presence of particular field but couldn't find it, why on earth doesn't the error message clearly state the name of this field thus helping the developer to more quckly locate fix the problem in the code?

As it stands, with the message in its present form you have to either guess which was the offending field or systematically search for it out of the tens or maybe hundereds of fields in the form (and perhaps any subforms that are embedded in it).

What will IBM do about this? Well, I see that they're at last firmly reassuring everybody that the "old" Lotus Notes capabilities will last into the foreseeable future.) See "Hannover": The next release of IBM Lotus for the IBM announcement.) If there's still lots of life in Notes, then surely it's very worthwhile for IBM Lotus Software to go about ridding Notes of little "'nasties" like this one and not just focus on adding more goodies.

Read More

High-tech suffers from terminal seriousness

Read this article at MarketingProfs.com (you might have to create a free resistration for the site): Humor in PR: Can You Hear Me Now? at http://www.marketingprofs.com/5/klotz-guest2.asp

How about you? Are you taking your IT career too seriously? Do you ever introduce any humor into your presentations, reports, web pages, calls, web pages, blogs ... Or are all your work interactions life terminally tedious and boring?

Variety -- and humor -- are the spice of life!

Read More

Removing Comments from Software (a valuable tip)

Hao jiu bu jian le [pinyin Chinese, otherwise “Long time no see”].

I have been enjoying my grandson's first birthday, and also recovering from a 'flu shot (it's winter time here Down Under) and a major disk crash which eventually led me to spend several weeks rebuilding and reorganizing my main system. That's all out of the way, so now I can "get back in the blogging saddle" (with millions of blogs out there, I’m sure my absence wasn’t missed) ...

- - - - -

I've worked with many programming languages over the years (since the 1960s). I've never been a full-time developer -- because I've alwasy had lots of other duties -- but I still develop a fair bit of code as and when the need arises.

And I do try to write brief but useful comments as I go, and to change the comments as the code is maintained over time.

I just came across this valuable article at StickyMinds.com about an aspect of commenting code that is frequently overlooked: Write Sweet-Smelling Comments (by Mike Clark).

- - - - -

And still on the topic of the commenting software ...

I am one of theose "old timers" originally brought up on languages like FORTRAN and PL/I and BASIC (the original Dartmouth version, not the Visual Basic form) and COBOL and ASSEMBLER were in vogue. In those days, you wrote everything as source code "in the open" and placed your comments in that source code.

The source code was originally punched onto paper tape or cards or other inconvenient media types, you would often get only one overnight run to complile and test your program, and had to wait until the next day to wade a printout and see what had happened. Get a comma out of place, and you'd have to wait until the next night for another run. You learned to code extremely carefully and to be extremely patient! But at least all of your code was right there in front of you on the printed page, and not tucked away in obscure places.

Most assuredly I don't want to turn the clock back, but I do reckon that modern development environments in certain respects tend not to lend themselves to good coding practices including good commenting. I say this because there's usually a bunch of visual and other structures that are being developed that typically do not have any place for embedding detailed relevant comments. So maintaining modern applications can turn into a nightmare because there's no embedded commentary about the structure and behavious of these ancillary structures.

I know it from first-had experience with trying to maintain/improve such applications. Heck, I sometimes even have trouble understanding my own work after the passage of not too much time, because I had no decent way of embedding comments everywhere they were needed and so when I came back to it had trouble remembering all of the "nooks and crannies" that needed to be worked on (or at lthe very least checked again) to do proper maintenance.

Sometimes there would be design properties -- and even deeply embedded code -- lurking in dark and forgotten spots, sometimes only to be discovered by chance later on! (This might have been a non-issue if the client had been willing to pay for the many days or weeks of time needed to comprehensively document all of these things, but more often than not such detailed documentation is not budgeted for.)

Hence let me make a call to action for tools vendors all and sundry to build better commenting facilities into ALL design elements that form part of their application design and developmentproducts. This could be Lotus Notes, or Java, or .NET, or just about any other product from any vendor -- you name it!

Read More