D R A F T

Sunday, November 6, 2016

Consul - Micro Services Discovery

Consul Service Discovery

Consul is a HashiCorp tool for service discovery, service registry, and health checks.
Service Discovery and Configuration made easy, distributed, highly available and data center aware.

Service Discovery:Consul makes it simple for services to register themselves and to discover other services via a DNS or HTTP interface. Register external services such as SaaS providers as well.

DNS Query Interface: Look up services using Consul's built-int DNS server. Support existing infrastructure without any code change.

$ dig web-frontend.service.consul. ANY

Failure Detection: Pairing service discovery with health checking prevents routing requests to unhealthy hosts and enables services to easily provide circuit breakers.
Multi Datacenter: Consul scales to multiple datacenters out of the box with no compilcated configuration. lookup services in other datacenters, or keep the request local.
Key-value storage: Flexible key/value store for dynamic configuration, feature flagging, coordination, leader election and more, Long poll for near-instant notification of configuration changes.

Consul provide a hierarchy Key/Value store with a simple http API. Managing configuration has never been simpler.

$ consul kv put foo bar
$ consul kv get foo
$ consul kv get -detailed foo
$ consul kv delete foo

Consul is designed to be friendly to both the DevOps community and application developers, making it perfect for modern, elastic infrastructure.

Architecture

Every node that provides services to Consul runs a Consul agent. running an agent is not required for discovering other services or getting / setting key/value data. The agent is responsible for health checking the services on the node as well as the node itself.

The agent talk to one or more Consul Servers. The Consul server are where data is stored and replicated. The servers themselves elect a leader. While Consul can function with one server., 3 or 5 (2n +1) is recommended to avoid failure scenarios leading to data loss. A cluster of Consul servers is recommended for each data-center.

Components of your infrastructure that need to discover other services or nodes can query any of the Consul servers or any of the Consul agents. The agents forward queries to the servers automatically.

Each data-center runs a cluster of Consul servers. When a cross-data-center service discovery or configuration request is made, the local Consul servers forward the request to the remote data-center and return the result.

Glossary

Agent: An agent is the long running daemon on every member of the Consul cluster. It is started by running $ consul agent. The agent is able to run in either client or server mode. Since all nodes must be running an agent., it is simpler to refer to the node as being either client or server, but there are other instances of the agent. All agents can run the DNS or HTTP interfaces and are responsible for running checks and keeping services in sync.
Client: A client is an agent that forwards all RPCs to a server. The client is relatively stateless. The only background activity a client performs is taking part in the LAN gossip pool. This has a minimal resource overhead and consumes only a small amount of network bandwidth.
Server: A server is an agent with an expanded set of responsibility including participating in the Raft quorum. maintaining cluster state, responding to RPC queries, exchanging WAN gossip with other data-centers and forwarding queries to leaders or remote data-centers.
Data Center: While the definition of a data-center seems obvious, there are subtle details that must be considered. For example, in EC2, are multiple availability zones considered to comprise a single data-center? We define a data-center to be a networking environment that is private, low latency, and high bandwidth. This excludes communication that would traverse the public internet, but for our purposes multiple availability zones within a single EC2 region would be considered part of a single data-center.
Consensus: Agreement upon the elected leader as well as agreement on the ordering of transactions. Since these transactions are applied to a finite-state machine, our defintion of consensus implies the consistency of a replicated state machine.
Gossip: Gossip is built on top of Serf which provides a full gossip protocol that is used for multiple purposes. Serf provides membership, failure detection, and event broadcasting. It's enough to know that gossip involves random node-to-node communication, primarily over UDP.
LAN Gossip: Refer to the LAN gossip pool which contains nodes that are all located on the same local area network or data-center.
WAN Gossip: Refer to WAN gossip pool which contains only servers. These servers are primarily located in different data-centers and typically communicate over the internet or wide area network.
RPC: Remote procedure call. This is a request / response mechanism allowing a client to make a request to server.

High Level Architecture Diagram

Let's break this image and describes each piece. First of all, we can see that there are 2 datacenters, labeled "one" and "two". Consul has first class support for multiple data-centers and expects this to be the common case.

Within each data-center, we have mixture of clients and servers. It is expected that there be between 3 to 5 servers. This strikes a balance between availability in the case of failure and performance, as consensus gets progressively slower as more machines are added. However, there is no limit to the number of clients, and they can easily scale into the thousands or tens of thousands.

All the nodes that are in a data-center participate in a gossip protocol. This means there is a gossip pool that contains all the nodes for a given datacenter. This servers a few purposes:

there is no need to configure clients with the addresses of servers, discovery is done automatically.
The work of detecting node failures is not placed on the servers but is distributed, this makes failure detection much more scalable that naive heartbeating schemes.
It is used as a messaging layer to notify when important events such as leader election take place.

The servers in each datacenter are all part of a single Raft peer set. This means that they work together to elect a single leader, a selected server which has extra duties. This leader is responsible for processing all queries and transactions. Transactions must also be replicated to all peers as part of consensus protocol. Because of this requirement, when a non-leader server receives an RPC request, it forwards it to the cluster leader.

The server nodes also operates as part of a WAN gossip pool. This pool is different from the LAN pool as it is optimized for the higher latency of the internet and is expected to contain only other Consul server nodes. The purpose of this pool is to allow data-centers to discover each other in a low-touch manner. Bringing a new data-center online is as easy as joining the existing WAN gossip. Because the servers are all operating in this pool, it also enables cross-datacenter requests. When a server receives a request for a different data-center, it forwards it to a random server in the correct data-center. That server may then forward to the local leader.

"This result in a very low coupling between data-centers, but because of failure detection, connection caching and multiplexing , cross-data-center requests are relatively fast and reliable."

