AWS 推出 Scheduled Reserved Instances

Amazon EC2 提供的新玩法,Scheduled Reserved Instances (Scheduled RI):「New – Scheduled Reserved Instances」。

Scheduled RI 可以指定買「某個特定時段」一年,像是每天的凌晨零點到八點之類的,拿來跑 report 這類需求。不過不同於 Standard RI 是不需要另外設定就會自動生效,Scheduled RI 需要開機器時指定才會使用。

不過只會省一些,而不像 Standard RI 可以省的量:

The new Scheduled Reserved Instance model allows you to reserve instances for predefined blocks of time on a recurring basis for a one-year term, with prices that are generally 5 to 10% lower than the equivalent On-Demand rates.

另外只有某些地區的新機種有這個選項:

This feature is available today in the US East (Northern Virginia), US West (Oregon), and Europe (Ireland) regions, with support for the C3, C4, M4, and R3 instance types.

就成本來看,應該是屬於最後 optimize 的項目,而不是一開始的最佳化...

HTTP Status Code 451

前陣子送出的 HTTP Status Code 451 要通過成為標準了:「Why 451?」。

Today, the IESG approved publication of "An HTTP Status Code to Report Legal Obstacles". It'll be an RFC after some work by the RFC Editor and a few more process bits, but effectively you can start using it now.

取自「華氏451度」這部講出版物言論自由的作品 (紙的燃點是華氏 451 度),在 Internet 時代,451 剛好在 HTTP Status Code 4xx 的範圍,被拿來用做「因法令限制而服法提供內容的 Status Code」。

在文件開頭說明了這個代碼的用途:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

RFC7686:保留 .onion 給 Tor 的 Hidden Services 使用

看到 Tor Project 很高興的宣佈 .onion 這個 TLD 在 RFC 7686 成為 Standards Track:「Landmark for Hidden Services: .onion names reserved by the IETF」。

而且也因為成為 IETF 的標準,在 CA/Browser Forum 上更有依據討論在上面的 CA 架構:

With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum.

Amazon S3 推出新的種類:Standard - Infrequent Access Storage

Amazon S3 推出了新的種類:「AWS Storage Update – New Lower Cost S3 Storage Option & Glacier Price Reduction」。

原先只有「Standard」、「Reduced Redundancy Storage」以及「Glacier Storage」三種,現在多了一種「Standard - Infrequent Access Storage」。

首先是計價模式,儲存的單價變便宜很多,但存取是要另外收錢的:

$0.0125 / gigabyte / month (one and one-quarter US pennies), with a 30 day minimum storage duration for billing, and a $0.01 / gigabyte charge for retrieval (in addition to the usual data transfer and request charges).

拉資料的費用相當的貴啊一個月拉兩次就超過 Standard Storage 的價錢了,所以這個「Infrequent」的要求其實頗嚴苛的...

另外空間的部份以 128KB 為最小單位在計價的:

Further, for billing purposes, objects that are smaller than 128 kilobytes are charged for 128 kilobytes of storage.

所以綜合起來看,Infrequent Access Storage 的設計上是拿來堆資料備份,但希望拉資料時很快就可以拉出來。其實就是 Google Cloud StorageNearline 的想法,一樣有存取另外收費的項目。不過 Nearline 有說平均的 latency 是三秒:

但 IA 好像是跟 Standard 相同等級?至少文章裡沒有提到...

PCI DSS 的更新:PCI DSS 3.1

PCI DSS 3.1 出了:「PCI COUNCIL PUBLISHES REVISION TO PCI DATA SECURITY STANDARD — PCI DSS 3.1 and supporting guidance helps organizations address vulnerabilities within SSL protocol that put payment data at risk; PA-DSS revision to follow —」(PDF)。

與 3.0 相比,修正了 SSL 與 TLS 的安全性問題。分成兩大塊討論,對於新的系統:

  • 禁止使用 SSL 與早期的 TLS (包括了 TLS 1.0 與 TLS 1.1 的某些設定)。

而對於舊的系統:

  • 在 2016 年 6 月 30 日後,禁止使用 SSL 與早期的 TLS。
  • 在這之前,不符合上述條件的設備必須修正到可以防禦已知的 SSL 與 TLS 問題。
  • 對於 POS (Point-of-sale) 與 POI (Point-of-interaction) 系統則是例外處理:確認可以防禦已知 SSL 與 TLS 問題的話,期限後仍然可以使用。

PHP-CS-Fixer 1.0 出版!

PHP-CS-Fixer 正式釋出 1.0 版:「PHP CS Fixer finally reaches version 1.0」。

原作者提到了之前的版本以 regular expression 為底,而這三個月有了大改變,現在的版本是以 token 來判斷:

The current stable version of PHP-CS-Fixer was released in August 2014 and it is still based on regular expressions, two years after the first public release. But in the last three months, things got crazy mainly because of Dariusz Ruminski. He did a great job at rewriting everything on top of a parser based on the PHP tokens, helped by 21 other contributors.

這邊寫一下用法:

php-cs-fixer fix /path --level=psr2

這樣會把目錄下的所有 .php 檔都清過一次。目錄的部份也可以用檔名,表示只處理一個檔案。

檢查程式碼是否符合 PSR-2 的工具:PHP_CodeSniffer (phpcs)

PHP_CodeSniffer 是套檢查 PHP 程式碼是否符合規範的工具。


WordPress 3.8.1 的 index.php 跑 PSR-2 測試。

想要測試的人可以用 Vagrant 安裝測試,我用 Docker 弄了老半天弄不起來,就跑去用 Vagrant 測試了...

(話說回來,Vagrant 與 Docker 真的是測試的神器,反正要弄一個 Ubuntu 平台上測試就是拿這兩個東西出來測...)

由於系統內的 PHP_CodeSniffer 不一定夠新,舉例來說,Ubuntu 12.04 的 php-codesniffer 只有 1.1.0,而掃 PSR-1 的程式出現在 1.3.5,PSR-2 出現在 1.4.0

安裝 c9s 所維護的 phpbrew 通常是還蠻常見的選擇。裝完後再用 pear install PHP_CodeSniffer 裝進去就有 phpcs 可以用了。

phpcs 預設是用 PEAR standard,可以指定 --standard=PSR2 強迫他使用 PSR-2 規則:

phpcs --standard=PSR2 foo.php

也可以直接強迫換成 PSR-2,然後再看設定有沒有改成功:

phpcs --config-set default_standard PSR2
phpcs --config-show

除了可以檢查單一檔案外,也可以丟路徑進去整個檢查:

phpcs foo/

可能是未來的 PSR-3:LoggerInterface

Jordi BoggianoPHP-FIG 上提案整合 log interface,參考「One logger to rule them all」這篇,提案本身可以參考「Logger Interface」這裡。

如果通過的話,這很有可能是 PSR-3... 所以 PHP-FIG 接下來的想法是建立 interface 嗎?hmmm...

PHP 的 PSR-{0,1,2} 中文版翻譯...

查資料的時候發現有人已經翻譯好 PSR-{0,1,2}:

想要快速了解 PSR 在定義什麼,可以直接看中文版,如果有覺得不懂的地方再去翻英文版的原文敘述。

關於可維護的 PHP 專案:PHP-FIG 的 PSR-0、PSR-1、PSR-2

一個組織裡要導入 coding standatd & coding style 時是功夫最少的時候,除非有特殊理由,不然我一向都是建議:

不要自己發明 coding standard 與 coding style,如果社群的規範合理,就照著社群的規範走。

社群中比較完整的包括:

兩份大多數的規範是相同的 (因為 community 已經有習慣了),不過現在感覺起來 PHP-FIG 比較熱鬧一點 (參與的人來自不同的專案),如果讓我推薦的話我會建議用 PSR-{0,1,2}。

Reply to「寫出好維護的 PHP 程式碼」。