読者です 読者をやめる 読者になる 読者になる

路上の自転車とマナーと嘘つきの人生

歩道を歩いていると、正面から自転車がやってくる。まあまあ人通りのある時間帯だ。とくに気にせず歩く。自転車も進んでくる。よけない。こちらもよけない。あわやぶつかる一秒前、こちらが躊躇して歩みを止める。自転車は少しだけ向きを変えてすれ違っていく。肩がかする。
歩道を歩いているときに、ふと道端の店が気になるのでよそ見をして立ち止まる。背中を何かがかすめていく。驚いて振り返ると、大きな大人が乗った自転車が颯爽と走り去っていく。
信号が青になったので、横断歩道を渡ろうとすると、横から自転車がやってくる。あちらが赤信号のはずだが、止まる気配がないので渡るのを躊躇する。自転車は颯爽と目の前を通り過ぎてゆく。

Tokyo 2102

路上での自転車の危険運転は歴史的な背景や資格が必要ないこと、自賠責保険の加入義務がないことなどもあり、現在日本の都市部で最も簡単に利用できる移動手段である。わたしの育った土地でも、自転車で移動しないと高校から進学の選択肢が極端に少なくなったものであった。しかしながら、自転車での事故が簡単に被害者の人生を木っ端微塵に破壊しうるというリスクが一般的に認知されているとはいいがたい。

自動車であれば、資格をとる年齢が18歳以上であること、自動車を購入する財力があること、自賠責保険の加入義務があることなど、歩道をでなければ事故には遭いにくいことなどから、加害者になってしまうリスク、加害者になっても何の責任もとれないリスクはまあまあ低かった。ここ数十年の警察の取り締まりと国交省の制度設計の努力の賜物といってもよいだろう。

残念だが、自転車が歩道を利用してよくなってからはそうではなくなった。自転車が歩道を通るようになってから状況は変わってしまった。歩行者は、自転車に注意するどころか怯えて歩かなければならなくなった。接触して骨折で済めばまだ運がよい方だ。そういう危険を犯すくらいなら、なるべく自転車を避けて歩くだろう。実際、ぶつかっては困るので避けて歩くようになった。

自転車にのっていると、歩行者の顔はなかなか見えない。車道は危険だし路駐が多いので歩道を進むことにする。多少スピードを出しても、歩行者は道を開けてくれる。これならぶつからずスピードを出してもよさそうだ。おっとあぶない。でもスピードを落とすとまた時間がかかるし、着くのが遅れてしまう。もうすこしスピードをだそう。

なんかすげえスピードを出してる自転車がいるぞ。かなわんなあ。なるべく端っこを歩いて距離をとろう。くわばらくわばら。

お、なんか道が空いてるぞ。まわりもよけてくれるし、マナーのいい人ばかりで助かるな。ありがとうございます。急ごう。あれ、赤信号だ。人もよけてくし、車もまだ動いてない、よし行ってまえ!行けた。セーフ。こんなもんかな〜次もこれでいけるっしょ。

この手合は、 自転車の運転による交通の危険を防止するための講習に関する規定の整備 なり、 取り締まり を強化してみたところで学ばないわけであるが。。。

Tokyo 1605

路上だけでなく、周囲の人達への脅威や恐怖に自覚的に配慮できるようになりたいものですね。

リアルタイムとバッチの違い

昨日、分散DB本読書会のあとに品川のラーメン屋でリアルタイムとは何ぞや〜みたいな話になった。自分の思いついたポエムをここに書いておこう。現場の問題とはあまり関係がない。

Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)という本によれば、DSMS (Data Steram Management System) とDBMS (Database Management System)の違いは、クエリを発行するデータ集合の性質にある。つまり、DBMSは今ある有限のデータに対して操作を行うための仕組みで、DSMSはこれからやってくる無限のデータに対して操作を行うための仕組みと定義されていた。このDSMSというやつは、古式ゆかしいストリーム処理システムのことで、まあいわゆるCEPとかの元になったものである。もうひとつ、DSMSではデータは永続的ではない。クエリが永続的なものであり、先に決まってなければならないというところくらいがポイントだろうか。