Consul Internals

CONSUL Commands (CLI)

Consul is controlled via a very easy to use command-line interface (CLI). Consul is only a single command-line application: consul. This application then takes a subcommand such as "agent" or "members". It also responds to -h and --help, to get help for any specific command, pass the -h flag to the relevant subcommand, for example to see help about the join subcommand:

$ consul join -h

Consul Setup

Consul Service Discovery tool example:

# Run these on all consul servers.

$sudo su

$ apt-get update

$ apt-get install git unzip -y

$ cd /root

$ wget https://dl.bintray.com/mitchellh/consul/0.5.2_linux_amd64.zip

$ unzip 0.5.2_linux_amd64.zip

$ rm -f 0.5.2_linux_amd64.zip

$ mv consul /usr/bin/

$ git clone https://github.com/anupkumardixit/consul_demo.git

# Bootstrap / Web UI Server

---------------------------

$ wget https://dl.bintray.com/mitchellh/consul/0.5.2_web_ui.zip

$ unzip 0.5.2_web_ui.zip

$ rm -f 0.5.2_web_ui.zip

$ cd /root/consul_demo

$ cp bootstrap.json config.json

# Save this keygen! Note, if your key has a slash in it you need to escape them for setup.sh. Or just regenerate one until it doesn't have a slash :)

consul keygen

# Non Boostrap Consul Server

---------------------------

$ cd /root/consul_demo

$ cp server.json config.json

# Consul Agent Server

---------------------------

$ apt-get install apache2 -y

$ cd /root/consul_demo

$ cp agent.json config.json

$ ./setup.sh HOSTNAME ENCRYPT_KEY IP_OF_BOOTSTRAP IP_NON_BOOTSTRAP

nohup consul agent -config-dir /root/consul_demo/config.json &

# Now lets test on our agent server.

$ curl -X PUT -d 'test' http://localhost:8500/v1/kv/web/key1

$ curl http://localhost:8500/v1/kv/web/key1

$ curl http://localhost:8500/v1/kv/web/key1?raw

Monday, October 3, 2016

Java 8 - Writing asynchronous code with CompletableFuture

You probably already know about Futures

A Future represents the pending result of an asynchronous computation. It offers a method — get — that returns the result of the computation when it's done.

The problem is that a call to get is blocking until the computation is done. This is quite restrictive and can quickly make the asynchronous computation pointless.

Sure — you can keep coding all scenarios into the job you're sending to the executor, but why should you have to worry about all the plumbing around the logic you really care about?

This is where CompletableFuture saves the day

Beside implementing the Future interface, CompletableFuture also implements the CompletionStage interface.

A CompletionStage is a promise. It promises that the computation eventually will be done.

The great thing about the CompletionStage is that it offers a vast selection of methods that let you attach callbacks that will be executed on completion.

This way we can build systems in a non-blocking fashion.

public <U,V> CompletableFuture<V> thenCombineAsync(CompletableFuture<? extends U> other, BiFunction<? super T,? super U,? extends V> fn, Executor executor)

The simplest asynchronous computation

Let's start with the absolute basics — creating a simple asynchronous computation.
CompletableFuture.supplyAsync(this::sendMsg);

It's as easy as that.
supplyAsync takes a Supplier containing the code we want to execute asynchronously — in our case the sendMsg method.

If you've worked a bit with Futures in the past, you may wonder where the Executor went. If you want to, you can still define it as a second argument. However, if you leave it out it will be submitted to the ForkJoinPool.commonPool().

Methods that do not take an Executor as an argument but end with ...Async will use ForkJoinPool.commonPool() (global, general purpose pool introduces in JDK 8).

This applies to most methods in CompletableFuture class. runAsync() is simple to understand, notice that it takes Runnable, therefore it returns CompletableFuture<Void> as Runnable doesn't return anything. If you need to process something asynchronously and return result, use Supplier:

final CompletableFuture<String> future = CompletableFuture.supplyAsync(new Supplier<String>() {
@Override
public String get() {
//...long running...
return "42";
}
}, executor);

lambdas:
final CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
//...long running...
return "42";
}, executor);

methods:
final CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> longRunningTask(params), executor);

Creating and obtaining CompletableFuture

Factory Methods:
static CompletableFuture supplyAsync(Supplier supplier);
static CompletableFuture supplyAsync(Supplier supplier, Executor executor);
static CompletableFuture<Void> runAsync(Runnable runnable);
static CompletableFuture<Void> runAsync(Runnable runnable, Executor executor);

Attaching a callback

Our first asynchronous task is done. Let's add a callback to it!
The beauty of a callback is that we can say what should happen when an asynchronous computation is done without waiting around for the result.
In the first example, we simply sent a message asynchronously by executing sendMsg in its own thread.
Now let's add a callback where we notify about how the sending of the message went.

CompletableFuture.supplyAsync(this::sendMsg).thenAccept(this::notify);
thenAccept is one of many ways to add a callback. It takes a Consumer — in our case notify — which handles the result of the preceding computation when it's done.

Chaining multiple callbacks

Transforming and acting on one CompletableFuture (thenApply):

CompletableFuture thenApply(Function<? super T,? extends U> fn);
 CompletableFuture thenApplyAsync(Function<? super T,? extends U> fn);
 CompletableFuture thenApplyAsync(Function<? super T,? extends U> fn, Executor executor);

CompletableFuture<String> f1 = //...
CompletableFuture<Integer> f2 = f1.thenApply(Integer::parseInt);
CompletableFuture<Double> f3 = f2.thenApply(r -> r * r * Math.PI);

lambdas:
CompletableFuture<Double> f3 = f1.thenApply(Integer::parseInt).thenApply(r -> r * r * Math.PI);

