<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等を使用したテスト環境について、ペパボとプレイドで勉強会を開催しました！

【ペパボ×プレイド】Tech Meetup 〜自動テスト・CI編〜を開催しました！

<html><head></head><body><p>こんにちは。プレイドの藤川(@atsushiss15)です。<br><br>
プレイドには学生時代よりインターンとして参加しており、今年の４月に新卒社員として正式に入社しました。現在に至るまで弊社の提供するKARTEの機能開発を担当しています。</p>
<p>今回はVue.jsを利用したコンポーネント指向のUI開発において、私たちが実際に遭遇した問題とその解決策として導入したStoreパターンについてご紹介したいと思います。<br>
Vue.jsというフレームワークが題材にはなりますが、Storeパターンの考え方自体は他のフレームワークを使った開発にも転用できると思うので、ぜひ読んでみていただければと思います。</p>
<h1 id="目次">目次</h1>
<ul>
<li>Vue.jsとは？</li>
<li>アプリケーションの大規模化に伴って生じた問題</li>
<li>解決策としてのStoreパターン</li>
<li>サンプルコード他</li>
<li>Storeパターンに移行した感想</li>
<li>最後に</li>
</ul>
<h1 id="Vue.jsとは？">Vue.jsとは？</h1>
<p><a href="http://jp.vuejs.org/" target="_blank" rel="noreferrer">Vue.js</a>を一言で表現するならば、「シンプルさが売りのMVVMフレームワーク」です。<br>
他の有名なMVVMフレームワークにはAngularJSやReactなどが挙げられますが、それらに比べてVue.jsはそのシンプルさ故に学習コストが低い上、あらゆる規模のアプリケーションで利用することができる設計になっています。</p>
<p>Vue.jsを知らない方でも、簡単なToDoアプリの実装例を見てみれば大体の使い方が理解できるのではないでしょうか。</p>

<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>
<script async="" src="//jsfiddle.net/atsushiss15/kj29sbh1/embed/js,html,result/"></script>
<p>上記のコードは、Vue.jsの公式サイトに掲載されているサンプルのコードを便宜上CoffeeScriptで書き直したものです。</p>
<p>簡単に解説をしてみます。<br>
id属性を用いてVueインスタンスと仮想DOMの紐付けを行い、<code>v-model</code>でデータの双方向バインディング、<code>{{ }}</code>構文でテキストのレンダリング、<code>v-for</code>でリストのレンダリング、<code>v-on</code>で要素にイベントリスナのアタッチをそれぞれ行っています。</p>
<p>Vue.jsはこの辺りさえ抑えておけば、とりあえずコードを書き始めることができるので便利です。</p>
<h1 id="アプリケーションの大規模化に伴って生じた問題">アプリケーションの大規模化に伴って生じた問題</h1>
<p>Vue.jsの最も大きな特徴の一つにコンポーネントシステムがあります。<br>
この仕組みを利用して、アプリケーションのUIをコンポーネントレベルに分割し、組み合わせるように実装することで、コードの再利用性が向上し、ロジックも各コンポーネントの中にカプセル化することができます。</p>
<p>コンポーネントの状態は各コンポーネントがそれぞれ管理し、状態やイベントの共有は<a href="http://jp.vuejs.org/api/#props" target="_blank" rel="noreferrer">props</a>や<a href="http://jp.vuejs.org/api/#vm-dispatch" target="_blank" rel="noreferrer">$broadcast</a>/<a href="http://jp.vuejs.org/api/#vm-broadcast" target="_blank" rel="noreferrer">$dispatch</a>といった仕組みを利用して行います。<br>
下図はコンポーネント間でのデータやイベントの伝達をイメージしています。propsを用いてデータを子コンポーネントへ明示的に受け渡したり、$broadcastや$dispatchを使って他コンポーネントへイベントの通知を送ることができます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ad51dcdd-703b-4f66-8255-89a89c6bdbcb/----------2016-10-12-19.27.58.png" alt=""></p>
<p>しかし、これらの仕組みを利用すると、アプリケーションの大規模化に伴い状態管理が複雑になってきてしまいます。<br>
状態が多くのコンポーネントに分散し、更にそれらが相互作用するようになるとpropsや$broadcastを使ったコンポーネント間でのデータやイベント伝達の仕組みが多用され、コンポーネント同士が密結合・複雑化し始めるのです。<br><br>
実際にKARTEの開発においても、これらが原因でコード変更の影響範囲が分かりづらく改修が困難になり、コードの重複やサーバーサイドとの無駄な通信などが散見されるようになっていました。</p>
<h1 id="解決策としてのStoreパターン">解決策としてのStoreパターン</h1>
<p>そこで私たちはStoreパターンによって<strong>アプリケーションの状態（State）・処理（Actions）・イベントの共有</strong>を行うことで、密結合しているコンポーネントの分離、コードの重複や無駄な通信の削減を目指しました。</p>
<h2 id="私たちがStoreパターンと呼んでいるもの">私たちがStoreパターンと呼んでいるもの</h2>
<p>Storeパターンは、Storeというグローバルな共有オブジェクトに複数のコンポーネントから使用される共通の状態・処理・イベントを管理させることで、コンポーネント同士を分離する考え方です。</p>
<p>下図のように、ユーザーから何らかの入力を受けたコンポーネントはStoreの共有処理（Shared Actions）を直接Callすることで共有状態（Shared State）を更新します。各コンポーネントはこの共有状態を監視することでそれぞれの表示を変化させます。<br>
また、Storeには共有のイベントも管理させます。何らかのイベントをトリガにしてコンポーネントごとの処理を行いたいケースなどは、これを利用して各コンポーネントに通知を送信します。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6593975e-2483-4c37-a10a-0c568d0ed4bd/----------2016-10-13-3.02.32.png" alt=""></p>
<h2 id="「Fluxとは何が違うの？」">「Fluxとは何が違うの？」</h2>
<p>というご指摘が挙がってきそうなので、<a href="https://facebook.github.io/flux/" target="_blank" rel="noreferrer">Fluxアーキテクチャ</a>との差分についても少し触れておきたいと思います。</p>
<p><a href="http://v1.vuejs.org/guide/application.html#State-Management" target="_blank" rel="noreferrer">Vue.js公式ドキュメント</a>でも言及されていますが、store patternは共有の状態・処理をグローバルなオブジェクトに管理させることでコンポーネント同士が密結合・複雑化してしまうのを防止することを目的としています。</p>
<p>そういった意味で、Fluxはstore patternの考え方をベースに、Event Dispatcherによる一方向（one-way）の状態更新フロー以外は許容しないという制約を加えたアーキテクチャであることが分かります。<br>
対して、私たちがStoreパターンと呼んでいるものは、Fluxの思想自体は汲み取りつつ柔軟性とシンプルさを担保したものであるといえます。</p>
<p>具体的には、状態更新に関する制約を設けないことで柔軟性を確保し、Event Dispatcher等は介さず直接関数をCallして状態更新を行うことでシンプルさを保つようにしています。そのためTPOに応じてコンポーネントが直接Storeの状態を書き換えることも許容します。</p>
<p>このように私たちがFluxのように、制約によってキレイに整理された（しかし少し大げさな）アーキテクチャよりも、柔軟性やシンプルさといったものを求めたのは**「ルールをできるだけ作らずに属人的に判断する」**という企業文化を大切にしているからです。<br>
また別の観点からみれば、KARTEの管理画面がサブアプリごとにページを分けるような構造になっており、そもそもフロントエンドが大規模化しすぎないように設計されているということも、このような方針を採る際の後押しとなりました。</p>
<h1 id="サンプルコード他">サンプルコード他</h1>
<p>何はともあれコードで説明するのが一番です。<br>
せっかくなので、冒頭でご紹介したToDoアプリのコードをStoreパターン的に実装してみます。</p>
<script async="" src="//jsfiddle.net/atsushiss15/fgone3us/1/embed/js,html,result/"></script>
<p>この例ではStoreによって状態（state）と処理（addToDo, removeTodo）の共有を行っています。<br>
一見コードが増えたようにも見えますが、複数コンポーネントで状態や処理の共有が行われるようになるとStoreパターンによる恩恵を享受できるはずです。</p>
<h2 id="イベントの通知について">イベントの通知について</h2>
<p>イベントの通知については幾つかの手段が考えられますが、次の２つをケースにより使い分けるのが良いのではないでしょうか。</p>
<h3 style="color:#494a50;" id="1. StoreのEventEmitterを利用してEventの通知を行う">1. StoreのEventEmitterを利用してEventの通知を行う</h3>
<pre><code class="hljs"><span class="hljs-comment"># Store側</span>
{EventEmitter} = <span class="hljs-built_in">require</span> <span class="hljs-string">'events'</span>
<span class="hljs-class"><span class="hljs-keyword">class</span> <span class="hljs-title">XxxYyyStore</span> <span class="hljs-keyword">extends</span> <span class="hljs-title">EventEmitter</span></span>
<span class="hljs-comment"># 省略...</span>
</code></pre>
<pre><code class="hljs"><span class="hljs-comment"># コンポーネント側</span>
<span class="hljs-comment"># ...省略</span>
methods: <span class="hljs-function">-&gt;</span>
    hogeAction: <span class="hljs-function">-&gt;</span>
      <span class="hljs-comment"># 別vueや別componentに変更等を通知</span>
      xxxYyyStore.emit <span class="hljs-string">'conditionChanged'</span>, {}

  compiled: <span class="hljs-function">-&gt;</span>
    <span class="hljs-comment"># 別vueや別componentからStore経由でイベントハンドリング</span>
    xxxYyyStore.<span class="hljs-literal">on</span> <span class="hljs-string">'conditionChanged'</span>, <span class="hljs-function"><span class="hljs-params">()</span> -&gt;</span>
      <span class="hljs-comment"># handling</span>
</code></pre>
<h3 style="color:#494a50;" id="2. watchやcomputedを利用して間接的にイベントハンドリングを行う">2. watchやcomputedを利用して間接的にイベントハンドリングを行う</h3>
```
# Store側
# ...省略
watch:
  'xxxYyyStoreState.todos': -&gt;
     # 共有状態に変更があった場合の処理
computed:
    isEmpty: -&gt;
      @xxxYyyStoreState.todos.length is 0 
```
複雑な変更と明示的なタイミングの制御が必要なものは **1.** の方法で個別にハンドリングし、そうでない場合は **2.** の方法でハンドリングするといった要領で使い分けてみると良さそうです。
<h2 id="その他に留意すべき点">その他に留意すべき点</h2>
<p>また、Vue.jsでStoreパターンを構築する際には以下の点にも留意するようにしてください。</p>
<h3 style="color:#494a50;" id="1. XxxYyyStore.stateに余分なものを入れない">1. XxxYyyStore.stateに余分なものを入れない</h3>
XxxYyy.stateは、Storeの外に公開されるオブジェクトです。Vueのデータ更新監視の対象になるので、あまり大きなものを入れないほうが良いです。
<h3 style="color:#494a50;" id="2. XxxYyyStore.stateを置き換えない">2. XxxYyyStore.stateを置き換えない</h3>
一つのStoreインスタンスを複数箇所で使い回す形になります。
constructorで作ったstateを、複数のVueコンポーネントで監視するようになるので、state自体を置き換えるコードがあると、値の追跡が正常に行われなくなります。
```
# まずい例
constructor: -&gt;
  @state=
    value: ''
updateXxx: (newState) -&gt;
  @state = newState # &lt;- @stateを置き換えているので、更新が拾えなくなる
```
<h3 style="color:#494a50;" id="3. 基本的に$broadcast, $dispatch, $parent, $childは使用しない">3. 基本的に$broadcast, $dispatch, $parent, $childは使用しない</h3>
これらの仕組みはほとんどStoreパターンで補うことができるので、コンポーネントの密結合・複雑化を防ぐためにも使うべきではありません。props（データを子コンポーネントに明示的に伝達する仕組み）に関しても使用を必要最小限に抑えてください。
<br>
さて、簡単なサンプルコードを使って説明してきましたが、なんとなく感覚は掴んでいただけたかと思います。実際にはもう少し考えなければならない事があるのですが、基本的には上記のシンプルなパターンを拡張していくイメージになります。
<h1 id="Storeパターンに移行した感想">Storeパターンに移行した感想</h1>
<h2 id="良かった点">良かった点</h2>
<ul>
<li>サーバーとの通信処理や複雑なロジックがStore側に集約されたことで、コンポーネント側はVueが本来担うべき表示系の処理に集中できるようになった。</li>
<li>コンポーネント間の密結合が解消され、コンポーネントの再利用性が高まった。</li>
<li>全体的に見通しが良くなるのでロジックの改修等が楽に行えるようになった。</li>
</ul>
<h2 id="考えるべき点">考えるべき点</h2>
<ul>
<li>重い初期化処理に対しては適宜遅延させるなどの工夫が必要になる</li>
<li>Storeでの処理後にコンポーネント側で後処理を行う際は、コールバックで行うのか、状態の変更を監視して行うのか、イベントをハンドリングして行うのか、などを適宜使い分ける必要がある</li>
<li>状態の更新フローに関する制約をどこまで設けるかは再考する必要がある</li>
</ul>
<p>所感としては、Storeパターンへの移行の目的としていた点はおおよそ満たせたのではないかと感じています。もちろんまだまだ試行錯誤が必要な点はあると思うので、より良いアーキテクチャを目指して日々改善していきたいと考えています。</p>
<h1 id="最後に">最後に</h1>
<p>ウェブ接客プラットフォーム「KARTE」を運営するプレイドでは、 KARTEを支える技術に興味を持つエンジニア（インターンも！）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html" target="_blank" rel="noreferrer">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects" target="_blank" rel="noreferrer">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>
</body></html>

Vue.jsを用いたコンポーネント指向のフロントエンド開発において弊社が導入したStoreパターンについてご紹介します。

コンポーネント指向のUI開発時に起きがちな密結合・複雑化問題をStoreパターンで解決する

<p>みなさん、ごきげんよう。プレイドの@akobaです。<br>
プレイドではCXチームのエンジニアとして、プロダクトの機能開発、ならびに弊社のウェブ接客プラットフォームKARTEで提供するアプリケーションの開発を行っています。<br>
今回は、KARTEでできることを広げる試みの一環として、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。<br>
具体的には、ユーザーの閲覧履歴、レビュー／コメント機能、今この記事をxx人が見ていますといった機能を作ってみました。<br>
通常ネイティブアプリ向けとして使われることが多いFirebaseですが、Webブラウザ上でも色々と面白いことができます。<br>
この記事が皆さんの開発の参考になれば幸いです。</p>
<h2>目次</h2>
<ul>
<li>Firebaseとは</li>
<li>Firebaseにデータを貯めていく</li>
<li>ページ内でユーザーの情報を共有する</li>
<li>リアルタイム機能を使う</li>
<li>KARTEを使ってアプリを配信</li>
<li>まとめ</li>
</ul>
<h2>Firebaseとは</h2>
<p><a href="https://firebase.google.com/">Firebase</a>とは、最近大きく注目を集めているMBaaS(Mobile Backend as a Service)、つまりモバイル開発のためのクラウド・ベースのバックエンドサービスです。2014年にGoogleに買収され、Google I/O 2016で新バージョンが発表されました。<br>
ここでのバックエンドとはDB、認証、ストレージ、解析、メッセージングプラットフォームなど（詳細は公式サイト参照）で、主にネイティブアプリ向けのプラットフォームとして提供されています。<br>
ただし、Web用のSDKも準備されており、今回はこのSDKをWebサイト上で使ってみたいと思います。</p>
<p>SDKといっても、Webページに下記のようなタグを貼るだけです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e5c996e6-805a-4054-8eaa-d1d6bbab1717/-2016-09-29-7.23.18.png" alt="web-setup-code"><br>
（xxxの箇所はFirebaseのプロジェクトによって異なります。詳細は<a href="https://firebase.google.com/docs/web/setup">こちら</a>）</p>
<p>Firebaseには様々な機能が用意されていますが、今回は<a href="https://firebase.google.com/docs/database/">Realtime Database機能</a>にフォーカスして使ってみます。<br>
この機能、BaaSなので当然なのですが、自分でサーバーを立てる必要がなく、上記のタグを貼るだけでブラウザからアクセス可能なKVSとして利用できます。<br>
DBとしての特徴は主に下記となります。</p>
<ol>
<li>DB全体が1つのJSON treeとして扱える</li>
<li>データの更新時、データを使っている各クライアントにリアルタイムで同期される</li>
<li>オフライン時もクライアント側でデータを保持し、オンラインになった時点でオンラインデータとマージされる</li>
</ol>
<p>1のために、個別のデータを更新するにはそのパスを指定して更新、全体を更新するにはルートパスに大きなJSONを1つ送るだけで済みます。（ただし大きすぎるJSONについてはそのまま送信はできないので、細かく分割して送信する<a href="https://github.com/firebase/firebase-import">ツール</a>が公開されています。）また読み込みの際も、全体のデータが欲しいのか、一部のデータが欲しいのかを、参照するJSONのパスを指定することで細かく指定することができます。<br>
2は色々と面白いことができそうですね。<br>
3もかなり便利そうですが、今回は使いません。</p>
<h2>Firebaseにデータを貯めていく</h2>
<p>では、実際にFirebaseのDBを使ってみましょう。</p>
<p>FirebaseのDBはKVS(Key Value Store)なので、なんらかのキーを軸にデータを集めていくことになります。<br>
キーとして もっともよく使われるのはユーザーID（ユーザー軸）でしょう。それ以外にWebページのURLやWebページ上のアイテム・コンテンツID、もしくは地域やユーザー属性のようなものをキーにしても面白いかもしれません。<br>
今回は、ユーザー軸とWebページ軸の情報をFirebaseに集めることにします。</p>
<p>まず最初にWebページ軸の情報。</p>
<pre><code>var pagePath = 'page/' + encodeURIComponent(location.pathname).replace(/\./g, '%2E');
firebase.database().ref(pagePath)
  .set({
    image: image,
    title: title
  });
