IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Complete nonsenseI've been thinking about the comments people have been making about the difficulty of correcting performance due to poor design after the fact. You're making some excellent points, and I respect your experience with watching the evolution (or lack thereof) of customer applications.

It certainly sounds like nothing we can do as is effective in improving application performance, as making sure that the people who design them have every opportunity and encouragement to do things right in the first place. As you might have guessed from the title of my blog, this has been my interest all along.

There are two ways I can think of offhand to address this -- the first and, I think more important, is better education. The other is better, more automated tools that can be applied automatically during development.

Besides the discussion here, what got me thinking about this is an example from a customer where the word NULL was used in a formula -- not as a field name, but as if it had some special meaning. For the record, NULL isn't a special word in a formula. It's treated the same as any other name: if you have a field named Null in your document, it gives the value of the field, otherwise it returns "". Instead of NULL, you could use any other word which isn't a fieldname, such as Hüperdoo or Squizzle. In fact, these are better choices because it's less likely that someone will later add a field with these names, making your existing formulas fail. Instead, use "". Then the formula can't be broken by later design changes.

I kind of expect that nearly all of you already know this, but it serves to further my topic. I'm well aware that people don't all come up with this wrong idea independently. They're doing it because someone has taught them to do it (see cartoon). I hope, after all these years, it's not official education materials from Lotus, or Lotus-certified trainers. But to make sure of that, I've signed up to review the training materials that we're putting out with version 8.0 -- the update courses and (more important for our purposes here) the start-from-scratch classes. I think I'll try to talk Rocky Oliver into doing the same. It's not only whether the training mentions the things you need to know, but whether the code samples and exercise answers reflect good design.

I've long been doing the same kind of review of the Designer help -- as I mentioned recently as regards supplying a date to the Search method -- but there is kind of a lot of it and only one of me, so I want to again urge you, if you see something in the help that you know is dumb, please use that feedback link.

The other side of education is certification. I'd like it to be difficult to get certified without a grounding in best practices. So I signed up to review the certification test questions also -- I'll probably suggest some additional ones, but don't worry -- there will be no puns. (Note: they might require me to take the version 7 update exam first. Heh.)

Then from the tools standpoint -- what I would really like to see someone come up with is a product that we might call, let's say, "Training Wheels for Lotus Notes." Whenever you went to save a design note, it would execute some code to analyze the information about to be saved, and come up with a screen of warnings. "Field 'Retry_d' is Computed, but it's just a copy of 'Retry'. You should probably make it 'Computed for Display'" or "Action 'Add Comment', Sub MarkAll, line 14: See Designer help for performance advisory on GetNthDocument method." The user could then opt to save or keep editing (and if the screen of warnings could stay up while they're editing, for reference, that would be ideal). Some of these hints might require longer explanations that the user could read by clicking a link: "The use of @Now and @Today in a view selection formula will drastically slow your application. Click here for details and alternative design suggestions."

Andre Guirard | 10 May 2007 01:15:00 AM ET | Man-cave, Plymouth, MN, USA | Comments (10)


 Comments

1) Don’t assume that Lotus ’Official’ courseware always gets it right!
Melissa Snell | 5/10/2007 6:18:13 AM

As a CLI I've occasionally seen a few interesting statements that have been 'missed', such as the R5 (I think it was) course which stated that Readers fields did not work in local databases (erm - ever heard of 'Enforce consistent ACL?'). Thankfully this particular one was corrected in training materials for later versions!

I wuold like to see a higher level course aimed at planning and implementing Enterprise Lotus Notes applications. It is generally in the jump from a simple 2-5 day app to a 20-30+ day app that Lotus Notes gets bad press because it is frequently not implemented correctly or the project fails because of a lack of understanding of all the interactions that need to be considered. IMHO you can't use the same approach for both projects and expect to be successful.

2) Tools. Why don’t we learn from Java experience and maturity
Ricardo Lucio da Silva | 5/10/2007 6:54:46 AM

Regarding the tools, there are lots of opensource tools that do exactly what you said, that is, validating code quality.

Some examples are:

FindBugs ({ Link })

PMD ({ Link })

One important characteristic about them is that they're flexible to accept user-defined rules, so you can create your own ones.

The worst think is: they just work for java.

One other tool in Java, that I do miss for LotusScript/Formula is something like JUnit ({ Link })

(I'm working within my company on a lotusscript framework like that, but I'm not sure I can publish it outside IBM. I'll check that)

But the main thing is: why don't we learn from the experience and maturity of the Java community? All the previous mentioned tools are widely used by the Java community, that's why they can also be integrated to the Eclipse IDE to be easily used.

Maybe we'll be able to have thinks like that when we have the new Eclipse-based Domino Designer 8.

3) you have to know what you don’t know
Charles Robinson | 5/10/2007 8:37:55 AM

My primary problem is you have to have a substantial body of knowledge before you realize that what you're doing isn't the correct approach. Also, the help doesn't help in a lot of cases and for many developers that's their only resource other than Notes.Net.

4) Teamstudio Analyzer
Maria Helm | 5/10/2007 8:52:57 AM

