HCL（Terraformの.tf）ファイルやCUEファイルのシンタックス内の文字列に（prettierなどの）任意のフォーマッタを適用する

Go

おそらくTerraformの.tfファイルがイメージしやすいと思いますが、.tfファイルのHCLシンタックス内に別のシンタックス（多くはヒアドキュメントで表現される複数行の文字列）を埋め込むことがあります。

私が真っ先に思い出すのがAWSのPolicyです。

resource "aws_iam_policy" "allow_dynamodb_table_post" {
  name   = "allow_post"
  policy = <<-EOT
  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Action": "dynamodb:*",
      "Resource": "${aws_dynamodb_table.post.arn}"
    }
  }
  EOT
}

今ではData sourceでaws_iam_policy_documentなどが提供されているのであまりないかもしれませんが、上記の例だとHCLの中のヒアドキュメント内にJSONシンタックスでポリシー定義が表現されています。

これは、file() 関数によって外部ファイルにすることも可能なので、別シンタックスは別ファイルにするという選択肢を取ることもできます。

ところで、様々な理由から*1そのままヒアドキュメントで記載したい場合もあります。

しかし、terraform fmt や cue fmt ではヒアドキュメント内のフォーマットまではしてくれません。それはそうです。

ただ、コードの可読性や統一感という点からもヒアドキュメント内の文字列についてもフォーマットしたいわけです。

私が所属するテイラー株式会社が提供するTailor Platformは、TerraformやCUEでGraphQLエンドポイントを有するHeadlessなERPアプリケーションを記述することができ、そのままデプロイすることができます*2。 アプリケーションに必要なロジックはCELやJavaScriptで書いたり、アプリケーションに必要な機能を持つGraphQLのカスタムqueryやmutationを追加で展開できたりします。

ここでもCELやJavaScriptやGraphQLなどの「別のシンタックス」がでてきました。

「HCLやCUEでインフラやアプリケーションを記述する際の選択肢としてヒアドキュメントも持っておきたい」というのが今回のモチベーションです。

hclstr / cuestr

というわけで書いてみました。

github.com

github.com

それぞれHCLやCUEの文字列（ヒアドキュメント）に対して任意のフォーマッタを適用できます。

使い方は簡単で、対象のファイルに対して hclstr fmt や cuestr fmt を実行するだけです。

フォーマッタは --field オプションで [fieldname]:[format command] の: 区切りの文字列を渡す形で指定します。--field オプションは複数並べて指定できます。

例えばあるディレクトリ以下の .tf ファイルの各 policy フィールドに対して prettier を実行したい場合は以下のようなコマンドになります。

$ find . -type f -name '*.tf' | xargs -I{} hclstr fmt {} --field 'policy:prettier ? --write --parser json'

? はプレースホルダです。? というファイルに対してフォーマッタを適用するようなコマンドを作れば良いです。

resource "aws_iam_policy" "allow_dynamodb_table_post" {
  name   = "allow_post"
  policy = <<-EOT
{
"Version": "2012-10-17",
  "Statement": {
"Effect": "Allow",
         "Action": "dynamodb:*",
"Resource": "${aws_dynamodb_table.post.arn}"
}
}
EOT
}

みたいな .tf ファイルも

resource "aws_iam_policy" "allow_dynamodb_table_post" {
  name   = "allow_post"
  policy = <<-EOT
  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Action": "dynamodb:*",
      "Resource": "${aws_dynamodb_table.post.arn}"
    }
  }
  EOT
}

という感じにフォーマットされます。

まだ、完全に対応できてるわけではありませんが、是非使ってみてください。

Fukuoka.go

上記のツールを含む最近作ったHCL/CUE系ツールの実装面についてFukuoka.goで紹介予定です（なんと10周年！！）。

fukuokago.connpass.com

今朝見た限りでは若干まだ空きがあるみたいなので、是非乾杯しましょう。

*1:例えば可読性

*2:2025年3月現在

ghq list をMonorepoに対応させる

Go

私は普段リポジトリの管理にghqを使っています。

そしてリポジトリ間の移動にはpecoと合わせて以下のようにコマンドを組み立てています。

$ cd `ghq list --full-path | peco` # ghq listの結果をpecoで選択して、その選択したリポジトリに移動する

Monorepoの台頭

最近、様々な理由からMonorepoが多くなってきているように思います。私が所属するテイラー株式会社でも多くのリポジトリがMonorepoになっています。

テイラー株式会社がOSSとして公開しているfabrix*1もMonorepoです。

