2012-12-24

『会社神話の経営人類学』



これを眺めてへえ、と思って手に取った本。たしかに、着眼点がめっぽう面白い。が、一方でうーん?となるところもあった。

著者たちは、会社にまつわる様々なポイントを人類学的に研究するという研究プロジェクトの人たちで、本書はそのうち、「神話」に焦点を当てた論考を掲載している。
会社にまつわる内部のことばがいろいろある。これを人類学における神話である、と見做した、というのが本書のひとつの成果だ。たとえば「社史」というものがあったりするわけだが、そこで語られている創業に至る過程はある種の創世神話であり、活躍する初期の社員たちの物語は英雄神話となり、受容されていくと指摘している。

この着眼点はめっぽう面白くて、↑の山形浩生の紹介文や、本書の序文などを読むとそれだけで「これは面白そうだ!」という気分になる。
が、一方で、個別の論考については、だからどうなんだろう、というのがもうひとつわかったようなわからなかったような気分になるものもあった。ひとつには、自分は門外漢なので細かな問題意識や前提となる用語の定義からしてよくわかっていない、というのがあるのかもしれない。「神話」というのは一般名詞でもあるため、定義には慎重であるべきだが、よくわからないまま話を進めてしまっているものもある。何を神話と呼ぶか、といった定義づけをやっている章も多く、それはよいのだが……。会社の創業にまつわるエピソードが、これは創業神話だ、ということが言えたとして、だからどうなんだろう、という先に踏み込んでおらず、エピソードをピックアップして、神話との類似性を指摘しただけの論考もわりとあったように思う。たとえば「オーケストラの神話」は、ウィキペディアによくある雑多な事例の箇条書きから踏みでた部分がすごく少ないと思う。

もちろん、神話であるからどうなのか?というところに踏み込んだ論考もちゃんとある。神話というのは、共同体のあいだで共有され、真実であるとみなされ、行動規範になったり、様々な風習……たとえば社内行事であるとか、社内の独自の研修であるとか、文化であるとか、そういったものを形作る役割を持つ。誰それがこう言った、というエピソードは、長い歴史のなかで現実から離れ、類型化し、あるいは言い直され、社内の価値観や文化に影響を及ぼす。

そもそも「社史」を神話の典拠とみなすというのは、それほど自明な話じゃなくって、なぜなら社史というのはそもそも事実を記載していくものである……だが実際には社史には様々な言葉がはいっていて、実際に神話的な影響を社員に及ぼしている、なんてことを言ってのける。

安い本でもないのでおすすめ、というほどでもないですが、まあ面白い本ですよ。

--

しかし、いちゃもんを上でつけたけれども、実際、この着眼点から自分の周囲を見渡してみると、ちょっと違った風景に見えてくるのも確か。自分の勤務先も、それなりにおもしろい神話をいくつも持っている。勤務先はアメリカの会社で、社史とかそういうもんはないけれど、外部からジャーナリスティックに、たまにおもしろ半分に、取り上げられる言葉がそういう神話を形作っている。

……まあ、勤務先の話ばっかりするのはあれだが、こんなものはもっと言えば会社に限った話でもないのではないか? たとえばハッカーコミュニティは、さまざまな英雄たちの神話に彩られているといえるのではないかなあと思ったりする。様々な先達たちの活躍はどちらかというと英雄神話の彩りを帯び、それ以外の人間の行動規範となっている。

そうやって素人的にあれこれ拡大解釈していくのは、実際どうなのかなあとも思うわけだけれども、それはそれで素人なりに楽しい。本に書かれている内容それ自体よりも、そうやってあれこれ考えることのほうがむしろ面白いとさえ思える本だった。

2012-12-04

チューニョを作ってみた

前に高野豆腐を作ったときに最後に言及したチューニョという食材を作ってみました。どうでもいいことですが、前に書いたときは微妙にいい間違えをしてました。
スープで煮込んだ。詳細は下記

ところで今回は写真をあんまり撮ってませんでした。使えねーな俺……。

さて、チューニョとは何かというと、じゃがいもを冷凍して脱水することで作るヤツのことです。東北地方でも凍みイモといって似たような食い物があるのだそうな。

高野豆腐は豆腐を凍らせて解凍してを繰り返してスポンジ状の食感を作り、ギュッと絞って脱水し、乾燥させて作ります。チューニョも基本の製法は一緒です。原産地(?)では、冬にその辺に放置しておくと凍結し、朝になると自然解凍し、ということになります。解凍したイモを足で踏んづけて脱水していくのだそうです。

北カリフォルニアは年中あったかいので、その辺に放置しても凍ることはないため、普通に冷凍庫に入れて凍らせ、朝になるとその辺に取り出して自然解凍させ、というのを実施しました。足で踏むのはさすがに抵抗があるので、手でぎゅっと絞ったり、上に皿をかぶせて膝立ちみたいな感じで体重をかけたりして、脱水をしていきました。これは確かにちょっと楽しい。

ある程度の脱水が済んだら、絞ってももうあんまり水分は出て来なくなります。そうしたらその辺に放置して、1週間ほどしたらかなり乾燥していました。

などと書いていますが、実はこれ、いっぺん失敗しました。なんか上に重しをして放置したら脱水が進むかなと思って試してみたところ、絞って出てきた水分に漬け込むかっこうになってしまい、漬物臭を発する物体となってしまい、泣く泣く捨てました。そういう余計なことはせずにその辺に放置するのがよいと思われます。

とにかく手で絞って乾かしてを繰り返すと、本体はシワシワになり、握り込むときの関係で皮がめくれてベロベロになります。皮がめくれて空気が触れている表面部分は黒く変色します。大してうまそうには見えない。
シワシワで黒い
こうなると完成ですが、食べる前にはまず、これを水に一晩ほど漬け、戻す行程が必要です(↑の写真は一瞬水につけた後、「写真いちおう撮っとくか」と撮ったもの水滴がちょっと見えるのはそういう理由です)。脱水したのに戻す……まあ乾物とはだいたいそういうものですかね。
戻したあと。あんまり変わってない
さて、戻すとどうなるかというとこうなりました。大きさ、あんまし変わってない……。写真を見比べるとシワは減ってるような気がします。ただ、水分を含んでいるものの、瑞瑞しさもさっぱりありません。じゃがいもらしさもありません。切った断面など、強いて言うとバナナに似ている感じ。なんかねっとりしてるし。あんまり戻ってないんじゃないかなあこれ……という気分。

でもまあヤバイ臭いはしないし食えそうだ。というわけで、炒めるよりは煮込む感じかなーと、ベーコンとキャベツとコンソメの素で煮込んでみました、というのが上の写真となります(やたら黒いですがそういうスープの素なのです。でもちょっと濃すぎた)。

適当に煮たあとでしばらく冷まして含め煮、ということにしましたが、冷ましている間に急激にスープを吸い込んだらしく、いきなりほぼ元と同じぐらいのサイズにまで肥大化しててビビりました。スープは中まで染み込んでおり、まあまあうまい。スープにしてからもすぐ食べず、一日ぐらい置いておくといっそう美味しかったかもしれない。確かに煮崩れることはなさそう。

イモっぽい食感もありつつ、ねっとりともしていて、独特っちゃ独特だし、スープを吸うので美味しいといえば美味しい。

けどまあ、わざわざ手間暇かけるほどの食いもんじゃないのは確かです。たぶんもう二度とやらん気がしますが、実験としては楽しかったので良しとしましょう。スーパーとかで売ってたら買ってもいいんでしょうが……まぁでもわざわざ買うほどでもないか、戻すのめんどいし。

2012-11-18

ファンタジーTVドラマ『Once Upon a Time』が面白い


というわけで引っ越してnetflixに加入したところで、 Once Upon a Time というテレビドラマを見てたのだけど、これが面白い。脚本は『Lost』などの脚本をしてきたエドワード・キトシスとアダム・ホロウィッツ。

このドラマでは、昔話の物語と現代が交錯する。メイン州にある小さな街、ストーリーブルックに住むのは、実はおとぎ話の登場人物ばかり。ただし、邪悪な女王の呪いにより、人々は全てを忘れ、普通の日常生活を営んでいる。この呪いを解けるのはただ一人、白雪姫と王子様の間に生まれた女の子、エマ・スワン。彼女はまさに生まれたばかりのころに発動した女王の呪いをからくも逃れ、ひとり現代世界にやってきていた。

生まれたばかりで何も知らない彼女はそのままストーリーブルックとは関係なく現実世界で成長し、ボストンで生活していた。だが、そこにヘンリーという少年がやってくるところから物語は幕を開ける。ヘンリーはエマが19歳のときに産み、そのまま里子に出した実子だという。そしてヘンリーはエマをストーリーブルックに誘う。そして、全てを伝える。ストーリーブルックの人々は、記憶を失ったお伽話の登場人物たちであること。ヘンリーを引き取った義理の母が邪悪な女王であり、いまはストーリーブルックの市長であること。などなど。もちろん、普通に育ったエマには、そんなことはとても信じられない。だが利発そうな子、ヘンリーがそういうことを言っていたり、継母とうまく行ってなさそうなのは気にかかる。そこでストーリーブルックにしばらく滞在することを決意する……。

ちょっと長いあらすじだけど、これが基本設定。各エピソードでは、おとぎ話世界でその昔、彼らが行動したことと、現代のストーリーブルックでのことが交互に語られ、そもそも昔、何があったのかという謎と、ストーリーブルックでこれからどうなっていくのかということが少しずつ視聴者に明らかになっていくという趣向。

おとぎ話の世界はわりといろいろなんでも詰め込まれている。ベースとなるのは白雪姫と王子様、女王をめぐる物語だが、それもぼくらのよく知る白雪姫とはちょっと違う。女王の元を追われ、狩人に見逃してもらった白雪姫は盗賊をしており、王子様を襲撃するというかたちで最初の出会いがあるし、王子様と隣国ではシンデレラがいるけれど、シンデレラを助けるのは妖精の女王ではなくルンペルシュティルツヒェンだ。ルンペルシュテルツヒェンはその後もあちこちで顔を見せる主要キャラクターであることが次第にわかっていく。

そして、各キャラクターの過去が少しずつ語られていく。白雪姫と王子様がどう出会い、どのように結ばれ、毒のリンゴとキスによる復活はどう起こるのか。王子様はどのように生まれ育ったのか、女王はどうして邪悪に染まったのか、7人の小人はどのように白雪姫と出会ったのか、鏡の由来、などなど。時としてあまり関係のない、シンデレラやヘンゼルとグレーテル、マッドハッターなども顔を見せ、この物語の主要な謎を埋めていく。

一方で、現代パートも少しずつ物語が進んでいく。白雪姫はいまでは小学校でヘンリーのクラスを受け持っている。いっぽう、ボランティア参加の病院では、名前のわからぬ患者として王子様が昏睡状態で寝ている。狩人は保安官をしているし、赤ずきんはカフェでウェイトレスをしている。ここにエマがあらわれることで物ごとはどんどん変化していく。王子様だったデイビッドは目覚め、白雪姫だったメアリー・マーガレットとやはり恋に落ちる。でもデイビッドにはキャサリンという妻がいる。キャサリンはおとぎ話世界ではミダス王の娘で、王子様と婚約していたのだ。そして、そして……。

ようやく1シーズン全て(全22話)を見終わったところでは、意外と話としては一段落している。アメリカのドラマにありがちなように、きちんと完結して大団円というのではなくて、思いっきり「ヒキ」で終わってはいるのだけれど、上で書いたような基本設定はそれぞれきちんと謎が語られ、物語は終わりを迎える。気になる続きは、ただいま第2シーズンが放映中なようだけど、netflixではまだ見られないので見ていない。まあアメリカのドラマというのは、そうやってどこまで面白くなるのかはわからないもんだけども、少なくともこの第1シーズンは面白い。

そういうわけで、かなりオススメです。役者の中では、ヘンリー役のジャレッド・S・ギルモアがいい。利発そうな子供の役をこなしている。

2012-11-14

レコーディングソーシャルダイエット、途中経過

はい、というわけで、オンライン上のソーシャルサービスを、無為に長時間利用するのを避けるために記録するというプロジェクトですが、まあまあ継続しています。しかし、記録しわすれもそれなりにあるという現状です。

記録内容について書いていませんでしたが、実はソーシャルなサービスだけじゃなくて、Google Readerなどの巡回も記録に取ることにしています。ぶっちゃけて言うと「ネットを使ったヒマツブシ」全般ということになりますでしょうか。

で、記録しているだけでも、1日に2時間程度はこういうことに時間を費やしているようです。予想以上に時間を使っている気がします。ゲームは1日1時間、とはちょっと違うかもしれないけれど、もうちょっと減らすべきですかね……。

ただ、当初の目論見通り、細々とした時間にちょくちょく見てしまうという問題は少し減っていると思います。習慣的に見てしまうことで時間を浪費することは減って、じゃっかんの時間の余裕もできつつある気がします。

とはいえ、そうそう思うようにはいきません。そもそも、特にナンにもしたくないダラダラしたいという状態がまずあるのであって、ヒマツブシの種を削ったとしても、ほかのどうでもいいことで時間を消費するだけという、なかば予想していた状況にもなってきました。まあ、ダラダラしたい時間にはダラダラするのがいいのではないかとも思うのですが、さて、どうしたもんでしょうね。

以下、枝葉末節ながら、記録を取る以外にやってみたことを適当に書いてみます。

  • 前にも書いたように、ケータイのホーム画面からもアプリのショートカットを削除。アプリ自体は残しておくが、せいぜいちょっとだけアクセスを悪くするため。
  • ところが、ケータイでの用途は、ちょっとしたあいた時間を潰すというものなので、アクセスを悪くする程度ではだめ。他のヒマツブシアプリがほしい。
    • キンドルは、ひとりで食事をするときなどはいいのだが、もう少し短い時間には向いていない
    • メールはそういうのに比較的向いているけど、いつも未読があるわけでもない
    • というわけで、InstaFetchというアプリを導入した。Instapaperで「あとで読む」にした記事を自動的に同期してくれて、いつでも読めるようにしてくれるアプリ。ロード時間がほぼかからないので、ちょっとした時間潰しに便利
  • いままで、こうしたサービスについては基本的にタブを開きっぱなしにしていたのですが、とりあえず閉じて必要なときに開くように方針転換。根本的に、こういう問題意識を持ってるのにタブ開きっぱなしはイクナイ。
  • こちらはいいヒマツブシの代替案がないのが現状。まあ本を読むぐらいかな……
というわけで、まとめると、そんなに順調というわけでもないですが、まあまあ続いています。

2012-11-09

財布なし生活のその後

おそらく誰も覚えてないと思いますが、年初から財布のない生活というのを試してました。せっかくなので近況を報告します。というか、まあ、ざっくりいうとわりと敗北な感じの話です。

改めて書いておくと、当時試行錯誤して到達したのは、財布に入れていたもののうち、
  • 小銭類は普段はあまり持ち歩かない、もしくは小銭入れをカバンに入れる程度に留める。お釣りの小銭はポケットにそのまま入れる
  • お札のためにマネークリップを使う
  • カード類はよく使うものだけを輪ゴムでまとめておく。残りは名刺ホルダーにまとめてカバンに入れておく
などと分散させるというものでした。小銭入れはけっきょく使っているので、ゲンミツに言えば財布の撤廃ではなくなったわけですが、普通の厚さの財布を後ろのポケットに入れておくよりはだいぶコンパクトになりました。

ただ、カード類に問題が出てきました。というのは、輪ゴムでとめるのはラクでいいなと思ったのですが、そのままずっとポケットに入れておくと、だんだん褪せてきたわけです。表面の色が少しぐらい剥げるならいいかと思ってたのですが、カード類で裏に書いた名前とかが読み取りづらくなってきたような気がしてきたので、これはちょっと別な方法を考えたほうがいいんじゃないかと思ったわけです。

で、リンク先の radium software の人でも、実際にはカード類には封筒を使っていると書いてあります。私もたまたま、カードにあうサイズの封筒をまちなかで見かけたので、これがいいんじゃなかろうか、と思い、切り替えることにしました。

ただ、これはもう生活スタイルか何かの問題だと思いますが、紙の封筒というのはかなりすぐボロボロになります。まあちょっとぐらい穴が開いても、カードをまとめて持ち歩くという用途には使えるのでいいんですが、しばらくすると完全にフチが破れて、カードを紙で巻くぐらいの状態になってしまうため、ある程度の頻度では交換しないといけなくなることに気づきました。

それでも引越しをするまで、ようは9月頭ぐらいまでは、ずっとそういう生活スタイルだったわけですが、アメリカに来てそういう封筒をどこで買えばいいかも定かではなくなってしまいました。まあ探せば普通にあると思いますが、カードを入れて持ち歩く用の封筒などというものを探してあれこれ吟味するぐらいなら、普通にカードホルダを買えばいいんじゃない?というかなり台無しな結論に到達してしまいました。

そんで買ったのがコレです。

数枚程度のカードが入って、マグネット式で紙幣を留める機能があるカードホルダです。まあまあ薄いし、たいしてかさばらないのはよいと思いました。どっちみちアメリカではほとんどの場合はクレジットカードが使えるので、現金を使うことは少ないんですが。

というわけで、カードホルダ兼マネークリップと小銭入れに分散しているので、いちおう「財布」は持たない生活になってるかもしれないけれども、まあ、当初の話からはちょっと遠いところに落ち着いたな、という現状報告となります。

ほんと人にもよるんだと思うんですけど、クリップとかなしで紙幣をポケットに入れてるとぐしゃぐしゃになってしまって紙幣が痛むし、小銭はポケットにそのまま入れてると実質使えなくなるし、カード類は上で書いた理由により何らかのカバーを必要とする気がします。なので自分の場合、こういうモノを管理するための何かはけっきょく必要だと思いました。

もっとも、それが「財布」という単独のものである必要はない、ということがわかったのはひとつの成果かなあと思います。うまくメンテすることで嵩を相当減らすことができますし、たいていの財布は構造上なかなか薄くはできないので、機能を分散させるというのは悪くないんじゃないかと思います。いっとき流行った薄い財布のようなものもあるのですが、あれも薄くて取り回しが便利な一方で、カードの枚数や小銭の容量には相当の思い切りがあり、使い始める前に自分の財布の中身を見返して、リストラ(再構築)をしないといけないものだ、と認識しています。つまり、「自分の生活スタイルを見返して必要なものだけポケットに入れる」という方向性じたいは、実はけっこう近いと思うのですね。

2012-11-02

レコーディングソーシャルダイエット / 30day challenge

アメリカでも11月になったということで、今月の30日チャレンジとして「レコーディングソーシャルダイエット」というのを考えてみたいと思います。この単語、どういう語順でも語弊があると思いますが、ようは「レコーディングダイエット」の手法をソーシャルメディア中毒に適用してみたい、ということです。

きっかけはHajime Morrita氏の投稿から「ネット依存」についての文章を読んだことでした。「ネット依存について思うこと」およびその反論記事への再反論記事である「ネット依存・続き」です。

ぼくも、「ネットの利用」はもう少し控えたいな、と思っている口です。ただ、ちょっと違うなという気がするのは、ネットの利用というよりはソーシャルメディアの利用というのが近い気がします。FacebookやGoogle+やtwitterや、ほかのなんでもいいんですが、何らかのソーシャルなメディアで無為に時間を潰してしまうことが多いなと思うわけです。
そういう意味では、↑の著者であるyucoさんの方法論は私にとってはやりすぎな面があって、スマートフォン自体は悪くない。たとえば、地図アプリは普通に便利だし日常生活を根本的に変えてしまうと思っています。ぼくにとって問題なのは、ソーシャルメディアの利用です。ぶっちゃけ、あいた時間でちょくちょくGoogle+とか見るみたいな。

だらだらとWikipediaを読んでしまうという問題もありますが、これはまた別な話かもしれません。それについては稿を改めたい。

こういうのは楽しいんですが過度に時間を使ってしまうのはいかんなと思うのです。実際、そういう観点からこういうののアクセスを完全に断っちゃう人もいますし、完全にこういうものを絶ったら生産性が向上した的なライフハック記事もよく見かけます。その通りだと思います。
でも、まあ、完全に絶ってしまうというのは私にとっては極端すぎる方法論だなと思うのです。そんな私にとっては、「依存」ではなく「誘惑」じゃないの、とする新井さんの指摘はいい点をついていると思いました。

つまり、もしこれが依存症だとすれば完全に断ち切ることが唯一の解決策となります。しかし、食べ過ぎと似たような問題なのだとすればダイエットの方法論を適用してみる、という考え方も成り立つ。

そこでレコーディングダイエットを適用してみるということを考えてみたわけです。レコーディングダイエットというのは、基本的には、自分の食ったものを記録していくというものです。本格的には品目を記載したり、カロリー計算したりするのですが、カジュアルには食べたものをひたすらメモしていくだけでもそれなりに効果があると言われています(たとえば大ヒットした岡田斗司夫の『いつまでもデブと思うなよ 』など)。
なぜ記録するだけでダイエットの効果があるのか、というのは明確にこうだという断言があるわけではないのですが、おおむねこのような理屈であると考えられている気がします。つまり、いまダイエットをしたい人というのがいて、その人の食生活に何らかの問題があり、したがってダイエットをしたいのだとします。メモしていくことで、自分がどれだけ食べたのかを把握することができ、ボトルネックを知ることができるというわけです。
また同時に、もし食生活の問題が間食や甘いドリンクなどであったとすると、いちいちメモを取るということが間食の頻度を下げることにつながります。書くだけで「わざわざ書くという手間をかけるほどのことか?」という疑問をもたげさせることにつながります。実際にはそのあと間食を食ってしまうとしても、なんとなく食べてしまう、といった状態と比較すると頻度は落ち、結果として間食の量が減るといったお手軽な効果があるのではないかと思います。

ソーシャルダイエットの場合、この後者がポイントなんじゃないかと思うのです。
いま、ソーシャルメディアへのアクセス量を減らしたいとしたとき、何が問題なのかというと、気軽にちょくちょくアクセスして時間を潰せてしまうというところなのではないか、という仮定を置きました。仮定っていうか、まあ自分の利用形態を念頭に置いています。こういったページを開きっぱなしにしておいて、何かちょっと時間があくと見る、みたいな感じです。これをやめる、ないしは頻度を減らすようにするためには、まさに同じような方法論が使えるんじゃないだろうか。

というわけで、何時何分から何時何分まで、こういうサイトを実際にブラウズしたか、というのを記録に取ることにしました。記録に取る場合、Chrome拡張などを使ってアクセス時間を自動的かつ厳密に測定する、ということもできるのですが、今回はそれをしないことにします。アクセスにフリクションをつけることが目的なので、手動の部分を残す、というのが大事です。
また、スマホについては、写真のアップロード等ができたほうが個人的にうれしいのでアプリ自体は残しておきますが、アクセス手段を悪くしておきます。たとえばホーム画面から除くなど。twitterのアプリは昔、似たようなこと考えたときにアンインストールしたのでいまは入ってません。

ぶっちゃけ、手動で記録するのは相当めんどいと思うので、すぐ飽きてやめちゃうかもしれません。30日も続いたらお疲れさま、とねぎらってやってください。続かなかったらギブアップ宣言をしますが、優しくしてあげてください……。

2012-10-31

Courseraの講義を翻訳してみた

ぐぐぷらを眺めていたら、行動的な知り合いがCouseraの講義に字幕をつけるのを手伝いたい、と申し出ていたのに気づいた。その後の進展を見ていると、実はCouseraの字幕翻訳という話はとっくにあって、amaraというサービスでボランティアベースで進めているらしい。

へえ、そりゃ面白い、ちょっくらやってみよう、などという軽い好奇心から、やってみたのでした。それがこちら。データ構造の講義の、赤黒木についての話です。以下はその体験談なのですが……

予防線を張っておきますが、この手の記事にありがちな「みんなもやってみよう!」という感じの気分にはなりませんでした。ぼくと同じく「へえ面白い、ちょっくらやってみようかな」と感じた人は、記事を最後まで読んでください。

さて。

どんな感じの作業になるかというと、少なくともCourseraの講義については、すでに英語字幕がついています。なので、その字幕をもとに淡々と日本語に訳していくということになります。ツールが使い辛いということはなく、あんまり問題はない気がします。ぼくはそのままブラウザで作業しました。

ですが、根本的に翻訳というのはしんどいわけです。どんな本でも一緒で、読むのはすぐでも翻訳となれば数倍とか数十倍という時間がかかります。読む場合にはなんとなく雰囲気で流しちゃうような細部の単語についても、きちんとどういう意味があり、文全体の構造を把握し、正しく日本語にしなければなりません。

もちろん、専門用語がバリバリなので、術語は定訳を使わなければいけないし、本当は同じ単語は同じように訳すといった労力を払う必要があります。あと、コンピュータ関係に特有の問題としては、カタカナ語が多いので、字幕の枠にあわせるのが大変な気がします。

しかも、講義というのは話し言葉なので、言いよどんだり、文法的に変な言葉になっちゃったりということもあります。なおかつ、映画の字幕とかと一緒で、あまり長文にならないよう、元の発言と時間的にもかけ離れたことにならないよう、気をつけて訳さないといけません。

さらに講義資料がある上でのことなので、「ここでこのノードが……」みたいな文章になっていると、英文字幕の字面だけから単に訳すというのは実際ムリで、講義を聞いてみて、こういうスライドでこういう言葉ならこういう訳になるか、などと確認しながら進めていくことになります。

さらにさらに追い打ちをかけるような問題としては、英語字幕の品質にも疑問があります。たぶん音声認識をベースにしていると思われ、不思議な字幕になっていることがあります。英文字幕だけから翻訳するとえらいことになりそうです。

結論を一言でいうと、「こりゃー大変だな」って感じです。たかが20分の講義ですけど、訳すのは何時間もかかりました。映画字幕の翻訳とかの大変さも垣間見ました。

というわけで、素人にはおすすめできない

翻訳することで講義内容と英語を同時に勉強、といったお気楽なつもりで始めたらいっかな終わらない気がします。自分でよく理解している内容について書いてこんなレベルですからね。自分の知らない内容については、翻訳しないほうがよいのではないかと思います。

期待されるのは、高い専門知識を持った人間が長時間をかけて頑張れる仕組みである気がしており、こういうものこそ大学とか公的機関で、地道にやっていくのが望まれるのかなあ、などとぼんやり考えました。ボランティアベースではしんどい気がするなあ。正直、私は「もうしばらくはいいや」っていう気分です。

あ、ところで上の私がやった訳ですが、もちろんたくさん間違いが含まれていると思います。見て気づいた点があったら、どんどん直していってください。そういう細かい修正は、ボランティアベースが効く気もします。

---

ともあれ、Couseraの翻訳というのは、未来を感じるのは確かです。こうして優れた講義がオンラインで誰でも受講できるとなると、すごいことになるんじゃないかと、期待だけは胸を膨らませておきたい。

2012-10-22

高野豆腐を自作した

そうだ、豆腐を冷凍しよう


どうもご無沙汰しております。最近、たまに自分で料理をしています。たまにというか、まあ土日だけなんですけど。しかもアメリカにいるわけですけど。でも、私のいるあたりには日本食材スーパーが豊富で、ちょっと高いかもしれないけれど、そんなに食材で不自由したりはしません。まあそんなに純和風なものばっかり食べないですし。

そういうわけで、豆腐を買ったわけです。豆腐を1丁。で、味噌汁に入れたりとかしてたわけですが、なにぶん土日だけしか料理しないと、ひとりで1丁など使い切れません。余る。どうしよう。もちろん、平日に適当な大きさに切って醤油でも垂らして冷奴にしてもよいのですけど、ふと「これは凍らせると高野豆腐になるのではないか?」という妄想が脳裏をかすめました。

で、せっかくだからやってみた。

手順

1. まず、豆腐の上に適当な重し(皿とか)を載せて均等に圧力をかけ、脱水させます。んで、「高野豆腐ってそういえば薄かったよな……」と思い、適当な厚さに切り、冷凍庫にイン。

