この文章を、あまりにも早く去ってしまった才能、 伊藤計劃 に捧げる。 さて、私の名刺には"mad web programmer"と刷ってある。「何が"mad"なのか」というのはFAQである。今まで幾人かに答えてきたその答えをここに書きたいと思う。 webの安全性について ネットが危険であると言ったのは誰だろう。いや、ネットは安全である。WWWの隣人は包丁であなたを刺さない。WWWの中傷者はログから追跡可能だ。 オフラインとは、認証を経ていない誰かがあなたの存在を抹消できる世界。証拠を残さずにひそひそと他人を中傷できる世界。顔が見えているというだけの実質のところ匿名で、他人を追い詰めることので きる世界。 オフラインは危険である。webはより安全なのだ。webが理想郷であるというつもりはないが、ことさらに「web炎上」などと言うな。 そこにある暴力性は、少数者がオフラインでは日々脅かされてい

今日、久しぶりに電車に乗り遅れてダウンした。交通機関の乗り換えやなんかは苦手だ。時間への正確さが明確に露呈するからだ。 何か予定を立てたら、1分でも遅れていることに気がついたら遅れているという事実が頭に残って一日中、私を責め立てる。そして、そんな状態だからまともに物事をこなせなくて被害は拡大していく。1分寝過ごしたとしたら、悲鳴を上げないでいるのに必死になって、そうしているうちにますます予定は遅れていく。 そこで、正確に予定を立てないことにする。ここで数字を考えると今度はその数字に縛られることになるだろうから明確には考えないが、予定の時間感覚精度に対して一定の割合までの遅れは許容できるようだ。だから、精度を低くする。具体的な数字を見ると1分/30秒刻みに頭が固定されてしまうので、アナログ時計は大まかに時刻を捉えるのに非常に役に立つ。そして、大体30分きざみの精度で予定を立てる。そうすればプ

「 アイヌ差別についてのブクマを全力でまとめてみた 」を読んだ。そして、コメント欄にある、「で、どうすりゃいいんだ?」との意見には考えさせられる。 何をすれば良いのかという疑問 一度形成された差別を解消する簡単な方法なんかない。弾圧や後ろ指さすのに積極的に荷担するのは論外。同化も、それこそが問題であったのに。アイヌがアイヌでいるということを許さず我々と同じであることを要請するということが。アファーマティブアクションは、有効な面はあるものの、得てして無用な差異意識を固定化したり加害者側の被害者意識を高める。まー、利権の温床になるケースもある、とは思う。それよりも利権があるという陰謀論で差別を正当化する虞のほうが大きいと思うけど。問題に無関心でいれば、それは差別者を側面から支援することになる。ましてここまで同化が進められてしまった民族問題に関して言えば、無関心であることはこのままアイヌというも

承前 。 3ヶ月ばかり時間が空いてしまったけれども、 sumimさんの記事 に答えたいと思います。 yugui さんの図は、たしかにクラスと特異クラス（メタクラス）が揃って並んでいて見た目にはきれいなのですが、これだとクラスが整然と並んでこそいるものの、肝心のメタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 いいえ、これで良いのです。なぜって? これが私の図(下記再掲)で一番言いたかったことで、ただ、一般のメタクラスと#<Class:Class>を並べているのはいただけないかな。これはsumimさんのSmalltalk版の図を意識しすぎて、まずかったかなと思います。 図1: うん、やっぱり メタ階層がどうなっているかという情報のほうは、正直なところ、いささか得にくいものになってしまっています。 これは当たってるかもしれません。 図の修

若年者(年齢の線引きはおいといて)のように価値判断が未発達な人間に見せないほうが良い情報があることは認めよう。それにしても、側にいる大人が日常的な指導や適切なフォローをすればカバーできるとは思うけどね。 技術的時期尚早 でも、何度でも言うけど、現在の技術的な水準では、webコンテンツのうち「有害」なものを検出するには無理がある。もしそれを完璧にできるって言う人間がいるなら、その人に国がちょっとした助成金を出すべきだ。そうすれば、みるみるうちにgoogleやmicrosoftやyahooなんか霞んでしまうはずだから。 つまりは、それぐらい、「有害」なものを検出するというのは技術的に難しい。貴重な情報を誤って「有害」と見なしてしまったり(false positive)、そのくせ露骨な性暴力コンテンツみたいなのを「有害でない」とみなしてしまう(false negative)。これが現代の技術の限

もともと今年の上半期はRubyに費やすつもりで活動してきた。といっても大部分は本を書いていただけだけど。 今後やりたいと思っていることを挙げる。 ドキュメントの充実 RubyはPHPだのPythonだのに比べるとドキュメントが不足してる。PHPは嫌いだけど、あの見るだけでも涎の出てくるマニュアルは素晴らしい。PHPの隆盛もさもありなん。Pythonは、あのstrictさは完全に文化なのでしょう。PerlにしたってCPANモジュールにはPODが必ず付いているし。 それにひきかえRubyは、未だに標準添付ライブラリの完全なリファレンスすら完成していない。メンテナンスも不十分だし。ソースコードに入ってるコメントが間違ってたり、新しいコマンドラインオプションがマニュアルに反映されてなかったりもした(そのままリリースしちゃったんだよ?　信じられる?)。 これは別にRuby開発陣の体質の問題とかそうい

