DEV Community: Filip Melka

Start Building TUIs with Bubble Tea

Filip Melka — Sat, 08 Aug 2026 14:40:42 +0000

When Claude Code first came out, what caught my eye was its terminal interface — the TUI. Ever since, I've wanted to build my own cool-looking TUIs. Recently, while learning Go, I came across Bubble Tea — a Go framework for making terminal apps. In this article I'll give you a quick "how to get started" guide and walk through the core concepts behind Bubble Tea, along with some tips and tricks I've picked up along the way.

The Elm Architecture (TEA)

Bubble Tea is based on the functional design paradigms of the Elm Architecture. So before diving into making our first terminal app, it's worth introducing ourselves with this pattern.

At the core of The Elm Architecture are three concepts:

Model: holds the state of your app
View: displays the Model's state to the user
Update: listens for messages and updates the Model accordingly

The Elm Architecture loop

Don't worry if this doesn't fully make sense yet — it'll click once we start building. So let's get started.

Building A Counter App TUI

We'll be creating a simple counter app. We want to display the current count in the terminal and be able to increment or decrement it using arrow keys.

Following the Elm Architecture, our program will have its own Model. You can technically use any type, but in practice it's almost always a struct. Let's think about what state our app needs to hold. It's a counter app, so it definitely needs to keep track of the count. Our model will look like this:

type model struct {
    count int
}

Next we have to create three methods on our model, so that we comply with the tea.Model interface:

type Model interface {
    Init() Cmd
    Update(Msg) (Model, Cmd)
    View() View
}

The first method is Init, which runs once when we first start the program. This method can be used for initial I/O using a command (more on those later). For now we can just return nil:

func (m model) Init() tea.Cmd {
    return nil
}

The second method is Update, which handles incoming messages and returns the new model and a command (which for now will be nil as well).

But first, what are these messages?

A message (tea.Msg) is just an empty interface:

type Msg interface{}

This means anything can be a message. Messages represent "something happened" — a keypress, a window resize, data returned from an API call, etc. There are several built-in messages that Bubble Tea itself sends — the two you'll run into most often are:

tea.KeyPressMsg: a key was pressed
tea.WindowSizeMsg: the terminal was resized

For our app, we want to listen for the KeyPressMsg. If the user presses the up key or k, we'll increment our counter by one (and similarly with the down key or j we'll decrement it). We also want the user to be able to quit the program by pressing ctrl+c or q (otherwise you'd have to close the entire terminal). Here's the code for the Update() method to handle this:

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {

    case tea.KeyPressMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case "up", "k":
            m.count++
        case "down", "j":
            m.count--
        }
    }

    return m, nil
}

We use switch statements to determine the type of the message (which, as mentioned, can be any type). If the message is of type tea.KeyPressMsg, calling the String() method on it returns the value of the key that's been pressed ("up" for the up arrow, "down" for the down arrow, or individual letter keys).

Notice what happens when we press ctrl+c (or q): we return the model (m) and tea.Quit — a built-in command that tells Bubble Tea to shut down the program's event loop. For incrementing and decrementing, we simply update the model's state and return it (with nil as the command because we don't need to perform any side effect yet).

The last method we need to implement is View. This method is responsible for rendering content based on the model's state so it can be displayed to the user. In Bubble Tea v1, the View method returned a string that would be printed out to the terminal, but in the current v2, this method returns a tea.View struct. You don't need to know much about the struct - most of the time you'll simply use the tea.NewView(str) function and pass in the string you want to display.

For our app, this method will look like this:

func (m model) View() tea.View {
    return tea.NewView(fmt.Sprintf("count: %d\n\n↑/k up • ↓/j down • q quit\n", m.count))
}

The most important thing to remember is that View() should never mutate state or trigger side effects - all state changes happen in Update().

And that's it - now we'll just add the main() function to start our program:

func main() {
    p := tea.NewProgram(model{})
    if _, err := p.Run(); err != nil {
        os.Exit(1)
    }
}

For reference, here's the full code up to now:

package main

import (
    "fmt"
    "os"

    tea "charm.land/bubbletea/v2"
)

type model struct {
    count int
}

func (m model) Init() tea.Cmd {
    return nil
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {

    case tea.KeyPressMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case "up", "k":
            m.count++
        case "down", "j":
            m.count--
        }
    }

    return m, nil
}

func (m model) View() tea.View {
    return tea.NewView(fmt.Sprintf("count: %d\n\n↑/k up • ↓/j down • q quit\n", m.count))
}

func main() {
    p := tea.NewProgram(model{})
    if _, err := p.Run(); err != nil {
        os.Exit(1)
    }
}

Commands

A command (tea.Cmd) is how Bubble Tea does anything that takes time or touches the outside world (network calls, reading files, starting timers, etc.) without blocking your UI.

A command is just a function that does some work and returns a Msg when it's done. Bubble Tea runs it in the background using its own goroutine, and once it finishes, feeds the resulting message back to Update().

Just so there isn't any confusion between messages and commands, here is a brief comparison between these two concepts:

	Message (`tea.Msg`)	Command (`tea.Cmd`)
What it is	Data describing something that happened	A function that performs an effect and returns a message
Type signature	`interface{}` (`any` type)	`func() tea.Msg`
Purpose	Represents an event	Triggers a side effect (I/O, timers, network...)
Where it's consumed	`Update(msg tea.Msg, ...)`	Executed by the Bubble Tea runtime (not by you directly)

Let's use commands to automate our counter — let's say we want to allow the user to toggle auto-increment, which increments the counter every second.

First, let's update our model so it keeps track of whether auto-increment is enabled, using a simple bool variable:

type model struct {
    count   int
    ticking bool // added
}

Before writing our own command, we need to declare our own message type. Let's call it tickMsg — an empty struct, since we don't need any data. We only need Update() to receive tickMsg whenever it's supposed to increment the counter.

