こんにちは、ミツバです。 縁があって、Go Conference 2019 Springに参加することができました。 ありがとうございました。
聞いたセッション
keynote
goproxyを作成しているケイティーさん
modulesはGoのバージョンの違いを吸収してくれて、Go Proxyではバージョン指定がきついのでプロキシを設けてバージョン問い合わせしたり、zipでの送受信ができるようにして、より楽にパッケージ管理が可能 (英語が危ういので違うかも)
checksumを設けて、本当に欲しいものだけを持ってこれるようにする
Case studies of designing developer friendly libraries
izumin5210さん :Wantedly
developer friendlyとは、simple, easy
Easyだと開発効率が高くなる反面、少し複雑なことをすると爆発してしまう しかしEasyは悪ではない
Goのcontext.ContextはI/Oの時間がかかる処理に利用する メトリクス収集にも利用可能 パッケージでは良く利用されている (例： newrelic/go-agent)
middlewareなどの概念も重要
拡張性の話
Redigoパッケージ doメソッドに処理を書いていく Connをラップすることでロギング周りの処理を変更可能だったりする
google-cloud-goパッケージ optionをNewするときにオプションを受けとれるようになっていて、オプションをさし替えることでユーザのちょっとこったことを実現する
functional option patternが拡張性が高くていい感じ builder patternもパッケージで利用されてたりしていて、拡張性は高め
functional option patternは以下の記事がわかりやすかったです。 qiita.com
wireは最高
Boilerplate生成 環境変数を設定しておくだけで各種設定を読みこんでくれるようなライブラリを作っている 足回りのことはある程度ライブラリに任せる選択もありかもという話
Better asset bundling tool than the best
shibu_jpさん: フューチャーアーキテクト
ne/httpのファイルシステムについて コンテンツの圧縮とかSPAとかで高速化を行っている
asset bundler から圧縮を解除してnet/httpに渡して、それを読んだ後、またまた圧縮してブラウザに返す処理をするそうなので、これを改善するやつを作ったよという話
brotliというcontent-encodingを利用すると爆速
Goならわかるシステムプログラミングを読みます
SPAの場合
buildしたやつをのローカルに置いておいて、それを読みにいく Goのバイナリ一個を持っていくことでできるようにする
assetsの暗号化もできる、便利
Goによる外部プロセス起動ベストプラクティス及びtimeoutパッケージ徹底解決
songmuさん
os/execパッケージで外部コマンドを実行できる TeeReaderを利用することで、teeコマンドのようなことが可能 command contextでタイムアウトとかが設定できる でも内部では、SIGKILLで止めてしまう
これによって、孫プロセスがずっと生き続けてしまうらしい SIGTERMを送りたいのだけど、Goはそれは各自でやってもらうという方針
そういうツールを開発 これはGNU timeoutを参考にしているらしい プロセスグループにもシグナルを送れる SIGCONTを送るようにもしておき、停止しているプロセスがあれば叩き起こす
Design considerations for container-based Go applications
hgsgtkさん
環境変数を見て、それらを一つの構造体として取得ができるGoパッケージ
zapを使ってカスタムロガーが作れる
ヘルスチェックは、エンドポイント生やして確認する DBなどもアプリケーションのエンドポイントから行ったりするらしい
Design pattern for Image and text composition in Go
timakinさん
赤い四角を書きたければ、各ピクセルに色を入力して画像として吐くようにしたい 画像とテキストの合成を行なう
/image/fontパッケージ imageにテキストを書きこめる
読みこめるfontが足りないので、freeetype/truetypeを使って読みこもうとしたけど、ヒラギノsansが読みこめない (つらい)
デザインパターン
- Processor
- Framer
- Drawer
- Labeler
- Encoder
ごにょごにょする
rakyll/statikパッケージ、assets importするときに利用できる
テキストをどこかで画像として保存しておいて、それを画像として合成するのも良い GoでのFont周りは意外ときついらしい
Dive into Buildkit LLB with Go
po3rinさん
mobyの機能を置き替える感じで Buildkitが登場 buildkitdというデーモンが立っていて、それをcliが叩く
buildkitctl のコードを見るとSolveが最終的に呼ばれている そして、llb.Definitionという定義がある
llbとは
ビルド時に利用しやすい構造になっているもの 非循環構造 DAG
llb2dotというツールを作成しこれを利用して、dot言語にして可視化ツールにながせる (便利)
buildkitには、Dockerfile2llbという関数があるので、それを使えば爆速でllb構造が手に入る
buildkitでDockerfileのparserがあるので、それを利用してASTを入手できる Dockerfile linterがお手軽に作れちゃう
Dockerfileを利用しなくてもllbは構築できるので、自作のファイル構造も利用可能
Fuzzy finder as a Go library
ktr_0731さん
行指向なので、オレンジという曲名がたくさんあったら一番欲しいものが不明 fzfを利用しているライブラリはfzfをインストールしないと利用できなかったりする。
なので、Go用のfuzzy finderを作った
検索アルゴリズム
Needleman-wunsch: fzyが利用しているアルゴリズム Smith-Waterman : fzfが利用いしているアルゴリズム
fzy: ALGORITHM.mdにスコアリングのルールが書かれている fzf: algo.goにスコアリングのルールが書かれている
Building Modules Discovery (from Go Team)
Goのパッケージの評価、コードクオリティや依存の話から、モジュールをその評価情報などから検索できるサービスを提供しようとしているよという話 (英語が危ういので違うかも)
Goのパッケージが探しやすくなると非常に熱いムーブメントが起きそうだなと思いました。
全体感想
個人的にGoという言語は、CLIツールなどを簡単に作成できて大好きなので、非常にどのセッションも有意義なものでした。
英語が危ういので、英語を聞きとれるようになりたいなぁと思いました。
buildkitは楽しそうなので、暇があったら中身を見てみたいと思いました。
