あーありがち

過去の日記 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ 今さら MochiKit とか他のライブラリも見てみる

prototype.js しか知らなくて prototype.js すげーって言ってるってことがバレるとちょっとかっこ悪いので*1、他のライブラリも調べてみる。と言ってもまずは先人の記録をトレースするところから。

• Collection & Copy - AJAX/JavaScriptライブラリまとめ (2005/9/6 Revision .1.3)
• Collection & Copy - MochiKit.Iterのサンプルコードを読む
• koyachiの日記 - Mochikit.Asyncのサンプルコードを読む

• Griddle Noise: Prototype.js and Mochikit

MochiKit は examples にある interpreter.js がすごい。（デモムービーで見ることができる。）あと、Logging や Test があらかじめ考えられているところがとても作りやすそう。単純なライブラリではなく環境に近づきつつあるという意味では Rails 的な気もしなくもない。

が、中身は Python にインスパイアされた関数型プログラミングで、ちょっと今の自分には読みにくい。コメントの入れ方など見た目の部分も今の自分は prototype.js の方が美しく感じる。あと茶々になってしまうし十分に多機能なのでしょうがないけど、どこが Lightweight なんだ？と思わなくもない。

名前空間の使い方は MochiKit の方がいいなーと思う。

Rico とか Dojo とかまだちゃんと見てねっす。ぱっと見たところ、ツールキットって言ってるだけあっって Dojo はブラウザ別の処理とか作り込みやすそう。マニュアルが JotSpot 使っててかっこいい*2。

_ jsDrive.pl ってどこにあんだ？

• mozilla/js/tests/jsDriver.pl
• mozilla/js/tests/mklistpage.pl

なんてものがあるんだけど、どこから入手できるんだろう？

jsDrive.pl は Firefox のソースの中にあった。mklistpage.pl はどこだー。

jsDrive.pl 動かしてみたけど Test Suite の作り方が分からないなぁ…。

_ Bloglines を使い始めた

ちょー今さらだけど Bloglines を使い始めてみた。これまでは Sage 一本で、もう Feed 増やしたらやってらんねーなと思っていたので全然増やさないできていた。（せいぜい数十しかないんだけど。）

どうして使い始めてみようと思ったのかまったく思い出せないんだけど、ふと思い出してチェックしてる Feed を Bloglines に登録し始めた。最初絶対 OPML でインポートできるはず、と思っていたのだが見つからず、手作業で登録し終わった段階でリンクを発見したorz

豆粒みたいな文字で切れそうになった。

なんだこれは。たださんは Bloglines に文句垂れてたか？ アンチ豆粒モヒカンはこれ絶対文句垂れてなきゃだめだろ。なんだ body の font-size: 69% って。あほか。Firefox 1.5 の @-moz-document で対応。ぷんすか。とりあえずこんな感じ。

@-moz-document domain( bloglines.com ) { 
  body {
    font-size: 100% !important;
  }
  body#subscriptions {
    font-size: 80% !important;
  }
}

なんか記事タイトルとかバランスが悪いが、細かいことはまた今度考えよう。

正直、「これそんなにいいのか？」というのが感想。ただ、

• JavaScript バリバリの subscriptions の編集
• フォルダ単位で一本のフィードにして読める

のは嬉しい。あと、

• どこでも同じ状態でチェックできるのが楽

だなと思った。クライアントサイドのリーダーだと使うクライアントごとにインストールしないといけないし、チェックの状況も二重管理になっちゃうので。記事保存機能なんかも便利そう。

アカウントは10ヶ月前に取得していた…。面倒くさくて試してないサービス、まだまだあるなぁ。

_ Bloglines の font-size を調整しまくり

やっと使いやすくなった。OSX での見た目しか考えてないので特に margin の辺りは逆効果の可能性もあり。

しかし、長いこと Sage で見てたから、本文のサイズは 100% じゃない方が一覧性が高くていいかもとか思い始めている自分がいる…。いやいや！ 本文は 100% が基本だよ！ と言い聞かせる。

