Hi, I’m Parker 👋

Full-stack developer with a background in finance and statistics. Check out my GitHub for more about me. This blog is mainly where I keep my tech notes and thoughts, and I’d be happy if you find something useful here.

Migrating to Hugo

I moved my blog to Hugo. I’ve had some free time in the gap between graduating and landing a job, so I finally got around to something I’d been putting off for a while. Why migrate at all A few things pushed me toward it. A couple of years into the Computer Programming and Analysis program, I’d seen enough tools and tradeoffs that “run a lighter stack” stopped being an abstract idea and turned into an actual plan. NotionNext is a good project. I’ll get into why it stopped working for me, but it’s more machinery than a personal blog needs. ...

2026-09-10

OSD600 Release 0.4 Part 3 - Reflecting

Intro My original goal for Release 0.4 was to contribute real code to a large open-source project related to finance. I completed that goal by working on Actual Budget, which is a fairly big project with around 23k stars. Thoughts About the Future Now that I understand the workflow better, I hope I can eventually try adding a feature or modifying core code in a large codebase. I’m also paying attention to bigger finance-related libraries such as QuantLib, and maybe one day I will be able to contribute there as well. ...

2026-09-10

OSD600 Release 0.4 Part 2 - Processing

🔔 Prelude: Me working with a big project… Wait, me? Starting the Contribution This week I finally moved from planning into actually contributing. I decided to work on Actual Budget again, and honestly, I was kinda nervous because this repository has 23.6k stars, real users, and an active core team. I chose a TypeScript issue related to incompatible type definitions (https://github.com/actualbudget/actual/issues/6290). In short, the Query type was missing a few methods and caused type errors inside the API package. ...

2026-09-10

OSD600 Release 0.4 Part 1 - Planning

🔔 Prelude: Tough week, and it will get tougher Planning for the release 0.4 Last week, we wrapped up some final tasks for Release 0.3, and now I’m officially moving into the work for Release 0.4. I mentioned earlier that I was still waiting for my PR for Release 0.3 to be merged. Fortunately, right after the lecture, someone from Opsimate finally reviewed my changes and gave me feedback. The response time was a bit slow, but at least things are moving again. ...

2026-09-10

OSD600 Lab 9

🔔 Prelude: Rocket lift off Answering Main Lab Questions Originally I had a reflection section for this blog, but my Professor provides some wonderful questions for me to share my experience and thoughts, so, my reflection has been melted into my answers. I hope you can find useful information directly in there. Which release tool and package registry did you choose? Provide links to everything you mention. Go has it’s unique release system — basically, if I init my module locally, push to the GitHub, have a right git tag version, and finally click the “Request” on https://pkg.go.dev/example.com/my/module … then, done, I don’t need to handle rest things, the module will be indexed on the official module platform, and anyone should be able to go install my module. So convenience. What was the process for creating a release? Be detailed so that other developers could read your blog and get some idea how to do the same. ...

2026-09-10

OSD600 Release 0.3 Part 2 - Fixing bugs

🔔 Prelude: Bugs in the middle of the way OpsiMate bugs fixing During the development of the new Coralogix integration, I ended up discovering two UI bugs — because of course things like this always happen, right? The first issue was a missing icon. This one was extremely small: a one‑line fix in a single file. Honestly the PR felt almost too tiny. Fortunately, another bug appeared at exactly the right time. This one involved a UI element that refused to trigger properly, which required a bit more investigation and work. Missing dog In my first blog post, I mentioned that OpsiMate includes a DataDog integration. Ironically, the dog went missing ...

2026-09-10

OSD600 Release 0.3 Part 2 - Adding features

🔔 Prelude: API document reading — totally as hell Coralogix Integration What is it? According to the official description, Coralogix provides “real-time insights and trend analysis for logs, metrics, and security data with no reliance on storage or indexing.” In simpler terms, it is essentially a real-time server monitoring and observability service. Coralogix helps track logs, visualize metrics, and detect anomalies without requiring developers to manage complex storage systems. For projects with active deployments, this kind of integration makes debugging and performance monitoring much easier. ...

2026-09-10

OSD600 Release 0.3 Part 1

🔔 Prelude: I have a bad feeling about this: once again, I find myself stuck trying to choose the right project. Main Content Still WIP At the end of this week, I haven’t submitted my first PR yet. Most of my time went into searching for a suitable open‑source project, and my plan is to update this post again after I finally publish my first PR. Since I previously mentioned that I want to contribute to a repo related to $finance$🤑, I spent a good amount of time exploring that topic. Here are some projects currently on my list: ...

2026-09-10

OSD600 Lab 8

🔔 Prelude: Another helpful hand, and more Main Content This week I worked on GtHub Actions CI for my Go project, added a Go linter, and wrote tests for a partner’s repository. The lab overlapped with my Cloud Computing (CCP) course, so the CI work fit well with what I’m learning there. Reflections I’m also taking CCP, so CI-related tasks felt practical. I had already added CI in a previous lab (I thought “why not?” while I was adding tests), so I extended that work here. Adding a Go linter was new to me (I know the eslint), but following the golangci-lint repo made it straightforward. Answering questions How did you set up your GitHub Actions CI Workflow? What did the YAML for this workflow look like? I searched “How can I set up my GitHub Actions CI Workflow?”, as just same as the question title. Then, I found a Go workflow templates by clicking the action button in GitHub. The workflow builds and tests on push and pull requests to main and dev. Super straightforward again. ...

2026-09-10

OSD600 Lab 7

🔔 Prelude: Code everywhere, tests everywhere, tokens everywhere, budget nowhere Main Content Testing commit: https://github.com/BHChen24/repo2context/pull/36/commits Answering Lab Questions Which testing framework/tools did you choose? Why did you choose them? Provide links to each tool and briefly introduce them. Since I my project is written by Go, so I just use the go test for testing: https://pkg.go.dev/testing As described on the official page, it “provides support for automated testing of Go packages.” It’s also a part of the standard library, so it can be used directly when the Go environment is set. At the beginning, I put the test files in another folder just like what I used to do with Typescript testing, but then I found it’s better to just place them beside the source code as a standard way in Go projects. Use go test [target folder/file] to run tests, and use go test -cover [target] to see the test coverage How did you set them up in your project? Be detailed so that other developers could read your blog and get some idea how to do the same. See above~ :) What did you learn while writing your test cases? Did you have any “aha!” moments or get stuck? I felt writing tests is painful. I have to consider each possible way to trigger an error, which is literally difficult to cover all the cases - also means I have to fully understand the tested target (mostly functions in Go). Always, when I hand my tests to AI for reviewing, it will give more comprehensive test cases, like missing values, edge cases, input format, etc. I did learned a lot. But I also begin to doubt that I can really memorize all useful cases. There are at least 10 to 15 cases for each function, even though there are some common cases I can reuse. Maybe a test cases document is the truly practical tool for the testing. I also made good use of “given-when-then” pattern for writing the tests. (See https://github.com/BHChen24/repo2context/blob/main/pkg/scanner/scanner_test.go) It’s super helpful for planning the test process. Did your tests uncover any interesting bugs or edge cases? No for this time. But I am curious about why I didn’t find any bugs… Maybe more tests will reveal some, or I need more time to review my tests. What did you learn from this process? Had you ever done testing before? Do you think you’ll do testing on projects in the future? Actually I have done the tests in the Lab6 (See https://github.com/BHChen24/repo2context/blob/main/pkg/tokenCounter/tokenCounter_test.go) At that time, I just simply thought that, “oh, since I will develop a new feature, maybe developing the tests at the same time is a good idea,” and then I created the tests beside it. I think doing the testing is a standard step for developing reliable applications, so I definitely will do that in my future projects. But I am actually feeling weird… Since each test case can be different, I’d like to say I’ve learned a lot from past tests, but for the next test I may still go blank with the new situation… Even though I know how to apply the test pattern, most of the time I still need to find some references to implement the test logic. Is it normal or not? Experience with Speckit As the additional content, I’d like to mention the new AI related tool called **Speckit, built by GitHub.** ...

2026-09-10