罢补濒办苍辞迟别と驳辞濒补苍驳と私
- 2. Talknote
- 4. 罢补濒办苍辞迟别の课题
- 6. PHP
- 11. 対策 ? 性能の問題 ? I/Oを中心に対策 ? DB周りのチューニング ? キャッシュの効率化 ↓ PHP自体がボトルネックに
- 12. 対策 ? 言語仕様の問題 ? テストの充実 ? リファクタリング ↓ 指数関数的に増す複雑さを カバーしきれない
- 14. Golang
- 15. 特徴 ? Googleが開発 ? シンプルな言語仕様 ? 事前コンパイル方式 ? 並列処理のサポート ? オブジェクト指向っぽくない ? クラスではなく構造体 ? 継承ではなく委譲
- 16. メリット ? 習得が容易 ? 高速 ? コードフォーマットの統一 ? 並列処理 ? コンパイル時の厳格なエラーチェック
- 18. 華やかさはなく いわば質実剛健
- 19. Talknoteの採用理由 ? プログラミングのガバナンス ? 堅牢なプログラミング ? 性能 ? デプロイの容易さ ? 並列処理
- 22. デプロイの容易さ ? ランタイムいらず ? ＝デプロイ先のセットアップがいらない ? 極端な話、ビルドしてコピーでデプロイ完了 ? go build -o app app.go scp app server:/usr/local/bin
- 26. Channel
- 27. goroutine ? タスク間の通信方式 ? メッセージパッシング ? Erlangが同方式を採用 ? 下記に影響を受けている言われている ? CSP ? pi-calculus
- 28. CSP ? Communicating Sequential Processes ? プロセス計算の一つ ? プロセス計算＝並行システムモデリング技法 ? 仕様記述言語 ? Golang以外に影響を与えた技術 ? Unixのパイプ
- 29. CPUを有効活用 ? 最近のCPUはクロック数が頭打ちでコアを増やす方向へ ? スクリプト言語の多くはマルチコアを活かしづらい ? GIL/GVLによってネイティブスレッドを複数同時実行で きない ↓ シングルスレッドアプリケーションでは CPUを有効活用できない
- 32. Talknoteの例 OAuth Client & OAuth Server & Web API
- 33. メール投稿サブシステム ? 2014/11リリース ? Go 1.4 ? フレームワーク ? Revel (Web API) ? ORM ? gorp ? OAuth ? osin
- 34. Revel ? フルスタック ? 基本Railsライク ? scaffoldingも当然あり ? しかしORMはなし ? ホットデプロイ ? 性能もそんなに悪くない ? https://github.com/revel/revel
- 35. Revel
- 36. gorp ? シンプルなORM「的」ライブラリ ? 基本はSQL叩いて結果を対応する構 造体にぶち込む ? なのでRevelと組み合わせた場合、基 本modelのコードがSQLを含む ? https://github.com/go-gorp/gorp
- 37. gorp
- 38. gorp
- 39. osin ? OAuth2のライブラリ ? OAuthクライアントだけじゃなくOAuthサー バもつくらなきゃなかったので採用 ? 割とちゃんと動いている ? https://github.com/RangelReale/osin
- 40. 认証サブシステム ? 2016/03リリース ? Go 1.6 ? パッケージマネージャ ? glide ? フレームワーク ? grpc-gateway
- 41. 认証サブシステム
- 42. glide ? パッケージマネージャ ? Go 1.5以上で公式採用されたvendoring機能 を利用 ? https://github.com/Masterminds/glide
- 43. glide
- 44. grpc-gateway ? gRPC (HTTP/2 + Protocol Buffers) をラップし て JSON API (HTTP/1.1 + JSON) を提供するリ バースプロキシを生成する ? https://github.com/gengo/grpc-gateway
- 47. ご清聴ありがとうございました
Editor's Notes
- #4: 社内SNS 社内コミュニケーションの最適化 メールを置き換える リテラシーが低いユーザでも迷わず使えるように Web, iOS, Android
- #8: 遅い アプリケーションが肥大化 キャッシュを階層化してIOのボトルネックを減らしたとしても遅い
- #9: 並行処理 fork()したりpthreadなどで対処できるが、プログラミングの難易度があがるしユーザランド fork()やstream_set_blocking()やReactPHPでNon-blocking I/Oという手もあるといえばある
- #10: バギー 型がないことの功罪、数値型と文字列型、empty() / isset() / is_xxx(), … 継承の濫用 DRYの罠 ユニットテストでもカバーしきれないこともある
- #11: コードを切り离しづらい
- #12: SQL, インデックス, 発行回数, nested loopであることを前提に キャッシュはDBだけじゃなくファイルアクセスも
- #13: コードベースでかいしゆるふわだから バグ要因の掛け算 整数なのか浮動小数点なのか文字列なのか実はbooleanなのか 静的型付けじゃないだけで一つの変数に対してこれだけの要素 組み合わせ爆発 ある意味PHPは玄人むけの言語（悪い意味で）
- #16: シンプルな言語仕様 手続き型 事前コンパイル方式 静的型付け クロスコンパイルもできる
- #17: 習得が容易 言語仕様がシンプル 高速 スタックとヒープ コールスタックやローカル変数、引数は原則スタック しかし関数内でnewしてポインタ返す場合はヒープ ヒープはGC対象 sliceに要素を追加しまくると最初はスタックにおかれていても途中からヒープにおかれる コンパイル時の厳格なエラーチェック importしたのに使用しないパッケージがあったり、使用しない変数があるだけでもエラー GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo.
- #18: イマドキっぽくない genericsがない propagationしないエラー処理 mutableな変数
- #20: プログラミングのガバナンス コーディングスタイルの強制 習得容易性 堅牢なプログラミング コンパイル時エラーの厳格さ 性能 ネイティブコード デプロイの容易さ バイナリ一個 並列処理 goroutine
- #21: プログラミングのガバナンス コーディングスタイルの強制 習得容易性
- #22: プログラミングのガバナンス コーディングスタイルの強制 習得容易性
- #23: デプロイの容易さ バイナリ一個
- #24: 並列処理 goroutine
- #26: 並列処理 goroutine m:nスレッド方式（アプリケーションレベル） m個のネイティブスレッドとn個のgoroutine 並行計算 モデル Process calculus(プロセス計算) CSP(Communicating Sequential Processes) 仕様記述言語 ガード付きコマンド Unixパイプ channel π-calculus タスク間の通信方式 メッセージパッシング 類） ex) Erlang 対）共有メモリ方式 ex) Java
- #27: タスク間の通信方式 メッセージパッシング 対）共有メモリ方式 ex) Java 同期メカニズムはchannelだけじゃなくてmutexなんかで待ち合わせるのもアリ グローバル変数触るんなら
- #28: コルーチンじゃないよ ? コルーチン ? 一旦処理を中断したあと、続きから処理を再開できる ? ノンプリエンプティブな感じ ? 並列というより並行プログラミング ? ジェネレータ（例えばphpのyield）に似ている ? プリエンプション ? 実行中タスクを一時的に中断させ、他のタスクを実行後に中断させたタスクを再開すること ? 通常カーネルの機能や割り込み処理はプリンプション不可能 ? プリエンプティブ?マルチタスク ? 実行中タスクにおいて一定時間内（タイムスライス）にOSへ制御が移り、次のタイムスライスのタスクを実行する ? OSがCPUの割り当てを管理する ? こっちが主流 ? ノンプリエンプティブ?マルチタスク ? アプリケーションがCPUの割り当てを管理する（空き時間にCPUを開放する） CPUはクロック数増加が頭打ちになり、マルチコア化 最大限に活かす方法は並列処理 GOMAXPROCS goのスケジューラはまだいけてない 1.5でスケジューラがだいぶ改善された模様 デフォルト値が1から論理CPU数になった OSスレッドのコンテキストスイッチはコストでかい なんでもかんでも並列処理じゃなくて並行処理 CSPやpi-calculusはプロセス計算
- #29: プロセス計算は、独立エージェントやプロセスの集まりにおける相互作用/通信/同期を抽象的に記述するツールである。 また、プロセス記述を操作?分析可能にする代数学的規則も提供し、プロセス間の等価性について（双模倣性を使った）形式的推論を可能とする。 CSPは独立したプロセス群がメッセージパッシングによって通信することで相互にやり取りしているものとしてシステムを記述する。
- #30: マリチコア初期はクロック数おさえていた 最近はそうでもないがまた頭打ち？ Sandy Bridge(#2) Ivy Bridge(#3) 性能強化、消費電力?発熱の軽減、グラフィック強化 Haswell(#4) 消費電力?発熱の軽減、グラフィック強化 Broadwell 消費電力?発熱の軽減、グラフィック強化 Skylake 若干性能強化、DDR4対応 ? CPU ? クロック ? クロック数の整数倍の時間で命令を実行 ? 4ステージ構成の命令パイプラインでは1個の命令を処理するのに4クロック必要 ? クロック数が多いほど単位時間あたりの命令実行数が多いことになる ? IPC = Instructions ?Per Clock cycle / 1クロックあたり実行可能命令数 ? Pentium4はクロック数至上主義でIPC軽視 ? スーパーパイプライン ? クロック数の向上に用いられる ? ステージ数を増加させ、パイプラインでの同時実行数を増加させる ? スーパースカラ ? IPCの向上に用いられる ? パイプラインの同時実行数を増加させる ? intelのハイパースレッディング（SMT = Simultaneous Multithreading / 同時マルチスレッディング）はこれ ? スーパーパイプラインとスーパースケーラはトレードオフの関係で、通常組み合わせる
- #31: GIL/GVL スレッドセーフじゃないところがあったり ? CPU ? クロック ? クロック数の整数倍の時間で命令を実行 ? 4ステージ構成の命令パイプラインでは1個の命令を処理するのに4クロック必要 ? クロック数が多いほど単位時間あたりの命令実行数が多いことになる ? IPC = Instructions ?Per Clock cycle / 1クロックあたり実行可能命令数 ? Pentium4はクロック数至上主義でIPC軽視 ? スーパーパイプライン ? クロック数の向上に用いられる ? ステージ数を増加させ、パイプラインでの同時実行数を増加させる ? スーパースカラ ? IPCの向上に用いられる ? パイプラインの同時実行数を増加させる ? intelのハイパースレッディング（SMT = Simultaneous Multithreading / 同時マルチスレッディング）はこれ ? スーパーパイプラインとスーパースケーラはトレードオフの関係で、通常組み合わせる
- #32: ついでにハマりポイント jsonのマーシャリング json->structでフィールドが小文字でprivateなゆえに値が設定されず数時間
- #35: Revel provides routing, parameter parsing, validation, session/flash, templating, caching, job running, a testing framework, and even internationalization.
- #37: そういや、前回の質疑応答で sql.NullInt64 と *int64 のどちらを使っていますか？みたいなのがあったと思うけど、 *int64 だとGC rootから辿るポインタが増えるからGCのプレッシャーが大きくなって嫌なので sql.NullInt64 を使って構造体にboolとint64を埋め込む方がそうならなくて良いって知見をGoConで聞いた。
- #46: クライアントサイドのエンジニアがWeb APIまで書く サーバサイドのエンジニアはマイクロサービス、すなわちビジネスロジックに集中 細かいマイクロサービス（コンテナ）を並べてスケーラブルに コードベースを小さくすることで捨てやすくする