A couple of days ago we hosted a one-day conference, HTML5 – It Just Got Real, at the Royal Society buildings in London. I’m happy to say that the event was a great success, and that the Q&A session that followed our talks was very lively!

As promised, we have made all of our presentations available online. The first three presentations have all been created using HTML5, whilst the last uses PowerPoint.

Attention!

These presentation were designed to work with the Chrome browser, and are navigated using the left and right arrow keys. They are not intended to be a demonstration of cross-browser HTML5, on the contrary! They illustrate the fact that HTML5 has not solved the need to consider specific browsers and browser-versions when writing code.

HTML5 Revolution

– by Colin Eberhardt, you can view the presentation in your browser, and view the sourcecode on github.

HTML5 – It Just Got Real

– by Chris Price, you can view the presentation in your browser, and view the sourcecode on github.

Designing the Future

– by Graham Odds, you can view the presentation in your browser, and view the sourcecode on github.

Cross-Platform Mobile Development

– by Colin Eberhardt, this presentation is hosted on slideshare, with videos made available via YouTube.

Natalie Jolly, Communications Manager, said:

“The quality of submission was particularly high and made for a very difficult decision. Everyone participating did extraordinarily well and the principles and disciplines behind each entry was fascinating to listen to. We wish every student involved all the best with their continued studies.”

Whilst there the team also took the opportunity to talk to students about career opportunities at Scott Logic as well as demoing the latest version of the ShinobiControls app ‘ShinobiPlay’.

The position is based in the ShinobiControls team (shinobicontrols.com), a product team based in our central Bristol offices, within easy walking distance of the railway station. The team is building a suite of fully customizable controls including Grids and Charts, in order to enable third-party application developers to build apps using innovative, enhanced UI controls. With over four hundred clients, they are now looking to augment the team with a senior developer who has at least five years of OO development experience or experience of ObjectiveC.

Essential:

