幹壞事是進步最大的原動力
PHP-FIG 前幾天公告了 PSR-7 (commit d40b64cc4e64e5a5b2fe998bb0a07d0b56e12505)，也就是 HTTP message interfaces。
由於 PSR 的編號只是提案順序，通過不一定會照順序。只是之前剛剛好都照著順序來 (PSR-0 到 PSR-4)，這次跳到 PSR-7 是跳過了 PSR-5 (PHPDoc Standard) 與 PSR-6 (Caching PSR)。
有了對 HTTP request 與 HTTP response 的標準後，可以馬上想到的是 routing library 與 controller library 可以接上去用，測試會變的簡單一些... 之後應該會有其他的想法可以做？
PHP-CS-Fixer 正式釋出 1.0 版：「PHP CS Fixer finally reaches version 1.0」。
原作者提到了之前的版本以 regular expression 為底，而這三個月有了大改變，現在的版本是以 token 來判斷：
The current stable version of PHP-CS-Fixer was released in August 2014 and it is still based on regular expressions, two years after the first public release. But in the last three months, things got crazy mainly because of Dariusz Ruminski. He did a great job at rewriting everything on top of a parser based on the PHP tokens, helped by 21 other contributors.
這邊寫一下用法：
php-cs-fixer fix /path --level=psr2
這樣會把目錄下的所有 .php 檔都清過一次。目錄的部份也可以用檔名，表示只處理一個檔案。
在「Send PSR-0 to the Standards Farm in the Sky」這篇文章裡作者大聲呼籲用 PSR-4 取代 PSR-0。
不過 PSR-0 在 Packagist 上被廣泛使用：
As of some time a few months ago (...), of the 20,097 packages hosted on Composer, 15,668 of them use PSR-0.
PSR-0 的設計是考慮到 PHP 5.2 沒有 namespace 時所留下來的特性 (以底線為主的切割方式)，在 PHP 5.5 都已經出版，而且 PHP 5.2 已經 EoL 的時候顯得有點多餘。
作者提議在 PSR-0 的文件開頭加上：
Deprecated - As of 2014-12-30 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative.
不過 PSR-0 的專案應該還是會跑很久？
PHP_CodeSniffer 是套檢查 PHP 程式碼是否符合規範的工具。
拿 WordPress 3.8.1 的 index.php 跑 PSR-2 測試。
想要測試的人可以用 Vagrant 安裝測試，我用 Docker 弄了老半天弄不起來，就跑去用 Vagrant 測試了...
(話說回來，Vagrant 與 Docker 真的是測試的神器，反正要弄一個 Ubuntu 平台上測試就是拿這兩個東西出來測...)
由於系統內的 PHP_CodeSniffer 不一定夠新，舉例來說，Ubuntu 12.04 的 php-codesniffer 只有 1.1.0，而掃 PSR-1 的程式出現在 1.3.5，PSR-2 出現在 1.4.0。
安裝 c9s 所維護的 phpbrew 通常是還蠻常見的選擇。裝完後再用 pear install PHP_CodeSniffer 裝進去就有 phpcs 可以用了。
phpcs 預設是用 PEAR standard，可以指定 --standard=PSR2 強迫他使用 PSR-2 規則：
phpcs --standard=PSR2 foo.php
也可以直接強迫換成 PSR-2，然後再看設定有沒有改成功：
phpcs --config-set default_standard PSR2 phpcs --config-show
除了可以檢查單一檔案外，也可以丟路徑進去整個檢查：
phpcs foo/
PHP Coding Standards Fixer 是在不破壞相容性的情況下，將 PHP 的程式碼往 PSR-2 的方向修正。
安裝的方式很簡單，直接抓下來：
wget http://cs.sensiolabs.org/get/php-cs-fixer.phar -O php-cs-fixer chmod a+x php-cs-fixer
看是要丟到 /usr/local/bin 下，還是丟到自己的目錄裡都可以。
裝完後就玩：
php-cs-fixer fix foo.php
如果 PHP 程式碼有進版本控制系統，在執行後就可以用 diff 看看改了什麼。
也可以對整個目錄修正：
php-cs-fixer fix foo/
預設是 PSR-2 以及一些作者自訂的規則，如果要強制只用 PSR-2 的話可以用 --level=psr2：
By default, all PSR-2 fixers and some additional ones are run.
有一些要注意的地方是，php-cs-fixer 因為是在不破壞相容性的前提下修正的，所以有些 method naming 的規則就無法修。不過比起手動修正 legacy code，可以省下不少時間...
剛剛看到「Composer now supports PSR-4」才發現有 PSR-4，而且出了好幾個禮拜了...
This PSR describes a specification for autoloading classes from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.
在已經有 PSR-0 的情況下，設計 PSR-4 讓人感覺有點怪，因為功能跟 PSR-0 是衝突的。
不過仔細看看以後發現 PSR-4 規則比較「乾淨」，有種想要汰換 PSR-0 的想法... 而且 Composer 裡 composer.json 的設計也允許針對不同的 prefix 使用不同的邏輯，看起來是把 PSR-0 當作過渡期的設計，希望大家換到 PSR-4？
PSR-0 與 PSR-4 最明顯的差異是對底線 (underscore) 解讀不同，在 PSR-4 中的底線沒有任何意義：
Underscores have no special meaning in any portion of the fully qualified class name.
在 PSR-0 裡則是說 class name 的底線必須換成 DIRECTORY_SEPARATOR：
Each _ character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR. The _ character has no special meaning in the namespace.
來想看看要怎麼轉換現有的系統...
Laravel 是個 PHP framework，是目前還蠻常看到討論的 PHP framework。不過實際在研究後發現用起來有點苦啊...
Laravel 官方覺得 PSR-2 是個鳥蛋 (參考 GitHub 上的 issue：「PSR-2 Conflicts」)，而我也知道 PSR-2 不怎樣，但這好歹是個標準可以靠啊...
另外一個是 overhead，在 AWS 上用 m1.large 跑 Ubuntu 64bits 測試純 PHP 的 echo "Hello, world."; 可以到 8000 reqs/sec (這是開了 APC 的情況測試，比較接近 production)，但同樣是要顯示 Hello, world.，用了 Laravel 後剩下 174 reqs/sec (debug mode 已經關閉)，如果再套上 Laravel 的 View 就剩下 152 reqs/sec...
也就是說這個數字是起點 (往下的起點)，這樣看起來有點慘烈啊...
剛剛才發現 PSR-3 已經正式定案了：「PSR-3 - Logger Interface」。
統一 log 界面，架構的基礎是建在 RFC 5424 (The Syslog Protocol) 對 log level 的定義上，使用 Psr namespace 定義實做的介面 (interface)。
目前看起來就到 PSR-3...
Jordi Boggiano 在 PHP-FIG 上提案整合 log interface，參考「One logger to rule them all」這篇，提案本身可以參考「Logger Interface」這裡。
如果通過的話，這很有可能是 PSR-3... 所以 PHP-FIG 接下來的想法是建立 interface 嗎？hmmm...
查資料的時候發現有人已經翻譯好 PSR-{0,1,2}：
想要快速了解 PSR 在定義什麼，可以直接看中文版，如果有覺得不懂的地方再去翻英文版的原文敘述。