gh auth loginで作成されたクレデンシャルだけで生活するためにgh-doを作った

GitHub CLIgh auth login で作成されたクレデンシャルはOSのセキュアストレージに保存されるようになりました。

次のエントリが詳しいです。

blog.kyanny.me

「じゃあ、もう全部セキュアストレージに保存されたクレデンシャルを使えばOK」となるのですが、なかなかそうはいきません。

なぜかというとGitHubのクレデンシャルを使うツールによって環境変数の扱いが異なるからです。

GitHubのクレデンシャル設定の歴史(私の記憶版)

注意: 以下は、あくまで私の記憶であって実際と異なるかもしれません。

前史

GitHub CLIgh )やGitHub Actionsの登場以前は、クレデンシャルを保存する環境変数名として使われていたのは GITHUB_TOKEN でした。また、github.comとEnterpriseを切り替えるための環境変数名は定まっていなかった気がします。

GitHub Actions の登場

GitHub Actionsが登場したことで、GitHub Actionsがデフォルトで設定している環境変数が認知されるようになってきました。

docs.github.com

これにより、 GITHUB_API_URL といった「github.comとEnterpriseを切り替える」環境変数に対応したツールが登場してきました。

GitHub CLIgh )の浸透

そしてGitHub CLIが広く使われるようになってきて、GitHub CLIがサポートする環境変数GH_HOST GH_TOKEN など)が認知されるようになってきました。

cli.github.com

異なる環境変数の取り扱いにまとめて対応する

上記のような経緯が(たぶん)あったので、GitHubのクレデンシャルを扱うツールはその登場時期によって認識する環境変数が異なります。

独自に環境変数名を定めているものはしかたないとしても、当時のデファクトスタンダード環境変数に対応していたツールにはなんとか対応したいと考えました。

また、GitHub CLIには gh auth token というトークンそのものを取得するコマンドがありますが、「github.comとEnterpriseを切り替える」環境変数まで設定してくれる訳ではありません。

というわけで、gh-do というコマンドを作りました。

gh-do

github.com

gh-doは何かというと gh auth login で保存されたクレデンシャルとホスト名を使って環境変数を設定してくれるツールです。

インストール

gh-doはGitHub CLI 拡張機能としてインストールして gh do として実行できます。

$ gh extension install k1LoW/gh-do
$ gh do --help
gh-do is a tool to do anything using GitHub credentials.

Usage:
  gh-do [flags]

Flags:
      --help
  -h, --hostname string   The hostname of the GitHub instance to do
      --insecure          Use insecure credentials
  -v, --version           version for gh-do

また、単体のコマンド gh-do としてインストールすることも可能です。macOSであれば Homebrewでインストールできます。

$ brew install k1LoW/tap/gh-do

使い方

引数にコマンドがあれば、環境変数を設定したうえでコマンドを実行してくれますし、

gh do -- any-command arg arg arg

引数が何もなければ環境変数をexportコマンドの形で出力します。

$ gh do
export GH_HOST=github.com
export GH_TOKEN=gho_xxxxxXXXXXXXXxxxxxxxXXXXXXXXXxxXXxxx
export GH_ENTERPRISE_TOKEN=
export GITHUB_ENTERPRISE_TOKEN=
export GITHUB_TOKEN=gho_xxxxxXXXXXXXXxxxxxxxXXXXXXXXXxxXXxxx
export GITHUB_API_URL=https://api.github.com
export GITHUB_GRAPHQL_URL=https://api.github.com/graphql

github.comとEnterpriseの切り替え」も環境変数 GH_HOST を読んで自動で切り替えてくれます。 また --hostname ( -h ) オプションで切り替えることも可能です。

$ gh-do --hostname enterprise.internal
export GH_HOST=enterprise.internal
export GH_TOKEN=gho_yyyyyYYYYYYYYyyyyyyyYYYYYYYYYyyYYyyy
export GH_ENTERPRISE_TOKEN=gho_yyyyyYYYYYYYYyyyyyyyYYYYYYYYYyyYYyyy
export GITHUB_ENTERPRISE_TOKEN=gho_yyyyyYYYYYYYYyyyyyyyYYYYYYYYYyyYYyyy
export GITHUB_TOKEN=gho_yyyyyYYYYYYYYyyyyyyyYYYYYYYYYyyYYyyy
export GITHUB_API_URL=https://enterprise.internal/api/v3
export GITHUB_GRAPHQL_URL=https://enterprise.internal/api/graphql