岩城保さんの「 左利きは身体障害か 」を読んだ。岩城さんが挙げる3つの段階にあわせて、私が為そうとしているGIDへの取り組み、活動家というものの意味あいについて考えてみる。 性同一性障害者への認知を広げ、社会適応を良くするということを考えたとき、前例として参考になるのは黒人公民権運動、フェミニズム、ゲイ・リベーションである。ところで、この組合せには見覚えがある。黒人、女性、同性愛者といえば合衆国の報道における3大圧力団体である。 これらの人々については、認知運動が成功してきたが故に圧力団体が機能し得ている。かつては機能しなかったし、いずれは機能しなくなるだろう。 段階1: 認知されていなかった状態 岩城さんの論では「左利きは本当に身体の障害だと考えられていた」状態に当たる。whiteとcoloredの区別は自明視され、あらゆる局面における性別による役割分担が自然なものとされ、同性愛者は異常

きたみりゅうじの連載 は、何かものを言いたくなるという点で上手いなぁ。 ソフトの使い方を覚えるというのは本質的なことではない。今現在、ホワイトカラーである個人が戦術としてそれらを覚える必要に迫られる局面は確かにあるだろう。でも、開発者がそれを肯定しちゃいけないよね。そういう「覚える負担」をなくすために開発すべきなのであって。 だが、ならば一般人は情報技術に対して無知であって良いのか。そのギャップは全て開発者が埋めるべきものなのか。それも違うと思う。世界認識を広げるための習得は必要だ。キーになるのは、「状態遷移システム」それから「非物質的実在」。エンド・ユーザー・コンピューティングを通じてこれらを習得することは万人に求められると考える。 最近の機械が使えない人というのは、大体が機械が状態を持つということに慣れていない。だから、何か操作をして状態が変化してしまうと、自分の立ち位置が分からなくな

『 The Ruby Programming Language 』を読んだ。こいつは良い本だ。副題の"Everything You Need To Know"っていうのは嘘じゃない。翻訳しようっていう話もちらほら聞こえる。当然、翻訳は出すべきだろう。 だが、この本は決して簡単ではない。こいつは 『プログラミングPerl』 と相似だ。その言語の創始者自身が書いた。そして、初心者が中級者になるために、最後に読むべき本はこれだ。けれども、その言語の流儀を全く知らない、チュートリアルすらやってない入門者は、この本では挫折する。 Ruby Inside も、こう書いてる。 The only downside, in terms of the thousands who might be browsing Amazon looking for a single Ruby book to start o

よし来た、id:ululun。いわゆる「俺のターン」ってやつだね。 「 ＜性同一性障害＞「就職内定取り消しは違法」と損賠提訴 」というニュースに関してid:ululunが書いた記事を読んだ。 GIDと「本当の性別」 性同一性障害者で、転職経験があって、id:ululunが引いてるWikipedia記事を書いた張本人で、はてなユーザーで現在ニートの私が是非とも語らねばならないようだ。Ha, Ha, Ha! 「身元保証人の署名偽造」という要素もあるのだけれども、こっちは置いておこう。「戸籍とは異なる性別を記載したこと」についてのみ語る。 性同一性障害者が就職などの際に提出する書類の記載をどうしたらよいのか、そもそも不必要な性別記載を求めている社会こそが問題なのではないか、という論点について。 何故、履歴書には性別欄があるのか 単純にJIS規格の履歴書様式例に性別欄があるからだろう。ま、その是非

第1回RHGの逆襲 を開催しました。お越しいただいた方々、ご覧くださった方々、ありがとうございました。 発表資料: rhg-strikes-back-1.zip ustream.tv: 最初 始まり - 笹田さんによる解説が始まるまで 中盤 笹田さんの解説が終わった後 - 再び私のターン 残り コードリーディングするつもりだったけど、HotRubyの解説が始まった。 発表資料は、あんまりまとまってません。その場でソースコードを開いたり色々するつもりだったのでself-containedではないです。その割には途中で資料を辿るのに必死になりすぎて、笹田さんのように華麗な解説とは行かなかったのが残念です。笹田さんのおかげで途中で目が覚めて、ホワイトボードで解説をしてるのが中盤以降です。人に伝える技術の未熟を痛感します。 ustreamの動画のほうも、笹田さん側の動画がRECORDされてないこと

ビブリオマニアが主人公だということで紹介してもらった「R.O.D」を読んだ。何という既視感! とても身近な現象をそのまま極端に拡大した風景が描かれている。私も、外出するときになぜそんなに本を持ち歩いているのかとよく問われるよ。決まってるじゃないか、行きに読むのと帰りに読むの、それから予備、それから途中の書店で買ったやつともう一軒はしごした店で買ったやつと、途中の古本屋で買ったやつだ。さすがに1店買いはしたことないなぁ。お金があればしてみたいけど。 他に活字がなければ定期券の注意書きまで読む、電話帳を喜んで読むっていうのは本当にやったことあるし。 稀覯本趣味は無いのでその辺はよく分からないけど、とにかく作者が本を愛してるのはよく分かった。仮にも本好きが本好きを語るならばもう少し叙述に凝って欲しかった感は無いではないけど。ライトノベルという制約はあるにせよ、もう少し書いても罰は当たらんだろう。

