幹壞事是進步最大的原動力
FOSDEM 應該是歐洲區最大的一般性的 open source conference (不是很確定)，在今年二月初的 FOSDEM 2020 結束後，投影片與錄影也陸陸續續整理出來，所以也可以去挖寶翻一翻了：「FOSDEM 2020 - Events」。
另外整理一下歷年的 event 數量，這主辦方的 scalability 能力看起來很驚人啊，目前還在長：
裡面的 event 都有依照這種技術主題整理過，所以可以自己挑有興趣的主題先快速看一下投影片，有興趣的話再看影片。當然，如果看到特定有興趣的講者，也可以考慮直接看影片...
先前看到「Learning Hiring Preferences: The AI Behind LinkedIn Jobs」這篇，LinkedIn 用機器學習提供雇主可能的對象。
依照官方的說法，這次提到的改進是透過雇主的行為調整推薦。當雇主對某個人有興趣的時候，LinkedIn 就會調整演算法去配合雇主有興趣的條件：
Based on how you interact with candidates, our algorithm learns your preferences and delivers increasingly relevant candidates across the Jobs product. If you’re consistently interested in candidates who are, say, accountants with leadership skills, or project managers who are adept at social media, we’ll send you more of those. And this all happens online in real time so that your feedback is taken instantly into account.
透過模擬 20% 的加成：
This new algorithm, which is used throughout the Jobs platform, performs nearly 20% better than the previous version in generating recommendations when we simulate our members' past hiring activity.
在 social network 這種演算法其實就是同溫層 (Echo chamber、Filter bubble)，在 LinkedIn 這樣的行為不知道會不會牽扯到 Discrimination 的議題...
AWS 推出 Amazon GuardDuty 監控內部網路：「Amazon GuardDuty – Continuous Security Monitoring & Threat Detection」。
從示意圖可以看到結合了許多 log 資料，然後綜合判斷：
In combination with information gleaned from your VPC Flow Logs, AWS CloudTrail Event Logs, and DNS logs, this allows GuardDuty to detect many different types of dangerous and mischievous behavior including probes for known vulnerabilities, port scans and probes, and access from unusual locations.
所以連 Bitcoin 相關網站也當作條件之一 XD
開了相當多區 (相較於之前 AWS Elemental MediaOOXX 系列...)：
Amazon GuardDuty is available in production form in the US East (Northern Virginia), US East (Ohio), US West (Oregon), US West (Northern California), EU (Ireland), EU (Frankfurt), EU (London), South America (São Paulo), Canada (Central), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Mumbai) Regions and you can start using it today!
在「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 的說明，看不懂就不要用，這樣會比較安全...