2008年11月15日 星期六

挫折感很重的 Cluster setup



  由於一些說不清理還亂的因素,我幫公司接下了幫某金控建置 HA SQL 2005 Cluster Failover infrastucture 的建置工作。
  完全沒經驗的我,想盡辦法取得所有可用的資源,跟 MS 要了本 MCITP Training Book 和 White paper 來 K ,竟然意外地發現我長久以來受到 Consulter Sales 漫天吹牛所得到的 Cluster & Failover 的認知是完全錯誤的!

2008年11月11日 星期二

專案末期的真實開發成本?


延伸閱讀:Feature Request, Or Bug Fixing?
        前一陣子忙到翻天,我手上的系統距離正式上線不到一個月,現在正進行 UAT 的 Cycle 2。所有該到位的功能性需求都到位,總算追趕上進度。今天我把同事本階段 TODO List 內最後一個項目槓掉,一切都進入收斂的階段。

        儘管到了 UAT ,針對同事負責的 Web UI 這塊,每天下午的 UAT Review 會議由使用者提出突發奇想的意見還是蠻多的,除非只是單純畫面呈現的調整,只要是牽扯到程式邏輯與流程的一丁點變動,幾乎都由我這邊阻擋掉。

        無論是我同事或是客戶,似乎都對變動的總體成本沒有正確的概念,事實上,實際的成本總是他們預估的四倍以上有餘,更不用說一開始就估計錯誤的話。帶回 CR 的同事曾說過這樣的話:他們這個需求很簡單,我最多只要花半小時就搞定了,為何要浪費一個小時在會議室跟他們爭論?


        這真的是對成本估計嚴重的誤解。

2008年10月19日 星期日

[ 心得 ] 從程式勞工邁向高階架構師之路-3


        禮拜四到微軟參加這一天的講座課程,講題相當聳動-『從程式勞工邁向高階架構師之路』,觀察現場的人數果然引起相當的迴響吧。

        這次講座知識含量還不錯,尤其是上午場次專門討論對開放原始碼的回收使用的經驗分享,對我格外受用。我自己也會找些開放原始碼來加速專案進展,但和主講者立論較為不同之處,是我比較偏向盡量保持開放原始碼的原貌,而講師的經驗分享則是談到如何追蹤與擷取出真正所需的部份。

2008年10月11日 星期六

死亡預告之當程式人「晉升」至管理階級


        患有重度憂鬱症的苦命工程師朋友 Vincent ,前幾天突然從 MSN 丟了幾篇文章給我。

        其中一篇 [ 當程式人「晉升」至管理階級 ] 看得我膽顫心寒,頭皮發麻。因為我目前專案的現況一切都毫無差錯地被正確敘述著:

        "隨著日子一天一天過去,你或許忙於自己的開發項目,而疏於了解其他成員的情況。但漸漸的,在一些固定的查核點上,你開始發現某些工作項目未能如預期完成,負責這些工作項目的成員總是告訴你,已經完成了 90%,再多給他一些時間,一定能夠完成。但這些工作項目,有些像是無法抵達終點一樣,始終未能完成。

2008年9月28日 星期日

[ 引用 ] TechEd 2008 重點整理

        連續參加 2006 / 2007 兩年 Microsoft TechEd ,今年的 TechED 2008 我沒參加。不過本來就預期今年的內容應該會蠻弱勢的,不比以往,所以沒甚麼可惜之處。

2008年8月30日 星期六

一個好的開發人員帶你上天堂,數個鳥開發人員拖你下地獄



  最近上網查資料,意外在我訂閱的部落格中,一個深入探討許多 .net 技術的優良部落格黑暗執行緒中挖到一篇好文,探討現今專業不被重視的社會中,優秀的工程師和平庸的工程師之間的天壤之別。像是這麼偏僻入裡的文章,身為技術人員而為榮的我一定要大推一下的啦:


  Developers, Are You Underpaid Or Overpaid? ( 雖然英文標題,但是中文文章 )


  其中有一段作者描述和新來的工程師相處的際遇,更是看得我在四下無人下頻頻點頭:


  「想起在前公司有個開發人員,我將一個案子交給這位前同事接手,幾天過去了,沒有聽到任何消息,心想:很好,事情應該很順利!又幾天過去了,我晃到他座位旁去關心一下進度,他老兄居然跟我說,他搞不太懂其中幾項需求,原來這陣子的時間全都在『搞懂需求』這件事上空轉。」


  這讓我想起最近帶著新同事合作開發專案的狀況。


  記得兩年前我跟著師父投奔去新竹時,也發現那邊半導體封測廠的老闆對軟體專業的不重視。既然花了大錢和公司股票請獵人頭公司挖角師父,卻在軟體開發專業上又不採納其意見,一昧地在言談表達覺得寫程式沒甚麼大不了。因為彼此對對方的專長領域不熟悉,每次爭論總淪為角力,看誰能把話題轉到自己的領域上就可讓對方辯無可辯,最後討論總變為模糊焦點的爭論...。


  但是想當然爾,CEO 和 RD 頭之間的戰爭誰比較可能獲得最後勝利?當然最後人事違和之下結束了我短命的新竹之旅,雖然這一出走也同時引爆該公司大量的開發人員陸續出走...。


  總之,這篇讓我心有戚戚焉的文章,希望廣為留傳,讓更多人知道工程師之間的差異決不是表面上看來這個簡單的計算!


  裡面有句重點:「優秀的開發人員通常薪水是偏低的,而鳥鳥的開發人員則多領了不該領的錢。


  最懂得精打細算的老闆們,到底應該好好善待幾個物超所值的優秀開發人員?還是大不了多顧幾個鳥鳥的開發人員來頂替他?


2008年8月24日 星期日

因為蝴蝶效應,所以軟體專案管理與眾不同。


  為何拿到了當紅專案管理師證照 ( PMP ) 的專業 PM,遇到軟體專案的管理實務仍是經常吃鱉和踢到鐵板?專案管理的需求普遍出現在各行各業,但為何唯獨軟體專案的管理可以不斷地在書店中推陳出新一再討論?到底,軟體專案的與眾不同之處在哪裡?為何軟體的品質如此難以掌握?
  說穿了,軟體專案的機動性、變動性與不確定性是遠高出其他性質的專案,而且,軟體的變動是最容易產生所謂「蝴蝶效應」。
  「巴西的蝴蝶煽動翅膀,引發德克薩州的暴風雨」誠可描述軟體專案常引發的系統現象。
  過去經驗已經證實,一般工程界常使用的瀑布式開發在軟體專案已證實並不適用,原因一方面是發生需求的機動性、另外是專案生命週期短暫,資源與時間成本不足以在開發前釐清所有需求與定案。

  但上面所述是後天人為環境所造成的特性,我們探討一下軟體開發本身的特異性,就是考量日後維護方便,而在軟體工程上不斷強調的共通性的抽離。常看軟體架構的書,一定會時常看到下圖這種類似堆積木的圖表 ( From Google Andriod architecture overview ),這代表的就是軟體環境是仰賴著基礎建設進行疊床架屋的模式演繹:

  想想看,高樓大廈蓋了差不多的時候,才發現當初地基打得不夠深,有可能不拆掉房子回頭把地基挖深嗎?但是在軟體專案中,釜底抽薪卻是十分常見的招數。程式跑得不夠穩?直接升級作業系統吧 ( 98 --> XP ),程式跑得不夠快?降級作業系統吧 (Vista --> XP )。
  綜觀其他業界,對於個別專案其實都有「資源獨佔」的特色,而「整合、開放、互通」卻是資訊軟體業的特色,也正是蝴蝶效應的溫床。想想看,一個建設公司為了降低成本或是強化材質而採用了新的混凝土水泥配方,會影響到該公司之前已經完工的大樓嗎?已經完成的部分幾乎已成定局,幾乎不會受其他外界因素改變而影響,這就是我所謂的「資源獨佔性」,但資訊業的整合技術的通透性,卻非如此。已經完工的功能模組、甚至已經上線運行多年的系統,因為外界一個看似毫不相關的改變而受衝擊的例子我隨便回想也有十多種案例。
  隨手舉個真實案例,來說明這種意料外的蝴蝶效應。
  某企業外包其薪資系統,該薪資系統是根據該企業現存共通的 HR ( 人力資源 ) 資料庫進行規劃與設計。得標的資訊公司因受限該企業現存的 HR 資料庫的結構與欄位限制,所以某部分報表所需使用到的暫存計算結果都是必須即時運算得出,而使上線幾個月的薪資系統導致「可正常使用但是效能不彰」的批評。
  於是該專案的 PM,經過評估,做了個「非常小的變動,但可大幅提升效能」的決定:就是要求在該 HR 的員工資料表 (Employee table ) 中添加一個新欄位 ( 假設新欄位名為 RowCount ),用來做為記錄最後一次計算結果,該欄位的資料只在相關資料變動時做必要的更新,如此以往每次跑報表需要即時計算加總的資料,變成立即可以隨手取用,效能表現的確讓在場所有人笑顏逐開。
  這個決定的風險考量呢?大家直覺的反應:「資料庫現存的欄位與資料全部沒有任何改變和影響,對現有的舊程式不會有任何衝擊。」是啊,一個 DLL library 原本有 10 個 API,多一個新的變成 11 個 API,對已經在使用原本就有的 10 個 API 的程式來說應該沒有影響啊。
  是嗎?也許有經驗的開發人員已經嗅出這個決定所忽略的風險是什麼了,但故事先繼續下去。
  新版的薪資系統幾經測試看來一切順利,翻翻黃曆挑了個黃道吉日上線,卻發現早已運行多年的 HR 人資系統突然間當機連連無法使用!人資系統的原始廠商在未事前照會、且系統已經使用多年乏人問津,是否仍在保固或是否有能力進行保固皆在未定之天的情況下,給了個想當然爾的回覆:「多年使用都沒出過事 ( or 其他那麼多客戶都沒出事 ),一定是你們自己做了什麼不可告人的勾當!」
  結局當然,新版的薪資系統被迫退版下線。其實造成 HR 系統無法運作的原因很簡單,因為 HR 系統內有個 SQL 語法把員工資料表與薪資記錄表連接起來:
SELECT * FROM Employee, Salaries WHERE Employee.ID = Salaries.EmployeeID
  而恰恰好,這個薪資記錄表內正好有個和 Employee 新添加的欄位同名同姓的 RowCount 欄位,這使得原本 HR 系統可以單純以 RowCount 找到他所需要的資料,卻變成必須透過前置詞 Salaries.RowCount 才能抓到正確的資料。
  這個問題好解決,新版的薪資系統改用其他不會產生重複衝突的欄位名稱即可。
  也許看這篇文章的人早料到這樣的風險並內心暗自批評該團隊太不專業,這麼顯而易見的風險都沒評估到。但我想重點是:不經一事不長一智各位自認專業有經驗的傑出人員在進行任何改變的決策之前,又真的有自信能評估到所有不可見的風險嗎?自認為的小改變、小需求,真的只是小改變、小需求嗎?還是你只看到冰山那一角
  如果經驗和遠見,真的只能從錯誤中學習 ( 我同意的確只能如此 ),在長江後浪推前浪之下,那誰來替我們客戶所使用的軟體做品質把關?前幾個客戶就當真是倒楣的白老鼠,給實習醫生練開刀的?
  在不預設立場的情況下,不論是十多年經驗的 PM 或是初掌兵符的 PM,軟體的品質唯有「測試、測試、再測試」,一句話,真金不怕火煉而已
  但是,完整的高密度測試,從單元測試、系統整合測試、壓力測試,所耗費的代價與人力大不大?非常巨大!
  若有認為測試沒啥大不了的想法,就代表根本沒在好好用心測。正常說來,測試和開發的成本比差不多 1 : 1 ( 但實務上客戶總會壓縮測試時程,這就是外行領導內行 )。
  回顧到此的重點:軟體專案的測試成本之高,源自於資訊環境容易產生「蝴蝶效應」所致,所以任何改變所引發的測試,決不只是表面上所看到的那些改變的測試,而是一個「全面性的測試」。
  將測試粗分為三個大階段,即是大家所熟知的 Alpha 、 Beta 、 Release Candidate ( RC ) ,之後 RTM ( Ready To Manufacture ) 幾本上就是進工廠量產的原型母片,不列入其內。
  各個軟體公司可能對這三大階段的定義略有不同,但大致上如下:

  • ALPHA:所有需求已凍結與定案,這階段的測是全力在找出所有程式錯誤臭蟲並修補。然而,在這個階段還可以做的重大決定,就是「拿掉」某些功能。然而這個拿掉的動作,不是單純的拿掉,是具有技巧性的以減低影響和風險,這部分稍後詳細介紹。


  • BETA:連「拿掉」的動作皆不再允許,功能規格 100% 確立,此階段全力檢驗前一階段找出的所有錯誤與臭蟲是否掃除乾淨,並將所有步驟重新來過,以便偵測出修補的動作是否引發新的錯誤臭蟲。


  • RC:已知的臭蟲已減少到可接受的範圍,開始進行使用者接受度測試,有些軟體公司會下放給外界第一階段的使用者或是特定社群做測試,以便回報更多可用資訊,或是在公司內部開始強制規定自己的一般員工開始安裝並使用此軟體以求意見回饋。這個階段的收穫基本上不改變產品架構與行為,多半影響使用說明文件的製作方式或是包裝行銷的模式。


  上面這三大階段可在各自細分,但我就不多說了。
  現在回頭細談在 ALPHA 階段移除功能這件事情。移除功能,是減少測試的負荷並追趕上市時程的常見手段,通常是發現某功能的相關錯誤怎麼測也測不完、修也修不完,這時只能忍痛拿掉。所以我們常見到世界某大軟體公司的產品,在 ALPHA 階段內建或是宣稱的功能,在 BETA 階段斷然消失,每次釋出的測試版本也都會有行小字提示:現在看到的不見得是真的,一切以上市後的正式產品為準。
  在上篇「專案經理到底該怎麼做」的文章,我強烈表示在 ALPHA 階段末期加入新需求是不智之舉,其中一個原因,就是專案經理預期不到的「蝴蝶效應」會讓整個專案進度倒退到 ALPHA 階段前,所有的測試必須重新來過,這等同於之前在 ALPHA 階段的測試投資全都是白費,延誤專案的可能性風險大增!
  那麼,拿掉功能不也有同樣的風險嗎?是的,所以說拿掉是有技巧的,拿掉不見得是移除,並不需要把相關的程式碼找出然後按下鍵盤的 [ DEL ]  鍵或是 [ Backspace ] 來刪光光,而是只要封蓋,讓使用者看不到摸不著即可。使用者無法使用該功能,不代表你系統的其他模組沒有呼叫該相關的程式碼,所以必須不見光地保留,讓風險降到最低。
  很多臭蟲大多是異常輸入或是異常處理沒有做好,封蓋的第一個好處就是免除了該功能對 Monkey Test 的反應與測試,但不影響其他程式碼的穩定性。
  所以我們會聽說一些世界某大軟體公司的產品有些非文件記載的 API 流出 ( 即代表對此 API 的功用不保證,如果你開發的軟體硬要使用,後果自負 ),或是遊戲軟體有密技可以出書,或是某些軟體有後門或隱藏功能可以使用... etc。
  就算使用「封蓋」的方式拿掉某些功能,全面性的重新測試仍是必須的,但是因為直接接觸使用者的面積減少,所以也同時減少了接下來三個階段的 Test scenario,因此對整個專案的時程影響不會太巨大。
  談完以上這些,我必須說軟體專案有其特異性,沒有實務上累積開發技術經驗的人,就算拿了 PMP 並且整天抱著個 PMBOK 在說嘴的人,根本不可能管理好軟體專案,也不可能是值得與他討論的對象。

2008年7月16日 星期三

半夜不想畫地圖...


  地圖日記算是最近新創社群網站中表現最亮眼、話題性與成長最快的網站。這個網站當初在國內外的 DEMO 大展上引爆話題,我就跟老婆聊到有這麼一個創新的網站點子 - 在地圖上寫日記。

  當時,我對此網站一切的了解都來自報導,實際上並沒有親自去玩他提供的服務。後來不知怎地,老婆因緣際會自己申請加入了地圖日記,從此我就幾乎常看她待在上面流連忘返。

  平平大家同樣是個寫日記、上傳照片的 BSP ( 部落格服務 ),為何地圖日記可以抓住大家不一樣的目光。在財大氣粗又卑鄙無名和師出同門的痞客還在為了所謂的功能性強弱廝殺在紅海當中,地圖日記真的抓到一個心理上的甜蜜點 - 利用地域性的觀念來關聯日記與文章

2008年6月26日 星期四

ASP.net 1.1 -- (*@__@*) --> ASP.net 2.0

  .NET 1.1 已經是微軟不可能再回頭支援的過時玩意了,.NET 2.0 的核心才是他未來技術發展的基石 ( 目前推出的 .NET 3.5 仍是以 2.0 為底層 )。對於微軟這種全面性推翻舊東西硬是逼著你升級的做法,我是很感冒,由其是對於過去 1.1 時代就選擇支持它的群眾,如今卻被逼著必須同時安裝多套不同的 IDE 來回在不同版本的程式間作維護。

  如今許多方便好用的功能都已經內建在  .NET 2.0 之上,回頭看看當初 1.1 寫的東西總是很想掉下眼淚,無奈自己已經誤上賊船,為了降低將來維護成本並且增加未來發展的視野性,最近幾天就鐵下心來,籌畫著將私底下仍在經營的網站,升級到 ASP.NET 2.0。

  為了讓整個升級過程無痛,我不想讓使用者發覺停機過久,盡量讓網站無法運作的時間縮短在一個「瞬間」,所以我決定利用 ASP.NET 2.0 / CLR 2.0 仍可以執行 1.1 版本的向下相容特性,決定先透過變更 IIS 內的版本設定讓 ASP.NET 1.1 開發的網站先執行在 2.0 的環境底下,等到平穩後,再找個機會以迅雷不及掩耳的速度,將重新編譯過的新版網站上傳到 FTP 蓋過舊的,這個過程理應只有幾個線上的使用者的 Session 失效,重新登入或是重新整理網頁就一切正常。

  其實整個過程說來蠻單純的,風險應該不大,但讓我拖了一年半載遲遲沒有動手的原因,主要就是用 ASP.NET 2.0 去執行 ASP.NET 1.1 的向下相容性並沒有很好,實際跑起來還遇到蠻多問題的,一直讓我怯步。

  首先,為了讓我的網站能同時支援以不同語言來顯示畫面 ( 目前同時支援 繁中 / 簡中 / 英文 的操作畫面 ),所以我網頁上的顯示文字是根據使用者下拉語言的選單動態產生的。我實做的方式很簡單,就是以一個 XML 檔儲存所有控件顯示的文字訊息。例如我有一個網頁 Index.aspx 上面還有一個顯示訊息的 Label ,其 ID = Label_Welcome,那我在繁中的 XML 語言檔 ( zh-tw.xml ) 就是如下:

<root>
    <Index>
        <Label_Welcome>歡迎光臨</Label_Welcome>
    </Index>
</root>

  如果是英文的語言檔 ( en-us.xml ) 就如下:

<root>
    <Index>
        <Label_Welcome>WELCOME!!</Label_Welcome>
    </Index>
</root>

  要讀取哪個檔案依下拉選單來決定,然後在每個 page 的 _PreRender() event 中依 [ 頁面類別名稱 + 控件 ID ] 組成的 XPath 去做顯示文字的讀取。但事實上,ASP.NET 在實際執行的時候,使用的不是你原本開發時撰寫的 class,而是它動態產生出來、繼承自你頁面 class 的新 class,而你當初編譯完成的 dll 其實也只是被它拿來當作 Code-Gen 引用參考的對象而已。

  ASP.NET 動態產生出來的頁面執行 class 通常命名為以下的規則:[ 你撰寫的頁面 class
名稱 + "_aspx"
],為此,如上述的網頁實際上會產生 Index_aspx 的新類別,所以我在使用
this.GetType().Name 組合 XPath 時,需要做點後製加工。當時的做法是把後面尾巴產生出的 "_aspx" 硬切掉 ( this.GetType().Name.Replace("_aspx", string.empty) )。

  但是不知何故,切換到 ASP.NET 2.0 的 runtime 執行,這個做法就失效了,整個頁面一整個空白,完全顯示不出任何文字。

  由於 VS 2003 無法 Attach 上 .NET 2.0 的 runtime process 做 debug,我也懶得修改程式吐 OutputDebugString,所有就沉潛了好一陣子置之不理。直到前幾個月突然心血來潮,一研究才發現到了 ASP.NET 2.0,動態產生的 Code-Gen 的命名規則改了,不管你原本的名字的大小寫,它會一律轉為全部小寫!所以我原本的 Index 會變成 index_aspx ( 這是哪個微軟的白痴工程師做出來的向下相容性啊?連這種無關緊要 naming rule 的小地方都不相容... )。去掉尾巴後,index 和 Index 由於大小寫的差異造成 XPath 讀取不到正確的顯示文字。

  知道問題所在後,改為直接使用 GetType().BaseType.Name 來解決此問題,寫法也比直接處理字串加工來得簡潔合理。

  測試一段時間看來沒太大問題,放上網站後,填申請表請虛擬主機商的工程人員幫我切換到 2.0 runtime,然後就靜悄悄地等幾天,也無法預知他何時會做轉換。所以這就是為何我非得經歷 2.0 跑 1.1 後,再轉換到 pure 2.0 的過程,因為無法預料對方何時幫我轉換設定

  不過看來昨天主機商下午幫我調整過設定,我信箱中收到一堆系統錯誤信件,發現所有線上交易都已經停擺了數小時。

  緊急調查下發現系統異常信件中提到:

Exception Content :
System.Web.HttpUnhandledException:
已發生類型 'System.Web.HttpUnhandledException' 的例外狀況。
---> System.ArgumentException:

無效的回傳或回呼引數。
已在組態中使用
或在網頁中使用 <%@ Page EnableEventValidation="true" %> 啟用事件驗證。

基於安全性理由,這項功能驗證回傳或回呼引數是來自原本呈現它們的伺服器控制項。如果資料為有效並且是必需的,請使用
ClientScriptManager.RegisterForEventValidation 方法註冊回傳或回呼資料,以進行驗證。"

  原來之前因為多層選單使用 ASP.NET 的 AutoPostBack 機制,嚴重讓使用者抱怨,故我修改為輸出許多 JScript 在瀏覽器端處理多重下拉選單的更新問題,但到了 2.0 ,這些 JScript 會動態修改原本 ServerControl 輸出時的內容造成和原本的 ViewState 產生差異,導致安全性驗證失敗。好在立刻在該頁面加註 [ EnableEventValidation="false" ] 關閉驗證就解決此問題。

  但是事情還沒結束,早上又再次收到一堆系統錯誤訊息,發現日期字串無法識別?

  "System.FormatException:字串未被辨認為有效的 DateTime

  仔細檢查程式碼,才發現之前我在組合日期字串時錯用了斜線符號:[ 2008//06//27 10:00 ],我大概老眼昏花,誤以為這是跳脫字元所使用的反斜線 ( \ ) ,所以都重複鍵入兩次。但這樣的日期解析,在 .NET 1.1 是可以被正確識別的

  好吧,又一個緊急上版修正這個問題。

  就這樣結束了嗎?不,這篇文章尚未完成的當下,我信箱內再度出現使用者抱怨的信件,說所有的電子訂單的金額都變成 0 ,要我緊急修復!God!再跳下去查,原來過去我為了增加效能,把部分 ServerControl 的 ViewState 給 Disable ,尤其是 TextBox 。

  因為我發現即使關閉 TextBox 的 ViewState ,因為 Submit Button 按下去時,瀏覽器照樣會將使用者輸入的資料回傳, ASP.NET 照樣會在初始化的時候將將該 value 填入控制項內,並不會取不到資料,功效相同卻不需要額外存放 Text Value 以外的其他 Properties。

  同樣,到了 2.0 ,這樣的做法式不行的,一切以 ViewState 驗證過的資料為主,於是乎沒有 ViewState 的 TextBox Control 瞬間被釘死。

  方才又修正好這個問題,不僅要抱怨一下,微軟的一個升級,在小細節上實在有太多不相容與不一致性了。這次轉換後,短時間不敢再輕易嘗試原本計畫中的下半場步驟 ---> 整個網站重新編譯成原生的 ASP.NET 2.0 版本現在是在 2.0 Engine 下以相容模式跑 1.1 的編譯產物 ) 。

2008年6月13日 星期五

BizTalk 之我思我見



  完成連續四天的課程後,昨天從恆逸拿到我這輩子第一張電腦技能的修業證書,沒想到既不是 .NET ,也不是 Java,竟然是做夢也沒想到的 BizTalk 2006

  雖然上面印著 Certificate 的 Title ,但這只是個無足輕重的修業證明,並不是證照。然而岳父卻非常看重這個證照橫行的時代,每每面對我這個除了駕照以外一無所有的軟體工程師,總是碎碎念,認為我技不如人、遲早被社會淘汰

  Anyway,這張假證照或許日後可以幫我唬弄過去,反正他甚麼也搞不懂。

  對於有程式開發背景的人來說, BizTalk 大體上並不難理解與入手,一本我目測約三百多頁的原文教材,包含上機實做練習,四個全天就講完了。但是我極度懷疑沒有程式開發背景的人員能夠理解 BizTalk 這套軟體的操作,所以基本上,我看待這個產品並不是取代程式開發人員的工具,但「或許」是節省開發人員時間與負擔的工具。

  強調「或許」,是對於開發老手,他早以手邊累積不少現成的套件或是函式庫,熟悉 OpenSource 的開發資源與現成的 Class,旁徵博引的開發效率未必會比滑鼠設定 BizTalk 內的各個 Pipeline / Adapter / Schema 來得慢,甚至可能還快上許多。但是對於新進的開發人員,BizTalk 提供許多現成的基礎環境設施與視覺化設定,應該可以幫助菜鳥進入實戰階段,所以充其量,BizTalk 是個拉近新手和老手之間差距的工具。

  也許有人會說,產品的設定與視覺化開發比起程式碼來得好維護,這應該是 BizTalk 該勝出的地方,但事實卻不然。

  我承認菜鳥工程師的程式碼解讀時會冒出無名火,但現在比較的狀況是,[ 經驗老道的工程師  vs ( 菜鳥工程師 + BizTalk ) ] ,如果常常去看 OpenSource 的開發人員會知道,有經驗的開發人員寫出的程式碼其實不難端倪,而且可修改的彈性高出甚多,逐步除錯也容易。但是,BizTalk
的除錯非常困難,且修改不易。整個上課過程中,我就飽受「一步錯,整個重來」的痛苦,一個 Schema 建錯,可能牽涉到的 Flow、Mapper、Pipeline、Ports...全部都得跟著調整或是重建,而且如果漏掉任何一個環節沒修正,非常不容易發覺,只知道訊息有進無回。



  說到日後維護容易嘛...,因為圖型介面使得一張圖勝過千言萬語,交接與理解較為容易,這些論點因為我缺乏真正的實務經驗,不作評論 ( 依我所聽到的前人經驗,他人接手前人的專案,其實並沒有比較容易交接或是理解 ) ,但我要強調,即使真的有這個好處也是應該的,公司並不會因為維護容易而降低維護成本增加獲利,因為你帶入產品進去做,每年的維護費用收入本來就會有部分被產品的原廠 ( ex. 微軟** ) 拿走,公司真正能從每年維護營利的金額本來就比完全自己做來得低許多。但如果帶了 BizTalk 進去做,維護成本沒降低多少,那開發廠商豈不是虧到沒衛生紙擦屁股?

  目前我參觀過的幾個 BPM Solution - TIBCO、IBM WebLogic 和 BizTalk,微軟的 BizTalk
是最為技術人員導向的產品,也是商務功能最弱的。

  這幾天上課,我嘗試分析 BizTalk 的成本效應。以它標準版 ( Standard Edition ) 的售價每顆 CPU 索價台幣 30 萬,中小型標案帶入不划算,價錢也無競爭力,但是大型案子要到多大的規模帶入,才能發揮效益產生競爭力呢?

  我的評估方式如下,如果某 SI 廠商的人日報價單價為 NT$10,000 / 人日,引進一顆 CPU 的 BizTalk 標準版授權,就必須至少縮短專案 30 個人日的開發成本才剛好打平。

  如果,客戶使用一台兩顆 CPU 的機器當伺服器,BizTalk Standard 就要額外開銷 60 萬,這還是在不需要買測試機授權的狀況下。然後,假設引進 BizTalk 可以節省 1 / 3 的人日成本,使專案上線時程縮短,如果要剛好達到平衡,BizTalk 的 60 萬開銷就至少必須與這 1 / 3 的人日的成本節省等價。

  剛提到一個人日一萬,60 萬就等於 60 個人日,也就是當總專案預估時程為 180 個人日的規模,引進 BizTalk Standard 版會剛好達成「開發階段」的成本平衡。這只是單論開發階段,也就是前期需求訪談、系統分析 (SA )、系統設計 ( SD ),與後期上線前測試階段系統整合測試 ( SIT )、使用者接受度測試 (UAT )、驗收流程 ( 文件 ) 都無法節省的狀況,專案規模至少要 235 個人日,也就是 235 萬以上的案子帶入 BizTalk 才有獲利的可能。

  以上的試算的情境 Scenario 純屬初估,而且是以單一案子導入為前提 ( 不考慮同一個客戶日後有第二案或是第三案在同一台伺服器上利用 BizTalk 額外建置的狀況,所以說做生意要看遠、做遠就是這個意思 ^_^ )。以下提供簡易的公式僅供導入的評估參考:

  適合導入 BizTalk 的專案規模 = [BizTalk 版本單價] * [CPU 數量] / [導入後預計節省的人日比例 ( 上例中為 1 / 3 ) ] * [130% ( 依比例計算前期與後期-非開發時期的人日成本 )]

  要提醒幾點,導入後能節省 1 / 3 的開發人力是非常非常樂觀的估計,聽有實務經驗的人說能節省 1 / 5 ~ 1 / 10 就偷笑了。其次,懂 BizTalk 的設計師人員的薪資一定比只會  Coding 的菜鳥工程師來的高出不少,就算不影響廠商給客戶的專案報價,也一定會墊高成本侵蝕利潤,這些都是必須再斟酌的。

** 微軟的維護費用不是採取一般廠商所使用的按產品售價比例收取維護費用的方式,而是採取買問題點數的做法。

*** 老師張 x 源其實教的還算有水準,雖然有些小錯誤,但還算用心。我現在都不太敢打別人的全名,因為發現大家都喜歡上 Google 查詢自己的名字。之前在中央聽了一場演講,我把對方講者的全名寫在部落格上,沒隔幾天,該篇文章就出現該演講者的回應跟我打招呼...

2008年4月28日 星期一

Heros Happen { Here } -- 2008 announcing


  今天一整天參加了微軟 Windows Server 2008 & VisualStudio 2008 的聯合上市發表會。這是個規模媲美要收幾千塊門票錢的 TechEd 的免費大型活動,看到微軟現場所動用的資源,可見這兩個組合真是微軟的心肝寶貝。

    照例, 早上 Session Openning 一樣有精心拍攝不輸美國影集製作水準的宣傳廣告片,以及話劇演出。

  每次看到這些,就會興起我幻想的念頭,將來我自己開的公司也要搞這些宣傳影片...。看來也許我跟李安一樣鍾愛的是拍電影、而不是寫程式做軟體。

  縱然我從小就是喝微軟的奶水長大的,但心底總是對其他平台與技術心生嚮往,例如,Java & Linux。總希望有朝一日可以脫離微軟的束縛,我想那應該是件很有成就感的事。

  但是看過這次微軟這兩款與我工作高度相關的重量級產品發表會,我越來越不能堅定這個願望。

  加上這次透露今年九月後,微軟將會模仿當年 JavaApplet 的做法,推出真正可以跨平台、可以依附相容在所有各家瀏覽器的 mini CLR engine。這個重要的宣示意義,代表日後我們都可以直接使用原生的 .NET 語言來開發各種平台瀏覽器端的應用程式,如果這個願望成真,不但從此擺脫不同瀏覽器對 JavaScript 支援度不一致的惡夢,且可以在一個舒適一致的環境下盡情高速開發所有的網際網路應用程式,最重要的是,各個不同的作業系統,甚至 Linux 上都可以執行我使用 .NET 開發的軟體。

  有這樣的願景,更加動搖我原本打算學習 Java 的想法 ( 因為當初就是為了跨平台 )。

  當然,這種仿 JApplet 的做法所使用的 mini CLR engine,應該能做的事情程度不會超過 .NET Compact Framework 就是了。

  另外關於 Visual Studio 2008,算是把 VS 2005 成熟化,基本上令人驚艷的東西都和 VS 2005 差不多,只是搭配 .NET 3.5 把原本需要另外下載的 Libraries 變成內建功能。

  不過整合 TeamSystem 的專案管理 Feature 的開發環境真的還是非常吸引人呢!

2008年4月15日 星期二

黑傑克捉鬼記


        趁今天結束之前,趕緊補一篇湊數的文章 ^_^。

        上回談到程式鬼打牆,測不準原理,這一篇就讓我來用淺顯易懂的白話文來抓鬼揭秘吧。


        其實程式會出現這樣結果不一致的落差,來自於 Performance 考量的思維 --


        只要當你真正要看運算結果的時後才進行運算,否則你只是要我運算,我還是可以先偷懶擺爛。

2008年4月7日 星期一

程式鬼打牆,海森堡測不準原理

  最近這兩天都遇到鬼打牆事件,明明預估很簡單輕鬆,可以提早下班的工作,卻連兩天都遇到當場傻眼無法解釋的現象,弄到加班都差點搞不定。

  其實軟體開發就像是堆疊黑盒子的積木,你很難確定一個函式呼叫後,底層到底是怎樣運作才生出你所渴望的回傳值?

  今天我遇到一個鬼打牆的狀態,那現象就像是你要學生背英文單字,要求他邊寫邊大聲地唸出來。你看他唸得字正腔圓,紙上書寫的單字也拼得正確極了,於是乎你放心的說:這些單字你都會了,默寫就好,不用唸出聲。但結果你回頭檢查紙上默寫的單字,卻每個全都拼錯!?

  大驚之下,你又要求學生邊寫邊唸,結果又是全都正確,但是等下默寫又全拼錯了...。

  如果你是老師,八成這時候已經認定這個學生性格乖戾在惡搞你,恨得心癢癢拿起教鞭痛扁這劣徒一頓。但是,我這次所遇到的這個學生,卻是一支 .NET Framework 標準 Class Library 內的標準 API。

  上面寫的,是給不懂程式開發的朋友理解我所遇到的鬼打牆狀況。這種現象,像極了我物理界背景的朋友耳熟能詳的量子物理現象,測不準原理。

  先聲明,這是一個單一處理程序與單一執行緒簡單到不行的程式。

  整件事就是開發時期,為了仔細觀察資料的變化,我會不斷把資料每個步驟後的狀態都輸出到螢幕上 ( Debug.WriteLine( ... ) ),確定他的變化如我預期。等到確定資料的每個狀態都正確後,我唯一做的事情就是把輸出到螢幕上的程式全部移除,交給客戶測試。沒想到資料結果怎麼測怎麼錯,連我自己機器上也跑不出正常預期的結果,我在客戶面前簡直是傻眼變成張口結舌的阿呆,五分鐘前那句我都測過,絕對沒問題。無疑是當場賞兩巴掌讓我信用破產。

  我不敢吭聲地趕緊把剛剛移掉的那些用來把資料輸出到螢幕上的程式復原回來 ( 就只是單純的把註解掉的 Debug.WriteLine( ... ) 回復,絕沒有更多多餘的動作 ),準備開始除錯找出問題,結果一切又都正常了。

  「可能我剛剛版本更新沒有成功吧?我心想,然後又把那些輸出螢幕的程式移掉再更新一次,靠!程式一跑資料又全錯?

  這件事真的是反反覆覆搞了我快一小時那麼久,客戶在旁看我這跳樑的小丑都快打嗑睡了。當然,這件事我最後找出可以理解的原因,也避開了這個問題,不過理解原因後,不免要對微軟的 .NET Framework 的 API 不夠直覺的設計缺失感到不悅。

  如果大家對這個程式的測不準原理的現象感到好奇想體驗,我提供以下的程式碼讓有興趣的人玩玩,至於造成此現象的原因,就留給大家自行參透吧 (或我下次在撰文解答 ):

  程式說明:這是一個處理以下 XML 文檔的簡單程式,

  <Root>
    <A/>
    <B>
      <BB/>
      <BB/>
    </B>
  </Root>

  程式要取出所有 <BB></BB> 內的資料,並且從整份 XML 內移除 <B></B> 節點 ( XmlNode )。

  Code (.Net 1.1 & C#):




string sXml = "<Root><A/><B><BB/><BB/></B></Root>";

XmlDocument oDoc = new XmlDocument();

oDoc.LoadXml(sXml);

// 關鍵來了

XmlNodeList oBBNodes = oDoc.SelectNodes("//Root/B/BB");

// Debug.WriteLine("oBBNodes.Count=" + oBBNodes.Count);

XmlNode oBNode = oDoc.SelectSingleNode("//Root/B");

if (null != oBNode) oDoc.DocumentElement.Remove(oBNode);    // 從原本的 XML 文件中拔除 <B></B> 以下的整個節點

Debug.WriteLine("oBBNodes.Count=" + oBBNodes.Count);




  這樣你就可以看到這懸疑的現象了。oBBNodes 明明就應該有兩個節點 ( Count=2 ),但是執行以上的程式,螢幕上卻會得到 "oBBNodes.Count=0" 的答案。

  但是如果把第六行的 // Debug.Wr..... 的註解恢復成可執行的 Code,結果螢幕上跑出來的輸出卻是:

   oBBNodes.Count=2
   oBBNodes.Count=2

  螢幕重複兩次輸出,但都是正確答案。

  哈,真的是很像測不準吧。如果不想跑出第六行的螢幕輸出,卻又想呈現最後正確的結果,可以把原本第六行的程式改成 "int n = oBBNodes.Count;" 做個愚蠢的虛功即可。

  真的是一整個蠢到不行。

2008年2月28日 星期四

除了 Y2K, 系統遇到閏年也是一個難關啊~~

  今天是四年一次的閏年 Feb 29。

  不約而同地,許多地方的不同系統都在這一個特別的日子開始作怪,這是就算乖乖也沒辦法保佑的災難。

  我手上 CXBC 的通知平台系統,在這一天發出給客戶的交易通知,所有從西元年轉換成民國年的資料全部錯誤,顯示民國 97 年 2 月 28 日,讓客戶把今天和昨天的帳務全搞混在一起,客訴電話直逼服務人員腦門。

  朋友在國 X 會負責的人資系統,也發現請假單開不出來,畢竟很多人會在今天請個假和 228 與週末湊個連續假期,不過幸運的是,請假作業是提前進行所以及早發現這個系統的毛病。但是另一個營運主系統則當得很慘,死機好幾個小時才搞清楚原來是閏年計算錯誤的問題。

  用民國年計算閏年是不行的!要用西元年,西元年!】

  【這不是學校老師都會出的作業習題嗎?小小毛病鬧這麼大?】
  ( 這凸顯我這種非正統科班出身的程式員的訓練不足與悲哀 )

  【你們這些廠商程式都不好好寫。】

  透過 MSN ,我彷彿看到身為 MIS 的朋友難以置信地咆哮著...。

  我遇到的問題呢,則是西元轉民國年,使用系統底層萬年曆運算,直接減去 1911 年所造成的,這種寫法的意思相當於,1911年前 ( 西元 97 年 ) 的今天的日期是幾月幾號。這樣的結果,找出的那一天當然不是閏年的二月 29 日。

  聽到這樣做法的 MIS 朋友,簡直不可思議地直叫:見鬼了!

  要在最短的時間內 ( 今天營業日之前 ) 緊急搶救這個問題,我採用最 dirty 的方法,直接字串取代的方式硬生生幹掉,不過這並不能完整地解決此問題,只是暫時性的規避。我發現,要完整的解決此問題還不是件容易的事呢!因為程式允許使用者傳入 DateTime Format String 來自訂日期格式,我是先知道使用者會使用 "yyy/MM/dd" 的格式然後在程式中硬生生地針對這種 Case 作 Replace,若真要完整解決,我還得自己撰寫完整的 FomatString Parser 才行,工程實在不小。

  總之,先過今天再慢慢想完整的解法。

  像這樣的 bug 四年出現一次,當初做再多測試也不太可能事前測出這樣的 bug,只能說要寫出個沒有 bug 的系統真是不太可能。

  處理閏年的問題,就留個不會遺忘的慘痛經驗來記起教訓吧。

2008年2月1日 星期五

[ 轉貼 ] 十年一覺程設夢 ( 下 )


前情提要點此


  原先我喜歡當工程師, 獨自躲在安靜的角落, 把上級交代的事做完後, 就天馬行空想新點子, 上網找資料看論文, 然後動手實作出來. 坦白說, 軟體工程師是蠻幸福的, 只需一台 PC, 有上網環境, 就可以實踐創意. 不需像硬體工程師需要一堆設備跟很多單位配合, 才能動手.


  然而經歷過 6 年不受重視被冰凍的職場生涯後, 我的態度改變了.


  公司規模變很大後, 一些事情都慢慢變複雜, 日後能給我自由空間發揮的直屬高級主管恐怕也不多見. 而且遇上一些案子, 高層會先考量需求的研發/維護人力, 來交給一個 team, 而非一個人來執行.


  工程師的我永遠是邊緣人, 只有發生問題解不掉時, 才會想到我. 而論功行賞, 封官加爵時, 根本忘記我的存在, 鐵定沒我的份.


  成立有戰鬥力的研發團隊, 是很費時費力, 還要靠運氣(產品大賣).但要摧毀它, 只需派個只會打嘴砲的主管, 不出半年, 很快就搞定.


  與其如此, 倒不如自己出任管理階層, 參與高層主管決策, 來爭取預算, 在自己業務範圍內, 營造出良好軟體開發環境, 吸引志同道合的 RD, 將所學 10 幾年的軟體經驗承傳下去, 為公司培養具執行能力的中階幹部, 來擔任士官長的角色. 只要具工程師性格, 有創意跟執行力的中階主管, 越來越多時, 我在公司內部, 才不會到處被視為麻煩製造者.


  若 EeePC 打算要衝出 500 百萬台的大量, 需要成立更多課級單位, 應付現階段出貨需求, 著手開發未來次代機種, 以及研發新軟體技術, 拉高技術競爭門檻, 降低生產成本. 到時候就急需一群能獨立作戰, 充分授權的士官長來貫測執行.


  軟體產業不是比人多, 而是比頭腦好的產業. 派個沒實務經驗的軟體主管, 馬上去大陸找一堆 2, 3 百個軟體人員來成立軟體部門, 沒有 20 幾個中階幹部來有組織規劃, 落實執行, 鐵定是一場災難.


  我原本打算只成立小型團隊, 從 2007 年 7 月時慢慢找, 才找到一些合適人員. 但因接下來 EeePC 的延生機種, 系統客制化, 以及相關軟體的開發, 讓高層一直催促我要儲備更多的軟體人才, 來應付未來的產品規劃.


  要加人可以, 但我要高層先答應, 以後分 Bonus 時, 是要看部門績效, 而不是數人頭. 如果我夠厲害, 其他軟體部門要用 10 個人做的績效, 而我能用 4 個人搞定. 到時就分 7 個人的 quota 給這 4 個人.


  如此公司可省 3 個人事成本, 而有實質貢獻的 RD 可拿到較好薪水, 願意長期待下來, 自我提升技術, 創造更多競爭力. 造成雙贏局面.


  另一方面, 若 EeePC 未來銷售不如預期, 養不起這麼多軟體工程師時, 我還能確保部門內 RD 的薪資能優於其他部門, 不用辭退多餘人力.


  為了引進更多志同道合的夥伴, 極力向高層推薦老戰友 Alex, Alex 在華碩任職期間, 曾做過 WebPAD, PDA, SmartPhone 等案子, 後因政治因素辭職去 BenQ, BenQ 的第一代 MP3 Player, 就是他做起來的. 最後也因政治因素, 鬥不過 BenQ PM 而回鍋華碩. ( 也就是有他這個案例, 我才打消辭職念頭, 繼續龜縮在華碩內, 等待機會 )


  他對 Embedded System 硬體架構/省電功能相當清楚, 我跟他合作過 2 款 WebPAD, 彼此具強烈工程師性格, 在系統功能設計上有相同看法. 而他歸到 EeePC 事業處後, 馬上就抓出一些硬體線路漏電問題, 作為改版及次代機種的改善目標.


  我建構軟體部門的想法是:


  1. 以驅動程式或跟硬體綁在一起的應用程式為主, 向外延伸.

  2. 用軟體手段來求系統穩定, 省電.

  3. 用軟體手段來降低生產成本.

  4. 用軟體來降低硬體設計成本, 並能提供更多的附加功能.

  5. 成立 “軟體 IC” team, 研究 algorithm 搭配既有的硬體設計, 在不增加任何硬體成本下, 用軟體手段提升 EeePC 影音品質.


  越老鳥的 Programmer 越謙虛, 因為越清楚自己的能力底線. 全球 Open Soucrce 高手的功力是遠遠勝過華碩軟體工程師. 要跟他們拼純軟體應用程式開發功力, 無異以卵擊石. 但因公司機密, 無法讓他們取得 EeePC 硬體設計圖及相關 IC 規格. 而這就是華碩軟體工程師能發揮最大價值的所在點:

  幫 Open Soucrce 高手解決硬體相關問題, 提供 Library 讓他們使用. 使他們隨心所欲改機, 修改軟體, 很容易將其他 OS移植到 EeePC.




  雖然 EeePC 事業處另有軟體部門負責 Linux, 而我是負責 Windows, 但我極力爭取在部門內成立 2 個 Linux 開發課.


  為此, 找到網通大廠及 IC 公司的兩位中階軟體幹部, 來負責 Linux 系統穩定度, 驅動程式, 跟工廠生產測試軟體等開發工作.


  工欲善其事, 必先利其器. 為了趕快進入狀況, 花了 1 個多月, 評估 MontaVista 的系統開發工具, 並派 RD 與其合作, 把該套工具從 MontaVista Linux kernel 移植到到 Xandros kernel 上. 有個 source code level, remote debugging 的開發環境, 遠比用 printk deug kernel/driver 方法來的精準快速.


  打算用 Embedded Linux 手機穩定度的水準, 來要求 EeePC Linux 系統穩定度. Linux 上沒有像 MS 在上億台 PC 上執行過的 WHQL/HCT/DTM 系統測試程式. 商用專業軟體工程師跟志工性質工程師做出來的系統測試程式, 兩者在性能,可靠度, 後續維護, 跟技術問題諮詢上, 是有很大差距的.


  而且 MontaVista 有多款 Embedded Linux 手機的成功開發經驗. 雖然花上百萬來買這套開發軟體, 我覺得非常值得. 現在隨便一個沒經驗剛畢業碩士的人事成本, 鐵定比它還貴, 而對案子的幫助鐵定遠遠比不上這套工具.


  如果 EeePC量夠大, 這些 Linux Device Driver RD 也都 tune 上來時. 到時候計畫成立一個 EeePC Linux Device Driver Certification 課, 要上 EeePC Linux 的 device driver 需先經過這個課來驗證. 並同時為 Ubuntu 跟 Google Andriod 的移植來鋪路.


  從 Google 放出 Android 的 source code 後, 我就一直對它念念不忘. 不出 5 年, Google 必定取代 MS, 而且還會比 MS 更恐怖.


  Google 不對 user 收任何費用, 它是向廣告廠商, content provider 收費. 只要 Android 舖的越多, 內建到更多能上網的前端便宜 device(手機, Settop Box, MID, UMPC, PC, NB, Game consle), 提供更好更快速的後端 server 功能及頻寬. 那還有誰想想用手機的視訊, 訂票, 看電視, 查餐廳/停車場等付費數據服務? 更何況還有跟 Google Map 結合的免費地圖導航功能.


  打不過對方, 就加入它, 利用它的力量. 站在巨人的肩膀, 才能看的更遠. 不然就會被巨人一腳踩死. 等量產相關工作都搞定後, 我一定親自下海, 加派人力來做這一塊.


  對工廠軟體下載跟自動化測試軟體的開發, 我非常注重. 軟體不只可以增加附加價值, , 還可以降低生產成本.


  12 月因 EeePC 生產不順, 兩次去上海工廠看問題, 發現有太多改善的空間.負責生產的工廠單位, 以前接過 Apple Mac NB 的代工案, 見識過 Apple 的軟體生產測試工具的效能. 當我提出這個觀念時, 他們極力贊成, 還一直逼問我何時可以導入, 完全不像其他單位的極力抵抗.


  有執行單位主管的全力配合, 這個案子已經成功一半了. 接下來就看我這個部門爭不爭氣, 來兌現支票.


  2008 年大陸頒布的新勞動合同法, 會增加生產成本, 現在一堆台商搬去越南來避開, 那是不是以後遇到相同問題時, 要搬去孟加拉 or 非洲? 而且以後衝量時, 有可能下單到其他代工廠. 如果能將生產相關的軟體技術, 掌握在手裡, 可以避開人力成本跟加快其他代工廠上線速度.


  若每台生產成本因而省下 1 元美金. 200 萬台就可省下 6400 萬台幣. 只要公司撥一半給我這個部門當 Bonus, 大家雖然累, 但是會累的很快樂, 累的很有成就感. 不會累的很幹.


  現請一位主任, 先在台北架起一個工廠軟體下載生產測試的模擬環境, 等把相關軟體開發測試過, 覺得有把握時, 再去大陸工廠實地上線測試.


  PM 規劃下一代 EeePC 時, 決定加入 TouchPanel 功能. 找來廠商來報價, 結果報一個離譜價格, 對方解釋是因需要一顆 USB IC 跟相關觸控軟體程式. XD! 是欺負華碩沒有懂軟體的人, 來亂開價的嗎?


  會後馬上交代一位高工, 叫他把 USB IC 拔掉, 照以前寫 WebPAD 觸控螢幕的驅動程式觀念, 來降低 Touch Panel 成本.


  程式設計俱樂部網站 (www.programmer-club.com)上, 在“用軟體模擬虛擬攝影機的硬體”討論串中, 我就提出類似用軟體模擬來節省硬體成本的觀念. 結果引起某家 IC RD 的對嗆, 說要尊重 IC 公司的智財權等等.


  就是系統廠 PM 沒經驗, 太好騙, 才讓這些公司獲取暴利. 同時也讓 IC 公司的 SW RD 瞧不起系統廠 SW RD 的功力. 在 EeePC 上, 如同在 NB 上用 Video Splendid 取代 Jepico IC 般, 我鐵定盡全力, 用軟體手段, 讓這些公司只能獲取合理報酬. 同時萬一要發動價格仗時, 也讓華碩有更多本錢跟對手硬拼.


  為達到人盡其才, 落實 RD 要幹 RD 的事, 而不變為領高薪的 QT, 我從 QT 部門挑出兩位學士測試工程師, 交由華梵大學畢業的副課長帶領, 讓他們負責 WHQL Test, WinXP image, 在 WinPE/XPE 上撰寫測試程式, 而他們表現完全不輸碩士級工程師. 讓我意外驚喜, 有物超所值的感覺.


  我給他們的任務是, 盡量用軟體手段改善流程, 來應付大量 XP image 製作, 而不是用人海戰術來應付. 薪水分紅將比照碩士工程師水準來調整.


  為了用以往 DVD Recorder/LCD-TV 的開發經驗, 來改善影音品質, 我找了交大應屆畢業資訊工程博士跟另一名寫 3D Game 的學士, 合作開發 "軟體 IC".


  原本給他們的 schedule 是半年將 Video Splendid 1.0 移植到到 EeePC (為了 7 月打考績時能向高層證明), 一年後推出Video Splendid 2.0. 結果花 3 個月他們就移植出來, 並且還寫出第 2 代 的 prototype. 真的是江山代有人出, 讓我突然覺得老了.


  OLPC 的 EC firmware RD 也應邀加入. 為等他把 OLPC EC 處裡完, 我等了 3 個月. 因他有 x86 BIOS, Window Application, 及 EC 的經驗. 只需把他教會 ACPI Driver 跟 device driver 相關技術, 以後我就可以專注規劃從 Window Application/ Device Driver/ ACPI BIOS/EC Firmware 一路打通的架構跟介面, 而由他去操刀執行, 配合 HW RD 的修改線路, 希望能將以往在 Bulverde VC上 學到的省電設計經驗, 落實到 EeePC 上.




  或許有人認為我是在吹牛說大話, 但如同史蒂芬周說過的, "做人如果沒夢想, 跟鹹魚有什麼兩樣...."


  做 RD 就是要有這種 Guts. 做不出來, 頂多浪費 2,3 個月, 大家走回頭路, 繼續當 WinTel 的順民, 乖乖照傳統 NB 的路子走, 但若做出來, 競爭對手想要照抄, 可沒那麼容易抄.


  硬體線路或許可以照抄, 但散落藏在 App/Driver/ACPI BIOS/EC 中的軟體, 可就沒那麼容易抄. 如同威騰可以抄襲聯發科的 DVD ROM server chip, 但無法抄襲其韌體. 於是原封不動將聯發科韌體套到自家的 chip 上, 結果被活逮, 判賠美金 5 千萬元.


  我沒有名校情節, 不會非台清交不用. 我在清交大的學業成績是吊車尾. 因為知道自己程度差, 所以非常用力拼研究所考試.


  在 "我的 DDK 學習經驗”中說只要黑手工程師. 10 年後我還是說同樣的話. 部門只有 2 位是清交畢業的. 我重視的是做事態度, 學習能力以及最重要的績效.


  現在這些同事在加入團隊之初, 我就先說不保證高薪, 也不要以為 EeePC 可以一直熱賣下去. 要有較好的薪水, 就要靠大家努力, 為公司創造利潤.


  為防止保障年薪後, 馬上就在公司內擺爛, 讓主管對他無可奈何的現象. 我是不會採保障最低年薪的手段來聘人.


  鴻海處理這類應徵者是: 你敢拿我就敢給, 要高薪可以, 先達到業績再說, 沒達到就一路打折下去, 從 1 千萬打折到最後只剩 100 萬, 天天逼進度, 讓那些自以為身價非凡的人, 待不滿一年, 沒等到股票, 就主動辭職.


  就有個手機團隊從工研院跳到廣達, 然後跳到鴻海, 結果不到一年就辭職回工研院.


  連我這個大頭目都要親自下海 coding, 不准團隊中存在只會打嘴炮, 不會做事的人. 就算以後幹到管理階層, 也絕對不能放掉技術的本. 自己沒技術能力, 如何去帶領更菜的工程師, 看出部屬的錯誤之處. 又如何能著規格變化來持續改善或推出全新的軟體功能?


  沒有一套軟體功夫能讓你吃一輩子, 除非你壟斷產品的某個研發流程, 建立山頭完全不讓別人進入來取代你. 讓上面的人想動你時, 考慮到陣痛期的成本, 就不敢輕易開刀. 自己的官位跟薪水遠遠凌駕在公司整體利益之上. 大公司一代不如一代, 技術斷層, 山頭林立的現象, 就是這樣造成的.


  也告訴他們, 總經理公開宣示, 在華碩分家後, 會以績效作為分紅主要考量, 大幅拉開 RD 間的待遇差距, 全力留住具競爭力的員工, 並且每年會 fire 不合適的員工, 來促進人才流動.


  若 EeePC 能在 2008 Q2/Q3 繼續站穩腳步, 我鐵定在大陸成立軟體團隊. 現在上 Google 查 device driver 相關的文章, 都出現一大堆量多質精大陸軟體工程師寫的技術文章, 遠遠超過台灣軟體工程師的文章.


  5年前在蘇州成立軟體團隊時, 就感受到大陸工程師在困境中, 力爭上游的精神. 在東北老家, 父母務農一個月才賺人民幣 200 元, 隻身到蘇州, 四個人擠在一間破套房內. 只能靠寫程式才有出頭的一天. 那種拼勁, 置死地而後復生的精神在台灣已不復見.


  當初還沒進華碩, 每月領資策會35 K 的死薪水, 租間在三重貧民區的頂樓房子. 老婆懷孕 8 個月, 夏季時太陽曬在屋頂, 頂樓房子熱的像烤爐, 怕開冷氣花錢, 就只穿條內褲, 吹電風扇, 假日窩在電腦前寫程式賺外快. 幫一家 CNC Controller 廠商寫 Win95 Device Driver, Sample Code, SDK Library, Document, InstallShield 安裝程式. 那時候真的是拼勁十足, 程設功力突飛猛進.


  我想現在大陸還有一大群這種有拼勁, Programming 能力夠水準的軟體工程師. 如果把他們組織起來, 好好訓練, 並給予合適報酬. 只要抓住趨勢, 全力猛攻. 這個團隊的戰鬥力會相當驚人.




  在台灣, 繼前波藍領階級失業潮後, 白領階級也開始失業. 我就常收到失業的美國 40, 50 幾歲華裔軟體經理的履歷. Andrew Grove 在 "Only the Paranoid Survive" 中寫到, "公司沒有天生就欠你一碗飯, 想吃飯就要靠自己去爭取".


  台灣的軟體工程師憑什麼要求高薪? 現在有些工程師是躲在大樹底下好乘涼, 公司大員工多, 可以混水摸魚, 濫竽充數. 但你能躲多久? 等到 40 歲被辭退又找不到工作, 小孩教育費, 全家生活費, 20 年房貸都要錢. 到時候要怎麼辦 ?


  華碩低月薪, 高分紅 ( 不一定高, 要看績效 ) 在業界中是出了名的, 當初兩位有家累, 房貸壓力, 30 好幾歲的高工, 衝著我畫出來的大餅, 甘願減薪加入團隊. 對他們, 我有一份道義責任, 以前幹工程師, 搞砸就只有自己吞苦果, 現在搞砸就有一堆人跟著倒楣.


  分家後, Jerry 定下遊戲條件: EeePC 事業處未達業績標準, 核心主管減薪 40%, 基層工程師不受影響. 相反地, 若超出預訂業績標準, 就以比例來多發分紅. 不久後就要跟他畫押留證據, 免得分紅時候, 空口無憑. 害慘底下這批工程師.


  我寧願用比華碩股票低的公司離職員工. 又套句史蒂芬周的話: "只要有心, 人人都是食神"


  就算台清交畢業的 RD, 一星期就能搞定的案子, 只要有耐力, 有毅力, 有興趣, 若他願意花 2 個月來搞定. ( 況且現在網路上一大堆 open/sample code 可供參考 ) 1個, 2 個, 3 個案子.. 一直做下去, 到最後他的技術能力決不亞於偷懶的台清交碩士.


  我只聽過玩 Online Game 玩到暴斃, 還沒看過寫程式寫到暴斃的案例. 如果部屬寫程式寫出興趣寫到上癮, 就像玩 game 殺終極大魔王般, 我根本不用管, 他自己就把案子做出超過我預期的效果.


  聯發科的開國元老原本在聯電中, 是被當皮球踢來踢去. 宏達電開張第 4 年, 資金燒光, 差點倒閉掉. 華碩在 Intel 放出要做 MB 消息時, 走掉一大批 RD. 在初創階段, 上述公司哪有本錢請素質超好的 RD? ( 華碩現在有兩位協理, 是光武工專跟淡江大學畢業的. ) 但還不是最後被他們搞起, 做到股王.


  我想找的, 就是有理想, 肯學肯拼, 愛寫程式的 programmer. 因自知條件比不上台清交, 所以會謙虛會認命去拼未來. 而不是畢業名校, 待過大公司, 自命身價不凡的 programmer.


  我就是要這種拿穿草鞋的精神, 去跟穿皮鞋的公司拼. 用龍蝦鮑魚做出好菜不稀奇, 用青菜豆腐做得出來才厲害. 只要肯學, 程度不要太差, 我願意花上 1 年, 傳授 coding 經驗, 把他帶上來. 依績效給他對稱的待遇.


  我印象非常深刻的事是, 有記者訪問朱經武博士 ( 超導體先驅學者 ) , 說一星期只有一個晚上能休息, 會不會覺得太累, 結果他回答, 有人肯幫我買數億元的設備, 讓我做我喜歡做的事, 我高興都來不及了, 怎麼會覺得累, 還覺得時間不夠用.


  所以有幾個這種部屬, 我就可以天天到其他部門, 串門泡茶啃瓜子.




  最近看的一本書 "科技頑童沃茲尼克", 感受相當深刻, 心有戚戚焉.


  Worziak 提到他非常喜歡在 HP 當工程師, 而當 HP 成立專案, 派出至少 5 個人以上的團隊, 來研發類似 Apple I/II 的產品時, 一些經理人覺得受到威脅, ( 因 Apple I/II 的軟硬體是 Worziak 獨自開發出來的 ) 完全將他柄除在外, 即使他卑微到只想當個小小印表機介面工程師都不行. ( 當妒才, 不求長進, 壟斷山頭的經理大量冒出時, 就是公司停止成長的徵兆 )


  因 Worziak 做過 Artira 的Ping-Pong ( 乒乓 ) / BreakOut ( 打磚塊 ) 電動遊戲, 將其 TV output, 搖桿, 影音效果的技術, 運用在 Apple II 上. 而他也做過盜打長途電話的藍盒子, 將其音頻技術, 運用在錄音帶來儲存 AppleI/II 程式的技術上. ( 以前做過亂七八糟案子的技術能量, 總有一天, 會在某個產品上整合 )


  又他知道如何用軟體去控制硬體 ( 寫電動遊戲時累積下來的軟體功力 ) , 把原先以純硬體觀念設計, 花 22 顆晶片組成的軟碟控制器, 改成只花 2 顆晶片, 搭配複雜的軟體設計, 在 2 星期內做出安靜超快的軟碟控制器. ( 不要傻傻聽信 IC 廠 Sale 的話, 去買又貴又耗電, 性能又差的 IC, 只要肯動頭腦, 了解基本原理, 軟體的確可以省下許多硬體成本 )


  在設計 AppleII 時, 用最便宜的方法, 支援現有美國電視機輸入頻率, 讓 user 不用花錢另外買 monitor. 而且只用 Apple1 一半的晶片數目, 就做出功能大幅超越 Apple1 的 AppleII. ( 不要花錢裝內建的 3G 網路卡, 利用藍芽連接 3G 手機的能力, 幫 user 省錢, 而不是害 User 多花錢, 讓一堆 IC 公司利用華碩去賺暴利 )


  為了堅持 Apple II 應該有 8 個擴充槽, 與賈伯斯起第一次爭執. 而被豬頭高階主管主導的 Apple III, 則慘遭開放式的 IBM PC屠殺. ( 不要為省 connector 的錢, 而把 EeePC MINI PCI-E/DRAM 擴充槽拔掉 ) .


  現在 Jerry 非常忙, 比周杰倫的牛仔還要忙, 根本沒時間看我的規劃方向, 只要解決掉他覺得 EeePC 不好用的地方, 就不會被他釘到牆壁上. 另一位硬體出身的協理相當 Open mind, 這本書就是他推薦我看的, 還蠻支持我對軟體附加價值的想法.


  最後只要滿足每個 PM 的出貨 schedule, 就不會天天來煩我. 只要部屬有 meet 進度, 我根本不會去管他們要做什麼. 讓他們自由發揮創意, 或者提早下班. 反正最後是看績效, 而不是看你每天待在公司的時間, 來決定升遷.


  績效是很模糊的東西, 做立即影響出貨的 XP image, 跟做花 1,2 年才看得到績效的 Algorithm. 何者孰重 ? 有些人就是運氣好, 撿到輕鬆, 主管誤以為績效高的案子, 而有些笨蛋就是想挑戰 mission impossible.


  又套句史蒂芬周說的話 : "貪官要奸,清官要更奸,不然怎麼去對付那些壞人?"


  當主管的, 要比部下更精, 不然怎麼去打出公平考績.


  在程式設計俱樂部上, 我有注意過一位 Harrison 網友, 他持續 2 個多月問我有關 ACPI Driver 的事, 我叫他去看一些公開資料, 從他問的問題, 越來越接近核心. 我就知道他真的有看這些資料.


  而且他說, BIOS RD 的他想搞 ACPI Driver, 是個人興趣, 不是公司硬逼. 我就是想找這種人來加入團隊. 但因他誤以為, 能進華碩的RD 都是高手, 想繼續練功, 練到更有把握. 所以婉拒我.


  但我告訴各位, 公司一大後, 有高手也有濫竽充數的夾雜其中. 而能撐到最後的, 通常是那些有毅力, 有耐心, 有危機感, 有執行力的人. 只要放在以技術為主, 沒亂搞政治的工作環境中. 他們就會自動自發, 甚至發揮出出乎意料的表現. 也不用管理階層天天在後面逼他們.


  況且我會先給舊版程式的 code, 讓他們 trace 打基礎, 有段緩衝期, 還有老鳥可以問問題, 然後再要求他們開發下一代的新功能. 像我現在, 除了開一堆會, 回一堆 E-MAIL之外, 還有時間寫 code, 上網查技術資料, 就是靠他們自動自發, 讓我省下許多時間.




  因 104 人力網站只能列出簡短描述, 導致我無法細說要求條件, 也無法讓應徵者充分了解我的規劃跟行事風格.


  因不想浪費彼此時間, 若有意應徵的人, 請先評估個人期望待遇與發展方向, 是否能符合我提出的這些條件, 才來投履歷.


  若有興趣的, 請到104 人力銀行, 或華碩人力網上留下聯絡方式. 並註明應徵 EeePC 事業處軟體第五部軟體工程師. 我只管 EeePC 事業處軟體第 5 部, 其他 EeePC 軟體部門不是我管轄.


  我不辦考試, 有意者請拿做過的作品, 來跟我閒聊. 目前我需求的人力有:



  1. 美術設計人員: (1名)

    需會操作 MAYA 等 3D 軟體並轉成 Direct3D 的格式, 會平面設計及網頁撰寫.

    需跟工業設計中心 ( MID ) 合作. 重點在設計 Application 的外表圖案.

    在相關產業有 2 年以上的經驗.


  2. Window 應用程式開發人員: (2名)

    需 MFC 2 年開發經驗, 工作項目初期負責 WinXP Image 製作,

    開發 WinPE上 的工廠測試程式. 及開發次代安裝光碟程式,

    若學習能力強, 不排除日後從事 Windows Device Driver 開發工作.


  3. Windows Display 驅動程式開發人員: (1 名)

    有在 IC 公司從事過 Windows display device driver 開發經驗.

    工作項目: 初期負責充分發揮 EeePC VGA chip 的硬體功能,

    撰寫 VGA Memory/3D Engine 測試程式 on WinPE or XPE.

    後期負責維護/升級 ASUS VGA Display Driver Hooking 技術.(這一塊技術我可以下指導棋)


  4. Windows LAN/WLAN/WiMax 驅動程式開發人員: (1 名)

    有在 IC 公司從事過 Windows WLAN/LAN device driver 開發經驗,

    具 NDIS, WinSocket 等相關技術背景.

    初期負責 EeePC 網路(LAN/WLAN/WiMax) 相關問題並 trace IC 公司提供的

    device driver source code, 撰寫 WLAN/LAN/3G 相關測試程式 on WinPE or XPE.

    後期負責 EeePC Window base 通信標案的相關技術.


  5. Linux LAN/WLAN/WiMax 驅動程式開發人員: (1 名)

    同上, 只把 Window 平台換成 Linux 平台.

  6. Linux Device Driver開發人員: (2 名)
    初期負責 trace and modify Linux device driver open source,

    確保在 EeePC 上的穩定度, 後期撰寫 Device 測試程式.


  7. Linux OpenGL開發人員: (1 名)

    有在 Linux 2.6.0 版以上 開發過 OpenGL 的經驗.


  最後若認為自己有潛力但不符這些條件的人, 也可以拿自己寫的程式碼或產品來跟我談.




  有個副課長說我, 這樣搞法, 恐怕沒幾個人來面試. 但我告訴他, 我就是要這樣惡搞, 找不怕死的人進來. 寧願這陣子, 咬緊牙關先撐住 EeePC WinXP 量產的壓力, 也不要急就章, 找到不合適的人. 若在台灣找不到, 就去大陸找.


  若 2008 年 Q2/Q3 跟 HP/Acer/Apple 對幹後, EeePC 還能在領先群中. 確定 EeePC 事業處有足夠盈餘來養更多軟體工程師時, 軟體第 5 部會擴大營業, 在台灣跟大陸, 再做一次徵才活動.




  工程師性格強烈的我, 因在網路上留言直言不諱. 多年在 BBS, www.23xx.com, www.programmer-club.com 上留下多篇文章, 公司內部早就有人看我不爽, 多次寄這些文章給 HC, Jerry 來背後告狀. 我相信這篇文章, 不久就有人背後告狀, 轉寄給他們. 為了節省他們的麻煩, 我自己經先寄給 HC, Jerry.


  被公司受聘, 只要不涉及公司商業/技術機密, 並不代表就沒個人發言權利. 連 MS 都有個內部員工網站, 可開放給外人觀看, 我常常看到有 MS 員工在裡面幹醮自家公司.


  主管跟部屬下班後, 大家都是普通的老百姓. 沒有誰比誰大.


  我也做好隨時離職的準備, 手上的資金, 讓我 30 年不工作都不成問題. 只要創意/執行力還在, 到其他公司還是可以發展出進階或全新的系統功能. 我也相信還是有其他公司的總經理, 有雅量來容納我這個異類.


  華碩不就是因 4 位創辦人不爽老東家宏碁, 離職後自行開業. 我敢肯定說, 華碩絕不會是最後一家, 因這種原因而成立的成功公司.


  微星老闆就非常有危機意識, 我上經濟部辦的 “ 94 年研發經理養成班”時, 就有 7, 8 個微星員工參加, 公司補貼全部費用, 也不用加班來補上課時間. 而技嘉老闆跑去開寶嘉, 代理標誌汽車. 從這點, 我就斷言微星會贏過技嘉. 當老闆都開始不務正業時, 你還能期望公司會有多好?


  已經脫離 ”為五斗米折腰” 階段, 若是沒人收留我, 那就自己當自己的老闆, 開 Window 驅動程式教學課程. 或當自由職的技術顧問, 日子還是一樣快樂. 未來我可不想像 HC, Jerry 般, 天天開會從早開到晚, 坐飛機全球跑來跑去, 錢夠用就好, 生命中也不是只有寫程式這項樂趣. 等女兒上大學後, 我就不幹了. 要去她的學校唸博士, 反正現在考博士, 只要準備書面報告跟口試就可以.


  最後祝大家都有個滿意工作, 而我希望下次長篇大論時, 就是說退休後要做什麼事.


  看著桌上兩隻 BANDAI MG 版 Hi-Nu/UNICORN, PG 版攻擊剛彈的素組模型, 跟一堆變形金剛: 柯博文, 大黃蜂, 飛輪, 黑魔, 毀滅者, 判官, 密卡登. 哦, 對了還有藏在櫃子裡的 1/350 大和號, X-Wing, Y-Wing, AT-WALKER, 何年何月才能幫他們改裝甲, 黏蝕刻片, 來上色, 做舊化? 雖然網路有人代做模型上色. 但做模型的樂趣, 就是看一片片塑膠片, 在手中慢慢成形, 而且一台比一台做的更細緻更逼真.


  寫到這裡各位大概猜出我的性格, 沒錯, 是宅男型工程師. 我找的部屬, 都是宅男型工程師.在我們這邊, 鐵定沒有鶯鶯燕燕, 讓你分心, 只有超安靜的環境, 讓你專心工作.


全文完...

2008年1月31日 星期四

XD! 科技人也是很迷信的


  這兩天,我因為要解絕某個燙手山芋、大家避之唯恐不及、鬼魅般難解的系統與網路問題,勤跑某金控的機房...到門口如下圖,有沒有察覺什麼不對嗎?



  轉頭看向另一邊,似乎機櫃上有某種降頭壓在上面...



  靠!乖乖病毒已經徹底感染佔據某金控機房!( 噓~~不要說出去是哪一家... )



  滿坑滿谷在機房繁殖的乖乖....





  銀行資訊人員的心聲:『乖,小的我今年能否安心回鄉過年就靠您了。眾資訊系統請慢用,吾等絕不敢怠慢,請高抬貴手。』



  來個乖乖供養系統大神的合照吧。



  等等,這邊是...?



  靠!連空調冷氣機也要吃乖乖啊!是啊,要是大小眼惹得空調大神不爽,空調大神一罷工,可是會連帶牽連資訊系統大神跟著不爽,然後集體罷工...有道理,說得過去。



  離開前看著這滿坑滿谷的乖乖,沒想到以往和同事間的玩笑話竟然在這邊親眼所見血淋淋地上演著,哪天我是否會遇到一個客戶的機房,所有的機櫃外都貼上『勒令禁止當機』道士黃符?我相信在某個角落一定有這樣的機房存在。高科技人士的迷信程度其實並沒有比較低啊...



[ 轉貼 ] 十年一覺程設夢 ( 中 )


前情提要點此


  2007 年四月某晚 8 點多時, 接到 Jerry 秘書的電話, 說要找我一起吃飯. 搭著 Jerry 的 Lexus 460 LS 加長豪華版, 去台北藝術大學吃飯. 席間才得知, 原來 Jonney 交代 Jerry 去執行百元電腦計畫, 但 Jonney 一直對軟體部分放心不下, 要 Jerry特別留意, Jerry 就請 HC 推薦合適的軟體人員來幫他看軟體這一塊.


  雖然 HC 大力推薦, 但 Jerry 擔心我常跟其他軟體部門有磨擦, HC 反問他, 是要找一個會打仗, 攻山頭的人 ( 對啦, 這種人死的最快, 無法享受勝利成果 ), 還是守成, 注重部門和諧圓容的主管 ( 割稻尾最在行, 處世圓融, 見縫插針 ). 幾經思考後, Jerry 最後還是找上我.


  其實在 2007 年 1 月時, Jerry 因底下的 PM 不懂軟體, 就叫我幫他看數位像框的發展機會, 我經過 2 天的技術 survey 後, 建議他取消, 因以其成本, 大可做一台 Thin Client 或 WebPAD. 如果真得要做, 建議 PM 考慮用 VIA C3 CPU + Linux 來開發.


  而邀請 VIA CPU Sale 來開會時, 負責 AMD 百元電腦的 PM 也跑來插花. 後因華碩跟 VIA, AMD 價格談不攏, 最後連百元電腦的案子都停矲. 所幸 Intel 看到 AMD 在 OLPC 上的聲勢, 為防止 AMD 鹹魚翻身, 就跟華碩合作, 進入百元電腦市場, 而使這台小電腦起死回生.


  餐敘後隔天就跟 PM, MID 等相關人員, 一起被關到北投春天酒店. 2 天後趕出百元電腦的UI/軟體功能規格初稿. ( 吃了兩天的生魚片, 真得有點反胃 )


  那時候公司內部並不看好百元電腦的前途, 只好用我們這群從四處徵招來的散兵游勇來執行. 但因這是 Jonney 非常重視的案子, 使 Jerry 認真執行, 一個星期開 3 次會, 常常開到凌晨.


  當時也不知道百元電腦會不會起來, 但與其繼續待在 NB team 被冰凍, 到不如把握這個機會闖一闖. 百元電腦是個人人不看好的案子, 沒有高官想進來插旗佔山頭, 完全沒有歷史包袱. 只有一群笨蛋, 傻傻的做. 有點像在公司內部創業的感覺, 如同 VGA 部門剛成立時一樣, 大家只想把東西做好. Just Do It! 而不會去想些有的沒的, 非技術性的事情.


  出關後, 上網查一下 Intel 對百元電腦的策略, 結果發現另一個消息, 原來 Intel 老早把 Xscale CPU 賣給 MARVEL, 全力專攻 X86 CPU 的省電技術, 並在以色列海法分部進行該專案.


  雖然那時 HC 知道我想換部門, 叫我去幫他看車用電腦這一塊, 但他底下也有山頭問題, 犯不著跟那些人玩政治. 而且我覺得跟隨 Intel 腳步比較有搞頭, 如同宏達電跟隨微軟般. 新興的產品, 有大公司在背後推, 才有機會成功.


  所以就接受 Jerry 的邀約, 加入百元電腦團隊. 忙了 1 個月多月後, 在 2007 年台北電腦國際展上, Jonney 拿出這一部百元電腦亮相, 並正式命名為 Eee PC.


  EeePC 會不會是曇花一現, 或是乘勢崛起, 我不曉得. 但我個人相信, 在 UMPC/MID 這塊領域能存活下來而且能獲利的, 必定是強調系統整合功能的公司, 絕對不是只相想靠低價成本搶單的公司.


  我非常佩服宏達電, 死死跟著 MS 的 Window Mobile 平台. 跟到第 4 年時, 公司差點倒閉. 因而引進王雪紅的資金. 但等到 WinCE 3.0 夠穩定, 能拿出來賣時, 宏達電是第一家有量產能力的公司. 同時它也聘請許多軟體工程師來做系統整合.


  當宏達電推自有品牌時, 一堆分析師看衰. 但因系統整合難度高, 其他手機代工公司是看的到, 吃不著. 後來連原先解約的電信公司, 迫於市場現實壓力, 也回頭找它代工, 甚至直接貼牌.


  我是天生反骨, 在 WinTel 體制下討生活討了 10 年, 因為了解所以不滿, 對其架構, 越看越不順眼. 在我眼中, EeePC 應是屬消費性電子產品, 但又需具有 PC 般的擴充能力. 能執行現有 Linux/Windows 龐大的 X86 base 軟體, 讓 User 可以自行添加自己慣用的軟體. 而不會像 PDA, 手機般, 被綁得死死.


  若按照傳統 NB 的觀念來設計, 鐵定無法持續穩住目前的地位. 競爭對手只要猛攻低價化, 體積小的罩門, 很快就追上來.


  現階段 EeePC 競爭對手, 都是以硬體成本來挑戰 EeePC . 談硬體成本 ( CPU, Panel, Battery ) 的功力, Acer, HP, Dell 會輸華碩嗎? 談垂直整合生產製造, 鴻海會輸華碩嗎? 更何況還有 Apple 神秘的 iBook.


  等 2008 年 Q2/Q3 這些重量級廠商的類似產品陸續出籠後, 必定是一場大廝殺. 策略不對, 研發能力不強化的話, EeePC 鐵定被痛宰! 或許現在一些的好消息, 讓華碩一些人飄飄然, 我可是蠻憂心, 挫著等.


  若 EeePC 朝更輕更薄, 更穩定, 更省電, 更快速開關機, 影音品質更好, 螢幕更大, 操作介面更人性化, 而且能控制住價格. 或許能產生許多差異性系統功能來持續吸引 USER 的眼光.


  其中系統穩定/省電功能/影音品質/人機操作介面, 軟體都可以幫的上忙.


  當然, 打嘴砲想當官性格的我, 一定會考慮到:

  沒人逼你做, 卻笨到自己主動挖個洞, 往下跳. 給自己找麻煩.

  做出來, 沒人感激你, 反而還惹毛一些人.

  做不出來, 別人逮到機會落井下石, 說你是大嘴巴, 愛吹牛.

  若乖乖按照現有 NB 業界的安全方法來做, 跟大家都一樣.

  老闆拿不出對照組來評估, 當然滿意你的績效.


  如同銀行的資訊長愛用 IBM 的軟體, 如果出問題, 他可說國際級銀行都用 IBM, 拿其他銀行來當擋箭牌. 採用一家名不經傳, 可以省 200 萬成本的本土資訊廠商方案, 萬一出錯, 讓銀行賠上幾千萬時, 鐵定被迫辭職或降級. 老狐狸的資訊長當然打安全牌.


  但工程師性格的我會想:

  如果在相同硬體成本下, 能用軟體充分發揮整所有硬體功能, 創造出更多附加價值, 而且軟體成本是在人事上, 賣 1 萬台跟賣 100 萬台, 是相同的成本. 當 CPU/VGA 硬體能力成長時, 軟體功能也隨之成長, 而且是以加速度來成長.


  另一方面, 軟體也可用來壓低硬體成本. PS3 因用軟體搞定 PS2 相容問題, 而省下 PS2 Chip 的成本. 那 EeePC 可不可以如法泡製? 若有 5 成把握, 我就放手一搏. 只要一台省下 1 塊美金硬體成本, 賣 300 萬台 就省下台幣 9000 萬, 若失敗, 只是多花 2 個人月的成本, 這個算盤實在是太划算!


  而這些觀念也獲得一名協理的支持, 幫忙我跟 BIOS/HW 部門溝通. 要是我出面的話, 根本沒人鳥我.


  這位協理, 以前華碩還小時, 我就跟他有過幾次合作經驗. 這次被關到北投春天酒店, 他 review 某個卡了1 個多月的軟體問題時, 我馬上提出解法. 2 個小時後, RD 回報已經解掉問題, 給他留深刻下印象. 後來在正式成立 EeePC 事業處之時, 他在 Jerry 面前也幫了我不少忙.




  一些 PM 開規格時, 因沒有深厚的技術背景, 為打安全牌, 常常就是:

  1. 照抄大廠 (DELL, HP, Acer) 的規格

  2. 照收 WinTel 的 roadmap.

  3. 照收 component/software 廠商的 solution.


  例如每家都配訊連的 PowerDVD, 在 UI 上打上公司 LOGO 來自欺欺人這種做法只能做到消極防禦, 無法積極攻擊競爭對手. 搞到最後, 大家功能都一模一樣, 只爽到訊連.


  而 Microsoft 在 MCE 2005 上推的 SideShow, 其起因是 PortPlayer 的 MP3 chip 被 Apple 取消用在 iPod上, 而改用 Samsung 的. 為了活下去, 它就跑去向 Microsoft 努力推銷 SideShow 觀念.


  SideShow 說穿了, 就是把 PortPlayer 的 MP3 Player ( 成本 US $50 ) 黏在 NB 背板上, 讓 NB 同時有 X86 CPU 跟 ARM CPU. 當 X86 CPU 關掉時, 可用 ARM CPU 的 SideShow 功能來看 picture, 聽 MP3, 和看 e-mail 通知.


  有沒有搞錯 ? 隨身攜帶的手機都可以做這些事. 一般 User 根本不需要這種華而無用的功能, 而且 SideShow 一直開著會耗掉 NB 電源. 在 NB 上加 SideShow, 獲利者是 PortPlayer, 而倒楣的是 NB 廠.


  在 EeePC 會議上, PM 計畫導入某家 PCI-E 3G 無線網卡, 內建在 EeePC. 同時要求軟體團隊來協助. 有沒有搞錯? 應該是這家公司要從頭包到尾, 自行負責, 它如果做不來, 還有其他家的方案. 哪有動用內部資源去幫外面公司賺錢的道理. PM 到底是領 EeePC 部門的薪水, 還是外面公司的薪水?


  在會議上我就開砲, 認為最重要的是, 趕快推出內建 BlueTooth, 跟能輕鬆與各家 3G 手機連線的軟體. 不必為 3G 上網的功能, 還要讓 USER 負擔 3,4 千元去買額外的 USB/PCI-E 3G 硬體. 況且用 3G 手機, 可馬上解決:

  1. 全球各國 Field Test 的問題

  2. 高速移動時的連線品質.

  3. 讓 3G 手機的電池去負擔天線/3G Chip 的電源, 不用耗掉 EeePC 的電力.


  便宜, 好用 又省電. 對 EeePC 價格, 軟體團隊, 及 User, 是三贏的局面.


  就是這種雞婆個性, 常常撈過界, 挑戰別人的專業, 無意間就得罪別人. 但我覺得, 工作除了賺錢, 還要有理想, 外帶對自我技術的提升, 看看自己的底限為何. 如果自己多花些時間, 從使用者的角度, 來改善產品品質, 幫 user 省錢. 而不是已交差了事的心態來做事. 當參與開發的產品能大賣時, 多分些 Bonus, 能獲得工程師最好的工作滿足感跟合理報酬


  Jerry 看到 EeePC 大受歡迎, 衝到 Amazone 網站最受歡迎 NB 的第一名時, 決定把這堆妾身未明的散兵游勇組織起來, 成為正規軍. 於是成立EeePC 事業處, 地位跟規模將與 NB/MB/手機事業處平起平坐.


未完待續...

2008年1月27日 星期日

[ 轉貼 ] 十年一覺程設夢 ( 上 )


  一向充斥垃圾的 BBS 的 Programming 版,難得出現一篇不錯的文章。看完後才發現這原來是華碩 ( ASUS ) EeePC RD 主管的一篇徵才文,但因為寫得實在用心良苦,就將他收錄至此。


  但是因為篇幅實在太長,我重新排版成合適 HTML 顯示的 Layout 後,會拆成分上中下三篇貼出。這篇文章,真正能激發熱血的宅男工程師,讓我們體會到宅字的真諦:


  宅,因為專注!宅,因為無人能及的執行力!宅,因為無與倫比的熱情與信念!宅,因為萬代的鋼彈模型!


  總之華碩急徵宅男,不夠宅者勿入!





發信人: weber1217.bbs@bbs.cis.nctu.edu.tw (weber), 看板: Language

標 題: 十年一覺程設夢

發信站: 交大資科_BBS (Mon Jan 14 00:42:42 2008)

轉信站: SimFarm!zoonews.ee.ntu!news.kkcity.com.tw!ctu-peer!news.nctu!csnews.cs


  十年一覺程設夢


  本文可視為“我的 DDK 學習經驗”的續篇, 不談軟體技術, 而是寫我在華碩 10 年的職場經驗. 描述學會了 DDK 這套工具, 我是如何運用它, 在工作上落實創意, 供各位參考. 另外我的為官經驗, 可說是失敗中的失敗, 各位可引以為鑑.


  我在華碩的第一位老闆是 HC, 我日後對軟體價值的想法, 受到他的影響極深.


  他以前在宏碁是 Jonney 的助理, 參與天龍中文終端機開發計畫. 當時工作, 是用宏碁自行開發的 ASIC, 搭配 firmware 來處理中文顯示.


  這份工作累積的經驗, 讓他日後有能力自己開一家 VGA Chip IC 公司. 而也使他成為在華碩中最了解軟體價值的董事.


  他在華碩第一份工作, 是從無到有成立 VGA 部門. 當時 3D VGA Chip 霸主是加拿大 ATi , PM 大主管屬意這家公司, 預計與其全面合作. 但 HC從 Chip 架構及規格, 反而看好另一家風中殘燭的 nVidia. 那時候 nVidia 找過麗台跟其他家 VGA 卡廠商, 都吃閉門羹, 沒人想理它.


  部門內成立 3 條產品線, 分別使用 ATi , nVidia, S3 公司的晶片.


  當時與其他部門最大的不同處是, VGA 部門 RD 是以軟3: 硬1的分配. 成為公司部門中, 擁有人數最多, 水準最整齊, 都是台清交碩士畢業的軟體人員. 連我跟他面試時, 還被他嫌在資策會待太久, 怕染上不好習性.


  HC 的個性是, 技術不願受制於人. 他逼 nVidia 吐出所有的 VGA source code, 命令底下一組軟體工程師來做效能最佳化的工作. 我分配到的工作是, 做安裝光碟程式, 及用 X86 組合語言來加速 VGA Driver執行效能 ( 因當時有許多 2D/3D 指令是用 CPU 先處裡過, 然後再傳給 VGA 晶片處裡 ).


  因解掉 1 個 nVidia 驅動程式的 Bug, 使華碩 V3000 繪圖卡領先其他對手, 早 1 個月出貨, 打響公司在 3D VGA 市場的名號. 因為這一點貢獻, 經 HC 推薦, 而獲得 Jonney 額外的獎勵獎金.


  VGA 部門在所有同仁努力下, 不到 2 年時間內, 就擠下原先在台灣第一名的麗台.




  因在驅動程式這個領域的耕耘, 我獲得在資策會時, 做夢也不敢夢到的高額報酬, 有感於當時 ( 1997 年 ) BBS, 雜誌文章皆是財團法人, 學術界人士, 學生的論調, 鮮少來自工業界的聲音. 而且是一面倒向 MIS, 資料庫. 於是在 BBS 上寫篇 " 我的DDK學習經驗 " 文章, 鼓勵其他軟體從業人員, 朝驅動程式發展, 而不是只押寶在 MIS, 資料庫. 當時在 BBS 上引起支持 RAD Tool, MIS, VooDoo 學生的筆戰, 搞到連 HC 去交大演講招募工程師時, 現場都有學生嗆聲點名, 說要找我單挑. 回來後問我是不是覺得時間太閒, 沒事做. ( XD! 現在是 nVidia 還是 VooDoo 活下來 ? MIS 公司還是 IC 公司錢賺的多 ? )


  事隔 3 年後, 在台灣微軟 WinCE 技術研討會上, 有一名微軟工程師趨前自我介紹.


  他原本是在交大擔任助理, 看過該文後, 放棄原有安穩待遇的工作, 自願降薪一半, 投身驅動程式開發領域. 我相信, 經過 MS SmartPhone, SoC 的興起, 聯發科, 宏達電躍昇為股王後, 他現在應居要職領高薪, 遠比當交大助理, 來得更有成就感.


  HC 深信公版公 Driver, 絕對無法支撐起產品競爭力. 於是在不增加任何硬體成本下, 極力要求我們要用軟體來增加附加功能. 而我們也不負他所望, 連續推出 3D Glass, Game OSD, 3D See Through, Time-Shift, Smart Doctor, OverLock 等特殊軟體功能, 讓 Sales 在報章雜誌上, 有材料來連連為華碩繪圖卡創造話題.


  在不到 5 年內, 他成立的 VGA 部門, 成為世界第一品牌的VGA 卡公司. 而以往稱霸的外國 VGA 卡公司, Diamond 跟 Elsa 公司, 一個倒閉, 一個縮編.


  當 Win95 問世, 引發一波 MB 大換潮, 得以讓華碩連續蟬聯 3 年股王 ( 但套句台語, 搖擺沒落魄的久, 10 年內, 股價從 800 多元變成現在的 80 幾元 )


  而 MB 也需要搭配 Win95 驅動程式的安裝光碟出貨, MB 的主管 Jerry 向他要求軟體人力協助. 他就派我去成立 MB 軟體支援課. 我雖然心中不願, 但卻也不得不捨下喜歡的 VGA 驅動程式工作.


  當時的 MB 部門是以 EE 及 BIOS RD 為主導. 軟體支援課形同雞肋般, 扮演的角色, 僅比 QT 部門高一點而已. 工作內容僅是製作安裝光碟, 檢查驅動程式的穩定度. 不過因 MB 種類日益頻繁, 使這份工作變成繁瑣的制式工作. 也讓我心中不時思考, XD! 自己是 RD 還是高級 QT ?


  然而繁瑣工作還是要做, 最後受不了, 我模仿 Win95 Plug and Play 的 driver 安裝機制, 寫出半自動安裝程式, 將公司所有的 Chipset, Audio, Lan 等等 driver 全部放在一張光碟. 當放進光碟機時, 安裝程式自動啟動來偵測 MB 上所有 Device 的 PID/VID, 挑出正確的 driver 供使用者安裝.


  這套方法, 不僅讓這個軟體支援課逃出繁種無聊的工作, 也大大減少 PM 的安裝光碟庫存壓力. 不用一種 MB 就要準備一張光碟, 而是 Intel, SiS, VIA 晶片組系列的 MB, 各一張安裝光碟.


  而我就利用這多出來的工作時間, 私下做一些自己感興趣的題目. 因沒影響到 MB 出貨, 所以 MB PM Joe 跟 Jerry , 根本都不曉得我私下在搞什麼東西.




  有鑑於 Win95 後, MS 宣稱要停止支援 DOS. 我就將 DOS 版的 MB BIOS Flash 程式, 改寫成 Win 版的 WinFlash. 大概撈過界, 惹毛負責 DOS 版 Flash 程式的 RD, 而讓 BIOS Team 不願導入. 完成的 WinFlash 只好靜靜躺在硬碟中.


  過了半年, 當時公司為康柏 ( Compaq, 現被 HP 併購 ) 製作一款無軟碟機, 安裝 WinNT 的 PC. 原先的 DOS Flash 程式無法在其上使用. ( NT 上無法在 DOS 模式下去存取硬體, 也沒有軟碟可以 bootup DOS ).康柏限期要提供解決方法, 藉由康柏施加在 PM 的壓力, 讓這套塵封的 WinFlash 程式, 得以應用到產品上, 在市面流傳.


  而另一家 MB 公司微星, 在我完成 WinFlash 的 2 年後, 也做出做法不同但相同功能的程式, 並在雜誌上大打能在 Win 上作 BIOS flash 的廣告. 看見其他公司的重視程度, 想起自家公司的態度, 真覺得 MB 軟體部門只是個打雜部門, 絲毫不受重視.


  完成 WinFlash 後, 當時 WWW 網路剛興起不久, 洞悉到網路潛力, 我跟部屬合作開發 Asus LiveUpdate, 利用網路, 在 Win95 下來自動更新驅動程式跟 BIOS. 由於 Asus LiveUpdate 是由 Client 跟 Server 兩部分程式組成的. Client 端的檢查, 下載機制完成後, 尚須要後端 Server 的配合, 才能啟動. 但初期 MIS 部門根本無配合意願, 最後透過 HC 的影響力, 總算幫 VGA 部門 架設更新網站. 經過 3 年後, 微軟把類似概念的線上更新功能, 直接內建到 Win 2000. 而現在華碩官方軟體下載網頁, 及 MB/NB/VGA/EeePC 的安裝光碟上, 都存在著這套軟體.


  同一時期 Intel 在 MB 上推出 Health Monitor 的功能, 用來偵測 CPU 溫度, 風扇轉速, 及機殼入侵. 同時推銷網管軟體 LDCM ( Lan DeskTop Configuration Management ) 給公司來 bundle 在 intel 系列主機板上. 而 maintain LDCM 的工作就落到我頭上.


  因 LDCM 既有的 InstallShield 安裝程式, 需事先提供硬體設定檔, 註明 MB 有幾顆風扇, CPU 溫度範圍等資料. 我的天啊 ! 若每一片 MB 都要這樣搞, 那我豈不是被 LDCM 搞死?

  於是修改既有的 InstallShield 程式, 讓它能掛上 device driver. 在安裝過程去偵測有多少顆風扇, CPU 現在溫度, 然後動態產生硬體設定檔, 餵給後面的 LDCM 設定程式去正確執行安裝.


  後來上 LDCM 訓練課程時, 聽到 Intel 人員提到 Acer 一個軟體部門, 正在進行於 LDSM Client-Server 架構下, 從 Server 端把 BIOS / Application / Driver 安裝到 client 端. 於是自己獨力將 WinFlash 修改成 LDCM 能使用的 PLUG-IN module, 提供 MIS 人員直接在 Server 端更新 Client 端 BIOS 的功能.


  因為 Intel 限制 LDCM 只能用在 Intel chipset 系列的 MB 上. HC 叫我想辦法, 在 SiS / VIA Chipset MB 上提供相同功能的軟體. 於是就開發 PC Probe 這套軟體, 但也發現讓問題越來越複雜. 3 家晶片組公司 ( Intel, VIA, SiS ) 有各自不同的介面 / 地址去讀取 Health Monitor, 甚至同家不同系列的晶片組也有所不同, 有用 SMB Bus, 也有用 I2C Bus 的. 而 Health Monitor IC 來源, 也有 3 家 IC 公司提供. 產生一堆晶片組加 Monitor IC 的不同組合.


  做第一片 MB 時, 還覺得有趣. 但做到第 10 片 MB 時, 就覺得又煩又無聊. 所以一直在想, 有沒有一勞永逸的解決方法.




  當初是 1999 年, Win2000 beta 版還在測試, WDM DDK beta 版首度出現在 Win98 ME 上, ACPI BIOS 1.0 spec 也剛出爐.


  看完 ACPI Spec 後, 加上幾年的 Window Programming 經驗, 我察覺到 MS 想利用此一規格, 迫使各硬體系統廠商必須提供 ACPI BIOS, 來讓 Windows OS 能直接控制硬體. 並且把 BIOS 角色壓縮成 Boot Loader. 一但 OS 啟動後, 讓 BIOS 沒有主控權, 以避免 BIOS 影響 OS 運作. ( MS 夠邪惡, 但很明顯並未得逞, 直到現在, 在 Vista 上, programmer 還是可以用 device driver 下 SMI 指令, 讓BIOS 取得控制權 )


  看過 ACPI BIOS 規格跟 WDM DDK beta 版後, 我終於找到處理 Health Monitor IC Access 跟 BIOS Flash 的一勞永逸方法. 讓所有硬體存取相關的動作, 全部集中在 BIOS 的 ACPI ASL code 中, 由應用程式透過 ACPI driver 來讓 ACPI.SYS 執行對應的 ASL ocde. 如此就不用三天兩頭為 SMBus I/O port來改device driver.


  於是一頭栽進去, 偷偷在 Win98 ME 平台上開發 Asus ACPI Driver. 同樣的, 因為有把該做的工作完成, HC 檢查進度時, 沒發覺異樣, 所以才不會對我碎碎唸, 說做這個東西有什麼用.


  但是 ACPI Driver 需要 ACPI ASL code 配合才能啟動. 自知惹毛過 MB BIOS Team, 他們是不會幫忙的. 求人不如求己. 於是找剛成立的 NB BIOS RD 部門, 向其要了 Lotus NB 的 BIOS 原始碼, 自己邊看 ACPI BIOS Spec, 邊在 Lotus 上修改 ACPI ASL code.


  當花了 3 個月時間, 寫出 Asus ACPI Driver 跟對應的 ASL Code 時. 因深知此技術的發展潛力, 便主動開技術介紹會, 邀請 NB/MB BIOS RD 來參加. 但會議結束後, 沒有一個 BIOS RD 感到興趣.


  但我並不灰心, 因 Win2000 WHQL Logo program 規定 BIOS 一定要支援 ACPI. 我知道總有一天, Asus ACPI Driver 會派上用場. 只不過卻沒料到, 這 " 總有一天 ", 卻是在 3 年後才來到.




  2002 年, 公司 的 NB 種類增多. 原先 NB BIOS RD 是直接 program VGA, 在各家 VGA Chip 的 Frame Buffer 上畫 OSD ( On Screen Display ), 但多種不同的繁瑣 VGA Frame Buffer 定址, 讓 NB BIOS 主管 Jason 受不了, 因他有聽過我的 ACPI 技術介紹會, 於是私下請我幫忙解決.


  我當時也沒多想, 本著同公司就應互相幫助, 將 Asus ACPI Driver 原始碼提供出來, 做投影片, 並教 NB 軟體工程師如何移植到 NB 平台. HC 常跟我說, 我是做事的人, 但卻不是做官的料, 有股 RD 的技術狂熱, 卻不懂職場的遊戲規則. 但我毫不在意, 老是把他的話當耳邊風. 但這次無私的 ACPI 技術提供, 不僅沒有獲得任何回饋, ( NB 部門可沒因此而多發薪水股票給我 ). 反而種下 4 年後不愉快的起因.


  雖然那時是在做 MB 的事, 但還是會關心 VGA team 的發展. 把 MB 上學到的 Health Monitor 跟動態超降頻的概念, 介紹給 HC. 在大家一遍喊 VGA 超頻的時候, 逆勢提出降頻觀念. 我認為做文書處理或上網時, VGA 根本不需要啟動 3D Engine 跟拉高頻率. 於是在 VGA 上實作出 Smart Doctor 軟體, 依據 VGA/CPU 實際工作負荷, 來動態超降頻, 以避免 VGA 長期處於高熱超頻狀況, 降低正常使用期限.


  事隔 1 年半後, nVidia 公司受到其他 VGA 卡製造商的壓力, 將這項功能, 直接內建在 Driver 中. 可惜當初沒人告訴我要申請專利. 不過雖然如此, 這套動態超降頻功能, 已經領先其他對手早 1 年半.


  當 VGA 部門闖出名號後, HC 為了尋求下一波成長動力. 將目光擺在當時熱門的 IA 題材: Setop Box 跟 PDA 上. 但因 VGA 軟體人力不足, 想將軟體人力從 MB 部門抽回來, 於是詢問我的意願.


  但他同時也點出, MB 軟體支援課雖然工作無趣繁瑣, 但會影響 MB 出貨, 公司不能沒有這個課, 而且未來將會隨 MB 產能大幅成長變成一個大部門. 但我二話不說, 自廢武功, 自動解散 MB 軟體支援課. 將底下的台清資訊碩士, 從無趣工作中解放出來, 投入 Embedded System 研發專案中. 我也不再想當管理階層, 跟 PM review 進度跟開會, 我覺得是浪費生命.




  在 2002 年時, 掀起一股 IA 熱潮. " PC 已死, IA 當道 ". Embedded System, 如 WinCE 3.0, Embedded Linux, VxWork 紛紛跳上檯面. 我被分派去做以 Embedded Linux 為主 的 Setop Box 跟 Thin Client.


  當時曾接觸過 Luxsonor IC 公司, 原想用其 IC 在 Setop Box 上. Luxsonor 的華裔羅副總, 因意識到 PC 運算能力提升, 以硬體為主的 MPEG2 decoder 將倍受威脅, 後因理念不合, 於是自立門戶, 成立 InterVideo (IVI) DVD 播放軟體公司. 而 Luxsonor 在將 MEPG2 decoder IP 授權給聯發科後, 被 Cirrus Logic 併購.


  因 IA 口號正熱, 一些軟體工程師很容易從傳產股金主募得資金, 在國內外, 小型 Embedded Linux 公司如雨後春筍, 陸續冒出. 連 Mr. Taiwan 谷月涵, 也插花當網虎國際的執行長, 來搞股票上市上櫃. 就可知道這些公司分名是擺明想 A 錢, 用股票換鈔票.( XD! 我打電話給網虎 Sale 問些事情, 結果隔天他就發新聞稿, 說華碩即將採用網虎的 embedded linux )


  在 Setop Box 上的 Embedded Linux 上執行的 Browser 功能很陽春, 涵蓋 PC NetScape/IE 的功能不到 30%, 而他們又無法克服 TV resoultion 及 interlacing 問題. 最後淪落為無實用性的玩具. 我也因而勸阻 HC 入股某家美國 Embedded Linux公司的念頭.


  Settop box 做半年後收起來, 改做 Web Pad, 一共用 Transmata TM5400, NS GEODE, VIA C3 3 家 CPU 來開發原型機.


  開發Transmata TM5400 WebPAD 時, 我負責 BIOS 與負責硬體的同事 Alex, 僅僅兩人完成該 Prototype. 當時我們好像是在搞家庭代工, 什麼事都自己來, 我邊下 BIOS 命令, 他就用 LA 去抓硬體訊號. 那陣子, 雖然壓力大, 但也學到 Phoneix NoteBook BIOS 架構, 並得知更多 Window 與 BIOS 溝通介面.


  當時觸控面板的介面 IC 並無支援傳統 PS2 介面, 於是我寫個 Win98 驅動程式, 用南橋晶片空出來的 GPIO pin 去接收介面 IC 的輸出資料, 透過驅動程式將其轉化成 PS2 Mouse Event, 去模擬出一個 PS2 Mouse Driver. 這是我第一次用軟體驅動程式模擬出特定硬體介面的經驗.


  5 年前的 SoC 剛萌芽, 硬體省電能力很弱, LCD-TV, 跟 LCD Panel 價格昂貴. 原型機完成後, 因暸解成本昂貴, 功能有限. 我向 HC 建議, 不要導入市場. ( 有夠呆吧! 如果煽動成功, 讓老闆投錢投人, 起碼可以撈到個副理官位來做, 至於賺不錢, 那是他家的事, 反正有其他賺錢的部門在養, 怕什麼! )


  結果同時期有兩家公司, 大眾電腦跟旺? 做出 WebPAD 商品, 想也知道, 都賠賠賠, 成了 3 賠產品.


  IA 熱潮的泡沫, 不到 2 年就消失. 但 PDA 因有 Palm 及 WinCE PDA 的銷售成長, 得以繼續生存下來.




  HC 意識到趨勢變化, 停止 Steop Box, WebPad 開發, 將所有軟體人力投入 PDA 開發. 於是我被指派去做 Intel Bulverde VC ( Validated Customer ) 計畫.


  Bulverde 是顆 SoC, 非 CPU. 它將 ARM base CPU, VGA, Peripheral, Memory Controller 全部塞到 1 顆 Chip 中. VC 計畫是, 在 Intel 提供的 pre-alpha SoC 板子上, 架上 MS WinCE 3.0 OS, 寫程式去測試功能.


  當時是利用 ICE, 透過 JTAG 介面來 program SoC, 使 SoC 發出預期的控制訊號, 接著用 LA 去量訊號, 檢查是否正確. 然後每星期回報 Bug 給 Intel 做除錯之用. 簡言之, 就是寫程式幫 Intel 作 SoC 硬體功能驗證測試.


  在參與過 Setop Box, Thin Client, 及 Bulverde VC 計畫, 讓我無意中充實對 IC 規格和硬體設計方面的知識, 有時候當下看是不相干的工作經驗, 往往是日後技術提升的基石. 經歷這時期實作經驗, 對日後軟體設計, 有極大幫助. 但因部門政治因素, 外加 VGA 軟體主管離職. 不得不放下喜歡的 Bulverde VC 計畫, 再度聽從 HC 的安排, 轉任 VGA 軟體主管.


  HC 一直想為 VGA 部門尋找另一波成長動力. 於是指派我去執行 DVD Recorder 及 LCD-TV 專案.


  初接任 VGA 軟體副理一職時, 一位負責維護 Display Driver Hooking 機制的 RD, 提出可以將 Video 結合 3D Game 的點子時, 我贊同他的想法, 並加碼加派一位 RD 去做 MPEG4 壓縮跟網路即時通訊功能來配合. 做出全球首套支援 3D Game 的視訊軟體. Sale 部門看到這套軟體後, 取名為 Game Face 來大力促銷. 隨後因 HC 想在大陸成立一個軟體團隊, 我暫時放下 LCD-TV 案子, 前往蘇州, 武漢, 西安等地的大學去招募員工. ( 有人跑大連, 哈爾濱的路線, 11 月, 還好不是我 ) 因老婆不願舉家遷移到大陸, 在蘇州華鼎成立團隊雛型後就返台.


  在 LCD-TV / DVD Recorder 這些專案中, 我陸續接觸到 WIS, LSI, TI OMAP, Sigma Design, Trident, OPlus, Genesis, PixelWork, Morning Star 等各家的晶片. 這段期間大量接觸各類的 IC 公司, 也讀了一堆相關的 IC spec and datasheet, 我試著去比較各家晶片性能. 遇到不懂的規格名詞時, 就上 Google, 翻 paper, 從基礎理論去了解其規格背後的含義. 而墊下對消費性電子 IC 方面的知識.


  因為國外 IC Design 公司的規格書寫得非常詳細, 我從中接觸到MPEG 2/4, H.264, Scaler, DE-INTERLACE, 視訊規格, 以及色彩學等方面的知識.


  記得當時 Trident 代理商的某個 FAE 很臭屁, 欺負我沒摸過 LCD-TV Chip, 還說 LCD-TV Chip 很有深度, 技術很難懂, 要像他這樣的人才才能搞懂. 結果事後 K 過 paper 跟 Video Demystified後, 才知道他誇口的那些知識, 根本是入門級.


  做這些案子期間, 我觀察到一些 IC 公司只專注在硬體開發, 如 LSI, TI. 而其 IC 所需的 DSP firmware 或 embedded system 卻要系統廠商, 花錢向其他家軟體公司購買, 相關的 Video/Audio codec 授權問題, 也是由系統廠各自向 MPEG2/Dobly 談判. 對玩慣 WinTel 的我為此深感不解. 為何無法提供一套完整的方案, 卻還要系統廠到處張羅硬體,軟體,權利金等事項?


  相同時期, 隨著 SoC 蓬勃發展, 聯發科洞悉到系統廠的需求, 招募眾多軟體工程師, 搭配自家晶片, 提供完整的 solution, 在不到 4 年時間, DVD Recorder 方面就打敗 LSI, 手機晶片方面, 則是嚴重威脅到 TI. 逼得 TI 也出 Davanci SDK for WinCE. 如果 TI 還不親自提供完整 TurnKey Solution, 中低階, 甚至高階手機晶片, 被聯發科攻陷是指日可待.




  在 2000 年, 華碩獲利大幅衰退, Jonney 意識到主機板高毛利時代, 已經一去不返, 連精英都嚴重威脅到華碩 ( 股價 130 : 70 ), 一堆 VGA 部門的軟體工程師, 集體跳槽到精英.


  Jonney 開始推動巨獅計畫. 進行公司組織重整後, VGA 部門被劃給 Jerry. 我因而失去重視軟體功能 HC 的支持, 我曾經因案子無預警被中斷, 當面對著 HC 拍桌子, 但他心胸寬大有雅量, 沒把這件事放在心上, 日後反而常常在暗中拉我一把.


  直屬長官變成 VGA 部門的硬體經理. LCD-TV 專案也被迫停擺, 由 Jerry 新成立的數位家電部門來主導. 而底下的一些軟體工程師看苗頭不對, 全部跳去負責 VGA 卡的軟體單位.


  但上帝關起門時, 同時也為你開了另一扇窗. 2004 年時 MS 推出 Media Center, 並且全球數位電視陸續開播. 雖然處於冰凍狀態, 算是苦中尋樂吧, 花時間 K 數位電視訊號規格, 去了解 RF, IF, BF, demodulator,及 OFDM 編碼的原理. 從這些規格跟通訊編碼原理中, 找到屬於技術人員的樂趣. ( 數位電視訊號規格有牽涉到視訊壓縮, 因有看過 MPEG2/H.264 資料, 所以蠻快就進入狀況. 有燒香就有保佑, 有讀書就有收穫 )


  不久後, Jerry 對 Barebone 部門報以高度的期許, 於是我轉移陣地, 設立一個軟體團隊來支援 Barebone 部門, 雖然還掛在 VGA 部門, 但 VGA 部門最高主管早就不理我, 考績被打得很爛.


  在 BareBone 部門初期幫忙接 Samsung 的代工案及自有品牌 E-Spreso. 但後期 Barebone PM 部門換主管後, 無意朝創新發展, 以衝產量為優先. 也不管軟體功能, 把底下的工程師當工具來使用.


  為了不讓底下的軟體工程師閒閒沒事幹. 加上看到 MB/NB 朝消費性電子化的發展趨勢, 同時也知道 LCD Panel 的色彩缺陷性. 我不想浪費在 LCD-TV 專案上獲得的一些研究經驗, 於是開案子, 將 LCD-TV 色彩處理功能導入到 VGA/NB 上.


  初期我將這個概念跟專利草稿給另一家 IC 設計的子公司參考, 希望能共同開發. 但後來子公司毫無分享意願. 認清現實一面後, 靠人不如靠己, 我分配 2 名 RD, 成立 Cameleon ( 變色龍 ) 專案,從事 NB 上的色彩功能開發, 並將此觀念介紹給某位 NB 高級 PM.


  因為這位高階 PM 是工程師出身, 有過 TV CRT 的相關開發經驗, 知道此功能的實用性. 雖然NB 內部有阻力存在, 但他仍盡力協助我在 NB 部門內介紹這項功能.


  幸運的是, 當時 Toshiba 推出強調色澤鮮艷的 Qosmio NoteBook, 該 NB 加裝 1 顆我以前摸過的 Trident LCD-TV Chip, 用來處理色彩運算. 而公司代工的另一家日系公司也想要有類似功能. 要求 NB team 評估用日本 Jepico 影像處理 IC 在其代工 NB 上的可能性.


  就在日系公司派出技術科長來台灣, 討論代工 NB 的技術相關問題時. IC 子公司透過高層主管安排, 向其 demo 他們開發的色彩軟體功能. 而我是幸好有該 PM 的私下安排, 向日本科長展示 Cameleon.


  雖然IC 子公司想透過高層主管的政治影響力, 來左右日系公司的選擇. 但在看過 IC 子公司, Cameleon, 及 Jepico 3 種解決方案後, 基於擴充性, 效能, 及價格的考量. 日系公司決定採用 Cameleon, 並派出其 TV 部門技師, 提供調校色彩參數, 來配合 Cameleon 使用, 正式導入在日本銷售的 NB 上.


  因為日系公司採用, 形成強而有力的背書, 原先反對的人都默不出聲, 順利消除 NB 部門內部阻力, Sales 部門將 Cameleon 改名為 Video Splendid, 如同 Asus ACPI Driver 般, 成為公司 NB 的基本功能.


  由於 Jerry 所轄的 VGA/Barebone 部門主管, 無意朝創新發展, 只優先衝產量. 外加看到 XBox 360/ PS 3 研發售價消息不斷冒出, 以及 LCD-TV 低價化. 魔獸爭霸也放出消息要移植到 Xbox 360 上時, 我判斷高階 VGA 卡, DMA 及客廳式 PC, 絕對不是 Xbox 360 / PS 3 的對手.


  試問當一台 Blue-Ray BD, 40 GB HDD, WLAN 801g 無線上網, 3 顆 CPU 的 PS3 只賣台幣 1 萬 4 千時, 還會有多少人去買 1 張 1 萬多元的高階 VGA 卡 ?


  MS 跟 Sony 可以賣一台虧一台, 以後靠 content service 跟 game license 來獲利. 但 Dell, HP, Acer, Asus 有可能虧錢賣 PC/NB/VGA 嗎 ?


  NB 市場的 VGA 方案都是內建, VGA 卡公司是看的到吃不著. 同時 NB 長力道已經逐步趕上 Desktop 時. 看不出有其它位來發展機會, 於是離開 VGA 部門, 轉調到以系統為主的 NB 部門.




  公司一變大, 一些事情再也不是以技術優劣來考量. 原先以為在 NB Team 可以開發第 2 代的 ACPI Driver 及 Video Splenedid, 尤其是 ACPI BIOS 已經出到 3.0B 版, 而 ASUS ACPI Driver 還停留在 7 年前的 ACPI BIOS 1.0 時.


  但這些想法都被 NB 軟體大主管拒絕. 有次討論工廠測試流程時, 還跟我解釋 ACPI Driver 的功能. 當時心想, 他還以為 ACPI Driver 真的是他手下自行開發出來的.


  在不被重用, 近乎被冷凍的狀況下. 又開始自己找事做, 看到大部分人用 NB 時, 通常是用 Mouse 居多, 而 TouchPad 就白白浪費在那邊. 加上當時 iPod的觸控螢幕功能造成熱門話題. 所以交代部下去搞個將 TouchPad 當 Touch Panel 用的程式並申請專利.


  結果搞出來後, PM 對其興趣缺缺. 但卻沒料到,過 1 年半後, 在 2008 年 CES show 展上, NB Sales 把這個 TouchPad 功能當成一個賣點.


  因從 2004 WinHEC 資料得知, 微軟即將力推 MCE 2005 跟 Vista Premium (code name Diamond), 會拉升 NB 對 TV 功能需求. 又看到大陸工資成長的趨勢, 及公司內部如火如荼的 LSS 精實運動. 我想到用軟體自動化來做工廠檢測.


  當時 NB工廠大多依賴人工作檢測, 無法有精確的量化數據. 在 6 Sigma 的 DMCIA 步驟中, 需有 M (Measurement) 步驟提供量化數據, 以統計手法分析, 作為方案效果評估, 來找出引起品質差異化的關鍵.


  假想若能提供每月數十萬台的 NB 測試量化數據來加以分析, 又能加速測試流程, 減少作業員需求量. 對公司的硬體設計, 供應商的電子元件良率控制, 應當有所幫助.


  於是實際到工廠待一個下午, 發現作業員真辛苦, 因為工廠沒能力去寫測試程式, 為了測試 TV, Camera, Audio 的功能, 須操作繁複設定的商用應用程式 ( IVI Home Theate, Cyberlink Power Cinema, 3D Mark 2003), 以人眼人耳去判斷, 而長期沿用 DOS/Assembly 的單工觀念, 將刺是測試幾個小站, 一站一站去測, 絲毫沒利用到目前 CPU/Windows 的多工能力, 也無法執行驅動程式來測試 device 功能. 而在測試聲音時, NB 啦叭跟機具運轉的噪音, 此起彼落, 真是個惡劣工作環境.


  於是回來後寫個快速測試 TV/camera 的程式, 交給部屬, 由他修改介面, 依工廠需求, 協助導入 Digital/Analog TV 軟體檢測, 因 MCE 2005/Vista Premium 的 NB 產量持續成長, 對 TV 的檢測需求, 大幅成長. 這套方便的 TV/Camera 檢測程式很快就正式導入 NB 生產線, 頗受作業員的歡迎.


  受到順利導入的鼓舞, 我計畫接下來開發 Audio, WLAN, BlueTooth 等檢測功能. 再度請出 Google 大神, 上網查聲音相關的論文跟原理文章, 最後使用麻省理工學院的快速複利葉轉換程式庫( MIT FFTW), 以及參考普林斯頓聲音研究室 ( Princeton Sound Lab ) 的公開原始碼, 在 DirectSound 上寫一個可同時測錄放音功能的快速聲頻檢測程式, 來檢測 NB 聲音輸出入 的 Channel Balance, Frequency Response, Total Harmonic Distortion, Back Ground Noise Level 品質. 為了確保聲音檢測的正確性, 我拿商用音頻測試軟體 SpectraLab 來比對.


  但是要導入時, 又發生政治因素, 讓快速音頻檢測程式無法上線. 軟體主管單位擺明, 要導入的話, 就把原始碼全部公開給他們, 並提供訓練課程. 不然的話, 就別想導入.


  大概因接 2 連 3 惹毛其他軟體部門, 造成 NB 新主管在管理上的困擾. 最後他丟個 PC Camera 的案子給我做. 並告訴我只准做這個案子, 不要再亂想或亂碰其他案子, 免得跟其他部門起衝突. 好吧, 反正不是第一次, 我再度發揮苦中尋樂精神, 自我尋找技術人員的樂趣.


  於是跟幾家 Camera USB IC 公司接洽, 初期因剛接觸 PC Camera 領域, 對相關技術不懂. 於是把 PC Camera 整個軟硬體架構拆解掉, 從 Lens, CMOS sensor, 步進馬達, USB IC, UVC/WDM Capture driver, KsProxy, DirectShow 等硬韌軟體功能, 從頭到尾走過一次.


  知道影像清晰度跟色彩對 camera 非常重要, 就花時間做快速 Auto Focus, 因嫌 USB IC 的清晰度判斷能力太爛, 自己寫 MTF base 清晰判斷程式來取代. 並上網去讀 Glass/Plastic Len 鍍膜對色彩的影響, 以及 CCD vs CMOS sensor 的色彩處理物理特性的優略點分析.


  甚至到最後, 覺得 CMOS sensor 的硬體色彩處理功能 (3x3 matrix process), 還是無法真正解決色偏問題, 還找到 Nikkon 的色彩處理晶片專利文章, 來了解 Nikkon 單眼相機對色偏的解法.


  在看過 Micron CMOS Sensor 2020 的 datasheet 及 USB UVC Spec 後, 花了 2, 3 個月, 去修改 USB IC 8051 firmware, 利用 UVC Extension 介面從 Windows App 關掉 USB IC 的功能, 直接去 program CMOS sensor. 才發覺原來一開始被 USB IC 公司的 sales 給呼攏了.


  原來 USB IC 公司把 Micron 2020 優異的硬體功能關掉, 只開自家 IC 的影像處理功能. 而 Sales 宣稱其因 IC 具有特殊的附加功能, 如 AWB, Scaling, Sharpness detection 等, 所以要賣得比較貴.


  但單純從運算速度來看, USB IC 的 8051 根本比不上 Micron 2020 的 68H11. 而這些功能可以被 CMOS sensor, VGA Scaling 及 Window App 所取代, 而且效果遠遠超過它.


  因 PC Camera 硬體設計進度一直拖延, 要做不做的. 一直等也不是辦法. 為了證明自己不是只會放砲愛吹牛, 寫虛擬攝影機驅動程式, 用 UVC Extension 介面去控制步進馬達, 做出快速自動對焦. ( 1.2 秒, 可以更快, 但受限於馬達步進機構精密度的缺陷 )


  將擷取到的畫面導入 VGA Vertex/Pixel Shader, 去做 face detection. 同時研讀微軟北京軟體學院的電子白板相關論文. 想將電子白板的功能導入虛擬攝影機驅動程式. 但最後還是看出主管並無心去推動這個案子.


  經過 WinFlash, Asus ACPI Driver, Video Splendid 的推動經驗後, 我已經對由內部推動創新的方法絕望, 都要靠外部的市場壓力, 來彌平內部阻力, 一些被 PM/RD 主管輕視的軟體功能才能出頭.


  這時興起辭職去其他系統廠發展的想法. 但就如同電影 " 東方不敗 " 中所說 :

  "江湖在哪裡? 有人的地方就有江湖 !"


  其他系統廠也會存在相同狀況, 如果沒有總經理級的支持, 到時候鐵定也是被排擠的份. 在華碩起碼還有 HC 知道我是會做事的人. 還好過沒多久, 果真 HC 就暗中幫了我一把.


=== 未完待續 ===

Google+ Badge