DEV Community: Christian Duarte

Release 0.4 // Final PR

Christian Duarte — Mon, 09 Dec 2024 23:26:13 +0000

Intro...

Its over. I finally finished my 0.4 release PR, pushed it, and it was accepted. I successfully created connect four using the LiteCanvas engine.

My Goals...

Of the goals I had listed and as mentioned in my progress update, I implemented the following.

Successfully created a Connect Four LiteCanvas game.

Studied the documentation as well as prior implementations of games and examples.

Added a dropping piece animation.

Having a simple UI and with friendly controls.

Having the game be 2 player back and forth.

Features...

A dropping piece animation using state changes of arrays.

2 Player turn based gameplay.

Selector with movement animations to select columns to drop in using the left and right arrow keys.

Drop piece activated with down arrow key.

Victory and Draw screens after game ends, with ability to replay the game by hitting the 'r' key.

Turn descriptors, with colour coordinated user text.

User score counter for both players.

Sounds for moving selector left/right, dropping a piece, winning a game, drawing a game, and replaying the game.

1 point given for a win to the winning player.

1 point given to BOTH players for a draw.

Accomplished...

In making this connect four game, I will walk through how I accomplished it.

Initializations:

Set up all necessary factors for the screen.

Set up the delays to be used for player moves with keyboard.

Set up the selector coordinates to be moved to on the board.

Set up the initialization of beginner game states.

Set up colours and positions to be used.

Set the game state.

Selector graphics:

Used a pre-used arrow drawing and modified to become a triangle.

Triangle gets rotated to look as it does later on.

Update/draw loop:

Set up the update loop, checking for update helpers depending on game state with every run of the game loop.

Set up the helper methods for updating as well as the drop piece.

Draw method:

Drew the parts of the board.

Drew the selector.

Set conditions based on game state.

Win/Draw methods:

Set up conditions for checking win based on vertical/horizontal/left diagonal/right diagonal.

Set up condition to update state based on draw.

Learnt...

Overall I learnt quite a bit about game development in this process. Although I have used PyGame in the past to create a similar implementation, I dod not use it at all as a reference and instead went into this project from scratch, wanting to learn about the LiteCanvas engine. First, I learnt how to create a game loop using the pre-defined classes. Then I learnt how to create objects using the engine. Then I learnt how to create a simple animation that was effective for my use case. Then, I learned how to make the possibly simplest method of checking rows, columns, and diagonals that I have come up with yet. Finally I learned how to add sounds and create them using the ZzFX library mentioned by the maintainer Luiz. In this process I think the only thing I could have done better would be to implement a more object oriented approach with classes and objects similar to my approach with PyGame that I made. In the end, I am happy with my game, and encourage you to pull and test it out for yourself. If you'd like to view the other games as part of the engine as well as mine, visit here. If you'd like to see my PR as mentioned at the start, visit here.

Release 0.4 // Progress Report

Christian Duarte — Mon, 09 Dec 2024 22:32:31 +0000

Intro...

Over the last 2 or so weeks, I have been working on my game from my last post of connect four for the litecanvas game engine.

So Far...

So far, I have been able to commit changes of drawing the board,

I noticed there were some samples and also a repo for presenting different games made with the engine and I decided that I would take on the task of creating a game for that repo. If I am successful with the first game in a short amount of time, I have the possibility to create more games, and also provide testing to the repo as I have told the maintainer Luiz that I may be able to assist with that as well and he confirmed this would be okay.

Samples

Official Games (1 so far)

Why LiteCanvas...

For this release I chose LiteCanvas because I went with the option of "Contribute to a project or community that has some special meaning to you."

