DEV Community: Peter Wan

Coming Full Circle: It starts and ends with Git and GitHub

Peter Wan — Fri, 06 Dec 2024 21:04:48 +0000

As I begin to finish my final assessment for the Topics In Open Source 2024 course, led by Professor David Humphrey, I find myself reflecting on how fitting this moment is. My journey in open source began with learning the fundamentals of Git and GitHub - understanding commits, branches, pull requests, and the intricate dance of version control. Now, here I am, contributing to a browser extension that helps others visualize and understand these same concepts better.

The Project

NirmalScaria / le-git-graph

Browser extension to add git graph to GitHub website.

Le Git Graph - Commits Graph for GitHub

A browser extension that displays the git graph for any GitHub repository.

Demo

Installation

Install the extension from the link -

For Google Chrome, Opera, Vivaldi, Brave, and Microsoft Edge:

https://chrome.google.com/webstore/detail/le-git-graph-commits-grap/joggkdfebigddmaagckekihhfncdobff

For Mozilla Firefox:

https://addons.mozilla.org/firefox/addon/le-git-graph-github-git-graph/

After installation, open any GitHub repository and a new 'Commits' tab will be visible.

Open the commits tab and follow the prompt to authenticate with your GitHub account.

Setup for Private Repos owned by an Organization

Access to private repositories owned by an organization is restricted by default. To access the commits graph for such repositories, you need to follow the following steps.

Go to https://github.com/settings/tokens
Create a Personal Access Token (PAT) with the following scopes -
- repo | Full control of private repositories

For a more secure option, use a Fine-Grained token (beta) with the following scopes -

repo | Read access to code, commit statuses…

View on GitHub

Le Git Graph is a browser extension that enhances GitHub's interface by adding a visual commit graph (note - if you have the repository installed locally, it'd be equivalent to running git log --all --graph).

While GitHub does have the ability to show you the list of commits on a repository, this extension provides the ability to view these commits in a graph form, which in my opinion, is really helpful.

GitHub's normal feature of showing commit history:

Le Git Graph's Commit View:

The ability to see the commit history and get a visual idea of when branches were made and merged serve to enhance one's understanding of a repository's development progress. I think those looking to contribute in open source development would find this extension to be highly valuable.

The Challenge

My contribution to this project involved fixing some of the broken behaviors when clicking the Commits button that is injected by Le Git Graph. The original issue can be found here, and my pull request showing what has been updated can be found here.

To sum up the issue - the Commits button would disappear sometimes when navigating across different GitHub links (e.g., simply clicking the name of the repository would cause the Commits button to disappear!).

The solution involved implementing robust event listeners for GitHub's various navigation events and improving how the extension detects and maintains UI elements across different page contexts. This fix ensures the Commits button stays visible and functional regardless of how users navigate through GitHub's interface, whether clicking repository links or switching between tabs.

The Learning Journey

Looking back, it's almost poetic how this project encapsulates my identity and growth in open source development:

