日曜夜から疲労感があり、翌日高熱頭痛でダウン。本日病欠二日目。だいぶよくなったので明日からは出勤できるだろう。

ちょっとがんばって余暇にコードを書いたりすると体調を崩す。体がボトルネックで頑張れないのはつらい。まあ体調を崩すのが概ねいつも頑張った直後なのは事実だとしても頑張ったあと常に倒れるわけではないから、「頑張ると倒れてしまう」というのは一般化しすぎだろう。ただ体調不良はシグナルとして受け取り、しばらくペースダウンの予定。

頑張ると常に倒れるわけではないとはいえ、頑張っている状態をデフォルトにできないのもまた事実だと思う。少しはマージンがないと不意のストレスやワークロードに対応できない。時間と体力が足りない。

様々な形で好きに使える時間が失われていくとき、できることは大きく分けて二つあると自分は暗に考えている。一つは「無駄な」時間をなくすこと。もうひとつは「他の」時間を諦めること。別の言い方をすると、無自覚に使っている時間を発掘するか、自覚的に使っている時間の内訳を変えるか。更に別の見方をするなら: 無駄を効率化するか、何かを諦めるか。

何かを諦めるのは得意な方だと思っていた。今やマンガや小説はほとんど読まず、ソーシャルメディア含むインターネットに費やす時間も減らし、長いブログも書かなくなった。けれど、本当の諦めはもっと深いところにあるのだろうとも思う。倫理的な理由から削れないと思っている家事労働や、健康のためのジョギングなどは今のところ聖域になっているけれど、これらを犠牲にするときはじめて自分の諦めの良さを問われるのだろう。趣味の時間をなくすのに大した痛みはなかったから。

でもその前に、自分が苦手な「無駄をなくす」ほうでもうちょっと手を打つ方が良いとも思う。働き方にはまだ工夫の余地があるし、家事や運動もそう。インターネットに使う時間もまだまだ多い。

最初の一歩として、頑張りすぎで倒れないよう「休憩」を意識して時間割に取り入れるようにしたい。いまはサボりと休憩の区別がはっきりしていない。Pomodoro をしている仕事中は休憩が休憩として機能しているけれど、たぶん何らかの planned break が生活全体に必要な気がする。休憩をサボリでなく回復の手段として自覚しないと、疲れからダラダラしたまま一日が終わってしまう。休憩が factor out されたら無駄な時間の不透明さも少しは改善されよう。

なので一日の中でどう休憩するかを考えたい。おっさんすぎて泣けるがやむなし。

Apache Phoenix. HBase への SQL アクセスを提供するレイヤらしい。もともとの開発者はSalesforce.

文法は ANTLR3 で書かれていた。AST は自前で作る。人の書いた semantic action を眺めるのは勉強になる。そしてみんな SQL 実装してるな。自分で。実行部分の難しさと比べると SQL のパースなんてのは些細なものなのでしょう。

空のプロジェクトをつくった。次はとりあえず何か動くという状態にしたい。最小限の SQL として

• SELECT で複数のカラムを指定, AS による aliasing あり
• FROM で単一のテーブルを指定
• WHERE 以降はナシ

が動くようにする。WHERE に進むには式を評価する必要があるのであとまわし。AST は作る。実行計画やデータフローみたいのは不要。スキャンして row を生成し, それを rename し, 最終的な column を accumulate する、みたいなことをするだけだから。最初は aliasing ナシでもいいキハするけれど、式の評価とかをする上でそのレイヤは必要そうなのでいれてみる。すごい簡単だが、それでも AST など必要な足場のために多少の頑張りが必要。

あと一応 API を考えないといけない。まずはあまりカッコつけずべたっとしたものにしておく。

Impala は lexer と parser generator にそれぞれ JFLex と CUP を使っている。CUP は聞いたことがなかった。 Syntax が違う以外はだいたい Bison ぽい。ANTLR みたいに AST をつくってくれる機能もあるっぽいけれど Impala ではそれを使わず自力で書いている。

なお Presto や Hive は ANTLR を使う。Java はこの手のツールが妙に充実してるね。そして Presto の文法ファイルを Impala のファイルと比べると ANTLR の強力さがわかる。が、自分が使う PLY は記述力の低いツールなので Impala の CUP コードの方が参考になるのだった。

Impala の文法を眺めつつちょっとだけ PLY の文法を書いてみて思ったこと: (1) 自分は SQL を知らなすぎる。すくなくとも一冊くらい SQL の入門書を眺めないと自分の作ってる文法の正しさを少しも判断できない気がする。UNION とかしらねー。(2) Impala からコピペしているせいが大きいとは思うけれど、SQL の文法はサブセットにしておけばそんなにむずかしくない。古い言語だけあってコードを簡潔にしようみたいな頑張りを感じない。サブセットの AST までなら割と問題なくいけそうな予感。(3) Python+PLY でパーサを書くのはけっこうよい。Lex/Yacc のダメさも Python のおかげで若干やわらぐ。

実際にプロジェクトの stub を作り、作りを考えつつコードを書きはじめていい気がしてきた。

GitHub が GraphQL をサポートしたというニュースに驚き、久しぶりに資料を眺めている。

以前みた時は、クライアント側は嬉しいけれどサーバ側を書くのが大変そうな印象だった。GraphQL サーバのフレームワークたちは、フレームワーク側がクエリを型単位のリクエストに分解する。フレームワークを使う側はデータを取得する "resolver" 一式を個々の型に実装する。

バックエンドが microservices や nosql になってしまっている大規模サービスなら悪くないデザインだけど、RDB から一撃で色々ひっこぬきたい人たちには嬉しくなさそうに見える。実質上 ORM の one-to-many association で lazy evaluation をするみたいになってしまい、性能上の問題もありそうだし。(なおこの問題を N+1 problem と呼ぶことを今更知った。) API endpoints をトラバースする手間がクライアントサイドからフロントエンドのサーバに移るだけだと、仕組みの大袈裟さに対する有り難みが小さく感じる。GraphQL の issue にもその申し立てがある。

調べてみると, GraphQL ライブラリのいくつかは N+1 problem への処方箋を持っていた。具体的には "N 回のリクエスト" を "N 個のオブジェクトを取り出す 1 回のリクエスト" にまとめようとする。なので N+1 が 1+1 になる。1 ではないけれど N+1 よりはだいぶいい。ただネストが深くなるとどこかで N が顔を出しそうではある。

Scala の GraphQL 実装である Sangria はバッチ化したいオブジェクトを Deferred という generic type で表す。するとフレームワーク側が同じ型の deferreds をまとめ、一撃で取得するリクエストを投げ、その結果をまとめて返してくれる。らしい。

Facebook が公開している DataLoader という JS のライブラリも似た感じ。データをすべて Promise でラップし、Promise の解決をバッチ化する。フレームワークにくっついておらずAPI が素直、コードも小さい。これを書いた人は Promise わかってんなというかんじがして良い。README には graphql-js と組み合わせてつかう例が載っている。関係ないけどその README 冒頭でちらっと書いてある background story がよい。その Ent っていうフレームワーク、むかしなんかの techtalk で聞いたよ! などと FB tech watcher としてにわかに盛り上がる。

Ruby では graphql-batch を使うと Github のブログに書いてある。読んでないけど似たようなもんなのでしょう。Intuit も使っているというから来年の確定申告がちょっとだけ楽しみになった...とおもったら TurboTax じゃなくて QuickBook か。残念...どうでもいいですが...

という具合に当初の印象に反しサーバ側もじりじり使いやすくなりつつあるかんじなのだろうか。

クライアント側。JS ならさておき Android はどうなのかなあ。graphql-java というのをつかうっぽいけれど、データを Java のオブジェクトにマップしてくれないとつらい。Java のクラスで GraphQL の型を表現する graphql-java-annotations なんてのがあるからあと一歩。Facebook がどうしているのか知りたい。ほんとに Android 向けで GraphQL 使ってるんだろうか。まあビルドシステムとべったりくっついててオープンソースに切り離せないとかなんだろうね。

現状だとまだ React スタックな人向けのフレームワークだなという印象。React-Redux-Relay-GraphQL のなにかをつくるのは楽しそうではある。AWS Lambda の API gateway みたいなレイヤが GraphQL を解釈して背後の lambda に dispatch してくれるなどの支援がすすみ、趣味プログラマからも手が届くテクノロジになってほしいもんです。

引っ越しに伴う電力会社の住所変更を忘れていたので PG&E に電話をしたら、新しい住所がみつからないという。なにかと思い管理人に確認したところ、電気代含む utility fee は家賃とセットで払うらしい(家賃に含まれていはいない)。PG&E ではない電気会社があるのか、それともアパート全体でまとめて払い、徴収を一元化しただけか。

これは電力自由化と関係があるのかとふと思う。むかしむかし旅行でサンフランシスコのホテルにとまったとき、電力自由化の煽りをうけ停電しまくりでごめんなさい、と張り紙がしてあったのを思い出す。それが Enron の仕業だったと知ったのは随分後のことだった。

前は家賃と電気代とその他の utility を別々に払っていた。それを一撃で払えるようになったのは便利ではある。一方で引っ越すたびに業者が変わるめんどくささもある。ゴミの回収が民間業者なのは、分別にうるさくないのが便利。ただ utility fee がかかるのと、ただしく処理されているのが若干疑わしいのは欠点。

From Wikipedia.

GROUP BY は aggregation 操作の引数として表現する。そして aggregation は伝統的な relational algebra ではなく拡張されたもの、なのか。そして SELECT には式が書けるわけだが、それも伝統的なやつには入っておらず拡張。てか Projection とか Rename だけだとどうにもならいし、Join も微妙にしょぼい。Natural join が一番重要とかまじか。SQL を実装するなら SQL にあわせた Relational Algebra がいるね。というかそれがほとんど Volcano なわけだが・・・。

代数的な性質を使い式変形をすることで高速化できるということに目をつけて形式化した Codd さんはえらかったが、自分は最適化を実装する気はないのでもうちょっと雑な何かでよさそう。

Redbook でも推薦されていた Volcano の paper を読む。(実際にはいくつもあるシリーズの一つ。)

俺の考えた最強の SQL 実行エンジンフレームワークを作ったぜという話。実行計画の個々のノードをある種の高階関数として定義しカスタマイズによってノードの実装は数を絞る、同時に複数の入力ストリームから出力を一つつくるストリームとしてノードを抽象化し、そういうストリームをつなぎあわせて実行計画を作ろうな、という主張。Rx の話を読んでるみたいな気分。これが 1990 年とは、アカデミアなかなかやる。C 言語で書いてあるのにイテレータで遅延評価でストリームとか functional jargon が飛び交っている。こんなかっこいいもの作って 90 年代のハードウェアでまともに動いたのだろうか。そして謝辞に Jim Gray と Stonebraker が...

参考になったが、それ以上にかっこよさがやる気を起こす paper だった。

せっかくなので頭の中にあることを書き出しておく。良いプログラマの皆様はこの進め方に「そんなことやってるからダメなんだよ」と思うことも多いでしょうがそっとしといてください。大してコードを書けないおっさんが余暇プロジェクトをやるときに何を考えてるかというのは、役には立たないにせよ興味深い記録になるでしょう。

不安の一つだった parser generator は PLY でなんとかなりそうなのでよかった。言語処理系的な面倒は色々あるだろうけれど、そこはビギナーとして素直にがんばる。

まだコードを書き始められる気がしない。他にも no idea 事項が多すぎる。わからないこと:

• 全体のアーキテクチャ。一度は何か実物のコードを眺めたい気がする。OLAP 系のオープンソースのデータベースをなんか眺めたい。論文も読んだことだし Impala でいいのかな。分散しなくていいんだけど、いまさら C で書かれた昔ながらのデータベースを読むのはいやだ。
• AST から実行計画を作るところの見当がつかない。いま Volcano の論文を読んで実行計画のオブジェクトモデルみたいのが少しわかってきたが、それと SQL の関係がわかってない。コレはどうしたら良いのだろうなあ。いいかげん SQL の本を読むべきなのかもしれないが、それは先が長すぎるので Wikipedia とかで最低限の理解を得られないものか。
• それと関連し、SQL のパースの反対側、実際に DataFrame を enumerate してデータを extract するところ、実行計画というか実行そのものも、どういうデザインがよいかよくわからない。これは時間をとって考えないといけないが、その前にとりあえず関係代数の復習はしたい。
• などの疑問は教科書に書いてありそうなので、結果的に RDB の教科書を一冊手元に置いておくのがよい気もする。しかしどれもこれも厚くて高くてレビューが低いので気が乗らない。いっそ cow book を買い直せばいいのか・・・。
• 書捨てでない Python の書き方。これは blocking というほどではないけれど、いまいち Python でちゃんとしたコードがかける気がしない。不安をやわらげるべく、ジョギングのお供で Python の本を読むことにした。

書き出してわかるに、われながらまったく出来そうもないことに手を付けてる感。しかしここでくじけるリアル三日坊主なのでもうちょっとなんとか進めたい。やるべきこと:

• Volcano の論文を読み切る
• Impala の SQL の文法をパクリつつミニマルな SQL を PLY でパースしてみる。まずは書捨てで良い。
• Wikipedia か何かで関係代数について復習する
• Python 読書継続

やりたいが時間なさそう:

• Impala のコード全体を眺める
• RDB の教科書を物色する。関係代数とか SQL の評価について丁寧に扱っているもの。

Python 用の parser generator として PLY を試す。といっても簡単な四則演算を評価するだけのパーサをつくる hello world をコピペしつつ動かしただけ。

自分は Lex/Yacc を真面目に使ったことがなく、Hello World 以外では他人の助けを頼りに通りすがりで既存の g ファイルをいじったことがあるくらい。だからノウハウを何もわかっていない。若いうちに言語処理系を作っておくべきだったが仕方ない。トライアンドエラーでがんばるとしよう。 Lex / Yacc の本を読んだほうがいいのだろうか。乗り気になれないけれど。

その少ない経験にもづいて思うに、PLY は Python-Lex-Yacc というだけあってまるっきり Lex/Yacc だなあ。そういうコンセプトのライブラリなので仕方ないが、もうちょっとモダンな何かにはなれなかったのかと思ってしまう。bug tracker の会話を見ても「デザインが古いのは歴史があるからで仕方ないし直す気もないよ」と言っている。API がモダンになるだけでだいぶかっこよさそうなのに残念。この上のレイヤで誰かがんばってくれないものか。Lex/Yacc とか 40 年前のテクノロジじゃん。これが 40 年前にあったというのはすごいことだが・・・。

いいところもある。作者が主張するとおりエラーメッセージは丁寧でわかりやすい。そして Pure python な上にコード生成を実行時にやるため yacc/lex コマンドを走らせる必要がない。これは動的言語らしくてよい。あと古いとはいえきちんとメンテナンスされている安心感はある。

モダンな parser generator として ANTLR を使おうかとも一瞬考えたけれど、別コマンド実行の不便をふくめ Python との相性の良さが低めに見えたのでやめておいた。Combinator 系はどうか。なんとなく動的型で combinator は違う気がする。

まずは他の SQL 実装の文法ファイルを眺めつつ PLY で簡単な SQL を解釈してみようかなあ。SELECT 文 WHERE なし式なしみたいなやつ。

プログラマが日本語で翻訳するのがどうとかいう話で盛り上がっているのを見かけた。

自分がそれなりに英語で苦労しているせいもあり、プログラマとしての英語に対する態度については一時期よく考えていた。せっかくなのでなにか書いてみたい。まず英語や言語バリアの話とセットで扱われがちな翻訳について。

色々ある翻訳の中でも、ブログなどの野良翻訳はやらないほうが良いと思う。自分も一時期よくやっていたので心苦しいけれど、その体験からこれはダメだと思うに至った。

ブログの翻訳は、まずブログが本来持っているソーシャルな性質を損ねてしまうのがよくない。ブログをはじめとするウェブのメディアでは対話や関心が通貨だ。何か対話のきっかけになるのが一番嬉しいし、コメントからライクまで様々なフィードバックを見るのも面白い。読まれた手応えが励みになる。翻訳はこの通貨の流れを断ち切ってしまう。書き手の知らない URL に書き手の知らない言葉で並ぶコメントは虚しい。何を言ったところで届かないから。

見方を変えると、ブログの野良翻訳は通貨としての関心を横取りしてしまう。個人的にはこの方が厄介な問題だと思う。

英語のブログを翻訳する方が、同じくらい意味のある日本語の文章を自分でイチから書くよりずっと簡単だ。だからオンラインで関心を集めたければ面白い英語の文章を見つけてきて訳せばいい。プログラマはブログに書いた文章の権利管理にさほど厳しくない。翻訳させてねと頼んで断られたことがない。全文ではなく適当な抜粋を訳したり紹介するだけなら断りもいらないから更に簡単。意地悪な言い方をすれば、テックブログの翻訳/要約は関心のサヤ取りをするまとめサイトに似ている。

