Packagist 打算把服務丟上 AWS：「An Update on Packagist.org Hosting」。
We decided to migrate the packagist.org website to AWS as well, including the database, metadata update workers, etc. This makes it much easier to build a highly-available setup, where machines can be rebooted or even rebuilt safely without bringing down the whole site.
不知道會搬多少上去... 目前 .com 的 packagist.com 已經上 AWS 了，但 packagist.org 與主要的流量來源 repo.packagist.org 看起來都還沒。
Twitter 上看到的公告：
Effective today, the PHP project has ended its volunteer mirror program. All users of PHP will now be accessing https://t.co/S2GoDChwgr sites directly from project servers and via CDN.https://t.co/POypIycsti#NotAnAprilFools
— php.net (@official_php) April 1, 2019
本來 PHP 開放讓各地區的自願者提供頻寬，使用 PHP 的網域名稱 (像是 tw.php.net 這樣)，現在則是全部都收回，由官方統一提供有 HTTPS 的網頁版本 https://www.php.net/。
目前看起來 latency 頗高，都是到美東的伺服器上？下載也都還是指在 https://www.php.net/ 上，不知道 CDN 是用在哪裡...
在 Twitter 上看到 Ondřej Surý 因為得到協助 (包括 Microsoft)，所以會繼續支援 PHP 5.6 與 PHP 7.0 的 PPA 更新：
PHP 5.6 and PHP 7.0 will stay (for now): https://t.co/iMkbVQdn5x
// Big kudos to @RemiCollet and @weltling for backporting the security fixes for EOL versions of PHP in @Microsoft @github repository: https://t.co/IWRJHlDFqo
— DEB SURY ORG (@debsuryorg) March 8, 2019
在「PHP 5.6 and PHP 7.0 will stay (for now)」裡面有提到這是 best effort，沒有保證會維持多久：
Please note that this is based on best effort and without any warranty.
對於還在這兩個版本掙扎的人再多了一些時間...
在「Links: February 2019」這邊看到 PHP 社群的提案，想要改善數字與字串比較的結果：「PHP RFC: Saner string to number comparisons」。
他給了一個經典的範例：
$validValues = ["foo", "bar", "baz"]; $value = 0; var_dump(in_array($value, $validValues)); // bool(true) WTF???
原因是 in_array() 是 == 而非 ===，所以就噴了... 而提案我看了還是覺得不行啊，看看會怎麼改吧 :o
剛剛才注意到 PHP 5.6 在 2019 年還有新的版本：「PHP 5.6.40 Released」。
在「Supported Versions」可以看到 PHP 5.6 應該是在 2018 年年底就終止更新，看起來是 5.6.39 在 2018/12/06 出之後，把剩下的一包都累積起來，「原則上」後面不會有更新：
Please note that according to the PHP version support timelines, PHP 5.6.40 is the last scheduled release of PHP 5.6 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.6 branch.
不過看起來官方的態度是「儘量幫」，如果有太嚴重的漏洞還是會補... :o
這兩天又遇到一次，這應該是 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 設定裡面...
這個功能在 ELB Classic 年代時有跟 AWS 提過，到 ALB 支援了 (總算...)：「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。
Application Load Balancers now support a slow start mode that allows you to add new targets without overwhelming them with a flood of requests. With the slow start mode, targets warm up before accepting their fair share of requests based on a ramp-up period that you specify.
然後時間可以設定，從 30 秒到 15 分鐘：
Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.
就之前的經驗來說，這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣，可能不會這麼吃這個功能。
主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時，儘量將 CPU 留給 opcache，把常用的頁面 compile 完並且放進 cache，而不是讓大量的連線灌進來，這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久，造成每個連線都很慢才跑完)
AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...
在「PHP Versions Stats - 2018.1 Edition」這邊看到這次的統計資料了，可以看到會使用 Composer (以及 Packagist) 的 PHP 版本中，7.0+ 已經是 78% 了，半年前是 67% 左右...
除了 PHP 5.x 以外，PHP 7.0 也是 12 月要停止支援 (2018/12/3)，比 PHP 5.6 的支援期還早一個月左右 XD
去年十一月出 PHP 7.2，現在已經更新到 7.2.5，各家軟體的相容性也都修的差不多了，差不多該升級了。
在「PHP 7.2 的效能改善」這邊有提到與 PHP 7.1 的效能改善主要來自於同時間有多人同時存取時的最佳化。
同樣 wiki 也跟著更新了，來看看效果如何...
在「Migrating to MySQL 8.0 without breaking old application」這邊看到這個有趣的故事 XD 這是作者的應用程式 Drupal 從 MySQL 5.5 一路升級到 8.0 的過程記錄...
真正的問題發生在 5.7 到 8.0：
原因是 Drupal 用到關鍵字了：
In fact, this old Drupal, uses a table name that is now part of the reserved keywords. It’s always advised to verify what are the new keywords reserved for MySQL itself. New features can also mean new keywords sometimes.
修正後就好了：
話說依照「File:Drupal release timeline.png」這邊的資訊，Drupal 6.2 也十年左右了？應該是 PDO 剛開始要推廣的年代，不知道他跑哪個版本的 PHP...
另外 MySQL 的升級意外的順利？雖然是一步一步升，但沒遇到什麼大問題...
