My Experiences with Google Code In
For the last few weeks, I have been participating in a contest known as Google Code In, and it has been one of the best experiences of my life.
You may be asking, what is open source development? It's when software such as Blender, Apache, Firefox, Android, and LibreOffice make their source code public for anyone to see. By doing this, various members of the community can all improve the software and learn from it.
Google Code In, or GCI, has 25 participating organizations, each with their own projects and tasks. All of these organizations allow participants to claim tasks and submit changes to their code.
Google Code In is obviously not an easy thing to go through, but the rewards are worth it. Firstly, if a student does at least 1 task, they win a digital certificate. If they do at least 3 tasks, they win a Google T-shirt. After this, the prizes become exponentially more difficult. Each organization (25 total) chooses 5 finalists (125 total) from the top students in their organization. Each finalist wins a Google hoodie. Finally, each organization chooses 2 grand finalists (50 total) from the 5 finalists, and they each win a free trip to Google headquarters in California.
This work is licensed under a Creative Commons Attribution 4.0 International License.
What is Google Code In?
Google Code In is a global, online contest where students help complete tasks for various organizations. It is, obviously, run by Google. In this competition, participants are given the opportunity to complete tasks for global organizations and actually make changes that will be seen by thousands of people. Luckily, they are not alone with these tasks, as they have talented mentors who are all super helpful and want them to succeed. Google Code In is an incredible experience for students from ages 13-17, as it focuses on open source development in order to teach students about cooperation and how real-world software is made. To learn more information, go here: https://codein.withgoogle.com/.You may be asking, what is open source development? It's when software such as Blender, Apache, Firefox, Android, and LibreOffice make their source code public for anyone to see. By doing this, various members of the community can all improve the software and learn from it.
Google Code In, or GCI, has 25 participating organizations, each with their own projects and tasks. All of these organizations allow participants to claim tasks and submit changes to their code.
Google Code In is obviously not an easy thing to go through, but the rewards are worth it. Firstly, if a student does at least 1 task, they win a digital certificate. If they do at least 3 tasks, they win a Google T-shirt. After this, the prizes become exponentially more difficult. Each organization (25 total) chooses 5 finalists (125 total) from the top students in their organization. Each finalist wins a Google hoodie. Finally, each organization chooses 2 grand finalists (50 total) from the 5 finalists, and they each win a free trip to Google headquarters in California.
My Contest Timeline
I primarily heard about this incredible contest around 3 months ago, in October of 2017. In my Technology and Design class, my teacher gave a presentation about the contest in order to spread it around and get us to compete. I had heard a tiny bit from my parents about Google Code In, but it was mostly just in passing. This was the first time I had ever heard about the contest and its format. From the moment I heard about it, I was excited to do many things. For the past few years, I had done some recreational programming while making some projects, but I knew that I wanted to go do something. And now, GCI was giving me that chance.
Time passed, and before I knew it, it was November 28th. As I booted up the Google Code In website and dashed through the registration, I realized that even though this was my first time doing Google Code In, I still wanted to at least make some impact in the world. As I finished my registration and began browsing through the task list, I noticed that many of the tasks seemed incredibly daunting. As I skimmed through tasks, I found a simple one that interested me: "Install Ubuntu Linux on Virtual Box, as base for a Liquid Galaxy installation". I had always heard about different operating systems such as Ubuntu, and I was interested in seeing the process for myself. As a result, I began work on the task. In the task, there were incredibly clear directions that documented everything I needed to do. After setting up the virtual machine, I took a picture with a keyboard shortcut. Then, I ran into my first problem.
One of the purposes of a virtual machine is to set up a sort of a section of the file system so that other files are not affected as one does work in the virtual machine. However, the screenshot I had just taken was through the virtual machine. Therefore, I couldn't get the photo out of the partitioned file system and onto my normal computer's filesystem, where I could submit the task. In order to fix this problem, I did what any person would do: Google it. As I went through multiple articles, some of which were not the greatest guides, I found a way to solve my problem. I could set up a shared folder that both the virtual machine and operating system could access. As I managed to extract my image and submit it, I felt a flash of pride. Although what I had just done was simply a task to get me acquainted with the system, I still felt proud of myself, as I had gone through a problem and taken it down. I felt ready for whatever Google Code In had to throw at me.
Now that I had finished my first task, it was time to go back looking for another one. As I browsed through the tremendous list of tasks, I noticed something out of the corner of my eye: "node.js". Over the summer, I had spent a bit of time working with node.js, a platform for building network applications. However, it was largely just messing around, and I was interested in trying out this Google Code In task. I went through the task, uploaded my code, and watched my email, expecting it to be passed... A few hours later, I got a response. It was rejected, and I sadly dismally looked at the task for the reason why. However, after reading the comments, I lit up, as I realized that these were simple errors that I could easily rectify. As I quickly made changes, I realized the importance of open source software. Not only does it help many people work on the same project, it also helps people verify others' work and make sure that it is the best before it is submitted. Not long after I finished my changes, my task was accepted, and I was free to begin work on something else. You can see the light module I made here: https://github.com/Ryan10145/npm-hello-world. It doesn't do very much, sadly.
So far, I failed to mention before that Google Code In allows one to do 2 beginner tasks before doing the rest of the tasks. The beginner tasks are obviously much simpler than other tasks, and I had just done my share of them. Therefore, I was now forced to do harder tasks. But I invited this opportunity, as I knew that this was my chance to prove myself. I would finally be able to do something useful. As I began searching for a task again, I decided that it was time to begin focusing on one organization. As I looked through the list, I found a few that interested me, but one caught my eye, Wikimedia.
Now I'll admit, when I first saw that name, I thought, "Did they spell Wikipedia wrong?" However, after clicking on it interestingly, I learned that Wikimedia was actually the company that runs Wikipedia. As I read further, I learned more about Wikimedia. Most importantly, I learned about Wikimedia's goals: bringing free knowledge to all people. After reading this, I knew what I wanted to do. As a student who self-studies compassionately, I know how valuable sources like Wikipedia and other free resources are. They are integral to helping a person learn, as anyone can contribute and collaborate from across the world. While my first few tasks were not with Wikimedia, I knew what I was going to be working on from now on.
The coming weeks were, simply put, incredible. For the first time in my life, I felt like I was properly contributing my skills to society. The first task I took on during my experience with Wikimedia was to fix a bug a bug with Kiwix, an offline mobile viewer for wikis. Prior to my fix, the search bar would show the same entry multiple times, leading to a very unpleasant user experience.
The fix for this issue was not complicated, and it only took a few lines to fix.
Despite its simplicity, completing this task was one of the best things I had ever done. I felt like I had truly helped improve a large project by contributing this small amount, and that fact made me immensely proud.
After one of my first contributions, I began doing a bit of maintenance on various projects to help improve the readability and reliability of the code. While I didn't add any new features, I felt happy that my code was going into a real product and that I was actually utilizing my skills.
Up until this point, I had been alone for my entire Google Code In experience, working entirely through the Google Code In interface. However, this would not go on for much longer, as I would soon discover 3 great tools: IRC, Phabricator, and Gerrit.
First of all, there's IRC or Internet Relay Chat. It's essentially a giant chat room where people can discuss various topics. Wikimedia uses this heavily, and they have tons of different channels where people can talk about various things. https://www.mediawiki.org/wiki/MediaWiki_on_IRC is incredibly valuable, as it gives you links to all of the various IRC channels. I am mostly on #wikimedia-dev, where there are countless people ready to help and numerous bots that constantly post updates about Phabricator and Gerrit.
And that brings me to the second thing mentioned: Phabricator. Phabricator is a place where people can create, discuss, and solve new tasks. Additionally, people can assign tasks to each other and set priorities. Sometimes, I would spend hours just looking through old tasks and code, looking at the incredible work people have done over the years. Here, I also met some incredible people who helped me along my journey this year with Google Code In.
Finally, there's Gerrit, which is a place where people can submit patches of code to be merged with projects. However, while this "patch" is submitted, it can be code reviewed by many people. While anyone can do a code review, only a few people can give the coveted +2, which allows the patch to be finalized and added to the project. Gerrit also supports inline comments, automated builds, and many other cool features that really help developers.
Before Google Code In and Wikimedia, I had never heard of these tools before. However, now that I have been introduced to them, I can safely say that I will be using them for the rest of my life.
After this, I added a new feature to an HTML scraping library for PRISM tags. PRISM tags are a type of metadata that can be put on websites in order to display how to cite information. For instance, if you go to nature.com/articles/nature24679 and view the source code, you can see various PRISM tags on lines 190-210. Here is a picture in case the website change:
I was tasked with making a tool be able to read this data and then to write tests for this functionality to ensure that it would work. Those changes can be seen here: github.com/wikimedia/html-metadata/pull/66/files. Like the Kiwix bug fix, while this was not a large change, it made me proud, as I could call it my own personal contribution to a library hundreds of other people will use.
In the next task, I helped fix an issue with an extension where some of the text on a graph was not being properly localized into target languages.
During this task, I really felt like I was being pushed, as I had to look through various resources in order to find out how I could use the tools given to me properly in order to fix issues and provide the appropriate changes. I made many mistakes, and it actually took over almost 3 weeks for the patch to finally be submitted. Fortunately, I was able to continue to work on other tasks while a certain bug was being ironed out, and I'm glad that eventually, the bug was finally figured out. You can see the changes here: https://gerrit.wikimedia.org/r/#/c/398174/.
Afterward, I helped create unit tests for various classes, which meant that I was creating a way to verify that the code was producing the intended output. This helps improve the reliability of the code, as in the future, someone may change the code. Unit tests help make sure that the code still runs correctly after changes. Therefore, while some people may see them as pointless, especially if they only focus on features and bug fixes, they are still crucial to development. Therefore, I am glad that I had the chance with Google Code In to work on them.
The final contribution that I made up was helping to improve a script in Pywikibot, which is a library and a collection of various scripts that help automate tasks on wikis. I made various changes to a script that downloaded large dump files, including adding a progress bar to the download and making the download more safe in case of an error. Some of these changes can be seen at https://gerrit.wikimedia.org/r/#/c/400616/ and https://gerrit.wikimedia.org/r/#/c/401199/.
From Wikimedia, I found many unique and different tasks that I am sure anyone could find interest in. Additionally, I tried to not only work with Wikimedia through the Google Code In website, but also through other methods. I made sure to subscribe to their mailing list, and many of the emails I received were intriguing. I also took time to browse through Phabricator and look at some other tasks so that I could learn more. It took me a while to get into the flow of things and set up a good working environment due to my unfamiliarity with the system, but after a few weeks, I managed to become reasonably proficient at navigating the command line, Git, Gerrit, Phabricator, and IRC. If you want to learn more about Wikimedia in Google Code In this year, you can go here: https://www.mediawiki.org/wiki/Google_Code-in/2017.
All of the tasks I did were challenging, and it took me a lot of time and effort to complete them. Overall, I did 24 tasks, and I'm proud of my work. However, I didn't complete these tasks alone. I would like to thank every single one of the mentors who helped me during Google Code In, including, but not limited to, legoktm, framawiki, Nikerabbit, d3r1ck, jayvdb, Xqt, zhuyifei1999, tonythomas, Umherirrender, Addshore, bawolff, and mhutti1. Additionally, I would like to thank some of my peers during Google Code In: eflyjason, rafidaslam, Albert221, Phantom42, and divadsn. While we may not have talked that much, I look up to every one of you for the work you have done for Wikimedia. If I forgot any names on any of the lists, I profusely apologize.
Once again, thank you to everyone for the past few weeks; they have been a blast. I learned many things: the value of code reviews, how misguided one can be on his/her first attempt, how one should especially never give up, and most importantly, how crucial sleep is. I couldn't have gotten through this without everyone's help. Finally, I would like to thank you, the reader, for sticking with me through this blog post. I can't wait for the next Google Code In, and I hope to see you there too!
One of the purposes of a virtual machine is to set up a sort of a section of the file system so that other files are not affected as one does work in the virtual machine. However, the screenshot I had just taken was through the virtual machine. Therefore, I couldn't get the photo out of the partitioned file system and onto my normal computer's filesystem, where I could submit the task. In order to fix this problem, I did what any person would do: Google it. As I went through multiple articles, some of which were not the greatest guides, I found a way to solve my problem. I could set up a shared folder that both the virtual machine and operating system could access. As I managed to extract my image and submit it, I felt a flash of pride. Although what I had just done was simply a task to get me acquainted with the system, I still felt proud of myself, as I had gone through a problem and taken it down. I felt ready for whatever Google Code In had to throw at me.
 |
