Best Practice Makes Perfect

DXL and fake security

Andre Guirard — Wed, 1 Jul 2009 12:32:56 -0500

The question before us today: should the DXL Exporter give an error and refuse to export design elements if (a) the user has less than Designer access to the application, and/or (b) the design of the application is hidden?

I'm going to argue that the answer is "no" in both cases. At the moment, there are restrictions -- you can't export any design elements if the database design is hidden, and (last I checked) you can't export an entire design at once if you don't have Designer access, but you can export individual design notes.

Some of you might regard these as security features, e.g. if you're using hide design to prevent users from seeing information in "hidden" fields, you don't want them to export the form design and see what the field names are. Others, including myself, regard these limits as a nuisance that does far more harm by preventing useful applications, than any good that may come from making it easier to hide information.

This is an example of "security through obscurity;" it only protects your information insofar as the people trying to get to it don't know how the technique for bypassing the restriction. Security through obscurity is still security; for instance, I know that it's not all that hard to open any combination padlock if you know the trick, but I'm not overly concerned that someone will use that knowledge to break into my gym locker (though I always give the dial a couple of turns to make it harder, should anyone try). But security of any sort is only valuable if there's not an obvious workaround.

There are several APIs that let users access information about Notes databases and design elements. None of these APIs are restricted by lack of Designer access or by design hiding (except that you can't get formulas that are hidden without going to the C/C++ APIs).

For instance, here's a very simple way to see the values of hidden fields in a database with hidden design. Any user can do this even without the Designer client, and without using DXL.

There are also various tools, such as NotesMan and the Teamstudio suite, that let users with zero application development skill get all sorts of detailed information about nsf files. The NotesPeek program, which is publically available, also will give you basically all the information you would need to know about an application. DXL adds very little to that.

Even without such tools, a user who can program in LotusScript or Java can use those APIs to get basic information about the names of design elements and their contents -- a list of all the fields on a form, for instance. The DXL restrictions I'm discussing seem to be aimed at users who can program, who have a Designer client, and are looking for information that they couldn't get from these other APIs or from publicly available tools. To me, this sounds like an empty set.

But let's just suppose for a moment that there are such users. We have to also assume that they aren't bright enough to use the NotesNoteCollection class to get all the design elements in the database and copy them to a local database without a hidden design, in which they are Manager. Then they can use DXL to their hearts' content. This is really pretty obvious, and takes maybe 10 lines of code.

The Hide Design feature, in particular, isn't really appropriate to use for security. Read/write access to documents and design elements, database ACL lists, and the like -- those are security. There are too many ways for an even somewhat clever person to get access to any information that they technically do have access to, for that to be effective as a security measure. Hide design's real purpose is to protect proprietary source code.

So in brief, these DXL limitations do very, very little to protect information, but they do make it more difficult to write efficient applications that use DXL to do useful tasks, such as scanning databases on a server for fields without field help or images without alt text.

Please comment. If you support leaving these restrictions in place (or adding to them!), could you give examples of a way in which they increase security or some other benefit?

Grouping docs in memory

Andre Guirard — Mon, 22 Jun 2009 07:51:48 -0500

I recently dealt with a question from someone who wanted a way using LotusScript to take a document selection and export each document's data into one of several files, grouped based on the value of the "AssignedTo" field -- so, a separate file for each person documents are assigned to. Having too many files open at a time would be a blocker, so they needed to sort the documents first to write all the data for one file, then move on to the next file.

When faced with such a problem, a lot of people's first instinct seems to be to create a folder that's sorted the way they want, put the documents into it, then read them back out. While this works, it's not going to give the best performance, because there's a lot of overhead involved in removing the old set of documents from the folder, adding new ones, indexing the view, and reading them back out. It's a lot of disk activity and network activity, slowing the server (assuming it's a server database), and it makes the database bigger than it was before, because folder membership is tracked by little records associated with the folder giving the document ID, timestamp, and whether the document was added or removed at that time. This is necessary so that folder membership can replicate. Besides which, we have a problem if there are multiple users working with the same folder, that they may interfere with each other.

