Wednesday, August 07, 2013

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.

8 comments :

sodoherty.com said...

I'm not sure if you are aware, but you can use Github with Domino Designer.

http://www.slideshare.net/perlausten/source-control-with-domino-designer-853-and-git-dan-notes-november-28-2012

Dmytro Pastovenskyi said...

Unfortunately that approach require using of IBM Designer and we wanted to get freedom of tools for FE guys.

Andriy Kuba said...

@sodoherty.com "http://www.slideshare.net/perlausten/source-control-with-domino-designer-853-and-git-dan-notes-november-28-2012"

It's need Domino Designer, It's create a lot of "garbage code", It's do not allow to create "hooks".

For example, on the "build" stage we build a set of JavasCript files in to one, validate it, minimize it.

We also need to synchronize some information from trivial document. Trivial Domino Designer Synchronize tool does not allow to do it.

sodoherty.com said...

@Andriy. Not sure what you mean by "Garbage code".

There was a discussion on this a week or two ago.

http://chat.stackoverflow.com/transcript/33291/2013/7/11

Andriy Kuba said...

@sodoherty.com.
Good discussion. I like that Git diagram too, looks like that is epic diagram.

"Garbage code" means code that need only for some system (framework) and useless for others.

Let's look on "example.js" file that resides in ".nsf". Native Domino synchronization plugin will create file "example.js" (clean code) and "example.js.metadata" (garbage code).

"example.js.metadata" contain specific information that useless for anyone but Domino synchronization plugin.

I am, as developer, completely not interested in the "example.js.metadata", every change in that file (that would be forced by Domino synchronization plugin on any "example.js" change) would discourage me.

Javascript is still a good decision, Java Libraries is worst. It's contain all metadata in the same file with java code.

stubben said...

I looked like the image when I first saw this piece of @formula code (small snippet):


allTypesBlock:=@Implode(@Transform(type_unique;"type";@Do(
count:=count+1;
countString :=@Text(count);
id := "t"+countString;
"[<]a class=\"pvs md_bx_rad md_adm_filter md_txt_deco_no md_blck md_fl\" title=\""+type+"\" href=\""+
@Do(link := "z"+param_z+"-t"+
@Do(
@If(@IsMember(countString;param_t );
@If(@Elements(param_t)=1;
"x";
@Implode(@Sort(@Trim(@Replace(param_t;countString;"")));"t")
);


There is very little HTML in that code and a lot more BE logic. It's not impossible to learn or understand but for a FE guy it takes time and whenever something breaks the FE guy need to annoy the BE guy.

With Velocity it can look something like this:


[<]div class="row">
[<]!-- Type headline -->
[<]div class="cell s1of4 pts">
[<]span class="plm fw7 fs5 fc4">$type_label[<]/span> [<]span class="h2">($type_size)[<]/span>
[<]/div>

[<]!-- Services headline -->
[<]div class="cell s1of2 pts">
[<]span class="fw7 fs5 fc4">$service_label[<]/span> [<]span class="h2">($service_size)[<]/span>
[<]/div>
[<]div class="cellRight s1of4">
[<]div class="cellRight fw7 fs4 bc1 md_txtc md_admlst_filter_expcol">-[<]/div>
[<]/div>
[<]/div>


Objects can be manipulated and the page can be divided up into even smaller and more manageable pieces of code blocks.

It speeds up the development and makes everybody happy :-)

Note:
I'v replaced start tag less then with [<] to be able to post.

sodoherty.com said...

@Andriy, "example.js.metadata" is not garbage code. It is data about the object in the database that isn't contained within the JS file itself. For example replication details, access control, design protection, etc.

If you plan to use the JS file independent of the NSF, then yes it doesn't make sense to do it this way. In fact you can switch designer over to Java project view (So same as Eclipse) and work with the files directly off disk.

But if you are using the JS file as part of your XPages, then the metadata is important.

Andriy Kuba said...

@sodoherty.com
>For example replication details, access control, design protection, etc.

You are correct, we just not use such data and I could not remember any project that use ACL on javascript files directly.

Generally we use clean JavaScript, i.e. it could be extracted from NSF and put in to CDN without problem for application.