What a crazy year this has been! A year ago my girlfriend and I had just started construction of our new house, so we were living temporarily in a ruin from 1892 and I was working at d60 in Vanløse. Now we are all settled in our house, Elisabeth is now my wife, she is starting her phd, and I have been working as an independent consultant for 11 months!

So it has been a very busy year for os, and I do hope 2015 will be a little less action packed, with time to enjoy our new lives and do some travelling. A trip to Barcelona is already in the cards, so it is looking promising.

Becomming independent

Starting as an independent consultant was something I had been considering for a while. When we moved I chose to go for the job at d60, because it was a good chance to build a new team. Long story short, that didn't go as I had hoped, so when opportunities presented themselves that would make starting on my own fairly smooth I had to seize the moment, and I am really glad I did. I have really enjoyed the freedom, the chance to work on very different projects and the improved possibilities to speak at conferences.

During these 11 months a have amongst other things built a workschedule module and a budgetting module, I redesigned a big webapplication, wrote an fairly large API, worked on components for QlikView, wrote a tool for calculating distance matrices for a logistics company and started work as a consultant on a large ecommerce project. So it has been really exciting and a lot of fun. When it comes to speaking I have been at the Warm Crocodile Conference, DDC, NDC, CNUG, Visma, Ida, Keyboard Warriors and Campusdays where I have been talking about Firebase, Angular, Azure and Single Page Application patterns. I tend to agree that the one thing that is more fun than programming is speaking about programming, so I have enjoyed all my talks and I hope to have time for pleanty of more talks next year.

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.

As I wrote before the conference I was glad to see some good speakers on the Microsoft track. So of course I prioritized a couple of these sessions, and went to Mads Torgersens C# talk and to Mads Kristensen talking about tooling in ASP.NET. Well technically Thorgersens talk was on the architecture track, but you get the point.

The new world after Roslyn

The C# talk went a bit more into writing analyzers and codefixes than what I had seen before, so that was quite interesting and one of the very concretely usefull takeaways. The idea is that writing an analyzer is just like working with any object model. No more magic, so writing extentions is becomming something any developer can do and no longer reserved for the minority with too much time on their hands. Torgersen also demoed some of the new language features that I blogged about earlier, but on top of that let slide that primary constructors probably won't make it into the language for the final release  in the comming version. The reason is that they want to do more and look at providing recordtypes as well as pattern matching - and want to make sure that they get it right. These are two great features that I miss from F# on a daily basis, so I was glad to hear this. I also aired the idea of make shorthands for stuff like factory methods, which could also reduce some of the boilerplate code that I see a lot.

At other conferences I have attended the last year or so, distribution and concurrency have been hot topics, coupled with functional programming and immutability which leands itself well to these kinds of problems. Todays program has certainly been no exception - at least for the talks I ended up picking.

The right Elixir for concurrent fault tolerant systems

In the afternoon I ended up sticking with the bleeding edge track, which has been really interesting. First off was a talk on Idioms of distributed applications with Elixir by Jose Valim, who wrote the language. In his talk Jose went over the idioms of Erlang, which is what Elixir is built on top of. He did a good job at presenting why light weight processes that are allowed to fail fast and recreated by supervisors makes it possible to build fault tolerant distributed systems that are easier to understand and run faster than other paradigmes often based on handeling exceptions via try catch blocks.

More...

So first day of GOTO in Copenhagen has kicked off, with a somewhat provocative talk entitled "Does the browser have a future?" by Tim Bray - the farther of XML. His initial point was that the browser being declared dead hardly is a new thing since this also happened on the frontpage of Wired magazine in both 1997 and 2010.

A backend detour

Tim went on a detour to cover how this is the golden era of backend development, where life is good because you have few interfaces and testing is easy because it is machines talking to machines. He went over how Erlang, Clojure and Scala are popular but probably not the answer, where he was more optimistic about Go. This should hardly be a surprise, because he has been working at google for a number of years until quite recently. He did however make some good points about having a simple way to work with asyncronicity in a simple language. In the same way he made a short argument that it is also the golden era of persistence, with big companies using NoSQL solutions like Cassandra that enables them to build huge systems that scale with relative ease.

More...

Sorry, but I can't help myself when a pun like this comes up. A couple of weeks ago Microsoft released previews of two new databases on Azure, called Azure Search and Azure DocumentDB. These two services make the storage story on Azure much more complete, for the needs of many a software developer. At least from my experience, they close a significant gap, where I have often gone "outside Azure", for something that would seem obvious for them to offer.

Providing feedback

I have mostly been looking at DocumentDB, because it is more general purpose and because it is completely new - where Azure Search is built on top of Elastic Search. Having played a bit with the preview I am pretty excited to see how DocumentDB will progress. Certainly more than Ayende, who was quick to jump on the bashwagon - but of course he would hardly be doing his work if he didn't. As I wrote on twitter, I am excited about the idea, although I also feel that it has quite a bit of way to go before I would use it for production software.

As it turnes out, that tweet was read by the team building DocumentDB, so shortly after I was contacted and have been writing to them about my two cents on the subject. Suffice to say, that I like their openness and most of the answers that I am getting about where they are going. I was especially happy to hear that the preview version is limited with reguard to request sizes, and that performance is a key area of focus, so they will be looking at the feedback that they get on this.

From this experience I encourage everyone to give the team feedback. It can become a very good database, but as with a lot of projects, they need feedback.

More...

Its a good thing I wrote my last blogpost when I did – otherwise I would not have had the chance to complain about the missing Microsoft track :) Shortly after I published my post, the conference announced just that track, and that Mads Kristensen is doing one of the talks on web tooling for ASP.NET. As a web-guy, that is really nice to hear, because Mads tends to have a bunch of good ideas to share, and he always gives a good talk.

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...

This week I was at NDC Oslo, and besides seeing a bunch of awesome talks and having fun with equally geeky people I got to talk about building realtime applications with Firebase, AngularJS and EmberJS. It’s a topic I like, because I can give the audience something very tangable that they can try. On top of that it is a chance to build types of applications that were quite difficult just a few years ago – but now it has become almost trivial.

The awesome people behind the conference have already made the video from my talk available here.

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...