Wednesday, December 7, 2016

Thoughtworks Technology Radar: Angular 2

On regular intervals, the people from ThoughtWorks release a Technology Radar update. Through this radar they share their thoughts on the technology and trends that are coming and going.


On multiple levels(Techniques, Tools, Platforms, Languages & Frameworks) they share if you should adopt, try, assess or move away(hold) from a technology and/or trend.

In the november 2016 update I noticed something interesting in the Languages & Frameworks. Where 2015 was the year of Angular.js, I noticed that no Angular could be found in the Adopt/Trial/Assess section. Instead you could find web frameworks and libraries like Ember.js, React.js and even Aurelia.

AngularJS could be found in the ‘hold’ section:


I’m wondering why they didn’t mention anything about Angular 2…

Tuesday, December 6, 2016

TypeScript File index.d.ts is not a module

After publishing my blog post yesterday about type definition files I got a problem when I tried to do the same thing for Modernizr:


Visual Studio finds my @types files but complains that it is not a valid module. In fact this makes sense. When using the import syntax, Typescript is looking for a 'module' i.e. a commonjs, amd, systemjs or umd module. Modernizr is added to the global namespace and is not available as a module.

To get intellisense, I have to use the ///<reference path=””/> syntax


Monday, December 5, 2016

Getting Type declarations in TypeScript 2.0

TypeScript has the concept of Type Definition files to provide TypeScript metadata for libraries that are not written in TypeScript. These TypeScripts files are maintained by the community and available at the DefinitelyTyped repo on GitHub. Before TypeScript 2.0 these type definition files were published on NuGet(Microsofts own package manager). As the TypeScript community kept growing and people outside the Microsoft ecosystem started using it, Microsoft decided to switch to npm as the package source for all type definitions.

So starting from TypeScript 2.0 you require no tools apart from npm. Let’s try this!

  • Open a web application in Visual Studio
  • Right click on your project and choose Quick Install Package… from the context menu
    • Note: if you don’t have this option, go install the Package Installer extension first


  • The Quick Install Package window is loaded. Choose NPM from the list of package managers and specify the library for which you want to load type definition files using the @types/<library> syntax.


  • Click on Install. After the NPM package is downloaded and installed, you can find it inside the node_modules folder of your project:


  • To use the library inside your TypeScript files, import the module and you’ll see that Visual Studio will search(and hopefully find) the related type information:


More information at

Friday, December 2, 2016

Block access to a specific folder in your ASP.NET MVC website

One way to block access to a specific folder in your ASP.NET MVC website is by combining the <location> with an <authorization> section inside your web.config:

In fact this is not the best approach as it is possible that this configuration is not applied when the ASP.NET pipeline is not invoked.

A better approach is to block the access at the IIS level by using the following configuration inside your web.config:

Thursday, December 1, 2016

The CRAP cycle and how to break it…

Did you ever hear about the CRAP cycle, the Create/Repair/Abandon/rePlace cycle?

You build an application. Over time you accumulate some technical debt. The application becomes harder to maintain. Developers start avoiding and working around certain aspects of the code. Maintenance becomes more and more expensive. Developers complain. New features become harder and harder to write and cost more. Business complain. The application becomes too complex to maintain, we abandon it and start replacing it. Only this time “we are doing it right!”. And of course we make the same mistakes. And the loop starts again…


How can we break this circle? What can we do to avoid it? Or is it an unbreakable law of software?

I don’t think it has to be. The problem is that most of the time architecture, code quality and a common set of guidelines are only applied at the beginning of a project. Although most applications are built using an iterative approach, the time spent in guarding the quality of the project decreases over time. And when the project finally arrives in maintenance mode, no one cares. The budget is gone, so every fix should be done as cheap as possible…

One the reasons is that the best developers/architects are assigned to new projects and that the lesser gods need to maintain it. This is really unfortunate both for developers/architects that move on(because they cannot learn from their mistakes) and for the poor guys/girls that need to maintain the project(because they get little room for improvement).

When is the last time you had to maintain the code you wrote?

Wednesday, November 30, 2016

NIST is bringing some common sense to password policies

As a consultant I’m frequently confronted with strange password policies. Every company I visit has different password rules with different expiration windows and so on. Although a password manager helps me to keep my sanity, I have a hard time understanding some of the multipage password rules that customers are using.

But ok, if it makes our systems more secure, it’s a burden I’m willing to carry. Unfortunately there is enough research available that shows that most of these rules make no sense and doesn’t help to improve security at all…

So reading the following post( about NIST(the United States National Institute for Standards and Technology) and the new guidelines for password policies they published made me happy.

An extract of some of the rules:

  • A minimum of 8 characters.
  • Allow at least a maximum of 64 characters(I hate it when I cannot use passphrases)
  • No composition rules (again, I hate it when I cannot use passphrases)
  • No password hints
  • No knowledge-based authentication(questions that only you should know the answer, like your favorite color Confused smile)
  • No more password expiration without reason

Thank you NIST!

Tuesday, November 29, 2016

NUnit tests are really slow when using Microsoft.Owin.Testing TestServer

After introducing Microsoft.Owin.Testing TestServer in a Test project we noticed that our test execution time increased from a few milliseconds for all tests to multiple seconds for each individual test.

With the help of dotTrace I noticed that most time was spent inside Microsoft.Owin.Hosting.Tracing.DualWriter. This class is used by OWIN to write all OWIN related data to the console.


After removing the related tracelistener using the line of code below, I noticed that the test execution time returned back to normal: