ドライイースト（カメリヤ vs サフ）

昔から朝食はパンでした。過去にはスーパーで食パンを買っていましたが、約10年前にホームベーカリーを購入したので、それからは自宅で焼くようになりました。食パンさえ焼ければ十分で、しかも材料には拘りがありません。

Webで情報を探すと、小麦粉やイーストの銘柄の違いを云々する記事が見当たります。材料を変えることで、出来上がる食パン自体に違いが出るとは思います。しかし出来上がりの違いは材料の違いだけではないだろうと思っていて、いかに「厳選」された材料を取り揃えようとも、それだけで自動的に「最高」の食パンが出来上がるわけでもないのではないかと考えています。

焼きあがった食パンを食べてみれば「美味しい！」と思うかもしれませんが、それは「厳選」された材料を使っているからとは限らず、自分が手間をかけた事を知っているという心理的なバイアスの効果かもしれません。

こういう訳で（極端に言えば）材料は何でも良いと思っているのですが、COVID-19の影響により、スーパーの店頭から強力粉やドライイーストが姿を消しました。報道によると、外出自粛により自宅でパンを焼こうとする人が増えていて、売り切れるスーパーが増えているようです。いつも行っているスーパーの店頭でも、ドライイーストや強力粉が置いてある棚だけがガラガラでした。

まだ自宅に手持ち分があるので、それほど焦る必要はないのですが、この状況が何時まで続くか不明なので、長期化した場合に備えて、買える時には買っておこうかと考えていました。いつも行くスーパーで取り扱っているドライイーストが「カメリヤ」だったので、これまで長い間にわたってカメリヤを使っていました。ふと別の店でドライイーストを探して見たら「サフ」を見つけました。

サフのドライイーストは、Web記事で言及している事があるので、知ってはいましたが、現物を見たのは初めてでした。カメリヤよりは高価ですが、購入を諦めるほど高価という訳ではありません。たまには別のドライイーストを使ってみるのも興味深いかと買ってみようかとも思いましたが、いつも行くスーパーでドライイーストの供給が増えたらしくカメリヤが店頭に並ぶようになったので、結局サフは買わずじまいです。

Web記事によると、サフを使うと、食パンの膨らみが良くないことがあるとか、焼きあがった食パンがしっとりしているとか、数々の感想を読むことができます。これらは多分に主観的な表現なので、いざ自分がサフを使って食パンを焼いたとしても、カメリヤとの違いが出るか、さらに気付くかということは、なんとも言えません。

食パンの主たる材料は「小麦粉」です。他にもバターとか砂糖とか、小麦粉以外の材料が必要となりますが、ドライイーストも主役ではないだろうと思います。ドライイーストが、ただの端役なのか、主要な（?）脇役なのか、その役割の大きさは不明です。いつもと同じ廉価な強力粉を使っていながら、ドライイーストをサフに変えただけで、ほっぺたが落ちるような（!）美味しさに、劇的に変化するとも思えません。

ホームベーカリーで焼いた食パンが、美味しいか否かということは主観的に判断することになるので、Web上の記事を何百本読もうとも、結局は自分がどう感じたかということに過ぎません。自分で使ってみて、Web記事に書いてあった通りだと思うかもしれないし、そうは思わないと感じるかもしれません。

そういう訳で、手持ちの（カメリヤの）ドライイーストを使い切ったら、サフを使ってみて、自分自身で体験してみようと思います。

Ganglia Monitoring Systemにおけるpythonメトリックのname属性

マシン環境をモニターするためのOSSとして「Ganglia Monitoring System」があります。標準的な構成を何も変更しないでインストールして利用しても構いませんが、独自にメトリックを作成してマシン環境を参照する事もできます。独自メトリックを自作するにはpythonを使用しますが、作成の仕方のコツを掴めば、作るのはそれほど難しくありません。

メトリックの処理はpythonで組みますが、メトリックの構成を規定するためにディスクリプタを初期化時に返す必要があります。その中には属性「name」があり、これが作成しているメトリックの名前となります。その名前規約として認められる文字長や文字種が明白に定義されている訳ではないようなので、時として問題が起きる場合があります。

名前に半角の英数字を使っているだけなら、別に問題は起きないと思います。また、記号類として、下線文字やハイフンを使う程度なら、差し支えないでしょう。

しかしながら記号類として「/」を使おうとしたら、問題が起きました。属性「name」で指定された文字列は、内部的にはRRDデータベースのファイル名として使われるようです。このために属性「name」において文字「/」が使われると、RRDデータベースのファイル名においてパス名が狂ってしまうようです。

