用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時,會定義自己的 Message-ID,另外後續變更的通知信件會增加 References 欄位,讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 Message-ID 改掉,使用自己的 Message-ID 欄位,可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來,只剩下後續的信件因為有相同的 References,所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin,只要是沒有 References 的信件 (像是每張 ticket 的第一封信),就從 Message-ID 複製一份到 References 裡,這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好,所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

Amazon MQ 在 ap-northeast-{1,2} 推出了...

Amazon MQap-northeast-{1,2} 推出了,先前自己架的,現在可以直接拿現成的服務了:「Amazon MQ is Now Available in the Asia Pacific (Seoul) and Asia Pacific (Tokyo) regions」。

不過 AWS 上的開發主要還是以 SQS 之類的服務為主,可以避免 scalability 的問題 (另外一種可能是一開始就打定要搬出來,所以選擇 open protocol 的方案)。在這樣的前提下,Amazon MQ 的定位就變成將現有軟體丟上去跑... (而不想自己管 XD)

AWS 推出用 ActiveMQ 架設的服務,Amazon MQ

AWSActiveMQ 包起來賣服務:「Amazon MQ – Managed Message Broker Service for ActiveMQ」。

在 AWS 上已經有 Amazon SQS 這類服務的情況下,應該還是因為 ActiveMQ 的生態更豐富,所以決定支援 ActiveMQ... 光是支援的通訊協定就比自家多很多,有很多應用可以直接接上去:

With Amazon MQ, you get direct access to the ActiveMQ console and industry standard APIs and protocols for messaging, including JMS, NMS, AMQP, STOMP, MQTT, and WebSocket.

不過支援的地區還是有限:

Amazon MQ is available now and you can start using it today in the US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland), EU (Frankfurt), and Asia Pacific (Sydney) Regions.

另外這個服務有提供 free tier,可以讓使用者測試:

The AWS Free Tier lets you use a single-AZ micro instance for up to 750 hours and to store up to 1 gigabyte each month, for one year. After that, billing is based on instance-hours and message storage, plus charges Internet data transfer if the broker is accessed from outside of AWS.

Amazon SNS 可以發簡訊到全世界了...

Amazon SNS 的新進展,簡訊可以發到全世界了 (之前應該是只能發到美國?):「New – Worldwide Delivery of Amazon SNS Messages via SMS」。

拉台灣的數字出來可以看到即使是最便宜的台灣大哥大 (Taiwan Mobile) 每通也要 NTD$1.35 左右,其他家就貴翻了... (所以應該是跟台哥大合作對接?)

不過對於本來就有用 AWS 服務的人來說,帳單是在同一張,報起來比較省事...

對各類 Message Queue 的效能測試

在「Benchmarking Message Queue Latency」這篇看到作者測了一輪 Message Queue 軟體:

RabbitMQ (3.6.0), Kafka (0.8.2.2 and 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)

測試包括了從一個 9 到六個 9 的 latency (i.e. 90%、99%、99.9%、99.99%、99.999%、99.9999%),另外也測了 message 大小帶來的效能差異。

99.9% 表示 1/1000,而 99.99% 表示 1/10000,如果差距跟 90% 很大,表示系統反應時間會很不一致。另外有些 Message Queue 軟體有 disk persistence 的功能,也因為寫入資料,會看到更大的差距。

善用或是避開這些特性去規劃才能減少問題,像是關掉 disk persistence 之類的方法。

Slack 支援多人討論群組

Slack 宣佈支援多人討論群組了:「Group Messages Come to Slack」。之前要找一群人討論事情必須要開一個 Private Channel,但每次開 channel 都要想一個名字出來很討厭,後來都用 #test_201510290916 這種沒有意義的名字,而現在可以直接拉人進來了:

另外一個是跟著的改變:「Private Groups become Private Channels」。

With the introduction of group DMs, which will cover many of the use cases that previously required private groups, we’ve transformed private groups into the brand new “private channels”. Private channels will be shown mixed in with your existing open channels alphabetically, with small lock icons next to the private ones. When the time comes to create a new channel, you’ll find a new public/private toggle on the configuration screen.

原先的 Private Channel 就跟 Public Channel 混在一起了...

PSR-7:HTTP message interfaces

PHP-FIG 前幾天公告了 PSR-7 (commit d40b64cc4e64e5a5b2fe998bb0a07d0b56e12505),也就是 HTTP message interfaces

由於 PSR 的編號只是提案順序,通過不一定會照順序。只是之前剛剛好都照著順序來 (PSR-0PSR-4),這次跳到 PSR-7 是跳過了 PSR-5 (PHPDoc Standard) 與 PSR-6 (Caching PSR)。

有了對 HTTP request 與 HTTP response 的標準後,可以馬上想到的是 routing library 與 controller library 可以接上去用,測試會變的簡單一些... 之後應該會有其他的想法可以做?