my-note, your-note, our-note
Where to begin... In my journey to learn everything I can about git and Github in my course, I have begun to contribute to projects in my class community. In my previous post about
my-note, I described my note taking app. As the note taking app was a lab for my course, many of my classmates made their own note taking apps, of which I have contributed to two of them. I will discuss each project and how I contributed.
micro-note
Micro-note was created by MeisterRed. It was comprised of a title and a text box, colored to match post-it notes. Like my note taking app, it saved automatically and when reloaded would retain it's information, storing the text written in the browser. It looked like this when I first saw it:
 |
| micro-note (before pull request) |
Issue - Add "Save" and "Download" Buttons
I thought that micro-note was lacking the ability to download your notes, which would allow the user comfort in knowing that they have their notes saved on their computer and allows the user to make more notes. I proposed using FileSaverJs, a library I used in my-note to facilitate downloading the notes taken. I also suggested adding a "Save" button to increase user comfort that their notes have been saved. The issue can be found
here.
Solution and Pull Request
First, I added the "Save" and "Download" buttons to index.html. The save button called the noteSave() function already implemented by MeisterRed. This function saved the contents of the text box in the browser's internal database. I linked the FileSaverJs library at the top of the document and created a downloadNote() function, showcased below:
This function uses the FileSaverJs function saveAs(), in order to generate a downloadable document from input. The input is first formatted as a Blob object, and then the blob object is passed to saveAs(), along with a name for the download file. The name is set by a variable, which I set using a text box next to the download button shown below:
 |
| micro-note (after pull request was approved) |
After I finished the button functionality, I added CSS code in order to fit the style of micro-note intact and provide context clues to how the app functions.The pull request was accepted with no comments or bug fixes needed. The pull request is located
here.
my-note (grommers00 version)
Although
grommers00's my-note had the same name as mine, our apps were similar and different in many ways. He and I had taken different approaches to the look and feel of the app. One of the most glaring differences was how we had used PaperCSS.
Issue - Improve the UI
 |
| my-note (before pull request) |
Grommers00 had used PaperCSS, but not in a way that utilized it's features. He had no styling on the text box, the buttons, and nothing to impress upon the user that they had successfully saved. I suggested that to improve the UI (user interface), I could add more features from PaperCSS to make his text box stand out more, and improve the responsiveness of his buttons. I also suggested adding an alert that would let the user know that a button had been pressed and was successful. The issue can be found
here.
Solution and Pull Request
 |
| my-note (after pull request) |
I added CSS to change the color of the buttons to represent their meaning in a more intuitive way. I also increased the size and emphasis of the text box. The red "Saved!" box is an alert that pops up for a second after the file is saved. There is also a "Removed Text!" version of the alert for the respective button. The alert was implemented using a function that I called at the end of each button function, with a different message for each one passed as a variable. The pull request can be found
here.
Interactions with my classmates
In both cases, I interacted with both developers online (Github and Discord) and in person in order to understand what they wanted me to do. In grommers00's case, we discussed what he wanted to do with his app and if the improvements I proposed followed his original idea. In terms of MeisterRed, we discussed his app's style and how I could fit my additions into his existing design. In both cases I tried to remain professional and fit with the original developer's style of code and naming conventions.
I also assisted some people in class with their apps. I had someone next to me who had never used html before. I assisted them in how to add javascript to the page, as well as some pointers on CSS and html formatting. I was able to help them get to a point where they could add their own features and play around with it confidently.
Reviewing Pull Requests on my app
agarcio-caicedo's Pull Requests
agarcio-caicedo made two pull requests on my app. Their
first pull request was to add dark mode. I really liked the way that they implemented dark mode, using a combination of javascript and css. I really enjoyed the way that it looked afterwards, and I thought it fit the original design very well. I approved it without fixes as I was really impressed and it hadn't broken anything as far as I saw.
The
second pull request that they made was to fix my word count feature. I used a really simple method to generate a word count by counting spaces. I knew that the word count could be tricked by adding more spaces between words but I thought that users wouldn't abuse this feature. What I didn't know was that this can cause issues in FireFox. I tested my app in Chrome so I had no idea that this feature would break in another browser. The fixes to my code were relatively simple and made the app seem more professional, so I added them in without any issues.
My Overall Experience
My overall experience with this process was good. I never realized that Github had so many safety measures. I thought that as a developed it helped me to manage what I added to my code. It also helped me to practice my code reading skills. Everyone has a different style of writing code so sometimes it is difficult to read other people's code. Following the original developer's style was also difficult at times for this reason.
My process was to begin by looking through the person's code, looking at their implementation on github.io, and then deciding what I was going to work on. I would then write an issue regarding the problem and would then fork the repo to work on a solution to the problem. If I finished early I would write a Pull Request detailing what I had done and referencing my issue in order to assist the developer in finding my issue. Then it was just a waiting game until the developer responded or merged my fixes to the master branch.
I learned a lot of things in this process. Most importantly, I learned the progression of the Github contribution process. I also learned how to deal with merge conflicts, as I had to fix one in order to perform a pull request with grommers00's app. I learned how to add css and javascript documents to an html page, which I had somehow never done before. Finally, I learned the git bash commands, which taught me to always pull before I push. I made that mistake too many times.
