Yellow is the New Blog

In response to: So Programming Language Really Does Matter

@Henning, in my opinion, IBM is absolutely running an experiment, but a rather clever one. The JSF specification is over 8 years old, and SSJS has been around even longer (Rhino, for example, was orginally created in 1997, and LiveWire was released in 1996), so the underlying technology isn't exactly new. On the other hand, in many ways, XPages have allowed Domino to leapfrog most of the web development platforms that are currently trendy... a phenomenon I honestly never thought I'd see.

I found this video about SSJS on the YUI Theater site intriguing:

http://developer.yahoo.com/yui/theater/video.php?v=isaac-ssjs

It's a short clip (at least compared to most on that site), but the implications are clear: platforms implementing SSJS are still considered leading edge, but there's strong momentum behind this, and over time, having a rock solid implementation is definitely going to be a strong selling point for any platform.

In case you're curious, Wikipedia has a listing of all known implementations of SSJS:
http://en.wikipedia.org/wiki/SSJS

...and yes, there's a glaring omission. :(

In response to: XPages - The Good, The Bad and the UGLY - II

I'm gonna have to disagree with both of you. JavaScript doesn't need classes because of closures... if you don't know what closures are, now would be an excellent time to find out. Nathan's spot on about Squawk: there's maybe a dozen lines of SSJS; and in every case it's just instantiating a Java object and calling a couple of its methods. But to be honest, all the apps I'm writing now include less and less custom Java classes because I'm sprinkling in calls to standard Java classes where I need them (same goes for @Functions, though that too is decreasing), and everything else is being handled in typical JS syntax. It's a very misunderstood language... far more powerful than its reputation (which is primarily the fault of lazy developers). Expect a followup post on my blog about what a JS "class" looks like. :)

If you follow Declan's blog, you already know that using the OneUI CSS template makes it even easier to rapidly give your XPages a pleasant user interface. Here's a quick tip for adding an interesting UI element to your pages that takes advantage of some of the OneUI behavior.

When you wrap any link in a span that has a style class of "lotusBtn", the link is rendered with a border and background graphic, so it looks like a button even though it's just a link. This is one approach for ensuring that an element intended to behave like a button (in other words, has an onClick event) will render similarly across all browsers. Since a section control, when rendered in a browser, is nothing more than just a link that uses client-side JavaScript to toggle the display of additional content, this allows us to render the section header such that it appears to be a button that, when clicked, displays the section contents. Since the entire section is wrapped in the "lotusBtn" span, which has a 1px border, the entire section has a border, but only the header has the background graphic... in other words, it looks like an inline dialog.

For example, if your XPage includes functionality for parsing RSS/Atom feeds and you want to allow the user to submit the URL of a feed they want to subscribe to, you might create a table for the URL field and corresponding label, and a button (or link styled as a button) for submitting the value. Here's how that would look if using this style technique.

Collapsed:

Expanded:

Note that in this case I'm using a custom image for both the expanded and collapsed state.

So the user clicks an element that looks like a button, which displays the additional detail inline instead of as a modal dialog or popup window. To enable this in your own XPage, select the section you want to render this way, switch to the Source tab and wrap the xp:section element in the following markup:

<xp:span styleClass="lotusBtn"><xp:section....</xp:section></xp:span>

One more quick customization to this technique: in addition to the "lotusBtn" class, you can add either "lotusBtnAction" or "lotusBtnSpecial". Instead of a silver background with blue text, the section header will have white text on a green background if using "lotusBtnAction", or blue if using "lotusBtnSpecial". So, for example, for a white-on-green button, the source would look like this:

<xp:span styleClass="lotusBtn lotusBtnAction"><xp:section....</xp:section></xp:span>

Click here to see an example of all three styles in action.

In response to: XPages... the Biggest Barrier

Unless you're nothing whatsoever like me, once you start actually developing XPages, you'll never want to write LotusScript again. I know that must sound crazy coming from me... until October I was a LotusScript fanatic. But trust me, SSJS is every bit as easy to write as LS (in my opinion, even easier, for several reasons), but WAY more powerful. I admit, thus far I've had the luxury of developing XPages for audiences primarily interested in a web interface. Additionally, nearly all of the XPage-based apps I've been building have been brand new applications. But on one recent project the client was rewriting an entire public-facing website from a LS-heavy version to an XPage version; much of the LS code that was still needed could be rewritten at a pace of 5-10 minutes per agent because the method syntax is so similar... but the majority of the code wasn't even needed anymore because it was reams of script just for rendering interface components that are now bundled controls in XPages.

