目前分類:我不要賣雞排 (24)

瀏覽方式: 標題列表 簡短摘要

看著灰暗的天空煩惱著:騎摩托車?坐捷運?還是騎腳踏車呢?(很可惜沒有開車的選項)
最後...還是騎著腳踏車出發了,
即使路面溼漉我的R1000仍飛馳在車陣中...大約五分鐘吧...呵
太久沒有運動了,
足足騎了四十幾分鐘才到學校,
結果跟學妹約好教Eclipse的時間都給遲到了...Orz
還好之後還是教完了,
想說把作業1解答釋出,
赫然發現...糟糕原先要釋出的解答含有作業2的加分題解答,
只好從學生交上來的作業裡挑出一份還不錯的,
用我的部分整合成一份新的解答,
試了三份都發現...他們的程式有蟲,
一看時間...不妙...下午的研討會快要來不及了,
趕緊跑去找孟哲學長一起去圓山飯店,

這次的研討會是微軟亞洲研究院(副院長是台灣人)首次在台灣辦的學術研討會,
主題是高品質軟體的挑戰...討厭微軟的人一定會大笑說:
先把Windows的臭蟲修完再開這種研討會吧!
我個人不討厭也不喜歡微軟,
如果真要比較...我比較討厭Linux...更何況Linux每月發出的漏洞修補程式也不少於微軟啊~
高品質軟體本來就不是一件簡單的事,
微軟為了這次研討會邀請了三位圖靈獎(資訊領域的諾貝爾獎)得主來台灣演講,
其中一個是Pascal語言的發明人Wirth, Niklaus
另外一位是Yao, Andrew Chi-Chih姚期智博士...目前唯一一位獲得圖靈獎的華人(台灣人),
最後一個是對資料庫有重大貢獻的Gray, James
聽起來場面果然浩大,
而且還有口譯機可以借...呵~不過口譯人員被資訊產業的英文用詞弄的團團轉,
不過整場(五場演講)聽完大概只有最後面兩場聽懂,
第二場幾乎快睡著了,
太過學術性了...用數學證明程式沒有bug...我覺得未來10~20年都不可能,
第一場沒什麼重點,
算是廣告吧!微軟全球副總裁李克雷斯特說明微軟亞洲研究院在這九年內做了什麼研究,
其實就算不用他廣告從比爾蓋茲上次在北京說的話就可略知一二了:
我很高興跟各位介紹北京總部(亞洲研究院設在北京),
這個地方全是天才,
每年幫微軟取得上千項專利及發表上千篇的Paper(而且都是高水準的期刊)...

唉~想當初微軟原本想把研究院設在台灣,
結果政府並沒有極力招募微軟到台灣,
最後把研究院設在北京了,
現在這些天才(很多是台灣人)全都到大陸去了,
還在大陸大學教書...其實會後我蠻想問那位圖靈獎得主一句話:為什麼不回台灣教書呢?

五場演講完是發問時間,
有個同學很有意思問了一個微軟討厭的問題:對於Open Source微軟的態度為何?
副總裁倒是挺直率的回答:
對於開放原始法微軟有自己的作法,
事實上我們已經跟很多國家的政府合作並公開Windows及Office的原始碼,
也和許多大學有合作關係並公開原始碼,
我要說的是公開原始碼(Open Source)與商業模式(Business Model)是兩碼子事,
即使是Red Hat也必需替公司尋找獲利的來源,
所以這些號稱Open Source的公司請不要把這兩件事混為一談並攻擊微軟,
而且我並不認為開放原始碼能替使用者(這裡指的是不會寫程式的廣泛end users)帶來任何好處,
反而帶來讓全球的人認為軟體應該是免費的缺點,
你會花錢買電腦,
為什麼不花錢買軟體呢?

好玩的是其中一個圖靈獎得主Niklaus Wirth有補充意見:
我一向反對開放原始碼,
試想如果某個模組已經被證明是沒有錯的,
你為何要去修改它呢?
我們要做的是逼使開發模組的人或公司開發沒有錯的模組,
而不是我們自己去修改模組,
面對開放的原始碼如果沒有註解,
你有自信修改的比原作者更好?
其實往往在修改後產生更多的bugs...

真是超有趣的想法,
他還有很多特別的想法,
例如他在演講中說到:
現在的軟體系統越來龐大但錯誤卻層出不窮,
原因在於電腦太快...震驚!
電腦太快了導致程式設計師太依賴工具而沒有認真地看待正在寫的程式,
總想著:錯了很快就會知道,那時候再改的想法。
這是錯誤的,
加上後來許多驗證程式是否正確的研究及測試的研究,
讓程式設計師想著:反正會有程式或測試會告訴我哪裡錯了?
而不去思考如何寫對一個程式?

這讓我想起來昨天早上在幫學弟看OOP作業時,
他很習慣的就把Eclipse切換到Debug環境,
其實我早就看出來哪行是錯的,
他卻在Debug環境中一行一行的跑(單步模式),
結果還是沒找出問題在哪裡,
我後來指著螢幕某一行說:
你把這行程式用中文說給我聽,
才說完陪著他看程式的佑竹馬上就笑了...他也知道程式錯在哪裡了,
這就是Code Review,
每個程式設計師在寫完某段程式時,
應該找個人幫你做Code Review,
一行一行用自然語言(以我們來說是中文)把想法說給對方聽,
在你說的同時,
你往往就會知道:啊~原來這裡寫錯了或是啊~原來這裡少判斷了什麼?
比起在debug環境中跑來跑去弄個灰頭土臉要好用多了,
Debug環境是最後的手段,
除非必要否則人腦會更好用(因為人腦比較聰明)!

另外一個有趣的問題:
先前MIT與廠商合作,要做出100元美金的電腦給第三世界國家的窮人使用,微軟會跟進嗎?

副總裁官方式的回答沒什麼意思,
反而是另外一個圖靈獎得主說:
請擺脫電腦一定是IBM PC那種有主機、螢幕鍵盤的想法,
現在幾乎每個人(他指開發中國家及已開發國家,口譯似乎漏掉了)都有手機,
如果摩爾定律繼續維持下去,
在未來每個人的手機都是一台電腦,
而且還是一台超級電腦,
價錢也絕對低於100元美金,
所以我從不擔心這個問題!

除了微軟很小氣的沒提供午餐及點心外,
我覺得這場研討會收穫不少!
希望微軟能多辦幾場這樣的研討會(規模可以大一點...)

關於圖靈獎可以參考(Yahoo奇摩知識+):
http://tw.knowledge.yahoo.com/question/?qid=1206032609940
至2005年為止的圖靈獎得主:
http://awards.acm.org/homepage.cfm?srt=all&awd=140

dbi1463 發表在 痞客邦 留言(0) 人氣()

今天是教師節...嗯...老實說我還真的忘記有這個節日了,
詹偉雄在美學的經濟一書中說的對,
你絕對不會忘記西洋情人節、白色情人節、母親節、端午節、父親節、中秋節和聖誕節,
因為一堆的商品廣告會不斷提醒你這些節日快到了,
但教師節呢?
似乎很少有相關的商品廣告吧!
教師節慢慢被遺忘了。

今天專題討論老師請來一位清華大學資訊工程博士來演講,
題目就叫做:數位學習 - Internet 下ㄧ波應用的推手,
原本以為會是什麼很學術或是很理論的演講,
不過後來卻讓我很意外...雖然有點像產品推銷啦!
在數位學習這一塊中,
鄭老師也投入相當多心思在這一個領域上,
雖然方向不太一樣,
我們卻也看過不少相似的軟體,
但這軟體真的很讓我意外,
首先,
他錄製教學相當簡單,
安裝完PowerCam後PowerPoint會有一個按鈕,
當你想使用PowerPoint報告時只需要按下錄製鈕,
PowerCam就會幫你放映投影片,
並且開始錄製畫面上的所有動作和聲音,
按下Esc鍵會同時停止錄製和放映,
最重要的是,
它錄製的影像超級清晰而且沒有絲毫的delay...聽說這是蘇博士擅長的項目(獨門配方?)
檔案也很小,
我還沒看過這麼好的螢幕動作錄製軟體。

第二個是它結合知識管理系統(Knowledge Management System),
所有錄製好的教學都可以透過網路上傳至網站上,
學生也可以針對線上教學發表意見與討論,
以後學生再也沒藉口說:某某老師上的有夠爛,所以這門課我什麼也沒學到...
因為某某老師上的有夠爛,
你還可以去其他老師的網站上課,
台大、清華、成功以及其他許多大學都有使用這套系統...我建議系上也採用這套系統好了,
想去台大上課?
用這套系統吧!

但老師是否就不需要了呢?
不盡然,
韓愈說:師者,所以傳道、授業、解惑也!
老師不是只有傳授知識而已,
即使再好的知識管理系統加上線上學習系統都無法完全取代老師,
最起嘛要有人錄製教學吧?

其他還有相當多應用,
我最有興趣的是論文報告,
之前跟老師提過要建立我們研究室的知識基礎,
畢竟我們的GTT和TPS都已經是四五年下來的成果,
新進學弟妹(學妹到還沒出現過?)總是需要一些教材讓他們快速進入狀況,
這系統可以拿來做這種用途!

最後某個學弟問:當初創業時只有兩個人,那資金哪來?
這讓蘇博士笑著說:這問題可以不答嗎?...秘密嗎?
不過他最後還是回答了,
他們當初是握有關鍵領先技術...就是那個小檔案高解析度的影像壓縮技術,
加上軟體業創業資本本身就不高...只要有人願意(通常都是創始者)不領薪水的話!
並沒有太大資金的問題,
至於行銷不要出太大錯誤應該就不會失敗...這點我持保留態度。
總之,
這讓我想起很久很久就被我塵封的想法:自行創業!
不想去大宇、宇峻等現有遊戲公司且又不去硬體公司上班的另外一條路!
關鍵就是...在畢業前讓自己取得關鍵領先技術!...有誰願意陪我不領薪水啊?

dbi1463 發表在 痞客邦 留言(0) 人氣()

為了讓學弟將心思放在如何寫出Object-Oriented的程式,
歷年的學長都會整理一些教學文件,
而今年這樣的工作換到身為OOP助教的我!

特別系上OOP這門課近幾年都採用Eclipse + CDT + GTK開發Windows平台的C/C++程式,
並不是為了省Visual C++的授權費...每年都會跟微軟購買兩三間實驗室的授權,
這種組合超麻煩的,
光是要在Windows平台上使用CDT,
就得在Windows平台上安裝Unix-like的模擬環境:MinGW或Cygwin,
要開發視窗程式還需要安裝GTK,
偏偏GTK還只能算是C的函式庫,
所以要花工夫包裝成OO的元件,
何必這麼麻煩呢?
主要是希望學生能透過這種方式學會如何用物件導向的方式包裝視窗元件,
也許有人會說:何必自己造車輪呢?
呵~對!我們就是在教學生自己造車輪,
明明有MFC這些方便的元件可以用,
或者有Visual Basic那樣拖拉元件拼拼湊湊的方式就可以寫一個小程式,
但那樣的程式真的好嗎?
沒聽過Observer Pattern?
那真的能把MVC架構用到駕輕就熟嗎?
更別說MFC中變形的Document-Application架構了,
沒聽過Singleton嗎?
那恐怕很少人知道Singleton的變形應用在許多地方吧?
沒聽過Command Pattern嗎?
於是可以看到很多人使用JBuilder開發Java程式時或是用Visual Basic時,
總是喜歡在按鈕上點兩下然後開始寫程式,
然後程式碼亂七八糟,
用這些怪理怪氣的方式在寫程式,
等到程式出現非預期效果時,
或是當掉時才問:為什麼會這樣?

