筆記

今天 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 將程式碼一段一段、各個模組拆開來測，發現真正影響效能的元兇僅是單一一行程式碼（不過因為迴圈的緣故，要跑很多次）：

以下的故事其實是在幾週前所發生的：話說 DR 在公司所用的一部桌機，某日發現其速度變得異常緩慢，Core i7 3770 的桌機跑起來竟然比 DR 家裡的 FX-8350 還要慢（怎麼可能！？），連打個字都會嚴重延遲。打開工作管理員一看，CPU 和記憶體的使用狀況卻都很輕微。根據過往的經驗，這表示問題可能出在硬碟上，果不其然，打開事件檢視器後，發現裡頭有大量的磁碟錯誤記錄……

那麼該如何是好呢？

這部桌機是 ASUS 的品牌電腦（而且還買不到一年），然而第一時間 DR 卻不想走 ASUS 的保固維修，因為如果走 ASUS 的維修，往來運送的時間以及問題的判定加上維修應該最快也要花上兩三天左右。雖然這部桌機並非 DR 主要的工作電腦，但仍需要用它執行一些特定項目，因此若讓它消失個兩三天可是造成一些困擾的。相反的，如果直接自行更換硬碟，在無其它意外的情況下，一天之內就可以讓電腦恢復成可工作的狀態。

於是 DR 的計畫如下：忽略 ASUS 的保固，直接拿一顆硬碟先換上去，然後把故障的硬碟送回硬碟原廠更換。當時 DR 只覺得這個計畫既簡單又明快，完全沒預料到接下來會遇到的障礙……

話說幾天前 DR 看到一份填字題目，就是那種有三個中文字，例如「法」、「復」、「語」，然後填入一個相同的字讓各個配對可以組成合宜的字詞，以這個例子來說，可以填入的解答就例如有「古」、「國」等。而當 DR 在嘗試作答時，突然靈機一動想到，其實只要有適當的詞庫，這應該是可以用程式去協助解答的。

那麼去哪裡找詞庫呢？DR 很快的想起開放原始碼的新酷音輸入法，於是在 GitHub 上把新酷音輸入法的純文字詞庫檔（tsi.src）抓下來，接著就開始嘗試用 Python 寫出填字程式，所構思的程式運作流程大概像這樣：

1. 讀取詞庫文字檔，篩選出兩個字的字詞。
2. 三個題目字各自去搜尋符合的字詞，並存成三組詞庫。
3. 清除三組詞庫中各自的題目字。
4. 比對三組詞庫中的剩餘文字，三組詞庫皆有的字便是可用的答案。

不知道有沒有人遇過這般如此駭人的畫面：

這個故事要從去年 DR 為了 MechWarrior Online 的緣故買了張 GeForce GTX 560 Ti 說起，剛開始用時覺得一切正常，唯一的例外是偶爾在 Windows 7 上用 Mozilla Firefox 上網時會突然出現如上圖（雖然那張照片是 Fedora 17，不是 Windows）般整個畫面佈滿色塊的狀況，接著畫面會恢復正常，然後 Windows 會出現「驅動程式已重新載入」之類的訊息。

把自己寫的舊東西再拿出來修改有時候是件很痛苦的事……話說 DR 近日受朋友所託，要將自己在大約兩年前寫的一支 pygame 程式做一些加強。由於當初的程式內容算是急就章寫出來的，所以在增加功能之前，DR 決定先大幅清理程式碼，包含終於用 Class 把該做的物件做好等等……

另一方面，DR 這次也決定使用 PyInstaller 來方便產出用於 Windows 平台的獨立執行檔，不過產出的執行檔卻無法順利執行，也沒有任何錯誤訊息可供排錯。後來經過網路上的搜尋以及一段一段的程式碼測試後，發現問題就出在這一行：

font = pygame.font.Font(None, 17)