Chris Sainty

Wrapping synchronous code in a Task returning method

noreply@blogger.com (Chris Sainty) — Mon, 18 Feb 2013 20:15:00 +0000

Imagine you have an interface.

Now imagine you want to implement this interface, but the code to go in there is not actually asynchronous. Neither is it cpu-intensive and requiring it’s own thread. It is just a regular piece of synchronous code.

There are three ways to do this that I know of.

So what is the difference between these three?
In terms of the IL being generated, the answer is quite a lot. In terms of relative performance though, the following falls strictly into the category of extreme micro-optimization.

The code

The first implementation is the most optimal approach. It turns out that Task has an internal constructor that takes a result. So the static FromResult() method is just a public wrapper around that constructor which returns a completed Task with your value. Task<T> is then cast to Task and off we go.

I find the second approach to be the easiest to read because you just need your async and no weird faux-return. This one actually generates quite a bit of IL. You get a full state machine created, it gets initialized and then executed.

That is a lot of generated code just to save me explicitly returning a Task!

The third option generates the code for the lambda, then passes it off to Task. The task is then handed to the scheduler and what happens next will depend on your scheduler. While this option is lighter on code-gen, the hand-off process makes this the slowest option.

Performance

I ran a couple of quick and dirty performance checks over these three. In each case firing off the method 100,000 times and blocking on the result in a tight for-loop.
The first implementation runs in about 2ms, the second in about 15ms and the third in about 170ms. Like I said, firmly in the realms of micro-optimization.
Something interesting to note though is that if you repeat the test with the debugger attached, the third option blows out to more like 30000ms! I guess there is some more context switching going on with the debugger attached which affects the performance.

Conclusion

Ideally you want to avoid doing any of this. Your best option is to support both synchronous and asynchronous implementations where appropriate. In practice I am finding that I often need to handle this wrapping process and so it is handy to understand exactly what I am asking of the compiler when I do. It may be a micro-optimization but it costs me nothing to do it the best way!

Interfaces again

noreply@blogger.com (Chris Sainty) — Tue, 29 Jan 2013 16:43:00 +0000

In my recent post about interfaces I showed one approach to breaking up and consuming your interfaces that I am finding interesting at the moment. The idea was born out placing restrictions on myself and trying to be explicit about my dependencies. I wanted to structure the code in a way where I couldn’t get lazy and just start firing off database code from anywhere in the codebase.

In an earlier iteration of that same thought process I had a different structure that was quite interesting in its own right. I don’t think either is better than the other. But I do find them both interesting and hopefully someone reading this does as well.

So what is my second example for you? Well again it involves tricks of code organisation to change the way the functionality of a class is consumed. This one is more about taking a class that implements multiple interfaces but exposing them in a more structured way. Again I will work in the repository space. For the same reasons as last time, it is a service type we all understand and that we have all seen go wrong at some point. Don’t read this as a guide on how you should structure code it is merely a thought exercise at this point.

So in this case we take a dependency on the large service class, the repository, but even though that class potentially implements a lot of code we use explicit interfaces and getters to cut down the surface of the class and help a consumer find their way through it.

Unlike my previous article this doesn’t give you much in your testing or make your code more explicit about it’s dependencies. It’s doesn’t do as much for refactoring or replacing implementations of individual interfaces. It is all about IntelliSense really and making a class which, for whatever reason needs to be this complex, a little more manageable.

Going back to where all this started, I am thinking a lot lately about how I manage abstraction. Where my interfaces sit, what boundaries they have and how their implementations are structured. It is nice to take a step back like this at times and look at our tools, ask what else can I do with this and how else “could” it look.

There are a lot of opposing opinions out there, opinions that are constantly changing and evolving. In the end we need to find the processes that are working for us, our teams and our codebase. Situations are never the same, so learn as much as you can and apply it where it makes sense.

In that spirit it must be about time for another “Learn Something New” post.

Fun with Explicitly Implemented Interfaces

noreply@blogger.com (Chris Sainty) — Mon, 28 Jan 2013 16:40:00 +0000

I’ve picked up a new coding technique recently. I’ve always been a bit uncomfortable with the 1:1 relationship between class and interface. I’ve also been uncomfortable with large service classes like a repository. When you take a dependency on a large service interface you are hiding all the details about what you are actually dependent on, which can cause you problems down the line with your tests and refactorings.
Repositories in particular quickly escalate to large numbers of functions. If I am working on tests for a piece of code that takes a dependency on that repository I have no option other than to read the code to see what methods it is calling. Tedious.

So when I stumbled across the long forgotten (by me) practice of explicitly implementing an interface I saw potential to take a fresh look at some of these concerns.

I still don’t know exactly where this train of thought will take me but I’d like to throw it out there and see if it gets the gears turning for anyone else. I am using this heavily in a new personal project, so by the end of it I should have a good idea of whether it has helped or hindered me.

A quick refresh on explicitly implementing and interface.

When you implement an interface like this (note the interface name in front of the method name) then it is only accessible when your instance of SqlRepository is cast as an IsEmailAlreadyInUse. Through a dependency injection container, which preferably includes an AsImplemetedInterfaces() option, this is very easily wired up.

Notice how the SqlRepository is internal, this is saying that you shouldn’t be giving out instances cast as this type. You should be handing out a single instance (per appropriate lifetime scope) cast as its various interfaces.
With this done, your code that is applying business logic around these persistence calls suddenly needs to be explicit about what functions it needs. It can no longer say “give me a repository and I will do what I please with it”

When you are writing tests (whether before or after writing the implementation) it becomes very obvious what your code is actually dependent on. Which makes it easier to mock and easier to refactor or replace.
An additional benefit is that if you end up with a lot of dependencies you should be stopping to consider if your pushing too much logic into a single code unit. Perhaps things can be broken down further and some reusability gained.

In my personal application I do all this in two code files. I have one where I define all my interfaces and one where I implement them all. Overall the approach is working well for me so far though, it has not been proven to be a burden to organise the code. I have very simple integration tests that ensure each command is doing what I expect it to. All my “complicated” logic is then easily unit tested with FakeItEasy.

Finally I chose the repository as an example because it is a pattern I see often which could really benefit from a new approach. It is by no means the only example. At the same time don’t just go breaking interfaces apart for the sake of it, use them correctly as your units of abstraction.