Running code on completion (thenAccept/thenRun)

CompletableFuture<Void> thenAccept(Consumer<? super T> block);
CompletableFuture<Void> thenRun(Runnable action);

future.thenAcceptAsync(dbl -> log.debug("Result: {}", dbl), executor);
log.debug("Continuing");
...Async variants are available as well for both methods, with implicit and explicit executor. I can't emphasize this enough: thenAccept()/thenRun() methods do not block (even without explicit executor). Treat them like an event listener/handler that you attach to a future and that will execute some time in the future. "Continuing" message will appear immediately, even if future is not even close to completion.

Combining two CompletableFuture together

Combining (chaining) two futures (thenCompose())
 CompletableFuture thenCompose(Function<? super T,CompletableFuture> fn);

CompletableFuture<Document> docFuture = //...

CompletableFuture<CompletableFuture<Double>> f = docFuture.thenApply(this::calculateRelevance);
CompletableFuture<Double> relevanceFuture = docFuture.thenCompose(this::calculateRelevance);
//...
private CompletableFuture<Double> calculateRelevance(Document doc) //...

Transforming values of two futures (thenCombine())

<U,V> CompletableFuture<V> thenCombine(CompletableFuture<? extends U> other, BiFunction<? super T,? super U,? extends V> fn)

CompletableFuture<Customer> customerFuture = loadCustomerDetails(123);
CompletableFuture<Shop> shopFuture = closestShop();
CompletableFuture<Route> routeFuture = customerFuture.thenCombine(shopFuture, (cust, shop) -> findRoute(cust, shop));
//...
private Route findRoute(Customer customer, Shop shop) //...

Notice that in Java 8 you can replace (cust, shop) -> findRoute(cust, shop) with simple this::findRoute method reference:

customerFuture.thenCombine(shopFuture, this::findRoute);

If you want to continue passing values from one callback to another, thenAccept won't cut it since Consumer doesn't return anything.
To keep passing values, you can simply use thenApply instead.
thenApply takes a Function which accepts a value, but also return one.

To see how this works, let's extend our previous example by first finding a receiver.

CompletableFuture.supplyAsync(this::findReceiver).thenApply(this::sendMsg).thenAccept(this::notify);

Now the asynchronous task will first find a receiver, then send a message to the receiver before it passes the result on to the last callback to notify.

Building asynchronous systems

When building bigger asynchronous systems, things work a bit differently.

You'll usually want to compose new pieces of code based on smaller pieces of code. Each of these pieces would typically be asynchronous — in our case returning CompletionStages.

Until now, sendMsg has been a normal blocking function. Let's now assume that we got a sendMsgAsync method that returns a CompletionStage.

If we kept using thenApply to compose the example above, we would end up with nested CompletionStages.

// Returns type CompletionStage<CompletionStage<String>>
CompletableFuture.supplyAsync(this::findReceiver).thenApply(this::sendMsgAsync);

We don't want that, so instead we can use thenCompose which allows us to give a Function that returns a CompletionStage. This will have a flattening effect like a flatMap.

// Returns type CompletionStage<String>
CompletableFuture.supplyAsync(this::findReceiver).thenCompose(this::sendMsgAsync);

This way we can keep composing new functions without losing the one layered CompletionStage.

Callback as a separate task using the async suffix

Until now all our callbacks have been executed on the same thread as their predecessor.

If you want to, you can submit the callback to the ForkJoinPool.commonPool() independently instead of using the same thread as the predecessor. This is done by using the async suffix version of the methods CompletionStage offers.

Let's say we want to send two messages at one go to the same receiver.
CompletableFuture<String> receiver = CompletableFuture.supplyAsync(this::findReceiver);
receiver.thenApply(this::sendMsg);
receiver.thenApply(this::sendOtherMsg);

In the example above, everything will be executed on the same thread. This results in the last message waiting for the first message to complete.

Now consider this code instead.
CompletableFuture<String> receiver = CompletableFuture.supplyAsync(this::findReceiver);
receiver.thenApplyAsync(this::sendMsg);
receiver.thenApplyAsync(this::sendMsg);

By using the async suffix, each message is submitted as separate tasks to the ForkJoinPool.commonPool(). This results in both the sendMsg callbacks being executed when the preceding calculation is done.
The key is — the asynchronous version can be convenient when you have several callbacks dependent on the same computation.

What to do when it all goes wrong

As you know, bad things can happen. And if you've worked with Future before, you know how bad it could get.
Luckily CompletableFuture has a nice way of handling this, using exceptionally.

CompletableFuture.supplyAsync(this::failingMsg).exceptionally(ex -> new Result(Status.FAILED)).thenAccept(this::notify);

exceptionally gives us a chance to recover by taking an alternative function that will be executed if preceding calculation fails with an exception.
This way succeeding callbacks can continue with the alternative result as input.
If you need more flexibility, check out whenComplete and handle for more ways of handling errors.

Error handling of single CompletableFuture

CompletableFuture<Integer> safe = future.handle((ok, ex) -> {
if (ok != null) {
return Integer.parseInt(ok);
} else {
log.warn("Problem", ex);
return -1;
}
});

lambdas:
CompletableFuture<String> safe = future.exceptionally(ex -> "We have a problem: " + ex.getMessage());

handle() is called always, with either result or exception argument being not-null. This is a one-stop catch-all strategy.

Callback depending on multiple computations

Sometimes it would be really helpful to be able to create a callback that is dependent on the result of two computations. This is where thenCombine becomes handy.

thenCombine allows us to register a BiFunction callback depending on the result of two CompletionStages.

To see how this is done, let’s in addition to finding a receiver also execute the heavy job of creating some content before sending a message.