We use Teamstudio Analyzer in a way similar to what you are suggesting as "training wheels". We have by no means put all the possible 'best practices flags' in there, but it could be used that way. Or someone could build off of what they've done to create a 'best practices analyzer'. The thing is, someone who already knows what they're doing has to build the filters, or there has to be a 'package' you can get that does it. Newbies aren't going to know to do this.

It really should be built into designer and enabled by default if we want everyone to use it.

That reminds me, there's something like that in Dreamweaver, I think. So, it's not only the Java community that already does this. Oh, and think of MS Word and how it squiggly-underlines spelling errors.

5) OpenNTF.org
Nathan T. Freeman | 5/10/2007 1:39:50 PM

One of the purposes of OpenNTF has always been best practices demonstration & resources. The level of success has been a mixed-bag. Perhaps deeper exposure of online resources from places other than IBM would help. Presumably, once someone fires up Designer, they're prepared to color outside the lines from IBM.

6) Best Practices
Jack Dausman | 5/10/2007 3:59:01 PM

My recommendation would be for a "Best Practices" guide, maybe along the lines of the new Notes.ini listing from Lotus Support.

While I find the idea of working with Lotus education/certification alluring, I think there are many, many hidden impediments. I have a long history working with the wonderful people in Lotus Ed (including serving on two advisory boards), and I promise you that it's tough to even get something like indexes added to the back of the manuals.

7) best practices
Mark Demicoli | 5/16/2007 11:21:01 PM

I think Best Practices come from best programmers :-] Just a few points I'd like to make:

1. Java people normally get their skills and methods from disciplined education (Uni etc). Notes people are normally power users who become Notes coders and generally have a strong 'change on the fly' culture which is very hard to shake.

2. You can give a coder all the tools and tips but you can't give him insight and talent.

3. Most Notes coders don't understand the underlying architecture of Domino which is essential to writing efficient code.

Because of point 1 (easy to get someone 'programming' in Notes without much training), I see many companies putting on cheap labour (ie graduates / students) and throw them in the pit. Sure! They can create views immediately. so .. erm... they are now ready to hack the corporate apps!

8) low barrier to entry low levels of output quality
Slawek Rogulski | 5/22/2007 1:25:55 AM

I think it goes with the territory that since you can hack something together in a day or so you get all the power users turned Notes Developer (not programmer) get their hands dirty. Its a double edged sword. Raise the barrier to entry and you get the "classically" trained folks interested. They bring with them all the things that are missing in larger Domino applications. I have often found that while Quick and Dirty apps are possible, the dirty does not go away when they are scaled up. And sooner than later you start to be constrained by the framework that has given you the head start. So all that advantage has been lost. Maybe it means that we should use Notes for small apps and prototypes. And as the small apps start to grow they should be re-implemented using an enterprise class technology. In most cases this switch will not happen and we are just left with what we have now. To paraphrase Albert Einstein "Make everything as easy as possible, but not easier."

I know that enterprice class means an order of magnitude more expensive/slower than notes/domino. So why not loosen up the notes framework gracefully. Look at ROO, RoR, Naked Objects and other Domain Driven development frameworks. Easy on ramp but backed by solid architecture to allow to to scale things.

That would be my belated $0.02...

9) low barrier to entry low levels of output quality
Slawek Rogulski | 5/22/2007 1:26:03 AM

I think it goes with the territory that since you can hack something together in a day or so you get all the power users turned Notes Developer (not programmer) get their hands dirty. Its a double edged sword. Raise the barrier to entry and you get the "classically" trained folks interested. They bring with them all the things that are missing in larger Domino applications. I have often found that while Quick and Dirty apps are possible, the dirty does not go away when they are scaled up. And sooner than later you start to be constrained by the framework that has given you the head start. So all that advantage has been lost. Maybe it means that we should use Notes for small apps and prototypes. And as the small apps start to grow they should be re-implemented using an enterprise class technology. In most cases this switch will not happen and we are just left with what we have now. To paraphrase Albert Einstein "Make everything as easy as possible, but not easier."

I know that enterprise class means an order of magnitude more expensive/slower than notes/domino. So why not loosen up the notes framework gracefully. Look at ROO, RoR, Naked Objects and other Domain Driven development frameworks. Easy on ramp but backed by solid architecture to allow to to scale things.

That would be my belated $0.02...

10) Certification tests
Karl-Henry Martinsson | 5/22/2007 5:32:47 PM

During this years Lotusphere, I finally (after developing in Notes/Domino for 10+ years) decided to get certified.

I am still on R5 at my work, but I walked in, did some sample tests, took the certification test and passed.

However, I noticed during the practice tests that some answers they asked for was wrong (in my opinion), or more than one answer could be right. There was one answer where you (if you know enough) could answer all alternatives, but only one was considered right, IIRC.

There were also at least one question where the answer was a bad way to do a certain thing. Why have questions on how to do bad things? Many new developers proabbly think that is good way to do it, if it is on the test and is the correct answer...

Sorry that I can't remember the exact questions.

I think one was something like "what is the only way to retrieve data from a remote server on teh internet". It had answers like "Java, Javascript or Lotusscript". Java was considered the correct answer. I can do it using Lotusscript and a COM object (in Windows only, but still), and you can under special circumstances use Javascript as well.

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact