DEV Community: AnhChienVu

Create a Pull Request for a new Feature of ImprovedTub

AnhChienVu — Fri, 06 Dec 2024 01:36:23 +0000

After 2 weeks contributing to the open-source project ImprovedTub, I am excited to share my Pull Request for the new feature.

To recap the work I've over the past 2 weeks, you can refer to the following blog posts:

In this blog, I will walk you through the code, steps and key learnings I've gained from this experience.

Implementing the Details Switch

Upon reviewing the source code, I discovered that all the sub-menu features represented in the extension were listed under the menu/skeleton-parts folder:

UI's Extension:

Since I was implementing the feature to display the details of the currently playing video, along with its associated channel information, I decided to introduce a new switch within the channel.js file. This file is responsible for defining the structure of the UI of Channel component, and in this case, it manages the behavior of the Channel button:

extension.skeleton.main.layers.section.channel = {
    component: 'button',
    variant: 'channel',
    category: true,
    on: {
        click: {
            // Other buttons ...
            ,channel_details_button: {
                component: 'switch',
                text: 'Details',
                value: false, // Default state is off
                on: {
                    change: async function (event) {
                        const apiKey = "YOUR_API_KEY";
                        const switchElement = event.target.closest('.satus-switch');
                        const isChecked = switchElement && switchElement.dataset.value === 'true';

                        // Store the switch state in chrome.storage.local
                        chrome.storage.local.set( { switchState: isChecked } );

                        try {
                            const videoId = await getCurrentVideoId();
                            const videoInfo = await getVideoInfo(apiKey, videoId);

                            const channelId = videoInfo.snippet.channelId
                            const channelInfo = await getChannelInfo(apiKey, channelId);

                            chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
                                //console.log("Sending message to content.js");
                                chrome.tabs.sendMessage(tabs[0].id, {
                                    action: isChecked ? 'append-channel-info' : 'remove-channel-info',
                                    channelName: channelInfo.channelName,
                                    uploadTime: new Date(videoInfo.snippet.publishedAt).toLocaleString(),
                                    videoCount: channelInfo.videoCount,
                                    customUrl: channelInfo.customUrl
                                })
                            });
                        } catch (error){
                            console.error(error);
                        }
                }
          }
    }
}

In the partial snippet code above, you will notice that I used a placeholder for the YOUTUBE_API_KEY. As mentioned in my Progress blog, I was unable to implement .env variable within a Chrome Extension. Therefore, to ensure the feature works correctly, the maintainer will need to generate an API key here. During development, I used my own API key for testing purposes; however, I could not include it in the source code for security reasons.

Next, I needed to track the state of the switch. To achieve this, I set its default value to false via the value attribute. I then implemented the necessary logic to track its state within the on { change:..} event listener. Since this function require fetching video data from the API, it needed to be asynchronous. To ensure the switch's state remains persistent, I saved it to Chrome's local storage using the following method:

chrome.storage.local.set({})

To adhere the DRY (Dont' Repeat Yourself) principle, I modularized the code into smaller functions, such as getCurrentVideoId(), getVideoInfo(), and getChannelInfo(), each responsible for fetching specific video data. Once all the required information is gathered, I passed it to the content.js file (which I will explain further below). The content.js file checks if the switch is on; if so, it displays the details, otherwise, it remains hidden.

These are all support function to get the Video data:

async function getCurrentVideoId() {
    return new Promise((resolve, reject) => {
        chrome.storage.local.get('videoId', (result) => {
            //console.log('Retrieved video ID from storage:', result.videoId); // Debugging log
            if (result.videoId) {
                resolve(result.videoId);
            } else {
                reject('Video ID not found');
            }
        });
    });
}

async function getVideoInfo(apiKey, videoId) {
    const response = await fetch(`https://www.googleapis.com/youtube/v3/videos?id=${videoId}&key=${apiKey}&part=snippet,contentDetails,statistics,status`);
    const data = await response.json();
    const video = data?.items[0];

    return video;
}

async function getChannelInfo(apiKey, channelId) {
    const response = await fetch(`https://www.googleapis.com/youtube/v3/channels?id=${channelId}&key=${apiKey}&part=snippet,contentDetails,statistics,status`);
    const data = await response.json();
    const channel = data.items[0];
    const customUrl = channel.snippet.customUrl;
    const channelName = channel.snippet.title;
    const videoCount = channel.statistics.videoCount;

    return {channelName, videoCount, customUrl};
}

After adding Details switch, the UI will look as this:

Coding `content.js` file

As mentioned in my Progress post, the content.js file is responsible for managing the UI of the webpage. Specially, this file handles the logic to track the state of the switch, which is sent from the channel.js as well as backend.js. The goal is to ensure the extension can maintain and reflect the switch's state across various scenarios. For instance, if a user turns on the switch while on a different webpage (not Youtube), the extension should retain this state when the user navigates to the YouTube page and display the details block accordingly. Similarly, if the switch is turned off, it should remain off upon navigating to YouTube.

To achieve this, all the primary logic is implemented after the DOM is fully loaded. Once the DOM is ready, I listen for changes in the video URL to ensure the extension correctly updates the displayed details. This enables the extension to send the updated Video ID whenever a user switches to a new video:

let previousVideoId = getVideoIdFromUrl();

    // Listen for changes in the video URL and send the updated video ID
    const observer = new MutationObserver(() => {
        const currentVideoId = getVideoIdFromUrl();
        if (currentVideoId !== previousVideoId) {
            previousVideoId = currentVideoId;

            sendVideoIdToBackground();

            checkSwitchStateAndFetchData();
        }
    });
    observer.observe(document.body, { childList: true, subtree: true });

However, this approach only addresses the scenario where the video ID in the URL changes. It does not handle the case where the video remains the same, but the user adjusts the switch from a different tab. To resolve this, I devised another solution: listen for visibility changes to handle page navigation. This means that when the users navigate to another page and toggle the switch, the extension will ensure that when they return to the YouTube page, the details switch will still function correctly - either displaying or hiding the details area based on the switch's state.

// Listen for visibility changes to handle page navigation
    document.addEventListener('visibilitychange', function() {
        if (document.visibilityState === 'visible') {
            checkSwitchStateAndFetchData();
        }
    });

I will need to combine both of these solution to fix all the edge cases that may happen with the switch function, and to DRY the code, I modularized the function checkSwitchStateAndFetchData() as a support function:

// Check if the switch is on and fetch new data. Otherwise, remove the details block
function checkSwitchStateAndFetchData() {
    chrome.runtime.sendMessage({ action: 'check-switch-state' }, function(response) {
        if (response.isSwitchOn) {
            chrome.runtime.sendMessage({ action: 'fetch-new-data' });
        } else {
            // Remove existing video details if the switch is off
            const targetElement = document.querySelector('.channel-info')
            if (targetElement) {
                targetElement.remove();
            }
        }
    });
}

Since content.js needs to communicate with backend.js through the messaging system, it listens for messages from the backend to determine when to display the details area. To ensure the details are updated when the user switches to another video, the extension will remove the existing details before adding the new ones.

backend.js sends 2 actions to content.js to notify it of the switch's state:

append-channel-info: This action is sent when the switch is turned on, signaling that the details should be displayed.
remove-channel-info: This action is sent when the switch is turned off, indicating that the details should be hidden.

chrome.runtime.onMessage.addListener(function (message, sender, sendResponse) {
        //console.log('Received message from background:', message); // Debugging log
        if (message.action === 'append-channel-info') {
            //console.log('Switch on Details mode'); 
            const {channelName, uploadTime, videoCount, customUrl} = message;
            const channelInfo = createChannelInfo(channelName, uploadTime, videoCount, customUrl);
            const targetElement = document.querySelector('ytd-video-owner-renderer.style-scope.ytd-watch-metadata');
            if (targetElement) {
                // Removing existing channel info if present
                const existingChannelInfo = targetElement.querySelector('.channel-info');
                if(existingChannelInfo) {
                    existingChannelInfo.remove();
                }
                targetElement.appendChild(channelInfo);
            } else {
                console.error('Target element not found');
            }
        } else if (message.action === 'remove-channel-info') {
            //console.log('Switch off Details mode');
            const targetElement = document.querySelector('.channel-info');

            if(targetElement) {
                targetElement.remove();
            } else {
                console.error('Channel info element not found');
            }
        }
    });

Exploring `backend.js` file

I'd like to once again thank the maintainer for providing clear comments throughout the code, which made it easy to identify where the messages sent from content.js are handled. In this section, I added 3 new action cases: store-video-id, check-switch-state, and fetch-new-data.

store-video-id: Upon receiving this action from content.js, the backend is responsible for storing the video ID in local storage. Once this is done, the backend sends a response message back to content.js, confirming that the request has been fulfilled. Notably, the return true statement is crucial here, as it ensures that sendResponse is called asynchronously. Without this, sendResponse would not function as expected.

case 'store-video-id':
//console.log('Storing video ID:', message.videoId); // Debugging log
if (message.videoId) {
    chrome.storage.local.set({ videoId: message.videoId }, function() {
    sendResponse({ status: 'success' });
} else {
    sendResponse({ status: 'error', message: 'No video ID provided' });
}
return true; // Indicates that sendResponse will be called asynchronously

check-switch-state: As discussed earlier, tracking the switch state is important. In this case, the backend retrieves the current state of the switch from local storage (where it was set by content.js) and sends it back to content.js.

case 'check-switch-state':
    chrome.storage.local.get('switchState', function(result) {
    sendResponse( {isSwitchOn: result.switchState});
    }); 
    return true;

fetch-new-data: This action is triggered when content.js detects that the user has switched to a new video. The backend then fetches the relevant data for the new video. The logic here mirrors the process used in content.js to fetch video data, ensuring consistency across both components.

case 'fetch-new-data':
            chrome.storage.local.get('videoId', async function(result) {
                const videoId = result.videoId;
                const apiKey = "AIzaSyA0r8em0ndGCnx6vZu1Tv6T0iyLW4nB1jI"; // Replace with your YouTube Data API key
                try {
                    const videoInfo = await getVideoInfo(apiKey, videoId);
                    const channelId = videoInfo.snippet.channelId;
                    const channelInfo = await getChannelInfo(apiKey, channelId);

                    chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
                        //console.log("Sending message to content.js");
                        chrome.tabs.sendMessage(tabs[0].id, {
                            action: 'append-channel-info',
                            channelName: channelInfo.channelName,
                            uploadTime: new Date(videoInfo.snippet.publishedAt).toLocaleString(),
                            videoCount: channelInfo.videoCount,
                            customUrl: channelInfo.customUrl
                        });
                    });
                } catch (error) {
                    console.error(error);
                }
            });
            return true;

Finally

There are all steps that I worked through to implement this feature, and here is the final outpu

In the area marked in red, I display the release time and date of the video, as well as the total number of videos posted by the channel. Additionally, I used an SVG icon to represent the "All Videos" link. When the user clicks on this icon, they are redirected to the video's channel. Another icon, representing "More Information," directs the user to a page where they can input a video link, after which all the video details are populated.

Continuous Progress in Adding new Feature for ImprovedTub

AnhChienVu — Fri, 29 Nov 2024 18:39:11 +0000

This week marks the beginning of my work on a new feature, as outlined in my previous blog post on Planning Step. The goal is to enhance user experience by introducing a toggle switch button, allowing users to enable or disable the display of detailed information about a played video and its associated channel.

To implement this feature, I began by diving into the foundational files used in developing a Chrome Extension, specially:

manifest.json
content.js
background.js

Each of these files plays a critical role in defining the behavior and structure of the extension. Below, I'll delve deeper into how I explored and utilized these components.

Exploring the `manifest.json` file

The manifest.json file is the cornerstone of any Chrome Extension. It serves as the configuration file that defines essential settings for the extension. For ImprovedTub, this file includes configurations like "background" scripts, content_scripts, permission and more. Without a properly configured manifest.json file, the extension simply cannot function.

These fields describes the extension:

permissions field specify the scope of the extension's functionality. For example, to interact with Youtube's DOM or store user preferences, we need to explicitly request access in the manifest:

The host_permissions field tells that this extension is only dealing with Youtube pages:

The background field specify scripts that run in the background, maintaining the persistent state of the extension. For ImprovedTub, this is crucial for managing event listeners and controlling features like toggle button. The background.js is a JavaScript file that will run separately from the web browser thread, the service_worker would not have access to content of web page, but it has capabilities to speak with the extension using the extension messaging system.

The content_scripts field define the scripts that will run within the context of the web pages. This is where we inject the logic to manipulate the user interface, such as adding the toggle button and displaying or hiding the details block.

The default_popup field tells me what html file will be served as the Extension's UI:

Adding Switch buton

After having some knowledges about files' structure and purpose via the manifest.json, I started adding a switch button named Details inside the menu/skeleton-parts/channel.js file:

channel_details_button: {
                component: 'switch',
                text: 'Details',
                value: false, // Default state is off
                on: {
                    change: async function (event) {
                        const apiKey = YOUTUBE_API_KEY;
                        const switchElement = event.target.closest('.satus-switch');
                        const isChecked = switchElement && switchElement.dataset.value === 'true';
                        console.log(isChecked)
                        try {
                            const videoId = await getCurrentVideoId();
                            const videoInfo = await getVideoInfo(apiKey, videoId);

                            const channelId = videoInfo.snippet.channelId
                            const channelInfo = await getChannelInfo(apiKey, channelId);

                            chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
                                console.log("Sending message to content.js");
                                chrome.tabs.sendMessage(tabs[0].id, {
                                    action: isChecked ? 'append-channel-info' : 'remove-channel-info',
                                    channelName: channelInfo.channelName,
                                    uploadTime: new Date(videoInfo.snippet.publishedAt).toLocaleString(),
                                    videoCount: channelInfo.videoCount,
                                    customUrl: channelInfo.customUrl
                                })
                            });
                        } catch (error){
                            console.error(error);
                        }
                    }
                }
            }

And it will look as:

When switch is off:

When switch is on:

At this stage, I am unsure how to use environment variables to store the YOUTUBE_API_KEY, as the Chrome Extension project is not built with Node.js, making it impossible to use the dotenv package. As a workaround, I plan to leave a note for the maintainer to manually add an API key to the placeholder for enabling API requests. Within the change function, I attempted to fetch video information using the Youtube API via the videoID. Once the data is retrieved, I used the chrome.tabs.query function to send it to content.js, enabling the UI to display the video details

Adding `content.js` file

To implement the toggle functionality, I added a new JavaScript file under js field in the manifest.json file. This content.js file will serves as a bridge for interacting with the main thread of web pages, such as injecting UI elements or handling DOM manipulations. However, at this stage, I faced a decision regarding the file's placement within the existing project structure.

While exploring the repository, I noticed a pattern: all JavaScript files referenced in the js field for web page interactions were located under the js&css/extension/ directory. Although this structure wasn't explicitly documented, it appeared to be the convention followed by the maintainers.

Based on this observation, I decided to create the content.js file within the same directory to maintain consistency.

Adding event listener in `background.js` file

This file will need to handle and send response back to the content.js. Inside this file, maintainer marked a note for MESSAGE LISTENER part where I will code to handle the message type from content.js:

/*--------------------------------------------------------------
# MESSAGE LISTENER
--------------------------------------------------------------*/
chrome.runtime.onMessage.addListener(function (message, sender, sendResponse) {
    //console.log(message);
    //console.log(sender);
    console.log('Message received in background:', message);

    switch (message.action || message.name || message) {
        ...
        case 'store-video-id':
            console.log('Storing video ID:', message.videoId); // Debugging log
            if (message.videoId) {
                chrome.storage.local.set({ videoId: message.videoId }, function() {
                    console.log('Video ID stored:', message.videoId); // Debugging log
                    sendResponse({ status: 'success' });
                });
            } else {
                sendResponse({ status: 'error', message: 'No video ID provided' });
            }
            return true; // Indicates that sendResponse will be called asynchronously

            case 'fetch-new-data':
                chrome.storage.local.get('videoId', async function(result) {
                    const videoId = result.videoId;
                    const apiKey = "AIzaSyA0r8em0ndGCnx6vZu1Tv6T0iyLW4nB1jI"; // Replace with your YouTube Data API key
                    try {
                        const videoInfo = await getVideoInfo(apiKey, videoId);
                        const channelId = videoInfo.snippet.channelId;
                        const channelInfo = await getChannelInfo(apiKey, channelId);

                        chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
                            console.log("Sending message to content.js");
                            chrome.tabs.sendMessage(tabs[0].id, {
                                action: 'append-channel-info',
                                channelName: channelInfo.channelName,
                                uploadTime: new Date(videoInfo.snippet.publishedAt).toLocaleString(),
                                videoCount: channelInfo.videoCount,
                                customUrl: channelInfo.customUrl
                            });
                        });
                    } catch (error) {
                        console.error(error);
                    }
                });
                return true;    

        }
});

I added 2 cases to handle events as store-video-id and fetch-new-data. As explained in manifest.json file that I used the chrome.storage to store the videoId to browser, and will fetch video's data based on this id.

Conclusion

So far, I’ve implemented most of the feature, but there’s still work to be done. I need to address a bug where the details section does not always reflect the toggle switch's status, especially when the switch is toggled on or off from a non-YouTube page. To fix this, I’ll need to add a mechanism to consistently check the switch’s state and ensure the UI aligns with it. Additionally, I need to dive deeper into the project’s code structure to determine the best place for my changes. Currently, my implementation is explicit and self-contained, but the maintainers follow a different coding style. To align with their approach, I’ll need to refactor my code to integrate seamlessly with the existing structure while maintaining the new feature’s functionality.

Exploring ImprovedTube: A Beginner's Journey into Open Source Chrome Extensions

AnhChienVu — Thu, 21 Nov 2024 23:00:08 +0000

This marks my first experience working on a Chrome Extension project. The extension, called ImprovedTube, enhance the Youtube user experience by offering a wide range of customization options. Users can tailor their preferences, manage content discovery, adjust themes, and refines the UI, giving them full control over their Youtube interaction.

ImprovedTube has been in development since 2019 and is an open-source project with contributions from volunteer developers worldwide. Its longevity and active maintenance make it an intriguing project to explore.

Why I chose ImprovedTube

When selecting a project to contribute to for my Release0.4 at school, several factors about ImprovedTube stood out:

1. Community and activity

The GitHub repository boasts over 3.5k Stars and 542 folks, indicating a strong community interest.
The project has seen 69 releases, with the latest release occurring just one month ago.

These metrics demonstrate an active and engaged community and a dedicated maintainer team still driving the project forward.

2. Real-world impact

ImprovedTube is not just a development experiment - it's a production-ready extension available for immediate use. You can install it via the Chrome Web Store and experience it features. Contributing to a project already in the hands of users was a significant motivator, as it gave my work tangible value

Overcoming the Learning Curve

Since this was my first experience developing a Chrome extension, I initially felt overwhelmed by the unfamiliar structure and file organization. Fortunately, I found a helpful Youtube tutorial that explained how to approach Chrome Extension projects. This video provided insights into common file structures and code organizations, helping me break the ice and start exploring the repository more effectively.

My contribution

After browsing the project's open issues, I came across an enhancement request that piqued my interest. This feature would add:

Detailed metadata about Youtube videos, including the published date and links to all videos on the channel.
Tools to make navigating and analyzing Youtube channel more efficient.

This task resonated with me because it allowed me to contribute something both functional and impactful while expanding my technical knowledge.

Goals and Reflections

Through this contribution, I aim to:

