Top-to-right, then top-to-bottom:

1. Mexican Hat
2. Red Morning Glory
3. Dogweed
4. Wallflower
5. Sweet Four O’Clock
6. Prickly Poppy
7. Eyed Gilia
8. Crag Lily
9. New Mexico Hop
10. Heartleaf Morning Glory
11. Purple Geranium
12. Red Cinquefoil

Gila Wilderness

📷 Sony α 7C II

Materials

I’ve used Ripstop by the Roll in the past, and I still think they’re best general source for MYOG projects (wide selection, good pricing, although shipping isn’t great).

• 0.66 oz MEMBRANE 10 Taffeta Nylon: One of the lightest options, fully downproof, and a nice feeling
• 0.5 oz Noseeum Mesh: I cut 3.5" strips from this, as it’s lighter than the precut baffle tape
• Gutermann Tera 80 thread
• Grosgrain ribbon: 3/8" and 3/4" widths
• Low profile center push buckles
• 1/16" Shock Cord
• Anchorable Cordlock (glow-in-the-dark, so I can find them at night)
• 900 FP goose down (from Amazon)

I considered 0.56 oz nylon, but my research concluded the weight savings weren’t worth the durability decrease.

The goose down is my main risk on this project. It’s not treated to handle water and is from an unknown source, but is way cheaper than RSBR’s 850 DWR down. Since I’m currently in a drier climate, I’m taking a risk on moisture management. Although I think the supplier shorted me a bit on weight (I think the 1 lb includes the bag it’s shipped in), I’m reasonably happy with it.

Patterning

I mostly did my own patterning. Dubber Designs has a generator, but I wasn’t able to import it properly into Apple Numbers or Google Sheets. It did provide some good guidance on down calculations. Ripstop by the Roll has a one-pager, but I didn’t do a full taper like they do.

vanCapare, HollowCartographer, and durianbae were good sources of inspiration on Reddit.

My rough down calculations are in Google Sheets.

Some of my decisions were:

• Long enough to fully cover my head. I generally sleep with my head fully covered and didn’t want to construct a separate hood.
• Partial taper around the legs. I get some weight savings this way, and it accommodates my side-sleeping.
• Four sleeping pad straps spaced along the body.
• Fully closed footbox. This means I don’t have a cinch at the foot, and prevents slipping off the pad.

My final measurements:

• 50" width
• 78" height
• 34" long taper, down to 35" wide at the toes
• Baffles are 3" thick and approximately 5" wide (10 vertical baffles, 6 horizontal baffles, and 2 in the footbox)
• ~10% overstuff

This required two shapes, cut twice for the top and bottom. The arc in the footbox’s length is the same length as the width of the bottom of the main body.

Baffles

Baffle design is a deep topic on its own, with a lot of options.

I seriously considered Karo baffles, but because I have experience sewing box baffles (from a pair of down pants I made my wife a few Christmases ago), I was confident enough to attempt them again.

I decided on a split vertical/horizontal design: upper body vertical and lower body horizontal. This seems to be the most popular option for DIY projects. Vertical avoids down clumping on the sides while sleeping, but it does make stitching a more complex (since you’re sewing along the long edge in a narrow tube). Horizontal is easier to construct, but down can clump at the sides when sleeping.

I do think chevron or diagonal designs could have benefits, but the complexity and margin for error seem quite a bit higher.

Construction

Construction of box baffling requires thinking inside out.

1. I started by sewing the box baffles on the wrong side of the bottom side layer of fabric. I tried to curve along the baffle material from my seam allowance to the center at the edges of my fabric, which adds a rounded finished edge.

2. I then sewed the footbox’s arc onto the base of the main body of the quilt.

3. Then, I sewed along the edge of the entire quilt except the top edge, wrong side to wrong side. This includes my straps, ensuring they’re on the inside. I now have an inside-out quilt, with box baffles sewn to one side, with raw edges exposed. When I flip this right side out, the edges are nicely finished, and my straps are exposed.

4. To fill with down, I used a length of PVC and PEX. I 3D-printed a removable cap for the PVC and a pusher to attach to the PEX. I filled and measured down into the PVC on a scale, slid the open end into my space to fill, removed the cap, and pushed the down into the cavity.

5. The next step is the most tedious. Working inside out from the base of the quilt, I sewed the unattached side of each box baffle to the wrong side of the top fabric. When I had 5 or so inches left to sew, I paused (with my needle down) and filled with the correct amount of down. Marking my lines was pretty tricky here, as the quilt was no longer a flat shape.

6. To finish the top edge I sewed a straight stitch, leaving a rough edge exposed. I then attached 3/8" grosgrain loops with my cordlocks attached. I then made a strip of bias tape with a double fold and finished ends, and sewed it on to cover the rough edge. Finally, I fed my shock cord through to finish it off.

Final product

The final product is around 22 oz and was more than warm enough for under 40℉.

Learnings

• The most common error I made was letting the fabric fold under itself while sewing, meaning I was sewing into an additional layer. I needed to pick this out and redo it each time.
• It was really difficult to mark up and keep accurate lines when I was partially through sewing. I’d prefer to figure out a method to fully mark out sewing lines while the fabric is flat. I need to find something better than chalk for this, as it needs to hold up through the several days of sewing.
• I’m not sure if the head cinch is necessary, based on how I sleep. Similarly, I don’t know if I need the strap closest to my head.
• If I were to redo this, I’d go with a shorter baffle with more overstuffing, to avoid down movement and save a little weight.

Skiing in early November in New Mexico

Sipapu, NM

📷 Sony α 7C II

A successful hunt

Grand Teton National Park

📷 Sony α 7C II

Pedicularis groenlandica, or elephant head, in the high alpine of northern New Mexico.

Wheeler Peak Wilderness, NM

📷 Sony α 7C II

I’ve been working on solving this problem. Though it’s not perfect, this post describes what I’ve come up with.

For convenience, the example code in this post uses UIKit only and is simplified to focus on the essentials. Full code (runnable on iOS and macOS) can be found in the sample code GitHub repository. I assume familiarity with SwiftUI and Core Animation basics in this article, as Apple and others provide good documentation.

Architecture

First, we need to connect SwiftUI to the Core Animation layer. This uses UIViewRepresentable and UIView (AppKit’s NS equivalents on macOS).

flowchart TD
    SwiftUI
    ViewRepresentable[NSViewRepresentable/UIViewRepresentable]
    View[NSView/UIView]
    CALayer

    SwiftUI --> ViewRepresentable --> View --> CALayer

Data flow

Our animatable property can be passed through each of these layers. This is simpler with one-way data binding, but by providing access to the SwiftUI binding through the UIViewRepresentable’s coordinator, my example code is bidirectional.

Here’s how our animatable value is passed from SwiftUI into our CALayer’s draw function.

struct ContentView: some View {
    @State var value = 0.0 // source of truth

    var body: some View {
        CustomSwiftUIView(value: value)
    }
}

struct CustomSwiftUIView: UIViewRepresentable {
    @Binding var value: Double

    func makeUIView(context: Context) -> CustomPlatformView {
        let view = CustomPlatformView()
        // this link allows our UIView to write value (and read if needed outside of standard SwiftUI updates)
        view.delegate = context.coordinator
        return view
    }

    func updateUIView(_ uiView: CustomPlatformView, context: Context) {
        // this "pushes" changes into our CALayer reactively, following standard SwiftUI updates
        (view.layer as? CustomLayer)?.update(
            with: context.transaction,
            value: value
        )
    }

    // The coordinator provides access to the value binding from CustomPlatformView
    class Coordinator: NSObject, CustomDelegate {
        var parent: CustomSwiftUIView

        init(_ parent: CustomSwiftUIView) {
            self.parent = parent
        }
    }

    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
}

class CustomPlatformView: UIView {
    // this coordinator provides read/write access to the value
    // for example, a custom gesture recognizer could update the binding
    var coordinator: CustomSwiftUIView.Coordinator?

    override class var layerClass: AnyClass {
        CustomLayer.self
    }
}

class CustomLayer: CALayer {
    @NSManaged var value: CGFloat // animatable property

    override func draw(in ctx: CGContext) {
        // use `value` as needed
    }

    func update(with transaction: SwiftUI.Transaction, value: Double) {
        // we'll fill this in later to respect animations
        self.value = value
    }
}

To summarize why we need each copy of value:

• ContentView: This is our main source of truth and should be considered the canonical one. SwiftUI and most reactive UI frameworks require top-down state passing.
• CustomSwiftUIView: Also inherent in SwiftUI is the data propagation model: passing properties throughout the hierarchy with a single source of truth. Because this is a binding, we can read and write it, but it could be a plain var if read-only access is needed.
• CustomLayer: This is needed for Core Animation to store intermediate values representing state mid-animation. Core Animation duplicates this again within the “model” and “presentation” parts of the layer tree. Writing to this value directly will result in state drift, you must use the Coordinator instead.

Note that we do not need to store the value inside the UIView layer. (In theory, we could move the drawing code into the UIView, but that kind of defeats the point of this post.) Instead, UIView relies on the Coordinator.

Animation

Now that we can read and write our animatable value, we want to animate it. Our goal is to drive all animation from a single place. Additionally, we’d like to use the most modern methods. For these reasons, and because we have to, we’ll use SwiftUI syntax.

Button {
    withAnimation {
        value = 0.5
    }
} label: {
    Text("Animate Value")
}

Custom CALayer Properties

First, we need to enable Core Animation for our custom value property. Two things are required:

1. Make value dynamic by specifying @NSManaged
2. Ensure Core Animation redraws when value changes

class CustomLayer: CALayer {
    static private let animationKeyPath = \CustomLayer.value
    static private var nsAnimationKeyPath: String {
        NSExpression(forKeyPath: animationKeyPath).keyPath
    }
    
    @NSManaged var value: CGFloat
    
    override class func needsDisplay(forKey key: String) -> Bool {
        key == nsAnimationKeyPath || super.needsDisplay(forKey: key)
    }
}

Bridging Transactions

The core component of this technique is using SwiftUI’s Transaction to determine if an animation is active when a property is changed. SwiftUI provides this in the context of a view representable’s update, which we can pass directly into our custom CALayer’s update.

struct CustomSwiftUIView: UIViewRepresentable {
    func updateUIView(_ uiView: CustomPlatformView, context: Context) {
        (uiView.layer as? CustomLayer)?.update(
            with: context.transaction,
            value: value
        )
    }
}

class CustomLayer: CALayer {
    static private let animationKey = "value-animation-key"

    func update(with transaction: SwiftUI.Transaction, value: Double) {
        // additional animation management is omitted

        if let animation = transaction.animation {
            // create Core Animation CAAnimation from transaction.animation
            let caAnimation: CAAnimation = ...
            add(caAnimation, forKey: animationKey)
        }
    }
}

Bridging Animations

Now, we need to transform the SwiftUI.Animation into a CAAnimation. This is a little more complicated. SwiftUI.Animation is fairly opaque. It doesn’t provide access to the type of animation, its configuration, or any way to execute itself as a function.

Instead, we use the fairly hacky technique of parsing the animation’s description and extracting parameters from it.

This is fairly straightforward for spring animations:

nonisolated(unsafe) let fluidSpringAnimationRegex =
#/FluidSpringAnimation\(response: (?<response>\d+\.\d+), dampingFraction: (?<dampingFraction>\d+\.\d+), blendDuration: (?<blendDuration>\d+\.\d+)\)/#

if let springParameters = try fluidSpringAnimationRegex.wholeMatch(in: description) {
    let caAnimation = CASpringAnimation()
    let response = CGFloat(Float(springParameters.response)!)
    let dampingFraction = CGFloat(Float(springParameters.dampingFraction)!)
    let omegaN = 2 * .pi / response
    caAnimation.stiffness = omegaN * omegaN * mass
    caAnimation.damping = dampingFraction * 2 * sqrt(caAnimation.stiffness * caAnimation.mass)
    return caAnimation
}

nonisolated(unsafe) let springAnimationRegex =
#/SpringAnimation\(mass: (?<mass>-?\d+\.\d+), stiffness: (?<stiffness>-?\d+\.\d+), damping: (?<damping>-?\d+\.\d+), initialVelocity: SwiftUI._Velocity<Swift.Double>\(valuePerSecond: (?<initialVelocity>-?\d+\.\d+)\)\)/#

if let springParameters = try springAnimationRegex.wholeMatch(in: description) {
    let caAnimation = CASpringAnimation()
    caAnimation.mass = CGFloat(Float(springParameters.mass)!)
    caAnimation.stiffness = CGFloat(Float(springParameters.stiffness)!)
    caAnimation.damping = CGFloat(Float(springParameters.damping)!)
    caAnimation.initialVelocity = CGFloat(Float(springParameters.initialVelocity)!)
    return caAnimation
}