There are ways to save yourself time now:

1. Use lower-camel-case. For example:

Set docSomething = vwSomething.getDocumentByKey("key", True)

When it comes time to rewrite that line of code in SSJS, all you have to do is delete "Set" and change "True" to "true" (and - optionally, but recommended - tack a ; onto the end of the line). LS won't let you change the case of a Boolean constant, but it doesn't care about case in method calls. So make your code more portable by using lower-camel.

2. Avoid extended class syntax for accessing item values. For example:

subject = docSomething.subject(0) 'original LotusScript

...becomes:

subject = docSomething.getItemValueString( "Subject" ); // SSJS equivalent

If your code is already:

subject = docSomething.getItemValue( "Subject" )(0)

...your code is more portable, because (like the previous example) there's simply less changes required.

In short, when there's something optional in one language that's required in another, it's generally a good idea to adopt that as a convention, because sooner or later you'll have a reason for using the other language... at which point either you're completely rewriting your code in a syntax that seems utterly foreign... or you're just tweaking code in a new but already familiar context.

I'm a big fan of XMarks, previously an extension for Firefox called Foxmarks for synchronizing bookmarks across multiple computers, now a cross-browser (IE and Safari, in addition to Firefox) extension that also allows synchronization of saved passwords... which is a handy feature, but I'm not too keen on storing all my site passwords on their server. While updating my preferences to disable that option, I stumbled upon a setting to "Use own server".

Intrigued, I clicked "Learn More", certain it'd be instructions for integrating it with PHP or Rails... but was pleasantly surprised to see that they support FTP but recommend WebDAV. Heck, I've had WebDAV set up on Ophelia for years. So I tossed a new database out there to store the XMarks data, and a couple minutes later had repointed the 3 laptops I use regularly to the Domino location. Works like a charm. Here's all you have to do:

1. Configure your Domino server to support WebDAV on for at least one DNS address.
2. Choose (or create) a database to store your data, and make sure it's set up correctly for WebDAV (allow design locking, No Access for Anonymous, Designer or above access for the account you'll authenticate as, maximum Internet access set to Designer)
3. In your XMarks settings, enable "Use own server", then specify the URL of a file resource (which doesn't need to exist in the database... it'll be created automatically) for each feature you want to use; for example:
http://dns/path.nsf$Files/xmarks.json
http://dns/path.nsf$Files/passwords.json
(where dns is the DNS address you configured to support WebDAV and path is the location of the database that will store the data)
NOTE: notice there's no slash between .nsf and $Files... while YMMV, I've found that including a slash confuses Domino. It tries to find a view called $Files instead of realizing you're trying to access the database via WebDAV.

That's it. That's all there is to it.

Weird... no code at all? Did I just submit an admin tip? Huh. Okay, then I'll end it with a development tease: I suspect if you replace the above URL syntax with URL's to agents/XPages/custom controls, you could do some crazy fun stuff with the posted JSON... but I'll leave that as an exercise for the reader ( <cough> dogear </cough> ).

Nathan posted an interesting insight into the current disparity between the targeting of end users in recent IBM product releases and the targeting of IT management in their marketing approach. In the comments, he refers to collaborative technology as "the great democratizer of the last decade", which got me thinking.

Here in the U.S., our system of government is a representative democracy. This is not a pure democracy in the etymological sense; if it were, it would collapse under its own weight... in a pure democracy, every decision must be approved by the masses and (one assumes) not much ever gets done. Rather, we are a republic: we elect a very tiny group (when one considers that the nation has several hundred million citizens) to make decisions on our behalf.

When those representatives are aware that their constituents are paying attention - most especially when it appears likely that those constituents are seriously considering replacing their representative with an alternative - it's not uncommon for their decisions to more closely reflect the "will of the people". In fact, it's extremely commonplace for an elected official's voting record to suddenly swing toward the center during an election year. That shouldn't be surprising: they're playing the odds; move toward whatever the center happens to be at the time, and you inch toward the magical 51% that lets you keep your job for a little while longer.

