Facebook: HTTPSサイトを狙うBREACH攻撃対策

約3年前 | 1 point

BREACHについてはまったく知識がなかったので、Facebookのセキュリティチームのこのブログは興味深かったです。

まず前提としてFacebookは、よく知られているクロスサイトリクエストフォージェリ(CSRF)攻撃への対策として、FacebookユーザにCSRFトークンを発行。トークンは攻撃者が簡単に発見できないもので、トークンを提示しないかぎりは他人になりかわってFacebookにwebリクエストをすることができない。この仕組みで、攻撃者に利用されて意図しない攻撃に参加させられるケースを防いでいます。

しかし、webページの内容が圧縮される際に暗号化されているとしてもトークンを見つけられてしまう可能性あり。

圧縮技術は、テキストの繰り返し表現を一度しか送信しなくて済むので、通信スピードをあげるのに役立つ。例えば、"Beetlejuice"...

積み重ねと目的意識

約3年前 | 1 point

Railsの10年の取り組みを振返った、RailsConf 2014のYehuda Katzのキーノートスピーチは、

  • 高い生産性をもたらすのは、特別優れた人のために特別なツールを用意するのではなく、共通の問題に対処する共通のソリューションを積み重ねること。そうすることで、次に挑戦する人たちは、地上から山頂を目指すのではなく、超高層ビルの高さからはじめることができる。
  • 一般的には、「ソフトウェアの抽象化は意図したほど役には立たないことが多い」( The Law of Leaky Abstraction ) という傾向があれど、共通のソリューションづくりにおいては、すぐに諦めるのではなく、「前よりもよくなるのか?」と自問しながら積み重ねていくことが大切。

という点がポイントだったと思います。

スピーチの中で、はじめて聞いた表現がいくつかありました。

Ego Depletion

「...

Netflix: 結果整合性の許容範囲は広がってしかるべき

約3年前 | 2 comments | 3 points

Cassandra Day Silicon Valley 2014でのChristos Kalantzis (Cloud DB Engineering Manager, Netflix) の講演。

  • 10年前を思い出してほしい、データの書込みは1台のマスターに、読込みは複数のスレーブで担いスケールさせていた。ウェブサービスでよく使われていた手法だが、レプリが完全に行われないケースはありえた。
  • Cassandraの場合は、大量のデータ処理でも結果整合性の遅延は極短く、信頼性高く、かつデータ修復機能もある。チューニングできるシステム。
  • Netflixでの実験:
  • - 二箇所のデータセンタで、Cassandra 1.1.7のクラスタを48ノード用意。
  • - Cassandraクラスタで、データセンタあたり50K/秒、全体で100K/秒のオペレーションを実施。
  • - 一つのデータセンタで百万件の書込みを実行。...

ブロックチェーンをもう一段深く理解する

約3年前 | 2 comments

このブログでGoogleのIlya Grigorikが言及している、

(ビットコインの)デジタル貨幣という側面より、もっと興味深く大きな意味をもつイノベーションは、その土台となっているブロックチェーンのテクノロジー。

という考え方は、いまやベイエリアの中心的な論調。ですので、ビットコインの貨幣的側面の規制を当局が検討したり、それがメディアで報じられても、まったくひるまずに、昨年後半あたりはブロックチェーン周辺のスタートアップにかなり投資がされています。

それらのスタートアップのサービスがこれから世の中に順次でてくるので、ブロックチェーンの仕組みについてはもう一段深く理解したいなと考えてました。その仕組みの概要や経済的な意味については、この日本語の記事のようにまとまったものはかなりでてきてますが、「どうしてこの仕組みにしたのか?」「この仕組みでなかったら、どういうリスクがでるのか?」...

OpenTable: APIのベンチマークと本番環境でのテスト

約3年前 | 1 point

OpenTableはその名の通りレストランの予約サービスを提供していて、(おそらく)最大手。スタンドアロンのアプリもありますが、USのレストランのサイトで予約をするときに、OpenTableの機能が組み込まれていることが多いです。

RunscopeのJohn SheehanとDropboxのSteve Marxがやっているポッドキャスト「Traffic and Weather」(APIとクラウドのネタを取り上げるのでこの名前にしたとのこと。)で、OpenTableの開発チーム(場所はUKにあるんですね。知らなかった。)のブログを紹介しています。

1) APIのベンチマーク試験

