Andy Butland

Umbraco CMS have recently moved their source code from CodePlex to Github which has triggered a flurry of contributions in the form of pull requests. Previously I had made a few small contributions to the project whilst on Codeplex and have now submitted some to Github. Whilst GitHub is very easy to use and has excellent documentation I managed to get in a bit of a tangle trying to manage different issues, so mostly for my own future benefit, am noting two working processes here. If anyone else reads, first port of call should be the Umbraco contribution documentation and GiHub's own help pages on forking and pull requests . One issue is that like other source control hosts, only one pull request can be submitted per branch. In order to keep things simple for the person on the other end, it makes sense not to combine several issues into one pull request. Hence coding the first issue in master branch, pull requesting, and then trying to move onto a second in master branch

Been spending a bit of time recently looking at JavaScript frameworks, and having a prototype project avaialble as an excuse to work on something, built a small application using Durandal . Have been concious recently that my front-end code wasn't nearly as structured and well organised as that I would write on the server side, and found this a great library for helping organise this code into modules. It also utilises knockout for UI binding via view models and views. Mostly the app runs as a SPA, though the prototype had an additional requirement to support offline access on devices. To support that I planned to package up the app using PhoneGap . That's the background... mainly though for this blog post wanted to record some links and notes for getting set up with this framework, and in particular the phonegap build service . Firstly I looked to use local PhoneGap. To get running found a couple of handy links: From PhoneGap themselves And from Clean Code Devel

This is the last of a three part series of posts on BackgammonR – an online Backgammon game built with SignalR. If you haven’t read it already, please see Part 1 – Game Engine and Part 2 – Server Side SignalR The first bit of JavaScript to note is not actually something you write, rather what SignalR generates in order for it to allow for the messages to be passed between client and server and vice versa. It’s at /signalr/hubs/ and if you view it you’ll can see how the methods defined on the server-side hub are exposed to the client. The script I have written though lives in /public/site/backgammon.js and whilst it consists of a number of methods it can be considered in three main sections. Data Binding Before getting into the client-side SignalR code it’s worth flagging up the other libraries I’ve used here. Jquery of course. But also knockout , which provides a nice separation between the intricacies of the UI and the details of the client-side model manipulated in co

This is the second of a three part series of posts on BackgammonR – an online Backgammon game built with SignalR. If you haven’t read it already, please see Part 1 – Game Engine . SignalR actually provides two abstractions above the base technologies for maintaining persistent connections between browser and server. One is fairly low-level, called PersistentConnection that I didn’t look into. The other is Hubs . I have a single SignalR hub called GameNotificationHub which inherits from Microsoft.AspNet.SignalR.Hub and thus obtains its base functionality. Within that class you can create public methods, which – once SignalR has worked its magic – become end-points that can be called from the client-side JavaScript. They all return void though – which initially seems counter-intuitive and not what you would do were you wiring up an end-point for an AJAX request for example. However the point is of course that with this type of application we may need to push responses to th

There’s no doubt who the cool kid on the block is when it comes to the “one ASP.Net” stack – SignalR , a library created to simplify the process of creating responsive applications that push AND receive notifications from the server. It provides a wrapper around a range of technologies that can provide persistent or semi-persistent connections, choosing the best available when the full chain from browser to server is taken into account. Wanting to look into this technology with a project that’s at least semi-real, I was inspired by an article in a recent edition of the digital magazine Dot Net Curry where the author created a game of noughts and crosses (or tick-tac-toe). Chess was going to be beyond me for sure, but I figured a game of Backgammon might be feasible to get running. Hence BackgammonR – for some reason all apps using the technology need to end with a capital R. The application I’ve built so far so far is running here on Azure . And code should anyone want to look

Tricky issue with the above 4 in one app... IE was blocking a session cookie from my ASP.Net MVC web application when hosted in the Facebook IFRAME. The anti-forgery token in ASP.Net (used to protected against spoof form posts known as CSRF attacks) would fail saying the cookie it was checking against couldn't be found. Turns out the issue was that in medium security settings, IE will "block third-party cookies that do not have a compact privacy policy". And as the app is in the IFRAME it is considered third party with respect to Facebook. To resolve I needed two things: 1) an XML file located at /w3c/p3p.xml containing <META xmlns="http://www.w3.org/2002/01/P3Pv1"> <POLICY-REFERENCES> <EXPIRY max-age="10000000"/> </POLICY-REFERENCES> </META> 2) and a header emitted (in server side code, the meta tag equivalent didn't seem to suffice) Response.AppendHeader("P3P", "CP='IDC DS

I've recently been working on a web application that required localisation - the display of translated copy depending on which country the user was visiting from. There was a different sub-domain for each country which was used to identify the appropriate one. It was also a requirement that the editor's of the website could update the translated copy from a simple back-office tool. For most of the copy of the website this was fairly straightforward to set up. I had a database table called Texts that contained three columns: Country, Key and Value. And hence by looking up for a particular country and key I could get the text to display. To ensure this was performant in practice what I did for each web request was to look up all the keys and values for the appropriate market and populate a dictionary object. The look-up was cached using so I was only hitting the database when I needed to rather than on every request. I then created a base view model that all other view mo