メッセージ。 - diary

たまに中華料理屋さんに入って不思議に思うのは、たとえば「野菜のオイスターソース炒め」というメニューがあったとしたら、それに併記して「鶏肉のオイスターソース炒め」、「魚のオイスターソース炒め」などというメニューが記載されていることだ。

「鶏がいいの？魚がいいの？」と聞かれているように感じるのだけど、どうもぼくの感性ではそのようなメニューの選び方はピンとこない。たとえばメニューに「麻婆豆腐」と「麻婆茄子」があってまださらに「麻婆鶏肉」、「麻婆魚」、「麻婆野菜」があるような感じ。

麻婆豆腐と麻婆茄子についてはイメージが湧き、「それを食べたいか、食べたくないか」を考えることができる。でも、「麻婆鶏肉」、「麻婆魚」、「麻婆野菜」と言われると、なんかこう、違う気がする。食べものというには、野菜か魚か鶏肉か、ブロックみたいに組み合わせて食べたいとか食べたくないとか決めるものではない、とでもいうような。

「麻婆は決まった、オイスターソース炒めは決まった」、「それに何を組み合わせる？」 と言われても、さっぱり分からない。比べられないというか。それらは交換可能じゃない。レイヤの切り分けとか、クラス設計が違うというか。

……こういうブロック指向のメニューって独特だよね？ 日本の料理とか、イタリア料理なんかでは、あまりないような気がする。中華料理屋さんに入ると、たまにそういうメニューの店があって、不思議だなぁと思います。

ああ 春だなぁ。
風は冷たいけれど、不思議にあたたかい。
太陽の光があたり一面を照らしだし、なにもかもがまぶしく見える。
あの空の色の青さ！ 昨日となにが違うのか不思議。

全雑誌休刊で“脱紙”加速、ソフトバンクの大変身｜inside｜ダイヤモンド・オンライン
http://diamond.jp/series/inside/03_01_003/

なんという「ものは言いよう」！ 笑った。

おいらが腹を立てているのはこれ↓っすよ。

はてなブックマーク - なぜ「見た目」にこだわらないのか、IT部門の大きな勘違い：ITpro
http://b.hatena.ne.jp/entry/http://itpro.nikkeibp.co.jp/article/OPINION/20080215/293889/

なんでこんな記事が受け容れられているのか。反対意見を唱えている人がほとんどいないなんて変だす。はっきり言ってあの記事は悪い記事だと思うのに、誰もそのことに気付かないの？ （いつものことだけど）頭がおかしくなりそうだ。

システムってのは、基本的にかけ算でとらえることが適切だと思う。たとえば梃子（てこ）みたいなものだ。梃子では、支点・力点・作用点を調節することで、力を何倍にも強めることができる。これと同じでシステムも、ある種の力（リソース）を何倍にも強めたり縮めたりできる。梃子の仕組みがシンプルなように、システムもまた一番基本の部分ではシンプルだ。

たとえば万力は梃子の一種だと考えられるけど、使い方を間違えれば大きな怪我の元になる。パッと見では予想できないような大きな力が、ある一点にかかるからだ。万力や梃子やシステムを使う人は、ある程度その道具に通じている必要があるし、十分注意して使わなければいけない。

これらの道具を開発・導入するにあたって、「梃子の力が大きすぎて危険だ」という意見が出ることがある。たしかに梃子の力は、十分うまくコントロールできてこそ道具としての実用性を満たす。使用者のスキルが確保できるかや、必要以上のスペックでないかどうかは、慎重に見極めなければならないと思う。

ただし、反対派の意見が「梃子の力が大きすぎて危険だ」の後にこう続くことに対して、ぼくは疑問を提出する。つまり、「梃子を使うのをやめて、もっと労働集約的な方法に切り替えよう」という意見だ。梃子が危険で、十分注意すべき対象であることにはぼくも同意する。しかし、だからといって梃子そのものの使用を否定したり、梃子の力のほとんどすべてをスポイルするやり方は、どうも違うのではないか。

使用者のスキルや、コントロール能力について不安があるのは分かる。だからそれは「十分に」注意して扱う必要がある。ただその問題への対策は、梃子の設計とは別の部分でやってはどうだろうか。梃子は梃子としての性能設計をきちんとデザインして、それをコントロールする部分や運用する部分に労働集約的手法を適用できないだろうか。そのほうが健全ではないだろうか。

ごめんなさい。

　「読んでもらえれば分かります」。記者という職業にとって、これは「禁句」である。いくら素晴らしい内容の記事でも、読んでもらえなければ無価値。だから記者は、見出しに最大の努力を払わなければならない。読者が雑誌や新聞をめくって、パッと目に入ってくるのは見出しだからだ。記事レイアウトの見やすさ、図や写真の的確さも欠かせない要素だ。

なぜ「見た目」にこだわらないのか、IT部門の大きな勘違い：ITpro

