筆記

赫然發現在 Linux 平台上使用掃描器其實還蠻簡單的，以 DR 所使用的 Epson Stylus CX5100 多功能事務機為例，在 Fedora 19 上由於提供掃描器支援的 SANE 已經跟著 GNOME 桌面環境一併安裝，因此只需要再安裝 XSane 的 GIMP plugin：

有些時候會需要在 Android 系統上測試一些程式碼，而一般來說，Android 的開發環境是基於 Eclipse。然而 DR 已經有好段時間沒有使用任何 IDE 了，目前所習慣的開發模式通常就是在文字編輯器上寫程式、用檔案瀏覽器管理檔案以及使用命令行介面（虛擬終端機）進行所需的操作，使用 IDE 反而會覺得渾身不對勁，尤其以前少數使用 Eclipse 的經驗也不是很好。

此外 DR 也不太滿意 AVD（Android Virtual Device）緩慢的效能，因此會想要建立一個無 IDE、也不需要 AVD 卻能夠測試 Android 應用程式的工作環境，所構思的具體作法如下：

Windows 平台上的語音辨識方案有兩種：一種是 .NET Framework 所內建的 System.Speech 命名空間，而另一種則是由 Microsoft Speech Platform SDK 所提供的 Microsoft.Speech 命名空間。兩者的結構頗為相似，許多類別和方法都是一樣的，不過前者的環境建置比較單純，用的是 Windows 本身的語音辨識功能，不需要再安裝 SDK。

Pocketsphinx 是來自卡內基美隆大學（Carnegie Mellon University）的語音辨識工具，許多 Linux 發行版的套件庫已經有收納此工具，以 Fedora 19 為例，執行以下 yum 安裝指令就能夠將所需的套件安裝完畢：

• sudo yum install pocketsphinx pocketsphinx-python

這陣子因為工作需求開始研究對聲音檔進行語音辨識的可行方案，第一個想到的便是 Google 的 Speech API。不過時至目前為止 Google 似乎還沒有打算將 Speech API 作為正式的產品發佈，不僅沒有任何官方文件說明其規格與操作方式，取得 API 存取權的方式也頗為迂迴。此外 Speech API 的存取也有不少限制，例如每日的請求次數為 50 次，以及聲音檔的長度限制大約在 10 秒左右。這使得目前的 Speech API 比較像是供開發者預覽用途，而不太適合實務應用。

Reverse Engineering for Beginners（逆向工程初學指南）是一本線上電子書，作者為 Dennis Yurichev。以份量來說，這本書的內容相當豐富，不過由於組合語言對 DR 而言實在是可怕的東西，所以 DR 只有快速的瀏覽了一下，然後挑了一個簡單的習題（1.4）試做看看。

習題 1.4 的要求是從執行檔中找出密碼，DR 下載了 Linux 版本的範例執行檔（password1），執行時會顯示「enter password:」，任意輸入字串後則顯示「password is not correct」。接著 DR 使用 hexdump 工具去尋找裡頭的可列印字串：

• hexdump -C password1 | more

最近 DR 在 Linux 上玩遊戲時，發現有不少遊戲在操控設定上無法識別除了基本三鍵以外的滑鼠按鍵，例如拇指旁的按鍵。但卻又不是每一款遊戲都有這問題，例如《惡靈勢力 2》（Left 4 Dead 2）就能夠識別到額外按鍵。這個狀況引起了 DR 的好奇心，基本上 Linux 遊戲的輸入控制都是利用 SDL 完成的，因此 DR 便想要自己動手做做看，並嘗試找出可能的差異。

一開始 DR 用以下的程式碼來識別滑鼠按鍵，但很快就發現了問題：

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

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

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

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

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