Trouble is, apart from the wonks, nobody knows you're moving toward the center... unless you tell them. President Obama was elected because his campaign was able to delude so many ordinary citizens into believing they could make a difference that the delusion became real. While plenty would dispute that the difference those people made was a good one, the assertion remains true: in our system of government, your voice will be heard if enough people are saying the same thing you are. That's why so-called "talking points" are so heavily used by both parties: standardize on the phrasing of the message you want heard, and the subtleties of any argument get drowned out by the bleating of so many supporters who haven't thoroughly examined the underlying implications... or, in some cases, even fact-checked the message.

What does any of that have to do with IBM? Imagine the following commercial:

(shot of smiling end-user in business casual attire)

"I love my email account at work, 'cause it's not just email."

(cut to a 25-second screencam of end-user doing end-userish things... specifically, tasks that can only be performed via the integration between email and business applications that Notes provides and that show off how pretty Notes is now)

"Our company uses Lotus Notes, so I can [description of the tasks shown in the screencam], not just send email and schedule meetings. It lets me edit documents, spreadsheets and presentations, send instant messages to colleagues and customers, and access all of the applications and websites I need to do my job. Lotus Notes really is all I need at work."

(cut back to smiling user)

"Can your email account do all that? If not, ask your boss why your company isn't using Lotus Notes..."

(user raises eyebrow meaningfully)

"... or using everything it can do."

(fade to IBM/Lotus logo, then to black)

Imagine if that commercial aired during American Idol, and the next day, every manager at some Exchange shop had 3 of his employees ask why they have to have 8 different Windows applications open just to do their job, when they could alternatively just use Notes. If that commercial kept airing (or others like it soon followed), each of those users would get increasingly annoyed each time they have to perform some occupational task requiring them to launch some application that exists solely for the purpose of performing that one tiny minute task. And maybe they'd complain to their boss again. And again. I guarantee you that, if managers really do get that kind of feedback from their staff, sooner or later IT is going to feel pressure to take a closer look at Notes, including the IT departments already running Notes but still supporting R4 'cause they haven't yet had either the courage or sufficient management backing to embrace the new millennium.

Last night I released a small but crucial update to DesignCatalog. It's hard for me to believe, but I've now been using this application (for all intents and purposes, in its current form) for nearly 6 years. And in all that time, I've never gotten burned by its reliance upon DXL. In other words, when using it to revert to a previous version of a design element, I've never ended up with a corrupted design element or even lost any code... at least, not that I noticed (i.e. nothing broke). Imagine my surprise, therefore, when I noticed that it wasn't storing the archived elements in note-format (/me looks sheepishly at the floor). I'm assuming that the reason I never got bitten by that before is that I primarily use it to archive versions of non-visual elements (specifically, agents and script libraries), and DXL is typically quite safe for those, even without using note-format. But it's a bit riskier for the other 1,500 of you who have downloaded DesignCatalog and may be using it for pages/forms/views, etc.

So version 1.2.2 is - aside from updating the About/Using docs to reflect the new release #/date - nothing more than remedying said oversight... an addition of 3 lines of code, to be precise. One of these days I'm going to update it to include some of the newer design elements (like Web Services and XPages), but in the meantime at least it'll now be round-trip safe for all the element categories it already supports.

I've occasionally mentioned the JavaScript concept of "closures", but recently it's come up in several conversations, so I wanted to revisit it in case any of you have been curious about what this is or why you should care.

Put simply, they're a complete departure from typical variable scope handling (unless you're used to Lisp or Perl). Consider, for example, the following LotusScript function:

Public Function getWidget (Byval widgetName As String) As Widget
 Dim localSomething As String
 Dim myWidget As New Widget(widgetName) 'Assume this class is defined elsewhere
 Let localSomething = "this is a pointless variable"
 Set getWidget = myWidget
End Function