この違いがお分かりだろうか。昨今、何とかというシステムがストリーム処理だの、リアルタイムだとオンラインだの、挙句の果てにマイクロバッチとかミニバッチという言葉が出てきて、さらにはバッチなのにレイテンシが100ms以内だとかどうとか、紛らわしいにも程がある。

そういうわけで、データベースの世界でリアルタイムとかバッチに一番関係あると思われる話がこれだ。そもそもリアルタイムという言葉をデータベースに持ち込むこと自体が間違っていて、本来データベースの世界にそういう言葉はない。バッチという言葉はたまに出てくるけど、テクニカルタームとしてではないと思う。あったら文献おしえてください。

そこさえ抑えた上で個別のシステムの主張と仕組みを理解していけば、混乱することはないだろう。

もうひとつのリアルタイムとしては、クラシックなリアルタイムOSの文脈がある。これは、ある処理に対して一定時間内に必ず結果を返すというものだ。上記の通り、この定義が頭にある人ほどデータ処理の世界にその言葉を適用しようとして混乱するだろう。だけど、ノリでみんな「自分たちのビジネスで影響がない程度のレイテンシで結果が返ってくる」という意味で言ってるだけで、コンピュータサイエンスの文脈には全く関係ないので混同しないように。

Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)

Stream Data Processing: A Quality of Service Perspective (Advances in Database Systems)

余談だがDSMSの「ストリームに対してクエリをかける」というのは、Pushされてくるデータに対してPassiveにプログラムを実行するという意味で昨今のリアクティブプログラミングに似ていると思うのだが、私のリアクティブプログラミングの理解は合ってるだろうか。

Vガンダムを(やっと)観た

さて宇宙世紀シリーズはほとんど観たしなあ…楽園追放面白かったけど、バンダイチャンネルで観たアルドノア・ゼロはイマイチだったなあとか考えていたところで、次は何にするかなあとボンヤリとバンダイチャンネルをウロウロしていたところ、うっかり間違えて月額課金してしまったのが4月の中頃のことであった。せっかくだから2週間あるし退会するまえに何か見ておこうと考えていたところ、昔どこかのスレで「話が進むにつれて、カテジナさんがどんどん変わり果てていくところのが見どころ」という評価をみかけて興味が湧いていたVガンダムをみることにした。せっかくだし連休の暇つぶしにもなったのだが、全部で51話もあったので結局一ヶ月かかってしまった。

www.v-gundam.net

初期のダラダラと観ている間にちょっと調べたときの富野翁の自作品の評価が面白くて余計に興味が湧いてしまった。

何がダメなのか探してください。
この作品は全否定したいと思っているものです。このような結果になったのは、全て監督の責任です。何かの間違いでこのBlu-rayで見た方は『機動戦士Vガンダム』の何がダメなのかを探してみてください。そこから気付ける人がひとりでもいらっしゃればBlu-rayとして出した意味があると思っています。

さて本編は…宇宙世紀でいうと130年とかそのあたり、UCから40年ほどあとのこと。ウッソ・エヴィンは地球の不法居住者で、カサレリアという森の奥深いところで平和に暮らしていた。しかしある日クロノクル・アシャーが新しいモビルスーツのテストでカサレリアにやってきた。パラグライダーで遊んでいたウッソがうっかりモビルスーツに引っかかって奪取してしまうところから話は始まる。そのしばらく前に、ザンスカール帝国はカサレリア近くの街ウーイックに反乱分子が潜んでいるとの情報をもとに、町ごと殲滅してしまい、…

