分散システム設計のチェックリスト - ワザノバ | wazanova
http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか？その障害がゆっくりと起きたらどうか？ システムをどのようにスムーズにデグレードさせることができるか？ システムは想定以上の負荷にどう対処するようになっているか？ 大きな障害が起き
スケールするサービスでの最新オペレーション事例 - ワザノバ | wazanova
https://www.youtube.com/watch?v=B1Wt8s4LEfk 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 10/29に開催されたSecurity@Scaleのカンファレンスで、興味深いと思った話題を拾ってみました。 SquareのDiogo Monicaの講演は、障害/脆弱性に対応する社内システムをどのように自動化 / 最適化させてきたかというテーマ。 脆弱性の種別（XSS等） x セキュリティゾーン（システムのどの箇所にとって脅威になるかを3段階に分類。DBに近い方が危険性が高い。）でスコア化することで、対応のために発行されるチケットは自動的に優先付けされる。 SLA（サービスレベルアグリーメント）において、例えば、P0は24時間以内、P1は7日以内、P2は30日以内と
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
Facebook: iOSアプリのアーキテクチャ - ワザノバ | wazanova
https://www.youtube.com/watch?v=XhXC4SKOGfQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 39分前 FacebookのiOSチーム、Adam ErnstとAri Grantによる@Sacle 2014での講演。データモデルとビューレイヤの改善の取組みについて紹介してくれてます。 1) データモデル 背景 2年前からHTML5からネイティブに切り替えて一旦大きく改善したが、その後機能を追加するたびにアプリのパフォーマンスが悪化。 ネイティブに移行後、オブジェクトのキャッシュレイヤとしてiOSのCore Dataを使ったのが失敗であった。 Core Dataの役割は「整合性を含むオブジェクトグラフ管理」 Facebook iOSアプリの場合、サーバ側を正のデータとするが、
シングルページアプリづくりのJavaScriptフレームワーク比較 - ワザノバ | wazanova
http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 開発言語やフレームワークの比較は、参考になるところはありつつも、その結果、不愉快な気分になる人がいるわけですが、それを懸念して、「（これを読んだ人は、他人の）意見を読んでいるだけだと思い返してほしい。貴方にどうすべきだと言ってるのではなく、自分にもしくはチームのために何がよいかは自分で判断すべきこと。」と前置きして、Henrik Joretegが、JavaScriptフレームワークについて私見をシェアしています。 反対意見も併記しようと思ったのですが、TwitterやHNでの反応がまだないようなので、注目すべきコメ
再利用性を高めるAPIの設計と見極め - ワザノバ | wazanova
https://www.youtube.com/watch?v=ZQ5_u8Lgvyk 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Casey MuratoriのGameTech Conference 2004での講演。 コードを再利用したいと皆言うけれども、いざ実践となるとなかなかうまくいかない。 ことの背景の解説とその解決策の方向性について、キャラクターアニメーションパッケージの開発を通じてCaseyが学んだことをシェアしてくれています。10年経っても変わらず、またゲーム以外の開発においても、当てはまることが多いかと。 インテグレーションのオプション あるコンポーネントをAPIを用意してゲームに組み込むインテグレーション作業と、その作業がどれだけゲームの完成に効果がある（ゲームプレイの完成とい
AdRoll: 420億件/日の取引をさばくRTBプラットフォームの計測 - ワザノバ | wazanova
https://www.youtube.com/watch?v=qURhXHbxbDU&list=UUKrD_GYN3iDpG_uMmADPzJQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 RTB (Real-time Bidding) のテクノロジーを利用した広告リターゲッティングのプラットフォームを提供するAdRollのエンジニア、Brian TroutwineのErlang Factory 2014での講演。InfoQで紹介されてました。 前提条件 1日最大420億件のトランザクション。（スライドの数値は誤りとのこと。）相当な並列処理が必要。 遅延（= 取引の完了期限）は100ms以下 Firm real-time system（遅延すると計算結果の価値はなくなるが、システム全体にとっては
エンタープライズ向けにPlay + Scalaを活用する - ワザノバ | wazanova
ウォルマートカナダの開発を担当した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プロトコルで通信できるものであれば何でもあ
Gilt: Playフレームワークの活用 - ワザノバ | wazanova
https://www.youtube.com/watch?v=WliXLG2Yo5k 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 GiltにおいてPlayフレームワークをどのように活用しているのか、Giancarlo Silverstrinが紹介してくれています。 単一のRailsアプリからマイクロサービスに切り替える過程で、JVM + Java -> JVM + Scalaと開発基盤を変遷。現在、本番環境には、250+サービス。 マイクロサービスへの展開時には、バックエンドのRailsアプリは残すかたちで既存の資産の有効活用。webレイヤでには75+個のアプリ（コード約7万行）がある。リソースとUIテーストを共有したアプリの組み合わせで、Giltのサイトは構成されている。 フラッシュセール（毎
API設計のポイント - ワザノバ | wazanova
Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス（success/error）をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか？PUTで使うか？ 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで？ ヘッダー？もしくはURLパラメータ？ リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント（/inventory
Flickr: スライドショーとHTML5ビデオを採用したトップページ - ワザノバ | wazanova
http://code.flickr.net/2014/04/23/building-flickrs-new-hybrid-signed-out-homepage/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 Flickrの非ログインユーザ向けのトップページは、縦型のスライドショーの構成。スライドを移動する度に、各ページ上に表示されているモバイル端末の画面内でHTML5ビデオが再生されるようになっています。（デモビデオ） その機能と工夫について、同社のエンジニアブログで紹介しています。 1) 機能概要 スライドショー的なUI: PC/タブレット画面向けには、scale3d()とzoomベースでスケールするコンテンツを提供。 インラインHTML5<video>、retina/hi-DPIスケール（フ
モバイルAPIデザインのまとめ - ワザノバ | wazanova
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コールが増えると、クライアントのスピードが落ちる。また障害の可能性となるポ
Scaling Agile @ Spotify を読み直す（その１） - ワザノバ | wazanova.jp
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf 1年前、同僚のエンジニアがSpotifyのこのペーパーにまとめられている開発体制を絶賛してたのですが、当時はちょっとピンとこなかった記憶があります。流行の概念を取り込んだうえに、マトリックス組織を更に複雑にしたような構成が、実務上うまくワークするのかどうかよくわからなかったからです。その後の自分の経験をへて、腹おちする仕組みなのかどうかを確認するために、改めてこのペーパーをまとめ直してみます。 昨年このレポートが書かれた時点で、開発部隊は３都市30チームの構成 Squad 開発の基本的な組織単位。スクラムチームに似た概念で、ミニスタートアップのような位置づけ。同じ場所で仕事をし、開発、テストから本番アップまで担うスキルがある。 自立した組織として運
Gilt: 単一のRailsアプリから複数のScalaアプリへの移行 - ワザノバ | wazanova
http://tech.gilt.com/post/73434506726/scaling-gilt-at-gilt-nyc-tech-talks-comes-to-2-park 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 GiltのYoni Goldbergが、同社のアプリが、RailsベースからScalaに移行しスケールしてきた経緯を紹介しています。 Videoがでたら是非紹介したいと思っていたネタですが、1ヶ月待ってもアップされないので、ひとまずあきらめてスライドの紹介だけになります。もしビデオがアップされたら改めて更新します。 2007年の典型的なスタートアップ。サービスをとにかくなるはやでローンチするために、当時盛り上がってきていたRailsを採用。 2009年、フラッシュセール開催時の
Discourse: 大規模オープンソースRailsプロジェクトの進捗 - ワザノバ | wazanova
http://rubyrogues.com/117-rr-discourse-part-2-with-sam-saffron-and-robin-ward/ 以前、「Discourse : パフォーマンス向上に注力したRubyアプリづくり [GoGaRuCo 2013] 」でも紹介したDiscourseのSam SaffronとRobin Wardが、Ruby RoguesのPodcastで、オープンソースになっているRailsアプリとしては最大級になってきた同プロジェクトの開発の状況をアップデートしています。 最初から、APIで100%カバーするつもりでサイトづくりをしている。パスワードリセットなど一部サーバサイドでレンダリングしているものはあるけど。 Ember.jsを採用した背景は、以前のプロジェクトで、 jQueryで相当リッチなサイトをつくったがコードをまとめるのが大変になった経
Githubの組織が成長する過程で変えたことと変えなかったこと - ワザノバ | wazanova
GithubのZach Holmanが語るGithubの組織戦略です。まず最初に、 Step #1: ロックスターエンジニアを雇う Step #2: ものすごく透明性のある経営をする Step #3: ブログ/ソーシャルメディアなどでテクノノロジーについて発信する Step #4: カンファレンスで会社について話す Step #5: カネに余裕ができる Step #6: 社員を大勢雇う Step #7: 会社のことを話さなくなる Step #8: コミュニティを無視する Step #9: 創業者が株を売って儲ける Step #10: 別の会社をはじめる という事例を挙げて、Githubは組織が成長する中で、このようなパターンに陥らないように、コミュニケーション及び仕事の進め方をどのように進化させてきたかについて紹介してます。 Dunbar's numberとしてよく知られるとおり、人間が良
Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp
https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン
スケール可能なTwitterの負荷テストの仕組み [GTAC 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=99RABfKNfcY [Slide] http://goo.gl/9VY2b TwitterのJames Waldropが、オープンソースのロードジェネレータライブラリlagoと、スケールが可能な負荷テストの仕組みについてGTAC (Google Test Automation Conference) 2013で語ってます。Twitterには本番トラフィックの一部を利用したテストもありますが、本講演ではテスト環境でのロードジェネレータを話題にしてます。 FacebookからTwitterに転職し、lagoをつくった理由は、 ありあわせのツールをもってきて使ってもだめで、エンジニアであれば何か開発しないと他のエンジニアから尊敬されない。 Scalaで書いてみたかった。 既存のロードジェネレータはどれも役に立たない
GoogleのCIとテスト自動化の取り組み [GTAC 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=nyOHJ4GR4iU [Slide] http://goo.gl/76Ggf Google Test Automation Conference 2013のキーノートスピーチで、GoogleのAri Shamashが同社のCIツール & 自動化されたテストプロセスを紹介しています。 [最初の前置きが13分。GoogleのCIの紹介の内容ではないので割愛。お話としては面白いのでVideo見てみてください。] エンジニア1,5000+人が5,000プロジェクトにアサインされている １億行のコード。50%が毎月更新。 1日当たり5,500+件がサブミッションされ、１億件以上のテストケースが実行されている。 Googleのクラウドテストシステムは多機能。ビルド作成、特定のターゲットをテストでき、テストカバレッジ計算、依
できるエンジニアだけで組織をつくる - ワザノバ | wazanova.jp
http://www.slideshare.net/bcantrill/surge2013 上記のスライドは、JoyentのSVP, EngineeringであるBryan Cantrillがエンジニア組織のあるべき姿ついてまとめたものです。BryanはSun Microsystems出身で、同社がOracleに買収されたのを受けて、2010年にJoyentに移ったという経歴。Joyentはクラウドサービスの会社ですが、Node.jsのスポンサー企業として知られ、Node.jsの中心人物であるIssac Schlueterなどフルタイムでオープンソース開発に従事する社員がいます。昨年、Greylock, Intel CapitalなどからSeries Dラウンドで$85Mの資金を調達してますので、投資家からは上場を期待されていると思われます。 彼の意見としては、 [モチベーションをあげるポ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
