DEV Community: Tasbi Tasbi

The Final Voyage: Conquering Input Validation and Charting New Paths 🌟

Tasbi Tasbi — Tue, 10 Dec 2024 04:02:50 +0000

When I embarked on this journey to tackle Issue #3 for the React-ChatBotify-Plugins/input-validator, I thought I had a clear course charted. The task? Enhance input validation to make it more efficient and robust. Easy enough, right? I quickly got to work, crafted a pull request, and thought, “This is going pretty smoothly!” 😌

But, as I soon discovered, the calm seas were deceptive. 🌊 What followed was a whirlwind of unexpected challenges, late-night debugging sessions, and a steep learning curve. Now, with the pull request (PR #4) finally generated, I find myself in the waiting phase as the repo owner reviews my work. 🕰️ While I wait, let me take you on a journey through the highs, the lows, and the lessons that made this release so memorable. 🛠️

The Calm Before the Storm: The Issue at Hand ⚓

When I first picked up the issue, it seemed like a fairly straightforward task: refine the input validation logic and make it more intuitive for developers and users alike. 🧩 The initial steps went smoothly, and I managed to get a working solution up and running. The pull request was submitted, and I naively thought, “Wow, I might actually be done early this time!” 🎉

Spoiler alert: I wasn’t. 🫠

The Perfect Storm: Challenges That Tested My Resolve 🌪️

1. Lint Errors – My New Archenemy 🐛

The first major challenge arrived in the form of lint errors. Fix one? Ten more popped up. It was like trying to hold water in a sieve. 🏗️ I’d run the linter, fix a spacing issue, and suddenly be bombarded with new complaints: unused imports, inconsistent indentation, missing semicolons—you name it. 😵‍💫

Here’s an excerpt of the chaos:

ESLint Error: 'React' is defined but never used 😤
ESLint Error: Expected consistent spacing 🫠

After hours of chasing down every error (and resisting the urge to throw my keyboard out the window 😅), I finally had a clean linter run. My victory was short-lived, though, as the real challenges were just beginning. 😬

2. The Phantom Folder: Coverage Files 🗂️👻

Just as I was celebrating my linting success, the repo owner pointed out that I’d committed the coverage folder to the repository. Rookie mistake. 🙈

Fixing this seemed simple enough:

Add the coverage folder to .gitignore 📄✏️
Remove the existing folder from version control history 🗑️

Easy, right? Well, not quite. 🥲 During the process, I accidentally deleted something else and broke the build. It took me a couple of tries (and a LOT of Googling 🕵️‍♀️) to get it right, but in the end, the repo was clean, and I’d learned an important lesson about attention to detail. 👌

3. The Case of the Unnecessary Dependency 🕵️‍♂️📦

Another piece of feedback from the repo owner caught me off guard: I’d added an unnecessary package, @types/testing-library__jest-dom, to the project. To make things worse, in my haste to fix this, I accidentally removed a different dependency instead. 🤦‍♀️

Here’s a quick snapshot of my internal monologue during this debacle:

"Wait, which dependency am I supposed to remove again? 🤔"
"Oh no, I just broke the tests. Undo! Undo! 🚨"
"Okay, let’s try this again, slowly this time... 😅"

Eventually, I got it right. 🙌 But the experience was a humbling reminder to double-check changes before pushing them. 🚀

4. The Surprise Twist 🌀🤯

While working on the issue, I stumbled upon a hidden opportunity for improvement. 🕵️‍♀️ Something about the way input validation was being handled sparked an idea: a potential enhancement that could take this plugin to the next level. I excitedly shared the idea with the repo owner, who acknowledged its value but pointed out that it was too advanced to tackle within my current timeline. 🛠️⏳

Although I couldn’t implement it just yet, this discovery left me inspired. 💡 The best part? The owner and I agreed to revisit the idea in the future, setting the stage for ongoing collaboration even after my semester ends. 🎉

Anchored in Growth: Lessons Learned 🌱

This release taught me more than I could have imagined. Here are the key takeaways:

Persistence is Key: Debugging is an art of patience. 🎨 Every error is a clue, and every fix brings you closer to the goal. 🏁
Attention to Detail: Small things, like .gitignore files and package dependencies, can have a big impact. Overlooking them can create unnecessary headaches. 🤯
Communication Matters: Open-source collaboration thrives on clear and open communication. 🗨️ Feedback from the repo owner was invaluable, and asking questions when in doubt saved me from making bigger mistakes. 🤝
Embrace the Unexpected: Discovering the potential enhancement was a happy accident that reminded me to always keep an open mind while working on a project. 💭✨

On the Horizon: What’s Next? 🚀

Although my semester is wrapping up, my journey with React-ChatBotify-Plugins is far from over. The repo owner is involved in several open-source projects, and I’ve expressed interest in continuing to contribute even after my course ends. 🙌 This collaboration has been an incredible opportunity to grow as a developer, and I’m excited to tackle more advanced challenges in the future. 💻💡

Closing Thoughts 📝

This experience wasn’t just about writing code—it was about learning to navigate the complexities of real-world development, collaborating with others, and growing through challenges. 💪 To anyone considering open-source contributions, my advice is simple: Dive in. You’ll learn more than you ever thought possible. 🚀

As I wait for the final review of my pull request, I’m already looking ahead to new opportunities and the lessons they’ll bring. 🌟 For now, I’ll leave you with this: every challenge is a chance to grow, and every mistake is a step toward mastery. Onward and upward! 🚢✨

**

Week 2 Blog: Progress Report on 0.4 🚀⛵

Tasbi Tasbi — Fri, 06 Dec 2024 04:00:49 +0000

Ahoy, fellow developers! It's time for my Week 2 update on my exciting 0.4 journey. While I’ve made significant strides, there’s a new storm on the horizon: CI issues. Let’s explore what I’ve accomplished so far, the challenges I’m tackling, and my game plan for smooth sailing ahead. 🌊⚓

What Have I Accomplished So Far? 🎯

In the first week, I focused on writing comprehensive tests and achieving high coverage for the @rcb-plugins/input-validator. Here’s the summary of my efforts:

✅ Testing Key Components:

validateFile.test.ts: Ensured file validation for different types of uploads (valid, invalid, empty, and null files).
getValidator.test.ts: Verified that the correct validator functions (validateTextInput, validateFileInput) are retrieved from the flow.
mergePluginConfig.test.ts: Confirmed that user configurations merge correctly with default configurations.
getPromptStyles.test.ts: Checked that dynamic styles apply correctly for error, success, and other prompt types.
useRcbPlugin.test.ts: Focused on the plugin’s core logic, including handling input validation, file uploads, and style restoration.

✅ Achieved High Test Coverage:

Most files have 95–100% coverage, including edge cases. This was a major win for ensuring plugin reliability. 🎉

What Have I Figured Out? 🧠💡

Through focused efforts, I learned:

How to Mock and Simulate Complex Scenarios:
- Used Jest and @testing-library/react to simulate DOM events, file uploads, and style updates.
- Managed to isolate and test plugin logic with precision.
Tackling Dynamic Style Updates:
- Successfully verified that styles update dynamically based on validation results.
Clean Code Practices:
- Modularized tests into distinct files for clarity and maintainability.

New Challenges: CI Issues 🚨⚠️

This week, I opened a Pull Request, which included all the tests and updates. While I was excited about the progress, CI (Continuous Integration) issues emerged like a storm cloud:

Here’s the error report:

Error: Unexpected any. Specify a different type @typescript-eslint/no-explicit-any
Error: 'error is defined but never used' @typescript-eslint/no-unused-vars
Warning: Unused eslint-disable directive (no problems were reported)

Key Problems:

Usage of any: Multiple instances of any in test files caused linting errors.
Unused Variables: Some variables like error were defined but not used, triggering TypeScript warnings.
Coverage Report Issues: The linter flagged unused ESLint directives in the coverage report.

Despite my efforts, I haven’t been able to fully resolve these CI issues yet. The errors are preventing the PR from passing CI checks, which means I can’t merge it into the main branch. 😞

How Will I Adjust? 🛠️⛵

To tackle the current roadblocks and stay on course, here’s my plan:

Fix TypeScript Linting Errors:
- Replace any types with explicit types in all test cases.
- Refactor unused variables or remove them entirely to clean up the code.
Debug and Recheck Tests:
- Ensure all test cases still run smoothly after fixing the linting issues.
- Use the --fix option with ESLint to resolve minor warnings automatically.
Collaborate for Feedback:
- Share the PR with maintainers for guidance on unresolved errors.
- Confirm if my approach aligns with the project’s linting and TypeScript standards.
Stay Flexible:
- If linting issues persist, consider breaking down the PR into smaller, manageable parts for better debugging.

Final Thoughts 💭✨

While the CI issues have slowed down my progress, they’ve also taught me the importance of attention to detail. Testing isn’t just about code coverage—it’s about clean, maintainable, and standards-compliant code.

Despite the hiccups, I’m optimistic about resolving these issues and pushing the PR forward. My next step will be to squash the linting bugs and ensure my work gets merged into the main branch.

Stay tuned for the final blog post next week, where I’ll reflect on the entire journey and (hopefully) celebrate a successfully merged PR! 🎉🚀

Until next time, happy coding! 💻🌟

🛳️ Charting the Course for 0.4 – Setting Sail for Success 🚢

Tasbi Tasbi — Thu, 28 Nov 2024 07:10:56 +0000

Ahoy there, adventurers! 👋 If you've been following my journey through the React Chatbotify seas, you know that my voyage in 0.3 was nothing short of exhilarating. Remember when I introduced file upload validation with TypeScript and React Chatbotify? Here’s a refresher. Spoiler alert: I lived to tell the tale. 🏴‍☠️

Now, as I gear up for the 0.4 voyage, it’s time to lay down the map, plan my destination, and gather the tools I'll need for this adventure. This post is a sneak peek into what I'll be doing in 0.4, why I chose this work, and how I’ll ensure my ship stays afloat. 🌊

🗺️ The Mission: Fortify and Refine 🛠️

For 0.4, I’ll be doubling down on my work with React Chatbotify’s input-validator plugin. The core focus will be to:

Expand Test Coverage: While file validation is seaworthy, other parts of the plugin—like merging configurations, style generation, and text validation—are still uncharted territory. I'll write comprehensive tests to boost confidence in every nook and cranny of the codebase. 🧪
Optimize the Plugin: The input-validator plugin is already robust, but I want to ensure it’s bulletproof and easily extendable for developers who rely on it. A treasure chest of maintainability, if you will. 🏴‍☠️
Contribute Back: My goal isn’t just to complete tasks; it’s to leave the plugin better than I found it. I’ll contribute my work upstream and ensure my code aligns with community standards. 🤝

🤔 Why This Project?

Great question, matey! Here’s why I picked this project:

Familiar Waters: Having worked on this plugin in 0.3, I’m already familiar with its currents and tides. But there’s so much more to explore! 🧭
Community Impact: Plugins like these empower developers to build smarter chatbots. Strengthening it means helping the community sail smoother seas. ⚓
Challenge Accepted: Testing, especially edge cases, can be tricky. But hey, what’s a voyage without a few storms? 🌩️

⚓ The Approach: Staying the Course

Here’s how I’ll navigate this journey:

Step-by-Step Progress: I’ll tackle one test case or feature at a time. Slow and steady wins the race. 🐢
Collaborate: I’ll actively seek feedback from maintainers and peers. After all, even the best captains consult their crew. 👩‍✈️
Stay Organized: With clear goals and weekly check-ins, I’ll ensure my ship doesn’t drift off course. 📅
Embrace Challenges: Bugs, edge cases, and unexpected hurdles? Bring ‘em on! They make the treasure at the end even sweeter. 🪙

🏴‍☠️ Goals for 0.4

💯 Achieve Full Test Coverage: No uncovered lines shall escape!
🚀 Submit a Stellar PR: My work should be clear, concise, and ready to merge.
🌟 Learn and Share: Document my journey, share lessons, and inspire others to contribute.

A Surprise Twist? Stay Tuned! 🌟

While digging through the repo, I stumbled upon a potential area for improvement—something that could really enhance the user experience. 🤫 I’m keeping it under wraps for now, but I’ve already started brainstorming how to tackle this secret challenge. First, I’ll confirm with the repo owner to see if it’s a valid and impactful task. If all goes well, you’ll hear all about it in my Week 2 update! 🕵️‍♀️✨

So there you have it, shipmates—a glimpse into the horizon. 🗺️ Stay tuned for updates as I embark on this adventure and bring back tales of testing, code, and maybe a few treasures along the way. Until next time, happy coding! 💻⚓

🛳️ Charting the Course for 0.4 – Setting Sail for Success 🚢

Tasbi Tasbi — Thu, 28 Nov 2024 07:10:56 +0000

🗺️ The Mission: Fortify and Refine 🛠️

For 0.4, I’ll be doubling down on my work with React Chatbotify’s input-validator plugin. The core focus will be to:

Expand Test Coverage: While file validation is seaworthy, other parts of the plugin—like merging configurations, style generation, and text validation—are still uncharted territory. I'll write comprehensive tests to boost confidence in every nook and cranny of the codebase. 🧪
Optimize the Plugin: The input-validator plugin is already robust, but I want to ensure it’s bulletproof and easily extendable for developers who rely on it. A treasure chest of maintainability, if you will. 🏴‍☠️
Contribute Back: My goal isn’t just to complete tasks; it’s to leave the plugin better than I found it. I’ll contribute my work upstream and ensure my code aligns with community standards. 🤝

🤔 Why This Project?

Great question, matey! Here’s why I picked this project:

Familiar Waters: Having worked on this plugin in 0.3, I’m already familiar with its currents and tides. But there’s so much more to explore! 🧭
Community Impact: Plugins like these empower developers to build smarter chatbots. Strengthening it means helping the community sail smoother seas. ⚓
Challenge Accepted: Testing, especially edge cases, can be tricky. But hey, what’s a voyage without a few storms? 🌩️

⚓ The Approach: Staying the Course

Here’s how I’ll navigate this journey:

Step-by-Step Progress: I’ll tackle one test case or feature at a time. Slow and steady wins the race. 🐢
Collaborate: I’ll actively seek feedback from maintainers and peers. After all, even the best captains consult their crew. 👩‍✈️
Stay Organized: With clear goals and weekly check-ins, I’ll ensure my ship doesn’t drift off course. 📅
Embrace Challenges: Bugs, edge cases, and unexpected hurdles? Bring ‘em on! They make the treasure at the end even sweeter. 🪙

🏴‍☠️ Goals for 0.4

💯 Achieve Full Test Coverage: No uncovered lines shall escape!
🚀 Submit a Stellar PR: My work should be clear, concise, and ready to merge.
🌟 Learn and Share: Document my journey, share lessons, and inspire others to contribute.

🚀 My Aha-Moment-Packed Journey to Releasing ReadCraft 🎉

Tasbi Tasbi — Wed, 27 Nov 2024 01:54:37 +0000

What’s up, DEV community? 👋 Have you ever felt like you're about to conquer the world, only to realize you’re stuck battling bugs that don’t make any sense? Yeah, same here. Welcome to my Lab 9 adventure where I took my humble Python script and turned it into a shiny, installable Python package, ReadCraft! Spoiler alert: it wasn’t smooth sailing, but hey, that’s what makes it fun, right?

🌟 The "Wait, I Can Do This?" Realization

Let’s start at the beginning. ReadCraft is a tool that automates creating README.md files using the Groq API. Sounds fancy, right? I thought so too. But when I started preparing it for release on PyPI, it felt less like fancy magic and more like assembling IKEA furniture without the manual.

🛠 The Tool Arsenal

Here’s the toolkit I used to make the magic happen:

PyPI: The destination for my masterpiece.
TestPyPI: The practice stage where all my mistakes went to die.
Twine: My trusty messenger to get packages uploaded.
GitHub Actions: My automation buddy to handle testing and (eventually) releases.

🧑‍💻 The IKEA Assembly of Packaging

The process was like building a LEGO Death Star but with more yelling at my terminal. Here’s the breakdown:

Step 1: "What’s a setup.py?"

setup.py turned out to be the heart of the operation. This magical file describes your project to PyPI. Mine looked like this:

from setuptools import setup, find_packages

setup(
    name="readcraft",
    version="0.1.4",
    description="A command-line tool to generate README.md files using the Groq API.",
    long_description=open("README.md").read(),
    long_description_content_type="text/markdown",
    author="Tasbi Tasbi",
    url="https://github.com/tasbi03/ReadCraft",
    packages=find_packages(),
    install_requires=["requests", "python-dotenv", "toml"],
    entry_points={"console_scripts": ["readcraft=readcraft.readme_generator:main"]},
    classifiers=[
        "Programming Language :: Python :: 3",
        "License :: OSI Approved :: MIT License",
        "Operating System :: OS Independent",
    ],
    python_requires=">=3.7",
)

I spent way too much time wondering if I needed python_requires. (Spoiler: Yes, I did.)

Step 2: Building the Package

This part sounded intimidating, but it wasn’t too bad. Running this command did all the heavy lifting:

python setup.py sdist bdist_wheel

Result? Two shiny new files in the dist/ directory. I felt like a wizard. 🧙‍♂️

Step 3: The Upload That Wasn’t

I confidently ran:

twine upload dist/*

And BAM! 403 Forbidden. I double-checked my PyPI token, reread the error message, Googled it, and finally realized… I forgot to configure .pypirc properly. Rookie move. Fixing it was easy once I knew what I was doing:

[distutils]
index-servers =
    pypi

[pypi]
username = __token__
password = <your_api_token>

🤦‍♀️ Challenges That Made Me Want to Quit

Here are a few memorable roadblocks I hit (and conquered):

"Where’s my .env file?"
My tool needs an API key from .env, but users kept forgetting to create one. Solution? Add a sample.env and update the README to scream, “DON’T FORGET THIS!”
Dependencies Gone Wild:
An old requests package version didn’t play well with Python 3.12. Upgrading dependencies was my first real debugging win.
Tests Failing for No Reason:
Oh, PYTHONPATH. Why do you exist? Adding it to GitHub Actions saved my tests and my sanity:

  env:
    PYTHONPATH: ${{ github.workspace }}

🎉 Aha Moments Worth Celebrating

Here’s the fun stuff I figured out:

GitHub Actions Can Do Magic: Automating my tests and PyPI releases felt like the future. No more manual uploads for me!
Publishing Feels Empowering: When my package finally showed up on PyPI, I might’ve done a little dance. Okay, a big dance.
Code Reviews Help: Testing with a partner uncovered gaps in my instructions. Fixing those felt like leveling up.

🛠 How You Can Use ReadCraft

Want to try it? Here’s how:

Install ReadCraft:

   pip install readcraft

Create a .env file:

   GROQ_API_KEY=your_api_key

Run the tool:

   readcraft path/to/your/file.py --output-dir ./output

🎯 Final Thoughts

Releasing ReadCraft wasn’t just about shipping code; it was about learning, struggling, and growing. If you’re thinking about releasing your own package, DO IT. You’ll make mistakes, but that’s the fun part.

What’s next for me? Probably world domination. Or maybe just more Python packages. Let me know what you think in the comments, and feel free to try ReadCraft for yourself:

pip install readcraft

Happy coding! 🚀

Sailing the TypeScript Seas: My Adventure Adding File Upload Validation to React Chatbotify

Tasbi Tasbi — Sat, 23 Nov 2024 02:00:24 +0000

Ahoy, fellow coders! 🏴‍☠️

Have you ever felt like a pirate setting sail on the vast ocean of code, only to realize you're navigating a storm without a compass? That's exactly how I felt when I embarked on my latest coding adventure: adding file upload validation to the React Chatbotify input-validator plugin.

As someone who can code in JavaScript in my sleep but is still getting acquainted with TypeScript, I knew I was in for a wild ride. But hey, what's life without a little challenge, right?

Grab your favorite beverage (mine's a cup of coffee with a splash of excitement), and join me as I recount my journey through TypeScript, React Chatbotify, and the quirks of file upload validation. Let's dive in! 🌊

Chapter 1: Setting Sail Without a Map 🗺️

The Quest Begins

It all started when I decided to contribute to the React Chatbotify Plugins repository. The issue at hand was straightforward—or so I thought:

Add support for file upload validation (Issue #1)

The plugin currently supports text input validation, but there's a need to validate file uploads as well. "Simple enough," I mused. Little did I know, I was about to enter uncharted waters.

Lost in Documentation
First things first, I needed to understand how React Chatbotify and its plugins work. I dived into the documentation and explored the react-chatbotify GitHub repo.

As someone who hadn't worked with plugins before, I felt like I was reading hieroglyphs. But with patience and copious amounts of caffeine, I began to piece together how everything fit.

Chapter 2: The Mysterious Case of the Missing Plugin 🕵️‍♀️

Writing the Validation Logic
I rolled up my sleeves and started coding the file upload validation logic. I added a new event listener for rcb-user-upload-file in the useRcbPlugin hook:

window.addEventListener("rcb-user-upload-file", handleUserUploadFile);

  return () => {
    window.removeEventListener("rcb-user-upload-file", handleUserUploadFile);
  };

Feeling confident, I fired up the app to test it out. And... nothing happened. The file upload wasn't working at all.

The "Aha!" Moment

After hours of frustration and questioning my life choices, I realized that I hadn't actually called the plugin in my main app. 🤦‍♂️

Here's what I was missing in App.tsx:

import ChatBot, { Flow } from "react-chatbotify";
import RcbPlugin from "./factory/RcbPluginFactory";

const App = () => {
  // Initialize the plugin
  const plugins = [RcbPlugin()];

  // ... rest of the code
};

export default App;

Once I added the plugin to my app, the file upload functionality sprang to life. Lesson learned: Always remember to include your plugins, folks!

Chapter 3: The Validation Conundrum 🧩

Adding File Validation Logic
With the plugin properly invoked, I set out to write the file validation logic. I created a separate function validateFile:

// validateFile.ts

import { ValidationResult } from "../types/ValidationResult";

export const validateFile = (file?: File): ValidationResult => {
  const allowedTypes = ["image/jpeg", "image/png"];
  const maxSizeInBytes = 5 * 1024 * 1024; // 5MB

  if (!file) {
    return {
      success: false,
      promptContent: "No file uploaded.",
      promptDuration: 3000,
      promptType: "error",
    };
  }

I thought I had everything sorted out. But then, another problem reared its head.

Chapter 4: When Validation Goes Rogue 🏴‍☠️

The Unexpected Behavior
Upon testing, I noticed that the text input validation wasn't working properly. When I typed in text, it was being blocked by the file upload validator. Wait, what?

This wasn't supposed to happen. The validateFileInput should only apply to file uploads, not text inputs.

Seeking Guidance
Stumped, I reached out to the plugin owner and showed them a screen recording of the issue. They pointed out that the validators were overlapping and suggested that the validateTextInput and validateFileInput should be independent of each other.

They also recommended adding a chatDisabled property to control when text input should be disabled.

Chapter 5: Righting the Ship ⚓

Separating the Validators
I made changes to ensure that each validator only handled its respective input type.

Updated InputValidatorBlock Interface:

// InputValidatorBlock.ts

export interface InputValidatorBlock extends FlowBlock {
  validateTextInput?: ValidatorFunction<string>;
  validateFileInput?: ValidatorFunction<File>;
  // ... rest of the properties
}

Testing Again

With these changes, I ran the app once more. Success! 🎉

Text inputs were validated using validateTextInput.
File uploads were validated using validateFileInput.
Users could provide a URL or upload a file, offering flexibility.

Challenges Post-PR

Once my pull request was submitted, it underwent a rigorous review process. Several changes were requested by the plugin owner, which was both educational and, at times, exhausting. Here are some of the significant updates I made based on the feedback:

Emotional Rollercoaster

Each round of feedback was a mix of "aha moments" and "why didn't I think of that?" While the process was tiring, it pushed me to improve the quality of my work. Ultimately, the back-and-forth discussions helped me gain a deeper understanding of the plugin's architecture.

Chapter 6: Key Takeaways 📝

What I Learned

The Value of Reviews: Code reviews are not just about pointing out mistakes—they're about collaboration and improvement. I came out of this process with a sharper eye for detail.
Patience Pays Off: Open-source contributions can be challenging, especially when you're new to the technology stack. Taking time to absorb feedback and iterate on your work is essential.
Typescript Confidence: This project significantly boosted my confidence in TypeScript. Understanding interfaces, custom types, and type-safe validation was a steep but rewarding learning curve.

Chapter 7: Challenges Faced 🏔️

TypeScript Trials

Being new to TypeScript, I found myself wrestling with type definitions and interfaces. Understanding how to define and use custom types like ValidationResult and ValidatorFunction was a steep learning curve.

Event Handling Headaches

Handling custom events like rcb-user-upload-file required a deep dive into the event system of React Chatbotify. Ensuring that event listeners were added and removed correctly was crucial to prevent memory leaks and unexpected behavior.

Fatigue from Iterations

The repeated back-and-forth for changes in my pull request was draining. While it improved the quality of my work, it also tested my perseverance.

Chapter 8: Wrapping Up 🛳️

Contributing to the React Chatbotify plugin was a rewarding experience. Despite the challenges, I walked away with valuable skills and a deeper appreciation for open-source development.

You can explore the pull request here and view the full commit history. I hope this story inspires others to dive into open source, even if the waters seem intimidating at first.

Final Thoughts 💭

Thanks for joining me on this journey! I hope my experiences can help others who might be navigating similar waters. If you have any questions or want to share your own coding adventures, feel free to leave a comment below.

Happy coding! 🚀

Navigating the CI Seas: A Tale of Mocking Files and Testing Stranger Code

Tasbi Tasbi — Sat, 16 Nov 2024 06:36:51 +0000

Ahoy, fellow developers! 🌊 Ever tried to sail the uncharted waters of someone else's codebase? Well, grab your compasses and let me regale you with my latest adventure in setting up Continuous Integration (CI) and writing tests for a project that wasn't mine. Spoiler alert: it involved a lot of mocking—both the technical kind and, well, the other kind too!

Setting Sail with GitHub Actions CI Workflow

First things first, I needed to set up a CI workflow for my own repository. I wanted to automate the testing process so that every push would run my tests and ensure everything was shipshape.

Here's what my .github/workflows/ci.yml looked like:

name: CI

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

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.x'
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run tests
      run: |
        python -m unittest discover

Pretty standard stuff, right? This workflow checks out the code, sets up Python, installs dependencies, and runs the tests. Simple, yet effective—like a trusty compass.

Boarding the Ship: Writing Tests for a Stranger's Repo

Now, here's where the real adventure began. I was tasked with writing tests for HTSagara's readme_genie repository. Imagine being handed a treasure map in a language you only partially understand. Challenge accepted!

The Quest for Meaningful Tests

I decided to focus on the read_file_content function, which, as the name suggests, reads file content. I thought, "What could possibly go wrong with reading files?" Turns out, plenty—if you're testing!

I wrote tests to handle various scenarios:

Empty Files
Files with Only Comments
Large Files

Here's a peek at one of the tests:

@patch("builtins.open", new_callable=mock_open, read_data="")
def test_read_file_content_empty_file(self, mock_file):
    """Test read_file_content with an empty file."""
    file_content = read_file_content(["empty_file.py"])
    self.assertEqual(file_content, "\n\n")

Mocking Files Like a Pro

Since I didn't want to actually create files, I used unittest.mock to simulate file operations. This was my first time heavily relying on mocking, and it felt like I was crafting illusions—like a code wizard!

Writing tests for someone else's codebase was like deciphering a coded message. I had to understand the function's intent, its edge cases, and how it handled unexpected input. It was both challenging and exhilarating.

Comparing Ships: My Repo vs. My Partner's

In my own repo, I had a cozy setup with straightforward tests. In contrast, HTSagara's repo was a grand vessel with intricate details. Their testing setup was minimal, so I had the freedom (and responsibility) to expand it.

The main differences were:

Test Coverage: My repo had tests covering most functions, while theirs had room for more.
Complexity: Their functions handled more edge cases, requiring more thoughtful tests.
CI Integration: Both of us used GitHub Actions, but the workflows had slight variations.

The Treasure of Continuous Integration

After setting up CI, I must say—I'm hooked! Having automated tests run on every push is like having a vigilant lookout who never sleeps. It catches issues early, ensures code quality, and gives peace of mind.

CI has transformed from a mysterious acronym to an indispensable tool in my development arsenal. It's like upgrading from a rowboat to a schooner.

Optional Challenges: Tackling the Behemoth

One of the optional challenges was to test the function's performance with a large file. I simulated a file with 1000 lines to see how the function held up:

@patch("builtins.open", new_callable=mock_open, read_data="line\n" * 10**6)
def test_read_file_content_large_file(self, mock_file):
    """Test read_file_content with a large file."""
    start_time = time.time()
    file_content = read_file_content(["large_file.py"])
    end_time = time.time()
    elapsed_time = end_time - start_time

    expected_content = ("line\n" * 10**6) + "\n\n"
    self.assertEqual(file_content, expected_content)
    self.assertLess(elapsed_time, 2, "Processing large files took too long!")

This test not only checked if the function could handle large files but also if it did so efficiently. I'm happy to report that it passed with flying colors!

Lessons Learned and Final Thoughts

Writing Tests for Others: It's a fantastic way to deepen your understanding of testing and code structure.
Mocking is Powerful: unittest.mock is now a close friend. It opens up possibilities for testing without relying on actual I/O operations.
CI is Essential: Automating tests saves time and reduces errors. It's like having a trusty first mate.

Overall, this lab was a thrilling voyage through the seas of CI and testing. I encourage everyone to venture beyond their comfort zones—who knows what treasures you'll find?

Fair winds and following seas! 🌬️🚢

Feel free to share your own adventures or ask questions in the comments below. Happy coding!

Testing ReadCraft: The Epic Adventure of Bugs, Mocks, and Merge Mishaps 🚀🐛🔍

Tasbi Tasbi — Sat, 09 Nov 2024 05:41:27 +0000

When I first set out to add automated testing to my ReadCraft project on GitHub, I thought it would be a simple exercise. Just throw in a few test cases, check that everything works, and call it a day, right? 🤔 Little did I know that testing would take me through a winding journey of commit errors, merge conflicts, and some pretty cool discoveries along the way. Here’s the whole story – the good, the bad, and the buggy!

🎯 Picking the Right Testing Tools: Pytest and Mocking Magic

To start, I needed to decide on a testing framework. Enter Pytest! Known for its ease of use, it’s perfect for both beginners and seasoned developers. I also included pytest-mock to help me simulate responses from the LLM (Large Language Model). Since ReadCraft relies on these responses, I needed a way to create predictable test cases without actually pinging the LLM every time.

Why Pytest? 🤷 It’s lightweight, flexible, and integrates well with GitHub Codespaces, where ReadCraft lives. Plus, Pytest’s descriptive output makes debugging a lot easier – a feature that would come in handy more times than I expected!

🛠 The Setup: Making Tests Seamless in Codespaces

My first task was to ensure every developer (including future me) could run these tests without any additional setup. That meant adding Pytest and pytest-mock to requirements.txt and creating a pytest.ini file to keep settings like verbosity and warnings under control. This setup ensures that anyone opening ReadCraft in a new Codespace can simply run pytest and have everything work out of the box. 🎉

Step-by-Step for Setting Up Pytest:

Added pytest and pytest-mock to requirements.txt.
Committed and pushed the setup so it would initialize automatically in GitHub Codespaces.

With these steps done, I was ready to start writing tests – or so I thought.

🐙 Challenge #1: The Great Merge Conflict Saga

One day, as I was diligently working on test cases, I ran into a Git dilemma: my local branch and origin/main had diverged. I had five commits that origin/main didn’t, and origin/main had six that I didn’t. Trying to pull in changes only threw errors at me, and I ended up tangled in a merge conflict jungle. Every time I thought I’d resolved the conflicts, Git had more surprises for me. 😅

In a moment of pure frustration and humor, I made the infamous commit:
“added my own mess ups” 6c2c7ca 🙈. This was the ultimate “Oops, I did it again” commit, acknowledging my messy merge attempts.

Lessons Learned:

Commit thoughtfully 📝: I learned the hard way that random commits can lead to chaos if you’re not careful with merging.
Staying calm with conflicts 😌: Working through conflicts became a mini-lesson in version control. I made a mental note to double-check branches in the future!

After what felt like a showdown with Git itself, I resolved the conflicts and moved on.

🕹 Mocking LLM Responses: How I Kept My Sanity

Since ReadCraft relies on responses from a large language model, I couldn’t afford to make real API calls in every test. That’s where pytest-mock came to the rescue. I used it to simulate responses from the LLM, ensuring consistent outputs in my tests. By mocking these responses, I was able to check how ReadCraft handled everything from a perfectly formatted response to an empty one.

Setting up mocks was a game-changer. It allowed me to focus on ReadCraft’s functionality rather than the unpredictability of external API responses.

🧩 Writing the Tests: The "Aha!" Moments

As I wrote tests for each function, I started seeing ReadCraft through a new lens. Testing isn’t just about validation; it’s about defining what each function should do under every circumstance. It led to some pretty satisfying “aha!” moments, like realizing that a function could break if the LLM returned a null response.

Challenges Faced:

Unintended Errors: Testing revealed a few hidden bugs, like formatting issues and the occasional crash when dealing with unexpected data from the LLM.
Edge Cases Galore: I uncovered scenarios where ReadCraft didn’t handle empty or malformed responses well, leading to crashes. These insights pushed me to add extra error handling.

🔥 The Joys of Bug-Hunting

One of my favorite discoveries was an edge case where ReadCraft threw an error if the LLM responded with an empty string. Without testing, I’d never have found this, and it helped me make ReadCraft more robust. With every bug I caught, I felt the project becoming stronger and more reliable. 💪🐞

🎉 Final Thoughts: Reflections on Testing

This whole process taught me more than I expected. Testing isn’t just a chore – it’s an exploration of your project’s strengths and weaknesses. Before this, I hadn’t fully appreciated the role of testing in making code resilient, but now I’m a convert. Going forward, I’ll absolutely be adding automated testing to my projects from day one.

So, if you’re considering adding tests to your project, I say go for it. Dive in with Pytest, learn the ropes of mocking, and don’t be afraid to make mistakes. Each misstep (even those dreaded merge conflicts) is just part of the journey, and in the end, your project will be better for it – and so will you.

Happy testing! 🚀🌟

📜 Mastering Code Quality in ReadCraft: Formatting, Linting, and Automation Adventure 🚀

Tasbi Tasbi — Sun, 03 Nov 2024 05:14:47 +0000

Setting up code quality tools in a project can seem intimidating at first, but I took on the challenge with ReadCraft and had an awesome experience! In this post, I’ll walk you through the tools I picked, the setup process, and the surprising discoveries along the way. I’ll also share the challenges I faced, including a tricky token usage fix, and how I tackled them. Let’s dive in! 🌊

🛠 Tools of the Trade: Why Black and Flake8?

To maintain clean, readable code, I chose two Python tools that make life a lot easier:

Black: Black is a “no-nonsense” code formatter. It decides on a code style and enforces it every time you run it, so you don’t need to worry about formatting. It’s fast, opinionated, and gives you back time that would have gone into tedious formatting debates.
Flake8: Flake8 is a linter that spots issues and potential bugs in Python code. Think of it as a super-smart friend who catches mistakes before they become headaches. Flake8 goes through the code, highlights errors, and keeps everything consistent. 🎩

These tools keep code quality high and avoid cluttering up my code with mistakes or inconsistencies. Want to add these to your project? Here’s how I set them up!

🔧 The Setup Process: Making Magic Happen ✨

Here’s the step-by-step guide to setting up Black and Flake8 for ReadCraft (or any Python project):

Step 1: Configuring Black

Configuration File: I created a pyproject.toml file to store Black’s settings. This config file specifies the line length, which Black enforces to keep code easily readable.
Ignore Unwanted Files: I added a .blackignore file to exclude directories like venv/ and output folders. This way, Black only formats the relevant files and skips unnecessary ones.

Step 2: Setting Up Flake8

Configuration File: I added a .flake8 file to set up the linter. This config file tells Flake8 which issues to ignore, sets a max line length, and specifies folders to exclude (e.g., .git and virtual environments).
Running the Linter: Running flake8 . in the terminal checks all Python files in the current directory, identifying errors and stylistic inconsistencies.

Fixing the Token Usage Issue

While setting up the code, I ran into an interesting problem: I was trying to check token usage directly from the API, but I wasn’t handling it correctly in my code. With some guidance (shoutout to the help I received!), I updated the code to ensure that token usage was only calculated once and displayed correctly.

Making it Easy with a Script

To simplify running both tools, I created a shell script format.sh:

#!/bin/bash
# Run Black only on the main project files
black readme_generator.py 

# Run Flake8 for linting
flake8 .

Now, with a single ./format.sh command, Black and Flake8 will work their magic on the key project files, keeping everything formatted and linted.

🔎 What Did I Find? The Surprising Results! 🤯

After running Black and Flake8, I was impressed—and a little surprised. Here’s what each tool found:

Black made my code look sleek and consistent. It fixed indentation issues and adjusted line lengths, making everything cleaner and more readable.
Flake8 flagged a variety of issues: unused imports, variables assigned but not used, and some style inconsistencies. These are easy to overlook but can create confusion or bugs over time. Fixing these made the code more reliable and professional.

🎨 Integrating Tools with VSCode: Making It Seamless

To make sure formatting and linting happen automatically, I set up Visual Studio Code (VSCode) to handle it as I work.

Setting It Up in VSCode:

Open Project: Open the project in **VSCode or GitHub Codespaces.
Install Extensions: If prompted, I installed the **Python, **Black Formatter, and **Flake8 Linter extensions.
Auto-Format on Save: Black now formats my code every time I save a file.
Real-Time Linting: Flake8 catches issues as I type, which keeps errors from piling up.

Thanks to .vscode configuration files, any contributor who opens the project in VSCode has the same setup, which keeps everything consistent and easy to manage.

🛠 Automating with a Git Pre-Commit Hook

To make sure nothing slips through the cracks, I added a Git pre-commit hook. This hook automatically runs Black and Flake8 on any files that are about to be committed, ensuring all code is clean and properly formatted before it enters the main branch.

Here’s How I Set Up the Hook:

Create the Hook File: In .git/hooks/pre-commit, I added the following script:

   #!/bin/bash
   black .
   flake8 .

Make It Executable:

   chmod +x .git/hooks/pre-commit

With this in place, every time I commit, the hook checks for issues and prevents the commit if it finds any problems. No more accidental formatting errors in the main branch!

💥 Challenges Along the Way

Setting everything up wasn’t entirely smooth sailing! Here are some of the challenges I ran into and how I solved them:

Ignoring Specific Files: Initially, Black formatted files in my virtual environment and output folders, which I didn’t want. Adding a .blackignore file solved this.
Configuring Linter Rules: Flake8 was a bit strict out of the box, flagging a lot of minor issues. I customized the rules in .flake8 to ignore warnings that weren’t relevant to the project.
Token Usage: I learned that tracking token usage required careful handling in the code, which I updated after receiving help, ensuring the usage was displayed correctly.

📚 Lessons Learned

Working through this setup was a great learning experience, and I took away some key insights:

Automating Quality Checks: Tools like Black and Flake8 are invaluable for ensuring code quality, but automating them with hooks and editor integration takes it to the next level.
Consistency Is Key: With Black, my code style is consistent across files and contributors. This saves time on code reviews and keeps everything readable.
Catch Issues Early: Flake8 flags potential problems as I code, which helps avoid bigger issues down the road.

Final Thoughts

Setting up tools like Black and Flake8 in ReadCraft has made development more enjoyable and less error-prone. If you’re looking to boost code quality in your project, I highly recommend giving these tools a try. Here’s the commit with the full setup.

Happy coding! 🎉

My Hacktoberfest 2024 Journey: A Month of Code, Growth, and Unforgettable Lessons 🚀

Tasbi Tasbi — Fri, 01 Nov 2024 22:02:12 +0000

October was a rollercoaster of coding, learning, and (let's be real) the occasional struggle. Hacktoberfest 2024 gave me the perfect chance to jump back into open source, armed with a little more resilience and a lot more experience than last year. Here’s the full recap of my month-long adventure: the issues I tackled, the PRs I (mostly) got accepted, and the invaluable lessons I picked up along the way.

First Stop: Security Questions for freeCodeCamp’s Developer Quiz Site 🔐

Let’s kick things off with a bit of a confession—my first pull request on the Developer Quiz Site? Closed. That’s right; midterms got the best of me, and I couldn’t follow through. When I returned to see it had been closed, I felt a pang of regret, but it only made me more determined to succeed this time around.

Fast-forward to Hacktoberfest 2024, and I came back to freeCodeCamp’s repository, ready to add new security questions on topics like SQL Injection and CSRF. This PR taught me a lot about attention to detail (no duplicates allowed!) and perseverance, especially when I had to work through merge conflicts with recent updates. Lesson learned: balancing life and code is tricky, but I’m here to stick with it.

Adding Unit Tests to React Chatbotify: A Journey Through Jest 🧪

Next up was react-chatbotify, where I took on the challenge of adding unit tests for the ChatBotButton component. Testing was new to me, and Jest became both a friend and a formidable challenge. I dug into the tests for the AudioButton as my guide and wrote tests for rendering, CSS classes, and visibility toggling with React Testing Library.

This experience showed me the importance of thorough testing and the satisfaction that comes when your code is confidently covered. Oh, and the PR was approved on the first try—win! 🎉

Sprucing Up Terminal Cricket with CLI Flair 🏏️

The third project took me into the world of command-line interfaces with terminal-cricket. My mission? Add a bit of flair to the CLI with animations, loading screens, and structured displays. I added quit functionality and animations to make gameplay more engaging—because who doesn’t want a bit of visual fun in a cricket game?

This was my chance to dive into ASCII art, experiment with terminal boundaries, and create a more polished, interactive experience for users. Seeing my changes come to life on the screen was incredibly rewarding.

Predicting the Weather with Python and OpenWeatherMap ☁️

For 100LinesOfPythonCode, I created a mini weather app that fetches current weather details using the OpenWeatherMap API. Working on this project taught me the magic of combining Python with APIs, and with a little help from the rich library, I added some nice terminal styling for better readability.

This pull request was a straightforward but fulfilling contribution. It was exciting to deliver a functional, visually enhanced tool that users can enjoy right from their terminal.

The Long Road with TranspilerX: Floating Action Buttons and Endless Tweaks 😅

Ah, TranspilerX. The project that tested my patience and persistence! My task was to implement a Floating Action Button (FAB) for mobile-friendly actions like clearing the code editor and toggling the theme. It sounded simple, but this one went through multiple iterations.

The repo owner requested changes, and I submitted updates through PRs 5.1, 5.2, and 5.3, polishing the FAB’s placement, look, and behavior. The owner has been quiet lately, so these PRs are still awaiting review. But hey, even in its unfinished state, I learned a ton about Material UI and responsive design. Here’s hoping for a green light soon!

Reflections: From Closed PRs to Growing Confidence

Looking back, Hacktoberfest 2024 pushed me in every way possible. I learned a lot about balancing real-life commitments with coding goals. That closed PR? It taught me resilience. The unit tests? They gave me a new appreciation for code reliability. And the FAB in TranspilerX? Well, it taught me that every feature, no matter how simple it seems, deserves attention to detail.

This month gave me confidence and confirmed that I’m on the right path. I’ve grown as a coder, problem-solver, and collaborator. Each project pushed my limits, and the feedback I received was instrumental in shaping my skills. Hacktoberfest has been an unforgettable journey—one that I know will fuel my passion for coding for years to come

🌟 See All My Contributions 📂

Want to check out my issues, pull requests, and blogs? Here’s everything I contributed this Hacktoberfest!

Tasbi03 - Tasbi Tasbi

🐛 Issues

Issue-1 - freeCodeCamp Developer Quiz Site
Issue-2 - React Chatbotify
Issue-3 - Terminal Cricket
Issue-4 - 100LinesOfPythonCode
Issue-5 - TranspilerX

🚀 Pull Requests

Pull Request-1 - freeCodeCamp Developer Quiz Site
Pull Request-2 - React Chatbotify
Pull Request-3 - Terminal Cricket
Pull Request-4 - 100LinesOfPythonCode
Pull Request-5.1 - TranspilerX
Pull Request-5.2 - TranspilerX
Pull Request-5.3 - TranspilerX

✍️ Blog Posts

Blog Post-1 - My Hacktoberfest Adventure: Contributing to freeCodeCamp's Developer Quiz Site
Blog Post-2 - My Second Hacktoberfest Adventure: Testing with Jest for the First Time
Blog Post-3 - My Hacktoberfest Journey: Redeeming Myself and Waiting for the Green Light
Blog Post-4 - Hacktoberfest Adventure: Adding Weather Magic to 100LinesOfPythonCode
Blog Post-5 - My Hacktoberfest Adventure: Wrestling with JavaScript and the Elusive Green Light

Hacktoberfest 2024 may be over, but this experience will stay with me as a reminder of how much you can accomplish when you embrace the journey. Here’s to more open-source adventures ahead! 🎉

My Hacktoberfest Adventure: Wrestling with JavaScript and the Elusive Green Light 🚥

Tasbi Tasbi — Sat, 26 Oct 2024 04:59:39 +0000

After three successful pull requests, I thought I had the hang of this whole Hacktoberfest thing. Find a repo, make changes, open a PR, and bask in the glow of contributions. Easy, right? Well, my fourth pull request decided to teach me a lesson in patience and perseverance. And it came with an unexpected twist: JavaScript. 🤯

The journey began when I found issue #19 on the TranspilerX repository. The task seemed straightforward: add a clear button to a code editor and create a mobile-friendly action button with multiple options. "How hard could it be?" I thought. Spoiler alert: way harder than I expected. 😅

Diving into the Code 🧩

First, I had to understand the existing code—which felt like stepping into a giant maze filled with traps labeled "JavaScript Errors." I spent hours trying to figure out how everything fit together. There were React components, a bunch of unfamiliar libraries, and a sea of state variables. The first time I saw the useEffect hook, I genuinely thought my brain might explode. 💥 But after some trial and error (mostly error), I started to get it.

This was my first time working with JavaScript in this capacity as before in my second hactoberfest PR I did testing using jest which was harder, using javascript is not harder but looking at code of lines of 500 in each file is way more harder, and honestly, it was like trying to cook a gourmet meal without knowing how to turn on the stove. Every time I tried to add something, BOOM – another error. A missing import here, an undefined function there, or my personal favorite: "unexpected token." 😩 It took a lot of Stack Overflow, Googling, and coffee to get through it. ☕

Finally Making It Work 🎉

After what felt like ages wrestling with the code, I finally got the functionality working. I added a clear button that sits perfectly between the language selector and the copy button on the web view. I even managed to add a SpeedDial button for the mobile view that pops open with the actions you need—clear the code, copy it, and switch the theme. The satisfaction I felt when it actually worked was unreal. I did a little victory dance, and yes, it was terrible. 💃🕺

I was ready to ride the wave of success. I opened PR #50, expecting the next part to be smooth sailing. But oh no—Vercel had other plans. Since the repo is under someone else’s account, my deployment needs to be authorized before it goes live. So now I’m waiting for a reply from the project maintainer, hoping they approve it and give me that sweet, sweet green check mark. ✅

The Hacktoberfest Struggle 🤹‍♀️

If you've ever done Hacktoberfest, you know that finding good repos can be like finding a needle in a haystack. I wanted projects that were challenging but also interesting—ones that pushed me to learn. But that’s a tough balance! I looked through countless issues, often finding ones that were either too simple or way beyond my skill level. It’s a weird feeling, right? You're either a coding wizard or a clueless muggle, sometimes both within the span of five minutes. 🧙‍♂️🤦‍♀️

This pull request was definitely my most challenging so far and you may thing that I just added 40 lines into my code and I am making so much fuss about it but remember when working on some else code is really difficult, it may look like a small thing to add but understanding what you are doing and getting accepted what you have done is most important. Hacktoberfest isn't just about getting t-shirts or badges; it’s about learning, growing, and figuring out how to solve problems. Sometimes, the most rewarding part isn’t the green check mark on your PR—it’s the journey that gets you there (though I’d still very much like that green check mark, please). 😜

Waiting for the Green Light 🚦

So here I am, four pull requests in, with three accepted and one pending review. I’m learning the art of waiting (and how to spell "origin" correctly—long story, don’t ask). This experience has shown me that open source contributions aren’t always instant gratification. Sometimes you have to be patient, persistent, and enjoy the process—even if it involves a lot of debugging and talking to your computer like it’s a person. 🤖💬

If you’re also on your Hacktoberfest journey, just know that every mistake is a step forward, and every success is a celebration—no matter how small. I hope my next post is about that beautiful green light on my PR, but until then, I’ll keep exploring, learning, and adding value, one error message at a time. 🚀

Check out my first Hacktoberfest story here: My Hacktoberfest Journey - Redeeming Myself and Waiting for the Green Light. And wish me luck for my fourth pull request getting accepted! 🍀

Happy coding! 💻

Hacktoberfest Adventure: Adding Weather Magic to 100LinesOfPythonCode 🌦️✨

Tasbi Tasbi — Wed, 23 Oct 2024 23:26:01 +0000

Hey everyone! 👋

I just wrapped up my fourth Pull Request for Hacktoberfest 2024, and it’s been such a rewarding experience. This time, I tackled an issue in the 100LinesOfPythonCode repo, where I added a Weather App that pulls in today’s forecast using the OpenWeatherMap API. Let me take you through my journey of coding, challenges, and fun.

🌤️ The Weather App PR

The goal was pretty straightforward: create a Python app that fetches weather information using an API. This is now live in the pull request #18. It’s not just your regular weather app, though! I spiced things up by using the rich library to make the terminal output look fabulous—complete with colored tables and loading animations. After all, why settle for boring text when you can make it beautiful, right? 😉

This PR adds the ability to get today’s forecast by simply entering the city name. I also made sure the data gets saved to a local JSON file so you can revisit it later. It’s a fun little project that really showcases how much visual polish matters, even in CLI apps.

🌀 The "Challenges" (A.K.A. The Hard Parts)

This project wasn't without its tricky moments. One of the hardest parts was handling asynchronous API data fetching while maintaining a clean and user-friendly terminal output. Managing the response timing with the loading animation needed careful tweaking, especially to avoid unnecessary delays while still making the user feel like the data-fetching process was smooth. Getting the balance between user engagement and efficiency was a real challenge.

Lastly, keeping my fork up-to-date was tricky because the owner kept making changes to the main branch. I had to frequently merge upstream changes into my working branch to avoid conflicts. This was a great learning experience in managing merge conflicts and maintaining a clean history, but it certainly added some complexity!

🚦 PR Waiting Game: My Third Hacktoberfest PR

My third Hacktoberfest PR was a bit of a waiting game. I was working on the Terminal Cricket Game, where I added core features and improved the terminal experience. The owner asked me to make changes in the root directory, and since then, I've been waiting for a response. It's part of the Hacktoberfest adventure—the thrill of coding, submitting, and waiting for that sweet, sweet "merged" notification. 🚀

🌈 Lessons Learned

Presentation Matters: It’s not just about the data; it’s about how you present it. The rich library really helped me take this weather app from "meh" to "wow!".
Keep Your Fork Updated: The owner made some changes while I was working on my fork, so I had to frequently pull from the upstream to stay synced. It’s a good habit to learn when contributing to open source.
Persistence is Key: Waiting for a PR to be reviewed can feel like forever, but staying engaged and being patient is all part of the experience.

🚀 What’s Next?

I’ve got a few more PRs to go for Hacktoberfest, and I’m looking for even more exciting issues to tackle. If you have any suggestions or projects, drop them in the comments below! I’m loving this journey so far, and can’t wait to see what else I can contribute to.

Until next time, stay curious and keep coding! 🌟

Check out my Weather App PR here

Follow my Hacktoberfest journey on DEV