Day 24: Mito
これは fukamachi products advent calendar 2016 の24日目の記事です。
今日はMitoについて話します。
Integralの失敗
11日目のIntegralの「抽象化の失敗」のところで取り上げましたが、Common LispのORMとして作られたIntegralはPostgreSQLのサポートに失敗し、サポートするには根幹部分から再設計が必要となりました。
その後dataflyを作ったりして、ORMよりももっと軽量なライブラリを好んで使っていました。けれどそれも、サムライトでIntegralを採用してから話が変わってきました。
いよいよ真面目にメンテナンスしないといけなさそうだけれども、Integralに手を入れ続けるのは限界がありそうです。そこで自信を持って使ってもらえるORMは必要だなと思って一から書き直したのが「Mito」でした。
Mito
Integralの経験を活かしてMitoでは慎重に抽象化を行いました。具体的にはdefclassをCREATE TABLE文と紐付けるメタクラス層と、そのメタクラスをData Access Objectとして扱えるようにするメタクラス層で分離しました。
また、Integralではdefclassの:typeをRDBMSのカラム型に変換できる機能もあったのですが、Mitoではそこまでの高度な抽象化はしませんでした。そのため少し保守的な設計になっていますが、何よりちゃんと動くことが大事です。
最近は僕もいくつかのプロジェクトでMitoを使っており、マイグレーションも含めて問題なく動いています。
名前の由来
どうでもいいことなんですが、「なんでMitoって名前なんですか」とサムライトの社内ミーティングで訊かれました。
Mitoというのは京都市動物園にいるアジアゾウの「美都」からつけました。
これは猛暑真っ只中の写真で、飼育員さんに水浴びしてもらっているところです *1。
飼育員さんがプールに入らせようと好物のりんごをプールに放ったのですが、プールが嫌いな美都は鼻を伸ばしてりんごだけ取っています。水こわいけどりんごは食べたい。
なぜアジアゾウの名前をつけたかというと。
昔、ElephantというCommon Lispのオブジェクトストアがありました。このAPIはよくできており、CLOSオブジェクトを永続化させるという高度な抽象化を行っていました。このElephantには問題も多かったのですが、目指した夢としての印象は僕にとっては強烈で、僕のORMにもその心意気は込めたいと思ったからです。あと愛着が湧くからです。美都かわいい。
まったく技術的な話ではありませんでした。
おわりに
MitoはGitHubで公開されており、現在Starは35ついています。
明日のアドベントカレンダーは最終日25日目のUtopianについてです。お楽しみに。
*1:写真は2013年当時のゾウ舎。今はゾウ舎が移築されて広くなっており、ゾウも4頭増えています。しばらく美都は奥のゾウ舎から出てこなくてまったく会えなかったのですが最近は見られるのでしょうか。
