kuanhung c

PHP for Message Queue Workers Supervisord  - Supervisor: A Process Control System

Opcache Understanding OpCache PHP 5.5: OUT-OF-THE-BOX BYTECODE CACHE Zend Opcache Is APC compatible with PHP 5.4 or PHP 5.5?

程式碼的靜態分析是 team work 或者 CI 中很重要的一個環節 而靜態分析，其中的一項功能 coding standard 和 coding style的分析更是可以保護你的眼睛 squizlabs/php_codesniffer 內建有許多 ruleset, 像是 PHPCS, PSR2, PSR1, Squiz, PEAR, Zend etc... 如果你仔細去看每個 Standards 目錄下的 ruleset.xml 和 Sniffs 目錄大概就可以看出 其實他們是互相 include, 然後在自己的 Sniffs 裡做 Overide 或者是定義自己的新規則 例如 PSR2 的 ruleset.xml 裡面就宣告了 reference rule 是 PSR1 而 PSR1 又 include 了像是 Squiz 之類的 如果因為某些歷史/framework 的因素, 你希望盡可能地採用 PSR2, 但是又希望 exclude 掉其中的某一部分, 例如 PSR0  這時候你可以在 Standards 目錄下建立自己客製化的 ruleset, 目錄裡面只要放 ruleset.xml  內容是 reference PSR2, 再另外加上你想 exclude 掉的 rule. 但是你要怎麼知道有那些 rule 可以 exclude 呢? 以你想套用大部分的 PSR2 ruleset, 但是又想 exclude 掉 PSR 0 為例. 我們知道 PSR2 引用了 PSR1, 而 PSR1 裡面又包含了 PSR0 所以 Standards/PSR1/Sniffs/Classes/ClassDeclarationSniff.php 裡面會檢查 class 有沒有正確宣告 namespace 想 Exclude 掉這個 rule 的話, 我們可以從目錄拆解出 rule name: "PSR1.Classes.ClassDeclaration" 大概就是這樣啦~ 透過客製化自己的 ruleset, 然後再設定 sublime linter 裡的 code sniffer. 就可以馬上讓你的知道, 自己寫的 code 有沒有符合規則. ...

如果 apc.enable_cli 因為"某些因素"有開啟的話 那麼有時候一些 command line 會遇到類似下面的 error "Cannot redeclare class xxxxx" 這時候有兩種方式: 1. 如果是針對 .phar 的話, 可以用 apc.filters="^phar://" 2. 如果是 cron job 或者暫時性的話: php -d apc.enabled=0 /path/to/cron_job.php 比較特別的是 phar 檔不只是 cli 容易遇到 redeclare error,  像是 aws 的 php sdk 最好還是用 composer 的方式安裝吧. See Also: http://stackoverflow.com/questions/4575341/php-with-apc-fatal-errors-cannot-redeclare-class http://docs.aws.amazon.com/aws-sdk-php/guide/latest/faq.html#why-am-i-seeing-a-cannot-redeclare-class-error

CakePHP Cheat Sheet   http://cakephpcheatsheet.com/

12-factor-cakePHP-applications Slides:  https://speakerdeck.com/josegonzalez/12-factor-cakephp-applications Youtube:  https://www.youtube.com/watch?v=Kye8yaq4jqk composer / satis  - Simple static Composer repository generator d11wtq / boris  - A tiny REPL(read-eval-print loop) for PHP kamisama/Cake-Resque - Resque plugin for CakePHP : for creating background jobs that can be processed offline later (redis backend) seatgeek / djjob D- A PHP port of delayed job (database backed asynchronous priority queue )

http://ihower.tw/blog/archives/5140 這個 flow 大概從三年前第一次看到.... 到之前為止一直沒辦法和實際的情況對應起來.... 我一直在想 git flow 要這麼多 branch 有甚麼用? perforce 的 code line 和用 git 的 branch 到底有甚麼差異? 經過上星期五一陣混亂的 rebase / merge 兩個放了快一個月的 feature branch 進 master branch 後....我終於懂了.... 在從 feature branch merge 回去 master 之前, 你也可以(也應該要)先在自己的 feature branch rebase 到最新的 code line, 測試整合後沒有問題的話, 就可以放心的 merge 回去。 用這樣的方式最大的好處是, 在自己的 feature branch 裡完全不會干擾到別人或者受到別人的干擾，你可以把開發的時間拉到很長，中途切換到其他工作，再隨時切換回來，而不會漏掉你不同 branch 裡修改的內容。而且 git 的 branch 讓你可以很容易的在自己的 feature branch 裡先測試整合後的結果。 git flow 則是提供了很好的 practice, 一般來說，遵循這樣的原則可以應付大部分的 release 需求 果然有些事，看了一百遍不懂，但是做了就知道了.... 其實目前我用的 flow 因為有結合 perforce 所以沒有用到 develop branch, 換個說法的話就是, 目前我用的 master branch 在 git flow 裡其實算是 develop branch.. 1. use rebase to update from master 2. rebase 完後記得 squash commit 3. 從 feature branch 進 master branch 時, 用 merge --no-ff 4. follow the  spirit of  git flow ....不要亂 merge .... 雖然條條大路通羅馬, 但是...會花不一樣的時間....