2006-10-01 [長年日記]
_ Yahoo! Widgets が面白いかも
突然デスクトップの話が増え始めたが、まぁサーバの話に行ったりデスクトップの話にきたりをくり返していた方がバランスがよかろうと。
で、なんで Yahoo! Widgets なのかというと、昔からクロスプラットフォームで動く小物デスクトップツールがほしいというか、やっぱ作れるといいなと思うことがよくあったから。
こういう小物は自分向けとか分かってる人が使う分には sh + awk とか Perl とか Ruby で書きゃいいんだけど、他の人も使えるとお互いにハッピーだよなと思うことは実はよくある。しかし awk とか Perl とか Ruby なんてのは普通の人の使っている PC（Windows）には入ってないし、OSX の場合は入ってるけど Terminal でコマンド叩けというのもアレなので、ちょっとした GUI がほしいという話になるわけだ。今なら Web ベースでもそれなりの使い勝手が実現できるので全部 Web ベースでもいんじゃね？と思ってしまいがちだが、現実にはローカルのファイルを操作したいとか、そういう需要が案外あって Web ベースには持っていけなかったりする。
プラットフォームを絞れるならこういう話に使えるツールは昔からある。AppleScript もそうだし、古くは DOS のバッチ用のユーティリティやメニュー系のツールも、HSP なんかもこういう系統に入れてしまっていいように思う。猛者になると Lotus 1-2-3 のマクロや Excel VBA でなんでもこなしてしまう人が出てくる、ああいう領域の話ね。今なら Windows でいちばんまっとうな手法は WSH なんだろな。たぶん。
問題はクロスプラットフォームって話になると途端に難しくなってしまう点で。いやね、
Windows で動かないとお仕事的には嬉しくないし、かといって Mac で動かないと自分が楽しくない
わけ。ここポイントね。テストに出すから。
つーことで以前から目をつけているのは wxWidgets や Gecko Runtime Environment だったり、まぁもっと言えば Java で書けばええやんという話になるわけだけど、やりたいことはそんなもんでイチからチマチマ書くような大げさなもんじゃなくて、ほんと sh スクリプトくらいなもんなわけ。（さすがに sh で書くのはちょっとしんどいけど。）
そこで Yahoo! Widgets なんだけど、これは内部に基本的な Unix コマンドを持ってるじゃないの。OSX は標準で入ってるから当然なんだけど、Windows 版も何十個もバイナリが入ってる。細かく確認したわけじゃないけど、Windows 版にバンドルされてるのは gnuwin32 のバイナリかな。たぶん。ま、つまり普通にローカルの作業ができるわけ。Perl や Ruby こそ入ってないけど、sh + fileutils + gawk ってのは普通にイケる。で、それに GUI を被せることができる。
いいじゃないの。
よおし。なんか書いてみっか。
2006-10-03 [長年日記]
_ fc2 が画像の直リンを弾いてるっぽい
お気に入りのねこブログがしばらく前（2週間くらい前かな？）から bloglines では何が何やら分からなくなってしまった。HTML の方では正しくねこを拝むことができるので、たぶん feed 経由の「いわゆる直リン」を弾くように設定が変わっちゃったんだろな。しかしねこ写真のブログなのに写真見れないんじゃ意味ないからなぁ。こういうのは feed に直接画像を埋め込んじゃう*1とかすれば回避できるんだろか。
この話に限らず、少し前から写真熱を取り戻そうとか思いながらスナップ写真を載せてるブログの feed をいくつか見てるんだけど、写真が入っていない feed の多いこと多いこと。photolog なのに画像が入ってないんじゃまったく意味ないじゃんとか思うんだが、やはりまだそういう人たちにはそれほど feed はアピールできてないのかな。あるいはどうしても HTML の方を見てほしい理由があるのか。*2
どうしても HTML にアクセスしてほしい（例えば写真の見やすさを考慮した背景などのデザインに凝っている）場合は、フィードにちょっと画質を落としたサムネイルを含め、「もっと読む」なんかで HTML の方へ誘導する方法もあるような気がするんだけど、どうだろう。
もっとアグレッシブに写真の一部にモザイクが掛かっている feed だとさらに HTML への誘導効果は高いかな。あ、そういう「CM またぎ feed 生成サービス」みたいなのあったら面白いかも。画像の一部にモザイクが掛かるとか、固有名詞っぽいところが勝手に伏せ字になるとか、人物を差してそうだったら「ある大物SE」とかイニシャルに差し変わっちゃうの。*3「もっと読む」のリンクの方は一回広告を表示してから HTML が出力される仕組みになってるの。
どうよ。放送業界に学ぶ feed 広告ビジネス。
2006-10-04 [長年日記]
_ Sunbird 0.3RC1
Mozilla な Calendar アプリである Sunbird の 0.3 RC1 が出ました。
Calendar Weblog: Sunbird and Lightning 0.3RC1 available
試してみたけど、Month View や Multi Week で日にちをまたいでガッとレンジを設定してイベントを設定するっていう使い方はできないんだな。New Event からは作れるんだけど。
どうも自分は右脳人間なのかオブ脳なのか、せっかくカレンダーが目の前にあるんだからまずそこにマウスでガッと線を引っ張って、で、何のイベントかを書き込むっていう使い方がしたいんだなぁ。日時を数字で入力するという使い方は性に合わない。もちろん細かい数字の指定はマウスよりも直接入力した方がいいんだけど、手順としてまずマウスでガッとやりたいの、ガッと。
Day View や Week View ではできるだけにとても残念だ。むしろ今の自分のスタイルでは Day View や Week View の中で時間をマウスでガッと指定できても嬉しい機会ってそんなにないのね。ガントチャート的というか、”日”単位でガッといきたい。
2006-10-05 [長年日記]
_ 最近リファラがまったく残らなくなった
※ 原因判明。tDiary 用 spamフィルタの正規表現で半角英数記号のみのアクセスを弾くようにしていたのが原因でした。自分でリンクを踏んでみてやっと気づいた。記号を含めたら urlencode 済み文字列が全部引っかかるじゃん。
でも spam フィルタの設定画面もまずいね、こりゃ。ツッコミだけでなく referer も含めて弾かれちゃうことがこの画面からは分からないもの。
と言い訳。
で、フィルタ解除したら早速 comment spam だな。どーしたもんかね、これ。ascii のみのツッコミを弾くっていうのはこの設定画面からは不可能なんだな。
ここのところ、リファラがまったく表示されなくなった。なんか設定ミスったのかなぁ？ カウンタとか付けてないし、アクセス解析もしてないので、リファラが消えると何が起きているのかさっぱり分からない。リファラを見て、ははぁ、こういう話題があるのか、と知ることもある*1し、なんにもないのはさすがに寂しい。*2
過去の日記へのリファラだから消えてなくなるとか言うんじゃなくて最初からなんにも表示されない。過去の日記の分は「当日でなくなったら消える」はずだから、最初からまったく表示されないっていうのは、何かのミスでなければ検索でたまたま引っかかってくる人すらゼロになったということか？ さすがにちょっとそれは変だなぁ。
いじったところと言えば半角英数記号のみのツッコミを弾くっていう設定くらいか。その設定が referer にまで影響するなんてこたぁないだろうし。（[追記] バッチリ影響してました。）
なーんだろ。
[追記]アクセス解析してた。解析のサービスを有効にしてたのをすっかり忘れてた。一ヶ月単位の集計結果を見るとなかなか面白い。user agent なんかは上位のほとんどが検索エンジンで、ついで feed 取得系のロボット。feedpath, google, bloglines, plagger, sharpreader, 1470.net 辺りが上の方にいる。Hatena Antena, Hatena RSS はその下くらい。livedoor はあんまりいない。
一昔前だと IE より Mozilla 系の方がアクセスが多いうちのサイトはやっぱ技術寄りかなぁみたいなことを思うところなんだろうけど、最近のブラウザの ua がどんなんだかもうよく分かっていない自分がいましたよorz 上位にいきなり食い込んでる IE とおぼしき ua は当然詐称だろと思っちゃうしね。
ところでこの解析、file と page に分かれてるけど、.rdf は…やっぱ page には入らないんだよな。feed と page とその他、で集計できると便利かも。でも feed の url って限定できないしなぁ。CMS でない場合はもうよく分からんということか。
2006-10-06 [長年日記]
_ Thunderbird のメッセージフィルタにコメントが書けたら便利じゃないかな。
メッセージフィルタの中に、順番に意味をもつフィルタの組み合わせがある。例えばこのアドレスからくるメールの大半はこのフォルダに入れておきたいんだけど、この 文言が subject に含まれる場合だけこっち、とか。あ、その場合は「含まれない」という条件を使えばいいのか。うーん。
でも同じ条件（で反対の意味）の記述を2つのフィルタに追加していかなきゃいけないのも面倒だなぁ。まぁ依存関係がややこしくなるのでその方がいいんだろうけど、管理が煩雑なのもアレだし、せっかく実行に順位があるんだからそれを使って記述がシンプルになるならその方がいいじゃんと思うのは逸般人の発想か？
あと正規表現でズバっと書きたいとかそういうことを思うやつはフィルタ用の別なプログラムで前処理掛けるようにした方がいいんだろか。msgFilterRules.dat はとても手書きしたいとは思えないし、どういう書き方ができるのかも分からないしなぁ。（なんかヘタにいじったら壊しそうな雰囲気。）
思えば電八は便利だったな。
2006-10-08 [長年日記]
_ Y! Widget Engine + UnixUtils で日本語を扱うには
※ UnixUtils というのは Windows 版でバンドルされている Unix コマンドのバイナリが入っているディレクトリ名のことです。今後、YWE*1 で利用できる Unix コマンドのことを UnixUtils と書くこととします。
調べたら日本語周りがやはり悩ましげ。JavaScript の部分は UTF-8 か UTF-16 でいいとして、UnixUtils の部分をどうするか。例えば Windows にバンドルされている gawk であれば locale に応じてそれなりによしなに日本語を扱ってくれるが、考えたら OSX 標準の awk は gawk じゃない。nawk かなんかだっけ。まぁどっちにしろ locale と一致しないエンコーディングはそのままじゃ扱えないわけで。何かしらエンコーディングを変換するツールが要るなぁというのが実際のところ。
Panther 以降は iconv が標準バンドルなので、Windows 用に gnuwin32 の iconv を Widget に含めてしまうことでなんとか対応できるかなって感じ。ただし iconv には自動判別の機能はないので、OOo みたいにファイルを開いて一部を目視で確認してもらって、このエンコーディングで OK なら次へ進む、という形にしないとダメっぽい。（Web から取得するんであればヘッダなり meta なりのエンコーディングを読み取ればいいんだけど。）
ところで iconv って半角カナの扱いはどうなってんだろ。
*1 Yahoo! Widget Engine
2006-10-17 [長年日記]
_ JavaScript 周りをもう一回確認しなきゃな
class ベース OO をマネっこしてるフレームワークは class 名というかコンストラクタというか、それを取得できなくなるよね？と不安になり、確認してみた*1。あと、コンストラクタや prototype プロパティへあれこれ追加する記法が変わっちゃうとドキュメンテーションツールが対応できなくなるんじゃね？と思い、それを確認…しなきゃと思っているところ。（つまりまだ確認していない。）
挙げたのは小さめで目に留まっているものだけ。別にフレームワークを網羅するつもりはないし、大きいものは扱いに困りそうで敬遠してるところ。
class名
- prototype(1.4)
- constructor も instanceof も意図通り動作せず
- jQuery(1.0.2)
- 独自の class 構文はない
- mootools(rev.64)
- constructor は意図通り取得できないが、instanceof での確認は可能
こうして見ると Web に特化しちゃうなら jQuery もアリかなと思わなくもない。mootools は全体の構造も丁寧に整理されている感じで好感が持てる。
prototype は最初のインパクトはすごかったが、インスパイアされた後出しのものが結構いいし、使うなら上のような問題がないものの方が嬉しいな。まぁ prototype が現状ではいちばん情報が豊富っぽいんだけど。
ドキュメンテーション
class の構造やツリーをドキュメント生成ツールが正しく認識できなくなるとドキュメントの自動生成ができなくなり、結果、ドキュメントのないコードだけが残り、「最初に書いたもん勝ち」というありがちな状況を生みそう。ということでドキュメント生成ツールとの相性を確認しなきゃな、と思っている。
今回、気になって調べたら Natural Docs という、これまた Perl で書かれたツールがあるみたいなので、それの動作も確認できたらいいなと思っている。
- jsDoc × prototype
- 未
- jsDoc × mootools
- 未
- Natural Docs × prototype
- 未
- Natural Docs × mootools
- 未
jQuery は独自の class 構文がないのでドキュメント生成ツールの対応を考える必要はたぶんないと思う。
※ Ajaxian >> Natural Docs: Better Javascript Doc によると、DoJo と Natural Docs の相性は悪くないのかな？
*1 そんなもん分かんなくたってメソッドがあったら動けばいいじゃないという考え方はもちろんアリ。
2006-10-20 [長年日記]
_ アドレス入力のダイアログは消さないでほしい
たいした内容じゃないんだけど。
最近のブラウザはアドレスバーに直接 URL を入力するじゃないですか。まぁそれが当たり前だと思っている人の方がたぶん圧倒的に多いですよね。かくいう私も「インターネット」を初めて体験したときに使った Netscape ではすでにそうでした。
ま、それはいいんですよ。問題は、このアドレスバーが見えなくなっていると URL を入力できないブラウザがあるっちゅーことなのです。例えば Firefox の場合は
- ツールバー周りのカスタマイズでアドレスバーを非表示にしている場合は [ ファイル ] → [ URL を開く ] としたときにそれ用のダイアログを開いてくれる
- しかしウィンドウ幅やツールボタンの関係でアドレスバーが実質的に使いものにならない場合は表示されているはずのアドレスバーにフォーカスが移るだけ
という動作をします。これはまだマシな方で、Opera ではそもそも [ ファイル ] → [ 開く ] の動作に URL を開くという機能がないし、Safari もアドレスバーを隠している状態で [ ファイル ] → [ 場所を開く ] とするとニョキっとアドレスバーが復活してしまいます。
※ IE 6 の場合は問答無用でダイアログを開くのですが、なんとなく IE 7 は最近のブラウザの傾向に合わせてきそうな予感。
いやまぁ、なんでそう思ったかっていうと、スクリーンショットを撮るときの都合で Opera のスモールスクリーンレンダリングを使って、さらにもうちょっと小さくして携帯っぽい雰囲気のスクリーンショットを撮ろうと思ったわけさ。そしたらアドレスの入力ができなくなっちゃってさ。あれーどうすんだコレと。時間ねーからまたウィンドウでかくしてアドレス入れ直してすでに作成してあるスクリーンショットの画像の上に重ねて目で同じ大きさに戻してスクリーンショットを撮って…って作業をやってたの。なんだかばかくさいなと思ったわけですよ。アドレスの入力さえできればウィンドウサイズを一生懸命大きくしたり小さくしたりする必要ないのに。
このときなぜ Firfox のスモールスクリーンレンダリングを使わなかったっていうと、フォームのボタンとかかっこよくないから。あーなに？ 全部画像で作ればって？ そんな時間ねーから自分でスクリーンショット撮ってんでしょうが。
あー、Camino にスモールスクリーンレンダリングできる拡張があればいちばんいいような気がしてきた。Camino に拡張なんてあんの？
2006-10-21 [長年日記]
_ 特定のフォントだけ適用除外ってできないかな
いやね、具体的には Osaka なんですけど。
これね、肉厚すぎて本文が丸ごと Osaka だと目が疲れるんですよ。平成でもヒラギノでもいい、Osaka にはしたくない。でもこれ、実現する方法がないような？*1
ユーザー CSS で上書き？ でも「このフォントの指定だけを無視する」なんて使い方はできないような？ 「このフォント指定で上書きする」っていうのは可能だけど、いつも必ずヒラギノで読みたいとかいう要求でもないしなぁ。
あ、そういえば昔 Windows でなんかフォントを一時的に on/off するソフトを使ってたな。*2あんなんが Mac にもあればいいのかな。めでたく Terminal の常用フォントから Osaka 外れたし。
試しに FontBook で使用停止にしてみたけど、やっぱ太いなぁ。うーん、この辺さっぱり分かってないからな。とりあえず @-moz-document で該当サイトの font 指定を上書きしておくか。ニュース系なので今後もまず見るしね。
2006-10-22 [長年日記]
_ Camino にした
Camino - MozillaのパワーとMacのエレガンス
XUL がね、遅いんですよ、OSX では。Windows とか Linux とか使ってる人は意外と快適だと思うんですけど、OSX 版の Firefox は明らかに他のブラウザより遅いんです。
それでも我慢してました。Mozilla の頃からのつきあいですもの。でもねー、試しに Camino 動かしてみたらすっげー速いの。そら速いだろうなとは思っていたけどもさ。Safari の速さを思えばこれくらい速くなっても不思議はないなと思ったけどもさ。いやー速いのなんの。
というわけで Camino に移行決定。webdeveloper はじめ各種 extension は、普段ただ Web 見てるときには必要ないしね。diigo と del.icio.us と bloglines の bookmarklet が動けば問題ないことが分かった。userContent.css はそのまま使えるし、user.js もだいたいうまく動く。bbs2chreader と QuickNote の extension は惜しいけど、2ch はそもそも最近ほとんど見ないし、そのままスルー*1、QuickNote は何か他のものを探せばいいや。もともとブラウザが常に立ち上がっているはずだからブラウザに依存したメモソフトを使うって発想になっただけで、これでなきゃいけないわけじゃない。スキンも最近はまったく凝ってなかったので気にしない。
いやーはえーはえー。Mozilla から Firebird に乗り換えたときくらいかそれ以上の衝撃。速い。
※ デフォルトでは command + クリックでタブじゃなくて新規ウィンドウで開いちゃうけど、これを変更すればほぼ違和感なし。あ。「長押し」ができない。これ結構痛い。あとタブの入れ替えができない。うむむ。
なんてものが。そうか忘れてた。あとは単体の RSS リーダが要るな。Camino は 1.1 で auto-discovery には対応するらしいけど、その時点でもリーダの機能はつかなさげなので、ローカルのフィードを確認する方法がない。
うげ。
Diigolet は単体じゃ動かないのか。ツールバーの機能を使って個人の設定を読み取って他に登録しようと考えているブックマークサービスを列挙する形になっているっぽい。つまり、Diigo にだけ post する分にはツールバーは要らないが、del.icio.us に同時に投げようと思ったらツールバーが要る。
うーむ。困ったな。
*1 RSS リーダーに登録しちゃうと気になるので登録はしない。
2006-10-23 [長年日記]
_ ブックマーク難民
Camino では Diigo ツールバーが動かないので del.icio.us（など）へのクロスポストができない。困ったなということで調べてみると Greasemonkey + userscript で同時ポストという技を使っている人がいるみたい。でも Camino は Greasemonkey も動かない。
Camino で Userscripts を利用する100-99の方法 (Camino Userscripts 100-99=1) - 2xup.org
によると Geekmonkey を使えばイケるらしいことは分かったが、そもそも標準でクロスポストの機能を持っている Diigo と del.icio.us に同時に投げたいなどという要求がないらしく、そんなスクリプトは見つからない。作れってか。今ちょっとそこには興味ないのですぐに動くものがほしいんだが。
Spurl.net というサービスは del.icio.us 限定だがサーバサイドでクロスポストの処理をやってくれるみたいだ。よーしじゃあアカウント作っちゃうぞー。import ! ……。経過がさっぱり分からない。しばらく放置したら import されてた。なんかゆってくれ。よーし検索！ 化け化けじゃん。これじゃ Diigo の代わりにはならない。
うぬー。
※ del.icio.us へのクロスポストを諦めればいいじゃんと思ったあなた。正しいけれどもそれは今のところできない。理由は二つある。一つはバックアップのため。もう一つは後発のブックマークサービスの多くは機能が増えた分操作感が悪い。なんだかんだで del.icio.us は使いやすいのよ。検索はともかく、タグや時系列に眺め直すときには del.icio.us の方が楽なの。
[2006-10-26 追記]Diigolet やツールバーをアップデートしたら Firefox でもクロスポストできなくなったorz ふざけんなっ。
2006-10-24 [長年日記]
_ emacs-w3m で referer は吐けないのか？
そんなにヘビーに使っているわけでもなかったので今まで w3m + Emacs で textarea を編集する際は普通に w3m から Emacs を起動して利用していたんだけど、ふと思い立って w3m-el を入れて全部 Emacs から作業するようにしてみた。
tDiary の CSRF 対策に引っかかって書いた内容全部飛ばしちまったorz
あとで分かったことだけど、どうも w3m から Emacs を起動するか、Emacs から w3m を起動するかの違いでしかないっぽいので、21.3.5 なら起動も速いし今まで通りの使い方でいいような気がしてきた。この方がマウスも普通に使えるし。
それより w3m.org がソースをそのまま吐いているのは何が起きているんだろうか。
ついでに以前 mule-ucs を組み込んで激重になった Debian 上の Emacs でも w3m-el なら快適だーと思っていたが、今度は textarea のレンダリングがおかしい。おうおうおう。そこが目的なんじゃい、emacs-w3m さんよぉ*1。
ということで強権発動して、システムワイドでいきなり mule-ucs を読み込もうとする startup の elisp を外した。必要なときに自分で require することにして起動を軽くし、こっちも w3m から Emacs を起動する方式に変更。同時にあれこれ起動を重くする要素を見直して少しでも快適に作業できるようにしてみた。
結局、元通りってことなんだな。
※ tDiary の設定をいじればいいじゃんとも思うんだけど、まぁそもそも emacs-w3m の操作性がちょっと趣味に合わないので、無理に使わなくてもいいやと思ったのでした。そうこう言っててまたそっちに傾くかもしれないんだけど。
*1 たぶんバージョンがちょっと合ってないんだろな。
2006-10-25 [長年日記]
_ 最近 Scheme にハマっている
別に SICP が流行っているとか関数型言語を勉強したいとかそういうわけではなくて。*1
なんでかって言うと、単に Emacs Lisp のすごさを感じることが増えてきたから、Lisp に興味が涌いてきたという流れ。じゃあなんで素直に Emacs Lisp じゃなくて Scheme なのかと言うと、この記事が前から気になっていたから。
OOエンジニアの輪！ 〜 第 21 回 川合史朗 さんの巻 〜
なんつーか、CLOS すげーっていうか、河合さんすげーっていうか。ということで実際には Scheme に興味が涌いたんじゃなくて、Lisp に興味が涌いたついでに Gauche 触ってみようということなのであった。*2Emacs Lisp は副次的に多少でも読み書きできるようになったらラッキー、くらいにしか考えていない。
とりあえず触りだけ勉強している限りは要素が少なくて助かる。ヘタすると本体の動作ぶっ壊しますよという辺りも Ruby や JavaScript の経験があればそんなに違和感はないし、メソッドがクラスに属していないとか、クラスが名前空間を作らないとかそういうのもなんとなく普通に飲み込めるようになってきているので、へー面白いと感じることができる。もう完全にクラスベースの呪縛からは解き放たれた感じ。よしよし。
2006-10-26 [長年日記]
_ なんちゃってスモールスクリーンレンダリング.user.js
この間のスクリーンショット事件で頭にきたので作ってみた。一応 greasemonkey でメニューから実行できるようになってる。
/**
* Pseudo Small Screen Rendering
*
* @constructor
*/
function PseudoSSR() {
/**
* base css
* @type string
*/
this.base_css = "* { margin: 0; padding: 0; line-height: 1.2em }";
/**
* body style
* @type Object
*/
this.body = {
'background': 'white',
'font': 'normal 100%/1.2 monospace',
'color': 'black',
};
/**
* container, for making body overflowed
* @type Object
*/
this.container = {
'width': '11.5em',
'height': '11.6em',
'overflow': 'auto',
'border': '3px inset black',
};
/**
* list block css
* @type Object
*/
this.list = {
'padding': '0 0 0 1.5em',
};
/**
* list item css
* @type Object
*/
this.list_item = {
'margin': '0 0 0 0em',
'list-style-position': 'inside',
};
/**
* force `a color' blue
* @type Object
* @since 2006-10-30
*/
this.a = {
'color': 'blue',
};
};
PseudoSSR.prototype = {
/**
* change html and apply css
*/
run: function() {
this.append_base_css();
this.insert_container();
var body = document.getElementsByTagName( 'body' );
this.apply_style( body[0], this.body );
var container = document.getElementById( 'container' );
this.apply_style( container, this.container );
this.apply_style4elements( 'ul', this.list );
this.apply_style4elements( 'ol', this.list );
this.apply_style4elements( 'li', this.list_item );
this.apply_style4elements( 'a', this.a );
},
/**
* append basic css in <style> element
*/
append_base_css: function() {
var head = document.getElementsByTagName( 'head' );
head = head[0];
var style = document.createElement( 'style' );
head.appendChild( style );
var style = head.getElementsByTagName( 'style' );
style = style[0];
style.innerHTML= this.base_css;
},
/**
* insert container <div> element
*/
insert_container: function() {
var body = document.getElementsByTagName( 'body' );
body = body[0];
var doc = new String( body.innerHTML );
body.innerHTML = '<div id="container">' + doc + '</div>';
},
/**
* apply JSON-style CSS to element collection
*
* @since 2006-10-30
* @param String ele
* @param Object style
*/
apply_style4elements: function( ele, style ) {
var node = document.getElementsByTagName( ele );
var len = node.length;
for ( var i = 0; i < len; i++ ) {
this.apply_style( node[i], style );
}
},
/**
* apply JSON-style CSS to element
*
* @since 2006-10-26
* @param DomNode ele
* @param Object style
*/
apply_style: function( ele, style ) {
var ele_style = ele.style;
for ( var prop in style ) {
ele_style[prop] = style[prop];
}
}
};
/**
* launcher
*/
GM_registerMenuCommand( 'PseudoSSR', function() {
var ssr = new PseudoSSR();
ssr.run();
} );
やってることは単に CSS で見た目を変えてるだけ（それも margin とかサイズをいじってるだけ）なので、user css だけでできるんだけど、user javascript になっていれば Gecko ブラウザで適用のタイミングを自分で選べるのでわざわざ JavaScript にしてみました。
ポイントは
- 自家製なので中身いじりたい放題
- Opera とか webdeveloper の small screen rendering よりも「ケータイっぽい」
くらいしかないです。
GM_registerMenuCommand() の中身をそのまま素で書いてやれば GeekMonkey を使ってブックマークレットにして Camino で動かせることを確認。CreamMonkey で動かすのには失敗しました。どうやんのか分かりません。
CSS を冒頭で定義しているのでこの辺をいじれば自分の好きなデザインのスモールスクリーンレンダリングもどきが作れます。あと、いきなり body 直下に div#container という要素を挿入するので、すでに container という id を持つ要素があるとまずいです。
margin-* とか font-* とかは DOM バインディングで定義されていないので反映されません。Firefox で試した限りでは fontSize などで定義されているようです。あるいは簡略記法で定義するのが純粋な CSS 上の表記と一貫性があっていいかも。
というわけでもろもろ踏まえてご自由にご利用ください。
2006-10-27 [長年日記]
_ GeekMonkey で利用する user js はどこにどう置いておくのがよいか？
いやーちょっとびっくりした。そういえば
bookmarklet を今まで意識して使ったことがなかった
という事実に今さら気がついた。昔、役に立つんだか立たないんだかよく分からない bookmarklet が流行った時期があったけど、その頃は興味なかったし必要もなかったしねぇ。
でも最近はサービスへのアクセスを助ける bookmarklet やツールバーってかなり普通に提供されてるし、かなり遅れて、しかも知らない間に bookmarklet を使うようになっていた。しかしここで、bookmarklet の基本中の基本を分かっていないということに気がつかされたわけだ。
いやね、GeekMonkey で利用するスクリプトが増えたらどうやって管理すればいいんだろうとふと思ったわけですよ。昨日は何も考えずに localhost の Apache 配下のフォルダに突っ込んだけどこれこんなところに置いといたらダメだなと思って動かしたの。でも GeekMonkey を使った bookmarklet って、要するにそのスクリプトを読み込む <script> 文を開いているドキュメントに挿入するだけだから、
http でアクセスできるところに javascript が置かれていないといけない
わけ。あーれー。自分だけで使うんでも http サーバが要るってか。まぁ普段はほとんど起きっぱなしだけど、なんかいやだな、それ。どこが user js なんだって感じ。
この「なんかいやだな」って感覚はたぶん GreaseMonkey から入っちゃったからなんだよね。CreamMonkey もそうだけど、こいつらはローカルのファイルに直接アクセスして user js を読み込んで実行させることができるのに対し、bookmarklet ではそれができない。つまり常にどこかで http サーバを動かしておかなければいけない。
あ。なんかそれ用に超ちっちゃい http サーバ動かしておけばいいか？ Apache だと何かの拍子に落としそうだけど、ひっそり動かしておく分には気づかずに見過ごしそうだ。
なんか探してみよう。
……。世の中には simple で small で fast とされている httpd がいっぱいあるんだなぁ…。
SHTTPD - an embeddable Web server にした。
cc shttpd.c
するだけ動くバイナリができる。まさにシンプル。Windows で動くバイナリがあるのは個人的には関係ないけど、それもまたよし。（同じノウハウが幅広く通用するものが好み。）
これ使って適当なポートで httpd を起こし、user js を置いておきたい場所に document root を設定すればいいわけだ。うむうむ。
2006-10-29 [長年日記]
_ 今さら PHP の気に入らないところ
※ 出ました「今さら」シリーズ。
こういう話はすでにあちこちで挙がってると思うけど、自分の中で最近いちばんでかいのは
変に「名前」や「文字列」を要求するところ
かな。まぁ標準で入ってる callback 処理する関数群なんかが分かりやすいんですが。
callback 関数名って基本的にグローバルな名前空間のものを要求するので、オブジェクトを作りまくってると使いにくい。一応
array( $obj, 'funcname' )
でイケるんだけど*1、こんなところにもわざわざ array() なんて場所を取る記述しなきゃいけないのがイヤ。
create_function も結局変数名が必要だし、中も文字列で書かなきゃダメだし*2、どうも使いやすくないんだよな。JavaScript の function や Ruby のブロックみたいにすっきり書きたい。
なんかこう、変なところでカタイというか、C っぽいというか。元々のツクリの制限がモロに表に出てきてるようなそういう感じ。LL なのにあんまり wrap されてないっていうか、LL らしくない気がする。
※ Lisp 回帰ってのはよく言ったもんだなぁ…
2006-10-30 [長年日記]
2006-10-31 [長年日記]
_ 旧Mac → Windows 逆Switchで気をつけるべきポイント
声高に言われないだけで、実はこの方向で移行している人はかなりの数に上るはず。とりあえず両刀遣いとして今のところ分かっているポイントをここにメモしておこう。
※ 例によって嘘、間違い、過不足はツッコミよろ、ということで。
- OS の操作性の違いは考えないこととする
- それ言っちゃったらキリないし、普通の人は OS ではなくアプリを使っているので、各種設定方法はともかく「作業」を開始するまでならなんとかなる。
- 両方で動いている大型アプリについても気にしない
- Office, Adobe ものなど
では気にするところはどこかというと。
- 絶対にアップデートさせる
- 温室育ちの Mac 使い*1はセキュリティに鈍感なので、かなり気合いを入れて教育する。そのうえで問答無用で自動更新にしちゃう。自動更新の適用で問題が出たら出たとき考える。（抜けない更新で地雷を踏んだら諦める。）
- ファイル名の制限
- Windows の方がファイル名に使えない文字の制限が多い。文字数の制限は緩和されるが、/ とか ? とか不用意に使っている場合はデータの移行ができないので注意が必要。
- メディアのフォーマットの違い
- Mac フォーマットのものは追加のソフトがない限り読めない。Mac では Windows フォーマットを読めるケースがほとんどなので、あとになってあれもこれも読めないと気づくケースが出てきそう。
- Finder と Explorer での挙動の違い
- いちばんびっくりするのは「上書き」と「入れ替え」の違いかな。まぁこれは Finder より Explorer の方がコンピュータ的には自然だし、恐らく少々の戸惑い程度で克服できるだろう。Windows 使いが見落としがちなのは「ラベル」機能かな？ 個人的には一切使ってないけど、バリバリにラベルやアイコンのカスタマイズをしているケースがよくあるので、それに依存してファイルやフォルダの分類を行っている場合、問題になるはず。
- テキストデータの扱い
- 改行コードと機種依存文字の問題。温室育ちの Mac 使いはこの辺に無頓着なので問題が出やすいかも。改行コードについてはアプリ側で吸収あるいは変換できれば問題ないかもしれないけど。
- メールデータの移行
- EUDORA とか Netscape Mail 使ってます、という場合は特に困らない。やっかいなのは Outlook Express を使っている場合。*2
- アプリのインストール／アンインストールの手順の違い
- Windows は Mac みたいに要らなかったら捨ててくれというわけにはいかないので、あまりスキルはないけどいじるのが好き、というタイプには注意。
- 設定方法が煩雑なのでデフォルトの設定が大事
- 多くの場合、Mac よりも Windows の方が設定変更の際の手順が多い。そこであとからユーザーが設定を変更しなければいけなくなるような状況を極力減らしておくことが肝要。
- Mac 独自ツールへの依存度の確認
- AppleScript バリバリ使ってますとか、grep, sed, awk, Perl など Mac 独自の UI がかぶってるものに強く依存してますとか、そういう場合の対処はかなり面倒。逆にこういうのがない場合の移行はそれなりにスムーズにイケるんじゃなかろうか。個人が個人用に作ってた小物ツールは無視。お仕事で使いたいなら認知されるようにしておかないとあとあと苦労するかもしれませんよ、というだけの話だと思う。*3
どれも個人での逆 Switch ではたいして問題にならないが、数が多いとそれなりの問題になるだろうというところ。特にファイル名やメディアの問題は後手に回ると不必要なコストが発生してしまう。
_ ここ？ [http://www.php.net/manual/ja/language.pseudo-types.php#lan..]