DEV Community: Alexander Samaniego

DPS909 Blog: Final Pull Requests

Alexander Samaniego — Sun, 11 Dec 2022 03:29:24 +0000

This post is an update on my progress on the issues I selected to work on in my previous post for Release 0.4.

Pull Requests

I completed my work on issue #201 and PR #224 for that issue. The PR was eventually merged into the main branch after a couple of necessary adjustments. I ended up having to adjust the querySelector in order to remove a condition. The querySelector now only selects elements with the attribute data-validation-on. This allowed me to simplify the code while only selecting elements from the page that were created by the library. Furthermore, I had to add a nullish operator to set the default event listener if there is no attribute specifying one. I also added optional chaining to check whether the attribute actually exists, to avoid any errors.

As for the other issue I wanted to work on, #211. It was slightly more difficult than I had thought. I spent a couple of days experimenting on how to enable validation on forms when the user optionally uses <validation>with a form passed in as a prop, as explained by the second point in this comment. I could not find a solution for this because I realized in Astro, you can't use prop component variables within the <script> element in a component. Outside a <script> element, it is possible to use component variables as described in the documentation. So, this is where I had trouble trying to apply event listeners to forms specified by the user after form creation. I didn't get a solid enough solution to create a PR for this issue. I asked the project maintainer a couple of questions for clarification, but they ended up closing the issue due to a change of approach.

So with things not going as planned, I quickly had to find another issue related to the form component. Luckily there was an issue directly related to the first PR I made. Issue #230 relates to the form validator again. All components except the Radio buttons were compatible with form validation. To fix this issue, I spent time experimenting with various ways to make the Radio buttons compatible. At first, I was looking at the validator file, Validator.astro, for any line of code that may have caused the error. When nothing came of it, I went through the process of form creation multiple times to see exactly why other components were being validated and not the Radio buttons. I realized the this library treats radio buttons as one form component when in reality it is actually multiple. So, I decided to look at the other components to see what is different about the Radio buttons. As I described in my comment here, I noticed that other components only contain <input> and <label> elements, whereas the Radio button element contained another <div> element that covers the other elements. I experimented with removing that element and found that validation works. I suspect that the additional element was interfering with validation of that component and created PR #234 describing my solution. It still needs to be reviewed and merged but I think that part will go smoothly.

Conclusion

I think this entire process was a good experience. I got to work on a project that I was already familiar with and further enhance my knowledge of it. I also got to work with the project owner and maintainers while working on my issues. Without their help the process would've taken much longer and it gave me more experience working with "strangers" on a public repository. I felt like I gained their trust with every successful PR. So while things may not have gone as planned, I still felt good about closing several issues while making 2 PRs. Things not going as planned also showed me that not everything goes smoothly so you have to think quickly to get things done. My goal was to complete at least 2 PRs and I got it done, even though it wasn't one of the issues I originally wanted to do.

This should be my last blog post for DPS909. This has been one of the most useful courses I've taken to date and I've come out a better developer than I was at the beginning. 10/10, would recommend.

DPS909 Blog: Issue Progression

Alexander Samaniego — Sun, 04 Dec 2022 00:57:16 +0000

This post is an update on my progress on the issues I selected to work on in my previous post for Release 0.4.

Progress

I began my work on issue #201. I was initially confused by the the description of the feature to be implemented, so I asked the project maintainer to explain it further. Another project contributor also further explained what was needed and this really helped me out. I also read up further on the Astro framework to understand how the project is put together. I started with the documentation explaining how Astro components work and read on from there.

After reading through the Astro documentation and going through the project documentation again, I experimented with the source code for a while just to see how I would implement the requested feature. The most difficult part about this was just trying to figure out how all the files work together. There are a lot of files in this project and it's easy to get lost. By the end, I felt like I knew the ins and outs of the entire project, so I began to code the feature into my forked version of the project.

By the end of the week, I opened a pull request (PR) with my feature implementation. I described what changes/additions I made and noted areas that require focus after the PR is merged.

The project maintainer and one other reviewer made comments on my PR which I ended up addressing and making the requested changes. Now I am just waiting for any further comments and for the PR to be merged.

Remaining Issues

Now that I've nearly solved one issue, issue #211 seems like it'll be a smoother process since it is relates to the same area of the project and I've already went through most of the documentation. So my plan for the coming week is to hopefully open a PR quicker than I did for the first issue. If no problems occur and I still have time before the deadline, I will attempt to solve another issue in the project.

DPS909 Blog: Planning Issues to Fix

Alexander Samaniego — Sun, 27 Nov 2022 23:53:31 +0000

As part of the final Release 0.4 project for our open-source course, we were asked to work on something larger and more impactful than anything we've done in the previous three releases. This can either be implementing features, fix a difficult bug, work on 2 or more smaller but related issues, or work on a bug in a large open-source community.

I chose to work on 2 or more smaller but related issues. The issues I chose were from a project that I've previously worked on called Astro Reactive Library. This project builds components and architecture for other projects that use the Astro framework for their reactive user interfaces.

The issues I chose to work on both relate to the form and validator components.

Issues: #201, #211,...TBD

Issue #201

The feature request here is related to the form component. In this issue is to implement new event listeners for other types of events. Currently, the validator will only attach an event listener for onBlur. There needs to be more event listeners and a way to determine when the event for validation on the client will occur.

Issue #211

The feature request is related to the validator and the form. In this issue, the way the validator attaches to components must be changed. Currently, the element selector uses the component <form> as a selector. The job here is to change it to use the unique ID attached to components as the selector.

My Goals

My goals for this Release is to take my basic understanding of the Astro framework and hopefully turn it into an advanced understanding by solving these issues and implementing the features correctly.

As of right now, these issues seem a bit confusing to me so there will be a lot of learning involved which will take a bit of time. Release 0.3 introduced me to the Astro framework and so my understanding of Astro is still pretty basic. This will be the challenge I will have to overcome.

If by the end I find that these issues were quick to solve, there are more issues in the project repo that relates to the same area of the project. I will tackle some more just to give me more of a challenge.

I will post an update on my progress and mention if I encounter any difficulties or if the issues are easier than I thought it would be.

Lab 10: NPM Package Release

Alexander Samaniego — Fri, 25 Nov 2022 04:38:37 +0000

This week in my open-source course (DPS909), for our last lab, we were asked to publicly release our static site generator (SSG).

Release Process

The package registry I choose to release my project on was npm.

To add my package to the registry I essentially just followed this guide. I had already done most of the steps, all I needed to do was create a npm account on the website then use npm publish to add the package to the registry. However, I still needed to create a release for my project before using npm publish.

To create the release I used the command npm version <version number>. This updates the version number in package.json and tags the release. I then used the command git push --follow-tags to push the tags to the GitHub repo. Once the release is tagged and pushed to GitHub, then the command npm publish can be used to publish the package to the registry

These steps are repeated for every update to the package.

This process was rather simple as I had already completed most steps while creating the project. The tricky part was not realizing the command npm version <version number> also tags the release. So I was manually attempting to tag the release and getting errors telling me that the tag already exists. This had me stumped for bit until I realized it was because the command also adds the tags.

User Testing

I had another student in the course test my npm package on their local machine. The only issue encountered was during the setup process. Their machine didn't recognize the ssg command that I used for the package. So I had to adjust the instructions to have the package be installed globally. I changed npm install ssg-cli-tool to npm install -g ssg-cli-tool. Once that change was implmented and the user installed the package globally, it worked as intended.

The Final Release

Here is the final package release: https://www.npmjs.com/package/ssg-cli-tool

To install this package, in the terminal input the command:

npm i -g ssg-cli-tool

Then run it using on a text or Markdown file by using this command:

ssg -i <filepath of txt/MD file>

Follow the instructions in the README.md file for more options.

GitHub Repo: https://github.com/alexsam29/ssg-cli-tool

DPS909 Blog: Internal Code Reviews

Alexander Samaniego — Sat, 19 Nov 2022 21:14:25 +0000

