The new social media tools are going to have as much of an impact as Notes did in its day, according to Laube. The problem, he said, is that they aren’t oriented toward accomplishing particular tasks, other than staying in touch with your friends and colleagues. “It is easy to miss particular things in your news feed in Facebook, but in a business context that isn’t okay at all,” he said.

Give the article a read, and more importantly listen to the accompanying podcast: Laube raises some good points (he even mentions the dreaded performance review!)

ReadWrite Enterprise: How Lotus Notes Changed the Collaboration Landscape.

The dutiful developer performs a “compile all” in their database, and is shocked to see a whole load of Lotusscript Error - Syntax Error reports in the compiler window. Whilst the compiler is probably pointing to a load of forms in one’s app (yeah, that’s helpful), the issue is actually with the shared action design element. You know, that bastard anomaly of a design note in Designer, whereby things that look like multiple design elements (shared action buttons)… aren’t (I hates it so I does, hates the shared actions element. Can you tell?)

I encountered this very issue earlier this week in a Notes client application I was performing some maintenance on, and it took me a while to track down. The offending action scripts were referencing some files that must have been stored on the previous developer’s machine, and Designer was not happy at all. As I found to my cost, Option Declare will not fix this issue. Nor will editing and re-saving the offending elements. One has no choice but to go through the code, find the errors and resolve them. The compiler gives little, if any, assistance at this stage.

My solution—which to my mind makes for far better coding practice anyway—is to rip out all the Lotusscript from such shared actions, and stick these routines in a separate library. You then reference these routines from the shared action buttons, and we never talk of this again. Moving the code solves a few things in one fell swoop:

1. Shared actions are all stored in one note in the NSF. If this note corrupts (and they do), you lose all that code
2. Storing all significant Lotusscript in one part of the application design (i.e. in script libraries) makes far more sense from a maintenance point of view
3. When editing Lotusscript in a script library, the compiler behaves itself and tells you about any problems. In shared actions, you’ll be lucky

So what do you know. 2011, and I’m still doing the odd Lotusscript tip… ;-)

Some of us have been clamouring for Domino Designer back on the Mac since it was pulled in release five. The Mac OS landscape (and mindshare of course) has changed dramatically since the R5 days, and then IBM came along and added fuel to the fire by using Eclipse as the base for new versions of Designer.

Fire? How so? I hear you ask… Well, inadvertently or not, in using Eclipse for your IDE you’re screaming that your environment will work on more than a Windows box. In the heady days of dreamy possibility represented by Hannover, one of the vaunted plus points for using Eclipse was its expandability, but also the fact that Eclipse is cross-platform.

Sooner or later, if Notes apps are to continue, the aged Windows-based C code underlying the standard Notes client has to be re-written, and then DDE has the wherewithal to become a true cross-platform Eclipse-based IDE of some heft.

But that won’t happen. Why? XPages. Drop the Notes cruft, go with the JSF-based XPages platform. If you have that, and only that, for your Domino apps, you stand a fighting chance of getting a cross-platform IDE^*. Until then, you’re pissing in the wind.

Let me be clear: I don’t mean this as a criticism (which may surprise some readers given my long-standing fondness for Macs). IBM have to pick their battles, and funds have to be apportioned: they’re not going to spend $$$ making layout regions work in Designer on Ubuntu.

^* that said, I still wouldn’t hold your breath if I were you. The Rational / Websphere tooling doesn’t have all this cruft, and that doesn’t work on OS X either.

James Governor, Lotus Gears Up To Embrace The Web, Rebuild its Developer Story, pwn Social Business.

The developer’s lot, when it comes to Lotus, is something a lot of us take an interest in, given the relative diminution of the Notes and Domino platform. Rather than just reading about it, it’s my hope that a lot of us will get to participate, now that the public announcement of Project Vulcan is getting pretty long in the tooth (in internet years :-)).

Governor lists a number of burgeoning technologies that make up this new approach for IBM Lotus, and it’s all good stuff. He is most definitely on the same page when he says this (my emphasis):

In the meantime, Rational has sucked all of the air supply of the room when it comes to talking about developer tooling and methods, which is a problem for SWG as a whole. Got a question for an IBM group about software development and they’re pointing you Rational’s way before they even hear what you have to say. Rational is really a business application rather than a developer tool. Developers don’t choose Rational—bosses do. Rational talks to heavyweight styles of development, such as embedded computing, where failure is not an option, and large scale global distributed software development (the kind of thing IBM is pretty much the only company in the world to do effectively. fwiw).

So you can imagine I was pleased to see a classic consultant slide from Lotus GM Alistair Rennie with a quadrant labeled Developer. Not a moment to soon. IBM needs to dramatically accelerate its attraction to Web developers—and Rational is the wrong tool for the job.

There is just one thing missing for me: APIs. Yep, pesky ole’ interfaces, the Achilles heel of the more traditional Lotus development world.

So, if you’re attending Lotusphere, find out what the future holds for us developers, and report back!

(Hat-tip to Stuart McIntyre at Collaboration Matters for the link).

A customer with tens of thousands of seats will always be able to call up their Lotus contact and have more influence than someone posting an idea on the web.

He is spot-on. And for me, therein lies the rub: this is why Notes is in the mess it is today. Oh, and another thought: if John’s assertion is true, why bother with “Ask the Product Managers” at all?

Peter Presnell, Ask The Product Manager: Making It Work.

Update: if you attend, be sure to have your bingo cards at the ready!

Anyway, on to the good ’n’ bad:

@Formula-style server-side Javascript

This rocks. I like very much. If you know the Domino Java API or the Lotusscript object model, then you will pick up XPages’ SSJS object model and syntax very quickly. Code migration should be relatively painless too, if that’s what you want

Pretty much everything is computable

It was always a frustration from Notes 5 on that not all things in Notes could be calculated at run-time. Some stuff just had to be hard-coded. Not any more! Just about everything has that magic blue caret that lets you use code to set values. Hurrah!

java.lang.IllegalArgument

This bloody error comes up way too much in Domino Designer (closing and re-opening DDE seems to sort it). And it means very little. The user is urged to examine his or her workspace logs, but they rarely shed any light. If the user can’t do anything about the error being presented, then they shouldn’t be seeing it, as far as I’m concerned.

CLFAD0221E and CLFAD0246E JVM errors resulting in HTTP 500 for users

These are the run-time errors I have really grown to hate. Underlying them is a NullPointerException in the low-level XPages servlet engine. They crop up when previewing XPages in 8.5.2, and I gather the issue is fixed in fix-pack 1. It’s a nasty regression, and renders certain types of XPages useless. I don’t know a full set of steps to reproduce, but in my case I am using an XPage in “headless“ or “agent” mode, whereby some SSJS is used to spit out a stream of XML. Other developers have reported issues with POST requests in web pages, especially when using rich text and file upload controls. YMMV. For me, the work-around is to code on the server (running 8.5.1) or to down-grade DDE to 8.5.1. Alternatively, you could try the tips outlined in this Lotus Developer Domain thread).

So, overall I would say that DDE is a solid start. Lots more work for all of us though!

Update, 17 December 2010: 8.5.2 FP1 has been released, and amongst other things the JVM / HTTP error 500 issue above is fixed (SPR is PHAN89ZB5T):

If a network read error occurs during an http post, the initialization of internal java objects does not complete and a java thread local is not set/reset correctly. This causes all subsequent xpage requests that are processed by that thread to fail and return an http error 500 to the client. Code was added to detect this case and reset the thread local so that subsequent xpages requests do not fail. This regression was introduced in 8.5.2.

Good news!

Inevitably, in the process, I ballsed up my comments form. Dear oh dear. Anyway, should be fixed now, and on the plus side I’ve updated some nasty old crufty Javascript with newer, cleaner implementations. Sorry about that (and many thanks to Bruce and the Wookiee for their assistance).

1. It’s coded in IBM Lotus Domino! Domino is a cracking platform for small ad hoc content management systems (CMS), and if you already have the infrastructure, why not use it?
2. It’s not hosted on a normal Domino box. It’s in the cloud baby!—Amazon Web Services to be exact
3. There are some CSS3 goodies in there, including @media directives for mobile browser splendiferousness

At LDC Towers we have our own Domino and Java server infrastructure, but we wanted to try something new, and kick the tyres with Amazon Web Services—by far the most mature and interesting cloud environment out there, as far as we’re concerned. Our experiences to date have been extremely positive, and the site is performing well thus far.

With regards the whole web-thing, there are wee bits of Javascript and CSS3 jiggery-pokery going on in the site (most evident in the portfolio page). It displays in Internet Explorer OK, but it really shines in modern Webkit- and Gecko-based browsers like Firefox, Chrome and Safari. You will also get an optimised version of the site if you browse it on an iPhone or similar device. As already intimated, we are using them thar funky media queries to render the most appropriate look for you, and we include a touch icon for iPhone home screens too.

If you want to know more about some of the stylesheet shenanigans at play, by all means drop me a line and I will knock up some techie posts here. In the meantime, take a look around.