満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
満足せる豚。眠たげなポチ。:フレームワークについて読む暇あったら、このエントリを100回読むべき
はてブをちら見してあれだったんで、書いておきます。タイトルは釣りタイトルっぽいですが、そんなこともなくまったくもって正直な気持ちです。 圧倒的に生産性の高い人（サイエンティスト）の研究スタイル フレームワークに踊らされるヒマがあったら、このエントリを繰り返し100回でも200回でも読んで実践してみるべきです。（こちらも1,000オーバーのブクマが付いてはいますね。） それだけの価値がこのエントリにはあります。 どうしてもフレームワークについて読みたいなら、大前研一さんの「企業参謀」「続企業参謀」をやっぱり100回でも200回でも読んで、その後で「マッキンゼー現代の経営戦略」を読んで衝撃を受けて、そこで「企業参謀」に戻ってみたら衝撃を受けたはずのことがすべてその何べんも読んだはずのその本に書いてあったことに気付いてぶっとんでみればいいと思います。 最近では斉藤嘉則さんの本のほうが人気のようで
満足せる豚。眠たげなポチ。:The Universal Design Pattern がおもしろそうな件
まだ読んでないけど、プログラミング界の戦略サファリかと思いきや、新しい視点の提案なのかな？ Stevey's Blog Rants: The Universal Design Pattern With this context in mind, I claim that the Properties Pattern is yet another kind of domain modeling, with its own unique strengths and tradeoffs, distinct from all the other modeling schools I've mentioned. At a high level, every implementation of the Properties Pattern has the same core API. It's the
満足せる豚。眠たげなポチ。:BDD に関するメモ。
で、肝心のBDDですが、これは確かに実績を上げてました。RSpecとSeleniumを使うようになって格段にバグも減ったし、「何をやってるか知りたければまずSpecを見ろ」っていう習慣も自然に浸透したし、LLに不慣れなベテランプログラマや新人プログラマを含む混成部隊でもペアプロのお陰で開発速度を維持できたし全体の技術水準も上がりました。 あと余談だけど、「Specのないコードを書くときは上長に申請書を提出させる」とか「ペアプロ時にはナビゲータはピコピコハンマー装備」とか、今回の名言「わかんないやつは黙ってろ」とか、本当にやっちゃう人ですからねyuguiさんは。実際に。そこに痺れる憧れる。 via RubyKaigi 2008に行ってきた 以上、個人的なメモ。 最近、自分でコードを書くときはよほど小さなツールでないかぎり、ほとんど BDD で開発している。BDD の体感的の感覚としては、森博
満足せる豚。眠たげなポチ。:CGI から Mongrel まで、Rack で Web アプリを Web サーバから抽象化する
Rack ってなに？ Rack は Web サーバと Ruby プログラムや Ruby で書かれた Web アプリケーションフレームワークとの間に、最小限のインターフェースを提供します。 http://rack.rubyforge.org/ Rack のインストール gem install rack Rack の簡単な始め方 Rack を使うには、まず call されるアプリケーションを書きます。call メソッドを定義し、引数に env を取ります。 # app.rb require 'rack' class TinyCaller def call(env) [200, {'Content-Type' => 'text/html'}, ["Hello, World."]] end end 続いて、Rack を使うための DSL ファイルとなる .ru ファイルを作成します。 # tiny
満足せる豚。眠たげなポチ。:データフロー並列性
「コンピュータプログラミングの概念・技法・モデル」を読んでいて、データフローという概念がおもしろかった。複数スレッドを走らせたときに、各スレッド間で変数の束縛が行われるまで互いに評価を待つというモデルのようで、シンプルな考え方で並列処理の恩恵を受けられる。関連して検索した結果をメモ。 現在のコンピュータは、大半がフォン・ノイマンモデルと呼ばれるアーキテクチャに基づいている。演算部、制御部、記憶部、出力部があり、命令を順番にフェッチし、実行していく。命令の実行順序をあらかじめ定め、各命令に必要なデータを集め、処理を行うという、命令を中心とした処理体系だ。ところが、データフローマシンでは、データの依存性に着目し、トークンをやりとりする形で演算を行っていく。トークンは、行先ノード、ポート、データからなり、行先ノードの指定のポートにデータを届ける。そのノードにおいては全てのトークンが揃ったところで
満足せる豚。眠たげなポチ。:オープンソースの一つの価値
分野は違うけど、まぁ、こういうことだよな。 この夏キネ旬から刊行されたムック内の監督インタビューに以下のコメントがあってひどく共感しました。 「･･･（業界の）若い子はまず映画を観ない。映画も観なきゃ本も読まない人が大半です。それで、演出家だのシナリオライターになりたい、って、もう笑止千万ですよ。自分の引き出しの中身を増やしもしないで、『いつか羽ばたく日』を夢想しているんだから世話ないです（笑）。引き出しの中身は、それまで見てきた作品の数に素直に比例するから、数を観てないとまずアイディアを出せない。（中略）･･･情報がたくさんあったところで、必要な情報を選ぶ能力は養ってないし、どれが面白いかを選別する目が養われていない。目の前にある仕事が忙しいんだろうけど、せめて己の無能くらいは自覚してほしい人たちがたくさんいます（笑）」 http://d.hatena.ne.jp/kaoru1107/2
満足せる豚。眠たげなポチ。:Asianux Road Show 2007 まつもとゆきひろさん、基調講演のメモ
2007/10/16 Miracle Linux 社開催の Asianux Road Show 2007 へ行ってきた。そのうち、まつもとさんセッションのメモ書き。急いでメモったので、理解が違っているところや聞き漏れ、聞き間違いがありえる。読まれる方は、そこを理解したうえで読んでください。 タイトル Ruby からのメッセージ 自己紹介 プログラマ オープンソース開発者 言語デザイナ 世に言語の種は尽きまじ 一説には数千とも数万とも ほとんどは消えていく アイディアの具現化 いつか自分の言語を 言語を作りたい人は一定数いる Ruby という名の言語も３つ存在する ただ、ほとんどは寿命が短く使われない 作者しかユーザがいない、とか 先端言語と普及言語 言語における対立軸 一般向け／学術向け 最新技術／枯れた技術 先端言語 特定のアイディアに深く依存 応用範囲が狭い アイディアの実用性を証明（
満足せる豚。眠たげなポチ。:Rails の link_to_remote を訳してみた
勉強会用に Rails API ヘルプの link_to_remote を訳していて、ラストまで訳したときに過去にも一度訳したような覚えが。そして大嘘が発覚。babie さん、ごめんなさい。。 新訳から抜粋。 さらに、オプションを指定することで、ブラウザサイドの JavaScript コードを利用することもできる。 :confirm: 確認ダイアログを利用する。 :condition: リクエストは、ある条件が満たされたときだけ実行される。リクエストが実行されない場合の条件を指定する。 :before: リクエストが開始される前に呼び出される。 :after: リクエストの完了後に呼び出される。 :submit: FORM エレメントの親となる DOM エレメントの ID を指定する。デフォルトでは現在の（current の）FORM となるが、テーブルの行の ID やその他の DOM エ
満足せる豚。眠たげなポチ。:プログラミングの原則を集めた Wiki 作りました。
プログラミングのノウハウや Tips、入門なんかはたくさんあるのだけど、本当に基礎となるような原則って意外に紹介される機会が少ない。 まさーるさんの「Open-Closed Principle とデザインパターン」や「オブジェクト指向の法則集」を見たときから、本当に世の中に知られるべきなのは、こういう内容だよなぁと思っていた。 ということで、作ってみました。 Concepts + Principles - プログラミングの原則 作った主旨もすでにまさーるさんのページで書かれているとおりです。 これらの法則は，絶対守らなければならないというものではありません．開発中に法則が守られているか意識することが重要です．つまり 今行っている設計はその法則が守られているだろうか その法則を破っている場合，破るべき正当な理由があるだろうか と絶えず考えるようにしましょう． via 「オブジェクト指向の法則
満足せる豚。眠たげなポチ。:Ruby の include, extend まとめ
この前の話の続き。 include, extend わかった。つか、自分で写した説明のとおりとしか言いようがない。 self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。 self.extend(other) とすると、 other のインスタンスメソッドを self の特異メソッドとして追加する。 Module はインスタンス化されないから、Module のインスタンスメソッドは extend するか、 include するかしないと使うことができないってだけだった。いったい何が理解できずにはまってたのか、自分でもよくわからず。。 てことで、まとめ。 self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。 特異メソッドは実装されない インスタンスメソ
満足せる豚。眠たげなポチ。:Ruby の include/extend が分からなくなってきた・・・
FileUtils は FileUtils.mkdir といった形で利用ができる。つまり、モジュールの特異メソッドになってるのだけど、module_function を探しても見つからない。 それでもコメントに燦然と輝く "# All methods are module function." の文字。 なんだ？？と思って探し回った結果。↓ そりゃ、そうだぁ。そんなやり方もあったのね。。（あれ、もしかして一般的なの？） というわけでメモ。 クラスメソッド＝クラスの特異メソッド。モジュールメソッド＝モジュールの特異メソッド。 モジュール関数＝モジュールの得意メソッドであり、モジュールの private メソッド。 self.include(other) とすると、Mixinにより self に other のインタフェースが実装される。 self.extend(other) とすると、 ot
満足せる豚。眠たげなポチ。:Web時代の今こそ読みたい「UNIXという考え方」
少し前にUNIXという考え方という本を読んだ。そして、これこそまさにプログラムするWebを理解するために読むべき本だと思った。 そしてしばらくしたところに現れたサービスが Yahoo! Pipes。自分でWebのAPIを触っているような人は発想自体への新規性は感じず、むしろ納得のサービスだったのではないだろうか。それにしても、Pipesという一部の人にはこれ以上なく直感的なネーミングは絶妙だと思った。 さて、そんなPipes（Yahoo!じゃない方の）についても触れられているUNIXという考え方。これは名著だ。しかも類著がない。（ふつリナ？そうかも。） UNIXという考え方は、UNIXを使う人ではなくむしろUNIXを使ったことがない人に読んで欲しい。それもソフトウェアを作る人に。なぜならこの本にはUNIXの使い方ではなく、UNIXという優れたコンセプトに横たわる設計思想が書かれているからだ
満足せる豚。眠たげなポチ。:すごい会議のための最高の手引書 『この「聞く技術」で道は開ける』
「すごい会議」を購入した人にはぜひ一度読んでほしい。「すごい会議」の公式副読本はおそらく「すごい考え方」なのだろうけど、この本もぜひ加えてほしい。すごい会議はこの TIME TO THINK をプロジェクトの推進で使うためにフレームワーク化したものだと言えるから。 問題の正しい対処の仕方を知っていて、一人で実践する分にはうまく行くのに、皆にそれをやってもらおうとした途端にうまくいかなかった経験はないだろうか？ たとえばプログラムでもいい。セオリーとしてどのようにすべきか、きっとあなたは知っている。ファウラーのリファクタリングも読んだし、デマルコのデッドラインも読んだ。もちろん達人プログラマーだって読んだし、デザパタ本だって読んでいる。コードコンプリートもライティング ソリッドコードも読んだんだ。楽々ERDレッスンも読んだ。何をすべきかは知っている。 ところが、それを組織でやろうとしたときに
満足せる豚。眠たげなポチ。:webの限界 / webの可能性
タイトルは、あえて原題をそのままコピー。 今回、我々は「ネットを主要な販売チャネルとした新しい生命保険会社」を作ろうとしているのであり、ネット上がいわば店舗になる。ここが、お客様との重要な接点。その店舗の作り方がコモディティであり、本質的に差別化するのは難しいと言い切られてしまうと、がっかりせざるを得ない。 http://totodaisuke.weblogs.jp/blog/2007/01/web_web_9de1.html 求めている答えははっとするような洞察を含んだ深い答えか、もしくは思いもよらないようなバカげた発想だろうと勝手に張り込んでバカ担当の方、それも最上級に妄想度の高いやつで応えてみる。 ぶちあげるのは、『保険金は保険料収入からは払いませんよ説』 保険のルールをとことんシンプルにしてみれば、「保険料を集めて、そこから保険金を払います」てことだ。現行のルールでは、元手がお金で
満足せる豚。眠たげなポチ。:技術者のための提案書のお手本を読む
Ringo's Weblog さんで紹介されていた Tim Berners Lee の提案書が面白い。一読されることをオススメします。素晴らしい文書をご紹介・翻訳して下さっている ringo さんに感謝。 1990年にTim Berners Leeが提出した、最初のWebブラウザ開発の提案文書は、優れたプロジェクト・マネジメントの手本となる文書である。 と書かれているとおり、何かが目を見張るほど卓越した提案書というわけではないが、非常にバランスが取れ、よく練られた内容の提案書になっている。（特殊な技法が使われていてスペシャルな存在になっているとかいう類ではなくて、ベーシックなスキルの積み重ねで全体として高品質な提案書になっている。） 個人的に好きな点は、 見通し：やりたいこと、やりたくないこと やらないこと の項。 この言い回しは、技術文書だとわりと見かけるのだけど、他の界隈ではあまり見な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
満足せる豚。眠たげなポチ。:Web 開発の決定版リファレンスになるか？Google DocType
満足せる豚。眠たげなポチ。:Ruby の設計思想について質問中
満足せる豚。眠たげなポチ。:Rails でチュートリアルが終わったら、の Wiki を作ってみた
満足せる豚。眠たげなポチ。:所信表明