Usability - Productivity - Business - The web - Singapore & Twins

By Date: June 2009

Genting Highlands Resort Reflections

After exploring Kuantan and Sungei Lembing we continued our personal Discover Malaysia trip to Genting Highlands Theme Park. After having seen the orginal a number of times it was obvious where Genting's inspiration came from (Wasn't there something with "flattery"). They have to practice with their website however. With NoScript active you don't see a thing. The theme park is divided into an indoor and an outdoor area (tribute to the weather here) with the indoor area actually containing a number of rides including a ferries wheel and a roller coaster. After the beach and nature in Kuantan that felt a bit creepy. But it operates well. SWMBO went - what Genting is all about - gambling and won the family dinner last night. One of my favorites are animal pictures. The body of a snake (a must have accessory over here) is muscle pure - quite a stretch target for my gym exercise.
Who is the animal and who is the human?
Of course the main attraction of any theme park are the rides. Genting has a number of them: The Corkscrew, Space Shot, Sky Venture (a body flying tower, very cool, Flying Coaster, Snow World (the only way to see snow in the tropics) and more. All of them are pretty new and feature impressive structures.
The structure of the Flying Coaster
However when you embark on a ride on the Cyclops you enjoy Malaysia's first roller coaster ever,

Read more

Posted by on 20 June 2009 | Comments (3) | categories: After hours

Picking your routing and replication architecture

Routing and replication is a core function of the Domino server. There are a few basic facts you need to consider when setting them up. A very popular setup, which I quite like too, is a hub spoke architecture: a central spoke communicates with spokes, so any communication has a maximum of 2 hops. An additional advantage of such an architecture is, that a server only needs to "see" the hub to reach any of the other servers. But even for a hub-spoke architecture there is room for improvement. Let us make two assumptions: the hub is where your SMTP mails arrive and depart (so "hub" could be a cluster) and all servers can see each other on the network.
  1. Mail Routing
    The normal Hub-Spoke routing has the advantage, that every email message is delivered with the maximum of 2 hops and that you only need 2 connection documents per server. It also works independent from network architecture or IP ranges.
     Hub Spoke Routing
    Of course - you need connection documents and every message will use 2 hops. If you have a lot of large internal traffic you create a bottleneck at the hub (even with multiple mailboxes). When all Domino servers "see" each other direct routing will be more efficient. To setup direct routing you need to put all participating Domino server into the same Notes Named Network (which implies that they all share the same network protocol - not an issue with TCP/IP everywhere today). You won't need connection documents anymore and routing is instant and direct.
    Notes Named Network Routing
    Are there reasons (beside obviously wanting of the prerequisites) why you wouldn't want to use direct routing? When you use your hub to perform central functions like virus scan, content integrity, enterprise archival, compliance check etc. you want every message to pass through your hub. Be careful what you wish for, you might just create your next bottleneck.
  2. Replication
    Replication comes with many choices: What server starts it, pull only, push only, pull-pull, pull-push. So it can get a little confusing (should I draw a diagram for you?). Hub Spoke replication architectures make a lot of sense. With 2 cycles all replicas are current. This is especially important for your system documents. However you need to be clear about how you set it up. The typical setup is the hub server to be scheduled to replicate with the spokes. From the 2 options: pull-pull and pull-push we find mostly pull-push. This means the hub does all the work.
    Hub Spoke Replication
    Since the hub doesn't do anything else (eventually run some central agents?), that seems a sensible choice. However it has a large pitfall. By default there is one replicator up and running per server. So your Hub is replicating with one spoke at a time. You can increase that number to 4 but you will with large changeset and many spokes run out of your replication time window. On the other side of a replication there is just another user session (watch your console, you will find: "Session opened for server Hub/MyCorp"). So when you turn the replication direction around it scales much better.
    Spoke Hub Replication
    When you schedule a pull-push replication on every hub, you can schedule all replications at the same time, since they are just sessions on the hub. You still will need 2 cycles to have all documents on all servers. Why would you not want to do that? 2 potential reasons (one stronger, one weaker) come to mind: firstly since all spokes push documents to the hub at the same time the peak utilization of the indexer on the hub goes up and might slow down other functions temporarily (time critical agents?); secondly replication is a bit "messier" the spokes might get some of the updated documents already in the first cycle instead of the second, if your application relies on sets of documents (Lotus Workflow comes to my mind) you end up with some documents "missing" until the completion of the second cycle. Other than that Spoke Hub replication is your method of choice.
As usual YMMV.

Posted by on 19 June 2009 | Comments (0) | categories: Show-N-Tell Thursday

Got a torch light --- will explore

Near Kuantan in Malaysia is the old mining town Sungei Lembing where Anthony's and Ernest's grandparents were born. The mines went out of business in the 1980ties, but the shafts are still there. Of course it is strictly forbidden and dangerous to explore them.
Anthony and Ernest as miners
When you translate "strictly forbidden and dangerous" into the languge of 2 nine year olds it awfully sounds like "fun and excitement".
The gentleman in green is Ernest Jian Long, the one in purple Anthony Bau Long.

Posted by on 18 June 2009 | Comments (1) | categories: After hours

How does the ideal Notes/Domino 8.5 upgrade looks like

Lotus Notes and Domino upgrades are comparable easy. The only challenge: poorly implemented Domino server will stay poorly implemented even after an upgrade. Unless of course you fix things. Once you know what you want to achieve there are many ways to get there. You simply could use smart upgrade to push out the clients and just install the new server software. What you end up with is your "old" Notes/Domino installation running with new code. That doesn't really cut it. It is like upgrading your trusted old Volkswagen two seater to a Mercedes S class (5 seater) but refuse to take more than one passenger, since that was your limit so far (or for that sake: drive faster than 150 km/h since that was the max the VW did). So how can you identify the ideal upgrade? Some of the following stuff should already run in your Domain, so it wouldn't require any effort other than a nod, but there are Domino installations that run despite their poor configuration (Domino is very forgiving):
Update: I have color coded items a well managed R6/7 Domain would have already before your upgrade.
  1. The Domino Server
    • You have defragmented your storage. You can use OS tools, an OpenNTF project or a commercially supported tool. Do that before and after the installation. You could consider different file systems used by other more stable operating systems.
    • You designed a high performance Domino server
    • You have implemented Domino Domain Monitoring (DDM) to run your server in "auto-pilot" (Don't forget the activity trends)
    • The Domino Configuration Tuner (DCT) has given you a clean bill of health
    • You have implemented the Certificate Authority. You use OU to divide your user base (typically by functions/departments/locations)
    • You have implemented the ID-Vault
    • You have cleaned your group structure to be machine verifiable and allows for next level automation
    • Users can create their own databases based on approved templates
    • All notes.ini variables you changed are in the server configuration document
    • Your SMTP routing is fully configured for Spam defense
    • The Domino server is clustered for high availability
    • Your network ports have encryption and compression enabled
    • DAOS is up and running (make sure you get your backups right)
    • Out-Of-Office is handled by the service, not the agents
    • The room and resources database is deployed
    • All servers in the same Notes Named Network can see each other on the network and each NIC interface on the server has its own NNN
    • Adminp runs flawlessly ( make sure your system databases replicate properly)
    • Traveler is up and running (buy yourself an iPhone as excuse)
    • All databases on your server have both the latest design and the latest ODS (currently ODS51)
    • You have designed and implemented Domino policies for all aspects of Notes/Domino usage (that might very well a project in its own right)
    • On your Domino server you have space for all user profiles since you have implemented roaming user profiles
    • You have installed and configured your Sametime chat entitlement
    • You have installed and configured your Quickr entry entitlement
    • There is a widget catalog with useful widgets for your organization
    • Smart Upgrade is configured
    • Your routing and replication structure is Spoke-Hub, not Hub-Spoke (that's a topic for another post)
  2. The Notes Client
    • You have defragmented your PC's harddisk. Do that before and after the installation. You could consider different file systems used by other more cherished operating systems.
    • Your machines have current drivers (Video is important) and patch levels
    • The Notes client installation has been moved to the Program Files for the application and the User Files for the user's data files (in Notes lingo we call that shared user install), so users logging into a workstation get their Notes install and not another.
    • You have implemented roaming users (one way or the other)
    • Policies configure and (if your users want to be dumb carefree) lock down your Notes clients
    • Shared login is implemented
    • The only version deployed is the full client, not the basic one. For weaker machines you use the notes.ini setting (deployed by a policy) to start the "classic" client
    • User know what the Notebook (formerly Journal) is for and use it
    • You deployed (optional) the MyAttachment tool
    • You have useful widgets configured
    • Firefox is your default browser
    • You have Windows, Linux and Mac clients
    • Smart Upgrade is configured
    • Users actually got upgrade training. (consider this)
  3. Your applications
    • You have identified performance gaps (e.g. too many lookups) and a plan to address them
    • The application's views are facelifted using the Java views
    • Your applications start making use of composite applications
    • There is a plan in place to recast your applications using XPages
    • You implement useful helpers in the sidebar
    • My personal favorite: You use eProductivity
    1. Important: The list above isn't the steps you need to do, but the results you should strive for. And remember: A lot of these should be in place already. If they are not, now is the time to clean-up. Don't settle for less. As usual: YMMV. Please comment what to add on.

Posted by on 16 June 2009 | Comments (7) | categories: Show-N-Tell Thursday

Not your usual Starbucks

Imitation is the strongest form of flattery. So a successful brand (or more accurate: excellent execution of a great idea: providing a 3rd place besides home) attracts imitators. Today at Xi'an's airport I was spotting a familiar sign, only on the second look it was quite different.
SPR Coffee at Xi'an airport.
While SPR shamelessly borrowed typeface, colour, style ideas (lights, seating or counter) and charming girls in green, they added their own style. There is full service at your table and you get a wide selection of Asian food. The coffee is good, but the late is not even close to the original.

Posted by on 07 June 2009 | Comments (1) | categories: After hours

XPages Workshops in XI'AN (today) and Hong Kong (06/07 July 2009)

Today I completed a short introduction into XPages for a business partner in Xi'an. Initially the participants were a little stiff:
Famous people from Xi'an
But with food and demo (click on the picture above) they warmed up to the new way of doing things. I'll spend the weekend in Xi'an visiting one of the five holy mountains of the Taoist: Mount Huashan. I'm curious how this will work out.
I'm pleased to announce, that I will conduct another XPages workshop, this time in Hong Kong. ( Update: Date for HK has changed!)The class will be on the 06/07 July 2009 and is open for registration. For details, location, fees etc. please contact Tony KT Lee from IBM Hong Kong.

Posted by on 05 June 2009 | Comments (2) | categories: XPages

Storing documents by lifecyle phases

In a business partner meeting (always an excellent source for blog ideas) in Beijing an interesting question popped up: "How should I split a (Domino) database if it gets really huge". The usual approaches are to split them along location or department lines. However in the discussion an interesting alternative approach emerged:
Database size vs. Update frequency
Document go through 4 phases:
  1. Draft: the document gets created but is not complete yet. Very often that state is neglected by Stalinist validation code.
  2. Current: The document runs through a workflow and people actively work with it, changing it often (e.g. add approvals)
  3. Historic: The document reached its final form and does not change any more. The document is still relevant and is looked at (often)
  4. Old: Nobody cares for the document any more, but you want to keep it for compliance or forensic reasons
From 1-4 the frequency of updates is declining while the number of documents is increasing. So splitting these documents into 3-4 different databases can make sense. In a XPage (or Dojo) application you can unify the display of these data easily. Food for your thoughts.

Posted by on 04 June 2009 | Comments (0) | categories: Show-N-Tell Thursday