Forem: Aubrey D

Shipping Meaningful Open Source Work

Aubrey D — Fri, 12 Dec 2025 20:20:56 +0000

Release 0.4 was about doing work I could be proud of, over multiple weeks. I chose to continue contributing to hiero-sdk-python because it aligns with my career goals (Python SDK development, developer experience, and reliable tooling), and because the repo has clear contribution standards and active maintainers. By the end of this release, I delivered two pull requests that together reflect both sides of real SDK work: improving a user-facing example and extending a core API with tests.

•PR #1044: Fix token association verification in the token airdrop example. This PR fixes a subtle but important developer experience problem: the example previously displayed token balances after association, which can be misleading because balances can remain 0 even when association is correct. The PR refactors the example output to verify association properly by checking whether the token ID exists in the account’s token_balances map and printing a clear “Associated / NOT Associated” result. This is the kind of change that looks small but prevents confusion for new users who copy/paste examples to learn an SDK.

•PR #1051: Support PublicKey for batch_key in the Transaction class with Unit & integration tests. This PR extends the transaction batching API so batch_key can accept both PrivateKey and PublicKey. Previously, only PrivateKey was accepted, which forced developers to provide private key material even in workflows where only a public key should be required. To make the change safe and reviewable, the PR also adds unit tests & integration tests.

Both PRs were built with the project’s standards in mind: minimal unintended behavior change, changelog updates, signed commits, and CI checks. I achieved the “meaningful work” goal by choosing one contribution that improves developer understanding and another that improves SDK capability. I also stayed consistent with weekly progress and worked through review/automation feedback instead of treating PR creation as the finish line.

This release reinforced that “real” open source work is not just writing code — it’s writing code that fits a system:
•Examples are part of the product. A misleading example can cost users hours and harm trust in the SDK. Fixing #815 taught me to treat examples like public APIs: they need to be correct and unambiguous.
•Small API changes can require broad thinking. Allowing PublicKey for batch_key sounds simple, but it touches typing, serialization paths, and testing expectations across transactions.
•Review feedback is where you level up. The most valuable part wasn’t writing the first version, it was iterating based on reviewer and also automation feedback to align with repo conventions.

Automated maintainership tools like WorkflowBot pointed out when the PR couldn’t be merged due to failing checks and provided direct links to contribution guides. Maintainer review helped me see beyond the immediate code change. For example, maintainers suggested expanding related example/tests around batch transactions, which is the type of ecosystem thinking I want to build in my future contributions. Even AI review comments were useful as a checklist for consistency, but I treated them as suggestions buy not authority and prioritized maintainer expectations and CI rules.

Release 0.4 gave me a realistic open-source development experience: choosing scope, shipping improvements, handling review cycles, and working with community standards. I’m leaving this term with stronger confidence in contributing to production grade Python projects, especially SDKs where correctness, developer trust, and maintainability matter.

Progress Update To Release 0.4

Aubrey D — Fri, 12 Dec 2025 19:55:43 +0000

In the second week of Release 0.4, my focus shifted from planning to execution. Rather than trying to finish everything quickly, I spent this week scoping the work more carefully, understanding the codebase in depth, and validating that the issues I chose were the right size and complexity for a multi-week contribution. I am currently working on two issues in the hiero-sdk-python repository: #815 and #1015. Although they differ in scope, they are connected by a common goal—improving the developer experience of the SDK.
This week was primarily about research and orientation. For Issue #815, I reviewed the existing example token_airdrop.py and examined how token association is currently demonstrated. I focused on understanding the expected behavior of token association in the SDK and why the current output could be misleading to users. This issue is relatively small in terms of code changes, but it requires careful handling to ensure the example remains correct, clear, and runnable. For Issue #1015, I spent time reading through the transaction system in the SDK to understand how batching works and how keys are handled internally. This involved tracing how transaction properties are stored, validated, and eventually serialized. At this stage, my goal was not to immediately write code, but to understand the broader design and identify which parts of the system would be affected by the proposed change.
The main challenge this week has been scope management. While Issue #815 is well-contained and straightforward, Issue #1015 touches a more central part of the SDK. Even a small API change can have ripple effects, so I needed to slow down and make sure I fully understood how the transaction pipeline works before committing to an implementation. Another challenge has been balancing progress with caution. Since this is a core SDK feature, I want to avoid rushing changes that could introduce subtle bugs or break existing assumptions.
Based on what I learned this week, I’m adjusting my approach in the following way:
•I will complete Issue #815 first, using it as a focused improvement that delivers immediate value and builds momentum.
•I will continue developing Issue #1015 incrementally, validating assumptions and testing behavior as I go rather than attempting a large change all at once.
•I will prioritize steady weekly progress over rapid completion, aligning with the long-term nature of Release 0.4.
This week confirmed that my chosen scope is appropriate for the remaining weeks of the course. While I’m not finished yet, I now have a much clearer understanding of the problem space and a solid foundation to build on moving forward.

