1 - Excellent idea. I started off in development about 9 years ago and spent the past 5 years as a developer and administrator. Learning some of the administration side of things made me a much better developer.

2 - Hmm -- I can think of one for Admins: DON'T RENAME GROUPS WITHOUT ASKING A DEV IF THEY'RE NEEDED FOR AN APP FIRST.

3 - The biggest factor in my level of enjoyment on all the various development jobs I've had over the past thirty years is the enlightenment level of the manager I worked for. With that insight I suggest another Top Ten list:

Top ten things managers should know about Lotus Notes administrators and developers.

1. The development department must have a separate server.
2. The development server needs its own administrator with skills to help developers.
3. The development administrator must be part of the design team to shape the administrative side of the final product.
4. The development manager must bend over backwards to encourage the developers to tell the truth about development progress.
5. The development manager must make sure the project budget is sufficient to provide the tools need to make the developers and administrators productive.
6. That's all I've got on this list right now.

Peace,

Rob:-]

4 - Good idea. Would love to see the list.

Here is an item which should be on both lists - how to create and manage groups so that application security is rock solid AND maintainable. I have always found this to be a real burden. The HR Department has a set of groups that maps to the org chart of the company, which is great, but application security often does NOT match to the org chart. So you make a group for your first new app, which now has to be maintained. Example, a subset of people in Accounting need accesss to your new app and that subset does not match any group in the org chart, so you create a new group. But when employees change (e.g. one person leaves that was in the group you created, and another one is hired that backfills that position), there is no straightforward way to ensure that the new person gets added to the group - Admin P should get rid of the deletion. Or at least I haven't found a way. Seems like this should be a "solved" problem which I am simply ignorant of. If so, can anyone enlighten me?

5 - Not sure if it will make a top ten, but don't do what I did at a job interview even though I got the contract.

I was discussing the difference between Administrators and Developers and stated, in my opinion, that good Developers understand enough about Administration (groups, NABs, security, etc.) to know what they need to do to code applications. On the other hand, Administrators have no clue about Development and are happy that way.

In the six months I was working there, the Administrator would not talk to me and went out of her way to make my life miserable. She took it personally when I stated that she did not understand what a Developer does even though she told me she had never coded a single line in her career nor had she ever even opened a Template.

My statement came from my experience in that I started in working Notes back in the version 3 days. I was supporting an OS/2 Notes server at the same time I was developing applications. I eventually decided that Administration was definitely not for me and concentrated on applications. I did however keep up my knowledge of Administration so that I could step in and help out if necessary. I figured that would give me a solid position but this Administrator simply wouldn't listen to me.

6 - Interesting stuff, especially as an administrator who started life as a developer (albeit with occasional postings as admin cover). I also tried to get a solid sandbox environment in place at my company for both development and testing, which has sadly gone by the wayside now., So, some things I would say to a new developer:

No, there is no way you can have the password to the id used for template signing.

Your new agent needs to send mail? Ok, what server are you sending it to? No, you can't use "made up" hotmail addresses. No, you can't even send them out to the public internet. Why? because you don't *know* they're not live addresses, or won't be tomorrow or whenever your testing finishes. We don't want to end up in spamhaus' list of naughty people, so I'm not going to allow you to relay through my live mail server. Set up your own mail server, on your isolated network, and get to know your dev server's hosts file.

You can enable that large agent when you tell me how many documents it's going to process in a live database, and how often. No, the word "probably" doesn't cut it here. Show me your fullscale test results.

No, you can't schedule that agent when I'm running the overnight compact.

You want to give anonymous what level of access?

No, you don't get Designer access to the NAB. tell me what you need to do and I'll do it (or tell you where it's already done).

Don't re-invent the wheel - we already have a db that has all the information you need here: if it's not in the format you want, let me know and I'll add the view you need.

Testing a new web app, and you need to make sure the server and domain referrals are working? Remember what I told you about your hosts file? There you go then.

No, you cant use the company SSL certificate for testing. Use your dev/test domain's CA process.

No, you can't automatically create new dbs unless I know how often your agent's going to do it.

You want to run it when? Dream on, if you want the users not to hunt you down with a rusty can opener while they lose all access to the server because your agent fires up during the monthly reporting panic.


OK, so it's mostly all noes, but maintaining a production environment sometimes means locking a developer's hands. Safer that way.

7 - @2, "DON'T RENAME GROUPS WITHOUT ASKING A DEV IF THEY'RE NEEDED FOR AN APP FIRST."

How about not coding group names into an app. That's pure config and belongs admin / app support.

The biggest thing that devs and admins need to understand is how to work together. Devs will often understand enough admin to set up a dev server and configure it to do what they want, but won't have an appreciation for what needs to be done to keep a production environment running smoothly. Admins' favourite work is "no", but they need to understand that devs have been tasked with developing an app by the business. Elegant solutions to that problem may have unusual characteristics.

In short, everyone needs to work together. If there is an antagonistic divide between the two camps then you'll never get the full potential out of the platform and spend a lot of time pissed off. And who wants that.

8 - I'm not sure this is a top-ten list, or if it will even be a list of ten, but here are some things I learned about administration that really helped me become a better developer.

1. Understanding security beyond the ACL. In my opinion this is a pretty basic requirement for any developer. Familiarizing myself with how secondary address books are set up, how password strength is assigned, and the order by which Domino checks the address books not only helped me troubleshoot issues with access to applications I designed, it helped me design them better in the first place.

2. Know your environment's mail routing configuration. I can't stress this enough.

3. Plan your agents--scheduled or web-triggered--well. That means learning the maximum number of simultaneous agents, the business and after-hours maximum execute times, and knowing (or at least working in conjunction with your admin who should know) the various maintenance jobs that will run on the server (and their times) so that agents will run at times when server maintenance is not being performed (or when other high-performance agents are running).

4. Don't just consider your application when designing it. If every column in every view is sorted *and* you store thousands of documents *and* your application will reside on a server that deploys other applications, chances are, you're going to hit performance snags in production. This isn't the admin's fault, and it isn't the server's fault. It's the developer's fault; learn to play nicely with others.

5. This references #3 somewhat, but understand what is going on in the Notes administration process when various events happen. If your agent creates an adminp request that requires administrative approval before executing, you'd be better off knowing that before designing your workflow (and associated times) around mistaken assumptions.

6. Don't always write your agents' error messages to log.nsf. If you need detailed agent logging, create an agent log database to be deployed with your application. It'll be easier for the developers and the administrators to troubleshoot problems.

7. Test your application well using volumes that you anticipate will occur in production. If you're fortunate enough to have a test environment which mimics production, use it to its fullest and really put your application through its paces. Which brings me to #8

8. Take the time and schedule a meeting (or meetings) with the administrator(s) of the environment you'll be deploying to. Give them an overview of the design, what its primary objectives will be, and review thoroughly all the agents, the security, and any other design features which will potentially affect the environment. Yes, admins are busy folks, but I'd wager 10 to 1 odds, they'd rather identify potential problems in a design *before* it hits production. If you've been able to test extensively as per #7, show your test case results in these meetings.

OK. So that's not ten. Here's a bonus. If you, the developer, are able, start to test your application in the next release of Notes/Domino as soon as you can. That way, you're prepared for when the admins come to you to say, "Oh, we're upgrading to version 8 at the end of this quarter."

9 - As for what admins should know about dev, I'm finding that much more difficult to answer.

I think first and foremost, admins should understand at what times (and for what operations) @Formula language is useful, when LotusScript is better than @Formula language, and when Java trumps all considerations. Many admins may never write a line of code in their entire career, but it can (at least) help if one is reviewing an application before deployment, particularly if a developer privileges one tool over the others in design.

I would also recommend all admins gain a basic understanding of the most frequently-used classes in LotusScript and/or Java, particularly the back-end classes since they are more likely to be used in scheduled/web-triggered agents and will (I suspect) take up most of the agent computing time on the server.

Check the "what's new with release ___" in the design help file of the next version of Notes/Domino. Again, this is more of a code-review tip: better to find instances where developers have relied on code not supported in an environment before the application is deployed.

Most developers and admins have been burned (or know someone who's been burned) by poorly-handled readers fields within documents and know to check for these things before releasing an application into production. Equally as important (though in my experience more overlooked) are the areas within design elements where developers can grant use/author and use/reader access to the element itself. Admins should be familiar with all the design elements and where access can be granted to each.

A general understanding of private and private on first use views/folders, when and how they should be used, and for what purposes -- particularly if users or groups of users will be allowed to store those private views on the server.

@DBLookup. I reckon that after enormous agents and view indexing issues, frequent use of @DBLookup (particularly within a single form) is responsible for the most performance complaints generated by end-users. Understanding what @DBLookup does and how it performs can significantly improve code review prior to deployment (although one hopes that a developer would find this during test!)

and that's all I've got so far...

10 - Ask Rudi

11 - nice post!...thanks for the idea..=)<b><a href="pinayspeak.com">Busby SEO Challenge</a></b>

12 - nice post!...thanks for the idea..=)&lt;b&gt;&lt;a href="pinayspeak.com"&gt;Busby SEO Challenge&lt;/a&gt;&lt;/b&gt;