著作一覧 |
最近、立て続けにアイスクリーム屋を開拓したのでメモ。
・ミルクポット
大橋のメインストーリトから目黒川のほうへ曲がったところにある。大橋らしい、古臭さがおしゃれな店舗のアイスクリーム屋。普通においしいが、特にオレンジシャーベットが良かった(ほうじ茶はいまいち)。林檎も良いというか、アイスクリームよりシャーベットのほうがおいしい気がする。カロリーは低め。
というか大橋ってとても不思議な商店街になっていて、歩いていて楽しい。なんだろうな? 首都高のぐるぐる大回転の建物が何かを引き寄せているのかも知れない。
麻布十番。ジェラートってシャーベットのことだと聞かされていたので普通にアイスクリームなので衝撃。異様に味が濃いのだが、それが良い。
本来チョコレートアイスは好みではないのだが、ノア(黒)なんちゃらが本当にノアなので頼んで食ったら衝撃的においしかった。
マルゲラがあまりに強烈だったので、近場の別のアイスクリーム屋のピッコへも行ってみた。すごくあっさりしているが、これ好きだ。
近所に、おそらく六本木で一番安い駐車場がある。
-以下、ここ数年に通っているところ。
・白一
2年前くらいからのお気に入りで、五反田と渋谷にある。異様に細長いソフトクリームのように見せかけた牛乳のシャーベット状のアイスで、見た目のおもしろさと、独特の食感。素晴らしい食べ物だと思う。
・SOWA
愛宕山のふもとのアイスクリームの製造販売屋さん(老舗)。割と好きだが、老舗っぽい味。
-数十年前の行列マーケティングでぶいぶい言わせた原宿/青山のハーゲンダッツは今ではコンビニアイス(路面店は両方とも無い)、西麻布のホブソンズは耳にしなくなった(まだあるのか?)、広尾のロビンソンズ(だと思ったが、店でコーンを焼いているのが実に特徴的だった。この3つの中では一番好み)もとっくに消滅していることから、やはり数十年たった後のことを想像すると、SOWAと白一は地味に生き残っているだろうが、マルゲラは撤退、ピッコはもしかしたらやっている、ミルクポットは微妙(大橋が衰退すると引きずられそうだ)というところかな。
具体的な数は2桁の前半(この日記のPVはしょぼいのよ)だけど、これまでここで紹介した本で群を抜いてアフィリエイトの結果が良かった(受け取りはギフト券にしているのだけど、ありがたく頂戴しています)のは、テスト駆動JavaScriptとモダンC言語プログラミングの2冊だ。
テスト駆動JavaScript(Christian Johansen)
モダンC言語プログラミング 統合開発環境、デザインパターン、エクストリーム・プログラミング、テスト駆動開発、リファクタリング、継続的インテグレーションの活用(花井志生)
どちらも良書なので、こちらも気を張って記述しているから相乗効果もあるだろうけど(より良いコンテンツがぶくまを集めるとか)、そうはいっても、僕には実に興味深い結果だ。(メディア的にはアスキーの本を取り上げる日記やブログがそれほど多くは無いからというのもあると思う。Team Geekも相当な注目度をもらったが、アフィリエイト的には大したことはない)
興味深いのは、どちらの言語も、現在としてはしょぼいことにある。そして、どちらの本も、そのしょぼさを克服するための手法について記述したものだということだ。
JavaScriptのしょぼさは、言うまでもない。型チェックが実行時にしかないことは大した問題ではなく、変数名の記述ミスに甘いことだ。Rubyのように未定義の変数で怒ったりしないし、そもそもスコープをvarで明示する必要がある点が最も問題だと思う。
Cのしょぼさは、強みでもあるが、メモリ管理の放任主義と、歴史的事情によるテキストエディタ派の強さ(EmacsやVimプロパーは良いのだよ。プロパーは経験によってそこにいるのだから。そうではなく今、この言語で開発を始める人たちのことだ)に代表される1970年代のプログラマワークベンチの呪縛にある。
つまり、僕は、自分のアフィリエイトで、破壊的イノベーションを目の当たりにしたのだった。
イノベーションへの解 Harvard business school press(Clayton M. Christensen)
解の中でクリステンセン(とアル)は次のように書く。
顧客が製品を購入する状況を構成するのは、顧客が片づけなくてはならない用事の機能的、感情的、社会的な側面である。
破壊的イノベーションとは、顧客の片づけ願望を突くことで、これまで市場に参加していなかった顧客を市場に参加させるか(機能は劣るがコストが圧倒的に低い製品による)、または既存の製品では解決しない片付け願望を異なるマーケティング的な切り口から再定義することで圧倒的な支配力を持つ持続的イノベーションからの乗り換えを促す。
もちろん、技術書なので、前者ということはあまり無いので、後者ということになる。フラナガンやK&Rを持続的イノベーションと、ここでは見なしているのだ(もちろん技術書をイノベーションに当てはめるのは無理筋なので、ここでは厳密なことを書いているのではない。だけど、わかる人にはいわんとしていることはわかるはずだ)。
一言でいえば、アスキーの鈴木さんは実に良い仕事をしているということなのだ(もちろん著者の花井さんやヨハンセンさんもだけど)。ありがたいことです。
なぜ、人類の歴史に王が生まれたのか、疑問だった。
強い奴が支配するというのは理解できる。臂力並外れた男が群れを率いるというのは、群れを力でねじ伏せ、他の群れとの戦いに勝利し群れを大きくするのに有利だ。猿山のボスに見られる。あるいは、交渉力に優れた奴が支配するというのもそれなりに理解できる。群れをまとめ、他の群れと交渉して併合し大きくするのに有利だ。あるいは技術力に優れたというのもあり得る。優れた農耕技術を持つとか、土木建設の設計能力があるとか。交渉力や技術力による支配であれば、それこそ人間だ。
しかし、どちらにしても、まずは平和的であれ闘争的であれ下剋上となるはずで、万世一系のような概念が出てくるとは考えにくい。
中国の歴史を紐解けば、三皇五帝がまさに優れた後継者へ禅譲する歴史だ。その間に農耕が始まり治水が始まり集落が形成される。そして夏になり殷となると王による一系支配となる。なぜ突然、一系支配が出てくるのだろうか?
所有の概念の誕生によるのだろうか? しかし、その場合においても、一系支配にそのまま結びつくとは考えにくい。なぜならば、子供が親の所有物を受け継ぐという概念は別だからだ。
さらには、ごくごく一部の例外を除き、なぜ主たる一系は母系ではなく父系なのだろうか?
ロイドの137億年の物語を、毎朝、朝飯を食いながら少しずつ読み進めている。先日、宇宙の歴史を1日に換算したところで、23時59分59秒過ぎのあたりまでやっとたどりついた。
今から、14000年前、氷期が終わりナトゥーフ人が住む地中海沿岸は乾燥しきった。そのため植物は枯れて、動物が死ぬ。しかし一部のイネ科の植物が残った。ナトゥーフ人は生き残ったイネ科の植物を切り盛りするようになった。農業の始まりである。と同時に遺伝子工学の始まりでもあった。イネ科の植物がこれによって改良され始めたからだ。それをナトゥーフ人は理解した。しかもイヌを飼い始めた。とは言っても最初はイヌではなく、オオカミだった。これも遺伝子工学だ。以後数1000年かけて、ナトゥーフ人たちは家畜としてのヒツジとヤギを作り出した。
ところが、イヌの飼育以降、新たな事象が発生する。乳児死亡率が高まったのだった(発掘された墓の1/3が8歳未満の子供なのだが、本来、哺乳類は子供の死亡率を減らすために妊娠期間を長く取り、餌を取らずにすむように哺乳するように進化したために、そこまで乳児の死亡率は高くないものらしい)。
ロイドはあっさりと、
その子たちは、動物の病気に感染した最初の犠牲者だったのかもしれない。もしそうだとしたら、新たな「人間の選択」がはじまったころになる。つまり、このような新しい病気に罹りやすい人が死に、罹りにくい人が生き残ったのだ。
と記述している。
137億年の物語 宇宙が始まってから今日までの全歴史(クリストファー ロイド)
2m超えの大年表も出ているのか。
ビジュアル大年表 137億年の物語(クリストファー・ロイド)
そこで、最初の疑問におれは立ち返る。
イネや家畜に対して原始的な遺伝子工学をふるった連中だ。
たとえば、Aさんの子供は全部で10人いて、10人とも元気に成年したとする。
ということは、Aさんの子供と一緒になって子供を作れば、その子供も元気に成年する可能性が高い(というようなことを、家畜や植物に対してやってきたのだから、そう考える高い蓋然性がある)。
かくして、Aさんがその集落での王となる。王子あるいは王女を残して残りは貴種混交に使われる。
王の意義は遺伝子の提供にある。
すると母系ではだめだ。うまくしても1年に1人しか生産できない。しかし父系であれば、集落全体に遺伝子を提供できる。
となると、その王の遺伝子を管理する人も必要となる。王の存在価値は遺伝子の提供である以上、それ以外の生産行為(農作業や家畜の世話)のように危険が伴う作業をさせるわけにはいかない。
かくして、貢物が生まれる。それを管理するために、僧侶のようなものが必要となり、最終的に宗教が生まれる。王は獣の神の子孫であり、尊い血が流れているといった、神話が生成される。
そこまで考えて、唐突にY染色体がどうたらというような話は、そういうレベルの話であり、正しく王の存在意義を評価しての物言いだったのだなと気づいた。それにしても失礼というか無礼な話だなと、21世紀に生きるおれには思えるのだった。
アマゾンの注文をいろんなマシンからするのだが、あらためて面白いなと思うのは、アマゾンのログインユーザの識別クッキーが、ユーザだけではなくマシンにも紐づいていることだ。
そのため、iPadからアマゾンへ入ると履歴やお勧めがiPadから参照するものが多く(文学が多い)、HTCJからアマゾンへ入ると雑多で(ぶくま読みとかするかして、そこからアマゾンを参照することが多いからだな)、メインのPCからはオーディオや猫グッズばかりになる。
既に購入した商品のページでは、どの端末から入っても購入済みと表示される(というか、アカウントがおれになっているから当然だけど)ので、ログインユーザに紐づいているのは間違いないが、それだけではなくログインしたマシンにも紐づいている(最後にログインした日時に紐づけているのかも知れないけど)。
Facebookとかだと、これまでログインしたことがないマシン(というよりもクッキーの有無だろうから、ブラウザが異なれば別マシン扱いとなるけど)については、よからぬ可能性を想定して識別/問い合わせをするし、ユーザだけではなくマシンを識別すること自体はそれほどおかしなことではない。
しかし、アマゾンは小売なので、別の考え方もできるはずだ。
つまり、同じユーザなのだから、履歴表示やお勧めを共通化することだ。
そこで、アマゾンのモデルとしては、ログインするマシンによって購入するものの傾向が異なると判断しているのだろうと考えてみる。実際、最初に書いたように、おれの端末ごとのアマゾンに対するユースケースは異なるので、この仕様は合っている。
でも、たまに、さっきPCで検索した商品を履歴に出してくれ、と、iPad使いながら憤ることもある。この場合、マシンは無視してユーザだけを見てくれということになる。
アマゾンの仕様は、AとBに分けて試した結果なんだろうか。それとも、たまたまアマゾンはマシン単位の履歴管理という選択をしたということなんだろうか。実際のところ、どちらが便利なのだろうか。
ネコの爪とぎをいろいろ試してみた。というか、1つあれば良いかと思ったが、人間がいて落ち着いてしまう部屋にいると、それなりにカリカリしようとする。トイレや餌皿は置いてあるところまで行ってくれるので、爪磨きも同じようなものかと思ったら、さすがに爪を磨くためにわざわざ設置した場所へ行くってことはないようだ。
それで、何か所か拠点になるところに置くことにしてみた。で、どうせ買うならいろいろ試してみることにしたのだった。
最初に購入したのは、段ボールハウス。
ボンビアルコン (Bonbi) キャットスクラッチハウス(-)
これは値段が手ごろだし、上に乗って遊ぶし、中に閉じこもって遊ぶし、がりがりするし、相当良いものだと思う。段ボールなのでくずがでまくるけど、それは家の床下相当の場所に溜まるので捨てるのも簡単だ(周りには飛ばない)。
難点は、存在感と、組み立てに使うプラスティックの留め具がかっこうのおもちゃとなることだ。とにかく気付くと外そうとするし、きつく締めてもいつの間にか外してアイスホッケーみたいにして遊んでいる。飲み込めそうなサイズなのでおっかない。
それで、今度は部品が少ない、洗濯板の小型版みたいなのをイオンで買った。むき出しの爪磨きなので、クズが出そうにない木製のやつにした。
が、どうも子猫には硬すぎるのか、いまいち使われない。趣向を変えて縦置きにしてみようかと思ったが、壁や柱に釘を打つのは抵抗があるし、ちょっと手を伸ばせばそちらをガリっとやってしまいそうで怖い。というわけで、なんか置いてある状態となっている。
むしろ、横に置いてある、妻のステップボードのほうが人気だ。
(表面がざらざらして、適度な弾力性があるものを、自分たちの爪磨きだと認識するようだ)人気があるのは良いが、がりがりされても困るので、カバーをかけて防御することになってしまった。
さらに子供の部屋にも設置するかということで、これまでの経験から、ハウスは大きすぎるし、段ボールはクズが出るし、木は固すぎる、はて困ったというところで、たださんが麻を導入しているのを読んで、麻のを購入(これもイオン)。
これは不思議な状態で、爪も磨くが、しょっちゅう座布団にしている。よほど気に入ったのか、昼寝をしているときもある。最初、またたびのせいかと思ったが、子供にきくと、見てすぐに爪研いでいたからまたたびは塗ってないとのことだ。
しかも、座布団認定なのか(時々は爪も研ぐけど)、横のほうの壁を引っ掻こうとしたりもする。縦置きのを導入したほうが良いのではなかろうか?
というわけで(イオンへ行く余裕がしばらくなかったので)、アマゾンで柱状のやつを適当に選んで購入した。
フラップ キャットスカイタワー Pole アイボリー GC-203(-)
なんか安定していそうだし、背伸びをしているネコの写真がバランス良く撮れているので、スペックを読まなかったのが運の尽きであった。
家に帰ったら巨大なオブジェが部屋を占拠していて仰天した。
妻が組み立てておいてくれたのだが、想像と全然違うでかさだった。特に設置面積がでかい。
その代り、相当安定していて、2匹で飛びかかったり、先端からジャンプしたりしても、多少揺れる程度で不安感はない。で、見ていると楽しそうだから良いことにしたけど、部屋がずいぶんと窮屈になってしまった(というか、おれの部屋には爪とぎハウスがあるから、2つ目はいらないのだが、他に置ける場所がない。それにしてもリング脇に設置しておくと、悪役レスラーが場外乱闘時に使ったり、イェーガーがタンカーの代わりに使いそうなサイズだ)。
材質は人間が触るとちょっと痛いくらいにささくれた木綿の紐をぐるぐる巻きにして鋲で止めたもので、底と頂上はフェイクファーでもしゃもしゃしている。爪を研ぐというよりは、よじ登って遊ぶ道具のようだが、それでも時々、伸びをしながらガリガリしている。
で、もう1個別のやつも注文してあったのも届いた。
こちらは絨毯を試してみた。サイズも予想通りの平均サイズ(一回り大きいかも)なので、予定していた場所へ設置した。
B00ECYSEWQ
割高だが、両端にしっかりした滑り止めが付いているので、立てかけて使えるのがミソなのだ(最初に書いたように釘で壁にぶら下げるのは嫌だからだ)。
どうも両端の滑り止めとそれを付けるためにしっかりした枠を用意したせいでコストがかさみ、これに麻や段ボールを組み合わせると、競争力がない価格となるので、絨毯と組み合わせておしゃれだから高価というコンセプトにしたみたいだ。見るからに絨毯なので、猫も最初は戸惑って、これなんだ? 研いでも良いのか? 状態だったが、引っ掻く真似したら、上に登って行った。ちょっと違うが、しっかり立てかけられているからおいおい研ぐようになるだろう。
素に近いWindows XPで動いているシステムがあって、どうしても、その中で動いているDLLの新版を入れたいとする。
そのDLLを呼び出すプログラムは、VC++6で遥か昔に作られたものだ。
しかし、手元にはVisual C++ 2010と2012しか無い。ここでランタイムをDLLとしてリンクするとすごく嫌なことが起きそうな気がする。かたやMSVCRT.dllをロードし、こちらはMSVCR10.DLLをロードする。競合はしないとは思うが(関数名の前のモジュール名が異なる)、ランタイムのバージョンが合わないというのはいかにも危なそうな匂いがする。
で、Visual C++ 2010でランタイムを静的にリンクすれば、mallocしたポインタをモジュールをまたがったところでfreeしたり、FILE*の交換などしなければ、気持ち的には安全なように思う。
そこで、Visual C++2010で静的ランタイムライブラリとリンクしてDLLを作ってインストールしたとする。
すると、オリジナルのプログラムが、入れ替えたDLLをLoadLibraryでロードしようとするとErrorCode 127(ERROR_PROC_NOT_FOUND)でエラーとなる。
何が原因でしょうか?
答えは、Visual C++2010のランタイムライブラリが内部でEncodePointer/DecodePointerという、Windwos XP SP2以降のKernel32.dllに実装されたWindows APIを呼んでいるからだ。素に近いWindows XPのKernel32.dllには、そういう関数は無い。そのため解決できずにロードエラーとなる。
で、このAPIは何ものか? と調べると、EncodePointerというように、exploit対策のためのポインタ曖昧化APIなのだった。
crtのソースを読むと、なるほど、onexitポインタのように、いかにも固定化しているとやばそうなポインタを曖昧化している。
やることをやっているんだなぁと、ちょっと感動した。と同時にマイクロソフトがやることをやっているのだから、素に近いWindows XPとか使ってはいかんよなぁという後ろめたい気持ちも生じるのであった。
# 面倒なのでやらないが、やってみるとどうなるか知りたいこと。EncodePointerで曖昧化したポインタをDecodePointerせずに踏むと、どういうエラーが表示(あるいはログ出力)されるのだろうか。
#include <windows.h> #include <stdio.h> int hello() { return printf("hello world\n"); } int main(int argc, char* argv[]) { int(*eptr)(); int(*ptr)() = hello; printf("%p\n", ptr); ptr(); eptr = EncodePointer(ptr); printf("%p\n", eptr); ptr = DecodePointer(eptr); printf("%p\n", ptr); ptr(); fflush(stdout); eptr(); return 0; }実行すると
c:\test>ptr.exe(上をコンパイルしたもの) 00811000 hello world 6E81F379 00811000 hello world (ptr.exeは動作を停止しましたダイアログを表示)追記:エンコードしたポインタへジャンプすることを想定しているのではなく、ダンプから取得した値へジャンプするライブパッチを作らせないことが目的なんだから、これで良いのだった。
マジ感動した!! / “小学生でもわかる計算だけで 0.9999…… が 1 な事を説明を読んで、学が乏しいおれは不思議になる。
0.11111...に置き換えて考えてみる。
0.1111... - 0.011111... = 0.1
で、0.111... をxに置き換えると、x - x/10 = 0.1
10x - x = 1
9x = 1
確かに、0.111..に9を掛けた0.999...は1なので整合性は取れている。
0.555...でやってみる。
x - x/10 = 0.5
9x = 5
トートロジーだった。
そこでふと気づくが、0.999...って有理数じゃないじゃん。そりゃ無理がきくのも当然か。
でも、なんだこの数は(数の紳士録)では紹介されてないや。
先月観たスカラ座のリゴレットはとても良かったが、今月は新国立劇場。
演出はモダンらしいが、それ以外はほとんど情報を持たないまま観始める。
と、モダンなホテルを舞台にしている。
ホテルを舞台と言えば、ラスベガスのホテルのショーフロアーで繰り広げられるメトのリゴレットをどうしても思い浮かべてしまうが、あちらがショービジネスへの置き換えに対して、こちらは暴力団の貸切宴会という風情で似ているようでも相当違う(が、どうしても似たような印象は受ける)。特に、3幕がメトはネオンが見える街道沿いの怪しい店というか街角に対して、こちらはネオンの裏側(つまり屋上)の怪しい集団で、ネオンが装飾となっているだけに近しいものがある。
しかしマントヴァ公の扱いは三者三様で、そこが一番の違いであった。
メトのマントヴァ公はショービジネスのスターなので、彼の回りの女性たちはスターの追っかけ(それだけにジルダが新鮮で、2幕冒頭は本気)、スカラ座のマントヴァ公は本当の公爵なので彼の回りの女性たちは当時の女性たち(それだけにジルダが新鮮で2幕の冒頭は本気)、新国立劇場のマントヴァ公は御曹司らしく女性は取り巻きが誘拐してきた見るからに犯罪被害者(相当価値観が歪んでいるので、ジルダも単にそのうちの一人として扱おうとしている魂胆が演出で示される、2幕冒頭も新しい相手に対する興味というか惜しいところで取り逃がしたという気分を示す演出)。
シナリオからは新国立劇場の演出はうがち過ぎだし、それほど気分が良い演出とも言えない。ただし、セットはうまくできていて、1幕の場面転換に余分な時間がいっさいかからないのは良い点だった(スパラフチーレと出会うのは1階のバー、リゴレットの家は上のほうのフロアーに借りている部屋)。
歌手は誰もが良い。マントヴァ公のキム・ウーキュンはええと驚くばかりの声量で、まずそこで驚いた。これまで4人くらいキムを観たけど、このキムが最も良いキムだ。
ジルダは金属的な声で最初いやだなと思ったが、楽器のようにきちんと演奏するすごい歌手、リゴレットは味があるすごく良い歌手、バスはまた妻屋か(他にバスはいないのか)と思ったらスパラフチーレも凄みがあり声が通り(最初にファーゾルトかファフナーで観たときは声が通らないバスだなぁと感じたのだが、オーケストラの編成に負けただけなのか、どんどん厚みが増しているのか)良い殺し屋だった。
C席8000円弱で、これだけ良いオペラを観られるのだから、まったく良い劇場だ。
(それにしても4階最前列は、手すりを撤去して欲しい。手すりのせいで舞台前面がまったく見えないからだ。大人の劇場なのだから興奮して落ちるばかは想定する必要ないし、あの程度の手すりではいずれにしても落ちるばかを止めることはできない、なんかくだらないエクスキューズなオーナメントだよなぁとつくづくうんざりだ)。
タモリ倶楽部見てたら、横須賀という谷戸の町がおもしろそうだったので、日曜日に出かけてみた。
タモリ倶楽部では、妙に細い道の中にある隧道をくぐりまくっていたけど、そこまでする気はないので、観音崎灯台にあるお台場を作るために寛永2年に手掘りした隧道ってのを取りあえず観ることにして、観音崎に向かったのだった。
ところが、どの駐車場も混んでいる。で、しばらく回りを何週かして(その間にも2つ3つ隧道をくぐる)、結局博物館の前の駐車場で15分くらい待っていたら入れた。
で、そこのイタリアンレストランがなかなか美味で驚いた(というのは、しょせん博物館/ビジターセンターの添え物のいい加減なお役所仕事だろうなとか想像していたからだが)。その日の地魚を使った定食は、いとよりのグリルマスタードソース掛け、ムール貝のパン粉揚げ、ラタトゥーユを添えた忘れたのグリル、バルサミコ酢掛け。随分凝っている。
というのは、どうでも良くて、観音崎灯台が思いのほかおもしろかった。というのは知らないことがたくさん。
まず、おれは浦賀と下田をごっちゃにしていたことがわかった。妻が浦和と浦賀をごっちゃにしているのをからかった後だけに、まったく無知の大口くらい愚かなことはないと反省。
次に、ペリーの要求に灯台の設置があったこと(それまで、日本には灯台がなかったらしいが、廻船問屋とか良く事故らないものだな)で、それを幕府が了承し、しかし幕府が消滅したので明治政府が履行したというのもおもしろい。
ここでフランス人の技術者(ヴェルニー)が灯台を作るのに大活躍。ヴェルニーは横須賀の製鉄所の所長も勤めた男で、観音崎灯台もその男の作品(土木工事だから一人で作ったわけではもちろんないにしても)で、他にもいくつも灯台を建てている。その男の引退後はイギリス人が大活躍。まったく明治時代のお雇い外国人の貢献というのはあらゆる領域にわたっているのだな。で、当時の横須賀の外国人の宿舎が立ち並ぶ写真とかがあって、そうやって開けたところなのかとわかっておもしろい。
さらに浦賀水道がなぜ狭いか(なんのことはなく、政府がというか軍が、海堡を設置して太平洋側から攻めてくる敵艦隊の東京上陸を阻止するため)というのも、そうでなくても富津岬との間がたかだか9kmしかないというのも初めて知ることばかり。それにしても、天気が良くてスカイツリーが見えるのには驚いた(灯台入場券売り場のおばさんに教えてもらった)。
というのも、観音崎のレストランを4sqに登録しようとしたら、金谷食堂とか、先日行った千葉は鋸山周辺の店がリストされるからだ。なんかぶっ壊れたのかと思ったが、過去のヒストリーとGPSの大ざっぱな位置情報から、それなりの精度で候補を出したのだなとそこで納得したのだった。
で、16号線を東京へ向かうと、がんがん隧道が出てくるので、なるほど、これは隧道が多いやと納得した。
しばらく行くと、右折の車がやたらとたまっているところに差し掛かって、右を見るとそこからぐるっと高架になって実は左折する道だとわかって、興味を惹かれる。左折するとがけなので、そこを昇るために一度右へ曲がってぐるっと半円を描きながら左へ戻り崖の上へ進む仕組みだ。追浜の手前の湘南鷹取入口というところ。で、途中で右、右、右で戻って鷹取のほうへ進むと、いずこも同じ、山の上は車を持っていて、駐車場付きの家に住む人の世界、山を下りると駐車場がない家に住む人の世界となっていて、それはそれでおもしろかった。
買って1年半のHTC Jがいよいよもってほたて貝になってきた(WiFiのみならずばしばし3G/1Gも落ちまくり、バッテリーがサドンデス、空ですというわりに再起動後50%とか)。
バッテリーがへたって電圧が不安定なのか(PCだとコンデンサーが膨らんだとか思うんだけど、スマほだし)、もっと重篤なのかわからない。(ウィルスチェッカーを外したらしばらくの間WiFiが使えるようになったけど、あれも電力負荷が一時的に減ったからではないか、とか考えてみる)
で、バッテリーを買うとかも考えたけど、もういいや、とHTC J ONE を買ってしまった。
で、事前に調べたらそういう文句が書いてあったが、確かに暗いところでカメラは紫になる。というか起動音がどうやってもばかでかくてどっきりする。しかも着信音切り替えのウィジェットが見当たらない。
と、不満点もあるけど、えらく速いし、画面が一回りでかくなって見やすいし、もしかしたらこれが最後のHTCだし、とりあえずはこれでいいや。
デセーをメインに据えて演出家のシヴァディエ、指揮者のラングレ(この人、イギリス移民か何かの子孫なのかな。妙な苗字に思える。丁寧な良い指揮者だけど先生っぽい)や他の共演者、練習ピアニスト(うまいものだし、しかも解釈を持っている。先生っぽい)、コーラス(そういえばオーケストラのほうはあまり描写がない)の人たちが、エクサンプロヴァンス音楽祭(席数が少なくてびっくり)のために、ヴェルディの椿姫を制作するまでの過程のドキュメンタリー映画。作ったのはフィリップベジアという作家。
フランスのドキュメンタリー映画って、以前見た行けラペビのニコラフィリベールもそうだが、モンタージュが実にうまい人が多い(というか、うまいドキュメンタリーが日本で公開されているだけかも)印象を受ける。唐突にダニエルシュミットやゴダールも優れたドキュメンタリー映画の作家だということを思い出す。ふと、日本の映画を考えると、市川崑の東京オリンピックが優れたドキュメンタリー映画(ニュース映画を期待していた人たちから酷評されることになったのはお互いに不幸なことだったと後知恵で考える)だったとか、神谷名前忘れた作家とかも思い出す。
この作品もドキュメンタリー映画として実にうまく、一貫して映画的だった。
シヴァディエ(映像に出てくる演出家は、誰もが映画的に振る舞うのは、そういう素養があるからなのかな。と、ヌーヴェルヴァーグ映画を撮るに出てくる作家たちを思い出す)の延々と語られる非常に手前味噌な解釈と、ヴィオレッタなら目を瞑っていても歌える(スタンダードなのでそう思うが、デセーが椿姫というのは違和感があるのも事実だ)デセー(なので、解釈をだらだらやられると茶々を入れたり、へらへら笑いながら振る舞ったりもしているのだが、その一方で、この人は本当にプロフェッショナルだなと感心するまじめさがあって、そのあたりの切り取り方がおもしろい。どのシーンで何をするかを、歌を歌って記憶していく箇所は興味深かった)の表現をめぐるバトルが映像の基調としてある。最後、ヴィオレッタが崩れ落ちるシーンを延々とデセーが練習する風景で締める。
それにしても、この映画を観ると、椿姫という雰囲気訳は、本当に、ミスリーディングだなと言わざるを得ない。シヴァディエの演出は、コーラスへの指示やジェルモン役のカストロノーヴォへの指示を見ている限り、楽しい夢のような世界(シャンパンの泡のようである)と、ヴィオレッタの孤独な生涯を対比させることに重点を置いているように読める。したがって、椿姫ではなくトラヴィアータでなくてはならない(ことを強調するために、背面に大きくその文字が描かれる。しかしそれは3幕で拭い去られる)。そこで映画の最後で繰り返される崩れ落ちるさまは、魂の救済(肉体は地へ、魂は天へ)を意味することになり、映画の締めであり、延々と練習する様子はデセーがシヴァディエの演出を納得したこと(映画のテーマである女優と演出家のバトル)の止揚となる。
うまいものだ。
Verdi: La Traviata [DVD] [Import](Natalie Dessay)
が、これがモダン演出は別として、スタンダードな椿姫の音楽かと言われると、それは違うんだな。おれはデセーのファンだから好きだけど。
トイレ砂を3種類ほど試したのでメモ。
最初に、次のトイレと砂を購入。
トイレは何も考えずに、家の近所のスーパーで一番安かったので買った。良い点:安い。洗うのは簡単(だけど、砂の入れ替え時しか丸洗いとかできないよね)。悪い点:機能性が無い。
子猫っぽかったときは何も言わずに使ってくれたので良いトイレだと思うが(入りやすいとか、砂が入っていることが見えるとかの、視点の関係も良いのだろう)、成長すると浅いからか、砂が飛び散る(ただし砂が原因の可能性も高い)。
同じく安かったので買った。匂いがあまり出ない(これは不思議なのだが、大便の回りにまとわりつくだけで消臭効果を発揮するのだな)、尿はきれいに固まるとか、スタンダードっぽい。
良い点:尿の固まりをトイレ付属のシャベルですくった後、軽くゆすると、使われていない砂は簡単に振える。飛び散りにくいかも知れない(他の砂へ変える都度飛び散る量が増えたのだが、それは猫が成長したからだと思っていた。でも、この砂は砂自身に重さがあるので飛び散りにくいかも知れない)
悪い点:使っているうちに粉末化してくる(おそらく尿を固めた部分のうち取り切れなかったものが、そうなるのだと思う。が、これはすべての砂について言えると思う)。
というわけで、悪くなかったのだが、しばらく使っているうちに不満点が出て来た。
ビニールにくるんで、ゴミ箱に捨てていたのだが、いくらビニールにくるんでいても匂いが出てくる。可燃物の収集日は週に2日なので、結構辛い(2匹だから出る量も倍だし)。普通にゴミ箱に捨てると猫がいじくるのでゴミ箱の上に重しを乗せて蓋代わりにしたが、匂いまでは止められない。
というわけで、最初は蓋付きのゴミ箱を購入。
Galva Square Dust Box [3L/ピンク](-)
これは良い。が、蓋を開けるととんでもない異臭が漂い出すことになってしまった。ある程度はがまんするにしても、もっと根本的に見直す必要があるぞと気づいた。
そもそも、排せつ物を流すために水洗トイレがあるのだから、猫の排せつ物も同様に扱えれば良いのではなかろうか? 問題は、砂なのだから……水洗トイレへ廃棄可能な砂もあるのではないか? と気づいた。
で、子供が近所のスーパーのペット売り場の人に聞いて購入してきたのが豆腐(といわずにオカラと言っているし、それが正しいのだろうけど、匂いはどうやっても豆腐)の砂。
これは相当良いものだった。豆腐の匂いも悪くない。猫も気に入ってぽりぽり食べる(トイレと認識しなくなるのではないかとびびったが、2~3日したら食べるのはやめた)のはちょっとひいたが、流せるのが良い。
吸臭性も悪くなく糞の回りにつくと匂いを結構吸い取る。ただ、尿を固める能力はちょっと甘くて、掃除は大変になった(複数の砂が凝固せずにふやけた状態でとどまっているので取り除く必要がある、というか最初の砂でも同じことだったのだろうとは思うが、こちらのほうが粒が大きいのでふやけたハグレ砂が目立つ。しかし、留守をしていたあとに取り除こうとしても、混じってしまってどれがそうなのかわからなくなるのが問題)。
で、この取り損なったハグレ砂が、猫がトイレを使うたびにかき混ぜられて粉になり、悪臭を漂わせることになった(おそらく上に粒状の砂が残っているからだろうが、トイレから離れると匂わない。しかし掃除のためにトイレの上に屈みこむとアンモニア臭が相当来る)。
しょうがないので、別のやつを試した。
ここまで、鉱物、豆腐と来たので、今度は木にしてみた。
これは最初、閉口した。風呂の入浴剤のような人工的なヒノキの匂いがしまくるからだ。おれは何が嫌いといって人工的な自然物の匂いが嫌いなのだ。これなら豆腐にしみこんだ尿臭のほうがましだ。が、しばらくたつと慣れてしまったのか、きつい匂いは発散してしまったのか、それほど気にならなくなった。
驚いたのは、粒が大きいことと、猫が成長したこと、トイレの縁が低めなことの3重効果で、すさまじく砂が飛び散ることだった。それは、補充する回数を調整して少しずつ減らして対処(豆腐のときより少ない量にしたわけだ)。ただ、粒がでかいので掃除(トースト用の卓上ほうきと塵取りセットを用意してある)は楽だということと、猫の足の裏にはつかないのか、遠くにいきなり落ちているということはなくなったので、差し引きはプラス。
糞臭は同じく取り除かれる。固まり具合は豆腐よりは強いが、それでもハグレ砂は出てくる。ただ、色が変わるのでわかりやすい。後、微妙なところだが、粒が大きいので救ったあとのトイレ付属のシャベルの篩では余計な砂が取り除けないので、常に余計に捨てることになり、結果的にハグレ砂が出にくくなった。
というわけで、ひとまず木のやつを利用することにした。
でも、やはり匂いは好きではないので、しばらくしたら、豆腐に戻る可能性はある。
というのがメインのトイレの状況。
それとは別に、猫の保護者から教えてもらったシステムトイレというのを2台目として購入した。
システムトイレは、鳥籠のように底が引き出し式になっていて、底には吸収性マットを敷き、それが尿を吸うので取り換えられるようになっている。大便は砂と一緒に上に溜まるのでシャベルで除去。
最初に買ったトイレとの一番の差は尿の掃除が1週間に1度とかに激減することにある。
で、イオンに行って調べたが、システムトイレは、花王かユニチャームかアイリスオーヤマというところあたりが出していた。
重要なのは底に敷く吸収性マットの出来不出来なのだろうから、生理ナプキンのユニチャームか、紙オムツの花王か、ということだろう(という他の製品の技術流用を想定したので、メガネの印象しかないアイリスオーヤマは脱落)。で、なんとなく花王は好きになれないので、ユニチャームを選択した。
デオトイレ 1週間消臭・抗菌デオトイレ フード付き本体セット (アイボリー)(-)
とりあえず元のトイレの掃除はそれほど困っていないので、システムトイレはリビングに置くことした。こちらは人間が飯を食うところでもあるから、砂が飛び散らないようにフードが付いたのを選択した。
で、置くと不思議なことにすぐに猫はそれがトイレだと認識するのが、おもしろい。確かにこれは便利だし、人間が猫の世話(尿の始末)にさかれる時間が激減するので、最初に買ったトイレもシステムトイレにしようかなぁと迷う。
B00C185YKU
10枚(1匹1週間が目安ということは2匹なら3~4日で、可燃ゴミの収集日に合わせれば良いのだろう)で1000円強なので、コスト的には砂(7リットルあると1ヵ月はもつ)が月あたり600円くらいに対して、やはり600円くらいということで、それほど差は無い。
デオトイレ 1週間消臭・抗菌 飛び散らない消臭・抗菌サンド 4L(-)
しかし、大便用の砂がトイレに流せない。システムトイレの性格上、トイレ砂には可溶性が無いからだ(尿を網目から落として底に敷いたシートへ染み込ませる仕組みだから、砂そのものは溶かせない)。
ゴミ箱の中のネコの大便と3~4日過ごすか、小便の始末を楽にするかという問題である。でも大便と過ごすのがいやで流せる砂をいろいろ試したのだから、結論は決まっているのであった。
で、結局、最初の配置(メインは普通のトイレ、リビング(それほど利用しない)にシステムトイレ)とした。ほぼ大便はメインのトイレでするのでこれで良いのだ。
岡本太郎の家へ行くと、庭に坐ることを拒否する椅子が置いてあって、座れるようになっている。で、座ると尻が痛い、あるいは落ち着かない。
その後、アップルのMacBookPro(そのころはPowerBookという名前だった)を買って、夏になって「おー、これがアップルのデザイン思想か。つまり、打鍵を拒否するキーボードということですな」と納得した。すごく先進的かつアートなコンピュータなのであった。こんなコンピュータはデルやNECには作れるはずがない。
でも、風のうわさによると、最近のSSD版は打鍵できるらしい。
APPLE MacBook Pro 13.3/2.9GHz Core i7/8GB/750GB/8xSuperDrive DL MD102J/A(-)
WebMVC(面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい)というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装(貧血)と最悪のDomain Model実装(鬱血 )が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど問題はない。
トランザクションスクリプトパターンというのは、コントローラに直接スクリプト(脚本つまり処理の手順)を記述するスタイルだ。想像通りに、コントローラの入り口から出口まで処理が記述される。とはいっても、通常はVにはそれなりに便利な機能があるので直接HTMLを吐き出すことはない(必要ならば吐いても良い)。この場合、Mの仕事はデータベースとの直接的なインターフェイスとリソースの管理となる。たとえば、次の疑似コード(C#とJavaとJavaScriptとRubyのごった煮)はトランザクションスクリプトだ。
void fooBar(request, response) { if (request.param[0] ... ) { // 入力をチェックしてみる response.redirectTo('error'); } var cmd = (new Model()).connection.createCommand(); // Mはコネクションプールの取得元としてしか使わない cmd.query = "select * from tbl where a = ? order by b"; // いきなりSQL cmd.params.add(request.param[0]); var rows = cmd.executeQuery(); response.params.add(rows); // 結果をビューへつなげる }
これでいいのか? もちろん全然OKだ。
なぜOKなのか? とは考えない。なぜだめなのかを考える。保守性が低い? 別に低くない。見通しが悪い? 全然悪くない。だめな理由は「それはMの責務であって、Cの責務ではない」という教条主義に抵触するというだけだ。くだらない。とはいえ、外部インターフェイスの端点の管理(ここではConnectionの取得、初期化など)はCからは遠ざけておくほうが良い。
で、時が流れたり、いろいろあって、次のようになったとする。
var conn = (new Model()).connection; conn.startTransaction(); var cmd = conn.createCommand(); // Mはコネクションプールの取得元 cmd.query = "select * ... inner join ... "; var nextParam = cmd.readScalar(); cmd.query = "update other_tbl set a = ? ...."; cmd.params.add(model.adjustParam2(request.param[2].toInt())); (さらに3つくらいのテーブルをいろいろいじくりまくり、パラメータをとっかえひっかえしまくる) conn.commit();
ここに至ってはじめて、それはCの責務ではないと言えば良いのだ。そこで、ごちゃごちゃしたものをMへ移動し、
var model = new Model(); mode.fooBar(request.param[0], model.adjustParam2(request.param[2].toInt())); reeponse.params.add(model);
ドメインロジックはモデルの責務、とすれば良いだけのことなのだった。
が、それがすべてでも無い。
もし、作成期間が山ほどあれば、最初のfooBarのSQL呼び出しがMにあれば、Mをテストするコードが書きやすい(RequestやResponseのモックが不要だからだ)。なら、Mでやるべきだ。
もし、このコードが仮置きですぐに別の言語/フレームワークなどで書き直す予定だったり、すぐに引っ込める可能性が高いサービスなのであれば、そもそもMにConnection管理機構を持たせる必要すらない。複雑になってきた例ですら、別に問題ない。そのままでOK。メソッドの抽出や分離ができるように考慮することだけが必要なのだ。
MとVとCに分割するメリット(コードの管理、ロジックの整理、拡張や修正を局所化できること、テストの記述が簡単になることなどなどたくさんある)とデメリット(管理すべきソースが増える、単純な処理でもコードナビゲータなしでは読みにくくなる、記述量の増加(特にJavaのようなおまじない系コードが必要な言語だと顕著)、エディターを選ぶために開発マシンのスペックが良くないと辛いとかたくさんある)はプロジェクトどころか、1URIについてですらばらつきがある。
そういうばらつきを無視して、なんでも同じやり方を適用しようとすることこそ避けるべきことなのだ。つまり、本当に必要なのは、MVCそれぞれの責務がどうしたというような特定パターンの知識を頭にたたき込むことではなく、そのプログラムの仕様を実現するには、どうすれば最も効率的(実行効率、保守効率、作業効率、管理効率、検証効率、配備効率などなどのさまざまな切り口について)なのかをさまざまなケースについて独立して考え、実装できることだ。
おしまい。
参考資料
エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)(マーチン・ファウラー)
とはいえ、
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)(Dustin Boswell)
どんなすぐれたデザインもコードが汚ければすべてが意味ない。リーダブルなトランザクションスクリプトパターンのほうが、アンリーダブルなドメインモデルより数1000倍良い。
猫のトイレ事情を書いたら、ogijunが使っているトイレを教えてくれた。
アイリス 散らかりにくいネコトイレ CNT-500 イエロー(-)
今の問題点は、ほぼ砂の片づけと散らばりになっているわけだが、見る限り、フードがあるから散らばりはなさそうだし、妙なギミックがあってネコにも楽しそうだ。
というわけで、えいやと買ってしまった。
いや、これはでかい。
設置面積も元の単純な開放型トイレより一回りでかい。
それに入口が高い。
なんでこんなにでかいのかと、フードを開けて納得した。
左の入り口から∩型の通路になっていて、右が砂場、左がスノコ状の砂落とし場になっているのだった。
入口は相当狭く感じるが、そこはネコなので問題はないとは思うが(ogijunのネコたちは子猫というわけではないと思う)、それでもトイレと納得してくれるのかえらく疑問になる。
で、黒坊と白坊が見ている前で、以前のトイレからの砂の移動とか見せる(ここで、新しい砂+古い砂の順に入れれば良いのに、全体の容積が今一つわからないので、新旧が逆転することになるのだが、それはまあどうでも良い)。さらに、蓋を全開状態のまま、それぞれ砂場に入れてやったりして、納得させてみる。
さらに蓋を被せて、入口から入れて見せてやるのだが、好奇心旺盛な黒坊は勝手に入って∩の右端点でUターンして戻って来たが、白はどうやっても入ろうとしない。えらく不安になる。
が、とりあえず、説明書にある潜り戸は慣れるまで撤去しろというお勧めに従って撤去したほかはそのままにして置いておく。入口も微妙に床から高い気がするので、薄い段ボールの箱を踏み台に置いておく。
しばらくすると、黒はちゃんと用を足して戻って来た。
が、白の動きが微妙過ぎる。もじもじそわそわしているのが、トイレの合図なのか、猫特有のびくびくなのかわからないので見守るしかない。
以前のトイレはとりあえず片づけてしまったので、システムトイレを使える状態にしておいて(普段は入らない部屋なので入口を閉めてあるので、その手前に持ってきておいた)放置しておくしかない。でも面倒なので眠ってしまったら、朝になったらちゃんとしていたらしい(ただ、入るところは見ていないので、すでに3日間我慢していたり、人が気付かぬ場所でしていたりして。で、それに合わせて黒坊が2倍排泄するとかあり得ないので問題ないのだろう)。
良い点:散らばらないというのはその通り。
開放型よりも砂を入れる場所が狭いのと散らばらないのとで深く入れることができる。すると実は木の砂は結構固まる能力が高いことがわかった。
掃除は想像よりは大変ではなかった。むしろ、砂を深く入れることによる良い効果(固まりやすい、匂いがしにくい)が得られる。
用足し中に顔を合わせることがないので、多分、ネコも落ち着けるのではないかなぁ(ネコじゃないのでわからないが、排泄中に見られるほうが幸福という獣はいないはず)。
残念な点:蓋に脱臭剤入れがあって、良い工夫だと思うのが、どちらの坊主か知らないが、カバーをはずして段ボールハウスに脱臭剤を隠していた。もう少し、猫には開けられないようにしたほうが良いなぁ(テープで蓋を止めるようにした)。
というわけで、実に良いものだった。ogijunありがとう。
26日は、新国立劇場でフィガロの結婚。
ホモキの演出はこれで2度目だが、今回のほうがぴんと来た。後で、バックステージツアーに当選して説明を聞いたが、前回はフルに舞台を使えたので庭師が上がって来る梯子は奈落から突き出したが、今回はリゴレットの舞台を地下に格納していた関係で横から1/4回転して突き出したとか。そんな違いはまったくわからなかったが、ツアーに参加していた人にわかっている人がいて、良く観ているものだなと感心した。
前回も序曲が快調だった記憶があるが、今回のシルマーの指揮は印象としてはさらに快調そのもので、聴いているだけでわくわくして来る。後、異様にソナタ形式の構造が浮かび上がって来てちょっと不思議だった。
フィガロのヴィンコという人は背が高いすっきりした歌手。歌もすっきりしていてしゃれた感じ。スザンナの九嶋という人はアシメトリクな衣裳が似合うコケットな感じでスザンナっぽい(結構、観ている歌手のはず)。アルマヴィーヴァ伯爵はヒゲのおっさんでプログラムに書いてあるセクハラおやじという言葉が似合う人。伯爵夫人のフレドリヒという人は最初、音程が不安定かなと思ったが(音程が本当に不安定なのは金管で、今回は意外と良くないなと思った)、きれいな声で印象が実に良い。でも特筆すべきはケルビーノのレナベルキナというウクライナの人で、顔も演技も歌も可愛い。
でもモーツァルトなので半分退屈しながら聴いているわけだが、何か所かはっとする箇所がある。これまで気付かなかった。
ケルビーノとスザンナが入れ替わった後のスザンナと伯爵夫人の二重唱が良い。
次に、結婚行進曲が実におもしろい(序曲もそうだが、シルマーという指揮者は曲の構造を浮かびあげるのがうまい)。
そして、フィガロがスザンナだと見抜いてちょっかいを出してスザンナにぼこぼこにされた後に、愛する人の声はわかるもんだ、声!? というやり取りで始まる歌の美しさにはびっくりした。なんてきれいな曲を作るんだろう。その歌の美しさに驚いているまま、伯爵夫人の許しの歌になるのだから、思わず感動してしまった。モーツァルトの音楽のくせに生意気だなぁ。
結局、ウルフ・シルマーが抜群なのだと思う。実に良い指揮者だ。
あと、ドンクルツィオの糸賀という人が実に良かった。
OSX snow leopardのApache2をぐちぐちいじる必要があったのでメモ。
・リスタート
sudo /usr/sbin/apachectl restart
なぜかreloadはない。
・mod_rewrite
OptionsにFollowSymlinksを追加する
(Apache2のデフォルトが変わったからだろうけど、mod_rewriteってsymlinkを作って実現しているのか?)
・user.conf
/etc/apache2/httpd.confとは別に、/etc/apache2/users/ログインid.confが作られて、そこでAllowOverride Noneが定義されているので、.htaccessを設置する場合には修正が必要。
ジェズイットを見習え |
_ shiro [小数表記の定義から、あらゆる有限小数には、0でない最後の桁を1つ減らしてその後に9を無限に続けるという「別バージョン..]
_ arton [おお、なるほど。別バージョンの定義があって、(定義である以上)整合性がとれるように定義されている、と理解しました(合..]