ReviewMonk を動かしてみた

一時期盛り上がって、しかし自分のコーディングに集中したことで下がっていた review 熱。今もまだ盛り上がってはきていないのですが、とりあえず前から気になっていた review 用のツールを一つ試してみました。

ReviewMonk ってなに?

一言で言うと

working copy を HTTP で公開しちゃって、誰でも diff を見れるようにするツール

です。今のところ(rev.14 時点)対応しているのは Subversion のみです。show full file をチェックすると diff だけでなく working copy の状態をそのまま表示することもできます。

セットアップ&実行

Rails 2 + svn HEAD で動かしました。

DBMS の migration 不要でいきなり動きました。とは言え adapter の設定はちゃんとしておかないとダメでしたが。

ドキュメントがちょっと違ってて

lib/settings.yml

は存在しなくて

config/settings.yml

でした。サンプルとして

project_root: /home/$USER/projects

が入っていますが、これだと実行ユーザーのホームディレクトリ以下に working copy が限定されます。しかし例えば開発者がサーバを共有している場合は

project_root: /var/src

なんて風にしても ok です。ただし、この

/var/src

以下に .svn を含むディレクトリがないと何もディレクトリがリストアップされないのでちょっと焦ります。これは svn が

svn: '.' is not a working copy

と言っている状態で、その下の階層を調べることはできません。しかし URI に

http://REVIEWMONK_TOP/codereview/stat/PATH/TO/WORKINGCOPY

と、project_root 以下の階層を直接打ってやると表示できます。

また、リスト表示の状態で

  • diff
  • recursive

がチェックでき、両方にチェックするとコマンドラインで

svn diff

と打った状態がブラウザに表示されます。デフォルトは

svn stat -N

でファイルのリストだけを表示し、diff の見たいファイルを選んで表示する、というスタイルです。

感想

他人の working copy の状態をお手軽にレビューするには向いているような気がします。少なくとも working copy のパスに URI が付くのは単純に便利です。

もちろん文字コードの問題はあるし、レビューとは言っても何かしら記録を残すことは今のところできません。ということはこのツールだけではレビューをワークフローとして取り入れることは難しいです。

以前、Trac の PeerReviewPlugin を試しました。これはこれでよくできていた1のですが、試した時点では

  • Review の feed を取れない
  • Wiki から source browser へのリンクなどがおかしくなる

など、常用するにはつらい問題を抱えていたので採用は見送ったままの状態になっています。今なら問題が解決してるのかなぁ? あんまりちゃんと情報を追いかけてないんですよね。

また入れ直してみるか、また何か別なツールを試すか…。

  1. コミットしたものをレビュー対象にするので今回のツールとは考え方が違います。 

nadoka を使ってニュースの feed を irc に複数垂れ流す

ネタとしては十分すぎるほど古いんだけど、irc 系の記事ってあんまり見ないのであえて起こしてみた。

※ 良い子は他の人に迷惑にならないところでマネしてね。

昨日、nadoka を導入した。それなりに便利そうだったのであれこれ設定をいじってみている。Twitter の要領でニュースをダラ見できたら便利そうだったのでやってみる。設定は以下のような感じ。

 Channel_info = {
   '#itnews' => {
     :timing => :startup,
   },
   '#news' => {
     :timing => :startup,
   },
 }

 BotConfig = [
   {
     :name      => :RSS_CheckBot,
     :rss_paths =>
     [
       'http://japan.zdnet.com/rss/news/index.rdf',
       'http://journal.mycom.co.jp/haishin/rss/index.rdf',
       'http://japan.cnet.com/rss/index.rdf',
     ],
     :cache     => File.join( ENV['HOME'], 'var/nadoka/RSS_CheckBot.cache' ),
     :ch        => '#itnews',
   },
   {
     :name => :Rss_CheckBot,
     :rss_paths =>
     [
       'http://feeds.reuters.com/reuters/JPTopNews/',
       'http://feeds.feedburner.com/reuters/JPBusinessNews/',
       'http://feeds.feedburner.com/reuters/JPWorldNews/',
       'http://www3.nhk.or.jp/topepg/rss/news/rss20/cat5.xml',
       'http://myrss.jp/rdf/r45b9b8dd2ab464231.rdf?v10',
     ],
     :cache     => File.join( ENV['HOME'], 'var/nadoka/RSS_CheckBot.cache' ),
     :ch        => '#news',
   },
 ]