あ。注釈が必要ですな。以下のユーザーCSS は Bloglines 上で全文を読むことを前提に組んだものです。それ以外の使い方をしている場合には適さないと思います。

@-moz-document domain( bloglines.com ) { 
  body#subscriptions {
    font-size: 80% !important;
  }
  body {
    font-size: 100% !important;
  }
  pre {
    overflow-x: scroll !important;
  }
  div.logbar {
    font-size: 90% !important;
  }
  .searchbar {
    font-size: 85% !important;
  }
  .tabs {
    margin-top: .5em !important;
  }
  div.channel_nav {
    font-size: 90% !important;
  }
  .channel h1 {
    font-size: 130% !important;
  }
  .channel h2 { 
    font-size: 110% !important;
  }
  .header_nav {
    font-size: 90% !important;
  }
  .content-main h3 {
    font-size: 120% !important;
  }
  p.author {
    font-size: 75% !important;
  }
  div.item_nav {
    font-size: 85% !important;
  }
  div.shortcuts {
    font-size: 90% !important;
  }
  div.homefooter {
    font-size: 80% !important;
  }
}

tiddlywiki とか試した影響かな、本文の投稿日時や更新日時の情報はマウスオーバーでうにょっと出てきた方が邪魔にならなくていいかなと感じる。

_ 今日は del.icio.us 始めました

うわーめっちゃ便利やわ（誰）

これも以前から使ったら便利じゃないかなぁと思いつつ放置していたものなんだけど、びっくりするくらい便利。シンプルでよさそうだなぁと以前から思っていた通り、使いやすい。タグの入力は、すでに誰かがタグ付けしてたら recommended や popular にリストアップされるのでそれをクリックするだけで済む。何も出てこないときはまっさらな大地を開拓していくような快感がある。

思ったより軽いのはたまたま調子がいいのか？*1

いつまで続くか分からないけど、登録も編集も削除も少ない手間で行えるようにいろいろ工夫されていて気持ちがいいので、意外と続くかも。

_ wiki-study ML に参加できない

なーんでだろ。quick ML を初めて使うから何か勘違いしてるんだろうけど。Cc は

http://qwik.jp/wiki-study/FrontPage.html

に書いてある通りに書かないといけないのかな？

_ そうそう。JavaScript の配列は扱いにくいんですよ。

JavaScript の暗黒面を覗く

というか Hash として活用しようとすると途端に扱いにくくなるって感じかな。確かに中身はハッシュテーブルかもしれないけど、Hash としては扱いにくい。けっきょく全部 for ( in ) でなめます、みたいな感じで書かざるを得ない。ださい。length プロパティもそうだけど他にもいくつかメソッドが期待したようには動作しない。少なくとも Firefox では。

で、どうせなら has_value() とか keys() とかほしいなと思ったので、自分は試しに Hash オブジェクトを作ってみた。すると JavaScript のオブジェクト周りの扱いにくさというかクセがよく分かる。

Object はプロパティの集合体でありハッシュテーブルなので、Object を作ってそこに obj[key] = val って放り込んでいくだけで Hash でござい、と言えてしまう。でも前述のように便利メソッドがないので Function を使ってオブジェクトを作って、そこにメソッドを足してみる。するとメソッドも変数と同じなので for ( in ) したときにそのまま列挙されてしまう*1。そうか、じゃあ列挙するのはもうみんな中のメソッドでやることにして、if ( typeof key != 'function' ) とかやればいいんだ、と思って調子に乗ってメソッドを作って行く。するとハッシュキーに使える名前がどんどん減っていく*2。それも困る。

そこでオレHash はこういう作りにしてみた。

var Hash = new funtcion() {
  return function() {
    this.obj = {};
  }
}
Hash.prototype = {
  method: function() {
  },
  ...
}

つまり実際のデータは hash.obj の中に詰め込んでいく。こうするとメソッドとデータの key で名前がぶつかることはない。しかしこの方法だと hash[key] = val とか for ( in ) とか普通の構文が一切使えなくなる。そこでずいぶん悩んだが、「ええいそんなもん禁止だ！」と開き直って Ruby からアイディアを拝借して fetch() とか store() とか merge() とかバンバン作っていく。そうするとなんとかそれっぽく使える状態になる。

