おさかなラボ - 冤罪で捕まった時知っておいた方がいいこと
ちょっと長いですが引用します 第17回 オタクだけが残った〜竹熊健太郎氏との対話（3） 竹熊 うん。ひろゆき氏の場合はね、もともと２ちゃんねる やる前に、交通違反のもみ消しサイトっていうのをやってた んだよね。当時は彼、原付でそのへんを走っていたから。 ―――（爆笑）そうなんですか。 竹熊 どうやってもみ消すかっていうとね。たとえ警官の 目の前でスピード違反やったとしても「私はやってません」 って言い張るんだって。すると警官が激怒して、「署に来い」 ってことになるでしょう。それで署に行って、５時間でも ６時間でも「お巡りさんの見間違いじゃないですか。私は やってません」って言い張るんだって。するとどうなるかって いうと、最後は警察が勘弁してくれと言い出す。つまり、 それ以上のことをやろうとすると、警察が告訴して裁判を 起こすしかないわけですよ。で、警察組織としてはたかが原付 のスピード違反
おさかなラボ - iPadのVNCがハンパじゃない件
追記： 1,200円とちょっと高いけど、iSSH SSH / VNC Consoleという製品がヤバい。ヤバすぎる。xterm-colorも対応してるから何でも出来る。複数の端末に同時接続したりできるらしい。忙しいのでまたあとで。 iPadでVNCを試してみたのだがこれはiPhone版と違ってかなり使える。動きもサクサクだしマウスやキーボードもタッチスクリーンで制御することができる。 ためしに、ピクセル比を１にして撮影してみた。 スナップショット 個人情報が丸出しだったのでぼかしてある。 縮小せずにこれだけ表示できるのだから、一般のディスプレイのかなりの範囲をカバーしている(*)。そしてWindowsの一般的なVNCクライアントよりも高速に感じる。 それにしても、自宅に固定アドレスを持っている人はパソコンにVNCサーバーを立ち上げっぱなしにしておけば、「あー自宅にExcel忘れてきた！」と
おさかなラボ - WebSocketsや永続的接続で死ぬのは誰か
近年、AjaxやHTTPそのものの代替としてWebSocketの実装や永続的接続の話題が絶えないが、今回はこれに関して検証してみることにする。 永続的接続というのは、つまりはソケット同士の繋ぎっぱなしを意味する。C10K問題が騒がれているなかで、これは現実的なソリューションなのか考えてみよう。 まず永続的接続でリソースが奪われるという話だが、これは当を得た理屈ではない。現実にAjaxがあることを忘れている。Ajaxはリクエストが発行されるごとにコネクションを張り、相手のプロセスを１つ独占し、余計なヘッダ流し、余計なヘッダをもらい、本来なら数バイトで済むようなやりとりも1KB近く消費する。リソースを奪っているのはAjaxの方なのだ。 永続的接続であれば、単にサーバーに「get user 13」などと予め決めたプロトコルを流すとすぐ答えが帰ってくる。コネクションもヘッダもいらない非常に軽量なも
おさかなラボ - Perlの日本語ドキュメントポータルは速やかに刷新すべき
と思いこんなものを作ってみました。α版なので細かいツッコミは歓迎ですが寛容にお願いします。当然気づいているバグもあるのですが、ケツを叩かれるとのそのそ動くのが私の習性なので。デザインの著作権を侵していますが、勝手な都合でsearch.cpan.orgの方から警告があるまではこのままにします。 http://kaede.to:8000/ 断言します。日本のPerlコミュニティには、このような、別の形の日本語Perlドキュメントポータルが絶対に必要です。 これは、しばらくは動くようにしておきます（なるべく・1ヶ月くらい？）。その後状況をみてなるべく当社とは関係ない（最終的には全く関係ない）ドメインでどこかに移転します。それ以降にデッドリンクになっているのを見つけた方は、canadie at gmail まで一言頂けると助かります（他力リマインダ）。 なお動いているのは弱小サーバーでしかも多段P
おさかなラボ - Coroでより賢い非同期クローラを作る
前回のエントリでは簡単なクローラの作り方を説明した。しかしこのクローラには欠点があり、取得したいURLが何千何万とある場合、一度にhttp_getが走ってしまい、リソースを使い切ったり同じサーバーへのアクセスを待つ間にタイムアウトしたりと都合が悪かった。そこで今回はAnyEventに加えCoroを使うことにより、並列を使ってリソースへの同時アクセス制限を行うクローラの書き方を解説する。 これは前回のエントリの改良版になるので、初めてこれを読む方は当該エントリを先に読んで頂きたい。 まず、前回はAnyEventを使い、condvarとsend-recvを使ってイベントの監視をしていたが、Coroと同時に使う場合これでは都合が悪い。イベントループを回す場合、一般的にAnyEventはrecvを、Coroはjoinを使うが、これらはどちらもイベントループが終わるまでブロックするのでどちらかし
おさかなラボ - Coroの並列をあっさり理解するための3つのサンプルスクリプト
Coroが非同期にルーチンを扱う（コルーチンを扱う）モジュールだということはご存知だと思うが、いまいちピンと来ていない人も多いのではないだろうか。これは、１つにCoroやCoro::Introの例題が悪すぎると思う。例えば、Coro::Introのサンプルスクリプトはこうだ。 use Coro; async { print "async 1\n"; cede; print "async 2\n"; }; print "main 1\n"; cede; print "main 2\n"; cede; このスクリプトは確かに面白い挙動をするが、スレッドを実現してるんだよと言われるとちょっと「？」である。こんなのgoto文でできるじゃんみたいな。そしていきなりセマフォやチャネルの話に飛んでしまい、肝心の「Coroはスレッドが実現できるんだよ」というところが分かりにくい。そこ
おさかなラボ - PerlでXSを使ってみよう
と思う人は多いと思う。気になっている人は多いだろう。しかし、XSに関する詳細なドキュメントは、ググってみると驚愕するくらい少ない。そして読みにくい。理由は後述する。 私もXSに関するドキュメントを書きたいのだが、カバーする範囲が広大すぎてどこから手を付けたらいいのか全く分からない。本が書けそうな勢いだ。エントリを分けて書くのか、既存とは別のチュートリアル文書のようなものを書くのか、悩んでいるところである。その代わり、今回はXSって食える？って人には有用なエントリにしたいと思う。そして簡単なサンプルを書いてみたいと思う。 少々のことなら分かるしググるし大丈夫だぜ！という人は、以下のエントリ、およびリンク先を参照すると良いと思う。 XS by id:naoya まずはXSって何？ってことだが、この時点で何がなんだかさっぱり分からない人が多いと思う。それもそのはず、XSという言葉が包括的
おさかなラボ - MixiはURIの長さとユーザのプライバシーのどちらが大事なのか
ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解@slashdot.jp いや、解決できるでしょ。http://www.mixi.jp/ にすれば。Mixiは会員のプライバシーよりURIの短さを優先したと思われても仕方ないのでは。今、http://www.mixi.jp/ にアクセスするとhttp://mixi.jp/にリダイレクトする（しかもこの2つFQDNの実体は同じ）ようになってるんだから逆もすぐできるでしょ？それがなぜできない。 ともかくMixiが、「ログインしていない人でも会員しか見られないはずのプライベートな画像を閲覧できてしまう脆弱性」に「ギブアップ」したそうだ。slashdot経由で非常に遠まわしな弁解文が見られる。以前、MixiとCookieドメインでMixiがおかしなCookie情報の改変をしたことは既に書いたが、こういった背景があったとは恥ずかしながら
おさかなラボ - MixiとCookieドメイン
Mixiが、一時的にCookieのドメインを“mixi.jp”から“.mixi.jp”に変更して、一部ブラウザからアクセスできなくなるという現象が起こりました。これをmixi側は「古いブラウザを使っているのが原因。新しいブラウザに変えれば直る」と一蹴しましたが、この対策が妥当だったかはともかくとして、規格上、古いブラウザと新しいブラウザのどちらに問題があったのかを検証してみます。 “.mixi.jp”への変更が妥当だったかどうかについて。 Cookieについては当初Netscape社のテキトーなドキュメントのみが仕様として成り立っていた経緯があり、実装にかなり揺れがあります。特に Cookieの大元の仕様と、RFC上のCookieの仕様の2つの内容が相反していて、Netscapeの仕様の方はDOMAINの先頭にドットを入れることに言及がない(サンプルは先頭ドットなし)。一方、RF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
