MaoYang-有話要說

昨天收到講師 高明權(tommy) 的建構與變更管理實務的簡報最後版本, 我大概看了一下, 真的是很棒的教育訓練, 沒來參加真的會很可惜, 這個教育訓練是我們公司主辦, 報名詳細資料可參考 這裡 . 談一下為何會有這個教育訓練的緣由! 最近這幾年, 我在台灣看過也自己去參加過各種軟體工程實務相關的教育訓練與研討會, 但是大部分都著重在專案管理, 變更管理與建構管理這方面的教育訓練相對專案管理卻相當的少, 在我對PM的認知, 變更管理與建構管理對於專案管理的成功與否其實扮演著舉足輕重的角色, 無論是硬體, 或是軟體都是一樣, 尤其是軟硬體整合的嵌入式產品. 為何會如此說, 舉一個很常見的例子, 產品開發的專案時程與人力的規劃都安排妥當, 照理產品應該很順利在預定的時程release, 但是似乎人生不如意十之八九, 產品release的schedule總是一拖再拖, 所以我們這次的教育訓練宣傳引出了以下問題, 而這也是我們在拜訪許多客戶, 客戶常問我們的問題, 這些問題與變更管理和建構管理做的好不好, 可是息息相關 ■ 專案一直無法收斂，Bug、Change Request做不完? ■ 產品出貨了卻發現說明書版本不對? 不清楚新舊版本的差異? ■ 已解決的問題再度發生? ■ 因為客製化需要，重複寫一樣的功能? ■ 客戶來電抱怨功能改版後反而不能用? ■ 不知如何正確使用版本控制工具? 關於講師高明權先生, 最早認識高明權先生時, 他當時還在三商電擔任系統部經理, 後來我在JavaWorld的Software engineering forum看到高明權先生post許多他個人的經驗與簡報, 例如 研發單位應具備的能力-1 研發單位應具備的能力-2 這兩篇文章, 我曾傳給客戶看, 獲得不少認同, 裡面就有提到建構管理對於研發團隊的重要性, 所以這次我們請了高明權先生來親身傳授更生動與實用的建構與變更管理實務,所以真的機會難得, 希望看到我Blog的網友多多宣傳.

如果要開發跨Linux , Mac, Windows, 等Rich Client端程式, RCP是個不錯的選擇, 寫了兩篇簡單的howto 建立RCP開發環境 建立一個RCP專案

1. 如何檢查Block 2. 如何使用Code completion

我在一個多月前, 寫了一篇帶新人的感想 , 讓程式碼像閱讀故事一樣容易 今天收到同達人的回響, 他針對我的論點, 衍伸許多深入的想法與精闢的論點 Code是寫給誰看的? 1/4 專業的Programmer Code是寫給誰看的? 2/4 關於課程安排 Code是寫給誰看的? 3/4 關於團隊合作 Code是寫給誰看的? 4/4 關於程式原理 很感動, 也讓我想了許多自己學習程式設計的過程, 認識我的朋友都大概知道我的背景是機械, 而不是資訊科學, 也不是資訊工程, 也就是說, 我並沒有受過完整的軟體設計, 與軟體工程等教育訓練, 我開始回想, 我是從那時候開始注重我的程式設計風格? 我最遠可以追溯到我念高二開始學習Basic那段日子, 從高二開始, 學校安排一個學期的Basic課程, 每週大約兩個小時, 老師先講解Basic程式設計語言的原理, 然後開始出一些簡單的作業讓大家回去練習, 當時的作業其實很簡單, 大部分都是邏輯訓練, 例如如何利用迴圈列印出像保齡球排列的圖型, 或是做一些檔案的I/O處理, Input/Output , 看似很簡單, 其實卻殿定我往後的基礎, 當年要教作業可是很有成就感, 因為能正確將老師的題目做出來的沒幾個, 但是我可是每道題目都是自己寫, 並上機將結果列印出來, 就在有一天要交作業的前一天, 我看到一位同學(楊松岳)也將作業列印出來, 並很認真在看老師還沒教的Basic章節, 我跟他哈啦一下, 並交流一下心得, 他告訴我, 他已經將整本的Basic K完了, 我當時很驚訝, 他說Basic實在很好玩, 所以他一口氣就將Basic的教科書 K完了, 我問了他幾個問題, 他總能很快回答我, 他告訴我他新的發現--DOS, 他發現Basic只是Basic, 最好玩還要了解DOS的原理, 我當時頗為震撼, 班上還有這一號人物, 而且他的成績並不是很出色, 但是玩電腦確相當有一套, 我們開始分享自己寫的code並互相討論是否還有更好的程式寫法, 他看了我的code總能指出這樣寫太沒效率了, 為什麼回圈一定要從0開始, 有些狀況從Maximum開始也不錯, 我想那應該是我最早的Code被Review的經驗, 所以我從那時候開始寫code就有被檢視的心理準備, 就像畫家畫一幅畫要接受大眾評論一樣. 當我踏入職場, 礙於所學非資訊, 礙於三

上週末在東森電影台看了冰公主, 很好看的一部電影, 描述一位擁有物理天份的女孩, 為了做一份申請哈佛大學的研究報告, 而這份報告是以尋求溜冰運動選手高難度動作中的背後運動物理方程式, 並以方程式來修正溜冰選手的姿勢, 她為了驗證自己的理論, 也親自下去學習溜冰的技巧, 確意外發現自己溜冰的天份, 女孩利用了自己的物理天份, 修正自己也幫助同學的姿勢, 做到了許多練習好幾年才能達成的高難度動作. 但是女孩的母親是反對女兒走向運動選手這一條路的, 母親 希望女兒循規導矩申請到名校, 成為一名物理學家, 但是女孩確不想放棄自己的溜冰潛能, 並計劃參加溜冰比賽...., 並且放棄了哈佛大學的申請... , 片中除了女孩對於理想的追求內心中的掙扎與選擇的心路歷程戲劇性, 片中的溜冰動作似乎也是由女主角自己親身達成, 也非常具有可看性. 整體來說, 這是一部兼具娛樂, 與勵志的好電影. 昨天在Cinemax又重看了這部電影, 矽谷海盜, 描述Apple與MicroSoft的發跡過程, 我看了三次, 每次看完總是有不同的感想, 昨天看完的感想是, 為什麼十七～八歲的Steve Job和Bill Gates為什麼他們的眼光看的比當時的老大哥IBM遠? 我想這是有點結果論, 因為MicroSoft和Apple成功了, 所以我們現在只能思考為何他們可以看到個人電腦產業這個遠景? 因為這個感想, 和看過冰公主, 眾合起來, 我有一番的體悟, 這兩部美國電影其實要告訴我的事情是一樣的-- 勇敢追求自己的夢想 重點不是學習Bill Gates的商業頭腦, 也不是學習Steve Job的偏執狂, 而是勇於追求自己的夢想. 在 蘭迪．鮑許教授的最後的演講 中, 藍迪也一直在強調 "夢想" , 藍迪說: 也許每個人發現自己的夢想很早, 或是要花十幾年以上才會知道自己的夢想, 但是請不要因此而放棄追逐自己的夢想 . 在我檢視自己的人生過程, 美國人的教育與台灣教育比起來似乎比較鼓勵追求夢想這件事, 從許多好萊塢電影可以看出美國人對於夢想追求的極致, 但是反觀台灣的教育就不是這麼一回事, 如果您的小孩有一天跟你說, 她/他想學溜冰去, 不想念書了, 大部分的父母或是師長都是反對的, 搞不好還會先挖苦一番. 我記得當時要從機械轉軟體業時, 還有自己出來創業時, 或是告

在搜尋一些技術資料時, 看到這篇How-to 如何將Java Virtual Machine安裝到iPhone 不過是要用破解iPhone的方式才能安裝, 看起來, 未來iPhone要內建JRE只是Apple要或是不要的問題.

iPhone程式啟動流程 Navigation-Base Application探索

經過4天的奮鬥, 總算把解封包演算法的Bug解決, 分享一下長久一來我的解Bug經驗, 雖然我還稱不上什麼武林高手, 但是這些經驗幫我渡過不少難關, 應該頗具有參考價值 當Bug出現的時候, 先使用Bug資料庫, 或是Issue Tracking軟體新增一個Bug. 我記得剛開始寫程式的那幾年, 遇到Bug, 第一件事就是先跳進去Source code 看問題到底出現在那裡? 但是往往Bug還沒解完, 其它事接踵而來, 開會,等等的中斷, 當思緒已經快想出問題的解法, 確因為"中斷"造成下次再接下去解Bug的時候又要重來. 所以先在Bug資料庫新增一個Bug, 看似很簡單, 但是這個習慣確是我工作兩三年後才養成的習慣. 勤寫Bug Comment 將心中對於Bug會發生的所有可能性記下來, 當思緒打結的時候, 將目前的進度與結果做個記錄. 這些記錄寫在資料庫中所建立的Bug是最好的. 以我解Bug的經驗, 每當遇到很棘手的Bug, 心中總是千頭萬緒, 不知從何下手, 在這思考的過程中, 沒有將思考的結果寫下來, 最後很容易陷入"思考的迷宮" , 思緒一直在繞圈圈, 走也走不出來, 但是有做記錄, 雖然會花一點時間, 但是確可以review自己的思路, 很快就可以找到出路. 善用Log message 例如 Java 的log4j , Object-C的NSLog. 如果是寫底層的device driver也是有對應的log utility. 使用Log也要有一些技巧性, 我的經驗是, 先將source code好好看過一次, 然後在可疑處下Log, 然後從console看Log是否按照自己所設計的邏輯顯示出來. 如果是Fat client程式 而且沒有具備通信功能, IDE的source level debugger就夠用了, 但是目前的程式幾乎都具備有通訊功能, source level dugger在解決realtime的訊息就略顯不足. 使用第三方工具驗證 當解Bug陷入膠著, 通常我會找其它功能正常的工具來驗證, 這種情況在寫DLL, Library或是framework常遇到, 例如我在解通訊程式的封包問題, 我可以先找已經可以正常工作的第三方軟體, 觀察正常的封包到底是長什麼樣子, 不過 這有點像是在做逆

建構與變更管理實務一日研習營 ■ 專案一直無法收斂，Bug、Change Request做不完? ■ 產品出貨了卻發現說明書版本不對? ■ 不清楚新舊版本的差異? ■ 已解決的問題再度發生? ■ 因為客製化需要，重複寫一樣的功能? ■ 客戶來電抱怨功能改版後反而不能用? ■ 不知如何正確使用版本控制工具? 建立正確的建構管理觀念可以幫助您解決以上的問題，且... 建構管理將累積公司的智慧財，大幅提升公司的競爭力 也和產品品質、開發進度、客戶口碑息息相關喔 !! 想知道有什麼實用的方法可以幫助建構管理 ? 建構與變更管理實務研討會 將讓您重新審視您現在的工作方法，發展更具競爭力的流程與團隊。 課程特色 實務與理論兼具的課程編排，透過課程當中的各項案例， 讓學員可以充分了解 ■ 協同作業與任務追蹤 ■ 知識累積與智慧資產 ■ 品質管理與變更控制 等實務與務實做法， 並了解如何運用建構與變更管理跟專案進程之間的共鳴， 達到數字管理的實質目的。 上課對象 1. 專案主管/經理 2. 專案團隊成員 3. 要協同設計並累積公司知識財者 4. 曾經或者即將參與多人協同發展專案者 課程簡介 專案管理已經是 21 世紀的顯學, 無庸置疑的, 我們或多或少都曾參與過甚至主導過專案, 人們也嚮往專案團隊能夠合作無間、順利達成使命的成就感, 本次規劃的 '建構與變更管理' 課程就是為此目的而設, 經由課程當中的各項案例與實務演練過程, 學員可以清楚知道團隊協同合作的堅實基礎該如何建立, 也能充分掌握規劃、執行、控制、改善的重要觀念, 藉由案例演練與工具操作等模擬過程, 學員將能實際體會到建構管理的各項優點, 日後碰到多人協同發展專案時, 定能勾勒出適合專案發展的作業架構。 1. 建構與變更管理 2. 釐清作業方法 3. 案例與對策說明 4. 數據與量化管理 5. 案例與工具運用(包含採用CodeBeamer+ Subversion實現建構管理) 　　 現場有實作練習, 請攜帶notebook上課 講師介紹 高明權 (Tommy Kao

最近在寫一隻iPhone的小程式, 有網路通訊功能, 一開始都很順利, 心中頗為得意, 但是昨天卻踢到了鐵板, 解出來的封包有時候是對的, 有時候卻是錯的, 這時候只好去Trace底層的封包資料結構, 上圖就是, 你看的出這是什麼東東嗎? 說真的經過5~6小時的奮鬥, 我到10分鐘前才掌握出其中資料結構所代表的意義, 也許你會說, 怎麼沒有定義封包格式文件? 這是一個OpenSource的Library ,source code就是文件:-), 所以只好一個byte一個byte把它Dump出來與程式的解碼演算法比對, 以逆向工程來解讀封包的資料結構. 我以為遠離Driver工程師後就不用再去做這樣的事, 但是顯然只要不脫離寫程式的工作, 這種問題隨時會出現. 只好認命一點吧!