There is another interesting pattern you can use when implementing your interfaces like this. I will hopefully go into that next time.

Avoid branching

noreply@blogger.com (Chris Sainty) — Mon, 14 Jan 2013 15:24:00 +0000

One thing I have noticed recently is that I like to avoid branching. Now what I am talking about here is not branching at a code level. I am talking about mental branching as I am writing code, following other trains of thought or investigating problems whose answers are not immediately necessary.

It seems obvious, but after following along some conversations on twitter recently I think I need to post more, even for things I find obvious. So…

About a meter from my desk I have a whiteboard.

The sections and structure of it don’t really matter, they are what makes sense for my project and the team I am working with.

Almost every note on that board is a branch I could have gone down that would have caused me to stop what I was in the middle of doing and focus on the branch. I find this sort of context switching very disruptive.

To be clear about the whiteboard this isn’t some sort of quasi-agile project workflow (we use trello for that), these are not story cards and if someone calls me up and says “we have some important thing you need to do” then I branch. This is not about sitting in a programming utopia where I am uninterruptable, it is about not interrupting myself. These notes are questions and tasks that need to be answered or completed but ones that can wait. Here are some examples

“Should we avoid making searches we know to be bad?”
”Should we write a $0 tax record or leave the tax record off?”

The domain I am working in at the moment involves talking to a lot third party APIs and integrating them into the internal domain model. So inevitably there is a lot of mapping that goes between the response from the API and the internal model, both are quite complex and different from each other.

So while I am sitting down with a list of 50 properties I need to go though and I come across one where I do not know the business answer to the problem, I write it on a note, stick the note on the board and move on.
Then once I am done, I go to the board and read through through the notes.

Sometimes with the extra knowledge I have gained since writing the note I can now answer it myself.
Sometimes I can ask someone else on the team and they answer it.
Sometimes I can research within the codebase for the answer.
Sometimes I need to talk to the product owner.

That is a lot of “sometimes” and it is precisely why I defer that chain of “sometimes” until the last possible moment.

Enabling sessions in Nancy

noreply@blogger.com (Chris Sainty) — Thu, 17 May 2012 07:21:00 +0000

As you may know, AppHarbify is built with Nancy. One of the reasons I decided to build it in Nancy, other than the fact that Nancy is awesome, was that I wanted to put together a real project that can be used as an example of Nancy in action. All the code for AppHarbify is available on GitHub.

To go with that I am planning to put together some blog posts talking about various aspects of the code.

To start with I am looking at sessions.

Getting Started

Nancy ships with a single session provider implemented, CookieBasedSessions. You can of course add your own.

This provider stores the session, encrypted, in the users cookies. Which is really not too bad of a solution to get started. You are up and running with a single line of code added to your ApplicationStartup method in your Bootstrapper.

Once enabled, you can simply access the Session property on Request.

Request.Session["Key"]

Now you don’t want to store too much data in a cookie-based session like this, as every request is sending the data back across the wire. Also it is theoretically possible the encryption could be broken. Side note: You can control the encryption provider with an optional second parameter to .Enable(). If you do not, then a new key is generated each time the app starts, invalidating all existing sessions.

Testing

If you do any work with sessions, you are likely to need to test them eventually. While the mechanism is a bit awkward, it is essentially pretty easy. My preferred method is to attach an event to the .Before pipeline in your testing Bootstrapper that injects the required session into the request.

By adding this simple extension method and calling it on your Bootstrapper whenever you want to test a route that needs session information, you can very simply abstract away your real session storage mechanism without adding more layers of abstraction to your actual codebase.

Future

While AppHarbify is currently running along fine using these cookie based session, for the reasons I have stated above it is not ideal. So the plan is to write Redis based session mechanism and take advantage of the easily installed Redis add-on at AppHarbor. Of course this code will be open-source and released independently of AppHarbify as a nuget package. So watch out for that!

AppHarbify Tools

noreply@blogger.com (Chris Sainty) — Tue, 15 May 2012 04:27:00 +0000

An important goal of AppHarbify is to make as much open source software as possible be AppHarbor-friendly. To speed this process along I will be creating and/or finding many libraries to solve common problems.

The first problem I have tackled is handling connection strings with Entity Framework. Specifically conventions based Code-First EF.

AppHarbor already has quite an elegant solution where you log into the Sequelizer add-on and set your desired connection string, then at deployment that connection string is either inserted or updated with the connection details for your instance.

Unfortunately AppHarbify can not rely on this mechanism as it can not set configuration variables inside an add-on.

The solution

What I found was a static property Database.DefaultConnectionFactory which holds the factory EF uses to create its database connections.

It was then a simple matter of detecting if we are on AppHarbor (by the presence of the AppSetting which AppHarbor stores the connection string in) and then replacing this factory with a new one that creates connections from the AppSetting.

https://github.com/csainty/AppHarbify.Tools/blob/master/src/AppHarbify.EF/ConnectionFactory.cs

NuGet Package

To make this as simple as possible I then bundled this up as a NuGet package AppHarbify.EF.

Once installed it is a one-liner to enable your application to use the connection string in web.config when not on AppHarbor, and switch across to their AppSetting when you are.

AppHarbify.EF.ConnectionFactory.Enable();

Migrations

There is one little snag with this approach. Migrations. The Migrations package, for reasons I have not yet investigated, chose to use their own mechanism for fetching the connection to the database. One that very strictly follows the convention of a connection string named after your DbContext.

So for Migrations to work, you need to strip the connection string out of your web.config when it is deployed too AppHarbor. With no connection string present it will then fallback through other means of creating the connection and settle on one that works for us. If AppHarbor is your only deployment target, this is simple. See https://github.com/csainty/JabbR/blob/AppHarbify/JabbR/Web.Release.config#L18

If you need to handle multiple deployment locations then this is going to get more tricky. I am hoping that the EF team can unify behind one strategy for database connection creation and make it extensible.

Announcing AppHarbify–Simplifying open source deployment

noreply@blogger.com (Chris Sainty) — Wed, 02 May 2012 01:42:00 +0000

Since finishing up my day job last week, I have had some time to dedicate to a project idea I had a few months ago. It is now time to formally announce it.

Say hello to AppHarbify!

AppHarbify aims to make deploying common software to AppHarbor even easier. So easy that it can be done by non-technical people or from mobile devices.

