MYOB Neo4J Coding Competition
Guest Author: Aidan Casey, Solutions architect, MYOB Australia
Last week marked the end of the MYOBNeo4J 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!
