▼ 2007年05月の記事一覧
Greasemonkey がページの描画にどのくらい影響を及ぼしているかをなんとなく知る方法 / redMine で trac の trac-post-commit-hook のような事をやる / livedoorReader の未読数を munin でグラフ化する / ウェブユーザビリティの法則は読んでおくべき /
« 2007年04月 | 過去ログ一覧 | 2007年06月 »
ユーザスクリプトを入れまくるとページの表示が遅くなるのは周知の事実ですが、実際どの程度の影響が出ているかを調べてみたくなりました。ユーザスクリプトはいわゆる一つの「DOMContentLoaded」のタイミングで実行されるので、HTML 開始時の秒数と onload 時の秒数の差分でも取ればなんとなくそれっぽいデータが手軽に取れるんじゃないかと思って、次のような HTML ファイルを作ってそのページを表示させる事にしました。超適当。
<html> <head> <script type="text/javascript"> var t = new Date; window.onload = function() { document.getElementById('result').innerHTML = ( new Date - t ); } </script> </head> <body> <div id="result"> - </div> </body> </html>
グリモンがオンの時とオフの時で、大体300ミリ秒くらいの差が出ました。いらないスクリプトは入れていないので、こんなのがわかった所でどうしようもないですけどね。でも実際に数値として出す事で、改めて無駄なものは入れないように気を付けようと思ってきたから、役には立ったのかも。
△トップ | コメント (0) | トラックバック(0)
と言っても特殊な事は必要なくて、svn リポジトリのリビジョン473から使えるようになっているので、更新するだけで使えるようになります。
trac-post-commit-hook が何者か知らない人のために説明しておくと、Subversion のコミットログに、関連チケットの番号を残すと、チケットの側でもログとリビジョン番号が確認出来るという、タスクと連動するなら割と必須な機能です。ちなみに redMine については redMine 使ってみる を参照。
話しを戻しましてリビジョン473以降にアップデートすると、「管理」→「設定」の下の方に「Referencing keywords」と「Fixing keywords」と言う項目が追加されます。この「Referencing keywords」が関連ログ用のキーワードで「Fixing keywords」がステータス変更用のキーワードになっています。
「Fixing keywords」が入力されると、「Applied status」に指定してあるステータスに変化する事になるので、ここは「解決」や「終了」などの連動させたいステータスを指定しておきましょう。
設定を終えてから、登録してあるプロジェクトのリポジトリで新しいチェンジセットのコミットをし、ログメッセージに「Referencing keywords」や「Fixing keywords」に含まれているキーワードと共に issue の番号を書くと、該当の issue に各リビジョンへのリンクが付与され、必要に応じてステータスが変化します。
trac と違ってコメント欄には何も追加されないのでわかりにくいのですが、この辺りは今後のバージョンアップでわかりやすく変化していくんじゃないかと思います。
さて、実は単にコミットしただけではすぐに issue 画面には反映されません。反映させる方法は二通りありまして、一つはブラウザで「SVNリポジトリ」を表示させる。もう一つはコマンドラインからログを反映させる、という方法を採る必要があります。
コマンドから反映させるには、./script/runner "Repository.fetch_changesets" -e production を実行させるだけです。大した話じゃありませんので、これを実行するプログラムをリポジトリの post-commit にでも書いておけば良いでしょう。
例えばこんな風に。
$ cat post-commit #!/bin/sh /home/takayama/rails/redmine/script/runner "Repository.fetch_changesets" -e production
オフィシャルサイトのフォーラムには cron を使ってやる方法 も書かれていたので、post-commit がうまく動かない場合やリポジトリがリモートにある場合は cron でやるのが良いでしょう。
最後になりますが、でぃべろっぱーず・さいど の中の人が日本語で情報交換出来る場として redMine Users を作って下さったので、興味がある方は参加してみてはいかがでしょう。私もいるんですが、コメントを投稿しようとしたら Google が不調だったせいか何かでうまくいかなくてスネて放ってありますごめんなさい。
今ベーシック認証の事を考えていまして、モデルを置き換えるだけで対応出来るんじゃないかとも考えているので、その辺の事を知りたかったりします。
△トップ | コメント (0) | トラックバック(1)
bloglinesの未読数をグラフ化する を見て真似したくなった。
自分の場合は munin を使っている ので、munin のプラグインを作ってみる。
munin のプラグイン用のディレクトリ(/etc/munin/plugins/とか)に ldr とか適当な名前を付けて以下のファイルを保存。実行権限も忘れずに。
User の所には livedoorReader のユーザIDを入れておくと良い。
#! /usr/bin/env ruby User = 'EXAMPLE' Url = 'http://rpc.reader.livedoor.com/notify?user=' require 'open-uri' def main content = open(Url + User).read content =~ /\|(\d+)\|\|/ result = $1 puts "unread.value #{result}" end def config puts <<__END__ graph_args --base 1000 --lower-limit 5000 graph_scale no graph_title livedoor Reader graph_vlabel number graph_category misc unread.label unread unread.info Unread count __END__ end if ARGV[0] == 'config' config else main end
他の(デフォルトの)プラグインを見ながら作ってこんな感じに。例外処理の作り方がわかんなかったので、そこはサボってます。
munin を再起動させて一週間くらい待つと、こんな感じのグラフができあがる。
なんつーか、未読数が多すぎていつ読んでんだか全然読み取れない上に、上下にピクピクしながら右上を目指している変なグラフになった。
△トップ | コメント (0) | トラックバック(0)
この本は大変評判が良くて、いつか読みたいリストにいながらも購入される気配が無いまま過ごしていたんですが、3月くらいに改訂版として第2版が出版されたので、ここぞとばかりに購入しました。
…確かに多くの人がお薦めするのが良くわかる。本当に素晴らしい内容です。ウェブの開発に携わる人は、もれなく読んでおいて欲しいです。
著者はユーザビリティの専門家で、多くのウェブサイトに関わってきた経験を持っているようです。そういった観点から、本当に気を付けなくてはならない点、あまり重要ではない点、などを実例を交えて教えてくれています。
特に全体に渡り、ユーザテストの重要性を説いているのが興味深いです。ユーザテストってのは、新しいウェブサイトに全く関わりの無い人間を連れてきて、操作をさせてそれを眺めるというアレです。 私も新しいモノを作ったら、同居人な人に使わせてみてどうやって操作するのかを眺める事はあるけど、こういう事をやった事が無ければ是非やってみて欲しい。 他人ってやつは自分とは全然思考が違うと言う当り前の事実に簡単に気付けます。
それに、結構名言だと感じた文も多かったです。
P.210
スクリーンリーダーのユーザーは、耳を使って「斜め読み」する。
以前アクセシビリティ関連のセミナーに参加した時に、どっかの会社の偉い人が、実際に視覚障害の人が読み上げソフトを使っている所は見た方が良いみたいな事を言っていましたが、確かに「斜め聞き」なんて事をしてるなんて全く想像していませんでした。
あとは、わりと自転車置場の議論になりがちな「みんな○○が好き(or 嫌い)」な問題にも触れていまして、いわく「平均的ユーザなどいない(P.151)」んだから、その時のサイトの内容に合わせて検討しなさいね、という事でした。
まあ、こんな感じでほんとお薦めです。 全ページカラーで、読むのにもあんまり時間は掛からないので是非どうぞ。
△トップ | コメント (0) | トラックバック(0)