Gain hands-on experience in developing Chrome extensions.
Learn how to navigate and contribute to a large, existing codebase.
Build confidence in open-source collaboration by contributing to a real-world product used by thousands of users.

Working on ImprovedTube has been an exiting challenge, and I look forward to seeing how my contributions evolve as I continue to explore the world of open-source Chrome extensions.

VShell: Production Release Workflow

AnhChienVu — Tue, 19 Nov 2024 20:05:37 +0000

This week, I am preparing to release my command-line tool, VShell, to production. This release will enable users to install and use VShell directly via npm without the need to clone and build the project locally. Written in JavaScript with Node.js, the tool will be hosted on npm for ease of distribution. Below is a detailed breakdown of the steps I followed to achieve this release:

Automating the Build Process

To ensure a reproducible and automated build, I created a build.js script in the root of the project. This script copies all necessary files into a dist folder, simplifying the build process.

Besides, I also set up a script to run it in package.json:

"build": "node build.js"

To run it, just need to type: npm run build on the console

Currently, I just wanted to demonstrate a simply build as copying files, but in the future, if I implemented with the UI, then I would need to use template bundle script as barbel.

Implementing Semantic Versioning

Previously, I often forgot to update the project version after making changes. For this release, I adopted Semantic Versioning to clearly communicate changes in the project API.

Given the significant updates since v0.0.1, I set the version to v1.0.0 by updating the version field in package.json. This version reflects a stable API with breaking changes and new features.

Tagging the Release in Git

To synchronize the version update with GitHub releases, I created a Git tag for v1.0.0:

git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin --tags

This ensures that the release is properly tracked in the Git repository.

Declaring Package Files

To publish VShell as an npm package, I explicitly defined the files to include in the package using the files field in package.json. This ensures that only the necessary files and directories are included in the published package.

Example:

Publishing to npm

To publish VShell on npm:

Sign Up and Log In: I created an npm account and logged in using: npm login
Publishing: Once authenticated, I published the package: npm publish

This made VShell available to users via npm.

Out of scope updates

GitHub Dependabot flagged a security issue with the transitive dependency cross-spawn. Since I didn’t install it directly, I used:

npm ls cross-spawn

to identify which package depended on it. I discovered that eslint was the source and resolved the issue by updating eslint to the latest version.

Additionally, I updated the README.md to provide clear installation instructions for npm users. I also improved the CONTRIBUTING.md file to guide contributors on setting up and running VShell locally.

To enhance accuracy, I incorporated feedback from Prof. David Humphrey, expanding and clarifying the GROQ system documentation.

Automating Releases with GitHub Actions

To streamline the release process, I added a job to my GitHub Actions workflow to automate npm publishing whenever a new tag is pushed.

Workflow Addition:

release:
    needs: build

    runs-on: ubuntu-latest

    if: startsWith(github.ref, 'refs/tags/')

    permissions:
      contents: write

    steps:
    - name: Checkout code
      uses: actions/checkout@v4

    - name: Setup Node.js
      uses: actions/setup-node@v4
      with:
        node-version: 22.x
        registry-url: 'https://registry.npmjs.org'

    - name: Install dependencies
      run: npm ci

    - name: Build project
      run: npm run build

    - name: Update version
      run: npm version ${{ github.ref_name}} --no-git-tag-version

    - name: Publish to npm
      run: npm publish
      env: 
        NODE_AUTH_TOKEN: ${{secrets.NPM_AUTH_TOKEN}}

    - name: Create GitHub release
      uses: softprops/action-gh-release@v1
      with:
        name: Release ${{ github.ref_name}}
        draft: false
        prerelease: false
        token: ${{ secrets.GITHUB_TOKEN }}

Key Features:

Conditional Trigger: The release job is triggered only when a tag (v*.*.*) is pushed.

npm Authentication: Using a secure NPM_AUTH_TOKEN stored in GitHub Secrets. You can create this token by going to your npm account and choose Access Token section.

GitHub Release: Automatically generates a release using softprops/action-gh-release.

Conclusion

By following these steps, I successfully automated the release of VShell to npm. Users can now install and use the tool effortlessly via:

npm install -g vshell

This streamlined process, coupled with proper versioning, dependency management, and documentation updates, ensures a professional and user-friendly release of VShell.

Working with GitHub OAuth Authentication

AnhChienVu — Fri, 15 Nov 2024 22:29:41 +0000

Hello everyone,

In this blog post, I’ll discuss my second pull request (PR) as part of the Release 0.3 series for my assignment. This PR continues my work on the GitExplorer project, which I initially contributed to during the Hacktoberfest event. For this week issue, the project maintainer requested the implementation of GitHub authentication functionality.

Overview of GitExplorer

GitExplorer is a project aimed at simplifying interactions with GitHub repositories. If you’re interested in learning more about the project or my previous contributions to it, feel free to check out my previous blog post for this repository.

The specific issue I tackled this time was the lack of GitHub authentication in the application. This limitation prevented the app from providing personalized features like starring repositories. My task was to implement a GitHub authentication feature that enables users to log in and log out using their GitHub accounts. Additionally, users would be able to star their favorite repositories and fetch a list of all their starred repositories with a simple button click.

Challenges: Working Without a UI Framework

GitExplorer does not use any modern UI frameworks like React. Instead, it relies solely on vanilla JavaScript, CSS, and HTML. While this simplicity has its advantages, it required me to dedicate more time to the issue as the original codebase was front-end focused. Adding GitHub authentication and related backend functionality meant venturing beyond the existing structure and implementing a server-side solution.

Migrating the Project and Setting Up the Backend

To support the new features, I first restructured the project. I moved all existing front-end code into a public folder and created a backend folder to house the server-side implementation. For the backend, I chose the Express framework as it integrates well with Passport.js, a library I used to handle GitHub authentication.

The steps included:

Setting up Express to serve the application.
Configuring Passport.js to handle authentication using CLIENT_ID and CLIENT_SECRET, which I stored in an .env file for security.
Adding routes to manage user actions like starring and unstarring repositories.

GitHub API Integration

After setting up the backend, I integrated GitHub’s API to support the required functionality. This included:

Enabling users to log in via their GitHub accounts.
Adding the ability to star and unstar repositories directly from the application.
Fetching a list of the user’s starred repositories and displaying them on a dedicated page, accessible through a button on the UI.

Writing Modular, DRY Code

Beyond implementing functionality, I focused on improving code quality by applying the DRY (Don’t Repeat Yourself) principle. I modularized the code by separating functions into reusable components, making it easier to maintain and extend in the future.

Lessons Learned and Looking Ahead

This was my first experience working with GitHub authentication, and it provided valuable insights into integrating third-party APIs and managing backend services. While the project initially appeared simple, working on both the front-end and back-end gave me a deeper understanding of full-stack development.