この手軽さを考えると、人々の視線を集めるのが主たる目的たるブロガーやオンラインメディアが翻訳、抄訳や要約をするのは、自分の好みをさておくと理にはかなっている。でもプログラマにとってはどうだろう。

プログラマがブログの野良翻訳をはじめるとき、最初の動機にやましいものはないだろう。すごく良い文章に出会った。友人や同僚に読んで欲しい。そんなところだと思う。よろよろと翻訳をして自分のブログなんかにアップロードする。大きな反響がおこる。広く読まれたことに満足する。

ただその満足感や刺激は、ちょっと強すぎる。自分の書いた文書では決して集まることのないであろう大きな関心が集まる。自分の文章でないことはわかっている。でも翻訳というのは、気に入った、感情移入した内容であればあるほど、自分の文章のように思えてしまう。少なくとも日本語にしたのは自分なわけだし、翻訳のプロセスを通じて普通より深く読み込むぶん無意識のうちに文章の中身が内面化される。書き手との一体感。この結びつきのせいで、翻訳にあつまった関心を自分から切り離すのが難しくなる。自分が何かすごいものを書いたような感触が、自覚しないまま心の底に残る。

別の良い文章をみつけ、また翻訳する。反応がおこる。何度かやると翻訳作業のコツがわかり、少ない労力で訳せるようになる。誰かに読ませたいというある種の善意と、人目を引きたいエゴが混ざりはじめる。そもそもこの二つの感情に区別があるのかすら自分には怪しい。「これを訳せばウケる」と考えはじめた自分に気づき戸惑う。自分はどこかに吐き出したい、誰かに伝えたいメッセージがあるから文章を書いていたはずなのに、なぜまた人にウケようとしているのか。

ソーシャルな関心という刺激に対する反応の度合いは個人差があると思う。自分はあまり意思が強い方ではないので、人目を引きたいという誘惑に負けることは多い。多かれ少なかれ人は関心の誘惑に引き寄せられる。ソーシャルメディアの隆盛がそれを示している。そして野良ブログ翻訳/要約作業は、手軽さ、一体感、関心からくる刺激のバランスから極端に強い誘惑を生み出しがちだと思う。この強すぎる効能が野良翻訳に手を染めたプログラマのインセンティブを大きく歪めてしまいはしないか。

関心を集めたいと思うのは必ずしも悪いことではないと自分は考えている。けれどオンラインで暮らすプログラマなら、プログラマやソフトウェア開発者としての経験や成果を通じて何かを語り、プログラマとして世の中に認知された方が良い。人に認められたい気持ちがプログラマとして前にすすむ力になるから。

ブログの野良翻訳に必要な能力はだいぶ違う。ある程度の英語力と、ウェブのメディアから面白そうなものを見つけるインターネット中毒力。あとは翻訳それ自体のスキルも少し。プログラマ読み物の翻訳家になるのがゴールなら、とまではいかなくてもその翻訳業を自分の主要な趣味にしたいなら、どうぞお好きにと思う。でもそれがいくら上手くなったところでプログラマとしての進歩はない。

だからプログラマとして成し遂げたいことがあり、その中で「コミュニティへの貢献」とか「勉強のついで」とかいう理由で翻訳をするなら、やめた方がいいかもしれない。その結果やってくる劇薬的な刺激に気が散りすぎるだろうから。何年も安易な人目引きを続けたせいで、自分はプログラマとしての aspiration を損ねたと感じている。英語やネット中毒力よりはテクニカルな技能や経験を通じてコミュニティに出て行く方がいいよ、たぶんね。

マニュアルや書籍の翻訳はどうか。自分はやったことがないからわからない。それにわざわざやろうとする人に水を差す気も起こらない。本を一冊訳したり更新されつづけるマニュアルの翻訳を保守するのは気楽とは程遠いからね。

モダンな SQL つき OLAP 実装の輪郭を眺めるちょろい方法はないかと Impala の paper を読む。

AST から plan をつくって, そいつを色々 rewrite してから実行する。そういえばそんなものだった気がする。AST と plan が別なのは、AST にごてごて色々つけてく一般的なインタプリタと違う。VM のバイトコードといえばそうかもしらんが。そして MapReduce, Spark, Pandas などを通ってから見ると SQL の実行計画ってまったくもってデータフローだね。Hive みたいのを作りたくなる気持ちが今更わかった。

