Tim sums it up:
So it seems that word is spreading about this great XPages stuff, (so someone does read my blog) and I am being asked what the plans are to deliver it in other countries. January is going to be planning month and Lotusphere 2009 So here is who to contact if you want to add you name to the list of people/countries that are interested.
to find out how to contact them you can use the WhoIs application.
Only Stephan and I know about this blog post so far so when you contact the others, please be gentle. ;o)

• EMEA: Tim Clark Please leave comments on this post to show an interest for EMEA.
• Asia Pacific: Qiao Ming Chen for China, Stephan Wissel (me) for Asian & India, Atsushi Sato for Japan
• ANZ: Craig Hart for Australia / New Zealand
• Americas: Craig Wolpert

IBM's business partner Elgui Software has a great piece of web2.0 software called IdeaJam (build on Domino/XPages). IdeaJam allows the sharing of ideas, commenting and voting on all ideas. It is an application no IBM customer should miss. Bruce just pointed me to the latest feature: seamless integration into Lotus Connections.
From the IdeaJam product page: "IdeaJam is a place where people can post and share their ideas, and gauge the marketability, popularity and viability with input from others.
When an idea gets posted, others can help promote or demote the idea and provide comments. Popular ideas will bubble to the top.
Make your opinion count."
Go and check it out.

I'm using Linux as my base operating system. Until Domino Designer is available on Linux I need to keep a Virtual Machine with XP around. I work with both VMWare and VirtualBox. One thing you automatically do with virtualized operating systems is to shut down what is not essential. In windows the services loaded by default can be cut back quite a bit. Of course you can overdo that. One lesson I learned the hard way: The Notes 8.5 client crashes fatally if the "DCOM Server Process Launcher" isn't running. Took me 2 days of wondering until Nathan gave me that tip. Apparently that service is needed on "bare-iron" windows too.

This time strictly for the kids. I had my stab at Elektromann. And I still remember its slogan: " Alles baut Elektromann was man mit Strom betreiben kann!"

And I thought the only vehicles the Danish were good at were Viking battle ships.

For the record: I don't own a car.

In Domino Agents are the Swiss Army Knife of development. They can be called from the client, triggered on schedule, automatically run on an event, be associated with a web action (Open, Close) or directly called from an URL using ?OpenAgent. The ?OpenAgent use of agents is subject of this blog entry. A agent triggered from an URL can use Print statements to output results back to the browser. When the first line of your print statements is "Content-Type:..." you also can serve XML or JSON or whatever exotic format your agent logic was able to conceive. Agents come with the usual drawback: the runtime environment is intitialized new for every agent run, so you need to update a document if you want to keep track (Replication conflicts anyone?)
XPages don't have a notion of agents (you can call them in the backend, but you won't get anything back from the print statements), so it seems a step back. On closer inspection however one can see, that XPages offer a greater flexibility for the same pattern of use. Every element on an XPages has a "render" attribute which determines if the element should be rendered. "Every" includes the page itself. So when you set the page's render property to false, well the XPage engine renders nothing. So you get an empty canvas you can paint on. XPages still provides you with the page event and access to scoped variables, so you can code better performing "agents" since you can keep lookups in memory. To get the equivalent to the LotusScript print you need the ResponseWriter from the externalContext. To set the content type you use the response.setContentType also to be found in the external Context. A sample snippet you could put in the afterRenderResponse event of your page would look like this (error handling omitted):

// The external context gives access to the servlet environment
var exCon = facesContext.getExternalContext();

// The writer is the closest you get to a PRINT statement
// If you need to output binary data, use the stream instead
var writer = facesContext.getResponseWriter();

// The servlet's response, check the J2EE documentation what you can do
var response = exCon.getResponse();

// In this example we want to deliver xml and make sure it doesn't get cached
response.setContentType("text/xml");
response.setHeader("Cache-Control", "no-cache");

// Here all your output will be written
writer.write("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<christmas date\"24Dec\" />");

// We tell the writer we are through
writer.endDocument();
facesContext.responseComplete();
writer.close();

