DEV Community: TD

Week 12: Improving Notifications

TD — Thu, 13 Apr 2023 14:17:36 +0000

With the release of Starchart 0.9, I implemented the functionality to process SSL Certificates expiration after a fixed interval.

To achieve this, we have a repeating background job to fetch certificates from the database that are no longer valid and notify the user regarding the most recent and successfully issued certificate if it is expired.

With support, I also implemented an Info icon button (linking to DNS Checker) in the front end for every DNS record associated with the authenticated user. Clicking on the Info icon opens a new tab and displays information relevant to the DNS record upon interacting with the "Search" button.

For the remaining two weeks, I intend on perfecting Notifications-related code while making minor contributions to the front end.

The path onward

TD — Tue, 04 Apr 2023 14:19:14 +0000

With the release of Starchart 0.8, we as a team are on the path onward to perfect the core features in preparation for shipWith the release of Starchart 0.8, we as a team are on the path onward to perfect the core features in preparation for shipping the first major release.

Tasks at hand

Given that the certificate flow is in place this week, I intend to implement support for notifying users via email when their certificate order is ready. Also, I would be adding a button in the UI which leads to an external resource. Lastly, as one of the Sheriffs on duty, I would ensure I do more PR reviews this week. ping the first major release.

Programming roadblocks

TD — Sun, 26 Mar 2023 23:08:43 +0000

Roadblocks are part of the journey toward finding your footing in the programming industry. It's on us how we maneuver our way around these obstacles to get to where we want in our careers.

In this blog post, I will review five major roadblocks new programmers will likely experience.

1. Not knowing where to start

Not knowing where to start can be frustrating for all of us, especially when employing a technology stack we are unfamiliar with or uncomfortable with. To overcome this challenge, begin with what you know and gradually expand your understanding.

2. Focusing on the problem rather than the solution

We often make the problem tenfold worse by focusing on the problem rather than the solution. For instance, while skiing, if we focus only on the trees rather than the path we should follow, we will only see trees.
Invest your energy in the desired outcome rather than the problem. A Solution-Focused approach to solving problems can help you get results faster.

3. Being afraid of asking for help

Sometimes the bravest thing we could do is ask for help. Of course, we should first try to figure out the problem independently, but if we have to meet specific deadlines and are still stuck, we should feel good about asking for help from community members.

4. Comparing yourself to others

We should never compare ourselves to others, no matter what. It does more harm than good to one's self-esteem. We should always remind ourselves that everyone starts the same journey, with the same struggles we currently face, to get where they are today.

5. Giving up

The thought of giving up should cease to exist in our minds because it's okay to struggle and be bad at something to get better at it. Replace such thoughts with positive affirmations to keep you going. One must Keep failing until one succeeds, without quitting. Remember, making something extraordinary requires struggle, patience, and dedication.

If this post was helpful, drop a like. If I missed an important point, leave it in a comment, as it would help me and others get better at programming one day at a time. :)

Amending my professional path

TD — Mon, 20 Mar 2023 18:00:34 +0000

In Starchart 0.6, one of the features we shipped is implementing repeatable background jobs to process expired DNS records at reconfigurable intervals on startup. Additionally, the jobs get removed automatically on completion and failure after seven days.

The Process

We start by running a query that fetches all the DNS records from the database, with the expiresAt field set in the past. If the array is not empty, we iterate through each record and perform the following actions:

Delete the expired DNS records from Route53 and the database
Send an email notification letting the user know about the DNS record expiration.

The Experience

This PR took less time to get merged than the one before it, as I am getting comfortable working with the BullMQ API. However, I should take some time to review my code to eliminate any ambiguity or silly errors, which I end up realizing immediately after pushing the code to be reviewed by the project maintainers. On a happy note, Starchart has attracted a new contributor, who raised a PR that closed one of the filed issues.

Amending my path

Over the last few months, it's my observation that I have improved in certain areas where I had struggled for a good chunk on my programming journey, and I could not be more happy about that I am amending my professional path.

