點燈坊

註解是一定要寫的，但要怎麼寫才能使開發者與工具都看得懂呢？PHPDoc是目前PHP註解的標準，提供了統一的註解寫法，並且獲得PhpStorm的支援，PHPUnit也使用PHPDoc，事實上Laravel的source code也是使用PHPDoc格式來寫註解。

之前我一直使用Homestead作為Laravel的開發環境，不過因為實務上遇到幾個問題，我一直想換掉Homestead，實際對MAMP PRO測試了一段時間後，發現剛好滿足我的需求。本文紀錄一些我使用MAMP PRO的心得。

OS X熱鍵之多是一大特色，不過初學者常常看不懂OS X熱鍵的特殊符號，如PhpStorm的熱鍵就完全以OS X特殊符號表示。本文整理出OS X常見熱鍵的意義，並附上其HTML代碼，方便自己寫blog時隨時查閱。

目前我都將所有範例的source code放在Github上，但有人跟我反應抓下來的Laravel專案無法執行，並不是我故意留一手，而是git採用了.gitignore機制，並沒有所有檔案都進Github，所以整個專案抓下來後，必須要有重建的步驟，整個專案才會還原。

談到unit test，就不能不談到isolated test，但實務上常常因為函式內有相依物件而無法做到isolated ，若是依照TDD的方式寫unit test，因為測試先寫，會一開始就考慮到可測試性，自然會將相依物件改用DI與service container的方式，但若是事後補測試，就常常會有因為相依物件而造成測試加不上去的問題。
本文歸納出幾個方法，有依賴注入方法，有OOP反璞歸真方法，最後還有PHP邪惡方法。

Service provider最主要的功能就是讓我們寫package，本文一步一步的介紹最簡單的package，僅有Hello World的功能，並包含route、controller與view，然後打包成package送上Github與Packagist，最後另外開一個專案，使用composer require下載，執行我們自己上傳的package。
實際寫過package之後，會讓我們對service provider與composer有更深刻的了解。

Laravel提供了service container讓我們方便實現Dependency Injection，而service provider則是我們註冊及管理service container的地方。

事實上Laravel內部所有的核心組件都是使用service provider統一管理，除了可以用來管理package外，也可以用來管理自己寫的物件。

若一個專案由多人共同開發，你可能相依到別人的class，自己在local本機unit test測試通過，並不代表上線之後沒問題，因為很可能別人class的修改導致你的class 執行失敗。
Travis CI與GitHub高度整合，只要你對GitHub push之後，Travis CI就能自動從GitHub抓最新版的code，並執行PHPUnit，最後將測試結果email給你。

由於Github的流行，越來越多人喜歡用markdown格式寫文件。使用Hexo寫blog時，我會使用Sublime Text寫markdown，但若寫專案的readme.md時，由於是在PhpStorm內工作，所以會希望也能在PhpStorm內寫markdown。可惜PhpStorm內建並沒有支援markdown格式，所幸JetBrains有另外開發plugin，讓我們也可以在PhpStorm寫markdown了。

Laravel 5.1內建PHPUnit與Mockery，直接使用就可以了，但Laravel 4.2沒有內建，必須自己手動安裝，但因為PHPUnit在Oct.02,2015宣布重要改版，PHPUnit 5.0僅支援PHP 5.6與PHP 7，只有PHPUnit 4.x會繼續支援PHP 5.3、PHP 5.4與PHP 5.5，所以導致Laravel 4.2在安裝PHPUnit時在版本上需要特別注意。此外在自己新增class部分，測試上也有小雷要注意。