在瀏覽器玩 HTML5 + JS + Canvas 寫的 Diablo...

沒錯,是 Blizzard 的那個 Diablo (暗黑破壞神):「Isometric minimal-code style game at html5 canvas and javascript」,遊戲可以在「http://mitallast.github.com/diablo-js/」這頁玩...

直接用 Blizzard 的圖資搞當然是很精彩 (而且很震撼),但這樣搞不會被 DMCA takedown 嗎 XDDD

給新手看的入門:要怎麼用 Google Reader 接收資訊

在公司內被問過好幾次了,用口頭講都比較概略性的講一講。這篇文章算是欠稿欠很久了...

對於剛開始用 Google Reader,或是很少用的人,我給的建議「不要一次想要訂太多東西」,一步一步去試,每個人讀文章的習慣都不一樣,用 Google Reader 整理的「最佳方式」當然也會不一樣。

可以嘗試的幾個方向:

開 Official 的分類來放官方 blog/feed

官方的 blog (或是 feed) 通常文章數量都不多,而因為官方的 blog 都官腔官腔,看的時候也需要抱著「這是官方的 blog」的心態看。拆一個獨立的分類放,集中一起看會是不錯的方式。

你可能一時間想不到有哪些官方的 blog 可以訂。再拆細一點,你可以先從有付費的服務表列,這些是我有付錢的服務,如果有可以訂閱的 feed 我都一定會訂起來看:

然後可以把現在沒付錢的常用服務也訂起來:

然後常用的硬體、軟體都可以訂:

訂可以放空腦袋的圖片 blog/feed

等到你的 Google Reader 放了不少資訊類的 feed 之後 (而且是只有資訊類的 feed),你開 Google Reader 的次數就會愈來愈低... XD 為了解決這個問題,你要放「大量」可以放空腦袋的 feed,第一類推薦的就是圖片 (開個獨立的分類來放吧),這可以去 Tumblr 上找,像是:

  • ak47 (偶而有 NSFW 類的圖,不過大多數情況應該還好)

如果你喜歡吃東西,就找美食 blog 訂。如果你喜歡旅遊,就找遊記 blog 訂。

附帶提醒,如果你發現裡面很多置入性行銷的文章,就再另外分一個類別吧 :p

最後的提醒...

中文 (母語) 與其他語言的 blog 要分到不同分類,如果你對簡體中文不熟悉的話,把簡體中文的 blog 也拆開。因為看母語與看其他語言的速度是不一樣的,如果看很多 feed 的時候,步調不一樣會很累。

希望對一直不知道要怎麼使用 Google Reader 的人有幫助... XD

看到許多其他的 CDN...

維基百科的「Content delivery network」條目裡面有份列表 (「Notable content delivery service providers」這個段落),不過剛剛在「HTTP Archive: new stats」這篇文章裡面又看到一些沒看過的名字 (在「Sites hosting HTML on CDN」這個段落),實際看了看發現還不少沒看過名字的 CDN...

一個是 cubeCDN,一家公司在土耳其的 CDN,但官網上一堆連結都失效 XD

另外一個是 Azion,一家以巴西為主的 CDN,除了巴西以外,還有美東、英國、荷蘭、新加坡、日本。缺了美西是哪招...

各種 credential 儲存的方式 (像是連到資料庫的密碼)

John Resig (現在在 Khan Academy) 在月初的時候發表了「Keeping Passwords in Source Control」討論要怎麼儲存 credential。

這不只是開發者的問題而已,這跟 code deploy 機制也很有關。目前沒有完美的方案,不同的解法都是在不同的環境與限制下而誕生出的產物。

Galera Cluster + Heartbeat

我一向不太喜歡 Galera Cluster + HAProxy 的設計。有四個理由:

  • MySQL server 看不到 client 的 IP。
  • HAProxy 本身就是 SPoF。
  • HAProxy 會增加 latency,並且限制 bandwidth。
  • 通常需要額外的機器跑 HAProxy。

我把跑了超過半年的 Galera Cluster + Heartbeat 的經驗貼到 Codership 的 Group 上,裡面包括了設定與 script,希望能有些迴響:「HA solution - Galera Cluster with Heartbeat」。

測試 DigitalOcean 荷蘭阿姆斯特丹的機器...

續上篇「DigitalOcean 與 Linode 的比較...」,先補上上次沒抓的圖,這是 DigitalOcean 可以用的 Linux Distribution:

這次仔細檢查發現 DigitalOcean 本身沒有提供 DNS resolver,是指到 Google Public DNS

nameserver 8.8.8.8
nameserver 8.8.4.4

從阿姆斯特丹的機器過去是透過 Cogent 到法國的 Google Public DNS,需要 10ms,這數字有點差。到是 OpenDNS208.67.222.222 是走 Tinet,就在當地處理掉,只需要 0.6ms 左右,但 OpenDNS 會把不存在的 hostname 指到他們自家...