ハッシュの中に Array を作るときは

hash.store( key, [] );
hash.fetch( key ).push( val );

てな感じ。まぁ正直これもどうだって感じではあるけど、練習にはいい題材だったと思う。

_ Trac の文字化けが解消した日

svn propset だけじゃなくて svn commit しなきゃダメだったのねぇ〜。考えたらそりゃそうか。すでに諦めていたのにあるとき突然文字化けしなくなって

Property svn:mime-type set to text/plain;charset=Shift_JIS

って出てて、かなり目を疑ってしまった。ごめんよ Trac もう一週間ずっとぶーたれてたよ、お前に。でも間違いだったんだなぁ。気づけてよかったよ。

なんで気づいたのかっつーと、ソースの中から Wiki にリンク張れないかなと思って試していたから。それはさすがにできなかった。まぁそんなこと許したらうっかり CamelCase の名前使えんくなるもんな。リンクだらけになって鼻血出そうになるわな。

_ wiki-study ML で恥ずかしいことに

• 登録のメールでは Cc は指示通りに書かないとだめ
  • 「こんな感じ」という適当な日本語に騙されてはいけない。
  • 2回も失敗したあげく、登録メールの Subject が「これでうまくいくかな？」だよ。なんだそれ。かっこ悪すぎる。
• いきなり Wiki 記法が有効
  • qwikweb の常識なのかもしれないけど、すげーびびった。
  • 個人的にはメールは字下げして書いてるんでかなりおかしなことになってしまう。普通に整形したメールはもう送れないってことですな。

qwikweb の注意事項をもっと強調しといてほしい。qwikweb ってチョー便利なはずって信じてたけど、注意しないといけないなぁ。

ま、なんにしても登録できてよかったけど。

あれ。Web が反映されてずいぶん経つけどメールこないな。

_ Bloglines のフォント設定…

誰もつっこんでくれないので気づかなかったが、オプションに文字サイズの設定あるやんけ。

でももう手遅れ。我が道を貫くことにした。

つかデフォルトの設定をもっと考えろ。ちくしょうっ…。

_ CNET Japan の幅が広がってうっとうしくなったな

つーか Feed でチェックだけしといた記事の本文が飛んでなくなってるし…。トラックバックは見えるけど本文が見えないっていういやんな状態になってる。

つか障害の原因てまだ調査中なんだ。そら大変だ。とりあえずこっちはこの使いにくいデザインへの対策を考えよう。ってことで。

_ 今さら Trac の感想

※ もうこの「今さら〜」というタイトルの付け方がマンネリだなぁ。

さて、頭の回転の速い Subversion 使いのみなさんにはもうすっかりお馴染みの Trac だが、わたしゃどうも道具を使いこなすまでが遅くてなかなかついていけない。しかしえっちらおっちら試してきた過程で思いついたことは一応書き留めてある。これから Trac を試してみようとか、ちょっと試したけどなんか思ったように動かんかった、という人に少しは役に立つかもしれないのでこのメモの抜粋を公開しようと思う。嘘、不足はツッコミよろ。

なお、以下のメモは FreeBSD 上で Trac 0.9.3 を動かしたときのものである。

まず Trac って何？

Subversion リポジトリブラウザ & Wiki & BTS（Bug Tracking System） の統合ツール。trac ロゴには Integrated SCM & Project Management って書いてあるように、Web ベースのプロジェクト管理ツール、という位置づけでそんなに外れてないと思う。（進捗管理とかできないけど）

Trac を動かすには何が必要？

• Webサーバ*1
• Python
• SQL系のDBMS（SQLite でも動くのでそんなに難しくない）
• Subversion

CGI, FastCGI, mod_python で動く。らしいけど、自分で確認したのは CGI と FastCGI のみ。

Windows でも Linux でも MacOSX でも動かせそう。個人的には FreeBSD でしか試してないけど、Windows なら All-In-One-Trac というものもあるので、必要なものが少なくない割には導入は楽になってきているんじゃないかと思う。

どういう人が使うと嬉しい？

Subversion を使って何らかのデータの管理を行っている人。cvs の場合は cvstrac という C で書かれたツールがあるようだが、試してないのでどんなもんかは知らない。

何ができない？

qwikWeb みたいにメールで Wiki の更新とかできないはず。ただし BTS(Ticket) の変更をメールで通知する機能はある。ViewCVS と違って特定のディレクトリ以下の tarball を download する機能はない。

インストール記事は書きません

頑張ってくれ。

セットアップするときの注意点

必ず svn リポジトリが一つは create されてること。

[2006-09-14 追記]svn リポジトリを cvs2svn で作成した場合、どうもデフォルトでは svn:eol-style=native という属性が付加されるっぽい。こうすると例えば Windows と Linux が混在している環境では「リポジトリ上では同じだが、手元でいじっているファイルの改行コードは違う」という現象が起きる。で、この working copy のファイルを利用して何かをしようとすると改行コードの違いが思わぬ副作用をもたらす可能性があるので注意。

deploy ツールを用意しろってことかなぁ。

重いので fastcgi か mod_python がオススメ

最初 CGI で動かしたんだけど、自宅サーバではびっくりするほど重かったので、fastcgi か mod_python がオススメ。マシンパワーが余っているか、気の長い人なら CGI でも大丈夫だと思う。

あと、Apache 2 用の fastcgi のセットアップのドキュメントで

<IfModule mod_fastcgi.c>
  FastCgiIpcDir /var/run/fastcgi
  FastCgiConfig -initial-env TRAC_ENV /var/lib/trac/HOGE
</IfModule>

みたいに書いてある場合もあるんだけど、fastcgi で TRAC_ENV を設定する場合は = で結んでおかないといけないので、上のままでは動かない。

<IfModule mod_fastcgi.c>
  FastCgiIpcDir /var/run/fastcgi
  FastCgiConfig -initial-env TRAC_ENV=/var/lib/trac/HOGE
</IfModule>

にする。（個人的には fastcgi の設定は lighttpd の方が楽だと思う。）

mod_python は自分では試してねっす。fastcgi は落ちたときに自動的に再起動してくれるとか便利な機能があるので楽ちんだと思うんだな。

マルチバイト文字（含む日本語）の問題

基本的には UTF-8 で扱うので日本語についても問題なく使える。UTF-8 に対応しているブラウザで編集すれば Wiki についてはなんら問題ない。trac-ja が提供されているが、これは基本的に UI やマニュアルの日本語訳であって、日本語の処理に問題があるためではない。*2

問題は Subversion で管理するテキストファイルのエンコーディングが UTF-8 じゃない場合。これの解決方法は二つある。*3

1. プロジェクト全体のエンコーディングを trac.ini の default_charset に指定する
2. 個々のファイルについて svn の機能でエンコーディングを指定する

svn propset svn:mime-type "text/plain;charset=ENCODING" filename

基本的には 1 の方法だけで問題ないはず。というのもこういうツールを使う人はもともとプロの開発者とかその手の人が大半なので、ある単位のファイル群のエンコーディングがバラついていることはまずあり得ないから。

ただしこれが個人的なファイルをとにかく突っ込んでいる場合や Web サイトのファイルを管理したいという場合はこの限りではないと思う。特に Web の場合、サーバサイドスクリプトでは内部エンコーディングとブラウザとの入出力に使うエンコーディングが違う、それに伴って CSS やクライアントサイドスクリプトのエンコーディングが違う、ということはよくある。

この場合は地味に svn propset & svn commit していくしかない。サブディレクトリが見つかると*4そこで svn propset は「止まる」ので、あまりたくさんのファイルに対して設定するのはしんどい。もうその場合はプロジェクトを分けちゃうのが正解だと思う。*5あるいはコード中にはもうマルチバイト文字は書かない。そう思った理由は以下のリンクに関する記述を参照されたし。

