#golangtokyoGoinabaです。#4に補欠からの当日滑り込み繰り上がりという運の良さで参加してきました。会場はペアーズの株式会社エウレカさん。倍率が2倍ということもあり、狭き門という印象のgolang.tokyoですが、今回から動画撮影も始まったようです。次回のgolang.tokyoの前あたりに公開されるそうです。自分も#2,#3と2回補欠だったのでこれは助かりますね!!ご紹介ありがとうございます!後日https://t.co/Z00WxR8ZGcにて配信させていただきます。2017年3月1日また、@tenntennさんからブログ枠の紹介がありました。先着順なので参加確定まとめることで頭の中の整理になるconnpassの資料のページに掲示されるので多くの人にブログを見てもらえるのが主なメリットだそうです。ブログ枠って人気ないのか。確定で参加できるし、まとめることによって勉強になって、しかもconnpassに貼られるので閲覧数伸びて美味しいのに。今回はConcurrency(コンカレンシー、並行性)がテーマでした。今回はブログ枠で参加ではないですが、ブログ枠で参加するときのためにまとめてみます。フラー株式会社WebクローラーのためのGo言語の話です。アプリのデータをストアからクローラーで24時間毎に取ってくる。単一のサイト(シングルドメイン)なので間隔が短いとBANされる可能性がある。10万以上のアプリのデータをクロールする。画像のダウンロードがあるので1回のクロール時間が異なってくる。コマンダーとクローラーから構成されるクロールプログラム。EC2インスタンスを立ち上げる。現状は29インスタンスくらい立ち上げる。SQSからアプリリストを拾ってストアをクロールしてデータをDBに、画像をS3に入れる。1回のクロール時間が異なるので、例えば100回クロールする2個のクローラーがあっても直列で実行すると処理終了時間がまちまちになる。Goroutineを使って時間をずらして並行に実行していくと実行時間が同じになる。SlackBotとしても動いている。クローラのステータスを通知させる目的。普通のSlackBotは1回コマンドを打つと1回返答が返ってくる。これだと何回もコマンドを打たないとならなくて面倒。クローラーに実装されているSlackBotはSlackの編集機能を使う。コマンドを受けた最初の投稿は普通に。次の投稿から編集機能を使用し、最初の投稿を編集する。普通の投稿か編集かの判断をしてPostをするGoroutineと投稿する文字列を生成するGoroutineが分けてあり、chanで通信している。並行処理時のTCPコネクションの枯渇問題DBからデータを吸い出すのも並行で行っている。何らかの理由でqueryが遅く、並行処理が重なってしまいTCPコネクションを使い果たしてエラーが出ることがある。100))を使用して一度に処理する回数を制限する。制限中にGoroutineが1つ終了するとブロックされていたchanのブロックが解除され、次のGoroutineが動作する仕組み。blogGoroutineはOSスレッドに対して多対多。1対1、多対1に比べて全てのコアを使えてコンテキストスイッチも高速でいいとこ取り。スケジューラーへの追加が煩雑になる。)にGoroutineが使えるようになっている。用語(runtimeパッケージ以下を読む時に覚えておくと役に立つ。4コアなら4Pは自分にスケジューリングされたGが無くなると、別のPからGを半分奪う。これにより、全てのスレッドが最大パフォーマンスで動作できる。runtime.GOMAXPROCS()が1でもGoは複数のスレッドで実行される。ハマりどころループしてGoroutine外の変数を参照する場合。runtime.GOMAXPROCS()が大きいほど切り替わりやすくなる。f()の仕組みがとてもわかりやすく理解できました。株式会社カヤックGAE/GoをAWSで動かすためのフレームワークの話です。下記を使用APEX通常、LambdaでGoを実行することはできないが、APEXを経由させることにより実行できる。Response)の相互変換Lambdaで動かさない時は通常と同じくサーバとして立ち上げられる。Lambda→APEX→Go(Ridge→Handler)メリット独自オブジェクトではなく、いつも使っているRequest/Responseが使えるRequest/Responseで書くからテストにhttptestが使える。ルーティングもGo内で行える。ローカルで動かせるからlocalhostを叩いて結果を受けるとかができる。EC2でも普通に動かせる。Lambdaのメリットが享受できる。高負荷時自動スケールEC2の管理無し!デプロイもコマンド一発。GAE/Go!できないこと同一名クエリ(foo=a&foo=b)や同一名ヘッダが受け取れない。バイナリ(画像等)が返せない。Gatewayが遅い。頻繁にアクセスが無い。レイテンシ要求がシビアでない。Logsに送られるが、それをLambdaに送ってRidgeでパースしている。github.com既存のWebアプリもちょこっといじってmux.HandleFuncを使うようにするだけでハンドラの中身を変えなくてもRidgeを使い始められるのがすごいですね!制限はありますが、ChatBotくらいから試しに使ってみるのはいいかもしれません。途中、ピザとビールが出る懇親会がありました。https://gist.github.com/kaneshin/a398720b8e20722a83bc6903e4017435発表予定だった牧さんが残念ながら都合がつかず来られなくなってしまったため、急遽かねしんさんがライブコーディングをすることに。懇親会しながらも、みんなの目線はスクリーンに釘付けでした。tenntennさんのツッコミも入りつつ、かなり盛り上がっていました。freee株式会社LINEBotを作る理由は日本で1番使われているチャットツールだから。非エンジニア(嫁、家族)にも理解してもらいやすい。必要な物サーバ(Goインストール)ドメインSSL証明書ようはhttpsで外部からアクセスできるGoが使えるサーバがあればよい。これがLINEからの通知を受け取るためのサーバになる。天気のWebAPI(LINEさん提供)があるので使う。公式にオウム返しのサンプルがあるのでそれに手を加える。GitHub作ったら家族のグループラインに招待する。嫁だけでなく、非エンジニアの友人駆動開発にも使えますね。「嫁はどうやって作るんですかとかでもいいですよ。JetBrainsJetBrains製のIDEの紹介です。英語だったので必死に聞きましたが半分はツイッターの#golangtokyoを追っていました。何件か気になるツイートを紹介します。2017自分は、こういうのどうやって作るんだろうっていうのを考えながら見ていました。2017まとめブログを書くのは結構大変だけど、頭の中が整理できるのでおすすめです。長めに書いてしまったのは反省点で、今後はもうちょっとまとめられるようにしていきたいと思います。やるコマンドSearchArchiveGroupsプログラミングはてなブログをはじめよう!i178inabaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。