Beyond The Yellow Bubble

I find new experiences are often the greatest source for innovation in my work.  This proved to be the case for me several years ago when I left my role as a Lotus Notes Developer to take on a role that involved using C# and ASP.Net.  When I returned to Notes development I found myself wanting to take many of the great things I had experienced with .Net development and apply them to Notes development.  This gave rise to me becoming an Object Oriented Programmer and also lead to me developing the .Domino Framework.  Version 1.0 of the .Domino Framework (available on openNTF) was my way of of taking many of the cool things I had found in the .Net framework, combining them with what I was now seeing with Notes 8.0, and delivering them using the Notes 6.0 technology I was being asked to use in my work.
.
I am now working on .Domino Framework 2.0. This new framework will be built from the ground up to overcome some of the complexities and limitations found in the original framework.  The inspiration for this new framework is coming from the time I spent late last year using Notes 8.5, XPages, and JavaScript (including SSJS) and what I saw at Lotusphere with Project Vulcan.  Is there a need for such a framework?  Well I believe so.  So far this year my own projects have been almost exclusively Classic Notes.  Unlike the world of many business partners, there is simply no demand at this time for me to develop XPage applications.  Also.... I also only have one month left on one of my current contract so I have been paying much closer attention to the Notes Job market.  What I have found interesting is that there is no signs of any significant demand (if any) for Notes developers with XPages experience.  It seems to me that the same skills of Notes Classic, LotusScript, LEI etc are the skills being sought for most of the current positions.  So after escaping the hype of #ls10 I am beginning to suspect that a very high proportion of Notes development in my part of the world will continue to be done using LotusScript.  My first goal for 2010 is therefore to find ways to add the power of JavaScript to the LotusScript language.   (And maybe even explore ways in which some of the concepts demonstrated for Project Vulcan can be implemented using Notes Classic.)  IBM stopped investing in LotusScript after Notes 6, but that doesn't mean the language should/need die.  It never ceases to amaze me just how flexible LotusScript and Notes Classic are as a development environment.
.
As an example.  LotusScript does not provide an extensive set of operations that can be performed on arrays.  So I have developed a new DominoArray class as part of the core of the .Domino Framework 2.0.  This class add properties and methods that are found in @Formulae, JavaScript, and Java that were never added to LotusScript.  Being a class it is now also possible to exhibit some of the capabilities and styles JavaScript provides with its own data types being implemented as customizable Objects.  The DominoArray class provides a length property (as provided in JavaScript and @Elements).  A number of methods have been implemented such as push(), pop(), slice(), splice(), reverse(), toString(), sort(), contains() (@Contains), keword (@Keywords), and subset (@Subset).  Using the DominoFramework 2.0 it becomes possible to write code that looks remarkably like some of the JavaScript code I had started to write last year.  e.g.

Call MyArray.Push(NewValue)
If (MyArray.Length > 3) Then Print MyArray.Splice(1,3).Sort().toString()

Another example is the Math object that is provided by JavaScript.   To reproduce this in LotusScript I have defined a DominoMath class as a container for all those special mathematical operations and constants not built into LotusScript.  By defining a global variable Math, which instantiate an instance of DominoMath, it becomes possible to write LotusScript code that looks very much like JavaScript.  e.g.

myBigVar = Math.Max(A,B)
myColor = Math.HexToDecimal(HexValue)

If there was one message I could leave for the still many Lotus Notes developers not yet doing projects with XPages, Vulcan etc....   It doesn't matter if you are still using Lotus Notes R5 or that Notes 8.5.1+ may still be several years away.  Nor does it matter if you have little or no access to Lotus products such as Connections, Quickr, or LotusLive.  Try and at least take a close look at what all these products offer.  And then go back to your own environment and think about how you can implement some of the cool features these other products provide.  With any version of Lotus Notes from R5 onwards you have the most powerful, flexible, and adaptive product in the Lotus family.  All that is required is a little inspiration and some cool LotusScript code.  (or of course you could wait for the .Domino Framework 2.0 to become available).

I recently wrote about some of the things that could be done to minimize the differences between writing LotusScript and JavaScript code.  These technique hopefully can help reduce the number of mistakes made in writing code when switching between languages - a fact of life for Notes 8.5.1 developers who develop both Notes Classic and XPage applications.  Having written LotusScript code for over 13 years I still find myself making some dumb mistakes over and over each and every time I write JavaScript/SSJS code.  Here are my top 10 mistakes:-

10) The first "S" in SSJS stands for "Server".  I have to stop designing solutions that run solely on the client and devise strategies that work when the server code is isolated from the user.

9) Forgetting that because of the flexibility of the language is so great, the SSJS editor will not find most of my dumb mistakes for me when I compile my code.

8) Forgetting that if I use == for a logical comparison that JavaScript will automatically convert both sides of the comparison to the same data type (usually string).  So if I don't want the number 1 to be the same as the string "1" I need to use ===.

7) Remembering to add () at the end of each method call to get the value returned by the method rather than a pointer to the method itself

6) Understanding the differences between how an array operates versus a vector

5) Remembering that a switch statement needs a break statement to be added ton stop the code falling into my next case.

4) Handling the subtle differences between a variable who's value is undefined versus a null value and and am empty string

3)  Forgetting the difference between an assignment statement (=) and an equality comparison (==)

2) Getting the case of my statements correct (e.g. if statement is all lowercase but Array is proper case),and all my variable names etc correct.

And the number one mistake I keep making is.....
1) When I think I need assistance in how to use a particular SSJS statement or the various SSJS classes I keep thinking I can find useful information in the new Eclipse online help!  (duh)

 I'm not one to either read a lot of books or blog book reviews but this is one of the best technical books I have read for a while (Are there any other types of books?).

Object-Oriented JavaScript by Stoyan Stefanov provides an excellent coverage of JavaScript from an Object-Oriented perspective.  It starts with a great coverage of JavaScript itself before it goes into details about the inner workings of functions, object and the Prototype statement.  The book is targeted at client-sided JavaScript but the majority of the book is equally applicable to Server Sided JavaScript (SSJS).  I have a few other books on JavaScript from my tome doing .Net development but I would highly recommend this book to anyone looking to transition from LotusScript to JavaScript, and especially those of you that wrote classes in LotusScript and want to know how the JavaScript equivalent (Objects) work.

This may be just Kindergarten but our teacher gave us a pretty lengthy required reading list to work on now and for later when we continue on to first grade..  Apparently those of us intending to focus on developing XPages for the Notes client when 8.5.1 is release have been instructed to use the same reading list until we are told to do otherwise...  Those people who have already done a lot of Web development will probably have a lot of these already.  Notes client developers have a LOT of reading to do...

Kindergarten

1. HTML - XPages provides a number of great controls but there is still a lot missing.  Those gaps will often be plugged with you own HTML.  When debugging XPage output it will be essential to be able to read HTML.  A book that explains the differences in the way modern browsers interpret HTML would be especially useful.  There are many on-line resources that can also be used.
   
2. JavaScript - The native JavaScript language is used extensively to script client events.  This same language also provides the basic syntax for server sided JavaScript (SSJS).  Most of your code is going to be JavaScript based, so a mastery of this language is required.
   
3. Dojo - Dojo is the javascript library (framework) that comes with Domino 8.5 and is used as part of XPages.  Dojo extends the capabilities of JavaScript as a language as well as providing a range of widgets (dijits) that can add even more WOW to your XPage applications.  Unfortunately IBM provide very little documentation about Dojo in the Domino Designer help so a reference book is almost essential to get the most out of this technology.
   
4. CSS - Styling of your applications should largely be achieved through CSS.  This language is an art in itself and something each Notes developer needs to develop a thorough understanding if they wish to make their XPage applications attractive and reduce some of the cross-browser issues.  A text that also explains themes would be beneficial as themes are also supported by XPages.
   
5. Xpages - Only joking!  There are no books to be found on XPages.  The oinline help that comes with Domino Designer will leave you underwelmed.  There are a lot of blogs that give very good coverage on your options for Xpages.  These include Declans life, the universe,and everything Xpage tutorial, The Domino Developers wiki, theXpages wiki, and the Xpages Blog.  And don't miss David Leedy's great Notes At Nine videos.  Lets just hope a book gets written soon as this topic is very large and it is impossible to see have its millions of components can be coeverded in depth by anything less than a 500 Kg reference book.
6. SSJS - I have no idea where you may go to get a good understanding about SSJS.  A good knowledge of JavaScript is a start as well as a good working knowledge of Commands and either the COM or LotusScript product classes (NotesDocument etc).  Tim Tripcony as Lotus911 seems to know about as much about SSJS as anyone, so watch his blog closely for tips etc.
   

1st Grade

1. AJAX: XPages makes use of XJAX technology to facilitate asynchronous calls to the server for things such as partial refreshes.  In your 2nd year of XPage applications you may want to build a better understanding of AJAX to embark on bullding more advanced controls and functionality.
   
2. XML A some stage soon after graduating from kindergarten you are likely to be building applications in which data will be passed between data using XML.  A good working knowledge of XML and related technologies such as XPath and XSLT will be helpful.  Remember, at some stage soon XPages will probably allow you to define data sources that draw data from XML files directly.
   
3. JAVA: It seems to me that every time you have to dive off and do anything advanced with SSJS you end up making calls to Java or using instructions that look a lot like Java.  Having a good working knowledge of Java is going to help you out.  e.g. The process of invoking a Web service seems to rely on using some Java-specific components.
   

Note: No specific text books were prescribed.  It was suggested we use Amazon or similar resources to find popular texts.  In time I may get more specific about resources you may want to consider.  For now just find a reasonably good text on each subject.  Readers please feel free to comment on good choices that are above the pack or especially relevant to Notes/Domino...

For Dojo I can recommend the book - Dojo - The Definitive Guide by Matthew Russell (O'Reilly)

Happy Reading everyone....

Application Development has been essential to the survival and growth of the Notes client.  Prior to Notes 8 its was generally felt (and argued loudly at lotusnotessucks) that the Notes client was a vastly inferior offering to MS Outlook.  Despite this Notes held on and appears to be now gaining market share on Outlook.  This was due in no small part  to the inability of Microsoft to provide an alternative to Notes as a RAD tool for applications.  Microsoft also had Visual Basic and the .Net programming languages but still they couldn't win.

With the release of Notes 8.5 and the introduction of XPages, a new discussion has started within the yellowverse about programming languages.   XPages introduces a new offering in Server-Sided Javascript (SSJS) a new language with a syntax similar to JavaScript but also containing references to the @Formula language and the Product classes commonly used within LotusScript (e.g. NotesDatabase and NotesDocument).  As to be expected people are somewhat divided.  Not surprising given the programming world as a whole has never adopted any one single programming language.  The science of programming languages are continuing to evolve.  Object Oriented programming languages such as Java and the .Net family have been very popular of late and probably are still the #1 and #2 languages.  O'Reilly published an article based upon technical book sales which seems to show C# rising and Java falling   PHP and Python are popular in Web development but these no longer seem to be gaining ground.  C/C++, upon which Notes was originally built, is also losing ground.  Ruby is one of the more modern programming languages that are starting to gain ground.  It also appears that JavaScript is gaining in popularity.  Both Ruby and JavaScript support dynamic data types, a feature being seen as superior to strongly typed languages such as Java and C#.  The growth in popularity of JavaScript may be a good sign for the future adoption and success of SSJS.

And so what about LotusScript?  Well LotusScript I liken to Visual Basic and VB.Net.  Not just because they are BASIC-based programming languages but also because they tend to attract people who could be considered "less sophisticated"programmers.  This is an important group to Notes development because they are responsible for putting so many Notes applications on our Domino servers so quickly making it almost impossible for IT department to replace.   Are these people likely to move to Java? - I doubt it, to SSJS? (well maybe) or stick to LotusScript like they did when we were first offered Workplace? (also possible).  Part of that decision is tied to the design elements that also go into creating a Notes Application.  As things stand at the moment with 8.5.0 there is no doubt in my mind that the novice and intermediate Notes developer will produce a Notes application much faster using Forms, Views, Framesets, Outlines, Pages, and Agents.  An advanced programmer will develop a superior Domino Web application using XPages.  Will they be as productive? (apart from Tim Tripcony -  I am not so sure)  And 8.5.1 does bring XPages to the Notes client....  I posted an idea on ideajam suggesting IBM follow the strategy I believe they may already be following, which is focus all future effort on developing SSJS and retire LotusScript.  Hardly scientific but it didn't exactly receive overwhelming support.  Based upon this and many discussions and discussion threads I have to believe the Notes world is divided. 

I have long lamented the lack of support for LotusScript over the years.  But most of all I would love to see a single programming language I can use everywhere within Notes.  One that allows me to do OOP and one that allows me to be productive.  Has IBM made things better now we have SSJS?  We have @language that was the first language that can only be used in some places but is still the only choice for things like view selections formulae,  field validation on forms etc.  LotusScript is probably the most universaly adopted but not supported on client sided Web applications or within XPages.  Java is still limited where it can be used and has never gained wide-spread adoption.  JavaScript is used with client sided Web applications (including XPages) but is only  of limited value for traditional Note client applications.  And now SSJS which is presently only available for server sided XPages scripts.  That's a pretty clear simple and concise programming model right.  One that should be easy to learn, especially if you are a novice or intermediate Notes developer?

So I would put forward a suggestion....  If we are not careful we may end up making this great product simply too difficult and confusing for people to continue to bother?  The number of people able to master them all and hence go on to do really great things may not be enough to cover for a loss of interest in our yellow underbelly. If we are in fact all part  of an elaborate food-chain we might just see the Notes version of an algae bloom which will not only effect the Notes application development environment but the whole Notes eco system that includes Notes Mail, Sametime, Quickr and Connections.  Yes, its true, people can still program in LotusScript and build applications the old way.  But it is the "old" way and getting older by the day.  If it is not modernized without making it overly complex people will find their way to  newer, easier, technologies.  Technologies like Google Gears and Sharepoint already threaten and there are sure to be other new products coming soon.

So what is needed?...  Well I see two distinct strategies possible.  The first (and my preferred) is modeled on what Microsoft did with .Net.  Develop an intermediate language that drives Notes and make all the above languages compile to this base.  This allows people to chose the language of their preference/experience and also opens the door should a language such as Ruby gain popularity.  The other would be to pick a language that best meets the needs of the Notes "core" and then make it available to ALL design elements (not just Xages).  Both options allow a developer (or development team) to focus on a single programming language requiring less learning, greater productivity, and lower cost development.  But clear direction is needed from IBM.  Without it we will all head off in different directions.  Many people will stick with what they know for as long as they can.  We need something major to shake us all and steer us in a common direction.  That might be a design element like XPages should it ever become powerful enough to do everything the other design elements do (or at least 98%), allows us to do it faster,  is "reasonably" easy to learn, and delivers a superior user experience on a Notes client, Web client, and mobile device.   If I have that I wouldn't care what programming language I am using.  Hey, that's the reason why I am a Notes developer and bleed yellow in the first place!

I don't normally plug my own ideas on ideajam, but this is one I would like to encourage notes developers in the yellowverse to cast a vote.  As many of you know from reading my blog I am in the process of learning how to develop xpages.  It is still early stages for 8.5, xpages ,and server sided Javascript but I am interested in getting and early indicator based upon your own experiences and insight as to whether or not xpages is likely to change Notes developer programming habits away from LotusScript towards Javascript.  Away from forms, views, pages and outlines to xPages.  IBM may or may not care but I am certainly interested.  It will help me decide what I do next with my OpenNTF project  .Domino Framework.  Do I continue to focus on LotusScript, do I turn my attention exclusively to xPages and Javascript, or do I focus on both?