And we can fairly easily recreate Apple’s default animation:

if description == "DefaultAnimation()" {
    // defaults changed in more recent versions
    if #available(iOS 17, macOS 14, tvOS 17, watchOS 10, *) {
        let caAnimation = CASpringAnimation()
        caAnimation.apply(response: 0.55, dampingFraction: 1)
        return caAnimation
    } else {
        let caAnimation = CABasicAnimation()
        caAnimation.timingFunction = .init(name: .easeInEaseOut)
        caAnimation.duration = 0.35
        return caAnimation
    }
}

However, traditional bezier animation curves are more difficult. SwiftUI produces descriptions that can be regex matched using:

#/BezierAnimation\(duration: (?<duration>\d+\.\d+), curve: \(extension in SwiftUI\):(?<cubicSolver>SwiftUI.UnitCurve.CubicSolver\(ax: (?<ax>-?\d+\.\d+), bx: (?<bx>-?\d+\.\d+), cx: (?<cx>-?\d+\.\d+), ay: (?<ay>-?\d+\.\d+), by: (?<by>-?\d+\.\d+), cy: (?<cy>-?\d+\.\d+)\))\)/#

However, I haven’t yet been able to figure out what the cubic solver is and how to convert its three two-dimensional coordinates ((ax, ay), (bx, by), (cx, cy)) into a bezier curve’s two two-dimensional control points (CAMediaTimingFunction.init(controlPoints:_:_:_:)).

Update 2024-12-10

Thanks to Eric from Play, I now know how to convert SwiftUI’s CubicSolver back to the original Bezier control points.

let pt1 = (
    x: cx / 3,
    y: cy / 3
)
let pt2 = (
    x: (bx + cx) / 3 + pt1.x,
    y: (by + cy) / 3 + pt1.y
)

caAnimation.timingFunction = .init(controlPoints: pt1.x, pt1.y, pt2.x, pt2.y)

Previously, I resorted to explicitly matching against standard timing curves I can explicitly create using SwiftUI and Core Animation. For example, ease in’s cubic solver is:

SwiftUI.UnitCurve.CubicSolver(ax: -0.7400000000000002, bx: 0.4800000000000002, cx: 1.26, ay: -2.0, by: 3.0, cy: 0.0)

And the Core Animation instance is:

let caAnimation = CABasicAnimation()
caAnimation.duration = Double(bezierParameters.duration)!
switch bezierParameters.cubicSolver {
case easeInAnimationCubicSolver:
    caAnimation.timingFunction = .init(name: .easeIn)
}
return caAnimation

Once the animation is created, we configure the keypath it modifies, and its start and end values without our layer’s update function. We also need to ensure we update the spring animation’s duration, as it depends on the value’s range. Core Animation will cut off the animation without this.

self.value = value

if let caAnimation = transaction.animation?.caAnimation {
    caAnimation.keyPath = Self.nsAnimationKeyPath
    caAnimation.fromValue = (presentation() ?? self).value
    caAnimation.toValue = value
    if let caAnimation = caAnimation as? CASpringAnimation {
        // Core Animation will cut off the animation if the duration is not updated
        caAnimation.duration = caAnimation.settlingDuration
    }

    add(caAnimation, forKey: Self.animationKey)
}

Final Result

For my final demo, I want to draw something that shows value animating. I’ll draw a circle that will animate through the vertical center axis of the view. I’ll also print the value as text to visually guarantee it’s changing.

let diameter = 20.0

override func draw(in ctx: CGContext) {
    ctx.clear(bounds)

    // set graphics context to support NSString drawing
    UIGraphicsPushContext(ctx)
    "\(value)".draw(
        in: bounds,
        withAttributes: fontAttributes
    )

    ctx.setFillColor(CGColor(red: 1, green: 0, blue: 0, alpha: 1))
    ctx.fillEllipse(
        in: CGRect(
            origin: CGPoint(
                x: (bounds.width - diameter) / 2,
                y: (bounds.height - diameter) * value
            ),
            size: CGSize(width: diameter, height: diameter)
        )
    )
}

Another feature I want to show is bidirectional data binding. When you click or tap on the custom view, it will interrupt the animation and set the parent to the current state, to keep everything in sync. We can also animate changes from the internal view using the same SwiftUI withAnimation function.

@objc func handleTap(gestureRecognizer: UIGestureRecognizer) {
    guard let coordinator else { return }
    coordinator.parent.value = (presentation() ?? self).value
    removeAnimation(forKey: Self.animationKey)
}

@objc func handleDoubleTap(gestureRecognizer: UIGestureRecognizer) {
    guard let coordinator else { return }
    withAnimation {
        coordinator.parent.value = (presentation() ?? self).value > 0.5 ? 0 : 1
    }
}

Complete code with an example app and Xcode project can be found at https://github.com/apexskier/swiftui-coreanimation.

Taking it further

I’m pretty happy with this approach, especially the ability to drive animations from multiple layers in the stack using the same mechanism. However, it’s not ideal for a few reasons.

From the SwiftUI spring documentation:

When mixed with other spring() or interactiveSpring() animations on the same property, each animation will be replaced by their successor, preserving velocity from one animation to the next. Optionally blends the response values between springs over a time period.

My approach does neither of these things. In theory, when an animated update propagates while an animation is in progress, we could look up the current animation and set the new animation’s initial velocity appropriately. The blocker is the opaqueness of CAAnimations, which don’t provide APIs for access to value or velocity at a given time.

Blending response values is even more difficult, as it would require dynamically changing CAAnimations over time, which isn’t supported.

As mentioned above, I haven’t figured out SwiftUI’s CubicSolver, which I think is a private struct implementing UnitCurve. It represents at least bezier curves, but I haven’t figured out the math or how it works. If you have any ideas, please get in touch!

Ultimately, these issues are due to the closed nature of SwiftUI and other Apple UIs. At the core, animation curves are math. Standard curves are simple functions over time (f(time) = value). Springs are more complex since they’re semi-stateful by taking the animated value into account, but are also deterministic. I’d like to be able to directly call these functions. Unfortunately, CABasicAnimation has no support for this. At first glance at the documentation, SwiftUI’s Animation appears to support this with func animate<V>(value: V, time: TimeInterval, context: inout AnimationContext<V>) -> V?. However, I have not found a way to get ahold of an AnimationContext outside of a custom Animation subclass, which makes this non-viable. SwiftUI’s UnitCurve has value(at:) and velocity(at:) functions that are exactly what I want, but don’t have a spring equivalent, and UnitCurves aren’t accessible from Animation. I could directly implement timing curve functions, but I’d prefer something built-in to avoid building it from scratch.

Update 2024-12-10

In additional to figuring out CubicSolver as mentioned above, I’ve extended the demo project on GitHub to show SwiftUI and CoreAnimation side by side, so you can visually confirm the animations are the same. SwiftUI has noticeable lag, but overall this approach works.

12/13 - The Claus Family

Especially considering the two sequels, not very good. Pretty unconvincing and to-be-expected storylines, both about Santa Claus and saving the biscuit factory. The humor wasn’t great either, but this was probably made worse by watching a dub.

★☆☆☆☆

12/16 - Family Switch

Family Freaky Friday, but not as good. Tenuous connection to Christmas. Lots of writing that had the appearance of jokes.

★☆☆☆☆

12/16 - Love Hard

Pretty good Christmas romantic comedy. The writing and acting were quite good in general, and the characters had more dimension than most rom-coms, especially Josh.

★★★★☆

12/17 - Holiday in the Vineyards

Pretty standard Hallmark-style Christmas romantic comedy, meaning not much comedy and a stretched connection to Christmas (who has a real estate deadline on Christmas Eve?). The son of a fancy wine company has to sneak around a small town to get inside info on buying the vineyard. Falls in love with a sexy local wine lady, and has to reveal his lies. Some gratuitous shirtless abs, and way too public sexy dancing.

★★☆☆☆

12/18 - Christmas with You

A slight deviation from the standard format, an aging pop star surprises a fan for the holidays, falls in love with the dad, and writes a hit Christmas song with him. Not terrible, but not one I need to watch again.

★★★☆☆

12/25 - Candy Cane Lane

This one was a wild ride. A neighborhood’s Christmas decoration contest escalates dramatically. This one was laugh-out-loud funny and I found the animation for the figurines quite effective.

★★★★★

Let’s start with a simple (though contrived) example. I’m writing some code that depends on the go-github library to interact with the GitHub API.

package before

import (
	"context"
	"fmt"

	"github.com/google/go-github/v47/github"
)

