What Is a Beer Mile?

A beer mile is a footrace, typically run around a track, with one gimmick: competitors must drink a beer before each lap of the track, completing 4 beers and 4 laps by the end of the race.

The race goes like this: competitors line up, beer in hand. The beer is a choice left to the competitor, but it must be at least 5.0% alcohol, and it must be at least 355ml (can or bottle). At the gun, competitors open their first beers and start moving. They must finish their beer before exiting a short “transition area”. Upon finishing, they can start their first lap. Once the lap is finished, they grab a second beer, and the process repeats for 4 laps in total.

Running and drinking is hard, but the real challenge is in keeping the beers down. Competitors must drink their entire beer, and if you throw up at any point during the race, the penalty is running an extra lap. In trying to drink the beers as quickly as possible, the beer tends to foam, and you’ve really got to focus on not letting it bubble its way back up your throat.

The current world record? As of writing, it’s held by Corey Bellemore, who ran a blistering 4:27 beer mile. If you want to know more, there’s a set of official rules and more results at beermile.com.

My History as a Beer Miler

2019, Running My First OCRC Beer Mile

I ran my first beer mile in 2019, hosted by the Ottawa City Run Club, at a tiny residential track in the suburbs of Ottawa. The run club would host interesting little races like this from time to time, and it was the first time I had heard of the beer mile. I signed up, just hoping to have fun with it, have a few beers with friends, and try something new.

The race ended up going…. alright. My primary goal was to just not throw up, and I did at least accomplish that! But it was certainly close. The way the foam creeps up your throat is hard to describe, but it really does feel like it’s going to force its way out.

I ended up finishing in 11:51, my beer drinking and laps getting slower and slower over the course of the race. The race wasn’t officially timed in any way, but I’ve got my results on Strava.

2024, The Renegade Mile, and an Invite to the Vancouver Beer Mile

In 2024, I discovered my favourite Vancouver run club, the East Van Run Crew, hosted their own beer mile. Unfortunately, I discovered this, along with some friends, just slightly too late — the race had already sold out. But, undeterred, we decided to run our own beer mile an hour before they had scheduled to run theirs, at a nearby track.

Turns out, we had actually ended up at the same track the Vancouver Beer Mile was planning to run at, and they offered to time our race for us. We lined up, and I was running my 2nd ever beer mile.

The race went well, I PR’d by quite a bit, finishing in 7:45, keeping the beers down, and pushing through the runs quite a bit faster. In this attempt, somehow almost every lap was faster than my fastest lap in 2019. From a fastest lap time of 2:02 in 2019, to a slowest lap time of 2:15 according to Strava.

So impressed by our ambition, Cory, race director of the Vancouver Beer Mile, invited us to compete in the subsequent official race, just 45 minutes later. Not one to back down from a challenge, I decided I’d go for a second round, and my 3rd ever beer mile.

You’d think 2 beer miles in a row would be hard, but there really wasn’t much to the 2nd one. The first 4 beers had nearly an hour to settle, and I had definitely begun to feel them. It almost made the running easier, to be a little tipsy… almost.

In the end, I followed up my 7:45 beer mile with an 8:10 beer mile. I do recall being absolutely goofy that evening, having 8 beers in just over an hour.

2025, The Vancouver Beer Mile, and Becoming Delusional About the Podium

In 2025, I came back to the Vancouver Beer Mile, having successfully registered for a spot in advance, and I was really starting to have some confidence in my beer-mile-running ability. I had only ever really paid attention to my friends, but I knew at that point I had become the fastest beer miler among them. In the lead up to that race I really started thinking a bit more about not just doing well against my previous attempts, but doing well in the race overall.

I had settled on a couple beers that sat well in my stomach and felt I could confidently keep down, I was generally a fast runner, faster than I had been at almost any other point in my life. I felt locked in.

The race itself is a blur. I remember friends cheering me on, I remember the feeling of the foam travelling up my throat, I remember trying to catch my breath before starting to chug the next beer. While this one’s on Strava, it’s also on Sportstats. Those told a clear picture: I was a fast runner, but a slow drinker. On average, I was running ~1:16 laps, and spending ~33 seconds per beer. The winner? ~1:12 laps, but just ~17 seconds. That was a huge gap. However, the podium wasn’t so far off. 3rd place was running ~1:21 laps (slower than me), but finishing his beers in ~15 seconds (much, much faster than me). I figured maybe I had a bit more in my legs, but I knew I had a lot more in my drinks.

2026, Putting It All Together at the Fraser Street Beer Mile

In 2026, the Vancouver Beer Mile organizers took a step back, and the Fraser Street Beer Mile took over. Costumes highly encouraged, I donned my Spider-Man suit once more. This year I was hoping to take up to a minute off my time, knowing I could drink the beers much faster than I had been in the past, and hoping to sneak my way onto my first podium.

At this point in my illustrious career as a beer miler I was confident I could keep the beers down while running. Once I finished a drink, got moving, and got the first couple burps out, the rest was easy. Stay cool, stay fast, don’t lose the leaders.

I started out in 6th place, finishing my first beer in 14 seconds, and heading out on the first lap around the track. Starting out in 6th had me slightly worried, but I felt confident I could get the next 3 beers down with some consistency, that I hoped the other racers wouldn’t be able to muster. I finished the first lap in 1:19, not my fastest, but I knew holding back just a touch was going to help with the beers.

For the 2nd beer, I did my best to get it down in one breath. In my opinion, that is what makes or breaks a strong beer mile. You finish a lap, it’s just shy of an all-out sprint, you’re gasping for air, and now you’ve got to hold your breath while you put back a beer so it doesn’t go down the wrong pipe. If you stop now, you’ll have to catch your breath again, and it’s only going to take longer. Hold your breath, suck the beer back, and get back to running as quickly as possible.

The 2nd beer ended up taking me 22 seconds, and I headed out, 8 seconds under my time at this point from 2025. I left the transition zone in 2nd place by just a second or two, but over the course of the next 200m I closed that gap. I lost a few seconds on the lap, leaving me just 3 seconds under my time from 2025, but in first place overall!

The 3rd beer went down surprisingly smoothly, but just a bit more slowly. I did end up having to pause and catch my breath a second time, and finished this beer in 26 seconds. However, that put me well under the 40 seconds it had taken me in 2025, and I headed out on the 3rd lap, still firmly in first place.

On the 4th lap, I, once again, stopped to catch my breath, but still put the beer back in just 27 seconds, giving me, to this point, a ~35 second lead over my 2025 result. I headed out on the last lap in 1st place, unbeknownst to me that 2nd place would kick that last lap, leaving on their 4th lap 10 seconds behind me, and finishing just 1 second behind me.

In the end, I’d finish the Fraser Street Beer Mile in 6:45, a 35 second PR over my 2025 beer mile, and in first place overall! For the first time in my life, I had not only finished on the podium, but had actually won the race! I was a bit in shock, that I had held myself together and legged out a win.

The full results of the race are on Sportstats and my own Strava activity is here.

What’s up Next?

The 2026 edition of the Fraser Street Beer Mile won’t be my last. I know there’s still so much room for improvement. There’s a huge gap between my average ~22 seconds per beer, and the elite beer drinking times of ~6–8 seconds. My laps are quick, but they could be quicker. The past couple years my focus has been on longer (much longer) races, but I’ve been thinking about stepping back from focusing on ultramarathons as my A-races each year, and diving back into the world of road racing. My eventual goal is to run a sub-6:00 beer mile. With a focus on speed and drinking, I think there’s plenty of space to find those ~45 seconds of improvement.

For now though, I’ve got my next couple races to focus on, and my wedding in the very near future.

But I’ll be back to take on the Beer Mile once more, in due time.

Mostly the party was a fun opportunity to gather, make some cheeky jokes at the expense of ourselves and our friends, and lament on the trends we feared would be in…

Here’s my list of trends. Some are personal, some are a little bit of a reflection on society.

OUT: Cellphones in the bedroom

Doomscrolling, distractions – some form of these showed up on many peoples’ lists at the party. My practical version: stop bringing cellphones into the bedroom. Remove the possibility for late night scrolling keeping you up too late, or starting your day with the dread of the state of modern politics.

Practically, this has meant plugging our phones in overnight right outside our bedroom door. We get up, we silence the alarms, and we crawl back into bed for a short snooze. But eventually I do get out of bed earlier than I have been, and my phone isn’t always the first thing I gravitate to anymore, once I am up (but, again, it’s only been a week. Hopefully habits won’t die too hard).

IN: Buying flowers for no reason

You don’t need a reason to tell someone you love them; you love them, and that’s enough of a reason in and of itself. Surely, then, we don’t need a reason to express that love in a physical and tangible way that delights and brightens one’s day and space.

In that regard, I would propose that buying flowers for your partners, your dates, your friends, is IN for 2026. You don’t need a reason, you don’t need a corporate holiday marred by overpriced flowers, you just need love in your heart, and a desire to express it.

As a couple, we buy flowers with some regularity, and this more just a reminder to continue doing that, and to perhaps inspire friends to as well.

OUT: GitHub

2025 saw a lot of tumultuous activity in the United States, for immigrants, minorities, and the under-privileged, at the behest of the latest administration. Spearheading much of the fearmongering and violence is Immigration and Customs Enforcement (ICE). GitHub, acquired by Microsoft in 2018, have had their fair share of controversy alongside their parent company, including partnering with weapons manufacturers. But with the recent role of ICE in the state of affairs in the US, GitHub’s contract with ICE, and the pludering of GPL code for Copilot, it’s time for a change.

This past fall I made the move to sourcehut, migrating all of my projects, deleting the code from GitHub, and leaving directions for visitors to my larger projects. Drew DeVault, the founder of sourcehut, has his quirks, but he’s firm on privacy, and the value of free and open-source software.

Sourcehut may not be the right move for you, but I promise you there’s a tool that suits your needs out there:

• The Zig programming language moved to the non-profit Codeberg
• Tangled offers decentralized git hosting and collaboration
• Fossil is a weird one, focused on simplicity and self-hosting

IN: Women’s Sports

Women’s sports in North America are seeing a boom. The Professional Women’s Hockey League had their inaugural season in 2023-2024, and has since expanded from 6 teams to 8, including the Vancouver Goldeneyes. If hockey’s not your sport, the Northern Super League also kicked off this year, a professional women’s soccer league recognized by the Canadian Soccer Association.

The gameplay is elite, the women are pros, and as the two leagues get their footing, tickets are significantly cheaper than any mens’ leagues in the city.

• This winter check out the Vancouver Goldeneyes at the Pacific Coliseum on the PNE Fairgrounds.
• When the NSL picks back up in April, find the Vancouver Rise in Burnaby at Swangard Stadium

IN: Personal Blogging

Everybody should have a blog. Not a tumblr, not an premium X account with a 10,000 character limit. The Internet has as much breadth as it has depth, and I implore you to share your own

Publish a blog and let me hear your thoughts. Writing pushes you to understand topics better, and has numerous other benefits. Talk about what you love, what you fear. Show me your poetry or impress me with your personal progress.

Here are a couple blogs I follow diligently, and some recent posts from them I found interesting. Download an RSS Reader and follow your favourites:

• the writer’s room shares her writing and thoughts on her daily life. Check out her recent queer cosmic horror short story
• Jenn is a mystery to me, but she writes endearingly about all sorts of things, including tech, culture, and her dead, deadbeat gay dad
• Dead Moms Book Club writes about her life, her grief, her aspirations. Another Mother’s Day presents a vulnerability I felt in my core.

OUT: The Algorithm

Jenny Odell, in How to Do Nothing: Resisting the Attention Economy writes about her Twitter feed:

Scrolling through the feed, I can’t help but wonder: What am I supposed to think of all this? How am I supposed to think of all this? I imagine different parts of my brain lighting up in a pattern that doesn’t make sense, that forecloses any possible understanding. Many things in there seem important, but the sum total is nonsense, and it produces not understanding but a dull and stupefying dread.

The Algorithm is everywhere, and it’s designed to capture your attention to commoditize it and sell it to the highest bidder. It’s an unfortunate symptom of much of the free Internet, that driving engagement drives ad sales and boosts revenue, and revenue is king.

In 2026, we are casting out the Algorithm and instead embracing RSS and mailing lists. RSS allows you to follow all the interesting people, blogs, news, etc. without needing to be exposed regularly to the whims of The Algorithm.

I have a feed of bloggers, indie devs, and friends that I have curated and can check in on once a day to see if there’s anything new or of note to me posted by them recently. RSS allows me to aggregate these sources and peruse them simply, at my leisure, without needing to traverse bookmarks or keep a hundred tabs open.

My RSS reader of choice is IconFactory’s Tapestry for iOS, which also presents me a chronological feed of my Mastodon timeline.

Find creators, writers, comedians, intellectuals elsewhere. I guarantee you they’re posting somewhere outside the walled gardens of social media, where you can follow them on your own terms.

Joan Westenberg writes a little bit more about ditching big tech in favour of the open web, and how the algorithm has transformed how we form opinions.

To a better year

Every year is an opportunity to invite self-reflection, and consider what’s important to us. 2026, for me, is going to be about dedicating time to the things I love that bring me joy, and pulling myself away from the platforms and media that don’t.

