<p>こんにちは。プレイドの@monoiです。<br>
プレイドでは主に管理画面周りの開発を担当しています。</p>
<p>さて、突然ですがプレイドには最近ある課題が浮上しています。<br>
それはメンバーが増えるに伴って、コミュニケーションの機会がなかなかない人ができてしまうこと。</p>
<p>この課題には多くの会社が頭を悩ませていると思いますが、コミュニケーションと言えば何と言っても<strong>ランチ</strong>ですよね。<br>
普段の業務であまり関わりのない人でも、一緒にランチに行けばそこには<strong>深い友情</strong>が芽生えるかもしれません。</p>
<p>そんなわけで今回は、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotを、AWS Lambdaを使って作成しました。</p>
<h1>目次</h1>
<ul>
<li>プレイドのbot紹介</li>
<li>AWS Lambdaとは？</li>
<li>作る</li>
<li>完成</li>
<li>最後に</li>
</ul>
<h1>プレイドのbot紹介</h1>
<p>botを作る方法は様々あります。</p>
<p>プレイドにはすでに多くのおもしろいbotがいるので、これらを紹介しつつ、処理方式を検討していきます。</p>
<h2>はる子さん</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bf5fcce8-3d22-467e-b818-f7ebe5f594da/hal.png" alt=""></p>
<p>はる子さんは優秀な人事・労務管理botです。<br>
勤務時間を管理してくれたり、社員のプロフィールを教えてくれたりします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/695cb0dc-1c30-41c7-979f-d558d15b6966/----------2016-12-14-16.09.02.png" alt=""></p>
<p>はる子さんは、社内に置いてあるMacBookAirにnode.jsサーバーを立てて動かしています。<br>
以前はiBeaconを使って社員がオフィスにいた時間を把握し、自動で勤務時間を記録してくれる仕組みもありました。（リモート勤務や外出が多い社員の勤務時間をうまく取得できないため、一時休止中。）</p>
<h2>KARTEくま</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/dd9c67da-d00d-41c8-ba1a-ba8a53b73e02/cap4.png" alt=""></p>
<p>KARTEくまはCX(Customer Experience)チームをサポートするためのbotです。プレイドが提供しているサービスで、異常な数値が検出されていないか等のチェックを行っています。</p>
<p>Google App Scriptで定期実行し、SlackのIncoming Webhookを叩いています。</p>
<h2>karte-hubot &amp; DeployBot</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6dfe76a1-b314-4ad3-8bd4-fba5e6ab7004/deploy_bot.png" alt=""></p>
<p>日々のデプロイを補助してくれるbotです。<br>
デプロイをするのにいちいちコマンドを叩くのは面倒だ、ということで、Slack上で特定のキーワードを打つとデプロイできるような仕掛けが作られました。</p>
<p>こちらはEC2インスタンス上で動作させています。<br>
karte-hubotは名前の通りgithub社の<a href="https://hubot.github.com/">hubot</a>フレームワークを使っています。</p>
<h2>さてどうするか。</h2>
<p><strong>完全に余計な手間ですが</strong>、まだ社内で使われていない方法で作ってみたい・・・！</p>
<p>というわけで今回は<strong>AWS Lambda</strong>で作ってみました。</p>
<h1>AWS Lambdaとは？</h1>
<p>FaaS（Function-as-a-Service）の一種で、AWS上に関数を置いておき、インスタンスを立ち上げることなくクラウド上でアプリケーションを実行できるサービスです。<br>
CloudWatch（定期実行）や、S3（データがアップロードされたら実行）など様々なAWSのサービスをトリガーにして実行させることができます。<br>
2016年12月現在、Node.js、Python、Java、 C#に対応しています。</p>
<p>実際に処理が行なわれている時間のみしか課金されないため、常時動かす必要のないアプリケーションとは相性がいいです。<br>
お昼の時間しか動かさない今回のbotにはうってつけですね。</p>
<h1>作る</h1>
<h2>作成するbot</h2>
<p>ランチメンバーを募集してグループ分けしてくれる<strong>ランチくまbot</strong>。</p>
<ul>
<li>12:00に「一緒にランチに行く人募集ー！」と誘いがくる。</li>
<li>13:00に上のメッセージに対してリアクションした人を適度な人数でグループ分けする。</li>
</ul>
<h2>slackでBot Userを作る</h2>
<p>まず https://slack.com/apps/build からBot Userを作成します。</p>
<p>作成が完了したら、登場させたいchannelにinviteしてあげましょう。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b37bc27-bb31-4c86-8027-28ca66844a22/----------2016-12-14-18.51.08.png" alt=""></p>
<h2>Lambdaのsetup</h2>
<p>続いて<a href="https://aws.amazon.com/jp/">AWSコンソール</a>からLambda Functionを作成します。</p>
<p>今回は定期実行なので、トリガーはCloudWatch Eventを使います。<br>
「平日12時」に実行の場合、CloudWatchのスケジュールは<code>cron(0 3 ? * MON-FRI *)</code>としてあげればOKです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9e584509-f549-4993-a992-083e09fd7ea7/----------2016-12-14-16.47.42.png" alt=""></p>
<p>「平日12時」のCloudWatch Eventでは<code>{&quot;event_name&quot;: &quot;send&quot;}</code>を投げるようにしています。<br>
「平日13時」のEventでは<code>{&quot;event_name&quot;: &quot;aggregate&quot;}</code>を投げます。<br>
event_nameによって処理内容をハンドルします。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f78cd9a1-3b7b-42a7-b198-ee7ff5133f1a/----------2016-12-14-16.53.12.png" alt=""></p>
<p>また、タイムアウトまでの時間がデフォルトでは3秒になっているのですが、slackのAPIを何度か叩くので念のため10秒にしておきます。</p>
<h2>コードを書く</h2>
<p>通常通りローカルでコードを書き、その後zip化してAWSのコンソール画面からアップロードします。<br>
ブラウザ上でもちょっとしたコードを書くことはできますが、モジュールのインストールなどはローカルで行う必要があります。</p>
<p>ボタンひとつでテスト実行することもでき、デバッグも容易です。<br>
もちろんただの関数なので、ローカルでも簡単にテストできます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f963c72b-8523-4763-aef1-004a7f388a37/----------2016-12-15-2.47.08.png" alt=""></p>
<p>Lambda Function内からのみアクセス可能な環境変数をコンソール画面から設定することができます。<br>
例えばCHANNEL名をここで設定できるようにすると、再アップロードせずに投稿先のチャンネルを切り替えられるようになり、テストが非常に楽になります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c4cfced0-5cbc-4561-b729-3488edd2994f/env.png" alt=""></p>
<p>その後は<a href="https://api.slack.com/">SlackAPI</a>を見ながらコードを書き進めていきます。<br>
SlackのAPIは非常に豊富でわかりやすいです。</p>
<h1>完成</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18ed12f5-d0df-4398-842c-bd5afb093da5/cap.png" alt=""></p>
<p>まずは自己紹介から入ります。<br>
先ほど紹介したKARTEくまbotの作成者である@akobaさんからも受け入れられたようです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/18f9c763-e4d4-4759-9807-54dfb60e1cc3/cap5.png" alt=""></p>
<p>12:00になるとlunchチャンネルにメッセージを投稿し、募集を開始します。<br>
よく分からないリアクションもいっぱい付いてますが、lunch_kumaは余裕で全て受け入れます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c03c1d8e-7a5e-4589-b478-7fe83421136d/cap3.png" alt=""></p>
<p>13:00になるとリアクションをしたメンバーをシャッフル、グループ分けします。<br>
いい感じにグループ分けできました！</p>
<h1>最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくはこちら（Wantedly）をご覧ください。 もしくはお気軽に、こちらの「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


社内のコミュニケーションを活性化させるため、ランチメンバーをシャッフルしてグループ分けしてくれるSlackbotをAWS Lambdaを使って作成しました！

SlackbotをAWS Lambdaでサクッと作ってみた | PLAID engineer blog

ランチメンバーを自動でグループ分けしてくれるSlackbotをAWS Lambdaでサクッと作ってみた

<html><head></head><body><p>プレイドの @nashibao です。</p>
<p>弊社では結構<code>BigQuery</code>を使い倒させていただいていて、社内向けのバッチ解析や<code>ChartIO</code>/<code>ModeAnalytics</code>等を介した社外向けのレポーティングとしての利用だけでなく、ABテストなどの集計系では（Query数のコントロールのためにキャッシュは介していますが）ほぼ直接アプリケーションのバックエンドとして利用しています。</p>
<p>またStreaming Insertが思ったより安定しているので、ニアリアルタイムにイベントを反映することができ、<strong>適当なQueryを投げ込んでPBの集計を気軽にやって、数百万使って唖然としてとりあえず寝て忘れる</strong>、みたいなことをしています。</p>
<p>先日も"GCP NEXT World Tour in Tokyo"において、弊社 @makinoy がジョブズばりのプレゼンをさせてもらいました。</p>
<p><a href="http://blog-plaid.com/event/2642/" target="_blank" rel="noreferrer"><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df784d2b-d07b-4eac-b2d1-afb1e918b464/DSC00529.jpg" alt="gcp"></a><br>
<a href="http://blog-plaid.com/event/2642/" target="_blank" rel="noreferrer">Google Cloud Platform 国内最大のイベント「GCP NEXT World Tour in Tokyo」にプレイドが登壇しました</a></p>
<p>さて、これだけBigQueryを使い込んでいる弊社ですが、仕組みについてはあまり外に出てないため、ほとんど知りません。</p>
<p><a href="http://research.google.com/pubs/pub36632.html" target="_blank" rel="noreferrer">DremelのPaper（2010/VLDB)</a> が6年前に出ていますが、その内容としては非常に単純なQuery Processingのケースのみを扱っていて、<code>シンプルな分割統治型のツリー処理</code> と、<code>独自の省スペースかつ効率的なNested Dataのカラムナ表現</code> の二点を中心に議論されています。論文の最後でも次のように締められています。</p>
<blockquote>
<p>In the future, we plan to cover in more depth such areas as<br>
formal algebraic specification, joins, extensibility mechanisms, etc.</p>
</blockquote>
<p>後半に乗っている<code>Dremel</code>と既存の<code>Google MapReduce/Sawzall</code>（Google 社内のMapReduce実装）とのパフォーマンス比較、キレイに線形にスケールする実験結果は一見の価値があります。ただ、カラムナについて独自のエンコーディング/FBMを使ったアセンブリ手法は、これがポッと作れてしまうGoogleはさすがだなぁ、と思う反面、カラムナにしたらそりゃパフォーマンスは上がるだろうという感じだし、割となんでもござれのHDDベースのMapReduceと比較して分割統治に特化した構造がパフォーマンスが出るのも当然だろ、という気がします。</p>
<p>それよりもむしろ、<code>テラ/ペタサイズのJOINやGroup Byが入り組んだクエリが数秒~数十秒で返ってくる</code>という理解不能な事象について深掘りして欲しい気がします。つまりちょうど<code>Dremel</code>のペーパーの範囲外ですw</p>
<p><a href="https://www.amazon.co.jp/Google-BigQuery-Analytics-Jordan-Tigani-ebook/dp/B00JUUZIZI" target="_blank" rel="noreferrer">Amazon.co.jp: Google BigQuery Analytics 電子書籍: Jordan Tigani …</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5438d3eb-fff3-4106-bd6e-4db25c4b588e/583ec39bdd099caa2040f48c::image.png" alt="img"></p>
<p>そしてようやく本題ですが、JOINを含めたQuery Processingについては2014年に出ているこちらの本の方が詳しいので、少し紹介したいと思います。<br>
ちなみにタイトルは（かなり）盛り気味です。</p>
<h1 id="先に感想">先に感想</h1>
<p>いくつかポイントがあると思いますが、僕が個人的に思うBigQueryのキモは次の3点です。（ちょっと想像で物を言っているので間違ってたら、、すみませんw）</p>
<ol>
<li>まずまずDisk IOの並列化（並みの並列化じゃない）</li>
<li>スピード重視でメモリとネットワークを酷使する設計（並みの酷使っぷりじゃない）</li>
<li>Slowなところを避ける代わりに出来なきゃ死ぬ設計。やり直せばいいという割り切り（その点逆にMapReduceはすごい）</li>
</ol>
<p>Disk IOを並列化して、読込をボトルネックから解放するのはこれ系では前提感あります。それに加えてネットワークを酷使したり、Hash PartitionによるShufflingなどで、メモリオーバーでabortするリスクをとるポリシーあたりがHadoopを含めたMap Reduce界隈と違うのかな、と感じます。</p>
<h1 id="基本構造とベーシックなクエリ処理">基本構造とベーシックなクエリ処理</h1>
<p>基本的な構造としては次のようになっているようです。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/55a1103a-d5c9-4f85-a446-1a0f8faa8ea2/583ec39bdd099caa2040f48b.png" alt="583ec39bdd099caa2040f48b.png"></p>
<p>クエリは<code>Root/Mixer/Slot</code>の順で伝播します。その時Slotのみで解決できないQuery要素に関しては排除されて伝播されます。<code>Slot</code>は実際にStorageレイヤと通信し最初の処理をする<code>Leaf Server</code>のスレッドのことのようです。そして、処理結果がSlot/Mixer/Rootの順で伝播し、それぞれ統治処理が行われます。</p>
<p>例えばJOINやGroup Byが絡まず、単純な分割統治処理のようなケースの場合</p>
<pre><code class="hljs"><span class="hljs-keyword">SELECT</span> corpus, word, word_count <span class="hljs-keyword">FROM</span> tbl 
  <span class="hljs-keyword">WHERE</span> LENGTH(word) <span class="hljs-operator">&gt;</span> <span class="hljs-number">4</span> 
  <span class="hljs-keyword">ORDER</span> <span class="hljs-keyword">BY</span> word_count 
  <span class="hljs-keyword">DESC</span> LIMIT <span class="hljs-number">5</span>
