Long Time No See

My head pokes out of the shell again...

Earth Date 2009.11.06

Posted by Rich Wheadon | Permalink




All those glorious promises of posting more often, sharing more, and just generally keeping something fresh on the blog have been broken. It appears I was a little overzealous for my own good… or maybe I just let too much creep into life and stuff started slipping.



And slipping is what I’ll dwell on today.



I’ve been a Lotus Notes/Domino developer since 1996, picking up the craft in a great shop called Universal Data Consultants. I’m thankful for the experiences I gained as I worked my way through a great beginner’s platform (IMHO). In the past 2 or 3 years I’ve been focusing more and more on other technologies and languages. The continual progression of my skills as I’ve been working through agile methodologies and more test-driven development has been quite challenging. I’ve moved from development on a Windows PC to primarily functioning on Mac and Linux machines, I use a text editor for nearly everything (TextMate is the one of choice for me on the Mac). Tons more could be said here, but the point is that I’ve been moving in what I believe to be forward direction.



Since Lotus Notes development really is still my core competency, with a bunch of JavaScript and web development ranking close therein, I have kept myself highly available since those skills are still valuable to the company I work for. Recently I’ve become very disappointed in that platform I once held in the very highest of esteem. It seems the “swiss army knife” that Lotus Notes is has finally become an achilles heel to me. You see, even though I have moved forward in the skills and technologies I am adding to my portfolio as a developer, IBM has simply allowed the development tools for Lotus applications to stagnate. The ONLY toolset available for Lotus Notes developers to use is called the “Domino Designer”(DD). Any developer using modern languages and modern tools will end up staring at DD in disbelief, often commenting that they hadn’t seen anything that bad in 10 years.



Hence, my topic of slipping.



The target audience of this post will know a little about programming and a little about the IBM Domino Designer product. I will focus only on the DD interface flaws from a LotusScript perspective, the DD interface also has programming context for formula(macro) language, Java, and JavaScript



Productivity slipping due to lost work I have lately been offended as I go through the painful process of writing what I hope to be good code in DD. The first really frustrating point is reached when I can’t save my code. In the IBM Designer tool built with a special focus on torturous UI implementation you can not save your code unless it can compile. I have had several occasions where the DD has crashed WHILE I was writing code that could not yet pass the compiler and therefore would not save. This meant that I lost all of my hard work and countless hours of productive progress for my company. Of course, all of you resident Notes Developers just kind of chuckle and say “write smaller code”. Chuckle all you want… you are in denial if you don’t agree that NO autosave and NO save unless the code can compile in the Designer is a really, really bad move. I must add, this is a behavior that Notes developers have been complaining about even before I began working with the platform.



Productivity slipping due to cumbersome IDE The pitiful truth about Domino Designer which I have finally realized in the past year is that it isn’t even as good as a well built text editor. Now, for you notepad or wordpad folks I need to emphasize immediately that those are not good text editors (I don’t care how many Java and Ruby “Hello World” programs you’ve done in them). I’m talking about editors with developer plugins and at a minimum line numbers. I have been using TextMate on the Mac, but Windows has TextPad and then there are some cross platform tools like JEdit and others. Just to illustrate some efficiencies in TextMate over the DD:




  1. Ctrl+Shift+K = Deletes the present line… the WHOLE line (no HOME then Shift+Right Arrow then DEL).


  2. Ctrl+Shift+D = Duplicate the present line… the WHOLE line (no HOME then Shift+Right Arrow then Ctrl+C then END then RETURN then Ctrl+V)


  3. Block selection


  4. Column Mode for text manipulation


  5. Block Tabbing (indention)


  6. GREP the project for a search term. (Either text or regex)



I could go on, but this isn’t a story about TextMate, it’s a fuzzy picture of Domino Designer… so let me shift gears back to that toolset. Mind you the list below isn’t exhaustive, just what is coming to memory as I jott this post.



1. No line numbers, okay wait, I’m wrong. Domino Designer has line numbers in that it displays the line you are on in a little box on the status bar. This means you have to scroll-click scroll-click through the editor box until you see something close to your target line number in that little block, then you can use the arrow key to navigate up or down until you reach the target line. Ridiculous.



Line Numbering difference



2. Undo in the Domino Designer is a complete crap shoot. You just never know what’s going to happen, and if you EVER try to to a reverse undo you are totally set up for failure.



3. Search/Replace is modal, although this is not an epic fail I find it so frustrating that I dread needing to use it.



