ちょっとしたメモ - application/jsonがRFC4627に
3月末にアナウンスされていたJSON仕様のRFCが、RFC 4627 The application/json Media Type for JavaScript Object Notation (JSON)として公開された。メディアタイプは表題の通りapplication/jsonで、標準ファイル拡張子は.jsonとなっている（拡張子の話は前回書き忘れた）。一部のミス修正以外は最終I-Dとほぼ同じ内容でRFCとなった。 XMLHttpRequestでの処理にはメディアタイプはあまり関係ないが、ブラウザで直接ファイルを開こうとするとapplication/jsonの場合はダウンロードが始まってしまう（Opera9では「XMLの解析に失敗しました」となる…？？）。実用には支障ないものの、手軽にデータを確認できないのは残念なところ。.jsonにapplication/jsonをマッピングするか
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
ひよったところからほころびはじめる - 最速配信研究会(@yamaz)
POBoxなどのUIの神,増井さんが提唱してる「富豪的プログラミング」という考え方がある. http://pitecan.com/fugo.html ざっくり言うと「今の世の中マシンパワーとかあまりまくってるからヘタにチューニングしたりメモリや実行効率なんかは考えずにガンガン行こうぜ!」というお大尽な方法だ. 増井さん的にはUIに特化した話のつもりだと思うんだが,どうも一般のシステムにも上記思想を持ち込んでるケースが多々見られる. まぁ.マシンパワーはモリモリ増えてるので,それでもいいんだろうけど,富豪すぎるのもどうよ？と日々感じてたところ下記のエントリがあった. 平民的プログラミングのススメ http://www.oiwa.jp/~yutaka/tdiary/20051229.html#p02 > しかし、個人的に最近気になってることとしては、一方で > やたらと富豪的プログラミングが度
取らぬしっぽの皮算用 : 404 Blog Not Found
2006年07月18日18:00 カテゴリMoney 取らぬしっぽの皮算用 マルクスだのパレートだの持ち出さなくても、ロングテールそのものはもっと簡単に説明できる。 [R30]: 悪夢のロングテール考 最近よく聞くのだが、どうもあちこちでロングテール論を悪用する人たちが増えているようで、ITの時代に入った途端に突然あらゆるところでパレート法則が無効になってしまったかのような物言いがされる。んなわきゃーない。ニハチの法則はいつまでたってもニハチなのだし、だいたいたまたま自分がニハチのニだからって偉そうに「キミたちもぜひハチでもロングテールに」とか言わないでくださいよお願いします。足下に10万円金貨から1円アルミ貨までいろいろ落ちているとする。金貨はアルミ貨の10万分の1しか落ちていないとする。あなたはどうするか? もしかがんで取るしか方法がないなら、なるべく高額な硬貨を見つけて、それを優先す
再帰再考 : 404 Blog Not Found
2006年07月23日13:00 カテゴリLightweight Languages 再帰再考 今やこれは逆ではないか。 再帰的アルゴリズム まずは，非再帰プログラムで問題を考えてみる。 難しいと判断した場合，再帰プログラムで考えてみる。 むしろ私はこうしてきた。 まずは再帰で実装する。 速度と資源の制約があるとき、非再帰で実装しなおす 一番の理由は、今やプログラミングそのもののコストの方がプログラムを実行するコストよりも大きいからだ。早くプログラムを書く要請の方が速いプログラムを書く要請より強いからだ。 次の理由は、再帰は遅いとは限らないからだ。特にLisp系では、末尾再帰(tail recursion)は重くない。これはもうshiroさんが力説しているのでそちらを参照して欲しい。フィボナッチ数列を解くプログラムはとにかく、階乗を解くプログラムぐらいだとわざわざ再帰しないようにするご利益
dRuby
I like Ruby. (07-05) 借り物人生 (07-05) 通販生活 (07-05) I like iPod (05-24) RWiki (05-14) Download (05-14) ソフトウェア・シンポジウム 2003 (04-28) ruby-amazonでAmazonWebService (04-16) DI ary (04-05) KoyaなTropy (03-29) 100%Rubyによる分散Rubyの実装。 distributed Ruby dRubyはRubyのメソッド呼び出しを拡張し、ネットワーク越しにメソッド呼び出しを 行なえるようにするライブラリです。 JavaのRMIやHORBをイメージすると近いです。 download drb-2.0.4.tar.gz - 2.0.4以降はruby-1.8以降に取り込まれています。rubyに添付されているdRubyの方
Rubyで分散オブジェクト (dRuby) | Netsphere Laboratories
(2002.04.27 加筆。) ネットワーク越しにオブジェクト（のメソッド）を呼び出せる分散オブジェクト技術。pure Rubyな実装であるdRubyで遊んでみる。 I like Ruby. 何が嬉しいの？ スタンドアロン・プログラム 分散オブジェクト化する オブジェクトをやり取りする ひとつのサーバーで複数のリモートオブジェクト オブジェクトサーバーを分散させる 何が嬉しいの？ 一つのプロセス内だとオブジェクトを操作するのは単にメソッドを呼び出すだけ。プロセスを跨ごうとすると，とたんにソケットだの何だのと，オブジェクトを分解して送信し，受信したら再びオブジェクトに復元しないといけなくなる。ネットワークの先にあるオブジェクトに直接アクセスできたらいいのに，と思う。これができるのが分散オブジェクトの嬉しさ。 分散オブジェクトの構図を図にするとこんな感じ。 [クライアント] [オブジェクト実
メディア・パブ: WikipediaもGoogleとwin-win関係に
WikipediaもGoogle Co-opのContributorに加わることになった。 検索結果の質を高めるためのプロジェクトであるGoogle Co-opは，技術，ヘルス，トラベルといった特定分野から着手している段階である。このため，Contributorとして参加しているメディアも，大半が技術，ヘルス，トラベル関係となっている。 早速，Wikipediaをsubscriptionとして登録してみた。657人目の登録者であった。下の画面は，私の登録履歴である。（クリックで拡大可能） その後，Google Search（英語版）で，Dalai Lama（ダライ・ラマ）を検索してみると，次のようにWikipediaがトップ位置に表示された。Dalai Lamaを紹介したWikipediaのページに直ぐに飛べる。 次に，技術用語のwifiを検索してみると，検索結果のトップ位置にdiggが現
メディア・パブ: YouTubeの瀕死説が浮上
今，インターネット業界で最も注目を集めている企業となると，やっぱりビデオ共有サイトのYouTubeであろう。同社を買収するならば10億ドル近くも要するいわれるほど，YouTubeは高く評価され始めているのだ。 ところが一方で，YouTubeはもうすぐ瀕死の状態に陥るとの見方も浮上してきている。Gawker Mediaが発行しているブログValleywagに，“Why YouTube is about to die”という見出しのエントリーが投稿されていた。Valleywagはシリコンバレーのゴシップ満載のブログで，少々過激で危なっかしい内容も飛び出るが，シリコンバレーの裏情報を知るには格好のブログである。 そのValleywagによると，YouTubeは経営的に追いつめられるとのことだ。特に，ネット接続の通信費が致命傷になりかねないと。今年初めから，通信費が月間100万ドル程度かかっている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Techknow Movable Type: Apache 2.0 mod_proxy によるリバース・プロキシの構築