連結在這：http://www.percona.com/webinars/2012-08-15-mysql-indexing-best-practices。
裡面除了介紹 MySQL Index 的種類與運作方式以外，也提到了「正確」的下 Index 的方法。由於 Index 會影響寫入的速度，並不是下愈多 Index 就越好的，而是應該視應用的 Performance critical query 的狀況來下適當的 Index。推薦會碰到 Database 的人（包含 netadmin 與 developer）都要去看看。
這是今年 4/26 在 Oracle 辦的 MySQL 研討會的分享。當時還沒有測 Percona Cluster 所以沒有相關的資訊…
之後有機會的話再補上。
自從入手 Nexus 7 之後，看 RSS Feed 的工具就從電腦改成 Android 平版了。7″ 的大小不會像手機一樣看到眼睛脫窗，也比 iPad 適合在捷運上單手手持。而 NewsRob 的背景同步功能則讓我不用每次出門前按下同步按鈕，只要把 Nexus 7 塞進包包就能出門。
不過，因為 Nexus 7 不支援 3G，如果看完要記下來，就沒辦法直接存到 delicious。用 Google Reader 的星號功能是一個解法，但是沒辦法下 tag。
能夠下 tag 又能離線存取的服務，之前試過 pocket (以前叫做 read it later) 還蠻好用的，因此就選它啦。離線紀錄下來的 URL，在回到有網路的地方時，會自動 sync 回去 Server 中。
pocket 也有提供收錄文章列表的 RSS Feed，預設是需要輸入密碼的，但可以在設定裡面改成公開(不需密碼)。我的 Feed 在 http://getpocket.com/users/jnlin/feed/。
根據 Wikipedia 閏秒這個條目，最近一次的閏秒剛好發生在 GMT 2012/6/30 23:59:60，也就是台北時間昨天早上 8:00 左右。結果踩到了 Linux 以及一些軟體的 Bug：
只要重開 OS / App 就可以解決問題。
作手機 Client 的人應該常常遇到這種問題：User 因為某些原因（像是常常賴床起不來），把手機的時間調快了 5 分鐘。如果用的又是 OAuth 這類會有 expire 機制的 Protocol，就會遇到認證失敗的問題。
一般的解決方法是，利用一台「時間準確」的 Server，提供正確的時間。可以透過 HTTP Header（可以少一個 request），也可以透過一個 API，例如：http://emma.pixnet.cc/index/now。最近的 Google Authenticator 也有類似的機制。
不過，不只是 Client 會有這樣的問題。雖然 NTP 已經很普遍了，但總是會遇到因為設定錯誤，或是防火牆擋掉，或是 blah blah 等等的原因，導致 Server 時間跑掉的情形。當然，也有可能是軟體 Bug 造成的問題，導致 Server 傳回的時間是錯誤的。
最近就遇到這樣一個好玩的現象：寫 Parser 的時候，會看一下 Server 給的 Last-Modified 的 header 來判斷是否要 invalidate cache，結果發現有的 Server 會回傳未來時間…XD
所以，如果你的 Server 有跟 NTP Server 定期對時的話，應該使用自己 Server 的時間，其他任何外部來的時間都不應該相信，一定要檢查合不合理。
CloudFront 支援 Dynamic Content: 原本 CloudFront 對於 Query String （也就是 ?key=value 這串東西）是不支援的，在計算 Cache Key 的時候會直接捨棄掉。現在已經可以在 Console 設定是否要將 Query String 納入成為 Cache Key 的一部分。
SES 支援 Domain 認證: 原本 SES (Simple Email Service) 的寄件者 Email 位址需要分別認證，如果寄件者很多的話，認證是件很麻煩的事情。另外就是有時候寄件者是個機器（程式），無法收到 AWS 寄來的認證信件。使用 Domain 認證之後，只要在 DNS 設定裡面加上一個 TXT Record，在這個 domain 下的所有 Email Address 都能夠透過 SES 寄信了。
本日蘋果新聞：5月電價調漲 電信3雄IDC業務先受惠
我相信成本增加導致營收增加（毛利沒增加）對股價會有正面效用（這篇是在財經新聞），但是電費是經營IDC的最大成本!?
也許對 IDC 業者來說可能是吧。
但是對台灣的 ICP (Internet Content Provider) 來說，最大的成本，不是電費而是頻寬費。
在美國， 1GBits/s 一個月台幣 X 元（含機櫃、冷氣、電費）。台灣 1GBits/s 一個月超過 40X 元。
如果以台灣這種低電價來說，電費居然是經營 IDC 最大成本的話，表示頻寬費用賺太兇了…
關於台灣的頻寬費用，有一篇好文值得複習：畸形的台灣網路環境(Peering)
三月 AWS 的動作很多…
首先是 AWS EC2 與相關服務降價。包含常用的 RDS 與 ElasticCache，On-Demand 大約降價 10% 左右，三年合約的 Reserved Instance 更降價 30%。
接著推出新的 Instance Type。原有只支援 32 bit OS 的 m1.small 與 c1.medium 現在可以支援 64 bit 了，而在 m1.small 與 m1.large 之間多了一個 m1.medium，價錢和規格都是 m1.small 的兩倍。
當這些 Instance Type 都支援 64 bit OS 之後，有些原本在 t1.micro 上跑太小，而到 m1.large 上跑又太大的應用，就可以無痛改用 m1.small 或是 m1.medium 了，不需要特別再準備 32 bit OS 的 AMI。
為了慶祝 AWS 支援 64 bit OS，Alestic 把 32 bit OS 的 AMI Link 從網頁上移除了XD
碎碎念：如果早點公布就好啦，在公布的 30 分鐘前剛把 Reserved Instance 刷卡買下去…Orz
PHP 5.4 在 3/1 已經發布了，其中我覺得比較重要的幾個新功能：
$a = [1,2,4,5]; 這樣的 Array Notation。func()[0] 和 (new Foo)->bar() 這樣的寫法。然後 5.4 剛出的新功能就有 bug 了…XD
unbound 是個輕薄短小好用的 DNS Resolver，也支援 DNSSEC。
這幾天剛好遇到一個問題：有一組 Cluster 的 Server Loading 分布不均，但一個小時後 Loading 會轉移 Server，原本有 Loading 的變成沒 Loading，原本沒 Loading 的變成有 Loading。
經過檢查之後發現是 Unbound 回傳 Resource Record (RR) 的順序問題。
按照這篇 Maillist 的說法，unbound 在回傳結果的時候，會完全按照原本結果的資訊回傳，包含 RR 的順序。所以 RR 的順序會固定一個 TTL (被 unbound cache 住了)，而剛好我們把 TTL 設為一個小時。
除了把 TTL 設短一些外，寫 Client 程式的時候，如果考慮有使用到 DNS Round Robin 來作 Load Balance 的話，最好不要固定使用回傳的第一個 RR 會比較好。