Spirit的異想世界

　　昨天和公司的高層(含最高層，我是裡面最菜的)開會，因為目前專案的進度可以說是delay了非常非常之久，我進到這個專案時，這專案就已經是delay的狀態了(據說已經跑了快2年)，所以我要說明為什麼開發時程會這麼長的理由，以及剩下的功能能在什麼時候完成。說起來有趣，我會和目前公司結緣，是參加了北科ezScrum團隊每個月舉辦的C. C. Agile。進公司快半年，雖然PM認為團隊開始進入狀況，我也認為團隊氣氛變好，但我不敢說我貢獻了什麼？我只盡力保住由團隊成員估時程的機會，而不是上面說了一個時程然後就是那樣；再來就是讓團隊成員有更多機會學更多東西，試著讓整體的開發速度變快；在code review時，盡量提供意見及分享自己寫的程式。雖然我試著東加一些西加一些，但其餘的agile practice，我目前還幫不上忙，因為這不是一個agile team。

　　其實是不是agile team我並沒有這麼在意，因為我自己本身沒有任何流派(unified proecess、scrum或waterfall之類)的信仰，只是我印象中曾經看過一句話，scrum master應該是保護羊群的牧羊犬，我還在努力中。不過，下個禮拜五，我還是(很無奈地)得交出一份類似計畫書的東西，上面會有一個時程：剩下12個功能(長期目標)完成的時程，而且是根據某個公式算出來的(現在電腦不只會選土豆，還會算時程)，這讓我想起之前看過一篇吃蘋果的文章，如果開發軟體能像吃蘋果那樣，每個人速度都差不多(事實上也不可能一樣)，那或許我調整一下公式裡的參數，多留一點buffer，團隊就會很高興，但那對團隊的進步沒什麼幫助，我之所以想保住讓團隊估時程的機會，是希望當團隊進步後，不斷地修正短期目標的時程，當短期目標不斷地減少，離最後的目標也就不遠了(好啦~其實我是想偷偷把scrum塞進團隊裡)。

　　昨天的會議，直屬主管、架構師和處長都幫團隊近況說了不少好話，不過，有些決定還是定下來了，包含今天我宣導的一件事(暫且就稱作是A吧)，沒想到剛宣導完，就引起一點不小的抱怨(我自己也...)，但離開公司前，我還是做了A才回家(以身作則)。結果，晚上收信，看到一封過去某人做A做了一陣子覺得A很好的信，那封信就像是傳教士在宣導『信耶穌得永生』。我認為A不是壞事，但就跟讀書方法一樣，某個人B很會念書考試成績很好，但B的讀書方法不見得適用於另外一人C，也許可以好心讓C試試看B的讀書方法，但不該是強迫C用B的讀書方法，因為有時候反而會有反效果。事實上，我自己的讀書方法是自己求學過程中一路摸索出來的，如果真要說，我的讀書方法肯定不適合很多人，因為我幾乎上課都不太聽課(我連自己指導教授的課有時候都會打瞌睡了)，也不太作筆記，完全是依照自己的步調在念書。

　　早上等待server啟動(因為某些原因今天無法用JRebel，但根據JRebel過去的統計，今天光是等待server重新啟動應該有0.5~1+小時)的時候，看到Ben Jai的網誌文章，可能是受指導教授的影響，我自己帶團隊的風格其實也就是無為而治，在成員碰牆時給些提示，有時候自己也不知道問題在哪裡時，和成員一起討論找出問題，剩下的，讓每個成員找出最適合自己的方法，就這樣。我自己雖然不怎麼加班(如果會議不安排在下午五點或五點半之後，那會更好)，進度也算跟得上自己估的時程，但我的開發方式也不見得適合其他人，我也不會要別人用我的開發方法。我只能說，制度和僵化有時候只有一線之隔。

　　就在昨天開完會後，聽到一個消息，今天早上又問了一下，說不定，下一次的C. C. Agile會讓我有新的緣分也說不定。今天還看到一個消息，可惜，Comic Surfer還沒產品化就看到這消息(我還有很多構想說)，真是可惜...

　　今天中午把其中一個功能給完成了，那個功能當初用IBM的公式計算需要24人時的時間，差不多就是三天多到四天(人一天工作是不可能滿8小時的)，不過我自己的time log顯示，2天搞定了，主要是因為這功能在我比較不熟的前台只有查詢，沒有任何編輯的動作，相對簡單很多，而本來就比較熟悉的後台在前開發一個功能時，留了很多可以重複使用的東西，所以省下一些時間可以拿來準備課程的投影片。下午開始忙下一個功能，老實說這個功能是我估算最麻煩的一個，因為它橫跨了好幾個畫面和動作，更有趣的是，幾乎所有的功能都有規格書，唯獨這個功能沒有，因為PM也不知道要怎麼做？

　　說來慚愧，和現在Comic Surfer Core的98%涵蓋率(Statement & branch coverage)相比，進公司到現在，我目前在寫的程式，搭配有單元測試的不多，主要有幾個原因，第一是Comic Surfer共121個測試案例，全部執行完畢平均不到2秒，這是讓我寫單元測試的動力，當一個測試要跑超過10秒，除非是超大系統的整合測試，我實在不想跑，也就自然不想寫了，現在光是一個小小的converter要測試，都要靠Spring framework注入一堆web services，10秒能啟動完整的環境就算是幸運了，即使那個method的測試案例可能不到0.1秒，但整體來說一個測試案例要跑10秒，啟動環境的時間是執行測試時間的100倍？光想就覺得煩...

　　幾天前一位同事被指派了一個任務，幫新進業務上機算機概論課程，我當時想還好我不用去當講師，結果高興不到一天，我就收到信了，因為一個人要上八節課實在太多了，所以我也被安排去分攤其中三堂課，什麼！我上禮拜五的planning meeting和另外一位同事已經跟大PM拍胸脯保證1/25會完成這個sprint的所有功能，時間是我跟另外一位同事估量後我們自己壓的，不是大PM壓的，但這已經是抓很緊的case了，手頭上還有1x張JIRA單要解，這突然其然的授課，勢必又要壓縮我的開發時間。

　　自從有了AJAX技術開始，越來越多網站都使用AJAX技術開發，好像沒用Asynchronous (或是event-driven)的方式寫程式就很落伍了，就連最新的WinRT API都加了一大堆Asynchronous API，但我常常看到一堆網站，在點下某個按鈕後，整個畫面變成灰色的，然後有個輪子轉啊轉的，轉個半天什麼事也不能做，這其實跟傳統的Synchronous網頁沒什麼差別啊！只差在有個輪子轉啊轉，讓使用者誤以為server還在(其實早就死了)，比較好的方式應該是只Block需要同步的部分，不需要同步的部分應該還是要讓使用者操作吧！GMail在load信件時會把整個頁面block住嗎？不會吧！不然不就失去Asynchronous的好處了嗎？

　　最近在修改Comic Surfer的Preferences模組，由於需要大量的字串(String)和各種形態(Integer, Double, Color, etc.)之間的轉換，寫著寫著，有個地方一直有問題，後來發現了一個有趣的地方，所以放了一段程式碼，裡面有10個問題，請猜猜看每題的Type應該是Integer還是Double？(點圖會放大，請別先偷看答案XD)

     

　　這又是一篇源自於學長在其『搞笑談軟工』部落格上的關於Design for testability問題，同樣這也引起網友的討論，但總覺得偏向於『對測試程式的修改』或是『使用第三方套件存取私有變數』，而不是修改程式讓程式變好測(Design for testability)，所以就野人獻曝，提供一個我覺得比較合適的解法。問題中的WidgetFactoryV2類別同時肩負了Simple Factory和Singleton的責任，前者負責針對Windows平台和Motif平台提供不同的factory instance；後者則讓factory在一個JVM只有一個instance。這樣的設計會讓測試不好測試，就如同問題中提到的，但事實上，這問題和Singleton是無關的，更貼切地說應該是『如何測試由平台引起的Simple Factory』，所以我將WidgetFactoryV2改成如圖1的SimpleWidgetFactory，只負責平台相依的問題，Singleton不再是它的責任，此外，我也將『平台』的資訊從程式內部直接呼叫System.getProperty()的方式，換成從參數傳入，如此一來，針對SimpleWidgetFactory就變得很容易測，如圖2所示。

　　今天的內容源自於一個學長於Facebook上問的問題：『你的軟體即將於這個sprint結束之後就要準備送給測試部門進行測試，但是軟體還有幾十個open issues (bugs)還沒解完，而其中大部份的issues都只有某一位programmer可解。請問假設你是Scrum Master，你將如何處置？』這問題一出，引來許多人的討論，也有人開玩笑地說在解決完issue後要把那一位唯一能解的programmer開除，因為他程式寫得不好，所以別人才看不懂無法解決問題，真的是這樣嗎？有時候程式看不懂，並不是因為程式寫得不好，而是領域差太遠。如果整個專案都在同一個領域中，大家都是該領域的programmer，還出現這樣的情形，或許那位programmer真的要稍微檢討一下，但如果一個跨領域的專案，而且跨得很遠，如果沒有另外一個領域的知識，寫程式都很難寫了，更別說要解bug了。

　　前言

　　北市府與Google對於Android Market的七日鑑賞期之戰，到目前還沒有結束，反倒是Apple果斷地回覆草草結束戰役讓我頗為意外。但如果認真想，App Store對Apple來說，重要的收益是透過App Store吸引顧客，然後賣出更多iPhone，而不是軟體利潤的分紅(雖然為數眾多的軟體，其三成分紅可能不少)，即便App Store上的所有軟體都是免費，只要iPhone大賣，Apple就是賺錢，所以真要得罪，手機顧客是不能得罪的，軟體開發者就稍為抱歉一點了，畢竟App Store提供的是一個平台，這個平台可以提供曝光機會，但如何賺錢可不是這個平台要負責的事情(當然，Apple會否認我的說法XD)。會有這樣思考的轉變，跟看完《免費！切開零定價的獲利秘密》這本書有關，我不敢說這本書上說的趨勢是對的，我想沒有人能夠真的預言未來，但就親身經歷來說，現在真的身處在一個資訊免費的世代，於是一個可能潛在軟體工程師(迷之音：『潛在』是指也可能不當軟體工程師嗎？)，有些有趣的心得。

　　最近寫paper寫煩了，就會拿起書翻一翻，加上先前幫忙鄭老師的Scrum推廣課程時，一邊聽課程一邊我的腦中也冒出一堆問題，所以我找上《Agile Software Development with Scrum》這本書，還沒看完整本書，不過，這本書確實解決了我腦中的一些問題，但也冒出一些新問題XD，由於這本書被當成睡前時看的書，有時候還會想這些問題想到沒睡好，看到現在，印象最深刻的卻是3.3.5節Working Environment一節中的一段：

　　在開始公布2010年台北科大資訊工程系OOP實習課優秀作品前，先來一段關於版權的聲明(現在網路上發表文章也得保護自己一下)：以下遊戲畫面裡的圖片版權皆屬原創作公司所有，學生只是利用截圖的方式取得圖片，作為練習物件導向程式設計(Object-Oriented Programming)的素材，作品並不提供下載，以保障原創作公司的權利。今年一共有73位學生修這門物件導向程式設計實習，分成40組，可以說是有史以來最多學生修課的一年(累死老師跟包含我的二位助教)，以Normal distribution來說，優秀作品的數量當然也比往年多一點，因此選出我心目中的前10名與4名佳作，選擇條件包含：遊戲的完整程度、操作流程度、畫面精緻程度、程式的品質以及趣味性。今年入選的作品都是二人一組的作品，雖然看不見萬夫莫敵的一人英雄作品，但也表示團隊合作讓成品更加完美。接著馬上來看Top 10的作品：

