Friday, January 24, 2014

Why attend LinuxFest at IBM Connect 2014

Thanks to Bill Malchisky, LinuxFest V is back at IBM Connect 2014. It will be held on Thursday, January 30, 2014 at 12:30 PM to 1:30 PM at the Dolphin - Oceanic 2.  Though it is not an official session, this is one of the sessions that I have always attended at Lotusphere/IBM Connect in the past. There is no marketing BS, all technical knowledge from some of the best Linux experts in the IBM Community.  And they tell you like it is.

As a software architect, designer, and developer, it is very important that you understand the operating system that your application is running on from the perspective of resources and security. This determines how you approach the design and architecture of your application.  Linux has become a significant part of the IBM Collaboration environment and its importance has been growing especially if you are looking at cloud-based solutions.  As a company, almost all our servers are on Linux and with a few desktops.  Even if you are running a Windows shop, you should attend this session.

So if you are an administrator or developer and attending IBM Connect 2014 you should attend this unofficial session at IBM Connect. Special thanks to Red Hat for sponsoring. For more information about this session go to Bill's blog:

http://www.billmal.com/billmal/billmal.nsf/dx/linuxfestv.htm

Monday, January 20, 2014

The End of an Era

As some know we are celebrating our 23th anniversary as entrepreneurs this year.  It has been full of highs and lows.  One of most fun achievement that we had was in the first couple of years as ReCor.  Now it is most standard corporate training with ReCor and social collaboration and BPM technology with Phora Group and our iPhora solutions.

As one starts out, you try to determine your bearings.  Usually reality hits and you throw out all the business plans and marketing stuff.  So early on we did some stuff for free hoping that something might come out of it in the future.  And that is what happened.  About a year later, the person we helped out came back to us to develop a kiosk for an exhibit.  We did not know much about kiosks at that time, but we knew technology.  You have to remember that we are talking about the early 90s and there is no Internet, Windows, Macs, fancy computers.  The latest and greatest was Intel 486 processor and VGA graphics card with a whole 64 Mbytes of memory and the beginning of touch screen technology which always turned yellow after awhile.

The requirements was that it had to be a real-time interactive touch screen application that would run everyday over and over again.  Windows 3.0 came out and it sucked.  So we had to use DOS which did not have much graphics capabilities

So my two colleagues, Rob Burton and Dan Eitel tacked with me on the development of these kiosks. With no real graphics compilers out there Rob Burton was able to find a machine code based library called Fast Graphics and we built our own language compiler that ran the kiosk in real-time.

We struggle for months to get it working, but we did it!!!

These kiosks were for the Take Flight Exhibit in the Museum of Science and Industry.  Millions and millions of attendees have seen and played with these kiosks and is one of the biggest exhibits in the Museum. If you ever attended the Museum of Science and Industry, you can not miss it.  We were able to attend the opening ceremony with all the big wigs.

These kiosks have been run everyday since. During a twitter conversation with Don McNally who was attending the Museum of Science and Industry, I was told by my colleague that the museum had recently replaced our kiosks with newer one near the end of last year.  I am very saddened and proud.  We never expect the kiosks to last 19 years of continuous use.  The kiosks were turned on by powering it up and turned off by a hard power shut down.  Gateway definitely built some nice hardware those days.

So to this day, these kiosk applications are the longest running applications that we ever built and we are proud of what we done and achieved. It was a fun project that resulted in where we are as entrepreneurs.

Tuesday, January 7, 2014

Optimizing Dojo Loading for Bootstrap Widgets

Over the past year, one of our major efforts for our iPhora products was to switch from using Dojo Dijit widgets to only Bootstrap widgets.  One of the problems that we have seen with Dijit widgets is that they take a long time to load and are very heavy compared with JQuery based Bootstrap widgets. The advantage of JQuery-based Bootstrap widgets is that they are loaded all at once as a single file. This is great to minimize the loading speed.  However, it does not lend itself to easy maintenance by multiple developers.

With Dojo you load the individual widgets are needed using dojo.require. Unfortunately, this results in multiple HTTP request in order to load the individual widgets and support files. Even if we are not using Dijit widgets but you want to use dijit._Widget to creating your own widgets, Dojo loads a whole brunch of additional files like dijit._LayoutWidget.js and doubles the loading process.  That is because you need to load dijit.js in order to use dijits. So without any widgets on the page it requires you to load the following:


 
 
I highlighted in red the files that I did not need to load.

 

Note: I use buildRendering directing instead of using dijit._Templated.  I load dojo.string when I need it and do not use dojo.cache.js since I am not using dijit._Templated.

So out of frustration, I was determined to figure out how to get rid of these unneeded files.  When you require dijit._Widget  it automatically forces you to load dijit._base which loads many files that is specific to dijit widgets.  So I first strip this down from:


if(!dojo._hasResource["dijit._base"]){
dojo._hasResource["dijit._base"]=true;
dojo.provide("dijit._base");
dojo.require("dijit._base.focus");
dojo.require("dijit._base.manager");
dojo.require("dijit._base.place");
dojo.require("dijit._base.popup");
dojo.require("dijit._base.scroll");
dojo.require("dijit._base.sniff");
dojo.require("dijit._base.typematic");
dojo.require("dijit._base.wai");
dojo.require("dijit._base.window");
}
 
to
 
if(!dojo._hasResource["dijit._base"]){ dojo._hasResource["dijit._base"]=true; dojo.provide("dijit._base"); dojo.require("dijit._base.focus"); dojo.require("dijit._base.manager"); dojo.require("dijit._base.place"); dojo.require("dijit._base.typematic");
dojo.require("dijit._base.window");
}
 
which takes care of all the dijit._base files.  The rest of the highlighted files are load by dijit.js. So instead of loading dijit.js for the page I created by own loader js file that contains:

/* Copyrighted 2009-2013 Phora Group. All rights reserved.*/
if(!dojo._hasResource["dijit._base"]){
 dojo._hasResource["dijit._base"]=true;
 dojo.provide("dijit._base");
 dojo.require("dijit._base.focus");
 dojo.require("dijit._base.manager");
 dojo.require("dijit._base.place");
 dojo.require("dojo.uacss");
 dojo.require("dijit._base.typematic");
 dojo.require("dijit._base.window");
}
if(!dojo._hasResource["dijit.dijit"]){
 dojo._hasResource["dijit.dijit"]=true;
 dojo.provide("dijit.dijit");
 dojo.require("dijit._Widget");
 dojo.require('dojo.cookie');
 dojo.require('iphora._ipBase');
}


It first loads all the _base files that I need and then load dijit which contains the only thing I need, dijit._Widget.  As part of the process I have it also load dojo.cookie which I usually need and iphora._ipBase which has all the base iphora support methods for creating Bootstrap widgets.

This method eliminates the need to call dijit._base separately which normally creates another HTTP request that is not needed. When the call is made to load dijit._Widget, dijit._base is already loaded with the new file list definition so it uses this list instead of the one that is provided.

So as a result of this exercise the loading process requires less than half of the files.


 
 
 
 
 
 
 
 
 
 
 
 
What you need to load depends are what you are doing with Dojo.  So if you are interested in creating a faster loading process you should experiment.  Have fun.