topless で Activity Monitor もどき

Aug 19, 2009

背景

Activity Monitor の動作例

MacOSX には Activity Monitor というツールがあります。Windows 使いにはタスクマネージャのようなもの、Un*x 使いには top みたいなものと言えば通じるかなと思います。しかし自分が思うに、これらのツールと違って Activity Monitor には決定的に優れている点があります。それは

プロセスの様子をモニタリングする際にフィルタが掛けられること

です。

スクリーンショットは自分の立ち上げている zsh プロセスだけをモニタリングしている様子です。タスクマネージャ¹ではソートはできても抽出まではできませんし、top でも特定の owner のプロセスは抽出できてもその中でプロセスの名前でフィルタを掛けることはできません。

これ、他の環境でもできたら便利だなぁと以前から思っていたのです。

21:57:04 >wtnabe< activitymonitor みたいに top を grep できたら便利なん
                  だがなー

できました。

topless

06:36:38 >wtnabe< 昨日の夜つぶやいていた activitymonitor みたいなやつは
                  ps, grep. topless でできた。例えば ruby 関係のプロセ
                  スは topless 'ps ax | \grep ruby | grep -v "grep
                  ruby"' で出せる。
06:40:39 >wtnabe< toplessは名前だけ知ってたけどこれ後藤大地さんか(*BSD
                  使いじゃない人向けに「漢のzsh」の中の人)。shスクリプ
                  トだしパッケージになくてもtarball落としてくればかなり
                  の環境で動くはず。
07:06:14 >wtnabe< インストールには make と pod2man が必要だけど、インス
                  トールしなくても動くし。ものすごく便利!!!ってわけじゃ
                  ないけど、持っておくとよさげだ。
                  http://codezine.jp/article/detail/67,
                  http://people.freebsd.org/~daichi/src/
07:12:00 >wtnabe< ちなみにインストールは古式ゆかしく make && make
                  install
07:31:00 >wtnabe< activitymonitor 代わりに使うときには ps よりも top の
                  batch mode と組み合わせると便利。ただし OSX 10.5 の
                  top には batch mode なかった。

後藤大地さん作の topless というツールはとにかくどんなコマンドでも top 風に定期的にリフレッシュしながら表示し続けてくれます。驚いたことに sh スクリプトで書かれており、Unix-like なシステムに標準で入っているコマンドだけを組み合わせて動作します。

インストール

FreeBSD なら ports にありますが、MacOSX, Linux は多くの場合パッケージにはありません。でも大丈夫、make と Perl と install があればインストールできます。tarball を紐解いて

make && make install

で ok. それも man が roff ではなく pod で書かれていて pod2man が必要ってだけなので、man が要らなければ topless というファイルをコピーするだけで構いません。

topless --help

と打てばだいたい使い方は分かります。

使い方

例えば

topless 'ps ax | grep zsh | grep -v "grep zsh"'

と打つと最初の Activity Monitor の例と同じように自分の zsh プロセスだけ抜き出すことができます。

本当に Activity Monitor のような情報が欲しければ

top -b

で top を batch mode で実行した結果を topless に渡すとそれっぽくなります。ただし -b オプションの batch mode は FreeBSD と GNU top では確認しましたが OSX の top にはありませんでした。まぁ、OSX では Activity Monitor 使えばいいんですけどね。今回の目的はまさにそれですから。

え。htop 入れればいいじゃん？な、なんだってー。

[追記] Linux だと watch かなと教えてもらいました。

Twitter / Hirofumi Saito: topless で Activity Monitor …

少なくとも Windows Vista までは ↩

「こだわリング」認定アイテムNo.1「メガネ」

Aug 19, 2005

んーと、これはあれか。メガネ男子好きの話なのか。メガネっ娘好きの話ではないのだな。両方やるとギャップが浮き彫りになって面白かったと思うけど、30分番組で両方やるのは無理だわな。

それにたぶん男がメガネ女子を語るのはまだタモリ倶楽部レベルじゃないと危険だろう。そもそも対象が極端に少ない。メガネ男子はメガネロックはじめ、普通に掛けてる人がかなり増えたが、メディアに露出してて tommy february6 みたいに狙いすぎてるメガネ、井上和香がいいともで掛けてるようなピンポイントアイテムとしてのメガネを外すと極端にサンプルが少ない。いきおい、2次元の人になるか、下手すると光浦とかになっちゃう。そもそもメガネ女子についてはまだまだ「ドジなメガネっ娘」とか「メガネ外すと実はかわいい」系の記号が強すぎる。

うーん、確かにメガネ男子好きに限定して正解だ。（※ そもそも女性向けの番組です。）

以下、YOU 語録。

「顔のいいダテ眼鏡なんて、まったく用事ないですね。」

「今わかった。所長（YOU）は男子の持ってるコンプレックス大好物。コンプレックスのない男はだめだ。コンプレックス万歳」

「（自分で眼鏡を掛けて）あたしの中のエロティシズムが目覚めますね」

立派な仕事してますよ、所長。

PukiWiki でスケジュール通知できないか考える

Aug 19, 2005

パソコンに向かって行う作業についてはそんなに難しくなくて、

単純に calendar2 に未来の日付で書いておく
すると当日には calendar2 が（何も引数を与えずに）置いてあるページを開くと、やるべきことがずらずら出てくる
ある程度の期間があるものは先日いじった calendar_viewer を併用すれば ok

この際、作業内容など細かいものは [ [task/ほげほげ] ] みたいな別ページに書いてそこにリンクを張っておけば、スケジュールの調整も簡単にできる。calendar ページにはあくまで項目だけを置いておく感じ。

ただし、例えばこれが不燃ゴミの日とかそういう類いになると、いちいちパソコンなんか見ないからまったく使いものにならない。そこで、

crontab とか at とかを使ってメールを出すとかすればよいのでは？

と思ったのだが、課題がいくつかあって、大きく分けると

crontab あるいは at を使うことについての課題
スケジュール情報を crontab あるいは at へ反映させるタイミングについての課題
プラグインとして実装するとして、呼び出し方はどうしよう

の3つ。以下に列挙すると、

crontab あるいは at を扱うライブラリがないのでベタ書きか？でもこれがあったら応用範囲は広そうなので、独立したライブラリになってた方がよさそう。→ 自分で書くのか？
Linux は /etc/cron.d が使えるのでその下に pukiwiki とか置いてやるのが楽そうだけど、FreeBSD はどうしようかなぁ。まさか /etc/crontab には反映させたくないしな。at って使ってないからよく分からん。
というかユーザーごとに crontab を分ける場合は crontab コマンド使うのがセオリーだからファイル直接いじるのは難しそうな気配が。crontab -u USER - でできるんか？
at の方が楽そうだけど、スケジュールのキャンセルをしようと思ったらそれを明示しないといけないので、通常の Wiki のページ編集の概念と合致させるのが難しそう。diff から自動的にキャンセルするスケジュールを割り出すこともできなくはないけど、確実かどうか不安。
Windows サーバのことは考えてない。at は NT系 Windows にもあるけど、書式とか全然調べてない。Windows 対応も含めるとやっぱ at でイクのがいいのかなという気はする。
ページ編集時に crontab や at に反映することができない
- PukiWiki のプラグインは基本的に表示の段階で効力を発揮するので、書いた段階でその内容を反映させることはできない。保存して自動でリロードされるときに反映って形になるが、毎回表示のときにあれこれ裏で作業やると重たい。
- config.php を利用して crontab や at へ反映させる情報を :config/plugin/ 下のページで一元管理してやればキャッシュとしても機能して負荷が軽くできるかも？
  - config.php を眺めてみたが、ページの書き出し用のメソッドは用意してあるので、できなくはなさそう。
編集時にアクションを起こす方法として、$update_exec ってのがあるけど、外部のコマンドを呼び出すだけなので、PukiWiki 内部の情報を渡すのはかなり難しい。array じゃないので別な何かもやらせようと思ったときには shell script やバッチファイルにする必要があるなど、使い勝手はよくない。
プラグインの使い方は普通のブロックレベルプラグインで #sched( アクション,通知方法, HHMM [,YYYYMMDD] ) みたいな感じがいいのか？ table で表示させるとかの工夫があればいいかもしんないけど、踏ん切りはついてない。

とかかな。まだ抜けはあると思うけど。

ちなみに、全然コードは書いてないので、すでにある、おれなら簡単に作れる、という情報の方が、crontab, at, config.php などに関する情報提供よりも嬉しいです :-)

まぁ Wiki でやろうとするなよという指摘がいちばん妥当なんだろうけど。

手元の環境だけでデータを起こす

Aug 19, 2004

はてなダイアリーライター

確かにファイルが手元にあるのは嬉しい。だから自分は

tDiary
squeeze プラグイン
cron
sitecopy

