去年 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 合理的推測，自己這輩子應該根除不了刪檔案快、狠、卻不太準的惡習……
今天動用到了 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 上的設定流程。
今天 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 將程式碼一段一段、各個模組拆開來測，發現真正影響效能的元兇僅是單一一行程式碼（不過因為迴圈的緣故，要跑很多次）：
以下的故事其實是在幾週前所發生的：話說 DR 在公司所用的一部桌機，某日發現其速度變得異常緩慢，Core i7 3770 的桌機跑起來竟然比 DR 家裡的 FX-8350 還要慢（怎麼可能！？），連打個字都會嚴重延遲。打開工作管理員一看，CPU 和記憶體的使用狀況卻都很輕微。根據過往的經驗，這表示問題可能出在硬碟上，果不其然，打開事件檢視器後，發現裡頭有大量的磁碟錯誤記錄……
那麼該如何是好呢？
這部桌機是 ASUS 的品牌電腦（而且還買不到一年），然而第一時間 DR 卻不想走 ASUS 的保固維修，因為如果走 ASUS 的維修，往來運送的時間以及問題的判定加上維修應該最快也要花上兩三天左右。雖然這部桌機並非 DR 主要的工作電腦，但仍需要用它執行一些特定項目，因此若讓它消失個兩三天可是造成一些困擾的。相反的，如果直接自行更換硬碟，在無其它意外的情況下，一天之內就可以讓電腦恢復成可工作的狀態。
於是 DR 的計畫如下：忽略 ASUS 的保固，直接拿一顆硬碟先換上去，然後把故障的硬碟送回硬碟原廠更換。當時 DR 只覺得這個計畫既簡單又明快，完全沒預料到接下來會遇到的障礙……
話說幾天前 DR 看到一份填字題目，就是那種有三個中文字，例如「法」、「復」、「語」，然後填入一個相同的字讓各個配對可以組成合宜的字詞，以這個例子來說，可以填入的解答就例如有「古」、「國」等。而當 DR 在嘗試作答時，突然靈機一動想到，其實只要有適當的詞庫，這應該是可以用程式去協助解答的。
那麼去哪裡找詞庫呢？DR 很快的想起開放原始碼的新酷音輸入法，於是在 GitHub 上把新酷音輸入法的純文字詞庫檔（tsi.src）抓下來，接著就開始嘗試用 Python 寫出填字程式，所構思的程式運作流程大概像這樣：