The plan is to make as much .NET (or Node.js) open source software as possible compatible with the AppHarbor platform. Then bring it all into the one place and offer single step deployment. You can try it out right now with some of the projects I have used for testing http://appharbify.com/Apps, including JabbR and FunnelWeb.

AppHarbify takes care of creating the application, installing the required add-ons, configuring application variables and deploying the code base. All you need to do is authenticate, via OAuth, with AppHarbor and choose which project to deploy.

In addition to all this deployment goodness, there is a second side to AppHarbify. From the Deployed Sites link you can see a list of all your deployed AppHarbor sites, regardless of whether AppHarbify deployed them, and add useful tools or features. At the moment support is limited to email based build notifications, but there will be plenty more.

This is all made possible thanks to the AppHarbor API.
AppHarbify is open source and on GitHub https://github.com/csainty/Apphbify. See the README for details on how to add new deployable software.
It is written with Nancy and of course hosted at AppHarbor.

If you have any questions, comments or suggestions I am on twitter @csainty and usually somewhere in the JabbR rooms.

Available for hire!

noreply@blogger.com (Chris Sainty) — Wed, 18 Apr 2012 02:21:00 +0000

Next week, after more than 11 years, I will be leaving Quids in search of a new adventure. In fact I will be hoping to roll two adventures into one, a new job and a new country.
I’ll keep this blog post relatively short so if you want to talk details drop me an email at csainty@hotmail.com

Let’s begin with the job.

Having worked my entire career with a single company, I am very open minded about the next step in my career. The most important factor is going to be the products I am developing. Something in the consumer web or mobile space would get me the most excited.

My professional experience is largely on the Microsoft stack. C#, SQL, ASP.NET MVC, Windows Phone 7 and all the related tools you use when doing Microsoft development. If you flick through my blog though you will find a lot of recent interest in Node.js, RavenDB and many other OSS tools.
I have no problem picking up new languages and have plenty of real world non-technical experience that transfers to any set of tools I might need to use.

So what about this second adventure?

Not content with simply changing jobs my wife and I are also looking to move overseas.
The primary focus is Europe, and top of the list is Copenhagen, Denmark. Most parts of Europe are open to consideration though. I won’t bore you with details here, if you would like to know a few more reasons I am more than happy to have a chat.

Job Hunting

The search is already underway. I have found a couple of decent sites to search on it-jobbank.dk, dk.indeed.com and careers.stackoverflow.com to name a few. I have also been tracking down individual companies based in the regions that interest me.
We all know that not every job is advertised though. So if you are interested or know someone that might be, I would love to hear from you.

Where to find me

Email: csainty@hotmail.com
Twitter: @csainty
Stackoverflow Careers: http://careers.stackoverflow.com/csainty
Stackoverflow: http://stackoverflow.com/users/625695/chris-sainty
Github: https://github.com/csainty
Coderwall: http://coderwall.com/csainty

Remote debug your iisnode hosted node.js app

noreply@blogger.com (Chris Sainty) — Thu, 22 Mar 2012 23:10:00 +0000

I recently came across iisnode’s built in support for the excellent node-inspector package. My iisnode host of choice being AppHarbor, I proceeded to set up a repo and make sure it all works there.

The good news is… It does!

Even better is that this is built straight into iisnode, you don’t need to touch your app code to get it working, you don’t even need to install the node-inspector package. It is all bundled in with iisnode.

You simply need to make a single change to your web.config rewrite rules so that the urls to launch the debugger are not treated as regular requests and sent through to you app.

So the way you get to the debug console is to hit up /app.js/debug where app.js is the entry point for your app. The rewrite rules here simply allow that url through as it is, everything else gets handed off to the app as normal.

So push up the modified web.config, hit the URL and this nice console pops up.

Clicking into Scripts presents you with a list of all the running JavaScript files on the server. Including those built into node itself. You can pick the file you want to debug, and set a break point by clicking on the line numbers.

With the breakpoint set, now you need to fire a hit off to the website that will run over the breakpoint.

This hit will sit there waiting for the server to respond, switch back to your debugger page and the breakpoint has been reached and is waiting for you to take some action.

As you can see you have full variable inspection, the options to step through line by line or continue running, variable watch and all the sorts of things you would expect. You even have mouse hover variable inspection like in Visual Studio.

When you are done debugging, you should call the /app.js/debug/?kill url which will shut down the debugger process.

Now I wouldn’t go doing this on production, and you certainly do not want to leave that route in place, I would set the debuggingEnabled property to false as well in production but for development or staging servers where you need to follow something through, this is simply awesome.

Custom Domain Testing

noreply@blogger.com (Chris Sainty) — Tue, 13 Mar 2012 02:04:00 +0000

I finally got around to purchasing a domain for this blog today (csainty.com) and so this is just a quick test post so I can make sure feeds and the like have all been repointed.

Nothing to see here.

WinJS - Classes

noreply@blogger.com (Chris Sainty) — Sat, 10 Mar 2012 02:08:00 +0000

In my last two posts on JavaScript for Windows 8 I looked at scope and namespaces. I pointed out that namespaces could be used to create “static” classes. I hasten to add they can be used for more, don’t make a hard link in your brain between namespaces and static classes.

So what about regular classes. There are a couple of ways to define a class in JavaScript, a simple way is to return a hash from a factory method.

We can shift name into a private scope by declaring a new variable inside our constructor which is captured by the resulting object.

However, for complex classes you intend to create a lot of, this method is generally not the suggested. Each instance is redefining the functions rather than simply pointing to an existing implementation in memory. This is where prototype inheritance comes in.

With this setup you start with your constructor, you then extend it’s prototype. Finally instead of calling the constructor directly, you call it with the new keyword, which creates you a new instance.

Note the capital P in Person, this is a convention to say this function is a class definition, so call it with new.

But, we have lost the private scoping on the name property. To get it back, we need to define the property inside the constructor like we did above, but then expose it with a getter method so that the methods on the prototypes can get at it.

It’s starting to get ugly isn’t it. Getting our reference to Person back out is quite awkward. The getter isn't much fun either.

So what does WinJS bring to the table?

There is a WinJS.Class namespace that contains a define method. It can be used to wrap up a big ugly class definition like that above into a simple method call that returns a class definition you can new up. It supports passing in your constructor, your instance methods/properties and your static methods/properties.

