Open Source updates

Open Source projects and code are an important aspect of what we do, so it’s good for us to be able to contribute and share with the wider community. Here’s an update of some of the recent work we’ve been doing.


On the uPortal front we’ve contributed a bug fix to the core uPortal framework which should be incorporated into the uPortal 4 patch releases.

And the Blackboard  Virtual Classroom portlet which we originally contributed to the Apereo foundation (then JASIG) has been updated by the University of Wisconsin to version 2.

Blackboard Learn

We have submitted a building block we wrote a while ago to do dynamic web forms to project oscelot, which is an open source community site based around eLearning. We chose to release the bb-webform-tool (as we call it) code on Github.

We have also submitted the a Building Block which allows creation and integration with Confluence Wiki spaces to Project Oscelot, and have put the bb-confluence-tool code on Github in preparation.

The portlet and building block code above have been released under the MIT license.

Stylesheet Documentation

As part of our CSS review we were looking at how to document and maintain style guides.  This is quite an open field but are currently trying StyleDocco.

You can write your comments in Markdown and present it along side your CSS to have examples of your HTML+CSS.  It’s all in one place and rather handy.

StyleDocco Example
StyleDocco Example

X-ray Tomography Control

The School of Geosciences has an X-ray computed tomography (CT) scanner installed within one of its basement laboratories, which researchers within the school have assembled from individual components. The scanner consists of a number of independent elements, including an X-ray tube and corresponding camera, air table for holding and rotating samples and PCs for controlling the X-ray tube and handling image capture from the camera. Custom software to control the image capture process was written by a PhD student, and this software was driven by Testpoint (which also controls the table on which the sample sits).


The original implementation was based around a Windows 98 installation, and while this solution was rock-solid, time taken for the image capture process was significantly longer than ideal, at around 6 seconds per image (with a 0.5-1.5 second exposure time). Additionally, with the existing high resolution camera displaying worsening artefacts from X-ray exposure, a more modern camera was purchased and required to be integrated into the image capture process.

CT SCreenshot

IS Apps successfully bid on the work to replace the existing PC and software, as an alternative to either purchasing a complete pre-assembled solution, or outsourcing the work to a third party. Limitations of driver availability for the hardware used meant Windows XP was the most recent OS which was suitable for the task, although fortunately this posed relatively few difficulties bar sourcing a new license!

A new C++ application was developed, using the Microsoft Foundation Class library to provide the user interface. C++ was chosen as both the original image capture application, and the majority of worked examples for the hardware, were written in C++. The desire to improve performance, and memory usage of the image capture process, also indicated towards C++ for the fine-grain control the language provides.

The interface was streamlined to eliminate unused options, the image processing options were expanded to clarify the available options, and a control added to allow the camera hardware to be chosen. The image capture process itself was encapsulated within a new dialog window which is displayed when the process is running, and contains the progress indicators and status display (start time, estimated end time, number of images captured, etc.).

CT SCreenshot 2To enable development without requiring constant access to the hardware, support for “dummy” camera and table hardware was added, where the application emulates the relevant hardware internally. As the components operate independently of each other, the user interface, table and camera all operate on individual threads within the application, ensuring that interaction with any of these three elements is processed as close to real time as possible. Communication within the elements is handled primarily via MFC message pumps from the hardware threads to the UI thread, with semaphores and events used to pass data down to the hardware threads where required (most hardware threads as given a fixed task to complete, and are expected to return only when it has finished).

This revised coupling of the hardware control, in combination with reduction in how frequently the cameras require to be re-initialised during an image capture, reduced image capture overheads to a fraction of their previous times. Early estimates are around a tripling in performance, with actual exposure time taken by the camera now dominating time taken.

An example of the resulting rendered “slices” of a section of meteorite, after reconstruction in Octopus, is shown below:


Obviously we’re very pleased with the project results, and hope this provides a clear illustration of the level of work IS Apps is capable of, as well as the cost benefits of in-sourcing of applications.



Testing Times in the SSP

For a recent project we needed to establish some base line timings using selenium and the process had to be automated.  We solved this by combining Firebug and Selenium and producing HAR files.

This article outlines combing firebug and netexport which gives you a very handy export for analysing all of your timings.  Your can then use the HAR viewer to have a look and see what is going on.

Another approach which we tried was – using a REST based proxy tool to record the har files.  This means you don’t have to use the firebug part so could be used cross browser.

We also are having a look at a couple of javascript based testing tools which are well worth a look:

SITS upgraded to 8.7.0

We have upgraded our SITS system to the version 8.7.0 over the last weekend. This was a double upgrade from version 8.6.0 to 8.6.1 and then from 8.6.1 to 8.7.0.

The upgrade process went well. It started from 1pm on Friday 28th Feb, and completed by Saturday evening. This allowed the technical technical tests to start from Sunday morning, and by the 4pm Sunday afternoon, the system was ready and re-opened to the public.


Creating a skeleton Spring MVC Portlet

If you’re needing to create a new JSR-286 portlet, the Apereo Foundation (formerly JASIG), have provided a Maven Archetype for the creation of a skeleton portlet.

Essentially you can run the following command:

mvn archetype:generate -DarchetypeGroupId=org.jasig.portlet.archetype -DarchetypeArtifactId=jsr286-archetype

It will ask you for the group, artefact and package information, and will automatically create a skeleton Spring MVC Portlet for you.

See the using the uMobile Portlet Archetype article for full details.