• Language expert (C++/ Java / C#)
• OO design skills, including design patterns
• Exposure to the full software development lifecycle
• Exposure to Agile/Scrum methodology
• Team player and self-motivated individual

Desirable:

• Objective C
• Mobile experience
• Product development experience

ScottLogic offer a highly competitive salary and benefits package, including:

• Performance and profit-related bonus scheme
• 25 days holiday per year, growing with length of service
• Life assurance
• Contributory pension scheme

In addition, we can offer the following:

• Office location in central Bristol
• A wide variety of technologies and platforms
• The opportunity to work with pro-active, smart developers

A CV and covering letter specifying your areas of expertise and interest, along with your salary expectations, should be sent to applications@scottlogic.co.uk.

Scott Logic is a software consultancy that provides the very best in bespoke software across web, mobile and desktop. Our consultancy work is complemented by two product brands, ShinobiControls (www.shinobicontrols.com) and Visiblox (www.visiblox.com). The ever-growing significance of user experience design in both our consultancy and product work means we are looking to grow our UX Practice.

While the job title hopefully already tells you a lot, here are more specifics about what we are looking for and why you should want to join us:
You share our core beliefs about user experience design, namely that:

• Research and exploration form the foundations of our designs, since problems can only be solved effectively once they are understood.
• Our collaborative approach focuses on delivering the end product with minimal waste, and empowers stakeholders, users and developers alike.
• Short cycles leading to analysis and feedback improve designs and maintain project focus.
• We create effective, beautiful interfaces because we recognise the importance of every design decision, not just those relating to aesthetics.

You want to design functionally rich applications across web, mobile and desktop, rather than just another website.

You want to be part of a team, producing high quality, innovative end products that effectively marry user needs and business goals.

You live, sleep and breathe user-centred design, and don’t mind extolling about both the theory and practicalities of it to anyone who will listen.

Coding doesn’t scare or alienate you, and you’re as happy to learn about it as you are educating developers about design.

As if that wasn’t enough, we also offer a great remuneration and benefits package, including:

• Performance and profit related bonus scheme
• 25 days holiday per year, growing with length of service up to 30 days
• Life assurance
• Pension Scheme
• Childcare vouchers
• Cycle to Work Scheme
• Referral programme – payable to anyone who refers a successful candidate

To apply, please email your CV, portfolio and a brief cover note to applications@scottlogic.co.uk.

This blog post describes the addition of a two-finger rotation and three-finger pitch gesture to the Windows Phone 8 Map control.

You can see these gesture in action below:

The WP8 release replaced the image-tile based Bing maps with a fully vector-rendered map from Nokia. Being vector-based, this map can be panned, zoomed, rotated and rendered at an angle (i.e. pitched). However, much of this new functionality is not offered to the end user!

The WP8 supports the same gestures that the Bing WP7 map did, i.e. a single-fingered pan gesture and two-fingered pinch to zoom. What about rotation and pitch? Why not allow the user to modify these via gestures?

The key here is to add some new gestures that complement the existing one. I opted for the following:

• Two-finger rotate – When the user places two fingers on the map this is currently used to zoom the display via a ‘spreading’ motion. However, if the user instead rotates the two touch points around the centre, the map should be rotated.
• Three-finger pitch – When the user places three fingers on the map, if they drag up or down, the map should adjust its pitch accordingly.

These gestures are enabled simply by creating them with a reference to the map:

new MapRotationGesture(map);
new MapPitchGesture(map);

If you don’t care how this all works, just head over to github and grab the code. If you want to find out more, read on …

Suppressing The Existing Gestures

In order to add these new gestures to the map, there needs to be a mechanism in place to suppress the existing gestures so that they do not interfere.

The technique I used is similar to a technique I demonstrated previously for suppressing pinch and scroll in the Windows Phone Browser control. Both the Map and WebBrowser controls have a visual tree containing a number of user interface elements. The inner structure of the Map is shown below:

Microsoft.Phone.Maps.Controls.Map
  System.Windows.Controls.Border
    System.Windows.Controls.Border
      Microsoft.Phone.Maps.Controls.MapPresentationContainer
        MS.Internal.ExternalInputContainer
          System.Windows.Controls.Grid
            MS.Internal.TileHostV2
            Microsoft.Phone.Maps.Controls.RootMapLayer

The technique for suppressing interactions is quite simple, just add a ManipulationDelta event handler to each one of these elements, setting the event to handled. The complete code is show below:

/// <summary>
/// A base class for map gestures, which allows them to suppress the built-in map gestures.
/// </summary>
public class MapGestureBase
{
  /// <summary>
  /// Gets or sets whether to suppress the existing gestures/
  /// </summary>
  public bool SuppressMapGestures { get; set; }
 
  protected Map Map { get; private set; }
 
  public MapGestureBase(Map map)
  {
    Map = map;
    map.Loaded += (s,e) => CrawlTree(Map);
  }
 
  private void CrawlTree(FrameworkElement el)
  {
    el.ManipulationDelta += MapElement_ManipulationDelta;
    for (int c = 0; c < VisualTreeHelper.GetChildrenCount(el); c++)
    {
      CrawlTree(VisualTreeHelper.GetChild(el, c) as FrameworkElement);
    }
  }
 
  private void MapElement_ManipulationDelta(object sender, ManipulationDeltaEventArgs e)
  {
    if (SuppressMapGestures)
      e.Handled = true;
  }
}

If you create an instance of this class and associate it with a map you can turn gestures on and off via the SuppressMapGestures property:

var gestureBase = new MapGestureBase(map);
gestureBase.SuppressMapGestures = true;

NOTE: Unfortunately this doesn’t solve the ‘map in a pivot’ or ‘map in a panorama’ problem that many Windows Phone developers have struggled with – the gestures that are handled are not propagated to a parent control.

A Rotation Gesture

The user can rotate the map by placing two fingers on the screen then rotating them around their central point. Because two fingers are also used for the pinch-to-zoom gesture, a suitable threshold needs to be introduced. I have found that disabling rotation until the user has rotated by 10 degrees feels about right.

The code that implements the rotation is really quite simple, the MapGestureBase subclass is shown in its entirety below:

/// <summary>
/// Adds a two-finger rotation gesture to a Map control.
/// </summary>
public class MapRotationGesture : MapGestureBase
{
  /// <summary>
  /// Gets or sets the minimuum rotation that the user must apply in order to initiate this gesture.
  /// </summary>
  public double MinimumRotation { get; set; }
 
  private double? _previousAngle;
 
  private bool _isRotating;
 
  public MapRotationGesture(Map map)
    : base(map)
  {
    MinimumRotation = 10.0;
    Touch.FrameReported += Touch_FrameReported;
  }
 
 
  private void Touch_FrameReported(object sender, TouchFrameEventArgs e)
  {
    var touchPoints = e.GetTouchPoints(Map);
 
    if (touchPoints.Count == 2)
    {
      // for the initial touch, record the angle between the fingers
      if (!_previousAngle.HasValue)
      {
        _previousAngle = AngleBetweenPoints(touchPoints[0], touchPoints[1]);
      }
 
      // should we rotate?
      if (!_isRotating)
      {
        double angle = AngleBetweenPoints(touchPoints[0], touchPoints[1]);
        double delta = angle - _previousAngle.Value;
        if (Math.Abs(delta) > MinimumRotation)
        {
          _isRotating = true;
          SuppressMapGestures = true;
        }
      }
 
      // rotate me
      if (_isRotating)
      {
        double angle = AngleBetweenPoints(touchPoints[0], touchPoints[1]);
        double delta = angle - _previousAngle.Value;
        Map.Heading -= delta;
        _previousAngle = angle;
      }
    }
    else
    {
      _previousAngle = null;
      _isRotating = false;
      SuppressMapGestures = false;
    }
  }
 
  private double AngleBetweenPoints(TouchPoint p1, TouchPoint p2)
  {
    return Math.Atan2(p1.Position.Y - p2.Position.Y, p1.Position.X - p2.Position.X)
            *(180 / Math.PI);
  }
}

Touch gestures are detected via the Touch.FrameReported event. When two fingers are placed on the screen the initial rotation angle is recorded. When the minimum rotation is exceeded, the Map.Heading is updated with each ‘delta’ reported. Really simple code, but a fantastic feature for the user!

A Pitch Gesture

You get a real feel for the vector-nature of the maps when you set the ‘pitch’, a style of rendering that is often used on satnavs.

I initially considered using a two finger pull-down gesture, which is similar to the one which Google Maps on Android uses, but found it very hard to coordinate the three gestures, zoom, rotate, pitch, which all use the same two-fingers! So instead, I opted for a three-finger pull-down gesture to increase the pitch of the map.

The code follows a very similar pattern to the rotate gesture:

/// <summary>
/// Adds a three-finger pitch gesture to a Map control.
/// </summary>
public class MapPitchGesture : MapGestureBase
{
  /// <summary>
  /// Gets or sets the sensitivity of this gesture
  /// </summary>
  public double Sensitivity { get; set; }
 
  private double? _initialPitchYLocation;
 
  public MapPitchGesture(Map map)
    : base(map)
  {
    Sensitivity = 0.5;
    Touch.FrameReported += Touch_FrameReported;
  }
 
  private void Touch_FrameReported(object sender, TouchFrameEventArgs e)
  {
    var touchPoints = e.GetTouchPoints(Map);
 
    SuppressMapGestures = touchPoints.Count == 3;
 
    if (touchPoints.Count == 3)
    {
      if (!_initialPitchYLocation.HasValue)
      {
        _initialPitchYLocation = touchPoints[0].Position.Y;
      }
 
      double delta = touchPoints[0].Position.Y - _initialPitchYLocation.Value;
      double newPitch = Math.Max(0, Math.Min(75, (Map.Pitch + delta * Sensitivity)));
      Map.Pitch = newPitch;
      _initialPitchYLocation = touchPoints[0].Position.Y;
    }
    else
    {
      _initialPitchYLocation = null;
    }
  }
}

As soon as three fingers are placed on the screen, the gesture becomes active. The movement of the first finger is used to determine the delta to apply to the Pitch property. Again, nice and simple!

The sourcecode for these gesture, plus a demo app is available via github. Please let me know if you use this code in any of your apps.

Regards, Colin E.

This blog post compares the same twitter search application written with both Knockout and Kendo in order to highlight the strengths and weaknesses of each framework.

Introduction

I’ve always been a big fan of Knockout, most likely because it reminds me of Silverlight (rest in peace).

For my thoughts on how Silverlight and Knockout compare, head over to codeproject where I wrote quite a lengthy article on the subject.

More recently I have been dabbling with the use of Knockout for writing mobile applications. Because Knockout is an MVVM framework and doesn’t have any UI components of its own, I used a combination of jQuery Mobile (jQM) and Knockout. I must admit, the integration of these two frameworks wasn’t entirely painless!.

It is the integration pain I experienced with jQM and Knockout that has resulted in my interest in KendoUI.

KendoUI (www.kendoui.com) is a commercial JavaScript framework that includes web and mobile UI widgets together with an MVVM framework, which, on initial inspection, closely resembles Knockout. The promise of an MVVM framework and mobile widgets that play nicely together is quite appealing!

In order to compare Kendo with Knockout + jQM I re-implemented the twitter-search application that I blogged about a few months ago. The rest of this blog post is a collection of thoughts, commentary on the differences and personal opinions.

The two version of the code are available on github:

• https://github.com/ColinEberhardt/Knockout-jQueryMobile
• https://github.com/ColinEberhardt/KendoUI-TwitterSearch

And you can see working examples at the following locations:

• Knockout + jQuery Mobile
• KendoUI

It is worth viewing the above on your phone.

From Knockout to KendoUI

• Knockout has magic properties, Kendo has magic objects!
• Knockout is more flexible regarding view model construction
• Kendo requires a little effort to make it work with Intellisense
• Knockout supports view model hierarchies
• Kendo bindings are not JavaScript!
• Kendo lacks a $data binding
• Kendo has its own UI widgets!
• Kendo UI does not mangle the DOM
• jQM has a more extensive set of styles
• Kendo supports multiple mobile themes
• Kendo has a datasource concept
• Knockout is open source, Kendo costs $$$

Knockout has magic properties, Kendo has magic objects!

JavaScript does not support the notion of change-notification when you change the value of an object’s properties. This is a vital feature for supporting binding within an MVVM framework, so both Kendo and Knockout have to provide this missing change notification.

With Knockout change notification is provided via observable properties:

var knockoutViewModel = {
  name : ko.observable("john")
};

When a property has been created via ko.observable you can subscribe to change notifications for that property.

With Kendo change notification is provided via observable objects:

var kendoViewModel = kendo.observable({
  name : "john"
});

And as a result you can subscribe to change notifications on the object..

Neither Kendo or Knockout are able to detect when a property is set directly, instead, you must set the property value via a function. With Knockout, your property is actually a function which you can set as follows:

knockoutViewModel.name(“john smith”):

Whereas with Kendo you set the property via the owning object:

kendoViewModel.set(“name”, “john smith”);

Both Kendo and Knockout support the concept of dependant properties, where you construct a property by composing one or more of the other objects properties, with change notifications happening automatically.

Both Kendo’s object-centic and Knockout’s property-centric approaches seem quite reasonable, but as we shall see later this small difference has an impact on many aspects of each framework.

Knockout is more flexible regarding view model construction

Because Knockout performs its ‘magic’ at the property level, it does not place any restrictions on the way in which you construct your view models. You can use the literal syntax:

var knockoutViewModel = {
  name : ko.observable("john")
};

Or define a constructor:

function KnockoutViewModel() {
  this.name = ko.observable("john");
}
 
var viewModel = new KnockoutViewModel();

Personally I like the second approach because it gives you a view model ‘factory’, i.e. you can create multiple instances of the same view model, and it also allows you to define both public and private functions:

function KnockoutViewModel() {
  this.name = ko.observable("john");
 
  saveState = function() {
    // do something here
  }
 
  this.update = function() {
    saveState();
  }
}

In the code above the saveState function is private – for more information on this pattern I’d recommend reading Private Members in JavaScript by Douglas Crockford.

All of the Kendo examples create view model using a literal syntax:

var kendoViewModel = kendo.observable({
  name : "john"
});

Initially I was under the impression that it wasn’t possible to create Kendo view models using constructor functions, furthermore, one of the nice guys from the Kendo support rather apologetically told me “I am afraid that it is not possible to emulate Knockout style of view model creation via functions. Kendo MVVM supports only the literal style.”.

However, after a little bit of thought, I realised that it is possible if you explicitly return an observable as follows:

function KendoViewModel() {
  this.name = “john”;
 
  return kendo.observable(this);
}
 
var viewModel = new KendoViewModel ();

However, things are not quite so straightforward – if you need to capture the reference to ‘this’ you must ensure that the reference is to the observable object, as follows:

function KendoViewModel() {
  this.name = “john”;
 
  function saveState = function() { 
    console.log(that);
  }
 
  this.update = function() {
    saveState();
  }
 
  var that = kendo.observable(this);
  return that;
}
 
var viewModel = new KendoViewModel ();

In the above code the variable, that, is always going to refer to the observable object regardless of what, this, refers to.

Kendo requires a little effort to make it work with Intellisense

Following on from the previous point, because the Kendo ‘magic’ is at the object level, Visual Studio Intellisense becomes flummoxed. Now I know that Visual Studio is perhaps not the best tool for JavaScript, but I can bet that quite a few Knockout and Kendo developers use it!

Visual Studio uses pseudo-execution of your JavaScript code to provide Intellisense. With Knockout this works well out-of-the-box – see the image below where the update function, together with its ‘summary’ text, are picked up by Intellisense:

Whereas with Kendo, in order for Visual Studio to be able to execute your code it needs to be aware of the Kendo and jQuery JavaScript files. This can be done by adding a ‘reference’ comment, as shown below:

Note that you can also see the other functions that are present on observable objects.

Knockout supports view model hierarchies

One particularly elegant feature of Knockout is that it supports view model hierarchies. When binding collections of objects, Knockout creates a child binding context that refers to the nested view model data. You can also explicitly set the binding-context of an element via the ‘with’ binding. This approach allows you to create complex nested view models.

With Kendo, when binding a collection of objects the ‘context’ for each item is the parent view model, which means that any event bindings are sent to the owning view model. This is clearly due to the way that Kendo uses observable objects rather than observable properties.

Whilst this is not a significant limitation, I do miss the binding-context concept when working with Kendo. The lack of this feature does mean that view models can become bloated.

Kendo bindings are not JavaScript!

With Knockout, bindings are JavaScript, which means you can have bindings which contain logic. For example:

data-bind="enable: searchTerm().length > 0 && isSearching() == false,
           click: search"

Kendo bindings are not JavaScript!

A simple way to achieve equivalent functionality is to move the JavaScript in the binding into a dependant property:

searchButtonDisabled: function () {
  return this.get("searchTerm").length === 0 && this.get("isSearching") === false;
}

Which is bound as follows:

data-bind="click: executeSearch, { disabled: searchButtonDisabled }"

I do not see this as a significant limitation of Kendo. I do use this feature quite often with Knockout, it feels a little like the Silverlight / WPF concept of value-converters. However, I can see how it could be abused, hiding JavaScript logic within bindings isn’t terribly good for testing or maintenance!

Kendo lacks a $data binding

With Knockout, if you create a ‘foreach’ binding to an array of strings, the template that renders each string can make use of the $data binding:

<span data-bind="text: $data"></span>

The above is needed because the binding-context of the above span element is a string – we want to bind to the object itself rather than a property of the object.

I could not find an equivalent feature with Kendo, so had to create an object as a container for the string:

this.recentSearches.unshift({ searchString: this.searchTerm });

And bind it as follows:

<span data-bind="text:searchString"></span>

Again, a pretty minor limitation.

Kendo has its own UI widgets!

So far much of my discussion has focussed on Knockout features which Kendo does not support. However, Kendo is much more than just an MVVM framework, it includes a large number of web and mobile UI widgets.

In the context of this comparison, I integrated jQM with Knockout to create my mobile UI – and as I mentioned earlier, this integration was pretty painful. In contrast, the Kendo UI Mobile framework integrates seamlessly with the Kendo MVVM framework – as you might expected!

Kendo UI does not mangle the DOM

While we are on the subject of the UI, one of the features of jQM that I really disliked is the way that it totally mangles the DOM.

In order to support the jQM styling it requires a large number of ‘supporting’ elements. As an example a button is transformed from this:

<button type="submit" data-bind="enable: isSearchEnabled,
                                 click: executeSearch">Go</button>

To this:

<div class="ui-btn ui-btn-inline ui-btn-corner-all ui-shadow ui-btn-up-c">
  <span class="ui-btn-inner ui-btn-corner-all">
    <span class="ui-btn-text">Go</span>
  </span>
  <input class="ui-btn-hidden" type="button" value="Go"
                  data-bind="enable: isSearchEnabled, 
                                    click: executeSearch"/>
</div>

This causes all kinds of headaches when trying to use jQM with an MVVM or MVC framework.

In contrast, with Kendo when you create a button:

<a data-role="button" 
   data-bind="click: executeSearch, { disabled: searchButtonDisabled }">Go</a>

It adds very little supporting structure:

<a data-role="button" class=" km-button"
      data-bind="click: executeSearch, { disabled: searchButtonDisabled }">
      <span class="km-text">Go</span>
</a>

And in many cases it leaves the DOM structure unaltered.

jQM has a more extensive set of styles

The jQuery Mobile framework is more extensive than Kendo. As a quick example, jQM nicely styles your list items:

With Kendo, you have to put in a bit of extra effort to style the list:

This is just one example of many – jQM is a big framework.

Kendo supports multiple mobile themes

The jQM UI is designed to look at home on iOS devices, which is just fine for the ~30% of people who own an iPhone. However, this UI just looks plain wrong on an Android or Windows Phone.

There are a few open source Android themes for jQM, but I didn’t get a satisfactory result with any of them. Also, Microsoft have contributed a Metro theme to jQM, but it is rather ugly!

In contrast, Kendo supports iOS, Android, BlackBerry and Windows Phone, as shown on their online demo. This is pretty neat!

Kendo has a datasource concept

With the Knockout + jQM application I wrote a very simple TwitterSearchService which acts as a datasource. The Kendo framework has a DataSource component which makes integrating with services such as Twitter much easier, you typically provide configuration to the DataSource and it does the rest. Also, the UI components like the ListView integrate directly with the DataSource, with features like pull-to-load-more available out-of-the-box.

Knockout is open source, Kendo costs $$$

This one is pretty obvious really …

Knockout is open source, and as a result doesn’t cost you anything to use it. For an open source project it is very well documented and there are many blog posts that provide tutorials and solutions to problems. The interactive tutorial is a particularly fantastic idea.

Kendo will cost you a few hundred dollars to buy (http://www.kendoui.com/purchase.aspx). Considering that Kendo is a UI widget framework, MVVM framework and mobile framework, I would say that the price is very reasonable. Also, the documentation is of a similar quantity and quality to that of Knockout.

Conclusions

This article has been a mixed-bag of observations, thoughts and opinions and it is not intended to be an exhaustive comparison. Despite that, I hope it will be useful for others.

I certainly prefer the Knockout implementation of MVVM, I find it more powerful and flexible than the Kendo equivalent. However, Kendo’s MVVM framework is certainly adequate.

When it comes to building mobile applications, the fully integrated Kendo solution has some pretty big advantages over Knockout and jQuery Mobile.

Regards, Colin E.

Announcing a one-day conference at the Royal Society, London UK, on the 14th of May.

Just a few years back I wrote a white paper titled “Flex, Silverlight or HTML5? Time to decide …” with the help of a couple of my colleagues, comparing the strengths and weaknesses of the three competing technologies. This paper was aimed at helping developers make an informed choice when faced with developing an interactive web site or complex web app.

Don’t bother reading that white paper now! It was only written two years ago, but is now so out-of-date that it might as well have been written ten years ago.

Here’s the penultimate paragraph:

“It is very difficult to predict where we will be in a few years’ time and whether there will be some technology casualties along the way. Can all three technologies co-exist? Or will one or more be relegated to the internet history books like Java Applets and ActiveX?”

Yes, there have been some casualties, both Silverlight … and Flex!

The rise of smartphones and tablets has accelerated HTML5 adoption to the point where plugins are considered a legacy technology. Invest in them at your peril!

The problem is that enterprise-scale HTML5 development is far from easy. With Flex and Silverlight you have the comfort of working within a shrink-wrapped development environment, whereas HTML5 is like the Wild West; assembling a workable set of tools, framework and processes is not an easy task.

This is why we decided to stage our own conference – we want to talk about the challenges of enterprise scale HTML5 development, and how to tackle them.

If you are interested, and are thinking of signing up, take a look at the conference website – html5-it-just-got-real.com – there will be talks on a range of subjects, ranging from practical and insightful to radical and fun (we have a BBC presenter and a guitar-wielding JavaScript rockstar).

Regards, Colin E.

Scott Logic Ltd is a growing technology consultancy which provides the very best in bespoke software solutions across a variety of market sectors. Our clients demand that we stay at the cutting-edge: we design complex business-critical systems, ranging from sophisticated graphical research analysis tools through to back-office settlement platforms.

Our development roles are very hands-on and at least 90% of your time will be spent developing software. We can give you the opportunity to get involved in full life-cycle development, working in collaboration with our clients, from our office locations in Newcastle, Bristol and Edinburgh.

Our offices are in city centre locations enabling an easy, car-free commute.

Essential:

• A relevant degree (involving some computer science) from a reputable university
• Commercial experience in an OO environment
• Experienced developing enterprise scale applications using Java EE
• Experienced in enterprise scale web development, specifically using HTML5 and JavaScript frameworks (jQuery / Knockout etc.)

Desirable:

• Consultancy experience

Scott Logic offers a highly competitive salary and benefits package, including:

• Bonus scheme
• 25 days holiday per year, growing with length of service up to 30 days
• Life assurance
• Childcare vouchers
• Cycle to Work Scheme
• Professional development opportunities

In addition, we can offer the following:

• Occasional travel to clients in London, New York and Europe
• A wide variety of technologies and platforms including web and mobile
• The opportunity to work with some of the best developers in the region

A CV and covering letter specifying your area of expertise,  interest and preferred location, along with your salary expectations, should be sent to applications@scottlogic.co.uk

Getting Started

The changes are targeted for the 2.3.0 release which means the only way of working with them currently (official npm package due soon) is to checkout the project from GitHub and build it yourself, luckily this is a relatively painless experience if you have git setup -

git clone git://github.com/SteveSanderson/knockout.git
cd knockout
./build/build.sh

The output files are located in the build/output folder, knockout-latest-debug.js is the one you’ll want for Node, unless you have a strange compulsion for minified code! Let’s quickly put together a hello world example based on the example from the Knockout website -

var ko = require('build/output/knockout-latest.debug.js');
 
// Here's my data model
var ViewModel = function(first, last) {
  this.firstName = ko.observable(first);
  this.lastName = ko.observable(last);
 
  this.fullName = ko.computed(function() {
    // Knockout tracks dependencies automatically. It knows that fullName depends on firstName and lastName, because these get called when evaluating fullName.
    return this.firstName() + " " + this.lastName();
  }, this);
};
 
// create an instance of the ViewModel
var vm = new ViewModel('Planet', 'Earth');
// subscribe to fullName changes
var subscription = vm.fullName.subscribe(function(value) {
  console.log(value);
});
// log the current value
console.log(vm.fullName());
// trigger a change
vm.lastName('Mars');
// dispose of the subscription
subscription.dispose();

Sticking the above in a file (hello-world.js) in the root of the knockout project and then running it through Node (node hello-world.js) gives us -

Planet Earth
Planet Mars

So far so good but that’s a lot of boilerplate code, what’s happened to ko.applyBindings and the corresponding template? Well at this point it’s worth going back and reviewing the spec runner for Node to get a better idea of exactly which bits of Knockout are expected to work.

What works? What doesn’t?

The following table lists the test specs for Node, taken from spec/runner.node.js, against the Knockout methods they exercise -

There’s a lot of observable related goodness there but glaring omissions around the DOM and templating functionality, which means no ko.applyBindings. However, taking a step back, you’ll probably have noticed that there isn’t much of a UI layer to Node, so even if those methods were there, what would they do?

Philosophy aside, where does this leave us? What can we do now that we couldn’t do previously?

Faster view model testing

As long as your view models aren’t making any direct use of the DOM or templating functionality, then you can now run your test specs through Node instead of something like Phantom.js. Your milage will vary but in the case of the Knockout test cases, the Node test specs run in a quarter of the time (0.5s) of the Phantom test specs (2s).

This isn’t a perfect example as the only a subset of the Phantom test specs are run by Node but in this case it does make enough of a difference to mean that the tests could now comfortably be run by a file-system watcher.

Potential to integrate with non-browser, JavaScript powered UIs

This was my original aim when making these changes, in my case it was to re-use the view models from an HTML5 app in a Titanium app. I ended up hacking a fake DOM in to keep the old code happy but if I were to try it again now, I could just include vanilla Knockout.

As well as simply being able to use Knockout, I hope that these changes will encourage people to create their own templating system for the non-browser UI elements, which in turn will make it even easier to use Knockout.

Crazy, pointless, Node-based view model fun!

Let’s say we create a view model like this -

var viewModel = {
  ticks: ko.observable(0),
  tick: function() {
    this.ticks(this.ticks() + 1);
  },
  bars: []
};
 
function createBar(index, count) {
  return ko.computed(function() {
    var a = viewModel.ticks() % ((count - 1) * 2);
    var b = Math.abs(a - count + 1);
    var c = Math.abs(index - b);
    var d = c / count;
    var e = 1 - d;
    return (e * e * e).toFixed(3);
  });
}
 
for (var index = 0, count = 6; index < count; index++) {
  viewModel.bars[index] = createBar(index, count);
}

Then combine it with an npm module called johnny-five and a bit of view binding code -

var five = require("johnny-five");
 
new five.Board().on('ready', function() {
  [3, 5, 6, 9, 10, 11].forEach(function(pin, index) {
    var led = new five.Led(pin);
    viewModel.bars[index].subscribe(function(value) {
      led.brightness(Math.round(value * 255));
    });
  });
 
  setInterval(function() {
    viewModel.tick();
   }, 100);
 
});

Finally, attach an arduino and what do you get?

The worlds first KnightRider LED effect powered by a Knockout view model (I think)! If anyone fancies making their own, the code is all available on GitHub

Tweet