GitExplorer still has many interesting issues open for collaboration. If time permits, I plan to contribute further. The project has proven to be beginner-friendly while offering ample opportunities to learn new technologies and concepts.

Thank you for reading, and I hope this post inspires you to explore similar opportunities for learning and growth.

Keep continuing with Open Source Development

AnhChienVu — Tue, 12 Nov 2024 19:47:45 +0000

Hello everyone, in this Release 0.3, I am focusing on two primary tasks. The first Pull Request I have chosen to address involves implementing a responsive navigation bar for the Dazzle-and-Delight project.

Project Overview

The Dazzle-and-Delight repository hosts a web-based event management platform. This platform allows users to browse information about both past and upcoming events. The website is built using JavaScript, HTML, and CSS, and contains approximately seven pages that require updates to ensure the navigation bar is fully responsive across various screen sizes.

Work Details

While the project itself is relatively straightforward, the scope of work required for this task was more substantial. Specifically, I needed to implement a responsive navigation bar that adjusts to smaller screen sizes (e.g., mobile phones and tablets).

To address this, I introduced a hamburger menu that, when clicked, reveals a vertical list of navigation sections. This menu is only displayed on screen sizes with a width of 768px or smaller. The implementation involved updating 14 files in total.

For better code organization and ease of debugging, I created a new file, navbar_menu.js, which handles the event listeners for the menu button:

document.getElementById('menu-bar').addEventListener('click', function () {
  console.log('click');
  document.getElementById('section-list').style.display =
    document.getElementById('section-list').style.display === 'none'
      ? 'block'
      : 'none';
});

document.getElementById('close-menu-btn').addEventListener('click', function () {
  document.getElementById('section-list').style.display = 'none';
});

My PR: Make the navbar responsive

Implementation Steps for Each HTML File:

Add a section element with the id="section-list" under the <nav> tag. This section is responsible for displaying the vertical navigation when the hamburger menu is clicked.

Include the script <script src="js/navbar_menu.js"></script> at the bottom of each HTML file. This script manages the show/hide functionality of the vertical navigation menu upon user interaction.

Conclusion:

While the project itself is not overly complex, the number of files affected by this change presented a considerable challenge. Compared to previous Pull Requests in this course, this task required more extensive file modifications. Although it may not be the most technically difficult task I've undertaken, the volume of updates made demonstrates progress in my open source contributions.

Implementing a CI Pipeline for VShell with GitHub Actions

AnhChienVu — Tue, 12 Nov 2024 04:13:10 +0000

Introduction

This week, I delved into setting up a Continuous Integration (CI) pipeline using GitHub Actions while also expanding my suite of unit tests for my project, VShell. The process has enhanced my understanding of CI principles, automated testing, and the tools that help developers ensure reliable code delivery.

What is Continuous Integration?

Continuous Integration is a development practice where code changes are automatically tested and integrated into a shared repository frequently. By leveraging a CI pipeline, developers can detect and address issues early in the development cycle, improving code quality and reducing integration risks. A CI/CD pipeline allows us to build, test, and deploy applications automatically, accelerating development and increasing reliability.

Setting Up the CI Pipeline with GitHub Actions

There are numerous CI tools available—Jenkins, CircleCI, TravisCI, and GitLab CI, among others—but for this week, I focused on GitHub Actions to implement CI/CD for my application. GitHub Actions offers an integrated, straightforward setup directly in GitHub, making it a great choice for my project.

Configuring GitHub Actions for My Project To set up a CI pipeline, I navigated to the Actions tab of my GitHub repository and selected the Node.js template, as my application is JavaScript-based and runs on Node.js. This generated a .yml configuration file that defines the CI pipeline’s behavior.

Understanding the YAML Configuration For those new to CI, the .yml file might seem intimidating. Here’s a breakdown of how it works:

Triggering the Pipeline: The pipeline is set to run whenever a push or pull request is made to the main branch, using the on keyword to define these triggers.

Defining Jobs: The configuration includes a series of jobs that execute when the CI pipeline is triggered. These jobs specify an Ubuntu OS build environment, test across different Node.js versions, and contain steps to set up and execute the runtime environment. Finally, the tests are automatically run to validate the code.

My experience

Environment Variable Configuration During my initial pipeline setup, I encountered an error related to the GROQ_API_KEY, which is essential for certain tests and defined in my local .env file. While tests ran smoothly locally, GitHub Actions couldn't access the variable, leading to failed runs.

Solution: Setting Up GitHub Secrets To address this, I configured a secret variable for the API key in my GitHub repository settings. Here’s a quick summary of the fix:

I navigated to the repository’s settings and added GROQ_API_KEY as a secret under Settings > Secrets.
In the .yml file, I added the env keyword to instruct the pipeline to retrieve this key, ensuring the tests could access it without hardcoding sensitive data in the configuration file.

Testing VShell: A starting point into Test-Driven Development

AnhChienVu — Thu, 07 Nov 2024 00:04:29 +0000

Testing Frameworks

For testing this project, I chose the following tools:

Jest:
- Why?: Jest is a widely used testing framework for JavaScript projects, and since my project was written in JavaScript, it was a natural choice. Jest provides a simple API for unit and integration testing, built-in mocking, and snapshot testing. It is ideal for both small and large projects.
- Link: Jest Documentation
Nock:
- Why?: Nock is a powerful library that allows you to mock HTTP requests. It works well for testing scenarios where external API calls (like LLM integrations) are involved. By using Nock, I can simulate LLM responses without actually hitting the live API, which makes the tests faster and more reliable.
- Link: Nock Documentation

Testing Configuration

Installing Dependencies
The first step was to install Jest and Nock:

npm install --save-dev jest nock

Configuring Jest with ESLint
Since Jest uses global variables like describe, test, expect, etc., I had to configure ESLint to avoid warnings related to uninitialized global variables. To do this, I added the following configuration in my eslint.config.mjs file:

import globals from "globals";
import pluginJs from "@eslint/js";
import pluginJest from "eslint-plugin-jest";

export default [
  {
    files: ["**/*.js"],
    languageOptions: { sourceType: "commonjs" },
  },
  {
    ignores: [
      "build/",
      "coverage/",
      "node_modules/",
      ".env",
      "*.config.js",
      "*.config.mjs",
      "examples/",
    ],
  },
  { languageOptions: { globals: { ...globals.browser, ...globals.jest } } },
  pluginJs.configs.recommended,
  {
    plugins: {
      jest: pluginJest,
    },
    rules: {
      ...pluginJest.configs.recommended.rules,
    },
  },
];

This tells ESLint that these global variables are provided by Jest, and it shouldn't flag them as errors.

