Home » Posts tagged "php" (Page 2)

Amazon Athena 可以透過 ODBC 連接了

Amazon Athena 支援 ODBC 了 (先前直接連結只支援 JDBC):「Amazon Athena adds support for querying data using an ODBC driver」。

With the availability of a new ODBC driver, you can now connect popular business intelligence tools to Athena. This allows you to report and visualize all of your data in S3 with the tools of your choice. In addition to the ODBC driver, Customers can now connect to Amazon Athena using a JDBC driver, an API and via the AWS Console.

這讓非 Java 的程式語言可以更方便的接上去了,像是 PHPPDO 支援 ODBC 但不支援 JDBC,要用就得想其他辦法:「PHP: PDO Drivers - Manual」。

PHP {7.1,7.0,5.6} 總算成為主流了...

PHP {7.1,7.0,5.6} (至少有安全性支援的版本) 佔了 90% 以上的量... 至少是有用 Composer 族群的主流了:「PHP Versions Stats - 2017.2 Edition」。

All versions                    Grouped
PHP 7.1.10      11.63%          PHP 7.136.63% (+18.99)
PHP 7.0.22      7.95%           PHP 7.030.76% (-5.36)
PHP 5.6.31      7.38%           PHP 5.623.28% (-8.16)
PHP 5.6.30      7.23%           PHP 5.56.11% (-4.5)
PHP 7.0.24      5.45%           PHP 5.41.51% (-1.6)
PHP 7.1.11      4.55%           PHP 5.30.76% (-0.22)

可以看出大家都在往 PHP 7.1 推了...

PHP 7.3 的 function 也會支援 trailing comma 了

這投票殺來殺去了好幾次才過,從 PHP 7.3 開始在 function 呼叫時就能接受 trailing comma 了:「PHP RFC: Allow a trailing comma in function calls」。

Wait, didn't we just vote on this?

Yes, there was an RFC to add trailing commas to all list syntax in PHP 7.2. Unfortunately due to an oversight on my end, the vote for function calls and function declarations was combined into one vote so the vote failed (but just barely!)

I was contacted by many “no” voters saying that they would have voted “yes” for function calls, but “no” for function declarations. This RFC proposes allowing a trailing comma in function call syntax only.

We are allowed to put this feature up for vote again since the mandatory 6-month waiting period has passed since the last vote and this RFC targets a new major version of PHP.

這次以 30:10 過了... (需要 2/3 以上同意)

PHP-FIG 成立官方網誌

Twitter 上看到 PHP-FIG 成立 official blog「PHP FIG」了,放在 Medium 上:

另外有更正說明的 tweet:

是一個知道 PHP-FIG 又有什麼大事的管道...

PHP 7.3 的 json_decode() 將會用 Exception 處理錯誤

在「PHP: rfc:json_throw_on_error」這邊提到 PHP 7.3 會解決 json_decode() 發生錯誤時的處理方式:

PHP has two functions for dealing with JSON, json_decode() and json_encode(). Unfortunately, both have suboptimal error handling. json_decode() returns null upon erroring, but null is also a possible valid result (if decoding the JSON “null”).

在這之前唯一的判斷方式是另外再呼叫 json_last_error() 或是 json_last_error_msg(),但這樣寫很辛苦,所以要引入 JsonException 了,總算...

PHP 7.2 的效能改善

作者在「PHP 7.1 vs 7.2 Benchmarks (with Docker and Symfony Flex)」這邊拿 Symfony 測試 PHP 7.2 的效能,發現效能提昇主要來自於多個連線時的情境:

前面的數字是前端頁面 (用了 Twig),後面的數字是純 API 呼叫。都可以看出 conc = 1 時其實沒有顯著差異,但只要有多個連線同時存取時,效能的提昇就會展現出來。對於繁忙的站台感覺會有不少幫助...

作者的猜測是 opcache 模組的改善,也就是在這段提到的:

- Opcache:
  . Added global optimisation passes based on data flow analysis using Single
    Static Assignment (SSA) form: Sparse Conditional Constant Propagation (SCCP),
    Dead Code Elimination (DCE), and removal of unused local variables
    (Nikita, Dmitry)

HHVM 的後續

官方對於 HHVM 的未來提出了說明:「The Future of HHVM」。重點就是他們不打算以 PHP7 為目標,打算關起來自己玩...:

Consequently, HHVM will not aim to target PHP7. The HHVM team believes that we have a clear path toward making Hack a fantastic language for web development, untethered from its PHP origins.

如果以 Packagist 上的資料來看 (PHP Versions Stats - 2017.1 Edition),HHVM 的數量應該是沒人了:

And because a few people have asked me this recently, while HHVM usage is not included above in the graph it is at 0.36% which is a third of PHP 5.3 usage and really hardly significant. I personally think it's fine to support it still in libraries if it just works, or if the fixes involved are minor. If not then it's probably not worth the time investment.

Comment 的地方有註明這是扣掉 CI 的量:

@ocramius: These numbers ignore Travis CI and other CI systems that set the "CI" env var in their workers. Without excluding those HHVM is around 0.95% so it's still low but those .36% is probably actual usage.

這樣就放心可以完全不用管 HHVM 了 XDDD