Engineer Blog

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> です。</p>
<p>今回は、2023年4月からBigQueryが<strong>Editions</strong>という料金体系の変更を行なったことによる、コスト最適化の挑戦について書いていこうと思います。前回は3年以上前になりますが、<a href="https://tech.plaid.co.jp/bigquery-slot-resource-optmization">6,000スロットを使うBigQueryのリソース配分最適化への挑戦</a> として同様にコストの最適化についてご説明してありますので、Slotとは何？という疑問をお持ちの方はこちらも是非ご参照下さい。</p>
<p>BigQueryは、Google Cloud Platformが提供する、大規模なデータセットを高速に分析できるデータウェアハウスです。BigQueryは、企業のデータ分析基盤として広く利用されており、その利用量は年々増加しています。</p>
<p>しかし、BigQueryのコストは、データの量やクエリの実行回数に応じて増加するため、コスト管理が重要となります。特に、BigQueryは2023年4月から、料金体系が<a href="https://cloud.google.com/bigquery/docs/editions-transition?hl=ja">Editionsに変更</a>され、従来の料金体系が変化しました。弊社におけるインパクトは主に2つあり</p>
<ul>
<li>slot(定額)の単価の増加</li>
<li>storageコストの減少</li>
</ul>
<p>による影響が発生しました。</p>
<p>storageコストに関する<a href="https://cloud.google.com/bigquery/pricing?hl=ja#storage">料金変更</a>としては、Physical StorageとLogical Storageといういずれかの課金体系が選択可能になったという点があります。どちらが最適かはユースケースによって大きく異なるため詳細は省きますが、<strong>Long-Term Physical Storage</strong> という圧縮効率が高く、長期保存されるデータに関しての費用が減少するため、弊社の場合はPhysical Storageへの課金とすることである程度のコスト減となりました。</p>
<p>一方で、slotの単価が <strong>$0.024/slothour</strong> から <strong>$0.048/slothour</strong> へ2倍の増加となるので、こちらのインパクトがより大きいという実情でした。従って、全体では大幅に増加という影響になり、弊社の分析基盤の要でもあるため、7月から9月にかけて集中的に主にSlotを中心としたコストを最適化する流れとなりました。その名も、<strong>Bigquery-Slot-Optimization Team</strong>です！</p>
<p>本記事では、BigQueryのSlotの最適化について主に実行した ① Monitoringの整備によるJobごとのSlot監視と削減、②AutoScaleの導入によるSlotBaseLineの最適化 という2つの観点から解説します。</p>
<h2>① Monitoringの整備によるJobごとのSlot監視と削減</h2>
<p>Slotのコスト削減のためには、まず、BigQueryの利用状況を把握することが重要です。BigQueryの利用状況を把握する第一歩は、BigQueryのConsoleのMonitoringを利用することです。Monitoringでは、BigQueryのジョブの実行状況やリソースの使用状況を時系列で確認することができます。Organization全体ではこのような利用状況であることが確認できます。<br>
<img src="https://ik.imagekit.io/plaid/cba093e9-b2e1-4746-b24f-4f0f99077eb7/bq_console_top_v2.png" alt="bq_console_top_v2.png"></p>
<p>MonitoringでBigQueryの利用状況を把握したら、slotを大きく消費しているJobを特定します。しかし、Monitoringの画面だけでは、ReseravtionやProjectごとでのGroupByしかできないため、クエリレベルでの細かい単位で調査することはできません。また、そもそも画面が非常に重く現実的に使いやすいものとは言えないという背景がありました（こちらはGoogleさん...お願いします...!）。クエリにラベルを適切に付与していれば、そちらで管理することも可能ですが、全てのProductでクエリにラベルを振るのは現実的ではありませんでした。そこで、独自のMonitoringを構築する必要が生じるため、CloudFunction/CloudScheduler/Datadog を用いて実装します。</p>
<p>まず、slotの消費は主にslot_ms (slot millisecond)で調査することになります。100slotを60sec利用するJobであれば、100×60×1000 = 6,000,000 slot millisecond という単位になります。</p>
<p>時系列で把握したいので、<code>INFORMATION_SCHEMA.JOBS_TIMELINE</code> というテーブルを利用します。<br>
単純には</p>
<pre><code class="language-sql">  SELECT
    job_id,
    period_start,
    period_slot_ms
  FROM
    `{YOUR_PROJECT_NAME}.region-us`.INFORMATION_SCHEMA.JOBS_TIMELINE
  WHERE
    period_start BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 20 MINUTE)
    AND TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 5 MINUTE)
    AND job_type = 'QUERY'
    AND statement_type != 'SCRIPT'
