Read More
programming language codes

Software rule #1

The odds that a bug is the result of a typo increase exponentially with the duration of your search

Extension to Category Posts in Custom Menu

The WordPress plugin I wrote, Category Posts in Custom Menu, supports custom extensions. Recently, I wrote an extension for someone who wanted to show all posts from some category, say […]

What do a warning, a comment, a test and your backlog have in common?

#warning This is going to be a nitpicky post.

There was once a developer who marked his code with TODO’s.


// TODO does not handle case X
public void Handle()
{

...
// TODO clean this up
var ugly = ...

...
// TODO re-enable after Y is implemented
// if (bla)
// {
// ...
// }

Another developer used warnings.


#warning still have to write test for this
switch (something)
{
case a: i = 4; break;
case c: i = 1;
default: throw new InvalidOperationException();

I’m writing this blog post to illustrate subtle but significant differences between four mechanisms that can be used for a shared goal: To mark what still needs to be done.

Unit testing 001

“Man, I just love unit tests, I’ve just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn’t broken anything by running the test over it again…” — http://stackoverflow.com/a/67500

The benefits of unit testing are well known, as are the many reasons that are offered when asked “Why don’t you do it?”. The arguments I hear over and over are:

  • “It takes too much time.”
  • “Our code isn’t suitable for unit testing.”

I’ve discussed unit testing with many people in the past years and at some point, I discovered one of the main reasons behind the arguments that were actually offered. We human beings find it much easier to say “It’s not possible”, “It’s too expensive”, “I don’t want to” or “I won’t start doing this until I’ve seen it work” (this one I encounter surprisingly often and makes me smile nowadays) than to admit:

  • “I don’t know how”

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 […]

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:

arduino

beardboard


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.