Neo4j 2.0 - Setup and first impressions

During the Christmas Holidays I took some time to play around with Neo4J. This is not the first time I tinker with it but definitely the first time I do it unsupervised. I must say the first time I played around with Neo4J it was under @albertoperdomo 's guidance and it felt like a liberation after several years of RDBMS.

DISCLAIMER: I'm a total newbie at Neo4j so don't take my advice for anything I'll be writing, this post is more of a compendium of notes for myself to check in the future.

INSTALLING

Installing any version (I needed 2.0.0) of Neo4J is insultingly simple thanks to @thedevel script: ndm. I even tweeted about it (again, for my own reference). Let me point out that even manually, isntalling neo4j is really simple.

IMPORTING MOVIE DATABASE

During Alberto's workshop intro to Neo4J we had a lot of small quizes so that each would have to keep on investigating and putting small concepts into practice. My idea to start playing around with Neo4J was to load that clean movie database, refresh some concepts from the notes I took during the workshop and then try to move on from that point.

First issue I faced with new features in Neo4J 2.0.0 were small syntax changes causing the load of a 1.9.3 database to fail. It's ended up being something quite silly though. What used to be:

     START n=node(*) MATCH (n)-[r?]-() DELETE r,n;

now turned into:

     START n=node(*) 
     MATCH (n)--() 
     OPTIONAL MATCH ()-[r]-() 
     DELETE r,n

There seems to be 2 differences:

• the trailing semicolon seems to be unnecessary now. It was causing a parsing error when reading the following line which caused the error message to be miss-leading since it pointed me in the wrong direction. I finally noticed the error message made no sense and tried to remove the semi-colon. It worked.
• Second thing is the replacement of '?' char to mark 'r' relationship optional in the query. Optional matcher's syntax seems to be new (or restricted to): OPTIONAL MATCH. I then replaced the edge from the query MATCHer and created an OPTIONAL MATCHer for it. It worked but I really doubt the two queries (old 1.9.x vs new 2.0.x) do the exact same thing. What I intended was to delete everything and that's what happens, but that's not enough proof to be satisfied with the rewrite.

(I'm not sure I can freely distribute the movies.cyp database) :-(

FIRST IMPRESSIONS

1. The web console has improved incredibly. It was a great tool already but it is now beyond awesome. You can judge yourself:
1. not only the tabular data presentation provides a clearer view of the schemaless data,





2. you can now peek at the results in graph view

I'm only scratching the surface of Graph DB concept at the moment. I hope I can get my hands dirty in the upcoming days...

Parallel collection manipulation in scala

Scala collections API comes packed with a very cool feature which is parallelizing any processing. See this example:

I first create a list (I could use a range or s/thing else too):

scala> List(1,2,3,4,5,6,7,8,9)
res0: List[Int] = List(1, 2, 3, 4, 5, 6, 7, 8, 9)

... and then build the skeleton of my processing. What I want to to multiply each value by 1000 and then divide each value by 500:

scala> res0.map{ 
    i => i*1000
  }.map{
    i => i/500
  } 
res1: List[Int] = List(2, 4, 6, 8, 10, 12, 14, 16, 18)

Nothing fancy so far.

Entering par

In scala every collection can be automagically wrapped into a counterpart that implements processing with a thread pool. I actually have no clue what the implementation is. Damn! I'll have to look it up. Anyway, insert 'par.' on your code and...

scala> res0.par.map{ 
    i => i*1000
  }.par.map{
    i => i/500
  }
res2: scala.collection.parallel.immutable.ParSeq[Int] = ParVector(2, 4, 6, 8, 10, 12, 14, 16, 18)


... the list becomes a ParVector and keeps all items sorted in the original position.
Let's try and see it in action: (added random sleep to 'help' context switching)

scala> import java.util.concurrent.TimeUnitimport java.util.concurrent.TimeUnit

scala> import java.util.Random
import java.util.Random

scala> new Random

res6: java.util.Random = java.util.Random@b9d964d

scala> res0.par.map { 
    i => TimeUnit.MILLISECONDS.sleep(res6.nextInt(1000));
    println(i);
    i*1000
  }.par.map{
    i => TimeUnit.MILLISECONDS.sleep(res6.nextInt(1000));
    println(i); 
    i/500
  } 
3
7
4
5
8
2
1
9
6
7000
3000
5000
4000
1000
6000
8000
9000
2000
res13: scala.collection.parallel.immutable.ParSeq[Int] = ParVector(2, 4, 6, 8, 10, 12, 14, 16, 18)

scala> 

Ta dah! Execution is run in parallel.

See more information re Parallel Collections on the overviews of the Scala Docs.

PS: For the curious...

If I get rid of the first 'par', the first processing is sequential, and the delays add up.

scala> res0.map { i => TimeUnit.MILLISECONDS.sleep( res6.nextInt(1000)  );println(i) ;i*1000}.par . map { i => TimeUnit.MILLISECONDS.sleep(  res6.nextInt(1000)  ); println(i); i/500 } 

1

2

3

4

5

6

7

8

9

5000

2000

1000

6000

3000

4000

9000

7000

8000

res17: scala.collection.parallel.immutable.ParSeq[Int] = ParVector(2, 4, 6, 8, 10, 12, 14, 16, 18)

SBT and ScalaTest and a strange exception

After few weeks developing in Play! at some point today I started getting an Exception out of nowhere.

[info] 
Exception in thread "Thread-109" java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2577)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at sbt.React.react(ForkTests.scala:98)
at sbt.ForkTests$$anonfun$apply$2$Acceptor$2$.run(ForkTests.scala:66)
at java.lang.Thread.run(Thread.java:722)
[info] Passed: : Total 23, Failed 0, Errors 0, Passed 23, Skipped 0

