Category: Programming

Playdate Development Is Incredibly Fun

For the last couple of weeks, since my post about Playdate Season 2, I’ve become obsessed with learning the Playdate SDK and learning to make games. The project I’ve been working on as a learning experiment is a Breakout clone that uses the Playdate’s crank for movement, which I’ve titled Crankout. I posted the source on GitHub if you’d like to look at it.

Making a simple game like this, which I can continue to expand and improve, felt like a good strategy for learning game development. Part of my approach to learning new things is to pick the simplest version of it I can think of which still demonstrates how something works. If I can’t start using the thing in some form almost immediately, I tend to get distracted and not get very far. My MiniCalc project I wrote in Ruby is another good example of this I wrote when I wanted to try making an interpreter.

What’s making this fun is that game development is a totally new area for me, and that the Playdate SDK is extremely accessible. The SDK is very bare bones, while still having all the pieces you need. If you look at the official documentation, it’s just a list of functions. There’s no engine or anything like that. It reminds me a lot of making games in QBasic when I was a kid.

If you’re interested, here’s resources that have helped me the most, aside from Panic’s documentation.

The Programming in Lua book. Written by one of the authors of the language. It’s short, approachable, and covers everything in Lua. I read this while taking notes in my bullet journal, and by the end feel like I’ve pretty much got it. There’s a couple of parts I skimmed or didn’t bother doing the exercises for, but I know what they are, so I can go back if those things ever come up. It’s a really small language and easy to learn.

SquidGod’s Playdate SDK tutorials. This guy should be on Panic’s payroll. He’s been putting out videos regularly on the SDK for years, and they’re incredible. Probably the number one resource for learning not just the Playdate SDK, but game development patterns as well. He also has a Discord that he’s active in, and he seems like a really nice guy who wants to help people learn.

Eventually I’m hoping to make a real game I can put on the Playdate Catalog, but for roughly two weeks in, I feel like I’m doing pretty well.

August 17, 2025

Game Development, Gaming, Lua, Playdate
title.love

I put up a small title casing website called title.love built with Ruby on Rails. Right now it is just a single page app with a text field, so it doesn’t really need a back end at all. It was a good chance to try out Kamal however, which, so far, I’m loving. It wasn’t any harder to set up than Heroku, and I can host multiple apps on a $6/month Digital Ocean server.

What I would like to do is expand this into a real website with user accounts and all of that, where you can tag and save your titles. Not that I think that’s a thing a ton of people would use, but it’s a good project for showing off some backend skills. Maybe I will even make a title.love mobile app at some point.

July 7, 2025

Ruby on Rails, Web Development
Xcode’s predictive code completion is worse than nothing

Unlike some of my friends, I’m not the biggest fan of the kind of AI code completion that tries to write blocks of code for you as you type, but I was still kind of excited to see what Apple’s version of that in Xcode would look like and wanted to give it a try.

On paper, it could be great. Xcode indexes all your code and knows everything about your project. Apple controls the entire experience, so the integration between the editor and LLM could be deep and relevant to your project’s code. As soon as you try it, you realize that’s not true. Wherever it’s pulling suggestions from, it doesn’t appear to have any kind of meaningful understanding of your project. Bummer.

The suggestions not being that good isn’t why I had to turn it off — sometimes they’re all right. Not close to as good as Copilot, but okay sometimes. The reason I had to turn it off, and the thing that is absolutely mind-boggling about the feature, is that it makes basic syntactic mistakes all the time. Things like putting the end quote in the wrong place or leaving off parentheses. Every time it made a mistake like this, I had to spend one or two minutes staring at the line, trying to find the error.

That’s not just bad; that’s worse than nothing. The good news is that engineers inside Apple use Xcode too, so I’m certain the team knows how much love predictive code completion needs. Hopefully, they’re spending the time and energy so that this year or next it can go from what it is now to what I was hoping it could be.

May 2, 2025

Developer Tools, iOS, macOS, Programming, swift, Xcode
Loving SwiftUI, missing UIKit.

At this point, I am primarily working in SwiftUI. At work right now, we are doing macOS and iOS, and we’re not using AppKit or UIKit at all. Where I’m at right now in my thinking is that while I do like SwiftUI, I kind of miss the old way of doing things.

UIKit and SwiftUI represent two different approaches to writing user interfaces — imperative versus declarative. I would define imperative as kind of inside out and declarative as inside out. With imperative code, you call a function or method to say “do this thing,” while with declarative UI, you say “render it this way based on the current state.”

Declarative systems like SwiftUI are great because they make a lot of things very simple. Try setting up an AppKit NSTableView versus a SwiftUI Table. It’s way less code the declarative way.

The thing is that I still miss the imperative approach a lot of the time. Being able to say expand this row when I click this button is extremely convenient. With a declarative system, if they don’t give you a way to declare it, you’re just out of luck. When you can declare it, that becomes something like set the variable of expanded row IDs to X so that my view can update and read that variable to show the expansion. It’s pretty circuitous.

I do wonder how much of SwiftUI works the way it does to be more familiar or natural to people coming from web development. Or maybe it was just inspired by those systems?

Here’s where I’m landing. It’s not that I want to go back to the old way — I don’t. I like writing less code. What I’m saying is that both systems have a lot of value, but that treating the SwiftUI approach as inherently better is wrong. Neither approach is better or worse, they’re different. I will probably continue to pine for the other whenever I work in one for the rest of my career.

April 24, 2025

iOS, Programming, swift, SwiftUI, UIKit, Writing

Shell Script Template

I wrote myself this small template as a starting place for when I’m writing shell scripts. I just wanted something basic with enough structure to remind me how I like to do things. I thought maybe it would be helpful for other people who don’t write shell scripts too often but want to them to be nice when they do.

