Fun with english words

In this post, I explain how I made the program “SubWordsFinder” that takes a string, and finds all real English words that contain that string, then removes the string from the match, and sees if the remaining characters form a real English word or not.

It started with me stumbling across the following “truism” on Facebook the other day:

My first thought was “gee, these guys have too much time on their hands. My second thought was: “Hmm, maybe I can do that as well?”

i.e. if I run SubWordsFinder tea, I expect the results to include:
”protease –> prose”

and SubWordsFinder ox should include
”toxic –> tic”

Finding all the words

So I started to search for “all English words download” on Bing and quickly found The English Open Word List (EOWL), which I then downloaded and extracted into a folder:
The ZIP file included all English words in both a CSV format as well as LF separated entries in a series of textfiles. I chose to attack the latter, and leave the CSV format alone.

Loading the files

I opted to create class WordsFinder that takes the path to the folder containing all the text files as its input:

Next, I created a LoadWords() method that loads all the files in parallel. I used a ConcurrentDictionary<string, IEnumerable<string>> in order to be able to work in parallel and not having to worry about locking issuesNyah-Nyah:
I did however, need to lock the variable finalWordCount in order to avoid writing to it from two separate threads.

Finding the SubString

Next challenge was to identify all words containing the substring that I was after. Turns out, this was really easy as well. Because I had split all the  words into a dictionary where the first letter of the word is the key, and because I had them all in a ConcurrentDictionary, I could parallelize the search to make it blazing fast:
Again, using Concurrent collections makes writing to them thread-safe, so a ConcurrentBag is where I stored all my matches. In my main program, I store all matches in the variable wordsContainingMatch.

Ok, so now I have a way of finding all words in the English dictionary that contains any substring. Next up is to remove that substring from the match:

The idea here is simply to create pairs of words containing the substring, and the corresponding suggestion for a word without it. These aren’t yet verified as English words, they’re simply strings with that substring removed. You can see that the form of the words is a string with a colon ‘:’ where the original match is on the left, and the suggested word without that match is on the right.

Last piece of the puzzle

With this new collection, wordsWithMatchRemoved, It was simply a matter of figuring out if the right side of the colon is a real English word or not, by checking against our dictionary:
I extract the string to the right of the colon, and see if that string exists in my dictionary using the Contains method:

As long as the string exists as an English word, it is added to the collection actualWordsWithMatchRemoved. I know, I could probably come up with better names…

Running it

Putting this all together in a running console application, I added a few System.Diagnostics.Stopwatch instances to time the program. Here’s running against the string PI:

Searching for lad gave me these:


So I could say “If you take the lad away from the paladin, you’ll end up with pain

I know, weird humor. But a fun way to spend 50 minutes on a saturday morning.

Contact me if you want the full source code, it’s so ugly that I’m not going to post it on github Smile



How is my plant doing, really?

I figured it’s time to post some pictures of my plant project at the same time that I’m trying our Word 2016‘s WordPress feature J

So, here’s Benjamin, or “Benny” as I’m calling him:

You can clearly see how healthy he looks? No wonder! Benny is now in control of his life! He does it all from turning on his growth-light, to turning the moisturizer on and off on dry days!

The soil moisture sensor keeps Benny happy. It lets him regulate the watering, and reports back to me when it’s time for a drink. Right now, the water pump is in house, and the relay that controls it is connected, however, I’m still searching for a transparent tube (esthetics matter!)

The light was a bit tricky. See, turning the light on and off isn’t really a big deal, but getting the light sensor to understand where the light is coming from required some smart thinking. It’d turn on the light at 6am, and then turn it off again 5 minutes later, because the light sensor was telling Benny “Hey, there’s enough light here, turn off the light!” – Benny doesn’t know the difference between sunlight and artificial light. I ended up moving the sensor to the back of my electronics panel, so that it is now facing the window directly, and not at all hit by the light from the growth lamp. Success!

Above you see some of the hardcore electronics. It’s all .Net Gadgeteer by GHI Electronics which allows me to skip soldering altogether. The modules that are connected together are:

  • Mainboard: the Hydra Mainboard
  • Power Relay (the red thing with the light on it)
  • Ethernet Connection (because I’m dead cheap, and didn’t want to spend more on a Wi-Fi Adapter)
  • A 16-character display
  • An earth moisture Sensor (in the soil)
  • An Air humidity and temperature sensor
  • Light Sensor (on the back)
  • 3 power Relays to regulate the water pump, the air humidifier, and the growth lamp
  • On the back, the triangular alien-looking thing is my Asus wireless Access point

