DEV Community: upa_rupa

VS Code Remote SSH: Automatically Invoke VS Code as Your Editor from External Terminals

upa_rupa — Tue, 28 Apr 2026 06:53:06 +0000

The Problem to Solve

VS Code Remote (SSH) is powerful, but there are situations where you want to handle terminal operations in your favorite external terminal like iTerm2 instead of the integrated terminal.

However, when working from an external terminal, you can't seamlessly use VS Code as your editor out of the box.

Open files with code <filename> from external terminals like iTerm2, Alacritty, or WezTerm
Use VS Code as the editor for git commit or crontab -e, but automatically fall back to another editor when VS Code isn't running

This article introduces a wrapper script that solves both.

Background: Why `code` Doesn't Work from Terminals Outside VS Code

Inside VS Code's integrated terminal, environment variables for communicating with the VS Code server (VSCODE_IPC_HOOK_CLI) and paths to dedicated executables are set automatically.

These aren't inherited by external terminals, though. So simply running the code command won't actually "open the file in a VS Code window."

This issue is well known, and there are existing articles offering solutions:

A common approach is to write the socket lookup in .zshrc or .bashrc — both references above take this route. The downside is that it's evaluated once at shell startup, so it can't keep up when VS Code is started or restarted afterward. The Vinnie article works around this by wrapping the lookup in a shell function you can re-run manually, but neither reference handles the case where VS Code isn't running at all.

In this article, we'll put the lookup in a standalone script that re-evaluates on every invocation and gracefully falls back to another editor when VS Code isn't running.

The Solution: A Wrapper Script Called `editor`

First, create a directory to hold the script (e.g., ~/bin) and save the following as editor.

Creating the Script

#!/bin/bash
# Find the most recent IPC socket
export VSCODE_IPC_HOOK_CLI=$(ls -t /run/user/$(id -u)/vscode-ipc-*.sock 2>/dev/null | head -1)
# Get the path to the VS Code CLI executable
vscode_code=$(ls -td ~/.vscode-server/cli/servers/*/server/bin/remote-cli/code 2>/dev/null | head -1)

# When VS Code is available
if [ -S "$VSCODE_IPC_HOOK_CLI" ] && [ -n "$vscode_code" ]; then
  if [ $# -eq 0 ]; then
    # Running `code` with no arguments often just exits silently,
    # so prompt the user to specify a file when invoked as an editor
    echo "When using VS Code, please specify a file: editor <filename>"
    exit 1
  fi
  # VS Code may be hidden behind other windows or take a moment to surface
  echo "Opening in VS Code..."
  # --wait blocks until the file is closed in VS Code
  "$vscode_code" --wait "$@" >/dev/null 2>&1
  exit $?
else
  # If VS Code isn't available, fall back to another editor (nano, vim, etc.)
  nano "$@"
fi

Granting Execute Permission

chmod +x ~/bin/editor

Shell Configuration

Make the script callable from anywhere and register it as the system's default editor. Add the following to your .zshrc or .bashrc:

# Add ~/bin to PATH (if not already)
export PATH="$HOME/bin:$PATH"

# Register as the default editor
export EDITOR="$HOME/bin/editor"
export VISUAL="$HOME/bin/editor"

How It Works

Auto-discovering the Latest Socket

You could hardcode the socket path in .zshrc, but it changes every time VS Code restarts and breaks. This script looks under /run/user/ on every invocation, so it adapts to whatever the current connection state is.

Use from External Terminals

With this script in place, you don't have to think about whether you're inside VS Code's integrated terminal. Just type editor in your favorite external terminal and VS Code opens the file.

Handling No-Argument Invocation

Running code with no arguments simply exits. That's confusing when invoked as an editor — nothing happens — so the script prints a hint instead.

Programs differ in whether they read EDITOR or VISUAL. Many tools, including git and crontab, prefer VISUAL, but some only check EDITOR. Setting both is the most reliable approach.

Where This Helps

Once EDITOR/VISUAL point at this script, VS Code is automatically used in situations like:

git commit — Editing commit messages
git rebase -i — Interactive rebase operations
crontab -e — Editing crontabs
Ctrl+x, Ctrl+e — Bash/Zsh command-line editing
Claude Code's Ctrl+X, Ctrl+E — Launching an external editor for prompt input

If VS Code isn't running when you invoke any of these, nano (or whatever you configured) takes over, so your workflow doesn't stall.

Behavior Summary

State	`editor file.txt`	`editor` (no arguments)
VS Code running	Opens in VS Code	Shows a guidance message
VS Code not running	Opens in nano	Opens in nano

Closing Thoughts

I love VS Code, but iTerm2's tmux integration (tmux -CC) is so handy that I often skip the integrated terminal entirely. Even then, I still want VS Code for actual file editing, and this wrapper made that workflow much smoother. Getting Copilot completions while editing crontabs is a quietly nice bonus.

It's a small piece of configuration, but if you're a fellow VS Code user in the same situation, hopefully this is useful.

This article was originally published in Japanese at archelon-inc.jp.

VS Code Remote SSH：外部ターミナルから VS Code をエディタとしてスマートに呼び出す

upa_rupa — Tue, 28 Apr 2026 06:51:33 +0000

VS Code Remote SSH：外部ターミナルから VS Code をエディタとしてスマートに呼び出す

解決したい課題

VS Code Remote（SSH）は強力ですが、ターミナル操作だけは iTerm2 などのお気に入りの外部ターミナルで、行いたい場面があります。

しかし、外部ターミナルからだと、そのままでは VS Code をシームレスにエディタとして利用できません。

iTerm2, Alacritty, WezTerm などの外部ターミナルから code ファイル名 でファイルを開きたい
git commit や crontab -e のエディタとして VS Code を使いたい。ただし、VS Code が未起動なら別のエディタを自動で起動したい

これらを解決するラッパースクリプトを紹介します。

背景：なぜ VS Code 外のターミナルから `code` が動かないのか

VS Code 内の統合ターミナルでは、VS Code サーバーと通信するための環境変数（VSCODE_IPC_HOOK_CLI）や、専用の実行ファイルへのパスが自動で設定されています。

しかし、外部ターミナルにはこれらの情報が引き継がれません。そのため、単に code コマンドを実行しても「VS Code のウィンドウでファイルを開く」という動作にならないのです。

この問題自体はよく知られており、解決策を紹介する記事もあります。

よくある解決策は .zshrc や .bashrc にソケット探索の処理を書くことですが、シェル起動時に一度だけ評価されるため、VS Code を後から起動・再起動した場合に追従できません。Zenn の記事のように独立したスクリプトにすれば毎回評価できますが、VS Code が起動していないときのフォールバックは考慮されていません。

本記事では、実行のたびに VS Code の通信用ソケットを探索し、適切なエディタを選択するスクリプトを作成します。

解決策：ラッパースクリプト `editor`

まず、スクリプトを配置するためのディレクトリ（例：~/bin）を作成し、そこに editor という名前で以下のスクリプトを保存します。

スクリプトの作成

#!/bin/bash
# 最新の通信用ソケットを探索
export VSCODE_IPC_HOOK_CLI=$(ls -t /run/user/$(id -u)/vscode-ipc-*.sock 2>/dev/null | head -1)
# VS Code の CLI 実行ファイルのパスを取得
vscode_code=$(ls -td ~/.vscode-server/cli/servers/*/server/bin/remote-cli/code 2>/dev/null | head -1)

