Sourcegraph: Goアプリのテスト

約3年前 | 1 point

Sourcegraphは、Goで書かれたオープンソースのソースコードサーチエンジン。GitHub、Google Code等を検索し、表示されたコード上でfunction名などをクリックすると、そのドキュメントと他の利用事例のコードが確認できます。現在は、Go / Python / JavaScript / Rubyをサポートしていて、近々Javaもカバーするようになるようです。APIの公開は準備中とのこと。

同社のQuinn Slackが、Goアプリのテストをテーマに講演しています。

最初の構成

  • データストア: DBへのSQLクエリを構築し、データに対するアルゴリズムも実行。
  • HTTP API: データストアからデータを取得。HTTPキャッシュの役割を担う。
  • webフロントエンド: APIからデータを取得し、HTMLテンプレをレンダリングする。

以前のテスト

  • DBに接続して、...

再利用性を高めるAPIの設計と見極め

約3年前 | 3 points

Casey MuratoriのGameTech Conference 2004での講演。

コードを再利用したいと皆言うけれども、いざ実践となるとなかなかうまくいかない。

ことの背景の解説とその解決策の方向性について、キャラクターアニメーションパッケージの開発を通じてCaseyが学んだことをシェアしてくれています。10年経っても変わらず、またゲーム以外の開発においても、当てはまることが多いかと。

インテグレーションのオプション

あるコンポーネントをAPIを用意してゲームに組み込むインテグレーション作業と、その作業がどれだけゲームの完成に効果がある(ゲームプレイの完成という意味だけでなく、インテグレーション作業が進むと、「メモリがしっかり管理できるようになる。」「パフォーマンスが向上する。」など、技術的に完成度があがることを指す。)かどうかという相関関係を考えてみる。...

Dockerのメリットと可能性

約3年前 | 2 points

Code ClimateのBryan HelmkampのRedDotRuby 2014での講演です。ビデオの前半の30分は、Docker + Rubyアプリのユースケースの場合の、概要/ツール紹介/デモです。ここでは、後半に語られているDockerのバリューについて、まとめてみます。

デリバリーの単位

Rubyエンジニアとして、デリバリーするときの単位という概念が今まではなかった(が、Dockerで実現できた)。かつて、JRubyでしばらく開発していたときがあって、その際は、jarファイルの中身がなんであれ、テストして問題なければ、DevOpsチームに渡すだけ。ある意味それはそれでよかったけど。一方、CRubyだとそのようにはいかず、.devファイルやディスクのファイルなどにパッケージするのにトライした人はわかるだろうが、それほど簡単にはいかない。

AdRoll: 420億件/日の取引をさばくRTBプラットフォームの計測

約3年前 | 3 points

RTB (Real-time Bidding) のテクノロジーを利用した広告リターゲッティングのプラットフォームを提供するAdRollのエンジニア、Brian TroutwineのErlang Factory 2014での講演。InfoQで紹介されてました。

前提条件

  • 1日最大420億件のトランザクション。(スライドの数値は誤りとのこと。)相当な並列処理が必要。
  • 遅延(= 取引の完了期限)は100ms以下
  • Firm real-time system(遅延すると計算結果の価値はなくなるが、システム全体にとっては深刻な状況にはならないこと。ちなみに、高度の安全性が求められる航空システムは、遅延すると計算結果の価値はなくなるだけでなく、状況によっては深刻な事態になる可能性があるので、”Hard real-time system” と呼ばれる。遅延しても計算結果の価値がなくならないケースの場合は、”...

Dockerイメージの最適化

約3年前 | 1 point

米国キャリアのリサーチ部門であるCenturyLink Labsが、

Dockerイメージは1Gを超えることがよくあって、ローカルで実験しているうちはよいが、ネットワークを介して頻繁にやり取りしはじめると、サイズが問題になる。

ということで、dockerイメージのサイズを減らす取り組みについて、ブログで紹介しています。

Layers

  • レイヤの構成の詳細については、Dockerのドキュメントを参照されたし。本議論のポイントとして理解しておかなくてはいけないのは、Dockerfileでの各操作の結果、新しいイメージのレイヤが順次生成されるということ。
  • イメージとレイヤを別物として議論していることが多いが、実はレイヤもイメージであり、イメージを構成するレイヤ群は、イメージの集合体である。

Image size

  • イメージのサイズとはそれを構成する各イメージ(= レイヤ)のサイズの合計である。
  • 各操作は、...

エンタープライズ向けにPlay + Scalaを活用する

約3年前 | 1 point

ウォルマートカナダの開発を担当したKevin Webberが、エンタープライズ向けの開発を前提としたPlayフレームワーク + Scalaの利用について、講演しています。

まずUIまわりのアーキテクチャについて、PlayをAPIとして利用するパターンと、Playを複数のSPA (Single Page Web Application)のホストとするパターンの二つを紹介。

1) UIを物理的に分ける

構成図例(ビデオ 6分40秒時点

  • PlayフレームワークをRESTful APIとして使う。Playにはフロント側のコードを置かない。各UIは、Play APIのクライアントという位置づけになる。
  • この場合のUIの選択肢は、
    • JavaScriptフレームワーク、HTML5/CSS/Javascript etc.
    • ネイティブモバイルアプリ
    • 標準的なwebプロトコルで通信できるものであれば何でもあり
  • ...

大規模分散システムのレスポンスを向上させる工夫

約3年前 | 3 points

GoogleのJeff Dean(Senior Fellow, システム & インフラグループ)による、Velocity Conference 2014のキーノートスピーチです。

Jeffは、オブジェクト指向言語によるプログラムの最適化で博士号を取得。DEC/Compaqの研究所の勤務をへて、1999年にGoogleに入社。以降、BigTable / MapReduce / Spanner / Google Translate / Google Brainなど、同社の大規模分散システムの構築に一貫して携わってきています。

例えば、検索結果のレスポンスを向上させるには、その裏で、Web / Images / Local / News / Video / Blogs / Booksなどのサブシステムへのクエリを走らせ、その計算結果を短時間でまとめなくてはいけないチャレンジがある。

...

運と実力を科学する

約3年前 | 2 points

Michael J. Mauboussinによる、成功することにおけるスキルと運の関係についての講演。

平均の人とよくできる人の差分、つまり標準偏差がどうなっていて、自分がその中でどこに位置するか。またそれが時系列でどう変化していくかが、運次第なのかスキル次第なのかに影響するというロジック。自分の携わる業界、会社、自分の担当分野などに当てはめて分析してみると相当面白そうです。

世の中には、宝くじやルーレットのように完全に運頼みでスキルが関係ないものや、プロスポーツのようにスキルの重要度が高いものまで様々。「わざと負けることができる。」のであれば、スキルが結果を左右する要素があるということ。

議論の前提となる三つのポイントの最初は、

偉大なスポーツ選手は卓越したスキルと運を兼ね備えると言われる。1941年に56試合連続ヒットを達成したJoe DiMaggioは、生涯打率も3割2分5厘。さらに、...

WebTorrent: サーバなしでPtoP接続を実現する

約3年前 | 1 point

昨年、「WebRTC: サーバのない世界でwebをつくり直す」で紹介したFeross Aboukhadijehは、手がけていたPeerCDNをYahoo!に売却したため、そのままYahoo!に入ったようですが、当時の「BitTorrrentをプラグインのないブラウザベースでつくろうと思っている。サーバがなく、トラックできないBitTorrentになる。」というアイデアは、そのままWebTorrentプロジェクトというかたちで継続しているようです。

そのFerossが、ハンガリーで開催されたCraftConf 2014での講演でWebTorrentの進捗についてアップデートしてくれています。

ちなみに、BitTorrentについてはこちらにわかりやすくまとまっていますが、

  • まず、.torrentファイルをwebサーバ等から取得。このファイルには手に入れたいデータの各ピースのハッシュと、...

Lonely Planet & GitHub: CSSの構成と方針

約3年前 | 1 point

CSS STATSが話題になったからでしょうか、自社のCSSの構成を分析して、記述方針について紹介するポストが続いています。

1) Lonely Planet

Lonely Planetは旅行サイトらしく、写真/動画満載の構成です。

Quick Facts

  • Sass Indented Syntax
  • 150+ソースファイル
  • キャッシュを考慮してコンパイルしたCSSは二つのスタイルシートに
  • CSSはページ当たり35kb (gzip)
  • 基本的には、remとpixelでサイズ指定。一部 em あり。

Preprocessor

  • Railsを使っているが、Sprocketsは利用せずに、Saasの@import機能でスタイルシートをつくっている。
  • Saasの機能は variable と一部で mixin くらい。
  • classよりplaceholderをextendするアーキテクチャを好んで使っていたが、...

PinterestのHadoopインフラ

約3年前 | 2 points

Pinterestもものすごい規模になってきましたね。

1日当たり20TBの新しいデータ。Amazon S3には約10PBが保存されている。

同社ではこのデータの処理にHadoopを利用していますが、

  • 毎日100人以上が、Quoboleが提供するダッシュボードを使って、2,000件以上のジョブを実行。
  • 3,000個のノードで構成される6つのHadoopクラスタを利用。エンジニアは数分で専用のクラスタが立上げ可能。
  • 毎日のログデータは、200億件。約1TBに達する。
  • このグラフによると、Pinterest全体のMapReduceクラスタのデータ処理総数/日は、800TBに近づいている。

Hadoopで自社サービスを立ち上げるための要件

Hadoopは、クラウドの利用や非エンジニアユーザの使用を前提にしたつくりではないので、Pinterest内で社員が使いこなせるソリューションにするために、...

CSSの詳細度をうまく操る

約3年前 | 2 points

Harry Robertsがブログで、CSSのプロジェクトをうまくスケールさせるためには、詳細度の影響をうまく抑えて、メンテナンス性を高めることがポイントだと解説しています。

どれだけ思慮深くソースの順や継承関係を整理しても、詳細度がトリガーになった上書き起きると、それまでの努力が台無しになる。詳細度のタチが悪いのはオプトアウトできないこと。

であるが、その悪影響をうまくコントロールする策としては、

  • CSSにおいてセレクタとしてIDは使わないこと。クラスを使うことを上回るメリットはない。そもそも、IDでできることはクラスでできる。IDは再利用が効かないし、詳細度がとにかく高過ぎる。クラスを無限につなげても、一つのIDの詳細度にはかなわない。
  • セレクタを不必要にネストさせないこと。.header .header-nav {}は、セレクタの詳細度を意味なく倍にしてしまうので、もし...