Technote

これまでCakePHP2用のデータジェネレータプラグインとして開発を続けてきたFabricateをV2として各種ORMへ対応するようなコアモジュールへと変更しました。 またFabiricateリポジトリのmasterブランチへは統合されていませんが、CakePHP3のリリース時期を合わせて、V2ブランチを本流にする予定です。 これまでのCakePHP2用ライブラリはcakephp2ブランチでメンテナンスを続ける予定です。

データジェネレータって何？誰得？という方は、以下の投稿を一読していただけると理解が深まります。

• テストデータの作り方 - 第73回 PHP勉強会

FabricateはRubyのFabricationとFactory_Girlに影響された「fixtureはDRYではないので、Fixture replacement を使おう」という流れに乗ったPHPクローンです。

Version2を作成するきっかけ

このキッカケはいくつかあります。 1つには昨年の CakeFest2014 で Fabricate の LT をした後で、 CodeIgniter の開発者だったことでも知られるPhil Sturgeon から、「これいいね、他のフレームワークでも使えるようにしてよ」と言われたことでした。 他のフレームワークでも使えるようにしたいという思いは、少しあったのですがまだ確約できなかったので「maybe」と返しただけでした。（このときPhilはかなり酔っていたので、私に話した事を覚えているのかどうかも怪しいですがw）

さらにもう1つおおきなキッカケがCakePHP3でのPSR対応によって、namespaceなど外部ライブラリを使いやすくなり、さらに外部ライブラリからフレームワーク本体のコードへのアクセスしやすくなったということがあります。 CakePHP2ではフレームワークへアクセスするにはアプリケーションまたはプラグインでないと困難で、特にORMに依存したライブラリをフレームワークをまたいで作成するのは困難でした。これがPSRの対応でやりやすくなったということ、CakePHP3への対応に合わせてV2を作って、他のフレームワークにも対応できるようにしようと思ったのです。

Fabricate V2の主な変更点

Fabricateの利用方法はほとんど変わっていませんが、各ORM用にアダプターと呼ばれるORMの差分を吸収するクラスを準備する必要があります。 Fabricateの本体にはFabricate\Adaptor\FabricateArrayAdaptorという連想配列構造を返すサンプル用のアダプターを用意しています。これを参考にアダプターを実装すればDoctrineやPropel、YiiやCodeIgniterでも利用可能になります。

アダプターの実装方法

とはいえ実際にORMに接続するアダプターもないと、ということでCakePHP3用のアダプターCakePHP Fabricate Adaptorも作成しました。

ここではCakePHP3のアダプター実装を例に、アダプターで何を実装しなくてはいけないのかを解説したいと思います。

作成するクラス

アダプタークラスはFabricate\Adaptor\AbstractFabricateAdaptorクラスを継承します。

<?php
use Fabricate\Adaptor\AbstractFabricateAdaptor;

class CakeFabricateAdaptor extends AbstractFabricateAdaptor
{
    ...
}

実装するメソッド

アダプターとして実装する必要があるメソッドは以下の3つです。

• getModel
• create
• build

それぞれのメソッドの実装を確認しましょう。

getModel

getModelメソッドは各ORMの差分を吸収するためのモデルインスタンスを返却するデータジェネレータの定義部分です。 データジェネレータとしては最も重要な機能です。

<?php
use Fabricate\Model\FabricateModel;

public function getModel($modelName)
{
    $model = new FabricateModel($modelName);
    $table = TableRegistry::get($modelName);
    $schema = $table->schema();
    foreach ($schema->columns() as $name) {
        if ($this->filterKey($table, $name)) {
            continue;
        }
        $attrs = $schema->column($name);
        $options = [];
        if (array_key_exists('length', $attrs)) {
            $options['limit'] = $attrs['length'];
        }
        if (array_key_exists('null', $attrs)) {
            $options['null'] = $attrs['null'];
        }
        $model->addColumn($name, $attrs['type'], $options);
    }
    foreach ($table->associations()->keys() as $key) {
        $association = $table->associations()->get($key);
        $target = $association->target();
        $className = get_class($target);
        $alias = $target->alias();
        switch ($association->type()) {
            case Association::ONE_TO_ONE:
                $model->hasOne($alias, $association->foreignKey(), $className);
                break;
            case Association::ONE_TO_MANY:
                $model->hasMany($alias, $association->foreignKey(), $className);
                break;
            case Association::MANY_TO_ONE:
                $model->belongsTo($alias, $association->foreignKey(), $className);
                break;
        }
    }
    return $model;
}

getModelはFabricateModelクラスのインスタンスを生成する責務があります。 FabricateModelはPHPのマイグレーションツールであるPhinxに影響を受けていて、スキーマの定義方法が似ています。

<?php
// Phinx
$users = $this->table('users');
$users->addColumn('username', 'string', array('limit' => 20))
      ->addColumn('password', 'string', array('limit' => 40))
      ->addColumn('password_salt', 'string', array('limit' => 40))
      ->addColumn('email', 'string', array('limit' => 100))
      ->addColumn('first_name', 'string', array('limit' => 30))
      ->addColumn('last_name', 'string', array('limit' => 30))
      ->addColumn('created', 'datetime')
      ->addColumn('updated', 'datetime', array('null' => true))

// FabricateModel
$users = new FabricateModel('users');
$users->addColumn('username', 'string', array('limit' => 20))
      ->addColumn('password', 'string', array('limit' => 40))
      ->addColumn('password_salt', 'string', array('limit' => 40))
      ->addColumn('email', 'string', array('limit' => 100))
      ->addColumn('first_name', 'string', array('limit' => 30))
      ->addColumn('last_name', 'string', array('limit' => 30))
      ->addColumn('created', 'datetime')
      ->addColumn('updated', 'datetime', array('null' => true))

利用できるカラム型はPhinxと同様で、オプションについて現時点ではlimit(長さ)のみ対応しています。

CakePHP3では

<?php

$table = TableRegistry::get($modelName);
$schema = $table->schema();

という記述でスキーマ情報が連想配列で取得できるので、それを繰り返してaddColumnを呼び出しています。

スキーマ定義を作成したら、次にモデルの関連を定義します。 モデルの関連定義は、以下のようにassociationを使って関連構造を一度に作成する場合に必要となります。

<?php
Fabricate::create('Users', function($data, $world) {
    return [
        'username' => 'taro',
        'posts' => $world->association('Posts', 3),
    ];
});

この例のように関連を設定するには、以下のようにFabricateModel::hasMany()やbelongsTo()を使います。

<?php
$users->hasMany('posts', 'post_id', 'Posts');
$posts->belongsTo('users', 'post_id', 'Users');

パラメータの指定方法は、hasManyもhasOneもbelongsToも同じで、(別名、外部キーカラム名、モデル名）を指定します。

create

createメソッドは、Fabricateによって生成された連想配列構造のデータを、ORMを使ってDBに保存する機能を実装します。

<?php
public function create($modelName, $attributes, $recordCount)
{
    $table = TableRegistry::get($modelName);
    $entities = $table->newEntities($attributes, ['validate' => $this->options[self::OPTION_VALIDATE]]);
    $table->connection()->transactional(function () use ($table, $entities) {
        foreach ($entities as $entity) {
            $ret = $table->save($entity);
            if (!$ret) {
                return false;
            }
        }
        return true;
    });
    return $entities;
}

$modelNameにはFabricate::create('Users',と記述した場合の、Usersが渡ります。 $attributesには生成された連想配列が渡ります。例えば以下のとおりです。

<?php
array (
  0 => 
  array (
    'title' => 'Lorem ipsum dolor sit amet',
    'body' => 'Lorem ipsum dolor sit amet, aliquet feugiat. Convallis morbi fringilla gravida, phasellus feugiat dapibus velit nunc, pulvinar eget sollicitudin venenatis cum nullam, vivamus ut a sed, mollitia lectus. Nulla vestibulum massa neque ut et, id hendrerit sit, feugiat in taciti enim proin nibh, tempor dignissim, rhoncus duis vestibulum nunc mattis convallis.',
    'created' => '2013-10-09 12:40:28',
    'updated' => '2013-10-09 12:40:28',
  ),
  1 => 
  array (
  ....

$recordCountは生成する件数ですが、この値はcount($attributes)の値と一致します。 CakePHP3では以下の流れでDBへ保存しています。

• TableRegistry::get()でテーブルインスタンスを取得
• Table::newEntities()で連想配列からエンティティを生成
• Table::save()でエンティティをDBに保存

build

buildメソッドは、Fabricateによって生成された連想配列構造のデータから生成したエンティティを返却する機能を実装します。

<?php
public function build($modelName, $data)
{
    $table = TableRegistry::get($modelName);
    $entity = $table->newEntity($data, ['validate' => $this->options[self::OPTION_VALIDATE]]);
    return $entity;
}

$modelNameにはFabricate::create('Users',と記述した場合の、Usersが渡ります。 $dataには生成された連想配列が1インスタンス分だけ渡ります。例えば以下のとおりです。

<?php
array (
  'title' => 'Lorem ipsum dolor sit amet',
  'body' => 'Lorem ipsum dolor sit amet, aliquet feugiat. Convallis morbi fringilla gravida, phasellus feugiat dapibus velit nunc, pulvinar eget sollicitudin venenatis cum nullam, vivamus ut a sed, mollitia lectus. Nulla vestibulum massa neque ut et, id hendrerit sit, feugiat in taciti enim proin nibh, tempor dignissim, rhoncus duis vestibulum nunc mattis convallis.',
  'created' => '2013-10-09 12:40:28',
  'updated' => '2013-10-09 12:40:28',
)

さいごに

現在CakePHP3用のアダプターしかないので「xxxx ORMについてアダプター実装したよ！」という連絡を待っています。 Fabricateのcomposer.jsonのsuggestに追加してPull Requestをもらえるととても助かります。

    "suggest": {
        "sizuhiko/cake_fabricate": "for integration with CakePHP3"
        // ここに追加したPRをお待ちしています
    }

皆様のPull Requestをお待ちしております！！

この投稿は2014年参加／発表したり、運営に携わったイベント、やっていた仕事の内容などについてふりかえるポストです。

1月

2013年から年末の忘年会が少なめで、2014年から新年会が異常に多いという現象になりました。 ちなみにこれは2015年も同様で新年会がいっぱいです。新年から1年をなかったこと（忘れる）にできるぐらいです。

まだタイトルもなく、何も中身も決まっていなかった CakePHPで学ぶ継続的インテグレーション 本（以降 CI本 ）が動き出したのでした。

当時のブログサイト My Opera Blogがもうすぐ終わりだ、やべーと言いながら、Co-Edoで何にしたら良いかなーと頭を悩ませていたのでした。

2月

非常に忙しくCakePHPの案件支援をしており、毎日ピリピリしていた記憶が….。仕事では人材の流動性の高まりを感じでいたのでした。

バグフィックスに対応した Fabricate 1.1.1 をリリースしました。

Bddプラグインのインストールをしようと思ったら、php-object-freezerが見つからないエラーで失敗するように なんとPHPUnitプロジェクトにあったリポジトリがpearからもgithubからも、世の中の公開リポジトリから一切いなくなったのでした。 これはforkして使っているSpec for PHPの依存ライブラリなので、しかたなくコードをlibの下に展開してSpec for PHPに同梱するようにしました。

CI本は主にチャットワークで作業が進み、目次を考えていました（まだ決まってはいない）。

いよいよ My Operaの終了までカウントダウンということで、ブログをMiddlemanに移行しました。 記念すべきMiddlemanでの一号記事 Hello Middleman!

3月

3/12 Web生誕25周年でした。 またそれに関連して「HTML5 Japan Cup 2014」が開催されることになり、ボランティアスタッフとしてハッカソンや審査などに関わるようになりました。

3/8 Co-Edoにてたまっていたブログネタを一気に3本投入しました

• Middleman インストールメモ
• VagrantでComposerからPHPUnitをインストールするときに注意したいこと
• CakePHPで動的にプレフィックスルーティングを追加したときに気をつけること

3/18 テスト駆動web開発勉強会 Vol.1で発表しました。 そういえば、Vol.2が開催されないなーとか思うのでした…

Middlemanに移行してブログ書くぞーと熱が上がっていたので、さらに一本 Composerのautoloadを使いこなす を投下。

3/25 第76回 PHP勉強会 に参加しました。確かHTML5 Japan Cup2014の告知をしたと記憶しています。

CI本は大筋が決まって、いざ書くぞーというモードになるのでした。

4月

4/4 今も続くCakePHP3もくもく会#3に参加しました（ブログ記事）。このとき初めてCakePHP3に触れたのでした。

4/9 はもちろん4q!カンファレンス。今年も盛り上がりましたー

4/12 Test the Web Forward Meetup (仮), Tokyo #2 に参加しました（ブログ記事）。私はShadow DOMに興味があったので、そのテストコードを書くチームに参加しました。帰宅後もいくつか作業をすすめ本家にプルリクエストが取り込まれるなど、Contributeしたぞーという気持ちが高まったのですが、その後あまり作業できていません。HTML5の仕様テストに興味はあるので、今年も少しずつ取り組みたいなーと思っています。

5jCupはスタッフ顔合わせがあったあと、すぐに第一回のアイデアソン／ハッカソンがあり、どちらもスタッフとして参加しました。

全然活動と関係ないのですが、その頃ちょうどいつも聴いているJ-Waveで流れていたY.I.Mのkonsaiという曲にはまって何日も頭をリピートしていたのでした。今でもたまに聴いてなごみますw

CI本は5jCupの繁忙期と重ならないように、なるべく早めにと思いちゃくちゃくと原稿を進めるのでした。

4/28 第77回 PHP勉強会に参加し、もくもく会でCakePHP3に触った話をしました。

5月

5/19 CakePHP もくもく会 に参加しました。

5/21 CakeDC/Migration プラグインがアップデートされ、generateコマンドでいろいろごにょごにょできるようになり、とても便利になったのでした。すぐにプロジェクトでもアップデートして記法を取り入れました。

後はひたすら仕事が忙しく、平日夜中や土日はほぼCI本の原稿を書いていた記憶が….

6月

イベントにたくさん参加しました。

• 6/12 - 6/13は毎年恒例のInterop
• 6/16 CakePHP 3.0.0 もくもく会（勉強会） #5 （ブログ記事）
• 6/23 【祝9周年】第79回 PHP勉強会
• 6/28 PHPカンファレンス関西

Fabricate1.2をリリースしました。主な機能追加は

• configで主キーを割り振らないようにするオプション
• Fabricate::define() のクローン
• Fabricate::association() のクローン
• Fabricate::trait() のクローン

これらでだいぶFabricator/FactoryGirl の実装に近づきました。

CI本は書きたい事は書ききって、全体の流れを整える調整が..

7月

5jCupはいよいよ審査モード。スタッフが集まって一次審査を行いました。大量に集められた審査用のガジェット（機器）など、作品も沢山寄せられてあっという間に時間が過ぎました。 そして、7/26 には表彰式が行われ、今年も前半戦イベントの幕が閉じたのでした。

7/29 CakePHP 3.0.0 もくもく会（勉強会） #6に参加。

いくつかのバグフィックスをしたFabricate1.2.1をリリースしました。

CI本は大大リファクタリング大会で、毎週末とても大変だったなぁ〜

8月

今年もCakeFestに参加しました（ブログ記事）。初スペイン（まぁだいたいどこへ行っても初なのですがw）。

Fabricateを遅まきながらTravis.ci対応したので、CakePHPのプラグインをCIする方法についてブログ記事を書きました。

CI本は校正をしながらいよいよ大詰め！

9月

原稿からも解放され、たくさんのイベントに参加しました。

• 9/4 CakePHP 3.0.0 もくもく会（勉強会） #7（ブログ記事）
• 9/6 俺のXP祭り
• 9/19 CakeFest報告会
• 9/25 HTML5とか勉強会
• 9/29 第82回 PHP勉強会

そしてついに、9/19 CakePHPで学ぶ継続的インテグレーションが発売されました（ブログ記事）。

10月

先月同様にイベントに参加したり、発表したり楽しかったー

• 10/9 10q!カンファレンス
• 10/11 PHPカンファレンスで発表（ブログ記事）
• 10/25 俺聞け10（急遽空手形で発表、Should Beeをアピール）
• 10/27 第83回 PHP勉強会
• 10/30 HTML5 デバイスAPI勉強会

そして毎年恒例のアレ（カレンダー）のイラストが原稿終わった後にあるのでした..

11月

いよいよ渋谷の支援案件も残りわずかとなりました。

• 11/17 CakePHP 3.0.0 もくもく会（勉強会） #9
• 11/25 HTML5とか勉強会

カレンダーデザイン終わり！

12月

12月から半分はJavaの新規案件のお手伝いにも行っていました。

12/23 にCakePHP 3.0.0 感謝祭 & もくもく会（勉強会） #10と同時開催（フロア別）で、『CakePHPで学ぶ継続的インテグレーション』ハンズオンセミナー を開催しました（私はサポート役でしたが…）。

例のCI本のハンズオンですが、まだ2回目ということでちょっと練度が足りなくて、参加者の皆様は若干消化不足だったかもしれませんが、またリクエストもありますので、ぜひ今年もやりたいと思います。

12/24 に渋谷の支援を1日残していますが、感謝のLT（ブログ記事）をしました。

まとめ

たくさんブログ書くぞーと言っていたくせに、14本しか書けませんでした。 執筆とかイベントスタッフとかあると、なかなかなー。わかってはいるのですが。

今年はもう少し情報公開できるだろうか。CakePHP3の新しいネタとかイロイロ書けそうですしね。 そうそう今日CakePHP3はRC1になりましたね。CakeFestもちょっと早めの5月末ニューヨークだそうですよ。ぜひ行かねば。

直近でいうと1月末にHTML5カンファレンスがあって、今年もスタッフ参加しますので、会場でお会いできればと思います。

さらには1月末に伊良部大橋が開通するので宮古に行きたいとか（これは完全に趣味ですが）。

今年もイロイロなイベントに参加したり、橋見に行ったり、また機会に恵まれれば執筆したりと変わらず活動していきたいと思いますので、皆様よろしくお願いいたします。

2014/12/24 に行われた【12/24 クリスマスイブ】第85回 PHP勉強会でLTをしました。

当日はもの凄く楽しく盛り上がったので、私が発表を開始する頃には会場の終了時間ギリギリになっていました。 このため高速LTで話していろいろ溢れた話などを記事にまとめます。

CakePHPを使った開発現場での481日間の支援

コンサル会社からご指名でお話をいただいたら、コミュニティの知り合いの会社でしたよ、というなんか遠回りな形で始まったお仕事でした。

まず参加して感じたのは、481日前のスライドにあるように、これはなかなか手強いなーという状況でした。 コンサルの方からイロイロ事情を聞いていたので、ある程度覚悟はしていったのですが、まずの印象はチーム開発ができていないなーという印象。ここでいうチームとは、誰かが指示して動くというよりは、全員の力で進んでいくアジャイルチームをイメージしています。 良い意味で言うとウォーターフォールのやり方としては、文化があってうまく進めている状況でした。

とはいえ最初に見た手順書とかコードとか、もっと優先してやらないといけなそうな事がたくさんあったので、スライドの順に対策を計画し、開発しながら改善活動をゆるやかに進めるということになりました。

できたこと と できなかったこと

かなり大きな案件だったため、複数のサブシステムがあり、スライドの対象は私が直接関わった2つについて支援した内容です。 ただ、施策のいくつかは全体として取り入れてもらったりして、現在も継続しています。

できたことについては、スライドに含んでいるので、ここではスライドに含められなかった、主にできなかったことについて書きたいと思います。

• デプロイの自動化
• 環境毎の設定切り替えの仕組み
• 共通化されていたコードの改善
• プロダクトオーナーとの関わり方
• more チーム

まずデプロイについては、独自の方法で半自動化されていました。 ここで列挙したのは、デプロイにcapやjenkinsを使ったりは「しなかった」という意味です。このあたりの改善はすでにワークフローとして機能しているものを改善すべきか、どこまで文化に踏み込むかという判断が必要になると思います。 本案件ではスクリプトを実行するのは手動ながらも、それによる問題はなさそうだったので、そのまま継続しています。 ただCI、インテグレーション、ステージング、本番とある内のインテグレーションだけはJenkinsと連動して自動デプロイできるようにしても良かったかなーと今頃思っていますが、まだいるメンバーの方、これを読んだらTRYしてみてください。

環境毎の設定切り替えの仕組みはあったのですが、当初設定を追加するのにExcelファイルを編集しないといけなくて、ひどく苦労しました（Excelファイルだと差分がわからないし）。現在はテキストファイルを直接編集して良い方式となり、これも全サブシステムに影響する箇所で対策がしにくくそのまま継続利用しました。 CakePHPだとCI本でも解説した CakePHP Environmentsプラグイン を使えると良かったのですが。ここはいずれCakePHP3対応するのであればプラグインに切り替えられると良いなーと思います。

上記と同じような理由で、すでに全サブシステムで共通化されていたコードの改善もあまり手が付けられませんでした。サブプロジェクトによって進捗具合が異なり私が入った段階ですでに多くの機能ができあがっていたサブシステムもあり、多くの共通部分は未着手のままとなりました。 一方で、できたことのほとんどは、まだ実施されていない自動テストだったり、サブシステム単位で改善できる箇所からの着手となったため、このような結果になっています。

プロダクトオーナーとの関わり方については、これはどの現場でもそうですが、開発からのアプローチだけではなかなか改善が難しい部分です。文化を変えるには内側からの大きな力だったり、より大きな成功体験を求めるといったことが必要となるのではないかと思います。 もしこのあたりを改善したいという現場があれば、プロダクトオーナーを含めてふりかえりをやって、ProblemとTryを共有して改善していくと良いと思います。でも大規模システムでは… なかなかに難しいですね…

moreチームということでは、最初に関わったサブシステムのチームでは、見積もりゲームをやって、カンバンを導入し、よりチーム力で進めたと思います。そのまま継続してやってくれると良いなーと思っています。私が離れてからもメンバー間でPull Requestに活発にコメントされていたし、とてもうまく廻っているという印象がありました。

一方でその後に担当したサブシステムは、かなり複雑な事情で始まりました。チームの力を付けながら進むというよりは、とにかく完成を目指すような形でしたので、チーム力という意味ではまだ道半ばだったかもしれません。 あと、年末に様々なイベントが不運なタイミングで重なってしまったのも、多少心残りですが、残ったメンバーの力を合わせて進めていって欲しいです。

さいごに

私はいろいろなところで揉めるというか、正論でズバズバ行くタイプなので衝突することが多かったと思います。 今回支援させてもらった現場では、派遣の方が多く、そういう意味でチーム力で進めていくのはとても困難な状況であったと思います。 特に社員ではない働き方を選んでいる人の場合、もの凄く前のめりでやりたい人と、3歩後ろをついていきたい人に別れると、これまでの経験で感じます。私もそういう意味では前者になる訳ですが…

例えばチーム全員で要求を仕様にブレークダウンして見積もりゲームをやったり、相互にコードをレビューしたり、これはAgile開発の文化にない開発者にとって、全員が望んでいる方法でないというのは、気持ちでは理解できます。 が、これをやらずに属人性を排除し、チームとしてより良く開発を進めていく方法が現時点ではあまり思い当たりません。 特にWeb界隈では人の流動性も高いので、極端に生産性を落とさない為にも、コードや仕様を引き継ぐというために時間を取られるといった事はできれば避けたいはずです。

このプロジェクトを通じて、テストデータジェネレータ Fabricate も作ったし、多くの実践投入実績や経験も得ることができました。

まだ現場では開発が続いており CakePHPで継続的インテグレーションを導入したモダンで大規模な開発 を継続しているという、貴重な体験ができていると思います。 そういう意味で、誰か事例発表をすると良いなーと思いますので、今年のPHPカンファレンスなどで話が聞けるのを楽しみに待っています。

そして、PHP勉強会の2日後、2014/12/26をもって、作業支援から離れました。

最後にステキなお花と色紙をいただきました。

本当にありがとうございました。引き続き開発頑張ってください！！

2014/10/11 に行われたPHPカンファレンス2014で発表をしてきました。

Photo by gihyo.jp

スライドは以下の内容です。

PHPカンファレンスでは公募セッションは最大30分のため、なぜ今回このようなタイトルを発表しようと思ったか、という背景については話ことができませんした。こちらのブログでは、スライドの共有と共に、その辺りの経緯について書いておきたいと思います。

なぜ今オブジェクト指向か？

オブジェクトデザインは原著から数えると、もう12年になろうとする訳です。これはセッションの中でも話したのですが、2003年当時はまだWebのフレームワークもまだ今日のようなものでなく、多くの会社は各社オレオレフレームワークを作っていた時代です。 オブジェクト指向が必要ないような使い捨てサイトならまだしも、受託やサービスなどソースコードを維持したり、機能アップをするような場面ではオブジェクト指向が必要だと考え、今のアジャイルムーブメントかそれ以上に語られていたはずです。

オレオレフレームワークを作ったことがある人は、オブジェクト指向やデザインパターンをよく勉強してそのあり方を議論したものです。 そのような人たちが、現在の入門プログラマーに「オブジェクト指向がわかってない」と言っても、そもそも通じないと思ったのがきっかけでです。

ここ4,5年の間にWebからプログラミングを始めた人（Webフレームワーク世代）は、すでに素晴らしいWebフレームワークがあり、その上でプログラミングをすることを要求されます。言語そのもの、たとえばPHPなら「イラストでよくわかるPHP はじめてのWebプログラミング入門」や「よくわかるPHPの教科書」あたりを読んでから、各フレームワークの本や公式チュートリアルを片手にアプリケーション開発を始めています。 つまりオレオレフレームワーク世代のオッサンが通過したオブジェクト指向やデザインパターンの経験に基づいてソースコードに手厳しいコメントを付けても、受けた方も辛いだけなのです。

今どのような弊害が起きているのか

で、このようなWebフレームワーク世代はCakePHPやその他のWebフレームワーク（MVC的なもの）を使って、MVCの枠に収めようとしてFatコントローラになったりしやすいのです。 なぜなら特定のディレクトリにフレームワークが指定した方法で書いていれば、良くわかんないけどうまく動いてしまうのです。フレームワークすげーな！という訳です。 それ以外の書き方は知らないし、どこにも書いてないのです。 結局、適切にクラス分割ができないため、結果として与えられた範囲の枠組みで問題はない、と考えているような状況を見かけるのです。 classってPHPの文法です、キリッ！とか言われたことはないですが、まぁ無くはないのかな…と。

じゃぁフレームワークの本に、その概念や考え方を書くべきだという声もあるかもしれません。私もCakePHP本の執筆に携わったことがあり、耳の痛い話です。しかしフレームワークの本では、すべてのフレームワークについての説明もページ数的に困難な中、OOPやMVCの概念のような内容を解説するのは困難なことも事実です。

そこで話してみようと思った

もちろん、オブジェクト指向ムーブメント世代のオッサンであってもオブジェクト指向をみんな理解しているかというと、そういう訳ではありません（まぁ少なくともみんな読書会なんかして勉強はしていたような気がします）。 今時のWebフレームワーク世代だって、しっかり勉強している意識高い人はいっぱいいるし、知っています。 ただ最近プログラミングを始めた人は、技術の移り変わりが激しいし、言語やフレームワークはどんどんバージョンアップするし、なかなか基礎的な事に対する勉強時間を作るのが難しいのではないかな、と思うのです。 しかもオブジェクト指向の勉強って難しいし「銀の弾丸」は無いわけです。最近そういった勉強会の話もあまり聞きません。 ではどのあたりから始めると良いだろう？という当たりを付けられるセッションをしてみたいと思ったのです。

私が技術支援で入った中で良く感じている問題はオブジェクト指向プログラミングというより、そもそものオブジェクト指向がうまく理解されていないと思ったので以下のポイントに絞った内容にしたいと思いました。

• オブジェクトとは何なのか
• オブジェクトを導出するにはどうしたら良いのか
• 今回のPHPカンファレンスのテーマは「知りたい，があなたを変えていく」

これらの要件に合うのは、責務駆動設計の中心的原理とテクニックを解説した「オブジェクトデザイン」の紹介が最適で、30分という時間に適している（知りたい==何か持ち帰って始めることができる）と思ったのです。

どうだったか

セッションをやっている間、いつも盛り上がっていないと不安なので、小ネタを差し込むのですが、皆さん真面目に聞きに来ていただいたので、講演者から見るとダダ滑りでした（個人的な感想です）。ただjoind.inのコメントを読ませていただいたり、顔見知りの方に確認した範囲では何かしら体験を持ち帰っていただけたようで「知りたい」につながったのかな、と思っています。

もし私の講演を聴いていただいてコメントまだな方は、コチラに一言いただけると嬉しいです。joind.inは匿名でのコメントもできますので、ご安心ください。

また、今回の目玉？！セッションであった「ウェブエンジニアに必要なセキュリティスキルとは 徳丸浩 x 大垣靖男」の対談セッションでも思ったのですが、お二人の話の大きな相違点のベースである現実論と理想論のケースはセキュリティだけではなく、オブジェクト指向についても同じだな、と思いました。 私はすべての人がオブジェクト指向を理解して進めるのが理想だと思うし、アジャイル原則の私たちはオブジェクト指向を理解しているプログラマーであるべき、と思っています。ただすべての人がそうでないというのも理解できるので、理解度はともかくオブジェクト指向と向き合って欲しいなと思っています。そこから何かが変わると良いな、と。

裏話

実は、セッションを応募するとき、PHPカンファレンスでは重複して申し込めると聞いていたので、オブジェクト指向超入門（上）と、オブジェクト指向超入門（下）の2セッションにして合わせて60分で申し込もうと思ったのですが、それは通らなそう(www)と思って自重しました。 またどこかで60分セッションやれる機会があれば、やってみたいなと思うのでした。

9/19に茅場町Co-Edoで行われたCakeFest2014報告会でも話した内容をベースに記事にしました。

すでに同日に発表された@yandoさんの記事「マドリードで見たCakePHP3の明るい未来」が秀逸なので、CakePHP3の動向についてはその記事をご覧ください。

では私は何を書くかというと、報告会でも話したCakeFest2014の全体感と、来年10周年を迎えるCakePHPを盛り上げる為にみんなでCakeFestに行こう！という気分になってもらえると良いな、というまとめになっています（ちょっとはCakePHP3についても書くよ）。

CakeFestの歴史

CakeFestは2008年に始まって、今回で8回目になります。 参考URL:lanyrd.com

• 2008/02 フロリダ・オーランド
• 2008/12 ブエノスアイレス（参考URLの年は間違っています）
• 2009/07 ベルリン
• 2010/09 シカゴ
• 2011/09 マンチェスター
• 2012/08 マンチェスター
• 2013/08 サンフランシスコ
• 2014/08 マドリッド

初年度を除いて、およそ1年に1回世界中からコミュニティのメンバーが集まるお祭りです。

2回目のブエノスアイレスを除いてアメリカとヨーロッパで開催されており、私が始めて参加した4回目のシカゴからは8月終わりor9月初めに開催されるようになりました。 コアデベロッパーは家族や彼女と来ていたりするので、夏休みも兼ねているのではないか、という緩いイベントだった..だったのです。

緩い理由は例えば2012年(マンチェスター)のスケジュールを見てもらえるとわかりますが、9時に始まって16時ぐらいには終了です。このときは2トラックだったこともあり、セッション数としては少なくはないのですが、泊まりのカンファレンスイベントとしては割とあっさり終了する感じです。このあとはLTやりたい人がいればやるみたいな、日本のキッチリしたイベントの仕切りやテキパキ感というよりは参加者がお茶やビールを片手に交流する時間がたっぷり取られているという感じだったのです。

2014年は違っていた

私もCFP（Call For Paper）にセッションの応募をしたのですが、落選してしまいました。 で、確定したスケジュールを見て、ビックリしたのです。 朝は9時からと例年通りですが、終わる時間が！！なんと21時ですよ。つまり12時間。これはちょっとしたPHP Matsuri状態ではないですか。

今年はシングルトラックでしたが、あんまりBreakタイムがなかったので、各自の判断でカンファレンスルームの外で話したりしていた状況ではありました。

なお私が知る限りのCakeFestの中では、最もイベントとしてのテキパキ感とかはあったように思います。これもコミュニティマネージャであるJames Watts氏の活躍があってこその事。CakeFestの仕切りも3回目という事でだいぶ慣れてきたのかなーとも思います。

CakePHPの中の人たち

そういえば、あまりCakePHPの中の人たちって使っていてもCakeFestに参加しないと知らないのではないかと思い、コアチームのメンバーの顔と名前が一致するように、2枚の写真で紹介します。

photo by Anna Fillina.

左からJames Watts、Jose Gonzalez(@savant)、Larry Masters(@phpnut)（敬称略）

こちらの写真は私がスペインに到着した夜の出来事なのですが、まぁお酒もだいぶ入っているところでの余興みたいな感じだったのでしょう。私はフライトの疲れでビールを1杯飲んで部屋に戻ってしまったので見ていなかったのですが、こんな感じでホテルのバースペースで盛り上がったり、そのあと朝4時まで繁華街へ飲みに行ったりしていたみたいです。 毎年朝方まで飲んでいる参加者がいるのもCakeFestの一部です（その影響か午前中はホテルの部屋から出て来ない人も多数ですがw）。

で、写真の後どうなったか、というとコチラの動画から確認できます。

ここ数年はコアチームへのQ&Aセッションがあります。こちらでもCakePHPの中の人たちを確認することができます。

photo by Anna Fillina.

左からMarc Ypes(@ceeram)、Mark Story、Mark Scherer(@dereuromark)、Larry Masters(@phpnut)、José L. Rodríguez(@josezap)、Jose Gonzalez(@savant)、Renan Gonçalves(@renansaddam)、James Watts（敬称略）

CakePHP1.3の終了と2系の今後

Q&Aセッションはカンファレンス1日目のお昼直後に実施されたのですが、午前中にMark Story氏からCakePHP3の話と、1.3のサポート終了の話があったので、その2つについて質問が集中していました。1.3のサポート終了に関しては、何とちょうど先週顧客にCakePHP1.3を使った案件の提案をしたばかりなのに、どうしたら良い？何とかならないの？！というビックリするようなQを聞きました。先日も1.3のアップデートがあったり、1.3自体非常に長い間使われているのだなぁと思いました。その後、質問をした人になんでこれから1.3使うの？と聞いたら、資産があるから、という事でした。 こちらのAは、ベストな方法はマイグレーションすることだけど、3ではなくCakePHP2にするのが良いという話と、1.3の件は通常のCakePHPとしてはムリだけど、CakeDCとして考えられなくもない。まぁビジネスだね、という回答でした。 とはいえ、たぶんCakeDCも1.3の面倒を見続けるのは現実解ではないので、マイグレーションのサポートをする事で解決をするのではないかなーと思われます。

日本でもまだCakePHP1.xを使っているサイトなど残っていると思いますが、3へのジャンプは難しいと思うので、まず2系にしておくことが重要になるでしょう。 2系についてはまだ3年はサポートと今回明言されています。じゃぁまた3年後には3にしないといけないの？！という話はあるかもしれませんが、1から2系へはアップグレードシェルがあるのと、3のアップグレードシェルができたとして、2系からのアップグレードのみ対応であると推測されるので、まずは2系なのかなと思います。これは上記のコアチームのQ&Aでの回答からも妥当な判断と思います。

CakePHP3で気になっていたこと

CakePHP3のもくもく会で、何度もCakePHP3を試しているのですが、昨年ビヘイビアって無くなるって言ってなかったか？と思い、ORM担当の大きいJoseこと@jose_zapに確認しました。答えとしては、いろいろ考えたけど、コールバックの関係もあって互換性を考え残すことにした。もちろんTraitにしてEventマネージャを使うアプローチは素晴らしいし、できればそちらを使ってほしいけど、コアとしてはビヘイビアも残すよ、ということでした。

恒例のリアルケーキ

今となっては恒例となったリアルケーキ。実はCakeFestで始めてケーキが登場したのは、2010年のシカゴだったと記憶しています。 キッカケは日本で開催されたCakePHPカンファレンス東京で、当時のCakePHP開発マネージャだった@gwoo氏を招いてCakePHP型のケーキを出したのがとてもウケが良く、それが本家でも採用されたと。CakeFestには日本コミュニティのDNAが含まれています！

この直後、コアチームとして新しく入った@dereuromarkがファーストバイトならぬカップケーキ投げの手荒い歓迎を受けたり、サプライズイベントがあったり、楽しくケーキを食べながら交流を深めて解散となりました。

CakeFest2014で感じたこと

CakeFestに参加すると、良く知った常連さんと、始めての人がいて、なるべく始めて会った人と話すようにいつも心がけています。

各国でのCakePHPの普及状況や、コミュニティの活動などの話を聞くのですが、ドイツから参加してきていた人の話によると、CakePHP(PHP)のイベントをやりたいけど、なかなか人が集まらなくて苦労している。日本ではどうなの？という話から、日本の状況を説明すると、とても日本のコミュニティが羨ましいという感想をもらいました。これはドイツ以外の参加者からも同様の反応をもらったのですが、まぁ日本というか東京など都市部には人が密集していてやりやすい状況なのかな、とも思います。そういった環境面やコミュニティ活動を積極的にやってくれる人がいるので都市部のエンジニアは特に恵まれた状況だと思います。もっと勉強会やイベントに出て交流しましょう！

今年は(も)シングルトラックだったのでほぼ全てのセッションを見る事ができたのですが、CakePHPと関連するセッションは、コアチームに集中していて、他のセッションはPHP全般だったり、JavaScriptだったり、HTML(CSS)だったりとCakePHPに関する話題は例年以上に少なかったような気がします。 これはCakePHP2のライフサイクルがだいぶ長くなっていて新しい話題が少なめなのと、まだ3は早すぎるという状況もあったのではないかと思います。 来年はコアチーム以外からも3の話題がもっと出てくるのではないかと思います。

CakeFest2014のjoind.inにスライドのリンクがあるので、ぜひCakePHP3のセッションについては見て欲しいのと、公式のPodCastが配信されているので、そちらも聞くとCakePHP3について理解が深まると思います。

CakePHPに関する話題以外で、ぜひスライドをチェックして欲しいのは

• Writing code that lasts presented by Rafael Dohms
• Why You Can’t Test presented by Chris Hartjes

どちらもPHP界では有名人で、同じ内容を各国のカンファレンスで講演しているので、どこかで見ているかもしれませんが、一度はチェックしてみてください。

LTもやったし、BDDプラグインの人として声をかけられたり、交流できた

また初日のLTでData Generator for Testing CakePHP Application（いつものテストデータの作り方の英語バージョンです）をやりまして、反響もたくさんもらいました。 CakeFestのスピーカーの中には、特にCakeと関係ないけどPHPのセッションとして応募してくる人もいるので、他のフレームワークには対応しないの？とか、Fakerと連動するにはどうするの？などなど。 CakeFestではLTは当日募集で、手を挙げればもれなく喋れるので、海外カンファレンスでのプレゼン登竜門としては最適と思います。

それと自分の自己紹介スライドのアイコンから、BDDプラグインの人でしょ？と声をかけられたりもして、Breakタイム少なかった割によく話したなーという印象でした。

また例年以上？に日本自体に関心がある人がいて、日本語喋れるノルウェーからの参加者（漫画大好き）だったり、日本食について聞いてくる地元スペインの人だったり、3次会でカラオケ行こうと誘われたり、フクシマの話をしたり、PHP以外の話でも交流ができました。

「海外のカンファレンスとか行ったことないし、大変そう」という方がほとんだと思います。私もお世辞にも英語得意でない（割と適当）けど、何とか交流できています。CakeFestであれば、ここ数年@yandoさんや私が参加していますし、行きたいと宣言すれば一緒に行く人が見つかるかもしれません。

もし会社勤めのエンジニアだと休みが取れない、経費出ない、など難しい事情があるかもしれないのですが、ぜひ上司と交渉して来れるようになると良いなと思っています。参加して得られることは文章では書けないぐらい大きいです。

コミュニティマネージャからのメッセージ

最後にコミュニティマネージャであるJames Watts氏から、キーノートに関連して日本のコミュニティへメッセージをいただきましたので、動画をシェアします。 では来年のCakeFestで会いましょう！

最初のトラブルは、テラスの石畳と砂利の間に足を取られて転びそうになったのです…