ここでは #news という channel と #itnews という channel を用意して、それぞれ別の設定で別の種類のニュースを流している。

同じボットだけと別々に設定を保持して機能させられるんだな。なるほど。

技術の必要性を現場が分かってなきゃどうしようもないというか

切込隊長BLOG(ブログ) - 本当に技術が必要とされる現場にgeekがいない

へー。

普段読んでないんだけど、面白い。

まぁ geek とかそういう言葉を持ち出さなくても、技術の分かっている人がいないと不幸を生むというのは、今の世の中あちこちにあるわけで。でも利益を生むかどうか分からないから技術者を飼っている組織ってやっぱ多くはないわけで、必要になったときにレベルの低い(競争のない世界にレベルの高い業者がいるわけない)外注に丸投げしてダメダメなシステムが導入されてものすごく生産性が落ちたりするわけですな。

証券取引所とか空港関係みたいなシステムだと落ちると目立つけど、毎日何度も不調になったり、メンテナンスしてもちっとも性能が改善されないとか、あげくクライアント側が固まりまくってどうにもならなくなるようなシステムは田舎には実はゴロゴロしてたりしなくもないわけですよ。使いものにならないシステムで恐ろしく生産性の低い仕事をイライラしながらこなしている人は不幸だなと思いますが、実際には内部に技術の分かる人が少しでもいれば、これはおかしいとかもっと早い段階で気づけて、最悪の現状を回避することはできていたような話だったりします。言い方は悪いけど自業自得って言うかね。

なんか話の軸がずれちゃったけど、みんな多少は技術者飼っといた方がいいと思いますよ、という話、なのかな。普通の待遇でたまたまパソコン詳しいから兼務、とか、せめてそういうのはヤメロ。

アジャイルの話を Web で眺めているのは嬉しくて楽しくてとても気持ちがいいけれど、現場のひどさはアジャイルの三世代くらい前というか、なんだ、HDD やオンラインが当然の今の時代に tape read error 頻発みたいな、そんな悲惨な状態を想像してちょうどいいくらいの、それでもそれをおかしいと気づけない、あるいは気づいててもどうにもならないと諦めているような人たちがイライラと毎日を過ごしているような、そんな感じだったりします。おわり。あ、自分とこの話じゃないです、念のため。聞いた話ね、あくまでね。

まこと先輩は高橋さんだ

第2回 誰でもWeb管理画面に入れる気前のいい会社 ("星野君のほのぼのWebアプリ改造計画", @IT)

このいつも不在の不良社員高橋さんこそがまこと先輩の正体なのだ! スパハカはこの中に居る!

……。

というかこの会社、それなりに Web アプリやセキュリティを知っているその同僚や先輩がシステム組めばいいのに、何やってんだとか思うのはダメですか。

まぁ Web の場合は見た目ばっか気にされるので中身ぐちゃぐちゃってのはよくある話ですが。しかし新人の星野君はローカルの実験環境で Perl + DBI + ほげほげな環境をよく再現できたな。慣れ親しんでいたのは PHP じゃなかったのか。@IT のこの手の連載に出てくる新人君は何も知らないくせにアプリのセットアップとか使い方への習熟とか尋常じゃないスピードでスキルアップしていく、すごくアンバランスな人材がいっぱい出てきてビビる。

サーバ上には、「Admin」以外にも「test」「old」などという名前のフォルダがたくさんあった。おそらく、バックアップなどの目的で置いているのだろう(※1)。

from 2ページ目

の辺りは懐かしすぎて涙が出ますねー(棒読み)

何かの拍子に文字が入らなくなる

