Home » 2014 » July

GitHub 的 CSS 設計

在「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

填補 Caltrain 營運空缺的 Fleet

去年年底參加 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.

還蠻有趣的嘗試,不知道成效如何...

PSR-0 轉換到 PSR-4

在「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 的 Ryan 換 InnoDB 的筆記與心得

沒記錯的話,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 的解決方案 (晚上就算設備出問題也不用擔心要爬起來救機器):

  • MyISAM 的讀寫互斥、寫入也是互斥。當有資料在讀取時無法更改資料庫內容,而有寫入時其他人不能讀取。另外同時間只能有一個人寫入。(有少數操作是例外,像是 bulk insert,這邊跳過)
  • MyISAM 不是 crash-safe storage engine。機器總是有機會爛掉,這時候除了重開機的時間外,還需要有修 table 的時間,對於網站的 uptime 比較痛。

這兩點是當時 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 聊,好像效果還不錯吧...

AWS 的 ELB 可以自訂 HTTP/HTTPS Timeout 時間了

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 秒。

Mozilla 推出 mozjpeg 2.0

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 可以查...

Archives