You might have followed part 1 and part 2. The story continues. Netgear's support process is broken and needs fixing. Luckily there are real people behind that process that are passionate about their products and customer happiness. Netgear confirmed, that my unit doesn't have 5 years of warranty and that the online warranty registration has a bug and that they started a review to fix the date. So at least they want to clean-up. Behind the scenes Chirpafrom the ReadyNAS support forum and Andrew Tan from Netgear Singapore worked on the case and I'll get my unit fixed for free. The spare part should arrive next week (while I'm doing XPages in Seoul) and I will be a happy camper.
@Jonathan: The ReadyNAS Pro is in high demand and on backlog. Andrew mentioned PK Computer at Funan will be happily sell you a unit, you just might need to wait a few days before it arrives.

On my last entry I got a comment, that your blog has been selected for the exclusive list of 100 IBM blogs. While I like flattery, it at the same time makes me suspicious. After all there are way more than 100 IBM blogs. They obviously did some homework, since on my page there was an ad suggesting to loose stomach fat, a topic I'm struggling with <g> The badge they suggest to display on my blog seems harmless enough (flat image link, no JavaScript goodies. Anybody encountered them? What are they up to?

Matthew 6:3 states " do not let your left hand know what your right hand is doing " and Netgear's support seems to have incorporated that. They only confuse " But when you give to the needy" with " But when you organise your customer care". While Chirpa from the ReadyNAS forum tries to help and confirms 5 years of warranty, other parts of Netgear think differently. I got a reply from Netgear this evening (to be fair: they sent it before lunch, but I was in the air then) stating that all information given by helpdesk is wrong: the companies stated as distributors are no longer distributing Netgear and the warranty supposedly is expired already (interesting fact: 5 years ago there was no ReadyNAS NV+). The online registration website of Netgear clearly states 17 Dec 2012 as expiration date of the unit

