kelan.io

Not Today, Rivers

Sun, 15 Feb 2026 00:00:00 GMT

Ticket Party 🎉

Thu, 12 Feb 2026 00:00:00 GMT

I've been using the [Codex app](https://openai.com/codex/) a lot since it came out (which was what, not even 2 weeks ago? Things are moving _fast_). It's a really nice app. I had been using Claude Code a bunch, and enjoying the results, but I never loved the terminal interface (TUI) app. I know it's [technically impressive how they do it](https://x.com/trq212/status/2014051501786931427), but I'm sitting here using a Mac, with a GUI and buttons and scrollable things… Let's use 'em! So, Codex.app is a nice UI improvement[^model-comparison]. But now that I'm using it more heavily, I'm quickly getting overwhelmed with all the tasks it's showing me. [^model-comparison]: And I haven't noticed any difference (better or worse) in the quality of the model results between ClaudeCode and Codex. I haven't done any exhaustive comparisons, but the current generation models all seem plenty capable for what I'm asking them to do. And it's really a huge leap forward from even a few months ago. The app's UI model is simple enough: add projects to the sidebar, and then in each project, you can start multiple chats. It's great for having parallel conversations. But since the responses (and coding and testing) in each one can be a little slow, **I was often waiting for one thing to finish before I could start the next**. I could probably use worktrees to avoid some of the blocking. But that doesn't actually help all that much with a Mac or iOS app, where you don't want to be running too many copies of the app in parallel. It's easier to develop/test a single change at a time. So I found myself starting one conversation in Codex, then while it's working, start planning the next (and having it write a `something-plan.md` file to my `docs/` dir), but then waiting to implement that plan until the previous conversation was done. But then the order of chats in the sidebar would shift, and I'd forget which one was next, and which plan docs were ready or done or not, and I'd end up feeling overloaded. Furthermore, when I'd come back to the project later, I'd have forgotten what I was working on, what order of things should go next, etc. So I wanted a little task-tracking tool to help myself and the agent. I had thought that [beads](https://github.com/steveyegge/beads) was maybe supposed to help with this (e.g. by letting me add a bunch of TODO tasks), but I never quite understood how it worked. And the more I read, the more it seemed like it didn't actually work that way. So, I figured I'd just make my own task tracker[^task-tracker]. Meanwhile, I saw [this similar idea from Daniel Duan first](https://hachyderm.io/@dduan@mastodon.social/116039123027386744), which reinforced that there was something useful in this idea. So I set off to build my own, and lucky for me, I had an eager LLM ready to help. [^task-tracker]: Said every software developer ever, at least once in their career. I mean, how hard could it be? So Tuesday morning I started a new project in Xcode, added the dir to Codex, and started describing my idea. That night, it was working well enough to be adding features to itself. And now two days later, I think it's interesting enough to share. It's nowhere near done, or even MVP, but I wanted to share an early glimpse of it, to see if it resonates with anyone else. ## The Basic Idea Instead of starting a chat and then going synchronously back-and-forth with the agent, I wanted to queue up a bunch of "tickets" for it to do. When it's done with one, it should move on to the next. That takes my sometimes-slow responsiveness out of the loop. But it also lets me refine the backlog while the agent is working (i.e., taking advantage of the agent's sometimes-slow responsiveness). And yes, I said "backlog". No, I'm not at all a Professional Scrum Person. But yes, I sorta did build myself a bug tracker. I suppose everyone does it at some point. And at least I did it quickly. So, as I'm working, I just add tickets for things I think I want it to do next, as the ideas strike me. Then I manually sort them in the backlog, add more notes, and (as of late last night) can have concurrent "planning" discussions in a chat interface on each ticket. Then when I'm happy with the plan, I can mark it as `Ready for Implementation`, and it will get processed in the queue when the agent gets to it. ## Current Status - The name is terrible (I have been trying hard to not get hung up on little details such as the name — it's actually easier to do that when I can so quickly make progress on features, so that's fun) - The UI is rough, but fairly functional - The "Run Loop" part doesn't fully work yet — but it's close - You can manually approximate it, by just clicking "Start" on the next ticket in the backlog - The code probably needs a lot of refactoring - In fact, this has been a fun experiment to learn how good the coding agents are these days (quite good, actually!) - I know there are things that aren't ideal - But I also feel confident that I can do large refactorings as necessary; the agents are actually quite good at that. So, again, I'm not worried about class/function names, because I know I can correct those later, as I get a better understanding of how the whole thing should work. - But, it's mostly "self-hosting" at this point. I'm writing most of the new features in TicketParty by using TicketParty. Yay! 🎉 ## Future Ideas There are a ton of obvious next steps (big and small), but the areas I'm most excited about are: - When the backlog has more refined details in it, then I can queue up a bunch of tickets, start the "run loop", and just sit back and watch the changes roll in. - If the agent has questions, it should queue them up for me. This can go both ways! - When I return to my computer, I should get a dashboard with the list of changes that are done, some ways for me to review them and comment on them, and see a list of questions for me (and a way for me to quickly give answers) ## At a Higher Level I think the interesting thing is that I could build this tool for myself in just a few days. It would have taken me weeks before, so I'd just never have done it. Maybe a more clever engineer than me would have figured out how to simplify it in a way that was more feasible to build (like, just a text file with tasks, and then a bash loop iterating over that). But I love that now I can have it both ways — I can quickly build a tool, which is nicer than it has any right to be. You can tell by the name, the crude UI, and the lack of polish that I'm not slowing down to make too many careful decisions. But I've come to realize that's actually another powerful thing about LLM-assisted development: I know I can ask the agent to update/refactor something later, so I don't slow down to overthink it up front. And in hindsight, I think that's a thing that really slowed me down as an engineer in the past. So I'm going faster now not just because I have an LLM writing code, but because it's helping me jump right over all the mental hurdles that used to trip me up in the past. As an aside, I know there is a lot of buzz around [OpenClaw](https://openclaw.ai/) right now, but frankly I feel a little skeptical about it. I don't yet trust these agents that much, to give them that much autonomy. And also, I _like_ thinking through the details of my projects. So, I think TicketParty is a meaningfully different approach; **instead of asking the agent to "do everything" for me, I get to micromanage it to do the tasks that I want**. And this tool just lets me do that in a convenient way. But, admittedly, I haven't used OpenClaw, so please LMK if I'm misunderstanding or re-inventing a wheel here.

Voids

Fri, 28 Apr 2017 00:00:00 GMT

I recently ran into a problem where I was confused by the difference between `()` and `Void` in Swift. **TL;DR** `Void` is a type, but not a value, and `()` is both a type and a value. ## Sometimes they're the same My confusion arose from the fact that I think of them as interchangeable, when it comes to function signatures. For example, these two are the same: ```swift func asyncWork1(completion: @escaping (String) -> Void) func asyncWork2(completion: @escaping (String) -> ()) ``` ## But not always However, given this generic `enum` definition[^1]: ```swift enum Result { case success(T) case failure(Error) } ``` [^1]: The fact that it's a `Result` isn't important, but just is the real example of where this came up for me. I was trying to represent the `success` case, but without a value. So I tried this: ```swift let result1: Result = .success(Void) ``` But that gave this (somewhat cryptic) error: ``` error: member 'success' in 'Result' (aka 'Result<()>') produces result of type 'Result', but context expects 'Result' (aka 'Result<()>') ``` It's because `Void` is just a type, not a value, and the compiler is expecting a value here. So, to fix it, we use `()` instead, which is a value. ```swift let result2: Result = .success(()) ``` And, since we've realized that the issue is `Void` is a type, not a value, it seems obvious to try this, which also works (but does feel a bit odd to me [^odd]): [^odd]: And not just because it's literally just adding 4 extra, unnecessary characters. ```swift let result3: Result = .success(Void()) ``` ## Parting Thoughts I do wonder a bit about why `()` is allowed as a type as well as a value [^constructing-nothing]. I think it has to do with the subtle details of Swift's syntax, and tuples, and the desire to be able to write `() -> ()` as a function signature, instead of `Void -> Void`? But, it did lead to some confusion in this case (no pun intended). [^constructing-nothing]: The `Void()` solution briefly made me think it would be funny to try to explain this by saying "the empty parens `()` are used for calling the constructor of the type next to it, and since there is *nothing* next to it, it constructs a `Void`". But that's almost *too* plausible. 🙃 --- *Thanks, as usual, to [Jacob](https://twitter.com/jtbandes) for pointing out the type/value difference to me here.*

Slack Abbrevs

Sat, 10 Dec 2016 00:00:00 GMT

Based on actual experience this week, the risk of confusion between these two different private channels (with the same Becky, but two differnet Jameses) is not just theoretical. I was especially befuddled by the fact that Slack added the last initial to Becky (which didn't need it -- because it's the same Becky), but not to James (which did need it). But then I learned that Becky manually edited her first name in Slack to include her last initial, to avoid this type of confusion. What a twist ending!

The answer is 4 nails

Sat, 10 Dec 2016 00:00:00 GMT

The other day I was wondering about the origin of the name of the band Nine Inch Nails. So I thought I'd ask Siri… Everybody knows the old rule of thumb: Two inches per nail, you can't fail. (Except if you then try to convert to nails again.)

TableFlip Registration

Wed, 05 Oct 2016 00:00:00 GMT

I've been beta testing [TableFlip](http://tableflipapp.com), which is a nice macOS app for editing Markdown tables. It was just [released today](http://christiantietze.de/posts/2016/10/tableflip-launch/), so check it out! (And, if you want a discount, check out the [share for discount](http://tableflipapp.com/share-for-discount/) promotion.) I really like this touch when entering your registration code:

Promise Lifetime Question

Sun, 18 Sep 2016 00:00:00 GMT

I'm starting to explore using Promises more in Swift, especially after reading Soroush Khanlou's [posts](http://khanlou.com/2016/08/promises-in-swift/) [about](http://khanlou.com/2016/08/common-patterns-with-promises/) them. I like the idea a lot, but I have some questions about best practices for managing the lifetimes of related objects (for specific use-cases). ## Motivating Example I'm trying to wrap some preexisting Cocoa API that uses the delegate pattern for callbacks, and making an API that returns a `Promise`. Let’s say you have this API that uses a delegate for callback from some async operation: ```swift protocol ExampleAPIDelegate: NSObjectProtocol { func workCompleted(result: String) } class ExampleAPI { static var sharedInstance: ExampleAPI weak var delegate: ExampleAPIDelegate? /// The result of this async work comes via the delegate callback. func startWork() { … } } ``` Here's how you might "wrap" it, so that you can deal with it by using a `Promise` instead: ```swift /// The enum is just for namespacing enum ExampleWrapper { /// Private helper to serve as the delegate private class DelegateShim: ExampleAPIDelegate { let fulfill: (String) -> Void let reject: (Error) -> Void init (fulfill: @escaping (String) -> Void, reject: @escaping (Error) -> Void) { self.fulfill = fulfill self.reject = reject } func workCompleted(result: String) { fulfill(result) } } static func promisedWorkResult() -> Promise { return Promise(work: { (fulfill, reject) in let shim = DelegateShim(fulfill: fulfill, reject: reject) ExampleAPI.sharedInstance.delegate = shim ExampleAPI.sharedInstance.startWork() }) } } ``` Which is nice to use: ```swift ExampleWrapper.promisedWorkResult().then { result in print("got \(result)") } ``` Specifically, the advantages are: * You don't need to conform to the delegate protocol (and thus be an `NSObject` subclass) to get the result. * You can put the code that handles the result directly in-line, rather than in a separate method.

Note about memory management I initially thought that the caller needed to hold a strong reference to the returned Promise object. But, this actually isn't necessary. Soroush pointed out that "Promises retain themselves as long as you have any completion blocks attached to them, and they clean themselves up on complete."

## The Problem: DelegateShim's lifetime But, there is still a memory management problem with this specific example. Nothing is keeping a strong reference to the `DelegateShim` object, aside from `work` closure. But that closure completes (and releases its references) before the delegate callback comes (when the async ExampleAPI work finishes). So, the `DelegateShim` object is gone by that point. ## Possible Solutions 1. One thought I had was to make a subclass of `Promise`, specific for this use case, and have that hold the `DelegateShim` object as a property. But, [Soroush's implementation of Promise](https://github.com/khanlou/Promise/blob/master/Promise/Promise.swift#L86) is a `final class` , so I couldn't subclass it. That could be changed, but it gave me pause, because I’m not sure if making it `final` was arbitrary, or if there really is a good reason to force you never to subclass it. 2. Another idea would be to use `objc_set_associated_object()` for the promise and delegateShim, but that seems very unappealing, especially because it ties us back to all the ObjC runtime and `NSObject` baggage that I'm trying to avoid. 3. If the `work` block (passed to `Promise.init(work:)` was held until the Promise fulfilled, that would solve this issue. The local reference to the `DelegateShim` in that closure would be enough to keep it alive until it's fulfilled. But, that requires a change to the `Promise` code. And, maybe that isn't good in most other use cases for Promises? Maybe it makes it too easy to create reference cycles and leak objects? 4. If we want to leave Promise as-is, we can manually approximate idea #3 by blocking at the end of the `work` closure, so it doesn't return until we're done. For example, we could wait on a semaphore that we don't signal until after the promise has been fulfilled. That would look like this: ```swift enum ExampleWrapper { private class DelegateShim: ExampleAPIDelegate { let fulfill: (String) -> Void let reject: (Error) -> Void /// Use this to block the `work` closure until the delegate callback comes, to keep the /// DelegateShim alive. let doneSemaphore = DispatchSemaphore(value: 0) init (fulfill: @escaping (String) -> Void, reject: @escaping (Error) -> Void) { self.fulfill = fulfill self.reject = reject } func somethingHappened(event: String) { fulfill(event) doneSemaphore.signal() } } func start() -> Promise { return Promise(work: { (fulfill, reject) in let shim = DelegateShim(fulfill: fulfill, reject: reject) ExampleAPI.sharedInstance.delegate = shim ExampleAPI.sharedInstance.start() shim.doneSemaphore.wait() // <-- This makes this block not exit until the semaphore is signaled }) } } ``` ## Feedback Welcome Are there other ideas that I'm missing? Is there already a common pattern that I should use here? Or, am I "holding it wrong", for whatever reason? [Let me know](https://twitter.com/kelan/status/777632098853105665)!

Playgrounds for Libraries

Sat, 10 Sep 2016 00:00:00 GMT

I recently noticed (in the [Interstellar](https://github.com/JensRavens/Interstellar) project) that you can include a Playground with your Swift library. I think this is a great way to provide some documentation and examples, and also to give a new user a way to easily start experimenting with using the library. So, this is my attempt to raise awareness about this, and to ask library authors to include a Playground in their projects. And, to lead by example, I [just opend a pull request to add this](https://github.com/khanlou/Promise/pull/2) to Soroush Khanlou’s [Promise](https://github.com/khanlou/Promise) library. ### How To It turns out to be pretty easy to do this. If you simply include the Playground in your workspace (or even just `.xcodeproj`), and then you make sure the `.framework` has been built (e.g. by building a scheme in your project that includes the framework), then you can simply `import MyFramework` at the top of your Playground, and use the public API. I’m guessing there is some magic that Xcode is doing to make this build/link correctly.

Synchronized Wrapper in Swift

Mon, 29 Aug 2016 00:00:00 GMT

This is an idea I've been tinkering with recently, to help enforce thread-safe access to properties in a class instance. It still needs some more refinement, but I wanted to write up my thoughts and progress so far, to start to get feedback.

Background

I recently noticed a pattern in my code where I use a dispatch semaphore, or serial queue, to achieve thread-safe access to some critical properties in a class. This works fine, but isn't enforcible at all. A simple headerdoc comment of /// -note: Only access these properties while holding the above lock is way too easy to overlook, even with the best of intentions. So, I was wondering if there was a way to have the Swift compiler help enforce this.

General Approach

The basic idea is to wrap the critical property in something that keeps the value private, and forces you to access them only using specific methods that do the locking/synchronization for you.

Here's the basic definition. We're using a simple DispatchSemaphore to do the locking.

```swift class Synchronized { private var value: T private let lock = DispatchSemaphore(value: 1) init(_ value: T) { self.value = value } } ```

It only holds a single value, but you can put multiple things in there by putting them all in a struct. And, then you know they will always be updated together.

```swift struct CriticalState { let title: String var things: [String] = [] var sublteDerivedValue: Int = 0 // for example, this is the length of the things array } let criticalState = Synchronized(CriticalState(…)) ```

Notice that value is private, so you can't access it directly.

```swift let criticalString = Synchronized("test") // This doesn't work: print(criticalString.value) ```

error: 'value' is inaccessible due to 'private' protection level

So, you have to go through accessor methods.

Here is one that gives you "read access" to the wrapped value. It waits for the semaphore first, and signals it after it's done.

As a side note, defer is nice here for a few reasons. First, it lets us return the output of the block without having to store it in a temporary variable, and second, because it will still signal the semaphore if we exit this scope via the block throwing.

```swift /// The unwrapped value is passed in to the given closure, as a read-only value. And, you can /// then calculate some value from it (the R), and return it from the closure, and /// it's returned from the .use() method. func use(block: (T) throws -> R) rethrows -> R { lock.wait() defer { lock.signal() } return try block(value) } ```

Here is how it looks to use it.

```swift let criticalString = Synchronized("test") let uppercasedString = criticalString.use { string in return string.uppercased() } print(uppercasedString) ```

TEST

What about modifying the value? Let's add another method for that.

```swift /// This method lets you pass a closure that takes the old value as an `inout` argument, so /// you can use that when determining the new value (which you set by just mutating that /// closure parameter. /// - note: The lock is held during the whole execution of the closure. func update(block: (inout T) throws -> Void) rethrows { lock.wait() defer { lock.signal() } try block(&value) } ```

Which we use like:

```swift let criticalString = Synchronized("test") criticalString.update { string in string = "new value" } ```

So, that's the basics. It's pretty simple, really. But, there are some subtle details and limitations to explore a bit more.

Limitation with Reference Types

Astute readers might notice that this whole approach has a fundamental flaw if the wrapped value is a reference type. A caller could keep a reference to the wrapped value, and mess with it outside of the closure.

Unfortunately, I don't know of a great solution for this. If you have any ideas, please let me know! But, even so, I still think that this whole concept has some value, because it's at least one step better to encouraging proper synchronization. You have to actively subvert it to break things, rather than simply forget to hold a lock at the write time (pun intended — sorry).

A simple example of this potential for abuse would be to just return the value from the .use() block.

```swift class CriticalState { … } let criticalState = Synchronized(…) let unsafeReference = criticalState.use { $0 } unsafeReference.mutate() // <-- This is bad! ```

So, I actually think it's worth addressing this head-on, and making a method for this, but naming it with an appropriate warning.

```swift /// - note: If the wrapped type a reference type, you shouldn't use the return /// value it to modify it, because that won't be synchronized after this methods returns. func unsafeGet() -> T { lock.wait() defer { lock.signal() } return value } ```

However, this operation is actually "safe" for value types, because the caller just gets a copy of the value, so it can't then affect the thing inside the wrapper. So, I would like to make two different "flavors" of this Synchronized struct: one for value types, and one for reference types. But I'm not sure if it's actually possible to express with Swift's generics. Again, if you have thoughts/feedback, let me know!

Further Questions and Issues

Locking

Using a DispatchSemaphore as the lock is not necessarily the best choice (but was a simple choice to illustrate the general pattern here). For further reading, start with this thread on Twitter. The major issue is priority inversion (like OSSpinLock) because, as Steve Weller points out, "Queues execute the waiters in order. Locks/semaphores use an unknown/unpredictable method to pick next", suggesting that a serial DispatchQueue would be better.

But both of those lock all access, even preventing two concurrent readers, which seems like it should be supported. So, something like a pthread_rwlock_t, can allow multiple readers as long as nothing is writing.

In a future post, I'll explore different locking implementations, with a way to easily swap them out on a case-by-case basis.

Naming Options

I'm not sure what name is best (for both the whole class, and the accessor methods). Some ideas are, for the whole class: class ThreadSafe<T>, class Critical<T>, class Protected<T>, for the use() method: func read(), func with(), and for the update() method: func write(), func mutate().

Since it's most important to consider how they look/feel at the call site, here are a few examples:

Here's the setup

```swift struct State { var statusMessage: String var items: [Item] } let state = Synchronized(State()) ```

Accessing with "read" and "write"

```swift let message = state.read { $0.statusMessage } state.write { state in state.items.append(Item()) } ```

Accessing with "use" and "update"

```swift let message = state.use { $0.statusMessage } state.update { state in state.items.append(Item()) } ```

Again, I'm open to suggestions, so let me know what you think!

Thanks

Thanks to Jacob, James, and the rest of the folks at Upthere for giving me early feedback about this idea during a discussion over lunch. And preemptively to anybody who has any feedback!

Swift - didSet on Local Variables

Thu, 25 Aug 2016 00:00:00 GMT

In Chris Eidhof's recent post I learned that you can use willSet and didSet on local vars. This is just a quick write-up to explore it a bit.

Here is a simple example; just print out a message every time a variable is set. Something like this could maybe be useful for debugging?

```swift var s1 = "initial value" { didSet { print("changed s1 to:", s1) } } ```

Now change the variable, and see that our print() is called.

```swift s1 = "new value" s1 = "newer value" ```

changed s1 to: new value changed s1 to: newer value

Recording History

Here is another example, that keeps a history of previous values.

First, set up an array to store the history of changes, and capture that in the closure. Note that I never said this is a good idea — it's just interesting that it's possible.

```swift var history = [String]() var s = "initial" { willSet { history.append(s) } } ```

Now, set it a few times.

```swift s = "a" s = "b" s = "c" s = "d" ```

And see the history was recorded.

```swift print("history:", history) ```

history: ["initial", "a", "b", "c"]

Final Thoughts

I'm not sure if this is an intended feature, or some weird side effect of the implementation. And, I don't know what an actual good use of it is. But it sure is a neat trick! Also, you can tell this isn't a very common thing, because Xcode's auto-indent doesn't handle it very well.

But, it seems like it wasn't a total accident, because of the error message if you try to do it on a let variable.

```swift let s = "initial" { didSet { print("test") } } ```

error: 'let' declarations cannot be observing properties

I'm not exactly sure what "observer properties" means, but at least it correctly points out that this only make sense on things that can actually change.

Follow Up

Turns out, there are might be some practical uses for this after all. My esteemed work colleague, Marc Palmer had an inspired idea to use this to implement a DSL, based on his experience with Groovy. I'm familiar with similar tricks from Ruby (using #instance_eval and friends), but I never thought that kind of thing would be possible in Swift.

Unfortunately, he noticed a problem (in an update in his post). It appears that multiple repeated sets to the local var get optimized out, so only the last one actually triggers the didSet. So this technique isn't quite reliable yet. But maybe there is some way to fix this, with some further experimentation.