CompletableFuture<String> to = CompletableFuture.supplyAsync(this::findReceiver);
CompletableFuture<String> text = CompletableFuture.supplyAsync(this::createContent);

to.thenCombine(text, this::sendMsg);

First, we've started two asynchronous jobs — finding a receiver and creating some content. Then we use thenCombine to say what we want to do with the result of these two computations by defining our BiFunction.

It's worth mentioning that there is another variant of thenCombine as well — called runAfterBoth. This version takes a Runnable not caring about the actual values of the preceding computation — only that they're actually done.

Callback dependent on one or the other

Ok, so we've now covered the scenario where you depend on two computations. Now, what about when you just need the result of one of them?

Let’s say you have two sources of finding a receiver. You’ll ask both, but will be happy with the first one returning with a result.

CompletableFuture<String> firstSource = CompletableFuture.supplyAsync(this::findByFirstSource);
CompletableFuture<String> secondSource = CompletableFuture.supplyAsync(this::findBySecondSource);

firstSource.acceptEither(secondSource, this::sendMsg);

As you can see, it's solved easily by acceptEither taking the two awaiting calculations and a Function that will be executed with the result of the first one to return.

Waiting for both CompletableFutures to complete

CompletableFuture<Void> thenAcceptBoth(CompletableFuture<? extends U> other, BiConsumer<? super T,? super U> block)
CompletableFuture<Void> runAfterBoth(CompletableFuture<?> other, Runnable action)

Imagine that in the example above, instead of producing new CompletableFuture<Route> you simply want send some event or refresh GUI immediately. This can be easily achieved with thenAcceptBoth():
customerFuture.thenAcceptBoth(shopFuture, (cust, shop) -> {
final Route route = findRoute(cust, shop);
//refresh GUI with route
});

I hope I'm wrong but maybe some of you are asking themselves a question: why can't I simply block on these two futures? Like here:
Future<Customer> customerFuture = loadCustomerDetails(123);
Future<Shop> shopFuture = closestShop();
findRoute(customerFuture.get(), shopFuture.get());

Waiting for first CompletableFuture to complete

Another interesting part of the CompletableFuture API is the ability to wait for first (as opposed to all) completed future. This can come handy when you have two tasks yielding result of the same type and you only care about response time, not which task resulted first. API methods (...Async variations are available as well):

CompletableFuture<Void> acceptEither(CompletableFuture<? extends T> other, Consumer<? super T> block)

CompletableFuture<Void> runAfterEither(CompletableFuture<?> other, Runnable action)

CompletableFuture<String> fast = fetchFast();

CompletableFuture<String> predictable = fetchPredictably();

fast.acceptEither(predictable, s -> {

System.out.println("Result: " + s);

});

Transforming first completed

CompletableFuture applyToEither(CompletableFuture<? extends T> other, Function<? super T,U> fn)

CompletableFuture<String> fast = fetchFast();

CompletableFuture<String> predictable = fetchPredictably();

CompletableFuture<String> firstDone = fast.applyToEither(predictable, Function.<String>identity());

Combining multiple CompletableFuture together

static CompletableFuture<Void> allOf(CompletableFuture<?>... cfs)

static CompletableFuture<Object> anyOf(CompletableFuture<?>... cfs)

allOf() takes an array of futures and returns a future that completes when all of the underlying futures are completed (barrier waiting for all). anyOf() on the other hand will wait only for the fastest of the underlying futures.

Linux Utilities

Shellinabox

Reference Links:

https://pkgs.org/download/shellinabox

http://linoxide.com/tools/web-remote-your-server/

$ wget http://dl.fedoraproject.org/pub/epel/7/x86_64/s/shellinabox-2.19-1.el7.x86_64.rpm

$ service shellinaboxd start

$ sudo netstat -nap | grep shellinabox

$ netstat -nap | grep shellinabox

Subscription Manager Workaround:

[root@sv2lxmkpdi10 ~]# yum install shellinabox

Loaded plugins: langpacks, product-id, subscription-manager

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

There are no enabled repos.

Run "yum repolist all" to see the repos you have.

You can enable repos with yum-config-manager --enable <repo>

[root@sv2lxmkpdi10 ~]#

Tuesday, November 3, 2015

Mongo Queries

Admin Queries

CRUD Queries:

# Update all document in a collection satisfying a condition of attribute in that collection.
Eg: add {"partner":true} in a collection provider if customers array contains one or more element.
>>> db.provider.update({"customers": {"$ne": [], "$exists": true}}, {"$set": {"partner": true}}, {"multi": true})

# monthly counts of all records
>>>
db.ping.aggregate([
{
$group :
{
_id: { month: { $month: "$created_date" }, year: { $year: "$created_date" }},
count: { $sum: 1 }
}
}
]);

# Distinct query:
>>> db.provider.distinct('region');

# Distinct multiple attribute query:
>>>
db.provider.aggregate([
{"$group" : {"_id" : {region_code: "$region_code" , region: "$region"}}}
]);

# Flatened Query:
db.region.aggregate (
{ $project: {"code":1, "description":1, "metro.code":1, "metro.description":1 , "metro.ibx.name":1, "metro.ibx.description":1, _id:0}},
{ $unwind: '$metro'},
{ $unwind: '$metro.ibx'}
);

# empty & null check
1. {"description" : {"$exists" : true, "$ne" : ""}}
2. {$and: [{description : {$exists : true}}, {description : {$ne : ""}}, {description : {$ne : null }}]}
3. {"$and": [{"description" : {"$exists" : true}}, {"description" : {"$ne" : ""}}, {"description" : {"$ne" : null }}]}

# Array Empty Check
1. { pictures: { $exists: true, $not: {$size: 0} } }
2. { pictures: { $exists: true, $ne: [] } } /* mongodb don't use index if $size is involved */
3. { pictures: { $gt: [] } }

