早上從報紙看到聳動的標題:我國爭取重返聯合國第十四次失敗,
有種不知道要說什麼的憤怒,
聯合國成立的目的難道只是幾個列強用來騙小國的嗎?
也許應該說聯合國無能吧!
要不然前一陣子以黎停戰協議怎麼會這麼久才會有動作,
列強不點頭聯合國就像個廢物,
即使協議通過了以色列就像個長不大的小孩似地,
非得到停戰協議上所說的時間前一秒才肯停戰...有美國撐腰就很囂張,
完全不把安南看在眼裡!
老實說會闖關失敗是聯想都不用想就知道的事情,
就算排入議程,
表決多數人支持,
可是中國卻擁有否決權...聯合國最奇怪的制度:一票就可以否決!
怎麼闖也一定會失敗,
與其用加入聯合國(用什麼國名加入聯合國我不在乎)來騙百姓,
還不如好好跟對岸談判,
如果兩岸沒有共識,
聯合國再怎麼闖也是沒意義的事情,
除非對岸不再擁有否決權!
說到制憲,
台灣也真的需要一部新憲法...國名要加入修憲議題也是可以,
華人受帝制影響之深,
這部需要全民擁有民主素養才能運行良好的憲法根本不適用,
華人有種只要當上總統就以為像是當皇帝一樣...不管藍綠都一樣,
即使立法院是在野聯盟佔多數也毫無尊重過在野聯盟(國會佔多數叫在野聯盟也只有台灣才有),
我們沒有法國人對於民主有高度的素養...用血與革命讓人民真正了解什麼是民主,
法國總統假設是A黨,
國會多數若是B黨(或反對黨聯盟),
為了方便施政總統大可宣布解散國會,
若重選後的國會仍由B黨(或反對黨聯盟)占多數,
總統就必須提名B黨領袖為總理(類似行政院長),
這雖然沒有規定在憲法裡,
但是這就是民主素養,
否則就會向台灣這樣發生國會與行政院對立的情形,
或許有人說總統是人民選出來的為什麼要聽命於反對黨?
那相同地國會不是人民選出來的嗎?
而且多數的國家都是用國會牽制行政,
為什麼?
因為國會通常是多數人的聲音...即使同政黨也不見得意見相同,
更何況國會呈現多黨派時,
聲音更是多元,
比起總統或是行政院長一個人且是一元的想法,
更能表現出全國多元的想法,
所以用國會牽制行政,
才不會變成專政獨裁...專制獨裁並非不好,只是不夠多元!
後來看到另一篇新聞更是覺得好笑:動員10萬人 16日上凱道 府院黨大反撲,
這也許只有在台灣才有可能看得到!
正常的民主國家人民可以以上街抗議遊行來表達對政府的不滿,
不管是由在野政黨動員會是人民自發性的參予都是很合理的,
但從沒有看過由執政黨動員遊行,
目的是在對抗另外一群反對執政黨的群眾,
然後用遊行的方式挺執政者,
實在是好笑到不行,
我們回到兩蔣時代了嗎?
用這種活動營造出萬民愛戴的假象?
執政黨要有雅量,
這種用動員遊行的方式來製作對立實在是很蠢。
總之,
我支持台灣加入聯合國,
不管是獨立還是統一只要是經過民主程序作成的決議我都接受,
最好是如同大前研一或連戰所說的,
台灣以類似獨立國家國協的方式(聯邦)統一,
但是對岸不能阻止台灣加入聯合國,
更不能干預台灣的國際發展及國內政治,
但是...我還是倒扁!
- Sep 13 Wed 2006 20:43
無能聯合國
- Sep 12 Tue 2006 22:00
【轉載】OOOO
單字: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才是上上之策。
- Sep 11 Mon 2006 23:42
我在凱達格蘭
好快~沒想到已經五年了,
五年前的今天是多麼令人震驚,
從此911變成歷史名詞,
一個讓人忘不掉了日子!
今天也是開學日,
我在北科的第13個開學日,
說真的已經對開學日沒什麼感覺了,
已經六個年頭了,
從今天開始又是另一個開始,
也許再收集滿7個開學日,
我就可以取得人生最後一張由學校發的畢業證書了,
因此我決定走出兩年前開啟的BlogDrive,
在Yahoo部落格重新開始!
上午悠哉悠哉地在與書怡伯朗咖啡聊天,
上完唯一的一節英文科技論文寫作後,
抱著書繼續泡在咖啡店裡,
那種充滿在咖啡香裡的感覺真棒,
即使沒喝上一口咖啡也會有提神的唯唯效果。
台北的夜晚最近不是很平靜,
看到他們不畏風雨的熱情,
我也想去表達心中的不滿,
在佳妮的邀約下,
在911的夜晚,
我在凱達格蘭大道上大聲喊出:下台!
表達自己的就是這麼簡單。
愛台灣不等於挺阿扁,
倒扁也不等於不愛台灣,
台灣是彩色的,
不是只有藍色或是綠色,
當然也不是只有我身上穿的紅色,
只要心是愛台灣的,
任何人都是台灣之子台灣之女,
與藍綠無關!
- Apr 02 Sun 2006 14:38
Erika Sawajiri
看到有人用英文拼日文名字的時候,
我總是有個疑惑,
不過我想還是遵循英文名字的排列方式:名+姓!
所以我認為標題的寫法是對的,
如果有錯的話請麻煩告知一下吧!
至於Erika Sawajiri到底是誰?
老實說我沒看過她主演的一公升的眼淚,
只是思賢看過之後就迷上她了,
還丟了一堆她的寫真給我...放心沒有18禁的圖片,
要我幫他做桌布,
當初不以為意想說我之前一口氣做了好幾個月的桌布,
應該不用再做桌布了,
沒想到...上次的桌布只到三月份而已,
哈~結果今天整個早上都在合成桌布,
發現她還真的蠻可愛的,
而且她的寫真拍的很唯美...不是那種很...的那種,
所以很適合拿來做桌布囉!
一不小心又一口氣做了三個月份的桌布,
啊~不行啦!
七月份我要用Misaki Ito的寫真做桌布...不曉得Misaki Ito是誰的請看電車男電視版,
哈~哈~該去寫程式了...XD
2006 April | 2006 May | 2006 June |
![]() ![]() ![]() ![]() |
![]() ![]() ![]() ![]() |
![]() ![]() ![]() ![]() |
- Dec 17 Sat 2005 23:48
[轉載]日本編列2150億美元預算確保科技大國地位
日本即使到現在依然是科技強國,
而且日本很多基礎科技一直都有很深入的扎根,
只要有成果就能夠申請專利,
- Dec 15 Thu 2005 00:18
12/14 - 五張卡片
神奇的事繼續發生了,
今天一整天精神洋溢連Group Meeting都沒睡著,
這是怎麼回事啊~
十一點Meeting結束,
奇怪怎麼欣道還沒下課?
最後...欣道睡過頭了...睡到我打電話給他?
所以我就自己一個人到處逛,
看看即將被拆除的光華商場,
想想還有點不捨耶...畢竟在那裡晃了五年多了,
特別是地下室,
在大三前,
那裡還有一家海報專賣店喔!
房間裡Final Fantasy VIII的掛廉就是在那裡買,
可惜後來老闆想休息就把店收了,
之後大部分的時間就是在地下室找漫畫和書...偶而找找光碟。
我想找個時間帶相機去拍光華商場...
之後照常去吃素食,
倒是老闆的女兒好像有點意外,
我怎麼是一個人來...平常禮拜三都是和欣道一起!
是啊...一個人...
接著去文具部挑卡片,
挑了五張,
我想卡片會送給我有辦法親手送達的人,
至於沒辦法親手送達的好朋友,
我會寄電子賀卡喔~~
真的想收到我親筆寫的卡片請留言(請註明地址和你是誰)...應該沒有吧!哈~哈~
不知道該說門票太大張還是卡片的信封太小,
似乎一定要折起來才塞的進去...
最後是程式紀錄...(看了會頭昏的人可以跳過~)
VisualTPS 1.0 M5 Build 20051214
總行數:13632
1. Single Interface Multiple Document架構完成
2. 被Bugs玩弄一個多小時...
看來先前預估一萬五千行是低估了,
修正目標至兩萬行...
真的是最後了,
給大家看幾張圖片(點選看放大圖)吧!
首先是我房間的掛廉:
這是目前VisualTPS的執行畫面,
其中一個子系統VisualTOL:
- Nov 07 Mon 2005 10:12
網路狂想曲
所以才會有這首網路狂想曲...
網路狂想曲
Server是可憐的,
因為它總是開著Passive Port等別人來連,
永遠不知道是不是真的有人來連,
還是無限漫長的等待...
Client是盲目的,
因為它天真地以為Server總是為它敞開大門,
即使對方已經不見了,
它總是要在好幾次的連線失敗後才承認對方不見了...
Connection是短暫的,
Three-way handshaking就能建立一個connection,
說兒戲卻不兒戲,
而結束也只不過是Four-way handshaking就說再見...
TCP是天方夜譚的,
Reliable只是一個負擔沉重的夢想,
Flow control & congestion control更是遙不可及,
更別說retransmission和Acknowledge是多麼煩人的事情,
因為連繫這種事情本來就不可靠...
Protocol是嚴格且殘忍的,
所有的connection都必須按照protocol來,
不合規矩通通踢開,
或許這才是最好的方式,
因為Server和Client才不會對未定義的事件而不知所措...
UDP相較之下是和藹可親的,
即使它是Transmit and pray,
但是雙方都不需要有建立connection的負擔,
也不用管對方是否收到,
因為收得到收不到,
全看對方運氣好不好或是它想不想收...
IP是值得信任的,
值得信任這句話本身就是個問號,
如果本身是可靠的就不需要加上值得兩個字,
因為IP永遠只會跟你說try its best effort,
and no guarantee...
Layer Architecture只是逃避責任,
把不想做的事情丟給下一層去做,
即使做錯了東西丟了責任都是下一層的事情,
這樣看來TCP還比較有人性一點,
丟了錯了TCP負責retransmit...
End point是不食人間煙火的,
它永遠只知道跟對方交談,
卻不知道這交談是經過多少人的努力才傳達對方,
如果連不到,
只會很生氣地說:死網路又給我斷線了...
可能很多人看不懂我在寫什麼,
網路說穿了,
只是把人與人之間的關係電腦化數位化,
上面所有的專有名詞,
你都可以在人與人之間的關係找到相對應的詞或是動作,
例如Layer Architecture就跟公司裡的分層架構很像...
電腦比較笨,
必須把人與人的關係簡化成讓電腦看得懂的規定或規則,
人或許比較聰明,
但是不見得能處理好所有人與人的關係,
因為人與人之間的關係本來就是很難很複雜的...
其實我寫的是人與人的關係,
所以才叫做狂想曲...
**Advanced reading:
TCP: Transport Control Protocol
IP: Internet Protocol
UDP: User Datagram Protocol
End point: The leaf node in the network Client: End point which uses services
Server: End point which provides services