2016年になりました

101ND610-DSC_0841

写真は、四谷の坂本 (tabelog) で買ったお節料理。とてもうまい。ついに2016年になった。

2015年を振り返る

2015年を振り返ろうとしたら、先日書いた記事に実際ほとんどまとまってしまっていて、特にまとめることもなさそうだった。昨年は対外発表とか勉強会とかそういうのをほとんどやっていない... と思ってSpeakerDeckを見返すといくつかやってた。

外向きに話すのをかなり減らしたのは子供が2月に生まれたこともあったんだけど、アウトプットしてるヒマがなくてひたすらインプットしていた一年だったからだ。

もう2年近く?続いているふたつの読書会に参加していて、ひとつは分散合意本読書会。こちらは、いわゆる同期本が1月に終了していて、非同期本に突入していた。それで、ようやくブロードキャストの基礎理論をやっと一年かけて前準備できたところ。次からやっと非同期世界の合意問題に入る。前準備だけで本一冊半、しかもずっと記号と証明の世界なので内容を理解していると自信持っていえるわけじゃないけど、驚かないくらいにはなれた。おかげでちょっとした分散プロトコルの証明くらいなら読めるようになったと自負している。

もうひとつの読書会は、いわゆる分散DB本というやつ。これがなんとか昨年内に全部読み終えることができて、なんというか、頑張ったなあという感じであります。はあ…。

どちらの本も、それぞれ別の理由で正直おすすめできるものではないのだが、やっぱり英語の本を何冊も読破できるようになって、しかもProofreadする方法を改めて確認できているので、これはなんというか大きな達成だなあというところである。まあ2年かけてやっと2.5冊読んだが、その間に洋書や論文の積読はもっと沢山たまっているわけで非常に悩むべきことである。

で、その次は分散処理本が読書会のキューにたまっている状況。こちらは基礎理論を広く押さえた(合意本は狭く深く…深すぎる)よい本だと思う。

個人的には、まあ詳しくは書かないがいろいろあった。一昨年に息子が幼稚園を一度やめた(僕が園長と喧嘩をした)のだが、近所の幼稚園にまた通いだして元気になった。よかった。たとえモンスターペアレントと呼ばれようとも、素人の教育論であったとしても、まあ許せないことは許せない。まさか子供の顔を見ない教育をする連中がいるなんて思いもよらなかったのだがまあいたんだ。

近所のジムに入会して筋肉トレーニングを再開した。学生時代にちょっとやって以来10年ぶりというレベルだが、なんとか体重と体脂肪率の目標 70kg / 20% を、たとえ一瞬にしろ風邪で食が細ったことが原因にしろ達成できたことはすばらしい。よく頑張った俺。おかげでベースになる代謝が増えて体温がちょっと上がって健康度が高まった。まだ30代なので、散歩とかヌルいこと言わずになるべく自分の肉体を追い込んでいきたい。スクワットも次男が生まれてから少しだけやっている。

Wii Uを買ってスプラトゥーンを始めた。非常にまずい。よくないことだ。あと年末は家族で沖縄に行ってきた。ハイシーズンだし別に泳げるわけではないのだけど、日差しも柔らかで気候も暖かい(晴れているわけではない)ので過ごしやすくてよかった。また行きたい。

101ND610-DSC_0460

D610を買ったのは先日のPyspa活動まとめでも書いたが、D610のカウンターは 101ND610/DSC_840 だった。つまり買ってから 10840回 シャッターを切ったことになる。実際残ってる写真や動画はもっと少ないと思うが大した量だ。容量はRAWも合わせて170GBに達した。今全力でS3にバックアップを流しているが、それでも一日で終わりそうなのだからインターネットはすごい。 2MB/s くらいだが、同時にスプラトゥーンもちゃんとできているので、スループット重視の通信とレイテンシ重視の通信を同時にできてるのだからやっぱりインターネットはすごい。

2016年の目標

参考

こういうの西暦で偶数年に書くことにした…わけじゃなくて、億劫でたまたま奇数年はやってなかったっぽい。

msgpack-erlang 0.4.0 to 0.3.5 をリリースしました

2015-11-11 15.27.37