Planning My Final Open Source Contribution

Aubrey D — Fri, 12 Dec 2025 19:10:16 +0000

For Release 0.4, I want to push myself further and work on a contribution that is meaningful to me and demonstrates everything I’ve learned this term about open-source development. After reviewing the options listed in the assignment, I decided to work on a feature-level contribution or bug fix for the hiero-sdk-python project. This is a repository I have already contributed to in earlier releases, so I am familiar with the structure, coding style, and contribution workflow. More importantly, this project aligns well with my long-term interests in Python development, and SDK design. During Release 0.3, I worked on adding an example script and became more familiar with how the SDK interacts with Hiero’s APIs. While working on the project, I noticed that certain parts of the SDK are still incomplete or could be improved with more examples, extra helper utilities, and better developer-side support. The codebase is active, well-maintained, and has reviewers who give detailed feedback—exactly the kind of environment where I can continue to grow as an open-source contributor. Over the next few days, I will communicate with maintainers to confirm which feature area would be most helpful and ensure my work aligns with their roadmap.
My plan is to take steady, visible steps each week:
Week 1 – Research and proposal
•Explore open issues, discuss with maintainers, and finalize the scope.
•Prepare a technical plan for the feature.

Week 2 – Development + iteration
•Implement the core part of the feature.
•Write tests, examples, or documentation as needed.
•Submit early PRs to get feedback from maintainers.

Week 3 – Finalization
•Address all code review comments.
•Polish tests and documentation.
•Publish the final PR and write my final reflection.

I wish I can deliver a feature that the maintainers are willing to merge and gain deeper experience reading large Python codebases and contributing at a higher level. This release is my opportunity to take one more step toward becoming a stronger open-source developer, and I’m excited to work on something I can be proud of.

Releasing "Repository-Context-Packager" to npm

Aubrey D — Sat, 22 Nov 2025 00:44:07 +0000

I recently prepared and published a small CLI tool called Repository-Context-Packager to the npm registry. I used npm as my package registry and the standard npm publish for releasing.

The release process started with preparing my package.json file. I set the version to 1.0.0 and added a files array to control what gets published. I also added a bin field for the CLI command, set the engines requirement, and created a prepublishOnly script to run tests and linting automatically before publishing.

Next, I created a .npmignore file to exclude test files, GitHub workflows, and dev documentation. This kept the package size small—only about 27 KB with 11 files. I used npm pack --dry-run to preview the package contents before actually publishing.

Before publishing, I made sure all 76 tests passed with npm test and verified the code quality with npm run lint. Then I committed the package.json changes and created a git tag using git tag -a v1.0.0 -m "Release v1.0.0". After pushing both the commit and tag to GitHub, I ran npm publish to upload the package to the npm registry. Finally, I verified everything by checking the npm package page and testing the installation with npm install -g repository-context-packager.

I was realizing that git tags and npm package versions are completely separate systems. npm reads the version from package.json, not from git tags. I initially created a git tag v1.0.0 and expected npm to automatically show that version, but npm still showed 0.9.0 because that's what was in package.json. The correct workflow is to update package.json first, commit that change, create the git tag, push everything, and then publish.

I also learned how to handle git push conflicts. When I tried to push my tag, it was rejected because the remote had new commits. I used git pull --rebase origin main to update my branch and resolved the conflicts. Another issue was that I had created a tag before updating package.json, so I had to delete it with git tag -d v1.0.0 and git push origin --delete v1.0.0, then recreate it on the correct commit.

Adding a prepublishOnly script that runs npm test && npm run lint was really valuable. It prevents me from accidentally publishing broken code because the publish command stops if tests fail.

The changes I made were minimal and focused on packaging rather than source code. I updated package.json with the new version, added a files array, bin field, engines requirement, prepublishOnly script, and keywords for discoverability. I created a .npmignore file to exclude tests, CI files, and dev documentation. I also updated the README.md with npm installation instructions and version history. The actual source code in the src/ and bin/ directories didn't need any changes.

When my partner tested the release process, they got stuck on two main issues. First, they were confused about the version mismatch—they saw the git tag v1.0.0 but npm showed 0.9.0. I explained that git tags and npm versions are separate systems and that npm reads from package.json. Second, they encountered a git push rejection because of remote commits they didn't have. I showed them how to use git pull --rebase origin main to handle this situation.

The testing session revealed that I needed better documentation explaining the relationship between git tags and package versions. What seemed obvious to me after going through the process wasn't clear to someone doing it for the first time.

Now that the package is published, users can install it globally with npm install -g repository-context-packager. After installation, they can use the repomaster command from anywhere. Common commands include repomaster --version to check the version, repomaster --help to see available options, repomaster . to package the current directory, and repomaster . -o output.txt to save the output to a file.

Setting Up CI Workflow: A Journey of Testing and Automation

Aubrey D — Wed, 12 Nov 2025 19:58:21 +0000

We set up a GitHub Actions workflow with two separate jobs that run on every push to the main branch and on pull requests. Here's what happens automatically:

Lint Job: This job checks our code quality using ESLint. It runs on the latest Ubuntu environment, installs our dependencies with npm ci, and then runs our linting rules. If any code doesn't meet our style standards, the build fails and we know we need to fix it before merging.

Unit Tests Job: This job runs all our tests using Jest. We're using the experimental ES modules support in Node.js, which required adding some special flags. The tests make sure our code actually works as expected.

My partner's repo-snapshot project uses a different testing framework called Vitest instead of Jest. He has coverage configured in his vitest.config.ts file, which automatically tracks code coverage whenever tests run. His setup looks pretty clean and modern since Vitest is built specifically for modern JavaScript projects. He also have a GitHub Actions CI workflow, but it's structured differently from mine. While I split our workflow into two separate jobs (lint and unit-tests) that run in parallel, he combine everything into a single build job. His workflow uses pnpm instead of npm, which is a faster alternative package manager. In his single job, he run format checking, linting, and tests one after another. But if the format check fails, you have to wait for it to fix before the other checks can run.

When I helped write tests, I focused on testing the parseTomlConfig function, which reads and parses TOML configuration files. I wrote test cases covering different scenarios - when the config file doesn't exist (should return an empty object), when it contains valid TOML content, when the TOML is malformed (should throw an error), and when using a custom config file path. One thing that made testing easier in his project was that Vitest has really nice mocking capabilities. I could easily mock the file system functions like existsSync and readFileSync so tests wouldn't depend on actual files existing on disk. The beforeEach hooks let me clean up mocks between tests, which kept everything isolated and predictable.

Every time I push code, I know within a few minutes whether everything still works. I don't have to remember to run tests manually or worry that I forgot to check something. If someone else contributes to the project, the CI workflow automatically checks their code. This is huge because it means I don't have to manually review every detail - the automated checks catch obvious problems. The workflow file itself documents how to run tests and linting, which helps new contributors understand the project setup. Having that green checkmark on pull requests just feels good. It shows the project is well-maintained and takes quality seriously.

I did two optional challenges. I Added a Linter to the CI Workflow. This was actually pretty straightforward once we understood the YAML syntax. We created a separate job specifically for linting that runs ESLint on all our JavaScript files. The key was making sure to install dependencies first with npm ci before running the linter. This catches style issues and potential bugs before they make it into the codebase. It's saved us from some embarrassing typos and inconsistent formatting. I also seted up a Dev Container. I created a devcontainer.json file that defines a complete development environment using Node.js 20 on Debian Bookworm. The most important addition was the postCreateCommand that runs npm install and npm link. This ensures that whenever someone opens the project in a dev container, all dependencies are installed automatically and the repomaster command is available globally. Without npm link, the CLI tool wouldn't work properly inside the container.

