HHVM 的人決定起草將 PHP 這個程式語言的規格定義出來:「Announcing a specification for PHP」。
文件可以在「Specification for PHP」這邊看到,不知道後續會有什麼進展?
幹壞事是進步最大的原動力
HHVM 的人決定起草將 PHP 這個程式語言的規格定義出來:「Announcing a specification for PHP」。
文件可以在「Specification for PHP」這邊看到,不知道後續會有什麼進展?
Oracle 的梶山隆輔在 COSCUP 2014 的投影片:「MySQL Performance Tuning at COSCUP 2014」:
推薦的主力在 MySQL 5.6,這點 Percona 的人也已經宣傳過很多次了:
MySQL 5.6 的改善很大,尤其是針對 InnoDB 相關的改善。在 MySQL 5.5 上還會有 CPU 吃不滿的情況,在 MySQL 5.6 好很多。
在「GitHub's CSS」這篇裡面講了很多 GitHub 設計的工具,以及評估的方式。
原文有提到 IE9 以及之前的版本中,單檔有 4095 selector 的限制,這點讓人稍微怔了一下:
The split was added years ago to solve the problem of Internet Explorer’s 4,095 selectors per file limit.
超過的要切割讀入...
另外在文中有提到 2012 年的投影片「GitHub's CSS Performance」吸引我的目光:
針對 diff 頁面大量元素時的 CSS 效能分析,除了各種 browser 裡 index id & class & tag 的方式外,另外還有不少為了加速而直接修改 HTML 的建議 XDDD
去年年底參加 Spark Summit 時有用 Caltrain 當作交通工具回飯店,好像是搭到末班車... (或者說是接近末班車?有點忘了...)
Fleet 的服務則是填補 Caltrain 減班或是休息的時候,用小型車在 Caltrain 的幾個大站提供服務:
Ride with friends, or meet other cool people on the way; we drive in a car, van, or shuttle seating 5 to 15 people.
Our shuttles run between 8 PM and 5 AM everyday, with 5 southbound departures, and 5 northbound departures.
另外主打比 Uber 便宜許多:
We are also ~2-4X cheaper than Uber and other ridesharing alternatives.
還蠻有趣的嘗試,不知道成效如何...
在 Nomad PHP EU 上的議程:「Composer: Stability and Semantic Versioning Demystified」,講 Semantic Versioning 在 Composer 上的應用。
投影片還講到了 Composer 處理版本需求互相重疊時的情況,可能會有 conflict 的問題...
在「Send PSR-0 to the Standards Farm in the Sky」這篇文章裡作者大聲呼籲用 PSR-4 取代 PSR-0。
不過 PSR-0 在 Packagist 上被廣泛使用:
As of some time a few months ago (...), of the 20,097 packages hosted on Composer, 15,668 of them use PSR-0.
PSR-0 的設計是考慮到 PHP 5.2 沒有 namespace 時所留下來的特性 (以底線為主的切割方式),在 PHP 5.5 都已經出版,而且 PHP 5.2 已經 EoL 的時候顯得有點多餘。
作者提議在 PSR-0 的文件開頭加上:
Deprecated - As of 2014-12-30 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative.
不過 PSR-0 的專案應該還是會跑很久?
沒記錯的話,Mobile01 應該是去年暑假左右從 MyISAM 換成 InnoDB 的?一切的起頭應該是蔣大「現在SSD硬碟可以拿來跑資料庫嗎?」這篇。
另外同場加映,使用 Percona 的工具讓管理上更方便:
MyISAM 是 MySQL 5.0 與 5.1 預設的 storage engine (到 5.5+ 預設的 storage engine 改成 InnoDB),讀取的效能相當好,但總是有些問題。
當時剛好有機會跟蔣大與 Ryan 聊到當時 Mobile01 遇到的問題,問了一些細節後感覺上是 MyISAM 的問題,就提了 MyISAM 與 InnoDB 的優缺點比較,以及幾個 InnoDB 的 High Availability 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器):
這兩點是當時 Mobile01 遇到最痛的問題:用 iostat 看起來 I/O 明明就沒有滿,但就是會卡 SQL query,而當機後修資料庫的時間又很長。
一個是已經在業界驗證很久的解決方案 XFS + DRBD + Heartbeat,當機器發生問題時的 downtime 從 30secs 到五分鐘 (依照資料性質與大小而有差異,在切換上線後有資料庫的熱機問題)。
另外一個是當時還很新的 Percona XtraDB Cluster,可以避免資料庫的熱機問題,不過技術很新。
後來 Mobile01 用 RAID 10 的硬體,軟體的部份用 Debian + XFS + DRBD + Heartbeat 跑 Percona Server 的 XtraDB (InnoDB 的加強版),先用 VM 做了 PoC (直接砍掉 mysqld,或是直接關掉 VM 之類的,測試整個機制夠不夠自動化),然後就上線了 :p
記得上線那幾天跟 Ryan 聊,好像效果還不錯吧...
Elastic Load Balancing 之前的 timeout 時間是預設值 60 秒,現在可以自訂時間了:「Elastic Load Balancing Connection Timeout Management」。
文章裡有提到好處:
Some applications can benefit from a longer timeout because they create a connection and leave it open for polling or extended sessions. Other applications tend to have short, non- recurring requests to AWS and the open connection will hardly ever end up being reused.
目前可以設定 1 秒到 3600 秒,預設值是 60 秒。
看到「Tools of The Trade, from Hacker News.」這個,把各種只要跟 Hacker News 有關的工具都列出來了。
已經用了某個工具,要找同質性的替代方案也可以在這邊找... 太過基礎的就只列出來而不會解釋了,像是「Google Analytics」XD
othree 前天已經寫過:「mozjpeg 2.0」,不過因為這類性的研究其實對全世界幫助頗大,所以就再提一次...
原文在「Mozilla Advances JPEG Encoding with mozjpeg 2.0」這邊,主要的成果:
With today’s release, mozjpeg 2.0 can reduce file sizes for both baseline and progressive JPEGs by 5% on average compared to those produced by libjpeg-turbo, the standard JPEG library upon which mozjpeg is based [1]. Many images will see further reductions.
文章內也出現了一些關鍵字:
We’ve added options to specifically tune for PSNR, PSNR-HVS-M, SSIM, and MS-SSIM metrics.
PSNR 是最常聽到的,其他幾個 keyword 剛好可以拿來當 entry point。在「Video quality」這邊的 See also 部份也有不少 keyword 可以查...