</code></pre>
<p>（word_countが最初からaggregationされているという現実にはなさそうなケースですが）単純に同じQueryがSlotに伝播され、それぞれのSlotが返す結果に対してMixerが同じQueryをかければ終了です。</p>
<h1 id="Small Group By">Small Group By</h1>
<p>次のようにGroup Byがある場合も分割統治型で処理されます。</p>
<pre><code class="hljs"><span class="hljs-keyword">SELECT</span> corpus, word, SUM(word_count) <span class="hljs-keyword">AS</span> total <span class="hljs-keyword">FROM</span> tbl 
  <span class="hljs-keyword">WHERE</span> ... 
  <span class="hljs-keyword">Group</span> <span class="hljs-keyword">By</span> corpus 
  <span class="hljs-keyword">ORDER</span> <span class="hljs-keyword">BY</span> total 
  DESC LIMIT <span class="hljs-number">5</span>
</code></pre>
<p>まず <code>Order</code>句と<code>LIMIT</code>句を排除してSlotに渡しクエリし、その結果をMixerに渡し、Mixerでは元のクエリをかけて終了です。ただしDistinctなKeyが多い場合メモリに乗り切らずabortします。</p>
<h1 id="BroadCast Join">BroadCast Join</h1>
<p>さてJoinですが、単純な場合としてJoinする片方がSlotにバラまけれるサイズであれば分割統治型の繰り返しで対応できます。（BigQueryでは <code>8mb</code>が閾値のようです）。こちらは</p>
<pre><code class="hljs"><span class="hljs-keyword">SELECT</span> hoge <span class="hljs-keyword">FROM</span> a 
  <span class="hljs-keyword">JOIN</span> 
    (<span class="hljs-keyword">SELECT</span> fuga <span class="hljs-keyword">FROM</span> b) <span class="hljs-keyword">AS</span> c 
  <span class="hljs-keyword">ON</span> a.hoge = c.fuga
