DEV Community: mpa-LHutchinson

Week 15: Release 0.4 release

mpa-LHutchinson — Wed, 11 Dec 2024 21:44:04 +0000

Introduction

Well, this is it. My final blog for DPS909. What a journey this has been. Not only did I get the chance to develop my own open source project, but I got the opportunity to interact with several open source projects and commit to working on them. This is one of the few courses I had this semester where it truly felt like what I was working on mattered, and I am forever thankful. For this final release, I was tasked with working on another open source project. There were several option of what I could do, but after looking through my options I decided to go with fixing a family of bugs on an open source project I've worked on before. That open source project is wordlecheat, and here's the link to its repo:

https://github.com/bodonovan/wordle_cheat

Why this project?

I choose to work on this project again for a couple of reasons. For one, the project was just really interesting to me and I wanted to learn more about it. Another reason is there were a couple of bug related issues on the repo that needed to be worked on, and I wanted to help with it as much as I can. Finally, my previous interactions with the repo manager have been quite nice, and I even introduced him to hacktoberfest. One more reason is this was the only person to get back to me of all the repos I contacted. My last blog post details that due to time constraints and personal things in my life I was not able to work on the desired project I wanted, since the repo managers never responded to me. So this, while not being as challenging, is still a project to dedicate my effort to.

A quick recap

If you don't know already, wordlecheat is a project that allows you to "cheat" at the game wordle. Wordle is a game where you need to guess a 5 letter word by entering letters. If you're wrong, the game will give you hints about your letters each turn. The game can either tell you you guessed the right letter in the right spot, the letter is in the word but not in the spot you guessed, or the letter isn't in the puzzle at all. Below is an example of a worlde game:

In this example, each guess gives more hints as to what the word is. A green letter means the letter is in the right spot, a yellow letter means it's somewhere in the puzzle but not on that spot, and a grey letter means it's not in the puzzle at all. This project allows you to cheat at this game by logging your progress and searching through a large dictionary of 5 letter words, like so:

My first issue that I worked on all the way back in October for this project was to simply find a new dictionary, since the previous one didn't have enough 5 letter words in it. For this release, I decided to delve into the source code and try to tackle as many bugs as I could, and here I will go over them.

Issue 1

https://github.com/bodonovan/wordle_cheat/issues/2

For this issue, I was tasked to fix a bug that made the "in" button not handle duplicate letters properly. The in button is meant to track letters that are in the word but not in the position the user guessed, for example if I the position was 2-A then the program would filter for words that have an A in them, but not in the second position. However, if you entered the same position letter combo multiple times it would log multiple times, which was unnecessary. For my fix, I had to look through the source code and understand where the in button was being tracked and adding letters. Once I found it, I added a check to see if it was already stored in the list. Finally, it would print out an error message if the user tried to do the same combo multiple times, and the error message had the same style as the rest of the code.

# add a rule that a letter appears in the target word, but not in the specified position
def add_in_letter(letter, posn):
    posn = int(posn)
    if letter in in_letters:
        # only add the position if it's not already in the list
        if posn not in in_letters[letter]:
            in_letters[letter].append(posn)
        else:
            print("Same letter and position so ignore")
    else:
        in_letters[letter] = [posn]
    add_rules_to_hist()

Finding and trying to understand this bug is what made this issue difficult, but once I figured it out it seemed pretty simple. I made a pull request but as of writing this blog it has not been merged yet. I'm not too worried though since the repo manager is usually slow to respond anyway.

https://github.com/bodonovan/wordle_cheat/pull/8

Issue 2

For this issue, I needed to fix a bug that caused the input field for letter to not be focused. At first I didn't understand what this meant, but after some research I found out the letter field would not be selected upon starting the program, so the user would have to manually click on it each time, which was inconvenient. In order to fix this bug, I had to understand how the window was created and the input fields were generated. It took some research but I was able to make the input field focused so the user does not need to click on the letter input every time. Once I made a pull request for this issue, it actually did get merged which I'm glad for.