を組み合わせた。うーん、結城さんとまったく逆のアプローチですな(^^; 出てくる道具の数は自分のやり方の方が多いから、一つでも不慣れな道具があるとかなり面倒な感じがするだろう。Perl スクリプト一本の方が他人に同じ環境を再現させようと思ったときは楽なのは間違いないし。

でもなんだろう。個人的にはやっぱり本番と同じ環境を手元で再現できるのが嬉しいんだな。特に Wiki 記法とかカテゴリとか便利な機能を使い始めるとどうしても Web アプリ上で書く方が書きやすい感じするし、オープンなアプリならインターネットに繋がらない環境でも再現できる。

つまり、手元の環境だけでデータもアプリも再現できる、それが嬉しい。まぁこれははてなの日記以外の機能をまったく必要と感じたことがないからってだけかもしれないけど。

ひらぶん

Aug 19, 2004

ことば

どうでもいいことなのだけど、一昨日の夜中に庄司くんの発した「へいぶん」という言葉に実は微妙に引っ掛かっていた。調べたらどちらでもよいらしい。

参考ひらぶん【平文】 (infoseek.co.jp)

ライブドア頑張るなぁ

Aug 19, 2004

新球団設立まで行くとは。今度は株価的にはあまり評価されていないようですが。ちょっと最近社長が個人でメディアに露出しすぎてるしねぇ。もっと抑えておいた方が印象はいいと思う。

しかし、素人目に見ても、今の日本のプロ野球ってそんなに商売として旨みはないと思うんだけど、なんでこんなにムキんなってるんやろか、この人は。

Python のパラドックス

Aug 19, 2004

Tool

www.textfile.org 経由「Pythonのパラドックス」

ついでに

「Revenge of the Nerds」

多少習得に難儀してもパワフルな言語で生産性を挙げろってことなのかな？でも読みやすさも重要で、そういう意味ではやはり Python や Ruby が現代的なのだと思う。Java に比べてセットアップも楽だと思うし。

しかし Lisp にもかなり興味が沸いてきたなぁ。やっぱ Gauche か。その前に、自分の中で Perl 並みとは言わないまでも Ruby での開発速度も上げていかないと。

ネットバンキングにご用心

Aug 19, 2004

Security

www.textfile.org 経由某ネットバンクでのお話 (hatena.ne.jp)

合わせて「デジタルARENA / ネットバンクで1600万円が突然消える」なんて辺りを読んでおくとあぶないのがどこか少しは分かるかも。

しかしなぁ。例えば自社ビルを建てるときにこの偉い人は免震構造とか空調のコストとか当然セキュリティを考えるはずなのに、ネットワーク絡みのセキュリティになると途端にみんな不勉強になるのはなんでですかね。

まぁセキュリティの話を本当に分かりやすく説明する力がある人は多くない、ってのはあるかもしんないけど。セキュリティに強い人たちは結局実際にセキュリティを確保したり検証したりするのが仕事の人ばかりで、啓蒙活動できるほど余裕のない人がほとんどだろう。また、例えば現役のエンジニアを卒業した人がネットセキュリティに警鐘を鳴らす役割を担えるかっていうと、まだそんなに歴史のない分野だから人材の確保が難しいだろうし、大学などでポストを確保できないと権威付けできないから偉い人の説得が難しいって面もあるかもしれない。それにセキュリティは暗号理論に強ければ教育できるってもんでもないから、退役エンジニアならその役を担えるかっていうと、そうとは言い切れない。

ここで簡単にというか乱暴に説明を試みると、今ちまたに溢れる脆弱性ってやつは、簡単に言えばデキの悪いカギを使っていても家財は守れませんよという話である。その事実に住民が対処しないのは泥棒に狙われる可能性が低いと判断していたり、本当に大事なものはデキのいいカギの金庫に入っていたり、銀行の貸し金庫に入っているから大丈夫、という計算が働いているからだろう。同じように、その事実に対し建物の管理人が対処しないのは、ピッキングに強いカギを使わないといけないという法律がないとか、ピッキングに弱いカギの建物を管理していても、それで訴えられる可能性は低いという計算が働いているからである。ネットバンクのこの手の問題も基本は同じだろう。

しかし現実世界には「周囲の目」という、自分たちが実際に対策をしなくてもある程度セキュリティレベルを保ってくれるありがたいものはあるが、ネット上のセキュリティにはそんなものは存在しない。また、ネット関係のセキュリティの場合は被害が簡単にでかくなってしまうという問題を見落としてはいけない。物理的なカギの場合はどんなに脆弱なカギでも人間がそれを開けて中を物色して退出するまでにそれなりの時間が掛かるし、人間の存在を消し去ることはできない。簡単に言えばその時間にその人がその場所に居たという事実を消すことはできない。アリバイ工作によってごまかすことができたとしても、人間の存在は消えない。しかしコンピュータの場合は文字通り一瞬で大量にデータが取り出せるし、不正なアクセスの痕跡は極力残さないようにすることが可能である。（条件が整えばほとんど追跡不可能な形で不正を行うこともできなくはない。はてなの日記にあるように、追跡云々という話まで含めてセキュリティ問題に対する強さなのであるから、脆弱なシステムではそもそも追跡できない場合も少なくはない。）つまり、コトが起きる可能性について同程度とみなすことができる物理的なセキュリティ問題とネット上のセキュリティ問題が仮にあったとして¹、実際にコトが起きたときの「やばさ」はネット上のセキュリティ問題の方が大きいってことである。

この「やばさ」は現実の被害の大きさ²に直結するものではないが、大事なのは「小さな穴に見えるものが本当に小さい穴なのかどうか」ということである。物理的な穴は大きさを見誤ることはまずないが、目に見えない穴の大きさをあなた（管理責任者）は本当に分かっているのですか、っつーことだ。