これはErlang Advent Calendar 2015 - Qiitaの11日目の記事だ。本日、 OTPの17と18のみに対応して古いOTPで動かなくしてコードがシンプルになった 0.4.0と、R16以前でも動く0.3.5をリリースした。 0.4.0 は別に新しい機能があるとかそういうわけじゃないのだけど、ついに maps がデフォルトになったとかあのよく分からない nil がなくなったとか、 Erlang の QuickCheck でバッチリテストされようとしているくらいだろうか(ちょっと頑張ったけど、結局うまく動いてない…)。

わたしの近況

Bashoという会社で働いていて、 Riak CS という製品の開発リーダー的なことをやりつつ、新製品Machiの開発もやっている。ほぼ毎日ひたすらコードを書いたり設計したり議論したり、ちょっとだけテストしたり、という感じ。でもわりとアーランのアプリを書いてばかりなので、OTPとかBEAMに深入りしなくてもやることは沢山あって仕事には困ってない…ので、OTPの知識が増えない…

MsgPackとmsgpack-erlang の近況

msgpack/msgpackのレポジトリでは「生きてる?」みたいなコメントされたりしてネット上では存在感が薄くなってきたが、 Basho に入って3年あまりついにBasho製品に MessagePack と msgpack-erlang の実装が入ってしまった。具体的には、 Riak TS という、先日若干界隈を賑わせた製品の下回りでデータのシリアライザとして利用されている。具体的には、 Riak にスキーマ的なのをつけられるようになって、それがMsgPackでシリアライズされてLevelDBに入るようになった。カラムナなデータ構造になったわけではないが、クエリの一部をLevelDBの直前のC++のところまでプッシュダウンすることで効率化されている。まあもともとLevelDBにはsnappy圧縮が入ってるんでMsgPackの小ささ自体がそこまで貢献してるわけじゃないけど、まあJSONよりはマシかあ、PBもスキーマいるし大変だよねえといったところだ。入社前に書いたコードがついに仕事で役立っている模様(なにせ私は直接関わっていないどころか知らないところでほとんど話が進んでいた)。

ちなみにNIF版の開発は全然やってない。メモリアロケータまわりまで含めてちゃんとやるのめんどくさそうなんやもん…

msgpack-erlangErlang QuickCheck テストを追加

QuickCheckはすばらしい。 msgpack-erlang を rebar3 化するにあたってあまりノウハウがなかったのだが、そこは想定外だがプラグインがあったので大した苦労もなく導入できた。書いたコードは本当に一部だけだった。特になにもしなくて

$ ./rebar3 eqc

だけでビルドとテストができるようになっている。

あなたも無料でQuickCheckが使える

もうほとんど忘れられているが、 msgpack-erlanghttp://quickcheck-ci.com でテストされている。URIはないのだが(マジかよって感じですね)、msgpack-erlang でサイトを検索してもらうと見つかるはずだ。未だに 17.1 だったり、メモリ使いすぎるとすぐ死ぬ(ので肝心のShrinkはあまり使えない)とかまあQuviqがあんまりやる気ないことは百も承知だが、ないよりはマシだ。マシだと思いたい。

頭が痛い問題

Arrays with numbers and {enable_str, true} · Issue #51 · msgpack/msgpack-erlang · GitHubがわりと面倒くさい。気持ちはわかる。Printableな文字列をそのままシリアライザにツッコミたいよね。そらそうだ。Functionを指定させるってのがいいのかなあという気になりつつはあるけど、文字列かどうかを判定させるオーバーヘッドがパフォーマンスにどれくらい効いてくるのか未知数ではある。

iolist() にしてみたい

いまのところシリアライザもデシリアライザも binary() しか使えないし吐かないようになっているが、これを iolist() にしたらどうなるかなというのはちょっと気になっている。もちろん iolist_to_binary() を間に挟むだけだと意味がなくてプログラミングは割と面倒くさいというか、どの粒度でバイナリを切ってリストにするとメモリアロケータを使う頻度を最小化できるかという問題になると思う。まずは erts_alloc をおべんきょするところから始めるべきだと思うんだけど、アロケータ周りをいじるとシステム全体に影響がありそうなのが気になる。という問いを空中に投げてこの記事を締めたい。

写真で振り返る2015年のpyspa活動まとめ

100ND610-DSC_3947
本年お気に入りの一枚。

