DEV Community: Elisaassa

Final Update - Failed to Release

Elisaassa — Thu, 12 Dec 2024 03:47:17 +0000

Despite my best efforts, I wasn’t able to complete the migration from Bootstrap 3 to Bootstrap 5. Here’s what went wrong and what I learned from the process.

The Gap Between Bootstrap 3 and Bootstrap 5

The differences between Bootstrap 3 and Bootstrap 5 turned out to be much larger than I initially anticipated. It wasn’t just about adding new features; the way components are structured and used has changed significantly. Adapting to the new grid system and rewriting JavaScript components required careful attention to detail, making the migration process far more complex than expected.

Layout Issues

One of the biggest challenges was the layout. Even after updating all the grid classes and testing responsiveness, the layout in Bootstrap 5 didn’t align perfectly with the original one in Bootstrap 3. There were subtle differences in spacing, alignment, and overall design that proved difficult to resolve. Fixing these issues would have required more time and resources than I had available.

Too Many Details to Modify

There were countless details that needed to be addressed, including:

Updating custom scripts that relied on jQuery.
Adjusting styles for deprecated CSS classes.
Testing and debugging every component to ensure functionality and visual consistency.

Each of these tasks was time-consuming on its own, but together, they became overwhelming and made it impossible to finish the migration within the planned timeline.

Bootstrap 3 to 5

Elisaassa — Thu, 12 Dec 2024 03:36:53 +0000

Why Updating From Bootstrap 3 to 5 is a Bigger Challenge Than Expected

When I first lokking this issue ifound it's mignt be easy . However, when I started updating a project from Bootstrap 3 to Bootstrap 5, I quickly discovered that the process wasn’t as straightforward as I’d hoped. Here’s a breakdown of the challenges I faced and how I tackled them during this journey.

Challenges I Encountered

1. Structural Overhaul

One of the first hurdles I faced was adapting to Bootstrap 5’s new grid system. The .col-md-* classes from Bootstrap 3 have been replaced with a more flexible .col-* system. While this is great for modern responsiveness, it meant I had to go through the entire project and replace these classes manually. Beyond just swapping the classes, I had to test and tweak layouts to make sure everything worked smoothly across different screen sizes. It was a time-consuming but necessary step.

2. Moving Away from jQuery

Bootstrap 3 relied heavily on jQuery for its JavaScript components, but Bootstrap 5 has completely removed this dependency in favor of vanilla JavaScript. While this is a step forward for performance and simplicity, it caused some serious headaches:

I had to rewrite custom scripts that were tied to jQuery. This included rethinking how event handlers like $(element).on(...) worked and replacing them with addEventListener.
Many third-party plugins that the project relied on were built for jQuery, so I had to either find alternatives or write custom solutions to replace them.

This process took a lot longer than I expected because of how deeply jQuery was embedded into the project.

3. Styling Discrepancies

Some CSS classes and utilities from Bootstrap 3 are no longer available in Bootstrap 5. For example, certain badge and button classes that were central to the project’s design had to be replaced or recreated with custom CSS. These small adjustments added up, and it took careful work to maintain the project’s original look and feel.

While the migration hasn’t been easy, it’s been an eye-opening experience. Modernizing the project with Bootstrap 5 has helped me understand the importance of staying current with technology and has pushed me to improve my skills with vanilla JavaScript and responsive design.

Facing Overwhelm and Overcoming Procrastination in Release 0.3

Elisaassa — Mon, 09 Dec 2024 01:28:59 +0000

Discovering an Interesting Project

As I was exploring different repositories for Release 0.3, I came across Puter, an open-source internet operating system. The more I read about it, the more fascinating it seemed. Puter is designed to be fast, extensible, and versatile—it can serve as a personal cloud, a platform for building web apps, or even a remote desktop environment. Its wide range of use cases and potential for impact really caught my attention. I realized this was a project I wanted to contribute to.

Finding My Place in the Project