Building a CI pipeline isn't just about running tests automatically, it's about creating a development workflow that makes it easy to maintain quality. The linter keeps our code clean, the tests verify functionality, and the dev container ensures everyone has a consistent environment. Together, these tools make collaboration easier and give us confidence that our code works as expected.

Setting Up Testing for My CLI Tool

Aubrey D — Sat, 08 Nov 2025 02:47:37 +0000

I just finished adding tests to my Repository-Context-Packager project,
I went with Jest as my testing framework. Jest is probably the most popular JavaScript testing framework out there and it comes with everything built-in, mocking, coverage reports. I didn't need to install a bunch of separate packages like you would with some other frameworks. Plus, Jest has really good documentation and a huge community, so when I got stuck, I could find answers pretty easily. The other reason was that Jest just works out of the box for most projects.

My project uses ES modules, and Jest doesn't natively support that without some configuration. First, I installed Jest as a dev dependency with npm install --save-dev jest, but then when I tried to run it with just npm run jest, it completely failed with a "Cannot use import statement outside a module" error. Turns out, even though Jest 30.x has better ES module support, you still need to run it with Node's experimental VM modules flag. So I had to update my package.json test script to node --experimental-vm-modules node_modules/jest/bin/jest.js instead of just jest. I also created a jest.config.js file to tell Jest to use Node as the test environment and specify where my tests are located. The config was pretty simple, just set testEnvironment: 'node', defined my test match patterns for files, and configured coverage settings. One more thing that tripped me up, I had to import jest from @jest/globals in my test files to use things like jest.spyOn() for mocking, and I also had to update my ESLint config to recognize Jest globals like describe, test, and expect, otherwise my editor was full of red squiggly lines complaining that these weren't defined.

I decided to start with three different modules to get good coverage of different testing scenarios. First was toml-config.js, which loads configuration from TOML files. This was perfect for a first test because it's a simple, pure function with clear inputs and outputs. I wrote 12 test cases covering everything from valid configs to malformed TOML syntax to missing files. I needed to create actual test fixture files instead of mocking the file system. My second target was tree-builder.js, which has two functions - one that builds a tree structure from file paths and another that renders it as text. This ended up being super fun to test because I could write 30 test cases covering all sorts of edge cases like empty arrays, nested directories, different path separators, dotfiles, and making sure the sorting worked correctly. I even added integration tests that combined both functions. The third module I tested was git-info.js, which gets Git repository information. This one was tricky because it involves running actual Git commands. I initially tried creating temporary Git repositories in my tests, but that got really complicated really fast with issues about deleted directories and branch names. So I simplified it to just test against the actual project repository, which worked much better. I wrote 13 tests covering things like checking the return value structure, handling non-Git directories, and various edge cases.

I discovered that my Git function needed to handle cases where someone runs it from a non-Git directory, and it properly returns null in those cases. The most interesting edge case was dealing with different Git default branch names - some systems use master and newer ones use main, so I had to make my tests flexible enough to handle both. I also found that testing with Unicode characters in author names and special characters in commit messages worked fine. One thing that surprised me was that my TOML parser properly rejected duplicate keys in config files, which I wasn't even sure about until I wrote a test for it.

I've written unit tests before in other projects, but this was my first time setting up Jest from scratch with ES modules, and honestly, it was more challenging than I expected. The ES modules support in Jest is still marked as "experimental" and it shows - the setup wasn't as smooth as I remembered from working with CommonJS projects. But once I got past the initial configuration hurdles, everything clicked. What really struck me this time was how much more thoughtful I've become about testing. Before, I used to just write tests to make sure functions returned the right values, but now I'm thinking more deeply about edge cases and failure modes. The biggest lesson was about test design. I learned that sometimes testing against real files and real Git repositories is actually better than mocking everything.

My Hacktoberfest 2025 Journey: From First PR to Four Projects

Aubrey D — Fri, 31 Oct 2025 09:00:18 +0000