type tickMsg struct{}

Now we'll write our own command, doTick(). Since tea.Cmd is just func() tea.Msg, doTick itself can have exactly that shape - a function that does the waiting and hands back a tickMsg when it's done. We'll use time.Sleep() to cause the one-second delay. Remember that the command runs inside a goroutine, so it won't block our app.

func doTick() tea.Msg {
    time.Sleep(time.Second)
    return tickMsg{}
}

Let's update our Update() method. First, we need to listen for when the user presses the spacebar - this is how the user toggles auto-increment. When spacebar is pressed, we do two things:

toggle the m.ticking state
if m.ticking is now true, return our model m and our doTick command

case tea.KeyPressMsg:
    switch msg.String() {
    case "ctrl+c", "q":
        return m, tea.Quit
    case "up", "k":
        m.count++
    case "down", "j":
        m.count--
    case "space":
        m.ticking = !m.ticking
        if m.ticking {
            return m, doTick
        }
    }

Notice one thing: we're not actually invoking doTick() when we return it. Instead, we're just handing Bubble Tea a reference to the function itself. Bubble Tea's runtime then calls it for you, in its own goroutine, and whenever it finishes, feeds the resulting tea.Msg back into Update().

But what if the command needs a parameter? For example, what if we didn't want to hardcode a delay of 1 second, but instead pass the delay time as an argument to the command? The solution is to wrap the command inside another function that takes your argument and returns the command:

func doTick(d time.Duration) tea.Cmd {
    return func() tea.Msg {
        time.Sleep(d)
        return tickMsg{}
    }
}

Then inside Update() we would call it like this:

case tickMsg:
    if !m.ticking {
        return m, nil
    }
    m.count++
    return m, doTick(time.Second)

Note the shift: doTick went from being a tea.Cmd itself to being a command factory — a plain function that returns a closure, which captures d (our passed delay argument) and only runs when the runtime actually invokes it. Because it's now a factory, you have to call it (doTick(time.Second)) rather than pass it bare.

A side note: the same behavior could be accomplished using the built-in tea.Tick() function, which adds a couple of niceties (it uses a proper timer instead of a blocking time.Sleep(), and it can be cleaned up if the program quits mid-wait).

func doTick() tea.Cmd {
    return tea.Tick(time.Second, func(t time.Time) tea.Msg {
        return tickMsg{}
    })
}

Just keep in mind that this version is a factory too (it returns a tea.Cmd, not a tea.Msg directly), so you'd call it as doTick() rather than pass it bare, the same way we called doTick(time.Second) above. Aside from that, it doesn't really matter which version you use.

Ok, back to our app. Right now we're only listening for tea.KeyPressMsg, but our doTick command returns a tickMsg — so let's add a switch case for that type too. We check whether m.ticking is still on (the user could've toggled auto-increment off during the one second before the command returns a message) and, if so, increment the counter and return our model plus the doTick command so the auto-increment keeps going.

Here is the full Update() code:

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {

    case tea.KeyPressMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case "up", "k":
            m.count++
        case "down", "j":
            m.count--
        case "space":
            m.ticking = !m.ticking
            if m.ticking {
                return m, doTick
            }
        }

    case tickMsg:
        if !m.ticking {
            // Toggled off while a tick was already in flight; drop it.
            return m, nil
        }
        m.count++
        return m, doTick // re-issue the next tick to keep it recurring
    }

    return m, nil
}

Notice that if we didn't return the doTick command, whenever the user toggles auto-increment on, the counter would only increment once and then stopped.

Finally, let's make a small change to our View() method:

func (m model) View() tea.View {
    state := "paused"
    if m.ticking {
        state = "ticking"
    }
    return tea.NewView(fmt.Sprintf(
        "count: %d [%s]\n\n↑/k up • ↓/j down • space toggle auto-tick • q quit\n",
        m.count, state,
    ))
}

And we're ready to run it.

Alt Screen

Right now, when we run our app, the rendered text is just appended to the terminal, with whatever we ran before still visible above it. Also, when you quit the app, the last thing that was printed stays on screen.

To make our app feel a bit more "professional", we can use an alt screen (alternate screen buffer). This gives our program a separate, full-screen terminal canvas to draw on without disturbing whatever was there before. With alt screen enabled, opening the app clears the terminal to a blank full-screen view, and closing it restores the previous shell content exactly as it was.

To enable alt screen, we simply set the AltScreen field on our tea.View to true:

func (m model) View() tea.View {
    state := "paused"
    if m.ticking {
        state = "ticking"
    }
    v := tea.NewView(fmt.Sprintf(
        "count: %d [%s]\n\n↑/k up • ↓/j down • space toggle auto-tick • q quit\n",
        m.count, state,
    ))

    v.AltScreen = true // enable alt screen

    return v
}

It's a one-line change, but it really elevates your app.

Logging

Being able to log things and state is crucial for debugging. There's one problem, though: because our program is occupying the terminal, we can't log to stdout.

Fortunately, we can still log to a file — in our case, a debug.log file. To enable this, we'll route all logs to this file in our main() function, using charmbracelet/log — a drop-in replacement for the standard library logger that adds leveled methods like Info and Error:

func main() {
    f, err := os.OpenFile("debug.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
    if err != nil {
        fmt.Fprintln(os.Stderr, "could not open debug.log:", err)
        os.Exit(1)
    }
    defer f.Close()
    log.SetOutput(f)

    p := tea.NewProgram(model{})
    if _, err := p.Run(); err != nil {
        log.Error("program exited with error", "err", err)
        os.Exit(1)
    }
}

To see how this works, let's log every time the user presses the space bar:

case "space":
    m.ticking = !m.ticking
    log.Info("ticking toggled", "ticking", m.ticking) // logged to debug.log file
    if m.ticking {
        return m, doTick
    }

If you open debug.log in the root folder, you'll see something like this:

2026/07/02 14:29:16 INFO ticking toggled ticking=true
2026/07/02 14:29:23 INFO ticking toggled ticking=false
2026/07/02 14:29:25 INFO ticking toggled ticking=true

To watch the log in real time, run tail -f debug.log from another terminal window.

Full Code

Here is the full code of our little counter TUI:

package main

import (
    "fmt"
    "os"
    "time"

    tea "charm.land/bubbletea/v2"
    "github.com/charmbracelet/log"
)

type tickMsg struct{}

type model struct {
    count   int
    ticking bool
}

func doTick() tea.Msg {
    time.Sleep(time.Second)
    return tickMsg{}
}

func (m model) Init() tea.Cmd {
    return nil
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {

    case tea.KeyPressMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case "up", "k":
            m.count++
        case "down", "j":
            m.count--
        case "space":
            m.ticking = !m.ticking
            log.Info("ticking toggled", "ticking", m.ticking) // logged to debug.log file
            if m.ticking {
                return m, doTick
            }
        }

    case tickMsg:
        if !m.ticking {
            return m, nil
        }
        m.count++
        return m, doTick
    }

    return m, nil
}

func (m model) View() tea.View {
    state := "paused"
    if m.ticking {
        state = "ticking"
    }
    v := tea.NewView(fmt.Sprintf(
        "count: %d [%s]\n\n↑/k up • ↓/j down • space toggle auto-tick • q quit\n",
        m.count, state,
    ))

    v.AltScreen = true // enable alt screen

    return v
}

func main() {
    f, err := os.OpenFile("debug.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
    if err != nil {
        fmt.Fprintln(os.Stderr, "could not open debug.log:", err)
        os.Exit(1)
    }
    defer f.Close()
    log.SetOutput(f)

    p := tea.NewProgram(model{})
    if _, err := p.Run(); err != nil {
        log.Error("program exited with error", "err", err)
        os.Exit(1)
    }
}

Next Steps

Now you have all the ingredients to start making awesome-looking TUIs. But as they say:

Don't reinvent the wheel.

So here are two popular libraries from the Bubble Tea ecosystem that make building TUIs much easier.

Lip Gloss

If you wanted to add colors to your TUI on your own, you'd have to hardcode ANSI escape codes into your output strings which is very tedious. Fortunately, there's a companion styling library for TUIs called Lip Gloss — think of it as "CSS for the terminal." Besides colors, it also handles things like:

borders
padding
margins
alignment
layout

It does all this through a declarative, chainable API. You build a Style and apply it to a string:

import "charm.land/lipgloss/v2"

style := lipgloss.NewStyle().
    Bold(true).
    Foreground(lipgloss.Color("#d52a2a")).
    Background(lipgloss.Color("#0ed7ff")).
    Padding(1, 2).
    Border(lipgloss.RoundedBorder())

fmt.Println(style.Render("Hello, World!"))

Bubbles

Another library you'll find handy is Bubbles — a collection of pre-built, reusable UI components for Bubble Tea. Here are some examples of what's included:

textinput: a single-line text field with cursor, placeholder text, and validation
list: a scrollable, filterable list with built-in pagination
viewport: a scrollable content pane
spinner: animated loading indicators
progress: progress bars

Each Bubbles component is itself a Bubble Tea model — you embed it in your own model, forward relevant messages to it, and render its output as part of your View.

Here is a quick example of our TUI, slightly enhanced using these two libraries — treat it as a preview to skim rather than something to trace line-by-line, it leans on a few APIs (like lipgloss.Place/Join* for layout and tea.WindowSizeMsg for sizing) we haven't walked through:

package main

import (
    "fmt"
    "os"
    "time"

    "charm.land/bubbles/v2/progress"
    tea "charm.land/bubbletea/v2"
    "charm.land/lipgloss/v2"
    "github.com/charmbracelet/log"
)

const (
    tickDelay     = time.Second
    frameInterval = 50 * time.Millisecond
    barWidth      = 36
)

var (
    containerStyle = lipgloss.NewStyle().
            Border(lipgloss.RoundedBorder()).
            BorderForeground(lipgloss.Color("99")). // purple
            Padding(1, 3)

    titleStyle = lipgloss.NewStyle().
            Bold(true).
            Foreground(lipgloss.Color("230")).
            Background(lipgloss.Color("99")).
            Padding(0, 1)

    countStyle = lipgloss.NewStyle().Bold(true).Foreground(lipgloss.Color("42")) // green

    autoBadgeStyle = lipgloss.NewStyle().
            Bold(true).
            Foreground(lipgloss.Color("0")).
            Background(lipgloss.Color("42")).
            Padding(0, 1)

    pausedBadgeStyle = lipgloss.NewStyle().
                Bold(true).
                Foreground(lipgloss.Color("230")).
                Background(lipgloss.Color("240")).
                Padding(0, 1)

    labelStyle = lipgloss.NewStyle().Foreground(lipgloss.Color("245"))
    helpStyle  = lipgloss.NewStyle().Foreground(lipgloss.Color("240"))
)

type model struct {
    count   int
    ticking bool
    lastTick time.Time
    elapsed  time.Duration
    width, height int
    progressBar progress.Model
}

func initialModel() model {
    return model{
        progressBar: progress.New(
            progress.WithDefaultBlend(),
            progress.WithWidth(barWidth),
            progress.WithoutPercentage(),
        ),
    }
}

func (m model) Init() tea.Cmd {
    log.Info("program started")
    return nil
}

type frameMsg time.Time

func doFrame() tea.Cmd {
    return tea.Tick(frameInterval, func(t time.Time) tea.Msg {
        return frameMsg(t)
    })
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {

    case tea.WindowSizeMsg:
        m.width = msg.Width
        m.height = msg.Height

    case tea.KeyPressMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            log.Info("quitting")
            return m, tea.Quit
        case "up", "k":
            m.count++
            log.Info("incremented", "count", m.count)
        case "down", "j":
            m.count--
            log.Info("decremented", "count", m.count)
        case "space":
            m.ticking = !m.ticking
            log.Info("ticking toggled", "ticking", m.ticking)
            if m.ticking {
                m.lastTick = time.Now()
                m.elapsed = 0
                return m, doFrame()
            }
        }

    case frameMsg:
        if !m.ticking {
            return m, nil
        }
        m.elapsed = time.Time(msg).Sub(m.lastTick)
        if m.elapsed >= tickDelay {
            m.count++
            m.lastTick = time.Time(msg)
            m.elapsed = 0
            log.Info("tick", "count", m.count)
        }
        return m, doFrame()
    }

    return m, nil
}

