Dimi Chakarov

From Algorithms to Adventures

Mon, 08 Dec 2025 10:00:01 +0000

In my previous post, I shared the story of how I fell in love with maze algorithms. I wrote about porting Jamis Buck’s Ruby code to Swift, building a visualisation engine, and the intellectual joy of understanding “perfect” mazes.

I ended that project with a robust MazeGenerator framework and a technical demo. I felt like 90% of the work was done. I just needed to wrap some UI around it, add a “Start” button, and I’d have a game.

I was wrong. I had a simulation, not a game. And turning the former into the latter would take me on a journey through bad design decisions, harsh feedback, and a complete pivot in how I thought about “fun.”

The “Nerd” Trap (v1.0)

When you build a game engine before you build a game, you tend to value the wrong things. I was obsessed with the algorithms. I wanted players to appreciate the difference between the Recursive Backtracker (long, winding rivers) and Prim’s Algorithm (short, organic branches).

My first version of the game was essentially my tech demo with added controls.

The Core Loop: Select an algorithm, generate a maze, solve it, and try not to touch any walls as you get points deducted for that.
The “Cool” Feature: A “Draw Mode” where you could sketch a shape with your finger, and the framework would generate a maze around it.
The Educational Angle: Info screens explaining “Diagonal Bias” and “Spanning Trees.”

I thought it was brilliant. It wasn’t. It was boring.

The Reality Check

You can’t convince people to use your app or play your game if you don’t do it yourself. I installed the game on my phone and tried to play it instead of Balatro or Mini Motorways. I didn’t last one hour. There wasn’t anything to keep me entertained or to make me want to win more points. I was bored.

Also, the “Draw Mode”? It turns out that drawing a mask with your fat finger on a phone screen results in a blocky, ugly shape. It was a technical marvel that resulted in a terrible user experience.

Finding the Fun

I was three months in. The codebase was sprawling with features nobody cared about (algorithm selectors, learning tabs, map editors). I had a choice to make: release a tech demo that no one would play, or strip back the nerdy features and make the game fun.

I chose the latter.

I stripped out the algorithm selector. I hid the educational content. I removed the Draw screen.

The Move Limit

The breakthrough came when I stopped punishing the player for hitting a wall and introduced a Move-Based system.

In the new version, you are given a strict budget of moves to solve the maze.

Efficiency matters: You can’t just wander; you have to plan.
Fairness is guaranteed: For any specific maze seed, the optimal path is a fixed number of steps. I could calculate the “Perfect Score” mathematically using Dijkstra’s algorithm.
Tension: Running out of moves is far more stressful (in a good way) than a timer counting up.

Suddenly, it wasn’t a racing game anymore. It was a strategy game.

Building the “Game” Part

Once I had the core mechanic, I needed to wrap it in a progression system. A game needs to feel like a journey, not a loop.

I introduced:

Power-ups: Since moves are vital to the game, power-ups became about economy. “Demolish Wall” costs coins to buy, but can help you get to that hidden crate and back before you run out of moves. “Jump” lets you skip long corridors and cash in on any remaining moves you have.
Terrain: I added ice (you slide, saving moves but losing control) and mud (costs double moves).
Progression: I added progressively harder levels - the mazes get bigger, the crates are further from the happy path, the terrain is rocky. Every ten levels, you get a prize. Every now and then, you unlock a rare avatar or stumble upon a hidden gem.

The Tech Stack: SwiftUI

I built the entire game in SwiftUI.

Many developers warned me against this, suggesting SpriteKit or Unity. But for a grid-based puzzle game, SwiftUI is surprisingly capable.

State Management: The grid is composed of VStacks and HStacks, rendered based on the game state.
Animations: SwiftUI’s implicit animations made the player movement (sliding from tile to tile) buttery smooth.
Iterative Speed: I could change the “Mud” tile view in one file and see it update across the entire game instantly in the Preview.

The hardest part was positioning the “items” and the player layers on top of the maze layer. I ended up using a complex layering of ZStacks that I don’t recommend to the faint of heart, but it worked.

Launching

The game, MZ: Maze Adventures, is finished.

All the cute avatars in the game were designed by my wife; the not-so-cute ones - by me. The music was composed by my son (who also decided to download the game to play, not just to listen to his music in action). It has no algorithm selectors, no “Draw Mode,” and no educational lectures.

It just has mazes. Perfect, frustrating, beautiful mazes.

You can download it now on the App Store.

Fitting User Content Without Clipping

Tue, 18 Nov 2025 19:25:01 +0000

For an app I’m working on, I needed to solve a deceptively tricky problem: how many list items can I show in a widget without clipping? The app lets users create lists - shopping, to-do, Christmas, you name it. I added a widget so they could track their current list and even tick off an item or two without opening the app. Since this is user-generated content, I control neither the number of items nor how long each one is. A shopping list might have many single-word items whilst a to-do list can have longer entries, sometimes spanning multiple lines.

The Naive Implementation

My initial implementation didn’t account for any of this. I used strict hardcoded limits depending on the widget family: 4 for small and medium, 8 for large. Here’s the code:

struct ListView: View {
  @Environment(\.widgetFamily) var family
  let items: ListItem
  var itemLimit: Int {
    switch family {
    case .systemSmall:
      4
    case .systemMedium:
      4
    case .systemLarge:
      8
    default:
      0
    }
  }

  var body: some View {
    ZStack(alignment: .topLeading) {
      switch family {
      case .systemSmall,
        .systemMedium,
        .systemLarge,
        .systemExtraLarge:
        let visibleItems = Array(items[0..<itemLimit])
        VStack(alignment: .leading, spacing: 0) {
          ForEach(visibleItems, id: \.id) { (item: ListItem) in
            ItemRowView(item: item)
          }
        }
      default:
        EmptyView()
      }
    }
  }
}

This worked fine until I started testing with longer items. Here are a few screenshots of it “working fine” and… well… not.

It’s harder to break with the medium or large widget, but it’s still possible. Not ideal.

Research and Solve

After some research, I discovered there’s no automatic way to handle this. I needed to do the calculations myself, accounting for:

The widget dimensions
Padding and spacing
Font size and line height
How many lines each item requires

Let’s apply this to the code.

var itemLimit: Int {
  itemLimitForWidgetFamily(items: items, family: family)
}

// ...

private func itemLimitForWidgetFamily(items: [ListItem], family: WidgetFamily) -> Int {
  var result = 0
  var currentHeight: CGFloat = 0

  for item in items {
    let lines = estimatedLineCount(for: item, width: widgetWidth)
    let itemHeight = lines * lineHeight
    currentHeight += itemHeight + itemSpacing
    
    if currentHeight > widgetHeight { break }
    result += 1
  }

  return result
}

The logic is straightforward: iterate through items, calculate each one’s height based on how many lines it needs, add it to our running total, and stop when we exceed the widget’s available space. The beauty of this approach? It works with your actual content, not arbitrary test data.

Notice we’re referencing some unknowns: widgetWidth, widgetHeight, lineHeight, and itemSpacing. Let’s resolve them.

We don’t need to be extra precise with these; ballpark it. So let’s trust the internet and use some estimated numbers here.

private func widgetHeight(for family: WidgetFamily) -> CGFloat {
  switch family {
  case .systemSmall:
    155
  case .systemMedium:
    155
  case .systemLarge:
    345
  default:
    0
  }
}

private func widgetWidth(for family: WidgetFamily) -> CGFloat {
  switch family {
  case .systemSmall:
    155
  case .systemMedium:
    329
  case .systemLarge:
    329
  default:
    0
  }
}

Measuring Text: How Many Lines?

Next challenge: determining whether each item needs one line or two. I decided to cap items at 2 lines maximum - if users want to see the full text, they can open the app. This keeps the widget clean and readable.

Here’s where things get interesting. We need UIKit to measure text (I know, I know):

private func estimatedLineCount(for item: ListItem, width: CGFloat) -> Int {
  stringFitsOnOneLine(item.name, width: width) ? 1 : 2
}

private func stringFitsOnOneLine(_ text: String, width: CGFloat) -> Bool {
  let constraintRect = CGSize(
    width: CGFloat.greatestFiniteMagnitude, 
    height: CGFloat.greatestFiniteMagnitude
  )
  let boundingBox = (text as NSString).boundingRect(
    with: constraintRect,
    options: [.usesLineFragmentOrigin, .usesFontLeading],
    attributes: [.font: UIFont.preferredFont(forTextStyle: .body)],
    context: nil
  )
  return boundingBox.width <= width
}

We’re using NSString’s boundingRect method to calculate text width with the system body font. If you’re using a custom font or text style, adjust accordingly.

The final piece of the puzzle is lineHeight, which we get from UIFont.preferredFont(forTextStyle: .body).lineHeight. Again, update if you’re using custom typography.

First Results

Let’s test it:

Almost perfect! But before shipping, I ran one more test. Good thing I did.

The Missing Piece

In the words of my favourite coding agent: I see the real issue now!

We forgot to account for padding around elements and the size of those checkboxes. The calculation assumed the full widget space was available for text, but that’s not true. We need to subtract the UI chrome.

Here’s the corrected calculation:

private func itemLimitForWidgetFamily(items: [ListItem], family: WidgetFamily) -> Int {
  var result = 0
  var currentHeight: CGFloat = 0
  let allowedWidth = widgetWidth - itemPadding
  let allowedHeight = widgetHeight - listPadding
  
  for item in items {
    let lines = estimatedLineCount(for: item, width: allowedWidth)
    let itemHeight = lines * lineHeight
    currentHeight += itemHeight + itemSpacing
    
    if currentHeight > allowedHeight { break }
    result += 1
  }
  
  return result
}

With this adjustment, we account for the checkbox width, the spacing between the checkbox and the text, and the horizontal padding (itemPadding), and the vertical padding around the list (listPadding). Let’s verify one more time:

Perfect. No clipping, clean edges, and it works with any content length.

Reflections

Working with widget code always feels a bit constrained. You have to accept certain limitations and adapt your expectations. But by using some lesser-known APIs and a bit of maths, we ended up in a good spot. The widget now gracefully handles user content of any length, showing as many items as will fit without breaking the visual design.

If you’re building widgets with dynamic content, I hope this approach saves you some debugging time. And if you have questions or improvements to suggest, feel free to send me a message.

Header photo by Immo Wegmann on Unsplash

Building a Maze Generation Framework

Sun, 09 Nov 2025 00:00:01 +0000

Iwasn’t looking for a game idea when I picked up Mazes for Programmers by Jamis Buck. I was just curious about algorithms and looking for something different from the usual data structures textbooks. And the book gave me that - it was incredibly well-written. I couldn’t stop reading. But there was one problem: all the code examples were in Ruby.

Ruby is not exactly my cup of tea. As an iOS developer, I am familiar with it, but I never got fluent. But I was itching for a new project, and I wanted to truly understand these algorithms, not just copy code in a language I didn’t know. So I embraced the challenge and started converting the code to Swift. What began as a simple translation exercise eventually evolved into a full Swift framework, then a demo app, and ultimately became an iOS game called MZ: Maze Adventures.

This is the story of that journey - specifically, the technical foundation that made everything else possible.

What Makes Maze Algorithms Fascinating

Before diving into the code, let me share what captured my imagination about maze algorithms. They don’t just generate mazes; they generate perfect mazes. In graph theory terms, a perfect maze is a spanning tree of all cells in the grid. This means:

The maze is connected (you can reach any cell from any other cell)
It’s acyclic (no loops)
It has exactly V-1 edges for V vertices
Most importantly: there’s exactly one path between any two cells

But here’s where it gets interesting: different algorithms produce mazes with vastly different characteristics, almost like different “personalities.”

Three Algorithms, Three Personalities

Recursive Backtracker (Depth-First Search)
This algorithm explores as far as possible before backtracking, creating long, winding corridors with fewer branches. The result is what’s called a “river pattern”: paths that players can get trapped in for extended exploration. It has high complexity and is ideal for more challenging puzzles.

Prim’s Algorithm (Randomised)
Prim’s randomly expands from the growing maze, creating many short dead ends with a tree-like structure. It feels more organic and natural, offering frequent decision points for the player. The complexity is medium, with many branching choices.

Binary Tree
Each cell makes a binary choice (typically north or east), resulting in a strong diagonal bias and predictable texture. Its main benefit? It’s very fast to generate. The downside is that the bias makes solutions easier to find. You can often solve these mazes by following the long corridors on the top or right edges.

For MZ: Maze Adventures, I ultimately chose Recursive Backtracker because I liked how the long corridors looked, and the higher complexity made it more challenging for players.

The Ruby to Swift Translation Challenge

When I began translating the algorithms, I had to consider every detail carefully. Ruby and Swift are fundamentally different languages with different paradigms, and that meant more than just syntax changes.

Here’s a side-by-side comparison of the Recursive Backtracker algorithm:

Ruby (from the book):

class RecursiveBacktracker
  def self.on(grid, start_at: grid.random_cell)
    stack = []
    stack.push start_at
    while stack.any?
      current = stack.last
      neighbors = current.neighbors
        .select { |n| n.links.empty? }
      if neighbors.empty?
        stack.pop
      else
        neighbor = neighbors.sample
        current.link(neighbor)
        stack.push(neighbor)
      end
    end
    grid
  end
end

Swift (my framework):

public class RecursiveBacktrackerMazeGenerator: MazeGenerating {
    private var stack: [Cell] = []
    
    public func generateStep() 
      -> (generated: [Cell], evaluating: [Cell])? {
        
        let current = stack.last!
        let unvisitedNeighbours = grid
            .neighbours(of: current)
            .filter { $0.links.isEmpty }
        
        if unvisitedNeighbours.isEmpty {
            _ = stack.popLast()
        } else {
            let neighbour = 
              unvisitedNeighbours.randomElement()!
            grid.link(cell1: current, cell2: neighbour)
            stack.append(neighbour)
        }
        return (generated: [current], 
                evaluating: stack)
    }
}

The logic is identical - both use a stack to track visited cells, both explore neighbours, and both backtrack when stuck. But the differences reveal each language’s philosophy:

Ruby’s neighbors.sample is elegant and expressive
Swift requires randomElement()! with explicit unwrapping
Ruby uses class methods (def self.on), while I used instance methods
Swift’s type safety means more explicit handling of optionals

Beyond One-to-One Translation

Initially, I translated the algorithms one-to-one. But then I wanted to visualise the generation of mazes step by step, not all at once. This forced me to restructure the code - instead of generating a complete maze in one pass, I needed a generateStep() method that returned intermediate states.

For three of the twelve algorithms I translated, I abandoned the Ruby code completely and implemented them based purely on the algorithm descriptions in the book. By that point, I understood the patterns well enough that it was actually easier than getting stuck in translation.

Building a Framework, Not Just Code

The real insight came when I decided to build this as a proper Swift framework rather than just a collection of files. This decision paid massive dividends later.

Protocol-Oriented Design

At the core of the framework is the MazeGenerating protocol:

protocol MazeGenerating {
    var grid: Grid { get set }
    func generateMaze(in grid: Grid)
    func generateStep() -> (generated: [Cell], evaluating: [Cell])?
}

This simple protocol allowed for easy swapping of algorithms. Need a different maze style? Just change the algorithm. Want to compare algorithms visually? Iterate through them. The flexibility was incredible.

Key Design Principles

Principle 1: Separation of Concerns

Grid handles cell structure and topology
Cell manages individual cell state and links
Algorithms implement MazeGenerating
Solvers (like Dijkstra’s) work on any valid maze

Principle 2: Type Safety Prevents Errors

Can’t link cells from different grids
Can’t access out-of-bounds cells
Can’t create invalid maze states
Swift’s type system catches these at compile time

Principle 3: Reference Semantics with Observable State for Real-Time Visualisation

@Observable
final class Grid {
    private var cells: [[Cell]]
    
    func link(cell1: Cell, cell2: Cell) {
        cell1.links.insert(cell2)
        cell2.links.insert(cell1)
        // Changes automatically notify SwiftUI views
    }
}

@Observable
final class Cell {
    var links: Set<Cell> = []
    var visited: Bool = false
}

Why this design choice:

Grid and cells are classes because they’re mutated during maze generation
The algorithm modifies the grid in place; changes happen instantly
@Observable allows SwiftUI views to automatically redraw as cells are linked
In the demo app, watching the maze generate step-by-step in real time was only possible because SwiftUI could react to these observable state changes
The visualisation loop becomes trivial: algorithm mutates observable grid → SwiftUI redraws → user sees generation in progress

The power of this approach: Separating the generative algorithm from UI concerns through @Observable meant the demo app didn’t need complex bindings or manual refresh logic. SwiftUI’s reactive framework automatically handled the visualisation.

From Framework to Demo App

In order to see what I was generating - and this will sound very familiar to iOS developers - I added a demo app to the framework. The demo app was written in SwiftUI and imported the framework.

The demo app lets you:

Select different maze generation algorithms
Generate mazes with a button press
Visualise the maze structure

Then, I added a solver using Dijkstra’s algorithm to show the optimal paths through the maze. Watching the solver trace the perfect path through a Recursive Backtracker maze was mesmerising.

The “Aha” Moment

Even before finishing the book, I was already thinking: This could be a game, right?

