The biggest change isn't structural. I built the templating engine behind this website back in 2020, and it's still going strong. It's the little sparkle in the header that randomizes the entire color palette.

Why Randomize?

I've always had a bold, retro-influenced design aesthetic—I've never wanted my home on the web to look like every other website. Most sites pick a palette and assign meaning to it. Blue means trust, green means growth, whatever. The truth is, these choices are mostly arbitrary. I could have gone with mauve or mustard or seafoam and it wouldn't change what I have to say about my interests.

So instead of pretending the color choice is meaningful, I made it playful. Click the icon, get a new palette. The structure stays, the skin changes.

Controlled Randomness

Pure randomness would be chaos. You'd get unreadable combinations—yellow text on white backgrounds, clashing accents, muddy pastels. The trick is constraining the randomness to a space where everything works.

The system defines three structural colors tied to a single base hue:

var baseHue = Math.floor(Math.random() * 360);

// Dark color (header, text) - base hue, low lightness
var newBlack =
  "hsl(" +
  baseHue +
  ", " +
  (30 + Math.floor(Math.random() * 40)) +
  "%, " +
  (5 + Math.floor(Math.random() * 12)) +
  "%)";

// Light color (cards, backgrounds) - complementary hue (180° offset), high lightness
var newWhite =
  "hsl(" +
  ((baseHue + 180) % 360) +
  ", " +
  (10 + Math.floor(Math.random() * 30)) +
  "%, " +
  (92 + Math.floor(Math.random() * 6)) +
  "%)";

// Page background - analogous hue (90° offset), mid lightness
var newBg =
  "hsl(" +
  ((baseHue + 90) % 360) +
  ", " +
  (20 + Math.floor(Math.random() * 50)) +
  "%, " +
  (50 + Math.floor(Math.random() * 25)) +
  "%)";

The 180° and 90° offsets are doing most of the work here. Complementary colors (180° apart on the color wheel) create natural contrast—the header and content cards will always push against each other. The analogous offset (90°) for the page background mediates between them, creating cohesion without monotony.

These relationships hold no matter where the base hue lands. A warm base gives you burgundy headers with cream cards on a dusty rose background. A cool base gives you navy headers with ice-blue cards on a sage background. The math is the same; the mood shifts.

Accent Colors

The structural colors carry the palette, but accent colors (links, dates, highlights) need their own treatment. These are randomized independently:

function randomHSL(minS, maxS, minL, maxL) {
  var h = Math.floor(Math.random() * 360);
  var s = minS + Math.floor(Math.random() * (maxS - minS));
  var l = minL + Math.floor(Math.random() * (maxL - minL));
  return "hsl(" + h + ", " + s + "%, " + l + "%)";
}

var newYellow = randomHSL(90, 100, 50, 65);
var newBlue = randomHSL(80, 100, 40, 60);
var newGreen = randomHSL(70, 100, 35, 55);

Each accent has its own saturation and lightness bounds tuned to what that role typically needs. Yellows stay high saturation and lightness so they pop. Greens stay lower lightness so they don't wash out. The hue floats freely, but the intensity is controlled.

This means you can get unexpected combinations—a warm palette with a cool blue accent, or muted backgrounds with a saturated pink link color. It works because these accents are used sparingly. They're punctuation, not prose.

Persistence

The palette persists in localStorage. Once you roll a palette, that's "your" version of the site until you change it. Different visitors, different memories of the same place.

colorVars.forEach(function (c) {
  localStorage.setItem("theme-" + c, root.style.getPropertyValue("--" + c));
});

For a personal website, I think that's the right energy.

The source is on GitHub if you want to see how the rest of the site works.

I've now open-sourced that engine and it's available on Github as HappyPath.

