HoloLens and the future of XAML Developers


HoloLens was recently announced to be a first-party member of the Windows 10 operating system. The few Windows developers who have actually maintained faith throughout the Silverlight and Windows Store debacles may actually find comfort in this.

So what is HoloLens?

HoloLens is Microsoft’s augmented-reality device. In other words, it’s a wearable visor that blends real-world objects with virtual ones.

XAML developers can now leverage their skills to build HoloLens applications. These applications can ultimately be constructed as universal-apps to run on all Windows 10 devices (i.e. Xbox, Surface, Windows Phone, etc.). However, writing a universal-app to run all devices requires much effort. As a result, I see the masses abandoning Windows Store App development as we know it and focusing on HoloLens app essentials.

I can imagine several uses for this new experience:

  • Simulation training (cars, planes, tanks, yoga, military)
  • Fitness (Connect with Microsoft Band)
  • Video Games (GTA, Call of Duty)
  • Gambling (Poker, Russian Roulette)
  • Movies (in theatre and at home)
  • Search Engines (videos)
  • Long distance relationships
  • Drones


In conclusion, HoloLens was recently announced to be a first-class member of the Windows 10 experience. It was announced as a wearable visor that blends real-world objects with virtual ones. I’m not sure what the hourly rate for a HoloLens Developer is. It could be $90 / hour, $130, or even $150. I guess a combination of supply, demand, and imagination will define the future for XAML Developers.


An alternative to writing complex queries for entities already in memory


There’s been a couple times where I have struggled to simply pull in data regarding some business entity and its association to other entities without bloating out a class definition for a business object.

Specifically, I was building an inventory system and discovered a pattern for looking up information without being loss in complicated query syntax.

Let’s just call it the Lookup Pattern.

This pattern is a single class that is a container of dictionaries that uses a naming convention for the dictionaries it contains.

The naming convention is the following:


Yes. It’s that simple.


public class Lookup


public Dictionary<string, decimal> StockCodeToTotalSupplyQty { get; set; }

public Dictionary<string, decimal> StockCodeToTotalDemandQty { get; set; }

public Dictionary<string, HashSet<Job>> JobIdToJob { get; set; }

public Dictionary<string, HashSet<Job>> QuoteIdToJobs { get; set; }

public Dictionary<int, HashSet<Job>> DaysRemainingToCompletedJobs { get; set; }

public Dictionary<string, HashSet<string>> StockCodeToStockAlternatives { get; set; }

public void Clear()


. . .




var stockCodeWithAlternatives = new List<string>() { demandRequirements.StockCode };

HashSet<string> alternativeStockCodes = null;
var exists = demandRequirements.Lookup.StockCodeToStockAlternatives.TryGetValue(demandRequirements.StockCode, out alternativeStockCodes);

if (exists)



In conclusion, I have provided a simple pattern for managing potentially complex queries using a simple alternative (i.e. Lookup).

Unit Testing a User Interaction



I have yet to sit-in on a software development user-group presentation on TDD and have the presenter answer my question on the following:

How do I unit test a user interaction (i.e. confirmation dialog)?

This question was answered for me several years ago when I studied Prism. Prism is a WPF framework for building large enterprise applications in which the framework focuses on building applications by using a modular approach.

Anyways, I learned their pattern and practiced my understanding of it using my own implementation.

My solution for providing a unit testable interaction results from the following structures:

·         IConfirmationInteraction

·         ConfirmationInteraction

·         ConfirmationInteractionEventArgs

An Actual Unit Test

        public void Example()
            // Setup
            var viewModel = new ShortageViewModel();
            var dependencies = _mock.Dependencies();

            dependencies.RefreshConfirmation = new ConfirmationInteraction(this, new ConfirmationInteractionEventArgs("some message", "Some Caption"));
            dependencies.RefreshConfirmation.RequestConfirmation += (s, e) => { return MessageBoxResult.Yes; };

            // Test

            var timeBeforeExtendedTimeline = viewModel.LastQueried;
            viewModel.Loaded = false;


            // Verify
            var secondQueryRan = viewModel.LastQueried.Ticks.CompareTo(timeBeforeExtendedTimeline.Ticks) > 0;

Notice how the RequestConfirmation event gives the client the opportunity to handle the actual implementation of the interaction as long as a result is returned.
This is the key element that is required for an interaction to be unit testable.


using System.Windows;

namespace Bizmonger.Patterns
    public delegate MessageBoxResult RequestConfirmationHandler(object sender, ConfirmationInteractionEventArgs e);

    public interface IConfirmationInteraction
        event RequestConfirmationHandler RequestConfirmation;
        MessageBoxResult Confirm();


using System.Windows;

namespace Bizmonger.Patterns
    public class ConfirmationInteraction : IConfirmationInteraction
        #region Events
        public event RequestConfirmationHandler RequestConfirmation;

        #region Members
        object _sender = null;
        ConfirmationInteractionEventArgs _e = null;

        public ConfirmationInteraction(object sender, ConfirmationInteractionEventArgs e)
            _sender = sender;
            _e = e;

        public MessageBoxResult Confirm()
            return RequestConfirmation(_sender, _e);

        public MessageBoxResult Confirm(string message, string caption)
            _e.Message = message;
            _e.Caption = caption;
            return RequestConfirmation(_sender, _e);

Calling Confirm() will launch the user interation.


using System;

namespace Bizmonger.Patterns
    public class ConfirmationInteractionEventArgs : EventArgs
        public ConfirmationInteractionEventArgs() { }

        public ConfirmationInteractionEventArgs(string message, string caption, object parameter = null)
            Message = message;
            Caption = caption;
            Parameter = parameter;

        public string Message { get; set; }
        public string Caption { get; set; }
        public object Parameter { get; set; }

This class provides the context of the message such as text content and a titlebar caption.



In conclusion, I have provided an implementation of the classes required to unit test a user interation. I welcome feedback.

Can a unit test also serve as an integration test?


I provided the following post in which I asked how to write a test once and specify it as a unit test or an integration test. Apparently, people did not like my question based on their teachings of what a unit test is versus an integration test. They have been trained to believe that the code used to write a unit test must be separated from the code used to write an integration test.

Question 1:

If you are unit testing a view-model and you inject a mock as a dependency instead of an object that actually relies on an external system, is it still a unit test?

I would say yes.

Question 2:

If you take that same test and you swap out the mock dependency with a real external system dependency (i.e. SQL Server), is it still a unit test?

I would say no. I would say that what was once a unit test is now a light-weight integration test because it now relies on an external system. The same code is still being exercised. However, we are now relying on an external system to satisfy an objective.


In conclusion, I believe that the code that serves as a unit test can also execute as a light-weight integration test by simply swapping out dependencies that the system-under-test relies on.

Is JavaScript the issue or is it its lack of Tools


I don’t think I have a problem with JavaScript. However, I do have a problem with its productivity. Perhaps the term “productivity” can be overloaded. In my case, it is. When I say “productivity”, I specifically mean the progressive development of a system along with its maintenance effort. Thus when I say maintenance, I am also including the refactoring effort involved. While considering JavaScript within the context of refactoring, perhaps I can view JavaScript as a language that should not be judged based on its lack of refactoring tools.

My Issue

Based on my understanding of JavaScript or lack of, JavaScript is not a proven industrial-grade programming language. What I mean is this language is not used as a tool of choice for the maintenance effort involving millions of lines of code. Air Traffic Control systems are not run on JavaScript. The code that enables a battleship or a commercial airliner to fulfill their critical functions is not written in JavaScript. JavaScript is just not going to be the programming language of choice for mission critical systems that have a significant codebase. Even though the tooling around JavaScript has improved immensely over the past few years, there are still no refactoring tools for this language that compares to the refactoring tools that we have in Visual Studio for C#. For example, you cannot rename a method or property that is referenced many times throughout a codebase having all references update accordingly. This becomes a big issue when you are continuously refining your code base for modularity, naming conventions,  and stub generation.


In conclusion, JavaScript as a programming language may be adequate for most problems. However, the language lacks the refactoring tools that we expect that actually do exist with languages like C#.