Having new partner
Since the day I jumped into OSD600 class, I have had a lot of great experiences. This course has brought me to an amazing open source community. Recently, I have been networking with Francesco Menghi about our first assignment (release 0.1). We have reviewed each other's codes and given feedbacks as well as found issues and errors of our programs. This is not the first time I have read someone else's codes, because I have a group of friends who help each other on learning in this programming field.
Reflection
The feeling of reading others' codes is amazing, you will not only experience various methods to deal with the same problem, but you will also figure out whether the way you write your codes is optimum or not. In the mean time, I also received the feedbacks from Menghi, he pointed out what did I do wrong, and he also gave me a suggestion to clarify my outputs which was great. I would say, if I did that project alone, I could never find those errors and my outputs would be confusing to users.
Problems of viewing someone else's work
There are also some drawbacks of viewing someone else's codes. Firstly, a lot of us are just junior developers. Even some of us have had at least a co-op before, viewing and estimating others' codes are extremely difficult. Sometimes, we have a tendency to stick to certain methods to deal with the problems depending on who are your instructors or what kind of documents you follow. This means if the person you are giving feedbacks to has a different way of writing code, compared to yours, it would be very confusing for you and you might end up having no idea what are they writing and what is the purpose of that line of codes. Another common problem that we are likely to face is if you find an error code, but your friend still do not know how to solve it, that problem would stay the same eventually.
Programs' issues
Menghi did a very good job, the program is running perfectly without errors, except he should have clarified how users will input the file(s) or folder. In more detail, if the input file's name has whitespaces such as Silver Blaze.txt, that file need to be put inside a double quote (ssg -i "Silver Blaze.txt"), otherwise, the program will not understand and assume that you input 2 arguments. Also, the --version option of his tool also needs to display the current name of the software due to the release 0.1 requirement.
Detail: https://github.com/menghif/dodo-SSG/issues
One of my program's problems is it accepts all files. For example, if you have an input.md, my program can still read it and export an html file, while it is supposed to receive only .txt file. On top of that, Menghi recommended me to fix the outputs so it will export files with specific names instead of just index1.html, index2.html, etc.
Detail: https://github.com/nguyenhung15913/OSD600-SSG/issues
All of the issues were fixed and it was not that hard to do so because they were just some common mistakes of misreading the assignment's requirements. I also re-wrote the codes based on his feedbacks and now I can see that my program have been better than before.
Top comments (0)