Best Practices - Hoping to spark some discussion

HCL Domino Domino Forum
1

Hi,

I have started work at a client, and have a few questions about doing best practices for the company.

As I understand it, they have bought a product, and the company had said that using templates is not the way to install new changes. Note: they have 4 levels of servers to do the testing on. They had said the best way to do the work is modify the developement code, and then when happy with it, refresh the design of the next level from the development dB. Template are a bad thing - and no body uses them any more.

The next issue is that the code I am reviewing has the file names hard-coded. The names are not constants in a script library or any thing, but must be in about 50 or 60 places. I had suggested that using a profile document with replica’s id’s may be a better way to go, but they said hard-coding is a better way.

ANother item is you know how you can say

msgbox ‘what ever’, MB_OK + MBICONSTOP, ‘titel’

The vendor is stateing that using the lotus script constants is not a good thing. It is much more easy to just hard code the constants . After all , everybbody knows what 16, 32 and all the other combinations by heart. Also, Lotus/IBM would never ever change these without first asking everybody if it is ok.

Finally the one thing that got to me was that all the dB’s on the four different servers are replica’s of one another. The servers are in different domains, but it was told to me, that having this set-up will never cause a problem, alghough I thought that other companies had set up their enviromnments differently - is, the database would not be replica’s.

Have I been missing out on anything, or is the above the best way to code now.

Thanks for your input.

John

ps. I am not kidding about any of this - this is what I have been told.

2

Subject: Best Practices - Hoping to spark some discussion

Your client is clearly on drugs. I second Stan’s recommendation on finding a different client, but while you’re looking, try to find out where your current client keeps their stash.

3

Subject: Best Practices - Hoping to spark some discussion

…the company had said that using templates is not the way to install new changes… They had said the best way to do the work is modify the developement code, and then when happy with it, refresh the design of the next level from the development dB. Template are a bad thing - and no body uses them any more.

Rot.

The next issue is that the code I am reviewing has the file names hard-coded. The names are not constants in a script library or any thing, but must be in about 50 or 60 places. I had suggested that using a profile document with replica’s id’s may be a better way to go, but they said hard-coding is a better way.

More rot. Replica id is better in most cases.

ANother item is you know how you can say

msgbox ‘what ever’, MB_OK + MBICONSTOP, ‘titel’

The vendor is stateing that using the lotus script constants is not a good thing. It is much more easy to just hard code the constants.

Rot, rot, rot.

After all , everybbody knows what 16, 32 and all the other combinations by heart.

If I want to memorize something I will start with Shakespeare and work my way down to Lotusscript from there. In the meantime my brain cells have better things to do than recall what 48 means in this context.

Also, Lotus/IBM would never ever change these without first asking everybody if it is ok.

Irrelevant.

Finally the one thing that got to me was that all the dB’s on the four different servers are replica’s of one another. The servers are in different domains…

Insane.

With their heads that far up their posteriors, chances are they will need your services for a long time to come. Sounds like a good client.

4

Subject: RE: Best Practices - Hoping to spark some discussion

Thomas,

thank you - that is what i thought - most importantly thank you for the laughs - i loved your answers.

5

Subject: RE: Best Practices - Hoping to spark some discussion

They had said the best way to do the work is modify the developement code, and then when happy with it, refresh the design of the next level from the development dB. Template are a bad thing - and no body uses them any more.

Er, I don’t think so.

The next issue is that the code I am reviewing has the file names hard-coded.

Really bad idea in most cases. Your way is better. Though if there are several databases that comprise a system, and they exist on multiple servers or may have local replicas, you might want to store the replica IDs in your profile instead.

…MB_OK + MBICONSTOP … The vendor is stating that using the lotus script constants is not a good thing…

I can’t speak for IBM on this, but my personal feeling is that it’s extremely unlikely that these values will change meanings – it would break all sorts of existing code. It’s more a question of readability. Admittedly, it’s inconvenient to have to include the lsconst.lss file, especially when there are contexts that don’t allow the use of Public. I’ve been known to copy out the relevant Const definitions into my code – but I never would hardcode the number in this context except for 0 – and I probably wouldn’t do that if it were a product, especially one the customer was expected to customize.

Other LotusScript constants, that you can use without needing a %Include – there’s even less reason to type the number.

Finally the one thing that got to me was that all the dB’s on the four different servers are replica’s of one another.

