Forem: kkrishnan10

Release 0.4

kkrishnan10 — Fri, 12 Dec 2025 19:55:08 +0000

For Release 0.4, I achieved the goals I set in my planning post by successfully implementing and submitting an initial category filtering feature to the Open Web Calendar project. I built this by extending the event conversion logic in convert/events.py, learning how the icalendar library exposes event metadata, and correctly using calendar_event.categories instead of manually parsing raw ICS fields after receiving maintainer feedback.

I also improved code quality by moving inline HTML styles into the project’s CSS files to match existing conventions. Throughout the process, I relied on automated tests using tox, worked in a dedicated feature branch, and updated the same pull request in response to reviews rather than opening new ones. The most important thing I learned was how open-source development is iterative and collaborative, with review feedback playing a critical role in improving both correctness and maintainability.

By engaging directly with the project maintainer through GitHub reviews and documentation links, I was able to resolve issues efficiently and align my work with project standards.

This experience demonstrates a complete open source workflow from planning and implementation to review and refinement and the technical details documented here should help others understand how category metadata is handled in Open Web Calendar and similar ICS based projects.

Release 0.4- Progress

kkrishnan10 — Tue, 09 Dec 2025 00:52:52 +0000

For my Release 0.4 progress, I spent this week digging into the Open Web Calendar codebase to understand exactly where events are parsed, how ICS data is converted to JSON, and how the frontend scheduler loads and displays those events. I was able to add category extraction on the backend by pulling the CATEGORIES field from ICS files and preparing it for JSON output. I also started exploring the frontend code to find where events are loaded so I can attach the category filter UI and filtering logic.

Even though some JS files were minified and harder to read, I kept narrowing down the correct source files and now have a clear path forward for adding the filter checkboxes and connecting them to the scheduler. My next step is to finish the frontend code, test everything together, and prepare the final PR. Overall, I’m on track with my plan and feel more confident with the structure of the project.

Release 0.4- Planning

kkrishnan10 — Mon, 08 Dec 2025 06:04:11 +0000

For Release 0.4, I decided to work on adding category-based event filtering to the Open Web Calendar project. This feature will let users filter events by category using checkboxes, which makes the calendar easier to navigate when there are many different types of events.

I chose this task because it is meaningful, visible to end users, and requires me to work across both backend and frontend parts of the project, which will help me grow as a developer. My approach is to break the work into clear steps:

First update the ICS parser to read the CATEGORIES field, then include those categories in the JSON response, and finally build a simple UI on the calendar page that displays dynamic checkboxes and filters events through the scheduler API.

Over the next weeks, I will implement each layer carefully, test with real ICS files, and refine the UI. My goal is to finish with a polished feature and a clean pull request that improves the project in a useful way.

Packaging and Releasing ContextWeaver for Lab 9

kkrishnan10 — Sat, 22 Nov 2025 03:20:29 +0000

For my lab, I worked on my repo ContextWeaver and I used Python’s packaging tools and published my project on TestPyPI using build and twine, since Python packages are all managed through PyPI and TestPyPI. The process was pretty detailed. I had to reorganize my code into a proper src/contextweaver structure, create a pyproject.toml with all the metadata, bump versions every time I re-uploaded, build the package using python -m build, and then upload it with twine.

I learned a lot about how strict packaging actually is especially versioning (you can’t reuse a version, or TestPyPI will reject it), and how the description shown on PyPI actually comes from your README.md. My “aha” moment was realizing that I had to update the version and pull the changes locally before rebuilding, otherwise I’d keep uploading the wrong version. I didn’t need to change my code logic, but I did have to clean up my file structure and add installation sections to my README so it made sense for real users.

For user testing, I asked my friend to follow only the README, and they immediately got confused about installation, Python version, and how to run the CLI. I took notes and updated the README to include installation (pip install), Python 3.10+ requirement, CLI examples, and troubleshooting. Now users can install my project with a simple pip install contextweaver, and they can run it using commands like contextweaver . -o snapshot.txt. Overall, the release process forced me to think about how a real user would experience my project, and updating the documentation made a huge difference.

Release 0.3 — Normalizing Unicode for Event Text

kkrishnan10 — Sat, 22 Nov 2025 03:11:10 +0000

For my second PR, I worked on improving Unicode handling across event data, specifically addressing a bug where diacritics and accented characters were displaying incorrectly in event summaries, descriptions, and locations in Open Web Calendar project.