| The picture for my first task |
Now that I had finished my first task, it was time to go back looking for another one. As I browsed through the tremendous list of tasks, I noticed something out of the corner of my eye: "node.js". Over the summer, I had spent a bit of time working with node.js, a platform for building network applications. However, it was largely just messing around, and I was interested in trying out this Google Code In task. I went through the task, uploaded my code, and watched my email, expecting it to be passed... A few hours later, I got a response. It was rejected, and I sadly dismally looked at the task for the reason why. However, after reading the comments, I lit up, as I realized that these were simple errors that I could easily rectify. As I quickly made changes, I realized the importance of open source software. Not only does it help many people work on the same project, it also helps people verify others' work and make sure that it is the best before it is submitted. Not long after I finished my changes, my task was accepted, and I was free to begin work on something else. You can see the light module I made here: https://github.com/Ryan10145/npm-hello-world. It doesn't do very much, sadly.
So far, I failed to mention before that Google Code In allows one to do 2 beginner tasks before doing the rest of the tasks. The beginner tasks are obviously much simpler than other tasks, and I had just done my share of them. Therefore, I was now forced to do harder tasks. But I invited this opportunity, as I knew that this was my chance to prove myself. I would finally be able to do something useful. As I began searching for a task again, I decided that it was time to begin focusing on one organization. As I looked through the list, I found a few that interested me, but one caught my eye, Wikimedia.
Now I'll admit, when I first saw that name, I thought, "Did they spell Wikipedia wrong?" However, after clicking on it interestingly, I learned that Wikimedia was actually the company that runs Wikipedia. As I read further, I learned more about Wikimedia. Most importantly, I learned about Wikimedia's goals: bringing free knowledge to all people. After reading this, I knew what I wanted to do. As a student who self-studies compassionately, I know how valuable sources like Wikipedia and other free resources are. They are integral to helping a person learn, as anyone can contribute and collaborate from across the world. While my first few tasks were not with Wikimedia, I knew what I was going to be working on from now on.
The coming weeks were, simply put, incredible. For the first time in my life, I felt like I was properly contributing my skills to society. The first task I took on during my experience with Wikimedia was to fix a bug a bug with Kiwix, an offline mobile viewer for wikis. Prior to my fix, the search bar would show the same entry multiple times, leading to a very unpleasant user experience.
 |
