DEV Community: Takashi Masuda

Read 'AWS Container Design and Build: A Practical Introduction, Revised and Expanded Edition' and Worked Through Every Hands-On Exercise

Takashi Masuda — Sun, 23 Aug 2026 11:11:28 +0000

I bought it on Kindle on February 20, 2026, and finished reading it on July 19. It took me quite a while.

I'd used ECS before, but I'd never built anything from scratch with it at work. Since it looks like I'll be working with ECS soon, and my last hands-on experience was a long time ago, I picked this up to catch up on the current state of things. The fact that it comes with hands-on exercises was another deciding factor.

How the Book Is Organized

It's 656 pages. Here's the table of contents:

Chapter 1 Overview of containers
Chapter 2 AWS fundamentals needed for container design
Chapter 3 Basic AWS architecture design
Chapter 4 Container design centered on ECS/Fargate
Chapter 5 Building an AWS container architecture (basics)
Chapter 6 Building an AWS container architecture (practice)

Chapters 1-4 are the design theory, and Chapters 5-6 are the hands-on part. You start actually typing at page 301, so roughly half the book by page count is hands-on.

The Hands-On Part

The hands-on exercises use four repositories:

You build a pet shop visit reservation app out of three containers: frontend, backend, and batch.

Here's roughly what Chapter 5 (the basics) covers:

Create the VPC-related resources with a CloudFormation template
Build the frontend and backend Docker images and push them to ECR
Create two target groups for Blue/Green deployment and set up an ALB
Create the ECS task definitions, cluster, and service
Create an Aurora PostgreSQL instance and pass the credentials to the containers as environment variables via Secrets Manager
Build a CI/CD pipeline with CodeConnections, CodeBuild, and CodePipeline

The book has you spin up an EC2 instance for development and work from there, but I built everything from my local macOS instead. That caused no real problems, though the load testing with k6 looked like a hassle to run from my local machine, so I created an EC2 instance just for that.

Chapter 6 (the practical part) is where you add the things you actually need in production.

Add a FireLens (Fluent Bit) sidecar container and ship logs to S3
Add an ADOT Collector sidecar container and do distributed tracing with X-Ray
Build batch processing with Step Functions and EventBridge Scheduler
Run load tests with k6 and watch Auto Scaling in action
Migrate service-to-service communication from Cloud Map service discovery to ECS Service Connect
Inject SIGKILL into the backend process with FIS and confirm automatic recovery
Enable GuardDuty's ECS Runtime Monitoring

Once you've got CodePipeline in place, pushing to the v2 branch of your forked frontend repository is all it takes to trigger a deployment. Getting this far is genuinely satisfying — you've got something that actually looks like the real thing 🎉

Keeping Costs Down

Cost was what I worried about most during these exercises. Here's what I was actually billed:

Month	Amount
June 2026	USD 16.62
July 2026	USD 82.34

The biggest cost was interface VPC endpoints. I left them running for a few days to see how much they'd add up to, and the bill climbed fast enough that I deleted them right away.

Lesson learned. From then on, I turned the following into a set of commands to run whenever I paused the exercises:

Stop the Aurora PostgreSQL cluster (note that it starts automatically after at most 7 days)
Delete the VPC endpoints along with their entire CloudFormation stack
Set the ECS service's desired count to 0

Resuming is the reverse. I also set up a budget alert.

Creating a Dedicated AWS Account for the Hands-On

Backing up a bit: every resource I created would be unnecessary once the exercises were done. So I enabled AWS Organizations beforehand and created a dedicated AWS account for the hands-on.

I've used AWS Organizations at work, but I'd never set it up as an administrator, so it was a good opportunity to understand it — IAM Identity Center included.

A Few Places I Got Stuck

There were three.

The first was the frontend's log group. The book says to "remove awslogs-create-group," but when I did, the log group was never created and deployments kept failing. I ended up creating the log group by hand. The backend's log group appears to be created by the CloudFormation template.

The second was CodeBuild triggering twice. After making the ECR tags immutable, CodeBuild started failing. Builds were being triggered by both the GitHub webhook and CodeBuild itself, so it was trying to push the same tag twice. Disabling the webhook fixed it.

The third was the EventBridge UI. The book has you create things from "Buses > Rules," but these days you need to use "Scheduler > Schedules."

Conclusion

It took me five months, but I now have a feel for building things end to end on ECS. Clicking through the settings in the AWS console should also pay off later when I write the Terraform.

This revised and expanded edition came out on January 30, 2026, so it covers recent topics like ECS Managed Instances and ECS Service Connect. I think it's a good book for anyone about to start working with ECS.

One thing to note: the Kindle edition is a fixed-layout book, so you can't highlight or take notes in it. I kept my reading notes in a private GitHub Discussion instead, and they piled up quite a bit. This post is a summary of them.

I hope this helps someone.

Reading Notes

Below are my personal notes.

P46. ECS Managed Instances

The data plane now has one more option:

EC2
Fargate
ECS Managed Instances

ECS Managed Instances was announced on September 30, 2025, and the official AWS documentation recommends it over Fargate¹. It's based on Bottlerocket, and since a new instance launches and replaces the old one every 14 days, ECS tasks need to be cycled regularly too.

Note: the book's hands-on exercises use Fargate.

P54. AWS Copilot Has Moved to Maintenance Mode

AWS Copilot is introduced as a tool for simplifying the use of ECS and App Runner, but when I looked it up, end of support had already been announced.

ecspresso is a similar tool. Where AWS Copilot lets you work without thinking about the infrastructure, ecspresso apparently assumes users who understand the infrastructure deeply.

I've been curious about ecspresso for a while, so I plan to give it a try.

P111. Connectivity Options Between ECS Services

Chapter 2 compares three approaches.

Service discovery with Cloud Map
- The simplest option. Relatively easy to operate if you're doing rolling updates
Private ALB/NLB integration
- Useful when you want authentication between services or a sorry page. Naturally, you pay for the ALB/NLB
ECS Service Connect
- A proxy container is automatically injected as a sidecar, controlling traffic, logs, and metrics between services
- Connecting from ECS services running in a different VPC works out of the box

Cloud Map looks like the call if rolling updates are enough; the other two if you need Blue/Green deployment or metrics.

Note: the hands-on starts with Cloud Map and migrates to ECS Service Connect on page 585.

P135. FireLens

Besides CloudWatch Logs (awslogs), there's FireLens for collecting container logs. So this is the thing that uses Fluent Bit — that finally clicked for me.

You can forward to CloudWatch Logs and then send to S3, but that runs up the bill, so FireLens is apparently the better choice.

On a side note, CloudWatch Logs announced intelligent tiering for storage on July 15. It automatically sorts logs into three tiers — Standard, Infrequent Access, and Archive Instant Access — based on access patterns. I should factor this into my logging strategy too.

🔗 Amazon CloudWatch Logs announces intelligent tiering for storage - AWS

P214. Secrets Manager vs. SSM Parameter Store SecureString

I'd never really understood when to use which, so the explanation was a big help.

The rule of thumb: use Secrets Manager if you need automatic rotation, and SSM Parameter Store SecureString if you don't.

P250. Fault Testing with AWS FIS

FIS (Fault Injection Service), AWS's chaos engineering service, lets you deliberately inject faults to verify a system's resilience.

In the hands-on on page 594, I sent SIGKILL to the backend to force-kill the process, then confirmed it recovered automatically. All you do is create an experiment template and hit "Start experiment," so it was easier than I expected.

P623. GuardDuty's ECS Runtime Monitoring

Just enabling Runtime Monitoring (ECS) from the GuardDuty console automatically launches an agent sidecar in each task.

I tried it out by getting into the backend container with ECS Exec and running nslookup against a cryptocurrency mining pool service — and it was properly flagged as a threat. If that's what you get from simply turning it on, there's little reason not to.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html ↩

Switching from the Mac port Build of Emacs to the Standard NS Build

Takashi Masuda — Sun, 21 Jun 2026 03:34:35 +0000

For a long time I'd been using railwaycat/homebrew-emacsmacport, a build of Emacs with the Mac port patches applied.

railwaycat / homebrew-emacsmacport

Emacs mac port formulae for the Homebrew package manager

Why I Switched to the NS Build

Over the past few years, though, I'd been feeling the following pain points.

The Mac port hasn't kept up with the latest Emacs
- The current latest Emacs is 30.2, but the Mac port only supports 29.4
With the latest railwaycat/homebrew-emacsmacport release, emacs-29.4-mac-10.1, I ran into the problem in issue #389 on my setup, so I'd been sticking with the previous emacs-29.1-mac-10.0
Ideally, I'd like to use the latest Emacs

The only reason I used the Mac port build in the first place was to automatically turn off Japanese input when I hit M-x and the like, then restore it to its original state afterward. Here's the configuration.

As long as I could reproduce this behavior, I'd be able to switch to the standard NS build. This time, that finally happened.

By the way, NS stands for NeXTSTEP, which on macOS refers to the GUI build that uses Cocoa (AppKit).

I Found That sis Could Solve It

After looking into it, I found that emacs-smart-input-source (hereafter "sis") could reproduce what I'd been doing with the Mac port build.

laishulu / emacs-smart-input-source

Minimize manual input source (input method) switching.

On macOS, sis uses a CLI called macism as the backend for switching input sources. It's by @laishulu, the same author as sis.

laishulu / macism

Reliable CLI MacOS Input Source Manager [MacOS上可靠切换输入法的命令行工具]

Installing the NS Build of Emacs

First, I installed the build from emacsformacosx.com via Homebrew.

$ brew install --cask emacs-app

Configuring sis Solved It

Installing macism

I installed macism via Homebrew.

$ brew install laishulu/homebrew/macism

macism can switch input sources from the command line on its own, like this.

# Set the input source to "ABC"
$ macism com.apple.keylayout.ABC

# Set the input source to Google Japanese Input's "あ"
$ macism com.google.inputmethod.Japanese.base

Configuring sis

This is all I configured.

;; When moving the cursor to the minibuffer, automatically switch to English mode,
;; and restore the Japanese input state after returning to the original buffer.
(sis-ism-lazyman-config
 "com.apple.keylayout.ABC"               ;; ABC
 "com.google.inputmethod.Japanese.base") ;; Google Japanese Input
(sis-global-respect-mode 1)

;; Switch the cursor color to match the input mode.
(sis-global-cursor-color-mode 1)

sis-global-respect-mode switches to English input when you move to the minibuffer with M-x and the like, and restores the Japanese input state when you return to the original buffer. This is exactly what I'd been doing with the Mac port build.

With that, sis solved it without any issues, and I successfully switched to the standard NS build.

Conclusion

I was able to switch from the Mac port build I'd used for years to the standard NS build. I'm glad I could solve the input source switching on M-x, which was my one and biggest pain point.

Compared to the Mac port build, there's nothing in particular that feels inconvenient.

I can now keep up with the latest Emacs. Emacs 30 feels faster when it comes to networking. You can really tell when using navi2ch(!).

I hope this helps someone.

Appendix

Switching Input Sources by Context with sis-global-context-mode

sis also has sis-global-context-mode, which looks at the characters around the cursor (the context) and switches the input source automatically.

(sis-global-context-mode 1)

For example, when you "write Japanese → edit somewhere else → return to the original spot and keep writing," it switches to Japanese input if you land mid-Japanese, or to English if you land mid-English. It determines whether the characters before and after the cursor are Japanese or English, and only switches when it can make that determination, so there are few false triggers.

That said, the default for sis-context-hooks, which decides when it fires, is '(evil-insert-state-entry-hook), which assumes evil. If you don't use evil, this hook never gets called and it won't work, so you'll need to add hooks that match your own workflow.

If sis-global-respect-mode (switching to English on M-x and back) is enough for you, I don't think you need to force this one on.

Mixing English Words into Japanese with sis-global-inline-mode

sis also has sis-global-inline-mode, which is handy when you want to mix English words into the middle of Japanese text.

(sis-global-inline-mode 1)

For example, when you want to write 日本語 some english text 日本語, you just type 日本語<space>some english text<space><RET>日本語. The moment you put a space right after the Japanese, it automatically switches to English input just for that spot (highlighted with an overlay), and a trailing space, RET, or moving the cursor outside the region returns you to Japanese input. There's no need to switch the IME manually.

By default, only "English within Japanese" is handled (sis-inline-with-english). If you also want "Japanese within English," add (setq sis-inline-with-other t).

Whereas sis-global-respect-mode / sis-global-context-mode handle "switching" the input source, this one creates a temporary English region on the spot — that's the difference.

I tried it for a day, but of course this behavior only applies inside Emacs, so character input behaves differently between Emacs and everything else. That subtle inconsistency was disorienting, so I stopped using it. Another reason is that even within Emacs, it didn't turn out to be all that intuitive.

Addendum (2026-06-25): There's a Mac port build of Emacs 30.2

I was tipped off via Mastodon. I was already aware of jdtsmith/emacs-mac, but since I prefer to keep customization to a minimum, since I prefer to keep customization to a minimum, it seemed like the right opportunity to make the move to the standard NS build.

hmelman: "@masutaka@mstdn.love Glad that's working for you.…" - Mastodon

@masutaka@mstdn.love Glad that's working for you. FWIW I've been using this fork of emacs-mac and it's been working fine for me. I'm now using the master branch (on Tahoe) so it's close to emacs 31. https://github.com/jdtsmith/emacs-mac

mastodon.social

I also received — for the first time! — a comment through the [ Send Message ] form at the bottom of the page, with the same content. Thank you! 😄

It seems there are quite a few people using the Mac port build. I can understand folks in language regions that need an Input Method — but I'm curious what benefits the Mac port build offers to those who don't.

Making Codex CLI and Codex.app Use mise-managed Ruby and Node.js

Takashi Masuda — Sat, 30 May 2026 12:43:18 +0000

I mostly use Claude Code, but lately I've been using Codex CLI and Codex.app (hereafter "Codex") more often too. My environment is macOS.

However, after I started using mise in [2026-03-29-1], I ran into trouble because Codex wouldn't use the mise-managed Ruby, Node.js, and so on.

Here's the state I was in:

$ where ruby
/usr/bin/ruby

$ ruby --version
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]

The Solution

I solved it by adding the following to ~/.zshenv:

# When Codex CLI and Codex.app run commands, .zshrc's mise activate zsh doesn't take effect,
# so add mise shims to PATH.
if [ -n "$CODEX_SANDBOX" ]; then
  PATH=${XDG_DATA_HOME}/mise/shims:$PATH
fi

Here's the state inside Codex after the change:

$ where ruby
/Users/masutaka/.local/share/mise/shims/ruby
/usr/bin/ruby

$ ruby --version
ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [arm64-darwin25]

Codex's Command Execution Environment Is a Sandbox

I'd vaguely suspected this for a while, but it seems Codex's command execution environment runs inside a sandbox.

You can spot the clues from within Codex:

$ env | grep CODEX
CODEX_CI=1
CODEX_SANDBOX=seatbelt
CODEX_THREAD_ID=019e7806-6025-7c13-a3c6-a70d41c13905

"seatbelt" refers to Apple Seatbelt, which appears to be macOS's sandboxing mechanism.

🔗 macOSで手軽にSandbox環境を構築できるApple Seatbeltの実践ガイド

しかしながら、Apple Seatbeltは公式にドキュメントを公開されておらず、非推奨とされています。一方で実際には多くのアプリケーションやツールで使用されています。

(English translation) However, Apple Seatbelt has no officially published documentation and is considered deprecated. Yet in practice, it's used by many applications and tools.

I see...

According to this article, Claude Code also adopts Apple Seatbelt, and I confirmed that it can be enabled with /sandbox (see the official documentation).

Coming from a background of being used to Claude Code, Codex's sandbox is hard to wrap my head around, but the following article covers it in detail. Much appreciated.

🔗 [Codex] sandbox実行の仕組みと設定方法を完全に理解する

Codex also seems to restrict network access by default. Come to think of it, I remembered that I'd previously set the following in ~/.codex/config.toml:

[sandbox_workspace_write]
network_access = true

The Road to the Solution

At first I tried to solve it with a setting like this in ~/.codex/config.toml, but it didn't work:

[shell_environment_policy.set]
PATH = "/Users/masutaka/.local/share/mise/shims/ruby:(the existing PATH settings hardcoded here)"

As I dug deeper, it occurred to me: "Doesn't ~/.zshenv get loaded every time, even inside the sandbox? If Codex-related environment variables are defined, I should be able to handle it in ~/.zshenv." That led me to the solution.

The reason eval "$(mise activate zsh)" in ~/.zshrc doesn't take effect is that ~/.zshrc is only loaded for interactive shells. Codex appears to run commands in non-interactive shells, so the settings in ~/.zshenv, which is loaded every time zsh starts, are what take effect.

I also came up with the idea of moving eval "$(mise activate zsh)" itself into ~/.zshenv, and it did actually work. However, I think this isn't a good approach. The activate PATH method is a mechanism that updates environment variables every time the prompt is displayed, so using it in a non-interactive shell with no prompt falls outside its intended purpose.

mise also recommends shims for non-interactive environments (scripts, IDEs, CI), so I followed that here. It's the same approach of adding shims to PATH that I adopted for Emacs in [2026-03-29-1].

I wanted to avoid hardcoding PATH into ~/.codex/config.toml since that would mean duplicate management with ~/.zshenv, so I'm glad it settled into a clean form.

Conclusion

I summarized how to make Codex CLI and Codex.app use mise-managed Ruby and Node.js.

I think mise is gradually gaining adoption, but I couldn't find an answer by Googling and wondered how everyone else handles this, so I wrote this short article. I hope it helps someone.

[2026-04] How I Currently Use Claude Code

Takashi Masuda — Sun, 12 Apr 2026 13:27:22 +0000

Here's a summary of how I currently use Claude Code.

I previously introduced a Claude Code book in [2026-01-16-1], but this time I'll write about my own workflow.

Development Environment

I work on my MacBook's built-in display. I'm not really someone who uses external monitors.

I display the macOS built-in Terminal.app in full screen and use tmux. I don't split tmux windows—instead, I switch between tabs (windows). I haven't (yet?) switched to Ghostty or iTerm2.

My editor is Emacs. Before Claude Code came along, I had tried switching to VSCode several times and given up each time, but now I no longer need to think about it. What a relief.

On a related note, Emacs's global-auto-revert-mode is really handy. When Claude Code edits a file that's open in Emacs, the buffer automatically refreshes. Here's my configuration.

For the Claude Code model, I use Opus 4.6 (1M context) both personally and at work. I basically don't use Sonnet. My personal Claude plan alternates between Pro and Max, and on Max I get the 1M context.

Workflow

I follow a 3-step workflow starting from GitHub Issues.

1. Creating a Work Plan

The starting point is a custom skill (slash command) called /create-plan-for-gh-issue.

It creates a work plan as a Markdown file based on the content of a GitHub Issue. The Issue can be for creating a PR, doing research, or anything else.

The key is to write the necessary information in the Issue. It can go in the description or comments, and it's fine if the content is messy. It also reads attached images.

After generating the plan, I go back and forth a few times to refine it.

2. Reviewing the Work Plan

I have a separate Claude Code session review the plan. When I'm unsure, I also have Codex review it.

I don't use Codex directly very often—instead, I use it through a custom skill called /codex-discuss.

💡 /codex-discuss will start a discussion on whatever you pass as an argument, and even without arguments, it figures out what to discuss on its own. When it's unclear what to discuss, it asks the user. I find it valuable for getting a third-party perspective, though the downside is that it's slow...

Since the plan is a Markdown file, it's easy to review, and there's no problem even if the work carries over into the next week.

Once the plan is finalized, I paste it as a comment on the GitHub Issue for record-keeping. I used to commit plans to docs/plans/ in the repository, but stopped because deleted filenames would show up in grep results as noise, and it just didn't feel right.

3. Executing and Reviewing the Work

Plans are typically divided into Phases, with each Phase expected to result in a commit.

For now, git operations are done manually by me. For suggesting commit messages, a custom skill called /suggest-commit-message has been very useful.

Before requesting a PR review, I run /review in a separate Claude Code session, and if I'm still unsure, I discuss it with /codex-discuss.

I also tried openai/codex-plugin-cc, but it didn't quite fit my style.

Additionally, for reviewing PRs from Dependabot, /review-dependabot-pr has been very handy.

Conclusion

I've summarized how I use Claude Code as of April 2026.

I try not to over-customize Claude Code. Looking at Twitter, it seems like everyone is doing advanced things, but I try not to be too influenced and instead trust my own intuition.

The Claude Code configurations I introduced above are all gathered in the following dotfiles-public repository.

masutaka / dotfiles-public

masutaka public dot files

I'll continue to refine my setup going forward, and I'm also planning to try out Codex.app, which has been getting good reviews.

Gleanings

Answering Yes/No Questions from Claude Code with y/n

When Claude Code asks a Yes/No question, y or n is sufficient. It's a small thing, but it helps reduce token usage.

Interview-Style Hearings from Claude Code

When the task at hand is vague, having Claude Code conduct an "interview-style" hearing helps organize your thoughts.

When there isn't enough information, Claude Code autonomously asks questions.

I have the line "Use the AskUserQuestion tool when asking the user for choices or decisions" in my ~/.claude/CLAUDE.md.

Keep Claude Code Sessions Short

I try not to extend Claude Code sessions too long, even when there's room left in the context window. My experience is that noise from intermediate steps creeps in and things start to go a bit off.

By the way, I monitor the current context window (cw) usage via the Claude Code status line.

Here's the configuration for the status line above:

Notification Settings from Claude Code

To avoid missing when Claude Code finishes processing, I have a setup that sends notifications to both the tmux status line and the macOS Notification Center.

An article by Yoshida-san, a former colleague, was very helpful.

Reliably Detecting "My Turn" in Claude Code - Zenn

Yoshida-san's article explains in detail how spinner display and unread markers work. My setup is based on that, with the following adjustments:

Common:
- Added a Notification hook so I can be alerted by tmux's unread marker and a notification sound even during idle states like waiting for tool approval
tmux:
- Added a SessionEnd hook to clean up the spinner, fixing the issue where the spinner kept spinning after exiting with /exit or C-c C-c
- Introduced a heartbeat file that monitors mtime as a TTL, so the spinner also auto-stops when interrupted with Esc
- Changed the unread indicator dot color from red to cyan, as cyan looks more like an "unread" marker
macOS Notification Center:
- Used different sounds for Notification (Funk) and Stop (Glass), so I can distinguish "attention needed" from "completed" by ear
- Added (tmux:N) with the window number in the notification body, so I know which window to switch back to

Here's the actual code:

~/.claude/settings.json#L53-L122 (hooks configuration)
~/.claude/scripts/tmux-spinner.sh
~/.claude/scripts/macos-notify.sh
~/.config/tmux/tmux.conf#L22-L32

Migrating from asdf and direnv to mise

Takashi Masuda — Sun, 29 Mar 2026 09:27:47 +0000

For managing versions of development tools like Ruby and Node.js, I had gone through *env tools like rbenv and nodenv, then switched to asdf in 2019. For environment variable management, I had been using direnv since even earlier—2014.

Recently, a tool called mise has been gaining attention. I wasn't particularly having issues, but out of curiosity and the motivation to reduce the number of tools—since I heard mise also has direnv-like functionality—I decided to make the switch. My environment is macOS.

jdx / mise

dev tools, env vars, task runner

What is mise?

mise (pronounced "meez") is a tool that handles both development tool version management and environment variable management in one place. It provides asdf-compatible runtime management along with direnv-equivalent environment variable management.

Here are the notable features I found after using it:

Can read .tool-versions (.ruby-version etc. requires configuration, described later)
Can define environment variables and task runners in mise.toml
- The official mise.toml may be a good reference
Supports mise.local.toml for local settings meant to be gitignored. This allows individual adoption even before a team officially adopts mise
Well-organized tool management experience
- mise install installs all tools from .tool-versions in one command
- mise list shows all tool versions and their source files at a glance

What I Did for the Migration

The official documentation has a migration guide from asdf, so start there. Below are the specific steps for my environment.

1. Homebrew Package Changes

I uninstalled asdf and direnv, and installed mise.

$ brew uninstall --force asdf
$ brew uninstall --force direnv
$ brew install mise

2. zsh Configuration Changes

I removed all asdf settings from ~/.zshenv.

-MY_ASDF_CONFIG_HOME="${XDG_CONFIG_HOME}/asdf"
-export ASDF_CONFIG_FILE="${MY_ASDF_CONFIG_HOME}/asdfrc"
-export ASDF_DATA_DIR="${XDG_DATA_HOME}/asdf"
-export ASDF_GEM_DEFAULT_PACKAGES_FILE="${MY_ASDF_CONFIG_HOME}/default-gems"
-export ASDF_NPM_DEFAULT_PACKAGES_FILE="${MY_ASDF_CONFIG_HOME}/default-npm-packages"
-export ASDF_PERL_DEFAULT_PACKAGES_FILE="${MY_ASDF_CONFIG_HOME}/default-perl-modules"
-export ASDF_PYTHON_DEFAULT_PACKAGES_FILE="${MY_ASDF_CONFIG_HOME}/default-python-packages"
-export ASDF_RUBY_BUILD_VERSION=master
-PATH=$ASDF_DATA_DIR/shims:$PATH

I also removed the direnv settings from ~/.zshrc.

-eval "$(direnv hook zsh)"

Instead, I added the mise configuration to ~/.zshrc. Since the activation mechanism enabled by this setting handles PATH management, no configuration in ~/.zshenv is needed.

eval "$(mise activate zsh)"

Here are the actual files:

~/.zshenv (no mise settings)
~/.zshrc

With the asdf-era environment variables gone, my zsh configuration became cleaner.

3. Installing Tools

I reinstalled the tools that asdf had been managing using mise install.

$ cat ~/.tool-versions
nodejs 24.14.0
ruby 4.0.2

$ mise install

$ mise list
Tool       Version   Source            Requested
node       24.14.0   ~/.tool-versions  24.14.0
ruby       4.0.2     ~/.tool-versions  4.0.2

4. Migrating default_packages_file

With asdf, I managed default_packages_file via environment variables in ~/.zshenv. With mise, I consolidated them in ~/.config/mise/config.toml.

[settings.node]
default_packages_file = "~/.config/mise/default-npm-packages"

[settings.ruby]
default_packages_file = "~/.config/mise/default-gems"

During the migration, I discovered a bug where ~ in Node.js's default_packages_file wasn't being expanded, causing default packages not to be installed. I reported it in Discussion#8606, and it was fixed in PR #8709 🙏 This is resolved in v2026.3.11 and later.

5. Configuring .ruby-version and .node-version Support

Neither asdf nor mise reads .ruby-version or .node-version by default. With asdf, you set legacy_version_file = yes in asdfrc, but with mise, the following configuration is needed. I added it to the repository's mise.toml or mise.local.toml.

[settings]
idiomatic_version_file_enable_tools = ["node", "ruby"]

What I Didn't Migrate

Some settings were either unnecessary to migrate or I chose not to migrate.

Ruby pre-install hook
- With asdf, I set RUBY_CONFIGURE_OPTS via pre_asdf_install_ruby, but this turned out to be unnecessary with mise
ASDF_RUBY_BUILD_VERSION=master
- mise automatically fetches the latest version of ruby-build when installing Ruby, so this setting is unnecessary
Perl default-perl-modules
- mise doesn't support default_packages_file for Perl (see the appendix below for a workaround)
direnvrc PATH_add
- I had a configuration to automatically add ./bin to PATH for Ruby projects with a Gemfile.lock
- mise doesn't have an equivalent global feature, but I decided to configure it per-project in mise.toml when needed
```
[env]
_.path = "./bin"
```

Conclusion

I replaced two tools—asdf + direnv—with just mise. The zsh configuration became cleaner, and being able to consolidate tool versions and environment variables in mise.toml is a nice benefit.

There were some gotchas like the Emacs compatibility issue described in the appendix below, but overall I'm happy with the migration.

Also, with direnv no longer needed, I was able to migrate from .envrc to .env, which later enabled me to set up .env mounting with 1Password Environments.

References

Appendix

Fixing ruby-lsp Not Working in Emacs

I encountered an issue where ruby-lsp wouldn't work in Emacs for repositories using a Ruby version different from the global one.

mise activate zsh takes a hook-based approach, using zsh's chpwd hook to switch tool versions when changing directories. However, Emacs doesn't execute this hook, so mise's version switching doesn't work.

mise offers an alternative to hook-based activation called shims.

	activate	shims
Best for	Interactive shell	Non-interactive (IDE, Emacs, scripts)
Hooks like `cd`	Triggered	Not triggered
`which` result	Returns the actual tool path	Returns the shim path

Initially, I added eval "$(mise activate zsh --shims)" to ~/.zshrc to enable both, but the mise documentation assumes activate and shims are mutually exclusive.

I ultimately settled on the following setup:

eval "$(mise activate zsh)" in ~/.zshrc (for interactive shell)
Add the shims directory to PATH only when launching Emacs

alias emacs="LC_COLLATE=C PATH='${XDG_DATA_HOME}/mise/shims:$PATH' emacs"

This creates a separation of concerns: regular zsh sessions use hooks only, while Emacs uses shims.

Compared to asdf's simpler shims-only design, this setup might look more complex at first glance. However, I understand this is a tradeoff stemming from mise being a replacement for both asdf and direnv. The real-time reflection of environment variable changes in the interactive shell via mise activate is something shims alone cannot achieve.

Workaround for Perl default-packages

mise's default-packages mechanism is a language-specific feature hardcoded in core plugins (Go, Node.js, Python, Ruby). Perl is not a core plugin—it's installed via the Aqua backend—so it's not covered.

As a workaround, you can run cpanm in mise.toml's [hooks] postinstall¹. This way, mise install alone sets up both Perl and CPAN modules.

[settings]
experimental = true

[hooks]
postinstall = "cpanm CGI HTML::Template"

Note that hooks is an experimental feature, so experimental = true is required. Also, postinstall runs on every tool installation, not just Perl, so this hook will be triggered every time you run mise install.

Update: 2026-06-21

Later, in mise v2026.6.6, hooks graduated from experimental, so experimental = true is no longer required. You can omit the [settings] section above.

The Relationship Between mise and aqua

aqua is a tool specialized in version management for CLI tools (terraform, gh, etc.), with robust security through checksum verification. While mise and aqua cover different scopes, mise can use aqua-registry as a backend (via the aqua: prefix), allowing you to install tools managed by aqua through mise.

They're not identical, but for personal dotfiles management, I feel mise alone can sufficiently cover aqua-like use cases. If your team uses aqua or you need checksum verification for supply chain security in CI/CD, there's still value in using aqua separately.

Hooks | mise-en-place ↩

Created a GitHub Actions Reusable Workflows Repository for Personal Use

Takashi Masuda — Mon, 23 Feb 2026 10:00:48 +0000

I created a GitHub Actions Reusable Workflows repository for my personal use.

masutaka / actions

GitHub Actions reusable workflows

What Are GitHub Actions Reusable Workflows?

GitHub Actions' reusable workflows is a mechanism that allows workflow files to be called from other repositories.

For example, you can call a workflow from another repository like this:

jobs:
  example:
    uses: masutaka/actions/.github/workflows/some-workflow.yml@main

Since you can consolidate common processes in one place, it saves you the trouble of managing the same workflow across multiple repositories.

There are some limitations and caveats to be aware of:

Reusable workflows in private repositories cannot be called from public repositories
Reusable workflows in private repositories can only be called from other repositories within the same org/user (different orgs are not allowed, and the Access policy setting of the called repository must be configured)
The env context at the calling workflow level is not propagated to the called workflow
Environment secrets cannot be passed (only regular secrets can be passed via secrets: inherit)
Reusable workflows always run at the job level (they cannot be used as steps). This means a separate runner starts each time they are called, and the filesystem cannot be shared between jobs. For private repositories, this also increases Actions minutes consumption. If you want to reuse at the step level, you need to use a composite action

Since masutaka/actions is a public repository, limitations 1 and 2 do not apply.

Included Workflows

Currently, I have included the following reusable workflows:

add_assignee_to_pr.yml (docs) - Sets the PR creator as the assignee when a PR is created
codeql.yml (docs) - Detects languages from changed files and runs CodeQL analysis
codeql_core.yml (docs) - Runs CodeQL analysis for specified languages
create_gh_issue.yml (docs) - Creates a GitHub Issue from a template
dependency_review.yml (docs) - Reviews PR dependencies
pushover.yml (docs) - Sends Pushover¹ notifications for workflow failures

I referenced mdn/workflows for the documentation structure, documenting each workflow's usage in Markdown files under docs/ and linking to them from README.md.

Why I Created This

I had been using route06/actions, a repository where I had been a maintainer at my previous job, even after leaving the company.

However, there were a few things I wanted to customize for personal use, and creating a new pushover.yml workflow prompted me to copy the necessary workflow files and create my own repository.

Up until then, the same pushover.yml file was duplicated across my personal repositories, but I took this opportunity to consolidate everything into masutaka/actions.

Handling Licenses

Both repositories are under the MIT License. For workflow files copied over, I added attribution to the original repository at the top of each file like this:

Example: codeql.yml:

# Derived from https://github.com/route06/actions/blob/main/.github/workflows/codeql.yml
# Copyright (c) 2024 ROUTE06, Inc.
# Licensed under the MIT License.

I also included both copyrights in the LICENSE file. I believe this satisfies the requirements of the MIT License.

Copyright (c) Takashi Masuda
Copyright (c) 2024 ROUTE06, Inc.

Conclusion

Until now, similar workflow files were scattered across my personal repositories, and I had to update multiple repositories every time a change was needed. By consolidating them into masutaka/actions, changes can now be made in one place.

As my personal repositories continue to grow, I plan to keep consolidating shareable workflows here going forward.

References

A push notification service for iOS/Android ↩

Created a Rails 8 Learning Repository and Started Recovering from a 6-Year Blank with Rails Guides and Claude Code

Takashi Masuda — Tue, 30 Dec 2025 05:17:38 +0000

Last month I changed jobs and returned to Rails development after a long time.

With a 6-year gap and only one month available for learning, I needed to efficiently grasp Rails 8's new features and refresh my memory of existing ones.

So I decided to learn by building a working app together with Claude Code while referencing the Rails Guides. I temporarily subscribed to Claude Code's Max plan at USD 100/mo.

Here's the repository I created:

masutaka / trial-rails8

Rails ガイドを元にした素振り

Learning Process

I used the Rails Guides as my main reference material.

1. Reviewing the Basics with Rails Guides

Following Getting Started with Rails, I created /products. I mainly learned about Active Storage (image uploads) and Action Text (rich text).

2. Learning Hotwire and Solid Trifecta

To learn Hotwire and Solid Trifecta, I created /chat and /posts.

/chat: Learned Action Cable, Solid Cable, and Stimulus
/posts: Learned Turbo Streams/Frames, Active Job, and Solid Queue. Added comment, follow, and notification features to a typical blog functionality

I learned through AI pair programming with Claude Code. The specific workflow was as follows:

Create a GitHub Issue (e.g., #14 Follow Feature)
Have Claude Code create a plan document (e.g., docs/plan-for-issue-14.md)
Have it create a PR based on the plan while understanding the implementation (e.g., #38)

I also utilized AI reviews from CodeRabbit. It pointed out N+1 queries and suggested adding tests, allowing me to maintain quality even in solo development. It's great that it's free for OSS.

Rails Features I Learned

Hotwire

Hotwire is a framework introduced in Rails 7 for achieving SPA-like UX. Hotwire consists of Turbo and Stimulus.

Turbo is further composed of three parts:

Turbo Drive: Speeds up page transitions (fetches and replaces HTML on link clicks)
Turbo Frames: Updates parts of a page (inline editing of comments, etc.)
Turbo Streams: Updates multiple locations simultaneously (updates list and count when adding comments)

Stimulus is a JavaScript framework, but it's a very thin layer for adding minimal JS with HTML as the starting point. I used it for UI control in the chat feature.

I utilized Turbo Streams in the comment feature. When a comment is posted, model callbacks broadcast it to other users' browsers in real-time.

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post, counter_cache: true
  belongs_to :user

  after_create_commit do
    # Append to comment list
    broadcast_append_to post,
                        target: "comments",
                        partial: "comments/comment",
                        locals: { comment: self, allow_actions: false }
    # Update comment count
    broadcast_replace_to post,
                         target: "comment_count_#{post.id}",
                         partial: "posts/comment_count",
                         locals: { post: post }
  end
end

Solid Trifecta

"Solid Trifecta" introduced in Rails 8 eliminates the need for external middleware like Redis or Memcached.

Solid Queue: Database-based Active Job backend
Solid Cable: Database-based Action Cable adapter
Solid Cache: Database-based cache store (not used this time)

I used Active Job + Solid Queue for the scheduled post feature. When you set a future datetime for published_at, a job executes at that time to publish the article.

# app/jobs/publish_post_job.rb
class PublishPostJob < ApplicationJob
  queue_as :default

  def perform(post_id, scheduled_at)
    post = Post.find_by(id: post_id)
    return unless post

    # Idempotency: Skip if already published
    return if post.published

    # Skip if publish datetime was changed
    return if post.published_at.blank? || post.published_at.to_i != scheduled_at

    post.update!(published: true)
  end
end

You can check job execution status with Mission Control Jobs. Access http://localhost:3000/jobs in development to view job history and queue status in a Web UI.

Other Features

Eager Loading: includes/preload/eager_load to prevent N+1 queries
has_secure_password + rate_limit: User authentication and rate limiting
Counter Cache: Efficient retrieval of comment counts (belongs_to :post, counter_cache: true)
Foreign key constraint on_delete: :cascade: Automatically deletes child records when parent is deleted. Used alongside Rails' dependent: :destroy to maintain DB-level integrity
Shallow Routing: Specifying shallow: true for nested resources shortens URLs for member actions (show/edit/update/destroy)
Polymorphic Association: Used for notification feature. Manages follow and comment notifications uniformly
Self-Referential Association: Used for follow feature. Expresses many-to-many relationships with a single follows table

Conclusion

Despite a 6-year gap, I was able to learn efficiently with Rails Guides and Claude Code.

Note that I didn't write many tests this time. The goal was to learn Rails features, so I'll save test learning for another time.

My mental model was stuck around the time of "temporarily disabling Turbolinks...", so I was quite impressed by Hotwire's ability to achieve SPA-like UX with almost no JavaScript. My memory of Rails was that it often served as an API server or adopted React for the frontend, but I now think Hotwire should be considered first.

Solid Queue and Solid Cable are also nice because you can start with just RDS, reducing the number of components.

I'll continue working through the open Issues while continuing to learn.

References

Finally Modernized My Emacs Setup with LSP + Tree-sitter

Takashi Masuda — Mon, 24 Nov 2025 10:13:19 +0000

In recent years, I've been mainly writing LookML, SQL, HCL, and other languages, with fewer opportunities to write programming languages like Ruby. However, I've recently returned to Rails development this month.

So, I finally got around to setting up LSP (Language Server Protocol) in Emacs.

During this process, I also learned about Tree-sitter and configured it as well.

※ LSP is an advanced code assistance mechanism provided by Language Servers, while Tree-sitter is a parsing engine that quickly generates AST from code to enable highlighting and structural editing.

Emacs Version I'm Using

I'm using Emacs 29.1 instead of the latest 30.2 for the following reasons:

I use railwaycat/homebrew-emacsmacport with Mac port patch
- I rely on some useful features provided by the Mac port patch
The latest Mac port patch is emacs-29.4-mac-10.1 and hasn't caught up to version 30
railwaycat/homebrew-emacsmacport@emacs-29.4-mac-10.1 with the patch has issue #389 on my environment
Therefore, I'm using railwaycat/homebrew-emacsmacport@emacs-29.1-mac-10.0

Introducing LSP

Adopted lsp-mode

I compared eglot, which is standard in Emacs 29, with the third-party lsp-mode.

I would have preferred to use the standard eglot, but I decided to adopt lsp-mode because there's information suggesting that Solargraph, which eglot requires as the Ruby Language Server, doesn't have good performance. lsp-mode requires ruby-lsp as the Language Server.

I haven't actually verified whether Solargraph really has poor performance 😅

lsp-mode Configuration Example

First, install the Language Server for each language in a PATH that Emacs recognizes (exec-path).

The correspondence between each language and Language Server is documented in Languages in the lsp-mode documentation.

Here are the Language Servers I installed this time:

Lang	Language Server
Dockerfile	dockerfile-language-server-nodejs
Go	gopls
JSON	vscode-json-languageserver
Ruby	ruby-lsp, ruby-lsp-rails
TypeScript	typescript-language-server

Next, install lsp-mode from Melpa.

Finally, just add the lsp-deferred function to the hook of the major-mode you want to enable.

Here's a configuration example for ruby-mode:

(add-hook 'ruby-mode-hook #'lsp-deferred)

With this, you can jump to definitions with M-. and return with M-,, and it also points out indentation issues. For other features, please see the lsp-mode documentation.

I also configured the following:

(setq lsp-keymap-prefix "C-c C-l")

;; Disable rubocop-ls so that ruby-lsp is prioritized even when rubocop is installed.
(setq lsp-disabled-clients '(rubocop-ls))

;; Format files on save for all buffers where lsp-mode is active.
(setq-default lsp-format-buffer-on-save t)

Discovered xxx-ts-mode Has Been Added to Emacs

When trying to configure lsp-mode for TypeScript, I noticed that xxx-ts-mode exists, which wasn't in previous versions of Emacs.

$ find /Applications/Emacs.app -type f -name '*-ts-mode.elc' | sort
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/c-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/cmake-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/dockerfile-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/go-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/java-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/json-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/ruby-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/rust-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/progmodes/typescript-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/textmodes/toml-ts-mode.elc
/Applications/Emacs.app/Contents/Resources/lisp/textmodes/yaml-ts-mode.elc

Unlike traditional xxx-mode which parses syntax using regular expressions, xxx-ts-mode parses syntax at the AST level using Tree-sitter. Therefore, syntax highlighting is more accurate, and indentation and structural editing are more stable.

I was about to skip it, but when I looked at typescript-mode's README.md, I learned that development has stopped:

Essentially all major development of typescript-mode has come to a halt.

So I decided to introduce xxx-ts-mode, starting with typescript-ts-mode. I also felt the benefit of being able to drop third-party xxx-mode packages.

Introducing typescript-ts-mode

You can install the Tree-sitter for TypeScript by adding the following to init.el:

(setq treesit-language-source-alist
      '((tsx "https://github.com/tree-sitter/tree-sitter-typescript" "v0.23.2" "tsx/src")
        (typescript "https://github.com/tree-sitter/tree-sitter-typescript" "v0.23.2" "typescript/src")))

(dolist (element treesit-language-source-alist)
  (let ((lang (car element)))
    (unless (treesit-language-available-p lang)
      (treesit-install-language-grammar lang))))

When this is evaluated, the *.dylib files built from source code fetched from GitHub will be installed directly under ~/.emacs.d/tree-sitter/.

libtree-sitter-tsx.dylib
libtree-sitter-typescript.dylib

💡 If you don't specify a tag, the default branch will be referenced. Since commit hash couldn't be specified, I specified tags from the perspective of security and version pinning.

Then, simply associate *.ts and *.tsx with typescript-ts-mode and tsx-ts-mode respectively. Also enable lsp-mode.

※ tsx-ts-mode is also defined in typescript-ts-mode.el.

;; TypeScript

(add-to-list 'auto-mode-alist '("\\.ts\\'" . typescript-ts-mode))

(defun typescript-ts-mode-hook-func ()
  (lsp-deferred))
(add-hook 'typescript-ts-mode-hook #'typescript-ts-mode-hook-func)

;; TSX

(add-to-list 'auto-mode-alist '("\\.tsx\\'" . tsx-ts-mode))

(defun tsx-ts-mode-hook-func ()
  (lsp-deferred))
(add-hook 'tsx-ts-mode-hook #'tsx-ts-mode-hook-func)

Supplement: Why I Didn't Adopt the tree-sitter-langs Package

The tree-sitter-langs package can also install *.dylib, but I decided not to adopt it for the following reasons:

It installs under ~/.emacs.d/elpa/tree-sitter-langs-20251019.1145/bin/ instead of ~/.emacs.d/tree-sitter/
- This directory name will change with version updates of the tree-sitter-langs package
The library names are like typescript.dylib instead of libtree-sitter-typescript.dylib

It's good for checking the location of Tree-sitter parsers for each language:

https://github.com/emacs-tree-sitter/tree-sitter-langs/tree/master/repos

Introducing Other xxx-ts-modes

Among the Emacs built-in xxx-ts-modes mentioned earlier, I introduced those with high usage frequency:

dockerfile-ts-mode
go-ts-mode
json-ts-mode
ruby-ts-mode

As an exception, I didn't introduce yaml-ts-mode. When saving, it formats with indent 4, and I couldn't figure out how to change it to 2.

Final Configuration for LSP mode, Tree-sitter, and xxx-ts-mode

LSP mode: init.el#L1044-L1063
Tree-sitter: init.el#L1431-L1450
dockerfile-ts-mode: init.el#L801-L810
go-ts-mode: init.el#L905-L917
json-ts-mode: init.el#L980-L989
ruby-ts-mode: init.el#L1121-L1132
typescript-ts-mode: init.el#L1014-L1028

Bonus: Migration from auto-complete to company-mode

There were usage points for company-mode in the lsp-mode code.

I had only heard the name company-mode, but apparently it's a completion framework that assists code input.

I migrated from auto-complete, which I've been using for years, to company-mode.

I saw some information suggesting that corfu, which is lighter than company-mode, might be better now, but I decided to go with company-mode this time as it seemed easier.

(setq company-minimum-prefix-length 2)
(setq company-show-quick-access t)

(add-hook 'after-init-hook #'global-company-mode)

Issues

When lsp-format-buffer-on-save is enabled for all buffers where lsp-mode is active, code written by others gets heavily reformatted, which might be awkward. Especially YAML files
global-company-mode is a bit noisy, so it might be better to configure it for individual major-modes. I might change this later

Conclusion

Finally, I brought my Emacs setup closer to a modern configuration with LSP + Tree-sitter. However, since there are almost no Emacs users around me, I'm not entirely sure how close I got.

I was also able to reduce some third-party packages. I want to minimize dependencies as much as possible, so that's good.

Added:
- company
- lsp-mode
Removed:
- auto-complete
- dockerfile-mode
- go-autocomplete
- go-eldoc
- go-mode

References

Making this Hugo-built blog multilingual

Takashi Masuda — Tue, 23 Sep 2025 12:17:05 +0000

Note: This article reflects the setup as of Hugo 0.138.0.

I've made this blog built with Hugo multilingual. For now, it's only available in English.

Why I implemented multilingual support

As part of my OSS activities at work, I often cross-post translated articles to platforms like dev.to and Medium. Recently, I've been casually translating and cross-posting articles on my own as well.

For example, the English translation of 2025-08-15-1 was cross-posted to these three sites:

dev.to - This served as the original English version
Hashnode - Set dev.to's article as the canonical version
Medium - Set dev.to's article as the canonical version

However, since I'm maintaining this blog masutaka.net, I thought it would be better to store the original English articles here and cross-post them to the above three sites. Setting the canonical URL to my own blog seems like it would also be beneficial for SEO.

Hugo's Multilingual Support

Hugo includes built-in multilingual support with simple configuration. All you need to do is add the following settings in your config.toml file:

defaultContentLanguage = "ja"

[languages.ja]
  weight = 1
  languageName = "日本語"
  title = "マスタカの ChangeLog メモ"

[languages.en]
  weight = 2
  languageName = "English"
  title = "Masutaka's ChangeLog Memo"

Articles with .en.md in their filenames will be the English versions.

Japanese version: content/posts/2025-08-15-1.md
English version: content/posts/2025-08-15-1.en.md

With this configuration, articles can be accessed via the following URLs:

Japanese version: https://masutaka.net/2025-08-15-1/
English version: https://masutaka.net/en/2025-08-15-1/

Multilingual Implementation Strategy

When implementing multilingual support, I followed this approach:

1. Maintain Existing URLs Unchanged

The most important policy was to absolutely preserve all existing URLs. Given that this blog has been operational for over 20 years, any changes to URLs would cause numerous broken links.

Therefore, I kept the Japanese version as is and added an /en/ prefix only for the English version.

/index.html - Almost unchanged, with /en/index.html added
/index.xml - Unchanged, with /en/index.xml added
/sitemap.xml - Changed to reference /ja/sitemap.xml and /en/sitemap.xml
/llms.txt, /llms-full.txt - Unchanged, with /en/llms.txt and /en/llms-full.txt added
- See reference: 2025-05-18-1

👉 The behavior described above is achieved through the configuration settings for defaultContentLanguage, [languages.ja], and [languages.en].

2. Keep English Menu Options in the Top Right Minimal

The Device, History, and About pages contain content that is primarily Japanese-specific with limited value in translation, so I decided to skip them this time.

Japanese Version: Archive, Tags, Search, Device, History, About
English Version: Only includes Archive, Tags, Search

Implementation Details

Here's an overview of the actual changes.

1. Modifications to config.toml

Added language configuration settings and corresponding menu settings for each language.

👉 The diff and the updated config.toml are attached in the Appendix.

2. Creating English versions of static pages

content/archives.en.md - Archives page
content/search.en.md - Search page
content/privacy.en.md - Privacy Policy

⚠️ Initially, I attempted to handle this by creating symbolic links from *.en.md to *.md, but Hugo did not recognize these links.

3. Modifying custom shortcodes

Updated the custom post shortcode to accept an lang argument.

layouts/shortcodes/post.html:

{{- $id := .Get "id" | default (.Get 0) -}}
{{- $lang := .Get "lang" | default .Page.Lang -}}
{{- $url := relref . (dict "path" $id "lang" $lang) -}}
{{- $title := .Get "title" -}}

<a href="{{ $url }}">{{ with $title }}{{ $title }}{{ else }}[{{ $id }}]{{ end }}</a>

Example usage:

<!-- If you specify an article ID as an argument, it generates a link in the current language -->
{{< post "2025-09-23-1" >}}
<!-- -> If the current language is English, this will generate a link to /en/2025-09-23-1/ -->

<!-- Adding the 'lang' argument creates an explicit link to another language -->
{{< post id="2025-09-23-1" lang="ja" >}}
<!-- -> If the current language is English, this will generate a link to /2025-09-23-1/ -->

4. Translation Support for Custom Partials

Since some translations were needed in layouts/partials/*.html, I created i18n/ja.toml and i18n/en.toml files.

Usage example:

<a href="https://example.com/" target="_blank" rel="noopener">{{ i18n "sendMessage" }}</a>

i18n/ja.toml:

sendMessage = "メッセージ送信"

i18n/en.toml:

sendMessage = "Send Message"

Conclusion

I successfully added multilingual support to this Hugo-built blog. The implementation was cleaner than I expected 👍

All existing URLs remained unchanged, limiting the impact to the /en/ directory
Achieved using only Hugo's standard features with minimal customization
Reduced maintenance costs by keeping the English menu minimal
sitemap.xml and llms.txt were automatically multilingualized

Moving forward, I'll translate new articles as needed and use https://masutaka.net/en/ as the original source while cross-posting to dev.to, Hashnode, and Medium.

While I'm not sure if there's actually an English-speaking audience, I'm satisfied with the result. With recent AI translation being fairly accurate, it's not that difficult anyway 😎

References

Multilingual mode - Hugo

Appendix

Changes to config.toml

diff --git a/config.toml b/config.toml
index 0830be8b..a6bae12c 100644
--- a/config.toml
+++ b/config.toml
@@ -7,7 +7,6 @@ googleAnalytics = "G-K28CQCC064"
 hasCJKLanguage = true
 languageCode = "ja"
 theme = "papermod"
-title = "マスタカの ChangeLog メモ"

 [permalinks]
   posts = "/:filename"
@@ -27,14 +26,12 @@ title = "マスタカの ChangeLog メモ"
   isPlainText = true
   mediaType = "text/plain"
   rel = "alternate"
-  root = true

 [outputFormats.llmsfull]
   baseName = "llms-full"
   isPlainText = true
   mediaType = "text/plain"
   rel = "alternate"
-  root = true

 #
 # papermod configuration
@@ -51,14 +48,9 @@ title = "マスタカの ChangeLog メモ"
   author = "masutaka"
   comments = true
   defaultTheme = "auto"
-  description = "マスタカの変更履歴が記録されていくブログです。"
   showtoc = true
   tocopen = true

-[params.homeInfoParams]
-  Title = "マスタカネット"
-  Content = "マスタカの変更履歴が記録されていくブログです。"
-
 [params.assets]
   theme_color = "#ffffff"
   msapplication_TileColor = "#da532c"
@@ -79,46 +71,81 @@ title = "マスタカの ChangeLog メモ"
 [[params.socialIcons]]
   name =  "GitHub"
   url = "https://github.com/masutaka"
-[[params.socialIcons]]
-  name =  "Dev"
-  url = "https://dev.to/masutaka"
-[[params.socialIcons]]
-  name =  "Hashnode"
-  url = "https://masutaka.hashnode.dev/"
-[[params.socialIcons]]
-  name =  "Medium"
-  url = "https://medium.com/@masutaka"
 [[params.socialIcons]]
   name =  "RSS"
   url = "/index.xml"

-[[menu.main]]
+#
+# Multilingual
+#
+
+[languages.ja]
+  weight = 1
+  languageName = "日本語"
+  title = "マスタカの ChangeLog メモ"
+
+[languages.ja.params]
+  description = "マスタカの変更履歴が記録されていくブログです。"
+
+[languages.ja.params.homeInfoParams]
+  Title = "マスタカネット"
+  Content = "マスタカの変更履歴が記録されていくブログです。"
+
+[[languages.ja.menu.main]]
   identifier = "archives"
   name = "Archive"
   url = "/archives/"
   weight = 1
-[[menu.main]]
+[[languages.ja.menu.main]]
   identifier = "tags"
   name = "Tags"
   url = "/tags/"
   weight = 2
-[[menu.main]]
+[[languages.ja.menu.main]]
   identifier = "search"
   name = "Search"
   url = "/search/"
   weight = 3
-[[menu.main]]
+[[languages.ja.menu.main]]
   identifier = "device"
   name = "Device"
   url = "/device/"
   weight = 4
-[[menu.main]]
+[[languages.ja.menu.main]]
   identifier = "history"
   name = "History"
   url = "/history/"
   weight = 5
-[[menu.main]]
+[[languages.ja.menu.main]]
   identifier = "about"
   name = "About"
   url = "/about/"
   weight = 6
+
+[languages.en]
+  weight = 2
+  languageName = "English"
+  title = "Masutaka's ChangeLog Memo"
+
+[languages.en.params]
+  description = "This is a blog that records Masutaka's change history."
+
+[languages.en.params.homeInfoParams]
+  Title = "Masutaka Net"
+  Content = "This is a blog that records Masutaka's change history."
+
+[[languages.en.menu.main]]
+  identifier = "archives"
+  name = "Archive"
+  url = "/en/archives/"
+  weight = 1
+[[languages.en.menu.main]]
+  identifier = "tags"
+  name = "Tags"
+  url = "/en/tags/"
+  weight = 2
+[[languages.en.menu.main]]
+  identifier = "search"
+  name = "Search"
+  url = "/en/search/"
+  weight = 3

config.toml after multilingualization

baseURL = "https://masutaka.net/"
defaultContentLanguage = "ja"
disablePathToLower = true
enableEmoji = true
enableRobotsTXT = true
googleAnalytics = "G-K28CQCC064"
hasCJKLanguage = true
languageCode = "ja"
theme = "papermod"

[permalinks]
  posts = "/:filename"

[taxonomies]
  tag = "tags"

[markup.goldmark.renderer]
  hardWraps = true
  unsafe = true

[outputs]
  home = ["html", "rss", "llms", "llmsfull"]

[outputFormats.llms]
  baseName = "llms"
  isPlainText = true
  mediaType = "text/plain"
  rel = "alternate"

[outputFormats.llmsfull]
  baseName = "llms-full"
  isPlainText = true
  mediaType = "text/plain"
  rel = "alternate"

#
# papermod configuration
#

[params]
  AmazonJpAffiliateID = "masutaka04-22"
  DateFormat = "2006-01-02 (Mon)"
  ShowAllPagesInArchive = true
  ShowCodeCopyButtons = true
  ShowFullTextinRSS = true
  ShowPageNums = true
  ShowPostNavLinks = true
  author = "masutaka"
  comments = true
  defaultTheme = "auto"
  showtoc = true
  tocopen = true

[params.assets]
  theme_color = "#ffffff"
  msapplication_TileColor = "#da532c"

[params.social]
  fediverse_creator = "@masutaka@mstdn.love"
  twitter = "@masutaka"

[[params.socialIcons]]
  name =  "Mastodon"
  url = "https://mstdn.love/@masutaka"
[[params.socialIcons]]
  name =  "Bluesky"
  url = "https://bsky.app/profile/masutaka.net"
[[params.socialIcons]]
  name =  "Twitter"
  url = "https://twitter.com/masutaka"
[[params.socialIcons]]
  name =  "GitHub"
  url = "https://github.com/masutaka"
[[params.socialIcons]]
  name =  "RSS"
  url = "/index.xml"

#
# Multilingual
#

[languages.ja]
  weight = 1
  languageName = "日本語"
  title = "マスタカの ChangeLog メモ"

[languages.ja.params]
  description = "マスタカの変更履歴が記録されていくブログです。"

[languages.ja.params.homeInfoParams]
  Title = "マスタカネット"
  Content = "マスタカの変更履歴が記録されていくブログです。"

[[languages.ja.menu.main]]
  identifier = "archives"
  name = "Archive"
  url = "/archives/"
  weight = 1
[[languages.ja.menu.main]]
  identifier = "tags"
  name = "Tags"
  url = "/tags/"
  weight = 2
[[languages.ja.menu.main]]
  identifier = "search"
  name = "Search"
  url = "/search/"
  weight = 3
[[languages.ja.menu.main]]
  identifier = "device"
  name = "Device"
  url = "/device/"
  weight = 4
[[languages.ja.menu.main]]
  identifier = "history"
  name = "History"
  url = "/history/"
  weight = 5
[[languages.ja.menu.main]]
  identifier = "about"
  name = "About"
  url = "/about/"
  weight = 6

[languages.en]
  weight = 2
  languageName = "English"
  title = "Masutaka's ChangeLog Memo"

[languages.en.params]
  description = "This is a blog that records Masutaka's change history."

[languages.en.params.homeInfoParams]
  Title = "Masutaka Net"
  Content = "This is a blog that records Masutaka's change history."

[[languages.en.menu.main]]
  identifier = "archives"
  name = "Archive"
  url = "/en/archives/"
  weight = 1
[[languages.en.menu.main]]
  identifier = "tags"
  name = "Tags"
  url = "/en/tags/"
  weight = 2
[[languages.en.menu.main]]
  identifier = "search"
  name = "Search"
  url = "/en/search/"
  weight = 3

Migration from Pocket and Hatena Bookmark to Raindrop.io (and Creating helm-raindrop.el)

Takashi Masuda — Fri, 15 Aug 2025 10:39:11 +0000

I've migrated from Pocket and Hatena Bookmark (Hatebu), services I had been using for over a decade, to a new bookmarking service: Raindrop.io. I've also created helm-raindrop.el so I can comfortably search from Emacs as before.

What is Raindrop.io?

🔗 https://raindrop.io/

Raindrop.io is a bookmarking service with a modern design and rich features.

Organize bookmarks with collections
Tagging and smart filters
Full-text search (premium plan only)
Browser extensions, mobile apps
Integrations with external services like IFTTT and Zapier
REST API for developers

The backend is proprietary, but everything else is open-source (OSS) and maintained by a single person, Rustem Mussabekov, who lives in Kazakhstan.

raindropio / app

Source code of web app and browser extensions

raindropio / mobile

Official Raindrop.io mobile app for Android

raindropio / desktop

Official Raindrop.io Desktop App

Migration Pocket and Hatebu to Raindrop.io

On July 8, 2025, Pocket was discontinued. I had used it as a "read-it-later" service for many years, so I had to find an alternative.

I had also been using Hatebu for a full 16 years since 2009, but since I've been distancing myself from social media in recent years, I decided to switch to a unified service.

Here's why I chose Raindrop.io:

The free plan is more than enough (unlimited bookmarks)
I can use it as a "read-it-later" service, just like Pocket
I can also use it as a persistent bookmarking service, like Hatebu
The API is public, making it easy to create my own tools
It has a data export feature, so there's less worry about vendor lock-in

The good things about Raindrop.io

After using it, I found several convenient features.

The free plan is practical

URLs can be edited - You can correct the URL later even if it changes
Collections feature - You can organize bookmarks like folders and set them to be public or private individually
Nested collections - You can set up a hierarchical structure
Highlighting feature - You can mark important parts of an article
Mobile app - In addition to the web version, browser extensions, and desktop version, there are also apps for iOS and Android

The paid plan's automated web archiving is convenient

🔗 https://help.raindrop.io/premium-features

AI-powered suggestions - It suggests appropriate collections and tags when saving and suggests merging or renaming similar tags
Full-text search - It performs a full-text search on the content of saved articles
Automated web archiving feature - It permanently saves content even if the site disappears
Reminder feature - It notifies you of a specific bookmark via the app or email at a specified time
Annotation feature - You can add notes to highlights
Detection of duplicate and broken links - Makes maintenance easier (?)
Automated backup - You can manage versions by linking with Google Drive
Extended upload limit - You can upload up to 10GB of images, videos, and PDFs per month

I tried the paid plan and found the automated web archiving to be very convenient.

I can't help but fix broken links when I find them. I know some might argue that if you can't find them, you don't have to maintain them...

While fixing them, I realized that many of my past bookmarks were inaccessible. With Raindrop.io's automated web archiving, a new reason is added to "read-it-later" or "bookmark": "it'll be readable forever."

The current paid plan is $33.04 per year (tax included), which is about $3.54 per month (tax included), so it's not a bad price.

The bad things about Raindrop.io

It's not a perfect service, so there are a few points that are difficult to use.

The app icon is plain - It's difficult to spot in my smartphone's share menu, and I often have to search for it
The saving process is a bit sluggish - It feels like it takes an extra 1-2 seconds to save a bookmark compared to Pocket
No archiving feature - If you're looking for a 'mark as read' feature like Pocket's, you'll need to create a dedicated collection and manually move bookmarks to it (which requires two taps)

However, even with these points, it's still a good and very usable service.

I created helm-raindrop.el

For this migration, I created helm-raindrop.el, which allows you to search and browse Raindrop.io bookmarks from Emacs.

masutaka / emacs-helm-raindrop

Helm interface for Raindrop.io

I'm not following what's next after Helm, but since the main function of helm-raindrop.el is to create a cache file ~/.emacs.d/helm-raindrop with the REST API, I don't think it will be difficult to migrate later.

Actually, I had a similar tool for Hatebu, and its extreme convenience was one of the reasons I was hesitant to migrate.

masutaka / emacs-helm-hatena-bookmark

Helm interface for Hatena::Bookmark

Being able to search bookmarks quickly from Emacs is quite comfortable. For example, if I think, "where was that article?", I just press ⌘-b and enter a search word. That's what my init.el does.

I'm not sure if it's a good or bad thing that I can continue to search for bookmarks from Emacs, but for now, I've managed to maintain the status quo.

Conclusion

Following the discontinuation of Pocket, I migrated to Raindrop.io, including Hatebu, which I had used for a full 16 years. At first, it was a reluctant migration, but after using it, I found it to be a surprisingly good service.

The free plan is practical, and the paid plan is also reasonably priced at $33.04 per year (tax included)
The API is public, making it easy to integrate with self-made tools
It has modern features like AI and automated web archiving

I also created helm-raindrop.el, so I've been able to maintain the ability to search from Emacs.

I recommend it to anyone looking for a bookmarking service. The free plan is very usable, and migrating from Pocket or Hatebu is easy, so it's a good idea to give it a try.

I'll continue to use it and will write another article if I discover anything new.

Self-implemented IFTTT Pro's RSS feed notification feature with AWS serverless architecture

Takashi Masuda — Sun, 20 Jul 2025 09:49:18 +0000

For casual information gathering, I've been running a serverless application called masutaka-feed since 2020.

masutaka / masutaka-feed

Notify my feeds of github and hatebu to mastodon and pushover

Post GitHub private feeds¹ to Mastodon
- Star and follow notifications are also sent to Pushover
Post Hatena Bookmark favorites feeds² to Mastodon

These are pieces of information that aren't worth subscribing to seriously with a feed reader, but I want to keep them in my field of view.

※ Mastodon posts are made to the private account @masutakafeed@mstdn.love

Previous Architecture Diagram
Current Architecture Diagram
Current Architecture
- Periodic execution with EventBridge Scheduler
- Lambda function responsibility separation
- Duplicate prevention with DynamoDB
- Configuration management with SAM continues
After the migration
Implemented with Claude Code
Conclusion

Previous Architecture Diagram

Previously, I used IFTTT's RSS Feed Integration to detect new items and call Lambda functions via API Gateway.

However, starting in 2024, RSS Feed Integration became available only with paid IFTTT Pro, so I was reluctantly paying the annual fee of $34.99.

GitHub:

Hatena Bookmark:

Current Architecture Diagram

Since I wasn't using IFTTT anywhere else, I really didn't want to continue paying the annual $34.99, so I completely migrated to an AWS serverless architecture this time.

The architecture uses EventBridge Scheduler to periodically check feeds and DynamoDB for read state management. Dependencies on external services have been eliminated, and processing is now completed entirely within AWS.

GitHub:

Hatena Bookmark:

Current Architecture

In the new architecture, the following components work together:

Periodic execution with EventBridge Scheduler

GitHub private feeds are checked every 5 minutes, and Hatena Bookmark favorites feeds every 15 minutes, executing the Lambda Subscriber functions shown below.

Lambda function responsibility separation

Each feed is separated into 2 Lambda functions:

Subscriber function: Feed retrieval and new item detection
- Retrieve RSS/Atom feeds and parse with rss-parser
- Manage read state with DynamoDB
- Call Notifier function if there are new items
Notifier function: Execute notification processing
- Filtering processing (GitHub only notifies specific events)
- Post to Mastodon
- Send notifications to Pushover (GitHub only)

Duplicate prevention with DynamoDB

Create tables for each feed
- GitHub: masutaka-feed-github-state
- Hatena Bookmark: masutaka-feed-hatebu-state
Set partition keys
- GitHub: Atom feed, each entry's id
- Hatena Bookmark: RSS 1.0 feed, each item's rdf:about
Set TTL to automatically delete old records after 30 days

Configuration management with SAM continues

As before, I use AWS SAM to manage the configuration of added components.

Environment variables continue to be managed with GitHub Actions Secrets/Variables, and automatic deployment occurs when commits are added to the main branch.

.github/workflows/deploy.yml

After the migration

Despite increased responsibilities, the code became unexpectedly cleaner
rss-parser was more convenient than expected - by just defining feed types like GitHubFeedItem and HatebuFeedItem, parsing became simple
- As a result, I was able to abandon HTML extraction using regular expressions
No longer need to pay IFTTT Pro's annual $34.99
- AWS costs stay within the free tier
Running error-free for about 2 weeks

Implemented with Claude Code

After starting to pay for IFTTT Pro, I had the concept in my head, but since it was essentially refactoring, I couldn't get motivated and left it alone.

Claude Code helped me overcome that lack of motivation, and I made great use of it.

Migration from JavaScript to TypeScript
- https://github.com/masutaka/masutaka-feed/pull/74
Migration from IFTTT Pro to AWS self-implementation
- https://github.com/masutaka/masutaka-feed/pull/77

💡 Each commit message in the pull requests contains Claude Code prompts.

Resource definitions in template.yaml are tedious to research, but Claude Code wrote them in one shot. Of course, I verified them afterwards.

EventBridge Schedulers definition
DynamoDB Tables definition
IAM Role settings for each resource
CloudWatch Alarm monitoring definitions

Conclusion

By self-implementing IFTTT Pro's feed notification feature with AWS serverless architecture, I was able to gain the following benefits:

Cost reduction: Annual fixed cost of $34.99 became essentially zero
Transparency gained: Full control over what items are added to feeds and what items have been marked as read
Enhanced monitoring: Can set up monitoring for feed subscriptions and detect failures immediately
Code optimization: Optimized feed parsing using rss-parser

Additionally, by utilizing Claude Code, I was able to significantly lower the motivation barrier for tasks like migrating from JavaScript to TypeScript and creating SAM templates.

I will continue to operate masutaka-feed at a low altitude going forward.

Example: https://github.com/masutaka.private.atom?token=xxxx ↩
Example: https://b.hatena.ne.jp/masutaka26/favorite.rss?key=xxxx ↩

Added llms.txt and llms-full.txt to My Hugo-built Website

Takashi Masuda — Sun, 18 May 2025 12:38:45 +0000

Note: This article reflects the setup as of Hugo 0.138.0.

What is llms.txt?

llms.txt is a Markdown-formatted text file proposed to address the limitation that LLMs have small context windows and cannot process entire websites.

It was proposed on September 3, 2024, by Jeremy Howard of Answer.AI at https://llmstxt.org/. It is not defined in an RFC like robots.txt.

The format includes certain specifications such as the website name in an H1 section, a brief summary, and a list of links in H2 sections.
Example: https://llmstxt.org/llms.txt

There's also llms-full.txt, which contains all website information.
Example: https://developers.cloudflare.com/llms-full.txt

There are directory sites for llms.txt as well:

The llms.txt and llms-full.txt I Added

I've added both:

How to Configure in Hugo

The necessary work involves modifying or creating just three files:

config.toml (modify)
layouts/index.llms.txt (create new)
layouts/index.llmsfull.txt (create new)

config.toml

I added the following to config.toml:

Defining outputFormats for llms and llmsfull while adding them to the default value of outputs.home, which is ["html", "rss"].

[outputs]
  home = ["html", "rss", "llms", "llmsfull"]

[outputFormats.llms]
  baseName = "llms"
  isPlainText = true
  mediaType = "text/plain"
  rel = "alternate"
  root = true

[outputFormats.llmsfull]
  baseName = "llms-full"
  isPlainText = true
  mediaType = "text/plain"
  rel = "alternate"
  root = true

layouts/index.llms.txt

I created layouts/index.llms.txt as a template for llms.txt:

# {{ .Site.Title }}

> {{ .Site.Params.Description }}


## Articles
{{ $yearMonthGroups := slice -}}
{{ range where (where (sort (.Site.GetPage "/posts/").Pages "Date" "desc") "Draft" "ne" true) "Sitemap.Disable" "ne" true -}}
{{ $yearMonth := .Date.Format "2006/01" -}}
{{ if not (in $yearMonthGroups $yearMonth) }}
* {{ $yearMonth -}}
{{ $yearMonthGroups = $yearMonthGroups | append $yearMonth -}}
{{ end }}
    * [{{ .Title }}]({{ .Permalink }})
{{- end }}


## Others

{{- $baseURL := .Site.BaseURL | strings.TrimSuffix "/" }}

* [Device]({{ $baseURL }}/device/): 所有デバイス
* [History]({{ $baseURL }}/history/): このサイトの歴史
* [About]({{ $baseURL }}/about/): 自己紹介
* [Privacy Policy]({{ $baseURL }}/privacy/): 当サイトの広告、アフィリエイト、プライバシーポリシー

Since Hugo site structures can vary widely, this is just one example. My blog has both blog posts and other articles, and since other articles don't change much, I hardcoded them in the Others section.

layouts/index.llmsfull.txt

I created layouts/index.llmsfull.txt as a template for llms-full.txt:

# {{ .Site.Title }}

> {{ .Site.Params.Description }}


{{/* Articles */}}
{{ range where (where (sort (.Site.GetPage "/posts/").Pages "Date" "desc") "Draft" "ne" true) "Sitemap.Disable" "ne" true }}
--------------------------------------------------------------------------------
title: "{{ .Title }}"
date: "{{ .Date.Format "2006-01-02" }}"
--------------------------------------------------------------------------------
{{ replaceRE "{{<\\s*comment\\s*>}}(.|\n)*?{{<\\s*/comment\\s*>}}" "" .RawContent -}}
{{ end -}}


{{/* Others */}}
{{ range slice "device.md" "history.md" "about.md" "privacy.md" -}}
{{ with site.GetPage . -}}
--------------------------------------------------------------------------------
title: "{{ .Title }}"
lastmod: "{{ .Date.Format "2006-01-02" }}"
--------------------------------------------------------------------------------
{{ replaceRE "{{<\\s*comment\\s*>}}(.|\n)*?{{<\\s*/comment\\s*>}}" "" .RawContent -}}
{{ end -}}
{{ end -}}

I made the delimiter longer because some articles contained ---.

Also, I made sure comments like the following wouldn't be included in llms-full.txt:

{{<comment>}}
This is a Hugo comment. It won't be output as an HTML comment either.
{{</comment>}}

nginx Configuration

Since llms.txt and llms-full.txt were showing character encoding issues, I added the following to the server directive:

location ~ "^/llms(-full)?\.txt" {
    root /usr/share/nginx/html;
    charset UTF-8;
}

Conclusion

I added llms.txt and llms-full.txt on my Hugo-built blog:

Regardless of whether there's demand for it, I'm satisfied with the result.

As a side note, I initially found a method on Hugo Discourse that used resources.ExecuteAsTemplate in layouts/robots.txt to generate llms.txt. However, I decided not to use this approach since including llms.txt in robots.txt is not yet common practice.

Another side note: in the past, my blog was created by converting a single ChangeLog-formatted file into HTML using a tool called chalow. Creating llms-full.txt reminded me of those days. It feels like I've come full circle.

DEV Community: Takashi Masuda

Read 'AWS Container Design and Build: A Practical Introduction, Revised and Expanded Edition' and Worked Through Every Hands-On Exercise

How the Book Is Organized

The Hands-On Part

Keeping Costs Down

Creating a Dedicated AWS Account for the Hands-On

A Few Places I Got Stuck

Conclusion

Reading Notes

P46. ECS Managed Instances

P54. AWS Copilot Has Moved to Maintenance Mode

P111. Connectivity Options Between ECS Services

P135. FireLens

P214. Secrets Manager vs. SSM Parameter Store SecureString

P250. Fault Testing with AWS FIS

P623. GuardDuty's ECS Runtime Monitoring

Switching from the Mac port Build of Emacs to the Standard NS Build

railwaycat / homebrew-emacsmacport

Emacs mac port formulae for the Homebrew package manager

Why I Switched to the NS Build

I Found That sis Could Solve It

laishulu / emacs-smart-input-source

Minimize manual input source (input method) switching.

laishulu / macism

Reliable CLI MacOS Input Source Manager [MacOS上可靠切换输入法的命令行工具]

Installing the NS Build of Emacs

Configuring sis Solved It

Installing macism

Configuring sis

Conclusion

Related

Appendix

Switching Input Sources by Context with sis-global-context-mode

Mixing English Words into Japanese with sis-global-inline-mode

Addendum (2026-06-25): There's a Mac port build of Emacs 30.2

hmelman: "@masutaka@mstdn.love Glad that's working for you.…" - Mastodon

Making Codex CLI and Codex.app Use mise-managed Ruby and Node.js

The Solution

Codex's Command Execution Environment Is a Sandbox

The Road to the Solution

Conclusion

Related

[2026-04] How I Currently Use Claude Code

Development Environment

Workflow

1. Creating a Work Plan

2. Reviewing the Work Plan

3. Executing and Reviewing the Work

Conclusion

masutaka / dotfiles-public

masutaka public dot files

Gleanings

Answering Yes/No Questions from Claude Code with y/n

Interview-Style Hearings from Claude Code

Keep Claude Code Sessions Short

Notification Settings from Claude Code

Migrating from asdf and direnv to mise

jdx / mise

dev tools, env vars, task runner

What is mise?

What I Did for the Migration

1. Homebrew Package Changes

2. zsh Configuration Changes

3. Installing Tools

4. Migrating default_packages_file

5. Configuring .ruby-version and .node-version Support

What I Didn't Migrate

Conclusion

References

Appendix

Fixing ruby-lsp Not Working in Emacs

Workaround for Perl default-packages

Update: 2026-06-21

The Relationship Between mise and aqua

Created a GitHub Actions Reusable Workflows Repository for Personal Use

masutaka / actions

GitHub Actions reusable workflows

What Are GitHub Actions Reusable Workflows?

Included Workflows

Why I Created This