October was one of my most productive months so far, I officially completed Hacktoberfest 2025! This was my first real experience contributing to multiple open-source projects, and honestly, it changed the way I think about coding, collaboration, and learning.

Hacktoberfest 2025 wasn’t just about collecting pull requests.
It was about learning how to read, communicate, and contribute to real-world projects that skills that you can’t really get from tutorials alone.

By the end of the month, I had contributed to four completely different codebases:
• One taught me backend testing,
• One taught me frontend motion design,
• One taught me async logic,
• And one taught me code clarity.

I started October nervous about even opening someone else’s repo.
Now I end it confident that I can step into any open-source project, figure things out, and leave it a little better than I found it.

Hacktoberfest PR: Cleaning Up Code

Aubrey D — Fri, 31 Oct 2025 08:48:44 +0000

Issue
PR

hiero-sdk-python is a Python SDK for the Hiero blockchain — a toolkit that helps developers interact with smart contracts, tokens, and transactions through Python.
It’s structured a lot like the Hedera SDK, where each type of blockchain transaction (freeze, unfreeze, transfer, etc.) has its own class, all inheriting from a shared base class called Transaction.

This SDK has a clear focus on clean design and maintainability, which is why this issue existed in the first place. The issue described a small but important cleanup: the TokenUnfreezeTransaction class had some duplicate logic that was already implemented in its parent class. The goal was to remove the extra field and method, and update the internal calls to use the inherited _require_not_frozen() instead.

This one was pretty straightforward, but it needed careful attention to detail.

Here’s what I did:
1. Removed the line that declared _is_frozen in token_unfreeze_transaction.py.
2. Deleted the __require_not_frozen() method entirely.
3. Replaced all instances of self.__require_not_frozen() with self._require_not_frozen() to make sure the class now used the inherited version from Transaction.

Before this PR, I didn’t realize how important method naming conventions could be in large codebases. In Python, a double underscore method gets “name-mangled”, so it doesn’t behave exactly the same as a protected _method. That subtle difference can lead to bugs if you don’t notice it.

Hacktoberfest PR: A Tiny Code Change

Aubrey D — Fri, 31 Oct 2025 08:36:32 +0000

issue
PR

erxes is an open-source customer experience and growth marketing platform — kind of an all-in-one tool for managing conversations, sales pipelines, marketing campaigns, and analytics. It’s a huge project with tons of modules and integrations, so even small fixes matter. This one was a really simple issue compared to my earlier PRs. The problem was a function that didn’t handle async behavior properly.

The fix was to make it return a Promise, ensuring that the function completed its asynchronous work before continuing.
That small change helped stabilize the flow and made the code cleaner and more predictable.

removeChecklists(contentTypeIds: string[]): Promise<void>;

Even a tiny change can make a real difference in a large codebase.
This fix reminded me how easy it is to overlook async behavior — and how important it is to make functions predictable when dealing with network requests, database calls, or delayed responses.

Hacktoberfest Contribution: Feature implement in make-it-oss

Aubrey D — Fri, 31 Oct 2025 08:18:14 +0000

This time I jumped into something new. I found this make-it-oss project. This is a useful tool to help open source maintainers manage the documentation (maybe scaffolding or helping contributions). The issue #35 caught my attention because it described a specific details of what they want.

The issue I worked on was a feature request to improve the user experience. Here’s what the request said (in simple terms):
When the user clicks the arrow button in the GithubInput component and the file list appears, the new content should animate smoothly upward — a slide-up and fade-in motion.
At the same time, the Hero section (the big intro banner) should disappear, leaving the focus on the file list.
A Back button should appear at the top so the user can bring the Hero back if they want to start over. Basically, the goal was to make the whole interaction feel more natural.

Before jumping into code, I wanted to see how things worked.
The part that handles the submission and file display is the GithubInput component.
It already fetched and displayed files once the repo was processed, but the Landing page, which also contained the Hero section, didn’t know when those files were ready. So the first thing I needed to do was make these two components talk to each other.
That way, when files were ready, the Landing page could hide the Hero and trigger the animation for the results.

