DEV Community: Patchy from FireHydrant

Rails without Webpacker

Patchy from FireHydrant — Fri, 23 Jul 2021 05:13:17 +0000

We recently removed webpacker from our Rails 5 application. While it was a great way to bootstrap a new Rails app with a significant amount of Javascript we encountered some serious performance problems that we felt really impacted our productivity. We build our application images after every git push and we’d like to be able to deploy them quickly.

We started out using webpacker to build our Javascript bundles and eventually switched to using webpack directly after seeing our asset build times exceed eight minutes. The end result was a 75% reduction in time spent building assets. This is a summary of our findings and the steps you can take to use vanilla webpack in your Rails application.

Read the full post here.

This post was originally published on the FireHydrant Blog on May 28, 2019 by Robert Ross.

3 Defensive Programming Techniques for Rails

Patchy from FireHydrant — Fri, 23 Jul 2021 05:10:03 +0000

Incidents happen all the time because of bad code deploys. You write some code that passes code review, it then is automatically shipped to production after a test suite passes, and BAM, an outage happens. This fairly common occurrence has ways to prevent it entirely. Using some simple ideas we can defend ourselves from the hidden mistakes that code reviews and chaos engineering sometimes won’t catch.

Defensive programming is great for codifying how a bug could be introduced, and raising an error right before it would happen, or choosing an alternative path.

If you have a style guide that specifies things like

“Always use concurrent indexes”
“Always have a timeout on a remote read”
“Never constrain to the account model in a foreign key”

Then this guide is for you.

Read the full post here.

This post was originally published on the FireHydrant Blog on July 20, 2019 by Robert Ross.

Pragmatic Incident Response: 3 Lessons Learned from Failures

Patchy from FireHydrant — Fri, 16 Jul 2021 21:54:04 +0000

In my past experience as an SRE I’ve learned some valuable lessons about how to respond and learn from incidents.

Declare and run retros for the small incidents. It's less stressful, and action items become much more actionable.
Decrease the time it takes to analyze an incident. You'll remember more, and will learn more from the incident.
Alert on pain felt by people — not computers. The only reason we declare incidents at all is because of the people on the other side of them.

Let’s dive into each of these lessons a little deeper, and how they can help you build a better system for pragmatic incident response.

Read the full post here.

This post was originally published on the FireHydrant Blog on July 15, 2021 by Robert Ross.

Working Together (but Separately) with MirageJS

Patchy from FireHydrant — Fri, 16 Jul 2021 21:46:43 +0000

Front-end development and APIs — you’ll rarely see one without the other, but they don’t always get up and running at once. Maybe you’re developing a completely new feature that relies on a nonexistent endpoint, or perhaps the endpoint is just out of date, missing key chunks of data. Front-end and back-end are being built simultaneously, but one isn’t available to the other just yet.

Read the full post here

This post was originally published on the FireHydrant Blog on June 17, 2021 by Hilary Beck.

Four things to consider when evaluating incident management platforms

Patchy from FireHydrant — Thu, 10 Jun 2021 17:35:42 +0000

When you’re feeling the stress and pain around incidents, making the decision to find an incident management tool is a no-brainer. But how do you choose the one that will work for you, your team, and your business?

You might be asking yourself:

Where do I start?
What do I need to know?
What questions do I ask?
What are the options?
How can I be sure we’re choosing the right tool?

Read the full post here.

This post was originally published on the FireHydrant Blog on May 26, 2021 by Robert Ross.

The MTTR that matters

Patchy from FireHydrant — Thu, 10 Jun 2021 17:29:02 +0000

“Mean time to X” is a common term used to describe how long, on average, a particular milestone takes to achieve in incident response. There’s mean time to detect, acknowledge, mitigate, etc. And then there’s the elusive “mean time to recover,” also known as “MTTR.”

MTTR, a hotly debated acronym and concept, measures how long it takes to resolve an incident on average. The problem with MTTR, though, is that it doesn’t matter.

Read the full post here

This post was originally published on the FireHydrant Blog on June 10, 2021 by Robert Ross.

Flexible Ruby on Rails Reader Objects

Patchy from FireHydrant — Tue, 18 May 2021 16:39:41 +0000

Rails and ActiveRecord are great at providing a simple interface for retrieving information from a database. With a few simple characters, I can retrieve all of my users with User.all. While this simplicity is great, it breaks down when you want to start doing more advanced queries such as paginated results, filtered records, etc. Typically you start to see Rails models get a swath of scope definitions to implement this, but over time this just becomes incredibly difficult to maintain. This also gets hairy when you want to use the same reader object for different types of requests (API vs UI for example).

Read the full post here

This post was originally published on the FireHydrant Blog on May 1, 2019 by Robert Ross.

Using React Select with Redux Form

Patchy from FireHydrant — Tue, 18 May 2021 16:30:17 +0000

At FireHydrant we use Redux Form for all of our forms. It's extremely easy to build complex form logic with all sorts of added bonuses that make using it in our React/Redux front end a no brainer.

However, when we started using React Select for our select fields we started running into some issues. You're likely running into some of the same issues we did and so this blog post will help get you off the ground and integrating these two libraries together.

Read how here

Originally published on the FireHydrant Blog on April 23, 2019 by Dylan Nielsen.