As part of the Release 0.3 project in my open source course (DPS909), I was asked to continue my learning progression from Hacktoberfest by performing internal code reviews on pull requests (PR). "Internal" in this case means a PR in a project repository that is maintained by the class.

The project I chose was Telescope, which is an open source web server and client application for aggregating and presenting a timeline of Seneca's open source blogs.

Code Review 1

I decided to review PR #3768. This PR addresses an issue in the sign up process where the Blog/RSS URL form cannot differentiate between a blog URL and a feed URL, as described here.

To review the code, I checked out the PR on my editor and ran the app on my machine. I followed the testing steps specified in the PR. I also purposely messed up some steps to see how the program would react with the changes. The changes appeared to work as I could input a Blog URL and a feed URL when signing up; I could complete the sign up with the form able to recognize a Blog URL and a Feed URL.

One of the previous reviews of the PR commented with a concern with the backend breaking if a user enters a Feed URL instead of a Blog URL. So I tried to investigate this myself. As I explained in this comment, the current PR changes prevent a function that specifically uses a Blog URL from being called. I also noticed the Blog URL being used when making a call to the database. However, this should also not break the backend because the call is just made to store information in the database.

Code Review 2

For the second code review, I reviewed PR #3769. This review was a little simpler, as it was a a UI change to the top navigation bar of the web page. The changes to the files included CSS adjustments and a new button at the top right of the page. The only feed back I could give was in this comment I left. I suggested to match the top nav bar with the side nav bar that appears when a user scrolls down; mostly for UI consistency.

Conclusion

Doing these code reviews, I realized that it was good to review all types of PRs no matter the complexity. I spent a lot of time trying find complex ones but even the most miniscule, like a UI change/addition, needs input from multiple people before being approved.

DPS909 Blog: Internal Pull Request

Alexander Samaniego — Sat, 19 Nov 2022 09:50:46 +0000

As part of the Release 0.3 project in my open source course (DPS909), I was asked to continue my learning progression from Hacktoberfest by making another pull request (PR) to an internal project. Internal in this case means a project repository that is maintained by the class.

The project I chose was Telescope, which is an open source web server and client application for aggregating and presenting a timeline of Seneca's open source blogs.

The Issue

The issue I chose to work on was issue #3607. This issue described a bug that was occurring during the sign up process when the user would input their Blog/RSS URLs to link to their account. The issue here is that the instructions state that the user can enter multiple URLs separated by spaces. But when multiple URLs are entered, the form throws an error and says it's an invalid URL. The user must get rid of the additional URLs and leave just the one.

The PR

PR: https://github.com/Seneca-CDOT/telescope/pull/3766

Let me just get one thing clear about this PR. It may only say that 1 change and 1 deletion occurred, but it was not as simple as the number of code changes make it seem. This was probably the most frustrating issue I've worked on so far in this course.

Problem 1

The frustration began even before working on the issue. I had trouble setting up the development environment. I followed the environment setup documentation exactly as described and I still could not run the backend or frontend of the application locally on my machine. A day was wasted going through the steps over and over again hoping it would work.

I then turned to the Telescope Slack channel hoping someone could help diagnose my problem. My course Professor noticed that it looked like Docker was running out of resources when trying to run the app. Telescope uses Docker to deploy all the different parts of the app. Based on that advice, I looked at every obvious resource like CPU, RAM and disk. I had over 10 GB of free space before attempting to run the app, but I noticed that Docker took up all that space and that's when the app build broke.

So obviously the problem was low disk space, much to my annoyance. I was told that Docker takes up a ton of disk space. I moved the Docker image file to another disk on my machine and that's when I was able to build and run the app... only took a couple of days.

Problem 2

The second problem I encountered was just learning how the entire application worked. I've never worked with Telescope before so everything was new.
I was already familiar with part of the tech stack used, but just the sheer size of the application was intimating. Trying to follow how the code was executed was also frustrating as I would often lose myself within all the files.