</code></pre>
<p>ページのURLパスをキーとして、ページ毎に、そのページのタイトルと画像URLを保存してみます。<a href="http://ogp.me/">Open Graph</a>の値などを入れておくといいですね。<br>
<code>page/</code>の部分はなんでもいいですが、RDBのテーブル名のように、データの種類を区別するためにつけておきます。また、Firebaseのキー名には<code>., $, #, [, ], /</code>は使えないのでパーセントエンコードしておきます。（が、以下では簡略化のためにエンコードのコードは記載しません）</p>
<p>次にユーザー軸の情報。単純に、閲覧したページのURLを保存しておきましょう。</p>
<pre><code>var userPath = 'user/' + userId;
firebase.database().ref(userPath + '/visit/' + location.pathname)
  .set({
    timestamp: parseInt(new Date() / 1000)
  });
</code></pre>
<p>ごちゃっとしていますが、<code>user/[ユーザーID]/visit/[URLパス]</code>に<code>timestamp</code>という値を書き込んでいます。<br>
<code>userId</code>の箇所は、なんらかの形で保持しているユーザー毎のIDを使用します。</p>
<p>ユーザーがページを見るたびにその情報をFirebaseに書き込んでいくと、FirebaseのDBには下記のようにデータが溜まっていきます。</p>
<pre><code>{
  &quot;page&quot; : {
    &quot;%2Fproducts%2Fdetail%2F12&quot; : {
      &quot;image&quot; : &quot;http://xxx.jpg&quot;,
      &quot;title&quot; : &quot;xxx&quot;
    },
    ...
  },
  &quot;user&quot; : {
    &quot;akoba&quot; : {
      &quot;visit&quot; : {
        &quot;%2Fproducts%2Fdetail%2F12&quot; : {
          &quot;timestamp&quot; : 1474968518
        }
      }
    },
    ...
  }
}
</code></pre>
<p>こうやって、ユーザー毎にそのユーザーが見たページのURL（パス）、ページ毎にそのページのタイトルと画像を保存しておくと、最近見たページのリスト（いわゆる閲覧履歴）が表示できます。</p>
<p>まず最初に、自分のユーザー情報を取得します。</p>
<pre><code>firebase.database().ref(userPath)
  .once('value')
  .then(function(snapshot) {
    var myUserData = snapshot.val();
    ...
  });