#!/usr/bin/env bash

# Uncomment for error handling
# set -e  # Exit immediately if a command exits with non-zero status
# trap 'echo "Error on line $LINENO"; exit 1' ERR
# trap 'echo "Script interrupted."; exit 130' INT

show_usage() {
  echo "Usage: $0 ..."
}

process_item() {
  local item="$1"
  echo "Processing '$item'"
}

main() {
  if [ $# -eq 0 ]; then
    show_usage
    exit 1
  fi

  # Your code here
  for var in "$@"; do
    process_item "$var"
  done
}

main "$@"

March 2, 2025

Shell Scripting

Something I Miss When Coding Swift

I know it’s not safe and goes against the whole ethos of Swift, but after having worked a lot in Ruby, being able to generate methods at runtime is a killer feature, and I miss it dearly. Swift is all about safety and static analysis, and those are totally valid goals for a language to have. That doesn’t change the fact that manually writing out a bunch of nearly identical methods across multiple classes is tedious.

I would also argue that in a lot of cases, even if the Ruby approach is less safe, being able to generate methods and properties at runtime can be less error-prone. If I only have to write that code once, it’s a small surface area for bugs.

Before I used Ruby on Rails, it had a bad reputation in my mind, because all I ever heard was how much it relied on “magic.” At the time, I interpreted magic as meaning that how Rails worked was somehow unknowable. It’s not, though. Once I started actually learning Ruby and then Rails, I could see exactly what was happening.

The magic of Rails is really just Ruby’s dynamic runtime — Rails uses introspection and code generation to define methods dynamically instead of upfront. Since I had a really strong background in Objective-C, which also features a dynamic runtime, this immediately made sense to me.

And just to be clear — I know Swift. I’m a Swift programmer. I’ve been using Swift as long as it’s existed. This isn’t a knock on Swift. I’m not even sure Swift should be able to do this. What I do know is that I hate writing more code than I have to, and when a language saves me from that, it makes me very happy.

February 22, 2025

Ruby, Ruby on Rails, swift
You’re Never Going to Fix Your Technical Debt

I’ve been thinking this week about how I write code and the quality I want to aim for. I’ve worked some pretty big and successful projects. I’ve seen things. So with that in mind, here’s what I’ve decided. There are only two times technical debt will ever be addressed: upfront or never.

What counts as upfront?

Upfront is anytime before the feature is “done.” I’m a pretty big fan of a style I call “getting in there and making a mess.” It’s actually one of the things I really like about SwiftUI. The whole style of writing SwiftUI encourages hammering out your view to the point where things are functional and then using the refactoring tools to break things up into components. Love that.

Figuring out what your abstractions are or where the objects are hidden is super valuable. It’s also generally only going to happen upfront.

You were probably wrong

I don’t care how many Uncle Bob or Martin Fowler books you read, your architecture is probably going to suck, you’ll never really fix it, and you’re going to spend the rest of time with it hanging around your neck. It’s that feeling where writing code in a project goes from being exciting to something where you mutter under your breath before starting each day once more unto the breach.

Your clean architecture you made super DRY will be the biggest piece of technical debt you have.

Eventually the other people at your job will start telling you why it’s actually a good thing. You don’t understand! We’re not like other companies, we’re cool and quirky and we needed to abstract away every API in the framework we use and put our own crazy thing on top of it. They’re wrong. Those people have been indoctrinated.

You don’t want to be the person starts talking about rewriting everything after their first week, but after a little while if everything still feels crazy and like it makes everything suck a little more, it probably does. Trust that instinct. Or don’t! Eventually you’ll be indoctrinated too. Or you’ll quit or get fired. One of those.

You never know less than when you’re starting

This is a truism that made sense to me as soon as I heard it the first time. The worst time to make decisions is upfront. You know so little. This is a terrible to commit to anything.

Wait. Didn’t I say that the only time decisions get made is upfront? Yeah, I did. Listen, life contains a lot of contradictions. Things aren’t always going to make sense. You should get used to that.

So what should you do?

The thing you can do upfront is refactor as you go (don’t overdo it) and make it as easy possible to change your mind later. Delay, delay, delay. Just make as few decisions as you can, so when you have to do the next thing.

Since I should probably finish this with something kind of actionable, here’s my recommendations.

The biggest thing I would think about is cohesiveness and getting an ability to feel out if things are remaining that way as you try and pull out your abstractions.

Avoid heavily abstracting away the API of whatever framework you’re writing on top of as much as possible.

Never (never, never) import a complex overarching architecture into your project. Do not. Especially not one that I promise you it will be terrible. My biggest red flag is anything that starts asking you to pass calls through multiple things to do one thing. Keep things as simple as you can as long as you can.

I get that this had some contradictions in it, but as I said, life is like that sometimes. The thing with technical debt is to minimize and delay. Also, don’t listen to thought leaders.

#programming #architecture

June 23, 2023

Programming, Software Architecture
MVC Discussion on the Rooftop Ruby Podcast

If you enjoyed my MVC Isn’t MVC post from a couple of days ago, you might also be interested in the latest episode of the Rooftop Ruby podcast. Joel and I discuss our thoughts on the post before getting into more detail on MVC, the forgotten editor controller, and how we might be able to implement something closer to the original MVC on the web using modern technologies like morphdom and Turbo Stream broadcasts.

You can find Rooftop Ruby by searching for it in your podcast app or clicking the link above.

#programming #podcast #ruby

June 22, 2023

podcast, Programming, Ruby

Category: Programming

What counts as upfront?

You were probably wrong

You never know less than when you’re starting

So what should you do?