Domino Upgrade

VersionSupport end
Upgrade to 9.x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet.
Contemplating to replace Notes? You have to read this! (also available on Slideshare)


Other languages on request.


Useful Tools

Get Firefox
Use OpenDNS
The support for Windows XP has come to an end . Time to consider an alternative to move on.

About Me

I am the "IBM Collaboration & Productivity Advisor" for IBM Asia Pacific. I'm based in Singapore.
Reach out to me via:
Follow notessensei on Twitter
Amazon Store
Amazon Kindle
NotesSensei's Spreadshirt shop
profile for stwissel on Stack Exchange, a network of free, community-driven Q&A sites


Designing a Web Frontend Development Workflow

In the the web 'you can do anything' extends to how you develop too. With every possible path open, most developers, me included, lack direction - at least initially. To bring order to the mess I will document considerations and approaches to design a development workflow that makes sense. It will be opinionated, with probably changing opinions along the way.
Firstly I will outline design goals, then tools at hand to finally propose a solution approach.

Design Goals

With the outcome in mind it becomes easier to discover the steps. The design golas don't have equal weight and depending on your preferences you might add or remove some of them
  1. Designed for the professional
    The flow needs to make life easier when you know what you are doing. It doesn't need to try to hide any complexity away. It shall take the dull parts away from the developer, so (s)he can focus on functionality and code
  2. Easy to get started
    Some scaffolding shall allow the developer to have an instant framework in place that can be modified, adjusted and extended. That might be a scaffolding tool, a clonable project or a zip file
  3. Convention over configuration
    A team member or a new maintainer needs to be able to switch between different projects and 'feel at home' in all of them. This requires (directory) structures, procedural steps and conventions to be universal. A simple example: how do you start your application locally? Will it be npm start or gulp serve or grunt serve or nodemon or ?
  4. Suitable for team development
    Both the product code and the build script need to be modular. When one developer is adding a route and the needed functionality for module A, it must not conflict with code another developer writes for module B. This rules out central routing files, manual addition of css and js files
  5. Structured by function, not code type
    A lot of the example out there put templates in on directory, controllers in another and directives yet into another. A better way is to group them by module, so files live together in a single location (Strongly influenced by a style guide)
  6. Suitable for build automation
    Strongly influenced by Bluemix Build & Deploy I grew fond of: check in code into the respective branch (using git-flow) and magically the running version appears on the dev, uat or production site. When using a Jenkins based approach that means that the build script needs to be self contained (short of having to install node/npm) and can't rely on tools in the global path
  7. React to changes
    A no-brainer: when editing a file, be it in an editor or an ide, the browser needs to reload the UI. Depending on the file (e.g. less or typescript) a compile step needs to happen. Bonus track: newly appearing files are handled too
  8. One touch extensibility
    When creating a new module or adding a new dependency there must not be a need of a "secondary" action like adding the JS or CSS definition to the index.html or manually adding a central route file to make that known
  9. Testable
    The build flow needs to have provisions to run unit tests, integration tests, code coverage reports, cshint, jslint, trace-analysis etc. Code that "oh it does work" isn't enough. Code needs to pass tests and style conventions. The tests need to be able to run in the build automation too
  10. Extensible and maintainable
    Basing a workflow on a looooong build script turns easily into a maintenance task from hell. A collection of chainable tasks/modules/files can keep that in check
  11. Minimalistic (on the output)
    Keep the network out of the user experience. A good workflow minimizes both the number of calls as well as the size of http transmission. While in development all modules need to be nicely separated, in production I want as little as possible css, html and js files. So once the UI is loaded any calls on the network are limited to application data and not application logic or layout
A very good starting point is John Papa's Yeoman generator HotTowel. It's not perfect: the layout overwrites the index.html on each new dependency/module violating goal #4 and it depends on outdated gulp modules - goal #10 (I had some fun when I tried to swap gulp-minify-css, as recommended, for gulp-cssnano and thereafter font-awesome wouldn't load since the minified css had a line comment in front of the font definition). I also don't specifically like/care (for my use case) to have the server component in the project. I usually keep them separate and just proxy my preview to my server project.

Tools at hand

There are quite some candidates: gulp, grunt, bower, bigrig, postman, yeoman, browserify, Webpack, Testling and many others. Some advocate npm scripts to be sufficient.
In a nutshell: there are plenty of options.
One interesting finding: Sam Saccone did research what overhead es6 a.k.a es2015 has over current es5. TypeScript (using browserify) performed quite well. This makes it a clear candidate, especially when looking at AngularJS 2
Next up: Baby steps


