Showing posts from 2012

Going Linux, setting things up

And so it was. Burning Ubuntu 12.04 on a blank CD was the last action I performed using the Windows operating system, all Linux from now on.

Stardate who-cares, approaching a black hole

I'm not quite sure how it all began, and whether natural selection had anything to do with it, but as far back as I can remember I've always developed for the Windows platform.

Getting your MSTEST unit test stdout to show in Jenkins

There is no easy way to say it, the default Jenkins plugin for publishing MSTEST results does not show a unit test's standard output when it fails.

Unit Tests - Help them, Help you

Unit tests are sometimes thought of that cousin nobody likes and everybody can't wait for him to leave, although he gets invited regularly because, well, what are you going to do? - He's family.
Whether we write unit tests because we believe in them, or because somebody insists that we do (be it your team leader, some agile guideline, the Pope, etc.), there are ways to make the end result more effective, and dare I say - fun.

MSTEST unit tests & deployment problems

Every now and again you might require for some additional resources to be present in order for your unit test to properly execute. This seems as a reasonable requirement, and MSTEST has indeed addressed it with what goes by the name "Deployment".

To configure deployment for your unit tests double click the "Local.testsettings" in your "Solution Items" folder, you should be able to see a "Deployment" option on the left side, allowing you to add files and folders to be copied alongside your unit tests. So far so good.

4 excuses to write poor quality code

1. This module can't be unit tested, it's too [insert-adjective-here].If it's too [insert-adjective-here], how do you even know it's working in the first place? And what about after we extend it with a new feature?2. Breaking logic into methods incurs a performance hit.So does inheritance, and separation into classes. Does this mean your design should consist of a single class with a single method where all business logic is placed?3. Commenting code is time consuming and hinders development.Same goes for going to the bathroom, but you don't see people skip that, do you?4. Coding conventions are too rigid, I'll call my fields whatever I want.Now that's just an excuse to write ugly code.

Enhancing code readability

I'm a big fan of easily readable code, in fact, my appreciation for code that reads almost English has only grown over the years. Extension methods in C# allow for some nice tricks to take place in this regard.

ClearCase, or is it?

I'm not sure the case is that clear with this one.

Disclaimer: I'm by no means a ClearCase Guru. I'm just someone who strongly believes source control management (SCM) systems should be perfectly usable by people who are not their admins. ClearCase begs to differ. After using it for almost a year, I'd like to beg, though not to differ, but for someone to put me out of my misery.

Performance counters in C# made easier

If you ever got to tango with performance counters in C# (+1, they can be very useful) you might have noticed that the current API leaves much to be desired. Things can get even more cluttered when you have a bunch of them. You have to store the name, help string, and type for each one so you can feed it to the API later on. You'll also need to store an instance for each counter so you can have its value updated. The other day a colleague of mine mentioned that the task of adding a new counter becomes a chore.

The good news is, you can make your life easier.

They let anyone commit to production these days

Today, more than ever so it seems, people outside the software engineering field partake in writing code that eventually makes it to production environments. An increasingly great number of companies have data analysts or researcher personnel write code as part of their job.

I find this phenomenon rather interesting as I do not believe this was the case as far as only a decade ago. Back in the day, doctors practiced medicine, chefs practiced cooking and researchers practiced, well, research. It was the software engineers who were concerned with how to get computers do what was needed to be done using code.
Today on the other hand, while it’s still quite difficult to find a brain surgeon who writes code, it is quite easy to find a computer vision researcher coding for a software company, or a statistician slamming hadoop jobs (the reason for this shift is interesting in its own right, but as design documents often state – this is out of scope).