Setting Up Nock for Mocking HTTP Requests
In the test files, I imported Nock and used it to mock HTTP requests:

const nock = require("nock");

Then, I defined mock HTTP responses for the LLM API like so:

    const mockResponse = {
      id: "chatcmpl-0b910ec8-e9d9-4095-99ed-1311b8efcf39",
      object: "chat.completion",
      created: 1730865897,
      model: "llama3-8b-8192",
      choices: [
        {
          index: 0,
          message: {
            role: "assistant",
            content: "This is a test response from the LLM.",
          },
          logprobs: null,
          finish_reason: "stop",
        },
      ],
      usage: {
        queue_time: 0.003401526000000002,
        prompt_tokens: 300,
        prompt_time: 0.079328471,
        completion_tokens: 500,
        completion_time: 0.215833333,
        total_tokens: 800,
        total_time: 0.295161804,
      },
      system_fingerprint: "fp_a97cfe35ae",
      x_groq: { id: "req_01jbztb85cf4nv71cyjd6pms9w" },
    };

    nock("https://api.groq.com/openai")
      .post("/v1/chat/completions")
      .reply(200, mockResponse);

This way, every time my code makes an HTTP request, Nock intercepts it and returns the mocked response.

Challenges that I faced

One of the major challenges I faced during this process was testing how the LLM handles streaming responses. This type of response is returned differently than a standard JSON object, which made mocking it a bit tricky. Here's what I learned:

Streaming Responses Are Different: The LLM streaming API sends responses in "chunks", which is fundamentally different from regular responses that come in a single payload. This required me to modify my approach to testing, specifically how I simulated the stream-like behavior.
Nock Can't Mock Streams Directly: Initially, I tried using Nock to mock the stream, but I quickly realized that it was designed to mock HTTP responses, not streams. I had to simulate the stream using an array of mocked chunks of data.

test("should return an object with response and tokenInfo properties", async () => {
    // Mock the stream
    const stream = [
      { choices: [{ delta: { content: "Hello" } }] },
      {
        choices: [{ delta: { content: " World" } }],
        x_groq: {
          usage: {
            queue_time: 0.001,
            prompt_tokens: 300,
            prompt_time: 0.046,
            completion_tokens: 500,
            completion_time: 0.203,
            total_tokens: 800,
            total_time: 0.25,
          },
        },
      },
    ];

    // Call the readStream function
    const result = await readStream(stream);

    // Assert the result
    expect(result.response).toBe("Hello World");
    expect(result.tokenInfo).toEqual({
      completionToken: 500,
      promptToken: 300,
      totalToken: 800,
    });
  });

Testing uncover some edge cases

Empty Chunks: One potential edge case I uncovered was how the system should behave when the streaming chunks are empty or incomplete. Handling empty chunks gracefully is crucial, as real-world API responses can sometimes contain empty or unexpected data.
Missing Token Information: I had to ensure that my code correctly handled cases where the token information (i.e., usage data) wasn't present in every chunk. This could happen if the stream is not fully sent or if it's split across multiple chunks.

These edge cases helped refine my implementation and ensure that my code could handle a variety of real-world situations.

What I learnt

This was a highly educational experience. Here's what I took away from it:

Testing is Essential: Although I had written tests before, this project was my first time writing tests for an API integration, particularly for something as complex as a language model stream. I now see just how important it is to test all parts of the system, including edge cases and error handling.
Mocking is Powerful: I learned the importance of mocking external dependencies. Using Nock to mock the HTTP responses saved me from having to rely on a live connection to the LLM, which could have been slow or unreliable. Mocking also allowed me to simulate different responses easily.
Confidence in Code: Writing tests made me feel more confident that my code was functioning as expected. The tests helped me catch potential issues early on, and they provided a safety net for future changes or refactoring.

Beyond Spellcheck: How Static Analysis Tools Enhance Collaboration in Coding

AnhChienVu — Wed, 30 Oct 2024 21:02:36 +0000

This week, I expanded my knowledge on the importance of code formatting in software development. Just as we rely on word processing software with spell check features to identify and correct spelling errors, developers should leverage code editors that offer formatting and linting capabilities to maintain code quality.

Why Use Static Analysis Tools

To enhance the quality of our code and reduce development time, it is essential for programmers to utilize static analysis tools. When collaborating on projects with multiple contributors, adherence to coding standards becomes crucial, as it allows others to read and understand the code more easily. This necessity has led to the emergence of various tools tailored to different programming languages. For my project this week, I chose to implement Prettier for my JavaScript codebase. In addition to formatting tools, a linter is also essential. A linter assists developers in identifying overlooked errors that may not affect the program's execution but can lead to significant issues in the code if left unchecked. For this purpose, I selected ESLint.

Prettier

To use Prettier, I installed it locally in my project with the following command:

npm install --save-dev --save-exact prettier

Next, I created two configuration files: .prettierrc and .prettierignore:

.prettierrc: This configuration file contains the rules for formatting.

I left it as an empty object because I want to use the default Prettier's setup without overriding any rules.

.prettierignore: This file lists the files or directories that Prettier should not format.

I included all the files and folders that I don't want Prettier will approach. Most of them are configuration files and self-generated files.

Notes:

Both files must be placed in the root directory of the project.
After installation, I can test Prettier's functionality by running:

npx prettier . --write

To make it easier to run that command, I made a script that will run in command-line. Inside the package.json file, I added a new script named format.

To use this, you just type this command:

npm run format

In addition to the local setup and command-line usage, Prettier can also be integrated into the code editor (such as VSCode) via an extension. Once installed, it automatically formats code upon saving a file.

Linter

ESLint is a tool designed to identify and report on patterns in ECMAScript/JavaScript code, aiming to enhance code consistency and minimize bugs. You can install and configure ESLint using:

npm init @eslint/config@latest

Upon executing this command, a series of questions will guide you through the setup in the terminal, and a new configuration file named .eslint.config.mjs will be created. Since I am using ESLint version 9.x, all configurations will be specified within this file. I also listed unnecessary files and folders for ESLint to ignore using the ignore property.

To streamline the linting process, I added a script in package.json for easier execution.

To run the script, you just type this command:

npm run lint

Editor Integration

While the aforementioned setup suffices for individual projects, ensuring a uniform development environment for all contributors is vital in collaborative settings. Therefore, I created a .vscode folder in the root directory containing two files:

extensions.json: This file lists the necessary extensions that developers should install when opening the project, providing prompts upon project launch.
settings.json: This configuration ensures that:
- The editor formats code on save using Prettier.
- ESLint automatically fixes linting issues on save.
- ESLint validates JavaScript files.
- Prettier requires a configuration file to format the code.

