Question: What’s the result of having 16 enthusiastic people with a variety of skills in a meeting room for a whole weekend?
Answer: An amazing hackathon!
It was a Friday evening and it was cold outside. Some of the participants had already spent the whole week attending a workshop. Some participants were just arriving after a long journey. Fortunately, none of these affected attendance, so at 7:00pm we kicked off the second APNIC Hackathon!
The first APNIC Hackathon in Kathmandu a year ago had been a success, with great feedback from the participants and the jury — happy with the amazing exchanges they had over a weekend and all the learning they took back home — as the most precious souvenir. Therefore, we had to organize a second one!
With Facebook and APRICOT as sponsors, APNIC providing support and taking care of the logistics, 16 participants (12 males and 4 females from 11 different economies), and a great jury, this new edition of the APNIC Hackathon became a reality.
After a round of introductions, going through the agenda and a bit of important housekeeping, we had a few words on what a hackathon is and what the main goals are: a “hacking” marathon — a whole weekend working on a problem, not to produce a perfect solution but to produce a quick and dirty outcome that will provide the opportunity of learning from other participants and setting the direction for a possible future bigger project.
Defining the problem clearly and setting specific goals the team wants to achieve during the hackathon — making sure they are ambitious but achievable — is an interesting challenge. Especially when some teams are formed by people who met each other for the first time and needed to discover their roles and rhythms.
We then introduced the topic: ‘A DRUM’, which is a catchy name we came up with to shorten Addressing, Distribution, Routing and Usage Measurement. Basically, the idea is to measure how addressing resources are distributed, routed and used. To get people inspired, we presented a list of ideas of projects participants might want to work on. Many thanks go to Emile, Geoff and Romain for their great ideas!
After some discussion, we ended up with a list of six ideas people wanted to work on. Some ideas were from the list we shared, two were proposed by participants and one was proposed by my colleague, George Michaelson, who we had the honour to have as a member of the jury for this hackathon. But people were still shy and hesitant to commit to a project, so in an auction-style energetic activity, we got the participants saying what project they were interested to work on and we adjourned after having taken a picture of the whiteboard with projects and people to work on them:
On Saturday morning we gave the participants the opportunity to change project if, after having slept on it, they realized there was another project they wanted to work on, and some of them did.
And to get the blood moving and our brains activated we did a bit of a warm up.
After an intense weekend of team work and knowledge exchange, where:
- Two projects merged into one
- One of the teams found their way through their project despite each team member programming in a different language
- The members of the jury actively engaged with participants, providing help and guidance
We overcame the difficulty of communication.
After all this, as well as coffee breaks in the foyer and snacks and pizzas in the room, we wrapped up with presentations by the teams, who shared: the goals they had set and whether they achieved them or not; the challenges they experienced and how they overcame them; the outcomes they produced; and any conclusions and next steps they could think of.
I’m happy to declare the 2nd APNIC Hackathon successful! The participants learned a lot, not just technically but also about project definition, planning, teamwork and collaboration. On top of this, the APNIC Secretariat got some great ideas that could eventually become products. What else could we have wished for?
While the goal of the APNIC Hackathon is not about ranking but experience, the jury chose a ‘winner’ based on the following aspects:
- Code, coding style, approach
- Innovation
- Team work
- Usefulness
- Overcoming barriers
Winner: ‘Outage correlation’ group. It was a tough decision, but this team worked very hard to produce a live solution.
Here are the final presentation slides from each group.
Country ASN dependencies
Goal: To identify the most commonly used ASNs in a specific economy on a specific date. They did it for their own economies, Korea and Kiribati.
Main challenges: Programming language and skill level, but most importantly, communication! “Our English is not that good”.
Solutions: “I let him work and I fill out with ideas and we use Google Translate”.
Conclusion: They were able to identify critical ASNs for end users in an economy, which would affect them accessing the Internet if not available.
Source code repository: https://github.com/munhyunsu/APRICOT19
ILIA (Invalid Length Invalid AS)
ILIA was presented by WUKYNs (an acronym of all team members’ names), which included five team members with different backgrounds from four economies.
Goals: Identify invalid routes, find type of invalidity (both of them achieved).
Main challenges: Amount of data to process; 5 different programming languages.
Solution: “Work with a reduced data set, because code produced mixed different languages so it’s inefficient.”
Conclusion: “We have to refactor code!” “Programming is important, building human network is even more important”. “Many of life’s failures are people who did not realize how close they were to success when they gave up” (Thomas Edison).
Source code repository: https://github.com/wyvernflyin/ilia
ceROVe
This group defined clear roles based on skills.
Goal: Remove ROV feature from routers and implement separately as a network function the router consumes.
Main challenges: Getting data from APIs, Python coding challenges, virtual environment (low performance).
Solutions: Get help from GGM, do research and learn, patience!
Conclusion: Goal achieved! Simple program produced and showcased. With app it is easier to query many different trust anchors.
Source code repository: https://github.com/ariscahyadi/ceROVe
Outage Correlation
Goal: Understand relation between BGP outages; find anomalies that may have caused outages (either physical or logical).
Main challenges: Different programming languages, data manipulation, communication.
Solution: Learn and have patience.
Conclusion: They were able to graphically combine outage reports and group ASNs based on their regions. They were able to represent the BGP outages that occur to different ASNs at the same time. They concluded that BGP outages of different ASNs show their dependency with each other.
Source code repository: https://github.com/HyungJiny/outage_correlation_APRICOT2019
BGP Bogon Reporter
Two project ideas merged into one.
Goals: Find unused allocated IP addresses; report BGP bogons.
Main challenges: Unexpected results (fake IPs), NRO/RIR delegated data is inconsistent with standard prefix-length.
Solutions: “Divide and conquer”.
Conclusions: Report about unused space produced, report about bogons produced, learned about Python, learnt about the importance of teamwork.
Source code repository: https://github.com/msjang/antibogon
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.