DEV Community: Anderson Yu-Hong Cai

PR-06 at Hacktoberfest: Applying E2E Testing Lessons to Chart.js + Alpha Vantage

Anderson Yu-Hong Cai — Sun, 26 Oct 2025 08:34:40 +0000

Introduction

In my previous post, I documented how seven rounds of feedback reshaped my HERE Maps E2E tests. This time, I put those lessons straight to work on a new page—Chart.js backed by Alpha Vantage—aiming to get it right on the first try.

Background

Project: Hackathon Starter
Page: Chart.js with Alpha Vantage data
Goal: Add a lean, reliable Playwright E2E test suite
Challenge: Avoid the “write everything, then refactor” trap

The Temptation I Skipped

Without the HERE Maps experience, I would have:

Loaded the page for every test (8 tests → 8 loads)
Checked static HTML (titles, buttons, icons)
Verified <script> tags and versions
Simulated flaky error scenarios

…which is exactly the bucket of things maintainers asked me to remove last time.

Applying the Lessons — From the Start

Here’s what I did instead, upfront:

1) Shared Page Pattern

Create the page once in beforeAll and reuse it across tests.

Effect: 8 potential page loads → 1 (≈ −87%).

2) Focus on Core Functionality

Not testing: titles, button labels, Font Awesome, <script> tags, descriptive copy.

Do test: chart renders with data, correct labels/points count, and observable behavior.

3) Precise Data Assertions

Where possible, assert exact values (not broad ranges). If data varies, assert deterministic transforms (e.g., label counts, date ordering, first/last point mapping).

4) API Key Strategy

Instead of testing fallbacks, I let the test fail fast when the Alpha Vantage API key is invalid. That surfaces configuration issues immediately and keeps the suite honest.

Final Test Structure

Test 1: Page loads once and initializes the chart
Test 2: Data → chart pipeline works (labels/points count, x–y mapping)
Test 3: Integrity checks (e.g., newest label aligns with latest data; legend present; canvas is drawn)

(Deliberately no static DOM/script/version checks, and no unreliable error simulations.)

Performance & Scope — If vs. Actual

Metric	Old Habit (Hypothetical)	Actual PR	Improvement
Test count	8	3	−62%
Page loads	8	1	−87%
LoC	~230	~110	−53%
Runtime	~15s	~8.4s	−44%
Review rounds	2–3	Likely 1	✅

PR Communication (What I Wrote)