| That doesn't seem right... |
After one of my first contributions, I began doing a bit of maintenance on various projects to help improve the readability and reliability of the code. While I didn't add any new features, I felt happy that my code was going into a real product and that I was actually utilizing my skills.
Up until this point, I had been alone for my entire Google Code In experience, working entirely through the Google Code In interface. However, this would not go on for much longer, as I would soon discover 3 great tools: IRC, Phabricator, and Gerrit.
First of all, there's IRC or Internet Relay Chat. It's essentially a giant chat room where people can discuss various topics. Wikimedia uses this heavily, and they have tons of different channels where people can talk about various things. https://www.mediawiki.org/wiki/MediaWiki_on_IRC is incredibly valuable, as it gives you links to all of the various IRC channels. I am mostly on #wikimedia-dev, where there are countless people ready to help and numerous bots that constantly post updates about Phabricator and Gerrit.
 |
| Interface of IRC |
And that brings me to the second thing mentioned: Phabricator. Phabricator is a place where people can create, discuss, and solve new tasks. Additionally, people can assign tasks to each other and set priorities. Sometimes, I would spend hours just looking through old tasks and code, looking at the incredible work people have done over the years. Here, I also met some incredible people who helped me along my journey this year with Google Code In.
 |
| One of many Phabricator Tasks |
Finally, there's Gerrit, which is a place where people can submit patches of code to be merged with projects. However, while this "patch" is submitted, it can be code reviewed by many people. While anyone can do a code review, only a few people can give the coveted +2, which allows the patch to be finalized and added to the project. Gerrit also supports inline comments, automated builds, and many other cool features that really help developers.
 |