type obj struct {
	user string
	gh   *github.OrganizationsService
}

func New(user string) obj {
	return obj{
		user: user,
		gh:   github.NewClient(nil).Organizations,
	}
}

func (m *obj) CountOrganizations(ctx context.Context) (int, error) {
	orgs, _, err := m.gh.List(ctx, m.user, nil)
	if err != nil {
		return 0, fmt.Errorf("couldn't list organizations: %w", err)
	}
	return len(orgs), nil
}

func (m *obj) IsMemberOf(ctx context.Context, org string) (bool, error) {
	result, _, err := m.gh.IsMember(ctx, org, m.user)
	if err != nil {
		return false, fmt.Errorf("couldn't call IsMember: %w", err)
	}
	return result, nil
}

How do you test this? github.OrganizationsService is a struct type, so we’re required to have a direct instance of it to pass type checking. In many cases, this will force your tests to make network calls. Usually, you can pass http.Client and override its behavior, but that gets messy fast.

Setup

The key to testing this behavior is to depend on an interface type instead of the struct. Go makes this easy, which you may not know if you’re used to other languages. In Go, an interface describes behavior that both your code or dependency code can implement. This feature means we can define an interface in our code that github.OrganizationService implements and the compiler will recognize it.

type githubOrganizations interface {
}

type obj struct {
	user string
	gh   githubOrganizations
}

I usually start with an empty interface and add methods as needed. Doing this helps keep my interface as clean as possible, which makes understanding code when refactoring or changing dependencies later easier.

Swapping *github.OrganizationsService for githubOrganizations works because all structs conform to the empty interface. However, I now see errors wherever I use .gh: m.gh.List undefined (type githubOrganizations has no field or method List).

We need to add each of the undefined methods to the interface. If I’m too lazy to look at the docs, I’ll temporarily swap githubOrganizations back to *github.OrganizationsService, jump to the definition of the previously undefined method and port it over.

type githubOrganizations interface {
	List(ctx context.Context, user string, opts *github.ListOptions) ([]*github.Organization, *github.Response, error)
	IsMember(ctx context.Context, org, user string) (bool, *github.Response, error)
}

Writing a test

Now let’s use this interface to write a test verifying CountOrganizations works as expected.

func TestCountOrganizations(t *testing.T) {
	obj := obj{
		gh: mockGHList{},
	}

	c, err := obj.CountOrganizations(context.Background())
	if err != nil {
		t.Fatal(err)
	}
	if c != 3 {
		t.Fatalf("unexpected number of organizations: %d", c)
	}
}

Here’s the real magic: mockGHList is a struct that embeds a pointer to github.OrganizationsService, which we originally depended on.

type mockGHList struct {
	*github.OrganizationsService
}

Go pointer semantics and struct embedding rules mean all methods of *github.OrganizationsService can be called on mockGHList, even when the embedded value is nil. This allows us to run the test without compilation issues, but because github.OrganizationService is nil, the test panics.

--- FAIL: TestCountOrganizations (0.00s)
...
github.com/google/go-github/v47/github.(*OrganizationsService).List

A nil pointer was found when trying to call .List on the nil *github.OrganizationsService. Go struct embedding rules mean that methods defined on the mockGHList object override those on the nested *github.OrganizationsService object. This rule lets us write our mock method.

func (mockGHList) List(context.Context, string, *github.ListOptions) ([]*github.Organization, *github.Response, error) {
	return []*github.Organization{{}, {}, {}}, nil, nil
}

Rerun the test, and it passes!

--- PASS: TestCountOrganizations (0.00s)

Benefits

Single-use, minimal mocks

By wrapping the original struct, we only need to implement the methods our tests directly depend on. This encourages single-use, minimal mock objects instead of manually maintaining large shared mocks.

