Forem: tom-takeru

Raise UX Cost-Effectively with Smart Default Values

tom-takeru — Thu, 02 Apr 2026 00:14:27 +0000

Thoughtful defaults are a high-leverage way to lift UX while keeping delivery costs down. You can avoid extra settings screens or branching logic and simply lighten user decisions. Here’s why defaults work and practical examples you can ship today.

Why defaults work

Reduce decision cost: People follow what is framed as “recommended” or “already selected.” One fewer click can materially shift drop-off.
Lower downside risk: Safe initial values keep mistakes from causing serious damage.
Shorten learning time: A good default shows “do this first,” so instructions can stay short.

Quick wins with defaults (with examples)

1. Pre-fill forms

Example: Auto-select country/region from the user’s IP. If you’re right 90% of the time, most users never touch it.
Example: Default start date to “today” and auto-calc end date as start date +1 day.
Example: Reuse profile data to pre-fill name and email whenever possible.

2. Communicate freemium limits via initial settings

Example: Make “5 per day” the default selection and label it “Free.” Steering by initial value often feels less pushy than text-only upsells.
Example: Default heavy batch jobs to "run overnight" to smooth system load while giving users a benefit.

3. Bias notifications toward “important only”

Example: For SaaS email, default to alerts/security on and marketing off. Turning promotions on later is an active choice and feels less spammy.
Example: Default push to “digest once a day,” with only urgent items sent immediately. Lower frequency tends to lift NPS.

4. Use safety-first defaults to prevent accidents

Example: For destructive actions (delete/overwrite), default to “show preview.” Require a confirmation phrase to disable it.
Example: For billing actions, default to “show confirmation dialog” with a short summary.

5. Ship a recommended preset as the initial path

Example: During onboarding, let users choose “Recommended preset” to set notifications, theme, and shortcuts in one go; fine-tuning can wait.
Example: In B2B settings, offer presets like “security-first,” “ops-simple,” and “dev-friendly,” with the safest one as default.

Checklist to measure cost-effectiveness

Does the default fit the current user mix? Review region, plan, and device distribution to pick what helps the majority.
Is overriding easy? Users who need a different value should see a clear path to change it.
Does behavior communicate intent better than copy? Aim for defaults that show the intent without heavy labels.
Is risk biased toward safety? Defaults should prevent severe incidents.
Can you observe and iterate? Track how default changes move business metrics.

Takeaway

Defaults are “one-time decisions that pay forever.” Before adding new settings, ask whether an intentional default can raise satisfaction for less build cost. For today’s release, start by questioning the defaults.

How Software Development Changes in the AI Era

tom-takeru — Thu, 19 Mar 2026 00:50:48 +0000

TL;DR

AI drastically reduces implementation cost, but it does not make software development itself unnecessary.
The skills that gain value are requirements definition, task decomposition, design, verification, and deciding what to build.
Observing the real world and spotting problems from firsthand experience remains a distinctly human strength.
Developers are moving from "the person who writes everything by hand" toward "the person who designs an AI-assisted development system and safeguards quality."

Introduction

Over roughly the past year, AI-assisted development has clearly entered a new phase. It used to be mostly about slightly better autocomplete. Now it can handle meaningful implementation, refactoring, test additions, and even review support.

That shift often triggers extreme takes such as, "Will humans stop writing code altogether?" But when I look at what actually happens in day-to-day development, reality feels more grounded. The cost of writing code has definitely dropped, but that has only made other bottlenecks more visible.

In this article, I want to sort out what changes in software development in the AI era, what does not change, and what skills are worth strengthening now. In particular, I believe the ability to observe real friction, notice discomfort, and identify genuine problems will remain one of the most important human roles.

The biggest shift is lower implementation cost

The largest change AI has brought is lower implementation cost.

Small CRUD features, rough UI scaffolding, minor changes that follow existing patterns, extra test cases, and the early steps of library migrations all move faster than before. In many cases, it is already quicker to let AI produce a first draft, review it, and tighten only the important parts than to write everything from scratch.

More recently, AI has gone beyond simple code completion. In some cases, a single instruction is enough to move from an idea to a basic service prototype. It can generate a rough UI, API, data model, and minimum interaction flow in one pass, which has clearly lowered the barrier to getting something tangible in front of your hands.

In other words, the relative scarcity of "writing code" itself is going down.

But lower implementation cost and easier software creation are not the same thing. If implementation gets faster, the next set of questions becomes heavier:

What should we build in the first place?
How much of it should we build now?
How should we split the work so it stays safe?
How do we know the generated code is actually correct?

The AI era rewards the people who are strong at those questions.

The center of gravity shifts from writing to deciding

In the future, what matters more is not moving your hands quickly. It is making sound decisions quickly.

Deciding what to build

AI can turn instructions into something concrete at impressive speed. But if the problem definition is sloppy, the output will be sloppy too.

What is the user problem? What is the real bottleneck worth solving right now? Where is the boundary between "we should do this this month" and "not yet"? If those judgments are wrong, even great AI just takes you in the wrong direction faster.

The starting point for good problem framing is noticing what is actually frustrating for users, what causes friction in the field, and what feels awkward when you touch the product yourself. Small operational annoyances, interface discomfort, and complaints that casually leak out in conversation are hard to discover from a spreadsheet alone. Observing the field and finding problems from firsthand information remains a very human job.

As development speed increases, the value of deciding product direction increases with it. Compared with a world where implementation skill alone created more differentiation, the decision of what to build becomes a much more direct source of competitive advantage.

Breaking work down

If you hand AI a task that is too large, it often produces output that sounds plausible but is risky. On the other hand, it performs very well when the scope is explicit, the constraints are clear, and the checkpoints are well defined.

That means the people who can break a large problem into small, safe pieces become much stronger.

For example, it becomes more important to separate work like this:

Lock the spec first
Define API boundaries first
Build only the UI first
Separate data migration from presentation changes
Prepare the verification path first

This skill mattered before AI too, but now that AI can act like an implementation partner, its value is much easier to see. People who decompose work well can raise the throughput of an entire team.

Design and architectural understanding

AI is good at producing locally reasonable code, but it does not naturally guarantee long-term architectural consistency.

That is why humans need to understand the whole structure. Where should a responsibility live? In which layer should a piece of logic go? Will this change make the system harder to extend six months from now? Those questions matter more now, not less.

To decide whether AI-generated changes are acceptable, you need to evaluate more than local correctness. You need to judge whether they fit the system as a whole.

Verification becomes more of a bottleneck than implementation

One thing I feel strongly in AI-assisted development is that verification is heavier than implementation.