# VS Code が利用可能な場合
if [ -S "$VSCODE_IPC_HOOK_CLI" ] && [ -n "$vscode_code" ]; then
  if [ $# -eq 0 ]; then
    # 引数なしの code コマンドはそのまま終了することが多いため、
    # エディタとして呼び出された場合はファイル指定を促すようにします
    echo "VS Code使用時は、ファイルを指定してください: editor <ファイル名>"
    exit 1
  fi
  # VS Code が背後に隠れている場合や、起動のラグを考慮してメッセージを表示
  echo "Opening in VS Code..."
  # --wait をつけることで、VS Code 上で閉じるまでコマンドを待機させます
  "$vscode_code" --wait "$@" >/dev/null 2>&1
  exit $?
else
  # VS Code が見つからない場合は、代替エディタ（nano, vim 等）を起動
  nano "$@"
fi

実行権限の付与

chmod +x ~/bin/editor

環境設定

作成したスクリプトをどこからでも呼び出せるようにし、システムの標準エディタとして登録します。.zshrc や .bashrc に以下を追記してください。

# ~/bin にパスを通す（未設定の場合）
export PATH="$HOME/bin:$PATH"

# 標準エディタとして登録
export EDITOR="$HOME/bin/editor"
export VISUAL="$HOME/bin/editor"

ポイント解説

外部ターミナルからの利用

このスクリプトを通すことで、VS Code の「統合ターミナル」の中であるかどうかを意識せず、使い慣れた外部ターミナルから editor と打つだけで VS Code を呼び出せるようになります。

引数なし実行のハンドリング

code コマンドを引数なしで実行すると、単に終了してしまう挙動になります。editor スクリプト経由で呼ばれた際に何も起きないと混乱するため、ファイル指定がない場合はメッセージを表示するようにしています。

環境変数 EDITOR と VISUAL のどちらを参照するかはプログラムによって異なります。git や crontab をはじめ、多くのツールは VISUAL を優先しますが、一部のツールや環境によっては EDITOR のみが参照されることもあります。どちらの変数から呼ばれても同じ挙動になるよう、両方に設定しておくのが最も確実です。

活用シーン

このスクリプトを環境変数 EDITOR/VISUAL に設定しておくと、以下のような場面で自動的に VS Code が使われます。

git commit — コミットメッセージの編集
git rebase -i — インタラクティブリベースの操作
crontab -e — crontab の編集
Ctrl+x, Ctrl+e — (Bash/Zsh の行編集)
Claude Code の Ctrl+X, Ctrl+E — プロンプト入力時の外部エディタ起動

もし VS Code を立ち上げていない状態でこれらのコマンドを打っても、自動的に nano（または設定したエディタ）が立ち上がるため、作業が止まる心配もありません。

動作まとめ

状態	`editor file.txt`	`editor`（引数なし）
VS Code 起動中	VS Code で開く	ガイドメッセージを表示
VS Code 未起動	nano で開く	nano で開く

おわりに

VS Code 大好きなのですが、iTerm2のtmux統合(tmux -CC)が便利なので、VS Code内のターミナルを使わないことも多かったのです。そういう時でも、ファイル編集時はVS Codeを使いたかったので、とても便利になりました。
crontab編集時に、copilotが補完してくれるのも地味に便利です。

ちょっとした設定ですが、同じようにVS Codeを愛用している方の参考になれば嬉しいです。

The Nine-Year Journey to the Orca Emoji (U+1FACD) — How a Single Character Moved the World

upa_rupa — Thu, 23 Apr 2026 05:18:26 +0000

I love orcas, so I always felt a bit sad that while we had whale (🐋) and dolphin (🐬) emojis, there was no orca. Then recently, I came across news that the orca emoji would be introduced in iOS 26.4^[1]. Since emoji aren't an Apple-proprietary thing — they're defined by an international standard called Unicode — I knew this had to be a bigger story. So I dug in.

What I found was the story behind the new orca emoji 🫍: a nine-year campaign by people around the world pushing for its adoption into the Unicode standard.

Basic Info

Field	Details
Code Point	U+1FACD
Name	ORCA
Block	Symbols and Pictographs Extended-A
Standard Version	Unicode 17.0 / Emoji 17.0
Release Date	September 9, 2025

This emoji was added as a new standalone code point^[2] — not expressed by combining existing emoji, but assigned its own unique code: U+1FACD.

2016–2017: Voices Rise Around the World

The orca emoji story begins well before any official proposal, and in multiple places at once.

In August 2016, Jökull Ingi Þorvaldsson from Iceland started an online petition on Change.org called "Make a Killer Whale Emoji," asking Apple to add an orca emoji^[4]. It gathered 39 signatures.

The following February (2017), Christoph Päper, a Unicode contributor from Germany, opened an issue titled "Orca emoji" on the GitHub Unicode proposals tracker (Crissov/unicode-proposals)^[3]. His point: we have whale (🐋) and dolphin (🐬) emoji — why not orca? The issue included a link to the Change.org petition above.

The voices were there. But voices alone don't create emoji. A formal proposal had to be submitted to the Unicode Consortium.

February 2019: A Third Person Steps Up

In 2019, a Spanish developer named Marcos Del Sol Vives turned these feelings into a formal proposal^[5].

On February 20th, Marcos submitted a proposal for the orca emoji to the Unicode Consortium's Emoji Subcommittee (ESC). He had no connection to Jökull in Iceland or Christoph in Germany — he was a third, independent voice.

Then in September 2020, Lukas Ewert in Germany (also independently) launched another Change.org petition, "Make Orcas an Emoji," collecting 356 signatures^[15].

People around the world, strangers to each other, were all asking for the same thing: an orca emoji.

Marcos's proposal followed the format Unicode requires and made a compelling case^[6].

Search Popularity Comparison

Using Bing search trends, Marcos showed that "orca" had roughly the same search popularity as "elephant." Elephants already have an emoji (🐘) — orcas don't. He quantified the gap.

No Existing Emoji Covers It

Unicode's proposal review includes an "exclusion factors" section, where proposers must argue why their submission shouldn't be excluded. Marcos addressed this directly^[6].

"Can't an existing emoji substitute?" — No. Orcas are commonly called "killer whales" but are scientifically members of the dolphin family, and they look quite different from whales. "Too specialized?" — Pufferfish, crickets, and swans already have emoji, so orca can't be considered too specialized. "Just a passing trend?" — Orcas have existed on Earth for about 11 million years, the proposal notes.

Sample Images

Following Unicode Consortium requirements, Marcos prepared sample images at 18×18 and 72×72 pixels, in both black-and-white and color.

2019–2023: The Gate Is Closed

From here, Marcos's proposal entered a long wait.

The proposal was sent in 2019. But the formal document number L2/24-249 wasn't registered in the Unicode document registry until 2024^[6]. There is no orca-related document anywhere in the 2019 Document Register^[7].

So what happened during those five years? Looking into it, what emerged wasn't simple neglect — it was a deliberate decision on Unicode's part.

The Iron Rule: Once Added, Never Removed

First, some background: Unicode has an absolute rule called the Stability Policy^[17].

Once a character is encoded, it will not be moved or removed.

This means that once a code point is assigned, it stays there as long as humanity uses this standard — forever. Mistakes cannot be undone. This is the foundation of Unicode's caution around adding emoji.

A Strategic Pause — Shifting to Quality Over Quantity

In 2020, the COVID-19 pandemic pushed back the Unicode 14.0 release by six months^[2]. Then in autumn 2022, the UTC (Unicode Technical Committee) announced that Unicode 15.1 would be a limited release.

ESC chair Jennifer Daniel saw this as an opportunity. Her January 2023 blog post, "Breaking the Cycle"^[18], stated:

emoji categories are about to hit or have hit a level of saturation.

the ESC approves fewer and fewer emoji proposals every year.

The ESC used this pause to tackle longstanding issues: unifying skin tone variations, redesigning family emoji, and improving bidirectional text support. They also decided to temporarily delay the Unicode 17.0 submission window until April 2024^[18].

This wasn't a shutdown from neglect. It was a deliberate pause to redefine the emoji addition process itself.

Marcos's Proposal, Waiting at the Gate

There is no record of the orca emoji being rejected. It doesn't appear on Charlotte Buff's list of rejected emoji proposals^[10], nor in the official Unicode non-approval notice archive^[11].

Marcos's proposal wasn't denied. The gate was simply closed.

2024: The Gate Reopens

On April 2, 2024, submissions reopened with new guidelines^[8]. ESC chair Jennifer Daniel announced the reopening^[9].

When the gate opened, Marcos's proposal — waiting since 2019 — finally received its formal document number, L2/24-249^[6]. Later that year in November, the ESC proposed 164 new emoji candidates to the UTC, including the orca^[12]. Of those 164: 9 new code points and roughly 155 skin tone variations of existing emoji. One of the new code points — the Apple Core — was ultimately withdrawn, and the remaining 163 were approved as Emoji 17.0.

No objections were submitted during the Public Review Issue (PRI #515) for Emoji 17.0 candidates^[16].

September 9, 2025: Official Adoption

As part of Unicode 17.0 / Emoji 17.0, the orca emoji was officially approved^[2]. About nine years from the first online petition; about six and a half years from Marcos's proposal.

Marcos himself hasn't spoken publicly much about the details of this journey. His site orca.pet records the fact of the proposal and the fact of adoption — simply^[5].

The Emoji Approval Process: Open, but Careful

Unicode's emoji approval process is designed to be transparent^[13].

Submit a proposal: Anyone can submit an emoji proposal
ESC review: The Emoji Subcommittee evaluates proposals and decides whether to recommend them to the UTC
UTC deliberation: Discussed by the technical committee; meeting notes are published
Draft candidate list: Before final approval, a candidate list is published as a Public Review Issue (PRI), open for public feedback, which is also published^[16]
Official release: Released as a new version of the Unicode standard

All proposals are published as PDFs on unicode.org and available for anyone to read^[6].

Given that an assigned code point can never be removed, this caution has good reason. As the orca's case shows, years between proposal and adoption aren't unusual. But that's not negligence — it's a reflection of the weight of defining a standard that will be used, permanently, across the world.

Platform Support Status (as of March 2026)

Platform	Status
Google Noto Color Emoji	Supported (v2.051, released September 12, 2025)^[14]
Apple (iOS / macOS)	In beta with iOS 26.4 / macOS 26.4; stable release expected March–April 2026^[1]
X (formerly Twitter)	Supported (Twemoji v17.0)
Microsoft (Windows)	Not yet supported; as of March 2026, just reached Emoji 16.0 support

Unicode defines the code point and meaning, but the visual design is left to each platform (Apple, Google, Samsung, etc.). That's why the same U+1FACD looks different on iPhone versus Android.

Display Test with Noto Color Emoji

This article loads Google's Noto Color Emoji font to test rendering of the new orca emoji.

🫍

Even if your browser or OS doesn't support Unicode 17.0 emoji yet, you should see it rendered via Noto Color Emoji. If you can see a large orca above, it's working.

Summary

The orca emoji (🫍) was born from independent voices in Iceland, Germany, and Spain — and took nine years to make it into the Unicode standard
Proposer Marcos Del Sol Vives built a case backed by search data and comparative arguments
The five-year gap wasn't neglect — it was a deliberate pause for Unicode to confront emoji saturation and redefine the addition process
Unicode's emoji approval process is transparent, but the Stability Policy demands care

Every emoji we casually use has a story behind it. And those stories are often less about triumph than about patience and a series of coincidences stacking up over time.

References

iPhone Mania, "iOS26.4で利用可能になる新絵文字のデザインが明らかに！ (Japanese)" March 10, 2026. https://iphone-mania.jp/ios-600850/
The Unicode Blog, "Unicode 17.0 Release Announcement," September 9, 2025. http://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Crissov/unicode-proposals, "Issue #103: Orca emoji," GitHub, February 5, 2017. https://github.com/Crissov/unicode-proposals/issues/103
Jökull Ingi Þorvaldsson, "Make a Killer Whale Emoji," Change.org, August 2016. https://www.change.org/p/apple-make-a-killer-whale-emoji-in-apple-s-emoji-board
Marcos Del Sol Vives, "Orca emoji," orca.pet. https://orca.pet/emoji/
Marcos Del Sol Vives, "Proposal for Orca Emoji," Unicode Document L2/24-249, 2024. https://www.unicode.org/L2/L2024/24249-orca-emoji.pdf
The Unicode Consortium, "UTC Document Register — 2019." https://www.unicode.org/L2/L2019/Register-2019.html
The Unicode Blog, "Emoji Submissions Intake Process Re-opening," March 2024. http://blog.unicode.org/2024/03/emoji-submissions-intake-process-re.html
Jennifer Daniel, "Emoji submissions re-opening," Substack. https://jenniferdaniel.substack.com/p/emoji-submissions-re-opening-april
Charlotte Buff, "Rejected Emoji Proposals." https://charlottebuff.com/unicode/misc/rejected-emoji-proposals/
The Unicode Consortium, "Archive of Notices of Non-Approval." https://www.unicode.org/alloc/nonapprovals.html
Emojipedia Blog, "What's New In Unicode 17.0." https://blog.emojipedia.org/whats-new-in-unicode-17-0/
The Unicode Consortium, "Submitting Emoji Proposals." https://unicode.org/emoji/proposals.html
Emojipedia Blog, "Google Debuts Emoji 17.0 Support." https://blog.emojipedia.org/google-debuts-emoji-17-0-support/
Lukas Ewert, "Make Orcas an Emoji," Change.org, September 2020. https://www.change.org/p/apple-make-orcas-an-emoji
The Unicode Consortium, "PRI #515: Unicode Emoji 17.0 Alpha Repertoire." https://www.unicode.org/review/pri515/
The Unicode Consortium, "Unicode Character Encoding Stability Policies." https://www.unicode.org/policies/stability_policy.html
Jennifer Daniel, "Breaking the Cycle," The Unicode Blog, March 8, 2024 (originally published January 17, 2023). http://blog.unicode.org/2024/03/breaking-cycle.html

This article was originally published in Japanese at archelon-inc.jp.

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

upa_rupa — Thu, 23 Apr 2026 05:18:22 +0000

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

私はシャチが好きである。なので、クジラ（🐋）やイルカ（🐬）の絵文字はあるのにシャチがないことを残念に思っていた。

しかし最近、iOS 26.4からシャチの絵文字が追加されるというニュースを目にした^[1]。絵文字はApple独自のものではなくUnicodeという国際標準で定められているはずだから、これはもっと大きな話のはずだ — そう思って調べてみた。

すると見えてきたのは、新しいシャチの絵文字 🫍 の裏にある、9年にわたって世界各地の人々がUnicode標準への採用を求め続けた物語だった。

シャチ絵文字の基本情報

項目	内容
コードポイント	U+1FACD
名称	ORCA
収録ブロック	Symbols and Pictographs Extended-A
標準バージョン	Unicode 17.0 / Emoji 17.0
リリース日	2025年9月9日

この絵文字は単独の新規コードポイントとして追加された^[2]。既存の絵文字を組み合わせて表現するのではなく、U+1FACD という固有のコードが割り当てられている。

2016年〜2017年 — 世界各地から湧き上がった声

シャチ絵文字の物語は、正式な提案よりもずっと前に、しかも別々の場所で始まっている。

2016年8月、アイスランドの Jökull Ingi Þorvaldsson がChange.orgで「Make a Killer Whale Emoji」というオンライン署名活動を開始した^[4]。Appleに対してシャチの絵文字を作るよう求めるこの署名には39名が賛同した。

翌2017年2月、ドイツのUnicodeコントリビューターである Christoph Päper が、GitHubのUnicode提案トラッカー（Crissov/unicode-proposals）に「Orca emoji」のissueを立てた^[3]。クジラ（🐋）やイルカ（🐬）の絵文字は存在するのに、シャチがないのはおかしい — そんな問題提起だった。このissueには前述のChange.org署名へのリンクも添えられていた。

声は上がった。しかし声だけでは絵文字は生まれない。Unicode Consortiumに正式な提案書を提出する必要がある。

2019年2月 — 3人目が動く

2019年、この想いを1本の提案書に変えた人物がいる。スペインの開発者、Marcos Del Sol Vives だ^[5]。

2月20日、MarcosはUnicode Consortiumの絵文字小委員会（Emoji Subcommittee、以下ESC）にシャチ絵文字の提案を送った。アイスランドのJökull、ドイツのChristophとは面識のない、独立した3人目の人物だった。

さらに2020年9月、ドイツの Lukas Ewert が、これらの動きとは別にChange.org署名「Make Orcas an Emoji」を立ち上げ、356名の賛同を集めている^[15]。

世界各地の、互いに知らない人々が独立して同じことを求めていた。シャチの絵文字がほしい、と。

Marcosの提案書には、Unicode Consortiumが求めるフォーマットに従った説得力のある内容が含まれていた^[6]。

検索人気度の比較

Bingでの検索トレンドを使い、「orca」の検索人気度が「elephant（象）」とほぼ同等であることを示した。象にはすでに絵文字（🐘）があるのに、シャチにはない — この不均衡を数字で可視化した。

既存の絵文字では代替できない

Unicode の提案審査には「除外要因」という項目があり、提案者はなぜ除外すべきでないかを自ら論証する必要がある。Marcosの提案書はこれに対して明快だった^[6]。

「既存の絵文字で代用できるのでは？」— できない。シャチは「キラーホエール」と呼ばれるが科学的にはイルカの仲間であり、クジラとは外見がかなり異なる。「特殊すぎるのでは？」— フグ、コオロギ、白鳥といった動物がすでに絵文字になっている以上、シャチが特殊すぎるとは言えない。「一時的な流行では？」— シャチは約1,100万年前から地球にいる、と提案書は答えている。

サンプル画像の添付

Unicode Consortiumの規定に従い、18x18ピクセルと72x72ピクセルのサンプル画像を白黒・カラーの両方で用意した。

2019年〜2023年 — 閉ざされた門

しかし、ここからMarcosの提案は長い待ち時間に入る。

提案は2019年に送られた。しかし、正式な提案書番号 L2/24-249 がUnicode文書レジストリに登録されたのは 2024年 のことだった^[6]。2019年のDocument Registerにシャチ関連の文書は一件も存在しない^[7]。

この5年間、何が起きていたのか。調べていくと、単なる「放置」ではない、Unicode側の意図的な判断が見えてきた。

一度付けたら消せない — Unicodeの鉄の掟

まず前提として、Unicodeには 不変性（Stability Policy） という絶対的なルールがある^[17]。

Once a character is encoded, it will not be moved or removed.
（一度エンコードされた文字は、移動も削除もされない）

つまり、一度コードポイントを割り当てたら、それは人類がこの標準を使い続ける限り永久に残る。間違いがあっても取り消せない。この鉄の掟が、絵文字の追加に対する慎重さの根本にある。

戦略的休止 — 「量より質」への転換

2020年、COVID-19の影響でUnicode 14.0のリリースが6ヶ月延期された^[2]。そして2022年秋、UTC（Unicode Technical Committee）はUnicode 15.1を限定的なリリースにすると発表した。

ESCの議長 Jennifer Daniel は、この状況を「機会」と捉えた。彼女が2023年1月に発表したブログ記事「Breaking the Cycle（循環を断ち切る）」^[18]には、こう書かれている。

emoji categories are about to hit or have hit a level of saturation.
（絵文字のカテゴリは飽和に達しつつある、あるいは既に達している）

the ESC approves fewer and fewer emoji proposals every year.
（ESCは年々、承認する絵文字提案を減らしている）

ESCはこの休止期間を使い、スキントーン（肌の色）のバリエーション統一、家族絵文字の再設計、書字方向の対応といった積年の課題に取り組んだ。そして Unicode 17.0の提案受付を2024年4月まで一時的に遅らせる と決めた^[18]。

これは怠慢による停止ではなく、絵文字の追加プロセスそのものを再定義するための 意図的な休止 だった。

門の前で待つMarcosの提案

シャチ絵文字が「却下」された記録は見つからない。Charlotte Buffが管理する却下済み絵文字提案リストにも掲載されていない^[10]。Unicode公式の非承認通知アーカイブにも見当たらない^[11]。

Marcosの提案は否定されたのではない。門が閉まっていたのだ。

2024年 — 門が開く

2024年4月2日、新しいガイドラインとともに提案受付が再開された^[8]。ESCの議長Jennifer Danielもこの再開を告知している^[9]。

門が開いたとき、2019年からずっと待っていたMarcosの提案はようやく正式な文書番号 L2/24-249 を得た^[6]。同年11月、ESCが164個の新絵文字候補をUTC に提案し、シャチもその中に含まれていた^[12]。164個の内訳は、新規コードポイント9個と既存絵文字のスキントーンバリエーション約155個。最終的に新規コードポイントのうち「りんごの芯（Apple Core）」1個が取り下げられ、残りの163個がEmoji 17.0として承認された。

なお、Emoji 17.0の候補に対するPublic Review Issue（PRI #515）では、反対意見は寄せられなかった^[16]。

2025年9月9日 — 正式採用

Unicode 17.0 / Emoji 17.0の一部として、シャチ絵文字は正式に承認された^[2]。最初のオンライン署名から約9年、Marcosの提案からでも約6年半。

提案者のMarcos自身は、この経緯の詳細を公には多く語っていない。自身のサイト orca.pet には、提案の事実と採用の事実が簡潔に記録されているのみだ^[5]。

Unicodeの承認プロセス — オープン、しかし慎重

Unicodeの絵文字承認プロセスは、透明性が高い設計になっている^[13]。

提案の提出: 誰でも絵文字の提案書を提出できる
ESCでの審査: 絵文字小委員会が提案を評価し、UTCに推薦するかを判断する
UTCでの審議: 技術委員会で議論される。議事録も公開されている
ドラフト候補リストの公開: 正式承認前に候補リストが公開され、Public Review Issue（PRI）として一般からのフィードバックを受け付ける。寄せられたフィードバックは公開される^[16]
正式リリース: Unicode標準の新バージョンとしてリリースされる

提案書はすべてunicode.orgでPDFとして公開されており、誰でも読むことができる^[6]。

一度割り当てたコードポイントは永久に消せないという不変性の掟がある以上、この慎重さには理由がある。シャチの事例が示すように、提案から採用まで数年かかることは珍しくない。しかしそれは、怠慢ではなく、世界中で永久に使われる標準を定めることの重さの表れでもある。

各プラットフォームの対応状況（2026年3月時点）

プラットフォーム	対応状況
Google Noto Color Emoji	対応済み（v2.051、2025年9月12日リリース）^[14]
Apple（iOS / macOS）	iOS 26.4 / macOS 26.4 ベータで対応中。正式版は2026年3〜4月予定^[1]
X（旧Twitter）	対応済み（Twemoji v17.0）
Microsoft（Windows）	未対応。2026年3月時点でEmoji 16.0に対応したばかり

Unicodeがコードポイントと意味を定めるが、実際の見た目は各プラットフォーム（Apple、Google、Samsung等）がそれぞれ独自にデザインする。同じ U+1FACD でも、iPhoneとAndroidでは見た目が異なるのはそのためだ。

Noto Color Emoji で表示テスト

この記事では、Google の Noto Color Emoji フォントを読み込んで、新しいシャチ絵文字の表示をテストしている。

🫍

お使いのブラウザやOSがUnicode 17.0の絵文字に対応していない場合でも、Noto Color Emojiフォントを通じて表示されるはずだ。上に大きなシャチが見えていれば成功である。

まとめ

シャチ絵文字（🫍）は、アイスランド、ドイツ、スペインと世界各地の独立した声から始まり、9年かけてUnicode標準に採用された
提案者の Marcos Del Sol Vives さんは、検索データや比較論証を駆使した提案書を作成した
5年間の空白は「放置」ではなく、Unicodeが絵文字の飽和に向き合い、追加プロセスを再定義するための戦略的休止だった
Unicodeの絵文字承認プロセスは透明性が高いが、不変性という鉄の掟ゆえに慎重さが求められる

普段何気なく使っている絵文字の一つひとつに、こうした物語がある。そしてその物語は、華々しい成功譚ではなく、忍耐と偶然の積み重ねであることが多いのかもしれない。

参考文献

iPhone Mania, "iOS26.4で利用可能になる新絵文字のデザインが明らかに！" 2026年3月10日. https://iphone-mania.jp/ios-600850/
The Unicode Blog, "Unicode 17.0 Release Announcement," 2025年9月9日. http://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Crissov/unicode-proposals, "Issue #103: Orca emoji," GitHub, 2017年2月5日. https://github.com/Crissov/unicode-proposals/issues/103
Jökull Ingi Þorvaldsson, "Make a Killer Whale Emoji," Change.org, 2016年8月. https://www.change.org/p/apple-make-a-killer-whale-emoji-in-apple-s-emoji-board
Marcos Del Sol Vives, "Orca emoji," orca.pet. https://orca.pet/emoji/
Marcos Del Sol Vives, "Proposal for Orca Emoji," Unicode Document L2/24-249, 2024年. https://www.unicode.org/L2/L2024/24249-orca-emoji.pdf
The Unicode Consortium, "UTC Document Register — 2019." https://www.unicode.org/L2/L2019/Register-2019.html
The Unicode Blog, "Emoji Submissions Intake Process Re-opening," 2024年3月. http://blog.unicode.org/2024/03/emoji-submissions-intake-process-re.html
Jennifer Daniel, "Emoji submissions re-opening," Substack. https://jenniferdaniel.substack.com/p/emoji-submissions-re-opening-april
Charlotte Buff, "Rejected Emoji Proposals." https://charlottebuff.com/unicode/misc/rejected-emoji-proposals/
The Unicode Consortium, "Archive of Notices of Non-Approval." https://www.unicode.org/alloc/nonapprovals.html
Emojipedia Blog, "What's New In Unicode 17.0." https://blog.emojipedia.org/whats-new-in-unicode-17-0/
The Unicode Consortium, "Submitting Emoji Proposals." https://unicode.org/emoji/proposals.html
Emojipedia Blog, "Google Debuts Emoji 17.0 Support." https://blog.emojipedia.org/google-debuts-emoji-17-0-support/
Lukas Ewert, "Make Orcas an Emoji," Change.org, 2020年9月. https://www.change.org/p/apple-make-orcas-an-emoji
The Unicode Consortium, "PRI #515: Unicode Emoji 17.0 Alpha Repertoire." https://www.unicode.org/review/pri515/
The Unicode Consortium, "Unicode Character Encoding Stability Policies." https://www.unicode.org/policies/stability_policy.html
Jennifer Daniel, "Breaking the Cycle," The Unicode Blog, 2024年3月8日（初出: 2023年1月17日）. http://blog.unicode.org/2024/03/breaking-cycle.html

Auto-Configure Git Hooks for Your Entire Team with Just npm install

upa_rupa — Wed, 22 Apr 2026 08:58:49 +0000

No more "Git hooks weren't working on my machine"

In team development, running tests locally before pushing is crucial — it reduces CI wait times and helps you move faster.

The problem? The .git/hooks/ directory is not tracked by Git. Every developer has to manually set up hooks after cloning a repo, which leads to familiar issues:

Forgotten setup: New team members or people rebuilding their environment skip the manual step
Stale hooks: When hook scripts are updated, getting everyone to re-apply the changes manually is a losing battle
No enforcement: Hook setup is left to individual discretion, making it hard to guarantee consistent quality across the team

Even with CI in place, slow feedback loops hurt if local checks keep getting skipped.

The fix: embed Git hook setup into npm install — an operation everyone already runs — so the entire team stays in sync without thinking about it.

And we'll do it without any extra libraries like Husky, using only Git's built-in features and npm scripts.

Local Git hooks and GitHub Actions: Better Together

Running tests locally doesn't replace CI — they serve different purposes and work well together.

Aspect	GitHub Actions	Local Git hooks
When it runs	After push	Before push
Feedback speed	Must wait for CI to spin up	Instant, right on your machine
Environment consistency	Unified, reproducible environment	Depends on local setup
Enforcement	Strong (cannot be bypassed)	Medium (`--no-verify` can skip it)
Resource cost	Consumes CI minutes	Only your local machine

Fast local feedback plus reliable CI checks — together they cover both speed and consistency.

The Setup: core.hooksPath + npm prepare

Just three steps:

1. Create a hooks directory in your project

mkdir -p .githooks

2. Write your hook scripts

Example: a pre-push hook that runs tests before every push

# .githooks/pre-push
#!/bin/bash

echo "🧪 Running tests before push..."

# Run project tests
npm test

if [ $? -ne 0 ]; then
  echo "❌ Tests failed. Push aborted."
  exit 1
fi

echo "✅ All tests passed. Proceeding with push."

Make it executable:

chmod +x .githooks/pre-push

3. Add a prepare script to package.json

{
  "scripts": {
    "prepare": "git config core.hooksPath .githooks"
  }
}

That's it.

Why This Works

How prepare behaves:

Runs automatically after npm install
Also runs after npm ci
Running npm install right after cloning is second nature — making this a reliable trigger

What core.hooksPath does:

Points Git to any directory instead of the default .git/hooks/
By pointing to .githooks/ in the project root, the hook scripts themselves become Git-tracked — updates to scripts propagate to everyone via the repository

Combined: clone the repo, run npm install, and Git hooks are active. No extra steps.

Simpler Onboarding for New Team Members

The old way:

Clone the repository
npm install
"Oh, the README says to set up Git hooks..."
Manually run git config core.hooksPath .githooks
(Half the team forgets)

With this setup:

Clone the repository
npm install ← done

Onboarding instructions become: "just run npm install."

Monorepo Support

If you have multiple sub-projects under a single root:

project-root/
├── .githooks/
│   └── pre-push
├── frontend/
│   └── package.json
├── backend/
│   └── package.json
└── package.json  ← configure here

Configure it in the root package.json and it works as long as you run npm install at the root.

A Real-World pre-push Hook

#!/bin/bash

echo "🧪 Running pre-push checks..."

# Frontend tests
if [ -d "frontend" ]; then
  echo "📦 Testing frontend..."
  cd frontend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Frontend tests failed."
    exit 1
  fi
  cd ..
fi

# Backend tests
if [ -d "backend" ]; then
  echo "📦 Testing backend..."
  cd backend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Backend tests failed."
    exit 1
  fi
  cd ..
fi

echo "✅ All checks passed!"

Summary

Don't rely on CI alone — run tests locally for fast feedback
Create a .githooks/ directory and place your hook scripts there
Set "prepare": "git config core.hooksPath .githooks" in package.json
Everyone on the team gets Git hooks automatically on npm install

Pushing without running tests becomes the exception, not the norm — and "I forgot to set up hooks" stops happening.

This article was originally published in Japanese at archelon-inc.jp.

npm install だけで Git Hooks を全員に自動設定する方法

upa_rupa — Wed, 22 Apr 2026 08:58:06 +0000

npm install だけで Git Hooks を全員に自動設定する方法

「自分だけ Git Hooks が動いていなかった」をゼロにする

チーム開発において、「コードを push する前にローカルでテストを回す」という運用は、CI の待ち時間を減らし、開発サイクルを高速化するために非常に重要です。

しかし、Git Hooks が格納される .git/hooks/ ディレクトリは Git の管理対象に含まれません。そのため、プロジェクトをクローンした後に各自が手動で設定を再現する必要があり、それが以下のような問題を引き起こします。

設定の失念： 新規参画時や環境再構築の際、手動コマンドの実行を忘れてしまう
更新の追従漏れ： フックの内容（スクリプト）を修正しても、全員に手動での再設定を徹底させるのが難しい
強制力の欠如： 設定の有無が各自の裁量に委ねられ、プロジェクト全体でテスト品質を担保できない

せっかく CI を導入していても、ローカルでのチェックが漏れてしまっては、フィードバックの速度が落ちてしまいます。

そこで、「npm install という誰もが必ず行う操作」に Git Hooks のセットアップを組み込むことで、意識せずとも全員の環境を同じ状態に保つ――そんな「仕組みによる解決」を目指します。

具体的には、Husky などの追加ライブラリを使わず、Git の標準機能と npm scripts だけで完結させる方法を解説します。

GitHub Actions とローカルGit Hooks の共存

ローカルでテストを実行したからといって、CIでのテストが不要になるわけではありません。それぞれ役割が異なるため、併用するのがおすすめです。

観点	GitHub Actions	ローカルGit Hooks
実行タイミング	push後	push前
フィードバック速度	CIの起動・実行を待つ必要がある	手元で即座に結果が分かる
環境の一貫性	統一された環境で実行される	ローカル環境の個別事情に左右される
強制力	高い（回避不可）	中程度（`--no-verify`で回避可能）
リソースコスト	CI実行時間を消費	個人のPCリソースのみ

ローカルで素早くフィードバックを得つつ、CIで環境差異のない確実なチェックを行う。この組み合わせが開発効率と品質の両面で効果的です。

方法：core.hooksPath + npm prepare の組み合わせ

以下の3ステップで実現できます。

1. プロジェクトにhooksディレクトリを作成

mkdir -p .githooks

2. フックスクリプトを作成

例：push前にテストを実行する pre-push フック

# .githooks/pre-push
#!/bin/bash

echo "🧪 Running tests before push..."

# プロジェクトのテストを実行
npm test

if [ $? -ne 0 ]; then
  echo "❌ Tests failed. Push aborted."
  exit 1
fi

echo "✅ All tests passed. Proceeding with push."

作成後、実行権限を付与します：

chmod +x .githooks/pre-push

3. package.json に prepare スクリプトを追加

{
  "scripts": {
    "prepare": "git config core.hooksPath .githooks"
  }
}

これだけです！

なぜこれで自動化できるのか

prepare スクリプトの特徴：

npm install の後に自動実行される
npm ci でも実行される
Git cloneした後、最初に npm install を実行するのは自然な流れ

core.hooksPath の特徴：

.git/hooks/ の代わりに任意のディレクトリをhooks置き場に指定できる
プロジェクトルートの .githooks/ を指定すれば、フックのロジック自体を Git 管理下に置けるため、スクリプトの更新もリポジトリ経由で全員に同期されます。

この2つを組み合わせることで、リポジトリをcloneして npm install するだけで、特別な操作なしにGit Hooksが有効になります。

新メンバーのオンボーディングが簡単に

従来の方法では：

リポジトリをclone
npm install
「あ、READMEにGit Hooksの設定手順が書いてあるな...」
手動で git config core.hooksPath .githooks を実行
（忘れる人続出）

この方法なら：

リポジトリをclone
npm install ← これだけで完了！

新メンバーへの説明も「npm installしてね」の一言で済みます。

複数プロジェクト（モノレポ）での対応

ルートに複数のサブプロジェクトがある場合：

project-root/
├── .githooks/
│   └── pre-push
├── frontend/
│   └── package.json
├── backend/
│   └── package.json
└── package.json  ← ルートに用意

ルートの package.json で設定すれば、どのサブプロジェクトから npm install しても機能します。

実際のpre-pushフック例

#!/bin/bash

echo "🧪 Running pre-push checks..."

# フロントエンドのテスト
if [ -d "frontend" ]; then
  echo "📦 Testing frontend..."
  cd frontend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Frontend tests failed."
    exit 1
  fi
  cd ..
fi

# バックエンドのテスト
if [ -d "backend" ]; then
  echo "📦 Testing backend..."
  cd backend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Backend tests failed."
    exit 1
  fi
  cd ..
fi

echo "✅ All checks passed!"

まとめ

GitHub Actionsだけに頼らず、ローカルでも素早くテストを回す
.githooks/ ディレクトリを作成してフックスクリプトを配置
package.json の prepare で git config core.hooksPath .githooks を設定
これでチーム全員が npm install するだけで自動的にGit Hooksが有効に！

push前に手元でテストを実行する習慣が、自然とチーム全体に広がります。 設定忘れによる「テストを通さずにpushしてしまった」という事故も防げますし、CIの待ち時間に悩まされることも減るでしょう。

How to Match Only `/` in CloudFront Using `/?*`

upa_rupa — Tue, 21 Apr 2026 10:30:52 +0000

Introduction

When building a site on AWS CloudFront, a common requirement arises: "I want to route only the root (/) to a specific origin, or apply unique logic strictly to that path."

The challenge is that CloudFront’s path patterns lack a way to match exactly /. Typically, you end up relying on the Default Behavior (*), which captures everything from scripts to styles. This makes it difficult to separate caching strategies or route requests to different origins cleanly.

This article explores a clean way to solve this by taking advantage of the specific behavior of the ? wildcard: using the /?* pattern to isolate the root path.

The Constraint: CloudFront Path Patterns

CloudFront’s routing relies on path patterns with specific limitations:

No regular expressions
Two available wildcards:
- *: Matches any string of 0 or more characters.
- ?: Matches exactly one character.
Priority-based evaluation: The first pattern to match a request wins.

Within these constraints, the goal is to find a way to express “everything except the root” so the root itself can be handled independently.

How the Pattern Works

The key lies in the strict "exactly one character" rule of the ? wildcard.

Breaking Down the Pattern

The /?* pattern works as follows:

/ — A literal slash.
? — Exactly one character (required).
* — Any string of 0 or more characters.

This means that /?* matches any path that has at least one character following the initial slash.

💡 The Mechanism

By assigning /?* a higher priority, you ensure that only the root request (/)—which has zero characters after the slash—does not match and falls through to the Default Behavior (*).

Matching Results

Path	Matches `/?*`?	Reason
`/index.html`	✅ Yes	Matches `/` + `i` + `ndex.html`
`/main.js`	✅ Yes	Matches `/` + `m` + `ain.js`
`/assets/style.css`	✅ Yes	At least one character follows the slash
`/`	❌ No	Zero characters follow the slash

Fine-Grained Routing: SSR vs. Static Assets

The most practical application is a hybrid setup (e.g., Astro, Next.js), where you need to separate dynamic rendering from static delivery.

/ (Root): Route to a dynamic origin (Lambda, App Runner, etc.) to serve dynamic content and generate SEO metadata.
Everything else (/assets/*, /favicon.ico, etc.): Serve directly from S3 for maximum performance and lower costs.

Without this pattern, you’d need to manually enumerate every file extension. With /?*, you get a robust, catch-all solution for assets.

CDK Implementation Example

This approach keeps your infrastructure-as-code clean and easy to reason about:

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

const distribution = new cloudfront.Distribution(this, 'MyHybridDist', {
  // 1. Default (*) Behavior — Lowest Priority
  // Only the root (/) falls through to here.
  defaultBehavior: {
    origin: new origins.HttpOrigin('ssr-api.example.com'), 
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // SSR requires fresh data
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    // 2. Everything except root (/?*) — Higher Priority
    // Serve and cache all static assets from S3.
    '/?*': {
      origin: origins.S3BucketOrigin.withOriginAccessIdentity(assetBucket),
      cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,
      viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    },
  },
});

Strategic Advantages

Zero-Maintenance Asset Routing: No need to update your config when adding new file types (.webp, .avif, etc.).
Architectural Clarity: The logic for your "Entry Point" and your "Assets" is split cleanly at the edge.
Optimized Caching: Apply a no-cache policy to your dynamic root while keeping aggressive, long-term caching for everything else.

⚠️ A Subtle but Crucial Limitation

When combining this with CloudFront Functions, keep in mind:

Rewriting request.uri within a Function does not trigger a re-evaluation of cache behaviors.

If a request hits the Default Behavior (*) and your Function rewrites the URI to /index.html, CloudFront will not move that request over to the /?* behavior. Execution stays within the behavior that matched the original request.

Summary

The ? wildcard in CloudFront is often overlooked, but it can be surprisingly powerful. Its strictness allows for an elegant implementation of path-based negation.

Whether you are managing SSR setups, multilingual redirects, or maintenance pages, /?* is a reliable tool for handling the root path as a first-class citizen in your routing logic.

This article was originally published in Japanese on archelon-inc.jp.

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

upa_rupa — Tue, 21 Apr 2026 10:01:18 +0000

Introduction

In the Google Groups web interface, you’ll see three main reply options:

"Reply to all," "Reply to author," and "Forward."

Have you ever used "Reply to author"?

There’s one important thing to keep in mind: the messages you send aren’t automatically saved for you to access later.

What Actually Happens

When you click "Reply to author" in Google Groups, it opens a window to send a direct email to the original poster. You write your message, hit send—and then:

It won’t appear in the group archive — because it’s treated as a private email.
It won’t appear in your Gmail Sent folder — because the message is sent through Google Groups rather than your own Gmail account.

In short, you won’t have any way to review that message afterward.

Since there’s no record in your "Sent" folder or the group history, you can’t double-check what you wrote or confirm it was successfully delivered. You’re left waiting for a response without a paper trail.

Why Does This Happen?

Google Groups was originally designed as a bulletin board system, but many people use it like a mailing list. Because the interface feels like email, it’s natural to expect sent messages to be saved—this is where the confusion starts.

Action	How it's handled	History
Reply to all	Posted to the entire group	Saved in the group archive
Reply to author	Sent as a private message	Not saved in the group or Gmail

"Reply to author" sends a direct email through the Google Groups platform. Since your own email client isn't the one sending it, no copy is kept in your Sent folder.

Watch Out for Delivery Settings

Your email delivery settings can make this even easier to run into.

If your subscription is set to "Digest," multiple posts are bundled into a single email. To reply to a specific post, you often have to open the Google Groups web interface—which makes it much more likely you’ll click "Reply to author" by mistake.

A Known Issue for Users Worldwide

This is a well-documented issue. The Google Help Community contains many threads from users reporting this exact confusion.

For example, a thread titled "How can I see replies to author (a la Sent Messages)" has over 130 "I have the same question" votes. A Gold Product Expert confirmed that Google Groups does not provide a Sent folder or a built-in way to review these messages.

Even the official help page, "Compose or reply to a message," explains how to use the feature but doesn't explicitly mention that your messages won't be saved.

How to Avoid This

The Reliable Fix: Reply via Gmail

Avoid using "Reply to author" on the web interface. Instead, open the notification email in your Gmail inbox and reply directly from there.

When you send from Gmail, the message is saved in your Sent folder just like any other email.

Other Workarounds

BCC yourself (if the option is available)
Copy and save your message before hitting send
Manually add your own email address as a recipient

Summary

The "Reply to author" button might look convenient, but it lacks the basic record-keeping we expect from modern email. To ensure you always have a copy of your correspondence, get into the habit of replying directly from your email client. Don't let your important messages become "sent and forgotten" without a trace!

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

upa_rupa — Tue, 31 Mar 2026 10:47:14 +0000

Introduction

When developing Microsoft Teams tab apps, there's a frustrating issue you may run into during local development.

After modifying frontend code and rebuilding, Vite/Rollup adds a content hash to filenames (e.g., TeamsInitializer.bBRVpIft.js). However, if the browser (Teams WebView) has cached the HTML, the old HTML continues to reference the old hashed filenames, which results in 404 errors.

In this article, we'll share a solution we discovered by digging into the internal structure of the Teams SDK v2 local server.

Common Solutions and Their Drawbacks

Approach 1: Remove Hashes from Filenames

// astro.config.mjs or vite.config.js
export default {
  vite: {
    build: {
      rollupOptions: {
        output: {
          entryFileNames: 'assets/[name].js',
          chunkFileNames: 'assets/[name].js',
          assetFileNames: 'assets/[name].[ext]',
        },
      },
    },
  },
};

Drawback: Removing hashes means the browser may cache files indefinitely, preventing code updates from being reflected. You lose the benefits of cache busting.

Approach 2: Use the Dev Server (HMR)

Using Vite or Astro's dev server with HMR (Hot Module Replacement) avoids caching issues altogether.

Drawback: Teams apps are typically configured so that the Teams client (WebView) accesses a specific port, making it difficult to use the dev server's separate port directly.

Investigating the Teams SDK v2 Internals

When looking into the @microsoft/teams.apps package in Teams SDK v2, we discovered that HttpPlugin uses Express internally.

// Excerpt from node_modules/@microsoft/teams.apps/dist/plugins/http/plugin.js
const express_1 = __importDefault(require("express"));

let HttpPlugin = class HttpPlugin {
    constructor(server, options) {
        this.express = (0, express_1.default)();
        // ...
        this.use = this.express.use.bind(this.express);  // ← use() is exposed!
    }

    static(path, dist) {
        this.express.use(path, express_1.default.static(dist));
        return this;
    }
}

Key findings:

HttpPlugin holds an internal Express instance
The use() method is exposed and bound to Express's app.use()
This means we can add arbitrary Express middleware

Solution: Set Cache-Control Headers via Middleware

Leveraging this discovery, we add middleware to disable HTML caching only during local development.

// src/index.ts
import fs from "fs";
import https from "https";
import path from "path";

import { App, HttpPlugin, IPlugin } from "@microsoft/teams.apps";
import { ConsoleLogger } from "@microsoft/teams.common/logging";

const sslOptions = {
  key: process.env.SSL_KEY_FILE ? fs.readFileSync(process.env.SSL_KEY_FILE) : undefined,
  cert: process.env.SSL_CRT_FILE ? fs.readFileSync(process.env.SSL_CRT_FILE) : undefined,
};

const httpPlugin = new HttpPlugin(
  sslOptions.cert && sslOptions.key ? https.createServer(sslOptions) : undefined
);

// Disable HTML caching for local development only
if (!process.env.RUNNING_ON_AZURE) {
  httpPlugin.use("/tabs", (req, res, next) => {
    // Disable caching for HTML files and index.html requests
    if (req.path.endsWith(".html") || req.path === "/" || !req.path.includes(".")) {
      res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
      res.setHeader("Pragma", "no-cache");
      res.setHeader("Expires", "0");
    }
    next();
  });
}

const plugins: IPlugin[] = [httpPlugin];
const app = new App({
  logger: new ConsoleLogger("tab", { level: "debug" }),
  plugins: plugins,
});

app.tab("home", path.join(__dirname, "./client"));

(async () => {
  await app.start(+(process.env.PORT || 3978));
})();

Key Points

Environment-based control: The middleware is only added when the RUNNING_ON_AZURE environment variable is not set (i.e., during local development)
Path matching: Paths ending in .html, the root path, and paths without extensions (SPA routing) are treated as HTML requests
Cache-busting headers: Three headers — Cache-Control, Pragma, and Expires — are set to ensure caching is fully disabled

Benefits of This Approach

Hashed filenames are preserved: JS/CSS files keep their hashes, so production environments' caching efficiency is unaffected
No impact on production environments: Since it's controlled by an environment variable, the middleware is not added during Azure deployments
Extensible: The same technique can be used to add logging, authentication, custom headers, and more

Use Case: Adding Other Middleware

Using this technique, you can add various middleware to the Teams SDK.

// Add request logging
httpPlugin.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// Add custom headers
httpPlugin.use((req, res, next) => {
  res.setHeader("X-Custom-Header", "my-value");
  next();
});

// Add authentication for specific paths
httpPlugin.use("/api/private", (req, res, next) => {
  if (!req.headers.authorization) {
    res.status(401).send("Unauthorized");
    return;
  }
  next();
});

Caveats

This approach relies on the internal implementation details of Teams SDK v2 (@microsoft/teams.apps v2.x)
The API may change in future versions
This usage is not documented in the official documentation

Conclusion

We discovered that Teams SDK v2's HttpPlugin uses Express internally and exposes the use() method. By taking advantage of this:

HTML caching issues during local development are resolved
Cache-busting via hashed filenames is preserved
Development experience is improved without affecting production environments

We hope this helps anyone working with Teams SDK v2 who runs into the same issue.

This article was originally published in Japanese at archelon-inc.jp.

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

upa_rupa — Tue, 31 Mar 2026 10:26:33 +0000

Introduction

Have you ever wanted to change the look of emojis displayed in VS Code?

On macOS, Apple Color Emoji is used by default for emoji rendering. While Apple's emoji designs are polished, some people prefer Google's Noto Color Emoji.

However, many online sources claim that "Noto Color Emoji doesn't work in VS Code on macOS."

In this article, we'll show you how to use Noto Color Emoji in VS Code on macOS, based on steps we tested and verified on macOS (Apple Silicon).

TL;DR

It's surprisingly simple — just two steps:

Install the Noto Color Emoji font
Update the font settings in VS Code's settings.json

No Custom CSS extensions or system-level font configuration changes are needed.

Steps

1. Install Noto Color Emoji

Install it using Homebrew:

brew install font-noto-color-emoji

2. Update VS Code Font Settings

Open settings.json and configure as follows:

Editor:

"editor.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Terminal:

"terminal.integrated.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Restart VS Code after making these changes.

Key Point: Don't Use Single Quotes

Normally, font names containing spaces are often wrapped in single quotes (e.g., 'Noto Color Emoji'). However, in our testing, it worked correctly without single quotes.

When quotes are added, macOS's system font fallback may prioritize Apple Color Emoji. Omitting the quotes allows VS Code (which is Chromium-based) to correctly resolve and use Noto Color Emoji.

Approaches That Didn't Work

During testing, we also tried the following approaches, but they were ultimately unnecessary:

Overriding with Custom CSS Extension

You might consider using vscode_custom_css.imports to replace Apple Color Emoji with Noto Color Emoji via @font-face:

@font-face {
  font-family: 'Apple Color Emoji';
  src: local('Noto Color Emoji');
}

While this worked for the editor area, it doesn't affect the terminal because the terminal renders via Canvas/WebGL, which means CSS overrides are not applied. In the end, the editor.fontFamily setting alone was sufficient.

System-Level Font Changes on macOS

Modifying CoreText's fallback settings is another option, but it risks breaking with macOS updates and affects all applications, so we don't recommend it.

Why This Method Isn't Well Known

VS Code is an Electron (Chromium)-based application. Chromium's font fallback handling can behave differently from macOS native applications.

Many articles explain that "Apple Color Emoji is prioritized at the system level on macOS, so it can't be changed." This is generally true for native macOS applications. However, in Chromium-based apps like VS Code, font-family specifications are more directly reflected in font selection, which is why this method works.

Test Environment

macOS: Darwin arm64 25.1.0 (Apple Silicon)
VS Code: 1.109.4 (Universal)
Electron: 39.3.0
Chromium: 142.0.7444.265
Noto Color Emoji: Installed via Homebrew
Also verified working over Remote SSH connections

Conclusion

Changing the emoji font in VS Code on macOS turned out to be much easier than expected. Simply add Noto Color Emoji (without quotes) to editor.fontFamily and terminal.integrated.fontFamily.

Despite widespread claims online that "it's not possible on macOS," by taking advantage of the fact that VS Code is Chromium-based makes it achievable with a simple settings change.

If you'd like to change the look of your emojis, give it a try!

This article was originally published in Japanese at archelon-inc.jp.

References:

CloudFront パスパターンで「ルートだけ」を特定するテクニック

upa_rupa — Tue, 31 Mar 2026 00:46:29 +0000

はじめに

AWS CloudFrontでWebサイトを構築する際、「ルート（/）だけを特別なオリジンに向けたい、あるいは特別な処理をさせたい」という要件に直面することがあります。

しかし、CloudFrontのパスパターン設定には「/ のみ」をピンポイントで指定する記法がなく、通常は Default Behavior (*) を使うしかありません。これではルート以外のアセット（JS/CSS/画像）まで同じ設定に巻き込まれてしまい、キャッシュ戦略やオリジンの分離が難しくなります。

本記事では、CloudFrontのワイルドカード仕様を逆手に取った、/?* パターンを使ってルートを浮かび上がらせるテクニックをご紹介します。

背景：CloudFront パスパターンの制約

CloudFrontのキャッシュビヘイビアでは、パスパターンを使ってルーティングを制御しますが、以下の制約があります。

正規表現は使えない
使用可能なワイルドカード:
- *: 0文字以上の任意の文字列にマッチ
- ?: 正確に1文字にマッチ
パターンの評価: 設定の上（優先度が高い順）から評価され、最初にマッチしたものが適用される

この「正規表現が使えない」という制約の中で、「ルート以外すべて」を表現する方法が鍵となります。

解決策：`/?*` パターンの正体

ここで活用するのが、? ワイルドカードの「正確に1文字」という仕様です。

パターンの意味

/?* というパターンは、以下のように解釈されます。

/ : スラッシュ（固定）
? : 正確に1文字（必須）
* : 0文字以上の任意の文字列

つまり、/?* は 「スラッシュの後に少なくとも1文字以上あるパス」 にマッチします。

💡 ここがポイント

このパターンを優先度「高」で設定することで、Default Behavior (*) にはルートリクエスト（/）だけを落とし込むことが可能になります。

マッチングの結果

パス	マッチ判定	理由
`/index.html`	✅ マッチ	`/` + `i` + `ndex.html`（1文字以上の継続あり）
`/main.js`	✅ マッチ	`/` + `m` + `ain.js`（1文字以上の継続あり）
`/assets/style.css`	✅ マッチ	スラッシュの後に「1文字以上」が存在する
`/`	❌ 不適合	スラッシュの後に文字がゼロ個のため

実用的なユースケース：SSR + 静的アセットの分離

最も汎用的な活用例は、Astro や Next.js などを用いた「SSR（動的生成）と静的配信のハイブリッド構成」です。

/ (ルート): 最新記事のリストやSEO用のメタタグを動的に生成したい（Lambda / App Runner 等の SSR）
それ以外の全パス (/assets/*, /favicon.ico 等): S3から直接、高速かつ安価に配信したい

通常なら拡張子ごとにビヘイビアを定義する必要がありますが、/?* なら一撃で分離できます。

CDKでの実装例

このテクニックを用いると、インフラ構成コード（CDK）も非常にシンプルになります。

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

const distribution = new cloudfront.Distribution(this, 'MyHybridDist', {
  // 1. Default (*) ビヘイビア：優先度が最も低い
  // ここには / だけが落ちてくるため、SSRサーバー（動的オリジン）へ向ける
  defaultBehavior: {
    origin: new origins.HttpOrigin('ssr-api.example.com'), 
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // SSRは基本キャッシュなし
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    // 2. ルート以外のすべて (/?*)：優先度を高く設定
    // アセット類をすべて S3 から配信する
    '/?*': {
      origin: origins.S3BucketOrigin.withOriginAccessIdentity(assetBucket),
      cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED, // 静的ファイルは強力にキャッシュ
      viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    },
  },
});

この手法のメリット

拡張子の列挙が不要: *.js, *.css, *.webp ...と延々と設定を増やす必要がありません。
責務の分離 (Separation of Concerns): 「動的なトップページ」と「不変の静的アセット」という、性質の異なるリソースをパスのレベルで完全に分離できます。
キャッシュ戦略の最適化: ルートHTMLには no-cache を、アセット類には長期間のキャッシュを、といった切り分けが一行のパターン定義で完結します。
メンテナンス性: 新しいファイル形式を追加しても、CloudFrontの設定変更は不要です。

⚠️ 注意点：CloudFront Functions との組み合わせ

このテクニックを使用する際、CloudFront Functions でパスの書き換え（Rewriting）を行う場合は注意が必要です。

CloudFrontの仕様上、Function内で request.uri を書き換えても、キャッシュビヘイビアの再評価（再マッチング）は行われません。

例えば、Default Behavior (*) に落ちてきたリクエストを Function で /index.html に書き換えたとしても、そのリクエストが /?* ビヘイビアに移動することはありません。あくまで「最初にマッチしたビヘイビアの設定」で処理が継続されます。

まとめ

CloudFrontの ? ワイルドカードは地味な存在ですが、「正確に1文字」という厳密さを利用することで、標準機能だけでは難しい「パスの否定論理」を組み立てることができます。

「ルートだけを特別扱いしたい」という要件は、SSR構成、多言語リダイレクト、あるいはメンテナンス表示など、実務で頻繁に発生します。この /?* テクニックを、シンプルかつ堅牢なインフラ設計の引き出しとして持っておくと非常に便利です。

参考資料:

Google グループ「投稿者に返信」の落とし穴 ― 送ったメッセージが消える？

upa_rupa — Tue, 31 Mar 2026 00:43:59 +0000

はじめに

Google グループのウェブ画面には、返信ボタンが3つ並んでいます。

「全員に返信」「投稿者に返信」「転送」。

このうち 「投稿者に返信」 を使ったことはありますか？

実はこのボタン、送信した内容が どこにも保存されない という、非常に気づきにくい落とし穴があります。

何が起きるのか

Google グループのウェブ画面で「投稿者に返信」をクリックすると、投稿者個人宛のメール作成画面が開きます。ここでメッセージを書いて送信すると……

グループのアーカイブには残らない — 個人宛の私信として扱われるため
Gmail の送信済みフォルダにも残らない — Gmail ではなく Google グループのシステムが代行送信しているため

つまり、送信した瞬間に、送信者本人ですら二度と内容を読み返せなくなります。

それだけではありません。送信済みフォルダにも履歴にも何も残らないということは、そもそも自分のメッセージが正しく送れたのかどうかすら確認できないのです。「相手に届いているだろうか」「内容に間違いはなかっただろうか」――そんな不安を抱えたまま、相手からの反応を待つしかありません。

なぜこうなるのか

Google グループは「掲示板（アーカイブ）」として設計されています。しかし実際には、多くの組織がメーリングリストとして利用しています。メールソフトのような感覚で使っているからこそ、「送信済み」に残るはずだという思い込みが生まれ、この落とし穴にハマりやすくなるのです。

操作	処理のされ方	履歴
全員に返信	掲示板への書き込み	グループのアーカイブに残る
投稿者に返信	掲示板の外での私信	どこにも残らない

「投稿者に返信」は、掲示板を通さずにシステムが直接メールを飛ばします。Gmail を介していないため、Gmail 側の「送信済み」フォルダにコピーを保存する処理が走らないのです。

メール配信設定にも注意

Google グループのメール配信設定も関連する話題です。

配信設定を「ダイジェスト」にしていると、グループへの投稿がまとめて届くため、個別のメッセージへの返信操作を Google グループのウェブ画面から行いがちです。結果として「投稿者に返信」の罠にハマりやすくなります。

世界中のユーザーが困っている

この問題は世界中で知られており、Google の公式ヘルプコミュニティには同様の質問が多数寄せられています。

英語版のヘルプコミュニティでは、「How can I see replies to author (a la Sent Messages)」というスレッドに 130人以上のユーザーが「同じ質問がある」と回答しています。Gold Product Expert の回答は 「Google グループには送信済みフォルダが存在せず、投稿者への返信を確認する方法はない」 というもので、現時点で仕様改善には至っていません。

なお、Google の公式ヘルプ「メッセージを作成する、メッセージに返信する」では「投稿者に返信」の操作方法は説明されていますが、送信内容が保存されないことについては一切触れられていません。

対策

鉄則：Gmail から返信する

Google グループのウェブ画面にある「投稿者に返信」ボタンは使わない。 必ず、自分の Gmail に届いた通知メールに対して、Gmail アプリ・画面から返信してください。

Gmail から送信すれば、「送信済み」フォルダにしっかり残ります。

その他の自衛策

返信画面で 自分を BCC に含める（チェックボックスがある場合）
送信前に内容をコピーしておく
宛先に自分のアドレスを追加する

まとめ

Google グループの「投稿者に返信」は、一見便利に見えて実は大きな落とし穴が潜んでいます。

送信内容はグループにも Gmail にも残らない
これは Google の仕様であり、現時点で改善の見通しはない
Gmail から返信するのが唯一確実な回避策

仕事のやり取りで「送った内容が確認できない」のは致命的です。ぜひこの仕様を知っておいて、大切なメッセージが消えてしまう前に対策してください。

DEV Community: upa_rupa

VS Code Remote SSH: Automatically Invoke VS Code as Your Editor from External Terminals

The Problem to Solve

Background: Why code Doesn't Work from Terminals Outside VS Code

The Solution: A Wrapper Script Called editor

Creating the Script

Granting Execute Permission

Shell Configuration

How It Works

Auto-discovering the Latest Socket

Use from External Terminals

Handling No-Argument Invocation

Where This Helps

Behavior Summary

Closing Thoughts

VS Code Remote SSH：外部ターミナルから VS Code をエディタとしてスマートに呼び出す

VS Code Remote SSH：外部ターミナルから VS Code をエディタとしてスマートに呼び出す

解決したい課題

背景：なぜ VS Code 外のターミナルから code が動かないのか

解決策：ラッパースクリプト editor

スクリプトの作成

実行権限の付与

環境設定

ポイント解説

最新のソケットを自動探索

外部ターミナルからの利用

引数なし実行のハンドリング

活用シーン

動作まとめ

おわりに

The Nine-Year Journey to the Orca Emoji (U+1FACD) — How a Single Character Moved the World

Basic Info

2016–2017: Voices Rise Around the World

February 2019: A Third Person Steps Up

Search Popularity Comparison

No Existing Emoji Covers It

Sample Images

2019–2023: The Gate Is Closed

The Iron Rule: Once Added, Never Removed

A Strategic Pause — Shifting to Quality Over Quantity

Marcos's Proposal, Waiting at the Gate

2024: The Gate Reopens

September 9, 2025: Official Adoption

The Emoji Approval Process: Open, but Careful

Platform Support Status (as of March 2026)

Display Test with Noto Color Emoji

Summary

References

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

シャチ絵文字（U+1FACD）がUnicodeに採用されるまで — 1文字のために世界が動いた9年越しの軌跡

シャチ絵文字の基本情報

2016年〜2017年 — 世界各地から湧き上がった声

2019年2月 — 3人目が動く

検索人気度の比較

既存の絵文字では代替できない

サンプル画像の添付

2019年〜2023年 — 閉ざされた門

一度付けたら消せない — Unicodeの鉄の掟

戦略的休止 — 「量より質」への転換

門の前で待つMarcosの提案

2024年 — 門が開く

2025年9月9日 — 正式採用

Unicodeの承認プロセス — オープン、しかし慎重

各プラットフォームの対応状況（2026年3月時点）

Noto Color Emoji で表示テスト

まとめ

参考文献

Auto-Configure Git Hooks for Your Entire Team with Just npm install

No more "Git hooks weren't working on my machine"

Local Git hooks and GitHub Actions: Better Together

The Setup: core.hooksPath + npm prepare

1. Create a hooks directory in your project

2. Write your hook scripts

3. Add a prepare script to package.json

Why This Works

Simpler Onboarding for New Team Members

Monorepo Support

A Real-World pre-push Hook

Summary

npm install だけで Git Hooks を全員に自動設定する方法

Background: Why `code` Doesn't Work from Terminals Outside VS Code

The Solution: A Wrapper Script Called `editor`

背景：なぜ VS Code 外のターミナルから `code` が動かないのか

解決策：ラッパースクリプト `editor`

解決策：`/?*` パターンの正体