作弊的文化

前一陣子看完這本書,對照當前社會上發生的風雨,突然覺得這本書說的太對了。不過書已經還了,所以只能盡量就我所能寫下記憶深刻的地方。

作者分析了很多實際的案例,和當前的社會制度,提出了幾個導致這種文化的原因。

1)貧富差距過大

第一名吃肉,第二名吃ㄆㄨㄣ,第三名以下統統喝西北風。勝者與敗者的差距過大導致人人都害怕當第二名,於是盡一切可能也要拿到第一名。作者提到了美國考試的一個例子:在美國如果被診斷出學習遲緩,那麼考試的時候可以不計時間,考卷上也不會特別加註。這導致了許多的家長用盡一切資源找到願意配合的醫師來幫他們正常的小孩開張學習遲緩的診斷書。

孔老先生也這麼說: 不患貧而患不均。

此外對於作弊的懲罰不夠,尤其是經濟犯。作者提出了幾個掏空公司的負責人為例子,指出他們早在事發前就把財產轉移。於是坐個短短的牢獄出來之後,就可以繼續享受。而所謂的享受可是幾百萬、幾千萬美金阿!在懲罰如此輕微而獲利如此豐富的情況下,也難怪一堆人都要作假了。

2)贏者全拿的遊戲規則

只要你是第一名,你什麼其他犯的錯都可以被允許,都可以被忽視。所以無名小站現在創業成功了,他們過程中的風風雨雨就可以被忽略? 作者提出了有錢人想盡辦法影響國會進而修改法律避稅的例子。也點明了現在社會的風氣:只要你成功,過程的瑕疵都可以被自動忽略。大家會跟你說,這不是重點,重點是ooo xxx,是啦,誰不犯錯,但死不認錯就太過…。這也難怪之前朱學恆先生會在XDite 的部落格迴響中,對某人大發脾氣了。

singletons

今天在查資料的時候,看到這種寫法,酷。

一般在java中,Singleton的寫法會長這樣:

public class Singleton {

static Singleton instance;

public static Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}

}

這樣每次都會判斷 instance 是否等於null, 但是其實只有第一次要而已。 所以可以改成下面這樣:

public class Something
{
private Something()
{
}

private static class LazyHolder
{
private static final Something something = new Something();
}

public static Something getInstance()
{
return LazyHolder.something;
}
}

這樣就不會每次都判斷了,而JVM的spec保證,something只有在第一次getInstance被呼叫的時候 才會被初始化:P (效率也比較好)

真是太酷了。

refer:

http://www.oreillynet.com/onjava/blog/2007/01/singletons_and_lazy_loading.html

http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom

唔 這年頭什麼都虛擬化了

今天在 TSS上 看到jSeamless 這套GUI 虛擬層的東東。看起來不錯,寫好java後,可以在ap跟 web上產生一致的介面跟行為。不過在web上是產生成flash (based on flash 9)而不是 html。討論中看到許多類似的framework,像是openlaszlo,不過openlazslo是撰寫xml後產生flash介面,而不是使用java。

類似的還有Echo2,吱 framework大爆炸阿..orz。

另外我一直很想看的討論-Rethinking JSF – The Real Problem 終於讓我等到了。再加上 Java开源框架发展的遐想 這篇,某方面來說,應該可以釐清一下這些框架的優缺點。 目前看起來wicket似乎受到很多人喜愛,不過叫好不叫座…

天看了一整個早上阿,討論串一直冒出來,終於可以稍稍解決困擾我很久的疑問。

考慮到維護性不能選Wicket來做,不然接手維護的怎麼辦(ROR!!! 那肯定沒人會改..XD)。
目前看起來就剩JSF跟Struts 2了。 不過我是不太可能選JSF啦….
看起來結果很明顯的樣子..

星海二(1)

看到星海二總是會想到星海。想到星海,就不由自主會想到當年高中、大一時的生活。看看部落圈中多少人開始回憶起之前的樣子,就知道星海在我們這一輩的心中佔據了多大的位置。

這種感覺就像在路上偶遇久未見面的老友。一開始總是以問候對方近況起個頭,再來就是互相交換一下共同朋友的近況,更進一步則是回憶起過去一同幹得傻事。回憶大多總是美好,因為它總是以一種抽離於當時境遇的方式存放。第一口永遠是甜,隨著糖衣的褪去,回憶伴隨著當時的氛圍出現,於是甜中似乎帶了點苦澀,青春的苦澀。這是第一層苦澀。第二層苦澀則是在於彼此間居然只剩下回憶這個相同之處。

高中時期,我們那一群下課後除了打籃球打到昏天暗地外,就是跑去網咖打電動。一開始是世紀帝國。其實玩什麼遊戲不是太重要(當然好遊戲肯定有大大加分的效果),而是那種同仇敵愾,一丘之貉的快感。我總是被這種氣氛感動,總是認為世界就會這樣繼續下去。世紀帝國雖然讓我們玩的很開心,但還遠遠比不上星海。當然,遊戲的熱度還是有差。

星海則是最讓我們癡迷,從下午五點玩個一兩場直到七八點,然後再去附近吃肉粽、肉圓。席間討論著剛才戰役的種種,好不快活。下課時間的言談中也充斥的星海與世紀的術語。星海在當時是超級熱門,一眼掠過網咖的螢幕,十之八九都是星海。一開始我們都是自己分隊玩,到後來就會有人找你們來挑。這時候就有趣了,就像打籃球跟外人對打一樣。更有同仇敵愾的那種氣勢。唉,很幼稚的地域性少年阿。

其實我很懷念一下課就跟大機機溜去大學部包25塊自助餐的時候,我也很懷念偷偷在教室裡用電鍋煮飯的那一刻,我也很懷念參加校內籃球三打三比賽的時候,雖然我一比賽總是軟手。不過嘛,這其實是第二種苦澀了。

沒多久就高三要準備聯考了,但是晚自習唸書總是苦悶,經常二、四招一招手,就有人隨你而去。既然二、四玩過了,一、三、五就要懷著懺悔的心稍微認真唸書。不過日期經常是顛倒過來:P。後來果然一堆人重考..orz。

但其實,大多數的朋友都是被那種氛圍所吸引,而不是遊戲本身。就像是我可以鼓動他們拿出錢來購買萬王之王,但脫離那個環境,他們再也沒有進入過那個世界。當我們上大學各分東西後,他們就不是那麼迷星海了。只有我還繼續毀人不倦。說穿了,對那時高中的我們而言,真正的苦澀其實就是找尋不到自己與這個團體或是世界的連結,是種急於證明些什麼的苦澀,與真正的苦澀相比就像是參了牛奶的拿鐵。但苦澀就是苦澀,就算是參了牛奶的咖啡,苦澀還是苦澀。於是當我們找到了一個出口,一個可以讓我們找到與這個團體、這個世界連結的證據,我們就緊抓住不放。

隨著大家各分東西,要維持住相同的感情就顯得困難許多。朋友在我們的生命中來來去去,能一路走下來的還真的要有點緣份。對我這種喜愛窩在住所又不常回南部的人來說,要維持住感情面,就顯得格外困難。一開始還會去互相的學校拜訪,後來我嫌麻煩,就逐漸退出了這些活動。當然時間也改變人很多,很多東西就自然而然的散了。我上次見到這群傢伙已經是兩年前的事了呢。有時候我會在想…

meebo雖然只是個線上msn的服務,但是它能查的到你不在誰的MSN名單中。人生中真的很多巧合,當我開始憶起這一切的時候,突然注意到meebo這個功能。看著你名單上的朋友資料中顯示:

has you:no

嘴角似乎有種說不出的苦味呢。

爆米花悅讀部落格

這是今天從公文系統中看到最有趣的東西了 lol

為推動公務人員閱讀風氣,建構完整的讀書會網絡,整合專書閱讀之相關訊息資源,提供予各機關(構)學校讀書會經營及線上討論分享平台,國家文官培訓所(以下簡稱本所)特建置「爆米花悅讀部落格」網站,作為閱讀分享之園地。(網址:http://blog.ncsi.gov.tw)

全文可以從這裡看到。 媽阿,太有趣了。我只有個疑問,怎麼選了一套比較不知名的部落格軟體呢?

Fast file Loading(Part .1)

source:http://www.gamasutra.com/features/20070419/garcia_01.shtml

這篇值得紀錄一下。這篇主要在比較如何快速地從硬碟或是DVD光碟機中把檔案載入。作者一共比較了四種。

程式碼我就不貼了,請連回原本的網站看。

1)正統可攜的方式(傳統c fopen的方式)

2)使用win32 api

3)File Memory Mapping

4)非同步IO

測試環境:

  • 7200轉的硬碟,平均讀取速度有46.8 MB/s
  • DVD-ROM(使用 DVD+RW) 平均速度為 2.40 MB/s

而作者為了怕作業系統cache這個檔案,還自行撰寫一個程式於讀取後清掉cache。這每個測試都測試過十次。

底下是測試數據,作者使用了一個100 MB的檔案。

硬碟讀取部份:

硬碟 Min(MB/s) Max(MB/s) Average(MB/s)
ANSIC 47.847 48.828 48.527
W32 47.483 48.852 48.497
MMapped 45.830 48.828 48.190
Async I/O 48.239 48.852 48.700

DVD部份:

DVD Min(MB/s) Max(MB/s) Average(MB/s)
ANSIC 2.381 2.386 2.383
W32 2.383 2.390 2.386
MMapped 2.524 2.528 2.526
Async I/O 2.384 2.408 2.399

從上面的結果你可以看到,硬碟部份差異不大。作者建議使用非同步IO的方法,一方面是非同步IO的方式是最穩定的方式,另一方面是可以同時啟動多個I/O的request。

結果…其實作者建議搭配另一種方式XD。其實很容易聯想啦,就是壓縮資料,畢竟在I/O的時候 CPU是處於idle狀態的。作者在此處利用了ZLIB而不是使用LZO。因為LZO並不支援串流格式。100MB 的資料被壓縮成64 MB。

底下是結果:

硬碟部份:

硬碟 Min(MB/s) Max(MB/s) Average(MB/s) Improvement %
ANSIC 59.067 69.384 67.558 +39%
W32 67.797 69.396 68.446 +41%
MMapped 52.247 53.562 52.980 +10%
Async I/O 68.634 69.832 69.242 +42%

DVD部份:

DVD Min(MB/s) Max(MB/s) Average(MB/s) Improvement %
ANSIC 2.469 2.476 2.472 +3%
W32 3.437 3.467 3.455 +44%
MMapped 3.713 3.724 3.720 +47%
Async I/O 3.464 3.475 3.470 +44%

結論)

作者推薦使用非同步分式,雖然他在每個特定的情況下都不是頂尖,但是他是最平均的方法。並且在使用壓縮格式的檔案方面也是最快的。