Skip to content

Instantly share code, notes, and snippets.

@thundergolfer
Last active January 27, 2018 03:20
Show Gist options
  • Save thundergolfer/f7e4c5827a4fb55f94e53266537e3d59 to your computer and use it in GitHub Desktop.
Save thundergolfer/f7e4c5827a4fb55f94e53266537e3d59 to your computer and use it in GitHub Desktop.

Showing a bit of my code

It's quite hard to look across some code you've written, and pick something out to show; Like most programmers, I really only found in past my work, things to fix and change. Had to pick something though, so I'll show simplegraphdb, which I something I wrote relatively recently (mid November 2017) in preparation for being a Golang programmer at Atlassian.

It's quite small, and self-contained. I had been interested for quite a while in graph databases, as I like the kinds of questions a graph database allows you to ask efficiently about certain kinds of data. They are also not something explored really at university, the relation-model dominating my education thus far.

I approached this project as a thing that could serve as an my introduction to graph database thinking. I wanted to keep things nice, simple, and elegant and found the "Hexastore" indexing model to be exactly this. It can be implemented by building and linking maps, and shows itself to be a straightforward example of the space-time tradeoff in database design. You will find all the code for the "Hexastore" in the hexastore.go module.

Overall the "simplegraphdb" is quite demonstrative of how I like my code written and organised. A unit test suite and a continue integration solution are a must. Linting and code-style standardisation are also to me really valuable for code readability and smoothing code-collaboration (the Golang tooling makes this batteries-included). Code is commented where it should be, though my Zendesk mentors taught me not to rely on it, and documentation (here in the form of the README.md and function docstrings) is non-negotiable.

Some current weaknesses in the project I think stem from it being a bit of a 'toy graph database'. Heterogenous datatypes are currently not handled, and the package's query interface doesn't expose data in a useful format (eg. JSON, or a 'Results' struct type), it's just a string table. Still I've tried to give a new user a easy way to see what "simplegraphdb" can do, through the Twitter network example.

Thanks for reading, and absolutely feel free to leave feedback on the project in the comments. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment