git で過去コミットを修正する

Git でバージョン・コントロールをしていて、時々、古いコミットで入れてしまったバグを見つけることがある。その解決方法。
本エントリーの内容は、Git ユーザマニュアル (バージョン 1.5.3 以降用) のほとんどコピーと言っていい。このマニュアル大き過ぎる。すぐにバグ修正したい時に、肝心の部分へ辿りつくのが大変。なので、自分用のエントリーにしてみる次第。

下調べ

バグのあるコミットは、どこかの集中リポジトリーに git push されていないこと。もし、git push されていると、整合性が取れなくなるので、この作業はしないこと。その場合は、素直にリポジトリーのヘッドにバグ修正のコミットを追加する。

前提

バグは、トピック・ブランチ new-feature の中で入れたこととする。
バグを入れたコミットのハッシュ値は 123456789... とする。
ハッシュ値は gitk もしくは git log と git show を使って調べられる。

修正作業

まず、バグを入れたコミットに bad というタグを付ける。

$ git tag bad 123456789

次に、バグの入ったコミットをチェック・アウト。エディターでバグ部分を修正する。

$ git checkout bad
$ emacs ... (修正)

修正が終わったら、git commit --amend で古いコミット (及びコミット・ログ) を上書きする。

$ git add -u
$ git commit --amend

コミットしたら git rebase コマンドでブランチを書き換える (正確には、「バグ入りコミット」を「修正済コミット」で置き換えている)。

$ git rebase --onto HEAD bad new-feature

--onto HEAD でブランチの先頭に戻ることを指定。new-feature は今いるブランチ名ね。ブランチを分けて開発していない場合は、通常 master がブランチ名になっているはず (ここら辺は git branch コマンドで確認すること)。
最後に、不要な bad タグを削除する。

$ git tag -d bad

トピック・ブランチについて

新機能を追加する際などは、その新機能ごとにブランチを作るといい。そして、新機能の目途が立ったら master ブランチにマージ (もしくは rebase) する。この様に、一つのトピック (今回の場合「新機能」) ごとに作るブランチを特にトピック・ブランチと呼ぶ。
もちろん、トピック・ブランチは「新機能」に限らない。大幅なバグ修正、機能変更、ドキュメントの書き直し etc. 様々な場面で使える。メリットは以下の通り:

• master ブランチの HEAD が常に安定している
• 複数のトピック・ブランチを持つことで、トピックごとの変更分を意識できる

例えば、トピック・ブランチ開発中でコードが不安定になっていても、必要ならすぐに安定した master ブランチに戻れる。「新機能」と「バグ修正」のトピックをブランチに分けることで、ブランチごとの安定度が高まる。新機能で 2 つ以上の方法がある場合も、複数のトピック・ブランチを使って両方のコードを書いてベンチマークを取れる。
今回のバグ修正に関しても、git rebase で conflict が起きたりする場合もあるので、できれば master ブランチ上ではやりたくない。
git は簡単にブランチの作成・統合・削除ができるので、どんどん活用するのが良いと思う。

参考サイト

• Git ユーザマニュアル (バージョン 1.5.3 以降用) — 1 つのコミットを再編集する

mew-absfilter.el が mew-contrib に含まれた

先日 mew-absfilter.el が github に公開されたと書いた。

• clmemo@aka: mew-absfilter.el 復活

このたび、その mew-absfilter.el が mew-contrib (@github) に含まれることになった。mew-contrib は Mew を便利に使うために有志が公開した mew のための EmacsLisp を含めたリポジトリー。管理者は Mew の開発者・山本さん。

• kazu-yamamoto/mew-contrib - GitHub
• kazu-yamamoto/Mew - GitHub (Mew 本家)

mew-contrib には、スパム・フィルターである mew-absfilter の他にも、mew から Namazu 検索するための mew-nmz、mew からウェブ・ブラウザーを開くための mew-browse などが含まれている。

Mew を使う人には、mew-contrib を是非チェックして欲しい。

Firefox 4 の MathML 対応が素晴らしいことになってる

数式を HTML の中で使う試みとして MathML が挙げられる。MathML は XML アプリケーションの一つで、数学記号を含めて高度な数式表現を可能にする。数式エディターで描いた数式を画像化して貼り付けたりしなくて良くなるわけ。

期待度の高い MathML だけれども、ブラウザー側の対応が進んでいない。

その中にあって、Firefox 4 が一歩先じている。どれ位い数式が描けるのかを誇示するために、ウェブ・ページを作っているので覗いてみて欲しい。

• MathML in Action

Firefox 4.0.1 で上記ウェブページを開いた時のスクリーン・ショットをお見せする。

LaTeX には及ばないけれども、非常に高度な数式が描けているのが見て取れる。

一方、Google Chrome の開発版 (14.0.794.0 dev) でこのページを見るとどうなるか。

見事に壊滅的。MathML の「マ」の字もサポートしていない (;_;)。

他のウェブ・ブラウザー (IE, Safira, Opera) は試していないので、もし興味を持たれたら比べてみるのも一興かと。

あとがき

ぼくは TeX からプログラムの世界に入った様な人間なので、数式を美しく表現できるだけで嬉しくなってしまう。正直、MathML なんて数式表現がちょこっと上品になっただけだと侮っていた。今回、Firefox の完成度を見るに、認識を改めないといけないと痛感した。

Firefox に続いて、Webkit, Opera が一日も早く MathML 対応してくれることを望む。IE は... ごめん。期待していない。

オーディオ・オフ会 黒川邸訪問

Phile-web コミュニティで有名な黒川さんのお宅にお邪魔してきた。3 時間たっぷりと音楽をきかせてもらったので、感想を書く。

黒川さんのメイン・システム

黒川さんは 3 つのオーディオ・システムを所有している。その詳細は自身のブログで公開なさっているが、自分用のメモに本エントリーにもメイン・システムの構成をコピーしておく。

• LP プレーヤー
  • プレーヤー: AMAZON SYSTEM AMAZON 2
  • トーンアーム: Mørch UP-4
  • カートリッジ: BENZ MICRO GLIDER SL
  • フォノイコライザー: EINSTEIN The Little Big Phono
• CD プレーヤー
  • CD プレーヤー: LINN IKEMI (アイケミ)
  • DAC: Wadia Digital DM-X32
• アンプ & スピーカー
  • プリ・アンプ: CELLO ENCORE 1MΩ
  • パワー・アンプ: CELLO ENCORE POWER MONO x2
  • スピーカー: PENAUDIO CHARISMA+CHARA COMPLETE SYSTEM
  • スーパー・ツィーター: TAKET TAKET-BATPURE C set