| One of many Gerrit Patches |
Before Google Code In and Wikimedia, I had never heard of these tools before. However, now that I have been introduced to them, I can safely say that I will be using them for the rest of my life.
After this, I added a new feature to an HTML scraping library for PRISM tags. PRISM tags are a type of metadata that can be put on websites in order to display how to cite information. For instance, if you go to nature.com/articles/nature24679 and view the source code, you can see various PRISM tags on lines 190-210. Here is a picture in case the website change:
 |
| Sample PRISM tags |
I was tasked with making a tool be able to read this data and then to write tests for this functionality to ensure that it would work. Those changes can be seen here: github.com/wikimedia/html-metadata/pull/66/files. Like the Kiwix bug fix, while this was not a large change, it made me proud, as I could call it my own personal contribution to a library hundreds of other people will use.
In the next task, I helped fix an issue with an extension where some of the text on a graph was not being properly localized into target languages.
 |
| Numbers on the tooltip and the axes are not properly localized |
Afterward, I helped create unit tests for various classes, which meant that I was creating a way to verify that the code was producing the intended output. This helps improve the reliability of the code, as in the future, someone may change the code. Unit tests help make sure that the code still runs correctly after changes. Therefore, while some people may see them as pointless, especially if they only focus on features and bug fixes, they are still crucial to development. Therefore, I am glad that I had the chance with Google Code In to work on them.
The final contribution that I made up was helping to improve a script in Pywikibot, which is a library and a collection of various scripts that help automate tasks on wikis. I made various changes to a script that downloaded large dump files, including adding a progress bar to the download and making the download more safe in case of an error. Some of these changes can be seen at https://gerrit.wikimedia.org/r/#/c/400616/ and https://gerrit.wikimedia.org/r/#/c/401199/.
 |