他にも属性「name」に文字「%」が使われるのも、問題を起こす原因となり得るようです。GangliaのWebインターフェイスでは、属性「name」の情報がURLの中に現れます。その時に文字「%」があり、その文字の直後にある2文字が「16進数」を表す文字にマッチしてしまうと、URLエンコードにより別の文字として扱われてしまいます。

これ以外にも問題となる文字があるのか、もうこれだけなのかは、分かりません。しかも、今回問題となった文字が、Gangliaの内部構造の変更により、将来的には問題とならない可能性もあります。OSSはドキュメント類の不備をソースコードを参照する事で補う場合があるので、問題があれば調査して原因を突き止めることは（原理的には）可能です。しかし問題が本来どうあるべきかを知ることは容易ではないでしょう。OSSを利用する際には、そのような事も意識する必要があるのではないかと思います。

Don't catch a cold.

The Japan Times Alphaで連載されているコラム「Odds & Ends」の2020年4月17日号のタイトルは「Health 3 Getting sick」でした。この中では、日本人は「Don't catch a cold.」とよく言うと書かれています。しかし英語圏ネイティブでは、このような表現をすることはなく、「Take care of yourself.」と言うのだと書かれています。さらに次のようにも書かれています。

Whenever I hear "Don't catch a cold," it reminds me of a mother talking to her small child.

コラムの著者も気付いているようですが、日本人が「Don't catch a cold.」という表現をするのは、日本語で「風邪を引かないで」とよく言うからです。日本人が日本語でそのような表現をすることは別に構わないのですが、日本人は英語で「Take care of yourself.」という表現を使うことを知らないのです。知らないから、日本語を英語に直訳したような表現になってしまうのです。その英語表現が、英語として破綻しているなら誤りに気付くところですが、英語でもそのような表現をしないわけではないようなので、単純な正誤の問題として考えることはできません。

よく笑い話になることですが、日本人は「お疲れ様です」のような表現をつかいますが、これを英語に直訳して「You must be tired.」と表現する人がいるようです（本当に居るのかどうかはわかりませんが）。この表現も英語構文的には誤りではないかもしれませんが、英語圏ネイティブが耳にすると、あまりの違和感にギョッとするようです。

日本語と英語の関係に限らず、自国語と外国語の翻訳においては、「意図の変換」をおこなう必要があるだろうと思います。

「空間」と「時間」という感性の形式

NHKで放映されている番組「100分 de 名著」の2020年6月のテーマは「カント 純粋理性批判」です。当初の予定では2020年5月に放映されるハズでしたが、COVID-19で制作が影響を受けたようで1ヵ月延期となりました。

NHK出版から出ているテキストでは、34頁に次のような記述があります。

「空間」と「時間」という感性の形式（感性にもともと備わった二つのフレーム）を抜きにして、事物を捉えることはできません。

「純粋理性批判」というのはイマヌエル・カント（1724～1804）の代表作で、難解な著作としても有名です。もっともこの書籍に限らず、哲学の書籍は、どれも難しいという印象を持つ人が多いでしょう。

話を戻して、「純粋理性批判」の解説の中で「感性の形式（空間と時間）」という説明が現れた事には驚きました。「空間と時間」というキーワードから思いつくのはアインシュタイン（1879～1955）による相対論における4次元空間（3次元空間+時間）の事です。

私たちが生きている世界は「3次元空間」なので、次元を落として「2次元空間（平面）」とか「1次元空間（直線）」を理解することは容易です。しかし次元を上げることは直観として理解できないし、図示することも不可能です。しかし相対論では「3次元空間」の次元を上げると「時間」を加えて「4次元空間」で理論を組み立てています。

カントは哲学であり、アインシュタインは物理学です。両者は時代が違いますし、学問分野も全く違うので、双方に交流があったとも思えません。そうでありながら、「空間」と「時間」を組み合わせることに自然な繋がりをみていることには、驚きを感じます。

お好み焼き（Japanese pizza）

The Japan Times on Sundayの2020年2月16日号に掲載されているエッセイ「Big in Japan by Mark Schreiber」のタイトルは「New outlets weigh whether new virus will affect Olympics」でした。その本旨から離れますが、文章の最後付近に次のような記述がありました。

127,000 tons of frozen processed foods such as okonomiyaki (Japanese pizza) and fried chicken parts (annual figures for 2018).

この文を見て気付いたのは、「お好み焼き」を「Japanese pizza」と訳していることです。

翻訳において訳語の選択は難しい問題だとは思います。世界中どこにでもあるようなものであれば、日本語で使われているある単語を英語で使われているその単語に置き換えることができるでしょう。しかし日本独自のもの（ここでは「お好み焼き」のようなもの）であれば、対応するものが英語圏に存在しないので、ローマ字（「okonomiyaki」のように）するしかないでしょう。多分それでは英語読者にとっては何のことか分からないだろうから「Japanese pizza」のように補足するのでしょう。「Japanese pizza」が適切な補足になっているかどうかは議論のあるところかもしれませんが、そのような表現で説明するという発想は新鮮でした。

