It’s no mystery I’m a Sidekiq fan — my background job processing library of choice for any non-trivial applications. My favorite feature of Sidekiq has to be retries. By default, failed jobs will retry 25 times over the course of 21 days.

As a remote company, we use Slack to stay in touch with everyone AND to manage/monitor our infrastructure (hello #chatops). We can deploy from Slack (we don’t generally, we have full CI) and be notified of infrastructure and application errors.

continue reading →

I’ve spent the majority of my career working for companies building products I either wasn’t interested in, or wasn’t the target user. They were jobs. In exchange for my 40 hours, they supplied me a paycheck. As a result, I went home at the end of the day and was able to disconnect.

Fast forward almost 15 years and I’m on the opposite end of the spectrum — I build a product I want to exist, a parent like me is the target user and furthermore, I have equity in the company.

continue reading →

In a previous article, I documented the upcoming public API changes slated for Sucker Punch v2. Because of a poor initial design, these API changes are backwards incompatible.

When I published the previous article, Mike Perham rightly pointed out the opportunity to support the previous versions’s API through an opt-in module. I was hesitant to include support for the old syntax by default, but allowing a developer to require a file to get the old syntax made complete sense to me. My intent was never to abandon existing Sucker Punch users, but it felt necessary for the success of the project going forward.

continue reading →

Sucker Punch was created because I had a need for background processing without a separate worker. But I also figured others did too, given that adding a worker dyno on Heroku was $35. For hobby apps, this was a significant cost.

Having gotten familiar with Celluloid from my work on Sidekiq, I knew Celluloid had all the pieces to puzzle to make this easier. In fact, one of the earliest incarnations of Sucker Punch wasn’t a gem at all, just some Ruby classes implementing the pieces of Celluloid necessary to put together a background processing queue.

continue reading →

In the recent series on transitioning to microservices, I detailed a path to move a large legacy Rails monolith to a cluster of a dozen microservices. But not everyone starts out with a legacy monolith. In fact, given Rails popularity amongst startups, it’s likely most Rails applications don’t live to see 4+ years in production. So what if we don’t have a huge monolith on our hands? Are microservices still out of the question?

Sadly, the answer is, “it depends”. The “depends” part is specific to your context. While microservices may seem like the right move for you and your application, it’s also possible it could cause a mess if not done carefully.

continue reading →

This article was originally posted on the PipelineDeals Engineering Blog

In the previous article in this series, we introduced a billing service to determine which features an account could access. If you remember, the email service was a “fire and forget” operation and was capable of handling throughput delays given its low value to the core application.

This post will explore how we handle synchronous communication for a service like billing where an inline response is required to service a request from the core application.

continue reading →

This article was originally posted on the PipelineDeals Engineering Blog

In the previous article in this series, we moved the responsibility of emails to a separate Rails application. In order to leverage this new service, we created a PORO to encapsulate the specifics of communicating with our new service by taking advantage of Sidekiq’s built-in retry mechanism to protect from intermittent network issues.

Communication between microservices can be broken down in to 2 categories: synchronous and asynchronous. Understanding when to use each is critical in maintaining a healthy infrastructure. This post will explore details about these two methods of communication and their associated use cases.

continue reading →

This article was originally posted on the PipelineDeals Engineering Blog

The PipelineDeals web application recently celebrated its ninth birthday. It’s seen its fair share of developers, all of whom had their own idea of “clean code”. As a team, we’d been brainstorming ways to wrangle certain areas of the application. The question we’d frequently ask ourselves was “How do we clean up [x] (some neglected feature of the application)?”.

continue reading →
Build a Ruby Gem Course - FREE!

Join 1,300+ other Rubyists and take your Ruby gem skills to the next level!

Whether you're an expert Rubyist, or just starting out, this FREE 10-day email course will guide you through the process of creating your own Ruby gems from start to finish.

Enter your email below to get started today: