app

Understanding the this reference in Javascript

2012-09-15T00:00:00Z

The this reference in Javascript is probably one of the most confusing scoping concepts for people coming new to the language. Understanding, the this reference lets you unlock the mysteries of Object Oriented Javascript and gain a better/more intuitive understanding of how the object model is structured.

Explicitly setting the this reference

Here’s a little code to get us going

function setVar(arg) {
  this.var = arg;
}
var obj = Object.create(null);
obj.setVar = setVar;
obj.setVar('hello');
console.log(obj.var); // => 'hello'

What’s going on here?

- We are declaring a function called “setVar” that sets the “var” property of whatever the “this” reference is pointing to, to the argument it receives
- We then construct an object called “obj”, assign it’s “setVar” property to the setVar function
- Finally we call the setVar function via the obj object

Executing this code, you’ll see that the obj object does now have a var property set to ‘hello’. Even though, no where in our code we are doing:

obj.var = 'hello';

How is this? When you call object.method() the this reference is set to object within the confines of method. In the above case, since we called obj.setVar the this reference was set to point to obj within the confines of the setVar method. And since, setVar adds a property called var to whatever it’s this is, obj was gifted with the var property.

Setting the this reference using “call” or “apply”

Javascript let’s you specify what you would like the this reference to be when calling a function, by using either the call() or apply() functions. The format of call() is:

SomeFunction.call(the_this_object, *arguments)

Rewriting the previous example to use call()

function setVar(arg) {
  this.var = 'hello';
}
var obj = Object.create(null);
setVar.call(obj, 'hello');
console.log(obj.var); // => 'hello'

As you can see, this feels a little more flexible and is sometimes better than the object.method() approach. The apply() function is identical to call() with the only difference between that the last argument is an array instead of your arguments being laid out comma seperated. If we were to use apply() instead it would be:

setVar.apply(obj, ['hello']);

Capturing the this reference

You might often see code that does:

var that = this;
....
Some code follows
        ....

And you might wonder why are they doing this. Inside every function call, the this reference is reset. So for example:

function outer() {
  this.foo = 'blah';
  function inner() {
    console.log(this.foo);
  }
  inner();
}
var obj = Object.create(null);
outer.call(obj);

Running this, results in undefined being logged. Why is that? The this reference in outer is set to obj since we are explicitly doing this by the call() function. However, in inner() the this reference points to a different object, which is why logging the foo property of this in inner() resulted in undefined.

How do we fix this? One way is to capture the this reference and use it.

function outer() {
  var that = this;
  that.foo = 'blah';
  function inner() {
    console.log(that.foo);
  }
  inner();
}
var obj = Object.create(null);
outer.call(obj);

Another way, would’ve been to call inner() using the call() function passing the this of outer to it. Personally, I think this is more readable.

Using the bind function

Javascript also let’s you bind the this reference to a function, so all future invocations of that function will use the object you had initially bound the function to. This is useful when you don’t want to keep remembering to use the call() function. An example of bind()

function setFoo() {
  this.foo = 'bar';
}
var obj = Object.create(null);
var boundSetFoo = setFoo.bind(obj);
boundSetFoo();
console.log(obj.foo); // 'bar'

Here, we are creating a bounded reference to the setFoo() function called boundSetFoo with the object obj being the this. This way of capturing this is particularly helpful when working with events and event handlers.

function eventHandler(evt) {
  if(!this.eventsReceived) {
    this.eventsReceived = [];
  }
  this.eventsReceived.push(evt);
  console.log('event is %s', evt);
}
var evtEmitter = Object.create(events.EventEmitter.prototype);

var obj = Object.create(null);
evtEmitter.on('some_event', eventHandler.bind(obj));

var someOtherObj = Object.create(null);
evtEmitter.on('some_event', eventHandler.bind(someOtherObj));

obj.emit('some_event', 'hi there');

Here we have two objects obj and someOtherObj both of which have subscribed to the some_event event on the evtEmitter object. Notice, how we reuse the eventHandler function but tweak it to bind to the right object just when we need it to. Neat, heh?

TL;DR

Javascript is super malleable, letting you bend it to your will. This malleability lets you come up with incredibly elegant solutions for seemingly intractable problems. But this malleability means, it’s pretty easy to write poor code too.

Using the watch command to maintain consistency of your Redis dataset

2012-08-09T00:00:00Z

As you start using Redis more, you soon find yourself delving into redis' transactions. A traditional RDBMS' view of CAS (compare-and-set) transactions is:

- Lock down the entire database to writes, allowing just the one connection in the transaction to write
- Perform a query to figure out which things need to change (Compare Step)
- Change those things (Set step)
- Release the lock (this happens automaticaly as part of your transaction completing)

Redis, on the other hand uses Optimistic Locking which makes CAS transactions look like:

- Start tracking stuff you think could change while you are in your transaction
- Perform a query to figure out which things need to change (Compare Step)
- Execute the transaction to change those things (Conditional Set)
- Check to see if the transaction completed successfully
- Repeat from step 1 to re-run transaction or just abort

Step 1, where you start tracking stuff prior to doing anything is where Optimistic Locking and the more traditional Pessimistic Locking diverge in a pretty big way.

Optimistic Locking

The general idea behind optimistic locking is that you need to know before hand what you think might change while you are perform a transaction and watch out for that. Pessimistic locking on the other hand, is a more heavy handed approach where you don’t want anything to change while you are in the middle of a transaction. Pessimistic locking, as you might’ve guessed, is more punishing on performance and for write heavy datastores like Redis that need to maintain high performance, it just is not an option. The downside with optimistic locking, though is that more of the heavy lifting falls on the engineer, who needs to put in a little more thought while dealing with transactions. Redis ships with a watch command that lets you specify what keys you want to keep an eye on, prior to running a multi-exec transaction.

An example

All this sounds great, but nothing beats a real-world example to see how to work with this and why it might be harder than you think. Recently, I was working on a task that required me to do just this — when a user logs into our app, figure all of that users facebook friends who are logged in, in our app and send that over.

The setup

The data in our app is structured in the following format:

- Users are hashes of the format “user|<user-id>”
- All currently logged-in users have their facebook ID’s stored in a “logged_in_fb_ids” set
- There is a facebook ID to user ID reverse look up hash map “fb_id_to_user_id_hash”
- Every user has a set of facebook friends ids that contains facebook id’s of people they are friends with on facebook — “fb_friend_ids_for_user|”

So finding the name of someone given their facebook id would look something like:

fb_id = 123456
user_id = redis.hget("fb_id_to_user_id_hash", fb_id)
user_name = redis.hget("user|#{user_id}", "name")

First stab

Given the above structure of data in the redis dataset a first shot at fetching all of the user_ids for all of my facebook friends who are currently logged in the app right now, might look like:

def fetch_loggedin_fb_friends_for_user(user_id)
  fb_ids_of_my_friends_who_are_loggedin = redis.sinter("fb_friend_ids_for_user|#{user_id}", "logged_in_fb_ids")
  user_ids_of_my_fb_friends = redis.multi do |multi|
    fb_ids_of_my_friends_who_are_loggedin.each do |fb_id|
      multi.hget("fb_id_to_user_id_hash", fb_id)
    end
  end
  user_ids_of_my_fb_friends
end

Race condition

The race condition with this approach is that between the time I figure out the facebook id’s of my facebook friends who are currently logged in to my app:

  fb_ids_of_my_friends_who_are_loggedin = redis.sinter("fb_friend_ids_for_user|#{user_id}", "logged_in_fb_ids")

And then figuring out the user_id’s for those facebook id’s, a user could have logged off and I’d be incorrectly reporting someone as being logged on when they are not. Granted, in this case, displaying stale data is not a big deal but there is an easy fix.

What I really want is between the between the time I start querying logged_in_fb_ids, to the time I compute the user_ids for those people, no changes should have happened in the logged_in_fb_ids set. If no changes, were made to this set while I was running my transaction I know that the user_ids_of_my_fb_friends data is accurate.

Fix

The fix in this case, is as simple as watch'ing the logged_in_fb_ids set before kicking off the multi-exec transaction, and then re-running the transaction if something changed.

def fetch_loggedin_fb_friends_for_user(user_id)
  redis.watch("logged_in_fb_ids")
  fb_ids_of_my_friends_who_are_loggedin = redis.sinter("fb_friend_ids_for_user|#{user_id}", "logged_in_fb_ids")
  user_ids_of_my_fb_friends = redis.multi do |multi|
    fb_ids_of_my_friends_who_are_loggedin.each do |fb_id|
      multi.hget("fb_id_to_user_id_hash", fb_id)
    end
  end
  user_ids_of_my_fb_friends
end

failed_cnt = 0
RETRY = 3
my_loggedin_fb_friends = fetch_loggedin_fb_friends_for_user(my_user_id)
while failed_cnt < RETRY && !my_loggedin_fb_friends
  my_loggedin_fb_friends = fetch_loggedin_fb_friends_for_user(my_user_id)
end

