Zen Codingを導入してみた

Amazonで、『HTML+CSSコーディングが10倍速くなるZen Coding』なる書物を見かけたので、ちっとばかり調べてみた。
ばりばり使うことがあるかというとかなり疑問だったけど、便利そうなので手もとのEmEditorやAptanaに導入してみた。


1. EmEditor


EmEditor向けにはマクロとして提供されている。
http://www.emeditor.com/modules/mydownloads/singlefile.php?cid=18&lid=281


上記ページで、FDマークの右の「Zen Coding macros and snippets」という部分をクリックすると、マクロのファイルがダウンロード可能。


同ページの手順書によると、

1. 「マイドキュメント」フォルダに「My Macros」（MyとMacrosの間は半角スペース）というフォルダを探す。
2. ない場合は、EmEditorでマクロを一度も使用したことがないことが原因と思われる。ない場合は、自分で作成してしまうこと（EmEditorで何でもいいのでマクロを記録、名前をつけて保存しようとすると自動で作成される）。
3. My Macrosフォルダに、zen_emeditor.jseeをコピーする。
4. もしスニペット・カスタムバーが表示されていなければ、メニューから＜ツール→プラグイン→スニペット＞をクリックし、表示する。
5. スニペット・カスタムバーの上で右クリック＜インポート／エクスポート→ルートにインポート＞をクリック。
6. zen-coding-en.eesnip（もしくは～ja.eesnip）を選択。
7. もしスニペット・カスタムバーが表示されていない状態でもZen Codingマクロを使用したい場合は、＜メニューからツール→プラグイン→プラグインの設定＞をクリック。
8. プラグイン一覧からスニペットを選択し、プロパティをクリック。
9. 「バックグラウンドでも実行する」にチェックを入れ、OK。

（以上、意訳・補足あり）

これでZen Codingマクロが有効化し、「div#name」とか何とか入力してF12を押すと、コードの展開が可能になる。編集設定がCSSの場合はCSS向けのZen Codingも可能。

また、ほかにもコマンドがあるらしいけど、そこら辺は上記ページを確認のこと。

2. Aptana（Eclipse）


Aptana（Eclipse）向けには、プラグインの形式でリリースが行われはじめている。
以前、Zen Codingについて調べたときにはまだなかったように思うので、隔世の感？


プラグインは、以下のページで配布されている。
https://github.com/sergeche/eclipse-zencoding


インストール手順にしたがうと、

1. メニューから＜Help→Install New Software...＞と進む。
2. アップデートサイトのロケーションとして、http://zen-coding.ru/eclipse/updates/を追加する。
3. 利用可能なプラグインのリスト中、「Zen Coding for Eclipse」（Uncategorized...→Zen Coding for Eclipse）にチェックを入れ、Nextボタンをクリック。インストール手続きを進める。
4. インストール後、（Aptana／Eclipseに促されるまま）再起動する。

（以上、意訳・補足あり）


これだけで、Aptanaのテキストエディター中でZen Codingが使用可能になる。
例によって「div#name」とか何とか入力してTabキーを押すと直前のコードが展開されて、HTMLになる。
コマンドのショートカットのカスタマイズもできるっぽい。詳細は上記ページを確認のこと。

Twitterに近世文語もどきでつぶやく

連日、大学図書館や国会図書館に籠もっている。当たり前のことではあるけれども、やはり種々の誘惑物やマンションのおばさんの叫び声などから隔絶された環境というのは、集中するのに最適で、とくに大学院生は「研究者用個室」なるものを借りられるので、なおよい。

そんなわけで9月に入ってPCに触れる機会と時間が著しく少なくなったのだが、8月以来わけあってTwitterを使い始め、最近慣れてきた。

140余文字の「つぶやき」をネット上に垂れ流すという、何とも贅沢（？）な無意味系サービスであるが、その制限文字数は最大限に使いたい。それで表題のような次第となる。おそらく少ない文字数により多くの情報を込めるには、

現代文語　＜　近世文語　＜　中国語　（＜　古典中国語？）

という順で有利であると思う。
しかし実際上中国語は書けないし読めない。結局近世文語からあまりに冗長な箇所のみ削ぎ落として用いるのが次善であるようす。

しかるに、そもそも「つぶやき」に普通言うような意味での「意味」とか「内容」とかいったものを込めるというのはTwitterの趣旨に反しているような気もする。

Opera 10.00 をさっそくインストール

WebブラウザOpera 10.00 の正式版がリリースされたというので、さっそくインストールしてみた。デザインがなんとなくChromeなのだが、単にデザインの流行の問題なのかもしれない。

例のごとくFirefoxとその拡張機能によるブラウジングに慣れてしまったぼくにとっては、テキストエリア内のテキストを外部エディタで編集するようなメニューがないことが残念なのだけど、またしばらく使ってみようか。

Opera 10のこととは関係ないが、Operaのインターフェースは、タブが、メニューバーとアドレスバーの間にあるところがけっこうお気に入り。デフォルトではウィンドウの左側に表示される「ブックマーク」その他のパネルの表示位置──パネルの上端は、タブバーの下辺に接していて、まるでサイドパネルは個々のタブに従属して居るみたいだ！──には疑問を感じるけれど、タブバーの位置はまったく理にかなっている。

Firefoxの開発コミュニティはといえば、Operaのみがこのデザインを採用していたころには見向きもしなかったのに、Chromeが同じデザインで登場したとたんに、タブバーの位置を移動すべきかどうか、という議論が突然に（？）はじまったような感じ。ちょっと滑稽に感じたが（Operaなら捨て置いても良いが、Chrome＝Googleだと焦りを感じるという）、これはあるいはネット・ニュースのつくりだしたフィクションだろうか。

Powered by ScribeFire.

markItUp!の低機能版をつくった

jQueryのプラグインとして動作する、WYSIWYGでないマークアップテキストエディターmarkItUp!の低機能版を作成した。

これまたより大きなアプリへの組み込みを前提にしたもので、スタイルをjQuery UIのCSS Frameworkに依存しているので、概観の統一ができる。また先に作成公開したjquery.tedit.js同様に、オブジェクトとしてもjQuery要素としても操れるようにしてみた。

jQuery UI Sortable とダブルクリック・イベント

jQuery UIプラグインについてのメモ。
バージョンは、jQuery 1.3.2、jQuery UI 1.7.2

jQuery UIプラグインのうちSelectableは、あらかじめ指定した要素をマウスのドラッグにより擬似的に選択できるようにしてくれる。
要素選択の動作中、点線で縁取られた透明のDIV要素（class属性はui-selectable-helper）を画面最前面に表示して、マウスカーソルの移動にあわせてこのDIVのサイズを変更、選択範囲を指定できるようになっている。そして選択動作（マウスのドラッグ動作）の終了後、その指定範囲にあった要素に選択されたことを示すclass属性（ui-selected）を追加する。

このSelectableの動作自体はすばらしいのだが、これによってSelectableの対象として指定した要素では、ダブルクリック（dblclick）などのイベントがキャンセルされてしまう。
現状では、Selectableにこれを回避するようなオプションは用意されていないので、擬似的に“ダブルクリック・イベント的状況”を判定するしかない。

var prev_target;
var dblclick_callback = function(...){ ... };
var selectable = $({String} selector) . selectable({
stop: function(event){

var selected = $('.ui-selected', selectable);/* stop イベントには、引数として選択された要素へのアクセス手段が提供される、ということがないので一々選択されている要素を取得 */

if(selected.length === 1){ /* 選択されている要素が1つだけ*/
if(prev_target /* 前回の選択要素が保持されていて（undefinedでなくて）、*/
&& selected.get(0) === prev_target /* 前回の要素と今回のそれが同じ */){

var dblclick_event = ... /* 必要ならばカスタム・イベントオブジェクトなどを作成 */
dblclick_callback . call(prev_target, dblclick_event, {selected: selected});/* （疑似）ダブルクリックイベント用のイベントリスナ関数を呼び出す */

}else{ /* 前回の選択要素が保持されていない場合 */

prev_target = selected.get(0);
window.setTimeout(function(){ prev_target = undefined; }, 250); /* 一定時間（この場合250ミリ秒）経過したら、この回の選択要素への参照を削除 */

}
}

/* 以降は本来の選択動作についての処理を適当に */

}
});

jQueryのプラグインをつくった

この2週間ほどで2つのjQueryプラグインをつくった。
おかげでまた一段とIEのことを知ることができて、“有益”であった…

■jquery.indent.js

指定されたHTML要素の内側のHTMLソースコードや、文字列のかたちで与えられたソースコードを、人間に見やすいようにインデントして返すもの。
（実はもうすこし前につくったものが結構バグがあり、非効率でもあったので全面的に書き直したもの）

■jquery.tedit.js

HTMLのTABLE要素をグラフィカルに編集するためのプラグイン。行・列の挿入・移動・削除、セルの結合・分割、コピペなどの編集と、編集結果を二重配列やTABLE要素として返す機能を持たせた。

どちらもより大きなアプリに組み込むことを前提に開発したが、そちらの完成時期は不明。友人のアドバイスにしたがってデモページをつくったりもした。

COLSPAN属性およびROWSPAN属性とIE

引き続きInternetExplorerのDOM実装と格闘していて気がついたこと。

■COLSPANとROWSPANは静的な値である？

jQueryが、IE6やIE7において、内部的にどのようにこの２つの属性を読み書きしているのかはわからないが、

( {jQuery} tdElement ).attr( 'colspan', {Number} colspanValue )
( {jQuery} tdElement ).attr( 'rowspan', {Number} rowspanValue )

という呼び出しで、DOMのTD要素に両属性を書き込みしても、ブラウザの画面内で表示されているTD要素にその効果──すなわち複数のセルを結合した大セルの表示と、それにともなう右隣、下隣のセルの適切な位置への移動──は行われない。

FirfoxやOpera、Safariで同じことをすれば、セルのサイズが変更される。つまり両属性を書き込んだ時点でそのTD要素を内包するTABLE要素の再レンダリングが行われて、前述の「効果」が現れる。（「効果」によって右や下方に押し出されてしまう余分なセルは削除すれば、きれいなテーブルになる）。

IEでは──すくなくともjQuery1.3.2を使用している場合──このような親切は期待できない。上記のattrメソッドで属性を書き込んだあと、TABLE要素に対して、

({jQuery} tableElement).html( ({jQuery} tableElement).html() )

などとすこしばかばかしい処理（TABLE要素内のHTMLソースコードを取り出して、それをそのまままた元のTABLE要素内に注入する）をして、手動でTABLEの再レンダリングを引き起こす必要がある。

※TABLE要素内の要素にイベントリスナなど後天的・動的に付加された情報がある場合、それらの情報は上記の処理では棄却されてしまう。これを回避するにはもっと面倒な処理を行う必要がある。

■COLSPANとROWSPANは別待遇

これはFirefoxでもそうなのだが、COLSPANとROWSPANはブラウザ内部では値の扱い方が違うらしい。FirefoxではCOLSPANやROWSPANが指定されていない要素に対して、たとえば

var td = $('<td></td>');
td.attr('colspan'); // undefined を返す
td.attr('rospan'); // 1 を返す

とattrメソッドを呼び出した場合、二つの属性で返される値が異なる。
これは標準と照らしてどうなのかわからないが、わかりづらい動作であることは確かであろうと思う。

IEではこれがさらに怪しげになる。

"colSpan"属性や"rowSpan"属性（なぜかSが大文字）が存在する。どういうときにこれらの属性値が出現するのかわからない。たぶん、

td.attr('colspan', {Number} colspanValue);
td.attr('rowspan', {Number} rowspanValue);

などとすると、（TABLE要素のinnerHTMLプロパティなどにアクセスするとわかるのだが）、TD要素に、この謎の属性が出現する。そしてなぜかこの謎の属性のほうが、"colspan"や"rowspan"（もちろんすべて小文字！）よりも効果が優先される。仕方なく、

if($.browser.msie){
td.attr('colSpan', {Number} colspanValue);
td.attr('rowSpan', {Number} rowspanValue);
}

などとすると、うまくいく。（$.browserつまりjQuery.browserオブジェクトは、jQuery1.3ではすでにサポート対象外宣告を受けているのだけど、こうしてしばしば立派に活躍していることを考えると、なぜサポート対象外？と疑問を感じる）

■そもそもIEでは、"colSpan"や"rowSpan"は存在しても、"colspan"や"rowspan"は存在しない？

さらに恐ろしいのは、IEで

td.removeAttr('colspan');
td.removeAttr('rowspan');

などとすると、エラーでJavaScriptの実行が停止してしまうこと。
おそらく「そんな名前の属性は存在しません」とでも訴えているのである。これにはかなりムカっとくる。

InternetExplorerのDOM属性認識

ここのところJavaScriptのライブラリjQueryのプラグインをいくつも作っていて気がついたのだが、InternetExplorer（IE）のJavaScript（JScript？）におけるDOM要素や、そのinnerHTMLプロパティからアクセスできるHTMLソースコードには独特なものがある。

Firefox、SafariではinnerHTMLプロパティからアクセスできるソースコードはタグ名がすべて小文字アルファベットで、XHTML的。ただしBR要素やHR要素、IMG要素などの元来閉じタグのない要素について末尾を「～/>」で終わらせる、というようなことはされていない。

Operaではある意味、innerHTMLというプロパティ名からして正しい挙動なのかもしれないが、タグ名はすべて大文字になる。

IEでは、innerHTMLプロパティから得られるソースコードは、Opera同様タグ名が大文字になる。そして属性値は、値にスペースが入らない種類のものである限り、「"～"」（クオテーション）で囲われていない。さらに、STYLE属性の、CSSプロパティ名がなぜかみな大文字アルファベットになっている。

これはDOM要素の属性にアクセスするためのプロパティを通じて、STYLE属性にアクセスした場合も同様であるらしい。CSSプロパティ名は大文字であった。

以上でもすでにして、IEのDOMが恐ろしくなってくるのだが、さらに問題があった。
IEでは手書きのソースコードや、DOMのメソッドを用いて作成したDOM要素に、手動で指定してはいない数多くの──おびただしい数の属性が追加される。innerHTMLプロパティを用いるにせよ、attributesプロパティを用いるにせよ、これらのプロパティによって得られるソースコードや属性の情報にはこちらが予期していない、しかもものすごい数の属性が含まれている。

たとえばTD要素（テーブルのセル）のcolspan、rowspanなどはこちらが指定しなくても、DOMのプロパティとしては存在していて、初期値は１。disabledという属性を持つことのできる要素については、かならず「disabled=false」。その他のすべての要素には「tabindex=1」が勝手にセットされているし、「on～」という形式のイベントリスナを指定する属性も空文字列が値として指定されて存在している。

これは結構タチが悪く、ソースコードがやたらと長く、また読みにくくなるし、下手に標準値などを指定されると困る場面がある（IEのDOMから得られたソースコードを他のブラウザで利用するときなど）。

結局上記４ブラウザでHTMLソースコードを標準化する（そして何らかの別の処理に用いる）には、

1. IEとOperaでは、タグ名の小文字化を実施し、
2. IEでは、「"～"」で囲われていない属性値を囲い、
3. IEでは、STYLE属性についてはCSSプロパティ名部分を小文字化し、
4. IEでは、さらに値が「0」であったり、「false」や「null」、「""」（空文字列）であるような属性は、（属性値だけでなく）属性ごとカットしてしまい、これは場合にもよるが「tabindex」については「1」であればこれも属性ごと削除する

──という処理が必要になる。

ネット広告のありがたさ

最近，ThunderbirdからまたGmail直利用に戻ってきた．
スレッド表示以外が用意されていないのがとても残念なのだが，ともかくメール検索のスピードはThunderbirdにはない強みである．

それでしばらくThunderbirdに移行していた間にかなり古くなっていた「フィルタ」の定義を徐々に改めて──追加・変更・削除している．

そうしているなかで，AmazonであるとかYahoo（の各種サービス）であるとかメールマガジン発行代行サービス（FreeMLとかMag2とか）であるとかの広告メールの膨大さを，またしみじみと感じていたのである．

これらの広告があればこそ，ぼくたちはとくにYahooやFreeMLなどを使用するにあたって，使用料を免除されているのである．実際メール広告はメールソフトやWebメールサービスですこし工夫するだけで簡単に自動削除できてしまうのだから，「使用料免除－広告メール受取」という取り引きは，ユーザー側にとってきわめて割の良いものに思える．

それはウェブサイト上のバナー広告やFlashによる広告も同じである．すくなくともFirefoxを使用しているユーザーは，当人にその気があればかなりの数の広告を自動で消し去り，表示されてしまったモノもまた手動で登録することで，次回以降，類似の画像を自動で消し去るようにできる．

なるほど便利．便利極まりない．もちろん広告のより多くの部分は，サービス使用料とは関係のないものだろう．

それにしてもこれって，サブプライムローンのはなしとどう違うのだろう，と思う．膨大な額の，「効果」のあるなし以前に「表示」すらされない広告に対して払われる，膨大なお金．

テレビやラジオ，新聞，街頭広告なら，「表示」されないということはない．でも，PC上では，すべてのユーザーが──とは言わないまでも，多くのユーザーが電子的なフィルタリングの手段を手もとに持っているのである．電子的な検閲は，徹底的であり拡張も容易である．

その点，ネット広告は「誰も見ていない」というわけではないし実際「ある程度は効果がある」のだろうけれど，結局「投資に見合った効果が──いやそれどころか表示が──なされているか分からない，まったく信用のおけないもの」なのではないか，と．

もちろん，われらの敬愛する企業経営者の方々の多くは，自分たちが思っている以上に自分の頭で考えてはおらず，彼らの愛読書やその手の雑誌に示された「事実」や「法則」にしたがって動くのだろうから，当面は大丈夫．

しかしいずれ「ネット広告の信用おけなさ」が彼らにも理解──もちろんその理解は「理性」よりも「崇拝」や「鵜呑み」によるものだろうけれど──されてしまったら？　くわばらくわばら．

久々に手書きでサイトを公開した

先週前半，とてもとても久しぶりに，ふつーの，手書きのHTMLでウェブサイトをつくった．この間に制作したものを公開するためのもの．とりあえず，今月中盤に作成したjQueryのプラグイン，Simple Templateを公開（つくった後でほぼ同名の別のプラグインが存在することに気がついた）．

手書きのHTMLというのは，ソースコードがCMSなどによって構成されたものでない，という意味で．DreamWeaverやホームページビルダーを使っていたという意味ではない（ここは強調…）．

もっとも各ページでメニューの項目を統一しなければならない都合などを考えるとすぐうんざりしてしまい，結局今ではPythonで記述したユーティリティプログラム（プログラムといっても極々単純で応用の利かないものであるが）でHTMLソースコードの構成を行っていたりする．

さてとりあえずサイトを作ってみたものの，次に公開できるものはなにかあるのだろうか，と考え中．

IEの正規表現 string.replaceメソッドとRegExp.$n

このGW中、構想2日、作成に2日もかけて、JavaScriptでうごくテンプレートエンジンのようなものをつくった。

「エンジン」というほど大したものではなく、ようするに文字列中で変数を使用したり、if文とeach文を使えるようにしたもの。とりあえず、構造は単純──これ以上複雑なものはぼくの頭では無理──なのでFirefoxやOpera、Safariでは動く。しかしIEでは動かない。なんだか、どうしようもなくバグっている。正規表現関連の処理で躓いている？

Googleで検索してみても、正規表現についてのIEの対応状況やバグの情報が見つからない…　DOMに関するものについては、本も出ているし、jQueryなどのライブラリでは当然その種の対応状況差やバグに対応してくれている。しかし、正規表現についてそういうライブラリはなさそう…　こまったなぁ…

【追記】

原因が分かった。

すくなくともIE7では、Stringオブジェクトのreplaceメソッドを、第1引数に正規表現、第2引数に動的な文字列の置き換えを行うための関数を指定して呼び出したとき、この第2引数の関数内で、RegExp.$n（nは整数）を呼び出しても、ただしく動作しない。

いや、そもそもreplaceメソッドの第2引数に指定した関数のスコープ内でも、RegExp.$nがちゃんと使えるなどと確約するような文章を読んだことがあるわけでもないので、「ただしくない」などというのはちょっとアレなのだが、しかし「直前の正規表現マッチングにおける、n番目の (...) に対応する文字列を返します。」（とほほのWWW入門）というところから自然に類推すれば、使えて当然というものである。

現にFirefox3、Opera9、Safari3では使えた。そしてIE7では使えなかった（せめてundefinedなどを返してくれればまだ解決は早かったのではと思う。IE7ではRegExp.$nは──いつもではないのだが──空文字列を返してよこすという、かなり奇妙な動作をしている。第1引数として渡した正規表現ではとてもキャッチできないような文字列を返すこともあった。何にしても最悪である）。

ヒントはここ（「JavascriptのString.replaceに無名関数を渡して複雑な置換」／Electronic Genome）にあった。

string.replace(regexp, function)

という形で、replaceメソッドを呼び出したとき、第2引数の関数には、引数が渡される。この引数は正規表現による直前のマッチングの結果により数が変化するので、関数内ではarguments[n]という形でアクセスするのが都合良い。このargumentsの内容は、それはそれでおもしろいのだが（ホントに）、この件には関係ないので、そこは上記の記事を参照のこと。

しかしともかく、このarguments[n]形式でのマッチング結果へのアクセスはうまくいった。IE6、IE7でもちゃんと動作する。他の上述のブラウザでも問題なく動く。

RegExp.$n形式のときの、「n」と、arguments[n]形式でのアクセスのときの「n」とは同一でよい。ただargumentsの最後尾と最後尾の1つ前、つまり2つの引数については別。この点は上記記事を参照するべし。

Tango続き

その後もTangoアイコンセットを探し回ってきたが、結局ブラウザ関係のアイコンは、OperaのTango CLテーマ（スキン）からいただくのがいちばん手っ取り早い方法のようである。

Operaの「ツール」→「外観の設定」の画面でダウンロードしたスキンは、Windows Vistaでは、「C:\Users\（ユーザ名）\AppData\Roaming\Opera\Opera\profile\skin」にある。Zip形式で保存されているのを解凍すれば、アイコン画像が入手できる。Zipの中に入っているテキストファイルを読む限り、Tango CLスキンはGPLなので、扱いも楽（？）でよい。

Firefoxの種々のTangoテーマからアイコンをいただくことも考えたが、とくに目的としていた「履歴」アイコンがちょっと気に入らずボツ（ちなみにこちらは何も一度ローカルのアプリ本体にダウンロードせずとも、Mozillaのアドオン・ページでダウンロードできる）。

Tangoアイコンを探す

ここのところPHPとjQuery、Uploadifyなどのプラグインを使用したファイル共有アプリの開発に参加していて、そこではTangoアイコンセットを使用している。

Tangoはそのデザインもよしなのだが、すくなくともベーシックなアイコンについてはCreativeCommons（CC）でもないようなので、大変に扱いが楽なのである。

しかし問題は公式サイト以外で公開されているものにしばしばライセンスが不明なもの──フリーならフリーと書くべきである──がある。

● tango extras (many icons for tango)　0.3

公式サイト外で公開されているうちで数量が多く役に立つのが、ここで公開されているものなのだが、

License:
see readme files in every archive since this set of icons contains many mixed icons

──とあるにもかかわらずそれぞれのzipファイルを解凍してもライセンスについて述べているファイルは出てこない。もちろんそこは都合よく解釈させてもらっているが…（「つまりパグリックドメインですね！」）

● Icon Inventory for Firefox3

ここは公式サイトからリンクされているページだが、公開されているアイコンを蝟集した画像にはライセンスについて何ら記述がない。だからここでも都合よい解釈でいこう。

● Tango OOo Theme

一番最近に探していたのはOpenOffice.orgで使用されているアイコン。自分のPC内にインストールされているOpenOffice.org 3のアプリ本体のファイル群の中をさがしたところ、

Program Files/OpenOffice.org 3/Basis/share/config

のなかにzipファイルの形でテーマファイルが格納されているのを発見。tango_images.zipのなかにTangoアイコンが含まれていることがわかったが、よく見るとTangoというよりGnomeテーマ（たしかにTangoと共通の部分が多いが異なる部分もあるアイコンセット）らしい。がっかり。しかもTangoではないアイコンがおびただしく混じっている…　OpenOffice全体と同様このアイコンもLGPLと考えてよいのかな…

またここで配布されているものはなぜかWindowsVistaに備わっている解凍機能（「すべて展開」）ではちゃんと解凍できない。他のアーカイバを使えば解凍できるが、これも同上でなぜかTangoならざるアイコンばかり詰まっている。images_industrial/resその他の中にTangoアイコンが見つかったが…（考えてみればこのフォルダ名自体おかしいではないか。industrialはそれ自体テーマ名である）。ともあれはっきりCCライセンス下での公開とあって、わかりやすい。

Powered by ScribeFire.

ImpressCMSでPrototype.jsとjQueryが衝突

前の投稿でも述べたところのjQueryと他のJSライブラリ──とくにPrototype.jsライブラリ──との衝突の問題．実際上そうそう起きることもないのだろうなと思っていたのであるが，ImpressCMSではそれが起きてしまった．

どうやらImpressCMSは標準の状態──オンラインで配布されたままの状態──でPrototype.jsが呼び出されるらしい．そのせいでXoops2上で開発していたモジュールで，jQueryを使用しているものに不具合が出てしまった．jQuery側で，「noConflict」メソッドを呼び出して，「$」を「jQuery」のエイリアスとしないようにする必要がある．

それにしてもまぁ，結局のところなぜ「$」を使おうとするのかわからない．1文字というのが最悪である（$jでもよいではないか）．

jQueryプラグインに挑戦しようとして…

これで何度目になるのだか分からないが，jQueryのプラグインを作成してみようと思い立った──思い立って「プラグイン　作り方」みたいなキーワードで検索してみると，「0日目：jQueryプラグイン作成の基礎知識」という記事と，その記事のブックマーク，ウェブクリップ，ブログへの引用などがおびただしく表示される．

でもこの記事はあくまで「初歩」的内容のみということらしく（それはそれでよいのだが），他のライブラリとの共存（衝突回避）の問題などにはふれておらず，細かいことにはふれていない感じ．この“流布”ぶりは作為的なものなのか，と感じる．

衝突回避問題ふくめ詳しい解説では「jQuery(3): プラグインを作ろう　-　HDEラボ」のほうが断然役立つ．以前すこし読んだ記憶があったのが，前述の記事の検索結果に邪魔されてなかなか発見できなかった．

拡張機能 Web Search Pro が便利

便利なFirefoxの拡張機能を見つけた．「見つけた」といってもユーザー評価が高く，「アドオン」→「アドオンを入手」画面でももともと高順位に表示されていたのだが…

その拡張機能 Web Search Pro は，Drag & DropZonesとContext Searchを掛け合わせたような拡張機能．実際関わりがあるらしいが，ともかく開発の裏側とかはあまり重要ではない．

Webページ上の選択したテキストをドラッグする（クリックしたままボタンを放さずカーソルを移動する）と，あらかじめ登録しておいた検索エンジンのタイル（Zones）がページの上に半透明に表示されて，その選択した単語を検索したい検索エンジンのタイル上にドロップする（クリックを終える）と，その検索エンジンでの検索結果を新しいタブに表示してくれる（前者と共通の機能）．

またテキストを選択した状態で右クリック→コンテクストメニューを表示すると「Web Search Pro for "（選択したテキスト）" on」という項目が表示されていて，ここからも検索エンジンを選べる（後者と共通の機能）．

Powered by ScribeFire.

Inkscapeに手をつける

オープンソース、フリーのベクターグラフィックソフト、Inkscape。
Adobe Illustratorの代わりとして、以前から目をつけていたが、PCにインストールしたまま、たまにSVG形式ファイルをPNG形式やJPG形式に変換するのに使う以外、ほとんど使用したことがなかった。

単に使う機会、使わねばならない場面がなかったということもあるけれど、ユーザーインターフェイス（UI）がわかりにくく、また使いにくいというのも大きい。もちろん、画像編集ソフトのUIというのは初心者にとってはいつも複雑過ぎるもの。使いにくいというのも、現行バージョンが 0.46 なので、仕方がないといえばそうなのである。

