デザインアセットをiPhone6に対応するワークフロー

3年弱前 | 1 point

発表されたiPhone6のサイズからして、予想はしてましたが、MerchbarのEdward Atenがまとめてくれたブログを読むと、改めて対応の工数を認識させられます。

iPhoneのレイアウト/解像度がどう変更されてきたか

  • iPhone3 - iPhone4: キャンバスのサイズは 320x480 pointsと同じなのでレイアウトは変更なし。解像度が 640x960 pixelesに倍増するので、アセットをアップグレードする対応。
  • iPhone4 - iPhone5: キャンバスが縦方向に伸びて 568 pointsに。内製のアセット(tabバー / statusバー / バナー)は topとbottomが揃っているので、間を少し伸ばすだけで対応可能。
  • iPhone5 - iPhone6: レイアウトと解像度を両方変更することになる。

iPhone6のケース

  • 解像度は@2xのままだが、...

ブログのグラフィックデザインに便利なツール

3年弱前 | 2 comments

Wazanova Newsは、モノトーンでシンプルなサイトにしたいので、意識的に画像を全く使わないのですが(読みやすさとか、アクセスの喚起とかの法則には反するのですが、個人的な趣味でそういう方針にしてます。読みづらいと思ってる方はすみません。。)、もしグラフィックを使うなら、このNathan Barryのブログで紹介されてる一連のテクニックが多いに役立ちそうです。Mediumのブログのようにできますね。興味深いので、ブックマーク代わりにメモ残しておきます。

Nathanのような、効果的な画像コンテンツをつくれるようになるワークショップも、各地で開催しているようです。

1) フリーの写真素材

Deviseでの二段階認証

3年弱前 | 1 point

LonelyPlanetは、devise_google_authenticatorを使って、Railsアプリ向けの認証管理ができる deviseGoogle Authenticatorを利用できるようにしているとのこと。

Google Authenticatorアプリの仕組みは、

  • QRコードを読込んで、モバイル端末上のGoogle Authenticatorアプリに、認証の対象としたいサービスを登録する。
  • 以降、認証の対象としたいサービスで、ID/パスワードの次に、トークンの入力が求められる。
  • Google Authenticatorアプリを開き、一覧の中から該当サービスのトークン(30秒間有効な6-8桁の数字)を選び、入力する。

devise_google_authenticator を実装する際の留意点として、

  • 無効なリクエストがくると root_pathにリダイレクトされる前提だが、...

サイトパフォーマンス: 1000msを目指す取組み

3年弱前 | 2 comments | 2 points

Guardian誌のPatrick HamannがLondon Web Performance Meetupで、モバイルサイトのパフォーマンス向上の取組みについて講演しています。

まずは、Web Performance TodayのeCommerceに関する調査で、

ユーザの期待するページ読込み時間は、2000年の8秒から、2012年には2秒を切るレベルまで下がってきている。

ことを挙げ、1秒以下を達成するには、

  • 3Gネットワークでは、DNS Lookup / TCP Connection / HTTP Request & Responseで 600ms (Guardianのある英国ではそれ以上)はかかる。残りの400msで、Server Response TimeとClient-side Renderingを最適化する必要がある。

...

Squareの内部APIの仕組み

3年弱前 | 2 points

SOAにおけるサービス間のコミュニケーションについては、CODE CLIMATEにおいて、Protocol Buffers vs JSONという比較が取り上げられていて、「ブラウザやJavaScriptが直接データを利用しないケース、特に内部サービス間のコミュニケーションにはProtocol Buffersの方が向いているのでは。」と紹介されています。

  • せっかく整合性のあるデータ構造を用意しても、サービス間のデータのやり取りの際に苦労させられることが多い。Protocol BuffersならProtoフォーマットにしてエンコーディングするだけで、意図するビジネスルールを維持できる。
  • 番号のフィールドがあるので、バージョンのチェックが不要。後方互換性を担保するために、コードの振る舞いを変更するような事態を避けられる。
  • 例えば、RubyとJSONのエンコード/デコードでは、...

コードを引継いでどこから手をつけるか

3年弱前 | 4 points

他人から引継いだコードを把握するのにどこから着手するかというテーマで、たまたまいくつかのエントリーを見かけました。「コードを読み切れないほど膨大にある。」「前任者、経緯のわかる人がいる/いない。」「ドキュメントがある/ない。」など様々な事情が想定されますが、全部まとめて主な声を拾ってみました。

  • 謙虚な姿勢で臨むこと。そのコードベースがわかりづらいのは、書き方が悪いコードだからかもしれないが、自分がその専門領域の知識がなかったり、ベースにあるアルゴリズムが本当に複雑な場合もありうる。それを、全てコードが悪いと思い込むと、自分にとってストレスだし、周りにも迷惑がかかる。
  • テストが完璧に用意されたコードはおそらくほとんどない。テストを追加、もしくは改善するという作業から着手すると、本番サービスに影響与えることなく、理解も進むし、コードの質も上がる。
  • 小さなタスクをこなして本番にアップしてみる。...

Yelp: git hookのためのマルチ言語対応パッケージマネジャ

3年弱前 | 1 point

Yelpでは、コードレビュー前にgit hookを利用してコードのチェックをしていますが、

  • プロジェクトごとにhookのbashスクリプトをコピペ/修正するのが面倒。
  • lintツールなどを利用するには、プロジェクトで使っている開発言語以外の言語用のパッケージマネジャーでインストールしなくてはいけないケースがある。
    • nodeのプロジェクトで scss-lint(Rubyで書かれている。)を利用する際、プロジェクトにGemfileを追加せずに、もしくはインストール方法を気にせずに利用できるようにしたい。
    • nodeをインストールしてなくてJavaScriptファイルを修正している際に、root権限なしでnodeをインストールして、JSHintを実行できるようにしたい。

という課題を解決してくれる、git hookのためのマルチ言語対応パッケージマネジャ「pre-commit」をオープンソースで公開...

LivingSocial: SOAのテストとmockの工夫

3年弱前 | 2 points

LivingSocialのRailsアプリSOAシリーズの5回目として、サービス指向アーキテクチャにおけるテストのあり方についての話。

まずは、アプリ間のサービスコールを全てmock/stubしたり、逆に依存関係を常にそのまま利用するのではなく、1回だけコールする手法を推薦しています。

テスト対象のコードは、依存するサービスに一度だけコール & レスポンスを記録し、その後の実行ではリプレイを利用する。

  • メリット
    • ネットワークコールが一度で済むので時間がかからない。
    • 実際のサービス環境、APIを反映したテスト結果を取得できる。
    • レスポンスデータが取得できれば、後は、依存するサービスをローカルで実行(時にはインストールも)する必要がなくなる。
  • リスク
    • 依存しているサービスが多い、もしくは大量のデータをリクエストするかたちだと、記録するレスポンスのデータが大きくなる。
    • ...

Flickr: キャッシュウォーミングで配信スピードをアップする

3年弱前 | 2 points

Flickrには膨大な写真データがあり、かつアクセス頻度は、超人気の写真から、ほとんど見られないプライベートな写真まで様々あり。よって、ユーザに快適な閲覧体験を提供するには、世界各地に適切にキャッシュを配置することが大切。

今回はそれを一歩進めて、キャッシュウォーミングで配信スピードを更にアップさせています。

まず通常(& 従前)のケースでは、

  • 1. ユーザのブラウザが特定の写真とサイズを米国のデータセンタにリクエストする。
  • 2. データセンタから、ユーザのブラウザにフィットする、指定されたサイズの写真の所在をURL情報で返す。
  • 3. キャッシュされていれば、一番近くの地域のデータセンタからキャッシュを読込む。
  • 4. キャッシュされてなければ、米国のデータセンタから読込む。

となりますが、キャッシュウォーミングでは、キャッシュがない場合でも、4. よりも短い時間での読込みを実現します。...

エンジニアの給与レベルがプロスポーツ化する日

3年弱前 | 3 comments | 2 points

先ほど、ワザノバのアクセスランキングをつくっていて、「給与を上げるベストな仕組みの解がない」が意外に上位ランクに入ってました。我ながら振返ってみて、タイトルも内容もネガティブ過ぎたかなとちょっと反省してます。その時は、休日に家族をスキーに連れて行ったのですが、自分は滑らずにスタバで原稿を書いていたので、そのストレスだったかもしれません(笑)

お伝えしたかったのは、

  • 業界全体の「平均」給与レベルを上げることの難しさ。
  • テクノロジーの変遷が早いので、職業市場における自分の相対価値が下がらぬよう、努力を続けなくてはいけない。

でしたが、話がそこだけに終始してたので、今日は少しポジティブな話を。

ウェブ/アプリエンジニアのこれから先の未来は、才能があり、かつ努力した人は金銭的にもっと報われるようになると考えてます。

最近のFacebookの買収案件で非買収企業の社員が受取る価値を単純に平均で計算すると、...

そろそろ1周年になります

3年弱前 | 3 points

昨年の8月の最終週に、最初の投稿をアップしたので、そろそろ1周年になります。

これまでアクセスの多かった記事をピックアップしてみました。もう既に「懐かしい。」と思う記事もあるので、この分野の動きの早さを実感できます。

ワザノバの記事を社内外にご紹介してくださった皆様、もろもろサポートしてくださった皆様にお礼申し上げます。引き続き、web/アプリサービスづくりに役立つ情報という視点で発信していきますので、2年目もよろしくお願いいたします。


1. GitHubの組織が成長する過程で変えたことと変えなかったこと

2. NTPベースのDDoS攻撃を理解する

3. 給与を上げるベストな仕組みの解がない

4. 何でもデバッグできるようになるスキル

5. 規模の大きい本番システムをGo言語で書き直した感想

6. RubyとPythonの違いからガベージコレクタを理解する

7. WebRTC:...

Groupon: アナリティクスシステム改善の取組み

3年弱前 | 2 comments | 1 point

GrouponのEngineering ManagerであるChris Powersが、同社のGeekfest Chicago Eventで、アナリティクスシステム改善の取り組みを紹介しています。

年半前に改善の取り組みを開始

  • 事業の拡大に伴ってアナリティクスの需要は、CEOへの報告から、マーケ/開発の現場の利用、データサイエンティストの分析まで様々。しかし、各チームがバラバラに複数のアナリティクスシステムを運用していて、オーナーシップを取るチームはなし。
  • トラッキング用にページあたり20-30ピクセルを仕込んでいて、つまりユーザ当たり 20-30 GETリクエスト / ページとなり、サーバ負荷が過大。
  • 「全てをトラックする。」を目標に内製のアナリティクスシステムの整備にとりかかる。

システム構成

web/アプリとバックエンドの関係図(ビデオ 10:20〜

アナリティクスデータの収集ルート図(...