Build notes
and updates.

My home server collects daily prices for 21 stocks and ETFs going back to 2010, Chicago-area road speeds every 15 minutes, and now weather from 8 airport stations. I wanted to know whether any simple rule built on that data beats just buying and holding. The short answer: no. Holding all 21 equally earned 15.3% a year from 2016 to 2026 and was profitable in 9 of 11 years. The best of eight rules earned 14.6%. The part I'm proud of is the test, not the answer. It is easy to make a backtest look amazing. You try enough settings until one wins, and then you report that one. So I built the lab to make that impossible: - Each year, a rule picks its settings using only the five years before it, then gets scored on that year. - A position is decided at one day's close and earns the next day's return. No peeking. - Every trade pays 0.05% in costs. - Next to every honest result, the page shows what the same rule would have claimed if I had tuned it with hindsight. That last column tells the story. Trend following earned 4.2% a year when tested honestly. Tuned with hindsight it looked like 9.5%. Same rule, same data; the only difference is cheating. The four timing rules (trend following, a calm-market filter, a moving-average crossover, buying dips) all earned between 3.3% and 6.0% a year, and only one of them beat holding in more than one year. The three allocation rules stayed invested and only changed how much went into each stock. They came much closer: risk-balanced weights 14.6%, a low-volatility tilt 13.2%, momentum rotation 11.4%. Momentum beat holding in 5 of 11 years, but it also fell 51.4% at its worst, against 35.6% for holding. The traffic question is still open. Every evening a tracker records how congested Chicago's rush hour was compared with the previous 20 weekdays, freezes that number, and later fills in how a basket of rail, trucking and parcel stocks did the next day. It needs about six months before the result means anything, and it cannot be quietly revised in the meantime. Everything is on the new Research page, sliders included. This is research on historical data, not investment advice.

The site got a refresh today. The look is the same hardware-and-console design, just finished more carefully. There are better fonts on Mac and Linux, a header that stays put while you scroll, cards that respond when you point at them, and sections that fade in as you scroll, unless you've asked your device to reduce motion. Jelly Swing Arcade and Couples Act are now on the projects list. The landing page also has a Latest updates log for quick news; the longer stories go here. Under the hood, the ASP.NET Core packages, Bootstrap, and the form validation library are all up to date. There is also a GitHub Actions check that builds every pull request, so a broken build shows up before it reaches the server.

The first TestFlight build was only the start. Since then Jelly Swing Arcade has been through versions 1.0.1 to 1.1.9. Early on came smarter bots, bouncy walls, player names, and a loading bar. Then came spiders and bats, a climb to a summit, a 30-second Tag mode, a How to Play tutorial, a power-up shop, a timed Coin Run, fifteen landmarks on the climb into space, and collectible chests with seasonal variants. Version 1.1.8 was a compliance pass with a privacy disclosure, plus a seasonal preview and some landmark swaps. Today's 1.1.9 fixes a crash when opening the Sparkle chest, gives the bots random effects, fixes a timer, and comes with new screenshots, a new store listing, and a support FAQ. After the nine failed runs in October, every TestFlight build since then has gone through on the first try.

Couples Act is my second game, and it is built for two people playing together. The star is Jolly, a jelly character, in a side-view 3D world. On desktop you move with WASD; on a phone there is a touch joystick. The first night produced a lot: ground, movement, a level select, new jellies with their own skeletons and animations, a start screen, character select, and a meadow with giant flowers and a castle in the distance. The next day added pines, a double jump with a flip, sprinting, and the first neighbor's shack. Thanks to the Jelly Swing work, Couples Act had its own TestFlight pipeline by the end of that first day. On Sunday night, two-player play over Wi-Fi went in, along with a small cookie-catching minigame and a performance pass. Just after midnight came the game's opening scene, called The Heart of Two. Online play will come later. Same-Wi-Fi play comes first.

I don't own a Mac, and Apple really wants you to own a Mac. So the plan was to do everything in the cloud: Godot exports the project to Xcode on a GitHub Actions macOS runner, the runner signs it, and the build uploads to App Store Connect for TestFlight. The game also got a new name for the App Store: Jelly Swing Arcade. The first nine runs of that pipeline failed: - One failed because the workflow file itself was invalid. - One failed while setting up the job. - Five failed decoding the signing certificate and provisioning profile. Getting those secrets out of App Store Connect and the Apple Developer portal, and into a form the runner accepts, was most of the fight. - One failed exporting the Godot project to Xcode. - One got all the way to archiving the signed App Store build and failed there. The tenth run went green, and the next one did too: a signed build headed for TestFlight without a Mac anywhere in the process. That night I added ads and broke it again. Three more runs failed in the export and archive steps, because the Google Mobile Ads Swift package needs its own handling. Pinning Ruby for the export helper, adding the Swift package after export, and signing only the app target instead of every target got it building again before the night was over.

On Sunday night I made the first commit of a small Godot game called Gravity Tax: falling blocks, flipped gravity, and a play area that keeps shrinking. By Monday night it had a real menu, more gameplay, multiplayer support, sound effects, and a performance pass to cut the lag. It also had a web release. The web release is where the first fight was. The GitHub Pages deployment failed three times and was cancelled once before the fifth run finally went green. None of it was hard once I understood it, but every failed deploy is a few minutes of staring at a log. The web version didn't last. I decided the game belonged on phones, and iPhone and iPad became the priority.

I added a private Strava importer to the portal. It connects with OAuth, encrypts the refresh token before saving it, and pulls in up to my latest 100 activity summaries when I press a button. It is deliberately manual. There is no background sync, and none of it shows up on the public site. Most of the follow-up work was the unglamorous part: handling a token refresh that comes back without athlete details, fixing how Entity Framework discovered the new migration, and sorting dates correctly in SQLite. Then two small additions: a reconnect button and elevation in the activity table.

Everything behind sign-in stays private. But a private server is hard to show anyone, so the site now has a public front door. The landing page tells the story from my first help desk internship in high school, through Illinois State and my internship at Old Second, to my role today as a DevOps Analyst. Under that are the projects I build outside of work and the tools I use. This blog is the last piece. Posts are written in the admin portal and rendered as plain text, so nothing I type can run as code in a visitor's browser. It is a small rule, but it means I never have to think about it again.

I wanted one place on my home server for the tools I build, instead of a scatter of ports and bookmarks. Aliens Server is that place: an ASP.NET Core Razor Pages app running in Docker on my Ubuntu machine, with ASP.NET Core Identity on SQLite for accounts and Tailscale for private access. The first version went up in a single day. By the end of it the portal had a redesign I actually liked: white molded hardware on the outside, black console glass on the inside, and one signal-green light that only turns on when something is actually true. That last rule matters to me. The dashboards in here show "unknown" and "not observed" until a real data source is wired in. A status light that is green by default is worse than no light at all. Accounts are provisioned by me, public registration is off, and roles decide what each person can see. Admins get the systems pages; friends get the tools meant for them.