Over this past summer, I really enjoyed making games for my portfolio with PyGame and learning how to use it as I went. So far my games have only been able to run as executables when downloading my games from itch.io, and I had no success with getting them to run in the browser. I have made a connect four game in the past, but that was with Python and PyGame where I was much more comfortable. Using LiteCanvas, I can have a small prototype alternative to my game in the browser this time, and can even help promote LiteCanvas to others by publishing my game (My games are not monetized). Even if I am trying to convert my code, JavaScript is different for me and will present me with many challenges. I think this is an issue that I will really enjoy working on as well as debugging along the way to make sure user inputs and animations are properly executed. It has meaning to me because having my game showcased on the official repo of the game engine is pretty cool to me.

My Goals...

My goals for this release are as follows.

Main Goals

Create a successful Connect Four game using the LiteCanvas engine.

Study the LiteCanvas documents and use cases to understand how the engine works.

Have a feature of dropping a chip into place with a falling animation.

Have a simple but user friendly setup with simple assets.

Have the game be a 2 player back and forth game.

Extra Goals (If game is completed early)

Provide testing for functions of the game engine itself.

Implement an AI opponent for the Connect Four game similar to but not as large as my PyGame.

Possibly create a new game, and draft some ideas beforehand.

Create more of these extra goals along the way if I think of more.

Release 0.4 // Progress Report

Christian Duarte — Sat, 07 Dec 2024 19:57:02 +0000

Intro...

Over the last 2 or so weeks, I have been working on my game from my last post of connect four for the LiteCanvas game engine.

So Far...

So far, I have been able to commit changes of drawing the board, successful checks for win cases, and the drawing of the board assets in the game loop.

Stuck...

In my development of this connect four game, I have come into 2 small issues aside from learning the engine. First, I set out to have a clean looking falling animation. Due to the limitations of not using complicated assets, but using the inbuilt drawing methods of the engine, I found that I had to create this animation in a different way than I intended. Because of the way the board is being drawn, there were overlapping shapes that I could not have a continuous fall animation behind open circles on the game board. I opted to go with board positions that change colour as the piece drops into its final place. My current animation can be seen below:

For my second issue, the game updated so fast that if I wanted to move the selector for dropping a piece it would instantly move to the end of the board. As well, when the pieces dropped they would instantly show at the bottom despite my attempts at the falling animation. To fix this, I added delays for moving the selector, dropping a piece, and waiting for a piece to drop before moving the selector.

Figured Out...

So far in this release, I have been able to figure out how to draw objects, how to keep states of objects that change with keypresses, how to use the game loop, how to use the update method, and more. It's been fun so far reading the documentation and cheat sheet guide and using it to create and play my game.

My Goals...

My initial learning of this release was just studying the docs. As mentioned above, I have been using the docs and cheat sheet guide(s) and following the proper syntax for the game to run. As well, I closely followed the game logic of the other game present in the games repo of 'Asteroids'. Using that code, I was able to figure out how to get my logic and initializations of variables and states done in a similar way. By the end of this release I hope to achieve my main goals. The extra goals may not be completed because of exam prep and final projects I've been working on. But I am almost complete with the game and on track to hit my main goals.

Of my main goals I have:

Created a Connect Four LiteCanvas game.

Studied the documentation as well as prior implementations of games and examples.

Added a dropping piece animation.

Having a simple UI and with friendly controls.

Having the game be 2 player back and forth.

Additional features I have added:

Selector with delays for user inputs.

Victory and Draw screens after game ends.

Turn descriptors.

Features currently in the works:

Score counter.

Ability to replay/continue playing the game.

Overall, I think by the release 0.4 due date I will end up completing my main goals. I am currently still working towards completion of the game, and am on track to do so by the submission.

Release 0.4 // The Plan

Christian Duarte — Fri, 29 Nov 2024 07:51:32 +0000

Intro...

For the next few weeks, I have been tasked with a 0.4 release for open source class. This release requires me to think outside the box and contribute something meaningful and something that will be a challenge for me.

My Plan...

For this release, I am creating a game! I have chosen to work on the LiteCanvas game engine created by Luiz Bills, that can be found here. LiteCanvas is a game engine created with JavaScript and is designed to be used for small web based game and animation creation.