系上的用意是要讓學生知道這些輪子為什麼這樣造?
或是為什麼不這樣造?
當自己會造粗造的輪子後,
就會知道原來別人要設計這麼好的輪子需要多少智慧,
會用更多心思去學習,
然後活用!

Visual C++就是太過方便了...其實Eclipse也很方便了,
MFC太好用了,
所以才會決定用上述的方法讓學弟無法偷懶,
但也苦了助教,
每年都要更新這些文件也蠻累的,
特別是當自己決定用CPPUnit改作業時才發現:ㄜ...為了寫CPPUnit自己也要寫一份成品出來...Orz
回想自己碩一時會抱怨文件寫的不詳細或是為什麼要用CDT,
常常覺得很不舒服,
但習慣後慢慢覺得...其實沒這麼難嘛!

但說句實話,
商業產品還是別用這種方式開發,
能用別人做好的輪子就別自己做輪子,
特別是自己做的輪子還比較差時!

呵呵~昨天減重班營養師問:暑假過後還有繼續變瘦的請舉手?
當時只有我一個人舉手...後來一個遲到女生瘦超多的,輸給她了~
即使瘦少少的兩公斤,
但...還是瘦了!
真是太高興了是也...Kero~Kero~Kero~Tama~Tama~Tama~

dbi1463 發表在 痞客邦 留言(0) 人氣()

