Frontend developers without knowledge about Domino

Do FE developers must have understanding of IBM Domino/Notes platform?

I believe they should know we use Domino as server, however that's it. Domino is server, so it is responsibility of BE developers. Few years ago when we had mixed UI and Backend in our projects each time FE developer had to do something in IBM Designer I saw such face.

I do not like such face :), one more reason why we forced our self to do what we did.

More details how FE developers works

I will try to describe workspace for typical FE developer on our project. First of all as I mentioned before they do not need IBM Designer, so they can use whatever they prefer. As all FE are located in GitHub after you import project you will get that (example from my Eclipse)

Once they commited anything to GitHub special mechanism would be triggered on our Jenkins build server and it will push all changes to Domino application.

Except many obvious benefits, any disadvantage?

Atm only 2 disadvantages:

1. It takes ~60 seconds after you commit appear in Domino application (Jenkins server has to push all changed elements from GitHub to Domino)
2. If you lost connection to internet - it's a problem (no access to GitHub)

Summary

If you do that you could get such benefits as: GitHub, freedom for FE, better mood for FE, new FE don't need to know anything about IBM Domino

Other articles in this series

1. How we build our web applications based on Domino
2. Split back-end and front-end areas, they should not block each other and be independent as much as it is possible.
3. Front-end guys should not have any knowledge about Domino, they don't need IBM Designer installed at all.
4. Back-end guys must have knowledge about Domino, however they don't need to use IBM Designer, only in very rare cases. Backend should be done using only Java (no LS/SSJS/@Formula etc)
5. Using Git+Jira is must and Jenkins server as builder server
6. Auto-tests.

Split backend & frontend when build web applications

Is it really a problem to mix Backend (BE) and Frontend (FE)?

Yes, it is a problem, it's simply wrong. Some of you will argue with me and say:

• I'm doing both: FE and BE and I'm 'pro' in both areas.
• Our FE developers learned Domino platform in few weeks, so we have no problems, they feel comfortable with doing stuff with IBM Designer.
• Our FE guys simply say what to change and we do that, they send us some template each time we need to change something.
• We are doing internal website and our internal employee do not care about speed, modern UI etc.

I believe some of you are really perfect in both areas: FE and BE and you have enough time to improve skills in both areas just in time, so you don't follow practice that 10 years old. Honestly, at some point I thought I was good enough in both areas (FE and BE) to do modern stuff, however more I worked with web more I realized that my skills FE is not good enough to build really modern, fast and easy maintained web application. I spent years before I gave up and said to myself: I'm quite good in BE and I'm not bad in FE and that's actually enough, after that life became a bit more easy :).

Where is a problem?

Let's take an example when new FE developer joint to the team and he got tasks to change some UI.

1. Classic example (mail9.ntf, form memo)

Problems:

• almost impossible to deal with that if you are not skilled in Domino;
• have to know @Formula language to change <Compute Values> or hidden formulas;
• have to know that fields might have some properties (classes, styles, id etc);
• should ask for help each time they need to change UI;

2. xPages example (discussion9.ntf)

Problems:

• more skill required about Domino, Java, SSJS and xPages especially;
• controls will generate HTML automatically and it is a problem for our team as we aiming for 100% control;
• as it's even more complicated, potentially FE will ask to involve BE developers each time they need to chagne UI.

If we split BE and FE then what?

Then life become much easier :), application will get better structure, things will go faster. How to do that? In our case we found template framework The Apache Velocity Project and tested it enough to make sure it would cover our needs. Then we started to move out UI from logic step by step, and yes, that process took months but once we did it we started to receive benefits immediately. Today we keep UI (HTML templates, CSS, JS) as files and our FE guys use GitHub. They are free to create new templates and organize their structure. They have huge freedom (compare to what they had 2 years ago) of how to do their job. There are really a lot of documentation + stackoverflow.com that can help. However Velcoity itself is quite intuitive and simple framework.

Wanna see 'Hello world' example?

In example bellow we pass 2 items to template (HashMap<String, String> map equal to Dim mylist List as String in LotusScript) then Velocity engine does rest of work and return result. In our project we simply pass all fields from document to template so FE guys have freedom and ability to work independently. It's really easy, proven by our FE guys.

HashMap<String, String> map = new HashMap<String, String>();
map.put("name", "Velocity");
map.put("author", "Joker");
velocity.applyVelocityTemplate("hello.world", map)

+++

## Velocity Template; id 'hello.world'
<html>
    <body>
       ## our hello world example
       Hello $name World!
       $author
    </body>
</html>

||

\/

<html>
    <body>
       Hello Velocity World!
       Joker
    </body>
</html>

Summary

Split and manage!

Other articles in this series

1. How we build our web applications based on Domino
2. Split back-end and front-end areas, they should not block each other and be independent as much as it is possible.
3. Front-end guys should not have any knowledge about Domino, they don't need IBM Designer installed at all.
4. Back-end guys must have knowledge about Domino, however they don't need to use IBM Designer, only in very rare cases. Backend should be done using only Java (no LS/SSJS/@Formula etc)
5. Using Git+Jira is must and Jenkins server as builder server
6. Auto-tests.

How we build our web applications based on Domino

Intro

I've been working with Domino for many years (however very possible less than many of you :-), I started to work with version 5 at the beginning and in few months we migrated to 6.X). I worked in few companies with absolutely different projects and processes of development. There were lot of 'hell projects' (without any structure inside, just mess) and few really 'cool projects' where I could learn something. I always tried to bring the best of the old projects into new. Now I'd like to describe how we develop applications in Domino today. No revolution in our approach, however I believe that is quite good one. The only required thing in that process - you must have time and desire to change process.

Team and projects

We are small and quite typical team: few back-end and front-end developers, manager and no QA as we do not do mistakes :). Roll out each 2 weeks with new features. We are developing CMS that manage external websites of our company.

Few very important points about websites we are doing here:

• website's pages have to load extremely fast (means 200-400 ms to load page);
• clean HTML, all (!) tags, attributes, javascripts should be controlled;
• easy roll out from development environment to production environment without any interrupt for users.

Process of development

Now let's look on most important points of development process. I'll describe each point more deeply in upcoming posts this week. Possibly I will add more points during that time, lets see.

1. Split back-end and front-end areas, they should not block each other and be independent as much as it is possible.
2. Front-end guys should not have any knowledge about Domino, they don't need IBM Designer installed at all.
3. Back-end guys must have knowledge about Domino, however they don't need to use IBM Designer, only in very rare cases. Backend should be done using only Java (no LS/SSJS/@Formula etc)
4. Using Git+Jira is must and Jenkins server as builder server
5. Auto-tests.

We've done almost all the list, some areas require some improvements however concept works and now it's only question of time. All front-end developers do not use IBM Designer in their daily job, back-end developers still use it (rarely), everything goes to GitHub, and then Jenkins take care about rest. That image illustrate what we have.

You are welcome to give your comments, idea, suggestions or something negative about that, everything can help and improve or process and wait for new posts soon :)

Other articles in this series

1. How we build our web applications based on Domino
2. Split back-end and front-end areas, they should not block each other and be independent as much as it is possible.
3. Front-end guys should not have any knowledge about Domino, they don't need IBM Designer installed at all.
4. Back-end guys must have knowledge about Domino, however they don't need to use IBM Designer, only in very rare cases. Backend should be done using only Java (no LS/SSJS/@Formula etc)
5. Using Git+Jira is must and Jenkins server as builder server
6. Auto-tests.

Replacement for DSAPI in Java/XPages

I've written few articles about how DSAPI could help you to control classic web application built on Domino. That solution worked perfect for us and difficulties I encountered were:

• slower development process due to my skill in C;
• poor documentations about how things work in DSAPI (probably most weak side for me);
• deployment process (you need to create new DLL each time and upload it to Domno Server, then restart HTTP);
• you have to be 'very-very' careful with everything, one mistake (i.e. memory leak somewhere) can crash the server at some point;

Last months we worked on new Web CMS based on Java/Velocity in Domino and result I must say was really great. I will make post about most interesting things later: the topic will be about java, html/templates, velocity, git, jenkins, jira and how it works together. I would call it pure Java approach to do development in Domino. The beauty using java as engine allow us to get rid of DSAPI. So everything what have been done with DSAPI (and in total I spend maybe 2-3 weeks) we replaced in 2-3 hours with Java.

case #1: Re-write URL from http://domain/page/subpage/ to http://domain/page/subpage with 301 status. We simply set new location in header and new status

  getResponse().setStatus(MOVED_PERMANENTLY_STATUS);
  getResponse().setHeader(LOCATION_HEADER, uri);

case #2: 404/500 etc error pages we only set correct status for response + throw out required content

  getResponse().setStatus(DEFAULT_ERROR_STATUS);

So my feeling about DSAPI is actually quite good, however be sure you know how to cook it, otherwise - don't go with that solution. Remember my example: I've spent weeks doing DSAPI via C and now we did exactly same in few hours. That feeling when I compared what I spent with DSAPI (via C) compare to new solution with Java. 100 hours agains 3.

Related topics
DSAPI for Domino
Rewriting URL in Domino using DSAPI
Solution for Lotus Domino to the trailing slash problem

Deferred Loading

On my job we are trying to decrease time for loading pages as much as it is possible, we simply want 'fast pages'. We don't want our users waited for 2 seconds each time they load page. We are focusing to keep not more then 0.5-1 second per page and we are doing really a lot in that area. Nowadays It's quite common for most of websites to include javascripts just in head area (or at bottom area) as static html so each time we load pages they will be not responsive till all resources will be loaded. I want to share how to load of javascript files (or any another resouces) just after page loads. It could increase speed dramatically. This solution loads all javascrip files deferred after page load on onload event. That snippet should be minimized and be present on every page where you want to use deferred loading.

Snippet of deferred loader

(function(){
 function deferred(success){
    if (typeof window.onload != 'function') {
   window.onload = success;
  } else {
   var old = window.onload ;
   window.onload = function() {
    old();
    success();
   }
  }
 }

 function getScript(url,success){
  var script=document.createElement('script');
  script.src=url;
  var head=document.getElementsByTagName('head')[0],done=false;
  script.onload=script.onreadystatechange = function(){
    if ( !done && (!this.readyState || this.readyState == 'loaded' || this.readyState == 'complete') ) {
   done=true;
   success();
   script.onload = script.onreadystatechange = null;
   head.removeChild(script);
    }
  };
  head.appendChild(script);
 }

 function getScripts(urls, success){
  var total = 0;
  function trySuccess(){
   total++;
   if(total == urls.length)success();
  }
  
  for (var i = 0; i < urls.length; i++) {
   getScript(urls[i],trySuccess);
  }
 }
 
 var DeferredLoader = window.DeferredLoader = {};
 DeferredLoader.getScript = getScript;
 DeferredLoader.getScripts = getScripts;
 DeferredLoader.deferred= deferred;
})();

How to use loading, in that example we load jQuery, then when it's loaded we load kissmetrics libraries and only then utils.

var urls = {
 jquery: "/javascript/jquery-1.9.1.min.js",
 dependent: ["/javascript/util-2013-04-10m.js"],
 kissmetrics:['//i.kissmetrics.com/i.js','//doug1izaerwt3.cloudfront.net/' + window._kmk + '.1.js' ]
};

DeferredLoader.deferred(function () {
 DeferredLoader.getScript(urls.jquery, function () {
  DeferredLoader.getScripts(urls.kissmetrics, function () {
   DeferredLoader.getScripts(urls.dependent, function(){})
  })
 })
})