Top 1 - Dokaoni (37.5 MB)

　　在IGS展示的作品，程式寫得相當簡潔，卻能有豐富的遊戲性，玩法是躲過怪獸並抓回逃走的小雞，路上的道具可以有其他效果，關卡及障礙物的多樣性，提供了相當好的趣味性，操作也相當流暢明快，從遊戲的開始到結束，再返回開始畫面，如此一個完整的流程都有細膩的處理，畫面走趣味的pixel風，整體來說是今年的最佳作品，在IGS展出也獲得不錯的評價。

 

Top 2 - BombMan (36.0 MB)

　　炸彈超人雖然是相當有歷史的遊戲，但隨著網路遊戲的風潮，如此的小遊戲又開始讓越來越多人喜歡，此組不但有你死我活的傳統玩法，還加入了佔地模式(類似用大戰玩圍棋)，看誰佔的地多，另外還有奪寶模式，節奏明快，畫面也相當精緻，道具豐富提高了趣味性，程式寫的也還不錯，是我推薦的IGS展出作品之一，可惜無緣能在IGS展出，整體來說十分優秀。

 

Top 3 - Mariball (25.1 MB)

　　在IGS展出的第二部作品，遊戲不但使用老師的Game Framework開發，還使用了Third party的物理引擎(Box2D)，這對程式的品質是一大挑戰，要結合多個library其實是相當困難的，但這組作品結合的相當不錯，在遊戲中提供了風、重力、彈力、滾、跳等物理現象，畫面的精緻度也夠，可惜操作的流暢度上可以再加強，讓遊戲性能提高，但也是相當優秀的作品。

  

　　話說今天的目標是把被我擱置四天(端午節都在弄海報)的軟體生命週期管理作業給弄完，但很怪的是，我電腦裡的RTC Client就是不聽話，無法改Work item就算了，還不能開，怎麼心情就很不爽，打開NB，神奇的事情發生了，NB上的RTC Client就沒事，重灌過桌機上的Client，一開始好好的，吃完飯重開Client又掛了，而且Workspace總是錯的，非常火大。後來忘記什麼原因了，想動Jazz Server的設定，順便把翻得很爛的繁體中文語言套件移除，這一移除完了，所有Project area、Team area和使用者帳號都掛了，連預設的ADMIN帳號都不能用，不會吧！我們已經跑了一個Sprint，準備進入下一個Sprint，而且明天就要Demo，這時候Server掛掉真是欲哭無淚，只好重新架Server和重建資料(怎麼覺得最近常做這種蠢事)，下午四點，Server資料重建完畢，可是日期一看就知道有問題XD，麻煩的是，同樣的步驟，現在Jazz Server無法用Windows Services的方式啟動，晚上九點半，終於把投影片弄完，這一折騰真是累人...

　　今天一位在資訊發展史上絕對有一席之位(這一席是好位子還是壞位子讓後人去評斷吧)的人退休了，沒錯，之前他還調侃自己拍了部短片，就是比爾蓋茲，在今天辭去在微軟的任何職務，專心在慈善基金會的運作上，他的成功或是與另外一位絕對也有一席之外的Steve Jobs的競爭都讓人津津樂道，當然，有人肯定他，也自然有人討厭他，而且討厭他的人恐怕也不少，討厭他的理由千奇百怪，但我覺得最主要的原因應該和人有種奇怪的情感有關，就是同情弱勢，當微軟吃掉大半的市場時，開始有人出來反抗，我不去爭論這些，畢竟自己曾經也是反M$一族，但當自己念了資訊相關科系，未來可能也是苦命工程師時，對於很多事情也有了不同的想法。

