Note: Part I will be more theoretical. If you already know about feature flags and want to learn about the rollout and degrade gems, check out Part II and Part III.

What are Feature Flags?

Glad you asked!

Feature flags, also known as “feature flippers,” “feature toggles,” and more, are a way to simply turn bits of code on and off in a live, running application.

While we won’t get into too many of the details in this post, here’s a simple way to think about it. Let’s say you run a bowling alley. Most of the time, it’s a straightforward establishment – lanes, balls, scoring computers, shoes… you get the idea. However, every Tuesday night you turn over the place, and now it’s Cosmic Bowling night! You’re blasting music, shining blacklights, the disco ball is spinning… it’s a different world. How are you going to carry out this operation?

On the Vitals Choice team, we have divided our product into a number of apps. Each of those apps has one running instance per environment , and we have several environments. So as you might imagine, making sure updated code gets propagated through all those places at the right time can be quite the task. Luckily, we have a Hubot instance which does most of the heavy lifting, but even issuing all the Hubot commands for every single app makes you wonder: shouldn’t there be a way to automate this better?

Well, it turns out that an attempt had been made in the past, but we ran into a problem: JavaScript’s asynchronicity. The server hosting Hubot was suddenly told to update all the apps for a particular environment, and the simultaneous processes overwhelmed the CPU and memory.

Considering the problem, I realized that callbacks were the way to go. Hubot comes with an evented system, which we could utilize to force Hubot to only launch one app at a time. Here’s what I came up with, and what I learned along the way.

Recently at work, I spent over a day trying to get one failing test to pass. I tried everything in the code, but no dice. Finally, I realized that the problem wasn’t with my code – it was with the way Capybara works. I want to save you the time I lost, so let’s get to it.

Capybara, to quote its creator Jonas Nicklas, “is ridiculously good at waiting for content.” It knows that when it’s told to find something on the page, or click a link, and it’s not there, don’t sweat it – just keep trying until a default timeout (Capybara.default_wait_time) is hit. When, and only when, that timeout is hit, Capybara will give you an ElementNotFound error.

This works great for most use cases. However, sometimes it just isn’t enough. Let’s illustrate with a real-world example.

Ruby provides a number of options for non-instance-specific variables – class variables (of the form: @@var), constants (in all caps: VAR), and class instance variables (@var).  Which one to use depends on the use case, and to some degree on personal preference.  Let’s explore this a bit.

Constants are meant to be – well, constant.  This is not technically enforced in Ruby; if you redefine a constant during program execution, it will display a warning, but not actually raise an error.  However, the semantic idea of a constant is that it should be defined once and not touched again. Variables, on the other hand, are variable.  They record a particular state that is likely to be redefined at some future point in time.

Now let’s examine some use cases and see where things start to get tricky.  To make things fun, let’s go to the zoo!

“CoffeeScript, c’mon and/ take a sip, they call it/ CoffeeScript, Coff-”

- oh, sorry, didn’t see you there! I was just humming the jingle from CodeSchool’s CoffeeScript course. Been working on it for a few days. I’ve never been a huge fan of the brown caffeinated stuff, but CoffeeScript? I’m addicted.

CoffeeScript is described by its creator, Jeremy Ashkenas, as “a little language that compiles into JavaScript.” Here’s how I would describe it: “JavaScript is written to give you a brain hemorrhage. CoffeeScript is more like a mild migraine.”

Helpers are a pretty nifty feature of Rails. And I’m not just talking about the built-in form helpers and the like, though those are awesome. I’m talking about the fact that you can custom-build your own helper methods to clean up repetitive content. Building your own helpers can be a bit tricky, though, so let’s first review a basic Rails rule that is likely to trip you up. Here are some things Rails doesn’t like:

1. <

2. >

Yup, Rails isn’t a big fan of HTML markup, unless it’s generated directly from the HTML in a view, or by one of the built-in Rails helper methods.

No, no, don’t get angry at Rails!!!  It’s for your own good, to make sure that you don’t accidentally run some sort of evil, malicious script that a user input into a form or submitted in some other way.

Security is really scary.  How scary?  Well, according to this very pretty infographic, it costs US residents $13.3 billion and 383 million hours per year.  And you don’t want to be the one people are pointing fingers at when there is a data breach.  So it’s really important to understand at least the basics of security – if not all the details, then at least some basic points of entry for hackers.

I’ve been working on a project for my upcoming presentation (next week!) at the Flatiron School, and I decided to use Facebook authentication.  This makes sense because users will generally have Facebook logins already, so the barrier to entry is lowered, and I don’t have the responsibility of taking care of a database of user passwords (or password hashes).  However, I needed to take care of a few things in order to make this happen.

Let’s say you have Player and BasketballTeam classes that are defined and used as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class Player
  attr_accessor :name, :number

  def initialize(name, number)
    @name = name
    @number = number
  end
end


class BasketballTeam
  attr_accessor :player1, :player2, :player3, :player4, :player5

  def initialize(player1, player2, player3, player4, player5)
    @player1 = player1
    @player2 = player2
    @player3 = player3
    @player4 = player4
    @player5 = player5
  end

  def starting_lineup
    str = "Ladies and Gentlemen, here is the starting lineup!\n"
    5.times do |num|
      player = self.send("player#{num + 1}")
      str += "\n##{player.number}, #{player.name}!\n"
    end
    str
  end
end


team = BasketballTeam.new(Player.new("Magic Johnson", 15), Player.new("Michael Jordan", 9),
  Player.new("Larry Bird", 7),Player.new("Charles Barkley", 14),Player.new("Patrick Ewing", 6))

puts team.starting_lineup

In this case, since there are always exactly 5 players, I don’t want to pull out an array every time and write team.players[0], and instead I’ve chosen to use 5 similarly named instance variables, so I can do team.player1. This looks nice, but also isn’t ideal. If I want to access player n, this starts to get ugly: team.send("player#{n}").

Well, here’s the good news: as usual, Ruby has a better way for you to do it.

One of our mottos at Flatiron is “Celebrate failure.”  We aren’t trying to get it right immediately – it’s all about trying something, making it work, and then improving on it.

I recently published a Ruby Gem called CheckEverything (the source code is here and the gem can be installed by typing ‘gem install check_everything’ into your Bash console).

Over the course of creating this gem, I’ve made some mistakes, and learned a few lessons: