You're paying how much for that server?

Like your cable bill, the internal cost of your servers tends to get bloated over time.  When was the last time you checked your bill?  I was working with one customer whose charges for servers was over $600 K.  Upon looking at the bill, they were paying for servers that were not Domino servers, and paying for servers that didn't exist anymore.

That is a start, but what is the next step?  A good way to consolidate servers is too look at the databases that are being used.  And the key thing is to look at databases not being used by people.  The unfortunate part of the activity reported by the Catalog is it lumps all activity together.  So, you can have a mail file that shows 'activity', but it is simply the router dumping spam in that mail file.  Likewise, you can have an agent running in a database that users don't access.  Thus, activity, but no users.  The good news is that you can use the Activity Logging feature of Domino to generate useful information.  The information provided by Domino is not real useful by itself, but I have a tool that can consolidate the information and give you the information you need to identify databases not being used by people.  Let me know if you want more information.

With this list in hand, you can start to identify servers that can be eliminated by consolidating the databases on fewer servers.  And when you start to consolidate servers, you should think about a tool like Panagenda's Marvel Client that can update all your users desktops to point to the changed server for the databases.

Coding tip for those copy and pasted fields

You know how the first paste gets you the same field name with an underscore and number added to it?  I have seen some really ugly code when someone wants to programmatically iterate over all the fields.  Things like checking a counter, or one time processing for the first field and then a loop for the rest of the fields.  All of this can be greatly simplified if you just go back to the first field and add an underscore and zero to the name.

So

Product
Product_1
Product_2

becomes

Product_0
Product_1
Product_2

etc.  Now you just loop through all fields starting with zero.  And if you come across this in an existing application, use a tool like scanEZ from Ytria to change all the existing douments.  It is well worth the time for this simple fix.

Speaking of things in the attic

I found this over the weekend

Oh the things I've seen

I was doing a web training session for a customer recently.  Since I know the user interface for the tool, I let the customer do the driving because it helps them become familiar with the interface, and the other attendees try to find the correct button before the person doing the work.  All in all this has worked real well for me to keep web attendees involved in the training.  So, the first step is to open one of their databases in designer and there it was.

and so on, perhaps twenty 'different' forms altogether.  This is a form of version management and way too common in Notes shops.  When you see this in forms, you know it happens in views where it is a really bad idea.  With forms, they don't take much space, but every view has an index that must be maintained.  It also means you might have things on Create menus or Action menus that you didn't anticipate.

So what do I mean by version management?  It is a way to track the changes in your design elements.  And it is a very good idea to track changes in your designs for many reasons.  Version management is one component of Source Code Control.  Ah, yes.  So that is why you need source code control.  People talk about it,  people tell you how to set up Git or Mercurial, but they don't tell you why you need source code control.

One of the other things you typically get with source code control is a tool to tell you what has changed.  Without printing a Design Synopsis for each of the forms.

So look for these features in your source code control system - it will really improve you development environment.

But let's go further.  The difference between these forms was several labels were changed.   This is another classic example of design meets data.  The data has now become part of the form.  This is bad because whenever the data changes, a developer is required to make changes to the database.  The whole database should be changed so that a new document was created, and the changed information entered on the document.  Use picklist or comboboxes to control the selections if you need to, but make it document level updates.  Now you are simply managing documents, not design changes.

I hope this was useful.

Welcome to my new blog

You may have seen some of my other posts under the Teamstudio blog.  Now that I don't work there, and have some time on my hands, there is still much to be added to the conversation.  And since I don't work for anyone, I don't need any disclaimers because the opinions expressed in this blog are my own.

So, what can you expect?  There are some tips on improving your development that I hadn't had a chance to put down on blog before.  I also will be looking into what are the pitfalls and resources for converting an R3 era application to an Xpage based web application.

So, come back often and add your thoughts.