Growl 與 Notification Center 隨便聊

今天聽到 OSX 下一版本 Mountain Lion 的消息，大更新不多，主要都是將 iOS 上的一些應用搬到 Mac 上來，而其中最吸引我注意的大概就是通知中心（Notification Center）了。

繼續聊下去前，先聊聊我理想中的電腦工作環境，要能提供兩個基本功能：

1. 單一而簡潔的指令輸入，可以快速鍵入指令進行工作；
2. 單一而簡潔的訊息輸出，將執行結果與事件統一一處發送通知。

說起來很簡單，說穿了也不過就是文字列模式下的延伸概念。關於第一點，現在已經有許多應用程式可以做到了，例如在 Windows 有 Launchy, Mac 則有 Alfred, 都是很棒的應用，直接熱鍵啟動執行指令，就可以開始進行工作，能有效節省時間。

然而由於圖形作業系統多個視窗各自為政的關係，要建構第二點的環境其實有些困難。在 Windows，當電腦連上外接設備，或是硬碟空間時，會有小小黃色的 Tooltip 通知視窗；當 MSN 有人傳訊息來時，有 MSN 的通知泡泡；防毒軟體的病毒更新碼有段時間沒更新時，會有防毒軟體的提醒對話泡泡。每個軟體都有每個軟體自己的通知與設定，顯示停留的時間與樣式也都個不相同。假設今天如果我要進入專注模式，想要暫時關掉所有外來的通知時，我得一個一個自己去設定，然後要放鬆時還得一個一個去打開，這會是多惱人的一件事情？

好在 Mac 上有 Growl, 一個第三方廠商所寫的訊息通知中心軟體。Growl 提供了公開 API, 讓軟體開發商可以支援將訊息發送到 Growl 作顯示。以我目前的電腦來看，就包含了以下程式的訊息通知：

• 1Password
• Adium
• Alfred
• Cappuccino
• Dropbox
• GrowlTunes
• HardwareGrowler
• Insync
• Pomodoro

這些不同的程式都可以透過相同的窗口向我報告，當我不想要干擾時，也可以很輕鬆的全部關掉。也正因為有如此多的軟體支援 Growl, 所以就算我不喜歡 Growl 他那爪子般的 icon, 不喜歡他把 GrowlTunes 與 HardwareGrowler 在 App Store 裡另外拆開來賣，但我還是購買並安裝了這套軟體。

回到最初所提的，下一版的 OSX 將會把 iOS 上的訊息中心給整合進來，我想最為首當其衝的就是 Growl 了。前面所提到的「單一簡潔的輸入」與「單一簡潔的輸出」，這工作由作業系統來做自然是再合適也不過了。因此不難想像，隨著應用程式逐漸支援新的訊息中心，Growl 將逐漸失去其既有的優勢。

只是就目前看來，Mountain Lion 的更新項目實在不多，如果到時候不是免費升級，而且賣得還跟 Lion 一樣貴的話，我實在很難下得了手花錢進行升級……

Mac 更換資料夾圖示的方法

最近想把 Mac 裡一些常用的資料夾換個圖示，找到的步驟如下：

1. 選取資料夾，開啟該資料夾的「簡介」視窗。
2. 將下載好的 .icns 圖示檔拉到「簡介」視窗最上方的小圖示上，就可以換掉原有圖示了。

我照了這個方法作，不過從網路上下載的 .icns 圖示檔，有些拉上去後可以成功更換資料夾圖示，有些卻不行。研究了半天也搞不清楚為什麼有些成功有些不行。後來找到了另外一個換圖示的方法，不僅更簡單，而且除了 .icns 檔案外，也適用於任何圖檔。方法如下：

1. 用「預覽程式」開啟你要用來當資料夾圖示的 .icns 檔，或其他圖檔。當然，尺寸最好是 512x512。
2. 開啟後，依序按下⌘A（全選），⌘C（複製）。
3. 然後選取想要更換圖示的資料夾，開啟該資料夾的「簡介」視窗。
4. 點選「簡介」視窗最上方的小圖示，按下⌘V（貼上），大功告成！

