Lab 1 for Release 0.1

Alexander Hugh
3 min readSep 26, 2020

--

If you saw the title of my last story I finished release 0.1, lFinder! Wohoo! Now came the funky part (not hard, funky). Helping to debug another person’s release 0.1. My partner was the awesome Thanh Tien Phat Nguyen for lab 1, however I couldn’t forget the contributions of Pedro Fonseca and github user c3ho helped debug lFinder before I started lab 1. Working with my partner was great, although asynchronous working is fine, it doesn’t beat synchronous in my books, but alas, this is my opinion.

Finding the issues was easy, we had both spotted and discussed about each other’s code for a solid two hours. We then discussed why we did what we did and found out new ways to improve each other’s release 0.1.

My Code

My first issue was that I did almost EVERYTHING in a single method, I KNEW I shouldn’t have done this but I was so in the moment coding that when it was complete I was hesitant to change the code. Of course this was pointed out to me by Thanh and I made a mental note for the next time I make stuff like this to avoid over bloating a single method.

The second issue was my README.md file, it had no installation instructions! Thanh and I both had this problem actually and we fiddled around with each other’s code in terminals till we found out just running npm install -g worked wonderfully. We also tried npm link which gave good results but wasn’t global.

However, the biggest issue wasn’t even with our programs however. It was with trying to push our changes to github. To be honest, this wasn’t a smooth process. If anything it was finicky and troublesome trying to get github to work with us. Even after we followed the lectures and searched up multiple tutorials online we couldn’t properly push our changes. We ended up just settling on writing issues in each other’s repos and solving them manually, which I know is dreadfully inefficient, it’s far easier to do a proper pull request but I was frustrated and missing dinner and Thanh had to go to work. I’ll have to do more research on why it was giving me such errors.

My Partner Thanh’s Code

While going through Thanh’s code I was amazed at the similarity of certain things like how we both used yargs and chalk. I did however enjoy how his was more simple to follow despite the lack of comments. One thing I noticed I did that Thanh didn’t (not that he needed to, just an observation) was that he didn’t check for duplicate URLs which would have made his already fast CLI even faster.

One thing I suggested when I was debugging his code is that he change the colour of his other unknown URL case to be different than his main unknown error case. This is because when I checked those files my browser gave me a warning on them. Other than that, it’s interesting seeing someone’s code that is both similar and dissimilar to you own.

Conclusion

While we fixed all the coding issues, discussed design choices and other things, it was still a disheartening feeling to be crushed trying to tame the beast that is git. Despite that, it was great actually working with each other’s open source programs and spotting things and learning off each other’s code.

--

--

Alexander Hugh

Student in software development at Seneca college, Ontario Canada. Primarily going to talk about programming stuff but may talk about other hobbies here.