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.
If you are learning Go you know there is no foreach nor while in Go - just for with a few different ways of setting it up. There is a nice gotcha if you are doing what you think is a foreach though.
Since I apparently got carried away blogged a lot in August 2008 I have to pick a few of the more interesting posts from that month and see if there is any update to be made. I guess that also means that by definition the things I don't mention today are not that interesting any more...
When I first started to learn Go a few months ago I compared a lot of things to things that was familiar to me; C#. And I decided to make a series of posts explaining some go-isms in C# (or .Net) terms as well as high-light some of the differences that are important to know about.
Well sometimes I'm lucky and somebody else writes something so I don't have to. Since you should assume that your system will be breached eventually you should make sure that your user's passwords cannot be exposed as a lot of users reuse their passwords across multiple sites.
So I start this series of updated old opinions and the MSDN blog change interface so there are no longer links to monthly archives except the last three months of posts. There is some logic to it I guess since it keeps the archive list shorter but I wish they made it configurable... Anyway; this time it is time to talk about some posts from July 2008 which can be found on this page.
Over the last few weeks I've been going over a few different ways to solve inter service communication. So which one is best then?
In order to distinguish pub/sub from message bus communication I will assume the pub/sub does not use another component to distribute the data as that would be a message bus pattern. I will assume that the publisher knows about all subscribers either statically or dynamically.