Data Structures and Algorithms

I'm finally done all my courses and since the job market isn't that great right now, I have taken a different approach. Instead of working personal projects or contributing to open source, I've decided to brush up on data structures and algorithms for a bit.

One thing I found lacking for Seneca's Computer Science related programs was the science portion of Computer Science, maybe it was because I was enrolled in CPA and not their BSD program.

For CPA the only course that deals with data structures and algorithms, DSA555 is offered as a professional option. After taking the course I noticed why, as a pretty smart person in the class said "If this was a mandatory course, a lot of people would be dropping out of the program, it was pretty hard". I still wish there was another similar course or two offered so we could learn more about analyzing the run times of more complex functions and graphs.

I took DSA555 last winter and have more or less forgot how to implement or how most of the things I learned in the class work: linked lists, trees, different types of searches + sorts. So now as I am typing this blog, I am solving and looking at problems on leetcode.

A friend of mine currently works for Tesla and is looking for a new job. Most of the places he's been interviewing at for a full stack position have also asked him data structure and algorithm questions on top of questions involving joining two tables in SQL or how to mock a request for testing.

I think this is fair as it makes a developer conscious of the code they write and makes it easier to recognize patterns and respond accordingly.

For example, say I have an array of sorted numbers and I have to find if a given number exists:

I could loop through the array and check each element
Or
I could check if my given number is the middle element in the array. Depending on if it is bigger or smaller I can use the upper or lower half of the array and repeat the same steps, until the number is found or not found.

The second option sounds tedious, but depending on the size of the array, it may actually turn out to be faster than the initial option.

It also allows developers to think about the function they are writing performance-wise. Is it a O(n) solution? O(n^2) or worse O(n^3)? If it is the latter two, can I improve the run time of it? For personal projects this may not matter as much, but if you are working on software or systems that will be used by millions of people or contains a ton of data, these little things start to add up!

OSD700 Post 1.0

When our prof doesn't have to review our feeble PRs, he's on a mission.

OSD700 Release 1.0

We've finally hit 1.0 for Telescope. What a journey.

I finished up the issues I was still working on from 0.9 and worked on a few more:

PR #919: Feed Type Should Support Delete, Modify (Delete + Create)
Overall, I did not expect the whole "add feed" feature to be this big. We had 4-5 people working on this. 3 on the back-end, 1 on the front-end and our prof helping out on both ends. Happy to say we have it working. My PR was working as expected, but it wasn't doing great performance-wise due to multiple Promise.all() and awaits, with help from our prof, we were able to get rid of a lot of them. I learned if you want to trigger our prof, wrap a Promise.all() within another Promise.all().

PR #931: Add a Way to Receive Updates when New Posts are Available
PR is done, I'm beginning to regret mentioning I wanted to work with React.

PR #937: Finish Search Feature
This PR was possible because I learned a few things from reviewing a PR by @Silvyre. Seriously, if you want to be a better developer, look into doing code reviews, you'll widen your perspective.

PR #989: Teach tools/autodeployment/server.js about a release to master
Our staging box auto deploys itself whenever there is a change in the master branch. We wanted to change it up for production so it will only auto deploy itself whenever there is a tagged release. One of the things I have neglected during my years at Seneca is scripting or just using linux commands. I've started on the path of slowly redeeming myself with this PR.

PR #993: Remove "feed added successfully" after some period
Front end change, this uses the SnackBar component implemented in #931 to display a toast informing the user if their feed has been added

Wrapping Up
I started this journey in OSD600 where our first assignment was to create a notepad app (I did the bare minimum) and trying to enhance or debug other students' implementation of it on Github, I even remember I had issues writing the notepad app. Back then, I could not imagine contributing to building a project from the ground up (Telescope)... I could barely fix an issue a week to keep up with Hacktoberfest during that time.

Now that OSD700 is about to wrap-up, I've noticed how much my attitude and skill changed:

We have to implement a new tool for Telescope? No problem, time for some experimenting.
There's a new component that needs to be built? Front-end huh... but I'm game.
New issues dealing with a tool that has been implemented but I haven't used yet? Pick me!
Nginx issues? Oh god. where's @manekenpix to hold my hand through this?

Overall this course and project was extremely fun. We worked like a team you would find in a workplace, we had dev-ops, back-end devs, front-end devs. We got to explore and experiment with different tools we normally wouldn't get a chance to work with all at once: ElasticSearch, Redis, Kubernetes(lol), Gatsby, GraphQL, Nginx, Docker, Jest, SSO. It did not matter if we were not able to implement them in the project. Just the opportunity to experiment with it has improved my knowledge with it, which I am very grateful for.

I think why these open source classes were so fun was because all the things we were doing were open ended. These were real world issues, there is no answer guide for us to take a look at when we were stuck. Sometimes even our prof was reading API or tool docs to understand and help us out when we were stuck on our PRs.