https://github.com/bodonovan/wordle_cheat/pull/9

Interacting with the community

At first I was nervous interacting with the repo manager as it seemed they weren't maintaining the project anymore. But after simply asking them for permission to touch up on the remaining bugs in their project, he allowed it and was even happy to see me continuing his project. They are a bit slow to respond to my questions but I appreciate them nonetheless because they gave me the opportunity to work on a really interesting project. (I even use the program to cheat at a few games of wordle myself!)

Conclusion

In conclusion, this project and this whole course for this matter has taught me so much about working on open source projects. I'll be able to say that I've contributed to these projects on my resume and it'll help me get a good career in the future, since open source projects are becoming more and more popular. Thank you for joining me in this journey, as this will be my final blog for this course. Peace!

Week 14: Release 0.4 progress

mpa-LHutchinson — Sat, 07 Dec 2024 04:12:12 +0000

This blog post is being made to let everyone know that unfortunately, none of the repository managers I reached out to got back to me. So I'm gonna try extra hard over the weekend to find at least 1 issue, preferably multiple, that I can work on. It's unfortunate that I wasn't able to make progress but given the extra schoolwork and other personal things going on in my life it's more understandable. By Wednesday I will have completed my pull requests, just like the previous releases.

Week 13: Release 0.4: Planning

mpa-LHutchinson — Fri, 29 Nov 2024 23:47:38 +0000

Introduction

This is it, the final stretch of DPS909. I've learned so much from this course and I've had so much fun on top of it. For my final release, I intend on committing most if not all of my issues into one of the open source projects that I've worked on throughout hacktoberfest and release 0.3. Of the projects that I've worked on, there's a couple that really caught my eye and I would like to continue working on. In this blog, I will go over each project and what makes them so interesting.

Maverick-Ai

https://github.com/Swifty9/Maverick-AI

This is a project that I've worked on before, where I created a 404 page. This is a really interesting project, it's able to take a message that a user types in and determine how "inappropriate" it is, by looking for offensive language. It also has a nice layout, using react and tailwind to create a good user experience.

As far as issues go, there are many options for this project. I could continue to working on frontend elements or I could challenge myself my looking into the backend AI aspect. Either way, I'd be happy to contribute to this project.

Now that I've looked through all the other open source projects that I've worked on, I think this is the one I will work on for release 0.4. Every other project I've worked on is either inactive or they aren't projects I'm excited to return to for one reason or another. But this project is still being maintained, and I have many options for issues to work on.

Moving forward

At the time of writing this blog, I intend to work on the project described above. If those plans change, I will keep everyone updated in my next blog post. Next week I will hopefully have 3 different issues from this project completed.

Week 12: Lab 9: Packaged release

mpa-LHutchinson — Sat, 23 Nov 2024 01:07:19 +0000

Introduction

In this weeks lab, I learned how to package my project and put it out there for others to be able to use. This allowed me to publish my package on npm and anyone can now access and use it on their own computer without having to clone my projects repository. In this blog, I will be going over how I managed to do this and the challenges I faced along the way.

Which release tool and package registry did you choose? Provide links to everything you mention.

For this lab, I used npm as my packaging tool for my project. This is because my project uses node, and npm is by far the most popular packaging tool for node projects. Here's the link for npm and how you can get started contributing packages to the registry:

https://docs.npmjs.com/packages-and-modules/contributing-packages-to-the-registry

What was the process for creating a release? Be detailed so that other developers could read your blog and get some idea how to do the same.

The process of creating a release involved first involved me modifying my package.json file to include a name and version of my project. I would update the version with this command:

npm version patch

This would update the version from 0.0.1 for example to 0.0.2, and this is what I would do until I was comfortable with my version of the project, in which I would run

npm version major

Which would upgrade to version 1.0.0. But before that I still had a lot to add.

I created my first package, by running

npm pack

This would create a .tgz folder where the package could be uploaded. Then I would run

npm login
npm publish

