a series of pipes

notes from building PipelineDeals

Strategies for Testing Ruby Services in a Rails app

At PipelineDeals, we follow the microservice architecture pattern. Many of our features are separate applications that expose a REST API. But this poses a challenge for testing our service applications.

This post describes a strategy for using an adapter to isolate the service in question, and then outlines a different strategies for testing the service integration.

Sattelite Apps

Continue reading →

A more serious postmortem/retrospective on Vagrant

Well that made people angry.

Really angry.

But amidst all the hoopla, some people did make some really good points about me coming across as a childish nincompoop. Also, I sounded too condescending and derogatory of the incredibly valuable field of devops, and didn’t judge fairly. All fair accusations.

This didn’t upset me. I mean, such a dousing of founded criticism is always a little hard to stomach. But it didn’t upset me a lot, not really. Maybe if I had written the article recently it would have. But I wrote it a year ago! So I sort of watched this all roll in from a distance. People were displeased with past me! But hey, so am I.

However, I am not displeased with my decision to stop using Vagrant. I think that was definitely the correct decision for our team, at the beginning of 2014. I think I wasted a lot of time in 2013, trying to keep our Vagrant hobbling along.

This coming from the only person on our team to ever push for Vagrant! I championed it for years. I still think of it fondly. (I certainly overstated the title of the last article. I tried to make the whole thing quite sensational. Perhaps people reacted against my sensationalism. Fair enough.)

Maybe someday we’ll return to it. But not now. And here’s why.

Hark! A Vagrant

Continue reading →

Why You Shouldn't Use Vagrant: Real talk from a Vagrant burn-out

This was originally published on Chad’s personal blog on 21 Feb 2014.

Hey, kid. Someday, some charmer is going to smooth talk you.

Why would you want MySQL and PostgreSQL both running on your machine all the time? they’ll probably ask. Just run them when you need them.

Then they’ll tell you about some slick way their company allowed all of their developers to click buttons on some website, like ordering a Fatty Meal at a McDougle’s: MySQL, Redis, a custom queue server, and our main app, please. Then BOOM. They get a fully configured VM, just like that! With exactly the things they need and none of that other crap. They spin it up, they get their work done. No fuss, no hassle. No having developers waste time configuring their environments.

And most of all, your charmer will woo you with how you’ll never again have developers saying, it works on my machine! That’ll be their biggest selling point. It will also be their biggest lie.

cake saying "I am nutritious." The cake is a liar.

Continue reading →

Wrapping Rest APIs with Ruby

At PipelineDeals, we have a growing number of satellite apps—we still have one main monolithic Rails app (which we’ve started calling p.core), but ever so slowly, we have ported bits & pieces of functionality out to smaller, separate apps. These apps communicate with p.core and each other in a couple of ways:

  1. A pubsub messaging system we built ourselves
  2. Our own APIs!

Essentially, our main Rails app (p.core) broadcasts events that happen in the system to any satellite app that pays attention. So, for instance, if a person’s email address was updated, we would send a pubsub message like person:updated:123456 and the payload would include information about the attributes that changed.

Conversely, when a satellite app needs to make a change to a model in p.core, the satellite app will use our public api to write changes.

When using our own APIs, we’ve grown into a pattern for wrapping them with Ruby classes that feels very clean and predictable to us.

our architecture imagined as a space elevator. Earth is p.core, the end of the elevator a satellite app, and the cable our api. The elevator box itself is composed of our Ruby classes.

Continue reading →

Introducing A Series of Pipes

We on the PipelineDeals engineering team feel proud of the work we do! But you wouldn’t know it by looking at the previous (lack of) content on this blog. We aim to change that.

So why the name change? Reason 1: our previous WebTwoPointOh-style name for it, PipelineDeals DevBlog, makes us want to take a nap. Reason 2: software engineering has a lot in common with plumbing (an idea I stole from @ngzax, who probably stole it from somewhere else).

Allow us to open the access panel and show you how it all works

Continue reading →

Achieving consistent, worry-free, super-fast deploys using AWS and ELBs

At PipelineDeals, we deploy code frequently, usually 2-3x per week, and sometimes even more often. As all web application developers know, deploying is sort of a nervous process. I mean, sure, 99.99% of the time, everything will go perfectly smooth. All your tests pass, your deploy to staging went perfectly, all the tickets have been verified. There is no reason to fear hitting the button. And, the vast majority of the time, this is true.

But all web application developers also know that sometimes, there is a snag. Sometimes the fates are against you, and for whatever reason, something goes bust. Perhaps you have a series of sequenced events that must occur to deploy, and one of the events silently failed because the volume that /tmp is mounted on temporarily had a 100% full disk. Perhaps that upload of the new assets to S3 did not work. Perhaps you did not deploy to ALL the servers you needed to deploy to.

And then, the worst happens. For a short period while you are scrambling to revert, your customers see your mistake. They start questioning the reliability of your system. Your mistake (and it is yours, even if some bug in some server caused the problem) is clearly visible to your customers, your bosses, and your peers.

Continue reading →

What it means to be truly geographically redundant on AWS

PipelineDeals is hosted on Amazon’s AWS cloud platform, and has been since 2007.   During these years we have been exposed to two separate mass outages, all of which affected their US-EAST availability zone.

Compared to other AWS availability zones, US-EAST center is their busiest, has the cheapest hourly server rates, and (happens to be) the most prone to massive outages.

Given that the majority of our customer base happens to be closer to the east coast, we keep our servers hosted in US-EAST.  What this means, however, is that we must be prepared to jump ship to another availibility zone with as little downtime as possible.

Continue reading →

Announcing V3 of the PipelineDeals API

The developers at PipelineDeals are happy to announce a new version of our API. V3 introduces many changes, including the following:

Continue reading →

Javascript error reporting for fun and profit

Here at PipelineDeals, our app is very Javascript intensive. In fact, for our Jupiter release, we moved much of our logic from rails to the browser and Javascript, using Backbone.js, Coffeescript and a host of other new cutting edge technologies.

During deploys and other edge cases, we want to know if a user has received a javascript error, just like we would with any other type of exception. We deploy very frequently. A few weeks ago we ran into a problem where one of our app servers did not minify and concatenate one of our javascript files correctly, and led to a host of issues that customers saw. In order to prevent this in the future, we decided to search around and see if we could have javascript errors report to one of our favorite tools, NewRelic RPM.

As it turns out, catching and reporting Javascript errors is pretty easy. We ended up hooking into window.onerror, which we define right after we add jQuery, right at the top of the page.

Continue reading →

Improving Rails Performance with Twitter's Kiji Ruby

In March, Twitter unveiled “Kiji”, an effort to significantly reduce the impact of running the garbage collector in the Ruby Enterprise Edition (REE) runtime.  Many have criticized their effort because it focused on the older 1.8.7 instead of the newer 1.9.x version of ruby.   But for older, larger apps that still run Rails 2.x or need ruby 1.8,  Kiji may be worth exploring.

MRI relies on a single heap that basically resembles  a slab allocator.   New slabs are created via malloc()  and carved up into a fixed 40-byte slot.  Each slot can hold a variety of ruby objects.   When a slab becomes full,  GC is invoked to clean things up by looking for non-reachable objects.  If the slab is still full after GC, then a new slab is allocated.

Continue reading →