「CakePHP」の記事 - Crieit

CakePHP4が出るらしいので各バージョンの歴史を振り返る

2018-11-24T22:10:28+09:00

CakePHP4がリリースされる日がもうすぐ近づいているようです。僕は今は使っていませんが、バージョン１の時代から３まで使い続けていたのでせっかくなので今までのバージョンを振り返ってみました。

CakePHP1

CRUDを簡単に構築できるスクリーンキャストが印象的で、見た瞬間に一気にのめり込んで大好きになったきかっけのフレームワークでした。当時いくつかPHPのフレームワークはありましたが、どれもぱっとせず、満足できるほど使いやすい、というものではありませんでした。CakePHPはその中でようやく使いやすいものがでてきた、という印象がありました。

Ruby on Railsを参考に作った（？）ということだったと思いますが、その甲斐もありかなり便利でその後の色々なフレームワークに影響を与えていたと思います。

コードの自動生成

bakeコマンドを使って色々自動生成してくれたため、それを修正して使ったりすることでかなり開発が早かったです。

分かりやすいファイル構成

MVCのベースとなる各ファイル自体もわかりやすかったですし、他の機能を拡張するためのコンポーネントやヘルパーなどもわかりやすく、簡単にファイル分割ができ開発はしやすかったです。

細かいバージョン

たしかCakePHP1は1.1, 1.2, 1.3という細かいバージョンでちょっと大きな機能追加があったりなどした記憶があります。（認証コンポーネントの追加やビヘイビアなど）

CakePHP2

PHP4の対応を捨てたバージョンです。結構色々とガラッと変わり、CakePHP1のプロジェクトはそのままでは動きませんでした。

今現在もかなり使われているような印象があります。baserCMSなんかもたしかこのバージョンだったと思います。１とどういう違いがあったのかは忘れてしまいましたが、何にしろ色々とちょっとずつ便利になっていたような記憶があります。これぞ、というものがあったわけではなく、１が色々検討しながら開発されたものだと思うので、色々話がまとまってきっちりした、という感じだったような気がします。

CakePHP3

Composerが導入され、モダンなフレームワークとなりました。ここでもあらゆることがガラッと変わり、CakePHP2のプロジェクトはそのまま使うことはできませんでした。多分現在CakePHP2のプロジェクトが残っているはそのあたりが原因だと思われます。

正直ここでかなり使いやすくなったので、3が使えるようになったら2を使う必要はないと思われます。とはいえ業務上アップグレードできない状況や、Composer導入や色々な仕様変更等の影響で踏み出せない勢の影響でまだまだ残っている様な印象を受けます。可能であれば3を使っていきましょう。

ちなみにこの時知りましたが、一応バージョンアップ対応用のスクリプトみたいなのを公式が作ってるんですよね。でもたいしたことはしてくれないのでほとんど意味がありませんでした。

CakePHP4

PHP7のみの対応となりました。ただ今回はそのあたりの対応がメインっぽく、それが要因となる破壊的変更以外はあまり行われず3からのアップグレードがわりと容易になるようです。軽いアップグレードが可能なのはここが初ですね。できる人はどんどんやっていった方が良いのではないかと思います。PHP5のサポートも今年で終わりですし。

CakePHPとLaravelの比較2018

2018-04-30T06:41:22+09:00

経緯

2016年に下記のようなCakePHPとLaravelの比較記事を書きました。

CakePHPとLaravelの使い道

また、こちらの記事はCakePHPのみの記事ですが完全にLaravelとの比較を意識していました。

CakePHP3の優位性を色々

この頃は正直CakePHPびいきでしたが、時も流れ色々と状況や考え方も変わってきたので改めて考察してみました。
（人によってはなんで今さらCakeとLaravelの比較なんてやってんだ、と思うかもしれませんが）

情報量

検索にしても日本語の情報が非常に少ない気がするので本当に人気があるのかと思ってしまう。

当時Laravelについては上記のように書いていました。

今はどちらも十分豊富に情報が溢れています。CakePHP3とか、Laravel5のようにバージョン込みで検索すれば紛らわしい情報も減りますし、困ったらドキュメント見れば大体分かります。

ヘルパー

LaravelのHtml, Formヘルパーはなんとなく不足している点が多いような気がする。実際使ってない人もいるようだ。 radioボタン群すらメソッド一つで作れないとは。

当時上記のように書いていたとおり、FormヘルパーはやっぱCakeの方が楽な気がします。とはいえLaravelも最低限の機能は備えており不便ではないため、そんな細かく気にするところでもないかなという気はします。LaravelはLaravelでバリデーションエラーが出た時の画面遷移等がCakePHPとは違いますが、そこにちゃんと対応できるようにしてくれていますし。

設定

Laravelは設定量が多い。パーツを追加する度にCakeだったらこんな設定しなくてもすぐ動かせるのに…。と思いながら設定をしなければならない。自由度が高いといえばそうなのかもしれないが、そんな自由度を得てまで時間をかけて開発したいのか、という疑問が湧いてくる。

これは多分Facadeの事を言ってたような気がします。Facadeを自分で作るのは確かに面倒ですが、これはテストのやりやすさにも繋がるように便利に作られてるものですし、今となってはそんな気にするようなものじゃないと思います。そもそもFacadeにする必要のないライブラリは普通に作ってしまえばいいだけですし。

CakePHPはヘルパーやコンポーネント追加していくだけのため分かりやすく楽ではあります。

あとは

ルーティングなんて設定しない

というのも書かれていますが、正直ルーティングを設定するのは他の言語も含めどのフレームワークでもあたりまえの事なのでこれも気にするようなことじゃないと思う。むしろCakePHPが特殊です。

とはいえ設定しなくても動くCakePHPはほんとに楽なのは楽です。ただ、ルーティングを設定することでresourcesの恩恵を受けられコードもシンプルになりますし、そっちはそっちでメリットは大きいです。

CakePHPがまずいのは、bakeの自動生成がresource形式になっていないこと。これがデフォルトでできたらかなり良いと思います。resource形式でないためif文なども増えてしまいますし。

DebugKit

これはCakePHPの圧勝に変わりはないです。見やすい。

追記）
最近はLaravel Telescopeというものが出た。まだ使ったことはないが、もしかしたら開発環境はこれで良いかもしれない。（本番では重いかも）

モデル

CakePHPのモデルはほんとに便利です。Laravelでも特に大きな不満はありませんが、Queryがモデルに属しておらずメソッド追加などが出来ないのがちょっと不満です。（一応設定すればできるみたいですが）

ただCakePHPのバリデーションはコードが非常に長いです。これはなんとかならないでしょうか…。

モデルは一長一短な気がします。

追記）
Laravel側にはscope機能が追加されていますので不便なく使えるようになっています。

マイグレーション

これも自動生成してくれるCakePHPを褒めちぎっていましたが、マイグレーションを書くのも今や他の言語のフレームワークも含め当たり前の事ですので普通に自分で書いています。特に気にするほどのことではありません。Laravelのマイグレーションは簡単ですぐなんとなくは覚えられますし。

先進性

JavaScriptについてはCakePHPは遅れています。LaravelはデフォルトでVueやBootstrap等が使えるためそれだけでもだいぶ優位です。CakePHPはまだjQueryでいいんじゃない？　というような空気を醸し出していて先進的とはいえません。将来どうなるのか心配になります。

他にもLaravelは色々なものと連携できるようにオフィシャルパッケージも続々追加されています。HomesteadやLaradock、簡単に認証できるSocialiteやWebpackを簡単にしたmixなど、周辺の開発環境なども色々と考慮されてきています。Laravel本家と周辺共に、みんなが開発しやすい環境を作り上げていこうという活発な姿勢が見られ非常に好感が持て、将来性が期待できます。ここは完全にCakePHPが敗北しているところです。

というか、ここだけでも今後はLaravelだけでいいかな、という感じすらします。実際、僕はもう既にLaravelしか使っていません。

今年の結論

趣味だったらLaravelを使うと知識や技術も広まりやすいので僕としては絶対的におすすめです。ただ、趣味なのでやはり好きな方を使えばいいと思います。

仕事だったら色んなフレームワーク使えた方が扱える案件や考え方の幅が広がりますので、できれば両方使ったことがあった方が良いと思います。

ただし他言語も含め、composerのようなパッケージ管理は当たり前の様に使われている時代ですので、composerを使っていないようなフレームワークはもう覚える意味はないように思います。（全て個人的な見解です）

mobageで運営していたゲームを終了させた

2018-02-14T18:32:46+09:00

概要

mobage & Yahoo! mobageで運営していたゲームを終了申請しており、ついに今月終了となった。
プログラムを見ると2014年のものがいくつかあるので恐らく3年弱くらいになるだろう。

環境

PHP (CakePHP2)
MySQL
cocos2d-x(JS)

背景

mobage等、課金システムのあるOpenSocialのプラットホームは法人でなくてはならない。
自分はフリーランスでエンジニアをしていたが、
OpenSocialのアプリで稼ぎたいと思ったので、mixiアプリが出始めた頃に法人化した。
それでmixi、GREE、mobageに登録し、それぞれアプリを出した。

mixiはまだネココさんというアプリが動いていると思う（誰もプレイしてはいないと思うが）。
GREEもネココさんを動かしていたが、サーバー代が厳しいので終了させた。

mobageはエンディングロードというRPGを出した。AndroidとPCブラウザのハイブリッド。
こちらもサーバー代が厳しかったのでさくらの安いVPSに途中で変更してほそぼそと続けていた。

終了した理由

売上はほとんど無かった。
10連ガチャが初回300円なのだが、3000円で引いているユーザーなんて見たことがない。

でも安いVPSに移動して費用的な負担はほとんど無かったので、記念にずっと残しておこうとは思っていた。
ただ、やっぱり色々懸念点が出てきたので終了することを決めた。
具体的な理由としては下記のようなもの。

問い合わせ対応が大変

基本的に問い合わせはちゃんと24時間以内に１次対応をしなければならない。
しかし、土日だってあるし仕事だってあるので毎日見てられない。
問い合わせが来たとしてもほとんどAndroid経由の営業スパムだし。

さらに、僕が普段使うPCをLinux Mintにしたことで問い合わせのソフトが使えなくなってしまった。
問い合わせが来たらWindowsに切り替えるかmacを立ちあげなくてはいけない。
正直もうだいぶ負担だった。

SSL化

いつからかChromeがSSLでない場合に警告を出すようになった。
世の中はSSLが当たり前に変わっていっている。
恐らく、そのうちChromeかmobageがSSL必須化し、SSL対応を迫られる日が来ることが予想された。