(And they can't type my name. How hard is copy and paste?). So we struggle on a little bit. Stay tuned.
Update: Salvation

I used to be a happy Netgear ReadyNAS NV+ user for almost 2 years. Until yesterday. After a routine shutdown the unit wouldn't power on anymore. Just a short blink of the LED and end of story. I removed the disks and verified that it is the unit, not one of the disks. So far so good, s**t happens, that's what warranties (the ReadyNAS comes with 5 years of it) and support lines are for.
So I called the 24x7 hotline proudly promoted on the Netgear Singapore website. Since I called after hours (I have a dayjob after all) I was transferred to the international support centre. To make it clear: everybody was polite and followed their scripts - but utterly useless. So no one at the front line to blame, rather the guys who designed that support system. Netgear's support centre is located in India (surprise, surprise) and lot of the people I spoke to had a clear Indian accent. I'm fine with that, a lot of my friends are Indian and typically fine folk. Someone with no exposure to Asia might struggle a bit.
The first person just functioned as a kind of dispatcher, giving me a case id and connecting me to a support engineer. The engineer concluded that a unit not powering up is a level 3 issue, gave me a new case id and connected me to a level 3 engineer. Than engineer concluded what I told the first guy: "The unit needs servicing". But he neither could issue a RMA number nor tell me where to bring the unit. He connected me to the department in charge, at least he thought. I ended up disconnected. So I called again. Stated my case ID, went to the second level engineer who then directly connected me to someone else. Every time I get connected I had to not only wait considerable time but also restate my case ID to every person I talked to. Now they told me I have to call the Singapore hotline to get an RMA for Singapore. I didn't pay attention that moment, but it turned out that it was the number I called in the first place. So I went through another round. When I ended in the same department again the person told me, that her supervisor could help but currently was in a meeting and would call me back. Which (s)he didn't. So this morning I called again. I asked the first guy why he not just could press the button and issue me a RMA and tell me where to bring the unit. He told me that they had different departments and his wouldn't handle ReadyNAS and that he would loose his job when breaking the rules and that he wouldn't do that. So I went through phone hell again. They tried to deflect me again to the Singapore support number (the one I was calling). After insisting that that is not a solution, they gave me the Netgear Singapore office number (for your reference: +65 62336810). It is Saturday, so what happened: A tape announcement tells me that the office operates Monday to Friday during office hours and anyway for technical support I should call the 24x7 hotline (from Singapore 800 6011 369)... exactly that number that was so useless in the previous calls.
In conclusion: Netgear's claim of 24x7 support is a laughing joke. I spend 2 hours on the phone, spoke to 15 different people, ended on a dead line 4 times and still have a broken unserviced unit. I feel like Buchbinder Wanninger ( German original). This is a classic case of " Support process, broken as designed".
Update: To add insult to injury... I sent sales@netgear.com a link to this blog entry that bounced back with a 550 content rejected.
Update2: (23Aug2009) With a copy of the entire blog post the message to netgear went through. Chirpa from the Netgear support forum tries to be really helpful. My wife briefly spoke to the guys from the shop where I bought it, they claim that their waranty for Netgear is 12 month (which is BS of course) and I got an online update from Netgear providing me the contact details of Singapore's Netgear distributors handling RMA for them. Shot an eMail off to them, wait what's happening on Monday.
Update 3: Salvation

Christmas season is coming, the mobile contract is up for renewal. So I'm device hunting. This looks promising (full Linux):

On the other hand. My favorite China-fake-phone-chipset supplier has recently published a Android capable chipset and once you get used to TV and dual sim card the phones are actually nice:

(did I mention that I'm used to use beta quality software only).

The last attempt to work with large number of entries in reader fields didn't work that well, so I try again. Andre suggested to limit the number of entries for performance (and after all if there is any breathing human inside the little yellow bubble understanding Domino performance it is him): " The other thing to think about is performance. When a user opens a view, the server has to decide which documents they have access to. So it takes a list of their groups and roles, and compares each of them to the Readers list of each document. If the user is in 30 groups and there are 500 values in the Readers field, that's 6000 string comparisons to determine that the user doesn't have access to one document. Multiply that by the number of documents in the view." So here is the plan:

• The class signature stays the same as in the previous version. Signature means: the properties and methods and their parameters
• Every application gets an unique identifier, so distinct group names can be build
• Once the number of entries reaches a threshold automatically groups are created in the NAB (That group creation for sure could be subject to great debate. Here are the options I was thinking about:
  • Allow direct access to the NAB to create/update groups. This option is feasible when the class is used for a web query save agent and the agent signer has sufficient rights
  • Store the names in Names fields and have a separate "When documents have been created or changed" agent process the changes
  • Use a "Run-on-server" agent and provide the document via the agent context (This also requires to "buffer" the names in Names fields
  • Use a web service to update the NAB
  • Use a mail-in database to handle request
• The DocumentUniqueIDs of all documents in use are recorded, so access becomes much faster (getDocumentByUniversalid vs. getFirstDocumentByKey)
• Not considered: check for duplicate groups - as in: check if a group with the same members. That would open a Pandora's box of checks: what to do if one document alters the group?

I updated the class and implemented "direct NAB update" and "mail-in a change request". The class picks on the basis of access to the NAB. Currently it works for server databases only (not local replicas, some more logic needed there) and it doesn't capture the UNIDs of the group documents. Further more it is lacking better error handling and documentation. Have a look at the modified class.
As usual: YMMV.

I have currently the pleasure of introducing new developers to Lotus Domino. While it is old new to the Yellow Bubble our new members wonder about code style and code smell for LotusScript programming. Looking at a lot of the existing code base they rather get a wrong impression. So we went through a few guidelines. Of course sticking to them becomes a lot easier with the new LotusScript editor in 8.5.1:

• Every time you skip OPTION DECLARE an angel must die. So for the love of [insert-what-is-holy-to-you] configure your preferences to automatically insert it. I've submitted a request to parliament to cane serial DECLARE offenders <vbg>
• Keep them short. Functions that carry on over hundreds of lines are a maintenance nightmare. A function does one thing at a time. So the routine that loops through your document collection doesn't process the individual documents, but calls a function with the document as parameter
• Names need to have a meaning. So variables a, b, c are a bad idea. Same applies to sub1, sub2 etc. There are very few exceptions like s for the current session, db for the database, dc for the document collection, v for the view and doc for the document to work on. Read Joel's write-up on naming conventions.
• Decompose your applications well. If you think that is a process of biological decay, take a free Stanford University course in computer science
• Global variables are a lazy programmers sign post (of course no rule without exceptions)
• Call MsgBox(Err$) is not error handling. It is pure laziness. Use an error handling framework like Julian's OpenLog or Devin's enhanced log, both available on openNTF. Name your error handlers like the function: ON Error goto Err_[NameOfYourFunction]. Use a Exit_[NameOfYourFunction] label as common exit point and have your error handlers at the end of the function (see the code templates below)
• Comments don't hurt anyone. Missing comments do. Comment the WHY not the WHAT. Use lsDoc to extract your comments into your documentation
• While commonly associated with Java only know your Software Design Patterns. Know them well. Read a book. Also know your Anti-Pattern (like this one)
• Make good use of the LIST keyword. LIST are fast and can replace repeated lookups. A list can't contain a second list, but an object with a list as public property, which can contain object with a list as public property ... you get the idea.
• I like the factory pattern. While the factory implementation is not in line with the pure teachings it makes the code much more readable (see code below)
• Don't sprinkle your (web) forms with JavaScript calls. JavaScript belongs into JS files and referenced. Also a bad habit is to hard code the form to act on document.forms[0] will break sooner or later (when you add the custom tagging or the portal integration or or or)
• Don't use document.all.[NameOfSomeButtonYouAddedHiddenly].click() to execute special functions. If you have back-end functions to call use a hidden field [NextAction] and a custom submit button (passthru HTML): <input type="submit" value="Do something special" name="NextAction"> The field NextAction will contain the value of the button. If you are smart you read the label from a config document, so you can change it without breaking your code.
• While it is convenient rethink the use of the shorthand doc.[FieldName]. While it has (against common believe) no measurable impact on performance it has an impact on readability (if you see doc.something you need to think every time is this a property or a field name) and your ability to switch between languages since Java and JavaScript don't entertain this notion.
• ViewEntries beat documents in speed any time. If you have to run through a long list of entries and only need to update a few, pack the criteria you need into view columns and run through the ViewEntries opening only the documents you need to change.

Some code templates we looked at:

In Domino 8.5.1 we will have a new Design Element "Component". This design element can be used in Portal, Mashups and the Notes sidebar as iWidget as well as composite component in the Notes client. In a component you pick 3 XPages (could be the same for all 3 cases) for read, edit and help mode. You also define the events the components "knows" and what type of event is is for that component: sending, receiving or both. An event is associated with a data type that can be primitive (String, number), JSON or a complex data type you defined with that component.
Components are the Lego blocks of your applications. A system designer now can quickly build "empty" components wire them up and then leave the implementation to the XPages development team. This could accelerate Domino's RAD capabilities further.

Notes and Domino applications often revolve around documents and approvals. When editing a document the application must ensure that nobody else can edit it. In Lotus Notes applications we have the Document locking functions which can even do a distributed locking. Looks good works well, if it wouldn't be for the last sentence in the developer help: Locks are not supported in Web applications. So you need to roll your own. Distributed operation can be tricky. The solution is to use an XPage (or servlet for older versions of Domino) on each server that runs a locking service. This service figures out what's the master lock server and tries to use it. If succesful it issues a lock, on failure to reach it it provides a provisional lock. The master server registers which server has asked for a lock status and notifies them when a lock is removed or renewed. Lock information is locally cached to minimize user delays. The flow would look like this:

There are a number of considerations when designing the detailed functionality:

• Should the document be locked only by the service (for web documents) or also for opening the documents from a Notes client
• Should the locking service use the master server to lock (yes if you answered the previous question with yes), optional - you could get away with code without Domino classes
• How to execute the locks: do a Ajax call before opening? Run the check in the QueryOpen? Check on save that you had a valid lock?
• Should a lock expire automatically (so no unlock function is needed) but the clients need to renew their locks periodically. How long would a lock live (5 minutes in a typical webDAV server)?
• Should a lock be persistent (the opposite of the expiring locks) and survive a server reboot?
• Would single sign-on be required (LTPA)?
• What would a syntax look like both for requests and responses?

This is what I came up with:

http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=lock&db=databasereplicaid&doc=documentuniqueid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=status&db=databasereplicaid&doc=documentuniqueid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=unlock&id=locktokenid
http://one.ofmy.servers.com/lockmaster.nsf/service.xsp?action=relock&id=locktokenid

Since a user "talks" to their own server the lockmaster has access to session.username. So a relock or unlock request can be verified against the user who made the original reqest and ignore/reject invalid username/token combinations. The response from the lockmaster would be in JSON and rather lean:

{ "status" : "ok|fail",
   "db":"databasereplicaid",
   "doc":"documentuniqueid",
    "owner":"Full name of the Owner"
    [, "id":"tokenid"]
    [, "expiry": 600]
    [, "msg":"Eventual explanation of the failure"]
}

The response slightly varies depending on the type of action performed and by whom. Using this approach you should have a fairly robust browser based locking mechanism.

Accessing RDBMS from Notes applications is quite popular. One of our customer asked what is an acceptable performance when accessing an Oracle database from XPages. We discussed test patterns and approaches. Just running one type of test wouldn't give an accurate picture. The total time for a test run is compiled from the raw database access speed (mostly network and the local driver performance), the Java JDBC layer, the XPages engine and the application running on XPages. So you have to test all these components:


So how to test these (you could rip the steps apart on a scientific basis, but they hold steady for practicality). Never forget that the subject and object of an observation influence each other. The bare fact of measuring the performance changes it:

1. Network and native library: You use the command line interface (in Oracle a terminal like window) to execute whatever query you want to test. Record the time. You can proably automate this using a tool like STAF. This is your base line. If that is already slow, you know network and database might be the problem already (and yes: you could run the test on the DB server too eliminating the network in between too).
2. JDBC and Connection pool: You don't write your own Connection Pool manager? Using a few lines of Java again from the command line will show how your VM is doing and how well the JDBC driver talks to the native libraries. You would already have a class that implements the Java LIST interface (preferably as virtual list), so you can use that as a data source later on. Heap size is a good candidate to tweak performance here
3. XPages engine: You have code in one button instantiating the class you already used in the previous step and execute the same queries. This will show you the difference between "raw" Java performance and the XPages engine
4. Your XPages application: All your code is here, your events, your JavaScript. The difference to the previous step highlight optimization potential in your code

Don't forget: running a test once isn't real. you need to have multiple iterations and use tools like JMeter or Rational Performance Tester to simulate concurrent user load. As usual YMMV.

The Portal Excellence Conference 2009 in Macao has concluded successfully and I'm off to Hong Kong. The ferry from/to Macao from Hong Kong can compete easily with any ride in Disney Land. After visiting customers all over China I will present at the Lotus Technical University in Melbourne, Australia on August 25-27 2009. I have quite a packed schedule:

1. 25 Aug 13:30 - 14:30 : Integrating Custom Domino Application Assets and Portal (Presentation)
2. 26 Aug 10:00 - 11:00 : Building your first XPages Application (Hands-On Lab)
3. 27 Aug 09:00 - 10:00 : Supercharge your Domino Applications with XPages
4.        15:30 - 16:30 : Domino and Quickr: It takes two to tango (Presentation)
5.        16:30 - 17:30 : Domino Performance tuning

I think the event is worth attending. When you are around, stop by and say hello.