In order to login to npm and publish the package. However, I realized there is already an npm package with the name auto-readme. So I just named the package auto-readme-liam and then I could publish it. This is how my first version of the package, 0.0.1 was uploaded. But it wasn't over, as there was more I had to add.

I needed to add this to my package.json:

"bin": { "auto-readme-liam": "./index.js" }

This would allow the user to run a script that runs the program. I also added this to the top of my index.js file:

#!/usr/bin/env node

There were some other issues, but I'm gonna go over them in the next question since it's more fit there. Once I fixed these issues however, I updated my README file to include instructions on installing the package.

What did you learn while doing your release? Did you have any "aha!" moments or get stuck?

I actually learned something about my project that was an issue. When I was testing my package release, I realized the README file that my program was supposed to generate was not generating in the proper directory. This, I figured out, was because my project would use _dirname in some parts, for example this:

var generatedFilePath = path.join(__dirname, readmeFileName);

However, _dirname in this case would end up being the global node_modules folder, since it was installed globally. To fix this, I replaced all instances of _dirname with process.cwd(), which refers to whatever directory the script is being executed in. I tested this and updated my package, and luckily it worked now. I'm glad I caught this problem, and if I ever make similar projects in the future I'll remember to do this.

How much did you have to alter your code, files, build, etc. to use the chosen package format and registry?

As you can see from the above questions, I didn't have to add a ton of new changes to my code. I just had to change around 5 lines in my index.js file and I had to add about 3 new things to my package.json file. The simplicity of node.js allowed me to upload my project to node easily.

How did the User Testing session with your partner go? Describe what it was like, where they got stuck, and how you corrected the problems.

Luckily testing this with a partner went pretty well. The only thing I needed to change was the instructions in my README for how to provide an api key, as the command to do it was slightly different in command prompt compared to the visual studio terminal for example. Once I found this out, I updated my README to give the user more clear instructions.

How do users install and use your project now that it has been released? Provide links and some instructions.

These instructions come straight from the README file of the official package release of my project. If you'd like to check it out, here's the link:

https://www.npmjs.com/package/auto-readme-liam

First, install the package:

npm install -g auto-readme-liam

Then, provide your API key as an environment variable:

set GROQ_API_KEY="<YourAPIkey>"

Once you do this, run this command:

auto-readme-liam

And now you're set! You can also run this command for help:

auto-readme-liam --h

Week 12: Release 0.3 pull request 2

mpa-LHutchinson — Thu, 21 Nov 2024 02:05:22 +0000

Introduction

This week I got my second and final pull request for release 0.3 merged. For this pull request, I had to fix a bug that was happening in a command line tool project. Working on this project was interesting as it was the first time I had to fix a bug, rather than adding a new feature to a project. Given the unfamiliarity with the project itself, completing this issue was the most challenging of all of them so far. I had some troubles configuring the project, to the point where getting the project to work was a harder challenge than fixing the issue.

The issue

Here is the link to the issue:

https://github.com/objectionary/eoc/issues/382

For the issue, I was tasked with fixing a bug with the command line tool. One of the commands available was deleting a directory and its contents. However, even after the successful deletion of a directory, it would print out a message saying the directory doesn't exist.

$ mkdir .eoc
$ eoc clean
The directory .eoc doesn't exist, no need to delete

After reading this, I figured the issue had something to do with the logic of the commands code. I still needed to get the command line to work, which required me to change some permissions in my visual studio. But after getting it to work, I looked in the file that had the code for the clean command.

I eventually found that the logic for deleting a directory was being executed before the check for the directories existence was executed, thus causing the program to always check a nonexistent directory. To fix this, I moved the deletion logic to only execute within the check, so it only executes if the program detects that the directory exists.

Completing the pull request

Once I fixed the bug, I created a pull request, explaining in it why the bug was happening and showing my fix. What scared me at first was when the github actions ran tests on the pull request, and they failed. But the maintainer still approved and merged my fix, and after checking other pull requests I realized the same job would fail on them as well, suggesting that workflow might have an issue and not my fix.

