Image taken from http://imgs.xkcd.com/comics/forks_and_spoons.png

Spork makes running unit tests faster by shortening the loading time. It requires some modifications to your spec_helper.rb file: (example from AC spec/spec_helper.rb)

require 'spork'

Spork.prefork do
  # Loading more in this block will cause your tests to run faster. However,
  # if you change any configuration or code from libraries loaded here, you'll
  # need to restart spork for it to take effect.
  ENV["RAILS_ENV"] = 'ci'
  $LOAD_PATH.push File.join(File.dirname(__FILE__),"..")
  require File.expand_path(File.join(File.dirname(__FILE__),'..','config','environment'))
  require 'spec/rails'
end
Spork.each_run do
  # This code will be run each time you run your specs.
  Dir[File.expand_path(File.join(File.dirname(__FILE__),'/spec_helpers','**','*.rb'))].each {|f| require f}
end

To use Spork: Install spork gem:

gem install spork

Bootstap spork: (then modify your spec_helper)

spork --bootstrap

Run spork in the background: (from application root)

spork &

Add --drb to the running test, for example:

spec spec/models/permissions.rb -c -fn --drb

I don’t need no CloudWatch: my app is bullet-proof

Yes, you have thought out every contingency, every possible happenstance, and every little accident that the universe could throw at your app. You have plans named after most letters of the alphabet. Your app is so strong that it will outlive cockroaches in case of a nuclear attack. However, there's still that devil-spawn butterfly down there in Brazil, waiting for the TechCrunch feature about your app to go live so it can flap its multicolored wings and bring it to its sorry knees. Or better yet, that butterfly and its buddies are waiting for you to showcase the app to potential investors.

