DevLOVE「DBも、進化せよ。」へ行ってきた

金曜の夜、DevLOVE勉強会「DBも、進化せよ。」へ行ってきました。

今回は、Jiemamyというオープンソースプロジェクトについて、開発者の都元ダイスケさんご本人が、コンセプトから特長まで丁寧に紹介してくださいました。Jiemamyというのは、開発モデルであり、DBの進化的設計を補助するツールです。…なんて書くまでもなく、おそらく有名ですよね。

当日の発表資料は、都元さんが公開してくださっています。

というわけで、学んだことと感想をメモしておきます。学んだことのメモは、あくまでも自分の解釈なので、誤りがあるかもしれません。

都元ダイスケさんによる発表

Jiemamyとは、Smart Build、Smart Version Control、Smart Modelの考え方に基づくDBの進化的設計を支える開発モデルである。

# 進化的設計と対照的な概念が、計画的設計とのこと。

Smart Build

アプリケーションは、環境の中で動く。環境とは、アプリケーションの制御下にないモノすべてを指す。たとえば、環境変数JVMの種類、Appサーバ、DBサーバなどが、"環境"である。

リポジトリからチェックアウトしたら、追加の情報を必要とせずに、できれば1コマンドでアプリケーションをビルドし、実行したい。1コマンドでは難しい部分については、きちんと文書化されて(Documented)いて欲しい。Jiemamyでは、これをSmart Buildという。

Smart Version Control

開発では、構成管理をする。このとき、アプリケーションとDB構成の同期をとる必要がある。

アプリケーションのソースコードだけを構成管理の対象にしても意味がない。なぜなら、特定のバージョンのアプリケーションをチェックアウトしても、実行できない可能性があるからだ。古いバージョンのアプリケーションは、最新のDBスキーマでは動かないかもしれない。そのため、アプリケーションの各バージョンに対応したデータベースの構成も保存する。

Jiemamyでは、環境を再現するための手段や情報もコミットする、コミットしたアプリケーションを動かせる環境もコミットする、というプラクティスを提唱する。これをSmart Version Controlという。

Smart Model

たとえば、テーブルと、テープル間の関連と、初期データがあるとする。これらを何に記述するか。

ER図か? ――ER図はたいていバイナリデータで、スマートビルドを妨害する。

sqlファイルか? ――sqlは、変更があったときに、編集がむずかしい。

ER図とsqlファイルの両方か? ――それはDRY原則に違反する。

このように、DRYが難しい場合がある。そのようなときは、原則に、注意深く違反しよう。そして、違反する場合はDocumentedを忘れないようにしよう。具体的に、次のポイントにも気をつけるとよい。

  • ER図とsqlの正副関係をはっきりさせておこう(差分があったとき、どちらを正しいとするか)
  • ER図とsqlが同期していない可能性を念頭において使おう

Jiemamyモデルは、この問題を解決する。Jiemamyモデル(XMLファイル)から、sqlや設計書を作成できる。このXMLは、マージされることを念頭においた書式にし、さらに、可読性にも配慮した。Jiemamyでは、これをSmart Modelという。

補助ツール群

ダイアログ:DB座談会

テーブルごとに話をする時間。今回は、各自の「DBのここが好き or ここを何とかしたい」という意見や、講演を聴いての感想を元に、話し合いました。

自分がいたテーブルは、気がつけばクラウドクラウド上のストレージの話で盛り上がっていましたが・・・ :-)

「開発環境を整備するための自動化の工夫に、感動した。他にも、開発環境整備をラクにするために、できることはないか?」というのが自分の感想でした。それに対して、同じテーブルにいた方から、次のような意見をもらいました。

  • 仮想化技術を使って、開発環境の乗ったイメージを配布できる
  • Google App Engineを使ってスケールする部分を自動でする

現在、仮想OSにゲストOSを乗せた状態で配布されたものを使っています。その上に開発環境まで構築したものを配布することは、まだしていません。あくまでも、標準的な基盤だけ作って配布する形式です。でも、開発準備の時間を短縮するには、たしかにフレームワークIDE、DBまで載せた状態で配布するのもアリですね。

ほかに、「DB管理自体、敷居が高いと思っていたけど、Jiemamyのようなポンと使えるツールもあり、今は良い時代だ」とか、「自分のプロジェクトでJiemamyをどうにか適用できないものか考えたい」という感想なども出ました。

感想とお礼

今回の感想は、出会ってしまった…の一言でした。どういうことか?

開発環境づくりを技術的なアプローチで支援するという試みに、自分は興味と思い入れがあります。なにしろ会社に入った時、「技術者が些事に煩わされずに開発できるような環境を整備する仕事がしたい」と主張して、いまの部署に配属されたくらいなので…(そういう考えに至った原因は、最初に働いた会社で痛い目に遭ったからですが)

今回の聞いたJiemamyの話は、そんな思い入れの部分にピタッと当てはまり、発表を聴いた後から懇親会が終わるまで、ずっと興奮していました。開発環境を整備するために、どこを、何を、どうやって、自動化・機械化できるかを、もっと考えていきたいと改めて思いました。

また、プロダクトありきでなく、開発プロセスを提唱しているという点が、自分が勝手に持っていたOSSプロジェクトのイメージと違っていて、新鮮でした。

今のプロジェクトは.NET C#SQL Serverなのですが、ひとまず仕事以外でJiemamyを使ってみたいです。

都元さん、DevLOVE運営の皆さん、同じテーブルや懇親会でお話ししてくださった皆さん、どうもありがとうございました。