あ、そうそうまだ試してない（まだ試し始めてから ascii の comment しか書いていない）けど commit log も UTF-8 で書かないといけないと思う。

[2006-08-02 追記]subversion 1.1 以降で gettext がリンクされていて locale がちゃんと設定されていれば、svn コマンドは locale を解釈したうえで UTF-8 に変換して commit する模様。どこかで拾った OSX 用 SVN バイナリは locale を解釈しなかったので Fink 版に変えた。

ツールを横断するリンクが便利

Wiki と BTS とリポジトリが一つのツールで扱えてとても便利だなと思うのは、それぞれを簡単にリンクさせられる点。Wiki からソースブラウザ、commit log から BTS へ簡単にリンクが張れる。これはかなり便利に使える。

ということは添付ファイルやめて svn で管理しちゃえばいいじゃん

最近の Wiki では添付ファイルの機能はそれほど珍しくない。Trac でもページに対してファイルを添付して、それをページから参照することができる。ただしこの添付ファイルはほんとにただ添付できるだけ。svn も Trac も履歴管理がバッチリできるのに添付ファイルは蚊帳の外なのであまり嬉しくないのだ。

そこで上のリンク機能。添付したいファイルを svn リポジトリに突っ込んで、Wiki からそこにリンクしてしまえばよい。画像の場合はこれに Image マクロを組み合わせるとそのままページ内に表示できる。具体的にはこんな感じ

[[Image(source:foo/bar.png)]]

で Wiki に書けばよい。なんて便利。これで Wiki のテキストも画像も全部履歴管理できるという塩梅だ。

svn リポジトリに dav アクセスできれば全部 HTTP で済むし、ファイルを編集してブラウザから添付し直して…なんて面倒な操作をしなくて済むのがすごく嬉しい。

認証は単なる BASIC 認証

インストール直後、Web サーバの認証を設定していない状態で login のリンクを辿るとエラーが出る。なんじゃこれと思ったが、

svn の dav アクセス用のユーザーDB をそのまま利用すればいいじゃん

という方針らしい。なんとスバラシイ発想。ま、逆に言えば dav アクセスを許可するつもりがなかった場合はあんまり嬉しくないんだけど。

認証を経ないと使えない機能があるのかどうかはよく知らない*6。まだそこまで使い込んでないんで。編集時のユーザー名はその場で記入できるので、普通に Wiki を編集するためには認証は必要ない。ただ login していると Wiki の編集時に自分の名前を記憶しておいてくれるので、その辺は楽。BASIC 認証の設定を済ませたら、せっかくだから dav アクセスも許可しちゃおうかとか思ってきちゃうから不思議だ。（lighttpd を使っている場合は違うか。）

いろんな RSS が取れて便利

CVS で管理しているプロジェクトでコミットの様子を RSS で吐かせようと思うと一工夫いる。しかし Trac では本当に様々な情報について RSS が提供されている。特定のファイルの更新を監視するなど、楽勝でできてしまう。これはいい。

今のところのまとめ

現在は ViewCVS + PukiWiki で似たようなことをやってはいるが、Subversion の CVS に対するアドバンテージ、ツールが統合されていることによる利便性がとても気持ちよい環境である。

一方 Wiki 単体ではプラグインの豊富さや日記形式の記入が楽に行えるなど、PukiWiki のアドバンテージももちろんあるので、全面移行というのはまだちょっと難しいように思う。逆に今までそういう環境を構築していない場合はとりあえず使っとけと言って間違いないと思う。多少セットアップが面倒でもお釣りはくるはず。

あ。ViewCVS と違って tarball のダウンロードできないなぁ。まぁ要らないか。要らない要らない。要らないってことにする。

_ そうかスクロールバーか

全文配信の議論そのものには全然興味ないんだけど、

ekken♂：「RSSには要約文しか載せたく無い」のではなくて……

