2004-01-04
_ HtmlImage クラスも作っちゃった
とりあえず画像の width, height が自動に入る、何も指定しなければ alt="" が補完される程度のものだけど、img もクラス化した。これで画像を途中で変更してもソースの方は修正が必要ない。また、JavaSctipt を利用した PNG の処理を plugin に渡すコードも動的に入れられる。（まだ作ってないけどさ。）うんうん。よい感じだ。
_ 最近分かったこと
- 鳩丸倶楽部のドキュメントが一括ダウンロードできるようになっていた。しかも、本番サイトのようにバナーも入っていないので非常に扱いやすい。
- Namazu は utf-8 のファイルをまともにインデックス化できない。できても日本語で検索できないので無意味。
- Namazu for Win32 は ActivePerl 5.8.x では動かない。5.6.x に決め打ちしている処理がある。
- とほほのWWW入門は逆にバナー入り。お手軽リファレンスとして使いでのあるとほほのリファレンスでは逆にダウンロードデータにバナーがしっかり入っている。スクリプトで全部カットしたが、少々面倒だ。
_ Project Dolphin に移行
Project 中止後すぐに Orca が始まったが、実際には数週間で Dolphin は復活していた。その後 Dolphin 復活の記事はスラドに載らなかったのでまったく注意することなく「なんかちょっと参加者少ない気がするなぁ」と思ったりもしたが、Orca に夢中だった 2003年前半。
後半に Dolphin 復活の話を聞いてあまりの悔しさに「今年はもう Orca でいく」と心に決めていたのだが、昨日ようやく Dolphin 用の Pulse クライアントに入れ替えた。今年は3万位くらいの順位からどこまで上がれるか。ずばり上狙っちゃうよ。
2007-01-04
_ Diigolet が使えないと困る
Camino なので bookmarklet である Diigolet で post してるのですが、以下のケースでは Diigolet がまともに動きません。
- frame のページ
- text/plain のページ
このリストを見て、DOM で HTML 文書全体を相手にあれこれやってみたことのある人は気づいたかと思いますが、文書の中に body 要素がないためにこうした問題が起きます*1。text/plain の場合はちょっとどうしようもないですが、frame についてはちゃんと考えれば対応可能です。もうちょっと頑張ってほしかったなぁ。
あと、bookmarklet などで post できなかったとき、Diigo のサイト上で bookmark を追加することになるのですが、この操作性がすこぶる悪い。というかどこから追加できるのかぱっと見分からない。あれだなぁ、こういうケースを体験するとユーザビリティって大事だなと思いますな。まぁごく単純な HTML の使い方の問題でしかないんだけど。
※ Diigo は本来もっと目立つべきアクションが select の中に埋もれていたり、form の ボタンを CSS で通常のリンクのように見せかけているために Safari や Camino でものすごく間抜けに見えたり、ちょっと検証不足じゃねーの？と思わせるところがちょこちょこある。今さらながら del.icio.us はよくできてる。
*1 body要素の中にレイヤーを作って overlay させているので。
2009-01-04
_ カバン買った
10年振り？11年振り？12年振り？に自分用のカバンを買った。いわゆる出張用のカバン。これでちょっとした小旅行的なものもだいぶ楽になるな。一応 MSI の U100 の環境もそれなりに揃ってきたし、e-mobile もあるし。
_ Meadow に苦戦
自分だけ向けメモ。設定が効いてんだか効いてないんだかよく分からない。
- 結局なんやねん！ Meadowが.emacsを読みに行く場所
- $HOME がない場合は NTEmacs では Application Data/.emacs みたい
- Meadow / UTF-8によるコピー＆ペースト
- Mac ではシステム標準のコマンド体系が ctrl では command に割り当てられているため、別にクリップボード同期できなくても困らないんだけど
install.exe は実行しなくちゃいけないっぽい。でないと autoloads とか便利な機能がちゃんと動かないっぽい。
Windows しかないときにもそれなりに作業できるようになるためにはやっぱ Meadow 必要だよなーたぶん。
2010-01-04
_ xig_installer なんてものを書いてみた
まとめ
- twitter を IRC に変換して使いたい
- tig.rb を使いたいけどどこからどう入れたらいいかよく分からない
- なんか tig.rb をもっとうまく扱いたい
人向けのツールを作ったよ。
まずはなんでこんなものを作ったのか、理由から。
~/bin になんでも突っ込むのをやめたい
現在自分の twitter 環境は
自宅サーバ上の(tiarra + TwitterIRCGateway) + クライアントPCの LimeChat
という構成になっているんだけど、実はサーバ上のプログラムは
すべて ~/bin 以下に放り込まれている状態
になっている。とりあえず動かし始めるときにはこういうのよくやるんだけど、一昨年末(!)から始めたホームディレクトリの整理の一環で、~/bin 以下も基本的に全利用ホスト共通にしたいと考えている。当然、いちばんのネックは
サーバ用の ~/bin の内容をクライアントに持ってきたくない
というところ。
gem の奥底の実行ファイルを呼ぶのがなんかイヤ
すでに書いたけど twitter への大半のアクセスに TwitterIRCGateway を使っている。ただ実はずいぶん前からこれの Ruby 派生版である tig.rb に乗り換えようとしている。
TwitterIRCGateway は自分にとって Twitter を気軽にかつディープに利用するようになるうえで絶対に外すことのできないプロダクトで、とても感謝している。
だけれど、やはりどうも FreeBSD + Mono という環境のせいなのか、
- よく分からない落ち方をする
- 稀に無限死亡モード（起こしても起こしてもすぐ死ぬ）に入る
- dll の入れ替えを手動で行うアップデート方法がなんかイヤ
などの細かい不満があった。一言で言うと
どうも管理しにくい
ということである。そこで Ruby だけで動くし、gem で install できる net-irc に付属している tig.rb に乗り換えようかということなんだが、
肝心の tig.rb は gem でインストールした examples/ 以下で、gem の深い階層の下の方のファイルを呼び出すのはなんかダサイし扱いにくい*1
ということで、net-irc 以下の examples/ 以下にある *ig.rb の実行ファイル、つまり何かと IRC の Gateway として機能する実行ファイルを PATH の通ったところに install してしまうツールを用意することにした。
前置きが長くなったけど、そんなわけで xig_installer というツールを書いた。
紹介
wtnabe's xig_installer at master - GitHub
と
xig_installer | gemcutter | awesome gem hosting
に置いてある。
ぶっちゃけると実にくだらないツールで、gem の奥底にある *ig.rb の一覧を作り、それを gem を実行している Ruby 本体と同じパスに対して install, upgrade, uninstall するだけ。小判鮫すぎるうえにたいしたことはしてない。
でもこれだけで実行時には普通に PATH の通っているところにある tig.rb を叩けばよくなる。これが嬉しい。
使い方は簡単。
- Rubyをインストール
- Rubygems をインストール
- gem install gemcutter
- gem install xig_installer
これで net-irc も依存関係でインストールされるので、あとは
(rehash) xig_installer install tig.rb
とすると Ruby を置いてあるパスに tig.rb がコピーされる。Ruby のインストールに管理者権限が必要なら
sudo xig_installer install tig.rb
にする必要がある。
その他の機能は
xig_install help
で確認してほしい。
tig.rb の使い方はとりあえず割愛ということでごめんなさい。
*1 gem バージョンじゃなくて git clone したものを使うでしょ、という指摘はとりあえず置いておく。
2012-01-04
_ ActiveSupport::JSONは自動でunicode escape sequenceにしてくれる
以前、JSON gemが1.4系でescapeしなくなったじゃん、ひどい！ みたいなことを言ったことがあって、その後 Rails を使うようになって、なんか JSON 出力したときに unicode escape sequence になってるような気がするなー、なんでだろー、JSON gem のポリシーがまた変わったのかなーとか思ってたけど、違った。
よく見たら Rails は JSON gem じゃなくて ActiveSupport の JSON ライブラリを使っていた。
ほーなるほどな。ということは ActiveSupport を使ってるんだったらこっちの JSON にした方がより安全な JSON を吐けるということか。
今度から Rails 使わないときも JavaScript に渡す JSON を作るときには ActiveSupport::JSON を使うようにしようかな。遅いかもしれないけど、その方が安心だし。
実はちょっと意地になってやってやろうと思って、ぐぐったら json/pure になんかあるっていうんで、json/pure の JSON.utf8_to_json_ascii っていうやつを試してみようと思ったらこれが String しか受け付けなくて、なんだそれと思って to_json した結果をこいつに渡せばいいのかと思ったら encode 壊れて decode できませんと言われて、なんだよそれ！って思った直後に Rails どうしてるんだろう、と読んだら解決したっつー話でした。
最初から Rails 読めばいいんだよ。