なお、セカンド・システムは PC 用、サード・システムは DVD 鑑賞用という風に使い分けておられる様子。ぼくは一つのオーディオ・システムで全部をやろうとしてしまうので、こういう割り切り方にはアッと思わされた。目的を明確にしているから、コスト・パフォーマンスが高い。音楽を楽しむことに達感されているんでせう。

黒川さんとの出会い

黒川さんを知ったのは Primare が切っ掛けだった。

2008 年 1 月。ぼくは Primare I30 というアンプを買った。その時、ネットで Primare のアンプについて検索した。ところが、Primare はスウェーデンのアンプで、あまり日本では有名でないらしい。ブログで記事を書いている人がほとんどいなかった。

そんな中、とても丁寧に Primare I21 (I30 の一つ下の機種) の記事を書いている方がいらっしゃった。それが黒川さんだった (現在、Primare I21 は手離されたようだけれども)。

• re:CC: Primare I21

この方とは、オーディオの方向性が合うんじゃないかしらん。そう思って、以来、ずっとブログを購読していた。

その後、Twitter などでお話しする機会を得て、黒川邸訪問と相成った。

メイン・システムの音

黒川さんのメイン・システムで一番気になっていたのがスピーカー Penaudio Charisma + Chara。というのも、ぼくは北欧系のメーカーが好き。そして Penaudio はフィンランドのスピーカー・メーカー。気になってしょうがない。一度、友達が Charisma だけ試聴のため借りたことがあったけれども、その時も押しかけて聞いたほど。

ここで脱線するけれども、Charisma + Chara について少し紹介しておく。Charisma はブックシェルフ型スピーカーで 50 万円程。交響曲をかけると、オーケストラがスピーカーの後ろ側に展開する様に聞こえる。加えて、楽器の位置がピタリと定まる。音のキレもある。オーディオ的に言えば、音場表現が豊かで、後ろ側に自然に展開し、音像定位が素晴らしく、スピードが速い。欠点を挙げれば低音が強くないこと (ブックシェルフ型の宿命かな...)。

そこで Chara が登場する。Chara は Charisma とくっついて、ブックシェルフ型の Charisma をトールボーイ型へと進化させる。Chara は Charisma のスピーカー・スタンドとなると同時に、片側面にウーファーを持っていて Charisma に足りない低音を補う役目を果たす。Chara の値段も 50 万円程度。Charisma + Chara で 100 万弱のスピーカー・システムになる。

写真は、Penaudio の Charisma + Chara の左スピーカーを撮影したもの。側面に見える灰色部分がウーファー。

閑話休題。

黒川さんのメイン・システムで音楽を聞く。まずは黒川さん選曲から一枚。エンリコ・オノフリの「驚愕のバロック・ヴァイオリン」からヴァイオリン編曲されたバッハの「トッカータとフーガ 二短調」。

CD は DAC を通さず、直接 CD プレーヤーから再生する。CD をトレイに置くときに黒川さん曰く、「低音がボワついているんですよ」。そして音楽がかかる。

Charisma 単体で聞いた時の印象は全く損われていない。素晴らしい音場表現。素晴らしい音像定位。友人宅で聞いた時よりも、元気に聞こえる。これは、アンプと電源が良いからでせう。そして、SN が非常に高い。小さな音が非常にクリアに聞こえる (あとで 1950 年録音 [モノラル] のピアノ曲を聞かせてもらったが、とてもピアノの音が澄んでいてウットリした)。

黒川さん懸念の低音。Charisma 単体で聞いた時よりも低音が出ていて楽しい。ただ、黒川さんがおっしゃる通り、少し低音に締まりがない。あとで聞かせてもらったオーケストラ曲では、特にチェロの低音で音階がちゃんと表現されていなかった。

黒川さんは続けて、CD プレーヤーとプリ・アンプの間に Wadia の DAC をかませた。すると、グッと低音がキビキビした音になった。これはイイ。ところが黒川さんによると、「DAC を入れると低音が締まる。だから、ロック系の音楽には DAC を使う。けれど、弦楽器などの艶やかさが失われる。だからクラシック音楽には DAC を入れない。ところが、DAC を入れると逆に低音がふくらんでしまう CD もある」という。オーディオって難しい。

そして黒川さんがもう一枚クラシックの CD をかけた。「これが難しくってね」。そう言って流れてきたのは、ソプラノとパイプ・オルガンだけのクラシック曲。ソプラノの艶を優先すると DAC は入れたくないけれど、パイプ・オルガンの深い低音が動き回ると DAC を入れたくなる。

低音の扱いを DAC の有無でフォローする技を見せつけた上で、「難しい」という曲をかけるあたりに、黒川さんの誠実さを見た。

持参した CD

メモ代わりに、黒川邸でかけさせてもらった CD を載せておく。

かけた曲は (左から)、ベートーヴェンのコリオラン序曲。マイケル・ジャクソンの Bad のピアノ・トリオ・カヴァー。トランス・シベリアン・オーケストラの「Beethoven's Last Night」から Mephistopheles' Return。オーストリア・ミュージカル「エリザベート」から Die fröhliche Apokalypse。あと一枚。バッハのパルティータ全曲をギーゼキングが演奏した CD も持参したが、これは現在廃盤の模様。

あとがき

憧れの一つだった Penaudio の Charisma + Chara が「本気(?)」で鳴っている音を聞くことができた。嬉しくてしょうがない。黒川さんのメイン・システムはもう一つの完成をみている様に感じた。更に手を入れるとしたら、大きな家へ引っ越すくらいしかないんじゃないかしらん。それ位い練り上げられているオーディオ・システムだった。

蛇足: 他の人の訪問記

黒川さんは、ぼくなんかと違って多くの人の訪問を受けている。少し検索するだけで、その訪問記が現れる。ぼくの言葉足らずな面を補完してくれると思うので、訪問順に記事を並べておく。なお、日付は訪問日ではなくブログのエントリーが投稿された日付を記した。

• 2007-01-28: 黒川さん宅に訪問してきました。：うぃんの音楽を楽しむためのブログ：So-netブログ
• 2007-02-18: 黒川宅訪問記: 酩酊日記
• 2008-03-22: さもえどのオーディオ散財日誌: 黒川邸お宅訪問♪
• 2008-05-06: Phile-web コミュニティ - Electro Mania! - 黒川さんち訪問
• 2008-05-19: Phile-web コミュニティ - 50代半ばのオーディオ２年生 - 黒川様のお宅を訪問させて頂きました
• 2009-09-08: Phile-web コミュニティ - nissyのページ - 黒川邸訪問記です！

Twitter で 1,000 following 達成

twitter/at-aka でフォローしている人の数が、今日 (2011-06-20)、ついに 1,000 人に達した。

記念スクリーン・ショット。

