DEV Community: lef237

Use gst to safely get an overview of all git states

lef237 — Thu, 04 Jun 2026 11:56:32 +0000

Checking changed files with git status, looking at history with git log, checking diffs with git diff...

When you repeatedly jump back and forth between these commands while working, you sometimes start thinking, “It would be nice if I could see all the information I want right now in one place.”

So I created gst, a CLI tool that lets you check the state of a Git repository at a glance.

lef237/gst: Read-only Git status visualizer

Why I built it

I was teaching Git to an acquaintance who had just started programming, and they said things like:

I don’t really understand git status

It’s hard to remember so many different commands

I’ve heard of tools like lazygit, but I’m scared I might accidentally change the repository state

That made me think: why not build a tool that solves those problems?

That was the starting point for this project.

What You Can See

When you launch gst, you can view your current branch, differences from remote repositories, modified files, staged changes, working directory diffs, stashes, and the commit graph—all from your terminal.

Demo video

A picture is worth a thousand words, so we have also prepared a video demonstration.

Watching it will give you a better sense of how gst works in practice and why it can be useful.

Installation

There are two ways to install it.

If you use Go, run:

go install github.com/lef237/gst/cmd/gst@latest

It also supports Homebrew. You can install it with:

brew install lef237/tap/gst

Usage

Normally, run the following command inside a repository:

gst

If you want to display the information once and then exit, use --once:

gst --once

In the TUI, you can move between views using the Tab key and arrow keys.

Press r to reload, and q to quit.

Read-Only

gst is a tool for checking the state of a repository.

It does not perform operations that modify the repository state, such as push, pull, checkout, commit, merge, or rebase.

Even if you are not very familiar with Git, there is less risk of accidentally changing something, so I think it is easy to use as a tool for checking repository status.

Diff display

In Git, staged changes and unstaged changes in the working tree are managed separately.

In gst, changed files are displayed with markers such as INDEX, WORKTREE, NEW, and CONFLICT.

This makes it easier to understand which files are staged and which files still only have changes in the working tree.

In the diff view, you can switch between the working tree diff and the staged diff.

This is useful when you want to check what will be included in the next commit, or when you want to organize your changes before splitting them into separate commits.

Copying diffs

In the diff view, you can copy the current diff directly to the clipboard.

Press y to copy working directory diffs, and i to copy staged diffs.

Pressing a copies a patch that includes all changes from HEAD to the current working directory.

The copied content is in patch format, so it can be applied with git apply.

I think this is very useful!

Summary

gst is not a tool intended to replace Git operations.

Rather, it is a tool for checking “what state is this repository in right now?” before you perform an operation.

Please give it a try :)

lef237 / gst

Read-only Git status visualizer

gst

gst is a read-only Git status visualizer for people who want to understand the shape of a repository before they run Git commands.

Demo: https://youtu.be/EMO3DaNkqT0

Motivation

Git beginners often struggle because the current state is split across several places:

commits and branches form a graph
local branches and remote tracking branches can point at different commits
the index and working tree can each contain different file changes

gst puts those pieces into one terminal dashboard. It does not push, pull checkout, commit, merge, rebase, or mutate the repository.

Install

go install github.com/lef237/gst/cmd/gst@latest

Or with Homebrew:

brew install lef237/tap/gst

For local development:

go run ./cmd/gst

To build a local binary:

go build -o tmp/gst ./cmd/gst

Release steps are documented in docs/release.md.

Usage

gst
gst --interval 1s
gst --once
gst --no-color

By default, gst opens the interactive TUI.

Interactive controls:

Move between views with tab, the left/right arrow keys…

View on GitHub

clauhist: browse full Claude Code history and resume sessions across projects

lef237 — Sat, 28 Mar 2026 04:43:38 +0000

Claude Code can already help you resume work from a project if you move into that working directory and use /resume there.

The limitation is that this is tied to the current working directory. If you want to look back across all of your past work, including sessions from other repositories and directories, that gets awkward.

clauhist is a small CLI tool for that case. It shows your Claude Code history in fzf, lets you browse sessions across working directories, and resume one from the list.

What it shows

Sessions are sorted by recent activity. Each row includes:

the last activity time
the project path
whether the path still exists
a preview of the first message
the message count

There is also a preview pane with the session ID, timestamps, and message list. Once you find the one you want, press Enter.

How it works

clauhist reads ~/.claude/history.jsonl, groups entries by session, and passes the result to fzf.

After you select a session, it runs:

claude --resume <session-id>

It does not keep its own database or add another history layer. It is just a thin local browser over Claude Code's existing history file.

Installation

cargo install clauhist

Or install from source:

git clone https://github.com/lef237/clauhist.git
cd clauhist
cargo install --path .

You also need fzf and Claude Code installed.

Usage

clauhist

Main controls:

Enter: resume the selected session
type: filter the list
Ctrl-/: toggle preview
Ctrl-C: exit

It is displayed on the terminal like this:

╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Claude Code History Browser  [Enter: resume  Ctrl-/: toggle preview  Ctrl-C: cancel]  │
├───────────────────────────────────────────────────────────────────────────────────────┤
│ Search:                                                                               │
│ > 2026-03-18 09:12  ✓ ~/projects/myapp      Tell me about Rust error handling…  (12)  │
│   2026-03-17 22:45  ✓ ~/sandbox/api-client  Generate client from OpenAPI schema  (8)  │
│   2026-03-17 14:30  ✗ ~/old-project         Database migration steps             (3)  │
╰───────────────────────────────────────────────────────────────────────────────────────╯

✓ means the project directory still exists. ✗ means it was moved or deleted. You can still resume the session, but cd into the original directory may fail.

Shell integration

If you add this to your shell config:

eval "$(clauhist init zsh)"

then clauhist will now change to the project directory within your current shell before launching Claude Code.

This allows you to immediately return to your original directory with cd -.

Without this, clauhist uses a subshell for the directory change, so exit to return to your original shell.

Local-only

clauhist only reads ~/.claude/history.jsonl and launches claude --resume. It does not send your history anywhere.

That is the whole tool: a simple way to browse past Claude Code sessions across projects and reopen one without moving directory by directory.

GitHub

You can find the repository here :)

lef237 / clauhist

Browse Claude Code history across working directories and resume sessions

clauhist

Browse Claude Code history across working directories and resume sessions.

╭───────────────────────────────────────────────────────────────────────────────────────╮
│ Claude Code History Browser  [Enter: resume  Ctrl-/: toggle preview  Ctrl-C: cancel]  │
├───────────────────────────────────────────────────────────────────────────────────────┤
│ Search:                                                                               │
│ > 2026-03-18 09:12  ✓ ~/projects/myapp      Tell me about Rust error handling…  (12)  │
│   2026-03-17 22:45  ✓ ~/sandbox/api-client  Generate client from OpenAPI schema  (8)  │
│   2026-03-17 14:30  ✗ ~/old-project         Database migration steps             (3)  │
╰───────────────────────────────────────────────────────────────────────────────────────╯

(Example output — actual appearance depends on your terminal and fzf version)

Claude Code can already resume work from the current project directory. clauhist solves a different problem: browsing the full history across all of your working directories from one place.

Select a session and press Enter — clauhist opens claude --resume in the project directory. When you exit Claude, you return to your original shell.

Why clauhist exists

If you cd into a project and use Claude Code's /resume there, you can inspect…

View on GitHub

https://github.com/lef237/clauhist

One-Time Editor, an editor for drafts before sending

lef237 — Mon, 09 Mar 2026 13:16:35 +0000

I've created an app called "One-Time Editor".

The image above shows dark mode. Here's what it looks like in light mode.

What kind of app is it, you ask? It's a text editor that can be used for drafting messages before sending them in a chat.

By using this app, you can avoid the worry of accidentally sending a message prematurely by hitting Enter.

To quickly understand how it works, I recommend watching the video, which I've attached below.

https://youtu.be/qwj9fr77vQg

How to Install

For macOS, use Homebrew. You can start using it right away by typing the following commands in your terminal.

brew tap lef237/tap
brew install --cask one-time-editor

Since it's an Electron-based app, it's also cross-platform compatible.

Windows and Linux users can install the pre-built app from here.

https://github.com/lef237/one-time-editor/releases

Windows users should select the .exe file, and Linux users should select the AppImage to install it. ¹

Features

The main highlight is that you can toggle (show/hide) the window using a keyboard shortcut.

What's more, it automatically copies the content you've entered as soon as you toggle it, allowing for instant pasting.

Open One-Time Editor with a keyboard shortcut.
Type the content you want to send.
Close it with the keyboard shortcut.
- The content will be automatically copied.
- On macOS, focus will automatically return to the window you were previously using.
Paste and then send.

It also supports switching between light and dark modes. I think the design is also stylish.

Of course, you can also customize the keyboard shortcut! The default is Ctrl+J, but feel free to assign any shortcut you like.

Why I Made It

Many people have probably experienced indecision about whether to use Enter, Shift+Enter, or Ctrl+Enter to send a chat message.

And then, accidentally sending a message in the middle of writing...

Using some kind of editor for drafting isn't bad, but it can be a bit cumbersome to constantly be asked to create a new file or to manage windows.

This app is designed for throwaway writing, and it allows for displaying/hiding the window and copying content with a single shortcut, making it quite fast.

Challenges During Development

There were several challenges.

However, the most difficult problem was dealing with code signing and notarization.

When you create an app with Electron, it works fine on your local machine, but if you upload it to the internet and download it, the app becomes corrupted.

You might have seen this warning when downloading things like Docker:

Therefore, you need to use the xattr command.

Fix macOS app is damaged and can't be opened" Error - Complete Guide - osxhub

osxhub.com

This means you need to run the command xattr -rc "/Applications/hoge.app" after installation, which is a bit troublesome.

When I looked into simplifying this, I realized that using postflight could automate this process if installed via homebrew-tap.

https://github.com/lef237/homebrew-tap/blob/main/Casks/one-time-editor.rb

If you're looking to distribute Electron apps, please use this as a reference!

GitHub

GitHub is also public.

If you have any feature requests, please open an Issue. 🐘

lef237 / one-time-editor

A lightweight scratchpad that lives one shortcut away

One-Time Editor

A lightweight scratchpad that lives one shortcut away. Draft a message, hit the shortcut again, and it's already on your clipboard — ready to paste anywhere.

Built for the workflow of writing chat messages, AI prompts, and quick notes that you type once and send.

https://youtu.be/qwj9fr77vQg

Install

macOS (Homebrew)

brew tap lef237/tap
brew install --cask one-time-editor

Manual download

Pre-built binaries for macOS, Windows, and Linux are available on the Releases page.

If you download manually on macOS, the app is not signed with an Apple Developer certificate, so macOS may show a warning. To allow it, run:

xattr -cr "/Applications/One-Time Editor.app"

How it works

Press Ctrl+J to summon the editor
Type your text
Press the shortcut again — the window disappears and your text is copied to clipboard
Paste wherever you need it

That's it. No save dialog, no file management, no friction.

The shortcut is…

View on GitHub

https://github.com/lef237/one-time-editor

If it doesn't work on Windows or other OSs, please comment on GitHub! ↩

Writing a Domain Model in Ruby Without Using class

lef237 — Wed, 13 Aug 2025 10:47:28 +0000

Introduction

From Ruby 3.2, the Data class has been introduced, allowing us to explore ways of representing domain models without using class. In this article, I’ll examine how we can do that.

When writing business logic in Ruby, we naturally tend to use class.

We set attributes in initialize, and change state via instance methods. Especially if you’ve been writing Rails code, this feels natural.

However, whether managing logic with a stateful class is suitable for every case is debatable. For domain logic where we want to avoid side effects, class-based design might not always be optimal. In recent years, designs influenced by functional programming have gained attention, and as has been discussed on X (formerly Twitter), the mainstream approach in TypeScript is moving toward avoiding classes entirely.

With the Data class introduced in Ruby 3.2, we can represent domains while keeping structural data and logic separate. In this article, I’ll show you how.

Note: This article focuses on representing domain logic, separate from Rails' ActiveRecord models.

I’m specifically looking at a style that works purely with plain Ruby syntax, without being tied to the Rails environment. This is driven more by curiosity than by real-world constraints, so please keep that in mind.

What Is the `Data` Class?

The Data class introduced in Ruby 3.2 lets you define immutable data structures easily. It’s similar to the Struct that Ruby already had, but all fields are immutable — to change a value, you must create a new instance.

class Data - Documentation for Ruby

To use a loose analogy: Struct is like a hash, while Data is like a read-only hash.

Let’s actually design a domain model using the Data class.

Example Domain Model

First, let’s think of an example.

We’ll imagine a Customer model with the following attributes:

id
email
first_name / last_name
is_active
created_at / updated_at

We want to be able to perform operations such as:

Changing the name
Changing the email address
Activating/deactivating the customer
Getting the full name

Especially the first three operations would naturally become methods that change state.

A Class-Based Implementation

First, let’s design it in the usual class-based way. You might find there are too many instance variables, among other nitpicks, but let’s just write it out as a sample.

class Customer
  attr_reader :id, :email, :first_name, :last_name, :is_active, :created_at, :updated_at

  def initialize(id:, email:, first_name:, last_name:, is_active: true)
    validate_name!(first_name, last_name)
    validate_email!(email)
    @id = id
    @email = email
    @first_name = first_name
    @last_name = last_name
    @is_active = is_active
    @created_at = Time.now
    @updated_at = Time.now
  end

  def change_name(first_name, last_name)
    validate_name!(first_name, last_name)
    @first_name = first_name
    @last_name = last_name
    touch
  end

  def change_email(email)
    validate_email!(email)
    @email = email
    touch
  end

  def deactivate
    return unless @is_active
    @is_active = false
    touch
  end

  def activate
    return if is_active
    @is_active = true
    touch
  end

  def full_name
    "#{first_name} #{last_name}"
  end

  private

  def touch
    @updated_at = Time.now
  end

  def validate_name!(first_name, last_name)
    if first_name.strip.empty? || last_name.strip.empty?
      raise ArgumentError, "Invalid name"
    end
  end

  def validate_email!(email)
    unless email.match?(/\A[^@\s]+@[^@\s]+\z/)
      raise ArgumentError, "Invalid email format"
    end
  end
end

This can be used as follows:

customer = Customer.new(
  id: "c1",
  email: "alice@example.com",
  first_name: "Alice",
  last_name: "Anderson"
)

customer.change_name("Bob", "Brown")
customer.deactivate
puts customer.full_name # => "Bob Brown"

Here, we create an instance with new and call methods to change its state — a very common approach.

The `Data` Class Available from Ruby 3.2

In Ruby 3.2, the Data class was introduced.

It feels similar to Struct, but all fields are immutable.

Customer = Data.define(
  :id, :email, :first_name, :last_name,
  :is_active, :created_at, :updated_at
)

To change a value, you use .with to create a new instance.

Suppose customer1 has first_name set to Bob:

customer1 = Customer.new(
  id: "c1",
  email: "bob@example.com",
  first_name: "Bob",
  last_name: "Johnson",
  is_active: true,
  created_at: Time.now,
  updated_at: Time.now
)

To change first_name to Carol:

customer2 = customer1.with(first_name: "Carol")

customer1 remains unchanged; customer2 is a new object with only first_name different.

puts customer1.first_name  # => "Bob"
puts customer2.first_name  # => "Carol"

With Data.with, we handle state not by mutation but by replacement, avoiding unintended side effects.

Writing Domain Logic with `Data` and Functions

Let’s rewrite the earlier class-based code using Data.

We’ll define a CustomerService module, separate from Customer, to hold our domain operations as functions.

Customer = Data.define(
  :id, :email, :first_name, :last_name,
  :is_active, :created_at, :updated_at
)

module CustomerService
  module_function

  def create_customer(id:, email:, first_name:, last_name:)
    validate_name!(first_name, last_name)
    validate_email!(email)

    now = Time.now
    Customer.new(
      id,
      email.strip,
      first_name.strip,
      last_name.strip,
      true,
      now,
      now
    )
  end

  def change_name(customer, first_name:, last_name:)
    validate_name!(first_name, last_name)
    customer.with(
      first_name: first_name.strip,
      last_name: last_name.strip,
      updated_at: Time.now
    )
  end

  def change_email(customer, email:)
    validate_email!(email)
    customer.with(email: email.strip, updated_at: Time.now)
  end

  def deactivate(customer)
    return customer unless customer.is_active
    customer.with(is_active: false, updated_at: Time.now)
  end

  def activate(customer)
    return customer if customer.is_active
    customer.with(is_active: true, updated_at: Time.now)
  end

  def full_name(customer)
    "#{customer.first_name} #{customer.last_name}"
  end

  def validate_name!(first_name, last_name)
    if first_name.strip.empty? || last_name.strip.empty?
      raise ArgumentError, "Invalid name"
    end
  end

  def validate_email!(email)
    unless email.match?(/\A[^@\s]+@[^@\s]+\z/)
      raise ArgumentError, "Invalid email format"
    end
  end
