Learning Journal | Nearsoft Academy | Week 10
November 30— December 07
Hello! 👋 This is my tenth-week takeaways being part of the Nearsoft Academy program, a space to learn, practice, and grow. I’ll post every week, all about the topics I’ve learned during this adventure.
This was the second week of the Open Source phase.
I did my first contribution to open source and I learned a lot during the trip.
Read code — Good practices
An open-source project is made by a big team and usually is a big project, so to contribute to them I should read different files and understand a small part of the project at least.
While reading and writing code on Material UI, I noticed the good practices they use on the project, but the most interesting part to me was the scripts they use to make sure the code is good to read and understand.
- yarn typescript. It checks the typescript declarations
- yarn prettier. It reviews the code to see if it is formatted
- yarn lint. Analyze code for potential errors
Testing
On material UI, they use CI/CD to check all the pull request the community creates, one of the ones that look interesting to me was the argos ci check, it takes screenshots and compares the current project with the changes you want to do, if they look different, it will give you an error and show you the differences between the 2 versions.
Pull requesting solutions
Try to fix an issue, could be a bit difficult at the beginning, finding the files where the change should be done, is kind of complicated, but is about going from the big picture to the details.
First, I reproduced the error and started looking from there, opening the imports and understanding the functions.
After solving the issue, the time to create the pull request arrived. To create the pull request, is important to red gain the contribution guide of the project, to see if you should follow a determined format that the project uses, and of course, you should add all the information needed to make it easy to understand.
Results
I started to work on 3 issues, 2 of them on Material UI and the other on Open Food Network I got a merge in one, where I worked with the useMediaQuery.
I created another PR and I’m still working on it, the project members take care of the way you solve the issue, so they asked me to make some changes to it.
With the 3rd one, I had some blockers, I recently start learning Ruby so all the installation environment is not one of my strengths, I wasn’t able to start working on that issue but, is it a failure?
I consider it as a step to success even if I didn’t create a PR, I learned more about ruby installation, versions, and docker. Now, I know that docker helps you to avoid a project work just in one machine with a specific environment, it creates containers where you can prepare all the things you need for the project to run.