実用Go言語 Forkwell Library #7
基調講演
3人の著者による発表
渋川さん
- Honda
- DeNA
- FutureArchitect
- 趣味 インラインスケート
辻さん
- 渋谷区の公務員からフューチャー
- 趣味 競技プログラミング、筋トレ
真野さん
- 新卒でフューチャーで13年くらい
フューチャーのかるい紹介
- ITコンサル会社
- 一次請けで実施、開発実装まで
- 中立のポジション
- ないものはつくる
- 一部上場企業が顧客
執筆の経緯
Go Conf Fukuoka 2019
- GoのFAQに関する発表
- ディレクトリとパッケージ
- ポインタと値
- defer参照
- immutableしたい→ない
- GoのFAQに関する発表
発表目的
- シンプルで可読性が高いがそれによって難しい部分
- システムの複雑は変わらない
- 複雑な記述力のある言語 → 短く表現できるが、学習コスト大
- シンプルな言語 → 学びやすいが表現が長くなる
- Goだと複数の言語機能を組み合わせて実現することがある(イディオム)
- どのような組み合わせ(イディオム)があるのか、ベストなパターン集があったほうがGoの学習に良い
- シンプルで可読性が高いがそれによって難しい部分
発表をその後、技術ブログ化
せっかくなのでオライリー・ジャパンに売り込み
- C++FAQ、PythonクックブックのGo版
- Goクックブックという仮題でスタート
- Javaは知ってるけどGoは知らない人むけ
ついでにフューチャーの同僚に執筆者としてデビューするチャンスを提供
- 共同執筆者からなる人が多い
- 業界全体が枯れてくるおそれ
- 実績
書き続けるのは難しい
執筆の流れ
- Python製のSphinxを利用
- 細かな機能がMarkdownより充実している
- term-validatorで語彙統一
- HTML生成やPDF生成で生成してレビューがしやすい
- いままで使って執筆したことがある
- Python製のSphinxを利用
最終レビュー
- 社内読書会形式
- 1章ごとにファイルを共有し15~30分黙読
- チャットにコメント書いてあとから議論を行う
- レビュー後、構成の変更や内容の追加もした
- 社内読書会形式
書いてて苦労した点
書きたい内容がどんどん成長していく
- 業務で遭遇したネタが追加される
- 技術ブログに書き出して、供養したり追加したり
クックブック形式にしにくいトピックも多かった
- 落とし穴の紹介など
- 読者層として基礎から説明する必要があった
- カテゴライズできなかったものは1章に押し込み
サンプルコードを丁寧に書くのが大変
- バリエーションを持たせる
ライブラリとか周辺知識を抑えないと書けない部分をどこまでとりこむか
マニアックになりすぎないようにした
Goの本を書く難しさ
- 循環参照問題
- 説明をするのに用語が循環する
- 循環参照問題
改訂するなら追加したい内容
- grpc/GraphQL
- 世の中の知見も集まってきた
- Generics
- 新バージョンの目玉
- sliceやmapの処理をシンプルにできる
- いままではinterface{}をつかってキャスト
- Test周りのツールチェーン
- モックサービスを使ってテストする
- トレードオフとしてテスト時間は長くなる
- 対策として分散する仕組みなどの話
- 静的な解析ができるようにする仕組み
- リリース
- リリースフロー、差分をわかりやすくする
- 属人化しないようにChangelogの自動生成
- 起動時にに自分のバージョンをログ出力するトレースの仕組み
- Excelを操作する方法
- GoogleDriveに送信する
- 方眼紙
- Markdownを扱う
- 静的解析系
まとめ
- Java開発者がGoを書けるように
- 実際の業務の内容を取り込んだ
- Goのエコシステムの発展とともに成長させたい
Q&A
GoでOSS活動するのにおすすめのリポジトリ
- 自分で触るライブラリを見るのがよい
- 意図しない動作に関してプルリクをなげる
- OSSの一歩になることが多い
- 社内で作るOSSだと直接メンテナにきく
テーブル駆動テストが長くなる
- 関数を分ける
- 入力パラメーターが多くなることが原因になるので、そこを短くする
- csvを読み取ってparseする
Goの許せないところ、嫌いなところ
- Javaである数値演算のクラスとかがない
- 静的解析を頑張ってバイナリのサイズを小さくして欲しい
- 小さくなればwasmにも使いやすい
- import文のソート順を文法で統一できると嬉しい
Goのエンジニアですごいと思う人とその理由
- mattnさん
- Windows対応のツッコミが鋭い
- sqlcの作者
- 思いつきとそれを実現していることすごい
- Goと別の深さを組み合わせたものができる人
- BigQueryのエミュレータを実現するのにC++と組み合わせる
サードパーティのGoのフレームワーク
- よくつかう
- echo, gin, chi, go swaggerなど
- go自体はnet/http上の小さいフレームワークであること
- grpcなど必要に応じて組み合わせて
- 内製のsqlライブラリで使ったり
- テンプレート文
プロパティベーステストの利用シーン
- 概念は関数型からの取り込みなのでは
- 単独で動くライブラリの品質を上げる
- Goは失敗のデバッグもしやすい
- シンプルな失敗ケースを見つけてくれる
レイヤーの層分けしたとき、ドメインそうのEntity構造体をフィールドをプライベートにする実装ってGo的にどうなのか
- フューチャー的にはデータベース構造にこだわっている
- あんまり細かくレイヤー分けしない
- 思想によりけり
上司に説得する方法という見出し、採用が難しいケースがあるのか?
- 導入が難しいケース
- エネルギー系
- 既存がPythonでできてて言語を追加するときは難しい
- 適材適所
- バイナリビルド
- DeNAでかってにバッチ処理につかったら怒られた
- エネルギー系
- 半分ジョーク、Goの紹介の章
Goのおすすめの勉強法
- 自分が使うツールを作ってみる
- レベルによりけり
- Tour of Goをおすすめ
- プロジェクトのなかで書いてフィードバックもらう
- 転職で給料を上げやすい
Excelのテストデータ
- リポジトリに入れている
ファジングの使い所
- セキュリティの勘所の不具合
Javaとの親和性, Javaの人がつまづきやすいところ
- あんまり躓かない
- 覚えることが少ない
- ポインタがあるくらい
- Javaにも軽量スレッドが入れば
- Kotlinの内容が取り込まれる
- 毎回nilチェックすることなど、文化になれる
リリースの注意点・トピック
- Go-releaserというのがある
- メジャーバージョンアップ
- バージョン2系にするときめんどくさい
- 依存ライブラリの追従
感想
- 本の執筆を売り込むコネがあること自体がすごいし、共著者を増やすことで業界をよくしようとする考えはすごいなと思った
- 質疑の時間長めで有益な質問も多かったのがよかった
- ジェネリクスやファジングも使えるようになりたい
- もう少し、執筆に関する話を聞いてみたかった
- 執筆のリタイアの対応とか
- 技術書の場合、出版社側の編集とかどうなるのか