end

Here, create_customer is used as a factory in CustomerService. By defining domain operations as functions, we can handle changes to state in a way that minimizes side effects.

Each function doesn’t change the Customer data structure directly — it uses .with to create a new instance. This preserves data immutability and brings the design closer to a functional style.

Also, by using module_function, we can call these functions without creating an instance of the module. Validation is performed inside the functions where needed.

This cleanly separates data (Customer) from behavior (functions).

Example Usage

customer = CustomerService.create_customer(
  id: "c1",
  email: "alice@example.com",
  first_name: "Alice",
  last_name: "Anderson"
)

customer = CustomerService.change_name(customer, first_name: "Bob", last_name: "Brown")
customer = CustomerService.deactivate(customer)

puts CustomerService.full_name(customer) # => "Bob Brown"

Note that when reassigning, we return a new object instead of modifying the original. I considered naming them customer_updated, customer_updated2, etc., but left it as-is for now.

By not using instance variables and passing all state through arguments, we avoid side effects. At that point, all that’s left is to store the final state in the database or handle it however needed.

For example, saving with SQLite might look like this:

db.execute(
  "INSERT OR REPLACE INTO customers (id, email, first_name, last_name, is_active, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?)",
  customer.id,
  customer.email,
  customer.first_name,
  customer.last_name,
  customer.is_active ? 1 : 0,
  customer.created_at.iso8601,
  customer.updated_at.iso8601
)

You can access attributes with customer.xxx, so it feels similar to using a class.

Points to Note

Of course, there’s nothing wrong with using class. For UI logic, controllers, database models like ActiveRecord, and so on, class-based design often makes sense.

In Rails projects, it’s common to extract structured data handling into POROs (Plain Old Ruby Objects) written as classes.

Plain Old Ruby Objects (POROs) in Rails Fat Models - DEV Community

However, as domain logic grows more complex, tracking “state changes” through the code becomes harder. In such cases, a design where “values are immutable and logic is functional” — like the one shown here — can make maintenance easier.

Summary

Ruby is a flexible language, and you can represent domain logic without relying on classes or instance variables.

Ruby 3.2’s Data class can be a useful tool for designing the domain layer as structured data plus explicit functions. You don’t have to use it for every case, but simply knowing it’s an option can broaden your design possibilities.

DEV Community: lef237

Use gst to safely get an overview of all git states

Why I built it

What You Can See

Demo video

Installation

Usage

Read-Only

Diff display

Copying diffs

Summary

lef237 / gst

Read-only Git status visualizer

gst

Motivation

Install

Usage

clauhist: browse full Claude Code history and resume sessions across projects

What it shows

How it works

Installation

Usage

Shell integration

Local-only

GitHub

lef237 / clauhist

Browse Claude Code history across working directories and resume sessions

clauhist

Why clauhist exists

One-Time Editor, an editor for drafts before sending

How to Install

Features

Why I Made It

Challenges During Development

Fix macOS app is damaged and can't be opened" Error - Complete Guide - osxhub

GitHub

lef237 / one-time-editor

A lightweight scratchpad that lives one shortcut away

One-Time Editor

Install

macOS (Homebrew)

Manual download

How it works

Writing a Domain Model in Ruby Without Using class

Introduction

What Is the Data Class?

Example Domain Model

A Class-Based Implementation

The Data Class Available from Ruby 3.2

Writing Domain Logic with Data and Functions

Example Usage

Points to Note

Summary

What Is the `Data` Class?

The `Data` Class Available from Ruby 3.2

Writing Domain Logic with `Data` and Functions