I noticed there were some samples and also a repo for presenting different games made with the engine and I decided that I would take on the task of creating a game for that repo. If I am successful with the first game in a short amount of time, I have the possibility to create more games, and also provide testing to the repo as I have told the maintainer Luiz that I may be able to assist with that as well and he confirmed this would be okay.

Samples

Official Games (1 so far)

Why LiteCanvas...

For this release I chose LiteCanvas because I went with the option of "Contribute to a project or community that has some special meaning to you."

Over this past summer, I really enjoyed making games for my portfolio with PyGame and learning how to use it as I went. So far my games have only been able to run as executables when downloading my games from itch.io, and I had no success with getting them to run in the browser. I have made a connect four game in the past, but that was with Python and PyGame where I was much more comfortable. Using LiteCanvas, I can have a small prototype alternative to my game in the browser this time, and can even help promote LiteCanvas to others by publishing my game (My games are not monetized). Even if I am trying to convert my code, JavaScript is different for me and will present me with many challenges. I think this is an issue that I will really enjoy working on as well as debugging along the way to make sure user inputs and animations are properly executed. It has meaning to me because having my game showcased on the official repo of the game engine is pretty cool to me.

My Goals...

My goals for this release are as follows.

Main Goals

Create a successful Connect Four game using the LiteCanvas engine.

Study the LiteCanvas documents and use cases to understand how the engine works.

Have a feature of dropping a chip into place with a falling animation.

Have a simple but user friendly setup with simple assets.

Have the game be a 2 player back and forth game.

Extra Goals (If game is completed early)

Provide testing for functions of the game engine itself.

Implement an AI opponent for the Connect Four game similar to but not as large as my PyGame.

Possibly create a new game, and draft some ideas beforehand.

Create more of these extra goals along the way if I think of more.

Lab 9 - NPM Release

Christian Duarte — Fri, 22 Nov 2024 20:41:27 +0000

Package and Registry...

For this weeks lab, I had to release my CLI tool to an official registry. For this I chose NPM. As well, I had to tag my release on GitHub as well as the registry.

The information I used in helping figure out how to do so can be found below.

NPM Docs

https://docs.npmjs.com/packages-and-modules/contributing-packages-to-the-registry
https://docs.npmjs.com/creating-and-publishing-unscoped-public-packages
https://docs.npmjs.com/creating-node-js-modules

Articles

https://hackernoon.com/publishing-a-nodejs-cli-tool-to-npm-in-less-than-15-minutes

Bun Docs

https://bun.sh/docs/cli/publish

Git Tags

https://git-scm.com/book/en/v2/Git-Basics-Tagging

Errors with build command

GitHub Copilot. Used it for helping solve an error when I built my program. My error was that my index.ts converted to index.js was not present in my dist/ folder. This was because I had an issue with my tsConfig file. I could not find the fix online, but Copilot helped me find my importing error.

Process...

The process for this release was as follows:

Researched the registry I was going to upload to. Bun has a publish command, but it is not in effect yet so I had to convert to node project and build it that way.

Setup my package.json. Set up my package.json file to include the dist/ directory and the command to be used by my CLI tool once published as well as the version and description.

Reconfigured my project. Moved around some files and imports to allow for the project to be run as an NPM module. Without this I could not properly build the project to a js equivalent and publish it.

Ran the build script. Used bun run build to build the project to a js app from my ts files.

Made an npm account. Made an account with https://www.npmjs.com .

Signed in through terminal. Used npm login to sign in, and followed the instructions.

Ran the publish command. Used npm publish to submit to the registry.

Setup git tags. Set the git tags for my release version matching the npm registry version.

Saved changes. Saved, committed, and pushed my changes as well as the git tags and checked my actions to ensure all tests passed on remote.

Aha! or Stuck?...

Working on this lab I didn't have any aha moments, other than maybe being excited that I was able to actually push my module to the npm registry. My stuck moment was definitely trying to figure out why the build was working but no files were present in the dist/ folder.

Altered Code...

Overall I didn't have to alter that much code besides now rnning my program from init() outside of the commant.ts file. My init() runs through the test file or the index.ts/js file and calls the command.ts. I did have to restructure a bit, having to move my index.ts file into the src directory for my publish and build to function properly. I ensured that my program works through the NPM install and through the git repo locally while I was making changes, as well as making sure my tests never broke.

User Testing...

With user testing, we weren't able to come to any bugs that were code errors that I or contributors created. The only errors that occurred were from my friend's computer not having correct permissions on his system to run scripts, and hadn't installed Bun due to it being missing from my README steps. There were a bit of steps that I was missing in my README.md that I tried to not hint or influence how to fix at first. I was able to help and took notes of what went wrong though and those issues are now outlined as steps in my README.md. Everything that contributed to lack of understanding has now been updated in my README, but I always am open to feedback if further explanation is needed. If my friend finds any bugs in the future I'm sure he will let me know, the only thing we encountered however was that sometimes if he gave the tool 2 of the same file contents but with different file names, the syntax for markdown would be very off and incorrect, as well as displaying the second duplicate file name wrong. This is something I will have to work on with my prompt engineering, and I think that seeing this happen to users will help me tweak my prompts ever so slightly to be better for these use cases.

Installing...

Now that my project has been released as an NPM module, users can install it with the

npm install -g f2read

command. In order for the project to work though, users must follow the steps outlined in my README.md located here.

Release 0.3 - OEV-docs PR

Christian Duarte — Thu, 21 Nov 2024 02:27:04 +0000

My Mistake...

In case you missed the last post, I would like to re-state:

For this release I messed up very badly. I messed up my due date for this release in my calendar thinking it was for the 30th instead of the 20th. I also completely forgot that I had to contribute to this release, it entirely skipped my mind. That being said, I did the best I could before the deadline to get some progress in, completing 2 PR's, one of which was really fun, and 1 of which required research.

Issue...

The issue for this second PR was for an app called OEV-docs. I saw an issue regarding some links needing to be updated to not redirect to a 404 page, and instead redirect to something more informative. In this case their main pages were /dapp/overview and /oev-searchers/overview. Searching for just /dapp and /oev-searchers resulted in 404 errors on the site. It had not been assigned to anyone and as I was running out of time due to my own mistakes, so I decided to complete the requested changes and push a PR anyway to see how it would go.

I also had another repo that I was set to work on, adding unit tests to a project. However, that maintainer hadn't got back to me in time and I had not yet made any tests for it, so I did not force a second PR through like I did with this one, which I admit is kind of reckless.

Problems...

The first problem I faced was not having ever worked on a VitePress project before. Everything was in markdown syntax and required pnpm commands which I had not worked on before. I had to do some research into VitePress routing, and had a little help from copilot to fix some mistakes I made as I was not 100% familiar with the environment still. In the end I was able to complete the requested issue.

The second problem was that of not being approved for the issue. I basically completed it and let them know that it was done. I only did this as the solution was minimal in terms of it did not impact a lot of their doings, but it did help significantly from what I was able to test.

Solutions...

I had to create an index.md for the root folders of /dapp and /oev-searchers. Inside these files I made sure with a script tag that if the window was undefined which would normally lead to a 404 error that it would instead redirect to the respective /overview links.

Example of /dapp/index.md:

PR...

At the time of writing my PR is still awaiting approval. I am not sure if it will be, but the maintainers have seen my code in some capacity and I am staying optimistic of the situation.

Overall...

Overall this was an experience that could have been handled a lot better by me given I had allowed myself more time and didn't mess up this badly with my scheduling. However the maintainers seem like good people who know what they are doing, despite a slight miscommunication between me and one of the maintainers on what my changes actually are. The maintainer thought that I edited a file that was in a directory as a result of an error which would break existing links, but I had created the file intentionally and tested that links were not harmed. I hope the maintainer at this time will review my code a second time and let me know of any updates, but overall this was a good experience to learn something new such as VitePress.

