たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
そういう機能が入ること自体は、別に悪い事ではない(ていうかIE7が標準でこの機能を持ってる以上は入れといた方がいいだろう)と思うんだけど、実装がなんだか……addTab()
の第1引数がabout:blankかどうかで挙動を変えるとか、ちょっとひどすぎない?
本気でこのあたりの挙動をちゃんとしようと思ったら、ツリー型タブ等のようにタブの親子関係をどっかに保持しておかないといけないと僕はずっと思ってる。それを避けて最小限の変更でそれらしい挙動を実現しようとしているから、余計にややこしい事になってるんじゃないかって気がする。
議論をよく読まないままBugzillaにコメントしてしまったんだけど、僕がコメントに書いた事のうち1つ(ブックマークを開く時にこれが働くのはなんか変じゃね?という件)は、すでに俎上にのぼって議論され尽くしてたみたいだ。
タブを開く、閉じるときの動作に関しては多くの議論が行われてきましたが、結局、「ユーザより賢くなろうとはしないこと(do not to try to be more clever than the user)」というガイドラインに従うことになりました。言い換えると、経験則に基づく自動動作がユーザの意図した動作に合致すると確信できないときは、自動動作を行わないということです。
追記。誰か分からんけど「feature freezeなのに何やってんだ!」という指摘をしている人もいたので、その辺の事も入れてコメントしてみた。
しかしまあこんな事ばっかやってるとますます「手は動かさないくせに口だけ出しやがるウゼエ奴」度が増していきますなあ……
1月15日追記。新しいパッチが提出された。addTab()
に引数を一つ増やして、それで新しい挙動を使うかどうかを制御するというもので、他に与える影響はだいぶ小さくなってると思う。引数の個数がどんどん増えていくのは見てて頭クラクラしてくるけど、これ以上のことをやろうとすると話がもっとでかくなりそうだから、落とし所としては無難な線じゃないかと思う。
鳥取にいる祖父の米寿のお祝いをするぞということで鳥取に行ってた。数え年で88、今年で満87歳。僕と60歳差。
往復共に飛行機で行くつもりだったんだけど、行きの日は羽田空港に着いた時点で、鳥取側の天候不良で着陸できないかも(伊丹空港で降ろされるかも)と言われてしまったので、それじゃ困るよと払い戻して陸路に切り替えた。品川から新幹線に乗って姫路でスーパーはくとに乗り換えて、これで一安心と思ったら、今度は倒木やらポイント切り替え機の不良やらで3時間くらいストップ……結局ほとんど1日がかりの移動になってしまった。
お祝いは親族(父から見ておじおばいとこにあたる人達がメイン)で集まって鳥取湖そばの店でカニ鍋だった。本当は先日結婚したいとこ(僕から見て)も夫婦で来るはずだったらしいけど来れなくなったとかで、僕と弟だけ場違いな感じだった……
帰りも直前の時点で「天候調査中」表示が出ててヤバイかなあと思ったけど、こちらは空港に着いた時点で「定刻通り運行」となっていて、無事に乗れた。行きは約8時間、帰りは30分……えらい違いだ。
ANAのショップでユニフォームコレクション2を行きに4つ、帰りに3つ買った。帰りに買った時は店頭に一般人らしき若いカップルや女性2人組がいて「オタクってこうやって箱振って中身を探ったりするらしいぜー」とか「これが日本の文化ってやつなのかねぇ」とか言って眺めてる後ろから手を伸ばして箱3つ取ってカード払いで買うという羞恥プレイだった。
お目当ての9代目さん(仮名)エプロン姿が1個出たのでもういいかという感じ。後はダブった分をどうしよう……ヤフオクにでも出してみようか。出す側は初めてだから勝手がよく分からない。
あ、ヤフオク出す前にまずここで聞いてみるのも手か。僕と面識ある人で、「キャビンアテンダント ブルーブラウス」「グランドスタッフ パープルスカーフ」「グランドスタッフ ブルースカーフ」「パイロット 半袖シャツ」のうちどれか欲しい物がある人はご連絡下さい。定価450円ですが400円くらいでお譲りします。「パイロット ジャケット」とのトレードでも可。
このへんで触れてた件に、Firefox 3.1で変化があるみたい。
Bug 446026 – restore utility of eval(s, o)
でも何が変わったのか(何をできて、何をできないのか)よく分かってない。
誹謗か中傷か知らんけど主題と主題と無関係且つ不愉快なコメントが付いていたので削除しよう、と思ったんだけど出先からだとちょっと面倒(今使ってるバージョンのblosxomのwritebackプラグインだと、個別のコメントを消そうと思ったらファイルを直接いじるしかないんで、いつもはFTPでファイルを落としてきて編集して再アップロードしてる……)だなあ、と思った所でそういえばさくらのレンタルサーバにはWeb上で利用できるファイルマネージャという物があったんだということに気がついたので、ログインして当該ファイルの所まで辿ってみたら、なんとそのままオンラインでファイルの内容まで編集できた。エンコーディングや改行コードも選べるようだ。
こういう時に痒い所に手が届いてしまうから、さくらのレンタルサーバから離れられない。(嘘です。単に他に乗り換える動機がないだけ。)
体か心が拒絶してるのか、それとも単にやる気の問題なのか、分からないんだけど、前のエントリに付いてるらしい反応を見られない。アクセスが拒否されてるという話ではなく(実際アクセスした訳じゃないから確認してないんだけど、多分それはないはず)、リンクをクリックしたらすぐに見れる事が分かっているのに、クリックしようという気になれない。
これまでだったら、きっとまた叩かれてるんだろうなと分かっていながら敢えて突撃して勝手に気分を害して勝手に熱くなって……というのがいつものパターンなんだけど。「クリックしちゃ駄目だ! その先を見たらまた泥沼だぞ!」と警告する心の声を振り切って、好奇心とかそういうのに負けてクリックするのが常なんだけど。今回はなんか違う。
誘惑に負けてリンク先を見てしまう、というのは、「見たら後悔するぞ」っていうのと「でも見なかったらもっと後悔するぞ」っていうのとがせめぎ合って、後者の方が勝ったという状態だ。でも今回は「見たら後悔するぞ」の方が勝ってるみたい。
なんか、「嫌なら見なきゃいいのに」って言う人の気持ちが、今は凄くよく分かる。「嫌だけど覗いてみたくなっちまうんだよコンチクショウ!! それが人間の性ってもんだろうが!!!」みたいに今まで思ってたけど、全然そうならない……心の底から「いやもうホント勘弁してください、もう見たくないんですってば……」ってウンザリしてる。ひょっとしたら、恐れおののいてすらいるのかもしれない。
僕から去っていった人達、の中には、今の僕と同じような気持ちになってた人もいたんかなあ。気がついたら足が遠のいてフェードアウトしてた、っていうんじゃなくて、ある時点を境に「あ、もうあかん」と何かがぷっつり切れてしまう、という感じで。
ああ、いや、でも……よく考えたら、今回が初めてじゃないのかも。思い返してみたら、英語で書かれた質問や報告の未読メールが数千件を超えてしまったことを意識した時にも、これと同じ気分になっていた気がしてきた。見なかった事にしよう、固めて深く沈めて目を逸らそう、っていう感じに。
なんでなんだろ。ストレス耐性が今まで以上に低下してるのか、それとも、今回の件から受けるストレスがとんでもなく大きかったのか。
mozIStorageStatement.finalize() メモ - 1/4ガロン
うっ。僕の知識は古かった。Firefox 3 Hacksで、createStatement()
で作ったステートメントは使い終わったらstatement.reset()
、と書いてましたが、statement.finalize()
が正解だったようです。
が、一律にこう置き換えるとよい、というわけでもないのがややこしい所です。mozIStorageStatementのfinalizeメソッドはどうやらFirefox 3.0.x(Gecko 1.9)で導入された物のようで、Gecko 1.8系では存在しません。なのでメソッドを呼ぶ前に存在確認をしておかないといけない。Firefox 2なんてもうサポート終了してんじゃん!と思うかもですが、Thunderbirdはまだ2.0.0.xが現役なのでもうしばらくは気をつけないといけないんですハイ。
ところで、僕はずっと誤解してしまってたんですが、ステートメントはstatement.reset()
でリセットすると、バインドするパラメータを変えて何度も使い回せるんですね。createStatement()
のオーバーヘッドがどのくらいなのかよく分からないのでアレなんですが、SQL文が変わらない時はキャッシュしたステートメントを使い回すようにするという形で、高速化を図れるでしょうか。XUL/Migemoに早速活かしてみたいと思います。
現時点までで、以下の設定項目が新設されたところまでは把握してる。
以下は削除された、と。
が、どれがどんな風に働くのかがごちゃごちゃして分からんようになってきた……
browser.urlbar.default.behavior(フラグを指定しておくことで、restrictとかmatchとかの指定をしたのと同じ状態から検索をスタートする)に3を指定するのと、browser.urlbar.search.sourcesに3を指定するのとの、違いがいまいち分からない。ので、ソースをあちこち辿ってみた。見てみた感じでは、どうやらnsNavHistoryのProcessTokensForSpecialSearchメソッドが鍵になってるっぽい。
検索対象のテーブルの指定や絞り込みの条件は、すべてmAutoCompleteCurrentBehaviorという1つの変数にフラグとして格納される。
これらを踏まえて、以下の順で処理されている。
ああややこしい……
その場での入力とデフォルト設定のどっちが優先されるのか、がパッと分からないのってどうかと思うんだけど……XUL/Migemoのスマートロケーションバー周りの挙動をこれに合わせないといけないんだけど、こういうわかりにくい挙動をそのまま再現するというのは、モチベーションが上がらないなあ。(ていうかバグ立ってそう)
21日追記。browser.urlbar.search.sourcesが廃止されてこのエントリの内容のかなりの部分は無駄になりました。
いやだから、それが「社会にとってどう役に立つの?」って言ってるんですよ。
なんか話がズレてますね。社会に役立つかどうかと、作品たり得るかどうかは別の話ではないのですか。誰も読む人がいないような駄作の小説だって作品だし、誰も見ないようなヘタクソな絵だって作品ですよ。オリンピックの一瞬一瞬だって作品だし、エクストリーム・アイロンがけもスポーツだし作品だし、世の中の全ては誰か(作者自身でもそうでなくても)が「作品」と呼んだ時点で、きっともう作品なのです。
で、その作品を作品として批評したり批判したりするためには、まずそれが「作品」であると認める事から始めないといけない。コンテキストを共有しないとどうにもならない。コンテキストを共有しないで批判するとなると、結局、「そんな物は作品とは呼べない」とか「そんな物は役に立たない」とか「ほーら、必殺技『ブラウザの実装が悪い』が出たよ」とか、メタな所で批判するしかなくなってしまう。そうじゃなくて、このマーク付けの仕方が美しくないとか、クラス名の付け方が美しくないとか、そもそもinvalidだしありえねーとか、これこれこういう風に問題を回避するのが腕の見せ所だろとか、そういう風に、同じ土俵で批判しないと作品としての批判にならない。
コミュンな人間が、作品として批判され得る物を世に出していなかった、訳ではなくて、他の人達が、コミュンな人間のアウトプットを作品として批判しようとしてこなかった、っていう事なんじゃないんですかね。
コミュンな人間が「安全圏から見下して物を言っているだけ」だったというのなら、マジョリティもまた、コミュンな人間のアウトプットの根底にあるベクトルの異なる考え方を「その考え方は常識的に考えて下らなくてあり得ない」と別のベクトルに当てはめて劣った物として位置づけて安全圏から見下していたわけで、それってお互い様なんじゃないんですかね。
まあ、マイノリティはマジョリティから「作品」として評価してもらえるように、マジョリティに対して説明したり迎合したりしていく必要がある(生き残っていくためにはそうするのが合理的である)、とは思います。それに繋がるようにと思って、自分は自分にできる範囲で活動してきたつもりです。そういう事に全く関心がなかった人もそりゃあいたでしょうし、自分の観測範囲に入るラウドマイノリティのせいかもしれませんが、絵やら小説やら映画やらの世界の人達に比べれば、傍迷惑なだけに終わってしまっていた人の割合が多かったような印象もあります。ただ、それもこれも全てひっくるめた全体を指して彼らは作品を出さない
などと言われた事に、自分はカチンと来ました。
そういう点では、野﨑氏は「作品として扱う事」を否定すらしていたわけで、僕の立場からは敵と言えるのかもしれませんね。
あと、当時リアルタイムでそれを作品と意識して強く意識していたかどうかと言われると疑問ではあるのですけれども、それについて真面目に考えたり物を書いたりするといった行動、その時の思い入れ、等々を振り返ってみる限りは、自分が他の「作品」に対して持っている・持っていた物に非常に近く、少なくとも自分には明確な区別を付けられません。ただ、作品を生み出すということにはそういうあり方もあるのではないかと、自分は思っています。なので、当時リアルタイムで「これは作品だ」と明確に意識していなかったとしても、それを悪い事だとは考えていません。また、「作品」として評価した場合において、自分のそれが高評価に値したのかどうかも、別の問題だと思います。
で、それはそれとして、現実的な面で大して役に立ってねーじゃんとか、馬鹿げた喜劇だとか反面教師だとかっていう話については、まったくもってその通りです。それは僕も過去に何度も述べてきた記憶があります。なので、その点には反論は無いです。
私の予測では、反撃として、必殺技「ブラウザの実装が悪い」が、展開されるはずです。いつものパターンという奴です。
ご期待に添って「ブラウザの実装が悪い」と書いておきます。仕様に照らし合わせて妥当であるとか整形式であるとかの最低条件を満たしていたら後はベストエフォート、どこで切るかは個々人のやる気と思いやり次第、というのが自分のポリシーですから。この辺については、ウェブブラウザなんかに気を遣わなくてもいい理由を先日見て、「こんなの全部対応してられっかよ……」という思いをより一層強くした次第です。
そして。CMSが当たり前の今こそ「エクストリーム・マークアップ」を提唱し、極限の(精神)状態における鮮やかなマークアップとCSS書き書きを芸術性の観点から評価するべき時なのではないだろうか。え、僕? あー僕はほら、もうGecko依存のアドオンの世界にドップリになっちゃってますんで……始まる前から引退表明。
会社の近くに新しくできたインドカレー屋に3日連続で行っている。そこのカレーが死ぬほど美味い!!! みんなも是非食べに行ってくれ!!! ていうか連れて行ってやるぜ!!! とかなんとか言うような話ではないんだけど。昼の値段ではカレーとナンのテイクアウトで690円、ライスの場合は普通の白いご飯。もう少し高いランチセットだと、サラダと飲み物が付いて、ご飯大盛りまたはナンおかわり無料。
カレーは好きな方だから、梅田の2ビルにいた時は3ビル地下にあった手頃な値段のインドカレー屋にしょっちゅう行っていた。でも、こっちに来てから、会社から徒歩ですぐ行けるような所にカレー屋を見つけられなかったので、あんまり行く機会がなかった(通勤途中には2件ほどあるのは確認済みだけど、どっちも入った事はない)。その反動なのかもしれない。
まあ、近所に店が全く無かったわけではなかったようなんだけどもね。僕は気がつかなかったけど、JR水道橋駅の方にはあったそうで。でも、そこに食べに行った人達の感想としては、水っぽくてコクが無くてまずかったとかなんとか。
で、須藤さん曰く、僕が3日連続で行ったその新しくできた店のカレーは、そんなにおいしくない方なんだそうで……前述の「まずかった」カレーと比べてどうなんでしょうかと聞いてみたら「うーん……」と考え込んでしまう、そんな感じみたいだ。新規開拓とか評判の店巡りとかをよくしてるらしい須藤さんの舌の方が、そういう事を一切しない僕の舌よりは確かだと思うので、多分、その評価が正しいんだろうとは思う。
そういう事があったので、僕の中では今後その店に関しては「世間的には不味いらしいけど何故か自分はよく行ってしまう店」とか「僕はこうしてうまいうまいと思って食べているけれども、ちゃんと味の分かる人から見たら哀れな物を食べてる風にしか見えないんだなあ」とかいう風に後ろ向きに認識することを避けられない気がする。そう思うとちょっと切ない。「彼女の黒コゲ手料理を『愛情が入ってるから十分おいしいのさ!!』と言って喜んで食べる」というよくあるノロケみたいなほどには、特別な感情をその店に抱いてるわけでもないし……
ちなみに、カレー屋ができる前にそこに入ってた飲み屋?の昼の定食を一度だけ食べた事があったけど、いやあ、あれはその……まずかった。僕が言うんだから相当なんだろうね。二度行こうという気にはなれなかった。まあ味だけじゃなくて、お昼のど真ん中に行っても僕以外誰も客がいなかったというあの気まずい空気にまた飛び込むのはためらわれる、という理由もあったんだけど。
追記。店の名前はソウルフード インディアだった。ストリートビューだとさすがに前の店のままだ。
別に特殊な文字なんか使ってないのに、メールを送信しようとすると「変な文字が入ってるからISO-2022-JPじゃ送れないよ! UTF-8にする?」みたいな確認が出る、という問い合わせを受けて調査をしてたら、原因は表題の箇所にあった。
「MS P明朝」みたいに非ASCIIな文字を名前に含むフォントを使おうとすると、フォント名自体が文字化けしてしまって、その化けた文字がISO-2022-JPの範囲外なので上記の確認が表示されてしまう、というのが事の真相だった。
で、検索してみたらMozilla Japanのナレッジベースが引っかかったんだけど……
Mozilla Japan - Thunderbird サポート - ナレッジベース - HTML 形式のメッセージを作成中にフォントを変更できない
日本では HTML 形式のメッセージはあまり好まれませんので、シンプルなテキスト形式で作成していただくという方法もあります。
ちょwwwwwwwそりゃないよwwwwwwwwwwww
ナレッジベースからリンクされてたバグはEditorコンポーネント扱いになってたんだけど、自分が特定した限りでは原因箇所はThunderbird固有のフロントエンド部分だったので、分かりやすいようにと思って新しくバグを立てた。
パッチを見ての通り、修正点自体はほんとに些細です。なのに何年も見過ごされてたっていうのが、なんだかなぁ……
1月13日追記。池添さんに教えてもらいながらレビュー依頼したりとかなんとか。checkin-neededキーワードが付いて、どうやらパッチ採用してもらえそうな感じ? そして関連する別のバグにもパッチを書いてみた。
1月15日追記。Trunkにチェックインされたよ! これで僕もThunderbirdコントリビュータ!(←クレジット入れ忘れてるのできっと誰にも知られないまま)
2月23日追記。重要なバグじゃないからパッチは2.0.0.xには入れないと言われてしまいました。重要じゃないのか……最初から付いてる機能が最低限すらまともに働いてない事がそんなに些細な問題ですか……。