Pretty straightforward: a new instance of some Widget class is constructed using the passed argument and returned from the function. A local String variable is declared and assigned a value, but it's completely unnecessary, because as soon as the function returns the new Widget object, any variables declared inside the function are garbage collected anyway. So if, for example, Widget contains a method that refers to the localSomething variable, that method will look for the variable within the class definition and, failing that, global variables... if none exists, expect an error.

Java adds another layer of garbage collection called block scope:

public Widget getWidget (String widgetName) {
 if (somethingIsTrue) { // assume a boolean defined elsewhere
  Widget myWidget = new Widget(widgetName);
 }
 return myWidget; // oops... NullPointerException
}

In this example, myWidget is actually local to the conditional (if) block: we can't refer to it outside of that block, because it's defined inside it. To refer to it after the block, we'd actually have to define it before the block, whether or not we plan to do anthing to it inside the block.

So what makes closures different? In JavaScript, an object returned from a function still has access to variables local to the function that returned it. "Whaaa?" Yes, the garbage collector knows not to destroy those variables until the object is destroyed, because it might want to refer to them later. For example:

var Widget = function(widgetName) {
 var localSomething = 'This may come in handy later.';
 return {
  displayLocal: function() {alert(localSomething);}
 };
};
new Widget().displayLocal(); // alerts the value of localSomething

In this case, an object is created that contains a single "public" method: displayLocal. This method can safely refer to the localSomething variable, because it's bound to that variable via closure. In essence, this allows JavaScript objects to contain "private" variables and methods: if we had defined any functions within the above function - but outside of the returned object - they could be called by the returned object... but not by other code outside of the function that contains them.

In other words, this allows JavaScript objects to be defined such that they behave more like class instances in other languages: they can contain public and private members. As such, in the above example, I "instantiate" a Widget via new... but worth mentioning is that I didn't need to: each time the above function is called, two new objects are created: a local String and an object containing a public method that can refer to that String even after the function that created both has returned. Hence, whether I include the new keyword or not, a new object with the same behavior template is created, and any locally defined objects bound to it by closure are new as well: a separate instance of localSomething is bound to each object created by calling this function. I tend to use new when calling functions that are structured this way to indicate (to myself and others maintaining my code) that the returned object behaves like a class instance, but the behavior is not dependent upon that convention.

One final syntactical nugget before discussing implications: tacking parentheses onto the example function's definition makes it behave something like a singleton:

var Widget = function(){
....
}();
Widget.displayLocal(); // we no longer need to call the function each time

In this case, the function is called immediately, so the variable Widget is assigned a pointer to the object that is returned from the function, not to the function itself. Widget IS the object. It has public methods bound to private data. For quite a while, I've preferred this approach to defining global singletons, because you don't have to call a function each time... you already have the object. But I'm finding that this tends to confuse people: they'll try to instantiate the object again, which causes the code to break, because Widget isn't a function, so treating it like a function returns an invalid result. In the end, of course, it's always best to keep global variables to a minimum; Yahoo recommends creating a single singleton that represents the entire application, and nesting objects appropriately within that space, and that's what I tend to do. This seems to mitigate the confusion, as most developers then grok that there's no need to construct new copies of the object; just "use" the object as constructed in-place, and customize it as needed.

So with all of that out of the way, why are closures actually useful? The same reason private members of a LotusScript class are useful:

• Internal storage of variables that cannot be mucked with from outside the object
• Minimizing global variables by associating groups of related data with a container object
• Probably most importantly, manageable code through proper decomposition without convolution of the public API

That last point probably bears repeating: as an object's complexity increases over the development (and enhancement) of the application or framework, you certainly could choose to make every method public. "Information hiding" (at least, in my experience) is more about shielding other programmers from the complexity of the code than it is about protecting the code from other programmers. When you're writing integration APIs (like a web service), of course, the latter factor increases, but the former is still crucial: imagine a WSDL that defined 237 service methods (and I assure you, they do exist)... it'd be a nightmare to keep track of what the service can be used for. Now imagine a complex web app that includes a JavaScript object with that many public members. It's highly likely that most of those members are for the internal convenience of the object itself, both to avoid duplicating the same code within multiple functions and to decompose the operation of each into tasks that are small enough to be easily understood. Closures allow for precisely that: decompose each function into smaller private functions, tuck away properties like internal counters that don't necessarily need to be publicly visible, therefore keeping the public API robust enough to meet the application's needs but simple enough to interact with and maintain.