デフォルトではOSのセキュアストレージに保存されたクレデンシャルしか使わないようになっていますが、--insecure オプションを付与することでGitHub CLIと同様にクレデンシャル用環境変数にも反応してくれます。

$ gh do --insecure

ところで

envchainにまとめるというのも汎用性高くてとてもオススメです。

github.com

というわけで

gh auth login で作成されたクレデンシャルだけの生活がはじまる...

github.comのSettingsにあるクレデンシャルはゼロ)

と思ったのですが、現在はまだ完全には至っていません。

Jasperめちゃ便利なのでオススメです*1

jasperapp.io

*1:GHESのPR/Issueビューワーとしてフル活用しています

Calendar Versioningを扱うパッケージ/ツールとしてcalverを作った

提供する機能とは関係なくリリースを定期的に実施するようなプロダクトや、バージョンにSemantic Versioning(以下SemVer)のような意味付けがしにくいプロダクトの場合、バージョン管理手法にCalendar Versioning(以下、CalVer)というものが採用されることがあります。

calver.org

例えば、CalVerのサイトに掲載されているケーススタディで私が知っていたものとしてはUbuntuのバージョニング( YY.0M.MICRO )があります。 22.04 とか 22.10 とかのアレです。

そしてちょうど私がバージョニングしたいプロダクトも

  • 1ヶ月に1度定期的にリリースしたい
  • しかし、なにかしらの要因で1ヶ月に1度以上リリースすることがある

というものでSemVerではない気がするし、とは言え単純に 年月 でバージョニングすると同月リリースがあるとバージョンがかぶることがあるということでCalVerを採用することにしました。

そして、CalVerを操作するパッケージやツールを探したのですが微妙に用途にあわなかったため、車輪の再発明ですが作りました。

calver

github.com

calver はGoのパッケージでありツールであるのですが、多くはツールとしての利用することが多いと思うのでツールとしての calver の紹介をします。

CalVerのバージョンの管理方式は1つではありません。なので calver ではまずバージョンレイアウトを指定します。

$ date
Mon May 15 13:01:27 UTC 2023
$ calver --layout YYYY.0M.MICRO
2023.05.0
$ calver --layout YY.MM
23.5

指定できるパーツはCalVerのSchemaの項に掲載されているものが使用できます。

次のバージョン

そしてCalVerの特徴的なものが「次のバージョン」です。

レイアウトが YYYY.MM.MICRO、 カレントバージョンが 2023.4.0、現在の日付が2023年4月だった場合、次のバージョンは 2023.4.1 になります。 ところが、レイアウトが YYYY.MM.MICRO、 カレントバージョンが 2023.4.0、現在の日付が2023年5月だった場合、次のバージョンは 2023.5.0 になります。

日付表記のバージョンが被った場合のみ、数値バージョンの部分がインクリメントされるのです。

calver では対象となるバージョンと --next オプションを付与することで次バージョンを計算できます。

$ date
Tue May  9 13:04:09 UTC 2023
$ calver --layout YY.0M.MICRO
23.5.0
# 対象となるバージョンを標準入力もしくは引数で与えることができる
$ calver --layout YY.0M.MICRO | calver --layout YY.0M.MICRO --next 
23.5.1

最新のバージョン

「次のバージョン」の元となるバージョンは「最新のバージョン」です。

calver は標準入力もしくは引数で複数のバージョンを与えると、最新のバージョンを取得し表示します。また、その中に指定のレイアウトに合致しないバージョン文字列があっても無視します。

具体的には次のようにバージョニングされたリリース群に対して使うことを想定しています。

$ date
Tue May  9 13:04:09 UTC 2023
$ gh release list | cut -f 1
v1.1.2
v1.1.1
2023.05.1
2023.05.0
v1.1.0
v1.0.1
2023.03.1
2023.03.0
v1.0.0
2023.02.0
v0.1.0
$ gh release list | cut -f 1 | calver --layout YY.0M.MICRO
2023.05.1
$ gh release list | cut -f 1 | calver --layout YY.0M.MICRO --next
2023.05.2

--trim-suffix

UbuntuのCalVerのレイアウトは YY.0M.MICRO らしいです。ただし、 MICROバージョンが 0 の場合は末尾の .0 が省略されます。

それを実現するオプションとして --trim-suffix を用意しています。

$ date
Tue May  9 13:04:09 UTC 2023
$ calver --layout YY.0M.MICRO --trim-suffix
2023.05
$ calver --layout YY.0M.MICRO --trim-suffix | calver --layout YY.0M.MICRO --trim-suffix --next
2023.05.1

MODIFIERバージョンを特別に扱ったりなど、かなり用途に沿った実装をしたつもりです。

というわけで

もしCalVerを使う機会がありましたらcalverを検討してみてください。

OSSとPHPerKaigi 2023

3月23日から25日までPHPerKaigi 2023に参加してきました。

phperkaigi.jp

参加してみての感想は、一言で表すと

かつて思い描いていたカンファレンスと、想像以上を提供してくれるカンファレンスの融合を体験できて楽しかったし嬉しかった

です。

想像以上の体験を提供してくれるカンファレンス

これはPHPerKaigiのことです。

カンファレンス運営に対して狂気ともいえる情熱を注ぎ続ける主催者と、それを強固にバックアップするスタッフの方々が存在することにより実現される体験。まだ今年で4回しか参加していませんが、常にアップデートされています。アップデートの方向も想像がつかないです。毎回毎回楽しい(毎回同じでも楽しいのに!)。

あらゆる場所にエンターテイメントがあり、おもてなしがあり、当日以前にもカンファレンス開催前のビッグなノベルティボックスや、事前登壇の自動録画機能など驚きがあります。

2020年のグッズで今だに遊べるのがすごいですよね。まだ遊べる。ずっと遊べる。

かつて思い描いていたカンファレンス体験

日本のカンファレンスで有名なものの1つにRubyKaigiがあります。

私は一参加者としてRubyKaigi 2017に参加させてもらったことがあります。

RubyKaigi のオススメコンテンツは廊下」という言葉があるらしいのですが、RubyKaigi 2017でそれを見る機会がありました。

2階に上がる階段の下にたまたまあったようなホワイトボードを使ってRubyのコミッタの方々が(おそらくRubyの実装について)議論していました。何回か通りがかったのですが、ずっと議論していました。

そういえば、かつて学生時代に参加した学会でもそういった様子を見ることがありました*1

ただ、私は「見ていた」だけでした。当事者ではなかったのです。

とても羨ましく感じたのを覚えています。「希少なオフラインで会う機会を使って自分たちのOSSや研究を進める」というのがカッコよく感じました。

カンファレンスにずっとそういった思いを持ち続けて、今年、PHPerKaigiでその体験を得ることができました。

runnを一緒に開発しているkatzumiさんがPHPerKaigi 2023に参加されるということだったので、「これだ!」とばかりにrunnの次の機能について議論させてもうことができました。

詳しくはkatzumiさんが書いてくださったエントリが全てです。

zenn.dev

延々と「オタクの早口」で話していた気がします。ずっと嬉しくてテンションが高かったのを覚えています。

PHPerKaigiは場を提供してくれている

ところで、PHPerKaigi会場に「もくもく会スペース」があったのはご存じですか? runn開発者会議ではこの場を有効活用させてもらったりしました(ホワイトボードも少しお借りしました)。

もくもく会スペース」があるということは「もくもく」が推奨されているということです。Track Cとして「突然の発表(アンカンファレンス)の場」も提供されていましたね(Dでも発表がはじまったとか)。

「PHPerKaigiはコミュニティ」といわれているとおり、PHPerKaigiの会場が「発表と聴講の場」以上の設計がされているのがわかります。PHPerKaigiはあらゆるコミュニケーションに開かれていると感じます。

そして、PHPerKaigiはOSS開発にも開かれていました。

runn開発者会議ができて、自分の思い描いていたカンファレンス体験ができたのはPHPerKaigiの場のおかげです。

カンファレンス中の成果

カンファレンス中の成果です。

tblsのER図の出力調整

tblsのER図(SVG)の出力が微妙(私も薄々感じていました)というフィードバックをもらって、それをごりっごりのワークアラウンドで対応しました

runnクックブックにレシピ追加

CDPランナーの使用において必要になる設定についての紹介レシピを追加しました。

runnのSSHランナーでsudoができるのかを確認

SSHランナーは keepSession: true でセッションをステップ間で維持できるのですが、PHPerKaigi内での質問に「sudoも大丈夫なはず」と回答したのですが不安だったのでテストを追加して試してみました。

github.com

runnでシナリオのステップごとの成功/失敗を記録

これがrunn開発者会議のメイン議題だったのですが、「ステップが失敗してもそのまま継続して最後まで実行したい」というユースケースに対応するべく、まずはrunnのシナリオのステップごとに成功/失敗を記録するように内部実装をいじっていました。

Release for v0.65.0 by github-actions[bot] · Pull Request #468 · k1LoW/runn · GitHub

で、「ステップが失敗してもそのまま継続して最後まで実行」したとして「そのシナリオは果たして成功なのか失敗なのか」についてkatzumiさんと議論して、「そのシナリオは失敗だろう」ということに落ち着きました*2

GitHub Actionsの continue-on-error: を例に出して議論していたのですが「実現したいユースケースは多分 continue-on-error: とは違う」ということになり、設定名も違うものになりそうです。

近いうちに実装を終わらせます。

OSSとPHPerKaigi 2023

思えば、パンフレットに趣味OSSについて寄稿させてもらったり、

fortee.jp

発表の一部でOSSについて紹介させてもらったり、

runn開発者会議をしたり、

懇親会でEmacsユーザミートアップをしたり、

私のPHPerKaigi 2023はOSS色の強いものになりました。

実際はそれだけではなくて、 ペンライトが意外に楽しくてブンブン振ったり、コーヒーとビールが無限だったり、uzullaさんの最高のエンターテイメントでかつ強く考えさせられる発表で「D!T!O!!!D!T!O!!!」と手拍子したり*3、N次会で綺麗なそーだいさんをみたり*4、非公開なこともあったり*5、濃い三日間でした。

運営の皆様、スポンサーの皆様、発表者の皆様、ありがとうございました!

「また来年!*6

*1:研究会ごとに分野が絞られているのでそういったことが発生しやすいし、むしろそれが重要コンテンツなんだと思います

*2:2人でいろいろ考えて議論しました

*3:是非録画で見てほしい

*4:残念ながら録画でもみれない

*5:何も書けない。匂わせもできない

*6:ってクロージングで小桜エツコさんの声で言ってた

tblsをセットアップするGitHub Actionとしてsetup-tbls(を作るツールとしてgh-setup)を作った

タイトルが何を言っているのかよくわからないと思いますので順を追って紹介したいと思います。

tblsをセットアップするGitHub Actionとしてsetup-tbls を作った

setup-tblsはtblsをインストールしてくれるGitHub Actionです。

github.com

各所で「ないの?」とは言われており(最近Issueもたった)、いつか作らないとなと思っていたのですが、いろいろ重なって作りました。

github.com

私はGoで作ったツールのActionはDocker container actionを使うのですが、tblsでそうするとDockerコンテナ上で動くtblsからデータベースサーバの名前解決ができなかったりして、それも手を鈍らせている原因でした。

今回作成した setup-tbls はComposite actionで作っているので上記のような心配もありません。

なお余談ですが、ActionというかRunner上のJobの実行環境については次の資料にまとめてあります。

speakerdeck.com

使い方は簡単で紹介するまでもないですが、 uses: k1low/setup-tbls@v1 で呼び出せば終わりです。

# .github/workflows/doc.yml
name: Document

on:
  push:
    branches:
      - main

jobs:
  doc:
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout .tbls.yml
        uses: actions/checkout@v3
      -
        uses: k1low/setup-tbls@v1
      -
        name: Run tbls for generate database document
        run: tbls doc

setup-*GitHub Actionを作るためのツールとして gh-setup を作った

setup-*install-* というActionは、大抵は実行ファイルをPATHに設置してくれるものです。

Goであれば本当にバイナリポン置きでいいのですし、そのバイナリは大抵GitHub Releasesにあるのであとは設置するだけなのですが、意外にこれが面倒なのです。

  1. まず実行環境を特定する(OSやArch)
  2. GitHub Releasesから特定バージョンもしくはlatestなリリースを特定
  3. 1の実行環境に適したリリースアセットを特定
  4. 3のリリースアセットが圧縮ファイルだったら展開
  5. 4の展開したファイルから必要なもの(今回は実行ファイル)だけ取得
  6. 実行環境のPATHを特定し5のファイルを設置

また、GitHub Releasesへのアセットの置き方も開発者によって、リポジトリによって千差万別です。私個人でもバラバラです(その時々でマイブームがある)。

それをいい感じにしてくれるツールとして gh-setup を作りました。

github.com

使い方はいくつかあるのですが、今回はGitHub Actionとしての使い方を紹介します*1

例えば、tblsをインストールする場合は以下のように書けます。

# .github/workflows/doc.yml
[...]
    steps:
      -
        name: Setup k1LoW/tbls
        run: k1LoW/gh-setup@v1
        with:
          repo: k1LoW/tbls

これだけで、煩わしい「GitHub Releaseからアセットを取得して実行ファイルをPATHに設置」をやってくれます。 中身は結構泥臭い実装が入っています。気になる方は是非 gh-setup のソースコードをご覧ください。

また、泥臭い実装を信用できない人にもいろいろオプションを用意していますので、詳しくは action.ymlのinputs:セクション をご覧ください。

さて、ここまで来たら勘のいい方はわかるかと思いますが、setup-tblsはgh-setupを組み込んで作っています。

setup-tblsのaction.ymlは次のとおりです。

name: 'Setup tbls'
description: 'GitHub Action for tbls, a CI-Friendly tool for document a database, written in Go.'
branding:
  icon: 'box'
  color: 'blue'
inputs:
  github-token:
    description: The GitHub token
    default: ${{ github.token }}
    required: false
  version:
    description: Version of tbls
    default: latest
    required: false
  force:
    description: Enable force setup
    default: ''
    required: false
runs:
  using: 'composite'
  steps:
    -
      uses: k1LoW/gh-setup@v1
      with:
        repo: github.com/k1LoW/tbls
        github-token: ${{ inputs.github-token }}
        version: ${{ inputs.version }}
        bin-match: tbls
        strict: true
        force: ${{ inputs.force }}

これだけです。ほとんどの処理はgh-setupの中にあります。

setup-* というGitHub Actionを作りたい方へ

是非 gh-setup をご検討ください。うまく動かない、気に食わない挙動についてはフィードバックいただけると嬉しいです。

これで setup-* は作りたい放題!

*1:実はGitHub CLI extensionとしてもスタンドアローンCLIツールとしても使えます

データベースドキュメント生成コマンド tbls 更新情報(Mermaid対応 / schema.json / tbls outの強化)

久しぶりのtblsの新機能紹介エントリです。

ドキュメントのER図出力にMermaidを指定できるようになりました

ER図の出力フォーマットにMermaidを指定できるようになりました。次のように er.format: セクションか --er-format オプションに mermaid を指定することで変更できます。

er:
  format: mermaid

開発裏話

GitHubがMermaid対応したことで「tblsもMermaid対応してほしい」という要望や提案は以前より多く受け取っていました。 しかし、個人的にあまりメリットを見出せずそのままPull Request待ちとなっていたのですが、今回エイッと作ってみました。

Mermaid対応をするにあたって1つとても面倒な仕様がありました。それはMermaidはER図の多重度(カーディナリティ)の指定が必須となっていることでした。