# Regex Queries:
{$or : [{ibx_a: {$regex: /FR/}}, {ibx_b: {$regex: /FR/}}]}

# Persa Ibx:
{"manual_provider_id": {"$ne": null}, "accounts.ibxs.ibx_code" : {"$in": ['RJ1', 'RJ2', 'RJ3', 'SP1', 'SP2', 'SP3', 'SP4']}}

# find duplicate records whose count is greater than 1:
db.provider.aggregate(
{"$group" : { "_id": "$provider_account_name", "status":{$first:"$status"}, "manual_provider_id": {"$first" : "$manual_provider_id"},"parent_sfdc_id": {"$first" : "$parent_sfdc_id"}, "count": { "$sum": 1 } } },
{"$match": {"_id" :{ "$ne" : null } , "count" : {"$gt": 1}, "status" : {"$eq": "ACTIVE"}, "manual_provider_id": {"$eq" : null} } },
{"$project": {"name" : "$_id", "_id" : 0} }
)

# total count
db.provider.aggregate(
{"$group" : { "_id": "$provider_account_name", "status":{$first:"$status"}, "count": { "$sum": 1 } } },
{"$match": {"_id" :{ "$ne" : null } , "count" : {"$gt": 1}, "status" : {"$eq": "ACTIVE"} } },
{ $group: { _id: null, count: { $sum: 1 } } }
)

db.provider.aggregate(
{"$group" : { "_id": "$provider_account_name", "status":{$first:"$status"}, "manual_provider_id": {"$first" : "$manual_provider_id"},"parent_sfdc_id": {"$first" : "$parent_sfdc_id"}, "count": { "$sum": 1 } } },
{"$match": {"_id" :{ "$ne" : null } , "count" : {"$gt": 1}, "status" : {"$eq": "ACTIVE"}, "manual_provider_id": {"$eq" : null} } }
)

Thursday, February 26, 2015

Multiple version of Node NVM or/ 'Home Brew'.

There are 2 ways to install Node:

Manually: use archive from Node web site.

maintain version using NVM (Node version Manager).

HomeBrew (Package Manager): '/usr/local/Cellar' with Base location: '/usr/local/'.

Brew versions for node and other packages / formulas.

Manually Install: NVM - Node version manager

Step 1: Run following Command, by end of this command NVM will be installed

$ curl https://raw.githubusercontent.com/creationix/nvm/v0.11.1/install.sh | bash

Close and open your terminal, it's not necessary to log out, we just need to make sure changes nvm made to your part is actually reflected, by running following command:

$ source ~/.profile

Alternatively run the command suggested on output of script:

$ nvm ls-remote

Should you see the error, -bash: nvm: command not found it may be because git is not installed.

Go ahead and install git and return the script:

$ apt-get install git

Step 2:

And you will be shown a list of all the available versions of node.js. You can always find out the latest stable release by heading to the node.js website, where it's printed in the center of the page.

To install version 0.10.13 (the latest as of this writing) type:

$ nvm install 0.10.13

If you type:

$ node --version

You will now see that node v0.10.13 is installed and active. If you had an older node app that only works with node v0.8.16, and wanted to downgrade, then you would input:

$ nvm install v0.8.16

To install and switch to v0.8.16.

When you're done and want to switch back to v0.10.13, you can do so with nvm's use command:

$ nvm use v0.10.13

Nvm is great and makes switching between node versions easy and convenient. However, there's one caveat. If you type:

$ which node

Home Brew (Package Manager)

Step 1:

~~LM-SJN-00874861:Library anudixit$ brew tap homebrew/versions~~

LM-SJN-00874861:0.12.0 anudixit$ brew tap homebrew/boneyard

Cloning into '/usr/local/Library/Taps/homebrew/homebrew-boneyard'...

remote: Counting objects: 747, done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 747 (delta 0), reused 0 (delta 0), pack-reused 744

Receiving objects: 100% (747/747), 181.57 KiB | 156.00 KiB/s, done.

Resolving deltas: 100% (348/348), done.

Checking connectivity... done.

Tapped 74 formulae

LM-SJN-00874861:0.12.0 anudixit$

Step 2:

LM-SJN-00874861:0.12.0 anudixit$ brew versions node

Warning: brew-versions is unsupported and will be removed soon.

You should use the homebrew-versions tap instead:

https://github.com/Homebrew/homebrew-versions

0.12.0 git checkout 1580f8b /usr/local/Library/Formula/node.rb

0.10.36 git checkout 06b10bc /usr/local/Library/Formula/node.rb

0.10.35 git checkout 51c3f4d /usr/local/Library/Formula/node.rb

0.10.34 git checkout 656117c /usr/local/Library/Formula/node.rb

0.10.33 git checkout 13848bb /usr/local/Library/Formula/node.rb

0.10.32 git checkout 72d9b70 /usr/local/Library/Formula/node.rb

0.10.31 git checkout 51dbf0b /usr/local/Library/Formula/node.rb

0.10.30 git checkout fa636a8 /usr/local/Library/Formula/node.rb

0.10.29 git checkout 7b968c6 /usr/local/Library/Formula/node.rb

0.10.28 git checkout f7d75de /usr/local/Library/Formula/node.rb

0.10.26 git checkout 0901e77 /usr/local/Library/Formula/node.rb

0.10.25 git checkout bae051d /usr/local/Library/Formula/node.rb

0.10.24 git checkout 8c47ff7 /usr/local/Library/Formula/node.rb

0.10.23 git checkout 5ab4328 /usr/local/Library/Formula/node.rb

0.10.22 git checkout 72f61d1 /usr/local/Library/Formula/node.rb

