Engineer Blog

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

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

<h2>はじめに</h2>
<p>はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。</p>
<p>本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。</p>
<h2>Journeyとは</h2>
<p>具体的な仕事内容をご紹介する前に、KARTEが持つ「Journey」という機能を紹介させていただきます。</p>
<p>JourneyとはKARTEで得られたユーザ行動を元に、シーンやシナリオに合わせてより1人ひとりの行動にあわせたアクションを実行する機能です *1</p>
<p>*1: <a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>例えば、「商品をカートに入れたままサイトを離れたユーザに、翌日プッシュ通知でクーポンを送る」といった複雑なシナリオを、管理画面で簡単に作成・配信することができます。</p>
<p>内部の仕組みとしては「定期実行基盤」と呼ばれるバッチジョブが存在し、このジョブが定期的に実行されることでユーザがシナリオ上のステップからステップに移動しています。</p>
<p>Journeyは現在ベータ版の機能として提供しており、今後より多くのニーズに応えられるよう定期実行基盤の改善を進めています。</p>
<h2>分岐ノードのデバッグ</h2>
<p>ここからは、実際に自分が担当した仕事を紹介していきます。</p>
<p>Journeyではユーザの各ステップを「ノード」という形で表現しており、管理画面上でノードを繋ぎ合わせることで複雑なシナリオを設定します。</p>
<p>今回自分は「分岐ノード」と呼ばれる、ユーザを属性によって異なるノードへと進めるためのノードを作り直す作業に取り組みました。</p>
<p><img src="https://ik.imagekit.io/plaid/7a976b2d-f83a-4e51-b5a8-15225c04d78b/mermaid-diagram-2025-08-28-123417.png" alt="mermaid-diagram-2025-08-28-123417.png"></p>
<p>定期実行基盤には、大きく2つの要件があります。1つは数百万規模のユーザを遅延なく処理できること、もう1つは「カートに入れたが購入しなかった」といったユーザごとの複雑な条件を計算できることです。</p>
<p>この要件を満たすため、アーキテクチャは工夫されており、「次にシナリオを進めるべきユーザを計算・抽出するコンポーネント」と、「実際にそのユーザの状態を次のステップに移動させるコンポーネント」というように、役割が明確に分割されています。</p>
<p>自分が開発に関わり始めた時点で新しい分岐ノードに対応する実装は完了していたのですが、一連の処理が正しく実行できる状態になっていませんでした。自分は、一連の処理が正しく実行されない原因を究明し、処理が完了できるようにするため様々な修正を行いました。</p>
<ul>
<li>コンポーネント間で参照しているデータベースが異なっていたため修正</li>
<li>コンポーネント間でハッシュの生成方法に差異があったため修正</li>
<li>分岐判定の誤り原因を調査するためデバッガーを導入</li>
<li>分岐ノードで分岐条件を正しく判定できても、実際に分岐先にユーザが移動しない問題の修正</li>
<li>評価環境と開発環境の差分をなくすためのマイグレーションの実施</li>
</ul>
<p>動かない間はひたすらクラウドサービスのコンソールを眺める時間が続き大変でしたが、分岐ノードのテストが正しく動作した時は本当に嬉しく感じました。</p>
<h2>BigQueryのオプションジョブ作成モードの適用</h2>
<p>Journeyでは一部でBigQueryを利用しています。インターンではパフォーマンス向上とコスト効率化を目指し、BigQueryの改善にも取り組みました。</p>
<p>BigQueryには8月からクエリが短い場合にジョブを作成せずにジョブを実行することができる昨日「オプションジョブ作成モード」が追加されました。*2</p>
<p>*2: <a href="https://cloud.google.com/bigquery/docs/running-queries?hl=ja#optional-job-creation">オプションジョブ作成モード</a></p>
<p>この機能がベータとしてリリースされた当初からJourneyではこのモードを利用するために、当時ドキュメントに記載されていた <code>QUERY_PREVIEW_ENABLED</code> という環境変数を適用していました。しかし、調査してみるとこの環境変数が設定されていてもジョブが常に作成されていることがわかりました。</p>
<p>さらにクライアントライブラリの実装 *3 を調べると、有効化の方法が環境変数での設定からクライアントのオプションとして設定するように変更されていることがわかりました。</p>
<p>*3: <a href="https://github.com/googleapis/nodejs-bigquery/pull/1480">クライアントの実装PullRequest</a></p>
<p>そのため、調査結果を元にオプションジョブ作成モードをクライアント側で明示的に指定するよう変更し、短いクエリの場合にジョブが作成されなくなったことを確認しました。</p>
<h2>プレイドでのインターン生活</h2>
<p>最後にプレイドでのインターン生活で特に印象に残った部分をご紹介します。</p>
<p>Journeyチームでは週次で全体のミーティングがあり、プロダクトの方向性などについての議論が交わされています。自分もそのような会議に基本的に出席するなかで、顧客から求められていることと技術的な制約の間を垣間見ることができました。</p>
<p>そのなかで毎度なぜ技術的な制約があるのかに立ち返りながら、ステークホルダー全員が理解できる形での説明が繰り返されている点から、単なる開発ではなく「仕事」として開発するということを学ぶことができました。</p>
<p>また技術的にも、今ある技術的課題がどこにあるのか、何が原因なのか、短期・長期でどのように解決していくのかといった議論にインターンという身でありながら参加することができたのも非常に面白かったです。</p>
<p>このように単なる開発ではなく、仕事としての開発を感じることができることがプレイドのインターンの一つの魅力だと感じました。</p>
<h2>終わりに</h2>
<p>Journeyは大量の入力があった場合にも問題なく処理できるようにするため、非常に複雑なアーキテクチャとなっています。</p>
<p>今回のインターンでは初回の1on1の際にメンターの方に分からないことを全て質問する機会をいただいたおかげで、期間を通して複雑なアーキテクチャであってもすんなりと理解することができました。 *4</p>
<p>*4: 利用されているマネージドサービスはほとんど触れたことのないものでしたが、期間を通じてそれぞれの強みと利用されている理由を理解することができました。</p>
<p>プレイドでは与えられた仕事だけでなく、自分が「ここはこうした方が良いのではないか」といった提案がインターン生であっても積極的に採用されるフラットな文化があり楽しく過ごすことができました。</p>
<p>実際にはこの記事の中ではなかなかご紹介できない様々な課題に取り組んだため、ぜひプレイドに入社して確かめてみてください！1ヶ月間お世話になりました！</p>


はじめまして、プレイドにて8月の1ヶ月間エンジニアインターンに参加しておりました、中村天晴と申します。プレイドではJourneyチームで、定期実行基盤に関するタスクに取り組んでいました。  本ブログでは自分がプレイドにて行った仕事を紹介しつつ、プレイドでの働き方やインターンの魅力をお伝えできればと思います。

プレイドインターン体験記：大規模ユーザデータを処理する裏側を覗く