// Update:On 8.5.2 or later writer.close() seems not be necessary/be rather harmful. Read the revisited entry
More information about the FacesContext can be found in the Domino Developer Wiki.

Bonus Tip: Since you do not render anything from the XPage you just used, why not take that empty page and write the documentation for that XAgent?
Update: Other posts on rendering your own output in XPages:

• Rendering ODF documents in your XPages
• Rendering your own output in XPages revisited

Have fun writing XAgents!

Based on the IBM Dublin workshop Tim, Matt and myself created the materials for the famous XPages workshop that ran in Hursley and Bejing (and is planned for other locations early 2009). One comment by a participant summed up the impact of XPages on Notes (yes it's coming for the client) and Domino:
"I was afraid that my lack of experience with the Lotus environment would prove to be a burden during the session, but it has not. On the contrary it might even have been an advantage (emphasis mine) , having experienced the workshop with clear eyes (if you will) not trying to apply old routines. It has been difficult to accept drag & drop and the "what you see is what you get" concept of developing. Coming from normally developing in a simple text editor basically. But it's quick effective and if there's any need to goof around with the source, the option is there. I think I will definitely embrace XPages and hopefully with the knowledge I've gained this week, have my colleagues do the same. (They are all Lotus fanatics anyway :) )"
A lot of our customers cite difficulties to find enough Lotus developers. With XPages Domino you develop in JavaScript end-to-end. These skills are much more readily available. Of course you need to learn the object model, but at least you get away with a single language.

Just watching the ZEN like concentration of Anthony playing the guitar is worth it!

The Mini is running Ubuntu 8.10 by now and does that quite well. Only Firefox somehow didn't load Java applets properly despite the fact that I had the latest and greatest JVM. 6.0_10-b33. Command line Java programs (like Websphere, Tomcat and some of the stuff for AD215) work plesantly fast. So something in the combination of Ubuntu, Java and Firefox doesn't seem to work. After a little research it turned out, that Sun has created a next generation plug-in that is supposed to address all the short comings in the Java plug-ins. There are a number of solutions out there, which didn't work for me. This worked:

1. Install Java6: sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-plugins and update-alternatives --config java
2. Change to the plugin directory: cd /usr/lib/jvm/java-6-sun-1.6.0.10/jre/plugin/i386/ns7
3. Delete (or rename): rm libjavaplugin_oji.so
4. Create a symboliv link: ln -s /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so libjavaplugin_oji.so
5. Start Firefox, type about:plugins and you should see libnpjp2.so as your Java plugin name
6. Check on this page (scroll down) if the applet is working

However you must be clear that this qualifies as ugly hack which most probably won't survive the next Java update.

What do I tacitly acknowledge here?

My friend Lucius started his own software company Smart Toucan. His first product is Auto-User, a tool that can test Notes Classic client applications. You can use it for recording/replaying demos or to run automated software test. While IBM has a great product for web application testing (the Rational team will not talk to me anymore if I don't mention them here <g>), automated testing capabilities for the Notes classic client are painfully absent. Auto-User plugs this gap. The current Beta release works with Notes 7 and I'm looking forward to the R8 Classic and Basic configuration versions. Go check it out.

Lotus Bluehouse is IBM's latest SaaS offering. It provides an open, secure, ad-free combination of popular functionalities of the Lotus portfolio:

• Contacts: You can sync your contacts with your favorite PIM including Notes and SyncML based one. Of course updating addresses becomes easy once you are connected to a contact. With best regards from Lotus Connections Profiles.
• Document sharing: Functionality like Quickr is available. Upload and share files including version control
• Plan and execute shared tasks: Lotus Connections contributed Activities
• Chat with other Bluehouse members: Just add the Sametime community im.lotus.com
• Design and fill-in forms (surveys anyone). With compliments from Lotus Turbo forms

... more to discover and more to come. Bluehouse is a subscription offering, but you can be teased by an existing member to a limited membership. Ping me if you want to give it a spin.

Estimating software project cost and duration seems to have parallels with the local weather reports: You simply can't rely on them. Waterfall project approaches are partly to blame. Estimating the amount of work units for a requirement is another. How much work is " The system needs to be user friendly"? For the sake of this post lets us presume your have a magic box, typically labeled experience, either explicit or implicit, that gives you an insight how much code you need. Once you know how much code (a.k.a. LOC or "lines of code") you need to write, estimation becomes manageable. A good tool to estimate is COCOMOII. With the LOC, COCOMOII and your average hourly cost you can estimate the cost easily (Thanks Mitch).
However using a visual development environment (Visual Studio, Eclipse, Adobe Studio, Domino Designer) makes things a little more complicated. A form or a view you draw is not a line of code. The UML model you paint (that will turn into a database schema and code classed via generation) is not a line of code. So you need to expand your mental estimation model slightly. There are two new terms to get familiar with:

• LOC_TE = "Lines of Code - Time Equivalent": The time for painting one form is equivalent to writing how many lines of code?
• LOC_AL = "Lines of Code - Avoided Lines": When you paint one form how many lines of code can you avoid to write? The whole promise of any visual environment is, that LOC_AL > LOC_TE. This probably varies from platform to platform and makes an excellent subject for a bar brawl between competing developer camps. I guess you won't find much information about that ratio since nobody ourdays would afford to build a system twice.

Where does that leave you for Notes or Domino estimations? You need to find your magic number for LOC_TE for the various design elements (see graphic below) and then apply the COCOMOII estimation. Of course you could simply use time estimates (by revisiting your past projects), then however you need to calculate your own project variance based on project complexity and team experience. Neglecting experience and complexity are the great fallacies happily endulged in by project planners with too little experience in software project estimations. The difference for a similar sized project can be 500% from " very experienced team working on a low complexity project" to " unexperienced team working on a high complexity project". Even if you just consider experience you will still have to shell out more than double the money (230%), 70% more people and 40% more calendar time for an inexperienced team.

The orange boxes are most likely what you will get out of the discussion with the business users, including some of the yellow boxes. For the red ones you can directly insert lines of code. How do you estimate your projects?

Happy Hari Raya to all my Muslim friends worldwide. While you celebrate worldwide, take a second and consider: is it time to switch your computer operating system? Would you consider to switch if you get (for free) a set of Islamic software: prayer times, Quran study tool, web content filtering etc. All this is actually available today in the Ubuntu Muslim Edition. It is free and it is based on the currently most popular Linux distribution Ubuntu. Go check it out!

Even if it is the tacit admission, that I need to get back in shape

I recently had the opportunity to look deep into the many thousand applications one of our customers has deployed. I found the following metrics:

• A Notes database application has per average 18.8 forms, 14.4 subforms and 37 views (including folders)
• There are 8000 lines of code per application (@Formula, LotusScript, JavaScript, Java) and 10.5 agents
• A form or subform has per average 10.7 fields and 8.8 actions or buttons. So if a form uses 3 subforms you would have 32.1 fields in that form.
• A view has per average 6.7 columns and 8.8 actions (We averaged actions across forms/views, so the number is the same as for forms/subforms)
• The Lotusscript functions have an average length of 21 lines

Of course: averages are averages. Typically you find a bunch of auxiliary forms/views with small numbers of actions/columns/fields and the main forms that tend to be much longer. Guess I'll play with that statistics a little more.
YMMV

Keyword fields (known to the younger audience as: Radio buttons, checkboxes, combobox, dropdowns etc.) very often are populated by @Formulas. @DBColumn, @DBLookup and @GetProfileField are equally popluar. For best performance you should use @GetProfileField (if that is possible in your application context). Another way to speed things up: prevent the formulas from executing in Read Mode. If for example a formula to populate the options looks like this:

tmp := @DBLookup("Notes":"NoCache";"";"(LookupProjectsBySponsor)";@UserName;2);
@if(@IsError(tmp);"You don't sponsor projects"; tmp)

change it to

@if(!@IsDocBeingEdited;@Return(@ThisValue);"");
tmp := @DBLookup("Notes":"NoCache";"";"(LookupProjectsBySponsor)";@UserName;2);
@if(@IsError(tmp);"You don't sponsor projects"; tmp)
 

You can refine that and not populate keywords you don't intend to change (based on a status), you would update the first condition then.