The Grid Master

On holiday this year, same as last year, I downloaded a few puzzle games for my phone. One of them was Einstein Grid Master by Kerelize. (You can find it […]

The xkcd surey

Have you ever thrown out all your different pairs of socks/underwear, bought a bunch of replacements that were all one kind, and then told all your friends how great it […]

Read More

On rediscovering painting

When I was a child, I was once asked to create a painting for a church. I don’t remember exactly what the event was, but I ended up creating a painting of a huge colorful mosque. After secondary school, I followed an art class and during my studies in Computer Science and Engineering, I also once took up a painting class. Although painting hasn’t been a constant hobby of mine, I do return to it from time to time. In the past year, I did quite a few paintings from photographs, as gifts for friends or friends of friends.

LEDWall prototype 1

A year or so ago, my partner and I said to eachother “Wouldn’t it be cool to create a LED wall for our living room?”. We then set about to buy an Arduino and some required components for the first prototype. It took a while for us to actually get started, but my phone tells me that on the 7th of June I sent my technogeeky friends a photo over WhatsApp of my breadboard experiment:



Build dependencies and hardcoded paths to shared network drives

Frankly, I’m surprised that I can’t find more blog posts on this topic.

I can’t imagine that I’m the only software engineer who has encountered dependency management of the form “it’s somewhere on the K: drive”. And yet, when I search online, I can’t find anyone griping about this. All I can find is this one blog post by Sonatype that goes on to advertise their Nexus repository manager.

In this case, we use environment variables for all our builds.. or so I thought. Last week, I encountered one project that was making an exception and doing its own thing: It was explicitly calling a tool on the K: drive and linking against libraries on that drive. Not only that, it didn’t use environment variables but hardcoded the path to the network drive in the build script and VS project settings.

Afhankelijkheden en hardcoded paden naar netwerkschijven

Het verbaast me zeer dat ik niet meer artikelen kan vinden over dit onderwerp.

Ik kan me haast niet indenken dat ik de enige software engineer ben die dependency management van de vorm “Het staat ergens op de K: schijf” tegenkomt. En toch, een online zoektocht brengt me enkel naar een artikel van Sonatype wat vervolgens hun Nexus repository manager aanprijst.

In ons geval gebruiken we environment variabelen voor al onze builds… dacht ik althans. Vorige week kwam ik een project tegen wat hier vanaf week: Er werd expliciet een tool op de K: schijf aangeroepen en er werd gelinked tegen libraries op die schijf. Dat niet alleen, er werden geen environment variabelen gebruikt, maar een hardcoded pad naar de netwerkschijf was opgenomen in het build script en de VS project instellingen.

Expressing ownership in a solution

I prefer expressing the difference between project a solution owns and projects it does not own (dependencies) with the help of Visual Studio’s solution folders. It’s a trick I didn’t […]

Ownership tot uitdrukking brengen in de solution

Het onderscheid tussen projecten waar een solution owner van is en projecten die generiek of herbruikbaar zijn breng ik graag tot uitdrukking met behulp van solution folders. Dit is een […]

Drie mailadressen, waarvan we er twee negeren

Als je op een account aanmaakt, kun je drie mailadressen opgeven: een e-mailadres onder “Mijn” een e-mailadres onder “Bezorgvoorkeuren” getiteld “DHL aankomstbericht” en een onder “E-mailadres voor e-mailvoordeel” […]