Code appears much faster than before. But the cost of confirming that the result is actually safe, does not break existing behavior, and covers edge cases has not disappeared to the same degree. Tools such as Playwright can automate some interactions, but in my experience they are still not at a level where I can trust them with everything.

For example, I sometimes use AI to produce the first draft of a large-scale refactor. The code comes out quickly, but the real time sink is verifying through E2E checks that the change has not introduced defects across screens and key flows. When the blast radius is wide, a human still has to touch the system carefully and confirm it has not broken.

Cross-cutting changes are even trickier. When you revise the boundary between free and paid plans across the product and fine-tune edge cases, you are dealing with a high-importance change that requires understanding the whole system. AI can update conditional branches in multiple screens and APIs very quickly, but if you do not understand the overall product behavior, you cannot correctly point out what is missing or inconsistent. In the end, a human still has to inspect the free/paid boundaries in detail before the change feels safe to ship.

As AI increases the amount of change a team can produce, a few issues move to the front:

Weak tests make it hard to merge with confidence
Ambiguous specs make review standards fuzzy
Weak monitoring makes production issues harder to notice
A lack of small release units makes every change riskier

So the teams that win in the AI era are not the teams that can generate the most code. They are the teams that can move fast without breaking trust and can learn quickly from what they ship.

That is why investments in tests, CI, type systems, safe deployment patterns, feature flags, and observability become even more important. The faster AI can run, the more valuable guardrails become.

Individuals and small teams gain much more leverage

The people who benefit most from AI are often individual builders and small teams, where decision-making and implementation sit close together.

The reason is simple: the closer the person deciding what to build is to the person prompting AI and making the final call, the shorter the loop becomes. You can decide, prototype, try it, revise it, and change direction very quickly.

Until recently, one of the biggest walls was, "I have an idea, but implementation is too heavy." That wall is lower now. As a result, planning ability, user understanding, and persistence connect more directly to outcomes. In an extreme case, you can go from a single prompt to a working prototype and start touching it almost immediately.

In individual development especially, you can start directly from inconveniences you feel yourself and small frustrations you run into repeatedly in daily life. That kind of firsthand information is powerful. Problems you discover by using, observing, and talking to people change the quality of the instructions you give AI.

An individual can now build a surprisingly strong product in a short time. That makes this a very interesting era for developers. At the same time, the mere fact that something can be built is becoming less of a differentiator, so what matters more is whose problem you solve and how well you solve it.

What changes at different stages of development experience

If AI exists, does that make foundational learning unnecessary? I do not think so. By "different stages" here, I mean stages of experience and responsibility as a software developer, not stages of AI-tool proficiency. The skills that matter simply show up differently at each stage.

Early-stage developers

Early-stage developers need the fundamentals to avoid trusting AI output blindly. If you do not understand what an error means, how HTTP and databases work, what types do, how state is managed, or how testing works, you cannot really evaluate AI suggestions.

AI makes it easier to get moving, but it actually increases the importance of foundational understanding. Without that base, you can easily mass-produce broken code that merely appears to work. A good target is to reach the point where you can explain AI-generated code in your own words.

Mid-level developers

Mid-level developers may have the biggest upside. Once you can read an existing system, think through the impact of a change, and hand AI the right-sized task, your productivity can jump significantly.

At this stage, the differentiator is not "I can write everything myself." It is "I know what to delegate to AI and what I need to own personally." The ability to split work into small requests and quickly judge whether a diff is sound becomes pure leverage.

Senior developers

Senior developers will be valued even more for architectural judgment, prioritization, quality standards, and designing the team’s overall development system.

In the AI era, a senior engineer is not only someone who can implement the hardest parts personally. It is also someone who can create an environment where both humans and AI work well. People who can design review standards, documentation, task-splitting strategy, and verification paths become especially strong. The value shifts from individual speed toward building a team that can move fast consistently.

What developers should start practicing now

The following habits will make it much easier to operate well in AI-assisted development.

Build the habit of writing specs clearly

If something exists only in your head, it does not transfer well to AI or to teammates. Writing down requirements, constraints, completion criteria, and non-goals, even briefly, matters a lot.

I think writing a good spec is more fundamental than writing a good prompt.

Work in smaller slices

AI makes it tempting to push through one giant change, but in practice, smaller units are safer. They are easier to review, easier to recover from when something breaks, and better for learning.

That was already true for human-only development. AI makes the benefit even bigger.

Build verification first

Tests, types, linting, E2E checks, and monitoring are all ways to avoid trusting output too easily. The more you use AI, the faster those investments pay off.

Deepen your understanding beyond code

The people who stay strong in AI-assisted development are the ones who understand the context outside the code: user problems, business domains, operations, billing, support, and organizational decision-making.

It also matters to actively go out and find problems yourself. Numbers and request lists only tell part of the story. Observing the field, using the product yourself, listening to user reactions, and experiencing the inconvenience firsthand give you a level of resolution that is hard to recover later just by reading a spec.

In the end, software is not judged only by how elegant the code looks. It is judged by how well it solves real problems.

Closing

Some people who made it this far may be thinking, "If the barrier to building is getting lower in the AI era, maybe I should turn my own ideas into something real."

I have always loved board games, and I make them myself as well. Through that work, I kept running into the same problem: I wanted to turn ideas into prototypes quickly, but preparation was heavy, and it was hard to reflect test-play feedback fast enough.

That connects directly to the argument in this article. What matters is not just "being able to build," but how quickly you can turn a problem into something tangible, get feedback, improve it, and repeat the loop.

That is why I am building KIBAKO.

KIBAKO is a service for quickly iterating on board game prototyping, collaborative editing, and test play online. I want to make the loop lighter: turn an idea into something playable, try it, improve it, and try again.

If you are interested in board game creation or fast prototyping, feel free to take a look.

Summary

If I had to summarize the shift of the AI era in one sentence, it would be this: the center of gravity in developer value is moving from "being able to write" to "being able to move things forward correctly."

Implementation skill is still necessary, of course. Hard problems will continue to require deep technical ability. But in everyday development, the weight shifts more and more toward defining requirements, decomposing work, verifying both AI and human output, and steering the work in the right direction.

And some jobs remain stubbornly human. Observing the world, noticing friction, and identifying the real problem is one of them. I believe that part becomes even more important in the AI era.

The people who will be strongest are not just the ones who know how to use AI well. They are the ones who can design the entire development process around AI while still finding real problems through human observation and judgment.

Why The Art of Readable Code Boosts Your English

tom-takeru — Tue, 11 Nov 2025 22:52:13 +0000