Once I could visualise these mazes and watch the solver find optimal paths, the game idea crystallised. Players could attempt to solve mazes with a limited number of moves. The solver could calculate fair move limits. Power-ups could let players bend the rules.

The framework was no longer just a learning project. It was the foundation for something playable.

Lessons Learned

Framework Separation Pays Off

Building a separate framework compelled me to consider interfaces and contracts. When I later built the game, I could import the framework and immediately have working maze generation - no copy-pasting, no coupling. The framework could be tested independently, and game logic stayed cleanly separated from maze generation.

Translation Forces Deep Understanding

Translating the Ruby algorithms to Swift made me understand them far more deeply than if I’d just read the Ruby code. I had to think about data structures, error handling, performance, and architecture. Every design decision was intentional, not just inherited from the source.

Visualisation Changes Everything

The demo app wasn’t just a nice-to-have; it fundamentally changed how I understood the algorithms. Seeing the mazes generate, watching the solver work, experimenting with parameters - this hands-on interaction revealed insights I would never have gained from code alone.

Start Simple, Iterate Quickly

The framework started with just three algorithms and basic functionality. But because the design was sound (thank you, protocol-oriented programming), I added eight more algorithms over time. Each took 30-60 minutes to implement with no changes to existing code.

What’s Next

This framework became the foundation for MZ: Maze Adventures, an iOS game that’s currently in beta testing. In future articles, I’ll dive into:

Building the game layer on top of the framework
SwiftUI for game development (pros and cons)
Progression, power-ups, and game economy

But it all started here: with a curious developer, a Ruby book, and the decision to translate algorithms into Swift.

Want to explore maze generation yourself? The framework is open-source on GitHub. Start with the Recursive Backtracker - it’s the most rewarding to watch in action. Or if you are into Ruby, I can recommend a great book! Find it here: Mazes for Programmers.

Visual debugging with Swift Charts

Sat, 08 Nov 2025 00:00:01 +0000

When I decided to implement the algorithm Soroush Khanlou so brilliantly described in his Elevated Swift talk I didn’t expect that the hardest part would be not the algorithm for the elevator (or lift, as we call it here), but rather the one for generating the traffic.

Let’s take a step back and describe what we are trying to achieve. We have an office building with a few lifts going up and down the floors. As a typical office building we want to simulate a realistic flow of people - more during the week, less on weekends; more arriving in the morning, less so at night. We also want to keep the randomness element. And let’s not forget the lunch break with lots of people going out and back in mumbling about the queue at the lifts.

When we take all this into consideration, our next step is to decide how often we run the algorithms - both for the lifts and for the traffic flow. As we want to ideally animate the lifts at some point, we need a loop running at a set interval, ideally a short one. We also need fake in-game time or otherwise our game will only work in real time and everything will take forever. This will also help us implement controls to slow and fasten the in-game time. After some experimentation, I arrived the following:

We have a timer that “ticks” at a set interval.
Every “tick” equals 10 seconds in-game time.
The initial “tick” interval is 0.5 seconds, with controls for changing it down to 0.01 (less is faster). I reached these timings with trial and error to what felt like a good pace - not too slow but also not too fast.

Some sloppy SwiftUI designing later, and we have our first running version. We can see the three lifts going up and down. There are people arriving at the ground floor. The lifts seem to be working well.

I showed it to a friend at the office and we decided to speed it up and see what happens. This would also allow me to show him a feature I’ve been building - a screen of charts for the enterpreneur who will manage the company maintaining the lifts. The more data we have, the more interesting and useful the charts will be.

We let it run for a couple of hours and then opened the screen with the charts.

Even though the lifts seemed to be working fine, we could easily spot a problem upon seeing the charts. The shape of the chart was the same regardless of the day of the week. The people generation algorithm should have prevented this from happening.

Good thing that I decided to include charts in the game or otherwise I would have missed this. And it didn’t take much. All I needed to do is save the journey data and then display it. Moreover, Swift Charts allows you to show live charts which brings dynamisms to the game.

Every time we update the building occupancy, we save a log entry.

let newPeople = peopleArriving(hour: hour, day: day)
let peopleGoingOut = goingOut(hour: hour, day: day)
currentOccupancy += newPeople - peopleGoingOut
generateCalls(newPeople: newPeople, peopleGoingOut: peopleGoingOut)
log.append(
    LogEntry(
        date: date,
        occupancy: currentOccupancy,
        groundFloorQueue: hallCalls.filter { $0.from == 0 }.count
    )
)

The code to show the charts is pretty straightforward.

Button("Stats") {
    showingStats.toggle()
}
.sheet(isPresented: $showingStats) {
    GroupBox("Building Occupancy") {
        Chart {
            ForEach(dispatcher.building.log) { item in
                BarMark(x: .value("Minute", item.date, unit: .minute),
                        y: .value("People", item.occupancy))
            }
        }
    }
    .padding([.horizontal, .top])
    GroupBox("Ground Floor Queue") {
        Chart {
            ForEach(dispatcher.building.log) { item in
                BarMark(x: .value("Minute", item.date, unit: .minute),
                        y: .value("Ground Floor Q", item.groundFloorQueue))
            }
        }
    }
    .padding()
    .presentationDetents([.medium, .large])
}

After fixing the issue with the daily crowd generation, I realised I needed to wait until the game generates enough data to see the result. I decided to add a button to generate a day worth of data in a second. That way I could see the results immediately.

The difference was immediately visible. The weekday patterns now showed the expected morning rush, lunch dip, and evening departure patterns, while weekends remained appropriately quiet. Without the visual representation, I might have spent hours stepping through code or worse, shipped a simulation that looked fine on the surface but behaved incorrectly underneath.

This experience reinforced an important lesson: when building complex systems with time-based behaviour, visual feedback isn’t just nice to have; it’s essential. Swift Charts made it trivially easy to add this debugging capability, and the investment of a few dozen lines of code saved hours of blind debugging. The charts became not just a feature for the game’s entrepreneur character, but a development tool that continues to help me validate new features and catch regressions.

If you’re working with any kind of time-series data or algorithmic behaviour, consider adding charts early in your development process. Future you will be grateful.

How to create a playful letter animation

Sat, 04 Mar 2023 00:00:01 +0000

Ihave been working on a word game recently, and I wanted to have nice playful animations to make the UI more fun. I decided to improvise, and the result turned out well. In this post, I will explain how you can create this effect and engage your users.

A journey of a great animation begins with a single letter. Or something. Let’s start our journey by designing a letter tile.

struct SingleLetter: View {
    let letter: Character
    let backgroundColor: Color
    let letterColor: Color
    
    var body: some View {
        Text(String(letter))
            .foregroundColor(letterColor)
            .font(.title3)
            .fontWeight(.heavy)
            .frame(width: 44, height: 44)
            .background(backgroundColor)
    }
}


struct SingleLetter_Previews: PreviewProvider {
    static var previews: some View {
        SingleLetter(letter: "W",
                     backgroundColor: .brown,
                     letterColor: .white)
    }
}

This is good enough for now. Using previews enables us to quickly test different colours and font sizes and land on an excellent combination. Expanding the preview will help us see the letter in context. That way, we can inform the code we will write next.

struct SingleLetter_Previews: PreviewProvider {
    static var previews: some View {
        HStack {
            SingleLetter(letter: "W",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "O",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "R",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "D",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
        }
    }
}

My instinct tells me to move the border definitions into the SingleLetter struct. I will hold off for now as I want to animate the borders later, and I am still determining where I can do that better.

Next, let’s create our word view, constructed by combining a bunch of letters. We already have the code in the preview above, so all we have to do is copy it to a new view.

struct SingleWord: View {
    var body: some View {
        HStack {
            SingleLetter(letter: "W",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "O",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "R",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
            SingleLetter(letter: "D",
                         backgroundColor: .brown,
                         letterColor: .white)
            .border(.orange)
        }
    }
}

struct SingleWord_Previews: PreviewProvider {
    static var previews: some View {
        SingleWord()
    }
}

We already saw the result in the preview of the previous view, so let’s keep going. Next, let’s parametrise a little. We need to inject the word we want to show instead of hardcoding it.

struct SingleWord: View {
    let letters: [Character]

    init(word: String) {
        self.letters = Array(word)
    }
    
