筆記

前一陣子 DR 因為工作環境的需求，開始嘗試撰寫 Mozilla Thunderbird 的擴充套件，卻發現網路上找不太到適合新手入門的教程。儘管網路上針對 Mozilla Firefox 的教程有比較多一點，可以先用來學習一些基礎概念（因為所有 XUL 應用程式的擴充套件都是採用相同的架構）。然而若想要進一步涉入 Thunderbird 的控制，就會發現幾乎找不到有什麼教程可以讀……

或許是因為這個領域缺乏入門資源，有志願者製作了 Add-on SDK 來協助擴充套件的開發。不過很不幸地，這玩意僅支援 Firefox 而不支援 Thunderbird，因此 DR 沒辦法用來做進一步的利用。

最近 DR 常透過 SSH 遠端連線到網際網路上的主機去做密集的指令操作，卻發現輸出入的反應速度相當緩慢，按個按鍵要等上許久才會顯示出所按的按鍵，就連 Tab 鍵自動補齊的反應速度也是慢得可怕。原本認為是網路的問題（畢竟是網際網路而非區域網路），但幾個環節檢查下來，只覺得網路速度應該沒有那麼差才是。

直到有一次 DR 在 Windows 下用 PuTTY 登入至相同的主機想要查點資訊，赫然發現反應速度天差地遠，當然沒有像區域網路那麼順暢，但至少回復到可以接受的程度。這才意會到恐怕這並不是什麼網路問題，問題是出在虛擬終端機軟體上。

去年 DR 在 Outlook 批次寄信與 SharpDevelop 這篇文章裡，提到自己因為工作需要寫了一支程式，該程式的功能是可以根據 CSV 格式的名單自動產生信件給 Outlook（或者 Outlook Express 和 Windows Live Mail）寄送。當這支程式完成後，DR 有很長的一段時間沒有再對程式碼做大幅度的更新，僅有針對特定需求略做客製化的修改。

直到最近，DR 再度涉及到大量信件寄送的業務，回頭再去操作當初自己寫的程式時，也許是因為操作思維的轉變，發覺這東西真是不太好用，很多地方現在都覺得礙手礙腳的，於是便打算將這支程式整個重寫過。然而事過境遷，不只是操作喜好改變，在程式架構上的評估也產生了一些轉變。

HiNet 企業簡訊（Socket to Air）是中華電信的線上簡訊發送服務，由於這項服務可讓用戶自行撰寫程式來連結伺服器，因此有提供通訊規格說明和許多程式語言的程式碼範例，包含 C（Unix、Windows）、Java、VB .NET、Perl 以及 PHP 等。不過沒有 Python 的範例，所以 DR 主要參考（更精確的說就是照抄）PHP 版本的範例，寫了一段用 Python 發送的版本。

以下程式碼僅單純示範如何登入 HiAir 伺服器，並發送一則文字簡訊給指定的國際號碼：

今天 DR 生出空來將使用一年多的 Fedora 17 重新安裝成 Fedora 19，一方面是為了軟體的除舊佈新，另一方面則是鑒於之前的不良經驗，而打算將 /home 目錄分成獨立的分割區。同時這樣的作法也可以使日後重裝系統時，只要保留 /home 不格式化就無須進行大量的資料轉移（今天 DR 在安裝之前，得先將 Linux 系統裡需保留的資料備份到 Windows 的分割區裡，然而 Linux 讀寫 NTFS 檔案系統的效率又很不理想……）。

DR 合理的推測，自己這輩子應該根除不了刪檔案快、狠、卻不太準的惡習……

今天動用到了 extundelete 這支針對 ext3/ext4 檔案系統的反刪除工具，雖然最後沒能把檔案救回，但還是在這邊做一點記錄。話說 DR 要在某部伺服器上做一支監控程式，於是就直接 SSH 遠端登入後用 Vim 編輯器來寫。DR 在這支程式裡設計了建立 *.pid 檔的機制，目的是要避免動作的重複執行，而悲劇就發生在當 DR 想要手動 rm 掉 *.pid 時，竟然手誤把 *.py 給 rm 掉了……

雖然損失的不是整支程式，因為另一部伺服器上的 Git 系統還有上週五所提交的備份，卻還是損失了今天早上一、兩個小時下來腦力激盪的成果，所以 DR 的第一個反應就是想把檔案救回來。然而在開始思考對策之後才意識到這部伺服器的配置可說是讓資料救援越顯困難，因為：

hiBox 是中華電信針對企業用戶的郵件服務，也是 DR 所在的公司目前使用的郵件服務。由於最近 DR 要試驗一些網站服務，其中會涉及對外寄信的功能，因此 DR 想到如果能設定 Postfix 利用 hiBox 來寄信，如此一來就會省事很多。

於是 DR 主要參考了自己好些年前寫的 Postfix 使用 Gmail SMTP 轉寄這篇文章（內容陳舊，有興趣閱讀的人切勿照單全收），不過也發現用 hiBox 寄信所需的設定內容事實上是單純很多，本文接下來的內容便是在 CentOS 6.4 上的設定流程。

首先建立 /etc/postfix/sasl_passwd，並在裡頭寫入一個有效的 hiBox 郵件帳號、網域及密碼，按照下列格式：

今天 DR 心血來潮，終於改掉了網站上一個自己覺得不太順眼的小問題，那就是左側的「最新內容」區塊預設是以修改日期來排序的，而這會有什麼問題呢？問題在於如果 DR 在過去的文章裡改錯字、或者大砍錯誤內容……那麼其文章排序就會跟主區塊不一致，因為主區塊是以文章的建立日期來排序的。這個問題不大，但多看幾眼就會覺得還是把兩個區塊都按照建立日期來排序會比較好。

Drupal 7 本身的管理介面並沒有提供這方面的設定，所以只能直接改程式碼。由於 DR 不諳 PHP，因此整個的研究和解決流程算是很懶人，先簡單用肉眼判斷相關程式碼應該是在 node 模組裡，接著對 node 的程式碼搜尋關鍵字，最後直接改改看就改好了……

於伯樂在線網站看到的翻譯文章，裡頭大部分的工具 / 指令 DR 聽都沒聽過（DR 只對 xeyes 和 shred 有印象）。也由於這些工具多半缺乏實用性，所以通常各 Linux 發行版預設都不會安裝，不過使用者可以嘗試藉由 apt-get 或 yum 等安裝工具從套件庫中搜尋並安裝。

原文連結在此：The funny side of Linux command line，原文的列表其實和譯文有一點出入。

這兩天 DR 在處理一支自己所寫的工具在特定狀況下效能嚴重低落的問題，這支工具是用 Python 寫成，其主要用途是分析特定的 XML 檔案，再經由 COM 介面呼叫 Excel 產出試算表格式的報告結果。就在昨天，DR 接到一支不過 2MB 大小的 XML 檔案，用工具跑卻遲遲沒有結果，比它還大上許多的檔案也未曾遇過這問題。於是 DR 置入了一些 print 函式監看程式的處理狀況，並關閉一些模組來交叉測試。從中發現這支 XML 雖小，符合個別分析條件的資料量卻是異常的多（基本上，這是一支不正常的檔案），致使得工具雖然沒有當掉，但仍在一些程序上停滯不前。

DR 接下來所做的事情就是將程式碼清查一遍，尤其 DR 常仗著硬體速度越趨發達、執行的工作又單純，對程式碼的效能便不是很在意，所以很容易寫出低劣的程式碼……在清查過程中找到了一些明明可以先經過篩選從而減少迴圈次數的程式段落，將其修正後再試一次，執行效率確實有變快一點，但還是不夠。

於是 DR 將程式碼一段一段、各個模組拆開來測，發現真正影響效能的元兇僅是單一一行程式碼（不過因為迴圈的緣故，要跑很多次）：