Your source of geek knowledge

Stuff I learned yesterday

I listen to a few podcasts. Mainly technical ones. I recently got a hint from Mike Minutillo about a podcast called “Stuff I learned yesterday”. I was blown away when I started listening to this podcast. It makes you think more about stuff that you learned. Furthermore, this podcast is full of stories from the podcasters themselves but also from the community. You’ll find the podcast here

One of the recent inspiring and very emotional episodes are

Finding clarity

If you have lost someone in your life like I did, you know why I like this one.

Are they even listening?

If you are a parent, like I am, you know why I like this one.

Subscribe! It is emotional, inspiring, makes you laugh, cry, think…

Post picture by

Mining for gold in your logfiles

Once you’ve already learned the ins and outs of a library, it may seem obvious how it should be used (and which parts should be avoided). The thing is that, from one project to the next, we often make use of new and different libraries and frameworks and may not appreciate some of the more subtle differences among those technologies.

The better frameworks out there will log all kinds of information, often telling you when you’re using them incorrectly. So don’t just think of log files as something only relevant for production. There are nuggets in there that can really help you in development as well.

Look at your log files at regular intervals. Doing that from time to time and, even better, automating it, can save you from headaches even before you release your products into production. Eventually, this practice will not only prevent bugs but it can also dramatically improve performance in certain cases.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications – The alternative nunit

In my last post, I explored xunit as an alternative to MSpec. In this blog post, I’m going to do the same with NUnit. Most people underestimate the power of NUnit. It is a great testing framework that has been around since the early days of .NET and Open Source and is still actively maintained. When it comes to tool integration, NUnit has one major advantage: The Resharper plugin is developed by JetBrains and shipped together with every Resharper release. So everybody which uses NUnit never has to worry about if there will be a Resharper integration. Furthermore, they’ll never worry about the plugin no longer being maintained (like in other One-Man-Show-Plugins). In fact there is even a 3.0 Beta release currently available of NUnit, all development is done on Github. Be sure to check out the release notes! Yes, yes nitpickers, it uses attributes and such but who cares?

So to reimplement the basic functionality of Machine.Specifications you need Continue reading

Machine.Specifications – The alternative xunit

In my last post, I showed how a Heisenbug can look like to you. In this post, I want to explore the different options I was considering to get rid of some of the pesky things around Machine.Specifications. During the work, I did for Machine.Specifications I asked myself more and more if it is really worth maintaining a whole ecosystem of tools when there are excellent frameworks available in the Open Source world. Why did I even look at alternatives? Why didn’t I just say, that’s it and move away from Machine.Specifications? Continue reading

OMG! They Killed My Stacktrace!

I can’t get that flashing red light on my desktop out of my mind. It’s nagging me. What is it? Oh my… I just killed the build! How embarrassing — only a few weeks on the team and I’m already a trouble-maker. Resistance is futile. The flashing red light got me. Five acceptance tests are failing on the build server. Hold on — those tests are working on my machine! Can’t I just add a works on my machine badge and carry on with the other things I have in the work pipeline? The “getting things done guy” inside me says yes, but my engineer heart tells me no. I roll up my sleeves and start analyzing what went wrong.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications – The Heisenbug

In my last post, I talked about me moving away from maintaining Machine.Specifications. Today I want to give you more insights into the decision process and what else I tried to save the project. When I was working for bbv Software Services AG, I was heavily using MSpec in multiple projects. I and also others in the company liked the lightweight syntax and the code-centric approach to specifications by example. We used it so much that it became together with SpecFlow one of our strategic open source library for specifications. We used SpecFlow in projects where the product owner or business analysts took the time to learn and write Gherkin. We used MSpec when the development team was writing the specifications (of course as closely as possible with the business). Continue reading