プロンプト

人参、ネギ、ピーマンと豚肉と冷凍うどんを使った焼きうどんのレシピを教えてください。肉は豚で豚こまなんで柔らかくしたいです。

回答

大人2人分で、**豚こま220g・冷凍うどん2玉**を想定します。豚こまは「酒＋片栗粉」で下処理すると、パサつきにくく柔らかくなります。

## 豚こまと野菜の醤油焼きうどん

### 材料（2人分）

- 冷凍うどん：2玉
- 豚こま肉：220g
- にんじん：1/2本
- 長ネギ：1/2〜1本
- ピーマン：2個
- サラダ油：小さじ1
- かつお節：あれば

**豚肉の下味**

- 酒：大さじ1
- 片栗粉：小さじ2
- 塩：ひとつまみ

**合わせ調味料**

- 醤油：大さじ1と1/2
- めんつゆ（2倍濃縮）：大さじ1
- みりん：大さじ1
- 酒：大さじ1
- 和風だしの素：小さじ1/2

### ① 豚こまを柔らかくする

豚こまに、

**酒 大さじ1 → 塩ひとつまみ → 片栗粉 小さじ2**

の順で揉み込みます。

そのまま**10〜15分**置いてください。

片栗粉が肉の表面を薄く覆うので、加熱したときに水分が抜けにくくなります。

### ② 野菜を切る

- にんじん → **細切り**
- 長ネギ → **斜め切り**
- ピーマン → **細切り**

合わせ調味料も先に混ぜておきます。

### ③ 冷凍うどんをレンジ加熱

冷凍うどん2玉を、**商品の表示どおりに電子レンジで温めます**。

完全に解凍してほぐしておいて大丈夫です。

### ④ 豚肉を焼く

フライパンに油小さじ1を入れて、**強めの中火**。

豚肉を広げて入れ、最初はあまり動かさず焼き色をつけます。

裏返して炒め、**ほぼ火が通ったところ**で次へ進みます。

### ⑤ 野菜を炒める

豚肉が入ったまま、

**にんじん → ネギ → ピーマン**

の順に加えます。

にんじんとネギを1〜2分炒めてからピーマンを入れ、さらに1分ほど。

野菜はクタクタにせず、少し食感を残します。

### ⑥ うどんを投入

レンジで温めたうどん2玉を加えます。

豚肉・野菜とうどんをざっくり混ぜ合わせます。

### ⑦ 味付けして仕上げる

合わせ調味料を回しかけます。

ここから**強めの中火〜強火で1分程度**。

汁気を飛ばしながら全体を炒めます。

最後にフライパンの底で醤油が少し焼けて、**香ばしい匂いがしてきたら完成**です。

味見して薄ければ、醤油を小さじ1/2程度追加してください。

仕上げに**かつお節＋黒こしょう**がおすすめです。

**豚肉の下処理 → 野菜を切る → うどんレンチン → 豚肉 → にんじん → ネギ → ピーマン → うどん → 合わせ調味料**

この順番で作ればOKです。

作ってみた

好みで勝手にニンニクスライスを入れてみた、めちゃくちゃうまい

感想

うまい。

元の記事を読む

プロンプト

夕飯
ご飯350g
豚肉200グラム
とろけるチーズ
たまねぎ
たまご
とまと大きいの1つ

がある、おとなふたりぶん、なにがいいかな？

回答

その材料なら、**豚肉とトマトのチーズ卵丼**が一番まとまりやすいです。

ご飯350gなら大人2人分にちょうどよく、豚肉200gもしっかり使えます。トマトの酸味とチーズがかなり合います。

### 豚肉とトマトのチーズ卵丼

**2人分**

- ご飯：350g
- 豚肉：200g
- 玉ねぎ：1/2〜1個
- 大きいトマト：1個
- 卵：2〜3個
- とろけるチーズ：50〜70gくらい
- 油：少量

味付けは、

- 醤油：大さじ1.5
- みりん：大さじ1
- 砂糖：小さじ1
- 酒：大さじ1
- ※酒がなければ水でもOK

**作り方**

1. 玉ねぎを薄切り、トマトを2cmくらいの角切り、豚肉を食べやすい大きさにする。
2. フライパンで豚肉を炒める。
3. 豚肉に火が通ってきたら玉ねぎを加え、しんなりするまで炒める。
4. 醤油・みりん・砂糖・酒を加えて1〜2分煮る。
5. トマトを加えて、崩しすぎない程度に1分ほど加熱。
6. 溶き卵を全体に流し入れる。
7. すぐにチーズを散らして蓋をし、弱火で1〜2分。卵が半熟くらいになったら火を止める。
8. ご飯175gずつにのせて完成。

ポイントは**トマトを最後の方に入れること**です。早く入れると水分がかなり出ます。

昨日のチーズオムライス系とは少し方向を変えつつ、**豚丼＋親子丼＋チーズトマト**の中間みたいな感じになります。黒こしょうがあれば最後に振るとかなり合います。

作ってみた

なお卵は入れてないのと、好みで薄切りにんにくを入れた

感想

うまい。ゴロゴロトマトが甘くて、酸味もあってうまい。とろけるチーズもうまい。

元の記事を読む

マインドマップのmacOSネイティブアプリケーションを作っています。

意識していること

• 決定論的な操作はスクリプトにして、Codexに使ってもらう。
• 判断基準はMarkdownに書き、Codexに判断してもらう。

流れ

1. 新しい機能を思いつく
2. 自分で仕様の方針を決める（ときにはCodexとアイデア壁打ち）
3. 自分で仕様の各ケースを思いつく限り列挙する
4. grill-with-docs スキルを使って仕様詰めを行う
5. 詰め切ったら to-tickets スキルと group-feature スキルでGitHubのイシューにする（※1）
6. イシューの内容・粒度をレビューする（※1）
7. レビュー内容を反映したイシューを作ってもらう（※1）
8. 初手のissueを implementスキルで専用ワークツリーを作って実装開始（※2）
9. Implementからレビュー用スキルを読んでレビュー&修正（※2）
10. ユニットテスト（※3）
11. E2Eテスト（※3）
12. Swift Format, SwiftLint, コードの重複確認(jscpd), 未使用コード確認(Perriphery)
13. 追加した機能の打鍵（※4）
14. 指摘があれば修正。なければCommit → Push → PRを作る（※5）
15. @codex review を投げて15分ごと（最大10回）に指摘を確認するようCodexに監視依頼（※5）
16. 指摘があれば自動で修正を開始→テスト→コミット→プッシュ→@codex review を投稿→監視（※5）
17. 指摘が仕様の変更に伴う場合は開発者に判断を委ねる（※5）
18. 指摘がなくなるまで繰り返す（※5）
19. 指摘がなくなったら、変更内容に関する資料を投稿（※5）
20. 打鍵をしてからマージ（※4）
21. ワークツリーを閉じる（機能開発のために作成されたビルドやキャッシュ関連も削除する）（※6）
22. 次の issueを implement開始（※2）

工夫

※1 Issueでプロジェクト管理をする

group-featureは、to-tickets で作ったIssueをSub Issueとしてまとめた親Issueを作るスキル。親Issueにはfeatureラベルをつけるため、GitHub のProjectでラベル絞り込みをすることで、機能単位と作業単位で分けて進捗管理ができる

Feature Issue = 機能管理

Sub issue = 作業単位

※2 実装を進めるとき

依存関係のないIssueは並列で実装する

to-ticketsは依存関係でIssueを分割してくれるので、依存がなければ並列でimplementする

作業の競合を確認する

複数のworktreeで作業するため、着手前でbranchや変更ファイルの重なりを確認する。情報収集はスクリプトを用意しており、その判断はMarkdownでルールを決めている。Codexはそれらを使って情報収集及び判断を行う。

※3 テストの実行環境

テストは副作用に応じてホストとVMを分ける

ロジックだけを確認するテストはホストPCで実行し、アプリの前面化、キーボード入力、Pasteboardの操作など、ホストPCに影響するテストは Tart のVMで実行している。これにより、ホストPCの操作への干渉を防ぐ。

どのテストをホストPCとVMのどちらで実行するか、同時に何件まで実行するかという判断基準はMarkdownにルールを書いている。

VMへのソースの転送、VMの起動、テスト、結果の回収、停止はスクリプトを用意しているので、Codexは実行するテストを選び、決まった手順はスクリプトに任せる。

ビルドの同時実行数を制限する

ビルドやVMを使ったUIテストなどは、共通のスクリプトを通すことで同時実行数を管理している（同時に行われるとPCがアチアチになってしまうので）。実行要求は共通のFIFOキューに入り、順番が来るのを待つ。

※4 実アプリでの確認

複数のworktreeで開発していると、別のbranchや古いビルドのアプリを確認してしまうことがあるため、起動用スクリプトを使い、識別用のラベルを表示する。設定とSQLiteも分け、どのコードを打鍵したのかを明確にしている。

起動中のアプリには、アプリ名とbranch名を表示する。

※5 PRの説明とレビュー

PRに変更内容を説明する資料を載せる

PRには、何を変えたか、どのように確認したか、まだ人が確認する項目があるかをまとめる。変更の構造が伝わりにくいときは、図も載せる。

PRレビューを監視する

PRを作ったセッションに、PRごとに1つのheartbeat監視を紐づけるスクリプトを作って、それをCodexに実行させている。いつ確認し、どの指摘なら自動で直してよいかという監視ルールはMarkdownに書いている。

• 15分ごと、最大10回繰り返す
• 監視によりレビュー指摘を発見したら自動で修正に入る
• 新しいcommitをpushしたら@codex reviewを投稿して、再び監視

直せる指摘は自動で修正する

仕様変更を伴わない指摘は、再現→修正→テスト→commit→push→スレッド返信→再レビュー依頼まで自動で行う。

仕様変更を伴う指摘は開発者が判断する

Issueや仕様変更を伴う指摘は自動修正せず、開発者に判断を委ねる。

※6 マージ後の片づけ

マージ後のworktreeはすぐに削除せず、退役用スクリプトでキューに入れる。未commitの変更や使用中のprocessなど、削除してよい条件はMarkdownに書き、安全なものだけを削除する。

元の記事を読む

前提

タスク管理の方法

今のPJでは、GitHub Issueとは別に独自のタスクリストを管理している。

各タスクには、次のように番号が振られており、基本的にこのタスクをもとに作業してPRを作っている。

No.998
No.999
No.1000

PRタイトルの付け方

PRを作成するときは、どのタスクに対する対応なのか分かるように、タイトルへタスクNo.を記載している。

例えば、次のようなタイトルにしている。

fix #999 ○○を修正

ここでの #999 はGitHubのIssueやPRを表しているわけではなく、PJ独自のタスクNo.999という意図だった。

発生した事象

あるPRをマージしたタイミングで、関係のないOpen中のPRがCloseされた。

自分ではCloseしていないはずなのに、GitHub上では自分がCloseしたことになっていた。

原因

GitHubのClosing keywords

GitHubには、PRやコミットからIssueを自動的にCloseするための Closing keywords という仕組みがある。

Using keywords in issues and pull requests

例えば、次のような表現がClosing keywordsとして認識される。

fix #999
fixes #999
close #999
closes #999
resolve #999
resolves #999

このように書かれたPRやコミットが デフォルトブランチ へマージされると、参照されている #999 を自動的にCloseできる。

通常であれば、

fix #999

と書くことで、

この変更によってGitHub Issue #999が解決する

という意味になる。

ただし、GitHubの #999 はIssueだけではなくPull Requestを指す場合もある。

#999 がOpen中のPRだった場合、そのPR自体がCloseされる。

タスクNo.とPR番号の一致

今回のPJでは、次の番号がそれぞれ別に採番されている。

• PJ独自のタスクNo.
• GitHubのIssue / PR番号

そして、両者の番号が近くなっていた。

例えば、次のような状態だった。

PJ独自のタスク: No.999
GitHub上のPR:   #999

この状態で、タスクNo.999に対応したPRへ、次のように記載した。

fix #999

こちらの意図は、

タスク No.999 を修正

というものだったが、GitHubは、

GitHub上の #999 を修正

と解釈する。

その結果、次の流れでPRがCloseされていた。

1. fix #999 と書かれたPRをマージする
2. GitHubがClosing keywordとして認識する
3. GitHubがGitHub上の #999 を参照する
4. #999 がOpen中のPRだった場合、PR #999がCloseされる

つまり、PJ独自のタスクNo.とGitHub上のIssue / PR番号が偶然一致したことで、自動Closeが発生していた。

対応策

タスクNo.の表記方法

独自の番号をPRへ記載する場合は、GitHubのIssue / PR参照と誤認されない形式にするとよい。

例えば、次のように # を付けない形にする。

fix 課題999
fix 999

GitHubのClosing keywordsは、IssueやPR番号と組み合わせて使われるため、独自タスク番号には # を付けないようにする。

まとめ

GitHubのPRタイトルやコミットメッセージに fix #999 のような表現を書くと、意図せずClosing keywordsとして解釈されることがある。

独自のタスク番号を表すために # を使っている場合は、GitHubのIssue / PR番号と衝突する可能性がある。

Closing keywords、知らなかったぜ...

元の記事を読む

処理の種類・正常/準正常/異常系などで階層を作ることで読みやすく・理解しやすくリファクタリングしたいタイミングが来る。

そんなときに JetBrains 系 IDE で command + 7 を押すと表示できる File structure が便利。

構造化前

構造化後

キーボードの矢印で移動すれば右側で開いているファイル内も追従するので、中身の確認もできる。

シンプルに行数が多いファイル内での作業をするときにも便利そうだ.

存在には気がついていたけど、実際使うシーンがなかったので、こういう場面で役に立つのか〜という発見。

元の記事を読む

新規ウインドウで開きたい場合は、Open project in の設定を確認する。

1. Settings を開く
2. 検索欄で project opening と入力する
3. Open project in を New Window にする

これで次からは、別プロジェクトを新しいウインドウで開ける。

仕事用PCだと新規ウィンドウで開くのに、私用PCでは置き換わってしまっていた。解決。

元の記事を読む

見終わって一週間しても熱が冷めやらない

eva EXTRAEX（通称薄い本）を見返したり、エヴァフェスのニュースなどを見ている

元の記事を読む

最初の要件定義

1. システムが満たすべき要件をリストとして列挙する
   • ここは自分で考えて手で書く。漏れや重複を少なく、エッジケースや分岐も細かく考える
   • 出来上がったアプリの動きを妄想する楽しいフェーズ
2. Codex CLIの plan mode で、要件定義したい旨・システムを作る目的・想定ユーザ・1.のリストを投げる
   • ディスカッションをしてヌケモレ重複を解消する
3. 作ってもらった plan を /docs/plan 内に配置してもらう

機能設計

1. plan内から1機能（フェーズ1）をピックアップし、詳細度を高めた plan を、plan mode で作成する
   • 実装に近い話をディスカッションして決めていく

開発

1. Codex CLI に フェーズ1 に対する TDD用の TODO リストを作成してもらい、.md に追加する
   • TODOリストは自分で作ってもいい
2. TODO リストをレビューする
3. TDDのループで実装を進める
   1. TODOリストから1件選ぶ
   2. Red: そのケースに対する失敗するテストを1つ追加 or 修正する
   3. Green: テストを通すための最小限の実装を行う
   4. Refactor: テストがグリーンの状態を維持したままリファクタリングする
   5. lint, format, knip を実行
   6. plan を更新する
   7. コミットする
   8. 問題なければ別のTODOに進む。
4. ☝のシーケンス内では都度、質問、要件・機能・TODOのブラッシュアップを行う
5. 定期的にテストケースの構造化を行う

繰り替えす

1. 次のフェーズのPlanを作成して開発 -> 次のフェーズの... を繰り返す

新しいセッションに入ったとき

• 上述のTDDの指示を毎回打ち込むのはめんどくさい
• また、context が圧迫してきたら plan を更新させた後 /compactするが、/compact 後はワークフローが崩れる
• そのため、上述のフローを skillsに登録している
  • 実装中の plan と次タスクを明示して指示している

# 指示の例
$workflow docs/implementation_plan_phase1-3.md の phase1.5 Case5 の続きを実装する

参考: skills

大まかに言うと、古典学派・TDDで実装してこうねという話

---
name: workflow
description: Shared collaboration workflow for implementing one TODO case at a time (t-wada style classical TDD). Assumes plan and TODO list are already agreed. Includes explicit review gates and pre-commit quality checks (lint/format/knip).
---

# Workflow

## Objective

Execute implementation with a strict one-case TDD cadence, using explicit review gates and deterministic diffs.

## Preconditions

- Plan and TDD TODO list are already agreed.
- We will start from an existing TODO item.

## Invocation

When starting work, the user says:

- `$workflow に従って、{XX} の {YY} を実装していこう`

## TDD Loop (One Case Only)

1. Pick exactly one TODO case (state the TODO id/title explicitly).
2. **Red**: add or adjust one failing test for the case.
3. Ask the user to review the test intent and failing result.
4. **Green**: implement the minimum code required to pass the test.
5. Ask the user to review the implementation.
6. **Refactor** while keeping tests green.
7. Ask the user to review the refactor.
8. **Plan Update (before commit)**:
   - Reflect the implemented behavior in the plan.
   - Mark the TODO case as completed.
   - Adjust acceptance criteria if clarified during implementation.
   - Record any design decision discovered during the case.
9. **Quality Gate (before commit)**:
   - run `lint`
   - run `format`
   - run `knip`
   - if any fail: fix minimally, keep scope constrained to the same TODO case.
10. **Commit the case**.
11. Move to the next TODO case.

## Guardrails

- Do not batch multiple TODO cases in one cycle.
- TODO must follow t-wada style, classical style TDD.
  - Behavior-first.
  - Outside-in thinking only when needed.
  - Prefer state verification over interaction verification.
  - No unnecessary mocking.
- Each TODO must represent a single observable behavior.
- Test cases must be written structurally.

  Use the following structure:
  - XXをするYY
    - XX のとき YY となる

- Test case names must be written in Japanese.
- Test names must describe behavior (condition + result), not method names.
- One test = one behavior.
- Do not test multiple branches in a single test.
- Avoid implementation detail assertions.
- Keep each step observable and explain why the change is needed.
- Prefer minimal deterministic diffs.
- Pause coding and return to discussion if disagreement appears.
- If scope changes, stop and re-align TODO/acceptance before continuing.
- Do not use English identifiers in test names unless domain terminology requires it.

- The plan must be updated before every commit.
- Implementation and plan must remain consistent.
- No commit without plan alignment.

## Commit Rules

- Commit only after completing Red → Green → Refactor and passing the Quality Gate.
- Use short imperative commit messages with prefixes such as `test`, `fix`, `refactor`, `docs`, `add`.
- Keep unrelated changes out of the commit.

効果的だと感じる文面は、TODO must follow t-wada style, classical style TDD.。

意識してること

1. 粒度の異なる計画書を作成して、コミット前に更新する
   • 進捗把握がしやすくなる
2. 1テストケース単位でコミットすることでPR粒度を小さくする
   • やりとりの頻度は増えるが、レビュー負荷が少なくなる
3. テストコードを重点的にレビューする
   • テストコードを正しいガードレールに仕上げることを意識する
4. 最初にシステムが満たすべき要件を自分で書いておく
   • 一番重要
   • 事前に考えて抜いておくと、AIが書いたコードの妥当性をスムーズに判断できる
   • 都度planで計画を立てるときにも、自分の手である程度要件を書いてからplanに投げる

悩み

• 計画書はすぐ陳腐化する
  • 作業完了までは計画書を削除し、その際に意思決定をADRとして残すほうがいいかも
  • AIに読ませたり更新させる場合は少ない文章のほうがいいし
• 業務では実践できていない
  • お金関係や規模の大きいシステム・チーム開発では上述のワークフローは使えていない
    • プロダクションコードめちゃくちゃレビューしてる
  • あくまでも個人での開発や厳密さを要求されない部分でのフロー

元の記事を読む

• Ran git status --short
  └ You have not agreed to the Xcode license agreements. Please run 'sudo
    xcodebuild -license' from within a Terminal window to review and agree
    to the Xcode and Apple SDKs license.

───────────────────────────────────────────────────────────────────────────

• 今はコミットできません。git 実行時に以下で止まっています。

と言ってくる

解決

Xcode を開いて

Agree すればいい

多分、Xcode のアップデートをしたのが原因

元の記事を読む

[tools].web_search` is deprecated. Use `web_search` instead

と言ってくる

原因

かつて .codex/config.toml に設定した [tools] web_search = true が非推奨になった模様

最新を見てみると...

config.toml

features. や tools. が非推奨となっている。

最下部の web_search が最新。stringで cached or live を指定してねとのこと。

解決

新鮮なデータが欲しいので live を設定

web_search = 'live'

CLIも無事警告が出ずに起動。

元の記事を読む

https://hono.dev/

めっちゃいい

apiがシンプルに書けるし、便利なミドルウェアが豊富
zodとの連携も強くてバリデーションを書きやすい

自分が作っているものは規模が小さいといいつつ、Cloudflare D1 と Durable Object（アラームが使いたい）も触る。乱雑に作るとまずいので以下のアーキテクチャにしてる

├── index.ts # 入口
├── 機能名
│   ├── controller # APIのふりわけ
│   ├── domain # 型など
│   ├── durable-object #  durable object alarm が呼ばれるときに処理（仮）
│   ├── repository # D1クエリ（生）
│   └── service # controllerから呼ばれるメソッド
└── web # クライアント
    ├── controller
    ├── csr # CSRする部分 
    └── ssr # ssrで返すベースのhtml

serviceとrepositoryはクラスじゃなくて純粋な関数にしている。規模が大きくなって辛くなってきたら考える。

クライアント側は、正直 pages にformをおいてworkerのapiを叩くのでもいいけど、jsx-domを試したくてこういう構造にしている。

楽しいなぁ、もっと深く触りたい

元の記事を読む

ブラウザのネットワークタブであれば、1つの通信に対するペイロードとレスポンスが確認できる。値そのものとパラメータ名がセットで表示されるのでわかりやすい。

なので、めちゃくちゃ使うようになった。
デベロッパーツール、もっと使ったほうがいい機能たくさんありそう

元の記事を読む

ワーカーとD1と比べて何が違うのかよくわからなかったけど、わかってきた

DOのnameってssh key gen するときのパスフレーズみたいなものなのか？

生成したDOのインスタンスとかアラームを一覧で取得する方法、ないっぽい?

わかってきてない... あ〜おもしろいなぁ

元の記事を読む

仕事は Windows と Ubuntu（WSL2） 。プライベートで macOS と Rasbian。

Windows 環境で開発していたが、昨年 WSL に移行した。docker も Ubuntu の docker engine を使うようになった。 使い慣れた Linuxコマンドも使えるし、エイリアスも使いまわせるしで快適に。 ファイルシステムの都合か、動作も早い。

ラズパイ は immich で写真を管理したり、ファイル共有のハブとして使用。 その他、プライベートにまつわる全ては M1 の MacBook Air で完結。後続の Apple シリコンも気になるが、M1 で快適に使えてしまっている。

エディタ

JetBrainIDEを使っている。 オールインワンで揃っているので開発のとっかかりが楽でいい。 DataGrid すき。

AI

CodexCLI はプライベートな開発用。GeminiCLIはコードリーディングに使用。ChatGPTは汎用。 仕事では ChatGPT にコンテキストと目的を投げてコピペ。疑問があれば更問して納得してからコピペ。そして手直し。 自分が説明できる状態でPRを出したいのでそんな感じの使い方。使わないほうが早いこともしばしば。

プライベートでは CodexCLI に書かせてから手動で修正。CodeRabbit CLI でレビューして...という感じ。MCPは全解除してしまった。

CodeRabbit、すき

また、NotebookLM を Podcast 生成用に使用。知りたいことを放り込んで音声化しておけば、育児や家事の合間に聞けるので重宝している。 子供ができてからまとまった時間が取れなくなってきたので、暇な耳に流し込む情報を自分で増やせるのはありがたい。 2025年末の月980円で使えるキャンペーンに乗っかったので、たくさん生成できてうれしい。

シェル

windows は powershell。mac は fish shell を使っている。 fish は昔いれたままなんの手入れもしておらず。Bash互換じゃない点に不便を感じることもあるので、zsh にしようか悩み中。

ターミナル

iTerm2、色々試したが変わらず。tmuxと共に使用。 ホットキーで開いたり隠したり。

dotfile

まったく手入れができていない。 iMac → Intel Mac → M1 という遍歴だが、毎回初期化して新規一点環境を作り直してしまうので...

ランチャー

Raycast 。ランチャー兼クリップボード管理ツールとして使っている quicktimeのエクステンションも便利

Clipboard History for Mac
QuickTime Recording

TODO管理

Emacs の orgモード。 事前にタスク分割をガッツリやるタイプの人間。毎タスクを時間計測している。見積もりを設定しておき、タスクを DONE にした時の差分が前後10分ある場合は、要因の入力を求めるようにカスタマイズまでしている。

大幅に差がある時は、だいたい設計理解や達成条件が甘いことが多い。

また、ストーリーポイントによる見積もりができるよう設定をいじっている。

日報

Emacs。 clocktable で 1日の終わりにその日の実行タスクを列挙する。 社内日報に書くネタを拾い、そのまま org mode で記述 → markdown にエクスポートしてSlackに提出するワークフローになっている。

ノートテイキング

Emacs の Org-roam を使っている。

いわゆる Zettelkasten¹ でメモが取れるプラグイン。2024年にエンジニアに転職した時から愛用。 勉強やら仕事やらプライベートやらの全てをぶちこんでいる。

ちなみに Emacs の設定は 2024年初頭の ChatGPT によるバイブコーディングによるものなので、酷い有様。いつか手を入れたい。

PC間でのデータ共有

Syncthingを利用。前述のEmacsによるノート、タスクなどの諸々を同期。仕事に関するものは共有しないよう除外設定をしている。 常にラズパイがハブとなっているため、WindowsとMac の片方だけ開いている状態でも問題なく同期可能。データにコンフリクトは起きない。

キーボード・マウス

2020年6月4日に購入した Keychron K2 を愛用中。アルミフレームの茶軸です。 転職前は自前の Macbook に繋いでいたが、今はほぼ Windows 専属に。

kinesis advantage 360 がほしい。 マウスは Logicool の M575 を使用。

モニター

LG 27MP89HM-S をメインに使用。右側に BoYata のノートPCスタンドを置き、その上に Windows を置いている。
左側には モバイルディスプレイを縦置きしているので 3画面状態。
cocopar15.6インチ
KUUVAN タブレット スタンド

元の記事を読む

小学生の時にどうぶつの森+を散々プレイしてたのが懐かしい。

クルクルランドとかバルーンファイトを散々やった。 ファミコンを終わりにすると、画面がけけソングが流れた自室に戻ってくる。コンポの位置によって音量が変わるから、音が大きかったり小さかったり。

あの静けさ居心地良かったな〜。ゲーム内時間も夕方で、実時間も夕方だった。

そういえば e+ だとGBAと連携できて、カードをスラッシュするとミニゲームができたな

あの時のどうぶつの森じゃないと感じられない世界観がある気がする。

ただノスタルジーを感じてるだけかな？

元の記事を読む

ここ最近恒例の月一エヴァ。 旧劇から全て見てきたけど、トップクラスに面白かった。序の次に好きかも。

昔見た時はキャラの心情もストーリーもよくわからなかったけど、 シンを見てキャラクターの気持ちを知っていたので、「あ〜ミサトさん、本当はシンジ君が心配だけど、ヴィレクルーに示しがつかないからわざと冷たくしてるのかな〜」とか「綾波はマジで別人だから、綾波から見たらシンジ君がヒスってるの全く意味わからないだろうな〜」とか、いっぱい想像できた。

昔見たときは、話についていくのがやっと（カヲルくんが13番目に堕とされた云々あたりは今もついて行けていない）だったけど、視聴済みなのでキャラの心情を想像する余裕ができていたのかもしれない。 特にシンジ君の気持ちがかなりわかった。シンジ君からしてみたらめちゃくちゃだな...

• 起きたらなんか14年経ってる
• みんな冷たい
• 綾波救えてない
• 救えてるじゃん...（救えてない
• 綾波の様子がおかしい
• カヲルくんが優しい
• そんなカヲルくんに、地上をめちゃくちゃにしたきっかけがアナタとか言われる
• 冬月に、綾波はママのクローンだぞって言われる
• 頭ぐわんぐわん

こんな状態でカヲルくんに「世界を戻せる」とか言われて希望を持っちゃって、「やっぱやめよう」なんて急にはしご外れたら、そりゃ強行突破しちゃいます

そして最後の予告はやっぱり最高ですね。

その後食べたマックのドラクエバーガー「ザク切りポテト&肉厚ビーフ やみつきコンソメペッパーマヨ」がとても美味しかった。 前のエヴァコラボの綾波バーガーも同じくポテトパティが使われていて美味しかった記憶。ポテトパティ、ハズレ無し

元の記事を読む

YouTubeで動画を再生

TODOリスト作成が大事

TDDの最初のステップとして、システムが満たすべき要件を列挙していく

例: マインドマップのノード操作

- [ ] ノードをクリックすることで選択状態になる
- [ ] ノードを選択状態で Tabキー を押下することで、子ノードを追加する
- [ ] ノードを選択状態で Enterキー を押下することで、兄弟ノードを追加する
- [ ] ノードを選択状態で Deleteキー を押下することで、対象ノードを削除する
- [ ] ルートノードを選択状態で Enterキー を押下しても、兄弟ノードが追加されない
...etc

思いつく限りのケースを列挙した後、テスト容易性・重要性を高めるようブラッシュアップする。 具体的にはテストしにくい要素（入出力やUI操作）を切り離した表現に直していく。

すると、以下のように表現できる。

- [ ] ルートノードに対する追加・削除操作
  - [ ] ルートノードを選択状態にできる
  - [ ] ルートノードを解除状態にできる
  - [ ] 選択状態を変更したとき、更新日時はこうしんしない
  - [ ] 子ノードを新規追加できる
  - [ ] 兄弟ノードを新規追加できない
  - [ ] 削除できない
- [ ] 通常ノードに対する追加・削除操作
  - [ ] 選択状態にできる
  - [ ] 解除状態にできる
  - [ ] 対象ノードの子ノードを新規作成できる
  - [ ] 対象ノードの兄弟ノードを新規作成できる
  - [ ] 対象ノードを削除できる
... etc

ドメインロジックじゃん。

Vue.jsを使っているので、ノード操作をuseNodeというComposablesに切り出した。

テスト容易なTODOを作成する過程で、UIとロジックを強制的に切り離さざるを得なくなるのが嬉しい。 AIにコードを書かせてもUIとロジックが混じらないし、1つのTODOごとに開発ないしはレビューができるので、品質が担保しやすい。

プロジェクトをコントロールできている感があって良い。気持ちが良い。最高、楽しすぎる。

ちなみに今は UI側って TDD でどうやるんだよ...ﾄﾎﾎ... というところで立ち往生している。

参考にしている資料

TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング
テスト駆動開発
単体テストの考え方/使い方

元の記事を読む

• 外部リンクを新規タブで開く場合、aタグに noreferrer, noopener 属性を付ける必要はない
• Disqusの Affiliate link のチェックを外す

経緯: target="_blank" のリンクが開かない

このブログでは、外部リンクに target="_blank" を付けることで、デフォルトで新しいタブを開くようにしている。

注記 2026/01/17時点では Nuxt Content でブログを書いていますが、当時は Hugo で作成していました。

ところが、本番環境に記事を公開して閲覧していたところ、外部リンクが正しく開かない現象に遭遇した。 具体的には、リンク押下後に Google Chrome ではアドレスバーに about:blank と表示され、新規タブで真っ白なページが開く。

Safari では、アドレスバーに遷移元のURLが表示され、新規タブで真っ白なページが表示される。

さらに奇妙なのは、この挙動が一定ではない点。 例えば「1回目は正しくリンク先が開くのに、2回目以降は真っ白なタブになってしまう」場合もあれば、「最初のクリックから真っ白なタブが開く」場合もある。

ただ、新規タブを開くを押下 or Command + クリックすると正常に開く。

まとめると👇️

• target="_blank" なリンクをクリックすると、真っ白なページが開く
• 新規タブのアドレスバーの値がブラウザによって異なる
• 真っ白なタブが開くタイミングにばらつきがある
• 新しいタブで開く は問題ない

🤔????

なんだこれ...

原因

クリックイベントを補足しているスクリプトを調べたところ、Disqus の一部スクリプトが関係していそうだった。 Disqus はウェブサイトやブログにコメントを追加できるサービス。 2007年頃の立ち上げから2013年頃に向けてバズった模様。それ移行も「Disqus導入してみた」系の記事は散見され、私も Hugo で作成している本ブログに導入した。 それが 2024年8月初旬頃。

Disqus には、外部リンクを自動的にアフィリエイトリンクに差し替える Affiliate Links 機能がある。これにより収益を得ている模様。 The Disqus Affiliated Links Program

Disqusで新しいサイトを作成するとデフォルトで有効化されている。

これが有効だと、記事内リンクのクリックをスクリプトで捕捉し、アフィリエイトリンク先にリダイレクトする。 この機能を無効化することでスクリプトが読み込まれなくなり、正常に新規タブで外部リンクを開けるようになる。

おそらく新規タブを開いた後に非同期で取得したリンクにリダイレクトをさせる処理があり、それが何らかの理由で、うまくいってなかったっぽい。

opener で新規タブの location をアフィリエイトサイトのリンクに変更しているが、nopener 属性のせいでうまくいかない...というストーリーかと思ったが、それだとすべての target="_blank" なリンクが開けなくなるし、そもそも元タブから新規タブのURLを変更するのはlocationじゃない気がするし...

うーん、よくわからない

解決方法

とりあえずDisqusのアフィリエイトリンク設定を無効にすること

1. Disqus Advanced Settings にアクセス
2. affiliate links のチェックを外す

追記 2025-09-14

今動作を確認したところ、

• アフィリエイトリンク機能が有効
• target="_blank" なリンク

でも問題なく遷移できた。

テスト用ページ

Disqus Affiliate Links テスト

執筆時は確かに記事冒頭の動作だった気がするけど...

新規タブで開きたい <a>タグ の属性はどうすべきか

良い機会なので調べ直してみた。

• noreferrer
  • ページA → ページB の遷移時に、 HTTP Referer ヘッダの送信を省略する
• noopener
  • ページA → ページB の遷移時に、 window.opener を null に設定する
  • HTTP Referer ヘッダは送信される
• noreferrer を設定すると、 noopener の設定が自動付与される
• window.opener.location = "<URL>" のように書き換えると、ページAのタブを任意のページCに遷移できる
  • この仕様を用いた攻撃を Tabnabbing という
  • Tabnabbing
• 今のモダンなブラウザでは target="_blank" なタグには暗黙的に noopener 相当の処理が自動付与される
  • Target=_blank implies rel=noopener | Stefan Judis Web Development
  • つまり、window.opener が null となる
• noreferrer はリファラを一切渡さないため、アクセス解析に支障をもたらす
  • 別タブへのリンク記述「target="_blank"とrel="noopener noreferrer"」の見直しを - 株式会社真摯
• Referer情報をどのくらい含めるかは Referrer-Policy で設定する
  • デフォは strict-origin-when-cross-origin

まとめ

• 単なる技術ブログでは外部リンクに
  • noreferrer属性 は不要
  • noopener属性 も明示しなくていい

元の記事を読む

2024年6月から自宅サーバで「おうちGoogleフォト」を運用している。 スマホで撮影した写真・動画を事実上無制限に保存して快適に閲覧ができる。

遠方の両親にはアルバムを共有。モバイルアプリがあるのでスマホから見てもらえる。

運用開始から約1年、安定稼働しているため、構築手順やハマりどころなどを振り返っておく。

モチベ

2024年に第一子が生まれ、写真・動画が一気に増えた。 それまで Google フォト のフリープランで運用していたが、無制限が終了したことで容量が 16GB ほどに制限されており、さすがに限界を迎えた。
Googleフォトの容量無制限無料バックアップ、2021年5月末で終了

容量を気にせずバンバン撮りたいので、👇の目標を立てた。

1. 事実上、無限に保存できること
2. スマホから保存・閲覧できること
3. サブスクしないこと
4. Google フォトからデータ移行できること
5. 遠方の両親にもシェアできること

現在（2025/08）のデータは合計265.6GBあるため、もしサブスクで運用すると...

• iCloud 2TB ¥1,500/月
• Google 2TB ¥1,450/月
• Amazonフォト は動画が5GBまでなので却下
• みてね は動画一本の長さが2分までに制限されるようなので却下

Googleでも ¥17,400/年 かかる模様

この記事では、

1. フォトストレージの構築（1.2.3.4.）
2. 遠隔地の写真をシェアする(5.)

という2つのゴールに分けて解説。

完成図

LAN 内の Immich サーバが Cloudflare を通じて外部公開される様子。モバイルアプリからはトークン、WebアプリからはSSO認証を通じてアクセスする。

• 登場人物
  1. Immich: 写真・動画管理用のOSSアプリケーション
  2. Raspberry Pi: Immichをホストするサーバ
  3. HDD・ケース: DB,写真の保存領域
  4. Cloudflare: LAN外との通信用のドメイン、トンネリング

ゴール1: フォトストレージの構築

必要なもの

写真管理用のアプリケーションとそれをホストするサーバ、そして保存領域。

アプリケーション

OSSのフォトアプリケーションはたくさんある。我が家はスマホだけで写真を撮るのでモバイルアプリが必須。

👇️の比較表から見たときにモバイルアプリとアルバム機能がある Immich を採用。Googleフォトライクなアプリで、別のツールを使用することでGoogle フォトからのデータ移行（後述）もサポートしている。

サーバ

Raspberry Pi 4 にした。好みです。アクセサリとともに。

• ラズベリーパイ 4 コンピューターモデルB 8GB
• Miuzei 最新 Raspberry Pi 4 ケース
• KIOXIA(キオクシア) 旧東芝メモリ microSD 64GB
  SDはOSのインストール用に必要

Immichの 必須要件 をクリアしている必要はあるので注意。

保存領域

容量については物理HDDを2つ（1つはバックアップ用）用意。

• WESTERN DIGITAL 3.5インチ内蔵HDD
• LHR-2BDPU3ES

HDDを裸て使ってみたかった

さて、必要なものが揃ったら次にラズパイをセットアップします

ラズパイとHDDのセットアップ

OSのインストール

公式に従います。OSを入れたSDカードをラズパイに指してbootする。
Getting started - Raspberry Pi Documentation

ローカルIP固定化

ラズパイが起動したらローカルIPを固定する。DHCPによる自動割り当てでIPが変わってしまうので、固定化しておくと楽。

ルータのDHCP設定で、ラズパイの有線LANのMACアドレスに対して任意のIPアドレスを紐づけている（画像の一番下の行）。 MACアドレスは以下で調べる。

1. ラズパイでをシェルを開く
2. ip a を実行する
3. eth0: の link/ether の後に書いてある

wifiを使うなら wlan0 を探すと良いが、速度を考えると有線がいいでしょう（今回は画像系なので特に）。

なお、使いたいIPアドレスが別の機器に設定されている場合、そのままでは手動割り当てができない。どうしても特定のIPアドレス（今回の例では 11.14）を使いたい場合は、以下の手順に従う。

1. 使いたいIPアドレスを使っている機器を、ネットワークから切断
2. ルータを再起動してIPアドレスの割り当てをリセット
3. 手動設定

一般的に利用可能な番号から順に割り当てることが多く、結果として若い番号から埋まっていく傾向がある模様（機種や設定で変わる）。

また、『ラズパイ ip 固定』で検索すると、 /etc/dhcpcd.conf を編集したり NetworkManager を設定するような記事がでてくるが、私の環境ではどれもうまくいかず...。ラズパイ公式も、ルーターでアドレス指定してねと言っている。
Assign a static IP address

VNCやSSHによる遠隔操作

ラズパイのセットアップが終わったら、毎度モニタにつなぐのも面倒なので遠隔でリモートデスクトップできるようにする。
VNCでRaspberry Piにリモートデスクトップ接続

sshしたときにパスワードを打つのも面倒なので、公開鍵認証しておくと楽ちん
ラズベリーパイをリモート操作（SSHコマンド）

ハードディスクのフォーマットとパーティション設定

次に、HDDケースにHDDを設置して、ラズパイとHDDケースをつなげる。

その後、以下を参考に2つのHDDをマウント。
Raspberry PiでHDDをマウントする

_私の場合、メインは /mnt/hdd1 、バックアップ用は /mnt/hdd2 にマウントした。

これで、ラズパイにOSを入れ、ローカルIPを固定し、HDDをマウントできた。次はImmichの導入。

Immichのセットアップ

Dockerでのセットアップと設定ファイルの用意

公式のクイックスタートと同じくDockerで立ち上げるのが楽。

なお .env ファイルのうち写真アップロード先とDB保存先は、先程マウントした hdd1 にしておく。

UPLOAD_LOCATION=/mnt/hdd1/immich/images
DB_DATA_LOCATION=/mnt/hdd1/immich/postgres

Immich管理アカウント作成

コンテナ立ち上げが成功すると、 http://<machine-ip-address>:2283 でImmichにアクセスできる。アクセス後はadminユーザの作成をする

一般ユーザアカウントも作成できるので、そのまま私・妻用のアカウントを作った。

また、ここでStorageTemplateの設定を確認しておくといい👇️

StorageTemplate

写真や動画の保存先・フォルダ構造やファイル名の付け方の設定のこと。私は UPLOAD_LOCATION/library/ユーザ名/2022/2022-02-03/IMAGE_56437.jpg のような形式で保存されるようにしている。

設定変更以降に追加した写真から反映され、変更前に追加済であったものは、 ジョブ → ストレージテンプレートの移行 ボタンを押すことで反映可能。

私の場合、Google フォト から大量の写真を移動してきたあとに設定をしたため、反映にかなりの時間がかかった。好みがあれば予め設定しておけると嬉しい。

ここまでで、ラズパイ・HDD・Immich のセットアップが完了。次は Googleフォト にある写真・動画を Immich に移行する。

Googleフォトからの移行

immich-go を使う。Google フォトの 写真をImmichで管理する保存領域に移行できるコマンドラインツールです。

必要な材料👇️

1. immich-go
2. Google Takeout
   • Google アカウントに保存されているデータをエクスポートしたもの
3. ユーザアカウントごとのImmich API キー
   • Immichに対してアプリケーション外から操作をする際に必要な鍵

具体的には、

./immich-go -server=http://<machine-ip-address>:2283 -key=<Immichで作成したAPI キー> upload -create-albums -google-photos <ダウンロードしたGoogle Photo Takeout のパス>

とすることで、Googleから落としてきたコンテンツをImmichの任意ユーザのコンテンツとして取り込むことができる。

写真の重複

バックアップ前に“写真がどこにあるか”を整理しておく必要がある。過去のすべての写真がスマホに入っていれば Immich のモバイルアプリを起動して、スマホからバックアップするだけでOK。

しかし実際には「Googleフォトだけにある写真」「スマホだけにある写真」「両方にある写真」が混在している。

// Google フォトに保存された写真と、スマホに保存された写真が一部重なってるイメージ
時系列:      2008 ------2017-------2023----------> 新しい

Googleフォト: [===========++++++++++]
スマホ       :           [++++++++++==========]

同じ写真がバックアップされてしまうと、容量がもったいない。

今回は、2008〜2023年は Google フォトから移行し、それ以降はスマホから直接バックアップすることにした。

厳密に分けることは難しく2024年前後に重複が発生するが、Immich には重複検出・削除機能があるため、多少は許容範囲。

immich-go

immich-go をダウンロードする。 <> Code 押下 > Download ZIP でOK。

PC内の好きな場所においておく。

Google Takeout

以下のリンクから Google Takeout にアクセスして、エクスポートする。 https://takeout.google.com/

Google フォトのみチェックボックスをONにして 次のステップ を押下

エクスポートを作成 を押下

しばらく待つとGoogleからメールが届く

メール内リンクに飛ぶと、件数ごとにダウンロードボタンが設置されている。順次押下してダウンロードしていけばOK。zipファイルがダウンロードされるはず。

件数が多すぎて面倒であれば、エクスポート前にファイルサイズを大きめに設定しておくといい。

Immich API キー

お次に API キー を発行する。immich-go から Immich のユーザアカウントに対して操作する際に必要な鍵。ユーザアカウント事に発行する。

手順

1. Immichにログイン
2. アカウント設定
3. APIキー
4. 新しいAPIキー
5. 任意の名前をつけて作成押下
6. 新しいキーが発行されるのでコピーしておく

immich-goで移行

コマンドを実行する前に、Google Takeout の zip を解凍して中身を確認する。今回は 2024年以降の写真はスマホからバックアップする方針のため、その期間を含む zip は不要。使用しないファイルはどこかに移動しておく

必要な zip ファイルを準備ができたら、 immich-go をダウンロードしたディレクトリへ移動して、次のコマンドを実行。

./immich-go -server=http://<machine-ip-address>:2283 -key=<Immichで作成したAPI キー> upload -create-albums -google-photos /takeoutがあるディレクトリ名/takeout-*.zip

なお --dry-run オプションをつけることで、実行される処理を事前に確認できる。

コマンド実行後、しばらく待てば Immich に画像や動画が取り込まれている。私のアカウントは写真が多かったためコマンドを実行して寝た🛌。翌朝には終わっていた。

モバイルアプリの設定

次に Immich モバイルアプリをダウンロードしてセッティング。

ダウンロード・ログイン・バックアップ、すべて以下のドキュメントに従えば無問題️
https://immich.app/docs/features/mobile-app/

アプリ起動直後は、 http://<machine-ip-address>:2283 でアクセス

作成したユーザのメールアドレスとパスワードを打ち込めばログイン可能

次にスマホのローカルに入っている写真・動画のバックアップ設定を行う
https://immich.app/docs/features/mobile-app/#backup

自動バックアップ設定もしておくと良い
https://immich.app/docs/features/automatic-backup

これで、スマホで取った写真をImmich経由でHDDに保存し、そのまま閲覧できるようになる。

HDD1をバックアップする

最後にHDD1のデータをHDD2にバックアップするよう設定したい。HDD1がだめになったらすべての資産が消えてしまうので

Borg を使う。差分バックアップツール。 Immich公式でも borg によるバックアップ方法が紹介されているため採用。

手順は公式ドキュメントに従う。ドキュメント中の “Borg backup template” をベースにしたスクリプトをimmich-borg.shとして保存し、毎週土曜の午前1:00に実行されるようcrontabを設定。

0 1 * * 6 /immich-borg.sh

Done

これで、スマホから Immich にログインして、撮影した写真や動画をそのまま HDD にバックアップできる環境が整った。 当初の条件もクリア

• 1. 事実上、無限に写真と動画が保存できること
• 2. スマホから保存・閲覧できること
• 3. サブスクはしないこと
• 4. Google フォトに保存した大量のコンテンツを引き継げること

週に一度は別のHDDにもバックアップを行う¹。

加えて Immich のアルバム機能を使えば、「息子用アルバム」や「旅行用アルバム」を作成し、私と妻がそれぞれ写真を追加できる。これまで Google フォトや LINE で行っていたスタイルも実現できる。

これにて、フォトストレージの構築はクリア。家庭内の写真管理は解決した。

ゴール2: 遠隔地の家族に安全に写真をシェアする

次の課題は両親への共有。
いままで私は LINE で親に写真を送っていた。が、結構面倒...😇 『一箇所にまとめておけば、好きなときに見てもらえる仕組み』がほしい。

幸いImmichであれば複数アカウントが作成できる。アルバム機能もあり、アルバム事に権限管理も可。 親用のアカウントを作り、両親はアプリを開いてアルバムをタップすれば、愛孫のかわいい〜👶写真を眺めることができるのでは🤔

しかし、自宅ホストのサーバである以上、外部からの安全なアクセス手段が必要。

この課題を解決するために、 Cloudflare Tunnel を使う。

Cloudflare Tunnel × Cloudflare Access

Cloudflare Tunnelは、軽量ツール（cloudflared）をサーバに入れることで公開IPやポート開放なしに外部公開できるもの。通信はCloudflareを経由する。

2023年6月ごろに Immich公式Discord に「どうやってインターネットに公開するのがよいか？」という議論があり、一定数のユーザーが Cloudflare Tunnel を採用していると述べている。

更に、Cloudflare Access による認証を組み合わせれば限定公開も容易。

なお、100MB以上のファイルをアップロードする際には制限があるので注意が必要（今回は読み込みオンリーなので問題はなし）

完成図（Cloudflare）

Cloudflare Registry でドメインを取得する

Cloudflareにサインアップし、ダッシュボードから ドメインの登録 > ドメイン登録 に遷移して任意のドメインを取得。 （取得しなくてもいい）

tunnelの作成

ドメインの購入が完了したらトンネルを作成。

手順

1. ダッシュボード
2. サイドメニュー
3. Zero Trust
4. ネットワーク
5. Tunnels
6. トンネルを作成する

1. Cloudflaredを選択する
2. 任意の名前をつけて保存
3. 次へ

Debian を選択して、表示されるコマンドをサーバで実行。

サーバ側でのコマンドが成功すると、このようにコネクタIDと接続済みステータスが表示されるので次へ押下

以下を入力して保存を押下

• サブドメイン: 任意の名前
• ドメイン: Cloudflareで購入したドメインがプルダウンで表示されるため選択
• サービス: HTTP
• URL: localhost:2283

これで、Cloudflare経由で外部公開できた。設定したURLを打ち込むことで、アクセス可能となっているはず。

Cloudflare Accessで認証機能を追加する

しかし、アクセス制限がついてなくて危険なので設定していく。

Webブラウザからの認証

まずはLAN外からブラウザで Immich へアクセスしたときに、Email認証ができるようにを設定。

ポリシーの追加画面に移動

1. Access
2. ポリシー
3. ポリシーを追加する

お次にポリシーを設定

1. ポリシー名に任意の名前を設定
2. セレクターで Emails を選択
3. 認証時にSSO対象となるメールアドレスを追加する
4. 保存

以下のように追加される

続いて、作成したポリシーをアプリケーションに設定する。

1. Access
2. アプリケーション
3. アプリケーションを追加する

次にアプリケーションの種類を選ぶ

1. セルフホスト
2. 選択する

アプリケーションの情報を入力

1. 任意のアプリケーション名を追加
2. パブリックホスト名を追加をクリック > パブリックホストの入力欄が出てくる
3. サブドメイン・ドメインは先程のTunnelと同様のものを入力
4. Access ポリシー欄で、 既存のポリシーを選択 を押下

1. 先ほど作成したポリシーがでてくるのでチェックして確認
2. 次へ で進んでいくと、保存ボタンが出てくるので保存

以上。再び、設定したURLにブラウザでアクセスしてみると、SSO認証画面が表示されるはず

ポリシーに追加した Email を入力すればメールが届き、メールに書いてあるパスコードを入力することで認証を突破できる。突破後はImmichのログイン画面に遷移する。（画像ではGoogle のOAuthでも認証できるようにしている）

モバイルアプリからの認証

次に、Immichモバイルアプリからアクセスする方法。モバイルアプリではブラウザのように認証画面に遷移できないため、そのままではログインできない。

そこで Cloudflareの Service Token と、Immichモバイルアプリの設定 カスタムプロキシヘッダ設定 を活用する。

Service Token は、アプリやプログラムから Cloudflare の制限されたリソースへとアクセスするための鍵。

Immich モバイルアプリには、サーバへアクセスする際のリクエストに任意の値を含めることができる カスタムプロキシヘッダ 設定があるため、こちらにトークンを設定することで認証を突破できる。

Cloudflare上の設定

Service Token を作成する

1. Cloudflare Zero Trustホーム
2. Access
3. サービス認証
4. サービストークンを作成する

1. 任意のトークン名を入力
2. 任意の期限を入力
3. トークンを生成する

クライアントID と クライアントシークレット が表示されるのでコピーしておく。

次に、再びポリシーを作成。セレクターから Service Token を選び、先ほど作成したトークンをプルダウンから選択。

ポリシーを保存し、先ほど作成したアプリケーションにこのポリシーを設定。

1. Access
2. アプリケーション
3. 作成したアプリケーション名の三点ドット
4. 編集

アプリケーションにポリシーを追加

1. タグ: ポリシー
2. 既存のポリシーを選択
3. 作成した Service Tokenのポリシーを選択
4. 確認
5. アプリケーションを保存

これでCloudflare側の設定は完了。

Immich モバイルアプリ上の設定

お次はImmichのモバイルアプリで、アクセス時にトークンを含めるように設定する。

1. Immichモバイルアプリのログイン画面を開く
2. 歯車マークをタップ
3. カスタムプロキシヘッダをタップ
4. プロキシヘッダに以下を入力します
   1. 生成したクライアントIDのヘッダーと値
   2. クライアントシークレットのヘッダーと値

以上。これで、Immichモバイルアプリから外部向けURLにアクセスしても認証を通過でき、作成済みアカウントでログインすれば写真を閲覧できる。

つまり、以下の手順を4人分実施すれば、両親も自分のスマホから孫の写真を見られるようになる。

1. Immichで両親のアカウントを作成する
2. 両親のアカウントに、息子のアルバムへの閲覧権限を付与する
3. 両親のスマホにモバイルアプリをダウンロードする
4. モバイルアプリでカスタムプロキシヘッダを設定
5. 各自のアカウントでログイン

Done👍️

これにて、

• 遠隔地の家族に安全に写真をシェアする

クリア。

費用

Google One (2TB) は ¥17,400/年。 初期費用はかかるものの、2年弱運用できればおとく...?

メリット

• サブスク費用が不要（
• HDD増設すれば容量は実質無限
• おもしろい

デメリット

• 初期構築の手間
• HDDが壊れたときのリスクが大きい。クラウドと比べてリスク分散も難しい
• Immich のアップデートが頻繁にある、破壊的な変更がたまにあるため、しっかり調べて対応しないといけない

今後の課題

• もう一箇所バックアップを用意したい
• 週1のバックアップ用にもかかわらず、HDD2が常時接続＆回転しっぱなし。

元の記事を読む

コンソール

1. 開発者ツール
2. 歯車マーク(⚙️)
3. コンソール > 移動時にログを保持にチェック

ネットワーク

1. 開発者ツール
2. 歯車マーク(⚙️)
3. ネットワーク > ログを保持にチェック

元の記事を読む

公式でもUXの関係でサポートしていないと明示されており、モーダルから別のモーダルを呼び出すことは可能だが、元のモーダルは消えてしまう。

Toggle between modals

なぜ消えるか

通常、Bootstrap5のモーダルはdata属性を用いて展開する。

<button class="btn btn-primary" data-bs-target="#modalA" data-bs-toggle="modal">
  Open second modal
</button>

このとき、bootstrap.js で呼ばれる処理の中に、すでに開いているモーダルがある場合は閉じる処理が入っているため、展開中のものは閉じられてしまう。

// avoid conflict when clicking modal toggler while another one is open
const alreadyOpen = SelectorEngine.findOne(OPEN_SELECTOR)
if (alreadyOpen) {
  Modal.getInstance(alreadyOpen).hide()
}

const data = Modal.getOrCreateInstance(target)

data.toggle(this)

js/src/modal.js

そのため、data属性を用いたモーダル展開を使うことはできない。

解決策

代わりにモーダルインスタンスの show() メソッドを使う。

js/src/modal.js

show() には上述の処理は含まれてないため複数のモーダルを同時に表示できる。 あとはモーダルと背景となる backdrop の z-index を調整してうまく層を作ればいい。

サンプル

以下は jQuery でモーダルの表示トリガーを監視し、モーダルの z-index と backdrop を管理することで入れ子モーダルを実装している。

js

$(function () {
  $(document).on('click', '.show-modal', function () {
    const nextId = $(this).data('show-modal')
    if (nextId) showModal(nextId)
  })

  function showModal(modalId) {
    const newModal = $('#' + modalId)
    const modalInstance = new bootstrap.Modal(newModal[0])
    modalInstance.show()

    _setupModalZIndex(newModal)
    _setupBackdrop(modalId)
    _cleanupModal(newModal, modalId)
  }

  /**
   * モーダルのz-indexを設定する
   * z-index = 1040 + 10 * 表示中のモーダル数（Bootstrap標準の重なり順に準拠）
   * ex: 1段目: 1040, 2段目: 1050, 3段目: 1060, ...
   */
  function _setupModalZIndex(modal) {
    modal.one('shown.bs.modal', function () {
      const modalCount = $('.modal.show').length
      const zIndex = 1040 + 10 * modalCount
      modal.css('z-index', zIndex)
      modal.data('zIndex', zIndex) // backdropで使うために保存しておく
    })
  }

  /**
   * モーダルbackdropのz-indexを調整する
   * ex: 1段目: 1039, 2段目: 1049, 3段目: 1059, ...
   */
  function _setupBackdrop(modalId) {
    // z-index の設定は shown.bs.modal の後でないと正しい数にならない
    $('#' + modalId).one('shown.bs.modal', function () {
      const modal = $(this)
      const zIndex = modal.data('zIndex')

      const backdrop = $('.modal-backdrop').not('.modal-stack').last()

      backdrop
        .css('z-index', zIndex - 1) // モーダルより1つ下に配置
        .addClass('modal-stack')
        .attr('data-backdrop-for', modalId) // 削除処理のためにモーダルIDで関連付け
    })
  }

  /**
   * モーダルが閉じられたとき（hidden.bs.modal）に、対応するbackdropを削除し、
   * フォーカスを親モーダルかbodyへ逃がす
   */
  function _cleanupModal(modal, modalId) {
    modal.one('hidden.bs.modal', () => {
      $(`.modal-backdrop[data-backdrop-for="${modalId}"]`).remove()

      const openModals = $('.modal.show')
      if (openModals.length > 0) {
        // 親モーダルにフォーカスを当てる
        const lastModal = openModals.last()
        const focusTarget = lastModal
          .find('[autofocus], .btn-close, .btn, input, select')
          .first()
        if (focusTarget.length) focusTarget.trigger('focus')
      } else {
        // 最後のモーダルを閉じた場合、bodyにフォーカスを逃がす（アクセシビリティ対策）
        $(document.activeElement).trigger('blur')
        $('body').trigger('focus')
      }
    })
  }
})

html

<link
  href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"
  rel="stylesheet"
/>
<script src="https://code.jquery.com/jquery-3.7.1.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js"></script>

<button class="btn btn-primary show-modal" data-show-modal="modal1">
  Open Modal 1
</button>

<!-- モーダル1 -->
<div class="modal" id="modal1" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Modal 1</h5>
        <button
          type="button"
          class="btn-close"
          data-bs-dismiss="modal"
        ></button>
      </div>
      <div class="modal-body">
        <button class="btn btn-secondary show-modal" data-show-modal="modal2">
          Open Modal 2
        </button>
      </div>
    </div>
  </div>
</div>

<!-- モーダル2 -->
<div class="modal" id="modal2" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Modal 2</h5>
        <button
          type="button"
          class="btn-close"
          data-bs-dismiss="modal"
        ></button>
      </div>
      <div class="modal-body">
        <button class="btn btn-secondary show-modal" data-show-modal="modal3">
          Open Modal 3
        </button>
      </div>
    </div>
  </div>
</div>

<!-- モーダル3 -->
<div class="modal" id="modal3" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Modal 3</h5>
        <button
          type="button"
          class="btn-close"
          data-bs-dismiss="modal"
        ></button>
      </div>
      <div class="modal-body">
        <button class="btn btn-secondary show-modal" data-show-modal="modal4">
          Open Modal 4
        </button>
      </div>
    </div>
  </div>
</div>

<!-- モーダル4 -->
<div class="modal" id="modal4" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Modal 4</h5>
        <button
          type="button"
          class="btn-close"
          data-bs-dismiss="modal"
        ></button>
      </div>
      <div class="modal-body">
        <button class="btn btn-secondary show-modal" data-show-modal="modal5">
          Open Modal 5
        </button>
      </div>
    </div>
  </div>
</div>

<!-- モーダル5 -->
<div class="modal" id="modal5" tabindex="-1">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title">Modal 5</h5>
        <button
          type="button"
          class="btn-close"
          data-bs-dismiss="modal"
        ></button>
      </div>
      <div class="modal-body">
        <p>Last modal (5)</p>
      </div>
    </div>
  </div>
</div>

モーダルからモーダルを開くたび、モーダルと backdrop の z-index を調整することで層を形成している。

      _______________
     /               /   Modal 4
    / z-index:1070  /
   /_______________/
------ -index:1069 ----- Backdrop 4


      _______________
     /               /   Modal 3
    / z-index:1060  /
   /_______________/
----- z-index:1059 ----- Backdrop 3


      _______________
     /               /    Modal 2
    / z-index:1050  /
   /_______________/
------ z-index:1049 ----- Backdrop 2


      _______________
     /               /    Modal 1
    / z-index:1040  /
   /_______________/
------ z-index:1039 ----- Backdrop 1

モーダルを呼び出すボタンには

• show-modal クラス
• data-show-modal="モーダルのID"

をつける。 モーダル自体は通常の定義と変わらないため、使い心地にも違和感はない。

<button class="btn show-modal" data-show-modal="modal1">Open Modal 1</button>

デモ

元の記事を読む

実装や技術的な問題解決に取り組むことは楽しい一方、レビューを受ける際に「レビュワーの正解を探し当てる必要がある」と考えていた。

背景には、私が「中途未経験で業界に入った自分には圧倒的に知識と経験が足りない」という劣等感を抱いていたことと、前職の文脈が影響していたからだと思う。

自分がレビューをするようになって

自分自身がレビューをする立場になったことで、認識が大きく変わった。レビューは「試験」ではなく「お互い知見・判断を持ち寄り、より良いものを作るための対話の場」であることを実感した。 レビューをしているとき、自分が過去に経験した課題や良さそな解法を提案としてコメントするが、それが唯一の正解だとは思わない。あくまでも提案であり、より適した解法があればそちらを採用したいという思いでレビューしている。

自身のPRについたコメントは批判ではなく嬉しい意見として捉えられるようになり、レビューに対する過度な緊張がなくなった。

無謬性は存在しない

レビューを経てマージされたコードにも後から修正が入ったり、仕様変更でやり直しが発生することも少なくない。最善な選択は後でひっくり返ることを実感した。

逆に言えば、自分の提案や設計次第でプロダクト全体の質が変わることを強く意識するようにもなった。 ただ言われたとおりに作るのではなく、自らの判断や提案がプロダクトに影響を与えるというコントロール感を強く持てるようになった。より主体的に開発に関われるようになったかな。

なぜ今まで実感できていなかったのか

書いてみると当たり前だが、なぜ実感できていなかったのか。 「評価される側」という立場から抜け出せていなかったことと、前職で身についた文化の影響が大きかったのだと思う。

以前は役人として働いており、そこでの仕事は無謬性が極めて強く求められていた。 前例主義・形式主義・間違えないようにするための決裁というプロセス。

その文脈をこちらの世界に持ち込んでいたから「決裁 = レビュー」という変換をしていたのかもしれない。

これから

今後は、レビュー時のコメントの書き方にも、これまで以上に気を配っていきたい。 私自身が前述のような経験をしてきたからこそ、コメントを受け取る側のコンテキストによって心理的な負担の感じ方が変化することを理解している。

「これはあくまで一つの提案であり、私の意見が唯一の正解ではないよ」というスタンスが、コメントからも自然に伝わるようにしたい。一緒により良い選択肢を探す姿勢を言葉に込めることを意識していきます。

元の記事を読む

1. open ~/Library/Preferences/com.apple.symbolichotkeys.plist
2. Root > AppleSymbolicHotKeys > 61 > value > parameters
3. item 2 を 131072 に設定する
4. PCを再起動
5. システム設定 -> キーボード -> キーボードショートカット -> 入力ソース に shift + space が設定されていることを確認
6. shift + space で入力ソースを切り替えられることを確認

経緯

昨年から仕事で Windows を使うようになり、以前から私物の M1 MacBook Air で愛用していた Keycron k2(英字キー) をWindowsにもつなぐようになった。

英字配列のため IME の 日本語⇔英語 切り替えに設定が必須。 macでは control + space で変換していた（caps lock を control に置き換えて）

ところがWindowsだと（経緯は忘れたが）同様の設定ができず、結局 shift + space で運用することとした。

仕事用PCのほうが使用率が高いのでいつの間にか手癖が変わってしまい、mac使用時に shift + space を押してしまうタイプミスが頻発。 作業にならないので、入力ソースを切り替えるためのショートカットを変更しようとしたが...

shift + space のキーボードショートカットを設定できない

当方 macOS 15.5 だが、システム設定 → キーボード → キーボードショートカット で shift + space が設定できない。 打ち込んでも反応しない。

そこで調べていたところ、以下を記事を発見

macOS 한영전환키를 Shift+Space로 설정하기 (feat. Sonoma)

やはり shift + space は設定できないようだが、解決策が書いてある。

com.apple.symbolichotkeys.plist ファイルの中にある、 AppleSymbolicHotkeys のうち

• 60番が 前の入力ソースを選択
• 61番が 次の入力ソースを選択

に該当し、Item2 の値を 131072 というキーコードに書き換えることで shift + space を登録できる模様。

試してみたところ、PCを再起動することで入力ソース切り替えのショートカットに shift + space が反映された 🙌

これで、同じ使い心地で日本語と英語を切り替えられて快適。

元記事でも言及されているが、なぜショートカットに shift + space が登録できなんだろう。 （ほかアプリのショートカットとバッティングする可能性が高いとか？）

今のところ、常駐させているアプリケーション（Emacs, iTerm）とは衝突しておらず、問題なく使えている。

元の記事を読む