TL;DR

Code is written for future readers—your teammates, your future self, and even AI—so clarity matters more than cleverness.
Choosing clear English names nudges you to research vocabulary, turning everyday coding into language practice.
Reading The Art of Readable Code naturally builds the desire to write clearer code.
- As a result, reading The Art of Readable Code boosts your English skills.

Code assumes someone will read it

A program is rarely "write once and forget." You will revisit it months later, collaborators will debug it, and AI tools will analyze it. When names and structures convey intent instantly, everyone saves time and avoids mistakes.

Think of names as short messages. Labels like data1 hide meaning, while pendingUsers tells the next reader exactly what to expect.

Naming doubles as English training

Using natural English is the best way to give code meaningful names. Romanized Japanese often confuses global teammates and future contributors.

Suppose you need to represent a list of users waiting for approval. Brainstorming phrases like pendingUsers or unapprovedAccounts pushes you to explore related vocabulary. Because the words are tied to a real task, they stick far better than flashcard memorization.

Learn the basics with The Art of Readable Code

The Art of Readable Code (published in Japanese as 『リーダブルコード』) is a concise guide to writing code that communicates. Each chapter covers a small habit—naming, comments, decomposing functions—making it approachable for beginners.

As you read, you internalize the question, "How can I help the next reader?" That mindset naturally leads you to refine English names and look up better phrasing, reinforcing both coding and language skills.

https://www.oreilly.com/library/view/the-art-of/9781449318482/

Key takeaways

Code clarity serves you, your teammates, and AI assistants alike.
Intentional English naming turns daily development into continuous language study.
The Art of Readable Code is an ideal starting point for aspiring engineers who want readable software and stronger English.

Start building the habit today: aim for code that is easy to read, and let the desire for better names guide your English learning.

Ship Small, Learn Big—Staged Rollouts Strengthen Your Product

tom-takeru — Sun, 26 Oct 2025 23:01:23 +0000

TL;DR

Ship smaller slices so users feel the value sooner and you can learn before over-investing.
Evaluate each cut by whether it delivers standalone value and avoids confusing users.
Design the slices, refine them during implementation, and iterate quickly with real feedback.

Introduction

This article lays out why delivering in small increments matters, how to decide where to draw the boundaries, and what execution pattern keeps those releases delivering value.

Why staged rollouts matter

Unlock value faster by shipping in smaller slices

Bundling everything into one launch keeps even finished functionality sitting on the shelf, pushing back the moment value reaches your users. Shipping a partial slice lets you invite them to try it without delay.

Letting people touch the product earlier surfaces real reactions right away, so the team can plan its next move with evidence. It also reduces the risk of overbuilding and having to undo work later.

Let early feedback steer you

Watching how people use the slice you shipped makes it easier to decide whether to double down or shift priorities. You stay away from slamming the brakes right before a launch, which protects both the team’s schedule and the user experience.

Prevent big-bang release disasters

All-at-once launches widen the blast radius when something goes wrong and draw out recovery times. Rolling out in stages limits how many people feel the regression and lets you focus monitoring and support where the change actually happened.

When each slice bakes in a risk review and clear rollback path, you can unwind issues quickly without denting user trust. The team stays confident and keeps improving the product deliberately.

Staged rollouts are like growing a tree

A staged rollout is like nurturing a product as you would a tree.

You plant a small seedling (the first feature), observe its growth (user feedback), prune the branches (remove unnecessary parts), and add fertilizer (make improvements). Step by step, it grows stronger and healthier.

How to decide on the release units

Can it deliver value on its own?

It's crucial to consider whether the slice can solve a complete, albeit small, user problem and be perceived as a useful improvement.
If a feature only provides value when paired with something else, you need to map out those dependencies and adjust the release order accordingly.

Will upcoming changes confuse your users?

If you expect to update the feature again soon, will that follow-up change create confusion for your users?
In other words, keep the rollout as small as possible unless doing so would violate these guardrails.

Other Considerations

Is its impact measurable?
Ease of rollback
Ease of marketing and communication

Steps for running a staged rollout

Sketch shippable slices during discovery

Product managers, engineers, and designers should sketch the units they believe can reach users early. Whether you cut the work by page, flow, or another lens, having those user-facing slices defined up front keeps later conversations smooth.

Re-scope during estimation to keep it realistic

Bring in engineering’s view of how the implementation will go. That is where you learn “these pieces should ship together” or “this part can be fully isolated.” Reconfirm priorities and resources, then lock in the release phases.

Use feature flags to meter exposure

Feature flags are runtime toggles that wrap new features, allowing for staged releases where you can switch features on or off without redeploying and enable them for specific users (e.g., internal-only or developers-only) as needed. They let you target slices to specific cohorts and expand coverage incrementally. That same toggle keeps risk low while still delivering value to the people you turn it on for.

Ship small, listen, and fold the learning back in

For each slice, move from implementation to testing to production in a tight loop. Right after each release, watch dashboards and support channels, and fold the reactions into the next improvement. Keeping the loop anchored in user feedback makes the value of staged rollouts obvious.

Summary

Shipping valuable functionality in the smallest possible increments benefits both users and the development team.
Looking at standalone benefit and dependency management helps you efficiently define release units.
Releasing in stages while folding real reactions into each iteration turns the need for staged rollouts into something you feel every day.

My AI-Era Technical Article Repository

tom-takeru — Sun, 28 Sep 2025 07:21:57 +0000

TL;DR

I keep English posts for dev.to and Japanese posts for Qiita in one GitHub repo, then lean on an AI-first writing flow to move faster🚀
Make targets wrap TypeScript scripts so draft updates and publications reuse front matter settings without risky manual toggles.
This repository is just my working example, so treat the structure and workflow as inspiration and remix them for your own stack.

Introduction

I wanted to draft articles entirely inside my favorite AI editor, teach the model how I structure posts, and shorten the handoff from draft to publication—this repository is how I made that happen📚

Feel free to peek at https://github.com/tom-takeru/articles as you read. The setup routes Japanese pieces to Qiita and English pieces to dev.to so each audience gets the right language. Qiita ships an official CLI, but I skipped it here. dev.to currently lacks an official command-line client.

Pick the ingredients that help your workflow and rearrange the rest.

Who this is for

Writers who want AI-first editing

You prefer loading Markdown into an AI editor and iterating with prompts instead of jumping between browser tabs🖊️

Writers who want to train their AI on house style

Keeping past articles and new drafts in one repo makes it easy to surface voice, format, and go-to sections for your assistant🧠

Writers who want Git-powered article history

Git history doubles as your publishing log, which makes diffs and reviews painless when you need approval🗂️

Writers shipping bilingual posts efficiently

You plan to publish Japanese to Qiita and English to dev.to in pairs, and you want automation to prevent duplicated work🌍

Repository at a glance

Here’s a quick tour of https://github.com/tom-takeru/articles.

Markdown lives under content/ja/ and content/en/, and each file’s platform field keeps the correct destination aligned🗃️
TypeScript scripts in scripts/ parse front matter and talk to the dev.to and Qiita APIs for draft and publish operations.
.posts-map.*.json files synchronize local Markdown with remote IDs so the Makefile can run exactly the steps you need.

Publishing workflow

Step 1 Draft the article

Edit your Markdown with help from your AI assistant and keep momentum with tight prompt-feedback loops✍️

Existing posts in the repo become on-demand references for tone and structure, and once the Japanese version feels right you can ask the AI for an English translation before reviewing it yourself.

Step 2 Create or refresh platform drafts

Run make draft to update dev.to and Qiita drafts🧪

PUBLISH_MODE defaults to draft, so you won’t accidentally ship a half-finished article.

If you need to embed images

Both Qiita and dev.to require manual uploads from their draft editors. The flow here is:

Run make draft to create the remote draft.
Upload images in each platform’s web UI.
Copy the generated URLs into your local Markdown.
Run make draft again to sync the updated content.

Step 3 Publish the article

Once everything reads clean, run make publish🎯

The workflow refuses to publish if a draft was never created, which guards against accidental releases.

Step 4 Merge changes into the main branch on GitHub

Commit your changes, push the branch, and open a PR💾

CI fetches the current publication status via API using the .posts-map.*.json records generated during your local runs. That safety net keeps forgotten draft or publish commands from slipping through.

When the checks pass, merge the PR into main.

If you need more detail, browse the README and source files in https://github.com/tom-takeru/articles.

Wrapping up

Pairing an AI editor with a Git-backed workflow turns article production into a tight loop of prompts, reviews, and scripted releases🌱

From here it’s all about tuning the process so it fits your voice and schedule.

Side note

I wrote this article with Codex Web and Codex CLI. Codex Web is my current go-to OpenAI assistant for spinning up isolated development environments in parallel. If you’re curious, check out my write-up: How I Used Codex to Ship Nearly 80 Pull Requests in Two Days

How I Used Codex to Ship Nearly 80 Pull Requests in Two Days

tom-takeru — Sat, 27 Sep 2025 09:38:56 +0000

TL;DR

Codex is the ultimate development environment if you already pay for ChatGPT Plus—parallel tasks and even mobile development made shipping almost 80 PRs in two days feel realistic.
Leaning on Codex Web as the hub, Codex CLI for precision edits, and splitting work across multiple environments with Ask-driven ideation sent my throughput skyrocketing.
Going forward, engineers will compete less on implementation and more on "what to build," driven by planning and architectural insight.

Introduction

Over two intense days of personal development I created nearly 80 pull requests. This article reorganizes that experience so you can see, at a glance, why Codex Web and Codex CLI together made it possible—from the background and motivation to the workflow details and what I plan to explore next.

Background & Self-Introduction

I am a board-game-loving full-stack engineer who constantly experiments with LLM-powered coding assistants. For more details about me, please see Getting Started with tom-takeru and GitHub | @tom-takeru.

Here is how my current toolkit looks.

My Current LLM Toolkit

GitHub Copilot
- Generate PR descriptions and pair with VS Code (I relied on it heavily for personal projects in the past)
Cursor
- Used intensively at work until a month or two ago
Cursor CLI
- Tried it for a few days right after the ChatGPT 5 release
Claude Code
- My primary assistant for work right now
Codex Web
- Using it nonstop for the past month on side projects
Codex CLI
- Hammering it daily over the past month as well
- I even hit the ChatGPT Plus usage limit screen:

CLI output when the limit triggers:

▌🖐  You've hit your usage limit. Upgrade to Pro (https://openai.com/chatgpt/pricing)
▌or try again in 19
▌hours 59 minutes.

Recently released usage overlay (the new 5h and weekly limits are visible):

╭──────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.42.0)                                               │
│                                                                          │
│  Model:          gpt-5-codex (reasoning low, summaries auto)             │
│  Directory:      ~/.config/nvim                                          │
│  Approval:       on-request                                              │
│  Sandbox:        read-only                                               │
│  Agents.md:      <none>                                                  │
│  Account:        dummy-email@example.com (Plus)                          │
│  Session:        -dummy-session-id-                                      │
│                                                                          │
│  Token usage:    0 total  (0 input + 0 output)                           │
│  5h limit:       [████████████████████] 100% used (resets 18:31)         │
│  Weekly limit:   [█████████████░░░░░░░] 64% used (resets 19:58 on 1 Oct) |
╰──────────────────────────────────────────────────────────────────────────╯

How I Think About Codex

Codex is the LLM coding assistant service that perfectly fits my needs.
It ships both a web interface and a CLI, and Codex Web in particular blew me away with how it handles multi-tasking.

Why I Started Using Codex

Claude Code running inside neovim showed me how powerful an LLM CLI could be at work, so I started searching for something I could lean on for side projects.
When I heard that my existing ChatGPT Plus subscription unlocked Codex CLI, I jumped in immediately.

How Codex Changed My Throughput

Subjectively, my development throughput jumped several times over. In the same amount of time:

Working with a conventional LLM coding assistant: Imagine you’re a single cook in a restaurant. You take an order, cook the dish, serve it, and only then can you start the next order.
Working with Codex Web: Now, imagine you’re the head chef of a large kitchen. You take five orders, hand them off to five different cooks, and they all work at the same time. You just check the dishes before they go out.

My Plan and Cost

Plan
- ChatGPT Plus only—$20/month with no additional Codex fee
Coverage
- Includes ChatGPT, Codex Web, and Codex CLI

Why Codex—Especially Codex Web—Stands Out

Combining Codex Web and Codex CLI reshaped how I manage tasks and experience development. Breaking it down highlights where the acceleration comes from.

Parallel Task Execution

Create an Environment by pointing Codex at a repository and it clones the repo into its own isolated workspace.
Multiple instructions progress simultaneously inside their own sandboxes.
It genuinely feels like managing a team of engineers from a lead’s cockpit.

PR Creation Speed

Review rough drafts in the browser, request fixes if needed, and create a PR (Drafts included) with a single click.

Screens that show the diff review and PR creation experience in Codex Web:

Codex Web displaying task diff after completion	Pull request generated via the Codex Web Push button

Idea Generation via Ask

Ask Codex for prompts like “Give me three small refactoring ideas,” then hit Start Task to spin them into runnable work immediately.

Screens that show how Ask suggestions flow into actual tasks:

Ask surface listing refactoring ideas	Starting a task directly from an Ask suggestion	Codex Web running multiple Ask-derived tasks in parallel

Development from a Phone

I used to stop at reviewing diffs in the GitHub app, but now I can inspect diffs and ship changes end-to-end from my phone.

Mobile task list inside the ChatGPT app	Summary view for a specific task	Task diff and Push (Create PR) button on mobile

Codex Power-Use Playbook

Codex Web sits at the center while the CLI and prompt design keep the pace high. This is the foundation I rely on.

Tip 1: Lead With Codex Web

Finish most development tasks entirely in the browser.
Split instructions by scope so work progresses in parallel without stepping on itself.

Tip 2: Use Codex CLI for Surgical Edits

Apply UI tweaks or rapid validation directly from the CLI.
Clone the repository into multiple directories to run Codex CLI across several environments. You still need to watch for conflicts, and it is easy to hit the Codex CLI quota, so this setup helps save that budget.

Tip 3: Shape Prompts Carefully

Break requests into “the smallest steps that satisfy the requirement.”
Define scope boundaries up front to avoid conflicts.
If conflicts happen anyway, rebase locally and resolve with the CLI.

Case Study: Shipping ~80 PRs in Two Days

This burst happened while building a subscription-style product I am developing. The repository has been active for about six months and has already closed roughly 400 PRs. The work I did this time included dev-environment improvements, library upgrades, UI polish, and mid-sized feature additions.

Step-by-Step Loop

Request tasks in parallel
- Hand Codex Web around five tasks at a time while being mindful of conflict risk.
Create PRs
- Skim the output and, if it looks good, turn it into a PR immediately.
- If something is off, highlight the issues and rerun the task.
Handle CI and reviews
- When CI finishes, respond to CodeRabbit comments or failures by pulling the remote branch.
- Combine Codex CLI with GitHub MCP so review follow-ups and pushes happen automatically from the PR link.
Merge
- Once the feedback and CI are clear, run manual verification and merge.
Reuse idle time
- While waiting for reviews or CI, hop back to other PRs and resume from step 3.

Running this loop meant that I looked up mid-session and realized nearly 80 PRs were ready in just two days.

What I'll Try Next

GitHub reviews via Codex Web
- Drafts are produced by AI and humans lead reviews today, but I want to try Codex’s review capabilities.
- The newly added /review command in Codex CLI looks especially promising.
Deeper CLI usage
- The web app is still my primary driver, yet I am convinced there are hidden gems left in the CLI.
Tool benchmarking
- I plan to keep using Claude Code and CodeRabbit alongside Codex so each tool can play to its strengths.

Reflections

Codex feels red-hot right now, with updates seemingly landing every two days.
- https://github.com/openai/codex/releases
Thinking hard about “what to build” matters even more.
- Engineers will win by designing direction, not just writing code.
Codex Web genuinely feels like a manager’s console.
- It is like coordinating four or five engineers, setting direction, and reviewing their code.
Task decomposition precision is crucial.
- The finer you split work before handing it to the Codex “engineers,” the better the outcome.
Architecture understanding is valuable.
- When the human understands the full picture, it is easier to define steps and delegate them.
Right now it still favors engineers.
- At this stage, engineers squeeze the most value out of the toolset.
The next battleground is deciding what to build.
- As AI tooling becomes accessible to everyone, the default becomes “you can build anything,” so creativity and planning take center stage.

Key Takeaways

Codex is the ultimate development environment if you already pay for ChatGPT Plus—no additional fee.
Pairing Codex Web for direction with Codex CLI for precision edits unlocks a new development rhythm.
Parallel tasks and mobile development feel like switching from walking to riding a bike—maybe even jumping into a car.
Shipping roughly 80 PRs in two days is absolutely doable.

Server Monitoring using GAS (Google Apps Script) within the Free Usage Limits

tom-takeru — Sat, 22 Mar 2025 04:52:08 +0000

When using Google Apps Script (GAS), one common concern is how much you can achieve within the free usage limits. In this article, we'll summarize these limits and demonstrate a practical example of how to prevent your backend server from sleeping by regularly pinging its health-check API.

Main Limits of GAS Free Tier

Below are the primary limitations of GAS’s free usage:

Item	Limit
Maximum execution time per script run	6 minutes (360 seconds)
Total daily execution time	90 minutes (5400 seconds)
Number of triggers	Maximum 20 triggers per script
URL Fetch calls	20,000 requests per day
Emails sent	100 emails per day

For detailed information, please refer to the official documentation: Quotas for Google Services (Official)

How to Use GAS for Regular Server Health-Check to Prevent Sleep

In this practical example, we demonstrate how to prevent a backend server running on a free plan from sleeping by pinging its health-check API every 5 minutes using GAS.

Implementation Steps

Follow these detailed steps to set up the GAS:

Create a new Google Spreadsheet.
Create a sheet named ServerCheckURLs.
Enter the URLs you want to monitor into column A of this sheet.
Open the GAS editor by clicking on "Extensions" → "Apps Script" from the spreadsheet.
Copy and paste the GAS script provided below and save it.

GAS Implementation Example

function main() {
  const urls = getUrlsFromSheet('ServerCheckURLs');
  Logger.log('===== HTTP Status of URLs =====');
  urls.forEach((url, index) => {
    const statusCode = fetchHttpStatusCodeWithRetry(url, 3, 30000);
    Logger.log(`${index + 1}. URL: ${url}\n   HTTP Status: ${statusCode}`);
  });
  Logger.log('================================');
}

// Fetch URLs from column A of the specified sheet
function getUrlsFromSheet(sheetName) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(sheetName);
  const lastRow = sheet.getLastRow();

  if (lastRow < 1) return [];

  const urlRange = sheet.getRange(`A1:A${lastRow}`);
  const urls = urlRange.getValues()
    .flat()
    .filter(url => url); // remove empty cells

  return urls;
}

// Fetch HTTP status code with retry mechanism
function fetchHttpStatusCodeWithRetry(url, retryCount, intervalMs) {
  let statusCode = fetchHttpStatusCode(url);
  let attempts = 1;

  while (statusCode !== 200 && attempts <= retryCount) {
    Logger.log(`Retrying ${url} (${attempts}/${retryCount}) in ${intervalMs / 1000}s...`);
    Utilities.sleep(intervalMs);
    statusCode = fetchHttpStatusCode(url);
    attempts++;
  }

  return statusCode;
}

// Fetch HTTP status code for a given URL
function fetchHttpStatusCode(url) {
  const options = { muteHttpExceptions: true };
  try {
    const response = UrlFetchApp.fetch(url, options);
    return response.getResponseCode();
  } catch (e) {
    Logger.log(`Error accessing ${url}: ${e}`);
    return 'Error';
  }
}

Set up a trigger following the steps below:

Trigger Setup

In the GAS editor, select "Triggers" from the left-hand menu.
Click on "Add Trigger" button at the bottom-right.
Select the main function to execute.
Set the trigger type to "Time-driven".
Choose the timer frequency, such as every 5 minutes, and save the trigger.

Practical Example: Evaluating a 5-Minute Interval Trigger

Here's a concrete example scenario:

Script execution frequency: Every 5 minutes
Daily execution count: 24 hours × (60 minutes ÷ 5 minutes) = 288 times/day
Maximum execution time per run: approximately 6.5 seconds
- Note: The 6.5 seconds represents the longest observed runtime, not the average.

Calculating total daily execution time:

About 6.5 seconds × 288 runs ≈ 1883 seconds (~31 minutes)

Result: Within Free Tier Limits

Note: Depending on your setup, you may hit either the execution time limit or URL Fetch limit first. It is advisable to calculate based on your specific number of monitored URLs and their response times.

Evaluating URL Fetch Limit

Here's a quick reference table to ensure you're within the daily URL Fetch limit (20,000 requests per day):

Number of URLs	Requests per Run	Runs per Day (every 5 mins)	Total Requests per Day	Within Limit?
1	1	288	288	✅ Yes
5	5	288	1,440	✅ Yes
10	10	288	2,880	✅ Yes
50	50	288	14,400	✅ Yes
69	69	288	19,872	✅ Yes
70	70	288	20,160	❌ No (exceeds limit)

As shown, you can safely monitor up to 69 URLs at a 5-minute interval without exceeding the free URL Fetch quota.

Comparing with GAS’s free limits (6 minutes per run, 90 minutes per day), the current scenario (maximum ~6.5 seconds per run, ~31 minutes per day) is comfortably within the allowed limits.

Therefore, such regular health checks every 5 minutes can safely and effectively operate within GAS’s free usage tier.

Real-Time Web Application demo with WebSocket - Backend

tom-takeru — Fri, 27 Dec 2024 00:55:52 +0000

Introduction

In this article, I will explore the backend implementation of my real-time WebSocket application. Built using Gin and Go, the backend efficiently manages WebSocket connections, stores messages, and broadcasts updates to all connected clients.

Project Structure

https://github.com/tom-takeru/web-socket-demo

My backend project is organized to ensure modularity and reusability. Below is the updated directory structure:

./backend
├── go.mod
├── go.sum
├── main.go
└── stores
    └── messages.go

Key Directories and Files

go.mod: Defines module dependencies and versions.
main.go: Entry point of the application that initializes the WebSocket server and routes.
stores/messages.go: Manages message storage with thread-safe operations.

Core Component: main.go

main.go is the main entry point for my WebSocket server application. It sets up the Gin router, defines the WebSocket route, and handles the WebSocket lifecycle.

Code Walkthrough

package main

import (
    "encoding/json"
    "net/http"
    "sync"
    "time"

    "github.com/gin-gonic/gin"
    "github.com/gorilla/websocket"

    "github.com/tom-takeru/web-socket-demo/backend/stores"
)

var (
    upgrader = websocket.Upgrader{
        CheckOrigin: func(r *http.Request) bool {
            origin := r.Header.Get("Origin")
            // NOTE: This project is for local development only.
            return origin == "http://localhost:3000"
        },
    }
    messageStore = stores.NewMessageStore()
    clients      = make(map[*websocket.Conn]bool)
    clientsMu    sync.Mutex
)

func handleWebSocket(c *gin.Context) {
    conn, err := upgrader.Upgrade(c.Writer, c.Request, nil)
    if err != nil {
        c.JSON(http.StatusInternalServerError, gin.H{"error": "Failed to upgrade to WebSocket"})
        return
    }
    defer conn.Close()

    clientsMu.Lock()
    clients[conn] = true
    clientsMu.Unlock()

    // Send existing messages to the new connection
    for _, msg := range messageStore.MarshalMessages() {
        conn.WriteMessage(websocket.TextMessage, msg)
    }

    for {
        _, message, err := conn.ReadMessage()
        if err != nil {
            break
        }

        var msgData map[string]string
        if err := json.Unmarshal(message, &msgData); err != nil {
            break
        }

        timestamp := time.Now().Format(time.RFC3339)
        msgData["timestamp"] = timestamp

        messageStore.AddMessage(msgData)

        modifiedMessage, err := json.Marshal(msgData)
        if err != nil {
            break
        }

        clientsMu.Lock()
        for client := range clients {
            if err := client.WriteMessage(websocket.TextMessage, modifiedMessage); err != nil {
                client.Close()
                delete(clients, client)
            }
        }
        clientsMu.Unlock()
    }

    clientsMu.Lock()
    delete(clients, conn)
    clientsMu.Unlock()
}

func main() {
    r := gin.Default()
    r.GET("/ws", handleWebSocket)
    r.Run("localhost:8080")
}

Key Functionalities

State Management: Tracks connected clients and ensures thread-safe access using a mutex.
WebSocket Lifecycle: Handles connection setup, message broadcasting, and cleanup on disconnection.

Conclusion

The backend implementation of my WebSocket demo application demonstrates how to manage real-time communication effectively using Gin and Go. By leveraging WebSocket for persistent connections and a thread-safe message store, this application serves as a robust foundation for building real-time web applications.

In the next article, I will discuss deployment strategies and optimizing WebSocket performance.

Links to the Series

Real-Time Web Application demo with WebSocket - Frontend

tom-takeru — Fri, 27 Dec 2024 00:42:27 +0000

Introduction

In this article, I will explore the frontend implementation of our real-time WebSocket application. Built with Next.js and TypeScript, the frontend serves as an interactive interface for sending and receiving real-time messages. Let's dive into the details of how this application is structured and how the components interact to provide a seamless WebSocket experience.

Project Structure

https://github.com/tom-takeru/web-socket-demo

The frontend project is organized to ensure modularity and reusability. Below is the updated directory structure:

./frontend/src
├── app
│   ├── globals.css
│   ├── layout.tsx
│   └── page.tsx
├── components
│   ├── HomePage.tsx
│   ├── message
│   │   ├── MessageInputForm.tsx
│   │   ├── MessageList.tsx
│   │   └── MessageSection.tsx
│   └── websocket
│       ├── WebSocketControls.tsx
│       ├── WebSocketSection.tsx
│       └── WebSocketStatus.tsx
└── hooks
    └── useMessages.ts

Key Directories and Files

app/: Contains global styles and layout definitions for the application.
components/: Includes the primary components for messages and WebSocket handling.
hooks/: Contains custom hooks, such as useMessages, for managing state and logic.
HomePage.tsx: The central page that ties everything together.

Core Component: HomePage.tsx

HomePage.tsx is the main entry point for the WebSocket application. It integrates message and WebSocket-related components while managing the application's state and lifecycle.

Code Walkthrough

"use client";

import { useState, useRef, useEffect } from "react";
import { useMessages } from "@/hooks/useMessages";
import MessageSection from "@/components/message/MessageSection";
import WebSocketSection from "@/components/websocket/WebSocketSection";

export default function HomePage() {
  const { messages, clearMessages, addMessage } = useMessages();
  const [connectionStatus, setConnectionStatus] = useState<
    "Connected" | "Disconnected"
  >("Disconnected");
  const [isSending, setIsSending] = useState<boolean>(false);
  const [message, setMessage] = useState<string>("");
  const wsRef = useRef<WebSocket | null>(null);

  useEffect(() => {
    return () => {
      if (wsRef.current) {
        wsRef.current.close();
      }
    };
  }, []);

  const handleOpen = () => {
    console.log("Connected to WebSocket");
    setConnectionStatus("Connected");
  };

  const handleMessage = (event: MessageEvent) => {
    console.log("Message from server:", event.data);
    const data = JSON.parse(event.data);
    addMessage(data.message, data.timestamp);
    setMessage("");
    setIsSending(false);
  };

  const handleError = (error: Event) => {
    console.log("WebSocket error:", error);
    alert("Failed to connect to WebSocket.");
  };

  const handleClose = () => {
    console.log("WebSocket closed");
    setConnectionStatus("Disconnected");
    wsRef.current = null;
  };

  const startWebSocket = () => {
    if (wsRef.current && wsRef.current.readyState !== WebSocket.CLOSED) {
      alert("WebSocket is already open");
      return;
    }

    clearMessages();

    const ws = new WebSocket("ws://localhost:8080/ws");
    wsRef.current = ws;

    ws.onopen = handleOpen;
    ws.onmessage = handleMessage;
    ws.onerror = handleError;
    ws.onclose = handleClose;
  };

  const stopWebSocket = () => {
    if (!wsRef.current) {
      alert("WebSocket is not open");
      return;
    }
    wsRef.current.close();
    wsRef.current = null;
    setConnectionStatus("Disconnected");
  };

  const sendMessage = async () => {
    if (message.trim() === "") {
      alert("Message cannot be empty");
      return;
    }

    if (!wsRef.current || wsRef.current.readyState !== WebSocket.OPEN) {
      alert("WebSocket is not open");
      return;
    }

    setIsSending(true);
    const jsonMessage = JSON.stringify({ message });
    wsRef.current.send(jsonMessage);
    setMessage("");
  };

  return (
    <div className="flex flex-col items-center justify-center min-h-screen p-8 pb-20 sm:p-20 font-sans">
      <h1 className="text-3xl font-bold">WebSocket Demo App</h1>
      <main className="flex flex-col gap-2 items-center w-full max-w-md">
        <MessageSection
          messages={messages}
          message={message}
          setMessage={setMessage}
          sendMessage={sendMessage}
          isDisabled={connectionStatus === "Disconnected" || isSending}
        />
        <WebSocketSection
          connectionStatus={connectionStatus}
          startWebSocket={startWebSocket}
          stopWebSocket={stopWebSocket}
        />
      </main>
    </div>
  );
}

Key Functionalities

State Management: Manages connection status, current message, and sending state.
WebSocket Lifecycle: Handles connection setup, events (onopen, onmessage, onerror, onclose), and teardown.
User Interaction: Provides clear feedback and controls for starting/stopping the connection and sending messages.

Conclusion

The HomePage.tsx component demonstrates the integration of WebSocket functionalities with a clean React structure. Its focus on state management and user interaction makes it the backbone of the application's frontend.

In the next article, I will explore the backend implementation using Gin and Go, detailing how the WebSocket server handles connections and messages.

Links to the Series

Real-Time Web Application demo with WebSocket - Overview

tom-takeru — Thu, 26 Dec 2024 23:51:28 +0000

Introduction to WebSocket

WebSocket has become an essential technology for building real-time, interactive web applications. Unlike HTTP, which relies on a request-response model, WebSocket establishes a persistent, full-duplex communication channel between a client and a server. This capability is particularly useful for applications like chat systems, live notifications, and collaborative tools.

In this article, I will walk you through a demo application I built to explore WebSocket behavior. The application uses Next.js with TypeScript for the frontend and Gin with Go for the backend. This is the first in a series of articles where we delve into WebSocket basics, implementation details.

Demo Application Overview

https://github.com/tom-takeru/web-socket-demo

The demo application demonstrates a simple WebSocket-based communication system. It includes the following features:

1. Real-time updates

Clients can send and receive messages instantly without refreshing the page.

2. Bidirectional communication

Both the server and the client can initiate communication at any time.

3. Minimal setup

The application is designed to be lightweight and easy to understand, making it a great starting point for learning WebSocket.

Frontend:

Built with Next.js and TypeScript, the client interface is minimal, featuring a text input for messages and a display area for real-time updates.

Backend:

Developed using Gin and Go, the server handles WebSocket connections and routes messages between connected clients.

Application in Action

Below is a screen capture of the application in action:

WebSocket Technical Details

Understanding WebSocket Protocol

WebSocket is a protocol designed for full-duplex communication over a single TCP connection. It is initiated via an HTTP/HTTPS handshake, after which the connection is upgraded to WebSocket. This allows for efficient real-time communication with reduced overhead compared to traditional HTTP polling or long-polling.

Demo Application Workflow

1. Connection Establishment

The client sends a WebSocket handshake request to the server. The server responds with an acknowledgment, establishing a persistent connection.

2. Message Flow

The client can send messages to the server, which then broadcasts them to all connected clients. Similarly, the server can push updates to the clients.

Tools and Libraries Used

Next.js
- TypeScript
Gin
- Go

Wrapping Up

