Strawberry PerlにDBD::mysqlインストール - kazuhoのメモ置き場dev.mysql.com から MSI 形式のインストーラをダウンロード 開発用ヘッダやライブラリも含めて、mysql をインストール mysql の scripts\mysql_config.pl を bin\ にコピー 管理者権限で cmd.exe を起動して cpan, force install DBD::mysql
vipっていうviラッパー作った - kazuhoのメモ置き場
http://github.com/kazuho/vip/ よくperlとかで、 $ perl print "テストコードを色々..."; ... ^Dとかやってテストするけど、コード書き間違えちゃったりした時に編集できなくてめんどいのと、書いたコードが失われちゃうのが嫌だなあと思ってた。で、ついに重い腰をあげて、２つの問題を解決するラッパー書いた。 $ vip | perlとかやると、vi で編集した結果を標準出力にはいてくれる。ファイルは $HOME/vip 以下に保存されるので、あとから探すこともできる。 以下FAQ Q. $ENV{EDITOR} を見てくれないのですが? A. vip (vi pipe) なので vi 専用です ... てか vip 言いたいだけ (ry
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
C/C++に文字エンコーディングバリデーション機能がないって、ほんと？ - kazuhoのメモ置き場
通りすがり (2009-09-16 18:09) > PHP以外の言語は「(略)」のに対し ここに挙げられている言語がWebアプリで使われる全ての言語ではない。 例えば、CやC++にはない。付け足せば、PHPやPerlなどのCモジュール内部で起こった不正な文字はスルーされうる。 よって、「Perl、Java、.NET、Ruby、PHPの中では」と書けば筋は通るが、「PHP以外では」は誤り。 そしてそんなことを、PHPの(脆弱性撲滅に注力している)開発者に言ったら、喧嘩を売られたと受け止められて当然。 PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14) というコメントが気になった。 C言語にある文字コード変換機能って言ったら mbtowc だと思うけど、mbtowc は無効なバイト列を受け取ると EILSEQ を返すことに
「Linux-DBシステム構築／運用入門」がすごい - あなたのシステム、ガラパゴス化していませんか？ - kazuhoのメモ置き場
松信さんがやってくれました。 ずいぶん前からデータベースの「正しい」構築と運用方法についてまとめた本はないかなーと思ってました。自分はこれまで、様々なネットワークアプリケーションのプログラミングやデータベースの設計、チューニングを行ってきています*1が、問題が解決できたようには見えても、果たしてそれが最適な解決策だったのか不安に感じることがありました。それは、体系的な知識に欠けているからです。だから、網羅的な教科書がほしいなぁって思ってたんです。 とあるインターネットでこの前、松信さんから「いま書いてる」って話を聞いて、一部を見せていただいたりしたんですが、つい昨日、手元に届きました。やったね☆ 名前は「Linux-DBシステム構築／運用入門」。「入門」と銘打たれているものの、基礎的な知識から、なぜそうなるのか、どう応用すればいいのか、といった点まで広くカバーしている*2、全方位的な隙のな
JavaScript で任意の漢字にマッチする正規表現を書く - kazuhoのメモ置き場
重箱の隅で恐縮ですが。弾さんは (function(e){ e.innerHTML = e.innerHTML.replace( /東京都?([\u3200-\u4DBF\u4E00-\u9FFF\uF900-\uFAFF]+)/g, '首都$1東京' ) })(document.body)漢字を判定する正規表現が工夫のしどころでしょうか。[一-龠]はUnicode時代にはちょっと古い。grep CJK /usr/local/lib/perl5/5.10.0/unicore/Blocks.txtが参考資料代わりです。CJK Unified Ideographだけ欲しければ[\u4E00-\u9FFF]でも行けます。 404 Blog Not Found:javascript+regexp - ていうか首都最強東京bookmarklet とおっしゃってるけど、[\u4E00-\u9FFF]
DNS移行の際の旧ネームサーバの取り扱いについて - kazuhoのメモ置き場
キャッシュサーバーの実装がおかしいとか言ってる人がちらほらいるんですが、NSレコードのTTLが切れている場合には必ず「上位のネームサーバーから再問い合わせすべき」なんですかね。ドメイン移管時なんかを除いてはほぼ確実に同じNSレコードが返ってくるでしょうから、先ずは同じネームサーバーを参照するのは悪い実装ではない(もちろんその際に新しいNSレコードが返ればそれをキャッシュする)と思うのですが「そうすべきでない」というような根拠があるなら教えてください。(ソース読んだ限り、失敗した場合は上位のネームサーバーに問い合わせるようになってました) 「TTLが切れている=古い可能性がある」であって「そのネームサーバーが信頼できない」というわけではないでしょう。 DNSのキャッシュについて - 金利0無利息キャッシング – キャッシングできます - subtech DJBDNS の以下の記述を見る限り、
memcached を SSD で動かす方法 - id:kazuhookuのメモ置き場
Re memcachedのストレージにSSDを使うアイディア - sdyuki-devel とりあえず、新たにサーバを開発しなくても、 SSD 全体をスワップに指定 memcached を CPU + SSDドライブ数 * 4 とかに指定 SSD の I/O ってどの程度多重化するといいんだろう (NCQ まわりとか?) 10/29 追記: 手元の環境では多重化によるパフォーマンス向上は観測できなかった (Kazuho at Work: Benchmarking SSD for MySQL) memcached の使用するメモリ合計をスワップーαに設定 ってやれば、ある程度の目算はたつんじゃないかなぁと思った。というのを書こうと思って忘れてた。 個人的には、あまり実メモリ:SSD容量の比率を極端にできない→それほどおいしくない、んじゃないかと思ってるけど、そんなのは机上の空論にすぎないわけ
MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに１回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に
MySQL+Java でサーバサイドプリペアードステートメントを使うべきで「ない」理由 - kazuhoのメモ置き場
useServerPrepStmtsのここの説明ではデフォルトがtrueになっているが、これは上述の通り嘘である。 (中略) そしてなぜfalseにされたかということの背景を察すると、trueにすることの弊害もありそうで、手放しでこれをtrueにすることを勧めることが少しはばかられる。 http://www.geminium.com/chiba_blog/2008/12/23/33/ 自分は Java 使ってないですが、MySQL の中の人が使うなって言ってます *1。その理由はメモリリークのような症状が出る可能性があるから。 So why are prepared statements a problem? Because users do not clean up/close unused prepared statements. Multiply the number of prep
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Q. UTF-8 の冗長性問題は、設計上の問題なのか? - kazuhoのメモ置き場