現在無料SSLができるのでそれほど技術的に問題はないのだが、
とはいえ既に稼働中のサーバーであれこれ操作するのは怖い。

それよりも一番問題なのが、先程も書いたようにLinux Mintに変えてしまったので、
開発環境をWindows側に残したままだった。
SSL対応のためにいちいちWindows（起動がすごく重い）に切り替えるのは大変。
しかも実装するとなるとまたあれこれ修正してテストもやり直さなければならない。
かなりの重労働で、ただでさえ仕事で忙しいのに厳しい。

責任

上記の問題点を考えているうちにふと思ったのが、
もし明日、明後日急にSSL必須になったらどうしよう、という思い。

もちろんmobageはちゃんとしていてそういうことは猶予をもってお知らせがあるので問題はないのだが、
例え１，２ヶ月であっても今の自分としては辛い。

そんなこんなやっているうちに対応できずSSL必須化になってしまったら、サービスは止まってしまう。
もしかすると正しく運用出来ないことで責任を追求されたりするのでは…等という考えが頭をめぐった。

サービス終了はもはや当然の決断だった。

最後の問い合わせ

不具合の問い合わせが来たのであれこれやり取りして修正した。
今回はDB側で修正すればよかったので問題なかったのだが、
プログラム側の修正が必要だったらと思うとゾッとした。
これが引き金になったと思う。

終了した

終了申請をし、課金終了の準備をしてお知らせをし、課金終了までに約１ヶ月、そこから終了までに約１ヶ月、無事終了することが出来た。
ちなみにこのあとも問い合わせ対応を行わなければならない。

ソース

公開したが、古く汚いので、動かなくて困っている、くらいの人でないと役には立たないものと思われる。

cocos側のプログラム。

GitHub - dala00/endingroad: Ending Road game client

READMEにも書いてあるが、フリー素材などは念の為再配布にならないよう全部削除している。

PHPで書かれたサーバー側は、
万が一mobageの漏洩させてはならない情報を削除し忘れて漏らしてはいけないので、
結構勢い良く適当にフォルダ毎がっつり削除した。
（それでもまだ怖いくらい）

GitHub - dala00/endingroad-server: Ending Road (server application)

もう不要だしPSR-2すら知らない頃の汚いプログラムなので何の参考にもならないが、
丸々欲しい人がいれば（機密部分は当然省いて）ゆずるので問い合わせして下さい。

一問一答

どんなゲームだったのか

当時リリースされたテラバトルを見て、これなら自分の作ったゲームも売れるんじゃないかと勘違いしてリリースした、簡易ストーリー型のステージクリア型RPG。

クソゲーだったか

プレイする人によるのではないかと思う。
クソゲーだと思う人もいるだろうし。頑張って作ったので割と遊べるのではないかとも思う。
フリー素材のクオリティも全般的に良かった。

経験値量的にすごく大変なはずなのにイベントキャラ全部最大レベルまで上げてくれた人もいた。本当に感謝。
ちなみにイベントキャラは+99するとSSRよりちょっと強い。（だった気がする）

リジェクトされなかったのか

一人で作ったので一般のアプリよりはしょぼかったと思うが、そういう理由ではとくにリジェクトされなかった。
不備があったりしたところを直していくとちゃんとリリースまで進めた。

エンディングは

実はエンディングのステージを作らずに終了してしまった。

考えていたものとしては、下記へ続いていくようなストーリー。

つまり偉い人たちが増えすぎた人間を排除するために世界は滅亡するという噂を広めた。
人々は楽園をめざすために冒険して減っていき、楽園に着いてもエルアネットに転送される。
（転送されるのか、偉い人側にいくのかは決めていなかった）

ちなみに舞台は未来の地球という設定。エアルスという名前にしようとしたが、
どうもガンダムで使われているようなのでルシアとかで想像していたと思う。

サーバー解約できて良かったですね

上記のアプリが一緒に入っているので解約できなかった…。
誰もプレイしていないみたいだし停止するか記念にGCPに移動してゼロ円運用（移動が面倒）するか検討中。

再公開はするのか

他に作りたいものがどんどん出てくるしそんなことをする暇はないので可能性は少ないが、
もし気が向いて試して一瞬で可能そうだったらやるかもしれない。
ただし可能性はかなり低い。

まとめ

一人でもソーシャルアプリは作れる。会社で複数人いるならもちろん。
こういったプラットホームは何もしなくてもインストールしてもらえるのでありがたいが、それだけでは絶対に足りない。

通常のゲームと同様、自分たちでちゃんと宣伝し、課金率も上げていかないと運営は成功しない。
やるならきちんとやらなければならない。
ゲームを作ってリリースして運用するのはとても楽しい。

技術的な話はQiitaで。

mobageで運営していたゲームのソースを公開

DockerでPHP5.5のLAMP環境を作成

2018-01-16T18:27:06+09:00

DockerでPHP5.5のLAMP環境を作成しました。

(PHP7.2のDocker環境サンプルは下記にあります)
PHP5.3のプロジェクトを7.2にした時の流れ

元々ローカル環境のまま、だましだまし動かしていましたが、シェルだとCake2のObjectクラスがコンフリクトしてついに動かなくなってしまったのでやむなく作成しました。

Dockerfile

FROM nyanpass/php5.5:5.5-apache

RUN echo 'date.timezone = "Asia/Tokyo"' > /usr/local/etc/php/conf.d/timezone.ini
RUN a2enmod rewrite
RUN docker-php-ext-install pdo_mysql mysqli mbstring