Here, we’ve chosen to retry 3 times, someone else might choose to abort the transaction. Your strategy for handling failed CAS transactions would depend on the situation.

TLDR;

Redis' watch command is what you should be using for CAS transactions.

Fight against Software Complexity

2012-05-20T00:00:00Z

Why does software in the industry suck so much? Having worked at couple of startups and big companies as well, I can quite honestly say that of all the projects/repos that I had worked on, there was but one that didn’t suck. The one that didn’t suck, was I’m sure in no small part due to the fact that it was written by just one person, the CTO of the company, and since it was a license-based SDK, there was a vested interest in keeping things organized. Open source software projects, when compared with industry projects, are way easier to understand and in much better shape.

Why is that? It’s my belief that there are a multitude of organizational factors, that come into play, that will connive to make your company’s project complexity shoot through the roof, if you ‘meh’ the fight against complexity. And no, I’m not going to delve too deeply micro things such as variable names, TDD, refactoring etc. Those things work great in the micro, but for being able to enfore them in the micro, you need some macro things to be in place first. It’s those macro things that I’d like to take a step back and rant about.

Fight against complexity begins from the top-down

The CTO of your software company, is probably the most important hire you can make. That person, should:

a) Know the technology stack you are going to be using, like 
    the back of their hand.
b) Have had experience managing projects and watching them 
    fall under the weight of their own complexity.

It’s really important, that when you hand off the tech responsibility for a project/product to someone, that they have complexity really high on their list of things to watch out for. This is the foundation on which your software is being built, so this person better be someone who is paranoid about complexity and will not stand for it.

Hiring process

When hiring engineers, the focus should be on one thing and one thing only — code clarity. No eff'ing puzzles, gotchas, any other crap. Give them a simple problem that requires them to model couple of objects/compose functions if it’s a functional language, and have them write up a program. Look at how readable this is. Someone who takes their craft seriously, almost always keeps things dead simple. They choose variable names that make sense. They are anal about indenting their code. All these things count a lot. Way more than, some crazy probability question that you think is going to suss out the geniuses. You don’t need geniuses – leave them be in their university labs. You need someone who can write clear, well thought out code. If they have a Github/other open source projects, take time to read through them to get a sense of their skill. Bottom line, it’s really easy to open the door to someone and have them shit all over your code-base, if you are not careful.

Team size

I’ve seen this time and again, the larger the team gets that is working on a single repo, the more crappy it becomes. And it’s an exponential curve. If you are a startup, you probably are a little under the gun by some VC hot-shots to hire more, and look big. Screw that, keep your head count small. Hire only the people you really need. If Instagram was able to get by with 7 people (not just engineers), you probably can as well. The more an engineer has a feeling of ownership over a repo/project, the more likely they are going to be to take time and do things right. I know there are some obvious cases to be made against, having just one person/few people work on a repo. Believe me, if you have been anal about your hiring process, they probably have kept things super organized in that repo, thereby making a transition to a new engineer almost trivial. The new engineer, would probably also have a really great first impression of working with a clean and well organized repo. This is crucial, since that new person would probably think twice about screwing things up when they have been given a clean well maintained repo.

Choice of language

I’m not interested in starting a flame war here — Coffeescript rocks or Ruby on Rails still rules or Python is just great or Clojure is awesome whatever.. My suggestion is simple, the higher the level of the programming language you choose when prototyping your app, the less complex it’s going to be. I personally, have a preference for Ruby for it’s clarity — but you should choose the highest level language most people on your team know. Good engineers take their tools very seriously, so the better the tools you are using the better the quality of engineers you are going to find. As you find speed becoming an issue, instrument first to confirm out if it’s the language, and then switch over to something a little lower in the stack. It’s way easier going from a higher to lower level in the programming stack.

Development speed

Finally, it’s often really tempting to give into the mad dash mode of software development. Where all you are doing, is just cranking out code and hoping it sticks. Given a choice, between adding a ton of features in one insane sprint, just to get ready for usability testing — think about cutting down some of the excess feature fat and focus on just the core feature set. It’s a helluva lot easier to add features to a simple repo, than to one that is a rat’s nest. All of the technical debt accrued in the mad dash sprint, is going to slow you down sooner than you think and start grumbles in your engineering team.

TL;DR

I think the complexity creep can be nipped by a) being aware that it exists and b) taking some common sense approaches to fight it.

Memory leaks during Event emission

2012-03-06T00:00:00Z

