Category Archives: {Code}

For a weekend project I built a backlight array for my TV which gives off ambient lighting according to what colors are being shown across the edges of the screen. Powered by a microduino and Abalight software for Mac.

According to the experts, backlights offset the brightness of the screen by lighting up the entire wall, while also giving the impression that the movie is bigger than just the screen.  I just say “woot.”


I recently had an issue with a server hosted at   One Saturday, it completely failed to boot and there was no SSH access.  After a little pleading with OVH to fix the server(since I had no access) , I was flatly told “No” several times. This was a dedicated server and as such, I was responsible for all aspects of its software.  “But your physical disks are failing to mount!” No help.  Grrr, ok I can solve this.

Here’s the only problem, I don’t even know what the error is on boot! I can’t see any of the boot screen, so I don’t know where its failing.

OVH has a convenient feature know as Rescue Mode which allows you to boot to an alternative  OS, so you can mount and correct any issues on the primary drive.  Utilizing this feature I got access to the disks and RAID array.  Everything seemed fine, but I ran through all the checks to be sure.

  • Hard Disks – No errors
  • Raid Array – Needed to be resynced, but does not fix boot
  • FileSystem – OK
  • Boot Logs – No help
  • Partitions – Disks are out of order, but does not fix boot

At this point, I’m out of ideas, so I call OVH one more time and ask them to look at the boot screen and tell me where its stuck.  They agree and tell me it boots to GRUB> prompt and stops.  Ok, this is good information.

I log back into rescue and scour the internet for a way to fix this.  The answer is found in an obscure ubuntu forum, which perfectly describes a way to reset the grub loader on each disk in the array, when utilizing a rescue mode.

