Goオールスターズ2参加レポート #eventdots

丹内です。少し前からGolangを勉強しつつブログ記事を書いていました。
夏のAWS関係の仕事が落ち着いたらGolangを改めて勉強しようと思っていた矢先、タイトルのイベントが開催されていたので、参加しました。

イベントサイト
Twitterまとめ

いまさら聞けないselectのあれこれ

• buildersconというイベントを準備中
• 10/22発売のWeb+DB Press
• (バッファ付き)チャネルはブロックが発生しうる
• selectにチャネル操作以外を入れるとエラーとして教えてくれる
• nil channelは読み書きでブロックするので、selectは成功することがない
  • 有効だったchannelを無効にしたり、ある時点から有効にしたりできる
• timerとfor selectのパターンはタイムアウトに応用可能
• doneチャネル: 処理が終わったらループを脱出
  • 1.7からはcontext
  • selectと合わせて処理を止めるコードで使うことが多い
• 質問: context.Doneはコスト無い？
  • ない。気にしなくて良い
• いろんなgoroutineが走っているコードを書くなら必須
  • selectを使うようなら中級者

Essentials of Golang

• Go Proverbs: Goのことわざ
  • 知っておくべきGoのプリミティブなところ
  • メモリ共有ではなくメッセージパッシング
  • 大きなインタフェースは非推奨など
• Constants
  • コンパイル時に処理される
  • 関数は呼べない。ビット演算か算術演算
  • iota: 定数を簡単に書く。列挙
  • 型を定義しておく
  • (10 * iota +1)とか書いて間違いやすいのでiota最初は捨てる
  • 例えばtime.Hourは定数だからconstにする、とか
• テスト
  • table-driven tests
    • goドキュメントにある
    • forで回すようなテスト
  • パラレルテスト
    • 1,2,3,4=10秒そのままだと待つ4つのテストを、t.Parallel()で並列に回せる
    • Runの前にキャプチャしないと意図しない値になる
  • race condition
    • ビルド時以前にテストで発見できる
    • go1.7から
  • go1.7からsubtestsでテストの時間を節約
• 正規表現
  • 遅い
  • goroutine safeに作られている
  • 初期化時のコストが高い
    • MustCompileを使いまわす
  • 遅いかどうかは、データと正規表現の中身による
  • Regexp.Copy()
    • キャッシュするときのMutexで遅くなってる
    • それを回避するCopy
• まとめ
  • ことわざに乗っ取るとGoらしいコードを書ける
  • go1.7の機能でテストを実行時に近いものにする
  • この発表の内容はgo1.7のリリースノートに書いてる
    • 1hくらいで読み終わるのでオススメ

とあるBtoB企業がGoを使ってみた話

※スライドの公開が確認され次第追記します

• 仕事で使ってないGoのライトな導入事例と思い出話
• カスタマーバーコード：郵便局が料金を割り引いてくれる
  • この画像生成や環境構築からGo
  • 起動回数が多く、JVMの起動コスト
• boombuler/barcodeを参考に
  • fmtによってコードが読みやすい
• 企業ブランディングの一環でGoの記事を書くことに
  • CodeZinの読者はWinが多いということでwinで書いた
  • 記事1本書いた後に執筆を持ちかけられる
• 社内ツールでの活用
  • databaseパッケージでRDBを操作するコマンド
  • 今後はPDFの大量作成を効率よく
• Goというジャンルを発信したことと、編集者の手がかからない記事を上げたことが執筆依頼に繋がったと思う

実践GoGoGo

• GoでDDD
• DDDのJavaやGoのサンプル実装を読みながら試行錯誤
• main.goではrepositorをnewしてるくらい
• handlerはシンプル
• DDDを実践すると起こりがちな、domainとrepositoryの設計が似てパッケージ名が重複するとかの辛み

goroutine、channelの扱い方

スライドのページ

• channelの使い方の疑問点は多い
• リソースリークとブロックの話

※昨日のServerlessconf Tokyoで元気を使い果たしてしまい、後半になるほどメモが雑になっています。申し訳ございません。

パネルディスカッション

• Goである理由、社内でGoを導入する方法
  • Railsで作られててパフォーマンスが問題になったところにGoの選択肢
  • 書いてて"しっくり来た"のがGo
  • 「Goが書けるから入社する」
  • Webアプリは導入しにくいので、APIサーバをこっそり入れた
  • LL使ってて「これからはGo」となるパターンが多そう
  • シングルバイナリだと運用担当者も楽という実績を積んで前向きな人を増やしていく啓蒙活動
  • PHPのコードがやばくてCTOが書き直しを決めた
  • =>エイヤで使えるところから入れて、反応を見て現場で入れた
• 導入するコツ
  • 既存を保守するガーディアンと新規のGoチームに分ける
  • 一部だけでもGoで書く
  • 政治をやった上で筋肉が必要
  • 実際に動かしてみないとわからないこともある
  • Goで動かしてRailsにプロキシ、落ち着いたらRailsを書き直す
• 一部をGo以外の言語を使っている人もいる
  • プロセス間通信が欲しいときもあるが、無いのでキューで繋いでる
    • 無い方がGoらしいが、ある方が便利
  • 既存の置き換えは無理しすぎないほうが良い。パフォーマンスとか使うべきところに使う
  • 機械学習やレコメンデーションはGo以外
  • まきさん：Cライブラリや有り物以外はGoで完結できる
  • 認証APIがRailsで残っている。Goへの移行が大変
  • 文字列の扱い。半角カナとかが大変
  • =>Goが苦手なものは特異な言語に任せる
• テスト、CI、運用周りの難しかったこと
  • オンプレの場合はGKEみたいな情報取れない
  • パッケージ管理。サードパーティのパッケージ管理インタフェースが変わるとCI落ちる辛み
  • パッケージ管理起因でローカルだとコケないのにCIだとコケるのもたまにある
  • graceful restartの仕方
  • 昔はライブラリが少なかったから自前で作って公開して保守する手間
  • goのdaemonize
  • goroutineのリソース共有に特有の癖。リソース漏れ
  • mockが辛い
  • 初期はGo習熟している人がおらず、subpackageに細分化しすぎて依存が多くなりビルド時間がかかる辛み
  • =>動いちゃえば楽だけどそれまでの設計とかテクニックが必要
• パッケージ管理
  • glide。vendoringしてない。godepth使ってたけどコミットしなきゃだめになって捨てた
  • vendoring入れると検索大変だしclone遅い
  • インタフェースが安定しているパッケージを使うことで、管理しない
  • パッケージ管理の仕組みを使うとライブラリのパッケージ管理が辛い問題
    • インタフェースが変わるときはパッケージ名を変えるとかすれば良い
    • パスにv1って入るとか
  • google社内では、サードは独自にホストしてる。上げるときはテスト専門の人が検証と通知して、開発者が対応
  • =>glideが多いが、使わない人もいる
• WebAppでGoってどうなのか
  • やってみたけど、テンプレートのフィルタ関数が弱くて辛いのでAngular化する予定
  • WebAppでは使ってない。フロントはReact。速攻で使いにくさを感じた
  • WebAppはPythonで作るとかが多い
  • できなくはないけど、そこにコストをかけたくない
  • 書こうと思えばLLでも書けるのでは?
    • データを扱うメソッドが追いにくいのは嫌なのでGo
  • Goで作っても嬉しいことない
    • template/htmlがあるから作んなきゃってなるので良くない
  • perlのテンプレートエンジンをGoに移植したけどメンテ辛い
  • だめだと気づいたけど時間なかったから仕方なくGoWeb。でも次はやらない
• 大規模開発におけるJavaとGoの比較
  • 比較してどうなるの？
  • 確かにJVMは早いが、同じくらいに宣伝されているベンチもある
  • パネラーにJava書いたことがある人が居なかったのでこの話題は終わり
• 今後Goに入って欲しい機能は？
  • ソート
  • 配列操作
  • type hintingとGenerics
  • Swiftの構文の一部は書いてて気持ちいいので入れて欲しい
    • でもあったらあったでGoらしくない
  • 言語としてシンプルで、欲しい機能も自分で作ればいいので思いつかない
  • Generics。でも入ってもGoが良くなるかは微妙。Goらしい形で入って欲しい
  • reflect使ったジェネレータで満足なのでGenerics無くても良い
• オススメパッケージ
  • 全体的に標準パッケージ。本体やテスト書くとき参考になる。
  • error2、testifyは必ず入る
  • context。でも標準になった
  • aws-sdk-go。アーキテクチャを学べる。generate code学べる
  • go-github。データ変換のrepositoryが参考になる
  • gcp-goも良い
  • grpc。エラーハンドリングの方法の参考
  • lexer。テキストテンプレート。Goっぽい
  • 標準の正規表現。遅いんだけどvirtual machine型の実装が面白い
• コミュニティとの関わり方
  • Tips共有されていってほしい
  • (お酒を飲みながら)発表したい
  • 共有できる情報を発信していきたい
  • 日本でGoを流行らせたい

まとめ

発表はもちろん、パネルディスカッションの中身が濃くておもしろかったです。 懇親会のじゃんけんでGopherくん人形がもらえたので、会社のデスクに置いてGolang勢力の拡大をアピールしていこうと思います。

ありがとうございました #eventdots pic.twitter.com/B6sSSOWcGA

— tannai (@yuukigoodman) 2016年10月2日