</code></pre>
<ol>
<li>サブクエリ<code>SELECT fugue FROM b</code>のみをSlotに配布</li>
<li>Mixerに結果が返される</li>
<li>返された結果をインライン展開して、全体のクエリを配布</li>
<li>Mixerに結果が集められ、Aggregationして終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0f92e382-bd5f-4629-b49c-fa7a9c372f90/583ec39bdd099caa2040f48a.png" alt="583ec39bdd099caa2040f48a.png"></p>
<p>一つ面白いのは、例えば5000 Leafあれば 5000 x 8MB = 40GBのネットワークコストをかけている、というところです。</p>
<h1 id="Shuffled Query（Big Join/Big Group By）">Shuffled Query（Big Join/Big Group By）</h1>
<p>最後に複雑なケースとして、大規模なJOINと大規模なGroup Byのケースです。MapReduceと同じようにShuffleフェーズを組み合わせて処理をしますが、Merge Sortではなく、単純なHash Partitioningで分散します。つまり100台のLeafで処理していれば、keyに対して100でmodを取り対応する各Leafに配布します。</p>
<p>（元々は <code>JOIN EACH</code>や<code>GROUP EACH BY</code>といった特殊な句が用意されていましたが、自動で判断するようになったようなので、省きます。( <a href="https://cloud.google.com/bigquery/docs/reference/legacy-sql" target="_blank" rel="noreferrer">Query Reference </a> )）</p>
<pre><code class="hljs"><span class="hljs-keyword">SELECT</span> hoge <span class="hljs-keyword">FROM</span> a 
  <span class="hljs-keyword">JOIN</span> 
    (<span class="hljs-keyword">SELECT</span> fuga <span class="hljs-keyword">FROM</span> b <span class="hljs-keyword">GROUP</span> <span class="hljs-keyword">BY</span> fuga) <span class="hljs-keyword">AS</span> c 
  <span class="hljs-keyword">ON</span> a.hoge = c.fuga