とまあ、ガンダムでいうところの子供が初めてモビルスーツにうっかり乗ってしまい最強のパイロットになる、わりかし悪い国家なりがいて攻めてくる、戦いたくないんだけど仲間を守りたいが一心で敵を倒しまくってしまう、でもやっぱり戦いたくないという…まあよくある大人と子供の間の年齢の機微を沢山描こうとしたある種の宇宙世紀の王道作品である。カテジナさんは、ファーストガンダムでいうところのセイラさん的なポジションなんだけども、クロノクルに捕まって以来なにやら雲行きがおかしくなって、話が進むに連れてその内心の狂気が明らかになっていく…。

と盛り上げて書いてみたものの、ZZ的なご都合主義も沢山登場していて果たしてこれでいいのんか、とか、終盤になると登場人物を無駄に特攻させて片付けたり、とかく51話4クールも続けるのは大変だったのだろうと思う。退屈になりながらもわりと頑張ってみれたのは、他に趣味がなかったからだと思う。特に凹むのは、シュラク隊のメンバーを始めレギュラー脇役を容赦なく死なせていくところ。最終話で何人片付いたことか…

個人的にどの話が好きかといえば、振り返ってみて「鮮烈!シュラク隊」だろうか。その後の悲劇をひとつも連想させない明るくカッコイイ登場はこのストーリーで一番ポジティブで盛り上がって、かっこいいところだと思う。ま、Blurayは買わないかな…。とりま、いっこくらいHGUC組んでみようと思う。

HGUC 1/144 LM314V21 V2ガンダム (機動戦士Vガンダム)

今更ストレージサーバーをFreeBSDとZFSで組んだ話

家にTimeCapsuleが2台あって、Mac miniも一部ストレージサーバーになっていて、デスクトップマシンにDVDを保存していて、しかも写真はS3にバックアップしてたんだけど、そろそろMac miniが一杯になってきて…という、まあいろいろ限界に近づいていたので我が家のストレージ用に一台新調した。

買ったもの