Twitter を良く見る日もあれば、全く見ない一週間もあったりする。そんな Twitter の使い方をしているけれど、Google Reader に優るとも劣らない情報源となっているし、一種コミュニケーションの場となっている。とにかく楽しい。楽しいと思い始めたのは、フォロー数が 300 を越えた辺りからだったと思う。フォロー数が 1,000 を越えた今、また少しずつ Twitter の (自分の中での) 立ち位置が変わってくるのかな? また、それも楽しみ。

第 162 回 TOEIC の結果

TOEIC の成積が発表された (ref. 第 162 回 TOEIC を受験した)。

265 (Listening) + 290 (Reading) = 555

この前受けた第 159 回では、275 (L) + 240 (R) = 515 点だったので、Listening で 10 点下がり Reading が 50 点増したことになる。確かに、今回リスニングで聞き取りにくいことが多かった。それがそのまま点数に出た気がする。リーディングの点数が 50 点上がったのは、集中力が増したのが良かったのだと思う。

総合結果は 40 点の上昇。次回は 600 点越えを着実に狙いたいね。

過去の記録

• 162: 265 (L) + 290 (R) = 555
• 159: 275 (L) + 240 (R) = 515
• 109: ??? (L) + ??? (R) = 615

新 ViV Lab 試聴室を訪問した

2011-06-12 (日)、友人と一緒に ViV Laboratory の試聴室を訪問した。目的は ViV Lab が開発したトーンアーム「Rigid Float」の試聴。友人が興味を持ったので、(何度か ViV Lab にお邪魔したことのある) ぼくが日取りをセッティングすることになった。そういうわけで、今回の訪問、ぼくは黒衣に徹した (※トーンアームは LP プレーヤーの部品の名称。ぼくは LP 関係に手を出していないので難しいことは分からない...)。

• ref. clmemo@aka: VivLab の LP プレーヤー用アーム「リジットフロート」

ViV Lab を最後に訪ねたのは、2009 年の 12 月のこと。当時、ViV Lab は横浜は中華街近くのマンションの一室にあり、試聴室は部屋の一部を試聴用に転用しているものだった。大手メーカーの様に専用の試聴室でない代わりに、「自分の部屋に入れた時」の音が想像しやすい試聴室だった。

新試聴室

その後、ViV Lab は鎌倉市に引越した。新しい試聴室に行くのは今回が初めて。

大船駅からバスに乗り、約 20 分。「半僧坊下」で降車する。ViV Lab に電話すると、ViV Lab の中の人が迎えに来てくれた。降車場から試聴室までは、歩いて五分とかからない。

戸を開けて中に入り、細い通廊を抜けると試聴室があった。

床は大理石 (本物じゃないと思うけど)。部屋の壁は全体がコンクリートの打ちっぱなし。天丼は吹抜けになっいる様で、かなり高い。スピーカーを囲う様に、階段状のステージが展開する。写真には二段分しか写っていないけれど、実際はもっと多い。ちょっとしたアリーナの様にも見える。

以前の試聴室では、音量を大きくすると床がビリビリと震えた。「大理石にコンクリート! これなら部屋が鳴ることはないでしょう」と言うと、「ステージ状の木の部分が鳴っちゃうんですよ」とのこと。部屋造りは難しい。ちなみに、今回の試聴でそこまでの大音量を鳴らすことはなかった。

さて、ViV Lab のオーディオ・システムを聞いてみる。ViV Lab は三種類のスピーカーを発売しているが、今回使ったのは一番高い Evanui Signature (ペア・420 万円)。

オーディオの良さは、「部屋が 6 割、システム 4 割」なんて言われたりもすれけれど、Evanui もその例に洩れない様子。前回聞いた時は、低音がブーミーだったけれど新試聴室ではその傾向がなくなり、スマートに音が出ていた。その丁寧さが、少し迫力不足な感じもした。もう一点、Evanui は音場表現が素晴らしい。旧試聴室は部屋が狭かったので、部屋全体にオーケストラが展開していた。一方、新試聴室は部屋が大きくなった分、相対的にスケール感が小さくなった様に感じた。低音も音場表現も、新試聴室の方が良いのだけれども、旧試聴室との印象の違いにとまどった。

また、2009 年 12 月から比べて、Evanui Signature にも色々と手が加えられている。今回、「音が良くなった」のが新試聴室のおかげなのか? 新しい変更のおかげなのか? が分からなかった。ちと残念。

旧試聴室以来 ViV Lab を訪ねていない方は、まず試聴室による音の変化を知るためだけでも、ViV Lab を訪問する価値があると思う。

試聴ディスク

友人持参の LP を中心に試聴。バッハの無伴奏パルティータをグリュミオーが演奏したものとか色々と。

久し振りに聞く Evanui Signature。新試聴室でどう鳴るかをちゃんと測りたいところだったけれど、他人のディスクじゃ分かりづらい。一枚だけは自分が聞き込んだ CD を持って行くべきだったと反省した。

あとがき

この他にも、ブログには (まだ) 書けないことを沢山話した。というか、ブログに書けない話題の方が多くて困った。

結局、ViV Lab の新試聴室に関するレビューで落ち着かせた。興味を持った方は、遠いけれど ViV Lab を訪ねてみては如何か。

Blogger Redesigned のスクリーン・ショット

2011-04-19、Blogger の開発チームは新しいデザインの Blogger を開発中であるとブログに書いた。そして、Blogger in draft を使っている人達に向けて、新 Blogger の機能を少しずつ公開 (roll out) していくと伝えた。

• Blogger in Draft: Blogger, Redesigned

アナウンス後、大低、2〜3 週間で新機能が使える様になっていたものだけれども、今回の新版はかなりゆっくりとしたペースで公開されているらしい。ぼくはつい先週、新 UI になった Blogger と出会えた。しかし、例えば日本で中心的 Blogger 解説ブログを開いているクリボウさんはまだ新 UI に移行できていない。

そこで、新 UI のスクリーン・ショットだけでもお見せしようと思う。

トップ画面

ログイン画面は二列表示。左側は、自分が管理しているブログ一覧が表示される。「ダッシュボード」をクリックすると、各々のブログの管理画面へ入る。「新しい投稿」は「ダッシュボード」内にある投稿画面へのショートカット。

画面の右側は「読者になっているブログ」の一覧。一種のフィードリーダーか?

ダッシュボード — サマリー

ダッシュボードに入るとまず「サマリー」が表示される。サマリー項目は以下の通り:

• ページビュー (詳細は統計タブで見られる)
• Blogger からのお知らせ
• 更新情報 (確認待ちコメント、公開されているコメント、今日のページビュー、投稿、読者)
• 最近の注目ブログ
• Blogger ガイド

ダッシュボード — 投稿

ログイン画面から「新しい投稿」をクリックすると、このページにアクセスできる。投稿エディターは、WYSIWYG 型と HTML 編集型の二種類が用意されている。下のスクリーン・ショットは WYSIWYG エディター。

