最近 Chrome 18 Stable 版本發佈。有些人發現了一個問題：中文字體變醜了。所謂的醜，具體上來說是「使用了另一種大家以前不習慣的字體」。

你會在 Facebook 、 Plurk 等網站看到「跟以前不太一樣的中文字」，例如以下是 Facebook 的字體在 Chrome 18 以前及 Chrome 18 的比較：

甚至是在 Wikipedia 載入的過程中看到字體會跳動。有影片為證：

OS X 版本：日文假名、英文字一起遭殃

好死不死的是，在 OS X 的 Chrome 是把簡體中文換成 STHeiti （华文黑体，長得很像 Heiti SC ，也就是 OS X 預設的系統字體「黑體-繁」的簡體版），因為我把系統字體換成 Hiragino Sans GB ，所以就又看到了天底下最醜的日文假名：

還有，在 OS X 的繁體中文換成儷黑 Pro ，導致以往在 OS X 會自動 fallback 到系統字體 Helvetica 的拉丁字，現在全都走樣了：

我對字體比一般人敏感，所以當我在 beta 發現這些事的時候，非常受不了，就換回 stable 了，以為這是 bug 總有一天會修好的，結果竟然上了 stable （！）。

此外，我還很討厭 Heiti SC / Heiti TC 或儷黑 Pro 當做內文字體，主因是 OS X 裡面的 Heiti 系列字體，粗體不夠粗，而儷黑 Pro 沒有粗體（你看到的都是軟體模擬的），這我不能接受。因此實際上我的 OS X 是換成英文版，並且通過 TCFail 協助把中文的字體改成 Hiragino Sans GB （佟青黑體）。沒記錯的話，當時 TCFail 就是因為大家討厭 Heiti TC 所以才出現的修改器。

Chrome 是我打開電腦到關閉電腦都會使用的軟體，一天到晚看著它，當然希望要看到漂亮的字體（至少是我自己修改作業系統設定到滿意的），而不是由他自己決定字體。

Chromium Team: 要讓大家可以依文字換字體

既然是碼農，又剛好 Chrome 是 Open Source 的 Chromium 改來的，那當然要發揮碼農的天性：「開票問！」我去 Chromium 的 issue tracker 很兇地問說為什麼要由 Chrome 自行決定字體？使用系統的 fallback 不好嗎？

GitHub has its official URL Shortening service, GIt.io. You can generate a shortened URL of a GitHub URL by sending an HTTP POST request to its API endpint, for example, through the command line:

$ curl -i http://git.io -F "url=http://github.com/..."

It will return a 201 Created response, with the shortened URL stored in the Location response header.

However, if you often need to shorten an URL on GitHub.com, it might be annoying typing the command manually each time.

I made a Chrome Extension to do that in a really easy way. When visiting a page on GitHub, you’ll see a small git.io icon at the end of address bar, click it, and the shortened URL will be generated. You can copy it to the clipboard by clicking on the shortened URL.

Get It Now!

It’s available on the Chrome Web Store (and the source code is on GitHub, too). Give it a try and see if it saves your time!

Limitations

No Custom Code

According to GIt.io’s documentation, we can specify code=yay to generate a shortened URL with preferred code, in this example, http://git.io/yay. But the purpose of this extension is to help you shorten URL with one click, and so far I have no idea on how to design an interface for the preferred code. If you have a good idea, please tell me.

GitHub Domains Only (Indeed)

Currently it only supports URLs with hostname equals to one of these:

• github.com
• gist.github.com
• raw.github.com
• developer.github.com
• develop.github.com

By invoking the API endpoint http://git.io with a non-GitHub URL, the server will return a 422 Unprocessable Entity error response, along with the body text:

URL must match /^((gist|raw|develop(er)?)\.)?github\.com$/

That’s how I limit the supported domains.

Now I’d like to talk about 2 things about Ajax that I learned from this project.

Ruby 1.9.2 is currently the most popular Ruby runtime. We used to install it through RVM by typing rvm install 1.9.2. But it does depend on GNU C Compiler (GCC), which has been removed from the new Xcode 4.3 (and also from the Command Line Tools). Although UNIX tools for building programs exists, including LLVM and LLVM-GCC, there is no official GNU C Compiler, which is required to build some programs like official Ruby 1.9.2 interpreter (YARV).

At this point, Ruby 1.9.2 does not support LLVM-GCC. If you type rvm install 1.9.2, you’ll get the error:

The provided compiler '/usr/bin/gcc' is LLVM based, it is not yet fully supported by ruby and gems, please read `rvm requirements`.

Although Ruby 1.9.2 can be compiled with Clang (LLVM’s compiler), there might be problems. If you try to force --with-gcc=clang, you’ll get a warning message:

Building 'ruby-1.9.2-p318' using clang - but it's not (fully) supported, expect errors.

In fact, it can’t even pass its own test scripts. I did compiled Ruby 1.9.2-p318 with Clang successfully, but when I run make test in the source directory, 8 out of 935 tests failed.

Downgrading to Xcode 4.1 (comes with GCC) will resolve the problem, but I want to keep the latest version of Xcode. Luckily if you upgrade from Xcode 4.2.1 (as I did), you may still have /usr/bin/gcc-4.2 in your system. But if you did a clean install, you will not have that compiler.

I don’t want to take the risk caused by building Ruby 1.9.2 with Clang. So I built it with a manually-compiled GNU C Compiler.

Here is how.

Shortcut for Unix geeks: Get the GCC tarball, make and install it, and rvm install 1.9.2 with that compiler.

Note: rvm install 1.9.3 works fine with Clang. This article is for 1.9.2 only.

如果你跟我一樣是 Markdown 的愛用者（就像 Blog 也用 Markdown 寫），你或許常常在引用資料的時候一直要按 Ctrl+C、Ctrl+V 的快速鍵。遇到圖片還得用滑鼠按「複製圖片網址」。有時我會覺得我手指快斷了。

Copy as Markdown 是我做的 Chrome Extension ，專門做這些事：

1. 把目前的分頁標題及網址複製成 Markdown
2. 按右鍵把超連結複製成 Markdown
   • 如果你是在圖片上按右鍵，則複製出來的會是連結包圖片 [![](img url)](link url)
3. 按右鍵把圖片複製成 Markdown
4. 把目前視窗的所有分頁及網址複製成 Markdown 的列表（！）

一按就完成，手指可以空出來做更多事，我是說寫稿。

載點

Chrome 網路商城由此去 、原始碼由此去 (MIT)。

截圖

大概像這樣（其實下圖的 markdown code 我也是直接用這個 extension 複製的… 超懶人 XD）：

Known Issues

已知問題有幾個：

1. 在 Windows 的 Chorme，複製連結的時候，不會複製連結文字。這個原因是 Mac OS X 會自動在按右鍵的時候就選取文字，但 Windows 版本不會。這是我上架之後才發現的 bug ，沒用 Windows 測試真的不行 orz
2. 複製圖片的時候，抓不到 alt 屬性；這個我還在找答案，很顯然直接從 Chrome 的 Context Menu OnClickData 物件 是抓不到的。這個問題要是解決了， 1 或許也就解決了。

Ruby Taiwan 是從 Ruby China fork 出來的論壇系統。原先 Ruby China 後端的資料庫系統使用的是 MongoDB，並搭配 Mongoid 這套 ORM for Rails，完全取代掉 Rails 的 ActiveRecord + 關聯式資料庫（如 MySQL） 的組合。

據說 MongoDB 在效能上比 MySQL 有過之而無不及，但因為 Mongoid 無法應用一些 ActiveRecord 特殊的功能或專屬的 gem，導致 Ruby Taiwan 要 refactor code 愈來愈困難，可以說是還沒享受到 MongoDB 的好處，就已經被 unmaintainable code 絆住腳了。因此 Ruby Taiwan 便決定要整個搬去 ActiveRecord + MySQL 。至於效能的話，最後面會提到。

不知道是吹著什麼風，現在很流行從 MySQL 搬去 MongoDB ，卻不流行反著搬， Google 一下關於 MongoDB 到 MySQL 的關鍵字，出來的全都是 MySQL 到 MongoDB 。只有一篇文章簡單地提到 MongoDB 到 MySQL 時要注意的一些事情，而且剛好他也是用 Ruby on Rails ，總算還是有一些參考資料。

步驟大概是這樣：

1. 先把 ORM 換成 ActiveRecord
2. 把 Mongoid 寫成的 model 一個一個改成 ActiveRecord 版本
   • schema 要改，且需要注意 MongoDB 與 MySQL 資料型態的差異
   • Mongoid-only method 要改
   • 有些硬幹的資料模型要整個 refactor 掉
3. 搬資料

以下就把這次搬家時改到的東西寫下來。

遷移過程的 commits 在 Ruby Taiwan 的 repository 。

雖然我搬了很多文章過來新站，但還是有不少文章沒有搬的。有一些是我還在觀察要不要轉，如果看的人很多可能就會搬過來。

不過這都不是重點，總之我實作了，在要噴 404 Not Found 的時候，轉址去舊站。

改寫 Sinatra 的 Not Found 程式

因為 Octopress 是採用 Sinatra 這個 Rack Middleware ，所以可以直接利用所有 Sinatra 支援的功能，包括用 redirect 轉址。

當然，因為需要執行 rack 的程式碼，所以我的 blog 是放在 Heroku 的。

在 config.ru 這個檔案裡面，有實作如果檔案找不到的時候，會輸出 404.html （見此），我要的是轉去舊站，所以這樣改：

1
2
3

not_found do
  redirect to("http://chitsaou.wordpress.com#{request.path}"), 307
end

這樣子，只要找不到檔案，就會轉址去 http://chitsaou.wordpress.com ；到那邊再找不到，就不干我的事了。

這裡我用了 307 ，也就是 Temporary Redirect ，讓認得 HTTP 狀態碼 的程式，不要視這個為永久轉移，因為我可能以後會砍掉那篇、或移到新站。如果你需要永久轉址的話，請使用 301。

我搬的文章只有一小部份，其他的會視流量決定要不要搬。為了可以轉址，我把 blog 放到 Heroku 。在 Octopress 的網站上有說明如何做。不過它的方法會強迫我把 compiled HTML 都放進 master ，我是有點潔癖的人，我覺得這樣感覺非常不良。

Blog 原始碼、草稿、上線網站管理流程簡介

我希望把程式碼及發表的文章，與 compiled HTML 隔離開來，且草稿先不公開。草稿可以放到 dropbox ，而程式碼加上已發表的文章，可以放到 GitHub 公開出來。我想到的管理方式是這樣子：