Grow UP! is an in-person game jam hosted locally in Vancouver, that partners with local non-profits to bring awareness to their causes through game jams. I first heard about it during Full Indie’s annual summit, and attended their November iteration.

For their November iteration, they partnered with 2 non-profits:

• Our Social Fabric is a non-profit fabric store that sells donated fabrics and fibre arts supplies, helping keep ‘waste’ fabric out of the landfill. They’ll sell to anyone with an interest in sustainable sewing supplies, including the fibre arts and slow-fashion communities.
• SPEC Repair Café is a monthly event hosted by the Society Promoting Environmental Conservation, inviting the public to bring their items in need of repair for free support in mending, repairing, and fixing their items. From bikes, to clothing, to computers, they offer free support in cooperation with the City of Vancouver to help keep waste out of landfills.

An aside: the City of Vancouver has recently cut funding to the SPEC and various sustainability and arts programs by the way of Ken Sim’s ‘Zero means Zero’ budget cratering funding for a wide array of social services, to support a zero-percent property tax increase and a $50 million budget increase for the Vancouver Police Department. Let city councillors know how much this sucks via their website.

A week prior to the event, they announced the theme this time around would be mending, and, to me, that immediately screamed “sewing”. The first night of the event, Friday, was focused on brainstorming and team building. We did a group brainstorming project, where everybody was contributing to an ideas board, what exactly “mending” meant to them. Once there were lots of ideas percolating, people started to group up to begin collaborating.

I proposed an idea based on my understanding that fabric scissors, for cutting fabrics and textiles, are fragile and prone to nicks when used to cut things other than their intended use. What if we had a game where the goal was to carefully cut and sew patches over holes, trying to ensure you didn’t damage your scissors, while moving speedily to complete the repair? This idea eventually evolved to be the basis of Sew Far Sew Good.

I ended up with a team of ~7 in total, including 3 programmers, 2 2D artists, a producer, and an SFX artist. Initially, it sounded a bit like there might be too many cooks, but our devs were either new to gamedev (me) or new to the tooling, meaning we’d be focused on building something fairly small scoped, and hopefully wouldn’t trample on each other’s work too much. Our 2D artists, producer, and SFX artist also found themselves collaborating with multiple teams, or working on their own games on the side, and I think that made for a nice balance, where everybody could find time to contribute to Sew Far Sew Good, and otherwise focus on their own thing.

Overall, the weekend went by quickly, with our team regrouping Saturday morning to kick off game development. By early Saturday, we hadn’t actually fully settled on a game to build… Those of us that arrived earliest started familiarizing ourselves with the tooling of Godot, and just generally working on what we wanted, not fully committed to collaborating. When our producer showed up, they brought up some of the ideas we had had the night before, and suggested we settle on one that seemed approachable, tightly scoped, and fun enough to play. A new Godot project was created, and we were off.

My focus in the game was on the character’s movements. I worked on keyboard controls, as well as programming the animations one of our artists delivered. Looking back, the work was really simple in the end, and the code reflects that. But with it being my first real foray into Godot, it took me most of Saturday to get just a basic character walking animation working!

This screenshot constitutes most of Saturday’s work! As you can see, besides some other variables being set by signals elsewhere in the code, it isn’t very complex at all. But bumbling through this was a fun challenge perfectly sized for my absolutely beginner Godot skills.

The team managed to get a solid demo by Saturday night, and most of Sunday was spent refining, and expanding. We added a couple more shapes to our game, we cleaned up the menus, and I worked on an algorithm to generate sewing points around the patches to randomize the gameplay a little bit.

By the end of Sunday, I’m proud to say, we had a fully playable + complete game! With 3 different shapes, and an overall accuracy report at the end of the game.

Overall, I’m really satisfied with what we accomplished. We managed to scope out a simple game perfectly sized for the weekend and skills that we had as a team. We collaborated effectively, finding things for everybody to do, and helping each other when we got stuck on a tricky bit of code, or tough interaction.

Despite feeling a bit overwhelmed at the start of the weekend, by Sunday I was getting really comfortable with Godot. It’s been an incredible tool, and was so easy to learn thanks to their detailed documentation.

You can play the game here.

Poem 1 (Sakura Award)

cherry petals  
find a home in my hair  
where do I belong?

Poem 2

Six feet underground
Are the cherry blossoms
Still blooming?

Why 5-Pin Bowling?

I started working on the first version of the Bowling Companion (its original name!) in January 2015. I was in my 2nd year of university, and was going to have to start applying to co-op positions for that summer. I was looking for my niche, something that I could build that would be unique, that I had a need for, and that I would be passionate about building. I had been bowling most of my life at that point, and realized that there wasn’t really a good option for 5-Pin Bowling scorekeepers on Android. Actually, I can’t remember if there were any at all! So I set my sights on building the first.

