主要是參考「WineHQ – Diablo III 1.0.*」這個網頁，另外找資料的時候有找到「[心得] Diablo III on Ubuntu 12.04 x86 – 看板 DIABLO – 批踢踢實業坊」這篇。

我是使用沒有 non-patch wine 1.5.4 跑的 (透過「Latest official WineHQ releases : “Ubuntu Wine Team” team」這邊提供的 ppa)，所以必須先用 Windows 裝完 Diablo III 後再 copy 到 Ubuntu 裡面。

登入問題用 echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope 解，但這個方法需要在每次重開機後再設定一次，在 /etc/sysctl.conf 內設定 kernel.yama.ptrace_scope=0 可以使得系統在每次重開機自動設定。

特效全開還是跑得不錯…

遊戲一向都是硬體升級的主要動力… :/

Blizzard 的遊戲都會發展 Windows 與 Mac 兩個平台，Diablo III 這次也是一樣。CPU 與記憶體一向都是小問題，顯卡才是真正的大問題…

手上的 MBA 與 Mac Mini 都是 Intel HD Graphics 3000，有支援但是效果開不起來，而桌機則是 8600 GT，也是差不多的狀況，加上 NTFS resize 一直失敗，決定去光華商場弄一顆硬碟與一張顯卡來跑，在網路上翻了一下資料，看起來 GTX 550 拿來玩 Diablo III 應該是夠用…

買完回到家後查資料才發現 GTX 550 全力跑的時候是個吃電大怪物，桌機上面加上新硬碟後就有四顆硬碟，目前靠 350W 的 Power 推，這樣大概不夠用，懶得出門只好上 24h 去弄顆新的 Power，應該是有機會在光華開門前就到家… :o

所以又回頭到 Mac Mini 上面安裝起來玩，果然頓頓的，升了一級後還是先去睡覺，等早上來裝新的 Power…

引用 CTO Werner Vogels 寫的「Dynamic Content Support in Amazon CloudFront」這篇好了，雖然沒有講完整，但把重點都提到了，而且比官方網誌「Amazon CloudFront – Support for Dynamic Content」這篇清楚…

這次 AWS CloudFront 上的功能都可以在 AWS Management Console 上設定，不需要另外安裝 3rd party 軟體或是自己寫程式呼叫 API。

這次最主要的更新在支援 query string。在之前的版本，這兩個 url 會被 CloudFront 當作是同樣的 url 而被 cache 成同一份：

• http://www.example.com/user.php?username=gslin
• http://www.example.com/user.php?username=gslin2

而這次可以設定是否要將 query string 納入計算。

另外一個重要的設計是支援 Cache-Control 與 Expires，當 Cache-Control 給出 no-cache 的時候，新版的 CloudFront 可以依照 Cache-Control 的要求處理。

有了這兩個改善後，本來需要在 server workaround 的事情就可以交還給 CloudFront 處理。之後應該是試著支援像 Akamai 的 Dynamic Site Accelerator 的功能？另外一方面也有可能讓消費者自己選擇 PoP？

功能愈來愈完整了…

把主機的 MySQL 從 5.1 升級到 5.5 後，想把主機上的 MyISAM table 都換成 InnoDB。

基本上是參考「Quick tip: how to convert tables to InnoDB」這篇提到的工具以及說明。

文章裡所提到的 mk-find 是 2008 年的時候的名稱，當時這隻工具是在 Maatkit 裡面，而 2012 年則已經併入 Percona Toolkit，所以文章裡本來是 mk-find 的地方要改成 pt-find。

另外我不想嘗試把 mysql.* 改成 InnoDB (我不知道會不會爆炸)，所以我的做法是只用 --print，然後丟到 vim 裡面加上 ALTER TABLE 以及 ENGINE=InnoDB ROW_FORMAT=COMPRESSED;。

pt-find 這個指令看起來可以用在很多地方，之後應該會有不少用到的機會…

環境是內部有兩台互相做 HA 的 server (用 Heartbeat 或是用 CARP)，然後給一個內部用的 domain 指到兩個 IP address，於是發現不太平均：「Unbound 回傳 RR Set 的順序問題」。

2010 年的時候就有人提過要這個功能，然後被打槍：「[Unbound-users] Round Robin DNS」，最主要的理由是「這應該是 client 要做的事情」。

2012 年三月有人決定自己來：「[Unbound-users] patch implementing round robin rrsets」，patch 本身蠻簡單的 (不過看起來不能保證 thread-safe)，另外也有一些 RFC 隱性希望 DNS resolver 可以處理 round robin 的事情。

四月的時候有人把 patch 修過，解決了 thread-safe 問題：「[Unbound-users] patch: rrset-roundrobin/minimal-responses」。

看起來之後的版本有機會內建了…

2009 年在 Ptt 寫的文章有提到不少 hosting plan，2012 年現在有不少變化…

VPS 的部份，Linode 的 CPU 一向是 C/P 值超漂亮的方案。最小的方案從 384MB RAM 變成 512MB RAM (價錢沒變，仍然約 USD$20/month)，在有 swap 的情況下，即使跑 Apache 與 MySQL 也應該還算堪用。

Linode 另外一個改變是多了東京機房。東京機房與台灣各 ISP 之間的 latency 都相當好。當以台灣使用者為主要族群而挑選 VPS 時，在東京的 Linode 主機通常是個好選擇。如果在 Linode 上面有 High Availability 需求，也有 NodeBalancer 可以用 (2011 年，Introducing NodeBalancer)。

Linode 已經算是不錯的方案，但如果你對 latency 非常重視 (日本與台灣之間大約有 30ms 的 latency) 而一定要使用台灣內部的 VPS (像是遊戲的伺服器)，那麼中華的 HiCloud 會是一個可以考慮的方案。

PaaS 的部份，目前比較有名的是 Heroku，支援的語言多，而且有 free quota，對於一些小站台或是測試應用應該是沒什麼問題，不過目前只有美東 us-east-1 機房 (Heroku 用 AWS 為底層)。另外 AWS Elastic Beanstalk 的方案也可以看看，目前支援 Java 與 PHP 兩種語言，區域比較多。

如果是 IaaS 的部份，AWS 能提供的功能比較多，AWS 東京機房對台灣的速度也不差。另外 AWS S3 在雲端靜態儲存這個領域還是領先者，就算用 VPS 或是 Dedicated Hosting 也還是可以考慮把一些東西放到 S3 上。

Dedicated Hosting 的部份，目前還會選的是美西的 Energy Group Networks (EGIHosting) 以及 Limestone Networks。需要大頻寬的時候可以到 Dedicated Servers 這頁翻翻，或是寫信跟 EGIHosting 要 quote，當你 commit 1Gbps 含機器的價錢大約是 USD$1/Mbps (台幣 NTD$30/Mbps)，連台灣的頻寬應該是透過 HE 或是 nLayer 連進來。

至於 CDN 服務，我的建議是，如果你不知道哪個比較好，就不要用吧… 等到你開始 profiling & analyze 後再回頭決定。

在 Hacker News 的摘要上看到的，對於政府提供數位服務，英國政府嘗試訂出設計原則 (雖然目前這份文件還是 alpha 版本)：「Government Digital Service Design Principles」。

這份原則是延伸自原來的七大守則：

其中有幾點相當棒：

• 第二條的「Do less」，如果有人已經做了類似的事情，就直接連出去，不要做重複的事情 (If someone else is doing it — link to it)，政府只需要提供其他人無法提供的資訊 (We should concentrate on the irreducible core)。如果能夠提供 API 之類的介面幫助其他服務做的更好，就提供出去讓其他人再利用 (If we can provide resources (like APIs) that will help other people build things — do that.)。
• 第四條的「Do the hard work to make it simple」直接提到，使用者會用政府的服務是因為沒有替代方案：如果不努力讓服務簡單易用，就是在浪費使用者的時間。(With great power comes great responsibility — very often people have no choice but to use our services. If we don’t work hard to make them simple and usable we’re abusing that power, and wasting people’s time.)
• 第五條的「Iterate. Then iterate again.」，考慮風險，如果一次到位的風險太高，邊打邊跑推出服務：從 alpha 階段進入 beta 階段，再從 beta 階段趨近於成熟，每個階段去看實際的反應，而不是一開始就畫一張大餅猜測使用者需要什麼。
• 第八條的「Build digital services, not websites」與第十條的「Make things open: it makes things better」，標題就說明得很清楚了。

即使是一般商業產品的設計也是通用的原則…

從 Colin Percival 的 Twitter 上看到的：

Looks like Amazon Web Services is giving away $50 credits which can be used for running FreeBSD on EC2: http://aws.amazon.com/solutions/global-solution-providers/microsoft/aprilcredit/

活動的網址在「$50 AWS Service Credit for Microsoft Windows Server Instances Running on Amazon EC2」這裡。照說明是用在 AWS EC2 的 Microsoft Windows Server 上，不過把 code 輸入進去後寫了一堆 product：

有打算用 FreeBSD 的人應該是不會有問題 (參考「FreeBSD on EC2」這個頁面的說明)，其他的服務不知道會不會也能用到，下個月就知道了 XD

「Client-Side Error Logging With Google Analytics」這篇提到可以用 Google Analytics 紀錄 JavaScript 錯誤…

不過這不是即時的紀錄，倒是作者有提到可以交叉比對，當發生 JavaScript 錯誤對於其他參數的影響：

Track the impact of client-side errors on other business metrics. With the reporting in Google Analytics you can see how these errors are affecting bounce rate, conversion and sales.

花了一些時間設定 mutt，本來在 terminal 上面沒打算看 html 信件，不過後來還是決定設起來，至少可以看到 html 的文字部分再決定要不要轉到 gmail 上面看…

在 ~/.muttrc 裡面加上：

auto_view text/html

另外在 ~/.mailcap 裡面指定用 w3m：

text/html;/usr/local/bin/w3m -I %{charset} -T text/html -dump %s; copiousoutput