1 2 3 4 5 |
$master = [ '' => '----', '0' => 'aaa', '1' => 'bbb', ]; |
とかの時
1 |
var_dump($master[null]); |
ってやると
1 |
string(4) "----" |
こうなるんだね、初めて知った。
1 2 3 4 5 |
$master = [ '' => '----', '0' => 'aaa', '1' => 'bbb', ]; |
とかの時
1 |
var_dump($master[null]); |
ってやると
1 |
string(4) "----" |
こうなるんだね、初めて知った。
まずDBにテーブルを作成する。
※例えばusers
テーブルを作成する。
んで次のコマンドを実行。
1 2 3 |
php bin/cake.php bake controller Users php bin/cake.php bake model Users php bin/cake.php bake template Users |
これでCRUD機能の完成。
PHPで画像周りの操作をする際はよくGDエクステンションを用いるが、GDの基本リサイズ関数であるimagecopyresized()
は縮小した際のジャギがひどく全くもって使い物にならない。
一応フィルタでスムージングもしくはガウシアンぼかしを適用できるが、やるだけ無駄。
そして多少結果がマシになるimagecopyresampled()
という関数も用意されているがこれもゴミ。~~ホントゴミ~~。
ということでこれからはPHPで画像の操作をする場合はImageMagick
を用いよう。(強制)
ようはGDより高性能で使いやすいいわゆる神エクステンション。100種類を超す形式の画像読み込みや変換に対応しており、WEBで扱うであろうファイル形式は当然いける。詳細は下記リンク。
http://php.net/manual/ja/book.imagick.php
yumを使おう。
1 |
$ yum list installed | grep php |
1 |
$ yum search imagick --enablerepo=remi | grep php |
php56-php-pecl-imagick-devel.x86_64
をインストールする。
1 |
$ yum install -y php56-php-pecl-imagick-devel.x86_64 --enablerepo=remi |
※ココから先は環境に依存する(?)場合あり。
imagick.so
をPHPのインクルードディレクトリにコピーしてやる。
※自分の場合は下記の感じ。
1 |
$ cp /opt/remi/php56/root/lib64/php/modules/imagick.so /usr/lib64/php/modules/imagick.so |
1 |
$ vim /etc/php.d/imagick.ini |
1 |
extension=imagick.so |
そしたらhttpdを再起動
phpinfo()
にて下記のように表示されていればインストール成功。
とりあえず当初からやりたかった画像のきれいなリサイズと切り抜きをやってみた。 今回は元画像の縦長、横長にかかわらず正方形になるようトリミングし、指定のサイズに縮小する処理を行いたかったのでそれをやる。
1 2 3 4 5 |
$thumbnail = new \Imagick(); // Imagickオブジェクトを生成 $thumbnail->readImage($image_path); // 入力画像パスを指定 $thumbnail->cropThumbnailImage(300, 300); // 縦横のピクセル指定 $thumbnail->setImageFormat('jpg'); // 出力フォーマットを指定 $thumbnail->writeImage($output_path); // 画像の出力パスを指定 |
これだけ。イヤほんと簡単。しかもめちゃくちゃキレイ。かなり最適化されてる。 ジャギが全く無いしGDはでスムージングを行なった処理と比較しても格が違う。そもそもの画像処理アルゴリズムが違うんだろうけど、GDがどれだけクソかわかる。
しかもサムネイル作成用の関数が用意されていて長さ指定するだけで中央から綺麗にトリミングしてくれるという至れり尽くせりっぷり。画像のフォーマット別に読み込み関数が分かれていない点も最高に使いやすいし、今後画像処理はImagickで行うことを確信した。
PHP5.4から実装されたClosure::bind()
を用いる。
たとえば下記のようなコード。
1 2 3 4 5 6 7 8 9 10 11 12 |
class hello { private function world() { echo 'hello World'; } } $class = new hello(); $class->world(); |
当然Fatal error: Call to private method hello::world() from context
と怒られる。
しかしClosure::bind()
を次のように用いると。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
class hello { private function world() { echo 'hello World'; } } Closure::bind(function() { $class = new hello(); $class->world(); }, null, 'hello')->__invoke(); |
なんと画面にhello World
が表示される。
第1引数に渡した関数内の処理は、第3引数に渡した名前のクラス内で実行されているものとして扱われるため、正常に関数を呼び出すことができている。
そう、Closure::bind()
は無名関数に限り実行時コンテキストを動的に変更できるというチート機能を有しているのである。
これを応用すると、PHPUnitでのテストケースにおいてもprivateな関数をテストすることができるようになるため、非常に強力な機能の一つであると言える。
Xdebugがインストールされている環境でvar_dump()
を使用すると、なんだか無駄にごちゃごちゃしてて挙句の果てにはmore elementsとかいう世紀末な状態になっていたので戻す方法をメモ。
php.ini
に下記を追記。
1 |
xdebug.overload_var_dump = 0 |
これでサーバーを再起動すればOK。
発狂せずに済んだね。
だいたいは怒られているパッケージ名に-devel
がついたパッケージをyum
でいれてやれば解決する。
指摘されているパッケージそのものをinstall
とかreinstall
とかしても一向に解決しないので注意。
変数の型が違う物同士を演算しようとすると出る。
なんで?
これは帰ってくる。というか普通にダンプ内容が表示される。
1 2 |
var_dump($hoge); die(); |
これはデータを受信していません、になる。
Chromeで言うとエラーコードERR_EMPTY_RESPONSE
になる。
1 2 3 |
var_dump($hoge); die(); die(); |
仕様なのか、、、??
die();の問題じゃないっぽい。
どうやらクラス内定数周りが絡むとこうなることが多い気がする。
要調査。