@Dospara 注文番号:xxxxx
------------------------------------------------------------------------
◎出荷された商品
TOSHIBA DT01ACA200 バルク[2TB]      [ 2個 ]
SanDisk SanDisk Ultra?SDSSDHII-120G-... [ 1個 ]
Intel Core i5 4590S BOX          [ 1個 ]
ASUS H97-PRO               [ 1個 ]
ADATA AX3U1600W4G11-DD (DDR3 PC3-1280... [ 2個 ]

とりあえずこれだけ買って、ふつうに組んだ。ハコは10年近く使っているものがあるので、それを流用。電源だけは先代のものを流用できたけど、Phenom X2とかAGPのグラフィックボードとかいろいろ古かったので、そのあたりはバッサリとさようなら。既存の SATA HDDが 250GB, 500GB, 500GB とあったので、そいつを利用してうまいことZFSなら…ZFSならやってくれるさ…!と思っていた。

SSDは単品でブートパーティションに。SSD内部で冗長化機構をいくつも持っているし、機械部品がないから故障率は少ないはずだ。ハズレを引かなければメモリやマザボと同等の寿命になるはず。仮にSSDが吹っ飛んでもまた買ってきて入れなおせばそれでよいのでOK。ストレージにするといっても常時起動ではなくむしろコールドストレージ(ほとんどオフにしておいて、必要なときだけ火を入れる)として運用するので可用性の要件もそんなに高くない。

memtest86

とりあえずこれ。MacBookUSBメモリに焼いて動かせるのはこれ(公式のやつだとうまく焼けなかった)。

To burn USB stick in Mac: http://www.memtest86.com
Technical instructions: http://www.memtest86.com/technical.htm

まあそんなに頑張っても仕方がないので、2時間ほどまわして納得。

FreeBSD 10.1

いい時代になった。CD-ROMなんか焼かなくても、USBメモリがあればカンタン。16GBとか、そんなにいらねーっていう。ミラーサイトを選択してMacで焼けるように FreeBSD-10.1-RELEASE-amd64-memstick.img.xz をダウンロード。

$ sudo dd if=FreeBSD-10.1-RELEASE-amd64-memstick.img of=/dev/disk3 bs=10m

diskutil list を活用してちゃんとUSBメモリを特定する。これでUSBメモリから起動する。

FreeBSDのインストールは簡単。zrootも簡単だった。rc.confをちょっといじるだけ。IPアドレスも固定。特殊なドライバも入れない。カーネルは一応GENERICでビルドしなおしたけど、これでCPUの最近の命令とか使えてるのかな。まあどちらでもよい。しかしここからが大変だった。

ZFSに慣れる

同僚がものすごいZFS推し(Solaris推しでもある)なので、ZFSを使うことは決めていた。しかし中途半端なHDDが3枚。2TBが2枚。なんとかローコスト運用して、HDDが壊れる度に大きいサイズのもので置き換えて徐々に拡大していきたい…
とりあえず何も考えずにいきなり zpool create しちゃうと、GPTパーティションがないやつもそのまま上書きでグダっとなってしまう。そいで corrupt とかいわれるので、予め

# gpart show
...
# gpart create -s gpt ada4
# gpart add -t freebsd-zfs -a 4k  ada4

としておく。こうすると /dev/ada4p1 ができるので、基本的にはこいつを使う。こんな感じ

# zpool create tank mirror ada1p1 ada2p1 ada3p1 mirror ada4p1 ada5p1
# zpool status tank
 ... tank の構成と状態がきれいに表示される

記憶が定かでないが、たしかこういう構成にしたと思う。ada1 ~ ada3 までが不揃いのHDDたちだ。これだけで自動的に /tank にマウントまでされてしまう。便利。LinuxVFSでウダウダ頑張っていたのがウソのようだ。

ストレージプールをバラしたいときは zpool destroy tank で一発だ。ウッカリやってしまわないように気をつけよう。

障害時の対処はこのあたりを参考にするとよいだろう。

これはメモにあったのだけど…パーティション作成の方法かな。gpartがたまに拗ねるときがある気がするんだ。

障害対応、いきなりの実践

しばらくそれでZFSで作ったり壊したりして遊んでいた。で、そろそろデータを全部移すか…ってなって、ひととおりコピーし終えた頃にやりやがった。 ada2 故障。autodetachされていた。ZFSは優秀である。とりあえず電源落としておいて、もうなんか500GBのやつをもう一度買っても切ないので秋葉原でWDのGreenを2TB 追加購入。ドスパラで買うと3年くらいの保証が無条件でついてくるのでお得だ!これが秋葉原での某DB飲み会の日だったので、4月10日だな。忘れないようにしよ。

いざ土曜日(だったっけ?)、古いHDDを何も考えずに挿して zpool add ada1p1 ada2p1 しちゃうと、セクタサイズが512Bのままになっていて…だかなんだかで zpool status の結果に "block size: 512B configured, 4096B native" と出てくる。どういうことだ。resilver は自動で動作している…が、きになる。ということでいろいろ調べる。

古いHDDはセクタサイズが512Bなのだけど、一方で最近のHDDはセクタサイズが4Kになっている。これをmirrorしちゃうと…セクタサイズが512Bのmirrorになっちゃう!スレの内容をまとめると、まあコイツが出てしまうともう戻らないってこった。新しいプールを作って import/export でやり過ごすくらいしか手はない。zpool 全体でどうなってるかは zdb -C | grep ashift でわかる。 9なら512B, 12なら4096B の模様。

僕はまだ新品のHDDもあるし、データはまあMac miniとかに散らばっているものをまた持ってくればよいので、バッサリと zpool destroy した(その前に一旦一枚ザラの単品パーティションにコピーした*1 )。いい機会なので、2TBのHDDを4本使ってふつうにサイズを揃えて運用することにした。

# zpool create data mirror ada1p1 ada2p1 mirror ada3p1 ada4p1

これだけ。RAIDZにしなかったのは特に理由はないが、仕事でErasure Codingに手を付けられていないので、いくらみんなが安定運用しているといってもちょっと怖かったのだろう。いや理由を思い出した。最初に4本スタートしてしまうと、構成をあとで変えられないからだ。

豆知識: GPT table is corrupt と /var/log/messages で言われたとき

# gpart recover <geom> 

http://yomemacs.hatenablog.jp/entry/2014/02/04/205509

TimeMachineバックアップに使う

netatalk3を入れよう

$ sudo pkg install netatalk3

参考

これでふつうにMacOSからも見れるようになるので、TimeMachine用、DVD鑑賞用、写真バックアップ用のパーティションを afp で見えるようにする。Go To Server...とかで afp://192.168.1.42:5128 とか適当にやっておけばOK

ログの監視

よく考えたらコールドストレージだから死活監視もクソもないのだが、起動時にあえてやるとしたら、いい方法がなかった(NewRelicとかそういうカッコイイのは大げさすぎる)ので、はやりのMQTTというやつを使ってみた。

$ tail -F /var/log/messages | mosquitto_pub -h lite.mqtt.shiguredo.jp -p 1883 -t "<name>/kushana/var/log/messages" -u <name> -P <passwd>  -r -l

としておけば、適当にどこからでも見れる。

$  mosquitto_sub -h lite.mqtt.shiguredo.jp -p 1883 -t <name>/# -u <name> -P <passwd>

まあ必要ないのだけどね。

電源を落とす

$ sudo shutdown -p now

電源管理機構があるとこれで動く。Linuxだと -h で電源落としてくれるのだけど、FreeBSDだと古式ゆかしい halt なので、電源ついたままシステムが止まる(コンソールがないので、停止シーケンスがいつ終わったか分からない…)。

TODO

やりたいこと

  • DVDをストリームするサーバーを立ち上げる
  • pipが動かない
  • Erlang/OTP 17.5 が --disable-hipe でコンパイルできない
  • 妻のTimeMachineをホスト

やらないこと

  • Wake on LAN: 手でボタン押したらええやん
  • TimeCapsuleの廃止: 複製はあればあるほどよいのだよ!

最後にもう一枚。よいショットだったのでどっちを使うか迷った。

*1:このときの cp -r が、ファイル名の辞書順ではない何かよくわからない順番でファイルをコピーしていたのだが、どうしてだろう? /usr/src/bin/cp のコードは3分で飽きてしまった

QConTokyo 2015 で喋ってきました

QCon Tokyo 2015 Conference|QCon 東京 2015 カンファレンス

QConTokyo 2015で、データベースアーキテクチャーの動向と使い分けというお題で発表する機会があった。Bashoは2014年2015年にかけてQConのグローバルなゴールドスポンサーをやらせてもらっていて、ロンドン、サンフランシスコでも社員が喋った。東京は…英語以外の言語での開催はここだけなので、で、日本語でQConぽい話ができる…ということで僕が喋ってきました。

speakerdeck.com

有料イベントで話すのは初めてなので、果たして対価に見合う話を聴衆にできるのか全く自信はなかった。裏番組はGoogleの中の人が話すGolangセッションだから、そもそも人が来ないかもしれない。と思ったら一番広いホールじゃねえか。しかも、いつもはデータベースとかインフラ系の技術に興味持って集まる人が対象だけど、今回は幅広い層の聴衆が来ているはずで、実際スーツの人が多くて…といつもとは違う感じだった。

特に聴衆の関心が読めなかったので、データベースの細かい技術の話やバズワード、マーケティング的ポジショントークなんかをなるべく入れないことを前提に話を練ったのでわりと苦労した。ここまでちゃんと準備してスライドを考えたのは初めてかもしれない。話の筋を考えることに集中したので、結果的にスライドにほとんど絵を入れられなくて文字ばかりになってしまったので、当日はちょっと退屈そうな人もチラホラいた。非常に申し訳なかった。ぼくも文字ばかりのスライド、本当は嫌いだ。

ぼくがあの話をしたその翌日にHacker Newsで Call Me Maybe: MongoDB Stale Reads | Hacker News のスレが盛り上がっていた。このはなしは大分昔にKyle KingsburyがちょっとTwitterで書いていたのでなんとなく知っていたが、果たしてどうなることやら…w 偶然だけど、日本ではLAMPスタックに加えて解析基盤と非同期実行のMQが入り始めたくらいで、システム自体の複雑化や大規模化がそこまで進んでないようにみえる。だからまだ問題になり始めていないのだけど、ネットワークは信頼できると思ったら大間違いなわけで、そういった認識が日本でも広まればいいなと思って書いた。データベースの技術はそのネットワークに依存しているわけで、そこはさすがに同意していただけるかなと思う。でもまあ、当たらぬも八卦、当たらぬも八卦ということで今後の成り行きを見守っていきましょう。

QCon当日はいろんな人と話したり、いろんな話を聴くことができて、世の中にはデータベースだけじゃないんだなあと改めて当たり前のことを確認したのであった。しかしテクノロジーカンファレンスなのだから、会場のWiFiはもうちょっとなんとかできると思うぞ。カンファレンスネットワーク、わりと技術的には難易度高いけどホラ、今は日本にもCONBUとかあるから。

「技術」という言葉について

とくにソフトウェアとかインターネット的な世界のはなし。典型的な用法は「〜〜という新しい技術を仕事で使いたいのだけど、上司が許可してくれない」というものだ。この〜〜には、たとえばちょっと前だとLAMP, Ruby on RailsとかAWSとかHadoopだし、今だとなんだろう、DockerとかC#かな。うーんこの違和感。私の定義では、これはどれも技術ではない。ただのソフトウェアだ。AWSはサービスだ。

TCP/IPSIPは技術だろうか?わたしの感覚ではノーだ。ただの仕様だ。いずれもベースになっている技術はあって、たとえばパケットのルーティングや名前解決、フレーム再送やウィンドウ制御の仕組みや実装は技術といっていいだろう。Hadoopは分散処理の技術を実装したソフトウェアだ。LAMPWebサービスを実装するためのソフトウェアスタックの総称で、そのなかに様々な要素技術はあるだろう。Dockerの中で使われいているAufsや依存性管理の仕組み、名前空間などを使ってインスタンスを分離する仕組み自体は技術だが、「Dockerという技術を習得する」という日本語は間違っている。

もうちょっと展開してみよう。Git引いてはGithubソースコード管理などのツールとして導入したときに、「Githubという技術を導入した」とは言わない。「Gitという技術を導入した」これもおかしい。「レポジトリを分散して管理できる技術を実装したGitというソフトウェアを使って、分散レポジトリを活かした開発フローを導入した」これくらい言わないと技術という言葉は使えない。課題を解決する体系立てられたワザを技術というのであって、ソフトウェアやサービスそのものを技術とはいわない。

わたしの感覚だと、片仮名でテクニックといわれる種類のものの方が技術と呼びやすい。たとえば探索系の問題があったときに単に深さ優先にするのではなくて、DPで実装する。数値計算ならdoubleとfloatで使い分けるコツが違うし、できればSIMD使いたいけどちゃんと実装するのは難しい…(SIMDをちゃんと実装した数値計算のライブラリがあったとして、それは単にライブラリであって技術とは呼ばない)。たとえばMySQLのbinlogレプリケーションはSplit brainが起きるけどSQL ServerならPaxosを使っているのでそれが起きない、とかそういうの。

よく「○○を支える技術」といって、その会社なりサービスを支えるソフトウェアスタックや、その運用を紹介する本が出版されよく買われるようだ。その本は、単に採用されているソフトウェアなりサービスのリストが書かれているわけではない。大抵はそこにある課題と、それを解決する方法が書かれていて、その方法のひとつの実装としてソフトウェアなりサービスの名前が載っているわけである。

もうちょっと違う説明の仕方にしようか。たとえば自分たちのECサイトにリアルタイム推薦を導入したい。そのときにリアルタイムレコメンドができるJubatusを導入するとしよう。Jubatusは新しい技術か?わたしの定義ではそうじゃない。Jubatusはソフトウェアだ。そこに実装されているLSHや、それを複数ノード間で同期する仕組みは技術だ。別にJubatusじゃなくてもSolrでもなんでもよい。Solrそのものはソフトウェアだ。その中で実装されているTokenizerや転置インデックス、インデックス更新の仕組み(詳しく知らない)は技術だ。やりたいことを実現する手段なり工夫なりを技術というのであって、ソフトウェアやプロトコルのことを技術とは呼ばない。

これが私の定義なのだが、Wikipediaなどを見ると「そもそも多様である」的なことが書いてあるの。インターネットでちょっと私の定義の合わない用法があったとしてもまあ言葉狩りだと思われたくもないので、まあ喧しく言わないようにしてここに書いて忘れることにする。

ちなみに、件の上司は、「○○という(仕事の)課題は、△△という技術で解決できるのですが、それを実装したものは〜〜というソフトウェアしかないので、〜〜を使うしかないです」といえば説得できると思う。それであなたが使いたいものは何でも仕事で使えるようになるよ。

キッチンライフを少しだけ楽しくする課金アイテムKitchen Aid

我が家では家事を楽にするための設備投資は推奨されている。最新の課金アイテムはキッチンエイドのスタンドミキサーというやつだ。これの便利さは折り紙つきで、なにせ手を汚さずにいろんなものを混ぜることができる。海外の料理番組では「キッチンエイドの目盛り4で5分間混ぜる」といった風にレシピが記述されているらしい。アタッチメントをいろいろとつけかえることで、様々な混ぜ具合や材料に対応している。テクノロジーは人間を楽にするだけでなく、作業を定量化することにも貢献しているのだ。ハンバーグをこねる、餃子のタネをこねる、クッキーやケーキのもとを作るといった用途で広く知られているこの道具だが、今回はちょっと変わった用途に使ってみた。

今回の材料は納豆である。納豆の既製品を買ってくるまでは異論の余地はないだろうが、その食べ方にはさまざまな議論がある。そこにかけるものの多様さは生卵、刻んだ葱、醤油、等々。中でも混ぜ方は大きな問題で、

すこし検索すればわかるが、いくつか流派があるようである。わたしの理解だと、およそ5〜10分ほど箸で力を入れて混ぜるのが泡立ちと粘りのバランスがとれていて丁度よさそうだ。一方で妻はあの泡が苦手で、ほとんど混ぜないのが好みなのだそうだが…今回問題にしたいのは、ちょうどよい混ぜ具合になるまでのあの手間である。腕が疲れる。指が疲れる。白飯が冷める。飽きる。もうやだ。でも粘りのある納豆を食べたい。ということでキッチンエイドで納豆を混ぜた。その様子を撮影したのでご覧いただきたい。


Mixing Natto with Kitchen Aid - YouTube

これは、KSM5という機種のスタンドミキサーで6〜7分、目盛り2〜3にして混ぜたときのものである。納豆は一般的な3パック組のものを一度に3パック投入した。粒はいささか大きいが、小粒のものにしておけばより潰れにくいだろう。人間が混ぜるよりもはるかに高速で強力な様子がわかるだろうか。

そうして混ぜたものの結果がこれだ*1

今回は実験的な意味もこめて少し長めに混ぜた。おそらく混ぜ時間は4〜5分が最適ではないかと思う。長く混ぜてしまうと、粘りが落ちてきて粒が潰れてしまうためだ。しかし写真の品は泡がよく肥大し、米粒とよく合わさって味は非常によかった。粘りが苦手という人はキッチンエイドを使って長めに混ぜてみると、手で混ぜたのでは得られない食感が得られてよいかもしれない。

*1:カラシが垂れているのは付属品のご愛嬌ということで勘弁