‘HTML Application with TypeScript’ Project Template for Visual Studio 2017


In Visual Studio 2015 there was a project template for building HTML applications with TypeScript. It was called, predictably, ‘HTML Application with TypeScript’.

The Visual Studio team have removed this template in Visual Studio 2017. I can see why. It contains some code that shows the time, ticking, in your default web browser when you start it. That isn’t really a ‘template’. The first thing you’re going to do is delete the code to show the timer.

Also it had some quirks. It used the ASP.NET C# templates as a jumping-off point. This is fine: it gives you stuff like pre- and post-build events that the other TypeScript project types don’t have, and the ability to configure IIS Express or another web server in the project properties. However, it insisted on building an (empty) C# library on every build that then wasn’t used for anything. This always seemed a bit odd.

Having said all that I used it quite a lot, mainly for test and play examples. Configuring a project to test TypeScript for an HTML application is not particularly easy. This template did it all for you, including making it ridiculously easy to include webpack so you could bundle multiple files using external module syntax. I may write about this separately.

The Template Resurrected

So having done some work with Visual Studio add-ins last week I thought I’d resurrect this project template. It’s now available as a Visual Studio Template Extension, both from Visual Studio Marketplace and under Tools/Extensions and Updates in Visual Studio 2017 itself. Search for ‘TypeScript HTML Application Template’.

It works exactly as the old one did.  When started with F5 it will start a web server, by default IIS Express, and show a ticking time in the selected web browser.  The code to show the time is in a TypeScript class.  If the browser is Internet Explorer or Chrome the code will break at breakpoints directly in Visual Studio, and the usual Visual Studio debug tools and windows will be available.  Note that if you are using Chrome you may need to hit refresh in the browser for breakpoints in startup code to be hit.


Debugging JavaScript/TypeScript Using Visual Studio 2017 and Chrome


One of the great new features of Visual Studio 2017 is that you can debug JavaScript and TypeScript directly in the Visual Studio IDE if they are running in Google”s Chrome browser.  We’ve been able to do this with Internet Explorer and Visual Studio for some time, but of course Internet Explorer is old and has been superseded by Microsoft’s Edge browser.  Edge does not support Visual Studio debugging.

Debugging with Visual Studio is a nice alternative to the context switch involved in using Chrome’s own debug tools.  All of the Visual Studio debug windows are available: Locals, Watches, Call Stack, and the Immediate Window all work.

The problem is it can seem a little difficult to get it working the first time.  This article is an attempt at a step-by-step guide to create a very simple program that works.

Making It Work

Here are the steps to set up a simple program that will break in debug on all my machines:

    • Start VS2017 and create an ASP.NET project (‘ASP.NET Web Application (.Net Framework)’). On the next screen select the ‘Empty’ template.
    • Add an index.html file. Paste the code below into it.