The 5-Pin Bowling Companion: The Java Era

Version One: Functional, but Ugly

I built the first version of the app over the course of about a month. I focused primarily on the functionality – things like data storage, score calculations, and statistics. Back then the Bowling Companion was written in Java, with XML, Views, and SQL. Every screen the app contained was a separate Activity, statistics were collected and calculated in an AsyncTask within the StatsActivity, and the UI was not quite fleshed out…

One thing that was good enough about this first version though? It helped me stand out among other co-op candidates, and I landed my first internship as an Android developer thanks to being one of the only ones with actual Android experience!

Version Two: More Functional, Less Ugly

Once I finished the first version, and had it functional, I made the most logical decision – scrap it and rebuild it from scratch!

I figured at that point, I had learned so much in the past month, from what APIs were available, to how to better structure my code, that I had already built up so much technical debt, and the performance was likely so poor I could easily make major improvements. So I copied the existing code over to a new folder, and created a new Android template from scratch.

Since the app was mostly working the way I wanted it to at this point, I focused on the design. You can see there are some pretty significant changes in the look of the app from v0.1 to v0.2.

Version Three: The Initial Release

Once I had the app looking pretty well how I wanted to, trying out this new “Material” thing Google was toting, I decided that I had, once again, come so far in my learning, it was time to scrap it and start all over once again. This time around, I focused on performance, functionality, and code structure.

I referred to the past implementations a lot, but starting from scratch again allowed me to easily make the changes I needed to, without having to worry about compatibility with what I had already written. Much of the underlying code, like the database, remained the same, but the entire structure of the app changed. I moved from Activities to Fragments, and pulled a lot of the scoring logic out of the activities into utility functions.

This rewrite would eventually become the first version launched, on April 1st, 2015.

Early Lessons from the Early Days

1. Kill your darlings. I wanted to be proud of this, I wanted to share it with a community I was a part of, and I wanted to provide something useful. The first version of the app, while functional, was not a delight to use! Redesigning it on top of the existing code would probably have taken me much longer, and I might not have gotten that first version out for months, with a lot more technical debt.
2. Think about your data model. The biggest mistake I made in these early days was being far too restrictive with the SQL constraints and datatypes. It made refactors difficult, when I better understood how I should be formatting the data and defining relationships. Some features were impossible for a while until I restructured the database! Taking the time to think about your long-term data model, and leaving yourself some wiggle room in the future can be extremely useful, before you lock yourself into something that becomes impossible to build on top of.

Rewriting in Kotlin

In February 2018, not too long after Google announced official support for Kotlin in Android Studio, I decided to rewrite the Bowling Companion in Kotlin. I experimented with the language a bit before diving in, and found that I really liked a lot of its early ergonomics especially when compared with Java. At this point I just recently graduated and was returning to working at Shopify on their native (at the time) Swift app, and I liked that Kotlin reminded me a lot of Swift.

The rewrite would end up taking me about 7 months, starting in February, with the first Kotlin version being released in September 2018. I don’t fully remember the process, but I do remember that I did not do it component-by-component, instead opting to fully rewrite the app from scratch and convert it all at once. Probably not the best idea, especially since up until this point I had never written a single unit test for the app, but it was hardly the app’s first rewrite! But the Bowling Companion has always first and foremost been a playground for me to explore in, and this was just another exploration.

In writing this blog post, I found the first couple commits, which I think are pretty comical – the first commit, a complete deletion of the entire Java source code, and the second commit, a “Hello World!” Kotlin template. Then, in September, the 3.0.0 Release of the Kotlin rewrite.

The months following that release I was plagued with crash reports from BugSnag. Mostly IllegalStateExceptions, but there was quite a variety. I chased those bugs down and fixed what I could. I don’t have a ton of recollection of this time, I’m mostly just looking through GitHub Issues to jog my memory.

Taking a Break

In 2020, I ended up mostly taking a break from working on the Bowling Companion. There were few, if any, bug reports or feature requests coming in, and I had picked up some other projects. I was mostly content with where the app was at. I had removed the ads and Google analytics, as I in my mind I didn’t want there to be any burden to maintain it – the app was completely free and detached, and therefore I offered it as-is. I would work on it when I wanted to, on my own terms.

The last version I ended up releasing of this iteration of the app was 3.2.0, in August 2020, targetting SDK 28.

Approach for iOS

