「コード」カテゴリーアーカイブ

FuelPHP 複数データベースへの migration


FuelPHP で複数データベースへ migration を行うやり方を説明します。 FuelPHP 1.7.2 を想定しています。

FuelPHP では php oil g model item name:string などのようにすると、 model と migration のためのコードが生成されます。 php oil g scaffold ... とやった場合にも migration のコードが生成されます。 ここで生成される migration コード に手を加えることで 複数データベースに対応させることができます。

変更前のコード

変更後のコード

db_config_key というのを付け加えました。 このパラメータでデータベースを指定できます。 具体的には config/db.php 内 のキーになります。 たとえば 'default' なんてのが入ります。 何も指定がなければ 'default' が採用されます。

このようにして複数データベースに対応させることができます。 migration の コードごとに データベースを書き換えればいいですからね。

Model の コードを活用した書き方

Model を利用してやってみましょう。

Model_ItemOrm を使っているという前提の話ですが、 データベースの指定に Model_Item::connection() を、 テーブルの指定に Model_Item::table() を、 主キーの指定に Model_Item::primary_key() を使っています。 このようにすると、 model の中に書いておけば migration のコードを変更しなくても済みます。 (ただし 既存テーブルについて model の テーブル名や $_connection を変更する場合には注意が必要になります。)


DIxAOP の Java Framework, Spring


Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

DIxAOP ってなんだ? と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAADDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。

Spring の特徴

Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。

Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。

オブジェクトのライフサイクルの問題
オブジェクトの生存期間をコントロールする作りこみが困難
部品化の問題
部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
技術隠蔽や不適切な技術隠蔽
高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。

Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。

Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です!)。 コードの例もあり、全体的にしっかりした印象を受けます。

以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。

アプリケーションアーキテクチャ

プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。

  • ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
  • 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ

この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。

アーキテクチャに求められるもの

  • 開発効率
    • 意図を把握しやすく、理解しやすい構造
    • テストが容易に行える構造
  • 柔軟性
    • 変更しやすく、機能追加しやすい構造
    • 将来の環境の変動に耐えられる頑健な構造

ティアとレイヤ

Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。

ティア

クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。

各ティアの例
クライアント層 パソコン、スマートフォン
中間層 アプリケーションサーバ
EIS層 DB、レガシシステム

レイヤ

EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。

トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。

Spring3 入門 (技術評論社)
Spring3入門 を Amazonで買う

テスト駆動開発でのテストコードの育て方


Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う

参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。

今回はテストのエッセンスについてです。 テストを書いて、実装コードを書き、機能追加していく中で需要なポイントを拾って書きました。 テスト駆動開発でテストを先に書く手順の続きになります。

Assert を先に書く

テストを書くときは Assert から書くのがいいそうです。 確かに、 ゴールから決めるのは常套手段ですね。

Assert から始めるに当たって、 まず考えるのは次の2つです。

  • What is the right answer? (どうなったら正しいといえるのか)
  • How am I going to check? (どうやってチェックするのか、何の値をチェックするのか)

本書に載っている例を見ると、 上の2点から始めて Assert 部分 から 存在しないクラスを使ってテストを書き始め、 最終的にテストを完成させているのがよくわかります。

テストデータ

Kent Beck によれば テストにおいて使用するデータにも鉄則があります。 わかりやすいもの、 すなわち 1 でも 2 でもよいのなら 1 を使うんだとか。

またシステムによっては 実データをテストに使うこともあると思いますが、 Kent Beck は実データは特に次のようなケースで有効であると述べています。

  • 実稼働している他のシステムで出力されたデータを使うリアルタイムシステムのテストをする場合。
  • 変更前のプログラムと変更後のプログラムによる出力を比較する場合。

特に難しい話ではありませんが、 一旦整理して頭に入れておきましょう。

テストの実装ルール

テストコードは一般的なプログラミングルールを逸脱することがあります。 例えばマジックナンバー。 というのも、 テストにおいては実装コードを完成させることと テストによるフィードバックを必要なだけ得られるようにするのが目的だからです。 MONEY EXAMPLE の章でもありましたが、 まずマジックナンバーを使うことで ひとまずのテストを完成させていました。

もういちど MONEY EXAMPLE の章で列挙されていた方法について説明されています。 Fake ItTriangulation がありますが、 一番最初におさえないといけないのは Fake It です。

Fake It (‘Til You Make It)

英語版102ページでは python でテストフレームワークを作っていたときの実例が紹介されています。 テストコードが Fake からどんどん変わっていく部分が再掲されています。

Kent Beck は Fake It のメリットとして次の2つを挙げています。 2つめのは 少し前のページにも出てきていました。

  • まずテストをグリーンにすることでコードに確信がもてる。 余計な心配をしなくていい。
  • わかりきったものでもテストを書いてグリーンにしておくことで、 今どの機能が足りていないかをわかりやすくする。

そこから Triangulation の話へと続きます。 内容は MONEY EXAMPLE で出てきた話の復習です。 復習なので割愛します。

パラメータを増やす場合

テストが完成した後で機能を追加する例として sum(int value) から sum(int[] values) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。

Test-Driven Development By Example (Kent Beck)
Kent Beck の Test-Driven Development By Example を Amazon で買う