About janvanderhaegen


Winter is coming…

Hey blogsters!

Does anyone else feel like this year just flew by? It’s December again, holy bleep!

Personally, it’s been a crazy busy year, especially since my last blog post. I’ve moved continents again, currently I’m living and working in Paris, France, on some of the sweetest tech I’ve ever tasted.

There’s a time to talk the talk, and there’s a time to walk the walk. This year’s been a slow blogging year, but only because I’ve been so busy walking the walk. Some time next year, who knows when, I’ll be back with a bunch of block posts. Time will tell if those will be titled along the way of “The best 5 things to make your startup successful”, or “The 5 pitfalls to avoid on your way to success”… Hah!

Anyways, whether you read this post in 2015 or later, I hope you are all doing absolutely amazing!

merry force



Google search tip: excluding old web pages

When searching for anything IT related, google/Bing often return Stackoverflow and CodeProject pages that are old. Really old. Like 2008 old, which often is way too old to still be accurate.

Thankfully, Google has a very simple trick: using the ‘advanced search’ you can limit the search result to pages that have been created/updated in the last ‘hour’, ‘day’, ‘week’, etc. A fixed number of different options are available through the advanced search UI, but Google’s query string has all the power you need… Simply append &as_qdr=y2 to any search URL to limit the search to pages that have been created/updated in the last 2 year.
Possible values for the as_qdr query filter are:
– d(x), where (x) is the number of days, for example &as_qdr=d14
– w(x), where (x) is the number of weeks, for example &as_qdr=w8
– y(x), where (x) is the number of years, for example &as_qdr=y1

Ironically, I found this tip in a blog post from 2007

@Bing: Come on my friend, you’ll never win this way…

Happy 4th anniversary!

Today I am meeting with a customer and he asked me how much LightSwitch experience I have. So I opened my blog’s dashboard, sorted the posts by ascending date, and there it was: my first post ever… Debugging your custom LightSwitch (Shell) Extension, dated July 27th, 2011. What a crazy coincidence, today, to the date, it’s been exactly 4 years since I transmitted my first words into the blog-o-sphere. Happy 4th anniversary guys ‘n guls!

How to make Visual Studio always run as an administrator

There’s a gazillion reasons why you might want to run visual studio as an administrator.
Mine was when installing a Nuget package that tried to run a PowerShell script on install, and complained about the execution policy not being set correctly.
Normally, Nuget automatically sets the PowerShell execution policy for the Visual Studio process itself so that it can run any script. Which might be dangerous, but hey if we were shy of danger we’d be doing something boring like being racepilots and not something adventurous like being developers.What developer would run the same track twice, manually! The dullness…

Anyways, a process cannot set it’s own PowerShell execution policy if it’s not running as an administrator.
Long story short, not running as administrator === not automatically being able to run PowerShell install scripts.

Luckily, I was doing a coding session with a very bright partner of mine, and she told me this trick:
– press Windows+E and go to C:\Program Files(x86)\Microsoft Visual Studio XX.X\Common\IDE
– right click and hit: troubleshoot compatilibity
– let it detect issues for a bit…
– troubleshoot program
– click: “the program requires additional permissions”
– yes, save these settings

From now on, VS will always and forever run as an administrator!


Forget P@ssw0rds, use phrases that motivate you!

It’s a good practice to change your passwords ever so often. If you’re working at a company with IT staff, they’ll probably force you to change your password every month. This is supposed to increase security, but in reality it decreases as people build a system for themselves to help remember what this month’s password was: J@n*05/2015

Since people change their password but not their own formula, changing password adds absolutely no increased security: even first graders can hack the current mutation given an earlier password.

So here’s the idea: stop using a fixed formula, but use phrases that motivate you!

Every month, pick one small goal for yourself. Just a small thing. Something you want to be better at, something you need to build up some courage to do so, something small you want to change. Then, motivate yourself by using that as a password. Since you’ll be typing it multiple times per day, you’ll motivate yourself to actually go do/change/forget/forgive it. It’s like your little personal life coach, whispering a single small goal you can accomplish this month, in your ear, multiple times per day.

Use this system for a year, and I promise you you’ll be happy you did. Here’s a couple to spark your inspiration:

… Yea, had to learn the hard way on that last one…

Feel free to inspire others too, share your favorite motivational password in the comments below!

Changing the ASP.Net web.config connectionstrings at runtime