docker-composer.yml

version: '2'
volumes:
  mysql_data:
    driver: 'local'
services:
  mysql:
    image: mysql:5.5
    volumes:
      - mysql_data:/var/lib/mysql
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "true"

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mysql
      - PMA_USER=root
      - PMA_PASSWORD=
    ports:
      - 8100:80

  zenkokutenkai:
    image: Dockerfileでビルドしたイメージ名
    volumes:
      - .:/var/www/html
    ports:
      - "8050:80"
    tty: true
    stdin_open: true

こんな古いLAMPプロジェクトのためにDocker環境なんて作りたくない…とは思うのですがこういう状況だからこそDockerが役立つんですよね…。

一人もくもく会をCakePHP3のみに変更

2017-03-10T08:49:58+09:00

Angular + CakePHP3 で作成していた

一人もくもく会

だが、Angularを捨ててCakePHPのみに修正した。

お客さんのために作成したサイトでも何でもないのでSEO対策とかどうでも良かったのでAngularを入れて試したのだが、
そもそもGoogleボットがレンダリングした状態を認識すらしてくれなかった。

インデックスもされないし、コンテンツも取得されない。
流石にそれはサイトとして存在させるメリットすらないのでAngularを使うのをやめた。

Fetch as Google

Search ConsoleにFetch as Googleという機能があり、
クローラに実際にどのようにサイトが見えているかを確認できるのだが、
それを実行したところ「Loading...」のみが表示されていた。

原因

原因は不明。
ただ、公開直後はFetch as Googleでちゃんとレンダリングされていた。
途中でAngularのバージョンをあげたのでそのあたりが原因かもしれない。

原因の特定

今回は面倒だったので特定せずにCakePHPのみにした。

JavaScriptを使い、tryでエラーをcatchできるので、それで試してみると良い、とどこかに書かれていた。
結局クローラアクセスの場合だけ出るエラーなどがJavaScript上にある場合、こうなってしまうのかもしれない。
JavaScriptフレームワークでサイトを構築するときに気をつけなければならない点のようだ。

werckerでCakePHP3のカバレッジ

2017-02-26T05:54:54+09:00

CakePHP3でwerckerのCIを設定している。
カバレッジも表示したいのだが、BitBucketのプライベートリポジトリは無料でカバレッジを表示できるサービスが多分無い。

そのため別途解決策として、
出力したカバレッジhtmlを他の適当にレンタルしているサーバーなどにscpで転送することでいつでも見られるようにしてみた。

先日作成したDockerイメージを少し改良してカバレッジと転送したものを作成した。

https://hub.docker.com/r/dala00/wercker-cakephp3-coverage/

scpで転送するのでssh鍵をwerckerの環境変数に設定する必要がある。
また、pipelineの設定もする必要があるがそれらは下記のページが詳しい。

werckerを使ってBitbucketからさくらのVPSに自動デプロイ - funxion

これでビルドが実行するとサーバー上にhtmlがアップされている状態となり、
ブックマークしておけばいつでも見られる状態となる。
（単なるhtmlなので自分の場合IP制限をかけている）

CakePHP3プロジェクトをwerckerで無料CI

2017-02-23T06:04:09+09:00

werckerにて、CakePHP3プロジェクトの無料CI設定をしたログ。

良いDockerイメージがなくwercker-laravel5を参考に作成したので、
基本的には下記に書いてあることそのままで設定可能。

https://hub.docker.com/r/dala00/wercker-cakephp3/

DBのホスト名とポートが環境変数で渡されるのでapp.phpのDBのtest設定を下記のように変更。

'host' => env('MYSQL_PORT_3306_TCP_ADDR', 'localhost'),
'port' => env('MYSQL_PORT_3306_TCP_PORT', 3306),

そしてwerkcer.yml

box: dala00/wercker-cakephp3
services:
  - id: mysql
    env:
      MYSQL_ROOT_PASSWORD: rootpasswd
      MYSQL_USER: testuser
      MYSQL_PASSWORD: testpasswd
      MYSQL_DATABASE: testdb

build:
  steps:
    - script:
        name: Install dependencies
        code: |
          composer install

    - script:
        name: Run phpunit
        code: |-
          vendor/bin/phpunit

MySQLは設定がデフォルトなので、not nullカラムを無指定で保存しようとするとエラーになる。
ローカルで設定を変えていたりするとそのへんでテストの差異が出るので、
ローカルも設定を合わせたりコンテナを使って開発したりなどの注意が必要。

カバレッジが必要な場合はこちら

werckerでCakePHP3のカバレッジ - アルファブレンドプログラミングチップス

Angular2とCakePHP3を共存させる

2017-02-12T05:53:12+09:00

AngularとCakePHPを共存、つまり同じホスト名で動作させたい場合。
例えば下記のように隣同士で並んでいるとする。
Angularはビルドしたdistフォルダのみの公開でその他のソースはアップなどはしない場合。

app
dist

公開フォルダはAngular側のdistフォルダにするが、
AngularもCakePHPもルーティングが必要になるので、distフォルダ内の.htaccessで両方動作するように設定を行う。

CakePHP側は、全てapiというprefix内にプログラムを入れることで振り分けが容易となる。

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ^/api/
RewriteRule ^ index.php [L]
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]

index.phpはCakePHPのwebrootのもののパス部分の記述だけを修正。下記の2箇所。

