若い人たちは、「文字列型」があるプログラミング言語しか知らないかもしれない。だが、汎用的な文字列型が一般的になったのは、プログラミング言語の歴史の中でも比較的最近のことである。 たとえば、1972年に誕生したC言語には文字列型がない。1980年代に良く使われていたPascalの文字列型は最大255文字しか格納できなかった。 なぜか？ それはメモリが貴重なリソースだったから。 1980年代のPCの搭載メモリは多くて数メガバイト。これに対し、長編小説の長さは1MB程度に達する*1。 当時、メモリはとても貴重な資源であり、テキストを処理するプログラムを開発するにあたっては、文字列をどのようにメモリ内に展開するかプログラマが細かくコーディングする必要があった。 だから、汎用的な「文字列型」というのは「夢」にすぎなかった。CあるいはPascalにおける文字列（CのASCIIZ文字列あるいはPasca
JavaScript文字列のエスケープ – yohgaki's blog に対して、 最近だと id="hoge" data-foo="<% bar %>" しておいて $("#hoge").data('foo') でとりだすのが主流かと思います。 はてなブックマーク - JavaScript文字列のエスケープ – yohgaki's blog のように、 そもそもJavaScriptコードを動的生成すべきでない JavaScriptコードに渡す変数はHTMLノードを経由すべきだ というような反論がついています。 が、はたしてそうでしょうか。 僕には、元の記事の手法も、HTMLノードを経由する手法もあまり好ましくない*1ように思えます。 そもそも、HTML生成時にXSS脆弱性が発生しがちなのは、 タグや静的な文字列と動的に生成される文字列が混在し 埋め込まれる多数の文字列を正しくエスケープ
Twitter で聞いてみたところ @hasegawayosuke さんいわく、Bookmarklet の文字数制限は最短だと約2,000文字らしいです。 でも、その長さで bookmarklet を書くのって難しいですよね。かといって、別のサーバから JavaScript をダウンロードして実行するとなると、そのダウンロードされたスクリプトが安全か、という問題が出てきます。 ならば、暗号学的ハッシュ関数を2,000文字以下で実装し、ダウンロードしたスクリプトの改ざん検証を行った上で実行すればいいのではないか。そうすれば、文字数の制限に悩むことなく Bookmarklet の開発に勤しめるのではないでしょうか。 ジャジャーン！というわけで、とても短い SHA-1 の JavaScript 実装を作りました*1。 GitHub - kazuho/sha1.min.js: SHA-1 impl
Labeled Tab-separated Values (LTSV) がブームのようです。 LTSV については、ラベルをつけることで柔軟に拡張できるという点が、その特徴として取り上げられますが、もう一点、タブをセパレータに使うことでログのパースが簡単になった、という点を忘れるべきではないでしょう。 特に httpd のログは NCSA httpd という HTTP/0.9 時代のWebサーバのログフォーマットがベースに拡張されてきたため、以下のようにセパレータとして空白、[]、ダブルクォート ("")*1が混在するという、とても処理しづらいものになっていました。どれほど複雑かは「404 Blog Not Found:perl - Apache Combined Log を LTSV に」の実装を見れば明らかでしょう。 127.0.0.1 - - [08/Feb/2012:23:52:4
常識を覆すソートアルゴリズム！その名も"sleep sort"！ - Islands in the byte streamを読んで、自分が書くとしたらこんな感じかなーと思った。多重化して select 使う必要ないよねということで。 use Time::HiRes qw(sleep); sub sleep_sort { # create pipe pipe(my $rfh, my $wfh) or die "pipe failed: $!"; # spawn the processes my @pids; while (@_) { my $value = shift; my $pid = fork; die "fork failed: $!" unless defined $pid; if ($pid == 0) { # child process $| = 1; sleep $value
sleep sort とか環境にやさしすぎて21世紀には不向きだと思うの。なので nicesort なるものを作ってみた。 #! /bin/bash function f() { nice -n "$1" perl -we 'for (1..1000000) {}' echo "$1" } while [ -n "$1" ] ; do f "$1" & shift done wait こんな感じで動きます。注意点としては、マルチコアだとうまく動かないので taskset 使いましょう (linux の場合) ってのと、0-20の範囲でしかそーとできないよってあたりかしら. $ taskset 1 ./nicesort.sh 1 9 6 4 1 4 6 9ちなみに、nice 値が１増えると実行時間は1.25倍になる。これは試験に出るよ！ 参考: 革命の日々！ CFSのnice値について
デーモン側をこんな感じで書きます。 use Errno qw(EEXIST); use Fcntl qw(S_IFIFO); use POSIX qw(mkfifo); my $FIFO_NAME = "/tmp/my_messenger.fifo"; if (mkfifo($FIFO_NAME, 0666)) { # ok } elsif ($! == EEXIST) { die "$FIFO_NAME is not a fifo!" unless +(stat($FIFO_NAME) & !S_IFIFO) != 0; } else { die "failed to create fifo:$FIFO_NAME, $!"; } while (1) { open my $fh, '<', $FIFO_NAME or die "failed to open fifo:$FIFO_NAME,
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
Apache の設定ファイルおける AddType を Plack でどうやるのか。 Plack::App::File (あるいはそれをラップしている Plack::Middleware::Static) は、拡張子から Content-Type を決定するのに MIME::Types を使っている thanks to miyagawa-san。 なので、たとえば Apache の AddType application/x-xpinstall .xpi AddType application/octet-stream .msiに対応する Plack::App::File の設定は、 MIME::Types->new(); MIME::Types->addType( MIME::Type->new( type => 'application/x-xpinstall', extensions
_ djb が自作ツールの更新を放棄してからずいぶんたって、qmail やら djbdns やらはゆっくりと置き替えが進んでいるようだ。が、いまだに使い続けられているものもある。具体的には daemontools。いまだに daemontools を 使うネタが書かれているのを見て絶望した。代替物はほかにもあるのに。 (中略) _ そんなわけで、わしのことを anti djb だと思っている一部の方々が飽きて燃料投下を望んでいるような声をだいぶ前にどっか(どこだか忘れた)で見かけたので、要望に答えて若干 djb を dis り気味に runit と ipsvd を解説してみました。わしゃ別に「いいものを使う」というだけで、djb が嫌いなわけでもなんでもないんだけどね。ちなみに、自分自身では好き嫌い以前に必要性を感じてないので使っておりませぬ(これ書くために何年かぶりにインストールした)。
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
通りすがり (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 を返すことに
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
2009年7月6日追記: 以下は svn switch あるいは svn switch --relocate が使えない場合の話です。 Subversion のレポジトリが移行したときに、手元に co してあるソースをそのまま、レポジトリの URL だけを書き換えたいことって結構ある。 ＃運用サーバへのデプロイが svn co だったりすると で、.svn/entries を書き換えるって手もあるらしいけど、なんかうまく行かなかったので、.svn ディレクトリを新しいレポジトリから取ってきたやつに差し替える方法で対処。以下手順。 % svn co http://new-repo /tmp/new-repo % (cd cur-repo && find . -name .svn -type d) > /tmp/cur-repo.dotsvn % (cd /tmp/new-repo && fi
講演は ustream で見て、懇親会だけ参加してきた。かな〜り勉強になった。GAE Data Store 関連でよくわからないことがあったので、２点質問をした。 Q. entity を更新してから index を更新していると言うが、それだと unique secondary index はサポートできないと思うのだが、どうか。 A. unique secondary index については、別途テーブルを作って管理してください。 感想. 複数の、ノードを跨がる unique secondary index があると 2-phase commit 的な話になるので、その割り切りはアリなのかなー。 Q. range query をサポートしていないというが、sharded, sorted array なのに何故？ A. 上下の両界をサポートしていないだけで、片方を指定した ascendin
クライアントの調整 Mac OS X の AFP クライアントには、サーバに対するネットワーク遅延をチェックし、その結果を基にパケットサイズを選択する機能が備わっています。そのために、クライアントは、AFP 接続を開始するために最初にサーバに送信するパケットの応答時間を測定します。この応答時間は、ミリ秒単位で測定され、AFP クライアントの変更可能な設定となっています。 (以下略) Mac OS X Server: クライアントおよびサーバで AppleShare のパフォーマンスを調整する Leopard の場合は設定箇所が変更されていて、問答無用でパケットサイズを 128KB にするときは defaults write /Library/Preferences/com.apple.AppleShareClient afp_wan_quantum -int 131072
404 Blog Not Found:デバッグより重要なもの 2009-04-02 あたりの議論は正直よくわかんないけど、以下、駄文。 データフォーマットとしてバイナリを推す派 vs. テキスト派の対立ってのは、別に最近始まったことじゃないわけで。この問題について自分が一番印象に残っているのは、 The Montagues and the Capulets (A shorter history of contending philosophies) というスライド。著者の Larmouth 教授は ASN.1 関係の人なので、バイナリよりの視点になっているかもというのと、あと XML Schema とかそのへんの進捗は入ってない古いスライドなのかなぁ、とも思いますが、でも両派の戦いをロミオとジュリエットに例えたり、「石器時代には〜」とか書いていたりして、おもしろい。 いずれにせよ、バイナリ
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