2. 翌日、冷凍庫を確認するとかちこちに凍ってました。これをいったん解凍させます。めんどかったので自然解凍させました。朝会社に行くまえに皿とかに放置すると、夜帰ってきたら解凍しているという。この時点でそうとう高野豆腐なアイデンティティを確立しています。なぜかちょっと黄色くなるし。なんでだろう。

3. 解凍したらギュッと絞って水分を出し、また冷凍庫で凍らせて、を繰り返しました。3〜4回ぐらい。

4. 何回か繰り返すけど、ある程度以上は水分が抜けたりはしなくなってしまった。天日干しにもしていなかったし……。ともあれ、この時点での見た目はかなり高野豆腐。たぶん完成、と思うことにする。

5. 冷凍庫で保管していたので氷結しているため、調理前にいったん熱湯で戻す。

6. 戻したら市販の高野豆腐と似たような感じになったので、ふつうに出汁醤油で含め煮に。

感想

テキトーに作った醤油味の雑炊と
普通にスーパーで売っている高野豆腐は、スポンジの「目」というか、穴の部分がきめ細やかだけど、これはふつうの木綿豆腐を適当に脱水して凍らせるだけなので、氷のぶぶんの大きさ(つまり脱水後の穴の大きさ)はまちまちであり、わりと大きな穴や亀裂ぽいものもけっこうできてしまう。

だが、そういう見た目にこだわらなければ予想以上にふつうに高野豆腐っぽい物体が出来上がった。味もふつう。穴も大きいので中まで味がしみる。本体も、むしろ豆っぽい味が強く出ている気がする。気のせいとか、自分作なので脳内補正が入ってるだけかもしれないが……。

作るのも、凍った状態から戻すのも時間がかかるのでおすすめではないのですが、まあ実験としてはなかなか楽しいかも。

そういえばアンデスの伝統食材として、じゃがいもを同じような工程で脱水してスポンジ状にするチューニョという食い物があるんだそうです。じゃがいもといえば、「冷凍にするとスポンジみたいになって不味くなる」(だから肉じゃがとかカレーとかは決して冷凍にしてはいけない)と基本事項のように言われる気がするのですが、敢えてそれをやってしまうという挑戦的なモノです。
面白そうなので、いずれやってみたい気もします。面倒そうだけど。

2012-09-28

Ernst Cline "Ready Player One"

嫌いになれない。

ギーク小説、というジャンルがあると思う。ギークな作家が、自らの体験を交えて書くようなタイプの作品だ。具体的な作品名やキャラクター名や設定が飛び交い、そこにどっぷりと「浸かっている」ような読者を喜ばせて、身悶えさせる。そういう意匠に凝りに凝った作品、っていうのが確かにある。
たとえば、秋口ぎぐるの『ひと夏の経験値』は、90年代にテーブルトークRPGをやっていた中高生というごく狭い人々にとってはただ事ではない迫真さがある。そういう狭い層にはいかんともしがたいというものがある、というタイプの小説というのは、たしかにある。

本書 "Ready Player One" も、そういう「ギーク小説」のひとつで、80年代アメリカのデジタルゲーム・アニメ・ゲーム・まんが・ポップカルチャーに強く依拠している。僕よりも少し年上の世代がストライクなのかな。いずれにせよアメリカの本なので、日本人にはそこまで強くは訴求しないかもしれないけれども、そういう道具立てがすごい。

21世紀のなかごろ、稀代のゲームデザイナーとうたわれたジェームズ・ハリデイがとある遺言のビデオレターを残す。ハリデイはもともと重度のおたくで、優れたゲームセンスを持ち、友達とゲーム会社を立ち上げて大成功する。だが21世紀初頭になって、MMORPGとSNSをくっつけたようなOASISというシステムを構築し、これまた大成功。この作品の時代には、このOASISというのがインターネットと同義になっていて社会インフラと化しており、なおかつそれが娯楽でもある、みたいな状態になっている。

ハリデイは自らの莫大な富を、このOASISのどこかに隠したのだという。それがビデオレターの遺言の内容だった。天涯孤独だった彼には肉親はおらず、富は宙に浮いている。ハリデイが隠した秘密を解き明かし、ゴールまでたどり着いたものがこの富を得ることができる。ヒントはないが、ハリデイの愛した80年代ゲーム・ポップカルチャーが強いモチーフになっていることが暗示されている。

これが発表されてからさあ大変、誰も彼も、猫も杓子も大企業も、この「イースターエッグ」を探し求める旅に出た。だがなかなか見つからない。手がかり一つとっても誰もわからない。人々はハリデイの嗜好から問題傾向を推測しようと、80年代ポップカルチャーの研究を深め、そういったファッションが大流行していく。だが、それでも見つからないまま5年が経過。人々の興味も薄れかけてきたそのころに、ついに変化がおとずれる。無名のハンターの名前が、突然スコアボードに躍り出たのだ。それが主人公である「ぼく」のことなのだが……。

どう思いますか、この筋立て。

似たようなことを思う人もそれなりにいると思うので、はっきり言わせてもらうと、こういうセカンドライフみたいなSNSが世界を席巻するみたいな世界観には、ぶっちゃけて言えばうんざりする。しかもこの本は刊行が2012年。2012年に出た本とは思えないほど、この小説内のサイバーカルチャーは時代錯誤感にあふれている。3DCGのSNSもそうだし、リアルライフとヴァーチャルライフの単純な二分もそうだ。いくらなんでもこれはないんではないか……などと思うのはもしかすると僕がMMORPGなどの文化に親しみがないからであって、スカイリムとかをやっている人にはこういうのもリアリティがあるのかもしれない。が、ともあれぼく個人の感想を正直に言うと、特に序盤は投げそうになるほど、この辺の感覚の齟齬が大きく、読んでいてキツいものがあった。

そもそもなぜ、SF作家は3DCGバーチャルリアリティがそんなに好きなんだろ? むしろ今となってしまうと、こういう世界にはリアリティを感じなくなってしまった。個人的には、3DCGのバーチャルリアリティ空間が採用されるのは、小説が書きやすいからだろうと理解している。チャットや掲示板だけで描写すると、あまりにも前衛的な文学になってしまう。大衆娯楽文化としては、会話の途中の細かい描写を描かないと読みづらくなってしまうし、そうするには手っ取り早いのは3Dにしてしまうことだ。そうすれば、目線を逸らしたり、身じろぎをしたり、そういった何気ない、言外のジェスチャーを描写できる。この本がそうなのも、案外とそういった理由だったりするのかも。

ともあれそういうわけで、ベースラインとなる設定は個人的にはかなりキツい。だが、娯楽小説としては普通によく書けており、読みやすいし、さらさらと読むぶんには特に問題を感じない。そんでもってむしろ、本書の核心はむしろポップカルチャーやゲーム・おたく文化の部分にある気がするので、ここにあまりこだわっても仕方ないのかもしれない。SFファンというのは基本的に設定にうるさいので、気にしてしまうわけだが……。

だが、そういう「きつさ」を乗り越えて読み進めると、やっぱりどうしても、嫌いになれない自分に気づく。なかに登場するゲームなどのネタの大半は、厳密にはよくわからんのだけれども、肌感覚でちょっとわかる。そしてその「わかっている感じ」というのはたまらない楽しさではあり、それこそが「ギーク小説」の(ギークにとっての)楽しみではあるわけだ。たまに登場する日本文化のネタはときどき微妙に間違っており(ウルトラマンの身長が156フィートだとか……アメリカではそういう設定なのだろうか?)、そういう感じでニヤニヤしたりする楽しみもある。それにまた、クライマックスの戦いで主人公がレオパルドン(東映スパイダーマンのやつ)に乗り込んで、「チェンジ・マーベラー!」とかやってから出撃してメカゴジラと戦う、みたいなところではやっぱり日本人のおたくとしては気分はそれなりに盛り上がり、「やっぱ嫌いにはなれないよなあ」としみじみしてしまうのだ。

つまるところ、この本は「ギーク小説」としてよく書けている。ギーク小説は、もちろん普通の小説として読んで楽しむこともできるけれども、中に散りばめられたギークネタを拾って楽しむというのがやっぱり楽しい、というタイプの小説だ。ぼくもそういう小説は好きなのだ。だから、どうにもこういう話は否定しにくいものがある。

まあ、苦労して読むほどの価値はないけれども、まんがいち訳されることがあったら読んでみたらいいんじゃないかと思います。

2012-08-29

chromiumの継続的インテグレーション

最近はどうもJenkinsとかTravisCIとかいうのが話題みたいなのだが、使ったことがないのでよくわからない。だがどうも漏れ聞く話を見ていると、こういうのは継続的インテグレーション(CI)と呼ばれていて、だいたい自分の社内プロジェクトでも似たようなことをやっているらしい。そこで、Chromiumがどういう環境でCIしているか、ということを簡単にまとめてみたい。あらかじめ書いておくと、名前が違うだけでだいたい普通です。

BuildBot
Chromiumは普通のクライアントプログラムなので、ビルド環境の想定がけっこう複雑だ。Windows/Mac/Linux/ChromeOS(最近はAndroidなどのモバイル環境)のようにプラットフォームは多岐にわたるし、同じプラットフォームでも様々なビルドコンフィグレーションがある。テストも数が多く、ローカルに走らせておくのは時間がかかる。

BuildBotは様々なビルド環境で実際にビルドし、テストを実行するフレームワークだ。複数のマシンインスタンスがそれぞれ微妙に違ったコンフィグレーションでビルドを行い、テストを実行してくれる。どこかに問題があれば即座に問題を報告し、ツリーを閉じる。

ツリーが閉じられると基本的にはだれもコミットができなくなる。問題のレポートは、問題となりそうな……つまりそれまでビルドが通っていたのに新しくビルドが壊れる状態になるあいだにコミットされたパッチの作者(たち)に送られる。問題を引き起こした開発者は、単純ミスですぐ直せそうなら自分で直すが、たいていの場合はrevertする。

鵜飼さんの講演にもあったように、Chromiumでは平日では平均で7分半にひとつといった頻度でパッチがコミットされている。このため、一つ一つのパッチをすべて段階的には確認するほどのリソースはかけず、複数のリビジョンをある程度はまとめてBuildBotで確認している。頻度が高いというのは、ツリーが閉じられたらものの数分で誰かが気づくということだ。ツリーを壊すと「お前の変更で壊れてるっぽいんだけど」と文句を言われ、せっつかれることになる。そんなときは冷や汗を書きながら、ごめんごめん、いまrevert中なんだ、などと答えたりする……。

sheriff
たいていの場合、ツリーの閉じられ方からはだれのどのパッチが問題なのかはすぐわかる。開発者は、壊れた状況から自分ぽいな、ということはすぐわかるし、壊したらすぐ自分で対処する。……とはいえ、完全に開発者の自治のみというわけでもなく、BuildBotとツリーの状態を守る専任もおり、sheriffという。

sheriffは専任といっても、実際にはローテーション制が採用されていて、担当になると数日間、ツリーの監視を行う。デベロッパは世界中にいるので、ローテーションも在籍地の時差を考慮して複数人が割り当てられており、さすがに夜寝てるあいだとかにはほかのsheriffが仕事をしてくれる。

sheriffの仕事は実際問題としてはそんなに忙しくはない。ふだんはのんびりと、メインの仕事をしていたりする。だが、ひとたびツリーが閉じたら問題を調べ、だれのどのパッチが問題を引き起こしたのか同定する。そしてその開発者とコンタクトを取って、修正が容易なら修正するし、ダメならrevertする。

炭鉱の庭師という記事を読んで、gardenerはsheriffより大変だなと思った。ツリーのcloseは自動的なためsheriffの仕事はリアクティブだし、上にも書いたように、多くの場合には何がツリーを閉じたのかは自明なので、負荷は大きくない。ごくまれにコンパイラのバグが顕在化して大混乱に陥ることもあるけれど……。sheriffはどちらかといえば、「ツリーが閉じててコミットできん!」と怒れるほかの開発者の代理に文句をいう仕事であり、仮に当該の開発者はもう家に帰ってしまったとかいった理由で反応がない、などの理由で連絡が取れない場合に責任をもってrevertする仕事だ。

trybots
BuildBotとは別にtrybotというのもある。trybotは、自分のパッチをコミットに確認するための仕組みだ。trybotも同じように、様々なビルド環境とコンフィグレーションを持っていて、それぞれ名前がついている。winとかmacとかlinuxとかlinux_chromeosとか。そしてそれぞれ適当なリビジョンのソースツリーを手元に持っている。開発者がコマンドを発行すると、パッチを適用し、実際にビルドしてテストを走らせ、結果を教えてくれる。

コミット前に適宜trybotを走らせておけば、パッチの健全さはわかる。Chromiumの使っているRietveldには改造が施されていて、trybotを走らせた場合にはその実行結果が表示され、わかるようになっている。

trybotはBuildBotほどバリエーション豊かじゃないし、ごくまれにtrybotをすり抜ける問題もある。だが99%の問題はtrybotでふるい落とすことができると思う。パーセンテージの数字は適当 :-P

commit queue
trybotは確認のためのインフラであって、それ自体は自動化はされていない。trybotの手間を惜しんでしまうひとがいることもありうるし、まれに必要なtrybotを走らせておらず、うっかりビルドが壊れるということがある。たとえば、ChromeOSでしか使わないと思っていたら、とある特殊なコンフィギュレーションのMacでも使われることがあることを見落としていたとか、標準的なC++を自分では書いているつもりがVCでだけコンパイルエラーになるとか。私もいちど、ごく普通にあるクラスにkInvalidIDというクラス変数を足したところ、実はCarbon内でkInvalidIDは#defineされているためMacでだけコンパイルエラーになる、などという自体に遭遇してひっくり返りそうになったことがある。そんなの知らんがな……。

閑話休題。

そんなわけで、commit queue (CQ)がある。開発者がパッチにフラグをつけるとCQはそのパッチをひと通りのtrybotにかける。それで全部でうまく行ったものだけがコミットされる。これによってくだらない問題を回避できる。上で書いたMacの問題も、まさにCQによって発見された問題であって、これがなければうっかりビルドを壊してしまっただろう。タイミングによっては直せず、revertされてしまったかもしれない。

もっともCQにも弱点はある。というのは、一般的なtrybotでの確認しかしないから、特殊なビルド環境で開発している場合は自己責任でtrybotを走らせるしかない。それに、特定のプラットフォーム以外ではビルドすらされないような変更では、CQを走らせるのはたんに時間と計算リソースの無駄でしかない。

コードレビューとコーディングスタイル
コードレビューいろいろでも紹介されているように、Chromiumのコードレビューはコミット前に行う。デベロッパは自分でレビュワーを見つけ出し、指定する。レビューは(trybot等の表示の改造が施された)Rietveldを使っている。

レビューは基本的にだれがやっても良いし、だれに依頼しても構わない。ただし、ディレクトリごとにオーナーがおり、そのパッチで関連するファイルのすべてのディレクトリのオーナーからの許可なしにはコミットはできない。とはいえ、オーナーの数は限られていることも多いから(たとえばui直下のオーナーは3人しかいない)、そうした場合には、そのファイルやパッチの内容に詳しいレビュワーにまずレビューをお願いし、そちらのレビューがひと通り完了した段階でオーナーにレビューをお願いし最終確認をもらう、というパターンも多い。

たまに、ふだんあまりいじらないあたりのファイルをいじっていると、だれにレビューをお願いしたらいいのかわからないこともある。そのときは適当にログを調べて、最近そのファイルをいじってたりそのファイルの変更をレビューしている人をピックアップしたりする。比較的最近、Chromiumで使っているgit-clでは、チェンジの内容からレビュアーをサジェストする機能が導入された。experimentalだが、わりとよいサジェスチョンをしてくれることも多い気がする。

ところで、Chromiumではコーディングスタイルを定めていろいろ細々と決めている。ベースはGoogleのコーディングスタイルなどだが、さらに細々としたことも決めている。このあたり、人によっては意見もあるだろうけれど、コーディングスタイルを決めることには、このタイプのレビューと親和性があると思っている。

レビューでは、いろんな人が勝手にいろんなことを言う。細かく、どちらでもいいことであっても、いったんこうと決めておくことでレビューが進められる。たとえば、Foo* barであってFoo *barでない、などのスタイルは、本来はどっちでもいいが、いずれにせよどちらかに統一すべきものだ。だからすぱっと決めてしまえばいい。そうすることで、機械的に問題をチェックすることすら可能かもしれない。瑣末なことを決めてしまえば、本質的なポイントにフォーカスしたレビューができる……まぁ理想的には……と思っている。

goma / ninja
コードレビューの話はいささか本題から外れてた気がするので話を戻す。

ChromiumはほぼC++なので、ビルドの高速化は至上命題だ。gomaはChromiumで使われるクラウドコンパイラで、ローカルのファイルをデータセンターのインスタンスに送り、コンパイル結果を返す。コンパイル結果はキャッシュされている。大半の場合はファイルの変更はないから、gomaのキャッシュにヒットするとコンパイル時間は凄まじく高速化される。gomaはもちろん開発者の生活も幸せにしたが、実際にはBuildBotやtrybotでも使われており、これらのチェックの高速化に寄与している。

ninjaは平たく言えばmakeの代替物。いわゆるビルドシステムだ。ChromiumではビルドにはGYPというソフトウェアを使っている。GYPは.gypファイルを読み込むと各種のビルドシステム用のファイルを生成する。WindowsならVCのプロジェクト、MacならXcodeプロジェクト、LinuxならMakefileといった具合。GYPはninjaサポートを済ませており、簡単な設定でこれらのファイルの代わりに(あるいは加えて)ninjaファイルを生成する。

ninjaはプロジェクトの目的に高速であることを第一に掲げていて、実際makeより格段に高速である。なぜそんなに速いのか、実際のところはよく知らないのだけど……。

まとめ
Chromiumでの開発環境をひと通り解説した。

正直なことを言うと、少しも特別なことはしていないと思う。当たり前のことを当たり前にやっているだけだ。だから、こういう文章がどれぐらい参考になるのかはよくわからない。

また改めて書くまでもなく、こうした手法やツールは相互に依存し合っている。trybotみたいな仕組みが必要なのはプラットフォームが多岐に渡っているからだし、またコミット前レビューの仕組みとも関わっている。Rietveldはコミット前レビューが前提なため、他のレビュープロセスなプロダクトで導入すると面倒なことになるかもしれない。gomaが大きな意味を持つのは、開発言語が主にC++であることも大きい。

開発プロセスに正解はない、と思う。あるプロジェクトでうまく行っている、というのを聞きつけて、その一部だけ取り出してもうまくはいかないかもしれない。どちらでもいいが一方を選択している、ということもある。ChromiumでRietveldが使われているのはたぶんGuidoが作ったシステムだからという理由でしかなく、WebKitにRietveldを導入したい、という意見はあまり興味を持たれないらしい。WebKitはbugzilla上でコードレビューも行うため、issueと正確に一対一対応されるが、Rietveldはバグトラッカーではないため、issue管理は別にやる必要がある。Chromiumではissueの管理はcode.google.comで行い、Rietveld上でissueと関連付けられるようになっている。レビューツールとissueツールが別、というのはぼくにとっては自然だけど、そこはまぁ好き好きかもしれないし、ぼくがなにかに洗脳されているだけかもしれない。

ちょっと話がそれたが、それでもまぁ、こういう文章もある種のケーススタディとして何かの参考になるとうれしいかな、と思う。

images:



2012-07-17

ChromeOS SKKの開発: 開発環境編


このシリーズは今回で最終回の予定です。

ChromeOS向けの「IME API」を使ってSKKを作りました、という話のシリーズなのですが、こういうものを作るときに何が一番厄介かといって、やっぱりデバッグだろうと思うわけです。
IMEはデバッグをするのが非常に厄介なたぐいのソフトウェアです。うっかり変なことをすると完全に壊れて何もできなくなることすらあります。ChromeOSのIME APIでは、IMEは単なるChrome extensionなために完全にsandbox化された環境で動作しますし、developer toolsもあるのでデバッグは相当楽なほうですが、それでもなかなか面倒な面もあります。
面倒さの一つには、実機での動作確認が面倒だということが挙げられると思います。ChromeOSでは、まだセルフホスティングの開発環境が整っていません。普通にたとえばWindowsやMacでChrome extensionを開発するなら、適当にJSファイルを書いてunpacked extensionとしてロードして手元で動かして見ることができます。ですが、ChromeOSではローカルファイルを編集するためのテキストエディタがありませんし(と思ったら、そういう拡張機能もあるようですが)、なんだかんだでまだまだ大変な面が強いわけです。
そういうわけで、今回はMacで開発をしたのですが、じゃあどうすればいいのでしょうか。Macのほうで拡張機能のパッケージ化を行い、適当なサーバにアップロードして、ChromeOSのほうでダウンロードして……などとやれば出来ますが、毎度それをやるのはあまり実際的でもありません。

といった状況を踏まえ、まず開発をするための実行環境を作ってみました。それがソースコード中のtestpageというディレクトリです。
こいつのやることは簡単です。まずmock.jsというJSを読み込みます。こいつはchrome.input.imeというオブジェクトをグローバルに追加して、setCompositionとかclearCompositionとかのメソッドを登録します。この関数の実行結果は、適当にHTMLで画面に表示させます。一方でキー入力も適当なeditableな要素のほうで受け付けておき、onkeydown/onkeyupを使って適当なイベントリスナにキーイベントを横流しできるようにしておきます。
そうしておいて、のこりの拡張機能で使うJSファイルをロードすると、ある程度は動作するようになるという仕組みです。実際に、前回の記事で書いたAppEngineのホストにくっつけて公開もしています→こちら

前々回の記事で、AJAX-IMEのようにページ内に寄生するIMEっぽいJSの話に軽く触れました。今回はこれと似たアプローチで、ただし、変換エンジンの処理を直接書き下すのではなく、IME API互換のレイヤを間に挟んでいる、という解釈ができるかと思います。
この手法はなかなかうまく行きました。ちょっとコードを書いたら、すぐ実際にキー入力してみてどう表示されるのか確認できる環境がある、というのはいいものです。すぐ確認できることによる全体的な開発の高速化もありますし、実際に動いているのを目にすることができるというのは、とくに開発初期においてモチベーションを高めるという意味もあると思います。わりとすぐにそこそこのものが開発できたのも、この方式のおかげというのがあるかなあと個人的には考えています。

まあ、実際には、APIのドキュメントをちゃんと読まずに実装したので、いざ実機にロードしてみたらちゃんと動かなかった、みたいなよくある失敗もあるし、JSやイベント処理まわりの無理解のために動かなかった、みたいなしょぼい問題もたくさん踏んでいるので、あんまり自慢するようなポイントではないような気もします。また、現状ではonKeyEventの返り値を見ていないので、一部の機能は全然動いていないように見えます。それに、動かして確認するといった単純な手法よりは、細かいコーナーケースではユニットテストをちゃんと書くほうが大事だったりします……このコードではテストを書いてませんが、IMEはコーナーケースばっかりなので本当はテストが大事です。
なのですが、個人的には、テスト環境を実装してみたら割と簡単に実装できて、これが思いの外便利だった、というハックがちょっと面白かったので、紹介してみた次第です。


photo: http://www.flickr.com/photos/mjmyap/147909798/in/photostream/ by mjmyap

2012-07-11

SKK for ChromeOSの開発:辞書データの話


前回書いたように、ChromeOSで動作するSKKを開発しました。当初の予定を変更して、今回は辞書の話を書くことにします。

実は私は昔、AJAX-SKKというものを書いてみたことがあります。とはいえ、JavaScriptの練習用コードだったということもあっていろいろ不備があるわけですが、何といっても変換には、適当なcgiをでっち上げて変換サーバにしていました。今回は、そういうことはやめようと決意し、全部JavaScriptで動くことを目指しました。

SKKの辞書には、バリエーションがいくらかありますが、最大のL辞書は相当大きく、これをそのまま扱うのは簡単ではないように思えました。そこで当初の構想としては、処理にwebworkerを使うだとか、保存にはIndexedDBを使うだとか、そういう現代的なテクノロジーを活用することを目論んでいました。
目論んでいたんですが、結果的にはこういうのを使うのはやめてしまいました。実際に、そういうコードを書き初めていたのですが、完成前にふと思いついてものすごく単純な手法を試してみたところ、あっさり動作してしまったしパフォーマンス上もたいして問題ではないように見えたので、それで行くことにしました。
その手法というのは、SKKの辞書データを単純にJavaScriptオブジェクトに変換してしまい、全部オンメモリに持つ、というものです。また、JavaScriptオブジェクトはJSON.stringifyでJSONフォーマットにシリアライズし、FileSystem APIを使ってローカルなファイルに保存します。次回以降は、ローカルなファイルを読んでJSON.parseするだけで辞書データが復元できます。
SKK-JISYO.Lをダウンロードしてパーズと保存を全部組み合わせた場合、手元の最新のChromebook (Series-5)で試すと、数秒で処理が完了してしまいます(しかもほとんどの遅延は辞書のダウンロード時間な気がします)。JSON.parseでローカルから復旧する場合は1秒強、といったところでした。辞書データは、バックグラウンドページがロードされたとき(つまりログイン時)に一度だけロードすればよいので、この程度の性能なら特に問題ないように思います。ログイン時のもろもろの処理に紛れてしまうんじゃないでしょうか。
むかし、SCIM-SKKを開発したときは、SKK-JISYO.L全体をはじめにパーズすると無視できない遅延が考えられるため、いろいろ効率化を工夫した記憶があるのですが、ああいう細かい工夫はいったいなんだったのかなぁという思いの去来する出来事でした。最近のコンピュータも、最近のJSエンジンも、速いよね……。


さて、それなのにソースコードには「server」の文字が含まれます。これは何をしているのかというと、辞書ファイルのミラーリングと、簡単な前処理です。
SKKは歴史があるので、辞書の配信もいささか時代がかった方式になっています。ファイル名自体が.gzの拡張子を持っていて、Content-Type: x-gzipのレスポンスヘッダがあります。コンテント自体を圧縮して配信するなら、Content-Encodingを使うのがHTTP的には正しかろう、とは思いますがブラウザのバグだとか歴史的な事情を考えると、この方式はむしろ自然だと言えるでしょう。ただ、自然だといっても、このままではJavaScriptで.gzを伸長するはめになります。これは今ひとつ現実的ではない気がします。
それに、SKK辞書はEUC-JPでエンコードされているという問題があります。.gzを伸長しても得られるのはEUC文字列ですから、Unicodeに変換しなければならない。これをJSでやるのはさすがにアホくさい。
そういった事情があり、AppEngine側でSKKの辞書のミラーリングをすると同時に、もうちょっと楽に扱えるように前処理を施します。
AppEngineではscheduled taskで1日に1回、openlabの辞書の配信元に問い合わせます(現在はopenlabが停止しているのでスケジュールも止めています)。で、更新のあった辞書ファイルをダウンロードしてきたらzlibで伸長し、そのデータをblobstoreに保存します。
拡張機能のほうからデータを持ってくるときには、単にサーバに辞書ファイルを問い合わせます。すると、blobstoreに保存してあるデータをContent-Type: text/plain; charset=euc-jpで返します。文字コードの変換はChromeがやってくれるので、JSレベルでは気づかぬうちに扱いやすい普通のテキスト形式でデータが手に入る、というわけです。

ちなみに、辞書ファイルは誰でも取ってこれます。たとえば http://skk-dict-mirror.appspot.com/SKK-JISYO.S.gz にアクセスしてみてください。openlabが停止している今では、偶然ですがキャッシュとして使えるかもしれません。


ところで、この話を会社でしたところ、そんなものはXHRでなんとかなるのではないかという指摘を受けました。あんまり詳しくなかったのですが、XHRでは返ってきたレスポンスのContent-Typeを上書きすることはできます。なのでContent-Typeだけならそれでもいいのですが、今回の場合はContent-Encoding: gzipも足してあげないとChromeはレスポンスボディを解釈できません。XHRではほかのレスポンスヘッダはいじることができないようなので、これだけでは無理なのではないかと思いました。ただ、Chrome拡張機能のwebRequest APIを使えばレスポンスヘッダをいじれるため、組み合わせればAppEngineがなくても良かったかもしれません。気づいてからずっとopenlabが落ちているのでまだ試していないのですが、復旧したら試してみるのもいいかもしれませんね。