これはPyspa 2015アドベントカレンダーの記事だ。今年もどうやらPython温泉が開催されたようだが、わたし自身にはわたしのブログの一年間の記事を見通しても特に何もなかった。せいぜいが開発しているソフトウェアの最新版が1.5から2.1になるまで頑張っていくつかのリリースサイクルをまわして必死でコードを書いていたくらいだ。うそです。いくつかニュースはあります。写真で振り返っていこう。

モリヨシ堂開闢

100D3300-DSC_2870

たまに参拝します。

勝手に奥田会を開催

100D3300-DSC_2962

仕事でシアトルに行く機会があった挙句会場が奥田さんの勤務先の目と鼻の先だったので、シアトルを案内してもらいました。

やっとフルサイズ機に移行沼へ

100D3300-DSC_3126

ミラーレスやAPS-C機を持ってはいたものの、やはりアマチュアでできる最高のクオリティがほしいと思って入門の定番機D610を新品のレンズキットで、とりあえず25-85mm/f3.5-4.5で購入。次のレンズはpyspaカメラ組がこぞって薦める35mm/f1.8の純正レンズで。これが第一歩となり、ニッコール70-200mm/f2.8とカールツァイスのPlanar 50mm/f1.4を買っていてとりあえずは満足している。12月までの10ヶ月で写真の連番4桁が一周して101になった。やはり、沼の中の方が圧倒的に早い。

次男誕生

100ND610-DSC_1142

彼のために、pyspa活動を専ら勤務中の平日昼間に限るようにしている。ひとりとふたりでは、手間は2倍程度で済むって思うでしょ?ちがうんだなこれが。

いくつかコンピューターの勉強をしたり

国立科学博物館に行ったり、大宮の鉄道博物館で撮れたMARS1はとてもインパクトがあった。息子が長くは見せてくれなかったのだが…

100ND610-DSC_6817

夏には家族で銀座に旅行したりもした。これはその中でもお気に入りの一枚で、まあそんなに上手く撮れているわけじゃないんだけど。

しうまちが華麗な転身

100ND610-DSC_9244

これまでは色白で生真面目なサポート職人とかポストセールスのエンジニアといった面持ちだったのに、すっかり脂ぎった色黒の外資系営業マンになってしまった。奥田さん以外の人はみんな変わっていく。嗚呼。このとき、西尾やところてん、ボランタスもいたんだけど。みんな5年前とはすっかり変わってしまった。

わたしが華麗な転身(写真なし)

今年初めに目標設定した、体脂肪率20%以下、体重70kg以下という減量目標をつい昨日達成してしまった。一年書けて4-5%と3-4kg程度を落とした。これは筋肉を渇望したからではなく、返ってこない生命保険や健康保険などの保険料よりも効率のよい投資を求めた結果だ。よほどの肥満でもない限りよくわからない民間療法や薬品に頼るのではなく、自分の身体を鍛えるのが一番よい。特に筋肉を増やすのがよい。

とにかくこれでやっと一息ついた計算だが、わたしには次の目標がある。もともと、基本的にはジムでいろんな種目(水泳、マシントレーニング、フリーウェイト、等々)を試してみて気に入ったやつを始めるという作戦だった。…一番楽しかったのはフリーウェイトだ。「地面から重いものを持ち上げるほど楽しいことはない」という言葉の通り、自重を制御できるようにするのが次の目標だ。おもにフリーウェイトや懸垂などで達成を目指すことにしている。

今後の展望

考えてみれば、今年はpyspaらしい活動をほとんどしていない。pyspaのいいところは年々意識が低まっていくところだ。いつまでも若いつもりで勉強会やりまくったりしてないのがよい。それでいてチャットでは常に各方面のエキスパートが集まっていて技術的な話題や知識に事欠くことがない。意識が低まるのとは逆にボランタスが口にする金額の桁は年々増えてるし、若いメンバーも新たに増えるし、メンバーの可処分所得も増えている。

私自身はたまに集りに参加はしたが温泉も行かなかった。プンコレ忘年会が久しぶりの活動になる。別に何もしないで大菅くんともりよしをおとなしくじーっと見ていようと思う。もしくは、スターウォーズのDVD6作分を手に入れたから、一人でそれでも観てようかな。

来年のpyspa活動は…うーん、懸垂できるようになって、またレンズ買って、どこかいいものでも撮ってがんばろう。

次世代ウェブカンファレンス #nextwebconf に参加できませんでしたのでお詫びします

