One of the first pieces of advice that aspiring contributors get when looking to contribute to their first open source project is to search for beginner-friendly issues. But what does it mean for an issue to be truly beginner-friendly?

Since the release of Grafana v7.0, we’ve seen a lot more developers taking advantage of the new plugins platform, which helps them build high-quality custom plugins faster than ever. Not only does this allow them to create their own custom visualizations and data source integrations—taking the Grafana experience to the next-level—but by sharing them with the community, they’re able to help others do the same.

There are a lot of great things about Grafana 7.0, but one of my favorite features is the new React-based plugin platform, which has a set of new APIs and design system to help you build your own plugin. The process is easier and faster than ever. In this blog post, I’ll show how you can create a panel plugin for visualizing scatter plots.

Grafana 7.0 introduced a brand new React-based platform, along with a set of improved APIs for building plugins. Since I knew some React from previous projects, I wrote my first Grafana plugin that would adapt the original Carpet plot to the new plugin platform. I’ve called it Hourly heatmap, and in this blog post, I’d like to quickly introduce what it does and how it can be helpful.

Running your software on dynamic infrastructure means that your monitoring platform needs to change dynamically. Variables let you reuse a single dashboard for all your services. Select the service you want to inspect from a drop-down menu, and watch panels update to only show you metrics from that service. A common use case for variables is to filter data within a panel. In this blog post, we’ll look at how you can dynamically add and remove entire panels through a feature called repeated panels.

As the work-from-home culture continues to reshape many people’s lives, the team at Grafana Labs has been sharing tips, tricks, and hacks we have learned as a remote-first company. One tool that has been vital to our internal communications and team building is Slack. If you’ve been using Slack in an office setting, you might find using Slack in a remote setting can be a new experience. Here are some of the best practices we use on Slack for seamless communication and to actually get work done.

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.