Much cleaner. Our class definition is sitting in the MyApp namespace ready to be created via new MyApp.Person('') and for good measure there is a static factory method MyApp.Person.createPerson('').

But what about private variables? You can use the same technique as my example above with the getter. If you had a lot of them you might wrap them all onto a single private hash that only needed a single getter. What you might see a lot of people do is simply prefix them with an underscore and hope others follow the convention that properties starting with an underscore are not to be touched.

Private scope aside, by combining WinJS.Namespace and WinJS.Class you have a really nice set of helpers to wrap up the task of correctly managing global scope and efficient class definitions. Neither is performing any magic, their source code is there for you to explore, they just get rid of some of the confusing boilerplate.

Node.js Background Workers on AppHarbor

noreply@blogger.com (Chris Sainty) — Fri, 09 Mar 2012 01:55:00 +0000

Today AppHarbor announced beta support for Background Workers, I have been eagerly awaiting this announcement as it is something I need all the time when hosting sites.

Background Workers are simply .exe files that the server now knows to look for and run if you have a worker assigned to background tasks in your subscription. It should be noted that if you are using the free single worker plan, then you can not run both a web and background worker. You do have the option to run a web OR a background worker though. So you can still try these out on your free account.
It should also be noted that trying to run two free accounts (one for web, one for background) that are servicing the same site is against the terms of service.

As people who follow my blog probably know, I am right into Node at the moment. So straight away I set about getting a background worker up that can run node for me instead of C#.

It was rather easy in the end, a simple wrapper that launches a node.exe process. You can grab the code from https://github.com/csainty/NodeWorker.
You don’t even need Visual Studio installed or Windows, you push the source code to AppHarbor and they build it for you!

The demo app I used for testing is also available, it simply logs entries off to logentries (a free, one click install, addon from AppHarbor) so I can see if it is working. That code is at https://github.com/csainty/NodeWorkerDemo.

So how does it work?

First you need to clone down the project from GitHub.

Then you need to add your node.js code into the app folder. The assumed entry point is app/index.js, but you can quickly point it elsewhere and add extra parameters to the node process if needed.
See https://github.com/csainty/NodeWorkerDemo/blob/master/NodeWorkerRunner/Program.cs#L19

Finally make sure your node_modules folder is in the commit (AppHarbor does not run npm for you yet) and that all the files are being copied into the build folder and you are done.
If you are unsure, check the build output on AppHarbor for lines like the following

Now push the whole project up to AppHarbor where it will be built and start running straight away.

The lifetime of a background worker is controlled by the exit code from your application. The wrapper will pass the exit code from your node process back out to AppHarbor, putting node in control. There are currently two supported values

Exit Code: 0 – Stop running the worker until the next deploy is performed
Anything else – Start the worker again immediately

If you take a look here you will see I chose to return 0 if there was a problem launching the node process. Meaning it will stop attempting to run your process. If this is not what you want, then you should change this value to be non-zero.

Finally similar to iisnode, all your <appSettings /> are added as environment variables when launching the node process which makes them available on process.env. Just like if you are hosting a node site on AppHarbor.

WinJS - Namespaces

noreply@blogger.com (Chris Sainty) — Wed, 07 Mar 2012 23:25:00 +0000

In my last post I explained a little about scope in JavaScript and why you should (and the default templates do) wrap each of your files in a self executing function.

One note about my code snippets. For simplicity I will be concatenating what would in a real application be multiple .js files into a single code snippet. I’ll use comments to show you where the files break.

So let’s imagine you are creating a helper function to do something really useful, like add two numbers together.

We have defined this function in the global scope, let’s do the right thing and wrap a function scope around each file.

Now the two scopes can’t see each other or interact with each other. So how can we make our add function available to the rest of our application without just throwing it in the global scope.

I present to you Namespaces.

Namespaces are not a part of JavaScript, they are a helper library that Microsoft has provided in WinJS to better handle the problem of scope in JavaScript. In fact if you dig into the references on your project, you can actually find all the code for Namespaces in the base.js.

Basically a namespace is an object that sits in the global scope. They can be nested and since you should be naming them much more uniquely than you would a regular variable the chances of conflicting with another library are slim.

So let’s expose our add function through a namespace.

The WinJS.Namespace object is itself a namespace, defined in the base.js I mentioned above, which is why we are able to just call off to it. Once we define our own namespace we can then call it in any later code in the same way.

Another interesting feature of Namespaces is that they are composed, so if you define the same Namespace twice instead of overwriting it you add to it.

Suppose we now want to add a subtract method, but we want it to be in a separate file from our add method. A better example, which we are using at Code52, suppose you have two implementations for your data access layer. You want them in the same namespace but in separate physical files.

This is super useful and kudos to Microsoft for making it work that way.

One last note on namespaces. Remember that the context in which you are defining your Namespace is local to itself. JavaScript captures that scope when you define a function though. So you can define functions and variables that are only visible to the functions you are exposing on your namespace.

To demonstrate this I will keep a running total of all the sum operations, and add a new function to return that total.

The runningTotal variable and the adjustTotal method are both local to the helpers.js file and inaccessible outside of it. However, the add and total functions that we are exposing through the namespace have captured and retained the scope in which they were define and therefore still have access.

So that is a quick introduction to namespaces. I have only shown exposing functions, but variables can be exposed as well. What I have shown here is most similar to a static class in C#.

Next time I will look at WinJS.Class and how you can use it to create class definitions.

Windows 8, WinRT and WinJS - Scope

noreply@blogger.com (Chris Sainty) — Wed, 07 Mar 2012 22:13:00 +0000

This week at Code52 we are taking on our first Windows 8 app. Just to make it interesting we are doing it using the HTML / JS stack instead of C# / XAML.

Before getting too far into WinJS (which is the general term I am going to use for referring to WinRT apps written in JS until someone tells me otherwise) it is a good idea to get a basic understanding of JavaScript as a language. It is a lot more in-depth than jQuery and the DOM would lead you to believe.

The first thing you are going to confronted with upon creating a new project and opening on of the .js files is this structure.

This is a self or immediately executing function. It defines a function, then execute it. Nonsense! I hear you scream.

