• some sort of IDE with a compiler
• version control
• and bug tracking.

Usually you get stuck with IDE with a compiler. Everything else is up to you. But how are things in Lotus Notes?

Version control

As expected Lotus Designer doesn’t have an integrated version control software. Not yet anyway. They are planing to build subclipse to work in new 8.5 designer, but that still needs some time. Also most people are probably still stuck at R7.

Well, one of the things you could use is Teamstudio Ciao!. This is a payed software meaning that either it becomes your department policy to use it or you will never use it. I had a chance of working with Ciao and I have to say that I was less than impressed. But that is just me. I know a lot of people using it without any drawbacks and with lack of tools out there, this is probably the way to go.

Next widely used option is to use separate templates for each and every version of your application. There are two things wrong with this. One is that there is no way any developer would do a new template just for fixing one single agent. Second one is that I am yet to see a consistent template policy.

Another possibility is to copy your database locally and then import it into Subversion (SVN) or perhaps write a script that would periodically do that for you. The thing is that you won’t be able to just revert to desired version of the database without deleting the existing one. There is one other option. You could export objects (agents, views etc.) as DXL, import it into SVN and then when needed import DXL back to the database. However, DXL is not 100% representation of design elements. Thus I wouldn’t recommend it.

As mentioned there is a subclipse project that would enable subclipse in Domino Designer 8.5. Subclipse is Eclipse plug-in for Subversion. And since Domino Designer 8.5 is built on Eclipse framework, this would finally solve most of our version control issues.

Bug Tracking

Why bug tracking? Well, I am yet to see software without bugs. And the thing that helps the most is some sort of bug tracking engine. However, oddly enough, this is the part rarely seen and used. Typical bug tracking process should go like this:

• someone reports a bug
• developer is assigned to the bug
• developer fixes the bug
• third person (inside a company and related to project the bug was reported for) tests the fixed code
• bug report is completed.

Now, show of hands. How many of you have this process implemented in your development cycle? I thought so. But being a Notes developer, what are your options?

There is a great open source project at openntf.org called BugTracker. Another option is to use some commercial product like Trackersuit Help Desk Software or similar.

If you are not attached to domino apps only, there are tons of open source applications for bug tracking. Probably most known amongst them are Mantis BugTracker and Bugzilla.

The most inappropriate systems for bug tracking I have seen thus far are internal forum and wiki. These applications are not meant to be bug trackers. So, please, don’t use them as such.

We all know how we felt for the very first time. Dropped into a thing called Notes, with something non-relational called a database, only to find out that it is really a massive component storage and not just a database. All that storing capabilities sooner or later require some sort of database organization. Most would be satisfied with basic configuration and that is fine, if you are creating a small internal database that no one will ever look at. Building a large web based application, one would soon find out that default is not even nearly good enough.

Why is web different?

1. Domino engine (at least up to version 7.0.3) still doesn’t know how to add Expires headers to css, JavaScript and image files and thus those files are never cached. Yes that is correct. Never.
2. Using pages for design elements as CSS and JavaScript is (since release 6.0) not recommended, as there are separate sections to store those files (Style Sheets and Files).
3. Sticking with pages and using computed text to generate links to images is slow and thus effects your web site performance. Specially from remote areas.

Thus, when redesigning a web database, I try to stick to following guidelines:

1. Put only CSS in pages (if it is really necessary) and use relative linking and 0 computed texts. All other resources are stored in desired places.
2. Give an alias to all design elements, i.e scripts/myscript.js or images/myimage.gif or styles/mystyle.css.

Naming convention assures me that my design is always easy to find, I can relatively assign links to image resources from CSS without a need for database replica id and most importantly, it allows me to force Expires header to design elements via Web site rules, which (due to design elements now being cached) results into significantly faster web site loading.