Closures and Callbacks: Running Arbitrary Task Sets Synchronously in JavaScript

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.

Asynchronous JavaScript - Without Failing Capybara Tests

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.

How to Stay Classy With Ruby Variables

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 101

“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.”

Using Helper Methods to DRY Up Rails Forms

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.

Exploring Security and Secret Tokens Through Facebook Login

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.

Struct: Ruby’s Quickie Class

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

class Player
  attr_accessor :name, :number

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

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

  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}, #{}!\n"

team ="Magic Johnson", 15),"Michael Jordan", 9),"Larry Bird", 7),"Charles Barkley", 14),"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.

Lessons From a Failed Successful Gem

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: