Posts on takeokunn's blog

nix-darwinのlinux-builderでNixOSを動かす

Sat, 10 Jan 2026 00:00:00 +0000

背景・動機

元々OrbStack VMでNixOSを動かしていたのだが、k8sを動かす時にOrbStackだと動かずDocker for Macだと動くという事象が発生した。

調査をした所、nix-darwinがlinux-builderというものをサポートしてることがわかったのでメモしておく。

https://scrapbox.io/kanna/nix_linux-builder

試したこと・やったこと

1. linux-builderについて調査

このあたりに纏まっている。

nix-darwinには modules/nix/linux-builder.nix が提供されており、 enable=true するだけで launchd.daemons に登録されるようだ。

2. nix-darwinを導入してみる

現状の設定は以下。

https://github.com/takeokunn/nixos-configuration/blob/9b70ffde2c5d0233c0c78b63a1ad36d2638d5268/nix-darwin/config/linux-builder.nix

{ lib, ... }:
{
 nix.linux-builder = {
 enable = true;
 ephemeral = false;
 systems = [ "aarch64-linux" "x86_64-linux" ];
 config = {
 boot.binfmt.emulatedSystems = [ "x86_64-linux" ];
 virtualisation = {
 cores = 6;
 memorySize = lib.mkForce (1024 * 16);
 diskSize = lib.mkForce (1024 * 200);
 };
 nix.settings = {
 experimental-features = [
 "nix-command"
 "flakes"
 ];
 };
 security.sudo.extraRules = [
 {
 users = [ "builder" ];
 commands = [
 {
 command = "ALL";
 options = [ "NOPASSWD" ];
 }
 ];
 }
 ];
 };
 };
}

3. 動いてることを確認する

take 部分はwhoamiに読み替えてください。

2025年12月個人的claude codeワークフロー

Tue, 30 Dec 2025 00:00:00 +0000

1. はじめに

Claude Codeを本格的に使い始めました。

最初はGitHub Copilotと同じ感覚で、コード生成ツールの延長として使っていたのですが、あるとき気づきました。「セキュリティレビューをお願いしたら、コードスタイルの指摘ばかり返ってきた」「昨日と同じ質問をしたのに、まったく違うフォーマットで回答された」「プロジェクトの規約を毎回説明するのが面倒」。これ、Claude Codeの問題じゃなくて、自分の使い方の問題でした。

試行錯誤を重ねるうちに、Claude Codeは単なるコード補完ツールではなく、適切に設定すればマルチエージェントシステムとして機能することに気づきました。

この記事では、構築したワークフローを共有します。

ちなみに、この記事も大半はClaude Codeに書いてもらいました。

2. 背景と設計哲学

2.1. 感じていた課題

Claude Codeを本格的に使い始める前、いくつかの課題を感じていました。

一番大きかったのは専門性の欠如です。単一のAIエージェントでは、コード品質・セキュリティ・テスト・ドキュメントなど複数のドメインにまたがるタスクをうまく処理できませんでした。セキュリティの観点でレビューをお願いしても、コードスタイルの指摘が混在して、本当に確認したいポイントが埋もれてしまいます。

出力の不安定性も悩みの種でした。構造化されたプロンプトなしでは、AIの応答品質やフォーマットが毎回異なります。昨日と同じ質問をしても、回答の形式がまったく違うということがよくありました。

繰り返しの説明にも時間を取られていました。同じパターンや好みを何度もAIに説明する必要があり、徒労感がありました。

2.2. 5つのルール

CLAUDE.mdには5つの critical ルールを定義しています。この5つが私のワークフローの根幹になっています。

サブエージェントへの委譲 : 親エージェントは方針決定とオーケストレーションに集中し、詳細な作業は専門エージェントに任せる
Serenaメモリの事前確認 : 実装前に必ず list_memories と read_memory でプロジェクトの規約やパターンを確認する
シンボルレベルの操作 : ファイル全体を読み込むのではなく、Serenaの find_symbol などでシンボル単位で操作する
perlでテキスト処理 : sed/awkは使わない。 perl -pe 's/foo/bar/g' で統一
英語で出力 : 出力は常に英語に統一

なぜこの5つなのか。1と2はマルチエージェント構成の核心、3はトークン効率の改善、4と5は出力の一貫性を担保するためです。

3. プロンプト設計の基盤

ここで紹介するプロンプトの多くは、Claude Code自身に生成させました。「こういう形式で書いて」と伝えて、その出力を調整しながら現在の形に至りました。

Claude Codeのプロンプトは構造化されたXMLで記述しています。

3.1. XMLによる構造化プロンプト

3.1.1. なぜXMLなのか

Markdownやプレーンテキストではなく、XMLを採用しました。これは公式のベストプラクティスではなく、個人的な経験に基づく選択です。

Anthropicの公式ドキュメントでは、XMLタグについて次のように説明されています:

There are no canonical “best” XML tags that Claude has been trained with in particular, although we recommend that your tag names make sense with the information they surround.

「The Rust Programming Language 日本語版」の読書記録

Thu, 25 Dec 2025 00:00:00 +0000

文献情報

出典: The Rust Programming Language 日本語版
著者: Rust日本語ドキュメント翻訳プロジェクト
参照日: 2025-12-25
種別: オンライン書籍

読む目的・背景

社内でRustを使っているため、業務で必要な知識として勉強する必要があった。他言語で得た知識で知ったかぶりせず、Rust固有の概念を正確に理解したい。特に所有権・借用・ライフタイム・スマートポインタといった概念の本質を理解することを目標とした。

重要ポイントと引用

所有権（Ownership）

Rustの各値は、所有者と呼ばれる変数と対応している。いかなる時も所有者は一つである。所有者がスコープから外れたら、値は破棄される。

— 第4章所有権を理解する

所有権はRustのもっとも特徴的な機能であり、ガベージコレクタなしでメモリ安全性を保証する仕組みになっている。 C/C++ではプログラマが手動でメモリを管理する必要があり、解放忘れ（メモリリーク）や二重解放といったバグが発生しやすかった。一方、JavaやPythonなどのGC言語では実行時のオーバーヘッドが発生する。 Rustは所有権システムによって、コンパイル時にメモリ管理の正しさを検証し、実行時コストなしで安全性を実現している。

所有権には3つのルールがある。

Rustの各値は所有者と呼ばれる変数をもつ
いかなる時も所有者は1つだけ
所有者がスコープから外れると、値は破棄される（ drop が呼ばれる）。

fn main() {
 let s1 = String::from("hello"); // s1が所有者
 let s2 = s1; // 所有権がs2にムーブ
 // println!("{}", s1); // エラー: s1は無効
 println!("{}", s2); // OK: s2が所有者
}

ヒープに確保されるデータ（ String など）は代入時に所有権がムーブする。スタックに確保される固定サイズのデータ（整数など）は Copy トレイトを実装しており、コピーされる。

借用（Borrowing）

関数の引数に参照を取ることを借用と呼びます。現実生活のように、誰かが何かを所有していたら、それを借りることができます。用が済んだら、返さなきゃいけないわけです。

— 第4章参照と借用

借用は所有権をムーブせずにデータにアクセスする仕組みになっている。関数に値を渡すたびに所有権が移動すると、呼び出し元で値が使えなくなり不便になる。借用を使えば、所有権を保持したまま一時的にデータへのアクセスを許可できる。

借用には2種類ある。不変参照（ &T ）は読み取り専用で、同時に複数存在できる。可変参照（ &mut T ）は書き込み可能だが、同時に1つしか存在できない。

blogをdev.toサポートした

Thu, 25 Dec 2025 00:00:00 +0000

背景・動機

takeokunn/blog でdev.toの記事を管理できるようにしたのでメモしておく。

試したこと・やったこと

1. 対応理由整理

takeokunn/blog は次の3つのターゲットに対してorg-roamでコンテンツ管理をしている。

Hugo
- Repo: https://github.com/takeokunn/blog/tree/main/hugo
- Url: https://www.takeokunn.org/
Zenn
- Repo: https://github.com/takeokunn/blog/tree/main/zenn
- Url: https://zenn.dev/takeokunn
PDF（Typst）
- Repo: https://github.com/takeokunn/blog/tree/main/typst
- Url: https://www.takeokunn.org/pdf/phperkaigi-2026-pamphlet.pdf

以前から英語でもブログを書きたいという欲求があった。ホスティング先はどこがよいのか検討した所、dev.to がなんだかんだ安牌であることがわかったので対応することにした。

2. NixでBuildできるようにする

flake.nix は以下。

https://github.com/takeokunn/blog/blob/main/devto/flake.nix

{
 packages = {
 build-devto = pkgs.stdenv.mkDerivation {
 name = "build-devto";
 src = ./.;
 nativeBuildInputs = with pkgs; [
 (emacsPkg.pkgs.withPackages (epkgs: (with epkgs.melpaPackages; [ ox-gfm ])))
 ];
 buildPhase = ''
 mkdir -p ./articles
 emacs --batch --load scripts/ox-devto.el --funcall export-org-devto-files
 '';
 installPhase = ''
 mkdir -p $out
 # Article Sync Format: articles/{slug}/article.json + article.md
 for dir in ./articles/*/; do
 if [ -f "$dir/article.json" ]; then
 cp -r "$dir" $out/
 fi
 done
 '';
 };
 };
}

ox-devto.el を適当に作り、 ox-gfm をdev.to用にwrapした。

Neovimの設定をNixvimに移行した

Thu, 25 Dec 2025 00:00:00 +0000

背景・動機

私はEmacsユーザだが、最近同僚エンジニアが全員Neovimユーザの会社に転職してしまった。よい機会だしある程度Neovimを使えた方がいいなと思い、Neovimをひととおり設定したのでメモしておく。

試したこと・やったこと

1. 管理方法選定

次のニーズを満たすものを探していた。

普段メインで触らないので塩漬ビリティの高い状態にする
lua scriptは可能なら書きたくない、期間が開くとどうせ忘れる
AIに書かせても動くことを保証しやすい状態にする
プラグイン管理と設定が近い状態にする

Nixにないかなと調査してた所、Nixvim を使えば上記の要件を満たせることがわかったので導入してみた。

余談だが公式ドキュメントは情報量が少ないのでソースコードを読んだ方がいい。

https://nix-community.github.io/nixvim/index.html

2. 初期構築

インストールガイドなどを参考に導入する。

https://nix-community.github.io/nixvim/user-guide/install.html

flake.nixで設定する。

{
 inputs = {
 nixvim = {
 url = "github:nix-community/nixvim";
 inputs.nixpkgs.follows = "nixpkgs";
 };
 };
}

home-managerのsharedModulesで読み込む。

nix-darwin.lib.darwinSystem {
 modules = [
 home-manager.darwinModules.home-manager
 {
 home-manager = {
 sharedModules = [ nixvim.homeModules.nixvim ];
 };
 }
 ];
}

あとはNixvimを有効にするだけ。

{
 programs.nixvim = {
 enable = true;

 colorschemes.catppuccin.enable = true;
 plugins.lualine.enable = true;
 };
}

3. AIに設定させる

あとは好みの設定をするだけ。

社内読書会でThe Rust Programming Languageを読破した

Thu, 25 Dec 2025 00:00:00 +0000

1. Introduction

社内でRust本の読書会を開催したのですが、大成功で終わりました。過去に社内読書会に参加した経験から、読書会というのはうまくいかないものだと思っていました。途中で自然消滅したり、一部の人だけが話して終わったり、結局何も身につかなかったりと、苦い経験がいくつもあります。

今回は全員満足度も理解度も高く大成功に終わったという実感があるので、何が良かったのか後学の為に纏めておきます。

あくまで私個人の経験に基づく独断と偏見が多分に含まれている点をご了承ください。

2. 開催情報

2.1. 基本情報

次の期間/時間に開催しました。

2025年9月〜2025年12月
毎日平日 17:00〜17:30

20章と分量のあるThe Rust Programming Language 日本語版を読破しました。メンバーは8人程度で、2人がRust熟練者、それ以外はRust初学者という構成でした。

2.2. 時間設定の意図

17:00〜17:30という時間帯は業務の終盤で集中力が切れやすい時間帯です。読書会にあてることでリラックスできたかなと思っています。

30分という短い時間の意図はそもそもが業務時間内というのと毎日継続するのにちょうどよい長さだからでした。長時間の読書会は準備も負担も大きくなりがちですが、30分であれば「今日はちょっと疲れているな」という日でも参加しやすかったです。

2.3. 進め方

30分間の内訳は以下です。ドキュメントツールに開催日付で記事を作り、共同編集で学んだことをメモする形式にしていました。

前半20分: 前回の続きから読書、学んだことや発見や疑問を雑にメモする
後半10分: メモを見ながら全員に共有

3. 個人的な目標

「落ち着いて座学をやる」というのが年々苦手になってきていた実感があったので、「ちゃんと机に座ってひとつずつ落ち着いて理解しながら進めていく」というのを目標に掲げていました。プログラミング言語の勉強といえど、手を一切動かさず、頭だけで理論を理解することを徹底しました。

特に今回の題材は理論を丁寧に理解していく必要があるRustだったので、題材としてはうってつけでした。

また、「他言語で得た知識で知ったかぶりしない」という目標もありました。良くも悪くも普段プログラムを書いているせいで大体の言語は手なりに書けてしまっていますし、特に最近はAIのせいで深く考えなくても良くなってしまっています。これが成長の足枷になってしまっているなという実感があったので、今回は理解が浅い部分の理解をサボらないことにしました。

4. うまくいった理由の考察

主に次の3パターンの取り組みをしました。

元の文章を読む
Geminiで理解の浅い所を深堀する
自分の理解した部分を有識者に語る会を開く

4.1. Geminiの活用

普段の読書会中は、その日に読む分をGeminiに質問しまくりながら読んでいました。 Geminiに「自分の理解ではこうだけどあってる?」のようにとにかく聞いて正確な理解に努めました。一般的な知識なのでハルシネーションがほぼなかったです。

具体的には次のような質問を投げていました。

「このコードがコンパイルエラーになる理由を、ライフタイムの観点から説明して」
「自分の理解ではこうだけど合ってる？」という確認

疑問点をすぐに解消できたのが助かりました。

4.2. 有識者に語る会

とはいえ、Rustは「所有権」や「借用」や「ライフタイム」や「スマートポインタ」など理解しにくい概念がいくつもあります。そこで、必要に応じて「自分の理解した部分を有識者に語る会」を30分設けてもらいました。有識者にひたすら自分の理解を喋りまくるという形式です。

「有識者に語る」というのが非常に重要でした。言葉を適当に濁せないし、用語を適当に使えないし、ちゃんと準備をしないといけないのが体験としてよかったです。 Geminiに質問攻めして「何が説明できれば俺は理解してるといえると思う?」とプロンプトに投げまくってました。

有識者に説明すると新しい知識が出てきたり、自分の中でしっくりする理解ができたのが良かったです。

世間的にはファインマンテクニックと呼ばれる手法です。

人生を変える最強学習メソッド、ファインマン・テクニック - Qiita

複数人でAirbnbを借りた時の清算方法

Thu, 25 Dec 2025 00:00:00 +0000

背景・動機

毎年VimConfでは秋葉原付近に2泊3日でAirbnbを借りて参加している。 10人くらい入れる物件を借りて、複数人が色んなパターンで遊びに来る。きれいに清算をしたい時のTipsをメモしておく。

試したこと・やったこと

1. 条件を整理する

割り勘をするにあたって、ステータスに応じて重みづけしたい。学生には多く払わせる訳にはいかないし、途中で帰ったりする人にもある程度支払ってもらいたいもの。

とはいえ、あまり複雑にしてもややこしくなるので、次の2軸で重みつけして清算することにした。

宿泊数
- 基本はコアメンバーで割り勘
- 一泊したら1、途中で帰ったら0.5みたいに雑に計算する
役割
- 学生は0倍、新卒は0.5倍、多く出していい人は1.5〜2倍などを用意する

2. 清算シートを作る

次のように清算シートを作った。人ごとに重みつけをして支払い金額を按分し、100円単位で丸める。

あとはslack上で専用チャンネルを作り、支払い先を用意して払ってもらい、シート上で支払い状況を可視化して、未払の人に対してリマインドしやすい形を作る。

https://docs.google.com/spreadsheets/d/13xlbYMcAHZ_7I0vcUYEmQ4fnoPiOXdbbdrOmfoaerHA/edit?gid=551108005#gid=551108005

得られた結果・所感

スプレッドシートを共有して納得感があるか確認し、支払い状況をシート上で可視化したらスムーズに清算できるようになった。

「学生に払わせる訳にはいかない」という個人的なポリシーがあるので、自分が清算業務をしてそもそも多く払うことで解決することにしてる。細かいコンビニでの買い物は面倒なので、その場にいる人で都度清算かポケットマネーで出すようにしてる。

清算業務でもっとも重要なのは「ややこしさを減らす」「困ったら自分の金で解決」なので、ケチケチしない方が早く終わる。

今後の展開・検討事項

この考え方を使えば他のユースケースでも使えるのであらゆる所で使いたい。

digツールはdoggoが便利

Wed, 24 Dec 2025 00:00:00 +0000

背景・動機

インフラ構築する時にdigを叩くことは必須なのだが、2025年にdigコマンドをそのまま使うのは流石に辛い。もう少しリッチなものがないか調べた所、doggoが良さそうだったので導入してみた。

試したこと・やったこと

0. ツール選定

Rust製のツールに dog というものがあるが、最終更新が2021年前と期間が空いてる。

後継にあたるツールがないかなと思って調査した所、Golang製の doggo というツールがあった。

It’s totally inspired by dog which is written in Rust. I wanted to add some features to it but since I don’t know Rust, I found it as a nice opportunity to experiment with writing a DNS Client from scratch in Go myself. Hence the name dog + go => doggo.

Nixでパッケージングされているし、CLIとしての完成度も高く、アクティブなプロジェクトだったので導入した。

1. home-manager module用意

特に設定項目がないのでshell completionだけ有効にしている。

{
 pkgs,
 lib,
 config,
 ...
}:
let
 cfg = config.programs.doggo;
in
with lib;
{
 options.programs.doggo = {
 enable = mkEnableOption "Command-line DNS Client for Humans. Written in Golang";
 package = mkPackageOption pkgs "doggo" { };

 enableBashIntegration = lib.hm.shell.mkBashIntegrationOption { inherit config; };

 enableZshIntegration = lib.hm.shell.mkZshIntegrationOption { inherit config; };

 enableFishIntegration = lib.hm.shell.mkFishIntegrationOption { inherit config; };
 };

 config = mkIf cfg.enable {
 home.packages = [ cfg.package ];

 programs = {
 bash.initExtra = mkIf (cfg.enableBashIntegration && cfg.package != null) ''
 eval "$(${getExe cfg.package} completions bash)"
 '';

 zsh.initContent = mkIf (cfg.enableZshIntegration && cfg.package != null) ''
 eval "$(${getExe cfg.package} completions zsh)"
 '';

 fish.interactiveShellInit = mkIf (cfg.enableFishIntegration && cfg.package != null) ''
 ${getExe cfg.package} completions fish | source
 '';
 };
 };
}

あとは programs.doggo.enable = true; で有効にするだけで使えるようになる。

Typst SlideのDracula Light Theme作成した

Wed, 24 Dec 2025 00:00:00 +0000

背景・動機

Typstテーマを自作したでDrauclaテーマのスライドを自作したのだが、実際登壇してみるとダークテーマは登壇会場によっては見にくくなってしまうことがわかった。 Draculaテーマだけでなくライトテーマでも生成できるようにしなくちゃいけなくなったので自作してみた。

試したこと・やったこと

1. テーマ選定

ライトテーマは世の中に沢山あるものの、好みのテーマを見つける必要がある。 Draculaテーマが好きな理由は、エコシステムが充実していてあまり努力せず統一感を出せるからであり、対応しているすべてのアプリケーションのカラーテーマをDraculaに設定している。

Draculaテーマにもライトテーマないのかなと調べた所、Draculaを逆から読んだAlucardというテーマがあった。

https://draculatheme.com/blog/dracula-pro-2.0-our-first-light-theme

これなら既存のカラーテーマとの統一感を出せるだろう、ということでAlucardを選定することにした。

2. テーマ作成

AIに適当にカラーテーマを作成させた。

https://github.com/takeokunn/blog/blob/main/typst/themes/alucard.typ

#let colors = (
 background: rgb("#FFFBEB"),
 foreground: rgb("#1F1F1F"),
 pink: rgb("#A3144D"),
 purple: rgb("#644AC9"),
 orange: rgb("#A34D14"),
 green: rgb("#14710A"),
 cyan: rgb("#036A96"),
 red: rgb("#CB3A2A"),
 yellow: rgb("#846E15"),
 comment: rgb("#6C664B"),
)

TextMate Themeも作成した。

https://github.com/takeokunn/blog/blob/main/typst/themes/Alucard.tmTheme

得られた結果・所感

「Software DesignでNix連載しました」というスライドを作って登壇してみた。特に問題なく登壇できたので今後も積極的に使っていきたい。

https://www.takeokunn.org/pdf/publishing-nix-series-software-design.pdf

今後の展開・検討事項

スライドテンプレートを作り込んでより表現力豊かなスライドを作れるようになりたい。

技術イベントのパンフレット記事をTypstでBuildする

Wed, 24 Dec 2025 00:00:00 +0000

背景・動機

組版が必要なあらゆるものはTypstを採用することにしている。

パンフレット記事や同人誌の組版をする時にも例に漏れずTypstで作成しているのでメモしておく。

内容は NixでTypstをBuildしGitHub Pagesでホスティングするとかなり重複するが、パンフレット記事を書くという側面で纏めていく。

試したこと・やったこと

1. Build周り

NixでTypstをBuildしGitHub Pagesでホスティングするに纏まっているのでこちらを参照。

2. テーマ選定とTypst設定

この手のテーマはTypstには大量にある。

コードのsyntax highlightのみ codly と codly-languages を使ってるが、デフォルトのTypstの機能を手で設定している。フォントはHackGenを入れており、日本語も英語も数値もきれいに描画してくれる。

#set text(lang: "ja", font: "HackGen", size: 8pt)

#set page(
 width: 210mm,
 height: 297mm,
 margin: 20mm,
 columns: 2
)
#set columns(gutter: 12pt)

#import "@preview/codly:1.2.0": *
#import "@preview/codly-languages:0.1.1": *
#show: codly-init.with()
#codly(languages: codly-languages)

#show raw: set text(size: 6pt)

#place(
 top + center,
 float: true,
 scope: "parent",
 clearance: 1em,
)[
 #set text(size: 18pt)
 パッケージマネージャNixで実現する \
 宣言的でクリーンなPHP開発環境の構築

 #set text(size: 12pt)
 たけてぃ \@takeokunn
 #v(1em)
]

得られた結果・所感

満足いくクオリティでpdfを生成できるようになったし、GitHub ActionsでBuildしてGitHub Pagesでホスティングできるようになった

gitleaksを導入した

Tue, 23 Dec 2025 00:00:00 +0000

背景・動機

秘密鍵をgit commitしないようにしたいと以前から考えていた。大体のプロジェクトのCIにsecretlintを導入していたが、手元でもpre-commitでも設定したいと思っていた所、gitleaksなら設定不要で楽に導入できることが分かったので導入した。

試したこと・やったこと

0. ツール選定

類似ツールにはgit-secrets、trufflehog、secretlintがある。

次の性質があるツールがよい。

nixpkgsにある
デフォルト設定がしっかりしてる
CLIで雑に実行できる

『Gitleaks』で機密情報の漏洩を防ぐ〜コマンド編〜を読んでいた所、自分のニーズを満たせることが確認できたので導入を決定した。

1. home-manager module作成

home-manager moduleを自作すると自由度が上がる。

https://github.com/takeokunn/nixos-configuration/blob/6df4a5955942bff1010b80e3c1bc48af48baebd5/home-manager/modules/gitleaks/default.nix

programs.gitleaks.enable = true するだけで設定完了する。

{
 programs.gitleaks = {
 enable = true;
 enableGitHook = true;
 settings = {
 extend.useDefault = true;
 };
 };
}

2. devenvのgit pre-commit導入

devenvでgit hookを定義してると、system globalのgit hookを読んでくれないことがわかった。

devenvでかなりhookを定義してるので、こちらでも明示的にpre-commitを定義している。 https://devenv.sh/git-hooks/

{ pkgs, ... }: {
 git-hooks.hooks = {
 check-merge-conflicts.enable = true;
 check-case-conflicts.enable = true;
 gitleaks = {
 enable = true;
 entry = "${pkgs.gitleaks}/bin/gitleaks protect --staged";
 };
 };
}

得られた結果・所感

より安全に git commit できるようになった。

簡易的なヒューリスティックパーサの自作方法

Tue, 23 Dec 2025 00:00:00 +0000

背景・動機

クローリング結果や業務で使ってるデータベースの値など世の中にはDirtyな値が山のようにある。一定のルールで正規化した値を取得したい場合にヒューリスティックパーサが便利。

業務で大量に作ったので作り方についてメモしておく。

試したこと・やったこと

0. ヒューリスティックパーサが適切か見極める

目の前の問題の性質がヒューリスティックパーサが適してるか確認する。

メリット
- 不完全・壊れた入力への耐性が高い
- 実装の簡単さ
- パフォーマンス
- 依存関係の排除
デメリット
- エッジケースに対応しきれない
- 偽陽性や偽陰性
- 正当性の証明が困難

1. テストデータのパターンを用意する

AIにテストケースをyamlで生成させる。たとえば次のyamlは文字列から月給の下限と上限を取得するparserを実装する例。

# 年収（年俸）の文字列があるパターン
- input: "300万円～350万円 ※この限りではありません。"
 expected:
 form: "年収"
 min: 3000000
 max: 3500000

# 年収の単純な範囲指定パターン
- input: "年俸400万円～500万円"
 expected:
 form: "年俸"
 min: 4000000
 max: 5000000

# 月給のパターン
- input: "月給20万円～25万円"
 expected:
 form: "月給"
 min: 200000
 max: 250000

- input: "月給25万3000円"
 expected:
 form: "月給"
 min: 253000
 max: 253000

# 時給のパターン
- input: "時給1,500円～2,000円"
 expected:
 form: "時給"
 min: 1500
 max: 2000

- input: "時給1,800円"
 expected:
 form: "時給"
 min: 1800
 max: 1800

# 日給のパターン
- input: "日給12,000円～15,000円"
 expected:
 form: "日給"
 min: 12000
 max: 15000

- input: "日給10,000円"
 expected:
 form: "日給"
 min: 10000
 max: 10000

2. パーサをAIに作らせる

「yamlのinputとexpectedに合うparserを自作して、vitestで実装して」とAIに命令すればよい。

emacs wgrepが便利だった

Tue, 02 Dec 2025 00:00:00 +0000

背景・動機

本記事は Emacs Advent Calendar 2025 の2日目の記事です。

emacs wdiredが便利だったでwgrepも便利だということが判明したのでこちらも調査してみる。

試したこと・やったこと

1. wgrepの機能調査

mhayashi1120/Emacs-wgrep のサードパーティpackageでMelpaから落とすことができる。

https://melpa.org/#/?q=wgrep

*grep* bufferの grep-mode にhookして wgrep-setup を実行し、 wgrep-mode というminor modeを起動する。

(add-hook 'grep-setup-hook 'wgrep-setup)

類似機能に標準機能の moccur-edit があり、migemoとの連携も取れるようだ。自分はmigemoユーザではないが将来的に試してみたい。

2. wgrep設定

defcustom としては以下だが、自分は特に設定していない。

変数名（Variable）	機能概要	戦略的利用法
wgrep-auto-save-buffer	変更適用完了時（wgrep-finish-edit）にバッファを自動保存するか。	大規模リファクタリング時、安全のため `nil` （手動保存）を維持するか、迅速な処理のために `t` に設定。
wgrep-enable-key	wgrepモードを有効にするためのキーバインド。	ワークフローの摩擦を減らすため、単一キー（例: “r"や"e”）に設定することを推奨。
wgrep-change-readonly-file	バッファが読み取り専用であるかどうかにかかわらず、変更を強制的に適用するか。	VCSによって保護されたファイルを編集する場合に有効化。

デフォルトのkeybindは次のようになっている。

(unless wgrep-mode-map
 (let ((map (make-sparse-keymap)))

 (define-key map "\C-c\C-c" 'wgrep-finish-edit)
 (define-key map "\C-c\C-d" 'wgrep-mark-deletion)
 (define-key map "\C-c\C-e" 'wgrep-finish-edit)
 (define-key map "\C-c\C-p" 'wgrep-toggle-readonly-area)
 (define-key map "\C-c\C-r" 'wgrep-remove-change)
 (define-key map "\C-x\C-s" 'wgrep-finish-edit)
 (define-key map "\C-c\C-u" 'wgrep-remove-all-change)
 (define-key map "\C-c\C-k" 'wgrep-abort-changes)
 (define-key map "\C-x\C-q" 'wgrep-exit)

 (setq wgrep-mode-map map)))

3. 挙動の確認

minad-wareのaffeで実験すると次のようになる。

個人的sketchybar設定

Sun, 30 Nov 2025 00:00:00 +0000

背景・動機

個人的Aerospace設定に続き、sketchybarの設定もしたのでメモしておく。

大体の対応は公式ドキュメントを元にClaude Codeに対応させた。

https://felixkratz.github.io/SketchyBar/

試したこと・やったこと

1. 完成イメージと設計方針

世の中のsketchybarのサンプルを作成して、こんな感じで作る目論見を立てた。

Hack Nerd Font: アイコンとラベル用
SF Pro: Appleロゴ用（macOS標準搭載）

┌─────────────────────────────────────────────────────────────────────────┐
│ [􀣺] [1 2 3 4 5 6 7 8 9 0] Firefox | 󰻠 5% 󰍛 42% | 󰖩 Home | 󰕾 50% | 󰁹 85% | 󰃭 01/15 Mon 󰥔 14:30 │
└─────────────────────────────────────────────────────────────────────────┘

また、すべてをdracula themeに寄せるのでカラーパレットをAIに作らせた。

colors = {
 background = "0xff282a36";
 backgroundTransparent = "0xcc282a36";
 currentLine = "0xff44475a";
 foreground = "0xfff8f8f2";
 comment = "0xff6272a4";
 cyan = "0xff8be9fd";
 green = "0xff50fa7b";
 orange = "0xffffb86c";
 pink = "0xffff79c6";
 purple = "0xffbd93f9";
 red = "0xffff5555";
 yellow = "0xfff1fa8c";
 transparent = "0x00000000";
 black = "0xff21222c";
};

2. 基本設定

2.1. home-manager設定

home-manager moduleで定義されているので enable=true するだけで入る。

emacs wdiredが便利だった

Sat, 29 Nov 2025 00:00:00 +0000

背景・動機

ryoppippi の「【外資ITエンジニアの開発環境】VimmerによるVimmer（になりたい人）のためのVim動画」という動画を見た。

{{< youtube id=“XsAlXYWzcv4” title="【外資ITエンジニアの開発環境】VimmerによるVimmer（になりたい人）のためのVim動画" >}}

その中で oil.nvim 紹介があり、vimの通常操作でファイル操作が可能になる機能がある。 EmacsのDiredでも同様のことがないか調査した所、標準機能に wdired.el というものがあったので使ってみた。

試したこと・やったこと

1. wdiredの機能調査

wdired は Writable Dired の略でDired拡張。

https://github.com/emacs-mirror/emacs/blob/master/lisp/wdired.el

大きな特徴は3点。 Emacs上で完結しているが故のkmacroなどの他の機能を使えるのが便利。

テキスト処理の延長でファイル操作ができる（ディレクトリ名も変更可能）
安全性とトランザクション
Emacs Lispによる拡張可能

2. wdired設定

Dired上で起動するの方法は wdired-change-to-wdired-mode を有効にすればよく、 r に割り当てている。

(define-key dired-mode-map "r" #'wdired-change-to-wdired-mode)

defcustom はそこそあるが、file permissionを変更できるように wdired-allow-to-change-permissions は設定してもよさそう。

;;; 定義元

(defcustom wdired-allow-to-change-permissions nil
 "If non-nil, the permissions bits of the files are editable.

If t, to change a single bit, put the cursor over it and press the
space bar, or left click over it. You can also hit the letter you want
to set: if this value is allowed, the character in the buffer will be
changed. Anyway, the point is advanced one position, so, for example,
you can keep the <x> key pressed to give execution permissions to
everybody to that file.

If `advanced', the bits are freely editable. You can use
`string-rectangle', `query-replace', etc. You can put any value (even
newlines), but if you want your changes to be useful, you better put a
intelligible value.

The real change of the permissions is done by the external
program \"chmod\", which must exist."
 :type '(choice (const :tag "Not allowed" nil)
 (const :tag "Toggle/set bits" t)
 (other :tag "Bits freely editable" advanced)))

;;; 自分の設定
(setotp wdired-allow-to-change-permissions 'advanced)

3. 挙動の確認

適当なディレクトリでdiredを開いて r を押す
ファイル名やpermissionを変更する
C-c C-c で保存する or C-c C-k でロールバックする

得られた結果・所感

diredでのファイル操作が本当に楽になった。普段がんばってshell script書いたりしてたので無駄なことをしてしまったと反省している。

k9sをDracula Theme対応した

Sat, 29 Nov 2025 00:00:00 +0000

背景・動機

最近仕事でkubernetesを使う機会に恵まれた。 kubernetesを使うにあたって、モニタリングツールはk9sがデファクトのようなのでhome-managerを使って導入した。「すべてのツールのカラーテーマはdracula themeに寄せる」という方針なので漏れなく対応した。

試したこと・やったこと

1. home-managerで導入

home-manager moduleはすでに用意されているのでenableするだけでよい。

C-c で閉じるよりも :q で閉じる方が直感的なので noExitOnCtrlC を有効化した。

https://github.com/nix-community/home-manager/blob/master/modules/programs/k9s.nix

{
 programs.k9s = {
 enable = true;
 settings.k9s = {
 noExitOnCtrlC = true;
 };
 };
}

2. dracula theme対応

k9sはskinという機能を用意しており、自前で用意したものを適用できる。 Claude Codeに必要なものを用意させた。

https://k9scli.io/topics/skins/

{
 programs.k9s = {
 settings.k9s = {
 ui.skin = "dracula";
 };
 skins = {
 dracula =
 let
 foreground = "#f8f8f2";
 background = "#282a36";
 current_line = "#44475a";
 selection = "#44475a";
 comment = "#6272a4";
 cyan = "#8be9fd";
 green = "#50fa7b";
 orange = "#ffb86c";
 pink = "#ff79c6";
 purple = "#bd93f9";
 red = "#ff5555";
 yellow = "#f1fa8c";
 in
 {
 k9s = {
 body = {
 fgColor = foreground;
 bgColor = background;
 logoColor = purple;
 };
 prompt = {
 fgColor = foreground;
 bgColor = background;
 suggestColor = purple;
 };
 info = {
 fgColor = pink;
 sectionColor = foreground;
 };
 dialog = {
 fgColor = foreground;
 bgColor = background;
 buttonFgColor = foreground;
 buttonBgColor = purple;
 buttonFocusFgColor = yellow;
 buttonFocusBgColor = pink;
 labelFgColor = orange;
 fieldFgColor = foreground;
 };
 frame = {
 border = {
 fgColor = selection;
 focusColor = current_line;
 };
 menu = {
 fgColor = foreground;
 keyColor = pink;
 numKeyColor = pink;
 };
 crumbs = {
 fgColor = foreground;
 bgColor = current_line;
 activeColor = current_line;
 };
 status = {
 newColor = cyan;
 modifyColor = purple;
 addColor = green;
 errorColor = red;
 highlightColor = orange;
 killColor = comment;
 completedColor = comment;
 };
 title = {
 fgColor = foreground;
 bgColor = current_line;
 highlightColor = orange;
 counterColor = purple;
 filterColor = pink;
 };
 };
 views = {
 charts = {
 bgColor = "default";
 defaultDialColors = [
 purple
 red
 ];
 defaultChartColors = [
 purple
 red
 ];
 };
 table = {
 fgColor = foreground;
 bgColor = background;
 header = {
 fgColor = foreground;
 bgColor = background;
 sorterColor = cyan;
 };
 };
 xray = {
 fgColor = foreground;
 bgColor = background;
 cursorColor = current_line;
 graphicColor = purple;
 showIcons = false;
 };
 yaml = {
 keyColor = pink;
 colonColor = purple;
 valueColor = foreground;
 };
 logs = {
 fgColor = foreground;
 bgColor = background;
 indicator = {
 fgColor = foreground;
 bgColor = purple;
 toggleOnColor = green;
 toggleOffColor = cyan;
 };
 };
 };
 };
 };
 };
 };
}

3. k9s起動する

無事反映されてることが確認できた。

個人的Aerospace設定

Sat, 29 Nov 2025 00:00:00 +0000

背景・動機

タイル型Window Managerは割と好きで、Linux Desktopではswayを使っているのだが、macOSでも使いたいと思っていた。 macOSでは昔ながらのyabaiと後発のAeroSpaceがあるが、AeroSpaceで自分のユースケースをすべて満たせていたので採用した。

1年使ってほぼ運用が固まったので後学の為にブログに書いておく。

設定の全文はこちら。

https://github.com/takeokunn/nixos-configuration/blob/main/nix-darwin/config/services/aerospace/default.nix

試したこと・やったこと

1. nix-darwinでAeroSpaceを有効にする

nix-darwinでservices moduleが提供されている。 enableにするだけでlaunchd agentの設定が有効になり、 Quit AeroSpace しても再起動されるようになる。

https://github.com/nix-darwin/nix-darwin/blob/master/modules/services/aerospace/default.nix

# 自分の設定
{
 services.aerospace = {
 enable = true;
 };
}

# nix-darwin記述抜粋
{
 launchd.user.agents.aerospace = {
 command =
 "${cfg.package}/Applications/AeroSpace.app/Contents/MacOS/AeroSpace"
 + (lib.optionalString (cfg.settings != { }) " --config-path ${configFile}");
 serviceConfig = {
 KeepAlive = true;
 RunAtLoad = true;
 };
 managedBy = "services.aerospace.enable";
 };
}

2. 基本設定

適当に便利そうな設定を入れている。 sketchybar の関係で gaps.outer.top=10 を入れて調整している。

{
 settings = {
 enable-normalization-flatten-containers = true;
 enable-normalization-opposite-orientation-for-nested-containers = true;
 accordion-padding = 0;
 on-focused-monitor-changed = [ "move-mouse monitor-lazy-center" ];
 exec-on-workspace-change = [
 "/bin/bash"
 "-c"
 "sketchybar --trigger aerospace_workspace_change FOCUSED_WORKSPACE=$(/run/current-system/sw/bin/aerospace list-workspaces --focused)"
 ];

 gaps = {
 inner = {
 horizontal = 0;
 vertical = 0;
 };
 outer = {
 left = 0;
 bottom = 0;
 top = 10;
 right = 0;
 };
 };
 };
}

3. keybind周りの設定

alt で操作する割と一般的な設定をしている。

Geminiで専門家カスタムGemを作る

Sun, 27 Jul 2025 00:00:00 +0000

背景・動機

普段使いのチャットベースのAIサービスを完全にGeminiに寄せる決断ができた。元々ChatGPTやClaudeを使っていたが、次の理由でGeminiがいいだろうという結論に落ち着いた。

Gemini 2.5 Proが賢すぎる
仕事関連のGoogle WorkspaceだとPro版が使える
電車の中でAndroidスマホでアイディア出しに使いやすい
オフィスツールとの親和性がよい
カスタムGemが作りやすい

メールサービスもそうだが、基本的に拘りのないものはGoogleに寄せていこう個人的な方針もあり、他サービスをアンインストールした。今回はGeminiのカスタムGemについての紹介と、Gemの作り方について纏める。

なお、自分の肌感覚の話が多いので注意が必要。

試したこと・やったこと

0. 基本的な方針

カスタムGemはデフォルトプロンプトが設定できるのだが、デフォルトのプロンプトを設定することは次のような利点がある。

技術的背景を伝える必要がないので効率性が高い
応答の品質と一貫性の確保
専門性とタスクへの特化

最近のLLMのモデルは賢いので、「あなたはAWSソリューションアーキテクトです」のようなことを伝えなくてもよしなに理解してくれるのですが、自分の肌感覚だと役割を伝えた方が明瞭な回答が返ってくる印象。自分がAIに質問を投げる時の大半は、明確に「これについて聞きたい」ということがある時なので余計作った方がいいなという結論になっている。

1. Gemを作るカスタムGemを作る

世の中にはさまざまなプロンプトエンジニアリングテクニックがあるが、プロンプト生成をするプロンプトをAIに生成させる方がコストが低いのでGeminiに作ってもらった。

# 1. YOUR PERSONA: Master Prompt Engineer & AI Behavior Architect

あなたは、AIの能力を最大限に引き出すための「システムプロンプト」を設計する、世界最高峰のプロンプトアーキテクトです。
あなたの使命は、ユーザーから要求された役割（例: AWSアーキテクト、マーケター、コピーライター）の本質を深く理解し、その役割をAIに憑依させるための、精巧でパワフルなシステムプロンプトを設計・生成することです。

# 2. GUIDING PRINCIPLES: The Blueprint of High-Quality Prompts

あなたが設計する全てのシステムプロンプトは、以下の5つの基本原則を必ず満たしていなければなりません。

1. **Deep Persona (深みのあるペルソナ)**: 単なる役割名だけでなく、その役割が持つべき「哲学」「価値観」「使命」「思考の軸」までを定義し、一貫性のある深い人格をAIに与えること。
2. **Structured Principles (構造化された原則)**: AIが従うべき行動や思考の指針を、明確で解釈の余地がない箇条書きの「原則」として定義すること。
3. **Actionable Workflow (実行可能なワークフロー)**: ユーザーからの入力に対し、AIが「どのような手順で思考し、どのような構造で応答を生成すべきか」という具体的な実行プロセス（プロトコル）を定義すること。
4. **Value-Adding Behavior (付加価値のある振る舞い)**: AIが単に指示されたタスクをこなすだけでなく、専門家として「より良くするための提案」や「潜在的なリスクの指摘」など、能動的で気の利いたアクションを取るように設計すること。
5. **Clear Constraints (明確な制約)**: AIが「やってはいけないこと」を禁止事項として明確に定義し、暴走や質の低い応答を防ぐこと。

# 3. EXECUTION PROTOCOL: Your Prompt Engineering Workflow

ユーザーから「〇〇用のシステムプロンプトを作って」という要求を受けた場合、以下の厳密なプロセスに従って応答を生成してください。

## STEP 1: Deconstruct the User's Request (要求の分解と役割定義)

- ユーザーが要求した「〇〇」という役割を分析します。
- その役割を完璧にこなす専門家が持つべき「スキルセット」「知識ベース」「思考様式」「価値観」を瞬時に定義します。

## STEP 2: Architect and Generate the System Prompt (プロンプトの設計と生成)

- 上記の分析と5つの基本原則に基づき、要求された役割のための**完全なシステムプロンプト**をMarkdown形式で生成します。
- 生成するプロンプトは、必ず以下の標準構造を含んでいなければなりません。

 ---
 **(ここからが生成されるプロンプトの内容)**
 ```
 `# CORE DIRECTIVE: SYSTEM PROMPT`

 `# 1. PERSONA: [役割名]`
 `(役割の定義、使命、哲学などを記述)`

 `# 2. GUIDING PRINCIPLES: [その役割の行動原則]`
 `(箇条書きで、思考の軸や価値観を記述)`

 `# 3. EXECUTION PROTOCOL: [具体的な実行手順]`
 `(ユーザーからの入力に対する思考と応答のプロセスをステップで記述)`
 `(必要であれば、対話開始時のテンプレート提示なども含める)`

 `# 4. ABSOLUTE CONSTRAINTS: [禁止事項]`
 `(やってはいけないことを具体的に記述)`
 ```
 **(ここまでが生成されるプロンプトの内容)**
 ---

## STEP 3: Provide a Rationale and Usage Guide (設計意図の解説)

- 生成したシステムプロンプトを提示した後、必ず以下の解説を加えてください。
 - **【設計意図】**: なぜこのペルソナ、原則、ワークフローを設定したのか、その設計思想を簡潔に説明します。
 - **【使い方】**: 生成したプロンプトをAIのシステムプロンプトとして設定し、どのように対話を開始すればよいかをユーザーに案内します。

## STEP 4: Iterate and Refine (改善サイクル)

- ユーザーから「もっとこうしてほしい」というフィードバックがあれば、それに応じて生成したプロンプトを即座に改善し、再提案します。

カスタム Gem 作成のヒント - Google を参考にカスタムGemを作成する。

プロポーザルの出し方・心構え

Tue, 22 Jul 2025 00:00:00 +0000

1. Introduction

最近プロポーザルの出し方について話す機会が身近で増えました。私自身、過去にPHPカンファレンスなどの技術イベントで何度も登壇した経験があります。本記事ではそうした経験から得られたプロポーザルを書く上での心構えや具体的なTipsについて解説します。

また、多くの人が悩む「プロポーザルを出すネタがない」という課題に対する私なりの解決策も提示したいと考えています。

あくまで私個人の経験に基づく独断と偏見が多分に含まれている点、また、自分はこうありたいという理想を書いている点をご了承ください。

2. 今北産業

日々学んだことや取り組んだことをアウトプットしよう
アウトプットしたものを元に魅力的なプロポーザルを作ろう
カンファレンスに限らず積極的に打席に立とう

3. 今回のスコープ

本記事で対象とするカンファレンスは、主にPHPカンファレンスのような技術カンファレンスを想定しています。

一口にカンファレンスと言ってもその規模や目的はさまざまです。たとえば国際カンファレンスであれば一定の権威性がありますし、地方のカンファレンスであれば一般的な勉強会の延長線上にあります。本記事では特にカンファレンスの規模を区別せずに書いています。

また、トークの長さとしては15分〜30分程度のものをイメージしています。 5分程度のLTはゲーム性が異なると考えているため本記事のスコープ外とします。

4. 直近出したプロポーザル

4.1. 実例

直近の2025年前半に提出したプロポーザルを実例として紹介します。

PHPConで採択されたプロポーザルは次のとおりです。

PHPCon関西で不採択となったプロポーザルは次のとおりです。

https://fortee.jp/phpcon-kansai2025/proposal/rejected?q=takeokunn

VimConfではEmacsに関するテーマで応募しましたが、残念ながら不採択となりました。

4.2. ポリシー

これはあくまで私個人のルールなので参考にされてもされなくても構いません。

Hugoで生成したブログにllms.txtとllms-full.txtを導入した

Fri, 18 Jul 2025 00:00:00 +0000

背景・動機

llms-full.txtで始めるAIサポートチャット - basemachina を読んだ。

最近gemini-cliで文章を書かせることが増えたので、自分の文章スタイルを学習させればブログを半自動生成できるんだろうなと思ったので試してみた。

試したこと・やったこと

1. llms.txtの規格について簡単に調査する

以下が仕様。 https://llmstxt.org/

llms.txt: サイトの概要や、サイトに含まれるページへのリンク一覧
llms-full.txt: サイト全体の情報を1つに収めた文書ファイル

各サービスのlls-full.txtは以下。

Cursor （約500KB）
- https://docs.cursor.com/llms-full.txt
Anthropic （約2.5MB）
- https://docs.anthropic.com/llms-full.txt
Mastra （約4MB）
- https://mastra.ai/llms-full.txt
Cloudflare （約17MB）
- https://developers.cloudflare.com/llms-full.txt

2. hugoに導入する

Hugo で作ったサイトに llms.txt と llms-full.txt を設置したを参考にした。

takeokunn/hugo-take-theme で次のlayoutを作成した。

index.llms.txt:

# takeokunn's blog

たけてぃ(@takeokunn)の個人的なメモです。

## URL Structure

Zettelkasten

- fleeting
 - 小さい技術的なメモ
- permanent
 - 纏まった技術的メモ
- poem
 - 個人的なポエム
- diary
 - 個人的な日記

## Content

{{ range .Site.RegularPages }}
- [{{ .Title }}]({{ .Permalink }})
{{ end }}

index.llmsfull.txt:

Makefileを便利コマンドメモとして使うことに対する違和感

Fri, 11 Jul 2025 00:00:00 +0000

追記

この記事に対するyasunoriの補足記事はこちら。

https://blog.yasunori0418.dev/p/appendix-makefile/

Introduction

yasunoriがZennに書いた「職場のプロジェクトに必ず配置しちゃうMakefileの話」というのがバズっています。「コマンドが覚え辛い」という、どのプロジェクトにもあるような問題を「Makefileをコマンドメモとして整える」ことによって解決するという記事でした。 SNSやvim-jp slackを見ていると賛同の声が多い印象を受けています。

https://b.hatena.ne.jp/entry/s/zenn.dev/loglass/articles/0016-make-makefile

私個人も過去に同様のMakefileを作ったことがあるし、現職でもMakefileが入っているプロジェクトがあるくらいにはよくある手法です。

しかし、この記事を読んだ時に自分としてはこの手法がイマイチだと感じました。モヤモヤをちゃんと言語化した方がいいだろうということでこの記事を書いています。

決して元記事を批判するつもりはなく、こういう視点もあるよというくらいの温度感で捉えてほしいです。

Makefileをコマンドメモに使うな
— たけてぃ𓁈𓈷 (@takeokunn) April 8, 2020

Makefileをプロジェクトに入れたい時の前提整理

そもそも「誰のために」「どのプロジェクト規模で」「どういう問題を解決したくて」Makefileをプロジェクトに追加するものなのか整理する必要があります。

今回のユースケースでは、古き良きC言語をBuildする時の make && make install のようなタスクランナー的な使い方ではなく、元記事と同様プロジェクトのコマンドメモとしての使い方について言及しています。

Makefileの想定利用者

想定利用者のペルソナ像は主に4種類います。

1つめは、デザインや文言を修正したい非エンジニア寄りのデザイナーです。

役割はUI/UXデザイナー、またはマークアップ担当者で、技術スキルは低〜中程度を想定しています。主な目的は、文言・デザインの軽微な修正を手元で確認し、FigmaやXDのようなデザインツール上ではなく「実際の画面」で表示を見ることです。行動特性としては、GUIでの操作が望ましく、ターミナル操作も最低限であれば対応可能ですが、何度も環境構築の手順を覚えるのは非効率だと感じています。主な課題として、環境構築に時間がかかること、依存関係が多すぎて途中で躓いてしまうこと、Node.js, Ruby, Pythonといった技術スタックの違いが分からない、といった点が挙げられます。

2つめは、そのプロジェクトに精通していないプログラマです。

役割は外部の協力会社のメンバー、派遣や業務委託のエンジニア、またはプロジェクトに参加したばかりの新人エンジニアを想定しています。技術スキルは中〜高程度です。主な目的は、限られた期間や担当範囲の中で、与えられたチケットの実装や修正を効率的に行うことであり、プロジェクト全体の詳細な把握は必要最低限で済ませたいと考えています。行動特性としては、ローカル環境の立ち上げに時間をかけたくないと感じており、覚えるべき新規のコマンドが多すぎると混乱してしまいます。主な課題として、「.envファイルはどこにあるのか？」「どの順番で起動すればいいのか？」「フロントエンドだけでなくバックエンドも動かす必要があるのか？」といった疑問が次々と湧いてくる点が挙げられます。

3つめは、そのプロジェクトに精通しているプログラマです。

役割はリードエンジニア、メンテナー、あるいは主要な開発者であり、技術スキルは高いレベルにあります。主な目的は、長期的な保守や機能の拡張や新機能の実装や大規模な構成変更など、プロジェクトの根幹に関わる作業することです。行動特性としては、再利用性や抽象化といった概念に関心があり、開発フローの自動化や最適化にも積極的です。主な課題として、コマンドが乱立して管理が煩雑になること、特定の担当者にしか分からない作業（属人化）が増えること、そしてドキュメントが古くなって陳腐化しがちである点が挙げられます。

4つめは、AI Coding Agentです。

役割はVibe Coding、その技術スキルは正確かつ高速な処理能力にあります。主な目的は、指定された手順を正確に実行し、ソースコードのビルド、テスト、静的チェックといった成果物の検証作業を滞りなく行うことです。行動特性としては、曖昧な指示に弱く、処理の中間ステップが明示的に定義されていないと失敗する傾向があります。また、コマンドの標準出力（STDOUT）が構造化されていることを期待する場合もあります。主な課題として、コマンドの実行に失敗した場合でも、その背景にある詳細な文脈を読み解いてリトライしたり、原因を推測ができない点が挙げられます。

想定しているプロジェクト規模

当記事で想定しているプロジェクトは主に3種類あります。

プロジェクト規模	コード行数	特徴
小規模プロジェクト	1万行程度	数ページ程度のちょっとしたWebアプリケーション、単一言語、依存ツールチェインが少ない
中規模プロジェクト	10万行程度	複数機能があるWebアプリケーション、複数言語、依存ツールチェインや開発用コマンドがそれなりに多い
大規模プロジェクト	100万程度	大規模なWebアプリケーション、複数言語、依存ツールチェインや開発用コマンドが多い

Makefileで実行するコマンド

今まで見てきたコマンドは主に3種類です。

はてなブックマークコメント非表示にした

Wed, 09 Jul 2025 00:00:00 +0000

背景・動機

バズった記事のはてなブックマークのコメントを見る度に、嫉妬や見苦しいコメントが際立つなという感想を長年持っていた。

自分のブログがはてなブックマークで書かれたことはないが、変な火種を生んでもしょうがないので非表示にすることにした。

試したこと・やったこと

1. 方針決め

org-roamで記事を管理しGitHub Actionsで適切に公開するにも書いたとおり、2025年7月現在、私は次の2つのブログを運用している。

	URL	想定読者	用途
自作ブログ	www.takeokunn.org	特定少数（2hop以内）	個人的な調査メモや作業ログ
Zenn	zenn.dev/takeokunn	不特定多数	対外的な活動報告 + 広報目的

Zennに関して、仕事に紐付く活動なので基本的しっかり腰を据えて書いている。所属企業のAdventCalendarもZennに書くことにしている。

一方自作ブログの方は、この記事もそうだが自分の作業メモとして書いている。なので、校正も甘かったり誤字脱字もあったり検証が甘かったり、基本的にツメが甘いことが多い。そもそも不特定多数を意識したブログではないので不特定多数からのフィードバックを期待していない。

ブックマーク自体はされてもよいので、今回は自作ブログの方のみ、はてなブックマークコメント非表示にすることにした。

2. コメント非表示対応

はてなブックマークヘルプに「コメント一覧非表示機能について」の記述がある。

https://b.hatena.ne.jp/help/entry/nocomment

今回は自作ブログなのでmetaタグを追加すれば解決するようだ。

<meta name="Hatena::Bookmark" content="nocomment" />

テーマは takeokunn/hugo-take-theme で管理しているのでタグ追加する対応をした。

https://github.com/takeokunn/hugo-take-theme/commit/618ddf7990affdbf0b72c705fc4e945d9d9224ec

あとはcurlを叩いて反映されてることを確認した。

$ curl -s https://www.takeokunn.org/ | grep 'Hatena::Bookmark'
<!doctype html><html lang=ja-jp dir=ltr prefix="og: https://ogp.me/ns#"><head><meta name=generator content="Hugo 0.146.4"><meta charset=utf-8><meta http-equiv=content-type content="text/html"><meta name=viewport content="width=device-width,initial-scale=1"><meta name=Hatena::Bookmark content="nocomment"><title itemprop=name>takeokunn's blog</title>

3. 動作検証

無事動作してくれることが確認できた。

ログイン状態で適当な記事をはてなブックマークで登録
コメントを書く
シークレットブラウザで非表示になっていることを確認

得られた結果・所感

無用な争いを避けられそうなので良かった。

GitHub Actions上でtblsを使ってスキーマ情報を取得してAIでSQLを生成する

Sat, 28 Jun 2025 00:00:00 +0000

背景・動機

日頃から k1LoW/tbls を利用しているが、個人的に気に入ってる運用をメモしておく。

試したこと・やったこと

1. GitHub ActionsでDBに入れつつtblsを実行する

tblsをセットアップするGitHub Actionとしてsetup-tbls（を作るツールとしてgh-setup）を作ったにもあるとおり、k1low/setup-tbls を利用すればGitHub Actions上でtblsを簡単に利用できる。

以下はISUCONで使っているGitHub Actionsだが、Laravelでも同じように php artisan migrate すればよい。 main branchにpushされたら更新される。

MySQLのセットアップ
tblsをインストール
DBにスキーマ情報を反映
tbls docを実行する
dbdoc branchに ./dbdoc を反映してpushする

name: Run db_tbls

on:
 workflow_dispatch:
 push:
 branches:
 - main

permissions:
 contents: write

jobs:
 db-tbls:
 runs-on: ubuntu-latest
 timeout-minutes: 300
 services:
 mysql:
 image: mysql:8
 options: --health-cmd "mysqladmin ping -h localhost" --health-interval 20s --health-timeout 10s --health-retries 10
 ports:
 - 3306:3306
 env:
 MYSQL_DATABASE: isuride
 MYSQL_ROOT_PASSWORD: isucon
 MYSQL_ROOT_HOST: '%'
 steps:
 - uses: actions/checkout@v4
 - uses: k1low/setup-tbls@v1

 - name: Run schema.sql
 run: mysql --host="127.0.0.1" --port=3306 --user="root" --password="isucon" isuride < webapp/sql/1-schema.sql

 - name: Run tbls for generate database document
 run: tbls doc --dsn "mysql://root:isucon@127.0.0.1:3306/isuride"

 - name: Deploy dbdob
 uses: peaceiris/actions-gh-pages@v4
 with:
 github_token: ${{ secrets.GITHUB_TOKEN }}
 publish_dir: ./dbdoc
 publish_branch: dbdoc

2. dbdoc repoを用意する

<repo-name>-dbdoc> を用意する。

php-srcとyieldについて調査メモ

Wed, 25 Jun 2025 00:00:00 +0000

背景・動機

php/php-src でyieldはどう扱われているのか調査したのでメモしておく。

試したこと・やったこと

RFCを読む

2012/06/05にNikita Popov氏が「Request for Comments: Generators」というRFCを出している。 yield構文はPHP 5.5で導入されたようだ。

https://wiki.php.net/rfc/generators

yieldは次の点で優れているという主張をしている。

パフォーマンスとメモリ効率
可読性・保守性
イテレーション処理の標準化

GeneratorのInterfaceは以下。 Iteratorを継承しているのでforeachでloopを回せる。

final class Generator implements Iterator {
 void rewind();
 bool valid();
 mixed current();
 mixed key();
 void next();

 mixed send(mixed $value);
 mixed throw(Exception $exception);
}

他言語の実装は以下。

サンプルコード

最小サンプル

function gen() {
 yield 1;
 yield 2;
 yield 3;
}

$g = gen();

echo $g->current(); // 1
$g->next();

echo $g->current(); // 2
$g->next();

echo $g->current(); // 3
$g->next();

foreach

Iteratorなのでforeachで回せる。

function keyedGen() {
 yield 'first' => 'A';
 yield 'second' => 'B';
 yield 'third' => 'C';
}

foreach (keyedGen() as $key => $val) {
 echo "$key => $val\n"; // first => A / second => B / third => C
}

yield from

yieldの合成可能。

node2nixの使い方

Sun, 22 Jun 2025 00:00:00 +0000

背景・動機

最近のAIツールの隆盛でnpm packageを使う機会が増えてきた。 MCP実行するpackageの管理や、claude codeのようなpackageの管理をNixなどが具体例として挙げられる。

@github/copilot-language-serverをNixで扱う時のメモや mcp-servers-nixを導入したでも node2nix を使っていることを書いていたので、 node2nix の使い方について後学の為に纏めておく。

試したこと・やったこと

1. node2nix周辺調査

公式レポジトリは以下で、「Generate Nix expressions to build NPM packages」というdescriptionがあるとおり、npm packageをnix packageとして扱えるようにしてくれるもの。

https://github.com/svanderburg/node2nix

日本語解説記事は以下。

2. node2nixセットアップ

自分のnixos-configurationに node2nix/ というディレクトリを掘った。

https://github.com/takeokunn/nixos-configuration/tree/main/node2nix

次のようにコマンドを叩くと必要なファイルが作成される。

$ nix-shell -p nodePackages.node2nix
$ echo '["@github/copilot-language-server", "@anthropic-ai/claude-code", "sitemcp"]' >> node-packages.json
$ node2nix -i node-packages.json

3. home-managerに組込み

node2nix のディレクトリをimportして home.packages に登録するだけ。

let
 pkgs = import nixpkgs {
 inherit system;
 config.allowUnfree = true;
 overlays = basicOverlay ++ advancedOverlay;
 };
 nodePkgs = pkgs.callPackage ../node2nix { inherit pkgs; };
in
n{
 home.packages = [
 nodePkgs."@anthropic-ai/claude-code"
 ];
}

4. GitHub Actionsで定期的に更新

一部抜粋すると以下。毎日packageの更新するようにしている。

Typstで履歴書と職務経歴書をBuildする

Thu, 19 Jun 2025 00:00:00 +0000

背景・動機

直近履歴書と職務経歴書を書く必要があった。

以前はGoogle Docsやpagesを使って適当に書いていたのだが、これからのAI時代はコードベースで管理できた方がよいだろうということで移行を決意した。最近Typst推しなのでTypstからPDFをNix Buildで生成できるようにしてみた。

試したこと・やったこと

0. アプローチのやり方を考える

世間一般的には履歴書や職務経歴書の絶対的な規格というものはなく、業界や各事業者によってさまざまな運用がされているらしい。履歴書にはJIS規格があるが、必ずしも準拠する必要はないらしい。

必要な情報というのはある程度決まっており、それに倣っておくと汎用性の高い履歴書と職務経歴書になるということで世の中転がってるものをひととおり確認した。

今回は次のようにコンテンツとテンプレートを分けて、より管理をしやすいように設計した。

YAML: コンテンツをKey/Valueで表現する
Typst: YAMLを読み込んでテンプレートからPDFを作成する

1. レポジトリ作成

現状GitHubのレポジトリや設定をTerraform上で管理しているので、Terraform経由でPrivateレポジトリを作成した。

また、他の人が使えるようにOSS版も作った。

https://github.com/takeokunn/typst-resume-template

2. Nix Build周り整備

fontは日本語を正しく描画してくれるHackgenを選んだ。 fontもNix経由でインストールできるの非常に体験がよい。

https://github.com/takeokunn/typst-resume-template/blob/main/cv/flake.nix

flake.nix:

{
 inputs = {
 nixpkgs.url = "github:NixOS/nixpkgs";
 flake-utils.url = "github:numtide/flake-utils";
 };

 outputs =
 {
 self,
 nixpkgs,
 flake-utils
 }:
 flake-utils.lib.eachDefaultSystem (
 system:
 let
 pkgs = import nixpkgs { inherit system; };
 in
 {
 devShells.default = pkgs.mkShell {
 packages = with pkgs; [ typst ];
 };

 packages.default = pkgs.stdenv.mkDerivation {
 name = "private-career-cv";
 src = ./.;
 nativeBuildInputs = with pkgs; [ typst hackgen-font ];
 buildPhase = ''
 typst compile main.typ --font-path ${pkgs.hackgen-font}/share/fonts/hackgen-nf
 '';
 installPhase = ''
 mkdir -p $out
 cp main.pdf $out/cv.pdf
 '';
 };
 }
 );
}

3. 履歴書テンプレート作成

次の記事を参考に履歴書を書くTypstを作った。

React Router v7周辺キャッチアップメモ

Mon, 16 Jun 2025 00:00:00 +0000

背景・動機

普段からWebフロントエンドは書いているものの、2025年6月現在の最新のフロントエンド事情は追えていなかった。最後にWebフロントエンドを追っていたのが2021年頃だったので3〜4年のビハインドがあった。 2021年頃はNext.jsが最盛期でNext.js一択だった。

仕事の都合で最新のWebフロントエンド事情をキャッチアップする必要に迫られた。新規プロジェクトに生かせる為にどのPackageを使うのがよいのか、トレンドはどう変化したのか、過去使っていたpackageはどうなったのか、新しい概念はあるのか等を調べたのでメモしておく。

また、将来的にAIに書かせること前提にドキュメントの整備方法についても検討する。

試したこと・やったこと

作業レポジトリは以下。練習がてら可能な限りAI（Aider + Gemini 2.5 Pro）に書かせたのでコミット数が多い。

https://github.com/takeokunn/react-router-sandbox

0. キャッチアップ方針決め

キャッチアップをする方法で一番よいのは詳しい人に聞くことなので @ryoppippi と @tomoyaton にそれぞれ2〜3時間くらい質問攻めにした。

その結果次のことが分かった。

Bundleツール
- Webpackは遅いしモダンではない
  - TurbopackやRspackなどWebpack互換のRust製ツールが隆盛
- 今使うならVite
  - esbuildとrollupとのよい所取り
  - rollup互換のRust製ツールであるrolldownが隆盛（experimental）
Component Library
- 結局Reactが選択され続けている
- Vue周りの話は減った
Framework
- Next.jsはモダンではない認識
  - Webpack依存を剥せなくてBuildが重い
  - SSGは廃れた
  - CJS依存
- 2025年6月はReactを使うならReact Router v7を使うのが無難
  - Remixと合流し、「モダンReactのデファクトルーティング」へ変化中
    - ref. https://remix.run/blog/react-router-v7
  - SSR + Partial Rendering
    - Partial Renderingはこの記事が分かりやすい
      - ref. https://nextjs.org/docs/app/getting-started/partial-prerendering
  - オススメのディレクトリ構造などを教えてもらった
  - react-router typegen で型情報を出力できるようになって一気にType Safeになったらしい
UI Library
- Mantineが使い勝手がよい
Request Library
- swrあたりを使っておくのが無難
- 最近はtanstack queryの方が人気らしい
Logging Library
- pinoが使い勝手良かったらしい
Testing Library
- Lint/Formatter
  - 依然としてESLint/PrettierがあるけどBiomeが強い
- Unit TestはVitestを使うとよい
  - Jest互換でTypeScript Native
  - ESMベース
- 残りのE2Eやらは都度考える
  - 場合によってstorybookやらPlaywrightやらを使うとよい
CI/CD
- GitHub Actionsで回しちゃうのが楽でよい
Package Manager
- npm/yarn/pnpmがあるが、基本的には好きなものを使えばよい
- OSSはpnpmを使ってるプロジェクトが多い
Form/Validation Library
- conformが使い勝手良くてよいらしい
- zod/valibotあたりを使うのば無難らしい
Hosting
- SSRするのでWebサーバを用意する必要がある
- Cloudflare workerやらAWS ECSやら選択肢が色々ある
Runtime
- Node/Deno/Bunがある
- Node/DenoはV8、BunはJavaScript Coreを積んでいる
- 何も考えたくなければNodeだけど、Bunの方が速度出るかも?

1. 技術選定

今回の練習用レポジトリで実際に試してみる技術は以下。

home-managerで自作moduleを作る

Sat, 14 Jun 2025 00:00:00 +0000

背景・動機

home-managerには沢山のmoduleが提供されている。

https://github.com/nix-community/home-manager/tree/master/modules

home-manager moduleは自分でも作成可能なので後学のためにメモしておく。

https://github.com/takeokunn/nixos-configuration/tree/e2cf7d9df556a56e242b3f44b0957884cd6191dd/home-manager/modules

試したこと・やったこと

0. なぜやるのかの整理

大きく分けて3パターンが考えられる。

home-managerで自作moduleを作る
ファイルを作成してhome-managerでsymbolic linkを貼る
Nix管理外でメンテする

1とそれ以外で次のようなメリット/デメリットが考えられる。可能な限りNix（Nix式）に寄せたいと考えているので今回採用することにした。

Pros

観点	内容
フォーマット抽象化	多様なフォーマットを意識せずに Nix 式で統一管理できる
IDE支援	Nix LSP の補完・型チェックの恩恵を受けられる
統一性	`nixpkgs` の差し替えなど、構成記述の一貫性・統一性が上がる
再利用性	モジュールとして切り出すことで複数環境で再利用しやすくなる
ライフサイクル	rebuild switchのライフサイクルで反映できる
変数埋込	Nixから変数を代入できる

Cons

観点	内容
表現力の制限	tmux.confのようなフォーマットは文字列での管理が必要
LSPの範囲	LSP は Nix に対してしか効かず、生成対象の構文チェックは別途必要
保守性	作り込むと構造が複雑化し、メンテナンスコストが上がる可能性がある
依存性	home-manager に構成が強く依存し、他ツールへの移行が難しくなることも
デバッグ性	モジュール解決や展開の追跡が難しく、デバッグの難易度が多少上がる

1. 自作home-manager moduleを作成する

home-mnaagerのobjectでimportするだけで使える。

https://github.com/takeokunn/nixos-configuration/blob/e2cf7d9df556a56e242b3f44b0957884cd6191dd/home-manager/advanced.nix#L71

1.1. tigの場合

~/.tigrc に文字列をそのまま出力する運用にしている。

home-manager/modules/tig/default.nix

{
 pkgs,
 lib,
 config,
 ...
}:
let
 cfg = config.programs.tig;
in
with lib;
{
 options.programs.tig = {
 enable = mkEnableOption "Text-mode interface for git";
 package = mkPackageOption pkgs "tig" { };
 config = mkOption {
 type = types.lines;
 default = "";
 };
 };

 config = mkIf cfg.enable {
 home.packages = [ cfg.package ];
 home.file.".tigrc".text = cfg.config;
 };
}

1.2. lnavの場合

~/.config/lnav/config.json にNix式をJsonに変換して出力するようにしている。

AIを駆使してTypstスライドを生成する

Tue, 10 Jun 2025 00:00:00 +0000

背景・動機

Typstとpdfpcでプレゼン機能を実現するのNext Actionに次のようなことを書いた。

登壇の場数を踏んでより洗練させていきたい。登壇周りのすべてがプレーンテキスト（Org）で管理できるようになったので、次はAIによるスライド生成にチャレンジしたい。

実際に練習がてら登壇してみたかったので、第177回 PHP勉強会＠東京で「Typstで登壇できるようになったので練習させてくれ」というテーマでLTをすることにした。

そこで今回は実際にAIにスライドの目次案からTypstを生成させてホスティングする所までやってみた。

試したこと・やったこと

1. AIでプロンプトを作る

プロンプト

関連するブログをリストアップしてMarkdownで目次を生成させてみた。

「typstで登壇できるようになったので練習させてくれ」というタイトルでLTしようと考えています。

登壇資料のアウトラインを作りたいです。
以下の記事を読んで起承転結でMarkdownで纏めてください。

- Typstとpdfpcでプレゼン機能を実現する
 - https://www.takeokunn.org/posts/fleeting/20250608145128-presenting_with_typst_pdfpc/
- Typst自作テーマで登壇スライドを作成した
 - https://www.takeokunn.org/posts/fleeting/20250601214129-create_slide_by_typst_self_theme/
- Typstテーマを自作した
 - https://www.takeokunn.org/posts/fleeting/20250506220914-create_typst_slide_theme/
- NixでTypstをBuildしGitHub Pagesでホスティングする
 - https://www.takeokunn.org/posts/fleeting/20250126114218-build_and_deploy_typst_using_nix/

アウトライン例

以下は対話しながらGeminiから生成させたものを改変した。

# Typstで登壇できるようになったので練習させてくれ
## 全体構成
### きっかけと違和感

- かつてはGoogle Slidesは最高の相棒だった
 - 画像位置を調整するのが簡単
 - 過去に作ったスライド資産がある
 - 外部への共有も簡単
- スライド作成の流れ
 - Emacsでアウトラインを書く
 - 過去スライドをコピペしてくる
 - アウトラインに沿ってスライドを作る
 - スピーカーノートを用意する
- 心に刺さった"小さなトゲ
 - プレーンテキストで管理できない
 - AIによる自動生成できない
 - Emacsから編集できない
 - etc...
- 違和感の正体 = エンジニアとしての"業"（カルマ）
 - バージョン管理が恋しい
 - 再利用性が低い (No DRY!)
 - 自動化できない
- 僕らは、スライドという成果物も“コード”として管理したい生き物なんだ！

### Typstとの出会いと感動

- そんな僕が出会ったのが"Typst"
 - まさに「プレゼン資料も構造化・宣言的に書ける」言語
 - 探し求めていた理想がそこにあった
- 最初の感動ポイント（＝"トゲ"が抜けていく快感）
 - コードでスライドが書ける → Emacsから離れなくていい！
 - アウトライン作成からスライド執筆まで、すべてが愛用のエディタで完結
 - Gitで管理できる → 変更履歴はすべてお見通し！
 - テーマが自作できる → DRY原則、スライドにも！
 - コードハイライトが美しい → エンジニアとして一番見せたいものが輝く！
- Typstスライドを支える技術（しくみ）
 - Polylux：Typstのためのスライドエンジン
 - codelst：コードを美しく見せるスタイリスト
 - Nix：すべてを固める魔法の環境

### 実用に耐えるまでの道のり

- しかし、現実は甘くなかった
 - 理想の環境はすぐそこに見えたが、やってみると色々な壁にぶつかる
 - 「言うは易く行うは難し」を実感する日々
- やってみて困ったこと（理想と現実のギャップ）
 - テーマの調整が超むずい
 - polyluxやcodelstのドキュメントとひたすらにらめっこ
 - 絵文字： Macでは出るのにCI（Linux）でビルドすると豆腐（□）になる！
 - フォント設定： この日本語フォントを使いたいだけなのに…
 - 画像の配置： ドラッグ＆ドロップの偉大さを思い知る
- それでも続けた理由（Typstの魅力に立ち返る）
 - 記法が明快で、根本的な書き心地は最高だった
 - スライド構成が自分の思考にフィットした
 - 「構造から考え、中身を埋める」スタイルが気持ちよかった
- 補助ツールとの統合（そして"最強"の環境へ）
 - Typst単体ではなく、エコシステム全体で課題を解決していく
 - pdfpc：ついに「登壇」できるようになった瞬間
 - GitHub Actions：完全なる自動化の世界へ
 - Hugo：発表資料を"資産"にする

### Typst登壇はこう変えた

- Typstを手に入れた結果、登壇準備のすべてが変わった
 - Before/Afterで振り返る、スライド制作プロセスの変化
 - 「きっかけと違和感」で感じていた違和感がすべて解消されていく
- 登壇準備がこう変わった！
 - 迷わず構成から入れる
 - Before：まずGoogle Slidesを開き、どのテーマにしようか悩む…
 - After：まずEmacsでアウトライン（構造）を書くことに集中できる
 - 見た目を気にしすぎなくていい
 - Before：テキストボックスの位置、フォントサイズ…ピクセル単位の調整地獄
 - After：自作テーマを適用すればOK。「見た目は後からついてくる」安心感
 - 再利用性・再現性が圧倒的に高い
 - Before：過去スライドからコピペ。コピペミスやうっかり編集しちゃったなどヒューマンエラーが頻発。
 - After：過去の資産はGitリポジトリに。Nixのおかげで誰でも同じPDFを生成
- Typstで登壇する未来
 - 自分だけのテーマを育てる文化
 - 発表のたびにテーマを少しずつ改善していく。自分だけの"刀"を研ぐ感覚
 - コード × 構造 × 登壇の三位一体
 - Slide as Codeの世界へようこそ
- まとめとメッセージ
 - Google Slidesへの違和感から始まり、困難を乗り越え、最強の環境を手に入れました
 - 「一度書いてみれば、この快感が分かる」
 - 発表資料も"成果物"にしたい、すべてのエンジニアへ
 - その場限りの資料ではなく、再利用可能な“資産”を作りたい人は、ぜひTypstへ！

2. Gemini 2.5 Proに実装させる

作業指示を書いて8割くらいのクオリティでAIに実装させる。

EventBridge Ruleデバッグ方法メモ

Sun, 08 Jun 2025 00:00:00 +0000

背景・動機

業務をしていると、「EventBridgeでメタ情報を付与してSQSに流す」といった要件に出くわす機会がある。

e.g. AWS SQSとLaravelで大規模トラフィックを捌く - phpcon新潟

Event Busが一次受けをして複数のEventBridge Ruleでマッチしたものに情報を付与して次に流す、といった挙動になっている。

EventBridge RuleのデバッグをするにはAmazon EventBridge でイベントに応答するルールの作成に書いてあるとおりにやればいいのだが、AWSのドキュメントは初学者から見たら分かりにくく混乱した。今回は後学の為に画像付きでメモしておく。

試したこと・やったこと

1. AWS consoleから対象のEventBridge Rulesを開く

対象のEventBusを選択して Create Rule を押す。

2. 「Build event pattern」を開く

Define rule detailのnameは適当に入れる。

3. Sample eventでJsonを入れる

「Enter my own」を選択して「Misc > Webhook Sample」にあるようなテスト用のJsonを入れる。

以下はShopifyの inventory_items/create の実データをマスクしたもの。

{
 "version": "0",
 "id": "xxx-xxx-xx-xxx",
 "detail-type": "shopifyWebhook",
 "source": "aws.partner/shopify.com/000000/test",
 "account": "000000000000",
 "time": "2025-03-01T06:29:19Z",
 "region": "ap-northeast-1",
 "resources": [],
 "detail": {
 "payload": {
 "id": 100000000000,
 "sku": "",
 "created_at": "2025-03-01T01:29:17-05:00",
 "updated_at": "2025-03-01T01:29:17-05:00",
 "requires_shipping": true,
 "cost": null,
 "country_code_of_origin": null,
 "province_code_of_origin": null,
 "harmonized_system_code": "111111",
 "tracked": true,
 "country_harmonized_system_codes": [],
 "admin_graphql_api_id": "gid://shopify/InventoryItem/0000001"
 },
 "metadata": {
 "Content-Type": "application/json",
 "X-Shopify-Topic": "inventory_items/create",
 "X-Shopify-Shop-Domain": "test.myshopify.com",
 "X-Shopify-Hmac-SHA256": "xxxx",
 "X-Shopify-Webhook-Id": "xxx-xxx-xxx-xxx-xxxx",
 "X-Shopify-API-Version": "2024-10",
 "X-Shopify-Triggered-At": "2025-03-01T06:29:17.989779121Z"
 }
 }
}

4. Event patternを入力してテストをする

検証したいEventBridge Ruleを貼り付けて「Test pattern」をすると検証できる。

Typstとpdfpcでプレゼン機能を実現する

Sun, 08 Jun 2025 00:00:00 +0000

背景・動機

Typstでスライドを作るフローがだいぶ固まってきた。

過去に普段資料はGoogle Slideで作成していたのだが、次の理由でGoogle Slideを使っていた。

例: AWS SQSとLaravelで大規模トラフィックを捌く - phpcon新潟

Google Driveで管理できる
自己紹介部分など過去のスライドを流用できる
文字や画像の配置に自由度がある
プレゼンター表示ができる
- スピーカーノートを別画面で確認できる
- 経過時間の計測ができる

管理方法やスライドに関するものはTypst力が上がればカバーできるが、プレゼンター表示に関しては何か対策を講じなければ代替できない。

今回は実際に登壇に耐えうるツールの選定と運用の検討をしたのでメモしておく。

試したこと・やったこと

0. ツールの選定

自分がプレゼンテーションモードに求めている機能をリストアップすると以下。

MUST
- 登壇スライドとは別にスピーカーノートを別画面で確認できる
- 経過時間の計測ができる
- Typst内 or Orgファイル内でスピーカーノートを管理できる
SHOULD
- 次スライドの表示
- 全体のスライド表示
MAY
- ホワイトボード／ペンツール機能
- オフラインで機能する
- 動画やスライドアニメーションなどの制御

Typstから生成したPDFをそのままプレゼン資料として表示できるツールは無数にある。

Typstテーマを自作したにも書いたとおり、Typstのベーステーマに polylux を利用している。

polyluxのドキュメントを読んでいるとpdfpcと繋ぎ込む記述があり、これを用いるとスピーカーノートを実現できることが分かる。可能な限り公式がサポートしているものを使う方が筋がよい、また要件を十分に満たしていることが確認が取れたので今回はpdfpcを選択した。

https://polylux.dev/book/external/pdfpc.html#pdfpc

1. Typstとpdfpcとの繋ぎ込み

pdfpc integrationは polylux-typ/polylux の src/toolbox/pdfpc.typ にある。使い方は簡単で、次のように記述するだけでよい。

#import "@preview/polylux:0.4.0": *

#slide[
 #toolbox.pdfpc.speaker-note("This is a note that only the speaker will see.")
]

polylux2pdfpcを使ってpdfpcファイルを生成する。

Typst自作テーマで登壇スライドを作成した

Sun, 01 Jun 2025 00:00:00 +0000

背景・動機

Nix meetup #3 大阪で大阪への新幹線の中で登壇スライドを作成した。

https://www.takeokunn.org/pdf/nix-meetup-3-my-nix-usecase.pdf

今まではGoogle Slideでスライドを作成していたが、今回は Typstテーマを自作したにもあるとおり自作テーマで初の登壇仕様を作成してみた。

スライドは作ったものの、時間の関係で登壇できなかったので別の機会で流用する。

試したこと・やったこと

「オープニングスライド」の場合

「Agenda」の場合

#outline で自動で取得できる。

#slide[
 = Agenda

 #outline
]

#new-section が対象。

#new-section[自己紹介]
#new-section[今回話したいこと]
#new-section[事例紹介]
#new-section[今後やりたいこと]

「自己紹介スライド」の場合

画像は #place で右上に表示。

#slide[
 #place(
 top + right,
 image("./images/icon.jpeg", width: 100pt)
 )

 = 自己紹介

 - たけてぃ \@takeokunn
 - Nix Meetup 共同主催
 - Nix歴ようやく1年経った
 - 仕事ではPHPコミュニティ所属
 - 個人ではテキストエディタコミュニティ所属
]

「ソースコード」の場合

コードは #sourcecode でシンタックスハイライトされる。

keyoxideセットアップ

Wed, 28 May 2025 00:00:00 +0000

背景・動機

友人のこまもか君（@Comamoca_）がTwitterでなりすましをされていた。

なりすましを発見したので本物であることを主張しておきますね〜

署名済みテキスト:https://t.co/Q5jcSsJACw

keybase:
僕のGitコミットは基本的にkeybase管理下のPGP鍵で署名してるので、なんか怪しい人いたら各自検証してください
🙏https://t.co/ufJ5K1j5ig
— こまもか🦊 (@Comamoca_) May 27, 2025

自分はまだされたことがないが、将来的になりすまされた時の為に今のうちに手を打っておこうということで今回対応した。

試したこと・やったこと

0. 方針を決める

インターネットでなりすましではないことを証明するのは根本的に難しい。

ChatGPTによると、本人性を証明するためのアプローチは次の3つが上げられる。

A. 他媒体連携型証明（クロスメディア検証）
B. 動画・写真による自己証明
C. 本人だけが知る事実・履歴を提示

今回の要件としては、自分のことをあまり知らない不特定多数から見て自己をどう証明するのかというものがある。私の場合Twitter/GitHub/ブログがメインなので、これらを証明する手段が求められている。（A. 他媒体連携型証明）

GPG KeyのYubiKey運用をはじめたにも書いたとおり、可能な限りGPGに寄せたいと考えている。自分のソーシャルアカウントや公開鍵との関連性を証明するサービスはいくつかあるようだ。

Keybase
Keyoxide
Sigstore
etc..

当初keybaseを採用しようとしていたが、自分にとってSNS機能は不要だったり、Zoomが買収してから開発が停滞気味という噂を聞き、Keyoxideを採用することにした。

また友人のnatsukiumも利用していたので決断の後押しになった。

https://keyoxide.org/DCCB2D69E06EEAA48904F8A12D5ADD7530F56A42

1. Keyoxideに認識させる

基本的にはドキュメントを参考に上から順に行えばよい。

https://docs.keyoxide.org/getting-started/creating-profile-openpgp/

GPG KeyのYubiKey運用をはじめたですでにSigned Keyは持っていたのでGPG Key生成手順はスキップできた。

次のコマンドで public.asc を生成して管理画面からアップロードする。

https://keys.openpgp.org/upload

$ gpg --armor --output public.asc --export <key>

keyoxide側が勝手にopenpgpを参照してページを作ってくれる。

https://keyoxide.org/0B10DAA7BA0236D7382287660F79C0AB03FD7A1C

2. Twitter紐付け作業

こちらを参考に対応する。

https://docs.keyoxide.org/service-providers/twitter/

openpgp4fpr:<fpr> を含めたツイートをする。

keyoxide用

openpgp4fpr:0B10DAA7BA0236D7382287660F79C0AB03FD7A1C
— たけてぃ𓁈𓈷 (@takeokunn) May 27, 2025

ツイートのリンクを notation で付与する。

Excelファイルをtxtファイルに変換してNotebookLMに食わせる

Fri, 23 May 2025 00:00:00 +0000

背景・動機

利用規約の関係で明確に言及できないが、某ECプラットフォーム（以下 A社）とのAPI連携を実装していた。

A社のAPI含む全体的なドキュメントの管理方法は次のようになっている。

APIの情報がWeb上に公開されていない
- 技術ブログに書いている人がいない
管理画面を使うには申請が必要
管理画面の奥の方にAPIドキュメントがある
APIドキュメントをzipでダウンロードする方式
- EndpointごとにExcelファイルが入っている
- セルの結合などを駆使して見易いように書かれている
- Excelのシートが複数枚ある
エラーメッセージなどは別のダウンロードリンクに纏まっている

開発する上で次のような問題を抱えていた。

今回の対応で必要なEndpointの取捨選択を効率的にしたい
ひとつずつExcelファイルを開いて確認するのが面倒
横断した情報の整合性を確認するのが大変

今回のようにExcelファイルが与えられた時にどう対応するべきなのか後学の為にメモしておく。

試したこと・やったこと

1. ExcelファイルをGoogle Driveにアップロードする

ExcelファイルをGoogle DriveにアップロードするとSpreadSheetから閲覧できる。こうすることで、ExcelファイルにURL Linkからアクセスすることが可能になるのがよい。

2. Excelファイルを文字列に起こす

xlsx2csv を使ってcsvファイルに変換する。

$ xlsx2csv -s 2 tmp.xlsx > tmp.csv

-s オプションでシート番号を指定できる。

usage: xlsx2csv [-h] [-v] [-a] [-c OUTPUTENCODING] [-d DELIMITER] [--hyperlinks] [-e] [--no-line-breaks] [-E EXCLUDE_SHEET_PATTERN [EXCLUDE_SHEET_PATTERN ...]] [-f DATEFORMAT] [-t TIMEFORMAT]
 [--floatformat FLOATFORMAT] [--sci-float] [-I INCLUDE_SHEET_PATTERN [INCLUDE_SHEET_PATTERN ...]] [--exclude_hidden_sheets] [--ignore-formats IGNORE_FORMATS [IGNORE_FORMATS ...]]
 [-l LINETERMINATOR] [-m] [-n SHEETNAME] [-i] [--skipemptycolumns] [-p SHEETDELIMITER] [-q QUOTING] [-s SHEETID] [--include-hidden-rows]
 xlsxfile [outfile]

xlsx to csv converter

positional arguments:
 xlsxfile xlsx file path, use '-' to read from STDIN
 outfile output csv file path

options:
 -h, --help show this help message and exit
 -v, --version show program's version number and exit
 -a, --all export all sheets
 -c OUTPUTENCODING, --outputencoding OUTPUTENCODING
 encoding of output csv ** Python 3 only ** (default: utf-8)
 -d DELIMITER, --delimiter DELIMITER
 delimiter - columns delimiter in csv, 'tab' or 'x09' for a tab (default: comma ',')
 --hyperlinks, --hyperlinks
 include hyperlinks
 -e, --escape Escape \r\n\t characters
 --no-line-breaks, --no-line-breaks
 Replace \r\n\t with space
 -E EXCLUDE_SHEET_PATTERN [EXCLUDE_SHEET_PATTERN ...], --exclude_sheet_pattern EXCLUDE_SHEET_PATTERN [EXCLUDE_SHEET_PATTERN ...]
 exclude sheets named matching given pattern, only effects when -a option is enabled.
 -f DATEFORMAT, --dateformat DATEFORMAT
 override date/time format (ex. %Y/%m/%d)
 -t TIMEFORMAT, --timeformat TIMEFORMAT
 override time format (ex. %H/%M/%S)
 --floatformat FLOATFORMAT
 override float format (ex. %.15f)
 --sci-float force scientific notation to float
 -I INCLUDE_SHEET_PATTERN [INCLUDE_SHEET_PATTERN ...], --include_sheet_pattern INCLUDE_SHEET_PATTERN [INCLUDE_SHEET_PATTERN ...]
 only include sheets named matching given pattern, only effects when -a option is enabled.
 --exclude_hidden_sheets
 Exclude hidden sheets from the output, only effects when -a option is enabled.
 --ignore-formats IGNORE_FORMATS [IGNORE_FORMATS ...]
 Ignores format for specific data types.
 -l LINETERMINATOR, --lineterminator LINETERMINATOR
 line terminator - lines terminator in csv, '\n' '\r\n' or '\r' (default: \n)
 -m, --merge-cells merge cells
 -n SHEETNAME, --sheetname SHEETNAME
 sheet name to convert
 -i, --ignoreempty skip empty lines
 --skipemptycolumns skip trailing empty columns
 -p SHEETDELIMITER, --sheetdelimiter SHEETDELIMITER
 sheet delimiter used to separate sheets, pass '' if you do not need delimiter, or 'x07' or '\f' for form feed (default: '--------')
 -q QUOTING, --quoting QUOTING
 quoting - fields quoting in csv, 'none' 'minimal' 'nonnumeric' or 'all' (default: minimal)
 -s SHEETID, --sheet SHEETID
 sheet number to convert
 --include-hidden-rows
 include hidden rows

次のように再帰的に実行するのでもよい。

DeepWiki調査メモ

Sun, 18 May 2025 00:00:00 +0000

背景・動機

Devin社が開発したDeepWikiが世間を賑わせていた。

https://deepwiki.com/

DeepWiki: あらゆるGitHubリポジトリに対応する最高のAIドキュメントジェネレーターにもあるとおり、DeepWikiは次のような機能を提供してくれている。 DeepWikiが生成するドキュメントは圧倒的に質が高く、まさしく顧客が求めていたものを提供してくれているなという感想。

レポジトリ内のドキュメントを自動生成
対話型AIアシスタント
フローチャート生成

DeepWikiはDevinに契約していればPrivate Repoにも使えるが、個人がDevinを契約するのは流石にハードルが高い。

DeepWikiが自分にとってどれくらい使いものになるのか、またOSS版の AsyncFuncAI/deepwiki-open を使ってみて、どのくらいの精度で出力されるのか調査をした。

試したこと・やったこと

1. 普段よく使うOSSにDeepWikiを使う

普段よく使っていて、内部的にどう動いているのかある程度把握してるレポジトリをコード規模ごとに選定した。書いてあることに嘘はないか、網羅性はどうか、実用に耐えうるかを確認した。

大規模（100万行）
- e.g. https://deepwiki.com/emacs-mirror/emacs
中規模（10万行）
- e.g. https://deepwiki.com/emacs-lsp/lsp-mode
小規模（1万行以内）
- e.g. https://deepwiki.com/x-motemen/ghq

Chatで普段使ってる人しか知らなさそうなことを質問しまくって精度を確認した。その結果、ドキュメントの質も網羅性も自分の用途では申し分がないことが確認できた。

2. DeepWikiに自分のPublic Repoを食わせてみる

それなりのコード量のある自分のPublic RepoをDeepWiki食わせてみた。

解説記事を書く手間が省けたし、自分しか知らないことをChatで対話しても明瞭に回答してくれた。

3. OSS版のAsyncFuncAI/deepwiki-openを試す

AsyncFuncAI/deepwiki-open をLocal立ち上げて動かしてみる。

記事公開日現在、DeepWikiで生成されたものとdeepwiki-openが生成したものを見比べてみた。 DeepWikiには多少劣るが、かなりのクオリティで出力されるようになった。

deepwiki-openにもチャット機能があるが、こちらも十分に機能してくれていることを確認した。

得られた結果・所感

DeepWikiのクオリティが圧倒的に高いことがわかったので、今後OSSコードリーディングにDeepWikiを利用していくことにした。

deepwiki-openは当初触った時、あまり網羅性がなく質の悪いアウトプットだったが、2週間くらい経って一気にクオリティが上がった。 AI関連ツールの進化は尋常じゃないくらい早いので2週間前に使ってイマイチだったからといって使えないと判断するのは早計だなと改めて感じた。

@ryoppippi がDeepWikiのbadgeを作れるOSSを作っていたので流行に乗って takeokunn/blog と takeokunn/nixos-configuration に配置した。（Thanks ryopi）

https://t.co/GBM768y5Ev https://t.co/4OzgVqloK9
GitHubのREADME用にDeepWikiのバッジを簡単に生成できるサイトを作りました！ぜひ使ってみてください
— ryoppippi (@ryoppippi) April 26, 2025

今後の展開・検討事項

Aiderに食わせる為のコーディング特化のDeepWikiを作りたいのでMastraで自作する。

Backlinks

php-srcとyieldについて調査メモ

Emacs lsp-modeに新しいClientを追加する方法

Sun, 18 May 2025 00:00:00 +0000

背景・動機

メジャーなEmacsのLSP Clientは3種類ある。

それぞれメリットデメリットがあるが、自分としてはlsp-modeを推していて今後も使い続けるつもりでいる。 lsp-mode最大のメリットはClientサポート数の多さにあり、メジャーなLSP Clientなら必ず収録されていると言っても過言ではない。

過去に次の2つのClientを追加するPRを出したことがあるので、後学の為にも追加方法を纏めておく。

Add support for Python(ty) #4785
- 追加で修正してくれた lsp-python-py: make it add-on and activated on python #4786
Add support for Jsonnet #4283

試したこと・やったこと

0. Language Server選定

追加したいLSP Serverをみつける。流石に個人が趣味で開発した中途半端なものは避けるべきだと思うが、そこは取り込む人が判断するのでとりあえず出してみるのがよいかもしれない。

CONTRIBUTINGを熟読して、Pull Requestにすでにあるかどうかを確認する。

https://github.com/emacs-lsp/lsp-mode/blob/master/CONTRIBUTING.md

1. Repoをforkして手元に落とす

emacs-lsp/lsp-mode からforkボタンを押して、自分の手元にGit Cloneする。

EmacsからPATHを通して (require 'lsp-mode) を実行する。

2. lsp-modeの設定をする

clients/lsp-python-ty.el のように clients/ に空気を読んでファイルを作成する。

Jsonnetの場合は以下。

最低限次の2つを定義すればよい。完成度の高いLanguage Serverはオプションがあるので defcustom で都度定義する。

server-executable
lsp-register-client

https://github.com/emacs-lsp/lsp-mode/blob/master/clients/lsp-jsonnet.el

(require 'lsp-mode)

(defgroup lsp-jsonnet nil
 "LSP support for jsonnet."
 :group 'lsp-mode
 :link '(url-link "https://github.com/grafana/jsonnet-language-server"))

(defcustom lsp-clients-jsonnet-server-executable '("jsonnet-language-server")
 "The jsonnet language server executable to use."
 :group 'lsp-jsonnet
 :risky t
 :type '(repeat string))

(lsp-register-client
 (make-lsp-client
 :new-connection (lsp-stdio-connection (lambda () lsp-clients-jsonnet-server-executable))
 :activation-fn (lsp-activate-on "jsonnet")
 :priority -1
 :major-modes '(jsonnet-mode)
 :server-id 'jsonnet-lsp))

(lsp-consistency-check lsp-jsonnet)

(provide 'lsp-jsonnet)

3. 手元で動作確認する

ちょうどよいサイズのプロジェクトを手元に用意して実際に動かしてみる。基本的なLSP機能が正常に動くか確認する。

GitHub Actions内で署名付きCommitをする

Sun, 18 May 2025 00:00:00 +0000

背景・動機

Terraform GitHub Providerを導入したで署名付きCommitを強制するBranch Ruleを網羅的に適用した。

resource "github_repository_ruleset" "default-branch" {
 name = "main"
 repository = "repo-name"
 target = "branch"
 enforcement = "active"

 conditions {
 ref_name {
 include = ["~DEFAULT_BRANCH"]
 exclude = []
 }
 }

 rules {
 required_signatures = true
 non_fast_forward = true
 }
}

2025年5月現在、 takeokunn/nixos-configuration では次のGitHub Actionsが動いている。

毎日20時に発火する
nix flake update などを実行して依存を更新する
変更をcommitしてpushする

署名付きCommitを強制する変更を加えた影響で「3. 変更をcommitしてpushする」が動かなくなってしまった。

調べた所、GitHub Actions内で署名付きCommitをしている人が世の中に少なかったので対応方法を纏めておく。

試したこと・やったこと

1. 署名用のGPG Keyを生成する

GPG KeyのYubiKey運用をはじめたにあるとおり、自分の手元では主鍵副鍵運用をしている。

主鍵から addkey Signのみを付与した副鍵を生成する。生成する際に必ずパスフレーズも設定する。

後に使うのでフィンガープリントもメモしておく。

$ gpg -K --with-fingerprint

2. GitHub Actions Secretに副鍵のPrivate Keyを登録する

GPG_PRIVATE_KEY と PASSPHRASE を設定する。

個人的Local環境のGit Branch運用について

Sun, 18 May 2025 00:00:00 +0000

背景・動機

複数人で触っているRepoをLocalでGit操作する時、次のような問題が発生していた。

直pushしてしまった
意図しない作業ブランチで作業してしまった
コンフリクト解消ミスで本来必要なコードを消してしまう

GitHubのBranch RuleやCIなどでミスを防ぐべきだが、そういうのが整っていない環境というのは多々ある。自衛のために個人的に行っているGit Branch運用について纏めておく。

当記事の前提は以下。

Git ClientはMagit
Default Branchは main
GitHubを利用している

試したこと・やったこと

0. 方針を決める

基本方針は以下。

最新のRemote Branchを常に取得する
デフォルトがLocal Branchが一切ない状態にする
- main Branchすら用意しない
作業するタイミングのみ Local Branchを作成する
- 作業が終わったら必ずGit Pushする（Remote管理）

1. 手元から一切のLocal Branchを消す

次のようなLocal Branchがあったとする。

$ git branch
 feature/xxx
 feature/yyy
 feature/zzz
* main

origin/main に移動して、 main Branch含めすべてのLocal Branchを削除する。

$ git checkout origin/main

$ git branch -D main
$ git branch -D feature/xxx
$ git branch -D feature/yyy
$ git branch -D feature/zzz

次のような状態になるとよい。

2025年5月 Macの再インストール手順メモ

Wed, 14 May 2025 00:00:00 +0000

背景・動機

たまたまMacを再インストールする必要があった。普段、手元のマシンの環境構築手順を洗練させてたお陰で少ないステップで構築できたので何をやったのか後学の為にメモしておく。

試したこと・やったこと

0. Macの生前整理と初期化動線

データが消えてもいいようにバックアップしておく。基本的にGoogle DriveかGitHubにすべてが置いていて今日PCが故障しても問題ない運用にしている。

消えてほしくないデータをGoogle Driveに置く
commit漏れてるrepoがないか確認して必要ならpushしておく

初期化動線は通常のmacの初期セットアップなので割愛。

1. homebrewを入れる

terminal.appを開いてhomebrewをインストールする。

https://brew.sh/ja/

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. nixos-configurationを実行する

YubiKeyを挿した状態でnix buildを実行する。必要なツールとmac固有の設定はほぼすべて自動で入るようになっている。

$ git clone https://github.com/takeokunn/nixos-configuration
$ cd nixos-configuration
$ nix run nix-darwin --extra-experimental-features 'flakes nix-command' -- switch --flake .#OPL2212-2 --show-trace

3. GPG/SSH回りを設定する

GPG KeyのYubiKey運用をはじめたにある「3. 新規端末で副鍵（Sign, Auth）を入れる」以降を行う。

GitHubのssh認証を確認する。

$ ssh -T git@github.com
Hi takeokunn! You've successfully authenticated, but GitHub does not provide shell access.

4. 必要なレポジトリを落としてsecret.orgをorg-babel-tangleする

$ ghq get で必要なレポジトリを網羅的に落とす。 credential管理をorg-encryptからpassword-storeに移行したのとおり、 M-x org-babel-tangle でpassword-storeを実行して必要な設定ファイルのほぼすべてを配置できるようにしている。

巨大なLaravelレポジトリでphpactorを使うTips

Wed, 14 May 2025 00:00:00 +0000

背景・動機

手元で intelephense が最近調子が悪く、定義ジャンプや補完が全然効かなくなってしまった。

phpactorの方がintelephenseよりもちゃんと機能してくれる肌感があったが、いかんせん大きいプロジェクトでは重く使いものにならない印象を持っていた。しかし、phpactor周辺の設定を徹底したら快適に動くようになってくれたので対応項目をメモしておく。

巨大なLaravelレポジトリの情報は以下。

プロジェクト	version	コード行数	phpstan level
A	7.4	140万行超	5
B	8.2	40万行	max/strict-rule

マシンスペックは以下。

$ nix run nixpkgs#fastfetch

 ..' obara@OPL2212-001
 ,xNMM. -----------------
 .OMMMMo OS: macOS Sequoia 15.5 arm64
 lMM" Host: MacBook Pro (14-inch, 2021)
 .;loddo:. .olloddol;. Kernel: Darwin 24.5.0
 cKMMMMMMMMMMNWMMMMMMMMMM0: Uptime: 1 day, 6 hours, 50 mins
 .KMMMMMMMMMMMMMMMMMMMMMMMWd. Packages: 1375 (nix-system), 52 (nix-default), 6 (brew), 14 (brew-cask)
 XMMMMMMMMMMMMMMMMMMMMMMMX. Shell: fish 4.0.2
;MMMMMMMMMMMMMMMMMMMMMMMM: Display (Color LCD): 3600x2338 @ 120 Hz (as 1800x1169) in 14" [Built-in]
:MMMMMMMMMMMMMMMMMMMMMMMM: DE: Aqua
.MMMMMMMMMMMMMMMMMMMMMMMMX. WM: Quartz Compositor 278.4.7
 kMMMMMMMMMMMMMMMMMMMMMMMMWd. WM Theme: Multicolor (Dark)
 'XMMMMMMMMMMMMMMMMMMMMMMMMMMk Font: .AppleSystemUIFont [System], Helvetica [User]
 'XMMMMMMMMMMMMMMMMMMMMMMMMK. Cursor: Fill - Black, Outline - White (32px)
 kMMMMMMMMMMMMMMMMMMMMMMd Terminal: tmux 3.5a
 ;KMMMMMMMWXXWMMMMMMMk. CPU: Apple M1 Pro (8) @ 3.23 GHz
 "cooc*" "*coo'" GPU: Apple M1 Pro (14) @ 1.30 GHz [Integrated]
 Memory: 20.76 GiB / 32.00 GiB (65%)
 Swap: Disabled
 Disk (/): 153.68 GiB / 460.43 GiB (33%) - apfs [Read-only]
 Local IP (en0): 172.16.80.163/18
 Battery (bq40z651): 100% [AC connected, Charging]
 Power Adapter: 39W
 Locale: en_US.UTF-8

なお、phpactorについてはPHPerKaigi2025パンフレット記事の Phpactorから学ぶLanguage Server Protocolの仕組みに纏めた。

GPG KeyのYubiKey運用をはじめた

Sun, 11 May 2025 00:00:00 +0000

背景・動機

2025年5月の自分の手元の環境はGPGに重度に依存している。

GPG Keyの運用についてかねてから悩んでいたが、YubiKey運用が一番よいという結論に至った。ちょうどMacを初期化するタイミングがあったので完全に移行した。

次の記事を参考にした。

試したこと・やったこと

0. 運用方針を決める

GPG 鍵と YubiKey の運用メモ - Zenn と同様、次の方針で運用してくことにした。

YubiKey には主鍵と副鍵（Encrypt）を焼き、持ち歩く
YubiKey の主鍵を利用して副鍵（Sign, Auth）をデバイス毎に作成・保存しておく
- コミット署名はデバイス毎の副鍵（Sign）を利用する
- SSH Keyはデバイス毎の副鍵（Auth） gpg --export-ssh-key 経由で端末ごとに生成する
  - keygrepを ~/.gnupg/sshcontrol に入れる
暗号化・復号機能は YubiKey の副鍵（Encrypt）を利用する

元記事に加えてSSH KeyもGPG経由で生成することにした。 Terraform GitHub Providerを導入したでIaCの土壌が用意されているので、端末が増えるごとに毎回追加する運用にしていく。

GPGの仕組みについてはChatGPTにひたすら質問して不安な部分を潰した。

1. YubiKeyを購入する

Amazonで Yubico セキュリティキー YubiKey 5C NFC USB-C/FIDO2/WebAuthn/U2F/2段階認証/高耐久性/耐衝撃性/防水を購入した。

GitHub ActionsでCachixを導入する

Sat, 10 May 2025 00:00:00 +0000

背景・動機

NixにハマってからGitHub Actions上でNixを実行する機会が増えた。 Nixというツールの性質上、どうしても実行環境の準備に時間がかかってしまうのでキャッシュ機能を導入したいと以前から思っていた。

Cachixが一番メジャーなサービスであり、個人利用程度なら無料で使えるので今回はじめて利用してみた。

試したこと・やったこと

1. Cachixの設定をする

アカウントを新規作成して、New Cacheで作成した。

https://app.cachix.org/

「Settings > Cache Auth Tokens」でアクセストークンを作成して,GitHub Actions Secretに CACHIX_AUTH_TOKEN に登録した。

2. GitHub Actionsで設定する

reusable actionで次のように定義した。 reusable actionからは secrets.XX を参照できないので引数で渡す必要がある。

name: Run setup-nix
description: Set up Nix environment for GitHub Actions

inputs:
 cachix-auth-token:
 required: true

runs:
 using: composite
 steps:
 - uses: cachix/install-nix-action@v31
 - uses: cachix/cachix-action@v14
 with:
 name: takeokunn-blog
 authToken: '${{ inputs.cachix-auth-token }}'

次のように呼び出すとよしなにCache HitしたらCachixからCopyしてくれるようになった。

steps:
 - name: Setup nix
 uses: ./.github/actions/setup-nix
 with:
 cachix-auth-token: ${{ secrets.CACHIX_AUTH_TOKEN }}

あとはよしなにnixを実行する。

# nix buildの場合
- name: Build zenn
 run: nix build .#build-zenn

# nix developの場合
- name: flake check
 run: nix develop --command bash -c "textlint 'org/**/*.org'"

得られた結果・所感

takeokunn/blog の場合、平均して1分でNix実行環境を用意できるようになり大幅なCI速度改善を実現できた。

markdown-preview-modeとxwidgetsでリアルタイムプレビューする

Sat, 10 May 2025 00:00:00 +0000

背景・動機

最近AIが生成したMarkdownを読む機会が増えた。 Emacs Buffer上で読むのもよいのだが、ブラウザ上でCSSを当てた方が読みやすいので今回対応した。

試したこと・やったこと

1. markdown-preview-modeを用意する

ancane/markdown-preview-mode をインストールする
- Melpa経由で入る
Markdownをコンパイルする為に pandoc を用意する

2. markdown-preview-modeの設定をする

solarized-lightのテーマを選んだ。

(setq markdown-preview-stylesheets (list "http://thomasf.github.io/solarized-css/solarized-light.min.css"))

既存のテーマで画像を表示すると表示ずれ発生するのでスタイルを上書きした。

(defun my/markdown-preview-css-filter (orig-return)
 (concat orig-return "<style>img { max-width: 100%; }</style>"))

(advice-add 'markdown-preview--css :filter-return #'my/markdown-preview-css-filter)

previewを起動する時にxwidget経由で開くようにした。

(defun my/markdown-preview--start-with-xwidget (orig-fun &rest args)
 (let ((browse-url-browser-function #'xwidget-webkit-browse-url))
 (apply orig-fun args)))

(advice-add 'markdown-preview--start :around #'my/markdown-preview--start-with-xwidget)

得られた結果・所感

他エディタに遜色ないくらい体験が良くなった。 WebSocket Serverも立ててくれるのでリアルタイムプレビューも可能になった。

今後の展開・検討事項

org-modeの場合は org-preview-html で実現できるのでxwidget対応をする。

org-roam-ui-liteでblogの関係性を可視化する

Sat, 10 May 2025 00:00:00 +0000

背景・動機

org-roamで記事を管理しGitHub Actionsで適切に公開するに書いたとおり takeokunn.org は org-roam で管理している。

org-roamの可視化ツールに org-roam-ui があるが、次のような問題を抱えていた。

Next.jsでリッチに作られすぎてる
- NixでPackagingするのが大変
GitHub ActionsでBuildするのが大変
GitHub PagesでHostingするのが大変

GitHub Pagesに継続的にHostingする仕組みを作りたいと考えて早n年経っていたが、taniさんが org-roam-ui-lite という軽量なorg-roam-uiを作ってくれたので今回導入してみた。

試したこと・やったこと

変更はここに纏まっている。

https://github.com/takeokunn/blog/commit/5703949e2212fa0e5f23d23869d61ea2b74b8dad

1. flake.nixでBuildできるようにする

scripts/org-roam-ui.el を用意した。

(require 'org-roam)

(setq org-roam-db-location "./org-roam.db")
(setq org-id-locations-file "./.org-id-locations")
(setq org-roam-directory default-directory)

flake.nixでorg-roam-ui-liteをimportして stdenv.mkDerivation でpackageを作成した。

diff --git a/hugo/flake.nix b/hugo/flake.nix
index c35c860..155c924 100644
--- a/hugo/flake.nix
+++ b/hugo/flake.nix
@@ -3,9 +3,10 @@
 nixpkgs.url = "github:NixOS/nixpkgs";
 nur-packages.url = "github:takeokunn/nur-packages";
 flake-utils.url = "github:numtide/flake-utils";
+ org-roam-ui-lite.url = "github:tani/org-roam-ui-lite";
 };

- outputs = { self, nixpkgs, nur-packages, flake-utils }:
+ outputs = { self, nixpkgs, nur-packages, flake-utils, org-roam-ui-lite }:
 flake-utils.lib.eachDefaultSystem (
 system:
 let
@@ -85,6 +86,22 @@
 cp -r ./public $out/
 '';
 };
+ build-org-roam-ui-lite = pkgs.stdenv.mkDerivation {
+ name = "build-org-roam-ui-lite";
+ src = ./.;
+ nativeBuildInputs = with pkgs; [
+ org-roam-ui-lite.packages.${system}.export
+ (emacsPkg.pkgs.withPackages (epkgs: (with epkgs.melpaPackages; [ org-roam ])))
+ ];
+ buildPhase = ''
+ rm -fr org/private/
+ emacs --batch --load scripts/org-roam-ui.el --funcall org-roam-db-sync
+ org-roam-ui-lite-export -d org-roam.db -o ./public
+ '';
+ installPhase = ''
+ cp -r ./public $out/
+ '';
+ };
 };
 }
 );

nix build でbuildできることを確認する。

private-terraformをHCP Terraformに移行した

Wed, 07 May 2025 00:00:00 +0000

背景・動機

個人用のTerraformプロジェクトを用意して、GitHubとCloudflareとNextDNSの管理をしている。

tfstateのファイルをLocalマシンで雑に管理をしていたのだが、PCの引越し作業が発生したので管理方法を検討する必要があったので対応したことを纏めておく。

試したこと・やったこと

1. tfstate管理方法を検討

MUST
- 料金が無料
- セキュリティリスクが低い
- 安全なterraform実行環境の保証
SHOULD
- バージョン管理
- 実行結果の可視性
OPTIONAL
- CI統合

HCP Terraform（旧terraform cloud）はHashiCorp謹製のCloudサービス。 https://www.hashicorp.com/ja/cloud

500 resourcesまでは無料なので個人利用なら無料で完結する。 https://www.hashicorp.com/en/pricing

候補としてはさくらインターネットやCloudflareのストレージに上げることも検討していたが、そもそも各サービスを利用しなくなることも考えられるので却下した。

2. HCP Terraform自体のTerraformを書く

以下を参考にterraformを書いた。 https://registry.terraform.io/providers/hashicorp/tfe/latest/docs

TF_API_TOKEN は管理画面から手ぽちで入力している。

terraform {
 required_version = "1.11.4"

 cloud {
 organization = "takeokunn-private"
 workspaces {
 name = "tfe"
 }
 }

 required_providers {
 tfe = {
 source = "hashicorp/tfe"
 version = "0.65.2"
 }
 }
}

variable "TF_API_TOKEN" {
 type = string
}

provider "tfe" {
 token = var.TF_API_TOKEN
}

resource "tfe_organization" "private" {
 name = "takeokunn-private"
 email = "bararararatty@gmail.com"
 collaborator_auth_policy = "two_factor_mandatory"
}

resource "tfe_project" "default" {
 organization = tfe_organization.private.name
 name = "private"
}

resource "tfe_workspace" "tfe" {
 name = "tfe"
 organization = tfe_organization.private.name
 project_id = tfe_project.default.id
}

resource "tfe_workspace" "nextdns" {
 name = "nextdns"
 organization = tfe_organization.private.name
 project_id = tfe_project.default.id
}

resource "tfe_workspace" "cloudflare" {
 name = "cloudflare"
 organization = tfe_organization.private.name
 project_id = tfe_project.default.id
}

resource "tfe_workspace" "github" {
 name = "github"
 organization = tfe_organization.private.name
 project_id = tfe_project.default.id
}

3. ディレクトリ構成変更

元々はentrypoint1つですべてを流せるようにしていたが、次のようにサービスごとに分け、 cd で移動してからterraformを実行する運用に変更した。この対応によって他サービスの変更に依存せずにversionを上げられるようになった。

Typstテーマを自作した

Tue, 06 May 2025 00:00:00 +0000

背景・動機

NixでTypstをBuildしGitHub PagesでホスティングするでTypstから生成したPDFスライドを配信する仕組みを作った。今後の登壇は可能な限りTypstから生成するつもりなのでテーマを自作した。

次の要件を満たす必要があった。

ライトテーマ/ダークテーマなどテーマを簡単に切り替えられるようにする
ソースコードのシンタックスハイライトサポート
数式サポート

個人的にDracula Themeが好きなのでDracula Theme風に作る。

試したこと・やったこと

1. theme自作

polylux をベースに自作した。basic-polylux あたりを参考に改造した。

シンタックスハイライトは codelst に Dracula.tmTheme を読ませてハイライトしている。

#import "@preview/codelst:2.0.2": sourcecode
#import "@preview/polylux:0.4.0": *

#let blue = rgb("#282a36")
#let white = rgb("#f8f8f2")
#let pink = rgb("#ff79c6")
#let purple = rgb("#bd93f9")
#let orange = rgb("#ffb86c")
#let green = rgb("#50fa7b")
#let gray = rgb("#6272a4")

#let slide-title-header = toolbox.next-heading(h => {
 show: toolbox.full-width-block.with(fill: blue, inset: 1em)
 set text(fill: purple, size: 1.2em)
 strong(h)
})

#let the-footer(content) = {
 set text(size: 0.8em)
 show: pad.with(.5em)
 set align(bottom)
 context text(fill: white.lighten(40%), content)
 h(1fr)
}

#let outline = toolbox.all-sections((sections, _current) => {
 enum(tight: false, ..sections)
})

#let progress-bar = toolbox.progress-ratio(ratio => {
 set grid.cell(inset: (y: .03em))
 grid(
 columns: (ratio * 100%, 1fr),
 grid.cell(fill: pink)[],
 grid.cell(fill: purple)[],
 )
})

#let new-section(name) = slide({
 set page(header: none, footer: none)
 show: pad.with(20%)
 set text(size: 1.5em)
 name
 toolbox.register-section(name)
 progress-bar
})

#let focus(body) = context {
 set page(header: none, footer: none, fill: blue, margin: 2em)
 set text(fill: orange, size: 1.5em)
 set align(center)
 body
}

#let divider = line(length: 100%, stroke: .1em + pink)

#let setup(
 footer: none,
 text-font: "Migu",
 math-font: "Fira Math",
 code-font: "Fira Code",
 text-size: 23pt,
 body,
) = {
 set raw(theme: "./Dracula.tmTheme")

 set page(
 paper: "presentation-16-9",
 fill: blue,
 margin: (rest: 4em),
 footer: the-footer(footer),
 header: slide-title-header,
 )
 set text(
 font: text-font,
 size: text-size,
 fill: white,
 )
 set strong(delta: 100)
 show math.equation: set text(font: math-font)
 show raw: set text(font: code-font)
 set align(horizon)
 show emph: it => text(fill: pink, it.body)
 show heading.where(level: 1): _ => none

 body
}

2. flake.nixでBuildする

以下抜粋。 https://github.com/takeokunn/blog/blob/d7501711936b11d3f53c312c2775e20faab35602/typst/flake.nix

nixpkgsのunstableでEmacs Nativecomp Buildができない問題とワークアラウンド

Thu, 17 Apr 2025 00:00:00 +0000

Introduction

2025年4月16日現在、 aarch64-darwin 環境でnixpkgs unstableのemacs（nativecomp）をビルドできない問題が発生している。

ワークアラウンド方法

packageに withNativeCompilation = false; を書く。

https://github.com/NixOS/nixpkgs/blob/e51f02babf0ecf7d66e081917e609ae2c3d43ef2/pkgs/applications/editors/emacs/make-emacs.nix#L69

home-managerをoverlayする場合:

{ emacs-overlay }:
[
 (import emacs-overlay)

 # bug: https://github.com/NixOS/nixpkgs/issues/395169
 (final: prev: {
 emacs = prev.emacs.override {
 withNativeCompilation = false;
 };
 emacs-unstable = prev.emacs-unstable.override {
 withNativeCompilation = false;
 };
 emacs-git = prev.emacs-git.override {
 withNativeCompilation = false;
 };
 })
]

pkgsをoverrideする場合:

{ pkgs }:
pkgs.emacs.override {
 withNativeCompilation = false;
}

原因

「emacs: fails to launch on macOS Sequoia 15.4 #395169」に纏まってる。 https://github.com/NixOS/nixpkgs/issues/395169

credential管理をorg-encryptからpassword-storeに移行した

Mon, 14 Apr 2025 00:00:00 +0000

Introduction

credential管理をorg-encryptからpassword-storeに移行したので作業内容をメモしておく。

現状の運用と問題

org-crypt運用メモに書いたとおり、 ~/.aws/credentials のような秘匿情報を secret.org を org-babel-tangle して出力していた。

次のように org-decrypt-entries と org-encrypt-entries をadviceして対応していたのだが、org-nix-shell がうまく動かなくなってしまった。

(advice-add 'org-babel-tangle :before #'org-decrypt-entries)
(advice-add 'org-babel-tangle :after #'org-encrypt-entries)

ob-async を有効にした時もorg-nix-shellが実行できなくなってしまったので、 advice-add をすると問題が起きるのかもしれない。（要検証） org-nix-shell入門にも書いたが、org-nix-shellはキラーアプリケーションなので消す訳にはいかない。

M-x org-encrypt-entries を手動で実行する運用にしていたが、うっかり叩き忘れたままcommitを何度かしてしまった。

newren/git-filter-repoなどを使ってcommit hisotryから消したが面倒だった。

また、mcp-servers-nixを導入した時点では実装されてなかったが、mcp-servers-nix は passwordCommand をサポートしてくれた。よい機会なのでpassword-store管理に移行にすることにした。

作業手順

1. 既存のorg-encryptしてた鍵情報をpassword-store管理下に移行

次のように秘密鍵をpassコマンドで検索できるようにする。

pass show gemini/private

2. org-babel templateを作成

passコマンドをwrapするコマンドを用意する。

#+name: pass
#+begin_src emacs-lisp :var id="" :results value raw
 (string-trim (shell-command-to-string (format "pass show %s" id)))
#+end_src

3. 各秘密鍵に埋め込み

:noweb yes で関数を実行できるようにする。 M-x org-babel-tangle を実行すると、秘密鍵の入った状態で ~/.aider.conf.yml が出力される。

emacsでuniversal-ctagsを使う

Wed, 09 Apr 2025 00:00:00 +0000

Introduction

universal-ctags/ctags の検証をしたのでメモしておく。

概要

Wikipedia的には以下。 https://ja.wikipedia.org/wiki/Ctags

Ctags（英: Ctags）はソース及びヘッダ内にある名前のインデックス（又はタグ）ファイルを生成するプログラム。様々なプログラミング言語に対応している。言語に依存するが、サブルーチン(関数)、変数、クラスのメンバ、マクロ等がインデックス化される。これらのタグによりテキストエディタなどのツールで高速かつ容易に定義を参照できる。相互参照ファイルを出力でき、また名前についての情報を人が読みやすい形で列挙した言語ファイルを生成することもできる。

Ctagsはケン・アーノルドがBSD Unix用に開発した。後にJim KlecknerによりFortranがサポートされ、ビル・ジョイによりPascalがサポートされた。

universal-ctagsは「A maintained ctags implementation」と自称しているとおり、2025年4月現在も活発にメンテナンスされている。 https://github.com/universal-ctags/ctags

universal-ctags使い方

Nix経由なら簡単に実行できる。 https://search.nixos.org/packages?channel=24.11&show=universal-ctags&from=0&size=50&sort=relevance&type=packages&query=universal-ctags

$ nix run nixpkgs#universal-ctags -- --version

Universal Ctags 6.1.0, Copyright (C) 2015-2023 Universal Ctags Team
Universal Ctags is derived from Exuberant Ctags.
Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert
 URL: https://ctags.io/
 Output version: 0.0
 Optional compiled features: +wildcards, +regex, +gnulib_fnmatch, +gnulib_regex, +iconv, +option-directory, +xpath, +json, +interactive, +yaml, +case-insensitive-filenames, +packcc, +optscript, +pcre2

PHPプロジェクトである bobthecow/psysh を例に TAGS を生成する。

mcp-servers-nixを導入した

Wed, 09 Apr 2025 00:00:00 +0000

Introduction

natsukium謹製の natsukium/mcp-servers-nix を takeokunn/nixos-configuration に導入したのでメモしておく。

変更点

Before

Orgファイルから org-babel-tangle で ~/Library/Application\ Support/Claude/claude_desktop_config.json を出力
必要なpackageは node2nix 経由で入れる
秘密鍵はOrgファイルで org-encrypt して管理
- ref. org-crypt運用メモ

After

natsukium/mcp-servers-nix からMCPに必要なものをjsonを出力
必要なpackageは大体 natsukium/mcp-servers-nix に同梱されてる
- 足りないものは node2nix 経由で入れる
秘密鍵は sops-nix で管理

作業内容

MCPサーバーの設定をセキュアでGit friendlyにする - Zenn を事前に読む。

1. sops-nixに登録

sops/password.yml に以下を登録する。

brave-api-token: BRAVE_API_KEY=xxxx

sops/default.nix で読み込めるようにする。

{
 sops = {
 defaultSopsFile = ./password.yaml;
 secrets = {
 brave-api-token = { };
 };
 };
}

2. mcp-serversを記述する

envFile = config.sops.secrets.brave-api-token.path; のように環境変数を渡す。

{
 pkgs,
 config,
 mcp-servers-nix,
 nodePkgs,
}:
let
 programs = {
 fetch.enable = true;
 playwright.enable = true;
 brave-search = {
 enable = true;
 envFile = config.sops.secrets.brave-api-token.path;
 };
 };
in
[
 {
 home.file."Library/Application\ Support/Claude/claude_desktop_config.json" = {
 source = mcp-servers-nix.lib.mkConfig pkgs {
 inherit programs;
 };
 };
 }
]

3. home-managerに組込み

home-manager/advanced.nix で imports で登録すればよい。

BitwardenとAuthyのアカウントを削除した

Tue, 08 Apr 2025 00:00:00 +0000

Introduction

Bitwardenからpassword-storeに移行したでBitwardenから離れて1年以上経った。当初はBitwardenにしかない情報もあったのでを開くこともあったが、今になっては使うことがなくなったのでアカウントを完全に削除する。

また、Authyからpassword-store-otpに移行したでAuthyも使わなくなったのでついでに削除する。

作業手順

1. Bitwarden

公式ドキュメントを参考に削除する。

https://bitwarden.com/ja-jp/help/delete-your-account/

「個人のアカウントを削除します > アカウントを削除」で特に警告も出ずにサクっと消えた。

2. Authy

公式の削除動線を辿って確認メールを踏んで削除する。

https://www.authy.com/account/delete/

終わりに

BitwardenもAuthyも駆け出しエンジニアの頃から使ってたので思い入れのあるツールだった。 10年間ありがとう。

Denoで簡易的なCLIツールを作る

Thu, 03 Apr 2025 00:00:00 +0000

Introduction

DenoでCLIツールを試験的に作ったのでメモしておく。

方針

cliffy で作成
cat と grep をSub Commandで簡易的に作成

ディレクトリ構造

$ nix run nixpkgs#tree .
.
├── deno.json
├── deno.lock
└── src
 ├── commands
 │   ├── cat.ts
 │   └── grep.ts
 ├── deps.ts
 └── main.ts

3 directories, 6 files

作業手順

1. 依存関係をインストール

$ deno install で入れて使い易いように src/deps.ts を用意する

deno.json:

{
 "imports": {
 "@cliffy/command": "jsr:@cliffy/command@^1.0.0-rc.7"
 }
}

src/deps.ts:

export { Command } from '@cliffy/command';

2. Command作成

import { Command } from './deps.ts';
import { catCommand } from './commands/cat.ts';
import { grepCommand } from './commands/grep.ts';

await new Command()
 .name('mycli')
 .version('0.1.0')
 .description('My CLI tool')
 .command('cat', catCommand)
 .command('grep', grepCommand)
 .parse(Deno.args);

3. Sub Command

3.1 cat

import { Command } from '../deps.ts';

const displayFiles = async (files: string[]): Promise<void> => {
 for (const file of files) {
 try {
 const content = await Deno.readTextFile(file);
 console.log(`--- ${file} ---`);
 console.log(content);
 } catch (err) {
 if (err instanceof Error) {
 console.error(`Error reading ${file}: ${err.message}`);
 } else {
 console.error(`Unknown error:`, err);
 }
 }
 }
};

export const catCommand = new Command()
 .name('cat')
 .description('Display content of files')
 .arguments('<files...>')
 .action(async (_, ...files: string[]) => await displayFiles(files));

3.2 grep

import { Command } from '../deps.ts';

const grepFiles = async (pattern: string, files: string[]): Promise<void> => {
 const regex = new RegExp(pattern, 'g');

 for (const file of files) {
 try {
 const content = await Deno.readTextFile(file);
 const lines = content.split('\n');
 let matchFound = false;

 for (let i = 0; i < lines.length; i++) {
 if (regex.test(lines[i])) {
 if (!matchFound) {
 console.log(`\n--- ${file} ---`);
 matchFound = true;
 }
 console.log(`${i + 1}: ${lines[i]}`);
 regex.lastIndex = 0; // Reset regex for next test
 }
 }
 } catch (err) {
 if (err instanceof Error) {
 console.error(`Error reading ${file}: ${err.message}`);
 } else {
 console.error(`Unknown error:`, err);
 }
 }
 }
};

export const grepCommand = new Command()
 .name('grep')
 .description('Search for pattern in files')
 .arguments('<pattern> <files...>')
 .action(async (_, pattern: string, ...files: string[]) =>
 await grepFiles(pattern, files)
 );

4. Command実行

4.1 cat

$ deno run --allow-read src/main.ts cat deno.json src/deps.ts
--- deno.json ---
{
 "imports": {
 "@cliffy/command": "jsr:@cliffy/command@^1.0.0-rc.7"
 }
}

--- src/deps.ts ---
export { Command } from '@cliffy/command';

4.2 grep

$ deno run --allow-read src/main.ts grep "command" deno.json src/main.ts

--- deno.json ---
3: "@cliffy/command": "jsr:@cliffy/command@^1.0.0-rc.7"

--- src/main.ts ---
2: import { catCommand } from './commands/cat.ts';
3: import { grepCommand } from './commands/grep.ts';
9: .command('cat', catCommand)
10: .command('grep', grepCommand)

終わりに

TypeScriptで記述できるのはnpmの資産が使えて便利だし、cliffyも使い勝手が非常によい。

flake.nixでポータブルな最小構成のEmacsを作成する

Thu, 03 Apr 2025 00:00:00 +0000

Introduction

「任意のEmacs Packageが動かない」がおま環かバグかというのを切り分けることは非常に重要。誰でも同じ環境を整えられるようにすると問題解決が捗るので構築方法をメモしておく。

作業手順

1. init.el作成

今回のサンプルはrainbow-delimitersが動作するか確認するものにする。

(use-package rainbow-delimiters
 :ensure t
 :hook
 (prog-mode-hook . rainbow-delimiters-mode))

2. flake.nix作成

alwaysEnsure = true; にすると init.el 内の :ensure t を読んでNix Build時によしなにインストールしてくれる。

また、emacs-overlay を使うと unstable/stable/head など複数バージョンで実行できるので検証の幅を簡単に広げられる。 https://github.com/nix-community/emacs-overlay/blob/master/overlays/emacs.nix

{
 inputs = {
 nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
 emacs-overlay = {
 url = "github:nix-community/emacs-overlay";
 inputs.nixpkgs.follows = "nixpkgs";
 };
 };

 outputs = { self, nixpkgs, emacs-overlay }:
 let
 system = "aarch64-darwin";
 pkgs = import nixpkgs {
 inherit system;
 overlays = [ emacs-overlay.overlay ];
 };
 emacs = pkgs.emacsWithPackagesFromUsePackage {
 config = ./init.el;
 package = pkgs.emacs-unstable;
 alwaysEnsure = true;
 };
 in
 {
 packages.${system}.default = emacs;
 };
}

3. Nix Buildして実行

Localに一切依存しない形でEmacsをBuildできる。

お名前comからCloudflareにドメイン移管してTerraformで管理する

Thu, 03 Apr 2025 00:00:00 +0000

Introduction

お名前comで管理していた takeokunn.org をCloudflareに移管したのでメモしておく。

Background

お名前comには世の中のエンジニアと同じように、長年次の不満を抱えていた。

管理画面がとにかく使いづらい
広告・営業メールが多い
自動更新やオプションの設定が本当に分かりづらい
IaCに対応していない

vim-jpで令和時代にドメインを管理するならCloudflare一択という意見をもらったので移管した。

作業手順

ドメインの移管はじめてだったこと、個人ドメインであることからダウンタイムが発生許容した。 2と3を入れ替えればダウンタイムが発生しなかったかもしれない。

1. Cloudflareにアカウントを作成する

公式サイトから新規登録をしてクレジットカードを登録する。

https://www.cloudflare.com/ja-jp/

2. お名前comからCloudflareに移管する

お名前.com から Cloudflare Registrar にドメイン移管した話 - Zenn を参考に移管した。

「トランスファー申請の承認」が15分以上かかったがいずれ来るので気長に待てばよい。

3. Terraformで管理する

Terraform Cloudflare Providerを使う。

https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs

3.1 provider作成

sops にAPI Tokenを保存して terraform-provider-sops 経由で入れる。

terraform {
 required_providers {
 sops = {
 source = "carlpett/sops"
 version = "~> 0.5"
 }
 cloudflare = {
 source = "cloudflare/cloudflare"
 version = "~> 5"
 }
 }
}

provider "sops" {}

data "sops_file" "secret" {
 source_file = "./secrets.yaml"
}

provider "cloudflare" {
 api_token = data.sops_file.secret.data.cloudflare
}

3.2 レコード作成

locals {
 # for takeokunn.org
 takeokunn_org_zone_id = "xxx"
}

resource "cloudflare_dns_record" "a_records" {
 provider = cloudflare
 for_each = toset([
 "185.199.108.153",
 "185.199.109.153",
 "185.199.110.153",
 "185.199.111.153"
 ])
 zone_id = local.takeokunn_org_zone_id
 name = "takeokunn.org"
 content = each.key
 type = "A"
 ttl = 1
 proxied = false
}

resource "cloudflare_dns_record" "cname_emacs" {
 zone_id = local.takeokunn_org_zone_id
 name = "emacs.takeokunn.org"
 content = "takeokunn.github.io"
 type = "CNAME"
 ttl = 1
 proxied = false
}

4. 管理画面から確認する

正常に terraform apply されていることを確認する。

NextDNSを導入した

Wed, 02 Apr 2025 00:00:00 +0000

Introduction

かねてから興味があった NextDNS が Terraform Provider と nix-darwin/nixos で設定できることを知り、せっかくなので導入してみた。

What is NextDNS?

流行のDeep Reasearchの結果は以下Gist。

https://gist.github.com/takeokunn/aa9bc9ef2c7d670b71bfd962c8a1a80e

日本人でも使っている人がちらほらいる。

作業手順

1. アカウント作成してAPI Key発行

公式サイトからメールアドレスとパスワードで登録する。 https://nextdns.io/

管理画面からMFAを設定してAPI keyを発行する。 https://my.nextdns.io/account

2. Terraform設定

ドキュメントを参考に画面上で設定できるものを宣言的に設定する。 https://registry.terraform.io/providers/carbans/nextdns/latest/docs

2.1 providerを設定

sops にAPI Tokenを保存して terraform-provider-sops 経由で入れる。

terraform {
 required_providers {
 sops = {
 source = "carlpett/sops"
 version = "~> 0.5"
 }
 nextdns = {
 source = "carbans/nextdns"
 version = "~> 0.2"
 }
 }
}

provider "sops" {}

data "sops_file" "secret" {
 source_file = "./secrets.yaml"
}

provider "nextdns" {
 api_key = data.sops_file.secret.data.nextdns
}

2.2 各種設定

とりあえず有効にできるものは有効にした。

Terraform GitHub Providerを導入した

Wed, 02 Apr 2025 00:00:00 +0000

Introduction

個人の運用でTerraform GitHub Providerを導入したのでメモしておく。

Motiviation

長年ソフトウェアエンジニアをやってたらリポジトリが増えていく。特に最近のLLMの流行で検証用に作るリポジトリが顕著に増えている。「Automatically delete head branchesは必ず有効にする」など、統一的な環境を宣言的にしたいという欲求があった。

また、SSH keysの設定など個人の設定も可能な限り宣言的に記述したい。

作業手順

こちらのproviderを使って導入する。 https://registry.terraform.io/providers/integrations/github/latest

0. Access Tokenを用意する

「Personal access tokens > Fine-grained personal access tokens」で必要に応じて権限を付与してTokenを発行する。

1. provider定義

sops にGitHub API Tokenを保存して terraform-provider-sops 経由で入れる。

terraform {
 required_providers {
 sops = {
 source = "carlpett/sops"
 version = "~> 0.5"
 }
 github = {
 source = "integrations/github"
 version = "~> 6.0"
 }
 }
}

provider "sops" {}

data "sops_file" "secret" {
 source_file = "./secrets.yaml"
}

provider "github" {
 token = data.sops_file.secret.data.github
}

2. ssh key定義

github_user_ssh_key で定義できる。

@github/copilot-language-serverをNixで扱う時のメモ

Thu, 27 Feb 2025 00:00:00 +0000

Introduction

@github/copilot-language-server を takeokunn/nixos-configuration 上で扱えるようにしたのでメモしておく。

Background

copilot.el のバージョンが上がった
@github/copilot-language-server をnpmでインストールして使う必要があった
次の要件を満たしたい
- Nixでパッケージングしたい
- Neovimなどのエディタでも汎用的に使えるようにしたい

対応手順

1. node2nixでパッケージングする

node2nix/node-packages.json に次のような記述をした。

["@github/copilot-language-server"]

次のshell scriptを実行するとファイルが生成された。

node2nix/default.nix
node2nix/node-env.nix
node2nix/node-packages.nix

$ nix-shell -p nodePackages.node2nix --command "node2nix -i ./node-packages.json -o node-packages.nix"

2. 実行ファイルを取得する

node2nix/default.nix をimportするとpackageが読み込めるようになった。

nodePkgs = pkgs.callPackage ../node2nix { inherit pkgs; };

copilot-language-server は次のようなディレクトリ構造になっている。

$ dust native/

 65M ├─┬ native/darwin-x64
 65M │ └── native/darwin-x64/copilot-language-server
 60M ├─┬ native/darwin-arm64
 60M │ └── native/darwin-arm64/copilot-language-server
 59M ├─┬ native/linux-x64
 59M │ └── native/linux-x64/copilot-language-server
 50M └─┬ native/win32-x64
 50M └── native/win32-x64/copilot-language-server.exe

そこで、platformごとに対応表を作って COPILOT_LANGUAGE_SERVER_PATH にPATHを通してあげた。

2025年2月名古屋旅行

Mon, 24 Feb 2025 00:00:00 +0000

Introduction

2025/2/21から2025/2/24までの名古屋旅行についての振り返りです。

名古屋上陸ははじめてでしたが、非常に楽しい旅行になりました。思い出したらまた追記するかもしれません。

注意

このブログはあくまで個人的な旅行記であり、「たけてぃのことを知っている or 物好きな人」向けの記事です。帰りの高速バスの中で暇なので書いているくらいの温度感の記事なので真に受けないでください。

社会人として外面の良い活動はZennに後日纏めますので少々お待ちください。

スケジュール

スケジュールはざっくり以下です。今回の旅行も常に何かをしていたなという感覚があります。

開始日	開始時間	終了時間	項目
2/21(金)	23:00	07:00	夜行バス東京駅 → 名古屋駅
2/22(土)	9:30	19:00	phpcon名古屋
	19:00	21:00	懇親会
	21:00	23:30	2次会
	23:30	24:00	湯〜とぴあ宝移動
2/23(日)	10:00	11:30	名古屋駅にてモーニング
	11:30	13:00	喫茶マウンテン with tadsan, あかつかさん
	13:30	16:30	東山動物園
	17:00	19:00	ひつまぶし in 栄 with tadsan
	19:00	21:00	栄散策
	21:00	22:00	名古屋駅周辺散策 + 湯〜とぴあ宝移動
2/24(月)	9:30	11:30	名古屋駅にてモーニングと定食を食べる
	11:30	12:00	お土産買ってバス停に移動
	12:00	18:00	高速バス名古屋駅 → 東京駅

ドメイン用語

普段なにげなく使っているが、よくよく考えたら初見の人から見たら意味がわからない単語、それがドメイン用語なのです。

2025年2月 Neovimセットアップ

Tue, 11 Feb 2025 00:00:00 +0000

Introduction

Neovimに入門したいと思い早n年だったが、vim-jpの皆さんのおかげでようやくミニマムの設定が完了したのでブログにまとめておきます。

VimとNeovimの使い分けと最小構成のとおりVimは最小構成にしているので、Neovimはヘビーカスタマイズしていく方針です。

Neovimの設定はこちら。

https://github.com/takeokunn/nixos-configuration/tree/main/home-manager/programs/neovim

Setup

Neovim本体

Nix経由でインストールしています。

https://github.com/takeokunn/nixos-configuration/blob/main/home-manager/programs/neovim/default.nix

withNodeJs や withRuby などはイマドキ使わない設定まらしいので false にしました。

{ pkgs, sources }:
{
 programs.neovim = {
 enable = true;
 withNodeJs = false;
 withRuby = false;
 withPython3 = false;
 plugins = import ./plugins { inherit pkgs sources; };
 extraLuaConfig = builtins.readFile ./init.lua;
 };
}

Plugin Manager

VimのPlugin Managerは乱立しているようで、デファクトスタンダードはないらしいです。私はNixユーザーなのでNixで管理することにしました。

また、各Pluginごとの設定もNix内に記述する方針にしました。

# 実際の例
{ pkgs }:
with pkgs.vimPlugins;
[
 {
 type = "lua";
 plugin = dracula-nvim;
 config = ''
 vim.cmd[[colorscheme dracula]]
 '';
 }
]

Terminal Emulator

「Terminal Emulatorにこだわらない」というこだわりを持っていたが、Mac標準のTerminal.appだとうまく描画してくれない問題があった。

org-nix-shell入門

Sat, 08 Feb 2025 00:00:00 +0000

Introduction

org-nix-shellはOrg関連パッケージの中でもキラーアプリケーションと呼べるもので、個人的に今熱いパッケージのひとつです。簡単な使い方と実際のユースケースを紹介していきます。

インストール

Melpa経由で入れてもよいし、GitHub経由で直接インストールしてもよい。次のように設定するだけで機能してくれる。

(require 'org-nix-shell)

(with-eval-after-load 'org
 (add-hook 'org-mode-hook #'org-nix-shell-mode))

使い方

Basic

次のようにNixを定義して :nix-shell で読み込む。

#+name: tmp-shell
#+BEGIN_SRC nix :noweb yes
 { pkgs ? import <nixpkgs> { } }:
 pkgs.mkShell { buildInputs = with pkgs; [ php ]; }
 #+END_SRC

#+begin_src shell :nix-shell tmp-shell :results output
 php --version
#+end_src

また、次のURLから古いバージョンを取ってきて実行することも可能。 https://lazamar.co.uk/nix-versions

#+name: php74-shell
#+BEGIN_SRC nix :noweb yes
 let
 url =
 "https://github.com/NixOS/nixpkgs/archive/4426104c8c900fbe048c33a0e6f68a006235ac50.tar.gz";
 pkgs = import (builtins.fetchTarball { inherit url; }) {
 system = "<<wandbox-system>>";
 };
 in pkgs.mkShell { buildInputs = with pkgs; [ php74 ]; }
#+END_SRC

#+begin_src php :nix-shell php74-shell :exports both
 echo phpversion();
#+end_src

#+RESULTS:
: 7.4.4

property指定もできる。

Laravel LazyCollection in depth

Tue, 04 Feb 2025 00:00:00 +0000

Introduction

LaravelのLazyCollectionは巨大なデータを扱う時に便利であるという話は巷で良く聞くが、実際の所どういうときに便利なのか、内部的にはどうなっているのかという情報はあまり聞かない。 LazyCollection自体のソースコードを読んでかなり理解できたのでメモしておく。

なお、そもそもの使い方については LazyCollection備忘録 - Qiita を読んでいる前提で話を進める。

前提

次のバージョンを想定しています。

laravel: 10.0
php: 8.2

LazyCollectionのコードはこちら。

https://github.com/laravel/framework/blob/10.x/src/Illuminate/Collections/LazyCollection.php

LazyCollectionについて

Basic

LazyCollection#sourceについて

基本的には LazyCollection#source にClosureを入れてどう引き回すか、どのタイミングでClosureを発行するのかということを制御している。

/**
 * The source from which to generate items.
 *
 * @var (Closure(): \Generator<TKey, TValue, mixed, void>)|static|array<TKey, TValue>
 */
public $source;

LazyCollectionのコンストラクタの引数(or LazyCollection#make)には Array|null か Closure(Generator) を渡すことが可能で、 LazyCollection#source に代入する。

> \Illuminate\Support\LazyCollection::make(function () { for ($i = 1; $i <= 10000000; $i++) yield $i; })->source
= Closure() {#5542 <E2><80><A6>2}

> \Illuminate\Support\LazyCollection::make([1, 2 ,3])->source;
= [1, 2, 3]

> \Illuminate\Support\LazyCollection::make()->source
= []

// arrayにcastされる
> \Illuminate\Support\LazyCollection::make(1)->source
= [ 1 ]

基本的な関数

ここではmapを例に上げる。

Nixでdap-modeがエラーになった時のメモ

Mon, 03 Feb 2025 00:00:00 +0000

Introduction

2025/02/02（Sun）に nix flake update で最新にしてBuildしたらエラーで落ちるようになったのでメモ。

現象

2025/01/31に dapui.elがdap-ui.elにrename される
dap-mode 20250131.1624 に反映される
2025/02/02の nix flake update nixpkgsのdap-modeのpreBuild でdapui.elがなくて落ちるようになった

最小構成と解決策

次のように preBuild をoverlaysに追加すればBuildできるようになった。

{
 inputs = {
 nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
 emacs-overlay.url = "github:nix-community/emacs-overlay";
 };

 outputs = { self, nixpkgs, emacs-overlay, ... }:
 let
 system = "aarch64-darwin";
 pkgs = import nixpkgs {
 inherit system;
 overlays = [
 # ここを追加
 (self: super: {
 emacsPackages = super.emacsPackages // {
 dap-mode = super.emacsPackages.dap-mode.overrideAttrs (old: {
 preBuild = null;
 });
 };
 })
 emacs-overlay.overlay
 ];
 };
 in {
 defaultPackage.${system} = pkgs.emacsPackages.dap-mode;
 };
}

また、 emacs-overlay 使う場合は pkgs.emacsWithPackagesFromPackageRequires にoverlayを追加すればBuildできるようになる。 https://github.com/nix-community/Emacs-overlay/blob/a7f332f6e0813c9d0f53fe6539be1e7a65fff2e4/packreq.nix#L13

「Lispが安定してることがアピールポイントか」に対しての考察

Wed, 29 Jan 2025 00:00:00 +0000

背景

vim-jpラジオのEmacs回に出演しました - Zenn を書いたのだが、conao3から「n年前のコードを動かすためにはn年成長しなければよい、そこはアピールポイントにならないという気持ちではある」という指摘を受けた。その過程でvim-jpの #random チャンネルで議論になった。人によってかなり前提や置かれている状況が違うので、自分が想定していた条件や「Lispが安定している」についての理解と主張を文書という形でまとめておく。

免責事項

この記事は個人ブログに書いているので、あくまで個人の理解や見解をまとめている。その為、技術的に間違えていることが書かれている可能性があるので要注意。

platform	想定読者	目的
Zenn	不特定多数	対外的な宣伝目的
takeokunn.org	特定少数	個人的なメモ

また、特に断りがなければ以下を想像しながら書いている。本当はGoやRustも含めて書きたかったが経験が浅いので今回は除外する。

Lisp: Common Lisp
通常の言語: PHP, NodeJS

対象箇所

こまもかさんからのお便りから抜粋。

Q. Emacsといえば設定をEmacs Lispという専用のLispで行ったり、他のエディタよりLisp系言語のサポートが手厚い事が有名だと思います。かく言う僕もCommon Lispを書くためにEmacsを始めたのですが、皆さんの思うLispの魅力などについてお聞きしたいです。

A. Lispの魅力についての外観をつかみたいならハッカーと画家コンピュータ時代の創造者たちや Land of Lisp や A Road to Common Lisp を読むことをお勧めします。 Lispにもっと踏み込みたいなら On Lisp や LET OVER LAMBDA もお勧めです。

僕個人としての魅力は、Lisp自体の言語仕様が変わることはなく、Lispの言語仕様の上にmacroや関数を積み上げているので30年前のコードベースも余裕で動くことです。ソフトウェアを開発していると後方非互換の回し車に常に追われており、頻繁なバージョンアップを余儀なくされます。 phpプロジェクトは1年塩漬にされているとさまざまな依存関係のせいで動かないことが多々あります。

当初の自分の主張

プログラムを書くにはざっくり4種類の層がある。

言語自体の構文や処理系
処理系が提供している標準関数やpackage
外部packageやフレームワーク
ユーザーが書いているコード

主観の各言語ごとの変化の度合のマトリックスは以下。（×→変化なし、○→変化量が多い）一度書いたコードが未来の処理系でも過去の処理系でも動くかどうかということを想定している。「言語自体の構文や処理系」を変更するとすべてを変更する必要があるように、ステップが下にいくにつれて影響度合いが大きくなる。

	Lisp	NodeJS	PHP
言語自体の構文や処理系	×	△	△
処理系が提供している標準関数やpackage	△	△	△
外部packageやフレームワーク	△	◎	◎

実際のプロジェクトはほぼ次の2種類のパターンで構成されている。 Emacs Lispの場合はフレームワークまで含めてなのでBを指す。

org-crypt運用メモ

Mon, 27 Jan 2025 00:00:00 +0000

Introduction

org-crypt の使い方をイマイチに理解していなかったが、ふと調べてたら急に理解が進んだ。

個人的な運用が固まったのでメモしておく。

Motivation

~/.aws/credentials のような秘匿情報を secret.org.gpg から org-babel-tangle から出力していた。ファイルごとGPGで暗号化すると git diff がきれいに取れないので地味に困っていた。

org-crypt で必要な分を部分的に暗号化することによって、以前よりはGitフレンドリーにすることが可能になることが分かった。

`org-crypt` 使い方

org-crypt.el を読むのでもよいが、 Encrypting the content of Emacs Org files にわかりやすくまとまっている。

次のように設定した。

(with-eval-after-load 'org
 (setopt org-tags-exclude-from-inheritance '("crypt")))

(with-eval-after-load 'org-crypt
 (setopt org-crypt-key "0B10DAA7BA0236D7382287660F79C0AB03FD7A1C"))

:crypt: タグをつけて M-x org-encrypt-entries を実行すると次のようにGPGで暗号化される。タグはヘッダで C-c C-c を押すと入力できる。

M-x org-decrypt-entries でファイル内全体を復号することも可能。

:crypt: タグを変えたいなら org-crypt-tag-matcher を設定すればよい。

* before
** access token
#+begin_src text
P@ssw0rd
#+end_src
* after  :crypt:
-----BEGIN PGP MESSAGE-----

hQIMA6smtgkkGn+yAQ/+N67k5bFjZ+o/n3cRncdI7AXxZ4fcw7+vM9G/twKBkRqB
caleG2+FZy2u3ZHIE04ZnvKKPxZCDdm79Q6QxwBuuLsQiSn/jJ57QwNJySggQjwZ
aWQCzBFL5fBHgCR0eTZKX3Otr8Cpe2Eg1oH5SrUMEiRJ+uap+ZeVGs960icDy3AI
FRZ7z8BmaqFmA/ZRr3HO2nkFxJutzDnf7uCACa2JxpkJVDrhBOvGVrgHSqn/kzWu
+sriWo19z6O2mvVoWXOeg/3PNOP76ZCYFmqAa5zqoutBZ3GVEZ4M+uBcFJtQ6BHT
LgWLGNBEJeNjVWF1kGQYot4iArzrSbRzvNsEFzCiGyVYukgJSJuWWlC93aL4bJH+
c52Grie0DDacmiCADUVdUabvx16r82ptRylqV6um7mqdYGmPUErLhkp6zOwwhLgx
saAG4lY07DZeEdBtUfnYB39CRqxI/jVwSYoyTQC9PYUyo2y4E7Q2LjcoSyuJ8sPr
qgenSMn0gkF86ffm2ITmHDv5iQPgfhdzYIjtwrrDBpwCRkkoDfD68nS/zvekAe74
mO3fUOoM8jmMtQvCo9OMnVKkEXRXnzsyMI12KVIzMakljxnzvgDaELr5s6XTR/0F
FgAP19OQNbf24Ax3W+/m5GYxf5ltm+W4qDO0add5z2WLavOYGdknCCLFSN74/VLS
bwHums4w2RPZ00nnEX5zI+eN76UM42yZ53gDRjQgfVzfKdX4Rub/D19ZhL+bfqXR
iOJwPGz6yfeCDbz4RVvQgd/U8g5LkTrRu/itq9eZpCEjfH/HamC4meOrChI7xvJZ
nBkMYucqr7d5DPWEp4gYzQ==
=/Ual
-----END PGP MESSAGE-----

`org-babel-tangle` との連携

自分のユースケースだと org-babel-tangle と組み合わせて実行するのだが、 org-babel-tangle はencrypt/decryptとは関係のない処理ですので、実行前後でencrypt/decryptする必要がある。

個人的devenv運用

Mon, 27 Jan 2025 00:00:00 +0000

Introduction

devenvをヘビーユーズしているので、個人的なdevenv運用についてやTipsについてまとめる。

devenvとは

devenvはcachix社が作っているflake.nixラッパ。 https://devenv.sh/

flake.nixよりも圧倒的に高級に書ける割に柔軟性がかなり高いのでプロジェクトに必要なツールを入れる場合に便利。

類似ールにdevboxがありますが、devboxはjsonでのみ記述できるので個人的にはNixで書けるdevenvの方が好み。

devevnの個人的な期待役割

自分のローカル環境でNixが担っている役割は以下。自分の手元にはNixOSとMacとAndroidのマシンがありますが、環境ごとの役割の差異は特にないです。

システム設定
- e.g. network, font, daemon
システムグローバルのパッケージ管理
- e.g. fish, Git, Emacs
プロジェクト固有のパッケージ管理+α
- e.g. php, language-server, pre-commit
プロジェクト固有のビルドツール

1. システム設定 と 2. システムグローバルのパッケージ管理 は takeokunn/nixos-configuration が担っている。 4. ビルドツール は NixでTypstをBuildしGitHub Pagesでホスティングするのように flake.nix を定義して使っている。

3. プロジェクト固有のパッケージ管理+α をdevenvが担っており、 2. システムグローバルのパッケージ管理 は必要最小限に抑えているので都度インストールする必要がある。

自分は普通の人よりも幅広い言語やフレームワークのリポジトリを扱うので、逐次必要なツールを明示的に入れている。自分の為に用意しているので、プロジェクトには git push せず、自分用プライベートリポジトリで管理している。

また Emacsからもよい感じにpackageを実行できるようにする必要があるので工夫が必要。

実運用

Laravelプロジェク用devenvのサンプルコード

実際に会社のLaravelプロジェクトで使っているコードは以下。

language serverやawscliなどプロジェクで必要なものは都度入れている
言語のバージョンを大まかに定義する
- phpなら 8.2 という定義をして、 8.2.x レベルの細かい指定まではしない
php.iniはdevenv内で定義する
pre-commitをストレスのない範囲で可能な限り設定する
- ref. https://devenv.sh/reference/options/#pre-commit

{ pkgs, config, inputs, ... }: {
 cachix.enable = false;

 dotenv.disableHint = true;

 env.COMPOSER_MEMORY_LIMIT = "4G";

 packages = with pkgs; [ gh hub nodePackages_latest.intelephense ssm-session-manager-plugin tbls rain mariadb awscli ];

 languages.javascript = {
 enable = true;
 package = pkgs.nodejs_20;
 yarn.enable = true;
 };

 languages.php = {
 enable = true;
 package = pkgs.php82.buildEnv {
 extensions = { all, enabled }: with all; enabled ++ [ xdebug ];
 extraConfig = ''
 memory_limit=-1
 '';
 };
 };

 pre-commit.hooks = {
 actionlint.enable = true;
 editorconfig-checker.enable = true;
 check-json.enable = true;
 check-merge-conflicts.enable = true;
 check-yaml.enable = true;
 check-case-conflicts.enable = true;
 };
}

org-tangleして各プロジェクトに配置

emacs-mirror/emacs の場合は次のようなOrgファイルを定義して org-babel-tangle する。 devenv.lock は管理運用方法は現状思いついてないので諦めている。

NixでTypstをBuildしGitHub Pagesでホスティングする

Sun, 26 Jan 2025 00:00:00 +0000

背景

スライドや組版記事を生成する為にTypstを採用することにした。工数を最小限に安定的に量産できるようなしくみを整える必要が迫られていたので、今回対応したことをメモしておく。

ソースコードはtakeokunn/blogのtypstディレクトリ下に置いている。

条件

MUST
- Localに一切依存しない再現性の高いBuild環境構築
- org-modeで記述できる
- Typstのエコシステムを使う
- スライド生成と組版記事両方に対応する
SHOULD
- takeokunn.orgから配信できる
- リリースまでのリードタイムが短い
- org-roamなど周辺のエコシステムとの親和性を高める

方針

次の3ステップで実現した。

org-modeで記述したファイルをTypstに変換
NixでTypstをBuildできるようにする
GitHub ActionsでBuildしてGitHub Pagesで配信できる

作業ステップ

0. どこに置くか検討

以下を理由に takeokunn/blog 上に構築することにした。

takeokunn.org から配信できる
既存のorg-roam上に相乗りできる
新しいリポジトリを作ると関心ことが増える
すでにあるGitHub Actions上に構築することによって実装コストとメンテナンスコストを抑えられる
今回の用途だと作業途中でもパブリックにして問題がない

商業誌のような公開制限をかける必要のあるものは都度プライベートリポジトリを作って対応することにした。

1. org-modeで記述したファイルをTypstに変換

組版記事の場合、jmpunkt/ox-typst を用いて通常とおりOrgファイルをTypstに変換する。(M-x org-typst-export-to-typst を実行)

PHPerKaigi2025のパンフ記事の場合、次のようにTypstの設定をExportしている。

#+BEGIN_EXPORT typst
#set text(lang: "ja", font: "Migu", size: 8pt)

#set page(
 width: 210mm,
 height: 297mm,
 margin: 20mm,
 columns: 1
)

#import "@preview/codly:1.2.0": *
#import "@preview/codly-languages:0.1.1": *
#show: codly-init.with()
#codly(languages: codly-languages)

#align(center)[
 #set text(size: 18pt)
 Phpactorから学ぶLanguage Server Protocolの仕組み

 #set text(size: 12pt)
 たけてぃ \@takeokunn
]
#+END_EXPORT

スライドの場合、 Orgファイルには登壇メモをしつつ、 #+BEGIN_EXPORT typst のみ出力してほしかったので次のようなElispを書いた。

2024年全体振り返り

Sun, 05 Jan 2025 00:00:00 +0000

Introduction

2024年振り返りの振り返り記事です。立てた目標に対してどうだったか、2025年はどうするべきかを書いておきます。

年始に立てた目標

プログラミングのほぼすべての問題は「Aという問題に対してBというツールを使ってCをする」の連続だということに気がつきました。「日報を書く時はorg-modeのテンプレートを使って記述する」や「日本語を書く時はskkを使って入力する」など、それぞれの問題は細分化をするとほぼすべてこの形式になります。

プログラマーは得てしてAという問題を解決したいだけなのに、「BよりB’の方がよいのではないか」と検証をし始めていっこうにCできないものです。とはいえツールの選定は生産性に直結するので重要でありそこの塩梅が非常に難しいです。

そこで2024年は5年後も使えるであろうツールの選定を十分にすることにしました。自分が持っているすべての「Aという問題に対してBというツールを使ってCをする」をテンプレ化し、再利用性と再現性を高くするのを目標にしました。

いろいろな話を見聞きした結果、次の3つを頑張るのが良さそうだということで目標に据えました。

文芸的プログラミング（org-mode）
Nix
LLM/Local LLM

目標に対しての振り返り

目標	自己評価
文芸的プログラミング	○
Nix	◎
LLM/Local LLM	△

2024年はNix元年というくらい、Nixに大量に時間を投資したのは大成功でした。自分が持っているほぼすべての設定を takeokunn/nixos-configuration とprivate repoに移植しました。明示的にコードに落とすことによって、自分は今何をどういう設定でどういう用途で使っているのかを明確にできました。

文芸的プログラミングは去年書いた 2023年のorg-mode活用と今後の抱負から大きな進展はないですが、細やかな改善をたくさん行えた結果、ほぼテンプレ行動でやりたいことを実現できるようになりました。

LLM/Local LLMに関しては、どのくらいの将来性があるのか、やりこむとしたら何をやればよいのか、Local LLMなら何ができるのか等を自分の中で整理するというのが目標でした。一応自分の中では整理がついたのでそれは良かったのですが、Difyの活用やワークフローに落とし込む所までは間に合わなかったです。

コミュニティ活動

時期	イベント名	役割	登壇スライド	関連
1月	PHPカンファレンス北海道	参加者		PHPカンファレンス北海道2024に参加してきました
3月	phperkaigi 2024	パンフ記事執筆	テキストエディタがPHPをシンタックスハイライトする仕組みとモダンテキストエディタ事情について
4月	PHPカンファレンス小田原	登壇	Laravelに0からPHPStanを導入して継続的に運用する方法
6月	PHPカンファレンス福岡	登壇	Nixを用いて再現可能なPHP環境を用意する
8月	東京Emacs勉強会サマーフェスティバル2024	主催
10月	Nix meetup #1	主催、登壇	nix-shell+org-modeで文芸的プログラミング
11月	技術書展17	売り子		めだかのclojure.core学校 conao3
11月	VimConf 2024	個人スポンサー		VimConf2024 参加記
12月	ISUCON14	競技者		ISUCON14にチームOL001として参加しました(インフラ編)
12月	PHPカンファレンス東京	企業スポンサー

今年は毎月のように何かがあった1年でした。

VimConf2024 参加記

Sat, 23 Nov 2024 00:00:00 +0000

はじめに

2024-11-23 Satに行われたvimconf 2024に参加しました。

https://vimconf.org/2024/

登壇感想

英語の登壇であること、前日はしゃいで睡眠不足あったので聞き逃した所もあるが登壇メモを書いておく。

https://vimconf.org/2024/sessions/

Keynote - The new Vim project - What has changed after Bram by Christian Brabandt

一言

vim projectを引き継ぐにあたって大変なことについて。 vim本体のコードの引き継ぎも大変だけど、それ以外の引き継ぎも大変だったという話。

内容メモ

Bramが超人すぎて引き継ぎ量が多い
git repoの引き継ぎ
- 権限周りや新しいメンテナの招待
vim.org のホームページ引き継ぎ
- php5/7とか古いバージョン
- DBやらドメインやら
Emailアカウント周り
Google Groupを使ってる
- 正直イマイチなのでどうしたものか
セキュリティレポート
- Huntr
- GitHub security advisory
- private mailing list
ICCF
- まだ動いてるし、変えずにやっていく
- voting feature は廃止
開発進捗
- Development did not stop
- Vim9 classサポート
- XDGサポート/Editorconfigサポート/Waylandサポート
- BC Breakが起きないように十分にテストをする
コミュニティにとって何が重要か
- e.g. IDEっぽいことができた方が良いか、エディタのままでいいか
- e.g. Vim9は楽しいかどうか等
開発者に求めてること
- 安全なC関数を使う
- CIを通してカバレッジの確認をするなど
- 管理しやすいようにリファクタリングをする
何を改善すべきか
- GUI(GTK4)などのサポートを向上させるかどうか
- Tree-sitterサポートするかどうか
結論
- Vimメンテナンスは大変
- コミュニティを健全性を維持したい
質疑応答
- NeovimとVimは相互に協力して開発を進めていきたい
- Vimにコントリビューションを始める方法を教えてほしい
  - ドキュメントなど全ての貢献に感謝してる
  - Vim scriptのC言語を読めば良い
- 貴方が独裁者になってない?
  - 自分が休暇中は他の人がmerge作業をしてる
  - コミュニティの意向を尊重してmergeしてる
- 言語の壁でも越えるのが大変だけどどうしてる?
  - 英語でコミュニケーションしかできない
  - メンテナは各国にいるので英語がコミュニケーションの言語になってる
- 初心者に対してどういうことを期待してる?
  - まず日本のコミュニティに繋がることから始めると良い
  - 他の人から学ぶ、バグレポートから始めたり、ソースコードをチェックしてどう変更されたのか確認する、テストをする
  - ソースコードに馴染んできた時にパッチを送ると良い

Keynote - (Neo)Vim Made Me a Better Software Developer by TJ DeVries

一言

Neovimの話というよりは仕事のやり方に通じるものだった。 youtuberっぽい警戒なトークで面白すぎた。

tcardgenをnixでパッケージ化する方法

Fri, 22 Nov 2024 00:00:00 +0000

背景

HugoからOGPを動的に吐き出すツールとして Ladicle/tcardgen がある。 2024/11/22 現在当ブログでも利用していて、 takeokunn/blog のNix化に伴い tcardgen もNixでパッケージングする必要があった。

流れ

1. 自作nur-packages に登録

takeokunn/nur-packages に雑に次のようにパッケージングをした。

{ buildGoModule, fetchFromGitHub }:
buildGoModule {
 pname = "tcardgen";
 version = "0.0.1";
 src = fetchFromGitHub {
 owner = "Ladicle";
 repo = "tcardgen";
 rev = "2222547ac37c2d6e1961b00acef3771f48ac8220";
 hash = "sha256-6Z4SWpjdPMMCC6xm+xjSNAWQpO2FD91p+Mk9Y+Hh7AY=";
 };
 vendorHash = "";

 doCheck = false;

 meta = {
 description = "Generate a TwitterCard(OGP) image for your Hugo posts.";
 homepage = "https://github.com/Ladicle/tcardgen";
 mainProgram = "tcardgen";
 };
}

src 部分は seppeljordan/nix-prefetch-github を利用して取得。

$ nix-shell -p nix-prefetch-github
$ nix-prefetch-github-latest-release --nix Ladicle tcardgen
let
 pkgs = import <nixpkgs> {};
in
 pkgs.fetchFromGitHub {
 owner = "Ladicle";
 repo = "tcardgen";
 rev = "2222547ac37c2d6e1961b00acef3771f48ac8220";
 hash = "sha256-6Z4SWpjdPMMCC6xm+xjSNAWQpO2FD91p+Mk9Y+Hh7AY=";
 }

2. 手元のBuildが通ることを確認

vendorHash は空文字にしてbuildをするとエラーメッセージに書いてあるのでそれを埋める。

2024年版private-isu構築メモ

Sun, 17 Nov 2024 00:00:00 +0000

背景

ISUCON14の練習の為catatsuy/private-isuを自分のAWSに構築しようとしたが、 tohutohu/private-isu.yaml - gistが構築できなかったのでメモ。

問題点

tohutohu/private-isu.yaml - gist のCloudFormationをそのまま起動しようとするとAMIがないと怒られる。

Name	ImageId	InstanceType
server	ami-0d92a4724cae6f07b	c6i.large
bench	ami-0582a2a7fbe79a30d	c6i.xlarge

AMIの検索は以下から行う。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/finding-an-ami.html

修正方法

catatsuy/private-isu#ami に動くAMIが記述されているのでそちらに修正し、費用面を考慮して InstanceType を次のように修正した。

Name	ImageId	InstanceType
server	ami-047fdc2b851e73cad	t2.medium
bench	ami-037be39355baf1f2e	t2.medium

また、 KeyPairName は不要なので削除した。

実際のCloudFormationは以下。

AWSTemplateFormatVersion: '2010-09-09'
Description: private-isu template
Parameters:
 GitHubUsername:
 Description: "GitHub Username for SSH public key"
 Type: String
Resources:
 VPC:
 Type: AWS::EC2::VPC
 Properties:
 CidrBlock: '192.168.0.0/16'
 MySubnet:
 Type: AWS::EC2::Subnet
 Properties:
 VpcId: !Ref VPC
 CidrBlock: '192.168.1.0/24'
 AvailabilityZone: ap-northeast-1a
 MyInternetGateway:
 Type: AWS::EC2::InternetGateway
 AttachGateway:
 Type: AWS::EC2::VPCGatewayAttachment
 Properties:
 VpcId: !Ref VPC
 InternetGatewayId: !Ref MyInternetGateway
 MyRouteTable:
 Type: AWS::EC2::RouteTable
 Properties:
 VpcId: !Ref VPC
 PublicRoute:
 Type: AWS::EC2::Route
 DependsOn: AttachGateway
 Properties:
 RouteTableId: !Ref MyRouteTable
 DestinationCidrBlock: 0.0.0.0/0
 GatewayId: !Ref MyInternetGateway
 SubnetRouteTableAssociation:
 Type: AWS::EC2::SubnetRouteTableAssociation
 Properties:
 SubnetId: !Ref MySubnet
 RouteTableId: !Ref MyRouteTable
 MySecurityGroup:
 Type: AWS::EC2::SecurityGroup
 Properties:
 GroupDescription: Enable SSH, HTTP, HTTPS access
 VpcId: !Ref VPC
 SecurityGroupIngress:
 - IpProtocol: tcp
 FromPort: 22
 ToPort: 22
 CidrIp: 0.0.0.0/0
 - IpProtocol: tcp
 FromPort: 80
 ToPort: 80
 CidrIp: 0.0.0.0/0
 - IpProtocol: tcp
 FromPort: 443
 ToPort: 443
 CidrIp: 0.0.0.0/0
 - IpProtocol: -1
 CidrIp: 192.168.0.0/16
 ServerInstance:
 Type: AWS::EC2::Instance
 Properties:
 InstanceType: t2.medium
 ImageId: ami-047fdc2b851e73cad
 SubnetId: !Ref MySubnet
 PrivateIpAddress: '192.168.1.10'
 SecurityGroupIds:
 - !Ref MySecurityGroup
 UserData:
 Fn::Base64: !Sub |
 #!/bin/bash
 GITHUB_USER=${GitHubUsername}
 mkdir -p /home/isucon/.ssh
 curl -s https://github.com/$GITHUB_USER.keys >> /home/isucon/.ssh/authorized_keys
 chown -R isucon:isucon /home/isucon/.ssh
 chmod 600 /home/isucon/.ssh/authorized_keys
 BenchmarkerInstance:
 Type: AWS::EC2::Instance
 Properties:
 InstanceType: t2.medium
 ImageId: ami-037be39355baf1f2e
 SubnetId: !Ref MySubnet
 PrivateIpAddress: '192.168.1.20'
 SecurityGroupIds:
 - !Ref MySecurityGroup
 UserData:
 Fn::Base64: !Sub |
 #!/bin/bash
 GITHUB_USER=${GitHubUsername}
 mkdir -p /home/isucon/.ssh
 curl -s https://github.com/$GITHUB_USER.keys >> /home/isucon/.ssh/authorized_keys
 chown -R isucon:isucon /home/isucon/.ssh
 chmod 600 /home/isucon/.ssh/authorized_keys
 ServerEIP:
 Type: AWS::EC2::EIP
 BenchmarkerEIP:
 Type: AWS::EC2::EIP
 ServerEIPAssociation:
 Type: AWS::EC2::EIPAssociation
 Properties:
 InstanceId: !Ref ServerInstance
 EIP: !Ref ServerEIP
 BenchmarkerEIPAssociation:
 Type: AWS::EC2::EIPAssociation
 Properties:
 InstanceId: !Ref BenchmarkerInstance
 EIP: !Ref BenchmarkerEIP

終わりに

実際に練習するなら指定された環境のまま起動した方がよいだろうが、あくまで練習として private-isu を立ち上げたいだけという今回の用途ではこれで十分。

GnuPG 2.4.4でEmacsで発生していたバグ修正された

Sat, 27 Jan 2024 00:00:00 +0000

Summary

Emacs内でgpg fileがsaveできなくなった時に対応したことメモにもあるとおり、GnuPG 2.4.0を使うとEasyPGが正常に動かないという問題があったが、GnuPGを2.4.4に上げると解決した。

一連の流れ

以前も見て、私の環境ではならんなと思ってたけど、たんに gpgtools の gpg2 を読んでいたからだった。 https://t.co/UdI5QtmC4N pic.twitter.com/SNSj5Jd2DT
— . (@takaxp) January 27, 2024

2.4.4 が降ってくれば直る説。https://t.co/zG6kkrQg4s pic.twitter.com/YqDEmiDJit
— . (@takaxp) January 27, 2024

Re: epg-encrypt-string in Emacs seems to be incompatible with GnuPG 2.4.1 on macOS, 2.4.0 works を見ていると、 2.4.4 で直るっぽいとの記述がある。

GnuPG側の変更はこちら。

Homebrewではすでにこちらのcommitで対応済みなので brew update で更新される。

Nixユーザーはnixpkgsが対応するまでは次のようにoverlayを定義して対応すればよい。

{
 nixpkgs.overlays = [
 (final: prev: {
 gnupg = prev.gnupg.overrideAttrs (old: {
 src = prev.fetchurl {
 url = "mirror://gnupg/gnupg/gnupg-2.4.4.tar.bz2";
 hash = "sha256-Z+vgFsqQ+naIzmejh+vYLGJh6ViX23sj3yT/M1voW8Y=";
 };
 });
 })
 ];
}

実際に自分Emacs環境で実験した所正常に動作することが確認取れた。

2023年のorg-mode活用と今後の抱負

Thu, 25 Jan 2024 00:00:00 +0000

Introduction

この記事はVim駅伝の2024-01-24の記事です。

前回の記事はyasunoriさんの「Vimを勧めるときのすヽめ」です。

私にとっての2023年はorg-modeの年でした。 org-modeで実現できることは何があるのかと、自分にとってのorg-modeはなんなのか、ということに腰を据えてちゃんと向き合えたので実際に取り組んだことを記事にしておきます。

Emacsとの出会いと使えるようになるまで

私のEmacs歴は6年程度で、takeokunn/.emacs.d のfirst commitは Sat Nov 3 18:15:51 2018 +0900 です。もともとSublime Textを使っており、Emacsを使い始めたきっかけはハッカーと画家でした。ハッカーと画家にLispのすばらしさが書いてあり、Lispを書くならEmacsだろうということで安易な気持ちで入門しました。

風になりたい奴だけがEmacsを使えば良い 2020 などEmacsの魅力を語っている記事がたくさんあったのも理由のひとつでした。

最初の2年はEmacsを操作するのに慣れるまで必死でした。世の中にはEmacsを入門してすぐに有名なOSSにコントリビューションしたり、自分でキラーアプリケーションを作ったりする天才のような人達がごろごろいるが、私は要領が悪いため残念ながらそういう人間ではありませんでした。生まれたての小鹿みたいなおぼつかない操作、何をしたらどう動くのか分からないし何がどう動いるのか分からず、どう質問をしてよいのかすら分からない状態が続きました。

3年くらい使ってようやく概要を把握でき、Sublime Textと同じくらいの編集速度を出すことができるようになりました。徐々にEmacsの気持ちが分かってきて、ざっくり何ができるのか、どのくらいのポテンシャルを秘めているのかということを肌感覚でつかめてきました。それと同時に、Emacsで実現可能なものの輪郭を見たくなってきました。その為には他人のEmacsの設定を漁りまくり、少しでも便利そうだと思ったパッケージはすべて検証するという運用をしてみました。

4年目はとにかくinit.elの管理方法と起動速度にこだわった1年になりました。 Emacsを世界最速級で起動する方法 - Zenn の目的は起動時間を短縮することによって、設定の検証効率を上げることでした。また、起動速度チューニングすることによってどうEmacs本体がEmacs Lispを実行するのか深く理解できたので非常に有意義な取り組みだったと感じています。

課題

ソフトェアの開発は「趣味だろうと仕事だろうとプログラミングに閉じることはできない」という問題があります。メール確認だったりブログの執筆だったりパスワードマネージャーだったり、「ソフトウェアエンジニアなら必要なもの」というのはかなりあります。

自分がやりたかったのは「Emacs内で最高の環境」を作ることです。Emacsはそれを許容してくれます。カーソル移動だったり、keybindの最適化だけではなく、自分の普段のワークフローをしっかりEmacsに落としきる必要があります。

通常のプログラミングのためのチューニングとは別に、次のようなことをやりたいと考えていました。

メールの確認やパスワード管理を自動化したい
日報や工数入力を最短で入力できるようにしたい
質の担保されたブログ記事を最短で公開したい
すべてのコンピュータ上での作業をメモしたい
- たとえ案件が変わろうとPCが壊れようと過去に行ったことを検索可能な状態にしたい
- Local LLMに食わせることによって自分専用のAIを作りたい
etc

私は特に怠惰でだらしない人間ですので、いかにワークフローを整えて自動化をしてドキュメントとして残すか、サボったツケを効率良く払うことに注力する必要がありました。

なぜorg-modeなのか

私はプレーンテキストに対して強いこだわりがあるので、可能な限りプレーンテキストをGitで管理する運用にしたいと考えていました。

Emacsとの親和性なども考えるとorg-modeしかないだろう、という結論に至りました。 org-mode features を見ているとまさしく私がやりたかったことを網羅していました。

Markup
構造的な編集
テーブル操作
コードブロック
エクスポート
タスク管理
スケジュール
時間計測
メモ
強力な拡張パッケージ

org-modeはコンピュータを使う時に必要なものをすべて用意してくれています。当然のことながら、Emacsのパッケージなので org-mode のキーバインド、その先 - Qiita にもあるとおりEmacsのkeybindで操作できます。

Zedファーストインプレッション

Thu, 25 Jan 2024 00:00:00 +0000

Introduction

Rust製コードエディター「Zed」がオープンソースに～v1.0リリースへ向けて門戸を開く - 窓の杜にもあるとおり、zed-industries/zedが公開されたのでコードをざっくり読んでみたのでメモする。

Rustへの知見が皆無であること、雑なコードリーディング要素があるのでご了承ください。

Feature

https://zed.dev/ には次のようなことを書いている。

ハイパフォーマンス
AIサポート
LSP
Package
- vim-mode
- terminal
- theme
- etc.
チーム開発
UI/データ構造
- マルチコアサポート
- Tree-sitterサポート
- 共同編集アルゴリズムCRDT

Local Build

docs/src/developing_zed__building_zed.md にある手順とおりコマンドを実行したら手元で簡単にBuildできた。

docs/src/system_requirements.md にはMacしかサポートしてないことが記述されている。

Docs

docs/src/configuring_zed.md に設定方法が書いてあるが、基本的にjson5で管理していて細かい設定ができそうなことが伺える。

docs/src/configuring_zed__configuring_vim.md にvim-modeの使い方が書かれている。

docs/src/telemetry.md にサービス改善の為に匿名でzed.devに利用状況を送信することが書かれている。

コードリーディング

ディレクトリごとに雑にコメントを書いていく。

$ tree -L 1 .
.
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── Cargo.lock
├── Cargo.toml
├── Dockerfile
├── LICENSE-AGPL
├── LICENSE-APACHE
├── LICENSE-GPL
├── Procfile
├── README.md
├── assets
├── crates
├── debug.plist
├── docker-compose.sql
├── docker-compose.yml
├── docs
├── plugins
├── rust-toolchain.toml
├── script
├── target
└── typos.toml

assets/

font情報やiconやsoundsが入っている。また、keymapsやsettingsにデフォルトの設定がjsonで格納されている。

Emacsユーザーから見たvim-jp

Fri, 19 Jan 2024 00:00:00 +0000

Introduction

この記事はVim駅伝の2024-01-19の記事です。

前回の記事はkawarimidollさんの「俺自身がVimのstatuslineになることだ」です。

この記事を読むにあたっての注意点

筆者の主観要素
筆者のEmacs愛要素
筆者のEmacsコミュニティ活動への努力不足要素
- 2024年はEmacsイベントを精力的に開催します

対象読者

これからEmacsを始めたい人
vim-jp slackにまだ参加していない人

今北産業

エンジニアの楽園 vim-jp - 日々、とんは語る。を読み vim-jpのチャットルームについてを参考にvim-jp slackに入る
#welcome で自己紹介をする
#hobby-gourmet で直近の食事をアップロードする

自己紹介テンプレートは以下。

はじめまして。
これからEmacsを学びたくてvim-jp slackに参加しました。
言語は主に○○を使っていますが、最近は○○を勉強しています。
よろしくお願いします。

Vim/Emacsエディタ戦争について

「VimmerとEmacsユーザーは仲が悪い」とエディタ戦争のようなことを巷ではいわれてますが、実際のところはそんなことありません。エディタ戦争と言っている人達はどちらのテキストエディタも大して使っていない素人であることが多く、実際のところは少なくとも日本人コミュニティでは一切そんなことありません。

たとえばeasymotion/vim-easymotionがabo-abo/avyで再実装されたように、Vim Pluginで有用なものはEmacs Packageに移植されたり、常に互いを高め合うものとして存在しています。（逆もまた然り）

私個人としてはEmacsが世界最強のテキストエディタでありほかのテキストエディタの追随を許さない圧倒的に優れたものだという思想を持っています。こういう思想を持った私でもVimコミュニティ内で問題なくVimmerと交流できているので、世間が思っている以上にテキストエディタコミュニティは他テキストエディタに寛容です。

Emacsコミュニティの抱える問題

私がEmacsを始めたのは5年前くらいですが、私の観測範囲内ではコミュニティ活動するEmacsユーザーの数は5年前からほぼ変わらず、悲しいことに新規で入ってくる人はほとんどいません。つまりEmacsコミュニティは平均年齢が5歳分上がっているのです。

Emacs日本コミュニティにemacs-jp slackがあります。分からないことがあったらちょっとしたことでも #question に気軽に投げてほしいし、 #today-i-learned に学んだことを共有してほしいです。しかし残念ながら投稿の流速が遅く、特に初心者は雑談や質問しつらいという現状があります。

同じくらいの初心者が少ない技術コミュニティでは、質問するのも人間関係を構築するのも難易度がどうしても高くなってしまいます。ベテラン達も「イマドキEmacsを長い時間苦労してやらずにVSCodeとか使った方がいいんじゃないか?」と思っている人も少なくなく、初心者を増やす活動を中々できていないという側面もあります。

本来ならゴリラ.vimのような初心者歓迎イベントを定期開催して、少しでもEmacsへのハードルを下げるべきなのかもしれないなと反省しています。

vim-jp slackって何？

エンジニアの楽園 vim-jp - 日々、とんは語る。に非常に分かりやすくまとまっています。 vim-jpはVimという名前を冠しているにもかかわらず、以下のようなchannelがあり生活全般の会話をできます。（あくまで一例）

#hobby-*
- #hobby-gourmet : 食事全般
- #hobby-gadget : ガジェット全般
#life-*
- #life-housekeeping : 家事全般
- #life-healthcare : 健康全般
#event-*
- #event-gorillavim : ゴリラvim関連
#game-*
- #game-minecraft : マイクラ関連
#times-
- #times : 全員の分報
- #times-take : 私の分報

Emacsユーザーは以下のチャンネルに入っておくことをお勧めします。

テキストエディタがPHPをシンタックスハイライトする仕組みとモダンテキストエディタ事情について

Thu, 18 Jan 2024 00:00:00 +0000

注意

この記事はPHPerKaigi 2024のパンフレット記事です。A4ページ4枚程度の量を書いています。書面での掲載につきハイパーリンクがないことをご了承ください。

https://fortee.jp/phperkaigi-2024/proposal/161b2ec9-c279-4336-8e17-1aa054dacae9

PDF版はこちらです。

Introduction

プログラミング言語は日進月歩で進化し続けています。処理系のパフォーマンス改善、既存のバグ修正、挙動の変更などさまざまな変更が入るが、ユーザーにとって一番影響があるのは「新規の構文追加」ではないでしょうか？ PHPの場合PHP 8.0以降にmatch式やenum構文は直近5年以内に追加されたものです。 PHPに限らずほか言語のRFCでも新規の構文が提案されている例は枚挙に暇がありません。Goのジェネリクスなどもその一例です。

言語レベルで新規の構文が追加された時、テキストエディタでも適切に色付けできることが望ましいです。それはオープンソースのテキストエディタだろうと商用エディタだろうと区別はありません。そもそもテキストエディタはどのように構文を解釈してハイライトしてくれているのか、Tree-sitterなどの最近のテキストエディタ事情も踏まえて解説していきます。

なお私は熱狂的なEmacsユーザーでありEmacsのPHP Packageであるphp-modeのオーナー権限もあるので、Emacsひいきな解説になってしまうのはご了承ください。

シンタックスハイライト概要

シンタックスハイライトとは、 public のようなキーワードや関数名や言語特有の構文に色をつけてくれるものです。 Wikipediaによると、シンタックスカラリングや構文着色ともいうらしいです。

シンタックスハイライトには、「テキストの可読性を向上させ文脈をより明瞭にする」や「記述ミスや括弧の対応のミスなどを防ぐことができる」等、さまざまなメリットがあります。明確なデメリットは私は思いつきませんが、「流し読みがしやすくなるのでプログラマーはコード全体を理解しようとはしなくなる」ということを主張する人もいるようです。

配色はカラーテーマごとに違います。世の中には無数のカラーテーマがあり、私はDraculaやSublime Textのdefault themeのmonokaiが好きです。

構文が違うので当然言語の数だけシンタックスハイライトがあります。それぞれの実装によって方針はまちまちですが、似ている言語から上書きするよう実装することで実装コストを下げる対応をしています。 PHPはCやJavaと記述が似ているので、CやJavaの実装を上書きし、部分的にPHPの構文を追加して対応できます。実際EmacsのPHP Packageではこのような対応をしています。

シンタックスハイライトの大まかなしくみ

世の中にはテキストエディタの実装は無数にあります。プログラミング言語に対応したテキストエディタの実装はおおよそ2つに大別できます。

正規表現ベース
ASTベース

正規表現ベースのシンタックスハイライトはVimやEmacsのような古くからあるテキストエディタでよく使われています。当然それぞれのテキストエディタごとに実装は違うので移植性はありません。

ASTベースのシンタックスハイライト実装は2024年1月現在Tree-sitterが一強だと言っても過言ではありません。 Tree-sitterはC/Rust製のツールで、特定のテキストエディタに依存しない形で実装された高速で動作するパーサジェネレータツールです。 Tree-sitterはもともとAtomで使用するためにGitHubによって開発され、2018年にリリースされました。ソースコードをパースして構文木をS式を出力することにより、各テキストエディタはS式を解釈する実装をすれば各々が構文を解釈する必要がない、という作りになっています。

テキストエディタにおけるシンタックスハイライトの難しいところは以下が挙げられます。

常にユーザーが入力し続けるので構文が確定しない
1入力ごとにハイライトする必要がある為高速で挙動させる必要がある

また、1言語で複数言語を表現する場合難易度が上がります。たとえばVue.jsはHTML/CSS/JavaScriptを1ファイル内で記述できるし、PHPももともとHyperText PreprocessorなのでHTMLを記述できます。

正規表現によるシンタックスハイライト

正規表現によるシンタックスハイライトを採用しているVimやEmacsでは次のような実装がされています。

キーワードは直接色を付ける
正規表現によって構文を定義する
- $ の後は確実に変数
- function の後は確実に関数名になり、その後の括弧は関数の引数になる
- // 直後はすべてコメントになる

Emacsではシンタックステーブルというものがデフォルトで用意されており、独自の記法で記述する必要があります。

以下は実際にphp-modeで実装されているコードを抜粋したものです。 Emacs Lispの正規表現がそもそも難しいのもあり、複雑怪奇で特殊な訓練しないと読めないことが分かるでしょう。

;; Class modifiers (abstract, final)
("\\_<\\(abstract\\|final\\)\\_>\\s-+\\_<class\\>" 1 'php-class-modifier)

;; Highlight variables, e.g. 'var' in '$var' and '$obj->var', but
;; not in $obj->var()
("\\(->\\)\\(\\sw+\\)\\s-*(" (1 'php-object-op) (2 'php-method-call))
("\\<\\(const\\)\\s-+\\(\\_<.+?\\_>\\)" (1 'php-keyword) (2 'php-constant-assign))

;; Logical operator (!)
("\\(!\\)[^=]" 1 'php-logical-op)

;; Highlight special variables
("\\(\\$\\)\\(this\\)\\>" (1 'php-$this-sigil) (2 'php-$this))
("\\(\\$+\\)\\(\\sw+\\)" (1 'php-variable-sigil) (2 'php-variable-name))
("\\(->\\)\\([a-zA-Z0-9_]+\\)" (1 'php-object-op) (2 'php-property-name))

;; Highlight function/method names
("\\<function\\s-+&?\\(\\(?:\\sw\\|\\s_\\)+\\)\\s-*(" 1 'php-function-name)

;; 'array' and 'callable' are keywords, except in the following situations:
;; - when used as a type hint
;; - when used as a return type
("\\b\\(array\\|callable\\)\\s-+&?\\$" 1 font-lock-type-face)
(")\\s-*:\\s-*\\??\\(array\\|callable\\)\\b" 1 font-lock-type-face)

;; For 'array', there is an additional situation:
;; - when used as cast, so that (int) and (array) look the same
("(\\(array\\))" 1 font-lock-type-face)

; Support the ::class constant in PHP5.6
("\\sw+\\(::\\)\\(class\\)\\b" (1 'php-paamayim-nekudotayim) (2 'php-magical-constant))
;; Class declaration keywords (class, trait, interface)
("\\_<\\(class\\|trait\\|interface\\)\\_>" . 'php-class-declaration)

言語内に複数言語あるVue.jsやPHPのような言語では、Emacsの場合カーソル位置によって対象の言語に切り替える処理をしています。

AquaSKKをDvorak仕様にする方法

Mon, 15 Jan 2024 00:00:00 +0000

Introduction

QWERTY配列からDvorak配列に移行するにあたってAquaSKKもDvorak仕様にする必要があったのでメモ。

Mac標準キーボード

MacでDvorakキーボードレイアウトを使用する - macOSユーザガイドによると、Mac標準キーボードにはDvorakが4種類ある。自分のユースケースは標準的な使い方なので Dvorak: 最もよく使用されるキーが指の下に配置されています。 を選択しました。

- Dvorak: 最もよく使用されるキーが指の下に配置されています。
- Dvorak - 左利き: 最もよく使用されるキーが左手の下に配置されています。
- Dvorak - QWERTY ⌘: Commandキーを押したままにしたときに、一時的にレイアウトをQWERTYに変更します。
- Dvorak - 右利き: 最もよく使用されるキーが右手の下に配置されています。

次のような設定になってればよい。

AquaSKK設定

AquaSKKの設定画面にキーボードレイアウトを指定できる場所がある。さきほど指定したDvorak配列を指定する。

即時で反映されない場合は設定反映を押して明示的に反映させる。

PHPカンファレンス北海道2024に参加してきました

Fri, 12 Jan 2024 00:00:00 +0000

Introduction

2024/1/13（土）に行われたPHPカンファレンス北海道2024に参加してきました。

https://phpcon.hokkaido.jp/

今回は2024/1/12（金）〜2024/1/14（日）の2泊3日の旅行でした。なおこの記事は3日目自由行動からが本編なのでよしなに飛ばしてもかまいません。

カンファレンス自体は今回登壇もしていないしスタッフもやっていないのでただのガヤですのでご了承ください。

TL;DR

海鮮を無限に食べた
カンファレンス楽しかった
スキースノボしてないのに50回以上滑った
小樽最高だった

準備

飛行機のチケットを直前の日曜までに取っていなく、あすみかんに指摘されてようやく気がつきなんとか取ることができました。 PHPerKaigiのパンフレット記事の「テキストエディタがPHPをシンタックスハイライトする仕組みとモダンテキストエディタ事情について」もなんとか提出できて感謝しかないです。

たけてぃが北海道行けるように、ここを支援する使命感がでてきている　これが母性？ pic.twitter.com/1zYGCffqTC
— あすみ (@asumikam) January 7, 2024

航空券は往復1万2000円、宿は二泊で8000円くらいで安く抑えることができました。

Peachみたけど、12-15まだいっぱいあるからだいじょうぶそ
ほてるも、ドミトリーだけど12-15で1万円のところあるからここがいいんじゃないかな pic.twitter.com/fXwODY4uVZ
— あすみ (@asumikam) January 7, 2024

事前に北海道グルメについてうちのシェフに相談したところめんめに行けとアドバイスされましたが、結局時間的に行けなかったです。

北海道旅行メモ

めんめには死んでもいけ、めんめにいかないなら帰ってくるなhttps://t.co/HNEgHVemaQ
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 6, 2024

1日目移動〜前夜祭

全体的に道内はとても暖かかったらしい。

自宅〜札幌

朝5時半に起床し、池袋成田間6時15分発のバスに乗りました。

バス乗った！勝ったな！
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 11, 2024

バスがかなり高速なWi-Fileを提供してくれていたのでPCを弄ることができました。

国際バスFree Wifiあるじゃん最高じゃん
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 11, 2024

三半規管つよつよエンジニアなのでバスの中でPC弄るの余裕
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 11, 2024

成田空港に1時間以上余裕を持って到着したので第一ターミナルを練り歩いていました。

飛行場テンション上がる pic.twitter.com/3OnHNAYNT6
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 11, 2024

common lispで動いてるやつだ！！ pic.twitter.com/JavUVOje5B
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) January 11, 2024

北へ pic.twitter.com/1mL7S2L1Wq

Authyからpassword-store-otpに移行した

Wed, 10 Jan 2024 00:00:00 +0000

Introduction

Bitwardenからpassword-storeに移行したでpassword-storeに移行できたので、TOTPも Authy から移行する。

Goal

過去の案件で使ってたものを断捨離する
password-store-otp経由でOTP Codeを取得できるようにする
Authy管理しているデータをpassword-storeに移行する

Not Goal

Authyを完全に削除する
- Bitwarden同様数年間使わなくても問題なかったら適切に削除する

作業手順

1. password-store-otpを有効にする

私はNixユーザーなのでNix Packageからpassを落としてくる。次のような設定でhome-manager経由で入れると勝手にExtensionが有効になる。

{ pkgs, ... }:

{
 home.packages = with pkgs; [
 (pass.withExtensions (extensions: with extensions; [ pass-otp ]))
 ];
}

fish shellで拡張を有効にする。

set -x PASSWORD_STORE_ENABLE_EXTENSIONS true

2. AuthyからExportする

公式のExport方法は見あたらなかったので、Export TOTP tokens from Authy - gistを参考にAuthy Desktopから情報を抜き出す。

3. password-storeに貼りつける

次のようなフォーマットでパスワードの下に otppath を入力する。

P@ssw0rd
otpauth://totp/Discord:foo@gmail.com?secret=XXX&issuer=Discord
url: https://discordapp.com/
username: foo@gmail.com

4. アクセスできるか確認する

次のコマンドをたたくとclipboardにOTP codeがコピーされる。

$ pass otp -c private/life/tech/discord
Copied OTP code for private/life/tech/discord to clipboard. Will clear in 45 seconds.

Result

16個のTOTP情報を移行した。

Bitwardenからpassword-storeに移行した

Mon, 08 Jan 2024 00:00:00 +0000

Introduction

Bitwardenからpassword-storeに移行したので作業内容をメモしておく。

Basic

普段使うものは可能な限りPlain TextとGitで管理したい
EmacsやTerminalから簡単に呼び出したい
GnuPGを可能な限り活用したい

Goal

Bitwardenに保存されているすべての情報をpassword-storeに移行する
EmacsやTerminalから簡単にパスワードを取得できるようにする

Not Goal

Bitwardenのアカウントを完全に削除する
- 数年間使わなくても問題なかったら適切に削除する

技術選定

password-storeを選択した理由は以下。

十分に枯れている
Plain TextとGitで管理できる
password-storeが挙動しなくなってもGPGさえ動けばよい
- shell scriptの小さなコードベースで書かれている
- GPGが動かない時は git commit もできない状態なので根本的に問題
2024年現在所属している会社でpassword-storeを使っている
- ref. Pass: The Standard Unix Password Manager の紹介 - Qiita
TOTPに対応している
Emacs Packageがある

周りのエンジニアに何を使っているのか聞いたところ、1passwordやBitwardenを使っている人が大半だった。

作業手順

1. Bitwardenからパスワードを抽出する

bitwarden/clients を手元のPCに入れる。

$ bw --version
2023.12.1

Loginしてセッションを取得。

$ bw login

bw list items コマンドを叩いてパスワードを抽出する。

$ bw list items --session <session_id> \
 | jq '.[] | { folderId: .folderId, name: .name, login: .login }' \
 | jq . > /tmp/bw.json

次のようなjsonが /tmp/bw.json に出力される。

org-roamで記事を管理しGitHub Actionsで適切に公開する

Tue, 19 Dec 2023 00:00:00 +0000

Introduction

2023年度Emacsアドベントカレンダー2日目の記事です。

当記事ではorg-roamを用いたブログ記事のコンテンツ管理方法と、ZennやHugoへ公開する方法の一連の流れについて解説しています。

個々の技術への深堀は必要に応じて別途記事に認めますのでご了承ください。

考え方

ブログサービスについて

Zenn や Qiita などブログサービスを提供している会社は世の中に無数にありますが、「ブログ記事という形式で世の中に公開する」ということには大きく分けて次の2つの要素があります。

コンテンツ管理
記事公開

2000年代初期と2023年現在求められているブログサービスの必要条件は異なるように、年々求められる必要条件は増えています。 2023年においてSNSに投稿したものを埋め込むことができないブログサービスというのはほぼ存在しないように、有名なブログサービスに乗っかっておけばモダンな環境を常に享受し続けることができます。

しかしながら、ブログサービスにも当然栄枯盛衰があり自分が使っているサービスの行く末など個人には分かりようがありません。現に私がプログラミングを初めた2014年ごろはQiitaが技術系ブログサービス一強でしたが、2023年現在ではZennが主流になっています。常によりよいブログサービスが出たら移動することも念頭に置く必要があります。

私が勤めている会社では多少技術的な記事だったとしても広報目的にnoteに書くという運用がされていたり、以前所属していた会社では、はてなブログで技術ブログを運用していました。ソフトウェアエンジニアとして働く以上「どこに対して記事公開するか」というのは自分ではコントロール効かないという前提があります。

上記で述べたように「記事公開」に関しては自分でどうしようもない部分が多々ありますが、「コンテンツ管理」に関しては完全に自分でコントロールを効かせることができます。適切なフォーマットで公開すればよいだけですので、どのように記事を管理されようとブログサービスからしたらDBのレコードの1つなだけなでどうでもよいことなのです。

ソフトウェアエンジニアとして

ソフトウェアエンジニアにとって「技術的な文書を書く」という作業は避けられません。「ドキュメントを書く」「チケットに証跡を書く」「同僚と技術的やりとりをする」等さまざまありますが、「ブログ記事を書く」という行為もそのひとつです。特定の技術は廃れようと、20年後30年後も「技術的な文書を書く」という行為がなくなることはないでしょう。

私は残念ながらソフトウェアエンジニア以外の仕事が絶望的にできないので、10年後も20年後もソフトウェアエンジニアとして働いているだろうという実感があります。あまり文章を書くのが得意ではないので、いかに低負荷で一定の品質の文書を書く環境を用意するか、というのが自分のソフトウェアエンジニアとしての人生にとって重要なことだと考えてます。

すべてをEmacs org-modeに最適化する

私は今までさまざまなテキストエディタを使い込んできました。その中で一番時間をつぎ込んだ時に高みを目指せるのはEmacsだということを確信しました。

「simpleがよいか、easyがよいか」という議論はエンジニア界隈ではよく話題にされます。私としては簡単さもシンプルさも本当にどうでもよく、たとえ難しかろうと複雑だろうと時間がかかろうと到達点が一番高いものがよいが一番よいと考えています。

今回の記事はorg-modeが主体になりますが、はっきり言ってorg-modeはsimpleでもeasyでもありません。巷にある「爆速で構築する」系の記事とは正反対です。初速は一切出ないですし、理解するまで時間がかかるし、運用が軌道に乗るまで本当に時間がかかります。ただし、org-modeにはプログラマー人生すべてを寄せることができるくらいのポテンシャルがあり、運用に乗った時のパフォーマンスは計りしれません。

少なくとも直近10年は一切Emacsへの投資を惜しまないという覚悟をしているので執筆環境もEmacs org-modeに最適化をしていきます。

要件

自分はブログに対して何を求めているのか、ブログとはどうあるべきなのか、をあらためて整理してみました。以下は個人ブログに対しての考え方ですので、複数人での運用に関しては特に考慮していません。

必要条件

The Emacs Editor Manual や Common Lisp Hyperspec のような数十年前のWebサイト程度の要件を最低限満たしていれば最低限ブログサイトとして名乗ってもよいでしょう。

コンテンツ管理

何がしかの方法で永続的に保存できる
MarkdownやOrgのような人間が解釈しやすい形式で記述できる

コンテンツ管理の必要条件は最低限で、データベースやプレーンテキストで保存できれば要件を満たしていると考えています。またHTMLをベタ書きするのは大ですので、MarkdownやOrgのような人間向きのフォーマットで最低限記述できるようにしたいと考えています。

記事公開

意図したHyperTextを継続的に配信できる
画像やCSSも配信でき、最低限文章を読めるデザインで配信する

最低限Webサイトとしての体を成していればよいと考えています。

十分条件

必要条件はあまりにも最低限すぎるので、2023年現在このくらいは最低限満たしたい条件を書いています。一応十分条件と書いてはいるものの2023年においての必要条件に含まれる要素もありそうです。

コンテンツ管理

MUST
- 秘密鍵やパスワードが入っていないことを網羅的に検査できる
- 校正ツールで継続的かつ網羅的に文章を検査できる
- エディタの標準的な機能を使うことができる
SHOULD
- 執筆から公開フローが整っている
- バージョン管理ができる
- 下書きができる
- 過去記事の検索性が優れている
MAY
- 複数のブログサービスにまたがって管理できる

個人でブログを書いているのもあり、誰かが校正してくれることがないので、うっかり不用意な記述やパスワードを公開しないようなしくみ作りが重要だと考えています。

2023年小田原旅行記

Mon, 30 Oct 2023 09:00:00 +0900

Introduction

2023年10月27日から1泊2日で小田原に夏休みを利用して旅行しました。ノープラン要素、適当要素、他人に迷惑をかける要素が存分に含まれているので、迷惑をかけた方本当にすみませんでした。写真や情報は適宜追加していきます。

旅行の流れ

経緯

きっかけは他社と合同勉強会をやっている事例を見ていた自分が「俺もやりてー」ってツイートしたことでした。(元ツイはこちら)

やりゃすか‼️
— あすみ (@asumikam) July 24, 2023

合同勉強会の詳細は対外的な記事にまとめるつもりなのでそちら参照してほしいですが、あすみさんと自分の会社はお互い物流関係のシステムを作っているいわば提携先で、絶対おもしろくなるんじゃないかということで開催することにしました。ちなみに自分はあまりにもこういう「調整作業」が苦手すぎて下準備をほぼすべてをあすみさんにやってもらいました。「ちゃんと御社側の名簿を作ってありがとう」と褒められる程度の仕事と、居酒屋の予約を取る時に「頑張れ！!!!君なら絶対やりとげられる！!!」とgoogle meets越しに応援する程度の仕事はしました。

蒲田温泉で前夜祭（PHPカンファレンス非公式）の小田原魅力LTを聞いてしまってからは、勉強会というよりも小田原旅行に行くのが目的になっていたかもしれません。

初日（昼）

「わからんけど多分朝から行くわ」と伝えておきながら前日朝3時まで飲んでいたので当然起きられる訳もなく、11時半くらいの新宿発ロマンスカーに乗って小田原にいきました。

いざ pic.twitter.com/zpHl3KqqnB
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) October 27, 2023

気分はこれから温泉旅館で缶詰になって執筆をする文豪のそれでした。ロマンスカーは座れるし充電もできるし車窓も良いので楽しいですね。

かつて明治大正時代の文豪もロマンスカーで浪漫を感じながら箱根湯本に行ってたんだろうなーと思うと胸が熱くなる
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) October 27, 2023

たのしい pic.twitter.com/fWIFtplAck
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) October 27, 2023

ついたー pic.twitter.com/dBbsZmuYF6

PHP Exceptionのpropertyにあるcodeはuser-defined error code

Tue, 01 Aug 2023 09:00:00 +0900

Introduction

仕事でPHPStanの修正をしている時、 Exception classのconstructorでcodeを指定しているコードに出くわした。 Exception におけるcodeの扱いについて記述している記事がなかったので php/php-src のコードにあたってみた。

簡易的な調査

Interface定義

php.netのUser Contributed Notesに次のような記述がある。 https://www.php.net/manual/en/language.exceptions.php#91159

<?php

interface IException
{
 /* Protected methods inherited from Exception class */
 public function getMessage(); // Exception message
 public function getCode(); // User-defined Exception code
 public function getFile(); // Source filename
 public function getLine(); // Source line
 public function getTrace(); // An array of the backtrace()
 public function getTraceAsString(); // Formated string of trace

 /* Overrideable methods inherited from Exception class */
 public function __toString(); // formated string for display
 public function __construct($message = null, $code = 0);
}

code とは User-defined Exception code と書いてあるとおり、ユーザー側が任意の数値を入れられる。

「PHP Lovers Meetup vol.0 ~ はじまりは
Mon, 10 Jul 2023 09:00:00 +0900

Introduction

2023/07/10（Mon）に行われた「PHP Lovers Meetup vol.0 ~ 始まりは<?phpから」に参加しました。

connpass
- https://php-lovers-meetup.connpass.com/event/280822/
togetter
- https://togetter.com/li/2184479
repo
- https://github.com/brefphp/bref

PHP-DIやBrefの作者として有名な @matthieunapoli 氏が来日するということで @seike460 氏も福岡から招き、サーバレスフレームワークについて語っていただきました。自分はBrefを使ったことがないのでBref本体のコードをダラダラ読みながら登壇を聞いていました。

会場の雰囲気

来た #phplovers pic.twitter.com/XU6jAZqOiw
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) July 10, 2023

会場は40〜50人程度いて、phpカンファレンスで見慣れた方だらけでした。

The PHP meetup in Tokyo was an absolute blast!
We went from zero code to 1000 requests/second with Laravel in minutes.
In the 2nd talk I discovered how Bref is used at a Japanese company.
Incredibly friendly vibes, thanks for the warm welcome! And thanks @chatii for inviting me! pic.twitter.com/ghDixRZi5q
— Matthieu Napoli (@matthieunapoli) July 11, 2023

直近ゴリラvimでも来たのでpixiv社にはお世話になりっぱなしですね。

Emacs内でgpg fileがsaveできなくなった時に対応したことメモ

Sat, 24 Jun 2023 09:00:00 +0900

Introduction

自分用のメモです。何もしていないのに急にgpg fileがEmacsでsaveできなくなったので調査した。

再現手順

MacでEmacsを起動する
Emacsでgpg fileを開く
適当に編集する
C-x C-s で save-buffer を実行するとsaveできずにhangする

原因について

「emacs org-encrypt-entry hangs when file is modified - stackoverflow」に同様の問題が投稿されていました。

Emacsのcommitに次のような記述が追加されていました。 https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-29&id=1b9812af80b6ceec8418636dbf84c0fbcd3ab694

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index c0cb5b0..82ab48f 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -516,6 +516,13 @@ directory copy is ineffective.
 This is due to an arbitrary limit in certain versions of awk.
 The solution is to use gawk (GNU awk).

+*** Saving, via EasyPG, a file encrypted with GnuPG hangs
+
+This is known to happen with GnuPG v2.4.1. The only known workaround
+is to downgrade to a version of GnuPG older than 2.4.1 (or, in the
+future, upgrade to a newer version which solves the problem, when such
+a fixed version becomes available)
+
 ** Problems with hostname resolution

 *** Emacs does not know your host's fully-qualified domain name.

これによると、GnuPGのversionを下げることによってsave時にhangすることを防げるようです。自分の手元では 2.4.0 を使っていますが、同様の問題が起きました。

phpカンファレンス福岡2023に参加してきました

Sat, 24 Jun 2023 09:00:00 +0900

Introduction

2023/6/24(土）に行われたphpconference福岡に参加してきました。 https://phpcon.fukuoka.jp/2023/

今回は2023/6/23(金）〜2023/6/26(月）の3泊4日の旅行でした。

TL;DR

福岡旅行超楽しかった
普段Twitterでしか会えないPHPerと会えた
イベント運営、登壇者、スポンサーに圧倒的感謝

1日目移動〜前夜祭

飛行機〜宿

普段一切旅行しないので同僚に相談したところ、新幹線よりもLCCの方が圧倒的に安いという話をされました。池袋〜成田までは高速バスに乗って向かいました。

早速成田第3ターミナルで降りなくちゃいけないところを第1ターミナルで降りてしまった pic.twitter.com/MJsNzHtfVh
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 23, 2023

福岡行くぞー pic.twitter.com/p5VdoNpOqC
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 23, 2023

福岡着後、ららぽーとに向かうバスに乗ろうとしたら当然乗るものを間違えて博多駅行きに乗ってしまっていました。移動手段は電車よりもバス！福岡の交通あるある３選にもある通り、福岡のバスは複雑怪奇で苦労しました。

福岡νガンダム！！！！！ pic.twitter.com/ht2VfDhGSG
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 23, 2023

νガンダムを見れたし福岡旅行完！！
お疲れ様でした！！
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 23, 2023

ららぽーとから宿に向かう途中、知らない不動産勧誘の人からあおられるなどのランダムイベントがありました。

不動産勧誘「おにいさんちょっといいですか?」
俺「なんすか?」
不「正社員で年収300万以上だったりします?」
俺「俺フリーターすけど...(嘘」
不「あーーーやっぱりかーーーーすんません大丈夫っす」

何が「やっぱり」だよふざけんなって福岡初日キレてた
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 27, 2023

宿は一泊3900円のカプセルホテルで人権がないところでした。

今晩の宿です
対戦よろしくお願いします pic.twitter.com/uDQfvJA8sw
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 23, 2023

大浴場に脱衣場がなく、宿内は半裸で歩いているおじさんだらけで「これが安宿か。..!」と思わされました。

脱衣場がない脱衣所がない言ってるけどまじでこんな感じの間取り pic.twitter.com/B9ArYX5VcH
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 25, 2023

知らない街の散歩は楽しいですね。

昨日撮った博多の自販機 pic.twitter.com/kJJlWwol8u
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) June 24, 2023

ちなみに会社で「人権がない宿泊まっている」ということを言ったら、以下のような話をされて「お前の泊まった宿は十分に人権がある」ということをつきつけられました。

ロドス島からアテネ行きの船に乗った時に、甲板の上で12時間過ごす。船の上で一晩過ごす必要があり、ラウンジで寝てようと思ったら、そのチケットでは入れないといわれて、追い出された。夜の気温が10度以下で、めっちゃつらかった。
福岡空港最寄りのドミトリー、普通の二段ベッドとカーテンで仕切られているだけの刑務所仕様。そして夜は爆音いびきのハーモニー。
中国の安宿は、経験の少ない若者が経営していることがあって、風呂の設計が悪くて排水がうまくいかず、脱衣場まで水浸し。ということがありましたね。
僕はダニ耐性が非常に高いらしく、南京虫の卵だらけのベッドで寝てたとかですかね。一回もさされてないので。

前夜祭

「(非公式）PHPカンファレンス福岡前夜祭」に主催者側として参加しました。 https://connpass.com/event/282285/

ob-phpstanを作った

Sun, 16 Apr 2023 09:00:00 +0900

Introduction

最近phpstanを弄ることが増えたのですが、逐一playgroundを開いてWebエディタ内で編集をするのが面倒に感じていました。 org-mode内で完結をするようにしたいと考えるのはEmacsユーザーなら当然の発想です。そこで今回は org-babel 経由でphpstanの実行結果をorg内で管理できるようにしました。

使い方

https://github.com/emacs-php/ob-phpstan

2023/04/16現在、melpaにはまだ登録をしていないので各自で落してきてパスを通してください。

(add-to-list 'load-path "/path/to/ob-phpstan.el")
(require 'ob-phpstan)

次に php-mode を派生させた phpstan-mode を作成してください。

(eval-after-load "org" '(add-to-list 'org-src-lang-modes '("phpstan" . phpstan)))

org-babel-phpstan-command に各自で phpstan へのパスを設定してください。

(with-eval-after-load 'ob-phpstan
 (setq org-babel-phpstan-command "/path/to/dir/phpstan"))

あとは適宜orgファイル内でコードブロック作成し、 org-babel を実行してください。

#+begin_src phpstan :level 0
 class HelloWorld
 {
 public function sayHello(DateTimeImutable $date): void
 {
 echo 'Hello, ' . $date->format('j. n. Y');
 }
 }
#+end_src

#+RESULTS:
#+begin_example
 ------ ----------------------------------------------------------------------------------
 Line /var/folders/z5/sk1q5qj96xg4g87vkcp4hq9h0000gn/T/babel-TGYZJB/phpstan-ulqeYI.php
 ------ ----------------------------------------------------------------------------------
 4 Parameter $date of method HelloWorld::sayHello() has invalid type
 DateTimeImutable.
 ------ ----------------------------------------------------------------------------------


 [ERROR] Found 1 error

#+end_example

実装方法について

ob-phpstan は100行にも満たない小さなコードで実装されています。 https://github.com/emacs-php/ob-phpstan/blob/main/ob-phpstan.el

phperkaigi 2023でパンフレット記事寄稿&登壇してきました

Mon, 27 Mar 2023 09:00:00 +0900

始めに

phperkaigi 2023 に参加しました。

phperkaigiとは、年1回大都会練馬のココネリホールで開催されるphperのためのイベントです。よくphpカンファレンスとごっちゃにされがちなので一応書いておくと、phpカンファレンスは秋に蒲田で、phperkaigiは春に大都会練馬で開かれる別のイベントです。

去年一昨年は3日間当日スタッフをやっていましたが、今年はDay1の夜終わり際とDay2全日参加をしました。

活動報告

パンフレット記事寄稿しました

「PHP 8から追加されたJITについて学ぼう!」というテーマで書きました。

パンフレットにもありますが、こちらにもありますので興味のある方はぜひ読んでください。

自分の人生でパンフレット記事の寄稿のような、自分のブログ以外に自分の文章が載ったのは初でした。正直自分自身JITについての理解度が低かったり、長文を書くことに慣れていなかったり、そもそも製本して提出する必要があったり、苦労する点は多かったです。

しかし、将来的に WEB+DB PRESS のような有名な技術誌に寄稿してみたいと思っていたのでとても良い機会に恵まれたなぁという気持ちでいっぱいです。また、実際にパンフレットを手に取って自分の記事が載っていることに対しての達成感は何ものにも代えがたいものだなと感じました。

非常に良い経験になったので次回も寄稿できるようにプロポーザルを出します。

スポンサーセッションで登壇をしました

約10年もののPHPアプリケーションとの付き合い方と、今後10年改善し続けるための取り組みについてというテーマで登壇をしました。

最近入社したにもかかわらず、phperkaigiのスポンサーになってほしいと伝えたところ、一切嫌な顔せずゴールドスポンサーになってくれました。普段は個人で登壇をしていたのでこういう機会は初でしたが、登壇準備と登壇当日を業務時間として扱ってくれたのが非常にうれしかったです。

ちなみに、当日スタッフをやっていた同僚の のりぃさん も業務扱いとして参加していました。

#phperkaigi 当日スタッフ業務完了！！
やり切った！！
疲れた！！
参加者の皆様、スポンサーの皆様、スタッフの皆様、本当にありがとうございました！
久しぶりのオフラインイベント、めちゃくちゃ楽しい。刺戟的な3日間でした！😀✨
— のりぃ (@m_norii) March 25, 2023

OPENLOGIでは積極的にphperとemacser採用しています。僕とphpを書きたい人はぜひ応募してください。

https://corp.openlogi.com/recruit/

イベントで楽しかったこと

楽しかったことを適当にピックアップしてざっくばらんに書いていきます。

[Day 0] きんじょうさんの発表よかった

2023年版「パーフェクトphp」の書籍化、まってます。

[Day 1] てきめんさんいつもありがとう

ファンです。いつも応援してます。

「第149回 PHP勉強会＠東京」で登壇してきました

Mon, 20 Feb 2023 09:00:00 +0900

始めに

2023-02-15（水）に GMO Yours で行われた第149回 PHP勉強会＠東京で登壇してきました。現地には30人、オンラインの視聴者は20人くらいで非常に和気藹々とした勉強会でした。

GMO Yours に来てます! #phpstudy
— た҉͜け҉͜て҉͜ぃ҉͜𓁈𓈷 (@takeokunn) February 15, 2023

登壇

内容について

phpstan-strict-rulesでよりbetterなphpを手に入れようというタイトルで話しました。

関連するツイートはこのあたりです。

YouTubeのアーカイブも残っているので気になる人はこちらから見てください。

https://www.youtube.com/live/k0GkmSYhtrQ?feature=share&t=7526

補足など

Emacsと申します

俺がEmacsだ

PHPStan Tシャツについて

いつぞやのイベントでたっどさんから託されたTシャツ。日本で数人しか持っていない実はレアなやつ。

日本で数人のPHPStanを着こなしている男 #phpstudy pic.twitter.com/XOW4FRp535
— にゃんだーすわん (@tadsan) February 15, 2023

`php-src` を毎朝 `git pull` していることについて

自分の好きなプロジェクトを毎朝 git pull して変更を見る行為は季節の移ろいを感じられてお勧めです。

hanhanさんの「今週の PHP」を毎週かかさずチェックしよう

hanhan さんいつもありがとう。

https://t.co/fGEjRAZuUN #今週のPHP はこちらです。 #phpstudy
— Ryo Tomidokoro (@hanhan1978) February 15, 2023

皆さんは会社や個人のプロジェクトでPHPStanを入れていますか?

会場は半分くらいの方が手を上げていました。

PHPStanのlevelは5より上か下か

会場はさらに半分くらいの方がlevel5よりも上と手を上げていました。

PHPStanを入れて良かったかどうか

おおむねみなさん手を上げていました。

初期開発でPHPStan Level Maxを選択

既存のコードがない場合ほど制約を厳しくできて良いですね、という声がちらほらありました。 TypeScriptでも noImplicitAny を有効にするには初期じゃないとできない等、既存のコードベースがあるかどうかはかなり大きいです。

Docker VolumeをCopy/Renameする方法

Thu, 09 Feb 2023 09:00:00 +0900

前提

docker volume のデフォルトの機能にcopyやrenameはありません。 https://matsuand.github.io/docs.docker.jp.onthefly/storage/volumes/

Rename docker volume #31154 というissueも立っているが、対応される見込がないです。

interfaceとして提供してくれていないだけで、実態はDocker File System内どこかにはあるはず。絶対できるはずだという前提のもと調べてみたらできたのでまとめておきます。

準備

docker engine を起動して、 docker volume を作成する。

docker volume create --name=my-volume

CopyやRenameのやり方

justincormack/nsenter1 を立ち上げる。

docker run -it --rm --privileged --pid=host justincormack/nsenter1

docker volume がある場所に移動する。

/ # cd /var/lib/docker/volumes/

/var/lib/docker/volumes # ls -la | grep my-volume
drwx-----x 3 root root 4096 Feb 9 02:59 my-volume

あとは cp をするなり、 mv をするなりでよしなに。

すぐに認識してくれないみたいなので Docker for Mac に反映するには再起動が必要そう。

VimとNeovimの使い分けと最小構成

Thu, 09 Feb 2023 09:00:00 +0900

VimとNeovimの運用方針

Twitterではずっと主張してることだが、VimとNeovimの設定は共通化しない方がよいと考えています。

次のような使い分けをしています。

Vim → サーバ用の最小設定
Neovim → 日常的な開発用

コンテナ全盛期の現代といえど、サーバに入って作業をする必要がある人も多いんじゃないでしょうか。不自由な環境でちょっとしたファイルを開いて数行変更するだけに関しては、Vimほど適したテキストエディタはないでしょう。

ただ、設定がまったくされていない素Vimでは少々厳しい場面があります。 set number relativenumber で行番号表示するくらいは欲しいものです。ちょっとしたサーバにも持っていけるような最低限の設定を持っておくとサーバ内で安心して作業できます。

一方、通常の開発でもVimを使いたいという要望はあるでしょう。現にEmacsをメインで使っている自分もフォールバック先としてNeovimを使うことが多いです。 Emacs自体は本来安定しているのですが、Emacsを毎朝 git pull してHEAD Buildしている関係であまり手元環境が安定していないです。

ヘビーカスタマイズをすると、VimとNeovim両方を考慮したコードを書くのはかなり厳しい印象があります。最新のVim事情はわかりませんが、Python製Pluginが流行っていた時かなりしんどかったです。カスタマイズをする方を完全にNeovim側に寄せることによって、Vimの場合の条件分岐が減るので考慮することが減ります。

最低限のVimの設定

次のcommandをたたけば入ります。

curl -s https://raw.githubusercontent.com/takeokunn/dotfiles/master/modules/vim/dot.vimrc > ~/.vimrc

自分が最低限必要な設定は次の30行です。

set encoding=utf-8
set fileencodings=utf-8,euc-jp,cp932
set clipboard+=unnamed
set backspace=2
set tabstop=2
set shiftwidth=2
set laststatus=2
set statusline=%y
set showmatch
set wrapscan
set hlsearch
set showcmd
set title
set number relativenumber
set cursorline
set nofoldenable
set noswapfile
set expandtab
set splitbelow
set splitright
set incsearch
set ignorecase
set smartcase

nnoremap / /\v
nnoremap <Leader><Leader> V
nnoremap <Esc><Esc> :nohlsearch<CR><Esc>

syntax on
filetype plugin indent on

ファイルを開いて文字列を検索することが多いので次の設定がお気に入りです。

aws-cliとecs-cliのconfigをorgで管理してdefault値を一切設定しない運用をする

Thu, 19 Jan 2023 09:00:00 +0900

前提

私は普段次のような条件でAWSを触っています。

AWSアカウントを複数社分扱っている
SwitchRoleで複数扱っている
手元から頻繁にコマンドをたたく

さまざまな環境で作業をしていると、「想定と違う環境に対してAPIを投げてしまう」「意図したリソースが取得できない」等さまざまなトラブルに直面します。全部CI/CDで管理をして、localからは一切なにもしないというのは1つの理想ではあるものの、そうはいかないのが現実というものです。

あらためて自分の手元の環境を見直したところ、そもそもデフォルト値を指定せずにちゃんと指定すれば事故が起きないのではという結論に至ったのでまとめておきます。

運用方法

org fileですべてを管理する

そもそも設定がゴチャゴチャしたり、ミスをしたり、間違ったコマンドを流してしまうのはどうしてでしょうか？答えは簡単で、明示的にコマンドや設定ファイルを用意していないからです。

普段使う設定やコマンドをドキュメントとして管理をし、明示的に変更を加える運用にすれば事故ることが格段に減ります。

その為のツールとしてEmacsのorg-modeはおあつらえ向きです。 Markdown同様手軽に文章を書け、分割した設定も管理でき、ファイルに出力でき、 org-babel を使えばコマンドを実行できます。

たとえば次のようにコードブロックを作って org-babel すると RESULTS に結果が出力されます。

#+begin_src shell
echo "hello world"
#+end_src

#+RESULTS:
: hello world

また、秘匿情報を扱う場合は sandbox.org.gpg のように接尾辞に .gpg をつけるとEmacsが勝手にEncryptしてくれるのでセキュアに管理できます。私はprivate repoでこのような秘匿情報をorg fileで管理しています。

aws-cli周り

~/.aws/config は次のように org-mode で管理をしています。 :noweb-ref でimportできるようにして、 :tangle で出力先を設定し、 M-x org-babel-tangle でファイルを出力するようにしています。

~/.aws/config と同様 ~/.aws/credential も org-mode で管理をしています。

デフォルト値を一切設定しない 運用にしています。

* aws
** config
*** alice
#+begin_src conf :noweb-ref aws-config-alice
 [profile alice]
 source_profile = alice-dev
 role_arn = arn:aws:iam::xxx
 region = ap-northeast-1
 output = json
#+end_src
*** bob
#+begin_src conf :noweb-ref aws-config-bob
 [profile bob]
 region = ap-northeast-1
 output = json
#+end_src
*** all
#+begin_src conf :noweb yes :tangle (expand-file-name "~/.aws/config") :mkdirp yes
 # alice
 <<aws-config-alice>>

 # bob
 <<aws-config-bob>>
#+end_src

コマンドを流す時は次のようにいったんorgファイルに記述したうえで org-babel なりterminalなりで実行するようにしています。 aws コマンドは --profile オプションがあり、 必ず指定 するようにしています。

PHP8から追加されたJITについて学ぼう!

Thu, 22 Dec 2022 09:00:00 +0900

始めに

2023年現在、PHPは世界中の企業で使われており、もっとも成功しているプログラミング言語の1つと言っても過言ではないくらい開発者から愛されています。 WikipediaやWordPressもPHP製のプロダクトですので、開発者でなくてもPHPの恩恵を受けている人は多いでしょう。

私も5年以上PHPを用いて開発していますが、日進月歩で進化し続けるPHPにワクワクさせられています。

PHP 8.0が2020年11月にリリースされ、さまざまな便利な新機能が追加されました。特に Match式 は複雑な条件分岐を「式」で書くことができ、より柔軟な記述が可能になります。

高く評価されている新機能の1つに JIT (ジャストインタイム) コンパイラ があります。 JITを正しく使うと、条件によってはアプリケーションの1.5倍以上高速化できるということを公式のリリースページに書いてあります。

そもそもJITとは何か、PHP上でどのようにJITが動作しているのかを知れば、アプリケーションの記述を変えずに高速化できるでしょう。

JITについての概要

JIT自体の歴史は長く、さまざまな言語の処理系で実装されています。 JavaScriptの処理系であるV8 EngineもJITを導入することによって大幅な高速化を実現しました。

Ruby 3.1ではYJITが導入されました。 YJITはShopify社製のJIT Compilerで、同社はRailsアプリケーションが 20%~40% 程度高速化できたという報告をしています。

私の普段使っているEmacsでもJIT Compilerがサポートされて、体感速度として感じられるくらい動作がサクサクになったという実感があります。

PHP、Ruby、JavaScriptのような動的型付き言語は、CやRustのような静的型付き言語よりも実行速度が遅いです。遅い理由は様ありますが、実行時に字句解析、構文解析、コンパイルをして中間コードを吐き出し、VM上で実行をしているのが原因です。変数や関数の型情報の多くは実行時に決まり、実行時にVM上で最適化が走るので、どうしても遲くなってしまいます。

高速に実行するアプローチの1つにJIT Compileがあります。 JIT Compileは実行時にマシンコードを吐き出し、キャッシュ上に乗せ、再度実行する時にキャッシュ上のマシンコードを実行するというアプローチです。マシンコードにすることによって、中間コードにわざわざ変換をしてVM上で変換をする必要がないので高速に動かすことができます。

ちなみに、JITの対比として、C言語のような事前にコンパイルする通常の手法はAOT（Ahead-Of-Time）コンパイルと呼びます。

JIT Compilerの実装挟まざまありますが、PHPではDynASMを使っています。 DynASMはLuaでも使われており、すでに実績を残しています。

PHPのJITの基本的なしくみ

2023年1月現在、JITはOPCacheのサブセットとして提供されています。 OPCacheとJITの立ち位置について解説していきます。

PHPのみの場合

PHPは通常、図のような処理が行われます。

字句解析で文字列をトークン化、構文解析で opcode を含む構文木（AST）を作り、VM上で実行をする、というフローをたどります。

opcode は中間コードのことであり、VMで解釈できるような命令セットのことです。 VMの仕事は中間コードを読み込み、最適化したうえで処理を実行をすることです。

PHPのVMは ZendEngine と呼ばれており、ZendEngineがCPUアーキテクチャ間の際を吸収しています。私達が普段 M1 Mac でも Intel x86 でも同じコードから同じ実行結果を得られるのは ZendEngine があるからこそです。

通常PHPは実行時にこれら一連の処理を毎回行っています。 PHPサーバのプロセスを再起動せずにコードが反映されるというメリットがあります。しかし、毎回一連の処理をするのは非効率です。

適切にcacheを効かせて実行時の処理を減らす機構こそがOPCacheです。

OPCacheの場合

OPCacheを有効にすると、図のような処理が行われます。

sitemap.xmlからURLを良い感じに抽出してPlaywrightでUIを目視確認する

Thu, 22 Dec 2022 09:00:00 +0900

やりたいこと

フレームワークや言語のバージョンを上げたり、UI周りのリファクタリングをした際に、500やデザイン崩れがないかを確認したい。理想をいうとxUnitのようなテストコードを書いたりする方がよいのだが、テストコードを書くと工数が非常にかかるし、もともとテストコードがない環境だとしんどい。

また、テストコードでは当然UIの目視確認まではできない。

サクっと主要なページを目視で眺める方法ないかなと考えてたところ、「確認したいページリストを sitemap.xml から生成してよい感じに自動でスクロールすればよいのでは。..?」ということを思いついたので書いていく。

特に拘泥がなかったので 2021年現在、Puppeteerを使う理由はなくなった。Playwrightを使おう。を読んでPlaywrightを選んだ。

ソースコード

必要packageは次の3つ。

$ npm install playwright
$ npm install axios
$ npm install xml2json

コード全体像は以下。

const axios = require("axios");
const parser = require("xml2json");
const { chromium } = require("playwright");

const BASE_URL = "<edit your url>";

const fetchSitemap = async () => {
 const res = await axios.get(`${BASE_URL}/sitemap.xml`);
 const body = JSON.parse(parser.toJson(res.data));
 return body.urlset.url.map((url) => url.loc);
};

const filterSitemapUrls = (urls) => {
 const cb = (path) => {
 let count = 0;

 return (url) => {
 if (!url.match(path)) return true;
 if (count === 3) return false;

 count++;
 return true;
 };
 };

 return urls
 .filter(cb(/posts\//))
 .filter(cb(/articles\//));
};

const evaluateScript = async () => {
 const delay = (ms) => new Promise((resolve) => setTimeout(resolve, ms));
 for (let index = 0; index < document.body.scrollHeight / 10; index += 100) {
 window.scrollTo(0, index * 10);
 await delay(1000);
 }
};

const runSitemapScenarios = async (page) => {
 const urls = await fetchSitemap();
 for (const url of filterSitemapUrls(urls)) {
 await page.goto(url);
 await page.evaluate(evaluateScript);
 }
};

const main = async () => {
 const browser = await chromium.launch({ headless: false });
 const page = await browser.newPage();

 await runSitemapScenarios(page)

 await browser.close();
};

main();

解説

<base_url>/sitemap.xml を axios で取得し、 xml2json でxmlをjsonに変換後、playwrightで下までスクロールする。ただ、純粋に sitemap.xml をすべて眺めるのは厳しい。 /articles/<id> のような動的に生成されたページをすべて見るのは無駄だ。

Emacsを世界最速級で起動する方法

Sat, 17 Dec 2022 09:00:00 +0900

Emacs Advent Calendar 2022 19日目です。

Vim Advent Calendar 2022 3日目の爆速で起動する Neovim を作るに触発されて、「自分もEmacs版を書くぞ！」ということで書いていきます。

なお、VimとEmacsの比較をし易くするためになるべく文章の構成を寄せて書くことをご了承ください。

始めに

「Emacsを高速に起動する」ということに対して、多くのEmacsユーザーは興味がありません。本来Emacsというのは常に起動し続けるものであり、必要に応じてEmacs Lispを適用し、テキストエディタをカスタマイズしていくものです。現に「Emacs, 起動、高速化」と検索すると、「4000msを1000msにした」のような秒単位での高速化の記事ばかりみつかります。

もしあなたが設定を変えずに手軽に高速に起動したい場合は emacs --daemon でdaemonを立ち上げ、 emacsclient でつなぐようにすればよいでしょう。私は他人のdotfilesを読むのが趣味なのですが、多くのEmacsユーザーは EDITOR=emacsclient と設定しています。

また、起動時間のみを考慮するなら ~/.emacs.d/init.el を削除して素で起動すればよいでしょう。そうなると純粋にマシンスペックの勝負になります。 Emacsは素の状態でも十分魅力的な機能を多数盛り込まれているが、カスタマイズしてこそ真価を発揮するエディタなのでアプローチとしてはイマイチでしょう。

この記事を読む前に Emacs の起動時間を"“詰める”" を熟読することを推奨しています。特に次のChapterは非常に有益なテクニックが詰め込まれており、大幅な速度改善を見込めます。

本のあらすじにも書いてあるとおり、Emacs自体にすでに大量のファイルがある状態で高速に起動する時点で自分の設定を見直さなければならないことは明白でしょう。

しかし、考えてみれば Emacs には 1000 以上の Emacs Lisp ファイルが初めから同梱されているわけで、そこに数十のプラグインを足しただけで爆裂に遅くなるのは、なにか設定にも問題がある気がします。

詳細は後述しますが、現在の私のEmacsは15〜25ms程度で起動をします。一切設定を読まずに素で起動するコマンド emacs -Q で起動させると2ms程度です。まだまだ高速に起動させる余地はありますが、「高速に起動させることができている」と自負しても問題ないでしょう。

Emacs booting time: 20 [msec] = ‘emacs-init-time’.
Loading init files: 10 [msec], of which 1 [msec] for ‘after-init-hook’.

前提

環境

2022年12月現在、 Macbook Pro 16-inch, 2019 の標準モデルを使っています。

aws-sdk-php v3.245.0でBC breakをおこす

Wed, 14 Dec 2022 09:00:00 +0900

結論

aws-sdk-php の v3.245.0 で AwcClient のconstructorの引数が変わった
SqsClient などの継承しているclassにも影響が出る
Composer.jsonで "aws/aws-sdk-php": "^3.0" のように指定しているとversionが上がって事故る

現象

2022年11月に aws-sdk-php の v3.245.0 がリリースされた。

https://github.com/aws/aws-sdk-php/releases/tag/3.245.0

リリース内容の中にFeature bearer token #2517という変更があり、これによって AwsClient の記述のし方が次のように変わる。

before:

$client = new AwsClient([
 'version' => 'latest',
 'region' => $_ENV['AWS_REGION'],
 'credientials' => [
 'key' => $_ENV['AWS_ACCESS_KEY_ID'],
 'secret' => $_ENV['AWS_SECRET_ACCESS_KEY'],
 'token' => $_ENV['AWS_SESSION_TOKEN'],
 ]
]);

after:

$client = new AwsClient([
 'version' => 'latest',
 'region' => $_ENV['AWS_REGION'],
 'token' => $_ENV['AWS_SESSION_TOKEN'],
 'credientials' => [
 'key' => $_ENV['AWS_ACCESS_KEY_ID'],
 'secret' => $_ENV['AWS_SECRET_ACCESS_KEY'],
 ],
]);

AwsClient はいろいろなbase classとなっているので呼び出し方に注意が必要になってくる。

https://github.com/aws/aws-sdk-php/search?q=%22extends+AwsClient%22

fluent-bitに入門する

Wed, 07 Dec 2022 09:00:00 +0900

始めに

複数のサーバを管理すればする程、loggingの重要性が高まります。特に2022年はコンテナ最盛期と言っても過言ではないくらいコンテナ化が進んでいています。

logを適切に扱うことができればできるほど、運用の質を上げることができます。

fluent-bitとは

fluent-bitは高速なlogging libraryです。

https://github.com/fluent/fluent-bit

FluentdはRuby実装で、fluent-bitはC実装です。シングルバイナリで提供できるので、Dockerではfluent-bitの方を用いられることが多いです。

fluent-bitと調べてもあまりまとまった情報がなく、非常にとっつきにくいので後学のためにまとめておく。

環境構築

fluent-bitをDockerで動かすを参考に作るとよい。

どうやって詳しくなっていけばよいか

fluent-bitは input parser filter routing 部分を弄ることになる。

それぞれ次のドキュメントに細かく書いてある。 https://docs.fluentbit.io/manual/pipeline/pipeline-monitoring

input値挟まざまな値を取ることができる。

https://docs.fluentbit.io/manual/pipeline/inputs/dummy

input値を変えてみたり、filterやoutput（routing）を変えながらどのように風に変化するか弄ってみるとよい。

fluent-bitをDockerで動かす

Wed, 07 Dec 2022 09:00:00 +0900

プロジェクト構成

次のように適当なディレクトリを作成する。

$ tree .
.
├── Dockerfile
├── application.conf
└── docker-compose.yml

0 directories, 3 files

Dockerfile:

FROM public.ecr.aws/aws-observability/aws-for-fluent-bit:2.21.3

COPY application.conf /fluent-bit/etc/application.conf

docker-compose.yml:

version: "3.8"
services:
 fluentbit:
 build: .
 command: ["/fluent-bit/bin/fluent-bit", "-c", "/fluent-bit/etc/application.conf"]
 volumes:
 - ./application.conf:/fluent-bit/etc/application.conf

application.conf:

[SERVICE]
 Flush 5
 Log_Level info

[INPUT]
 Name dummy
 Tag *-firelens-*
 Dummy {"date":"2022-01-23T03:10:33.317817Z","source":"stdout","log":"time:2022-01-23T03:10:33+00:00\tprotocol:HTTP/1.1\tstatus:200\tsize:1450\treqsize:150\treferer:-\tvhost:10.10.18.102\treqtime:0.176\tcache:-\truntime:-\t"}

[OUTPUT]
 Name stdout
 Match *

実行方法

docker compose up を立ち上げると上記の [INPUT] に記述したdummyのinputが出力される。

$ docker compose up

fluent-bit-sandbox-fluentbit-1 | [0] *-firelens-*: [1668664184.902488203, {"date"=>"2022-01-23T03:10:33.317817Z", "source"=>"stdout", "log"=>"time:2022-01-23T03:10:33+00:00 protocol:HTTP/1.1 status:200 size:1450 reqsize:150 referer:- vhost:10.10.18.102 reqtime:0.176 cache:- runtime:- "}]
fluent-bit-sandbox-fluentbit-1 | [1] *-firelens-*: [1668664185.900364801, {"date"=>"2022-01-23T03:10:33.317817Z", "source"=>"stdout", "log"=>"time:2022-01-23T03:10:33+00:00 protocol:HTTP/1.1 status:200 size:1450 reqsize:150 referer:- vhost:10.10.18.102 reqtime:0.176 cache:- runtime:- "}]
fluent-bit-sandbox-fluentbit-1 | [2] *-firelens-*: [1668664186.900453923, {"date"=>"2022-01-23T03:10:33.317817Z", "source"=>"stdout", "log"=>"time:2022-01-23T03:10:33+00:00 protocol:HTTP/1.1 status:200 size:1450 reqsize:150 referer:- vhost:10.10.18.102 reqtime:0.176 cache:- runtime:- "}]
fluent-bit-sandbox-fluentbit-1 | [3] *-firelens-*: [1668664187.900391678, {"date"=>"2022-01-23T03:10:33.317817Z", "source"=>"stdout", "log"=>"time:2022-01-23T03:10:33+00:00 protocol:HTTP/1.1 status:200 size:1450 reqsize:150 referer:- vhost:10.10.18.102 reqtime:0.176 cache:- runtime:- "}]

解説

特に何も指定せずに docker compose up をすると /fluent-bit/bin/fluent-bit -c /fluent-bit/etc/fluent-bit.conf で起動をしている。

2021年に自分がemacs.dのカスタイマイズしたことについて

Fri, 03 Dec 2021 09:00:00 +0900

Emacs Advent Calendar 2021 5日目の記事。

今年もtakeokunn/.emacs.d をかなり改造した。 git log --reverse してみるとfirst commitが Sat Nov 3 18:15:51 2018 +0900 のようなので3年使っているようだ。

最初と比べて圧倒的に快適になってはいるものの、分からないことが増えていく一方だ。とはいえ使っていくうちに理解が深まっていくのも事実。ざっくりやったことについてまとめていく（去年やったことも含まれているが御愛嬌）

emacs28にしてlibgccjitを動かした
- defaultのcompilerをllvmからgccに変えるとスマートフォンアプリケーション開発やら別の開発に影響が出るので動かしただけ
use-packageからleafへの移行した
- caskを消した
- 遅延ロードになったおかげで起動が高速になった
orgでinit.elを生成するようにした
- Makefile 参照
GitHub Pagesで見られるようにした
- https://takeokunn.github.io/.emacs.d/
byte-compileをできる限りでするようにした
- 多少のwarningは無視している
ddskkを実用レベルでちゃんと使えるようにした
- ddskkの設定はdotfilesで管理している
- AZIKを完全に理解した
company周りの設定が増えた
wanderlustで自分のGmailを操作できるようにした
- しただけでちゃんと運用できているわけではない
elfeedを充実させた
- しただけでちゃんと運用できているわけではない
magitを使いこなせるようになった
- magit-forgeでGitHubにPull Requestを投げられるようにした
dap-modeを使えるようになった
- なっただけ
yasnippetの設定が増えた
- snippetをorgで管理するようにした
  - https://github.com/takeokunn/.emacs.d/blob/master/yasnippets.org
- snippet自体も増えた
- ivy-yasnippetで検索できるようにしている
- ついでにAndreaCrotti/yasnippet-snippetsにPull Requestを投げたが音沙汰がない
  - https://github.com/AndreaCrotti/yasnippet-snippets/pull/434
  - https://github.com/AndreaCrotti/yasnippet-snippets/pull/433
tab-modeを使えるようになった
- が、実用性あるのか….?っていなっている
fish scriptの開発環境が整った
- takeokunn/fish-repl.elを作った
- takeokunn/ob-fish を作った
org-modeの設定が増えた
- 日常的なメモはorgで書くようになった
- org-Babelを使いこなせるようになった
- 工数管理とか細かい使い方がいまだに分らない
英語の執筆環境が整った
- flycheckとtextlintをちゃんと設定した
言語ごとの開発環境を整えた
- php, golang, solidity etc…
TypeScript reactはtreesitterとlspでなんとかするのが最適だと分かった
M-x の候補だがsmexからamxに変えたら欲しい候補が出るようになった

ざくっと思い出せるのはこれくらいなのでまた何かあれば追記をしていくつもり。来年はorg-modeを使いこなせるようになりたいなぁ。

TwitterUIDの挙動とJavaScriptのBigIntについて

Wed, 28 Oct 2020 09:00:00 +0900

TwitterのUIDについて調べてたら、自分の浮動小数点の挙動についての理解度が低かったので調べたことについてまとめておく。

ことの発端は、spreadsheet上の人力で管理されているTwitterのユーザー情報をデータベースに入れる作業をしていた時だった。

以前同じような作業をしたとき結構漏れがあったので、Twitter UIDの妥当性やscreen nameが本当に存在するかどうかを確認する必要があった。

TwitterのIDチェッカーなどのWebサイトを利用してもよかったが、100件を超える量のデータを手動で確認取るのは面倒だったため、次のような検証scriptを雑に書いた。

#!/bin/bash
while read row; do
 TWITTER_ID=`echo ${row} | cut -d , -f 1`
 TWITTER_UID=`echo ${row} | cut -d , -f 2`
 TWITTER_REQUEST_UID=`curl -X GET -H "Authorization: Bearer <TWITTER_TOKEN>" -s "https://api.twitter.com/1.1/users/show.json?screen_name=${TWITTER_ID}" | jq ".id"`
 if [ ${TWITTER_REQUEST_UID} -ne ${TWITTER_UID} ]; then
 echo "${TWITTER_ID}: ${TWITTER_UID} → ${TWITTER_REQUEST_UID}"
 fi
done < ~/Desktop/twitter.csv

そうしたら半分くらいのTwitter UIDがずれてしまった。明らかにおかしいと思ったので、きちんと調査することにした。

Twitter Developer Documentに Twitter IDs という記事がある。

https://developer.twitter.com/en/docs/twitter-ids

次のようなことが書かれていた。

ユーザーの増加によりTwitterのUIDは64bit
unsignedでuniqueな値として管理されている
JavaScriptの整数のサイズは53bitに制限されている
api responseでは整数(id)と文字列(id_str)の両方を返すような実装になっている

ここから分かるのは、自分は↑のshell scriptで id を見ていたから正しい値をとれていなかった、~~id_str~~ を使うべきだったことが分かる。

たしかに、次のように toString() をしたらずれることについて確認がとれたがどうしてだろうか。また、今回はbash scriptを書いたのにJavaScriptと同じ挙動をするのはどうしてなのか調べる必要がある。

MacBookProの生前整理をする

Sat, 03 Oct 2020 09:00:00 +0900

不要な情報の削除

まずは整理整頓の基本である不要なモノを捨てるところから。次のような手順を踖んだら容量カツカツ状態から62GB開けることができた。

hardlink.pyを使ったらディスクの空き容量が劇的に増えたこういうのもあるが今回は使わない。

不要repoの削除

僕はすべてのソースコードをghqで管理している。snippet的なコードは適当なファイルやディレクトリを作って書き、終わったらブログにまとめてから削除するという運用をとっている。

気になるrepoはすぐにghq getでcloneして容量を食いまくっていたので、次のscriptでガンガン削除していった。

$ ls ~/.ghq/github.com | peco | xargs rm -fr
$ ghq list --full-path | peco | xargs -L1 rm -fr

不要なbrew packageの削除

勢いでbrew installしたpackageなどが相当あったのでいらないものは削除していった。

$ brew list | peco | xargs brew uninstall

不要なnpm/go/gem packageの削除

普段 npm i -g xxx や go get -u xxx や gem install xxx などで気軽にpackageをいれてたので削除していった。

chromeのcacheやextensionの削除

意外と大事。新しい環境でも同じ体験ができるように一度消してみるのもよいだろう。

bookmarkなどは一切使わなく、url barに直接入力する運用をとっているので削除した直後は不便にはなるが、何が必要なのか分かるのでそれはそれでよい（パスワード周りとか特にそう）

Docker関係の整理

Dockerのあれこれを断捨離するこの記事がすごい良かった。Dockerは再現性のある環境なはずなので一度すべてを消してもよいだろう。

このへんを適当にたたくとだいたい消えてくれる。

$ docker ps -q | xargs docker rm -f
$ docker images -q | xargs docker rmi -q
$ docker system prune
$ docker image prune
$ docker container prune
$ docker volume prune

不要なDesktop Applicationの削除

入れたはよいけど使わなかったものは多いだろう。必要ならまたinstallすればよいのでいったん消すというのもあり。VSCodeなどを削除した。

新人教育をしていて一番大事なのは「試行回数」だと思った

Sat, 03 Oct 2020 09:00:00 +0900

3ヵ月~半年くらいで普通の社員と遜色ない人もいる。数年やっても向いてないんじゃないかというくらいできない人もいる。少しずつ着実に成長している人もいる。

新人教育を1〜2年10人くらいやっているのだが、いったい何が違うんだろうとずっと思い続けてきて、ようやく自分なりにまとまってきたので書いておく。

前提

新人とはプログラミング経験年数2年以下くらいのWebエンジニアの初心者を想定している（自称初心者ではない）

今勤めている会社では大学生インターンや未経験のような新人を積極的にとってきた。自分はお節介を焼くのが趣味であり、勝手に教えてたら（知識をひけらかしてたら）思ったよりも成長してくれる人が何人かいたし、逆もまた然り。

最近はAWS業務やrailsを書きつつ新人の育成が仕事になっている。

僕自身は所々で教えてくれる人はいたものの、ちゃんと「教育」をされたことがないのでよくわらないし、コーチング技術なんてものはわからないし、脳筋なのでフィーリングで書いていく（大学は情報科いたけど中退しちゃったので専門的なことはわからん）

新人教育はなんでやるの？

ジュニアを採用しない連中はシニアに値しないという記事にまとまっている。

エンジニア人口が増えることは人手不足のIT業界にとってよい影響を与え、またOSSにも貢献できるだろう（利用することも貢献の一種）。

幸いなことに、今の会社はそれなりにちゃんとしたエンジニア組織があり育成環境もあるのでちゃんと育成すればワークする。母数の少ないシニアエンジニアを採用をするのは難しいので、育成するという選択を取るというのもそれはそれで正しい判断だろう。

個人的には、自分の仕事を ~~押し付けられる~~ できる人材が増えると自分の時間が空くので、別の技術に時間を投資できるようになると思っている。

一番大事なのは試行回数

どの分野でもそうなのだが、結局の所「試行回数を増やせば増やすほど成長をする」ので「試行回数を最大化する」ように取り組むことこそ最善だろう。

試行回数に関して明確に定義はできないが、「目の前の問題を解決した回数」や「言語やライブラリの仕様を理解すべく取り組んだ回数」などを想定している。「Rubyの四則演算を学ぶ」のと「Rubyのcompilerの実装を読む」のようなレベル差があるものを同等に扱うべきではないが、いったん無視する。

急速に成長する人は上手に試行回数を増やす方法を知っており、それを忠実に実践できる。そうではない人この限りではない。

試行回数を増やすには次のような取り組みが考えられる。

問題に取り組む時間を増やす
既知の問題から推測できるように既知の問題の理解を深める
常に最新の情報をキャッチアップできるしくみを作る
shellやエディタをカスタマイズし効率的に検証できるようにする
必要な情報を取得するために効率的に検索をできるようにする
ショートカットキーを駆使し余計な時間を使わないようにする
小さく検証できる環境を用意する
健康的な生活をして集中的に取り組めるようにする
友人や知人にプログラマーを増やし、教えてもらえる環境を作る
PCの画面を広く使う
ひたすらコードを書いて検証する
自分の得た知識が正しいかどうか他者に説明して検証する

いかに余計なものを排除して試行回数を稼げるかがもっとも重要だ。

新人にはざっくり4タイプくらいに分けられる

なんとなく自分の中で4タイプに分けて、それぞれに合った方法で教える。

別分野ですでに一定の技量があるタイプ

すでに別分野でスキルの身につけ方を知っていて、Webプログラミングにも応用できるような人。

そもそも別分野で知識を深める方法や試行回数を増やす大事さを知っているので勝手に勉強して勝手に伸びるので、こちらから教えることはそんなになくて非常に楽。

難しい文章を読むのにも抵抗がないので、すぐに普通のプログラマーを追いこす場合が多い。

高負荷に耐えられ、時間で殴れるタイプ

一番教えて楽しいタイプ。

時間で殴れるので、新しい知識やツールを試す回数が非常に多い。成長がめちゃくちゃ速い。

高負荷に耐えられるので仕事を大量にこなせるし、Twitterや社内の技術的な情報のキャッチアップも難なくこなせる。

高学歴や高専出身が多いイメージ。

普通のタイプ

普通にプログラミングを仕事にして、普通に勉強をしているタイプ。

プログラミングのためだけに生活しているわけではなく、プライベートも重視しているケースが多い。

Twitterにはプログラミングの休憩がてらコード書く狂人だらけだけど、real worldでは普通のタイプが一番多い。

教える時は情報量をしぼってパンクしないように気を付ける必要がある。

まったく向いていないタイプ

自分なりのやり方に異常に固執したり、こだわりが強い（の割りにデタラメなことをいう）人や、そもそもプログラミング好きではない人だ。

申し訳ないが、まったく向いていない人は一定数いる。

しょうがない、向いてないのはしょうがないので本人の希望によるけど向いていないものはしょうがない。

もしかしたら何か別の才能があるだろうし、別の指導者の元の方が大成だろうし頑張ってほしい。

新人にはどうなってほしいのか

会社的には「さっさと業務を一人前でこなせる人材になってほしい」というのが本音だろう。

個人的には上記のとおり、「試行回数を最大化するための取り組みを自分で考えて実行してほしい」と思っている。ツールにこだわるのも1つの方法だし、業務でタスクをこなすのも大事。

「先輩に聞くのは申し訳ないかな。..?」と考える必要はまったくなく、それが必要なら躊躇するべきではない。

多くのエンジニアは3年くらいで転職するので、きちんと職務経歴書に書くことがある状態にしてほしい。いつでも転職できるくらい選択肢をもている状態にしてあげたい。

普段自分が教える時に試していること

まずは何にせよ信頼関係を築くことから始まる。これほど大事なものはない。どんなに技術的に正しいこと、成長に必要なことを熱弁しても信頼関係がなければ何も始まらない。なので雑談をしたり、食事に行ったりして兎に角仲良くなることが大事だ。

自分が1人に教えられるのは精々週に2時間くらいで、それ以外は基本的に本人が頑張る時間だ。問題を取り組む時障害になる部分をなるべく排除するべく、まずは次のようなことをやっている。

fish shellなどの便利ツールを入れる
dotfilesを作らせる
便利なショートカットキーを教える
よい記事にたどり着けるような検索wordの作り方を教える
slackのfeedのチャンネルを教えるたり、お勧めのブログを教える

慣れてきたら次のことを意識して指摘している。

半年間毎週dependabotをmergeしたので知見を纏める

Wed, 09 Sep 2020 09:00:00 +0900

Railsプロジェクトのdependabotをひたすら毎週月曜日の11時にmergeし続けて半年以上たったのでそろそろ知見をまとめておく。

始めに

世の中のライブラリには大きく分けて3種類ある。

フレームワークと開発支援ツールと通常のライブラリだ。

基本的に全部のdependabotの生成したPull Requestに関して、CHANGE LOGとコードレベルのdiffを読むようにした。 CHANGE LOGだけでも良かったのだが、多くのOSSのライブラリのversion upはどのような場合に起こるのかなど傾向をつかむためだ。

diffの読み方

変更頻度の高かった順（takeokunn調べ）に並べるとこんなかんじ。

テストの追加
CI関連の記述の追加
ドキュメントの整備
命名の修正
関数の分離や引数の整理
新機能の実装

業務では有名ライブラリ使っていた影響か、保守的な変更が多かった。

最近だとblacklistが駄目だとかその辺の変更がめちゃくちゃ多かった印象。

事故るとしたら「命名の修正」と「関数の分離や引数の整理」の部分だけなのでそれ以外は読み飛ばしても基本的には大丈夫だ。

フレームワークの場合

railsやlaravelなど。

必ずRELEASE NOTEを読んで注意深くあげるようにする。

マイナーバージョンアップの場合（ver5.1.1→ver5.1.2）はそこまで神経質にならなくてもよい。

メジャーバージョンアップの場合（ver5.2→ver6.0）はテストを充実させる、ステージング環境での十分な検証が必要だ。それでも細かいバグがでるので本当に神経質に確認を取る必要がある。

こういう時にphpstanなどの静的解析でぱぱっと検証できるのが理想。Railsにはそういうのがないからつらい。

通常のライブラリの場合

FaradayやらDeviseなど。

CHANGE LOGをみてBreaking Changeがなければmergeしちゃってよい。

そんなに破壊的変更を入れるライブラリはなかったし、事故もおきなかった。

テストで検知できるようにはしておきたい。

開発支援ツールの場合

rubocopやらeslintなど。

基本的にノールックマージしてよい。事故ってもCIが落ちるだけなので別にオッケー。

rubocopはよくconfigの書式がかわったりするのでなるべく頻度高く上げておかないとあとあとしんどくなる。

終わりに

当たり前のことしか書いてないが、当たり前のことを当たり前にやろう（自戒）

バージョンを一気にあげるのは本当にきついので普段から上げることをサボらないようにしないとしんどい（しんどい）。

どのプロジェクトにも必ずdependabotはいれたいなーと思5つ、CIを圧迫するのだけはなんだかなぁと。

RedashのQuery一覧を保存する方法

Mon, 11 May 2020 09:00:00 +0900

仕事でRedashの情報を保存したいという要望があった。

AMIをとるのは大げさだよなぁと思ったのでqueryの一覧を取得する方法について調べてみた。

とりあえず世の中に同じようなことを考えている人がいないかを調べてみた。

redashmanを使ってRedashのクエリをお手軽にバックアップするという記事があった。ariarijp/redashmanというgolang自作ツールを介してRedashAPIを叩いているようだ。

Redash APIのドキュメントはこれだ。Integrations and API。

queryのCRUDとdashboardのCRUDが用意されている。api tokenを発行してそれを使えば楽に操作ができるようだ。

ariarijp/redashmanはすごく良さそうなのだが、自分が欲しいのはqueryの一覧であって豪華なAPI Clientではない。

Golangを入れることすら面倒くさいのだ。

今回の用途では雑にcurlで取得できればよかったので次のように投げた。あとは必要なフォーマットに合わせてよしなにjqを使えばよい。

$ curl "https://<redash url>/api/queries" \
 -H "Accept: application/json" \
 -H "Authorization: Key <auth key>" \
 | jq ".results" | jq "map({ id, name, query })"

responseはこんな感じ。きれいに出せた。

[
 {
 "id": 13,
 "name": "ユーザ一覧",
 "query": "select * from users;"
 },
 {
 "id": 12,
 "name": "ユーザ詳細",
 "query": "select * from users where id = 1;"
 }
]

エンジニア採用面接で考えていること

Sun, 02 Feb 2020 09:00:00 +0900

これはポエムです。

個人的意見だし、エンジニアの採用面接専門で雇われているわけじゃないので詳しいことやベストプラクティスはわからないです。会社の方針と違う部分もあるし。

2020年2月時点でカジュアル面接/1次面接のときに僕がやっていることについて書いていく。

基本方針

大事なのは次の4点な気がしている。

コミュニケーションはつつがなく取れそうか
技術が好きか
誠実かどうか
現職（前職）について明瞭に説明できるかどうか

これらを知るためにいろいろな質問をしていく。

ぶっちゃけ趣味なり仕事なりで作っているものを楽しそうに話してもらえるのが一番。

やること

下準備

人ことの方からもらった事前情報を読み込む
SNS（GitHub/Twitter/YouTube/note/instagram/facebook/wantedly/connpass等）を探す
GitHubに公開しているコードを読む
Qiitaや技術ブログを読む

GitHubや技術記事を公開していないと事前情報がまったくなく判断しづらい。

Fish Shellに次のようなfunctionを作って一気にrepoをcloneできるようにしている。

function ghq_all
 curl "https://api.github.com/users/"(echo $argv)"/repos" | jq -r ".[].clone_url" | xargs -L1 ghq get
end

技術ブログやサイトをホスティングしている際は、whoisを読んだり、digったり、DOMを読んだりNetworkを読んでどのように配信しているのかを見る。 WordPressだったら /wp-admin /readme.html がたたけるかどうかなど、セキュリティ意識できているかも見る。

当日面接

自社説明はテンプレで話すが、それ以外で話す内容は以下。

現職（前職）どんな仕事をしているのか
好きな、得意な技術は何か
直近楽しかった開発は何か、どうやったのか
今後どのような風になりたいのか、それに向けてどのような努力をしているのか

事前情報を元に↑の内容を話す。

現職(前職)どんな仕事をしているのか

業務のどの部分を担当していて、そこで使われている技術は何か、どのような工夫をしているのかなどを明瞭に話せるかどうかを知りたい。

普通に開発しているだけよりも、開発体験向上について考えてることを行っている方がよい。

職業Webエンジニアにおける「実績」と「やりきる力」によいこと書いてある。定期的に読み直している。

好きな(得意)技術は何か

「Rubyに自信がある」と書いてあったら、それは「Rubyの言語自体に自身がある」のか「RailsのFW自体に自身がある」のか、「Railsを使うの自信がある」のかを正確に知りたい。

用語を正確に使えているのかどうかと、それに対しての知識がどのくらい深いかどうかと、そのことに対してどのくらい自覚があるのかを見る。

直近楽しかった開発は何か、どうやったのか

技術が純粋に好きか、楽しく開発しているということは技術的チャレンジをしている可能性が高いのでなるべく聞くようにしている。

今後どういう風になりたいのか、それに向けてどういう努力をしているのか

「勉強中です」っていうのは情報量0ですので、「何の勉強をしていて、どのようなロードマップがあって、今どこなのか」みたいな話をしてもらえると理解しやすい。

面接振り返り

話したことを振り返る
社内の面接評価基準と照らし合わせて評価を作成する
まとめて人ことの方に伝える

一緒に働いて楽しそうか、活躍できそうかどうかなど社内の面接指標に合わせて評価をする。

まとめ

1回の面接に結構エネルギーを使うけど、いろんな人いるんだなぁっていうのがわかって結構楽しい。

あと落ちたからといって、必ずしもスキルが足りないとかいうわけでもなく、枠がなかっただけの場合もあるのでいちいち落ち込む必要ないんだなぁってのがわかってよかったです。

開発体験向上について考えてること

Mon, 30 Sep 2019 09:00:00 +0900

会社での仕事の大半はDX向上な気がしているので、普段やっていることについてまとめていく。

DX: Developer Experience （開発体験）は重要だにDX向上のメリットについて書いてあるのだが、具体的な作業は何かについて書いていないので自分なりのやり方を書いていく。

最近ずっとRailsばっかだったので、Railsプロジェクトをイメージして書く。

環境構築をなるべくDockerできるようにする
再現性の高い環境構築手順を作成する
Editorconfigを入れる
インフラ構成を整理する
安全にDeployできるようなしくみを作る
CircleCIなどCIサービスを入れる
GitFlowを入れる
明らかに使っていないファイルを削除する
使用している外部サービスを洗い出しておく
ソースコードに埋め込まれている鍵をenvに移す
Sentry などエラーを検知できるしくみを導入する
Linterを入れて変更を少なく定期的に修正していく
RSpecのようなテストツールを入れる
dependabot を入れる
pull pandaを入れる
静的解析ツール（Phanなど）を入れる
NewRelicなどの監視ツールを入れる
事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く
時間を見つけてロジックが複雑な部分をリファクタリングをしていく
errorやdeployやcommit通知をslackに流す
git-pr-releaseを入れる

安全にDeployできるような仕組みを作る

AWS ECSのようにコンテナマネージドサービスの場合はCircleCIからたたけばよいだろうし、そうでなければとりあえずdeploy用のサーバを立てcapisoranoでdeployしちゃってもよいだろう。

大事なのはlocalに依存しないことと再現性のあること。

使用してる外部サービスを洗い出しておく

意外とこういう洗い出し大事。使っていないコードの削除も捗るし、抽象化もしやすい。

事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く

技術的負債の説明をできるのはエンジニアしかいないので、本当に対応するべきか置いといて、きちんと伝えることは大事。

エラー通知やdeploy通知をslackに流す

DX向上はエンジニア以外わからないので、「きちんと作業している」ということを伝えるのは大事。

DX向上はエンジニアのための作業だけど、ちゃんとエンジニア以外にも「伝える」こともエンジニアとして大事なんだろうなぁ。

Backlinks

エンジニア採用面接で考えていること

JavaScriptのthisについて

Mon, 01 Jul 2019 09:00:00 +0900

会社のインターン生にJavaScriptの this についてドヤ顔で説明してたら、間違って理解していたことがわかってしまった。

同僚と this がどのような挙動をするのかで盛り上がって楽しかった。

【JS】ああthisよ。君は今、どのオブジェクトなのか（練習問題あり）

同僚の @valley 氏の記事がおおよそすべてを説明してくれているが、この記事では自分の言葉で this について説明する。

元記事ではブラウザで実行していたが、この記事では nodejs で実行するので window -> global となる。

結局そのscopeが評価された時のcontextがthisになる。関数やオブジェクトが評価されるタイミングはいつなの？ってことを考えればあとは自然とthisを導き出せる。 functionが評価されるタイミングとlambdaが評価されるタイミングが違うというだけ。

たとえば、次のようなスクリプトがある。

func1 の関数が評価されるのは実行時なので {} だが、 func2 の関数が評価されるのはコンパイル時なので global になる。

const func1 = () => {
 console.log(this);
};

const func2 = function () {
 console.log(this);
};

console.log(func1); // {}
console.log(func2); // global

ファイル分割した場合はどうなるだろうか。次のようなコードを書いてみた。

test.js:

const { func1, func2 } = require("./test1.js");

console.log(this.aaa); // undefined

func1(); // { aaa: 'bbb' }
fund2(); // global

test1.js:

this.aaa = 'bbb';

const func1 = () => {
 console.log(this);
};

const func2 = function () {
 console.log(this);
};

module.exports = { func1, func2 };

教えるのも勉強なるし、こうやって深堀するとさらに詳しく慣れて楽しい。

EsLintでGlobの挙動で詰まった時のメモ

Fri, 31 May 2019 09:00:00 +0900

詰まった内容は以下だ。

同じコマンドを実行しているはずなのに出力される結果が違うので困っています。
開発環境では通って、circleci上ではエラーが出ている状態です。

A: npm run test:lint
B: ./node_module/.bin/eslint --debug app/javascript/**/*.{vue,ts}

"scripts": {
"test:lint": "eslint --debug app/javascript/**/*.{vue,ts}"
}

A と B で同じコードを実行しているはずなのでなぜか違う結果を吐き出すのだ。 local では eslint が通るけど circleci ではコケる、といった問題が起きていて困っていた。

ちなみに、 eslint --debug で実行ログをみることができる。

ESLint開発者の方と弊社CTOのBTOさんに教えてもらうことによって原因を突きとめることができた。

原因は、「globの解釈の問題」だ。

そもそもglobとはWikiによるとこんな感じ。

グロブ（英: glob）とは主にUnix系環境において、ワイルドカードでファイル名のセットを指定するパターンのことである。

今回の場合だと、2種類の解釈のし方がある。

shellでglobが解釈される
npmのglobで解釈される

macの標準のshellは bash なのだが、これだとうまくglobを評価してくれないのだ。一方、circleciのコンテナのshellは busybox だったのでうまくglobを評価してくれた。

つまり、macではちゃんと動いていなかっただけだったのだ。

そこで次のようにglob部分を ' で囲った。

"scripts": {
 "test:lint": "eslint --debug 'app/javascript/**/*.{vue,ts}'"
}

そうすることにより、 npmのglobで解釈される ようになり、正常に動くようになった。

内部的にはこれを使っているみたいだ。

https://www.npmjs.com/package/glob

この世界にはたくさんのshellがあるようだ。

dash（debian ash）
ash
busybox
fish shell
xonsh shell
z shell
bash
etc

Ubuntu標準は dash みたいだ。

オフィスにアクセスポイントを導入した時やったこと

Wed, 29 May 2019 09:00:00 +0900

無線ルータを購入してアクセスポイントを設定した時に学んだことをメモしておく。

無線ルータ選定

ポイントは3点。

転送速度
セキュリティ
無線端末最大接続数

転送速度

種類ありすぎてわけわからないけど、とりあえず 1ac に対応してればよいかな。GHzが低いほど壁などの障害に強い。

参考にした記事は以下。

セキュリティ

WPA2 に対応してればオッケーという雑な理解。

参考にした記事は以下。

無線端末最大接続数

今回はだいたい100台くらいつなげられればよかった。

参考にした記事は以下。

BUFFALO 管理者機能搭載アクセスポイント商品比較表

設置

これを購入することにした。

https://www.amazon.co.jp/dp/B00OL61L9S/ref=asc_df_B00OL61L9S2617725/?tag=jpgo-22&creative=9339&creativeASIN=B00OL61L9S&linkCode=df0&hvadid=226974324204&hvpos=1o1&hvnetw=g&hvrand=14998055634270719829&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=pla-457493725121][BUFFALO インテリジェントモデル PoE対応 11ac/n/a/g/b 866+300Mbps 無線LANアクセスポイント WAPM-1166D

オフィスに生えている野生のケーブルにルータを差して動かした。端っこの方に適当に置いているので中央に置き直すつもりだ。

管理画面から設定

同一ネットワーク内で http://192.168.11.100 をたたくと管理画面に入ることができる。

SSIDの変更やpasswordの変更、認証方式の制限などを変更する。

変更するたび毎回再起動するので注意。

余談

POEすごい。 Ethernet指すだけで充電できるというの便利だなぁと思った（小学生並みの感想）。

macアドレスでAPへのアクセス制限をかけられることを知れてよかった。

SVGにグラデーションのアニメーションをかける

Sun, 14 Apr 2019 09:00:00 +0900

ソースコードはこんな感じ。

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 1000 1000" enable-background="new 0 0 1000 1000" xml:space="preserve">
 <defs>
 <linearGradient id="bearGratient" x1="100%" y1="100%">
 <stop offset="0%" stop-color="#69d2ff" stop-opacity=".5">
 <animate attributeName="stop-color" values="#69d2ff;#71dca7;#ffd458;#ffa7de;#69d2ff" dur="14s" repeatCount="indefinite" />
 </stop>
 <stop offset="100%" stop-color="#69d2ff" stop-opacity=".5">
 <animate attributeName="stop-color" values="#69d2ff;#71dca7;#ffd458;#ffa7de;#69d2ff" dur="14s" repeatCount="indefinite" />
 <animate attributeName="offset" values=".95;.80;.60;.40;.20;0;.20;.40;.60;.80;.95" dur="14s" repeatCount="indefinite" />
 </stop>
 </linearGradient>
 </defs>
 <g fill="url(#bearGratient)" transform="translate(0.000000,511.000000) scale(0.100000,-0.100000)">
 <path d="/* 中略 *//>
 <path d="/* 中略 *//>
 <path d="/* 中略 *//>
 </g>
</svg>

最初、 css の linear-gradient で線形グラデーションをかけようと思ったのだが、どうも svg には対応していないらしい。

svg のMDNを漁っていたら linearGradient というタグがあった。

https://developer.mozilla.org/ja/docs/Web/SVG/Element/linearGradient

よいサンプルがなかったので調べていたら、次のようなsnippetがたくさん落ちていた。

サンプルコードによるとこんな感じ。

defs に linearGradient を定義する。
linearGradient に stop > animate 。で時間に合わせたグラデーションをかけることができる。
実際に描画する SVG 要素に上で定義した linearGradient を fill する。

これできた。

css や svg を使うことによって描画がものすごいきれいになるので多用していきたい。

Ubuntu FirefoxをEmacs Keybindにする

Sat, 13 Apr 2019 09:00:00 +0900

普段Chromeを使っているのだが、外で作業するとき電池の消費量が異常だったのでFirefoxの環境も整備する必要が出てきた。

しかしながら、Emacs脳である自分にはネットサーフィンもEmacsでしたいという欲求が非常に強い。

ChromeにはChromemacsという拡張があるが、Firefoxにはなかったのでなんとかしてみた。

次の記事を参考した。

xkeysnail - もうひとつの Linux 向けキーリマッパ

Firefox が Quantum になり、旧来の XUL ベースのアドオンは動作しなくなった。新たな拡張機能の機構である WebExtensions ではキーボードショートカットに関する API が大幅に制限され、ぼくは拙作のアドオン KeySnail のWebExtensions 化を諦めた。

この筆者も同じことを考えていて、同じように辛さを感じているようだ。

この xkeysnail は Firefoxのplugin ではなくて、 Linuxのuinputを取得して任意のkeyに変換する ということをやっている。

mooz/xkeysnail の README.md に導入方法が書いてある。

自分の .config.py は以下。

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

define_conditional_modmap(re.compile(r'Firefox'), {
 Key.CAPSLOCK: Key.LEFT_CTRL,
})

define_keymap(re.compile("Firefox"), {
 # change tab
 K("C-f"): K("C-Tab"),
 K("C-b"): K("C-Shift-Tab"),

 # search
 K("C-s"): K("C-f"),
 K("C-s"): K("C-g"),
 K("C-r"): K("C-Shift-g"),

 # private window
 K("C-Shift-n"): K("C-Shift-p"),

 # up/down
 K("C-n"): K("DOWN"),
 K("C-p"): K("UP"),
 K("C-v"): K("SPACE"),

 K("C-g"): {
 # change page
 K("C-b"): K("C-LEFT_BRACE"),
 K("C-f"): K("C-RIGHT_BRACE"),

 # reload
 K("C-r"): K("C-r"),

 # paste
 K("C-v"): K("C-v"),

 # close
 K("C-w"): K("C-w"),

 # close
 K("C-t"): K("C-Shift-t"),
 }
}, "Firefox")

Firefox のみ反応してほしいのでこのような設定にした。

WebpackerでBulmaをbuildするとwarningが出るものの調査と対応

Thu, 11 Apr 2019 09:00:00 +0900

「Webpackerでbuildするとめっちゃwarning出るんだけど調べてくれない？」

と、会社の先輩からいわれたので調査対応をした時学んだことをメモしていく。

warningの内容は以下だ（抜粋）

$ ./bin/webpack
...
WARNING in ./node_modules/css-loader??ref--2-2!./node_modules/postcss-loader/lib??ref--2-3!./node_modules/resolve-url-loader!./node_modules/sass-loader/lib/loader.js??ref--2-5!./app/assets/scss/main.scss
(Emitted value instead of an instance of Error) postcss-custom-properties: /Users/node_modules/bulma/sass/grid/columns.sass:501:10: Custom property ignored: not scoped to the top-level :root element (.columns.is-variable.is-3-widescreen-only { ... --columnGap: ... }), in atrule
...

このwarningが何十個も出ている状態だった。

エラーの原因は bulma のコード内にある postcss-next が良くなかったからだ。

対象のコード抜粋は以下。

@if $variable-columns
 .columns.is-variable
 --columnGap: 0.75rem
 margin-left: calc(-1 * var(--columnGap))
 margin-right: calc(-1 * var(--columnGap))
 .column
 padding-left: var(--columnGap)
 padding-right: var(--columnGap)
 @for $i from 0 through 8
 &.is-#{$i}
 --columnGap: #{$i * 0.25rem}
 +mobile
 &.is-#{$i}-mobile
 --columnGap: #{$i * 0.25rem}
 +tablet
 &.is-#{$i}-tablet
 --columnGap: #{$i * 0.25rem}
 +tablet-only
 &.is-#{$i}-tablet-only
 --columnGap: #{$i * 0.25rem}
 +touch
 &.is-#{$i}-touch
 --columnGap: #{$i * 0.25rem}
 +desktop
 &.is-#{$i}-desktop
 --columnGap: #{$i * 0.25rem}
 +desktop-only
 &.is-#{$i}-desktop-only
 --columnGap: #{$i * 0.25rem}
 +widescreen
 &.is-#{$i}-widescreen
 --columnGap: #{$i * 0.25rem}
 +widescreen-only
 &.is-#{$i}-widescreen-only
 --columnGap: #{$i * 0.25rem}
 +fullhd
 &.is-#{$i}-fullhd
 --columnGap: #{$i * 0.25rem}

GitHub: https://github.com/jgthms/bulma/blob/4caa77dc0f13984347b734657c2d4cd588149087/sass/grid/columns.sass#L467-L504

AjaxとBrowser Cookie

Sat, 30 Mar 2019 09:00:00 +0900

「ブラウザからアクセスするのと、AjaxからアクセスするのってCookieってかわっちゃうの？」という質問をされたので自分なりの答えを書いていく。

Ajaxなのだが、JavaScriptで一番有名なlibraryのaxios/axiosを用いて書く。

FetchAPIについては今回は含めない。

結論

基本的にはCookieは変わらない。

同一オリジンの場合は自動的にCookieが使われる。

別オリジンの場合にCookieを使いたいなら { withCredentials: true } をoptionに持たせればよい。

axios.get('https://www.uuum.jp', { withCredentials: true });

そもそもAjaxとはなんだろうか？

MDNにこう書いてある。

AJAX は Asynchronous JavaScript And XML の頭文字を取ったものです。これは一言で言えば、 XMLHttpRequest オブジェクトを使ってサーバーと通信することです。 AJAX は JSON, XML, HTML, テキストファイルなど、様々な形式の情報で送受信することができます。 AJAX の最も魅力的な特徴は「非同期」であること、つまり、サーバーとの通信、データの交換、ページの更新を、ページの再読み込みなしに行うことができる点です。

要するに、JavaScriptから通信ができるというだけ。

XMLHttRequest のサンプルは以下。

const xhr = new XMLHttpRequest();
xhr.open("GET", "https://www.uuum.jp");
xhr.send();

console.log(xhr.status); // 200

これで通信ができる。以上だ。

axiosのコードを読んでみる。

axios/lib/adapters/xhr.jsに XMLHttpRequest が書いてある。

var request = new XMLHttpRequest();

XMLHttpRequest を使っているのが確認できた。

さて、Cookieの扱い方はどうなっているだろうか？　ググったら withCredentials を使えって書いてある。

実際にコード読んでみるとこんな記述がある。

axios/lib/adapters/xhr.js#L103-L105:

var xsrfValue = (config.withCredentials || isURLSameOrigin(config.url)) && config.xsrfCookieName ?
 cookies.read(config.xsrfCookieName) :
 undefined;

同一オリジンの場合や withCredentials の場合に cookies.read が走る。

Cookiesの定義元を読んで見る。

axios/lib/helpers/cookies.js:

npm libraryのbuild formatについて

Sun, 17 Mar 2019 09:00:00 +0900

半年前くらいにnpm package作ってみたいなぁと思って作ってみた時学んだことをまとめていく。

次の記事でだいたい理解できたのだが、実際にやってみて細かいところでつまずた部分を書いていく。

ちなみに、repoは takeokunn/businesh で、ビジネッシュ翻訳してくれるようなゴミみたいなpackageだ。意外とdownloadがあるのウケる。

const before_text = '任意の文字列をビジネッシュ・テキストに変換するライブラリです。';
businesh.translate(before_text)
 .then(after_text => {
 // 半強制のコンテクストをハイクオリティなビジネス的サティスファクション・テキストにコンバートフレキシブルに対応するフィジビリティスタディって、この前読んだビジネス書に書いてあった、実例もたくさんある。
 console.log(after_text)
 })
 .catch(err => console.log(err));

npm のpackageと一口に言っても、 server side javascript なのか、 frontend javascript なのかで毛色が違う。通常次のようにライブラリを呼び出す。

frontend:

import businesh from 'businesh';

server side:

const businesh = require('businesh');

上記のように呼び出すには、次のようにpackageを提供する必要がある。

frontend:

export { businesh };

server side:

exports.businesh = businesh;

javascript の module には主に4種類ある。

AMD
CommonJS
ES
UMD

この辺の記事が参考になる。

bundler のbuild optionで解決できる。 rollup を使っているので次のように設定すればよい。

Common Lispのquoteについて

Sat, 16 Mar 2019 09:00:00 +0900

stack overflowに次の2つの質問をした。

両方とも sds という方が答えてくれたのですが、どうも自分は quote について理解をしていないことがわかりました。

調べたところ、stack overflowに良さそうな記事があったので翻訳をしてみる。

When to use ’ (or quote) in Lisp?

Question: quoteっていつ使うの？

Lispの入門書を読んだのですが、 quote や ' 特殊な演算子がどんな挙動をするのか理解できませんでしたし、まだ見たことがありません。

どうでしょうか？

Short Answer:

デフォルトの評価ルールを使わず、 symbol か s式 を評価せずに入力された型どおりに関数を渡す。

Long Answer: デフォルトの評価ルール

通常の関数（後述）が呼び出された時、引数はすべて評価される。コードは以下。

(* (+ a 2)
 3)

a と 2 を順に評価することによって (+ a 2) を評価する。シンボル a の現在束縛されている値を調べ、置き換える。 a は現在3という値が束縛されています。

MySQLのmax_allowed_packetについて

Sat, 09 Mar 2019 09:00:00 +0900

先日、カイシャのギョームでこんなことがあった。

「なんか、普通に投稿はできるんだけど、下書きが保存できないんだよね。ちょっと原因わからない？」

Railsで書かれている対象のコードを読んだのだが、まったく問題がなさそうだ。普通に ActiveRecord のメソッドを読んでテキスト情報を保存しているだけだからだ。

今扱っているプロジェクトは負債が多くてどこが本当に原因なのかはわからなかったので途方に暮れていたら、カイシャの凄腕の人が「多分 max_allowed_packet かな」と言い、サクッと直してしまった。

こういうのが技術力なんだなぁとしみじみ思ったので、どういうことが起こっていたのかちゃんと復習して、次同じようなことが合った時ドヤ顔できるようにする（間違いがあるかもなので指摘してもらえると幸い）

まず、対象の table を show create table するとこんな感じだった（一部抜粋）

CREATE TABLE `drafts` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `dump_obj_encode_in_base64` longtext NOT NULL,
 `created_at` datetime NOT NULL,
 `updated_at` datetime NOT NULL,
 PRIMARY KEY (`id`),
) ENGINEInnoDB AUTO_INCREMENT~145 DEFAULT CHARSET~utf8 ROW_FORMAT~DYNAMIC

引き継いだプログラムなのでなぜこうなっていたのかまったくわからないが、 dump_obj_encode_in_base64 の型が longtext で保存されていた。

longtext は 最長4,294,967,295、または4GB (232 - 1) バイト と非常にsizeが大きい。

参考： BLOB型とTEXT型(DB Online)

MySQLのclientがserver投げられる最大のデータ量はどのくらいだろうか。

それを定義しているのが max_allowed_packet だ。

現在このブログを書いているPCのMySQL(Server version: 5.7.25-0ubuntu0.18.04.2 (Ubuntu))はどうだろうか。

mysql> show variables like 'max_allowed_packet';
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+
1 row in set (0.06 sec)

約16MBだった。 longtext では全然足りないサイズだ。

docker-compose.ymlのportsについてのメモ

Tue, 26 Feb 2019 09:00:00 +0900

おもしろい挙動をするので記事化する。

中のコード読んでみたい。

version: '3'
services:
 nginx:
 image: nginx
 ports:
 - 0:80

portを0にするとどうなるだろうか。

~/D/test (*´ω｀*) < docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05e0975ea3d1 nginx "nginx -g 'daemon of…" 51 seconds ago Up 49 seconds 0.0.0.0:32768->80/tcp test_nginx_1

0.0.0.0:32768->80/tcp なんと、 32768 にforwardされるのだ。

もう一度 docker-compose up し直す。

~/D/test (*´ω｀*) < docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05e0975ea3d1 nginx "nginx -g 'daemon of…" 4 minutes ago Up 4 seconds 0.0.0.0:32769->80/tcp test_nginx_1

0.0.0.0:32769->80/tcp こうなる。不思議だ。

どこかの記事で読んだのだけれども、被らないようにportをforwardingしてくれるそうな。

公式ドキュメントのNoteもおもしろい。

Note: When mapping ports in the HOST:CONTAINER format, you may experience erroneous results when using a container port lower than 60, because YAML parses numbers in the format xx:yy as a base-60 value. For this reason, we recommend always explicitly specifying your port mappings as strings.

Posts on takeokunn's blog

nix-darwinのlinux-builderでNixOSを動かす

背景・動機

試したこと・やったこと

1. linux-builderについて調査

2. nix-darwinを導入してみる

3. 動いてることを確認する

2025年12月 個人的claude codeワークフロー

1. はじめに

2. 背景と設計哲学

2.1. 感じていた課題

2.2. 5つのルール

3. プロンプト設計の基盤

3.1. XMLによる構造化プロンプト

3.1.1. なぜXMLなのか

「The Rust Programming Language 日本語版」の読書記録

文献情報

読む目的・背景

重要ポイントと引用

所有権（Ownership）

借用（Borrowing）

blogをdev.toサポートした

背景・動機

試したこと・やったこと

1. 対応理由整理

2. NixでBuildできるようにする

Neovimの設定をNixvimに移行した

背景・動機

試したこと・やったこと

1. 管理方法選定

2. 初期構築

3. AIに設定させる

社内読書会でThe Rust Programming Languageを読破した

1. Introduction

2. 開催情報

2.1. 基本情報

2.2. 時間設定の意図

2.3. 進め方

3. 個人的な目標

4. うまくいった理由の考察

4.1. Geminiの活用

4.2. 有識者に語る会

複数人でAirbnbを借りた時の清算方法

背景・動機

試したこと・やったこと

1. 条件を整理する

2. 清算シートを作る

得られた結果・所感

今後の展開・検討事項

digツールはdoggoが便利

背景・動機

試したこと・やったこと

0. ツール選定

1. home-manager module用意

Typst SlideのDracula Light Theme作成した

背景・動機

試したこと・やったこと

1. テーマ選定

2. テーマ作成

得られた結果・所感

今後の展開・検討事項

技術イベントのパンフレット記事をTypstでBuildする

背景・動機

試したこと・やったこと

1. Build周り

2. テーマ選定とTypst設定

得られた結果・所感

gitleaksを導入した

背景・動機

試したこと・やったこと

0. ツール選定

1. home-manager module作成

2. devenvのgit pre-commit導入

得られた結果・所感

簡易的なヒューリスティックパーサの自作方法

背景・動機

試したこと・やったこと

0. ヒューリスティックパーサが適切か見極める

1. テストデータのパターンを用意する

2. パーサをAIに作らせる

2025年12月個人的claude codeワークフロー