In 2022, I started working on the first version of the Bowling Companion for iOS. Mostly I was looking for a new native iOS Swift project to work on, while I was working with React Native in my job. I had recently learned about The Composable Architecture, had some experience building with SwiftUI, and decided to go all in on both for this app.

With how old the Android app had become at this point, I knew I wanted to match its featureset, but I wouldn’t be using its design for any inspiration. I relied on SwiftUI’s default styling primarily, and built an all new UI for the app. This also gave me a chance to rethink the structure of the app from a UX perspective, moving some content to top-level tabs, but leaving the hierarchical nature of Bowlers > Leagues > Series > Games as the primary way users would interact with the app.

Overall, the Bowling Companion for iOS would take me just under a year to build. It wasn’t until March of 2023 that I settled on the name “Approach”, and the first version of the iOS app would release in September 2023.

Jetpack Compose and building Approach for Android

During the process of building Approach for iOS, Google announced that they would be removing unsupported apps from the Play Store, and any app that wasn’t targeting at least SDK 32 (I think) would become unavailable to new users. Of course, as mentioned above, the Bowling Companion only targeted SDK 28, and quite a bit had happened in the ~4 years since its release.

Some of the major hurdles I encountered when thinking about how to address this were:

• Kotlin, and especially Kotlin’s Coroutines, had undergone a major version update with breaking changes
• Views were no longer the default recommended by Google, and Jetpack Compose was now preferred
• The Charts library I was using, MPAndroidChart had not been updated in some time and was likely abandoned.

Once again, I would lean on my trusty tool, the rewrite. This would now be the SIXTH time I had written the Bowling Companion from scratch, leaning on years of lessons and inspiration, to create what I think is by and far the best version of the app that’s ever existed.

This rewrite ended up taking just over a year to complete, and Approach for Android was first released in September 2024, with feature parity to the iOS app!

Current State of Affairs

As of writing (April 2025), Approach is two native apps, for iOS and Android. Features are generally built in parity, and released in unison!

The iOS app is built with TCA and SwiftUI. It supports iOS 17 and 18. There are 138 modules, including 36 feature modules, 15 repositories, 19 services, and 34 libraries.

The Android app is built with Jetpack Compose, MVVM, and follows Google’s recommended (as of 2025) layered architecture. It supports SDKs 26 and higher, and targets SDK 35. There are 92 modules, including 20 core modules, 36 feature modules, and 36 feature UI modules.

In total, in the repository there have been 3,986 commits to main, averaging just over 1 commit per day! From a clean clone, cloc reports 65,526 lines of Swift across 902 files and 66,347 lines of Kotlin across 901 files. In total, it reports 161,776 lines of “code”, but that includes SVGs, some generated localizations, and some template files.

See you in another 10 years! Maybe I’ll be talking about Kotlin Multiplatform, Skip, or something as of yet unreleased!

Advent of Code

Every year since its inception I’ve participated in Advent of Code, an annual advent calendar of coding challenges that get released throughout the month of December, with the eventual goal of completing each day and saving Christmas.

Challenges are released each night at 12AM Eastern Time, meaning that I get them at a cool 9PM Pacific. Most nights I hope on a call with some friends and we chat about past challenges and when we’ll encounter certain theories or formulas that have been the hardest challenges in past years.

This year, I ended up with a total of 40/50 stars (challenges solved) at the end of December.

Of all the challenges this year, I think the one I had the most fun with was Day 14, simulating the movement of robots, and finding when they arrange themselves in a Christmas tree shape. You can find my code here which was to basically just continue the simulation and search for a bunch of robots lining up in a row. How I actually solved it realtime though was printing every state of the simulation to my terminal and just using Cmd+F to search for an unlikely number of robots in a single row – I think it was ~10 or so, and it took me straight to the state that output the tree! I ended up 324th overall that day, one of my best performances this year.

Hot Chocolate Fest

Every January in Vancouver Hot Chocolate Fest begins. Their website is always a little difficult to navigate, and it’s never easy to find nearby participating cafés with good flavours. So this year I gave myself a fun little challenge – 3 days to build a better app than they had. Here’s the final result.

First, scraping the data. The website is annoying to navigate and, so too, was the data source. I ended up scraping 2 pages – the first for the vendor names and details of the hot chocolates they were selling, and the second for the vendor locations from a custom Google Map.

