Today, we’re introducing a small but useful change to the Anomaly detection that configures which hosts the host triggers should listen to. Do you have a stroopwafel in your hand? Yes? Then let’s dig in.
Today, we’re bringing you an update of the performance/exceptions sample page. This update includes a number of improvements that will help you navigate and filter the available samples faster and more smoothly. We’re bringing these changes as an iteration of sample navigation improvements that we launched a while ago. We received valuable feedback from our users: the overlay made the navigation choppy instead of fluent.
When requirements change for your product, there arises a need to change not only the codebase but also the existing data that already lives in production. If you’re performing the changes locally, the whole process seems fairly simple. You test your new feature against a sparkling clean database, the test suite is green, and the feature looks great. Then you deploy, and everything goes to hell because you forgot that production was in a slightly different state.
This blog post will explain how to effectively profile your website so that you can deal with performance pain points. We’ll go through the two most used tools in Google Chrome for profiling: Imagine that you optimized your backend and everything is running smoothly. However, for some reason, the load time of your pages is still unreasonably high. Your users might be experiencing sluggish UI and long load times. This post will help you sort these issues out.
Today, we’ll dive deep into monitoring hosts. The good news is that we’ll point you to some shortcuts on how to set up host monitoring in an easy way. The bad news is that we won’t be doing any percussive maintenance on any host. To monitor hosts, you have to set a few layers in place. Doing all this by yourself would be the hard way. You may ask: “How hard could it be?”.
In today’s post, we’ll look at system tests in Rails 6. System tests are meant to auto-test the way users interact with your application, including the Javascript in your user interface. Minitest, being the default testing framework in Rails, is a great match for system testing. With all the configuration that Rails handles for us, there are just a few steps needed before we have our first tests up and running.
In case you missed it, we released Ruby gem 2.10. It focusses mostly on diagnose and configuration. Though a bit late, here’s a round-up of what’s in the release.
Today, we will dive into one of the hard parts of using any monitoring - making sense out of all the data that is emitted. We think this is one of the hard parts. And being developers building for developers, we think a lot like you do – we think. Pun intended. Nowadays, we monitor AppSignal with AppSignal (on a separate setup), so we are still dogfooding all the time. We still run into challenges as you do, often before you.
In today’s post, we’ll go over what continuous integration and continuous delivery are, the benefits that come along with employing CI/CD, and some best practices that you should follow. We’ll also explore a wide array of Elixir ecosystem tools that can help you create top-notch CI pipelines. In order to experiment with a handful of the tools that we will be discussing, we’ll use a Git hooks Elixir library to execute our CI/CD validation steps, but on our local machine.
In this post, we’ll look into tried and true methods of improving Rails view performance. Specifically, I will focus on database efficiency, view manipulation, and caching. I think the phrase “premature optimization is the root of all evil” has been taken a little out of context. I’ve often heard developers use this during code reviews when simple optimization techniques are pointed out.