Back in the old days (1990's), the best practices to keep a server up and running included smearing garlic on the sides of the server rack, hanging clovers and horseshoes on the door and lighting a candle to Edward Murphy. This list is not exhaustive. Now, with the advent of cloud computing we don’t even know where the servers are, let alone have access to them without getting shot at or eaten by giant Dobermans.

OK, I need CloudWatch; how do I go about it?

Out of the box, the guys at AWS give you five metrics at a frequency of one sample every 5 minutes. For free. These metrics are CPU, Disk Reads, Disk Writes, Network In, and Network Out and are stored for two weeks. To have a look, log in to your AWS console and select the EC2 tab. Once you see the instance you're interested in, click on it: on the bottom half of the console, click the tab labeled "Monitoring". Do it, I'll wait here.

While we are on this screen, go to the "Description" tab and write down the instance id; we'll use it later. To get a collective impression of how things are running, select multiple instances on the top half of the console. The "Description" tab will show nothing useful, but the "Monitoring" section will render an aggregation of metrics, each instance with its own color.

There isn’t much you can do with these metrics but get a feeling on how your fleet is doing. Think of it as licking your finger to get a sense of where the wind is blowing.

In order to close the feedback loop, we need a way to take action based upon conditions we can measure. Enter CloudWatch. On the top of the console, go over the "CloudWatch" tab and select "All Metrics" on the Navigation panel. On the "Viewing" combo box, select "EC2: Instance Metrics". You'll see a list of metrics; we're after the one reading "CPUUtilization" for the MetricName field, and the instance id you wrote down earlier (told you we'll need it) for the InstanceId field. Clicking on it will bring forth a more detailed graph and some nifty buttons on the right side. You can play for a while and go reminiscing with your instance going back and forth in time, up to two weeks ago. The fun part begins with the "Create alert" button.

In the alarm creation wizard you can set up a threshold condition that will trigger the alarm. Once you set this threshold you can define what you want it to do. Alarms can be in one of three possible states: OK, ALARM and INSUFFICIENT DATA. When the threshold condition is reached for the period of time set, the alarm will go from OK to ALARM. This state transition could also initiate an action. Notice that the actions are performed only during state transitions. Let's have a look at this with an example: say you set an alarm whose threshold is 90% CPU for 30 consecutive minutes. During the first 29 minutes the instance is at 90% CPU the alarm is still in the OK state. Worse still, if the CPU is at 100% during those first 29 minutes, the alarm will remain in the OK state. Once the alarm transitioned to the ALARM state, if an action was defined for this transition it will be taken. The alarm will remain in this state until the condition does not hold, i.e. the CPU has been below 90% at least for one sample in the last 30 minutes.

Here's when CloudWatch' sampling frequency becomes relevant: you can have 1 sample every 5 minutes for free, or 1 sample per minute for a monthly fee per instance monitored (at the time of this writing, it was around $3.50/month/instance). If you are sampling once every 5 minutes, and you set the alarm condition for 10 minutes you are actually evaluating only two samples. Conversely, if you take many samples at that rate, things can get very bad till the moment you notice. In short: spend the three fifty and sleep better.

The Succubus
Get More: SOUTH
PARKmore...

would you rather give 3.50 to the loch ness monster?

There's also the third state: INSUFFICIENT DATA. The alarm enters this state when, as is implied in the state's name, it does not get data from the instance. Setting an action for a transition to this state can be immensely valuable: it basically tells you that your instance is dead.

Regarding the actions that can be taken upon transitions: the most obvious is of course sending an email. To set this up you need to define a channel of sorts in the Simple Notification Service (SNS) tab. You set a topic ("database-machines") and assign to it subscriptions (email addresses of people on your team). More interesting alternatives to email are HTTP, SMS and SQS. With HTTP you can set up a web service somewhere that reacts to the alert. And with SQS you can dispatch messages through Amazon's Simple Queue Service; how cool is that?

All that is pretty cool… what else can CloudWatch do?

I'll write about custom metrics and auto scaling in the upcoming posts. Stay tuned!

There are many reasons to write/maintain code in a modular manner. When considering testing, the modular code allows each segment/class/flow to be tested separately. Before you object, let me demonstrate one tip that might come handy. Here is a (simplified) class to be tested:

    
function ModalOverlay() {
    var shown = false;

    this.show = function() {
        // roughly will open a dialogue only in half of the total requests
        if (Math.random() < 0.5) {
            shown = true;
        }
    }

    this.hide = function() {
        shown = false;
    }

    this.isShown = function() {
        return shown;
    }
}

That's right! The overlay code is by no means deterministic but still testable as is. How? Let's inspect the well-known Math.random() method:

    
describe("Modal Overlay Test", function() {
    var mocRandomObj;
    var modalOverlay;

    function MocRandomObj() {
        var predefinedRandomResult;

        this.set = function(result) {
            predefinedRandomResult = result;
        }
        
        this.get = function() {
            return predefinedRandomResult;
        }
    }

    beforeEach(function() {
        mocRandomObj = new MocRandomObj();

        // here goes the punch!
        spyOn(Math,'random').andCallFake(mocRandomObj.get);

        modalOverlay = new ModalOverlay();
    });

    describe("when probability is coined", function(){
        beforeEach(function() {
            mocRandomObj.set(0.4);
        });

		it("should show overlay", function() {
			modalOverlay.show();
			expect(modalOverlay.isShown()).toBeTruthy();
		});
	});
});

As demonstrated above, with a big help from spyOn() a fake code block is called and a known "probabilistic" value is returned. You couldn't ask for it to be any more simple! Generalizing the above approach, we can be extremely flexible and mock all kinds of behaviors in almost every granular level, leaving the tested code intact.

We will be more than happy to hear about your testing/mocking tricks and techniques. If you choose to share any tips or constructive criticism of your own, we are here to listen (and respond).

In Clean Code: A Handbook of Agile Software Craftsmanship, the author describes the optimal structure of an agile function:

The following advice has appeared in one form or another for 30 years or more.

In order to make sure our functions do one thing, we need to make sure that the statements within our function are all at the same level of abstraction.

Usually, the statements are themselves made of functions that also do one thing, leading to a recursive structure. If you think about it, the basic structure of functions is Mind Map. We will illustrate this at the end of the article.

Javascript is really one of the best languages to illustrate this Mind Map concepts because in javascript, functions are first class citizens and functions can be nested very naturally. So let's take a very common example in javascript: the testing of some new feature: the feature is only enabled in some predefined ratio of the page views and then we compare performance vs. the old feature. For example, imagine you want to compare the user experience of two designs of the same button. The cool name for this methodology is Ab testing.

As an example, let's dig into the code for the creation of a COOOOL Button: sometimes, we will use the new style and sometimes the old style:

function createCOOOOLButton(){
    if(shouldUseNewStyle()){
        createNewStyleButton();
    } else {  
        createOldStyleButton(); 
    }
}

In this post, we will focus on the implementation of the function shouldUseNewStyle(). This function is not the most complex function one has ever written, but it is neither so trivial. There are different constraints to deciding whether we want to use the new/old style:

1. Ab test value (generated by the server or randomly)
2. Url parameter (enforce new/old design - mostly used for dev/test phases)
3. Enforce new design for fancy users

Let's try to express this complexity in a single line of code where all the parts belong to the same level of abstraction.

function shouldUseNewStyle(){
    function isEnforcedByUrlParam() {...}
    function isEnabledByAbTest() {...}
    function isEnforcedByUserCategory(){...}
    return isEnforcedByUserCategory() || isEnforcedByUrlParam() || isEnabledByAbTest();
} 

Hey!!! Wait a minute. How do you implement all those functions? The answer is very simple: NEVERMIND. Or more accurately, at the level of abstraction of shouldUseNewStyle, it is of no interest to dig into these details. Writing all those details into separate functions is the essence of the structure of an agile function. It ensures that:

1. The code is structured into small blocks
2. All parts of the blocks belong to the same level of abstraction

Now, we can continue our recursive journey into the details of the implementation. Let's say, we want to read the code of isEnforcedByUrlParam(). No problem, just unfold the line (any descent IDE supports folding/unfolding: even vi!!!) and here is the result

function isEnforcedByUrlParam() {
    function getUrlParameter(variable) {...}
    return getUrlParameter('cool_button_new_style') === '1';
}

It's that simple! The enforcement by url occurs if, and only if, the cool_button_new_style url parameter is switched on. Again very readable. Again, we don't care about the implementation of getUrlParameter() - at this level of abstraction.

Let's end our recursive journey here. Just before you go back home, let me keep my promise and summarize in a single picture the whole structure of the agile function we have described. Let me introduce the Mind Map!!!