And when Fazza retired, it was Uncle Oren who inherited the old fellow's toolbox... The toolbox was what we called a big 'un. It had three levels, the top two removable, all three containing little drawers as cunning as Chinese boxes. It was handmade, of course. Dark wooden slats were bound together by tiny nails and strips of brass. The lid was held down by big latches; to my child's eye they looked like the latches on a giant's lunchbox...
One summer day I helped Uncle Oren replace a broken screen on the far side of the house. I might have been eight or nine at the time. I remember following him with the replacement screen balanced on my head, like a native bearer in a Tarzan movie. He had the toolbox by the grabhandles, horsing it along at thigh level...
We finally reached the window with the broken screen and he set the toolbox down with an audible sigh of relief. When Dave and I tried to lift it from its place on the garage floor, each of us holding one of the handles, we could barely budge it. Of course, we were just little kids back then, but even so I'd guess that Fazza's fully loaded toolbox weighed between eighty and a hundred and twenty pounds.
Uncle Oren let me undo the big latches. The common tools were all on the top layer of the box. There was a hammer, a saw, the pliers, a couple of sized wrenches and an adjustable; there was a level with that mystic yellow window in the middle, a drill (the various bits were neatly drawered farther down in the depths), and two screwdrivers. Uncle Oren asked me for a screwdriver.
"Which one?" I asked.
"Either-or," he replied.
The broken screen was held on by loophead screws, and it really didn't matter whether he used a regular screwdriver or the Phillips on them; with loopheads you just stuck the screwdriver's barrel through the hole at the top of the screw and then spun it the way you spin a tire iron once you've got the lugnuts loose.
Uncle Oren took the screws out -- there were eight, which he handed to me for safekeeping -- and then removed the old screen. He set it against the house and held up the new one. The holes in the screen's frame mated up neatly with the holes in the window-frame. Uncle Oren grunted with approval when he saw this. He took the loophead screws back from me, one after the other, got them started with his fingers, then tightened them down just as he'd loosened them, by inserting the screwdriver's barrel through the loops and turning them.
When the screen was secure, Uncle Oren gave me the screwdriver and told me to put it back in the toolbox and "latch her up." I did, but I was puzzled. I asked him why he'd lugged Fazza's toolbox all the way around the house, if all he'd needed was that one screwdriver. He could have carried a screwdriver in the back pocket of his khakis.
"Yeah, but Stevie," he said, bending to grasp one of the handles, "I didn't know what else I might find to do once I got out here, did I? It's best to have your tools with you. If you don't, you're apt to find something you didn't expect and get discouraged."
I want to suggest to you that to write to the best of your abilities, it behooves you to construct your own toolbox and then build up enough muscle so you can carry it with you. Then, instead of looking at a hard job and getting discouraged, you will perhaps seize the correct tool and get immediately to work.
Even though he's using the toolbox as a metaphor for the art of writing, it applies equally well to the art of programming.
And the On Writing book is an excellent overall read, by the way. It's not the terrifying fiction that Stephen King is known for; rather, it's a memoir of the things in his life that formed him as a writer, and some great discussions on how to write a story. Definitely recommended reading.
It looks like a lot of the discussion took some strange turns and went way off-road, with talk of J2EE and bytecode generation and general "my platform is so much better than your platform" arguments.
Here's my take on using Java in Lotus Notes:
You should use Java when it's the right tool for the job. You should learn it so you know how to use it when you need it.
That's it in a nutshell. No esoteric arguments about the beauty of Object Oriented programming or unit testing or whatever. Java is a tool, just like any programming language. When you're comparing LotusScript to Java, you're not comparing two brands of hammers to figure out which one is best. You're comparing a hammer and a wrench. There are certain nails you can hammer into a wall with a wrench, and certain bolts you can pry out with a hammer, but in general you should be using the right tool for the job.
"A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in. Should I use an old shoe or a glass bottle?"
a) It depends. If you are looking to pound a small (20lb) nail in something like drywall, you'll find it much easier to use the bottle, especially if the shoe is dirty. However, if you are trying to drive a heavy nail into some wood, go with the shoe: the bottle with shatter in your hand.
b) There is something fundamentally wrong with the way you are building; you need to use real tools. Yes, it may involve a trip to the toolbox (or even to the hardware store), but doing it the right way is going to save a lot of time, money, and aggravation through the lifecycle of your product. You need to stop building things for money until you understand the basics of construction.
As far as determining the situations where Java is a better choice than LotusScript, I outlined several cases over 3 years ago: times when you need to use threads or sockets or the vast array of external libraries that have been written in Java, for instance. I recently put some working examples in the Java Jumpstart samples database from my and Tom's session at Lotusphere. Take a look at the modal dialog box with a progress bar or the 3-D pie chart, and tell me how you would reasonably do that with LotusScript.
Of course, I'm completely ignoring the argument that we should be learning Java and Eclipse to get ready for Hannover. I think it's a great point and it's absolutely true, but unfortunately it's one that's lost on most people who are already swamped in their current jobs and have a hard enough time keeping up with the here and now, rather than planning even 2 months down the road. I can appreciate that; I think we all can.
Do I think that IBM needs to do a better job at actively pushing Notes/Domino developers into Java and Eclipse (which was Jack Dausman's original point)? Absolutely! And not the "why don't you learn Workplace?" kind of pushing, because that's jumping way too far forward. Maybe more official training classes on using Java and/or Eclipse with Notes, some webinars on cool stuff you can do right now in your current Notes environment, or -- if IBM wants to keep Workplace on the screen -- even good examples of how to integrate Notes and Workplace today. Heck, maybe they could make the Lotusphere Java Jumpstart session that Tom and I did a freely downloadable video! ;-)
On the other hand, I also think that Notes developers need to take their own initiative and plan for the future that they can see coming. See Rich Schwartz's latest blog entry for some perspective on accepting change, including his great Bob Dylan quote, "admit that the waters around you have grown... you better start swimmin' or you'll sink like a stone."
Yes, you'll be able to natively use LotusScript in Hannover, just like you can now. Just like you can still go to Blockbuster and rent VHS tapes instead of DVDs. The old technology is still there, and it still works, but shouldn't you at least start looking at some of the new technology? DVD players are cheap, and you don't have to get rid of your VCR or old tapes, because you actually can have both. And if you have both, then you can borrow your co-worker's DVDs as well as your Mom's old tapes and watch either one.
It's not an either-or question, it's a matter of choice. But you don't really have choice if only know how to use one tool.
Not that I have a problem with that. I think it's a great idea to have a way for people to report and track bugs in a product. The Bugzilla model is a good one.
If you're not familiar with the Bugzilla product, here's the "About" page that you can click through to browse around. Two working implementations I can think of off the top of my head are at Mozilla and WineHQ.
Bugzilla normally has kind of a plain, ugly interface though. It'll be interesting to see how Microsoft ends up managing their look and feel (since they've got some good UI designers in-house) and whether a nice-looking Microsoft interface might spur a more active community of Bugzilla skinners who can make the pages and forms seem a little less raw.
Then again, maybe there already is an active Bugzilla skinner community out there. A quick Google search didn't turn up any promising leads, but that doesn't mean anything.
UPDATE: slightly feisty discussion about all this on Asa Dotzler's mozillazine blog.
Rather, I'd like to point out that the state of Indiana is finally trying to straighten out it's extra-weird DST situation. Come April 2nd, the entire state will be on Daylight Saving Time.
That may sound unbelievably trivial, but the current/old setup was that part of the state is in the Central time zone and part is in the Eastern time zone and some of the state recognized DST but not all of it. I had a friend who was a salesperson in the Indianapolis area, and he said it was really hard to keep appointments straight if you had clients all over the state.
The new setup still has the time zone split, but everyone will finally be on DST together. Here's some information from a recent IBM technote (and it's as good a summary as any I've seen):
State of Indiana time zone changes beginning April 2, 2006
Prior to April 2, 2006, Indiana has had a complex time zone fabric consisting of three different time zones, with Daylight Saving Time observed in some, but not all areas.
- The northwestern corner of the state, close to Chicago, Illinois, follows Central Standard Time (CST) and observes Central Daylight Time (CDT) in the summer months. The same is true of the southwestern tip of the state, near St. Louis, Missouri.
- A few counties in the southeastern part of the state follow Eastern Standard Time (EST) and observe Eastern Daylight Time (EDT) in the summer months.
- The majority of the state, including the capital, Indianapolis, follows what the Windows operating system calls the "Indiana (East)" time zone, which is GMT -5 (Eastern Time Zone) but does not observe DST. This means that in the winter months, Indianapolis has the same time as the states to the east of it (Michigan, Ohio, and the US East Coast), while in the summer months, Indianapolis has the same time as the state to the west of it (Illinois), so that they are an hour behind the East Coast.
Upcoming changes to Indiana time zones and DST:
In April 2006, the central part of the state, here referred to as "Indianapolis", will change permanently from the "Indiana (East)" time zone to Eastern Time. This portion of the state will remain in GMT-5, but will start observing DST in the same way as the eastern states and a few southeastern Indiana counties already do. They will join DST for the first time on April 2, 2006, when most of the US changes to DST. The change in Indiana is a permanent change of time zone.
For more information, refer to the following map of Indiana counties depicting the time zones as of April 2, 2006:
Of course, in 2007 the DST schedule for the entire USA will change, so we Americans will have plenty more fun with this stuff next year.
Oh, and on a related note Australia is delaying the ending of their Daylight Saving Time schedule by a week this year to accomodate the Commonwealth Games, but if that affects you and you didn't know it then you've probably already experienced any problems you're going to experience (because this week is the extra week).
I've sent a few e-mails back and forth to the author of the LDD forum post that started this whole thing -- he was very nice, and gave me a lot of good information -- and I found the following:
So... even though I realize there are a LOT of people using the OpenLog code without problems, if anyone is still concerned about the LSI_Info function, I am making available a modified version of the OpenLog template:
I have removed most of the calls to LSI_Info (where they could be replaced with calls to GetThreadInfo), and added a global flag called NoLSIStackTrace that you can set to "True" if you want to disable the remaining instance of LSI_Info (the one that gets the stack trace). I've also added some code that should allow OpenLog to log errors to Domino Domain Monitor (DDM) in Notes 7.
There are a lot of other changes I have on my list, but those are likely to make it to a 2.0 release because they'll require more testing -- and I really want to make sure I don't break anything, because I know that a lot of people are relying on this in production environments. I've had some great suggestions from users of the database, but backwards-compatibility is kind of tricky sometimes. This release is really about getting rid of LSI_Info for people who are concerned.
I'm going to float the new template out there as a 1.1 BETA version, if anyone is immediately worried about the LSI_Info calls (or if you just want to play with the DDM logging). There are also a few minor bug fixes. After I've had a little more chance to test it and get some feedback, I'll post a non-beta version to the OpenNTF site as an "official" download.
Please note that this is a copy of the current version of OpenLog, not a replica, so it shouldn't overwrite anything if you move it to your server. Also, I've changed the template name to "OpenLog 1.1 BETA", so you'll need to make that adjustment as well. Most likely, your upgrade process will be:
Good luck, and please test this on a development server first!!! If you have any questions I'll be out of pocket for much of next week, but I'll check e-mail and comments on this entry as much as possible.
Beyond the strong out-of-the-box aspects of Lotus Notes security -- databases ACLs, Readers and Authors fields, built-in PKI and encryption options, etc. -- there are a lot of interesting things you can do to secure your interaction with "the outside world". Here are a few:
You can either self-certify your server (which means the users will get prompted with an "are you sure you trust this certificate?") or you can buy one from a registrar whose root certificates are already included with modern browsers. Some of these (like Verisign and Thawte) are very expensive, but you can also get a GoDaddy certificate for very little money -- it's recognized by all modern browsers and IBM even has a Technote describing how to use a GoDaddy SSL certificate. I've used one, and it worked perfectly.
There are several steps involved in the setup process, but it's well documented in a few places. For example, here's a short set of instructions, and here are some longer instructions with a lot more detail. In Notes 7 you can even use S/MIME from iNotes/DWA, and there's an API interface so you can call the encryption routines from your own programs.
Those are the things I can think of off the top of my head. I'm sure there are more, but that will at least whet your whistle.
UPDATE: Per Henrik Lausten mentioned that you can also have SSL-encrypted IIOP and LDAP connections. I never knew that. So then I checked the Domino Admin Help again, and saw that all of these protocols can be configured for SSL:
Coolness. And again, it's all built-in to the product.
Here's the whole post, as it exists in this moment in time:
For those who use OpenLog or have written code with LSI_Info:
IBM has recently told us that our open source database OpenLog that calls the function LSI_Info is not thread safe. LSI_Info is an internal debug code and cause memory issues such as heap corruption.
We have had to remove the OpenLog code from our Domino application to ensure its reliability.
I am hoping that IBM/Lotus will provide a thread-safe solution because we do rely on this code.
All I can say is that I've talked to a lot of people who have included the OpenLog code in a lot of databases, and I've never heard of any kind of memory issues. Which isn't to say that they don't exist (they may and they may not), simply that it doesn't correspond with any anecdotal evidence that I'm aware of.
Also, the LDD post never said whether there was actually a memory problem in the first place. It only says that they removed the OpenLog code "to ensure [the database's] reliability". Which may mean that this was a theoretical problem rather than a real one. Because Normunds Kalnberzins asked for more specifics in a follow-up post and didn't get any, I went ahead and e-mailed the author of the post to try to get some additional information.
If any of my IBM buddies out there could ask around for me, I'd appreciate it. If this really is a problem, I'd like to try to work around it. If not, I'd rather not mess around with code that's not broken.
In other words, I want to make sure it's not like when Lotus Support told Mikkel Heisterberg that there was a 100MB recommended limit on Notes mail databases (which Ed Brill quickly determined was completely incorrect, as experience told all of us it was).
I was asked about TLS (think https/SSL for e-mail), and whether or not Domino supports it. I thought to myself, "Self, didn't Chris Linfoot just post something about that?". Why yes he did. In fact, Chris Linfoot actually posted step by step instructions for setting up SMTP TLS on Domino for his most recent SnTT entry!
That's some good stuff right there.
As I see it, the impetus behind Web 2.0 is the drive to make the do-it-yourself Internet more efficient. And this is what is mostly overlooked by the folks who hope to create a new dot-com boom by promoting excitement about Web 2.0... They don't get it. The latest buzzwords just capture an idea that has been passed along for decades: "If you want something done right, do it yourself." Welcome to Web 2.0. You're on your own!
While I wouldn't agree that this sums up my vague understanding of Web 2.0, I think it's a point that's very well said. Greasemonkey, Web APIs, mashups, aggregation, tagging -- essentially a user-controlled web experience. Bringing all the distributed data together in whatever way makes sense for you. That ends up being a very powerful idea.
It did end up being a little long, but for any of you ADD-types out there who may have trouble focusing on anything that's more than about 5 minutes in duration, it really is worth listening all the way to the end. In the last 15 minutes or so (maybe more), Bruce and I went through some of the "questions from the audience", and there's good information there. A few little tidbits I'll point out for you:
Otherwise, please download and listen at your leisure.
There are 3 common ways to deal with reading CSV files:
While all of these techniques work, I'd like to offer up a fourth option. About a year and a half ago, without much announcement, I put the CSVReader class on my Notes Tips page. It was sort of a side note to accompany some code that converts CSV files to XML, but I've actually found that I've used the CSVReader code a fair bit (CSV to XML was something I played with, but in practice the XML parsing was too much overhead).
Here's some example code, to let you see how it works:
Use "CSVReader Script Library" Dim fileName As String Dim headerArray As Variant Dim dataArray As Variant Dim reader As CSVReader fileName = "C:\testdata.csv" Set reader = New CSVReader(fileName) '** for our example file, the first non-blank line is a set of '** column headers headerArray = reader.getNextLine Do Until reader.isEOF dataArray = reader.getNextLine If Not Isnull(dataArray) Then Print headerArray(0) & " = " & dataArray(0) End If Loop
That's pretty much it. Normally you'd be doing some ForAll loops or something, but that's the basic structure. By default the delimiter is a comma and the quoted string character is a quote, but you can change those at runtime if you need to (like if it's a tab-delimited file). Blank lines are skipped and delimiter characters within quoted strings are handled properly.
In my experience, comma-delimited files are at least as common as XML for a "neutral" text data format, sometimes more common. So maybe this will help you out a little if you need to accept data from an external non-database system (like an Excel spreadsheet :-).
technorati tag: Show-n-tell thursday
Anyway, one of my wife's friends told her the other day that she was going to give up pessimism for Lent, but she wasn't sure if she'd be able to do it.
I just laughed and laughed... Oh, the irony.