Thanks to the wonderful browser manufacturers whom we web developers all love so dearly, we don't have to settle for buttons that look alike regardless of which browser our users are using. The variations are even fairly predictable: in IE, buttons are blocky and gray, Firefox tries to blend in with your operating system theme (unless overridden in an extension), and - like everything else Apple does - Safari's buttons are cute, shiny, and round. And what's that other one? I always forget.

But... if you want to be boring and ensure that your buttons look (nearly) identical - but still attractive - across all major browsers, and you happen to be developing in XPages, it's easy. Assuming you're using the button control (as opposed to input tags via passthru), switch to the "All Properties" section and, under the "basics" category, set the value of "dojoType" to "dijit.form.Button", and "dojoUsage" to "enable". The button will now be magically rendered as a dijit (yes, Domino handles the necessary require statements for you automatically), so it will look reasonably modern and consistent across browsers.

One of several new offerings Lotus 911 unveiled at Lotusphere was a new product called Crowded Wisdom. To quote our shiny new website:

Crowded Wisdom™ is Lotus 911's social idea management and business decision support solution. Featuring a sophisticated Web 2.0 interface, Crowded Wisdom allows employees, customers, vendors and partners to share ideas that can then be quickly and easily evaluated on multiple criteria by the defined community. Ideas can be contributed by anyone at any time, and become immediately available for other users to add to their personal Wishlist.

But the wisdom of crowds doesn't end there. Participants can organize their wishlists by ranking and rating ideas with simple drag & drop gestures. By sorting ideas in order of priority, users can express not simply that they like an idea, but where they rank it among other ideas they like. They can also rate ideas independent of their ranking, creating a deeper understanding of priorities and preferences.

Site administrators can group ideas together into Scorecards, which are then made available to crowd participants. Scorecards can be limited to a preset collection of ideas, or be open-ended. Once participants have submitted their scores, administrators can see rankings and ratings for all the ideas. Administrators can also assign weighting values to participants, which will differentiate their scoring, allowing key customers and users to have a stronger voice.

For example, imagine you are a major fast food chain and want to seek ideas from your customer base about what products or services to offer. You could start by having an open collection of ideas, letting people feed off of and rate each other's ideas, building a loyal community of interest. Then you can create a targeted Scorecard of the highest rated ideas that are actually feasible and publish that to the community to prioritize and rate ideas AGAINST each other, giving you valuable market intelligence about what changes you could make that would have the highest impact to your community. That is the power of Crowded Wisdom™.

The site then goes on to describe how much it would cost you (spoiler: surprisingly little) to run this in-house or hosted on our servers, but you can try it out for free and simultaneously improve BleedYellow by submitting suggestions - and adding suggestions from others to your wishlist - at http://wisdom.bleedyellow.com.

This post isn't specifically about my impressions of Lotusphere as much as it is about version 8.5 of Domino.

Imagine you're at a movie with a friend. It's well-written, well-acted, perhaps a little slow at the start, but intelligent, innovative, and just... well, different from all the crappy movies Hollywood is fond of making these days. The plot advances steadily, and as it builds to a thrilling climax... your friend gets up to leave.

"What? You're leaving now?"
"Yeah, the Jonas Brothers movie is about to start. I think I'll go see if it's any good."

Seriously, if you know anyone who uses Notes/Domino and they're even thinking of migrating to another platform, your response should be, "you're leaving now, are you crazy?" The 8.5 client has all the pretty of 8.0 with noticeably less overhead - and is solid on Mac and Linux (heck, they even ship both .RPM and .DEB installers... they're really getting the hang of this Linux thing lately) - Domino Designer is FINALLY based on a proper IDE framework, and XPages... oh my goodness, XPages. When I first heard about them, my reaction was, "hm, sounds interesting". When I actually started developing with them, my reaction rapidly changed to, "holy crap, this changes everything". I've spent a ridiculous amount of time on them since, and my excitement about them continues to grow.

