はてなブックマーク

Figmaのstylesをもとにして「Tailwind CSSのテーマ」「tailwind-mergeの設定」「Storybookのドキュメント」などの各種ファイルを自動生成する#デザインシステム デザインエンジニアの安田（@_yuheiy）です。 弊社で開発しているデザインシステムのSourでは、CSSフレームワークとしてTailwind CSSを採用しています。この記事では、Sourで使用しているTailwind CSSのバージョンをアップグレードしてTailwind CSS 4に対応する際に作成した、Figmaのstylesをもとにして各種設定ファイルを自動生成する仕組みについてご紹介します。 なお、ここで紹介するものと同様の実装をGitHubでも公開しています。記事中の解説と併せて参照してください。 JavaScriptからCSSベースの設定方法への変更 Tailwind 3以前で

デザインエンジニアの安田（@_yuheiy）です。 先日、「アクセシビリティ学習の手引きとしての入門講座」という記事を公開しました。これに伴って、当エンジニアブログ自体のアクセシビリティの問題が気にかかったので、併せてその改善も行いました。 この記事では、そのなかで遭遇したよくある失敗例と具体的な対処方法についてご紹介します。アクセシビリティの問題の多くは似たようなパターンを有しているため、主要なケースについて知っていただくだけでも、多くの割合の問題を未然に防ぐことができるはずです。 5月12日に記述内容を一部変更しました。 文字やアイコンのコントラスト比 改善前は、文字色やアイコンの色が薄すぎて見えづらい箇所がいくつかありました。はっきりとした黒色ではなく、淡い灰色になっているような要素のことです。これらは、ロービジョンのユーザーや、ディスプレイの色が見えづらい状況にあるユーザーにとって

合理的配慮という言葉の意味は次のとおりです。 社会生活において提供されている設備やサービスなどは障害のない人には簡単に利用できる一方で、障害のある人にとっては利用が難しく、結果として障害のある人の活動を制限してしまっている場合があります。このような、障害のある人にとっての社会的なバリアについて、個々の場面で障害のある人から「社会的なバリアを取り除いてほしい」という意思が示された場合には、その実施に伴う負担が過重でない範囲で、バリアを取り除くために必要かつ合理的な対応をすることとされています。これを「合理的配慮の提供」といいます。 出典: 事業者による障害のある人への「合理的配慮の提供」が義務化 | 政府広報オンライン たとえば、障害者がレストランを利用する場合、次のような配慮が必要になると考えられます。 車椅子に乗った人のために、ふだん置かれている椅子を移動させて、車椅子のまま席につけるよ

Developer Experience & Performanceチーム所属の安田（@_yuheiy）です。社内の開発環境の改善をおもな業務としています。 今回は、KARTEの複数のシステム間で共有する定数ファイルを、これまで社内向けのnpmパッケージとして配布していたところから、代わりとなる独自の仕組みを構築して管理する方式に切り替えたことと、その移行プロセスについてご紹介します。 なおこの記事は、先日行われたイベント「Webフロントエンドを軸に、幅を広げたエンジニアたちの仕事」での私の発表内容をもとにしたものです。 KARTEにおける「定数」とは プレイドのKARTEは、いくつものシステムの組み合わせによって構成されているサービスです。それらのシステムは、マイクロサービスとして開発体制やソースコードが分割されていますが、ほとんどすべてのソースコードは一つのgitリポジトリの中に集約さ

はじめに こんにちは，プレイドのCore Platformチーム[1]（プレイドで社内の全てのプロダクト基盤やリアルタイム解析基盤[2][3]を扱っているチーム）でインターンをしているlaplaといいます．プレイドでは2024年6月より働いており，この度社内で広く用いられているデータベースであるMongoDBのバージョンアップ業務に携わったので，その過程で得られた知見についてまとめようと思います． データベースのバージョンアップは，データベースを使用しているシステムにとって避け難いタスクであり，それはプレイドも同様です．そこでプレイドでは， 単に公式のアップデートドキュメントを読むだけではなく， MongoDBの内部構造も理解した上で作業することにより，安全なバージョンアップを継続的にかつサービス無停止で行っています．今回はその点について説明しようと思います． なお，本記事はデータベースの