What it Does (and Why I Think It's Cool)

• Smart Asking: It's not just a simple counter. HappyPath looks at how many times your app has been opened, how many "significant actions" a user has taken, and how long they've been using your app. It's all about catching them when they're happy.
• You're in Control: I've made the thresholds fully customizable. You decide how many launches, actions, or days pass before a prompt is considered. This means you can tailor it perfectly for your app.
• Native & Seamless: It uses Apple's own SKStoreReviewController, so the review prompt feels like a natural part of the app, not an annoying pop-up.
• No Nagging: It's version-aware. Once a user has reviewed a specific version, they won't be asked again for that same version. Phew!
• Easy to Use: It's built with a simple shared instance, so integrating it into your project is a breeze.

A Peek Under the Hood

HappyPath keeps track of a few key things in UserDefaults:

• hp_appLaunchCount: How many times my app has been launched.
• hp_significantActionCount: How many "happy path" actions a user has completed.
• hp_lastReviewRequestDate: The last time a review was asked for.
• hp_lastVersionPromptedForReview: The app version when a review was last prompted.
• hp_firstLaunchDate: The very first time the app ran.

The magic happens in requestReviewIfAppropriate(). It checks all these conditions, and if everything aligns, it politely asks for that review.

You can use my default settings, or set your own thresholds:

import HappyPath
import SwiftUI

@main
struct MyApp: App {
    init() {
        // I usually just go with the defaults:
        _ = ReviewManager.shared

        // But if I want to tweak it:
        // let customThresholds = ReviewThresholds(
        //     minLaunchesBeforePrompt: 10, // My app needs more launches
        //     minSignificantActionsBeforePrompt: 5, // More actions needed
        //     minDaysSinceFirstLaunchBeforePrompt: 14, // Give them 2 weeks
        //     minDaysBetweenPrompts: 180 // Only every 6 months
        // )
        // _ = ReviewManager(thresholds: customThresholds)
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

Track Launches

I call incrementAppLaunchCount() every time my app starts up. Easiest place is usually in your main ContentView's onAppear:

import SwiftUI
import HappyPath

struct ContentView: View {
    var body: some View {
        Text("Welcome to my awesome app!")
            .onAppear {
                ReviewManager.shared.incrementAppLaunchCount()
                print("App Launch Count Incremented!")
            }
    }
}

Ask When Active

I also trigger requestReviewOnAppActive() when my app becomes active. I like a little delay to ensure the UI is fully loaded:

import SwiftUI
import HappyPath

struct ContentView: View {
    var body: some View {
        Text("Your amazing content is here.")
            .onAppear {
                ReviewManager.shared.incrementAppLaunchCount()
            }
            .onReceive(NotificationCenter.default.publisher(for: UIApplication.didBecomeActiveNotification)) { _ in
                // Give the UI a second to settle
                DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) {
                    ReviewManager.shared.requestReviewOnAppActive()
                }
            }
    }
}

If conditions aren't met, the system logs might look like this:

🌟 HappyPath: Not prompting (launch count 1 < 5).
🌟 HappyPath: Not prompting (days since first launch 0 < 7).

But when they are, it's a beautiful sight:

🌟 HappyPath: All conditions met. Requesting review.
🌟 HappyPath: Review requested. Last prompt date and version updated.

Log Happy Moments

This is the key! I call logSignificantAction() whenever a user does something great in my app – saves something, completes a level, whatever makes sense for your app.

import SwiftUI
import HappyPath

struct TaskCompletionView: View {
    var body: some View {
        Button("Mark Task as Done") {
            // My task completion logic here
            print("Task completed successfully!")
            ReviewManager.shared.logSignificantAction()
        }
        .padding()
    }
}

System logs will confirm the action:

👍 HappyPath: Significant action count: 1

(And if that action pushes the total over a threshold, a review prompt might pop up right after!)

Find HappyPath on GitHub: https://github.com/tylerreckart/HappyPath.git

Hope this helps you on your own app development journey! Let me know what you think.

Happy coding,
Tyler

In my last post, Sound Synthesis in C++, I introduced the instrument I have been prototyping for the last few months on the Daisy Patch module. Since then, things have evolved quite a bit—I've ditched the Patch submodule, gone all-in on the Seed hardware, and added additional components such as multiplexers to unlock way more control over CV and potentiometer input.

This was the next logical step in the prototyping process. If I wanted to turn the prototype into a real instrument, I needed to ditch the pre-built hardware and start prototyping my own circuit. Sure, this means designing a custom PCB and handling more of the low-level wiring myself, but that’s part of the fun, right?

One of the main limitations of the Seed is the number of available analog inputs. In order to circumvent this, I've utilized two CD74HC4067 multiplexers—game-changing ICs that lets me drastically expand the number of CV and pot inputs without needing extra ADC pins.

This setup means I can have a ton of tweakable parameters without running out of inputs, which is huge for the amount of tweakability that I want this instrument to have.

What’s Next?

Now that the hardware is mostly sorted, here’s what’s next on my plate:

1. Refining the firmware—tweaking CV scaling, optimizing scanning, and making sure everything runs rock solid.
2. Real-world testing—pushing the multiplexer setup in different modulation scenarios to see how it holds up.
3. Finalizing the hardware design—getting it ready for a clean, reliable build and testing initial PCB designs.

Got thoughts, feedback, or just want to nerd out about synth design? Drop me a message or follow along on GitHub!

Over the course of the last year, I have been heavily invested in building and designing my own instruments that allow for deep interaction with sound. Modular synthesis taught me that the process of shaping sound can be as rewarding as the final result. The Trautonium’s focus on subharmonic synthesis felt like a perfect match for the kind of exploratory sound design I enjoy—an intersection of historical technique and modern modular sensibilities.

This project is my attempt to modernize the sound of the Trautonium using digital signal processing (DSP). The implementation starts with a core oscillator that generates a fundamental frequency, and from there, additional oscillators create subharmonics by dividing the fundamental pitch. Each subharmonic oscillator contributes harmonics that can be dynamically mixed, recreating the harmonic depth that made the original instrument so special. Here's how this works programmatically:

// Generate subharmonic frequencies
pitch_sub[0] = pitch_main / 2.f;
pitch_sub[1] = pitch_main / 3.f;
pitch_sub[2] = pitch_main / 4.f;
pitch_sub[3] = pitch_main / 5.f;

Each oscillator supports multiple waveforms—sine, triangle, saw, ramp, and square—allowing for additional tone shaping. Another key feature is scale quantization. The original Trautonium offered continuous pitch control via a ribbon controller, but in this digital version, MIDI notes can be quantized to predefined scales for musical structure. Pitch information is quantized like this:

int QuantizeToScale(int note, int scale_index)
{
    int octave = note / 12;
    int note_in_octave = note % 12;
    const int *scale = scales[scale_index];

    for (int i = 0; i < 7 && scale[i] != -1; i++)
    {
        if (note_in_octave <= scale[i])
            return octave * 12 + scale[i];
    }
    return (octave + 1) * 12 + scale[0];
}

Please take a look at this short demo of the current firmware for insight into the Aulos' sonic character:

If you're curious to learn more or experiment with this implementation, the project is open-source.

So, the first thing we'll need to do is define the view hierarchy. When working with custom navigation, I have found that it is often easier and more natural to have the tab view context live above the app's main navigation state, then nesting navigation views within each of the individual tab paths. Let's define these parent-level views through an enum declaration.

enum TabView {
    case home
    case search
    case discover
    case profile
    case settings
}

Then we need to consider the context of how the tab bar UI will render in relation to our views. The simplest way to do this is by using a ZStack {} wrapper to render the tab bar higher up in the application's z-axis and thus above each of our child views. The child views will need to account for the height of the wrapper, but that is a simple calculation. All we need to do to handle the view switching is utilize a simple switch statement that will render the target view based on the application's current state.

struct ContentView: View {
    // Define the currently active view. This should default to the home screen.
    @State private var activeView: TabView = .home

    var body: some View {
        ZStack {
            switch (activeView) {
                case .home:
                    Color.red
                case .search:
                    Color.blue
                case .discover:
                    Color.green
                case .profile:
                    Color.yellow
                case .settings:
                    Color.purple
            }

            // TabBar(activeView: $activeView)
        }
    }
}

We can then define the markup to render the view itself. For now, each tab option will be represented by an SF Symbol until the button component is defined.

struct TabBar: View {
    @Binding var activeView: TabView

    var body: some View {
        VStack(spacing: 0) {
            Spacer()
            
            Rectangle()
                .fill(Color(.systemGray5))
                .frame(height: 0.5)
            
            HStack(spacing: 0) {
                Image(systemName: "1.circle.fill")
                    .frame(maxWidth: .infinity)
                Image(systemName: "2.circle.fill")
                    .frame(maxWidth: .infinity)
                Image(systemName: "3.circle.fill")
                    .frame(maxWidth: .infinity)
                Image(systemName: "4.circle.fill")
                    .frame(maxWidth: .infinity)
                Image(systemName: "5.circle.fill")
                    .frame(maxWidth: .infinity)
            }
            .padding(.top, 15)
            .padding(.bottom, 30)
            .background(Color(.systemBackground))
        }
        .edgesIgnoringSafeArea(.bottom)
    }
}

At this stage you should have a screen that looks similar to this:

The tab bar group item is similarly straightforward in its markup:

struct TabBarGroupItem: View {
    @Binding var activeView: TabView

    var targetView: TabView
    var image: String
    
    var body: some View {
        Button(action: {
            withAnimation(.spring()) {
                // Update the view.
                self.activeView = targetView
                // Provide haptic feedback.
                UIImpactFeedbackGenerator(style: .medium).impactOccurred()
            }
        }) {
            VStack(spacing: 6) {
                Image(systemName: image)
                    .font(.system(size: 22, weight: .medium))
                    .foregroundColor(activeView == targetView ? .blue : .gray)
                
                Circle()
                    .fill(activeView == targetView ? .blue : .clear)
                    .frame(width: 4, height: 4)
            }
            .frame(maxWidth: .infinity)
        }
    }
}

With that defined, the TabBar component can be updated with the view-switching markup.

HStack(spacing: 0) {
    TabBarGroupItem(activeView: $activeView, targetView: .home, image: "house")
    TabBarGroupItem(activeView: $activeView, targetView: .search, image: "magnifyingglass")
    TabBarGroupItem(activeView: $activeView, targetView: .discover, image: "safari")
    TabBarGroupItem(activeView: $activeView, targetView: .profile, image: "person.crop.circle")
    TabBarGroupItem(activeView: $activeView, targetView: .settings, image: "gearshape")
}

Now there are just a few more pieces we'll need to implement. Because we're using the z-axis to render the tab bar above the application's content, a shared Screen view can be used to provide a wrapper around the content for each tab that will let you adjust behavior and placement with a few simple modifiers. As seen in the snippet below, this is where you can use Swift's built-in transition modifiers to add some flavor to the way your views switch.

struct Screen<Content>: View where Content: View {
    let content: () -> Content

    init(@ViewBuilder content: @escaping () -> Content) {
        self.content = content
    }
    
    var body: some View {
        content()
            .edgesIgnoringSafeArea(.top)
            .transition(.push(from: .leading))
    }
}

If you're feeling ambitious, you could easily implement an intelligent "push" animation by defining the navigation scheme and using the index of the current screen with the target screen to determine which direction to animate the push from.

With that, the Screen view wrapper can be integrated into our application's root view.

struct ContentView: View {
    @State private var activeView: TabView = .home

    var body: some View {
        ZStack {
            switch (activeView) {
                case .home:
                    Screen { Color.red }
                case .search:
                    Screen { Color.blue }
                case .discover:
                    Screen { Color.green }
                case .profile:
                    Screen { Color.red }
                case .settings:
                    Screen { Color.purple }
            }

            TabBar(activeView: $activeView)
        }
    }
}

That's it! You now have a tab view controller at the root of your app that you have complete control over. You can add custom animations between views, interactions on tab changes, and more.

By this time, I had spent much of my childhood playing collectible card games. First playing Pokemon as an extension of the Gameboy games that I still hold dear, then transitioned into years of playing and collecting Yu-Gi-Oh cards as I went through elementary school. It didn't take long after I discovered Magic for the game to become the primary focus for my collecting and playing. The 15-minute walk down the road to my local game shop to spend a hard-earned $3 on a booster pack of Guildpact, Planar Chaos, and Future Sight became a weekly ritual. As I went through high school and college, my interest in the game faded over time. Programming became my driving interest, and the rest, as they say, is history.

Fast forward to the summer of 2022. I have a family of my own and a little one that is discovering his own interests. In a place that I think many parents can relate to, my wife and I were looking for a way to spend more intentional time together after we put our son down to bed at night. It was on one of those nights that my memories of playing Magic as a kid came back to me. I remember turning to my wife and saying:

"There was this game that I played when I was a kid. I think if we gave it a shot it could be something that we both could really enjoy."

She agreed, and we've been playing regularly since.

Returning to the game after nearly 15 years was odd. In my time away, the number of cards available for play had exploded and there were completely new ways to play the game. Cards that I remember pulling out of $3 boosters are currently trading for hundreds of dollars. One of the aspects that hadn't changed much, however, was how most players tracked their board state during play.

When I was a kid we used small memo pads and dice to track life totals and counters. That is still largely the case today. While there are apps out there that are built for this exact purpose, none of them had the feel and features that I wanted in a tabletop companion app. So I decided to build one. A little more than a month's worth of work later and Spindown is now available on the app store for iOS, iPadOS, and MacOS devices. The app provides an easy-to-use interface for tracking board state, player counters, and more. One of the features that I am most pleased with is an indexed and fully searchable copy of the official Magic rulebook. Magic is an incredibly complex game, with an equally complex set of rules. Spindown's rulebook feature lets players spend less time on rules checks and more time playing the game they love.

My wife and I have been using the app for our games since the early builds when the idea first occurred to me. We enjoy augmenting our play sessions with the app, and I am hopeful that others will too.

Download Spindown on iOS, iPadOS, and MacOS today.

The iPhone’s camera is accurate enough to calculate a proper exposure in almost all cases. The device object exposes plenty of methods for manually setting ISO and exposure modes. These methods are incredibly handy when you want to control the values of your exposure in real-time, but when put into the context of light metering, their usefulness diminishes. All of the data needed to calculate each piece of the exposure triangle is already included in the EXIF data generated when an image is captured.

This starts with writing a method to make an exposure and capture its data. This method will live in the existing CameraViewModel class.

func capture() {
    if let photoOutputConnection = self.photoOutput.connection(with: .video) {
        photoOutputConnection.videoOrientation = .portrait
    }
        
    var photoSettings = AVCapturePhotoSettings()
        
    if self.device.isFlashAvailable {
        photoSettings.flashMode = .off
    }
        
    photoSettings.photoQualityPrioritization = .balanced
        
    DispatchQueue.global(qos: .userInteractive).async {
        self.photoOutput.capturePhoto(with: photoSettings, delegate: self)
    }
}

The important line to note above is self.photoOutput.capturePhoto(with: photoSettings, delegate: self). This statement declares that the model’s photoOutput should capture a photo with the settings declared in the method above, with the model itself serving as the delegate. This means that the model will need an additional method to handle the output. However, first we’ll need to define a class that can serve as a container for the captured metadata.

class PhotoMetadata: Equatable {
    static func == (lhs: PhotoMetadata, rhs: PhotoMetadata) -> Bool {
        return lhs.captureId == rhs.captureId
    }
    
    var captureId: UUID = UUID()
    
    var iso: Int64?
    var lensAperture: Double?
    var exposureDurationSeconds: Double?
}

With the metadata class defined, the output method can be written as:

func photoOutput(_ output: AVCapturePhotoOutput, didFinishProcessingPhoto photo: AVCapturePhoto, error: Error?) {
    for category in photo.metadata {
        if category.key == "{Exif}" {
            let container = PhotoMetadata()

            let isoRatings = (category.value as AnyObject).object(forKey: "ISOSpeedRatings") as! [Any?]
            container.iso = isoRatings.first as? Int64
                
            let apertureValue = (category.value as AnyObject).object(forKey: "ApertureValue")
            container.lensAperture = apertureValue as? Double

            let exposureTime = (category.value as AnyObject).object(forKey: "ExposureTime")
            container.exposureDurationSeconds = exposureTime as? Double
                
            self.metadata = container
        }
    }
}

With the output method defined, the needed markup for making the exposure and displaying the captured metadata is simple and straightforward. We’ll start by adding a few state variables to the parent view.

@State private var calculated: Bool = false
@State private var iso: Int64?
@State private var lensAperture: Double?
@State private var exposureDurationSeconds: Double?

From there, the view markup can be written as follows:

ZStack {
    CameraPreview()
        .environmentObject(camera)
        .edgesIgnoringSafeArea(.all)
                
    if device != nil {
        VStack {
            if self.calculated {
                VStack(alignment: .leading) {
                    Text("ISO: \(Int(self.iso!))")
                    Text("F-Stop: \(self.lensAperture!)")
                    Text("Shutter Speed: \(self.exposureDurationSeconds!)seconds")
                }
                .foregroundColor(Color.black)
                .padding()
                .background(Color.white)
                .cornerRadius(8)
            }
                        
            Spacer()
                        
            Button(action: { self.camera.capture() }) {
                Text("Calculate")
            }
        }
        .padding()
    }
}
.onAppear {
    camera.setUp()
                
    if camera.device != nil {
        device = camera.device
    }
}

The capture method written earlier can be accessed through the already defined camera object in a SwiftUI button with self.camera.capture(). The final step is just to chain a change handler to track when the camera’s metadata object changes and display that information to the user.

.onChange(of: camera.metadata) { newState in
    self.iso = newState?.iso
    self.lensAperture = newState?.lensAperture
    self.exposureDurationSeconds = newState?.exposureDurationSeconds
                
    self.calculated = true
}

That’s it! As long as Xcode doesn’t yell at you or throw and build errors your way, when launching the app in its current state you should be able to view the camera output and capture exposure information. Setting ISO, aperture, or exposure length values will come in subsequent posts.

It took me a long time to conceptualize how the metering system would work. Metering for large format photography is something that I really struggled with early on. Thanks to a recent episode of The Spooky Park Bench Podcast featuring large format landscape photographer Alex Burke, things clicked into place for me when Alex shared his metering ethos and how he use a digital camera to compose for large format.

Alex uses a mirco four thirds camera to compose and make his initial exposure calculations. The 4:3 aspect ratio isn't too far from 4:5, which is the format Alex shoots. So, with careful consideration using a digital camera to compose for large format is fairly simple.

What's more interesting though, is that he uses his digital camera's built-in light meter to calculate the base exposure and then compensates for aperture or conditions from there. This makes sense. Modern digital cameras have excellent light meters. I have long struggled with my dedicated meter. I have gotten fantastic results, but I have also miscalculated and ended up with drastically underexposed images even when the calculations seemed right in the moment.

Like all other modern digital cameras, the iPhone also has an excellent light meter built in. You can get fantastic images from an iPhone. Consistent metering is one of the most crucial aspect for getting those results. So, I decided to change my ethos and focus on using the tools at hand to acheive more consistent results. That starts with interacting directly with the iPhone's camera.

In order to do so, we'll need to start by building out the view model that the camera session will run in and apply any user inputs to the camera's session.

import SwiftUI
import AVFoundation

class CameraViewModel: NSObject, ObservableObject, AVCapturePhotoCaptureDelegate {
    @Published var device: AVCaptureDevice!

    @Published var session = AVCaptureSession()
    @Published var photoOutput = AVCapturePhotoOutput()
    
    @Published var preview: AVCaptureVideoPreviewLayer!
    @Published var previewURL: URL?
}

Below the defined variables, the model also needs to instantiate a AVCaptureDevice.DiscoverySession in order to retrieve capture data from the device's cameras. For the purpose of this test I've decided to limit it to the rear wide angle camera, but camera can be accessed from this object.

let discoverySession = AVCaptureDevice.DiscoverySession(
    deviceTypes: [.builtInWideAngleCamera],
    mediaType: .video,
    position: .back
)

With the class and base variables defined, we can now define a setUp method to initialize the camera session.

func setUp() {
    do {
        // Start the AVCaptureSession
        self.session.beginConfiguration()
        
        // Ensure all inputs/outputs area cleared at run time.
        for input in session.inputs { session.removeInput(input) }
        for output in session.outputs { session.removeOutput(output) }
        
        // Manually select rear camera and declare the AVCaptureDeviceInput
        self.device = self.discoverySession.devices[0]
        let input = try AVCaptureDeviceInput(device: self.device)
        
        // Add the input to the active session.
        if self.session.canAddInput(input) {
            self.session.addInput(input)
        }
        
        // Additional configuration if photo capture/output is desired.
        // if self.session.canAddOutput(self.photoOutput) {
        //     self.session.addOutput(self.photoOutput)
        // }
        
        // Commit the configuration.
        self.session.commitConfiguration()
    } catch {
        // Log any errors.
        print(error.localizedDescription)
    }
}

Now that the base view model has been defined, we'll need to write a simple UIViewRepresentable UIKit wrapper for CameraViewModel for use in SwiftUI.

public struct CameraPreview: UIViewRepresentable {
    @StateObject var camera = CameraViewModel()
    
    public func makeUIView(context: Context) -> UIView {
        let view = UIView(frame: UIScreen.main.bounds)
        
        // Add the session to the preview layer
        camera.preview = AVCaptureVideoPreviewLayer(session: camera.session)
        // Display property configuration
        camera.preview.frame = view.frame
        camera.preview.videoGravity = .resizeAspectFill

        view.layer.addSublayer(camera.preview)
        
        DispatchQueue.global(qos: .userInteractive).async {
            camera.session.startRunning()
        }
        
        return view
    }
    
    
    public func updateUIView(_ uiView: UIView, context: Context) {}
}

That's all that you need to get a basic camera session running in a SwiftUI View.

@main
struct App: App {
    @StateObject var camera = CameraViewModel()

    var body: some Scene {
        WindowGroup {
            ZStack {
                CameraPreview()
                    .environmentObject(camera)
                    .edgesIgnoringSafeArea(.all)
            }
            .onAppear { camera.setUp() }
        }
    }
}

As I have grown as a photographer, especially as a film photographer, I have consistently found myself looking for a centralized tool for tracking the data that goes into each exposure. Whether that be reciprocity, bellows extension, or just understanding how different film stocks brought their own unique characteristics to each image. For the majority of my time as a photographer, this process has been completely manual. For each emulsion I would have to read the data sheet and look at the reciprocity failure curve to understand how to compensate for light fall-off on longer exposures. Calculations and formulas would then live in a small notebook that I kept in my photography bag.

This is not a unique system. It's proven and it works, but I wanted something better. I wanted something in my pocket that would have the ability to make the calculations I needed, save the data, and act as a universal notebook for me to put that data to understand it better and grow as a photographer.

As I've written about on this blog already, I decided to build myself a little utility to solve this problem. For a long time it was a buggy, fickle app that would crash if the inputs weren't 100% right. That was fine for me, because I knew the edge cases, but as I continued to add functionality it seemed more and more clear to me that this could be a useful tool for other photographers as well.

That's when I started to share my idea with other photographers. I started to get feedback on the kinds of tools that they'd want to use in the field. That's when this app turned from a pocket companion for myself into what it is now. And as of the time of this writing, Aspen is available on the iOS App Store for devices running iOS 16 or newer.

There's still a lot that I want to put into the app. There's a Sekonic-inspired spot metering function on its way, but that undertaking was cut from the original release. I'll continue to write about my progress as the app gains features and feedback from its users.

There are several ways to accomplish this behavior. My initial implementation was to use native Gesture recognition. However, the amount of overhead required to allow the additional tiles to recognize the current gesture was more than I wanted to try and implement as part of the app's MVP. With that in mind, I turned to .onDrag and .onDrop handlers. While the handlers themselves didn't have what I needed out of the box, defining a custom DropDelegate was an easy enough solution.

This post provides an overview of that implementation. It's not a step-by-step tutorial, but it should suffice for those with even a passing knowledge of Swift and SwiftUI.

Let's start with a simple data model:

struct DashboardTile: Identifiable, Equatable {
    static func ==(lhs: DashboardTile, rhs: DashboardTile) -> Bool {
        return lhs.id == rhs.id
    }

    var id: String {
        self.key
    }

    var key: String
    var label: String
}

This model provides a simple data structure with two properties, key and label. With our data structure in hand, we need to define our DroppableTileDelegate that will handle override the default drag-and-drop handler's behavior.

struct DroppableTileDelegate<DashboardTile: Equatable>: DropDelegate {
    let tile: DashboardTile
    var listData: [DashboardTile]

    @Binding var current: DashboardTile?
    @Binding var hasLocationChanged: Bool
    
    var moveAction: (IndexSet, Int) -> Void
    
    func dropEntered(info: DropInfo) -> Void {
        guard tile != current, let current = current else { return }

        let from = listData.firstIndex(of: current)
        let to = listData.firstIndex(of: tile) else { return }
        
        hasLocationChanged = true
        
        if listData[to] != current {
            moveAction(
                IndexSet(integer: from), to > from ? to + 1 : to
            )
        }
    }

    func dropUpdated(info: DropInfo) -> DropProposal? {
        DropProposal(operation: .move)
    }
    
    func performDrop(info: DropInfo) -> Bool {
        hasLocationChanged = false
        current = nil
        return true
    }
}

With the DroppableTileDelegate defined, we can define the view that our layout will live in. Note that the tiles and the binding representing the currently dragged tiles are passed into this view from the parent view. This allows data to be shared with other views if necessary. The default drag preview behavior is overwritten by the preview closure that follows the definition of the .onDrag handler. If we don't override this with our UI, the default hard-edged previews will be shown. For some apps that might be all that is necessary, but since my dashboard tiles had rounded edges, it required that a custom overlay that used contentShape to trim those corners be used.

struct DashboardTileView<Content: View, DashboardTile: Identifiable & Equatable>: View {
    @Binding var tiles: [DashboardTile]
    @Binding var draggingTile: DashboardTile?

    let content: (DashboardTile) -> Content
    let moveAction: (IndexSet, Int) -> Void

    @State private var hasLocationChanged: Bool = false
    
    init(
        tiles: Binding<[DashboardTile]>,
        draggingTile: Binding<DashboardTile?>,
        @ViewBuilder content: @escaping (DashboardTile) -> Content,
        moveAction: @escaping (IndexSet, Int) -> Void
    ) {
        self._tiles = tiles
        self.content = content
        self.moveAction = moveAction
        self._draggingTile = draggingTile
    }
    
    let screenWidth = UIScreen.main.bounds.width
    
    var body: some View {
        VStack {
            ForEach(tiles) { tile in
                VStack {
                    content(tile)
                        .overlay(
                            draggingTile == tile
                            ? RoundedRectangle(cornerRadius: 17).fill(.thinMaterial)
                            : nil
                        )
                        .onDrag {
                            draggingTile = tile
                            return NSItemProvider(object: "\(tile.id)" as NSString)
                        } preview: {
                            content(tile)
                                .frame(minWidth: screenWidth - 20, minHeight: 80)
                                .contentShape(.dragPreview, RoundedRectangle(cornerRadius: 18, style: .continuous))
                        }
                        .onDrop(
                            of: [UTType.text],
                            delegate: DroppableTileDelegate(
                                tile: tile,
                                listData: tiles,
                                current: $draggingTile,
                                hasLocationChanged: $hasLocationChanged
                            ) { from, to in
                                withAnimation {
                                    moveAction(from, to)
                                }
                            }
                        )
                }
            }
        }
    }
}

The custom drop delegate that we defined above is passed into the delegate parameter of the .onDrop handler. A trailing closure also allows for the view to be animated when the moveAction is invoked. From there, all we need to do is define the action itself.

func moveTile(_ from: IndexSet, _ to: Int) -> Void {
    layout.move(fromOffsets: from, toOffset: to)
}

With the above all defined (and compiling without error), all we have to do is reference the DashboardTileView and pass in the associated bindings.

DashboardTileView(tiles: $layout, draggingTile: $draggingTile) { tile in
    SimpleTile(tile: tile)
} moveAction: { from, to in
    moveTile(from, to)
}

Voila!

The culprit is the inverse square law. As the bellows are extended, the intensity of light available to expose the negative is inversely proportional to the square of the distance from the film plane. That fall off of light needs to be factored into the final exposure. Otherwise, you'll end up with a dark, underexposed image.

The calculation to compensate for bellows extension is simple, but it's a pain to do in the field or working with extreme extensions for macro photography. I've had the formula in a small notebook that I keep with my large format gear to reference when out in the field, but I thought there could be a better way. So I decided to build one.

This little photography app, which I've taken to calling Aspen, solves that problem. In its current state, you can adjust for bellows extension, film reciprocity, as well as filter factors. It also includes a handy notebook for referencing exposures in the future.

The app is still very early in its development, but it's been a very handy tool for me as I have been exploring extreme macros and working with alternative printing processes. I haven't put it on the app store yet, but if you're handy with Xcode, you can view the source on Github and build it locally to run on your device.

More updates will come as I add additional features and build out the user experience.

By the time I graduated high school, a lot of that creative energy had been put on the back burner. I stopped taking on client work and focused on getting myself into college. It took a few years of finding out who I wanted to become, but I eventually found myself back in the industry. However, this time was different. One of the limitations of my early design work is that I desperately wanted to take the screens and apps that I had designed and turn them into real, functional products. So that’s what I focused on. I started to build my software development skillset. As I learned more and more about how to build feature-rich applications, write tests, and ship products, the design-oriented aspect of my work fell back into the background.

Fast forwarding to today, I’ve been writing software professionally for nearly a decade. I wouldn’t trade that career choice for the world. And while my day-to-day work is primarily technical, developing robust and scalable software requires a lot of creative problem-solving. It’s incredibly rewarding when you can come to a clean, functional solution to a complex problem or difficult task. With as much as I enjoy my work, the itch to create for creation’s sake has never left. It was time to find a new outlet.

Enter the camera

I bought my first real camera in the summer of 2020. My wife and I were preparing for the birth of our first child, and like many fathers-to-be, I wanted to capture as many of those early moments as possible. So I did my research. I found a camera with the right balance of image quality and budget-friendliness and made the commitment. It was a gently used Canon EOS R in practically new condition. I cycled through a few lenses at first as I learned the system, but eventually landed on a Cannon RF 24-70mm f2.8L with its fast aperture and a great balance of focal ranges that suited my needs.

After my son was born, the Canon ended up within arm's reach for much of those early weeks and months. Every time I used it, I became a little more comfortable with it. I started to understand how changing settings like shutter speed, aperture, and ISO could affect the image. Before long, I was hooked. I started to go out to take pictures just for the sake of taking pictures. I had found an outlet that let me step back from the computer screen and enjoy the process of creation.

And then there was film

It wasn't long before I got the itch to try my hand at shooting film. I felt confident in my abilities to understand how to capture a well-exposed image, and the unforgiving nature of film photography was the next step for me to hone my abilities with the camera. It started with 35mm and quickly moved into medium format before settling finally on a large format 4x5 view camera.

Large format forces you to slow down. Each movement of the camera subtly affects the focus and depth of field of the image. If you rush the process, you'll likely forget to set everything correctly. The shutter might be too long. The aperture might be too wide. You may not have accounted for bellows extension and how the light diminishes as you extend the distance between the lens and film plane. A miscalculation more than likely leads to an unusable image. However, when you can focus on the composition and find the right light, the results are breathtaking.

Finding photography, and large format film photography has brought that creative energy back from the background. It is something that I have grown incredibly passionate about over the few years since I fell into the hobby. I think we all need an outlet, and I feel very grateful to have found mine.

"Happy he who has passed his whole life mid his own fields, he of whose birth and old age the same house is witness...For him the recurring seasons, not the consuls, mark the year; he knows autumn by his fruits and spring by her flowers."
Claudian, Carmina Minora (XX)

A large part of my interests outside of programming, a healthy portion of the stacks of books I get through each year, centers around one subject: antiquity. I've had a strong interest in history since I was a kid. The story that follows is one that I've known for a few years, but I thought it was an interesting subject and wanted to share it in my own way.

The early Roman pre-republican calendar, attributed by the Romans to the eponymous first king Romulus himself, was lunar. Built around the phases of the moon and the agricultural seasons of the Italian peninsula, the Roman year began in March at the start of spring and ended in December with the autumn planting. It consisted of ten months, just 304 days.

A year of just 304 days is missing 61 days. That's not an insignificant number of days. A single generation of the error led to seasons wildly out of sync with the calendar date. According to Livy in his The Early History of Rome, Numa Pompilius, the second king of Rome, attempted to correct the issue with the calendar by dividing the year into twelve lunar months. First by adding an additional fifty days to the year and secondly by taking a day from each month of thirty days to allow for two winter months, January and February, both of which had twenty-eight days.

A year closer to what we would recognize in the modern era had been established, however, the Romans were a superstitious people plagued with an aversion to even numbers. An additional day was added to January to avoid the unlucky number. The entire month of February was already considered to be unlucky, so they left it untouched. The Romans now had a year of 355 days, just ten days off from the astronomical year.

This calendar system went on essentially untouched until 46 BC. The Romans kept the seasons in sync by manually intercalating (inserting) those missing days. However, left untouched the Roman calendar as before would fall out of synchonicity with the seasons. That responsibility fell on the Pontifex Maximus; Rome's chief priest. In 46 BC, the Pontifex Maximus was one of the most famous people to have ever lived: Julius Caesar.

Caesar was elected Pontifex Maximus in 63 BC. It was a position he would occupy until his death until 44 BC. Just six years into his role, conflict over the migration of a Celtic tribe exploded into war. By 58 BC Caesar was fully consumed in his conquest of Gaul. Only a year after returning to the Rome in triumph, rivalries in the senate would boil over into a new war, Roman against Roman. Fought across the burgeoning empire, the four year conflict would see the death of Pompey the Great and Caesar elected by the Senate and people of Rome as dictator for life. There hadn’t been an intercalation since Caesar's election to the proconsulship in 58 BC. By his return to Rome from Egypt in 46 BC and his election to the dictatorship, there was a three month discrepancy between the seasons and the calendar date. The harvest was being celebrated before the crops had even been taken in.

When Caesar returned from Egypt, he returned with a familiarity with the Egyptian calendar. The Egyptians, unlike the Romans, used a solar calendar to track the passage of their year. With his power as Pontifex Maximus and at the direction of the Alexandrian astronomer Sosigenes, Caesar added ninety extra days to the year. Ninety. The addition meant that the year 46 BC had a length of 455 days. The addition also meant that 46 BC was now the longest year in human history. The calendar that resulted consisted of four nearly equal seasons divided into a more familiar 365 days. Because the solar year is approximately a quarter of a day longer than the calendar year, Caesar automatically inserted a single intercalary day every four years at the end of February, inventing the concept of the leap year.

Caesar went on to do a number of notable things after his reforms, now referred to as the Julian calendar, but that is where this post will leave him. The Julian year averaged exactly 365.25 days. That is extremely close, but exactly 11 minutes too long. Meaning that the calendar would gain almost a day every 128 years. By the mid sixteenth century the discrepancy had amounted to around ten days. The spring equinox, the annual event used by the Catholic Church used to calculate the date of Easter, was no longer occurring on March 21. In 1582, Pope Gregory XIII stepped in to reform the system once again. To correct the immediate issue, the Pope omitted the extra ten days from that year. 1582 only consisted of 355 days. October 4 was followed by October 15. To prevent the issue from happening in the centuries and millennia that followed, three leap years were to be omitted every four-hundred years.

The Gregorian calendar has been in use ever since.

Related Reading

• Caesar: Life of a Colossus
• Roman timekeeping
• Leap Seconds

While I’ve grown up and made a career in large part because of the social internet, over the past few years as the spread of misinformation and vitriol has grown exponentially I’ve started to see the way most of us currently interact with social media as irreparably harmful to our society. That’s not to say that there aren’t benefits to the core ideas at the foundation of the social internet; I just believe that more harm is being done than good.

I also believe strongly that the algorithms that control the feeds on these platforms also plays a large roll in the toll these platforms can on us as individuals. Like countless others, on many occasions I’ve found myself endlessly scrolling through my feeds. Twitter, Instagram, Facebook, repeat. I would get to the point to where I wasn’t even really paying attention to what I was doing. Just scrolling through the feeds to occupy empty space.

The algorithms behind the feeds on these platforms are designed to elicit this kind of behavior. When you run out of content, they’ll automatically populate the feed with suggested content. It keeps you scrolling. It keeps you on their platform. The longer you’re on their platform, the more ads you’ll see and the more likely you are to click through to one of them.

This behavior isn’t healthy.

The combination of the damage these platforms do to our communities and the unhealthy behavior I’ve recognized in myself have led me to restructure how I interact with social media. Finding what works for me has taken a few months, and it might not work for everyone, but I have found myself on these platforms less and less since I’ve put the following measures into place.

1. As a general rule, unfollow everyone except those that you truly want to see in your feeds. No more influencers. No more brands. For me this means restricting my follow list to just friends and family.
2. Privatize everything. Lock down your privacy settings and only allow the content you share to be shared with those that you choose to be shared with.
3. When you reach the end of a feed, close the app. No more listless scrolling.
4. Find an outlet. The time you’ll gain back is valuable. Fill it with something that you truly enjoy. For me, this has been photography.

I’m not removing myself from social media. At this point in our society, I think that route isn’t sustainable in the long run. These platforms are here to stay. However, I believe that deliberate, conscious use can go a long way to a healthy relationship with the social internet.

class Thing {
  #name = "";

  get name() {
    return this.#name;
  }

  set name(value) {
    this.#name = value;
  }

  #someMethod() {
    this.#name = this.#name.toUpperCase();
  }

  publicMethod() {
    // Private-named properties and methods can
    // be accessed inside the class.
    this.#someMethod();
    return this.#name;
  }
}

new Thing().#someMethod();
//          ~~~~~~~~~~~
// error!
// Property '#someMethod' is not accessible
// outside class 'Thing' because it has a private identifier.

const myThing = new Thing();
myThing.name = "Ted Lasso";
const jazzyName = myThing.publicMethod(); // "TED LASSO"
myThing.#name;
//      ~~~~~
// error!
// Property '#name' is not accessible
// outside class 'Thing' because it has a private identifier.

To make methods, getters/setters or fields private, all you have to do is prefix the name with #.

It's worth noting that private fields and methods exist only as declared up front. They cannot be created later, ad-hoc, or through assignment. You also can't declare private fields or methods in object literals. If you implement your class by adding individual methods to the prototype, or using a class framework, private methods and fields can't be used.

At the outset, we should establish how SSR works in React:

1. A request is sent from the client.
2. The server fetches the data for the entire app.
3. The server renders the entire app as HTML and sends it in the response.
4. The client loads the JavaScript bundle for the app.
5. The client runs the code in the JavaScript bundle, connecting it to the generated HTML.

This approach works, and it has for a long time, but it's not an optimal solution.

The first problem is that your app has to fetch everything from the server before your app can show anything. By the time the DOM is painted with the server-generated HTML, you must already have all the data ready for your components on the server. The second issue, building on the first, is that your app has to load everything before it can hydrate the server-generated HTML with the JavaScript code. Prior to React 18, React programmatically stepped through the server-generated HTML while rendering the components, attaching every listeners, and executing functions. The performance hit comes from the fact that due to this method of execution, your app must load the JavaScript for every component in the render tree before it can start hydrating any of them. The final consequence from this design methodology is that your app must hydrate everything before the end-user can interact with anything.

With prior versions of React, rendering is all or nothing. Your server responds with HTML, which is received by the client and is then hydrated when the bundle is loaded.

<html>
  <head>
    <title>My webpage</title>
  </head>
  <body>
    <main>
      <header>
        <span>My webpage</span>
        <nav>
          <a href="/about">About</a>
        </nav>
      </header>
      <article>
        <h1>Post title</h1>
        <p>...</p>
      </article>
      <section class="comments">...</section>
    </main>
  </body>
</html>

In React 18, you can now wrap part of a component tree with the <Suspense> component.

<Flex>
  <Header />
  {posts.map((post) => (
    <Flex.Item>
        <Post
          title={post.title}
          body={post.body}
        />
        <Suspense fallback={<Loading />}>
          <Comments comments={post.comments} />
        </Suspense>
    </Flex.Item>
  )}
</Flex>

By wrapping the <Comments> component with <Suspense>, React won't wait for the comments to start streaming to render the HTML for the rest of the page. Instead, React will render a placeholder (fallback) component until the comments are loaded.

The HTML sent by the server will now look something like this:

<html>
  <head>
    <title>My webpage</title>
  </head>
  <body>
    <main>
      <header>
        <span>My webpage</span>
        <nav>
          <a href="/about">About</a>
        </nav>
      </header>
      <article>
        <h1>Post title</h1>
        <p>...</p>
      </article>
      <section class="loading">
        <span>Loading...</span>
      </section>
    </main>
  </body>
</html>

Then, when the data for the comments is ready on the server React will automatically inject the new HTML into the stream as well as a <script> tag that includes logic to replace the component in the HTML stream. That's where the power of the <Suspense> component lives. Your app doesn't have to fetch all of the data before your server can render anything. If some part of the call stack delays the initial response, you don't have to choose between delaying all of the HTML in the response or substituting it until the data is ready.

The features introduced by <Suspense> solve all three of the existing problems with SSR in React:

1. Your app no longer needs to wait for all of the data to load on the server before rendering HTML.
2. Your app no longer needs to wait for all JavaScript to load to start hydrating.
3. Your app no longer needs to wait for all the components in the current render tree to be hydrated for users to start interacting with the page. Instead, the <Suspense> component along with createRoot uses selective hydration to prioritize the components the user is interacting with and hydrate them early.

The <Suspense> component is completely opt-in. Simply replace your if (isLoading) { ... } conditionals with <Suspense> wrappers. The improvements are automatic, but it serves as an illustrative example of the power of declarative component loading states. Your users will see your app's content sooner and will be able to start interacting with it faster. The slowest parts of your app will no longer hold back the parts that are fast. If your app uses SSR to serve content, the <Suspense> component in React 18 is a no-brainer.

The Jaeger-LeCoultre (or LeCoultre & Cie as it was marketed in North America in the mid twentieth century) Atmos is a unique member of the horological pantheon. The 259-serial pictured above is from my personal collection and is an excellent example of how the design of the Atmos contributes to the clock’s longevity; having left the factory in the mid 60s.

What makes an Atmos clock unique among the class of pendulum-driven mantle clocks is that it does not need to be manually wound. Like all mechanical timepieces, the Atmos is driven by a mainspring. However, unlike most clocks of its class and construction, the Atmos’ mainspring is wound by the expansion and contraction of a volatile liquid, ethyl chloride, inside of a hermetically sealed bellows system.

As the surrounding temperature rises the ethyl chloride vaporizes, compressing a spiral spring. When the temperature falls the vapor condenses back into a liquid, allowing the spring to return to its resting state. The constant motion generated by the compression and expansion of this spring drives the bellows system and subsequently winds the clock’s mainspring.

A temperature change of only one degree can sufficiently power the clock for up to two days.

While the Atmos’ construction is unique among many clocks today, clocks powered by changes in atmospheric pressure date all the way back to the early 17th century. The inventor of the mechanism, Cornelis Drebbel, built as many as 18 atmospherically-driven clocks that we know about today.

If you ever get a chance to inspect an Atmos clock in person or add one to your collection, I highly recommend it. The smooth motion of the pendulum and openness of the mechanism it drives is mesmerizing.

Early iterations were simple static HTML and CSS bundles with a tinge of JavaScript thrown in for effect. Over the years my website would evolve to take the form of a CMS-backed blog, a blog with hand-written post content as HTML templates (I definitely don't recommend that one), a single-page React application, and most recently a statically-rendered React blog.

Looking back, I can see each iteration as a reflection of where I was in my journey as a software developer. As my skillset increased and depth of knowledge expanded, my goals for what my website could be grew in turn. The last few iterations of my website have been built in React; and why shouldn't they have been? I've been working with React professionally since 2015. I love React and the flexibility it gives developers to build and ship modern apps for the web. However, what I haven't always loved about React is the sheer amount of boilerplate code required to get an app up and running.

I should note that things have gotten better over the years. There are great tools like create-react-app, Next.js, and Gatsby that make the tooling and configuration steps needed to get a React app up and running as minimal as possible. This is nice, but they don't get rid of the problem. The configuration and boilerplate still exists behind the scenes in the respective package's build system.

When I decided to rethink my website for this iteration, I had to think long and hard about that reality. I decided that I just didn't need an entire Babel and Webpack configuration and the immeasurable amount of dependencies that come with one just to publish content for the web. It's all of those little idiosyncrasies specific to React development that just added more friction to the publishing process than I wanted. I didn't want to have to worry about making sure my dependencies were up to date just to build the website. I shouldn't have to write an entire component hierarchy just to build a blog.

It was that friction that kept me from publishing more on the blogs I've built in the past. So, I set out to build a publishing system that I actually wanted to use. I ended up with three requirements:

1. The website should be statically rendered.
2. The website should have as few dependencies as possible.
3. All post and page content should be rendered with Markdown templates.

Those requirements, and a week of playing around with Node's file system tools have led me to this iteration. All of the content on the website is written in Markdown with the HTML markup being generated through Pug templates. The only dependencies the build system has are related to asset minification, code-block formatting, templating, and XML generation for the RSS feed. That's it. No complex build configurations.

During the build process for this website, I had a realization about how extensible the templating system is and how easy it would be to write additional themes that could be quickly configured with a single point of configuration. I didn't set out to build a tool that other people could use to build static websites quickly and easily, but what I ended up with is what I am calling Mortar.

Mortar is built to be exceptionally simple. I didn't want it to make any bold assumptions about what a user would want or to burden them with complex configurations and deployment requirements. Simply put, it doesn't try to outsmart the user. Mortar gets out of the way and allows the user to focus on what actually matters: the content.

So, how does it work. As mentioned briefly above, it's a straightforward adaptation of Node's file system tools and a few additional libraries that aid with asset minification, markdown parsing, and templating. Markdown files placed in the pages and posts directories are automatically parsed, fed through the templating system and compiled into HTML templates. All the web server has to do is serve content from the build folder. The exact method for accomplishing that will vary based on the server a configuration a user might be utilizing (NGINX, Apache, etc), but the process is exceptionally simple.

I chose Pug as the templating engine for the HTML markup because of its performance and specific bend towards Node apps. The syntax, heavily influenced by Haml, is simple and only takes a few minutes to pick up. Inline JavaScript is a breeze and variable scope is automatically passed into included components, meaning that you don't have to worry about prop inheritance or explicitly passing what you need into the component.

include time.pug
doctype html
html(lang="en")
  head
    if seo.title
      title=seo.title
    else
      title=""
    if seo.description
      meta(name="description", content=seo.description)
    else
      meta(name="description", content="")
    include templates/head.pug
  body
    main.content
      include templates/nav.pug
      include templates/intro.pug
      each post in posts
        article
          div.article--header
            a(href=post.path) #[h2=post.attributes.title]
            +time(post.attributes.date)
          div.article--content
            | !{post.body}
      include templates/footer.pug

That's the pug template that generates all of the markup for the homepage of this website. That's it. More complex pieces of functionality, such as generating the time tags underneath post titles is easily handled by Pug mixins that can be included in a number of templates.

-
  function toISODate(date) {
    return (new Date(Date.parse(date))).toISOString();
  }

mixin time(date)
  time(datetime!=toISODate(date), pubdate="pubdate")="Posted on " + date

Over the years I've used a lot of different templating engines. Early in my career, Twig was the templating system I used to build Craft CMS websites. In the intervening time I've used Handlebars templates, EJS templates, and of course, JSX templates in the context of React apps. Of all of those varying templating engines, Pug has to be the simplest I have used. The syntax is clean, declarative, and easy to understand. It makes building themes for Mortar websites a breeze.

Mortar still has a long way to go as a tool before it's ready for a wider audience. It's still firmly in it's "happy accident" phase. It has several aspects that can be optimized further and I have lofty ambitions for automatic deployments. Mortar started as a way for me to remove friction from the process of publishing content on my website. My hope is that if someone else out there has the same frustrations I've had when it comes to writing content for a personal website without the weight that comes from a full-fledged CMS, that Mortar can be an effective tool for them too.

I'm extremely pleased with this iteration of my website. I'm excited to use this clean slate and the build system I've put together as a springboard to publish more content to my home on the web.