もともとtblsが持つスキーマ情報にはカーディナリティがなかったのと、カーディナリティはスキーマの情報から一意に決まるものではないので、今回のMermaid対応に向けて次の機能を追加しました。

  • リレーション情報をオーバーライドする機能(修正できる機能)
    • 自動判定されたカーディナリティを修正するため
  • スキーマ情報にカーディナリティを新たに新設
    • そもそもカーディナリティの概念がスキーマ情報になかったため
  • カーディナリティの自動判定
    • 現状と同等のステップでER図を生成するため「Mermaidの場合はカーディナリティを手入力」という方向は取れないため

Mermaid対応よりむしろこちらのほうが大変だったのはいうまでもありません。

ドキュメントの出力と同時に schema.json を出力するようになりました

ドキュメントの出力と同時に、スキーマ情報を集約した schema.json を出力するようにしました( tbls out -t json で出力されるものと同等のものです)。出力先はドキュメントの出力ディレクトリになります。

目的としてはスキーマ情報の構造化データの保持です。

tbls doc で出力されるMarkdown形式のドキュメントはあくまでドキュメントで、構造化データとは言いにくいものです。都度データベースに接続してスキーマ情報を解析しなくても良いように一度取得したスキーマ情報を構造化データとして保持するようにしました。

開発裏話

実は、schema.jsonのファイル名を何にするかと、その出力先をどこにするかを本当に悩みました。

Issueでいろいろご意見を下さった皆様、本当にありがとうございました。

tbls out を強化しました

tbls out コマンドを強化しました。

github:// スキームに対応( tbls out だけでなく tbls doc tbls diff でも使用可能)

schema.jsonGitHubリポジトリから直接取得してデータソースとして使用可能です。

出力するテーブルを制御する --include --exclude --table オプションを整理。さらに --label オプションを追加

tbls out で出力するテーブルを制御するオプションを整理しました。またテーブルに付与しているラベルでも出力テーブルをフィルタリングできるようになりました。

開発裏話

tblsは基本データベースドキュメントを生成する tbls doc コマンドがフィーチャーされるので tbls out はあまり目立たないですが、個人的には今回の新機能の目玉はこちらのほうです。

schema.jsonをデフォルト出力にしたことで、将来的にはデータソースドキュメントをtblsで管理しているリポジトリには schema.json もコミットされるようになるはずです。

そうすると次のようなことが簡単にできるようになります。

$ tbls out github://k1LoW/tbls/sample/mysql/schema.json -t mermaid --table users --table posts
erDiagram

"posts" }o--|| "users" : "FOREIGN KEY (user_id) REFERENCES users (id)"

"posts" {
  bigint id PK
  int user_id FK
  varchar_255_ title
  text body
  enum__public___private___draft__ post_type
  datetime created
  datetime updated
}
"users" {
  int id PK
  varchar_50_ username
  varchar_50_ password
  varchar_355_ email
  timestamp created
  timestamp updated
}

tblsで管理されている最新のスキーマ情報をデータベース接続なしにいつでも取得できるようになります。

また、 tbls out コマンドで対応しているフォーマットにはMermaidだけではなくPlantUMLやJSONSVGPNGなどもあります。

私はこれを「"スキーマ情報の取得"から"スキーマ情報の活用"への道が開かられた」と捉えています。

テーブルに付与するラベルを活用することで、ラベルで意味のあるグルーピングされたテーブルのER図だけ出力するということもできます。 ここらへんのグルーピングはndiagでも実装したビューポイントの考え方につながってくると思っています*1


というわけで、

そうです。仕込み、実はまだ続いています。

「runn クックブック」はじめました

昨年からrunnというオペレーション自動化ツールを開発しています。 runnの認知のされ方としては「インテグレーションテスティングツール」とか「シナリオテスティングツール」といったほうがいいかもしれません。

github.com

runnにはさまざまな機能があります。 しかし、その機能全てを作者である私自身が紹介しているかというと全くできていない状況です。Twitterですらつぶやいていない。

READMEもできるだけ書いていますが、十分とは言い難い。

これは良くないと思い、もう少し頑張ることにしました。

今後、しっかりとrunnの機能の紹介をしていこうと思います。

runn クックブック

というわけで「runn クックブック」はじめました。

zenn.dev

