At the Code-a of the Semester
12 Dec 2023The following text is licensed under a CC-BY-SA 4.0 Global License. You may share it freely, even for economical purposes, so long as you provide me credit and a link to the license.
December is the time people do many things; reflecting on what they did throughout the year, making plans for both the holidays and the coming year, and cheating on their spouses. Since I am not married, I would like to focus on the first of these things.
As with any class, a given subject is divided in many smaller subjects, and three of the ones that resonated with me the most were open source, development environments, and managing a project with Agile.
Sourced from an Open Range
I previously had joined the free culture movement (which supports the freedom to distribute and modify anyone’s creative work without dealing with the original author’s censorship) in 2022, so I already had some understanding of the various licenses (even some such as the Licence Libre de Québec or the European Union Public License, which understandably a University of Hawai’i course would not go over) and that free and open source software is software whose code is available to distribute, modify, and share.
What I did learn in this class, however, is how to work on an open source project. Specifically, when using GitHub, I learned how to add a license, both automatically and manually, as well as how to make my repositories shareable. I also learned how to communicate with potential sources of aid by asking smart questions, meaning I have a better clue as to how to give people enough information to help me figure out what I should do next. Therefore, I understood specific ways people can build off others’ works and improve them. (I attempted to work on a Japanese translation of a software I used, but alas, school life got in the way. Over my break, I plan to translate pieces of software that I foresee myself using.)
For instance, I would see nothing wrong with free and open source software engineers asking for donations or even “selling” their open source software as done by elemetaryOS (a Linux distribution) or DeArrow (a YouTube extension that edits the titles and thumbnails of YouTube videos on the fly to remove clickbait). Sometimes this funding comes from the sale of physical objects, such as Pop!_OS and Tuxedo OS being supported by the hardware that System76 and Tuxedo Computers respectively sell. It is also possible to sell your own computers, or even clothing, and donate part of the purchase to the distribution included, as happens with Manjaro. In fact, this philosophy extends outside the world of software all together, as proven by Nina Paley, the filmmaker behind public domain films Sita Sings the Blues and Seder-Masochism. (These films made more money in the public domain than they would have using traditional distribution.) I will take the free and open source mindset with me wherever I go.
Environmentalist IDEas
This class was also not my first encounter with development environments, but I did learn a fair bit about their inner workings. I had used the JetBrains suite before using a free version of their Python IDE. This semester, on the other hand, I had to use a paid version of their JavaScript IDE, and do much more with it than I had done while coding in Python. This led to problems when I discovered that the unofficial Flatpak package I was using had permission issues that stopped much of the functionality I needed from working, and I needed to not only reinstall the program as a snap, but I also needed to install Chromium (I refused to use Chrome proper) in the same way. I did enjoy the IDE once it was set up, especially near the end of the course. At some point, the IDE was the only way I could push and pull from a Github repository that someone other than me set up. That said, I should have made the time to get acquainted with the shortcuts in the IDE so that I could have saved more time later on.
The ordeal with trying to use IntelliJ IDEA made me understand why so many programmers insist on using simple text editors and/or command line tools to write the code itself, and I see the importance in diversity from being forced to use that particular option. With that said, I do also see why someone would not only choose the proprietary IntelliJ IDEA but also the paid version. It had many bells and whistles that made looking through the code and finding errors much easier as well as keep my style consistent. It was easier to find a line of code when I did not remember what file it was in, as well as to search through large project trees in general. When I am coding in the real world, I may or may not have more freedom to the choice of an IDE, so I should experiment with several while I have the time to do so, then I should be able to find my preferred balance between simplicity and function.