func (m model) View() tea.View {
    badge := pausedBadgeStyle.Render("PAUSED")
    barLabel := labelStyle.Render("space starts auto-increment")
    percent := 0.0
    if m.ticking {
        badge = autoBadgeStyle.Render("AUTO")
        percent = min(float64(m.elapsed)/float64(tickDelay), 1)
        remaining := max(tickDelay-m.elapsed, 0)
        barLabel = labelStyle.Render(fmt.Sprintf("next +1 in %.1fs", remaining.Seconds()))
    }

    body := lipgloss.JoinVertical(lipgloss.Center,
        titleStyle.Render("✦ COUNTER"),
        "",
        lipgloss.JoinHorizontal(lipgloss.Center,
            countStyle.Render(fmt.Sprintf("count: %d", m.count)),
            "  ",
            badge,
        ),
        "",
        m.progressBar.ViewAs(percent),
        barLabel,
        "",
        helpStyle.Render("↑/k up • ↓/j down • space toggle auto-tick • q quit"),
    )

    v := tea.NewView(lipgloss.Place(
        m.width, m.height,
        lipgloss.Center, lipgloss.Center,
        containerStyle.Render(body),
    ))

    v.AltScreen = true

    return v
}

func main() {
    f, err := os.OpenFile("debug.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
    if err != nil {
        fmt.Fprintln(os.Stderr, "could not open debug.log:", err)
        os.Exit(1)
    }
    defer f.Close()
    log.SetOutput(f)

    p := tea.NewProgram(initialModel())
    if _, err := p.Run(); err != nil {
        log.Error("program exited with error", "err", err)
        os.Exit(1)
    }
}

Bubblon

Finally, I'd like to mention one third-party library called Bubblon that I've used extensively. As your app grows, you might want to start thinking about parts of your app as different independent models. Bubblon makes it easy to manage these independent nested models. There's a really good article by Roman Parykin explaining how to manage nested models in Bubble Tea, which is definitely worth reading.

One thing I've encountered though — it seems that Bubblon is currently only supporting Bubble Tea v1 (which has some type differences with v2). Fortunately, Bubblon is a single file, so what I ended up doing is creating my own bubblon package inside my project, copying the controller.go file into it, and manually updating it to make it compatible with Bubble Tea v2 (the View() method returns tea.View instead of a string, plus a couple more small changes, but nothing too difficult). A coding agent handles the port without much trouble.

Conclusion

In this article, we built a simple counter app TUI, which walked us through the main building blocks of Bubble Tea, a Go framework for building modern TUIs. We started with The Elm Architecture, the pattern Bubble Tea is built on. Then we handled user input and updated our model accordingly, which was rendered to the terminal for the user to see. From there we got familiar with commands, which let us run long-lasting tasks without blocking the app, made our app full-screen with the alt screen, and set up file logging for debugging. Finally, we looked at Lip Gloss and Bubbles - two libraries that take your TUI from "it works" to "it looks great".

Is 1 Larger Than 0.999...?

Filip Melka — Sat, 08 Aug 2026 13:36:20 +0000

Let's go back in time to primary school, to those exercises with comparison symbols, where you had to compare two numbers and fill in the right sign:

3 ? 5 8 ? 8 2 ? 1

Just to be sure, the correct answers are: "<", "=", ">".

Now that you've had a nice trip down memory lane, here's one more for you:

0.999 \dots ? 1

And the answer is... "=". That might seem a bit unintuitive. We're saying that $0.999 \dots$ (repeating forever) and $1$ aren't two different numbers sitting close to each other - they're the exact same number.

The Proof

If you don't believe what you've just read, I don't blame you. So let's prove it.

The algebra trick

Let's define:

x = 0.999 \dots

If we multiply both sides by 10, we get:

10 x = 9.999 \dots

Now we'll subtract $x$ from the left side and $0.999 \dots$ from the right side - we can do this without any trouble, since by our definition they're the same thing:

10 x - x = 9.999 \dots - 0.999 \dots

9 x = 9

Divide both sides by 9, and we get:

x = 1

So by our definition of $x$ , it must be true that:

0.999 \dots = 1

There it is: a concrete proof that $0.999 \dots$ and $1$ are the same number.

But you might still not be fully convinced, so let's try another way to prove it.

The fraction trick

We know that one third is:

\frac{1}{3} = 0.333 \dots

Multiply both sides by 3:

\frac{3}{3} = 3 \cdot 0.333 \dots

And we get:

1 = 0.999 \dots

We can even add any real number to both sides - say, 4:

5 = 4.999 \dots

Which reveals something rather fun about decimal notation: every terminating decimal has a "twin" written as an infinite string of 9s. $2 = 1.999 \dots$ , $0.7 = 0.6999 \dots$ , and so on, forever.

The "name the gap" argument

If $0.999 \dots$ were less than 1, there'd have to be some positive gap between them - some tiny number you could add to $0.999 \dots$ to reach 1.

So if you think one number is larger, try naming that gap. Pick something tiny, like 0.000000001. Unfortunately, $0.999 \dots$ already beats it - it's already closer to 1 than that. Pick something even tinier, and the same thing happens, every time. No matter how small a number you name, $0.999 \dots$ has already closed the distance. There's no room left for a gap, which means there's no gap at all - they're the same number.

Geometric Series And Lazy Zeno

Another way to write $0.999 \dots$ is:

0.999 \dots = \frac{9}{10} + \frac{9}{100} + \frac{9}{1000} + \dots

We're adding up infinitely many terms, where each one is $\frac{1}{10}$ of the one before it. This is called a geometric series, and it has a well-known formula. We won't derive it here, but we'll happily use it: if you start with a term $a$ and each following term is the previous one multiplied by a ratio $r$ (with $r$ between $- 1$ and $1$ ), the whole infinite sum works out to:

S = \frac{a}{1 - r}

Plugging in our numbers ( $a = \frac{9}{10}$ , $r = \frac{1}{10}$ ):

S = \frac{\frac{9}{10}}{1 - \frac{1}{10}} = \frac{\frac{9}{10}}{\frac{9}{10}} = 1

So $0.999 \dots$ , viewed as a sum stretching out to infinity, still lands exactly on 1. Which brings us to Zeno.

Zeno of Elea

Zeno of Elea was (supposedly) an ancient Greek philosopher who lived around the 5th century BCE in Elea, a Greek colony in southern Italy.

One morning Zeno woke up parched. His nightstand, holding a cup of water with half a tablespoon of lime juice already stirred in, sat a single meter away from him. Being a philosopher, he couldn't just reach for it - he had to wonder whether reaching it was even possible. To get to the table, he reasoned, he'd first have to cover half the distance, leaving half remaining. Then half of that half, leaving a quarter. Then half of that, leaving an eighth. And so on, forever - no matter how much distance he'd already closed, there was always the same fraction of it still waiting to be closed.

Four successive steps toward the cup, each one halving the distance that remains: 1/2 m, then 1/4 m, then 1/8 m, then 1/16 m.

This is Zeno's paradox (and for the record, I have no evidence he actually drank lime water in the mornings - but it's hard to be certain of anything with these ancient philosophers).

