The language I chose to use in my github repo was GO. Go was an interesting language to briefly learn and had some interesting syntax. Nothing about it was out of the ordinary and I would use it again if I saw the need for it. I chose this language just as a way to get exposure to something I have not used before.
To help with creating one of the functions in my issue tracker I simply looked at GO’s documentation and followed the steps they took. This lead to no licensing issues but there were some technical issues dealing with file paths and building the project while keeping in mind that other users would be working on this code base. I had to make sure to reference the current project directory when hashing a file and made sure to use a file everyone working on this would have access to (the license file).
Contributing to another project was a rewarding experience. I chose a python project as I had experience with python in the past and was looking more into figuring out how to do a pull request then to learn a new language. It was easy enough to make changes to my forked repo and then submit a pull request.
Having users contribute to my project was something I have done before but in the past everyone was a contributor of the repo. The way we did it now was through issues and pull requests. It was fun to help people with issues on the project by communicating through the issue tracker, assigning the issues and reviewing their code in the pull request.
The most important thing I learned as a contributor to another persons repo was to make sure I did my best to not introduce my own coding style to the project but to conform to the style and standards of the project. As a maintainer I learned that it is important to clearly state your style and standards and to include instructions on how to build and run the project to ensure everyone gets similar results.
In using git I ran into issues connecting the pull request to the issue I was solving and learning how to assign people to issues. All of these problems were fixed with experience and research.
Finding a suitable bug can be a daunting task. Searching github or bugzilla for a new bug that hasn’t been assigned can take some time and a lot of the time that bug might be too difficult for a first bug. Luckily many open source communities leave minor bugs open to help people who are interested in contributing open. These bugs are usually tagged with good first bug and give contributors the chance to learn how to install the environment and get familiar with the review process.
I fixed two bugs that dealt with fire fox. The first bug I found was a mentored bug on the fire fox developer tools. The bug was to change a function call dealing with nodes in the inspector. I needed to change the call to an existing function as well as change the string on the menu to reflect the change. When I first started this bug all the instructions were laid out on how to go about fixing this bug. Naively I thought some of the instructions were unnecessary and went ahead and fixed the bug how I thought it should be fixed. It turns out a massive project like fire fox that is written in many languages has a system in place to make sure when a string is changed in one language, devs who work on fire fox in other languages can be notified of these changes. I submitted my patch using bugzilla and mercurial and was promptly informed that I neglected to follow the steps and would have to edit my patch to propagate the change to devs working in other languages. Luckily the mentor was very helpful and I got more experience in mercurial with changing commits. The process of fixing this bug and the exchanges with the mentor over bugzilla took around three days. Once the commit fixed all of the issues detailed in the bug report the mentor submitted my patch for testing on Mozilla test servers. They provide a link so you can watch the status of your bug as it is being tested. My patch passed all testing and the mentor informed me he would tag the bug for landing and said a code sheriff would eventually come by and push/merge the commit for me. The bug and all the interactions can be found here:
The second bug I fixed was very straightforward. The bug was to remove four lines of obsolete code in the fire fox project. Since I was experienced with mercurial and how to upload patches to bugzilla the bulk of the work on this bug was taken up by updating my fire fox project with the latest commits and rebuilding my project. One thing I noticed was my commit was still in my ‘hg outgoing’ from my last fix. I was nervous that if I used the command ‘bzexport’ to push my second bugs commit to bugzilla it would push my old one. To avoid this I deleted my first commit, I suspect there is a abetter way around this but since I did not push the code my self I was unsure. Perhaps in the future working in a separate branch per bug would get around this issue. The bug this time was simple and did not require testing. I did not have to change my commit as I got everything right the first time. The bug and my interactions with my mentor can be found here:
The mentors at Mozilla are very friendly and helpful. They are a smart group of people and are exceptionally patient when helping beginners. I found it easy to approach them and after fixing my second bug the mentor even gave me a list of ‘good second bugs’ and ways to find more bugs to keep contributing. In the future I want to try working on slightly more complex bugs and possibly on projects on GitHub to get more familiar with making pull requests and pushing my own bugs to repos.
The bug I was recently working on this week was a bug in the fire fox developer tools. This bug was an update to the developer tools to call a new function to collapse nodes when viewing HTML. The change was to make the collapse function call the collapse all function to recursively collapse all the child nodes of the node you are collapsing. The community so far has been very friendly, helpful and patient as I was making obvious mistakes such as not updating comments. They stayed kind and helped me through every step including testing and uploading.
As I worked on the bug I learned a lot about mercurial, the version control used in the fire fox project. While mercurial is similar to git I am not an expert in either and it has been a learning experience. I was having trouble pulling new versions of fire fox and ended up pulling prematurely and rebuilding my entire project which takes hours on the virtual machine I use.
Mozilla does very interesting things when managing a multi-language large scale project like Mozilla. Since i had to update the string of an item on the menu that would not be translated to other languages. To solve this Mozilla has any changes done to strings be accompanied by a variable name change as well. The reason they do this is so when developers working on the other languages build their project it will fail as their variable does not exist any more. This signals the developers to look at the new variable and apply a translation to ensure the strings are updated across all languages. They also have an online code tester that tests changes done to the project as well as code deputy’s who are responsible for landing code changes to ensure nothing breaks.
The bug I chose to fix was on a rust project called Bindgen. Bindgen is a rust library that automatically converts C or C++ headers into rust bindings. Essentially it converts the header files into usable rust that can be called. The project has had 143 contributors and can be found here https://github.com/rust-lang-nursery/rust-bindgen.
The bug I chose can be found here https://github.com/rust-lang-nursery/rust-bindgen/issues/1040#issuecomment-332820423 and it is essentially a bug where when converting unsigned long long integers you get an error because bindgen automatically treats all integers as signed and converts numbers that are too large for signed integers into a negative (2’s compliment) and tries to assign it to an unsigned variable afterwards. I chose this bug because I wanted to learn rust.
To solve this bug I am going to need to familiarize myself with rust and then learn this entire project and even then I am going to need to pinpoint the bug. I think this should take be 2 or 3 weeks. I am nervous I am not going to be able to solve the bug and the problem at hand is not as easy as stated.
The developers for the project chat on an IRC channel as well as the comments in the bug. I was greeted with a warm welcome and encouraged to ask questions. All in all it was a pleasant experience and I hope to be able to fix this bug.
Recently I have tested Atom, Githubs open source electron based code editor and Visual Studio Code (VSC), Microsofts open source electron based code editor. While the two felt very similar when opening and viewing projects While both editors had a very similar feel and design I decided to explore VSC in depth due to the fact that I have some experience with it and it being more popular. You can download VSC from https://code.visualstudio.com/.
This is what VSC looks like with the best-resume-ever project open in it:
Many things come easily with VSC such as opening an entire folder is as simple as file -> open folder, changing how many spaces a tab has is controlled through a set of options like this
and installing extensions for a customized experience is made easy with the extensions manager which allows you to search for almost any extension you can think of. When I search for Java in the extension manager I get a list of different extensions with various functionality relating to java:
Next I decided to make my workflow with VSC seamless and download some helpful extensions. I downloaded one for C++ IntelliSense which is pretty self explanatory, it gives VSC the ability to auto-complete code which can greatly speed up ones workflow. Another one I got was Git History which gives you a nice visual representation of a projects git log making it easier to view commits as well as a Python linter which underlines incorrect python syntax. These extensions were nice but the two that stood out were Code Runner and Material Icon Theme.
The run code extension runs your code by simply right clicking and selecting run code. It does this by using compilers installed on the machine.
Material icon theme changes the icons of files in your project to allow for easy identification of file types by giving them custom icons.
The MIT license is a popular open source software license. Its purpose is to explicitly state what is allowed to be done to the software that uses it. The MIT license seems to be very flexible and allow most things such as altering the code, copying the code completely and even selling the code. After reading the license I then read The MIT License, Line by Line by Kyle E. Mitchell which can be found at https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html.
While reading this article the first thing that caught my attention were the copyright laws. Under the MIT license the original writer of the code holds ownership but any contributions to the code are not owned by the original writer and any marginal change gives copyright ownership to the contributor. Not that this matters too much as the next section in the article and MIT license in general gives everyone who downloads the software the same permissions, although I assume this comes in to play if someone tries to remove the original license for whatever reason.
I found it interesting that the MIT license deals with copyright but does not touch on patents but according to the article the language used in the license leaves the discussion of patents an ambiguous one.
The last part I found interesting is the limit of liability part. I found it interesting that the wording is specifically crafted to leave no liability for the licensee of the software when I had assumed using free software would already imply all these things but they specify this explicitly in the license even going as far as excluding suing for tort claims by the licensee.
Building Firefox was a unique and rewarding experience. It was interesting to see just how vast an open source project could be. The thing that amazes me the most is how such a giant collaboration can utilize peoples strengths to coordinate and build such a large and complex code base. Firefox has millions of lines of code while nothing I have collaborated on previously exceeds thousands of lines and could be build effortlessly.
I first decided to build Firefox on windows which required 40gb of space and a lot of steps to set up the build environment. I ran into errors when installing the build tools-rust, python etc so I decided to switch to a Linux virtual machine running Ubuntu. While this will severely slow down the entire process it would simplify the process and not interfere with my current desktops configuration and tools.
The Ubuntu download was a lot simpler only requiring a wget to install everything with only requiring input for prompts. It also only required around 8gb of space. Since the virtual machine had limited ram and cpu I was in for a long wait. The download and installation of build tools took a little over an hour. This included the Mercurial repo–firefox’s choice of version control–which contains the actual files and the build tools like python, rust, and other things needed. After this completed you simply navigate to the directory and run ./mach build. The first build on my virtual machine took around 3 hours which worried me into thinking each change I make would require a 3 hour build which was just on feasible. Luckily I later found out mach only rebuilds the parts that are changed making my subsequent builds much faster.
After the project has been built you can run ./mach run to get Firefox up and running. It was a learning experience navigating the code and changing different aspects of it. In the end I made the new window launch a cat gifs page, I changed the size of tabs to be oversized, I changed the label for the new window and I added a gif animation into the tabs/tab bar.