<< 2007/04/ 1 1. とりあえずしばらく起業はたぶんしないと思うけど
2 3 1. S5 を使うなら Camino より Firefox がよい
4 1. Pager が microformat に対応するとちょっとかっこいいかも
5 6 1. 最近 awk をよく使う
7 8 1. 夜桜行ってきた
9 10 11 1. screen + emacs c/s 生活始まる
12 13 14 1. 珍しい Dav クライアント
15 1. メントレGゴールデン
16 1. 言語の互換性と難民発生率
17 18 19 1. APOP 解読成功らしい
2. どうでしょうClassic ヨーロッパリベンジ
20 21 1. ちょっと疲れて手が進まない
22 1. Diigo って API ないのか?
23 24 25 26 1. __PHP_Incomplete_Class を防ぐ富豪アプローチ
27 1. 唐突にまとめ
28 29 1. 身体に染み付いたテンポ
2. 時間ができたのであれこれアップグレードとか
30 1. Web 上のリソースの賞味期限
>>
トップ «前の日記(2007-04-26) 最新 次の日記(2007-04-29)» 編集

2007-04-27 [長年日記]

_ 唐突にまとめ

一段落ついたので最近自分とその周辺を振り返って感じたていたことをまとめてみる。

  • Subversion 便利
  • CLI 便利
  • rsync 便利
  • Emacs 便利

Subversion 便利

単純な話、CVS より Subversion の方がクライアント環境が充実している。CLI の人ばかりなら CVS でも Subversion でも使える機能に違いがあるだけで大きな問題はないが、そうでない人が居るなら CVS より Subversion の方がよい。Subversion より高機能なものもあるだろうが、クライアントの対応はやはり今のところ Subversion がイチバンだろう。また Subvserion は使えるプロトコルに http があり、ネットワークに乗せやすい。

ただし cvs2svn で何も考えずに既存のリポジトリを変換してしまうと svn:eol-style が native になっちゃって Windows の人の環境では CRLF になっちゃって、それがあとで影響する可能性があるので注意が必要。

やっぱ CLI 便利

扱うべきオブジェクト(ファイルだったりそうじゃなかったり)が大量にある場合は GUI より CLI の方が効率的に作業できることが多いなぁと思った。

  1. 履歴によって同じ、あるいは似たような作業のくり返しがやりやすい
  2. ファイルの書き換えに関しては、同じアクションで実際にファイルを書き換えるのか、結果の表示だけを行うのかなどのスイッチが行いやすく、テスト -> 本番という段取りを踏みやすい
    • sed 発祥の -i オプションが便利すぎ
  3. パイプによって必要なデータだけを相手にしやすい
  4. 必要なデータ、情報をテキストとして抜き出しやすい
  5. 重くなって作業不能とかいう事態にまず陥らない

特に最後の二つは重要である。

重くなって作業できなくなっちゃうという現象は、立ち上げっぱなしにして使うアプリ*1なら基本的に必ず起きると見ていい。最近だとタブで大量にページを開きやすくなったブラウザなんかもそういうケースが多いような気がする。ま、とにかくそういうことがちょくちょく起きるというのはこれを読んでいるような人はよくお分かりのことと思う。特に大量のオブジェクトを扱うケースなんかでね。

しかし必要なときに立ち上げてフィルタ動作して慎ましく終了するような CLI のツールの場合、そういうことはない。いや実際には自分でやろうとしている処理が悪ければ全然結果が返ってこないとかいうことはもちろん発生するのだけれど、今まで普通に動いていたのに、別な作業をやろうとしたときにモタモタされて作業が進まないってことはほぼないと言っていいと思う。簡単な話、shell が重くなって全然作業できないなんてことは普通起きない。

「テキストとして抜き出しやすい」のも本当に大切なことで、作業のリストアップと作業ボリュームの検討をする人と実際に作業する人が違う、あるいは検証する人が違う、なんてケースではとても重宝する。作業リストを起こしやすく、「見える化」させやすいのだ。

GUI のエディタや IDE で何が不満て、検索した結果見つかったファイル群のリストをテキストとして落とせないことがほとんどである点だ。何もかも自分で作業するとかそのまま作業に移って結果さえあればいいって言うんならそれでもいいんだけど、中間の段階でチェックを掛けにくいのは「兵隊」の道具としては扱いにくいんだよなぁ。

※ 「戦士」の武器としてはいいかもしんないけど、自分で使っていないからそこら辺はよく分からない。

ついでに、ファイルのリストも内部でオブジェクトとして抱えちゃうタイプの(例えば eclipse などの)IDE は履歴管理していないファイルでもファイルが大量にあるだけで動作が重くなっちゃうのでとても不便だなと思った。(プロジェクトの管理方法をうまく設定すれば遅くならないのかな?)

便利だなと思う CLI の使い方サンプル

xargs をやっとつかめた。今まで知らずに済ませていたのが本当に恥ずかしくなった。数年前のときもこれ知ってればもっと速かったんだなぁ。

find . EXPRESSION | xargs grep -Hn PATTERN

で、修正の必要なファイル名と行番号と修正箇所を抜き出しておいて

find . EXPRESSION | xargs perl -i.bak -p -e 's/PATTERN//'

で、実行、なんて感じ。*2あるいはその前に