ラベル、スケジュール投稿、オプションがよりシンプルになっているのが分かる。スクリーン・ショットは「ラベル」をクリックしたところ。ラベル一覧はこんな風に表示される。

上のスクリーン・ショットは HTML エディター。「スケジュール」の選択画面を表示させてみた。

ダッシュボード — 統計

ページ・タブは (ぼくが) 使っていないので省略。コメント・タブにはコメント一覧が表示されるけど、プライバシーを考慮して省略。

統計タブの中身は、旧バージョンと変わりない。

収益タブには何も表示されなかったので省略。

ダッシュボード — レイアウト

ブログのレイアウト変更を行なうタブ。

ダッシュボード — テンプレート

ブログのテンプレートを編更するためのタブ。

ダッシュボード — 設定

設定用のタブ。設定タブは更に 5 項目に分類されている。

• 基本
• 投稿とコメント
• モバイルとメール
• 言語と形式
• その他

あとがき

新 UIになって、新機能が増えたりしたわけではないらしい。主に UI を大幅に変えただけと考えて良さそう。強いて言うなら、タブ間の遷移がスムーズになり、編集画面もスマートさを増している。UI の変更以上にバックエンドを大きく書き換えているものと思われる。

科学論文の英語用法百科 (グレン・パケット)

先のエントリーで、日本人がよく間違える英語を解説した新書「猫舌流 英語練習帖」を紹介した。

• clmemo@aka: 猫舌流 英語練習帖 (柳瀬 尚紀) を読む

「猫舌流 英語練習帖」は主に「小説」を読む時に間違え易い英語表現を中心に解説していた。

本エントリーで紹介する「科学論文の英語用法百科」は科学論文を書く人向けの参考書。

科学論文の英語用法百科〈第1編〉よく誤用される単語と表現
グレン パケット 理論物理学刊行会 Glenn Paquette


京都大学学術出版会 2004-09
Amazonで詳しく見る by G-Tools

京都大学学術出版会が出版。ページ数は 688。

作者のグレン・パケット (Glenn Paquette) 氏は京都大学基礎物理学研究所 (湯川記念館としても知られる) の研究員。基礎物理学研究所が出版する物理学論文誌「Progress of Theoretical Phisics」において 9 年間、英語論文の校閲をしてきた実積がある。本書は、約 2,000 本という (日本人が書いた) 英語論文にチェックを入れてきた経験を集体成したもの。

各章ごとに、誤り易い「表現」が取り上げられている。章の数は 133 にのぼる。誤用の例文が多く示されていて、何故それが誤りなのかを丁寧に解説している。

例を 2 つほど挙げてみる。

1 つ目は「Since」(Chapter 115, p.550)。本書は 学術論文においては、接続詞 since を because の同義語として用いるには注意が必要 と言う。何故か? 長々と説明が続くが、乱暴にまとめると because の同義語として用いられていることが明らかな場合でも、since は必ず時間的なニュアンスを伝える ため。本書は 6 ページ使って、since の不自然な用法や正しい用法を説明する。

2 つ目は「on the other hand」(Chapter 91, p.431)。英和辞書をひくと「一方で」と訳が出るこの成句。本書は 留意すべき点が二つある と言う。その一つは、on the other hand がつなぐ文の主題は同じでなければならないということである。もう一つは、これらの文は、その主題について異なった見方を示さなければならないということである。日本人は話題を変える時にさえ「一方で」を使ってしまうが、「on the other hand」の意味は日本語の「一方で」よりも狭く限定されている。本書が on the other hand に割くページ数は 13。それだけ日本人が誤って使うということを示している。

ぼくは since も on the other hand も、間違った用法で使うことが多かった。上の例を見ても分かる通り、本書は、科学論文だけでなくビジネス英語でもやらかす間違いを指摘しているので、英文を本気で書くつもりの人は買っおいて損はない。

続編は?

本書のタイトルに「第 1 編」とある。序文には、「科学論文の英語用法百科」について全五巻での完結を目指していると記されている。その内訳は次の通り:

1. よく誤用される単語と表現
2. 冠詞、前置詞、代名詞
3. 動詞
4. 文法、構文、言葉遣い
5. 物理学、数学における特別な問題

本書の第 1 版は 2004 年に発売された。以降、続編は発刊されていない。本書の質が高いだけに、続編が出版されることを願う。

「チーズはどこへ消えた?」と「バターはどこへ溶けた?」

図書館で 100 ページほどのビジネス書「チーズはどこへ消えた?」(以下『チーズ』) を読んだ。隣に「バターはどこへ溶けた?」(以下『バター』) という本が並んでいたのでそちらも読んだ。どちらも面白い本だった。特徴的なのは、『チーズ』と『バター』では言っていることが正反対に見えること。

本の紹介と自分の考えを書いてみる。

チーズはどこへ消えた?

本書は三部で構成されている: 同窓会で人物紹介と近況報告をする第一部。第一部の「こんな話を聞いたんだ」を受けて語られる「寓話」の第二部。再び同窓会に戻り、「寓話」を現実世界の問題に照らし合わせてディスカッションする第三部。

寓話には迷路の中でチーズを探す二匹のネズミと二人の小人が登場する。ネズミと小人は大きなチーズを見つけるが、ある日、そのチーズは消えてしまう。ネズミはチーズが日々小さくなっていることに気付いており、現状が長続きしないことを予想していた。チーズが消えた日、彼らは新しいチーズを探しに出る。小人達は、チーズのあった場所から動こうとしない。現実を認めたくない。しかし、小人のうち一人は、恐怖が自分を縛っていることに気付きチーズを探すため古巣を後にする。行動に出た二匹のネズミと一人の小人は新しいチーズを見つける。

ここで語られる「チーズ」は「私たちが人生で求めるもの、つまり、仕事、家庭、財産、健康、精神的な安定……等の象徴」とされる。寓話の中ではいくつもの言葉が大文字で表記される。要約すると「変化に敏感であれ」「変化に合わせて新しい行動しよう」「新しい行動への恐怖を乗り越えよう」の三点。

本書は寓話一つで完結しても十分面白い。加えて、第三部のディスカッションが寓話の良さを引き出している。現実問題における複数のケースに対して、寓話を適用すると「自分はどうするべきか?」を論じている。第三部があるおかげで、寓話を寓話として受け取めてそれ以上考える人が少なくなる。「読者」の場合どう考える? と本が問いかけてくるし、寓話を現実に適用する方法の一端は既に示されている。

本が薄いのも良い。チームで仕事をしていると、新しいことに挑戦しない人が (特に上司に) 出て来る。そんな人に、ちょっと読んでみて、と勧めるのに丁度良い厚さだから。

バターはどこへ溶けた?

『バター』は『チーズ』の半年後に出版。内容は『チーズ』のパロディーになっている。『チーズ』と同じく三部構成で、一部が同窓会、二部が寓話、そして三部は「ディスカッションする必要はないよね」と言って皆が別れる。

『バター』の寓話には森の中で住む二頭のネコと二頭のキツネが登場する。ネコとキツネは美味しいバターを見つけるが、ある日、そのバターはなくなってしまう。キツネはバターを探しに出かける。一頭のネコはキツネと同じくバターを探しに出かけるが、先にバターを見つけたキツネに追い返される。一方、残ったネコは出かけたネコの安否を案じながら、幸せな日々を送る。出かけたネコが戻ってみるとびっくり。人がバターを用意してくれていた。その頃、キツネは猟師に殺されていた。

ここで語られる「バター」は「追い求めだしたらキリがないもの、財産、名誉、出世、権力」の象徴とされる。要約すると、「今までバターがなくても生きていけたのに、わざわざバターを探しに出かける必要があるのか?」「幸せはここにあるんじゃないのか?」。

あとがき

『チーズ』も『バター』も主人公達は幸せになる。けれど、方法論が違う。『チーズ』は「新しい行動」を起こすことによって、『バター』は「新しい行動」を起こさないことによって幸せになる。

これは「チーズ」と「バター」の象徴が違うことに起因するとぼくは考える。

『チーズ』の世界では「チーズ」が唯一の食料。一時的に失うのは良いけれど、長期的になければ死んでしまう。それは「会社の利益」「生活するための最低限のお金」「体や精神の健康」に当たる。だから、何らかの変化でこれらが失われることがないよう、敏感にアンテナを張りめぐらし、必要ならば「新しい行動」にシフトする必要がある。そうすれば、「会社の倒産」「趣味もなく食べるだけの生活」「病気やケガ」などから逃れられる。上手くやれば、今以上の成果を得ることができる。

『バター』の世界では「バター」は唯一の食料ではない。バターを見つける前まで、ネコたちはバターなしで生活していた。キツネたちがバターを発見して初めて、ネコたちもバターの美味しさを知ることになった。だから、バターがなくなったところで元の生活に戻るだけのこと。バターを「名誉」「出世」「権力」の象徴としているのは、なるほどと思う。名誉・出世・権力を追うばかりが幸せの道じゃない。名誉・出世・権力がなくたって幸せな生活は出来た。

ぼくは『チーズ』と『バター』を読んでこう思った。「チーズ」を探すことは必須事項。けれど、「チーズ」を探し続けて、いつの間にか「チーズ」が「バター」になってはいないか? 「バター」を追い始めていると思ったら、その「バター」は本当に自分に必要なのか考えてみたい。

蛇足: 『チーズはどこへ消えた?』『バターはどこへ溶けた?』どちらがよい本か?

『チーズ』と『バター』を比べている本も出ている。読んでみたけれど、「黄色の表紙が良い」とか「お風呂で読んだ」とか脱線話が多くて... あまりお勧めできない。

一つ、ほう、と思ったことがあったので引用。『バター』が『チーズ』の半年後に出版されたことについて...

ダリオ、あんた、本当に善人ね。こんなの、出版社がフリーライターの誰かを雇って、アメリカ人にでっち上げて書かせたに決まってるじゃない。私の見るところ、このイラストを担当した吉沢深雪って人が怪しいわね。小出版社のことだから、ギャラはイラスト込みの買い取り。重版から印税が支払われるってとこかな

真相は闇の中だけれどもね。

ブログを書くために — IT 技術系ブログの場合

Fans:Fans で「ハウツー★Blog」というキャンペーンをやっているので一枚噛んでみる。主旨は以下の通り。

ブログをお持ちの皆さまが、ブログの書き方で気をつけていることや、心がけていることって何ですか?

ブログのレビューやコメントにて、ブログの書き方について投稿してください!

clmemo@aka を書くに当たって、気を付けていること等を書いてみる。

大まかな手順

1. ネタ探し

フィードリーダーや Twitter を中心に自分が興味を引くネタを集める。自分が興味を持てない話題は大低よい記事に出来ないのでスッパリ切る。

フィードリーダーに登録するのは、まず第一にオフィシャル・サイトのブログ。第二にその分野でメジャーなサイトのブログ。第三に自分が発掘した良エントリーを書くブログ。

オフィシャル・サイトは、自分が使っているサービスやツールをメインに網羅する。メジャーなサイトは、livedoor Reader のおすすめフィードやはてなブックマークを参考にするとすぐに見つかる。マイナーなサイトの探し方は二つ。一つ目はブログにコメントやトラックバックを送ってくれたブログをチェックすること。その多くは自分と興味を同じくしているので、チェックしていると思わぬネタを拾えることがある。二つ目は Google Analytics 等のアクセス解析を使って、自分のサイトにリンクしているサイトを洗い出す方法。アクセス解析を上手く使わないと、ゴミ情報 (検索エンジンとか) を拾うことになるので少し難易度が高い。

2. 一次情報に当たる

面白いネタを見つけたら、まずその情報の一次情報に当たる。大低は、サービスやツールのオフィシャル・ブログが一次情報になっている。一次情報を見つけたら、英語でも、とりあえず目を通す。

エントリーを書く際も、一次情報へのリンクを張ることを忘れない。自分が間違えたことを書いていた場合でも、読者が「オリジナル」の記事をすぐに参照できる様にしておく。これは、あとで自分のブログを読み返す時にも重宝するので欠かさないこと。

3. 周辺情報をチェックする

同じ情報元を使って書いているブログの記事を読む。目的は、一次情報の確認 (特に一次情報が英語の場合)、そのブロガーの視点・切り口の勉強。

一次情報へのリンクと並べて、良エントリーを抽出してリンクを張っておく。最新情報の場合、良エントリーへリンクを張ることは読者への第二・第三視点提供となるので好ましいと考えている。

古い情報であっても、自分にとって有益である場合は時期を気にせずエントリーにする。この場合の目的は「有益情報を自ブログへ集中化」させること。そして、自分のブログを検索するだけで目的の内容を引き出せる様にすること。

新しめの情報は自分と読者のため。古めの情報は主に自分のためと割り切って書いている。

4. 読者対象を定めて書く

情報が集まったら、エントリーを書く。この時、自分の読者をちゃんと想定して書く。

読者はその分野のアマチュアか? プロか? 最低でも、この区別は付けておく。対象読者がアマチュアの場合は、難しい用語を避ける、アマチュアの知らない技術用語を把握する、そしてその技術用語の説明を加える、スクリーン・ショットを多用する、ビデオを作れるならなお良い。相手がプロの場合は、不要な説明はバッサリ省いて、いきなり核心に入る。

読者の対象をエントリー内で変えることは絶対にしない。特にアマチュア向けのエントリーなのに、プロ向けの書き方が混ぎれ込むのはよろしくない。よくやりがちなのが、難解な用語を (説明なく) 使うこと。

エントリーごとに対象読者を変えるのは、むしろ好ましいと考える。ブログ全体で、対象読者を一つに絞るのは (個人ブログの場合) よほどのことでないと難しい。ぼくの場合、次の様に対象読者を変えている:

• 大半のエントリー: 大学時代の友人で IT にも興味を持つ友人がいる。彼が初めて読んでも分かる様にエントリーを書いている。彼がぼくのブログを読んでいる・読んでいないは関係ない。あくまで仮想読者を一人に絞っているだけのこと。特に新サービスの紹介などは、この基準で書いている。仮想読者が一人なので、あれこれ考えなくて良いのがメリット。
• サービス向けエントリー: 一度紹介したサービスが成長した場合、対象読者をサービスの利用者に変更している。Blogger, Google Reader, Emacs etc. に関するエントリーがそれに当たる。サービスを使っている人にとって当たり前の説明はしない。
• 一部の読者に対するエントリー: ぼくは 2 つのブログを持っている。1 つは技術系の clmemo@aka (このブログ)、もう 1 つは趣味系の life@aka。この中で、オーディオというカテゴリーには困った。ぼくはオーディオ機器に少しだけ凝っているのだけど、これは趣味ではなく技術的な内容になる。すると、clmemo@aka で扱うことになるんだけど、clmemo@aka は技術といっても IT 系に特化している。オーディオの世界と IT の世界は違う。仕方ないので IT 系の読者はある程度切り捨てて、オーディオ系の読者を対象にエントリーを書いている。なので IT 系の人達にはエッと思うエントリーに出遭うこともあると思う。とはいえ、技術な人達全員にオーディオへ少しでも歓心を持って欲しいので、内容によってはなるべく平易な用語を使うよう心がけるエントリーもある。少くとも、アマチュア向けとプロ向けの混在だけはしない様に気を付けている。

5. 自分の意見を入れる

どんなに短いエントリーでも、自分の考え・意見を持つ。

こうなってくれると嬉しいとか、この変更は好きでないとか、この機能は重宝している (重宝するケースを書けるとベスト) とか、何でも良いから短く自分の言葉を入れる。自分で書いていると「自分の言葉」なんか... と軽く思いがち。でも、他人のブログで面白いと思うものは、一行でも「自分の言葉」の入っている。

どんなに短くても良いから、少しだけ他の人が書いてないことを書いてみよう。

Tips

小さな Tips を集める

小さな Tips や技術情報であっても、集めると読者にとって重宝されることがある。

• clmemo@aka: 我流ながら Doing List を二年間試して得た Tips 集
• clmemo@aka: Emacs で C 言語プログラミングを始める人へのイントロダクション
• clmemo@aka: オフ会で幹事をするにあたり使ったウェブ・サービスのまとめ

長いエントリーを分割する

長いエントリーは書く方も読む方も疲れる。適当に分割してしまうのも手。

• clmemo@aka: 10 万円代の CD プレーヤー比較 その 1
• clmemo@aka: 10 万円代の CD プレーヤー比較 その 2
• clmemo@aka: 10 万円代の CD プレーヤー比較 その 3

他人の企画に乗ってみる

他の人がお題を出してくれる場合がある。このエントリーなんか正にそれ。ブログ間の横の繋がりが出来たりして、存外面白い。

• clmemo@aka: Closure (クロージャー) って何だろう?
• clmemo@aka: 自己紹介バトン
• clmemo@aka: Musical Baton (ミュージカル・バトン)

他人の困ったを解決

ブログや Twitter で「○○が分からない」と呟かれていたら、その解答を自分なりに書いてみる。ある意味、最低一人は読者が保証されるエントリーの書き方。もしかしたら、それを縁にブログ間の友好関係が築けるかも。

• clmemo@aka: Android の onClick event listener を楽に書く
• clmemo@aka: 停電対策にケミカルライト
• clmemo@aka: マンガ家向け? USB 対応トレース台

あとがき

ブロガーの数だけ、ブログの形がある。ここに書いた「ブログを書くために」は、ぼくのブログの書き方を書いただけにすぎない。他のブロガーは他のブログの書き方をしている。

どんどん技術を真似て盗んで面白いブログを書いて欲しい。

最後に一言。盗むのは、「記事の内容」ではなくブロガーの「技術」「話術」「文章術」!!

Fans:Fans がトップページに検索機能、プロフィールにお気に入り機能を追加した

2011-06-07 に Fans:Fans からメールが届いた。内容はタイトルの通り。

• トップページに検索機能がついた
• プロフィールにお気に入り機能がついた

詳細は、スクリーン・ショット付きで本家ブログに書かれている。

嬉しい点

何故、この件をエントリーにしたのか?

理由は、この機能追加が先日行なわれた Fans:Fans のイベントでの要望を反映したものだから。

• ref. clmemo@aka: 第 1 回 Fans:Fans ユーザーミーティングに参加した

ブロガーやモニターの人間を集めて、意見を聞くイベントは多い。けれど、その意見をどう活かしたかを参加者にフィードバックするところは少ない。

Fans:Fans では、変更したことをメールでお知らせして、更にブログの記事で詳しく解説している。本来、イベント参加者に意見を求めて改善を行なったなら、こういう手順を取って欲しいもの。他の企業には、是非、お手本にして欲しいと思い、ブログの記事にした。

参加者は、イベント開催者とのコンバセーションを望んでいる。一方通行な意見の扱み上げや、一期一会的なイベントは望んでいない。自分の意見が却下されても良い。その理由を説明してくれれば。結局のところ、企業やイベントの内身が少しでも透明化されると、とても嬉しい。何が起きているのか分からない! 自分の意見がどうなったのか分からない! そんなのは、ちょっと悲しい。

mew-absfilter.el 復活

Infoseek のウェブ・サービス終了とともに mew-absfilter.el のウェブ・サイトも消えた。mew-absfilter.el の配布サイトが Infoseek のウェブ・サービス上で公開されていたため。

その、mew-absfilter.el。github で改めて公開されることになった。

• tabmore/mew at master - GitHub

作者の Saito さんには感謝。

今はまだ mew-absfilter.el の説明など少ないけれど、次第に充実していくことと思う。

WWDC にて Lion, iOS5, iCloud 発表

2011-06-07 午前 2 時 (日本時間)、Apple の恒例イベント WWDC 2011 が開催された。基調講演にはステーヴ・ジョヴスが現れた。

今回の話題は 3 つ。新 Mac OS Lion、iOS5、そして iCloud。

MacOS 10.7 Lion

Lion は CD/DVD での配布は行なわれない。App Store から購入する形を取る。価格は $29.99 (過去のアップグレード版は $129 だった!)。2011 年 7 月発売予定。開発者プレビュー版は今日からダウンロード可能!

