Go Conference mini 2023 Winter IN KYOTOに参加してきた #kyotogo

Go

京都に行ってきました。

Go Conference mini 2023 Winter IN KYOTO

kyotogo.connpass.com

すでに、ne-sachirouさんによりスライド資料などが集められています。感謝！

scrapbox.io

「miniとは？」となるGoで濃縮された1日になりました。運営の皆様、本当にありがとうございました！

私はと言うと、登壇はしたものの完全にカンファレンスを楽しんでいました。

本編

以下、一言感想です。

Deep dive into log/slog package

既に使ってはいましたが、実装は特にみていませんでした。普通に使えるイメージ。

「nAttrInline = 5」の理由がなるほどなあという理由でした。これ再度計測してレポートしたら変わってくるような値なんですかねー。

Goプログラムがビルドされるまで（コンパイラーの仕組みを探る）

まさにタイトルの通りで、非常にわかりやすい丁寧で面白い発表でした。コンパイラがわかった気になってしまうくらいのわかりやすい発表である意味注意しないといけない発表でした。

Goにおけるcall graphを用いた大規模コードベースの影響調査

私の発表前で、残念ながらリアルタイムでは聴講できませんでした。XのTLがざわついていたのが印象的でした。

あとで資料を拝見させてもらったのですが、影響調査のためのコールグラフを使うというアプローチはなかなかな腕力だなと思いました。すごい。

最近PHP界隈でも「ASTが同じならOK」みたいな腕力が流行っている？ようですけどなんかブームですかね？

Parsing case study in Go

私の発表です。

speakerdeck.com

公開できる事例の多さでは自信があったので（OSSなのでそれはそう）、とにかく事例を詰め込みました。

何かしら持ち帰ってもらえれば幸いです。

日時処理の新スタンダード: Synchro によるタイムゾーン安全、楽々開発

Xで開発しているときから知っていたのですが、とても良いパッケージだと思いました。

じゃあこれを明日からプロダクションに採用するためにはあと何の検討が必要かなーと考えていました。

Go1.22で導入予定だったzeroというbuilt-inについての紹介

大どんでん返しと貴重な経験のお話で面白かったです。

Go Getでのchecksum不一致に遭遇した話とその対応

これは...逆にやらかしたことがあるので、逆にすみませんと言う気持ちになっていました。

CUE+Goで安全かつ簡単に設定ファイルを自動生成してみた

CUEもずっといつか必要になるかも！？と思っているのですが、普段は360YAMLからは一桁二桁小さい数しか扱わないので、いつかのために今後もウォッチしておこうと思います。

context.WithoutCancelについて語る

「伝搬してきた値は使いたいがキャンセルされたくない」というニーズは分かっていたのですが、しっくりきていませんでした。しかし、「contextは値を伝搬する要件とキャンセルの要件の2つを担っていて、現状それを分けることが難しい」という説明にしっくりきました！

Golangを使ったDB用負荷テストツールの開発

流石の tools でした。コードも読んでみようと思いました。あとご挨拶できなかったのが残念（失敗の1つ）。

インターフェースのラッパーを作る際の落とし穴

ラップすると型アサーションに失敗する挙動については知らなかったです。全部作るのは確かに面倒そうだなと思いました。

生成AIによる静的解析ツールの自動生成

静的解析に求められる正しさと生成AIがもたらすまだ不安定な出力の相性って悪いんじゃないかなと思っていたのですが、 確かに https://github.com/gostaticanalysis/skeleton にあるようにある程度テンプレート化されているコードの穴埋めという意味だと「いけそう」と思いました。

The Future of encoding/json

「encoding/jsonはJSONエンコードしてくれればいいんじゃ？」と思っていたのですが、この発表で「なるほど良い」と思いました。便利パッケージが1つ増えるのを待つ気持ちです。

続) TinyGo で作る自作キーボードの世界

びっくりした！あんなに簡単にキーボードできるのか！！！！！！！！！

触って理解するGoコンパイラの最適化

感想はこちらになります。

開発チーム横断タスクフォース「Goサブ会」の運用事例と今後の展望

ペパボでもチャプターやGoの情報共有会はあるのですが、Goサブ会はまた違うものでした。 懇親会でも詳しく聞いたのですが、雑な理解で言うと「権限と責任がある」横断組織となっているようでした。

そういう組織がプログラミング言語のくくりであることが「強い！」と思いました。

プロダクションで使うGo Pluginの利便性とパフォーマンス性

「プラグインとは」からはじまりGoでできるプラグインのアプローチの紹介でした。

公式見解キツいw

ちなみに私は git-style が好きです。

Revolutionising Inheritance with Generics: A Fresh Approach in Go

Genericsの効果的な活用のお話でした。時間切れだったのであとで資料を拝見しましたが、Genericsを使って親structをつくりつつその親の構造体の1フィールドに子を渡しておくというのはなるほどと思いました。 Embeddingとちょうど依存が逆になっているから「責任の逆転」と言っているという理解でした。

net/http から net.Conn を掘り起こす

なんかreflectパッケージとかを使って引っ張り出すのかな？と思ったらちゃんと正攻法で取得できていました。 知らなかったので知識として覚えておこうと思いました。

GoとテストとインプロセスDB

テストでインプロセスDBを使う話。httptestスキーとしては興味津々で聞きました。

使うためにバグを薙ぎ倒していくのが印象的でした。

個人的な使い方としては syumai さんのポストの方法がよいなあと思いました。

ブログのリアクションから始めるGoのパフォーマンス分析入門

カッコ良すぎるムーブでした。見習いたい。

GoのProtocプラグインを活用した効率的なgRPC負荷試験戦略

.protoファイルからの生成、良いアプローチだと思っていて、私ももっとプラグイン書いて生成していかないとなあと思いました。

作ってよかったgraceful shutdownライブラリ

「Hatenaの知見」「Goサブ会の知見」となっているのが最高だと思いました。

runn開発者会議 in 鴨川

runnの開発者が揃ったので恒例のオフラインでの開発者会議をしていました。懇親会までの時間、鴨川で。

今回出た機能検討は覚えている限りだと次のような感じ

  1. ファイルの存在有無などで実行するステップを変えたい
    • ビルトイン関数への実装以外で何か良いアイデアはないか
    • Fileランナーを作っていいのだろうか
  2. 複数のAPIサーバへリクエストをするようなシナリオで、一部のAPIサーバだけモックしたい
    • 同じシナリオを使ってそれぞれのAPIサーバ開発でテストを行うイメージ
    • https://github.com/vcr/vcr 的な挙動が必要？
  3. 成功したステップをスキップしつつ成功時の値はキャッシュとして利用したい
    • ユースケースとしては2のほうと同じなので、あくまで実現方法の違い
  4. APIテストを担うことが多いが、テストランナーの現状のワンライナーしか許容しない記法があまり可読性良くない
    • 別の記法「も」サポートしたほうが良さそう

どれも実装にいたるまでは詰められなかったので、一旦寝かせてあとはオンラインで引き続き。難しい。。。

懇親会

Gopherのたしなみとして「ORMは何を...？」などから始めつつ、いろいろお話ししました。話が楽しかったのですが、一方でもっといろんな人に挨拶すればよかったなあなどと思いました。

あと、これは課題です。

あとはtenntennさんにPull Requestのレビューを直接お願いするというオフラインカンファレンスムーブをキメるなどしていました*1。

2次会

はてな社さんにお邪魔させていただきました。ただ、まあ、もうダメでした。楽しかったです。

感想

最初にも書きましたが本当に濃いGoな1日でした。

お疲れ様でした！ ありがとうございました！

*1:後日レビューしていただきました