Eventually, I was able to somewhat grasp how the sign up process worked. So I decided to start working on the issue at hand.

Problem 3

The third problem I had was figuring out where the bug was originating from. I found the component used for the validating the Blog URL in the sign up form (RSSFeeds), so I started debugging there.

I had no idea why the error kept appearing after inputting more than one URL. I experimented with every 'validating' and 'error' variable in the component to see if something changed. The file was covered in console.log in my attempt to find the source of the bug.

I then noticed that if I commented out an error check there would be no error with multiple URLs and they would be parsed correctly; as I described in this comment.

However, one of the Telescope admins suggested I keep the error check and guided me to look elsewhere in the project. So I still didn't find the origin of the bug.

Problem 4

This problem was due to the fact that I did find the origin of the bug as I described in this comment. However, I could not implement the solution I had come up with because I could not find a way to convert input text to an array while still being validated by the form validation schema. I had experiment with what seems like every possible solution, but could not get past the error that the validation schema would throw. I even tried adjusting the validation schema to accommodate the array, but nothing.

The Solution

After many hours of frustration with not being able to implement the original solution that I thought of, I noticed that the Channel URL section of the sign up form uses the same RSSFeeds.tsx component and a similar validation schema. Oddly, the Channel URL input does not have the same bug when inputting multiple URLs.

As I described in more detail in my PR, this was because the Channel URL is not validated as a URL. It was only validated as a string so it could accept multiple URLs. When it's validated as a URL any space in the string automatically flags it as an error, which is why the bug existed.

So I made sure to match the Channel and Blog URL validation schema. Just doing this one simple change completely fixed the bug.

Conclusion

I feel this PR taught me how to deal with frustration and taught me the importance of working with others on GitHub and Slack. Without guidance from other people I probably would have given up because I would have thought this was out of my skill level. The solution may have been simple, but the process to get there certainly was not.

DPS909 Blog: External Pull Request

Alexander Samaniego — Sat, 19 Nov 2022 06:18:58 +0000

As part of the Release 0.3 project for my open-source course (DPS909), I was asked to continue my learning progression from Hacktoberfest by making another pull request (PR) to an external project.

Ideally, I would have continued working on the project I had already contributed to during Hacktoberfest because I would already be familiar with. But these projects currently didn't have many open issues so it was difficult to find one that wasn't assigned already.

I was recommended to take a look at this project called the Astro Reactive Library. This repository builds components and architecture for projects that use the Astro framework for their reactive user interfaces.

The challenge with this project was that I never even heard of the Astro framework before this. I had no idea what it was and I would have to learn the very basics of the project before even thinking about solving an issue. Luckily, the learning process went smoothly and I was able to get a quick grasp of how the Astro framework works and how the components in the project build UI components.

The Issue

So after this learning process I felt comfortable looking at issues and determining which one I could tackle. I took a look at issue #140 which was related to the components used to create forms. To summarize, the way they assigned the id attribute of the <input> tag the same value as the name. However, the project owner believed that this would cause issues since they use IDs as selectors, so the id attribute needs to be unique. The ideal solution was to create an id attribute that is not the same as the name attribute by making a function that creates a Short Unique ID (UUID). The UUID should be prefixed with arl and assigned that as the id value for every <input> tag.

The PR

PR: https://github.com/ayoayco/astro-reactive-library/pull/182

My idea to fix this issue was slightly different than the suggested solution. Instead of creating a new function to generate the UUIDs, I found an existing NPM library that does exactly what is needed for this issue. It's called the Short Unique ID Generating Library. I added the library to the project. Now any time I need to generate a UUID, I just import the library to the file and assign a UUID like so:

const uid = new ShortUniqueId({ length: 9 });
const id = uid();

The next step was to add id properties to form-control and form-group and assign them with UUIDs so every time the component is created, it will have a unique ID. I added the property, assigned it a UUID in the constructor, and made a get function for the property.

I then found every instance where the id attribute in an HTML tag is assigned the same value as the name attribute. I also changed all <label> tags to use the associated id value for their for attribute.