購入は Mac App Store に行き、「Lion」を「buy」。ダウンロード後、アップグレードが始まる。Lion のダウンロード・サイズは 4 GB。再起動なしに利用可能。

複数の Mac を持っている場合は? アカウントが同じなら、一回「Lion」を買えば他の Mac でもアップグレードできる。

主な新機能は以下の通り:

マルチタッチ・ジェスチャー対応

Apple のノート PC は現在、全てマルチマッチ対応のトラックパッド。

Lion では、ダブル・タップでズームイン/アウト、2 本指ピンチ・イン/アウト、2 本指のスワイプで次・前のページへ (Safari)、もしくは次・前アプリへ (フルスクリーン・アプリ)。3 本指スワイプ (上) でミッション・コントロール。

スクロール・バーは標準では現れなくなる。ジェスチャーでスクロールする時にのみ現れる。

フルスクリーン・アプリ

アプリのフルスクリーン表示が簡単にできる様になる (Safari, iMovie などのデモが表示)。右上にマウスを持って行くとフルスクリーン化もしくはフルスクリーンの解除。

ミッション・コントロール

Exposé に Spaces が統合されミッション・コントロールと呼ばれる。Space の一覧が Exposé 画面の上にサムネイルで現れ、ワン・クリックでスペースの切り替えられる。左上にマウスを持っていくとミッション・コントロールがスタート。

ミッション・コントロール中にスペース・キーを押すと、プレビューがスタート。

Mac App Store

Mac 用アプリの入手元。Lion には built in。アプリ内購入 (In-app purchase)、新バージョンの通知が可能。デルタ・アップデートもサポート (アプリを丸ごと新バージョンに入れ替えるんじゃなくて、変更部分のみを入手してバージョン・アップする方法。ダウンロード時間が短くなる)。

自動保存機能

対応アプリは、自動保存が可能になった。「保存」ボタンを押さなくてもよくなった。

メニュー・バーのファイル名をクリックすると、プルダウン・メニューが現れる。メニューから、「自動保存の停止」が選べる。また、同メニューから「ファイル・オープン時へ戻る」、「ファイルのコピー」なども選択可能。

自動保存機能に伴って、ファイルのバージョン管理も自動的に行なわれる。

AirDrop

Peer-to-Peer によるファイル転送機能。相手側の OS が AirDrop 対応なら、すぐに使える。Wi-Fi 経由。データは暗号化して送られる。

misc

• Lion の新機能は約 250
• 3000 の新 API
• メール・アプリが刷新 (メール・アプリは使ってないので、変化のほどがよく分からない ^^;)
• Windows Migration assistant
• FileVault2
• FaceTime 対応

iOS5

iOS5 のリリースは今秋。開発者版のリリースは今日。

新機能は以下の通り:

PC Free

iOS のアップデートも PC Free。iTunes がなくても平気。アップデートはデルタ・アップデートをサポート!

iTunes のライブラリーとも Wi-Fi で同期可能。

Notifications

通知機能がより洗練された。トップ画面で下にスワイプすると、Notification Center が現れる。Notification Center には全ての「通知」が管理されている (Android みたい)。

アプリ実行中に通知が来ると、「通知が来た」と画面上方にお知らせが表示される。ゲームをしている時でも邪魔にならない。

ロック画面にも「通知」表示が現れる。通知部分をスライドすることで、いきなり対象アプリを起動可能。

Newsstand

雑誌購入が可能になった。対象の雑誌は New York Times など (日本の雑誌はどうなるのかな?)。

雑誌を購入すると、自動的にダウンロードされ Newsstand アプリ内に置かれる。ダウンロードはバックグラウンドで実行され、ダウンロードした雑誌はオフライン時でも閲覧可能。

Reminder

ToDo リストを作成、時間・場所を設定可能。「何時になったら○○する」「どこへ来たら○○する」を事前に通知可能。

ToDo リストは複数のデバイスで同期される。またカレンダー・アプリにも同期される。

Built in dictionary

英英辞書がデフォールトで入った。全てのアプリから利用可能。

Twitter 対応

カメラや写真アプリなど、多くのアプリとの連携が可能になった。

Safari から URI を、Map から自分の居場所を Twitter に簡単に送れる。

Safari アップデート

Reading List なる「Read It Later」相当の機能がデフォールトで対応。Reading List に入れた記事は、後で複数のデバイスで閲覧できる。

タブ機能も追加された。

カメラ・アップデート

ロック画面にカメラ・ボタンを配置。ボリューム・アップ・ボタンをカメラのシャッター・ボタンとして利用可能。

ピンチ・インでズーム。タップでオートフォーカス対象をロック。

写真撮影後、すぐに写真の編集 (切り取り・回転・赤目処理) が可能になった。

メール・アップデート

• リッチ・テキスト編集機能
• 送信先 (To:) を Cc: や Bcc: へドラッグで移動
• 全メールを検索
• 既読・未読フラッグの追加機能
• S/MIME に対応

New Keyboard

今までキーボードは画面下にしか現れなかった。キーボードをドラッグして上へ持っていくと、キーボードが少し小さくなって左右に分かれる。iPad で親指だけでキーボード入力することを考慮して作られた機能。

iMessage

iPhone の SMS が iPad/iPod Touch でも利用可能になった。グループ・メッセージにも対応。

iCloud

iCloud は Apple 版ストレージ・サービス。今秋リリース予定。開発版のリリースは今日。

Apple は今まで同様のサービスを MobileMe として提供していた。MobileMe アプリは全て iCloud 用に書き直される。MobileMe は $99/年 だったが、iCloud は無料!! ストレージ・サイズは 5 GB。

iCloud は自動アップロード、(他デバイスへ) 自動プッシュをサポート。対象コンテンツは、連絡帳、カレンダー、モバイル・ミー・アカウントのメール、バックアップ (Wi-Fi 必須: アプリ、音楽、iBooks、写真・ビデオ、デバイス設定、アプリ・データ)、ドキュメント (Pages, Numbers, Keynote で作成したもの)。そして、iCloud Storage API を使って iCloud 対応化されたアプリのデータ。

ストレージの 5 GB に購入アプリ、音楽、本は含まれない。メールやドキュメント、バックアップの容領が 5 GB。写真は最新の 1,000 枚が対象となる。iCloud 上の写真は 30 日間保存されるので、永久に保存するものは iCloud 経由で Mac や Windows マシンに移動させること。

iTunes Match

iTunes で管理している楽曲をスキャンして、好みに合いそうな曲を提案するシステム。年間 $24.99。

スキャン後、iTunes で売られていない曲はクラウドにアップロードされる。そして、売られている曲は自動的に 256 kbps の AAC (DRM 無し) に変換させられる (これはイイ!)。

