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 →

It’s impossible to escape Javascript in a Rails application. From a tiny script to a full-on Javascript framework, websites are becoming more and more reliant on Javascript, whether we like it or not.

Several articles back, I documented how I handle page-specific Javascript in a Rails application. My solution included a third-party jQuery plugin that did some magic on the $(document).ready function in combination with CSS style scoping to limit the functionality.

continue reading →

In light of RailsConf last month, I spent some time thinking about my experience learning Ruby and Rails back in 2009. The conference included quite a few seasoned veterans, but like any popular technology, there was also plenty of people that either just started learning Rails, or are considering doing so in the near future.

Turning the clocks back to when you knew much less about something is hard. But putting yourself back in that position can offer valuable insight to the opportunities available and how they might be improved in the future.

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: