OSD600 #2: Let the show begin...

This week in the course OSD600 was pretty interesting so far.
First of all it had been a long time since I had dedicated my time to write something from scratch; It's sort of a skill every developer needs. Over the course of the year most of the code I'd written came mainly from either my Co-op term writing boring C++ code or either empowering compilers on exciting projects like LLVM!

The project in question is the following rust-cli-tool (Yes, the name is not decided yet...). While most of the Rust traction I had before was code mainly written by myself for exploration purposes, I redirected my efforts quite differently this time, making my code very modular and as accessible as I could.

I already had some assumptions regarding the viability of doing my project in this language. It indeed takes time to get things working, but when they work, safety at runtime is not a concern.

I intended to write this originally in OCaml, however if the barrier It's already high in Rust; OCaml It's x2 times harder for the average student to contribute to. It would've been cool though.

The following questions are extracted from Lab 1 for the OSD600 course at Seneca Polytechnic

- How did you go about doing your code reviews? Do you prefer an async or sync approach? Why?

It is always an interesting experience to get your code reviewed by somebody else, it certainly provides very constructive feedback and highlights mistakes that are unlikely to repeat if you're competent enough.

In regards to the async or sync approach: I don't think I've ever heard of code reviews synchronously at least coming from my co-op terms or that I've ever heard. In companies senior developers tend to be busy, hence flexibility is a must in that aspect.

- What was it like testing and reviewing someone else's code? Did you run into any problems? Did anything surprise you?

This is certainly a skill I've got yet to develop. It is not the same as implement something that aligns with some specific requirements(aka PR's). Certain details and having a mental debugger are crucial for any effective code review.

- What was it like having someone test and review your code? Were you surprised by anything?

Not surprised at all. In my specific case and throughout my whole career code reviews will be prevalent and will occur no matter what.

- What kind of issues came up in your testing and review? Discuss a few of them in detail.

I reviewed Parker's repo. The Issues overall where trivial. Certain things not being documented, or core functionalities not implemented and not having a clear message for the user. This is normal given his project is at a very early stage of development. While I won't expand on any issue in detail given they're not substantial enough, I experienced a Language shock when writing Rust as to reading Go. They're two Languages with completely different philosophies; Rust focuses in verbosity contained within It's type system for the sake of memory safety, while Go focuses on simplicity, easily readable and modular code.

_- Provide links to issues you filed, and summarize what you found
_

Link

Most of what I catched were nits and not worth talking in detail. While I could've been critical of any aspect in regards to the functionality which is not implemented, I didn't feel that was the point. As Labs progress I'll try to be more critical given all of the projects complexity will increase significantly.

- Provide links to issues that were filed on your repo, and what they were about

Link

Most of the issues came from lack of testing which was not implemented in this first lab. Along these fixes I also did some extra things like adding a very barebones ci-cd pipeline and test suites on the core functionalities (Pardon me if it was not required for this lab but I cannot implement a new feature without knowing I didn't break anything else). If any other students find difficult errors encountered on the pipeline side of things, I can relax the tests temporarily to make it more accessible while they're introduced to this process.

• #2: Revolved mainly around a faulty core functionality related to pattern matching. the crate I used for this Globset. The patterns passed through the CLI were not compiling and matching properly any regular expression when performing the proper file/directory traversal. Fixed it pretty easily by computing the relative path of every file which seemed to satisfy this dependency. I was curious on the nature of regular expressions and had a quick read related to glob in Wikipedia.

The other one worth mentioning

• #3: I may have missed it somehow but I should've stated clearly that the -o flag was not implemented yet. While that could've been a simple solution I went forward and implemented that type of output generation utilizing the already existing infrastructure around File handling. Some nits though, I'm still not dumping each file content's . So far I'm simply displaying the files we're discovering. In the following week we'll handle the proper content handling as we should

- Were you able to fix all your issues? What was that like?

Yes! Took sometime but it was worth-wile. Had a really good time writing rust as It's a breadth of fresh air due to the excellent tooling present in that ecosystem. Once you utilize cargo and It's package management, you don't wanna rely on manually installing dependencies in C++.

_- What did you learn through the process of doing the testing and reviewing?
_

Of course not too much of learning on my end. I've got two super important milestones I really want to accomplish within this course, one of 'em:

I'm well aware My project might not be the easiest to contribute to given Rust's technicalities. Making my project attractive to people not familiar with It's ecosystem will be crucial for my success in this course, we'll eventually get there.

• David