Let's show Zeno where he went wrong. Unlike Zeno, we know this is a geometric series with $a = \frac{1}{2}$ and $r = \frac{1}{2}$ , and we also know how to sum it:

S = \frac{\frac{1}{2}}{1 - \frac{1}{2}} = \frac{\frac{1}{2}}{\frac{1}{2}} = 1

The sum equals 1, so Zeno would in fact reach his table in a finite amount of time and could've had his drink. So where did his reasoning break down? It's not a silly argument, but it conflates two separate things:

Infinite steps vs. infinite distance
Infinite steps vs. infinite time

The first mistake is assuming that summing infinitely many pieces of distance must add up to an infinite total distance - which, as the geometric series shows, simply isn't true (in this case it sums to 1).

The second is assuming that infinitely many steps must take infinitely long. But if Zeno is walking at a constant speed, each step takes proportionally less time than the last - step two takes half as long as step one, step three a quarter as long, and so on. Time is a geometric series too, and it converges to a finite total just like the distance does. So Zeno completes infinitely many steps in a perfectly ordinary, finite stretch of time - and his lime water was never in any real danger.

Conclusion

In this short piece, we showed that $0.999 \dots$ and $1$ are the exact same number - first with an algebraic trick, then with a fraction trick, then with a "name the gap" argument. Along the way we picked up the geometric series formula, which let us settle Zeno's paradox.

How I Set Up a Custom Domain for My Blog

Filip Melka — Sat, 08 Aug 2026 11:50:07 +0000

I'm building my own blog with Astro, hosted as static pages on GitHub Pages. At some point "filip-melka.github.io/blog" stops feeling like a real address, so I went and got my own domain. Here's the whole process, start to finish.

How Does A Domain Work?

Before buying anything, it's worth knowing what you're actually buying. Let's take a domain apart:

https://www.example.com

https: protocol
www: subdomain
example.com: domain name, made up of:
- example: the name
- com: the Top-Level Domain

TLD (Top-Level Domain)

The TLD is the suffix at the end of a domain name - .com, .org, .net, .io, .de etc. TLDs sit at the top of the domain naming hierarchy and fall into a few buckets:

gTLDs (generic): .com, .org, .net, .app, .dev
ccTLDs (country code): .uk, .de, .jp
sTLDs (sponsored, restricted to specific communities): .gov, .edu, .mil

Fun fact: ICANN (Internet Corporation for Assigned Names and Numbers) reserves every two-letter TLD exclusively for country codes, which is why gTLDs are always three or more characters. The twist is that some countries have leased out their ccTLD for reasons that have nothing to do with the country, simply because the letters happen to spell something useful:

.ai - Anguilla, now shorthand for every AI startup on earth
.me - Montenegro, popular for personal branding
.tv - Tuvalu, a favorite for streaming/video sites
.io - British Indian Ocean Territory, adopted wholesale by tech and startups

So who actually keeps track of all these TLDs?

Registries

A registry is the organization that owns and operates a particular TLD. Here are some examples of these organizations:

Verisign runs the registry for .com and .net
Public Interest Registry runs .org.

The registry holds the authoritative master database for its TLD (who owns what, which name servers each domain points to, when it expires) and runs that TLD's core DNS servers (more on those shortly). Registries generally don't sell to the public directly; you buy through a registrar instead.

A registrar is the company you actually buy a domain from (GoDaddy, Namecheap, Cloudflare, etc.), accredited by ICANN and by each registry to sell and manage domain names. When you register example.com, your registrar submits that registration to the .com registry, which adds it to the master database. Once that's done, you become the registrant - the person or organization that owns the domain.

You buy a domain from a registrar, which registers it with the registry that owns the TLD.

But when someone types your domain into a browser, how does the browser know where to send the request? That's DNS's job.

DNS (Domain Name System)

DNS is the internet's phone book - it translates human-readable names (example.com) into IP addresses (93.184.216.34) that computers actually route traffic to. It's organized as a hierarchy:

Root servers
- The top of the hierarchy
- Don't know where example.com lives, but know which servers handle .com
TLD servers
- Know which name servers are authoritative for example.com specifically
Authoritative name servers
- Usually run by your hosting provider or DNS provider (like Cloudflare)
- Hold the actual records (A, MX, CNAME, and so on - more on those below)

When you type a URL, your device asks a recursive DNS resolver (often run by your ISP or a public provider like Cloudflare or Google) to look up the name. That resolver walks this chain - root, then TLD, then authoritative - caching the answer along the way so it doesn't repeat the whole walk next time.

One more term worth knowing before we move on: WHOIS privacy.

WHOIS privacy

WHOIS is a public lookup protocol that shows a domain's registration details:

Registrant name
Address
Email
Phone number
Registrar
Key dates

Historically this was fully public, meaning anyone could look up a domain owner's home address and phone number just by knowing their domain name.

WHOIS privacy (also called domain privacy or a privacy proxy) lets the registrar swap in its own proxy contact info for the public WHOIS record instead of yours, forwarding any legitimate email through to you. Most registrars now throw this in for free. Worth knowing too: GDPR (via ICANN's Temporary Specification) pushed most registrars to redact personal WHOIS data by default for individual registrants.

Put together

You pick a name under a TLD, buy it through a registrar, which registers it with that TLD's registry, and the whole thing becomes reachable because DNS propagates the routing info - with WHOIS privacy optionally shielding your personal details from the public record.

Buying A Domain

Plenty of services sell custom domains, and most bundle a domain with hosting. Since I'm hosting on GitHub Pages, all I actually needed was the domain itself plus solid DNS control. A few options worth knowing about:

Porkbun: one of the cheapest full-service registrars, with consistent renewal pricing
Cloudflare Registrar: sells at wholesale cost with no markup - you pay whatever Cloudflare pays the registry, at registration and at renewal
Namecheap: a popular all-rounder, though the cheap first-year price is usually followed by a renewal bump

One place I'd personally steer clear of is GoDaddy. I've used it before (bought two domains through them), and beyond the usual steep renewal jump after a cheap first year, they made a change in February 2026 that's worth knowing about: a Terms of Service update reclassified customers as "Business Customers" by default, stripping away consumer protections and pushing disputes into arbitration.

What domain to buy

Since this is a personal blog, I wanted my own name as the domain. It came down to two options:

filipmelka.com
filip-melka.com

I went with filipmelka.com. A few reasons:

One less keystroke - every extra character is one more chance to typo it
Hyphens are the first thing people forget when typing a domain from memory
It's easier to say out loud
It just looks cleaner

For the TLD, I went with .com - it's the one people assume by default, it's the most universal, and it's usually the cheapest and most stable option long-term. There are other reasonable picks:

.dev: popular in software circles
.me: reads nicely for a personal site

One TLD I'd think twice about right now is .io. It's had a great run in tech and startup circles, but its future is genuinely uncertain: in May 2025, the UK and Mauritius signed a treaty transferring sovereignty over the Chagos Archipelago (the actual land behind the British Indian Ocean Territory designation that .io is based on). If BIOT eventually disappears from the ISO country-code standard, .io could face a phased retirement over the following years. As of early 2026 the treaty's ratification has stalled after the US withdrew its consent, so nothing is imminent - but it's not a TLD I'd want to build something long-term on today.

I ended up going with Porkbun and bought filipmelka.com for $11.08 for the first year, with the same price at renewal. Domain acquired - now to make it actually do something.

Set DNS Records

Next up: DNS records. Why? Because my domain name and the actual location of my website are two completely separate pieces of information, and nothing connects them automatically.

When you register a domain, the registry just notes "this name belongs to this registrant, and its authoritative name servers are X." That's it. It has no idea what should happen when someone types that domain into a browser. DNS records are the missing instruction set. They live on your authoritative name servers (Porkbun's, in my case) and answer specific questions:

"What IP address serves the website?" (needs an A record)
"What server handles email for this domain?" (needs an MX record)
"Prove you actually control this domain" (needs yet another record)

Here are the main record types you'll run into:

Record	Purpose
`A`	Points a domain/subdomain to an IPv4 address
`AAAA`	Same as `A`, but for IPv6 addresses
`CNAME`	Alias - points a subdomain to another domain name instead of an IP
`MX`	Points a domain to the mail servers that handle its email
`TXT`	Arbitrary text (used for domain verification)

Porkbun has a one-click helper for this exact GitHub Pages setup. First, open the DNS config and delete all existing records ("Delete All Records" at the very bottom) - otherwise the old and new records will conflict. In the "Quick DNS Config" section, click "GitHub."

You'll be asked for your GitHub username. Enter it, hit submit, and wait a few seconds. This sets your A, AAAA, and CNAME records automatically. You'll notice several A (and AAAA) records rather than just one - here's why that's not a mistake.

Multiple A records for the same host is a standard DNS technique called round-robin DNS. Those aren't four different websites - they're four different edge servers in GitHub's front-end fleet, all serving GitHub Pages content. Publishing all four buys you two things:

Redundancy - if one of GitHub's front-end servers goes down or is under maintenance, your domain still resolves fine via the other three (a single A record would be a single point of failure)
Load distribution - when a resolver gets back multiple A records for the same name, it typically rotates which one it hands out first, spreading traffic across GitHub's servers instead of hammering just one

Add The Custom Domain In GitHub

Next, tell GitHub about the domain: repo → Settings → Pages → Custom domain, type it in, hit save. This does two things:

Stores the custom domain in your Pages configuration
Kicks off domain verification

DNS propagation can take anywhere from a few minutes to 24 hours. GitHub shows a green checkmark on the Pages settings page once it sees valid records. Once it's green, check "Enforce HTTPS" - GitHub auto-provisions a free Let's Encrypt certificate for you.

Update `astro.config.mjs`

The last piece was updating Astro's config: set site to my domain, and drop base (which you only need when deploying to username.github.io/repo-name).

export default defineConfig({
  site: 'https://yourdomain.com',
  base: '/', // or omit
})

Once DNS has propagated, HTTPS is enforced, and the site rebuilds, I confirmed everything worked by visiting https://filipmelka.com (my canonical URL, set in Pages settings) and https://www.filipmelka.com (which GitHub automatically redirects to the canonical one).

I keep saying "canonical URL" - worth explaining what that actually means. It's the address you officially designate as the "real" one: the version you want indexed, linked to, and shown in search results, with everything else redirecting or pointing back to it. When you set Astro's site property, Astro generates a <link rel="canonical" href="..."> tag in your page <head>, telling search engines "however someone arrived at this content, treat this URL as the definitive one." This matters for SEO - without it, if the same content is reachable through multiple URLs (with or without www, with or without a trailing slash, http vs https), search engines can split ranking signals across all of them instead of consolidating on one.

The short version:

When duplicates or variants exist, canonical marks which one is the "real" one that everything else defers to.

And with that, I'm happy to say my blog is officially live on its own domain.

Before wrapping up though, a few loose ends worth tying off.

Next Steps

Add a sitemap

A sitemap is an XML file listing every URL on your site, so search engines don't have to discover your pages purely by following links around - it's you handing Google a table of contents instead of making it wander your site page by page. It doesn't guarantee indexing or ranking (Google still decides what's worth indexing), but it removes "Google never found this page" as a possible failure mode.

Adding one to an Astro project is really simple - just install Astro's official sitemap integration:

npx astro add sitemap

It requires your site field to already be set, which I'd already done. On the next astro build, it auto-generates sitemap-index.xml and sitemap-0.xml in dist/, listing every page it finds - no manual maintenance as I add articles.

Add a `robots.txt`

robots.txt is a plain text file at your site's root (mine lives at https://filipmelka.com/robots.txt) that tells web crawlers which parts of your site they're allowed to crawl. It's the first thing well-behaved bots check before touching anything else on your domain.

To add it, drop a robots.txt file in public/ so it gets copied to your site root:

User-agent: *
Disallow: /admin/
Disallow: /drafts/
Allow: /

Sitemap: https://filipmelka.com/sitemap-index.xml

User-agent: * means "this applies to all bots"
Disallow: ... blocks specific paths
Allow: / explicitly permits everything else
Sitemap: is a common convention pointing crawlers straight to your sitemap

It's a request, not a lock. Well-behaved crawlers (Google, Bing) respect it; malicious scrapers can and do ignore it entirely.

Add an RSS feed

An RSS feed is an XML file listing your recent posts in a structured, machine-readable format - title, link, publish date, description. It's how people subscribe to a blog without needing an account or an email newsletter.

Instead of a human checking your site, an RSS reader (I use Feedly, though there are plenty of others) periodically polls your feed URL and pulls in anything new, surfacing it alongside every other blog the subscriber follows.

Adding it in Astro is just as easy - just follow the official guide.

Verify my domain in Google Search Console

Google Search Console exposes fairly sensitive data - search traffic, which queries bring people to your site, security issues, even the ability to request a URL be pulled from search results. Google isn't going to hand that over to just anyone who types in a domain. Verification (via a DNS TXT record) is how you prove you actually control the domain, rather than someone merely claiming to.

To verify, go to Search Console → Add Property → Domain (not "URL prefix" - the domain property covers www, non-www, and both http/https variants in one shot). Google gives you a TXT record to add, then you click "Verify" - it usually resolves in minutes, occasionally longer.

Once verified, you get visibility into things that were previously invisible:

Indexing status: which pages Google has actually indexed vs. crawled-but-skipped vs. never seen, and why a given page isn't indexed
Search performance data: which queries bring people to your site, your click-through rate, average position
Core Web Vitals / mobile usability reports: page-speed and mobile-friendliness scores that factor into ranking
Direct submission tools: submitting your sitemap, or requesting a re-crawl of a specific page right after you fix something instead of waiting for it to happen naturally

This is my first time using Search Console, so I'm still finding my way around it - I'll write about that experience once I've got more to say. For now, the short version:

Indexing happens whether you verify or not. Verification is what lets you see what's happening and fix it when something's wrong, instead of only finding out when your traffic mysteriously drops.

Conclusion

In this article I walked through setting up my own custom domain, start to finish. We started with the theory - what a domain is actually made of, and who's responsible for each piece - then I covered why I picked filipmelka.com and Porkbun as my registrar. From there, we set the DNS records and added the custom domain in GitHub, so that when someone types my domain into a browser, they land on the content hosted on GitHub Pages.

I Created a Claude Skill for Usage-Aware Automation

Filip Melka — Sat, 08 Aug 2026 11:21:06 +0000

I built and published my first Claude skill: Claude Gauge.

Quick side note: it's only been tested on macOS so far — if you try it on something else, I'd love to hear how it goes.

The skill lets Claude see your current usage and reset times for both the session and weekly limits, in Claude Code and Claude Desktop.

That, in turn, makes it possible to automate around your subscription limits. But first, here's why I needed this in the first place.

The Problem

I'm on Claude's Pro plan, which has two separate usage limits:

A session limit
A weekly limit

The session limit resets every five hours, but whatever you don't use doesn't roll over — in other words, if you don't use it, you lose it. Same story with the weekly limit.

My goal was simple: get the most out of my subscription by putting unused tokens to work before they expire. Specifically, I wanted Claude to pick up lower-priority tasks near the end of a session window, instead of letting that capacity go to waste.

Basically, I wanted to be able to tell Claude something like:

Check my usage every hour. If the session usage is below 40% or resets in less than 30 minutes, start working on the items from the backlog.

Simple enough — except for one catch.

Why not ask Claude directly?

Claude Code has no built-in access to your usage numbers. Seeing them means typing /usage yourself; Claude can't invoke that command on its own.

So to automate around usage, I needed a way to give Claude access to it — which is how Claude Gauge was born.

How Claude Gauge Works

Claude Gauge gives Claude Code visibility into both your session and weekly usage, plus their reset times. But if Claude can't run /usage itself, and headless mode (claude -p) doesn't support UI-only slash commands, how does it actually get that data?

The skill spawns a real interactive claude process inside a pseudo-terminal (via node-pty), types /usage into it just like a person would, and waits for the output to settle. From there, it feeds the raw PTY byte stream into a headless terminal emulator (@xterm/headless) rather than parsing the bytes directly — the TUI (terminal UI) repaints panels in place using cursor-positioning escape codes, so simply concatenating the raw output would produce garbled, overlapping text. Reading the emulator's final rendered screen buffer instead gives one clean frame, exactly what you'd see if you'd typed the command yourself. From there, it's just regex over that screen text to pull the "Current session" and "Current week (all models)" blocks — percent used and reset time — convert the reset time into an absolute timestamp and a countdown in milliseconds, and print the result as JSON.

{
  "currentSession": {
    "used": 0.14,
    "resetsAt": "2026-07-19T16:00:00.000Z",
    "resetsIn": 7089559
  },
  "currentWeek": {
    "used": 0.35,
    "resetsAt": "2026-07-19T17:00:00.000Z",
    "resetsIn": 10689559
  }
}

One downside: since this is essentially screen-scraping the official TUI, it's a bit brittle across Claude Code version changes. There's also a --raw flag that dumps the unparsed panel, handy for debugging if the parsing ever breaks.

Usage

To get started, follow the instructions in the README.

After cloning the repo, if you want the skill available across all your projects, run the install script:

./install

This does two things:

Copies the skill into ~/.claude/skills/ (replacing any older version already there)
Installs the npm dependencies

Then open Claude Code and ask:

What's my current usage?

A few seconds later, you should see something like this:

On its own, having Claude tell you your usage isn't all that useful — you could just type /usage and get the same answer, faster. The real value is in automating around it.

Using with `/loop`

Combine Claude Gauge with the built-in /loop skill, and you can build your own automations that put unused tokens to work instead of letting them vanish.

To burn through leftover weekly usage, for example:

Every Sunday at 8AM check my usage. If my weekly limit is below 80%, start working on the items in the project backlog.

Or lean on the reset times instead:

Check my usage every hour. If my session limit is below 50% or resets in less than 30 minutes...

Or even use it to skip an iteration of a recurring task when the usage is high:

Perform … every hour. If the current session usage is above 75%, skip the iteration.

Using with `/goal`

As mentioned in this article, /goal lets you manage usage with an explicit stopping condition — something like "stop after 5 tries." With Claude Gauge, you can swap that for:

...stop when the session usage reaches 10%.

The Final Problem

I'm happy with how this works on my laptop, but there's still one catch: my laptop has to stay open. Right now there are three ways to schedule recurring or one-off work:

/loop — requires an open session and the machine on
Desktop scheduled tasks — requires the machine on
Claude Routines — runs on Anthropic-managed cloud infrastructure

/loop needs the terminal session to stay open, and Claude Desktop needs the laptop to stay on. Routines are the exception: they run Claude prompts on Anthropic's own infrastructure, so they keep going even when your laptop is off.

So, in theory, running Claude Gauge inside a routine would be the ideal setup. Unfortunately, the skill needs an authenticated Claude Code session to work, and routines start from a fresh environment every time — so this doesn't work yet.

That's as far as I've gotten. If I find a way around it, I'll write about it — and if you already know a better approach, let me know.

Conclusion

That's the story of Claude Gauge: why I built it, how it works under the hood, and a few ways I've been using it. I'm sure there are plenty of other use cases for usage-aware automation I haven't thought of — if you come up with one, I'd like to hear about it.

DEV Community: Filip Melka

Start Building TUIs with Bubble Tea

The Elm Architecture (TEA)

Building A Counter App TUI

Commands

Alt Screen

Logging

Full Code

Next Steps

Lip Gloss

Bubbles

Bubblon

Conclusion

Is 1 Larger Than 0.999...?

The Proof

The algebra trick

The fraction trick

The "name the gap" argument

Geometric Series And Lazy Zeno

Zeno of Elea

Conclusion

How I Set Up a Custom Domain for My Blog

How Does A Domain Work?

TLD (Top-Level Domain)

Registries

DNS (Domain Name System)

WHOIS privacy

Put together

Buying A Domain

What domain to buy

Set DNS Records

Add The Custom Domain In GitHub

Update astro.config.mjs

Next Steps

Add a sitemap

Add a robots.txt

Add an RSS feed

Verify my domain in Google Search Console

Conclusion

I Created a Claude Skill for Usage-Aware Automation

The Problem

Why not ask Claude directly?

How Claude Gauge Works

Usage

Using with /loop

Using with /goal

The Final Problem

Conclusion

Update `astro.config.mjs`

Add a `robots.txt`

Using with `/loop`

Using with `/goal`