https://github.com/objectionary/eoc/pull/383

Conclusion

Overall I am glad I was able to complete my last pull request for release 0.3. With this blog being concluded, I have now finished release 0.3. Overall I am happy I got to work on more issues since hacktoberfest was my favorite assignment of this class. In the future I will be looking to participate in more events like hacktoberfest in order to expand my skills and help with more open source projects.

Week 12: Release 0.3 pull request 1

mpa-LHutchinson — Wed, 20 Nov 2024 21:04:46 +0000

Introduction

This week I got my first pull request for release 0.3 merged. For this pull request, I had to design a page on the frontend of a site. This project actually interested me when I looked at it, basically it's a tool that detects if a message has any "profanity" or otherwise offensive language in it, using AI. The layout and design of their site was very visually appealing as well, taking advantage of react and tailwind CSS. I haven't worked on designing a full webpage for any of my hacktoberfest pull requests, so I thought this would be a fun and challenging issue to tackle.

The issue

Here is the link to the issue:

https://github.com/Swifty9/Maverick-AI/issues/57

For the issue, I was tasked with creating a 404 page for the website, IE. the page that displays if the user tried to navigate to an invalid route. This wasn't just a simple 404 page with just an error message, it needed multiple requirements, including a helpful error message, links to other sections of the site, animations, and an overall consistent design with the rest of the site. It required me to follow the sites design while also making it stand out as a proper 404 page. Needless to say I had a lot of fun working on this issue, since I like the project. At the end of the day I made a page that looked like this:

Completing the pull request

Once I designed this entire webpage, I created a pull request and informed the maintainer that I completed my issue. They were happy with my work and merged it with no issue. Here's the link to the pull request:

https://github.com/Swifty9/Maverick-AI/pull/88

Conclusion

Overall I am glad I was able to complete one of my two pull requests for release 0.3. This pull request was more challenging than the ones I worked on for hacktoberfest, as I had to not only design an entire page to fit a websites design, but it had to feature some new content. This pull request gave me more much needed practice working with react applications, and I am thankful for that. One more to go!

Week 11: Lab 8: CI with github actions

mpa-LHutchinson — Sat, 16 Nov 2024 03:27:25 +0000

Introduction

For this weeks lab, I was tasked with implementing Continuous Integration into my release 0.1 project, using github actions. This has allowed my tests to be ran with every push and pull request to github, ensuring the most recently committed version of the project passes the tests. In this blog, I will be going over how I implemented CI on my project and added a test to another persons project in order to test their CI.

How did you set up your GitHub Actions CI Workflow? What did the YAML for this workflow look like?

To setup github actions, I went to the actions tab and choose to make a new workflow for a node environment. It automatically generated an entire yml file that runs the tests. There was only one issue which was I needed to add an environment variable to the yml file and my github environment. Once I did this, my yml file looked like this:

# This workflow will do a clean installation of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-nodejs

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    env:
      GROQ_API_KEY: ${{ secrets.GROQ_API_KEY }}

    strategy:
      matrix:
        node-version: [18.x, 20.x, 22.x]
        # See supported Node.js release schedule at https://nodejs.org/en/about/releases/

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

How did your partner's repo and testing setup differ from yours? What was it like writing tests for a project you didn't create?

My partner for this lab used python for their project, so they needed to configure a yml file that ran python dependencies. And the testing framework for python was quite different from node, so it was challenging trying to understand how the tests worked. Instead of making it too complicated for myself, I just added a test case that was similar to one that already existed, except it just checks for a different case. The original test looked like this:

class TestFileInput(unittest.TestCase):
    @patch("sys.stdout", new_callable=StringIO)
    @patch("sys.stderr", new_callable=StringIO)
    @patch("sys.argv", new=["docbot.py"])
    def test_no_files_provided(self, mock_stderr, mock_stdout):
        # Run the main function with no files provided
        with self.assertRaises(SystemExit):  # Expecting the program to exit
            main()

        # Check that the error message about missing files is printed to stderr
        error_message = mock_stderr.getvalue().strip()
        self.assertEqual(
            error_message, "error: the following arguments are required: file"
        )