　　先前某個節目邀請Steve Jobs與比爾蓋茲同台接受訪問，主持人希望兩位給對方良性的評語，Steve Jobs所說的其中一項是，微軟開創了第一家成功的純軟體公司(目前微軟已經不是純軟體公司了)，當時軟體根本不受重視，只是硬體的附庸產品，當時的IBM也是抱著這種心態讓微軟慢慢長大，最後反而失去資訊產業的領導地位，我個人也認為，這也許真的是他的一項成就，至少在他之前，沒人敢開一家純軟體公司，即使他的對手Apple也不是純軟體公司。

　　我個人認為另外一項成就大概就是Windows了，這項成就很多人一定有異議，但如果沒有Windows，軟體發展的速度恐怕不會這麼快，此話怎說呢？Windows也許漏洞百出(其實任何一套作業系統都有漏洞)，但他提供一個比當時UNIX系統需求更低，容易上手的作業系統(Linux系統需求更低，但老實說非常不好上手，帶有濃濃的工程師臭味)，此外，由於他的高佔有率，和向下相容特性，讓軟體開發者可以只開發一套系統就能滿足大多數客戶的環境，這點EA的老闆就有感而發的說：遊戲產業至今，有許多平台，不管是Sony的PlayStation、M$的XBox或是一般電腦，但就是沒有一個單一的開發平台。這對任何軟體產業都同等重要，想像一下，如果市面上現在作業系統有十來套，各擁有一定數量的市占率，軟體公司為了不放棄任何一個市場，只好把同樣一套軟體假設A，開發成十來套不同的版本，A for Windows、A for Sun UNIX、A for IBM UNIX、A for RedHat Linux...，那需要多少的成本維護這麼多種版本呢？

　　當然，現在的情況是Windows吃掉很大的市場，軟體廠商只需要開發一種版本或是針對次小的市場再開發一個版本即可，這簡化了開發的麻煩，不過這讓市場失去活性，但簡化開發時的問題是一個事實！先前BlueRay打敗HD-DVD成為新一代藍光DVD的標準，對消費者到底是好事還是壞事現在也還沒有定論，過去DVD有+R和-R等混亂的標準時，似乎也沒甚麼影響，如果把Windows視為BlueRay，也許是一種特殊的觀點來看這問題了，本來標準這種東西，就是贏者通吃，不然有誰記得錄影帶也曾是兩大規格大戰下後贏者的天下呢？反之，我比較樂見的，應該是一個標準制定，不同OS在同一標準下開發出各具特色的OS，軟體廠商只需要在標準上開發軟體就能在符合標準的各式OS上執行，那軟體會發展得更快更好！

　　總之，在比爾蓋茲退休的日子，祝福他退休的生活愉快，也提出我對他個人一個不一樣的看法。

　　下午問書怡要不要禮拜五吃個飯，其實是要幫她過生日，一開始還蠻順利的，不過最後在價錢上露餡了，她希望找別太貴的地方吃飯，我一個沒注意就回答她有分母別擔心，這一講馬上就讓她知道我們想幫他過生日，於是本來都已經約好的晚餐就取消了，可見，她真的不愛過生日。

　　原本想一口氣把電腦圖學的作業五寫完，不過從下載老師的skeleton到睡覺前，我啥也沒完成，幾個詭異的錯誤就花去我不少時間，而所有錯誤的來源都是FreeImage這個Library，只要不使用FreeImage就沒有錯，一但用了就error一大堆，好吧！請教Google神看看有沒有人遇到這種問題，用錯誤訊息搜尋一下，似乎沒甚麼人出現這問題，只有一位網友提出同樣的錯誤訊息，不過沒有人回覆他，但我意識到可能的原因是新版的Visual Studio和FreeImage不相容，那...那我去下載Source code重新編譯看看好了，編譯完後看到lib檔就有點嚇到了，41.xMB！？我編譯錯組態了嗎？這麼大的lib怎麼上傳啊？弄到凌晨快一點，決定放棄了，明天再去請教老師吧...

前天老師突然決定視窗程式設計要用C#，
ㄟ...之前討論的時候選項不是C++ or Java嗎？
好吧！
既然老師連教科書都選好了，
那就用C#吧，
當初老師要我跟政文自己挑要當哪門課的助教，
最後會選大學部的視窗程式設計，
是想說順便利用這個機會學習MFC或是其他語言的視窗程式設計，
經由老師這一決定，
MFC得由我自己摸索了，
不過還是可以學到新玩意C# Forms，

