ニュースを見て「これはひどい」と心でつぶやくとき なんかあると「〜ばいいのに」と思うとき みんな、はてブを使えばいいのに!と思ったとき キーワードリンクがさほど気にならなくなったとき 何か困ったことがあると、人力検索に相談しようと思うとき コーギーを見たら「あっ、シナモンだ」と思うとき はてなやめたい! と思うとき このエントリーは、きっとブクマされるだろうと企んでる今!
この文書は内容が古くなり、非推奨となったので削除しました。あしからずご了承ください。
題名 Catalyst::Manual::Cookbook - Catalystでお料理を 説明 ママが昔よく焼いてくれたおいしいコード! レシピ デバッグ画面を強制表示する endアクションでdie()を呼び出すと、リクエストの最後にデバッグ画面を強制表示させることができます。 sub end : Private { my ( $self, $c ) = @_; die "forced debug"; } いちいちこれを書いたり消したりするのが面倒なら、endアクションにこんな条件文を加えることもできます。 sub end : Private { my ( $self, $c ) = @_; die "forced debug" if $c->req->params->{dump_info}; } こうしておくと、たとえばクエリストリングに"&du
画像配信の負荷分散も比較的簡単?(その2)のつづき. 初めての方は画像配信の負荷分散も比較的簡単?(その1)からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
生後4日で生みの母と生き別れになった娘。経済的な事情により生後4日のわが子を泣く泣く養子に出さざるを得なかった母。そんな2人がどこかで擦れ違っても、お互いに親子だと気づくことは絶対にないだろう。いや、同じ職場で働いていても、会話の機会が少なければ、自分たちが親子だということに気づかないかもしれない。 ミシェルさんは、10代のころから自分の出生の真実を知っていた。両親が彼女に打ち明けた。ミシェルさんは両親の実の子ではなく、生後わずか4日でもらわれてきた養子だった。 それを知ったミシェルさんは、生みの母にいつか必ず会いたいと思うようになった。 1996年、美容学校を卒業したミシェルさんがネイルアーチストとしてのキャリアを開始したのは、Hair By Stewartという名の美容院。社会人としてのスタートを切った後、生みの母に会いたい気持ちがますます強くなっていった。 美容室には若い同僚たちのほ
つたない英語だろうがなんだろうが、彼らにとっては日本語よりも65536倍わかるんだから。 そう、これ重要。めちゃくちゃ重要。 DHHに質問責めにあった時、田中 哲さんが一緒にいて、田中さんの英語の発音はほとんどこれと同じだったけど(スミマセン!)、日本人英語に慣れてないはずのDHHにもしっかり通じてた。 私のプレゼン資料(要Firefox)も、DHHに見てほしいから英語にしたけど、たぶん定冠詞とかそういうのがあちこちおかしいと思う。 どんなにひどくても英語なら何割かは伝わるけど、日本語だと99%伝わらない場面はある。 ちなみに、私は大半の読者より自分の馬鹿さ加減をよくわかっていると思う(→アンカテ(Uncategorizable Blog) - サリエリの教養あるいは永遠のアウエイ)。幅広い教養が無い人には、自覚しながら毎日恥をさらしているこの痛みはわからないだろう。 でも、どんなにひどい
http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ(画像とか)を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単?(その1)からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
●NTTDATAの社内SNSは成功するか? 公式にプレスリリースにも出ていますが、NTTデータでは2ヶ月で約3,600人の社員が参加しています。職縁SNSはNTTグループ全体に広がる勢いですね。 関連記事は以下の通りです。 ▼NTT データ、社内 SNS の利用状況を発表――約3分の1がアクティブユーザー http://japan.internet.com/busnews/20060620/4.html ▼NTTデータ、SNSを社内に導入 http://bizplus.nikkei.co.jp/news/index.cfm?i=2006061608000b1 http://gigazine.net/index.php?/news/comments/20060620_ntt_sns/ ▼株式会社NTTデータの社内SNSスタート4日間で2000人突破! http://www.atpress.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く