去る10月18日に行われた次世代ウェブカンファレンスは、わたしもサーバーアーキテクチャーというセッションにスピーカーとして呼ばれていた。わたしも話す気満々だったが、当日の朝になって次男が発熱してしまい家庭の予定を変更して妻は次男、わたしは長男を連れて彼の予定をこなすことにした。ので泣く泣く当日朝に参加を断った。当日は盛況だったようで何よりである。

100ND610-DSC_2702

当日はスタッフが充実していて、ストリーミングや録画も行われた。わたしが出るはずだった server_arch セッションの動画も公開されている。ここでは、当日言おうと思っていたことと、この動画を見て言いたいことをここに書いて当日参加できなかった詫びとしたい。すまんかった。

ウェブ is 何 / 次世代 is 何

CERN発祥のHTTP/HTMLで情報伝達する仕組み(昔WWWとか言われていたもの)が普及しきって、あらゆる情報がインターネットを介して繋がる今、ウェブはもう世間のITシステムそのものになってしまったと思う。ので、まあウェブという言葉に意味はなくてコンピューターシステム、くらいなものだと考えるのがよろしい。じゃあ次世代のコンピューターシステムとはなんぞやというと、まあムズカシイというか、Googleとアマゾンの中にある未公開のものがいちおう最先端といわれている。まだ論文になっていない技術や、公開されていないソフトウェアがおそらく沢山あって…というのは期待しすぎかな? じゃあなぜこういうものが大学から出ないかというと、もうデータも設備もないから。コンピューター技術が脳内の思考実験とすこしのコンピューターで発展する時代は終わっていて、21世紀になってからは完全に設備産業になってしまった。設備を持っていないところは次世代なぞ作り出せない。全てはクラウドになるのだ。

…っていうのがビジネス的な考えで、まだ諦めるには早い。全てがクラウドに載ってしまえば、他のセッションのようにプロトコルやデザイン表現の問題が議論の中心になりやすいだろうが、本当にそれでよいのか? みんなオープンソース大好きなんじゃないの? AWSGCPも肝心のところは一切公開していなくて、それが非常に優れているのは認めるけれども、中身が分からないものを使い続けるのにオープンソース大好きとかいってたら、私が呪いをかけておいてさしあげよう*1。その手のプロプライエタリクラウドは、実装が公開されていないことはともかく、仕組みが分からないことが問題で、謎テクノロジーを使ったサービスはAWSGCPから山のように出ているわけだ。みんなそれでいいの?って思う。その上で自分の大事なビジネスを動かすのは短期的にはいいしビジネス的には正しい判断だと思うけど、技術者としてはそれは許せないよね?

かくいう私は iPhone も持っているし、この記事もMacで書いているが、まあOSそのものはもうコモディティ化してしまっているので別に何でもよいのである。最近はSurfaceに興味がある。

まあつまり次世代がどうとか以前に、いまは多くの人がブラックボックスの上に立っているわけでそれはどうなのとまず言いたい。それが分からないことには次世代もクソもないし前に進めない。それを無視できないのを忸怩たる思いで見てきた(中の人になるというのは選択肢としてなくはない)。

サーバーアーキテクチャー is 何

歴史的には、クラサバがあって、LB-AP-DBの三層とLAMPみたいな流れがあったのだけど、今はそれが多様化していてMQなりHadoopなりが裏側で動いているし、データベースもRDBMSだけじゃなくていろんなもの(いわゆるNoSQLと十把一絡にされているやつ)が登場している。コイツラをどう使い分けてサービスを構築するか、みたいなのがひとつの課題。

もうひとつは、そういうサービスの構成要素は「サーバー」ではなく、そういったひとつの役割を持ったサーバー群(クラスタとか言ったりする)が提供する機能(レプリケーションしたMQとかDBとか、もしくはLBの下でスケールアウトするAPとか、etc)をどう組み合わせてサービスを構築する時代になったのだけど、その個々のクラスタ的なやつをどう作るか、どう動くかというのももうひとつの課題。

マイクロサービスとかいうのは、更にもうひとつ屋上屋を重ねた感じで、大きくなりすぎたものを疎結合に分割していくこと。こいつはまあ、相当にビジネスが大きくなってから考えることでテクニカルにはそんなに考えることないんじゃないかと思う。むかしマッシュアップとか言ってたアレと相似形だと思えばよろし。

... という前提があったところで、録画を見た感想

  • gRPCのはなし: まあこれはHTTP/XMLJSONみたいなテキストプロトコルがバイナリになって高速化・効率化されましたって以上の話はないと思う。RPCの決定版という意味では、プログラミング言語の決定版でGoを出してきたのと相似形だと思えばよろし。
  • Thriftのはなし: gRPCが出た今、そっ閉じでいいんじゃないでしょうか。Facebookの中の人になるなら話は別だけど、実装やプロトコルとしてそんなに違うことはない。Hadoopまわりで使われているらしいけど、まあ別に何でもいいでしょ。
  • リアクティブがどうのこうのという話: N:Mのスレッドモデルがない処理系だとコールバック地獄になって非同期でコード書かないといけないっていう、そういう問題を啓蒙してみんなで取り組みましょうってことなんだけど僕はそれが既に解決されているErlangを書いてる人なので価値がわからない。N:Mの軽量なスレッドモデルがあればいいんでしょ。
  • Backpressureの話: これは push 型のアーキテクチャで、かつpushされるモノが非常に多い時に受け側が死ぬ問題を解決するもの。そうじゃなかったら必要じゃないし、必要ならフレームワークでも標準化でもなんでもやればよろし。たとえばスマホのpush通知なんかだと必要ないでしょ?
  • 非同期は人類には早すぎたとかいう話: 別にミドルとかカーネルのレイヤならみんなやってることなので、人類が進歩すればよろし。ってだけじゃあアレなので…どうやってCPU数よりも数桁多いIOなりコネクションを捌くって話で、効率的に1:1のスレッドモデルで複雑な非同期プログラミングをするか、多少効率は落ちるけどN:Mのスレッドモデルで同期プログラミングにするかっていうトレードオフでしかないと思う。パフォーマンスが欲しければ非同期で苦労してください。
  • ネットワークに限界が来ている話:海底ケーブルを引いたりGCPを使えばよいという話にはならない。データはどうやっても光の速さを超えられないわけで、たとえば地球の裏側のDBと同期レプリケーションが現実的な性能でできるか?といえば今のところTrueTimeしかないのだけど、それでレイテンシは10~30ms程度なわけだ(一般的な水晶振動子の精度が確かその程度だと記憶しているので、現実的にはそれ以上は無理だと思う)。そこが一番ムズカシイと思うけど、たとえばクラスタ間の連携とかサービス間の連携、接続についてはよくしらないので割愛。
  • Scala / Go の話: バージョン依存関係はいまのところ銀の弾丸はないので、どれ使っても大変だと思う
  • Erlangの話: 特にコメントはないです
  • 並行処理は人類には早すぎたとかいう話: 別に早すぎないと思うけど… 難しいのは設計よりもテストで、プロパティテスティングとかFault injectionとかその手の技術は発展してきているので必要な場面では苦労して使えばいいと思うけど。
  • マイクロサービスがあって初めて非同期になる: 耐障害性を考えるとそうかも?投機実行にも非同期は必要だね
  • Eventual Consistencyの話: どうしてマイクロサービスになったらそうなるのかはよく分かってないけど、2相コミットすればなんとかなるんじゃない?
  • kubernetesの話: 最近は分散スケジューラにも興味があるので、調べないと…

話そうと思っていたこと

ウェッブシステムを構築するためにはまあとにかく有象無象のツールなりミドルウェアを理解して運用しないといけない。全部見守らないといけない。大変。そういうときにはOpenStackなりでマシンを仮想化して監視やルーティング、デプロイをきれいにしてTerraformとかAnsibleとか使えるようにして…っていうのが Service as a Code を実現するために必要なことなんだけど、それってまあ「使う側」の考え方で、もうちょっと悪くいうと使うだけの話になってしまう。使うだけじゃなくて先導して作る側にまわるためにはもうちょっとビジョンが必要だと思う。

ここまでコンピューター技術の発展ってハードウェアの発達、つまり工業技術の発展に駆動されてできることが増えてきたから、ソフトウェア側の人間はそれを追いかけるだけでよかった。でも、近年は発達し尽くして端末も普及し尽くして、できないことはないっていうくらい格段に増えてきた。もちろん、連続的でリニアな発展を続けるなら、ハードウェアの進歩に立脚してそれに対応できるソフトウェアなりミドルウェアを設計すればよかったんだけど、非連続な進歩のためには「何でもできるんだけど、どうやったらいいか分からん」みたいな状況だった。それが、ここ数年で明らかに変わってきたことがある。

それは、ソフトウェア技術の発展が、ハードウェアの発展ではなくてビジネスや社会状況の変化によって生まれた新しいワークロードによって駆動されるようになってきたということ。まあビジネスや社会状況の変化はインターネットの発達によって駆動されてきたんだけど…新しい技術を生み出している先端企業というやつはデータ駆動でビジネスを動かしていて、そのビジネスのためにソフトウェア(ミドルウェア)を開発しているわけだ。インターネット上のデータを全部アーカイブして最適な広告を売れるようにするとか、世界中の人間にネットを通して物を推薦して売るシステムを組むとか、世界中の人間関係を全部オンラインに持ってくるとか、まあそういうクレイジーなスケールなり仕組みなりが今の人類の限界なので、そこからじゃないとコンピューター技術の発展も見えてこないんじゃないかなあというのが僕の持っている感覚です。そこからじゃないとアーキテクチャの変化は分からないし、それのはるか後ろを追いかけるだけで面白いの?という煽りをやりたかった。


で、その煽りのあとで最近だとBorg, YARN, Mesosとかがその例なわけで、デプロイのためのHashicorpプロダクトがやけにバズってる日本でデプロイは大した問題じゃないんだよって、あえてちょっと違うアプローチのものを紹介したかったんだけど、まあそれはまたの機会に。

あとは、マイクロサービスの文脈で可用性とかネットワーク分断の話ってわりと日本だとスルーされがちだよねえと思うので、これをはっておきますね。

kuenishi.hatenadiary.jp

まとめ

徒然なのでまとめる気はあまりない。読む方、聞く方は大変だけど、まとめなくていいって楽だよ…

*1:OSSという文字がゲシュタルト崩壊して、手足をくねらせて横たわる人間に見える呪いです

札幌へ行ってきました

DB Techshowcase Sapporoの開催に合わせて札幌に行ってきた。

まずはニッカの余市蒸留所に行ってきた。

100ND610-DSC_7528

本当にウィスキーを作っていた(当たり前である)。宮城峡を訪れたときに行って非常に楽しかったので、今度も…と思って行ったらスッカリ観光地であった。朝ドラのためだろう。人が多いし、原酒不足もあって原酒直売もなく、原酒の有料試飲もなく、トホホ…竹鶴ノートの実物も拝めたしよかったとする。余市駅、わたしが昔利用していた津山線を思わせるものが多く非常に風情があってよかった。

100ND610-DSC_7454

さて夜は薄野である。🍣。いろいろ検索して調べてみるも、人気と言われていた店があったりなかったりで、適当にフラフラと行ってみたらもうその店はなくて…でもひとつのビルに3軒も寿司屋が入っていることもあり。今回は飛び込みでまつもとという店に入ってみた。

100ND610-DSC_7567

薄野も路地があって、なかなか色気のある街でした。呼び込みが多いので行く人は気をつけて。

100ND610-DSC_7574

写真はないけど、ホテル近くの坂東珈琲はよい香りのするカフェであった。

二日目はサッポロビーム#80に参加。PyCon Sapporoの準備をみんなしてる中、僕は普通に仕事。その後、 nikuさんに四季 花まるという🍣屋へ連れてってもらう。コスパが非常によく、単なる刺身寿司じゃないところがまたすごい。これが札幌では標準レベルなのだそうだ。写真は帰りに撮った夜の電波塔。三脚を持たずに行くとか、私はカメラ持ちの資格ないかもしれない。

100ND610-DSC_7611

最終日の昼食は札幌駅前の奥芝商店でスープカリー。ボリュームがやばかった。

100ND610-DSC_7632

夜は千歳空港でラーメン。本当はえびそば一幻をまたnikuさんに薦められたのだけど、列ができていたので断念。空港内にラーメン街があって、もう口がラーメンしか受け付けない状態になっていたので、白樺山荘で札幌みそラーメンに挑戦。

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

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

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にプログラムを実行するという意味で昨今のリアクティブプログラミングに似ていると思うのだが、私のリアクティブプログラミングの理解は合ってるだろうか。