find . EXPRESSION | xargs perl -p -e 's/PATTERN//' | less

で確認してもいいかな。動作が複雑になりそうならスクリプトを起こして使う、という具合に簡単に切り替えられる点も便利。(というか複雑なパターンはエディタや IDE の置換機能で乗り切れないよなぁ。もちろん不必要な変換が起きていないかどうか diff で確認しておくのもお忘れなく)

修正の状況も

svn status -v | awk '$1 =="M" {print $NF}'

とか

svn diff | awk '/^Index:/ {print $NF}'

とかでリストをすぐに作れる。便利便利。

diff も GUI のツールはファイル全体を対象にして開いちゃうことが多いと思う(もちろんそうなっている方が便利なケースも多々ある)んだけど、あれも複数のファイルの変更の全体像を確認するのには不便なんだよな。というか

svn diff | less 

のように使えないと commit log 書くときや不必要な修正をし過ぎていないかどうかの確認のときに不便だと思うんだけど、そういうのは IDE 派な人はどうしてるんだろう? 単純に疑問。変更したファイルが10個あったら一つずつ diff の作成を10回くり返すの? マジでそうなら IDE 使うなんて信じられない。

CLI はキーボードから手を離さなくても使える

IDE 使いの人の作業を見ていると何かするたびにマウスに手が離れて、しかも目的のオブジェクトをポイントするのに時間が掛かるといったことがちょいちょい起きている。本人は疑問に感じていないのだろうが、どうもハタで見ているとイライラする。どうしてそんなに作業のテンポを悪くする要素ばかりなのだと。

もちろん習熟度によっても違うだろうし、マウスカーソルを合わせただけで情報を取得できるツールチップなど CLI や curses では逆立ちしても実現できない機能などはかなり便利だと思う。GUI 全般やマウスそのものを否定するようなアホな話がしたいのではない。

しかしやはりインターフェイスには向き不向きがある。すべての作業において Terminal さえあれば十分と言うつもりはない。ただ Terminal に否定的な人や嫌悪感を抱いている人にも、「あなたの作業スタイルはあなたが思っているほど便利でも速くもないのだよ」ということは知っておいたもらいたいのだ。決してオイラが old type だからとか新しい IDE が理解できないからこういうことを言ってるわけじゃないのよ。

※ どこかのブクマコメントかなんかでこの手の話題を見かけたような気がするんだけど、なんだったか忘れてしまった。ちなみに自分でもデータベースの中身をチェックしたり簡単な UML を書く際に eclipse は使っている。ただし Emacs ほど長い時間は使っていないし達人の技などは知らないので、勘違いはあるかもしれない。

rsync 便利

いろいろクセがあって個人的には意外とハマる rsync だけど、やはり使えると便利。まぁ単純に .svn などの特殊なディレクトリやファイルを除外してネットワーク越しにミラーリングできればなんでもいいんだけど、こういうツールを何か一つ押さえておくのは大事だなと思った。Explorer や Finder の機能だけしか使えないってんじゃ話にならない。

Emacs 便利

これは余談。今まで

  • ediff-buffers
  • vc-mode

など開発者なら使ってて当たり前だろと思われるようなものを使わずに全部コマンドだけで済ませていた。いやこれはかなり恥ずかしい。いや Emacs のような巨大なツールなんか使いこなせなくて当然だから恥ずかしくないと言えばちっとも恥ずかしくはないんだけど、使い始めたらどっちも手放せないな。(vc で log とか化けまくっちゃうのはなんか設定が足りないのか、そもそも UTF-8 で動作させていないとダメなのかな?)

Emacs 22 のカラーカスタマイズは以前 FreeBSD の Emacs で確認済みなので、近いうちに Emacs も入れ直して手元の環境をすべて UTF-8 に統一しちゃった方がいいかなーと思い始めている今日この頃。

なんて言ってたら Dan の中の人が CotEditor をベタ誉めしている*3。おぉ、確かにこれはいい。今度薦めておこう。自分でも mi の代わりに入れておくつもり*4。まだちょっと負荷テストが足りてなさげで、大量のファイルを開いたりすると途端に重たくなっちゃうのはご愛嬌かな。

これ、桁折り位置をウィンドウ幅以外でその場で指定できるといいなぁ。

cf. AYNiMac : 自作ソフト : CotEditor 0.9.2

mi はもっさりしていて、Smultron は日本語判別がタコなのと MDI なのがイヤだったんだけど、これはどちらもクリアしているので GUI なエディタはこれに落ち着きそうだ。

*1 多くの GUI アプリや Terminal 上で動くものでもエディタなら同じ

*2 正規表現ライブラリが食い違っているのが気になる場合は全部 Perl とか。高級な sed として使うときは Perl 便利だなぁ。

*3 このエントリは書き始めたのがこの日付なだけで実際には29日に書いている。

*4 フォントは Osaka-mono ではなく Monaco 12 で。

本日のツッコミ(全2件) [ツッコミを入れる]
_ (2007-05-05 14:34)

"perl -np" と p と n オプションを両方同時につかっても、pしか有効にならない気がするのは私だけでしょうか…。

_ wtnabe (2007-05-05 17:54)

おぉ? 無意識に両方付けてました。perldoc perlrun に思いっきり "A -p overrides a -n switch." って書いてありますね…。修正しときます。