This test would check if the user tried to run the program (docbot.py) without providing a file for it to feed to the LLM, and if the appropriate error would occur. I took this test and used it to create my own:

class TestInvalidFileInput(unittest.TestCase):
    @patch("sys.stdout", new_callable=StringIO)
    @patch("sys.stderr", new_callable=StringIO)
    @patch("sys.argv", new=["docbot.py", "nonexistentfile.py"])
    def test_no_files_provided(self, mock_stderr, mock_stdout):
        # Run the main function with an invalid file provided
        with self.assertRaises(SystemExit):  # Expecting the program to exit
            main()

        # Check that the error message about missing files is printed to stderr
        error_message = mock_stderr.getvalue().strip()
        self.assertEqual(
            error_message, "Error: Source file nonexistentfile.py not found."
        )

This test would check if the user tried to provide a file that doesn't exist, and sees if the appropriate error message shows up. As of writing this blog, my partner hasn't merged my changes since he needed to go to bed, but I'm confident it will pass since it passed on my local machine.

What do you think of CI now that you've set it up for yourself?

Honestly, I like how CI is implemented through github actions. Not only does the UI feel user friendly and fresh, but it is a genuinely useful tool for checking that your projects tests pass automatically. I will make sure to take advantage of github actions in the future whenever I need to add tests to a project.

Week 10: Lab 7: Automated testing

mpa-LHutchinson — Sat, 09 Nov 2024 04:47:30 +0000

Introduction

For this weeks lab, I introduced a testing framework to my release 0.1 project, writing test cases for all the commands that were available. This included successful inputs of each command as well as well as their respective error cases if they had any. In this blog, I will discuss the testing framework I used, along with the troubles I had with making tests for this lab, since not everything ended up working out unfortunately.

Which testing framework/tools did you choose? Why did you choose them? Provide links to each tool and briefly introduce them.

The testing framework I choose for my project is jest, which I found from this list of popular node testing frameworks:

https://developer.okta.com/blog/2020/01/27/best-nodejs-testing-tools

Jest is a javascript testing tool that allows for the creation of easy yet powerful test suites. I choose jest because, since I was new to testing in javascript, I wanted to use one of the most popular tools available so I had as much available documentation on it as possible.

How did you set them up in your project? Be detailed so that other developers could read your blog and get some idea how to do the same.

Setting up node.js in a project is simple. First, you need to install it through npm

npm install --save-dev jest

Then, for simplicity, add a script in the package.json file of your project, like so:

"scripts": { "test": "jest" }
once you have this, you can run npm test and any files with the name "test" will have their test cases ran. It's recommended to keep them in a folder names tests or something along those names.

Next, to create a test suite, set it up like this:

`describe('index.js (nonLLMtests)', () => {

test('displays welcome message if only two arguments are provided', () => {
const output = execSync('node ./index.js').toString().trim();
expect(output).toBe(
'Hi! Welcome to Auto-ReadMe. For help, run this command: node index.js --h. Enjoy!'
);
});
};`

Here, "describe" creates a test suite, and "test" creates a test case. In the example, I test my basic welcome command by creating the proper arguments and "expecting" a certain output.

How did you handle LLM response mocking?

This is where I got stuck this lab, as I wasn't really able to figure out how mocking could work for my program. I tired using nock to create a mock HTTPS server, but no matter what I couldn't figure out a way to get it to create a request. So For the purposes of this blog, I couldn't handle LLM response mocking. I will figure this out in the future, so for now I just had my LLM related test cases use the real LLM.

What did you learn while writing your test cases? Did you have any "aha!" moments or get stuck?

As discussed in the previous section, I did get stuck on the response mocking and was unable to complete it for this lab. However, creating the other test cases made me realize that my program needs a proper configuration file where variables used across multiple files is defined (including the test cases). Doing this made changing the code for testing much simpler, and working with the code will be much easier in the future.

Did your tests uncover any interesting bugs or edge cases?

Interestingly enough my tests, once properly implemented, did not show any bugs or edge cases. When the tests were written properly, they gave the expected output with the proper input.

What did you learn from this process? Had you ever done testing before? Do you think you'll do testing on projects in the future?

In this process, I learned how to create tests with jest and how to best utilize them. I have done testing before, mainly with unittest in python, but I have never done it with jest in a javascript project. In the future, I will implement tests as long as the project warrants them, since the process of creating test cases is very long and tedious. But ultimately having them greatly helps the project and automates the process of finding problems/bugs with code.

Week 9: Lab 6: Static Analysis Tooling

mpa-LHutchinson — Sat, 02 Nov 2024 01:26:18 +0000

Introduction

For this weeks lab, I was tasked with adding some new features to my release 0.1 project. These included a CONTRIBUTING.md file, a formatter, a linter, and editor integration. Doing these changes gives users contributing to the project a useful guide, plus some tools that will help them commit clean, well formatted code. In this blog, I will discuss adding these changes to the project and answer questions related to the lab.

Which tools did you choose? Why did you choose them? Provide links to each tool and briefly introduce them.

For the code formatter, I chose prettier. This is because my project uses javascript as its main language, and I felt like it would be a simple setup. Here's the link for prettier: https://prettier.io/

For the linter, I chose ESLINT. I chose it because ESLINT is a very common linter for javascript code, and there's a lot of useful guides on setting it up. Here's the link for ESLINT: https://eslint.org/

How did you set them up in your project? Be detailed so that other developers could read your blog and get some idea how to do the same.

For prettier, the first step was to install it with npm:

npm install --save-dev prettier

Then, I added some files to my project. I added ".prettierrc", which contained some default formatting options for prettier. I also added a .prettierignore file which specifies which files and directories to ignore. For this project, I listed every file except for the two that should be worked on (index.js and ai.js). Finally, I added scripts in my package.json file so the user can run prettier from the command line.

For ESLINT, the first step was to install it with npm:

npm install --save-dev eslint

Then, I used this line to generate a configuration file for ESLINT:

npx eslint --init

Then, like with prettier, I created an eslintignore file that would ignore files that aren't being worked on. Then I added scripts to package.json so the user can run ESLINT on the command line.

What did the tools find in your code? Did you have to fix a lot of issues?

When using prettier, I noticed a bunch of indentation got fixed. I expected this, as the indentation of my project before was honestly very messy, which tends to happen with javascript projects. When using ESLINT, it actually found a variable that was declared but never actually used. This surprised me as I just assumed it was needed in the code. So I got rid of it. So thankfully there wasn't that much to fix according to the code formatter and linter.

How did you get the tools to run from the command line?

As discussed before, I added scripts to the package.json file which allowed the tools to run from the command line. They looked like this:

"scripts": {
    "format": "prettier --write .",
    "format-check": "prettier --check .",
    "lint": "eslint .",
    "lint-fix": "eslint . --fix"
  }

This way, if you do npm run, followed by one of the commands listed (for example npm run format-check), it will run that tool from the command line.

How did you integrate the tools with your editor/IDE?

To integrate the tools with my editor VScode, I installed the VScode extensions for prettier and ESLINT, and wrote a configuration file that would run the tools whenever you saved. To test these, I purposefully indented something poorly, then saved it as I watched prettier correct the indentation. To test ESLINT, I added an unnecessary variable, and ESLINT would highlight it as an error. But I wasn't done here, as I wanted to create a file that would automate this process for others using VScode. To do this, I created an extensions.json file that contained recommended extension for new users to install once they cloned the project.

What did you learn from the process?

In conclusion, this lab introduced me to some very helpful tools that I was able to use in order to make my project cleaner. I learned not only how to use these tools but automate the process in order to make it easy for myself and future developers of my project. At the end of the day, this project helped a ton with my understanding of making the contributing process better.

Week 9: Hacktoberfest pull request 4

mpa-LHutchinson — Wed, 30 Oct 2024 20:23:42 +0000

Introduction

At long last, I got my last pull request for hacktoberfest merged. For this last pull request, I wanted to find an issue that wasn't super challenging but was still more challenging than my previous pull request. I purposefully looked for a project that doesn't use my main language (javascript) and instead uses a different language. Additionally, I looked for a project that I wouldn't immediately understand at first. This issue I feel was perfect for my requirements. In this blog post, I will discuss this pull request as usual but at the end I will also go over 3 pull requests I worked on and (attempted) to get merged, but for one reason or another I didn't want to include them in my release 0.2 assignment.

The Issue

Here is the link to the issue: https://github.com/jessesimpson36/yamldifftool/issues/1

This project is a tool that compares 2 yaml files and writes their differences out to another file. Before I made any changes to the file, the output would always go to the file that the user specifies with the ---output argument. For the issue, I needed to introduce the option to write the output to stdout instead. This was already a bit of a challenge as the code was not immediately readable. But I only had to focus on what mattered: Where the output was going. And at the very bottom of the program I found this code:

with open(args.output, 'w') as outfile:
        yaml.dump(root_diff, outfile, sort_keys=False)

I knew this was what I needed to change. So after some research, I changed it to have a condition. If there was no output argument, it would print the output to "sys.stdout" (I had to add an import for sys at the top of the file)

if args.output:
    with open(args.output, 'w') as outfile:
        yaml.dump(root_diff, outfile, sort_keys=False)
else:
    yaml.dump(root_diff, sys.stdout, sort_keys=False)

I also needed to make changes to the argument parser so the default value is None. This way the condition would work. Once I did this, I got it to work.

Completing the pull request

After this fix, I created a pull request. The maintainer actually noticed an accidental change that I made, and so I corrected it and resent it. The maintainer was very nice about it and I was able to get my final hacktoberfest pull request merged! Here is the pull request:

https://github.com/jessesimpson36/yamldifftool/pull/5

Other Pull Requests

Before I end this blog, I'd like to talk about 3 pull requests I worked on over the course of October that for whatever reason I felt couldn't be included in my release 0.2 assignment.

https://github.com/TheBaljitSingh/Apna-Blog-Frontend/pull/2

This pull request was initially going to be used as my final entry for release 0.2. But after thinking it over, I realized I should find a different one. This issue required me to optimize an image on a blogging site so it would work with a mobile view. The issue also said I could add something else to the homepage. I optimized the image and added a login and signup button on the homepage. However, the maintainer asked me to remove those buttons so my pull request would just include the image optimization. While I do respect the maintainers decision, it was unfortunate since the image optimizing was easy and the buttons required me to think a little bit about how to make the user experience better. The PR was too simple, so I moved on to a different one.

https://github.com/noskofficial/noskofficial.github.io/pull/79

This was actually the first pull request I worked on, and I'm disappointed it didn't get merged. My task was to add some creative things to a homepage, which forced me to think carefully and work with the design elements and theme of the site. After adding around 5 new features to the homepage, I updated the pull request. Unfortunately, the maintainer to this day has not even responded, even though I tried to contact them. It's a shame because I worked harder on this pull request than any others and I would've loved to have it as the final entry.

https://github.com/One-Zero-Code/ngx-toastr-message/pull/19

This pull request I already discussed in my second blog about hacktoberfest. In summary, the task was too simple for me to consider using it given this was supposed to be my third pull request (I just had to update a README file with a couple of lines).

Conclusion

In conclusion, I really enjoyed hacktoberfest. It gave me the opportunity to contribute to several different open source projects and learn what's it's like to work with the maintainers and have my work put out there. It wasn't all perfect, I did have some troubles not only finding good issues to work on but also working with the project maintainers. I handled these issues respectfully, but at the end of the day some things just didn't work out. In the end, this was a great hands on experience of what open source is about: communication, collaboration, and openness. I'm excited to participate in it next year!

