Pinterestをスケールさせる中で学んだこと

3年弱前 | 1 point

PinterestのMarty Weinerによる goto; conference 2014の講演。

  • 「webサイトどうやってつくるの?」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。
  • 現在のPinterestのシステムアーキテクチャの全貌。
  • 個別のテクノロジーの選択理由。

などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード(初日の10:20のコマです。)できるので、そちらを見ていただいてもわかりやすいかと。

「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。」とのことですが、「これを聞いてくれてる皆さんが自分たちと同じ失敗をしないために。」というのが、Martyが伝えたいポイントです。

テクノロジーを選択するときに自問すべきことは、

  • 自分たちのニーズを満たすのか。
  • ...

急成長するサービスのサーバインフラ

3年弱前

サービスを一から立ち上げる場合も、成功したサービスが更に拡大する場合も、いずれもスケールさせるのは一苦労ですが、今回は、Dropboxの初期の取組みと、Facebookの最近の動きを取り上げてみます。

まずは、DropboxのKevin Modzelewskiが、創業当初のサーバインフラの進化を時系列で紹介している講演から。

Dropboxのデータの特徴

書込みボリューム大: 通常のサービスはコンテンツをつくるより消費するボリュームが圧倒的に多いので、read/write比率が、100:1とか1000:1であるのが典型だが、Dropboxはユーザの全端末がコピーを持つ構造なので、その比率が約1:1になる。つまり、同じサーバに対して、他社よりも100倍、1000倍書込みの役割が大きくなる構造。

ACID特性の要件をしっかり守る必要がある。ユーザの情報を預かるのだから、原子性について、「...

リスクとコストのバランスを考慮したテストカバレッジ

3年弱前

Rocky Mountain Ruby 2014で、Pivotal LabsのArjun Sharmaは、「用意したテストケースで、自信をもってデプロイできるのか?素早く不安なくリファクタリングができるか?」という条件を満たすには、コードのリスク程度に見合ったテストタイプを選択することを勧めています。

まずは、テストカバレッジ分析ツールについて、

  • 良いカバー率というのは要注意。それをどう解釈するか。カバレッジの定義がツールごとに異なる可能性や、書き忘れたコードやアサーションはチェックできないことを考慮すると、単純に目標のカバー率を達成したからこのアプリは大丈夫ということにはならない。
  • 一方で、悪いカバー率は、テストケースのどこに弱点があるかを明確にしてくれる役に立つ情報。

テストタイプを下記の三種類に分類して、それぞれのコストをまず認識する。

単体テスト

  • 依存関係はスタブ / モックして、...

npmとクライアント側でのパッケージ管理の議論

3年弱前 | 1 point

npmに登録されているパッケージ数は10万、月間ダウンロード数も5億を超えました。7月の段階で月間3億程度ですから、こちらのグラフで見てもわかるように、かなり成長が加速してきていますね。

EdgeConf4において、パッケージ管理をテーマにしたディスカッションに、npmのCTOであるLaurie Vossと、npmのpeer dependencyをつくったGoogle Chrome TeamのDomenic Denicola(ES6のPromiseの取組みでも知られた人ですね。)が参加しています。この二人と、BowerのJosh Peekを中心に議論が進んでいます。ちなみにJoshはGitHubの社員で、最近では、左右に並べてdiffを比較できる便利な機能をつくった人でもあります。

「サーバサイドのパッケージマネジャとしては、CPANやRubygem、...

CSSパフォーマンスツールを使いこなす

3年弱前 | 1 point

CSSconf EU 2014におけるGoogleのAddy Osmaniの講演です。CSSのパフォーマンス向上に役立つツールを40個+ 紹介してくれてます。

背景

パフォーマンスの最適化において、

  • ベースラインとしてやること
    • 最小化(minification)
    • 結合(concatenation)
    • 画像の最適化
    • 圧縮(GZip, Zopfli)
    • 非同期スクリプト
    • キャッシュの利用
    • WOFF2フォント
    • CSSスプライトを使う
    • リダイレクトをしないこと
  • スピードアップ
    • パフォーマンス向上に重要なCSSのインライン化
    • レンダリングをブロックしないように、急ぎでないアセットの取得を遅らせる
    • 使ってないCSSの削除
    • 修正の都度、ビジュアルの劣化テストを実施
    • パフォーマンスのベンチマーク測定
  • できればなお良いこと
    • 色、セレクタ、フォント種類/サイズを削減すること

最近のユーザの期待値は、ページの表示速度が0-100msであれば早い、...

APIの後方互換性を保つ工夫

3年弱前 | 2 points

Stripeの決済サービスの成長は、APIが使いやすいというエンジニアの間での評判がかなり寄与したと記憶しています。

同社のAPIは現在、

  • エンドポイント: 106
  • バージョン: 65
  • APIクライアント: 6

ユーザ企業を煩わせることなく後方互換性をしっかり担保したいという方針を守るための工夫を、Amber Fengが紹介してくれています。

1) ユーザが利用するバージョン情報の把握