image: http://www.flickr.com/photos/62396887@N00/1405476175/

2012-07-08

ChromeOSで動作するSKKを作った

ChromeOSには標準でいろんな言語がサポートされています。言語サポートとひとくちにいってもいろいろあるわけですが、入力方法もそうしたサポートのひとつでしょう。日本語にはMozcが使われており、中国語や韓国語も各種のOSSライブラリが使われています。CJK以外のアジア諸語ではlibm17nが使われています。ラテン文字を使った言語についても、様々なキーボードレイアウトをサポートすることで入力に対処しています。
とはいっても、そういうのは全然完全じゃないわけです。Mozcだけでは日本語はサポートしきれません。中国語でも、主として本土の人向けのピンイン入力や、台湾でよく使われるzhuyin入力や、Canjie(部首変換)はサポートされていますが、boshiamyのようなプロプラエタリなインプットメソッドは導入できません。
そういったわけで、ChromeOS用にインプットメソッド拡張機能APIというものが提案されており、これが現在、バージョン21(devチャンネル)でのみ利用できる状態になっています。このAPIを使えば、たんにJavaScriptで拡張機能を書くだけでインプットメソッドを導入することができます。
というわけで、昔とった杵柄、という塩梅でSKKを書いてみた、というのがこちらになります。ソースコードはgithubに公開しています。そういえばライセンスとかreadmeとか、ちゃんと書かないとな……。
折角なので、苦労話とか実装の話を適当に何回かにわけて書こうかと思います。ところでSKKといえば、openlab.jpがもうかれこれ2週間以上、ストップしているように思われ、何があったのか不安な面が強いのですが、辞書については諸般の事情から、てきとうなappengineインスタンスを作ってそちらでサーブしていますので、この拡張機能の辞書のダウンロードについては心配ありません。

さて、手始めにIME拡張機能とはいったいなんなのか、どう動くのか、という話を書いてみたいと思います。
はじめに、おそらく誤解をしている人も多いと思うので書いておきましょう。IME拡張機能は、よくあるAJAX-IMEのブックマークレットなどのようなものとは根本的に異なります。どちらが良い悪いというのではないです。ブックマークレットだけでブラウザ内で動くというのはとても優れたハックだし、すごい話だなと思うのです。ですがその場合、インプットメソッドはウェブのコンテントエリア内でしか動きません。
ChromeOSの場合はnothing but webですから、ウェブ以外に何があるのだろうと疑問に思うかもしれませんが、実際にはたくさんの入力エリアがあります。たとえばomniboxや検索ボックス。ネットワーク設定用のダイアログ。アプリケーションリストのポップアップ。などなど、実は意外とあるのですね。また、候補ウィンドウの描画などを、ホストするウェブページと独立にうまく描画するのは、そう単純な話でもないのです。
ChromeOSでは、内部的には現在、ibusというIMEフレームワークが使われています。ibusはマルチプロセスなIPCベースのフレームワークで、各IMEの入力エンジンはibus-daemonと別なプロセスで動作します。Chromeでキーイベントが発生すると、まずはibus-daemonを介して入力エンジンへキーイベントが届けられ、処理結果がまたIPCメッセージとしてChromeに戻ってくるという構造になっています。ちなみにChromeOSでは候補ウィンドウはibusではなくChrome自身が描画するという実装になっています。
図にするとこんな感じかな。
表現としてはわかりづらいですが、composition(未確定文字列)とかcandidates(変換候補)はブラウザプロセス内で表示/描画されます。
一方、AJAX-IMEブックマークレットなどの構成では、ウェブページ内にIMEが寄生します。てことで、ざっくり書くとこんな感じ?
表記上、わけられていますが、レンダラプロセス内にあるJSエンジン(v8)のなかにIMEの処理がロードされ、ブラウザプロセスから届けられたキーイベントを横取りして処理するというイメージ。この場合、すべての処理はレンダラプロセス内にあり、compositionやcandidatesの描画もレンダラを使って行ないます。htmlを使って自由に描画できるという面ではいいのかもしれないけど、ホストとなるウェブページの描画事情に応じて様々な厄介な問題が引き起こされがちです。あともちろん、omniboxなどウェブページの外側にあるモノにはアクセスできません。
IME-APIでは拡張機能を使うので、やはりIMEの処理がレンダラプロセスの中にロードされます。と書くと後者と似ているように聞こえるかもしれませんが、やはり異なります。なぜかというと、IMEの処理がロードされるレンダラプロセスは、ユーザがいま見て入力しようとしているウェブページのものとは異なるものだからです。
Chromeの拡張機能には「バックグラウンドページ」というものがいます。これは、その拡張機能が有効になっているあいだは、ずっと起動されているレンダラプロセスで、様々な処理を受け持つことができます(ちなみについ最近、こないだのGoogle I/Oにて、バックグラウンドページも必要なあいだだけ起動してあとは止めておく、という機能が紹介されています)。IME-APIを使った拡張機能でも、このバックグラウンドページにIMEの処理を持たせることが想定されています。この場合、バックグラウンドページのコンテンツというのは存在せず、ユーザが実際に目にすることはありません。どちらかといえば、さまざまな拡張機能APIにアクセスするJSコードのデーモン的な位置付けになっていると言えると思います。
ここに来ると、IME-APIというのは既存のibusに相当するレイヤとみなすことができます。ibusはd-busをベースにしたIPCフレームワークを使っていますが、IME-APIではChromeがブラウザプロセスとレンダラプロセスのあいだで行われるIPCレイヤによってibusと同じようなことを代替するという試みとなります。
このため、compositionやcandidatesの描画は、ibusと同等にブラウザプロセス内で動作します。ブラウザから見た場合、ある変換エンジンが拡張機能を使ってJavaScriptで書かれているのか、それともibusクライアントになっているのか、というのは大きな差がないようになっているわけです。

実装上はどうなっているかというと、バックグラウンドページは、基本的にはいくつかの初期化処理をしたら後はなんにもしない状態にしておきます。初期化のなかには、chrome.input.ime.onKeyEventというイベントハンドラにaddListenerによってハンドラ関数を登録します。そうするとユーザがキーを打鍵すると、そのたびに登録したハンドラ関数が呼ばれます。関数のなかでは、setCompositionやcommitText、candidatesの設定などの関数を呼ぶことができ、IMEの状態を任意に変えることができます。起動時のonActivateや、フォーカスの入出にかかわるonFocus/onBlurも使えば便利であろうと思われます。
そんな感じで、あとはキーイベントハンドラを上手く処理するJSコードを書きさえすれば完成という次第です。
次では、開発プロセスに関係することを書こうかと思っています。

2012-06-06

共産主義スーパーヒーロー! 『キャプテン・チャイナ』

今朝方、Google+でテクニカルライターのMike Elgan紹介していたコミックが凄そうだったのでうっかりKindleで買ってしまった。その名も『キャプテン・チャイナ』!!

……
amazon.comでKindle版が$2ぐらい。もっとも、この第1巻はエピソード1つ分で、20ページぐらいです。英語版と中国語版がバンドルされてて全体で40ページぐらい。

せっかくなので軽く中身を紹介しておきます。
……かつて、1950年代末、毛沢東は大躍進政策中にスーパーソルジャー計画を立案。数千人を越える兵士たちの候補から最終的に五人のエリートが選抜され、そのうちのとくに優秀な一人が中国の最初のスーパーヒーローに選ばれます。人民解放軍に由来するリベレーター(解放者)というコードネームを与えられ、当時の中国で大々的に宣伝が行われました(あ、解放者、というのは中国語版の名前)。ですが、当時の技術的な限界から、超人改造には無理があり、選抜者は全て死亡。大躍進政策自体も失敗に終わったことにより、この超人兵士計画は頓挫してしまいました。
それから50年。実は五人の候補のうちのひとり、リベレーターは死んでおらず、50年間冷凍冬眠していました。それを現代の技術によって蘇らせたのがキャプテン・チャイナ(中国隊長)、というわけです(なんでコードネームが変わったのかはよくわからないw)

さて、国際的な記者発表会でキャプテン・チャイナのお披露目をしたのですが、記者の財布を盗む、というお誂え向きのアクシデントが! 即座にキャプテン・チャイナは専用の武器、レボリューション・キャノン(革命砲)取り出し、泥棒を撃ち殺しちゃいました。
「犯罪はこの偉大な国では許されない!」
おかげでボスはカンカンです。泥棒の一幕はもちろんヤラセだったのでした。「パンチでも浴びせとけばいいんだ!」「ヤラセだと知らされていなかったので……」どうも部下(↑の後ろで立ってる金髪)が「その方が臨場感が出るから」と気を利かせて教えなかったのでした。「まあ、本物の犯罪者を使ったのは不幸中の幸いだったが……」そんなことでいいのか。おかげで革命砲には普段は弾を込めないこと、という縛りがつけられました。

さてそんな折、どこかで見たことのある黒人のアメリカ大統領が訪中することになりまして、キャプテン・チャイナ一行になぜか「アメリカ大統領が襲われる、守れるのはキャプテン・チャイナだけだ」という謎のタレコミがありました。どう考えてもその情報は怪しいし警備はしっかりしているから、というボスの至極もっともな意見に耳を傾けず、制止するボスの目をかいくぐってその場に行ってみると、飛行機を降りた大統領と中国の主席が握手をして挨拶をしているところを、小型の飛行ユニットで空をとぶヴィラン、ブラッディクロス(血十字)が襲撃している真っ最中でした。
ブラッディ・クロスさん
キャプテン・チャイナもさっそく戦闘に参加し、ほかの警備員のもっていた銃でなんとか応戦するもののいかんせん性能不足は否めません。「主席! この拳銃では非力です。レボリューション・キャノンの使用許可を!」「許可する!」といったわけでレボリューション・キャノンを使ってみごとにブラッディ・クロスを撃退。すんでのところで取り逃がしたものの、大統領の命は救われたのでした。めでたしめでたし。

とまあそんな感じ。
ほかにも、「コードネームはキャプテン・チャイナ(英語でcaptainは大尉のこと)だけど自分は軍では少佐だった」とか、どう拾っていいのかわからない小ネタがあったりして、マジなのかネタなのか判断に苦しんでいます。どうなんだろうこれ。
とはいえまだ最初のエピソードが終わったばかり。ブラッディクロスが何故かキャプテン・チャイナの本名を知っているという衝撃(まあいちおう……)の展開や、謎のタレコミをしたのが誰だったのかなど、伏線はいろいろある気がします。
ぼくはたぶん続刊は買わないと思いますけど。

2012-05-16

Go言語の型宣言をHaskellから理解する

という誰得記事を書いてみたいと思います。

Goの型システム……というかtype宣言はなかなか面白いんじゃないか、ということに最近気づきました。type宣言は新しい型を宣言するものです。たとえば、A Tour of Goのだと、
type Vertex struct {
X int
Y int
}
のように宣言します。これは当然のように思われるかもしれません。
ところが、type MyFloat float64 のように宣言することがあります。これはどういう意味があるのかというと、実態としてはfloat64なのだが新しい型として定義したい、という意思表示となります。

具体的に、これが意味するものとしてメソッド宣言を見てみましょう。VertexにAbsというメソッドを定義した場合:
func (v *Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
このように表記します。このとき、*Vertex 型の変数 v について v.Abs() とメソッド呼び出しができるわけです。
同じように、type MyFloat float64 として宣言したMyFloatに対しても、メソッドの宣言ができます():
type MyFloat float64
func (f MyFloat) Abs() float64 {
if f < 0 {
return float64(-f)
}
return float64(f)
}
というか、どんな型に対してもメソッドの定義ができます。ただし、異なるパッケージの型に対して勝手にメソッドを追加したりできない、ビルトインの型も同様に挙動を変更させることはできない、という制限があります。そのため、既存の型と実態は同じだが独自の意味合いを持たせたい(実態としては数値だが特別な意味を持たせたい、というような場合)にこういう型定義によって別の型をつくることになります。この場合、Abs()というメソッドはMyFloatという型に対してついているのであって、float64に対して呼ぶことはできません。
つまり、float64MyFloatはほんとうに別な型なのです。たとえば上のコードサンプルでreturn fとすることはできません。Abs()が返すべきのはfloat64だからです。MyFloatfloat64は加減乗除等の演算も行えません。事前に型変換を行う必要があります。

たしか『入門OCaml』だったかとおもいますが、会計処理的なシステムで、消費税込みの金額とまだ税を組み入れてない金額が両方あるので混乱しがちになるという話が出てきて、phantom typeを導入して型安全を保つという事例があったとおもいます。同じことがGoのtype宣言では可能です。

この挙動は面白いし便利だと思う一方、C/C++のtypedefを知っていると、とても奇妙に思えます。C/C++のtypedefは簡単に言うと型に別名をつけるだけだからです。typedef float MyFloat、などと書いてもMyFloatfloatは区別されません。floatを引数に取るメソッドにMyFloatを与えても構いません。C/C++を使っている場合、これはこれで便利なものです。

ここでC/C++のtypedef相当の言語とGoのtype相当の言語を両方併せ持つ言語といえば、そう、皆さんご存知のHaskellですね(やっと出せた)。Haskellでいうとtype宣言がC/C++のtypedefであり、Goのtypeに相当するのはnewtype宣言だと言うことができるでしょう。
Haskellのnewtype宣言というのは、実態としては他の型と同等であるが、全く別の新しい型として定義したい、という場合に使います。たとえばA Gentle Introduction to Haskellでは、Integerと実態は同じであるが正数のみを扱うNatural型を定義しています(日本語訳)。Goのtypeはまさにこれと同じことをします。Natural型に対して定義したメソッドがIntegerに影響を与えないところも同じです。

ところで、Goにはtypedefはありません。既存の型に別名をつけることはできません。例えば上でVertexという構造体が出てきました。ここで、type Vertex2 Vertex などとしても、*Vertexに対して宣言されたAbs()メソッドは、*Vertex2型の変数にたいして呼ぶことはできません。
不便じゃないんでしょうか。そもそもtypedefってなぜ必要なんでしょうか。

Haskellのtype宣言は、既存の型に別名をつけるという意味で、まさにtypedefです。実例としても、String型は実際のところ文字のリスト[Char]型である、という代表例もあります。これはまさに同じであって、String型の値はリストとして扱うことができます。リストを引数に取る関数はすべてStringを扱うことができるし、パターンマッチもできます。これがnewtypeとして別の型になってしまうと、Haskellのリストを扱うためのパワーをスポイルしかねません。いっぽう、Stateモナドは、実態としてはただの関数だけども、newtype宣言でState型として宣言されています。こういうものはHaskellではtype宣言では扱いづらいし、ややこしい問題もありますが、newtype宣言によって状況はかなりクリアになります。
ようするに、「メソッドは引き継がれない」「別の型として扱われる」という点がメリットになるかデメリットになるか、というのがnewtypeを使うか、typeを使うかの違いになっているといえるでしょう。

Go言語では、どうして他の型のエイリアスを作らなくても問題にならないのでしょうか。たとえば、
var f1 MyFloat = MyFloat(1)
var f2 float64 = 1.0
f1 + f2
などとするとコンパイルエラーが発生します。f1f2は異なる型なので演算はできません。実際、上で挙げた例のように、税抜の金額型と税込の金額型を別の型として宣言している場合、この2つの型の変数同士を気軽に足せてしまったら分けた意味が薄れるので困る。f1 + MyFloat(f2)などとしなければならないわけです。

ところが、
var f1 MyFloat = MyFloat(1)
f1 + 1.0
これはエラーになりません。
Go言語には暗黙の型変換はないのだけど、数値リテラルは特定の型の値を持つわけではなく、文脈によって適切な数値型となり、実態として数値の型であるモノ(MyFloatとか)も数値型とみなされます。演算子もまた、数値型に対して有効であるという定義であり、オーバーロードや再定義ができません。このように演算子やリテラルを特別処理にすることで、暗黙の型変換なしに、異なる型であっても、こういうよくある表記では問題を起こさないようになっています。

また、メソッドについてはどうでしょうか。HaskellのString[Char]と同等なのはリストに対するオペレーションを使いたいからだと思います。ただ、Go言語のメソッドや関数では、多くの場合インタフェースが一致しているかどうかだけが大事で、継承関係を必ずしも持つ必要がありません。このため、既存の型と構文上も同等に扱いたいというモチベーションがそれほど高くないのではないか、と推測しています。
Go言語を設計するにあたり、どれぐらい慎重にこういったことが決められたのかはぼくは知らないのですが、こういった事例からは、「こうしておけば実用上問題ないでしょ」という思い切りのようなものがあるな、と思うのです。
実際のところ Haskell にしたって type 宣言を書くことはそう多くない気がします。なくてもかまわないといえばかまわない、Stringだけがうまくいけばそれで良い、そういうヤツなのではないでしょうか。だが、既存の言語の枠組みで「String[Char]のように扱う」ためには、type宣言のようなものを持ち出すか、さもなくばStringを特別扱いしなければなりません。特別扱いはイヤだ、言語の定義で直交性を保ちたい、という美的センスがあるのではないかと思うのです。

直交性というのはプログラミング言語の「美しさ」を語る上では大事なキーワードだと思うのですが、Go言語では、そこまで最重要なポイントとみなされていないんじゃないかという疑念を抱いています。もちろん軽視しているのではないでしょうが、「大事だけどほかに重視すべきことがある」という価値観があるように思います。
でもそれでいいじゃん、動くし実用上は問題ない、といえるのがGoの面白いところだなと思った、というところで締めたいと思います。

2012-04-17

mosh (mobile shell)の論文を読んでみた


mosh: MITからモバイル時代のSSH代替品という記事を読んでmoshというモノの存在を知りました。で、USENIXに採録予定の論文があるというのでそれも読んでみました。

moshでは、作者が独自に設計したSSP (State Synchronization Protocol)というトランスポート層の独自プロトコルを使っています。SSPというのは大雑把に言うと、下層にUDPを想定して、状態を送り合うというプロトコルのようです。
ターミナルのようなアプリケーションの場合、クライアントにせよサーバにせよ知りたいのは最新の状態であってそれ以外はドロップしてしまっても問題はない。そこで、UDPの1データグラムに収まる範囲で状態を送り合うということを想定しています。コネクションを張らないことで、クライアント側は途中でいきなりIPアドレスが変わっても問題が起きない、というのが「モバイル時代の」という触れ込みの所以です。
暗号化と認証についてはSSHに乗っかるようです。まずクライアントはサーバにSSHで接続します。するとサーバ側ではふつうにユーザプログラムとしてmoshサーバが起動し、ランダムな暗号鍵を生成してクライアントに送ります。クライアントがこれを受け取ったらSSHのコネクションは切断しても大丈夫で、あとは各パケットをこの共通の暗号鍵で暗号化します(nonceも使うので、リプレイ攻撃の問題はありません)。

moshのもうひとつの特徴がlocal echoです。ふつうのリモートシェルではキー入力はサーバに送られ、サーバからエコーバックが返されて初めて表示されるわけなのでどうしても遅延が発生します。moshではローカルの側で一時的にエコーを表示しておいて、予測通りだったらそのまま確定させる、といったことをします。このため入力のフィードバックがすぐ得られるという利点があります。
もっともこれは大きな問題もあって、sudoしたりとかvi使ったりとかすると余計な文字が出てきてしまう。そこで状態を予測してlocal echoしたいときだけする、みたいなことが書いてあります。しかし論文には出しちゃいけない状態だということがわかったらすみやかに消す、みたいなことしか書いてない気も……。コードを見ても、たんにRTTとかをみて充分に高速だったら表示しないだけな気も。あまり良くわかりません。sudoのパスワードは見えそうな気がしますが……。
なんとなく直感的には、状態をlocal echoあり、なし、不定の3状態にしておいてありのときだけlocal echoする、改行等で状態を不定に戻す、不定からはサーバのエコーバックを見てありに遷移、といった単純なものでも充分マシな気もしますが、毎回微妙な遅延があるのが嫌だったんでしょうか。

この論文はしかし、以上に書かれていない、全体の4分の1ほどの内容がなかなか味わい深いのです。moshというのはようするに仮想端末の再実装なので、仮想端末のめんどくさいところにいろいろ遭遇してしまった、そういう苦労話みたいな話があるのですね。たとえば、

  • ISO-2022は状態があるのに、状態を戻さない壊れたファイルをcatしたりすると端末が文字化けして回復できなくなるんだぜ!
  • UTF-8も表示できるようにしたぜ! ところでECMA-48にはそういう話は記載がないのだが(略)
  • CJK文字って倍幅なんだよな! しかも行末に半分だけ余白がある場合は(略)
  • ローカルとサーバでlocaleが違うばあいに(略)
  • そもそもどうやってlocaleを指定するかというと(略)
……などなど。
論文本体よりは個人的にはこの辺の苦労話が味わい深く感じられる論文でした。そういうところはあんまりまっとうな論文という気はしないけど(USENIXにはありそうだけど)、片手間に読む分にはなかなか面白いのでみなさんもぜひ読んでみてください。

2012-03-31

BBCのテレビドラマ『シャーロック』第二期を見た

昨年夏にNHKでも放映された、イギリスBBCのテレビドラマ『シャーロック』。シャーロック・ホームズの物語を、舞台を現代に置き換えて翻案したドラマで、評判になりました。本国では実は第二期がこの冬に放映されていて、もうDVDは出ていたので見てみました。

設定は同じで、ストーリーも第一期の直接の続編。ただ、ワトソンの書くブログは趣味的な側面が強くなっていき、ホームズの活躍を伝えるものとなっています。そしてブログによってホームズの存在も話題になり、ネット世代のプチ有名人みたいな扱いに。
画面のつくり、とくにシャーロックの推理シーンのかっこ良さは第一期そのままなので、そのままの続編として楽しめる作りで、おすすめです。第二期も第一期と同じく、1話90分で全3話。ひとつのエピソードで90分は長い気がするのですが相変わらずスピーディな展開。またハイスピードカメラを使った映像など凝った画面がとてもカッコイイ。

第1話 A Scandal in Belgravia
原典の「ボヘミアの醜聞」 (A Scandal in Bohemia) をベースにしたエピソード。アイリーン・アドラーが登場してシャーロックと丁丁発止のやりとりを繰り広げるサスペンス+淡いロマンス。シャーロックはアイリーン・アドラーのもつ機密を奪回することになるが、アイリーン・アドラーはシャーロックとも渡り合えるほどの切れ者で、シャーロックとは惹かれ合うようになる……。
タイトルのBelgraviaはロンドン中心部の高級住宅街のことだそうです。

第2話 The Hounds of Baskerville
『バスカヴィル家の犬』 (The Hounds of the Baskervilles)をベースにしたエピソード。タイトルのわずかな違いからもわかるように、このエピソードではバスカヴィルというのは家名ではなく地名。バスカヴィルという場所に軍の研究施設があり、周辺では恐ろしい魔犬のうわさが流れていた。軍研究施設から脱走した強化犬だというもっぱらのうわさだが……?
途中の推理シーンは今期の白眉ともいうべきシーンでしょう。カッコイイ! 岩石の上に立ち、周囲を見渡すシーンもカッコイイ。

第3話 The Reichenbach Fall
タイトルのライヘンバッハの滝といえばスイスにある滝ですが、ここはもちろん原典ではモリアーティ教授とホームズが対決し、墜死したことで有名(生きてたけど)。そういうわけで前期に引き続き、モリアーティとの直接対決のエピソードです。モリアーティはどうやってかロンドン塔、イングランド銀行、ペントンビル刑務所の警備システムを破り、自身もロンドン塔にある王冠の強奪を敢行。急行した警察によって取り押さえられ、モリアーティの裁判が始まる。モリアーティはいったい何を目論んでいるのか? そしてシャーロックは?
冒頭からワトソンが My best friend, Sherlock Holmes, is dead. と言うところから始まる本エピソードですが、いったい物語がどう進み、結末はいったいどうなるのか、本当に死んでしまうのか? ところでこのタイトル、直接的にはもちろんライヘンバッハの滝のことですが、いくつかの意味が込められています。

ということで、おすすめです。NHKでもまた放映するんじゃないのかなー。しないのかなぁ。

2012-03-26

ブルース・シュナイアー "Liars and Outliers"

忙しくて文章を書く暇があまりなかったが、ブルース・シュナイアーの新作 Liars and Outliers: Enabling the Trust that Society Needs to Thrive を読み終えていた。
本書は "Beyond Fear" (邦訳:『セキュリティはなぜやぶられたのか』)の続編に当たる本だと思う。シュナイアー先生がふたたび、社会を相手に自らの知見を述べるといった体裁の本だ(実際には、この間に書かれた他の本を読んでないので、もうちょっと流れがあるのかもしれないが)。
"Beyond Fear"では、9.11以降のアメリカ社会、とくに空港のセキュリティチェックが厳しくなってきた現実を踏まえ、それがいかに形骸化して効果をもたらさなくなっているかを指摘していた。そして、セキュリティというのはプロセスであり、常に人の手で運営され、見直される必要があることを提言していた。
この本は、そのもっと前提部分に立つ。社会がなぜ、どのように成り立っているのか、セキュリティはその中でどういう地位を占めるのか。
本はこういうシーンから始まる。まさに今日、見知らぬ人間が家の前に来て水漏れを直しに来たと伝える。著者はその人のIDを確認することもなく家に招き入れ、その人物もまた、ふつうに修理をする。修理が終わればお金を払う。家のものを盗もうともしないし、家主も勝手に奪ったり、支払いを拒否したりしない。そんなことがあるだろうと気に病むことすらない。
なぜか。それは信頼があるからだ。その水道工との信頼関係ではない。なんせその人とは初めて会ったところだ。でも社会への信頼がある。互いに同じ社会に属し、その行動規範に則っているという信頼がある。

これがこの本のテーマである。
たとえば囚人のジレンマという問題がある。二人の容疑者がいる。互いに別々の部屋に入れられ、相手を告発するかどうか持ちかけられる。互いに黙秘していれば、1年間投獄される。相手が黙秘して自分が告発すれば、自分は釈放されて相手は10年間の投獄をされる。両方ともが告発すれば、両者とも6年の刑に課せられる。
このとき、相手がもし黙秘しているのだとすれば、自分は黙秘をしていれば投獄され、告発すれば釈放される。もし相手が告発をするのだとすると、やはり告発したほうが自分の刑期は短くなる。したがって、どんな場合でも告発するのが合理的となる。
ここでシュナイアーがユニークなのは、いわゆる繰り返し囚人のジレンマ問題に持ち込まなかったところだと思う。よくある「しっぺがえし戦略」はここでは扱わない。囚人のジレンマの問題を1回だけ行うとして、どうなるだろう。
実際の問題で似たようなシチュエーションを考慮すると、そうするのが合理的であっても告発してばかりの殺伐とした状況にはならない。なぜか。僕たちはどうやって信頼を構築するのだろう。
というのがこの本のテーマである。
以降、様々なシチュエーションを考慮しながらいかにして社会的な圧力(societal pressure)が構築され、人々にとって協調的に行動することが合理的になるか、ということを示していく。倫理観、評判、社会システム。そしてセキュリティはそれらの仕組みを支えるためのテクノロジーとしてのみ存在する。
だが、社会の仕組みとしていかにうまく協調的な行動を導こうとしても、完全にはうまく行かないことも強調する。嘘つき(Liar)や例外(Outlier)は必ず存在してゼロには決してできない。むしろ、ゼロは目指すべきではない。それを目指すことで不必要な社会圧力や仕組みが生まれ、社会は高いコストを払い続け、失敗に追い込まれるのだ。

シュナイアーが"Beyond Fear"を書いたのは、9.11への反動ともいうべきアメリカ社会の反応に感じるところがあったからだろう。基本的に本書の姿勢もそこに立脚しているようで、多少は9.11に関係するポイントもある(だが、その扱いは注意深い)。いずれにせよ、日本人の読者としてはやはり震災後の原発をめぐる議論について思わざるをえない面もある。
久々の力作ということもあって、たぶんこの本もすぐに邦訳が出ると思う。そのときにでも是非読んでみて欲しい。
おすすめ。

2012-02-07

EPUBが論文出版のデファクトスタンダードになる日は来るか

で、一つ前のエントリでも書いたようにKindleはわりと愛用するようになったのですが、不満な点もあって、論文。論文が読みづらい。

KindleにはPDFの表示機能が組み込まれてはいるのですが、なにせ画面が小さいので、もともとA4(やレターサイズ)で表示されることを前提にしている論文だと文字が相当小さくなってしまう。ましてや2-columnの論文となるともう無理って感じです。またページ繰りもじゃっかん遅い。ユーザエクスペリエンスがまずい。拡大して読む、ということもできないし。
シリーズの中でもKindleDXだけは比較的大きいので論文とかも読みやすいのでは、という考えに基づいて私も買ったことがあるのですが、これも間違ってたなあというのが正直なところ。上に挙げた文句のうち、「画面が小さいので読みづらい」という問題が若干緩和されているだけで、ユーザエクスペリエンスがよくないといった話は全然解決していないのですね。
一方、携帯電話やタブレットで読むという選択肢もちょっとないな、と思っています。これも前のエントリに書きましたが、Kindleに慣れてしまうと、E-Inkの読みやすさというのを実感します。それに、特に携帯電話で、ページの一箇所を拡大表示で読むというのも読みやすいのかなぁというのが若干疑問だったり……。

というわけで掲題の話を、ちょっと前から思っているわけです。そもそも論文をPDFで配布する必然性って、ないよね? EPUBとかのほうがいいんじゃないのかなあ?

PDFというフォーマットが悪いということは全然ないのだけど、PDFは「紙」とか「ページ」とかいった概念に強く依拠するフォーマットだということは言えます。だから紙に印刷して読むならとてもいいんです。いっぽう、昨今の電子書籍フォーマットでは、もはやページという概念すらなくなっている。たとえばAmazonの「なか見検索」でも、Kindle版の場合は上下になめらかにスクロールするUIになっちゃっているわけです。
そしてこの、ページという概念がないというのがキモでして、デバイスごとに違う文字サイズで表示できるし(ユーザも文字サイズをカスタマイズできるし)、デバイスごとに一画面分の文字数(単語数)がかわるということもありうる。だからどのデバイスでも読みやすいように読める。
ま、ようは、紙で印刷して読むならPDFも優れていますが、紙を使わないなら電子書籍デバイス向けのフォーマットというものがあり、そちらを使うといろいろ捗るぞ、というやつではないかと思うわけです。

でも実際問題としてどうなの、という面はあると思います。電子書籍デバイスは現状、相当の趣味人でないと持っていないものなのは確かなので、そういう人向けに頑張るというのも何かおかしい気がします。いちおうEPUBをパソコンなどで読めるソフトもありますが、電子書籍デバイスを持ってない人はそれで頑張れ、というのもいかがなものか、という気もします。だめなら印刷する、というのもありだとは思いますが、EPUBのデータを紙に印刷してPDFの品質に勝てるのか、というのは疑問です(っていうかやったことないからわからないのですが……)。
一方で、巨大な学会のproceedingsなど、昨今もはや紙に印刷するほうが珍しいのではないかという気もします。PDFの入ったデータを全員に渡しておしまいで、後日に一部だけ選んでエルゼビアから出版される、というパターンもおなじみなのではないでしょうか。私はだいぶ長いこと学会とかには行ってませんが、私が学生時代だった当時でさえ、分厚いproceedingsは定番の「忘れ物」でした。CDなりなんなりで電子データのみを配布する、というのは一般的でした。今ではそれがむしろ普通でしょう。
とすると、紙に印刷することを前提にしたPDFというフォーマットの利点は、実はそれほど大きくないのではないかという気もするのですが、どうですかね……。

技術的な話としては、latex2epubというのはとっくの昔に作られています。もちろんクオリティはわからないけど、latex2htmlはもともとあったわけですから、同程度のクオリティを目指すのは不可能ではないのかなと。となると、大学の先生におかれては、ぜひ、PDFとあわせてEPUB形式でも公開してほしいなあ、と思っているところではあるのです。もっとも、latex2htmlで論文をhtml化して公開しているのも相当の「趣味人」だけでしたから、こういう草の根運動は実を結びそうもないのかも……。
この話を同僚と話していたら、「TeXやDVIから変換したPDFはパターンがあるから、PDFからEPUBに変換できるんじゃないか」というアイディアも出ました。それはクールかもしれません。それでもいいなあ。うーむ。

いずれにせよ、学術出版の世界で電子書籍というのはもっと注目されたり実験されたりしてもおかしくないのになあ、とは思います。私のあずかり知らぬところで、きっと色々進んでいるのだろうな、と期待しつつ、様子を見ている外野の私なのでした。

2012-02-03

電子書籍強化月間のまとめ

電子書籍で生活をするという30day challengeが完了したので、まとめます。

チャレンジの概要
スタート時にこちらにまとめました。紙の本を一切読まず、それに充てていた時間を電子書籍に使うというものです。まんがや雑誌も「紙の本」に含まれる、また紙で売られた本をスキャン(いわゆる自炊)したものは電子書籍には含まない、といったレギュレーションを課しました。ちなみに所有している電子書籍デバイスはAmazon Kindleのみです。Androidデバイスは持っているので、それをサポートする環境はいちおう使えるのですが、E-Ink以外で読むのは抵抗感があり、使っていません。

読んだ本
実態はどうだったか?
読書時間は平日はあまり多く取ることができておらず、これもこれでなんとかしないといけないなあと思うわけですが、この辺の改善は行わないまま、今回のチャレンジを始めてしまいました。結果的に読書時間はそれほどかわらず、大して分量を読めないままだったという現状認識が、まずあります。
とはいえ、リストしてみると意外と冊数があります。私は普段の読書量だと、月間で4-5冊といったところだったと思うので、一見するとそれよりは多いですね。とはいえ、日本語の本はどれもかなり短いものが多いので、あまりたくさん読めたという気がしません。英語の本はさすがに読むスピードも遅いし。長編は実質的には1冊、Charles Yuの本しか読んでない。Kelly LinkのPretty Monstersは短篇集、F&SF誌も中編が6本とか入っているので分量もあり、短編はちょっと体力を使うというのを実感しました。

まんがについては、余力があればウェブ雑誌を探してみたりしてもいいかなと思ったのですが、他の本だけでも十分に読むものは多かったので、けっきょく挑戦に至りませんでした。単行本も買っていません。ただし、単行本については前提として、電子書籍は刊行から数ヶ月遅れてやってくることが多い、という事情もあるような気がします。興味のあるまんがはだいたい新刊で買っているので……。

感想と今後
30day challengeは、二通りのパターンがあると思います。第一には生活スタイルを変えるというパターン。毎日自転車で会社に通う生活をしてみる、というチャレンジですね。こういうチャレンジの場合、期待される効果としては、生活スタイルが変わり、今後も毎日ではないにせよ自転車出勤生活を続ける、というものになります。
一方で、30日で小説を書き上げる、みたいに、新しいことを挑戦してみるだけでその後も続けるとも限らないタイプのチャレンジもあるとおもいます。この場合は、ひとつ何かを成し遂げるというものですね。
今回の件についてはその辺の認識が中途半端なまま始めてしまったという反省点があります。とりあえずお試しで電子書籍に注力してみたものの、今後も電子書籍のみの生活ができるかというと、まあできないだろうなと思いながら始めていたのです。かといって、何かを成し遂げるというようなタイプのものでもないし。

しかし、ひとまずのところ、電子書籍のみでの生活というのはどうかというと、なくはない、といったところだと思いました。とくに英語で本を読むならほぼ支障はないと思いました(新刊が即Kindle化されるとも限らないし、すべてがKindle化されるわけでもないので、今後の電子書籍ライフではそのへんも気に掛かるところですが)。一方、和書はまだバリエーションが少ないため、完全移行は難しいと言わざるを得ないと思いました。したがって、翻訳書から徐々に電子書籍に移行していくという当初の想定通りの流れになりそうな気がします。
問題はむしろ、紙の書籍と電子書籍のバランスをどうするか、という点にあります。正直わたしも紙の本という物体への愛着は薄い方なので、紙の本は可能な限り回避したいという意識があります。またそれは今回のチャレンジでかなりはっきりしてきました。今所持している本の処分を進め、また新しく購入するのは控えめになるのではないか、と思っています。

ただ問題はまんがでして、まんがはそれ以外の書籍よりはるかに権利関係が厳しく、電子書籍化があまり期待できません(確かに、下手に弱い制限で販売して一番海賊版などが出回りやすいのはまんがだろう、という悲しい現実は理解できます)。スキャンも明白に禁止している出版社や作家が多いので、こうなるとなるべく買わないか、買っても読んだら捨てるというオプションを取るしかなくなってしまっています。まんがとどうつきあうか、というのはもう少し様子を見て考えたいと思っています。

紙の本のスキャンについて
ところで、自分で紙の本を買ってスキャンするのは、過渡期の技術としてアリかなあと思っていたのですが、なんというか、わりとどうでもいいような気がしてきました。自宅に累積した本には何らかの手段で電子化してでも保存したいものがあるため、スキャン自体は、ある程度は継続をするつもりです。ですが、持っている本の大部分は処分しても問題ない気がしますし、新しい本を買って電子化して読むというのはあまり私の生活スタイルには合わないと思いました。
スキャンした本というのは、ようするにページの画像データのことですが、電子書籍デバイスで読むのはあまりおすすめできるユーザ体験ではないと思います(Kindleの画像表示能力がそんなに高くないという個別事情もあります。解像度の調整をしないと相当読みづらい)。紙の本として購入したものを、あえて労力を費やして電子化してから読むというのはメリットが薄いと思いました。そのまま紙の本として読むほうがなんぼかよろしい。まあ、分厚い本であれば、持ち歩きやすいという利点があるかな、とは思いますが……。
とはいえ、上でも書いたように、今ここにある本の山のうち、いくらかを電子化して保存するという行為については否定的ではありません。後から参照し、必要な箇所だけ読むという面では、電子化することの利点もそれなりにありそうです。ただ現状、縦書きの書籍のOCRの精度は全然よくないものが多い気がするので、本によっては「後から検索したい」という欲求は満たしづらい場合もあります。

電子書籍デバイスについて
上にも書いたように、今回は電子書籍デバイスとしてはAmazon Kindleのみを所持という状態でスタートしました。チャレンジをはじめる前に事前調査をもっとすべきだったとあとで思いましたが、現在の日本の電子書籍サイトでKindleというのはまったく役に立たないデバイスとなっています。基本的にはSony Reader、PC向けにWindows、タブレットならiOS、という環境のサポートが主になっていて、Kindle、Mac、Androidな私はまるで手がでない(笑)。AndroidやMacのサポートはまれにあるのですが、品揃えの問題と、発光する画面で本を読むというのはちょっとありえないという考えから、まったく頼むことはありませんでした。上に挙げた日本語の本は、どれもEPub形式で購入しています。もっともKindleはEPubも表示できないので、Calibreで変換しています。
Kindle自体は私はとても好きなデバイスなのですが、実際問題として日本でもKindleが支配的であるべきだとも思いません。楽天が買収したKoboが日本に来るという話もあり、これもこれで期待しているところです。結局のところ品揃えの多寡で決まる面が大きいと思うので、いい品揃えであればデバイスには強いこだわりは、私には今のところないのです。
ただやはり、E-Inkは必須だと思いました。発光するデバイスで本を読むのは正直しんどいです。またKindleは圧倒的に軽い、という利点もあります。実際、私もいっときAndroidタブレットを入手したときにはKindle終わったな、と思ったのですが実態は全く逆でした。重量には大きな意味があります。軽くて読みやすい、という利点を他のデバイスがどう乗り越えるか、というのが要点だなと思っています。

2012-01-27

コンテキストスイッチ力

最近、社内で関わるプロジェクトが移り、当然と言えば当然だが生産性が低下している。ついでに、長いビルドの暇な時間に、プログラマの生産性ってなんだろうな、ってなことをぼんやり考えたりしている。
スーパーエンジニアは凡百なエンジニアの数十倍とか数百倍という生産性があるという。数十倍かはわからないけど確かにものすごく生産性の高いエンジニアというのはいる。いるのだけど、何故彼らは生産性が高いのか。っていうか、そもそも生産性、ってなんだろう。

一般的にプログラマの生産性というとコーディングスキルだと思われている気がする。だけど、それだけなんだろうか。そりゃ優れたコードを書くのは才能だし、スピードも才能で、ぼくにはそんなものはない。ただ、言語も開発環境も大同小異なプロジェクトのメンバー同士でも、かなり生産性には差がある。この差がコーディング能力だけでつくとはとても思えない。

高林さんの文章で、プログラマの生産性についての考察があった。いちいちうなずくこと然り。レスポンスが異常に速いとか、フットワークが軽いとか、終わらせるとか……。と読みながら、ひとつ付け加えることがあるとすれば "コンテキストスイッチ力" があるんじゃないかと思った。コンテキストスイッチのコストが低い人は総じて生産性が高い。

プログラマの仕事というのは、意外と待ちの時間があるものだ。ビルドに費やしている時間、データをダウンロードしたりアップロードしたりする時間。解析プログラムが巨大なデータを処理している待ち時間。レビューやメールの返事待ち。その他もろもろ。
そういう細かい空き時間をどう使うかというのは生産性に大きく寄与している。複数の作業を効率良く並列に進められるか。関連するコードを読んでみたり、論文に軽く目を通してみたり、メールの処理時間に使ったりもできる。
私はコンテキストスイッチのコストが高めなので、ビルドのログが流れていくのを眺めながら、比較的どうでもいいこと(プログラマの生産性ってなんなのか、みたいなこと)をあれこれ考えたりしてしまう。
ビルド中にメールでも書こうか、とメールの画面に移って、書いていたら意外と手間取ってしまって送信してほっと一息ついたら実はとっくの昔にビルドが終わってて、本当はその後にテストを実行させないといけなかったのだが……みたいなあるあるネタを実際にやっちまったりして。……あるよね?

コンテキストスイッチのコストはどうやったら下げられるのだろう。

そんなことが分かっていたら、こんな文章を書いているはずがないので(笑)、私にもよくわからない。だがひとつ仮説として考えているのは、自分の作業フローを見通す能力なのではないかということだ。今からメールの返事を書くのにどれぐらいの時間がかかるのか。ビルドはどれぐらいの時間で終わって、その間にできることは何か。作業時間の予測とか、比較的短いスパンで何ができて何をどの順番でやるか、というのを把握していれば、テンポよく作業を進めることもできる。
レスポンスが速いというのもそういうことだ。メールやチャットで連絡が来たときにプライオリティ付けがきちんとできないと、連絡したのにいつまでも返信ができない。逆に、チャットで相談に乗っていてひととおり解決したところでさっきまで何をしてたっけ……とならずにすぐ復帰できる人は生産性が高いし、自分はすぐ復帰できるからこそ連絡にきめ細かく対応できる。
また、こういう知識や優先順位づけは一般化しづらく、プロジェクトやチームによっても往々にして変わるから、プロジェクトが変わると生産性がいったん落ちたりするのだと思う。

プログラマの界隈ではよく「フローに入る」という表現がある。それがどういう意味なのか正確に把握している自信はないけど、少なくともコンテキストスイッチをよしとしないということだ。人間、コンテキストスイッチのコストは決してゼロにはならないので、それを減らして作業に集中するというのもひとつの作戦だ。だけど、それが全てでもないのでは、と思う今日この頃。
たぶんきっと、このへんはプロジェクトの性質にも関わっている。ビルドにどれぐらいの時間がかかり、テストの実行やレビューや各種のプロセスがどうであるか、というのにもよる。個人プロジェクトに近いものほどフローが重視され、大きなプロジェクトではコンテキストスイッチは避けられないものとして対峙する必要があるのかも。

いずれにしても、コードを書くパワーだけが生産性ではない。だけど何しろコードを書いて生活しているように思っているので、そこを頑張ってしまいがちなのではないか、とちょっと思っている今日この頃です。

2012-01-25

テキストフォーマットからの脱却

ありのさんにPowerShellの話の要望を出したら運良く書いていただいたのだが、これが面白い。
私のざっくりとした把握では、PowerShellではテキストだけじゃなくてオブジェクトも直接パイプを使って受け渡しできるみたいなシステムだったかと思うけど、やっぱしそういうのは面白いなと思う。興味はあるけどWindowsはもうずっと使ってないからなぁ。

似たようなことを考える人は、たぶんほかにもいて、たとえばTermKitはJSオブジェクトを受け渡すような感じになっているし、きっと似たようなことを考えて、UNIXな世界に持ち込もうとした人はほかにもいたのだと思うが、今のところ全滅な気がする。

しかし、なんでUNIX系のシステムではこういう考え方が普及しないのか。
個人的には、UNIXの世界の根底に流れる思想がテキスト志向だからだと思う。もともとUNIXの開発の名目は文書処理システムだった、といった神話があるが、真偽はさておき、UNIX系システムには共通のフォーマットというものがない。データは基本的には行志向のhuman-readableな文字列で、それぞれのプロセスがそれぞれなりに文字列処理をするという文化になっている。そんななかで成長してきた便利ツールも、ファイルも、そういった文化を受け継いでいる。単純な空白区切りやタブ区切りでも、よっぽど変な場合を除いてはだいたいうまく動くし問題ないわけ。
そして、その文化を反映するようにUNIXではテキスト処理のツールというのがものすごく充実している。catやheadやtailを使って人間が目で見て、簡単なエディタ(ed/sed/vi)でちょちょっといじれて、cutやheadやtailやuniqやsortやgrepで処理できる世界がもうそこに展開されている。たとえばちょうど偶然nokunoさんがテキスト処理用のUNIXコマンドまとめという記事を書いているが、これがまさにUNIXなのだと思う。
日付の処理も、dateコマンドとexprで頑張る変態テクニックが、きっと探せば出てきて、それがきっとUNIX wayなのだ。

そんな世界をPowerShellみたいな世界観にもっていくのは大変だ。できるのはほぼ同じ事なうえに、過去の資産を生かせない。ここでいう過去の資産ってのは別に各種ツールの実装の問題だけじゃなくて、今まで持っていたデータファイルなども含まれる。こういったものをうまく扱えるようにしつつ、過去の資産と比べて実利がなければうまくいかないし、UNIXの世界はよく言えば自由、悪く言えばカオスなので、オブジェクトの形式を揃えるなんて夢のまた夢だろう。
psやtopのようなコマンドを簡単に処理できればいかに楽かと思う時もあるのだけど、そういうのはperlとかpythonとかrubyとかで、直接APIを叩くほうがいいってことになってしまう。

実際、こういうツールの代わりに、irbを立ち上げっぱなしにして、何かあったらrubyを使うという人はわりといると思う。
それはまぁ、合理的な選択でもある。

PowerShellでなんでああいうことができたのかというと、まず .NET 環境というものがあるWindowsだからだったのだと思うし、UNIXとは「文化がちがーう」という奴なのでこれはまあ仕方ないというしかない。だけど、こういうテクノロジーの可能性を見るのはとても面白いなーと。

2012-01-20

甘酒づくり

去年唐突にやってみた甘酒づくりを今年もたまにやっています。
麹から作る甘酒は、自然な甘さがあって美味。初詣などで買える甘酒は酒粕から作ったものであることが多いのですが、これは文字通り別物というか、別種の飲み物といったほうがいい感じ。お酒のような匂いもなく、ただ甘いのです。

甘酒の作り方は、検索するといっぱい出てくるのですが、私の場合はだいたい以下のとおり。
まず、麹をどこかから入手します。スーパーで売ってるとのことですが、私の場合、近くを適当に見て回ったら見当たらなかったので、けっきょくamazonで買いました。分量はそんなに多くなくても大丈夫。

米の分量ですが、この時は半カップほどでした。これで完成後の分量は、お椀に2−3杯分できます。普通の紙コップで飲むなら4-5杯分ぐらい?けっこうな量ができます。
あと、麹もほぼ同量用意します。麹の量は、米と同量だとかなり甘くなって贅沢な雰囲気になるというのですが、ぼくや皆さんの場合、どうせそのために麹を買ったのだし、盛大に使いましょう。
ともあれ、用意した麹は水につけておきます。ぬるま湯(20-30度ぐらい)にするといいという話もあります。

米の方は、おかゆにします。おかゆは炊飯器でもできますが、ここでは鍋で作っています。鍋に米と3倍の量の水を足して、中弱火ぐらいで温め始めて、沸騰する頃に弱火にしていきます。頻繁にしゃもじなどでかき混ぜてやらないと底に焦げ付くことがあるので注意。まあ、鍋で作るおかゆの作り方も、ネットを探せばいっぱい出てきます。

おかゆが完成したら、まず冷ます必要があります。完成直後のおかゆは熱すぎるので、そのままでは麹が澱粉を分解して糖になる反応ができません。要するに全然甘くならないわけです。甘酒づくりの好適温度は50-60度と言われています。
もちろん厳密である必要はないので温度計で図るほどでもなくて、私は適当にやっています。小指を突っ込んでみて、我慢はできるけどちょっとつらいというレベルですね。お風呂よりはかなり熱いけど、すぐ引っ込めたくなるほどでもないというか……。
ともあれ、放置しているだけではおかゆはなかなか冷めないので、適宜水を足したりして温度を調整します。この辺は適当で大丈夫。
温度が適温になったら、先程水につけておいた麹をそのまま投入し、全体的によく混ぜます。
混ぜ終わったら保温します。甘酒を作るのはだいたい6-8時間ぐらい、簡単に言うと一晩ぐらいかかりますから、そのまま放置すると冷めてしまいます。冷めてしまうと好適温度から外れて甘くはなりません。
保温の方法は、炊飯器を使う方法や、こたつを使う方法などいろいろありますが、私のオススメは湯たんぽを使う方法です。湯たんぽをあらかじめあたためておいて、その上に鍋を置きます。
この状態で、保温のためにさらに周囲をタオルでぐるぐる巻きにしておけば、それほど熱が逃げることもありません。
これを作ったのは夜中だったので、ここまでできたらひとまずオヤスミナサイ、また明日〜。

で、一晩して出来たのが右の写真。見た目はあんまり変わっていませんが、これで完成です。
ただ、一晩放置しておくと、さすがにけっこう冷めてしまっているので、そのまま飲んでもそんなに甘みを感じません。なので、火にかけてあたためてから飲みます。火にかけるのは、混入した雑菌を除く意味もあるようで、放置すると酸っぱくなるという話も見かけました。

完成した甘酒は、コップとかだと米粒が残ってしまうので、私はお椀でいただいています。
今回のはなんだかものすごく甘かった! でもそれが美味しい。とてもいい出来でした。「酒」といいつつお酒らしさは微塵も感じられません。
ところで、甘酒は砂糖は使いません。米をおかゆにするときにできる澱粉を麹の力で分解して糖分にする、というのをやるわけです(この糖分をさらに分解してアルコールにするとお酒ができるわけですね)。
もっとも、自分で作ったものは何でも美味しい気がしてしまうものなので、何ごとも割り引いて考える必要はあります。でもやはり、自分で作るこういうものは美味しいし、何より楽しいなあという感じ。

ところで、これまで私は甘酒ってのは、麹が澱粉を分解して糖分を作るのだと思っていたのですが、実はちがうんだそうで、麹の好適温度は20-30度ぐらい。50-60度は全然快適な温度ではなく、コウジカビは死滅してしまうんだそうです。
じゃあ何が起きているのかというと、コウジカビがつくっていた酵素が澱粉を分解して糖にする、その酵素の好適温度が50-60度だというのですね。麹を水につけて戻してるときに「ぬるま湯だといい」というのは、コウジカビの好適温度にしてみて生育させつつ酵素を増やしたいのかな、という気がしていますよく知らんけど。

というわけで甘酒づくり、いかがでしょうか。時間はかかるけど作業自体はたいしたことはないので(おかゆを作って麹を入れて保温するだけですからね)、ぜひ皆さんもどぞー。

2012-01-15

財布のない生活への挑戦

年始にライフハック:分厚くて邪魔なサイフを薄くする方法 - Radium Softwareという記事を読んだ。財布から余計なものを省きたいと前から思っていたというのと、Google+で紹介したところ知人で似たようなことをやっている人がいるということ、あと私がKZR氏のファンだということ(笑)もあり、試してみることにした。

で、結論を先に書いちゃうと、全面的な撤廃には失敗。

まずは書いてあるように財布を撤廃して紙幣数枚と日常使うと思われるカード類、小銭を適宜ポケットに入れていたのだが、いろいろ問題が出てきた。
  • 小銭はポケットに雑然と入れているとごちゃごちゃになって取り出せなくなる。いきおい、支払いは紙幣で済ませてしまい、小銭がたまる。
  • 紙幣も雑然としており、複数種類が入り交じってしまい、支払い時にいろいろ滞りがちになる。紙幣はしわくちゃになったり、下手をするとちょっと破れたりした。
  • カード類もどれがどれかわからなくなる。束ねる必要はある。また、日常あまり使わないカード類は家に置いておいたのだが、たまに使うパターンで難儀することもあった。
小銭を収容しつつ紙幣もカードも全部入れられる財布というのは、やっぱりそれなりの歴史を経てああいう形態になっているのだなあと思ったのだった。もちろんその人のライフスタイルにもよるし、紙幣がしわくちゃになるとかそういうものは、ポケットに何を入れているかとかポケットに手を突っ込んで歩いたりするかどうかとかいったその人の日常行動の影響が強いと思う。
いずれにせよKZR氏の場合はうまくいったのだろうが、自分の場合はあまりうまく行かなかった。結局3日かそこらで音を上げた。

ただ、だからといって必ずしも財布を使う必要はない。自分が直面した問題ってのは、何らかの意味での収容用具はやっぱ必要だった、ってことだし。せっかくなので財布生活に戻るのも癪だ。というわけで、別な手段を検討した。

小銭:
財布でなくてもいいが、なんらかのかたちで小銭入れは必要だと思った。というわけで、写真にあるような小銭入れをハンズで買った。ただ、ポケットに入れるわけじゃなくてかばんに入れて持ち歩くことにした。かばんから出すのが億劫なシチュエーションでは紙幣で支払いを済ませて、つり銭はポケットに入れておき、帰宅してから小銭の整理をする。時間と心に余裕があれば小銭入れからの支払いもする、って感じ。

紙幣:
小銭入れと同時にマネークリップも購入した。専用のマネークリップも同じくハンズでいろいろあるが、それなりの金額はかかる。今使っているのは、やっぱり写真に写っているやつ。本当は、カードホルダーと一体化しているものというのもあって、それが良いかと買ってみたのだが、それなりにかさばるので買い直した。
ところで、マネークリップって必要? もっと安いクリップとか、輪ゴムとかでいいんじゃない? という気もする。まあ輪ゴムでもいいかもしれないけど、取り回しは不便かも。100円ショップで売ってるような安いやつでも何の問題もないと思うが、丈夫さが大事なので壊れやすいやつにはしないように。ポケットの中でするっと抜けちゃったら意味ないので。

カード類:
比較的よく使いそうなカード(ようはSuicaとか)はポケットに入れて持ち歩きたい。だけども、そういうカードはそう多くないので、これは輪ゴムで束ねて適当にポケットに入れることにした。輪ゴムはやはり取り回しが若干面倒臭いかも。Suicaなら束のまま置けばいいので楽だけども。

このスタイルで1週間ほど生活してみたが、案外と悪くない感じなので、しばらくこれで行きたいと思う。紙幣やカード類はどうにかなると思うが、どうしたって何らかの意味での小銭入れは必要だと思ったな。

さて、普段ポケットに入れられないカード類をどうするかということなのだが、これは今でも家に積み上がっていて、どうしたもんかと悩んでいる。封筒を買ってつっこもうかと思ったのだが、これもすぐ何が何やらわからなくなりそうだし……。「そんなにあれこれ使うの?」という指摘はごもっともなのだけど、私は趣味でロッククライミングのジムに行くわけですが、すくなくともジムごとの会員証が必要。で、今日はここに行く日だからこれを持って……とかやるのは案外煩雑だということがわかったのでした。
という話をしていたら、同僚が名刺バインダーにカードを入れるというライフハックを紹介していたので、これも試してみようかと思います。