Understanding Git: When I first started, visualizing Git's branching and merging concepts was one of the biggest challenges for me. However, once I understood those concepts, I started using git log --all --graph daily as if it was a matter of fact thing to do. Jump forward to the present, I'm trying to improve the functionality of Le Git Graph, which offers this visualization to others.
Browser Extensions: As mentioned in my previous blogs when I worked on the ImprovedTube extension - I have recently been invested in learning more about browser extensions. The work I did for Le Git Graph, has taught me about the complexities of integrating with existing web applications (you have to know a lot about GitHub's interface in order to manipulate it!). Working on this extension made realize GitHub's dynamic nature requires me to carefully handle different page states and navigation patterns - and even then, there might be things that change and I'll have to update the code accordingly.
Open Source Collaboration: Contributing to an existing project means understanding someone else's code, following their conventions, and thinking about backward compatibility - skills that weren't even on my radar when I first learned Git. Wrapping my head around someone else's codebase has always been quite difficult for me - even with Le Git Graph, I had to move cautiously since I'm familiar with let and const variable declarations which have block level scope, vs. var which has function level scope - believe me, these little things add up. Nevertheless, I couldn't let little things like that completely overwhelm me, instead I tried to understand the purpose of Le Git Graph by staring at its manifest.json found in the root of the project. By looking at the filenames listed under content_scripts, my top-level understanding of the extension improved.

In the picture above, you can see files that are dedicated to drawing the git graph (i.e., drawGraph.js). By taking a moment to digest these different filenames, I was able to better understand how this repository worked.

Technical Deep Dive

The technical challenges I faced were particularly interesting because they touched on multiple aspects of modern web development:

Navigation Handling: GitHub uses Turbo (formerly Turbolinks) for navigation, which required careful handling of different events:
- turbo:load for initial page loads
- pjax:end for partial page updates
- DOMContentLoaded for ensuring our code runs at the right time
DOM Management: The solution required careful management of the DOM:
- Detecting and handling different UI containers based on context
- Preventing duplicate buttons during reinitialization
- Maintaining state across navigation events
Error Handling: Robust error handling was crucial:
- Graceful fallbacks when expected elements aren't found
- Cleanup of stale elements and event listeners
- Proper logging for debugging purposes

Results and Achievements

Looking at my initial goals from the beginning of the course to right before this final blog post, I would say I was able to:

✅ Learn about Git and GitHub for the purpose of working in Open Source
✅ Pick a niche that I wanted to focus on for development (browser extension development).
✅ Find repositories that aligned with my goals and aspirations (ImprovedTube and Le Git Graph). Fixed the disappearing Commits button issue
✅ Work on using my pre-existing web-development skills to contribute meaningful code to an open source project

These 4 results and achievements make me realize how far I've come since the start of my open source journey and makes me excited to venture further down this path.

Conclusion of my experience of the `Topics in Open Source 2024` course

As I wrap up my journey in the Topics in Open Source 2024 course, I've seen my skills progress from learning basic Git commands to contributing to a tool that helps others visualize those very concepts. Through my work on Le Git Graph and ImprovedTube, I've grown from someone who knew nothing about browser extensions to a developer who can navigate a browser extension's codebase and potentially enhance it. This course has taught me that open source development is more than just writing code; it's about understanding existing systems, collaborating effectively, and contributing to tools that make development more accessible for others. As I move forward, I'm excited to continue growing in the open source community, armed with the knowledge, skills, and confidence I've gained from this course. Thank you Professor Humphrey, for providing great guidance during this journey and helping me discover my place in the open source world.

Continuous contributions

Peter Wan — Sun, 01 Dec 2024 03:44:26 +0000

Following up on my last blog, I've been aiming to learn more about browser extension development through practical experience. In particular, I've been trying my hand at contributing to the open-source project, ImprovedTube, which enhances one's viewing experience on YouTube. The source code for ImprovedTube can be found below:

code-charity / youtube

[top~1 open YouTube & Video browser-extension] - Enrich your experience & choice! 🧰180+ options & clever features 📌set+forget📌Longest-standing(been tough). Please join🧩us👨‍👩‍👧‍👧 ..⋮ {playback|content discovery|player|extra buttons|distractions|related videos|shorts|ads|quality|codec|full tab|full screen}

()
Report a bug · Wish a feature · Contribute · Donate · Test🧪

/ImprovedTube/ a powerful but lightweight extension,
to enrich your video experience & enable your content selection

Top 50 g 'Might
be the only YouTube Extension you'll ever need'
'enhances YouTube in meaningful ways'
'Strong Add-on, full control. Yet clear & easy'
Thanks ♡ to our contributors, Alan Tan, Raszpl
translators (+ wiki-authors? +donators?)

Original introduction

«Improve YouTube!»

/ImprovedTube/ is a strong & lightweight extension! - 80 features / the only one of a kind!

Since 2012 we have gradually been adding lightweight features, while keeping up with Youtube changes. (throughout the years we witnessed the birth & fall of other promising & open YouTube Extensions 1, 2, ... ) Today adding features can be easier & so motivating as there are 500 000 users. [👪Join us]. …

View on GitHub

Currently, I've been researching a family of related issues pertaining to ImprovedTube's Cinema Mode setting. Cinema Mode is a neat feature that hides all of the clutter on YouTube as you're watching a video.

In the screenshot below, you can see that on the top-right, ImprovedTube provides a switch that lets you enable the Cinema Mode button shown on the YouTube player (NOTE: whenever I say switch, I am referring to the setting at the top-right, whenever I say button, I am referring to what's on the YouTube player).

If I actually press on the Cinema Mode button, you'll notice that many things disappear - video suggestions, comments, etc.

This feature is really neat! But as I was testing this feature personally, I noticed some inconsistencies with how the extension behaved. The most apparent inconsistency was that I expected to see the Cinema Mode button disappear if I disabled the Cinema Mode switch, and similarly, I expected the Cinema Mode button to appear if I toggle the Cinema Mode switch on. Long story short - the toggle switch wasn't working as expected. Whenever I tried to disable the Cinema Mode switch, I noticed that the YouTube Player button still persisted. I was confident that this was not the expected behaviour either since ImprovedTube's other toggle switches would cause their respective buttons to appear or disappear accordingly. As such, I logged this issue: https://github.com/code-charity/youtube/issues/2700 (you can see exactly what I mean because I posted a video showcasing the issue).

I noticed that there was a lot of "buzz" around the Cinema Mode option in general(you can see that I linked some other related issues and pull requests), and so on the particular issue that I logged, I wanted to be very specific as to what I thought was wrong, and what I thought should be changed.

I volunteered to fix the issue that I brought up because I think that I had a clear expectation on how this issue should look like once it's been resolved. I also logged this issue to help me get into the flow of trying to fix some of the other issues related to the Cinema Mode setting. While I haven't exactly figured out the exact expected behaviour of the other issues yet, I will carefully review them later.

For now, I'll leave you with the pull request that I made, which hopefully, fixes the weird behaviour I stated in my issue: https://github.com/code-charity/youtube/pull/2701.

Learning by Doing: working on ImprovedTube

Peter Wan — Fri, 29 Nov 2024 02:54:44 +0000

Hi!

This blog a mental note about how I want to start learning about browser extensions by contributing to ImprovedTube, a well known browser extension that enhances your experience on YouTube.

Install ImprovedTube on Chrome

Install ImprovedTube on Firefox

I've always wanted to learn more about browser extensions, but never found myself in a position where I had the time to do so. Fortunately, one of the courses I'm currently taking - Topics in Open Source 2024, has presented an opportunity for me to work on projects that I'm actually interested in. For me right now, that is browser extension development.

I chose browser extension development because I wanted to use and refine the existing skillset I have with regards to Web Development (i.e., knowledge of HTML, JavaScript, and CSS). Browser extensions from what I have seen, lets me make use of all of the skills that I built so far with regards to web development, but won't necessarily force me to build a whole web app or web page by myself. From my experience, I find that most extensions that I use such as adblockers or light mode/dark mode extensions really adjust the content of existing web pages. By working on extensions that manipulate existing web pages, I hope to learn more about how websites like YouTube are structured by directly controlling some of the elements that they provide.

I was particularly drawn to ImprovedTube because it lets me customize my experience on YouTube - something I use on a daily basis. I know that if I work on ImprovedTube and if my changes get accepted, that I will feel immensely rewarded.

My plan of attack for learning about extensions in general

As mentioned in one of my previous blogs, I initially was going to peruse Mozilla's documentation on cross-browser development. However, I never really got to doing their particular examples. Instead, I've begun working through some examples from Chrome's guide instead:

Extensions / Get started | Chrome for Developers

All the basics to get started with Chrome extensions

developer.chrome.com

You can kind of see that I have a little note-taking thing here going on:

Without diving too much into the details, I plan on reading through this documentation and getting a hands-on feel for how things work. The great thing about browser extension development for me so far is that I get immediate feedback from the changes I make to the browser extension code. I plan on completing the rest of the Getting Started section from Chrome's documentation, while constantly looking back at ImprovedTube's code to see how they make use of these concepts in their own extension.

The family of issues I think would be good for me to tackle on ImprovedTube

At the time of writing, I've been working on this particular pull request, that aims to hide a link that appears on videos and video cards on YouTube. After working on this issue (even though it hasn't been accepted yet), I think I have a decent grasp on what files I need to modify to see the desired changes.

The particular family of issues I think I'd be able to handle would be any issues regarding hiding something from YouTube that users don't want to see.

In fact, I might ask the maintainers if they'd be open to me writing some documentation for them so that it will be easier for new open source contributors to add features like this themselves.

Conclusion

I still have lots to learn about Browser Extensions and ImprovedTube, but I'll try to learn more about both by doing.

That's all from me, see you next time!

Re-publishing gimme_readme to npm with GitHub Actions

Peter Wan — Fri, 22 Nov 2024 18:58:52 +0000

This week in my Open Source class, my classmates and I were tasked with publishing each of our own programs to a package registry.

When you hear someone say code registry, package registry, or registry, I like to think of these words as representing a place where developers and companies publish their code for others to download. For a more accurate description, you can read this article by Mozilla:

Package management basics - Learn web development | MDN

This brings us to the end of our tour of package managers. Our next move is to build up a sample toolchain, putting all that we've learnt so far into practice.

developer.mozilla.org

Why download code from a registry? Why not just go to GitHub?

Individuals familiar with GitHub might wonder, "Why should I even bother posting my tool to a registry? Why not have my users go to GitHub, clone my repository, install the necessary dependencies, build the intermediary files, and run my program?".

Long story short: developers publish their code to registries to make it easy for end users to use their programs.

With that little introduction on why we publish code to registries, let me tell you my process of publishing my JavaScript tool, gimme_readme to the npm registry which was built to host JavaScript code.

You can download my code by visiting its npm registry link below:

gimme_readme - npm

gimme_readme is a command-line tool powered by AI that generates a comprehensive README.md file for your project. It analyzes multiple source code files at once, providing concise explanations of each file's purpose, functionality, and key components, all. Latest version: 1.0.0, last published: 16 hours ago. Start using gimme_readme in your project by running `npm i gimme_readme`. There are no other projects in the npm registry using gimme_readme.

npmjs.com

Re-publishing my code to npm

As mentioned in the title of this article, I have already published my code to npm before, and this time around, I was re-publishing my code with new features that weren't included in a previous release.

In addition to publishing the new features that my code has, I also wanted to ensure my end users systems weren't bloated with any extra files from my program.

Here is a picture that shows what my users are currently getting when they download gimme_readme, following the instructions on the `npm registry:

As you can see above, there are a lot of folders and files that are unnecessary for a user to have (as opposed to a developer). For example, do you think my users would want my "tests" folder to test my program's code? Probably not. Do you think my users need the config files needed to format and lint my source code? Probably not. Do you think my users would need to use my ".github" folder for any particular reason? Probably not.

To this end, I have been working to find a solution to minimize what is downloaded by a user; specifically, I want them to only have the source code needed for my program to run.

To `.npmignore` or to not `.npmignore`? That is the question.

As I was thinking about re-publishing my code, I was also talking with my friend Uday Rana, about the idea of using a .npmignore file to "ignore" files I didn't want to publish.

Literally right after I mentioned the topic, Uday Googled .npmignore, and found an article written by Jeff D on why one should never use a .npmignore file. To be clear, I wholeheartedly agree with Jeff's article.

Essentially, the idea is that we should be explicit with what we want to publish (whitelisting), as opposed to stating which files we don't want to publish (blacklisting).

Whitelisting the files we wish to publish is simple with npm. All we need to do is edit our package.json file by adding a "files" option, that indicates which files we want to publish for our program.

Below, I've taken a screenshot of package.json's "files" option, which states, "include the src/ directory when publishing this program". I have since committed these changes and these changes are available in my v1.0.0 release of my code.

NOTE: Certain files by default, are always published to npm, regardless of what you specify or don't specify in your "files" option. If you want to learn more about how to use the "files" option, check out npm's official documentation on how to use the file option.

After publishing my code to npm with my updated package.json, users that install/re-install gimme_readme will now have a lot less bloat on their computers! See the difference below:

Adding a GitHub action to publish my code to `npm` when I add a new release

Besides enhancing the experience of my users (by reducing the bloat that comes from installing gimme_readme via npm), I also added a continuous development pipeline (cd pipeline for short) that would automate my publishing process to npm when I make a new release on GitHub. For exact details on how to do this, you can refer to GitHub's Publishing Node.js packages guide. This feels good now, because at the click of a few buttons, I'm able to publish code that I know is stable (according to my CI pipeline), from GitHub.

You can find the code for my cd pipeline here.

Testing with Uday

As I mentioned earlier, I was working with my friend, Uday Rana, with regards to testing. At the time of writing, he was able to install my tool, and use it like so:

Things look good to me, and most of the options I have for my tool more or less behave the way he expects. But I'll have to repeat this process again, because I have some further optimizations I want to add!

The journey never ends... but that's what makes it fun!

I have also recently heard of ways to optimize my code further. Particularly, I'm invested in learning how to improve my CI and CD pipelines by learning about composite actions, and reusable workflows with regards to GitHub actions. My hope is that these techniques will help me reduce the amount of code I write, and offer some type of performance boost! I don't know much about these topics yet, but you can bet I will probably blog about it soon.

And that my friends, concludes what I wanted to talk about in this blog.

See you next time!

Working on a browser extension

Peter Wan — Thu, 21 Nov 2024 00:37:14 +0000

This week, I wanted to look for an open-source project that I could use on a daily basis and where I could myself contributing a lot to going forward.

Lucky for me, I stumbled upon the ImprovedTube extension and found its GitHub repository, shown below:

code-charity / youtube

[top~1 open YouTube & Video browser-extension] - Enrich your experience & choice! 🧰180+ options & clever features 📌set+forget📌Longest-standing(been tough). Please join🧩us👨‍👩‍👧‍👧 ..⋮ {playback|content discovery|player|extra buttons|distractions|related videos|shorts|ads|quality|codec|full tab|full screen}

()
Report a bug · Wish a feature · Contribute · Donate · Test🧪

/ImprovedTube/ a powerful but lightweight extension,
to enrich your video experience & enable your content selection

Original introduction

«Improve YouTube!»

/ImprovedTube/ is a strong & lightweight extension! - 80 features / the only one of a kind!

View on GitHub

A project like this is very important to me, because it enhances the experience of something I do daily - watching videos on YouTube via my desktop. In addition, this project focuses on a topic I was interested in since I started programming: adblocking technology.

The fact that ImprovedTube offers the ability to block ads and its code is open-source, hit all of the right checkmarks for me.

So with my limited amount of web programming knowledge, I decided to take a stab at one of ImprovedTube's open issues that involved blocking ads.

How I tried to approach the codebase

I knew that there must be some great resource for me to read and learn the nitty gritty nuances of building a browser extension for different browsers (e.g., building for Chrome, Firefox, etc.) - but I wanted quickly see how I could add changes to some extension code and have those changes reflect in a browser.

To that end, I decided to follow the tutorial below from freeCodeCamp.

Long story short, this video got me to the point where I could quickly understand how I could edit ImprovedTube's code and have my changes reflect within my browser. Since I intend to work on this repository more going forward, I thought that I should dive deeper into learning the ins and outs of a browser extension, and will probably begin reading Mozilla's Guide on Building a cross-browser extension:

Build a cross-browser extension - Mozilla | MDN

The introduction of the browser extensions API created a uniform landscape for the development of browser extensions. However, there are differences in the API implementations and the scope of coverage among the browsers that use the extensions API (the major ones being Chrome, Edge, Firefox, Opera, and Safari).

developer.mozilla.org

Currently, I'm waiting for some clarification with regards to the proper way of implementing the fix for the original issue. You can find the original issue and my pull request below.

The original issue logged, where I was able to at least reproduce the issue:

Hide "Includes Paid Promotion" #2634

SuperTRev16 posted on Oct 28, 2024

⚬ PROBLEM: The annoying "Includes Paid Promotion" popup that tells us there is a paid promotion in the video. I can see how that's a legal thing, but is still unwanted bloat. Most YouTube channels always have some kind of affiliate marketing nowadays anyway. We don't really need a reminder of that on every other video.

⚬ SOLUTION:
Create a new feature that gives us the ability to hide that.

⚬ RELEVANCE / SCOPE: YouTube player

View on GitHub

My pull request:

feat: add styles to hide 'Includes Paid Promotion' elements #2684

peterdanwan posted on Nov 19, 2024

This pull request attempts to close #2634.

As discussed in #2634, certain videos include a clickable link on top of the video titled, Includes Paid Promotion as shown in the video below:

https://github.com/user-attachments/assets/5a67afbb-2bb1-4991-bf4f-4ad20b29ef76

With the changes made, the extension now hides the HTML elements related to the Includes Paid Promotion link:

https://github.com/user-attachments/assets/d4772053-d1cf-40d5-abe3-0e4b86c61546

Please let me know if there's anything else I should change - I'm happy to learn and fix more issues!

View on GitHub

My goal right now as I await further clarification is to read more of Mozilla's documentation regarding building a cross browser extension, in hopes of making it easier for me to contribute to ImprovedTube going forward.

Contributing to expressjs

Peter Wan — Wed, 20 Nov 2024 00:51:17 +0000

Hi! My name is Peter, and if you don't know me, I'm a computer science student, currently taking Professor David Humphrey's Topics in Open Source 2024 class.

Since September of 2024, I've been working to build my presence in the open source community. If you'd like to follow my journey, you can find me on GitHub:

peterdanwan (Peter Wan) · GitHub

Full Stack Developer | Games and AI Enthusiast - peterdanwan

github.com

With my final semester and the Topics In Open Source course coming to an end, I want to share my progress as a budding open-source developer and my roadmap for future growth.

Where I'm at right now

Let me start with one key realization: I have a lot to learn. If you'd asked me at the start of the semester what I needed to learn, I would have said "Everything!"

Now? I'd say "Enough to get the job done."

As I near the end of both this course and my final semester, I'm incredibly grateful to have taken Topics in Open Source. Without it, I wouldn't have gained nearly as much practical experience with Git and GitHub. After months of hands-on work, I can confidently say I've mastered many aspects of these tools.

However, open-source is more than just Git and GitHub.

To me, Git and GitHub are just a means to an end of understanding a code base. With regards to Git, I no longer have problems with creating branches to work on, navigating between branches, resolving merge conflicts, rebasing my branch's commits onto the current changes on the upstream main branch, squashing commits, testing code on different branches, etc.

I'm pretty happy to say those things are second nature now! But once again - to me, Git and GitHub are just a part of what it means to be an open-source developer. Let me tell you how I want to improve as an open-source developer.

How I want to improve as an open source developer

Remember when I mentioned knowing "Enough to get the job done"? Let me show you what that actually means through my recent pull request for expressjs.com.

Understanding the project's scope

First step: understanding what I'm working with. expressjs.com is the official documentation site for express, one of the most popular web frameworks for Node.js. While this was quick to grasp from their beautifully designed website, the journey was just beginning.

Express - Node.js web application framework

Express is a fast, unopinionated, minimalist web framework for Node.js, providing a robust set of features for web and mobile applications.

expressjs.com

Understanding the issue at hand

After getting familiar with the project as it is, I looked for an issue I could tackle. I found this one:

Broken link and missing page #1684

chrisdel101 posted on Nov 17, 2024

The following links are broken _includes/header/header-id.html

<a href="/{{ page.lang }}/changelog/4x.html">Release Change Log</a>

_includes/header/header-th.html

<a href="/{{ page.lang }}/changelog/4x.html">บันทึกการเปลี่ยนแปลง</a>

Suggest change to: <a href="/en/changelog/">Release Change Log</a>

Missing page causes console error in UZ language: /css/langs/uz.css

Suggest adding this page.

View on GitHub

I chose this issue because it involved HTML and CSS - technologies I'm comfortable and familiar with. However, what looked simple actually taught me an important lesson about open source development:

Even familiar-looking tasks can involve unfamiliar territory.

The repository used technologies I'd never touched before, and that's where the real learning began. It took me about an hour just to decide whether to attempt this issue - maybe too long in retrospect. I was hesitant because the project used Ruby, which was completely new to me.

Spoiler alert: Setting up Ruby was... an adventure.

Understanding how to setup the project locally

Setting up your local development environment is often one of the most educational parts of an open-source contribution.

I learned a little about Ruby and Jekyll, simply by trying to run expressjs.com locally.

Here's how my journey unfolded:

Initial Confusion: I started by installing Ruby directly on Windows. While it worked, it wasn't ideal, because I was having problems with the version I installed being different than the one used in the project. Version management on Windows was not fun. As such, I uninstalled my installation of Ruby on Windows and its other dependencies and looked for an alternative solution.
The WSL Discovery: My research led me to the conclusion that I should run Ruby on the Windows Subsystem for Linux (WSL), since it offers a much better development environment and access to the powerful Ruby Version Manager (RVM), which would allow me to work on projects that use different versions of Ruby. To me, installing RVM was a very similar feeling, since I use nvm-windows to allow me to switch between different node versions.
Version Management Learning Curve: Once again, I learned about RVM and its similarity to Node.js's nvm. This taught me the importance of version management in development environments.

Below are the actual commands I used to get my development environment ready:

## 1. Installing RVM (Ruby Version Manager)
# First, import GPG keys needed to verify RVM installation
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

# Download and install RVM
\curl -sSL https://get.rvm.io | bash -s stable

# Verify RVM is installed and get its path
which rvm

# Load RVM into your current shell session
source /home/peter/.rvm/scripts/rvm

## 2. Installing Ruby
# Install Ruby version 3.3.5 (latest stable as of early 2024)
rvm install 3.3.5

# Set 3.3.5 as your default Ruby version
rvm use 3.3.5

# Verify RVM and Ruby installations
rvm -v
ruby -v

## 3. Setting up Jekyll
# Install Jekyll and Bundler gems
gem install bundler jekyll

# Install project dependencies from Gemfile (must be within the target directory with the Gemfile)
bundle install

# Start the Jekyll server with live reload and external access
# --host 0.0.0.0 allows access from other devices on your network
# --livereload automatically refreshes your browser when files change
bundle exec jekyll serve --host 0.0.0.0 --livereload

Tackling the issue

With my development environment configured, I was able to begin addressing the issue at hand, that is to simply update the
anchor tags containing broken links to an English version of the link (since the English version of the link isn't broken).

That was the easiest part of this whole contribution.

I also made sure to look at some logs to see if there were any errors to fix. I suggested adding another file css/id.css, which follows the same
coding format of files that were added already, since I had an inkling that would resolve some of the error logs.

One of the maintainers of expressjs.com Chris Del, provided very immediate feedback stating that was the thing to do (thank you Chris!).

As such, I also added this change to my pull request.

Waiting to merge changes and learning to get involved with discussions

With that said, the changes I have made are now waiting to be merged into expressjs.com's main branch.
A follow-up issue was made to discuss the standards of the expressjs.com website. That is:

should a user be redirected to a working English page than to a broken-link in the correct language?

That is not up to me to decide, but I wanted to be part of the discussion. You can follow the discussion over here.

Learning to Grow as an Open Source Developer

What started as a simple HTML/CSS fix turned into a journey that taught me valuable lessons about open source development:

Stepping Out of Comfort Zones: While I chose an issue that involved familiar technologies (HTML/CSS), I ended up learning an entirely new tech stack (Ruby/Jekyll). This taught me that growth happens when we're willing to tackle the unfamiliar.
Technical Growth: Setting up development environments, managing versions, and working with new tools are all crucial skills. Each challenge makes the next one easier to approach.
Community Engagement: Through discussions like the language redirect discussion, I learned that open source isn't just about code - it's about participating in meaningful discussions that shape project decisions.

Looking ahead, I plan to improve by:

Taking on increasingly challenging issues
Learning to work with different tech stacks and development environments
Engaging more actively in project discussions and decision-making
Contributing to documentation and helping other newcomers
Building relationships within open source communities

Most importantly, I've learned that being an effective open source developer isn't about knowing everything - it's about being willing to learn anything. Every contribution, no matter how small, is an opportunity to grow and make a positive impact on the projects we care about.

If you're considering getting involved in open source, remember: start small, be curious, and don't be afraid to learn as you go. The community is here to help you grow.

# From Jest to Pytest: A JavaScript Developer's Journey into Python Testing

Peter Wan — Thu, 14 Nov 2024 23:30:32 +0000

From Jest to Pytest: A JavaScript Developer's Journey into Python Testing

As a developer with a JavaScript background, I've spent a fair amount of time writing tests with Jest. In my project, gimme_readme, I had to play around with some experimental features with Node and Jest because of the 3rd party npm modules I was using. I was able to find great Stack Overflow threads that taught me how to run Jest tests when using ES6 syntax. Without the wisdom of these smart individuals, let's just say I would have struggled! However, armed with this knowledge of how to use Jest's experimental features, I was able to:

write my tests in Jest (despite my weird configurations)
set up my CI pipeline very early on, which is set up to:
1. lint my code (i.e., check for any potential lines of code that can be problematic in the future or can cause bugs as they are now)
2. test my source code (i.e., runs tests that I have written which explain how my source code should work).

The code for the CI pipeline I described above can be found here, and is set to run whenever a push is made to any branch or when there's a pull request. This way, anyone who's trying to contribute to my repository will know if the code they contributed is "good enough to go" with regards to merging it into my main branch - at least as far as automated tests go.

Anywho, that's enough about the work I've done for my repository way back when.

This week, I decided to take on the challenge of writing some tests for a Python project written by my friend Aryan Khurana. Aryan's project is a command-line tool called github-echo which provides insights on a GitHub repository. Using an unfamiliar language + a testing framework I had never used (PyTest) was definitely outside my comfort zone, but I really appreciated that Aryan was willing to show me the ropes (thanks Aryan!).

Testing Python code with `pytest`

When I started working on tests for Aryan's repository, I was immediately overwhelmed by how different the tests looked. While Jest had become familiar territory for me, Python's pytest felt very foreign. Nevertheless, with Aryan's guidance and some determination, I started to understand its unique features.

Let's break down what I discovered in their test cases:

Parameterized Testing: One of the first things that caught my eye was the @pytest.mark.parametrize decorator. This is similar to Jest's test.each, but with a cleaner syntax:

   @pytest.mark.parametrize(
       'invalid_url',
       [
           'https://gitlab.com/username/repository',
           'https://github.com/username',
           # ... more test cases
       ],
   )

Context Managers: Instead of Jest's expect().toThrow(), Python uses context managers with pytest.raises:

   with pytest.raises(typer.BadParameter, match='Invalid GitHub repository URL'):
      check_cli_arguments(invalid_url, 'gemini', 0.5, Path('output.md'))

Temporary File System: The tests use pytest's tmp_path fixture for file system operations, which is much cleaner than setting up mock file systems in Jest:

   def test_output_file_is_directory(self, tmp_path):
      # tmp_path is automatically provided and cleaned up

Final Thoughts

This experience of working with both JavaScript and Python testing frameworks has broadened my perspective on software testing. While Jest felt like home territory, I've come to appreciate pytest's powerful features like parameterized testing and fixtures. Whether you're writing JavaScript or Python tests, the end goal remains the same: delivering reliable, well-tested code to your users.

Testing LLM Applications: Misadventures in Mocking SDKs vs Direct HTTP Requests

Peter Wan — Mon, 11 Nov 2024 03:40:01 +0000

Introduction

Let me preface this blog by saying this isn't like my other blogs where I was able to walk through the steps I took to complete a task. Instead, this is more of a reflection on the challenges I've encountered while trying to add tests to my project, gimme_readme, and what I've learned about testing LLM-powered applications along the way.

The Context

This week, my Open Source Development classmates and I were tasked with adding tests to our command-line tools that incorporate Large Language Models (LLMs). This seemed straightforward at first, but it led me down a rabbit hole of testing complexities I hadn't anticipated.

My Testing Journey

The Initial Approach

When I first built gimme_readme, I added some basic tests using Jest.js. These tests were fairly simple, focusing mainly on:

Verifying function outputs
Checking basic error handling
Testing simple utility functions

While these tests provided some coverage, they weren't testing one of the most critical parts of my application: the LLM interactions.

The Challenge: Testing LLM Interactions

As I tried to add more comprehensive tests, I ran into an interesting realization about how my application communicates with LLMs. Initially, I thought I could use Nock.js to mock the HTTP requests to these language models. After all, that's what Nock is great at - intercepting and mocking HTTP requests for testing.

However, I discovered that the way I am using the LLM is making it hard for me to write tests using Nock.

The SDK vs Direct HTTP Requests Dilemma

Here's where things get interesting. My application uses official SDK clients provided by LLM services like Google's Gemini and Groq. These SDKs act as abstraction layers that handle all the HTTP communication behind the scenes. While this makes the code cleaner and easier to work with in production, it creates an interesting testing challenge.

Consider these two approaches to implementing LLM functionality:

// Approach 1: Using SDK
const groq = new Groq({ apiKey });
const response = await groq.chat.completions.create({
  messages: [{ role: "user", content: prompt }],
  model: "mixtral-8x7b-32768"
});

// Approach 2: Direct HTTP requests
const response = await fetch('https://api.groq.com/v1/completions', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${apiKey}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    messages: [{ role: "user", content: prompt }],
    model: "mixtral-8x7b-32768"
  })
});

The SDK approach is cleaner and provides better developer experience, but it makes traditional HTTP mocking tools like Nock less useful. The HTTP requests are happening inside the SDK, making them harder to intercept with Nock.

Lessons Learned

Consider Testing Strategy Early: When choosing between SDKs and direct HTTP requests, consider how you'll test the implementation. Sometimes the "cleaner" production code might make testing more challenging.
SDK Testing Requires Different Tools: When using SDKs, you need to mock at the SDK level rather than the HTTP level. This means:
- Mocking the entire SDK client
- Focusing on the SDK's interface rather than HTTP requests
- Using Jest's module mocking capabilities instead of HTTP interceptors
Balance Between Convenience and Testability: While SDKs provide great developer experience, they can make certain testing approaches more difficult. It's worth considering this trade-off when architecting your application.

Going Forward

While I haven't yet fully resolved my testing challenges, this experience has taught me valuable lessons about testing applications that rely on external services via SDKs. For anyone building similar applications, I'd recommend:

Think about testing strategy when choosing between SDKs and direct API calls
If using SDKs, plan to mock at the SDK level rather than the HTTP level
Consider writing thin wrappers around SDKs to make them more testable
Document the testing approach for others who might work on the project

Conclusion

Testing LLM applications presents unique challenges, especially when balancing modern development conveniences like SDKs with the need for thorough testing. While I'm still working on improving the test coverage for gimme_readme, this experience has given me a better understanding of how to approach testing in future projects that involve external services and SDKs.

Has anyone else encountered similar challenges when testing applications that use LLM SDKs? I'd love to hear about your experiences and solutions in the comments!

Hacktoberfest 2024: A retrospective

Peter Wan — Thu, 31 Oct 2024 23:39:56 +0000

Hi fellas! It's the end of October and by extension, the end of Hacktoberfest 2024.

For the month of October, I've been constantly contributing to open source projects and in doing so, I learned a lot. For walkthroughs on the issues and pull requests I had done during this time period, you can check out my other blogs below:

I wanted to take a moment to reflect on the takeaways I got from participating in Hacktoberfest as a contributor.

Below, are the list of things I did that I believe helped me on my journey. I would highly recommend others to follow a similar approach!

Master Git Fundamentals

Learn essential git commands and workflows
Practice branching, merging, and resolving conflicts
Don't hesitate to consult Git documentation or ask for help in project discussions
Keep a cheat sheet of commonly used git commands handy
- I keep all of my git shortcuts in my .gitignore
- And if all else fails... ask GPT or Claude.

Familiarize yourself with Searching for Projects and looking through them

Use GitHub's advanced search filters (language, labels, "good first issue", etc.) > Try finding issues from here and working with different filters:
Follow projects that interest you to stay updated on new issues
- Personally, I followed projects that I have seen on YouTube (with regards to gaming) and projects whose tools I use (e.g., Microsoft Visual Studio Code).
Look for projects with active maintainers and study their contribution guidelines
- Search for the keywords contribute or contributions in a repository to ensure that you follow a repository's guidelines
- If you don't follow someone else's contribution guidelines... (don't expect them to accept your PR!)
Research previous issues and pull requests to see if you can find hints on how to solve your own issue.
- For example, check out my own pull request you can see that I reference an existing pull request to back up the work I did.

Conclusion

This was just a short summary of what has been an incredible month-long journey in open source contribution. But rather than just taking my word for it, I encourage anyone reading this to get out there and dive into open source yourself! Remember: every expert was once a beginner, every maintainer was once a first-time contributor, and every journey starts with that first pull request.

Happy coding, and see you in the next Hacktoberfest! 🎃 💻

Tips on Improving an Open Source Project

Peter Wan — Wed, 30 Oct 2024 01:40:23 +0000

Hello there!

I just wanted to leave some notes on what I think are some best practices to follow when creating and maintaining an open source project.

I have implemented these best practices on my GitHub repository for my command-line tool, gimme_readme, which allows one to send multiple source files to an LLM easily, and get a quick response on what those source files are doing.

peterdanwan / gimme_readme

gimme_readme is a command-line tool powered by AI that generates a comprehensive README.md file for your project. It analyzes multiple source code files at once, providing concise explanations of each file's purpose, functionality, and key components, all in a single, easy-to-read document.

gimme_readme

gimme_readme is a command-line tool powered by AI that generates a comprehensive README.md file for your project. It analyzes multiple source code files at once, providing concise explanations of each file's purpose, functionality, and key components, all in a single, easy-to-read document.

See our 0.1 Release Demo!

1. Getting Started

To get started with gimme_readme, follow these steps:

Install the latest version of Node.js for your operating system.
Run the following command to install gimme_readme globally:
```
npm i -g gimme_readme
```
NOTE: MAC/LINUX users may need to run sudo npm i -g gimme_readme
Generate a configuration file by running in any folder you'd like:
```
gr-ai -c
```
This command creates a .gimme_readme_config file in your home directory. Do not move this file from this location.
Open the .gimme_readme_config file and add your API…

View on GitHub

My quick advice is to set everything I'm about to mention as soon as possible! It'll make your development experience as well as the development experience of others as seamless as possible.

Start with a License

Whether you want your project to be worked on by others or not, you should look into adding a license to your work. Your license will describe what others can or cannot do with your code, so I would highly suggest you think about this before creating your repository.

That said, I am not a lawyer, so I cannot disclose information on what's the best license for your use-case or provide any legal advice.

What I can say is that, I would start by reading the documentation that GitHub has provided here to set up a License for your project.

Add a main README.md file and have it link to other documentation when appropriate

Your README.md should provide a clear overview of your project and getting started instructions. For detailed topics that require in-depth explanation, create separate documentation files and link to them from your main README.md.

Recently, I have added a section to my README.md that links to the License I mentioned earlier. This would be a prime example of when you'd want to provide a link to something instead of explaining it directly in your README.md.

Add a `CONTRIBUTING.md` file & `CODE_OF_CONDUCT.md`

Since I have been invested with learning more about Open Source Development, I have come across two common files that are usually apparent in large, open-source projects:

CONTRIBUTING.md
CODE_OF_CONDUCT.md

These files appear to be fairly common with large projects and have a very well defined purpose (you can infer what they're about just from the names!).

You'll note that both of these files are quite lengthy, but at the same time focused. Having these files can help minimize the bloat of your main README.md file, which should explain the scope of your project, and direct others to appropriate resources when necessary.

Imagine you're a maintainer for a project and someone asks you for the steps on how to contribute.

If all your instructions were in your README.md file, you'd have to say, "Look at my README.md file and look for the contributing section".

In comparison, if you have a dedicated file to contributing, you can just say, "Please read CONTRIBUTING.md". That in of itself is a major time saver (believe it or not).

With regards to the CODE_OF_CONDUCT.md, it's nice to have a document that explains your expectations of others who interact with your project. Having a document like this serves as a safeguard for you to enforce rules of conduct on your project, and hopefully, gets others to behave properly.

As such, I would highly recommend creating these files to make your experience as a creator/maintainer of a project seamless.

I don't expect you all to re-invent the wheel when making a CONTRIBUTING.md file or CODE_OF_CONDUCT.md file.

My Professor, David Humphrey shared with my class a useful site which generates these files for you.

That is: https://generator.contributing.md/.

After discovering this site, I made a CONTRIBUTING.md file and CODE_OF_CONDUCT.md file and began simplifying my main README.md file.

Below is a screenshot that shows how much clutter was removed from my main README.md file now that I have dedicated files on how to contribute and how to conduct oneself in my repository:

For casual users of my tool, I believe this to be a lot less intimidating when trying to get the gist of my repository.

For people looking to develop, they'll be able to quickly scan my main README.md and know where to find guidelines on how to contribute and conduct themselves.

Now, I want to talk about adding static analysis tools to my project.

Add static analysis tools

Very early on in my project, I added static analysis tools which are essential utilities that analyze code without actually running it. These tools help maintain code quality, consistency, and catch potential issues early in development. Below, I have listed different types of static analysis tools and examples of these tools that I've used in gimme_readme.

NOTE: that since static analysis tools are built to analyze your code, there will be some folders or files that you do not want them to analyze (to save time in processing). I myself, had to make recent changes on what to ignore to speed up my development.

Linters (ESLint)

Linters analyze your code for potential errors, suspicious patterns, and style violations. ESLint helps enforce coding standards and catch bugs before they make it into production. For example, it can:

Detect unused variables
Find syntax errors
Enforce consistent code style
Identify potential runtime errors

Linters will help you spot potential problem areas when others contribute to your repo. They will often help you spot unneeded code (unused variables), and buggy code.

Below, is my Eslint config file, eslint.config.mjs with explanations on what it's doing:

// Import predefined global variables for different environments (browser, node, jest, etc.)
import globals from 'globals';
// Import ESLint's new flat config for JavaScript (includes recommended rules)
import pluginJs from '@eslint/js';

export default [
  // First config object: Define file patterns and module settings
  { 
    files: ['**/*.js'],           // Apply to all JavaScript files
    languageOptions: { 
      sourceType: 'module'        // Treat files as ES modules (enables import/export)
    } 
  },

  // Include ESLint's recommended ruleset
  // This adds common error-catching rules and best practices
  pluginJs.configs.recommended,

  // Configure language features and global variables
  {
    languageOptions: {
      ecmaVersion: 'latest',      // Use the latest ECMAScript features
      globals: {
        ...globals.commonjs,      // Add CommonJS globals (require, module, etc.)
        ...globals.es2021,        // Add ES2021 globals
        ...globals.node,          // Add Node.js globals
        ...globals.jest,          // Add Jest testing globals
      },
    },
  },

  // Define directories to ignore during linting
  {
    ignores: [
      'node_modules/**',          // Third-party dependencies
      '_examples/**',             // Example code directory
      '.husky/**',                // Husky git hooks
      '.git/**',                  // Git internals
      'coverage/**',              // Test coverage reports
    ],
  },
];

Formatters (Prettier)

Formatters automatically style your code according to predefined rules. Prettier handles all the formatting heavy-lifting, ensuring consistent:

Indentation
Line length
Quote usage
Comma placement

Formatters are particularly helpful to ensure that if multiple people are contributing to your repository, the code "reads the same", since everyone will have their code formatted correctly, using your style guide.

Below is my .prettierrc file, that defines the rules I wish to have with regards to formatting my code. Prettier will look at this file to understand the rules for formatting, and check if my source code files abide by these rules. NOTE: that the comments aren't valid in JSON, but I'm putting them here to explain what they do.

// .prettierrc
{
  // Controls whether parentheses are always added around a single arrow function parameter
  "arrowParens": "always",  // Example: (x) => x  vs  x => x

  // Adds spaces between brackets in object literals
  "bracketSpacing": true,   // Example: { foo: bar }  vs  {foo: bar}

  // Controls how Prettier formats quoted code embedded in the file
  "embeddedLanguageFormatting": "auto",  // Automatically formats code inside template literals

  // Line ending style (linefeed only)
  "endOfLine": "lf",  // Uses \n instead of \r\n (Windows style)

  // Whether to insert a special @format marker at the top of files
  "insertPragma": false,  // Won't add @format marker to formatted files

  // Controls how markdown text is wrapped
  "proseWrap": "preserve",  // Doesn't change wrapping of markdown text

  // Whether to only format files with a special @format marker
  "requirePragma": false,  // Formats all files, not just those with @format marker

  // Use single quotes instead of double quotes
  "singleQuote": true,    // Example: 'hello'  vs  "hello"

  // Number of spaces per indentation level
  "tabWidth": 2,          // Uses 2 spaces for each indent level

  // Adds trailing commas where valid in ES5
  "trailingComma": "es5", // Example: { foo: bar, }  vs  { foo: bar }

  // Whether to use tabs instead of spaces
  "useTabs": false,       // Uses spaces for indentation

  // Maximum line length before wrapping
  "printWidth": 100       // Wraps code at 100 characters
}

With Prettier, there is a concept of an ignore file, which will be used to tell Prettier which files to avoid when formatting. This file is the .prettierignore file, and mine is shown below:

# Generated files
node_modules/
package.json
package-lock.json
_examples/
.husky/

Pre-commit Hooks (Husky)

Pre-commit hooks are perhaps my favourite static analysis tool since they can ensure that your other static analysis tools are being used.

With regards to git, a pre-commit hook runs certain actions prior to your commit.

As I explained earlier, we have other static analysis tools such as a linter or formatter - however, there's _nothing enforcing a contributor from linting or formatting their code properly.

If you set up a pre-commit hook, you can enforce that any changes made to your repository (even locally on another user's machine), are formatted and linted properly.

I use Husky to write a very simple file that lets me describe the exact steps I want to run before someone commits a change to my repository. This file is found within the .husky folder, and is called "pre-commit". The content is shown below:

# .husky/pre-commit
npm run format
npm run lint
npm run test

By looking at this file, you'll see that husky runs the following before a commit:

a format script
a lint script
a test script

These npm scripts are defined in my package.json file:

...
  "scripts": {
    "test": "node --experimental-vm-modules node_modules/jest/bin/jest.js -c jest.config.js --runInBand",
    "lint": "eslint --config eslint.config.mjs \"./src/**/*.js\" \"tests/**/*.js\"",
    "format": "prettier --write \"./src/**/*.js\" \"tests/**/*.js\"",
    "coverage": "node --experimental-vm-modules node_modules/jest/bin/jest.js -c jest.config.js --runInBand --coverage",
    "prepare": "husky"
  },
...

Husky runs these commands for you before you commit, but users can also run these scripts directly into the command-line themselves.

The last thing I wanted to talk about was Editor Integration.

Editor Specific Integration

To make development smoother, I've included VSCode configuration files:

.vscode/extensions.json: Suggests recommended extensions for the project

{
  "recommendations": [
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "streetsidesoftware.code-spell-checker"
  ]
}

.vscode/settings.json: Ensures consistent editor settings across the team

{
  "editor.insertSpaces": true,
  "editor.tabSize": 2,
  "editor.detectIndentation": false,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll": "explicit"
  },
  "files.eol": "\n",
  "files.insertFinalNewline": true
}

.vscode/javascript.code-snippets: lets us define shortcuts that will type out repetitive pieces of code with a few characters. I made my own snippet which will print out a file path like // src/ai/ai.js in a JavaScript file when the user writes rpath in that file and presses "Enter".

{
  "Insert Current File Path Comment": {
    "prefix": "rpath",
    "body": ["// ${RELATIVE_FILEPATH/[\\\\]/\\//g}"],
    "description": "Inserts a comment with the relative path of the current file"
  }
}

These files help new contributors get set up quickly with the right tools and settings.

Conclusion

Implementing these best practices early in your open source project sets a strong foundation for both you and your future contributors. From establishing clear licensing and documentation structure to setting up robust static analysis tools, each element plays a crucial role in creating a professional and maintainable codebase.

While it might seem like a lot of upfront work, having proper licensing, well-organized documentation (README.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md), and automated tools (ESLint, Prettier, Husky) will save countless hours of manual work and reduce potential friction in the development process. These practices not only make your project more approachable for contributors but also help maintain high code quality as your project grows.

Remember: it's much easier to establish these practices at the start than to retrofit them into an existing project. Whether you're building a small tool or planning for a larger open source project, taking the time to implement these configurations early will pay dividends in the long run.

Just take a look at how many commits I needed to do to fix my project (if you set this up early, there will be less work in the future, I promise!):

It was too much for me to stare at, so I decided to squash my commits into one like so:

With that, that's pretty much everything I wanted to cover - organize your documents early and use static analysis tools. Happy programming!

Devlog: Hacktoberfest 2024 (4/4)

Peter Wan — Sat, 26 Oct 2024 01:23:34 +0000

Hello all! This is my final Hacktoberfest devlog for 2024.

To get more context with regards to this devlog, please see my other devlogs below:

In this final week of Hacktoberfest 2024, I wanted to challenge myself by contributing to larger open source projects. Specifically, I wanted to provide a pull request that involves a fix or a feature that is larger than just fixing a spelling mistake.

At the time of writing, I have made several pull requests, none of which have currently been merged or seen yet by the maintainers.

The work I did this week fell into several categories:

logging new issues for projects
requesting information on how to get started with an issue I logged, or requesting advice on fixing an existing issue
creating pull requests for issues that I felt like I had enough information to make an attempt

1. Logging new issues for projects

All the issues I worked on this week were related to Visual Studio Code extensions, since Visual Studio Code is my text-editor of choice.

One of the extensions that I use makes working with markdown easier. This extension is called, Markdown All in One on VSCode, but is known as vscode-markdown on GitHub.

Markdown All in One has a feature I really like, which is to convert markdown into HTML, but I noticed that I was having an issue where the conversion wasn't working how it used to.

It turns out that because I had another extension called, Markdown Preview Mermaid Support in Visual Studio Code enabled (known as vscode-markdown-mermaid on GitHub), I was unable to use the Markdown All In One's feature properly.

To that end, I logged 2 issues:

One for Markdown All In One
Another for Markdown Preview Mermaid Support

While I have yet to hear back from Markdown All In One from the time of writing, I was able to get a quick response from the maintainer of Markdown Preview Mermaid Support that this issue would not be investigated further because as of right now, the Markdown Preview Mermaid Support is only built to support the base Visual Studio Code settings.

So despite doing my best to log an issue and reproduce the problem, I was not able to gain enough information as of yet to contribute further to resolving this issue.

2. Requesting information on how to get started with an issue I logged or on an existing issue

My next step was trying to find existing issues on projects that I was interested in. I wanted to follow-up on an issue logged for Plasmo, a framework which is a framework for building browser extensions using React and TypeScript.

I found this issue, which had the issue of good first issue. I had no idea how to work on this issue at all, but I wanted to make an attempt to at least set up my development environment so I went straight to Plasmo's guide on how to contribute.

I found a small grammatical mistake which I thought I could fix quickly as I was tackling the main issue, so I raised an issue and made a pull request to fix the issue.

I didn't get a response for my pull request that fixes the grammatical mistake, or any word on how to tackle the original issue in question, but hope to soon.

3. Creating some pull requests when I had enough information to work off of

Because of how hard it was for me to find an issue that I could actually contribute to, I reached out to my Professor for some guidance. He was able to find this issue for a Visual Studio Code extension that I use every day - a spell checker. In Visual Studio Code, the extension is known as Code Spell Checker, and on GitHub, the repository is called,
vscode-spell-checker.

After taking the time to sit with the code and go through some of the commit history, I was able to find another pull request that contained a solution that I think was essentially what I needed to do in my very own pull request.

As such, I studied the changes made in that pull request, and made my own pull request which references the fix from the other pull request.

And with that, I had finally made a contribution that in my mind, met the requirements that I was trying to meet, which was to contribute to a large open-source project and contribute something other than a fix for a simple spelling mistake.

While this pull request still hasn't been processed by a maintainer, I am hopeful that the fix will go well, given that I more or less followed the example from one of the maintainer's commits.

With all of this said - I want to conclude this series of devlogs for Hactkoberfest 2024.

It was a great experience working on small, medium, and large sized projects. I feel like I've gained a little bit more mastery over git and GitHub, and know how to use these tools to my advantage now. In addition, I feel a lot more comfortable searching for solutions and reading code, by virtue of viewing all sorts of different open source repositories.

My immediate hope is to get some feedback from the maintainers for the different issues/pull requests I currently made, but my long-term hope is that in the near future, I can work more closely with a repository of my choosing, and make important and vital changes/improvements that will better the repository and help its community of users.

Devlog: Hacktoberfest 2024 (4/4)

Peter Wan — Sat, 26 Oct 2024 01:23:34 +0000

Hello all! This is my final Hacktoberfest devlog for 2024.

To get more context with regards to this devlog, please see my other devlogs below:

At the time of writing, I have made several pull requests, none of which have currently been merged or seen yet by the maintainers.

The work I did this week fell into several categories:

logging new issues for projects
requesting information on how to get started with an issue I logged, or requesting advice on fixing an existing issue
creating pull requests for issues that I felt like I had enough information to make an attempt

1. Logging new issues for projects

All the issues I worked on this week were related to Visual Studio Code extensions, since Visual Studio Code is my text-editor of choice.

One of the extensions that I use makes working with markdown easier. This extension is called, Markdown All in One on VSCode, but the is known as vscode-markdown on GitHub.

Markdown All in One has a feature I really like, which is to convert markdown into HTML, but I noticed that I was having an issue where the conversion wasn't working how it used to.

It turns out that because I had another extension called, Markdown Preview Mermaid Support in Visual Studio Code enabled vscode-markdown-mermaid, I was unable to use the Markdown All In One's feature properly

To that end, I logged 2 issues:

One for Markdown All In One
Another for Markdown Preview Mermaid Support

So despite doing my best to log an issue and reproduce the problem, I was not able to gain enough information as of yet to contribute further to resolving this issue.

2. Requesting information on how to get started with an issue I logged or on an existing issue

I found a small grammatical mistake which I thought I could fix quickly as I was tackling the main issue, so I raised an issue and made a pull request to fix the issue.

I didn't get a response for my pull request that fixes the grammatical mistake, or any word on how to tackle the original issue in question, but hope to soon.

3. Creating some pull requests when I had enough information to work off of

As such, I studied the changes made in that pull request, and made my own pull request which references the fix from the other pull request.

While this pull request still hasn't been processed by a maintainer, I am hopeful that the fix will go well, given that I more or less followed the example from one of the maintainer's commits.

With all of this said - I want to conclude this series of devlogs for Hactkoberfest 2024.

DEV Community: Peter Wan

Coming Full Circle: It starts and ends with Git and GitHub

The Project

NirmalScaria / le-git-graph

Browser extension to add git graph to GitHub website.

Le Git Graph - Commits Graph for GitHub

Demo

Installation

Setup for Private Repos owned by an Organization

The Challenge

The Learning Journey

Technical Deep Dive

Results and Achievements

Conclusion of my experience of the Topics in Open Source 2024 course

Continuous contributions

code-charity / youtube

«Improve YouTube!»

Learning by Doing: working on ImprovedTube

My plan of attack for learning about extensions in general

The family of issues I think would be good for me to tackle on ImprovedTube

Conclusion

Re-publishing gimme_readme to npm with GitHub Actions

Why download code from a registry? Why not just go to GitHub?

Re-publishing my code to npm

To .npmignore or to not .npmignore? That is the question.

Adding a GitHub action to publish my code to npm when I add a new release

Testing with Uday

The journey never ends... but that's what makes it fun!

Working on a browser extension

code-charity / youtube

«Improve YouTube!»

How I tried to approach the codebase

Contributing to expressjs

Where I'm at right now

How I want to improve as an open source developer

Understanding the project's scope

Understanding the issue at hand

Understanding how to setup the project locally

Tackling the issue

Waiting to merge changes and learning to get involved with discussions

Learning to Grow as an Open Source Developer

# From Jest to Pytest: A JavaScript Developer's Journey into Python Testing

From Jest to Pytest: A JavaScript Developer's Journey into Python Testing

Testing Python code with pytest

Final Thoughts

Testing LLM Applications: Misadventures in Mocking SDKs vs Direct HTTP Requests

Introduction

The Context

My Testing Journey

The Initial Approach

The Challenge: Testing LLM Interactions

The SDK vs Direct HTTP Requests Dilemma

Lessons Learned

Going Forward

Conclusion

Hacktoberfest 2024: A retrospective

Master Git Fundamentals

Familiarize yourself with Searching for Projects and looking through them

Conclusion

Tips on Improving an Open Source Project

peterdanwan / gimme_readme

gimme_readme is a command-line tool powered by AI that generates a comprehensive README.md file for your project. It analyzes multiple source code files at once, providing concise explanations of each file's purpose, functionality, and key components, all in a single, easy-to-read document.

gimme_readme

Table of Contents

1. Getting Started

Start with a License

Add a main README.md file and have it link to other documentation when appropriate

Add a CONTRIBUTING.md file & CODE_OF_CONDUCT.md

Add static analysis tools

Linters (ESLint)

Formatters (Prettier)

Pre-commit Hooks (Husky)

Editor Specific Integration

Conclusion

Devlog: Hacktoberfest 2024 (4/4)

1. Logging new issues for projects

2. Requesting information on how to get started with an issue I logged or on an existing issue

3. Creating some pull requests when I had enough information to work off of

Devlog: Hacktoberfest 2024 (4/4)

1. Logging new issues for projects

Conclusion of my experience of the `Topics in Open Source 2024` course

To `.npmignore` or to not `.npmignore`? That is the question.

Adding a GitHub action to publish my code to `npm` when I add a new release

Testing Python code with `pytest`

Add a `CONTRIBUTING.md` file & `CODE_OF_CONDUCT.md`