With different data in them? So we’re assuming there are no users who are members of multiple domains, who will create a local replica of the application and replicate with servers in two different domains? Seems unnecessarily risky to me.

6

Subject: RE: Best Practices - Hoping to spark some discussion

Andrea,

Thank you for input. I agreee with you on the constanst from IBM, I don’t think they would change them either. I use them as you said for readabilty.

As for replica’s I am in totaly agreement. The chances of somebody accidently turning on replication is small, but I have alsways said why even take the chance. They are not really big notes users here, so the user do not know how to create replica’s.

thanks again, john

7

Subject: Best Practices - Hoping to spark some discussion

Find another client. Fast. This one will eat your mind, your soul and your children.

(I don’t like working by replicaid if I don’t have to, but this business of hardcoded server names is not a good thing.)

8

Subject: RE: Best Practices - Hoping to spark some discussion

Thanks Stan. I have read your answers before and found that you have always given out great advice. The client company is a very good company to work for. It is the vendor who sold them the software that these are notes best practices.

Some of the stuff I can understand, The big one was that templates not used by anyone anymore. Most of my other clients have always used templates, and if they did not I convinced them this is the way to go - and most did.

9

Subject: RE: Best Practices - Hoping to spark some discussion

If you have several databases with the same design on the same server, or the same database design on another server, templates are a must.

Templates are also good to prevent loss of work and loss of functional designs.

We have 3 level of servers: development servers, testing servers, and production servers. All changes to designs are done on the development side, and before a developer starts to change something, he marks the design document as locked (Prohibit design refresh or replace to modify). Once the development is over, the developer copies the design documents to the test server’s databases and informs the tester that the changes are ready for testing. If testing was a success, the lead programmer removes the design locks from the design documents from test and development servers and puts the design documents into the template. The template is then replicated accross development/test/production.

This setup is a result of our key business criterias for the servers:

  • Production side must be up 24/7/365 (We have 3 world region servers to ensure also uptime during Domino version upgrades and OS reboots, and of course disaster recovery and replacement servers)

  • Testing side must be always functional and if necessary, easily restorable to the previous functional version

  • Development side must have all freedom to research and develop new technologies without having to worry about testing and production

About the programming side, constants should only appear once troughout the whole system/world. If you change that constant, the change should be reflected everywhere.

Using replica ID’s for databases/views/documents is not the best solution, but sometimes it’s easier to do things that way. However if you have a replica ID mentioned somewhere, it should also be a constant and follow the rule for global constants, ie. it should only exist in one place. The best solution of course for every constant, replica ID, server name, etc… is to have a global parameter database, where you can change those values centrally.

10

Subject: RE: Best Practices - Hoping to spark some discussion

Mika,

Thnak you for your response. Some of the clients that I have worked are international, and have different directories for the dB’s, which is why I have a global dB as you mentioned, where I keep the replica id’s for opening the dB.

I agree with everything you have stated, and generally have programmed that way. I was just curious to know why this vendor choose to tell the client what it did.

john

11

Subject: RE: Best Practices - Hoping to spark some discussion

John… frankly, this vendor has no business providing advice if this is the kind of advice being given. The unfortuante end result is a bad reputation for Notes/Domino. The practices that they recommended went out of practice in the early 90’s, and any dev. shop worth their salt would never adopt them again.

What is quite common is having a template (which provides a source code backup if any database corrupts), a development area - where all your testing dbs reside, and then the production area(s). The production databases should be replicas if data is to be exchanged, otherwise just the template name can be the same on all databases.

When starting an enhancement project, change the template name so that it will only refresh with the testing dbs. Once you have the user signoff to your changes, change the template name back to the production template name, and let the server refresh overnight (when no users are using the dbs), although not a necessity.

With the above structure, setup or profile documents, or system registry documents are a must. Hard coding was the fortune of many developers prior to Y2K, as so many applications needed changing to remove hardcoding. It’s not the way to go now.

Sounds like your client has lots of work to be done to get to best practices… if you want a partner with 14 yrs. experience, let me know… LOL…

Best regards, Tom.

12

Subject: Best Practices - Hoping to spark some discussion

Hi John,

I just saw this posting today. Kind of reminds me of where we worked and the whole issue with templates. You already know my thoughts on this. I concur with everyone else - except finding their stash of drugs, of course :slight_smile:

Good luck with that project. Mine is just about done. Maybe we can work together again sometime.

Audie