各位喜愛 Ruby 的朋友們,Ruby Tuesday 三月場由 tsechingho 接力主辦,時間地點是 2009/3/10(二) PM7~9 台中市東海書苑,詳細資料請前往報名網頁。
這次的題目有 tsechingho 介紹如何運用 rails 2.3 的 template 與 engines 來加速建置一個 rails 程式,以及 weijen 介紹如何撰寫 rspec 測試。
😆 👨🏻💻 📚 🚀 💰 ✨
各位喜愛 Ruby 的朋友們,Ruby Tuesday 三月場由 tsechingho 接力主辦,時間地點是 2009/3/10(二) PM7~9 台中市東海書苑,詳細資料請前往報名網頁。
這次的題目有 tsechingho 介紹如何運用 rails 2.3 的 template 與 engines 來加速建置一個 rails 程式,以及 weijen 介紹如何撰寫 rspec 測試。
Update(2009/4/22): 投影片在這裡
一年一度的台灣 Open Source 界盛事 OSDC.TW 開放報名了,日期是 4/17~4/19,今年我有一場 50min 的演講談 Ruby 1.9,大綱如下:
於今年初發佈的 Ruby 1.9.1 是 1.9 系列的第一個穩定版本,本 talk 將介紹新功能、講解與 1.8 相異的地方、如何撰寫 1.8 和 1.9 同時相容的程式以及分享 Ruby 1.9 on Rails 的經驗。
另外還有我跟同事 xdite 和 weijen 一起準備的 Ruby on Rails tutorial 在 4/17(五) 上午。如果你想從頭好好認識 Rails 2,這是一個非常好的機會,保證真才實料。
這次主辦單位還佛心來也找了 DHH 來做 RoR Q&A (Video conference),真是令人緊張啊,要先好好準備問題了… :D
喔,這真是太好用了,使用 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 的範例如下:
參考資料: