Student Application - Keon Woo Kim
Name ?KeonWoo Kim
- University: New York University, B.S in Computer Science
- Date study was started: August 2012
- Expected Graduation Date: May 2018 ( I took two and a half years of leave to serve alternative military, which I also worked as a programmer)
Programming Languages (in a scale of 1-5):
- Python: 4
- C++: 3
- Java: 3
- I also do a little bit of shell script and I am eager to learn more languages like Perl to achieve tasks of this project.
I started coding using Linux since elementary school but only used Debian Linux as a supporting tool for operating my web or embedded projects. However, I am very passionate at learning new things to successfully complete this project. I read master's thesis Solving the Bootstrap Problem for Free and Open Source Binary Distributions(https://mister-muffin.de/bootstrap/thesis.pdf) to improve my understandings for this project.
Open Source Contributions:
I am a very strong advocate for free and open-source software. Though it is not a programming project, I maintain an awesome list of natural language processing articles and lectures in my Awesome-NLP project (https://github.com/keonkim/awesome-nlp). Moreover, I just started writing an open-source book called “Pythonic Data Structures and Algorithms” (https://github.com/Pythonic-Studies/Pythonics-Data-Structures-and-Algorithms) in Korean language because I found there are not many books that show “pythonic” implementations of algorithms, python being really minor language in Korea. I also made minor contributions (mostly documentation or bug fixes) to Node.js full stack web framework called “UPPERCASE” and machine learning framework called “Torch7” and made bug patches to “React-Rocket-Boilerplate”. I also make non-computer science contributions to other open source projects. For example, I am participating Firefox Ambassador Program lead by Mozilla foundation. Not only I aim to contribute to these projects by programming, but I also promote them by giving technical presentations to the public.
Collaborative Working Experience:
As I mentioned above, I took two years of leave from school to experience the professional working environment. My past working experiences generally consist of startups with services ranging from embedded systems, cloud platform and machine learning. I am currently participating in an internship program offered by a machine learning startup called solidware (http://solidware.io), which focuses on applying advanced algorithms to improve financial service. Because of this environment, I was able to become familiar with the process in data science. The internship is going to end in few weeks before Google Summer of Code program starts. When I think of the projects I have worked on at my school or at work. One of the hardest things that I learned to deal with is working with other people in a shared codebase. Reading other people’s code, managing the changes that they make, having them deal with changes I make, and having them read and understand my code, has actually made me a better programmer. It resulted me writing a cleaner, more efficient, more understandable and better code.
Links to my works:
Unfortunately, my recent works I made in the current company are hidden from public because they are proprietary property. However, I store most of my personal projects in my ?GitHub account (https://github.com/keonkim). I also love to put myself in a challenging situation, so I experienced several hackathons. The projects I’ve done in the past hackathons are listed in here (http://devpost.com/keonkim).
What makes me the best person to work on this project?
- I believe my enthusiasm for free and opensource contribution and willingness to learn qualifies me for the project. What I want people to see is not what I learned or did in the past, but the attitude of how I took the challenges of studying unfamiliar fields and how quickly I analyzed, understood and managed to produce a successful outcome at the end.
Interests and Hobbies:
- I like to study different fields of computer science in my spare time. For example, my day job consists of mostly web server development, therefore I am doing a project related to other parts of computer science such as hacking. Additionally, I recently have begun to write a book called “Pythonic Data Structures and Algorithms”.
* Project title: Cross Bootstrap
Synopsis: Retrieved from the Debian wiki page of GSoC projects page:
- Automatically bootstrapping new and existing Debian architectures still is a difficult task with many challenging subproblems. Quite a few of them are suitable to be solved by a mentored student. Out of 22000 source packages in Debian, only 5000 have satisfiable cross Build-Depends. Figuring out which packages need changes to fix satisfiability issues is non-trivial from the currently available diagnostics. Improving the presentation of these issues using (to be developed) heuristics and integration into tracker.d.o would be a significant step towards solving them. Instead of work on metadata, working on the practical issues with cross building can be an alternative focus of a suitably skilled applicant. The overall goal of this project is to make cross building just work. This project is the continuation of several successful GSoC projects during the past years (see Related projects)
Project Details: I consulted with the hosts of this project and selected one of the options they offered.
I wish to work on turning the problems that prevent cross compilation on the dependency level (http://bootstrap.debian.net/cross_all.html) into something maintainers can understand by employing heuristics. For example, fixing many packages by informing maintainers what to do. Many of the satisfiability problems are similar in nature and simply involve many similar fixes over a wide range of packages, but Debian operates in a way that makes applying simple fixes to many packages difficult.
- Therefore the idea is to find common patterns in the diagnostics of dose-builddebcheck (diagnostics like deciding which package is at fault) and nicely present those diagnostics. For instance, if a python module turns out to have no installation candidate, chances are that a ":native" annotation is missing. So this very simple heuristic basically says "if there are a direct build-depends on python-something and python something is an arch:any packages, then annotate with :native". My task will be to find more and better of those rules and use them to turn the difficult dose-builddebcheck diagnostics into something actionable from a maintainer's point of view.
- The ultimate goal, therefore, is to build a console application which can automate the process explained above. Even though the algorithmic solutions to this are very not likely to scale, I wish to make a tool that at least fastens the process.
- In addition to the console application, I am going to make an integration into tracker.debian.org.
Benefits to Debian:
- Fasten the process of and solving the cross build problems in packages.
- Assist to Debian properly self-hosting
- Assist in the goal of bootstrap project, making Debian a true Universal OS more approachable.
- Automate the system of simple, but unscalable tasks.
- Bug reports with simple heuristics for the dependency satisfiability problems.
- Patches for those cross build problems in h ttp://bootstrap.debian.net/cross_all.html
- A console application that automates the tasks above by studying the reporting process using cross_all.yaml file as a data source.
- Inegration with tracker.debian.org.
Phase 1: Getting Ready to Start Project
- Now ~ April 23 - familiarize myself with the concepts and tools (Debian, Distro Tracker, Bootstraping Debian). Refine the project plan.
April 23 - Student Projects Announced
April 22 ~ May 22 - Community Bonding
- April 22 ~ May 23 - Detailed planning and studying for the project.
Phase 2: First Half of GSoC
May 23 ~ June 28 - Students Work on Their Projects
- (Week 1) May 23 ~ 30 - Try solving problems in both "Missing" and "Conflict" problems.
- (Week 2 ~ 5) June 1 ~ June 24 - Report to the maintainers and if possible, patch the bugs. Start planning to build the automated system.
Jun 21 ~ 28 - Midterm Evaluations
Phase 3: Second Half of GSoC
Jun 28 ~ August 16 - Students Continue Coding
- (Week 6 ~ 10) June 27 ~ July 29 - While still reporting and patching build the program that automates this process. Recap study of Distro tracker and tracker.debian.org.
- (Week 11) Aug 1 ~ Aug 5 - Build thorough tests for the program and integrate with tracker.debian.org.
Phase 4: Finalizing Work & Continued Contribution
- (Week 12) Aug 8 ~ Aug 12 - Patch bugs, refine documentations, and promote the works to developer community
August 16 ~ 24 - Students Submit their Code and Evaluations
August 24 ~ 30 - Mentors Submit Final Evaluations
August 31 - Results Announced
- September 1 ~ Future - My goal is to continue contribution to debian community as a maintainer.
Exams and other commitments: I do not have exams during the GSoC.
Other summer plans: I do not have anything planned except for GSoC. You have my full commitment.
Why Debian?: I have used Debian and Debian based operating system for many years now and I was always impressed by the easy-to-use deployment and dependency management system. I would be honored to take part in one of those efforts.
My previous Debian contributions: I have not made Debian contributions other than recommending my friend to install Debian for his first Linux at college.
Are you applying for other projects in SoC? I am planning to apply for Lua disassembler and assembler project by ?LabLua and dataset and experimentation tools by mlpack. I will update if I make firm decision.