You’re done setting up your first graph panels. You want to do more, look around the visualization settings, and discover the settings for the X and Y axes. You stumble over the configuration for a "Right Y" axis. You ask yourself, "Why on earth would I need another Y axis?"

Great dashboards answer a limited set of related questions. If you try to answer too many questions in a single dashboard, it can become overly complex. As a consequence, a single dashboard often can’t tell the whole story. So you end up navigating between several, and it can be quite inefficient to search for a particular dashboard every time you need it. Luckily, there are some hacks for navigating between dashboards.

This is a follow-up on my previous post where I showed how you can write user-friendly client packages for REST APIs that will make it even more enjoyable for users to integrate with your services. And for many services, the patterns I showed will probably suffice. This time though, we’ll take a look at two additional patterns. First, I’ll show you how you can bring your client package up-to-date by adding support for the context package. Then we’ll look at how we can pass optional parameters for things like pagination and filtering. Let’s jump right in.

If you are providing a RESTful API for your product, you are already doing developers around the world a huge favor by enabling them to do amazing things, things that you may not even had imagined were possible. By providing your users with a client SDK in their favorite language you are making it even easier to integrate their services with yours. In this blog post I will show you how to write your own client package in Go!

I’m writing this on the way home from GolangUK where I did a talk on Building an Enterprise Service in Go, based on the DDD Sample App. I was really overwhelmed with the positive feedback I got, some of which came from developers who never heard of DDD prior to my talk. Not totally unexpected however, since it’s an approach to a problem space which I believe Go has yet to conquer, but among the feedback I got were a few valid concerns that I thought I would address in the form of a blog post.

Go has been widely successful for creating tools and infrastructure, but the simplicity of the language also makes for an excellent fit for implementing core business applications. We will look at a few patterns for domain objects and code organization and hopefully we'll take some additional steps towards Go in the modern enterprise. During this talk we will look at a sample application that demonstrates how a core domain could be implemented in Go. Hopefully, it will serve as leverage and inspiration for developers that want to write their next enterprise service in Go rather than using the traditional Java stack.

Up until now, we have only looked at one service in isolation, but this is seldom the case in a service-oriented architecture. For the last post in this blog series on Domain Driven Design in Go we will have a look at how we interact with other services. In particular, we will have a look at two concepts that help us reason about these interactions: application services and bounded contexts.

In my previous post I announced a project I have been tinkering with lately; porting an existing DDD sample application to Go. I elaborated a bit about its background and the general structure of the application. In this post we are going to have a look at some of the implementation aspects that I have encountered so far.

In 2008, Citerus developed a Java sample application in close collaboration with Eric Evans, based on the examples in his book. The purpose was to showcase the concepts from DDD in a real-world application. Since then, the application has been ported to other languages such as C# and Ruby. Of course, as a DDD practitioner and a Go developer I thought it might be a fun exercise to try porting it to Go.

I did a talk on Event Storming a short while ago where I started off by explaining why state transitions are so much more interesting than the actual states themselves. We had a lot of good discussions afterwards and I felt I wanted to elaborate a little bit further on the theme, in the context of distributed systems.

So we have been looking at adding circuit breaking to our services at my current client as part of making them more resilient. We used the fantastic hystrix-go package and since I could not really find any other examples other than the ones in the tests, I thought I might share one.

Upplever du att det finns ett glapp mellan de som förstår verksamheten och de som utvecklar mjukvaran? Genom en enkel övning kan ni utforska er affär, underlätta dialogen mellan de inblandade och samtidigt förbättra kvaliteten på er mjukvara.

When I set out to port the DDD sample application to Go, I had done a couple of minor projects in Go on my spare time. The experience I had got from those projects had been refreshing, to say the least. I felt like I was being more productive than I had ever been in other object-oriented programming languages. But then I got curious.