Epoch (sic) Parties!

When going over the posts from February 2009 I found some moderately interesting stuff and then one real gem. And it was not the fact that we passed epoch time 1234567890.

Go for C# developers: Polymorphism

One of the things I miss the most in Go is polymorphism. I must confess that the lack of polymorphism is one of those things that still annoys me sometimes.

Go for C# developers: Go is not a functional language

Last week covered a lot of ground but that articled linked last week did not cover another aspect of Go that might bite you.

Go for C# developers: 50 things you should know

Once again I can just lean back and relax as somebody else already did my work.

Slow tests, courage and zombie driven development

When I was going over my old posts from January 2009 I had a flashback of how I for a while aimed at posting something every other day. Today I must say quality may have suffered from that and I apologize... So here are the highlights...

What is the most vulnerable operating system?

For whatever reason I needed some data on what the most vulnerable operating system was and instead I stumbled over some questionable use of statistics. At least in my opinion.

Go for C# developers: All your async are belong to us

Learning how to write "good" go code (in some definition of good) sometimes mean you need to unlearn old habits. This is especially true when it comes to asynchronous code if you have a C# background.

Go for C# developers: Where to define interfaces

When writing Go code the general guideline is not to create interfaces unless it is really needed. A good example would be an interface with only one concrete implementation. Now for the mind boggling part; in C# we would probably create that interface if the type needs to be faked in some test while in Go you wouldn't. Or actually you would. But in a different place...

Another example on ways to to make your code testable

Before you go crazy on me screaming that making code testable for the sake of testability is bad I'd like to agree. However testable code have other nice properties like loose coupling for example - something you likely want. Anyway, in this article there is a great comparison between using inheritance vs composition to implement a class and how that affects both the design of the class and the tests. TL/DR; use composition and dependency injection. Please.

The 2008 advent calendar - 24 ways to write a test

Oh yes I love December 2008. I decided to challenge myself and write the same test in 24 different ways. And it was an interesting experience!