はじめに こんにちは。プレイドでWicleを開発しているchakeです。 Wicleはプロダクトを使うユーザーの行動を分析し、改善するサイクルを助けるプロダクトアナリティクスサービスです。先日パブリックベータ版をリリースし、だれでもオンライン上からサインアップすることができるようになりました。詳細はこちらをご覧ください。 本ブログではWicleの認証を支えるClerkについて、採用してよかったことやハマった点などを中心に紹介します。 また、2024年9月現在、Clerkをdevelopment環境で利用した紹介記事は多くある一方で、production環境で実際に利用した記事はあまりないため、実運用までに必要なもろもろの準備などについても解説していきます。 Clerkとは ClerkはClerk, Inc.が提供するReact、Next.jsなどのモダンウェブ向けに作られた認証・認可サービ

デザインエンジニアの安田（@_yuheiy）です。 この記事では、社内向けに提供しているライブラリの使用状況を把握すべく作成した、プロダクト全体のソースコードを解析して、提供しているモジュールおよびそれを使用しているプロダクトごとに個別に自動集計する仕組みとその実装方法について解説します。 ライブラリ開発の問題と使用状況の解析 弊社では、KARTEのプロダクト群全体のデザインシステムである「Sour」を開発しています。その一環として、React製のUIライブラリ「sour-react」を作成し、社内向けのnpmパッケージとして提供しています。現在、sour-reactはKARTEのいくつものプロダクトにおいて採用されており、UI開発に欠かせないものになるほど浸透しています。 作成したライブラリが広く使われるようになるのは喜ばしくもありますが、一方、それに伴って新たな問題が生じることもありま

株式会社プレイドのCore Platformチームに所属しているBrownです。これは社内勉強会をブログ化したもので、BigQueryを題材にし、大規模なデータベースでの分散処理の仕組みについて紹介します。本ブログではBigQueryを題材にし、実際の大規模なデータベースでの分散処理を確認していくため、初学者の方から、もう一歩踏み込んでデータベースや分散処理の仕組みについて学習したい方を主な読者として想定しています。 弊社ではBigQueryについてのブログを複数執筆しており、このブログは2016年に現CPOである柴山が書いた「Bigqueryの内部処理について徹底解剖してみた」の2024年バージョンです。前回のブログでは内部でのクエリ処理に焦点を当てていますが、今回はBigQueryの全体のアーキテクチャを広く見ていきます。 BigQueryでの分散処理 BigQueryはリレーショナル

はじめに こんにちは、エンジニアインターンの八谷（やたがい）です。プレイドには2023年3月から10月の7ヶ月間インターンとして在籍し、前半はセキュリティチームにて、後半はプラットフォームチームにて開発に携わりました。 今回のブログではプラットフォームチームにて取り組んだ、異なるデータベース間のリアルタイムレプリケーションについて解説いたします。 MongoDB AtlasからBigQueryへのリアルタイムレプリケーション 背景 プレイドではアプリケーションのデータベースとしてMongoDB Atlas（以下MongoDB）、データ解析のためのデータウェアハウスとしてBigQueryを利用しています。MongoDBはドキュメント指向で高い柔軟性を持つ、アプリケーションデータの保管に適したNoSQLデータベースであり、BigQueryは大容量のデータのスケーラブルな分析を可能にするデータウ

こんにちは、エンジニアのkomukomoです。フリーランスとしてプレイドでお仕事させていただいています。これは社内勉強会をブログ化したものです。この記事では、OLAPデータベースにおいて分析クエリを高速化するために使われている技術について説明します。 また、データベース使用者がどう使うかというよりはデータベース自体の内部の話にフォーカスしています。 Introduction データベースに対するクエリというと様々なパターンが考えられますが、その処理の分類として、OLTPとOLAPという言葉が使われることがあります。[1] OLTP（Online Transaction Processing） 大量のデータの中から該当の箇所を特定して表示、更新、削除 例：チケットの予約、口座の入出金 OLAP（Online Analytical Processing） 大量のデータから集計、ソート 例：分析