require dirname(__DIR__) . '/app/vendor/autoload.php';

$server = new Server(new Application(dirname(__DIR__) . '/app/config'));

index.phpと.htaccessはAngularの開発時のsrcフォルダに入れておき、
angular-cli.jsonのapps.assetsの設定に含めておけば良い。

こういった方法であればホスト名も同じにできるので、SSLを2つ分とったり、などという手間をかける必要がなくなる。

一人もくもく会というサービスを作成

2017-02-11T01:22:31+09:00

一人もくもく会というサービスを作成して公開した。

一人もくもく会

概要

世の中誰でも夜暇な時に適当にプログラミングをあれこれ試す時があると思うが、
そういった時のログを投稿できるサービス。

Qiitaやブログのようにきっちりプログラムや記事を完成させなくても、
適当にどんどんその日毎のログを残すためのもの。

フレームワーク

Angular
CakePHP3

デザインはとりあえずAngular MaterialやMaterial Design Liteをごちゃごちゃに使っている。
できればAngular Materialのみでやりたかったが、こちらは現在betaで開発中のため色々足りない。
他のあちらこちらから色々使えるパーツを探してきて使う必要がある。

現状

とりあえず必要最低限以下の機能を作成しただけなので、αバージョン。
誰でもすぐGithubアカウントかTwitterアカウントでログインできるので、
気が向いた方は使っていただける状態。
0円でSSLもつけているので。

今後

作成は進めていくが、せっかくなのでその開発ログも実際にサービス上に残していく予定。
誰にも利用されなくてもデータが増えていくというのは一石二鳥だ。

その他補足色々

マークダウン

投稿はmarkdownで可能。
Github色のシンタックスハイライトも入れてある。

SPA

Angularを使っているのでSPAとなっている。
面倒なのでサーバーサイドレンダリングはしていない。
とりあえずGoogleのクローラに全部お任せ。
きっとそのうちAngular自体がデフォルトでUniversal対応してくれるだろう。

Google Analytics

SPA用にAutotrackというのがあるのでそれを使った。動いているかは不明。

ソーシャルシェア、ブックマーク

投稿データにシェア、ブックマークボタンをいくつか入れてみた。
SPA用に調整してあるので多分動くと思うがまだ記事が0なので本番では未確認。
うまく動かなかったら投稿しつつ修正していく。

ソース管理

非公開なのでBitBucket。CakePHP3のCIはCodeship。
Angularは元々テストでエラーが出まくってしまうのでエラーを取り切ってから対応予定。

不具合

いくつかある。早めに必要な機能などもある。掲載しつつ修正していく。

デプロイ

distフォルダ毎サーバーにアップすれば良いのだが、
それだけでも毎回面倒なのでデプロイ用のプログラムを作る必要がある。

ただ、各ファイルのハッシュ値はソースを変更しなければ毎回同じっぽいので、
dist毎pushしてしまえばサーバー側はpullだけでもいいかもしれない。

ちなみに、distディレクトリにCakePHP用のindex.phpが入っていて、.htaccessでCakePHP側とAngular側を振り分けている。
またこの詳細は別記事に書く。

CodeshipでBitBucketのCakePHP3のCI

2017-01-31T01:43:46+09:00

BitBucketのCakePHP3プロジェクトのリポジトリをCodeshipで無料CIを試した。

werckerを使おうと思ったのだが適したDockerイメージが無いとダメで、
適当に設定してみようと思ったがうまくいかなかったりして時間の無駄な気がしたので、
試しにCodeshipを使ってみたらすぐ動いた。

月間特定の数のビルド、等であれば無料で使える。

設定方法だが、基本的には言われるがまま設定すればできる。
php選択肢が途中であるのでそれを使えば良い。
phpunitはうまくいかなければ直接vendor/bin/phpunitに変更。

プログラム側だが、環境変数が渡されるのでDB接続情報にそれを使えば良い。

'username' => env('MYSQL_USER', 'test'),
'password' => env('MYSQL_PASSWORD', 'test'),
'database' => env('TEST_ENV_NUMBER') ? ('test' . env('TEST_ENV_NUMBER')) : 'test',

あとはpushしたりretryすれば普通に動いて完了する。

cakephp/migrationsにプルリクエストを送った

2016-12-22T05:55:55+09:00

はじめに

CakePHP3 Advent Calendar 2016 - Qiita

20日目が空いていたので。

内容

CakePHP3のマイグレーションにはmigration_diffという機能があり、
差分から自動的にマイグレーションファイルを作ってくれる超便利な機能がある。

ただ１点、
afterオプションだけ自動的につけてくれない、
という仕様だったのがずっと気になっていた。

気になってソースを調べてみると、
なんとなく可能なんじゃないか、という感じに見えた。
でも付けられていないということは何か理由でもあるのだろうか？

と思いつつ対応してみたら簡単にafterをつけることができた。
せっかくなのでテストも作成し、issueでPRしていいか聞いてみたところOKが出たのでPR。
Milestoneにも入ったので問題なければ恐らくマージされるのではないかと思う。

Add 'after' attribute to migration_diff by dala00 · Pull Request #281 · cakephp/migrations · GitHub

ちなみにafterが無いのは特に理由はなくまだだれも対応していなかっただけだった。

テスト方法

migration_diffのテストは、実行後git statusしてみるとだいたい分かるが、
マイグレーションファイルが作成され、それを想定される出力結果ファイルと比較する、というもの。
MySQLやPostgresでファイルが分かれているのでそれぞれテストして出力結果ファイルを修正する。