Week 8: Hacktoberfest pull request 3

mpa-LHutchinson — Sat, 26 Oct 2024 00:16:40 +0000

Introduction

This week I got my third pull request for hacktoberfest merged. As far as projects go, this one interested me the most as it was a program made for a specific purpose. The program is designed to "cheat" at the game wordle, a game that makes the user guess a 5 letter word by inputting letters one at a time. It "cheats" at this game by asking the user for an input and searching through a dictionary of thousands of 5 letter words that contain the letters guessed so far. This project was interesting, and I wanted to contribute to it in a meaningful way.

The Issue

Here is the link to the issue:

https://github.com/bodonovan/wordle_cheat/issues/3

For the issue, I needed to find a better dictionary for the project to pull from. The project had a dictionary containing hundreds of thousands of English words to pull from. The problem is that the dictionary did not contain enough words, and sometimes the program would not be able to find the correct associated wordle word. My task was to go online and find a better dictionary somewhere online, then update the code accordingly.

I managed to find a text file in an online repository that contained around 300k English words. For comparison, the old dictionary had around 200k words. I simply replaced the file, then ran the file "extract.py" which takes every 5 letter word from the dictionary and puts them in a separate text file. This file ended up having noticeably more words in it as a result.

Completing the pull request

Once I added these changes, I created a pull request and informed the maintainer that I added the change. The same day, the maintainers merged the pull request. I did have to ask them to make the repo hacktoberfest accepted, as they actually didn't know what the event was prior to this. So I'm glad I was able to introduce them to it, maybe they'll partake in it next year.

https://github.com/bodonovan/wordle_cheat/pull/4

Conclusion

Overall I am thankful I was able to get another pull request approved. This pull request was more challenging than the last 2 as I had to understand how the program worked and do some research into finding a proper new dictionary. But luckily I managed to complete it, and I just have one more pull request to go!

Week 7: Hacktoberfest pull request 2

mpa-LHutchinson — Sat, 19 Oct 2024 20:09:11 +0000

Introduction

This week I got my second pull request for hacktoberfest merged. The thing is, I've technically got 2 pull requests merged, however since they are both relatively simple I will only count one of them for the purpose of my release 0.2 assignment, as the objective of the assignment is for the pull requests to be progressively more challenging. But for this week I made an easy pull request in order to have something to blog about this week.

The Issue

Here is the link to the issue:

https://github.com/InDieTasten/ASCII-mate/issues/35

This repo I worked on was for a tool called ASCII-mate, a CLI tool with mouse support for drawing ASCII art and animations. For my issue I simply needed to create an MIT license file for the repo with the author being the owner of the repo. Needless to say this was a pretty trivial task as I've made an MIT file earlier this semester for my own release 0.1 repo. All I had to do was fork the repo, create a file titled "LICENSE" and copy the MIT license information into the file.

Completing the pull request

Once I added these changes, I created a pull request and informed the maintainer that I added the change. The same day, the maintainers merged the pull request. They were nice and even gave me a tip that I didn't know of, which is if you write words like "Closes" or "Fixes" and then the issue number in the PR description, it will auto-link the PR and close the issue automatically when it gets merged.

https://github.com/InDieTasten/ASCII-mate/pull/41

Other pull request

While searching for other issues to work on, I completed another relatively simple one where all I had to do was add something to a README file. While I could include this as one of my 4 pull requests for release 0.2, I'm going to choose to search for 2 more complex issues instead. If you'd like to check out the issue and pull request I'll leave them here:

https://github.com/One-Zero-Code/ngx-toastr-message/issues/16
https://github.com/One-Zero-Code/ngx-toastr-message/pull/19

Conclusion

Overall I am thankful I was able to get another pull request approved. These first 2 pull requests are a great starting point, but now I will search for harder pull requests in order to challenge myself.