Related MicroZone Resources
Like this piece? Share it with your friends:
Guest Author: Aidan Casey, Solutions architect,
MYOB Australia
Last week marked the end of the
MYOB
Neo4J coding competition. This was an internal competition for the
development team in the Accountants Division of MYOB, to develop a
customer relationship system for accountants using node.js and
Neo4J. MYOB is one of the largest ISV in Australia and the team in
the Accountants Division are focused on developing line of business
applications for accounting practices.
A coding competition with a
difference!
I wanted to have a level playing field
for the competition so what better to throw at a bunch of Microsoft
developers than a Neo4J, Node.js and Heroku challenge!
The competition ran for 8 weeks and the challenge was to build an
online CRM system that ingested a bunch of text files that
represented data from a typical accounting practice. The business
domain was very familiar to the team but the technologies were all
new.
To add another twist, points were
awarded to the people within the team that made the biggest community
contributions over the 8 weeks (MYOB ‘brown bag’ webinar
sessions, yammer discussion threads and gists on GitHub). I wanted
this to be a very open open-source competition!
Why Neo4J?
When you dig deeper and analyse the
data that an accounting practice uses it’s all based around
relationships – an accounting practice has employees,
employees manage a bunch of clients, and these clients are
often related (husband and wife, family trust etc). The competition
gave the team a chance to dip their toes into the world graph
databases and to see how naturally we could work with the data
structures.
And the winner is... Safwan Kamarrudin!
I’m pleased to announce that Safwan
Kamarrudin is the winner and proud owner of a new iPad! Safwan’s
solution entitled “Smörgåsbord” pulled together some really
cool node.js modules including the awesome node-neo4j, socket.io and
async. Safwan made a massive contribution to the competition
community through the use of yammer posts, publishing GitHub Gists
and by running brownbag sessions here in the office.
Accountants Division program manager
Graham Edmeads presenting Safwan with his prize!
An interview with the winner!
Qn – So where did you come up with
the name “Smörgåsbord”, are you a big fan of cold meat and
smelly cheese?
I chose the name because the
competition asked contestants to use a smorgasbord of technologies.
Plus, I thought it would be cool to have umlauts in the name.
Qn – Where can we find your
solution on GitHub?
Qn – Complete this sentence –
Neo4J is completely awesome because …
Data is becoming more
inter-connected and social nowadays. While “relational” databases
can be used to build such systems, they are definitely not the right
tool for the job due to their one-size-fits-all nature (despite the
name, relational databases are anything but relational). Modelling
inter-connected data requires a database that is by nature relational
and schema-free, not to mention scalable! And in the land of graph
databases, in my opinion there is no database technology that even
comes close to Neo4J in terms of its features, community and
development model.
Qn – What in your opinion is the
biggest challenge to wrapping your head around Graph database
concepts?
For someone who is more used to
relational databases, the differences between nodes and tables need
some getting used to. In a graph database, all nodes are essentially
different and independent of each other. They just happen to belong
to some indices or are related to other nodes.
This also relates to the fact that
nodes of a similar type may not have a fixed schema, which can be
good or bad depending on how you look at it.
Another subject that I had to
grapple with was whether it makes sense to denormalize data in Neo4J.
In a NoSQL database, normalization has no meaning per se. In some
cases, data normalization even negates the benefits of NoSQL.
Specifically, many NoSQL databases don't have the concept of joins,
so normalizing data entails having to make multiple round trips to
the database from the application tier or resorting to some sort of
map-reduce routine, which is inefficient and over engineered.
Moreover, normalization assumes that there's a common schema shared
between different types of entities, and having a fixed schema is
antithetical to NoSQL.
Finally a word of thanks!
I’d like to say a huge thanks to Jim
Webber, Chief Scientist at Neo Technologies for helping me launch the
coding competition. Jim was struck down with chicken pox just hours
before the competition was launched but he still managed to join me
online to launch it and take the team through the infamous Dr Who use
case. You are a legend Jim, many thanks!