0.10.21 git checkout f8e98c8 /usr/local/Library/Formula/node.rb

0.10.20 git checkout 653960e /usr/local/Library/Formula/node.rb

0.10.19 git checkout 7973d20 /usr/local/Library/Formula/node.rb

0.10.18 git checkout b74c1c9 /usr/local/Library/Formula/node.rb

0.10.17 git checkout f7bbdcc /usr/local/Library/Formula/node.rb

0.10.16 git checkout 1782834 /usr/local/Library/Formula/node.rb

0.10.15 git checkout 89e0a43 /usr/local/Library/Formula/node.rb

0.10.14 git checkout dbc76e5 /usr/local/Library/Formula/node.rb

0.10.13 git checkout f88d5b8 /usr/local/Library/Formula/node.rb

0.10.9 git checkout ec5f331 /usr/local/Library/Formula/node.rb

0.10.8 git checkout ee99542 /usr/local/Library/Formula/node.rb

0.10.7 git checkout e44f345 /usr/local/Library/Formula/node.rb

0.10.6 git checkout 8583540 /usr/local/Library/Formula/node.rb

0.10.5 git checkout 3b589c5 /usr/local/Library/Formula/node.rb

0.10.4 git checkout 10e219d /usr/local/Library/Formula/node.rb

0.10.3 git checkout 71fd5b1 /usr/local/Library/Formula/node.rb

0.10.2 git checkout 91636ea /usr/local/Library/Formula/node.rb

0.10.1 git checkout bfb5239 /usr/local/Library/Formula/node.rb

0.10.0 git checkout 687062f /usr/local/Library/Formula/node.rb

0.8.22 git checkout 3c4a714 /usr/local/Library/Formula/node.rb

0.8.21 git checkout a3ef032 /usr/local/Library/Formula/node.rb

0.8.20 git checkout 9f95fff /usr/local/Library/Formula/node.rb

0.8.19 git checkout 4824d7c /usr/local/Library/Formula/node.rb

0.8.18 git checkout 07783c3 /usr/local/Library/Formula/node.rb

0.8.17 git checkout 59c35b9 /usr/local/Library/Formula/node.rb

0.8.16 git checkout 8aeaf15 /usr/local/Library/Formula/node.rb

0.8.15 git checkout fc6441e /usr/local/Library/Formula/node.rb

0.8.14 git checkout 11b5459 /usr/local/Library/Formula/node.rb

0.8.12 git checkout 3ae0e38 /usr/local/Library/Formula/node.rb

0.8.11 git checkout f24a5f5 /usr/local/Library/Formula/node.rb

0.8.10 git checkout 4c0b143 /usr/local/Library/Formula/node.rb

0.8.9 git checkout fb8447d /usr/local/Library/Formula/node.rb

0.8.8 git checkout 52bdfa1 /usr/local/Library/Formula/node.rb

0.8.7 git checkout ae6acb4 /usr/local/Library/Formula/node.rb

0.8.6 git checkout bfc71f7 /usr/local/Library/Formula/node.rb

0.8.5 git checkout 7b00c66 /usr/local/Library/Formula/node.rb

0.8.4 git checkout 7b2f682 /usr/local/Library/Formula/node.rb

0.8.3 git checkout 31f8d9f /usr/local/Library/Formula/node.rb

0.8.2 git checkout 50ae8e4 /usr/local/Library/Formula/node.rb

0.8.1 git checkout 9ff0a1d /usr/local/Library/Formula/node.rb

0.8.0 git checkout 01f8006 /usr/local/Library/Formula/node.rb

0.6.19 git checkout 83988e4 /usr/local/Library/Formula/node.rb

0.6.18 git checkout 653fb77 /usr/local/Library/Formula/node.rb

0.6.17 git checkout a3ecde3 /usr/local/Library/Formula/node.rb

0.6.16 git checkout ed17582 /usr/local/Library/Formula/node.rb

0.6.15 git checkout e18b02f /usr/local/Library/Formula/node.rb

0.6.14 git checkout 30813c8 /usr/local/Library/Formula/node.rb

0.6.13 git checkout 3b771d0 /usr/local/Library/Formula/node.rb

0.6.12 git checkout 0e8ea8a /usr/local/Library/Formula/node.rb

0.6.11 git checkout 3eec1f4 /usr/local/Library/Formula/node.rb

0.6.10 git checkout 7e202eb /usr/local/Library/Formula/node.rb

0.6.9 git checkout f752570 /usr/local/Library/Formula/node.rb

0.6.8 git checkout 74bff39 /usr/local/Library/Formula/node.rb

0.6.7 git checkout 9a52dcf /usr/local/Library/Formula/node.rb

0.6.6 git checkout 97fce9a /usr/local/Library/Formula/node.rb

0.6.5 git checkout 911726f /usr/local/Library/Formula/node.rb

0.6.4 git checkout 67a2615 /usr/local/Library/Formula/node.rb

0.6.2 git checkout 05b94b9 /usr/local/Library/Formula/node.rb

0.6.1 git checkout b6eb4fc /usr/local/Library/Formula/node.rb

0.6.0 git checkout 6bec7fc /usr/local/Library/Formula/node.rb

0.4.12 git checkout 3eea412 /usr/local/Library/Formula/node.rb

0.4.11 git checkout b6aa338 /usr/local/Library/Formula/node.rb

0.4.10 git checkout 523d360 /usr/local/Library/Formula/node.rb

0.4.9 git checkout 10b3ded /usr/local/Library/Formula/node.rb

0.4.8 git checkout 8d45d93 /usr/local/Library/Formula/node.rb

0.4.7 git checkout cb6a4b4 /usr/local/Library/Formula/node.rb