The PR went well, the project owner only asked me to assign the <FormGroups> component a UUID since I had missed that originally.

Conclusion

This was step above the PR requests I made during Hacktoberfest as I mainly stayed working with web frameworks I was already familiar with. With this PR, I had to teach myself the basics of Astro and figure out how individual components are made using this framework.

DPS909 Blog - Lab 9: Continuous Integration

Alexander Samaniego — Fri, 18 Nov 2022 16:53:16 +0000

This week in my open-source course (DPS909), we were asked to add Continuous Integration (CI) to our static site generator (SSG).

This continues the work we did in lab 8 when we added testing. CI is a method where you can build and run tests automatically whenever anything is pushed to the repo, or a new pull request is made.

GitHub Actions CI Workflow

To setup CI in my project, I created a GitHub actions workflow. I followed this guide which shows how to build and test a Node.js project using GitHub actions workflows.

The YAML file I created for testing looked very similar to the example template given in the guide. The only thing I had to change was the operating system the workflow jobs run on. I changed it to run on Windows instead of the default Linux/Ubuntu environment. This was because I originally did my tests on my local Windows machine, so the snapshots taken by my tests use CRLF instead of LF for line endings. So just to avoid any testing errors coming from a windows environment, I changed the workflow job environment to match.

Adding Tests to Another Repo

PR to another repo: https://github.com/cychu42/staticSiteCon/pull/21
My partner's repo and testing setup was very similar to my own. The main difference was that they used multiple testing files which kept things more organized. In hindsight, I probably should've done the same thing to keep things cleaner.

They pretty much covered all areas of their program with their existing tests. I just added tests to their MD parser that was similar to tests they added for their text parser. I did this just to make sure testing for both parsers are consistent.

Conclusion

Now that I know how to add CI to my project, I feel like it's a must to add it to any new project I create since it makes testing easier. You don't have to worry about accidently merging anything that will break the code in main.

DPS909 Blog - Lab 8: Testing

Alexander Samaniego — Fri, 11 Nov 2022 22:17:53 +0000

For this week in my open-source course (DPS909), we were asked to continue working on our static site generator (SSG) and add automated testing to the project.

The Testing Framework

The testing framework that I chose for the project is Jest. Jest is a testing framework originally developed by Facebook for React UI testing. However, now it's its own tool that is used for any type of JavaScript project, including Node.js. I mostly chose it because of it's snapshot capabilities that allow you test whether UI elements on a page change unexpectedly.

Setup

In order to setup the framework in my project, I followed the documentation on the Jest website.

First, I installed Jest in my project by using the command:

npm install --save-dev jest

Then I created a test folder with a file called test.js that will contain all the testing code. For the initial setup, I used a basic test that had nothing to do with the source code:

test('adds 1 + 2 to equal 3', () => {
  expect(1 + 2).toBe(3);
});

Finally, I added the following bit to package.json:

{
  "scripts": {
    "test": "jest"
  }
}

I then used this command to start the testing process:

npm test

Should everything be installed correctly, this will be the output in the terminal:

PASS  ./test.js
✓ adds 1 + 2 to equal 3 (5ms)

Writing Test Cases

I initially had trouble coming up with test cases because I've been so accustomed to just running the code manually and testing it myself. I don't have much experience with automated testing so this was a new experience. I also wrote the source code to show error messages should something go wrong when manually testing. Coming up with ways to automate testing was the tricky part.

I thought I should test something simple. So I made test cases all the functions in Utils.js. These functions are small but crucial functions that verify things like file and directory existence.

In order to test the main functionalities of the project, I decided to create tests for HTML file generation and Index page creation. I tested the functions HTMLfile() and indexPage() that I had made for this purpose in create.js. I used Jest snapshots to take initial snapshots of the UI elements in the HTML pages created. Future tests will compare the UI elements against the snapshots to make sure nothing has changed. I tested Markdown to HTML file creation, txt to HTML file creation, and index page creation. To make these tests work with snapshots, I had to adjust the function to return a value. Originally, these functions returned nothing. So I added a return statement that returned the generated HTML body.