It's much more efficient to sort documents in memory, but people don't like having to write extra code to do it. I'm working on a sample LotusScript library that should make this a lot easier, but in the meantime, here's the approach I suggested. The specific application didn't really require the documents to be sorted -- just grouped into collections that go in to the same export file. So I suggested this approach:

Dim session As New NotesSession

Dim ByAssigned List As NotesDocumentCollection
Dim selected As NotesDocumentCollection
Dim db As NotesDatabase
Dim docCur As NotesDocument
Dim strAssignedTo$

Set db = session.Currentdatabase
Set selected = db.UnprocessedDocuments
Set docCur = selected.GetFirstDocument()
Do Until docCur Is Nothing
strAssignedTo = docCur.GetItemValue("AssignedTo")(0)
If Not IsElement(ByAssigned(strAssignedTo)) Then
Set ByAssigned(strAssignedTo) = db.CreateDocumentCollection
End If
Call ByAssigned(strAssignedTo).AddDocument(docCur)
Set docCur = selected.Getnextdocument(docCur)
Loop

ForAll coll In ByAssigned
strAssignedTo = ListTag(coll)
' generate report for person strAssignedTo from documents in coll.
End ForAll

This isn't perfect; there's probably a limit to the number of documents you can have in a collection, so you maybe could handle larger data sets by defining your own classes (which, as I mentioned, I'm also working on making simpler). But for a limited set of applications, this gets the job done without many lines of code, and without the overhead of working with folders.

Shared actions and hidden designs

Andre Guirard — Tue, 16 Jun 2009 12:36:07 -0500

Something I happened on recently in the course of helping the template developers, that I thought might not be generally known.

When you create a shared action in LotusScript, if it uses unknown names, you are allowed to save that shared action, even though the syntax would be considered incorrect for code used in any other context. For instance, if you write this line in an agent:

Set ctx = GetExecutionContext( doc )

the compiler will complain if the GetExecutionContext function isn't defined elsewhere in the code. A shared action will tolerate this, however, with the expectation that the reference will be resolved at runtime as a function in the form, view, or whatever that includes the shared action.

What's important to realize about this, is that the compiler still can't produce object code with this unresolved reference. So for this shared action, Designer saves only the source code. When the action is used, the source must be compiled at runtime in the context of the design element containing it.

Of course, this is only possible in cases where the source code is available at runtime. So, shared actions containing unresolved references are not compatible with being able to hide the design of your application.

If this is a problem, define a script library that includes the globals and/or functions that you want your shared action and form (or whatever) to share. Both the form and the shared action would "use" that library. When code is loaded, script libraries referenced in multiple places in the code are only loaded once, and their global variables only allocated once. So if a form event assigns a global that's defined in the script library, and a shared action reads that same global, it will see the value assigned by the form code. Since this can be successfully compiled, the object code is stored, and no runtime compilation is needed.

DXL frameset workaround

Andre Guirard — Mon, 1 Jun 2009 12:03:37 -0500

I noticed this morning, while writing a utility that uses DXL to reverse the order of left and right frames in a frameset (for BIDI) that the representation for complex framesets, though it "round trips" successfully, is not structured as one might expect. For instance, consider the frameset shown on the right. We would expect the DXL to have a tree structure such as:

1. frameset
....	a. frameset
....	....	i. frame A
....	....	ii. frameset
....	....	....	x. frame B
....	....	....	y. frame C
....	b. frame D

However, the actual structure is:

1. frameset
....	a. frameset
....	....	i. frame A
....	....	ii. frameset
....	....	....	x. frame B
....	....	....	y. frame C
....	....	iii. frame D

A subtle but important difference -- frame D is a child of the wrong node.

The importer doesn't actually pay attention to the XML hierarchy in this case. Instead, it looks at the 'rows' or 'columns' attribute of a frameset element to determine how many children it has. That's why the round-trip works, and of course, if you wanted to manipulate the frameset in a way that doesn't depend on the structure (replacing a replica ID in links, for instance), it's not a problem. But if you're doing something where it does matter (as it does for my application), the workaround is to fix up the DOM tree using a routine such as the following:

Sub FixupFrameset(domeFS As NotesDOMElementNode, parent As NotesDOMElementNode)
' domeFS is a element which we must verify contains the right number of children.
' If it does not contain enough, error out. If it contains too many, the spares should be moved to
' the parent, which is assumed to be also a frameset. Process recursively.
' Note: this could be done without passing in the parent element, since it can be retrieved from
' domeFS. But passing Nothing for this argument on the initial iteration, lets you prevent
' a node being added as a child of a non-frameset node, without having to take the time in here
' to test whether the parent is a frameset node.
' This is to workaround a bug in the DXL exporter output, where frameset elements are not closed
' early enough.
Dim strElems$, cExpected%, values
strElems = domeFS.GetAttribute("rows")
If strElems = "" Then strElems = domeFS.GetAttribute("columns")

If strElems = "" Then
cExpected = 1
Else
values = Split(strElems, " ")
cExpected = 1+UBound(values)
End If

Dim domn As NotesDOMNode
Dim domeChild As NotesDOMElementNode
Set domn = domeFS.FirstChild
Do Until domn.Isnull
If domn.Nodetype = DOMNODETYPE_ELEMENT_NODE Then
Set domeChild = domn
Dim strNam$
strNam = domeChild.Nodename
If strNam = "frame" Or strNam = "frameset" Then
If strNam = "frameset" Then
FixupFrameset domeChild, domeFS
End If
If cExpected = 0 Then
domeFS.Removechild domeChild
parent.Appendchild domeChild
Else
cExpected = cExpected - 1
End If
End If
End If
Set domn = domn.Nextsibling
Loop
If cExpected > 0 Then
Error 13990, "Frameset contained fewer children than the columns or rows attribute indicates (" & strElems & ")."
End If
End Sub

DXL priorities -- your input requested in Crowded Wisdom

Andre Guirard — Tue, 26 May 2009 09:47:35 -0500

Revision: Never mind, looks like this survey is only open to Design Partners, who will have gotten email about it.

For everyone else, please note we're working with partners to make sure we do the highest-value improvements to DXL, first, as we work our way toward full fidelity.

Previous surveys of our business partners for DXL priorities have identified views, agents, and script libraries as high value areas for improvements. We've been working on those, and we believe you'll be pleased by the improvements in 8.5.1 CD6/Beta 1. We've greatly improved stability also, which was identified as a top priority.

We're about to plan the next phase of DXL work, and we'd like your further feedback to help us identify which improvements will be of the greatest immediate use to you. We're focusing on getting as much as we can into 8.5.1 to do the most good.

Please help us prioritize our upcoming activities by thinking about what you need most to do the things you want to do with DXL; then go to Crowded Wisdom on bleedyellow.com and weigh in. We'd like feedback from more people and thanks to this tool, are equipped to measure with more precision the relative "weight" of potential improvements.

Queryclose issue revisited

Andre Guirard — Wed, 20 May 2009 14:11:12 -0500

Earlier, I blogged about the problem of Queryclose code being unable to prevent closure of documents in the Eclipse-based Notes client. This is SPR # AGUD7DSU3Q. At that time I described a "fix," actually a workaround since in addition to installing a new version, it requires modifying the form.

We're working on a fix for 8.5.1 that would simply fix the problem (note: as always, no information about fixes in future versions can be considered final until the version is actually released).

If you feel this is an important issue, and particularly if you feel it will block deployment of 8.5 clients in your company (or your customers), please contact Lotus Support and open a PMR to request inclusion of the fix in an 8.5 FP. This will help me make the case for this internally, in case there's any push-back on doing the FP.

Equally, if you feel this is not an important issue and you'd prefer that developer work on something else, please feel free to respond by commenting here.

Thanks

We need a new developer FAQ...

Andre Guirard — Mon, 18 May 2009 11:52:58 -0500

I had reason to look recently at the FAQ we link to from the new topic form in the forums. It seems to me this is not the right format for our main purpose (heading off the same two dozen questions that get asked over and over). I'd like to have a FAQ document that directly addresses those questions, then tells them where to search for more answers. Here's my proposed list of questions; I've probably left off some important ones, so please chime in with any you think should be added or removed. My goal is to have up to 50 of the commonest questions.

Where else to look for answers.
Why doesn't anyone answer my question on the forum? Doesn't IBM monitor these?
@DbLookup, @DbColumn don't work on the web.
Other problems with @DbLookup, @DbColumn, GetDocumentByKey, etc.
Comparing date fields.
Documents in a view show up under different dates for different users.
My full text search isn't working.
How do I add fields to a form while the user is editing it?
Change the value of rich text in a document that's open in edit mode (add text, insert attachment, add a picture).
My application is slow.
@UserName doesn't work in view selection formula.
@DbLookup, other functions not working in view selection or column formula.
View selection to include only documents that have/do not have responses of a particular kind.
Sort view categories by total.
Sort view based on information in, or number of, response documents
Users can't edit documents they're supposed to be able to edit.
Users can't see documents they're supposed to have read access to.
Documents go missing.
Old documents suddenly reappear long after they have been deleted.
My hide formula isn't working.
How to assign a sequential number to each document.
Schedule an agent to run at time intervals that the agent properties do not support (e.g. the 1st and 3rd Sunday of every month).
Notes client or Domino server crashed; how do I find out why?

Thoughts about time travel

Andre Guirard — Tue, 5 May 2009 08:24:13 -0500

So there's someone with a PhD who says time travel is possible without the planet-sized exotic objects previously thought necessary -- he thinks he can build something human-scale.

The first application that springs to mind, of course, is to travel back in time and do something to stop Pauly Shore from making any movies.

Unfortunately, it's not possible to go back to before the machine is first constructed. Darn.

New article on date/times in Notes...

Andre Guirard — Sat, 2 May 2009 22:10:42 -0500

Just posted a new article in the Domino Designer wiki about working with dates and times in Lotus Notes. As usual, you are invited to comment if you see anything wrong or incomplete.

Link

Automate full-text search in client app

Andre Guirard — Thu, 30 Apr 2009 05:00:00 -0500

A feature added in the Notes version 8.0 client but not much publicized, is the ability to perform a full-text search in a view using a Notes URL. This makes it simple to automate the creation of complex full-text searches for the user, perhaps based on information they enter in a dialog.

The URL syntax to perform the search is:

Notes://server/db/view?SearchView&query=yourQueryHere

There are no arguments to control stemming and sort order; these go to the defaults that the user last used. The server, db, and view components can be as usual for Notes URLs, and the query parameter must be escaped into valid URL characters. If the view is already open, the search occurs in the open view window.

The code below demonstrates how to create a search in this way based on information the user entered in a dialog:

Sub Initialize
Dim session As New NotesSession
Dim wksp As New NotesUIWorkspace
Dim db As NotesDatabase
Dim docDialog As NotesDocument
On Error Goto oops

Set db = session.CurrentDatabase
Set docDialog = db.CreateDocument
If wksp.DialogBox("searchAssistDialog", True, True, False, False, False, False, _
"Enter Search Criteria", docDialog, True, False, True) Then
Dim query, url$
query = Evaluate({ @URLEncode("Domino"; Query) }, docDialog)
url = "Notes://" + Replace(db.Server, "/", "%2f") + {/} _
+ db.ReplicaID + "/" _
+ wksp.CurrentView.View.UniversalID + {?SearchView&query=} + query(0)
Call wksp.URLOpen(url)
End If
Exit Sub
oops:
Msgbox "error " & Err & " line " & Erl & ": " & Error
Exit Sub
End Sub

The agent code assumes that the form used in the dialog (searchAssistDialog in this case) contains a computed field named Query that calculates the query you want to perform, based on the field values entered by the user. Coming up with this query string is the most difficult part of this project, but this is different in every case, so there's little I can say here to help you, except to point out an example in the "Student FT Search Dialog" form in the free download that accompanies this article: Views Part 1: User-Based Views and Query Assistant. The article describes other, harder ways of doing what we are now doing more simply using this new URL capability.

Of course, you could read the user's field values in the agent and calculate the query there, but I like an approach that lets you put everything that needs to know what fields are in the user assistant, into a single design element. If you prefer to use LotusScript to calculate the query, you could do it in the Queryclose event of the dialog form.

Note: the expression wksp.CurrentView.View.UniversalID doesn't work in desktop private views. You might want to modify this code to see whether wksp.CurrentView.View returns Nothing, and in that case use the view name or alias instead. In case the UNID is available, though, it's more reliable, since there may be duplicate view names or aliases.

Performance with @AllChildren

Andre Guirard — Thu, 23 Apr 2009 05:00:00 -0500

A performance question came up after my presentation today which I thought I should address with a blog entry. This has to do with the database option "Don't support specialized response hierarchy" and the associated functions @AllChildren and @AllDescendants.

"Specialized response hierarchy" refers to an internal table stored in the NSF that lets Notes quickly locate all the responses to a specified parent document. Without this table, functions that require this ability -- such as the above-mentioned functions and the NotesDocument.Responses property -- simply do not work. Instead, they act as if the document had no responses. Of course, it's extra work for Notes to update this table every time a note is modified, so it's better to turn the option off if it's not needed. But how do you tell when it's needed?

Let's take a sample application containing one main form, and one response form. You want a view that shows the main documents whose status is "Unfinished", and also their responses. Without using the responses table, you could write the following selection formula:

SELECT (Form = "Main" & Status = "Unfinished") | Form = "Response"

I'm assuming that the response documents do not contain any field value that would let you tell whether their parent is in the view.

To do the same selection assuming the specialized response hierarchy enabled, you might write:

SELECT (Form = "Main" & Status = "Unfinished") | @AllResponses

On the face of it, there seems to be no differences between these two approaches. In either case, only those responses whose parents are in the view, are visible.

However, it's not quite so simple. Suppose there are 100 main documents and each of them has one response, and suppose 20% of the main documents are at "Unfinished" status. In the first case, all 100 response documents are also in the view, even though most of them are not visible. They're in the stored view index, and you can find them with a full-text search. So the index contains column values for 120 rows of data.

In the second case, the view index contains only those responses whose parents are also in the view. That's 20 main documents and 20 response documents, a total of 40. So the stored view index is smaller, and probably takes a lot less time to calculate just because fewer documents must be inserted into it.

Incidentally, you can see the size of the view indexes using Domino Administrator, if you want to try a test and compare for yourself.

Also consider what happens while the first view is being indexed -- imagine yourself in the situation of the view indexer. You're handed documents in random order, and you have to insert them into the index at the appropriate position. Every time you find a response document, you have to search the view for a matching main document (one whose UNID matches the response's $REF). Locating a document in a view by UNID is pretty fast, but it's not instantaneous. Also, if you find a response document and don't find the corresponding main document, you have to insert it somewhere in the index anyway to keep track of it until the matching main document does turn up, if that ever happens.