學鏞辭典
單字:OOOO(Obsessive-Object-Orientation Obliquity)
發音:KK: [O`OOO] DJ: /O`OOO/
解釋:n. 【醫學】【電腦】過度物件導向偏頗症,是一種過度使用物件導向(Object-Orientation)的病症,好發於年輕的程式員身上。屬於接觸性傳染,帶原者包括了不良的程式設計書籍和不夠專精的程式設計老師及同事同學。
例句:

1. OO Advocates tend to be OOOO patients. OO 擁護者很容易就會變成 OOOO 的病人。
2. People with a good understanding of computer science can get rid of OOOO. 對於資訊科學有深入的瞭解可以避免 OOOO。
3. Most OO experts used to be OOOO victims. 大部分 OO 專家都曾經是 OOOO 的受害者。

為了要有模有樣,我發明 OOOO 這個詞時,還特別參考了心理學的強迫症(obsessive-compulsive disorder),原本想叫做 obsessive-object-orientation disorder(OOOD),只是我不喜歡在這個詞的最後使用 disorder,我於是用 O 開頭的單字 obliquity 來取代 disorder,剛好形成四連 O 的詞。

當今 OOOO 的感染者人數眾多,數量直逼想靠樂透彩發大財的愚夫愚婦。他們常常有嚴重的幻想,認為全世界最了不起的東西就是 OO,成天開口閉口都是 OO,寫程式時只管大用特用 OO,完全不管 OO 所帶來的負面影響。

許多錯誤的資訊,是造成 OOOO 普遍的原因。例如下面的說法,在許多書上都看得到:

物件導向是很自然的,教導一個小孩物件導向比教導一個電腦教授更簡單,因為教授已經太熟悉電腦內的運作,所以比較難建立正確的物件導向觀念。

上述的說法並不正確,但是許多人卻都以為這樣的說法是對的。我認為這樣的說法錯在於:

1. 只要對於電腦運作原理的認知不夠,很難真的學會 OO,因為 OO 畢竟是用在電腦上的。許多人通常只能瞭解封裝,對於繼承不能完全掌握,對於多型更是難以捉摸。
2. 只要對於電腦運作原理的認知不夠,規劃出來的 OO 一點都不實用。可能是效率太差,可能是彈性太差,問題很多。

OOOO 患者寫出來的程式常常會有下列的病徵:

1. 太多類別:每個類別重用率極低,造成記憶體浪費太多。通常這樣的狀況,必須適當地利用繼承來改寫,或把功能類似的數個類別濃縮成一個類別。
2. 太多繼承:繼承固然可以提高重用率,但是也會使得物件體積變大許多,而且執行效率也會變差。繼承被誤用的情況一直很嚴重。更糟的是,繼承是一種靜態的關連,使得程式的彈性變差。許多時候,繼承可以用 associate 來改寫。
3. 太多物件:通常前述的「太多類別」會造成太多物件的狀況,但是即使類別不多,也有機會造成太多物件的狀況。一個程式使用太多物件會造成記憶體浪費。其實在許多時候,物件可以彼此共享的。
4. 太多短命物件:這會造成建構(construct)和回收(reclaim)花的時間太多,對於系統效率有很不好的影響。許多程式員的程式中有許多短命物件,但他們卻完全不自覺。可以使用 Object Pool 等方式來改寫。
5. 太多視覺元件:「太多物件」已經很不好了,如果這些物件是視覺元件,更是雪上加霜。視覺元件需要耗費 CPU 大量的運算能力。
6. 太多執行緒:其實從 OO 至上的角度來看,每個物件都是一個執行緒是最 OO 的,但是這樣顯然實際上不可行,因為佔用太多 OS 的資源,效率會變很差。

想擺脫 OOOO,你需要花好幾年的時間。建議各位好好研究 Java Swing,這是一個將 OO 發揮到極致又不失彈性和效率的 API。上述的六個 OOOO 的病徵,Swing 完全都沒有,足見 Swing 設計的巧妙。

OOOO 固然不好,但千萬不要因噎廢食而不用 OO,畢竟 OO 還是好東西,只是再好的東西都要適量。想擺脫 OOOO,您不妨多學習一些好的 design pattern,並認識作業系統、編譯器、以及程式語言內部的原理。



因為要準備博士候選人資格考,
看了一整天的Head First Design Pattern...再次推薦這本好書!
後來閒暇之餘在O'Reilly網站上找書時發現到這篇小文章,
看了深有同感,
特別是這學期身兼OOP助教,
到時應該會看到很多感染OOOO病人吧!
或是ANOO的病人...Absolute No Object-Oriented? 笑~
不過我覺得會導致OOOO病人越來越多的原因絕對跟現在市面上充斥一堆非常爛的書有關,
特別是書名中有類似:輕輕鬆鬆學、快樂學等關鍵字,
也很容易看到有那種書名寫著C++卻用很多C概念所寫的書,
於是很多人要不就是完全搞不董OO是什麼回事,
就是K了幾本爛書就以為自己會使用OO了,
可是卻連一個完整的軟體如何分析設計都沒做過,
於是學鏞辭典裡面所述的幾個病徵就出現了,
所以對於想學程式設計的人,
我不反對挑中文書...畢竟原文書真的很貴,
但是還是多挑一點原文翻譯書吧!
想學C++嗎?
侯捷先生幾本翻譯書都是很不錯的選擇!
想學Java嗎?
蔡學鏞先生幾本翻譯書(Head First Java亦是不錯的"觀念"入門書)和O'Reilly系列的書籍也很不錯!
想學美術設計嗎?呵~好像偏離主題了...其實這是我的興趣之一,
上奇出版社及無限可能創意出版社也是不錯的選項,
也許有人認為他們只是封面排版比較漂亮而已...也比較貴一點,
不過如果連一本書都排的不漂亮,
你確定那本書的作者能教會你什麼嗎?

此外別以為K了幾本書就自認為自己是C++/C#/Java或是VB的高手,
程式語言只是語言!
一個高超的軟體工程師就算只會一個語言,
也比會很多語言卻完全不會設計的程式技師強太多了!
最後...除了語言、設計、規劃及管理外,
多充實自己的Domain Knowledge才是上上之策。

dbi1463 發表在 痞客邦 留言(0) 人氣()

«12