</code></pre>
<ol>
<li><code>b</code>に関するサブクエリをLeafに配布する。（例えば100Leaf）</li>
<li><code>fuga</code>を100個にHash Partitioning（<code>shuffle</code>）し、Leaf間でデータを交換する</li>
<li>Leafでサブクエリを実行しMixerに終了したかどうかだけを返す（データは返さない）</li>
<li>次に<code>a</code>に関するクエリをLeafに配布する（例えば500Leaf）</li>
<li><code>hoge</code>を500個にPartitionしLeaf間でデータを交換する</li>
<li>さらに3のデータも500個にPartitionし、Leaf間でデータを交換する（この処理がどこに挟まるかちょっと書いてなくて想像で書いてます）</li>
<li>Shard上でJOINのクエリを実行し、Mixerに結果を返す</li>
<li>Mixerで統合し終了</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6e7a1ef9-4119-4d18-8b8c-dba18a848b52/583ec39bdd099caa2040f489.png" alt="583ec39bdd099caa2040f489.png"></p>
<p>大きな注意としては、どでかいデータでHashが偏ると乗り切らずAbortする、という点です。</p>
<h1 id="最後に">最後に</h1>
<p>先に書いた感想と同じですが、割と古典的というか泥臭いやり方でShuffleを実装したりしているところ、ネットワーク/メモリを酷使し、合わないものはAbortするところなど、失敗を許容する代わりにパフォーマンスを出す設計が重要なように思います。</p>
<p>もう少しMapReduce界隈との設計思想の違いについても想いを馳せてみたかったんですが、図を作っていたら力尽きた感じがあるので、議論したい方は是非ともPlaidの社内勉強会等に来てください！</p>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit.html" target="_blank" rel="noreferrer">プレイドの採用ページ</a>か、<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">Wantedly</a>をご覧ください。</p>
</body></html>

プレイドで使い倒しているBigqueryの内部構造について徹底解剖してみました！

BigQueryの内部処理について徹底解剖してみた| PLAID engineer blog

Bigqueryの内部処理について徹底解剖してみた