At the time I write this blog entry, I’ve gathered over 12 000 readings, in intervals of 5 minutes. Benny takes a new reading every single second, but averages it against the previous one for up to five minutes before he submits the average of those 300 readings to an Azure Table. Table storage in Azure is dirt cheap. Those 12 000 readings aren’t costing me anything so far (bout 1-2 kroner MAYBE). It is by far the cheapest data store I’ve ever used. I plan to use these in Machine learning once I have a full year or so of readings.

So there you have it, some images and updates around Benny and I J


Oh, and if you’d like to see the live data, don’t hesitate to hop in to Benny’s webpage:


Light regulation is now active

DSC_5256Apologies for the long absence of information regarding my Plant watering project

Today I hung up a lamp above my plant in order to provide it with enough light as the Norwegian summer goes over to fall/winter.

The process required only a programmable relay (the RelayX1 from GHI Electronics, which is a simple on/off switch controllable from my Fez Hydra mainboard.

The intent, of course, is to preserve bulb life and energy by only providing enough light when the outside light from the window is insufficient. The plant, a ficus benjamina, requires a solid 15 hours of light every day to be happy, and with this, I’ve ensured that as far as light goes, it will smile all year round!





Image: The bulb is nice looking on the cheap-o lamp housing that I got for it


Image: The RelayX1 is the blue box in the middle of the picture that regulates the light on/off

Rules for turning the light on/off

The time frame the light bulb operates in is between 06:00 and 21:00 (15 hours). The following rules/pseudo code are then applied every second:

  1. Outside of the time frame (21:00 – 06:00)
    1. If the lamp is on, then turn it off immediately
    2. If the lamp is already off, then do nothing
  2. Inside the time frame (06:00 – 21:00)
    1. When the amount of lux is below our threshold and the lamp is off,  only then do we turn it on
    2. If the lamp has been on for at least one hour, and there is now sufficient light coming in through the window, then turn it off, otherwise, keep it on.


DSC_5252As advised on the light bulb documentation, I’ve placed the lamp around 0.5m from the top of the plant, as you can see on the image.

You can check out the values that my plant is emitting at the following url:

The site should be semi-responsive!

Temporary file download links in Azure Storage

Lets say that you have a project in which you want to make files available in Azure Storage for a limited amount of time. This is not only possible, it’s super simple! Here’s how you do it:

First, make something that will connect you to your Azure Storage Account:


The image above shows my class AttachedFileRepository and it’s constructor, where we do the regular stuff of connecting to a CloudBlobClient, which is the object that represent that class’s state.


Next, provide a time-limited download URL in the method:


The magic, of course, happens in the method GetContainerSharedAccessUri:


Basically, what I’m doing there, is to create a SharedAccessBlobPolicy object where I set the expiration time of the policy and limit the access to the blob to read only.

Once the policy is created, I can create a “Shared Access Signature” using that policy that will provide access to the blob even though it is in a private container, and the blob itself is marked as private.

Appending the sharedAccessSignature to the blob URI is all it takes to open up that blob for download for the set time. Ingenious!


If you need to protect your files, and grant access only to paying customers, then this will provide the customer with a time-bombed download URL. You could, for example, allow 2 minutes download link.

Another scenario is provding download links to only authenticated users, for example a class that wants access to some class-related files, must be logged on to get the list of files. If they attempt to publish the download link to someone else, that link will only be valid for the time that you’ve set.

Repono historicae mensuras

(Storage of historical measurements)

Summary / TL;DR

This is the third post in the WaterMyPlants project. The first post, which describes the project in some detail is here. The second, about collecting weather measurements is here.

This time, I speak about how quickly one can set up a database using windows Azure, and how the interface used to store and retrieve data with is a core domain component, and at the same time, the implementation of that interface is a detail that belongs in the data layer.


It has been a while since the last post, this is mostly to do with a small setback in my project. The mainboard that I had started with (the Fez Hydra) turns out to be an open source mainboard that does not support all the modules from GHI, among them, the WiFi RS21 Module, which is essential to my project – I need my plant to be able to connect to the web services in the cloud directly, and not via a computer in my home. Doing so would just be introducing another point of failure.

Image 1: My desk at home. I run Synergy between all 3 desktops, so that I only have to use the center mouse & keyboard for 99% of all my inputs.

Saving the measurements in SQL Azure

There will come no good out of this project unless I am able to store the data somewhere, so for the third part in this series, I wanted to expose my thinking around that.

Creating the database

09.06Setting up a database in windows Azure is a matter of logging on to the Azure portal, then select the SQL Databases. For this project, I went with all defaults: new database –> Sql database –> Quick Create and chose my database name WaterMyPlantsDb.

  1. One of the first things that you’ll want to do once the database has been created is to allow your home network access through the windows Azure SQL server firewall. By default, all external IP addresses are blocked until you’ve explicitly allowed access.


After that, you’re nearly done, just grab the connection string by clicking on the “View SQL Database Connection strings” from the database page, and you’re set to go. Notice that the connection string does not contain the password that you chose for the database.




Specification first – Always!

The act of storing and reading to/from a database should never matter to the logic of your program, those are application boundaries that your main logic should not care about. In other words, if my logic requires a measurement to be stored, then that is what is going to happen – where and how is not the concern of our domain logic: 

Image 3: Writing my specifications in gherkin syntax makes it easy to automate. Notice the lack of mentioning of specific technologies.

I already have WeatherMeasurement as an entity in my project, so all I need is to “discover” my new Interface, and then implement it. The gherkin above is tied to the following code:

09.06 - bdd
Image 4: Implementation of the specification leads to the discovery of the required objects and methods

The interface IMeasurementStorage does not exist in my solution yet. Neither does the method Add() or the property Newest, however, once I write these, the system will have an implementation of the contract that should be working with the SQL database. Notice also how I extended the WeatherMeasurement with a Note property. This was to differentiate two otherwise equal measurements, and to make test data unique by setting a random GUID as the note.

Also note that I did not decorate the interface with methods that I do not need. The specification drove forth one property and one method, and those are the only items that I am interested in implementing. Doing anything more than that would be gold-plating the code; another malpractice often seen in various projects. Embrace YAGNI – That is solid advice.

Image 5: The discovered interface is a vital part of the domain

This interface is a core component in my domain, however the implementation is highly Sql Server specific, and belongs in the data layer. Since this is the first class that uses Sql server, a new pair of projects need to be added to the solution:

Image 6: We now have somewhere to put all our Sql-server IO classes

The implementation from here on, is strictly TDD. I specify / implement in micro-steps following the same pattern as described in previous blogs. I will be posting about the use of Entity Framework and code-first approach in my next post.

A story about the weather

This is the second blog post of my project WaterMyPlants. You can find the first blog post here


This time, I just wanted to share a little about the process of going through one task in TFS from the very beginning until the task was pegged “done” – all using BDD and TDD, of course – there is no other way!

Image 1: The task for Collecting weather data from is now resolved

Since I am the only developer on this project, and also project owner, the project architect, and project code monkey, my scrum board tends to look like the teeth of a shark. My backlog is wafer-thin, and the user stories often come about AFTER the tasks have been described. Normally, you would have a well-defined backlog of user stories and for each sprint, a set of tasks for every user story planned.

User Story and Scenario

In order to know where to start, I always and without exception define scenarios for the task at hand based on the user story. This time, the story was about collecting wetaher data from an external source – I do not own a weather station, so the next-best thing is to grab the weather from a trusted source: 

The user story

Feature: There is a component that can retrieve weather information from

	As a system developer
	I can obtain information about the local weather from
	So that I can find patterns between plant thirst and outside weather
@task61 @performsIO
Scenario: The component retrieves data from based on provided GPS location
	Given that the system has implemented weather retrieval component for Yr.No
	When I ask the system to retrieve weather data for my gps position
	Then the system responds with some arbitrary weather data

Code: User story 62 is about getting weather information from an external source

The tag performsIO needs some explanation: What it does is basically tell SpecFlow to use a runtime configuration prior to running this scenario. I use Structuremap as my IoC container to keep things simple.

public void BeforeMockedEnpointsScenarios()
	ObjectFactory.Initialize(init => init.AddRegistry(new WebRuntimeRegistry()));	
I usually have one “real” registry that I provide the applications with, and one registry 
where all the IO performing classes are replaced with mocks.


Implementing the scenario

All that was left to do was to write the code for each scenario step and “discover” 
my components methods: 

[Given(@"that the system has implemented weather retrieval component for Yr\.No")]
public void GivenThatTheSystemHasImplementedWeatherRetrievalComponentForYr_No()
   // No code required for this step

[When(@"I ask the system to retrieve weather data for my gps position")]
public void WhenIAskTheSystemToRetrieveWeatherDataForMyGpsPosition()
    var collector = ObjectFactory.GetInstance<IWeatherCollector>();            
    var measurement = collector.GetWeather(new GpsLocation());
[Then(@"the system responds with some arbitrary weather data")]
public void ThenTheSystemRespondsWithSomeArbitraryWeatherData()
    var weatherMeasurement = ScenarioContext.Current.Get<WeatherMeasurement>();

   // Inspection… 


I often write steps that do not require code. This is simply because I deem the scenario text 
to be a first class citizen, and seeing as it promotes understandability of the system, I 
opt for verbosity.
The GpsLocation class defaults to use the longitude and latitude of my house, which is why it 
only requires instanciation. 
Lastly, the inspection step simply verifies that the values of the weathermeasurement look ok. 
I’ve hidden the implementation details behind the comment “// Inspection”

The Test Driven part

BDD has now driven forth the need for an IWeatherCollector with the method GetWeather(GpsLocation). Additionally, it also specifies that it the collector needs to return some form of WeatherMeasurement class.

It is time to bring out the SOLID principles from the closet and do some test driven work. I will spare you the code details (do email me if you want them), but here are some of the points that I would like to make:

Image 2: Test explorer could use a “document order” sorting option

As you can tell, I am using Roy Osherove’s naming system for my unit tests. Since I see these as micro-specifications, I just love the way these work as fine-grained API documentation for the method I just described. Unfortunately, Visual Studio does not show me the tests in document-order!

This would give the most meaning to anyone looking at the unit-test explorer. A workaroundis to hit the shortcut-key ctrl+m+o between two unit tests in VS2012 to contract all methods:

Image 3: Collapsed view of my unit tests using Roy Osherove’s naming convention

Reading the unit-tests in document-order is, in my view, the best way to understand a method.

TDD is also about discovering contracts

Following the SOLID principles of object-oriented design, it quickly became clear during the implementation of  IWeatherCollector that the Single Responsability Principle drove me to use the following contracts: 

Image 4: Requirements of the WeatherCollector class identified during TDD

Why: The WeatherCollector class is no more than a service class that requests some xml from an external source and then translates that xml into a WeatherMeasurement object. The single responsability of the collector, is simply to combine the result of a reader and pass it along to the proper converter if all looks ok. This could possibly lead to using the name WeatherRepository instead, however, Collector was a term I felt more at ease with. Readability > patterns!

I won’t bother you with the details, but the implementations of the WebReader and Converter followed the same TDD approach – one after the other.

Geen tests lead to green story!

So, with all the specifications (unit-tests) now passing, and no more System.NotImplementedException() I ran SpecFlow to see if I had forgotten anything else:

Image 5: All done from SpecFlow. The user story was implemented as specified

General approach: Once you’re done with all the unit-tests for a method, you should run the user story to see if you have forgotten anything else. In my case, I only had one scenario, but I found out twice that I had to implement WebReader and then IConverter<XElement, WebMeasurement>. If you forget one, the SpecFlow report shines in red, telling you that sometihng is not yet implemented.  
– Do you still wonder why I love BDD?

Image 6: Looking at the details of the scenario; the real output from


In this second post, I wanted to share with you how I use BDD and TDD to drive code:

  • Drag the task to “In progress” on your scrum board
  • Find or create the SpecFlow feature file for the user story that the task belongs to
  • Write one or more scenarios required to deliver that single task
  • Implement the scenario steps and drive forth the interfaces, their methods and objects required by the task. One scenario at the time! Do not implement classes yet, just let the interfaces sit until you’re done writing the scenarios.
  • Once done with one scenario, proceed to implementing the interfaces and objects using TDD
    • Create the classes
    • Implement the methods using TDD
    • Discover additional objects and contracts, but do not implement them before you’re done with the method you’re working on.
  • Every time you’re done with the unit-tests for a method, run a complete SpecFlow report and see if you have more scenarios to implement
    • Implement the missing scenarios, one at the time until report is all green
  • On the scrum board, drag your task from “In progress” to done
  • Pick the next task


Writing this blog post took me far longer than actually doing the steps above. Without the blog post, I would’ve been done within the hour.

Profectus Est!

(It is started!)

Project Water my Plants has begun. This blog post marks the arrival of the first bits of electronics, and provides a simple overview of how the getting started with gadgeteer felt like.

White stripe spider plant
Image 1: The victim: A white stripe spider plant(Chlorophytum comosum ‘Vittatum’)

My box of Gadgeteer devices has arrived. I’ve found a suitable plant to experiment with and all of the software required to get started is now installed in two places (on my desktop and on my laptop (for field experimentation). As you can see from the brown bits, this plant is already suffering, and requires immediate attention of the highest technical quality to survive…

Overview of the project

The project has been set up using Visual Studio 2012 and will be managed by Team foundation Service, which will also function as my source control provider.

 Initial Solution Layout
Figure 1: Overview of project layout

The project structure follows the typical N-layered approach as seen on the image above. Within folder 10.10 (Application/Micro Framework) is where the electronics software are made – the rest of the folders are hosts to the Web page and Web Services. The Specifications folder contains screenshots and some frameworks for running the project in a BDD harness using a combination of SpecFlow and CasperJs 

Getting started with Gadgeteer

Image 2: The Gadgeteer Moisture sensor half buried in the plant soil

Installing the .Net gadgeteer project was straight forward, except for a couple of things:

  • You should install the entire 4.2 SDK, and then upgrade to 4.3
  • There is a Visual Studio 2012 compatible Core + Templates for Gadgeteer that you need to install once you’re done installing the 4.2 stuff, otherwise, you won’t be able to see the Gadgeteer application project types.


    Once installed, creating the project was as easy as adding a new project to the solution, choosing Gadgeteer Application and following the wizard:

    Gadgeteer Wizard
    Image 3: The first page of the wizard asks what type of mainboard you have

    The wizard starts by asking what type of mainboard you have, and then proceeds to create a diagram where the mainboard is visualized. From there, it is as simple as just dragging the components you want from the Toolbox onto the designer, and connecting them by clicking on the gates and drawing a line:

    Gadgeteer Designer in VS2012
    Image 4: Using the designer tool to drag the components and connect them to the board

    Auto-generated code

    Every time you save the designer, the auto-generated partial class Program is updated with the new components and port assignments. The generated code is clean and easy to understand. No cluttering or cryptic names here. The module names are default the same as the module type.

    OGadgeteer Designer Generated Code
    Image 5: Designer-generated code

  • Measure My Plant

    The first batch of electronics to arrive were needed for my first application, MeasureMyPlant.exe which is a device application that is going to do two things:

    1. Take readings of the environment that the plant is in (moisture, light, temperature)
    2. Transmit data over wifi to a cloud service in Azure


    Only part 1 was done in this stage, because I waited with the more expensive WiFi component to get a cheap proof of concept going. It turns out that I should’ve ordered everything at once. The electronics simply worked! Within 5 minutes of typing, I had the following program running on the Hydra board:

    Image 6: My first running program on the hydra board

    Time to order some more stuff!

    I will now proceed with some of the more expensive modules. While I await the arrival of these, I will be working on the website. There may be a blogpost or two about that soon…

    For now, a few more images of the protagonists of this blog post:

    Image 7: The modules used in this blog (click for larger image)

    Image 8: My Fez Hydra mainboard with all the connection ports(click for larger image)

    Geeky meetup with Novanet

    Novanet Doorbell

    I had the pleasure of being invited to a late-night geek meet, hosted Novanet, a consulting company focusing on the Microsoft platform. I was invited to attend the meet by my future collegue in Microsoft, Arif Shafique, something I appreciated greatly.

    The first subject of the evening was held by Anders Nygaard, whom gave an introductory speak about developing Windows modern UI apps using HTML5/JavaScript. He gave some great tips on how to get started, with clear, easy to follow examples along the way.You should follow his “One app each month” blog where he has committed himself to releasing one new app every month on the Microsoft Appstore. If you ever get the chance to attend one of his talks, then you’re in for a treat!

    The second speaker, Einar Engebretsen, gave a very good introduction to Domain-Driven Design. It smoothly transitionined to the open-sourced Bifrost Framework, which focuses on delivering business value through the use of well-established patterns such as CQRS and MVVM. Followhing this speech, I have decided to use this framework in my soon-to-be-announced super-secret “Water my Plants” gadgeteerproject, and and the same time see if I can mend some of the misinterpretations that I have built up around DDD.

    Additionally, Einar also introduced us to another project he is working on; Forseti. Simply put, Forseti is a test runner for most JavaScript test harnesses, and, of course, it’s built in .Net. We only had a couple of examples shown, but they were enough to say that it is way faster than anything I’ve seen so far, compared to standalone Jasmine, Grunt and other runners.

    Einar is the kind of speaker who demonstrates by giving examples, all coding is done live, and as usual accompanied by deep insight and inspiration. Einar is, in short, pure coding awesomeness!

    Once more, thank you, Novanet for a great and geeky meetup!

    Structuremap: Singleton class with multiple interfaces

    In a recent project, I had the need to implement multiple interfaces in a single Repository class

    public class UsageStatisticsRepository : DbContext, IApiKeyCounter, IIpAddresssCounter
    // …

    We use Structuremap as our IoC container, and attempting to configure the two interfaces as Singletons gave us two instances (naturally), once for each interface.

    The solution, was to use the not-so-obvious keyword Forward in order to re-use the Singleton instance for another interface as so:

    public class DigitalDiasRegistry : Registry
        public DigitalDiasRegistry()
            Forward<IApiKeyCounter, IIpAddressValidator>();


    With that, the problem was solved, and only one instance occured. Since I fiddled some time to figure this out, I thought sharing it would help someone else.

    Hett smilefjes

    Using Structuremap to resolve ViewModels

    One of the things I find myself doing over and over again when working in xaml-based applications is to create a ViewModelFactory based on Jeremy D. Miller’s StructureMap.

    All my ViewModel classes are based on a class BaseViewModel:

        public class BaseViewModel : INotifyPropertyChanged

    The fun, of course, begins when your viewmodels need to know about other viewmodels. Lets say, for instance that your main view contains a Container control in which you would like to swap views in. Using structuremap, it is easy to inherit the Registry class in order to stitch together associations between views and models:

    public class ViewModelsRegistry : Registry
        public ViewModelsRegistry()
            Rig<MainWindowView, MainVindowViewModel>(Registered.MainWindow);
            Rig<TrioEventsView, TrioEventsViewModel>(Registered.TrioEvents);
            Rig<NewsContentView, NewsContentViewModel>(Registered.NewsContent);
        private void Rig<TControl, TViewModel>(Registered name) 
            where  TControl : ContentControl where TViewModel : BaseViewModel

    The Registered reference is an enum that I use to keep tabs on what views/viewmodels that are implemented:

        public enum Registered
            Unknown = 0,

    As you can tell, the ViewModelsRegistry uses ContentControl as it’s container type. This makes it  compatible with all derivates, including Window and UserControl.
    Following the factory pattern, the result follows:

    public static class ViewModelFactory
        public static void Initialize(Registry registry)
            ObjectFactory.Configure(o => o.AddRegistry(registry));            
        public static ContentControl Get(Registered name)
            var control = ObjectFactory.GetNamedInstance<ContentControl>(name.ToString());
            control.Loaded += (s, e) => {
                control.DataContext = GetDataContextFor(name);
            return control;
        public static BaseViewModel GetDataContextFor(Registered name)
            return ObjectFactory.GetNamedInstance<BaseViewModel>(name.ToString());

    The ViewModelFactory basically leans on structuremap providing the method Get() that stitches together a view and it’s model. One example of such use:


            public void LoadEvents(object dummy)
            private void SetViewModel(Registered name)
                    _loadedControls.Add(name, ViewModelFactory.Get(name));
                CurrentContent = _loadedControls[name];

    In the above snippet, taken from the MainWindowViewModel,  LoadEvents is bound to a button click on the Main Window. Once clicked, If I haven’t already loaded the control, I use the factory.Get() method to create a UserControl with initalized datacontext, before I finally set the ContentPresenter (CurrentContent) on the Main window viewmodel.

    The factory can easilly be expanded to swap out datacontexts, provide different views. This blog post is mainly about using structuremap to make it happen.

    Jeg bare tøyser