せっかくならストックされていく形が良いだろうと思い、Zennの本の形式で書いていくことにしました。 また、「どうせ一気に書ききることは難しいだろう」「本の構成を決めて書くこともできないだろう」と判断していわゆる「クックブック形式」で書くことにします。

この本は、不定期でレシピの追加や編集をする形で運用する予定です。 まだ紹介していない機能やユースケースがあるので、今後もレシピを増やしていこうと思います。

(runnの新機能を「runn クックブック」で紹介するような習慣ができるといいな...)

ちょっと実験

はじめて「本形式」で書くのですが、最初で最後の可能性もあるので「有料」の実験をしようと思っています。 この本は500円の有料本としていますが、無料公開範囲をちょいちょい変更してみようと思っています。 なので、購入する場合は注意してくだい。明日には全てが無料公開範囲になっている可能性もあります(逆もあります)。 ただ、もし、もし購入していただけたら開発や執筆のモチベーションになります。どうぞよろしくお願いします。

2022年の振り返りと2023年の抱負

2022年の振り返り

2022年はそれなりに変化のあった年でした。 仕事もですがプライベートの方面で多くの変化がありました。一番大きいのは引越しです。変化を嫌う私としては当時本当にストレスだったのですが、今、「引っ越していなかったら」と思うとゾッとします。むしろ変化に耐えられた要因の1つが今の家だったと思います*1

2021年に「自分が何が好きなのか」を言語化できて2022年を過ごしてみて、振り返ってみるとやはり「開発者のための開発」が好きなんだと感じました。 ますます「何エンジニア」なのかわからなくなってきているのでその点は悩みです。

2022年の抱負は「挑戦する」でした。 「挑戦したか?」というと疑問が残るところです。

ごく小さな挑戦としては新しい勉強会コミュニティへの参加があります。 1つは開発しているツールが対象とする領域のコミュニティでの発表、もう1つはツールを開発しても良い場への参加をしました。

testautomationresearch.connpass.com

gophersou.connpass.com

どちらもとても楽しかったです。

ソフトウェアテスト自動化カンファレンスでは、カンファレンスを通してテスト自動化の世界の広さだったり普段テストを生業としている方の考えを体験できたのがよかったです。

ごーふぁー荘は、後期TechTouch*2や私が参加させてもらっていた時代のFukuoka.rbを思い出してしまい、とても居心地が良いです。また参加したいです。

あと、大名エンジニアカレッジで講師をさせてもらいました。

daimyo-college.pepabo.com

「人に教える」は本当に難しいと感じた体験でした。

OSS

2022年は2021年と比べて新規は少なかったですが、既存OSSのメンテナンスも多かった気がするのでこんなものかなと思っています。

2022年最も力を入れたOSSは何かと問われたら runn です。「runnの開発のためにOSSを書く」ということも多かったです。

2023年ももう少しrunnに力を入れていきます。「自身のツールを広める」という意味での広報面も強化したい。

発表

お誘いいただいたのを含めて4件。少なかったかなあという印象です。

2023年の抱負

今年は「書く」です。

コードを「書く」もですが、Issueを「書く」、Slack TLに「書く」、文書を「書く」をやっていきたいです。Twitterも書いていく。あと「描く」も再開したい。

リモートワークがメインになっている状況だと「書かない=いない」になります。もっと書いていかないと本当に存在が希薄になっていくなあと感じています。普段出不精なのがインターネット活動にまで影響しはじめていて本当にヤバい。家族にしか存在を認知されなくなってしまう。

「アウトプットをした結果インプットできる」というのは各所で言われていますし私もそう思っています。書くもアウトプット。

「書いていくぞ!」というか「(もう一度)書くのに慣れるぞ!」という気持ちです。

あ、あ、あ、あ、あと分割キーボードを今年こそ!手に入れたい。買うキーボードはもう決めているんです。

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

*1:何にゾッとしていたのかについてはここでつらつら書く話でもないので直接会った時にでも聞いてください。主に子育ての話なので特に面白い話でもないです。

*2:会社の名前ではなく、はるか昔に私が運営していた勉強会というかもくもく会です。