Release 0.3 - Maverick-AI PR

Christian Duarte — Thu, 21 Nov 2024 02:12:35 +0000

My Mistake...

For this release I messed up very badly. I messed up my due date for this release in my calendar thinking it was for the 30th instead of the 20th. I also completely forgot that I had to contribute to this release, it entirely skipped my mind. That being said, I did the best I could before the deadline to get some progress in, completing 2 PR's, one of which was really fun, and 1 of which required research.

Issue...

The issue for this first PR was for an app called Maverick-AI. I saw an issue regarding a footer needing to be updated and thought this would be a good match for my skills. As I looked further into the issue I saw that this had potential to be a great PR and one that I would enjoy contributing to.

Problems...

The only problems I really faced was that of needing to come up with a design for the footer. I was given creative freedom by the maintainers to create the footer as I pleased, and this made me have to apply some knowledge of UI design principles and draft some concepts. I honestly think that was the hardest part, as I have become very accustomed to working with Tailwind CSS as of late.

My concepts on Figma of potential footer designs can be found here.

Solutions...

After creating a design I liked from scratch, I kept it as a reference on my secondary display for a direct comparison with my locally running environment.

Below is the design I ended up sticking to:

Below is my final implementation for web and mobile views:

PR...

My PR went smooth on this issue, having 0 merge conflicts thanks to me pulling and locally merging changes that occurred while I was working on my issue. I was very happy to see it accepted so quick.

Overall...

Overall this was a very pleasant experience for me. The maintainers were very informative, helpful, and encouraging, and if they should require my help in the future I would gladly commit more changes.

Lab 8 - CI Actions and Testing

Christian Duarte — Sat, 16 Nov 2024 02:14:09 +0000

Actions setup...

This week I had the task of implementing more tests and a CI workflow to my project. I had to use a YAML file to run my tests on pull requests and pushes to the main branch.

My YAML file used for this action run:

Partner Repo...

The repo I worked on this week was for my partner Liam's project. His project is located at: https://github.com/mpa-LHutchinson/Auto-README

The Auto-README repo differed from mine as it had testing for 2 different files as well was setup slightly different. It also had almost full coverage for the files being around 78% with only 5 lines not being covered by the tests. I decided to convert his way of including a config file into a function, and then allowing for testing to be done on that function. The tests had 95% coverage when I completed my tasks.

For a full breakdown of my changes, visit my pull request here

CI Setup...

Overall, I enjoyed adding a CI action to my repo. This allows me to have testing that runs every time I push to main or commit a pull request and also for contributors of my repo to have the same. When I see a pull request from someone to my project now I can see if the test cases all still work and if the program is working as expected with changes included.

Optional Challenges...

This week I had a lot of projects due and was not able to devote enough time to the optional section.

Lab 7 - Jest Testing

Christian Duarte — Sat, 09 Nov 2024 02:27:46 +0000

Improvements...

This week I had the task of implementing testing into my project, and updating my CONTRIBUTING.md to reflect how to access the test suite.

Tools...

The tools I chose to implement this week were 'JEST' and 'Nock'.

JEST

JEST is a testing framework available as a VSCode extension and an npm module. It can be used within a program to provide a test suite with sectioned tests for different functions (at least in my use case). I have used jest before in my previous cloud computing class but had not used it in the almost 1 year since I took that course. It was not too hard to get back into. The documentation for JEST can be found here

Nock

I had never used Nock before this assignment, nor did I know what Nock is/was. Nock is a "server mocking and expectations library for Node.js". In this project, I used it to simulate my project connecting to the Ollama API in the test suite, where I could then test my main function without running an Ollama instance. The documentation can be found here

Setup...

JEST

For the JEST setup, I ran

bun add jest

which added JEST to my project. I then created the command.test.ts file in the root of my project, to correspond to my command.ts file in the src folder of my project. After that I downloaded the JEST extension from the VSCode extension marketplace to allow for 1 click and automatic testing on save.

Nock

For the Nock setup, I only ran 1 command, and then included the proper dependencies in my test file, the command to install was:

bun add nock

LLM response mocking...

When implementing my tests, I did use GitHub Copilot a few times when I got stuck, to explain me the syntax for JEST as I did not remember certain things, or in some cases for setting up Mock data to be implemented. The main area I had to gain help from Copilot with, was the init() testing, as I hadn't used nock before, and was having a hard time implementing it myself using just the documentation. I console logged my AI response in my init() function to see the structure of the response, then used copilot to help me structure the nock, and was presented with this:

Now that this is complete, I have to go back and remove the logging, as a realize while typing this that I never removed it.

Tools running from CLI...

As provided in my setup above, adding the scripts allowed me to run the tools from the command line. The prettier script opens up all of my files and formats them to the prettier format, and the ESLint script checks only my src/command.ts file for lint errors as it contains my main logic, and my only other file is just 1 line of code that had no issues when I tested it.

Writing test cases...

While writing my test cases I was able to get through the helper functions I created pretty straightforward. I knew how they worked, I knew how to go about testing them, and I was able to debug my issues pretty easily. The hardest part of the helper functions was finding the right amount of coverage with my use cases. The main part I got stuck on was the init() as mentioned before. I had an issue with the way I was doing it being that my test was checking for the creation of the README.md file made by init() with the mock LLM response before the init() had completed the process of creating the file. My "aha!" moment was realizing that not all of my async processes were being awaited, and that's why it was completing before the init() finished.

Test case:

AHA fix:

Bugs and/or edge cases...

In my testing journey on this lab I only found things like cases where an error case could never occur, or a conditional of a function could never be entered. For example in my check file path function I had a section to check if a filename didn't contain a "." meaning its a directory, then inside that did another check for if it was a directory. This was useless and was contributing to me not having great coverage. I was able to fix many issues like this, and make my code slightly more simple and effective in the process.

What did I learn?

Overall from this process I learned or re-learned how to introduce JEST testing, and a testing suite into my project. I also learned how to use the extension which made running individual tests very simple and straightforward, as well as letting me run tests with 1 click. I actually enjoyed running and figuring out how to create tests for this tool although I struggled with my init() towards the end. In the future, I hope that I can retain the knowledge that I learned about JEST testing and maybe even Nock, and can introduce testing into more of my personal projects.

Lab 6 - Formatting and Linting

Christian Duarte — Sat, 02 Nov 2024 02:00:54 +0000

Improvements...

This week I had the task of implementing a formatter and a linter into my F2Read repository project.

Tools...

The tools I chose to implement this week were 'Prettier Formatter' and 'ESLint'.

Prettier formatter

Prettier formatter is a VSCode extension and/or npm module that can be used to format code in a nice looking way with a simple command or the click of a button. I chose prettier as I had been using it already to format my documents in VSCode for quite a while now, and on my old PC had it set up for formatting on save from an older project in last year's cloud computing class. The documentation can be found here

ESLint

ESLint is another VSCode extension and/or npm module that can be used to check for lint warnings and errors live while programming, or with a simple command run. I chose ESLint as I have chosen to have it in react projects in the past and figured it would be easy to start with. The documentation can be found here

Setup...

Prettier formatter

For the prettier setup, I had to run various commands, and ignore several files and folders in the configuration files, while leaving the format settings to their defaults. I followed the official prettier documentation which I will list below as I used their 'bun' section.

Commands (In-Order):

bun add --dev --exact prettier

bun --eval "fs.writeFileSync('.prettierrc','{}\n')"

node --eval "fs.writeFileSync('.prettierignore','# Ignore artifacts:\nbuild\ncoverage\n')"

Make any changes to the .prettierignore as needed:
Add the below script to the package.json scripts: >