說到C#，
上學期初印的C#電子書依舊還躺在我的書架上，
只看了前兩章，
因為老師的一句話：你要花點時間把那本書弄熟，畢竟學弟們會問問題...
好吧！衝了~Hello C#
好久沒這麼認真了，
沒想到一個下午就把一整本書給K完了，

嗯...對大多數的人和剛開始的我來說，
C#根本是Java的微軟版本，
不過看完書後，
我覺得不完全是啦！
只能說：
C#在語法上跟Java一樣都是抄襲至C/C++...微軟稱這語言為C#不是沒道理的，
C#可以在任何有.Net Framework的作業系統上執行，
和Java不同的是，
JVM幾乎在各大型的作業系統上都有，
但.Net Framework...抱歉只有微軟一家有提供完整的版本，
Linux上幾乎沒人想理會微軟，
只有一個momo...

實際寫了幾個小程式後，
覺得C#還不錯玩，
改天把老師那本教科書上的範例全部拿來玩玩，
玩完就算是K完了，
視窗程式的概念大多已經有了，
只差在不同語言有些不同的實作方式。

一個下午就能夠K完C#，
也許哪天再花一個下午K完VB.Net...

嗯~在自我放逐了一天後，
還是得面對該面對的事情：WiMAX開發環境教導會議，
如果我是子計畫的PM應該也會不想聽吧！
特別是我把時間選在明天...呵~應該很多人都知道明天是啥日子，

在試了六七次後，
我終於把Fedora Core 6、Eclipse、CDT和CppUnit之間的完美關係找到，
剩下的就是Makefile的問題了，
根據之前自己和學生寫OOP作業時的經驗，
Makefile會是一個令人討厭的東西，
所以在搜尋了好幾個網站後，
終於找到方法可以設定CDT，
自動根據程式的結構產生出Makefile，
哈~這可是難得的經驗，
下次再當OOP助教時這可是教材之一，
讓他們用CDT建置專案，
少了麻煩也省去重複編譯的時間，

正當狂喜之時，
卻也發現事情總是有一好沒兩好，
CDT能產生的Makefile是很好，
但是...他只允許一個專案裡只能有main入口...
這讓我傷腦筋了，
畢竟多個子計劃在開發，
一定會希望自己能夠測試程式或執行什麼東西之類的，
如果一個專案裡只能有一個main那就太糟糕了，
當發現這點時，
糟糕~已經下午五點了...

好吧！
我想子計畫該面對Makefile也是遲早的事，
還是讓他們自己寫Makefile吧！

晚上開始弄Guide文件，
抓圖、打字、找文章...弄到凌晨兩點，
我不行了，
睡覺去吧！
剩下的Coding Standard下次再跟他們約定...

原先的安排是寫journal paper，
不過臨危受命下...犧牲睡眠、燃燒自我~
開始安裝第n次的Fedora 6...忘記幾次了數數看：
1. 裝PartionMagic後切出一塊空間裝Fedora Core 6...失敗！Fedora Core 6不認得NTFS
2. 裝在隨身硬碟上...失敗~
3. 試試Virtual PC 2007接著裝Fedora Core 6...失敗！Fedora Core 6連光碟開機都失敗
4. 再試VMWare 5.5.xxx接著裝Fedora Core 6...失敗~原來是設定弄錯了
5. 在網路上找相關文章後終於安裝成功了

