Acorn DevOps
@acorndevops.bsky.social
acorninteractive.ca
Home of the devvy Kjörndogs. Buckle up, get comfortable. We’ll be pushing automated updates from any major developments on our core application, while publishing technology insights, code related findings, and general dev musings.
Home of the devvy Kjörndogs. Buckle up, get comfortable. We’ll be pushing automated updates from any major developments on our core application, while publishing technology insights, code related findings, and general dev musings.
Perhaps not trunk quite yet, but a
✌️Baleen Effort✌️
Inviting the question of paradox in relationship between modern memery and the roles of applied programming.
They are not related at all, and yet have everything in common...
✌️Baleen Effort✌️
Inviting the question of paradox in relationship between modern memery and the roles of applied programming.
They are not related at all, and yet have everything in common...
November 12, 2025 at 7:29 PM
Perhaps not trunk quite yet, but a
✌️Baleen Effort✌️
Inviting the question of paradox in relationship between modern memery and the roles of applied programming.
They are not related at all, and yet have everything in common...
✌️Baleen Effort✌️
Inviting the question of paradox in relationship between modern memery and the roles of applied programming.
They are not related at all, and yet have everything in common...
Using our branch-based refactor, our PRs are continuing to bolster insights for our QA, enabling us to build out programmatic test coverage, which is certainly not an overnight feat.
To use appropriate corporate terminology our initial quote Fuddle Duddle now has bolster application awareness...
To use appropriate corporate terminology our initial quote Fuddle Duddle now has bolster application awareness...
November 12, 2025 at 7:25 PM
Using our branch-based refactor, our PRs are continuing to bolster insights for our QA, enabling us to build out programmatic test coverage, which is certainly not an overnight feat.
To use appropriate corporate terminology our initial quote Fuddle Duddle now has bolster application awareness...
To use appropriate corporate terminology our initial quote Fuddle Duddle now has bolster application awareness...
Getting somewhere now. As in cooking with ethically sourced and sustainable low C02 biofuels.
(The kind of cadence that doesn't cry foul over oat almond milk, if you know what I mean)
Having one to several pages in a state of refactor means we can move on to integration strategies now.
(The kind of cadence that doesn't cry foul over oat almond milk, if you know what I mean)
Having one to several pages in a state of refactor means we can move on to integration strategies now.
![A flow diagram showing the Services Contact Form process on the Acorn website. The flow begins at START and moves to a Services Single page (default). Users encounter a form asking "Want to chat more about [service]?" with mandatory fields (First name, Last name, Email) and Message field. After form submission, there are two paths:
Success path (green): Leads to Services Single page (success state), sends verification email to inbox, then reaches END
Error path (red): If validation fails for mandatory fields, returns user to the form to correct entries
The diagram includes mockup thumbnails of the services page interface at the bottom. A note references the Figma mockups at the provided URL.](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:n3xrtzprp3blxeqiid5abew3/bafkreielzrh3tihvrnh7hulyqctkmi527mysilcucnjc6qqvqer7iatgre@jpeg)
November 12, 2025 at 5:35 PM
Getting somewhere now. As in cooking with ethically sourced and sustainable low C02 biofuels.
(The kind of cadence that doesn't cry foul over oat almond milk, if you know what I mean)
Having one to several pages in a state of refactor means we can move on to integration strategies now.
(The kind of cadence that doesn't cry foul over oat almond milk, if you know what I mean)
Having one to several pages in a state of refactor means we can move on to integration strategies now.
It's a bit of back and forth, but now KNOWING we have all mongo collections added to the global data container without route provisioning, we can see how total blocking time is implicated by the mongo queries themselves which implicates largest contentful paint.
October 27, 2025 at 5:41 PM
It's a bit of back and forth, but now KNOWING we have all mongo collections added to the global data container without route provisioning, we can see how total blocking time is implicated by the mongo queries themselves which implicates largest contentful paint.
forward. As for the evolution into TDD, it becomes (interesting | mind numbing) depending on your point of reference. The when part of
1) after a foundational refactor
2) the establishment of route based subscription handling
3) updates to methods themselves
4) adding tests?
Pseudo code start:
1) after a foundational refactor
2) the establishment of route based subscription handling
3) updates to methods themselves
4) adding tests?
Pseudo code start:
October 27, 2025 at 5:36 PM
forward. As for the evolution into TDD, it becomes (interesting | mind numbing) depending on your point of reference. The when part of
1) after a foundational refactor
2) the establishment of route based subscription handling
3) updates to methods themselves
4) adding tests?
Pseudo code start:
1) after a foundational refactor
2) the establishment of route based subscription handling
3) updates to methods themselves
4) adding tests?
Pseudo code start:
The applications indexing after the SSR boondoggle on prod *appears* to be making waves now. It's things like these (touching up blemishes on prod while enacting a structural refactor) that have me happy about the environment provisioning. Now we're almost done the overdue global data provider.
October 27, 2025 at 5:31 PM
The applications indexing after the SSR boondoggle on prod *appears* to be making waves now. It's things like these (touching up blemishes on prod while enacting a structural refactor) that have me happy about the environment provisioning. Now we're almost done the overdue global data provider.
Route activation with new SSR patterns starting to show results. Blocking time and thread work will be a doozy, but it's a good first step.
October 24, 2025 at 11:45 PM
Route activation with new SSR patterns starting to show results. Blocking time and thread work will be a doozy, but it's a good first step.
Things in the ... spooky um swamp, at now getting SCARY.
By being able to ~conjure~ the
1) suspense and SSR lazy loading pattern with
2) code splitting on page sections with
3) adequate react router handling paradigms with errorBoundaries, interstitial placements and reusable designs
By being able to ~conjure~ the
1) suspense and SSR lazy loading pattern with
2) code splitting on page sections with
3) adequate react router handling paradigms with errorBoundaries, interstitial placements and reusable designs
October 24, 2025 at 3:04 PM
Things in the ... spooky um swamp, at now getting SCARY.
By being able to ~conjure~ the
1) suspense and SSR lazy loading pattern with
2) code splitting on page sections with
3) adequate react router handling paradigms with errorBoundaries, interstitial placements and reusable designs
By being able to ~conjure~ the
1) suspense and SSR lazy loading pattern with
2) code splitting on page sections with
3) adequate react router handling paradigms with errorBoundaries, interstitial placements and reusable designs
Code refactoring is healthy and you're gonna LOVE it.
October 23, 2025 at 9:22 PM
Code refactoring is healthy and you're gonna LOVE it.
As for the branch-to-trunk approach updates, our QA... Werewolf ... is now evaluating where to apply test cases in conjunction with our full stack.
As we go CURSED route by route, we can continue to update this coverage. By the time we're done it would be time to trunk.
As we go CURSED route by route, we can continue to update this coverage. By the time we're done it would be time to trunk.
October 23, 2025 at 7:38 PM
As for the branch-to-trunk approach updates, our QA... Werewolf ... is now evaluating where to apply test cases in conjunction with our full stack.
As we go CURSED route by route, we can continue to update this coverage. By the time we're done it would be time to trunk.
As we go CURSED route by route, we can continue to update this coverage. By the time we're done it would be time to trunk.
And FINALLY after all that, we begin to be able to roll out design tweaks as well.
The challenge I am giving the team is to
1) enact test coverage on a per page basis while
2) using deltas in code changes such that our coverage is adaptive to revisions.
Now that is a "thriller", to us.
The challenge I am giving the team is to
1) enact test coverage on a per page basis while
2) using deltas in code changes such that our coverage is adaptive to revisions.
Now that is a "thriller", to us.
October 23, 2025 at 7:32 PM
And FINALLY after all that, we begin to be able to roll out design tweaks as well.
The challenge I am giving the team is to
1) enact test coverage on a per page basis while
2) using deltas in code changes such that our coverage is adaptive to revisions.
Now that is a "thriller", to us.
The challenge I am giving the team is to
1) enact test coverage on a per page basis while
2) using deltas in code changes such that our coverage is adaptive to revisions.
Now that is a "thriller", to us.
Branch-to-trunk updates:
We did need the branch for the core upgrades to INFORM the coverage. So while divergent from our QA branch, we can at least stipulate what is going on, and what needs coverage to begin to trunk.
🧟Otherwise we would haunt the project🧟
We did need the branch for the core upgrades to INFORM the coverage. So while divergent from our QA branch, we can at least stipulate what is going on, and what needs coverage to begin to trunk.
🧟Otherwise we would haunt the project🧟
October 23, 2025 at 3:01 PM
Branch-to-trunk updates:
We did need the branch for the core upgrades to INFORM the coverage. So while divergent from our QA branch, we can at least stipulate what is going on, and what needs coverage to begin to trunk.
🧟Otherwise we would haunt the project🧟
We did need the branch for the core upgrades to INFORM the coverage. So while divergent from our QA branch, we can at least stipulate what is going on, and what needs coverage to begin to trunk.
🧟Otherwise we would haunt the project🧟
Staying on season brand take one:
One thing that doesn't invite Freaky Feelings is using LLMs to scan for dependency updates combinatively.
As many have experienced before, it is almost like in the past you change one dependency and a mutant hand shoots out of the ground while the stakeholders
One thing that doesn't invite Freaky Feelings is using LLMs to scan for dependency updates combinatively.
As many have experienced before, it is almost like in the past you change one dependency and a mutant hand shoots out of the ground while the stakeholders
October 23, 2025 at 2:32 PM
Staying on season brand take one:
One thing that doesn't invite Freaky Feelings is using LLMs to scan for dependency updates combinatively.
As many have experienced before, it is almost like in the past you change one dependency and a mutant hand shoots out of the ground while the stakeholders
One thing that doesn't invite Freaky Feelings is using LLMs to scan for dependency updates combinatively.
As many have experienced before, it is almost like in the past you change one dependency and a mutant hand shoots out of the ground while the stakeholders
Build time now down by 3 minutes from ~10.
Incremental changes, as we merge the production environment commit flags
- [(major|minor|patch|hotfix)] -
and now have husky and jest setup, in preparation for refactoring the remainder of the app, route by route.
Incremental changes, as we merge the production environment commit flags
- [(major|minor|patch|hotfix)] -
and now have husky and jest setup, in preparation for refactoring the remainder of the app, route by route.
October 17, 2025 at 5:15 PM
Build time now down by 3 minutes from ~10.
Incremental changes, as we merge the production environment commit flags
- [(major|minor|patch|hotfix)] -
and now have husky and jest setup, in preparation for refactoring the remainder of the app, route by route.
Incremental changes, as we merge the production environment commit flags
- [(major|minor|patch|hotfix)] -
and now have husky and jest setup, in preparation for refactoring the remainder of the app, route by route.
ah ah ah.
It's a bit of a slog, but now with the code splitting paradigm and designs in place, we can clean up the rest and start working on batching the remainder of the refactor.
It's a bit of a slog, but now with the code splitting paradigm and designs in place, we can clean up the rest and start working on batching the remainder of the refactor.
October 16, 2025 at 9:03 PM
ah ah ah.
It's a bit of a slog, but now with the code splitting paradigm and designs in place, we can clean up the rest and start working on batching the remainder of the refactor.
It's a bit of a slog, but now with the code splitting paradigm and designs in place, we can clean up the rest and start working on batching the remainder of the refactor.
Today having seen the react-skeleton patterns added, i was able to
1) turn off all routes except the one in question in the react router
2) invoke suspense and react-lazy
3) verify SSR was still operational and
4) 🪄
1) turn off all routes except the one in question in the react router
2) invoke suspense and react-lazy
3) verify SSR was still operational and
4) 🪄
October 16, 2025 at 6:03 PM
Today having seen the react-skeleton patterns added, i was able to
1) turn off all routes except the one in question in the react router
2) invoke suspense and react-lazy
3) verify SSR was still operational and
4) 🪄
1) turn off all routes except the one in question in the react router
2) invoke suspense and react-lazy
3) verify SSR was still operational and
4) 🪄
Shop talk now:
The tricky part is understanding the efficiency dynamics between staging dependencies in a given application and their roles in degrading performance.
So while both are respectively necessary, concerns about AI jazz include doign the exact same thing way sloppier.
The tricky part is understanding the efficiency dynamics between staging dependencies in a given application and their roles in degrading performance.
So while both are respectively necessary, concerns about AI jazz include doign the exact same thing way sloppier.
October 15, 2025 at 6:25 PM
Shop talk now:
The tricky part is understanding the efficiency dynamics between staging dependencies in a given application and their roles in degrading performance.
So while both are respectively necessary, concerns about AI jazz include doign the exact same thing way sloppier.
The tricky part is understanding the efficiency dynamics between staging dependencies in a given application and their roles in degrading performance.
So while both are respectively necessary, concerns about AI jazz include doign the exact same thing way sloppier.
*been on vacation check in notes*
🥸 with established environment provisioning, now we are able to continue to deploy changes to our ... mindful production server.
Being able to have our showcase up the whole time, while now coming around to performance enhancements (as in the marketing plan) is..
🥸 with established environment provisioning, now we are able to continue to deploy changes to our ... mindful production server.
Being able to have our showcase up the whole time, while now coming around to performance enhancements (as in the marketing plan) is..
October 15, 2025 at 5:26 PM
*been on vacation check in notes*
🥸 with established environment provisioning, now we are able to continue to deploy changes to our ... mindful production server.
Being able to have our showcase up the whole time, while now coming around to performance enhancements (as in the marketing plan) is..
🥸 with established environment provisioning, now we are able to continue to deploy changes to our ... mindful production server.
Being able to have our showcase up the whole time, while now coming around to performance enhancements (as in the marketing plan) is..
![Screenshot of a terminal showing a Git commit on the production branch of acorninteractive.ca. The command line shows 'git commit -m "Add husky pre-push hook to enforce annotated tags on production branch"' followed by a multi-line commit message with bullet points explaining the changes: Install Husky v9 for Git hooks management, Add pre-push hook that requires annotated tags before pushing to production, Update README with Husky setup instructions for both environments, and Ensure production releases are properly versioned and documented. A Technical details section lists four items about hook validation, error messages, Meteor environment compatibility, and troubleshooting documentation. The commit notes 'Current version: v1.0.4' and shows the commit hash [production 4e12bb0] with statistics: 3 files changed, 152 insertions(+), 5 deletions(-), and 'create mode 100755 .husky/pre-push'. The terminal prompt shows version indicators v1.0.0, v14.21.3, and v2.7.18 with branch indicators](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:n3xrtzprp3blxeqiid5abew3/bafkreihnxjb2hohzg6h5izsn4rj5xkfgz6ldmwzueurhyqna5amkhync3u@jpeg)
Here goes nothing.
October 8, 2025 at 3:43 PM
Here goes nothing.
If you look at the docs in the comments they outline deprecation warnings and
*slides the documentation duotang with this on the first page after opening*
*runs away*
*hides*
*never speaks to anyone again for the remainder of adult life*
*slides the documentation duotang with this on the first page after opening*
*runs away*
*hides*
*never speaks to anyone again for the remainder of adult life*
October 6, 2025 at 9:53 PM
If you look at the docs in the comments they outline deprecation warnings and
*slides the documentation duotang with this on the first page after opening*
*runs away*
*hides*
*never speaks to anyone again for the remainder of adult life*
*slides the documentation duotang with this on the first page after opening*
*runs away*
*hides*
*never speaks to anyone again for the remainder of adult life*
Now that the wheels are greased to systematically break down the current state of the application, and have enacted the types of transactions that need to occur to
1) produce tests
2) report testable areas from the server and
3) report design criterion for test coverage
It's off to polish prod.
1) produce tests
2) report testable areas from the server and
3) report design criterion for test coverage
It's off to polish prod.
October 3, 2025 at 9:11 PM
Now that the wheels are greased to systematically break down the current state of the application, and have enacted the types of transactions that need to occur to
1) produce tests
2) report testable areas from the server and
3) report design criterion for test coverage
It's off to polish prod.
1) produce tests
2) report testable areas from the server and
3) report design criterion for test coverage
It's off to polish prod.
While we're getting there with some aspects of the FCP score, there's a bit of dev pong going on about the
-what i'll call-
hero opens mouth weird effect... going down. This invites a much more interesting conversation to host on such a platform.
-what i'll call-
hero opens mouth weird effect... going down. This invites a much more interesting conversation to host on such a platform.
October 3, 2025 at 9:02 PM
While we're getting there with some aspects of the FCP score, there's a bit of dev pong going on about the
-what i'll call-
hero opens mouth weird effect... going down. This invites a much more interesting conversation to host on such a platform.
-what i'll call-
hero opens mouth weird effect... going down. This invites a much more interesting conversation to host on such a platform.
Today's notes
-
As a refresh we have:
1) enacted test coverage for the SSR itself and
2) are proposing to handle server-client data hydration methods (yeet)
So there are two moves:
1) dev to qa (SSR loop)
2) dev to design to qa (server-client hydration and UI)
-
As a refresh we have:
1) enacted test coverage for the SSR itself and
2) are proposing to handle server-client data hydration methods (yeet)
So there are two moves:
1) dev to qa (SSR loop)
2) dev to design to qa (server-client hydration and UI)
October 3, 2025 at 8:58 PM
Today's notes
-
As a refresh we have:
1) enacted test coverage for the SSR itself and
2) are proposing to handle server-client data hydration methods (yeet)
So there are two moves:
1) dev to qa (SSR loop)
2) dev to design to qa (server-client hydration and UI)
-
As a refresh we have:
1) enacted test coverage for the SSR itself and
2) are proposing to handle server-client data hydration methods (yeet)
So there are two moves:
1) dev to qa (SSR loop)
2) dev to design to qa (server-client hydration and UI)