幹壞事是進步最大的原動力
AWS 宣佈 t3 系列的機器也可以上 Dedicated Single-Tenant Hardware 了，也就是實體的機器不與其他人共用：「New – T3 Instances on Dedicated Single-Tenant Hardware」。
會需要避免共用實體機器，其中一種常見的是需求是 compliance，主要是在處理資料 (尤其是敏感資料) 時要求實體隔離，以降低 side-channel attack 或是類似攻擊的風險：
Our customers use Dedicated Instances to further their compliance goals (PCI, SOX, FISMA, and so forth), and also use them to run software that is subject to license or tenancy restrictions.
另外一種情境是 AWS 的美國政府區，直接與一般商業區的系統切開，不過這也得有經濟規模才有辦法這樣玩...
uBlock Origin 是一個在瀏覽器上擋廣告的軟體，以前在推廣的時候都只提到可以過濾掉網站上的廣告，大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD)，但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」，大家接受度意外的爆高，不過這有點扯遠了，回到原來的主題上...
先介紹一下 uBlock Origin 的開發模式，除了一般的 stable 版本外 (「uBlock Origin」這組)，另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組)，這樣讓使用者比較容易安裝與測試，這個方式也可以在 Tampermonkey 上看到。
這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知：「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。
拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」，也就是不能把目的不同的東西強迫使用者綁在一起使用：
Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose
後續的 1.22.5rc2 也被拒絕，然後他回信詢問了 CWS 官方，得到的仍然是罐頭回應，然後他就決定丟著 (而這個作法還蠻聰明的)，接著這件事情就被丟著變成 PR 事件上了一些媒體，然後昨天就突然解了...
Google 最近的動作愈來愈多了，一方面在嘗試避免觸動反托拉斯法的情況，儘可能打壓這些擋廣告的套件...
AWS 推出了 AWS Single Sign-On：「Introducing AWS Single Sign-On」、「Announcing AWS Single Sign-On (SSO)」。
將 SSO 當成一個服務來賣的概念，可以將既有的 Active Directory 服務掛上去當後端，然後對外透過 SAML 2.0 接上各種服務：
目前掛在 us-east-1 上，AWS SSO 的部份不另外收費：
There is no additional cost to enable AWS SSO. It is now available in the US East (N. Virginia) Region.
從官方的截圖可以看到包括了蠻多常用的 SAML 2.0 服務，也可以自己設定：
Jenkins 的 Blue Ocean 計畫打算改善讓人頭痛很久的操作體驗了：
Blue Ocean is a new project that rethinks the user experience of Jenkins.
Jenkins 讓人頭痛有兩個面向，一個是界面很難讀，另外一個是操作流程很沒有規則，所謂「熟悉 Jenkins」其中一個很艱難的任務就是要背下一堆功能「蔵在哪邊」。而這次 Blue Ocean 想改善的事情看起來主力放在界面，對於流程修的比較少... 即使如此，這還是可以讓使用的人減少一些痛苦就是了...
成功與爆炸的表現：
在專案頁面的後面有提到 Blue Ocean 用的技術：
Blue Ocean is built as a collection of Jenkins plugins itself. There is one key difference, however. It provides both its own endpoint for http requests and delivers up html/javascript via a different path, without the existing Jenkins UI markup/scripts. React.js and ES6 are used to deliver the javascript components of Blue Ocean. Inspired by this excellent open source project (react-plugins) an <ExtensionPoint>pattern was established, that allows extensions to come from any Jenkins plugin (only with Javascript) and should they fail to load, have failures isolated.
又是個不需要用 SPA 呈現的東西跑去用 React 了...
Mozilla Developer Network (MDN) 寫了一篇關於 JavaScript 的介紹文章，算是以現在的角度來教 JavaScript：「A re-introduction to JavaScript (JS tutorial)」。
不是給完全不懂的人入門看的，而是對程式語言有了解的人看的。
文章裡面不單純只是教學，還引用了許多重要的文獻，尤其是 ECMAScript 規格書。有想要考據確認規格書怎麼定義會很方便。
而最後面還提到了 browser 上 DOM 實作時的 memory leak 問題以及解法，這對於現在 single page application 的應用也愈來愈重要了。
維基百科描述了當初沒有規劃多語系與多系統的帳號管理，而產生出來的 migrate 計畫：「Single-User Login provides access to all wikis」。
整個計畫到實作完成長達十年 (大約從 2004 年開始有想法)，接下來進入最後階段：
This week, we will begin the process of renaming the remaining 1.46 million accounts – those which have not responded to all attempts at outreach. That process is expected to take approximately one to two weeks.
從第一次編輯到現在也好久了啊...
在寫 shell script 時，[ 與 [[ 到底用起來有什麼不一樣？查出來記錄起來：「What is the difference between double and single square brackets in bash?」。
第一高分的答案 (由 Kyle Brandt 回答) 與第二高分的答案 (由 abhiomkar 回答) 都值得看，尤其是 abhiomkar 寫的範例很清楚：
$ [ a < b ] -bash: b: No such file or directory $ [[ a < b ]]
對判斷式子裡面的解讀是不一樣的。
剛剛看到 AWS 宣佈 AWS IAM 支援 SAML 2.0：「AWS Identity and Access Management Using SAML」。
SAML 是 Single Sign-On 協定的一種，2001 年就推出來了，不過其中用到的架構頗為複雜，由於是 XML 交換技術，再加上要在 XML 上面簽名 (XML Signature)，其實我不是很喜歡這東西... @_@
當初會硬要接觸是因為 Google Apps 的 SSO 是使用 SAML，真是懷念啊...
由於是個公開標準，有不少企業 SSO 方案都有支援 SAML。而 AWS IAM 支援 SAML 就相當於讓控管的部份整合起來了... 我好像也應該來弄弄了？
「MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。
在文章裡提到，在 5.6.3 之前的版本，MySQL replication 都是 single-threaded，所以當 master 可以充分發揮多 CPU 能力時，slave 仍然要一個更新跑完才會跑下一個更新。
舉例來說，假設 master server 上有兩個 thread 在跑：
UPDATE table1 SET foo = 0 WHERE ...; (SQL 1，假定是 CPU bound，需要跑 100 秒)UPDATE table2 SET bar = 1 WHERE ...; (SQL 2，也假定是 CPU bound，也需要跑 100 秒)假設 thread 1 先執行完，這時候 slave 就會在跑完的時候收到 SQL 1，然後把資料同步進去。等到 100 秒過去後，再跑 SQL 2，再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。
在 master server 執行時會是這樣：
兩個 SQL query 可以同時跑。
到了 slave 時，在 MySQL 5.6.3 之前的 replication 會變成這樣：
可以看到還是得先執行 SQL 1 再執行 SQL 2，所以最長會有 200 秒的 replication lag。
而 5.6.3 之後支援 multi-threaded replication，可以用 slave_parallel_workers 指定平行執行 SQL query 的數量，這讓 master server 與 slave server 之間的 replication lag 降低不少：
在收到同步的 SQL 指令後就可以同時跑，這讓 replication lag 降到 100 秒。
不過還是要提，如果希望把資料同步問題降到最低，那麼 Galera Cluster 可以解的更徹底，不論是寫入的那台 master server，或是其他的 master server (在 Galera Cluster 架構裡都是為 master)，一律都是同步執行：
不會有 master server 與 slave server 不同步的問題，可以減少很多 application 層的麻煩...