Linux安裝好後，
想說直接用Fedora Core 6內建的Eclipse來安裝CDT外掛，
啥？
為什麼失敗？
缺少PDT？
有沒有搞錯啊！
你知道現在是幾點嗎？
我光是安裝Fedora 6就已經花掉一個上午和半個下午，
弄了半天還是怪怪的，
決定重新裝第六次的Fedora Core 6，
這次Java(JRE & JDK)和Eclipse都不安裝，
然後一切手動開始安裝，
Fedora Core 6...done
JDK...downloaded and installed
Eclipse...downloaded and unpacked
CppUnit...download, unpacked, make and installed
呼~
到這裡才開始第一次用Eclipse寫程式，
Hello World成功，
哈~哈~
不過高興沒有維持多久...
想說直接用OOP課程給學生的skeleton來編譯看看，
跑沒多久就冒出29x個errors，
預期中的是還不打緊，
但...為了讓makefile正確可以動又花了不少時間，
凌晨兩點...
畫著一個class diagram的視窗終於跑出來了，
但cppunit依舊是失敗，
我不行了先去睡覺...

結果...一整天都在弄Fedora Core 6...

冬天真得是很適合腳踏車到處亂晃的季節，
吹著涼爽的風(台灣的秋天不太像秋天不然應該也很適合)，
既不會汗如雨下也不會覺得熱，
到學校後打開Notebook開始寫下午要教Java用的簡易計算機，
說到計算機印象很深刻，
因為大學修應用軟體設計實習時，
第一次真正先通盤思考過要如何寫，
然後用比許多人少數倍的時間，
開發出最完整功能的成品，
從那次之後慢慢開始想學如何『設計』程式，
而不是寫程式...

原本想把以前的程式找出來，
卻發現它從備份光碟裡消失了...
會有球亂跑的樂透機、工程計算機還有小畫家...都不見了！
嗚~有點難過說，
隨著自己的進步和所學的知識越多，
以現在的我來看那些程式都有一個特色：醜~
而且可能還不是普通的醜，
那時用JBuilder開發成applet的方式，
所有的程式都寫在同一個class裡，
如果沒記錯小畫家那個class應該有超過一千五百行吧！
小畫家...又是另一個印象深刻的東西，
還記得報告完的那一天陪欣道去欣優，
佳潔一看到我就問：沒睡好啊~
呵~因為我第一次整整40個小時沒睡覺(真正寫程式的時間沒多少)！
所以...究竟小畫家花多少時間寫完呢？
大概不到二十個小時吧！
前置的設計時間卻花了將近兩倍吧！
但整體加起來還是比其他人少非常非常多，
所以...設計還是很重要的！

也因為這樣，
為了教羿君還在白板上畫了一些圖，
沒想到意外發現到教學妹寫計算機程式時有個超妙的方式，
用鄭一雄老師的教法來『設計』
呵~
我想這就是知識都是相通的！

會在週末睡到十一點起床的...恐怕很多吧！呵呵~
但是會在美好的週末工作的人應該會比較少一點了，
昨天是OOP作業2的繳交截止日期，
我盡量不去想但是還是沒辦法忘記，
因為當作業2截止繳交之時，
也是助教繼續忙下一個作業的時候了，
還記得當年...呵呵~其實沒很久啦~兩年前而已！
為了OOP作業可是哀號遍野，
幾乎每次作業(第一次和最後一次除外)都是寫了三四十個小時，
特別是第五次作業和第六次作業，
跟GTK+奮鬥了許久，
加上Eclipse + CDT + Cygwin + GTK+每次編譯都要好久，
幾乎都陷入要不要編譯的長考之中，
在這樣的噩夢下，
今年我跟政文決定不讓他們碰觸太多GTK+的問題了，
所以早在一個禮拜前我請政文準備Homework 3的Skeleton，
Skeleton?那是什麼東西？
說穿了就是已經替他們設計好介面，
把程式的架構都弄好，
只需要把恰當的codes填入合適的地方即可，
但這卻也苦了我們，
就像是人月神話中說的系統架構師總是和實作工程師吵架，
實作工程師總認為系統架構師的設計不切實際，
系統架構師卻認為實作工程師想法太狹隘了，
而這個情況正好也在前兩次作業出現過，
總是有學生去找老師抱怨：為什麼助教要這樣設計？
老實說聽完蠻心灰意冷的，
如果你覺得我們的設計不好請直接來找我們討論啊！
跑去找老師是什麼意思啊！
突顯你比較厲害嗎？
我不敢說我自己多厲害啦~
但好歹這是兩個博士研究生共同設計出來的成果，
難道不能尊重一下嗎？
如果在業界，
我真不曉得這些學生敢不敢跳過系統架構師直接找老闆或PM理論的？