そのあたりをきちっとやったら後は環境依存のエラーやよくわからないものが出るので、
forkしたリポジトリをTravis CIでチェックして本家と同じ感じになればOKだと思われる。
PRした時も同様のチェックが自動的に行われる。

まとめ

せっかくのオープンソースなので気になったり不足を感じる点があったら是非PRしてみた方が良い。
あとはマージされることを祈るばかり。

ちなみに仕事場ではもう勝手に修正をあてている。
もしマージされなかったら永久に自分で修正し続けるしかない。

追記)マージされました。

CakePHP3の優位性を色々

2016-12-01T09:01:42+09:00

はじめに

この記事は下記の1日目としての投稿。

CakePHP3 Advent Calendar 2016 - Qiita

昨今は様々なphpフレームワークがある。Laravelとかは最近流行ったりしていて色々触ってみるが、
自分はやっぱりCakePHP3に帰ってきてしまう。それだけ便利で楽だからだ。

他のフレームワークには慣れているけど、CakePHPはなんか古臭くて触ってない、という人も是非一度使って見てほしい。
離れられなくなるはず。
CakePHP2以前しか使ったことがない人も一度触ってみてほしい。

では何が一体そんなにいいのか、色々と述べてみる。

ルーティングなんて設定しない

設定しない。するとしてもprefixルーティングくらい。
コントローラとテンプレートがあれば設定しなくてもアクセスできる。

もちろん、他に変えたければできる。

 'Articles', 'action' => 'view'],
    ['id' => '\d+', 'pass' => ['id']]
);

しかもテンプレート上で普通にヘルパーでリンクを作ると、勝手に設定したURLに置き換えてくれる。
変更後等もわざわざテンプレート側の調整等するのは古い時代のフレームワーク群の話。

Html->link(
    '閲覧する',
    ['controller' => 'Articles', 'action' => 'view', $acticle->id]
) ?>
出力: 閲覧する

高性能なDebugKit

こんな便利なデバッグバーは他にはない。デザインも秀逸で見やすく扱いやすい。

一番下にバーがあり、各タブをクリックすると全画面でデータが表示される。これが一番ベストだと気づいた。
CakePHP2のデバッグキットや他のフレームワークのもの等は、
下などに中途半端なサイズでドッキングしていてなんとかウィンドウにカーソルを合わせてサイズ調整したり、
両方狭い状態で操作したりするのはストレスになるだけで完全に時間の無駄だった。

テンプレートにsetされた変数はここで見られる。非常に見やすい。

SQL。

時間やメモリ使用の流れも見られる。

その他定数定義やrequestオブジェクトの中身、セッション等も見られる。
一度慣れたら他のフレームワークで開発する気にはなれない。

ORMがすごい

Articles->find()
foreach ($articles as $article) {
    $article->title;
}

// 実は$articlesはQuery。配列じゃない。なので使いまわせる。
$allCount = $articles->count();
$articles->where(['category_id' => $categoryId]);
$countInCategory = $articles->count();
// ResultSetに変換
$this->set("articles{$categoryId}", $articles->all());
// 配列に変換
$this->set("array{$categoryId}", $articles->toArray());

echoするとクエリになるのでそのままサブクエリで使える。

Articles->Comments->find()
    ->where([〜〜〜〜]);
$articles = $this->Articles->find()
    ->where(["($sub) > 5"]);

それぞれのデータはEntityなので例えば下記のようなメソッドを追加すると

private) {
        return '非公開';
    } elseif ($this->company) {
        return $this->company;
    } elseif ($this->name) {
        return $this->name;
    }
    return '未登録';
}

テンプレートは下記だけでいい。今の時代フレームワークを使ってるのに同じif文を複数のテンプレートに大量に書くなんてことはまさかしないだろう。

user->display_name ?>

bakeでコード生成

昔はコントローラもモデルも自分で一から書いてもさほど変わらない、というところがあったが、
今は設定なども増えて便利になっているので、bakeするのがかなり効率的。というかコントローラとモデルはすべてbakeで作るべき。
テストの雛形も作ってくれるし、そもそも記憶を頼りに適当に作ると変な設定を書いてエラーになってしまったりする。

モデル

TableとEntityが作られる。

Tableでは基本的な設定、コンポーネントのロード、DBを元にしたカラムやリレーションの設定、
バリデーション、データチェックの設定などが自動で作成される。
NULLでないカラムは必須項目に設定されたり等する。

Entityは特にたいした設定は行われないが、
passwordカラムがあったりするとjson_encodeした際に含まれないような設定を追加してくれていたりする。

コントローラ

特に設定しなければCRUDアクションが勝手に作られる。
特に拘り不要の管理画面などであればbakeだけで作れるし、
そうでなくてもベースに使えるのでかなり楽。

テンプレート

こちらもbakeで作成したコントローラそのままで使ったりするのであればそのまま使える。
Bootstrapのプラグインもあるのでそちらを使うことも可能。
まあテンプレートは必要であれば使う、と言ったところか。

その他

なんでもかんでもbakeで雛形を作ってくれる。
コマンドオプションも色々見てみると楽しい。

APIとしてjsonを使いたい時

デフォルトでは特に何もする必要はない。普通にindexとかviewのアクションにAcceptヘッダーとしてapplication/jsonを送ればhtmlでなくjsonが返ってくる。