| We're making progress! |
Reflections
Both Google Code In and Wikimedia have taught me so much. Before the contest began, I was focused on making small applications and games with languages like C++ and Java. I had very basic knowledge of Python and JavaScript, while none of PHP. However, I was determined to still make a difference and help Wikimedia. While it initially did not suit my skills and it was a struggle, I was dedicated to helping out Wikimedia.From Wikimedia, I found many unique and different tasks that I am sure anyone could find interest in. Additionally, I tried to not only work with Wikimedia through the Google Code In website, but also through other methods. I made sure to subscribe to their mailing list, and many of the emails I received were intriguing. I also took time to browse through Phabricator and look at some other tasks so that I could learn more. It took me a while to get into the flow of things and set up a good working environment due to my unfamiliarity with the system, but after a few weeks, I managed to become reasonably proficient at navigating the command line, Git, Gerrit, Phabricator, and IRC. If you want to learn more about Wikimedia in Google Code In this year, you can go here: https://www.mediawiki.org/wiki/Google_Code-in/2017.
All of the tasks I did were challenging, and it took me a lot of time and effort to complete them. Overall, I did 24 tasks, and I'm proud of my work. However, I didn't complete these tasks alone. I would like to thank every single one of the mentors who helped me during Google Code In, including, but not limited to, legoktm, framawiki, Nikerabbit, d3r1ck, jayvdb, Xqt, zhuyifei1999, tonythomas, Umherirrender, Addshore, bawolff, and mhutti1. Additionally, I would like to thank some of my peers during Google Code In: eflyjason, rafidaslam, Albert221, Phantom42, and divadsn. While we may not have talked that much, I look up to every one of you for the work you have done for Wikimedia. If I forgot any names on any of the lists, I profusely apologize.
Once again, thank you to everyone for the past few weeks; they have been a blast. I learned many things: the value of code reviews, how misguided one can be on his/her first attempt, how one should especially never give up, and most importantly, how crucial sleep is. I couldn't have gotten through this without everyone's help. Finally, I would like to thank you, the reader, for sticking with me through this blog post. I can't wait for the next Google Code In, and I hope to see you there too!
-Ryan Chang
This work is licensed under a Creative Commons Attribution 4.0 International License.
Comments
Post a Comment