# Emerging Graphs – Returning to Nature

### Returning to Nature?

We imitate nature. period

It has been going around for trizillions of years that someone actually found time to write a paper about it. Cameras, imitate the eyes, airplanes, imitate the birds, submarines, does the fishes and so on and on.. What about storing relations between objects. Assume, a person is related to another person. Storing it in a fully normalized database would look like this.

Recon it’s self explaining.

This’s our good ‘ol Relational DB. Fast and memory efficient. Do note that i would have put glittering lights or even a disco ball over the memory efficient tag. Storing so much data and using so little memory was a killer idea in those days. But not any more. read this..

Memory is cheap these days and it’s time we moved out of relational databases. Let’s see how nature handles a simple relationship, like the one in the above example… as a Graph.

Two entities (in this case, two persons), a father and a son. They have an invisible link between them. Direct the link from father to son, it’s a ‘father-of’ link. This is where a Graph Database comes into picture.

### What’s a Graph db?

A graph db has ideally 3 pillars.

1. The nodes
2. The relationships
3. The properties

The relationship connects nodes and the properties add extra values to the nodes and relationships. Let’s see a neat example

I grew up seeing Matrix and it could not be simpler than this. The blue circles are Nodes and the bold directed lines are relationships.

You can see the properties of relationships and nodes in grey squares.

A graph database uses nodes, relationships between nodes and key-value properties instead of tables to represent information. This model is typically substantially faster for associative data sets and uses a schema-less, bottoms-up model that is ideal for capturing ad-hoc and rapidly changing data.

And if you are looking for an entry point into the graph db universe, it’s here

There are lots of resources available for Graphs online and here’s the article that got my attention..

# And the tag is closed..

No, I am not taking about Malcom Gladwell’s bestseller. The much hated (and loved) html tag, <Blink> has finally met it’s maker. We all had our fun, we made texts of various sizes and colors blink and blink all over the screen. Almost a decade back, it was one of the first tags I learned.

The element had already been removed from Internet Explorer, was never implemented in Chrome and was ignored by most browser-makers because it never made it into a W3C HTML spec.

Like many bad decisions, blinking was conceived after a long night of drinking, with Netscape’s founding engineer Lou Montulli lamenting the limitations of Lynx in a bar.

Don’t ignore the fact that in the mid-1990s web pages were rather dull. Fonts didn’t display at all, ActiveX didn’t exist, inline multimedia was in its infancy and Java was still a new kid on the block. Blinking texts gave life to webpages for years.

If there is a <blink> fan out there, you can bring back <blink> from it’s grave using this extension for Chrome.

# String intern() function and String Pool

The Java programming language requires that identical string literals (that is, literals that contain the same sequence of code points) must refer to the same instance of class String. In addition, if the method String.intern is called on any string, the result is a reference to the same class instance that would be returned if that string appeared as a literal. Thus, the following expression must have the value true:

Elucidating, if there are more than one string literal with the same value, they share the memory.

Consider the example. An application X processes the results from a questionnaire which expects an YES/NO response. Adding on, there are more than a billion replies. If you store  all those ‘YES’ and ‘NO’ values separately, you’ll end up clogging up your precious memory. So, why don’t we have a single string for ‘YES’ and let the trizillion literals point to it. This is exactly what JAVA does and the table where they store all such string literals is called the String Pool

```String sampleOne = "Dylan";
String sampleTwo = "Dylan";
String sampleThree = new String("Dylan");

if(sampleOne == sampleTwo){
System.out.println("One and Two are same");
}

if(sampleOne == sampleThree){
System.out.println("One and Threeo are same");
}

```

In line 1, we create a String with value “Dylan”. In this process, Java automatically adds a reference of the String “Dylan” to the String Pool. In line 2, when we try to create another string, Java sees if this is already available in the String Pool and just points the literal to the value. But in line 3, we use the new operator to create a string. This is a bit off the mark, the new operator forces Java to ignore the String Pool and create a new instance. This’s the reason why line 6 is printed and line 10 is not… This very well explains why it’s not advisable to use a new operator while creating a String.

### intern() method

The docs tells us that the intern() method returns a canonical representation of the string. In other words, using the intern() method, we are forcing Java to check the String pool and return the value of the String. Let me modify the above example

```String sampleOne = "Dylan";
String sampleTwo = "Dylan";
String sampleThree = new String("Dylan").intern();
if(sampleOne == sampleTwo){
System.out.println("One and Two are same");
}
if(sampleOne == sampleThree){
System.out.println("One and Threeo are same");
}
```

Here, both line 6 and line 10 is printed.
Instead of creating a new instance in line 3, the intern() forces Java to return the String from String Pool.
Enough Said