github.com

私が普段ウロチョロするリポジトリのうちのMonorepoの割合が急速に増えてきています。

ところが、今までの私のリポジトリ移動のやり方（ cd $(ghq list --full-path | peco) ）だと、リポジトリルートのディレクトリには移動できてもその中で管理されている各プロジェクトのルートディレクトリ（サブルート）には移動できません。

そろそろストレスになってきたので、ghq list をMonorepoに対応すべく作ってみました。

roots

前提として、 ghq は（リモート）リポジトリの管理のためのツールであり、Monorepoといったリポジトリ内の運用方式のためのツールではないと個人的には考えています。

なので、ghq本体をいじらずに ghq list 拡張するようなツールとして roots を作成しました。

github.com

roots は指定のディレクトリから複数のルートディレクトリを探索するコマンドです。

例えば、先ほど紹介したfabrixのリポジトリで roots コマンドを実行すると次のようになります。

$ pwd
/path/to/src/github.com/fabrix-framework/fabrix
$ roots
/path/to/src/github.com/fabrix-framework/fabrix
/path/to/src/github.com/fabrix-framework/fabrix/examples/mock-todoapp-server
/path/to/src/github.com/fabrix-framework/fabrix/examples/vite-todoapp
/path/to/src/github.com/fabrix-framework/fabrix/packages/chakra-ui
/path/to/src/github.com/fabrix-framework/fabrix/packages/fabrix
/path/to/src/github.com/fabrix-framework/fabrix/packages/graphql-config
/path/to/src/github.com/fabrix-framework/fabrix/packages/unstyled
/path/to/src/github.com/fabrix-framework/fabrix/shared/eslint
/path/to/src/github.com/fabrix-framework/fabrix/shared/prettier

複数の package や example があることがわかります。それぞれをルートディレクトリと判定してリストアップできています。

少しfabrixのリポジトリに深く入ったところで roots コマンドを実行するとどうなるでしょう？

$ cd packages/fabrix
$ pwd
/path/to/src/github.com/fabrix-framework/fabrix/packages/fabrix
$ roots
/path/to/src/github.com/fabrix-framework/fabrix
/path/to/src/github.com/fabrix-framework/fabrix/examples/mock-todoapp-server
/path/to/src/github.com/fabrix-framework/fabrix/examples/vite-todoapp
/path/to/src/github.com/fabrix-framework/fabrix/packages/chakra-ui
/path/to/src/github.com/fabrix-framework/fabrix/packages/fabrix
/path/to/src/github.com/fabrix-framework/fabrix/packages/graphql-config
/path/to/src/github.com/fabrix-framework/fabrix/packages/unstyled
/path/to/src/github.com/fabrix-framework/fabrix/shared/eslint
/path/to/src/github.com/fabrix-framework/fabrix/shared/prettier

なんと、同じように複数のルートディレクトリを取得できています（具体的な探索戦略の紹介はREADMEに譲ります）。

ghq list をMonorepoに対応させる

さて表題の件です。roots コマンドは標準出力からもディレクトリを受け取れます。

もうわかったかと思います。パイプで繋げばいいのです。

$ cd `ghq list --full-path | roots | peco`

これで、ghq list で得た各リポジトリそれぞれでMonorepo構成のルートディレクトリを探索して移動先としてリストアップしてくれます。

個人的にかなり便利になりました。

よろしければみなさんも使ってみてください。

本題

roots と聴いて The Roots を思い浮かべたあなた。お友達になれそうです。


README.mdの様子

[追記] consult-ghq の対応

現時点では consult-ghq--list-candidates の上書きが一番手っ取り早そうです

(defun consult-ghq--list-candidates ()
  "Return ghq list candidate with roots."
  (with-temp-buffer
    (unless (zerop (apply #'call-process
                          "bash" nil t nil
                          '("-c" "ghq list -p | roots")))
      (error "Failed: Cannot get ghq list candidates"))
    (let ((paths))
      (goto-char (point-min))
      (while (not (eobp))
        (push
         (buffer-substring-no-properties
          (line-beginning-position) (line-end-position))
         paths)
        (forward-line 1))
      (nreverse paths))))

*1:https://note.com/tailortech/n/nf2f9edb2f919

VSCode上でkey-chord.elをできるだけ再現する

Emacs VSCode

できてしまった...

marketplace.visualstudio.com

まず、本エントリの主題である key-chord.elの機能については是非 https://www.google.com/search?q=key-chord.el をご覧ください。私は今でもキーボードショートカットの革命の1つだと思っています。

key-chord.elは個人的には最後の難関キーバインドExtensionだと思っていたのですが、VSCode Extensionを作り慣れてきた結果実装が見えてきて、手を動かしてみたらできてしまいました。

設定としては次のような感じです。

{
  "key-chord.definitions": {
    "hj": "undo",

[...]

}

これで h と j の同時押しでundoが実行できます。

h と j はQWERTY配列においては隣同士です。つまり、

h と j のキーの間を押すだけでコマンドが実行できるわけです。実はキーとキーの間にもキーがあったということです！便利！！！！

これ、思った以上に便利なのでVSCodeなみなさんも使ってみてほしいです。

最終的には以下のエントリーのような微調整できるようにはしたいと思っています。

qiita.com

VSCodeでキータイプイベントを取得できるイベントを使えるExtensionは1つだけ

ところで、key-chord.elを他のエディタで再現するにはどうしてもキータイプイベントを取得できる必要があります。

ところが、VSCodeでキータイプイベントを取得できるイベントを使えるExtensionは1つだけという制約があるとのことなのです。

github.com

これはツラい...

私のVSCodeのExtensionラインナップではsmartchrがキータイプイベントの取得をしており、それとKey Chordとがバッティングするわけです。

今のところ解決策がなく、困っています。

どうしたものか...

VSCode上でsequential-command(-config).elのseq-homeとseq-endをできるだけ再現する Part 2

Emacs VSCode

k1low.hatenablog.com

前回、

本格的に sequential-command.el をちゃんと実現してみようかなと思います

と言っていましたが、なんとか「ぽい」ものを実現できました。

Sequential Command

marketplace.visualstudio.com

設定としては sequential-command.definitions にある A から Z までのスロットに実行したいコマンドのリストを定義しておくと、それらがそのまま sequential-command.executeA から sequential-command.executeZ のコマンドから呼び出せるようになります。

例えば、

{
  "sequential-command.definitions": {
    "A": [
      "cursorLineStart",
      "cursorTop",
      "sequential-command.seqReturn"
    ],

[...]

}

と設定している場合、sequential-command.executeA を呼び出すたびに「cursorLineStart（行頭）」「cursorTop（先頭行）」「sequential-command.seqReturn（元のカーソル位置」と順番にカーソルを移動します*1。

やはり1つのキーバインドで複数のコマンドが実行できるのは便利。

VSCode Extensionでは、キーバインド設定ができるコマンドは動的に作成できず、あらかじめExtensionのpackage.jsonに記載しておく必要があるみたいなので*2、上記のようなスロット形式にしました。まあ26個もあれば十分でしょう。

本家 sequential-command.el との違い

先ほど、「ぽい」ものと言ったのですが、残念ながらSequential Commandの挙動は本家の挙動を完全には模倣できていません。

仕組みとしては、ステートを持った上で sequential-command.execute* を実行するたびに登録されているコマンドを順番に実行するのですが、他のコマンドを実行した場合、その順番を保持しているステートをクリアする（上記の例だとまた「cursorLineStart（行頭）」から開始するようにする）必要があります。

ところが「コマンドを実行された」というイベントは現在のVSCode（1.96.4）には提供されていないようなのです。

github.com

なので、一定時間経過したらステートをクリアするようにしました（ sequential-command.sequenceTimeout で設定できます）。

この課題、良い解決策があれば是非教えてください！

では

良いエディタライフを。

*1:私はMarkSetを有効にするために emacs-msx.* のコマンドを並べています

*2:他のやり方があれば教えてください

VSCode上でsequential-command(-config).elのseq-homeとseq-endをできるだけ再現する

Emacs VSCode

ひょんなことからVSCodeのセットアップをしています。

Emacs化

私のメインエディタはEmacsです*1。

なので、キーバインドを慣れているEmacsにしていきます。

まず、Awesome Emacs Keymapをインストールしたら、ほとんどのキーバインドがEmacsライクになりました。

marketplace.visualstudio.com

「OptionキーではなくCommandキーをMetaキー（M-）として使いたい」という個人的に譲れない設定もチェックボックス1つで実現できました。すごい。

残りの（好みの）キーバインド設定はVSCodeのKeyboard Shortcutsの設定だけほぼほぼでできました(( Ctrl-t でターミナルをトグル表示とか))。

俺のEmacs化

さて、私としては（特殊な機能は置いておいても）コードを書くときに無意識に使うようなキーバインドはできるだけ実現したい、むしろかなり実現させたいと考えています。

その中でもEmacsでいう smartchr.el、sequential-command.el、key-chord.elによって実現されているキー操作を実現したい。

smartchr.elについては、すでに我らがEmacsヒーロー id:kiwanami さんが実現してくれています。

marketplace.visualstudio.com

key-chord.el や sequential-command.el はちょっと（TypeScriptがほとんど書けない）私には*2難しいです。

ところで、VSCodeのKeyboard Shortcutsでは when 句を使うことで条件付きキーバインドが設定できるようです。

「これを使えば sequential-command.el を実現できないまでも sequential-command.el で実現していた seq-home や seq-end の動きは実現できそう」

sequential-command/sequential-command-config.el at a48cbcbe273b33edd3ae56e68f44b4100fa3a48a · rubikitch/sequential-command · GitHub

と思いついたので、作ってみました。

ちなみに sequential-command.el の本来の機能は次のエントリをご覧ください。

rubikitch.hatenadiary.org

Cursor Position Contexts

marketplace.visualstudio.com

実現方法がすごいトリッキーなので、いろいろ説明を省きますが、カーソルの位置を when 句のコンテキストとして使えるようにするためのVS Code Extensionです。

先ほどの Awesome Emacs Keymap と合わせて使う場合、次のようなキーバインドを追加すると、ほぼほぼ seq-home、seq-end と同じようなカーソル移動が実現できます。

[
    {
        "key": "ctrl+a",
        "command": "cursorTop",
        "when": "textInputFocus && config.cursor-position-contexts.cursorHome"
    },
    {
        "key": "ctrl+e",
        "command": "cursorBottom",
        "when": "textInputFocus && config.cursor-position-contexts.cursorEnd"
    },
    {
        "key": "ctrl+e",
        "command": "cursor-position-contexts.cursorReturn",
        "when": "config.cursor-position-contexts.cursorEnd && config.cursor-position-contexts.cursorBottom && textInputFocus"
    },
    {
        "key": "ctrl+a",
        "command": "cursor-position-contexts.cursorReturn",
        "when": "config.cursor-position-contexts.cursorHome && config.cursor-position-contexts.cursorTop && textInputFocus"
    }
]

とりあえずこれで、Ctrl+aを押すたびに、ほぼ「（行のコード先頭->）行頭->ドキュメント先頭->元の場所」というような動きをします（細かい挙動がまだ実現できていません。元の場所に戻れなかったりします）。逆の挙動は Ctrl+e です。

config.* を設定値としてではなくコンテキストとして使っている時点でかなりトリッキーなのですが、まあ、挙動は満足いくものができました。

というわけで

これでコードを書いているときにあまりイライラしなくなったので、本格的に sequential-command.el をちゃんと実現してみようかなと思います（え？）。

key-chord.el は難しそうだな...

以上、エディタ設定の現場からでした。

*1:これからもEmacsの予定です

*2:まだ

fido-vertical-modeの設定あれこれ

Emacs

久しぶりに .emacs.d （Emacsの設定）を新たに書き直しています。

（かなり）重い腰を上げた理由は、新しいMacBookに切り替えたこととか、ふとEmacs 27から29に上げたらEmacs環境が壊れたこととかいろいろあるのですが、設定をモダンにやり切るところまでやろうと思ったのは、やはり @takeokunn からの突き上げ？がvim-jpラジオでピークに達したことが理由です*1。

audee.jp

audee.jp

最初は「今の設定が動くところまで」だけで終わっていたんですけどね。

最後の最後にvim-jpラジオを聴いて「やるかああああああああ」となりました。上記のエピソードはEmacserにとてもオススメです。やる気にさせてくれます*2。

やはり道具としてのEmacs、使い込まないといけないですね*3。

20252021年最新のEmacsの設定

さて、何がモダンなEmacsの設定なのかというと、2021年の記事ですが以下がとてもわかりやすいです。信頼できる筋のエントリなので信頼できます。

blog.tomoya.dev

今時のEmacserには普通なんだと思いますが、私は2024年までHelm / Companyで止まっていましたからね。隔世の感があります。

ようは

  • Emacsの標準の機能を駆使する
  • 小さなパッケージを組み合わせる

というのがトレンドのようです。

Vertico、Consult、Corfu、Orderless、Marginalia、Embark らへんが、主力っぽいです。

よーし、だんだんわかってきた。

fido-vertical-modeを使う

さらに、確かな信頼できる筋のエントリを見てみます。これも2021年。

qiita.com

Emacs 28から fido-vertical-mode というVerticoっぽいマイナーモードが、Emacs標準で提供されたそうです。

で、

「”Emacsの標準の機能を駆使する”のがトレンドなら、Verticoよりもfido-vertical-modeを使ったほうが良いのではないか」

という安直な動機で、fido-vertical-mode を使うことにしました。

(fido-vertical-mode +1) ;; 設定はこれだけ。便利。

が、

どうやらまだ時代はVerticoのようで、fido-vertical-modeの設定例があまりなく、少し困ったので、いくつか設定を共有します。

補完のためのミニバッファの領域を大きくしたい

Anything/Helm時代、私は補完候補を大きく画面の半分に出して使うスタイルだったのですが、初期設定だとConsult（+ fido-vertical-mode）で補完候補を出しても、画面の1/4程度しか出してくれません。

Verticoであれば vertico-count で設定できるっぽいのですが、fido-vertical-mode に fido-vertical-count はありません。

じゃあどうすればいいのか。ということで icomplete.el*4のソースコードを見に行ったらそれらしい記述がありました。

As many completion candidates as possible are displayed, depending on the value of max-mini-window-height', and the way the mini-window is resized depends onresize-mini-windows'.

emacs/lisp/icomplete.el at 6a299b3caceb2c73b932ba73849738faa8c5d975 · emacs-mirror/emacs · GitHub *5

さらに設定例までありました。なるほど。

(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq-local max-mini-window-height 3)))

will constrain Emacs to a maximum minibuffer height of 3 lines when icompletion is occurring.

emacs/lisp/icomplete.el at 6a299b3caceb2c73b932ba73849738faa8c5d975 · emacs-mirror/emacs · GitHub

というわけで、私は画面の半分（50%）まで表示させたいので小数点以下の値を使って以下のように設定しました。

(add-hook 'icomplete-minibuffer-setup-hook
          (lambda ()
            (setq-local max-mini-window-height 0.5)))

なお、max-mini-window-height に自然数を設定すると表示画面割合ではなく表示行数になります。便利。

補完スタイル（ completion-styles ）にOrderlessを使いたい

www.gnu.org

補完スタイル（主に補完候補の絞り込みのスタイル）をOrderlessをはじめとする便利なスタイルに切り替えるのが良いとのことなので以下のように設定してみましたがうまく補完スタイルがデフォルトから変更されません。

(fido-vertical-mode +1)

;; Consult
(use-package consult
  :ensure t
  :hook (completion-list-mode . consult-preview-at-point-mode))

;; Orderless
(use-package orderless
  :ensure t
  :custom
  (completion-styles '(orderless basic))
  (completion-category-overrides '((file (styles basic partial-completion)))))

また icomplete.el のソースを見にいくと、fido-vertical-mode（ fido-mode ）の起動タイミングで completion-styles が flex に上書き設定されていることがわかりました（ icomplete--fido-mode-setup 関数）。

emacs/lisp/icomplete.el at 6a299b3caceb2c73b932ba73849738faa8c5d975 · emacs-mirror/emacs · GitHub

icomplete--fido-mode-setup 関数は minibuffer-setup-hook にフックされているっぽいので、発火タイミングを調整しながら、さらに completion-styles を上書き設定するようにしました。

;; Orderless
(use-package orderless
  :ensure t
  :custom
  (completion-styles '(orderless basic))
  (completion-category-overrides '((file (styles basic partial-completion))))
  :config
  (remove-hook 'minibuffer-setup-hook #'icomplete--fido-mode-setup)
  (add-hook 'minibuffer-setup-hook ;; <- icomplete--fido-mode-setup より後に発火させる
            (lambda ()
              (setq-local completion-styles '(orderless basic))))
  (add-hook 'minibuffer-setup-hook #'icomplete--fido-mode-setup))

なお、 orderless doesn't work with fido · Issue #110 · oantolin/orderless · GitHub でも同じようなワークアラウンドが紹介されていました。

もう少しスッキリ書きたかったのですが、今のElisp力ではここまで。

2025/1/14 10:28追記

早速有識者からアドバイスをいただきました。ブログ書いて良かった。

;; Orderless
(use-package orderless
  :ensure t
  :custom
  (completion-styles '(orderless basic))
  (completion-category-overrides '((file (styles basic partial-completion))))
  :config
  (add-hook 'minibuffer-setup-hook
            (lambda ()
              (setq-local completion-styles '(orderless basic)) t))

スッキリ！

Orderlessのスペース区切りと相性が悪いのをなんとかしたい（2025/1/14 15:17追記）

vim-jp Slackの #tech-emacs チャンネルで、fido-vertical-modeを使っているとスペース入力でワード補完が走ることがあり、それがOrderlessの「スペース区切りでの補完キーワード列挙」の機能と相性が悪いというのを教えていただきました。

設定時は気づいていなかったのですが、確かにスペースでワード補完が走ってしまうことある*6ことがわかりました。

ソースを追ってみると minibuffer.el のkeymapとバッティングしていることがわかりました。

emacs/lisp/minibuffer.el at e6ad99e36c6c2e5322381f8af48cc283d2d899dc · emacs-mirror/emacs · GitHub

ということで無効化します。

;; Orderless
(use-package orderless
  :ensure t
  :custom
  (completion-styles '(orderless basic))
  (completion-category-overrides '((file (styles basic partial-completion))))
  :config
  (keymap-unset minibuffer-local-completion-map "SPC") ;; for using with fido-vertical-mode
  (add-hook 'minibuffer-setup-hook
            (lambda ()
              (setq-local completion-styles '(orderless partial-completion))) t))

なお、最近は define-key global-set-key ではなく keymap-set keymap-global-set を使うらしいです（これも #tech-emacs チャンネルで教えてもらいました）。

naokton.hatenablog.com

今のところ fido-vertical-mode で十分満足

Verticoを使ったことがないのでアレなんですが、今のところ fido-vertical-mode で十分満足しています。Marginaliaもちゃんと連携できますし。 「Emacsの標準の機能を駆使する」という意味ならまあ良い選択なのではないかなと。

有識者のアドバイスお待ちしております。

*1:今までも会うたびに、むしろ最初に会った時からずっと、「Emacsの設定をモダンにしろ」と言われ続けていました。いつも最新のEmacs事情が聞けて楽しい。

*2:主にEmacs

*3:ラジオでの@tadsanの発言より

*4:fido-modeは誕生の経緯からicomplete.elにあるようです

*5:簡単のため、このエントリではソースコードへのリンクをGitHubにある非公式のミラーリポジトリに貼っています。ref: https://www.reddit.com/r/emacs/comments/4bg3b6/what_is_the_emacs_github_mirror_for/

*6:たぶん https://github.com/emacs-mirror/emacs/blob/e6ad99e36c6c2e5322381f8af48cc283d2d899dc/lisp/minibuffer.el#L4826-L4828C25 らへん

2024年の振り返りと2025年の抱負

明けました

2024年の振り返り

2024年の初めは漠然としていました。しかし、蓋を開けてみれば、新規事業におけるサポートや設計のテコ入れ、チームメンバーとのコミュニケーションなどで、慌ただしく過ぎていった気がします。

（多少私が一日の長があることから）同じソフトウェアエンジニアとして、チームメンバーへ大小フィードバックをしたりしていましたが、「打てば響くとはこのことか」という具合に、目を見張る勢いで自力にしていく様を眺めていました。すごかった。 次のアウトプットを期待せざるを得ないです。楽しみにしています。

そして（ちょうど時期的には並行していましたが）、見つけてしまったテイラー株式会社に意を決してコンタクトをとり、結果として転職することになりました。

2025年、年始早々から、そわそわしています。

OSS

2024年、振り返れば結構少なくなったな...。とはいえ一生使いそうなパッケージも作れた気がします。

runnは無事(?)v1にはなりませんでした。 が、多くの企業で使われていることを観測させてもらい（みなさんアウトプットありがとうございます！！！）、それらの環境に微力ながら貢献できていると思うと、身が引き締まる思いです。

zenn.dev

年末に個人的念願の defer: と force: の機能を実装したので、早めにクックブックに登録しないと。

発表

発表も少なかったです。後半は意図的にプロポーザル投稿を抑えていましたが、それでも少ないかもです。

現在応募しているプロポーザルもPHPerKaigiだけです。

fortee.jp

（もし内容に興味がでてきましたら是非スターをください！）

今年はどうなるんだろう。。。登壇を止めようとかは全くないのですが、やはり内から湧き出る何かを共有したいので、今のところはわかりません。

2025年の抱負

今年は「一歩踏み出す」かなと思っています。いろんな意味で一歩踏み出していかないと立ちゆかなくなりそうなので、歯を食いしばってやっていこうと思います。その場から動くことがものすごくストレスになる人間なのですが、ここは踏ん張りどころかな、と。

今年もどうぞよろしくお願いします。