Dimi Chakarov

A Refined Authentication Experience | Dan Lages

Mon, 30 Mar 2026 12:27:39 +0000

A Refined Authentication Experience | Dan Lages In a large-scale consumer application, it is vital that the authentication experience is both secure and intuitive. The Just Eat Takeaway applicati... danlages.com

I got inspired by my friend Costa’s write-up and decided to try it on my own blo

Sun, 29 Mar 2026 19:36:12 +0000

I got inspired by my friend Costa’s write-up and decided to try it on my own blog. A more detailed article coming soon… for now, enjoy the result

Things Or how I made a telegram bot update my website costafotiadis.com

AI is making CEOs delusional

Sun, 29 Mar 2026 19:06:52 +0000

Universal Links are hard. Good that we have Alberto to help us out!

Sun, 29 Mar 2026 18:31:28 +0000

Universal Links are hard. Good that we have Alberto to help us out!

Universal Links At Scale: The Challenges Nobody Talks About A deep dive into the practical challenges of implementing, testing, and maintaining Universal Links at scale albertodebortoli.com

How I Built a Telegram Bot to Post Notes to My Jekyll Blog

Sat, 28 Mar 2026 08:00:00 +0000

I‘ve been wanting to add a “micro-blog” to my site for a while – a place for quick thoughts, links I’ve found interesting, or a video worth sharing. Not a full article, just a line or two with a link. The kind of thing you’d share in a group chat.

Posting on my site isn’t that hard right now. I duplicate the last post (as an MD file), rename it, open it in Panda, and start writing. Once I’m done, I open Fork and push my changes to GitHub. A few seconds later, the article is live.

That’s all good when I have my laptop with me. If I only have my phone, I would have to do all that in the GitHub web interface or develop a complicated workflow in order to use an app on the phone. Another problem is styling. The current blog theme works for long technical articles. To a lesser extent, it also works for a short story or a review. It doesn’t work for link posts or for hot takes.

Then my friend Costa wrote about how he built something similar using a Telegram bot, and I decided to build my own version. His setup uses Railway to host the bot and appends entries to a single page. Mine is slightly different: each note becomes its own Jekyll post, and the bot runs locally on my Mac. That way, I avoid having to sign up for a new service.

The Architecture

The setup is simple:

I send a message to my Telegram bot (from my phone, desktop, wherever)
A Python script running on my Mac picks it up
The script creates a Jekyll post file via the GitHub Contents API
GitHub Pages rebuilds the site automatically

No servers, no containers, no CI pipelines. The bot talks directly to GitHub’s REST API to create files in my _posts/ directory, and GitHub Pages does the rest.

The Bot

The bot is about 150 lines of Python code, built on two frameworks: a Python wrapper for the Telegram API called python-telegram-bot and httpx. It handles three types of messages (for now):

Just a link - fetches the page’s Open Graph metadata (title, description, image) and creates a note with a link preview card
A link + my thoughts - As above, but use my notes as the post body
Plain text - saved as a quick thought, no link involved

Creating Posts via the GitHub API

The clever bit (borrowed from Costa’s approach) is that the bot never touches a local git repo. It uses the GitHub Contents API to create files directly:

async def gh_create_file(client, path, content, message):
    url = f"https://api.github.com/repos/{GITHUB_REPO}/contents/{path}"
    payload = {
        "message": message,
        "content": base64.b64encode(content.encode("utf-8")).decode("utf-8"),
    }
    r = await client.put(url, headers=GH_HEADERS, json=payload, timeout=15)
    r.raise_for_status()

A single PUT request creates the file and commits it. GitHub Pages picks up the new commit and rebuilds the site within a couple of minutes.

Fetching Link Previews

When you share a link in Telegram, WhatsApp, or Slack, you get a nice preview card with the page’s title, description, and image. I wanted the same thing on my blog.

The bot fetches Open Graph metadata from the URL:

async def fetch_og_metadata(client, url):
    r = await client.get(url, timeout=10, follow_redirects=True,
        headers={"User-Agent": "Mozilla/5.0 ..."})
    page = r.text
    return {
        "title": _get_meta(page, ["og:title", "twitter:title"]),
        "description": _get_meta(page, ["og:description", "twitter:description"]),
        "image": _get_meta(page, ["og:image", "twitter:image"]),
    }

It then generates an HTML preview card that gets embedded in the post. One gotcha: sites behind Cloudflare (like Medium) return a “Just a moment…” challenge page instead of real content. The bot detects these bad titles and falls back to extracting a human-readable title from the URL path.

Security

Since the bot publishes directly to my site, I needed some restrictions. Posts are only allowed from my Telegram user ID. And all the keys to connect to GitHub and Telegram are stored on my Mac.

ALLOWED_USER_ID = int(os.environ["ALLOWED_USER_ID"])

async def handle_message(update, context):
    if update.effective_user.id != ALLOWED_USER_ID:
        await update.message.reply_text("Not authorised.")
        return
    # ... create the post

The Jekyll Side

I needed a few tweaks on my blog templates to make this work.

A Separate Layout for Notes

Regular blog posts use my post.html layout, which shows a featured image, read time estimate, and prev/next navigation. That’s too heavy for a one-liner. I created a minimal note.html layout:

---
layout: default
---

<div class="post note">
  <p class="meta">{{ page.date | date: '%B %d, %Y' }} &middot; Note</p>

  {{ content }}
</div>

No title heading (the body is the content), no read time, no post navigation. Just the date and the text.

A Notes Tab

I added a notes.md page that lists only posts in the notes category, and added it to my site navigation. The filter is a simple Liquid condition:

{% for post in site.posts %}
  {% if post.categories contains 'notes' %}
    <!-- show the note -->
  {% endif %}
{% endfor %}

Notes also appear on the homepage alongside regular posts. The homepage template detects notes and shows them differently – just the date and content text, without the usual title-as-link treatment.

Link Preview Cards

The preview cards are styled with CSS to look like the link previews you see in messaging apps – a border, rounded corners, the page’s image on top, and the title/description/domain below. The key CSS:

.link-preview {
  display: block;
  border: 1px solid darken(white, 15%);
  border-radius: 8px;
  overflow: hidden;
  margin: 1.5rem 0;

  img {
    width: 100%;
    max-height: 300px;
    object-fit: cover;
    display: block;
  }
}

One thing to watch out for: Jekyll uses kramdown for Markdown processing, and kramdown can mangle raw HTML if you’re not careful. The fix is to wrap the HTML card in kramdown’s {::nomarkdown}...{:/nomarkdown} tags, which tells it to pass the HTML through untouched.

Running It Locally

Costa uses Railway to host his bot. I didn’t want to sign up for another service, so I run mine locally on my Mac using launchd.

A .plist file tells launchd to start the bot on login and restart it if it crashes:

<dict>
    <key>Label</key>
    <string>com.dchakarov.notebot</string>
    <key>ProgramArguments</key>
    <array>
        <string>/path/to/my-bot/.venv/bin/python</string>
        <string>/path/to/my-bot/bot.py</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
</dict>

Install it with:

cp com.dchakarov.notebot.plist ~/Library/LaunchAgents/
launchctl load ~/Library/LaunchAgents/com.dchakarov.notebot.plist

The bot runs as long as my Mac is on. Since Telegram uses polling, it works regardless of whether I send the message from my phone, tablet, or desktop. Messages sent while the Mac is off simply queue up in Telegram and get processed the next time the bot starts. And yes, my Mac is a laptop, so my thoughts don’t go live immediately. So what?

Setting It Up Yourself

If you want to build your own, here’s what you need:

Prerequisites

A Jekyll blog on GitHub Pages
Python 3.9+
A Telegram account

Steps

0. Think of a good name for your bot. Don’t be lame.

1. Create a Telegram bot. Message @BotFather on Telegram, send /newbot, and follow the prompts. Copy the bot token.

2. Get your Telegram user ID. Message @userinfobot on Telegram. It replies with your numeric ID.

3. Create a GitHub personal access token. Go to GitHub Settings > Developer settings > Fine-grained tokens. Create a token scoped to your blog repository with “Contents: Read and write” permission.

4. Set up the bot.

mkdir cool-bot && cd cool-bot
python3 -m venv .venv
.venv/bin/pip install python-telegram-bot httpx python-dotenv

5. Create a .env file with your credentials:

TELEGRAM_BOT_TOKEN=your-token-here
GITHUB_TOKEN=your-github-pat
GITHUB_REPO=yourusername/yourusername.github.io
ALLOWED_USER_ID=your-telegram-id
SITE_URL=https://yoursite.com

6. Add the bot script - you can find the full source code here: Telegram notes bot. Feel free to contribute!

7. Test it. Run .venv/bin/python bot.py, send a test message to your bot, and check your GitHub repo for the new file. Since one of the features of this setup is that posts get published immediately, be ready to delete your test posts from GitHub.

8. Set up launchd to run it automatically once you’re happy (see the section above).

What I Learned

I didn’t learn Python, that’s for sure. With Costa’s article and code on one side and Claude on the other, implementing this setup was a fun journey. Testing something that publishes live is challenging, so I had to pull locally and delete the test posts rather quickly on each iteration. There are still a few wrinkles to fix, and a few that will never get fixed, but overall, I am quite pleased with the result. Expect more frequent, shorter posts in the near future.

Check out the Notes section to see it in action.

Hero image by David Travis on Unsplash

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.

Dimi Chakarov

A Refined Authentication Experience | Dan Lages

I got inspired by my friend Costa’s write-up and decided to try it on my own blo

AI is making CEOs delusional

Universal Links are hard. Good that we have Alberto to help us out!

How I Built a Telegram Bot to Post Notes to My Jekyll Blog

The Architecture

The Bot

Creating Posts via the GitHub API

Fetching Link Previews

Security

The Jekyll Side

A Separate Layout for Notes

A Notes Tab

Link Preview Cards

Running It Locally

Setting It Up Yourself

Prerequisites

Steps

What I Learned

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