そのほか気になった点: 実行ノード間では tuple をやりとりする。columnar storage でも中間状態は tuple らしい。ただし将来的に materialize したい時は in memory columnar format にしたいと言っている。これは good news のような bad news のようなかんじ。そしてどういう時に materialize が必要なのか自分はわかってない。式の評価に LLVM をつかう。SparkSQL が bytecode generation でやっているところを LLVM でやる。どのくらいの粒度でコード生成してるのかね。書き方から判断するに tuple を渡して評価するくらいの規模に見えるけれど。まあ toyql は interpreter でよい気がする。

更に雑多なメモ: 標準フォーマットは Parquet. Parquet は Twitter と Cloudera の共同開発だったのか。nested/repeated はこの論文の時点ではサポートしていない。Parquet の意味なくね? そういえば Dremel paper は nested/repeated の話で半分くらい紙面を使っていた気がする。Impala paper はそれがないおかげでシステムの全体像にページが割かれており自分の目的には都合がよあかったとも言える。

システムとしては、実行計画をつくる coordinator と評価をする executor という分け方をする。MapReduce とかと同じ。インプロセスでもこういう切り口にするのがいいのかね。わからん。

ちょろく輪郭を冷やかすという目的には良い paper だった。

休暇明け以来いまいち働きがピリっとしない。立て直そうとしばらくさぼっていた Poromodoro を復活してみる。あっさり復調。Porodoro はやれば捗る。知ってる。でもいつの間にかやめてしまい、仕事が滞り、やばいと気づいて復活する、の繰り返し。なぜ続けられないのか。

思いあたる理由はいくつかある。まずしょうもない理由: Pomodoro につかうデバイスの調子が悪い。自分は Wear Tomato という時計アプリを使っているのだけれど、しばらく前から機械の調子が悪く時計自体をつけていなかった。控えの時計があったのを思い出して交換してことなきを得た。ところで Pomodoro はスマート時計のキラーアプリだと思う。嬉しい人は多くないかもしれないけれど、Pomodoro やるなら大変よい。どのスマート時計でも実装がありそうだし。

もうすこし根深い理由。めんどくさくて崩れる。自分は Pomodoro を始めるのより中断するのを面倒に感じることが多いと気づいた。仕事の調子がいいとき、いまいいとこなのに中断してられっかよと休憩シグナルを無視して進めてしまう。そして規律が失われる。仕事の調子がいいうちは Pomodoro の世話にならないけれど、何かが行き詰まったりやる気を挫く壁に阻まれるとダメになる。そしてそんな壁は遅かれ早かれ現れる。Pomodoro が回っているとくじけた時も立て直しやすい。だから調子がよくてもリズム通りに break したほうが良いのだろうね。

もうすこしマクロな理由。ずっと Pomodoro をやっているとだんだん息苦しくなる。自分が仕事を get things done するだけの機械になった気がしてくる。もうちょっと自由がほしい。自分で決めたタスクであり習慣なのだから理論上は Pomodoro の枠組みの中で自由を得ることはできるのだろうけれど、いまいち気が乗らない。

まえ何かで Pomodoro をしない日を作るアイデアが紹介されたいた。今回は試してみようと思う。金曜は No Pomodoro Day. あと一日 1 サイクルは仕事と直接関係ない資料を読むなど脇道にそれる自由を自分に許したい。われながら甘いと思うけれど、そんくらいは許してくれよということにしておく。

SQL の使えるデータベースでも書いてみるかなと思い立つ。そんな簡単なものではないはずだから完成の見込みは薄いけれど、できることがわかっているものを書いても面白くないからね。せっかくなので、今回は作業および調査の記録をここに書き残してみたい。でも挫折したら一連の投稿は公開せずに捨てると思う。かっこわるいから。

データベーステクノロジにはなんとなく憧れがあったけれど、仕事で縁がないせいかまったく詳しくない。趣味で自作するにしても B-tree から組み上げると気が遠くなりそう。 そして SQL は好きになれなかったし一方で NoSQL も面白くない。そんな状態のまま10年くらいが過ぎた。

けれどこのごろ仕事で BigQuery をさわったおかげでちょっとだけ SQL と縁が出てきた。そして OLTP でなく OLAP 寄りのデータベースなら B-tree からはじめなくてもよさそう。実装すれば SQL への理解も深まって良いかもしれない。なんて安直な動機がはじまり。

