幹壞事是進步最大的原動力
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 層的麻煩...