DEV Community: Harshil Patel

Kubernetes on Windows: A Guide to Running Kubernetes Using Minikube and kubectl

Harshil Patel — Fri, 20 Dec 2024 23:04:10 +0000

There is a GitHub repository where I have added detailed notes on what Kubernetes is, along with notes on its components and architecture. You can check it out here:

hpatel292-seneca / Learning-Kubernetes

This repo contains basic notes about kubernetes like its Architecture, components and how to use kubernetes using kubectl

Learning-Kubernetes

What is Kubernetes?

Kubernetes is an open source Container Orchestration tool.

What is Container Orchestration??

Container Orchestration is a process of automatically managing and coordinating a large number containers. It manage task like

Starting and Stopping containers
Placing containers on right machine
Scaling containers up and down based on usage
Restart containers on failures

Kubernetes helps you manage containerized application in different environment like on-permise, Cloud, Hybrid setup. It ensures you application runs effectively, remain scalable, and are resilient to failures, without you having to manage containers manually.

Why Kubernetes was developed??

Kubernetes was developed by Google and later open-sourced to help manage the complex challenges of deploying and running large-scale containerized applications. Before Kubernetes, Google used its internal system called Borg, which inspired Kubernetes.

Need for Container Orchestration tool:

As Container adoption grew, so did the complexity for managing those containers. Here are few reasons why Kubernetes became…

View on GitHub

Installing Minikube

To get started, you first need to install Minikube. Visit the official Minikube site: Minikube Start Documentation. Choose your operating system and follow the provided steps to install Minikube.

For Windows users, you can use PowerShell to install Minikube by running the following commands:

New-Item -Path 'c:\' -Name 'minikube' -ItemType Directory -Force
Invoke-WebRequest -OutFile 'c:\minikube\minikube.exe' -Uri 'https://github.com/kubernetes/minikube/releases/latest/download/minikube-windows-amd64.exe' -UseBasicParsing

This will download and install Minikube to your system. Next, add Minikube to your system’s PATH environment variable by running the following command:

$oldPath = [Environment]::GetEnvironmentVariable('Path', [EnvironmentVariableTarget]::Machine)
if ($oldPath.Split(';') -notcontains 'C:\minikube') {
  [Environment]::SetEnvironmentVariable('Path', $('{0};C:\minikube' -f $oldPath), [EnvironmentVariableTarget]::Machine)
}

This ensures that you can run Minikube commands from any terminal session.

Setting Up a Hypervisor

Minikube requires a hypervisor to run. Depending on your operating system, you can choose from several options. For a detailed list of supported drivers, refer to the Minikube Drivers Documentation.

If you already have Docker Desktop installed on your Windows system, you can use Docker as the Minikube driver. To start a Kubernetes cluster using the Docker driver, run the following command:

minikube start --driver=docker

This command will also install kubectl as a dependency. You can now use kubectl to interact with your Kubernetes cluster, specifically the API server.

Now as minikube is running let's check if it's actually running or not. To get all nodes in the cluster you can cun |

kubectl get nodes

Basic Operations with kubectl

Now, as kubectl is installed and configured, now we can use it to interact with Kubernetes cluster.

1. Check the Status of Nodes

Command: kubectl get nodes
What It Does: Lists all nodes in the cluster with their status (e.g., Ready, NotReady).
Example Output:

  NAME       STATUS   ROLES    AGE   VERSION
  minikube   Ready    master   5m    v1.23.0

Details: Shows information like node name, roles, and Kubernetes version. For Minikube, there is typically one master node.

2. List Pods

Command: kubectl get pods
What It Does: Displays all running pods in the default namespace.

3. List Services

Command: kubectl get services
What It Does: Lists all Kubernetes services in the default namespace.
Example Output:

  NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
  kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   5m

Details: Services provide networking between pods. The default service is Kubernetes' internal DNS service.

4. Create a Deployment

Command: kubectl create deployment <name> --image=<image-name>
What It Does: Creates a deployment, which manages the pods and ReplicaSets. In Kubernetes we cannot interact with pods directly, instead we can use deployment and deployment act as abstraction layer on pods.
Example:

  kubectl create deployment nginx-deployment --image=nginx

Details:
- Creates a deployment named nginx-deployment.
- Downloads the nginx image from Docker Hub and creates a pod using it.
- Verification: Run kubectl get deployments to confirm the deployment.

5. View Deployment

Command: kubectl get deployments
What It Does: Lists all deployments in the current namespace.
Example Output:

  NAME               READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   1/1     1            1           5m

Details: Displays the deployment's readiness and availability status.

6. View ReplicaSets

Command: kubectl get replicasets
What It Does: Lists all ReplicaSets associated with the deployments.
Example Output:

  NAME                      DESIRED   CURRENT   READY   AGE
  nginx-deployment-6fd8c8   1         1         1       5m

Details: Shows the desired and actual number of pods for each ReplicaSet.

7. Edit a Deployment

Command: kubectl edit deployment <name>
What It Does: Opens the deployment's configuration file in your default text editor.
Example:

  kubectl edit deployment nginx-deployment

Details:
1. Opens the configuration file for the deployment.
2. Edit fields like the container image. Example:
```
 spec:
   containers:
   - name: nginx
     image: nginx:1.16
```

Save and close the editor.
Kubernetes automatically terminates old pods and creates new ones with the updated configuration.
Verification: Run kubectl get pods to see old pods terminating and new ones starting.

8. Check Logs

Command: kubectl logs <pod-name>
What It Does: Fetches logs from a specific pod.
Example:

  kubectl logs nginx-deployment-6fd8c8

Details:
- Logs provide output generated by the container application inside the pod.
- If no logs are available, it means the application hasn't logged anything yet.

9. Describe a Pod

Command: kubectl describe pod <pod-name>
What It Does: Provides detailed information about a pod.
Example:

  kubectl describe pod nginx-deployment-6fd8c8

Details:
- Shows detailed events like image pulling, container creation, and issues (if any).
- Useful for debugging pod startup problems.

10. Access Pod Shell

Command: kubectl exec -it <pod-name> -- <command>
What It Does: Opens an interactive terminal session in a container inside the pod.
Example:

  kubectl exec -it nginx-deployment-6fd8c8 -- /bin/bash

Details:
- You are now inside the container of the pod.
- Use this to debug or test the container environment.
- Exit the session by typing exit.

11. Delete a Deployment

Command: kubectl delete deployment <name>
What It Does: Deletes the deployment along with its associated pods and ReplicaSets.
Example:

  kubectl delete deployment nginx-deployment

Details:
- Automatically removes all pods and ReplicaSets under the deployment.
- Verification: Run kubectl get pods and kubectl get replicasets to confirm deletion.

12. Apply Configuration File

Command: kubectl apply -f <file.yaml>
What It Does: Creates or updates resources defined in a configuration file.
Example:

  kubectl apply -f nginx-deployment.yaml

Details:

The file can define multiple resources, like deployments, services, etc.
Example Configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

To update the deployment, modify the file (e.g., change replicas to 3) and reapply it:

kubectl apply -f nginx-deployment.yaml

Setting Up a CI/CD Pipeline with Azure and Playwright for StyleMate

Harshil Patel — Fri, 13 Dec 2024 01:00:51 +0000

I have been working on a web app called StyleMate. Initially, I started this project to practice my C# and .NET skills. Over time, I added more pages and features and began exploring advanced functionalities. Recently, I integrated GROQ LLM to generate intelligent clothing suggestions and a weather API to enhance recommendations based on current weather conditions.

After incorporating these features, I decided to add a CI/CD pipeline for automated deployments and integrate testing into my project. Here’s how I set up the pipeline, handled challenges, and implemented a staging environment for robust testing.

Adding a Deployment Pipeline

To deploy StyleMate, I created an Azure Web App with a free App Service plan and a SQL database. The database costs around $5 per month using Azure credits. To streamline deployments, I configured the deployment center in the Azure Web App.

Challenges with Default Pipeline

Initially, the default pipeline created by the deployment center used subscription ID, tenant ID, and resource ID for deployment. However, I wanted to deploy using the Publish Profile method, which is simpler and works well for smaller projects.

After some research, I found that I needed to enable SCM Basic Auth Publishing under the Web App configuration settings. This configuration allows the pipeline to use the Publish Profile for deployments.

Pipeline Code

Here’s the pipeline I configured for building and deploying StyleMate:

