Developing against third-party or unfamiliar web APIs can be painful and slow compared to using native libraries. For example, making requests with an HTTP client is simple enough but offers no compile-time sanity checks and no way for code suggestion tools like Intellisense to help you navigate. Worst of all, if the API you are consuming introduces breaking changes, you won’t find out until runtime.
In this two-part series, you’ll get a comprehensive overview of everything you need to know to test your LiveView applications in Elixir. In Part I, I’ll introduce you to LiveView testing guidelines and you’ll write some flexible and elegant LiveView unit tests. In Part II, you’ll write interactive LiveView tests that validate a full set of live view behaviors.
Tests are an integral part of most well-working Rails applications where maintenance isn’t a nightmare and new features are consistently added, or existing ones are improved. Unfortunately, for many applications, a production environment is where they are put under heavy workload or significant traffic for the first time. This is understandable as such tests are costly.
Measuring and offsetting your carbon footprint may seem like a daunting task. In this post, we’ll explain how to easily and quickly perform the calculations in a DIY style. Let’s go!
Linting is the process of statically analyzing code in search of potential problems. What constitutes a problem, in this case, can vary across programming languages, or even across projects within the same language. I would put these problems under a few different categories: Let’s take a look at a few examples of each.
It’s easy to get lost with dozens of plugins and frameworks when starting a new project that requires basic authentication and authorization capabilities. It doesn’t have to be that way. In this article, we’re going to explore two valuable Node.js packages — Passport and CASL — that can help you boost the security of your application by providing both authentication and authorization functionality.
In today’s post, we’ll dive into how we, at AppSignal, solved a daunting engineering challenge. Giving you a look into the kitchen, this post will show you how we tested a new database in production without having to worry about errors/downtime. Alright, let’s get cooking!
Setting up a proper monitoring overview over your application’s performance is a complex task. Normally, you’d first need to figure out what you need to monitor, then instrument your code, and finally make sense of all the data that has been emitted. However, with a few things set in place, and an APM that natively supports Ruby, it’s easier than ever to take this step. In this post, we’ll show you how you can do it too.
Regardless of the tech stack used, many developers have already used Redis or, at least, heard of it. Redis is specifically known for providing distributed caching mechanisms for cluster-based applications. While this is true, it’s not its only purpose. Redis is a powerful and versatile in-memory database. Powerful because it is incredibly super fast. Versatile because it can handle caching, database-like features, session management, real-time analytics, event streaming, etc.
ActiveRecord is Ruby on Rails’ most magical feature. We don’t usually need to worry about its inner workings, but when we do, here’s how AppSignal can help us know what’s going on under the hood.
