CakePHPとLaravelの比較2018

経緯

2016年にこんなCakePHPとLaravelの比較記事を書いた。

CakePHPとLaravelの使い道

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

CakePHP3の優位性を色々

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

情報量

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

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

今はどちらも十分。CakePHP3とか、Laravel5とかで検索すれば紛らわしい情報も減るし、困ったらドキュメント見れば大体分かったりする。

ヘルパー

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

当時上記のように書いていたとおり、FormヘルパーはやっぱCakeの方が楽な気がする。とはいえそんな細かく気にするところでもないかなという気はする。

設定

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

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

でもまあCakeはヘルパーやコンポーネント追加していくだけだからほんとに楽ではある。

あとは

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

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

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

CakePHPがまずいのは、bakeの自動生成がresources形式になっていないことだ。これがデフォルトでできたらかなり良い。

DebugKit

これはCakeの圧勝に変わりはない。

モデル

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

ただCakeのバリデーションはコードが非常に長い。これはなんとかならないかな。

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

マイグレーション

これも自動生成してくれるCakePHPを褒めちぎってたが、マイグレーションを書くのも今や当たり前の事なので普通に自分で書いている。気にするほどのことでもない。

先進性

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

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

というか、ここだけでも今後はLaravelだけでいいかな、という感じすらしてきてしまう。

今年の結論

趣味だったらLaravelを使うと知識や技術も広まりやすいのでおすすめ。

仕事だったら色んなフレームワーク使えた方が扱える案件や考え方の幅が広がる。ただし他言語も含め、composerのようなパッケージ管理は当たり前の様に使われている時代なので、composerを使っていないようなフレームワークはもう覚える意味はないように思う。(全て個人的な見解)

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

概要

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

環境

背景

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

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

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

f:id:dala:20180208221803j:plain

f:id:dala:20180208221839j:plain

終了した理由

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

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

問い合わせ対応が大変

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

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

SSL

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

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

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

責任

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

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

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

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

最後の問い合わせ

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

終了した

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

ソース

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

cocos側のプログラム。

GitHub - dala00/endingroad: Ending Road game client

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

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

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

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

一問一答

どんなゲームだったのか

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

クソゲーだったか

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

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

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

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

エンディングは

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

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

エルアネット - Google Play の Android アプリ

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

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

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

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

再公開はするのか

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

まとめ

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

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

技術的な話はQiitaで。

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

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

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

元々ローカルのPHPのままだましだまし動かしてたのだが、 シェルだとCakePHP2の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

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

幼稚園用達成ボードアプリを作成

概要

タブレット向け幼稚園用達成ボードアプリを作成した。 (単なるWEBアプリ)

https://child-achievement.alphabrend.com/

適当に作ったのでBitbucketは使わずGithubで公開している。

GitHub - dala00/child-achievement: Achievement for children

経緯

息子の発達が遅れており、 幼稚園で勝手にうろうろしたり指示を聞けなかったりするので、 少しでも頑張る気持ちを増やせないかと作成した。

特徴

報告画面

f:id:dala:20171117215035p:plain

  • タブレットなので楽しい
  • 簡単タップ操作のみ
  • Google認証のため誰でも使用可能
  • 発達が遅れている子向けのためそうでなければ簡単すぎて楽しくなさそう

集計画面

f:id:dala:20171117215410p:plain

  • 30回達成(1日最大6項目)するとレベルアップするので楽しいかもしれない
  • 週ごとの集計なので早く推移が分かってやる気が出るかもしれない

開発環境

ほんとはElixir & Phoenixで作りたかったが、デプロイに時間がかかる可能性があった。 作っている間に幼稚園を追い出されたら意味がないのでとにかく早く作ることを目的とし、 ぱぱっと設置できるphp5.6のさくらレンタルにLaravel5.4で作って入れた。 (それなのに本質とは関係ない認証導入でちょっとてまどってしまったが…)

まとめ

息子にやらせていたら2歳の次男もやりたそうに騒いで大変だった。

マルチアカウントなのでやらせることは可能なのだが、 そもそも幼稚園向けの項目しかないのであまり意味がない。

すると妻がちゃちゃっとコピペみたいな感じで流用できるんだから用意してあげたら、 みたいなことを言ってきて顧客にはしたくないなと思った。

最終的にアカウントIDで項目を変更できるよう修正した。(設定機能はない)

werckerでCakePHP3のカバレッジ

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制限をかけている)

さくらの共用レンタルで.php.htmlが表示できない

さくらの共用レンタルだと、phpunitで出力したカバレッジファイルなどの.php.htmlという拡張子のファイルにアクセスすると

Premature end of script headers

というエラーが出る。

必要なフォルダ内の.htaccess

RemoveHandler .php

とすると正しく表示できるようになる。

Linux Mint 18でmailtodisk

Linux Mint 18でxamppに入っているmailtodiskと同じことができるようにした。 多分Ubuntu16あたりでも同じだと思う。

詳しくは

php - Use of mailtodisk / mailoutput in XAMPP for Linux - Stack Overflow

にかかれていることそのままなのだが、例えば下記のようなファイルを作成する。

/usr/local/bin/mailtodisk (実行属性を忘れないように)

#!/usr/bin/php
<?php
$input = file_get_contents('php://stdin');
$dir = '/home/yourname/Documents/mailoutput/';
$filename = $dir . 'mail-' . gmdate('Ymd-Hi-s') . '.txt';
$retry = 0;
while(is_file($filename))
{
    $filename = $dir . 'mail-' . gmdate('Ymd-Hi-s') . '-' . ++$retry . '.txt';
}
file_put_contents($filename, $input);

そして上記の$dirで保存フォルダを指定。 保存フォルダに書き込み属性を忘れずに。

あとはphp.iniのsendmail_pathに上記スクリプトを指定すれば良い。 apache用とcli用の2つがあった。

sendmail_path = /usr/local/bin/mailtodisk

さらに下記のようなものを以前作ったので、 localhost以下に適当に配置してブックマークしておけば簡単にメールを見たり削除したりできる。

GitHub - dala00/MailoutputViewer