Lastly, I do not think this would have been possible without our prof and lead @humphd, he's a monster. Deployment, back-end, front-end, authentication, system + architecture design, he is knowledgeable in it all. He can and will request changes on your PR which you spent hours working on. As of writing, we have ~468 closed PRs, of which he has probably reviewed close to that same number of them. Thank you for guiding us.

In no particular order it was a blast working with you guys. Thank you @manekenpix, @cindyledev, @Silvyre, @agarcia-caicedo, @grommers00, @miggs125, @lozinska, @yatsenko-julia

Other students at Seneca, if you have a chance to take OSD600/OSD700. Please do. This is probably the highlight of your program.

OSD700 Release 0.9

This post serves two purposes. I was told to blog and this is to test PR #931 for Telescope.

I'd like to give a big shout out to frequent collaborator and contributor @manekenpix for always helping me out. Be it reviews, collaborating on issues or help testing. He has made contributing to Telescope a lot easier than it should've been.

Here's the PR list I worked on for 0.9 and will continue to work on for 1.0

PR #937: Finish Search Feature
This is a PR in progress

The search feature we have right now works, but it isn't polished. We currently only support one search filter, authors. Searching takes a while, but there's no indication of whether the results are loading or not. I added a spinner to fix this. I have to also have to add an endpoint we have to search through Post content and return post results based on the data we get back.

PR #931: Add a Way to Receive Updates When New Posts are Available
This is a PR in progress

This is pretty close to finishing. I added a timer that will fire off a fetch request to get the number of posts in Telescope. If there is a change, a non-intrusive alert should pop up for 6 seconds letting the user know there are new posts available.

This PR also led @manekenpix and I on a 3 hour wild goose chase to track down why we weren't able to get one of the custom headers we had for Telescope. This resulted in the following PR #934, that's right, if you check the PR it took us 3 hours to add/change 4 lines. It was fun, but so so frustrating.

PR #919: Feed Type Should Support Delete, Modify (Delete + Create)
When I get frustrated with the two PRs above, I like to work on this because the backend doesn't lie. I don't have to deal with stuff rendering or not rendering on my screen or go reading up on new hooks. I pray if I ever have to do front-end development in the workplace I'll only have to use UseEffect and UseState hooks.

Anyways, this PR provides the functionality of removing a Feed and having it also remove associated posts in Redis + ElasticSearch. This PR was enjoyable because it taught me the advantages of writing lots of tests. The function works, but I just need  to finish writing a test for it and it should be ready to be reviewed by our gatekeeper @humphd.

Other PRs I worked on were refactoring the layout.js component we had previously using class components to become functional components. Refactoring this didn't take so long and at the end of it, I realized I got pretty good at using the useEffect and useState hooks of React.

As we're nearing 1.0 for Telescope and with so many things left to finish prior to shipping. I present the following as nobody in the Telescope channel has started panicking yet.

Developing with a Test First Approach

I spent this week kind of sluggishly finishing up PRs that were close to completing such as the version on the banner. We can now see what the latest commit Telescope is running now by clicking on the version.

Another one I finished up since last release was configuring Nginx to use recommended settings by Mozilla.

Yes, I am still neglecting Kubernetes...

However, today I'm here to write about an issue I just took on and started working on at 2AM this morning, Issue-908 and I think I am close to finish. This work involved Redis, which was nice as some of my earliest contributions to Telescope were Redis related issues.

For this PR I took a different approach, put a heavy emphasis on thinking about and writing tests, I quickly wrote new features that should have mostly worked and used the tests I wrote to aid in making sure they are mostly correct. Up to this point, I haven't really written much tests, I have maybe modified existing tests. So this time I made sure I wrote a ton of tests to cover situations and from there working on the new features so that whatever I am expecting and what I'm actually receiving match. 

The approach was refreshing, instead of having to console.log() things, the tests easily told me what they were doing or what the value being returned was. For example as part of this PR I had to create a function that removes the Feed and all its associated Posts, some people might write a test that adds two posts belonging to a feed, delete the feed and check whether the posts still exist in the database.

Here's what I did:

1. Create the feed for the test, make sure the created feed has the same values I used to create the feed.
2. Create two posts, make sure the created posts' data have the same values I used to create the posts.
3. Remove the feed, make sure the removed feed doesn't return any thing, check if both posts are empty too.

Is this test perfect? Probably not, there may or may not be some edge cases I haven't though of yet. Is this overkill? I have no idea, but more is probably better in this case. Will I write more tests in the future as long as it is not in the front-end? You bet. With all these tests, if any of them start failing, I can probably pinpoint where the code went wrong, instead of playing a guessing game.

Be responsible, write tests!