Building VTS

The Official VTS Engineering Blog

Ruby Metaprogramming by Example

By Dean Nasseri

In Ruby the term metaprogramming refers to the dynamic nature of the language, which allows you to define and redefine methods and classes at runtime. Metaprogramming is often presented as a very nebulous and dangerous concept, one that is difficult to explain and hard to wrap your head around, and thus should be avoided. I’d like to to take some time to show a few powerful uses of metaprogramming techniques in real live code.

Route53 SSL Naked Domain Redirect

By Karl Baum

In a previous post, I wrote about the “shortcut” we took in configuring our naked domain to point to our Heroku app within Amazon Route 53. To recap, we pointed an A record directly at the IP address of our Heroku application. Unfortunately Heroku application IP addresses tend to change from time to time. This meant that we needed to monitor our naked domain to ensure it was still functioning. We set this up back in January and every now and then over the last 10 months, our root domain would stop working. Each time it would stop working, we would get an alert, and I would dutifully log into the Route 53 console and update the A record to point at the new IP address. Well, for some unknown reason, the IP address changed two consecutive nights and each morning when I awoke, I saw the alerts and had to fix our root domain. I was finally convinced that this “shortcut” was not good enough.

As outlined in this article, Heroku recommends pointing an Alias record directly at an S3 bucket and configuring that S3 bucket to redirect. The problem with this approach is that it does not support SSL. That means that will correctly redirect to but will cause the browser to show a security error. Fortunately, instead of pointing our alias at an S3 bucket, we can point it to a cloudfront distribution with our SSL certificate installed. We then can point our cloudfront distribution at Heroku as our origin server. Our application deployed at Heroku can then perform the redirect of to

A Brief History of Vim

Recently I had the pleasure to participate on my first Vim Meetup and it was absolutely amazing to see a bunch of enthusiasts talking about this editor that has been continuously growing since its inception.

There was something exciting about this particular Meetup, someone was going to talk about its history! The talk was great and we even got to play with some of the editors that inspired Vim.

Promise Like a Kid

By Gustavo Matias

A promise is simply a way to handle responses from an asynchronous request. An example I really have fun imagining is when I was a kid, whenever my mom and I would go grocery shopping, I would beg her to buy some of my favorite cookies.

However, with one condition. She would allow me to run to the cookie lane as long as I promised her that I would come back with the cookie’s price, which she would then decide wether or not to buy it based on its price. Meanwhile she could continue with her regular grocery shopping.

On my way to the cookie lane there was a challenge though, not get lost or kidnapped. Fortunately that never happened so my promise would always get resolved and I would come back with the price :). That right there was one of the first times I got introduced to promises without even realizing it, so exciting!

Applying that in Angular is much more fun and also less dangerous, you get to make any type of request to servers that can be miles away, while you can go on with executing some other code and decide what to do when that far away server responds. All of that without even having to get away from your computer and no risks to get kidnapped, how cool is that!?

Adventures in Upgrading to Heroku Cedar-14

By Karl Baum

Heroku has deprecated their old Cedar-10 stack and the time came for us to ugrade to Cedar-14. The problem was that when we tried it out within our staging environment, our homepage response time went from 50ms to around 8000ms. That’s just the homepage which did practically nothing. Nate Berkopec recently wrote a great post on rack-mini-profiler and the flamegraph jumped out at me as a great tool to dig into this issue.

First I had to make mini profiler available within our staging environments on Heroku. I know mini profiler can run within production, but it was a bit much for my stomach to handle. For now, I made the following gems generally available in all environments within our Gemfile.

gem 'flamegraph'
gem 'rack-mini-profiler'
gem 'stackprof'
gem 'memory_profiler'

Then I added the following before_filter within our application_controller.rb.

before_filter :check_rack_mini_profiler


def check_rack_mini_profiler
  #allow for rack mini profiler in staging with a param
  if params[:rmp] && !Rails.env.production?

I ran the flamegraph against our homepage on Cedar-14 with the following url using the rmp and pp query params.


Here is what came back.

Flame Graph on Cedar-14

Zen and the Art of Rails Routing Constraints

By Alex Wheeler

Rails is an amazingly powerful web framework that no doubt stands out as one of my favorite technologies I have the pleasure of working with every day as a software engineer at VTS. One of its greatest characteristics, and surely why it has gained so much traction over the last decade, is how dead simple it makes accomplishing certain tasks. While there are countless books that cover most of the things we love about Rails, something I’ve found myself appreciating recently is the concept of routing constraints, which are provided to us via the ActionDispatch::Routing::Mapper::Scoping module.

At a high-level Rails provides 3 types of constraints - HTTP verb constraints, segment constraints, and request-based constraints. We’ll start with the simplest - HTTP verb constraints. The match method commonly found in routes.rb takes a via option, which can be used to constrain multiple HTTP verbs to a given route.

Http Verb Constraints

match 'properties', to: 'properties#index', via: [:get, :post]

VTS Engineering Core Values

By Andrew Lin

What qualities make a good engineer at VTS? Here’s our unedited document below. Read on afterwards to see how we developed it.

VTS Engineering Core Values

Headings are ideas with their own meaning, but are nuanced by the bullet points nested underneath. Importance is indicated by ranking in list, not by number of bullet points.

1. Passion

  • Driven, takes initiative, self-motivated

  • Software Engineering feels like a hobby.

  • Enthusiasm about technology, learning

2. Collaboration

  • Make each other better

  • Willing to put own work aside when a teammate asks for help

  • Good communicator

  • Sense of humor

3. Empathy

  • For clients, other devs, other departments

  • Respectful

How We Run Migrations

By Paul Gut

Running migrations is hard, especially when you’re dealing with an ever-changing, sophisticated data model. Or, better put, running migrations can be hard. Having dealt with every type of migration problem imaginable here at VTS, over the years we’ve developed a system that actually makes migrating one of the smoothest parts of our deployment process.

It’d be selfish to keep this knowledge entirely to ourselves, so here it is. Below are three very simple principles that will save you 95% of the hassle associated with database migrations. And yes, you’re right - I made up the 95% figure. In reality, I’m sure it’s much higher.

Make all data migrations asynchronous background jobs

In order to successfully deploy an app without bringing it down for too long, it’s essential that the db:migrate process executes quickly.

Imagine the following scenario: right before the deploy, one of your engineers opens a pull request that renames a heavily used column in one of your models. She replaces all the references to the old name in the code by the new one, and she adds a migration that changes the actual name. Simple enough - renaming migrations run very quickly, so the app should be good to go in a matter of seconds, right? You merge the pull request and deploy.

Interning at VTS

By Phil Fishbein

Interning at VTS

This past summer has been one of my best for one simple reason: VTS decided to interview me, an 18 year old, and give me an internship (most companies would simply throw my résumé away). I’ve been an intern at VTS for the last week of June, all of July, and the first half of August. There is nothing like being on a real collabrative team working towards one goal. Being from central New Jersey meant that people who enjoyed software development were few and far between. This meant that most of my software education was self taught, and most of my projects had me as the only team member. Engineer Photo


There’s something to be said about the culture of startups in general. It’s a fast-paced environment where work moves fast. In larger companies, it can take weeks or even months to push a feature. At VTS, it takes a few days; a week at most. VTS especially has a very unique culture. From random push-ups to random clapping, VTS is a really fun and productive place.