name: Build and deploy .NET Core application to Web App StyleMate
on:
  workflow_run:
    workflows:
      - Build and deploy ASP.Net Core app to Azure Web App - StyleMate-Staging
    types:
      - completed
env:
  AZURE_WEBAPP_NAME: StyleMate
  AZURE_WEBAPP_PACKAGE_PATH: .\published
  CONFIGURATION: Release
  DOTNET_CORE_VERSION: 8.0.x
  WORKING_DIRECTORY: .
jobs:
  build:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: windows-latest
    steps:
    - uses: actions/checkout@v4
    - name: Setup .NET SDK
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ env.DOTNET_CORE_VERSION }}
    - name: Restore
      run: dotnet restore "${{ env.WORKING_DIRECTORY }}"
    - name: Build
      run: dotnet build "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --no-restore
    - name: Install Playwright Browsers
      run: npx playwright install
    - name: Test
      run: dotnet test "${{ env.WORKING_DIRECTORY }}" --no-build
    - name: Publish
      run: dotnet publish "${{ env.WORKING_DIRECTORY }}" --configuration ${{ env.CONFIGURATION }} --no-build --output "${{ env.AZURE_WEBAPP_PACKAGE_PATH }}"
    - name: Publish Artifacts
      uses: actions/upload-artifact@v3
      with:
        name: webapp
        path: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
  deploy:
    runs-on: windows-latest
    needs: build
    steps:
    - name: Download artifact from build job
      uses: actions/download-artifact@v3
      with:
        name: webapp
        path: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
    - name: Deploy to Azure WebApp
      uses: azure/webapps-deploy@v2
      with:
        app-name: ${{ env.AZURE_WEBAPP_NAME }}
        publish-profile: ${{ secrets.StyleMate_84FD }}
        package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

Integrating Testing

I added testing to the pipeline to ensure the application works correctly before deploying to production. The pipeline includes:

Unit Tests using xUnit to validate core logic.
End-to-End (E2E) Tests using Playwright to simulate real user interactions.

Challenge with E2E Testing

Playwright tests run on an actual website. If a code change breaks functionality, deploying it directly to production can cause issues. Ideally, tests should run on a staging environment to prevent this.

Initial Attempt: Deployment Slots

Azure App Service deployment slots would have been perfect for staging. However, the free App Service plan does not support deployment slots.

Staging Environment Solution

As a workaround, I created another Azure Web App called StyleMate-Staging. I then updated the pipeline to:

Deploy the application to the staging web app (StyleMate-Staging).
Run Playwright tests on the staging environment.
Deploy the application to the production web app (StyleMate) only if all tests pass.

Final Workflow

Here’s how the pipeline works:

Build and Test:
- The application is built and unit tests are executed.
- Artifacts are created and uploaded for deployment.
Staging Deployment:
- The application is deployed to StyleMate-Staging.
- Playwright tests run on the staging site.
Production Deployment:
- If all tests pass, the application is deployed to the production web app, StyleMate.

Conclusion

By integrating a CI/CD pipeline and testing workflow, I ensured the reliability and quality of StyleMate. The staging environment allowed me to run Playwright E2E tests safely without impacting production users. While Azure's free App Service plan has limitations (e.g., no deployment slots), the workaround with a separate staging app worked seamlessly.

This setup provides a robust foundation for deploying high-quality code and further enhancing StyleMate.

If you’d like to check out the project, here’s the GitHub repository.

My Journey Contributing to Node.js Core: The Final Chapter (3/3)

Harshil Patel — Fri, 29 Nov 2024 04:06:49 +0000

This is the final blog in my three-part series where I share my experience contributing to the Node.js core repository. In my previous blogs, I detailed how I identified an issue, tested it locally to confirm its existence, and opened a pull request (PR) with the necessary changes. You can read the first two blogs here:

test_runner: add level-based diagnostic handling for reporter #55964

hpatel292-seneca posted on Nov 23, 2024

This fixes #55922

Change summary

Updated the reporter.diagnostic to accept level parameter like this

  diagnostic(nesting, loc, message, level = 'info') {
    this[kEmitMessage]('test:diagnostic', {
      __proto__: null,
      nesting,
      message,
      level,
      ...loc,
    });
  }