今現在利用しているFC2ブログだと、RSSで配信する部分は「続きを読む」よりも以前の部分みたいです。「続きを読む」を使わなければ、エントリの全文を配信するようですね。ブログのデザインの問題で、意見が分かれやすいのが「続きを読む」の有無でして、コレ、嫌いな人は徹底的に嫌いみたいですが、個人的には長文が多いブログにおいては、あったほうが読みやすいと考えます。１ページに表示させているエントリ数が多い場合、「続きを読む」を使わなければ、スクロールバーがつかみにくいのが嫌なのです。

忘れてた。みんなホイール使ってるんじゃないの？

自分はスクロールバーのつまむ部分じゃないところをクリックするか、▼をクリックするか、RoolUp, RollDown を押す（PowerBook だと fn + page ▲▼）か、いちばん多いのは「スペースを押す」っていう行為なので、長文が表示されているときのスクロールバーっていうのは「おーどんどん長文読み込んでる、うわーどんどんスクロールバーのつまみが小っさくなってる。すっげー、超ちっせぇ。」くらいにしか思ってなかった。

でもなんとなく、「これくらいのスクロールバーのサイズが画面全体の中のウィンドウデザインとしてかっこいい」というのは自分の中にあるなぁ。そう思うと、スクロールバーのデザインて大事かもしれない。

_ 風邪引いた

今年というか今シーズンというか、なんだかよく風邪を引く気がする。一応うがい手洗いは欠かしていないし、割とまともなものを食べているような気はするんだけどなぁ。満足に動かなくなった加湿器についてもう少し真面目に対策を考えた方がいいだろうか。

でも安くて小さくてそこそこ動くものって、実は案外ないんだよな。

_ 古典的な感じがするがメモ魔って大事

• 取りまとめは誰がするのかはっきりしない
• 取りまとめるはずの人が記憶頼みタイプでかつ短期記憶力がない

のは不幸だなと思った。せめてお互いにメモを取ってくれてりゃいいんだが、絡む人が誰もメモを取らないタイプってのは見事すぎやしないか。

だいたいどうして自分の記憶力に自信を持てるのかなぁ。それがもうさっぱり分からないんだけど。特定個人の話じゃなくて、自分の記憶力なんてまったく信用ならないと思うんだけどね。

_ メッセージカタログの取り扱い

なんべんやってもコメントがつけられないので頭にきてこっちに書き出しておく。

PHPでメッセージカタログはgettextしかありえないでしょ - よくきたblog

この前の日に PHPでメッセージカタログはgettextしかありえないでしょ というエントリがあって、そのリンク先で Pure PHP の gexttext がいちばん遅いという記述になっているんだけど、この Pear のものは Pure PHP じゃないのかな？ 中見りゃいいんだけど聞いた方が早いので聞くつもりだったのに聞けないもんだからどうしよう。

_ Thunderbird 1.5.0.2 も出る

Firefox を Firefox 自身の更新通知機能で初めてアップデートした今日この頃。

• mozillaZine 日本語版 >> Blog Archive >> セキュリティ＆安定性が改善された Firefox がリリースされた
• yohgaki's blog - Firefox, Thunderbird, SeaMonkyは直ぐにアップグレードが必要
• US-CERT Technical Cyber Security Alert TA06-107A -- Mozilla Products Contain Multiple Vulnerabilities

Thunderbird は is to be released ということになっているので直に出るんでしょう。確認した時点では Firefox 1.0.8 と Thunderbird の 1.5.0.2 の日本語版はミラーには届いてない模様。

「じきに」なんてのは絶対に忘れるので先日開発した簡易タイマーをセットする。何？ 簡易タイマーには何を使っているのかって？ よろしい、そんなに聞きたいか。オープンソースの時代だものな。わっはっは。公開してやろう。

0 14  *  *  *  open -a /Applications/Stickies.app/Contents/MacOS/Stickies

cron でスティッキーズを立ち上げるだけ :-P 普段スティッキーズ使ってるとこの手は使えないけどね。自分の場合はメモは Wiki + QuickNote（Firefox Extension）なのでスティッキーズは遊んでいたのだ。Windows のタスクスケジューラと違って crontab -e って打ってコメントアウトしておいたスティッキーズの起動設定を日時調整して有効にするだけ。楽ちん。（Terminal は常に起きているっていう前提が必要だけど。）

