Tag: laravel

Laravel 將不會有 LTS 版本

查資料的時候發現，在 Laravel 9 剛發佈的時候是有掛 LTS 版本的資訊 (從「Laravel 9 (LTS) 出了」這邊的截圖可以看到)，但在發佈後沒多就就被拿掉了，在 Taylor Otwell 的 Twitter 上有提到這件事情：

從幾個 forum 討論的態度上看起來以後不會出新的 LTS 版本了，之後的版本都是提供一年的 bug fix + security fix，再加上另外一年的 security fix，基本上有兩年的 support，算是半強迫開發者時間到了就要升級版本...

另外一個有看到的問題是，現在的 Laravel 9 支援的 PHP 版本因為底層 Symfony 要 PHP 8.0+ 關係也一起被拉上來，連 PHP 7.4 都不支援了：

這個靠「***** The main PPA for supported PHP versions with many PECL extensions *****」這類 3rd-party repository 來補是還能解，但感覺 Symfony 對這些問題的態度...

PHP (以及 Laravel) 下使用 DynamoDB 的 ORM 工具

在 Twitter 上看到「Laravel DynamoDB Eloquent Models and Query Builder」這篇文章，裡面講「Laravel DynamoDB」這個套件，可以在 PHP (以及 Laravel) 下存取 DynamoDB。

雖然套件提到了 Laravel，但文件裡面也有提到支援非 Laravel 的 PHP 環境下使用，單獨拿出來用也沒問題，比較重要的反倒是 DynamoDB 對各種 key 的概念。

如果是從零開始設計，但又不想要自己管資料庫，我會偏好先用 RDS 設計，無論是 MySQL 或是 PostgreSQL 的版本都行，畢竟 RDBMS 上面能做的事情比較多，對開發者比較友善，除非是第一天上線你就預期量會大到連 db.m5.24xlarge 都擋不住之類的情況...

Laravel 9 (LTS) 出了

剛剛看到 Laravel 9 (LTS) 出的消息：「Laravel 9 is Now Released!」，對應的 release notes 在「Release Notes」這邊可以看。

相隔兩年半的 LTS 版本，另外也要求到 PHP 8.0+：

不過 Lavavel 的 LTS 設計上，沒有與一般 release 差太多，LTS 版本是 24/36 個月支援 (功能/安全)，但一般版本是 18/24 個月支援：

For LTS releases, such as Laravel 9, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 18 months and security fixes are provided for 2 years.

如果看隔壁 Ubuntu 的 LTS 是 60 個月，但一般版本是 9 個月；Node.js 的 LTS 是 36 個月，以及一般版本的 9 個月，這樣看起來就有很明顯的差異...

這樣看起來跟一般版本好像也還好？

讓 Laravel 的 PHPUnit 在發生錯誤時把 Stack 丟出來

這兩天又遇到一次，這應該是 Laravel 裡設計比較奇怪的地方，既然是跑 PHPUnit 的環境，為什麼不預設在錯誤發生時把完整的 stack 拋到 console...

這邊的解法是參考「Laravel: How to enable stacktrace error on PhpUnit」這篇的解答。

舊版需要自己丟 handler 進去 (5.4 以及之前的版本)，在 5.5+ (寫這篇時最新的穩定版本已經是 5.6) 有內建 withoutExceptionHandling() 可以用，所以在 tests/TestCase.php 內搞定 setUp()：

    protected function setUp()
    {
        parent::setUp();
        $this->withoutExceptionHandling();
    }

不知道有沒有機會直接進 Laravel 的 package 設定裡面...

有 Lazy Connection 功能的 PDO object

在「Aura.Sql」這邊看到有提供 Lazy Connection 的 PDO object，而且是繼承自本來的 PDO object：

Provides an extension to the native PDO along with a profiler and connection locator. Because ExtendedPdo is an extension of the native PDO, code already using the native PDO or typehinted to the native PDO can use ExtendedPdo without any changes.

Lazy connection. ExtendedPdo connects to the database only on method calls that require a connection. This means you can create an instance and not incur the cost of a connection if you never make a query.

之後可以拿來跟 Laravel 的 Eloquent 一起用看看。本來的 PDO 物件在建立時就會建立連線，對於連線的開銷其實蠻大的，用這個應該是個方向...

另外是 Profiler 的能力，需要用的時候應該會很好用：

Profiler. An optional query profiler is provided, along with an interface for other implementations, that logs to any PSR-3 interface.

引一下來源，當初是從「Atlas.Orm 2.0 Is Now Stable」這邊在看文件時一路看到的。

Laravel 5.5 釋出，第二個 LTS 版本

Laravel 推出第二個 LTS 版本，5.5 版：「Laravel 5.5 LTS is Now Released」。

當初 Taylor Otwell 對 LTS 還蠻感冒的 (參考去年的 tweet)，居然推出了...

有 LTS 對於商業應用的維護來說還是方便不少... 大概是考慮到這個原因，所以還是推出了 :o

Symfony 4 將放棄 HHVM

PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越，參考下面的連結)，這使得後來大家為了相容性與擴充性的考量，HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊，作者從 packagist.org 上得到的數據)：

這使得 Symfony 決定在 Twitter 上蒐集意見，而後決定下一個 major version (4) 將不再支援 HHVM：「Symfony 4: End of HHVM support」。

馬上想到的是 Laravel 用了一堆 Symfony 的元件啊，之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用，甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。

用 prestissimo 加速 PHP Composer 的下載速度

在「碼天狗週刊 #33」上看到的「prestissimo」這個軟體，可以平行下載 Composer 所需要的軟體而讓速度變快。作者測試 Laravel 的安裝：

$ composer create-project laravel/laravel laravel1 --no-progress --profile --prefer-dist

從 288 秒變成 26 秒：(這種 benchmark 跟地點應該有關係，看作者似乎是日本人？不知道是不是在日本測的...)

感覺應該要變成 Composer 的內建功能才對？

MariaDB 讀寫分離的工具：MaxScale

MariaDB 的 MaxScale 軟體提供 MySQL 相容的 proxy interface，可以將後端一群 MySQL server 架構隱藏起來，讓應用程式不需要處理這部份。

而 Percona 的人則介紹 MaxScale 作為讀寫分離的工具：「High availability with asynchronous replication… and transparent R/W split」。

如果你是用有支援讀寫分離的 ORM (像是 Laravel 中的 Illuminate::Database)，由於 ORM library 幫你處理好了，你可以省掉這個工作。

但在其他的情況，像是應用程式沒有原始程式碼，或是只能設一組 server，你就必須透過像 MaxScale 這種軟體來幫你打散負荷量。

Percona 給的範例提供了很多設定檔，應該是改一改就可以動 (當然效能調校是另外要花功夫的事情了)，對於有興趣的人應該可以丟人研究？

用起來有點苦的 Laravel...

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...

也就是說這個數字是起點 (往下的起點)，這樣看起來有點慘烈啊...