Is DDE a bit buggy out of the gate? Of course it is. My biggest pet peeve at the moment is that on Vista (yes, I know, I should be using the version of Windows that came out around the same time as Notes/Domino 5, but the Thinkpad tablet I use at work has no optical drive, and I'm not sure I feel comfortable reimaging my work PC via a thumb drive like I routinely do with my personal laptops), drag-select is broken almost everywhere... I guess Cinderella was right: you don't know what you got 'till it's gone. But honestly, compared to the myriad of functionality they could have completely hosed while porting this beast, if that's the most glaring bug I've found so far, in my opinion they executed brilliantly. There's plenty more that can be done with it - OOB SVN support, for example - but that's the whole point: now that Designer uses Eclipse for its core engine, the extent to which it can be further extended is downright silly. I expect we'll be seeing some amazing changes to it in subsequent releases. The hard part's done... now the real fun begins.

Call me a fanboy if you like, but far more than any preceding release, 8.5 doesn't merely give me hope that the product will survive, it's reminded me of the thrill I felt when I first encountered it 11 years (and 14 days, but who's counting) ago. Abandoning this platform now would be an act of sheer madness.

One of the highlights of Lotusphere for me this year was presenting at the Speedgeeking event. I was asked to present on performance optimization of Domino applications through zero-index design... in other words, designing applications that contain NO views. As I mentioned during the presentation, this may seem antithetical, because if convention is any indication, a Domino application is required to contain at least 300 views in order to be of any use. Trouble is, views are expensive: the more you add, the slower the application becomes; in fact, an entire server's performance can be degraded by the number and complexity of the views in the applications the server hosts. Zero-index NSF design, then, is structuring applications such that we can take advantage of the knowledge that a document's UNID is read-write.

As promised (to those who attended... and a few who didn't), the slides (both of them, in fact) and example database have now been posted.

By the way, if you've guessed that this approach has something to do with why nearly everything in Squawk ignores indexes entirely (and if you haven't seen it since we first announced it, you might want to take another look), you'd be right... though I'm not allowed to say much more than that, of course...

IBM did something rather cool this year in connection to the BOF sessions at Lotusphere: they created a LotusLive group associated with each, which includes a discussion forum allowing the BOF to continue in virtual mode indefinitely. If you're a DXL fan - or would like to be but don't quite trust it yet - please join the DXL in the Wild group.

Urs Meli asked if there's a list of known bugs, missing features and workarounds. I started a thread in the group discussion forum in the hopes of consolidating such a list. As time permits, I'll be adding the items I'm already aware of as responses to that thread; if you have any to add, please drop by and post them.

In response to: DXL Erros

Urs, I'm not aware of any consolidated list of known bugs, so I created a discussion topic on LotusLive within the "DXL in the Wild" group associated with the BOF I co-moderated with Mac Guidera: https://apps.lotuslive.com/contacts/groupprofiles/groupForum/18083 As time permits, I'll post to that thread a list of the issues Lotus 911 has become aware of in our use of DXL. In the meantime, remember that setting the ForceNoteFormat property to True when exporting gives you the raw format, which is "round-trip" safe; in other words, although the output for most design element types is impossible to parse, it at least allows note archival and restoral without any loss of fidelity.

After months of living in the source pane of various XPages (drag-n-drop is intended to ease development, but for some reason I find it's still faster to just edit the source XML directly), riding the bleeding edge of the latest (and, yes, greatest) release of Domino, it was fun to briefly return to my roots tonight.

I'm not much for slides (even in Symphony), so for my Speedgeeking session, I decided I'd rather just show y'all an example database... live demo, baby. Don't worry, it'll run just fine locally if need be. As I was coding it tonight, I made a very deliberate design decision: other than a sprinkling of necessary LotusScript, all the code in the demo is our old friend, Notes Formula. No Java, no JavaScript, no XML... in fact, everything in there has been available to us since 6.0. And if you're still running version 5, (6 years and 5 major releases later), we would be happy to lend a helping hand in getting you upgraded. The point is that Formula can still do extremely useful things. It's nowhere near as powerful as SSJS, of course, but I can create a full-blown CRM (with multiple sort options for contacts despite not having created a single view) from scratch in a couple hours using a few lines of a scripting language that is almost identical to VB3 and a 19-year old macro language. In what other development platform would that be possible?