どんなものを実装すると楽しいかを考える。できれば新しい言語が使いたい。Rust や Scala が使えれば満足度が高そうだけれど、あまりに使いみちがなさそうで盛り上がらない。でもそれを Pandas あたりに繋げば使い道があるかもなあと考えた後、いっそ Pandas の DataFarme 相手に Python で SQL を実装するのはどうかと思い至った。DataFrame はほぼデータベースのテーブル(しかも column oriented) だし、データのロードとかはぜんぶ Pandas に任せられる。SQL を実装するところだけやればよい...気がする。Python は新しい言語とは言えないけれど、書捨てより真面目に使えるようになっていいとは思っていた。Java や C++ よりはやる気になる。

世の中には pandasql  という似たようなことをするライブラリがある。これはデータを sqlite にインポートして SQL を解釈させる。何も面白くない。そもそも現状の自分の SQL レベルを踏まえると競合や実用性を考えても仕方ない。気にしなくてよかろう。

遅そうではある。ま、仕方ないね。速さが気になるところまでいったら上出来。 C++ につなぐとか色々できることはあるでしょう。

名前。実用性を重んじず SQL を理解するのが主目的、ということを強調すべく toyql と呼ぶ。

自分のデータベースや SQL への理解度。ほぼ素人。むかし cow book を読んで感動した記憶があるものの、しょうじき中身は覚えてない。RDB エンドユーザ体験は通りすがりで何度かさわったくらい。大半は ORM 越し。最近ちょと BigQuery を書いているけれど、難しいことはしてない。真面目にスキーマを決めたことはない。正規化とか怪しい。たぶんできない。改めて書き出してみるとほんと素人だな・・・。

どこからはじめよう？今のところまったく何の見当もつかない。最初はデータベースの教科書を読みなおそうと思ったが、すごく時間がかかりそうな上にいまいちピンとくる教科書が見当たらない。じゃあ SQL の仕様書はどうかとおもって探すも 1000 ページくらいある。自分の現状だと歯が立たなそう。

PostgreSQL のマニュアルをみたら、それなりに詳しく SQL が載っていた。これを読むべきか？でも OLAP を作るのに OLTP を調べるのは何か違う気がする。手元に置いておくくらいにしよう。

まずはなにかデータベースのコードでも読もうか。あとは Python を少し勉強しなおし、NumPy と Pandas も少し調べて、Python 用の parser generator を探して試して・・・

コード書く前の準備がけっこうある。できれば一ヶ月くらい調査したらコードを書き始めたい。明らかに勉強する必要のあることが目の前にあるのは気が滅入るような元気がでるような。ガッと書き始められないところに力の無さを感じる。まあ事実なので仕方ない。

不安要素。なにより時間のなさ。そして時間がないことからくるやる気の低落。それにプログラミング力。他の優先事項もある。毎日読むなり書くなり何かはして、やる気を途切れさせないようにしたい。できればね。

引っ越しにともなう懸念のひとつは自転車通勤体験が悪くなることだった。まえのアパートは Stevens Creek Trail という遊歩道/自転車道から五分くらいの距離にあり、これを走ると通勤自動車ラッシュの中を自転車で並走したり高速道路の出入り口で怖い思いをすることなく会社まで走れた。眺めも良かった。

引っ越しに伴い trail ともお別れか・・・と思って調べたら、実は別の trail を走れることがわかった。前よりも入り口までの距離は遠いし眺めも大してよくない。でも高速道路の入り口は回避できる。めでたい。

Mountain View 市は環境保全や景観維持に厳しく Google などが申し出た敷地拡大などをむげなく断ったりと自分からすると感じのわるい相手だけれど、整備された trails をみると we get what we pay な面もあるな、と思うのだった。

でもまあ Stevens Creek Trail の通勤がなくなるのは寂しい。仕事がうまくいかなかった帰り道も、夕日を背後にそびえ立つ NASA の巨大建築物と周囲の林を横目に土手を走る開放感に救われた。そういう見晴らしはもうない。

そんなのを作っているらしい。そして後方互換製はないらしい。まじで? RxJava 1.x ですらしばらく見ないうちにだいぶ変わっているというのに、ついてけないな。機能的に大きな違いは Java 9 に入る Reactive ぽい API と互換性をもたせることだというが、一方で Java 8 以前を切り捨てるわけでもないというし、いまいち立ち位置のはっきりしない買い直しであることよ。