OSD700: Working with BullMQ Worker/Queues (cont'd)

TD — Sun, 12 Mar 2023 21:52:30 +0000

This week, I upgraded the notification system in Starchart by implementing background jobs that repeat every 5 mins to query the database for existing DNS records or Certificates expiring in less than a month. If the query returns any data, we check the last time we notified the user. If we have never notified the user, we will send an initial reminder encouraging the user to log in to the system and renew the expiring records.

I am confident that initial reminders will be rolled out. Still, we would need to update the value of lastNotified when we renew expiring DNS records and Certificates so that users can be reminded again. I need to update the code so we can send a second reminder when records are about to expire in less than a week.

Implementing background jobs to roll our notifications in this PR has been one of my most meaningful contributions to the project. It needs improvement, and I intend to perfect it so that any code that builds on top of it does not fail.

OSD700: Working with BullMQ Worker/Queues

TD — Mon, 27 Feb 2023 23:58:34 +0000

This week I got to work with workers/queues without prior experience. I had to fill gaps in my understanding, and implement functionality simultaneously, so this week was less productive in terms of coding and more in terms of learning.
One of the main reasons I struggled working with BullMQ API was that the concepts seemed too abstract. It took me a while to understand the relationship between Queues and Workers and how to leverage them to run background tasks to check whether we have to send email reminders to users or not.

I added a background job to Starchart to repeat every 5 minutes and check whether any domains or certificates in the database expire in less than a month. We send out notifications if we find such an entry in the database. We are also keeping track of the number of times we have notified the user, as we only want to send up to two reminders. The first reminder will be sent out one month in advance, and the second reminder will only be sent out close to the expiration date.

At the moment, I want to send the first reminder without any problems or side effects. If that goes well, I will work on sending another reminder close to the expiration date.

I want to get comfortable working with BullMQ workers and queues, as the api can be leveraged in many projects requiring background job processing to solve real-world problems without burdening the application.

OSD700: Unit Tests & Code Reviews

TD — Tue, 21 Feb 2023 05:44:20 +0000

This week I only got to contribute a little to Starchart, as I was still familiarizing myself with BullMQ Worker Queues. However, I finished writing unit tests for Nodemailer that essentially send an email notification via Nodemailer transport. It then verifies whether the email is received by the fake SMTP server established using MailHog.

Unit Tests & Mixed Reception

My PR received mixed reception primarily because it needed comments. A unit test should be well documented, so programmers can understand what the code is doing. Adding documentation may be time-consuming as I also have to focus on implementing the core functionality, blogging about it, doing code reviews, and ensuring I stay caught up in other courses. However, there are solutions like TSDoc which documents the code for you, so as a programmer, you can spend more time programming and less time documenting.

Next Steps

This week, I intend on working on what I could not get done last week: sending test notifications when a domain status updates to pending or error. Making notifications work using BullMQ's Workers/Queues will probably be one of my most significant PR this semester, and I have to ensure I do it right, so it is well received.

Working with Nodemailer and MailHog

TD — Mon, 13 Feb 2023 21:46:02 +0000

This week developers at Seneca College have been working hard to add more features and functionalities to Starchart. With the release of version 0.2, I got to experiment with MailHog; tool developers used to test sending and receiving emails in a development environment using a fake SMTP server. Another cool thing is you don't need an actual recipient or sender account to use Mailhog. I like Mailhog because you do not have to install it locally. Pulling the Mailhog docker image and building the container will give the developer access to a friendly UI similar to that of Google or Outlook.

The Fun Part

The exciting part was sending test emails using the sendNotifications I contributed to and having them appear in real-time in the Mailhog UI.

The Tough Part

The challenging part was writing unit tests for Nodemailer using Vitest/Jest API. Fetching messages sent to the recipient using the endpoint returns a deeply nested object. I had to end up using to expect functions such as arrayContaining and objectContaining in conjunction to ignore fields that were not relevant to the test suite.

Up Next

This week I intend on implementing functionality for sending email notifications when a domain becomes active or errors using BullMQ workers queues. Also, working with BullMQ may prove challenging, but I want to give it a shot, as I would gain valuable experience. Another goal is to update the Dependabot configuration to avoid non-LTS node version updates. Also, since I am one of the Sheriffs this week, I intend to be highly available if any problems require prompt attention.

OSD700 - Eventful week contributing to Starchart

TD — Sun, 05 Feb 2023 22:35:29 +0000

Last week was all about getting started; this week, we were tasked with building on top of the Blues Stack template we set up last week.

This week was quite eventful, and we broke things, but we also managed to fix things as a team. There was a lot of collaboration and active participation, which needs to be improved in some of the other courses I have previously taken.

There were moments when I felt stuck or made a mistake that I thought was irreversible, but luckily the team I am working with was there to steer me in the right direction.

My first task with porting over middleware used by Satellite and adding it to Remix's server. Remix's Blues Stack, by default, uses Morgan, but we wanted to use Pino instead. However, Pino seems to cause a problem, so David has to switch to using Winston.

My second task was to configure Nodemailer to send email notifications in the future. We have set up the function responsible for sending emails, but there's no way of knowing if it will work. We may have to make some adjustments to the current Nodemailer configuration. Next week, I aim to implement functionality to ensure we can successfully send test email notifications.

Finally, setting up Dependabot was fun, but some of us got bothered by it, while others remained unaffected. One of the significant issues with the Dependabot setup was that it would raise PRs for major version updates. We do not want Dependabot to major version updates, as, according to David, it's risky and should be handled manually. Gladly, I resolved that issue by restricting Dependabot to minor and patch-level version updates.

This week I want to ensure we can send the test notifications successfully. Also, I want to enhance Dependabot's current configuration. I am open to helping in other areas of development if needed.

Small Contributions to Starchart

TD — Fri, 27 Jan 2023 21:41:42 +0000

This week, I set up the initial Starchart project using Remix's Blues Stack template. The PR is the starting point for adding, modifying, and removing features and functionalities. There were some problems running the development environment, as the user had to copy the default Postgres credentials from .env.example to a new .env file. I most likely forgot about including it as a step in the "Steps to Test" section of my PR because the .env file was created by the script I used to generate the template for the project. However, as we do not intend to use Postgres to store our data, and the purpose of the PR was to provide a starter code for the team, the PR was successfully squashed and merged.

I also got the opportunity to review a PR in the Starchart repo that dealt with adding package-log.json to the tree and removing dependencies with security issues. The package-log.json was automatically added to .gitignore when I ran the script to generate Blues Stack project, so I pointed out that we should add it back to the tree as it's an essential file for several reasons. One is that it has an optimization purpose of letting npm skip previously installed dependencies during the installation process. Another thing worth pointing out was removing prom-client since it is a Prometheus-related dependency we are trying to avoid.

Some of the errors from my end could have been avoided had I not felt the pressure of keeping other teammates waiting, as all the core features and functionalities rely on the initial Remix Blues Stack setup.

Planning: Using Satellite features in Starchart

TD — Fri, 20 Jan 2023 22:03:45 +0000

Overview

Starchart is a new project being put together by developers at Seneca College. The project will help students manage SSL certificates and subdomains without too much hassle and free of cost.

The project is currently in the planning phase, and being part of the development team, I have been researching ways to add relevant bits of Satellite in the Remix Blues Stack project, we intend on using for Starchart.

The Plan

After studying Satellite and Remix's Blues Stack source code, I compiled a list of features and functionalities we can port from Satellite. It's better to port features from Satellite rather than replace Remix's Blues Stack server with it, as Satellite comes pre-bundled with some dependencies that we do not require in Starchart.

Proposed Satellite Features

Logger
Middleware
Hash
Create Error

Proposed Dependencies used by Satellite

pino, pino-http, pino-pretty (to use Logger)
http-codes (to use Create Error)
Terminus (for health-check and/or shutdown)
helmet (for setting http headers)
express-jwt (for middleware)
cors

Proposed File Structure

After generating a Blues Stack project, we could create a directory named "Satellite" where all the files from Satellite would live. The structure will look similar to the Satellite directory within the Telescope, with only files relevant to Starchart. After installing the needed dependencies, we need to refactor the code to use Typescript and ESM (import/export) syntax to ensure it works.

Server.ts Changes

Since we are using Pino-based logger, we would import logger in server.ts and pass that as a middleware instead of passing morgan.

healthCheck

There's already a route setup for healthCheck in the app directory within Remix Blues Stack project, we could tweak that file to configure terminus using createTerminus function for healthCheck functionality.

Middleware

We could utilize the isAuthorized and isAuthenticated middleware functions to authorize and authenticate users. Also, we could benefit from the errorHandler middleware.

Hash

I am unsure if we need this function, as it's helpful for hashing information that is safe to pass in URLs. We cannot use it for hashing passwords, so if there's no need for hashing information in the URL, we do not need to port this function.

Conclusion

Once the team decides what features and functionalities we need from Satellite, we could start by filing an issue for it in the Starchart repository and go from there.

OSD700 - Setting up Telescope and more

TD — Wed, 18 Jan 2023 11:56:00 +0000

Last semester in OSD600, we were introduced to the Telescope project, maintained by developers at Seneca College. It was a daunting experience to set it up locally initially, as I ran into issues with authentication and correctly seeding the Postgres database. With support from the project's maintainers, I could run Telescope properly on my operating system and contribute to both the client side and the project's backend.

Steps I take to Start Telescope

Load Docker Desktop client
Run the pnpm services:start script
Stop parser using Docker Desktop client
After all the containers are started, run: cp ./src/db/env.example .env
Run pnpm db:init script
Restart parser using pnpm services:start parser

Memory Issues

I have no issues running Telescope on my machine, except that specific containers consume too much memory space, which makes my system lag. I also helped one of my peers connect to the Telescope's backend locally.

Goals

This semester, I look forward to familiarizing myself more with microservices and Docker, so I am comfortable using these technologies in the future.