OS X を使っていて、何かの拍子に通常の文字入力に利用するキーが入らなくなるという症状にハマることがある。そんなにしょっちゅう起きるわけじゃないから放置しているんだけど、なんだか気持ちよくない。2台使っていて2台ともで起きるので機械に固有の問題じゃないと思う。

通常の文字入力には使わないキーの組み合わせなので command + tab なんかは普通に使える。でも command + q はできない。いちばん困るのは emacs -nw で作業しているときで、こいつはどうすることもできずに terminal ごとお亡くなりになっていただくしかない。remote で screen 使ってれば auto detach の恩恵に預かれるが、local だとどうしようもない。emacs だから自動でどこかに保存されてるさーと思ったときに限って文字化けしていて復旧できなかったりする。1

なんだろ、これ。PowerBook + 10.3.x + ことえり固有の問題なのか、OS X では漏れなく発生しうるのか。ちなみに、アプリは問わず全体的に入力できない。NumLock の on/off とも関係ない。つかどうにかこの状態を脱出できないものか。今のところログオンし直せばいいってのは分かってるんだけど、前述のように emacs -nw のようにマウスで保存作業を行えないアプリのデータを殺したくない。短ければマウスでコピペできるかもしんないけど、そんな軟弱な方法やだ。

  1. w3m + Emacs という組み合わせで、ファイル名を明示的につけずに作業していたりするのがいけないんだろうけど。 

nifty の tty が来年春をメドに廃止へ

NIFTY SERVEのフォーラム、2005年3月をめどにWebフォーラムに移行 (INTERNET Watch)

スラドの方でコミュニティの質の違いやあの頃の方が S/N 比が高かった的な発言がちらほら。この辺は思うところがあるのだけど、今までうまくまとまったことがなくてちゃんと書いたことがない。

ま、とりあえず感慨深いですねということでここに記しておく。気が向いたら書き直すかも。

ヌーヴォ−解禁

今年も木曜の夜に行きました。お気に入りのバーへ。

ここ 3 〜 4 年くらいは確実にヌーヴォーを目当てに行っている。去年と今年はお店で一番乗りに飲んでいる。世間では今時ヌーヴォーヌーヴォー騒ぐなんてバカみたいという捉え方もあるだろうが、逆に流行る前からずっと好きだった人だっているんだから、こういう指摘は一面的だ。自分は赤ワインを普通に飲めるようになったのがここ 5 〜 6 年くらい1なので、ヌーヴォー解禁を楽しめるようになったのが最近というだけで、別に独りだけブームが 5年遅れできたわけではない

味の方は去年と比べて酸味が強い。去年のものはもっとぶぁっと広がってすごく華やかだったんだけど、今年は少し落ち着いた。今年のものの方が普段飲むにはいいかもしんない。

その後、Usquaebach Reserve を初めて飲む。ある人のマシンの名前として6年前くらいにこの名前を拝借したんだけど、実は今まで一度も飲んだことがなかった。感想は、ちょっときつい。香りは最初ちょっとラムっぽい?とか思ったけど、飲んでみるとしっかりスコッチ。度数的には普通なのに飲んだ感じの強さは普通のものよりワンランク上。ロックで少し時間を置くと飲みやすくなるけど、味的には最初のきつめの方が好み。このときはゴハンにグラタンを食べていたんだけど、これを食べた後に飲んだのがよかったみたい。

言い換えると、普段飲むには少しつらい。間違ってもナイトキャップとしては飲めない。

  1. それ以前から飲めてはいたが、自分の好みがはっきりしてきて、赤ワインを飲むのが好きだと自覚できてきたのが 5 〜 6年という意味。 

くそ

Ruby を使いたいと思いつつ、Perl で書くのがいちばん速いからつい使ってしまう。

ノートパソコンのディスプレイを

デスクトップ型のディスプレイとして活用できるようなものってないんですかね? あったらめちゃくちゃほしいんですけど。需要あるような気がしません? 普段サーバなんてディスプレイ要らないんだし。

About

例によって個人のなんちゃらです