golang.tokyo #5 感想
4月27日に開催されたGolang.tokyo#5に行ってきた。 GCPUG Tokyoとの共同開催ということで30分枠はGAEでGo言語を使ったお話。
直前に人数を見たら珍しく定員割れをしてましたそれでも100人超えてるあたりGoの注目度の高さが伺える。
GO *GAE
株式会社カブクさんの方の発表(資料未公開)。 GAEの基本的な部分の説明と、実際に業務で使ったときのお話。 Go言語は業務で使っていますが、GCPは触れたことがない勢なので基本的なところを説明していただいてとてもありがたかった。
以下、気になったところ箇条書きで書く。
- GAEにはStandardとFlexibleの2種類ある
- Standard Environment(SE)
- PaaS
- スピンアップが速い
- Goは1.6
- Flexble Environment(FE)
- Dockerのコンテナを立ち上げる
- バイナリを扱える
- Standard Environment(SE)
- 基本はSEを使う
- バイナリを扱いたいならFEしかない
- カブク内で使っているところは3D解析のAPI
- SEとFEを両方合わせて使用している
- SEだけだと他の3D解析APIのリクエストに60秒以上かかるためタイムアウトする
- FEだとTaskQueueが使えない
社内でもGCPを使う話はちょこちょこ聞くけど60秒制限はよく引っかかりそうなのでちゃんと覚えておく。 あと、辛かったことで言っていた事と全く同じことを自分もGoを最初に触った時に思っていたのでわかりがあった。
GAE/GOの勘どころ
株式会社ソウゾウの@osamingoさんの発表。
以下、気になったところ箇条書きで書く。
- CloudSQLの最大同時接続数が12(Master,Slave合計で)
- Vendoringは出来るらしい(質疑応答より)
- gb
- direnv
- Deployもよしなに
- Monitoringも楽
- GCPは運用が楽
- GCPは運用が楽(重要)
GCPでの細かいハマりどころとかツール等々。 AWSの運用めんどくさくない?と最近気づき始めたのでGCPの運用が楽という話を聞いて触りたくなった。
Datastore/Go のデータ設計と struct の振る舞いについて
ここからLT枠。 @pospomeさんのDatastoreでの設計のお話。
設計の話は特に好きなのでfmfmと思いながら聞いていたが、@vvakameさんの
Datastoreを使う上でネストしたstructは自動生成系ツールとの相性が悪い可能性があるのでバッドプラクティスだよ論者です #golangtokyo
— わかめ@TypeScript味 (@vvakame) 2017年4月27日
というツイートを見てなるほど自動生成系ツールもあるのかという知見を得た。
となると@__timakin__さんもツイートしていたように、サービスロジックで扱う構造体とDatastoreで扱う構造体を分離するのが、 ベターかなぁという感じがした。
DataStoreは保存するときにそれ用のEntity定義してるから、完全にそのpackage以外のstructからは区別して使ってる #golangtokyo
— timakin (@__timakin__) 2017年4月27日
Contextアンチパターン
神(Context)を殺した話。
面白かった(小並感)。
自分ではまだContext.Valueを使っていなかったが、使う時には気をつける。
あと、現在自分のチームではechoを使っているが、スライドの内容と同じように殆どRoutingにしか使ってないんだったら少し重い。 なので、最近は、個人でWebのものを書くときとかプロダクトから少し離れたツールを書くときは httprouterを使っている。
ASTライブコーディング
@tenntennさんのASTライブコーディング。
以下のコードから文字列のhoge変数だけを取り出すコードを10分で書いていた(すごい)。
package main import ( "fmt" ) func main() { var hoge = "hoge" fmt.Println(hoge) func() { var hoge = 0 fmt.Println(hoge) }() }
触ろう触ろうと思ってastは全然触っておらず、いい機会でもあったので自分でも書いてみた。
https://gist.github.com/nametake/1fd82014bdfc434a32aba6590c4c66bb
(@tenntennさんがやっていたやり方とは違う気がするけど取り出せてるからセーフ)
astを触ったことがなくてもast.Print
の内容を見ていれば何となくどうなっているのかわかって、思っていた以上に楽ちんに書けた。