こんにちは、プレイドでCore Platform開発の責任者をしているエンジニアのkusappeです。 プレイドの社内向けに行ったModern Data Stack勉強会の内容が好評だったので、データ基盤に携わる方に向けてブログ化しました。 この記事では、Modern Data Stackとは何か、そのメリットや特徴について解説します。また、具体的な技術要素・主要サービスや重要だと思うトレンドについても紹介します。 Modern Data Stackとは？ Modern Data Stackとは、データの収集、処理、分析、可視化などデータ活用に関わる機能を、それぞれに特化したクラウドサービスやSaaSツールを組み合わせて構築するという考え方やその基盤のことを指します。 クラウドサービスやその周辺の技術要素の進化によって、従来のデータ基盤と比べると以下のメリットがあると言われています。 高い

プレイドでは、社内の脆弱性診断と外部の会社に依頼する脆弱性診断を組み合わせています。 普段のセキュリティレビューは社内で行いますが、定期的に外部の会社に依頼して脆弱性診断を行なっています。 これら2つの脆弱性診断は、競合するものではないため、2つを組み合わせて行うことがセキュリティをより高めることに繋がっています。 社内の脆弱性診断の流れ 実際に社内の脆弱性診断をどのような流れで行なっているかを見ていきます。 大きく分けて次のような流れで行なっています。 依頼 ヒアリング 脆弱性のチェック フィードバック 修正/レビュー 再チェック 社内では、この一覧の流れをセキュリティレビューと呼んでいます。 開発をしてるチームから依頼が来たら、ヒアリングシートをもとにヒアリングを行います。 ヒアリングでは、そのプロダクトのアーキテクチャ、脆弱性診断のスコープ、どういう問題が起きると一番困るかといった認

Introduction 前編の記事では、Personalizationに特化したリアルタイムユーザー解析エンジン（Blitz）のコンセプトとPre-Aggregation手法を説明しました。 今回は刷新された解析エンジンのコア要素である「強整合な解析」を実現するアーキテクチャのポイントを紹介します。 強整合な解析とは何か？ プレイドの新しい解析エンジンでは、とあるユーザーのイベントが発生した際、過去も含めたイベント履歴やユーザーごとの統計値を元にフィルタリングを行うことができます。 強整合な解析とは、フィルタリングを行うユーザーの統計値が必ず最新の状態であること、つまり過去全てのイベント履歴が反映されていることを指します。 やりたいことはとてもシンプルですが、秒間最大13.4万イベントが発生する高トラフィック、かつ数百ms内の低レイテンシーが求められる状況下で、ユーザーの統計値を常に最新

Introduction PLAIDでは9年ほど前から、大規模ストリーミングデータから高速に、Aggregation/Filteringをするモジュールを育ててきて、KARTEというプロダクトの基盤としてきています。Personalizeのようなタスクをツールにガシガシ組み込むために必要なモジュールで、かなりニッチな情報ということもあって外部にあまり発信する機会がありませんでした。（決して面倒だったからではありません。決して。。） ただ、少し前にそのエンジンの刷新プロジェクトが終わったところで、そのプロジェクトの発信と併せて、初期コンセプト上の面白み（コード上は2度3度と刷新されていますが、初期コンセプトの面白い部分は踏襲されつつ新しいものが加わっています）もそれなりにあるし、発信してみようと思って書き始めました。 要求されること 現在は コードネーム “Blitz” と呼ばれる分析モジュ

プレイドでソフトウェアエンジニアをしている小池 (ハンドルネーム: koikeya) です。 今回のテーマは「KARTEの仕様に詳しいChatGPTを作ってみた」です。 最近話題のChatGPTを用いて、プレイドのプロダクトであるKARTEについての質問に回答させてみます。 KARTEに関する一般的な知識しか回答できないChatGPTに対して、質問文とサポートサイトの情報を与えることで詳しい仕様についても答えられるようにします。 将来的には、チャットサポート業務を支援する機能が作れるかもしれません。 チャットサポート業務 KARTEではKARTE Talkというチャットサポートのサービスを展開しています。 プレイドでもKARTE Talkを利用してカスタマーサポート業務を行っています。 KARTEでは新しい機能や仕様を続々とリリースするため、チャットサポートの担当者は最新の仕様を確認すべく