When using @AllResponses, on the other hand, it's not necessary to search the view for a main document matching a given response, or vice versa. That's because when you find a main document that should be in the view, you can immediately grab all the responses from the internal "response hierarchy" table (a quick search because it's sorted by UNID), and they can be inserted into the index immediately following the main document you just added. If the first part of the selection formula matched any response documents, you would still have to insert them provisionally until their parents turned up, but in this example that's not going to happen (much -- if there's a replication conflict document it could end up that way).

So that sounds like less work. I haven't tested it, but it seems reasonable -- don't you think?

Update method for unsaved rich text

Andre Guirard — Thu, 16 Apr 2009 05:00:00 -0500

A tip for people generating rich-text reports on the fly and displaying them without first saving the report document....

This is fine, but you may find that your report is missing whatever bit of text you added last. When you save or mail a document, any pending changes are saved into the rich text item, but if you just use NotesUIWorkspace.EditDocument, you first must call NotesRichTextItem.Update, which flushes pending output to the rich text item.

Do Until doc Is Nothing
...
reportBody.AddNewline(2)
Set doc = documentCollection.GetNextDocument(doc)
Loop
Call reportBody.Update()
Call ws.EditDocument(False, docReport)

So tell me again why you’re not using profile documents?

Andre Guirard — Wed, 25 Mar 2009 17:54:04 -0500

I've been doing some experimenting to determine best practice recommendations about profile documents. They're problematic for use in web apps, granted, because their cache on the web server is very long-lived. For client applications, however, I don't see any reason to avoid them, and from a performance standpoint they have much to offer as an alternative to looking up configuration information using @DbLookup or @DbColumn.

The main problem you need to avoid in the client, is the creation of blank, duplicate profile documents when someone uses a replica that's not fully initialized (i.e. has not yet replicated the profile document). However, this is not hard to do.

First, @GetProfileField will never create a profile document. You can use the function on forms and so forth without worrying about creating bogus profile documents if the profile hadn't been replicated yet to a new replica. @SetProfileField will create a profile if it doesn't exist.

Profile documents are also unaffected by replication formulas. I'm sure this hasn't always been the case, but not sure when it changed. Again, with this change, there's less chance of the profile getting zeroed out by someone trying to use it in a local replica.

We also have ways in LotusScript now, to retrieve a profile document without creating it. Instead of db.GetProfileDocument(x) you can now do, for instance:

Set docProfile db.GetProfileDocCollection("MasterProfile").GetFirstDocument()

And then, of course, you have to check whether docProfile "Is Nothing" before you try to use it, but really you should be doing that anyway.

As for keeping track of your profile documents, some time back I posted a tool to view and control all the profile documents in an application.

To let someone edit the profile, you would want to do it in a way that can't result in someone creating a duplicate profile -- at least not without a fair warning. So you wouldn't just use @Command([EditProfile];...). Instead, you could use an action button or agent with code such as the following:

Option Public
Option Declare ' always use Option Declare
%INCLUDE "lsconst"
Const WINDOWTITLE = "Application Setup"
Const PROFILENAME = "MasterProfile"

Sub Initialize
Dim session As New NotesSession
Dim wksp As NotesUIWorkspace
Dim db As NotesDatabase
Set db = session.CurrentDatabase
Dim docProfile As NotesDocument
Set docProfile = db.GetProfileDocCollection(PROFILENAME).GetFirstDocument()
If docProfile Is Nothing Then
If db.CurrentAccessLevel < 6 Then
Msgbox "Only the database manager may create the setup document.", _
MB_ICONSTOP, "Application Setup"
Exit Sub
Else
Dim result%
result = Msgbox({Warning! Setup document does not exist. Do you want to create one?

If one already exists in another replica of this application, it will cause problems.}, _
MB_ICONEXCLAMATION+MB_YESNO+MB_DEFBUTTON2, WINDOWTITLE)
If result = IDNO Then
Exit Sub
End If
End If
End If

wksp.EditProfile PROFILENAME
End Sub

Come to think of it, I guess you could do this using a formula if you used @GetProfileField first to check whether the thing existed. To check whether a profile document exists in formula language:

@GetProfileField("profilename"; "$Name") != ""

So to integrate this into a "Edit Profile" action:

PROFILENAME := "MasterProfile";
@If(@GetProfileField(PROFILENAME; "$Name") != "";
"profile exists - continue";
@UserAccess(@DbName; [AccessLevel]) = "6";
@If(@Prompt([YesNo]; "Application Setup"; "WARNING! You are about to create a new setup document, which will be a problem if there's already a setup document in another replica which hasn't been replicated to here yet. Do you want to proceed?");
"";
@Return("cancel")
);
@Return(
@Prompt([Ok]; "Application Setup"; "Sorry; only a database manager can create a setup document.")
)
);
@Command([EditProfile]; PROFILENAME)

So, if we have some holdouts who are still not wanting to use profile documents in their Notes client applications, please comment -- why not?

Need your DXL priorities

Andre Guirard — Tue, 17 Mar 2009 12:31:00 -0500

I'm on the team working to improve DXL. Our goal is to make it round-trippable as has been occasionally requested by developers, but it's a big job. So, we're trying to figure out what part of that we should attempt for version 8.5.1.

NOTE: As usual, this does not constitute a promise on IBM's part to provide any specific functionality in any specific version.

Please chime in with your prioritized list of the top five or so specific DXL issues. An explanation of how those fixes would affect you/what you would be able to do that you can't now, would be welcome also.

Also, please comment on what full fidelity means to you. Is it sufficient if the design element or document is identical in terms of function and appearance, or do you need it to be identical bit for bit (except for the timestamps and signatures, of course), and why?

Thanks.

See you in Denmark?

Andre Guirard — Tue, 10 Mar 2009 10:46:25 -0500

I've been invited to speak at the DanNotes User Group conference, April 22-23 this year. I'm looking forward to getting together with the folks there -- and sweating to pull together some content to present in my copious spare time. I expect my topics will be new Designer features (especially the LotusScript editor), XPages, and design for performance (which got excellent reviews at Lotusphere).

I think registrations are still open, for any of the European contingent who are interested. To keep it accessible, I promise to present in English, not Danish -- a very easy promise for me to keep!

Covering beginner topics for the Designer wiki

Andre Guirard — Mon, 23 Feb 2009 09:55:05 -0500

I haven't been adding much technical content to this blog recently, because the little time I have available for that kind of thing has been going toward the Designer wiki. My most recent article there is How to Write a Hide Formula (about which, as usual, I invite reader comments and corrections). This is fairly basic formula stuff, but it's the sort of thing that beginning developers often have a hard time with.

You folks who read this blog, probably have similar things that you could contribute. I'd like to see the wiki become a resource for Notes developers of all levels to go when puzzled, or when they have spare time to read articles that might benefit them for later projects. So we need a range of information from the basic to the high-end. What seems obvious to you might not be obvious to everyone. Are there development techniques you use routinely that might be a pleasant surprise for someone new to Notes development?

Delaware and Hawaii -- the answer

Andre Guirard — Mon, 9 Feb 2009 09:36:19 -0500

The question was: what do Delaware and Hawaii have in common, different from other U.S. states?

Both states have a "punch" soft drink which you can buy in other states and overseas.

It doesn't seem that any other states have punches. I know, Delaware Punch is a little obscure, but I think people had a fair chance using Google. :-)

Delaware and Hawaii trivia question

Andre Guirard — Fri, 6 Feb 2009 05:20:00 -0500

What do Delaware and Hawaii have in common, different from other states?

Hint 1: Some may say it's really not Delaware, but Ohio. Phooey on the quibblers, say I.

Hint 2: You probably have to be about as old as I am, or live in certain states (oddly, those states do not include those mentioned above), to get this without the assistance of Google (which I would consider cheating -- you're on your honor!).

Be the first with a correct answer, and win fame and glory! No actual prizes, sorry.

A challenge for formula weenies

Andre Guirard — Thu, 5 Feb 2009 04:00:00 -0500

I just published a Domino Designer Wiki entry on troubleshooting @DbLookup (and other lookup operations). Though it's been reviewed by a couple of people internally, I probably made some mistakes or left out some things that might cause a lookup to fail. See if you can catch my errors -- please post a comment in response to the Wiki document if you find anything.

(Or you could just edit the entry, I suppose. Earlier I was concerned that using the web rich text gadget on these would mess them up, but editing it with a Notes client doesn't really seem to be much better. I really have to talk to those people about that.)

I’ve been slammed!

Andre Guirard — Tue, 3 Feb 2009 06:00:00 -0500

I recently received a letter from the phone company ACN (link not provided because I don't want to raise their search ranking), welcoming me as a new customer. Only problem: I'd never heard of them. They had switched me from my previous phone service provider without my permission or knowledge, a practice known as "slamming." Many people in Minnesota are in the same situation (ACN tells me so themselves). Yes, it's very illegal. Yes, the FCC has strict rules about this. Yes, the Attorney General of the State of Minnesota will probably sue the pants off them.

I had to contact my previous provider and ask to have it switched back. That's no big deal, but apparently the slamming began with a faxed order form from one of their sales people (who had never had any contact with me) with my name hand-printed (not in cursive) on the line where I was supposed to sign. I'm not a legal expert, but that seems to me like a felony. It doesn't matter whether the forgery was done skillfully -- if someone writes something on the signature line, purporting to be the signature of someone other than themselves, and action takes place as a result, that's grounds for a long jail sentence. Yes, I definitely do intend to press charges.

If you search online for ACN, you'll find they're a "multi-level marketing organization". They have lots of "independent representatives" who have each paid in excess of $500 for the privilege of badgering their family and friends to sign up for phone service and to try to get them to become sub-representatives to themselves, like vampires with a head vampire. This gives ACN a large sales force of not overly intelligent people, who are strongly motivated to make back the money they wisely spent, which means signing up others in their circle of acquaintance. The desire to not have been the only one fooled, is probably not a factor.

One wonders what percentage of ACN's revenue comes from selling phone service, and what percent from the money people pay them for the privilege of working for them. My God, that sounds like something out of a fever dream. I want to run a company where people pay me to work for me! Except, of course, that I would be afraid of going to hell.

Do not call it a pyramid scheme. It's probably untrue that most people who sign up as reps end up losing money on the deal. And anyway it would be unfair to characterize it as a scam just because of that, even if it were true. Some reps buy Corvettes. Whoo! Corvettes! You just gotta get out there and hustle, as some responders to this thread point out.

I managed to get ACN to send me a copy of the faxed order (which is how I know about the printed "signature"). It came from an obviously fake fax number (555 exchange, like in the movies) and was page 18 of 35. One assumes if the forger wasn't bright enough to write something that at least looked like a signature on my form, they probably weren't bright enough to vary the handwriting or make something that looked like a real signature on any of the other forms. So I imagine the data entry person entering information from this fax, 35 consecutive pages containing obviously false signatures in the same handwriting, and do they say to themselves, "Hmm, don't these look fake?" Apparently not. But ACN's published policy is that (to prevent slamming) they'll reject any forms that look the least bit suspicious. Clearly it's not ACN's fault that this is happening, since their policy forbids it.

Of course, it's hard to get everyone in a big company to implement your corporate policies. Normally, you'd expect the data entry people to get a little slack. Unless, of course, there had been recent reports of slamming in a particular region. In such a case, since ACN is serious about preventing slamming, they probably alert all their folks to watch for suspicious looking orders from Minnesota, and remind them to look for them in general. Apparently, this has been going on in Minnesota for weeks (see http://www.cheezymovies.blogspot.com/, entry for 21 January 2009). But probably this is not enough time to send a memo to the data entry people. It takes time to compose such a memo, choosing your words carefully so that it will not be misunderstood.

Also, since this is a phone company, you would expect them to have the ability to use caller ID on their fax line. ACN could refuse blocked calls on that line, and log the caller IDs, which are really difficult to fake (unlike the originating number of a fax machine, which you can just program into the machine). That way, they could immediately track down which phone a phony order was faxed from, and find out who was doing it. Or failing that, at least to flag as suspicious all further orders faxed from the same line. But it looks like either nobody at ACN has thought of doing this, or the person who isn't bright enough to make a forged signature look like an actual signature, is bright enough to fax from a different phone each time. But I believe ACN is really taking a hard line against slamming. They clearly don't want anyone doing that. They just needed someone to suggest this sophisticated and non-obvious technique to them. Now that I have done so, I'm confident they'll implement it immediately.

NOTE: You may be wondering, "But wait! To get credit for the sale, doesn't the representative have to write their ID number on the form? What motivation would they have to write someone else's number there?" I wondered that too, but ACN tells me this is indeed what's happening. I would look first at the common head vampire of all the vampires whose ID numbers were on the fake orders, since they benefit from their minions' sales (and who else has access to those ID numbers?). This is fairly obvious, and nobody should expect to get away with it, but again, I don't think the MIT crowd sign up for this program.

ACN has been sued in one other state that I know of for slamming (I didn't search for other cases). In that case, they claimed that the representative who was forging orders was an independent contractor and that ACN was therefore not liable for their actions. I don't know how successful they were in making that case. However, after that lawsuit, they're doing everything in their power to prevent slamming. It says so right there in their policy.