たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
Gomitaさんが訳し残された所を訳してみた。children要素のincludes属性の解説はちょっと分かりにくいような気がしたんで勝手に英語版にも例示を追加してみた(リファレンスを勝手にド素人が書き換えるなんて差し出がましいにも程がある)。ところで、複数タブでページ内の部分的な編集をしてると、タブを開いた時点のバージョンの記述が他の部分にも影響してしまうっぽい? なんか何度も無駄な書き換えをしてしまった。こんな荒しまがいの事をやってるとそのうちアカウント停止されてしまうだろうか。
JavaScriptによるXPCOMコンポーネント作成の練習に、XUL/Migemo勝手改造版の主要な部分をXPCOMコンポーネントにするという実験をやってみた。
ブランチ切って昨日一日作業してたんだけど、それなりにうまくいったようなので、すでにTrunkにマージはしてある(Subversionでブランチ切ったものを再び統合するやり方が分からなくて右往左往したのは秘密だ)。
Ez Sidebar、ずっと放置してたけど更新した。install.rdfの記述もFx 2で使えるように直した。なんかエラーが起こってたから直さなきゃと思ってずっとあれこれしてたけど、見当違いの所ばっかり見てて6時間以上は無駄にしてしまった
うーん。対象バージョンをFx 2以降くらいに限定して作りを直すべきかなあ……現状は、他の拡張機能が動かないとか諸々の意見を受けて、このさいだからとbrowser.xulをそのまんまオーバーレイで読み込ませる事でブラウザに組み込まれた拡張機能もすべて分離したサイドバー内に読み込むようになってるんだけど、分離したサイドバー内で動作することを想定されてない(ていうか普通はそうだ)拡張機能、例えばXUL/Migemoとかでエラーが起こってしまっていて、動作の上では問題ないんだけど、エラーコンソールにエラー表示が出るのがいまいちキモい。
これを解消するには、不精してbrowser.xulまるごとオーバーレイで読み込むのをやめて、必要な所だけをezsidebar.xulに直に書く事なんだけど……コンテキストメニューの定義の事とか考えると気が重くなってきて、やっぱりやめようかな……って気になってくる。
まとめサイトのXPCOMコンポーネント開発の資料に、須藤さんがLinuxとMac OS XでのC++でのコンポーネント開発のチュートリアルを書き加えてくださった。というわけでそれに触発されて自分もJavaScriptで実際にコンポーネント作ってみた。
以前からこのページにあった解説はコンポーネント名やなんかが全部「xxx」という形になってて何がなんだか分からなかったので読む気がしなかったんだけど、須藤さんが書いてくれた部分は英語の原文と同様にコンポーネント名とかもちゃんと具体例を示してあったので、それを見ながら試してみることで、やっと理解することができた。というわけでJSの例も具体例を示すように書き直しておいた。
世の中的には、どうなんだろう。具体例から原則を見出すチュートリアル式のやり方と、原則から具体例を導き出すやり方の、どっちがウケがいいんだろうか? 先日書いたSoftware Designの記事(次号掲載予定)はチュートリアル的な書き方を意識して書いたし、自分が記事を書くときはなるべくそうするようにしてるんだけど、思考回路が全く自分と異なる人から見たら、こんなのまどろっこしくてとてもじゃないけど読んでられねえ、というものなのかもしれない。
そしてもし頭の良い人達にそういう人の方が多いのだったら、馬鹿な僕がサンプルを勝手に具体的な物に書き換えたことによって、彼らの足を引っ張ることになってしまっているのかもしれない。だとしたら申し訳ない限りだ。
くでんさんの記事を見て改めてプレビューサイトにログインしてみたら確かに僕の奴は全部サンドボックス(品質が低いと見なされた拡張機能が放り込まれる所。ここにある物は一般ユーザからは見えない。)行きになってました。
まあ中には放置しっぱなしで動作の怪しい物もあるんでしょうがないんですけど、一応自分的には「これはそれなりに安定してるんとちゃう?」と思ってる物も全部サンドボックスに突っ込まれてたので、いくつか拾い出してもバチは当たるまい、と思ってNominate to appear on public site
のリンクをクリックしてみたんだけど……一般に公開するアドオンは、サンドボックスに置かれているアドオンよりも品質が高く、Web の利用価値を高めるものでなくてはなりません。
と言われると「うーん……そう言われるとべつに品質高くもないし役に立つようなものでもないし……」と思えてきて、「くだらねー物を何個もノミネートしてきやがって余計な作業増やしやがってこいつムカつくマジで死ねよ」とか思われるのも悲しいし、という感じで「Nominate」ボタンをクリックするのがためらわれて、すごすごと引き返してきました。
まあサンドボックス内にあっても拡張機能のページ単体を直に表示すれば見れることは見れるようなので、今後は旧バージョン置き場+比較的安全なダウンロード元としてだけ使うのが僕の場合は性に合ってるのかな……と、卑屈な気分になっている僕がいます。
Thunderbird 2でメッセージ内検索がFind As You Type/Find Barベースの物に変わったということで、これから仕事でTb 2をいじくり回す機会も増えてきそうだからその練習も兼ねて(?)、XUL/Migemo勝手改造版をTb 2に対応させてみた。あと、Tb 2対応のためにコードの一部を若干抽象化したので、その勢いで同じくFind Barを使ってる「ソースの表示」ウィンドウでもXUL/Migemoを使えるようにしてみた。
新規プロファイルでTb 2(2.0正式版リリースに向けた最新のナイトリービルド)を起動して気がついたけど、「戻る」「進む」って初期状態でツールバーに表示されてるのね。カスタマイズで自分で追加しなきゃいけないって聞いてたから「ありえねー」と思ってたけど、単に旧バージョンからプロファイルを引き継いだ人だけがそうなるってことだったのか。
あとGmailのアカウントを簡単に設定できるようになってた(名前とメールアドレスを入力するだけでOK)のは地味に嬉しい。内部的にはただのアカウント設定のテンプレート内蔵ってことなんだけど、こんな調子で有名どころのサービスを一通り網羅してくれてれば、個人ユーザ向けにお薦めできるポイントになると思うんだがなあ。
plus7さんによるXUL/Migemoの実装の解説を見ると分かる通り、XUL/Migemoでは正規表現での全文検索を実現するためにDOM2 Rangeの機能を使っている。この方法は素直に使うとscript要素の内容やstyle要素の内容、その他非表示の要素の内容にまでヒットしてしまうということで、氏は色々と工夫されていた。
takenさんが紹介されている、nsIScriptableUnescapeHTMLを使えばこの件について改善できるか……? と思ったけど、調べてみたらこの機能はFirefox 2以降でしか使えないっぽい(Fx 1.5では使えない)。残念。
まあ、軽く見た感じでは、全然別のDOMDocumentFragmentを生成するものということで、どちらにしろXUL/Migemoでは利用できなかったかもしれないんだけど。
Mozilla Europeの中の人による関連エントリの和訳シリーズも併せて。
池添さんは、「建設的な事もせずにグダグダ言うだけの周辺の人間を切り捨てれば開発はもっとスムーズに進む」「内輪ノリのコンテンツなんかを手作りするのに無駄な時間を割くくらいなら、プロモーションはプロに任せて、プロモーションの素人であるMozillaの中の人はもっと別の事に時間を使うべき」と言っていた。効率を重視して、最終目標を「良いプロダクトを作ること」「そのプロダクトを広めてより良い世の中にすること」と考えるのなら、それが一番だと僕も思う。
XUL/Migemo [Forked Edition]の挙動がおかしいのを直そうとしてハマってしまった。検索欄に長い文字列をペーストして検索を実行しても正常に検索できないという問題。
色々条件を変えて試してみたら、どうも、検索できなくなってるんじゃなくて、リンク内の文字列のみ検索するモードに強制的に切り替えられてしまっているようだった。しかし検索モードを指定するフラグの値を変更しても全然効果が現れない。
Type Ahead Findの実装の深いところを見てみてびっくらこいた。検索バッファ(最後に検索した文字列)が空の状態で検索を始めて、且つ、accessibility.typeaheadfind.linksonlyがtrueの時は、強制的にリンク内検索モードになるように書かれてるじゃあないですか。そりゃあ、いくらやっても無駄なはずだよ……
つうかコレ書いた人何考えてんだろう? 普通のページ内検索でこの設定を参照する意図が全然わからない。これってクイック検索の時専用の設定じゃないのん? まあ、そもそもこの問題に引っかかったのは何らかの理由でaccessibility.typeaheadfind.linksonlyがtrueになってしまってた(初期状態はfalse)のが原因なので、こっちのせいといえばこっちのせいなんだけど。
とりあえず、検索を実行する前に検索文字列の最初の1文字で検索してからもう一度長い文字列で検索するようにしてみたところ、accessibility.typeaheadfind.linksonlyがtrueでも問題なく意図通りの動作をするようになってくれるところまでは確認できた。でも、これって変なやり方だよなあ。たぶんaccessibility.typeaheadfind.linksonlyをfalseに設定するのが本道なんだと思う。でもこの設定を本来の目的で使いたい人はどうすればいいんだろう? 全く訳がわからない。
Fx2でこの問題が起こることを確認したけど、Fx3ではどうなのかは未確認。そっちでも起こってるようならいよいよバグ報告してみようか(どちらかというと機能要望?)。
Multiple Item Packaging……必要になったのでちょっと検索してみたら、MDCの方は未訳だったので、訳してみた。他の文書でマルチアイテム拡張XPI
という訳があったから、それに倣って「マルチアイテムパッケージ」としてみたけど……勝手に造語増やすなよと怒られたりせんかな?