Dashboards should be easy to build and provide powerful insights. Our magic dashboards are already created automatically, so you don’t have to spend any time setting up these dashboards yourself. Many developers started tracking custom metrics that were unique to their applications. From these metrics, you can create custom dashboards and add triggers to get notified if values go outside of your desired range.
In today’s post, we’ll take a deep dive into Rails migrations. We’ll break down the migration into different pieces, and in the process, learn how to write an effective migration. We’ll learn how to write migrations for multiple databases, as well as how to handle failed migrations and techniques of performing rollbacks. To understand the whole post, you’ll need to have a basic understanding of databases and Rails.
Every JavaScript project starts ambitiously, trying not to use too many NPM packages along the way. Even with a lot of effort on our side, packages eventually start piling up. package.json gets more lines over time, and package-lock.json makes pull requests look scary with the number of additions or deletions when dependencies are added. “This is fine” — the team lead says, as other team members nod in agreement. What else are you supposed to do?
DHH just coined the term “Citadel,” which finally gives us an excellent way to reference how we approach tech at AppSignal. We said, “Hey, this is us! Our thing has a name now”. In addition to the Majestic Monolith, someone should write up the pattern of The Citadel: A single Majestic Monolith captures the majority mass of the app, with a few auxiliary outpost apps for highly specialized and divergent needs.
Many of us are impacted in one way or another by the Covid-19 virus. At AppSignal, we asked our team to prioritize their families and (mental) health first. We hope you were able to do the same. We are starting to find a new rhythm in these uncertain times, and are continuing on our mission to bring developers amazing monitoring. In that light, we are happy to ship the first version of AppSignal for Node.js.
Ruby has always been known for the productivity it brings to its developers. Alongside features such as elegant syntax, rich meta-programming support, etc. that make you productive when writing code, it also has another secret weapon called TracePoint that can help you “debug” faster. In this post, I’ll use a simple example to show you 2 interesting facts I found out about debugging.
If you have some experience setting up monitoring for different setups, this post is for you. Since different parts of your architecture have different tasks, they also have different expectations. Today, we’ll take a quick dive into how to deal with that reality and set up monitoring for it. Warning: In this post, you’ll have to bear with our enthusiasm for setting things up perfectly.
In today’s post, we’ll learn what gRPC is, when you should reach for such a tool, and some of the pros and cons of using it. After going over an introduction of gRPC, we’ll dive right into a sample application where we’ll build an Elixir backend API powered by gRPC. Let’s jump right in!
In today’s post, we will be looking into a software design pattern called Facade. When I first adopted it, it felt a little bit awkward, but the more I used it in my Rails apps, the more I started to appreciate its usefulness. More importantly, it allowed me to test my code more thoroughly, to clean out my controllers, to reduce the logic within my views and to make me think more clearly about an application’s code’s overall structure.
Elixir 1.10 was recently released, and with that release came a little-known, but very interesting feature—compiler tracing. This feature means that as the Elixir compiler is compiling your code, it can emit messages whenever certain kinds of things are compiled. This ability to know what’s going on when Elixir is compiling our code might seem simple, but it actually opens up a lot of doors for opportunities to build customized compile-time tooling for Elixir applications.