Any hardcoded mock codifies its expectations of how specific scenarios behave, usually the first tests it’s used in. Those expectations make it harder to use for new tests. As the codebase grows, it either doesn’t thoroughly test new behavior or combinatorially increases in complexity (by introducing [boolean flags](https://martinfowler.com/bliki/FlagArgument.html, for example). At some point, the mock deserves its own tests to track what it’s doing.

Fail-by-default

This pattern fails when executed code makes unexpected method calls, which can help catch accidental changes.

Mocking libraries

I’ve also successfully used this pattern with third-party mocking libraries.

Here’s an example of use with "github.com/stretchr/testify/mock".

type mockGHIsMember struct {
	mock.Mock
	*github.OrganizationsService
}

func (m *mockGHIsMember) IsMember(ctx context.Context, org, user string) (bool, *github.Response, error) {
	args := m.Called(ctx, org, user)
	return args.Bool(0), args.Get(1).(*github.Response), args.Error(2)
}

func TestIsMember(t *testing.T) {
	gh := mockGHIsMember{}
	obj := obj{
		user: "apexskier",
		gh:   &gh,
	}

	gh.On("IsMember", mock.MatchedBy(func(context.Context) bool { return true }), "org", obj.user).Return(true, (*github.Response)(nil), nil)

	result, err := obj.IsMemberOf(context.Background(), "org")
	require.NoError(t, err)
	assert.True(t, result)
}

I still only need to mock the method being called.

Caveats

• Defining an interface does not work when using struct fields since interfaces can only declare methods.
• Auto-complete won’t show other methods available on the original struct type. https://pkg.go.dev is your friend, or you can manually declare a variable of the original type and use auto-complete on that.

You can view the code from this post at https://github.com/apexskier/go-struct-mocking-demo/.

Carlsbad Caverns National Park, NM

📷 Sony α6300

In most cases, the TODO should be filed in your team’s issue tracker immediately and cross-linked with the pull request. Some people have processes that track issues using TODOs, but I don’t believe source code works well for issue tracking. Source code represents the current state of your product. Reviewing historical context, though possible with version control, is not the primary interface. Issue tracking systems are built for prioritization, tracking context, linking related issues, and assigning responsibility.

TODOs are usually used to defer technical debt. Moving them to your issue tracker’s backlog allows prioritization against feature work by putting them in the same playing field and can be used as a metric to understand the depth of technical debt.

TODOs often describe an expected future change. It’s tough to predict the future, so the TODO might not make sense when the next person reads them. I still encourage using comments to describe the problem and the reasons for not addressing it, but not to prescribe action. In the future, you’ll have much better context when deciding how to fix the issue, or you might be able to just delete it.

Even though I don’t like seeing TODOs in a codebase, I often use them in my feature branches and scan through the diff once I’ve opened my draft PR to decide if it’s ready for review. They’re lighter weight than an issue tracker and can act as a checklist for a single task. Generally, though, they’re an indicator of poor quality and have more responsible alternatives.

Looking towards the beach town of Sopot on a warm summer evening.

Sopot, Poland

📷 Sony α6300

Generally, I try to follow standard conventions in my personal configuration. I try to use the command line in a way that I don’t feel like I’m constantly stumbling in unfamiliar environments like remote servers, docker images such as node or golang, or a fresh Raspberry Pi. This practice also makes it much easier to help my coworkers—I can work within their terminal or help instruct them without needing to translate commands. It can be painful to watch someone with muscle memory for custom git aliases or non-standard shells working in a freshly provisioned EC2 instance.

Even considering these benefits, a lot of customization provides more than enough value to be worthwhile. A familiar shell makes the debugging experience much more pleasant, and installing the tools I need to investigate takes time. I’ve also spent years polishing my bash prompt, and I love using it.

My most common use case is debugging docker and Kubernetes networking behavior. For example, I can spin up a pod in our cluster running the toolbox image and use curl and dig to verify DNS behavior.

I also occasionally need to run an image that takes a long time to start or run using a wrapper utility that doesn’t bind ports on my host. In this case, I can run my toolbox within a local docker network and connect to the image without needing to restart it or dig into the internals of how it’s initialized.

Keeping my toolbox image up to date is automated directly in my dotfiles repository, using the same scripts I use when setting up a new computer. Whenever I push to the default branch, a GitHub action builds the image and publishes it to GitHub’s container registry¹.

The docker image builds from debian:stable-slim, copies my dotfiles, runs my installer and setup scripts, then runs bash. Putting this together was a nice way to verify the cross-compatibility of my setup. The only serious issue I ran into was ensuring my setup scripts could run non-interactively. I also took the opportunity to double-check that my dotfiles don’t contain too much personal information (like a preconfigured git user) to let other people use my setup without accidentally impersonating me.

Try it yourself by running

docker run --rm -it ghcr.io/apexskier/dotfiles/toolbox

You can read more about it and see exactly what’s installed by visiting my dotfiles.