はてなにはてブの仕様を問い合わせたけど、メールにて回答すると返信があったきり反応がない。 ので、誰かが「それYuguiの勘違いだよ」とか「フィルタに引っかかってるんでね?」とか言ってくれるのを期待して晒してみる。 追記 2008-01-10追記 今日、この記事を見たと言うことで「改めて」はてなから返信をいただいた。その返信には「前の返信」が念のため引用されていた。「前の返信」に見覚えがなかったのでスパムフィルタに引っかかったメールの山を漁ってみると、そこに発見。質問投げたその日のうちにちゃんと反応はくれてたのね。どうも失礼しました。 「前の返信」では「スタッフが調査するのでしばらくお待ちください」だったけど、今回の返信では「最初のブックマーク時に対象記事へのリンクが存在しなかったのでは?」という指摘。や、それはないよ。念のため実験をして確認した後、再度返信した。 追記 2008-01-29

@ITに まつもとさんとささださんの記事 が載ってる。Ruby 1.9についてだそうだ。 まつもと　いえいえ、逆にこれをちゃんと伝えていただきたいんです。1.9は安定版じゃなくて開発版です。“ブリーディング・エッジ”（Bleeding Edge）といって血がどばどば出ている状態のものです。そのために1.8系を用意しているということです。1.9の荒削りな部分が丸くなるには年単位で時間がかかると思うんです。そのときまでは1.8が運用されていると思います。もし何かの事情で1.9をエンタープライズで使いたいということであれば、自己責任でやっていただくしかない。 ——でも、あまりエッジなことをやっていると、1.8系と互換性のあるJRubyがマスマーケットを獲って、Ruby 1.9とかい離していく可能性もあるんじゃないですか。 まつもと　ええ、Ruby 2.0が1.x系をサポートするJRubyと別物に

Ruby 1.9.1がリリースされた訳ですが *1 、何しろ評価器がYARV化されていてRHG当時の知識が通用しないので咄嗟にパッチを書けなくて大変悔しい思いをしました。 そういうわけで、RHGこと『Rubyソースコード完全解説』を片手に、その内容に沿いながら最新版のruby実装を読む集いを1月から都内で開催します。参加者募集です。 詳細は次のWikiページにて。 <URL:http://qwik.jp/rhg-strikes-back/FrontPage.html> *1:え? まだ!?

Seasar Conference 2007 Autumnで、千葉先生は言語特性の動的と静的について話したらしい。私ゃ見に行かなかったけど、みんなその話はしてた。あと、 文殊堂さんのレポート を読んだ。 曰く、 ロード時までにクラス書き換えできれば十分じゃないの？ うん。Railsはね。だから、私は思っている。みんなもっと Module#freeze を使えばいいのに。……と、リンクしようと思ったらリファレンスマニュアルに載ってないじゃん。riには載ってるけど。そりゃマイナーなわけだ。 Module#freeze するとメソッドの追加削除ができなくなる。だから、VMはfrozen classの利用を検出したらメソッド探索をインライン展開したりとかいう最適化の余地があるんじゃなかろうか。その適切なタイミングを検出させるのは難しくてもあるいは、 GC.start みたいに YARV::Opti

ひがさんが思考停止を批判している 実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統一したほうが無難」なんてのは、おやじ予備軍シンドロームだと思う。 で、Railsにもその虞ありとのことだ。 Javaの世界はフレームワークが乱立していて適切な組み合わせを選ぶのが大変だからRailsで統一されているRubyがいいんだと。 これには、全然賛成できません。悩みたくないからスーパーなデファクトを望むのは、危険だと思うんですよね。ライバルがいないとどうしても進歩の速度が鈍ります。Rails一党独裁よりも、いくつかのフレームワークが競い合うほうが健全なのではないかと思います。 これについてのRailsサイドからの言い分はあかさたさんが「本筋には大賛成です。枝葉末節についてです。」と断った上で「 Ra

やられたと思った。「そうか、ミステリーか」と思った。 帯の煽りに依れば「推理小説を模った魔術師の物語」だそうだけれど、私はそう思わない。この小説の魅力は、「ファンタジー作家が書いたミステリー風味のライトファンタジー」ではなく、「ミステリー作家が書いたファンタジー風味のライトミステリー」であるところにある。 なるほど、これを本格推理といったら怒る人がたくさんいるだろう。変則過ぎるし、必ずしも手がかりを完璧な形で提示している訳ではない。でも、Web上の書評を見るに「こんなのはミステリーではない」と言ってくれる人がいる程にミステリーなのだ。「ミステリー風味のライトファンタジー」にそんなことを言ってくれる人はいない。 トリックスターズ (電撃文庫) 作者: 久住四季,甘塩コメコ出版社/メーカー: メディアワークス発売日: 2005/06メディア: 文庫購入: 1人 クリック: 63回この商品を含む