Sorry for the late PR! After your feedback on the HERE Maps tests (#1457), I wanted to apply those optimizations here before submitting:

Using a shared page to reduce page loads

Removing static element/script checks

Focusing on core functionality and precise assertions

Happy to adjust anything further if needed.

Why this works: it explains the delay, shows growth, lists concrete improvements, and stays collaborative.

Side-by-Side: Two PRs, Different Approach

HERE Maps PR (#1457): 7 tests → 7 feedback points → heavy refactor → final 3 tests.
Chart.js PR (#1489): Started with the optimized pattern → 3 focused tests → expecting minimal feedback.

Key Takeaways

Transfer learning matters. Yesterday’s feedback is today’s checklist.
Preventive design beats cleanup. Do less, better, earlier.
Test what users see, not implementation details.
Fail fast on config (API keys). It saves everyone time.
Communicate like a teammate. Own trade-offs and invite discussion.

PR-05 at Hacktoberfest: Optimizing HERE Maps E2E Tests and Handling PR Feedback

Anderson Yu-Hong Cai — Sun, 26 Oct 2025 07:46:12 +0000

Introduction

In open-source projects, writing code is only the first step — communicating with maintainers and iterating based on their feedback is where real growth happens.

This post documents my journey contributing to the Hackathon Starter project, where I implemented and later optimized HERE Maps E2E tests in Playwright following seven rounds of feedback from the project maintainer Yasharf.

Background

Project: Hackathon Starter
Task: Add E2E tests for the HERE Maps API page
Tool: Playwright
Challenge: The initial PR worked but was inefficient and needed significant refactoring

The First Version — Functional but Inefficient

My first submission included seven test cases covering everything from page elements to map rendering.

However, it had major issues:

Reloaded the page for every test (7× page loads)
Checked static HTML content (titles, buttons, scripts)
Contained repetitive logic
Took ~15 seconds to run

7 Key Feedback Points and Improvements

1. Use a Shared Page

“Use shared page to avoid reloading for each test.”

Replaced beforeEach with beforeAll to reuse the same page instance.

✅ Result: Page loads reduced from 7 → 1 (-86%).

2–3. Remove Static Checks

“Drop static page components check.”

“Drop script version check.”

Removed unnecessary tests for static HTML and script tags — E2E tests should focus on user behavior, not layout or boilerplate.

4. Verify Exact Values

“Verify hardcoded expected values.”

Replaced fuzzy range checks (e.g., 2–4 miles) with precise expected results (toBe(2.85)).

5. Skip Error Scenario

“Skip error scenario test.”

Removed artificial error interception — such cases belong in unit or integration tests, not end-to-end.

6. Reframe API Key Test

“Frame as tiles loading test.”

Since HERE Maps uses CDN caching, invalid API keys can still load tiles from cache (returning 200 OK).

Reframed the test to verify tile loading success instead of API key validity.

7. Technical Limitation — Map Details

“Check expected Seattle values (coordinates, markers, etc.).”

This was the hardest one.

The map variable is declared with const inside a script block in the Pug file — making it inaccessible from Playwright.

All attempts (window.map, DOM lookup, canvas inspection) failed.

In the end, I removed this test and explained the limitation clearly in my PR comments.

Final Result — Simplified and Efficient

Metric	Before	After	Improvement
Test cases	7	3	−57%
Page loads	7	1	−86%
Lines of code	190	66	−65%
Runtime	~15s	~9s	−40%

The remaining tests now focus purely on core functionality:

Map initialization and rendering
Distance calculation accuracy
Tile loading verification

Key Learnings

🎯 Define Clear E2E Boundaries

✅ Test user interactions and functional outcomes
❌ Don’t test static HTML or styling

⚡ Optimize for Efficiency

Use shared pages or contexts
Add listeners before page load
Remove redundant tests

📏 Prefer Precision

Use exact expected values instead of ranges

🧩 Handle Technical Limits Gracefully

Try multiple approaches
Avoid modifying production code unnecessarily
Communicate clearly when a limitation exists

💬 Communicate Like a Collaborator

A good PR response acknowledges issues, explains reasoning, and proposes alternatives —

“Happy to discuss alternative approaches.”

goes a long way in maintaining a positive contributor-maintainer relationship.

Conclusion

This contribution taught me that:

Quality over quantity — meaningful tests matter more than many tests
Performance is strategic — fewer reloads, faster runs
Communication is key — technical skill and collaboration go hand in hand

Open-source work isn’t just about code — it’s about learning to cooperate, explain trade-offs, and evolve with feedback.

Related Resources

PR-04 at Hacktoberfest: Implementing a Domain Validator for Terraform Provider

Anderson Yu-Hong Cai — Mon, 13 Oct 2025 21:55:02 +0000

Implementing a Domain Validator for Terraform Provider

Overview

This is my fourth pull request for the open-source project terraform-provider-validatefx.

The issue (#34) asked for a new is_domain validator to check domain name formats such as example.com.

The goal was straightforward: follow RFC 952 and RFC 1123 to ensure the validator accurately recognizes valid domain names while rejecting malformed inputs.

Implementation

The validator (domain.go) checks:

Overall length (max 253 characters)
FQDN support (trailing dot allowed)
Label validation (1–63 characters, no leading or trailing hyphen)
Character restrictions (letters, digits, hyphens only)
TLD rules (no all-numeric top-level domains)
Proper handling for null, empty, and unknown values

A simple regex was used for label verification:
^[a-zA-Z0-9]([a-zA-Z0-9-]*[a-zA-Z0-9])?$

Testing

A total of 24 test cases were added in domain_test.go, covering:

Valid domains (simple, subdomains, deep hierarchies)
Invalid domains (double dots, invalid chars, too long)
Edge cases (empty string, unknown values, FQDN)

The tests run in parallel and verify both pass and fail messages for accuracy.

Example

I also added a Terraform example (main.tf) containing nine test inputs — four valid and five invalid — showing how users can apply the new validator in real configurations.

Development Process

Created a feature branch: feature/domain-validator
Followed the same structure as existing validators (email, uuid)
Used go fmt for formatting and confirmed successful build and tests
Committed with clear messages:
- add domain validator
- add tests for domain validator
- add example for domain validator

What I Learned

Even though the task was similar to my previous validator work, it reinforced best practices in:

Following RFC standards
Writing consistent, well-tested code
Keeping PRs small and focused
Maintaining a clean commit history

Reflection

This contribution may seem minor, but it added another essential validator to the Terraform ValidateFX provider.

Step by step, each pull request builds experience, improves confidence, and strengthens understanding of open-source collaboration.

PR-03 at Hacktoberfest: Implementing a Credit Card Validator for Terraform Provider

Anderson Yu-Hong Cai — Mon, 13 Oct 2025 05:48:55 +0000

My First Open Source Contribution: Implementing a Credit Card Validator for Terraform Provider

How It Started

I recently found an interesting GitHub project — terraform-provider-validatefx, a Terraform provider that adds validation functions for HCL. One open issue (#37) asked for a credit card validator. It looked like a great opportunity to learn and make my first open-source pull request.

Understanding the Project

Before coding, I learned how a Terraform Provider works:

Terraform is an “Infrastructure as Code” tool by HashiCorp.
Providers are plugins that extend Terraform with new resources or functions.
ValidateFX provides validation helpers (like validatefx_email() or validatefx_uuid()).

Implementing the Validator

Each validator follows the same pattern:

Implement the frameworkvalidator.String interface.
Add descriptions.
Write ValidateString() for actual checks.

I implemented the Luhn algorithm to validate card numbers:

Remove spaces and hyphens.
Ensure 13–19 digits and numeric only.
Reject all zeros.
Perform Luhn checksum validation.

Writing Tests

I added comprehensive tests for:

✅ Valid cards (Visa, MasterCard, Amex)

✅ Formatted inputs (spaces, hyphens)

❌ Invalid cases (checksum, wrong length, letters, all zeros)

and edge cases (empty, null, unknown).

Technical Challenges

Line endings: Git detected false changes → fixed with core.autocrlf.
Integration tests: some Docker tests failed due to existing repo issues.
Unimplemented functions: the repo references validatefx_email() etc., so I focused only on the validator logic.

What I Learned

Technical:

Terraform Plugin Framework basics.
Luhn algorithm logic.
Cross-platform setup and test-driven development.

Collaboration:

Reading existing patterns before adding code.
Scoping work to one issue.
Communicating clearly in PRs.

Result

My PR included:

1 new validator file
1 complete test file
Full Luhn-based validation logic

Takeaways

This first contribution taught me both coding and collaboration.

If you want to start with open source:

Pick a small, well-defined issue.
Understand the project first.
Write clear tests.
Be patient — every issue is a learning opportunity.

PR-02 at Hacktoberfest: From Issue to Pull Request: Adding Windows Network Monitoring to SysMood

Anderson Yu-Hong Cai — Sun, 12 Oct 2025 05:16:53 +0000

Introduction

Recently, I contributed a Windows-specific network monitoring feature to the open-source project SysMood — a small system stats CLI that originally showed only CPU and memory usage.

This post documents how I went from opening an issue to submitting a pull request, including what I built, the challenges I met, and what I learned along the way.

PR: https://github.com/RayBreeze/SysMood/pull/8

Background

Project: SysMood (lightweight CLI system monitor)
Goal: Add Network Sent / Received (KB/s) to the main display
Environment: Windows (MinGW / g++, CMake)

Workflow

Opened Issue #7 proposing network monitoring for Hacktoberfest.
Created a feature/network-monitor-windows branch.
Implemented logic in network_monitor.h for quick testing.
Adjusted main.cpp display and “mood” thresholds.
Compiled, tested, and fixed bugs repeatedly.
Submitted the PR with clear description and Closes #7.

Technical Highlights

API Used: GetIfTable (from iphlpapi) to retrieve interface counters.
- Tried GetIfTable2 for 64-bit stats but reverted for broader compatibility.
Build: Requires linking -liphlpapi (CMake already handles this).
Filtering: Deduplicated interfaces by dwIndex and ignored inactive ones.
Overflow Handling: Added wrap-around logic since counters are 32-bit.
Sampling: Two readings (3s apart), rate = Δbytes / elapsed time.
Display: Unified units to KB/s with simple thresholds (0, 1, 10, 100, 1000).

Key Challenges & Fixes

Linking Error: Fixed by linking -liphlpapi.
Header Incompatibility: GetIfTable2 unavailable in MinGW → fallback.
Timing Bug: Corrected order of t0/t1 sampling and interval computation.
Unit Confusion: Clarified KB/s vs Kb/s and adjusted mood thresholds.

Lessons Learned

Windows IP Helper API quirks and MinGW compatibility details.
Importance of documenting quick build commands (g++ ... -liphlpapi).
Counter wrap-around is a real issue in performance stats.
Even small contributions benefit from clear issue planning and minimal PR scope.

Future Ideas

Support GetIfTable2 when headers allow (native 64-bit).
Move logic into src/network_monitor.cpp for cleaner structure.
Add an optional --network-debug mode for verbose output.
Consider smoother averaging for display (EMA or multi-sample).

Conclusion

This Issue → PR journey helped me understand Windows network monitoring in depth — from API details to linking traps.

For anyone planning similar contributions: start with a well-defined issue, test iteratively, and keep your PRs small and review-friendly.

PR-01 at Hacktoberfest: Google Maps E2E Testing — for hackathon-starter

Anderson Yu-Hong Cai — Thu, 09 Oct 2025 23:05:40 +0000

📝 Introduction

Recently, I took on an interesting open-source issue — writing end-to-end (E2E) tests for the Google Maps integration in the sahat/hackathon-starter project.

What seemed like a simple task turned out to be full of unexpected technical challenges, and through solving them, I gained valuable experience in both testing strategy and open-source collaboration.

🎯 Project Background

Hackathon Starter is a popular Node.js boilerplate that integrates various third-party APIs and services.

Its Google Maps example demonstrates how to embed an interactive map in a webpage with features such as:

Custom markers
Font Awesome icons integration
Info windows
Map controls
Boundary restrictions

The goal of Issue #1428 was to implement comprehensive E2E test coverage for this page.

🔍 Technical Exploration

Initial Analysis and Tool Selection

I began by analyzing the project’s existing test setup:

Test Framework: Playwright (already configured)
Environment setup: Dual .env configuration (.env vs test/.env.test)
Target page: /api/google-maps

Why Playwright?

Powerful browser automation
Rich element locator options
Network request interception
Cross-browser support

The First Major Discovery — `window.map.getCenter()` Problem

At first, I tried using window.map.getCenter() to verify the map’s center position.

However, it didn’t work as expected. After inspecting the source code, I found that the map object wasn’t accessible globally — meaning the test couldn’t directly call Google Maps API methods.

This discovery made me realize that many standard map testing approaches wouldn’t apply in this implementation.

🧪 Testing Strategy

Faced with limited API access, I designed a multi-layered testing strategy:

DOM-level validation – verify key elements and containers
Script validation – confirm Google Maps API is correctly loaded
Map tile detection – ensure the map visually loads
Custom marker testing – verify custom markers and info windows

🚫 The Challenge of Error Handling Tests

Simulating API Key Failure

At first, I almost overlooked the scenario where the app might fail to connect to the Google Maps API — because after setting up the environment, the connection always worked smoothly.

It wasn’t until one day, during a random network interruption, that I accidentally discovered the app had a built-in mechanism for handling API connection failures. That unexpected finding reminded me how easy it is to miss edge cases when everything “just works.”

To validate this behavior, I used Playwright’s request interception feature to simulate a failed API request:

await page.route('**/maps/api/js*', route => {
  route.abort('failed');
});

Why Complete Error Verification Matters

Initially, I only checked either the error title or message.

Later, I realized that complete error validation should check both — ensuring the app gracefully handles and communicates failures to users.

This experience taught me that covering as many runtime scenarios as possible in testing — even rare or “unlikely” ones — often reveals hidden robustness (or fragility) in the application.

🎛️ The Center Map Button Dilemma

The “Center Map” button turned out to be the most challenging test item.

Although the implementation worked correctly in the UI, the test couldn’t verify its effect because the map variable wasn’t globally exposed.

Current Testing Limitations

✅ Button existence

✅ Button visibility

❌ Unable to verify recentering behavior

Proposed Solutions

Modify source code to include window.map = map (global reference)
Alternative check: monitor map tile or CSS transform changes
Visual regression: compare before/after screenshots

📊 Final Test Results

After multiple iterations and optimizations, I implemented 7 comprehensive test cases:

Test Category	Coverage	Status
Page Load & Element Display	DOM validation	✅
Google Maps JS API Load	Script validation	✅
Map Initialization & Custom Elements	Functional verification	✅
API Error Handling	Failure scenario simulation	✅
Map Controls & Interactions	UI interaction testing	✅
Font Awesome Icons & Marker Position	Visual check	✅
Marker Click & Info Window	Content verification	✅

Coverage Highlights

🌐 Web fundamentals
🗺️ Map API integration
🚨 Error handling
🖱️ User interactions
🎨 Visual consistency

🎓 Key Learnings and Reflections

Technical Takeaways

Mastered Playwright: Advanced usage of element locators, network interception, and JS evaluation.
API Integration Testing: Learned alternative strategies when direct API access isn’t possible.
Error Handling: Realized the importance of verifying complete error content.

Project Management Insights

Task Decomposition: Broke down complex testing goals into smaller, achievable units.
Iterative Improvement: Started with basic tests and gradually expanded coverage.
Clear Communication: Documented limitations and proposed solutions clearly in GitHub issues.

Open Source Experience

Understanding the Codebase: Deeply reading existing implementation is crucial.
Respecting Original Design: Extend coverage without disrupting functionality.
Constructive Contribution: Don’t just point out problems — propose practical solutions.

🔮 Future Outlook

This experience gave me a deeper understanding of E2E testing. In future projects, I plan to:

Perform testability analysis before implementation
Document testing strategy rationale and known limitations
Continuously monitor and improve test coverage

📚 Conclusion

What started as a “simple Google Maps test” turned into a comprehensive testing journey covering API integration, error handling, and user interaction.

This process not only strengthened my technical skills but also deepened my appreciation for the open-source community.

Every technical limitation can be an opportunity for innovation.

Every debugging session can lead to meaningful learning.

If you’re interested in this topic, feel free to check out my contribution on GitHub:

PR: #1457
Issue: #1428 – Add E2E tests for Google Maps integration example

Reflections on Designing a Search Autocomplete System

Anderson Yu-Hong Cai — Sun, 05 Oct 2025 06:57:15 +0000

This week in our Toronto Study Group meeting, I shared Chapter 13 of "System Design Interview", which focuses on designing a search autocomplete system (like Google’s typeahead).

Instead of summarizing the whole chapter (you can see our study notes here), I want to highlight my personal takeaways.

Learning About Trie

Before this, I only had a very basic understanding of the Trie data structure. This chapter gave me a clearer picture of why it’s so often mentioned in system design.

What stood out to me:

Fast prefix lookups: a Trie lets you quickly jump down character by character until you reach the prefix node. It doesn’t matter if there are millions of queries stored — the lookup only depends on the length of the prefix.
Caching the top-k results: instead of searching the whole subtree every time, each node can keep a small list of the most popular queries. This uses more memory, but it makes the response feel instant to the user.
A simple idea, but powerful in practice: seeing how these small optimizations change a basic data structure into the backbone of something like Google autocomplete was eye-opening. It made me realize that system design isn’t about inventing new structures, but about applying and adapting classic ones to meet scale.

Even though I haven’t implemented a full Trie-based system myself, I now understand better how it connects to real-world needs: speed, caching, and user experience at scale.

System Design Insights

Over the past few weeks of reading about scalable system design, my mental model has shifted.

In the past, I used to think in simple terms: a frontend, a server, and a database — and that felt enough. But now I see how much more there is when you operate at massive scale.

Concepts like load balancers, shard managers, or even command queues are still a bit abstract to me. Sometimes I even ask myself: “Why not just one server to handle it all?”

But when I imagine systems serving millions of users, it becomes clear that a single server would never be enough. These architectural pieces — though complex — are the reason why large-scale systems can stay fast, reliable, and resilient.

Extra Reflections from Our Discussion

One thing I found fascinating: Google really does send a query for every single character you type.

It feels so seamless that you don’t even notice — but behind the scenes, that must be billions of requests.

We also talked about whether techniques like debouncing are used to reduce the server load. Maybe Google applies it, maybe not — but from the user’s perspective, it feels instant. That balance between user experience and server cost is really interesting.

Another fun idea we explored was the use of Main Trie + Side Trie:

Main Trie: stable, historical data
Side Trie: recent or trending queries Merging them ensures autocomplete feels both reliable and fresh. This kind of layered indexing was new to me and gave me a better appreciation for search system design.

Why It Matters

Right now, all of this is still a bit abstract since I haven’t built something at this scale.

But I see these patterns as mental models I can draw on in the future:

If I ever need to design a program that scales, I’ll know to think about indexing strategies, cache design, and data aggregation pipelines.
Even just learning about Trie reminded me that “classic” data structures can directly influence how real-world systems are built.

Closing

This was part of our Toronto Study Group’s weekly sharing.

I’m grateful for the chance to not only read but also explain my understanding, which helps me internalize the ideas better.

For anyone learning system design:

It’s okay if it feels abstract now. These concepts are seeds — they’ll grow into real tools once you face scaling challenges in practice.

I’m Joining Hacktoberfest 2025

Anderson Yu-Hong Cai — Mon, 29 Sep 2025 05:56:11 +0000

A few days ago, I decided to take part in Hacktoberfest 2025
! https://hacktoberfest.com/
Honestly, I’m both excited and confused — can I really push meaningful PRs? I have no idea. But that’s the beauty of Hacktoberfest: it’s about trying, learning, and finding a place where I can contribute.

In this post, I’ll briefly introduce what Hacktoberfest is, how the rules work, and share my current thoughts and hopes.

What is Hacktoberfest?

Hacktoberfest is an annual, month-long celebration of open source software. It’s supported by DigitalOcean, Major League Hacking, and other partners. The goal is simple but powerful:

Encourage more people to get involved in open source.
Grow the community by lowering the barrier to entry.
Reward contributors for their efforts.

How to Join

Register: Sign up on hacktoberfest.com with your GitHub (or GitLab) account.
Find projects: Look for repositories that have the hacktoberfest topic or issues labeled as “good first issue” / “help wanted.”
Make Pull Requests: During October, submit PRs to participating repositories. Contributions don’t need to be huge — fixing typos, improving docs, or adding small features all count.
Reach the goal: Typically, 6 accepted PRs are required to complete Hacktoberfest (subject to the 2025 rules).
Get rewards!!!

My Strategy

To make the most out of Hacktoberfest 2025, here’s my plan:

Prepare now: practice Git/GitHub workflows, and warm up with small contributions.
Find interesting projects: look for ones related to technologies I use or topics I care about.
Document the journey: I’ll write about my attempts, successes, and even failures. I hope writing blogs can be a way to push myself, haha
Join the community hopefully: I have joined the Hacktoberfest Discord group. I found that there are some interesting repos there, and hopefully, I can find some repos and people I can work with.

Final Thoughts

Hacktoberfest 2025 feels like a big challenge for me. I don’t know yet if I’ll succeed, but I do know this:

Every attempt is a learning experience.
Rejected PRs aren’t failures, they’re feedback.
The important thing is to try, explore, and connect with the community.

So here I go — diving into Hacktoberfest, hoping to discover cool projects, contribute in meaningful ways, and enjoy the journey.

If you’re also joining Hacktoberfest, let’s connect and encourage each other along the way!

Release 0.1 - Go?

Anderson Yu-Hong Cai — Sat, 13 Sep 2025 08:01:20 +0000

In OSD600 2025 Summer, Release is the project we will spend most of our time on. It is a CLI tool that can generate a text file for a repo, so we can send it to an LLM. This way, it preserves not only the content of the files but also the structure of the repo.

The first thing I need to decide is which language I would like to use.

So far, I’ve given myself a challenge—Go might be a good choice.

The first thing I considered is that I would like the user not to worry about the environment. They should just open the command line, type the command, run it, and get the result. I don’t want them to have to install any unnecessary software.
→ That’s why C++ might also be a good choice.

However, ChatGPT gave me another idea: how about Go?

Go can also compile code into an .exe file, so people can use it directly. Also, I am eager to learn backend knowledge, and Go is one of the languages I would like to explore.

So, that’s the story so far.

I installed Go and finished my first tiny program hello-go, and started learning how to write in it:

package main
import "fmt"

func main() {
    fmt.Println("Hello, Go + VS Code!")
}

Yeah, just my first try.
I guess I need some practice before I really start writing Release, and I hope I can push myself to do more.

See you next time~

Starting My Open Source Journey

Anderson Yu-Hong Cai — Fri, 05 Sep 2025 06:22:13 +0000

This post marks the beginning of my open source journey. If I am lucky, I may become involved in OSD600 at Seneca, which could make this path even more possible. But either way, I feel it is time to start.

Who am I?

I’m Anderson, someone who is always eager to explore new worlds—especially the ones that aren’t easy. That’s why, when I worked in finance, I studied Financial Engineering. I became a data analyst even before I officially held the title. Now, I am working hard to become a developer.

That is the reason I am here.

Why open source?

Open source has always felt intimidating to me. Even now, I hesitate to dive in. Every time I research repositories, it seems like everyone is doing something cutting-edge, and I often feel lost.

To me, open source is a milestone—a sign that you are becoming a real developer. That’s why I want to understand how to get involved. I want to know what it really is. I want to see the world from that perspective.

I know I will need guidance. It’s like trying to climb the highest mountain: you must walk on your own, but without learning from others, you will either give up or fail. The journey requires both independence and support, and I don’t want to face it unprepared.

What I would like to get

So far, I am not familiar with open source—the environment, the way people collaborate, the culture, the community news. I want to build a closer connection with it. That is the first thing I hope to achieve this term.

The second thing I want to discover is: what can I do for the community? Can I contribute something? How do I find the right tasks and actually make a contribution?

And finally, I want to explore who I can become through this journey. Up to now, I’ve been learning many things, but I haven’t decided where to go deeper. What am I good at? What do I truly enjoy? What does the community need? I need to find these answers so I can focus, go deeper, and eventually find my own way.

Open source has always been on my mind, and I believe this is the right time to begin.

Search for the repo trend

Deciding which repo to introduce is really difficult. I found one repo that tries to build an AI-oriented quantitative investment platform, which matches my financial background. I also saw projects aiming to build AI agents, which is a popular topic nowadays. But finally, I chose the one below, which attracted me the most.

PowerToys

PowerToys is a Windows system utilities project that includes many interesting tools like Color Picker, FancyZones, Text Extractor, and other cool small utilities. It also has a long history.(Wiki - Microsoft PowerToys)

One of the reasons I chose this repo is because the project is written in C# and C++. After learning a lot of C++, I wanted to find a place where I could actually use it. Also, these tools are really cool. Snipping Tool is the one I use the most, and I was so excited when I discovered that it originally came from PowerToys(Wiki - Snipping Tool). I guess this shows how open source can improve the world.

So, this is my first blog, and I hope it gives a brief idea of who I am, what I am doing, and what I have explored so far. Even though it’s just a tiny step, it might turn out to be an important one for me.

You don’t have to be great to start, but you have to start to become great. Let’s keep going together!

DEV Community: Anderson Yu-Hong Cai

PR-06 at Hacktoberfest: Applying E2E Testing Lessons to Chart.js + Alpha Vantage

Introduction

Background

The Temptation I Skipped

Applying the Lessons — From the Start

1) Shared Page Pattern

2) Focus on Core Functionality

3) Precise Data Assertions

4) API Key Strategy

Final Test Structure

Performance & Scope — If vs. Actual

PR Communication (What I Wrote)

Side-by-Side: Two PRs, Different Approach

Key Takeaways

Links

PR-05 at Hacktoberfest: Optimizing HERE Maps E2E Tests and Handling PR Feedback

Introduction

Background

The First Version — Functional but Inefficient

7 Key Feedback Points and Improvements

1. Use a Shared Page

2–3. Remove Static Checks

4. Verify Exact Values

5. Skip Error Scenario

6. Reframe API Key Test

7. Technical Limitation — Map Details

Final Result — Simplified and Efficient

Key Learnings

🎯 Define Clear E2E Boundaries

⚡ Optimize for Efficiency

📏 Prefer Precision

🧩 Handle Technical Limits Gracefully

💬 Communicate Like a Collaborator

Conclusion

Related Resources

PR-04 at Hacktoberfest: Implementing a Domain Validator for Terraform Provider

Implementing a Domain Validator for Terraform Provider

Overview

Implementation

Testing

Example

Development Process

What I Learned

Reflection

PR-03 at Hacktoberfest: Implementing a Credit Card Validator for Terraform Provider

My First Open Source Contribution: Implementing a Credit Card Validator for Terraform Provider

How It Started

Understanding the Project

Implementing the Validator

Writing Tests

Technical Challenges

What I Learned

Result

Takeaways

PR-02 at Hacktoberfest: From Issue to Pull Request: Adding Windows Network Monitoring to SysMood

Introduction

PR: https://github.com/RayBreeze/SysMood/pull/8

Background

Workflow

Technical Highlights

Key Challenges & Fixes

Lessons Learned

Future Ideas

Conclusion

PR-01 at Hacktoberfest: Google Maps E2E Testing — for hackathon-starter

📝 Introduction

🎯 Project Background

🔍 Technical Exploration

Initial Analysis and Tool Selection

The First Major Discovery — window.map.getCenter() Problem

🧪 Testing Strategy

🚫 The Challenge of Error Handling Tests

Simulating API Key Failure

Why Complete Error Verification Matters

🎛️ The Center Map Button Dilemma

Current Testing Limitations

Proposed Solutions

📊 Final Test Results

Coverage Highlights

The First Major Discovery — `window.map.getCenter()` Problem