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.

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.

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)?”.

A few fellow authors and friends of mine have put together the Ruby Book Bundle including some of the best Ruby/Rails books out there. The bundle went on sale this morning! It’ll only be available for a week, so be sure to pick it up soon if you’re interested.

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.

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.

In my last article, I presented some code that wrapped up accessing a customer’s Stripe data and added a caching layer on top. I wanted to take some time to dig in to that code and see how we can make it better.

Decorators give us a tool to add additional functionality to a class while still keeping the public API consistent. From the perspective of the client, this is a win-win! Not only do they get the added behavior, but they don’t need to call different methods to do so.

With so many services available these days, it’s almost impossible to find or build an application that doesn’t rely on a third-party service. Most developers that have dealt with billing systems within the past few years have likely heard of Stripe. Stripe is, by far, the most developer-friendly billing service I’ve implemented.

While Stripe does provide a number of features and plugins that make updating a credit card or signing up for a service simple, there are occasions when data needs to be fetched from Stripe in real-time. For these cases, it’s great to be able to fetch and cache this data before-hand, and only expire if you know there’s been a change.

It’s no mystery that I’ve grown to love Rails fixtures. And I tend to mostly use relational databases in my applications, specifically PostgreSQL.

Most applications have ancillary data that’s required to support the main function of the application — think drop-downs with states for shipping or credit card type.

For the past 2 years, I’ve committed myself to specific goals for the year to come. Most people call them New Year’s Resolutions. Heck, I probably even referred to them as “resolutions” too. But the more I thought about it, the more it dawned on me that a “resolution” felt more like a fix for something — something that didn’t go well in the previous year. Think weight loss (everyone makes this resolution at least once in their life) or a dedication to be more focused.