<h1>自己紹介</h1>
<p>こんにちは！8月1日からプレイドでインターンをしている<a href="https://my-portfolio-kh49.vercel.app/">櫻井絵理香</a>です。<br>
普段は京都の大学に通っています。</p>
<p>これまでiOS開発をメイン（正直、iOS開発しかほとんどしたことがありませんでした...）でやってきましたが、今回のプレイドでのインターンでは初めてフルスタックで開発をしました。私は今回のプレイドのインターンでは、「モバイルアプリのNative UI構築に関する課題を解決する」新規事業・プロダクト開発のチームに配属されました。</p>
<p>Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。<br>
この記事では、そんな貴重な体験について詳しくお話ししたいと思います。</p>
<h1>インターンでの内容</h1>
<h2>デモアプリの実装</h2>
<p>SDKの機能や使用感を実際に体験してプロダクトの理解を深めるために、Figmaのデザインに沿ったデモアプリの実装を行いました。インターン開始時に「やりたいことはあるか？」と聞かれた際、CI構築とテスト実装への挑戦を希望していたため、デモアプリでこれらの技術要素を組み込むことになりました。アプリ開発では実際にSDKをコードベースに統合し、その動作を確認しました。SDKの内部実装を詳細に調査するのは初めての経験でした。<br>
<img src="https://ik.imagekit.io/plaid/01cb494a-cd74-4d5f-9919-7b345945c420/Group1759.png" alt="Group1759.png"><br>
画像はデモアプリのもの</p>
<h2>CIとテスト実装の実践的学習</h2>
<h3>GitHub Actionsによる継続的インテグレーション</h3>
<p>初めてGitHub Actionsを使用し、プルリクエスト時の自動テスト実行環境を構築しました。ワークフローファイルの設定からテスト結果の可視化まで、継続的インテグレーションの仕組みを実践的に学習できました。</p>
<h3><strong>段階的なテスト戦略の確立</strong></h3>
<p>プロジェクトIDの変更をテキストで手動入力することの煩わしさを解決するため、管理画面側でプロジェクトIDをQRコード化し、SDK側で読み取って即座にプロジェクトIDを反映する機能を実装しました。この新機能の品質を保証するため、QRコード読み込み機能を中心としたユニットテストを実装し、Swift Testingフレームワークを使用してViewModelの状態管理をテストしました。</p>
<p>具体的には、QRコード検出時の状態変化、スキャン開始/停止の制御、カメラ権限拒否時のエラーハンドリングなど、ユーザーの実際の使用パターンを想定したテストケースを作成しました。</p>
<p>テスト実装を通じて「何を保証すべきか」という設計思想の重要性を学びました。単純な動作確認だけでなく、スキャン中でない場合のQRコード無視処理や、複数回の検出処理など、境界条件や異常系も含めた包括的な品質保証の考え方を身につけることができました。</p>
<p>一方でUIテストでは従来手法の限界を実感しました。要素特定の困難さ、UI変更への脆弱性、環境依存による不安定性、そして工数の大きさが課題となりました。この解決策として<strong>MagicPod</strong>を導入し、ノーコードでの効率的なUIテスト自動化を実現しました。</p>
<h2>グラデーションカラーの実装</h2>
<p>デモアプリ実装を通じて実際のプロダクトの機能や使用感を掴むことができたため、次のステップとして実際のプロダクトへ新機能を追加しました。プロダクトの管理画面でグラデーションカラーを指定し、それがSDKに反映される機能を実装しました。この実装を通じて、フルスタック開発における問題解決力やスキーマ設計の重要性について多くの学びを得ることができました。特に印象的だったのは、スキーマを定義してmake generateコマンドでコードと型が自動生成される体験と、GraphQLを初めて触ることでプロダクトの根幹部分に関わることの責任感でした。</p>
<h3>実装の全体像</h3>
<p>アーキテクチャは以下のような流れになっています</p>
<ol>
<li>管理画面でグラデーションカラーを指定</li>
<li>データベースとGCSに保存</li>
<li>iOS SDK側でGCSからJSONを読み取り</li>
<li>JSONをパースしてレンダリング</li>
</ol>
<p>以下に動作の流れのイメージ図を記載します。</p>
<p><img src="https://ik.imagekit.io/plaid/e66702ba-fdf2-4f80-932d-e5c1184adc86/%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%882025-08-2911.20.06.png" alt="スクリーンショット2025-08-2911.20.06.png"></p>
<h2>フルスタック開発における問題解決力</h2>
<h3><strong>長い連携チェーンでのデバッグの難しさ</strong></h3>
<p>管理画面（フロント）→ バックエンド → GCS → SDK → アプリという長い連携チェーンで開発を進める中で、最も困ったのは「どこで問題が起きているか分からない」状況でした。</p>
<ul>
<li>フロントからバックエンドにJSONが正しく読み込めているか</li>
<li>GCSに正しく送信できているか</li>
<li>SDK側でJSONが正しくパースできているか</li>
</ul>
<p>これらを一つずつ確認していく作業は想像以上に大変でした。</p>
<h3><strong>問題を小さく分割する習慣</strong></h3>
<p>この経験を通じて、問題を小さく絞って解決していく方法が身につきました。各段階でのデータ整合性を確認し、どの部分で失敗しているかを特定する習慣は、今後のフルスタック開発でも必須のスキルだと感じています。</p>
<h2>GraphQLスキーマ設計の責任と互換性管理</h2>
<h3><strong>プロダクトの核となるデータ構造への責任</strong></h3>
<p>GraphQLを触ること自体が初めてで、特にJSONがプロダクトの大事な部分であることを理解した時、その定義から関わることの重大さを実感しました。スキーマの変更がプロダクト全体に与える影響の大きさは、新規プロダクトならではの貴重な体験でした。</p>
<h3><strong>互換性を考慮した設計の重要性</strong></h3>
<p>最も頭を悩ませたのは互換性の問題でした</p>
<ul>
<li><strong>後方互換性</strong>: 古いJSONで新しいSDKが正常に動作するか</li>
<li><strong>前方互換性</strong>: 古いSDKで新しいJSONが処理できるか</li>
</ul>
<p>これらの両方を考慮しながらスキーマを設計することで、将来的な変更に柔軟に対応できる基盤を作ることの重要性を学びました。</p>
<h3>インターンシップで学んだコーディングの基本</h3>
<p>インターン期間中に最も重要だと実感したのは、レイヤー構造を意識したコード設計です。各層の役割を明確に分離し、適切な抽象化レベルを維持することの重要性を学びました。<br>
単一のモジュールで複数の概念を同時に定義してしまうと、コードの保守性が著しく低下することを実際の開発で経験しました。プレゼンテーション層、ビジネスロジック層、データアクセス層といった責務の分離により、システム全体の理解しやすさと拡張性が大幅に向上することを実感できました。</p>
<h3>Claude Codeでの限界</h3>
<p>Claude Codeは非常に有効なツールですが、その限界についても理解を深めました。新規のiOSアプリ開発のような、ゼロから構築する慣れ親しんだ技術領域では優秀な開発パートナーとして機能しました。<br>
しかし、既存のWebアプリケーションなど、触ったことのない技術スタックでは期待通りの結果を得ることが困難でした。コードが動作するだけでは不十分で、なぜそのような実装を選択したのかという設計思想の理解が不可欠であることを学びました。ツールに依存するのではなく、各コードの抽象化レベルを正確に把握し、システム全体の中での位置づけを理解することの重要性を実感しました。あと、めっちゃ重複でコード書いてくる。差分だけ見ててもダメ、既存のアプリだとすでに実装済みのものがあるかもしれないので、そこを注意しなければならないと感じました。</p>
<h3>まとめ</h3>
<p>今回のグラデーションカラー機能の実装は、単なる機能追加を超えて、フルスタック開発における多くの重要な概念を学ぶ機会となりました。特に以下の点は今後の開発でも大切にしていきたいと思います</p>
<ul>
<li><strong>問題を小さく分割し、段階的にデバッグする習慣</strong></li>
<li><strong>スキーマ設計における互換性への配慮</strong></li>
<li><strong>自動生成ツールを活用した開発効率の向上</strong></li>
<li><strong>プロダクト全体のアーキテクチャを意識した設計</strong></li>
</ul>
<p>フルスタック開発は確かに複雑で困難な面もありますが、プロダクト全体を俯瞰し、エンドユーザーまでの一連の流れを自分の手で作り上げることができる魅力的な野だと改めて感じました。今回の経験を活かして、より良いプロダクト開発に貢献していきたいと思います。</p>
<h1>プレイドで働いてみての感想</h1>
<p>これまでの私の開発経験は主にiOSアプリ開発に限定されており、SwiftとFirebaseを中心とした比較的狭い技術スタックでの開発が中心でした。しかし、今回のインターンでは初めてフルスタック開発に挑戦し、フロントエンドからバックエンドまでの一連の開発フローを体験することができました。この経験は、技術者としての視野を大きく広げる貴重な機会となりました。</p>
<p>他のインターン先で既存アプリケーションの保守・運用は経験したことはあるのですが、今回は新規プロダクトの機能開発に携わることができました。ゼロから機能を設計・実装していく過程は新鮮で、プロダクトが成長していく様子を間近で見ることができたのは非常に貴重な体験でした。スタートアップフェーズのプロダクト開発に関わることで、技術的な判断だけでなく、ビジネス観点も含めた総合的な開発プロセスを学ぶことができました。</p>
<p>プレイドでは、オンライン・オフライン問わず、チームメンバーとのコミュニケーションが非常に取りやすく、疑問点があれば気軽に相談できる雰囲気がありました。そのため、インターン期間を通じて楽しみながら多くのことを学ぶことができ、充実した時間を過ごすことができました！<br>
<img src="https://ik.imagekit.io/plaid/6c2d4724-8115-4a53-8de3-b095626aa231/IMG_0619.jpg" alt="IMG_0619.jpg"></p>


こんにちは！8月1日からプレイドでインターンをしている櫻井絵理香です。今回のプレイドのインターンでは、Webのフロントエンド、バックエンド、インフラアーキテクチャ、そしてiOS SDKまで、超フルスタックな体験をさせていただき、自分にとって大きな挑戦となりました。普段慣れ親しんだiOS開発の領域を飛び出して、新しい技術スタックに触れることで多くの学びを得ることができました。 この記事では、そんな貴重な体験について詳しくお話ししたいと思います。

プレイドインターン体験記：初めてフルスタックでの開発

<h2>はじめに</h2>
<p>こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。</p>
<h2>KARTE messageについて</h2>
<p><a href="https://karte.io/package/message/">KARTE Message</a>は、クライアント企業が保有するデータをもとに、メールやプッシュ通知、LINEのメッセージの送信をノーコードで行うことができるため、マーケターなどの非エンジニアの方でも簡単に大規模なコンテンツ配信が可能なマーケティングオートメーションツールとなっています。</p>
<h2>取り組んだタスク</h2>
<p>今回のサマーインターンで取り組んだタスクは、キャンペーン編集画面における未保存の変更に対する警告機能の実装です。<br>
KARTE Messageにおけるキャンペーンとは、特定のターゲットユーザーに対してメール、アプリプッシュ、LINEなどのマーケティング施策を一括で設定し、実行するための機能です。キャンペーンの設定は「配信タイプ」「対象ユーザー」「アクション」「スケジュール」　の4つの要素で構成されています。すべての設定が完了し、キャンペーンを「実行」すると、指定したチャネルを通じてクリエイティブをターゲットユーザーに届けることができます。<br>
今回、解決したかった課題は、「キャンペーンの新規作成・編集中に、入力・変更した内容を保存せずに他のページへ移動すると、その内容がすべて失われてしまうこと」　でした。</p>
<p>※以下の画像は、実装した警告機能です。</p>
<p><img src="https://ik.imagekit.io/plaid/08d05abc-a607-4fbf-b180-ce7ba2578fbe/%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%882025-08-2615.37.32.png" alt="変更検知"></p>
<p><img src="https://ik.imagekit.io/plaid/4a6a1e4b-265f-4252-8906-58fadf93c9dd/%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%882025-08-2615.38.46.png" alt="変更検知"></p>
<h2>実装について</h2>
<p>実装は、以下の図のようになっています。</p>
<p><img src="https://ik.imagekit.io/plaid/a4cde3d8-441d-4fc6-bdaf-08b8a272f1fb/%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%882025-08-2715.06.47.png" alt="変更検知"></p>
<h3>変更検知の基本ロジック</h3>
<p>機能の核となるのは、状態の差分検知です。初期状態と現在の状態と比較し、両者に差分が生じた場合に「未保存の変更あり」と判定する仕組みです。</p>
<h3>編集後の離脱防止アラート機能</h3>
<p>未保存の変更があるかどうかを最終的に判定する関数がtrueの場合、beforeunloadイベントでe.preventDefault()を実行します。アプリケーション内の画面遷移はVue Routerのナビゲーションガードで画面遷移時の確認ダイアログを表示されるよう制御しています。</p>
<h3>異なる画面間のデータの自動同期と偽陽性防止</h3>
<p>5秒毎に実行されるタブ間データの自動更新処理については、スナップショットも同時更新するようにしました。そして、デフォルト値の初期反映で新規作成時の偽陽性を回避しています。</p>
<h3>保存成功時の状態リセット</h3>
<p>データの保存処理において、API 呼び出しが成功したタイミングで、状態を保存後の最新の状態にリセットします。</p>
<h2>苦労したこと、工夫した点</h2>
<p>今回のタスクに対して、苦労したこと、工夫した点が多く分けて３つあります。</p>
<p>一つ目は、システム的な値の変更と、ユーザーの入力値による値の変更を切り分けるのが課題でした。サーバーに最新のデータをポーリングしにいって値が変わる実装があり、その更新をユーザーによる変更と区別する仕組みが必要だったからです。また、新規作成時にデフォルト値がセットされ、これをユーザーの入力値と誤って判定する箇所もありました。デフォルト値であれば警告が出ないように、そしてユーザーによる変更があった場合も検知できるよう実装しました。</p>
<p>二つ目は、実行時の画面遷移(配信実行中など)でも未保存の警告が出ないように工夫しました。</p>
<p>三つ目は、KARTE Messageの契約プランによって初期で入ってる値が違うところがあり、初期スナップショット(initialSnapshot)を作る時に調整することで、新規作成時の偽陽性を回避できるようにしています。</p>
<h2>インターンで得られたこと</h2>
<h3>反省点</h3>
<p>これまで、コードベースが大きく、かつ多くのユーザーに利用されているプロダクトの開発経験がなかったため、自分の変更が予期せぬデグレを引き起こさないよう、常に意識して開発に取り組んでいました。具体的には、変更検知の箇所を事前に調査してチェックリストを作成し、動作確認時にチェックしていました。プロダクトが非常に巨大であるため、どこに何が書かれているのかを特定するだけでも一苦労でした。当初想定していたよりも広範囲に影響が及ぶことに気づかず、手戻りが発生してしまったこともあります。特に今回のタスクを通して反省しているのは、分からない部分を一旦後回しにしてしまった結果、それが設計時の考慮漏れに繋がってしまった点です。</p>
<h3>学び</h3>
<p>この経験から、変更に着手する前に、関連する機能を広く深く理解し、影響範囲を正確に見極めることの重要性を痛感しました。この広大なコードベースをキャッチアップするために、AIを活用したり、ディレクトリ構造から関連コードを推測して読み進めたりと、様々な工夫をしました。自分の変更が関わる全ての機能を把握するまでには時間がかかりましたが、このインターンを通して、複雑で大規模なシステムについて慎重に開発を進める力が身についたと感じています。</p>
<h2>最後に</h2>
<p>プレイドでのインターンを終えて、一つのタスクをやったこと以外にも、チーム内の輪読会の参加<br>
や、インターンの最後にあるdemodayでの発表などたくさんの刺激があり、とても成長できたと感じていますし、楽しかったです。チームメンバーの皆さんや、一緒に開発してくれた方々をはじめ、プレイドの社員の方々、インターン生のみんな、ありがとうございました。とても充実した時間を過ごすことができました。</p>


