One of the really nice things about Azure Webapps is the support for running Webjobs. Most large webapplications will at some point need some data or media processed by a background process, and for that Webjobs are a perfect fit.

More...

Xplat has been the big topic around ASP.NET 5, but to be honest it does not matter that much for many of us. Sure it is always nice to have options, but if you work in a Microsoft shop or at an enterprise who see them selves as based on Microsoft technologies, then that is not likely to change - and why should it? The good news is that taking the framework and tooling apart to enable these options also brings a more aligned and flexible architecture, that solves some of the issues with eg. build setups that we have today. With that said, xplat is not all that ASP.NET 5 is about.

More...

With ASP.NET 5 which is currently in Beta 8, Microsoft has launched a new web server named Kestrel, which is of course Open Source. There are a number of reasons they are building Kestrel, but most importantly to provide a cross-platform web server which does not rely on System.Web and a full version of the CLR in order to bootstrap the new execution environment (DNX) and CoreCLR - which was not possible with Helios.

More...

Today GOTO Copenhagen was kicked off and it has been packed with good talks. The keynote was by Anita Sengupta, who talked about working on descent and landing on Mars based on her work at NASA. Amasingly interesting subject, and some really extreme conditions that these people work under. To illustrate it takes 7 minutes from when they enter the atmosphere on Mars until the robot has landed, but the signal takes 14 minutes minutes from it is sent until it reaches control on earth. More...

Pleanty of people have said that concurrency and functional programming are becomming essential to developing modern systems. Some have even gone so far as to say that if you don't adapt you will become a maintenance programmer in a few years. With the increasing need for concurrency to provide speed and handeling of huge amounts of data, I beleive it to be true. I do however beleive there will still be pleanty of smaller applications, so I am not predicting doomesday for anyone quite yet.

More...

Fantastic times! I just got back from a week off around easter, summer is almost here and I was awarded Microsoft MVP for ASP.NET/IIS for the first time. So all I that is missing is getting some blogging done.

At the moment I am really enjoying TypeScript, and I am feeling really good abouts future with the recent collaboration between the TypeScript and AnguarJS teams. I still argue that in most cases where you want your solution to live long, you should avoid the SPA frameworks. However I concede that they are popular, so it is a good step for TypeScript, which I think will help the adoption. I also think it will be good for Angular 2.0, to avoid introducing their own new language, and instead get the benefits of the good work done on TypeScript itself as well as tooling.

More...

Lately I have been speaking quite a bit about building Single Page Applications. Most recently I have been arguing that we skipped the discussion of weather or not we need a framework at all to build a Single Page Applications? Everyone quickly got into the battle of the frameworks, and argued about the good and bad parts of Angular, Ember, Durandal and a bunch of other contenders to the throne. These days I would argue that Angular won, which is supported by google batteling the frameworks, looking at training courses offered and joblistings. As a .NET developer this is furtner obvious now that AngularJS is part of the ASP.NET package, and samples are showing up that use it for Apache Cordova applications, which are also being embraced by Microsoft.

However, the more I have been working with these frameworks, the more I have started to question their actual value. At least to a point where I think it is something we need to think more about, when choosing which way to go. Sure frameworks give you a nice package that tackles application structure, routing, templating, two-way binding and dataaccess - but at what price? Using a framework, always means letting someone else decide a lot of things on your behalf, and it means taking a dependency on a large codebase. So in this blogpost, I will try and make the case for growing your own architecture.

You might think "so what, we do that all the time, we shoulden't be reinventing the wheel and what does it matter to depend on a framework". If they provide enough value I would surely agree, but it should always be measured against the risks of vendor lockin, issues with breaking changes, performance implications and restrictions on growing your application going forward. With a fast evolving web, these issues are very real. A framework might still be a good choice, but we need to at least think about the pros and cons.

Two-way binding is a huge sinner when it comes to performance and modelling restrictions, if the model chosen is not right for what you are building. Breaking changes are hurting developers daily, and with both Angular and Durandal looking to be complete rewrites for their next versions - so if you use them, you will be stuck with the current version, or you will be doing a rewrite of your own fairly soon.

A client of mine requested an integration with OpenWeatherMap, so like so many times before it was a chance to think about how to make such an integration robust and performant. Its as common a task as they come, but also something that tends to end up feeling more complex than I would like. Having heard a lot of good things and played a bit with Redis I felt that it would be a good choice for providing super fast caching, while also allowing for more than basic key/value storage.

Getting off the ground

The project is already running on Azure, so it was an obvious choice to give Azures new Redis based caching service a go. As of now the service is still in preview, but the the level of caching I need I feel quite comfortable with it. Getting started was as easy as most things on Azure - click add, fill in a name and press go. As every day as this has become, I am still blown away by how easy and fast it is every time I need to provision a new VM or service – and a Redis cache is no different.

On the downside I am not quite convinced by the new Azure portal, because to me the UX feels more shiny than useful. As of this writing the caching service is only available through the portal, but inspite of my reservations it was easy to get going, and it provides a nice overview of requests, storage space used as well as cache hits and misses.

More...

Lately I have spent a bit of time with NDepend, who contacted me if I wanted a free license, in exchange for a blogpost. This was actually great timing on their part, as I was already thinking about giving it another go. Being completely honest I tried NDepend some years ago, and at the time I simply didn't know where to start and where I would get the most value from using such a tool. So back then I pretty much wrote it off, but have again and again heard good things from other developers who are using it.

My first thought when I ran NDepend this time around was that a lot had changed. The first thing that met me was a wizard for analysing a project, so I pointed it at my current project. This was the point I got derailed the first time I tried NDepend, because I remember being met by the code metric view which does look kind of scary - especially being new to a tool like this. Now however I was met by a dashboard, that is still complex, but a vast improvement since it gives a pretty good idea of some of the power that NDepend provides. I still can't help think that the tool could gain a lot by providing simpler guides through some key usecases though.

More...

Since the amount of javascript in an average website has exploded, the need to unittest that code has become apparent. I think we are still a bit behind in this respect, as I often hear from people don’t know what “the right way” is to create such as setup. Sadly this seems to mean that they never got off the ground and skip testing clientside. Without starting any kind of war on this, I think most of us like at least some number of tests and the option to do TDD.

Well I may already have painted myself into a corner, as I don’t claim to know the one and only “right way”, but I have found a way of going about it that I really like and have fun with. Shortly put, I have been playing around with Mocha.js and Should.js – supported by the Chutzpah test-runner and testem that allows a light weight way of running tests while doing TDD.