<!DOCTYPE html>
    <meta charset="utf-8" />
    <button type="button" onclick="helloFunction()">Say Hello</button>
        console.log("In script");
        function helloFunction() {
            console.log("In helloFunction");
        window.onload = function () {
            console.log("In window.onload");
  • Put breakpoints on the three console.logs either by clicking on the lines and hitting F9, or by clicking in the margin on the left hand side
  • Select ‘Chrome’ in the debug dropdown in the toolbar, and hit F5 or click the green arrow.
  • RELOAD THE PAGE by hitting ctrl-F5 or the clicking the reload page icon in the browser address bar.  This is the catch: the steps above will bring up the page and show the button, but they WON’T immediately hit the breakpoints on an initial page load.  You need to reload the page in the browser.  Note that this is different from debugging with Internet Explorer from Visual Studio, which will hit the startup breakpoints immediately.
  • The first breakpoint should be hit and Visual Studio will break in debug.

Once the breakpoints are hit you can use Visual Studio’s usual debug tools, single step (F10/F11), continue and hit the next breakpoint (F5), add new breakpoints, use the other debug windows etc.  If you click the button any breakpoint in the button event handler will be hit.

This also works if you create a JavaScript (.js) file and put the code into it (and reference it from the HTML), or if you create a TypeScript (.ts) file and put TypeScript code in it (and reference it from the HTML).

Problems and Possible Solutions

Note that you CAN’T debug with Visual Studio and Chrome’s own debug tools simultaneously.  It’s one or the other.  If you bring up the Chrome tools window by hitting F12 you are going to disable the Visual Studio debug session.

As I mentioned, the steps above work on all my computers.  I’m running Visual Studio 2017 Community Edition and Windows 10 as a standard user.  However, if the breakpoints are not hit some Stack Overflow answers are suggesting some things to try:

  • Run Visual Studio as an Administrator.
  • Disable JavaScript debugging in Visual Studio, build and run, then enable it again. The setting is at Tools/Options/Debugging/’Enable JavaScript debugging for ASP.NET (Chrome and IE)’. The option is about half way down a long list, and not easy to find.

Connecting to Tibco EMS from a C# Client


This is a slightly esoteric post, but hopefully it will be of use somewhere.  Below is some reasonably simple code that shows the basic use cases for connecting to a Tibco EMS Server topic from a C# client using Tibco’s TIBCO.EMS.dll.

It actually points at a locally installed instance of EMS.  That is, the server code is running on the workstation.  If you have the Windows EMS installation you can just install it in the default path and the instructions below should work.  Alternatively it’s relatively simple to change the server name from ‘localhost’ and put a username and password in the code to connect to a secure EMS Server.

How to Use the Code

  • Get hold of the Windows Tibco EMS install, and install it on your workstation on the default path.  Note that Tibco do NOT provide this for free: you need to have paid them for a licence.  If you work for a large organization you will probably find you already have a licence.
  • Create a C# console application called ‘TestEMS’, and reference TIBCO.EMS.dll (the C# EMS assembly) from the install.
  • Paste in the code below.
  • Run the code.  You should see a console window showing that a message has been sent by a publisher and received by a subscriber.

If you want to connect to an existing EMS server in your organization all you need is the TIBCO.EMS.dll assembly, not a full client install. You need to change the appropriate parts of the code below to point to the server: change ‘localhost’ to the server name, and add a username and password if they are needed.  Obviously you don’t need to start the server locally if you do this.

What the Sample Does

As you can see, the code starts the local EMS server, then creates a topic publisher and a subscriber to the same topic.  It then sends a ‘Hello World’ message using the publisher.  The subscriber’s message handler prints out the message to the console when it receives it.

The sample code is slightly more sophisticated than the most basic use case.  It also shows how to set a property on a message, and then to how filter the subscription using a message selector based on the property.  The message is sent with an additional property of ‘Owner’ with value ‘Rich Newman’.  The subscriber is only listening for messages with an Owner property that contains the string ‘Rich Newman’.  You can see this if you change the name of the owner in the message that’s sent: the message listener will not get the message.


using System;
using System.Diagnostics;
using System.Threading;
using TIBCO.EMS;

namespace TestEMS
    class Program
        static void Main(string[] args)
            Console.WriteLine("Test started");
            new Program().Run();

        private void Run()
            CreateClientTopicSubscriber("Owner LIKE '%Rich Newman%'"); // Pass "" for no message selector
            EMSServerPublishThisMessage("Hello World""Owner""Rich Newman");

        #region EMS Server
        private const string tibcoEMSPath = @"C:\tibco\ems\5.0\bin\";
        private readonly string tibcoEMSExecutable = tibcoEMSPath + "tibemsd.exe";
        private Process tibcoEMSProcess;
        public void StartEMSServer()
            tibcoEMSProcess = new Process();
            ProcessStartInfo processStartInfo = new ProcessStartInfo(tibcoEMSExecutable);
            tibcoEMSProcess.StartInfo = processStartInfo;
            processStartInfo.WorkingDirectory = tibcoEMSPath;
            bool started = tibcoEMSProcess.Start();

        TopicConnection publisherConnection;
        TopicSession publisherSession;
        TopicPublisher emsServerPublisher;
        private void CreateEMSServerTopicPublisher()
            TopicConnectionFactory factory = new TIBCO.EMS.TopicConnectionFactory("localhost");
            publisherConnection = factory.CreateTopicConnection(""""); // Username, password
            publisherSession = publisherConnection.CreateTopicSession(falseSession.AUTO_ACKNOWLEDGE);
            Topic generalTopic = publisherSession.CreateTopic("GeneralTopic");
            emsServerPublisher = publisherSession.CreatePublisher(generalTopic);


        internal void EMSServerPublishThisMessage(string messagestring propertyNamestring propertyValue)
            TextMessage textMessage = publisherSession.CreateTextMessage();
            textMessage.Text = message;
            Console.WriteLine("EMS Publisher published message: " + message);


        #region EMS Client
        TopicConnection subscriberConnection;
        TopicSession subscriberSession;
        private void CreateClientTopicSubscriber(string messageSelector)
            TopicConnectionFactory factory = new TIBCO.EMS.TopicConnectionFactory("localhost");
            subscriberConnection = factory.CreateTopicConnection("""");  // Username, password
            subscriberSession = subscriberConnection.CreateTopicSession(falseSession.AUTO_ACKNOWLEDGE);
            Topic clientTopic = subscriberSession.CreateTopic("GeneralTopic");
            TopicSubscriber clientTopicSubscriber = subscriberSession.CreateSubscriber(clientTopicmessageSelectortrue);
            clientTopicSubscriber.MessageHandler += new EMSMessageHandler(test_MessageHandler);

        void test_MessageHandler(object senderEMSMessageEventArgs args)
            Console.WriteLine("EMS Client received message: " + args.Message.ToString());


Asynchronous Programming in .Net: Async and Await for Beginners


There are several ways of doing asynchronous programming in .Net.  Visual Studio 2012 introduces a new approach using the ‘await’ and ‘async’ keywords.  These tell the compiler to construct task continuations in quite an unusual way.

I found them quite difficult to understand using the Microsoft documentation, which annoyingly keeps saying how easy they are.

This series of articles is intended to give a quick recap of some previous approaches to asynchronous programming to give us some context, and then to give a quick and hopefully easy introduction to the new keywords


By far the easiest way to get to grips with the new keywords is by seeing an example.  For this initially I am going to use a very basic example: you click a button on a screen, it runs a long-running method, and displays the results of the method on the screen.

Since this article is about asynchronous programming we will want the long-running method to run asynchronously on a background thread.  This means we need to marshal the results back on to the user interface thread to display them.

In the real world the method could be running a report, or calling a web service.  Here we will just use the method below, which sleeps to simulate the long-running process:

        private string LongRunningMethod(string message)
            return "Hello " + message;

The method will be called asynchronously from a button click method, with the results assigned to the content of a label.

Coding the Example with Previous Asynchronous C# Approaches

There are at least five standard ways of coding the example above in .Net currently.  This has got so confusing that Microsoft have started giving the various patterns acronyms, such as the ‘EAP‘ and the ‘APM‘.   I’m not going to talk about those as they are effectively deprecated.  However it’s worth having a quick look at how to do our example using some of the other approaches.

Coding the Example by Starting our Own Thread

This simple example is fairly easy to code by just explicitly starting a new thread and then using Invoke or BeginInvoke to get the results back onto the UI thread.  This should be familiar to you:

        private void Button_Click_1(object sender, RoutedEventArgs e)
            new Thread(() => { 
                string result = LongRunningMethod("World");
                Dispatcher.BeginInvoke((Action)(() => Label1.Content = result)); 
            Label1.Content = "Working...";

We start a new thread and hand it the code we want to run.  This calls the long-running method and then uses Dispatcher.BeginInvoke to call back onto the user interface thread with the result and update our label.

Note that immediately after we start the new thread we set the content of our label to ‘Working…’.  This is to show that the button click method continues immediately on the user interface thread after the new thread is started.

The result is that when we click the button our label says ‘Working…’ almost immediately, and then shows ‘Hello World’ when the long-running method returns.  The user interface will remain responsive whilst the long-running thread is running.

Coding the Example Using the Task Parallel Library (TPL)

More instructive is to revisit how we would do this with tasks using the Task Parallel Library.  We would typically use a task continuation as below.

        private void Button_Click_2(object sender, RoutedEventArgs e)
            Task.Run<string>(() => LongRunningMethod("World"))
                .ContinueWith(ant => Label2.Content = ant.Result, 
            Label2.Content = "Working...";

Here we’ve started a task on a background thread using Task.Run.  This is a new construct in .Net 4.5.  However, it is nothing more complicated than Task.Factory.StartNew with preset parameters.  The parameters are the ones you usually want to use.  In particular Task.Run uses the default Task Scheduler and so avoids one of the hidden problems with StartNew.

The task calls the long-running method, and does so on a threadpool thread.  When it is done a continuation runs using ContinueWith.  We want this to run on the user interface thread so it can update our label.  So we specify that it should use the task scheduler in the current synchronization context, which is the user interface thread when the task is set up.

Again we update the label after the task call to show that it returns immediately.  If we run this we’ll see a ‘Working…’ message and then ‘Hello World’ when the long-running method returns.

Coding the Example Using Async and Await


Below is the full code for the async/await implementation of the example above.  We will go through this in detail.

       private void Button_Click_3(object sender, RoutedEventArgs e)
            Label3.Content = "Working...";        

        private async void CallLongRunningMethod()
            string result = await LongRunningMethodAsync("World");
            Label3.Content = result;

        private Task<string> LongRunningMethodAsync(string message)
            return Task.Run<string>(() => LongRunningMethod(message));

        private string LongRunningMethod(string message)
            return "Hello " + message;

Asynchronous Methods

The first thing to realize about the async and await keywords is that by themselves they never start a thread.  They are a way of controlling continuations, not a way of starting asynchronous code.

As a result the usual pattern is to create an asynchronous method that can be used with async/await, or to use an asynchronous method that is already in the framework.  For these purposes a number of new asynchronous methods have been added to the framework.

To be useful to async/await the asynchronous method has to return a task.  The asynchronous method has to start the task it returns as well, something that maybe isn’t so obvious.

So in our example we need to make our synchronous long-running method into an asynchronous method.  The method will start a task to run the long-running method and return it.  The usual approach is to wrap the method in a new method.   It is usual to give the method the same name but append ‘Async’.  Below is the code to do this for the method in our example:

        private Task<string> LongRunningMethodAsync(string message)
            return Task.Run<string>(() => LongRunningMethod(message));

Note that we could use this method directly in our example without async/await.  We could call it and use ‘ContinueWith’ on the return value to effect our continuation in exactly the same way as in the Task Parallel Library code above.  This is true of the new async methods in the framework as well.

Async/Await and Method Scope

Async and await are a smart way of controlling continuations through method scope.  They are used as a pair in a method as shown below:

        private async void CallLongRunningMethod()
            string result = await LongRunningMethodAsync("World");
            Label3.Content = result;

Here async is simply used to tell the compiler that this is an asynchronous method that will have an await in it.  It’s the await itself that’s interesting.

The first line in the method calls LongRunningMethodAsync, clearly.  Remember that LongRunningMethodAsync is returning a long-running task that is running on another thread.  LongRunningMethodAsync starts the task and then returns reasonably quickly.

The await keyword ensures that the remainder of the method does not execute until the long-running task is complete.  It sets up a continuation for the remainder of the method. Once the long-running method is complete the label content will update: note that this happens on the same thread that CallLongRunningMethod is already running on, in this case the user interface thread.

However, the await keyword does not block the thread completely.  Instead control is returned to the calling method on the same thread.  That is, the method that called CallLongRunningMethod will execute at the point after the call was made.

The code that calls LongRunningMethod is below:

        private void Button_Click_3(object sender, RoutedEventArgs e)
            Label3.Content = "Working...";        

So the end result of this is exactly the same as before.  When the button is clicked the label has content ‘Working…’ almost immediately, and then shows ‘Hello World’ when the long-running task completes.

Return Type

One other thing to note is that LongRunningMethodAsync returns a Task<string>, that is, a Task that returns a string.  However the line below assigns the result of the task to the string variable called ‘result’, not the task itself.

string result = await LongRunningMethodAsync("World");

The await keyword ‘unwraps’ the task.  We could have attempted to access the Result property of the task (string result = LongRunningMethodAsync(“World”).Result.  This would have worked but would have simply blocked the user interface thread until the method completed, which is not what we’re trying to do.

I’ll discuss this further below.


To recap, the button click calls CallLongRunningMethod, which in turn calls LongRunningMethodAsync, which sets up and runs our long-running task.  When the task is set up (not when it’s completed) control returns to CallLongRunningMethod, where the await keyword passes control back to the button click method.

So almost immediately the label content will be set to “Working…”, and the button click method will exit, leaving the user interface responsive.

When the task is complete the remainder of CallLongRunningMethod executes as a continuation on the user interface thread, and sets the label to “Hello World”.

Async and Await are a Pair

Async and await are always a pair: you can’t use await in a method unless the method is marked async, and if you mark a method async without await in it then you get a compiler warning.  You can of course have multiple awaits in one method as long as it is marked async.

Aside: Using Anonymous Methods with Async/Await

If you compare the code for the Task Parallel Library (TPL) example with the async/await example you’ll see that we’ve had to introduce two new methods for async/await: for this simple example the TPL code is shorter and arguably easier to understand.  However, it is possible to shorten the async/await code using anonymous methods, as below. This shows how we can use anonymous method syntax with async/await, although I think this code is borderline incomprehensible:

        private void Button_Click_4(object sender, RoutedEventArgs e)
            new Action(async () =>
                string result = await Task.Run<string>(() => LongRunningMethod("World"));
                Label4.Content = result;
            Label4.Content = "Working...";

Using the Call Stack to Control Continuations

Overview of Return Values from Methods Marked as Async

There’s one other fundamental aspect of async/await that we have not yet looked at.  In the example above our method marked with the async keyword did not return anything.  However, we can make all our async methods return values wrapped in a task, which means they in turn can be awaited on further up the call stack.  In general this is considered good practice: it means we can control the flow of our continuations more easily.

The compiler makes it easy for us to return a value wrapped in a task from an async method.  In a method marked async the ‘return’ statement works differently from usual.  The compiler doesn’t simply return the value passed with the statement, but instead wraps it in a task and returns that instead.

Example of Return Values from Methods Marked as Async

Again this is easiest to see with our example.  Our method marked as async was CallLongRunningMethod, and this can be altered to return the string result to the calling method as below:

        private async Task<string> CallLongRunningMethodReturn()
            string result = await LongRunningMethodAsync("World");
            return result;

We are returning a string (‘return result’), but the method signature shows the return type as Task<string>.  Personally I think this is a little confusing, but as discussed it means the calling method can await on this method.  Now we can change the calling method as below:

        private async void Button_Click_5(object sender, RoutedEventArgs e)
            Label5.Content = "Working...";
            string result = await CallLongRunningMethodReturn();
            Label5.Content = result;

We can await the method lower down the call stack because it now returns a task we can await on.  What this means in practice is that the code sets up the task and sets it running and then we can await the results from the task when it is complete anywhere in the call stack.  This gives us a lot of flexibility as methods at various points in the stack can carry on executing until they need the results of the call.

As discussed above when we await on a method returning type Task<string> we can just assign the result to a string as shown.  This is clearly related to the ability to just return a string from the method: these are syntactic conveniences to avoid the programmer having to deal directly with the tasks in async/await.

Note that we have to mark our method as ‘async’ in the method signature (‘private async void Button_Click_5′) because it now has an await in it, and they always go together.

What the Code Does

The code above has exactly the same result as the other examples: the label shows ‘Working…’ until the long-running method returns when it shows ‘Hello World’.  When the button is clicked it sets up the task to run the long-running method and then awaits its completion both in CallLongRunningMethodReturn and Button_Click_5.  There is one slight difference in that the click event is awaiting: previously it exited.  However, if you run the examples you’ll see that the user interface remains responsive whilst the task is running.

What’s The Point?

If you’ve followed all the examples so far you may be wondering what the point is of the new keywords.  For this simple example the Task Parallel Library syntax is shorter, cleaner and probably easier to understand than the async/await syntax.  At first sight async/await are a little confusing.

The answer is that for basic examples async/await don’t seem to me to be adding a lot of value, but as soon as you try to do more complex continuations they come into their own.  For example it’s possible to set up multiple tasks in a loop and write very simple code to deal with what happens when they complete, something that is tricky with tasks.  I suggest you look at the examples in the Microsoft documentation which do show the power of the new keywords.


The full code for these examples is available to download.


This article has only covered the basics of the async/await keywords, although I think it’s addressed all the things that were confusing me when trying to learn about them from the Microsoft documentation.  There are some obvious things it hasn’t covered such as cancelling tasks, exception handling, unwrapping tasks (and why you might need to do that) and how to deal with the reentrancy problems that arise.  All of these are covered reasonably well in the documentation.

Personally I think async and await are far from intuitive: the compiler is performing some magic of a kind we don’t usually see in C#.  The result is that we are yielding control in the middle of a method to the calling method until some other task is complete.  Of course we can do similar things with regular task continuations, but the syntax makes regular continuations look slightly less magical.

However, async/await are a powerful way of controlling multithreaded code once you understand what they are doing.  They can make fairly complex threading look simple.

Why Starting a New Task in the Task Parallel Library (TPL) Doesn’t Always Start a New Thread

The Task Parallel Library in .Net is a wonderful resource.  However, one thing that is a little confusing is that it is actually possible to start a task that runs on the same thread as the current code.  That is, we can do Task.StartNew and it still runs on the same thread.  This isn’t the behaviour we expect.

This can happen particularly when we are writing .Net user interface applications where we marshal data on to the UI thread.

Consider the sample code below, which runs in the button click event of a simple WPF application.  This is a not unusual pattern for a user interface application: we start a Task on a new thread and then perform a continuation on the user interface thread using the current synchronization context, which is the user interface thread synchronization context (TaskScheduler.FromCurrentSynchronizationContext()).  We would typically do this so that we could write the results of the Task into the user interface.  There are several articles on the internet that describe this.

private void button1_Click(object sender, RoutedEventArgs e)
    Debug.WriteLine("UI thread: " + Thread.CurrentThread.ManagedThreadId);
    Task.Factory.StartNew(() => 
        Debug.WriteLine("Task 1 thread: " + Thread.CurrentThread.ManagedThreadId))
    .ContinueWith(ant =>
        Debug.WriteLine("Continuation on UI thread: " + Thread.CurrentThread.ManagedThreadId);
            => Debug.WriteLine("Task 2 thread is UI thread: " + Thread.CurrentThread.ManagedThreadId));
    }, TaskScheduler.FromCurrentSynchronizationContext());

However, in the code above we then start a new Task from the continuation (task 2).  This runs on the user interface thread by default.  This is almost certainly not what we are trying to do.  We probably want to run something on a background thread, which is what usually happens when we start a Task.  As a result it’s slightly hazardous behaviour; we can easily end up blocking the user interface thread because we think the code is running on a background thread.

The output from a couple of button clicks using this code is as below:

UI thread: 8
Task 1 thread: 9
Continuation on UI thread: 8
Task 2 thread is UI thread: 8
UI thread: 8
Task 1 thread: 10
Continuation on UI thread: 8
Task 2 thread is UI thread: 8

The reason for this behaviour is that the user interface thread synchronization context is still in force when we start our second task.

Fortunately, in this case at least there is a simple solution, even if it isn’t so obvious.  We can tell the new Task to run explicitly using the default synchronization context instead of the user interface synchronization context when we start it.  The simplest syntax for this changes the code as below.  Notice it passes TaskScheduler.Default as an argument to Task.Start.  The terminology here for a user interface application is a little confusing.  The ‘current synchronization context’ is accessed using TaskScheduler.FromCurrentSynchronizationContext, which we typically do from the user interface thread.  Then the ‘current’ context that results in delegates being queued back to the user interface thread.  The ‘default synchronization context’ is the context that results in delegates being queued to the thread pool.

private void button1_Click(object sender, RoutedEventArgs e)
    Debug.WriteLine("UI thread: " + Thread.CurrentThread.ManagedThreadId);
    Task.Factory.StartNew(() => 
        Debug.WriteLine("Task 1 thread: " + Thread.CurrentThread.ManagedThreadId))
    .ContinueWith(ant =>
        Debug.WriteLine("Continuation on UI thread: " + Thread.CurrentThread.ManagedThreadId);
        Task task2 = new Task(() 
            => Debug.WriteLine("Task 2 thread: " + Thread.CurrentThread.ManagedThreadId));
    }, TaskScheduler.FromCurrentSynchronizationContext());

The output from this is now as we would expect:

UI thread: 9
Task 1 thread: 10
Continuation on UI thread: 9
Task 2 thread: 11
UI thread: 9
Task 1 thread: 11
Continuation on UI thread: 9
Task 2 thread: 10

For more detailed discussion on this see:



CPDOs for Beginners


CPDOs (constant proportion debt obligations) are in the news currently.  In spite of a judge describing a CPDO issued by ABN Amro as ‘grotesquely complicated’ the basic concept behind the instrument is pretty straightforward.  This article describes the strategy behind a CPDO at a high level.

Overview of a CPDO

A CPDO is a financial instrument issued by a bank that a sophisticated investor can invest in.  To the investor CPDOs behave like bonds that pay a higher rate of interest than similar instruments issued by the bank.  So the investor gives the bank some money for a certain period, usually several years.  The bank pays a high rate of interest throughout the period and, in theory, gives the money back at the end.

To achieve this higher rate of interest the bank effectively speculates with the money they are given.  They speculate in quite a distinctive way, however.

The Basic Strategy – Sell CDS Protection to Generate Income

The first thing the bank does is to invest the money the investor has given them in something that will pay them the normal rate of interest.  If that was all they did obviously they would not be able to pay the high rate of interest to the investor.

So the bank needs a way of generating extra money.  To do this they use CDS.  I have written an earlier article on the exact mechanics of CDS, but you don’t need to know the details to understand CPDO.  What you do need to know is that CDS are like insurance contracts: if you sell protection on a CDS you receive periodic payments in return for a small chance that you will have to pay back a much larger sum.  You pay back the larger sum if the a specific company gets into financial difficulty: this is known as a ‘credit event’ or ‘default’.

Note that the banks actually use CDS indexes in CPDOs, which are CDS on a basket of companies rather than one company.  However the idea is the same.

The basic strategy is that at the start of the period the bank sells enough CDS protection to easily generate enough money to pay the high rate of interest to the investor for the period of the investment, assuming there is no need to pay anything back because of defaults.  The bank works out how much protection to sell using a set of rules that are defined in the CPDO documentation.

Periodic Rebalancing

Once they have done that they leave everything alone for a while.  After a set period of time they look at how the CPDO is doing.  At this point they may change the amount of CDS protection they are selling.  This is known as ‘rebalancing’.

The CPDO may be doing well: none of the CDS may have had credit events, for example.  In this case the bank might reduce the amount of CDS protection they are selling.

Conversely some of the CDS in the CPDO have suffered defaults.  It may be that the amount of CDS that have been sold will no longer be enough to generate the money needed to repay the investor.  In this case the bank might increase the amount of CDS protection they are selling.

The bank will do this rebalancing periodically throughout the life of the CPDO.  It is usually done every six months to coincide with the dates that the CDS indexes are updated.


Note that all of this is done according to the set of rules that are defined in advance: it’s not a judgment call.  The rules can look fairly complex.  However all they really do is describe a way of calculating ‘leverage’, which is the value of the money to be received from the risky CDS contracts outstanding versus the amount of cash they need to generate, maybe multiplied by a fixed factor. The bank will try to keep the leverage constant at every rebalancing: if the amount of cash to be generated has increased (because there have been defaults) then the value of the money from the CDS contracts needs to be increased, so we enter into more contracts.

Possible Results of the Strategy

The aim, of course, is to generate plenty of money through this speculation in CDS.  The ideal is to generate so much money that it can all be invested in relatively riskless instruments and still pay for the cashflows on the CPDO.  At that point you don’t need to speculate any more: you can ‘cash in’ the CPDO.

An alternative is that you lose so much money from paying out on the CDS that you get to the point where it’s clear you won’t be able to pay the interest rate and principal on the CPDO.  The rules governing the CPDO usually define this ‘cash out’ point: when it is reached the structure will be unwound and the bank will pay what money is left back to the investor.

A final alternative is that the ‘cash in’ or ‘cash out’ points are never reached, but and the CPDO just expires but without sufficient cash to repay the investor in full.


Those of you who are familiar with gambling will recognize this as a simple martingale strategy.  If you lose you increase the amount you are betting.  This is in the hope that you will win next time and get all your money back.  Of course if you lose again you can increase the amount you are betting again, but you run the risk of losing substantial amounts of money.

Effects of Market Moves

There are a few other points to notice about this product:

  • The best case for the investor is to get the high rate of interest on their investment and all of their money back.  The CPDO is not speculative in the sense that the investor can make better returns if the market moves favourably.
  • The investor is selling protection in the credit markets.  The CPDO will lose money when companies get into financial difficulty.  If many get into financial difficulty simultaneously the CPDO may well suffer large losses.  This means the investor will not get much of their money back.  Of course, that’s exactly what happened with many of these instruments.
  • It’s possible to structure a CPDO such that in normal market conditions there is a good chance that the CPDO will cash in.  If the bank is simply trying to get a little bit of extra interest by speculating in CDS over a long period of time then they might usually win their bet.
  • I’ll leave it to the reader to decide whether this is really a product that anyone should have been ‘investing’ in, AAA-rated or not.


This article has given a very high-level overview of CPDOs.  It has inevitably glossed over some details, but hopefully it explains the basic idea.

CPDOs were invented in the credit boom, and when the crash came they lost many people a lot of money.  I doubt we shall see them again any time soon except in lawsuits.

Beginner’s Guide to Techniques for Refreshing Web Pages: Ajax, Comet, HTML5


This article briefly discusses the technologies used in modern browsers to display web pages, and goes into a little more detail about the user experience on those web pages, in particular how we can get part of a web page to refresh automatically when data changes on a web server.

Browsers and HTML

I’m sure anyone who’s reading this page is aware that the web is based on a request and response process that returns web pages of data.  If I click on a link my browser makes a request for the web page specified in the link, the request gets routed to the appropriate server, and the server responds with a page of HTML which my browser displays.

HTML (hypertext markup language), of course, is a simple markup language that tells a browser where to put text and images on a web page using tags (e.g. <header>).  The request format is a text URL (uniform resource locator) of the kind you see all the time in your browser’s navigation bar.  Furthermore, the returned text can contain additional links that the browser will show underlined and that I can click on.

Anyone who uses the internet understands this, but the success of the web is at least in part due to the simplicity of that model.  The HTML is just text with a few special tags in angle brackets, and all a browser has to do is know how to send a request, handle the response, and then draw a screen using the HTML that’s returned.  Similarly all a web server has to do is know how to receive a request, get the right HTML text to send back, and send it.  Often web servers will simply store the text in text files on their hard drive, and just load and send the right one in response to a request depending on the text of the request.

At root it’s unbelievably simple; just look what it’s turned into.

Other Technologies Used In Web Browsers

Of course modern browsers aren’t as simple as described above and there are a number of other technologies that they understand and developers can use.

Firstly, developers want to write code, so there’s also a programming language embedded into every modern browser.  This is Javascript.

Javascript allows programmers to write little bits of code that can run when events happen in the browser.  The Javascript can manipulate what’s displayed in the browser programmatically, or can perform other actions.

For the Javascript to change what’s displayed it needs to manipulate the HTML.  Obviously this can be done by simply changing the text.  However, there’s a programmatic representation of a web page that Javascript can use to manipulate elements within it.  This format is the Document Object Model or DOM.

Another baseline technology for what gets displayed to the client is Cascading Style Sheets (CSS).  These allow a common look and feel to be applied to a group of web pages without the need for detailed coding in each page.

Drawbacks of the Basic HTML Request/Response Page-Based Model

HTML + Javascript + CSS allows us to create quite sophisticated web pages.  However, there’s one big drawback with the model as described above: to display new data we have to click on a link to request a whole new page and wait whilst it loads.

For a more sophisticated user experience there are a few things we might like to have:

  1. The ability to refresh part of a web page without reloading the entire page.  Initially this could be initiated by the user clicking a button, but we want just the relevant data to update, not the entire page.
  2. The ability to do this refresh whilst allowing the user to continue to interact with the rest of the page.  That is, the request shouldn’t block the user, it should be asynchronous.
  3. The ability to update the page when data changes on the server without the user having to refresh in any way.

1.  Refreshing Part of a Web Page

The first problem that developers tried to solve was updating part of a web page in place without reloading the entire page.  There are several ways of doing this.


However, there are some simple approaches that predate Ajax.  One is to use IFrames.  These are HTML elements within a page that can issue their own request/responses to a web site and render the results independently of the rest of the page.  They have a SRC property that can be set to a URL.  If you set the src to a different or the same URL (say on a button click) the new data will appear without a full page reload.

Many developers don’t like IFrames.  Search engines can get confused by them.  They may show scrollbars if your content doesn’t fit correctly.  Worse if your user has scrolled to the bottom of a page and then you load a new shorter page in the same frame they may be off the bottom of it.  Because of restrictions in HTML IFrames can usually only issue requests to the same site as the main site of the page they are on.  All of this means people have looked for better solutions.

Script Injection

Another approach to refreshing part of a web page is client-side script injection.  This takes advantage of the fact that Javascript code in a web page can be retrieved from a server using a URL via a src tag.

The basic approach is the same as for IFrames: we can set or reset the src of the script code, and the browser will retrieve the script from the URL and execute it.  If we send back valid Javascript that updates part of our web page, or calls a function that does, then we don’t have to refresh the entire page.

One advantage of this approach is that script tags can issue requests to any URL, not just the same site as the page they are on.  One disadvantage of this approach is that it can lead to security vulnerabilities in the code.


JSONP is just a way of using client-side script injection across domains to get data from a different website: we request the script from the different server and it returns it as the parameters of a Javascript function which immediately executes and uses the payload.

2.  Refreshing Part of a Web Page Asynchronously

Ajax (Asynchronous Javascript and XML) is probably the primary technology for this.  Ajax is actually a label applied to a way of using many of the technologies described above to allow web pages to be displayed and then be updated asynchronously without reloading the entire page.

The main distinguishing feature of Ajax is that it uses a relatively new request response mechanism.  This is called XMLHttpRequest.  When a browser makes a request using XMLHttpRequest it provides the name of a Javascript function that will be called back by the server.  This function will have access to the data sent back from the server.

The original call to the server will not block and will not reload the page.  The user can carry on interacting with the page as usual, even if the call to the server takes some time.

It is up to the callback function to make whatever changes it needs to make to the web page using the usual Javascript techniques described above.  This will typically involve updating just a part of the screen.

One thing to note here is that the data returned is just text.  It doesn’t have to be XML, in spite of the names (XMLHttpRequest, AjaX).

3.  Updating a Page Automatically when Data Changes on the Server

Ajax as described so far updates a page in place, but only in response to a request from the web page.  This means that the user has to click a button or something similar for the page to update.

Obviously there are situations where data is changing and we would like it to update on our web page without the need for the user to manually refresh.

There are quite a few ways of doing this, some of them direct extensions to the Ajax model described above:


Javascript allows us to fire events that run code in the browser at set intervals.  So a very simple approach is to automatically request a refresh of the part of the screen we are interested in updating periodically.  We can do this using the Ajax techniques above, so that the rest of the screen remains responsive.

The drawback to this is we may make requests when no data has changed, putting unnecessary load on our servers.  Also our data on the client may well be out of date at any given time if we are between polling requests.

We really want a way for our server to send data only when it’s changed, and at the moment it has changed.

Long Polling

Another approach is long polling.  Here the browser fires off a request with a long timeout and sets up a handler for the results using Ajax as before.  However, the server itself doesn’t respond until it has data that has changed, and then it sends the data in response to the original request.  The browser handles the request and immediately sets up another long timeout request for future updates.

The disadvantage of this approach is that the server has to keep the connection (a network socket) open until it has data.  In general it will have as many connections as it has clients waiting for data.  This obviously puts load on the server and the number of sockets that the server can possibly use becomes a limiting factor.  Also this is clearly a more complex solution to implement than normal (short) polling.


In streaming the client makes a request and the server responds with an open response that keeps the communication channel open and allows subsequent responses to be sent to the client.  The server may eventually time out the connection, or may keep it open indefinitely.  If the connection times out the client will have to make another request to refresh the data.  So this approach is like long polling with the client needing to make fewer requests.

One drawback of this approach is that many proxy servers buffer http responses until they are complete: that is, they won’t send on the message until they have the completion.  This means the client won’t get timely updates.  Another obvious drawback is that this is a fairly complex way of keeping data up to date.

With all of these approaches the call backs from the server tend to tie up one http communication channel.  As a result many approaches to solving the problem use (at least) two channels: one for polling or streaming to  update the data in place, and one for regular requests from the client to the server.

A number of commercial frameworks have been built using these techniques.


Comet is a name that’s been applied to the techniques described above to update a web page in place automatically when data changes on the server using a longlasting HTTP connection.

HTML 5 Web Sockets

HTML 5 web sockets are the new way to do bidirectional communication between a web page and a server.  They don’t use the old HTTP request/response at all, but instead set up one dedicated channel for communication between client and server.  This is fast, and the messages involve very little redundant header information, unlike conventional HTTP requests.

The main drawback of this new technology currently is that many browsers do not support it.  For example, it doesn’t work in the last version of Internet Explorer, IE9, although it works in IE10.