_ そうか、あとで検索か

あとで読まずに検索 - jarp,

「あとで読む」ってそんなにいいかなぁ、Bloglines なんかでも Keep New ってあるし、それでいいんじゃないの？ と思っていたけど、あとでまとめて自分用のデータから検索できるのはいいな。もともと検索目的でソーシャルブックマークが使えるだろうと思って使い始めて、クリップするものには必ず自分に役に立ちそうなコメントを書き込んでいるんだけど、そういうの細かく気にしなくても検索できるようになるのは便利だ。要らなきゃ消せばいいんだし。でもそうなると全文が入ってないとあまり意味がないなぁ。すべての記事で Feed に全文が入っていてこそ、という感じがする。

まぁ使ってみるか。

ところで livedoor Reader も使っているところを脇で見た感じはとてもサクサク使えて気持ちよさげ。そうかこれが最速の人の仕事か。すげぇな。livedoor ID を作る段階で躊躇しちゃうのが難点だけど。*1

_ メールを RSS みたいに読めないかなぁ

全文でも要約でもいいけど、subject と本文でペインを分けずに一連でだらだらっと表示されるもの。「操作」ができるだけ少ないものがいい。Gmail とかメルマガとか特定のサービスではなく、自分にくるメールを RSS リーダーで読む。まぁごにょごにょごにょごにょと組み合わせてやればできそうなんだけどもー。

なんか楽できんかな。（テンション降下中。）

あと認証が必要で RSS を配信してないサイトのチェックをどうにか楽にできないかしら。

あぁ。

もーしーかーしーてー。Plagger ? に合わせたデータ投げればいいのかな？

[2006-07-17 追記]

phpspot開発日誌 経由 PHP Classes - Class: POP/IMAP to RSS なんてものが登場したらしい。

_ 荷解き

引っ越し続きでまったく荷物を紐解かずにあっちからこっちへ運んでいただけの時期があったので、うちには中身を何年も見ていない段ボール箱がいくつもある。

久しぶりにスピッツを聞こうと思ってこれをひっくり返したら中島みゆきのアルバムが10枚も出てきた。

いやーおれほんとに中島みゆき好きだったんだな。

……。ThinkPad 530 が出てきた。

_ iCal 形式のデータって意外と公開されている？

Google Calendar を試してみた。操作性は確かにすごいんだけど、すでに意外といろんなカレンダーを見ることができるのも驚き。見ると iCalendar 形式（RFC 2445）のデータをインポートできるみたい。

ということはあれか。もうすでにあちこちに iCal 形式のデータがあるってこと？ あー OutLook も対応しているのか。そうか、それなら納得。iCalendar のデータの生成・加工って、iCal や Sunbird が重たくてやる気にならなかったけど、Google Calendar の軽さならいいかもしれない。

_ プログラミング言語を学んで、さて何を書く？

rubyco の日記のコメントに注目。難しい質問だな、これ。

まずこの人は言語そのものが初めてということなので、その言語のサンプルを片っ端から打ちこんで*1動かすというだけでもよいような気がする。言語そのものが初めての場合、その言語では何を実現するのがどれくらい大変か、あるいはどれくらい簡単かなんて辺りがさっぱり分からないだろうから、「作りたいものを作れば？」と言っても背伸びしすぎてとんでもないものを作り始めて挫折しちゃうかもしれない。

あるいは言語そのものが初めてということは当然アルゴリズムも学んだことがないだろう*2ということで、基礎的なアルゴリズムを学べる本（別にサイトでもなんでもいいけど）に手を出すというのもありだろう。個人的には簡単なゲームを題材にしたものがあればアルゴリズムの学習にいいと思っているので、そういうのが見つかればベスト。

ある程度慣れているんならその人のやり方（例えば rubyco さんはいきなりリファレンスを参照する方法を調べている）でやればいいんだけど、初めての場合はその初めての言語を学ぶ環境にもよるし、漠然としたままだと考えにくいなぁ。

