ウチのBraunのマルチクイックがかなりヨレてきてるので、買い換えたいなあ、と長いこと思っているのだが、ヨレていても使えるので放置プレイではや1年以上。とか思っていたら新型が出た。
しかし、旧型との違いがよくわからん。チョッパーが金属製になったところ？
新型にあわせて真空パック？できるオプションが発売されたのだが、別に新型専用というわけでもなく。
広告収入で儲けてるサイトとかやってると、やっぱりRSSフィードを行なうことで増加or減少したトラフィックがどれくらいあるのか、というのは把握したいところで。
でも、"?rel=rss"を引き回すんならともかく、そうでないなら"ほにゃらら?rel=rss"は"ほにゃらら"にリダイレクトする仕様にしとけばいいのにな。
ええと、まとめると、1819年に出現した彗星のチリが1956年に流星群になって、彗星の方は2003年に小惑星として(再)発見されて、2014年にまた流星を降らせるかもしれない。
……江戸の仇を長崎で討つ、みたいな話？(違う)
handlerのメンバ関数で子クラスで必ず定義しなくちゃいけないのは、
int open(const char *name, int mode, uint test_if_locked);
int close(void);
int rnd_init(bool scan);
int rnd_next(byte *buf);
int rnd_pos(byte * buf, byte *pos);
void position(const byte *record);
int create(const char *name, TABLE *form, HA_CREATE_INFO *info);
THR_LOCK_DATA **store_lock(THD *thd,
THR_LOCK_DATA **to,
enum thr_lock_type lock_type);
void info(uint);
const char *table_type() const;
const char **bas_ext() const;
ulong table_flags(void) const;
ulong index_flags(uint idx, uint part, bool all_parts) const;
本質的なのはstore_lock()までぐらい。まあ、名前見りゃなんとなく何する関数かは想像つくと思う。こんだけ実装すりゃおしまいなので、テキトーなもんならでっちあげるのは簡単だ。
write_row()とかの更新系関数は必須ではない。なので、現実的に一番お手軽なケースは、どっかヨソのシステムで作られるデータに対する便利なアクセス手段としてMySQLをフロントエンドとして利用する、とか、そんな場合になるかな。
Zopeとかほど大げさすぎなさそうなCMS。どっかでちょっと試してみるか。
さようならレッツ2。今までご苦労さんだった。
ヘッドフォンのコードとめるクリップ。なんか便利そうなので注文。日本あてでもサイトに書いてある送料でOKらしく、もう送ったよん、とメールが来た。
デカい！『ぼくの地球を守って』に出てたネコ思い出した。やっぱメイン・クーンかなんかの系統かな、これ。体重何キロぐらいあるんだろ……
こーゆー嘘をつく親は珍しくないと思うが、それをマジメに信じる子供は珍しい気がするｗ。
BMXのメンテしたついでに、しばらく前にヤフオクで買ったフロントのストラット・タワーバーをつけてみる。ナット4本はずして、もう一度つけるだけの作業ともいえないほどの作業。
とりあえず買い物がてらちょろっと走っただけだけど、明らかにフロントの剛性が上がってていい感じ。
create()関数。名前の通り、テーブルをcreateする時に呼ばれる。MySQLのデータ・ディレクトリを覗いたことがあれば分かる通り、ストレージ・エンジンに関係なく、すべてのテーブルにはtablename.frmという拡張子のファイルが作成されて、ストレージ・エンジンに関係のないメタデータ、フィールド定義だったりとかはその中に格納される。
ストレージ・エンジンのcreate()は.frmファイルが作られた後で呼ばれ、ストレージ・エンジン固有のメタデータだったり、データそのものを格納する領域のセットアップを行なう。ファイルのopenは必要であれば別途open()が呼び出されるので、ここで行なう必要はない。要するに空のテーブルを一個作るのがcreate()の仕事だ。
MyISAMのようにテーブルごとに対応するファイル(tablename.MYDとか)を作成して、そこに(メタ)データをストアする場合、ファイル名を「tablename.拡張子」にして、bas_ext()関数が拡張子のリストを返すようにしておくと、テーブルが削除された際のファイルの削除はMySQL(デフォルトのhandler::delete_table())が勝手にやってくれる。InnoDBみたいに別のところにデータをストアするのであれば、別途delete_table()の実装が必要。
create()の引数は、const char *name, TABLE *table_arg, HA_CREATE_INFO *create_info の3つ。nameはテーブル名ではなく、ファイルが置かれるディレクトリへのパス＋テーブル名。通常だったら"$data_dir/dbname/tablename"という文字列になる。これに拡張子つけて使え、ということだ。これはいいとして、table_argとcreate_info。TABLEの定義はtable.h、HA_CREATE_INFOの定義はhandler.hにあるので、それを見れば分かるけど、基本的にはcreate文のオプション(comment="XXX"とか、maxrows=XXXとか)がcreate_infoに格納されていて、それ以外のcreate文の本体に書かれたテーブル構造に関する情報(.frmに格納される情報)はtable_argに格納されている、と考えてOK。
オプションがこの時点ですでにcreate_infoにセットされていることから分かる通り、ストレージ・エンジンが独自のオプションを必要とする場合にはストレージ・エンジン以外のコード、パーサとかもいじらないといけない。初期のFederatedエンジンはそれが面倒くさかったのか、commentにオプションを記述するsyntaxだったりした。このへん、もうちょっとなんとかならんものかと思ったり。
閑話休題。class handlerはtable_argと同じTABLE *型のtableというメンバを持っていて、これを使えばtable_argに含まれている情報はcreate()以外のメンバ関数においていつでも取得できる。なので、これをcreate()で保存しておく必要はない。create_infoの方の情報は他に保存されているわけではないので、必要なら保存しておかないといけない。
空テーブルの作成が正常に終了したらcreate()は0を返す。そうでなければエラーコードを返す。MySQLのソースでの関数の戻り値の流儀は大体のところ、正常終了は0(FALSE)、そうでなければエラーコードだ。個人的には失敗した時にNULLとか返す奴らとかと混じった時に、条件判定の意味を取り違えがちなので、この流儀はそんなに好きじゃないんだけど。
事件前には、突然ひげを生やしたり、記者クラブ内のいすをけるなどの奇行も目立つようになっていたという。
ひげを生やすのは奇行なのか……
久しぶりに歯医者に行った。なんか差し歯がぐらぐらすんなーと思っていたら、差し歯の下が虫歯になって膿んだのだった。で、とりあえず差し歯を抜いて膿を出して、その後どうするか考える、とゆーのが今日の治療だったんだが。
麻酔2本打たれてオレは全然痛くないのに、医者が「痛くないですかー？」「痛いですよねー？」「もう少しだけ我慢してくださいねー」「大丈夫ですかー？」となぜか焦りまくってる。いや、それよりもなぜあなたはマイナスドライバーを手に持っているのですか？とツッコみたかったのだが。どう見てもあれはホームセンターで売ってる安物のマイナスドライバーだった。ひょっとしてオレはメカ沢なのか？みたいな。
で、差し歯抜いた後、やっぱり別に痛くもなかったんだが、うがいしたらすげー血だったので、口の中はそれなりにホラーなことになっていたのだろう。その後、歯茎切って膿を出すのに、やっぱり別に痛くもないのに、さらに麻酔を2本追加された。で、また「痛くないですかー？」「痛いですよねー？」。
いや、それよりもマイナスドライバー……。
子供の頃に読んだ本だが、急になんとなく読みたくなったので買ってみた。頭がいいんだか悪いんだかよくわかんない犬とその飼い主の一家の話。牧歌的でいい話だ。オレも近所の人間から二十二口径のライフルをプレゼントされてみたい。
MySQLでSyBaseチックなcolumn-wiseストレージってのは、オイラも考えてたんだけど、上物が基本的にrow-wiseなストレージを期待してるところがあって、簡単には実装できない気がする。select_lexから必要とされてるフィールドの情報取得して、それ以外のフィールドはダミー埋めて返すとかってんでいけるかな？という気もするのだが。
「非モテ」とゆーヒトの中には、「恋愛に対するリソース配分の優先順位が低いヒト」とゆー一族がいて、それはそれで別にいいんでないのとハタ目には思うし、本人も自分が恋愛に資本投下していないことに自覚的だったりするので、自分で「非モテ」とか言ってても割と確信犯的だったりする。ついでに言うと、恋愛に対する「正しい」投資なんてのはありえないので、本人は恋愛に対して投下してるつもりじゃなかったリソースが、たまたまどこぞの女子のツボにハマってしまって、まあ、「モテ」ではないのかもしれないけど、そこそこ気の会う恋人できたんだからいいじゃん、みたいなところに落ち着くこともありがち。つーか、その水準以上に恋愛に資本投下するヒトってのは、それは恋愛が生きがいな人々だろ。それは冬の間スキー場にこもっちゃうスキー馬鹿みたいな、別次元の生き物だ。
いや、そこまでやらないにしても、オレはオレのツボにハマった女子のツボにハマりたい、けれどそこに割くリソースがない！とゆー葛藤なのかな、「非モテ」とゆー奴は、となんとなく思っていたのだが。今日たまたま見かけたどこぞのブログの非モテのヒトは、「恋愛が市場経済なんだとしたら、(恋愛による)癒しを得るためには勝ち続けなければならないわけで、それが本当なら負け組である非モテが癒されることなどないのではないか」と暗澹たる心中を書き綴っていた。
そんなの恋愛を金とかスポーツとかマンモス狩りとか、何に置き換えても一緒だろ、と思ったんだけれども、これは↑で書いたような一族とはまた別の、勝てない自分とそれなりに折り合いをつけてしまっているので、勝つことに必死になれない、とゆー非モテ一族なのかな、と思ったり。負けたことのない奴、負けた自分が許せない奴ってのは、そんなことうだうだ悩む以前に、負けたくないので必死になるわけで。最初から負け組であることが前提、必死になって資本投下しないことが前提でやってるんじゃ、そら、恋愛だけでなく、なんだって勝てんだろ。孫悟空だって何にもしないでスーパーサイヤ人になれたわけじゃないんだし。非モテ云々以前の段階でヒトとして負けてる気が。
まあ、世の中ひょっとするとどこかの南の島では「ただの昼飯」が木になっていて、木陰で仰向けに寝てるだけで腹が満たされたりするのかもしれんけれど、寡聞にしてそういう島が発見されたという話は訊いたことがないので、そういうヒトらが生きてくのはさぞや大変だろうなあ、と思うことしきり。
昨日届いた。べつにすごーく面白いものでもないが、他にうまい代用品があるかというと微妙なような。まあ、役には立つのでよし。
この論理だと、暗算とかチェスとか歌を歌うとかの能力に関わる脳の部位をいじるのはどうなるの？つか、人格なんて外部の刺激(特に薬物。あるいは言語)でフツーに操作できるものなわけですが、脳の電気刺激だけを特別視する理由は？悲しみ中枢を電気刺激してハッピーになっちゃうのが人間の尊厳を侵害していて、酒飲んだ勢いで好きでもない男とやっちゃうのが人間の尊厳を侵害していない理由はなんなんだ？
機械が人間より速く計算ができても、チェスで世界王者に勝っても、いまどき誰も人間の尊厳が傷ついた気がしていないのと同じようなもんで、あと何年か何十年か経ったら、機械の力でハッピーになっても誰も気にしないと思うし、その時になったらその時で、まだ説明されていない事柄、まだ機械によって達成されていない領域にこそ人間の尊厳があるのだという毎度の論理を展開するんだろうなあ。
PartitioningのようなConstraint Exclusionってなにゃ？って思って調べたら、こんなの見つけた。継承使って子テーブルにCHECK制約つけとくと、親テーブルにクエリなげた時にオプティマイザがCHECK制約を満たさない子テーブルのスキャンは省いてくれるってことね。継承使うのがpostgres的だが、UNION使ったviewの時に同じことやってくれるDBは多いよな。Oracleはやってくれないんだっけ？SQL Serverはやってくれるはず。Cコンパイラとかならフツーにやっちゃうレベルの最適化ではある。
DBMSの場合、JITコンパイラみたいなもんで、最適化に時間かけすぎてもかえって遅くなるところが難しいところだよな。
片山氏は不妊治療に言及し「５、６組に１組が不妊治療を受けており、負担は高額。少子化対策のため保険適用を認めた方がいい」と述べた。
んー、いっそ非モテも国家が支援したらどうなんだろう？美容整形手術に保険を適用するもよし、結婚相談所を控除対象にするもよし。
病院通いしてたりで、のんびりやってるウチに、MySQL 5.1のマニュアルにストレージ・エンジンを書くの章ができてしまった。素晴らしい。まずはこれ読んでみることにしよう。
日本映画専門チャンネルで見た。25分という尺の割にはドラマは薄いかなあ、という気はするんだけど、そこを云々する映画ではないわな。ネガドン襲来の時に人々が慌てふためくカットが1つぐらいはあった方がよかったんではないかと思うのだが。まあ、そういうカットのためだけに作らなきゃいけないオブジェクトの数とか考えると、いれたくてもいれられなかったんだろうなあ、とは思うんだが。ちょっと淡々と進行しちゃってるのが残念なところ。
映像はホント良くできてる。消し忘れた吊り線がないかどうか探しちゃったくらいｗ。こないだやっぱりスカパーで見た釈由美子の『ゴジラ対メカゴジラ』より、こっちの方がよっぽど好感持てる。実写よりCGの方が、「物」っぽい汚れた質感が出てるってどういうことなのよ？と思うんだが、まあ、それが作った奴のこだわりの水準の違いなんだろうなあ。
ひさびさのカート。慣れない夜＆慣れないメガネでの運転＆ブレーキの初期制動の悪いマシンでのレースで、どうなることやらって感じだったけど、まあ、ウチのエースのタイムから1秒落ちぐらいでは走れた。Myレーシング・スーツ族でもオレより2秒ぐらいしか速くなかったし、こんなもんでよしとしよう。
つか、アレだな、オレはインベタのライン使って、しかもドリフトしすぎなんだよな。イン側のタイヤバリアが視界にバッチリ入ってる感じ。いい歳してタイヤバリアに突っ込みたくないからなんだが、もう少しコース幅をいっぱいに使ったライン取るべきだと思うし、カートなんだから後輪滑らせるなよ＞オレ。これでも始めの頃と比べるとだいぶマシになってきたと思うけど。
タバコのecho。今日普段いかないコンビニに行ったら売ってたので買ってみた。喫煙暦20年以上になるが、echoとかわかばとかゴールデンバットとか吸ったことのない私。で、いま1本吸ってみたんだが、べつにそんな悪くないんじゃね？昔、当時まだ共産圏だった国で吸ったタバコよりはずっと吸える気がする。てゆーか、マイルドセブンよりはこっちの方が好きかもオレ。
キャメルがJTの偽キャメルになってしまって以来、なにを吸えばいいのか迷っているんだが、入手性がよくってそれなりに吸えるタバコってなかなかないよなあ。ウィンストンとか悪くないと思うんだけど、売ってるところ見つけるの大変だし。キャメルの前に吸っていたポール・モールも、やっぱり入手性は低い。まあ、他になんもなきゃマルボロでもいんだけどさ。
ウチの猫を病院に連れて行ったら、待合室に飼い犬のワクチン接種で来たらしい中年の夫婦がいた。犬はパピヨンで、名前は「ポコ」というらしいのだが、オバハンの方がいかにもオバハンライクな大声で、パピヨンに向かって「ポコちん！ポコちん！」としきりに話しかけていて、それってどうなのよ、ババア、と思うことしきり。ダンナが無口なのは、やっぱりそのせいだったんだろうか？
今日届いた。予想したより好印象。『The Red Shoes』よりよっぽどいい感じ。『The Dreaming』とか『Hounds of Love』とかの頃の凝りまくった音を期待すると全然違うんだけど、むしろ初期の頃に近い、ピアノ弾き語りで作曲したものを、フツーにレコーディングしましたって感じの作りなんだけど。地味に曲はいい。
『The Dreaming』とかをなかったことにしてしまえば、キンキン声で『Wuthering Heights』とか歌ってた姐ちゃんが、うまく歳とって落ち着いた歌うたいになったなあって感じで、いいレコードだと思う。
問題はやっぱり『The Dreaming』、『Hounds of Love』が比較するものがない名盤だってところなんだけど。
仕事柄、調査を兼ねて登録してみた。
無料で月間500万PVまではOK。Google AdWordsのクライアントなら無制限。単純なPV、ユーザー数カウント、アクセス元IPを使ったドメイン別、地域別(GeoIPマッピング)の集計、セッション解析、コンバージョン集計etc.、フツーいりそうなものは一通りそろってる。日本語訳はイマイチおかしいが。
これだけのもんを無料で出されちゃうと、ログ解析サービスで儲けてるところは辛そうだなあ。
とか言ってたら落ちてる(11/14 21:25現在)。とか言ってたら復活してる(11/14 22:36)。はよ、レポートでないかな。
少年は高校受験直前の今年一月、古山さんと廊下で会い「試験頑張れ」と声を掛けられた。合唱コンクールの際にも「頑張ろう」と古山さんに励まされた。少年はこの時初めて古山さんから励ましの言葉をかけられたといい、それ以来「少し気になる女の子になった」という。
だが、高校に入り交友関係が広がった古山さんは次第に少年と疎遠になる一方、少年は好意を強め、古山さんの自宅前で待ち伏せしたり、自転車で古山さんの周りを回ったりする姿が目撃されている。こうした行為を古山さんは「近寄らないでほしい。うざい」と友人にもらしていたという。
犯行当日、これまでの古山さんの態度について思いを巡らせ、「おれは何も悪いことをしていないのに腹が立つ。憎たらしい」と思い、古山さんの自宅に向かい自宅にいた古山さんを包丁で切りつけ殺害した。
お馴染みのパターンか……。オレも大学時代にこーゆー奴(男の方)から人生相談されて困ったことあるよ。「いっそ殺したい」とかフツーに言うもんな。田舎の男子校出身の奴とかに多いタイプ(偏見)。
世の中には、初めて言葉をかけてくれた姐ちゃんを恋人だと思い込んでひたすらついていく、アヒルの子供のような非モテ男子が結構いっぱいいるということを、年頃のお姐ちゃんは知っておくべきなのかもしれず。とはいえ、フツーの基準から言ったら、ごく当たり前の人付き合いの範囲の行動で、「優しくされた」と思っちゃうんだから気をつけてもどうにもならんのだよな。
とりあえず、「何も悪いことをしていない」だけで他人から好かれるわけではないということを、親とか社会とかは子供の頃から教育しておいた方がいいと思う。
公正取引委員会の報告書の方に、
我が国における広告取引において，広告効果やコストに対する広告主の意識が一般に必ずしも高くないことは，この分野において長年寡占的市場構造が続いてきたことがその背景となっていると考えられる一方，逆にこうした広告主の意識が寡占的市場構造が変わらない要因の一つともなっている。
という文があるけど、これに尽きると思うなあ。
非正規化すれば速くなると思ってるヒトって多いよな。まず正規化して、joinが必要ならjoinのパフォーマンスを限界までチューンするのが王道だろ。
非正規化って要するにjoinのprecomputationであって、precomputationのコストが見合う場合にのみ投入するべきテクニックだ。動的＆自動的なjoinのprecomputation＝materialized viewにするぐらいなら、どーせ元のテーブルに対する単純クエリーなんてほとんど実行しないんだから最初から静的に手作業でprecomputation(join)しとけーってことなんだから。
表が非常に小さくてprecomputingのコストがバカにできる場合はおいておくと、どっちの最適化をまずやるべきかっつったら、まずは正規形でのチューニングだよな。
今年はまだ食ってないなー。
去年の今頃、当時の最高値、500万円前後で落札されたトリュフは腐ってしまったって話だが、コイツの運命はいかに？しかし、キロ1000万円は高すぎだろ？せいぜい100万円じゃねーの？大きいトリュフの方がうまいもんなのかね？ってゆーか、1kgってフツーにスライスしてくれる分量で何人前？せいぜい1食分が数グラムってレベルだよなあ？
重さの割に高い食材っつーと、バニラビーンズとかカツオ節とかカラスミとかコノワタとかがキロ数万円ぐらいのレンジ？サフランがキロ十数万とか二十万円ぐらい？黒トリュフやキャビアもそんなもんか？そうやって考えると、まあ、キロ数十万円ってのは死ぬほど高くもないのだなあ、とか思ったり。
ネットのサービスって、大きなものを小分けにすることはできるんだけど、小さいものをくっつけて大きくするのは難しいんだよね。上位2割のユーザーが売り上げの8割を叩き出してくれるし、経費の8割もそこで発生するんだから、残りの8割の奴らは面倒くせーからタダにしちゃえって発想が成立するのも、そこかなって思う。リアルの商売でありがちな、「小口注文をいちいち相手にするの面倒くさいから、小口は相手にしない」ってのが、「小口注文をいちいち相手にするの面倒くさいから、小口はタダ」って理屈に変わってるんだよな。ソフトはタダで、サポートで(大口から)金取るっていう商売と同じ考え方だが。
それはさておき、Google Analyticsのユーザーはざっくり分けると、トラフィックの多いヒト・少ないヒトっていう2種類と、AdWords買ってくれるヒト・AdSenseを掲載してくれるヒト・どっちでもないヒトっていう3種類(AdWords買ってAdSense掲載してくれるヒトもいるだろうが)で、計6種類いるわけだけど。まずAdWordsを買ってくれてる、大口の顧客に関しては、これは顧客サービスの範囲内っつーことで理解できるよな。いっぱいAdWords買ってくれるからタダでAnalyticsつけてあげます。
小口のAdWords顧客に関しては、全体の8割が月間500万PVを下回る小口かもしれないが、そいつら全部あわせてもデータ量としては2割しかないんだったら、わざわざ課金システム作ったりサポート窓口作ったりするコストの方が、2割の追加投資より高いから、コイツらにもタダで提供しちゃえってのも分かる。
AdSense掲載してくれるヒトに関しては、Analytics導入してトラフィックが増えてくれる＆AdSenseのクリックが増えてくれればGoogleとしても儲かるわけで、しかもおそらくAnalyticsが処理しなければならないトラフィックに比例してAdSenseのクリックも増えるので、Googleとしてもメリットがある。俗に言うWin-Winの関係って奴だよな。なので、コイツらにもタダで提供してOK。
となると、残るはAdWordsも買わなければAdSenseも掲載していないユーザー。このうち月間500万PVを超えるような大口に関しては、Analyticsを利用するためにAdWords買ってくれればOKなので、Google的にはやっぱり問題なし。Analyticsを導入してがんばった結果として月間500万PVを超えてしまうような中口？もOK。Googleにとっての純粋なフリーライダーは、AdWordsも買わなきゃAdSenseも掲載しなくって月間500万PV以下の小口だけ。そいつらをタダ乗りさせてもペイするラインってのが月間500万PVだとGoogleは予想したんだろうな。
風邪ひいたので会社休んだ。薬屋いってストナアイビージェル買って飲んで、昼飯食ってしばらく寝たら少し復活。
日本語変換とゆーものを使い始めたのが、68なんとかなCPUにグリーンディスプレイと2Dフロッピー(2DDとか2HDでなく)のついたワープロ専用機で当然単文節変換(単漢字変換じゃないだけ当時としては画期的だった)。そのあとしばらくATOK系を使った後、長いことSKK、そのあとPOBox。いまも携帯は予測変換方式の奴だし、TungstenでもPOBox。
そーゆー生活してたせいか、どうもMS-IME使ってても単語〜単文節で変換しちゃう癖が抜けなくって、それが学習機能と相性悪いらしく、家のマシンも会社のマシンもかなり変な変換をしまくってくれる。かといって学習機能を完全にオフにするのも辛い。
つーわけで、単文節変換モードつくりませんか？＞Microsoftさん。
レポート出た。最初に見た時に、コンテンツ・オーバーレイとかって、ページ内のリンクのCTRとか表示してくれそうなメニューがあった気がするんだが、今見たらそれが見つからない。それが見たかったのになー。職業的関心で。負荷対策で削ったのかな。
レポートの内容を見る限りでは、ユーザー単位でのトランザクションを保持しなくても、すべての指標が計算できるようになっているようだ。一見、ユニークビジターを任意期間に対して計算できるようにするには、「日付、ユーザー識別子、ページ」みたいなデータを保持していないと重複排除ができないように思えるが、実際のところは「日付、ページ、前回訪問日、人数」とかって情報を持ってしまえば、日付が期間内で、なおかつ前回訪問日がNULLか期間外(前)のレコードについて、人数の合計を取得すればユニークビジターが計算できる。
もちろんそれとは別にユーザー単位でのトランザクションを保持することは勝手なので、「だからGoogleはAnalyticsで個人情報を保持していない」という話ではなくって(しかしざっと見た感じではユーザー識別子をアサインしてはいないように見えるし、クッキーはgoogleのドメインでなく集計対象サイトのドメインでの発行になるので、サイトをまたいでユーザーの行動を追跡することはできないように見える)、プライバシー話は置いておいて、ユーザー単位でのトランザクションの保持がmustでなければ、Analyticsのサービス提供に必要なストレージはかなり抑えることができる、というのがポイント。過去データをどのくらいまで取っておいてくれるつもりかしらないが、月間数百万PVとか数千万PVとかってレベルでは、Googleにとってはゴミみたいなデータ量にしかならないだろう。
前回訪問日をクライアント側で記憶させていて、毎回データ収集サーバの方に送っているのだとすると(urchin.jsちゃんと読んでないので想像だが)、送られてきたデータを片っ端からDBにインサートして、集計はsum取るだけの非常に軽い処理にしかならないので、計算量的にも大したことはない。レポートはデイリーなんので、実際には1日1回バッチでロードしてaggregateする(あるいはaggregateしてからロードする)だけの話だな。
と、以上の想像が当たってるとすると、技術的にどうこうってよりも、うまい具合に機能セットをチョイスして、うまい具合にクライアント側でデータ処理させて、Google側で必要なリソースを抑えてあるなあ、という感想。
生活するために、「人に食べさせてもらうために」無理に気に入らない相手と「共同体」を形成しなくてもいいということは、生き方の選択肢が拡がったということだとしかわたしは考えたことがなかったので、「窮屈」と考える人がいるのには軽いカルチャーショックを覚えた。
食い扶持を稼ぐ時だけ気に入らない相手とでも「共同体」を形成しておけば、残りの時間は好き勝手やってても許されるというのは、それで十分にありがたいことだなあとしか考えたことがないオレは、もっとカルチャーショックを覚えたかもしれない、とか言ってみる。
まあ、アレだろうな。そのなんだかよく分からない「既存の価値観」だか「共同体」だかから利潤を得ていた(つもりでいる)人間にとっては、「既存の価値観」のシェアが低下するってのは、既得権益が侵害されちゃったような気になるんだろうな。という議論はコメント欄にもあるか。オレはどっちかっつーと「共同体」とやらには入れてもらえなくて、明日世界が滅びてしまえばいいのにと思っていた側の人間なんので、そゆ考え方は理解できてもイマイチ実感がわかない。とりあえず「窮屈」というのは適切じゃないと思うんだが。
ちなみに念のため書いておくとコメント欄にある「piro」ってのはオレとは別人。多いよな＞piro/ぴろ。
open() と close()。そのまんま。openしてcloseすればいい。1個注意しなきゃいけないのは、MySQLは一度open()したテーブルを使いまわす場合があって、その場合はいったんclose()して再度open()するのではなく、reset() を呼び出せばストレージ・エンジンがopen()直後と同じ状態に復帰することを期待する、という点だ。なのでストレージ・エンジンがなんらかの状態を保持する場合、reset() (= extra(HA_EXTRA_RESET))を実装して状態をクリアするようにしておかなければいけない。たとえば先読みキャッシュを実装していたりとか、extra()で渡されるヒントを使ってアクセスを最適化したい場合とか。
RFC2616によるとHTTP 1.1準拠なweb鯖はGET http://hogehoge/ みたいな絶対URIでのリクエストをサポートしなければならないらしい。現状ではクライアントはproxyリクエストの場合しか、絶対URIでのリクエストを投げないが、将来的には絶対URIでのリクエストを必須にしたいので、鯖は今からサポートしやがれ、ということなんだそうな。
しかし、NameVirtualHostとかで明示的にホスト名を指定しない限り、apacheは自分がどういうホスト名でアクセスされる可能性があるのかを知らない。なので、NameVirtualHostで明示的に指定されているもの以外のHost名で絶対URIリクエストを受け取った場合、ホスト名部分は無視して、デフォルトのホストがURIのパス部分を要求をされたのと同じ振る舞いをする仕様なんだそうな。
で、実際、ブラウザのHTTPプロクシにapacheで動いている適当なホストのホスト名、たとえばhoge.comを指定して、好き勝手なURL http://任意のホスト名/path にアクセスすると、http://hoge.com/path の内容が返ってくる。
だからなんだ？と言われると、いや、それだけ、としか言いようがないのだが。
ギークなＴシャツとかの通販。仕事が充分ギークなので、服までギークになろうとは思わないけど、いくつかは欲しいなあ。
どこぞのサイトでMySQL4.1 vs 5.0のベンチマークとったら、5.0のInnoDBのパフォーマンスが4.1の1割しか出ないって話があったが、実はそれはinnodb_thread_concurrencyのデフォルトが変わっていたからだよん、というお話。
innodb_thread_concurrencyって、apacheで言えばMaxClientsに相当するようなパラメータで、小さすぎると鯖が遊ぶし、大きすぎると鯖が死ぬし、当然限界まで負荷かかるような状況での性能には相当影響するので、適切じゃなければ1割になっちゃうのも当たり前っちゃー当たり前。(もちょこっと詳しくはこのへんとか参照)
ま、教訓は「カリカリにチューニングしてない状態でのベンチマークなんて無意味」っていうお約束の話だな。
まー、アレだ。ホリエモンは少なくともニッポン放送買収劇で儲けたし、名目だけでも業務提携＆資本提携を取り付けたわけだから、ミキティとしては何も手に入れずに引くわけにゃあいかんのだろうなあ。
MySQLのテーブルから任意の1行をランダムに取り出す。
数値のidが振られているという前提なら、かなりエグいやり方としてはhandler構文を使って
handler entry open;
handler entry read index_on_id last where id <= @random_id;
handler entry close;
かな。handler構文ってどのバージョンからサポートされたんだっけか。
服を買いに、例によって新宿丸井メンズ館へGO。余計なもの買いまくって散財。まあ、でも、こうやって一度にまとめて買うからアレなだけで、一つ一つはそう高いもの買ってるわけじゃないんだよな。
新宿伊勢丹でチーズ買おうと思ってケースの前で悩んでたら、「ボージョレ・ヌーヴォーにあうチーズとかお探しですか？」と言われた。その後、焼酎と日本酒も買って丸井メンズ館に戻って、店員さんに買い物袋預かってもらった時に、中身は酒っすと言ったら、「ボージョレ・ヌーヴォーですか？」と言われた。
ボージョレ・ヌーヴォーってそんな大変なイベントなのか？
MySQLのLOAD DATA LOCAL INFILEって、クライアント側はどうやって処理すんのよ？とソース調べてて発見。サーバ側からのファイル要求はlibmysql中のcli_read_query_resultが処理してくれるので、クライアント側では要求されたファイルのopen, read, closeに対応するcallbackを用意すればいい。
いいな、これ。XMLなんてやめてS式にしようよ、テキストのマークアップもS式でやろうよとずっと思ってたんだけど、まさにコレだ。ちょっと研究しよう。
From: order-update@amazon.co.jp
Subject: Amazon.co.jpへのご注文について（#XXX-XXXXXXX-XXXXXXX）
To: piro@banana-fish.com
Cc: order-update@amazon.co.jp
Date: Mon, 21 Nov 2005 19:06:31 -0800
平素は、Amazon.co.jpをご利用いただき、誠にありがとうございます。
お客様よりご注文いただきました商品についてお知らせがございます。
件名のご注文番号にてご購入いただいた商品のうち、タイトルに"SONY
XCP CONTENT/COPY-PROTECTED CD"と表示されております商品にはXCP
digital rights management (DRM)ソフトウェアがインストールされ
ております。
このソフトウェアをPCで再生いたしますとセキュリティ上の懸念があ
るた、発売元である米国Sony BMGよりXCPソフトウェアが入ったCDの
販売停止の要請がありました。詳細につきましては、米国Sony BMGの
サイト（http://cp.sonybmg.com/xcp/）（英語）をご覧ください。
サラ・マクラクランのリミックス盤がひっかかった模様。
こないだオーケストラの楽器の値段を調べていて、楽器屋のサイトでハープが売ってるの見たら、なんとなくマルクス・ブラザーズを見たくなった。で、とりあえずこのパラマウント時代のBOXセット買ってみた。まだ『我輩はカモである』しか見てないが、やっぱマルクス・ブラザーズは面白いな。
ネット上のコミュニケーションに関する初心者と、技術に関する初心者がごっちゃになってないか、というのはさておき（大ざっぱには相関してるだろうし）。
世の中が悪意で満ち溢れていると思うのなら、それを教えてやればいいんであって、裸の王様状態で世の中から隔離して、その後そいつをどうやって面倒みてやるのよ？
ロングテール論じゃないけど、旧来のメディアと自分の人脈だけからでは入手できなかったような情報が手に入れられる、というのがネットの一番の利点だと思うのだが。それはもちろん自分にとって愉快な情報だけが手に入ることは意味していないわけだけど、でも、そのリスクは承知の上で自分だけの素敵な出会いを探してヒトは精を出しているんじゃないのか？初心者だからリスクの評価が間違ってることは大いにありそうだけど。
システム的に情報を遮断するというのは、そうやってせっかく自分の価値観にぴったりあった自分だけの素敵な情報を探している奴に対して、他人が先回りして「不愉快そうな情報」を隠してしまわるってことなわけで、それをやるなら逆に彼/彼女が求めているものを探してきてやるところまで責任持たなきゃだめだろ。国家は実際にそういった検閲をするけれど、(一応)その結果としての国民の幸せには責任を持っていることになっている。それが筋ってもんで、そこまでやらないならただの余計なお節介だ。
田舎から上京してきたばかりの冴えない純情童貞非モテ青年の前から、都会の洗練されたウッフン姉ちゃんを「どうせ相手にされないだろうから」と隠してまわるくらい余計なお世話じゃないのかね。
しかし、彼を立ち止まらせて「おい、お前さん、ウッフンガールはお前が考えている以上に甘くはないぜ？」と考えさせてもいいのではないか？
単純に立ち止まらせるだけなら、一言「ネットは怖いよ」と教えてやればいい(なんなら具体例も示してクドクドと教えてやればいい)だけの話なので、立ち止まって具体的に何かを学ばせる機会を与えるということだとして。
ネットの上での不特定多数の見知らぬ人間とのルーズな双方向コミュニケーションのようなもの(?)を上手く行なうには、それなりのスキルが必要であるから、いきなりその世界に飛び込ませる前に、心の準備なり訓練をする「教習所」的な場所が必要で（それを提供するコストがペイするのかはさておき）、そういった場所が提供されていて、そこにとどまるもよし、そこから出て行くもよし、戻るもよし、っていうのは妥当だと思うけど。でも、「教習所」ってのは自由と責任が制約されてはいるけれど、ホンモノの車に乗れる場所なわけだ。
リファラ、トラックバックetc.を一切封じるってのは、「不特定多数の見知らぬ人間とのルーズな双方向コミュニケーションのようなもの(?)」ではないものを提供しようとしているわけで、そこから「不特定多数の見知らぬ人間との(以下略)」について学ぶことができるかと言うと、たぶん無理。エロゲを渡して「まずこれで慣れたら、次は路上に出て実際の女の子にアタックしてみましょう」ってぐらい無理だと思う。シミュレータ教習にもならん。
それぐらいならむしろ、見知らぬヒトと文通してみるとか、交換日記してみるとか、あるいはもうすこしモダンな手段としてネトゲでもやらせる方がよっぽど教育的効果は高いのではないかと(恋愛にしても、ネットにしても)。
あるいは一定の閾値を越えた記事を書いた時に一斉にブックマークされて一斉にコメントされるのがショック受けちゃう理由かもしれないので、日頃からつまらない記事にもいちいちコメントつけてくれるヒトがいるといいのかもしれない。「今日は朝起きて仕事して酒飲んで寝た」だけ書いても、「つまんねーよ」とか「昨日と同じじゃん」とか「食事はしなかったんですか？」とかいちいちコメントしてくれるの。それだと本人も書いた文章に対して思い入れがない分、ショックも少なかろう。もちろん記事の内容に応じたコメントがつく、記事が痛ければコメントも辛らつになること重要。必ずコメントしてもらえる日記コミュニティサイト。素敵じゃん。教育的効果もあるし、日記書く励みにもなる。
ついでに抽選箱と手袋もオマケでつけといて欲しかった。
大胆っていうか……。
容積だけの問題なら、1Uのサーバ5000台(あるいは2500台)って、40フィートコンテナに詰め込めるよな。下の方のサーバが重さで潰れる気がするが。つか、そこでがんばるくらいなら、素直にトラックの台数増やした方がいい気がする。コンテナに詰め込んだサーバの台数で、ギネスの記録申請するならともかく。電源つなげばOKの状態でデータセンターに送れば、現地での設置の手間が省けるってのはあるけど、メーカーがそれやってくれるならともかく、自分たちでやるんだったら、どこでラッキングするかの違いだけだよな。
40フィートコンテナに詰め込んだ状態で動かすという話だとすると(元記事読むとそれっぽい)、空き地にコンテナおいて、地面から掘り出したダークファイバつないで、下手したら電源は発動発電機で自家発電っていう屋台の焼き鳥屋みたいなイメージ？それはどう考えても無理というか、設置場所に充分な電力と冷却設備があることをアテにできるなら、やっぱりべつにがんばって詰め込む必要ないし。仮に冷却装置はコンテナに詰め込めたとしても、数百kWの電源を用意して、防犯システム/警備員置いて、そのための施設も置いて……って考えたら、安普請のデータセンター建ててもトータルじゃ変わらないだろ？ていうか、コンテナの積み下ろし用のクレーンはどうするの？
神武天皇以来のY染色体を守るためにも男系継承でなくちゃならんと言う人々がいるそうで。だから偉いのかっていったら、万世一系と一緒でオレのY染色体だって、2000年前の男系祖先の誰ぞのY染色体だよって話なので、だからどうした？って感じなのだが、まあ、それが天皇制のアイデンティティだとゆーなら、それはそれでいいんでないのと思うし、有識者会議の提案する女性天皇・女系継承容認案ってのも、それって一度皇族の遺伝子にコンタミされたら、みんな皇族っていうバイオ・ホラーみたいな話だよな、とも思わなくもなく。
そういったことは全てさておき、本当に天皇家が系図の通り神武以来のY染色体を受け継いでいるのだとしたら、2000年間一度も嫁に浮気されなかった家系として、それはそれで尊敬に値するのか、とか思ったり。いや、まあ、浮気されても子供ができなきゃいいんだけどな。神武以来で七十何世代ぐらいになるんだっけ？フツーだったら絶対に何人かは不義の子だと思うんだけどな。
……2000年間？それは西暦か。神武紀元は西暦＋660年だっけ？
データのskewのかかり方の問題から、それを言ったらGoogle Toolbarの情報の方が上質なんでないの、という気がする。あれってPageRankを取得するために、Googleにユーザーが閲覧中のURL送るでしょ？(これ)
Analyticsがドメイン間の移動を検知できるのは、移動先がAnalytics入れている場合(リファラから)か、移動元サイトが__utmLinkerを仕込んでいた場合に限定されるので、「義理リンクやスパムＴＢ」なリンク先と、単にAnalytics入れてないだけのリンク先を区別するのは難しいはず。__ulmLinkerは置いておくと、あくまで移動元と移動先の両方がAnalyticsを入れている場合に限って、その間のトラフィックの多寡が分かるに過ぎない。世の中「フツーGoogle Analytics」な状況になれば、また話は違うだろうが、さすがにそれはないだろう。ユーザーのweb閲覧行動を分析しようと思った時に、30%のサイトのトラフィックが取れる(Analytics)のと、30%のユーザーのトラフィックが取れる(Toolbar)のと、どっちがデータとして分析しやすいかって言えば、もちろん後者の方だ。前者は欠損のあるデータだが、後者はサンプリング・バイアスはかかっているだろうが欠損のないデータだから。
バルクロード(LOAD DATA [LOCAL] INFILE)の際の、ロード・ファイルのパース/内部表現への変換のCPU負荷が気になる。内部表現に近い形のファイルからロードする方法が欲しいなあ。binlog使ったmaster-slave間のデータ同期って内部表現使うんだっけか？ダミーのmysqldにblackholeストレージ・エンジンつかってbinlog書かせておいて、そいつとの同期を取ることでロードするってのを、今思いついたけど、それが上手くいったとしても、なんか美しくないよな。sql_load.ccあたりをちょこっといじれば、そういう機能足せるかしらん。
彼らの言っていることは、手続きが厳守されることを前提にtry〜catchを省略してアプリケーションを設計するが如しである。
うーん。そうじゃなくて、モヒカン族のヒトは、リファラやコメントを隠すという解決が、エラーが発生しているのに例外あげないで、テキトーに処理して誤魔化しちゃうようなもんだと言っているんだと思うのだが。
趣味もないし、コレクターでもないという人は、料理の腕を見せるとか
それ、立派な趣味だろ＞料理の腕。違うのか？
趣味もないし、コレクターでもないという人は、彼女の趣味/コレクション見物を口実に彼女の部屋にあがりこめばいいのだ。
つか、趣味/コレクションを口実に部屋に呼べるお姉ちゃんは、どんなやり方しても大抵どうにかできるから大丈夫だろ。趣味/コレクションだけで好きでもない男の部屋になんか行かないって、フツー。友達として好きなだけかもしれないので、いきなり押し倒すのはまずいと思うが。
あと、
デート帰りに「コーヒーでも飲んでいかない? いや、その、何もしないから」と誘うのは、いかにも……すぎるし
「何もしないから」とか余計なコト付け加えるのがマヌケなんであって、とりあえず「コーヒーでも飲んでく？」って言ってパスされたら、「やあ、ボクは親切で言っただけで下心なんて全然ありませんから」って顔で平然とスルーしとけばいいのに。それを何回か繰り返してれば、そのうちコーヒー飲みにくるから。そして、それが繰り返せない相手にはたぶん好かれていないから。
オイラも同じことを色々考えたけど上手いやり方が思いつかなかったので、sudoから起動されたコマンドがexecしたコマンドの記録が取れればいいのなら、いっそのことexecveをフックしてsyslogに書かせりゃいいんじゃないか、と思った。
sudo1.6.8で追加されたNOEXEC機構は、コマンドの実行時に常にEACCESSを返すexec関数群を含むsudo_noexec.soをLD_PRELOADでプリロードするわけで、これをこんなコードと差し替えてやれば(libcをstaticリンクしていないプログラムについては)、実行のログががっちり取れる。sudo_noexec.soを置き換えるなんてことはしなくても、LD_PRELOADを明示的に渡してもいいわけだが。
でも、あやしい手段なので、まだ実戦には投入していなかったりｗ
改ざんを見抜けなかったことについて、大蔵市長は「厚さ１０センチに達する書類に数字が羅列されている。建築確認申請が出てから、それを一つ一つ３週間のうちにチェックするのは厳しい」と説明している。
それが仕事だろ、バカタレ。チェックするのが厳しかったら、人員増やすなり、業務フロー改善するなり、それでも無理なら期限伸ばすなりするもんだ。
素敵な基地外っぷり。モンティ・パイソンみたいだ。
この記事だけじゃなくて、はてなブックマークになんらかの制限を要求する意見に対して一般的に感じる違和感なんだけど、「低リテラシーユーザーへの抑制機構」を設けるのであれば、はてなブックマークでコメントつける側だけでなく、つけられる側にも必要だと思うな。ていうか、極端な話、ネット上での公開された言論すべてについての抑制機構が必要なんでないかと。オレはブログになんでも書くが、それに対する批判は聞きたくない、というのは教育上もよろしくないので、「自分が抑制しただけ他人も抑制される」システムであるべきだ。
その場合の「リテラシー」って、どこかの誰かに定義してもらうものではなくて、「オレが気に入らない奴は低リテラシー」っていうオレサマ法であるべきで（はてなが定義した「高リテラシー」なユーザーが気に食わないって奴だっているだろう）、結局OpenID+FOAFみたいな仕掛け使って、自分の言論を公開する範囲をドメインとかユーザーIDってレベルではなくって、もっと繊細にコミュニティの距離を使ってチョイスできる仕掛けであるべきなんじゃないのかな、と。で、初心者のために、デフォルトの公開範囲は狭くしておいてやると。
ツレと二人でバイクで昼飯食いに出かける。ツレはGSXR-400R(GK76A)、オレはVolty。当たり前だがさっくりおいてけぼり。ムカつく、このアマ。普通二輪の範囲でGK76Aをブチ抜けるバイクってなんだ？現行車種だとなさそうだよなあ。やっぱVFRとかFZRとかZXRとかじゃないとダメか？
自分が開発したレシピを結構忘れているということに気がついたので、メシを作ったらメモることにしようと思う。
つーわけで、今日の夕飯。成城石井でファッロが売ってたので牛肉とキノコのファロット。
材料：
ファッロ(スペルト小麦):1カップ
シチュー用牛スネ肉:200gぐらいだったっけ？
タマネギ:昨日サーモンの添え物に1/4使った残り
セロリ:1本
ニンジン:1/2本
キノコ:(今日はマイタケとシメジ)適当
塩、コショウ、クミン、タイム、ベイリーフ、ニンニク
白ワイン:1カップ
水:適当
オリーブオイル:適当
ファッロは米と同じように研いでおく。スネ肉は水にさらして血を抜く。タマネギ、セロリ、ニンジンはアシェにする。スネ肉とアシェにした香味野菜をひたひた＋αぐらいの水で茹でて、丁寧にアクを取る。しばらくしてアクが出なくなったら、すべてを圧力鍋にブチ込み、白ワイン、タイム、ベイリーフ、クミンを適当に加え、適当に塩コショウして15分中火で煮る。
その間に、鍋にオリーブオイルを敷き、アシェにしたニンニクと適当にちぎったキノコを適当に塩・コショウして軽く炒める。圧力鍋の錘が落ちたら、キノコの鍋に中身を移して混ぜ、塩・コショウで味を調える。
最近、近所のスーパーで見かける男前豆腐とかって豆腐がある。ネーミングはバカだが、味は割りといける。しかし、食の細い年寄りには1パック400g近い量は辛いものがある。ぜひ小さいパックを出して欲しいなあ。
ところで、豆腐屋ジョニイと言われと、首の後ろにジョウロさして頭に豆腐入れて運ぶのか、とか思ってしまったのは別に秘密でもなんでもない。懐かしいな＞記憶屋ジョニイ。
つーわけで、今日は男前豆腐の「湯豆腐野郎」を買った。で、フツーに麻婆豆腐にしようと思ったのだが、あけてみたら、むしろ寄せ豆腐に近い感じの豆腐だった＞湯豆腐野郎。豆腐屋ジョニイより大豆度が高いっつーか、ねっとりとした感じ。
なので、麻婆豆腐っつーよりは麻婆あんかけ豆腐みたいな方向性で。
豆腐: 200gぐらい
ひき肉(牛豚合挽き): 200gぐらい
葱: 2本
黄ニラ:適当
生姜：1片
ニンニク:2片
花椒:大匙2杯
花椒粉:大匙1杯
五香粉:大匙1杯
クミン・シード:小さじ1杯
ベイリーフ:1枚
唐辛子粉:大匙2杯
粉末スープ:適当
豆板醤:適当
紹興酒:適当
片栗粉:適当
サラダ油、ゴマ油:それぞれ適当
葱の青いところ、ショウガ、ニンニクを適当にざくざく切って、花椒、クミン・シード、ベイリーフと一緒に100ccぐらいの油で中火ぐらいで炒めて香りを出す。金属ボウルに花椒粉、五香粉、唐辛子粉を入れて、少量の水で練り、そこに先ほどの油を投入してかき混ぜて放置。これでラー油ができる。
このラー油でひき肉、みじん切りの葱＆黄ニラを炒めて、水・紹興酒を加え、豆板醤、粉末スープで味を整えたら、片栗粉でトロ味を強めにつけ、ゴマ油を少量混ぜる。
レンジでチンして温めておいた豆腐の上から、この麻婆ダレをかけて完成。
レコードの内部表現について。
レコードの内部表現をかいつまんで言うと、先頭に削除済みレコード、NULL値のフラグが入ったbit field、その後各カラムのバイナリ表現が素直に並んだバイト列、って感じ。
先頭のbit fieldは、まず1バイト目のLSBが削除済みレコードかどうかを示すフラグ。0なら削除済み。その後、create tableでの定義の順番にLSBからMSBに向かってnullableなカラムの数だけNULLかどうかのフラグをあらわすbit。1ならNULL。あまったbitは1。
あとはintegerなら4バイト、char(10)なら10バイトってな具合に、自然な幅・表現で各カラムの内容が定義された順番に並ぶ。varchar,varbyteに関しては長さ＋最大幅分のバイトという、これも自然な幅・表現だ。
この表現で1レコードを表した時に必要となる領域のサイズ(bytes)は、TABLE構造体tableのtable->s->reclengthに入っている。またTABLE構造体にはあらかじめ2レコード分の領域がtable->record[2] として確保されていて、大抵の場合record[0]に読み書きしたいレコードを格納して扱うことになっている。
メモ
(http://d.hatena.ne.jp/koyachi/20051127/1133026272)
ファイル/ネットからの読み書きを効率化するのに、IO_CACHEとかって仕掛け用意してるのか、へー、とか思って使ってみたら、なんか上手く動かない。常に上手く動かないのではなくて、ローカル・ファイルからの読み込みは上手くいくが、ネット(クライアント)からの読み込みだけ上手くいかない。
なんでだ？と思って調べてたら、クライアントからのread()に相当する_my_b_net_read()とかって関数の実装が、引数に読み込みたいバイト数を指定させるにも関わらず、どーせLOAD DATA LOCAL INFILEでの1文字単位での読み込みにしか使わないからって、1文字(バイト)しか読み込み用バッファにコピーしないような実装になってたよ。ご丁寧にattribute unusedの指定までしてある。orz……。
MySQLのコードのこういうノリはどうも好きになれんなあ。
ノートPC鯖にFreeBSD 6.0 入れた。安定して動いているみたいなので、ひさびさにDNSをノートPC鯖の方に切り替えてみた。これでOKなら次はwebを切り替えるか。
_ Taka [analyticsについてなのですが、あのエントリではanalyticsで収集した情報が、そのサイトのランクに影響す..]
_ ぴ [サイトの「ランク」は、全サイトの中でどの程度の人気があるかという指標なわけですよね？25人の男子がいるクラスである5..]