This issue affected international users whose calendars contained characters like á, ñ, ü, and ø. To fix this, I explored the ICS conversion process in events.py, added a normalization function using Python’s unicodedata.normalize("NFC"), and made sure it applied consistently to all text fields before being passed to the frontend. This required reading through the ICS parser, learning how the project structures event data, and testing with sample ICS files that contained accented characters to verify the fix.

Compared to my earlier assignments, this PR felt more like real open-source work, debugging a subtle data-handling issue, updating backend code, and manually validating changes across the UI. This contribution helped me get comfortable modifying a larger codebase and taught me how to approach encoding problems that don’t always produce obvious errors but have a real impact on user experience.

Release 0.3 — Fixing All-Day Events Displaying as Two Days

kkrishnan10 — Sat, 22 Nov 2025 03:04:51 +0000

For my first PR in Release 0.3, I decided to fix an issue in the Open Web Calendar project where all-day events were showing incorrectly as two-day spans. This bug had been reported by multiple users and required me to go deeper into the frontend event-rendering logic in calendar.js.

I started by running the project locally, comparing real ICS behavior, reading the DHTMLX scheduler documentation, and tracing how the app determines whether a start and end time represent a one-day duration. Eventually I discovered that ICS all-day events use an exclusive end date, which meant the calendar was interpreting them as starting at midnight on Day 1 and ending at midnight on Day 2.

My fix adjusted the date-handling logic so that if both timestamps begin at 00:00, the end date is automatically shifted back by one day. I tested this using multiple ICS files and confirmed that the calendar now displays all-day events cleanly as a single day. This PR pushed me to analyze JavaScript code more deeply than I did in Release 0.2, and it helped me better understand how calendar systems handle date boundaries.

Lab 8- OSD 600

kkrishnan10 — Fri, 14 Nov 2025 22:02:24 +0000

For this lab, I set up GitHub Actions in my ContextWeaver repo by creating a workflow file that runs pytest every time I push to main or open a pull request, and it was actually helpful because I could see right away when I broke something in scanner.py and when it got fixed. After that, I created a new branch and added more tests to my own project, then opened a PR to make sure CI was working properly.

For the partner part, I used rust-cli-tool repo, which was totally different from mine since it uses Rust and cargo test instead of Python and pytest. Writing a test in someone else’s project felt weird at first, but once I made a simple sanity test it was fine and it passed with their CI too.

Overall, setting up CI made me realize how useful it is because it catches mistakes right away, and it really does stop you from accidentally pushing broken code. The main CI setup and testing across repos went smoothly and now I understand why teams rely on this so much.

Lab 7 - Testing with pytest

kkrishnan10 — Sat, 08 Nov 2025 02:30:37 +0000

For Lab 7, I used pytest and pytest-cov in my repo ContextWeaver because they’re simple, popular, and well-documented tools for testing in Python. I added them to my requirements.txt, installed them in my virtual environment, and created a tests folder with a conftest.py file so my test files could import modules from src.

I started by writing unit tests for ignore.py to check how it handled default, gitignore, and extra patterns, then added integration tests for main.py to make sure the CLI worked correctly with different ignore options.

At first, one of my tests failed because of how my pattern matching worked, which helped me understand how *.py behaves in subdirectories. Running coverage showed that ignore.py had 100% coverage, while the overall project had 23%, so I could clearly see what still needed more testing.

I realized how much automated testing improves confidence in my code, especially for catching small mistakes early, and I will definitely keep using pytest for future projects.

Hacktoberfest Final Week

kkrishnan10 — Fri, 31 Oct 2025 01:03:00 +0000

For my final Hacktoberfest contribution, I worked on Issue #18 which was “Rotate Array by K Positions” in the Seed-Pursuit repository. The issue didn’t have a full description, so I interpreted it as the standard DSA problem of rotating an array to the right by k positions.

To prepare, I explored the repository’s structure and confirmed it was written in Java, then set up my local environment and created a new branch for the fix. I reviewed different rotation methods and chose the optimal reverse-based approach, which rotates the array in O(n) time and O(1) space. My implementation reverses the entire array, then the first k elements, and finally the remaining ones, ensuring all cases work even when k exceeds the array length.

The final file, DSA/RotateArrayByK.java, includes a main() method for testing, where users can input n, the array elements, and k, to see the rotated output. Before coding, I researched similar solutions on GeeksforGeeks to verify my approach and syntax. The main challenge was understanding the repo’s submission style and ensuring my code matched its conventions.