To make all that work, I started by letting the Landing page know when files were ready to show. I added an onFilesReady() callback in the GithubInput component so it could notify the parent once the repo scan finished. When that callback fired, the Landing page set a simple showFiles state to true — which controlled everything: hiding the Hero, showing the file list, and triggering the animation. Instead of creating new components, I reused GithubInput with a small filesOnly prop that hides the input and only renders the file checklist. For the animation itself, I kept it lightweight using Tailwind’s built-in transitions. The Hero fades and slides up out of view, and the file list fades in from below with a 300ms ease-out motion. I also added a Back button that scrolls smoothly to the top and resets the state. To keep it all stable, I avoided unmounting the Hero right away — I just visually hid it, which prevented any layout jumps and made the whole experience feel smooth and focused.

This PR taught me that UI polish is all about state control and simplicity. Smooth animations aren’t about fancy code, they come from clear logic. I learned how to reuse components smartly, how to hide elements without breaking layout flow, and how small visual cues can make a big difference in user experience. It was also a reminder that testing animations on different viewports (especially mobile) is crucial — timing and motion feel completely different on smaller screens.

Implementing New Feature in Repository Context Packager

Aubrey D — Tue, 28 Oct 2025 00:54:12 +0000

I extended my Repository Context Packager tool by adding a new feature:
File Filtering by Extension via the --include flag.
This feature allows users to specify which file types they want to include when generating repository summaries.
For example, users can now do the following:

repomaster . --include "*.js"
repomaster . --include "*.js,*.py,*.md"

Many users only want to extract meaningful source code or documentation. By allowing them to filter files by extension, the tool becomes more flexible and efficient when used to generate data for LLM input or AI code assistants. In this feature, the program first parses these patterns from the CLI, then uses the globby library to quickly find all matching files in the current directory. It supports advanced glob syntax, .gitignore, and cross-platform paths, and it handles most of the complexity automatically. Finally, the tool filters the collected file list so that only files whose absolute paths match the globbySync() results are included in the final output.

This feature was inspired by the open-source project Repomix, which also supports --include and --exclude options for pattern-based file selection.
Repomix uses the same globby library, so I followed its approach.

The main difference is that my implementation is intentionally simpler which I focused only on inclusion logic, leaving exclusion and .gitignore merging for future versions.

After completing this feature, I’ve opened two new issues to continue improving overall flexibility in the tool:
• issue-12
• issue-13

These two changes will reduce code complexity, improve performance, and make filtering behavior consistent with modern CLI tools.

Exploring Repomix and Learning from Its Feature

Aubrey D — Mon, 27 Oct 2025 23:01:36 +0000

This time, I studied an open-source project called Repomix to better understand how professional open-source tools organize their code and implement advanced features. Repomix is a CLI tool that packages repository context for LLMs — similar to my own project Repository Context Packager, but much more feature-complete. To analyze Repomix, I used a tool called DeepWiki. DeepWiki automatically indexes the source code of open-source repositories and presents it in a structured, documentation-style website. It breaks the project down into categories such as Command Line Interface, Configuration System, and Core Packager, and provides direct links to the original GitHub files. This made the process much faster — instead of opening dozens of files manually, I could see how Repomix’s architecture fits together at a high level and then jump straight to the parts I cared about.

The feature I chose to explore was: Include Patterns. By tracing through the DeepWiki documentation and the linked source files, I found that Repomix implements file filtering in three main stages:

Parsing the CLI Arguments Repomix uses Commander to parse options like --include "*.js,*.py". The argument string is split into an array of patterns (for example: [".js", ".py"]).
Merging Configuration Sources In defaultAction.ts, the CLI arguments are merged with configuration file values (repomix.toml or .json) so that defaults are respected and CLI options override them when provided.
Applying the Filters with globby During the repository scanning phase, Repomix uses globby to list all files, passing the include/exclude patterns directly to it. This allows the user to precisely control what files are read and included in the output. What I liked most was how modular this logic is, instead of writing custom filtering code, Repomix delegates the complex part to globby, which supports glob patterns, .gitignore, and cross-platform path normalization.

From this learning process, I do learned that instead of reinventing pattern matching, using globby simplifies the entire filtering process. Good naming helps understanding and searching. It’s easier to learn when you have a concrete feature to trace instead of reading everything blindly.