    var body: some View {
        HStack {
            ForEach(letters, id: \.self) { letter in
                SingleLetter(letter: letter,
                             backgroundColor: .brown,
                             letterColor: .white)
                .border(.orange)
            }
        }
    }
}

struct SingleWord_Previews: PreviewProvider {
    static var previews: some View {
        SingleWord(word: "WORD")
    }
}

Again, the preview is the same.

And we finally arrived at the interesting part. Let’s shake these letters! We can start by rotating them left and right continuously. Some trial and error help us determine the angle that will best serve our needs. Here you can see what happens when we try .rotationEffect(Angle(degrees: -20)) and .rotationEffect(Angle(degrees: +20))

To animate the angle, we need to make a few changes. We need a state var to hold a value that can be animated. We will use a boolean in this case. We also need to use the powerful .animation view modifier. There are many animation settings you can play with. For our purposes, a simple .linear animation will suffice, with a duration of 1 second. We will set it to repeat forever and autoreverse as we don’t want the letters to suddenly twitch. Let’s see the code.

struct SingleWord: View {
    @State private var isAnimating = false
    private let letters: [Character]

    init(word: String) {
        self.letters = Array(word)
    }
    
    var body: some View {
        HStack {
            ForEach(letters, id: \.self) { letter in
                SingleLetter(letter: letter,
                             backgroundColor: .brown,
                             letterColor: .white)
                .border(.orange)
                .rotationEffect(Angle(degrees: isAnimating ? -20 : 20))
                .animation(.linear(duration: 1).repeatForever(autoreverses: true), value: isAnimating)
            }
        }
        .onAppear {
            isAnimating = true
        }
    }
}

They are moving! Job done? No. I don’t know about you, but to me, that looks more like marching than dancing. It is too perfect and uniform. We can alternate rotating letters - while the first rotates from -20 to 20 degrees, the second rotates from 20 to -20 degrees, and so on. In addition, we will introduce explicit spacing for the HStack as we need the letters to be further apart and not overlap when they “dance”.

    var body: some View {
        HStack(spacing: 20) {
            ForEach(letters.indices, id: \.self) { index in
                let letter = letters[index]
                SingleLetter(letter: letter,
                             backgroundColor: .brown,
                             letterColor: .white)
                .border(.orange)
                .rotationEffect(Angle(degrees: isAnimating ? angles(for: index).from : angles(for: index).to))
                .animation(.linear(duration: 1).repeatForever(autoreverses: true), value: isAnimating)
            }
        }
        .onAppear {
            isAnimating = true
        }
    }
    
    private func angles(for index: Int) -> (from: Double, to: Double) {
        index.isMultiple(of: 2) ? (from: -20, to: 20) : (from: 20, to: -20)
    }

To make the movements even less perfect we can introduce randomness. Instead of returning -20 or 20, the angles method can return something like Double.random(in: 18...22), for example.

So far, we have managed to produce rotating letters. Our target is dancing letters so let’s keep going. The other two attributes we can animate are scale and border width. Changing the scale of the letters will introduce a pulsating effect, which, combined with a border thickness, will have the desired result. We want all these animations to happen in unison. That’s why we will use the same isAnimating variable to control all of them. Let’s start with scale. We don’t want the letters to get too big or too tiny, so the scale factor shouldn’t change more than 10-20%. You can play with it and see what values work for you. For my needs, 0.85 - 1.15 works best. Once again, feel free to add randomness for even better results.

    var body: some View {
        HStack(spacing: 20) {
            ForEach(letters.indices, id: \.self) { index in
                let letter = letters[index]
                SingleLetter(letter: letter,
                             backgroundColor: .brown,
                             letterColor: .white)
                .border(.orange)
                .rotationEffect(Angle(degrees: isAnimating ? angles(for: index).from : angles(for: index).to))
                .scaleEffect(isAnimating ? scale(for: index).from : scale(for: index).to)
                .animation(.linear(duration: 1).repeatForever(autoreverses: true), value: isAnimating)
            }
        }
        .onAppear {
            isAnimating = true
        }
    }
    
    private func angles(for index: Int) -> (from: Double, to: Double) {
        index.isMultiple(of: 2) ? (from: -20, to: 20) : (from: 20, to: -20)
    }
    
    private func scale(for index: Int) -> (from: Double, to: Double) {
        index.isMultiple(of: 2) ? (from: 0.85, to: 1.15) : (from: 1.15, to: 0.85)
    }

We are almost there. Next, let’s animate our borders too, and introduce that randomness I keep mentioning. Also, let’s change the preview background and see how our letters perform on a darker stage.

struct SingleWord: View {
    @State private var isAnimating = false
    private let letters: [Character]

    init(word: String) {
        self.letters = Array(word)
    }
    
    var body: some View {
        HStack(spacing: 20) {
            ForEach(letters.indices, id: \.self) { index in
                let letter = letters[index]
                SingleLetter(letter: letter,
                             backgroundColor: .brown,
                             letterColor: .white)
                .border(.orange, width: isAnimating ? 5 : 0)
                .rotationEffect(Angle(degrees: isAnimating ? angles(for: index).from : angles(for: index).to))
                .scaleEffect(isAnimating ? scale(for: index).from : scale(for: index).to)
                .animation(.linear(duration: 1).repeatForever(autoreverses: true), value: isAnimating)
            }
        }
        .onAppear {
            isAnimating = true
        }
    }
    
    private func angles(for index: Int) -> (from: Double, to: Double) {
        let firstAngle = Double.random(in: -22 ... -18)
        let secondAngle = Double.random(in: 18 ... 22)
        return index.isMultiple(of: 2) ? (from: firstAngle, to: secondAngle) : (from: secondAngle, to: firstAngle)
    }
    
    private func scale(for index: Int) -> (from: Double, to: Double) {
        let firstScale = Double.random(in: 0.85 ... 0.9)
        let secondScale = Double.random(in: 1.1 ... 1.15)
        return index.isMultiple(of: 2) ? (from: firstScale, to: secondScale) : (from: secondScale, to: firstScale)
    }
}

struct SingleWord_Previews: PreviewProvider {
    static var previews: some View {
        ZStack {
            Color.black.opacity(0.8).ignoresSafeArea()
            SingleWord(word: "PLAY")
        }
    }
}

In summary, we created a cool dancing effect that can delight our users. We didn’t even have to build and run the app; we saw all the action in the live previews. Where to go from here? You can add more animations to your views. Another easily animatable property is the offset. I didn’t include it here as it would have been a bit too much animating all at once. Another thing you can do is extract the rest of the hardcoded values, such as the frame size, the spacing, and the border width, and play with them. Let me know what you manage to achieve.

You can download the code for this post from https://github.com/dchakarov/letter-play.

Let me filter that for you

Sun, 03 Jul 2022 00:00:01 +0000

TL;DR Let’s create a Swift script that will take a list of stocks and a finance API key and give us a shortlist of dividend stocks we should consider investing in. Our script focuses on Freetrade & uses a Yahoo Finance alternative API, but it can be easily adapted to work with any list of stock tickers and any finance API. Get the code here.

Every Friday at Just Eat Takeaway we have a meeting called WWDC-watchers. It’s organised and hosted by the iOS team and open to everyone. We spend half an hour discussing a WWDC (or related) video we picked and watched during the week leading to the meeting. We keep it simple - everyone sticks a bunch of sticky notes on a dedicated virtual board, and at the meeting, we go over them one by one, sharing what we learned and how we feel about the topic.

At a recent event, we discussed a Tech Talk on a somewhat obscure Apple framework called TabularData. Watching the video and discussing it with my fellow developers excited me about the framework, and I decided to use it for an idea I had at the time.

For the past few years, I have been using Freetrade for investing. This is not an endorsement, nor is it financial advice. I primarily focus on the so-called dividend investing with the occasional impulsive buy. I choose companies to invest in by searching online or asking friends for recommendations and then doing my due diligence. Before spending too much time on research, I also need to ensure a given company is available on Freetrade.

I don’t start my research on Freetrade and instead need to go out of my way to find suitable companies because of the app’s lack of filters or tools to get to the companies that match my criteria. You are presented with a massive list of thousands of companies without filtering or sorting. Going to their website gives you some filters, but that is far from enough. Moreover, you can only see 20 companies at a time. It looks pretty, but it’s not very useful. Thankfully, if you scroll past the list, you will find a link to a google sheet with all the companies available on the platform.

You can, of course, use your superpowers in filtering google sheets to achieve what you want. But where is the fun in that? Instead, I downloaded the list in CSV and gave TabularData a spin. To learn more about TabularData I recommend you read this amazing introduction.

Before we dive into Xcode let’s have a look at the data. We have around 6300 companies with 14 properties for each of them. Let’s see which of these properties are useful for us:

Title - the company display name, the way it will appear in the app, e.g. Just Eat Takeaway.com
Long_Title - the full company name, e.g. Just Eat Takeaway.com NV
Subtitle - what the company does, e.g. Online food ordering
Currency - the currency, e.g. gbp
ISA_eligible - if you can buy the company for your ISA account, e.g. TRUE
SIPP_eligible - if you can buy the company for your SIPP account, e.g. TRUE
ISIN - no idea, e.g. NL0012015705
MIC - no idea, e.g. XLON
Symbol - the stock ticker, e.g. JET
Fractional_Enabled - whether you can buy fractional shares of the company, e.g. FALSE
PLUS_only - whether you need a PLUS Freetrade account to buy the company, e.g. FALSE
for_Ireland_investors - no idea, e.g. FALSE
for_Netherlands_investors - no idea, e.g. FALSE
KIID_URL - a link to a “Key Investor Information” document

As you can see, there is no information about any market performance metrics - dividend payments, dividend growth, market cap, current price, etc. The only properties we can use for our purposes are Title, Currency (if we want to focus on a given market, e.g. the US), ISA_eligible (as my account is an ISA), Symbol, and PLUS_only, as I am wondering whether to subscribe to their PLUS plan.

Start with creating a command line Xcode project. Add the ArgumentParser package by going to File -> Add Packages and selecting it from the Apple Swift Packages collection. Next, since we want to have the CSV file as an input to our script, let’s add it to the scheme arguments like so:

Next, let’s start by parsing our file and printing out what we read:

import TabularData
import Foundation
import ArgumentParser

@main
struct DivStocks: AsyncParsableCommand {
    @Option(name: .long, help: "The input filename with full path")
    private var inputFile: String

