How GitHub Uses GitHub to Build GitHub
Build features fast. Ship them. That’s what we try to do at GitHub. Our process is the anti-process: what’s the minimum overhead we can put up with to keep our code quality high, all while building features as quickly as possible? It’s not just features, either: faster development means happier developers. Slides Video References Merlin Mann’s “Mud Rooms, Red Letters, and Real Priorities” sinatra_
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
るびま
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
さいきんの Rails サービスを高速化をしてみた - A Day in the Life
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
Linode Cloud Asia-Pacific!
767 ) }" x-bind:class="sideCol ? '--sideColOpen' : '--sideColClosed'" > { input.disabled = !input.value; } ); }, handleSubmit: function( e ) { let form = e.target; this.filterInputs( form ); } }" x-init="let sq = new URLSearchParams( window.location.search ).get( 'sq' ); search_queried = ( null !== sq && '' !== sq )" x-bind:class="( search_queried || search_focused ) ? '--active' : ''" > Query
通信を 6 ミリ秒縮めるための海底ケーブル 、3 億ドルかけて敷設へ | スラド
新たな大西洋横断海底ケーブルが 3 億ドル (約 230 億円) かけて敷設されるそうだ (The Telegraph の記事、本家 /. 記事より) 。 このケーブルの目的は通信時間を縮めるため。現在使われているケーブルは 1990 年代に敷設されたものが多く、この新しい光ファイバーケーブルはロンドン〜ニューヨーク間の通信を現在の最速と比較して 6 ミリ秒縮めることができるとのこと。この帯域はロンドンおよびニューヨークの証券会社や銀行などの金融企業に販売され、その価格は従来のケーブルを使用した場合の 50 倍にもなると予想されるという。 しかしスピードが何よりの命であるトレーディング業界においては 1 ミリ秒の差が 1 年では 1 億ドル (約 77 億円) の差を生む場合もあると試算されているそうで、需要は高いのかもしれない。
はてなの脱「自作サーバー」宣言から「さくらのクラウド」の未来まで はてな×さくら座談会2011夏 - はてなニュース
2011年夏、はてなは自社サーバー群の保守運用を、自社管理から「さくらインターネット」への業務委託に切り替えました。はてなが自作サーバーの自主運用から大規模データセンターへのアウトソースに切り替えた理由や、さくらインターネットが2011年11月にサービス開始を予定している「さくらのクラウド」について、さくらインターネットの田中邦裕社長、はてな最高技術責任者（CTO）の田中慎司（id:stanaka）、はてなエンジニアの吉田晃典（id:marqs）が語り合いました。 （※この記事は、さくらインターネットの提供によるPR記事です） クラウドサーバーはIaaS型のさくらのクラウド http://ishikari.sakura.ad.jp/ http://ishikari.sakura.ne.jp/blog/ ■ はてな、脱「自作サーバー」宣言の理由 stanaka この度はてなは、さくらインター
text.ssig33.com - 金くれを App Engine から heroku に引っ越した。
金くれを App Engine から heroku に引っ越した。 App Engine が値上げをするのでそれに対応した。 Twitter で App Engine の値上げの話で盛り上がっていて、課金履歴から新料金での課金額が分かるよという話だったので、見てみると金くれの場合新料金では一日 $1.5 ほど取られるとのことらしい。 話にならない。金が欲しくて作ったのに毎月 $45 も持っていかれるのは狂気の沙汰だ。 そこで App Engine から heroku に移行することにした。 App Engine 版のソースコードは紛失してしまっているのでスクラッチで作り直した。そもそも残っていたとしても App Engine に様々な部分が最適化されており(JRuby を使ってはいたものの)再利用は難しかったと思う。 データを標準の機能でエクスポートした。なかなか再利用の難しいデータがエク
インターネットが物理的に壊れる原因いろいろ:Geekなぺーじ
インターネットは物理的な回線の上に構築されているため、物理回線の故障がインターネットに影響を与えることがあります(この記事は主にLayer 1編みたいな感じです)。 意外と知られていない、あんな原因やこんな原因を紹介しようと思います。 なお、ここで紹介するものは全体の一部であり、これ以外にも色々と障害発生の原因はあります。 酔っぱらったハンター 米国では、通信回線に対する脅威の一つに「酔っぱらったハンター」が挙げられます。 2010年に行われたNANOG49の「Keynote: Worse Is Better」というセッションで、GoogleのVijay Gill氏が以下のように述べています。 アメリカには入手が容易なアルコールと、入手が容易なハイパワーなライフルを両方とも手に入れられる環境がある ハンティングシーズンに獲物を発見できずに酒を飲んだハンターが、暇つぶしに露出している光ファイ
トラフィックの新記録が出ました
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 昨日のFirefox 6のリリースで、ftp.jaist.ac.jpが流したトラフィックの新記録が出ました。5分平均で3835.9Mbpsがその記録です。実際には一時的に4Gbpsの上限にぶつかっています。23時過ぎにトラフィックがガクッと落ち込んでいるのは、上限にぶつかったためBouncerから死亡判定を受けてトラフィックが割り当てられなくなったためです。 0時前後にも何度かトラフィックが落ち込んでいますが、これはCPUが耐えられなくなってBouncerから死亡判定を受けたためです。ロードアベレージは0時前後に90近くに達しています。UltraSPARC T1は3
通信障害のお知らせ : 【回復】 ｓｐモードがご利用しづらい状況について（回復報 8月16日午後7時00分更新） | お知らせ | NTTドコモ
平素はNTTドコモのサービス・商品をご利用いただき、誠にありがとうございます。 spモードで利用しづらい状況が発生し、お客様には多大なご迷惑をお掛けしております。現在復旧作業に努めておりますので、何卒ご理解を賜りますよう宜しくお願い申し上げます。 1.発生日時 2011年8月16日（火曜） 午前11時35分頃 ※現在、復旧に向けて作業中です。 2.影響地域及び影響を受けると想定されるお客様 全国でspモードをご利用のお客様 3.状況 spモードが利用しづらい状況 4.原因 ドコモの通信設備の故障 ※詳細は現在調査中です。
Mongo DBを半年運用してみた
MongoDB is a document-oriented database that stores data in flexible, JSON-like documents. It supports features like replication, auto-sharding, and indexing. The document discusses using MongoDB with Ameba Pico's photo tagging service, including initial implementation with one shard, expanding to multiple shards as user numbers grow over time, and repairing and upgrading shards over time to suppo
第2回 読み誤りや誤削除など人為ミス続発
みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。 その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった（表-18）。 さらに、携帯電話での振り込みといった新サービスを導入する際に、夜間バッチの負荷テストを行っていなかった（表-19）。 みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった（表-20）ため、こうした問題に気付くこともなかった。 みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていない（表-21）など、リスクの大きさを正しく把握することができていなかった。 夜間バッチが異常終了した原因は、口座bの振り込みデータを振り分ける（分割する）処理で、上限値
みずほ銀行の3月のシステム障害の調査報告pdfが超面白いのでマはみんな読むべき « おれせん。
みずほ銀行：システム障害に関するお知らせおよびお問い合わせ先 http://www.mizuhobank.co.jp/oshirase.html 中段の「システム障害特別調査委員会の調査報告書について」のリンク 直リンクはこれ（5/20掲載） 前半しばらく「グダグダ鬱陶しい能書き」が続きますが9ページ目の「3. 本障害発生以前のシステム障害及び対応状況」あたりからギアが入って、11ページ目の「4. 本障害の発生事実」からトップギアというかちょっとしたヘル絵図であります。 ……ああ、その前にここを引用しておこうかな、4-5ページの「2. システムの概況」内「(3) 次期システムの概要」箇所。 (3) 次期システムの概要 次期システムについて、ビジネス環境の急激な変化に対応すべく、肥大化・複雑化した現行システムを新たなシステムとして再構築するために、2004 年から MHFG を中心に検討
Perl好きの女性Webエンジニア二人がIBM DB2を試してみた - はてなニュース
Webアプリケーション開発に欠かせないデータベース管理システム（RDBMS）。オープンソースの製品が広く利用される昨今ですが、無償で利用できる商用のRDBMSもあります。そんな製品の一つがIBMの「DB2」です。歴史が長く、実績はたくさんあります。そうはいっても使ったことない！ どんなもんだか試したい！ そう思った一人が、フリーランスのWebエンジニア女子、id:acotieさんでした。普段から開催している勉強会の番外編として、同じくWebエンジニア女子のid:aomushi510さんを呼び、無償で利用できる「DB2 Express-C」に触れてみることに。記事の終わりにはプレゼントのお知らせもあります。 （※この記事は日本アイ・ビー・エム提供によるPR記事です。） このたびの東日本大震災で被災された皆さまに心よりお見舞い申し上げます。皆さまの安全と一刻も早い復旧と復興を心からお祈り申し上
Architecture by Accident
This document discusses how architecture emerges even when not initially planned. It begins with an overview of databases, message queues, and caching as common architectural elements that emerge over time. The document then provides examples of how simple applications and data needs can evolve into more complex architectures with multiple servers, databases, caching, and services. It emphasizes t
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Solr at cookpad
Twitterにおける大規模システム構築、3つの原則