bun prettier . --write

ESLint

For the ESLint setup, I had to install dependencies, and left all the default configurations as they were.

Commands (In-Order):

bun add -d eslint

bun eslint --init

bun add -d eslint-config-airbnb eslint-plugin-import eslint-plugin-react eslint-plugin-jsx-a11y

Add the below script to the package.json scripts to run the linter on any files, in my case the src/ directory: >

eslint src/*.ts

Auto Linting and Formatting...

For auto linting and formatting in VSCode, please visit the bottom section of my CONTRIBUTIONS.md here, where I have outlined the steps to do so.

Bugs and Issues...

While working, I found no issues with the prettier format once I ran the script. My code worked fine, and it removed unnecessary whitespaces within my code. As mentioned before, I have been using it to format while working already through the VSCode extension, so there was no conflictions, errors, or bugs for me. With ESLint, I found several errors of which 2 I placed ignoring comments due to them being an err in a catch wasn't used. I wanted these ignored because they had custom error messages by me used in place, and I did not find it as an ACTUAL issue to my program. The third I commented was an issue of a type being any, where it could be explicitly defined. It was in receiving the Ollama response. I found it was easier for me to leave the definition as any because that was my choice of how to define it (it gets redefined one line after) and I left it ignored. The other issues, I did use the lint suggestions and cleaned up my bugs. Mostly setting const for variables of let that never get redefined.

Tools running from CLI...

As provided in my setup above, adding the scripts allowed me to run the tools from the command line. The prettier script opens up all of my files and formats them to the prettier format, and the ESLint script checks only my src/command.ts file for lint errors as it contains my main logic, and my only other file is just 1 line of code that had no issues when I tested it.

IDE Integration...

To integrate into my IDE, I mentioned it above in my steps as well. But I will provide screenshots here for context. The implementation into my IDE can be seen below:

What did I learn

Overall from this process I learned or re-learned how to install a formatter and linter into my code, set up auto formatting, auto and live linting, and set up GIT Hooks into my code. I also did a better job this time around of rebasing, squashing, and then committing and pull requesting my code, and was way more successful with my squash. I was in less of a rush and was more comfortable this lab than when I did the last one with rebasing, and I enjoyed it much more thoroughly this time. Overall this was a short but solid lab and learning experience for me.

Hacktoberfest Week 4

Christian Duarte — Thu, 31 Oct 2024 00:16:14 +0000

Intro...

This week, I worked on my fourth and final commit of Hacktoberfest. Because I had a lot to do with exams, projects, and personal projects over the reading week, I didn't want to delve into a major fix. Instead I opted for something new that wasn't the most complicated but is still something I had to get my self familiar with. I found a project, the Code Thesaurus located at https://codethesaur.us and I saw they had an open issue to help with adding some Kotlin syntax to the thesaurus.

The issue ...

The issue I worked on pertained to adding Kotlin syntax for input and output operations in the thesaurus so they can be compared to the implementations of other languages.

The issue I contributed to can be found here:
https://github.com/codethesaurus/codethesaur.us/issues/736#issue-2436514141

The fix ...

To prepare the fix I had to setup the environment of the project. It was well documented and easy to setup by just following the commands given.

The steps I took were as follows:

Reviewed the issue

Created a fork to ensure it was something I was familiar with

Set up the project

Looked where the fix was supposed to be located and ensured I would be good to fix this.

Asked and waited for approval

Ran the server / application

Begun implementation

Same process as the previous PR's.

In order to prepare and actually make the fix, I continued with my scoping out the project to ensure familiarity with the language and framework setup to ensure that this was a change I was comfortable working on.

Code ...

The code for my fix was editing JSON formatted data. It was not too much, it was just writing values for "code", "comment", "name", and other values or JSON data.
The code was less than I expected, but I had to do a lot of research on the side, as I was uploading documentation for Kotlin, which I have no previous experience in. I had to thoroughly research Kotlin and its syntax in order to ensure correctness and provide accurate descriptions for each code snippet I provided.

Code of io.json before the fix:
N/A, file did not exist

Example Code of io.json after the fix:

In the new code you can see that I only had to work with formatting json data this time around, implementing code examples, comments if needed, and a description of the code to be compared.

Difficulties ...

This project did not cause me any prior research and/or major difficulties to setup as it was well documented and ran easily on my PC. However my only difficulties came with ensuring my Kotlin code was good and working.

Maintainers ...

Overall I had little interaction with maintainers up until the pull request, only having spoken about confirmation regarding the issue to be assigned.

PR ...

My pull request for this week's post can be found here:
https://github.com/codethesaurus/codethesaur.us/pull/762#issue-2627255281

Hacktoberfest week 3

Christian Duarte — Thu, 17 Oct 2024 15:43:04 +0000

Intro...

This week, I worked on my third commit to a public open source repository. After last week's full UI redesign, and the prior week's small fix, I felt comfortable to hit my goal of contributing to a larger scale application. I was able to find a project called Onlook, which is an application that allows users to create React apps and modify the components as if they were designing with Figma.

The issue ...

The issue I worked on pertained to adding a hint of text to a textArea field where a user can enter the tailwind classes for an object. The field should say "enter to apply" with an icon of an arrow when the textArea is within focus, and that hint should disappear when out of focus.

The issue I contributed to can be found here:
https://github.com/onlook-dev/onlook/issues/549

The fix ...

To prepare the fix I had to setup the environment of the project. It was easy and documented extremely well within their README.md of the repo.

The steps I took were as follows:

Reviewed the issue

Created a fork to ensure it was something I was familiar with

Set up the project

Looked where the fix was supposed to be located and ensured I would be good to fix this.

Asked and waited for approval

Ran the server / application

Begun implementation

In order to prepare and actually make the fix, I wanted to first make sure that this fix was actually something I am comfortable working on because it was from a larger scale application. I forked and pulled from the repo, looked into the file where the fix would take place, and decided this was a good fix for me. I then awaited approval and when complete began my work on the issue.

Code ...

The code for my fix was more than I expected to be honest. I thought it would be a simple setting of a variable with a React state and using that to decide if the text would show on focus or not. That ended up being the easy part, the hard part was the margin of the text and the content of the textArea. As I described to the maintainers, the hint had some overlap with the content when a user would resize the textArea as per their textArea being resizable. In order to curb this fix I had to use React's useRef to get the size of the content area and apply auto resizing to the textArea to the size of the content + another 20px for margin. It looked pretty good, and I had a nice review discussion with the maintainers.

Code of TailwindInput.tsx before the fix:

Code of TailwindInput.tsx after the fix:

In the new code you can see that I had to stray a bit from their implementation style as this was a harder fix than initially thought, and after I had sent my PR for approval, the maintainers acknowledged this.

They did however tell me that what I did was a good idea, and then made their own commits before merging to ensure that the variable names I had given were more suited to what they were looking for, and replaced my img tag with their icon custom component that I was not aware of at the time of making my fix. I appreciate that they were able to clean up some of my code and accept it in a respectful manner.

Final code after adding their changes to my fix:

Difficulties ...

This project did not cause me any prior research and/or major difficulties as I am familiar with React and Tailwind CSS. However I did struggle to match their code style properly, and I think that is something I am still learning to get better at. Only with time and practice will I be able to more effectively, efficiently, and properly implement coding solutions to a project.

Maintainers ...

Overall I had a lot of interactions with the maintainer(s). It was a large scale repository and the maintainer I had interactions with wasn't the one who opened the original issue. I really enjoyed working on this fix especially with it being such a large scale project, and I can say that the maintainers were nothing but nice, respectful, and helpful during this feature implementation.

PR ...

My pull request for this week's post can be found here:
https://github.com/onlook-dev/onlook/pull/572