URLを変えたり状況によってjson用のresponseをreturnしたりするコードを書くのは昔の時代のフレームワークの話。もちろんそういったこともできる。

(実際にはそういった設定があるのだが、初期化時点でその設定のコードが入っている)

マイグレーションの便利な機能

phpMyAdminで適当にテーブルを構築しておけば、コマンド一発でマイグレーションファイルを作ってくれる。すごく楽。
稼働中のプロジェクトにマイグレーションを途中から導入することも問題ない。

自分で書いて、抜けが見つかったらrollback&migrateでテスト中のデータとか一旦空になったりとか、面倒じゃないんだろうか？

初期化。

bin/cake bake migration_snapshot Initial

差分のマイグレーション作成

bin/cake bake migration_diff NameOfTheMigrations

マイグレーションファイルが増え過ぎたらマイグレーション関連データとファイルを削除してまたsnapshotすれば１ファイルにまとまる。

まとめ

他にもアソシエーション関連機能は便利だし、優位性関係なく非常に便利な機能が揃っている。

やっぱり仕事を早く効率的に終わらせたいなら、phpフレームワークの中ではCakePHP3が一番いいのではないかと思う。（個人的意見）

追記）
そして2018年にこういうのを書きました
CakePHPとLaravelの比較2018

CakePHP3とLaravel5のマイグレーション比較

2016-10-15T00:52:18+09:00

phpのフレームワークには大体マイグレーション機能がついている。
業務でアプリケーション開発を行う時は各開発者のローカルの開発環境、サーバー上の開発環境、ステージング環境、本番環境などと分かれていたりするため、
そういった場合はマイグレーションを使用すると本当に楽。

なので使うのは使うのだが、正直あまり好きではない。
rollbackして再度migrateしたら一度データは消えてしまうし、
本当はRidgepoleのように完成形だけ保存して勝手にその形に合わせて欲しいというのが本音。

ただ、必ずしもそうできるというわけではないので、それでも使うのであればなるべく楽したい、
ということでCakePHP3のマイグレーションの便利さをLaravel5と比較してみる。

Laravel5のマイグレーション

Laravelのマイグレーションは必要なものは揃っていて、基本という感じ。
seedもあるのでデータの初期化もできる。

雛形作成

php artisan make:migration add_votes_to_users_table --table=users
php artisan make:migration create_users_table --create=users

実際の処理書き込み

$table->string('name')->nullabel()->after('id');

実行

php artisan migrate

特に迷うこともなく簡単。
その他にもいくつか機能はある。

CakePHP3のマイグレーション

基本的なところは大して変わらない。
だが、いくつか便利なものがある。

差分から勝手にマイグレーションファイル作成

なんと、最後のマイグレーションと現在の構成を比較し、
勝手にマイグレーションファイルを作成してくれる。
phpMyAdminで適当にカラム追加したり調整したりして
最後に実行すればいいだけ。すごく楽。

bin/cake bake migration_diff AddFlagToTable

afterだけ自動ではないので自分であとで付ける。

これも間違いがあった場合はrollbackで戻せる。

またこの機能のため、現在の構成をダンプデータとして保存しておいたり、
マイグレーション済みとしてマーキングしたりすることも可能なので
適宜その時の状態に応じて調整できる。

マイグレーション無しで進めてしまったアプリケーションも後付でマイグレーション方式に変更できる。

コード書く量を減らして早く仕事を終わらせよう。

CakePHP3でアソシエーションが保存されない

2016-09-22T07:20:53+09:00

CakePHP3は単なるエンティティの保存もアソシエーションを含む保存も全てsaveメソッドで行う。
しかしなぜかこの関連データが保存されない場合があった。

原因を探ってみるとdirtyが無かったため。
Users hasMany Itemsの場合であれば

$user->dirty('items');

とすればuserに変更が無くてもitemsが保存される。

CakePHP3でEmailのfromの共通設定をDBで指定する

2016-09-07T06:23:21+09:00

CakePHP3はapp.phpにてメール送信のfromのデフォルトを簡単に設定できる。

固定ならそれで問題ないのだが、問題はDBの設定でfromを指定したい場合。

bootstrap.phpを見てみると、app.phpの設定はConfigure::consumeで削り取られており、
あとでConfigure::writeをしてもfromを動的に反映させることができない。
Emailのクラスを見ても設定できる方法はない。

しかしよく見ると、EmailにはStaticConfigTraitが使用されている。
これを利用することでfromのデフォルトを動的に指定することができる。
下記のようなコードをアプリケーションの共通処理で行っておけば良い。

$keys = Email::configured();
foreach ($keys as $key) {
    $emailConfig = Email::config($key);
    $emailConfig['from'] = $config->from_setting;
    Email::drop($key);
    Email::config($key, $emailConfig);
}

設定は変更できないので、丸々入れ替える形。

CakePHP3のテーブルにprefixを使う方法

2016-07-15T23:21:07+09:00

CakePHP2まではDB設定でprefixが使用できたのだが、
何故か3になってから設定がなくなっている。
テーブルクラスにそれぞれ設定していくのが普通だが、

bootstrap.phpのuseをたくさんしている箇所に

use Cake\Event\EventManager;

末尾に

EventManager::instance()->on('Model.initialize', function ($event) {
    $instance = $event->subject();
    if (strpos(get_class($instance), 'DebugKit') === false) {
        $instance->table('myapp_' . $instance->table());
    }
});

