サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
docs.wantedly.dev
デザインの構造を正しく捉えることは、UI の実装を専門にしているかどうかを問わず、開発生産性が高く、ユーザにとっても使いやすい実装を実現するための重要なポイントです。 この章では、Wantedly におけるデザインシステムの構成、そして UI を実装する上で基礎となる Wantedly の UI デザインシステムの概念と考え方について解説します。 なお、この記事はノンデザイナーズ・Wantedly デザインシステム完全理解ペーパーを元に書いています。
Wantedly では、システム内部のマイクロサービス間通信に Protocol Buffers / gRPC を利用しています(『protobufスキーマとgRPC通信』の章)。 では、他のマイクロサービスではなく、Webアプリやモバイルアプリに向けて API を提供する場合についてはどうすると良いでしょうか? この章では、アプリから使えるシステムの API(まさに "Application Programming Interface" です)を用意する際に使う、GraphQL Gateway について概説します。 GraphQL Gateway とは、システムの中に数あるマイクロサービスの一つで、アプリ向けに GraphQL API を提供するものです。 基本的に、アプリからシステムに対しての API 呼び出しは全て GraphQL Gateway が引き受けることを想定しています(ま
このドキュメントはインシデント発生前に予防として読んでおくことを想定しています。 緊急時は Incident Response (internal) 及び #war_room (internal) を確認してください。 インシデント対応について Incident Response (internal) がより網羅的かつ真とするドキュメントです。 このドキュメントでは上記のドキュメントの内容を補足する内容として特に new joiner が認識しておくべき情報を抽出/加筆したものです。 もし上のドキュメントとこの章に食い違いが生じる場合は上のドキュメントを真としてこの章を編集してください。 各チームで new joiner を受け入れるときにこのドキュメントを一律に共有することで共通認識を得ることを目的にします。 このため主に障害対応経験が少ない人に向けた最低限の心構えを共有するものであり障
経営においてデータを使って判断することは必要不可欠であり、その正確性とスピードがビジネスの勝敗を決めます。 Wantedly のデータ基盤の存在意義の1つは、そのビジネスにおける意思決定の正確性とスピードをサポートすることです。
Infra と各チームの SRE が中心になって、 ポストモーテムの作成や同期的なレビュー会を毎週行っています。 https://github.com/wantedly/post-mortems (internal) に過去のポストモーテムをまとめています。 Wantedly では、日々新しい機能や新しいシステムが追加されています。 そのため、成長と同時に複雑な分散システムになりつつあります。 インシデントやサービス障害は、増幅する規模感と変化の速度から避けがたいです。 インシデントが発生した場合は、基本的にその場で原因対策し安定運用に戻します。 しかし、こういったインシデントから学びを得るための定式化されたプロセスがなければ、同じようなインシデントが無限に繰り返し起こることになります。また野放しのままになってしまえば、インシデントの複雑さは加速度的に増し、あるいは積み重なってシステムの対
本章では、gRPC in Ruby の Quick Start から一歩先、「Wantedly で Ruby を使って gRPC Server/Client の開発をどう行なっているのか」について紹介します。
本稿では gRPC + protobuf の入門とWantedlyにおけるベストプラクティスを紹介します。 protobuf (Protocol Buffers) はデータフォーマットで、JSONの役割を置き換えるものです。一方 gRPC は通信プロトコルで、HTTPの役割を置き換えるものです。 gRPC + JSON や HTTP + protobuf のような組み合わせも可能ですが、Wantedlyでは使わないので以降では考えません。 JSONとprotobufの重要な違いとして、protobufはフォーマットがスキーマに依存するという点があります。JSONはスキーマがなくても完全なシリアライズ・デシリアライズが可能ですが、protobufのデータをシリアライズ・デシリアライズするにはスキーマ情報が必要です。gRPCは技術的には必ずしもスキーマ依存ではありませんが、実装上はスキーマなし
Wantedly のエンジニアには、課題発見からリリース、そして結果分析までの一連の改善ステップを、オーナーシップを持って進めることが期待されます。その中のフロントエンドの実装において、プロダクトデザイナーと上手くコミュニケーションをとって協働することは、改善スピードを上げるためにも、またプロダクトの品質を上げるためにも重要なスキルになります。 本章では、Wantedly のエンジニアとして、プロダクトデザイナーとのコミュニケーションのあり方や、プロダクトをスムーズに開発するために気をつけることを説明します。前半では、一般的にデザイナーと協働するために心得ておくと良いことを、後半では、スムーズに仕事を進めるための心得について、リリースまでの全体像を説明した後、各ステップごとに気をつけるべきことを説明します。 デザイナーと上手く協働するテクニックは色々とあると思います。また、一緒に働く人によ
この章では、モバイルのアーキテクチャについてまとめています。 Wantedlyでのモバイルの歴史から、現在の状態、そして将来の展望について記述しています。 この章は、継続的にメンテナンスされ、モバイルエンジニアのオンボーディングの一助になることを期待します。 モバイルアプリにおいて、アーキテクチャにバージョンが生まれるのは必然です。 既存のアーキテクチャの課題感への解決策として新しいバージョンのアーキテクチャが生まれたり、パラダイムシフトが起きるとアーキテクチャが変わっていきます。 アーキテクチャは、バージョンが新しくなるたびに改善していきます。 しかし、古くなったアーキテクチャをすべて一度にリニューアルするのは、膨大なコストが掛かるため非現実的であり、徐々に古いものを新しくしていくのが現実的です。 そのため、常に古いバージョンのアーキテクチャと向き合う必要があります。 この章は、古いアー
Wantedly のフロントエンドは React で書かれており、フロントエンドコードは複数のリポジトリに分かれています。 元々は一つのモノリシックなリポジトリでフロントエンドも管理していましたが、新規で作成するページの大部分は新しいリポジトリで書かれています。 そして、この新しいフロントエンドのリポジトリも、企業側管理画面、ユーザー側画面とで分かれています。 一方で、ヘッダーやサイドバー、フッターなどといったナビゲーションなど、リポジトリ間で共通の UI があります。 実装が重複しないよう、それらを Wantedly 共通の React コンポーネントライブラリに切り出しています。 以下は実例です。これらのページは異なるリポジトリで実装されてます。 一方、青色で囲われたヘッダーは共通なので、ライブラリの中で実装され、それを各リポジトリで呼び出しています。
Wantedly の UI デザインシステムは「WantedlyのUIをデザインする上での共通の考え方とツール&アセット」でありエンジニアとデザイナが効率よくコミュニケーションするための共通言語となる デザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮する Wantedly におけるデザインシステムは、「プロダクト・デバイスをまたいでも・誰がデザインしても体験やブランドとしての一貫性を保つ」「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザに価値を届ける速度を向上させる」といった目的のために作られたものです。 より詳しくは、デザインシステムが加速させるプロダクト開発 / Desi
新しく Wantedly の開発チームに参加する人向けのドキュメント集です。社内のエンジニアが知るべき情報のうち外部にも公開できる情報を体系的にまとめたものです。 入社前後のフルタイムの社員が一番の想定読者です。ハンドブックの内容はインターンや採用選考を受けている人にも役に立つことを期待しています。また、PDF 形式の電子書籍およびオンラインドキュメントとして広く一般公開しています。1 年に 1 度、物理書籍としても印刷し社内外に配布します。
このページを最初にブックマークしてみませんか?
『Wantedly Engineering Handbook | Wantedly Engineering Handbook』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く