這個方法除了資料夾外，也可以用來更改磁碟映像檔的圖示。

Blogging with Markdown

用 Markdown 寫部落格

前陣子比較了一些輕量級標記語言，想作為之後自己撰寫文件的格式依據。其中 reStructuredText 太過複雜，就不考慮了；剩下的 AsciiDoc 與 Markdown 兩者中，剛開始我比較喜歡 AsciiDoc 多一些。因為 AsciiDoc 有支援表格的語法，而 Markdown 則必須透過 Inline HTML 的方式，這麼一來如果文章中想包含表格，免不了還是得塞入一堆礙眼的 HTML 語法。

不過比起 AsciiDoc, Markdown 的應用支援顯然要來得廣泛得多，除了 GitHub 與 BitBucket 等網站外，有相當多的工具或編輯器支援 Markdown 語法，例如 Day One, iA Writer 或是 Byword，這方面壓倒性勝過 AsciiDoc。於是乎 Markdown 便逐漸成為我的首選，至於不能製作表格的問題嘛，反正作表格的機會也不是那麼多，大部分時候也可以用清單方式來呈現資料，所以倒不是太大問題。

決定用 Markdown 作為主要規範後，第一個想到的就是用 Markdown 來寫 blog。不過 blogger 本身沒有支援 Markdown 語法，也沒有外掛或工具支援直接將 Markdown 寫好的文章發佈。大部分用 Markdown 在 blogger 寫文章的方式，都與 Notely: How to use Markdown in Blogspot posts 這篇文章的作業流程大同小異：

1. 在你的電腦中用文字編輯器撰寫文章並儲存成檔案（原作者 Joel 使用 yyyy-mm-dd post title.txt 的檔案命名方式）
2. 開啟 Daring Fireball: Markdown Web Dingus 網站，複製貼上文章內容，進行轉換。
3. 最後，將轉換完成的 HTML 碼貼到 blogspot 的新文章中。

另外，貼上時要注意以下兩點：

1. 在貼上新文章時，確定文字輸入區上方的模式是在「HTML」下而非「撰寫」。
2. 開啟右側「文章設定」最下方的選項，
   1. 「撰寫模式」勾選解譯輸入的 HTML。
   2. 「換行符號」勾選使用 <br> 標記。

我目前也是採用類似的流程。比較特別要提的有以下幾點：

1. 標題除了作為檔名外，檔案內的第一行也會放上一級標題；最後一行則是列出這篇文章的標籤。所以在轉換為 HTML 時，要去首尾行。
2. 檔案存放在 dropbox 空間中。這樣可以確保文章有多份備份。
3. 文章是用 iA Writer 寫的。寫完之後用〈在 OS X 中隨時隨地將 Markdown 轉為 HTML〉這一篇提到的方法轉換為 HTML 碼，這樣就不用再開啟線上轉換的網頁了。

---

這篇文章就是用上述流程所寫的，你可以到這邊看看原始模樣。

代碼配色，從 Zenburn 到 Solarized

這些年來，我的代碼配色方案都是以 zenburn 為首選。深色底，低對比，對眼睛舒服，代碼的段落也清晰。zenburn 也是網路上很受歡迎的配色，這有一個好處，就是越多人用就越有可能被 porting 到不同的 IDE 或 Editor 上，所以從 Visual Studio 到 Eclipse 再到 XCode 都可以找到現成的 zenburn 設定。

上圖就是目前在用的 zenburn。由於用這麼久都已經習慣了，從沒有想過會有第二種配色讓我如此滿意，結果前天突然發現 Solarized 這一組配色，當場就被迷住了，我才認識這組配色不到 24 小時，就把 zenburn 從我的 vimrc 中換掉了。

• 官方網站：Solarized - Ethan Schoonover
• GitHub 檔案庫：altercation / solarized - GitHub

說起來，會注意到 Solarized 也是無心插柳。原本是在找 markdown + blogger 的 solution, 沒有找著，倒是見到了一個以 github 為基礎的 blog framework, 叫 Octopress。我對 Octopress 沒有太多興趣，純粹好奇它的技術架構（畢竟以 SCM 作為 blog 後端，是很有趣的想法），所以研究了一下。然後意外地在〈使用 Octopress + GitHub 免費架設部落格，以 Markdown 語法快速發表文章〉這篇文章中意外地注意到 Solarized 這組配色。

Solarized 最令我覺得神奇的地方，就在於同一組基本色，可以任意搭配淺白色或淺黑色背景，都一樣清晰明瞭。它的色盤也控制在 16 色內，所以即使在終端機模式下使用也不會突兀。在官方網站上，也列出了 Visual Studio 與 Xcode 等 IDE 的配色支援；for eclipse 的配色網路上搜尋得到，不過官網上沒列出，不曉得是不是名字相衝的緣故（太陽 vs. 日蝕）=P

我在終端機純文字模式下的 Vim 與圖形介面的 MacVim 分別指定了 Light 與 Dark 兩種配色。這樣在 Vim 中編輯時，只要瞄一下我就可以知道現在是在終端機模式下還是獨立的 Mac App。

另外這配色除了用在程式碼外，也有提供給一般應用程式使用的版本，例如常見的 putty, OSX 自帶的 Terminal, 以及 iTerm 2 等。一樣都可以在 Solarized 放在 GitHub 上的 Repository 上找到。

在 OS X 中隨時隨地將 Markdown 轉為 HTML

很多人喜歡用 Markdown 寫純文字的文件，包括我。簡單又有規範，而且幾乎所有文書軟體／編輯器都可以開啟（應該沒有不支援純文字的編輯器吧？），也可以轉成 HTML 在網路上發表。

在 Markdown 作者 John Gruber 的網站上有提供了一個 perl 寫的 Markdown 轉換指令稿，可以將 Markdown 轉換成 HTML。不過每次要轉檔都要進終端機下指令也是麻煩，今天剛好看到一篇文章，可以在 OS X 中加入一項服務，透過該服務，任何只要提供文字編輯的應用程式，都可以經由右鍵選單輕鬆將 Markdown 轉換成 HTML。

原始文章：
Installing Markdown as an OS X Services Menu Item Using Automator

懶得看原文的也可以看下面步驟。原文中的作法是將轉好的 HTML 直接取代掉原始 Markdown，因為我的需求不同，所以以下的步驟還會加上將轉好的 HTML 放到剪貼簿中。

先下載 John Gruber 所寫轉換指令稿：Markdown.pl
下載後找個地方存放，我是放在 "/usr/local/bin/" 下面。

然後開啟 Automator，選擇新增一項「服務」

接著會在視窗中看到如下內容。勾選「輸出會取代所選文字」，如果你只複製到剪貼簿而不需替換掉原本文字，可以不用勾選。

在左側程式庫列表中找到「執行 Shell 工序指令」，拉到右側。然後在文字區域中輸入 "/usr/local/bin/Markdown.pl" （請依照下載時所存放位置作適當修改）

如果只是要產生 HTML 碼，到上個步驟就可以了。若還要把轉換後的 HTML 存到剪貼簿中，一樣在左側程式庫列表中找到「拷貝到剪貼板」，然後拉到右側剛剛的指令下方。

存檔，大功告成！

接下來實驗看看。打開「文字編輯」或是任何可以編寫純文字的程式，隨便打一段 Markdown 指令。輸入完後全選，叫出右鍵選單，可以看到我們剛才辛苦的結晶：

用力給他按下去－－噹啦～全部變成 HTML 了，很方便不是？

Python 遞迴處理路徑下檔案與資料夾

取得某個路徑下的所有檔案與資料夾是經常會使用到的功能，尤其是在寫一些小工具來處理硬碟上的檔案時。早先我都是用傳統寫 C++ 的方式來思考，所以在 Python 的文件中找到了 listdir() 這個函式，然後寫了類似以下的代碼：

import os

def doInDir(somedir):
    print somedir
    fileList = os.listdir(somedir)
    for f in fileList:
        fullpath = os.path.join(somedir, f)
        if os.path.isdir(fullpath):
            doInDir(fullpath)
        elif os.path.isfile(fullpath):
            print fullpath

doInDir("/tmp/")

不過最近發現在 Python 下做事其實可以更簡單，內建的 os.walk() 就提供了非常強大的功能，使用的方式如下：

import os

for root, dirs, files in os.walk("/tmp/"):
    print root
    for f in files:
        print os.path.join(root, f)

相比之下，同樣的功能用 os.walk() 就精簡了許多。上面兩段程式碼做的事情基本上是一樣的，都是列出指定資料夾下的所有檔案與子資料夾；不過有個小小地方需要注意一下，就是用兩種方法索處理的內部順序並不相同。listdir() 會按照深度優先搜索的順序，一層一層往下深入，其中檔案與資料夾的先後順序是交替穿插的；而 os.walk() 因為把檔案與文件夾都歸類好放在各自的 list 中，因此兩者的處理是分開的。以下是上面兩段程式針對同一個範例資料夾的輸出，可以看出處理順序的不同。

os.walk()

/testtree/
/testtree/1file
/testtree/3file
/testtree/2dir
/testtree/2dir/21file
/testtree/2dir/24file
/testtree/2dir/22dir
/testtree/2dir/22dir/221file
/testtree/2dir/23dir
/testtree/4dir

os.listdir()

/testtree/
/testtree/1file
/testtree/2dir
/testtree/2dir/21file
/testtree/2dir/22dir
/testtree/2dir/22dir/221file
/testtree/2dir/23dir
/testtree/2dir/24file
/testtree/3file
/testtree/4dir

Python 計算檔案的 CRC32 驗證碼

用 Python 計算 CRC32 很簡單，只要使用內建的 binascii 模組即可。

import binascii
print binascii.crc32("hello world")

要反覆計算的話，可以用：

crc = binascii.crc32("hello")
crc = binascii.crc32(" world", crc)

其中的第二行，將前一步驟所計算的 CRC 結果作為參數再次傳入函式中。


如果要計算檔案的 CRC32，可以透過以下函式來計算：

import binascii
def computeFileCRC(filename):
    try:
        blocksize = 1024 * 64
        f = open(filename, "rb")
        str = f.read(blocksize)
        crc = 0
        while len(str) != 0:
            crc = binascii.crc32(str,crc) & 0xffffffff
            str = f.read(blocksize)
        f.close()
    except:
        print "compute file crc failed!"
        return 0
    return crc

上面比較特別要注意的是這行：

crc = binascii.crc32(str,crc) & 0xffffffff

根據官方文件，在 Python 2.x 的版本中，binascii.crc32 所計算出來的 CRC 值域為 [-2^31, 2^31-1] 之間的有號整數，為了要與一般 C 所實作的 CRC 結果作比對，需要將其轉為無號整數，所以加上「& 0xffffffff」這段來做轉換。如果是 Python 3.x 的版本，其計算結果為 [0, 2^32-1] 間的無號整數，因此不需額外加上修正。


另外，上述 computeFileCRC 計算的結果為十進位整數，而通常見到的 CRC32 字串會以 16 進位方式表示，所以可以這樣轉換：

crcstr = hex(computeFileCRC("somefile"))[2:]

或是，如果要直接使用在字串中，也可以用 format 的方式轉換成 16 進位格式：

print ("crc32: %08x" % computeFileCRC("somefile"))