With the data scraped and cleaned up into convenient JSONs for me to read, I began building an interface. I chose SwiftUI simply because I have familiarity with it, it’s quick for bootstrapping, and I wanted this done fast. I also chose SwiftData for the little data I wanted to store alongside the scraped data. This ended up being a mistake – I’ve never used SwiftData personally, and it wasn’t intuitive to map the data I had to the storage format I wanted/SwiftData expected. In the end, I switched over to Pointfree’s Sharing library, which simplified things a lot.

The end result was a simple little app that listed all the vendors and flavours, with a search by name, or a filter by allergens, as well as a map with details of the vendors and offerings. Unfortunately, Hot Chocolate Fest only lasts 1 month and I started this project halfway into the event. Hopefully I can dust it off next January and use it then!

NaNoWriMo

As I do every year, I attempted to complete NaNoWriMo this November. The goal of NaNoWrimo (National Novel Writing Month) is to write 50,000 words over the course of a month, averaging 1,667 words per day, on one’s way to finishing the first draft of a novel.

I’ve always loved writing, though I generally stick to much more short form writing, but I still aspire to write a novel someday. NaNoWriMo humbles me every year, as I realize just how much of a commitment it is, and, more than that, how hard it is to write something good!

I do enjoy the few writing sessions I get out of it each year though. I generally have some semblance of an idea going in, and then after a few days I lose interest in that idea and move on. I’m still searching for the novel idea that’ll make me want to keep writing.

Approach

Approach is the 5 Pin Bowling app I build for iOS and Android. This month I didn’t spend to much time on it, instead preferring to focus on Advent of Code, but I did finish a few small tasks.

Adding High Series of X Statistics

One of the most useful things about Approach is the statistics it offers, reporting on a variety of aspects about your bowling and you’re improving or where you need to focus your game. These statistics can be charted as a series of points, or accumulated over time to a singular value.

Approach has a system for calculating the statistics, which queries the user’s games, and passes the games to a set of objects which perform calculations based on the properties of the game, and return the final statistic values. This makes it fairly quick and simple to add new statistics into the app.

This month, a user noted that there’s a “High Series of 3” statistic, tracking the highest total series the user has bowled for a series of 3 games. But often leagues are 4 or even more games, and there was no way to measure improvements in those leagues.

Therefore, this month I added a number of statistics for “High Series” of 2 up to 20 games.

Advent of Code

December 1st marks the beginning of Advent of Code, a month-long coding challenge that releases a new puzzle at midnight EST each night, where coders all over the world attempt to parse the puzzle and determine a solution as quickly as possible.

I’ve been doing Advent of Code since it first launched in 2015, and I’ve built up a small library of helpful utilities over those years. However, they’re all written in Python because I used to use Python a lot more back in those days, for work or personal projects. But I rarely write Python at all anymore. In fact, the last time I wrote any Python was actually during last year’s Advent of Code. I’ve found that it leads to me spending too much time remembering the intricacies of Python’s list comprehension, or the syntax and tools of my own library.

This year, I’ve decided to attempt to solve all the days using Swift, my preferred language of choice. I spent some time in November converting my personal CLI tool for running the challenges from Python to Swift, and have also converted a number of my personal utilities over to Swift as well.

I post all my Advent of Code solutions on GitHub, and this year will be no different!

I’ll have more of a write-up on how it goes at the end of the month!

Vancouver Writer’s Fest

This month was Vancouver’s annual Writer’s Fest, and I finally decided to attend some of the events. I always take a look at the festival’s events and am never really in too much of an active writing mood, but this year I decided to make sure I made it more of a priority and to go to at least one event.

In the end, I actually ended up going to 4!

The most useful was, I think, Night Class: A Workshop with UBC School of Creative Writing, where various UBC professors of their creative writing department came to give very condensed lectures and then a short writing prompt. My biggest takeaway from this event was one of the professors (I think it was Whitney French, though I might be misremembering) talked about for her to really get into writing, she had to figure out how her brain worked. For me, I definitely have trouble choosing and focusing on a single task. What works for me when I’m coding is that I let myself pick up and drop tasks very quickly – short, little bursts of intense focus, and then drop it and switch to something new, until I find something that really catches me and I can dedicate time and deep focus to it. Sometimes I have to pick up and drop the same thing multiple times before I can really take off with it. I’ve never applied this style of thinking and working to my writing. I always try to pick one project and see it through for a while before I drop it and never return to it, usually even dropping writing altogether for weeks or months at a time. I’m going to try some different approaches this November to see if I can coax some better writing out of myself this month.

NaNoWriMo

Speaking of November, NaNoWriMo is kicking off next month, an annual challenge to write 50,000 words and finish the first draft of a novel. It’s much less about writing anything of substance, and mostly just about volume – writing and building the habit of writing!

