Copying NVM node install globally

As the title suggests, if you are setting up node for a server and you want the flexibility to be able to change versions of node, in an ideal world you would want to be able to download and package the versions you need in order to be able to deploy it.  However a quicker (not ideally a neater solution) is as follows:

Run the following command after running the nvm install {version}; nvm alias default {version}

This will copy the version of node you just installed in the /usr/local

Serial control flow in node.js

Node is know for its ability to handle events and async methods etc. but there are plenty of use-cases where might need to get some flow control in place. So not matter what order the callbacks return in, you would like them to be executed in the right order.

There is a nifty npm called ‘nimble‘ which allows you to exactly that. Here’s a code sample to explain how it works:

and so even though the functions return at different times due to different values of timeouts, the output is predictable.

Update: Visting its website you will find more code snippets doing even more cool stuff. like running events in parallel, and running functions on various types of collections.

Selenium 2 Grid, Webdriver Quickstart Guide


selenium-rcAutomated Browser based testing help dramatically reduce the time spent on manual smoke testing. In 2013, this might be an obvious thing to do but it always amazes me how even established enterprises actually still rely a lot of manual functional testing. Mostly because of the lack of continuous delivery methodologies or even basic CI servers that constant keep running tests to prove that either the tests are still valid or the code on the web is still functioning as expected.

Selenium has two flavors:

  • Selenium IDE if you want to be able to do a quick bug re-production script and if you want to automate some bits of the exploratory testing. My pet annoyance about that is its not entirely reliable as it currently only supports Firefox browsers (July 2013)
  • Selenium Webdriver: The latest successor of selenium is a far better proposition. As quoted on its website

    “Driving a browser natively as a user would either locally or on a remote machine using the Selenium Server it marks a leap forward in terms of browser automation”

I set out on setting up a grid recently at work and here are my notes on that. Hopefully this will save someone time.In case you are coming from an older version of selenium, here are some compelling reasons why you should try out webdriver:

    • It no longer has the limitation of the single host origin policy
    • The new version can work around earlier limitations of file uploads, downloads, popups and dialogue barriers. It emulates a user experience via automated scripts
      – You no longer have the limitation of running your tests in a linear fashion, this would increase the speed at which you run tests, helping increase the overall number of test cycles you can do. 


      Here’s the logical order in which most of the test steps take place

      • Developer/Tester writes tests using one of the testing frameworks (JUnit, PHPUnit, Cucumber etc.)
      • The tests are configured to talk to a single selenium server, called the Hub
      • The tests are configured for each environment, which means based on the environment for which the tests runs, it can tell the hub which URL to target the tests on
      • The tests can be configured also to run on a single or multiple browser types
      • The hub has a number selenium nodes registered to it which also register their capability e.g. Types of browser they can start and number of instances of each based on their specification (e.g. RAM, CPU etc.)
      • The tests talk to the Hub via the HTTP Protocol and send instructions
      • The Hub then negotiates on the behalf of the test harness and fans out tests to various nodes based on the requested capability and availability of the nodes
      • The hub also manages the collection of nodes by testing constantly which ones are alive and then de-registering the ones that aren’t any more

      Configuration for Hub

Starting the hub is pretty simple

The hub can take a JSON file as an argument for further configuration

Configuration for Node

obviously you will need to change the location of the hub if its on a different server than the node which would usually be the case.
similarly once the node has started, you can trigger the node as follows:

Further Readings

Creating Perl Modules

A couple of notes to build a Perl Module.

using the module with the require function:

Using the module with the Use function

The difference between the two approaches is that use imports the symbols into the local namespace, so you don’t have to use the namespace anymore.

Making a module

Using the h2xs utility that comes along with PERL

      -A omits the Autoloader code (best used by modules that define a large number of infrequently used subroutines)
      -X omits XS elements (eXternal Subroutine, where eXternal means external to Perl, i.e. C)
      -n specifies the name of the module

The module can be tar and shipped.
To install the module:

This will produce following result

Dynamic hostname for VM’s generated from Virtualbox

I am currently working on dynamic environment provisioning for baremetal and hypervisors. Going through my notes, I found the following post, it was obviously copied from somewhere and i don’t have the URL for it. I am posting it here again for future reference as i think it is a very clever idea.

These scripts are used for simple management of hostnames for several VirtualBox VMs comprising a test or sandbox environment on your local machine.

  • Each VM is configured to use bridged network adapter, so all VMs and the host can see each other
  • A script is installed in each VM to run on post-ifup, which grabs VM’s IP, puts “$IP $desired-hostname $desired-fully-qualified-hostname” into /etc/hosts, changes hostname correspondingly, and puts VM’s hostname and fq-hostname into VM’s properties
  • A script is used on the host machine, which loops through running VMs, and updates /etc/hosts on the host machine and on the VMs


1. On CentOS/RedHat VM:
1.1. put “” to /etc/sysconfig/network-scripts directory
1.2. change HN and FQHN variable values to desired hostname and fully qualified hostname for this VM
1.3. make soft link to the file from /sbin: ln -s /etc/sysconfig/network-scripts/ /sbin/ifup-local
2. On the host use update-vms script to update VMs and host’s /etc/hosts files when VMs are started, stopped, or network configuration (IPs) is updated