ユーザ企業が最初にAPIコールをしたときのバージョン情報をStripe側で記録している。ユーザ企業はバージョンのことを意識することなく、それ以降は、最初のバージョンのAPIを継続して利用し続けるかたちになる。もしユーザ企業側でバージョンの変更をしたい場合は、ダッシュボードでの設定や、リクエストヘッダーに情報を付加することで可能。

2) バージョンと機能の整合性

...

デザインアセットをうまく管理したいけれど

3年弱前

DropboxのデザインチームのDaniel Edenが、アセット管理をGit + Dropbox + Web Hooksで対応している話です。

かつて、ゲーム開発のデザインアセットの管理をDropboxでやっていて、同じ問題に遭遇していたので、Dropbox自体も試行錯誤している(& それを正直に話してる)ところが少し微笑ましいですね。

自分のチームで問題になったのが、

  • 誰かが突然アセットを削除してしまう事故がたまに起きる。
  • 全てのアセットをあわせると相当重たいので、新しいメンバが入社してダウンロードを始めると、オフィス全体のネットがフリーズしてしまう。
  • 完成バージョンなのか、作業中なのかよく整理されてなくて、担当者以外は状況がよくわからない。(これはフォルダの整理とメンテの問題ではありますが。。)

安価なソリューションというのは思いつかなかったので、...

Reactを実際に使ってみた話が増えてきた

3年弱前 | 2 comments | 2 points

コンポーネントベースのviewレイヤのライブラリであるReactを、実際に使ってみた感想についての発信が増えてきているので、まとめてみました。(4)はFluxの話も入ってます。)

1) Reactとは?

E4E Developer Conf 2014の講演でFacebookのBen Andersonは、Reactを採用しているサービスを挙げています。

Facebook / Instagram / GitHub (Atom) / Khan Academy (with Backbone.js) / Mozilla Firefox (for Paneis) / NY Times / Reddit (store)

また、その仕様の背景については、

既存のフロントエンドのソリューションは、複雑な双方向データバインディングになりがちなのに対して、...

Rustを学びシステムレベル言語を理解すること

3年弱前 | 2 points

Rustについては「Rustのあれこれ」で少し触れましたが、今回はYehuda Katzが、Skylightの一連のブログGoGaRuCo2014の講演で、「ハイレベル言語のプログラマーがシステムレベルの言語を学ぶチャンス」という観点で紹介しているのを取り上げてみます。

主なポイントとしては、

  • プログラミング言語の特性は変わることがないとか、プログラミング言語のパフォーマンスと生産性は常にトレードオフであるという考え方は、JavaScriptにおいて、生産性が少し改善されつつ同時にパフォーマンスが大きく向上してきたという事実から、必ずしも正しくはない。
  • Rustは、セグメンテーション違反が起きないという意味での安全性と、どこにメモリを置くか直接コントロールできる仕様を両方兼ね備える。
  • Rustを学ぶということは、...

CDNの挙動を検証する取組み

3年弱前 | 2 points

Code for Americaなど、ネットの力で政府機関を改善していく取組みがここ数年増えていますが、中でもGOV.UKは、英国政府のwebサービスのあるべき仕様をサービスデザインマニュアルに詳細にまとめ、政府関連のウェブサイトを取りまとめています。その活動は、3分ほどのビデオにまとめらてますが、技術関連の情報発信にも力を入れてきています。

さて今回のGOV.UKのエンジニアブログは、受け入れテストを充実させてCDNの挙動を検証した取組み。実装の詳細から、バグのケースまで網羅されていて、かなり詳しく紹介されています。合わせて、Go言語の net/httptesting のパッケージをベースに作成したコードも、Githubで公開されています。

1) 背景

  • CDNの追加に際し、従前のものと同じ挙動を期待できるかテストケースを整備する必要がでてきた。
  • サービスデザインマニュアルにおいて、...

仕事の進め方とアーキテクチャの相関関係

3年弱前

「システムの設計は、その組織のコミュニケーション構造を反映したものになる。」というコンウェイの法則について、ThoughtWorksのPete Hodgsonは、それを逆のかたちで、つまり、採用すべきアーキテクチャの特性を活かすために人と人とのコミュニケーションをどう改善するかということに、かなり時間をとっていると語っています。

コンウェイの法則は、重力のように不可避なもの。うまく活かせるように変わるか、対応できずにダメになるかの二者択一だ。

各サービスの担当チームが細分化されている大企業の顧客において、SOA(サービス指向アーキテクチャ)の導入に取組む中、各チームの自由度が高まるというメリットを享受しながらも、一方で、

  • チームごとに優先順位が違ったり、バグなどでのリリーススケジュールの調整。
  • 何をやっているかわからない他のチームのサービスが障害起こすことで、...

エンジニアマネージャー論と学びを抽出する努力を続けること

3年弱前 | 2 points

真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。

情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。

RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿を “44 engineering management lessons” にまとめています。

44項目と盛りだくさんですが、抽出するという文脈でいくと、自分にとっての今回の学びは、...