よくもまぁ、こんな阿呆なことを書くよなぁ。「見た目」と「記事レイアウトの見やすさ、図や写真の的確さ」は別の問題じゃないか。前半と後半で論点のつながりがない適当な記事。記事全体から、欺瞞があふれだしているように感じる。そういう考えでいるから、その場だけウケがよかったり、キャッチーな絵が用意できたセンセーショナルな記事ばっかりになるんじゃないか。地味だけど周知が必要な記事をもくもくと作ることも大事。良い読者は、地味だけど価値があるような記事を見分けることができるし、そういう読者を増やさなければならない。メディアの役割とは何か？ その場だけ読者を煽って、話題を提供して、楽しませればそれでよいのか？ 読者を育てることが大事なんじゃないのか？ なんのためにメディアは存在するのか？ それがさっぱり抜け落ちてる。魚を与えるだけというのでは駄目だ。魚の釣り方を教えるような記事を書いてほしい。

えーと。このサーバーのデータを2月9日ごろに誤って消してしまい、ようやっとmomoka.cgiの分を復旧しました。あとは、momokam.cgiよりも昔に書いていた日記（yaswiki2.cgiとyaswiki.cgi）も復旧したいのだけど、データがどこかに残っているか分からない状態です。もし復旧できなかったらごめんなさい。（なにより、皆さんからいただいたコメントなどがなくなるのが心苦しいです）

で、今回の顛末ですけど、次のような感じです。

・最近デジカメで遊んでいるのだけど、ノートパソコンのハードディスク容量が足りなくなってきた
・そこで、サーバーのハードディスクを整理して空き容量を増やし、そこに画像を置こうと思った
・うちのサーバーは伝統的に4つのパーティションに分けて使っている。それぞれのパーティションの役割は、(1)OSエリア1、(2)OSエリア2、(3)スワップ領域、(4)データやホームディレクトリなどを置く場所。こうやっておくと、新しいOSが出るたびに(1)と(2)に交互にインストールできて便利なのです
・ところが、(4)はあまり整理されておらず、バックアップ用データやワークエリアなど、いくつかの用途のファイルが混在していた
・このたび、ディスク容量を増やすにあたって(4)のディレクトリのworkというディレクトリのゴミ掃除をまず行うことにした。具体的には、雑誌のCD-ROMの付録データだとか、ほかのディレクトリにも存在しているような重複ファイルだとかを削除しようとした（重複ファイルの検出にはMD5を使用）
・一方そのころ、momoka.cgiなどを置いている/homeディレクトリは、(4)のworkの下にあるhomeというディレクトリを実体としたシンボリックリンクとしていた
・掃除対象のディレクトリでMD5を実行したところ、「そのディレクトリに存在するすべてのファイルが重複ファイルである（/homeにも同じファイルが存在する）」と報告してきた。（この作業には簡単なスクリプトを回した）
・「おーそうかそうか。たぶんバックアップ用として一時的にまるまるコピーしたファイルなんだろう」と思ってrm -fRした。
・/homeがなくなった
・サーバーではRAID 1構成を組んでおり「オペミスしない限りデータはなくならない。バックアップ取らなくてよかんべ」と思って全然バックアップを取っていなかった。

まーこんな感じです。トホホ。。

ぼくは昔からバージョン管理システムが好きで、定期的に新しいのを試したくなる。ただまぁ、使ってみてもすぐ飽きて長続きしないのだけど……。ここ最近はdarcsを使っていたが、なにやらMercurialの評判がよいみたいなので使ってみた。

ちょっと試してみた感じではけっこう使用感がいい。Mercurialの仕組みについては下記の文章を読むとどういうものか分かる。

リモートリポジトリ
http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-remote.html

読み下すとこういう感じ。
(1)分散バージョン管理システムなので、n対n型でリポジトリが存在する
(2)リポジトリ間の同期は、pull（先方のデータを手元にマージ）とpush（手元のデータを先方にマージ）で行う
(3)基本的に選択的マージをしない。pullやpushをすると、先方と手元のあいだの差分がすべてマージされる。「先方のコードは欲しいけどこの部分だけマージしたくない」と思ってもそれをサポートする機能がない
(4)ただし、pushやpullは明示的にどこかのリポジトリを指定して行う（デフォルトでは直接の親がpullやpushの対象となる）ので、「リポジトリAからばかりpullする」みたいなことが起こり親子関係、上流・下流の関係ができる。

(3)の特徴によって、分散リポジトリ全体で1つのコードを作るというエネルギーが発生する。一方で(4)の特徴を使えば、あるノードを中心としてブランチコードをもっぱら開発することができる。収縮と発散の仕組みがうまくシステムに取り込まれていて面白い。

ところで（でくるで）、こういうツールのことを勉強するのって楽しい。なんかこう、ドラゴンボールで修行して強くなるとか、北斗の拳で新しい技を覚えるのとか、そういうのに似てる。新しい道具を使いこなせるようになると、自分が強くなるような気がしてそういうのが楽しいんじゃないかなと思った。