Then I updated #handleEvent like this

 #handleEvent({ type, data }) {
    switch (type) {
      case 'test:fail':
        if (data.details?.error?.failureType !== kSubtestsFailed) {
          ArrayPrototypePush(this.#failedTests, data);
        }
        return this.#handleTestReportEvent(type, data);
      case 'test:pass':
        return this.#handleTestReportEvent(type, data);
      case 'test:start':
        ArrayPrototypeUnshift(this.#stack, { __proto__: null, data, type });
        break;
      case 'test:stderr':
      case 'test:stdout':
        return data.message;
      case 'test:diagnostic':  // Here I added logic
        const diagnosticColor =
          reporterColorMap[data.level] || reporterColorMap['test:diagnostic'];
        return `${diagnosticColor}${indent(data.nesting)}${
          reporterUnicodeSymbolMap[type]
        }${data.message}${colors.white}\n`;
      case 'test:coverage':
        return getCoverageReport(
          indent(data.nesting),
          data.summary,
          reporterUnicodeSymbolMap['test:coverage'],
          colors.blue,
          true
        );
    }
  }

And I am Updated reporterColorMap like this

const reporterColorMap = {
  __proto__: null,
  get 'test:fail'() {
    return colors.red;
  },
  get 'test:pass'() {
    return colors.green;
  },
  get 'test:diagnostic'() {
    return colors.blue;
  },
  get info() { // Here I added logic
    return colors.blue;
  },
  get debug() { 
    return colors.gray;
  },
  get warn() { 
    return colors.yellow;
  },
  get error() { 
    return colors.red;
  },
};

and color already contain logic for this colors

I also set the reporter.diagnostic call from test.js like this (level="Error")

if (actual < threshold) {
            harness.success = false;
            process.exitCode = kGenericUserError;
            reporter.diagnostic(
              nesting,
              loc,
              `Error: ${NumberPrototypeToFixed(
                actual,
                2
              )}% ${name} coverage does not meet threshold of ${threshold}%.`,
              'error'  // Level is set to error for red color
            );
          }

Here is Demo output:

View on GitHub

After submitting the PR, I was excited to see it get approved almost immediately. However, it hasn't been merged yet, as Node.js requires two approvals for a PR to land.

One interesting aspect of contributing to Node.js is the continuous integration (CI) process. The CI for Node.js takes around four hours to complete its run. Unfortunately, one of the CI checks for my PR failed. The failing check was First commit message adheres to guidelines / lint-commit-message (pull_request). As the name suggests, this check validates whether the commit message adheres to Node.js's specific guidelines.

Upon reviewing the CI output, I discovered that Node.js requires commit messages to follow a specific format outlined in the Contributing.md document. Here’s a snippet of the commit message requirements:

Although I had seen this requirement earlier and formatted my commit message accordingly, I made a small mistake—I forgot to include a blank line after the first line. I reached out to a maintainer to ask if I could rewrite the commit message and force push the change. After receiving approval, I pushed the corrected commit message.

However, after the new commit, the CI ran again, and this time, the Lint CI failed. To debug further, I decided to run the linting process locally, where I encountered the following errors:

The lint errors I encountered were minor, and I was able to fix them quickly. After addressing these issues, I pushed the changes again, and this time all CI checks passed successfully for my PR.

Subsequently, a maintainer requested a change to remove the debug() from the log level. They mentioned that there are alternative ways to include debug output and provided guidance on how to proceed:

I made the requested changes and pushed the updated code.

Later, I received another request from the maintainer to update the documentation and write a test case for the changes to ensure the PR could land. Fortunately, they provided clear directions on where to add the documentation and tests:

Updating the Documentation

I started with the documentation updates and navigated to doc/api/test.md, as suggested by the maintainer. The document was extensive, so I searched for keywords like "diagnostic" and found the relevant section for Event: test:diagnostic:

I wasn't sure if this was the correct place to update the documentation, so I messaged the maintainer in the PR thread to confirm my proposed changes. Here’s the exact message I sent:

The maintainer responded, confirming that this was the right place for the updates but requested that I remove mentions of color and the default values. After updating the documentation accordingly and getting approval, I pushed the changes.

Adding Test Cases

Next, I moved on to adding test cases, which turned out to be the most challenging part of this PR. The maintainer directed me to the /test/parallel directory to locate the appropriate file for adding tests. However, I was surprised to find 3567 test files in this directory:

The contributing guide mentioned that if you're unsure where to add a test, it can temporarily go in /test/parallel. However, I noticed that many tests had not been moved from this directory, making it difficult to determine their purpose or scope:

I spent considerable time exploring various files and eventually found two tests related to the error threshold. While these tests verified that output was being printed to the stream, they did not cover colored output. I messaged the maintainer to ask for guidance on where to add tests for colored output and referenced these files:

The maintainer suggested adding the test in test-runner-output.mjs, noting that it contained snapshot tests, some of which tested colored output:

I reviewed the test-runner-output.mjs file but struggled to understand it. To clarify, I researched snapshot testing and found this explanation:

Snapshot tests capture the rendered output of a component, function, or application at a specific point in time and store it in a "snapshot" file. Future test runs compare the output against the saved snapshot to ensure that it has not unexpectedly changed.

Using this understanding, I identified a test checking colors in the snapshot. After analyzing the snapshot file, I confirmed it included color information. I wrote a new test to verify that the ANSI escape sequence for red (\u001b[31m) was present in the snapshot. While the test passed locally, it did not create a snapshot.

I suspected I needed to pass a flag to enable snapshot creation. Using tools/test.py --help, I discovered the --snapshot flag and ran the test again. Despite the flag, no snapshot was created, nor did I receive any errors. Further investigation revealed that I could use a locally built Node.js binary to run the tests:

Using the locally built Node.js binary, I discovered the test was being skipped because Windows lacks pseudo-terminal support:

I messaged the maintainer, explaining my test implementation, references, and the issue I encountered:

The maintainer advised modifying the test to explicitly require pseudo-terminals, ensuring it wouldn't run on unsupported systems:

I implemented the test accordingly. Initially, I printed the output for debugging purposes, verifying that the error message appeared in red:

Afterward, I committed the final test and pushed the changes. The CI ran again, and all checks passed successfully. However, the maintainer requested another update to the documentation, asking me to remove a few additional details. I followed their instructions, made the changes, and committed them.

Final Thoughts

Contributing to Node.js has been a transformative experience. From navigating CI workflows to writing snapshot tests, every challenge taught me something new. The opportunity to collaborate with experienced developers and interact with maintainers was invaluable. This journey reinforced my willingness to learn and adapt, and I look forward to contributing more to open-source projects in the future.

Contributing to Node.js: Implementing Dynamic Colors for Test Runner Diagnostics (2/3)

Harshil Patel — Wed, 27 Nov 2024 21:39:01 +0000

Introduction

This is the second blog in a series of three, where I am sharing my experience contributing to the Node.js core repository. You can read the previous blog here: Contributing to Node.js: Improving Test Runner Coverage Reporting. In the previous blog, I discussed how I discovered the issue and confirmed that it exists in Node.js.

After that, I forked and cloned the Node.js repository and opened it in VS Code. One thing I’ve learned from working on many open-source repositories is that finding where to add or modify code is just as important as knowing what code to add. Fortunately, there was another pull request linked to the issue I was working on, which gave me some useful context.

That pull request also addressed the issue I was working on, but it hardcoded the value for the color. My task, on the other hand, was to implement a level parameter and update the event reader to handle the logic for adding colors dynamically. For example, my issue was to ensure that error messages for coverage would appear in red, but instead of hardcoding the color, the level parameter would allow developers to set it appropriately based on the severity.

Tracing the Code

From the linked pull request, I knew where I could start. The first file to investigate was test.js, which prints the error message when the test coverage threshold isn't met.

Here, I noticed a call to reporter.diagnostic(). To better understand what was happening, I backtracked to locate the definition of this function. After spending a good amount of time, I found the definition of diagnostic() in tests_stream.js.

diagnostic(nesting, loc, message, level = 'info') {
  this[kEmitMessage]('test:diagnostic', {
    __proto__: null,
    nesting,
    message,
    level,
    ...loc,
  });
}

I added a level parameter here, defaulting it to 'info'. This was the first step to make the error color configurable.

Adding Logic for Severity-Based Colors

Next, I located the handler for test:diagnostic in spec.js. Here, I added logic to dynamically retrieve the color using reporterColorMap, which maps severity levels (e.g., info, warn, error) to specific colors.

#handleEvent({ type, data }) {
  switch (type) {
    // ...
    case 'test:diagnostic': {
      const diagnosticColor = reporterColorMap[data.level] || reporterColorMap['test:diagnostic'];
      return `${diagnosticColor}${indent(data.nesting)}${reporterUnicodeSymbolMap[type]}${data.message}${colors.white}\n`;
    }
    // ...
  }
}

I then traced the reporterColorMap definition in utils.js and updated it to map severity levels to appropriate colors. Here’s the updated code:

const reporterColorMap = {
  '__proto__': null,
  get 'test:fail'() {
    return colors.red;
  },
  get 'test:pass'() {
    return colors.green;
  },
  get 'test:diagnostic'() {
    return colors.blue;
  },
  get 'info'() {
    return colors.blue;
  },
  get 'warn'() {
    return colors.yellow;
  },
  get 'error'() {
    return colors.red;
  },
};

With these changes, the level parameter now dynamically controls the color of the diagnostic message, making it easier for developers to identify severity levels at a glance.

Building Node.js Locally

Now that the changes were made, it was time to test my work. To do this, I needed to build Node.js locally. I referred to the Building.md file for instructions. Before building, I had to install the prerequisites for my environment. The document mentioned three options for installing these prerequisites.

Initially, I tried the second option, which involved using WinGet. However, during installation, it prompted me to grant several permissions, one of which required uninstalling Visual Studio Code. Since I didn’t want to reinstall Visual Studio Code, I canceled the installation. I then reached out to the maintainer for advice, and they recommended the third option: building with Boxstarter.

Testing the Build

After preparing the prerequisites using Boxstarter, I started building Node.js locally. However, the build process ran for over 1 hour and 30 minutes without completing. This seemed unusual, so I asked the maintainer about it in the issue thread. They mentioned that the build process typically takes about 25 minutes.

After reading that, I canceled the build and decided to try again the next day. On the next attempt, the build completed in just 10 minutes. With the locally built version of Node.js ready, I went back to the sample repository I had created earlier to test the issue of error printing in blue (as described in my first blog). This time, I ran the same test cases but used the locally built Node.js. And guess what? It worked! The error was successfully printed in red.

Opening a Pull Request

After confirming that my changes worked, I committed them and opened a pull request. In the pull request, I described the changes I made and asked the maintainer for a review. Shortly after, I received a response from the maintainer, who mentioned that I needed to update the documentation and write test cases for the changes I had made.

Conclusion

That’s it for this blog. In the next blog, I will share how I updated the documentation and added test cases to complete the pull request.
Next Blog: My Journey Contributing to Node.js Core: The Final Chapter (3/3)

Contributing to Node.js: Improving Test Runner Coverage Reporting (1/3)

Harshil Patel — Sun, 24 Nov 2024 05:03:26 +0000

Introduction

Hi! My name is Harshil. I am currently enrolled in the Open Source Development course at Seneca College. In this course, we are required to contribute to different open-source repositories every week. So far, I have contributed to more than 10 issues across 6+ open-source repositories. You can find the full list of my contributions here: List.

During my most recent contribution to Chatcraft, I realized that contributing to significant issues can be challenging, but true learning happens when you push yourself outside your comfort zone. For that pull request, I spent over 35 hours working on it, as I received numerous change requests from the maintainer. The most important lesson I learned is that big things take time and persistence.

With this insight and my growing experience in open-source contributions, I started searching for a big issue to tackle next. My goal is to contribute to something that I will genuinely be proud of.

Finding the Right Issue

I started exploring different repositories and their issues. Initially, I looked for issues in the repositories I had already contributed to, but I couldn’t find any suitable ones. Trust me, finding a good issue to work on is a challenging task. I also tried checking out various large repositories, such as React, VS Code, and .NET, but I still couldn’t find anything that matched my skills and interests.

Finally, I discovered a good issue in the Node.js repository. Node.js is a cross-platform JavaScript runtime environment that executes code outside of a browser, built on Chrome's V8 engine. I have worked extensively with Node.js, having built many projects using it, but I never imagined that one day I would get the opportunity to contribute to its core development. I reached out to the maintainer to ask if I could work on the issue.

Understanding the Issue

After receiving the maintainer's response, I started looking into the issue. The title of the issue is "Add a level parameter to test runner diagnostics." Initially, it was difficult to understand the issue based on the title and description, but there was a reference to a related pull request that provided more context. Upon reviewing the pull request, I discovered that the issue was related to the test_runner module in Node.js.

The Node.js test_runner is a built-in module that enables developers to create, manage, and execute JavaScript tests. It supports various testing workflows with features like TAP output and subtests. You can learn more about the test_runner here.

The issue suggests adding a level parameter (e.g., debug, info, warn, error) to the diagnostics functionality of the test_runner. This enhancement would allow developers to apply color coding to the output based on the severity of messages, making it easier to differentiate between message types. The idea originates from a related issue where errors in test coverage thresholds were displayed in blue instead of red, leading to confusion during code reviews and debugging in CI pipelines. Here is the original issue.

For example, if I am developing a project and using Node.js for testing, I might write some test cases and require all my files to have 100% test coverage. Using the test_runner, I could pass the flag --test-coverage-lines=100, which compares the actual coverage to the expected value. If the actual coverage is less than expected, the test coverage report currently prints an error message in blue. This color is not noticeable, causing developers to mistakenly believe their code meets the coverage requirement. Moreover, if this flag is used in a CI pipeline, the pipeline could fail unexpectedly, creating further confusion.

Planning the Fix

After that, I reviewed the files involved in this issue and posted a message in the issue thread outlining the changes I was planning to make.

The maintainer responded promptly, suggesting some modifications and encouraging me to start working on the issue and submit a pull request.

First, I wanted to try the --test-coverage-lines=100 flag locally. To do this, I created a sample JavaScript repository, added a sample file, and wrote a test case file to test that code. However, when I tried using the flag, I encountered an error.

After reviewing the original issue, I noticed that they were using Node.js version 22.. To match their setup, I installed Node.js v22. using Node Version Manager (NVM) and switched to that version.

Despite this, the flag still didn’t work. I tried various troubleshooting steps, but none of them resolved the issue. Eventually, I found a blog that explained how to set up and run the Node.js test runner properly. By following the steps outlined in the blog, I successfully set up the test runner.

Here is the result:

The error message was printed, but it appeared in blue, which confirmed the issue I needed to address: changing the color of the error message to red by adding level in diagnostics.

Conclusion

This contribution was a perfect example of how open-source development combines problem-solving, collaboration, and persistence. While I faced challenges setting up the environment and understanding the issue, the process deepened my understanding of Node.js internals and taught me how to navigate complex problems effectively.

In my next blog, I will discuss the steps I took to address and fix this issue. Next blog can be found here: Contributing to Node.js: Implementing Dynamic Colors for Test Runner Diagnostics (2/3)

Publishing resume-enhancer to PyPI

Harshil Patel — Sun, 24 Nov 2024 02:05:29 +0000

Hi my name is Harshil and if you have read my previous blogs then you know that I am working on a Command line tool called resume-enhancer. ResumeEnhancer is a command-line tool that uses AI to optimize your resume for specific job descriptions. Input your current resume and job description, and it will suggest changes to highlight relevant skills, experience, and certifications without adding false information. It helps tailor your resume to increase your chances of getting hired. I was working on this tool for quite some time and here is my first blog I wrote when I started working on this.

I publish resume-enhancer to PyPI. This blog is about my experience of publishing my CLI tool to PyPI.

To begin with, I created a file called pyproject.toml and it contain logic for building the resume-enhancer. Below is the example of my pyproject.toml file for resume-enhancer and I will share some details about it.

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "resume-enhancer"
dynamic = ["version"]
description = "A CLI tool for optimizing and tailoring resumes based on job descriptions using AI."
readme = "README.md"
readme-content-type = "text/markdown"
license = {text = "MIT"}
authors = [
    { name = "Harshil Patel", email = "26harshilpatel11@gmail.com" }
]
homepage = "https://github.com/hpatel292-seneca/ResumeEnhancer"
requires-python = ">=3.11"
dependencies = [
    "annotated-types==0.7.0",
    "anyio==4.5.0",
    "certifi==2024.8.30",
    "charset-normalizer==3.3.2",
    "colorama==0.4.6",
    "distro==1.9.0",
    "groq==0.11.0",
    "h11==0.14.0",
    "halo==0.0.31",
    "httpcore==1.0.5",
    "httpx==0.27.2",
    "idna==3.10",
    "jiter==0.5.0",
    "log-symbols==0.0.14",
    "lxml==5.3.0",
    "openai==1.46.0",
    "pydantic==2.9.2",
    "pydantic_core==2.23.4",
    "pypdf",
    "python-docx==1.1.2",
    "requests==2.32.3",
    "six==1.16.0",
    "sniffio==1.3.1",
    "spinners==0.0.24",
    "termcolor==2.4.0",
    "tomli==2.0.2",
    "tqdm==4.66.5",
    "typing_extensions==4.12.2",
    "urllib3==2.2.3"
]

[project.optional-dependencies]
dev = [
    "black==24.10.0",
    "flake8",
    "pre-commit==4.0.1",
    "pytest==8.3.3",
    "pytest-xdist==3.6.1"
]

[project.scripts]
resume-enhancer = "app.resume_enhancer:main"

[tool.hatch.build.targets.wheel]
packages = ["app"]

# Dynamic versioning using Hatchling
[tool.hatch.version]
path = "app/_version.py"

1. `[build-system]`

This is where you tell Python what tools to use to build your project. I chose Hatchling because it’s lightweight and gets the job done without unnecessary complexity. The requires line lists Hatchling as a dependency, and build-backend points to the module that actually handles the building process.

2. `[project]`

This is all about the “what” and “who” of your project:

name is the name of the tool people will search for on PyPI. In my case, it’s resume-enhancer.
dynamic: Instead of hardcoding the version number, I’m letting Hatchling handle it dynamically (more on that below).
description and readme: These give users an overview of the tool and display nicely on the PyPI project page. The description is short and sweet, and the readme points to my README.md file, which explains everything in detail.
license: I went with MIT because it’s simple and permissive.
authors: This is where I get to take some credit—my name and email go here.
homepage: A link to the GitHub repo so users can check out the source code, file issues, or contribute.
requires-python: I set a minimum Python version of 3.11 because I wanted to use its newer features.
dependencies: This is the shopping list of all the packages my tool needs to work. It includes things like openai (for the AI magic), pydantic (for validating data), and tqdm (for those cool progress bars).

3. `[project.optional-dependencies]`

This is the “extras” section for developers. I added a dev group here with tools like:

black: Makes sure the code is formatted nicely.
flake8: Keeps the code lint-free.
pytest: Makes testing easier.
pre-commit: Runs checks automatically before you commit code to avoid silly mistakes.

4. `[project.scripts]`

Here’s the cool part—this section makes the tool runnable from the command line. When someone installs resume-enhancer, they can just type resume-enhancer in the terminal to launch it. This works by pointing to the main function inside my app.resume_enhancer module.

5. `[tool.hatch.build.targets.wheel]`

This section tells Hatchling to include the app directory when building the package. It’s a simple way to make sure only the important files are packaged when the tool is uploaded to PyPI.

6. `[tool.hatch.version]`

This part makes versioning easy. Instead of manually updating the version every time I make changes, Hatchling reads it directly from a file (app/_version.py). It’s super handy, especially if you’re using automation tools for publishing.

Publishing Resume Enhancer to PyPI

Once my pyproject.toml file was ready, the next step was to package and publish Resume Enhancer. Since I’m working on Windows, I used Python commands to handle the build and upload process. Here’s how it works:

Step 1: Install Required Tools

Before you can publish, you need to make sure the necessary tools are installed. Run these commands to set everything up:

py -m pip install --upgrade build twine

build is used to create the distributable package.
twine handles uploading the package to PyPI.

Step 2: Build the Package

To package the tool, I ran the following command in the project directory (the one containing pyproject.toml):

py -m build

This creates a dist/ directory containing two files:

A source distribution (.tar.gz)
A built distribution (.whl)

These files are what you’ll upload to PyPI.

Step 3: Publish to PyPI

Once the package was built, I published it to PyPI with the following command:

py -m twine upload dist/*

Twine will prompt you to enter your PyPI credentials. If you don’t have an account, you can create one here. Once you enter the credentials, Twine takes care of the rest, uploading your package to PyPI.

Changes Made for the Chosen Package Format and Registry

To package Resume Enhancer for PyPI, I didn’t need to make drastic changes to my codebase, but I did have to tweak a few things to meet the requirements of the chosen package format and registry. Here’s what I changed:

1. Added `app/_version.py`

To dynamically manage the version of the tool, I created a file called app/_version.py with the following content:

# Version file for Resume Enhancer Tool
__version__ = "1.0.2"

This file acts as the single source of truth for the version number, making it easier to update in one place whenever I release a new version.

2. Configured the Version in the Code

In my config file, I imported the version from app/_version.py to ensure consistency throughout the tool. Here’s an example:

from app._version import __version__

# App Config
TOOL_NAME = "Resume Enhancer Tool"
VERSION = __version__

By doing this, I can display the version wherever needed (e.g., in the CLI output) and ensure that it matches the version uploaded to PyPI.

User Testing Session: Insights and Improvements

I had one of my friends who test the Resume Enhancer tool. It was a great experience, as he easily navigated through the tool using the README as his guide and successfully ran it without encountering any issues. His feedback was incredibly valuable in ensuring that the tool and documentation were beginner-friendly and easy to use.

What Worked Well

Clear Documentation: My friend found the README straightforward and was able to install the tool, understand the commands, and use it effectively.
Smooth Functionality: The tool worked as expected, and he especially appreciated the examples in the Usage section, which helped him quickly test the core functionality.

Suggestions for Improvement

Although he had no trouble running the tool, he suggested adding:

A Note on Installing Dependencies: He pointed out that while pip install resume-enhancer works, users might not realize they need to have pip set up correctly on their system. A small section explaining how to install pip and ensure Python is in the system PATH would help complete beginners.

How to Install and Use Resume Enhancer

Now that Resume Enhancer is live on PyPI, installing and using the tool is quick and easy! Here's how users can get started:

Install the Tool Open your terminal or command prompt and run:

   pip install resume-enhancer

Verify Installation Check if the installation was successful by running:

   resume-enhancer --version

Run the Tool To use the tool, provide the path to your resume and job description along with your API key:

   resume-enhancer --resume path_to_resume --description path_to_description --api_key groq_api_key

Configuration File You can simplify command usage by creating a configuration file. Learn more about it here.

For detailed documentation and examples, check out the GitHub repository and the PyPI project page.

From Bug Fixes to Best Practices: My Open Source Contributions to ChatCraft and xUnit

Harshil Patel — Wed, 20 Nov 2024 22:35:23 +0000

First PR

This blog is about the two PRs I made this week. If you’ve read my last blog about my contribution to ChatCraft, where I worked on the Ask and Retry menus, you’ll know that I contributed a reusable component for those menus. While working on that issue, I discovered a bug.

The bug occurred when you retried a response—sometimes the request failed on the LLM side, but no error message was displayed on ChatCraft when it happened. To address this, I opened an issue, included a video demonstrating the bug, and asked the maintainer if I could work on it.

Sometime AI message retry is failing. #716

hpatel292-seneca posted on Nov 09, 2024

https://github.com/user-attachments/assets/769179fd-2428-4725-8ec9-3fe759ea887e

Hi @humphd @tarasglek , I notice that some AI message retry is failing API call.

View on GitHub

After receiving the maintainer's approval to work on this, I started investigating the issue. My first task was to locate the function responsible for making the API call for the retry action. I began by examining the component that renders the retry button. Then, I followed the chain of parent components that passed the RetryFunction to this component. Eventually, I found the function handleRetryClick, which contained the logic for handling retries. Interestingly, there was a //TODO comment left by the original developer to add UI error handling in the catch block.

After identifying the location, my next task was to display the error message using the useAlert() hook, as requested by the maintainer. I implemented the change by adding the error() method like this:

I then created a PR for this change and requested the maintainer's review.

added UI Error display for failed retry on message #733

hpatel292-seneca posted on Nov 16, 2024

This Fixes #716

Changes

chatcraft.org\src\components\Message\AiMessage.tsx (https://github.com/tarasglek/chatcraft.org/blob/83d180244708becc62ac61e4452b923a2412a33b/src/components/Message/AiMessage.tsx#L130)

Update the catch block for retry from this

catch (err) {
        // TODO: UI error handling
        console.warn("Unable to retry message", { model, err });
      }

to this

catch (err: any) {
        error({
          title: `Response Error`,
          message: err.message,
        });
        console.warn("Unable to retry message", { model, err });
      }

Here is the demo:

https://github.com/user-attachments/assets/371ebd0d-dbb1-4236-a38f-110eedee883e

View on GitHub

The maintainer requested a small update to change the error message from Response Error to Retry Error. After making this change, my PR was merged.

Second PR: Improving Documentation for Member References in xUnit Attributes

Recently, I have been learning xUnit for writing unit test cases for one of my projects. While exploring the xUnit GitHub repository, I noticed it is an open-source project. This sparked my interest, and I started looking for issues to contribute to. I found a relatively simple issue:

Add an analyzer which recommends nameof usage #2991

bradwilson posted on Aug 01, 2024

Whenever we use string properties on attributes intended to point at a member, we should encourage the use of nameof rather than hard-coded strings.

This includes, at least (please look and see if there are others):

IFactAttribute.SkipUnless
IFactAttribute.SkipWhen
MemberDataAttribute constructor

View on GitHub

This issue aimed to improve the clarity and reliability of attributes that reference class members. The goal was to encourage developers to use safer practices, such as the nameof operator, when referencing members in attributes like MemberData, SkipWhen, and SkipUnless.

The Problem

When working with attributes like MemberDataAttribute, developers often rely on hard-coded strings to reference class members. For example:

[MemberData("SomeMemberName")]

This approach has several drawbacks:

Refactoring Risks: If the member name changes, the string reference doesn’t update, leading to runtime errors.
Readability: Hard-coded strings are less clear than using nameof.
Compile-Time Safety: Strings aren’t validated at compile time, making it easier to introduce typos or errors.

The Solution

To address this, I proposed an improvement to the XML documentation for these attributes. The updated documentation explicitly recommends using the nameof operator to reference members, ensuring compile-time safety and better readability.

Example Documentation Updates

For MemberDataAttribute:

/// <param name="memberName">
/// The name of the public static member on the test class that will provide the test data. 
/// It is recommended to use the <c>nameof</c> operator to ensure compile-time safety, 
/// e.g., <c>nameof(SomeMemberName)</c>.
/// </param>

For SkipWhen:

/// <remarks>
/// To avoid issues during refactoring, it is recommended to use the <c>nameof</c> operator
/// to reference the property, e.g., <c>SkipWhen = nameof(IsTestSkipped)</c>.
/// </remarks>

For SkipUnless:

/// <remarks>
/// The name of the public static member on the test class that will provide the test data.
/// It is recommended to use the <c>nameof</c> operator to ensure compile-time safety, 
/// e.g., <c>nameof(SomeMemberName)</c>.
/// </remarks>

The Impact

These changes improve the developer experience by:

Encouraging compile-time safety, reducing runtime errors.
Enhancing readability and maintainability of code.
Supporting better practices for refactoring, especially in large projects.

My PR

After implementing the changes, I submitted a PR and requested the maintainer’s review. You can find the PR here:

added recommendation to use nameof #3062

hpatel292-seneca posted on Nov 18, 2024

This fixes #2991

Change History

MemberDataAttribute: Updated XML documentation for the memberName parameter to recommend using the nameof operator for compile-time safety.
SkipWhen: Updated XML documentation to suggest the use of nameof for referencing public static properties to ensure safer and more maintainable code.
SkipUnless: Added a recommendation in the XML documentation to use the nameof operator when referencing public static properties, promoting best practices.

View on GitHub

Reflections

This PR reinforced the importance of clear and detailed documentation in guiding developers toward best practices. While the change may seem small, it can significantly impact code quality and developer productivity.

Stepping Out of My Comfort Zone: Refactoring Menus in ChatCraft

Harshil Patel — Wed, 20 Nov 2024 17:10:37 +0000

Hi! My name is Harshil, and I am currently enrolled in an Open Source Development course at Seneca College. I had heard great reviews about this course, which is why I decided to enroll. During the lectures, I remember my professor repeatedly saying to "go out of your comfort zone" while contributing to open-source repositories. At the time, I didn’t give much thought to this advice.

Last month, I contributed to four open-source repositories, and I just realized that I did those contributions while staying in my comfort zone. I was working with technologies I was familiar with, tackling issues I knew how to resolve, and handling tasks that weren’t particularly challenging for me. While these contributions were valuable, I now understand that I wasn’t learning much by staying in my comfort zone.

This blog is about an issue I contributed to that pushed me out of my comfort zone. It was during this experience that I realized learning happens when you push yourself beyond what feels comfortable. Growth truly begins when you step outside your comfort zone.

Issue

This blog is about my contribution to ChatCraft.

tarasglek / chatcraft.org

Developer-oriented ChatGPT clone

ChatCraft.org

Welcome to ChatCraft.org, your open-source web companion for coding with Large Language Models (LLMs). Designed with developers in mind, ChatCraft transforms the way you interact with GPT models, making it effortless to read, write, debug, and enhance your code.

Whether you're exploring new designs or learning about the latest technologies, ChatCraft is your go-to platform. With a user interface inspired by GitHub, and editable Markdown everywhere, you'll feel right at home from the get-go.

Features

We think ChatCraft is the best platform for learning, experimenting, and getting creative with code. Here's a few of the reasons why we think you'll agree:

🛠️ You're in Control: Customize all aspects of a chat. Use your own System Prompts, edit, delete, and retry AI messages with models from competing vendors in the same chat.

🌍 Multiple AI Providers: ChatCraft supports both OpenAI and OpenRouter, giving you access to a…

View on GitHub

The task for this assignment was to tackle bigger issues than the ones I worked on last month. While looking for issues, I found an interesting one in ChatCraft:

Re-use features from Ask menu in Retry sub-menu #643

humphd posted on May 31, 2024

In #642 @menghif did some expert work to make the Ask menu more responsive and easier to use. We have a similar need in the Retry menu for AI Message responses. It would be interesting to see if we can re-use the same UX there, such that you can switch providers/models when retrying.

View on GitHub

The issue, "Re-use features from Ask menu in Retry sub-menu," focuses on improving the Retry menu for AI responses by reusing the better design and functionality from the Ask menu. Essentially, the task was to develop a reusable component for the menu that could be rendered in different places.

Since I had contributed to ChatCraft before, I already had a local clone of the repository. However, when I tried pulling the latest changes, I realized my local repository wasn’t up-to-date with the original repository. At that point, I needed to set up a remote upstream. After setting it up, I successfully pulled the latest changes and got started.

Contribution Process

I started by identifying the files I needed to change. Once I found them, I took time to understand the context and figured out the logic behind the menu functionality, which needed to be extracted into a reusable component. Essentially, there were two places—the Ask menu and the Retry menu—that rendered menu components, and the maintainer wanted to reuse the same logic in both places.

I wasn’t very familiar with the menu component from @chakra-ui/react, so I researched it and found that its structure looked like this:

Menu > MenuButton > MenuList > MenuGroup > MenuItem

Initially, I thought about making MenuList reusable while keeping Menu and MenuButton at their original locations since the Ask menu and Retry menu had some differences in functionality, like hover effects and click handling. However, this approach didn’t work because the Ask menu used components from @chakra-ui/react, while the Retry menu used components from @szhsin/react-menu. This difference in libraries meant I had to make the entire menu reusable instead of just parts of it. I mentioned this in the issue's comments:

Comment for #643

hpatel292-seneca commented on Nov 09, 2024

Here's the corrected and improved version:

Hi @humphd, I tried to separate out the menu logic into a separate component, and it worked. Here is the demo:

Demo Link

I just need to confirm one thing. I used a conditional in the component to render the MenuButton like this:

{menuButtonLabel &&
      React.isValidElement(menuButtonLabel) &&
      menuButtonLabel.type === SubMenu ? (
        <MenuButton
          as={Box}
          fontSize="1rem"
          fontWeight="normal"
          cursor="pointer"
          color="inherit"
          padding="0"
          background="none"
          border="none"
          aria-label={label || "Choose Model"}
          title={label || "Choose Model"}
          onClick={openOnHover ? undefined : onOpen} // Open on click if not openOnHover
          onMouseEnter={openOnHover ? onOpen : undefined} // Open on hover if openOnHover
          onMouseLeave={openOnHover ? onClose : undefined} // Close on hover out if openOnHover
        >
          {menuButtonLabel}
        </MenuButton>
      ) : (
        <MenuButton
          as={IconButton}
          size="sm"
          fontSize="1.25rem"
          aria-label={label || "Choose Model"}
          title={label || "Choose Model"}
          icon={<TbChevronUp />}
          onClick={openOnHover ? undefined : onOpen} // Open on click if not openOnHover
          onMouseEnter={openOnHover ? onOpen : undefined} // Open on hover if openOnHover
          onMouseLeave={openOnHover ? onClose : undefined} // Close on hover out if openOnHover
          borderLeftRadius="0"
        />
      )}

The reason for this approach is that both use cases require MenuButton to function differently. Initially, I tried to keep this logic separate and only shared the menuItem logic, but it didn’t work. This is because the two places where this component needs to render use different menu libraries: one uses @chakra-ui/react components, and the other uses @szhsin/react-menu. That’s why I had to make the entire Menu component reusable.

What do you think?

View on GitHub

To handle the differences, I used an ad-hoc approach for rendering MenuButton. The Ask menu required a click effect to open, while the Retry menu used a hover effect. With this solution in place, everything was working as expected, so I created a pull request (PR):

Added ModelProviderMenu component and reused it in PromptsendButton and MessageBase #729

hpatel292-seneca posted on Nov 15, 2024

This fixes #643.

Added a reusable component, ModelProviderMenu, and replaced the logic in PromptSendButton and MessageBase to utilize this component.

Overview of Changes:

Added a new component:
ModelProviderMenu contains the logic for displaying models and providers, allowing the user to change models and providers directly from it.
Updated PromptSendButton:
Replaced the existing menu logic in PromptSendButton with the ModelProviderMenu component. This menu appears next to the send button.
Updated MessageBase:
Refactored the retry logic in MessageBase to use the ModelProviderMenu component, ensuring consistency and reusability.

Demo

https://github.com/user-attachments/assets/b55bf561-08c3-4d74-8958-1f7b3c6ac559

View on GitHub

Interestingly, the owner added me as a developer for the repository and asked me to send another PR from the original repository’s branch.

I accepted the developer request and cloned the original repository. Initially, I was confused about how to transfer my changes from my forked repository’s branch to the original repository’s branch. Then I remembered I could set up my forked repository as a remote, fetch the branches, and merge the changes. I did that successfully and made another PR from the original repository branch.

Change Requests

After making the PR, the maintainer started reviewing my changes and requested several updates—eight change requests in total.

Added ModelProviderMenu component and reused it in PromptsendButton and MessageBase #730

hpatel292-seneca posted on Nov 15, 2024

This is Requested from #729

</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/tarasglek/chatcraft.org/pull/730">View on GitHub</a></div>

It turned out that my ad-hoc approach was making the new component less reusable and introduced bugs. The maintainer suggested that the new component should use @szhsin/react-menu instead of @chakra-ui/react, and asked me to revisit the previous approach of extracting MenuList.

I started by making the required changes and created a new component called ModelSelectionMenuList, extracting the MenuList into this component. It worked as expected for the Retry menu, as its parent component was already using @szhsin/react-menu. However, it failed for the Ask menu, which was still using @chakra-ui/react components.

I reached out to the maintainer again, and they advised refactoring the Ask menu to also use @szhsin/react-menu components. Following their guidance, I successfully refactored the Ask menu to align with the new structure. This made the component consistent and reusable across both menus.

Mobile Screen Refactoring

While refactoring the Ask menu, I discovered that it was rendered differently for mobile and laptop screens. To address this, I updated my new component to handle both variations by using the same template logic to render different menus based on screen size. I also ensured that the Ask menu for mobile screens was refactored appropriately.

Final Thoughts

In total, I spent around two full days completing the PR for this issue. During the process, I had moments of doubt, feeling like I might not be able to finish it. However, I persevered and completed the task, gaining valuable knowledge in the process.

The most important lesson I learned from this issue—and from the Open Source Development course—is to challenge myself and step out of my comfort zone. Growth truly happens when we push our boundaries, and this experience reinforced that belief.

Automating Testing: My Journey with GitHub Actions, CI Pipelines, and Test Automation

Harshil Patel — Fri, 15 Nov 2024 22:13:45 +0000

This week, I was tasked with automating testing, linting, and error checking for my ResumeEnhancer project using a GitHub Actions CI workflow. Continuous Integration (CI) automatically tests new code as soon as it's added, helping to catch issues early before they affect the entire project. This ensures the code remains stable, speeds up development, and facilitates smoother collaboration among developers.

CI pipelines are not new to me, as I’ve developed CI/CD pipelines for previous projects. However, last month, while contributing four pull requests to open-source projects, I realized the importance of pipelines in maintaining clean and consistent code across repositories.

In this blog, I’ll share my experience setting up a CI pipeline. I chose GitHub Actions because I’m already using GitHub for source control. GitHub Actions spin up a machine to execute tasks when code is pushed or a pull request is created. To implement CI with GitHub Actions, you define a series of steps to ensure your code meets the required standards.

For my ResumeEnhancer project, I am using:

Black for code formatting,
Flake8 for linting,
Pytest for testing.

Here’s how my CI pipeline looks:

name: ResumeEnhancer CI Pipeline - Test, Lint, and Format

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

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.11", "3.12"]

    steps:
      # Check out the repository code
      - name: Checkout code
        uses: actions/checkout@v3

      # Set up Python
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v2
        with:
          python-version: ${{ matrix.python-version }}

      # Install dependencies
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      # Make format.sh and lint.sh executable
      - name: Make scripts executable
        run: chmod +x ./format.sh ./lint.sh

      # Run formatting
      - name: Run format.sh
        run: ./format.sh
        continue-on-error: false

      # Run linting
      - name: Run lint.sh
        run: ./lint.sh
        continue-on-error: false

      # Run tests
      - name: Run Tests
        run: |
          pytest

Initially, I included Python versions ["3.10", "3.11", "3.12"], but my CI run failed. After investigating, I discovered that the tomllib module, which I’m using, is built into Python starting from version 3.11. As a result, I had to remove Python 3.10 from the list.

This CI pipeline for the ResumeEnhancer project automatically runs whenever code is pushed to the main branch or a pull request is created. It uses an Ubuntu environment and tests the code on Python versions 3.11 and 3.12. The pipeline performs several steps:

Checks out the repository code.
Sets up the required Python version.
Installs project dependencies.
Ensures that the formatting (format.sh) and linting (lint.sh) scripts are executable and error-free.
Runs automated tests using pytest.

Here’s the result after successfully setting up the CI pipeline:

While I’ve worked with CI before, setting it up for my project reminded me of how valuable it is. It’s reassuring to know that every time I push code or open a pull request, the pipeline automatically checks formatting, linting, and tests—saving me from manual effort. It’s like having a safety net that ensures the code remains clean and consistent, which is especially helpful when contributing to open-source projects or collaborating with others. CI reduces stress and makes development more efficient.

Testing Out a Classmate’s CI Workflow

To test CI workflows further, I collaborated with my friend Non. I added a test case to his repository, chat-completion-api, to evaluate his CI pipeline, and he did the same for mine. His project also uses Python, but instead of pytest, it uses unittest for testing.

The main difference between unittest and pytest is that unittest is a built-in testing framework with a structured approach, while pytest offers more flexibility and features, making testing simpler and more powerful. Since I’m familiar with pytest, adapting to unittest was straightforward. I wrote two test cases for a function in utils.py, and here’s the PR.

Overall, I enjoyed working with CI. It simplifies development and ensures high-quality, consistent code.

Automated Testing Made Simple: Setting Up and Exploring pytest

Harshil Patel — Wed, 06 Nov 2024 22:43:50 +0000

This blog is about integrating a testing framework into my ResumeEnhancer CLI tool. As my work on ResumeEnhancer has progressed, I realized that adding test cases would be essential to maintain code quality as the project grows. I considered a few options like pytest, nose, and unittest but chose pytest since it’s widely used and a great choice for learning a popular testing framework.

Setting up pytest is straightforward—just run pip install pytest, and you’re ready to go.

Testing

I began by researching how to write and run test cases with pytest. I created a tests folder and added my first test file called test_utils.py. I decided to follow the test_filename.py naming convention and wrote my initial test case for a utility function called read_txt_file(). This function reads text from a .txt file, as the name suggests. I explored three different ways to test this:

Mock the open function – This approach pretends to open a file without actually creating one.
Create a temporary text file – Here, I’d create a small .txt file in the test specifically for this function.
Use a test.txt file in the project folder – I’d store a test file in the main folder to use as needed.

Finally, I decided to mock the open function and proceeded to write the test cases.

Next, I explored ways to run specific test cases. I found that you can run a particular test case with pytest path_to_test_file::class_name::test_name. If you haven’t used classes, you can omit the class name, like this:

pytest also has a Watch Mode, which reruns only failing tests automatically whenever the code changes. To use it, add the --looponfail option:

Mocking API Responses

Next, I wanted to add test cases for the get_response() method. This function takes a resume and job description as inputs, along with settings to customize the response. It uses an AI model to review the resume and suggests ways to make it a better fit for the job description. The feedback focuses on highlighting important skills, experiences, and keywords that could be added or emphasized to improve alignment with the job requirements.

Since get_response() uses the Groq API, I needed to mock the API call for testing. Here’s how I initially tried it:

import responses

sample_llm_response = {"choices": [{"delta": {"content": "Mocked response content"}}]}
responses.add(
    responses.POST,
    "https://api.groq.com/openai/v1/chat/completions",  # Mock this URL
    json=sample_llm_response,
    status=200,
)

However, when I ran the test, it failed with an error saying the API_KEY was invalid.

After some investigation, I realized that the code initializes the Groq client first with client = Groq(api_key), and then makes the API call. Mocking this constructor call directly didn’t work, so I decided to mock the entire Groq client like this:

@mock.patch("resume_enhancer.Groq")  # Mock Groq client initialization
def test_get_response_valid(mock_groq):
    # Mock the client instance and its chat.completions.create method
    mock_client_instance = mock.Mock()
    mock_groq.return_value = mock_client_instance  # Groq() returns the mock client instance
    mock_client_instance.chat.completions.create.return_value = [  # Mock response
        mock.Mock(
            choices=[mock.Mock(delta=mock.Mock(content="Mocked response content"))]
        )
    ]

    # Capture stdout to check the printed output
    with mock.patch("sys.stdout", new_callable=StringIO) as mock_stdout:
        get_response(
            resume="Sample Resume",
            description="Sample Job Description",
            api_key="test_api_key",
        )
        output = mock_stdout.getvalue()
    # Assert that the expected content is printed in the output
    assert "Mocked response content" in output

I wrote 11 test cases to check different scenarios for get_response(), and all the tests passed. However, I found myself repeating the Groq mocking code in each test, which made things messy. I looked for ways to avoid this repetition and found I could use a class-based setup to share common mocking logic among all tests. Here’s the improved setup:

class Test_get_response:

    def setup_method(self):
        # Mock the Groq client and its completions method
        self.patcher = mock.patch("resume_enhancer.Groq")
        self.mock_groq = self.patcher.start()  # Start the patch

        self.mock_client_instance = mock.Mock()
        self.mock_groq.return_value = self.mock_client_instance
        self.mock_client_instance.chat.completions.create.return_value = [
            mock.Mock(
                choices=[mock.Mock(delta=mock.Mock(content="Mocked response content"))],
                x_groq=mock.Mock(
                    usage=mock.Mock(
                        completion_tokens=100,
                        prompt_tokens=50,
                        total_tokens=150,
                        completion_time=0.35,
                        prompt_time=0.15,
                        queue_time=0.1,
                        total_time=0.6,
                    )
                ),
            )
        ]

    def teardown_method(self):
        self.patcher.stop()  # Stop all patches after each test

This setup removed the repetitive mock code, and everything worked smoothly.

Conclusion

I learned a lot about pytest, including how to mock API calls, function calls, and even third-party classes like Groq. Testing has shown me how useful it is for keeping the code reliable as I add features.

Before this, I had written test cases in JavaScript using Jest, but this was my first experience mocking both functions and an API. Previously, I only did basic tests without much setup for dependencies, so learning to mock an entire API client in pytest was new for me. This process has helped me understand the value of mocking for isolating parts of the code in testing.

Now, I see why testing is so valuable, and I’ll make it a habit in future projects. It catches issues early, makes the code easier to update, and builds confidence that everything works as expected. This experience has shown me that putting effort into testing upfront is well worth it for creating better, more reliable projects.

Automating Code Quality: A Guide to Setting Up Formatters, Linters, and Pre-Commit Hooks in Python Projects

Harshil Patel — Fri, 01 Nov 2024 18:42:22 +0000

Enhancing Code Quality with Static Analysis Tools in Resume Enhancer

In this blog, I’ll share my experience of adding Static Analysis tools to my Resume Enhancer project. Static analysis tools work on source code itself, helping to maintain quality by automatically fixing formatting issues, spotting potential code flaws, and alerting us to common errors.

Source Code Formatter

For code formatting, I chose Black. Black has become my go-to formatter because it removes the need to worry about minor formatting decisions. By using Black, I give up some control over these small details, but in return, I get a fast, consistent, and reliable tool that keeps my code clean and eliminates pycodestyle warnings. This frees up time and mental energy for more important tasks.

To install Black, I used:

pip install black

After exploring the documentation, I ran Black manually on my main code file, resumeEnhancer.py, and found that most of my code was already formatted. Here’s what it looked like:

Next, I created a format.sh script to make it easy to run Black on all coding files in one step. Here’s the result of executing the script:

Linter

Linters help us catch common and subtle mistakes, which can be easy to overlook. To spot these issues, I used Flake8 to lint my source code. After installing Flake8 with pip install flake8, I ran it on my main code file and, to my surprise, discovered many errors:

I added Flake8 configurations in a .flake8 file and created a lint.sh script to streamline the linting process. After fixing all the errors that Flake8 identified, I realized how essential linting is—it catches tiny errors that could otherwise lead to larger issues later on.

Editor/IDE Integration

Using static analysis tools at build time is great for automating code quality checks, but integrating them directly into my editor made an even bigger impact. With Black and Flake8 integrated into my editor, I could catch and fix issues as I coded—no waiting until I was finished. A formatter that tidies code on save and a linter that flags issues in real-time helped keep my code clean and consistent.

To integrate Black and Flake8, I installed the necessary extensions in VSCode. Initially, I installed an extension called black instead of black formatter, which caused formatting issues. After troubleshooting, I discovered the correct extension, and everything worked smoothly.

Pre-Commit Hook

Adding a Git pre-commit hook was a powerful way to ensure my code remained consistent and clean before each commit. A pre-commit hook automatically runs the formatter on any files being committed, saving us from having to remember to do it manually.

Pre-commit hooks are especially useful when working with others because they apply formatting uniformly across all commits, making the project’s codebase more readable. Setting one up was straightforward. I used pre-commit to configure a hook that runs Black on any changed files before committing.

After configuring the pre-commit hook, I tested it, and it worked perfectly:

What I Learned

This lab taught me the value of automating code quality checks. Setting up tools like Black and Flake8 wasn’t just about following rules—it made my coding process smoother and more efficient. I realized how much time and effort is saved when formatting and linting happen automatically, allowing me to catch issues early on. This experience showed me the power of automation and consistent coding standards in collaborative projects.

Hacktoberfest 2024: My Journey and Key Learnings

Harshil Patel — Sun, 27 Oct 2024 23:00:12 +0000

Final Recap Blog Post: My Hacktoberfest 2024 Journey

October has been a month full of learning and challenges! Hacktoberfest 2024 was my first time contributing to open-source, and it was a great experience. In this blog, I’ll reflect on everything I did this month, how I improved, and what I learned from it all.

Summary of Contributions

I started this month by contributing to four different projects as part of Hacktoberfest. Each one came with its own set of challenges, but in the end, I was able to complete all four PRs successfully.

My first PR was for Chatcraft, where I worked on adding new logos for different LLM models. This task taught me how important it is to communicate with maintainers and be open to feedback. Even small changes, like updating logos, can make a big impact.

The second PR I did was for WrenAI, and this one was the most challenging. I had to deal with multiple services running on Docker, install dependencies, and even run into OpenAI token errors. It was frustrating at times, but I learned so much about how big projects work and how to debug them.

For my third PR, I contributed to ZTM-Quest, a fun game project where I adjusted the player's speed based on their energy level. This PR was exciting because it combined coding with something I enjoy—games. It also taught me about game mechanics and handling dynamic properties.

My fourth PR was for Libplanet, and I wanted to switch things up by working with C#. I had experience with C# from my ASP.NET projects, so it felt like the right move. I worked on removing redundant code from a utility class used for unit testing. This task helped me brush up on unit testing and gave me a chance to work with a decentralized .NET library.

How I Improved

Throughout Hacktoberfest, I’ve definitely grown as a developer. At the beginning of the month, I felt a bit lost when navigating large repos, but by the end, I was much more confident. I’ve gotten better at source control, debugging, managing dependencies, and reading through codebases. My problem-solving skills have also improved since I had to tackle a lot of unexpected issues, especially with WrenAI.

Patience and persistence were key lessons for me. Not everything went smoothly, and some tasks took longer than expected. But I learned how to stay calm and work through the problems one step at a time.

Lessons Learned

One of the biggest things I learned during Hacktoberfest was that open-source isn’t just about coding. It’s about teamwork, following guidelines, and understanding the community’s goals. The feedback I got from maintainers was super helpful, and it taught me how to write cleaner, more efficient code.

I also learned not to be afraid of contributing to bigger projects, even if they seem overwhelming. Some of my best learning moments came from working on WrenAI and Libplanet, which pushed me to step out of my comfort zone.

What’s Next

Even though Hacktoberfest 2024 is over, I’m excited to keep contributing to open-source. This month has shown me how rewarding it can be to be part of these projects, and I want to keep going. I’m looking forward to exploring new repos and continuing to grow as a developer.

To wrap it up, Hacktoberfest 2024 was an amazing experience. I’ve learned a lot, made valuable contributions, and grown both in my skills and confidence. I’m excited to see where this open-source journey takes me next!

DEV Community: Harshil Patel

Kubernetes on Windows: A Guide to Running Kubernetes Using Minikube and kubectl

hpatel292-seneca / Learning-Kubernetes

This repo contains basic notes about kubernetes like its Architecture, components and how to use kubernetes using kubectl

Learning-Kubernetes

What is Kubernetes?

What is Container Orchestration??

Why Kubernetes was developed??

Need for Container Orchestration tool:

Installing Minikube

Setting Up a Hypervisor

Basic Operations with kubectl

1. Check the Status of Nodes

2. List Pods

3. List Services

4. Create a Deployment

5. View Deployment

6. View ReplicaSets

7. Edit a Deployment

8. Check Logs

9. Describe a Pod

10. Access Pod Shell

11. Delete a Deployment

12. Apply Configuration File

Setting Up a CI/CD Pipeline with Azure and Playwright for StyleMate

Adding a Deployment Pipeline

Challenges with Default Pipeline

Pipeline Code

Integrating Testing

Challenge with E2E Testing

Initial Attempt: Deployment Slots

Staging Environment Solution

Final Workflow

Conclusion

My Journey Contributing to Node.js Core: The Final Chapter (3/3)

Change summary

Updating the Documentation

Adding Test Cases

Final Thoughts

Contributing to Node.js: Implementing Dynamic Colors for Test Runner Diagnostics (2/3)

Introduction

Tracing the Code

Adding Logic for Severity-Based Colors

Building Node.js Locally

Testing the Build

Opening a Pull Request

Conclusion

Contributing to Node.js: Improving Test Runner Coverage Reporting (1/3)

Introduction

Finding the Right Issue

Understanding the Issue

Planning the Fix

Conclusion

Publishing resume-enhancer to PyPI

1. [build-system]

2. [project]

3. [project.optional-dependencies]

4. [project.scripts]

5. [tool.hatch.build.targets.wheel]

6. [tool.hatch.version]

Publishing Resume Enhancer to PyPI

Step 1: Install Required Tools

Step 2: Build the Package

Step 3: Publish to PyPI

Changes Made for the Chosen Package Format and Registry

1. Added app/_version.py

2. Configured the Version in the Code

User Testing Session: Insights and Improvements

What Worked Well

Suggestions for Improvement

How to Install and Use Resume Enhancer

From Bug Fixes to Best Practices: My Open Source Contributions to ChatCraft and xUnit

First PR

Changes

Second PR: Improving Documentation for Member References in xUnit Attributes

The Problem

The Solution

Example Documentation Updates

The Impact

My PR

1. `[build-system]`

2. `[project]`

3. `[project.optional-dependencies]`

4. `[project.scripts]`

5. `[tool.hatch.build.targets.wheel]`

6. `[tool.hatch.version]`

1. Added `app/_version.py`