今天 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 寫出填字程式，所構思的程式運作流程大概像這樣：
不知道有沒有人遇過這般如此駭人的畫面：
這個故事要從去年 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)
以下 DR 將列舉一些自己在近日 Steam 的 Linux beta 中所遭遇的問題以及解決方法。由於這些問題是針對 Steam 中的遊戲而非針對 Steam 客戶端本身，故決定以額外筆記的方式留存，而不放在 How-To：Linux 安裝 Steam 一文裡。而 DR 也合理的推測這些問題應該會在後續的更新中逐步修正，因此僅供目前有遇到相同問題的人參考。
1. 安裝 NVIDIA R310 版 Linux 顯示驅動程式
DR 從來不是個喜歡嘗鮮的人，甚至以 Windows 來說，DR 升級作業系統的速度還比一般人慢上一截：當年大家在用 Windows 95 時，DR 還在用 DOS + Windows 3.1。而當大家用 Windows 98 時，DR 也還在繼續用 95。等到大家開始用 Windows XP 時，DR 還用了好段時間的 Windows Me（這版本可是另一個故事了），接著就用了好幾年的 XP，最後換成 Windows 7 根本就還是幾個月前才發生的事。
基本上 DR 都是因為硬體的大幅度更換才會進行 Windows 作業系統的升級。不過就在幾天前，DR 因故必須安裝 Windows 8 來用一下，於是就從官方網站下載預覽版（Release Preview），然後裝在 VirtualBox 上。