報上提到許多中國的教育界人士跨校發表聯合聲明,抵制西方耶誕節。聲明中表示,慶祝耶誕是『是國人在文化上陷入集體無意識的表現』。「而消除西方文化影響當務之急,是先向兒童大力普及傳統文化,將讀經納入學校教育,從國民觀念入手」。
很多人把『現代化』與『國際化』還有『商業化』跟西方文化入侵混為一談。
首先,用西方文化一網打盡,根本是駝鳥的想法。西方,包括東歐與中東嗎? 同樣是美洲,光是中美洲與北美洲就有極大的文化差異,更不用說在歐洲水火不容的英國與法國了。再者,耶誕節在亞洲是跑出去玩的日子,沒有幾個人是真的在感念耶穌的。說穿了就是找個藉口出來購物唱歌跳舞,頂多了不起就是肥了開店促銷的老闆們打折扣戰罷了。若要抵制,是抵制百貨公司呢,還是抵制教堂?
個人認為,與其抵制西方文化,不如先抵制自己。中國從使用簡化字那天開始,就已經與珍貴的傳統價值脫鉤了。在全面使用簡化字的情況之下,想要說服下一代愛惜自己文化,那就只能讀前幾年才寫出來,專門避開正體字的中華字經。當年為了取得無教育革命大眾的支持而造成文字低俗化,到今天就只落得一個藉口: 十三億人都在用,所以不能改。什麼叫向下沉淪,全國使用錯別字,低俗字,就是向下沉淪。
你若是愛中華文化,請給正體字一個機會。
Friday, December 22, 2006
Thursday, December 14, 2006
Java求職者要當心的錯誤
首先是一般面試準備的部份
一、沒有辦法回答的問題請不要寫在履歷表上
這在台灣聽起來好像是廢話,但是在這裡卻經常發生。原因是人力仲介公司多半知道在大公司裡履歷表會經過職員篩選之後才會到面談人員的手上。為了能過第一關,這些仲介公司都會提醒你盡可能把現在流行的字全部寫進去。根據目前來看,五個人之中至少有一個會寫一些不存在的工作經驗。我的看法是,千萬不要上了人力仲介的當。如果你寫出來了,你就要真的能回答。等談到一半發現履歷表上是掰的,這樣後面就很難繼續了。
二、答錯時不要害羞,也請不要發脾氣
再厲害的資訊人員也是會寫出有錯的程式,更何況是回答問題。如果面試人員明確告知答案可能有誤,不要害羞,您有權力問正確的答案,也可以提出一些討論。但是很重要的一點,請避免出現防衛過當的情況。如果對方認為答錯,必然有其原因。這個時候絕不能想著要扳回面子而強行辯解,僅就問題解答提出簡單討論即可。滔滔雄辯在正式工作時或可發揮效益,然而在求職時打口水戰卻可能贏了面子,輸了裡子。當然,更要避免發脾氣而大罵面試人員問這什麼無聊沒人用的東西答不出來。
接下來是技術的部份
三、Pass by value
Java在傳遞參數的時候是傳值的,這個答案不能錯。如果怕被搞混,就乾脆背下來: All parameters are "pass by value". 細節可以參考Ken Arnold The Java Programming Language, 2.6.1.
這個答案通常是有老經驗的C語言程式設計師容易答錯。
四、cookie不是session
如果是找web相關程式工作,請避免把cookie跟JSP/Servlet session object搞混。cookie是放在瀏覽器的;session object是活在伺服器裡的。在session裡面放一萬個超大的圖檔,會先搞掛伺服器,不是瀏覽器。截至目前為止Java沒有人在搞view state這一套,所以這個答案能模糊的空間也不是很大。
五、Design Pattern: Singleton
很多人會順手寫上Design Pattern,而且第一個回答的就是Singleton。Singleton是用來保證在執行環境裡只有一個物件instance的技術。請小心,Singleton是個陷阱,因為大部份人所知道的Singleton都是抄自GoF的書。GoF的Singleton對於單程單緒的程式是可以的,但是放到Java上面,GoF Singleton有兩個大問題:
1. 當你有多個JVM的時候,Singleton作不到single instance(因為每個vm有一個instance)
2. 那怕只有一個JVM,Singleton也不能保證多執行緒安全。安全的Singleton看起來一點都不酷。細節分在另外一篇文章裡。
六、資料庫的Connection Pool用完了還是要還的
你如果用完不還,JDBC是不會自動把它回收的。這跟Garbage Collection一點關係都沒有。稍微有一些工作經驗的人應該都受過這種教訓。
七、如果是應徵程式設計師,請小心避免熱門關鍵字SOA
老實說,SOA根本是分析師或是決策人員在玩的東西。如果提到SOA,請確定您沒有把它與Web Service和Enterprise Service Bus(ESB)搞混在一起。
八、不懂EJB一點關係都沒有,不要硬寫上去
說真的,不懂EJB一點都不影響面試結果。反正EJB2現在是過街老鼠,企業避之唯恐不及,所以大可放心的說你不用EJB。今年開始不少人看到EJB3變簡單了,忙著寫在履歷表上。請小心,因為EJB3只是開發的時候變簡單,真正放在機器上跑,還是要面對原來的問題,還是要得和serialization/rmi/iiop/tcp/ip/ethernet搏鬥。如果您寫上EJB的經驗,至少要曾經deploy ear到真正的機器上跑過才算。還有,Message-driven EJB是用來『接收』的,不是用來送訊息的。
九、你職業生涯裡最有成就的例子
凡是有主管在的時候,主管最常問這個問題。準備這個答案的時候,有量化的資料最好了,例如,『因為我寫了這個工具,公司員工平均一周省下四個小時』,或是『本來系統反應時間是九十二秒,經過refactoring之後只需十六秒,快了將近600%』主管們不在乎你會不會程式語言,但是很在乎你想不想解決問題。
其餘的就真的看運氣了。
一、沒有辦法回答的問題請不要寫在履歷表上
這在台灣聽起來好像是廢話,但是在這裡卻經常發生。原因是人力仲介公司多半知道在大公司裡履歷表會經過職員篩選之後才會到面談人員的手上。為了能過第一關,這些仲介公司都會提醒你盡可能把現在流行的字全部寫進去。根據目前來看,五個人之中至少有一個會寫一些不存在的工作經驗。我的看法是,千萬不要上了人力仲介的當。如果你寫出來了,你就要真的能回答。等談到一半發現履歷表上是掰的,這樣後面就很難繼續了。
二、答錯時不要害羞,也請不要發脾氣
再厲害的資訊人員也是會寫出有錯的程式,更何況是回答問題。如果面試人員明確告知答案可能有誤,不要害羞,您有權力問正確的答案,也可以提出一些討論。但是很重要的一點,請避免出現防衛過當的情況。如果對方認為答錯,必然有其原因。這個時候絕不能想著要扳回面子而強行辯解,僅就問題解答提出簡單討論即可。滔滔雄辯在正式工作時或可發揮效益,然而在求職時打口水戰卻可能贏了面子,輸了裡子。當然,更要避免發脾氣而大罵面試人員問這什麼無聊沒人用的東西答不出來。
接下來是技術的部份
三、Pass by value
Java在傳遞參數的時候是傳值的,這個答案不能錯。如果怕被搞混,就乾脆背下來: All parameters are "pass by value". 細節可以參考Ken Arnold The Java Programming Language, 2.6.1.
這個答案通常是有老經驗的C語言程式設計師容易答錯。
四、cookie不是session
如果是找web相關程式工作,請避免把cookie跟JSP/Servlet session object搞混。cookie是放在瀏覽器的;session object是活在伺服器裡的。在session裡面放一萬個超大的圖檔,會先搞掛伺服器,不是瀏覽器。截至目前為止Java沒有人在搞view state這一套,所以這個答案能模糊的空間也不是很大。
五、Design Pattern: Singleton
很多人會順手寫上Design Pattern,而且第一個回答的就是Singleton。Singleton是用來保證在執行環境裡只有一個物件instance的技術。請小心,Singleton是個陷阱,因為大部份人所知道的Singleton都是抄自GoF的書。GoF的Singleton對於單程單緒的程式是可以的,但是放到Java上面,GoF Singleton有兩個大問題:
1. 當你有多個JVM的時候,Singleton作不到single instance(因為每個vm有一個instance)
2. 那怕只有一個JVM,Singleton也不能保證多執行緒安全。安全的Singleton看起來一點都不酷。細節分在另外一篇文章裡。
六、資料庫的Connection Pool用完了還是要還的
你如果用完不還,JDBC是不會自動把它回收的。這跟Garbage Collection一點關係都沒有。稍微有一些工作經驗的人應該都受過這種教訓。
七、如果是應徵程式設計師,請小心避免熱門關鍵字SOA
老實說,SOA根本是分析師或是決策人員在玩的東西。如果提到SOA,請確定您沒有把它與Web Service和Enterprise Service Bus(ESB)搞混在一起。
八、不懂EJB一點關係都沒有,不要硬寫上去
說真的,不懂EJB一點都不影響面試結果。反正EJB2現在是過街老鼠,企業避之唯恐不及,所以大可放心的說你不用EJB。今年開始不少人看到EJB3變簡單了,忙著寫在履歷表上。請小心,因為EJB3只是開發的時候變簡單,真正放在機器上跑,還是要面對原來的問題,還是要得和serialization/rmi/iiop/tcp/ip/ethernet搏鬥。如果您寫上EJB的經驗,至少要曾經deploy ear到真正的機器上跑過才算。還有,Message-driven EJB是用來『接收』的,不是用來送訊息的。
九、你職業生涯裡最有成就的例子
凡是有主管在的時候,主管最常問這個問題。準備這個答案的時候,有量化的資料最好了,例如,『因為我寫了這個工具,公司員工平均一周省下四個小時』,或是『本來系統反應時間是九十二秒,經過refactoring之後只需十六秒,快了將近600%』主管們不在乎你會不會程式語言,但是很在乎你想不想解決問題。
其餘的就真的看運氣了。
Sunday, December 10, 2006
春天大拜拜

儘管所有的資訊人都知道,這世界上沒有一顆神奇的銀色子彈可以同時打到鮪魚肚與膝蓋(扯遠了),但是Spring卻不能免俗的想要當一顆銀色子彈,學Java EE把所有商業規格吃下來。這就像蝙蝠俠的編劇一樣,凡是看到什麼,加上蝙蝠兩個字,就成為新產品,例如蝙蝠飛機,蝙蝠書包之類的。看起來Spring也學會了蝙蝠俠的這幾招。這三天下來,什麼東西前面通通都加上Spring: Spring OSGi, Spring JMS, Spring Weblogic, Spring Mule, 到最後還來個Spring.NET, 聽得我真的快吐了。我一直覺得dependency injection是對的觀念,而且Spring與Pico Container一樣, 是不錯的設計。只是說,真的有必要用這個方式把所有東西都沾到邊來賣嗎?
Tuesday, December 05, 2006
Monday, December 04, 2006
Saturday, December 02, 2006
核一: 核二: 核三: 核四

不是核電場。是講前幾周開打的四核心CPU大戰與伺服器虛擬化與軟體授權。
其實伺服器虛擬化已經在IBM的商業系統有好一陣子了。不但可以把一台機器當成多台來跑,也可以把多顆CPU合在一起當成一個來用,且記憶體大小也可以隨時增減。早年的IBM系統只跑專門寫給IBM的程式,因此很少有人注意到它們用了什麼軟體授權。直到這幾年,Linux與Windows伺服器虛擬化的技術成熟,企業才發現了這個新的省錢漏洞:買一套當n套用。
不僅是虛擬化影響到軟體授權方式,多核心技術也是。原本很多軟體依CPU的數量來計價。去年出現雙核心的處理器之後,只要買一個CPU的軟體就可以當兩個cpu來跑。這些軟體公司在去年紛紛更改他們的Licensing Model來因應雙核心處理器帶來的改變。算幾個CPU來計價的時代已經過去了。算安裝在硬碟幾套的時代也已經過去了。新的Licensing Model,算的是在記憶體裡存在的數目與核心數目。不管你在硬碟裡裝了幾次,每載入記憶體一套,就算一套的錢。如果你關掉一個vm,再開一個,這樣也只算一套。
前幾天打電話去Windows XP Pro的啟動熱線。接電話的印度女服務員很明顯是聽不太懂什麼是虛擬化,拼了命問我是幾台電腦。嗯。一台。
Subscribe to:
Posts (Atom)