とはいえ、ウェブサイトで使用するロゴやアイコンなどの制作のためには、使用方法を覚えておいた方が次ごうが良さそうだということで、またマニュアルやチュートリアルを読み始めた。

なにはともあれ、まずはUIの見てくれをよくしたい、ということで、Windows版Inkscapeで使用されているデフォルト・テーマ（アイコンセット）を、Linux版──FedoraやUbuntuのリポジトリに登録されている──Inkscapeで使用されているTangoテーマ（アイコンセット）に切り替えよう、ということになった。

「Inkscape」「テーマ」などのキーワードで検索するとかなり上位に表示されるのは、Inkscape@JP - リファレンス (カスタマイズ >> テーマ)だが、ここ書かれていた情報はかなり古いものらしく、ここで上げられているTangoアイコンセットは実際上かなり不完全な出来の段階のものであった。

「Inkscape」「Tango」で検索すると、[Tango-artists] Inkscape Tango Icon Theme / Simon Pascal Klein klepas at klepas.org Mon Jan 12 09:04:35 PST 2009というポストがあって、ここからリンクされている場所http://jesusda.com/files/inkscape-tango-theme/に、7z圧縮されたTangoアイコンセットが公開されていた。

テーマ（アイコンセット）の交換方法については、Inkscape@JPに掲載されていたままの方法がVistaでも通用した。

Powered by ScribeFire.

mimeTypes.rdfに異常

Firefox3のプロファイル・フォルダ内にあるmimeTypes.rdfというXML文書に異常があり、CMSのファイルアップロードツールで、PDFファイルをWebサーバへアップロードしようとしたところ、これが拒絶されてエラーメッセージが表示されるという問題が起きた。

同じ問題が、「FireFox の mime タイプがおかしい」（はっぴぃ・りなっくす）で取り上げられていた。

サーバー側に通知される MIME タイプが
「application/x-octet-stream」になっていた。

まさに、これ。
ここにあった、解決方法で問題は解決。
ただしこの記事では、mimeTypes.rdfのある場所が、

C:\Documents and Settings\user\Application Data\Mozilla\Firefox\Profiles\cqq0mbyp.default\mimeTypes.rdf

となっていたが、こちらのPC（Windows Vista Business　SP1）では、

C:\Users\(user name)\AppData\Roaming\Mozilla\Firefox\Profiles\(...).default

にあったので、ここにメモしておく次第。

Powered by ScribeFire.

goo辞書でFirefoxがクラッシュ…

goo辞書サービスを利用しているときに、Firefox3（Windows Vista Business SP1）が頻繁にクラッシュするような気がする。
単語を検索し、検索結果の一覧画面で、その単語の解説を読もうと、リンクをクリックした瞬間の。

頻繁といっても、他のサイトと比べて、という相対的なものだが、一瞬でFirefoxがダウンしてしまい、Windowsの側からFirefoxがクラッシュした旨報告される場合と、Firefox自体のクラッシュ報告ツールが表示される場合とがある。複数のタブを開いて作業をしていると（それこそScribeFireなどを使用していると）、ぞっとする瞬間である。

当該画面では7つのスクリプトが読み込まれているようになっているが（うち1つは読み込み失敗）、これらのうちに問題があるのかも知れない。事実ならば、gooの問題でもあるが、Firefoxの問題でもある。

Powered by ScribeFire.

『ウィキペディア革命―そこで何が起きているのか?』──もっと良質の翻訳がほしい

何となくおもしろそうに思って、『ウィキペディア革命―そこで何が起きているのか?』を買って、読んでいる。

しかし──読んでいる途中に感想を書くのもあれだが──、翻訳者がコンピュータ用語に通じていないためか、原書の著者がそうであるためか、あるいは日本とフランスとでコンピュータ用語体系に違いがあるためか、意味不明な表現箇所が散見されて残念である。たぶん翻訳がうまくないのだと思う。コンピュータ用語と関係のない部分でも、文意を解せない箇所があるから。

ウィキペディアが──ウィキペディアそのもの、ウィキペディアの運営者個人、ウィキペディアで執筆する人びと、ウィキペディアを利用する人びと、そのそれぞれが──持つ問題性を考えれば、この読みにくさはまったく残念である。

Powered by ScribeFire.