Being a senior school pupil, finding love could be difficult. Likewise, finding individuals happy to invest their week-end teaming up beside me at a hackathon are hard as well.
An application that analyzes compatibility between Github users by using graph theory and the power of love at hackCooper 2016, I worked with Isabella Berry to solve these two problems with Github Dating Simulator. It is maybe maybe not just a dating simulator into the old-fashioned sense—rather, it is an internet application that enables individuals searching for hackathon groups to locate people who have comparable coding backgrounds in order to prevent the trouble of scrambling to get a group during the minute that is last.
Github Dating Simulator will come in two tastes. “Dating mode” enables a user to input two Github usernames to ascertain just just how suitable they truly are. “Team generation mode” (the greater mode that is practical enables a person to enter a list of Github usernames, will return the perfect pairings for every regarding the users. In addition permits them to create options that are several such as for instance exactly how many individuals should really be incorporated into each group.
For each match that Github Dating Simulator analyzes, it outputs a “compatibility” percentage, which can be fundamentally the program’s confidence level why these two different people should be able to come 
together well.
Simply for fun, it yields a summary of “first date ideas”, that are essentially arbitrarily created task some ideas in line with the typical languages provided between each user to simply help kickstart the ideation procedure. (as soon as it discovers really matches that are compatible it outputs a summary of “first date places”—a.k.a. upcoming hackathons.)
I became accountable for the UI design while the technical execution on this task. Probably one of the most projects that are statistically intensive labored on to date, Github Dating Simulator depends on a mixture of the Github API and graph algorithms to effortlessly and accurately set users.
Pairing Algorithm
To produce matchings, it appears during the language use of each individual and compares it on a level that is experience-based those for the other users. This means somebody who possesses great deal of repositories written in Ruby should be marked as an “expert” while an individual who has just only written 70 lines of Ruby should be marked being a “beginner”. This permits users become matched along with other programmers proportional with their level of skill, that allows programmers to utilize individuals of comparable coding backgrounds, making for a much simpler hackathon experience overall.
(this can be something which had been extremely contested, as you might want to match people with additional experiences with particular development languages with anyone who has less experience for a far more academic experience. Maybe an alternative for this kind of matching algorithm will be the next upgrade.)
My records and sketches when it comes to UI design.
For a graph, each individual is plotted off their users with various paths of varying “lengths”. Each individual is a node from the graph, and every course represents a typical language between two users. (If two users usually do not share any typical languages, they’ll not have paths among them.) Path length is determined because of the mean square distinction of every of the languages a person understands.
The algorithm attempts to discover the path that is shortest (essentially, comparable experiences with specific languages) between two users. After that it aggregates all the paths between two users into a single “compatibility” metric according to a logarithmic scale, after which starts producing matches beginning with the compatibility percentage that is highest. As soon as a individual happens to be matched with another individual, it’s going to delete both users through the graph so they really cannot again be matched. The algorithm continues until all users have already been matched or there aren’t any more available users to match.
API Use
One of many challenges that are major we went into ended up being that the Github API has price restricting, which stops one from making way too many API demands in an offered period of time. To resolve this nagging issue, we applied a pseudo-caching system by having a PostgreSQL database. Utilizing the Github API’s conditional demand function, we just make the full demand to Github that the data at each location has been changed if they tell us. Otherwise, we medepend count on formerly saved information that it hasn’t changed since we know.
Presenting Github Dating Simulator at the expo that is judging.