0.4.6 git checkout 7c0f0d9 /usr/local/Library/Formula/node.rb

0.4.5 git checkout 8241b81 /usr/local/Library/Formula/node.rb

0.4.4 git checkout 83753a9 /usr/local/Library/Formula/node.rb

0.4.3 git checkout f4a925d /usr/local/Library/Formula/node.rb

0.4.2 git checkout 0476235 /usr/local/Library/Formula/node.rb

0.4.1 git checkout 8a60de4 /usr/local/Library/Formula/node.rb

0.4.0 git checkout b4497ec /usr/local/Library/Formula/node.rb

0.2.6 git checkout 8602eee /usr/local/Library/Formula/node.rb

0.3.2 git checkout 168cb3d /usr/local/Library/Formula/node.rb

0.2.5 git checkout f55f417 /usr/local/Library/Formula/node.rb

0.2.4 git checkout 89438ae /usr/local/Library/Formula/node.rb

0.2.3 git checkout 730f311 /usr/local/Library/Formula/node.rb

0.2.2 git checkout 981bb41 /usr/local/Library/Formula/node.rb

0.2.1 git checkout c963a35 /usr/local/Library/Formula/node.rb

0.2.0 git checkout fbb93d9 /usr/local/Library/Formula/node.rb

0.1.104 git checkout ed51a5b /usr/local/Library/Formula/node.rb

0.1.103 git checkout f3e7c1b /usr/local/Library/Formula/node.rb

0.1.20 git checkout 2baa60c /usr/local/Library/Formula/node.rb

0.1.17 git checkout ab7697f /usr/local/Library/Formula/node.rb

0.1.14 git checkout a82e823 /usr/local/Library/Formula/node.rb

LM-SJN-00874861:0.12.0 anudixit$

Step 3:

LM-SJN-00874861:0.12.0 anudixit$ cd $( brew --prefix )

LM-SJN-00874861:local anudixit$ pwd

/usr/local

Step 4:

LM-SJN-00874861:local anudixit$ git checkout fa636a8 /usr/local/Library/Formula/node.rb

Step 5:

LM-SJN-00874861:local anudixit$ brew install node

Error: node-0.12.0 already installed

To install this version, first `brew unlink node'

LM-SJN-00874861:local anudixit$

Step 6:

LM-SJN-00874861:local anudixit$ brew unlink node

Unlinking /usr/local/Cellar/node/0.12.0... 8 symlinks removed

LM-SJN-00874861:local anudixit$

Step 7:

LM-SJN-00874861:local anudixit$ brew install node

==> Downloading https://homebrew.bintray.com/bottles/node-0.10.30.mavericks.bottle.2.tar.gz

curl: (22) The requested URL returned error: 404 Not Found

Error: Failed to download resource "node"

Download failed: https://homebrew.bintray.com/bottles/node-0.10.30.mavericks.bottle.2.tar.gz

Warning: Bottle installation failed: building from source.

==> Downloading http://nodejs.org/dist/v0.10.30/node-v0.10.30.tar.gz

######################################################################## 100.0%

==> ./configure --prefix=/usr/local/Cellar/node/0.10.30 --without-npm

==> make install

==> Downloading http://registry.npmjs.org/npm/-/npm-1.4.9.tgz

######################################################################## 100.0%

==> make install

==> /usr/local/bin/npm update npm -g --prefix /usr/local

/usr/local/Cellar/node/0.10.30: 1547 files, 19M, built in 2.4 minutes

LM-SJN-00874861:local anudixit$

Step 8:

LM-SJN-00874861:local anudixit$ cd /usr/local/Cellar/node

LM-SJN-00874861:node anudixit$ ls

0.10.30 0.12.0

Step 9:

LM-SJN-00874861:local anudixit$ brew unlink node

Unlinking /usr/local/Cellar/node/0.10.30... 5 symlinks removed

LM-SJN-00874861:local anudixit$ git checkout -- Library/Formula/node.rb

LM-SJN-00874861:local anudixit$ brew install node

Warning: node-0.10.30 already installed, it's just not linked

LM-SJN-00874861:local anudixit$ brew link node

Linking /usr/local/Cellar/node/0.10.30... 5 symlinks created

LM-SJN-00874861:local anudixit$ node -v

v0.10.30

LM-SJN-00874861:local anudixit$

Step 10: Switch Versions

LM-SJN-00874861:node anudixit$ brew switch node 0.12.0

Cleaning /usr/local/Cellar/node/0.10.30

Cleaning /usr/local/Cellar/node/0.12.0

6 links created for /usr/local/Cellar/node/0.12.0

LM-SJN-00874861:node anudixit$ node -v

v0.12.0

LM-SJN-00874861:node anudixit$ brew switch node 0.10.30

Cleaning /usr/local/Cellar/node/0.10.30

Cleaning /usr/local/Cellar/node/0.12.0

5 links created for /usr/local/Cellar/node/0.10.30

LM-SJN-00874861:node anudixit$ node -v

v0.10.30

Sunday, January 18, 2015

Application Specific Password - "iphone : imap.gmail.com is incorrect"

How to fix Gmail incorrect password/user name error on iPhone?

Sometimes the iPhone mail app will intermittently stop getting Gmail and the dialog box below will appear. The message "The user name or password for imap.gmail.com is incorrect" can show up even if you have made no changes to your Gmail account settings on the iPhone.

Here are instructions on how to fix this problem should it occur on your device:

Quit all mail clients that are accessing the affected Gmail account. This means the Mail app on the iPhone and any other place you are accessing your Gmail from such as a computer.
Open Safari on the affected iPhone and navigate to this page: http://www.google.com/accounts/DisplayUnlockCaptcha to create application specific password.
Enter your full Gmail address, password and type the characters you see in the picture. Touch the unlock button to verify your account.
Open the Mail app and your Gmail access should be restored.

Tips:

Disable iCloud (Apple) and configure Gmail from Setting > Email .. to get your contact & Calendar from Google Account (you need to setup google's "Application Specific Password").

Sunday, January 11, 2015

No separate schema definition for p-namespace and c-namespace.

p-namesapce (Parameter namespace)
c-namespace (Constructor namespace)

p-namesapce (Parameter namespace)

p-namespace simplifies the setter-based dependency injection code by enabling you to use the parameters to be injected as attributes of bean definition instead of the nested <property> elements.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="addr1" class="com.ixi.samples.spring.cpns.Address">
<property name="houseNo" value="2106"/>
<property name="street" value="Newbury St"/>
<property name="city" value="Boston"/>
<property name="zipCode" value="02115-2703"/>
</bean>
<bean id="constArgAnotherBean" class="com.pfl.samples.spring.cpns.Person">
<property name="firstName" value="Joe"/>
<property name="lastName" value="John"/>
<property name="age" value="35"/>
<property name="address" ref="addr1"/>
</bean>
</beans>

with p-namespace, you can write this as:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="addr1" class="com.ixi.samples.spring.cpns.Address"
p:houseNo="2106"
p:street="Newbury St"
p:city="Boston"
p:zipCode="02115-2703"/>
<bean name="person1" class="com.ixi.samples.spring.cpns.Person"
p:firstName="Joe"
p:lastName="John"
p:age="35"
p:address-ref="addr1"/>
</beans>

It is simple! All you need to do is

Add the p namespace URI (xmlns:p="http://www.springframework.org/schema/p") at the configuration xml with namespace prefix p. Please note that it is not mandatory that you should use the prefix p, you can use your own sweet namespace prefix :)
For each nested property tag, add an attribute at the bean with name having a format of p:<property-name> and set attribute value to the value specified in the nested property element.
If one of your property is expecting another bean, then you should suffix -ref to your property name while constructing the attribute name to use in bean definition. For eg, if you property name is address then you should use attribute name as address-ref

c-namespace (Constructor namespace)

c-namespace is similar to p-namespace but used with constructor-based dependency injection code. It simplifies the constructor-based injection code by enabling you to use the constructor arguments as attributes of bean definition rather than the nested <constructor-arg> elements.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="addr1" class="com.pfl.samples.spring.cpns.Address">
<constructor-arg name="houseNo" value="2106"/>
<constructor-arg name="street" value="Newbury St"/>
<constructor-arg name="city" value="Boston"/>
<constructor-arg name="zipCode" value="02115-2703"/>
</bean>
<bean id="constArgAnotherBean" class="com.pfl.samples.spring.cpns.Person">
<constructor-arg name="firstName" value="Joe"/>
<constructor-arg name="lastName" value="John"/>
<constructor-arg name="age" value="35"/>
<constructor-arg name="address" ref="addr1"/>
</bean>
</beans>

and with c-namespace, it can be written as
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:c="http://www.springframework.org/schema/c"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="addr1" class="com.pfl.samples.spring.cpns.Address"
c:houseNo="2106" c:street="Newbury St"
c:city="Boston" c:zipCode="02115-2703"/>
<bean name="person1" class="com.pfl.samples.spring.cpns.Person"
c:firstName="Joe" c:lastName="John"
c:age="35" c:address-ref="addr1"/>
</beans>

It is same as p-namespace. All you need to do is
Add the c namespace URI (xmlns:c="http://www.springframework.org/schema/c") at the configuration xml with namespace prefix c. The prefix is not mandatory like p-namespace
For each nested constructor-arg eleemnt, add the attribute with name c:<argument-name> to the bean definition and set the actual argument value as attribute value.
If one of your constructor argument is expecting another bean, then you should suffix -ref to your argument name while constructing the attribute name to use in bean definition (like p-namespace). For eg, if you argument name is address then you should use address-ref

Well, the above code has an issue though. It is using the constructor argument names and that will be available only if the code is compiled with debug enabled which may not be the case with production code. So, you will have to use the index rather than the argument names. With index, we can rewrite the above code as follows.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="addr1" class="com.pfl.samples.spring.cpns.Address">
<constructor-arg index="0" value="2106"/>
<constructor-arg index="1" value="Newbury St"/>
<constructor-arg index="2" value="Boston"/>
<constructor-arg index="3" value="02115-2703"/>
</bean>
<bean id="constArgAnotherBean" class="com.pfl.samples.spring.cpns.Person">
<constructor-arg index="0" value="Joe"/>
<constructor-arg index="1" value="John"/>
<constructor-arg index="2" value="35"/>
<constructor-arg index="3" ref="addr1"/>
</bean>
</beans>

With c-namespace:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:c="http://www.springframework.org/schema/c" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="addr1" class="com.pfl.samples.spring.cpns.Address"
c:_0="2106" c:_1="Newbury St"
c:_2="Boston" c:_3="02115-2703"/>
<bean name="person1" class="com.pfl.samples.spring.cpns.Person"
c:_0="Joe" c:_1="John"
c:_2="35" c:_3-ref="addr1"/>
</beans>

You may notice that there is not much difference rather than using index in the place of argument name. Also, the index should be prefixed by _(underscore) to make it as a valid xml attribute name.

You can use both p-namespace and c-namespace in together in bean definition( see below):
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xmlns:c="http://www.springframework.org/schema/c" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean name="person3" class="com.pfl.samples.spring.cpns.Person"
c:_0="Mary"
c:_1="Joe"
c:_2="30"
p:address-ref="address2"/>
</beans>

You may also have noticed that there is no separate schema definition for p-namespace and c-namespace.