Go for C# developers: Closures, loops and pointers

As a seasoned C# developer you should be familiar with the common pitfalls of closures where a variable in a lambda function is not always what you think it is. Go's pointers can easily introduce a similar problem even without the use of lambdas.


Go for C# developers: Go for Java developers

Ok, so I was lucky. Somebody else already covered the basics and I share the first impressions covered in this article. Since Java and C# (at least compared to Go) are pretty much the same, this is a good first read if you are in the C# world and want to explore the Go world. However there are two things I would like to point out.



Well it is that time. This week I started at Google so who knows which direction this blog takes now. At least I should be able to contribute yet another story on how to get a job at Google.


Military LINQ, Time and pointers for kids.

Wow, I was apparently very busy blogging in October 2008. While there are some things that I will not cover below that might be worth reading I wanted to highlight a few things. Both good and embarrassing stuff...


Go for C# developers: Unit testing

Let’s talk about unit testing and Go. The fact that unit tests typically are placed side by side with the code (in the same package as the code under test) and how Go deals with exposing functions outside of a package leads to some interesting things.


Amazon AWS DevDay San Francisco: Serverless Track

Earlier this week I spent a day following the serverless track at the AWS dev day in San Francisco. I guess serverless is the "new thing" in "the cloud". By building a serverless service you build a service using an infra structure where you don't care about servers, virtual machines or containers but rather functional units.


Peek inside Netflix A/B testing

Just a quick suggestion for today. Read this article on A/B testing at Netflix as it both shows you the importance of supporting A/B testing in your platform as well as an interesting insight into how we humans work when looking for something to watch & chill.


Go for C# developers: Interfaces that are never nil

This was a funny feature I came across when i was learning Go. I was working with an API that used interfaces and was surprised that some of my code did not behave the way I expected.



I've always been and advocate for intentionally ignoring the DRY (Don't Repeat Yourself) rule when writing tests if it makes the tests easier to understand. I've even (repeatably) said that some duplication might actually be a good thing when writing tests.