At first, I wasn’t sure where I could make a meaningful contribution. The codebase was large and complex, and I wasn’t confident about diving into technical issues. But as I spent more time understanding the project, I discovered something I could work on: completing missing Traditional Chinese translations. This task stood out to me because it aligned perfectly with my strengths—I’m fluent in Chinese and could ensure the translations were accurate and culturally appropriate.

The task wasn’t complex or flashy, but it was important. Adding translations would make the project more accessible to Chinese-speaking users. I realized this was my chance to help in a meaningful way.

Recognizing the Need to Grow

This experience made me reflect. I need to improve my technical skills and build confidence with complex codebases. Small tasks like translations are a good start, but I want to do more. I want to be ready for bigger challenges in the future.

OSD Lab9

Elisaassa — Sat, 23 Nov 2024 04:12:34 +0000

For Lab 9, I focused on packaging and releasing the Code-Formatter-Advisor project on PyPI, making it accessible for easy installation by others.

Choosing the Release Tool and Package Registry

For this project, I chose Python's standard package manager, PyPI (Python Package Index), as the release tool. PyPI is widely used for distributing Python packages and is accessible to most Python developers. You can find the release at Code-Formatter-Advisor on PyPI.

Creating the Release

The process of creating the release involved a few key steps:

Preparing setup.py: I created a setup.py file to include metadata like the package name, version, author, and dependencies. This setup file is crucial as it tells PyPI how to build and install the package.
Generating Distribution Files: Using the command python setup.py sdist bdist_wheel, I generated both source and wheel distribution files. These files were stored in the dist/ directory, ready for uploading.
Uploading to PyPI: I used Twine to upload the package to PyPI: twine upload dist/*. During this step, I needed to use my PyPI credentials, including an API token. After uploading, my package was live on PyPI.

Lessons Learned

While working on this release, I learned the importance of configuring setup.py accurately, especially with correct dependency management. I encountered a few issues with encoding in the README.md file, but I resolved them by specifying the encoding in the setup.py.

An "aha!" moment for me was understanding how git tags work alongside releases. Tagging releases (git tag -a v1.0.0 -m "Initial release") helped me track versions effectively.

Alterations Made for the Release

I had to create and modify the setup.py to add package details and define dependencies. This included adding all necessary libraries and ensuring the README.md provided proper instructions for installing and using the package.

User Testing Feedback

For user testing, I asked a fellow developer to try installing my package from PyPI and follow the README instructions. They had minor issues understanding the virtual environment setup step, which I have clarified in the README. This experience highlighted the importance of clear and precise instructions for users who may not have the same technical background.

Using Code-Formatter-Advisor via PyPI

Users can now install Code-Formatter-Advisor directly from PyPI by running:

pip install code-formatter-advisor

After installation, the command-line tool can be used as described in the updated README to analyze code and get formatting suggestions.

Code-Formatter-Advisor on PyPI provides an easy entry point for developers to leverage this tool in their projects.

Building Robust Projects with GitHub Actions and Collaborative Testing

Elisaassa — Fri, 15 Nov 2024 22:27:16 +0000

In my recent development journey, I focused on adding Continuous Integration (CI) and enhancing test coverage using GitHub Actions. Here's a brief overview of my experience.

Setting Up GitHub Actions CI Workflow

I set up a GitHub Actions CI workflow to run tests with every push and pull request to the main branch. This involved creating a YAML configuration to automate the setup:

Triggers: The workflow runs on every push and pull request to the main branch.
Environment Setup: Uses Ubuntu, installs Python 3.10, along with Flake8 for linting and Pytest for testing.
Linting and Testing: Linting checks code style, while Pytest validates functionality.

Collaborating on a Partner's Repository

I also added tests to a partner's repository, which used a different framework. Adapting to someone else’s code structure highlighted the importance of well-documented contribution guidelines.

My Thoughts on CI

Implementing CI made me realize it's a crucial tool in modern software development. It automates testing, reducing the risk of human error and ensuring code quality. Now, I feel more confident about the reliability of any changes pushed to the main branch.

Optional Challenges: Adding More Tests and Static Analysis

Adding more tests to my partner's project and integrating a linter into the CI helped maintain a cleaner codebase by catching issues early.

Key Takeaways

CI is Essential: It ensures code quality and reliability.
Clear Contribution Guidelines Matter: They make it easier for others to contribute.
Collaborative Testing: Writing tests for a new project improved my adaptability and understanding of new codebases.

🧪 Testing Framework for Code-Formatter-Advisor

Elisaassa — Sat, 09 Nov 2024 03:42:58 +0000

🎯 Overview

In this blog, I’ll share my experience setting up automated testing for the Code-Formatter-Advisor project. I’ll cover the tools I used, how I set up the environment, handled mock responses, and what I learned along the way.

🔧 Chosen Tools

I used pytest as my testing framework, along with Python’s unittest.mock module to create mock responses for my LLM API. Here’s why:

pytest: It’s simple, yet powerful for writing concise test cases. Learn more about pytest here.
unittest.mock: Ideal for mocking API responses without hitting the live API during tests. Check out unittest.mock documentation.

🛠️ Setting Up the Testing Environment

Here’s how I set up the testing framework in my project:

Installing Dependencies:

   pip install pytest
   pip install python-dotenv

These are used for running tests and managing environment variables.

Creating the Test File:
I created test_example.py in my project’s root directory. It contains unit tests for various functions in my project.
Writing the Tests:
I used pytest and unittest.mock to create mock versions of LLM API responses and simulate different scenarios.

🌀 Mocking the LLM API

Mocking LLM responses was crucial for reproducible tests. I created a mock response using MagicMock from unittest.mock, which allowed me to:

Return a consistent response for each request.
Avoid relying on live API calls.

Example of mocking:

@patch("analyzer.send_chat_completion_request")
@patch("analyzer.read_code_file")
def test_analyze_code_with_mocked_llm(mock_read_code_file, mock_send_chat_completion_request, tmp_path):
    mock_read_code_file.return_value = SAMPLE_CODE_CONTENT
    mock_llm_response = MagicMock()
    mock_llm_response.choices[0].message.content = "Mocked formatting suggestions."
    mock_send_chat_completion_request.return_value = mock_llm_response
    # ...

💡 Lessons Learned

Aha! Moments

Mocking Simplifies Testing: Mocking the LLM allowed me to avoid issues like rate limits and unstable responses, making tests consistent.
Refactoring Improves Testability: I realized breaking large functions into smaller components makes them much easier to test.

Challenges

Initially, I faced issues with Git branches, specifically merging my testing branch into main. After some troubleshooting, I learned about interactive rebase and fast-forward merging, which cleaned up the commit history.

🐞 Interesting Bugs Found

Missing Files: I found that when certain files were missing, my code wasn’t handling the errors gracefully. This was fixed by adding appropriate error logging.
API Errors: Testing revealed that not all API errors were being caught, which could lead to crashes.

🎓 Takeaways

Testing Matters: I’d never done thorough testing before, but now I see its value in creating reliable software.
Smaller Is Better: Breaking down functions into smaller units isn’t just good practice for readability, but also for testing.

I’ll definitely continue writing tests for future projects to ensure better quality code.

📘 Conclusion

Setting up testing for my project taught me a lot about how important automated tests are for maintaining code quality. Mocking tools like unittest.mock are powerful allies when working with external APIs.

If you’re new to testing, my advice is: start small, be consistent, and keep learning. Writing good tests takes practice, but it’s absolutely worth it!

Let me know your thoughts or questions below! 😊

Enhancing Code Quality: Adding Formatters and Linters to Code-Formatter-Advisor

Elisaassa — Sat, 02 Nov 2024 03:37:48 +0000

In this post, I want to share my journey of integrating various code quality tools into my project, Code-Formatter-Advisor. These tools helped me improve the overall quality, readability, and maintainability of the codebase, and I'm hoping this guide can help others interested in enhancing their own projects.

Tools I Chose

For this project, I chose the following tools:

Black (Python Code Formatter) - Black is a widely used opinionated Python code formatter that helps standardize the look of Python code. Its primary advantage is that it eliminates arguments over style, helping teams stay productive.
Flake8 (Python Linter) - Flake8 is a linting tool that combines PEP 8 compliance checks, pyflakes, and other plugins to catch issues in the code. It's easy to set up and gives comprehensive feedback to identify and fix errors.

Why I Chose These Tools

Black was chosen for its simplicity and for being highly opinionated, meaning it requires minimal configuration and is effective in keeping everyone on the same page regarding style.
Flake8 was chosen because it offers a good balance between error detection and style consistency, while being easy to integrate into the existing workflow.

Setting Up the Tools

1. Setting Up Black

First, I installed Black by running the command:

pip install black

To apply Black to the project, I configured it to format Python files on the entire project. I also created a simple script (run_formatter.sh) to run Black from the command line:

#!/bin/bash
black .

2. Setting Up Flake8

Similarly, I installed Flake8 via:

pip install flake8

I added a configuration file .flake8 to specify the max line length and files to exclude:

[flake8]
max-line-length = 88
exclude = venv, __pycache__, migrations

I also created a script (run_linter.sh) to execute Flake8 from the command line:

#!/bin/bash
flake8

Configuring Both Tools

To make it easy for contributors to use these tools, I documented these steps in a CONTRIBUTING.md file and added them to my GitHub repository. Contributors can run ./run_formatter.sh and ./run_linter.sh to apply these tools.

Issues Found by the Tools

Once I ran Black, it reformatted most of my code to ensure a consistent style. There were a few areas where indentation and spacing were corrected, and it also enforced line breaks for long lines.

When running Flake8, it detected some common issues such as:

Line length violations: Several lines were longer than the configured limit (88 characters).
Unused imports: Flake8 flagged unnecessary imports, allowing me to clean up the code.

Integrating Tools into VS Code

I also integrated Black and Flake8 with Visual Studio Code (VS Code) to ensure real-time feedback during coding. Here are the steps I followed:

Install Python Extension: The official Python extension for VS Code supports Black and Flake8. It provides linting and formatting features automatically.
Enable Formatting with Black: I configured VS Code to use Black for formatting upon saving. This was done by adding the following to the VS Code settings (.vscode/settings.json):

   {
     "python.formatting.provider": "black",
     "editor.formatOnSave": true
   }

Enable Linting with Flake8: Similarly, I enabled Flake8 as the linter by setting:

   {
     "python.linting.flake8Enabled": true,
     "python.linting.enabled": true
   }

Command Line Integration

To run these tools from the command line, I provided the run_formatter.sh and run_linter.sh scripts, which help developers easily run formatting and linting tasks on the entire project without needing to remember complex commands.

What I Learned

This process was insightful as it highlighted several best practices for improving code quality:

Automation is Key: Automating code formatting and linting makes the development process smoother and less error-prone. Developers can focus on coding rather than worrying about stylistic details.
Integration with Editor: Real-time linting and formatting while writing code make it easier to maintain standards and fix issues on the spot.
Code Quality Tools Save Time: Implementing these tools improved readability and maintainability, ultimately making the codebase easier to work with for everyone.

Conclusion

Using Black and Flake8 helped enhance the quality of the Code-Formatter-Advisor project significantly. If you’re considering improving your project’s code quality, I recommend trying these tools for Python projects. I hope this guide helps others set up a similar workflow!

My Third PR for Hacktoberfest

Elisaassa — Thu, 31 Oct 2024 19:24:49 +0000

Lessons from Testing the Voice Button Component

Testing components can sometimes be a rollercoaster, and my recent experience with testing the VoiceButton component in my project was certainly a ride full of unexpected turns. In this blog post, I want to share what I encountered, the challenges I faced, and some insights that I hope might help others who are working on similar projects.

Setting the Scene: Voice Button

The VoiceButton component is a part of an interactive chatbot interface that allows users to interact with the bot using their voice. My goal was to write unit tests for this component to ensure it renders properly and behaves as expected when users interact with it. Specifically, I needed to validate that it changes state (toggle on/off) when clicked and reflects those changes visually.

The journey started with the VoiceButton tests, and while I initially hoped to use the same approach as other button components, this proved to be more challenging than expected.

Challenges with VoiceButton Tests

While I referenced tests from similar components, like the AudioButton, the VoiceButton seemed to have a mind of its own. No matter how carefully I wrote the tests, they would consistently fail, specifically in checking the state toggling and style changes.

Failing Tests and Debugging Loop: The tests for the VoiceButton consistently failed, indicating that the expected style or class change didn't occur after the button was clicked. The message was clear: the button remained in the "disabled" state when I expected it to be "enabled."
Console Logs and Debugging: I added console logs to trace the events and state changes during the test, but the logs showed that, despite simulating a click, the button state didn't update as expected in the test environment. I tried adjusting timeouts, tweaking how the button was clicked (using fireEvent.click() or fireEvent.mouseDown()), but the issue persisted.

Moving Forward

For now, I have tests in place that ensure the VoiceButton renders properly and shows the initial state as expected. While I referenced the AudioButton approach, I didn't write or fully test the AudioButton itself. The VoiceButton tests are more basic due to the issues I encountered.

I plan to revisit the VoiceButton tests later with fresh ideas and potentially refactor the component to make it easier to test. One consideration is to split out complex logic into smaller, isolated parts that can be tested independently.

Testing can often feel like a frustrating loop of trial and error, especially when dealing with UI components. But every failure teaches you something new, and even a small success—like getting the VoiceButton to render correctly—is progress worth celebrating.

Final Thoughts

This was my first time participating in such a big, complex project, and it was also the last day of Hacktoberfest when I worked on it. I didn't complete four pull requests this time, but I learned a lot about the challenges of testing complex components. Next time, I plan to start earlier and use this experience to improve my skills further.

My Second PR for Hacktoberfest

Elisaassa — Mon, 28 Oct 2024 18:34:55 +0000

My Second PR for Hacktoberfest: A Journey of Finding and Fixing an Issue

Participating in Hacktoberfest has been a rewarding experience, and my second Pull Request (PR) taught me a lot. Here, I want to share how I found an issue, solved it, and what I learned.

Finding the Issue

I browsed repositories with the "Hacktoberfest" label on GitHub, filtering for "good first issue" or "help wanted". I found a basic static website project that had incorrect setup instructions in the README.md. The instructions mentioned running npm install, but there was no package.json file, making the step incorrect.

Fixing the Issue

I forked the repository, cloned it, and confirmed the problem. Since it was a static website, I updated the README.md to remove the npm install step and provided instructions to open index.html directly or use a simple local server.

I tested the changes, committed them with a clear message, and created a Pull Request explaining how my updates improved the setup process.

What I Learned

This PR taught me the importance of accurate documentation. Documentation is often the first touchpoint for contributors, and incorrect instructions can lead to confusion. By improving the README.md, I made the project more accessible, contributing to a welcoming open-source environment.

Hacktoberfest is not just about adding code—it's about making meaningful contributions. Even small improvements can significantly enhance user experience.

My First PR for Hacktoberfest 🎉

Elisaassa — Mon, 28 Oct 2024 00:52:59 +0000

This October, I took my first steps into the world of open source by contributing to the Awesome Social Chess project as part of Hacktoberfest. My contribution might not have been a groundbreaking feature or a big code change, but it was something that could make a difference for others: a Contributing Guide. I noticed that new contributors could benefit from clear instructions, so I decided to create a guide that would make it easier for them to get started.

🚀 Getting Started

It all began when I identified the need for a Contributing Guide and created an issue to highlight this gap. After making sure no one else had opened a similar issue, I went ahead and submitted it. Getting assigned to work on it was really motivating, and I felt excited to get started.

🔗 Forking the Repository: I forked the Awesome Social Chess repository to my GitHub account and cloned it locally so I could work on it offline.
🌿 Creating a Branch: From there, I created a new branch called add-contributing-guide and got to work.

✍️ Writing the Guide

Writing the guide was a rewarding process. I focused on making it clear and easy to follow, with step-by-step instructions on how to fork the repo, create branches, make changes, and submit a pull request. I wanted it to be approachable, so I added a few friendly emojis to make it less intimidating and more engaging.

✨ Reflections

Even though adding a Contributing Guide might not seem like the most critical contribution, it taught me so much about how to support an open-source community. I learned the value of good documentation and how important it is to make projects accessible to everyone, especially newcomers. This experience showed me that even small contributions can have a big impact. I’m excited to keep contributing, learning, and being part of the open-source world.

Refactoring Code

Elisaassa — Fri, 11 Oct 2024 22:40:21 +0000

Refactoring is an essential part of improving software quality. It involves restructuring existing code without changing its behavior, aiming to enhance readability, maintainability, and performance. In this blog post, I'll take you through how I refactored my code, focusing on each stage of the process and how I used Git tools like rebase and squash to clean up my project's history.

Identifying Areas for Improvement

Split Code into Multiple Files: My initial script was growing unwieldy. I decided to split the code into separate files for different functionalities. For example, I moved utility functions into utils.py and the main analysis logic into analyzer.py. This made the code modular and easier to read.

Using Git to Manage Changes

Interactive Rebase

Interactive rebase (git rebase -i) is a powerful tool for rewriting commit history. During this refactoring, I used rebase to organize my commits in a meaningful way.

Combining Commits: Instead of having three commits that represented individual small changes, I combined them into one logical commit. This way, the commit history clearly shows one refactor, rather than multiple messy changes.
Editing Commit Messages: Rewriting commit messages during rebase allowed me to add more descriptive details, making it easier for others (and future me) to understand the changes.

Git Squash

While using rebase, I also applied the squash command to merge multiple commits into a single cohesive commit.

Why Squash?: By squashing multiple commits, I made my project's history cleaner. Squashing helps present the end product of a series of changes without the noise of every single incremental adjustment.
Final Commit: I ended up with one well-documented commit that encompassed the entire refactor, titled: "Refactor: Extract utility functions and split code into separate files."

Lessons Learned During Refactoring

Handling Merge Conflicts: During the process, I ran into some merge conflicts. They occurred because there were changes in both the main branch and my refactoring branch. Handling these conflicts taught me more about how to carefully review differences and make decisions about which changes to keep.
Breaking the Code: There were moments when my code broke due to some changes I made while moving functions around. I learned to rely on small, incremental changes and test regularly to prevent breaking the application.
No Bugs Found (This Time!): Fortunately, while refactoring, I didn't discover any new bugs. This was a sign that my original functionality was sound, and the refactoring successfully made the code cleaner without introducing issues.

Conclusion

These changes made my project cleaner, more organized, and easier for others to understand. And thanks to Git, I could confidently make these changes, knowing I had the tools to manage the history and avoid chaos.

OSD lab4 : Adding TOML Support to a GitHub Project

Elisaassa — Fri, 04 Oct 2024 21:01:49 +0000

Overview

This week, I worked on adding support for reading configuration from a TOML file to a peer's project on GitHub. It was a great learning experience that took me through the ups and downs of coding and version control. Here’s a brief overview of how it went:

Coding the Feature

The goal was to modify the existing configuration setup to support TOML files so that users could manage settings more easily. I used the tomli library, which made parsing TOML files straightforward. After implementing the changes, I ran into a few minor issues around handling exceptions and ensuring the correct path for the config file. By using print debugging and carefully reading the documentation, I resolved these issues and tested the feature.

Working with Git: Challenges and Solutions

Using Git was where things got interesting. I created a new branch, issue-15, for the changes and set up the remote repository. Creating a Draft Pull Request and pushing changes was smooth, but I encountered conflicts when merging. The tricky part was resolving these conflicts without messing up the codebase. I used the GitHub conflict resolution tool, which helped me view both changes side by side and decide what to keep. After a few careful attempts, I managed to resolve the issues.

Lessons Learned

Handling Merge Conflicts: Resolving conflicts taught me the value of keeping my branch up to date with the latest changes from main. I should have synchronized more frequently to avoid major conflicts.
Frequent Communication: My peer was very detailed and precise in their responses. My peer not only replied quickly but also provided clear instructions on how to resolve specific issues, such as the exact commands and code adjustments needed. This level of detail made it much easier to understand and fix the problems quickly.