</code></pre>
<p><code>once</code>とは、このタイミングでデータを一度だけ取得するということです。更新の監視は行いません。</p>
<p>myUserDataには上記のJSONの一部、下記のようなデータが入っています。</p>
<pre><code>&quot;visit&quot; : {
  &quot;%2Fproducts%2Fdetail%2F12&quot; : {
    &quot;timestamp&quot; : 1474968518
  }
}
</code></pre>
<p>このvisit以下の各キーについて、ページの情報を取得すると、過去閲覧したページの画像とタイトルを表示できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/91964ea1-84de-4013-8086-3e5df2208773/-2016-09-28-19.07.08.png" alt="recent_items"></p>
<p>1点注意ですが、当然閲覧履歴はどんどん溜まっていきます。残念ながら、現状FirebaseのDBにはexpireの機能がないようなので、ある程度の数を超えたらtimastampの古いものから消していく等の対応が必要です。</p>
<h2>ページ内でユーザーの情報を共有する</h2>
<p>先ほどの例は、ユーザーを軸に、ページの情報を取得しましたが、その逆も可能です。<br>
たとえば、</p>
<pre><code>firebase.database().ref(pagePath + '/review/' + userId)
  .set({
    nickname: nickname,
    comment: comment,
    starCount: starCount,
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>のような値を書き込むことで、ページにユーザーレビューを投稿する機能も実装できます。<br>
ユーザーレビューまで行かなくても、書き込みを例えばサイトのスタッフのみに制限しておけば、各ページ、そのページに表示されている商品や記事への、スタッフのコメント機能が実現できます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2a0b8dd-d4d3-4a52-8478-60aa1ef0f73f/-2016-09-27-23.09.33.png" alt="staff_comment"></p>
<p>スタッフは、実際に自分のサイトにアクセスして、該当のページでコメントを入力するだけです。<br>
こういった機能はいかにもウェブ接客という感じですね。</p>
<h2>リアルタイム機能を使う</h2>
<p>Firebaseの特長でもある、リアルタイムのデータ同期機能を使ってみましょう。<br>
今度もページ軸で、</p>
<pre><code>firebase.database().ref(pagePath + '/visit/' + userId)
  .set({
    timestamp: parseInt(new Date() /1000)
  });
</code></pre>
<p>そのページを見ているユーザーをどんどんページ情報に追加していきます。<br>
ページ側では、そのページの情報を下記のように取得します。</p>
<pre><code>firebase.database().ref(pagePath + '/visit')
  .on('value', function(snapshot) {
    updateUserCount(snapshot.numChildren());
  });
</code></pre>
<p>先ほどの<code>once</code>と違い、<code>on</code>では対象の値が更新されるたびに都度、指定した関数が実行されます。<code>numChildren</code>でデータ内の子要素の数を取得し、<code>updateUserCount</code>で表示するユーザー数の値を更新します。<br>
こうしておくと、表示されているユーザー数が、新しくユーザーが来訪するたびに増えるようになります。</p>
<p>ということで、今このページに出ている↓は、実際にFirebaseで作っています。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7e1e941a-c86e-4a93-8cd1-8c06e596093f/-2016-09-28-18.57.14.png" alt=""></p>
<p>なんか出てたけど消しちゃったよという方は、このページをリロードいただくともう一度出るかと思います。</p>
<p>こちらについても、timestampをチェックして一定時間以上前のユーザーは削除していく等の対応が必要です。このページに設置してあるものについては、ページの閲覧から10分以上経過したユーザーを削除しています。</p>
<h2>KARTEを使ってアプリを配信</h2>
<p>最後に、こうやって作ったアプリケーションを、弊社のウェブ接客プラットフォームKARTEで実際に配信してみます。<br>
上記のサンプルでは、ユーザー軸、ページ軸ともFirebaseのDBを使ったのですが、KARTE自体がユーザー軸の解析を行っているので、ユーザー軸のデータの管理はKARTEに任せることができます。<br>
したがって、KARTEを使って上記のアプリを配信する際は、下記のような役割分担となります。</p>
<ul>
<li>KARTE：いつ・誰に・どうやって配信するかを制御。ユーザー情報を管理</li>
<li>Firebase：ページ毎の情報を管理</li>
</ul>
<p>KARTEでは、通常あらかじめ用意されたテンプレートを利用し、色やテキスト、画像等を差し替えるだけでコンテンツが配信可能です。しかし、もちろんフルカスタマイズすることも可能で、HTML、CSSに加えてJavaScriptの実行も可能な自由度の高いプラットフォームとして作られています。<br>
したがって、今回のような外部のサービスを利用することも、そのためにそのサービスのタグを呼び出すことも可能です。また、今回の記事では触れていませんが、いわゆるウィジェットを作る用のAPIも用意されています。</p>
<p>実際に作成しているエディタの画面です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/1462c55a-bbfe-4b20-b725-232def824886/-2016-09-27-16.44.49.png" alt=""><br>
HTML、CSS、JavaScriptが自由に編集できるので、ここにFirebaseを使用するコードを書きます。</p>
<p>先ほどご紹介した、このページで表示しているユーザー数のカウンターも、KARTEを使って配信しています。</p>
<h2>まとめ</h2>
<p>最後は少し駆け足になってしまいましたが、Firebaseを使って簡単にWebサイト上で動作するリアルタイムアプリケーションが作れる様子、またそれをKARTEを使ってWebサイト上に自由に配信できる様子が伝わりましたでしょうか。<br>
実際、Firebaseでアプリケーションを開発する際には、事前に用意する必要があるものもほとんどなく、思い立ったタイミングでサクッと簡単に機能を実装できてしまいます。</p>
<p>ウェブ接客プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" id="wantedly-visit-buttons-wjs" 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>


今回は、Firebaseというサービスを使ってWebサイト上で動作するアプリケーションをいくつか作ってみたのでご紹介します。