機密情報が間違ってログ出力されたことを検知する仕組みを、Datadogのセンシティブデータスキャナーで作る#Security#Datadog 概要 秘密鍵やAPIトークンなどの機密情報が含まれやすい場所として、ソースコードを管理するリポジトリがあります。 PLAIDでは、ソースコードへの機密情報のハードコードは原則として禁止していて、Secretlintを使い機密情報のコミットを検出しています。 リポジトリ以外の場所にも機密情報は含まれることがあります。 たとえば、KARTEはさまざまなSaaSと連携しているため、連携するSaaSのAPIを利用するためのAPIトークンなどをデータベースなどに保持しています。 これらのAPIトークンは、お客さんがプロジェクトに対して設定でき、トークンもお客さんの環境のものを利用するケースもあります。 オプション一覧 | CX（顧客体験）プラットフォーム KA

不正アクセスの中でも、アカウントへの不正ログインはもっとも基本的な攻撃になります。 なぜならログイン画面はどのサービスでも公開されていることが多く、 最近は外部サイトから流出したパスワードリストを使ったCredential Stuffingといった攻撃も行われます。 そのため、アカウントへの不正ログインは、攻撃者にとってはどのサイトでも共通の攻撃ができる比較的安易な攻撃方法となります。 この問題への根本的な対策は難しいですが、KARTEでも実装している多要素認証やアカウントロック機能といった対応が考えられます。 一方で、このような攻撃が実際に行われているかを監視する仕組みは、直接的な対策とは別途必要になります。 なぜなら、対策に抜け道がある可能性や外的要因で攻撃が突発的に発生する可能性があり、それに気付く仕組みと組み合わせることが重要となるためです。 KARTEではログのモニタリングにDa

AlloyDBのPrivate previewに参加し、Google I/Oでコメントが引用されました#GCP#AlloyDB こんにちは、エンジニアの oga です。 5/12(日本時間)にGoogle I/Oで AlloyDB と呼ばれる新しいデータベースプロダクトがアナウンスされました。 アナウンスブログ: AlloyDB for PostgreSQL を発表：高額なレガシー データベースからの解放 | Google Cloud Blog PLAIDでは、Private previewの段階で紹介をして頂き非常に興味深いものだったのでpreviewに参加して検証を行なっていて、以下の様なコメントを寄稿させて頂きました。 Introducing AlloyDB, a PostgreSQL-compatible cloud database service　より引用 以下和訳 「PLAI

こんにちは、エンジニアのmkataigiです。 突然ですが、PLAIDエンジニアブログをリニューアルしていました！ このブログは2016年4月から、プレイドのエンジニアが日々の開発業務のなかで得たさまざまな知見を、社内外の皆さんへと共有する場として運営されてきました。おかげさまで公開済みの記事は100件を超え、各記事を通じてたくさんの方々に私たちのパーソナリティについて知ってもらうことができたのではないかと感じています。 今回は、そんなPLAIDエンジニアブログを（なんとフルスクラッチで！）リニューアルしたので、その経緯や感想について簡単にまとめてみたいと思います🚀 リニューアルの動機 ページビューや採用ページへの流入数が思った以上に多いことが判明 このブログは、「社外の人にプレイドの中のエンジニアのユニークなパーソナリティを知ってもらうこと」を目的として運営されてきました。（参考: プ

「KARTE Blocksリリースの裏側」はKARTE Blocksが2021年9月14日に正式リリースされたことを記念して開始した連載シリーズです。 2021年11月8日に公開した「KARTE Blocksを支える技術」から11月19日に公開した「KARTE Blocksにおけるポジショニングの考え方とその狙い」まで10本の記事を公開しました。 このように複数人での連載記事を書く場合にどのように進めるべきか、「KARTE Blocksリリースの裏側」という連載ではどのように進めていったのかについて紹介します。 最初に編集者を決める 複数人で書く場合に重要なのが、編集者を決めることです。 複数人で書く連載は、記事の内容がバラバラになりやすいです。 そのため、連載としてのバランスの良さを求めるならば、それを管理する編集者を決めておくことが重要です。 編集者は次のような役割をもっています。 コ

