幹壞事是進步最大的原動力
在「Homebrew Analytics Install On Request Events — Homebrew」這邊，Homebrew 利用了傳回來的資訊算出 2016/07/14 到 2017/07/14 的安裝套件次數，列出前一千名。(我是把他關掉，因為隱私問題不想要傳出去... 參考「Homebrew 會將安裝資訊送到 Google Analytics 上」這篇。)
比較有趣的是第一名的 node 超級多，比第二名加第三名的 git + wget 還多...
拿來翻一翻還 ok，順便看一下大家用什麼...
以前要記錄行為會透過 AWS Lambda 轉丟到其他帳號下記錄，有一堆眉眉角角的東西要注意，現在則是直接支援了：「New – Cross-Account Delivery of CloudWatch Events」。
文章裡有提到兩種用途，其中一種就是做安全性的記錄：
Separation of Concerns – Customers would like to handle and respond to events in a separate account in order to implement advanced security schemes.
另外一種則是為了將記錄丟到同一個地方：
Rollup – Customers are using AWS Organizations and would like to track certain types of events across the entire organization, across a multitude of AWS accounts.
價錢看起來沒什麼問題，每一百萬次收 USD$1：
Events forwarded from one account to another are considered custom events. The sending account is charged $1 for every million events (see the CloudWatch Pricing page for more info).
在 Amazon ECS 上面固定時間跑某些東西，以前得自己用 AWS Lambda 帶 (或是自己架，不過這樣就要自己考慮 High Availability 架構了)，現在則是直接支援：「Amazon ECS Now Supports Time and Event-Based Task Scheduling」。
Previously, you could start and stop Amazon ECS tasks manually, but running tasks on a schedule required writing and integrating an external scheduler with the Amazon ECS API.
Now you can schedule tasks through the Amazon ECS console on fixed time intervals (e.g.: number of minutes, hours, or days). Additionally, you can now set Amazon ECS as a CloudWatch Events target, allowing you to launch tasks by using CloudWatch Events.
Mark Callaghan 寫了篇關於 performance_schema 的用法 (很短)，讓大家先把這個參數開習慣，雖是入門推廣班：「Short guide on using performance_schema for user & table stats」。
他推薦的兩個資訊是：
select * from table_io_waits_summary_by_table select * from events_statements_summary_by_account_by_event_name
當使用 5.7+ 時，可以考慮這兩個：
SELECT * FROM sys.schema_table_statistics SELECT * FROM sys.user_summary
簡單到不行，但卻可以幫不少忙... 很棒的入門推廣班 XDDD
Google Analytics 推出了 Autotrack 工具，讓開發者更容易整合：「Introducing Autotrack for analytics.js」。
可以看到有些地方是將 Unobtrusive JavaScript 的概念拿出來用，像是 Declarative event tracking 這邊用 data attribute：
<button data-event-category="Video" data-event-action="play">Play</button>
對於還沒有針對 Google Analytics 客製化整合的人都會有幫助：
While anyone could use and benefit from autotrack, the library is primarily geared toward sites that do not customize their current analytics implementation and would like to take advantage of the features described in this article.
GitHub 上的說明可以看到預設了非常多常用的功能，像是 socialTracker 預設就有提供 Facebook 與 Twitter (咦，你們自己家的 Google Plus 呢？)
不過這個軟體有免責條款，不屬於 GA 的正式產品：
The autotrack library is not an official Google Analytics product and is not covered by Google Analytics Premium support. Developers that choose to use this library are responsible for ensuring that their implementation meets the requirements of the Google Analytics Terms of Service and the legal obligations of their respective country.
看起來先進很多，之後自己開發東西拿出來用用...
在「New Event Notifications for Amazon S3」這邊提到的重點：
The bucket owner (or others, as permitted by an IAM policy) can now arrange for notifications to be issued to Amazon Simple Queue Service (SQS) or Amazon Simple Notification Service (SNS) when a new object is added to the bucket or an existing object is overwritten.
也就是說，S3 上有變動時會透過 SQS 觸發後續行為。由於這是 AWS 自己提供的功能，解決了以往「上傳檔案後自己觸發 SQS」不能保證 atomic 的問題。
好像馬上就想到某個專案可以用到...
codership (Galera Cluster 背後的公司) 剛剛發了一篇文章，說明將 MySQL 轉換到 Galera Cluster 有哪些事情要先處理：「5 Tips for migrating your MySQL server to a Galera Cluster」。
純粹技術上的事情大致上是這樣：
另外幾點不是技術上的問題，而是 policy 應該規劃的事情... 把事情列出來，多隻眼睛檢查後再一步一步照表操課。
PS：對於 Galera Cluster 不熟的人可以先去看官方網站以及 Percona 的說明，看不懂就不要用，這樣會比較安全...
hashchange 是 HTML5 event，紀錄一下目前支援的情況：
目前 IE6/IE7 常見的模擬方式是透過 hidden iframe 做類似的效果...
另外在偵測瀏覽器是否有支援 hashchange 可以利用「Detecting event support without browser sniffing」這篇說明的方式偵測是否有支援特定的 event，可以避免使用 browser sniffing。