同様のサービスを Amazon と Google が始めている。Amazon は 5 千曲につき $50 なので、25,000 曲以上所有しているなら iTunes Match の方が安い。Google は値段をまだ出していない。また、256 kbps への自動アップグレード機能は iTunes Match にしかない。

あとがき

iCloud が無料というのが驚きだった。そして iCloud Storage API に注目したい。

今、ぼくは家計薄アプリを iPhone で使っている。けれど、iPad では使っていない。理由は、iPhone・iPad 間でデータの同期が出来ないから。

データの同期が必要なアプリはいくつかあるけれども、どれもウェブ・サービスを持っている。例えば Twitter, foursquare, Evernote。だから、ウェブ・サービスを持たない「同期」アプリは出来ないと思っていた。

ところが、iCloud Storage API はこの問題を解決する。ウェブ・サービスなしでも、データの同期が出来てしまう。iOS 内だけで完結できる。これは素敵。

猫舌流 英語練習帖 (柳瀬 尚紀) を読む

猫舌流英語練習帖 (平凡社新書)
柳瀬 尚紀


平凡社 2001-06
Amazonで詳しく見る by G-Tools

一風変わった「英語」の本。特徴は「日本人が間違えやすい英語」に絞って解説している点。

第一章では、「I am 〜」の文法でどれだけ豊かな英語表現が出来るか教えてくれる。例えば「I am a Xantippe.」という英文。Xantippe を辞書でひけばソクラテスの妻と出る。この Xantippe、ソクラテスを罵った悪妻として有名。そこから訳文は「どうせ私は悪妻ですよ」となる。なるほど、英語は奥が深い。

第二章は第一章の復習問題。豊富な実例文を出して、読者の理解を深める。

第三章は前章まで触れた「about」「little」「with」「oneself」等の使い方を詳しく解説している。一例を挙げると、「A few swallows still wheeled about the walls, giving shrill little cries」。訳文はこうなる。「燕が数羽、なおも壁から壁へ旋回しては、甲走った鳴声をあげた」。作者はここで、「little」の用法を注意する。little は、特に形容詞の後ろに添えて、話者もしくは書き手の感情をこめる (p.87)。知らないと、いろんな所で「小さな」と訳して意味を取り違えそう。

第四章は第三章の復習。特に辞書を引くことの重要性 (と失敗談) を書いている。

最後の第五章は長文に挑む。対象は「物語」ではなく「新聞」。物語と新聞では、使う英語も変わってくる。第五章ではイギリスの大衆向け週刊紙 The Weekly Telegraph から 2001-02-07 付けの記事を一本丸々取り扱う。たった一本の記事なのに、これでもかと誤訳しそうな例が飛び出すのは驚くばかり。

猫舌流について

本書は、翻訳家の飼い猫が執筆した設定になっている。これは夏目漱石の「わが輩は猫である」のオマージュ。ただし、単なるオマージュに終わらない所が本書の魅力。

英文を訳すには日本語のセンスも重要。漱石の文章を引きながら、その実例を示している。それも原書のままで。例えば第二章冒頭で引用する文章は次の通り。

鼠を捕るのは思つたより六づかしい者である。

ここで使われる「者」は「者」の旧字体。「者」を漢検 漢字辞典で引くと 2 つ目の意味に「こと。特定のことがらを指す」とある。前者、後者の「者」ね。最近の人はこういう用例では「もの」を平仮名書きするけれども、漢字を使うなら「者」なんだねぇ。ぼくも知らなかった。

辞書

本書は、「辞書を引け」「辞書を引け」と何度も訴えている。英語上達に辞書は欠かせない。

本書で登場する辞書も様々。OED, POD, American Heritage Dictionary, Merriam-Webster's Collegiate Dictionary, Merriam-Webster's Third New International Dictionary, Shorter Oxford English Dictionary。OED は別として、一冊は持っておきたいもの。

失敗談

最後に、第 4 章にある辞書びきの失敗談が面白かったので引用して、本エントリーを終える。

不細君はあるとき唐突に、守人にこう尋ねた。

——ユーエヌって、どこの国でしたっけ?

守人は即座に答えた。

——辞書を引け。

瞬時にそう返答したが、実はその瞬時の間に、守人の脳裏には次のような考えが渦巻いた。(中略)

守人は考えた。ユーエヌ? UN? ロシアのウクライナ (Ukraine; 英名ユークレイン) の属領? イタリアのウンブリア (Umbria; 英名アンブリア) にあった古代王国? アフリカのウガンダ (Uganda; 英名ユーガンダ) に生れた新興国? 見当がつかないので顔がゆーがんだ。

そのあと守人は、パソコンに収められている辞書や事典、書棚のありとあらゆる答書や事典を調べていた。インターネット検索も試みていた。しかし UN がどこの国かは突きとめることができない。

翌日、守人はさりげなく訊いた。

——ユーエヌ、分ったか。

——ユーエヌ? あ、国じゃなくて、国連よね。UK がイギリスだから、ふと UN がどこの国かと思って。

守人は絶句した。

Android の onClick event listener を楽に書く

ヒビノアワさんがブログでこんなことを呟いてた。

androidのアプリ開発をしてると、画面のUI部品のイベントを受け取るイベントリスナを書くことになるわけですが、これ、書き方によっては、やたらonCreateメソッドが長くなっちゃっていやだーなと思っていたのです。

ヒビノアワ: Javaのイベントリスナをどう書く？ より引用

この点について、Android 1.6 以降は (onClick イベントに限って) 楽な書き方ができる様になっている。Android の開発ブログにも書かれているので、大意を取って解説する。

• ref. Android Developers Blog: UI framework changes in Android 1.6

一般的な書き方

UI の button にクリックされた時のメソッドを定義したい場合; つまり button に onClick の EventListener を紐付けたい場合、onCreate メソッドの中に次の様なコードを書く。

findViewById(R.id.myButton).setOnClickListener(new View.OnClickListener() {
    public void onClick(View v) {
        // やりたいこと
    }
});

ボタンの数が増えると、上記のコードを何行も書くか、if 文で分岐を入れるかしないといけない。これは大変。

Layout で設定

Android 1.6 からは、XML layout ファイルにクリックされた時に呼ばれるメソッドを書ける様になった; button 要素が onClick 属性を持ち、メソッドを直接指定できる様になった。

レイアウト・ファイルはこうなる。

<Button android:onClick="myClickHandler" />

で、Java ファイルには (onCreate メソッドの外に) 次の様なコードを書けばいい。

class MyActivity extends Activity {
    public void myClickHandler(View target) {
        // やりたいこと
    }
}

この書き方なら、ボタンの数が増えても onCreate は長くならないし、コードの見た目もスッキリする。何より、コーディングが楽。でしょう?