Javascript has garbage collection, so there’s no way we can leak memory right? Wrong. Memory leaks are pretty easy to create in Javascript much like in any other language that has garbage collection. The problem isn’t that bad when running Javascript on the client – unless you are having a blatantly obvious memory leak that kills your browser everytime the page loads. Writing Javascript on the server on the other hand, means you really have to focus on making sure you are not leaking any memory since your server process is going to be pretty long running.

Creating the leak

Here’s a little javascript snippet:

var events = require('events');
var emitter = Object.create(events.EventEmitter.prototype);

var i = 0;
(function createObject() {
    var temp_func = function() { console.log('hi'); };
    emitter.on('some_event', temp_func);
    if(++i < 10) {
        process.nextTick(createObject);
    }
}());

Now, when you run this it should be just fine, but believe me it leaks memory. The line with the leak is:

emitter.on('some_event', temp_func);

Basically, this line grabs the function object temp_func and pushes it onto an array stored somewhere deep in the bowels of the emitter object. What this means, is that the temp_func object is never going to be garbage collected unless the emitter object is and is the only one having a reference to it. Now you might think, temp_func is a pretty small function but remember, it’s also storing a closure to every var declared in every function it’s nested in. This is fine, if that’s what you want. Often times though, you find your object’s have a lifespan after which they really needn’t be subscribed to events. In which case, you’ll find your unneeded objects still hanging around eating memory. If you know when to unsubscribe from listening to an event, it’s as simple as:

emitter.removeListener('some_event', temp_func);

TL;DR

Anytime you find yourself subscribing to events, try figuring out when to unsubscribe at that same time. Remember, removeListener is your friend.

Custom events in NodeJS using prototypal OOP

2012-02-07T00:00:00Z

I’ve been playing around recently with NodeJS and have found the sheer performance to be insane. Apparently it isn’t just me and a lot of other places have been able to significantly reduce their bloated infrastructures down by a lot by making the switch.

Anyways, the point of this post is not to sell NodeJS, but rather to show how to use it’s event’s API. I confess, I’m not a fan of the Pseudo Classical OOP pattern in Javascript. It just doesn’t feel right, and prototypal OOP works and feels right. Basically, if you are doing something like:

var honda = new Car();

You are doing the pseudo classical way. If you are doing something like:

var honda = car.create();

You are doing prototypal inheritance and you rock!

That said, trying to figure out how in the hell do I emit events in NodeJS sent me on a crazy wild goose chase, look at this Stack Overflow article, since they all were requiring the use of the hated new keyword. Instead, just do the following:

var events = require('events');
var objectWithEvents = Object.create(new events.EventEmitter);

And then you can do:

objectWithEvents.on("yay", function(){
  console.log("Feign enthusiasm!");
});
objectWithEvents.emit("yay");

Hope this helps and yea stick with Prototypal Inheritance in JS. It’s much simpler.

On the future of Software Engineering

2012-01-28T00:00:00Z

Silicon Valley and the rest of the tech industry is going through a very well documented crisis and no, I’m not referring to another tech bubble (although it may be happening). What I’m instead talking about is a chronic shortage of engineers and designers.

While a lot of well known VC’s, angel investors (insert other hot-shot name here) think it’s going to just go away the same way the dot-com bubble burst, I’m not so sure.

This is not 2000 and thinking of today in terms of the 2000 dot-com bubble is wrong. Here’s why…

No cloud computing

This is an ENORMOUS deal. There was no virtualization software back then. No Xen, no vmware. As a result no software as a service products. No EC2, no S3, no rackspace. Nothing. Nada. Web-scale companies such as Facebook, Twitter, Heroku (on which I am hosting this blog) just wouldn’t have been able to get off the ground. Or even if they did, it would have been a super rocky path.

Modern tools and methods

If you were working back in 2000, you were probably using a bloated piece of crappy software like Java. There still are a lot of places that just don’t get what it means to get things done soon using productive tools, but I’ll leave that rant aside for now. Working with a bloated crappy tool meant, slower turn around times between when someone from product would like to see something happen and the engineering doing and it being sput out from QA.

If you’ve worked or spoken with anyone working with Ruby/Python/Javascript I’m sure you’d have been amazed at how fast they got things done. This isn’t because they are some kind of magical breed of human beings, who are able to operate at vulcan speed. It’s because the tools they use are just that good. Look at Paul Graham’s essay on how his company was able to get stuffed ship before their competitors just by making the choice to use the right tools.

Here are just a couple of the awesome tools, we have now that didn’t exist back then:

- Git/Mercurial (distributed version control eff'ing rocks!)
- Github and it's enormous contribution to open source software
- Rails and similar frameworks for Python
- iOS SDK and the App Store
- Agile/Scrum way of working instead of waterfall

Couple these with the cloud computing power from point #1 and you have a recipe for being able to build, argue over, ship your product out in days. The argue step could slow down the workflow just a tad bit, but that’s an unknown :). This stuff takes months in bigger companies/banks and other obsolete corporations!

The employment bottle-neck

Since things are so great and the cost to launch a company and raise capital so little and so easy, a lot of engineers are just going it their own and launching their own startups. You are not going to like any boss as much as yourself, am I right? :)

What now, what comes next

I think the way this glut resolves itself, is that startups find a (to borrow an overused phrase in the financial world) new normal. What this means is startups will start seeing and getting used to having just one person do the role of five from the past. This is further made possible by today’s tools and tech. I spend my day doing sysadmin, developer, machine learning stuff amongst others. This would have been done by atleast 3 different people just a couple of years back. The tools and tech will further evolve to make this new normal possible and efficient.

Once startups get used to the feeling of just having a super minimal head count the demand for new talent will ease up and the market will correct itself.

Who gains the most

The gulf between what it means to be a startup employee and a non-startup employee will widen. If you are a startup founder and are looking for one tech person, you would want that one person to have solved a lot of the tech problems you will probably be running into. In other words, you need someone who has worked in a startup before. This demand, for someone with a specific set of up to date skills forces what economists would call a specialized economy and the one’s benefitting the most from it would be the ones that can meet those specialized demands, i.e. startup engineers and designers.

Comparison of MRI and JRuby GC's for a MMO Game Server

2012-01-02T00:00:00Z

I’ve been looking at using Ruby for building up a stateless game server in a MMO setting. Ruby to many people, means Rails, which in turn means, a web app. The typical web app request when viewed through the lens of memory (allocation & deallocation) and IO (DB writes & reads) looks as follows:

Now, depending on the app you are building and the database you are using and the language you are using you may hit a bottleneck either while allocating or deallocating memory (GC slowness) or while doing IO (latency, DB size etc.). A request to a game server on the other hand looks something like this:

As you can see in the case of a game server, the garbage collector (GC) is really under the gun to perform under extreme stress. With this in mind, I decided to evaluate jruby-1.6.5 and ruby-1.9.2 to see which of these two rubies performs better under the IO characteristic the game server is going to be put through. I created the following two scripts: one for MRI and the other for Jruby. The only difference being, that in Jruby I was using Threads while in MRI I’m using straight up Kernel processes, since I want to do real parallelism and ruby thread’s in MRI don’t do real parallelism, as they still have a GIL.

Results

I knew the JVM has a way better GC, but boy did I underestimate it:

When 20,000 Objects get created and reaped in every request MRI 1.9.2 breaks down at 300 requests per second, while JRuby is at a swaggering 800 req/sec. Once you start getting down to the 3,000 Objects created & reaped per request region, JRuby really starts to differentiate itself at 3600 req/sec while MRI stalls at 1760 req/sec. The JVM’s GC is just way more performant!

Settings

I ran these using RVM on a Mac Book Air 1.6 Ghz Intel i5 4GB RAM, fwiw.

Exploring Java's concurrent packages via JRuby

2011-12-28T00:00:00Z

Threads are back in style these days. If you were like me, a Java engineer getting into Ruby couple years back, you probably would have seen your fair share of JVM bashing by a few people who relished beating on all things Java, while peddling their half-assed gems as software masterpieces. This is not to say that Java, especially it’s community, loves to over-engineer the crap out of everything they can lay their hands on, but (and this is a pretty big BUT) the JVM is a seminal piece of software. Okay, if you are still hanging around after this rant, I thank you for affording me this indulgence.

Having gotten that out of the way, for the next couple of posts I’ll work on exploring some of the concurrency packages Java ships with, along with discussing the Java concurrency model, all the while using JRuby to drive my code.

Why JRuby?

As much as I hate the irrational bashing of another language, I’ve really grown to love working with Ruby. It’s just great for “putting your ideas down on paper”, with minimal ceremony. While for many, this ceremony may not feel like a big deal, it actually is. This talk on cognitive pyschology goes into further detail as to how our brain processes information, and how boiler plate code comes in the way of other engineers understanding your code. Using JRuby also has a unintended benefit of really forcing me to concentrate just on the concurrency and parallelism concepts, without wasting a lot of time of on all those Java'ish things such as final variables or private static methods, amongst others. It’s also going to be a lot more fun focussing only on the awesome things of the Java concurrency packages, while skipping all of the code bloat that is part and parcel of working with Java.

