golang.tokyo #8 勉強会
概要
- プログラミング言語のGoの導入企業のメンバーが集まり、
Goの普及を推進するコミュニティです。
開催日
2017/8/28(月) 19:30〜
開催場所
ハッシュタグ
#golangtokyo
登壇者
星一 / hajimehoshi
登壇資料
Ebiten - 概要
- 極めてシンプルな２Dゲームライブラリ
- 描画・入力関数が計約５０個
- マルチプラットフォーム
- Apcahe License 2.0
Ebiten - 機能
Ebiten -メインループ
- Runに毎フレーム実行する関数を指定する
- 引数として画面を表す*ebiten.Imageが渡ってくる
- 画像、画面、オフスクリーンなどが全てが*ebiten.Image
Ebiten - 描画
- アフィン変換行列
- 平行移動、拡大縮小、回転の組み合わせを１個の行列だけで表す
実例 - 償いの時計
- ファミ通に載った
- goで開発したの初めて…
15000 DL(2017年8月)
RPGエンジンをGopherJSでJavascriptに変換
- ブラウザ上でゲームのテスト
実装 - 描画
実装 - 音のデコーダ
実装（デスクトップ） - GLFW
- OpenGL / GLFW
実装 GopherJS(ブラウザ)
- GopherJS
- GoをJavascriptに変換するソフトウェア
- goroutineも動作する
実装 - パフォーマンス
- プロファイルを取る
- 他のプラットフォームに比べると一番やりやすい
- コピーを避ける
- ロック、チャネル、goroutineを避ける
- 下手に呼ぶとsetTiemoutが呼ばれる
- deferを避ける
- deferなしより２５倍遅い。実も元々遅い
- リフレクションを避ける(encoding/jsonなど)を避ける
- JSONからMessagePackに変更中
実装 - GopherJSの状況
- GopherJSはまだまだ不安定
実装（モバイル）
- gomobile bindを使用した
- 実装に難航した
- gomobileが悪い？
- Goそのものが悪い？
- GPUが悪い？
- コンテキストロスト問題
- パフォーマンスチューニング
登壇者
zchee
登壇資料
https://www.slideshare.net/KoichiShiraishi/go-by-zchee
個人で作っているGoパッケージ
- Docker for Mac
- とりあえずいいみたい
Neovim用のGoプラグインをpure Goで書いたもの
- MessagePack RPC話せればどの言語でもプラグイン書ける。Goも例外ではない
まとめ
- 個人プロジェクトはやったもの勝ち
- まずは自分が不満を持ったものをやってみる
- Goの速度を信じて、既存のものをもっと速くしたい
LT枠1
- ChatOps
- ナイスなリリースフロー
ChatOpsを導入すること
- Pros
- 手作業・属人性の排除
- リリースの状況が追いやすい
- サービスに愛着が枠
- Cons
- 権限管理が煩雑になりがち
ChatOpsの環境にGAEに使うこと
気をつけたいこと
- GAEとりあえずTaskQueuに積む
- Slackの３秒ルール
LT枠2
GDBについて
デバックツールを使っていますか？
- println(‘’)
- 大量のlogの中から探し出さないといけない
- 毎回 buildしなければいけない
- デバックコードをcommitしてしまうことがある
-
- GgggoがGDBをサポートしている
- インストールめんどくさい
- Qiitaとか見てインストールしてね
How to debug
- デバックする際には最適化を外す
- list command
- break command
- run command
- continue command
- delete command
- backtrace
- info command
- global変数
- info variables
- info breakpoints
- info goroutines
- *がついているものが現在実行中のもの
- print command
- アドレスを表示したり
- whatis
- 変数の型のを表示
- disas
- 逆アセンンブル
- watch
- set variable
まとめ
- tab補完が聞くのが気持ち良い
- HTTP Serverのデバックどうするの？
- deleveが良さそうかもです…
LT枠3
システム構築にgPRCを使った話
gRPC
- Google製のRPC
RESTのエンドポイント辛い問題
- コード生成で開発の効率化
Streaming RPC
ほとんどのクライアントがRESTを要求
GOOD
- Streaming RPCが想定通りに使えた
- 生成されるコードが自分好み
- BAD
まとめ
- gRPCは良い。