So here’s an interesting challenge we had to overcome today: every developer in the team has small variations in his/her workstation setup. Instead of micro-managing each installation (we all know how developers love to be micro-managed and even more so how they love to be told how to set up their workstation), we thought we’d give a stab at changing the connections from the web.config at runtime.

Wait, aren’t there a million posts on how to do that already? Well, yes, but most of them use web.config transformations (which aren’t ran when you locally debug), or actually save the web.config (physically changing the file on disk so that the next developer that gets the default web.config is screwed).

What we wanted to do, is actually load the default web.config, but, per developer, change some of the in-memory values.
Turns out, all you need is a little reflection:

        private static void SetConnectionString(string name, string connectionString)
                .GetField("bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic)
                .SetValue(ConfigurationManager.ConnectionStrings, false);
            var connection = System.Configuration.ConfigurationManager.ConnectionStrings[name];
                .GetField("_bReadOnly", BindingFlags.Instance | BindingFlags.NonPublic)
                .SetValue(connection, false);
            connection.ConnectionString = connectionString;

Then, in your global.asax application_start method, before doing anything else:

#if BOB
  SetConnectionString("LocalSqlServer", "wow");
  SetConnectionString("DefaultConnection", "much monkey patch");
  SetConnectionString("AndAnother", "very connectionstring");  

Finally, each developer goes to the configuration manager (the dropdown next to ‘Debug’), creates a new configuration based on ‘debug’, then in the project properties > Build > adds the conditional compilation symbols BOB, CUSTOMCONNECTIONSTRINGS.
Now each developer can run his/her own configuration and manage how they’ve set up their own system, the code that does the monkey patching of the connection strings is not even included in the release output, and the actual web.config file is never modified and will always contain the default values.

Github: the social coding experience

A couple of months ago, I joined an open source project called aurelia as a core team member. Like many open source projects, the project uses github for its source control

I’ve been a Microsoft stack lover all my tech life, thus until recently my only visits to github were when someone (for reasons unknown to me at that time) hosted a sample on github. My only experience with git was clicking on the ‘download as zip’ button in github to grab that sample.
Microsoft really never trained me to think otherwise.
I’m a big believer of ‘sharing is caring’ though, that’s why a lot of my blog posts come with inline code samples, samples on MSDN or an extension on codeplex. Imagine where we, the LightSwitch community, would be now if LightSwitch had its source openly available from the start.

About 5-6 weeks ago, I started working on the aurelia validation plugin. It was an eye-opener, to say the least. After only a week of building out some core components, another aurelia team member created a pull request (pull requests are like a request to merge a provided changeset) to implement translations for the validation messages. Great, I thought at the time, a team working together on a project.
Yet, it was more than that. That same week, someone outside of the team submitted a pull request to turn the repository into a JSPM package so it can be easily installed using the JSPM package manager. Soon after, someone fixed some small typos in the documentation. More ‘language packs’ in Mexican, Swedish, Turkish and other languages arrived that week. Some bugs were reported as issues, with clear code sample instructions on how to reproduce it and sometimes even a code to fix the issue, and another issue was opened simply to discuss an integration strategy with another open source validation plugin.
Someone even wrote additional unit tests.
Unit tests!!!
Someone willingly sacrificed personal time to write… unit tests…

I slowly grew to realize the amazing truth: open source projects are not just projects where the source is publicly visible. Github isn’t just a source control website. The open source community, github in particular, are also, and perhaps most importantly, about the social coding experience. Working together with a variety of people to accomplish common goals, to share the creation of something awesome, to share and intensify the joy of our common passion.

Earlier this year, I was talking to some Microsoft folks and they were so excited about their recent announcement that Microsoft server stack is going completely open source.
I didn’t get the big deal at that point.
I use the technology already, and if there’s something I’d like to do different, there usually is support to configure my will or I reverse engineer the sources to see if I can monkey patch it, and carry on with my task at hand.
Yet now I understand: open source is not about having their source in the open, it’s about having an open invitation to join their coding experience.

Let’s hope that everyone and every team at Microsoft truly get that too. Let’s hope that their next products or versions of existing products, embrace the same love for the social coding experience. Lets hope that Microsoft can teach their somewhat traditional B2B LOB introvert application developer flock to embrace the social coding experience too.

Because, after all, what a beautiful experience it turns out to be.