Semester in Review
Tags: opensource, webdev, programming
Published: 2022-04-22 00:40:36

This is it, my final blog for the semester. It's been quite the ride. To start off I will briefly go over what I have done to contribute this past week for the release of 3.0. I will then do a reflection on the course and give some insights into my experience.

### Release 3.0
This week was a pretty busy week, what with exams and final projects being due. Even still, I was able to get some things done before we ship 3.0. 

I was able to land my [`Octokit` PR](https://github.com/Seneca-CDOT/telescope/pull/3485) that I have been plugging away at the last little bit. I ended up not only adding the `Octokit` package to the `dependency-discovery`, but I also did the same in our `Status` microservice since the `throttling`, and `retry` plugins are included in the main package. I also ended up adding `throttling` and `retry` functionality to the `dependency-discovery` since that was the entire point of updating the package. 
![Throttle](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tovo1tjfmkxzncf24pjb.png)
 
That was my only PR for this week. I did however do some reviews to try and help others get stuff landed for the final release of the semester. I first did another review of Tuee's [PR for removing](https://github.com/Seneca-CDOT/telescope/pull/3413#pullrequestreview-948710587) the legacy backend. This PR is an important one. We want to get it landed for 3.0 so we can start using all the cool new `Supabase` stuff that has been added this semester. I had some issues testing it, but after clarifying with Tuee I was able to spin it up and approve it for merging.

The other two reviews I did this week where a little simpler to complete. The first one was a [bug fix](https://github.com/Seneca-CDOT/telescope/pull/3522) by Francesco. He just disabled some of the logging that was cluttering up the Docusaurus build log. 

The other review was a quick [patch fix](https://github.com/Seneca-CDOT/telescope/pull/3530) made by the professor himself to try and get our CI tests to not consistently fail. This would make it so people can get stuff landed for the final release, but we would have to properly fix it at a later date.

### Reflecting

Looking back on the course and I am pretty proud of my accomplishments. In the beginning I had set out to improve my skills with Docker and the backend stuff in general. I took on, within reason for the amount of work I was able to do, any and all issues related to Docker. 

This eventually lead to me taking responsibility for, and 'owning' the launch of our Docker Registry. Even though I 'owned' it, a lot of work and help was provided by a number of others. Josue in particular was a great help since he has such great understanding of the project as a whole. I am especially appreciative of his help because he is not even a student this semester, all the help he gave was during his own free time. 

A lot of what I did for getting the registry up and running was just getting things like PR's started to the best of my ability, and then post it as a draft PR and ask for help putting the last few pieces together. It was nice working in such a collaborative manor.

I can especially appreciate the collaboration because at my place of employment, I am the lone developer after a senior dev took another opportunity a few months ago. It's hard working through things as a junior developer by yourself. Having many minds on a single issue can not only get the task done sooner, but also save an individual from getting stressed and burnt out working on issues that are giving them troubles. This has shown me that I do not want to work at a start up any more, I would rather have a team I can depend on and break through issues with. 

So, while a lot of the testing of the registry setup was done by Josue and Dave. I still made sure it all happened. During the triage and planning meetings, I would make sure to ask what direction, or what the next steps would be for the registry. I was driving the issues and making sure things got done by following up or starting thins on my own. That is why, even though I feel like I was guided through a lot of what had to get done code wise, I still feel like I can honestly say that I 'owned' the issue, and that I was responsible for getting the registry up and running. 

One problem with me taking ownership of the registry is that I put all my attention to it and was not keeping up with what everyone else was doing. Yea, I knew the big picture things like adding Supabase, or getting the Parser service up and running. When the registry launched there was still about a month left of the course and when I was looking at issues to pick up and help with, it felt like I was so far behind. I felt that since other people had been working on things related to these issues that it would be far easier and take much less time than if I were to try and bash away at it. 

A prime example of the is how long it took me to do the `Octokit` stuff. Jerry had mentioned it would be a relatively quick and simple PR to do when I took it over from him. Looking back on it, it was, but I had to do a bunch of research to just find out what Octokit was, and then I was uncertain of how and where we wanted to use the expanded package. Overall, it took me far longer to get the PR landed than it would have taken Jerry, but he had other, more important issues to try and tackle. 

I tired to make up for this by getting in on more reviews, but most every time I went to check if something needed to be reviewed and everything was marked with `changes requested` so I left it alone. I also tried looking into some of the Supabase issues, but I haven't been following it at all so it was quite daunting to try and step in to fix things when I don't even know how to spin it up. 

### Wrapping up

Just like with the previous course, this course was another great example of how to give students real life work experience that will look good on most any resume. I feel much more confident in my Git abilities and feel like I have learned a lot about Docker, nginx, registries, and workflows/yaml files.

These two course should be core curriculum, but I understand why they are not. There is only one David Humphrey, and without him I find it hard to see these courses being as successful as they are. He really goes above and beyond what most of the other teachers do. I just wish I had known his cloud computing course was going to be available to my program this summer. If I had a time machine I would gladly take that course over the Azure Fundamentals cloud course I just completed this semester.