    func run() async throws {
        let fileUrl = URL(fileURLWithPath: inputFile)
        let pathUrl = fileUrl.deletingLastPathComponent()
        let options = CSVReadingOptions(hasHeaderRow: true,
                                        delimiter: ",")
        let fullDataFrame = try! DataFrame(
            contentsOfCSVFile: fileUrl,
            columns: ["Symbol",
                "Title",
                "Currency",
                "ISA_eligible",
                "PLUS_only"],
            types: [
                "Symbol": .string,
                "Title": .string,
                "ISA_eligible": .boolean,
                "Currency": .string,
                "PLUS_only": .boolean],
            options: options)
        print(fullDataFrame)
    }
}

Please note that I will not go into much detail on the TabularData framework itself, as this is very well covered in both the video and the article I linked above.

Running the script in Xcode should give us something like this in the console:

┏━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃    ┃ Symbol   ┃ Title               ┃ Currency ┃ ISA_eligible ┃ PLUS_only ┃
┃    ┃ <String> ┃ <String>            ┃ <String> ┃ <Bool>       ┃ <Bool>    ┃
┡━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ 0  │ ABNa     │ ABN AMRO Bank       │ eur      │ false        │ true      │
│ 1  │ ECMPAa   │ Eurocommercial      │ eur      │ false        │ true      │
│ 2  │ AVTXa    │ Avantium            │ eur      │ true         │ true      │
│ 3  │ VASTNa   │ Vastned Retail      │ eur      │ true         │ true      │
│ 4  │ VVYa     │ Vivoryon Thera      │ eur      │ true         │ true      │
│ 5  │ FURa     │ Fugro               │ eur      │ true         │ true      │
│ 6  │ VLKa     │ Van Lanschot Kempen │ eur      │ true         │ true      │
│ 7  │ FASTa    │ Fastned             │ eur      │ true         │ true      │
│ 8  │ BRNLa    │ Brunel              │ eur      │ true         │ true      │
│ 9  │ CMCOMa   │ CM.com              │ eur      │ true         │ true      │
│ 10 │ EBUSa    │ Ebusco              │ eur      │ true         │ true      │
│ 11 │ BBEDa    │ Beter Bed           │ eur      │ true         │ true      │
│ 12 │ ACOMOa   │ Amsterdam Commod    │ eur      │ true         │ true      │
│ 13 │ KENDRa   │ Kendrion            │ eur      │ true         │ true      │
│ 14 │ PNLa     │ PostNL              │ eur      │ true         │ true      │
│ 15 │ ALFENa   │ Alfen Beheer        │ eur      │ true         │ true      │
│ 16 │ AMGa     │ AMG Advanced Metal  │ eur      │ true         │ true      │
│ 17 │ AALBa    │ Aalberts            │ eur      │ true         │ true      │
│ 18 │ JDEPa    │ JDE Peet's          │ eur      │ true         │ true      │
│ 19 │ VPKa     │ Koninklijke Vopak   │ eur      │ true         │ true      │
┢╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍┪
┇ ...                                                                       ┇
┗╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┛
6,359 rows, 5 columns

Let’s filter out non-US companies and only include those that require a paid subscription and are ISA-eligible. This will help me decide if a PLUS plan subscription is worth my money.

        let dataFrame = fullDataFrame
            .filter(on: "Currency", String.self, { $0 == "usd" })
            .filter(on: "ISA_eligible", Bool.self, { $0! })
            .filter(on: "PLUS_only", Bool.self, { $0! })
            .selecting(columnNames: "Symbol", "Title")

        print(dataFrame)

We get a much shorter list of 445 companies. It’s still a lot to sip through one by one, but a significant improvement over the 6359 companies above.

┏━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃      ┃ Symbol   ┃ Title                    ┃
┃      ┃ <String> ┃ <String>                 ┃
┡━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 2255 │ ANDE     │ Andersons                │
│ 2281 │ TILE     │ Interface                │
│ 2358 │ CALM     │ Cal-Maine Foods          │
│ 2592 │ DCOM     │ Dime Community           │
│ 2595 │ CPSI     │ Computer Programs        │
│ 2789 │ CONN     │ Conn's                   │
│ 2799 │ ANIK     │ Anika Therapeutics       │
│ 2915 │ AGYS     │ Agilysys                 │
│ 2924 │ CMTL     │ Comtech Telecomm         │
│ 2962 │ COOP     │ Mr Cooper Group          │
│ 3049 │ APEI     │ American Public Ed       │
│ 3065 │ MDRX     │ Allscripts Health        │
│ 3126 │ BCOR     │ Blucora                  │
│ 3141 │ PDFS     │ PDF Solutions            │
│ 3153 │ BJRI     │ BJ's Restaurant          │
│ 3155 │ SPPI     │ Spectrum Pharmaceuticals │
│ 3159 │ VREX     │ Varex Imaging            │
│ 3164 │ THRM     │ Gentherm                 │
│ 3170 │ FARO     │ Faro                     │
│ 3181 │ ANGO     │ Angiodynamics            │
┢╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┪
┇ ...                                        ┇
┗╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┛
445 rows, 2 columns

Next, we need to figure out a way to enrich the data about these companies with details about market cap, dividends, PE ratio, and other useful information. As developers, we know the best way to do that is by using an API. I googled for a free one, and not many came up. Most don’t offer dividend data, so I ended up using this Yahoo Finance alternative API. It has a free tier offering 100 requests per day, which is a very low number, so we need to be very careful when using it, or we would need to wait until tomorrow to continue our experiments. Since we don’t plan to be running this script frequently, a one-time parsing of the data is more than enough, and we can save some money by using the free tier.

Looking at the documentation, the /v6/finance/quote endpoint is suitable for our needs. It gives us a lot of data for a given company, and we can also query 10 companies at a time, which, considering the 100 requests/day limit, means that by grouping our requests we can get data for all of the 445 companies in one day. Let’s create a model that matches the fields we need from the response:

struct Stock: Decodable {
    let symbol: String
    let trailingAnnualDividendYield: Double?
    let trailingPE: Double?
    let averageAnalystRating: String?
    let marketCap: Int?
    let epsTrailingTwelveMonths: Double?
}

struct QuoteResponse: Decodable {
    let result: [Stock]
}

struct StockResponse: Decodable {
    let quoteResponse: QuoteResponse
}

Depending on your investment strategy and where the market is at a given time, your filters might be vastly different from mine. Even mine might change from day to day. That’s why it makes sense to download and store the market data for these 445 companies and then be able to tweak our filters at will without worrying about API rate limiting.

Let’s design our API client to do just that. Our saveStocks() method will need two arguments - the list of stock symbols (remember, up to 10) and our API key.

func saveStocks(symbols: [String], apiKey: String, pathUrl: URL) async throws {
    let parameters = [
        "region": "US",
        "lang": "en",
        "symbols": symbols.joined(separator: ",")
    ]
    var components = URLComponents(string: "https://yfapi.net/v6/finance/quote")!
    components.queryItems = parameters.map { (key, value) -> URLQueryItem in
        URLQueryItem(name: key, value: String(value))
    }
    var request = URLRequest(url: components.url!)
    request.httpMethod = "GET"
    request.addValue("application/json; charset=utf-8", forHTTPHeaderField: "Content-Type")
    request.addValue(apiKey, forHTTPHeaderField: "X-API-KEY")
    let (data, response) = try await session.data(for: request)
    guard (response as? HTTPURLResponse)?.statusCode == 200 else {
        throw APIClientError.invalidResponse
    }

    let fileUrl = pathUrl.appendingPathComponent("stocks-\(symbols[0]).json")
    try data.write(to: fileUrl)
}

We are using the first symbol in each group as a name for the file - you can improvise here, like using numbers or hashing the list. Since all the symbols are unique, picking the first one should be good enough. Looking at the folder afterwards, we can see the resulting files.

Our next step is to add a method to read the files and return them to our script. We already have all the necessary parts for this, so the technique is relatively straightforward.

func stocks(symbols: [String], pathUrl: URL) async throws -> [Stock] {
    let fileUrl = pathUrl.appendingPathComponent("stocks-\(symbols[0]).json")
    do {
        let data = try Data(contentsOf: fileUrl)
        let decoder = JSONDecoder()
        let decoded = try decoder.decode(StockResponse.self, from: data)
        return decoded.quoteResponse.result
    } catch {
        return []
    }
}

Let’s return to our main script and use the methods we created. First, let’s update the script to accept some more arguments. We need one for the mode (i.e. whether we are saving data to disk or parsing it) and one for our API key. This is how the first few lines look now.

struct DivStocks: AsyncParsableCommand {
    @Option(name: .long, help: "The input filename with full path")
    private var inputFile: String
    @Option(name: .long, help: "Whether to save data locally or use it to do analysis. Use 'save' or 'parse' or leave out to parse")
    private var mode: String?
    @Option(name: .long, help: "You API key for yahoofinanceapi.com")
    private var apiKey: String?