4. No class browser. When you want to create a function or sub in the LotusScript programming environment you place your cursor in the Options or Declaration section and type “Function something_or_another( valIN as string )” and hit enter… the function shows up in the navigation tree to the left of your programming window. All good. So, you’ve got this object oriented programming thing down and you find that wrapping your own little classes really helps. So you go to the Declaration section of a LotusScript library and type “Public Class ThisIsGoingToBeGreat” and hit enter. Nothing special happens, you are still in the Declarations section and DD was really nice to add “End Class” under your cursor. Then you add a “new” sub, a couple helper functions, maybe some property getters and setters. About the time you extend your class you realize this is becoming one big ugly mash up of code. Nothing in the navigation tree, nothing. This is the point where you are beginning to realize that the folks who wrote this piece must either not care about helping developers, or it was nearly 5PM on a friday when they got to this point and by the time they returned on monday morning to finish the code too many brain cells had been killed by shooters and 150 flavors of beer. You lose.



5. No built in stack trace or exception handling. For an illustration lets say we are testing some code and it falls into an error. After launching the code you get a prompt:



type_mismatch



Not very helpful. It’s at this point you realize there’s no stack trace, nothing but that pitiful little dialog that tells you the equivalent of “null pointer” with “no root cause” or maybe one of those really cool “the application has failed with the error ‘could not allocate memory’”. Now stop your crying and go write a bunch of exception handling code sissy boy. You should be getting used to failure now, and please don’t waste your time thinking things are going to get better.



6. No “real” line numbering. I know I repeated this one, but neglecting to give this to the Notes developer community is just so bad that repeating the sin is important to me.



7. Global Variables. Global variables are bad (IMHO). Here is where the Lotus Notes developer community loads 5 barrels of the 357 with Glazers and spins the dial. Global Variables are a powerful area of the Domino IDE, and something not common in most structured programming outside statics and system constants. Start declaring variables in this area and you’ve (by default) just begun creating the pinnacle of mutability. These variables are now accessible by all functions within the existing library, and any libraries that use this library. This doesn’t seem so bad at first since really the most important use of the Declarations section (to me) is creating custom classes. BUT! I often find that global variables are a magnet for lazy and irresponsible programmers, for example just this week I found the following “free-floating public” global variables declared: i, f, doc, temp, db, view, session, s, x, y, flag. If you are a Notes programmer and you don’t immediately recognize those variable as a near mortal sin to application development then I suggest pink slipping yourself today.
Needless to say, despite programmer idiocy… This is pretty bad. And stating Lotus got this from VB doesn’t make it right.



8. Eager block evaluation. I don’t know whether I can call this good or bad, but I can guarantee that it causes a lot of confusion to developers who sometimes see their logic work and sometimes it causes runtime errors for no good reason. If this is the first time you have heard the term “eager evaluation” then here’s the crash course:
Eager validation will execute/evaluate all of the logic in an expression whether it’s necessary or not. For example,



    If 15 > 20 AND mydoc.favoriteColor(0)=3 then  
...some code here...
End If


would throw a runtime error ‘Type Mismatch’ if mydoc.attempts is missing or is a string rather than a number. The significant factor is that it NEVER passed the first test so the runtime should have never found the type mismatch.
Not eager (lazy?) validation would have just run until fail on the IF, so in the case above lazy validation would have just given up.



9. No watch window in the script debugger. I’m going to ignore almost everything else about the LotusScript debugger today and focus on one HUGE deficiency. There is no interactive watch window, and for that sake no way to find out what an expression is evaluating to in the running script that you might have open for debugging. This means that if you have some code that says



If mydoc.createdDate(0) = Yesterday then
processRecord( mydoc )


and you have that line set as a breakpoint then you have no way of quickly finding our what the “real” value of mydoc.createdDate or “Yesterday” is at runtime. And if you have over 255 fields on the document then it could be impossible to get that value. This one shortcoming in the IDE makes it necessary for the Notes developer to be very verbose and write lots of variables into the code, just so we can debug. Because if it isn’t a variable it likely isn’t going to be available for you in the debugger.



10. Variants. Finally, only because my target has been to stop at 10. Variants. Who in their right mind ever created the programming disaster that is the Variant data type. Even worse, who thought it would be a really good idea to have the default datatype as Variant? Nothing like a defined data type that could be any of the data types at any time. For the lazy programmer there is nothing better than a good old globally declared Variant, just make it whatever you want it to be no matter how frustrating it is to the person who has to inherit the code base. Even better, let’s forget declaring anything since that will instantly guarantee that you can create variables on the fly and not worry about what you want the data type to be!



That’s about all I have the stomach to cover today. I could go into really bad code I’ve had to support and poor project management, but that’s for another blog.