はてなブックマーク

デザインの構造を正しく捉えることは、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 が引き受けることを想定しています（ま

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 で行ったソフトウェア設計についての新人研修『ソフトウェア設計の Why & What & How』で話した内容をまとめたもので、全員に知っておいて欲しいソフトウェア設計の基礎概念について取り扱っています。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と What と How をつなげて話しています。 ソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決しているのかを考え

Wantedly のフロントエンドは React で書かれており、フロントエンドコードは複数のリポジトリに分かれています。 元々は一つのモノリシックなリポジトリでフロントエンドも管理していましたが、新規で作成するページの大部分は新しいリポジトリで書かれています。 そして、この新しいフロントエンドのリポジトリも、企業側管理画面、ユーザー側画面とで分かれています。 一方で、ヘッダーやサイドバー、フッターなどといったナビゲーションなど、リポジトリ間で共通の UI があります。 実装が重複しないよう、それらを Wantedly 共通の React コンポーネントライブラリに切り出しています。 以下は実例です。これらのページは異なるリポジトリで実装されてます。 一方、青色で囲われたヘッダーは共通なので、ライブラリの中で実装され、それを各リポジトリで呼び出しています。

Wantedly の UI デザインシステムは「WantedlyのUIをデザインする上での共通の考え方とツール＆アセット」でありエンジニアとデザイナが効率よくコミュニケーションするための共通言語となる デザインシステムを (Web) Frontend に持ち込む際は、単なるコンポーネントカタログではなく、システムが定義するものと同じレベルの抽象を持つライブラリ・フレームワークとして実装することで、より有効性を発揮する Wantedly におけるデザインシステムは、「プロダクト・デバイスをまたいでも・誰がデザインしても体験やブランドとしての一貫性を保つ」「デザインの生産性を向上させ、デザイナ - エンジニア 間コミュニケーションを改善することで、ユーザに価値を届ける速度を向上させる」といった目的のために作られたものです。 より詳しくは、デザインシステムが加速させるプロダクト開発 / Desi

新しく Wantedly の開発チームに参加する人向けのドキュメント集です。社内のエンジニアが知るべき情報のうち外部にも公開できる情報を体系的にまとめたものです。 入社前後のフルタイムの社員が一番の想定読者です。ハンドブックの内容はインターンや採用選考を受けている人にも役に立つことを期待しています。また、PDF 形式の電子書籍およびオンラインドキュメントとして広く一般公開しています。1 年に 1 度、物理書籍としても印刷し社内外に配布します。