昨日、atimeについての「Linuxキーワード」の記事を送った。元々、金曜日が締切りだったのだがすっかり忘れていて、休日出勤している編集部の方からの連絡で急きょ書き上げたものである。ところが今日公開された文章を見ると、relatimeの説明部分が次のようになっていた。
同オプションを指定すると，「ファイル・データの変更時刻」（mtime）か「ファイル状態の変更時刻」（ctime）のどちらかがより古い場合だけ，atimeを更新します。
ぎゃー！意味が変わっとる！ 強調した部分は元原稿では「どちらかより古い場合だけ」と書いていた。これが意味が分かり辛いという質問を受けたので、編集部に「こういう意味です」と意図を説明したのだが、説明がうまくなかったのか意味を逆に取られてしまったようだ。分かり辛い原稿を書いて、しかも確認を怠った私のミスである。元原稿のままにするか、「どちらかより（atimeが）古い場合だけ」と修正するようにお願いしたので、いずれ直ると思う。間違った情報を広めてしまって申し訳ありません。
しかしいつもこんなのばっかだな。私は…。
7 件のコメント:
はじめてコメントいたします。
btrfs vs zfs のプチ騒動(?)のときから心配して見ていましたが、誤読や誤解を誘発しやすい修辞技法で記事をお書きになっているのが根本的な問題なのではないでしょうか。
今回の件にしても実際にITProの編集の方が誤読してしまったわけですし、正直 mount(8) の英語 man page での
Access time is only updated if the previous access time was earlier than the current modify or change time.
の記述のほうが私には分かりやすいです。限られた時間で字数を埋めるためには今の修辞技法は有効かもしれませんが、簡潔に本質をまとめるというスタイルへ転換することが必要なのかもしれません。
一読者として今後の奮闘に期待申し上げます。
要は私の頭がおかしいんですよ。「できるだけわかりやすく」という気持ちが空回りして、かえって分かりづらくなるという悪循環に陥っています。ダメな奴は何やってもダメという見本みたいなもんです。猫さえいなければ、すぐにでも死にたいです
ちょっと極端なコメントを書き過ぎましたが、冷静に考えても「本質を簡潔にまとめられず」「誤読や誤解を誘発しやすい文章を書く」ライターなんて害悪だけの存在でしょう。奮闘すればするだけ世間に迷惑をかけるわけです。ちなみに私は現在、文字数ベースで原稿料をもらっているわけではありません。冗長で無駄な表現は、私が糞のような頭で「こう説明した方が分かりやすいだろう」と思って書き加えたものです。実際は、ご指摘のようにそれがノイズとなって、かえって理解を妨げているわけです。
なにもそこまで悲観的になられる必要はなく、ちょっとした努力と工夫で十分克服できる問題ではないかと思います。
具体的に atime の場合で考えてみますと掲載先は「Linuxキーワード」という小辞典的なコーナーですので、かなりライトに
・ファイルへのアクセス時刻を記録する管理情報で一般的には inode に記録される
・tmpwatch, find ( atimeオプション ), mutt などのソフトウェアで使用される
・しばしば noatime オプションによる atime 更新を省略するチューニングが行われる
という程度で十分だったように思います。今回問題になった部分はばっさりカットされることになりますが、この部分についてはさらに吟味を重ねたうえで「Linuxカーネルの新機能」の次のネタにまわす位で、「Linuxキーワード」に押し込めるのはいささか窮屈だったのかもしれません。
いわば「引き算でのブラッシュアップ」なのですが、伝えたい内容のうち1割2割でも伝われば儲けものだと割り切りきってしまうのはどうでしょうか?
個人的には日経Linux6月号の「Linuxカーネルの新機能」が表現したいことと文章量のバランスがとれていたように思います。
具体的なご提案ありがとうございます。しかしご指摘の問題は内容ではなく「表現」なわけです。「誤解や誤読を誘発しやすい修辞技法」なのですから，書く内容を削るという方向では本質的な解決にはなりません。むろん「書く量」が減れば，問題は少なくなるのでしょうが，この程度の分量でダメならダメなわけです。しかも「Linuxキーワード」において「relatime」は外せない内容です。なにしろデフォルト動作になるわけですから。本当はFedoraやUbuntuですでにデフォルトになっていることも書きたかったのですが，それを削ったほどです。「Access time is only updated if the previous access time was earlier than the current modify or change time.」という分かりやすい表現を「同オプションを指定すると，「ファイル・データの変更時刻」（mtime）か「ファイル状態の変更時刻」（ctime）のどちらかより古い場合だけ，atimeを更新します。」と糞のような文章にしたことがそもそもの問題なのだと思います。
ITProのサイトのほうに修正が入ったのでこの話題を引っ張っても仕方がない感がありますが、もう少し続けさせてください。
書く内容を減らすというのは、減らすことによって生まれた余裕をより分かりやすい表現へ推敲することに振り向けてはどうでしょうかという提案です。relatime が重要だというのであればむしろ独立した項目として記事を作るよう逆提案してみる価値があるのではないでしょうか。
問題となった部分が分かりづらい表現に見えるのは原因として
・ctime mtime についての記事が未掲載で短いながら説明が必要な状況となっており、それによってかかり受けの見通しが悪くなってしまっている
・(修正されましたが)ctime mtime と比較対象になる atime について当初の原稿で省略してしまったので、比較構造がとりづらくなってしまっていた
というところだと思います。試しに ctime mtime の説明を省いて書いてみると
『同オプションを指定すると，mtime か ctimeのどちらかより古い場合だけ，atimeを更新します。』
となり、非常にスッキリしましたが、やはり previous access time に相当する部分が省略されると比較構造がわかりづらく見えてしまいます。
この部分が登場するまでに、かなりの説明が中に入れられていることもあり、そういったことも誤読を誘う一因だったのではないかと思います。
個人的な印象で申し訳ないのですが、ものすごく何かに追い立てられて焦っていろいろなことを盛り込み、その結果自滅しちゃっているように感じてしまうのです。
スタイルが違いすぎるかもしれませんが、結城浩さんのようなおちついた空気感を出せるようになると、ライターとしての格が出てくるのではないでしょうか。
また、入稿前に親身にレビューしてくれるような方を作るのも手かもしれません。
過ぎたことは仕方ありませんので、これから良い記事を書くためにどのような要素が必要なのかを前向き(これ重要)に模索してみてはいかがでしょうか。
ありがとうございます。いただいた解説によって、元の私の文章がいかにひどかったかが再認識できました。誤解を受けないように省略をしないこと，語句解説の位置について何とかうまい解決策を見つけることの2点を意識していこうと思います。語句解説は個人的な好みで言うと、最初に簡潔な文章を出して、あとで説明するスタイルが好きなのですが、「見知らぬ単語は出た時点で解説すべし」というルールがあるのでなかなか悩ましいところです。ですが、今回の原稿で言えば、ctime、mtimeを最初にatimeと一緒に解説しちゃえば良かったわけで、仰るように「推敲不足」の一言に尽きますね。せめて人並レベルの文章が書けるところまでは持って行きたいと思います。なんとも低レベルな目標ですが…。
コメントを投稿