こんにちは、エンジニアの@tarrです。 前回の連載記事ではマルチクラウドなどを使い、Blocksでは最大限落ちないようにリスクヘッジをしながらシステムを構築しているという記事を書きました。 AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術 今回の記事は、リリース前の状態で、どのように負荷に対応するシステムを構築したかという話です。 リリース前のシステムで、スパイクやユーザー数の急激な増加を予測して、スケールするシステムを作るのは非常に難しいです。 どのように使われるのか、どのような量のリクエストが来るのかを正確に予測することがしづらいからです。 一方で、リリースのタイミングでいきなり落ちてしまって、機能しないものを提供するわけにもいきません。 また、無限にコストをかけることもできないため、コストにも配慮した落とし所を探る必要もあります。 今回は、Blocksがリリース前にス

インクリメンタルに新しい技術を取り入れる方法では、VueからReactへ段階的に移行していったという話を紹介していました。 このReactの採用を決定してから大きな論点となったのは、ReactでCSS(スタイル)をどのように書くかについてです。 Reactのスタイリング方法には、デファクトと言えるものはありません。 Styling and CSS – React CSSファイルとclassNameを使う方法、CSSファイルをimportするCSS Modules、JavaScriptでCSSを書くCSS in JSなどさまざまな方法があります。 スタイリングライブラリの選定は、表現力はそこまで大きく変わりませんが選択肢が多過ぎます。 そのため、VueやReactを選ぶといった技術選定よりも難しい部分があります。 KARTE Blocks(以下、Blocks)では、最終的にReactのスタイ

こんにちは、エンジニアのtarrです。 KARTE Blocksは既存のサイトにタグを一行入れるだけで、そのサイトを簡単に書き換えたり、ABテストなどで最適化したりできます。 これは、サイトを読み込むときにタグによってBlocks内で設定された内容を反映させているのですが、既存のサイトの挙動に手を加えている以上、一定のリスクが存在します。 今回はそのリスクをインパクトに沿って4段階にわけ、その4つに対してそれぞれ、Blocksがどのように考え、リスクヘッジをしているかを解説します。 後半では、リスクヘッジの施策の一例として、AWSとGCPの両者を使って、サービスプロバイダレイヤーでの冗長構成をとっている仕組みを厚めに説明しています。 この記事は「KARTE Blocksリリースの裏側」の4日目の記事です。全10回を予定しています。 これから毎日記事を更新していくため、更新をチェックしたい方

KARTE Blocks(以下Blocks)では、Blocksを利用するサイトに1行の<script>タグを埋め込むことでサイト書き換えや効果計測をします。 Blocksでは、この<script>タグで埋め込むスクリプトファイルをbuilder.jsと呼んでいます。 この記事では、Blocksが扱うbuilder.jsというサードパーティスクリプトの仕組みについて紹介します。 builder.jsというセカンドパーティコンテンツをもつサードパーティスクリプトについて知る builder.jsでは安全にサードパーティスクリプトを開発して、配布、読み込みしているのかを知る サードパーティスクリプトの開発、テスト、デバッグ方法について知る この記事は「KARTE Blocksリリースの裏側」の3日目の記事です。全10回の予定です。 これから毎日記事を更新していくため、更新をチェックしたい方は@K

📝 require(moduleName) は同期処理なのに対して、import(moduleName)は非同期処理となります。 📝 tsconfig.jsonでesModuleInteropがtrueでないとdeafult importの意味合いは異なります。 この表はCommonJS ModulesとECMAScript Modulesで機能的に1対1で応するという意味ではありませんが、 大まかにはこの対応表にそってECMAScript Modulesの構文へと変換ができます。 エディターを使い手動で変換したり、次のようなツールを使ってある程度機械的な変換も可能です。 cjstoesm commonjs-to-es-module-codemod このモジュールの変換で重要なことは、できるだけCommonJS ModulesとECMAScript Modulesを混ぜないことです。