でもできる。

ただし何かのライブラリ等でModel.initialize前に処理をしている場合にはエラーになるので、
テーブル毎に設定するのがかたそう。

CakePHP3ページネーション時にhead内にSEO対策のlinkタグを挿入する

2016-06-30T05:56:03+09:00

ページ分けをする際、それらのページは一連の同じページであることを示すために
headタグ内に下記のようなタグを挿入する。
下記のような感じ。

CakePHP2のころからあったようでそちらのマニュアルには書かれているのだが、
下記をheadタグ内に入れておくだけで可能。
defaultレイアウトに入れておけば良い。

Paginator->meta() ?>

Hierselectプラグインの作成

2016-06-21T06:24:35+09:00

HierselectのjQueryプラグインを作成した。
Hierselectというのは、例えばプルダウンで大、中、小カテゴリを選択する際に、
大カテゴリの選択によって中カテゴリプルダウンの中身を属するもののみに更新し、
さらに中カテゴリの選択によって小カテゴリのプルダウンの中身を更新、
のような機能。

他にも同様のプラグインがあったのだが、
phpで作成したselectタグではちょっと使いにくい部分があったので作成した。

GitHub - dala00/jquery-hierselect: Simple jquery hierSelect plugin

上記のスクリプトさえ読み込んでおけば、
javascriptで設定する必要は無くHTMLだけで動作させることができる。
サンプルは下記。

https://dala00.github.io/jquery-hierselect/

下記のような感じでdata属性を追加するだけで良い。

CakePHPで利用

本題として、CakePHPで簡単に動作させたかったというのがある。
CakePHPでは通常のリスト配列でなく、
['text' => '....', 'value' => '...', 'data-category-id' => ***]
の配列を渡せば良い。

この２つを組み合わせることで簡単に(?)Hierselectを動作させることができるようになる。
プロジェクトごとに何度も書くのが面倒なのでプラグイン公開してみただけ。

CakePHPとLaravelの使い道

2016-05-11T06:34:18+09:00

2018年版も書きました。
CakePHPとLaravelの比較2018

ずっとCakePHPを好んで使ってきたが、Laravelがすごく人気が高いとのことなので使用してみて色々と比較。

情報量

Laravelはドキュメントのどのページを見ても何か説明が足りない気がする。
人のパッケージのソースを見たり検索で情報を探したりしなければならない。
情報が見つかったあとドキュメントを見てみたらやはり書かれていなかったりする。

検索にしても日本語の情報が非常に少ない気がするので本当に人気があるのかと思ってしまう。

ヘルパー

LaravelのHtml, Formヘルパーはなんとなく不足している点が多いような気がする。
実際使ってない人もいるようだ。
radioボタン群すらメソッド一つで作れないとは。
そのため比較するとCakePHPのヘルパーはかなり充実しているのだと実感した。

設定

Laravelは設定量が多い。
パーツを追加する度にCakeだったらこんな設定しなくてもすぐ動かせるのに…。
と思いながら設定をしなければならない。
自由度が高いといえばそうなのかもしれないが、そんな自由度を得てまで時間をかけて開発したいのか、という疑問が湧いてくる。

用途

上記から、まずCakePHPとLaravelは開発するアプリケーションの用途が異なると思う。
DBテーブル量の多い昔ながらのFormベースの大きな基幹システム開発を行うのであればCakePHP3一択かと思う。

逆に、スマホアプリ用のサーバーアプリケーション開発や
ReactやAngular等のコンポーネントベースライブラリを使った開発などであれば
テンプレートはほとんど必要なくAPI開発に重点を置くことになってくるので
この場合はLaravelが非常に適していると思う。

まとめ

ちなみにさくらのレンタルサーバー等はそのままではCakePHP3が使えないのだが、Laravel5.0は使用できる。
しかしそれでも基幹システムはCakePHP2を使った方がまだましのように思えた。

Laravelしか使ったことない人、CakePHP2しか使ったことない人、
フレームワーク自体未経験の人は是非下記も見てほしい。

CakePHP3の優位性を色々

CakePHP3のテスト時にBehaviorによるエラー

2016-04-16T01:49:59+09:00

CakePHP3でテストをする際、突然大量のエラーが発生することがあった。
その直前にやったことといえばBehavior関連のテストの作り込み。

関連するテストが２箇所あるのだが、その両方を実行するとエラーになり、どちらかだけコメントアウトするとエラーが出ない。
両方が相互に絡み合ってエラーになっているらしい。

調べてみると、そのテストはファイル関連のbehaviorを使ったテストだったため、
behavior側にファイル操作関連の設定をできるようにしてテストを用意にしていた。
通常は呼ばれないのだがテスト用にだけ必要なメソッドを使っていた。

どうもテストが変わってもその設定が保持されてしまっているらしく、２回めに呼ばれたテストがエラーになってしまっていたらしい。
もちろんtearDownでモデルはunsetしている。それにもかかわらず。

どうもBehaviorはTable内に直接保存されているわけではないのでunsetだけでは他のテストに影響する状況が残ってしまうらしい。
テスト終了時に設定を元に戻す処理を実行するとエラーが出なくなった。

ちなみに、BehaviorはBehaviorRegistryに登録されており、
これはTableRegistryと同様ObjectRegistryを継承しているのでresetメソッドを使うことでも対応できそうな気がする。
（試してはいない）