Concurrency and Parallelism

The terms concurrency and parallelism get thrown around a lot and I for one didn’t really understand the difference until I bothered looking it up recently. Here’s a diagram that should help clear it up:

As you can see, concurrency doesn’t mean squat. In the concurrent graph, Thread A runs from time 0-10 and then the CPU scheduler schedules Thread B to run from time 10-20, after which it switches back to Thread A and so on and so forth. So the machine is not actually executing CPU instructions at the same time. In the parallel graph, the machine does execute instructions on both threads at the same time between time 10 and time 30. All this is assuming you have a multi-core CPU of course (if you don’t you probably don’t really want to be reading this or any other blog post on parallelizing work).

Thread Safety

Now that we have understood that parallelism, is really what we are after, we can look at the various problems that arise when you have your code run in a multi-threaded parallel environment. These problems that crop up are all grouped under the broad umbrella called thread safety. So before we look at each of these problems let’s first try and get a sense of what it means to be thread safe.

The simplest way to define what it means to be thread safe is, the invariant of your code is preserved even while running in a multi-threaded environment. What this means, is that, whatever behavior your code said it would exhibit does not change whether it’s running in a single or multi-threaded environment. An example, will help make this clear:

class Incrementer
  def increment
    @val ||= 0
    @val += 1
  end
end

incrementer = Incrementer.new
incrementer.increment

Now as you can see, the behavior this class is promising to uphold is an arithmetic series where every element the increment function returns is 1 greater than the last element it returned. This is the invariant of this code. Now, with a little unlucky timing, in a multi-threaded environment, this invariant can be broken and this function can skip numbers or return the same number it did in it’s previous call. The following line:

    @val += 1

Is not actually an atomic operation, i.e. a computer operation that is exactly one instruction. Rather, it can be thought of as two discrete operations:

    temp = @val + 1   - (1)
    @val = temp       - (2)

With a little unlucky timing, line (1) could complete by Thread A and then Thread B could run and re-execute line (1) in which case it’s reading a stale value of @val. There is also the initialization of the variable, which is not Thread safe, but I’ll leave that for a later discussion. So how do we make this code thread safe?

Synchronization and locks

One of the easiest ways we can make this code thread safe is by requiring that whenever a given Thread is scheduled to run by the CPU scheduler it needs to have a lock. If it does not, it should do nothing and go back to waiting. Java has a keyword called synchronized that let’s a Thread try to acquire a lock on an Object. The thread safe version of the incrementer with this in, looks like:

require 'java'

class Incrementer < java.lang.Object
  def increment
    self.synchronized do
      @val ||= 0
      @val += 1
    end
  end
end

incrementer = Incrementer.new
incrementer.increment

The call to self.synchronized tries to acquire a lock on self which in this would be the instance incrementer of the Incrementer class. Couple of things to note here:

- In order to be able to synchronize on an Object, that Object 
  should have a *java.lang.Object* object somewhere it's ancestry tree
- Ensure that all your threads synchronize on the same Object, or 
  they'll be getting/releasing different locks

This code is actually a case of over-synchronization, and over-synchronization is bad in that, it is slow. To give you a taste of some of the cool, Java packages we can use, here’s an altered version:

  def increment
    self.synchronized do
      @val ||= java.util.concurrent.atomic.AtomicInteger.new
    end
    @val.incrementAndGet
  end

Here we still need to guard a section of our code where we initialize our instance variable. But as soon as we have verified we have a valid reference, we release the lock and call the incrementAndGet method made available to us by Java’s AtomicInteger objects.

Conclusion

Thread safety is when the behavior of your code does not change when it’s run in either a single or multi-threaded environment. Java’s synchronized keyword is the simplest form of Thread safety, that uses a concept called locking where, only a Thread that has acquired a lock is permitted to run. JRuby gets for free a lot of the Java concurrent packages and this is great news for engineers looking to build parallelizable code but are not yet ready to give up on ruby.

Up next

Sharing data, thread visibility, volatile variables, thread safe initialization and immutable objects and how they rock!

Philosophy and Test Driven development

2011-11-23T00:00:00Z

For someone coming to test driven development for the first time & even for those who have been dogmatically following it through the course of their work, the question “What do I test?”, still remains. In this blog, I am going to take a shot at answering that question using tools that Philosophy provides, specifically those employed by Immanuel Kant in his ground-breaking First Critique of Pure Reason. Those coming from a philosophical background, can see me drawing a hugely controversial line in the sand, and choosing to remain on the side against the empiricists by my previous statement. Over the course of this blog, I will go on to defend this position and expand on why an empirical approach to Test Driven development is flawed.