By establishing the .vscode folder with settings.json and extensions.json, I ensure that all contributors share a consistent development environment, with Prettier and ESLint seamlessly integrated into Visual Studio Code. This setup facilitates automatic code formatting and linting according to the project’s configuration, simplifying the maintenance of code quality and consistency.

Addressing Formatting Issues

After running Prettier, I identified a few files that required manual adjustments, primarily adding commas to the last elements of objects.
Following the ESLint run, I discovered 13 issues, most of which were due to the use of the global object process, which does not require initialization. To resolve this, I added the following comment at the top of the affected files:

/* eslint-disable no-undef */

Additionally, there were some imported values that were not used; for these cases, I simply removed them.

Conclusion

Through my exploration of static analysis tools, I have gained a deeper understanding of their significance, particularly in collaborative projects. The primary goal of these tools is to facilitate teamwork and maintain high code quality, and I now appreciate how to effectively set up a project to integrate these essential tools from the outset.

Open Source, Open Doors: Wrapping Up Hacktoberfest 2024

AnhChienVu — Mon, 28 Oct 2024 19:39:39 +0000

After four consecutive weeks of Hacktoberfest, I’ve finally completed the challenge with four approved PRs. I have to admit, I felt quite nervous at the start of this event, as open-source felt like something outside my comfort zone. However, beginning with smaller issues helped me build confidence, and soon enough, I was motivated to seek out more complex issues to solve. Part of this drive, I think, came from being a student—contributing to a developer community gave me a sense of real-world experience.

If you’d like to read more about my Hacktoberfest journey, feel free to check out my personal page, where I’ve recorded my reflections after each PR. But without further ado, let’s dive into my final week’s PR.

Overview of Mikochi: A Minimalist Remote File Browser

Mikochi is a lightweight, self-hosted remote file browser, ideal for users managing files on private servers or NAS (Network Attached Storage). This tool allows users to easily navigate through remote directories, perform file management tasks like uploading, downloading, renaming, and deleting files, and even stream media files directly to players like VLC or MPV.

Built with a modern web interface powered by JavaScript/Preact and an API backend in Go/Gin, Mikochi provides a seamless and responsive experience for remote file browsing.

What I worked on

In this project, I tackled an issue related to enhance user control and security in Mikochi, I implemented a log-out feature accessible via a "Log Out" button in the application’s navbar. This feature was designed to securely log users out by clearing authentication tokens and redirecting them to the login page. On the frontend, the log-out button triggers an API call to a new /logout endpoint, clears the JWT from local storage, and refreshes or redirects the page to ensure users are fully logged out. On the backend, I built logic to handle the /logout endpoint by adding the token ID to a list of invalidated tokens. This list is checked in the JWT authentication middleware, ensuring that any request with an invalidated token is rejected with a 403 response. This addition improved Mikochi's security, helping users control active sessions and protecting their accounts on shared or public devices.

Solution

In this PR, I implemented a secure log-out functionality for Mikochi, addressing both frontend and backend requirements to enhance user session control. On the frontend, I created a Logout component to handle the API call to /api/logout and clear the JWT from local storage. When the user clicks "Log Out," the JWT is removed, a POST request is sent to the backend to validate the log-out, and the page redirects the user to the main login screen using window.location.href. On the backend, I modified the JWT generation in generateAuthToken() to include an ID property, allowing tokens to be invalidated effectively. I then added a handler in backend/auth/handlers.go to manage logout requests by appending the JWT ID to an invalidated token list. The JWT middleware checks each request, denying access if the token has been invalidated and returning a 403 response. To verify the functionality, I conducted manual testing by re-inserting a previously invalidated token into local storage after logout, ensuring that any attempt to reuse it failed, effectively securing the logout process.

My Thoughts

For me, this was a fascinating project, blending backend and frontend development into a single project. The issue I addressed on the frontend was relatively straightforward—creating a logout button, with a bit of CSS to improve its appearance. I’ve been learning React for a while, so while I needed a brief refresher, it helped me understand the code and components already in the source.

On the backend, the project owner had containerized the project using Docker, which was familiar ground for me. The most time-consuming part, however, was working with Go, the backend language for this project. I had no prior experience with Go, but tackling this issue gave me the opportunity to learn it to a functional level, which I found quite rewarding.

Open Source Achievement: Completing My Third PR in Hacktoberfest

AnhChienVu — Fri, 18 Oct 2024 01:19:28 +0000

Participating in Hacktoberfest has been exciting and rewarding journey for me, as I've had the opportunity to contribute to meaningful open-source projects while honing my skills. This year, for my third Pull Request, I chose to contribute to a project that's more complex than my first 2 PRs, it is the ZTM-Quest repository.

ZTM-Quest Overview

ZTM-Quest is a project that is part of the Zero to Mastery Academy, a platform that helps developers improve their skills and build real-world projects. The project itself is an engaging interactive web app that allows users to complete quests, level up their coding abilities. In this blog, I'll walk you through my experience working on the ZTM-Quest repo, the challenges I faced, what I learned, and how I managed to complete my third PR for Hacktoberfest

My Pull Request

This week, I tackled an issue focused on enhancing the ZTM-Quest project by adding additional NPCs (Non-Playable Characters) to map_start. Currently, the project has only a limited number of NPCs per map, and the maintainers wanted to populate the map_start area further. Fortunately, the project already included some code for generating NPCs randomly, which provided me with a solid starting point. Additionally, the maintainer suggested that I could create custom NPCs using my own spritesheets, but given the complexity and size of the codebase, I decided to proceed with the existing assets to meet the project requirements more efficiently.

The ZTM-Quest project consists of three maps: map_arcade, map_city, and map_start. For this issue, I focused solely on map_start to align with the maintainer’s request. As someone who has never worked with a 2D game development library before, I initially found the task daunting. However, thanks to the maintainer’s guidance and detailed instructions, I was able to navigate through the codebase and identify the key files and structures related to the task.

I started by exploring the src/factories/npc.factory.js file, where the NPC creation logic is defined. From there, I began adding new NPCs by creating a file named randNpcsOnRestroomSinkCouch.gameObject.js in the src/gameObjects/map_start directory. My initial implementation placed NPCs in only one location (chairs), but upon further review, I realized that the maintainer intended for them to be distributed more dynamically across the map. To address this, I utilized the search functionality in my code editor to identify other relevant locations, such as sinks, couches, and washrooms.

Based on the positions of these identified objects on the map, I added two NPCs standing near the sink, two sitting on the couch, and three positioned in the washroom area, thus creating a livelier and more interactive environment in map_start.
My PR

Conclusion