</code></pre>
<p>のようにすれば、簡単に取得できます。</p>
<p><strong>period_slot_ms</strong>とはperiod(=1sec)あたりのslot_msを意味するので、1secあたりのJobごとのスロット消費量が簡単に取得できます。</p>
<p>このテーブルをさらに、<code>INFORMATION_SCHEMA.JOBS</code> というテーブルを用いて、job_idをkeyにjoinすることで、実行されたqueryを取得できます。取得したqueryをさらに、<code>REGEXP_CONTAINS</code> 関数を用いて、正規表現で任意のJobに集約します。例えば、<code>WHEN REGEXP_CONTAINS(query, r'/* JOURNEY') THEN 'journey'</code> という表記により、queryのコメントに<code>/* JOURNEY</code> が含まれているqueryを <a href="https://karte.io/product/journey/">Journey</a> というProductのために使っているQuery Jobという形で集約できます。</p>
<p>集約することで、Productごとに消費したslotのtimelineが得られるので、これをDatadogに送信します。送信するには <a href="https://cloud.google.com/functions?hl=en">CloudFunction (2nd gen)</a> を用いることで簡単にDatadogに送信できます。</p>
<p>Query ResultをBigqueryClientとDatadogClientを用いて送信するだけです。<br>
TypeScriptで書くとこのようになります。（※一部抜粋）</p>
<pre><code class="language-typescript">  const slots: v2.MetricSeries = {
    metric: '${metric_name}',
    type: 2,
    interval: 1,
    points: points,
    tags: [`project:${projectId}`, `task:${task}`],
  };

  const params: v2.MetricsApiSubmitMetricsRequest = {
    body: {
      series: [slots],
    },
  };

  apiInstance
    .submitMetrics(params)
    .then((data: v2.IntakePayloadAccepted) =&gt; {
      console.log('API called successfully. Returned data: ' + JSON.stringify(data));
    })
    .catch((error: any) =&gt; console.error(error));
</code></pre>
<p>この関数をDeployするには</p>
<pre><code class="language-bash">gcloud functions deploy $FUNCTION_NAME \
  --project=$GCP_PROJECT \
  --region=$REGION \
  --runtime nodejs14 \
  --entry-point=index \
  --gen2 \
  --source ./build \
  --trigger-topic=$TOPIC_NAME \
  --trigger-service-account=$TRIGGER_SERVICE_ACCOUNT_ADRESS \
  --service-account=$SERVICE_ACCOUNT_ADRESS \
  --retry \
  --timeout=180s \
  --set-env-vars=DATADOG_APP_KEY=$DATADOG_APP_KEY,DATADOG_API_KEY=$DATADOG_API_KEY
</code></pre>
<p>というgcloudコマンドだけでdeployできます。</p>
<p>さらに、このFunction を Cloud Scheduler で定期的に実行します。<br>
ただし、あまりにも頻度が高いとslotに負荷をかけるため、10分おきに実行しています。</p>
<p>結果として、送信したMetricsを用いて以下のようなDashBoardを構築しました。<br>
<img src="https://ik.imagekit.io/plaid/61cdd26c-0f08-4fbd-b796-63bbce5c8612/datadog_top_v2.png" alt="datadog_top_v2.png"></p>
<p>これにより、どのJobがどの時間に大きなSlotを消費しているのかが、一目瞭然になります。<br>
消費Slotの多い上位のJobをターゲットにして、それぞれ個別に対策を行います。</p>
<h2>② AutoScaleの導入によるSlotBaseLineの最適化</h2>
<p>BigQueryのコスト削減のためには、<a href="https://cloud.google.com/bigquery/docs/slots-autoscaling-intro?hl=ja">AutoScale</a> を利用することも有効です。AutoScaleは、BigQueryの利用状況に応じて、自動的にリソースをスケールアップまたはスケールダウンする機能です。AutoScaleを利用することで、余剰していたBaseLineを最適化し、コストを削減することができます。</p>
<p>弊社はReservationという単位でProductごとに個別のSlotを持っているため、個別に利用状況を判断し調整します。<br>
例えば Datahub というProductではdatahub独自のSlotをReservationとして占有しており、サービス提供に支障がないように余裕をもったBaseLineを敷いていました。<br>
しかし、休日深夜帯などほとんど利用されていないような時間帯でも、BaseLine分の料金は課金されてしまうことになります。<br>
これを最適化するために導入されたのが、AutoScaleです。</p>
<p>そうなるとBaseLineを全部0にしてしまえばいい感じに最適化されるのでは？と疑問に思うかもしれませんが、一方でBaseLineにはCommitという概念があり、<a href="https://cloud.google.com/bigquery/pricing?hl=ja#flat-rate_pricing">年間契約</a>することにより割引価格が適用できます。</p>
<p>そのため、固定分を割引価格で、変動分を定価で、のような使い方をすることができるため、一概に0にするのが正解とはいえません。</p>
<p>これらを考慮した上で、弊社で最適化した結果が以下の通りです。<br>
<img src="https://ik.imagekit.io/plaid/daa0289b-1fe7-4024-9dca-440bebed292d/slot_autoscaling.png" alt="slot_autoscaling.png"></p>
<p>いかがでしょうか。利用量に応じて動的にSlotがAutoScaleしていることがわかると思います。<br>
ただし、BaseLineと違って変動分にどれくらいのコストがかかっているのか？がなかなかConsoleだけだとわかりにくいので、こちらもDatadogに送信すると以下のような画面になります。<br>
これによりBaseLine+AutoScaleの料金の見積もりと監視が容易になります。<br>
<img src="https://ik.imagekit.io/plaid/a741e551-2926-4af0-a77b-1edc77c04a38/datadog_autoscale.png" alt="datadog_autoscale.png"></p>
<p>ただし、AutoScaleも完璧ではなく、Scaleup/downでOverHeadの時間はかかります。<br>
弊社の要件であると、「軽いクエリで必ず1,2sec以内で結果を返して欲しい」という要件も一部存在します。その場合は、interactive用のReservationを別途確保して、BaseLineを100や200で設定することで、この問題を解決することが可能です。</p>
<p>最も大事なのは、<strong>Productごとに要件を把握し適切にReservationを配分する</strong>ことであり、前回同様変わらないです。Product Teamとしてはもちろん余剰にSlotを使えた方が楽なのですが、会社全体としての予算があり、あくまでその配分の中で最適化するというのを理解してもらうことが大事です。</p>
<h2>最終的なコストは...?</h2>
<p><strong>全体で約20%のコスト削減を実現</strong> することができました。<br>
年間にして***円(非公開)の効果で、弊社の基盤としてはかなりのインパクトがありました。</p>
<p>以上のように<br>
① Monitoringの整備によるJobごとのSlot監視と削減<br>
② AutoScaleの導入によるSlotBaseLineの最適化全体</p>
<p>でBigQuery全体として、約20%のコスト削減を実現しました。</p>
<p>BigQueryのUpdateは特に早く、コストの最適方法はその都度変化するため、継続的に検討を行う必要があります。今回の方法は主にEditionsへの移行に伴う最適化でしたが、今後のUpdateに伴ってより良い方法が出る可能性があります。ご自身の環境へ適用する場合は、最新のドキュメントを参照の上、ご検討下さい。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営する<a href="https://plaid.co.jp/">PLAID</a>では、データを活用しプロダクトを改善していくエンジニアを募集しています。<br>
詳しくは、<a href="https://recruit.plaid.co.jp/">弊社採用ページ</a>をご覧ください。</p>


BigQuery Editionsにおけるコスト最適化

BigQueryのコストの最適化への再挑戦〜BigQuery Editionsへの料金体系の移行について〜

社内で脆弱性診断を行なっている理由や、どのように診断から修正までを行なっているか、また社内で脆弱性診断をやることでどのような変化が起きたかについて紹介します。

社内でのプロダクト脆弱性診断の方法、継続することで見つかる脆弱性の傾向の変化

今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。

MongoDB AtlasからBigQueryへのリアルタイムレプリケーション

<p>初めまして！エンジニアのとさ (@tosa_now)です！</p>
<p>プレイドは、2023/10/28 (土) に開催された<a href="https://vuefes.jp/2023/">Vue Fes Japan 2023</a>にゴールドスポンサーとして協賛しました。</p>
<p>スポンサーブースの運営をする機会をいただき、参加者の皆さんに<a href="https://karte.io/">KARTE</a>のデモや現在作成中の機能についての説明やお話をすることができました。</p>
<p>今回のブログでは、参加したVue Fes Japanの様子をお伝えできればと思います。</p>
<p>今回スポンサーとして参加した理由は、PLAIDが開発しているKARTEというプロダクト内ではなんとVueが0系の時から利用しており、現状でも管理画面の大部分がVueで書かれておりコミュニティに助けられているので少しでも還元したいという思いから参加しました！</p>
<h2>Vue Fes 当日の様子</h2>
<p><img src="https://ik.imagekit.io/plaid/20f62fe9-7a00-4d55-b0bc-8e3702e7b810/1000002289.jpg" alt="1000002289.jpg"><em>スポンサーブースの準備完了後の写真</em></p>
<p>主にブースではKARTEのプロダクト説明をメインで行っていました。<br>
来訪してくださった方とVue2からVue3への移行をどのように進めているのかなどの技術雑談話でもりあがりました。</p>
<p><img src="https://ik.imagekit.io/plaid/bcbfc85c-7535-4087-a132-75fbb2c890cc/IMG_4361.jpg" alt="IMG_4361.jpg"><em>エンジニアのnichimuさんがスポンサーブースに立っている様子</em></p>
<p>プロダクト説明では、<a href="https://blocks.karte.io/">KARTE Blocks</a>と新機能であるエレメントビルダーを開発しているエンジニアのjunjun (@junish_js) さんによるデモで大いに盛り上がりました！！</p>
<p>エレメントビルダーの開発の裏側は<a href="https://cxclip.karte.io/products/developer/action-editor/">こちら</a>の記事で解説しています</p>
<p><img src="https://ik.imagekit.io/plaid/4a62f6c0-d15d-49ff-a81f-cb11fe87f2d6/IMG_4364.jpg" alt="IMG_4364.jpg"><em>エンジニアのjunjunさんがプロダクト説明をしている様子</em></p>
<p>とさの個人的な趣味でVue Fesの開催二日前に発売されたHHKB Professionalのお試し会も開催しました。興味を持ってくださる方が多くて嬉しかったです。<br>
<img src="https://ik.imagekit.io/plaid/00ea3072-8ce7-4ef7-ad70-6a0cfcf0e2a3/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882023-11-0510.53.04.png" alt="スクリーンショット2023-11-0510.53.04.png"></p>
<p>Vue Fesのスポンサーブース全体が賑やかでどの企業さんも回っていてとても楽しかったです。</p>
<h3>参加した開発メンバーの感想</h3>
<p>デザイナーの今西さん<br>
今回、ブース対応を初めて担当し、KARTEの魅力が少しでも伝わっていれば嬉しいなと思います。ひさしぶりのオフラインカンファレンスということで、当日は大いに盛り上がり、とても楽しい1日を過ごすことができました！</p>
<p>エンジニアのjunjunさん<br>
Vue Fesにスポンサーとして参加したのが新鮮でした。また、イベントは参加者と交流するという楽しみかたがあるんだと気づきました。私はVue Fesがきっかけでプレイドを知って入社したので、皆さんも知っていただけたら嬉しいです。またお会いましょう！</p>
<h3>おわりに</h3>
<p>Vue Fesのスタッフの皆さん、準備及びに当日の運営ありがとうございました！<br>
PLAIDはこれからもVue.jsのコミュニティグループの活動を応援しています。</p>
<p><img src="https://ik.imagekit.io/plaid/a0f082ec-3452-4958-a31d-50c506335c07/1000002292.jpg" alt="1000002292.jpg"><em>ブース撤収直後のサインボードの様子</em></p>


株式会社PLAIDはVue Fes Japan 2023にゴールドスポンサーとして参加して、スポンサーブースの運営を行いました！

Vue Fes Japan 2023にゴールドスポンサーとして参加しました！

KARTE 管理画面のパフォーマンスの監視をするにあたって考えたことや Datadog の活用のポイント、改善で取り組んだことについて紹介します。

Datadog を使った KARTE 管理画面パフォーマンス改善の取り組み

<p>エンジニアの mizchi です。本記事は plaid advent calendar の 8日目になります。</p>
<p>フロントエンドに携わる人なら、フロントエンド開発にまつわるものは、ブラウザの中で開発が完結するはずだ、と考えたことがないでしょうか。僕は個人的にブラウザ上で開発が完結すべきであって、技術的にも不可能ではない、と思っています。これは開発環境と実行環境が同じであるべきという <a href="https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A9%E3%83%B3%E3%83%BB%E3%82%B1%E3%82%A4">アラン・ケイ</a> の Smalltalk と同じ発想です。</p>
<p>筆者はブラウザ上で Git/GitHub の操作ができる <a href="https://nedi.app/">https://nedi.app/</a> というエディタを作成したり、そこから markdown のプレビューだけを高速化したり <a href="https://mdbuf.netlify.com/">https://mdbuf.netlify.com/</a> というMarkdown プレビューツールを作ったり、最近は <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a> (名前はまだない)という開発ツールを趣味半分仕事半分で作っています。PWA、オフラインキャッシュ、 WebWorker、node ツールチェインが発達した今なら、これが可能なのではないか？ ということで、その環境を試作した話です。</p>
<h2>ゴール: フロントエンドでフロントエンドをビルドする</h2>
<p>ブラウザ上でフロントエンドが開発できると、何が嬉しいでしょうか。まず、ブラウザさえあればよいので、開発構築が容易になります。特にプログラミング教育では、いかに最初の一歩を踏ませるかが大事で、その上で視覚的なインパクトが伴うフロントエンドや、ゲームエンジンは特に入門向きだと思っています。(HTML/JS/CSS が入門向けの環境かどうかは、Web 開発以外の観点で議論の余地があると思いますが…)</p>
<p>また、開発者向けの実用的な側面でも、現代の GUI の開発は、ビルドに伴うファイル転送とプレビューなどの必要で発生している各種 IO への負荷が大きい問題を解決できる可能性があります。今までは書き出すしかなかったメモリ上の中間状態を引っこ抜いたり、プロセス的な距離が近くなるので開発ツールの効率を考え直したり、そのための差分検知のあり方が大きく変わるはずです。</p>
<p>ツールとプレビューがセットになった環境があると、動かせるコードのシェアが容易になります。ReactNative の開発者ならば、 <a href="https://snack.expo.io/">https://snack.expo.io/</a> で簡単なコードのシェアをしたことがあるのではないでしょうか。</p>
<p>というわけで、フロントエンドでフロントエンドをビルドする、またはその開発ツールについて考えると、次のテーマが浮かび上がってきます。</p>
<ul>
<li>永続層: ファイルシステム</li>
<li>ツールチェインの解決</li>
<li>ネイティブプラグイン</li>
<li>エディタ</li>
</ul>
<h2>永続層: ファイルシステム</h2>
<p>現実には永続化とファイルストレージの問題があります。手軽な永続層として使われる localStorage は単なる KVS、しかも同期ブロッキングな API なので、プログラミングで大量のデータを扱うには不向きで、 IndexedDb は非同期で高速ですが、 <strong>ホスト OS の空き容量サイズが一定値を下回ると消える可能性がある</strong> という挙動で実装されてあることが多く、現実に発動することは稀ですが、大容量を扱う可能性があるものとしては、完璧に信頼できるストレージではありません。</p>
<p>仮想ファイルシステムは、一旦は揮発する開発環境として扱う、という従来のブラウザツールによくあるポリシーを採用するのは不可能ではないのですが、 2019 年現在、 <a href="https://wicg.github.io/native-file-system/">Native File System</a> という API が提案され、Chrome で開発者フラグを建てると使うことができます。これに活路が見いだせるかも？と期待しています。</p>
<p>これは、限定的なホスト環境へのファイル読み書き機能です。この機能を使って、一旦はブラウザストレージに書き込んだものを、単一ファイルへの内部状態の書き出しを実装すれば、非効率とはいえ、ホスト環境のディスクへの永続化が可能です。まだ試していないですが、簡易なファイルソケットとして実装すれば、双方向の RPC も実装できるかもしれません。(となるとブラウザ単独で完結するという旨味もなくなるんですけどね…)</p>
<p>Native FileSystem 現在は単体ファイルの Read or Write, またはディレクトリの Read のパーミッションしかないのですが、 単体ファイルへの Read &amp; Write や、ディレクトリへの Read &amp; Write パーミッションがあると、使い勝手の良いブラウザ開発環境のストレージが実装できる可能性があります。</p>
<p>とはいえ、歴史的にはブラウザからのファイルシステムへのアクセスは、 ActiveX 経由の悪意あるディスクトラバースとして悪用された過去があるので、セキュリティ的に危険な機能です。慎重に議論されて実装される必要があるとは思っています。</p>
<p>参考:</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria">ブラウザーのストレージ制限と削除基準 - Web API | MDN</a></li>
<li><a href="https://www.html5rocks.com/ja/tutorials/offline/quota-research/#toc-chrome">モダンブラウザのストレージ容量と調査方法まとめ - HTML5 Rocks</a></li>
<li><a href="https://mizchi.hatenablog.com/entry/2019/09/08/090057">Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする - mizchi's blog</a></li>
</ul>
<h2>プリプロセス | バンドリングの課題</h2>
<p>永続ストレージ問題は(問題はあるものの)解決されたとして、次に立ちふさがるのは現代のフロントエンドツールチェインです。</p>
<p>node.js 向けのツールチェインは、古くから isomorhic や universal javascript という概念があるのですが、多くはブラウザ向けに動くように調整された shim と一緒にビルドすることが可能です。</p>
<p><a href="https://qiita.com/kyrieleison/items/4ac5bcc331aee6394440">Universal / Isomorphic JavaScript について - Qiita</a></p>
<p>しかし、ここに標準ライブラリの net や fs といったモジュールを使うと話がややこしくなります。素朴な http 通信に限ったとしても、ブラウザはアクセス先に CORS の制約を受けます。このため、特にプロキシなどを用意しない場合、 CDN ぐらいしかアクセスできません。こうなると npm から tar.gz を落とす、といった、npm/yarn のツールチェインの入り口が閉じられてしまいます。</p>
<p>fs もブラウザ環境での永続層を想定しない結果として、 fs のよく使われるポリフィルは存在しません。一応、 <a href="https://github.com/jvilk/BrowserFS">https://github.com/jvilk/BrowserFS</a> という IndexedDb をバックエンドにできるツールがあるのですが、あまり現代的ではない古い設計なのと、素朴な read &amp; write を行うだけで、シーケンシャルなファイルアクセスができず、とても遅いです。</p>
<p>この結果、 React や Vue のような、フレームワークのランタイムは比較的に簡単に扱うことが可能なのですが、ブラウザでパースできない JSX や Vue SFC を扱うためのツールチェインをブラウザ側にもってくるのが、ひと手間かかります。具体的には、ユニバーサル性を謳うどのツールも、ツールチェインの依存のどこかで fs を無意識に依存のどこかで含んでいて、それらをモック化しつつビルドするのは、一手間かかります。</p>
<p>ライブラリのコアがブラウザでも動くことを謳いながら、ツールチェインのどこかで Isomorphism が失われるのは他の環境でもよく発生します。例えば eslint のプラグイン や textlint のプラグインは、外部ファイル参照の解決に fs を使いに行くものが多いので、ここをなんらかのインメモリキャッシュに差し替えたりしなければなりません。逆に言うと、それさえすれば動くものも多いです。</p>
<h2>解決策: CDN</h2>
<p>Proxy を設置しない場合、 CDN でフロントエンドのツールを引っ張ってくる必要があるのですが、幸いなことに便利な CDN がいくつかあります。</p>
<ul>
<li><a href="https://www.jsdelivr.com/">https://www.jsdelivr.com/</a> npm のファイルへの CDN</li>
<li><a href="https://unpkg.com/">https://unpkg.com/</a> npm へのファイルへの commonjs でビルドしたものを返してくれる CDN</li>
<li><a href="https://www.pika.dev/cdn">https://www.pika.dev/cdn</a> npm へのファイルのうち、 package.module で ESM でビルドしたものを返してくれる CDN</li>
</ul>
<p>内部パスやカスタムローダーで特殊なファイルを解決する際は jsdelivr, module が指定されていたら pika.dev, それ以外は unpkg などの使い分けすると効率よく引っ張ってこれそうです。 npm は unpublish が特別な場合を除いてできないので、一度引っ張ってきたらローカルキャッシュに入れてしまっても構わないはず。</p>
<h2>ネイティブプラグインの問題: WebAssembly は使えるか?</h2>
<p>フロントエンドでフロントエンドを開発しようとすると次に問題になるのはネイティブプラグインです。有名所で、 node-sass などが C で書かれた libsass でコンパイルされたプラグインですね。</p>
<p>現代のフロントエンドは、 その為の開発ツールは基本的に JS で書かれてはいるのですが、またそうではないものも wasm で提供されるようになりはじめています。例えば <a href="https://github.com/kkos/oniguruma">正規表現エンジンの oniguruma</a> は Atom などで使われ、Sublime や Atom や VSCode で連綿と引き継がれてきた使われる共通の TextMate 仕様のコードハイライト定義で使われていたのですが、これが <a href="https://github.com/NeekSandhu/onigasm">NeekSandhu/onigasm: Oniguruma regex library on the web using WebAssembly</a> という wasm 版 oniguruma が提供されるようになったことで、 VSCode Online のウェブ版のビルドが実現されています。</p>
<p>とはいえビルドサイズが膨らむことが多く、PWA のオフラインキャッシュと組み合わせてロード時間を短縮する必要があったりします。</p>
<p>wasm のパッケージを登録できる <a href="https://wapm.io/">https://wapm.io/</a> を眺めていると、想像していたより幅広いツールが日々ビルドされています。(使い物になるかはともかく…)</p>
<p>最近登録されたものを見てると、 wasi でファイルシステムが触れるようになったのが大きいですね。jq の wasm ビルドがあったり、極端なものだと、 wasm でビルドされた python があったりします。</p>
<ul>
<li><a href="https://wasi.dev/">WASI |</a></li>
<li><a href="https://wapm.io/package/jq">https://wapm.io/package/jq</a></li>
<li><a href="https://wapm.io/package/python">https://wapm.io/package/python</a></li>
</ul>
<p>とはいえ wasi も結局ブラウザで使うにはモックかインメモリキャッシュに差し替える必要があるので、これらはだいぶ辛そう…</p>
<h2>というわけで、作ってみた</h2>
<p>決めたこと</p>
<ul>
<li>超巨大ファイルストレージは扱わない(超巨大ファイルを扱うための git 組み込みもしない)</li>
<li>FS も複雑なものを扱わない想定でフラットに展開する</li>
<li>ブラウザ上で動く rollup コンパイラでインメモリに展開し、ライブラリは CDN から引く</li>
<li>エディタは vscode で実績がある monaco-editor で、 TypeScript を編集してフロントエンドのコードをプレビューする、という単目的なツール</li>
</ul>
<p>できたのがこれ</p>
<p>URL: <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/70c48f8c-2a80-4900-a271-91adcc5f78bf/b4d3778564f04badf9b6562a331b256a.png" alt=""></p>
<p>ソースコード <a href="https://github.com/mizchi/bundle-on-browser">https://github.com/mizchi/bundle-on-browser</a></p>
<p>注意: 読み込みが遅いしバギーです。リロードで動かなかったりしたら、 DevTool &gt; Application &gt; Clear Site Data でキャッシュを破棄してください。</p>
<p>ドラッグアンドドロップできる可変レイアウトは <a href="https://github.com/mizchi/react-unite">https://github.com/mizchi/react-unite</a> という昔作った Unity 風のレイアウトシステムを引っ張り出しました。タブが他のペーンに移動できたりして楽しいと思います。</p>
<p>lodash, preact, react, vue, svelte で動作確認をしています。(workspace タブの preset を見てみてください)</p>
<p>CDN の一回目の読み込みは遅いですが、二回目以降はキャッシュされて早いです。これによって、ブラウザ上でバンドルしてるにも関わらず、十分高速なプレビューが実現できています。</p>
<p>NativeFileSysetem が有効になっているならば、 Cmd+S で現在のファイルシステムのダンプを示す json を保存でき、Cmd+O でそれを読み込むことができます。</p>
<h2>ブラウザ上のコンパイラの実装について</h2>
<p><a href="https://github.com/mizchi/web-compiler">https://github.com/mizchi/web-compiler</a> では、 ブラウザ上で動く rollup に、以下の機能を組み込んで、それ自体がブラウザで動くようにバンドラをコンパイルしました（ややこしい）</p>
<ul>
<li>ESM のバンドル</li>
<li>typescript の読み込み(tsx の解決)</li>
<li>npm のバージョンの解決</li>
<li>CDN からのファイル実体の解決</li>
<li>svelte の読み込み(なんとなく)</li>
<li>terser による minify</li>
</ul>
<p>その結果、4MB あって読み込みが重くなってしまったのですが、ブラウザでもサーバーでも、<code>npm install @mizchi/web-compiler</code> で次のコードが動くようになりました。</p>
<pre><code class="language-js">import { compile } from &quot;@mizchi/web-compiler&quot;;
const pkg = {
  dependencies: {
    &quot;lodash.flatten&quot;: &quot;*&quot;
  }
};

const code = `export default 1`;
const out = await compile({
  entry: &quot;/index.js&quot;,
  files: {
    &quot;/index.js&quot;: code
  },
  pkg,
  tsConfig: `{
    compilerOptions: {
      target: &quot;es5&quot;
    }
  }`
});
console.log(out);
</code></pre>
<p>ファイルシステム上の絶対パスと、そのエントリーと、解決すべきパッケージの dependencies が書かれた package.json と、その tsconfig.json です。これらを仮想 FS として、足りないものは CDN から引いています。</p>
<p>rollup のプラグインの規約がとてもわかり易いので、ハックしやすかったです。 <code>rollup(...).generate()</code> はブラウザ環境で動くことを知っていれば、あとは何でもできると思います。</p>
<h2>エディタ</h2>
<p>VSCode で使われてる monaco-editor を使っています。</p>
<p><a href="https://github.com/microsoft/monaco-editor">https://github.com/microsoft/monaco-editor</a></p>
<p>VSCode は electron(node) への依存が極力切り離されているので、ブラウザで起動可能なビルドが作れます。(<a href="https://github.com/microsoft/vscode/blob/master/scripts/code-web.js">https://github.com/microsoft/vscode/blob/master/scripts/code-web.js</a> を参照)</p>
<p>試してみたところ、永続層が実装されていないのでインメモリで揮発してしまうのですが、ここを実装すると任意のバックエンドの VSCode が作れそうでした。</p>
<p>ここまでわかったので、さらに VSCode をハックして monaco 上で TypeScript の設定を読んだり、仮想 FS 上で TS の補完を扱ったりできたり、といったものを実装したのですが、それについては別途 12/9 の ginza.js で話す予定です。</p>
<p><a href="https://ginzajs.connpass.com/event/154596/">Ginza.js#7 - connpass</a></p>
<h2>未来</h2>
<p>現状、フロントエンド開発すべてを Web に移す、といったことはまだ無理ですが、用途を絞れば、たとえば用途特化のオーサリング環境や学習用の開発環境などとしては十分実用的なものが作れると思います。</p>
<p>PWA によってオフラインツールが作りやすくなった今、みなさんも思い思いのエディタを自作してみてはいかがでしょうか。以上、フロントエンドでフロントエンドをビルドする話でした。</p>


フロントエンドでフロントエンドをビルドする

<p>こんにちは、monoi &amp; komukomo &amp; tik-sonです。<br>
11/18-11/21にかけてサンディエゴで開催された <a href="https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/">KubeCon + CloudNativeCon North America 2019</a>に参加してきたので、その様子をご紹介したいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a7eaaca0-b5f9-470d-ae8d-2235c892f22a/image--5-.png" alt="image--5-"><br>
サンディエゴの景色。めちゃくちゃ過ごしやすい気候でした。</p>
<h2>Anthos Day</h2>
<p>メインカンファレンス前日のDay Zeroには、様々な企業がイベントを開催していました。<br>
私たちはその中でAnthos Dayに参加しました。</p>
<p><a href="https://cloud.google.com/anthos">Anthos</a>はGoogle Cloudが開発しているプラットフォームで、特定のクラウドに依存しないアプリケーション開発・実行環境を提供しています。<br>
例えば<a href="https://cloud.google.com/kubernetes-engine">GKE</a>をオンプレミスで動かすサービスなどを提供しています。</p>
<p>&quot;Anthos Day&quot;と言いつつも意外とGKE本体についてのアップデートの発表もあり、GKEユーザーである私たちに有意義な内容が多かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/04915593-5d9b-476e-95c0-7f84dc02b3f1/image--6-.png" alt="image--6-"><br>
Anthos Dayでのセッション</p>
<h2>日本人交流会</h2>
<p>Day Zeroの夜には<a href="https://kubecon-jp.connpass.com/event/145278/">日本人交流会</a>が開催されました。<br>
一昨年は30人程度だった参加者も今年は150人ほどまで増えたようで、ここからもKubernetesの盛り上がりが感じられました。</p>
<p>Kubernetesの知見を持った多くの方と情報交換ができ、また日本に帰ってからも継続できる繋がりを作ることができたのは非常に良かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/02e6efd5-5802-438b-b5fb-5ae77ceb1c05/image--7-.png" alt="image--7-"></p>
<h2>Kubecon開幕</h2>
<p>今年のKubeconには1万人以上が参加していたようで、会場は熱気に包まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b5d72ae-a5a4-4e4f-b29f-69b6c058e7e0/image--8-.png" alt="image--8-"></p>
<p>Kubernetesのユーザーというより、Kubernetesシステムまわりの開発者やプラットフォーム提供者によるセッションが多かったです。<br>
データベースやログ・監視系、セキュリティやサービスメッシュなどをはじめとした、あらゆる分野のプレイヤーがKubernetesエコシステムに参加しており、Kubernetesの柔軟性や拡張性の高さを感じるとともに、エコシステムの広げ方のうまさも改めて感じました。</p>
<p>意外なところでは、米国では金融機関や政府もKubernetesやCI/CDのオートメーションなどを活用したモダンなアーキテクチャを構築している事例も発表されてました。<br>
また、オンプレミスで運用している事例も多かったことも驚きました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ace13e0-de61-491f-9b1b-f4091d3d1ace/image--9-.png" alt="image--9-"><br>
会場には卓球台やレトロなゲームマシンもありました</p>
<h2>Anthos / GKEのPMとのミーティング</h2>
<p>Anthos / GKEの機能に関するフィードバックや、高速にスケールアウトすることが求められるKARTEにおいてKubernetesをどのように使うべきかなどに関してディスカッションしました。<br>
アーキテクチャの構成に関する事例や内部仕様、自分たちが気づいていなかった他機能との連携など、公式ドキュメントを見るだけでは得にくいような情報も得ることができ大変有意義でした。</p>
<p>ミーティング後には、<a href="/google-cloud-next-tokyo-19/">毎度恒例</a>のPLAIDオリジナルの漢字Tシャツをプレゼントし喜んでいただけました。（笑）</p>
<h2>まとめ</h2>
<p>KubeConに参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。<br>
セッションの内容自体はWebで公開されているものが多いですが、どのようなセッションが人気で何に対して盛り上がっているのかを体感したり、実際に開発者やユーザと交流したりできたため、多少コストは高め（フライト時間は往復で約1日..!）ですが、意味のある時間を過ごすことができたかと思います。機会があればまた参加したいと思います。</p>
<h2>最後に</h2>
<p>PLAIDではKubernetesなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135">こちら</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>


KubeCon in San Diegoに参加してきました！

KubeCon in San Diegoに参加してきました！ | PLAID engineer blog

Our seeking to stable k8s deployment.

<p><a href="https://qiita.com/advent-calendar/2019/plaid">PLAID Advent Calendar 2019</a> 3日目担当の <a href="https://twitter.com/algas">@algas</a> です。今年は量子コンピュータを個人的に勉強しています。最近では量子スプレマシーが話題になりましたね。会社の業務では量子コンピュータを直接使っているわけではないので今のところは完全に個人の趣味です。ソフトエンジニアとして生きていれば遠くない将来に業務で量子コンピュータを使うこともあると思っています。</p>
<h2>概要</h2>
<p>本記事では Google の論文 <a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a> の中で使われている技術とそれが必要な背景を解説したいと思います。論文自体の内容に関する考察までは本記事では扱いません。論文の概要は <a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">Google AI Blog &quot;Improving Quantum Computation with Classical Machine Learning&quot;</a> でも紹介されています。</p>
<h2>対象読者</h2>
<p>量子コンピュータや機械学習に多少の知見がある読者を対象とします。アドベントカレンダーのネタなのにそんなに軽くないです。それぞれの技術の専門家の方はぜひ元論文を読んでみてください。</p>
<h2>背景</h2>
<p>現状の量子コンピュータを使って実用的な問題を解くための主な課題として以下の3つがあります。</p>
<ol>
<li>量子ビット数が少ない<br>
量子ビットの数が多いほど高い精度の計算や多くのパターンの組み合わせの計算ができるようになります。</li>
<li>量子状態を維持できる時間が短い<br>
量子コンピュータで問題を解いている間は量子状態を維持する必要があります。<br>
量子状態を長い間維持できる方がより複雑な問題を解くことができます。</li>
<li>ノイズやエラーのために信頼性が高くない<br>
古典コンピュータではノイズの除去やエラー訂正が実用上で十分なレベルに達しています。<br>
それに比べて量子計算でのエラー訂正は簡単ではありません。量子状態を維持する時間が短いので大規模計算で訂正処理をするのが困難です。量子ビットを測定すると量子状態が壊れるので測定せずに訂正する方法が必要です。</li>
</ol>
<p>この3つ目の課題を解くのが紹介する論文の手法です。</p>
<h2>論文の解説</h2>
<h3>量子コンピュータのノイズ</h3>
<p>量子コンピュータのノイズには主に以下の２つがあります。</p>
<ol>
<li>量子ビット自体への干渉
<ul>
<li>量子コンピュータでは量子ビットに情報が保持されます。光子や音量子が量子ビットの近くを通ることによって量子力学的に干渉することがあります。</li>
<li>量子ビットの値を確定するためには「測定」する必要があります。測定の精度によって量子ビットの値が間違っていることがあります。</li>
</ul>
</li>
<li>量子ビットを制御する道具によるノイズ
<ul>
<li>量子ビットが載ってる物理基板の電気信号や電磁場によってアナログのノイズが混じってしまうことがあります。</li>
<li>熱によるホワイトノイズ以外にも、外部の電波源、DAコンバータなどもノイズの発生源になります。</li>
</ul>
</li>
</ol>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ba139dd5-672d-4e91-956e-9a5ec344c666/57f6b41cba3d6eafb00633637f064550-png.png" alt="ノイズの図"></p>
<h3>論文の概要</h3>
<p>量子コンピュータのノイズ問題を解決するために「深層強化学習を使った新しい量子制御フレームワーク」を作りました、という内容の論文です。<br>
フレームワークの応用用途には以下があります。</p>
<ul>
<li>量子シミュレーション</li>
<li>量子化学</li>
<li>量子スプレマシー</li>
</ul>
<p>量子計算中の情報の漏れがノイズの主な原因の1つです。理論的には情報の漏れを完全に予測できればノイズを改善できます。量子コンピュータ全部をシミュレーションできればこれが実現できます。しかし現実的には量子コンピュータ全部をシミュレーションするのは計算効率の問題や大規模な計算においては難しいので完全には予測できません。その代わりに物理モデルを改良することで量子計算のいくつかのパラメータを最適化してノイズを減らすことができます。</p>
<h3>論文の結論</h3>
<p>既存の手法の確率勾配降下法(SGD)よりも桁違いで良い結果が得られたそうです。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a9dac92a-2c98-4f71-afd0-e51469b438b2/fcf78285bc840c1f345fd76fdaf599b9-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 4)</p>
</blockquote>
<h3>On-Policy Trusted-region Deep Reinforcement Learning</h3>
<p>深層強化学習の図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13ee3c26-1495-4af7-8148-f4ff5f349d9e/571328050131bfec2920c9d5bb86e4e4-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 1)</p>
</blockquote>
<p>深層強化学習の技術については以下によくまとめられています。本記事と合わせてお読みください。<br>
<a href="https://qiita.com/shionhonda/items/ec05aade07b5bea78081">深層強化学習アルゴリズムまとめ</a></p>
<ul>
<li>深層学習(Deep Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/df1bac60-9d83-4662-97f3-6d069eab6166/efc3e5c080b5b8fb30e96b5fbf22c1df-png.png" alt="DeepLearning"></li>
<li>強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/436aea15-bd98-45ad-be1e-f77e2966da05/a487c561028d9bf9783570645d39d350-png.png" alt="a487c561028d9bf9783570645d39d350-png"></li>
<li>深層強化学習(Deep Reinforcement Learning)<br>
= 深層学習(Deep Learning) + 強化学習(Reinforcement Learning)<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/cc5e3a4d-9001-4d76-aa8c-31a145ad6c9d/f09e4543ebfe850c4b2daa220cb1b97b-png.png" alt="f09e4543ebfe850c4b2daa220cb1b97b-png"></li>
</ul>
<blockquote>
<p><a href="http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf">http://people.csail.mit.edu/hongzi/content/publications/DeepRM-HotNets16.pdf</a></p>
</blockquote>
<ul>
<li>Trust Region Policy Optimization<br>
論文: <a href="https://arxiv.org/pdf/1502.05477.pdf">https://arxiv.org/pdf/1502.05477.pdf</a><br>
解説記事: <a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">RL — Trust Region Policy Optimization (TRPO) Explained</a><br>
信頼できる領域内にステップを抑えることで状態の急激な悪化を防ぎます。急な勾配を崖に例えると、崖を飛び降りない手法といえます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/605a19c8-0032-4b80-ba8f-e8092362973b/----------2019-12-02-17.15.43.png" alt="崖から飛び降りない図"></li>
</ul>
<blockquote>
<p><a href="https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9">https://medium.com/@jonathan_hui/rl-trust-region-policy-optimization-trpo-explained-a6ee04eeeee9</a></p>
</blockquote>
<ul>
<li>On-Policy<br>
解説記事: <a href="https://qiita.com/ABmushi/items/83a639506fcbc4050ce8">強化学習のOn-PolicyとOff-Policy</a><br>
現在の方策(Policy)に則って(on)将来の行動が選択されることを前提に学習します。崖の近くの道が選ばれにくくなります。On-Policy とは逆に方策に依存しない Off-Policy もあります。</li>
<li>Policy Neural Network<br>
解説記事: <a href="https://towardsdatascience.com/policy-networks-vs-value-networks-in-reinforcement-learning-da2776056ad2">Policy Networks vs Value Networks in Reinforcement Learning</a><br>
現在の方策(Policy)を改善するのが目的です。行動空間が高次元でも連続でも使えます。確率論的な方策も学習できます。局所解に陥りやすく評価が非効率的であるというデメリットもあります。</li>
<li>Value Neural Network<br>
最適行動価値(Value)関数を推定するのが目的です。局所解には陥りにくいアルゴリズムもあります。行動空間が高次元の場合には計算負荷が大きくなります。</li>
<li>確率勾配降下法(Stochastic Gradient Descent Method)<br>
解説記事: <a href="https://postd.cc/optimizing-gradient-descent/">勾配降下法の最適化アルゴリズムを概観する</a><br>
目的関数を最小化する問題を解く方法の1つです。局所解に陥りにくいメリットと最適解をいつまでも得られない可能性があるデメリットを持ちます。</li>
</ul>
<h3>Quantum Unitary Gate</h3>
<p>量子回路図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/352383d0-03df-4b28-8d76-a93872a44ae8/b0028cd46b91048d89f779df10bfcdb8-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)"></p>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Fig. 2)</p>
</blockquote>
<p>量子コンピュータに知見がない方は以下も合わせてお読みください。<br>
<a href="https://www.slideshare.net/techblogyahoo/ss-138380151">ゲート方式量子コンピュータの概要</a><br>
<a href="https://en.wikipedia.org/wiki/Quantum_logic_gate">Quantum logic gate</a></p>
<ul>
<li>量子ビット(qubit)<br>
古典ビットは0か1の2つの状態しかありません。量子ビットは測定した時に初めて値が確定し、その状態によって確率的に0か1のどちらかの値になります。複数回測定するとその出現確率の状態に近づきます。
<ul>
<li>古典ビットの「0」: 0が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/89e4b213-6b8e-4c21-b5a8-6f7d3459ff2c/ket0-2.png" alt="ket0"></li>
<li>古典ビットの「1」: 1が100%測定される状態<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9a7885ef-f000-4459-8eb8-a8ed076fe6e5/ket1-2.png" alt="ket1"></li>
<li>一般的な量子1ビット<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/af71b94d-f1c5-4da3-ad69-0deefdf30da5/qubit1-2.png" alt="qubit1"></li>
<li>ブロッホ球:量子ビットの状態を仮想的に表した球<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e9594ab5-73d9-4f1d-9608-62543a689458/quantum_gates_bloch_sphere.png" alt="bloch-sphere"></li>
</ul>
</li>
<li>量子ゲート演算の基本
<ul>
<li>nビット量子ゲート演算<br>
2^n x 2^n の行列=ゲート( U )を 2^n 要素のベクトル = 量子nビットに作用させます。</li>
<li>1ビットの場合には以下の式で書けます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/35eab83e-6b2c-42f7-a79b-79edc54648f1/quantum1_u_gate.png" alt="quantum1_u_gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e7f633ef-3745-4a0e-99ac-7770757e24de/quantum1_u-1.png" alt="quantum1_u"></li>
</ul>
</li>
<li>1ビット量子ゲート
<ul>
<li>RYゲート: ブロッホ球のY軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ddc4adf9-d2b9-42cb-bc16-755dbf9dc023/ry-gate-1.png" alt="ry-gate"></li>
<li>RZゲート: ブロッホ球のZ軸の周りに位相をθだけ変化させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c0bbdf6c-6650-41e0-8a10-4ad3fe7f45ce/rz-gate-1.png" alt="rz-gate"></li>
</ul>
</li>
<li>2ビット量子ゲート
<ul>
<li>CNOT(Controlled Not)ゲート: コントロールビット(下図の上側のビット)が1の時だけターゲットビット(下図の下側のビット)の値を反転させます。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/114d84fa-5c20-4ff6-b3dc-c5b02c4c6f27/cnot-gate-1.png" alt="cnot-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/96cdff24-43c8-4f7e-bc5c-1d68d0cfea75/cnot-circuit.png" alt="cnot-circuit"></li>
<li>SWAPゲート: 2つのビットの値を交換します。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/bbd5349e-a253-429b-af9f-5791bf45754d/swap-gate-1.png" alt="swap-gate"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/ac550bb8-01b2-40be-a472-58deaf0a553f/swap-circuit.png" alt="swap-circuit"></li>
</ul>
</li>
<li>Quantum Unitary Gate
<ul>
<li>たとえば簡単のために α=π/4,γ=π/4 と仮定すると、U は以下のような演算になります。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aa05c59b-70fc-405f-86ec-409a6acf6333/ui-simple.png" alt="ui-simple"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/7bfbc15b-d980-48c1-9e5a-d03e22ef0318/rz0.png" alt="rz0"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2e4ec040-3d83-4165-a3c9-3118cb82094c/rz1.png" alt="rz1"><br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/14929f10-dc99-47ee-b8d9-02e7048c96ea/ui-result.png" alt="ui-result"><br>
SWAPゲートと一緒になります。ちょっと簡単にしすぎました。</li>
<li>論文による測定結果<br>
α を横軸にして γ=π/2,π/6,π/3 の場合の単位時間あたりのゲート実行時間を縦軸にした図です。<br>
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f72780d3-32fd-4f72-bd30-0bebabd94ce8/5dacd6723662c60dec0d909e5a2f9c6a-png.png" alt="“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)"></li>
</ul>
<blockquote>
<p>“Universal Quantum Control through Deep Reinforcement Learning” (Figure 3)</p>
</blockquote>
</li>
</ul>
<h2>本記事のまとめ</h2>
<p>量子コンピュータの直近の主な課題の1つであるノイズ問題を改善する手法を提案する論文の背景と論文内に登場する技術を紹介しました。背景の状況や要素技術が理解できると論文の内容にも興味を持てるのではないでしょうか。</p>
<h2>参考文献</h2>
<ul>
<li><a href="https://www.nature.com/articles/s41534-019-0141-3.pdf">“Universal Quantum Control through Deep Reinforcement Learning”</a></li>
<li><a href="https://ai.googleblog.com/2019/10/improving-quantum-computation-with.html">&quot;Improving Quantum Computation with Classical Machine Learning&quot;</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798159928">現場で使える! Python深層強化学習入門 強化学習と深層学習による探索と制御</a></li>
<li><a href="https://book.mynavi.jp/ec/products/detail/id=90706">つくりながら学ぶ! 深層強化学習 PyTorchによる実践プログラミング</a></li>
<li><a href="https://www.shoeisha.co.jp/book/detail/9784798157467">絵で見てわかる量子コンピュータの仕組み</a></li>
</ul>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<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>


PLAID Advent Calendar 2019 3日目 論文 “Universal Quantum Control through Deep Reinforcement Learning” の背景と要素技術の解説

深層強化学習は量子猫の夢を見るか？ | PLAID engineer blog

深層強化学習は量子猫の夢を見るか？

<p>@otolab です。</p>
<p>ITP 2.2, 2.3に関する調査を行いましたので、検証ツールの解説を行いたいと思います。</p>
<p>今回の検証では、ITP 2.2のリンク装飾（Link Decoration）されたランディングページによるcookieの保存期間短縮と、ITP 2.3で追加されたリファラへのリンク装飾に対する制限について調べています。</p>
<p>2つとも、広告流入時にIDを1st partyとして保存するようなケースを想定しており、流入元から対象サイトへの情報伝達・保存を制限するものです。</p>
<p>なお、localStorageに制限が掛かったことが2.3での変更の大きなポイントですが、制限の元となる条件は2.2のcookieと同様であるのと、localStorageの寿命を簡単に見る方法がないため今回はテストを行っていません。</p>
<p>この記事はITPについての基本的な知識がある前提で書いています。</p>
<h2>意外だったこと</h2>
<ol>
<li>リンク装飾に対する制約は2PV目以降にも引き継がれる</li>
<li>trackerドメイン上でのインタラクションによる猶予の影響は受けない</li>
<li>レスポンスヘッダによる遷移はリンク装飾とみなされない（？）</li>
</ol>
<p>詳細は後述します。</p>
<h2>ツール</h2>
<p>実験しつつ書きつつだったので、コードやテスト内容は結構場当たり的ですが……。手元では再現性のあるテストを実行できるようになったので、公開します。</p>
<ul>
<li><a href="https://github.com/otolab/itp2.3-test">検証ツール</a></li>
</ul>
<p>また、cookieの寿命(expire)をJavascriptから取得する手段がないので、適宜、Webインスペクタを開いてcookieの有効期限を確認してください。</p>
<p>mochaを使っていますが、上記の理由からタスクランナーとしてのみ使っている状態です。</p>
<h2>検証内容</h2>
<p>検証に使ったのはSafari 13.0.1と、Safari Technology Preview Release 93です。</p>
<p>テストはコンソール(<code>localhost</code>), SiteA(対象サイト、<code>1stparty.localdomain</code>), SiteB(トラッカードメイン、<code>3rdpartytestwebkit.org</code>)の3つのホストにまたがって実行します。</p>
<p>コンソールはテスト実行の起点になるページで、遷移の関係をシンプルにするために導入しました。このページからのpopupはブロックしないように設定しておいてください。</p>
<p>SiteBはSafariがテスト用に最初からトラッカードメインとして判定しているドメインです。このドメインから対象サイトへの遷移が今回の検証のテーマになります。</p>
<p><code>3rdpartytestwebkit.org</code>, <code>1stparty.localdomain</code>は/etc/hostsなどにあらかじめ127.0.0.1として登録しておいてください。ローカルホストの別名として登録された状態になります。</p>
<p>テストは条件を変えてSiteB =&gt; SiteAの遷移を繰り返しながら、cookieを設定していきます。</p>
<h3>検証手順</h3>
<ol>
<li>初期設定
<ol>
<li>SiteA, page1にアクセスして、Cookieを設定(key1, key2)</li>
</ol>
</li>
<li>リンク装飾付き遷移
<ol>
<li>SiteB, page1にアクセス<br>
metaタグによってSiteA, page2に装飾付きで遷移</li>
<li>SiteA, page2でCookieを設定(key3, key2)<br>
手動でリンクをクリックしてSiteA, page3に装飾なしで遷移</li>
<li>SiteA, page3でCookieを設定(key4, key1)</li>
</ol>
</li>
<li>リンク装飾なし、referrer装飾あり遷移
<ol>
<li>SiteB, page2にアクセス<br>
metaタグによってSiteB, page3に装飾付きで遷移</li>
<li>SiteB, page3にアクセス<br>
metaタグによってSiteA, page4に装飾なしで遷移</li>
<li>SiteA, page3でCookieを設定(key5)</li>
</ol>
</li>
<li>リンク装飾あり手動遷移
<ol>
<li>SiteB, page4にアクセス<br>
手動でリンクをクリックしてSiteA, page5に装飾付きで遷移</li>
<li>SiteA, page5でCookieを設定(key6)</li>
</ol>
</li>
</ol>
<p>Cookieはいずれも8日間で設定します。</p>
<h2>検証結果</h2>
<h3>1. 初期設定</h3>
<p>1-1でCookie(key1, key2)を保存します。</p>
<p>document.cookieにjavascriptで値を保存しているので、8日間の有効期限を設けても7日間にまで制限されます。これはITP 2.1の効果ですね。</p>
<h3>2. リンク装飾付き遷移</h3>
<p>リンク装飾されたランディングページによる制限のテスト(2-2)。および2PV目での制限の継続をチェックするテスト(2-3)です。</p>
<p>2-2では新規のkey3の寿命が1dayまで短くなることが確認できます。また、1-1で設定したkey2を上書きすると同様に寿命が縮むのが確認できます。</p>
<p>ついでにリファラの短縮が起こらないことも確認しています。ここではSiteB, page1にリンク装飾がないため、このリファラ短縮の処理は起きていません。</p>
<p>2-3のテストを見てみましょう。ここで明文化されていない現象が観測できます。SiteA, page3はランディングページではなく、SiteA内で手動でリンクを踏んだ場合の遷移です。にもかかわらず、key4, key1の寿命は1dayに制限されます。</p>
<p>「意外だったことその1」です。</p>
<p>2PV目以降で再保存することで寿命が伸ばせてしまうと効果がない。ということなのでしょう。</p>
<h3>3. リンク装飾なし、referrer装飾あり遷移</h3>
<p>ITP 2.3で追加されたリファラの短縮とリンク装飾の関係を調べます。</p>
<p>3-1, 3-2の遷移でSiteB, page3にリンク装飾を付け、そのままSiteA, page4にリンク装飾なしでランディングします。</p>
<p>すると、リファラの短縮が観測できます。また、Cookie(key5)の寿命が縮まないことも確認できました。2つは別のものとして扱われているようです。</p>
<p>また、詳細は不明なのですが、もう一度同じテストを流すとリファラの短縮が発生しないことがあります。毎回cacheを消すとリファラ短縮が安定して発生しするのですが……。バグなのか正しい挙動なのかは不明です。</p>
<h3>4. リンク装飾あり手動遷移</h3>
<p>トラッカードメイン上でのユーザインタラクションによってCookieの寿命を延長する処理があるので影響を調べましたが、リンクデコレーションの処理とは連携していないようです。</p>
<p>4-1でSiteB上でリンクをクリックした際に、ログを見るとインタラクションを検出したというログは出るようなのですが、4-2でCookieを保存すると1dayの制限がかかります。</p>
<p>今回はSiteB上でのインタラクションは影響してこないようです。広告のクリックの追跡を想定した制限のようなので、そういうものなのかもしれません。</p>
<p>「意外だったことその2」です。</p>
<h3>extra. レスポンスヘッダによるページ遷移</h3>
<p>「意外だったことその3」です。</p>
<p>テストツールのindex.jsの<a href="https://github.com/otolab/itp2.3-test/blob/e4cc3994a7e4fa74b2c40f5b8b3f5a1596e8b8e3/index.js#L16-L33">16-33行のコメントアウト</a>を外します。そうすると、SiteBでのページ遷移がmetaタグではなく、レスポンスヘッダによるリダイレクトに置き換わります。</p>
<p>この状態でテストすると、じつはリンク装飾によるCookieの寿命短縮が発生しません。テスト方法が悪いのかブラウザのバグなのかはちょっとわからないのですが……。</p>
<p>どうも、現在のページのURLとリファラのURLの比較のみでリンク装飾の制約を掛けているのではないかなと言う印象を持ちました。レスポンスヘッダによる遷移だと、referrerの値がもう一つ前のページになるんですよね。今回のテストケースだとコンソール(<code>localhost</code>)がリファラになります。</p>
<h2>まとめと感想</h2>
<p>ページ遷移の状態やキャッシュの影響を受けるらしく、挙動がなかなか安定しないため苦労しました……。</p>
<p>さて。</p>
<p>ITP 2.2, 2.3は、ランディングページにクエリ・フラグメントがつくケースすべてを対象としているために、「サイトの作り方」自体を制約して方向づけるような仕様変更であると言えます。たとえば、商品詳細ページに<code>?item=abc123</code>のようにクエリをつけて表現するサイトは、トラッカードメインとみなされたサイト上からのアクセスで、常時cookieやlocalStorageの保存に不安定さを抱えることになります。</p>
<p>今回の変更で不安定化するフェアユースの例としては、ログイン無しでのお気に入り機能などですね。実装方法を変えれば安定化は可能なので、Safariでの動作が必須ならばサイト自体に修正をいれることになるでしょう。</p>
<p>今後も機能の更新が想定されますので、注目していきたいと思います。</p>
<h2>参考</h2>
<ul>
<li><a href="https://webkit.org/blog/8828/intelligent-tracking-prevention-2-2/">Intelligent Tracking Prevention 2.2</a></li>
<li><a href="https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/">Intelligent Tracking Prevention 2.3</a></li>
</ul>
<h2>いつもの</h2>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、顧客体験をよりよくするとはどういうことなのか、Webの未来はどう在るべきか、深く考えたいというエンジニア（インターンも）を募集しています。</p>
<p>詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<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>


ITP 2.2のリンク装飾に関する制限と、ITP 2.3のリファラへのリンク装飾に対する制限について検証を行いました。検証のためのツールを作ったので解説します


ITP 2.2, 2.3の検証ツールを作ってみた | PLAID engineer blog

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js の設計地図を作成しました。設計概念の依存関係の図式化して理解し、
フロントエンド設計をモデリング起点で考えたブログです。

Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

<p>こんにちは、makinoy &amp; positiveflat &amp; tik-son &amp; nichimuです。<br>
7/30-8/1にかけて開催された Google Cloud Next Tokyo ’19に参加してきたので、その様子をご紹介したいと思います。紹介と言いつつも、Cloud Nextでのセッションの内容のシェアではなく、Cloud Next開催中にPLAID社員がどのような動きをしていたかについてシェアしたいと思います。</p>
<h2>Google PM陣とのミーティング ＠PLAIDオフイス</h2>
<p>PLAIDでは<a href="https://cloud.google.com/bigtable/?hl=ja">Cloud BigTable</a>を始め、NoSQLのデータベースを多く使っているということもあり、<a href="https://cloud.google.com/bigtable/?hl=ja">Cloud BigTable</a>、<a href="https://cloud.google.com/memorystore/?hl=ja">Memorystore</a>など、NoSQLサービスのProduct Managerの方々をPLAIDオフィスに招き、ディスカッションを行いました。<br>
このディスカッションはGoogle Cloud Next Tokyo ’19 開催前日に実施し、</p>
<ul>
<li>PLAIDでどのようにこれらのNoSQLを使っているのか/使い分けているのか</li>
<li>既存のGCPのサービスに求めることは何なのか</li>
<li>サービスの特性をより活かしたアーキテクチャとは</li>
</ul>
<p>などのテーマについて議論を行いました。<br>
限られた時間だったので議論は尽きず、続きはビデオ会議などを駆使しリモートでやっていく予定です。</p>
<p><img src="https://ik.imagekit.io/newt/tr:w-1000,h-1000,c-at_max/61b151f921640c0018173598/2841f03f-6dbb-4631-9f54-b59066eda7f0/google-cloud-next-tokyo-19.jpeg" alt="google-cloud-next-tokyo-19.jpeg"><br>
Cloud BigTable、Memorystoreなど、NoSQLサービスのProduct Managerの方々との写真</p>
<h2>Meet the Expert ＠Google Cloud Next Tokyo’19</h2>
<p>Google Cloud Next Tokyo ’19が開催されている最中も、Googleの開発者とのミーティングを行なっていました。<a href="https://cloud.google.com/bigquery/?hl=ja">BigQuery</a>、<a href="https://www.kubeflow.org/">Kubeflow</a>、<a href="https://cloud.google.com/dataflow/?hl=ja">Cloud Dataflow</a>の開発者との議論を行いました。</p>
<p>実は5月に開催された<a href="/google-cloud-next-19-in-sf/">Google Cloud Next San Francisco ’19</a>の際にも、既に我々はKARTEのアーキテクチャについてGoogleの開発者と共有した上で議論をしていました。そのため、特にBigQueryなどに関しては、それを念頭に置いた上で今後の開発に役立ちそうなトピックを中心に議論をすることができました。<br>
また、機械学習基盤についてもディスカッションを行うことができました。現在、PLAIDでは、エンドユーザーのデータを大量に保持していますが、十分に活用できているとはまだまだ言えない状況です。機械学習などの技術をKARTEにも取り入れはじめている段階で、どういったデータの流れをどう作るべきなのか、データのvalidationをどうするべきか、ということなどをKubeflowの開発者に伺えたことは非常に良かったです。短い時間ではありましたが、プロジェクトの初期の段階で開発者とディスカッションできたことは、設計に取り組む上で大きなアドバンテージとなりそうです。</p>
<p>ミーティング後には、PLAIDオリジナルの漢字Tシャツをプレゼントしました！２種類あり、「hotfix: 迅速」「analytics: 解析」が書かれています。PLAIDデザイナーが心を込めて作った甲斐もあり、喜んでいただけました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565080407452_iOS+.jpg" alt="BigQuery、Kubeflow、Cloud Dataflowの開発者との写真" title="BigQuery、Kubeflow、Cloud Dataflowの開発者との写真"><br>
BigQuery、Kubeflow、Cloud Dataflowの開発者との写真</p>
<h2>Google Cloud Billing teamとのミーティング ＠PLAIDオフイス</h2>
<p>また、Google Cloud Next Tokyo ’19 開催後にGoogle Cloud Billing Teamとミーティングを行いました。<br>
組織が大きくなる中どのようにコストを管理していくべきなのか、GCPの考え方をシェアしてもらいつつ、PLAIDの現状をお伝えし、あるべき姿についてディスカッションしました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565080391497_W8051119.jpg" alt="Google Cloud Billing Teamの皆さんとの写真" title="Google Cloud Billing Teamの皆さんとの写真"><br>
Google Cloud Billing Teamの皆さんとの写真</p>
<h2>CTO 牧野とエンジニア 竹村の登壇 ＠Google Cloud Next Tokyo’19</h2>
<p>Cloud Nextのセッションでは、エンジニアサイドからは2人登壇しました。</p>
<p>CTOの牧野からは、「秒間6万イベントの大規模リアルタイムデータを活用する機械学習基盤の実現」を発表いたしました。GCPには、<a href="https://cloud.google.com/bigquery-ml/docs/bigqueryml-intro?hl=ja">BigQuery ML</a>、<a href="https://cloud.google.com/automl-tables/?hl=ja">AutoML Tables</a>、<a href="https://cloud.google.com/ai-platform/?hl=ja">AI Platform</a>などの機械学習サービスがありますが、それらのサービスをどのように活用しているかについて発表いたしました。</p>
<p>詳細につきましては、プレスリリースをご確認ください。<br>
<a href="https://press.plaid.co.jp/data/20190801/">https://press.plaid.co.jp/data/20190801/</a></p>
<p><img src="https://paper-attachments.dropbox.com/s_B4301733157BC4E8942C126B98488C9A0747D29A0340FB43A199BCCC760D822F_1566799637362_IMG_20190801_144105.jpg" alt="PLAIDの牧野祐己" title="PLAIDの牧野祐己"><br>
PLAIDの牧野祐己</p>
<p>また、竹村からは「PLAIDがGCPを使い、続ける理由」というテーマで発表しました。<br>
GCPのTokyoRegionが出来る前から使い始め、現在も数あるクラウドサービスの中で何故ヘビーに利用し続けているのかというお話をいたしました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_495C088E061F4CCFCB2EDF25134394B291C83E750D9DE3EC3C286EBBF71A4BB4_1565181257794_IMG_20190731_192125.jpg" alt="PLAIDの竹村尚彦" title="PLAIDの竹村尚彦"><br>
PLAIDの竹村尚彦</p>
<h2>BizDev 宮原とプロダクトスペシャリスト 池上の登壇 ＠Google Cloud Next Tokyo’19</h2>
<p>また、ビジネスサイドからはPLAIDで事業開発からプロダクトマネジメント、アライアンスを担当する<a href="https://speakerdeck.com/miyashino">宮原</a>と開発から採用、技術広報を担当するプロダクトスペシャリストの池上が登壇しました。</p>
<p>「GCP をフル活用した<a href="https://karte.io/product/datahub/">「KARTE Datahub</a>」で挑む次世代のデータ活用」というテーマで、PLAIDのストラテジックパートナーである<a href="https://www.nri-digital.jp/">NRIデジタル</a>様との取り組みである、リアル接点を活用した次世代のデータ活用事例「リアル・デジタルマーケティング」を発表しました。</p>
<p>詳細につきましては、プレスリリースをご確認ください。<br>
<a href="https://press.plaid.co.jp/data/20190731/">https://press.plaid.co.jp/data/20190731/</a></p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733233501_image.png" alt="PLAIDの宮原忍" title="PLAIDの宮原忍"><br>
PLAIDの宮原忍</p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733287627_image.png" alt="NRIデジタルの倉澤様" title="NRIデジタルの倉澤様"><br>
NRIデジタルの倉澤様</p>
<p><img src="https://paper-attachments.dropbox.com/s_4728A931DD51A7808A452108583713580BBAA209584910654C1CC5512171042D_1565733408737_image.png" alt="パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）" title="パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）"><br>
パネルディスカッションの様子（NRIデジタルの萩村様、PLAIDの池上純平）</p>
<h2>PLAIDのブースについて</h2>
<p>会場では、様々なパートナー・スポンサー企業によるブース展示が行われていました。弊社PLAIDも、ブースで来場者の方に向けてKARTEの紹介をさせていただきました。開催期間を通して、多くの来場者がKARTEに興味を持ってブースに立ち寄っていただきました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566797495978_76ZdkLYET8yF0DYRIH05ig_thumb_2.jpg" alt="PLAIDブースの様子" title="PLAIDブースの様子"><br>
PLAIDブースの様子</p>
<p>今回も様々な種類のノベルティを用意して臨みました。</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660933793_image.png" alt="Google Cloud x KARTEマウンテンボトル" title="Google Cloud x KARTEマウンテンボトル"><br>
Google Cloud x KARTEマウンテンボトル</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660950286_image.png" alt="Google Cloud x KARTEノート" title="Google Cloud x KARTEノート"><br>
Google Cloud x KARTEノート</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566661102642_image.png" alt="Google Cloud x KARTEコンパクト充電器" title="Google Cloud x KARTEコンパクト充電器"><br>
Google Cloud x KARTEコンパクト充電器</p>
<p><img src="https://paper-attachments.dropbox.com/s_D4AD4C59B0D0507617124AF427CAFF94DF20ECB07B8E8B50341E21B4450C9CFD_1566660965124_image.png" alt="ハンドスピナー型 USB &amp; Lightningケーブル！" title="ハンドスピナー型 USB &amp; Lightningケーブル！"><br>
ハンドスピナー型 USB &amp; Lightningケーブル！</p>
<h2>まとめ</h2>
<p>Google Cloud Next Tokyo ’19に参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。今後も、Googleと密に連携を取りながら、KARTEとGCPの価値を高めていきます。</p>
<h2>最後に</h2>
<p>PLAIDではGCPなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135">こちら</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>


Google Cloud Next Tokyo ’19に参加してきた中で、PLAIDエンジニアがどのような動きをしていたかについてご紹介いたします！

Google Cloud Next Tokyo ’19に参加しました！ | PLAID engineer blog

Google Cloud Next Tokyo ’19に参加しました！

<p>（このブログ記事は、<a href="https://l.facebook.com/l.php?u=https%3A%2F%2Fmedium.com%2F%40aavondet%2Finterning-at-plaid-for-2-5-months-fc2d8c6a3a17%3Ffbclid%3DIwAR39SIv4MHPB4gyO1HOQvGwuXOJvLgO7bZjK-Wlgg4-XBYIrNe83owfROIs&amp;h=AT0dg2wvphvSMKOhzD03eL6-R97JyjOepJ7X8Gs43x4GyFx7EsBXRkepVPa58f-XjSTRVdiVFu-B9am-yQJzRGjyMNSaHNQ0co4kjJty2OfSq8zUfotoeCIbJ-Q0vIp5BNJ-fW3T">Interning at PLAID for 2.5 Months</a>の本人による翻訳記事です）</p>
<p>こんにちは！<br>
プレイドで5月中旬から8月までDevインターンとして働かせてもらっていたアボンデット(@arnaud_avondet)です。僕は日本育ちのハーフで、今は米国ペンシルベニア州のカーネギーメロン大学で数学を専攻している大学2年生です。大学ではCMU日本学生会や、CMUブロックチェーングループで活動をしています。プログラミングは2年前に興味を持ってPythonの学習で始め、ウェブ開発は一年ぐらいの経験を持っています。</p>
<p>今回のインターンシップはプログラマーとして初めての仕事であり、フロントを書いたり多国化対応（i18n; Internationalization）の仕事を通して色々学べました。今回は開発プロセスとプレイドの文化について振り返ってみました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3e81e6b5-f5fa-4d53-878b-8d8dccd47c77/pic1.jpeg" alt="pic1"></p>
<h1>フロントエンド</h1>
<p>JSのコードを書いて来たこの一年間、僕は色々なアニメーションのライブラリに触れたり、UI/UXの記事などを読んでフロントエンドに興味を持ちました。プレイドに来て二週間目、早速フロントエンド関連のチームのタスクをもらい、初めてのフレームワークを習う事になりました。プレイドが提供しているCXプラットフォームKARTEはVueを使っているので、それを通してコンポーネント式のフロントエンドの書き方を勉強しました。</p>
<p>僕にとってKARTEのような大きなプログラムの開発プロセスに関わるのは新しい経験でした。普段であればHTMLを早く書いて、長時間かけて下手なCSSでスタイリングをし、最後にロジックを書くという作業を毎回繰り返していました。全部に触れられる事が楽しいのは確かですが、一つ一つの段階で全力を尽くせていない感じがしました。会社での開発は一味違い、綺麗なUIをInVisionで作るデザイナー、HTMLでそれを実装するコーダー、それでロジックをJSで書く僕、とそれぞれの仕事を得意な人が担当するようになっていました。一人一人が独自のタスクに集中出来るため、より良いプロダクトが出来上がりました。その上、プレイドではタスクにより違う役割を任せてくれるので色々な得意分野を生かせるようになっていました。自分でコードする時よりも効率的な仕事が出来た気分になり、気持ち良かったです。</p>
<p>画面の組み込み作業をやっていく上で、一番重要性を感じたのがデザイナーとプログラマー関係性です。特にフロントだけを書き換えるタスクでは既存のバックエンドの資産をそのまま活用しつつ、機能の互換性や網羅性を担保するためにはコミュニケーションをうまくとる事が大切です。デザイナーとプログラマーの観点をよく活用し、直面している制限を乗り越えられる解決案を生み出すのが何よりも貴重だと思いました。<br>
アサインされた仕事の一つは、アカウント設定ページの組み込みでした。最初はどのユーザーでも何回かは使う画面を自分が担当する事に対してとても緊張していましたが、エンドユーザーと直に接する楽しみもありました。コードの動作チェックをする時、様々なユーザーの行動を予測して作業をしていくと色々な行動パターンに気づき、新しい案などが思い付いてきました。この画面の開発はやった仕事の中でも一番楽しく、ユーザーがそのページと接する事を考えると嬉しいです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/6265ca5a-3602-4872-9038-908137c49136/pic2.jpeg" alt="pic2"></p>
<h1>多国化対応（i18n）</h1>
<p>インターンを始めて3週間目に会社内で2週間に一度行われる「Dev Demo Day」に参加しました。「Dev Demo Day」とは各エンジニアチームがここ二週間でやった仕事のデモをしたりその開発に対して振り返る場でした。僕がそれぞれのチームの発表を見て一番興味を持ったチームは、多国化対応を担当するi18nチームでした。18年間日本で育ったハーフとして、僕は日本と西洋の文化や言語によく触れていて、お互いの違いや類似点を深く理解しています。これなら自分も何かを貢献できると思い、チームに入りたいと決意しました。</p>
<p>当初は多国化対応の難しさを知らず、ただ小さなリファクタリングを掛けたり、多言語のリソースファイルを用意するだけだと思っていました。プラグインはvue-i18nを使い、簡単に通貨のフォーマットや言語を変換出来るようになっていました。そのライブラリを作った@kazuponさんも同じチームで一緒に作業をしていて、多国化対応のどんなチャレンジも乗り越えられる自信がありました。ですが、チームに入ってから数日後、早くも先の道のりが思ったより長く見えてきました。</p>
<p>i18nをやってきた上で一番印象に残ったのが、特定の言語や文化のUIへの影響でした。チームとしてよく見かけたのが日本人のユーザーを意識して作られていた画面で多国化対応には難しいものがたくさんありました。その中でも一番困難だったのが日本語の文の構造を中心としたデザインであり、そういう場合には簡単なリファクタリングだけでは綺麗に対応出来ず、デザイン自体を再検討する必要がありました。</p>
<p>このようなチャレンジと向き合い始め、僕は色々なグローバルなウェブサイトはどうやって効率的に多国化対応をしているか気になって調べた結果、一つの会社が僕にとって際立っていました。Githubは世界中で使われているサイトでもありますが、驚いた事に言語のサポートは英語しかないのです。UIをより顕密に見るとラベルのほとんどがユーザー側でインプットされたものが表示されていて、そのためユーザーのネイティブ言語になっています。その他の細かいタブなどは「issue」や「pull request」のように短くて簡単に覚えられる単語を使用しているため、英語が流暢でなくても慣れやすくなっています。Githubのコア部分には英語の長くて難しい文章がないため、誰でも使えるようになっています。</p>
<p>Githubを例とし、i18nの作業でできるだけユニヴァーサルな表記法を使うようにしました。例えば「9時30分」とUIに書いてあるものを「9:30」にしたり、どこの国の人でも理解できるように気を使いました。今だとこういう細かい修正は小さく感じますが、将来的にグローバル化したいソフトウェアとしては長い目で見ると今から標準的に対応する必要があります。</p>
<p>多国化対応をソフトウェアエンジニアリングの観点から考えたことがなかったですが、プレイドのi18nチームと共に活動をした結果、グローバル化する企業にとってはとても重要な要因であることに気付きました。国際化はラベルを一旦全部翻訳して一度きりで終わるものではなく、開発フローを修正したり、品質チェックを導入し管理する動的なプロセスだと分かりました。KARTEのi18nで直面した様々な困難を考えるとさらに大きいソフトウェアの多国化対応の難しさが想像できないです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/100bb83d-e75c-48e5-bf6c-a3b55afad2b5/pic3.jpeg" alt="pic3"></p>
<h1>プレイドの文化</h1>
<p>この2ヶ月半で一番印象に残ったのがプレイドのカルチャーでした。インターンとして僕は小さいissueや面倒なデバッグをすると想像していました。実際には2週間目にはもう新しい画面の組み込みタスクを渡され、3週間目には正社員と一緒のエンジニアチームに入れさせてもらいました。色々なミーティングに参加したり、他の社員と協力したりと没入的な経験が得られました。</p>
<p>プレイドがインターンにとって最高な会社である一番の理由としては会社のフラットな構造がある事だと思いました。僕は他のエンジニアと一緒のように扱われ、自分の意見や提案を悩まずに言える環境で仕事ができました。入社した当時、フロントへの興味を少し表しただけですぐに画面の組み込み作業をくれました。僕が助けられるi18n関連のタスクがあるか聞いてみたらチームに加入させてもらい、席もチームの横で作業出来るように動かしてもらいました。フロントとi18nに手をつけ始め、画面の組み込みと一緒に多国化対応もしていく提案をしたらそれも受け止めてくれて、二つのチームと一緒に同時に作業を進められるようにしてくれました。</p>
<p>時にはこのフラットな構造の問題点にも気づきました。場合によってはチーム同士のコミュケーションが良くとれていなく、具体的に他のチームがソフトウェアのどこの部分の作業をしているのかがはっきりしていなかったです。i18nチームとしては近い将来に使われないコードを対応しないように新しく作られる画面や機能などについて知っておきたいところですが、それでも時々もったいない仕事をしてしまいました。このようなコミュニケーションのずれを防ぐためにプレイドのエンジニア部門も2週間に一回は最近やっている仕事について発表する「Dev Demo Day」があります。それでも、これは任意であり、発表をしても5分間のデモだけで重要な点を見逃してしまう事がよくありました。このミーティングはきちんとした構造がないため、ポテンシャルを最大限に発揮できていない感じはしましたが、コミュニケーションを良くする一歩としてはとてもいいと思いました。長所や短所関係なく、僕はプレイドのような日本にとってはユニークに動いている会社の一部として働けた事に感謝しています。</p>
<p>ベンチャー企業であるため、プレイドの開発速度はとても速かったです。週ごとにリリースされる新しい機能の数が見事で、自分の書いたコードが短時間で使われる事に満足ができ、終わった仕事に対しての価値観が強く感じられるのが好きでした。僕はすぐにこのペースに慣れて、いつの間にか好きになってしまいました。特にいつもやる事がたくさんあったため、自分でも次にやるタスクが簡単に見つけられ、退屈であった一日はなかったです。タスクを選択する事で自分の能力にあった仕事、もしくは一番良いチャレンジになる仕事を選ぶ事ができました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/31d10c97-c2c4-4fd2-abe1-61ffaa63c4ba/pic4.jpeg" alt="pic4"></p>
<h1>最後に</h1>
<p>当初インターンを始めた時、2ヶ月半は長い期間だと考えていましたが働くほどすぐに時間がたってしまいました。自分を「プログラマー」と呼ぶことができるかどうかわからない状態から、どこのエンジニアチームでも自分の能力を発揮できる自信を持てるようになりました。インターンシップならではの経験を得ながら、会社のために何かを貢献できて嬉しいです。短い時間であっても、プレイドでのインターンシップは僕にとって素晴らしい経験であり、これからの会社の進歩を見るのがとても楽しみです！</p>


こんにちは！プレイドで5月中旬から8月までDevインターンとして働かせてもらっていたアボンデット(@arnaud_avondet)です。今回のインターンシップはプログラマーとして初めての仕事であり、フロントを書いたり多国化対応(i18n)の仕事を通して色々学べました。今回は開発プロセスとプレイドの文化について振り返ってみました。

プレイドでのインターンを振り返って | PLAID engineer blog

プレイドでのインターンを振り返って

<p>最近またpokemon goをやり始めた kataigi です。</p>
<p>プレイドで開発しているKARTEはユーザーのアクセス情報を分析するサービスの一種です。KARTE以外にも、Google AnalyticsやAdobe SiteCatalystなどユーザーのアクセス情報を分析するサービスは多くあり、使ったことある人も多いでしょう。ただ、そんなサービスでもどんな方法でデータを取得・トラッキングしているか知らないと、データの正しい意味がわからず、使いこなすことは難しいかと思います。ここではそんな分析の前提となるデータのトラッキングの方法をざっくりまとめてみました。</p>
<p>トラッキングの方法には様々な種類があります。どんな状況でも正確にデータが取れる方法というのはないため、それぞれの方法の特徴を知った上で、環境とデータに合わせて使い分けるのが大事です。今回は、ページやコンテンツの表示回数を測るインプレッショントラッキングと、クリック回数を測るトラッキングについて詳しくみてみたいと思います。</p>
<h1>インプレッショントラッキング</h1>
<p>一つ目は表示回数のトラッキングです。ページが表示される時はページビューですが、例えば商品レコメンドなどでは、同じページでも表示される商品情報が変わるなど、ページ閲覧回数とコンテンツ表示回数は異なってくるため、コンテンツの表示回数も計測したい場合は、より一般的にインプレッション（露出回数）という用語が使われます。トラッキング技術としてはページビューはインプレッションに含まれるので、ここでは合わせてインプレッショントラッキングとします。</p>
<p>基本的にはページ/コンテンツが表示された回数を測ることになります。コンテンツが自分の管理下にあるか、計測タイミングがコンテンツ表示前か後か、というあたりで使う技術が変わってきます。</p>
<h2>アクセスログ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/e665a42d-9f4a-413f-a96b-57b0556d838a/image1.png" alt="image1"></p>
<p>一番シンプルな方法は、サーバ自体のアクセスログを使う方法です。コンテンツを表示する時のブラウザからのアクセスをサーバ上でログに残しておく方式になります。原理的に、コンテンツ配信サーバ自体を自社で管理していないと計測できません。</p>
<h3>メリット</h3>
<p>概ねどのサーバでもアクセスログは出力されるため、準備不要で計測でき、最も手軽。</p>
<h3>デメリット</h3>
<p>アクセスログを計測するため、自社管理対象のサーバしかカウントできない。<br>
アクセスがあった ≠ 表示されたではない（ブラウザで描画される前に離脱してるかも）ので、計測値は真の値より多くなる。</p>
<h2>ピクセル（ビーコン）</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c5b88637-a42c-45e5-a16c-e88980ba3ff4/image2.png" alt="image2"></p>
<p>２つ目はピクセルトラッキングとかビーコントラッキングと呼ばれる方法です。この方法は、ページやコンテンツと一緒に極小の画像（ピクセル）を読み込ませ、その画像へのアクセスを計測する方法になります。読み込ませる画像は自社のサーバ外に置いても良いため、多くのアクセス解析システムで用いられている方法です。</p>
<h3>メリット</h3>
<p>自社管理外のサーバでもカウント可能。<br>
HTMLメールなど、配信されるコンテンツでも計測可能。</p>
<h3>デメリット</h3>
<p>コンテンツが表示されても即離脱するとカウントされないため、滞在時間が短いなど一部指標の計測が難しい。<br>
メーラーなどのJavaScriptが使えない環境だと、ピクセルが描画されてしまい、コンテンツが崩れる可能性がある。</p>
<h2>スクリプト</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a34d47fb-e4e9-4951-8c6e-01212b8c21f9/image3.png" alt="image3"></p>
<p>ピクセルトラッキングでは画像にアクセスしていましたが、実際は画像ではなくても特定のURLにアクセスさえしてくれれば同じことが実現できます。そのためページやコンテンツの表示に合わせてJavaScriptで計測用のURLへアクセスする方法も取られます。<br>
JavaScriptを使用できるため、好きなタイミングで計測できるようになります。例えば、滞在10秒後・20秒後・30秒後…にトラッキングして滞在時間を計測したり、ページのスクロール率100%のタイミングでトラッキングして、ページの読了率を計測したりもできます。<br>
IAB（ <a href="https://www.iab.com/guidelines/iab-measurement-guidelines/">https://www.iab.com/guidelines/iab-measurement-guidelines/</a> ）が提示しているような、厳密な計測（コンテンツが50%以上表示されていること、など）を行う場合は、JavaScriptによるタイミングの制御が必須となってくるため、必然的にこの方法が用いられます。</p>
<h3>メリット</h3>
<p>ページの50%以上読み込んだらなど、集計タイミングを柔軟に作れる。</p>
<h3>デメリット</h3>
<p>JavaScriptが必須なため、メーラーなどJavaScriptの実行を制限された環境だと使えない。</p>
<h1>クリックトラッキング</h1>
<p>続いてはクリックトラッキングについてです。ページやコンテンツの効果を測りたい場合、インプレッション数に加えて、実際にコンテンツをクリックした回数を計測することが必要になります。その時のクリックの計測方法も複数あります。</p>
<h2>リダイレクタ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/367fa81d-167f-48cc-9909-5280545f3d42/image4.png" alt="image4"></p>
<p>クリックした時に目的のページへすぐに遷移せず、一旦別のサーバを挟む計測方法です。httpのstatus code 302を活用します。リンクをクリックした時に一旦リダイレクトサーバにアクセスし、そのクリック情報を記録したのち、ブラウザのstaus code 302のリダイレクト機能を使って目的のサーバへ遷移させる方法です。<br>
短縮URLと呼ばれる機能とほぼ同じ動きをするため、合わせて実装されていることが多い印象です。</p>
<h3>メリット</h3>
<p>一般的なWebの仕組みに乗っているので、だいたいどこでも動く。</p>
<h3>デメリット</h3>
<p>余計な遷移を挟むため、ページ遷移が少し遅くなる。</p>
<h2>イベントハンドラ</h2>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9cf48347-7b15-49b5-9b3c-a15583995563/image5.png" alt="image5"></p>
<p>２つ目はリンクのclickのイベントハンドラを使う方法です。JavaScriptを使うことで、リンククリック時の処理(onclickなど）に介入して、ページ遷移をする前にアクセス情報を記録用のサーバへ飛ばす方法になります。クリック情報記録用のアクセスとページ遷移を非同期に行えるようになるので、前述のリダイレクトのような不要なページ遷移をせずに実行できます。</p>
<h3>メリット</h3>
<p>余計なページ遷移を発生させないで済む。</p>
<h3>デメリット</h3>
<p>別途clickハンドラが設定されているとかち合うことがある。<br>
JavaScriptが使えない環境では動かない。</p>
<h1>まとめ</h1>
<p>アクセス情報やクリック情報を計測するための技術を駆け足で見てきました。複数の計測の仕組みを作るのは大変ですが、正確な計測を行うためには環境に応じて技術を使い分ける必要があります。環境と計測内容から適切な計測方法を探し出してみてください。</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<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>


ウェブ上でのデータを解析する前に、まずはデータを正しく計測したい！ユーザーのインプレッションとクリックのイベントを収集する方法をまとめました。

計測したいものに合わせてイベントトラッキングをする方法 | PLAID engineer blog

計測したいものに合わせてイベントトラッキングをする方法

<p>こんにちは！エンジニアの@g0eです。4月1日にPLAIDに入社して、約4ヶ月が経過しました。<br>
まだまだ勉強することだらけですが、ようやくKARTEの開発環境にも慣れてきました。</p>
<p>本記事ではプレイドエンジニアの組織文化について、入社4ヶ月目のフレッシュな目線で書いてみようと思います。<br>
転職活動中でプレイドに興味がある、KARTEというプロダクトの裏にあるエンジニア文化に興味ある、といった人にとってなにかの参考になれば、と思います。</p>
<p>入社直後にも<a href="https://blog.plaid.co.jp/n/nc8cabf281d1e">この記事</a>でもプレイドという組織について少し話をさせてもらっているので、もし興味がある方はこちらも合わせて読んでみて頂けると嬉しいです。</p>
<h2>プロダクトファースト</h2>
<p>プレイドでは<a href="https://karte.io/">KARTE</a>というマーケティングツールの開発を行っています。自分が転職活動をする時にまず第一条件としてあげていたのが、自社開発の強いプロダクトを持っているという点だったのですが、やはりエンジニア文化を語るにあたっても、このKARTEというプロダクトを中心にエンジニア文化が形成されているという点は外せないかと思っています。</p>
<p>入社後の研修プログラムでも、まずはKARTEについての理解を深めるところから始まります。<br>
また、社内では<strong>ガチャ</strong>と呼んでいる仕組みがあって、プロダクトに関する不具合が見つかった場合や、エンジニア側での調査が必要な問い合わせがあった際に、その担当をエンジニアにランダムに割り当てる仕組み（厳密には順番なのでランダムではないのですが）があります。</p>
<p>普通に開発をしていると自分自身が書いたコードやその周辺領域以外はブラックボックスということが多いと思うのですが、それを意識的にバラしにいくという仕組みになっています。<br>
以下はガチャの担当が回ってきた時に自動的に割り当てられるissueにかかれているメッセージの一部です。</p>
<blockquote>
<p>bugfixを実際開発した人に回すのは基本的に最小限にする。キャッチアップも兼ねてbugfixは受け取った人がやること。分からない場合、どうしても時間がない場合はしょうがない</p>
</blockquote>
<p>自分も入社してしばらくしてこのガチャの担当に入れてもらったのですが、最初は初見のコードになかなか苦戦したものの、以下のようなメリットを感じています。（この仕組みは自社プロダクトを開発している会社では導入を検討する価値のある仕組みだと思います）</p>
<ul>
<li>自社プロダクトの（実装面だけではなく）仕様や使い方に対する理解が促進される</li>
<li>普段自分が担当している領域以外も含めたシステム全体像の理解が促進される</li>
<li>最初の実装を担当していたエンジニアへの確認などエンジニア間でのコミュニケーションが促進される</li>
<li>（クライアントからの調査依頼も含まれるので）、クライアントからの声に直接触れる機会を持てる</li>
</ul>
<h2>変化に対する柔軟性</h2>
<p>マーケティングの世界はとにかく変化が激しい世界で、KARTEを取り巻く外部環境の変化も激しく、市場に合ったプロダクト開発を進めていくためには柔軟性やスピード感が非常に重要になってきます。プレイドでは、その変化に柔軟に対応できるようにいくつかの仕組みがあります。</p>
<p>まず最初に挙げられるのが、開発を行う際のサイクルについてです。社内では開発期間を2ヶ月毎に区切ってその1区切りを<strong>フォーカス</strong>と呼んで、フォーカス毎に各チームで達成したい目標を設定して、開発に取り組んでいます。2ヶ月という比較的短いサイクルで区切ることによって、短期間のうちに成果を出せるように意識的に動くことになります。<br>
当然、2ヶ月では終わらないような開発を行うこともあるのですが、その場合はフェーズを切る形で対応するなどして、短期・長期のバランスをとっています。</p>
<p>フォーカスは2〜5人程度で担当する機能毎にチームを組んで進めていくのですが、チームの組み換えもフォーカス毎に行うこととなり、人によっては2ヶ月で新しい機能開発を終えて、次の新規機能の開発に着手していくことになります。一部高い専門性が必要となる領域ではある程度メンバーが固定化されている部分もありますが、それでも一部のメンバーを入れ替えることで変化やチーム間での交流を促すような仕組みになっています。<br>
（席替えも月1回の頻度であり、基本的にはチームごとに近い席に座ることが多いのですが、毎月周りの景色が変わるというのもなかなか新鮮でした。）</p>
<p>次に挙げられるのが、<strong>創造のための破壊</strong>という点です。どのような会社やプロダクトであっても、技術トレンドの変化によって技術的負債の返済とは付き合い続けるものだと思います。特に技術的負債によって苦労したことがある人は、なるべく負債にならないようにと、技術選定にかなり時間をかけてしまうのではないでしょうか。</p>
<p>プレイドのエンジニア文化として強く感じたのは、『<strong>とりあえずやってみる</strong>』からの、『<strong>違うと思ったら作り直す</strong>』という文化です。同期入社の@kazuponさんの<a href="/pug_to_html/">エントリー</a>でもあったような、大規模な変更についても、かなりアグレッシブに取り組んでいます。<br>
これまで作ってきたものを躊躇なく破壊（作り直すことが）することができ、それを『<strong>承認より謝罪</strong>』の文化に則って進めることができることは、変化に対応し続けるためにも、スピード感を持ち続けるためにも、非常に重要な役割を担っているように感じます。<br>
（影響範囲の大きい変更を加えることは、なかなか大変で責任も伴うことですが、変え続けていくことを是として、失敗してもフォローし合える空気感を作ることが重要なのだと再認識しました。）</p>
<h2>生産性を高め続けること</h2>
<p>最後に、入社して感じたこととして、生産性を高めることへの意識が（これはエンジニアに限らず）全社的に非常に高いということです。</p>
<p>自社で（マーケティング）のツールを開発しているだけあって、世の中のSaaSサービスに対するアンテナが非常に高いというのもあると思うのですが、とにかく社内で色々なサービスを使って、色々な業務を自動化したり効率化したりという取り組みが行われています。（入社して一番最初の仕事がPCと社内で使っているサービスのセットアップなのですが、ここでまず社内で使っているサービスの豊富さに驚きました）</p>
<p>また、既存のサービスをうまく利用するだけでなく、無いものは自社で開発してしまったり、会社の制度も含めていかに効率化するか、というのが非常によく考えられています。<br>
一例にはなりますが、社内で生産性を高めるために行われている取り組みや制度を次に挙げてみました。リモートワークについては、突発的な問題への対応に限らず、集中作業日としてうまく活用している人も多いように感じます。（心なしか大雨の日はオフィスに人が少ないような気も…）</p>
<ul>
<li>毎日勤怠をつけるのが大変
<ul>
<li>→　会社のNWに繋ぐと自動的に勤怠を記録するシステムを自社開発</li>
</ul>
</li>
<li>毎月の経費精算が大変
<ul>
<li>→　前もって手当として定額を支給する<a href="https://atengagement.com/jinji-zukan/allowance/">制度</a>を運用</li>
</ul>
</li>
<li>家庭の事情や天候不順で通勤が困難
<ul>
<li>→　リモートワークの制度をうまく活用</li>
</ul>
</li>
</ul>
<p>エンジニア(プログラマ)の美徳として『<strong>怠惰</strong>』であること、がよく挙げられ、自分自身もルーチンワークは苦手な方なのですが、いまのところ不満を感じずにエンジニアの美徳を貫いて作業に集中できる環境になっているように感じます。</p>
<p>やや働き方や働く環境的な話に寄ってしまったのですが、エンジニアとしての業務の進め方に関しても、上記の様な生産性を強く意識した環境になっています。最初の項目で挙げたガチャの仕組みはslack上のボットにより自動化されていたり、ビジネス職の方からの依頼や相談もすべてgithub上のissueに集約される形になっていて、基本的にはコードとgithubとslackがあれば通常の業務は回せるようになっています。</p>
<p>良い側面ばかりを書いてきたのですが、当然、これらの生産性を高めるための取り組みの裏側には、それだけのアウトプットが求められ続けていることや、そのためのセルフマネージメントが要求されるということを、忘れてはいけないな、とも思います。</p>
<h2>最後に</h2>
<p>最後まで読んで頂いてありがとうございます！<br>
いかがでしたでしょうか？プレイドのエンジニア文化に興味を持って頂けたでしょうか？</p>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://plaid.co.jp/recruit/engineer.html">弊社採用ページ</a>または<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>


こんにちは！エンジニアの@g0eです。4月1日にPLAIDに入社して、約4ヶ月が経過しました。
本記事ではプレイドエンジニアの組織文化について、入社4ヶ月目のフレッシュな目線で書いています。

Engineer Blog

Recent Article

フロントエンドでフロントエンドをビルドする

KubeCon in San Diegoに参加してきました！

Our seeking to stable k8s deployment.

深層強化学習は量子猫の夢を見るか？

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js設計地図〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

Google Cloud Next Tokyo ’19に参加しました！

プレイドでのインターンを振り返って

計測したいものに合わせてイベントトラッキングをする方法

入社4ヶ月で感じたプレイドエンジニアの組織文化

Archives

Writers

Recent Article

フロントエンドでフロントエンドをビルドする

KubeCon in San Diegoに参加してきました！

Our seeking to stable k8s deployment.

深層強化学習は量子猫の夢を見るか？

ITP 2.2, 2.3の検証ツールを作ってみた

Vue.js設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

Google Cloud Next Tokyo ’19に参加しました！

プレイドでのインターンを振り返って

計測したいものに合わせてイベントトラッキングをする方法

入社4ヶ月で感じたプレイドエンジニアの組織文化

Archives

Writers

Vue.js設計地図〜設計概念の依存関係からフロントエンド設計を見つめ直す〜