😆 👨🏻💻 📚 🚀 💰 ✨
喔，這真是太好用了，使用 Mac OS X 內建的字典程式查 API：
下載之後放到 ~/Library/Dictionaries ，就可以在 Dictionary 中使用，也可以在 Spotlight 中搜尋。Priit Haamer++
Windows 跟 Linux 的使用者，你們的解決方案在這裡。
為了之後如果重灌還記得怎麼做，特此紀錄。
Panasonic W2E 是我的第一台筆電，買四年多了。輕加上電池可以撐很久，現在擔任我的第二台小筆電還十分好用。但是上個禮拜硬碟終於因為年紀大了掛點，因為硬碟電壓是 3.3V 跟一般 5V 不同，需要特別折腳什麼的，加上拆裝看起來挺複雜的，所以就在網路上找有經驗的水貨商幫忙，今天拿回來了。
重裝 Win XP 之後，首先要找驅動程式，網頁在 Let’s note CF-W2シリーズ 導入済みドライバー | パナソニック パソコンサポート，內容如下：
cpupower_r3t2w2y2_2553_d030520.exe CPU 省電設定
dmi_r3t2w2y2_2553_d030557.exe 瀏覽系統資訊
hkeyapp_r3t2w2y2_2553_d040571.exe fn鍵
hotkey_t2w2_55_d030259.exe fn鍵
hkeyset_r3t2w2y2_2553_d030477.exe fn鍵設定
lan_r3w2_25_d031123.exe 網路驅動程式
numlkntf_r3t2w2y2_2553_d040660.exe Num鍵提示(沒什麼用的日文提醒)
intelinf_t2w2_55_d030128.exe 主機板驅動程式(這個要第一個裝)
pcinfo_r3t2w2y2_2553_d040080.exe 瀏覽NB資訊
sd_r3t2w2y2_2553_d020984.exe SD 驅動程式
chgsddrv_r3t2w2y2_2553_d030714.exe SD 設定
sdkey_r3t2w2y2_2553_d030702.exe SD ??(沒裝)
opdoff_w2y2_53_d040707.exe 光碟機自動省電
sound_t2w2y2_553_d030899.exe 音效卡
loupe_r3t2w2y2_2553_d040695.exe ??(沒裝)
nselect_r3t2w2y2_2553_d040702.exe 切換網路軟體(沒裝)
video_t2w2_55_d030395.exe 顯示卡驅動程式
ienlarge_r3t2w2y2_2553_d040681.exe ??(沒裝)
觸控版驅動程式
wheelpad_r3t2w2y2_2553_d040717.exe 可以在觸控版畫圈圈表示捲軸(但這個版本不能用)
modem_r3t2w2y2_2553_d040336.exe 數據機驅動程式
無線網路驅動程式
wlansw_r3t2w2y2_2553_d040656.exe 無線網路切換軟體(沒裝)
其中如果碰到日文版，有 google 到這篇講說可以修改一下 setup.ini，把
[Languages] Default=0x0011
改成
[Languages] Default=0x0009
但是 WheelPad 的功能還是裝不起來，又 google 到這篇有 wheelpad 英文版，改裝這個版本就沒問題了。(裝 WheelPad 之前要先裝觸控版驅動程式)
萬眾矚目的 Ruby 1.9.1 終於發佈了，公告詳見 Ruby 1.9.1 is released。這個版本是 1.9 系列的第一個穩定版本，大大提昇了 1.8 令人詬病的效能 (請見 Antonio Cangiano 的 benchmarks )，非常令人期待它的商業應用。
要在 Mac 上安裝起來玩玩看的話，可以這樣做與本來的 Ruby 1.8 共存 (參考自How to compile and install Ruby 1.9.1 on Mac OS X Leopard)：
curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.bz2 -o ruby-1.9.1-p0.tar.bz2 tar xjf ruby-1.9.1-p0.tar.bz2 cd ruby-1.9.1-p0/ autoconf ./configure --program-suffix=19 make && sudo make install
這樣就會有 ruby19, irb19, gem19, rake19 等指令可以用了（Ruby 1.9 內建了 rubygems 跟 rake 囉)。不過目前還很多 Gems 沒有跟上 Ruby 1.9 的腳步，尤其是需要 native build 的 Library（例如 mysql 跟 mongrel 都裝不起來）。
Update(2009/4/5) 使用 Rails 2.3.2 就不需要以下 patch 了，裝起來就可以跑了。MySQL 可以改裝 tmtm.org/en/mysql/ruby/ 這個 Ruby 1.9.1 相容版本。
如果有研究興趣想把 Ruby on Rails 跑起來，除了需要用 Rails edge 版本( 2.2.2 的話，需要 patch active_support/deprecation.rb 227 行用 begin … rescue LoadError; end 把整段 test 包起來)，還需要至少裝 rack 跟 sqlite3-ruby gems，另外 Webrick 也需要自己手動 patch 如下(這是因為 Ruby 1.9 把 String #each 拿掉了)：
class String
def each
self.split($/).each { |e| yield e }
end
end
成果是 Ruby 1.9 on Rails 有圖有真相：
補充(2016/1/16): Software Costs Estimation In Agile Project Management
一般在台灣簽軟體開發合約，最常見的就是固定價格、固定規模的合約（最晚何時要交出符合這些規格的軟體和文件），但是碰到的問題就是兩造雙方都覺得需求定不清楚，而陷入對立的情形。接案的希望少做、出錢的希望多要一點，所以往往都在討價還價中試圖在期限中完成。如果實作後發現一開始的估計太保守、開發中途客戶又不斷加規格、需求頻繁變更或是任何意外，往往就就會開始 Delay，一旦專案延遲，第一個犧牲的就是開發品質了，例如省掉測試作業等。變成開發範圍太大 -> 無法如此交貨必須加班 -> 品質降低的惡性循環。
但是要採用敏捷開發，這種合約要怎麼寫啊？敏捷開發不就說專案一開始不需對規格詳細內容做決定嗎？
XP 方法論提出四個互相影響的專案變數：成本、時間、品質、開發範圍。也就是如果定死價格、時間和範圍，品質就會變成可犧牲的變數。XP 派別認為這四個變數，最常、最應該可以變動的就是開發範圍，也就是定好價格、時程和品質，但是要做什麼再談。回到合約上看，也就定期限、定總價但不定規格，例如 Kent Beck 建議的：『供應商將提供八個程式設計師為顧客服務，並且兩個月的金額是 $1,000,000。規模每兩週協商一次，協商時根據 XP 方法進行』。
但是不定規模對顧客而言最大的擔心，就是他想要知道他花了 $1,000,000 到底可以得到什麼，因此在台灣還很難接受這種合約方式，照 Kent Beck 的說法，只能玩成價格固定、交期不變、規模求個大概。例如我們和多就使用 User Story (註)的方式來定規模，保留與客戶溝通及實作的彈性，又有可以拿來估價的基準。雖然都會將專案時程切到至多三個月（一季）來做最大的估價範圍，不過還是會有一開始低估規模而造成專案 delay 風險（所以加強專案的估計技巧也是個努力的方向）。
另一種在台灣常見合約的作法，是分成兩次簽約跟報價，第一次簽約預備開發期，目的是要完整討論出需求跟規格，這部份就會先收取一次費用。第二次簽的約才根據詳細規格再報一次總價。不過這種方式基本上就把敏捷開發一開始『規格不確定也無妨』的優點給犧牲掉了。
還有一種簽法就是計時合約（顧問費），花了多少時間就請多少款，但是基本上這跟固定價格、固定規模型的合約還是有一樣的利益矛盾問題：供應商為了多賺點錢，會希望多加人、多加班多報一點時數。客戶則想要在人力、時間盡可能少的情況下，做出盡可能多的功能。
各位接案的前輩們，你們是怎麼做的呢？
註：
User Story(使用者情節)是一段簡單的功能敘述，以客戶或使用者的觀點撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶需求，因為實做細節將延後至開發時才會確定。
幾個 User Stories 的範例如下：
參考資料：
Update(2011/5): 推薦安裝 Peepcode 快速找檔
Update(2010/5): 10 TextMate bundles/plugins to boost your Ruby on Rails development productivity
Update(2009/2/21): Textmate 只有內建 Ctrl+Shift+A 的 SVN 功能，要支援 Git 請裝 Git Textmate Bundle，按 Ctrl+Shift+G 就可以有快捷功能。
Update(2009/2/22): 另外推薦一個不是 TextMate 的 Plugin，但是搭配起來非常好用的 Visor，只要使用快捷鍵就可以在螢幕上方下拉出 Terminal 畫面。
第一名是 AckMate， ack 是一套專門用來搜尋大型程式碼的工具，效能真是超級好。裝了這個套件之後，內建的 Find in Project 就別再用了吧。
第二名是 TextMate Plug-in: ProjectPlus，可以在顯示 SCM 的檔案狀態（例如有本地異動或有新增檔案等等），支援 SVN, Git, Mercurial, Svk 跟 Bazaar。
第三名是 CJK-Input.tmplugin，讓你可以正常輸入中文。如果有需要正常顯示，就必須換字型為 TextMateJ2 (see 解決 Textmate 中文問題)。
跟 Ruby on Rails 相關的有 Ruby on Rails TextMate bundle、Ruby TextMate bundle 和 Rails footnotes（會在例外錯誤畫面放有 Textmate 的連結，點下去就開出來該檔案，十分方便）。
Theme 方面，我自己用的是 Rails Envy Theme 連結失效，改放這裡 Rails Envy Theme (2011/3/20)。
另外就是官方 wiki 上的 Plugins 可以試試看。
有效率的團隊互動是敏捷軟體開發的一個重要基石，能與人一起開發軟體是很棒的事情。
小小一本書，拖了這麼久終於整理完了，總計六篇：
開會是個溝通必要但又花時間討人厭的事情，在 Agile 方法論裡面提出了一種叫 Stand-up meeting 的每天開會方式，正如其名建議的：請站著開會，這樣才會提醒大家盡早開完。每個人至多兩分鐘報告三件事情 1.距離上次開會，我做了什麼? 2. 到下次開會，我打算做什麼 3. 我碰到的困難。如果有需要討論更細節特定的東西，請再約有關係的人在開完 stand-up 各自帶開即可。一般來說合理的 stand-up meeting 時間約10到15分鐘，至多絕不超過 30 分鐘。另外就是儘量不要等人，時間到了就開始吧。
Stand-up meeting 有幾個好處：1. 繼續專心每天的進度 2. 如果 developer 碰到任何問題，可以有機會發出聲音尋求幫助，加速事情解決 3. 幫助團隊成員了解其他人在做什麼事情。
軟體架構設計師已經變成有點被濫用的職稱了，一個只會畫好看的圖、講厲害的行話、用一堆 Patterns，但是真的要實做前就跑走的設計師是沒有用的。真的設計隨著實際開始實做、實際的 Feedback 之後才會逐漸演化。就像打戰一樣，一旦開打 Plan 就無用了，只能不斷地 Planning，策略決策也許千里遠可以做，但是戰術決定非得實際在戰場上了解才行。
The designer of a new kind of system must participate fully in the implementation. by Donald E. Knuth
作為一個架構設計師，要實際了解設計真的可行才算是負責。真正的 architect 是團隊中的導師，有能力解決較複雜的問題，但絕不放棄 coding。絕對不要用不 coding 的架構設計師，不實際 coding 了解系統是不可能設計好軟體的。 * Good Design evolves from active programmers. *
“這個地方是 xxx 寫的，只有等他放假回來才能修的好”，這種事情很糟糕。請避免讓某一段 code 只能由某特定 developer 處理的情況，試著輪調 developer 去寫系統中不同的模組，分別由不同的人看過也可以讓程式更加被 checked、refactored 和 maintained 過，一旦碰到哪裡急需要修 Bugs 也不會發生等人的窘境。
當然，也許讓 developer 專屬某一領域的工作可能會開發一時會比較快速，不過放長遠一點看，透過多人共同開發的方式會獲得比較好的程式品質，也會比較好維護。整個團隊的 developers 的平均水準也可以拉高。對 developer 來說，知道寫出來的程式將來會被別人看，也會寫的更加用心。
這件事做起來當然是要注意過猶不及，例如太頻繁的輪調造成混亂或是系統中真的有某處需要特定人的特定專業知識。重點是 “你可以不需要了解系統中的每個細節，但是你也不應該害怕要你接手處理系統中的任何一塊”。
在 XP 方法論中，這件事情更是直接透過 Pair Programming 來達成，每一段 code 至少被兩個人擁有(處理) :p
當你發現你比同事都懂的多的時候，請學著分享，正所謂教學相長，讓團隊一起提昇。當 Mentor 不代表要像當老師一樣用上課的方式，透過 Pair Programming 就是一種很好的學習成長方式。
當 Mentor 不一定就是直接回答人家答案，回答一個方向讓人去思考也是個好方法，也許他還會回報你更多好答案。
千萬不要把(已知)會爛掉的程式 commit 進入版本控制系統，不然其他人更新最新版本之後不能正常執行，影響開發進度。請在做完一個任務或解完 Bug 之後，通過 unit test 之後再 commit 進去。當然，”It’s not ready” 不是一個久久不 commit 的藉口。
找到程式問題的最佳時機就是剛寫好的時候：也就是在寫好程式及測試之後，輪流由另一外 developer 檢查程式(review code)。另一種採行 review code 的方式就是實行 XP 方法論的 pair programming：一人寫程式打字另一人是導航員。
Review code 要做什麼事情？
Code Review 可以大大改進程式品質、降低錯誤率，而且非常實用讓團隊彼此進步。
不要在 Deadline 那天才報告壞消息。如果任務中途碰到技術困難，也要提出來讓大家想想看怎麼解決，甚至讓客戶知道也許他們願意用其他任務交換。盡量公開進度資訊，團隊跟客戶才會對進度感到放心、知道何時幫助你，讓你贏得信任。不要等著讓別人追問你進度如何。