如果要用阿姆斯特丹機房的機器,在裝完機器後要記得 DNS 的部份可能要自己架,測試的時候是用 Unbound 架一個給自己用...

網路的部份:

  • 從台灣過去大約 280ms,從 Linode 東京過去大約 265ms。
  • 看起來是 Cogent + Tinet,看不太出來是以 Cogent 還是以 Tinet 為主,traceroute 時兩者都不少。
  • 大多數的 CDN 都在阿姆斯特丹當地有點,所以都沒什麼問題。不過 CloudFront 把我丟到隔壁德國法蘭克福機房 (大約多了 7ms)。
  • 如預期的,連到俄羅斯的網站大多都是直連。

Opera 換 WebKit...

Opera 決定放棄自己維護 render engine 了,將改用 WebKit:「Opera gears up at 300 million users」。

不確定是什麼樣的考量,我猜是為了省成本順便做的決定。翻了 gs.statcounter.com 的資料,Opera 的全球佔有率愈來愈低,看起來還蠻有可能的?

不過大多數的公司還是不管他吧:

YUI Target Environments

以及:

DigitalOcean 與 Linode 的比較...

DigitalOcean 因為「Linode vs DigitalOcean, performance benchmarks」這篇上了 Hacker News 熱門文章列表,把本來試用帳號的名額都用完了,現在要測試要自己花錢... XD

原文是測效能 (I/O 速度與 CPU 速度),我是看其他的部分:

  • 價錢便宜又提供 SSD (看完提供的內容與品質後,居然還可以打趴 Linode,這真是低到不可思議 XD),控制介面又是自己開發的,難怪會讓 Hacker News 的人熱起來...
  • 計費是 by hour,然後每個月的上限就是表列出來的金額,比起 Linode 是以天計算友善不少...
  • 目前機房的點有點少,只有美東 (New York) 與荷蘭 (Amsterdam),我開美東的點測試,從台灣過去大約要 200ms,從 Linode 東京過去是 170ms。
  • 可以常見的 Linux 套件 (DebianUbuntuFedoraArchLinux、...),32bits 或是 64bits 都有提供,我是裝 Debian 6.0 64bits 版本,然後直接用 apt 換成 wheezy 後重開是沒問題的,Linode 沒換成功過...
  • 網路看起來是 Level3 + Cogent,而且是以 Level3 為主力,Cogent 的部份目前只有看到部分的 Akamai 走 (static.ak.fbcdn.net 這組),不過速度也沒什麼問題...
  • 紐約本來就是大點,各家 CDN 測起來都在當地有點。不過 CDNetworks 怎麼把 N2 (n2.panthercdn.com) 丟到華盛頓啊 (大約 8ms),反而是 L1 (l1.panthercdn.com) 走紐約本地...

Twitter 上已經看到 tkalu 已經把一些東西搬過去了:

十一歲就寫木馬的小朋友真是太有前途了...

看到「AVG finds 11 year-old creating malware to steal game passwords」這篇裡面的說明:

The company said it had recently reverse-engineered one piece of malware that turned out to be the handiwork of an 11 year-old Canadian boy intent on stealing passwords used to access games such as Team Fortress.

AVG 的報告是出自「Q4 2012 AVG Community Powered Threat Report」(PDF) 的第 17 頁。

MySQL 5.6 的 GTID...

看到 Percona 的人在討論 MySQL 5.6 的 GTID (Global Transaction ID) 功能,剛剛就實際到 AWS 上開了兩台 m1.large 測試:「How to create/restore a slave using GTID replication in MySQL 5.6」。

要測試 GTID,因為剛出來沒多久,沒有多少文件可以看。MySQL 官方的「Replication with Global Transaction Identifiers」是必讀的文件。查 MySQL 官方文件時可以發現 5.6.9 (RC) 到 5.6.10 (GA) 其實還是改了不少變數名稱,如果在網路上找舊文章照抄是不會動的...

先提結論,Galera Cluster 畢竟出來很久了,成熟度比 GTID 高,建議現在先觀望一陣子,至少等 best practice 出來後再進場測試...

之前的 MySQL replication 有很多方法可以在不停機,或是停的時間很短的情況下把第一份 slave 資料與 replication 資訊生出來,舉例來說:

  • 系統如果用 InnoDB,可以用 Percona Xtrabackup 拉出。
  • 系統如果用 XFS + LVM,可以用 FLUSH TABLES WITH READ LOCK + XFS freeze + snapshot 功能拉出。
  • 甚至直接用空的 slave 跑 pt-table-sync...

但目前 MySQL 官方對 GTID 給的方式是 read only + mysqldump,這就算用 xtrabackup 也應該快不到哪吧... 這幾個月應該會一直有文章出現,裡面應該會有偷吃步的方法,看到再來測試看看 :o