The Scientific Method and Test Driven Development

Over the course of it’s history, the term “scientific method” has gotten horribly and inexorably linked with empiricism. Here’s why – the scientific method to most people means, measuring your way to some kind of truism. The empiricists, rejoice at this incorrect linkage, since this allows them to quiet conveniently slide in a bunch of probabilities into the mix and state confidently that somehow those probablities make that truism all that more true! The fact remains, that science (outside the realm of quantum mechanics which is still under “study”) follows Newtonian physics, which is distinctly anti-empirical. You don’t remember “A body continues in it’s state of rest or constant motion unless an external force acts on it with 99% probablity”. Instead, if you actually peel back a couple layers from the “scientific method” onion, you’ll see scientists quiet often have “theories” (which is a polite way of saying they make stuff up) and then look at measurements as a way of testing the viablity of this theory. Only then, do they try getting the math right to make it acceptable. In many cases, theories just remain unprovable (proving alternate interior angles are equal in geometry for instance) and just remains as something we see and feel to be true, hence it is true.

So how does all this tie in with Test Driven Development? The answer is painfully simple – tests are measurements. So, when working with measurements we can choose to either follow the empirical approach of keeping the focus on measurements, or the Kant'ian and Common Sense approach of giving the benefit of doubt to the thing we think is true, unless we can prove measurably that it isn’t.

So where does this lead us? It leads us to writing more negative tests that cover the edge-cases where the behavior of the system we are building is undefined or at the very least not something you think it’s going to be. In mathematics parlance, if you are modelling in software a non-continuous function you need to be writing tests for where the “continuity” breaks down. An example,

        -
F(x) = | 2,  x != 1
       | 10, x = 1
        -

A quick refresher, this is not a continuous function because the limit as this function approaches 1 from either negative or positive infinity is going to be 2, when in fact the value at 1 is 10. Using this as a guide, we see our test for this function should explicitly state the behavior of this function at 1.

Tying it all together

So how do we employ the Kant'ian world view in our software tests to make more maintainable, understandable software? Don’t write tests for the obvious. If you are writing a function that sums up two numbers, don’t write a test for that. Let that remain a law that’s just understood to be true within the confines of your system. Software engineering after all is making abstract representations of reality. Reality, is that which impinges on our senses and gives us a model in space time of our surroundings. How do we know a table is a table? Does it fulfill some measurements that deem it to be a table? Nope, it just is a table. Similarly, how do we know that we call a sum() function that we have in written into our software system, it actually does add two numbers? We don’t and we shouldn’t be foolishly writing tests to state the obvious, it just is. On the other hand, given the following function:

def sum(a, b)
  if a != 0 && b != 0
    a + b
  else
    1.thousand
  end
end

Here this is most definitely not a continuous function and not something that we can just leave be. Write a test for the case where either a or b or both are zero.

TL;DR

As software engineers, we spend way too much time buried in the minutae of our world. Step out a several million feet, every once in a while and explore how philosopher’s & thinker’s grappled with such fundamental concepts as reality & truth’s thereby laying the foundation for modern science. I can guarantee, you will get a far better perspective of what it is you and I are doing and more importantly what it is that we can take for granted and what it is that we shouldn’t.

Persistance options with Redis

2011-09-23T00:00:00Z

Most people thinking of Redis, think of it is an in-memory datastore. This is totally true. However, there is a lot of misconception with the “in memory” part; as being if my redis server crashes I lose all of my data. This part is most definitely not true. Redis persists your data to disk and provides you with all of the knobs you are going to need to need to fine tune how often you’d like this persist to take place, while still eeking out the performance you’d like to get out of redis.

The two storage options

A picture speaks a thousand words, so here goes:

Option 1: Binary .rdb file

 ----- 
|  R  |
|  E  |    Option 1     ---------------------
|  D  | -------------> | Binary File (.rdb)  |
|  I  |                 ---------------------
|  S  |
 -----

Option 2: A text file popularly known as an Append-Only File (AOF)

 ----- 
|  R  |
|  E  |    Option 2     ---------------------
|  D  | -------------> |  Text File (.aof)  |
|  I  |                 ---------------------
|  S  |
 -----

With both these options, you can create a brand new redis server with the data from your old redis server by simply copying the .rdb of .aof file and pointing your new redis server at the copied file.

What’s the difference?

Besides the obvious fact, that one is in binary the other in text format, you may ask what’s the difference between them? The Append Only File (AOF) is basically a log of all the commands your redis-server has run. Every single operation that your redis server has executed gets written to the AOF. So if you did:

INCR USER_COUNT 1
INCR USER_COUNT 1
INCR USER_COUNT 1

In your AOF you will see all three increment operations. On the other hand, the binary .rdb file is basically a snapshot of all the keys and values in your redis server.

As you may have guessed, the AOF can grow really large since it’s logging every operation; which is why redis has a command called BGREWRITEAOF that as the name suggests rewrites the AOF in the background. The re-write results in a file of way smaller size. Taking the example from above, let’s say that after the third INCR USER_COUNT is now 10. The AOF file will have something along the lines of:

SET USER_COUNT 10

Why even have two formats?

I mean, isn’t it going to be a pain to remember to keep doing BGREWRITEAOF; or you risk running out of disk space? The AOF let’s you do something special which the binary .rdb file just is not going to be able to do. Again, a picture will explain this way more clearly:

 R1  --> /var/db/redis/file_one.aof
 R2  --> /var/db/redis/file_two.aof

So you have two redis servers, each writing to their own files. You can now do:

cat /var/db/redis/file_one.aof /var/db/redis/file_two.aof >> /var/db/redis/file_three.aof

And now bring up a new Redis server pointing at file_three.aof:

R3  --> /var/db/redis/file_three.aof

And this new redis server will have all of the data from servers R1 & R2. How cool is that?!

Merging data across all of your redis servers

Going off on a tangent for a bit here and trying to re-hash the trick discussed above. Let’s say you have multiple redis servers running and they are storing in binary format. You would now like to merge all of their data together, while the servers are running with zero downtime. Here’s one way to go about it:

redis-cli -p <first-server-port> CONFIG SET appendonly yes
redis-cli -p <first-server-port> BGREWRITEAOF
redis-cli -p <first-server-port> CONFIG SET appendonly no

redis-cli -p <second-server-port> CONFIG SET appendonly yes
redis-cli -p <second-server-port> BGREWRITEAOF
redis-cli -p <second-server-port> CONFIG SET appendonly no

All this is doing, is basically flipping the AOF switch, forcing your redis server’s to rewrite their AOF’s and then flipping it back to the binary storage format. You can now, merge these two AOF files by cat'ing them out to a third file as shown before and voila, you now have all of your data from your two redis servers in one AOF file that you can then use to bring up a new redis server (or as a backup).

Which one is better?

For most situations, using the binary format is better. When in doubt, avoid using the AOF – you run the risk of running out of diskspace if you forget to do a BGREWRITEAOF. And if you do end up having to merge data across multiple redis-servers, you could always do the trick shown above. The binary format is also a little faster in couple of redis-benchmarks that I had run.

Fine tuning binary format save strategy

Redis let’s you specify how often you’d like to take a snapshot of your redis DB and persist it to disk. A typical configuration entry that you will in a redis.conf file (here’s an example of one ) will have entries in the SNAPSHOTTING section that look like:

save 900 1
save 300 10
save 60 10000

Read the first line as “Snapshot the in-memory DB to disk every 900 seconds if only 1 key has changed”. The second line as “Snapshot the in-memory DB to disk every 300 seconds if only 10 keys have changed”. And the last line as (you guessed it) “Snapshot the in-memory DB to disk every 60 seconds if 10000 keys have changed”. Now you can play with these parameters and tweak them as you see fit. For instance you could have something like:

save 5 1

Where you’ll be taking a snapshot of your DB every 5 seconds even if a single key has changed. Obviously this is going to come with a performance impact (since disk write’s or fsync’s as they are known the geek world are a time consuming operation), but Redis does support storing your stuff on disk even at this paranoid level! Finally, you can force a snapshot to happen anytime with the BGSAVE command.

Fine tuning AOF save strategy

In AOF mode, redis keeps logging what operations it’s doing in-memory. You can tell redis how often you’d like it to flush this in-memory buffer to disk. In the APPEND ONLY MODE section of a redis.conf file you will see an entry for appendfsync. Typical values are:

appendfsync always
appendfsync everysec
appendfsync no

Where the always and everysec operations are pretty self-explanatory. The no option is kind of a misnomer. With the no option set, redis assumes no responsibility for deciding when it’s flushing the in-memory AOF buffer to disk, it’s let’s the Operating System decide when it needs to be done. Of the three, the no option is generally the most performant, while at the same time being the most risky. The everysec option seems the most popular giving the best of both worlds.

TL;DR

Redis does store your data to disk and has numerous options that let you control how often you’d like it to persist your data. So if this is what is holding you back from using Redis, don’t let it anymore.