Let there be a light - Angular, nodeRED and Websockets

NodeRED has conquered a place in my permanent toolbox. I run an instance in Bluemix, on my local machine and on a Raspberry PI. I build a little demo where a light connected to a Particle lights up based on an event reaching a NodeRED instance. However I don't carry my IoT gear every time (got lots of funny looks at airport security for it), but I still want to demo the app. The NodeRED side is easy. I just added a websocket output node and the server side is ready to roll.
Web socket in NodeRED
On the browser side I decided to use angular.js and one of its web socket libraries ng-websocket. The application code is just about 50 lines, so here it goes:
'use strict';

var websocketEndpoint = 'wss://'+window.location.hostname+'/ws/bulb';

console.log('Application loading ...');
// Declare app level module which depends on views, and components
var myApp = angular.module('myApp', ['ngWebsocket','ngRoute']);

myApp.config(['$routeProvider', function($routeProvider) {
    console.log('Routes loading... ');
    $routeProvider.when('/bulbon', {
        templateUrl: 'bulbs/bulb-on.html'
    }).when('/bulboff', {
        templateUrl: 'bulbs/bulb-off.html'
    }).when('/bulbunknown', {
        templateUrl: 'bulbs/bulb-unknown.html'
    }).otherwise({redirectTo: '/bulbunknown'});
}]); ($websocket, $location) {
    var ws = $websocket.$new({
        url: websocketEndpoint,
        reconnect: true
    }); // instance of ngWebsocket, handled by $websocket service

    ws.$on('$open', function () {
        console.log('Websocket connection open');

    ws.$on('$message', function (data) {
        console.log('data arrived');
        var newlocation = '#/bulbunknown';
        if (data.bulb === 1) {
            newlocation = '#/bulbon';
        } else if (data.bulb === 0) {
            newlocation = '#/bulboff';

        window.location = newlocation;

    ws.$on('$close', function () {
        console.log('Websocket connection closed');


The HTML is simple. I split it into the main file and 3 status files. One could easily put the statuses into a script template section or inside the app.


Put an angular face on your inbox

In the last instalment I got vert.x to emit a Notes view, read from your local mail file, to be emitted as JSON stream. While that might be perfectly fine for the inner geek, normal mortals want to look (and interact) with something more pretty.
The cool kids on the block for web interfaces and applications are Twitter BootStrap and AngularJS, so these will be the tools in this instalment.
Not familiar with them? Go and watch some videos. Back? Let's get going.
Since I'm not much of a designer, I choose the ready made Admin LTE template based on bootstrap. The main reason for choosing this one, was a timeline layout that I wanted for the inbox.
My inbox is already sorted by date, so it should fit nicely (so I thought). However the view optically is categorized by date and under the hood just a flat list of <li> elements. A little tweaking was necessary. The result looks quite OK for an after hour exercise:
Alternate layout for the Inbox
The steps to get there:
  1. Tweak the vert.x service to render a categorized by date version of the inbox. You can do that without touching the underlying view. I'll provide details on that modules in a later article (and some sample data below). The main difference for now: the inbox data will be available at the URL /notes/categorized/($Inbox)
  2. Create templates and directives for Angular
  3. Create the Angular.js app and its Controllers
Of course, no application is complete with a nice set of challenges. The biggest here was the flat list for the time line. I tried to adjust the CSS to accommodate a hierarchical list, where the outer elements are the date containing all messages arrived at that day, but there was too much CSS. So I decided to tweak the output a little.


This site is in no way affiliated, endorsed, sanctioned, supported, nor enlightened by Lotus Software nor IBM Corporation. I may be an employee, but the opinions, theories, facts, etc. presented here are my own and are in now way given in any official capacity. In short, these are my words and this is my site, not IBM's - and don't even begin to think otherwise. (Disclaimer shamelessly plugged from Rocky Oliver)
© 2003 - 2017 Stephan H. Wissel - some rights reserved as listed here: Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution/NonCommercial/ShareAlike Creative Commons License, with the exception that no rights are granted -- since they are not mine to grant -- in any logo, graphic design, trademarks or trade names of any type. Code samples and code downloads on this site are, unless otherwise labeled, made available under an Apache 2.0 license. Other license models are available on written request and written confirmation.