William Tulloch

Running MS Orleans in Docker locally

Tue, 20 Aug 2019 02:22:52 +0000

A note for my future self since clearly I forget what I have in the past.

If you have pulled down the Microsoft Orleans Docker sample and then try to run it against the Azure Storage Emulator you may find yourself pulling your hair out wondering why it doesn’t work.

Simply put if you try to use the default Azure Storage Emulator connection string it won’t work because the storage emulator endpoints (http://127.0.0.1:10000-2) are not accessible by default from external networks including the Docker network.

The first time I tackled this I solved it following Rahul Gupta’s article which uses netsh proxy mapping. This solution works but is itself a fair bit of work to set-up and doesn’t persist if you restart your machine.

The second option, which is a lot simpler, is just to replace http://127.0.0.1 with host.docker.internal. so in you code the connection string to the Azure Storage Emulator will be as follows:

const string connectionString = "DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://host.docker.internal:10000/devstoreaccount1;TableEndpoint=http://host.docker.internal:10002/devstoreaccount1;QueueEndpoint=http://host.docker.internal:10001/devstoreaccount1;";

Notes on creating NPM packages"

Wed, 26 Jun 2019 10:22:52 +0000

Call me stupid but I have really struggled with creating NPM packages. Not so much with the actual publishing (I mean how hard is npm publish) but more around how to structure the project, what and how to include/exclude files and folders, et.al.

I think in part it is because the idea of creating a package on occurs to me when I am part way through something I have been hacking on which usually means that project already has too many moving parts and is in no fit state for packaging. Nevertheless I start trawling through the node modules I have installed, reading OSS projects trying to grok what they have done all to just end up in a ball of frustration.

Of course being overly ambitious in what I want to achieve doesn’t help (currently I am trying to write a create- package for npm init) but also, to my way of seeing if you dig into existing packages, there is no single way of structuring them or determining what files to include (do you use, dist or lib folders, should you include src and test, etc).

Now the clouds have cleared. The other night I found this article by Bruno Krebs on the auth0 website: Developing and Publishing an NPM Package. To my mind, as walk through tutorial, this article is the clearest guidance I have come across in regard to setting up and creating NPM packages and worth working through.

Next steps for me. Adapting for working with TypeScript and exploring different CI options (the tutorial uses Travis CI but CircleCI seems to be gaining traction. Also Azure Devops is to be considered).

Blazor - Setting up a JSInterop library using TypeScript

Sun, 30 Sep 2018 10:22:52 +0000

Intro

At some point, if you have been playing around with Blazor, you may consider creating a Blazor JsInterop library. If you create a new Blazor library project (dotnet new blazorlib ) the project assumes you use JavaScript but what if want use TypeScript to write your interop code?

If you look through the Blazor source code will see that is exactly what is being done for the interop libraries where both TypeScript and webpack is being used. What is not immediately obvious is how this being wired together.

The rest of this post is my attempt at documenting how to get this working to save time in the future plus some additional notes around creating JSInterop libraries for Blazor

Getting started

NOTE: This is not of my own making but has been dug out of the Blazor solution (Microsoft.AspNetCore.Blazor.Browser.JS). I just thought it would be worth documenting it since the solution was new to me and would be worth making more visible.

In summary the steps requred are as follows:

initialise npm
import webpack and associated libraries
create a webpack configuration file
Edit the proj file

I am, for the sake of expendency, going to assume that have node and npm installed. I will also assume you have the Blazor pieces installed but if not you will need to install the following:

.NET Core 2.1 SDK (2.1.402 or later).
Visual Studio 2017 (15.8 or later) with the ASP.NET and web development workload selected.
The latest Blazor Language Services extension form the Visual Studio Marketplace
The Blazor templates on the command-line:
dotnet new -i Microsoft.AspNetCore.Blazor.Templates

Create a new Blazor library

There isn’t a Visual Studio template for a Blazor library so to create one you use the dotnet cli: dotnet new blazorlib -o ExampleLibrary

Add node modules

While we are doing command line stuff cd to the library project folder.

First initialise npm
npm init -y

Next install the following node modules:

webpack
wepack-cli
typescript
ts-loader

npm i webpack webpack-cli typescript ts-loader -D

Once that is done open up the project in Visual Studio.

Configuring webpack

Add a new webpack.config.js to the project and use the following as the basic configuration (replacing the entry values).

const path = require('path');
const webpack = require('webpack');

module.exports = (env, args) =>({
    resolve: {
        extensions: ['.ts', '.js']
    },
    devtool: args.mode === 'development' ? 'inline-source-map' : 'none',
    module: {
        rules: [
            {
                test: /\.ts?$/,
                loader: 'ts-loader'
            }
        ]
    },
    entry: {
        "indexedDb.Blazor": './src/InitialiseIndexDbBlazor.ts'
    },
    output: {
        path: path.join(__dirname, '/dist'),
        filename: '[name].js'
    }
});

update the project file

Next open the project file and use the following example has a basic guideline for the changes that need to be made.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
     <TargetFramework>netstandard2.0</TargetFramework>
    <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
    <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
    <DefaultItemExcludes>${DefaultItemExcludes};dist\**;node_modules\**</DefaultItemExcludes>
    <NoWarn>CS2008</NoWarn>

    
     <!--VS's FastUpToDateCheck doesn't consider .ts file changes, so it's necessary to disable it to get incremental builds to work correctly (albeit not as fast as if FastUpToDateCheck did work for them)--> 
    
    <DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Build" Version="0.6.0" />
    <WebpackInputs Include="**\*.ts" Exclude="dist\**;node_modules\**; **\*.d.ts" />
  </ItemGroup>
  
  <Target Name="EnsureNpmRestored" Condition="!Exists('node_modules')">
    <Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
    <Exec Command="npm install" />
  </Target>

  <Target Name="RunWebpack" AfterTargets="ResolveReferences" Inputs="@(WebpackInputs)" Outputs="dist\indexedDb.Blazor.js" DependsOnTargets="EnsureNpmRestored">
    <RemoveDir Directories="dist" />
    <Exec Command="npm run build:debug" Condition="'$(Configuration)' == 'Debug'" />
     <Exec Command="npm run build:production" Condition="'$(Configuration)' != 'Debug'" />
    <ItemGroup>
      <EmbeddedResource Include="dist\**\*.js" LogicalName="blazor:js:%(RecursiveDir)%(Filename)%(Extension)" />
    </ItemGroup>
  </Target>
</Project>

Update npm config.

Finally update the npm config (package.json) and add the following to the script node.

{
  ...
  "scripts": {
    "build:debug": "webpack --mode=development",
    "build:production": "webpack --mode=production"
   
  },
  ...
}

In theory once this is all done running build should generate the JavaScript output.

Compodoc - Documentation for Angular

Fri, 22 Dec 2017 07:22:52 +0000

So sue me

Okay so I am probably a bit a late to the party but just found this library for documenting Angular projects called Compodoc.

In all it took about 15 minutes to get up an running on an existing project. The great thing with it allows you to step back from the code and get a sense of the bigger picture.

Running Angular unit tests in VSTS - PhantomJs is dead to me

Thu, 21 Dec 2017 23:22:52 +0000

Background

A current project I am working on is a hybrid Angular 4 and Asp.NET core 2.0 web application. CI has been set up on Visual Studio Team Services (VSTS) and as part of the build we wanted to run the Angular unit tests (logical really).

Did a bit of research and the recommended approach, in summary, is to install as dev dependencies phantomjs-prebuilt and karma-phantomjs-launcher, configure the karma config to include phantomjs as a browser. Then on VSTS add a new command line task to run angular-cli (ng) with the following arguments:

    test --watch=false --single-run=true --reporters=junit,progress --browsers=PhantomJs

Cool, do an initial build and the test run. But then a couple of days later this happened:

   SyntaxError: Unexpected token 'const'
  at http://localhost:9876/_karma_webpack_/vendor.bundle.js:1318

What the f***!.

After much swearing, comparing commits and experiementation found the problem, PhantomJS only provides Javascript support upto ES5 beyond that it throughs a wobbly.

The solution

The simple solution is to abandon PhantomJS and use Headless Chrome. Here is how it’s done.

install GoogleChrome Puppeteer.

  yarn add puppeteer
  # npm i puppeteer -D

Modify Karma.config.js. add the following line above the module.exports statement

    process.env.CHROME_BIN = require('puppeteer').executablePath();

Update the browser to include ChromeHeadless

    browsers: ['Chrome', 'ChromeHeadless']

To test it locally run the following command.

   ng test --watch=false --single-run=true --reporters=junit,progress --browsers=ChromeHeadless

At this point it should all work.

Now on VSTS, in the build definition (and this assumes you already have a command to run npm install) add a new command line task.

Done! angular unit tests are now running successfully in VSTS.

The final piece is to publish the test results.

Back in the karma.config.js modify or add the jUnitReporter configuration as follows:

 junitReporter:{
      outputDir: '',
      outputFile: 'test-client.xml'
    }

Then in the VSTS build definition add a new Publish Test Results task and complete it has in the screenshot below.

Ruminations on five years presenting at DDD Melbourne

Sun, 17 Aug 2014 10:22:52 +0000

A few weeks ago, along with Aaron Powell, I was recognised for being voted up five years in a row for DDD melbourne. Aaron has already blogged on his experience over those five years 5 Years of DDD Melbourne and not to be out done I thought I would chip in with my two cents worth.

In this post I am going to reflect back on those five years and look at some of the things I have learnt.

##2010 - Code Contracts When the first DDD Melbourne was announced I thought this would be a bit of a hoot so tossed my hat into the ring.

I had over the years done presentations before, including a senate committee hearing once, and in a previous life I had been a musician so I had some familiarity with standing in front of a room full of people and making a fool of myself. A technical presentation in front of your peers though that is a different kettle of fish.

This was around the time that Visual Studio 2010 had just been released and out of some kind of perversity proposed a talk on Code Contracts. To be honest I didn’t think this would get voted up but it did.

For a first-timer the talk went well. I was lucky in my choice of topic; Code Contracts is/was a reasonably self-contained so I avoided the classic first-time presenters trap of running out of presentation time though it was a close run thing.

##2011 - Securing web services (WCF) with WIF I had been an early fan of claims-based identity and in particular working with WIF. At the time I did this talk I had been working at client where I had developed a custom STS to issue SAML tokens for securing WCF services and it was this work that I used for the basis of this talk.

My intention was to take the audience through the entire process; from creating a custom Security Token Service (STS) through to using it to secure a WCF service. In hindsight I probably overreached a little bit on this one and tried to cover too much which meant I ended rushing towards the end. This was a good learning experience through. Some of the keys things that I learnt were:

Don’t be too clever - I invested too much energy creating a back story for my presentation and the “humour” of it was lost on anyone who didn’t know anything about the New York art scene in the 60’s (really doesn’t anyone know about Andy Warhol and The Factory).
Too much code - I ended up writing too much boiler plate code which really didn’t add anything to the talk. Additionally by using code snippets the audience really didn’t get a chance to understand what was happening.

##2012 - What’s new in .NET 4.5 At the time of this talk I was co-authoring a book on .NET 4.5 with two of my colleagues which formed the basis for this talk. This was what I think of as a shopping list presentation.

For this talk I took eight of the key new features in .NET 4.5 and gave a brief rundown on each of them. Again, in hindsight, I think the code examples didn’t always hit the mark. This was in part due to the nature of shopping list talks, since you are essentially jumping from topic to the next without any really story arc. This meant the demo code couldn’t be built up and thus giving the audience a context for the examples which were occasionally a bit laboured.

##2013 - Securing .NET WEB API I was personally very happy with this talk. The story arc and timing all came together. No rushing to get to the end and all the demos made sense and kept the audience engaged.

One of the key things I did this time was to show key code concepts in my slides rather than in Visual Studio. This allowed me to remove any extraneous information and keep the focus on what was important. This also meant that when running the code demos the audience already had some context for what was being shown.

##2014 - Don’t Say F*$k to the Client and other war stories I had been playing around with the idea of doing a non-technical talk for a while and this was the result. The intention had been for a light-hearted talk but as I worked up the stories things took a more serious tone.

Though this was probably the hardest talk I have done, there was no code to hide behind, on a personal level I think it was one of my best and the feedback from the audience was positive.

The hardest part of developing this talk was finding a “voice” for the presentation and I spent a lot of time writing, editing and rejecting stories to discover it.

##In Summary I love presenting. It is challenging, requires work and I would be lying if I didn’t admit to being scared shitless every time I did it but the payoff has always been worth it.

The following is ragtag collection of some of the things I have learnt over the last five years.

Avoid dot points.
Too often I had attended talks where every slide shown was crowded out with dot points. Effect of this is that your audience has to split their focus between what you are saying and reading what is on the screen. My preference is to use slides primary as context markers.
Words are a visual element.
Think of words as images as opposed to text on a page.
Coding in front of an audience is hard
You do it everyday, how hard can it be. Bloody hard, especially when you make a mistake and half the audience are shouting out suggestions.
If you are going to do code examples you really need to plan ahead and keep it concise. Also practice coding standing up, very rarely do you do a talk sitting down. Finally learn to talk while you writing code. There is nothing worse then the silence of an auditorium while you bash away at a keyboard for five minutes. Keep the audience engaged, explain what you are doing.
Giving a talk is entertainment not a form of punishment.
Yes it is a technical talk but that is no reason to be boring.
In the beginning get all your ideas down and then edit ruthlessly.
It is easy to overload a talk with unnecessary detail. When I first start a working on a talk I use a mind map to capture as much as I can and then start shaping the story I want to tell.
Writing demo code takes time.
Give yourself enough time to get it right and always have a fall-back position if you intend to code live in case things don’t go as planned.
Don’t read from your slides, talk to them.
There is nothing more tedious then a presenter who recites word for word the content of their slides. Additionally this means you end up not engaging the audience (see the next point).
Talk to your audience.
When people attend your presentation they are there to hear you talk so do them the courtesy of engaging with them.
You will always be nervous before you present.
I always have this moment, about an hour out from when I have to present, when the weight of stupidity descends. The thing is if you have done the prep it should all fall into place.
Practise your talk.
This is not one of my strong points, let’s face talking aloud to yourself can feel a bit weird. The thing is it doesn’t have to be word perfect but it will help you get the talk’s rhythm. For the last talk I did I practiced my talk by dictating to the computer. This allowed me to practise my delivery as well as fine tune the content.

The ng-include, the $watch and the child scope

Tue, 18 Feb 2014 10:22:52 +0000

“Beware the child scope for it will bite you on the arse”

Even after eight months on a project that is using AngularJS the most I can claim is I know enough to be dangerous and to be lulled into a false sense of security. This false sense of security lead to no small amount of hair-pulling the over day.

The issue I encountered involved a custom directive we have for auto-completing values in a text field. The field itself is used to look-up hospitals. As the user types in a name the directive displays a list of possible matches and when the user selects one it takes the corresponding hospital object and assigns it to a property on the scope that was passed into the directive. A watch is set-up in the scope to listen to the property so that when it changes it extracts values from the hospital object and displays them to the user. To express this is in code, the controller had the following:

var controller = function ($scope, patientReferralService) {
        $scope.selectedPatientHospital = undefined;

        $scope.$watch("selectedPatientHospital", function (newValue, oldValue) {
            // if we have a hospital then populate required values. 
            if (newValue) {
                $scope.referral.Patient.Location.Hospital = newValue.Nickname;
                $scope.referral.Patient.Location.HospitalId = newValue.Id;
                if (newValue.hasOwnProperty("SwitchboardPhone")) {
                    $scope.referral.Patient.Location.SwitchboardNumber = newValue.SwitchboardPhone;
                }
            }
        });
        //rest of code removed for brevity
    };

And the html:

<div>
    <input type="text" data-ng-model="referral.Patient.Location.Hospital" id="inputHospitalName" name="inputHospitalName"
           data-campus-auto-complete="selectedPatientHospital" data-source="campuses"
    />
</div>

All well and good, and this has been working just fine until I decided extract some of the UI into a partial view and add it to the form as an ng-include. Now when I ran the application the $watch was not being fired.

Just to show how much I still have to learn, what I didn’t know is that when you use ng-include (or ng-repeat, ng-include, ng-switch, ng-view, ng-controller) is that Angular creates a new/child scope which prototypically inherits from its parent scope.

This is usually not a problem until you either attempt a 2-way binding on a primitive value defined on the parent or, as in my case, try to add a new instance of an object defined on the parent. The problem is not with Angular but with how prototypical inheritance works in JavaScript.

In essence what happens, why my code no longer worked, is that when you assign a value to a primitive on the child, instead of walking the inheritance tree of the child to find the corresponding property it creates a new property which shadows/hides the parent property.

The solution, once I understood this was fairly simple. Rather than having a property on the parent that the directive changed directly I created an object that would have properties that could assigned to and watched. The modified code looks something like this:

var controller = function ($scope, patientReferralService) {
$scope.thingsToWatch = {
    selectedPatientHospital: undefined,
    selectedPlannedDestinationSite: undefined
};
$scope.$watch("thingsToWatch.selectedPatientHospital", function (newValue, oldValue) {
    // if we have a hospital then populate required values. 
    if (newValue) {
        $scope.referral.Patient.Location.Hospital = newValue.Nickname;
        $scope.referral.Patient.Location.HospitalId = newValue.Id;
        if (newValue.hasOwnProperty("SwitchboardPhone")) {
            $scope.referral.Patient.Location.SwitchboardNumber = newValue.SwitchboardPhone;
        }
    }
});
//rest of code removed for brevity
};

<div>
    <input type="text" data-ng-model="referral.Patient.Location.Hospital" id="inputHospitalName" name="inputHospitalName"
data-campus-auto-complete="thingsToWatch.selectedPatientHospital" data-source="campuses"/>
</div>

If you want a more in-depth explantation of the problem, I found this article really helpful Understanding Scopes.

Weird shit with WebAPI, Basic Authentication & Session Authentication Modules

Wed, 12 Feb 2014 10:22:52 +0000

On a current client’s site we have the following:

A custom login REST service endpoint that allows the passing in of a username and password using basic authentication and issue a Json Web Token (JWT).
Another REST service to update data. This requires the JWT to be passed in with the call as a Bearer token in the Authorization header.

Within the web application itself this has been working fine XHR and adding the Authorization header with the appropriate value where required.

This has all been working fine.

Recently the client has requested that their clients would like to have the ability to update data from their own systems rather than entering it through the website. Fine, not a problem since the REST services already exist. I thought I would knock up a quick proof of concept just (as a console app) to confirm that all works as expected and to provide guidance for external users.

Now I have done this numerous times and here is a sample of the code:

	
private static TokenResponse GetAuthenticationToken(HttpClient client, 
        Uri loginUri)
{
    var encoding = Encoding.GetEncoding("iso-8859-1");
    TokenResponse tokenResponse = null;
    var authHeader = new AuthenticationHeaderValue(
    "Basic", 
    Convert.ToBase64String(
    encoding.GetBytes(
        string.Format("{0}:{1}", "testUser", "somepassword"))));

    client.DefaultRequestHeaders.Authorization = authHeader;
    client.DefaultRequestHeaders.Accept.ParseAdd("application/json");

    var result = client.GetAsync(loginUri).Result;

    if (result.IsSuccessStatusCode)
    {
        var response = result.Content.ReadAsStringAsync().Result;

        tokenResponse = 
        JsonConvert.DeserializeObject<TokenResponse>(response);
    }
    else
    {
        Console.WriteLine(result.StatusCode);
    }
    return tokenResponse;
}

Thing is every time I ran it the call to the login endpoint returned a 401. Okay clearly I am doing some wrong. Fire up Fiddler and check the header. Nope all good I have an Authorization header. Okay next debug into the delegating handler that handles the basic authentication. Inspect the request header and I have no Authorization header. Somewhere between making the call and hitting the delegating handler the Authorization header has been nuked.

As you could appreciate this is a little disconcerting and after a few hours of exploration and hair pulling downright frustrating. And then I noticed this in the web.config.

<add name="SessionAuthenticationModule" 
     type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

Hmmm at some point we must have playing around with the idea of using WIF for our authentication. Surely that can’t be causing the problem but with nothing to lose at this point I decided to comment it out. Ran my test app and it all worked.

Now why this was nuking my Authorization header I am not sure. I have debugged into the class but can’t Identity where it is doing it but removing it has fixed the problem so I am going to leave it at.

Note to self: remember to removed unneeded settings from the web.config

Unit testing aynomous types

Sat, 01 Feb 2014 10:22:52 +0000

A colleague had a case where he needed to test the values assigned in an anonymous type returned by a class. With anyonmous types the .Equals() behaves a little a differently from typed objects. To paraphrase MSDN if, within the same assembly, two or more anonymous object initialisers define a sequence of properties that are equal in sequence, name and type the compiler treats them as instances of the same type. For example if we wrote the following test you would find it will pass.

[Fact]
public void CompareTwoAnonymousTypes()
{
    var expected = new  { FirstName = "John", LastName = "Cale" };
    var actual = new  { FirstName = "John", LastName = "Cale" };
    
    Assert.Equal(expected, actual);
}

On the other hand if we swapped the properties around on one of the initialisers the test would fail (in fact it would raise a compiler error).

   
[Fact]
public void CompareTwoAnonymousTypesWithDifferentPropertySequence()
{
    var expected = new { LastName = "Cale",FirstName = "John" };
    var actual = new { FirstName = "John", LastName = "Cale" };

    Assert.Equal(expected, actual);
}

But this not the real issue. As started previously, anonymous must be in the same assembly for them to be considered the same type. Given we have the following class in another assembly:

    
public class TestClass
{
    public object GetAnonymousType()
    {
        return new {  FirstName = "Lou", LastName = "Reed" };
    }
}

any attempt to validate the return value in a unit test will fail.

So what the solution?

A great tool for testing two instances of a given class to ensure that their property values are equal is FluentAssertions. FluentAssertions has a method called ShouldBeEquivalentTo() which does an object graph comparison. For example:

[Fact]
public void CompareTwoInstanceOfPerson()
{
    var expected = new Person{FirstName = "James", LastName = "Brown"};
    var actual = new Person{FirstName = "James", LastName = "Brown"};

    actual.ShouldBeEquivalentTo(expected);
}

This also works for comparing two different classes that have the same properties such as comparing a dto with the source of the data.

  
[Fact]
public void PersonDtoShouldEqualPerson()
{
    var person = new Person {FirstName = "Lou", LastName = "Reed"};
    var personDto = new PersonDto { FirstName = "Lou", 
    LastName = "Reed" };

    personDto.ShouldBeEquivalentTo(person);
}

So does this help with my colleague’s problem? Will yes it does but with one twist. By convention, with unit tests, we test the actual value against the expected value. For example actual.ShouldBeEquivalentTo(expected). When evaluating anonymous types we need to flip it around and test the expected value.

[Fact]
public void ObjectShouldBeEquivalentToReturnValue()
{
    var tester = new TestClass();

    var expected = new {FirstName = "Ted", LastName = "Dancer"};

    var actual = tester.GetAnonymousType();

    expected.ShouldBeEquivalentTo(actual);
}