總之為了不讓他們接觸太低階的GTK+，
我把我的週末拿來修改政文的Skeleton讓它更好用更好寫，
希望我們做的不是傻事...

六點半的鬧鐘響起，
沒課的上午何必這麼早起呢？
答案早在心中但卻不願意承認地把鬧鐘按掉，
繼續睡...
這種睡眠狀況其實是很不好的，
心裡總是惦記著什麼事情，
但也這樣讓我昏昏沉沉補眠到八點，
而那鬧鐘聲似乎也只是為了吵醒我而存在，
全家都沒人聽到似的，
直到八點老媽醒來敲我的房門說：你不是要去研討會？
還想繼續睡的我問：幾點了？
一句不經意的回答把我從半夢半醒間整個帶回現實：八點！
研討會八點二十開始報到，
只好趕緊吃完早餐騎上野狼...淡忘它太久了，還花了將近兩分鐘發動！
總算在九點趕到會場，
ㄜ...人有點少，
雖然場地還蠻正式的，
卻感覺不出來是國科會應有的排場？
說排場也怪怪的，
總之就是感覺不太對，
領了名牌和午餐卷後聽開幕式，
只能說官方舉辦的研討會就是得聽官方式說法的開幕式，
一點新鮮事都沒有，
超無趣的，
之後有兩場專題演講，
我就故意放棄聽「我國自由軟體推動與政策」...
因為勢必又是一場無意義的演講，
結果另外一場由廠商來演講的「Open Source的方向與趨勢」也是...
難怪我們Open Source的市值做不起來！

Linux的Desktop UI是行銷的事情？
拜託你如果說是跟藝術有點關係我還勉強可以接受，
行銷...如果UI爛的可以靠行銷真的能有幫助嗎？

其實國內會這麼積極投入Open Source的發展，
說好聽一點是站在偉人的肩膀上看的更遠，
說難聽一點就是不肯花錢投資基礎工業或是買source code的license
而Open Source正好提供一個機會，
讓原本沒有基礎的人，
一下子好像拿到了天上掉下來的禮物一樣，
突然什麼都有了，
連原始碼都有了，

但這真的是台灣要的嗎？
換個角度再想想看，
如果沒有Open Source台灣的軟體業會變成什麼？

可能是因為我原本是電子系的學生，
每次想到Open Source就會想到VLSI產業的IP，
假設我們要設計一顆IC裡面需要一個CPU和一個DSP，
我們可能取得ARM的IP和TI的DSP的IP，
然後再用Layout的軟體將這兩個IP加到自己的IC當中，
每個IP授權都是要錢的，
但...花錢買來的IP其內部結構(電路)是看不到的，
你只能把它當成黑盒子，
透過嚴謹規範的Interface定義來連線，
那軟體為什麼不能這樣做呢？

特別是會中也提到一點，
演講人當時在看Linux的核心時，
常常看不懂為什麼要這樣寫？
於是體會到文件的重要，
有次他參加國外的Open Source討會提到這問題，
結果得到的回答是：Source code is document...
最好是這樣啦！

Open Source既不是黑盒子...黑盒子只需要知道介面就好，
卻又沒有良好的文件，
那就像是盲人拿到潘朵拉的寶盒一樣危險！

我個人還是比較贊同上次那位圖靈獎得主所說的，
工程師的責任是將黑盒子做到最好，
而不是喊著我把原始碼公開了，
覺得不好你可以自己改，
那只能對工程師這樣喊，
如果你的程式是賣給連一行程式都沒寫過的一般顧客，
最好是他們會改程式碼啦~
真是搞不清楚狀況！