APIのパフォーマンスを比較するNode.jsツールapi-benchmarkとそのGruntラッパーgrunt-api-benchmarkをオープンソースで提供。(参考画面

正しくセットアップする。

  • ...

Airbnb: 最も利用されている機能がベストだとは限らない

約3年前 | 3 points

A/Bテストを繰り返したり、検索機能を磨いたりというのは、どのようなウェブ/アプリサービスでも注力するところではあると思いますが、Airbnbの取り組みを学んでいると、「自分のサービスにとってはどのような機能を選択肢に入れて、どのように選択するべきか。」については、当たり前に聞こえるかもしれませんが、よくよく考えて決めなくてはいけないポイントだと改めて認識させられます。

A/Bテストで、コンバージョン率の改善がすぐに見られた機能をサクっと選択してしまい、実は中期的にはコンバージョン率が変わらない(もしくは悪化する)可能性を確認しない。「ほとんどのユーザが価格帯順のソートを選択するから、検索機能は価格帯順の検索結果をデフォルト表示にすればよいだろう。」という意思決定をしてしまし(もちろんこれが正解なときもあります。)、他にベストな選択肢/検索ロジックがある可能性を追求しない。...

エンジニアチームでブランドを築く

約3年前 | 2 comments | 1 point

Nis Fromeのこのブログは示唆に富むものでした。

NisのチームがNew Yorkでハッカソンに参加したときのこと。慣れないテクノロジーに苦闘して、進捗が見えなくなってきた深夜3時、メール配信サービスのSendGridのエンジニア達が会場にやってきて、参加者に声をかけながら部屋をまわりはじめる。SendGridのDeveloper EvangelistであるMike Swiftから、「何か手伝える?」と言われた際に、SendGridのAPIを使ってるわけではなかったので、一旦は断る。しかし、彼は矢継ぎ早に質問を重ねてきて、Nisのチームがどのようなテクノロジースタックを利用してそのハッカソンの課題に取組んでいるかを把握。それから懇切丁寧に、Nis達はよく知らない分野だがその解決に役立ちそうなツールやリソースやベストプラクティスを解説してくれる。1時間かけて教えてくれた内容の多くは...

Rails wayにどこまで従うべきかという議論

約3年前 | 1 point

RailsでInteractorをうまく利用する」と「DHHとのピンポン」で紹介した議論をうけて立ち上がったサイト( http://www.dhh-ping-pong.com/ )で、DHHに挑戦するコードのピンポンが行われてます。

最初に取り上げられたAndrzej Krzywdaとのやりとりは、こちら。Andrzejのリファクタリングについてのオリジナルのブログはこちら

また、Andrzejは最新のブログの投稿で、その比較について解説しています。

  • 自分はコードとRailフレームワークとの関係をなるべく疎にすることで、リファクタリングしている。controll filterとmodel callbackは避ける。DHHは逆で、filterもcallbackも利用している。
  • また、レポジトリのパターンも利用することで、目的としてはロジックのフレームワーク依存をなくすこと。...

イラっとさせないUIの工夫

約3年前 | 1 point

カルーセルでスライドを順に見せるサイトがどうしても好きになれないのですが、この記事をみてはっきり自分がそう思う理由がわかりました。コンテンツに価値があるかどうかはっきりしないのに、待たなくてはいけないというシチュエーションにイラっとさせられるのだと思います。隠れているスライドが興味をそそるものであるかどうか判断つかないのに、それが表示されるまで待たなくてはいけない。ですので、ほとんど待たない。あと何枚スライドがあるかのインジケータがあっても、そもそも興味があるものかどうかわからないのでクリックもしないという悪循環。サービスを理解してほしいので、たくさん情報を提供したいというコンテンツプロバイダー側の意向と、サイトがちょっとだけ豪華に見えるというモチベーションはあろうかと思いますが、ユーザにはそれほど刺さらないかと。

そういう意味では、...

Stack Overflow: 技術的負債の必然性

約3年前 | 3 comments | 2 points

Stack ExchangeのエンジニアであるMarc Gravellがブログで、Stack Overflowのタグ検索のパフォーマンスをあげるために一時的に対応した迂回策を、時間をかけて修正していった経緯を紹介しています。「あまり褒められたやり方ではないけど、その時点ではそうするのがベストだった。」という負債はあるよねという話しです。

Step 0 : 背景

  • Stack Overflowでは、質問に紐づいたタグを検索(“{a} and {b} and {c}”, “{d} or {e}”, “{f} but not {y}” など)のうえ、該当する質問を抽出したり、検索結果ページを表示させる利用シーンが莫大にある。
  • 一般的にはPostsテーブル、Tagsテーブル、PostTagsテーブルを用意し、 PostTagsをかなり駆使すると思うが、それではパフォーマンスがよくない。...

Stripe: 支払フローのアニメーションの工夫

約3年前 | 1 point

StripeのUI DeveloperのMichael Villarが、同社のサービスの生命線である支払フローにおけるデザイン上の工夫を紹介しています。支払フローはユーザの離脱の可能性が高い箇所なので、ストレスを減らす工夫は効果が期待できそうですね。

1) アニメーションで文脈を補完する

gif version | MP4 version

支払のために入力した個人情報を再利用したいときのために「Remeber Me」のチェックボックスが用意されてます。それをチェックするとはじめて、Helpページへのアイコン、「安全のために携帯番号を入力ください。」という入力ボックスがアニメーションで表示されます。このタイミングで表示することにより、何のために携帯番号の入力をお願いしているのかが、ユーザにわかりやすくなります。

2) 画像をシェークさせてエラー表示する

gif version | MP4...

モバイルAPIデザインのまとめ

約3年前 | 1 point

Natasha Murashevがブログで、API Strategy and Practice Conferenceにおける、Michele Titolo (先月、「Ruby RoguesメンバとiOSエンジニアのAPI議論」で紹介しました。)とEtsyのPaul Wrightの講演のポイントをまとめてくれています。

1) スピード

  • ユーザは待ってくれない。300msで、リクエスト / レスポンスの処理 / ユーザに結果の表示をする。

2) RESTが常にベストとは限らない

  • 以前のEtsyのAPIリソースはDBスキーマのミラーになっていた。クライアントがリスティングのリストを受け取ったら、ユーザがFavoritedに指定しているリスティングIDを取得するために、再度APIコールする必要があった。クライアントのAPIコールが増えると、クライアントのスピードが落ちる。...