こんにちは！8月からの1ヶ月間サマーインターンとしてプレイドで働いていた蜂須賀大智です。個人でWebアプリケーションを開発したり、他社で少し開発経験を積んだりする中で、自身のフロントエンドの技術力をさらに高めたいという思いがありました。そんな中、サポーターズの1on1イベントでプレイドという会社を知り、面談を重ねるうちに事業の面白さに惹かれ、インターンとして働くことになりました。このブログでは、私がプレイドでインターンとしてどのような課題に取り組んだか、そこから何を学んだかについてお話しさせていただきたいと思います。

プレイドインターン体験記：一ヶ月のインターンで体験した技術と学び

<h2>Introduction</h2>
<p>I'm @kazupon from the Developer Experience team.</p>
<p>PLAID offers a product called KARTE that enables continuous improvement by providing popup dialogs to users visiting their website through campaigns, analyzing visualized user behavior, and implementing measures. We provide an editor called &quot;Flex Editor&quot; for editing these campaigns.</p>
<p>We've achieved a massive performance improvement in KARTE's no-code editor Flex Editor by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.</p>
<p>This article is a follow-up to our previous post:</p>
<p><a href="https://tech.plaid.co.jp/rollup-perf">How We Made Rollup Build Times 10x Faster to Improve Preview Display</a></p>
<p>Actions are applications that allow editing action templates (internally called &quot;campaign templates&quot;) through KARTE's admin panel. They're edited using &quot;Flex Editor&quot;, a no-code editor that builds JavaScript code server-side for execution as marketing campaigns on websites.</p>
<h2>The Challenge: Build Times Hurting UX</h2>
<p>When users save edited actions in Flex Editor, they're built server-side for web delivery. However, lengthy build times were causing slow server responses, forcing users to wait and degrading the overall experience.</p>
<p>According to our DataDog metrics, action-compiler build times ranged from <strong>5-10 seconds</strong>, sometimes exceeding 20 seconds.</p>
<p><img src="https://ik.imagekit.io/plaid/c1113f81-799b-4227-bb09-16658d3ffd0e/asset-builder-bad-perf.png" alt="DataDog metrics showing server-side build times ranging from 5-10 seconds"></p>
<p>The primary culprit? JavaScript-based bundlers running server-side.</p>
<p>As mentioned in our previous article, action-compiler internally uses Rollup, a JavaScript-based module bundler. Module bundling is inherently CPU-intensive. While modern JavaScript engines like V8 and SpiderMonkey can achieve near-native performance through internal optimizations, they're not ideal for CPU-heavy tasks.</p>
<p>Bundlers like Rollup, which parse massive amounts of JavaScript code and perform tree-shaking on module graphs, suffer from JavaScript's event-loop-based single-threaded architecture when it comes to CPU-intensive operations.</p>
<p>While Web Workers or Node.js worker threads (<code>node:worker_thread</code>) can provide parallelization, Rollup's architecture wasn't designed with parallel bundling optimization in mind.</p>
<p>Additionally, to maximize action performance on websites, we use Terser (a code minifier) for minification. Since minification involves static code analysis followed by compression, it adds even more CPU overhead on top of Rollup's bundling process.</p>
<h2>The Solution: Migrating to Rolldown</h2>
<p>To tackle server-side action build times, we decided to migrate from Rollup to Rolldown.</p>
<p><a href="https://rolldown.rs/">Rolldown</a> is a high-performance JavaScript bundler written in Rust with Rollup API compatibility, promising significant bundling performance improvements.</p>
<p>Rolldown addresses Rollup's performance challenges through several innovations. Bundler operations like JavaScript module parsing and module graph tree-shaking are accelerated using crates from the Oxc project and Rust-side multi-threaded parallelization.</p>
<p>While maintaining API compatibility for existing Rollup plugins, Rolldown's architecture enables plugins to run in parallel on the JavaScript side through Workers, coordinating with the Rust side.</p>
<p>At the time of writing, Rolldown is at v1.0.0 beta.32. When we evaluated migration (January 2025), we found:</p>
<ul>
<li>Core bundler implementation was nearly complete, with only edge cases and bug fixes remaining, indicating <strong>stability</strong></li>
<li>Major <a href="https://github.com/rolldown/rolldown/issues/819">Rollup plugins were compatible with Rolldown</a>, maintaining <strong>compatibility</strong></li>
<li>I <a href="https://github.com/intlify/vue-i18n/pull/2067">verified bundling behavior</a> in my OSS projects, confirming <strong>proper operation and faster bundling than Rollup</strong></li>
<li><a href="https://github.com/intlify/vue-i18n/actions/runs/12644519450">E2E tests</a> confirmed <strong>bundled JavaScript modules worked correctly</strong></li>
</ul>
<p>These factors and verification results led us to adopt Rolldown for the Flex Editor project.</p>
<h3>Migration Approach</h3>
<p>Thanks to Rolldown's Rollup API compatibility, migrating my OSS projects and packages within Flex Editor was straightforward. However, action-compiler presented unique challenges.</p>
<p>As explained in our previous article, we have two types of action-compiler:</p>
<ul>
<li>For Browser: Used for action preview functionality in Flex Editor's GUI application</li>
<li>For Server (Node.js): Used server-side to build actions for deployment as campaign applications on websites</li>
</ul>
<p><img src="https://ik.imagekit.io/plaid/a217bf9c-89f5-4ad8-84ae-1d71e26f51dd/asset-builder-action-compiler.png" alt="Architecture diagram showing action-compiler for both browser and server environments"></p>
<p>Both environments use Rollup to build actions into JavaScript code. It's a single-source package optimized for performance in each environment.</p>
<p>The browser-oriented action-compiler pre-bundles JavaScript modules that actions depend on to improve editor preview UX, as mentioned in our previous article. It even bundles Rollup itself into action-compiler for optimized build speed.</p>
<p>The server-oriented action-compiler bundles with Rollup and minifies with Terser (via Rollup plugin) to maximize action performance. Like the browser version, action-compiler itself is bundled, but unlike the browser version, it simply imports Rollup from node_modules rather than bundling Rollup into action-compiler.</p>
<p>While each environment uses Rollup appropriately with environment-specific configurations, maintaining a single source while using Rolldown only server-side required careful planning. We wanted to avoid code complexity and increased maintenance cognitive load from implementing Rolldown-specific code.</p>
<h3>Leveraging API Compatibility for Rolldown Migration</h3>
<p>We achieved server-side action-compiler Rolldown migration by leveraging API compatibility and using a bundler to rewrite Rollup imports in server-side implementation code.</p>
<p>Specifically, we implemented a Rollup plugin that replaces <code>import { rollup } from 'rollup'</code> with <code>import { rolldown as rollup } from 'rolldown'</code>.</p>
<p>This gets a bit complex, but action-compiler is a JavaScript package that compiles (bundles) actions into JavaScript code using Rollup. As mentioned, we bundle action-compiler itself for browser and server optimization. (In other words, we're bundling a bundler with a bundler!)</p>
<p>Here's the relevant excerpt from action-compiler's bundler configuration file (rolldown.config.js) - note that action-compiler's bundler is now Rolldown:</p>
<pre><code class="language-js">// ...

/**
 * Replace import syntax with rolldown when using in Node.js environment
 */
if (isNode &amp;&amp; useRolldown) {
  plugins.push({
    name: 'replace-import-syntax',
    transform(code, id) {
      if (id.endsWith('src/prod.ts') || id.endsWith('src/dev.ts')) {
        return code.replace(/import\s+{\s+rollup\s+}\s+from\s+['&quot;]rollup['&quot;]\s*;?/gm, () =&gt; {
          return `import { rolldown as rollup } from 'rolldown';`
        })
      }
    }
  })
}

// ...
</code></pre>
<p>That's it!<br>
(The implementation uses simple regex string replacement rather than AST-based static analysis since we're only transforming two files.)</p>
<p><code>isNode</code> determines if the bundle target is Node.js - <code>true</code> for Node.js (server-side), <code>false</code> for browser. <code>useRolldown</code> determines whether to use Rolldown server-side - <code>true</code> uses Rolldown, <code>false</code> continues using Rollup.</p>
<p>When both <code>isNode</code> and <code>useRolldown</code> are <code>true</code>, the bundler registers a plugin that rewrites <code>import { rollup } from 'rollup'</code> to <code>import { rolldown as rollup } from 'rolldown'</code> in action-compiler's code.</p>
<p>By setting these flags appropriately (both <code>true</code>) when bundling action-compiler for server use, the code is transformed to use Rolldown. Using the bundler eliminated the need for Rolldown-specific code in action-compiler itself.</p>
<h2>Rolldown Server-Side Build Performance</h2>
<p>With Rollup successfully replaced by Rolldown in server-side action-compiler, we measured build performance using the following configurations and environment.</p>
<h3>Metrics</h3>
<ol>
<li>Rollup<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> (no minification)</li>
<li>Rolldown<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup> (no minification)</li>
<li>Rollup + Terser (<code>@rollup/plugin-terser</code><sup class="footnote-ref"><a href="#fn3" id="fnref3">[3]</a></sup>)</li>
<li>Rolldown + SWC (<code>rollup-plugin-swc3</code><sup class="footnote-ref"><a href="#fn4" id="fnref4">[4]</a></sup>)</li>
<li>Rolldown + built-in minifier (<code>oxc-minify</code><sup class="footnote-ref"><a href="#fn5" id="fnref5">[5]</a></sup>)</li>
</ol>
<p>For comparison, we included cases without minification and the Rollup + Terser combination. Since <code>oxc-minify</code> was in WIP status during our implementation and might not function correctly for actions in the Flex Editor beta production environment, we also measured performance with Terser and SWC available as Rollup plugins.</p>
<h3>Environment</h3>
<p>Performance measurements were conducted on:</p>
<ul>
<li>Machine specs:
<ul>
<li>Model: MacBook Pro 14-inch, 2021</li>
<li>Chipset: Apple M1 Max</li>
<li>Memory: 64GB</li>
</ul>
</li>
</ul>
<p>The action structure for build performance testing:</p>
<ul>
<li>Build target action structure:
<ul>
<li>index.tsx</li>
<li>App.svelte</li>
<li>gen.ts</li>
<li>customScript.ts</li>
<li>karte-template.json</li>
<li>props.json</li>
<li>variablesQuery.json</li>
<li>localVariablesQuery.json</li>
</ul>
</li>
</ul>
<p>The action UI represents a campaign like this:</p>
<p><img src="https://ik.imagekit.io/plaid/a7f21d69-6f5b-45d6-a980-3b1a0e31ae0e/asset-builder-target-action.png" alt="Example campaign UI created with the action in Flex Editor"></p>
<p>While we'll skip the detailed file contents, when editing and saving in the editor, action file code is serialized into JSON with this structure and sent server-side for building:</p>
<p><img src="https://ik.imagekit.io/plaid/1c02f655-95ec-4206-8822-4cff3a4821b2/asset-builder-action-codes.webp" alt="JSON structure showing serialized action file codes sent to server for building"></p>
<p>For these performance measurements, we used server-oriented action-compiler to build this action code.</p>
<h2>Build Performance Results</h2>
<p>Here are our performance measurement results:</p>
<h3>Build Times</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Max Build Time</th>
<th>Min Build Time</th>
<th>Average Build Time</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup (no minification)</td>
<td><strong>560.596119 ms</strong></td>
<td>205.13774 ms</td>
<td>236.0695421 ms</td>
</tr>
<tr>
<td>Rolldown (no minification)</td>
<td>112.801283 ms</td>
<td><strong>23.01124 ms</strong></td>
<td>33.42461761 ms</td>
</tr>
<tr>
<td>Rollup + Terser (<code>@rollup/plugin-terser</code>)</td>
<td><strong>2424.394387 ms</strong></td>
<td>959.403731 ms</td>
<td>1149.732976 ms</td>
</tr>
<tr>
<td>Rolldown + SWC (<code>rollup-plugin-swc3</code>)</td>
<td>235.093658 ms</td>
<td>106.845099 ms</td>
<td>125.2551525 ms</td>
</tr>
<tr>
<td>Rolldown + built-in (<code>oxc-minify</code>)</td>
<td>143.829239 ms</td>
<td><strong>28.230994 ms</strong></td>
<td>40.44968284 ms</td>
</tr>
</tbody>
</table>
<p>Without minification, Rolldown clearly outperforms Rollup. Comparing Rolldown's minimum build time to Rollup's maximum shows approximately 24x improvement, with an average 9x performance boost. These results confirm Rolldown's acceleration benefits for action builds.</p>
<p>With minification, Rolldown builds still outperform Rollup + Terser. Comparing Rolldown + SWC's minimum build time to Rollup + Terser's maximum shows about 23x improvement, averaging 9x faster. With Rolldown's built-in minifier, we achieved an incredible <strong>87x</strong> improvement at minimum and <strong>29x</strong> on average.</p>
<p>These results demonstrate that while the SWC minifier via <code>rollup-plugin-swc3</code> provides acceleration, using Rolldown's built-in <code>oxc-minifier</code> delivers overwhelming build performance gains.<sup class="footnote-ref"><a href="#fn6" id="fnref6">[6]</a></sup></p>
<h3>File Sizes</h3>
<table>
<thead>
<tr>
<th>Configuration</th>
<th>Minified Size</th>
<th>Gzipped Size</th>
</tr>
</thead>
<tbody>
<tr>
<td>Rollup + Terser</td>
<td>92.15 kb</td>
<td>31.38 kb</td>
</tr>
<tr>
<td>Rolldown + SWC</td>
<td>114.73 kb</td>
<td>39.11 kb</td>
</tr>
<tr>
<td>Rolldown + built-in minifier</td>
<td>122.09 kb</td>
<td>40.35 kb</td>
</tr>
</tbody>
</table>
<p>File size results revealed interesting insights for action builds.</p>
<p>Various Rolldown minification configurations resulted in approximately 20-25% larger bundle sizes compared to Rollup + Terser. This is because Svelte runtime code used by actions is pre-bundled with Rolldown during action-compiler bundling.</p>
<p>Rolldown's built-in minifier <code>oxc-minify</code> has <a href="https://github.com/vitejs/rolldown-vite/issues/155#issuecomment-2856998564">several open issues</a> regarding minification optimization. Our analysis of the built code confirmed issues matching these reported problems.</p>
<p>The reason for pre-bundling Svelte runtime code is to accelerate Flex Editor preview display, as explained in our previous article.</p>
<p>Comparing minification performance between SWC (<code>rollup-plugin-swc3</code>) and <code>oxc-minify</code>, SWC showed higher compression rates.</p>
<h2>Trade-offs with Rolldown Adoption</h2>
<p>Performance measurements of Rolldown-powered server-side action-compiler showed build times exceeded expectations, while bundled action JavaScript file sizes increased 20-27% compared to Rollup + Terser.</p>
<p>Our goal was to accelerate server-side action build times and improve the save experience in Flex Editor. After team discussion, we decided to adopt Rolldown with its built-in minifier (<code>oxc-minifier</code>) for server-side build acceleration.</p>
<p>The trade-off: JavaScript action files delivered will be larger than Rollup-bundled versions. However, new actions from Flex Editor have been reduced to 1/10th the size of current production actions through architecture renewal. Server-side build acceleration with Rolldown not only improves DX through reduced server infrastructure costs but also enhances end-user UX when saving in Flex Editor. The dual benefits of DX and UX improvements drove our decision to adopt Rolldown with built-in <code>oxc-minifier</code>.</p>
<h2>Production Build Performance</h2>
<p>At the time of writing, we've deployed Rolldown-powered server-side action-compiler to production as a beta for select customers using Flex Editor. We continuously monitor server-side action-compiler performance with DataDog. Here's the graph after introducing Rolldown-powered action-compiler to production:</p>
<p><img src="https://ik.imagekit.io/plaid/8d78539a-e84b-475b-8447-90b789e8c97f/asset-builder-rolldown.png" alt="DataDog graph showing dramatic reduction in build times after Rolldown deployment"></p>
<p>In production, the system runs in a Kubernetes (k8s) container environment. Pre-migration action-compiler build times of 5-10 seconds have dramatically reduced to hundreds of milliseconds. The accelerated server-side build times when editing and saving actions in Flex Editor result in faster server responses and noticeably improved editor UX.</p>
<h2>Future Outlook</h2>
<h3>Towards Rolldown's Official Release</h3>
<p>While Flex Editor currently uses Rolldown beta, we'll continue updating toward the official release. We hope the file size issues mentioned earlier will be resolved by Rolldown's official release. Vite is also progressing with Rolldown integration through <a href="https://github.com/vitejs/rolldown-vite">rolldown-vite</a>, and we've verified <a href="https://voidzero.dev/posts/announcing-rolldown-vite#real-world-impact">up to 16x acceleration</a> in the Flex Editor project.</p>
<h3>Technical Future Prospects</h3>
<p>With Rolldown adoption, we've dramatically improved build time challenges. Our next step involves exploring AST-based editor generalization. While currently using Svelte-based AST, we're considering migration to Vapor's AST/IR base using <a href="https://github.com/kazupon/inclusion-vapor">inclusion-vapor</a> and expansion to other products.</p>
<h2>Conclusion</h2>
<p>This article detailed our journey migrating from Rollup to Rolldown, dramatically improving server-side build times and enhancing product UX.</p>
<p>Despite being in beta, Rolldown's core functionality is nearly complete and ready for production use. JavaScript/TypeScript projects can especially benefit from significant build time reductions, improving DX and accelerating CI/CD deployment cycles.</p>
<p>I hope this article inspires you to consider Rolldown for your own projects.</p>
<p>If you're interested in working on projects while contributing to OSS, please check out our <a href="https://recruit.plaid.co.jp/product">careers page</a>.</p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>v4.35.0 <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn2" class="footnote-item"><p>v1.0.0-beta.32 <a href="#fnref2" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn3" class="footnote-item"><p>v0.4.4 <a href="#fnref3" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn4" class="footnote-item"><p>v0.12.1, using minify feature <a href="#fnref4" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn5" class="footnote-item"><p>Minifier provided by the oxc project <a href="#fnref5" class="footnote-backref">↩︎</a></p>
</li>
<li id="fn6" class="footnote-item"><p>This performance measurement compares only SWC and Rolldown's minifier under Rolldown. As shown in various <a href="https://github.com/privatenumber/minification-benchmarks">minification benchmarks</a>, performance varies depending on the code being minified. <a href="#fnref6" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


We've achieved a massive performance improvement in KARTE's no-code editor "Flex Editor" by accelerating action build times up to 87x, dramatically enhancing the user experience. In this post, I'll walk you through our journey of migrating from Rollup to Rolldown for server-side build optimization.

Achieving 87x Faster Server-Side Action Builds: Migrating from Rollup to Rolldown

<p>デザインエンジニアの安田（<a href="https://x.com/_yuheiy">@_yuheiy</a>）です。</p>
<p>プレイドの多くのシステムでは、サーバーサイドの実行環境としてNode.jsを採用しています。そのため、サーバーサイドもクライアントサイドもまとめてnpmを使って依存パッケージ（dependencies）を管理している場合がほとんどです。</p>
<p>システムのメンテナンスにおいては、このような依存パッケージのバージョンを継続的にアップデートし続けることが重要です。そこで今回は、社内向けに実施した、依存パッケージのバージョンアップをテーマにした発表を一部再編集してご紹介します。</p>
<h2>なぜ依存パッケージのアップデートが必要か</h2>
<p>筆者が所属するDeveloper Experience &amp; Performanceチーム（通称: DXチーム）では、その活動の一つとして、さまざまなシステムの依存パッケージのバージョンをアップデートして回るような作業をする機会がよくあります。DXチームでは、現在アクティブに開発が行われていない一部システムのメンテナンスを担当したり、既存のチームの開発をヘルプしたりする場面があり、その一環として併せてこのような作業を行っています。</p>
<p>依存パッケージをアップデートすることには、おもに次のような理由があります。</p>
<p>まず最初は、Node.jsのバージョンアップに対応するためです。Node.jsのバージョンアップにともなって古いバージョンの依存パッケージが動作しなくなることがあるので、Node.jsに追従するために必要な作業です。</p>
<p>次は、一般的なソフトウェア品質や開発効率の向上のためです。多くのパッケージはバージョンアップにともなって、動作上のバグの修正やパフォーマンスの改善、セキュリティ上の問題の解決が行われているほか、便利な新機能が追加されたりしています。これによってソフトウェアの外部品質が改善したり、余計な実装が不要になって設計がシンプルになったりする可能性があります。また、古いバージョンのパッケージを使い続けていることで、それに携わる開発者が古いバージョンの使い方を調べたり覚えたりといった無駄な学習コストを払わなければならないという問題もあります。</p>
<h2>デザインシステムの最新化のために</h2>
<p>もう一つの理由は、利用されているデザインシステムを最新化するためです。社内向けのデザインシステムであるSourが多くのシステムに導入されていますが、Sour自体の内容は日々アップデートされ続けている一方、各システムで利用されているSourのバージョンはアップデートされずに古いものが使い続けられていることが少なくありません。</p>
<p>参考までに、<a href="https://karte.io/">KARTE</a>のリポジトリにおいて使用されているSourのバージョンは次の通りです（件数は発表時のもの）。</p>
<ul>
<li>4.x: 5件（うち3件はDXチームが管理するシステム）</li>
<li>3.x: 5件</li>
<li>2.x: 11件</li>
<li>1.x: 2件</li>
<li>0.x: 1件</li>
</ul>
<p>筆者の本務はSourの開発ですが、ユーザー側でのバージョンアップが行われなければ開発している意味がありません。そのため私自身がそのアップデート作業を担当することもありますが、それに併せてその周辺環境を整備しなければならない場面もあります。というのも、Sour自身が依存しているパッケージのアップデートにともなって、ユーザー側の関連するライブラリのアップデートをしなければならなくなったり、もしくは、そのようなアップデートにともなう問題が発生しないかをテストするための環境が必要になったりすることもあるからです。</p>
<h2>タイミングが遅れるほどアップデート作業が難しくなる</h2>
<p>一般的に、依存パッケージが古くなればなるほど対処が必要な問題が増えて複雑化し、作業が難しくなる傾向にあります。特に古いシステムをメンテナンスしていると、複数の古い依存パッケージ同士が絡み合う問題が発生してデバッグが難しくなったり、古いバージョンで想定されていなかった環境依存の問題が発生して解決のために余計な手間を取られたりすることがよくあります。</p>
<p>また、関連する機能を担当した当時の開発者がチームや会社を離れたりしていることもあります。アップデートにともなう動作確認が必要になることがありますが、そのような場合、期待される正しい仕様や動作確認の方法がわからなくなる可能性もあります。あるいは、当時の担当者にしか意図を理解できないトリッキーな実装が行われているような場合もあります。</p>
<h2>「システムのメンテナンスは天下の回りもの」</h2>
<p>これは昔から個人的に唱えている理論です。システム開発の仕事をしていると、知らない誰かが作ったシステムを回り回って自分が引き継ぐというような場面は珍しくありません。そして、自分が作ったシステムもいずれまた別の誰かに引き継がれていくことになります。</p>
<p>システムの出来の良し悪しにかかわらず、引き継いだ人にはそのすべてを引き受ける責任が生じます。だからこそ、後任の誰かのために、自分が今担当しているシステムはできるだけ良い状態にしておくという心づもりでいることが大事だと思います。</p>
<h2>作業の進め方</h2>
<p>具体的な話に移ります。</p>
<p>まず、これから説明するような作業にあたっては、さまざまな観点でのソースコードの変更をしなければならない場合があります。そのため、必ずしも1つのpull requestで一気に対応しようとするのではなく、適切な粒度に分解しながら作業を進めてください。これについては普段の機能開発と同じです。</p>
<p>次に、CIが不十分だと感じる場合はあらかじめ整備しておくのがよいです。作業を細かく分割するほど、人力ではチェックの抜け漏れが発生しがちです。変更にともなうテストを効率的に行うために、できるかぎり自動化してしまいましょう。</p>
<h3>不要な依存パッケージを削除する</h3>
<p>アップデートの前に、不要な依存パッケージがあればあらかじめ削除しておきます。使わないものをアップデートしても仕方がないからです。</p>
<p><a href="https://knip.dev/">Knip</a>を導入することで、未使用の依存パッケージやデッドコードの検出ができます。これらを削除することで余計な要素を削れます。さらに、KnipをCIに組み込むことで、今後余計なものが追加されないように予防することもできます。</p>
<p>また、そのほかにも不要な機能などが残っていれば削除しておきます。</p>
<h3>言語の標準機能に置き換える</h3>
<p>Node.jsのアップデートにともなって、これまでサードパーティのパッケージが必要だったことが、Node.jsのコアの機能として実現できるようになっていることがあります。「<a href="https://zenn.dev/morinokami/articles/npm-uninstall">Node.js の進化に伴い不要となったかもしれないパッケージたち</a>」などを参考にして置き換えてください。</p>
<p>また、ECMAScriptやDOM仕様のアップデートにともなって、同じくサードパーティのパッケージが不要になることもあります。「<a href="https://github.com/you-dont-need/You-Dont-Need">You-Dont-Need</a>」などが参考になります。</p>
<p>依存パッケージを減らしてコアの機能に置き換えていくことで、将来的なメンテナンスコストを削減できることになります。</p>
<h3>package.jsonのアップデート</h3>
<p><code>package.json</code>に記述されている<code>dependencies</code>や<code>devDependencies</code>のバージョンをアップデートする際には、次のようなコマンドを使用すると一気に書き換えができて便利です。<code>--interactive</code>オプションを指定することで、アップデートする対象をチェックボックス方式で選択できます。</p>
<p>npmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
npx npm-check-updates --workspaces --root --interactive
</code></pre>
<p><img src="https://ik.imagekit.io/plaid/9266d5fd-ceff-47f0-a94e-7d78bcfe707e/ncu.png" alt="新しいバージョンが存在するdependenciesのうち、必要なものを選択式でアップデートできる。パッケージごとに現在のバージョンとアップデート後のバーションが表示される。"></p>
<p>出典: <a href="https://github.com/raineorshine/npm-check-updates">raineorshine/npm-check-updates: Find newer versions of package dependencies than what your package.json allows</a></p>
<p>pnpmの場合:</p>
<pre><code class="language-bash">cd path/to/monorepo-root
pnpm update --latest --recursive --interactive
</code></pre>
<p>pnpm 10.12以降であれば、catalogsで管理しているバージョンもいっしょにアップデートできます。</p>
<p>またロックファイルは壊れやすいので、インストールに際して問題が発生した場合は再生成してみるとよいです。</p>
<pre><code class="language-bash">rm -rf package-lock.json **/node_modules &amp;&amp; npm install
</code></pre>
<h3>破壊的変更への対応</h3>
<p>セマンティックバージョニングにおいては、メジャーバージョンが上がるか、もしくは1.0.0に満たない場合のバージョンアップでは、常に破壊的変更の可能性があります。そのためアップデートをする前には、ざっとでもいいのでパッケージのCHANGELOGに目を通しておくことをおすすめします。</p>
<p>また、最新版よりもいくつも古いバージョンを使っている場合は、破壊的変更が積み重なって簡単にアップデートできないことがあります。そのような場合、バージョンは一気に上げるのではなく、ある程度の区切りに分けて段階的にアップデートしたほうが作業が簡単になります。</p>
<h3>後継のライブラリに置き換える</h3>
<p>場合によっては、あるパッケージの代わりとなる後継のパッケージ（ライブラリ）が登場しているがあります。既存のパッケージがメンテナンスされなくなったり、アーキテクチャが古くなって根本的な刷新が必要になったりしたときに、それを置き換えるために別のものが開発されて、コミュニティでもそちらが主流になっていくというパターンです。</p>
<p>KARTEでよく使われているところで言えば、次のような後継のパッケージがあります。</p>
<ul>
<li>Jade → <a href="https://pugjs.org/api/getting-started.html">Pug</a>（参考: <a href="https://github.com/pugjs/pug/issues/2184">Renaming jade -&gt; pug · Issue #2184 · pugjs/pug</a>）</li>
<li><a href="https://github.com/TypeStrong/ts-node">ts-node</a> → <a href="https://tsx.is/">tsx</a>（もしくは、<a href="https://nodejs.org/api/typescript.html#type-stripping">Node.jsのtype stripping</a>を使う）</li>
<li><a href="https://jestjs.io/">Jest</a> → <a href="https://vitest.dev/">Vitest</a></li>
<li><a href="https://recoiljs.org/">Recoil</a> → <a href="https://jotai.org/">Jotai</a></li>
<li><a href="https://lodash.com/">Lodash</a> → <a href="https://es-toolkit.dev/">es-toolkit</a></li>
<li><a href="https://github.com/raineorshine/npm-check-updates">npm-check-update</a> + <a href="https://github.com/ds300/patch-package">patch-package</a> + <a href="https://github.com/open-cli-tools/concurrently">concurrently</a> → <a href="https://pnpm.io/">pnpm</a> CLI（同等の機能がpnpmに組み込まれている）</li>
</ul>
<p>既存パッケージのアップデートと併せて、後継のパッケージへの移行も行いましょう。</p>
<h3>気になる部分はついでに改善しながら進める</h3>
<p>パッケージのアップデート作業をしていると、それに関係するほかの部分が気になることもあります。気になった部分についても、そのままにしておかず、せっかくなのでついでに改善してしまうのがよいです。たとえば次のようなものです。</p>
<ul>
<li>CIの構成をきれいにする</li>
<li>いらないnpm scriptsを消す</li>
<li>冗長な設定ファイルをクリーンアップする</li>
<li>deprecatedなメソッドの使用箇所を直す</li>
<li>破壊的変更がある箇所の周辺のコードをリファクタリングする</li>
</ul>
<p>このようなメンテナンス作業は普段は軽視されがちで、ともすれば老朽化した仕組みがそのまま何年も動き続けていることになりがちです。だからこそ、みなさんにはぜひ<a href="https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html">ボーイスカウト・ルール</a>を意識してもらいたいです。</p>
<blockquote>
<p>ボーイスカウトには大切なルールがあります。それは、「来た時よりも美しく」です。たとえ自分が来た時にキャンプ場が汚くなっていたとしても、そしてたとえ汚したのが自分でなかったとしても、綺麗にしてからその場を去る、というルールです。そうやって、次にキャンプに来る人達が気持ちよく過ごせるようにするのです（このルールは元々、ボーイスカウトの父と呼ばれるロバート・スティーブンソン・スミス・ベーデン=パウエルの「自分が最初に見た時よりも、世界をいい場所にすべく努力しよう」という言葉から来ています）。</p>
<p>これに倣ってコーディングに関しても同じルールを定めるとしたら「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」となります。最初にそのモジュールを書いたのが誰であるかに関係なく、皆がそうやって、たとえ少しずつでもモジュールを改善する努力を続けたとしたら、その結果どういうことが起きると思いますか?</p>
</blockquote>
<p>出典: Kevlin Henney編、和田卓人監修『プログラマが知るべき97のこと』、オライリージャパン、2010年</p>
<h2>こまめなアップデートを習慣化する</h2>
<p>アップデート作業は後回しにするほど面倒な問題を引き起こしがちです。善は急げと思って、まずは今日からやってみましょう。</p>
<p>いったんひと通りのアップデートができたら、それ以降も定期的にアップデートを続けられるように、次に作業する日を決めてしまいましょう。月に1回程度が目安です。もしくは、<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot">Dependabot</a>などの自動化ツールを使って作業を自動化するのもよいと思います。</p>


Node.jsやフロントエンドのプロジェクトにおけるdependenciesをアップデートするうえでのよくある問題やうまく進めるためのコツなど。

package.jsonのdependenciesをアップデートする技術

<p>こんにちは、エンジニアの <a href="https://github.com/komukomo">@komukomo</a> です。2020/01/30 に行われた <a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">Google Cloud Anthos Day</a> に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。（他の登壇者の方の資料も<a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">公式サイト</a>にて公開されています）</p>
<hr>
<p>我々が開発している <a href="https://karte.io/">KARTE</a> ではユーザの行動データを扱っており、その中にはセンシティブなデータも含まれているので KARTE を開発する上ではセキュリティというのは重要なトピックです。ということで今回お話したのはセキュリティに関する内容で、直接プロダクトの KARTE とは関係ないのですが、</p>
<ul>
<li>GKE でのセキュリティに関する考え方</li>
</ul>
<p>と、個別機能の紹介とユーザ目線での注意点や感想ということで</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a></li>
<li><a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a></li>
<li><a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a></li>
</ul>
<p>について発表してきました。内容としては、これからGoogle Kubernetes Engine (GKE) を導入しようとしている方や運用しはじめの方、機能の概要を知りたい方向けのお話となっています。</p>
<p>こちらにスライドとざっくりお話した内容を載せておきます。</p>
<script async class="speakerdeck-embed" data-id="b9e34200315a473fae23b66f07ca4168" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>GKEにおけるセキュリティ対策</h1>
<p>最初のトピックは GKE でのセキュリティ対策の話で、中身を省いて結論のみ書いてしまうと、</p>
<ul>
<li>ユーザの管理範囲と Google の管理範囲を意識しましょう</li>
<li>まずは GKE 公式のドキュメントにそって運用していきましょう</li>
</ul>
<p>ということで基本的すぎる感じになってしまいましたが、それでも重要なことだとは思うので、ここにも当日紹介したドキュメントのリンクを貼っておきます。</p>
<p>GKE の記事:</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/security-overview">Security overview</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster">Hardening your cluster's security</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins">Security bulletins</a></li>
</ul>
<p>こちらは GKE に限らず、Kuberentes の記事:</p>
<ul>
<li><a href="https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/">9 Kubernetes Security Best Practices Everyone Must Follow</a></li>
<li><a href="https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/">Security Best Practices for Kubernetes Deployment</a></li>
</ul>
<p>以降は個別の GKE の機能のお話です。</p>
<h1>GKE Sandbox</h1>
<p><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a> は、信頼できないワークロードをクラスタで動かすようなケースで有用な機能です。<br>
内部では <a href="https://gvisor.dev/">gVisor</a> が使われていますが、この仕組みは使う前にざっくりとでも中身を知っておくとといろいろと判断する上で役に立ちます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/69ebe27d-0498-4443-96bb-bc1888ce20d6/Screen-Shot-2020-01-31-at-13.11.04.png" alt="Screen-Shot-2020-01-31-at-13.11.04"></p>
<p>gVisor では kernel の System Call をインターセプトして、kernel の機能を emulation するようなレイヤを実装しています。（さらっと書きましたが、なかなか凄まじい実装です。コードは<a href="https://github.com/google/gvisor">こちら</a>。）<br>
このようなレイヤを実装することで、コンテナは System Call を直接実行できなくなり、Host はセキュリティを考慮して制限された System Call のみ処理するようになるので、kernel の脆弱性を悪用するような攻撃から Host を守ることができます。</p>
<p>この gVisor をGKE上で使えるようになっているのが、 GKE Sandbox です。</p>
<h2>注意点</h2>
<p>使用する上で気をつけておくとよさそうと感じたのは、互換性、パフォーマンス、gVisor の責任範囲についてです。</p>
<h3>互換性</h3>
<p>kernel の機能を emulation している部分があるので、そもそも使いたい機能が使えるかはまず確認しておくとよいかと思います。GKE Sandbox にも gVisor にも互換性に関するドキュメントがあるので両方読んでおくと確実かと思います。</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods?hl=en#limitations-incompatible">(GKE Sandbox) Incompatible features</a></li>
<li><a href="https://gvisor.dev/docs/user_guide/compatibility/">(gVisor) Compatibility</a></li>
</ul>
<p>自分は GKE Sandbox を最初試したとき <a href="https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/">Port Forward</a> が使えないということを知らずにデバッグしようとしていて、無駄に調査に時間をかけてしまいました😅</p>
<h3>パフォーマンス</h3>
<p>こちらもgVisorがSystem Callをemulationしているため gVisor を使うとそのワークロードのパフォーマンスが劣化する可能性があります。逆にいうと、System Call を激しく使わない数値計算のようなワークロードはそれほど影響はないと考えられます。<br>
実際に GKE Sandbox を使う場合にはもちろんその時に計測するかと思いますが <a href="https://gvisor.dev/docs/architecture_guide/performance/">gVisor のPerformance Guide</a> もあるのでこちらも参考になるかと思います。</p>
<h3>gVisorの責任範囲</h3>
<p>仕組みをしっていれば当たり前の話かもしれませんが、gVisor を使えばサンドボックス化は完璧、というものではありません。例えば Pod 間通信の制御をするなら別途設定が必要です。自社でサンドボックスのような基盤が必要なサービスを運用する場合は、gVisor の挙動を把握した上で適宜必要なレイヤーの制限をかけていく必要があります。<br>
gVisor がどのような目的で作られ、どのような脅威を軽減するのかについては <a href="https://gvisor.dev/docs/architecture_guide/security/">Security Model</a> に詳しく書かれています。</p>
<h1>Binary Authorization</h1>
<p>次の話は<a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a>。こちらは信頼できるイメージのみがデプロイされることを保証できる機能です。クラスタでBinary Authorization を有効にすると、Pod 作成の前に Policy のチェックが入ります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/66682698-9e64-4edf-8df2-0d15a91021ce/Screen-Shot-2020-01-31-at-13.35.02.png" alt="Screen-Shot-2020-01-31-at-13.35.02"></p>
<p>Policy の設定としては image の Path のホワイトリストの他、 <a href="https://cloud.google.com/binary-authorization/docs/making-attestations">attestation</a> という概念があるので、信頼できる検証者によって検証されたイメージのみ許可、といった設定が可能です。（※発表スライド内では&quot;署名&quot;と書いてしまっていますが、英語では attest なので多分&quot;証明&quot;、&quot;検証&quot;という訳の方が正しいですね。）</p>
<p>設定可能な <a href="https://cloud.google.com/binary-authorization/docs/policy-yaml-reference">Policyの仕様</a> はとてもシンプルなので、ざっと<a href="https://cloud.google.com/binary-authorization/docs/example-policies">設定例</a> と合わせて読めばすぐに把握できるかと思います。</p>
<p>運用時は、いろいろと例外的な状況も発生するかと思いますが、Dry Run（Policyチェックしてログは出すが制限しない）や、Break Glass（ Policy を無視してデプロイできるようにするannotation）という機能もあり、こういった運用時の考慮もされています。</p>
<h2>注意点・感想</h2>
<p>Binary Authorization の注意点としては、PolicyはGCPのプロジェクトごとで、クラスタごとの設定はある程度できるのですが Namespaceごとの細かい設定はできません。そのため、大きなクラスタで複数チームを Namespace で管理している場合は Policy 設定が難しいかもしれません。</p>
<p>ちなみに Mercari さんではGKEのBinary Authorizationではなく、その内部で使われている<a href="https://github.com/grafeas/kritis">kritis</a> を<a href="https://tech.mercari.com/entry/2019/12/23/084839">自社でフォークして使用している</a>とのことです。</p>
<p>また、「何かを強制する」機能全般に言えることですが、Dry Run や Break Glass の機能があるとはいえ、管理するProjectが大きくなればなるほど導入が大変になるものです。（有効化したものの全対応が難しくいつまでたっても dryrun 状態...のように）<br>
導入するつもりなら早めに、迷っているなら修正が難しくなる前に判断するのがよいかと思います。</p>
<h1>Anthos Config Management</h1>
<p>最後に<a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a> （以下、ACM）。こちらは、セキュリティというよりは運用の話ですが、Namespace や RoleBinding など様々な設定を管理するための機能です。</p>
<p>ACMはいわゆる <a href="https://www.weave.works/blog/what-is-gitops-really">GitOps</a> で クラスタの設定管理をするツールで、クラスタに ACM のオペレータを入れておくと、そのオペレータが指定した Git Repository と同期し設定をクラスタに反映してくれます。（ちなみに、とくに管理可能なオブジェクトの制限は今の所ないようで Namespace や RoleBinding だけでなく、Deployment や Service でも同期してくれます。そのため ACM でアプリケーションのようなものもデプロイ可能ですが、反映の順序は考慮されないそうなのであくまでも設定系のオブジェクトのみにしておいた方が良さそうです。）</p>
<p>単一クラスタ、単一 Namespace しか扱っていない場合はさほどありがたみはないかもしれませんが、複数クラスタ、Namespace を運用していて、似たようなポリシーを全体に適用したいケースなどに有用かと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24dbe497-853a-4a1a-8f86-e14c60707833/Screen-Shot-2020-01-31-at-13.35.41.png" alt="Screen-Shot-2020-01-31-at-13.35.41"></p>
<p>Git Repository との同期だけであればその他の <a href="https://fluxcd.io/">flux</a> や <a href="https://argoproj.github.io/">argo</a> などでも可能かとは思いますが、ディレクトリの階層構造でNamespace に階層構造のようなものを持たせられる、という点は特徴的です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13096746-712c-4544-b2bb-5a1dcdd9754b/Screen-Shot-2020-01-31-at-13.35.49.png" alt="Screen-Shot-2020-01-31-at-13.35.49"></p>
<p>例えば ACM で管理するポリシーの Repository を上の図のようなディレクトリ構成（緑は何らかのk8sオブジェクトのyaml、オレンジは Namespace の yaml とします）にした場合、Namespace が3つ (audit, service-a, service-b) 作成され、<code>all-policy</code> は全てのNamespace に反映、<code>app-policy</code>は <code>service-a</code>と<code>service-b</code>の Namespace にのみ反映、といった挙動になります。</p>
<p>ちなみに ACM の他にも、こういった階層構造を使うというアイデアはあるようです。<br>
https://github.com/kubernetes-sigs/multi-tenancy</p>
<h2>感想</h2>
<p>ACM は仕組みも動作もシンプルなので、Anthos を使っていてクラスタ、Namespace が複数あるような環境ならば入れておいて特に損はなさそうかなと感じました。ACM の導入についても、既に多くのクラスタにいろいろな設定をいれて管理していたとしても、ACM 管理用の repository に対象のyamlを入れてそのオブジェクトが管理対象になる（ <code>configmanagement.gke.io/managed: enabled</code> という annotation がつきます）のを待つだけなのでそこまで大変ではなさそうです。</p>
<h2>Policy Controller</h2>
<p>ACM の基本的な機能は以上なのですが、追加オプションとして、 <a href="https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller">Policy Controller</a> という機能もついており、こちらは <a href="https://github.com/open-policy-agent/gatekeeper">Gatekeeper</a> を使ったポリシーの Enforcer です。（ACM の機能とは全く別機能のような気がしますが、現状 ACM の中の機能として提供されていたのでおまけとして紹介しています。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0099943d-6ac9-4d92-aa5f-74580eafe43e/Screen-Shot-2020-01-31-at-14.49.23.png" alt="Screen-Shot-2020-01-31-at-14.49.23"></p>
<p>例えば <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/">PodSecurityPolicy</a> の場合は、「特権コンテナ禁止」といった特定の条件の制限ができるかと思いますが、こちらは任意の Kind の field をチェックできるため柔軟に設定をすることが可能です。公式の例では、Ingress の domain に重複がないか、Namespace に特定の prefix がついているか、などをチェックするサンプルがありました。</p>
<p>何をどう制限するか、というのは <a href="https://www.openpolicyagent.org/docs/latest/policy-reference/">Rego</a> という言語で書くことになるのですが、<a href="https://cloud.google.com/anthos-config-management/docs/how-to/creating-constraints-and-templates">よく使うテンプレートは予め用意されている</a>ので Rego を知らなくてもある程度使うことができます。</p>
<h1>最後に</h1>
<p>Google Cloud Anthos Dayで話したGKEのセキュリティとその周りの機能の紹介でした。Kuberentes も GKE でも次々と新機能がでてくるので追っていくのは大変ですが、全てのユースケースで必要なものではないものも多いので、しっかりそれぞれの機能を把握した上で適切に運用していきたいですね。</p>
<hr>
<h1>おまけ</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c94b1c36-a2d1-45ee-ae26-2b5bd16a8c2f/anthosday-plaid.jpg" alt="anthosday-plaid"><br>
<a href="https://github.com/MasayaAoyama">@amsy810</a> さんに撮っていただいた写真。ありがとうございます👍</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab76dea-068f-413c-832b-cfdbaa6baac5/20200130A_L260.jpg" alt="20200130A_L260"><br>
こちらは Google Cloud Anthos Day 後の懇親会。Googler、登壇者、スポンサー、様々なAnthos/k8sな人たちと話しました。これからのさらなる盛り上がりを感じたとともに、我々もどんどんアップデートしていかないとと感じました！...ということで、スピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>


2020/01/30 に行われた Google Cloud Anthos Day に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました | PLAID engineer blog

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

<p>こんにちは。プレイドで2019年8月から現在までDevインターンとして働いている大矢です。2020年4月からは正社員として働く予定です。<br>
この記事では、プレイドのインターンでどんなことをしたか、何を学んだか、そして入社を決めた理由について書いていきたいと思います。</p>
<h1>はじめに</h1>
<p>簡単に自己紹介をします。僕は大学では情報工学を専攻していて、自然言語処理の研究をしています。<br>
2019年の8月からプレイドでインターンを始めて、週4日程度で通い、今月で約半年になります。<br>
プレイドでインターンをする以前にも、他社のインターンでWebアプリの開発をしたり、自然言語処理の技術を使った開発をする機会は何度かありました。研究が落ち着いた頃、開発経験を積みたいと思いインターンを探していました。</p>
<h1>インターンを始めるまで</h1>
<p>プレイドのインターンの求人（ <a href="https://www.wantedly.com/projects/387546">https://www.wantedly.com/projects/387546</a> ）には</p>
<ul>
<li>求められるレベルが非常に高い</li>
<li>圧倒的に成長できる</li>
<li>社員と同じチームで働くことができる</li>
</ul>
<p>というように書いてあり、求められるレベルが非常に高いことにビビりつつも、ちょっと背伸びした環境にいたほうが成長できるということはなんとなく知っていたので、面接を受けてみることにしました。面接では、プレイドのインターンの制度について聞いたのが印象に残っています。<br>
プレイドに参加したインターン生は、インターン担当の社員、メンターと数ヶ月おきに面談を行います。面談までの期間の成果や働き方をみて、継続が難しいと判断された場合には契約の更新が行われない場合がある、というものです。<br>
最初は戸惑いましたが、この制度はとても良いものだと思いました。まず、求人に書いてあった「求められるレベルが非常に高い」「圧倒的に成長できる」に対する説得力が格段に上がりました。求人にこのようなことを書いてある会社は他にもありますが、この会社で働けば確実に成長できるなと感じました。<br>
また、自分にとっても良い刺激になるなと考えました。3ヶ月おきに評価があるため、それまで気が緩むことなく常に全力で働ける。そして契約の更新が行われた場合には、一定の自信になりますし、更新が行われなかった場合にも、学生なので生活に困るということはないし、挫折を味わうことで成長につながるのではないかと思いました。<br>
つまり、インターン生にとってもこの制度はプラスだと思い、インターンに参加することを決めました。</p>
<h1>インターンでやった仕事</h1>
<p>プレイドでは、エンジニアのチームは1チーム1〜5人程度に分かれ、そのチームで2〜3ヶ月の期間（フォーカスと呼びます）目標を立てて開発をしていきます。僕は、入社してから1ヶ月間はAPIチームというチームで働いていたのですが、フォーカスの区切りのタイミングで基盤チームというところを希望し、行かせてもらうことができました。<br>
それぞれのチームでやった仕事について紹介したいと思います。</p>
<h3>APIチームでの仕事</h3>
<p>インターンに参加して初めに与えられたタスクは、KARTEが提供する、開発者向けのAPIを開発するというものです。社員が取り組むような実践的で非常にやりがいのある仕事であると同時に、このタスクに関してはほとんど仕様が決まっていなかったので、僕にとってはチャレンジングな仕事でした。また、Node.js や Mongo DB についても全く経験がなかったため、技術的にも初めての状態でした。<br>
実際に取り組み始めてみると、そもそもKARTEのことをもっと知らないと、仕様を決めることもできないと感じました。以前に参加したインターンでは、仕様が決まったタスクが渡されることがほとんどだったので、そのプロダクトについて詳しくなくても、ある程度はできてしまうものでした。<br>
KARTEについて学ぶには、KARTE Dojo という、わかりやすい動画が用意されています。僕はその動画を見て、KARTEとはどんなもので、どういう機能がよく使われているのかということを理解しました。とは言っても、実際のユーザがどのように使っているか、APIにどのようなニーズがあるかまではわからないので、社員と相談しながら仕様を決めていきました。<br>
結果的に、無事に1つのAPIの実装を終えることができました。</p>
<h3>基盤チームでの仕事</h3>
<p>ちょうどフォーカスの区切りの頃、モノリシックなKARTEのシステムをマイクロサービス化するということを主に行なっているチーム（基盤チーム）があり、僕はとても興味を惹かれたので、9月からは基盤チームにジョインすることになりました。基盤チームでは他にも、開発環境をよくするための取り組みや、既存のサービスのパフォーマンスを改善するための取り組みを色々と行なっています。<br>
僕はチームとしてこのような仕事に打ち込めることが非常に有意義だと思いました。なぜなら、APIの開発をしていた時に、テストの不便さや、開発環境のパフォーマンスの悪さを感じつつも、目の前の仕事を早くこなさなければという気持ちが優先してしまい、具体的な改善作業をするには至らなかったからです。<br>
基盤チームでは、いろいろな事をしましたが、今は主にテストの改善をしています。まずは、不安定なテストを計測する仕組みを導入しました。 具体的には、github に push するたびにCircle CI で実行されるテストの結果を、Google BigQuery に送り、Google Data Portal で可視化しました。この可視化により、e2e（エンドツーエンド）テストの不安定なシナリオを特定できるようになったり、「不安定な気がする」ではなく「何%の確率で落ちているから不安定だ」と数値で示せるようになりました。<br>
また、不安定なテストにはある程度共通の原因があることもわかりました。改善については、テストケースに一つ一つ修正を入れていくというよりかは、今あるテストを壊して、不安定になる原因を排除しつつ作り直すというような方針で進めています。<br>
不安定なテストは開発スピードに大きく影響するため、非常にやりがいがあり責任のある仕事だと感じています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23177920-367c-4182-a4ee-8db534cf03f7/photo1.jpg" alt="photo1"></p>
<h1>インターンで感じたこと、学んだこと</h1>
<h3>仕事の進め方について</h3>
<p>インターンでも社員と同様に信頼して仕事を任せてもらえているという実感がありました。<br>
APIチームで開発をしているときに、プレイドで初めての仕事だったため、わからないことはどんどん質問するようにしていました。これまでのインターンやアルバイトなどで、そのように指導されていたからです。とにかく早く成果物を完成させるということに、重きを置きすぎていました。しかし、プレイドで仕事を始めて1〜2週間ほど経った時、メンターから「遠回りしても、自分一人で解ける範囲を増やすためにもっと時間を使って良いよ」という言葉をいただきました。<br>
実際にこのことを意識しながら仕事をしてみると、より解ける範囲が増えていくことに気づきました。問題に直面したとしても、次に何をするべきか考え、手を動かすことができました。<br>
こうして、自分が解ける範囲がどんどん増えて行くことを実感し、仕事が楽しく感じましたし、自信にもなりました。<br>
この時に、メンターが、インターン生が作る成果物だけでなく、インターン生の成長にも大きな価値があるという風に意識しているのだと感じました。</p>
<h3>APIについて</h3>
<p>APIチームでは、仕様を考えていく際に色々なことを学びました。<br>
APIはKARTEでできないことを外でしてもらうためのサービスなので、既存の管理画面からGUIで操作が可能なことを提供しても意味がありません。自分なりに、KARTEのユーザだったらどうするか、ということを意識しました。また、サービスの内部で使っているAPIは、仕様を変更した時の影響範囲が把握できるため、変更が難しくありません。しかし、外部のAPIの場合には多数のユーザがそのAPIをすでに利用している可能性があるため、破壊的な変更をすることが困難になります。そのため、APIにどのような機能を持たせるかは非常に慎重に検討する必要があり、必要最低限の機能を備えるのが良いということを学びました。</p>
<h3>基盤（テスト）について</h3>
<p>基盤チームでは、主にテストの改善をしていて、技術的に学ぶことが非常に多かったです。<br>
テストにも何種類かあり、ユニットテスト、システムテスト、e2eテストなどがあります。僕は初め、e2eテストをたくさん作れば、コスパよく網羅的にシステムのテストができるとなんとなく思っていました。<br>
しかし実際には、e2eテストはもろく、不安定になりやすいもので、テスト対象のシステムのソースコードが同じでも、成功するときもあれば失敗するときもあるといったものでした。そのため、外部の環境になるべく依存しないテストを多く作り、e2eテストはシステムのコアな部分を守る必要最小限のものにするのが理想的であるということを学びました。</p>
<h1>プレイドへの新卒入社を決めた理由</h1>
<p>入社を決めた理由はいくつかありますが、プレイドの文化には特に良い印象を持ちました。<br>
例えばプレイドには「承認より謝罪」という文化があります。<br>
これは、「自分で考えてやるべきと思ったことは、誰かの承認を得なくても、とりあえずやってみて良い」というようなものです。他にも色々な文化があるのですが、多くの文化に共通する考えがあると思っています。それは、「なるべくポジティブに考えたり、人のポジティブな側面を信じる方が、トータルで得られるメリットが大きい」というような考えです。<br>
「承認より謝罪」の文化の話でいうと、承認を得るために余計なことを考える必要がなかったり、失敗したとしてもそこから得られる学びがあって、それと比較したら失敗することによるデメリットは（多くの場合は）小さい、といった考え方になると思います。<br>
実際にプレイドに来て、このような考え方がプラスだと実感できた場面はいくつもありました。APIチームでメンターから「遠回りしても良いよ」という風に言われて実践してみたときもそうでした。このような文化のある会社で働けることは、自分の人生にとってプラスだと思いました。<br>
正直、僕はプレイドから内定をいただいたときに、こんな優秀な人たちの中でやっていけるのだろうかと考えました。僕にはすぐに人と比較してしまったり、自信をなくしてしまったりしてしまう癖がありました。でも、最近はそんなこと考えても時間の無駄だなと思っています。優秀なメンバーと一緒に働けることは自分の成長に大きなプラスになりますし、たまに自信をなくすくらいがちょうど良いと考えています。<br>
入社してからは今以上に多くの困難があると思いますが、成長の機会と捉えて、前向きに働いていきたいと思います。</p>
<h1>最後に</h1>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76095c7b-50a0-4ae7-af87-8b346f0d0c69/photo2.jpg" alt="photo2"></p>


プレイドのインターンで学んだことと、入社を決めた理由  | PLAID engineer blog

プレイドのインターンで学んだことと、入社を決めた理由

<p>エンジニアの<a href="https://twitter.com/jumpei_ikegami">池上</a>です。<br>
私の横着によってイベントから1ヶ月以上経ってしまいましたが、2019/12/11(水)に、ラクスルさんとの共同主催で「Vue.js for 2020」というイベントを開催しました！</p>
<p><a href="https://plaidtech.connpass.com/event/153623/">【PLAID × ラクスル】Vue.js for 2020 - connpass</a></p>
<p>会場はプレイドのオフィスを使い、LTや、スポンサーブース、懇親会など盛りだくさんの内容でした。</p>
<p>イベントの詳細については下記のイベントページからご覧いただけますが、<a href="https://twitter.com/takepepe">takepepe</a>さんによる<a href="https://github.com/takefumi-yoshii/vuex-guardian">vue-guardian</a>の実装に関する30分間のセッションがあったり、スポンサー企業を主催2社も含めて6社取ってブースを設けてもらったり、お祭り感のあるイベントになりました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3e4e5ec4-0b6e-487f-ad42-b9b9ef7a362f/plaid_booth.jpg" alt="plaid_booth"></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f052e23b-556f-44f7-b184-6ba6fb2db86c/raksul_booth.jpg" alt="raksul_booth"></p>
<p>運営自ら楽しみすぎて写真を全く撮っていなかったですが、懇親会もとても盛り上がりました！（なぜかピザとお寿司の写真だけあったので貼りますw）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0094c3e5-1130-4c48-b210-97548b9a6c3a/pizza.jpg" alt="pizza"></p>
<p>登壇内容の詳細等については、ラクスルさんのエンジニアブログに詳細にまとまっていたので、こちらも合わせてご覧ください！</p>
<p><a href="https://tech.raksul.com/2020/01/07/vue-for-2020-event-report/">【PLAID × ラクスル】Vue.js for 2020 イベント開催レポート | Raksul ENGINEERING</a></p>
<p>イベントレポートは以上です！<br>
今後もプレイドとして、他の会社さんと共同で技術系のイベントを開催し、技術コミュニティに貢献していきたいと考えています。面白そうな話があれば、ぜひ<a href="https://twitter.com/jumpei_ikegami">池上</a>などプレイドメンバーまでご相談くださいー。</p>
<hr>
<p>ちなみに、プレイドでは、Vue.jsを0系の頃からゴリゴリ使って大規模アプリケーションを作っています。プレイドで働くことに興味がある方がもしいたら、<a href="https://meet.plaid.co.jp/">弊社採用ページ</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>


2019/12/11(水)に、ラクスルさんとの共同主催で「Vue.js for 2020」というイベントを開催しました！会場はプレイドのオフィスを使い、LTやtakepepeさんのセッション、スポンサーブース、懇親会など盛りだくさんの内容でした。

Vue.jsに関するイベントをラクスルさんと共催しました！ | PLAID engineer blog

Vue.jsに関するイベントをラクスルさんと共催しました！

<p>Microservicesは面白い。ほとんどすべて必要なことはそこに書かれているように思う（言い過ぎ）。<a href="https://martinfowler.com/articles/microservices.html">https://martinfowler.com/articles/microservices.html</a> 訳 <a href="http://kimitok.hateblo.jp/entry/2014/11/09/211820">http://kimitok.hateblo.jp/entry/2014/11/09/211820</a></p>
<p>&quot;適切に&quot; 分離し、&quot;適切に&quot; それらの間の依存さえ解決出来れば、コンポーネントを個別で管理し運用し、進化させ続けることが出来る。開発チームは自分達の関心範囲が明確になり、集中しビジネスレベルで責任を持つことさえできる。</p>
<p>ただし、多分 &quot;適切な&quot; 人が読んだら、に限る。これは半分言葉だけの問題で、&quot;マイクロ&quot; と &quot;サービス&quot; が共に少しミスリーディングなせいか、現実問題どのように切ったらいいかがよくわからないからだ。</p>
<p><code>Self Contained Systems</code> は正直単なる Microservices の具体的解釈の一つ（ほぼAlias）に過ぎないと思うが、明示的に1レイヤー増やしていること（Microservicesでは暗黙的なだけ）で、事業の進め方や組織ポリシーを反映させやすく、扱いやすい気がしている。その割に知られていない気がしているのでご紹介。</p>
<h2>Self Contained Systems</h2>
<p>詳しくは下記を参照。<br>
<a href="https://speakerdeck.com/rstrangh/self-contained-systems-1">https://speakerdeck.com/rstrangh/self-contained-systems-1</a> だいたい書いてあるスライド<br>
<a href="https://scs-architecture.org">https://scs-architecture.org</a> 本丸のサイト<br>
<a href="https://www.infoq.com/articles/scs-microservices-done-right/">https://www.infoq.com/articles/scs-microservices-done-right/</a> infoqの記事</p>
<p>ざっくり言えば、Microservice を複数束ねたもの （+ 必要であればFront/Api） を SCS: Self Contained System と呼び、それらをTeamにAssignしよう、というもの。<a href="https://micro-frontends-japanese.org/">Microfrontends</a> に親しい人にはそちらの解釈に近いように感じるかもしれない。Frontも含まれないものも表現できる意味で少し適用しやすい。（front側はurlベースでの協調がメイン。基本url切っちゃおうということ）</p>
<p>イメージ（別にモノレポの制約とかはない）</p>
<ul>
<li>repo
<ul>
<li>system1 = product1 (Teamにassign）
<ul>
<li>service1.1</li>
<li>service1.2</li>
<li>...</li>
<li>api</li>
</ul>
</li>
<li>system2
<ul>
<li>service2.1</li>
<li>service2.2</li>
<li>...</li>
<li>front</li>
</ul>
</li>
<li>...</li>
</ul>
</li>
</ul>
<p>System間は通常のMicorservicesと同様に、単純なRestやEvent BusをVersion管理して依存を切る。<br>
System内はコードを直接依存させても良いし、versionを意識せず開発し、Deployはsystemの粒度で同期して行われることを想定する。（Canaryを使いたいケースでは使えば良い）versionを意識した開発は気が滅入る。できうる限り考慮したくない。<br>
ある意味、SCSsの一つのSystemは、<code>多少構造化されている小さいMonolith</code> だと言える。Monolithの良さは凝集性に、デメリットはスケール性にあるが、一つのTeamを小さく=一つのSystemを小さくする制約が付けられれば、良い点だけが享受できる。</p>
<p>Systemそのものの考え方はそれで良いとして、ここでの最大の関心は、Systemの境界、ひいてはTeamの境界をどう引くか、というところにある。</p>
<h2>Teamをどのように機能させたいかと、Systemの切り方</h2>
<p>Teamの境界をどう考えるか、は <code>Teamをどのように機能させたいか</code> と関連している。これは多くの場合、事業構造/組織ポリシーそのものと関連している。（つまり、それぞれの企業ごとに別の解がある）（注1）</p>
<p>例えば、Plaidの場合は（少し特殊なところかもしれないが、）事業のベースを抽象度が少し高い設計をする代わりに、その具現化のために、メンバーの発想力とモチベーションを生かすことを想定している。また間違いによるエラーの許容度も高く設計していて、大きく、素早く開発サイクルを回すことをちょっとした競合差分として設定している。そのため、Teamに対してサービスレベルでの意識を持ってもらう構造になること、できうる限り大きい幅広の範囲で裁量がわたるような構造にすることが、組織ポリシーとしても重要で、それは事業構造から来ている。</p>
<p>具体的には、Designer/Business/Developer が1Teamで動けるようにして、Featureよりもなるべく大きい Productを持つようにし（Productと呼ばないケースも多いが）、アーキテクト設計から、クライアント提供方針、（必要であれば）価格/コスト、マーケティングまでをある程度裁量を持たせる粒度で切る必要がある。<br>
その時、1Productのサイズは、その1Team（Plaidの場合TeamのサイズはDeveloperのみでは2~5人程度を目安）が1サイクル（Plaidの場合2~3ヶ月）でまわせるサイズを考える。これは提供できるものの制約にもなるが、それがそのままSystemの単位になる。</p>
<p>これはPlaidにおけるSystemの切り方の一つの例（注2）だが、もちろん他にも色々考えられる。</p>
<p>例えば、安定性/障害耐性等が高まることが事業構造上競争優位になるような場合、なるべく小さく、（SCSsのように一気通貫性を高めAgilityを上げるのではなく）職能によるレイヤーで切って固く進めた方が良いかもしれない。</p>
<p>結局次のような質問に答えつつ、Systemの粒度をまず決める必要がある。</p>
<ul>
<li>チームのサイズをどのくらいが適切と考えるか</li>
<li>事業構造とTeamの機能のさせ方をどう考えるか</li>
<li>事業フェーズをどのように考えるか</li>
</ul>
<p>注1: 個人的にはこれも <code>逆</code> と書くのはミスリーディングだな、という気がしているけれど、business architecture → org structure  = system architecture を目指す 逆コンウェイ戦略 といいたいことは多分同じ。</p>
<blockquote>
<p>'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture <a href="https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver">https://www.thoughtworks.com/radar/techniques/inverse-conway-maneuver</a></p>
</blockquote>
<p>注2:<br>
もちろん、System Architecture寄り (DDDとか) の切り方に引っ張られた方が良い場合もある。というか結構ある。そこら辺は、、柔軟に判断するw</p>
<h2>終わり</h2>
<p>結局systemっていう言葉を導入しただけなので、なんてこともないが、microserviceそのものを使っていると多分悩んだであろうところが、ある程度社内で悩まずに進めている。正直結構うまくハマっている好例だと思うので、誰かの参考になれば。</p>
<p>CI/CD戦略とかk8sの使い方とか、モノレポとかversion管理とか、そこの具体が当然また面白いところではあるし、実際に進めているところのHard thingsとかがまた面白いところだと思うが、そこは基盤チームの誰かが書くと思う &amp; 弊社に来てくれればいくらでも説明しますので、気軽に遊びに来てくれれば良いんじゃないかと思います。</p>


Self Contained Systemsの紹介 | PLAID engineer blog

Self Contained Systemsの紹介

<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設計地図 〜設計概念の依存関係からフロントエンド設計を見つめ直す〜

Engineer Blog

Recent Article

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

プレイドのインターンで学んだことと、入社を決めた理由

Vue.jsに関するイベントをラクスルさんと共催しました！

Self Contained Systemsの紹介

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

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

Our seeking to stable k8s deployment.

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

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

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

Popular Articles

Popular Tags

Archives

Writers

Recent Article

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

プレイドのインターンで学んだことと、入社を決めた理由

Vue.jsに関するイベントをラクスルさんと共催しました！

Self Contained Systemsの紹介

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

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

Our seeking to stable k8s deployment.

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

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

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

Popular Articles

Popular Tags

Archives

Writers

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