The reason for this structure is scope. JavaScript’s scope boundary is at the function level. It is not at the file level, or at the block level (like in C#). For example this code works.

But if we define our variable in a self executing function. Then it does not.

Functions scopes are stacked, and the outer most layer of that stack is called the global scope. So consider a large application with hundreds of js files. If each of these files did not use the self executing function trick to get a local scope, then they would all share the global scope. Now consider how likely it is that two files would share a variable name and cause difficult to track down bugs.

It is interesting to note that Node actually wraps your modules in a function scope for you, so you get this safety out of the box.

I’ll try keep these posts short and to a single topic, so that will do it for this one. Next I am going to take a look at the WinJS.Namespace helper and show you how to use it to safely get objects back out of your function scope and into accessible globally.

Launching a Metro.css + Node.js site on AppHarbor

noreply@blogger.com (Chris Sainty) — Thu, 16 Feb 2012 22:40:00 +0000

Last week I contributed a tiny piece of code to the Code52 Metro.css project. My contribution was a node script that creates a boilerplate Node.js website for you using the Metro.css styles, Express and wires up the LESS compilation.

Today I am going to run you through using this code to generate a site and push it to AppHarbor, who now support hosting Node.js sites.

I assume that you have Node.js and npm installed on your dev machine and referenced in the path. All of which should happen if you use the excellent Windows Installer package.

I also assume you have git installed and that you have created your AppHarbor account and added a new site. I have blogged about doing this before, their site has been updated since but the process is fairly similar.

While at AppHarbor you will need to do two things. The first is to take a copy of your repository URL, which is now accessed by pressing the button shown in this screenshot.

The second is to turn on file system write access. You do this from the settings page by enabling the checkbox shown below and hitting update application.

What this does is allow the LESS compiler to generate and cache CSS files on demand, rather than having to compile them in a build step.

Now let’s jump to the command line.

First we need to clone the metro.css repo from GitHub and jump into the node folder, which contains the scripts we need.

git clone https://github.com/Code52/metro.css.git
cd metro.css/node

Now we need to use npm to install the dependencies required by the script.

npm install

Next we generate our site, change to the generated folder and install the dependencies for our site.

node metro –i c:\projects\metrosite
cd \projects\metrosite
npm install

Simple as that, our site has been generated and is ready to be deployed. This whole process will look something like this.

If you want to see it running locally, just fire it up (node app.js) and point your browser to localhost using the port specified.

So to deploy to AppHarbor, we need to first create a git repository for our site, commit the changes and then push this commit up to AppHarbor. From the folder that contains our generated site (c:\projects\metrosite in my example) we do the following.

git init
git add .
git commit –m “Initial commit”
git remote add origin <YOUR APPHARBOUR REPOSITORY URL>
git push origin master

Which will look something like this, though I supressed the commit output for the purposes of the screenshot.

This sends your site up to AppHarbor, where it is loaded up and made live.

Back at AppHarbor, your application page will show the current build status. Usually the build will be fairly instant, but if the Status column has a little spinning indicator, then you will need to wait for the build to complete. Give it the occasional refresh.

When that is done, click the “Go to your application link” and marvel at your creation.

See my copy live at http://nodemetro.apphb.com/

Bug hunting in the public eye

noreply@blogger.com (Chris Sainty) — Thu, 02 Feb 2012 01:18:00 +0000

A few days ago, ayende put up a post showing a bug that had been found in RavenDb that was causing the profiling tools to enter an infinite loop.

http://ayende.com/blog/152738/bug-hunt-what-made-this-blog-slow

This was followed by a post about how this bug had come into being and survived so long.

http://ayende.com/blog/153825/ask-ayende-what-about-the-qa-env

So confession time, that’s my bug. I contributed the early code for the profiler.

So since then I have been trying to work out how I missed it. Was I really so oblivious to what was going on while writing that code?

Second to that, how had it sat in production on ayende’s blog for 6 months or so without being noticed?

I am glad to say I have an explanation for both, which I will share now.

First some background on how the profiling actually works.

When you attach your DocumentStore to the profile, the following code is run

Basically we attach to the OnSessionCreated event and stuff a header into the response with the session id.

This is very important, and the key to why this bug was missed. So I will say it again, the X-RavenDb-Profiling-Id header is only added to your response if you actually open a session.

So lets look at that JavaScript again.

It only calls back to the server when it gets an AJAX response that has the header set. So if you make an AJAX request to your server for data that does not come from RavenDb, the profiler will not pay any attention to that request.

The request to get the profiling results does not need a session, and in all my development it did not create a session. So it never set the header. So it never entered a loop.

So that explained to me how I had missed the bug, the way I deal with session management (creating and disposing of them only as needed) simply does not trigger the bug.

So with my conscience cleared, I moved on to the second problem. Just because I handle my session this way, clearly RacoonBlog does not, surely that bug hasn’t been there since ayende turned on the profiler for his blog.

Well let me present a commit to the RacoonBlog source from the very end of December.

https://github.com/ayende/RaccoonBlog/commit/b284efae61108af991221d948eb891e1310bc64b

In this commit, Racoon switched from creating sessions only as they are needed (my way of handling them) to creating the session in the BeginRequest event of *every* request. So even requests that don’t use the session still create one. Which obviously adds the profiling header and tells the JavaScript “this request hit RavenDb, so you should fetch it’s profiling results”.

So until that commit was pushed live RacoonBlog, like my own sites, simply did not trigger this bug, it was sitting there dormant just waiting for someone to take a different approach to session management.

So there we have it. I really don’t feel so bad about it now.

To a certain degree the JavaScript was actually correct. It noticed an AJAX request that said it had profiling information attached and it fetched that information. The fallacy in this argument though is that the JavaScript also has enough information available (the request URL) to know that it is being lied to. It should have used that information to avoid the trap that was laid for it. So it’s still a bug for all that I wish it were not.

Experiments in text adventure

noreply@blogger.com (Chris Sainty) — Tue, 31 Jan 2012 02:39:00 +0000

Like many who were into computers “back in the day” I still maintain a nostalgic, warm and fuzzy feeling at the memory of early text based adventure games.

Back when all I knew were the PRINT and INPUT commands in QBASIC, these were the very first programs I created.

Where am I going with this?

Well over the weekend I was learning the Impress.js presentation library and thought to myself that it really was a beautiful way to display text in a web browser. Then a little light bulb went off in my head.

3 hours later, I had forked impress.js and used it’s HTML5 canvas and CSS3 animations to create an engine for a modern text adventure game.

You can see the results of that intense session of programming here http://csainty.github.com/ImpressGame

I have quite a few other ideas for what I could do with this underlying concept. If it eventually comes together as I see it, it will be beautiful.

Getting deeper into Open Source

noreply@blogger.com (Chris Sainty) — Wed, 25 Jan 2012 23:07:00 +0000

It’s about 8 months since my first contribution to an open source project. It was followed up minutes later by one to reverse all the accidental formatting changes I made. Damn you Visual Studio!

I am happy to say that it was not an isolated contribution though.

Now I am by no means a prolific contributor and my spare time is more often spent tinkering with my own ideas and projects rather than working hard on open source. However, there has been a steady enough flow of pull requests and projects to keep me satisfied that I am at least involved.

RavenDb and Nancy are where most of my focus has been. Two great examples of modern C# open source development.

In my own right there have been RavenDb plugins for Glimpse and MvcMiniProfiler.

Straying from C# there is even a start being made on a Node.js client for RavenDb. Getting started with Node has been an absolute blast, and my first serious attempt at adding a new language to my skill set since C#. Sure I’ve dabbled with jQuery heavy javascript in the past to add a little life to a web page, but truly learning the object model and scoping rules of javascript is a different beast entirely.

Most recently, as in last week, I have been pitching in at Code52, a new idea for this year which tackles a new project every week. It has been very .NET focussed so far, but that is simply a product of the founding core of developers having .NET backgrounds. At the end of the day, the people who are in the chat room at the start of each project are the ones who decide the technology stack. I hope to get them doing a Node project at some point this year.

The project from last week was IdeaStrike a UserVoice inspired (clone?) site that you can simply deploy to AppHarbor and manage yourself to track ideas and gather feedback about your product. You can see it in action at http://ideastrike.apphb.com/.

It uses Nancy and Entity Framework. I wouldn’t call it a best practice example of either at the moment, it is tough to refactor a project that goes from start to finish in a week. It is however a good example of a non-trivial application, with (some) tests, in Nancy.

Even though the week is up, the project does not stop there. People are always welcome to fork, change, commit and send through a pull request.

A full list of previous projects, that will update over the year, can be found at http://code52.org/projects.html.

This week the focus is a cross-platform multiplayer game. Much further out of my comfort zone, but a great chance to learn some XNA, and eventually Android and iOS when those clients are added.

Now this is a fairly reflective post, not my usual style, but the point is really just to spread the word. There are lots of interesting projects around, big and small, in almost any language you care to use. Just pick one and jump in.

Running a NodeJS server alongside your NodeJS desktop app

noreply@blogger.com (Chris Sainty) — Mon, 16 Jan 2012 07:50:00 +0000

The node-webkit project added a new feature yesterday, one which I requested. So I feel I should put up a quick post about it and why I think it could be useful.

The change was simple enough, giving you the ability to pass a callback to node-webkit that is called when the application is closing.

The primary reason I wanted this was to allow you to create, and then clean up, a local web server within the lifetime of your application.

It was previously possible to create the server, but when you closed the app, the process would stay open with the webserver waiting for requests.

The callback looks something like this.

So why exactly is this useful? Well I have a couple of uses in mind.

Some libraries and UI controls have only been coded to fetch their data with an HTTP request. This gives you a simple way of using such a library or control. You just point it at the local server and handle the request.
If you did all data access across the HTTP layer, then you remove one more piece of uncommon code between a web and desktop application, now the difference between the two is just the URL it is pointing at.
It allows you to pre-process previously static files. This means you could compile your LESS or CoffeeScript files as they are being served. It also means you could serve HTML from a ViewEngine such as Jade instead of from static files on disk.

Further thoughts on NodeJS desktop applications

noreply@blogger.com (Chris Sainty) — Fri, 13 Jan 2012 00:47:00 +0000

I have been working on a more complete demo of creating a desktop app with NodeJS.

This one will use a full UI (KendoUI) and a Sqlite database to create a basic CRUD style app based on the Northwind dataset. Someone really needs to put together another (and actually well designed) standard database that people can use for apps like this.

While putting this together I have been considering reasons why you might actually write an application like this.

Something that dawned on me is that I am only really using Node in a very thin data layer. My Views and View Models are all standard HTML/JS. Which means the only thing I would need to do to switch this application I am writing to being on the web would be to replace the data layer which is currently using Node to access Sqlite with one that goes across the network to a REST service.

This means I am effectively writing an identical web and desktop app at the same time. Which opens up some interesting offline capabilities.

Add a build time dependency injector to switch between the Node and REST data layers, and a synchronisation mechanism (assuming you want the user to be able to use either) and you have the web and desktop versions of your app running the exact same codebase.

Now that is pretty darn interesting.

Creating desktop apps with NodeJS

noreply@blogger.com (Chris Sainty) — Tue, 10 Jan 2012 05:40:00 +0000

Last week an interesting thread was started on the NodeJS mailing list.

https://groups.google.com/d/msg/nodejs/iy7Re33dwyU/yxwLlx1aUNMJ

Roger Wang from the Intel Open Source Technology Center posted about a new project from their team called node-webkit.

https://github.com/rogerwang/node-webkit

node-webkit brings WebKit to NodeJS. With it, client side applications
can be written with a HTML/CSS UI on NodeJS platform. We believe the
async I/O framework and Javascript language is a perfect combination for
client (mobile) side applications.

Basically it allows you to write HTML/JS/Node client side applications using webkit as the renderer.

This is very interesting, and in some respects like the path Microsoft are taking with the HTML/JS WinRT in Windows 8.

Currently this is Linux only. But with Node and WebKit both being cross-platform, it is only a matter of time until it gets onto other platforms.

Getting started with a fresh Ubuntu 11.10 install in a VM I had to do the following to get it all installed.

Open up a text editor and edit the file /etc/apt/sources.list
Add a new line at the end “deb http://libwebkitnode.s3.amazonaws.com/ oneiric/”
sudo apt-get update
sudo apt-get install git-core nodejs-dev libwebkitnode-dev libev-dev
git clone https://github.com/rogerwang/node-webkit.git
cd node-webkit
node-waf configure build

You can then test it is running with “node tests/helloworld.js tests/testfs.html”

If everything goes to plan you, up should pop a window that lists the files in the current directory.

Take a look at the tests/testfs.html to see how they have done that.

Now on to my first test project. I am once again making a twitter search, it really is one of the easiest APIs around to quickly run up a test against.

All the below code is on github at https://github.com/csainty/node-webkit-twitter

One note, I put a copy of the node-webkit into the node_modules folder. I am sure it will come to npm eventually, but for now this was the easiest method.
When I tried to reference it from it’s own folder, it could be found, but then my other dependencies couldn’t. I must be misunderstanding something there.

Our app.js is very simple, this is the entry point to the app, configures the webkit browser surface and loads an initial page.

index.html is also pretty straight forward, it is just basic HTML with Knockout bindings. It includes script references for jQuery, Knockout and our own index.js

Now for index.js, this is where the really interesting code is.

You can freely mix your traditional browser based HTML with your node.

So we call in our dependency on the request module.
We then use jQuery to delay our execution until the page is loaded.
We use Knockout to create our ViewModel which binds itself to the HTML.
Then in the search function on the ViewModel we call out to request to fetch the data from twitter.

Now of cource everything in this little demo can be done client side already. But I wanted to keep it simple, we can get to the filesystem (as the intel demo shows) and we can use existing libraries to get to a database or other persistence layer.

To fire it up just run “node app.js”

I hope to put together a more in-depth demo soon, one that involves local storage, and one of the HTML5 UI frameworks to pretty it up a bit. I’ll keep you posted on how that goes.

Remember I am on twitter these days as well @csainty. So follow me there if you want to know what I am up to.

Tutorial: Nancy + MongoDb + AppHarbor

noreply@blogger.com (Chris Sainty) — Tue, 29 Nov 2011 22:32:00 +0000

Time for a quick tutorial on how to get a site up and running on AppHarbor using Nancy and MongoDb.

First up you are going to need Git installed. On windows my preference for Git is this kit http://code.google.com/p/gitextensions/. It installs everything you need and gives you a nice GUI to work with plus some basic integrations with Visual Studio.

(Just in case you have missed the craze that is Git, it is a version control system. A very good one. Go learn about it)

Next you will need NuGet.

(In case you missed nuget, it is a package manager for .NET development. Use it to maintain third party libraries you are using in your applications)

Finally, you are also going to need an account at AppHarbor.

(In case you have missed AppHarbor, it is a new form of hosting for asp.net web applications. You push your code to their server, they build it, run your unit tests and then deploy it. From there you can scale the application and install add-ons etc.)

The end result of this tutorial is the app hosted on AppHarbor here http://nancymongo.apphb.com/ which is a basic message posting app that I have used before when playing around with Nancy. It super simple and boils down to two api methods with a page to interact with them.

All the code is on GitHub here https://github.com/csainty/NancyMongo

Setting up AppHarbor

We are going to start with AppHarbor, once you have an account set up, go to the Applications page and create a new application.

This will give you the URL for your git repository where we will later be pushing the code. So keep this page open or the URL handy.

Down the bottom of this page is an Add-ons section. Hit “View Available Add-ons”

As you can see there are quite a few, since we are using Mongo here, Click through to MongoHQ.

MongoHQ are a hosted MongoDb provider, they are partnered up with AppHarbor so that it is a single click install to create an instance on their servers for your AppHarbor site. Even better, the build process on AppHarbor will perform a replacement on your web.config file to insert the correct URL to the instance. So you can have a development/testing server configured locally and when you push to the server it will switch to the production server for you!

Add the free sandbox MongoDb instance to your site.

You should be sent back to the application page with a message saying your instance is configured. Now if you click through to the “Variables” tab you can see a MONGOHQ_URL variable. Any values set up in this tab will be added/replaced in the AppSettings section of your web.config file at build time.

We are going to break with convention here a little. Normally you do not need to know the value of that key since it is the production server. But to save us setting up test/dev MongoDb instance on our own machines, we are going to point at it for development as well. There is some CSS on the page that truncates the value, but if you view source and search for mongodb:// you can get the full value.

It includes your username, password and database name. So don’t go sharing this value, and if you are pushing your code to the public, make sure you remove it first, like I have.

Keep that value at hand, it’s time to jump into Visual Studio.

Building our App

Create a new ASP.NET Empty Web Application.

Fire up NuGet (either the GUI from right clicking the references folder in your project and choosing Manage NuGet Packages, or from the command line)

Install the following packages by searching for them and hitting the install button

Nancy
Nancy.Hosting.AspNet
KnockoutJS
Official MongoDb C# driver
NuGetPowerTools

One more thing with NuGet, we are going to need to jump into the NuGet “Package Manager Console” from the Tools menu | Library Package Manager sub-menu

Once the console loads type “enable-packagerestore” and hit enter.

This command was added by the nugetpowertools and adds a build step into your project file that ensures all the nuget dependencies have been downloaded. This is very useful since you are not going to be uploading a compiled application to AppHarbor, you are sending up your source which is built on their servers. So you have to give them the dependencies some way, and the alternative is to commit them all to your git repository. Doing this bloats your repository for no good reason. Trust me, this step is worth doing on every project you use NuGet for.

Once that completes you can close the package manager console.

Now open you your web.config file and add an AppSetting of MONGOHQ_URL with the value you grabbed from AppHarbor.

Just to stress this point one more time, normally you are going to have a dev/test server. You would be putting it’s URL in here and letting AppHarbor override it with the production URL when you publish.

Now on to some code, to start with add a Models folder with a single Message.cs class.

Note the Attribute on the Id field, this tells the MongoDb driver which field is the Id and how to generate an Id for that field. There are many different options for Id generation, we are using one of the string methods.

Now we are going to need a bootstrapper (CustomBootstrapper.cs) to configure Nancy and our Dependency Injection.

Bootstrappers are the starting point for all Nancy sites that do a bit more than Hello World.

First we are adding the Scripts folder as a static content folder. This tells Nancy to automatically handle requests to the Scripts folder as static file requests. The Content folder is added by default, though we don’t use it in this project. There are a number of overrides on the builder we are using here to customise how the mapping works.

Next we hook up Dependency injection on the various MongoDb driver classes we might want to get a handle on. This localises all our creation and init code so that our Modules can just request what they need and let the injection container provide it.

Basically we are creating our Server instance using the connection string from web.config then pulling the database name off this connection string to grab out Database instance, we then create a Collection for our Messages to be stored in. The C# MongoDb driver actually manages it’s own object life time, so even if we called MongoServer.Create() multiple times we would always get back the same instance, but I still like to use Dependency Injection rather than have to create these time and time again in my module code.

So let’s look at the two Modules (PageModule.cs and ApiModule.cs)

A Module in Nancy is where we wire up how the web server is going to response to requests. I cover it off in this blog post as well. We inject the Messages collection straight into our Api module without having to worry about how it is being created, or what it’s lifetime is.

Then finally we have the View (Views/Homepage.html), which is essentially a static HTML page and is processed by the built in view engine.

So now we have all the code files in place, run it up and make sure it all works, when it does, it is time to deploy.

Creating our Git Repo

Now we have a working project, lets put it into Git and send it up to AppHarbor.

Fir up the GitExtensions GUI and select “Create new repository”

Choose the folder your solution is in and Initialize as a personal repo. (Pro tip: Init a bare repository in your dropbox/mesh folder and push to it for easy offsite backup)

Now you need to edit your .gitignore folder to tell it what files to include and exclude from your folders.

Start by hitting the “Add default” button, remove the *.exe line as we want to include the nuget.exe which was added by NuGetPowerTools. Then add a line “[P]ackages\” at the bottom to filter out the packages folder. This folder contains all the NuGet packages which will be downloaded on the AppHarbor build server by NuGetPowerTools.

Now you should be able to Commit the changes from the Commands menu.

Deploying to AppHarbor

Still in GitExtensions, from the Remotes menu choose “manage remote repositories”, click the new button, give it a name and paste in the Git url you were provided when creating your AppHarbor application. Remotes are simply other copies of a repository that you can push code to and pull code from.

You can then “Push” to this remote (again from the commands menu), which will being the build and deployment process on AppHarbor.

One thing to watch out for, with OpenSSH selected as your SSH client (chosen when installing Git Extensions) you will have a black window pop up during the push, this is actually asking you for your AppHarbor password, type it in, or right-click and paste (Dont Ctrl-V) and press enter. Not sure what happens if you are using PuTTY.

If I get a chance I hope to look into the GitExtensions code and improve this if at all possible.

It Lives!

Now if you go back to your application page in AppHarbor and refresh you should be presented with something like this.

You will have the status of your build, which you can dig into to get the full console output from the build process. Assuming the build worked, you will also have a link to your app. Click it and be amazed.

Learn Something New: Node

noreply@blogger.com (Chris Sainty) — Thu, 27 Oct 2011 05:52:00 +0000

Node seems to be everywhere at the moment. Long on my list of things to take a look at, I finally took the time to sit down with it yesterday and get it up and running and get a feel for what it does.

In the process I also took my first look at Heroku, which is the cloud hosting platform for Ruby, Node, Java etc. that AppHarbor borrows heavily from in the .NET world.

As always, my code is on GitHub, and the site is live on Heroku. This sample is literally a Hello World, with so many moving parts, I really wanted to just focus on the raw details of getting Node running first in a Linux VM, then on Windows, then on Heroku.

Both Node and Heroku provide great instructions to get everything up and running, so they should be your first port of call.

https://github.com/joyent/node/wiki/Installation

http://devcenter.heroku.com/articles/node-js

With how easy Node is to get running on Windows now, there really is no excuse not to give it a go.

Simply download the stand-alone node.exe from here.

Put it in a folder, and create a HelloWorld.js file with the following content.

Then run node HelloWorld.js and hit http://localhost:8080/ in your browser.

At it’s heart, Node is about IO and sockets. It is not specifically about the web, people have just seen how useful it can be for web development.

Before you get too far into it, you are likely to want to start plugging in some other packages, such as a routing framework to manage your requests and a view engine to render your HTML>

This is where the Node Package Manager (npm) comes in. The node install instructions linked above explain how to install this on windows, which has been seamless for me so far.

You probably want to look at express for the general framework roles and jade for a view engine.

Another recent blog post I will call out to take a look at is Jon Galloway’s effort today which includes a lot of detail and goes into hosting the node.exe process inside IIS on windows servers.

I had a real sense of joy when I fired up Node and started fiddling around. I am fairly comfortable in javascript, and going back into a straight text editor to write my code was a bit like stepping back in time to my teenage years hacking away in qbasic. While my initial investigations were only skin deep, I definitely see myself taking a much deeper look very soon.

My Windows Phone 7 thinks it is developer locked?

noreply@blogger.com (Chris Sainty) — Mon, 24 Oct 2011 23:44:00 +0000

I ran into an interesting problem today that warrants a blog post to hopefully help someone searching when they hit it themselves.

Last night, I turned on my phone only to be greeted with a helpful message informing me that my application gReadie had been revoked by Microsoft and that I should uninstall it.

After a moment of panic, I realised that I didn’t actually have a retail copy of gReadie installed on my phone, just the developer build I had been working on. So I didn’t think a lot more about it intending just to copy a new version on when I arrived at the office this morning.

That plan failed though when Visual Studio informed me my device was developer locked, and I could not deploy my application.

Strange.

So I ran the developer unlock tool, it connected to App Hub, then to my device and said my phone was unlocked again. Great, back into Visual Studio, and up pops the same error.

After a quick tweet to vent my frustration, I gave everything a reboot, unlocked again, and still no luck.

At this point I logged into App Hub, to check my registration was still valid and see what was up with my device.

To do this, click you name in the top right corner, then choose the devices tab.

Bingo!

Chris’ Phone, Registered 24th Oct 2010, Expiration Date 24th Oct 2011.

My unlock registration had expired, and the phone unlock tool shipped with the phone tools does not renew it.

So I simply hit the remove button inside App Hub, went through the unlock tool once more, and everything was working again.

So keep this in mind as you approach your one year anniversary of owning an unlocked WP7 device. You will need to pop into App Hub and renew the unlock registration yourself.

I’m now on Twitter

noreply@blogger.com (Chris Sainty) — Wed, 12 Oct 2011 00:47:00 +0000

Just a quick FYI to let people know I am now on Twitter with my own account @csainty.

Up until now I have been using the @quidsmobile account for a mix of personal comments and supporting gReadie. It will go full-time WP7 app support now.

All my blog posts will be announced on my new personal account, along with other little comments on programming and tech.