    func run() async throws {
        let fileUrl = URL(fileURLWithPath: inputFile)
        let pathUrl = fileUrl.deletingLastPathComponent()
        let shouldSave: Bool = (mode == "save")
        let options = CSVReadingOptions(hasHeaderRow: true, delimiter: ",")

Next, we create a new temporary data frame containing only the symbols and use Apple’s Algorithms framework to group them in chunks of 10 quickly. We need these chunks for both getting the API data and parsing the already saved files.

let tickerData = dataFrame.selecting(columnNames: "Symbol")
let symbolGroups = tickerData.rows.compactMap { row in
    (row["Symbol"] as! String)
}.chunks(ofCount: 10)

The save mode is straightforward - we use our API client and pass the chunks of symbols.

if shouldSave {
    let apiClient = APIClient()
    guard let apiKey = apiKey else {
        print("Please provide an API key if you want to save stock data.")
        return
    }
    for symbolGroup in symbolGroups {
        try await apiClient.saveStocks(symbols: Array(symbolGroup), apiKey: apiKey, pathUrl: pathUrl)
    }
    print("Stock data saved!")
} else {

Running the script at this point should save all the downloaded data to the same folder as the input file.

$ ./stock-tables --input-file "~/stocks/all-freetrade-stocks.csv" \
    --mode save --api-key ghdssngdskFigselAsngshkmvakgjdDsggv

Now for the fun part. Let’s pick our stocks! First, we want to create a new table containing the data we gathered from the API. We will include:

The stock symbol.
The market cap.
The trailing dividend yield.
The trailing PE ratio.
The trailing EPS.
The average analyst rating.

Feel free to adapt this part to include or exclude what you think you need for your filters.

We create our table by creating the columns with capacity matching the number of companies we have as an input, then adding our data to the columns, and in the end, appending the columns to an empty table. It feels a bit counter-intuitive, especially if you are used to working with other data structures in Swift.

var symbolCol = Column<String>(name: "symbol", capacity: rowCount)
var marketCapCol = Column<Int>(name: "marketCap", capacity: rowCount)
var divCol = Column<Double>(name: "trailingAnnualDividendYield", capacity: rowCount)
var peCol = Column<Double>(name: "trailingPE", capacity: rowCount)
var ratingCol = Column<String>(name: "averageAnalystRating", capacity: rowCount)
var epsCol = Column<Double>(name: "epsTrailingTwelveMonths", capacity: rowCount)
var stocksDataFrame = DataFrame()

let apiClient = APIClient()
for symbolGroup in symbolGroups {
    let stocks = try await apiClient.stocks(symbols: Array(symbolGroup), pathUrl: pathUrl)
    for stock in stocks {
        symbolCol.append(stock.symbol)
        marketCapCol.append(stock.marketCap)
        divCol.append(stock.trailingAnnualDividendYield)
        peCol.append(stock.trailingPE)
        ratingCol.append(stock.averageAnalystRating)
        epsCol.append(stock.epsTrailingTwelveMonths)
    }
}

stocksDataFrame.append(column: symbolCol)
stocksDataFrame.append(column: marketCapCol)
stocksDataFrame.append(column: divCol)
stocksDataFrame.append(column: peCol)
stocksDataFrame.append(column: ratingCol)
stocksDataFrame.append(column: epsCol)

The result is a nice table with all the data we need:

┏━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃    ┃ symbol   ┃ marketCap     ┃ trailingAnnualDividendYield ┃ trailingPE ┃ averageAnalystRating ┃ epsTrailingTwelveMonths ┃
┃    ┃ <String> ┃ <Int>         ┃ <Double>                    ┃ <Double>   ┃ <String>             ┃ <Double>                ┃
┡━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 0  │ ANDE     │ 1,294,674,176 │                    0.018702 │  12.473925 │ 2.0 - Buy            │                   3.068 │
│ 1  │ TILE     │   788,537,728 │                    0.002996 │  14.151548 │ 2.3 - Buy            │                   0.937 │
│ 2  │ CALM     │ 2,479,804,928 │                     0.00245 │  136.57681 │ 2.7 - Hold           │                   0.371 │
│ 3  │ DCOM     │ 1,203,996,672 │                    0.031424 │   8.220793 │ 1.6 - Buy            │                   3.732 │
│ 4  │ CPSI     │   476,646,464 │                         0.0 │  25.619047 │ 2.2 - Buy            │                    1.26 │
│ 5  │ CONN     │   347,763,008 │                         0.0 │   4.049861 │ 2.3 - Buy            │                    3.61 │
│ 6  │ ANIK     │   324,038,112 │                         0.0 │  79.571434 │ 2.3 - Buy            │                    0.28 │
│ 7  │ AGYS     │   891,197,696 │                         0.0 │        nil │ 2.3 - Buy            │                  -0.902 │
│ 8  │ CMTL     │   324,026,752 │                    0.033167 │        nil │ 2.0 - Buy            │                  -1.013 │
│ 9  │ COOP     │ 3,162,441,984 │                         0.0 │   2.293386 │ 2.2 - Buy            │                  18.658 │
│ 10 │ APEI     │   257,012,736 │                         0.0 │  14.051546 │ 1.5 - Strong Buy     │                    0.97 │
│ 11 │ MDRX     │ 2,093,000,960 │                         0.0 │  18.540598 │ 2.4 - Buy            │                   0.973 │
│ 12 │ BCOR     │   771,079,168 │                         0.0 │      102.0 │ 2.0 - Buy            │                    0.16 │
│ 13 │ PDFS     │   900,812,096 │                         0.0 │        nil │ 2.0 - Buy            │                   -0.58 │
│ 14 │ BJRI     │   601,913,536 │                         0.0 │  658.46155 │ 2.6 - Hold           │                   0.039 │
│ 15 │ SPPI     │   138,726,976 │                         0.0 │        nil │ 2.0 - Buy            │                  -1.024 │
│ 16 │ VREX     │   866,844,032 │                         0.0 │       36.3 │ 1.3 - Strong Buy     │                     0.6 │
│ 17 │ THRM     │ 2,176,421,376 │                         0.0 │  23.544804 │ 2.0 - Buy            │                    2.79 │
│ 18 │ FARO     │   614,313,472 │                         0.0 │        nil │ 2.5 - Buy            │                  -2.547 │
│ 19 │ ANGO     │   724,800,064 │                         0.0 │        nil │ 2.0 - Buy            │                  -1.023 │
┢╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┪
┇ ...                                                                                                                       ┇
┗╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┛
442 rows, 6 columns

Our next and final step is to apply filters and trim down the list to a handful of stocks we like, which we will then spend some time looking into before buying. This step is the most subjective - the filters I will show you are almost certainly not the ones best suited for your needs. So rather than explaining and defending my strategy, I will try to generalise it so you can apply the algorithm easily to your situation.

Let’s say we only want companies with more than a billion-dollar market cap. We also want them to be profitable, so their EPS (earnings per share) need to be a positive number. And finally, let’s focus on companies with at least a 1% yearly dividend yield. Let’s see the code:

let oneData = dataFrame.joined(stocksDataFrame, on: (left: "Symbol", right: "symbol"), kind: .left)
    .filter(on: "marketCap", Int.self, { $0 ?? 0 > 1000000000 })
    .filter(on: "epsTrailingTwelveMonths", Double.self, { $0 ?? 0 > 0 })
    .filter(on: "trailingAnnualDividendYield", Double.self, { $0 ?? 0 > 0.01 })
    .selecting(columnNames: "Symbol", "left.Title", "right.marketCap", "right.trailingAnnualDividendYield", "right.averageAnalystRating")

┏━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ┃ Symbol   ┃ left.Title              ┃ right.marketCap ┃ right.trailingAnnualDividendYield ┃ right.averageAnalystRating ┃
┃     ┃ <String> ┃ <String>                ┃ <Int>           ┃ <Double>                          ┃ <String>                   ┃
┡━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 0   │ ANDE     │ Andersons               │   1,294,674,176 │                          0.018702 │ 2.0 - Buy                  │
│ 3   │ DCOM     │ Dime Community          │   1,203,996,672 │                          0.031424 │ 1.6 - Buy                  │
│ 28  │ TTEC     │ TTEC                    │   3,060,135,936 │                          0.014306 │ 1.9 - Buy                  │
│ 30  │ JJSF     │ J&J Snack Foods         │   2,501,749,248 │                          0.019463 │ 2.2 - Buy                  │
│ 32  │ BANF     │ BancFirst Corp          │   2,684,981,248 │                          0.017108 │ 3.2 - Hold                 │
│ 37  │ PATK     │ Patrick Inds            │   1,560,645,504 │                          0.018709 │ 2.2 - Buy                  │
│ 47  │ SBSI     │ Southside Bank          │   1,231,553,664 │                          0.034331 │ 3.0 - Hold                 │
│ 54  │ IPAR     │ Inter Parfums           │   2,324,677,632 │                          0.013877 │ 2.5 - Buy                  │
│ 59  │ UCBI     │ United Comm. Bank       │   3,161,725,184 │                          0.026792 │ 2.1 - Buy                  │
│ 64  │ FHB      │ First Hawaiian          │   3,147,763,968 │                          0.042328 │ 3.3 - Hold                 │
│ 66  │ SAFT     │ Safety Ins              │   1,230,186,496 │                          0.042669 │ nil                        │
│ 69  │ MRTN     │ Marten Transport        │   1,473,398,016 │                          0.010033 │ 2.2 - Buy                  │
│ 72  │ KLIC     │ Kulicke and Soffa       │   3,059,982,592 │                          0.011819 │ 2.6 - Hold                 │
│ 73  │ EGBN     │ EagleBank               │   1,568,721,792 │                          0.031389 │ 3.0 - Hold                 │
│ 81  │ COLB     │ Columbia Banking System │   2,238,077,184 │                          0.040788 │ 2.7 - Hold                 │
│ 95  │ BANR     │ Banner Corp             │   1,880,339,840 │                          0.030693 │ 2.5 - Buy                  │
│ 98  │ PPBI     │ Pacific Premier Bank    │   2,995,054,080 │                          0.042485 │ 2.6 - Hold                 │
│ 118 │ SHOO     │ Steve Madden            │   3,058,015,488 │                          0.017405 │ 2.1 - Buy                  │
│ 124 │ SCHL     │ Scholastic Cp           │   1,257,351,552 │                          0.016616 │ nil                        │
│ 125 │ FFBC     │ First Financial Bank    │   1,907,738,496 │                          0.045365 │ 3.0 - Hold                 │
┢╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┪
┇ ...                                                                                                                         ┇
┗╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┛
98 rows, 5 columns

We achieved some success, but we have two remaining problems. First, we still have 98 companies to sip through. Second, the dividend yield field is hard to read. We can also make the column titles better. Let’s get the easy tasks out of the way first.

let formatter = NumberFormatter()
formatter.numberStyle = .percent
formatter.maximumFractionDigits = 2

var prettyData = DataFrame(oneData)
prettyData.transformColumn("right.trailingAnnualDividendYield") { (val: Double) -> String in
    let number = NSNumber(value: val)
    let formattedValue = formatter.string(from: number)!
    return "\(formattedValue)"
}
prettyData.renameColumn("left.Title", to: "Company")
prettyData.renameColumn("right.marketCap", to: "Market Cap")
prettyData.renameColumn("right.trailingAnnualDividendYield", to: "Dividend Yield")
prettyData.renameColumn("right.averageAnalystRating", to: "Average Analyst Rating")

┏━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┓
┃    ┃ Symbol   ┃ Company                 ┃ Market Cap    ┃ Dividend Yield ┃ Average Analyst Rating ┃
┃    ┃ <String> ┃ <String>                ┃ <Int>         ┃ <String>       ┃ <String>               ┃
┡━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 0  │ ANDE     │ Andersons               │ 1,294,674,176 │ 1.87%          │ 2.0 - Buy              │
│ 1  │ DCOM     │ Dime Community          │ 1,203,996,672 │ 3.14%          │ 1.6 - Buy              │
│ 2  │ TTEC     │ TTEC                    │ 3,060,135,936 │ 1.43%          │ 1.9 - Buy              │
│ 3  │ JJSF     │ J&J Snack Foods         │ 2,501,749,248 │ 1.95%          │ 2.2 - Buy              │
│ 4  │ BANF     │ BancFirst Corp          │ 2,684,981,248 │ 1.71%          │ 3.2 - Hold             │
│ 5  │ PATK     │ Patrick Inds            │ 1,560,645,504 │ 1.87%          │ 2.2 - Buy              │
│ 6  │ SBSI     │ Southside Bank          │ 1,231,553,664 │ 3.43%          │ 3.0 - Hold             │
│ 7  │ IPAR     │ Inter Parfums           │ 2,324,677,632 │ 1.39%          │ 2.5 - Buy              │
│ 8  │ UCBI     │ United Comm. Bank       │ 3,161,725,184 │ 2.68%          │ 2.1 - Buy              │
│ 9  │ FHB      │ First Hawaiian          │ 3,147,763,968 │ 4.23%          │ 3.3 - Hold             │
│ 10 │ SAFT     │ Safety Ins              │ 1,230,186,496 │ 4.27%          │ nil                    │
│ 11 │ MRTN     │ Marten Transport        │ 1,473,398,016 │ 1%             │ 2.2 - Buy              │
│ 12 │ KLIC     │ Kulicke and Soffa       │ 3,059,982,592 │ 1.18%          │ 2.6 - Hold             │
│ 13 │ EGBN     │ EagleBank               │ 1,568,721,792 │ 3.14%          │ 3.0 - Hold             │
│ 14 │ COLB     │ Columbia Banking System │ 2,238,077,184 │ 4.08%          │ 2.7 - Hold             │
│ 15 │ BANR     │ Banner Corp             │ 1,880,339,840 │ 3.07%          │ 2.5 - Buy              │
│ 16 │ PPBI     │ Pacific Premier Bank    │ 2,995,054,080 │ 4.25%          │ 2.6 - Hold             │
│ 17 │ SHOO     │ Steve Madden            │ 3,058,015,488 │ 1.74%          │ 2.1 - Buy              │
│ 18 │ SCHL     │ Scholastic Cp           │ 1,257,351,552 │ 1.66%          │ nil                    │
│ 19 │ FFBC     │ First Financial Bank    │ 1,907,738,496 │ 4.54%          │ 3.0 - Hold             │
┢╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┷╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┪
┇ ...                                                                                               ┇
┗╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍┛
98 rows, 5 columns

We will try to trim down the list of stocks further by using the analyst rating we get from the API and only consider stocks with a “Strong Buy” rating (1.5 or lower). A simple string comparison will suffice for now because this script is not something we will run very often. If you want to optimise further, you can extract the numeric rating and use it for comparison.

.filter(on: "right.averageAnalystRating", String.self, { $0 ?? "2" <= "1.5" })

And voilà, we have our final list:

┏━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━┓
┃   ┃ Symbol   ┃ Company                      ┃ Market Cap    ┃ Dividend Yield ┃ Average Analyst Rating ┃
┃   ┃ <String> ┃ <String>                     ┃ <Int>         ┃ <String>       ┃ <String>               ┃
┡━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━┩
│ 0 │ CSGS     │ CSG Systems Intl             │ 1,893,075,840 │ 1.72%          │ 1.0 - Strong Buy       │
│ 1 │ GFF      │ Griffon                      │ 1,386,450,304 │ 1.43%          │ 1.4 - Strong Buy       │
│ 2 │ SXI      │ Standex                      │ 1,096,411,520 │ 1.07%          │ 1.2 - Strong Buy       │
│ 3 │ WD       │ Walker & Dunlop              │ 3,421,355,520 │ 2.02%          │ 1.4 - Strong Buy       │
│ 4 │ STC      │ Stewart Information Services │ 1,517,544,832 │ 2.52%          │ 1.2 - Strong Buy       │
└───┴──────────┴──────────────────────────────┴───────────────┴────────────────┴────────────────────────┘
5 rows, 5 columns

In Conclusion

We started with a big spreadsheet, and after some light coding, we have an excellent short list of companies we can further analyse. Using TabularData is easy and fun. Oh, and also, I am not subscribing to the PLUS plan - the additional companies I would be able to buy are not that appealing. Not all is lost, though. I can update the script to filter the non-PLUS companies for a follow-up article.

You can find the source code for the script on GitHub. Feel free to reach me on Twitter if you have any feedback.

And yes, we are hiring! If you want to work with me day-to-day (and who doesn’t?), ping me on Twitter!

Photo by Nathan Dumlao on Unsplash

Drafting away

Sun, 12 Jun 2022 00:00:00 +0000

As I promised last week, let’s see how we can have drafts in our GitHub pages blog instead of posting live and fixing on the fly.

Turns out, once we have Ruby installed, it’s a piece of cake.

Step 1: Install Jekyll:

$ gem install jekyll

Step 2: Go to your website folder and run:

$ bundle install

Step 2.1: If you are using Ruby 3+, you need to add webrick manually:

$ bundle add webrick

Step 3: Run Jekyll with drafts enabled (as per the instructions):

$ bundle exec jekyll serve --drafts

Step 4: Create a draft post in the _drafts folder and make sure the file name doesn’t include the date, e.g. drafting-away.md

Step 5: Go to http://127.0.0.1:4000 and see your draft post in the list.

Once you are ready to go live, move the post over to _posts and don’t forget to add the date to the file name, e.g. 2022-11-11-drafting-away.md.

Much more professional, innit?

P.S. Ideally, I want to be able to send the draft post to a friend to review before publishing. I am not sure that’s possible on GitHub though. Please ping me on Twitter if you know how.

Ruby on (my) M1 Mac

Sat, 11 Jun 2022 00:00:00 +0000

Once again I went deep into a rabbit hole. It started with writing an article about Apple’s TabularData framework (coming soon) and deciding to preview it. I am using Jekyll for this blog and it’s hosted on GitHub Pages. From what I read, in order to preview it, I needed to enable drafts. For that to happen, I needed to run Jekyll locally. This is where the fun started.

Installing Jekyll locally is a piece of cake, they say. You just need Ruby. To manage that, you need a ruby version manager, and they recommend chruby. That’s all good but I use Fish shell and that’s where things get a tad more complicated.

I tried with brew install chruby ruby-install, brew install chruby-fish, ruby-install ruby-3.1.2, echo 'ruby-3.1.2' >> .ruby-version + a bunch more commands from various sources. And, of course, I restarted my Mac a bunch of times just to be sure. It didn’t work. Then I stumbled upon Ruby on Mac. I felt excited at first but then decided I don’t want to spend $49 just to install Ruby. I am not even a ruby developer.

Then I remembered that we have a “How to get your Mac up and running” guide in my team’s wiki. And part of the guide is on how to install Ruby because - doh - we are iOS developers, after all.¹

Anywho, here’s what I did, and what I wanna have written down for, you know, next time.

Uninstall chruby, chruby-fish, delete the .rubies folder, etc. (skip that on fresh install)
brew install gnupg
ln -s /opt/homebrew/bin/gpg /opt/homebrew/bin/gpg2
gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
curl -sSL https://get.rvm.io | bash -s stable
curl -L --create-dirs -o ~/.config/fish/functions/rvm.fish https://raw.github.com/lunks/fish-nuggets/master/functions/rvm.fish
echo "rvm default" >> ~/.config/fish/config.fish
(optional?) rvm osx-ssl-certs update all
rvm install 3.1.2 (obviously, update that)
rvm list
ruby -v

And then install Jekyll (even if you don’t need Jekyll, you might want to install openssl)

brew install openssl
set -gx LDFLAGS "-L/opt/homebrew/opt/openssl@3/lib"
set -gx CPPFLAGS "-I/opt/homebrew/opt/openssl@3/include"
set -gx PKG_CONFIG_PATH "/opt/homebrew/opt/openssl@3/lib/pkgconfig"
gem install jekyll

Voila.

Well, not that fast.

$ jekyll

Could not find proper version of jekyll (4.1.1) in any of the sources

$ bundle install

listen-3.2.1 requires ruby version >= 2.2.7, ~> 2.2, which is incompatible with the current version, ruby 3.1.2p20

It took me embarrassingly long time at this moment to figure out that the issue was my existing Gemfile.lock with an older version of jekyll in it.

$ rm Gemfile.lock

$ bundle install

$ jekyll

Finally!

Stay tuned for the “How to draft an article on Jekyll.”

I blame Cocoapods. ↩

Preparing for Advent of Code

Tue, 30 Nov 2021 21:37:00 +0000

I get an advent calendar every year and I do enjoy opening those tiny chocolates, but that’s nothing compared to revealing the next challenge in Advent of Code - my favourite developer event of the year.

Each year we try to save Christmas by solving programming challenges (apart from last year when we were instead trying to save our vacation). It is a very nicely organised competition happening at https://adventofcode.com/.

Last year I was creating a new Xcode project for each task. With 25 days of challenges that can get tedious. This year I decided to prepare a bit and created a GitHub template repo with basic parsing and regex support (using the framework I created last year after the event).

If you are using Swift check out the template here. Feel free to raise a PR or an issue if you want to contribute.

Happy coding :)

Regular Expressions FTW

Sun, 17 Jan 2021 00:00:00 +0000

When I started doing the Advent of Code 2020 challenges in December I thought I can get away with not using regular expressions. I tried relying on string manipulation alone. I wrote a whole bunch of replacingOccurrences(of: and components(separatedBy:. It was all well and good until I reached Day 4. I managed to figure out how to do most of the parsing without regular expressions but the height bit was tough. The rules were:

hgt (Height) - a number followed by either cm or in:
If cm, the number must be at least 150 and at most 193.
If in, the number must be at least 59 and at most 76.

After some googling, coding and debugging I had the following solution:

func heightValid(_ height: String) -> Bool {
    let pattern = #"(\d{2,3})(cm|in)"#
    let regex = try! NSRegularExpression(pattern: pattern, options: [])
    let nsrange = NSRange(height.startIndex..<height.endIndex, in: height)
    var valid = false
    regex.enumerateMatches(in: height,
                            options: [],
                            range: nsrange) { (match, _, stop) in
        guard let match = match else { return }
        if match.numberOfRanges == 3,
            let firstCaptureRange = Range(match.range(at: 1), in: height),
            let secondCaptureRange = Range(match.range(at: 2), in: height) {
            let number = Int(height[firstCaptureRange])!
            let metric = String(height[secondCaptureRange])
            if metric == "cm" {
                if number >= 150 && number <= 193 { valid = true }
            } else if metric == "in" {
                if number >= 59 && number <= 76 { valid = true }
            }
            stop.pointee = true
        }
    }
    return valid
}

It was working great. The only challenge I had was that it was a bit lengthy. If I was to use this approach for the next challenges I needed it to be more modular.

I decided to create a framework that gives me a generalised version of this method which I would be able to use going forward. I didn’t want to introduce third party dependency managers so I opted for SPM. My goal was to be able to write as little code as possible at the caller side. Here is what I came up with:

let helper = RegexHelper(pattern: #"(\d{2,3})(cm|in)"#)
let results = helper.parse(inputString)

Making the framework open source was a no brainer. You can get it here. Any questions or suggestions? Ping me on Twitter or raise a pull request.

Dimi Chakarov

From Algorithms to Adventures

The “Nerd” Trap (v1.0)

The Reality Check

Finding the Fun

The Move Limit

Building the “Game” Part

The Tech Stack: SwiftUI

Launching

Fitting User Content Without Clipping

The Naive Implementation

Research and Solve

Widget Dimensions

Measuring Text: How Many Lines?

First Results

The Missing Piece

Reflections

Building a Maze Generation Framework

What Makes Maze Algorithms Fascinating

Three Algorithms, Three Personalities

The Ruby to Swift Translation Challenge

Beyond One-to-One Translation

Building a Framework, Not Just Code

Protocol-Oriented Design

Key Design Principles

From Framework to Demo App

The “Aha” Moment

Lessons Learned

Framework Separation Pays Off

Translation Forces Deep Understanding

Visualisation Changes Everything

Start Simple, Iterate Quickly

What’s Next

Visual debugging with Swift Charts

How to create a playful letter animation

Let me filter that for you

In Conclusion

Drafting away

Ruby on (my) M1 Mac

Preparing for Advent of Code

Regular Expressions FTW