golang.tokyo #25 参加レポ

golang.tokyo #25 に参加してきました
補欠だったんですが、ブログ枠が空いてたので急遽そっちで参加することに

でいい機会なのでブログをはじめてみることにしました

というわけで本題

今改めて読みなおしたい Go 基礎情報 その1

docs.google.com

概要

Go の郷に入るというテーマで "言語思想" と "Go Way な設計実装" が分かるような記事/書籍を紹介する話
それらの記事/書籍から Go の Simplicity がどのように実現されているかを学んでいく

感想など

私自身もなんとなくでしか Go らしさを理解していなかったので、紹介された記事を改めてよく読も
丁度、Go の研修用資料も書いてたので個人的にとてもタイムリーな発表でした

今改めて読みなおしたい Go 基礎情報 その2

概要

Go の郷に入る Part 2
こちらはより実装よりで、"言語仕様" と "内部処理" についての記事/書籍を紹介

質問

Q.util とか common とかはよくダメなネーミングだと言うが、標準パッケージにも ioutil とか httputil とかあるの、あれはよいのか??

A.ああいうのは io とか http とかコンテキストが制限されているからよさそう

Q.どもったような名前はダメだと言われるが、context.Context とかは許されるのはなんで??

A.context パッケージは Context 型しかないから仕方無いのでは

感想など

const では float64 + int みたいな計算が許されることとか知らないことが多かった
内部実装とかはパフォーマンスチューニングしたいときとかに役立つはずなので、少しづつ読み進めよ

golang binary hacks

golang binary hacks (golang.tokyo #25)

概要

Hugo Extended の docker image を Alpine Linux で作ったら Segmentation fault で動かなかったので、バイナリにパッチをあてて直した話
musl がスレッドに対して割り当てるスタックサイズが小さかったのが原因で、それは ELF のヘッダをいじることで変更できた github.com

感想など

debug/elf パッケージ知らなかった、めっちゃ便利そう
現行の alpine:edge image だとスレッドのスタックサイズが大きくなっているのでこの問題の発生頻度が低くなっているらしい

Consider a test of image processing in Go

概要

画像処理のテスト手法を色々なパッケージから調べてきて紹介していく話
計算コストを抑えるとテスト失敗時の詳細が失なわれるという傾向があるので、その辺りも考慮する必要がある また、テストデータを準備するのも難しく、goldenfile 方式で用意するのがよさそう

感想など

画像となると情報量が膨大になるのでやっぱりテストするのもテストデータを用意するのも大変そう
会の後、統計的な手法でテストしてるパッケージの例などがあったか聞いてみた
-> そういう手法でやってるパッケージ自体は無かったらしい

package名と変数名がかぶっているのをとにかく検出したい

概要

パッケージ名と変数名とかが被っているミスをよくやるので静的解析して検出できるようにした話 x/tools/analysis 便利 あとテスト作るのがとても簡単

github.com

感想など

静的解析、ネタはあって手が空いたらやりたかったので参考にしたい

github.com

も便利そうなので使ってみよ

おわり

こうやって纏めると資料を読み返すことになるのでやっぱりよいですね
今後もブログ枠空いてたら積極的に取っていこうと思います