Lessons Learned

While writing and coming up with tests cases, it became increasingly clear that my source code was not written with testing in mind. I had to make some adjustments to make some tests work, but I feel like I should have even more test cases had my code been initially written with testing in mind.

So from now on, I will always include automated testing in my code and make sure that I write my code with testing in mind.

Automated testing commit: https://github.com/alexsam29/ssg-cli-tool/commit/dff551f7690bf7caaa3db6902b934145df401853

DPS909 Blog - Lab 7: Static Analysis Tools

Alexander Samaniego — Fri, 04 Nov 2022 00:28:38 +0000

For lab 7 in my open-source course (DPS909), we were asked to implement static analysis tools into our static site generator (SSG).

Static analysis tools help us to maintain quality in the source code by fixing common coding errors and formatting the code to make it much more readable.

Source Code Formatter

For the source code formatter, I chose to use Prettier. Prettier is an opinionated code formatter that can be integrated into most of the popular editors/IDEs. I chose this because Prettier works well with JavaScript, which is the language I use for my SSG. I am also familiar with Prettier as I have used the Visual Studio Code extension before.

Project Setup

To setup Prettier in my project, I followed the npm installation guide on the website. To summarize, I ran a npm command (npm install --save-dev --save-exact prettier) in the terminal to install Prettier packages in the project. Then I created config(.prettierrc.json) and ignore(.prettierignore) files to let the editor know the project uses Prettier and to let it know what files to ignore. Once the packages are installed and the config and ignore files created, you can run npx prettier --write . on the command line to format all files in the project.

Editor Setup

I use Visual Studio code as my editor of choice. Prettier offers a VS Code extension that you can download to make using Prettier easier. I downloaded the extension from the extensions sidebar. Prettier docs also has a editor integration guide showing how to integrate Prettier into other editors/IDEs.

Git Hooks

I also installed Git Hooks to make sure that all commits are formatted properly. Again, I followed the same installation guide and ran the following commands to install packages:

npm install --save-dev husky lint-staged
npx husky install
npm set-script prepare "husky install"
npx husky add .husky/pre-commit "npx lint-staged"

Then I added this to my package.json file:

{
  "lint-staged": {
    "**/*": "prettier --write --ignore-unknown"
  }
}

Now, all commits will be formatted properly.

Linter

For the linter of choice, I decided to use ESLint. I chose ESLint for the same reason as Prettier, I already had experience using the VS Code extension and it works for JavaScript.

Project Setup

To setup ESLint in my project, the process was very similar to installing Prettier. I followed the installation guide on the website. I first used this command, npm init @eslint/config to install packages and create a config file (.eslintrc.js) that will contain rules used to check the code. Once this is done, you can then run npx eslint yourfile.js to check and fix errors on that specific file.

After installing ESLint, I also had to install eslint-config-prettier to make sure ESLint and Prettier work well together. This turns off all ESLint rules that are unnecessary or might conflict with Prettier. I followed this installation guide to install it.

Editor Setup

Much like Prettier, ESLint can also be integrated into the editor. Since I use Visual Studio Code there is an extension that is available for download which will make running ESLint easier. For other editors, this editor integration guide on the website will show you how to integrate ESLint with most of the popular editors.

Source Code Changes

Running Prettier on my source code didn't change a whole a lot. The main thing that changed was a lot of spacing issues. Indenting was reduced to make more code visible at once without having to scroll horizontally.

ESLint made a lot of changes, mainly to variable declarations. I defaulted to using var to declare variables, however, ESLint changed my declarations to use let instead to help reduce the chance of errors as described here. It also changed variables that were not reassigned to use const instead of var. This is because it helps the reader to understand that the variable is never reassigned and improves maintainability as described here.

Conclusion

This lab showed me that you can add source code formatting and error checking directly to projects. Before I had used extensions for this purpose and never directly implemented it by installing it into the project. Now because of this lab, I know how to directly implement static analysis tools into future projects to make sure my code is readable and follows good coding practices.

Here are all the changes made to my project: https://github.com/alexsam29/ssg-cli-tool/commit/bcde670fb80c102fcdd37d4febdd39b99b4b7ca1

Hacktoberfest Recap

Alexander Samaniego — Sun, 30 Oct 2022 22:28:23 +0000

Well my first ever Hacktoberfest is now over. It was stressful at times, but I think that was mostly just because it was my first one. The main challenge throughout the month was finding issues to work on. Since this is a global event, you had to be quick and/or lucky to find a good issue that was both challenging but yet, not overwhelming for a beginner like myself.

Overall, I made four pull requests (PRs) over the course of the month. Which can be read about here:

I think I made good learning progress with my PRs. The first PR was just me getting into the swing of things and getting used to contributing to a public open-source project. The second PR is where I actually got to put some coding skills to the test by fixing an existing bug in a project. It gave me some experience researching potential fixes to bugs that weren't my own creation. The third PR allowed me to continue with my work on the same project and gave me the opportunity to enhance a feature of the project. It was challenging as I had to brainstorm potential solutions that would give me the enhancement I was looking for. The fourth and final PR, while simple coding wise, gave me experience exploring different types of projects and tech stacks that I probably would not have explored had I not been participating in Hacktoberfest. The fact that it was challenging to find good issues to work on forced me to explore many projects to create a new issue myself. This gave me a good learning experience as I had to read and learn about many types of tech stacks in order to get a good understanding of the project, so that I could create an issue in the repository.

Overall, Hacktoberfest gave me the confidence to put myself out there and not to be afraid of contributing to open-source projects. No matter your experience level or how easy or difficult an issue is, every contribution is a learning experience.

Hacktoberfest Week 4: Finding and Creating Issues.

Alexander Samaniego — Sun, 30 Oct 2022 21:51:52 +0000

For the fourth week of Hacktoberfest, I searched for and created my own issue in a repository, rather than finding an existing issue.

Project Recap

The project I chose is a rather simple project. It's a web application designed to test and practice typing skills. User's can take and practice typing tests and the results will then be saved locally.

The Issue & Pull Request

Initially, I tried to find an issue that was more challenging coding wise when compared to last week. However, I struggled to find an issue that was challenging and realistically do-able with my current skill set this late into Hacktoberfest. The problem was that I mainly encountered repositories that weren't real open-source projects and were created solely for Hactoberfest pull requests (PRs). When I did find an issue that I wanted, I was not quick enough to comment as somebody else was already assigned the task. Due to this, I spent way too long just searching GitHub for issues.

The Challenge

In order to still give myself a challenge, I decided to create my own issue instead of relying on ones already made. To do this, I had to find, fork, setup, run, and explore many (many) projects to find potential bugs and or features I'd like to add. I had to learn many tech stacks and read countless of documentation pages to get these projects to run and know how they work.

This is what made this week's PR much more challenging than the previous weeks because before, the bug fixes and feature requests were already made by someone else. All I had to do was find a way to fix/add it. Now, I had to do the bug finding and thinking for new features. There was that additional 'rookie fear' of creating new issues because you get the feeling that others will judge you for something; like potentially missing something in the documentation or having your feature request be seen as 'dumb' by others. There were times where I thought I had found a bug, but it was just an error with setup on my part. Or times where I'd suggest an issue, but the project maintainers would deny or suggest something else.

Once I got past the most challenging part and got an issue that I created assigned to me, I got to work. The issue I got assigned was to add a new table in the Typing Test project that showed the average speed and time of all typing tests taken. I'll be honest, this issue wasn't too challenging. I added the new feature by calculating average times in the JavaScript files and adding a new table below the existing one using the DOM. I created the PR and got the feature added to the project with very little adjustments needed.

Conclusion

While the actual coding was not as challenging as I had initially hoped, I'm still glad I got this experience because the challenge of creating a new issue myself gave me a chance to explore many projects that I probably would not have looked at before. I gained knowledge on different tech stacks and it gave me new found confidence to not be afraid to create new issues in open-source projects.