Working on this issue gave me invaluable insight into the open-source community and game development. The ZTM-Quest maintainers have been incredibly supportive and professional, providing timely feedback and resources to help me succeed. When I first joined the project, I was invited to their Discord group, where I could reach out whenever I had questions. This made the experience even more enjoyable and collaborative.

Overall, this week pushed me out of my comfort zone as I took on a challenge in an area I had no prior experience in—2D game development. Despite the initial learning curve, I gained confidence in navigating unfamiliar codebases and problem-solving within a complex project. As I look forward to completing my final PR for Hacktoberfest, I aim to continue exploring new areas of development to broaden my skill set.

Hacktoberfest Week 2: Diving Deeper into Code Contributions

AnhChienVu — Fri, 11 Oct 2024 23:38:17 +0000

Greetings, everyone! How’s Hacktoberfest going for you this year? Personally, I’m really enjoying it so far. We’ve now entered the second week of October, which means it’s time for my second pull request (PR) out of the four needed to complete the challenge. This week, I decided to push myself a bit further by contributing to a project’s codebase rather than focusing solely on documentation, as I did in Week 1.

Recap of Week 1

In my first PR of Hacktoberfest, I worked on improving project documentation. As a beginner, I wanted to ease into the process with smaller, manageable tasks. However, for this second week, I decided to take on something more technical: contributing to the GitExplorer project.

Project Overview: GitExplorer

GitExplorer is a web application that simplifies the discovery and exploration of top GitHub repositories. It allows users to filter repositories based on programming languages, topics, and other sorting criteria. While the UI is still under development, the project offers a valuable learning opportunity for contributors, especially beginners. Many of the issues in the repository are tagged as "good first issue," making it a great place to start.

For my contribution, I chose to implement a navigation feature that enhances user experience when browsing repositories.

Identifying the Problem

Issue
The project initially had a button for navigating to the next page of repositories, but it lacked a full pagination system. Users couldn't easily navigate back and forth between pages or jump to a specific page, which posed usability issues. I noticed this limitation and requested the project maintainer to assign the issue to me.

During my time working on the project, one aspect that stood out (and not in a good way) was the way the codebase was structured. The project had all the logic written into a single script.js file, which could become difficult to maintain as the project grows. While I didn't want to make major changes in this PR—since it focused only on the pagination buttons—I plan to suggest refactoring the code structure in a future issue.

Actually, before that there is another developer who created a button that navigate to the next page, but it's not good for User experience when they want to navigate back and forth, as well as specific page. Due to this reason, I commented to ask maintainer assign this issue for me.
As the time when I was working on this project, there is one thing that I didn't like about it. It is the way the maintainer structure his code base as he was writing every logic into only 1 script.js file. However, I don't want to have a lot of fix in this issue because it only ask for pagination buttons. I will create a new issue requesting to re-structure the code base later.

New Feature: Enhanced Pagination

My PR
The existing functionality had only one button to navigate between pages, with 10 repositories displayed per page. My goal was to implement a more user-friendly pagination system with "Previous," "Next," and numbered page buttons. This would allow users to jump directly to the page they're interested in, making the navigation experience smoother.

Implementation

GitHub API Constraints:

While implementing the pagination, I encountered a limitation with GitHub's API, which restricts results to 1,000 items. If a search yields more than 1,000 repositories, attempting to navigate beyond this limit results in an error, returning undefined data. Given the design displays 10 repositories per page, I capped the number of pages at 100 to avoid hitting this issue.

Code Changes:

I introduced a new <div> section in script.js for pagination. This allowed me to add some CSS styles to improve the button aesthetics and user experience.
The core logic for pagination was encapsulated in two new functions:
- createButton()
- renderPagination() These functions dynamically generated the pagination buttons based on the available pages and applied styles to disable the current page button, preventing users from accidentally re-clicking it. I also added hover effects to the buttons for a more polished look.

CSS Improvements:

For the pagination design, I made sure that the current page button is disabled and styled differently to indicate its state. Other page buttons received hover effects to enhance interactivity and improve user experience.

Conclusion

That wraps up my contribution for Week 2 of Hacktoberfest. I’m now on the lookout for another repository to contribute to next week. Ideally, I’d like to find a project that’s a bit more challenging, so I can continue to push myself and improve my skills progressively.

Thanks for reading, and I look forward to sharing more about my Hacktoberfest journey!

DEV Community: AnhChienVu

Create a Pull Request for a new Feature of ImprovedTub

Implementing the Details Switch

Coding content.js file

Exploring backend.js file

Finally

Continuous Progress in Adding new Feature for ImprovedTub

Exploring the manifest.json file

Adding Switch buton

Adding content.js file

Adding event listener in background.js file

Conclusion

Exploring ImprovedTube: A Beginner's Journey into Open Source Chrome Extensions

Why I chose ImprovedTube

Overcoming the Learning Curve

My contribution

Goals and Reflections

VShell: Production Release Workflow

Automating the Build Process

Implementing Semantic Versioning

Tagging the Release in Git

Declaring Package Files

Publishing to npm

Out of scope updates

Automating Releases with GitHub Actions

Conclusion

Working with GitHub OAuth Authentication

Overview of GitExplorer

Challenges: Working Without a UI Framework

Migrating the Project and Setting Up the Backend

GitHub API Integration

Writing Modular, DRY Code

Lessons Learned and Looking Ahead

Keep continuing with Open Source Development

Project Overview

Work Details

Implementation Steps for Each HTML File:

Conclusion:

Implementing a CI Pipeline for VShell with GitHub Actions

Introduction

What is Continuous Integration?

Setting Up the CI Pipeline with GitHub Actions

My experience

Testing VShell: A starting point into Test-Driven Development

Testing Frameworks

Testing Configuration

Challenges that I faced

Testing uncover some edge cases

What I learnt

Beyond Spellcheck: How Static Analysis Tools Enhance Collaboration in Coding

Why Use Static Analysis Tools

Prettier

Linter

Editor Integration

Addressing Formatting Issues

Conclusion

Open Source, Open Doors: Wrapping Up Hacktoberfest 2024

Overview of Mikochi: A Minimalist Remote File Browser

What I worked on

Solution

My Thoughts

Open Source Achievement: Completing My Third PR in Hacktoberfest

ZTM-Quest Overview

My Pull Request

Conclusion

Hacktoberfest Week 2: Diving Deeper into Code Contributions

Recap of Week 1

Project Overview: GitExplorer

Identifying the Problem

New Feature: Enhanced Pagination

Implementation

Conclusion

Coding `content.js` file

Exploring `backend.js` file

Exploring the `manifest.json` file

Adding `content.js` file

Adding event listener in `background.js` file