CANON MG3130のメンテナンス

Microsoft Windowsに繋いでいるプリンタはCANON MG3130です。購入した時期は忘れてしまいましたが、この製品は2011年モデルらしいので、もう10年弱ほど使っていると思います。本体価格に対して、インクの値段が高いのが気になっています。しかしプリンタ業界のビジネスモデルはインクで稼ぐらしいので、不満ではありますが、どうしようもありません。

それはさておき、1～2週間ほど前から印字が崩れるようになってきました。崩れる形態は様々ですが、（変な例えかもしれませんが）3D画像を専用メガネを使わずに見た時のようにブレていたり、また表の罫線がガタガタにずれてしまっていたりします。

Webを検索すると、印字調整をすると直る（ことがある）そうです。操作ガイドを参照しながら、印字調整をおこなってみましたが、全く復旧しません。そもそも印字調整用のパターン印刷自体が乱れまくっていて、これで本当に調整できるのだろうかと心配になるほどです。たまたま調子が悪かったのかもしれないと思って、何度も実行してみましたが、何度やっても駄目でした。

印刷が不良になったのは最近の出来事ですが、もう数か月前から用紙のローディングでも不調だったので、もしかすると寿命なのかもしれません。買い替える時期が来たのでしょう。それはそれでも仕方のないことですが、残念なことに最近プリンタインクを買ったばかりなのです。インクが無くなった時にすぐに印刷を継続できるようにするため、常に在庫を確保しておくようにしています。それが残っているのです。

MG3130のインクはBC-340/341ですが、大容量モデルBC-340XL/341XLを持っています。まだ開封していないので、プリンタを買い替えたら無駄になってしまいます。CANONで現在販売中のモデルでBC-340XL/341XLを利用できる製品は無いようです。

もし買い替えるとしてCANONならTS5330にしようか考えていました。1万円ちょっとで買えるようです。インクも必要になるし、想定外の出費です。なんとかMG3130を使い続ける方法はないかと、Webを検索してみました。

CANONのWebサイトでFAQを見ていたら「エンコーダーフィルムの汚れを確認し、汚れている場合は清掃してください」という情報がありました。さらに「【インクジェットプリンター】《動画》エンコーダフィルム清掃方法(MG4230/MG4130/MG3630/MG3530/MG3230/MG3130/MG2130/MX523/MX513)」で動画付きで説明されています。

そもそも「エンコーダフィルム」というのが何処の事なのかよく分からなかったのですが、動画の手順に従いクリーニングしてみました。紙コップに中性洗剤を入れた水を用意して、綿棒につけて汚れを落としてみました。購入依頼クリーニングをしたことが一度もないので、綿棒はすぐに汚れで黒くなってしまいます。綿棒を10本ほど交換しながら、綺麗になったと自己判断するまで汚れを落としました。

そして改めて印字調整シートを印刷してみたら、見違えるように綺麗な（まともな）調整シートがプリントされました。さらに印刷も試してみたら、今までの異常な印字が見違えるように普通に戻りました。クリーニングした効果があったようです。

CANONのFAQでは「プリンターはエンコーダーフィルムによりFINEカートリッジホルダーの位置を検出しています。」とも書かれています。汚れが酷かったので、印字位置が狂っていたのかもしれません。

これでプリンタを買い直す必要はなくなりました。MG3130は今後も使い続けられそうです。

/usr/binを何と読む

Webを見ていたら「人によって読み方が違うことが多いテクノロジー用語、どんなものがある？」という記事をみかけました。読み方に差が生じる用語は多くあると思います。この記事にある「Linux」についても「リナックス」と読む人と「ライナックス」と読む人がいて、僕自身は「ライナックス」と読むことが多いです。

この記事を見て思い出したのが、/usr/binなどの「bin」を何と読むかです。僕は「ビン」と読みますし、そう読む人が多いようです。しかし「バイン」と読む人がいました。本人に何故そう読むか尋ねたところ、この「bin」というのは「binary」の略だと思うので、「バイナリ」を略して「バイン」と呼んでいる、と答えていました。この理屈は理解できなくもありませんが、僕自身の読み方が「ビン」から「バイン」に変える気持ちにはなりませんでした。

別な例を出せば、/etcの「etc」は何とよむでしょうか。僕は「エトセ」と読みます。何故なら「etc」は「et cetera」の略だと思うからです。これは上述した理屈と同じ発想です。だったら「bin」を「バイン」と読むように転向してもよさそうなところなのですが、そのつもりはないのです。人間の心はなんと不思議なのでしょうか。