JayWilson.zip

How I Automated JABA's Developer Update Posts

2026-03-15T00:00:00Z

JABA has three active repos: iOS, backend, and website. Meaningful work ships across all of them every two weeks, and users and newsletter subscribers deserve to know what changed. Consistent content about what's being built matters for SEO too. The problem was that writing updates kept falling off my plate. I'd miss a cycle, feel behind, and the gap would grow.

I built a pipeline to fix that. It pulls from all three repos, collects merged PRs and commits, and turns them into a published blog post every two weeks without me writing anything.

What the Pipeline Does

A GitHub Actions workflow runs on odd-numbered Thursdays. It collects recent merged PRs and commits from all three repos, hands them to Claude with a carefully defined prompt, validates the output, and opens a PR on the Hugo site for my review. I approve it, Cloudflare builds, and the post goes live. Newsletter content falls out the other side automatically.

Here's the full flow:

flowchart TD
    A[GitHub Actions Cron] --> B[Collect Changes]
    B --> C[Generate Post with Claude]
    C --> D{Validate}
    D -->|Fail| E[Pipeline Halts]
    D -->|Pass| F[Open PR for Review]
    F --> G[Approve and Merge]
    G --> H[Cloudflare Build]
    H --> I[Newsletter Draft Ready]

The Five Scripts

The pipeline is five Node.js scripts chained with piped I/O. Each reads from stdin and writes to stdout. Every script is independently testable, and failed runs leave intermediate files in /temp so it's easy to see exactly where things broke.

Here's how the repo is structured:

automated-dev-updates-newsletter/
  ├── config/
  │   ├── frontmatter-template.yaml
  │   ├── repos.json
  │   └── system-prompt.md
  ├── output/
  │   └── pending-newsletter.md
  ├── scripts/
  │   ├── collect-changes.js
  │   ├── create-pr.js
  │   ├── fetch-newsletter-content.js
  │   ├── generate-post.js
  │   ├── run-pipeline.js
  │   ├── validate-post.js
  │   └── write-hugo-file.js
  ├── state/
  │   └── last-run.json
  └── temp/

1. Collect Changes

This script hits the GitHub API via @octokit/rest and fetches merged PRs from all three repos within the lookback window, plus commits from the iOS repo specifically. Two filtering passes happen here.

Dependency noise removal: Anything from Dependabot or matching chore(deps) patterns gets dropped. Real changes, but meaningless to users.

Deduplication: Commits that belong to a merged PR are already represented by that PR. Including them again would double-count the work and give Claude redundant signal.

What comes out is a clean JSON object with the actual meaningful changes.

2. Generate Post

The filtered changeset goes into a user message, and the system prompt (which lives in config/system-prompt.md, not hardcoded) defines JABA's voice, the output structure, and hard rules about what not to include.

Claude writes a 300 to 600 word post as a single cohesive narrative, not a bulleted list of changes. The goal is something a non-technical user can read and understand, not a changelog.

3. Validate

This is the most opinionated part of the system.

The validator checks five things before the post can proceed:

Minimum word count: a post that's too short probably missed something
No commit SHAs: Claude sometimes copies them verbatim from the input
No PR numbers: same problem
No internal repo names: users don't need to know how the codebase is organized
No speculative language: phrases like "coming soon", "planned feature", and "in development" are signs Claude invented roadmap items that don't exist

const MIN_WORD_COUNT = 100;

const HALLUCINATION_PHRASES = [
  "coming soon",
  "planned feature",
  "in the future",
  "will be available",
  "upcoming feature",
  "roadmap",
  "we plan to",
  "we intend to",
  "we will be adding",
  "stay tuned",
];

// ...

  // 1. Minimum word count on body
  const wordCount = countWords(body);
  if (wordCount < MIN_WORD_COUNT) {
    fail(`body is too short (${wordCount} words, minimum is ${MIN_WORD_COUNT})`);
  }

  // 2. Commit SHA patterns
  const shaMatch = body.match(/\b[0-9a-f]{7,40}\b/i);
  if (shaMatch) {
    fail(`body contains what looks like a commit SHA: "${shaMatch[0]}"`);
  }

  // 3. PR number patterns
  const prMatch = body.match(/#\d+/);
  if (prMatch) {
    fail(`body contains a PR/issue number: "${prMatch[0]}"`);
  }

  // 4. Internal repo names
  const internalNames = getInternalRepoNames(reposConfig.source_repos);
  for (const name of internalNames) {
    const pattern = new RegExp(
      `\\b${name.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")}\\b`,
      "i"
    );
    if (pattern.test(body)) {
      fail(`body contains internal repo name: "${name}"`);
    }
  }

  // 5. Hallucination phrases
  const bodyLower = body.toLowerCase();
  for (const phrase of HALLUCINATION_PHRASES) {
    if (bodyLower.includes(phrase)) {
      fail(`body contains hallucination signal phrase: "${phrase}"`);
    }
  }

  // All checks passed — pass JSON through to stdout
  process.stdout.write(JSON.stringify(input) + "\n");

Any failure halts the pipeline entirely. The partial output gets saved to /temp for debugging, but nothing moves forward. Validation runs before the PR is created, so bad output never reaches reviewers at all.

4. Write Hugo File

The validated post gets wrapped in TOML front matter and saved to the correct path in the Hugo content structure. Date, title, and slug are derived from the run metadata.

5. Create PR

The file is committed to a new branch on the Hugo site repo and a PR is opened with me tagged as reviewer. Nothing publishes automatically. I get a notification, check the post, and can see a live Cloudflare preview of exactly what it'll look like before approving anything.

After the Merge

When I merge the PR, Cloudflare kicks off a new site build and the post goes live. At the same time, a webhook on the Hugo repo fires a repository_dispatch event back to the pipeline repo.

A second GitHub Actions workflow picks that up, strips the TOML front matter from the published file, and writes the clean post body to output/pending-newsletter.md. Ready to paste into Loops.so with no reformatting needed.

name: Notify Internal Tools on Changelog PR Merge

on:
  pull_request:
    types: [closed]

jobs:
  notify:
    if: github.event.pull_request.merged == true && startsWith(github.event.pull_request.head.ref,
'changelog/')
    runs-on: ubuntu-latest

    steps:
      - name: Get merged file path
        id: get-file
        env:
          GH_TOKEN: $
        run: |
          FILE_PATH=$(gh api \
            repos/$/pulls/$/files \
            --jq '.[0].filename')
          echo "file_path=$FILE_PATH" >> "$GITHUB_OUTPUT"

      - name: Fire repository_dispatch to jaba-internal-tools
        env:
          GH_TOKEN: $
        run: |
          jq -n \
            --arg fp "$NaN" \
            '{"event_type":"changelog-pr-merged","client_payload":{"file_path":$fp}}' | \
          gh api repos/cctPlus/jaba-internal-tools/dispatches \
            --method POST \
            --input -

The two-phase design is intentional. last-run.json updates immediately after a successful pipeline run so the next collection window is correct. pending-newsletter.md only updates after the PR merges, so the newsletter always reflects human-approved content, not just whatever Claude generated.

Config-Driven, Not Code-Driven

Adding a new source repo should not require touching pipeline logic. The repo list lives in config/repos.json. The system prompt lives in config/system-prompt.md. Adding a new source is a one-line config change.

The system prompt took iteration to get right. It defines voice, tone, what to include, what to avoid, and explicit output constraints. It's doing a lot of the work that keeps the output clean, ahead of the validation step.

The Cross-Repo Webhook Bridge

The Hugo site repo can't directly trigger workflows in the pipeline repo because they're separate repositories. Rather than share secrets across repos, there's a minimal workflow on the Hugo site side that fires a repository_dispatch event on merge. The pipeline repo listens for that event type and handles it.

Each repo only knows its own side of the contract. No credentials need to be shared across repo boundaries.

Wrapping Up

The pipeline runs every two weeks whether or not I think about it. I get a PR notification, review a Cloudflare preview, hit merge, and the post is live. The newsletter content is already waiting to be pasted.

The only step I kept for myself is the approval, and that's on purpose. Everything else was just friction between shipping and communicating.

How to run Swift Tests Serially across files

2025-11-09T00:00:00Z

I'm going to list the guide first and then why I needed to do this.

NOTE

This is using Swift Testing

Guide

Create a main test Suite and mark it as @Suite(.serialized)

import Testing

@Suite(.serialized)
struct MainTestSuite {
}

Make an extension on the struct and put your other Suite in side it and also mark it as @Suite(.serialized)

extension MainTestSuite {
    @Suite(.serialized)
    struct SubTestSuiteA {
        @Test
        func testA() {
            #expect(true)
        }
    }
}

Repeat as you need to for all your suites

Run your tests and your tests should ruin serially. In my testing, they are ran in alphabetical order.

Why I needed this

I am working on FetchKit, a user feedback system for my apps (and maybe yours), and I need to write tests for the repositories, which is what acceses the databases. Since I am testing reading and writing from databases, I want to just use one test database. At the end of each test, I clean up the databse and erase everything so if tests are running parallel the data the test expected to be there could be wiped. DEFINITELY DO NOT WANT THAT.

A lot of the examples I saw online showed:

import Testing

@Suite(.serialized)
struct MainTestSuite {
    @Suite(.serialized)
    struct SubTestSuiteA {
        @Test
        func testA() {
            #expect(true)
        }
    }
    @Suite(.serialized)
    struct SubTestSuiteB {
        @Test
        func testB() {
            #expect(true)
        }
    }
}

This is fine and ultimately nothing wrong with it, except for the file gets really massive, and I'm not a fan of that. I tried asking AI and well that was a bust, so I just tried writing the "sub" test suites in extensions and it worked.

What is FetchKit?

FetchKit is a feedback management system that helps developers collect, organize, and act on user feedback directly from their applications. Instead of relying on scattered feedback from app stores, support emails, and social media, FetchKit lets you capture feedback where it matters most: inside your app.

If you're interested in FetchKit, then make sure to join the waitlist, and you'll get weekly updates with the chance to sign up for the beta.

Journey to $1000 MRR: Month 1 recap

2025-10-31T00:00:00Z

At the beginning of October, I set out on a lofty goal, $1000 MRR by this time next year (October 2026). I meant to make a blog post, but I forgot in classic Jay fashion.

My starting stats:

App	Subscribers	MRR
iHog	28	$28
Camp Notes	1	$2
Coffee_	0	0
Universe Converter	0	0

October

To help achieve the MRR, I decided to make smaller goals each mopnth that will hopefully help me. For October those were:

Redesigning and fully implementing RevenueCat paywalls in iHog
Asking for reviews in Camp Notes and write 3 blog posts to help SEO to the website
Adding analytics and adjusting the paywall view in Universe Converter
Adding analytics and RevenueCat to Coffee_
Get to $50/MRR

Here is what I ended up doing.

iHog got exactly what I implemented and I am running a pricing test in the US to see if I can charge a higher price.
Camp Notes ratings and reviews are being asked for, a new paywall is being experimented with, which you can read here. I did not end up writing the 3 blog posts.
Universe Converter did not get a hard paywall or a RevenueCat paywall because I decided to just keep it as a tip jar. There is not anything I feel comfortable with charging.
I ended up not working at all on coffee_ 🙃 I ran out of time.

What did I end with stats wise?

App	Subscribers	MRR
iHog	42	$30
Camp Notes	4	$10
Coffee_	0	0
Universe Converter	0	0

I am sitting at $40 MRR, which means I am like $10 short of my goal, but the subscriber numbers increased which is good and the right direction.

What's next?

Well I started working on a new app JABA that will take a lot of my focus away from Coffee_ and Universe Converter. I just don't see those two apps being something I really want to work on long term. JABA is a revamp of PocketBudget that I worked on earlier this year. I just wanted to start from scratch and with no pressure from existing baggage.

iHog

Add in a free trial to the monthly product and see if that moves subscriptions
Figure out what is causing all the crashes

Camp Notes

Write at least one blog post
Improve load times on the Campground List
Start working towards Scout Badges, which are in app achievements

Here's to November and see if I can keep the needle going up!

Camp Notes's First Paywall Experiment

2025-10-16T00:00:00Z

Today, I started my first paywall experiment for Camp Notes. I don't really have enough users to make it worth it, but I want to try it out anyway. I am comparing a fixed footer always showing the package buttons with a toggle for a free trial to one long scroll with the free trial option as a button like the non trial options.

What I'm hoping to learn is if users are more likely to convert if they have to scroll or not. I'm also curious if people will switch to the free trial version at all.

Ideally this experiment is ran until at least 35 users have gone through it, but I think that'll take a really long time considering I've only had 4 users start a trial since I launched on September 6th. If I haven't hit 35 users by December 15th (2 months from now), then I'll stop the experiment and choose the option that had slightly better results even if it's not statistically significant.

NOTE

The prices in this screen are the placeholders that RevenueCat generates in their app so I can preview the paywalls.

This experiment is part of my goal to hit $1000 MRR by October 2026. You can follow that journey on YouTube, Instagram, or right here on my blog.

Current MRR: $33
Goal MRR: $1000
Months left: 11

Camp Notes Won a OneSignal Boost Award at Shipaton

2025-10-13T00:00:00Z

I entered Camp Notes into RevenueCat's Shipaton hackathon and placed 5th in the OneSignal Boost Award category, winning $5,000 and recognition in their blog post. I'm really excited about this result and glad I decided to participate.

For context, Camp Notes is a camping app that lets you record details about individual campsites within campgrounds. You can track GPS coordinates, amenities, add photos, and rate your experiences. The idea came from getting into camping this year and wanting something more structured than a shared Apple Note.

What is Shipaton

Shipaton is RevenueCat's hackathon for indie developers. The goal is simple: ship a brand-new app to the iOS, Android, or Mac App Store using the RevenueCat SDK.

There were multiple award categories including Best Overall App, Build in Public, and category-specific awards for integrations like OneSignal, Adapty, and others. Over 800 entries were submitted, which made the competition pretty intense.

The Submission

Once I proved Camp Notes was feasible, the entire plan became submitting it to Shipaton. I started development around when the hackathon kicked off, and everything was aimed at having something ready to enter.

I highlighted the core features in my submission: site-level tracking with GPS coordinates, the 1-5 star rating system, photo documentation, and community data sharing. I also emphasized the collaboration features I was planning to add, which was the original inspiration for building the app.

I targeted the OneSignal category specifically because I wanted the best chance to win something. I knew notifications and in-app messages would be part of Camp Notes eventually, so implementing OneSignal for the hackathon made sense.

Using OneSignal

OneSignal handles several things in Camp Notes. Initially, I used it to collect emails for the waitlist and notify users when the app launched. Now it powers in-app messages for updates, notifications when subscription trials are ending, and both transactional and marketing emails.

When a user registers, they get a welcome email encouraging them to use the app again. It's straightforward stuff, but it works and sets up the foundation for more sophisticated messaging down the road.

The Competition

Placing 5th out of over 800 entries feels really good. The judging criteria included functionality, design, potential impact, and how well the RevenueCat SDK was integrated, so there was a lot to get right.

I learned that I should think more strategically about categories if I do this again. The Build in Public award, for example, might have been a better fit if I'd actually planned for it and documented the process more publicly.

I'd absolutely do this again. The competition pushed me to ship faster and think more carefully about how I could position what I was building.

What's Next

The app's roadmap stays the same. I'm focused on visit collaboration, gamification with user rewards, advanced filtering and sorting, and API integration to populate the database with existing campground data.

I'm aiming for 10+ visits recorded per month by next year and building out the features that make Camp Notes actually useful for people who camp regularly.

Thanks to RevenueCat, OneSignal, and the other sponsors for running the hackathon. It was a great experience, and I'm really happy with how it turned out.

Camp Notes v1.0.0 is now shipping

2025-09-12T00:00:00Z

After some back and forth, Apple approved Camp Notes 🎉

The last reason it was not approved was because subscriptions needed an account, which I challenged and then it was approved.

Here are some stats since launching:

Downloads: 23
Impressions: 778
Trials started: 1
Crashes: 0
Visits made: 3

Here is how I am interpreting these numbers:

My keywords need to be adjusted for more impressions. Let's be honest "Camp" is probably overloaded, so I need better keywords for better search.
I need better marketing. I need to write more blog posts on campnotes.app to drive more organic content. I need to create social media content to get a wider audience. There's just a lot of marketing I can do.
There just isn't enough campgrounds in the app to entice users to add visits. I prioritized being able to add camp grounds and getting the app out without making sure there were campgrounds in the app that people could add visits to. I think this is making the app seem bare. After v1.1.0 is out, I'm going to work on getting more data into the app.
It's been 1 week. It's been 1 week so I still just need to chill and focus on making a good app.

It's time to work on RevenueCat's Shipaton materials though.

Waiting for Review: A Camp Notes Update

2025-09-03T00:00:00Z

It's been 6 App Store submissions, and I still have not gotten past the review process. I have been rejected for the following reasons:

Login and Signup views are not usable on an iPad.
Legal links in the paywalls didn't work
Login is not working properly (3 times)

The first 2 submissions were easy mistakes that I should've seen coming, but the last one has been like hell trying to debug. I figured out I wasn't clearing the auth token between login and signup attempts so it would go stale and not allow any logins. I also had TestFligth feedback about the keyboard not showing on the Login view from settings, so I made sure to submit that fix as well. Hopefully 6th time is the charm and I can release on September 15th.

I still have the waitlist open, so if you're interested in trying out Camp Notes before it's released, please sign up here.

I'm starting to work on v1.1.0 which will include the following:

Ability to add a visit without a campground or site
Notifications to allow for trial ending and subscription notifications
What's new system

I finally submitted a side project

2025-08-27T06:41:00Z

As you can tell from my YouTube channel or post here, I like to start lots of projects, but I am not the best at finishing them. This year Shipaton was announced and I had big plans to finish PocketBudget for it, but I'll be honest that was way too much work to rush through and finish, so I pivoted to a new project, Camp Notes.

Camp Notes started because my wife and I got into camping this year. We wanted to track the campsites we've been to, what amenities they had, that kind of stuff. Everyone in the PNW seems to camp so we figured we'd try it out. We could have just used a shared Apple Note, but that would be messy and unstructured. I wanted to capture specific things like ratings and photos showing how much space there is for tents. So I thought "let me see what I can build in 2 weeks."

Within those two weeks, I was able to get a basic version of the app done where I could add a campground, a site, and record a visit. I figured I could take it a couple steps further after that to include photos and sharing of a card about the visit. After a few more weeks of development, I had a v1.0.0 release.

What Made This Different

One thing that really helped me throughout this process was using Claude Code. I leaned on it for designing and architecting features, and it helped me stay focused and move faster.

The external deadline from Shipaton also really helped me figure out what was and wasn't necessary. For example, I wanted to add Sign in with Apple support, but I didn't want to waste time on that since users can use email and password just fine. I made a note to add it later when I implement collaboration features, but it wasn't needed for v1.

Staying Focused on Shipping

Something that really helped was not getting derailed by feedback right before shipping. A couple of days ago I got TestFlight feedback asking why a site number was necessary for logging visits. Instead of completely rethinking and redesigning the add visit flow right before shipping, I just kept the current approach and made a note to work on it later. I didn't want to rethink entire flows when I was so close to getting something out the door.

This is something I definitely want to improve since right now the add visit flow can be a bit clunky because you have to create or select the campground and site first before you can log a visit. Recognizing that this could wait for v1.1 instead of blocking my v1.0 launch was really important.

What's Next

It's still missing the ability to collaborate on a visit, but that's the next feature I'll work on after Apple approves the app. I also want to separate site ratings from visit ratings since right now they're combined. There's a bunch of other stuff I want to add like some type of dashboard with stats, trip planning features, the ability to favorite campgrounds, and some nice to haves like campground list sorting and searching.

For the add visit flow improvements, I'm planning to A/B test a new approach that's just a form without requiring a campground or site first. I won't have enough users to get statistically significant results, but I like the idea of practicing this skill for future job interviews.

The Big Picture

Having what I feel is enough to submit the app to the App Store is a big deal for completing side projects for me. I am a master at starting but never finishing or getting them out the door. I felt proud when I hit submit, and I'm really proud that I have actually submitted it to the App Store and hopefully others will find it useful.

The key lessons that helped me actually ship this time: build small versions and get them out, don't get distracted by things that might not matter, and use external deadlines to help prioritize what's truly necessary versus nice to have.

PocketBudget Update: July 10, 2025

2025-07-09T00:01:00Z

I didn't really figure out the issue from earlier, but I did find a solution. I just had to use a different formatter. Since, I'm not writing test right now, I had to create a TransactionsListView to display the list of transactions to make sure they were added correctly. Once that was confirmed, I tweaked the design a bit and now I have this New Transaction view.

I'm pretty happy with the design, but I still need to figure out some UX around what happens after the transaction is saved or cancelled.

My next task is to implement the functionality for views to update when data is saved.

PocketBudget Update

2025-07-09T00:00:00Z

Cranked away on PocketBudget last night.

The last time I streamed and worked on it, I ran into a data fetching issue. Turns out my dates were not the same so the comparison in the predicate didn't work. I made the predicate more flexible by making sure the startDate are within the same day and not specifically the exact same time and date.

Started building out the new transaction flow, which is what I'll continue on stream tonight. Make sure to drop by and say hi either on Twitch or YouTube.

Twitch: https://www.twitch.tv/heyjaywilson
YouTube: https://www.youtube.com/@heyjaycodes

My goal is to get the iOS app shipped by the end of the month, so I can enter shipaton and then continue building out the backend.

How to see path of file in "Alex: AI for Xcode"

2025-06-04T00:00:00Z

In Alex: AI for Xcode, sometimes you need to add context to the chat and reference a file but sometimes your files are the same name so you can't really tell which one you actually need to reference.

To see the full path, hover over the file and the path will appear.

I love flying

2025-05-10T00:00:00Z

Flying is always fun for me. It doesn't matter where I'm going. Being in an airplane above the land (or water) is always mesmerizing to me.

I always make sure to book a window seat. I didn't recently and was quite dissapointed.

PocketBudget Stream #3: Swift Testing and Foreign Keys

2025-05-01T00:00:00Z

This was a long one tonight. Just shy of 3 hours and starting off I didn't even want to do testing 😬. I also deviated from what I said I was going to do last time which was working on a subscriptions table and only worked on what would propel functionality forward, meaning I started working on creating and fetching budgets.

Creating the budget table

Since I had the users table and repository done, it was actually pretty easy to get the budgets table created. The tricky part was getting the foreign key relationship right - the budgets table needs to reference the users table to maintain data integrity.

Cursor helped me build the initial statement, but something felt off about it. After some mid-stream googling and checking the PostgreSQL documentation, I found out that PostgreSQL has specific requirements for foreign key constraints. Here's what worked:

func createTable() async throws {
  try await self.client.query(
    """
    CREATE TABLE IF NOT EXISTS "budgets" (
        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
        user_id UUID REFERENCES "users" (id),
        budget_name TEXT NOT NULL,
        created_at TEXT NOT NULL,
        updated_at TEXT NOT NULL
    )
    """,
    logger: self.logger
  )
}

The REFERENCES "users" (id) part tells PostgreSQL to make sure any user_id we try to insert actually exists in the users table. If we try to create a budget with a non-existent user_id, PostgreSQL will reject it.

Testing budget postgres actions

Testing repositories is usually straightforward with in-memory storage. You just construct the object and pass it into the init. Then you can perform actions, like creating a new one or getting a specific one. Where I ran into issues was testing the Postgres repository.

I had already implemented tests on the User Repository and knew I needed it to run serialized since all the tests share the same database. What I wasn't prepared for was how Swift Testing handles multiple test suites. By default, it runs everything in parallel, which means:

First test suite starts and creates a user
Second test suite starts simultaneously and tries to create a user when the table is supposed to be empty
Both tests try to modify the database at the same time, causing failures

To solve this, I first tried marking both suites with @Suite("Budget Repository Tests", .serialized). But that only serializes tests within each suite. The suites themselves were still running in parallel. The docs don't really cover this case, so I turned to Cursor and the YouTube chat for ideas.

The solution was to create one parent test suite that controls everything. Here's what it looks like:

import Testing

@testable import App

@Suite("Database Tests", .serialized)
struct DatabaseTests {
  var userTests: UserPostgresRepositoryTests
  var budgetTests: BudgetPostgresRepositoryTests

  init() async throws {
    self.userTests = try await UserPostgresRepositoryTests()
    self.budgetTests = try await BudgetPostgresRepositoryTests()
  }

  @Test("Create tables successfully")
  func testCreateTable() async throws {
    try await userTests.testCreateTable()
    try await budgetTests.testCreateTable()
  }

  @Test("Create user successfully")
  func testCreateUser() async throws {
    try await userTests.testCreateUser()
  }

  @Test("Create budget successfully")
  func testCreateBudget() async throws {
    try await budgetTests.testCreateBudget()
  }

  @Test("Fetch budget successfully")
  func testFetchBudget() async throws {
    try await budgetTests.testFetchBudget()
  }
}

I took out all the @Test and @Suite from the individual repository test files but kept all the actual test logic there. This way, the parent suite controls when tests run, but each repository keeps its own test code organized. I didn't think this would work at first since I hadn't seen this pattern in any examples, but it effectively solved the test parallelization issues.

What's Next and When

I'm not too sure when I'll be back - at most it'll be about 2 weeks away. I have some personal stuff coming up and it's causing a delay, but the latest I'll be back is May 14th at 8pm PST.

Off stream, I want to get more of the Pockets (AKA categories) figured out, but that will take some time so I'll more than likely still be doing some of that on stream. If you're really curious about what I'll be doing next, you can join the discord or follow me on socials.

PocketBudget Stream #2 Recap

2025-04-27T00:00:00Z

This was the second stream of me building PocketBudget.
I set out to do four things, but only ended up finishing two. Honestly, that's fine — I learned a lot more about how PostgresNIO works, so still a win.

What happened this stream?

After last stream, I decided I want to tackle all backend needs first before moving on to the client (an iOS app in my case). So this stream, I started working on basic CRUD operations for a User, since almost all data in the app will eventually relate back to a user.

NOTE

CRUD stands for Create, Read, Update, and Delete.

I wanted to complete full CRUD support for users, but only got Create fully working and started a stub for Read (fetching all users). Realistically, fetching all users is only useful for me during development — it doesn’t actually move the app forward much yet.

One thing I spent time on was learning how to catch a specific error from PostgresNIO. It took some digging, but I found that I needed to check the sqlState field and match it against the code 23505 to detect a unique constraint violation (basically, when trying to insert a user that already exists based on unique fields). Here's the code I ended up with:

// Inside a do-catch block
catch let error as PSQLError {
    if let sqlState = error.serverInfo?[.sqlState] as? String, sqlState == "23505" {
        logger.error("🚨 User already exists with the same auth_provider_id and auth_provider")
        throw HTTPError(.badRequest, message: "User with this auth_provider_id and auth_provider already exists.")
    }
    logger.error("🚨 \(String(reflecting: error))")
    throw error
}
// Rest of catch

What's next?

I’ll be continuing some work off stream — mainly converting existing tests from XCTest to Swift Testing and writing new tests for the work done so far. I also plan to finish the Delete and Update operations for users offline.

I want to set up swift-format on the project too, so the codebase stays clean and consistent as it grows.

For the next stream:

Set up the subscription table
Update ResponseUser to include whether the user is currently subscribed

Keeping the goals small on this stream so that I can hopefully get them all done. If I end up getting them done, then I'll head on to budgets next.

PocketBudget Stream Recap

2025-04-24T00:00:00Z

What is PocketBudget

PocketBudget is an envelope budgeting app. It's philosphy is to budget every dollar into a pocket (aka category) to be spent.

Why?

I want to build a budgeting app. I also want to replace my current budgeting app with the one I'm building.

What's the stack?

Backend

Swift
PostgreSQL

iOS App

SwiftUI

More apps to be decided later... I need to finish the app first.

Goals from the stream

Create backend repo
Get 1st build of Hummingbird working
Add Postgresql
Configure docker to run the database and server

What happened

Created the backend GitHub repo using the Hummingbird template
Was able to build and run the server after running configure
Started to implement Fluent then completely over thought what an "in memory" database meant so pivoted to PostgresNIO to follow the tutorial/guides more on Hummingbird's website
Added a docker-compose file to run the server and database at the same time and was able to see my table in TablePlus, the app I use to inspect databases.

NOTE

TablePlus is part of SetApp, which I've found worth the subscription. You can get SetApp here and if you sign up we both get a month free.

What's next?

When: April 27 2024 at 2pm PST Where: YouTube or Twitch

Goals:

Create a user
Delete a user
Update a user's display name

Stretch goals

Budget model
Add a budget table
Create a budget related to a user

How I am using AI Assisted Coding

2025-04-18T00:00:00Z

AI code editors are becoming more popular, and I am trying to incorporate them into my worklfow. The keyword there is trying. It's successful sometimes and definitely not in other times.

I'm currently using Cursor and Alex and pay for both. I use both for iOS and Swift projectsm, but Cursor is also used for web projects. Both these products get frequent updates, so these tips could be outdated by the time you see this.

Last updated: April 24, 2025

Things that work (the majority of the time)

Adding more context. Linking a lot of files does allow for more context.
Creating a full spec and telling it to implement it but to check in occassionally.
- You still need to really spec out exactly what needs to happen and make sure there are no logic gaps.
Giving as much context as you can think of
- Make sure to include all the files you think are going to be necessary to implement the task that way it doesn't make up initializers or function signatures 🙄

Things that don't work (the majority of the time)

Using a chat for a lot of different things
- It's easy to think that a long running chat will have all the context, but it will forget more things.
Using it or brand new frameworks
- If there aren't a lot of articles or resources for the framework you're trying to use on the internet, the chances of AI helping you with it are really low.

What I find AI really good at

Docker files. I am clueless about Docker files, but it's really good at helping me figure out what I need to change and what I need to do to get it working.
Scripts. I'm pretty new to making scripts or doing anything with the command line. Since most of that has been written about, AI is actually really good at writing scripts that need to do a specific task.

iHog v2025.1.0

2025-04-18T00:00:00Z

I've released my first release of iHog this year. I wanted this release to do more than a bug fix, but that's what it is. ETC is releasing a new version of Hog, so I need to get the code base ready for potential changes. This meant pausing my Show Notes feature that I spent way too long trying to get right. I think I did figure out my issue there so it should be able to be added soon after Hog 5 support.

User Highlights

User profile sheet
- Allows a user to test new features via a code
- Adds the ability to mass delete objects and shows
Fixes an issue where a user couldn't delete a show

Developer Highlights

No more Core Data.
- This release moves everything over to Swift Data and removes all Core Data related files.
Moved files around in the repo
- This allows Alex: AI for Xcode to work better on packages

I'll make more posts about some of the pains I went through with Swift Data, but for now feel free to check out the code as iHog's code is available on GitHub.

iHog is built in an open repo, so please feel free to look at the issues, code, or drop me some feature ideas in the GitHub Discussion Board

Things I didn't think HRT would change #1

2025-04-08T00:00:00Z

I started HRT to medically transition in August of 2023. Since then I had the expected changes, small weight distribution and voice change mainly. I had heard that testosterone could change a person's foot-size but being that I was 29 when I started and fully grown, I didn't think it would happen to me. I was wrong. Today, I received an order for a new pair of shoes I already owned but 1/2 a size bigger.

I now have 4 pairs of shoes that fit me, a winterized pair of Vans that I bought too big at the time but needed for a trip, a pair of hiking boots, a pair of Thursday boots, and now these Reeboks.

I knew my foot had grown in December because my parents gave me the Thursday boots as a birthday gift but they were too small when I received them. I just didn't want to replace my sneakers yet since it's been too wet to not wear the other shoes. Now that it's starting to rain a smidge less in the PNW, I'll probably be making more show purchases.

Writing down my 3 tasks

2025-04-07T00:00:00Z

Recently, I started writing down my top 3 tasks for the day and it's a habit that's sticking Monday through Thursday. I hold myself a bit more accountable when it's written down than when I have it in a task manager for some reason.

YouTube short

Sunday Reset

2025-04-06T00:00:00Z

I let my desk get a bit messy over the last couple of weeks, so it's time to clean it up. I think I work a bit better when there's not a lot of clutter and sometimes it's hard for me to find the difference between clutter and decoration. I can say for sure I had too much clutter with all the papers I recycled today.

YouTube Short

Trans Day of Visibility 2025

2025-03-31T00:00:00Z

I don’t talk about this too much here, and I think today is a good day to do it. I’m Jay and I’m a trans man. My pronouns are he/him. I started posting on socials, streaming, and making YouTube content as a way to represent people I didn’t see a lot of in tech and I am going to continue that.

Today is Trans Day of Visibility which is a day celebrated in the community to just raise awareness about transgender people. We exist and just want to exist without discrimination as most people do. Today is my 2nd Transgender Day of Visibility since figuring myself out, and I’ve just gotten to be a better and happier version of me since, as most trans people do.

New post from FeedCraft

2025-02-23T00:00:00Z

Here’s a new post from the FeedCraft app I’m working on.

Callout support

2025-02-21T00:00:00Z

With the help of Cursor, I think I've added support for callouts similar to GitHub's alerts.

Here are examples of how mine render:

NOTE

That has one line in it.

TIP

This is a tip

IMPORTANT

This is important

WARNING

This is a warning

CAUTION

This is a caution

NOTE

This is a note
With a second paragraph and some inline styles and a link.

Here's how it works under the hood:

> [!NOTE]
> This is a note
>
> With a second paragraph and some inline **styles** and a [link](https://example.com).

The > [!NOTE] is the callout type which is picked up by a plugin that looks for the token and created the HTML structure of the callout.

That structure looks like

<blockquote data-callout="note">
  <p class="callout-label"><span class="callout-icon"></span>NOTE</p>
  <p>This is a note</p>
  <p>With a second paragraph and some inline <strong>styles</strong> and a <a href="https://example.com">link</a>.</p>
</blockquote>

The hard part was getting the tokens and the content right underneath the callout type to render correctly.

Here's the final javascript that does the trick:

import MarkdownIt from "markdown-it";

export function calloutsPlugin(eleventyConfig) {
  const md = eleventyConfig.markdownLibrary || new MarkdownIt({ html: true });
  eleventyConfig.setLibrary("md", md);

  md.core.ruler.after("block", "callouts", function (state) {
    const tokens = state.tokens;

    for (let i = 0; i < tokens.length; i++) {
      const token = tokens[i];
      if (token.type === "blockquote_open") {
        const text = tokens[i + 2];
        const match = text?.content?.match(
          /^\[!(NOTE|TIP|IMPORTANT|WARNING|CAUTION)\]/
        );

        if (match) {
          // Add data-callout attribute
          token.attrs = token.attrs || [];
          token.attrs.push(["data-callout", match[1].toLowerCase()]);

          // Add class to the first paragraph
          const para = tokens[i + 1];
          if (para && para.type === "paragraph_open") {
            para.attrs = para.attrs || [];
            para.attrs.push(["class", "callout-label"]);
          }

          // Get cleaned content
          const content = text.content.replace(match[0], "").trim();

          // Set the label
          text.content = `<span class="callout-icon"></span>${match[1]}`;

          // Add paragraph with content
          const paraOpen = new state.Token("paragraph_open", "p", 1);
          const contentToken = new state.Token("text", "", 0);
          contentToken.content = content;
          const paraClose = new state.Token("paragraph_close", "p", -1);
          tokens.splice(i + 4, 0, paraOpen, contentToken, paraClose);
        }
      }
    }
  });
}

This plugin is then added to my 11ty config file and runs on build.

This was quite the exercise to get it right even with the help of Cursor. It's hard to get Cursor to think of different ways to do the same thing if you don't prompt it first. I was stuck in a few loops of getting the same answers over and over when I should have been prompting for different ways to do the same thing. I tried going a mainly CSS route, but it wasn't working so then I had to prompt it to think about how to do it with standard HTML layout which eventually got me to the solution.

Congrats Canada on winning hockey 🏒

2025-02-20T20:42:00Z

Congrats Canada on winning hockey 🏒 today!

What do we do now?

2025-02-18T21:36:00Z

I'm not sure what to do now. I'm scared. I've been scared since the election. I moved so we could live in a state that offered us more protections and rights, but with every day and every executive order, I'm not sure how much protection we will have and for how long.

I am really hoping that something will be done to stop this dictatorship from getting stronger, but that hope is fading with each passing day.

So I'm asking, now what? What am I supposed to do? How do I continue to exist when the government is shifting so radically and so quickly?

Nice post about testing in SwiftUI

2025-02-18T09:49:00Z

Jon Reid, @qcoding, made a good article detailing what to test and what not to test in SwiftUI.

I like the emphasis on testing behavior not appearance. I think this is really important due to how SwiftUI handles refreshes. SwiftUI is going to update a view based on changes made so we need to make sure the behavior is producing the proper changes. We don't need to actaully test that the button is Blue instead of Red. We need to test did the conditional change and did it change to the value that's expected. We can visually see in SwiftUI previews that button will change colors based on the values given.

FeedCraft coming soon!

2025-02-18T06:23:00Z

Over the weekend, I started working on FeedCraft more seriously (I know I said no new projects, but I technically started this last year so it fits in my year of follow-through) because I need a quick way to post here.

What is the purpose of FeedCraft?

FeedCraft is an iOS app that allows users to make posts on their GitHub hosted blog. All the blog needs to do is support text files with front matter. Usually these are Markdown files, but they can be any file type.

Why did I build FeedCraft?

I wanted a way to quickly post to my blog when the inspiration struck, so here we are. An app that's 80% of the way done and it's getting a blog post to help me finish it.

What features does it have?

Customize front matter
Copy and paste your content from the app to wherever you need it
Apply front matter templates*
Create, update, and publish files directly to your GitHub*
Preview your markdown post*

* = paid features

There are more features cooking, but for right now, this is what I want to launch with. It might not be a lot but it's a good start. If you have more ideas on what to add here, then please shoot me a message somewhere on the internet.

What's the tech stack?

It's pretty simple for now:

SwiftUI
Swift Data

I'm doing a lot on device for now, so no need to really overcomplicate it. Once I add in photo uploading and crossposting to social media platforms, I might need to add in a server but I don't think that's necessary right now.

When does it launch?

I'll be opening a TestFlight at the end of the month, but I need to get some of the UI and UX nailed down a bit more. I'm hoping to go live sometime in March depending on feedback.

Thanks y'all for reading!

Six main interests

2025-02-17T10:54:00Z

I was asked by a friend to list off my main 6 interests, so I thought that might make a good blog post. These are listed in most to least interested.

Software development. This could be dwindled down to just Swift development, but sometimes I like to cross into web dev.
Videography and photography. I like cameras and tech, so this was a no brainer. I enjoy taking the photos, recording the video, and the editing process.
Taylor Swift.
Off roading. I don't do it often, but I am interested in it and do look it up quite a bit. Before the administration ruins public lands, I'm hoping to go out when it's a bit dryer and explore.
Corgis.
Hockey. I root for the Seattle Kraken, Minnesota Wild, and Minnesota Frost.

I'm pretty confident in this order, but I do have many more interests.

Why I Started Drinking Old Fashioneds

2025-02-15T00:00:00Z

If we go to a restaurant together, I’ll order an old fashioned. It’s a standard drink that most places can make, and I like bourbon, well now I like bourbon. I didn't like bourbon before.

I started drinking old fashions mainly because I thought they were “manly”. It’s kind of silly now that I think and write about it, but it’s true and I’m not alone in this idea. I have a friend who says she started drinking beer because “that’s what lesbians do”.

It's interesting thinking how certain actions help you feel more connected to your identity due to social norms. It just makes me wonder how society shapes how we see ourselves.

AWS free tier is pretty great

2025-02-09T21:53:00Z

I've been creating a couple AWS Lambdas lately to run some in progress features for this site, and I've been pleasantly surprised by the free tier. Everytime I go to estimate the cost, it's like $0.00...

Let's see what happens as I keep building and adding more though.

My Website is Back with a New Look

2025-02-02T00:00:00Z

Here's my new website. It's still a bit under construction and rough around the edges, but it's a start.

I use this site as a place to write about my experiences and thoughts on my life. I'm also a software engineer, so I'll be posting about my projects and thoughts on software development.

What I take with me on a weekend away

2024-09-09T00:00:00Z

Recently, I went on road trip to see my wife's family. I thought I'd make a list of what I take in my backpack. There was no expectation of me doing any type of work. I thought I might need to do some task management and maybe want to take some photos/video so that's what I packed for.

View this post on Instagram

A post shared by Jay (@heyjaywilson)

The Bag

The bag I use is the Wandrd PRVKE 21L. I also have this bag in the 31L size, and I really like it. The organization is great and there's a lot of space.

Gear

iPad Pro M4 13" with Apple Pencil Pro
Camera: RX100v
Camera: Sonvy ZVE-1
AirPods Pro

Power

Misc

Altoids can with headache medicine
USB C memory card reader
USB C hard drive
MagSafe battery charger

FindRelief - Project Log 3

2024-09-01T00:00:00Z

What I accomplished this week

I didn't do too much this week, but I did settle on how the lists of places will look. I usually design in code cause it's easier and quicker, but this was not one of those times. I have a lot of information I want to present in each row, so I decided to turn to work in Sketch and figure out what it should look like.

There are 3 states here.

Add a place. It doesn't exist in my database. This is Target in the screenshot. It has the the + sign.
Not selected place. It exists in my database, but the user has not selected it to get more info. It's a lot of icons in the top row, but that's okay. The user can also upvote/downvote and update the location.
Selected place. It exists in my database, and the user has selected it. This is Houndstooth in the design on the right. It explains the icons and what the location has restroom wise. The user still has access to upvote/downvote and edit.

Again, these are all designs and my intentions. Here's what I ended up with in SwiftUI previews.

The key differences is the size of the arrows, the number of upvotes and downvotes, and the edit button is gone. I made the choice to remove the edit button and replace it with either a swipe action or a context menu, since I don't think it will be used too often and it wasn't a crazy thought since @steve228uk suggested it on my threads post.

What's next?

Update the data and get the view to adjust in real time. This might take some actual work since I don't think I really built this in a way to respond to the data like that
Update the server to retrieve the data
Update the server to edit for specific properties like upvoting/downvoting
Implement favorites. Which I think will be the paid part of this app. A small yearly subscription to help cover server costs.

Will I meet the Ship-a-ton deadline?

I don't think I will and that's okay. I'll keep working and trying to though and see how close I get.

Previous Dev Logs for FindRelief

Log 1
Log 2

FindRelief - Project Log 2

2024-08-25T00:00:00Z

What I accomplished since Log 1

Setup dev vs prod builds using XCConfig files, which I wrote a blog post for
Started using packages due to some reason the previews not working in the Xcode project
- I should've really figured this issue out, but I decided to not worry about it and keep building
Searching for a place based on a region in a user’s map
Figure out how to use a Swift Actor to manage the search service
- I need to still dive into Swift Concurrency a lot more
Create a route to add a place on the server
Allow a user to Add a Place from the app
Create a Trello board to track tasks and any features/feedback that people might have from seeing various posts on the internet

Here's a couple posts on social media I made while ~~struggling~~ building the app.

Post by @heyjaywilson

View on Threads

Why does Xcode need to block me from doing anything while copying shared cache? It takes just enough time that I also get distracted...

2024-08-15T07:30:00Z

Why does Xcode need to block me from doing anything while copying shared cache? It takes just enough time that I also get distracted...

How to get the current MKCoordinateRegion from a MapCameraPosition

2024-08-15T00:00:00Z

Goal to achieve: Get the MKCoordinateRegion of the map I'm looking at.

What I tried and did not work:

struct MapSearchView: View {
	@State private var position = MapCameraPosition.automatic
	@State private var mapRegion: MKCoordinateRegion = .init()

	var body: some View {
		Map(position: $position)
		.onChange(of: position) {
			print(position.region)
		}
  }
}

This would always print nil even though it's supposed to be the current region.

What I ended up getting to work:

struct MapSearchView: View {
	@State private var position = MapCameraPosition.automatic
	@State private var mapRegion: MKCoordinateRegion = .init()

	var body: some View {
		Map(position: $position)
		.onMapCameraChange { mapCameraUpdateContext in
			mapRegion = mapCameraUpdateContext.region
		}
  }
}

I had to use the specific onMapCameraChange to get the region and then update a state variable. I can then use that however I want.

Why does Xcode need to block me from doing anything while copying shared cache? It takes just enough time that I also get distracted...

2024-08-14T00:00:00Z

Why does Xcode need to block me from doing anything while copying shared cache? It takes just enough time that I also get distracted...

FindRelief - Project Log 1

2024-08-14T00:00:00Z

I'm starting this log to help hold myself accountable and to build in public. I'm a big proponent of building in public, and I started this project by being quiet about it. The reason for that was cause I needed to see if I could actually do a lot of what I wanted to, and I can so now it's time to introduce it and start a log.

What is FindRelief?

It's a restroom finder that has an emphasis on what type of restrooms are available. Being trans, I need to find restrooms that are safe for me to use and usually that means a family or gendered neutral restroom so I decided to make an app for that. This data will be self reported by users (or just me).

What's the tech stack?

iOS App: Written in SwiftUI. When I need local storage, then I'll probably lean on SwiftData, but I might actually use Boutique
Map data is provided by MapKit since there's web data available if I decide to expand this app.
User authentication is handled with Clerk. I've seen this pop up in the web dev world lately and their iOS SDK is in early beta, so I figured why not try it. If it fails, I can pull in another auth platform, but so far it's been relatively easy to use.
Database is a dynamodb table. I'm using a single table design. I wanted something quick and easy. Will see how that goes
Server is written in Swift using the Hummingbird framework

What's been done so far?

I'm building both parts of the app at the same time, so that areas of the server are built as I'm working on that area in the iOS app.

Server side

Created an access pattern, entity relationship diagrams, and entity charts
Create a user
delete a user
get a specific user

As I mentioned, Clerk handles user auth, but I need to be able to associate a user in the database with updates and places created, so I wanted my own record of ids, dateCreated, and usernames. I also want to be able to store how many updates a user makes (future thinking here about a user's reputation on the app), so I needed a place to store that. Here's the data I think I need about a user so far:

erDiagram
	User {
		string userid
		string username
		string createdAt
		string updatesAt
		int numberOfUpdates
	}

App Side

Implement account creation
Implement account deletion (requirement by apple)
Implement account sign out
Started searching for places

What's next?

Tapping on a place on the map will bring up details about that locations restroom
The details for a location will appear in search results
Store the locations details in DynamoDB

Been using VSCode for some swift stuff and not having to deal with the package.resolved always changing is 🔥

2024-07-12T00:00:00Z

Been using VSCode for some swift stuff and not having to deal with the package.resolved always changing is 🔥

How to access custom headers in Hummingbird 2

2024-07-08T00:00:00Z

Hummingbird is a server framework written in Swift. I'm using it at work and for a few personal projects. It's small and quick to build, so it checks the boxes for what I'm trying to do.

The Hummingbird project is quickly moving to v2.0 (as of writing this RC 2 is out 🎉), and that brought a change with accessing custom headers. In v1 it looked something like request.headers["custom-header-name"]. In v2 it now requires a bit more work thanks to the reliance on Swift-HTTP-Types, but ultimately I think it's a cleaner call site.

First, you need to extend HTTPField.name and add the new header name in there.

// don't forget to import HTTPTypes
import HTTPTypes

extension HTTPField.Name {
  // if you don't force unwrap here, you'll need to account for the optional in the next step
	static let customHeaderName = Self("custom-header-name")!
}

Then you can call it in a very similar way to v1.

let headerValue = request.headers[.customHeaderName]