Yesterday, I competed at CU Boulder’s Colorado Invitational. I got into the meet by the skin of my teeth: the entry standards for unattached athletes were very stringent at 6.80 for the 60 and 21.41 for the 200. Thankfully, the 22.25 I ran last weekend converts to an outdoor 21.40, and the meet director was kind enough to allow me to race.

Training leading up to the meet was almost nonexistent: I was in Denver all week for Vesta’s winter offsite, and I wasn’t able to find a good track to work out on. Between the lack of training and stacking a few nights of bad hotel sleep, I wasn’t expecting great times in the meet.

My first race was at 4:30pm; I showed up to the track around 9am to get in the pre-meet workout that I would normally do the day before. That workout confirmed that I wasn’t super sharp—I struggled to get a cohesive block start.

I don’t think I recovered super well from the pre-meet—by the time I warmed up to race, my calves and hip flexors were slightly sore.

I was back in Bozeman last weekend for the 2023 Bobcat Challenge. In the week leading up to the meet, my coach and I identified that my back was rounded in the “set” position, causing some energy loss on my first step. My PT and I worked on feeling my hip/back angle specifically in blocks which made a huge difference:

The difference was remarkable; I set several workout PRs in my first speed workout after the adjustment. Naturally, I was excited to put it to the test in a competition setting.

Track season’s back!

I opened my indoor season with a 60 and 200 on Wednesday at the Bobcat Preview in Bozeman, Montana (full results).

This year, Adidas entered the superspike game with their Prime SP2. Their athletes found immediate success with the new spike, most notably 2022 world champions Noah Lyles and Shaunae Miller-Uibo. I recently managed to get my hands on a pair of SP2s and put them to the test.

EF Core generates and stores a full snapshot of the database for every migration. For a large data model, like we have at Vesta (come join us!), every migration adds ~15k LOC. Over time, we end up with more migration than application code—in 10 months, we generated over 2 million(!) lines of migration code.

All these snapshots significantly impact compile time, and without configuration, makes interacting with the codebase more tedious and slower. These snapshots also aren’t useful—after enough time has passed, it becomes prohibitively difficult to actually revert N migrations back.

Ideally, we’d be able to “squash” old migrations into one, removing the old snapshots and migration logic while preserving the ability to spin up a fresh database. In the following, I’ll describe how we achieved this at Vesta.