Code One Zero: A One Day Hackathon Product
This post is about a shared experimental project we worked on together as a group during a hackathon at Tikal. The challenge was to have something of value in production by the end of the day, and it had to include at least two technologies out of a list. So here goes.
The Problem
Multiple teams in big companies write plenty of code and maintain a lot of projects, which often causes code duplications.
It is not uncommon, for example, that one team develops an email extraction function from text blobs, and another team develops the exact same feature, unaware that it is already long tested and deployed, and spends 3 more working days for no good reason.
The Plan
Our project is a SAAS that scans code repositories and with the extraction of metadata from the analysis of code and inline comments, it generates an index of the functionalities across the project into a database.
During the design process, the developer can use the search engine to find possibly existing functionalities for the task at and reuse instead of duplicate.
The tool uses AST (abstract-syntax-tree) to locate all classes, functions, class methods and inline comments. A special inline-comment tags “@coz” (code-one-zero) are treated as strong indexes.
Then, indexes it all in the database.
*We also investigated a bit about processing it through AutoML at the same time to gain some more insights. This hasn’t gone far yet, but we’ll get there.
The Use Case
Say the developer wants to write a function to extract an email from a text blob. They can then search via the UI and see what this search yields from the database:
In order for this to be helpful and save time and effort, this is how the users should annotate their code:
The Desired Tech Stack
Our star technologies from the mandatory list were originally Kotlin, LitElement, and PostgREST.
PostgREST, as described in its documentation, is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations. So as we realized we were able to leverage PostgREST to run the data API layer and have it do most of the magic, it appeared that we didn’t actually need Kotlin at all, and so it was out of the game.
The UI was built with LitElement, which is a base class for easy creation of web components compatible with any framework or web page. Since our UI is so minimalistic, there was no reason to bloat the app with a framework or a big UI library. Also, we wanted to play with web components, and to some of us, it was the first time doing so.
And so, by the end of the day, we had the POC working.
It’s So Simple!
All the developer has to do is search for the relevant tags and terms and see if a related code already exists.
Of course, they would also have to annotate their own code the same way for others in the organization. This way we can prevent duplications and extra work, and maintain a sort of living documentation, with almost zero effort.
Visit the repo:
Members of the Group
Stav Barak (me!)
Follow us guys, we’re awesome.
Thank you for reading. We would love to get feedback and suggestions.
