プログラミングとかそんなの

2012年9月2日日曜日

DBリファクタリング読書会第三回に参加しました

DBリファクタリング読書会は、前から気になっていた勉強会で、今回たまたまタイミングがあったので参加して来ました。

今回は3章の「データベース・リファクタリングのプロセス」でした。

まずは、ビールとピザで腹ごしらえをしてから講演、全員が参加してのディスカッションという流れで読書会は進んでいきました。懇親会が本番みたいな勉強会が多いので最初から懇親会というコンセプトは話も弾んで良かったと思います。

読書会中のツイートはこちらでまとめられています。また、全体的な流れはgarage-kidさんがブログにまとめているのでそちらを参照されると良いかと思います。ここでは読書会の本編とも言える座談会の内容について個人的に気になったテーマをピックアップして紹介します。

実際のプロジェクトでDBリファクタリングを実践したことがある人？

15人位中 3人

やはり、DBの修正はできれば避けたいというのが一般的ということなのでしょうか。そんな中、DBリファクタリングを実際のプロジェクトに適用したt-wadaさんの経験談が非常に勉強になりました。railsのプロジェクトでは開発プロセスの一部として当たり前のようにDBリファクタリングをしているそうです。ただし、シングルアプリケーションに限ります。

マルチアプリケーションのデータベースリファクタリングについてもディスカッションがありましたが、シングルアプリケーションの場合と比べて単純ではない、でも出来なくはないという印象でした。

マイグレーションを適用した後にロールバックすることは何処まで実現できるか？

個人的に凄く気になっていたので質問してみました。

そもそもプロダクション環境でロールバックが必要にならないよう、その前段階で十分に検証を重ねることが前提。
逆変換が書ければロールバックは基本的にはできる。逆変換がないマイグレーションがpull requestされてもリジェクトする。
データを統合するようなマイグレーションの逆変換を書くことは不可能なのでそういう状態にならないように設計段階で注意をする。

というお話を聞けました。さらにマイグレーションに関して、

マイグレーションは細かいステップで作ったほうがレビューをしやすい。
ただし、プロダクション環境に適用する前に見直して重複した更新を省いたり、更新したけど結局戻したみたいなマイグレーションを整理して軽くする。
マイグレーションの適用時間 = システムの停止時間となる場合が多い。

という話も聞けました。

DBリファクタリング適用の移行期間を設ける必要があるのはどういう状況か？

マルチアプリケーションの場合に必要となるケースが多い。
DBを利用するすべてのアプリがすぐに対応できるわけではないので対応待ち期間を作る。
そもそもどのアプリが使っているのかがわからないケースがあるので、移行期間を設けて問題が起こらないことを確認するという場合も。
データ参照しかされないのであれば、Viewが使えることが多い。
先にスキーマ変更してから移行期間に古いスキーマをViewで見せるか、新しいスキーマをViewとして見せて、移行期間後にスキーマを更新するかはケースバイケース。どっちでも良い。

ステージング環境は何処まで本番と同じ環境が作れるものなの？

それクラウドなら(ry
データに関しては極力本番に近いデータが望ましい。

まとめ

講演、座談会のどちらも内容が非常に濃くて大変勉強になりました。読書会の運営スタッフの皆さん、会場を提供してくださったOracleの皆さんありがとうございました。

次回は4章の「稼働環境へのデプロイ」についてです。最近、継続的デリバリーという本を読んでいて非常に気になるテーマなのでタイミングがあえばまた参加してみたいです。

2012年5月16日水曜日

CakePHP2.0の翻訳作業環境を構築する

CakePHP2.0系のドキュメントの日本語への翻訳作業が危機的状況にあるらしいので、この記事を参考にしながらひとまず翻訳作業をするための環境をMac + brewで作ってみました。

私の環境では紹介されていた手順の他にsphinxcontrib-phpdomainのインストールが必要でした。またbrewでインストールしたpythonのeasy_installを使えるようにするまでに少し嵌りました。

作業の流れ

pythonのインストール
pipのインストール
sphinxのインストール

pythonのインストール

まず、pythonをインストールします。この記事を執筆時点では2.7.3がインストールされました。

$brew install python

インストールがうまくいっているかどうかを確認するために次のコマンドを実行します。

$which python
/usr/local/bin/python
$python --version
Python 2.7.3

となっていればOKです。whichコマンドの結果が/usr/bin/pythonだった場合、Macにはじめからインストーされているpythonが参照されているので.bash_profileを編集して/usr/local/binにPATHを通して下さい。

pipのインストール

次にeasy_installを使ってpipをインストールします。私の環境ではそのままeasy_installコマンドを実行するとMacにあらかじめ入っている2.4系のpythonのeasy_installが起動しました。brewでインストールしたpythonのeasy_installを使うために、~/.bash_profileを編集してusr/local/share/pythonにPATHを通しました。

export PATH=/usr/local/share/python:$PATH

ここまででくればあとは、

$easy_install pip
$pip install sphinx
$pip install sphinxcontrib-phpdomain

とコマンドを実行してCakePHPのドキュメントをmakeできる環境の完成です。

まとめ

とりあえず、ビューのあたりでも翻訳作業をしてみようかなと思ってます。作業がかぶってる人がいたらツイッター等で連絡をもらえるとありがたいです。

2012年4月30日月曜日

CoderetreatでTDDに挑戦してきた

Coderetreat in Drecom powered by AgileSibuyaに参加してきました。

イベントの詳細については、HIROCASTERさんがここに詳しく書かれているの詳しくはそちらでどうぞ。

このエントリーでは１ヶ月前まではCoderetreatという言葉すら聞いたことなかった私がどんなことを考えながら参加していたのかをつらつらと書き綴ってみようと思います。今後、Coderetreatに興味を持った方がイベントの雰囲気をつかむ手助けになればと思います。

イベントへの参加目的

目的というほどのものではないのですが、Coderetreatへの参加を決めてから漠然と

テスト駆動開発を実践してみたい
新しい言語に挑戦してみたい（RubyかJavascript、できればHaskellとか）

ということを考えていました。特に新しい言語という部分に関してですが、自分で環境構築などをするとどんなものがいいかなど結構調べるのに時間がかかるので既に構築している人とペアプロすることで自分の環境を作る時の足がかりにできたらいいなと思っていました。

各セッションで考えたこと

4/28に実際にイベントに参加して来たわけですが、各セッションでは自分なりにテーマをもって楽しむことができました。

Session1. PHP

ペアでコーディングを進めていくにあたって、どうやって意思疎通の方法を探っている間に終了してしまいました。今振り返ると、ドライバーとナビゲーターを交代するタイミングが曖昧だったのは良くなかったなと思いました。

Session2. PHP

テスト担当と実装担当にわけて進めていきました。テスト担当者がテストを追加したらドライバーとナビゲーターをスイッチして実装担当者がテストを成功させるところまでコーディングするという流れです。

私はテスト担当だったのですが、テストデータの作り方が悪かったせいでセッション後半でテストが簡潔に記述できなくなっていきテストデータを整理するのにかなり時間を使ってしまいました。fixtureの管理は重要ですね。

Session3. PHP

このセッションでも基本的にテスト担当と実装担当にわけて進めていきました。前回のセッションで得られた教訓をいかしてテストデータも簡潔に記述でき、結果として結構順調に進めることが出来たのではないかと思います。

このセッションではテストが実装の方向性を作っていくという流れが作れたのが非常に良かったと思います。

Session4. Javascript

このタイミングで実装言語を変えてみたいと思い、Javascriptの開発環境を準備されていた方とペアを組ませてもらいました。私はJavascriptでの開発経験がとぼしかったので、テストの書き方等の基本的なことを教わりながら進めていきました。にもかかわらず前のセッションよりもさらに実装が進みました。

Session5. C#

前のセッションで違う言語でやっても案外いけると調子にのって火傷を負ったのがこのセッションでした。例によってテストを担当していったのですが、しょっぱなでデータ構造の選択をミスったため最後の段階でコーディングが複雑になりました。データ構造の選択は重要ですね。

また私の準備不足が原因で、ペアの方を待たせてしまったのが申し訳なかったです。

Session6. 不参加

HPが0に近づいた人達(?)で集まって、エクストリームフィッシュボウルをやりました。Rubyをかける人がほとんどいないのに何故かRubyを選択し、残念な結果となりましたがそれはそれで学ぶことが多かったと思います。それと最後にRSpecのモダンな書き方を実演してもらえたのが凄い勉強になりました。

まとめ

ペアプロは怖くない、むしろ楽しい。けど、ずっとはしんどい。
テストファーストによって実装は導かれるという経験ができて良かった。
あわよくば、関数型言語で導いてくれる人と出会えるといいなと思ってたけど出会えなかったのが残念だった。（同日に開催されていた名古屋の会場ではF#が猛威を奮っていたようですが・・・。）

余談

PHPのリファクタリングツールが貧弱なことに絶望して、今年に入ってからPHP用のリファクタリングツールをVimスクリプトでコツコツと作成しています。まだ機能は少ないですが順次機能追加していくので良かったら使ってみてください。

2011年12月29日木曜日

QuickRunからSQLを実行するための設定(MySQL用)

この記事は、Vim Advent Calendar 2011 の29日目の記事です。

Webアプリの開発をしていると、少し複雑なSQLを書かなきゃならないとか、開発用のデータを入れ替えたいなどSQLを実行したいと思うシチュエーションが多々あります。そんなとき、皆さんはどのような方法でSQLを実行してるでしょうか？シェルからコマンドを叩いてみたりphpMyAdminのようなWebベースのDBMSを使ったりといくつか方法があると思います。

私はシェルからコマンドを起動することが多いのですが、ほんの一瞬であってもVimから離れてシェルに戻るのが苦痛です。また、DBMSを使う場合でもVimから離れてSQLの編集を行わなければならなかったり、VimでSQLファイルを編集してからそれをDBMSにもっていったりと何かと煩雑な作業が入るのが辛いです。

そんな私のようなVimmerのためにVim内からSQLを実行するためにdbextというすばらしいプラグインがあります。このプラグインについてはここの記事などで詳しく解説されています。対応しているDBも多く機能も豊富です。

しかし、私はちょろっとSQLを実行して結果を確認してみたいだけなのであまり使うか使わないかわからない機能がごてごてあるのは好きではありません。かといってプラグインを自作するとバッファ管理やなんやらとメイン部分以外に書かなくてはいけないコードが結構多くなり、コスト対効果が悪くなくなってきます。

なんかいい方がないかと考えていたところ、普段からお世話になっているQuickRunを設定すればいけそうなことに気がつきました。

というわけで、vimrcにQuickRunでSQLを実行するための設定を追加してみました。今回は、

MySQLのみ対応
.sqlの拡張子を持つファイルを実行できるようにする
コードに埋め込まれたSQLを実行できるようにする

という内容で設定しました。設定自体は短いのですが、せっかくなので最終形にたどり着くまでにたどった過程をさらしてみたいと思います。

.sqlファイルを実行できるようにする

はじめに、vimrcにQuickRunのsql用の設定を追加します。接続設定などはこの段階ではとりあえず設定の中に埋め込んでしまい、QuickRunからmysqlコマンドを実行する一連の流れが正常に動作することを確認します。

commandの'mysql'は自分の環境にあわせて変更して下さい。また、"username"、"mypassword"、"testdb"については適宜自分の環境にあわせて変更して下さい。

この設定で重要なのは、execの%cはcommandで指定したパスに置き換わり%sはQuickRunが生成する一時ファイルへのパスに置き換えられるという点です。

これで.sqlという拡張子がついたファイルに"show tables;"のようなSQLを書いてQuickRunを起動すれば実行結果が表示されます。QuickRun便利すぎですね。

接続設定を切り離す

次に、さきほどの設定に埋め込んだユーザー名、パスワード、DB名などを変数として定義できるようにして柔軟性を持たせます。

この設定では、さきほどexecに埋め込んでいたオプションを%oに置き換えて、新たにcmdoptというキーを追加しました。%oはcmdoptで指定された式の評価結果によって置換されます。cmdoptはかなり柔軟な設定ができるのですが、今回はMakeMySQLCommandOptions()という関数を定義しその返り値を渡すように設定しました。

MakeMySQLCommandOptions()関数は、

ホスト名(g:mysql_config_host)
ポート番号(g:mysql_config_port)
ユーザー名(g:mysql_config_user)
パスワード(g:mysql_config_pass)
DB名(g:mysql_config_db)

のうち未定義のものがあればプロンプトから入力させ、定義されている場合はそれを使ってmysqlコマンドに渡すオプションを組み立てます。また、上記設定以外にmysqlコマンドへ渡したいオプション(ソケットなど)がある場合はg:mysql_config_otheroptsに設定します。

以上で接続情報の設定は完了です。

コードに埋め込まれたSQLを実行できるようにする

最後に、コードに埋め込まれたSQLを実行するための設定をします。もともとQuickRunは選択したコードだけ実行するという機能があるので、ビジュアルモードでSQLを選択して

:'<,'>QuickRun sql

と入力すれば選択した部分をSQLとして実行することができます。毎回入力するのが面倒であれば、

などとキーマッピングを設定しておけばSQLとして明示的にQuickRunを起動することができます。

まとめと今後の課題

とりあえず、以上でQuickRunからSQLは実行できるようになったのですが実際のところコードに埋め込まれたSQLは、

SELECT id, title, created
FROM posts
WHERE created BETWEEN ? AND ?

のようにプレースホルダーが含まれている場合がほとんどです。場合によっては、$beginやobj.method()のような変数や式が埋め込まれている可能性もあります。最初に紹介したdbextだとこの問題も解決されています。QuickRunを使ってこの問題を解決できるかどうかについてはこれから考えていきたいと思います。解決できれば使い勝手がかなり改善されるのではないかと思います。

参考

QuickRunの設定の仕方はヘルプにかなり詳しく書いてあるのでぜひ読んでみて下さい。また、今回下記のサイトを参考にして設定を行いました。

2011年12月24日土曜日

Vimプラグインを紹介しているスクリーンキャストを集めてみた

Vimの環境整備をしているこのプラグインをうまく使いこなすとどんな感じでコーディングできるようになるんだろう、といったことが気になるものです。そんなとき、スクリーンキャストがあるとプラグインインストール後の雰囲気がわかるので大変助かります。

そんなわけで、YoutubeにアップされているVimプラグインを紹介したスクリーンキャストを集めてみました。

個別のプラグインの紹介はここでは割愛しますが、動画の中に出てくるVimにインストールされているプラグインはわかる範囲でリストアップしてリンクを張りました。また、私は下記のすべてのプラグインを使ったことがある訳ではないので間違ったことを書いている可能性があります。もし、そのプラグインは今はあまり使われなくなったとか、他にもっと良いプラグインがあるよ等の突っ込みがあればどしどしお願いします。