Once completed, I pushed my changes to GitHub and created Pull Request. This experience helped me improve my confidence in contributing to open-source projects, practice Git branching and PR etiquette, and apply algorithmic logic in a real project environment.

Code Reading Analysis – Repomix Ignore Feature

kkrishnan10 — Mon, 27 Oct 2025 18:31:50 +0000

For Lab 6, I studied how Repomix implements its ignore functionality to learn from an established open-source project before extending my own tool. Repomix goal is to bundle repository content while automatically excluding unneeded files using patterns from .gitignore, configuration files, and default rules.

While reading its source code, I focused on the modules responsible for loading ignore files, merging pattern lists, and testing whether a file should be skipped. I used GitHub Code Search and git grep to locate functions like load_gitignore(), merge_patterns(), and should_ignore(), and I also reviewed related tests and pull requests to understand how the maintainers verified their behavior.

Through this code reading exercise, I learned that Repomix design is modular and extensible, it separates pattern gathering, normalization, and filtering into different components, which makes debugging and reuse easier. The feature also uses recursive matching for directory globs (**/) and negation handling (!pattern), concepts I later adapted in my own implementation.

I realized how important small helper functions and clear naming conventions are when reading other people’s code. Reading “with a goal” focusing specifically on how patterns are loaded and applied helped me stay focused instead of getting lost in unrelated parts of the repository.

Overall, examining Repomix taught me practical lessons in open-source code navigation and feature design. It showed me how to analyze real-world projects to guide improvements in my own work. This directly inspired the Git-Aware Ignore System I later wrote for my project ContextWeaver, which merges default patterns, .gitignore entries, and user-provided globs into a unified filter. Reading Repomix’s code first made implementing this feature far easier and more intentional.

Lab 6: Writing the Git-Aware Ignore Feature in My Project

kkrishnan10 — Mon, 27 Oct 2025 18:14:28 +0000

After exploring how Repomix handled file-ignoring logic, I wrote the same type of feature in my own project, ContextWeaver. My goal was to make my repo ContextWeaver automatically skip irrelevant files such as node_modules, build folders, and logs while scanning repositories.

To achieve this, I created a new module called ignore.py and integrated it into main.py. The ignore.py file merges default ignore patterns, .gitignore entries, and any custom globs provided through the --ignore flag. In the main script, these patterns are used by a helper function should_skip() that decides whether each file should be kept or excluded.

I also added new CLI options such as --ignore, --no-default-ignores, and --verbose. When running the command "python3 src/main.py . --verbose", the program lists every file with “ADD” or “SKIP,” giving a clear view of what gets included. The resulting file list is saved to contextweaver_output.txt, making the tool more user friendly and Git-aware.

This was my first time reading another project’s source code to learn a feature and then reimplementing it myself. It showed me how to adapt ideas while writing cleaner, modular code. The next steps are already planned in my Issues page: adding nested .gitignore support, handling negation patterns (!pattern), benchmarking performance, and improving documentation. Through this lab, I learned how open source developers plan incremental improvements, file Issues, and build on one another’s work to make software evolve continuously.

Week 3 – Adding a New API to the Public APIs Repository

kkrishnan10 — Mon, 20 Oct 2025 06:30:59 +0000

For my third Hacktoberfest contribution, I decided to work on the Public APIs repository, which collects free and open APIs that developers can use for learning or building projects. It already had the Hacktoberfest topic, so it was a great choice for a simple yet meaningful contribution.

I added a new entry for the Art Institute of Chicago API to the Art & Design category. This API provides free access to artworks and museum data, making it an excellent resource for anyone interested in art or cultural data projects. I updated the README.md following the project’s contribution rules, kept the description short, formatted the table correctly, and ensured the entry stayed in alphabetical order.

The process taught me how strict formatting can be in large open-source repositories and how even a one-line addition needs to follow established contribution guidelines. I also learned how to use the contributor checklist to verify spacing, description length, and commit squashing before submitting.
Once I pushed my branch and opened the pull request, GitHub showed that the repo already carried the Hacktoberfest topic, so the PR automatically counted toward my progress. Seeing my name appear among contributors felt rewarding—it reminded me that open source values every improvement, no matter how small.

Next, I plan to explore a project where I can contribute a small code or configuration fix, continuing to move from documentation toward hands-on development tasks.