_ ajax は組み込み向けかも

いやふと思いついたんだけど。

クライアントサイドの処理に期待して HTML に整形しないでデータ投げ返せるし、転送量も減らせそうだから負荷が減るんじゃないか的な話があるじゃないですか。あれに期待して HDD レコーダなんかの組み込みの Web インターフェイスは ajax にしていったらいいかも。

と思ったのは RD の Web インターフェイスの反応にいつもちょっとイライラするからなんだけど。まだ実際に番組登録とかの処理に入ってないんだからもっとサクサク返してきてよーと思うわけ。あとすでになんかブラウザの機能で戻るなとかそういう制限が加わってるので ajax になってもその辺は今と同じだし。

ただもっと十分に枯れないと危険かな。一度リリースしたらなかなかデバッグできないもんな。アップデートの強制適用とかできるんなら話は別だろうけど。

_ Web ページを手のひらツールでスクロールさせたい

主に横スクロールが発生したときに思うんだけど、スクロールバーにマウスカーソル合わせるのも邪魔くさいし、カーソルキーを使うのも鬱陶しい。

そんなとき手のひらツールでガッと横スクロールできたらステキ。

もしかして Greasemonkey ?

[04-28 追記]Scrollbar Anywhere を教えていただいた。早速使っているんだけど、気づいた点を少し。（いずれもバージョン 0.8 の段階の話。）

• デフォルトではドラッグの際にマウスカーソルも変わらないし、スクロールバーというだけあって、マウスを動かした方向と反対に動く。これらはいずれも設定で変更可能。
• 通常の onmousedown で動作が始まるので、例えば右クリックに割り当ててしまうとコンテクストメニューが全然使えなくなる。
• だからと言って左クリックに割り当てると、こうして textarea 内で編集しているときにもドラッグして選択とかするときにスクロールしまくって困る。
• 中クリック…って、PowerBook のパッドでどうやって使うんだろ？
• マウスカーソルの動きとスクロールが合わない。
  • あくまでマウスの動きと連動するのは目に見えないスクロールバーであってウィンドウ内のオブジェクトではないってことかな？

キーコンビネーションがあればだいたい文句ないレベルなんだけどなぁー。便利だから使うけど、左クリックにそのまま割り当てちゃってるので、簡単に off にするボタンか何かあるともっとよさげ。

[2007-07-10 追記] Grab and Drag :: Firefox Add-ons なんてものも。

_ JSDoc で prototype.js が…読みやすくならなかった

prototype.js をもう少し読もうと思って、とりあえずクラスとかちゃちゃっと分類して読みやすくならんかなと思って JSDoc に掛けてみた。

漏れまくり。

まぁ javadoc 形式のコメントなんか一切ないんだけどさ。それにしてもコードの概観を眺めるくらいには使えるんじゃないかと思ったわけですよ。

うーん。src/ ディレクトリで一つずつ読むしかないのか。

_ 酔っぱらった

昨日、酔っぱらって帰ったらうちの前に酔っぱらいが寝ていた。

同じマンションに住んでるのは知ってたので、肩を貸してうちを探して回った。

今朝お礼にお菓子もらった。

Amazon から『RailsによるアジャイルWebアプリケーション開発』が届いた。ぱらぱらと眺めた。

今日はだらだらと寝て過ごした。

平和ってすてき。

※ 結城さんの日常とのこのギャップはなんだろうとか悩んじゃいけない。

_ ふと MacPerl

MacPerl は System 7.0 から動く Classic Mac 用の Perl. Mac らしい UI がついている。OSX で動いているのは普通の Perl.

• The MacPerl Pages
• SourceForge.net: MacPerl
• MacJPerl五

5.6 のバージョンが出てる。5.8 は alpha が出て止まってる。まぁいずれにしても 2002年に止まったと見ていいのかな。JPerl は 5.2.（5.004ベース？）

実際に使おうという気はないんだけど、とりあえず見てみた。