WebSocket enables real-time, interactive experiences that are indispensable for modern web applications. By building this demo application, we gain a deeper understanding of how WebSocket function and how to implement them effectively using Next.js and Gin.

In the next articles, we will dive deeper into the implementation details.

The simplest demo on SSE(Server-Send Events)

tom-takeru — Fri, 22 Nov 2024 22:00:21 +0000

Introduction

Server-Sent Events (SSE) is a web technology that allows a server to push real-time updates to a client over HTTP. Unlike WebSockets, SSE is simpler to implement as it uses a one-way communication channel from the server to the browser and works over a regular HTTP connection. It is especially useful for applications requiring periodic updates, such as live scores, notifications, or real-time monitoring dashboards.

I created this demo because I’m currently developing an application where AIs discuss various topics. I wanted to implement some stream-like features and discovered the technology called "SSE".

Demo Overview

This demo showcases how Server-Sent Events (SSE) can be used to send real-time updates from an API to the browser. In this example, the browser displays a series of sample messages sent by the server. The simplicity of this demo makes it an excellent starting point for understanding how SSE works and integrating it into your projects.

Demo Video

Below is a video demonstrating how the Server-Sent Events (SSE) demo works in real time. Watching this video will give you a better understanding of how the client and server interact to provide real-time updates.

Implementation

The core implementation of the Server-Sent Events (SSE) demo is split into two parts: the frontend and the backend. The full source code is available on GitHub: sse-demo repository.

Frontend (`ui/src/app/page.tsx`)

The frontend is built with React and provides buttons to start and stop the SSE connection, displaying real-time messages from the server. Here are the main highlights:

Connecting to SSE: The handleStartConnection function creates an EventSource object connected to the /events endpoint. It listens for messages, open events, and error events:
- onmessage: Handles incoming messages and updates the messages state.
- onopen: Logs when the connection is established.
- onerror: Handles errors, logging details and closing the connection if needed.
Stopping the Connection: The handleStopConnection function closes the SSE connection and cleans up.
UI: The page includes a simple interface with start/stop buttons and a list to display messages.

"use client";

import type React from "react";
import { useState } from "react";

const App: React.FC = () => {
  const [messages, setMessages] = useState<string[]>([]);
  const [eventSource, setEventSource] = useState<EventSource | null>(null);

  const handleStartConnection = () => {
    const newEventSource = new EventSource("http://localhost:8080/events");

    const handleOnMessage = (event: MessageEvent) => {
      console.log("onmessage", event.data);
      setMessages((prev) => [...prev, event.data]);
    };

    const handleOnOpen = () => {
      console.log("Connection established");
    };

    const handleOnError = (error: Event) => {
      console.error("onerror", error);
      console.log("readyState:", newEventSource.readyState);
      console.log("Connection error occurred.");
      newEventSource.close();
      setEventSource(null);
    };

    const handleOnClose = () => {
      console.log("Connection is being closed by the server.");
      newEventSource.close();
      setEventSource(null);
    };

    newEventSource.onmessage = handleOnMessage;
    newEventSource.onopen = handleOnOpen;
    newEventSource.onerror = handleOnError;
    newEventSource.addEventListener("close", handleOnClose);

    setEventSource(newEventSource);
  };

  const handleStopConnection = () => {
    if (eventSource) {
      eventSource.close();
      setEventSource(null);
      console.log("Connection closed");
    }
  };

  return (
    <div>
      <h1>Server-Sent Events Demo</h1>
      <button
        type="button"
        onClick={handleStartConnection}
        disabled={!!eventSource}
        className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded disabled:opacity-50"
      >
        Start Connection
      </button>
      <button
        type="button"
        onClick={handleStopConnection}
        disabled={!eventSource}
        className="bg-red-500 hover:bg-red-700 text-white font-bold py-2 px-4 rounded disabled:opacity-50 ml-2"
      >
        Stop Connection
      </button>
      <ul>
        {messages.map((message, index) => (
          <li key={`${index}-${message}`}>{message}</li>
        ))}
      </ul>
    </div>
  );
};

export default App;

Backend (`api/main.go`)

The backend is built using the Gin framework for Go and includes the following key features:

CORS Configuration: The backend uses the Gin CORS middleware to allow connections during debugging.
SSE Endpoint: The /events endpoint streams a series of pre-defined messages to the client with a delay between each message. Key components:
- Headers are set to specify the text/event-stream content type.
- Messages are sent in a loop, with a 2-second delay between each message.
- A final close event signals the end of the connection.

package main

import (
    "fmt"
    "time"

    "github.com/gin-contrib/cors"
    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()

    r.Use(cors.New(cors.Config{
        AllowOrigins:     []string{"*"},
        AllowMethods:     []string{"GET", "POST", "PUT", "DELETE"},
        AllowHeaders:     []string{"Origin", "Content-Type"},
        ExposeHeaders:    []string{"Content-Length"},
        AllowCredentials: true,
    }))

    r.GET("/events", func(c *gin.Context) {
        c.Writer.Header().Set("Content-Type", "text/event-stream")
        c.Writer.Header().Set("Cache-Control", "no-cache")
        c.Writer.Header().Set("Connection", "keep-alive")

        fmt.Fprintf(c.Writer, "retry: 0\n\n")
        c.Writer.Flush()

        messages := []string{
            "(Mike) Hello",
            "(Tom) Hi!",
            "(Mike) How are you?",
            "(Tom) I'm good, thanks! How about you?",
            "(Mike) I'm doing well, thanks for asking.",
            "(Tom) What's your plan for today?",
            "(Mike) I have a meeting in the afternoon.",
            "(Tom) Sounds good. Let's catch up later.",
            "(Mike) Sure, see you later!",
            "(Tom) Bye!",
        }

        for _, msg := range messages {
            // NOTE: This is just for demonstration purposes.
            time.Sleep(2 * time.Second)
            fmt.Fprintf(c.Writer, "data: %s\n\n", msg)
            c.Writer.Flush()
        }

        c.Writer.Write([]byte("event: close\ndata: \n\n"))
        c.Writer.Flush()
    })

    r.Run("0.0.0.0:8080")
}

How to Run It

To run this demo, please refer to the README.md file in the GitHub repository. It contains step-by-step instructions for setting up and running both the frontend and backend of the project.

Conclusion

This demo provides a simple yet effective introduction to Server-Sent Events (SSE), demonstrating how to stream real-time messages from a server to a browser. By focusing on the basics, it’s designed to help you quickly understand the core concepts and start experimenting with SSE in your own projects.

If you’re interested in trying it out or building upon this example, check out the full source code on GitHub: sse-demo repository.