Strangely enough it would be thrown on every test execution but all tests pass (see last line). 

Turns out it's a known (and already fixed) issue in sbt 0.12.2 so that was only a matter of updating:

   # sed -e 's/0.12.2/0.12.3/g' project/build.properties

Word Wrap #katayuno

I finally got the chance to attend a Softonic's Katayuno.

I love the Coding Dojo's in general, but those organised at Softonic are special because of their office decoration (out of the average) and because they're breakfast.

Once I got at Softonic I must say the ambient, even with an empty office, felt different from many other  companies I had visited before. The place is clean, ample and colorful you also have to consider the fact that's we were at story 9 which is over the average building height in Barcelona so the view was also quite stunning. Yes, you can see the sea from the dinner. And yes, there's a dinner.

Back to work

We got to work and after fiunchinho's introduction to TDD and red-green-refactor warmed-up on a first 30 minute pomodoro. The problem at hand was the KataWordWrap which fiunchinho selected specially for it's simplicity. It's not that he thinks we are stupid (which we are) it's that eh wanted us to complete the kata for once. SPOILER some of the pairs did complete the kata so fiunchinho just got a badge unlocked!

I paired twice in Java and after the break I paired once in scala. I'm still not very fluent in scala but I'm happy to report that we completed the kata in scala in little over a pomodoro (and I think we got further than previous pomodoros too!). Here's the final code:

This last session I paired with dvillacampa that is completely new to scala. I must say he very patiently listened to all my funoby comments about the language.

Simple Build Tool

Today I finally jumped into using sbt.

I found how to get it and how to setup my machine at it's GitHub documentation (https://github.com/harrah/xsbt/wiki/Getting-Started-Setup), and now trying to make it work with my current code (https://bitbucket.org/ignasi35/scala-eclipse).

The main reason why I chose to test sbt is the continous testing:

• you can have sbt continually running (actually waiting for you to change something) and it will notice when something changed and compile and run it's tests. Actually, that's just a case of the actual feature: continous so you are not limited to continous testing.

So far I'm struggling to make it work with my existing FunSpecs.

Reactor Pattern

It's been long since I last wrote in english (probably never) but I found today was a good day to take this nack (start anew).

I read lately a lot about programming languages. Being a 100% JAVA (lazy) guy I never found the right moment to start. Finally via Coding Dojo's at Run Room with the people from Agile Spain I lost fear and made the first step.

I'm currently focused on Scala. I chose an OOP+Functional to start with and discovered it's scripting too !?!?. I made that choice after I had my attempts the past with python (scripting) and found that learning paradigm and API all at once was too much for me. Having JAVA's API in Scala world is really helping.

But let's get back to the subject of the post.

Something I've been paying some attention involuntary is the reactor pattern. I read from it today at aitorciki's post on concurrency inabout python and there I learnt that it's what Node.Js is actually doing. That struck me. I had read about Twisted and also had seen Node.Js code but failed to see the pattern there. I'll now get to the theory and will start digging.

Cassandra

Fa unes setmanes que estic llegint Cassandra: The Definitive Guide [Kindle Edition]. A veure quan trobo l'excusa, el temps i els recursos per a posar en pràctica el que hi estic aprenent.

NOTA: Allí hi he descobert els Bloom Filters i he recuperat l'interès per les estructures de dades.