<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/81e6ad0d-7393-4edb-9ddf-8d6a74776c40/b169e8b6-b251-40e6-82a2-dfea82be77ff.png" alt=""></p>
<p>こんにちは！<br>
プレイドでインフラエンジニアをしている@ikemonnです。</p>
<p>本日は10/27(木)に開催しました「【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜」のレポートをお届けしたいと思います。</p>
<h2>発表タイトル</h2>
<ul>
<li>ペパボを支える大統一CI基盤と人々</li>
<li>KARTEを支えるCI環境</li>
<li>自動マルチブラウザテストを導入・運用した話</li>
<li>グーペのE2Eテスト運用事情</li>
<li>並行処理のテストは難しい</li>
</ul>
<h2>ペパボを支える大統一CI基盤と人々</h2>
<p>まずペパボ @ravelllさんから「ペパボを支える大統一CI基盤と人々」についてお話頂きました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0c5f4b9d8bc74e09ae75265cc73e9a8b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>ペパボさんのCI環境の変遷や現在の姿、現場の声、課題などについて発表して頂きました。<br>
各チームがそれぞれ <code>いいかんじに</code> CI環境を立てていた時代からdrone.ioを用いた社内統一CIができるまでのお話です。</p>
<p>CI環境を社内で統一することによって、「CI環境自体のトラブルが減ったり」「困ったときに誰にでも質問できて楽」といったメリットがあったそうです。<br>
とは言え、Dockerfileをメンテする人が有識者に限られたり、drone.io/Docker側の問題があったりと課題もあるので改善しつつ運用されているようです。</p>
<p>弊社も現在絶賛Dockerize中ですので、大変勉強になりました。</p>
<h2>KARTEを支えるCI環境</h2>
<p>次にプレイド @positiveflatから「KARTEを支えるCI環境」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="61d9c5aa1a3340e2b3a8510fd90ef810" data-ratio="1.29456384323641" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>プレイドでは、Web接客サービスKARTEのサービス開発当初から、CIの仕組みを強化し続けています。今回は、弊社のCIの全体像と、CI環境強化の途中で発生したいくつかの問題とその解決策について簡単に紹介しました。会場にいた方は、CIに取り組みたいけどまだ取り組んでいないという方が多かったので、今回の内容がCI導入のきっかけになれば幸いです。詳しくは<a href="/2016_08_24_uitest_automation/">こちらのブログの記事</a>でも説明していますので、是非ご覧ください。</p>
<h2>自動マルチブラウザテストを導入・運用した話</h2>
<p>次にプレイド @sdaikichiから「自動マルチブラウザテストを導入・運用した話」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="537b41d4a4434a58b6c69ebb1b701d07" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p><a href="/multi-browesr-test/">40通り以上の自動マルチブラウザテストをSelenium x CircleCI x BrowserStackで実現する</a> を元に、PLAIDでマルチブラウザ（クロスブラウザ）テストを導入・運用をした経験から、設定方法やハマりどころを紹介しました。<br>
（sdaikichiが挙手制アンケートをとったところ）会場にはほぼマルチブラウザテストを行っている人はおらず、CIのマルチブラウザテストはかなりハードルが高いことが伺えました。<br>
twitterでは「(BrowserStackに関して)テストを全て動画にしてくれるのはありがたい」などの感想がつぶやかれていました。</p>
<p>ポケモンやりすぎ！</p>
<h2>グーペのE2Eテスト運用事情</h2>
<p>続いてペパボ @hypermktさんから「グーペのE2Eテスト運用事情」の発表がありました。</p>
<div style="width: 100%">
 <script async class="speakerdeck-embed" data-id="d8b089ddbf864a848a0a88035eb4d176" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>自己紹介をPHPUnit(テストはちゃんとパスする)で書かれていて、掴みからバッチリでした！<br>
テストが全くなかったサービスにテストを導入されたお話で、チームメンバーにテストコードの必要性から実装方法までを説明し、今ではUTもE2Eテストも都度追加しておられるそうです。<br>
まずは正常閲覧テストから始めてみると簡単に実装できて良いとのことでした！</p>
<h2>並行処理のテストは難しい</h2>
<p>最後にペパボ @nakano_akihitoさんから「並行処理のテストは難しい」の発表がありました。</p>
<div style="width: 100%">
<script async class="speakerdeck-embed" data-id="0da601e2e2f1483b9cb21791d7bb0e0c" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
</div>
<p>並列・並行処理が注目されている中、どのように並列・並行処理のテストをすればよいかを具体的にコードを見つつ説明して頂きました。<br>
<code>sleep 1</code> のように不安定な処理をいれるのではなく、<code>Humble Object pattern</code>で処理を切り出したり、<code>メッセージパッシング</code> を使うことでテストを上手く書くことが出来ます。</p>
<p>ご自身でもPHPの並列処理をするライブラリ<a href="https://github.com/ackintosh/snidel">ackintosh/snidel</a>を書かれておられるので、ご興味のある方はご覧ください！</p>
<h2>最後に</h2>
<p>今後も引き続き勉強会を開催したいと思っておりますので、一緒に勉強会を開いてくださる方を募集中です。</p>
<p>また、ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


drone.io, CircleCI Enterprise, BrowserStack等を使用したテスト環境について、ペパボとプレイドで勉強会を開催しました！