$ sudo fdisk -l (From this you need to find the device name of your physical drive that won't boot, something like “/dev/sdxy″ - where x is the drive and y is the root partition. Since I was using a software RAID, root (/) was on md1)
$ sudo mount /dev/sdxy /mnt (Mount the root partition)
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ sudo chroot /mnt  (This will change the root of executables to your your drive that won't boot)
$ grub-mkconfig -o /boot/grub/grub.cfg (insure that there are NO error messages)
$ grub-install /dev/sdx (NOTE that this is the drive and not the partition. try grub-install --recheck /dev/sdxy if it fails)
Ctrl+D (to exit out of chroot)
$ sudo umount /mnt/dev
$ sudo umount /mnt/proc
$ sudo umount /mnt/sys
$ sudo umount /mnt


Hopefully this will save someone some agony in the future and give you a few hours of your life back.


I recently need to set up caching for a very slow API service I was working with.  However the app I was working with forced a query param of “timestamp” on all requests.  This effectively killed the cache because all api requests were flowing through a single endpoint, and only the query params differentiated the requests.  So here’s how to set up caching and strip out query params with nginx.

http {
    # Create a storage location for 
    # caching and call this location "my-app"
    proxy_cache_path /data/nginx/cache levels=1:2 
         max_size=100m inactive=60m;
    server {
        location /api/  {
            # Strip out query param "timestamp"
            if ($args ~ (.*)&timestamp=[^&]*(.*)) {
                set $args $1$2;

            # Use the "my-app" cache defined above
            proxy_cache my-app;

            # Only cache 200 responses and cache for 20mins
            proxy_cache_valid 200 20m;

            # Create a unique cache key
            # Proxy the request

I’ve been learning a lot of Reactive Extensions (Rx) lately, and in the spirit of learning I decided to share some 984368initial thoughts on the concepts and give a very light overview.  Rx is very deep, but hopefully this article gives you an initial understanding and examples to solidify the knowledge.

If you haven’t heard of Rx before, I highly recommend reading Erik Meijer’s blog post in which he describes an alternate way of thinking about events.  In short, he describes events (mouse clicks, keyboard events) as a stream of data.  Think of an array where you have a list of items but with the added element of time in between each item.  For example, as your mouse moves it creates a stream of coordinates. (The dots represent time passing)

mouseMoves = [….{x: 45, y: 45}…….{x: 45, y: 50}…..{x: 50, y: 50}…]

See, mouseMoves is just an array with time between the items.  This is what is known as an Observable.

Once we have an observable, we can do all kinds of things to the stream of data.  We can filter it for certain items, we can map over each data item and transform it to something else, we can merge it with another Observable to create a new data stream.   The documentation for the javascript implementation, gives you just a taste of what you can do.

A Practical Example – Mouse Moves

Let’s say that we want to add a listener to our page that detects whenever the mouse hovers over an image tag.  In addition, while we want to know whenever the mouse is hovering over the image, we also want to throttle the number events actually occurring.  The following Rx code accomplishes this in just a few lines of code.

Let’s take this line by line to see just what is happening.

After querying the page for a list of image tags, we create two new Observables by attaching them to the images DOM list.  These observables are now listening to all mouseover and mouseout events.

// Listen to the stream of mouseover events
var mouseOvers = Rx.Observable.fromEvent(images, 'mouseover');

// Listen to the stream of mouseout events
var mouseOuts = Rx.Observable.fromEvent(images, 'mouseout');

Now that we are listening to events, we want to filter these events to only return every 300ms (as opposed to very fast which it would do right now) and only while we are still hovered over an image.  Here’s how this code works. We loop over the list of mouseover events streaming in using ‘map’. For each event we occur, we create a new Observable that is delayed by 300ms.  And lastly, we filter that nested observable with the ‘takeUntil‘ operator so that we only return a valid event if the mouse has not left the image.  At this point, the event is then returned to the outer ‘map‘ result for the final operator, ‘switchLatest.’ Switch latest takes in a stream of events and returns only the most recent event. This operator is especially useful for ajax calls, where you may have made a few requests, but only care about the data from the most recent request made.  Likewise, this returns the most recent mouseover event that was valid.

// Create an Observable for all mouseOvers
var imageHover = mouseOvers.
    // For each (map) mouseOver event
    map(function(e) { 
        // Wrap the event with an another Observable, so we can throttle it
        return Rx.Observable.return(     
            // Wait to see if the mouseOver is still on this same boxart
            // Don't return anything if a mouseout occurred, this stops the observable from returning anything else
    // Return the last throttled event

Now that we’ve created our observable with its propers filers, we simply ‘forEach‘ or ‘subscribe’ over the stream as if it were an array.

// Subscribe to the img hovers
imageHover.subscribe(function(x) {
    console.log('Mouse over image with alt tag: ' + x.alt);

That’s it!  We can now listen for mouseover events on images like an array.

This is just scratching the surface of Rx and we haven’t even touched on how Observables automatically unsubscribe themselves from events or handle errors.  If you’d like to learn and play more with observables, I highly recommend giving Jafar Husain’s interactive tutorial a try.

Been taking a look at ReactJS over the last few days, which is an interesting view library from the folks over at Facebook.  What I really like about it so far is the “componentization” of  objects on a page.  The general idea being,  any part of the page should be able to stand on its own.  Think widgets.  In theory this is a nice idea until components need to interact.  For example, a list of items with a search box that filters the results.  Component 1 is the search box, Component 2 is the list of items.  In the traditional MVC pattern, the controller would be responsible for handling this interaction.  In react, you would create a parent component which would handle the passing of state change to the list component.  It doesn’t really matter what the parent component is, just that its children are the list and the search box.

Considering the issues I have with the traditional MVC pattern for front end web apps, I’m interested in how this approach by ReactJS performs in the real world at scale.  Especially on very interactive web apps.  In past large web apps, I’ve used an event bus to facilitate the communication between components and thereby reduce tight coupling.  My initial concern is that there will be hooks and callbacks being passed through each component in ReactJS, making the code a challenge.

Time to dig in and see the real world results.

I recently read The Principles of Object-Oriented JavaScript by Nicholas Zakas and was enthralled by his patterns for prototypal inheritance of both instantiated and non-instantiated objects.   As I put each of these patterns to practice I noticed an interesting “discrepancy” between the the way each was linked to its parent.  I thought it was interesting enough for me to dig into, so it might make an interesting blog post.

Example 1: Instantiated Object Inheritance

In the example below, we create our parent class “Animal” which is created via the function method.  We attach a simple method to the prototype which retrieves the private “species” variable.

Then we create a “Dog” subclass by creating it via the function method, then linking the two classes with

Dog.prototype = Object.create(Animal.prototype);

This overrides the default Dog prototype with the Animal prototype, resulting in the correct prototype chain.  Here is a very abbreviated version of the prototype chain.

Screen Shot 2014-05-14 at 4.43.33 PM

Note the very important constructor attachment required after we override the prototype.

Dog.prototype.constructor = Dog;

Pretty common sequence to chain these two classes together.  Any changes made to Animal will get automatically chained to Dog.  Now let’s take a look at the non-instantiated example.

Example 2: Non-instantiated Object Inheritance

In this example we’ll use a IIFE (Immediately-invoked functional expression) to create our parent class, with our retrieval function as above.  This pattern is common for singleton type use cases.

Now notice how we chain the prototypes of the Animal and Dog classes, specifically what is passed to the Object.create() function.

var myDog = Object.create(animal);

No mention of a prototype!  Why not?  Why are we attaching the object itself instead of its prototype?

The reason is because of what Animal is in this second example.  In example 1, Animal was created via the function literal resulting in an object with a full prototype chain inherited from Function. In the second example, animal was created via the inline object declaration “{}” resulting in an object with a prototype of “null”. To put it shortly, an object only has a prototype property if it was created via function literal.

Screen Shot 2014-05-14 at 4.43.40 PM

So if you called the following code, you would get a big fat error because animal has no prototype property.

var myDog = Object.create(animal.prototype); //TypeError

So in example 2, the Animal object itself is what gets chained to myDog. MyDog  can now add its own methods without modifying the original Animal object.