I’ll be doing little to no coding for the next month (if I can keep myself honest…) and I’ll be focused on writing instead.

Approach

Approach is the 5 Pin Bowling app I build for iOS and Android. This month I focused on iOS and data management.

Automatic Backups

Approach for iOS uses GRDB, a framework for working with SQLite from Swift that makes it really simple to query your SQLite DB with strong typing and robust error handling and concurrency. Perfect for Swift.

Unfortunately, one issue I’ve had with GRDB is figuring out how to safely and effectively sync the database to iCloud. Approach doesn’t charge any money or have a premium plan (yet) and I’m not quite willing to front the costs for a fully fledged backend sync, so it’s gone without any sort of cloud syncing up until now. There’s an option for users to export their data to keep it safe, but I’m not sure you can rely on non-technical users to do that (especially the aging demographic of bowlers).

My solution? I eventually realized that SQLite conveniently works out of a single file. All the data is stored there, and we can move or copy that file easily to create a backup! So all I had to do is use GRDB’s built in backup command to copy the database to another file, then I could sync that file to a folder in the user’s iCloud (as long as they’re signed into an Apple account).

Backup syncing will be enabled by default, but users will be able to disable it and delete the files from their iCloud if they can’t spare the room. It’ll backup with some regularity, and we’ll make sure the backups don’t get too stale or take up too much room. That’s all still a work in progress, but coming soon!

Imports from Android

I had a user reach out mid-October and ask why they couldn’t get their data to import correctly from the exported file from their Samsung phone, onto their new iPhone. The reason was that I had never actually built support for this! Let’s understand why this was the case, and how I built support for it.

iOS Data Format

When using GRDB’s automatic encoding and decoding for records, column names end up matching exactly how you define the corresponding variable (for example, a League belongs to a Bowler through the bowlerId foreign key, which is GRDB will write the column name). You can overwrite this default by explicitly defining CodingKeys on a Codable record, but I opted to use the default behaviour.

Another default, enums are encoded as their String representation, so the enum League.ExcludeFromStatistics has two cases, include and exclude and the SQLite values reflect that:

Android Data Format

Approach for Android uses Room, the de facto data storage solution for the platform. It has slightly different defaults.

When defining your models, you can easily override the column names directly inline, otherwise they will match your variable definition. This led me to mix the Kotlin standard camelCase with SQLite standard snake_case names, appropriate for each platform. A League’s bowlerId property in the Kotlin model would be reflected as bowler_id in the SQLite table column:

In Kotlin, enum class values are usually defined in UPPERCASE, and the value stored in SQLite reflects that:

Supporting Imports

With these platform differences in mind (among others), I couldn’t simply swap out the underlying DB file when importing, so I had to take a slightly custom approach.

First, I let the user pick the file from their filesystem. iOS will give you a URL as a result, and I start by copying that file to a temporary location (that I clean up at the end of the process) so the system can’t lock my access or delete it out from underneath me while I’m trying to process the file.

Next, I look at the file extensions and headers and try to determine what sort of file is being imported. When exporting, Approach for iOS uses GRDB’s backup function to cleanly write to a fresh SQLite DB File. Room doesn’t expose this as easily, so instead I zip up the sqlite and sqlite-wal files and give the user a single zip file. That means when importing I need to know if I’m dealing with a SQLite file or a ZIP file and act accordingly. Other files are unsupported and the app will report an error to the user.

Once I have the primary SQLite file, I open it with GRDB and try to perform a few reads to see if I can determine the format. GRDB uses migrations and a grdb_migrations table to track which migrations have been applied. I know that I can import any Approach for iOS file that has no newer migrations than the current app has – any older and GRDB will automatically handle the migration, any newer and the database is in a format we can’t understand. Room uses a hash value to define its DB versions, so I can inspect those.

For any supported iOS DB versions, I just copy the file to Approach for iOS’s DB file location and let GRDB handle the import/migration. For supported Android DB versions, I perform a series of queries and writes to ensure all the data gets copied over correctly. These queries will have to be kept up to date as the database format evolves over time, but that’s a trade-off I was okay with!

Once the DB file has been prepared, we attempt to open it and if it all succeeds, we let the user inspect the app and validate everything imported correctly – there is always an option to revert.

Unfortunately, I didn’t make the cut this year.

Instead, I share my poems with you:

Poem 1

"Your time will come" they say
as if we couldn't be
cherry blossoms in march

Poem 2

Children dying, crying
for mothers. Don't they know
the cherries are blossoming