pointSourcegraphは、Goで書かれたオープンソースのソースコードサーチエンジン。Code等を検索し、表示されたコード上でfunction名などをクリックすると、そのドキュメントと他の利用事例のコードが確認できます。Rubyをサポートしていて、近々Javaもカバーするようになるようです。APIの公開は準備中とのこと。Slackが、Goアプリのテストをテーマに講演しています。DBへのSQLクエリを構築し、データに対するアルゴリズムも実行。データストアからデータを取得。HTTPキャッシュの役割を担う。APIからデータを取得し、HTMLテンプレをレンダリングする。コードを再利用したいと皆言うけれども、いざ実践となるとなかなかうまくいかない。ことの背景の解説とその解決策の方向性について、キャラクターアニメーションパッケージの開発を通じてCaseyが学んだことをシェアしてくれています。10年経っても変わらず、またゲーム以外の開発においても、当てはまることが多いかと。インテグレーションのオプションあるコンポーネントをAPIを用意してゲームに組み込むインテグレーション作業と、その作業がどれだけゲームの完成に効果がある(ゲームプレイの完成という意味だけでなく、インテグレーション作業が進むと、「メモリがしっかり管理できるようになる。」「パフォーマンスが向上する。」など、技術的に完成度があがることを指す。)かどうかという相関関係を考えてみる。2014での講演です。Rubyアプリのユースケースの場合の、概要/ツール紹介/デモです。ここでは、後半に語られているDockerのバリューについて、まとめてみます。デリバリーの単位Rubyエンジニアとして、デリバリーするときの単位という概念が今まではなかった(が、Dockerで実現できた)。JRubyでしばらく開発していたときがあって、その際は、jarファイルの中身がなんであれ、テストして問題なければ、DevOpsチームに渡すだけ。ある意味それはそれでよかったけど。CRubyだとそのようにはいかず、.devファイルやディスクのファイルなどにパッケージするのにトライした人はわかるだろうが、それほど簡単にはいかない。InfoQで紹介されてました。前提条件1日最大420億件のトランザクション。(スライドの数値は誤りとのこと。)相当な並列処理が必要。system(遅延すると計算結果の価値はなくなるが、システム全体にとっては深刻な状況にはならないこと。Labsが、Dockerイメージは1Gを超えることがよくあって、ローカルで実験しているうちはよいが、ネットワークを介して頻繁にやり取りしはじめると、サイズが問題になる。いうことで、dockerイメージのサイズを減らす取り組みについて、ブログで紹介しています。Layersレイヤの構成の詳細については、Dockerのドキュメントを参照されたし。本議論のポイントとして理解しておかなくてはいけないのは、Dockerfileでの各操作の結果、新しいイメージのレイヤが順次生成されるということ。イメージとレイヤを別物として議論していることが多いが、実はレイヤもイメージであり、イメージを構成するレイヤ群は、イメージの集合体である。レイヤ)のサイズの合計である。Scalaの利用について、講演しています。Application)のホストとするパターンの二つを紹介。Playにはフロント側のコードを置かない。APIのクライアントという位置づけになる。2014のキーノートスピーチです。Jeffは、オブジェクト指向言語によるプログラムの最適化で博士号を取得。DEC/Compaqの研究所の勤務をへて、1999年にGoogleに入社。Brainなど、同社の大規模分散システムの構築に一貫して携わってきています。Booksなどのサブシステムへのクエリを走らせ、その計算結果を短時間でまとめなくてはいけないチャレンジがある。Mauboussinによる、成功することにおけるスキルと運の関係についての講演。平均の人とよくできる人の差分、つまり標準偏差がどうなっていて、自分がその中でどこに位置するか。それが時系列でどう変化していくかが、運次第なのかスキル次第なのかに影響するというロジック。自分の携わる業界、会社、自分の担当分野などに当てはめて分析してみると相当面白そうです。世の中には、宝くじやルーレットのように完全に運頼みでスキルが関係ないものや、プロスポーツのようにスキルの重要度が高いものまで様々。「わざと負けることができる。」のであれば、スキルが結果を左右する要素があるということ。議論の前提となる三つのポイントの最初は、偉大なスポーツ選手は卓越したスキルと運を兼ね備えると言われる。DiMaggioは、生涯打率も3割2分5厘。Aboukhadijehは、手がけていたPeerCDNをYahoo!に売却したため、そのままYahoo!に入ったようですが、当時の「BitTorrrentをプラグインのないブラウザベースでつくろうと思っている。サーバがなく、トラックできないBitTorrentになる。」というアイデアは、そのままWebTorrentプロジェクトというかたちで継続しているようです。2014での講演でWebTorrentの進捗についてアップデートしてくれています。ちなみに、BitTorrentについてはこちらにわかりやすくまとまっていますが、まず、.torrentファイルをwebサーバ等から取得。STATSが話題になったからでしょうか、自社のCSSの構成を分析して、記述方針について紹介するポストが続いています。Planetは旅行サイトらしく、写真/動画満載の構成です。(gzip)基本的には、remとpixelでサイズ指定。PreprocessorRailsを使っているが、Sprocketsは利用せずに、Saasの@import機能でスタイルシートをつくっている。pointsPinterestもものすごい規模になってきましたね。1日当たり20TBの新しいデータ。S3には約10PBが保存されている。同社ではこのデータの処理にHadoopを利用していますが、毎日100人以上が、Quoboleが提供するダッシュボードを使って、2,000件以上のジョブを実行。3,000個のノードで構成される6つのHadoopクラスタを利用。エンジニアは数分で専用のクラスタが立上げ可能。毎日のログデータは、200億件。このグラフによると、Pinterest全体のMapReduceクラスタのデータ処理総数/日は、800TBに近づいている。Robertsがブログで、CSSのプロジェクトをうまくスケールさせるためには、詳細度の影響をうまく抑えて、メンテナンス性を高めることがポイントだと解説しています。どれだけ思慮深くソースの順や継承関係を整理しても、詳細度がトリガーになった上書き起きると、それまでの努力が台無しになる。詳細度のタチが悪いのはオプトアウトできないこと。あるが、その悪影響をうまくコントロールする策としては、CSSにおいてセレクタとしてIDは使わないこと。クラスを使うことを上回るメリットはない。そもそも、IDでできることはクラスでできる。IDは再利用が効かないし、詳細度がとにかく高過ぎる。クラスを無限につなげても、一つのIDの詳細度にはかなわない。セレクタを不必要にネストさせないこと。