ところで Java 9 に Reactive ぽいものを入れてきた Java は偉い。入れてきたといっても実際はインターフェイスを４つ足すだけらしく、そのインターフェイスも reactive-streams.org なる草の根標準化運動の成果らしい。reactive-stream と同じ signature を Java 9 で提供し、reactive-stream 側が Java 9 向けバイナリで java.util.concurrent.Flow に定義されたインターフェイスを実装すれば色々ハッピー、というかんじなのだろうか。まあ Java の標準に入ってると便利なこともあるのでしょう。コレクションや Stream が Reactive のオブジェクトと interop できるとかね。

C++ にしても Java にしてもそろそろ終わるかなと思わせておきながら地味に改善を続けているのが偉い。個人的に C++ は unlearn して Java はメンテナンスモードくらいの気持ちでいたけれど、仕事でつかうにはそれなりについて行かないといけない。C++ と Java の会社に勤めている限りはこれらから抜け出すことはないのだろうなあ。

なんとなく眺めた Guide to NumPy の第1章。

時は20世紀末。後に Jython や Iron Python を生み出す MIT の若き天才 J.H. が書き捨てた Python 用数値計算ライブラリ Numericを使っていた著者はだんだんとコミュニティに入り込んでいくが、新参ライブラリ numarray の登場によりコミュニティは分断、崩壊の危機を迎える。そこで著者は立ち上がり、両ライブラリを超える第三のライブラリを書き上げた。それが NumPy であるッ!

なかなか熱い話じゃないですか。最初の Numeric を書いたのが後の出世株たる Jim Hugunin だというところもいいスパイスになってる。

2000 年代あたまに Python で数値計算をやろうとしたこの人たちは偉かったね。そして著者は Mayo Clinic でインターン(?) をしながら開発をやってたというから Mayo Clinic が偉かったのかもしれない。

隣町に引っ越した。

引越し屋は地元の小さいところを選んだ。Yelp のレビューが好評だったため。費用はチップ込みで $700 弱。まったく安くないが、そのぶん仕事は速やかだったし値段も明朗会計(時間給+ダンボール代)かつ見積もり未満だったから文句はない。IKEA ベッドの分解と再組み立て、食器類の梱包が特に助かった。これらを自分でやるのはしんどい。逆に一人暮らしで食器も少なくベッドもマットレスを直に床に置いている身軽な暮らしなら自力で引っ越せるだろうね。費用も $100-200 くらいで済みそう。軽トラ、ダンボール、助けを求めた友のメシ代。

地元企業にたのむとグローバルブラック企業の下僕みたいな疲弊した顔の誰かではなく気のいいジモピーがやってくる。資本社会の搾取構造を直視しなくて済むのは精神衛生によい。笑顔がタダでないのは健全な気がする。精神衛生という贅沢を、いつもできるわけではないけれど。

今回はすぐ近く、隣町への引っ越しだった。州をまたいで引っ越す苦労を想像するとやや気が滅入る。サブカルチャーから判断するにロードトリップをするのがアメリカ標準。猫はどうやって連れて行くのだろうなあ。彼らにロードトリップは荷が重かろう。ちょっと検索すると専用の業者がいくつか見つかる。そういう人たちに頼むのだろうか。結局は誰かと旅するほかない。

荷造りはカネの力でラクをした一方、退出時の現状復帰チェックに向けた掃除には苦労した。一日かけてあちこち掃除したものの、猫の引き裂いたカーペットと日々の調理でベトついたキッチンまわりは追加の費用負担となりそう。月々払っているネコ代  $50x2 は一体何のためだったのか。犬はともかく猫は何のサービスもうけていないのに・・・。

壁の画鋲跡などは何も言われなかった。事前に手渡された退出時清掃ガイドには画鋲跡をパテで埋めろとあり、それに従った甲斐があった。この caulk というやつは便利だね。壁に釘や鋲を打つ不安が薄らいだ。

チェックを終えた管理人に「なかなか住心地のいいアパートでした」と伝えたら「ありがとう、できれば Yelp にレビューを書いてね」との返事。このあたりは Yelp にアパート単位のレビューがある。自分もそれなりに参考にした。好感を示した住人にのみレビューをたのむあたり、スマホアプリのレビュー依頼ダイアログみたいだな。

そういえば地元の引越し屋からは何も頼まれなかった。呑気な人々よ。