大逃殺

大逃殺

如果你只看過電影版的大逃殺 , 你會覺得故事背景設定的有點扯 ,

國家(某些特定的單位的主導者)因為認為國家的競爭力衰退 , 是因為和平的日子大家過的太爽了 ,

所以社會出現了太多米蟲 , 每個人渾渾噩噩的過日子 , 為了提升競爭力 , 讓人回到有生存競爭的心態 ,

選出一個班級的少男少女 , 然後放到一個小島上 , 每個人給定不同的武器或是工具 , 然後給定一定的時間 , 要彼此之間互相殘殺 , 然後到了時間之後 , 如果生存者超過 一個人 , 則所有的生存者就全部殺掉...

(這是大逃殺I 電影的基本設定 )

一開始 看到 大逃殺 , 是在租書店租到 大逃殺 II ,

看完之後 , 想說看看有沒有 大逃殺 I 可以看 , 結果租書店沒有 , (人的天性 , 就跟看到星際大戰 IV , 你就會想看看 那 I , II , III 的內容是蛇麼)

不過呢 , 有 漫畫版 的大逃殺 I , 大概是 12 還是13集 , 所以就先看了(漫畫版的名稱好像叫 生存遊戲)

後來逛到光華商場時 , 發現了 特賣片 一片 99 元的大逃殺 I ,

買回來看過之後 , 又上網去看了一下其他人對於大逃殺 I 電影的討論 , 發現評價不是很好 ,

因為我看過電影版 I , II , 跟 漫畫版 , 所以可以知道為何大家的評價不是很好

原因在於 漫畫版的大逃殺 , 裡面幾乎多多少少都會有每個角色的情緒 , 背景 的相關描述 , 即便是配角也都會有 , 而電影版的大逃殺因為角色太多 , 所以刪掉了很多角色的背景描述或者是內心想法的片段 , 當這些片段 都被刪除之後 , 剩下的就是很表面的 , 角色之間的彼此打打殺殺 , 甚至因為刪除了某些片段 , 所以你會覺得電影版 I  角色或者是劇情的轉折之間會有些莫名其妙或者是突兀．

不過 , 基本上來說 , 電影版 , 已經刪掉很多 情色片段 , 跟血腥片段了 , 電影版仍然是屬於 成年者才能看的

而漫畫版就更 情色跟血腥了...(基本上 大逃殺 完全不適合給 未成年人 觀看)

說一下，其中的幾個差別，

電影版 大逃殺 I 中負責指揮行動的那個老師 , 是一個在家被女兒嫌棄 , 在校被學生看不起的老師 , 有些討厭 , 卻又有些可憐 ,

漫畫版 , 大逃殺 , 指揮行動的老師 , 完全是個豬頭 , 兼心理變態 , 完全是以看到學生的死亡為樂 , 期間還強暴了 主角在育幼院的女老師(電影版 沒有這一段)

大魔王級角色1

另外像 , 相馬光子 , 剛剛提到的情色部分 , 都來自於她 ,

漫畫版中 , 有不少她的片段描述 , 她也算是大魔王級別的角色 , 為了求生存獲取金錢 , 不惜犧牲肉體 , 進行援助交際 , 或者是充當大哥的女人 , 極度保養自己的肉體 , 所以在島上還有辦法從容的洗澡跟換美美乾淨的衣服 , 同時間也是個變臉快速 , 有雙面人的性格 , 一個是真實自我的狠角色 , 一個是裝做清純可憐的少女 , 還挑撥 幾個男人為她拼鬥 , 在過程中 , 也可以出賣肉體去騙取男人的信任 , 分派到的武器是鐮刀 , 喜歡用鐮刀 , 割斷別人的喉嚨 ... , 甚至在最後碰到另一個學生 桐山和雄 時 , 也不惜希望能夠出賣肉體 , 來求取生存....

電影版中 , 相馬光子 這個算是魔王級角色的戲份就被刪的一踏糊塗 , 當然也沒有什麼情色部分出現 , 只有在相馬光子 要死亡時的記憶片段 , 表示她會那麼求生存 , 是因為小時後被母親出賣給戀童症的變態中年男子 (基本上這一段就很突兀 , 因為前面的片段中 , 並沒有任何著墨於相馬光子 性格與行為的描述 , 但是漫畫中有  )   , 基本上跟漫畫差很多 , 已經是亂改的程度了

大魔王級角色2

桐山和雄(天才學生)

漫畫版中 , 他是家中極度有錢的學生 , 與其他同學也是同窗三年 , 他沒有人類感情與情緒的存在 , 但是是一個高度天才 , 廚藝 , 音樂 , 武術 , 運動 , 幾乎是過目即學 , 而且因為沒有人性 , 所以也是超級殺神 , 有大半的學生都被他追殺 , 而且成功的殺死

在他死亡的片段中 , 才說明 , 原來他的沒人性 , 是因為小時候出車禍 , 有碎片刺入他的腦中 , 所以導致他的無情緒 , 無人類感情的情況

電影版中 , 桐山和雄 變成是一個轉學生 , 也沒有他的背景描述 , 純粹只是出現他拿著武器殺殺殺 , 然後最後被 其他人殺死

(基本上也是被亂改一通的角色)

漫畫中 , 七原秋也 跟 中川典子 是逃出島上 , 用的好像是 川田章吾 聯絡到的船隻逃離 ....

(然後川田章吾 掛了)

跟電影的結局不太一樣

另外還有亂搞的地方是

電影版中　，　中川典子　跟那個老師好像存在若有似無的關聯(有點像是 中年男子 著迷於 少女一般)，所以那個老師最後才會放過七原秋也 跟 中川典子

另外像電影 大逃殺 II , 就存純只是為了滿足 大逃殺 I 電影的影迷衍生出來的產物 ,

規則修改的更嚴苛 , 相同座號的男生跟女生都被配成一組一組的 ,  只要一組中的其中的男生或是女方死去 , 同一組的倖存者的項圈也會爆炸 , 就是要死兩個一起死

以下說的是漫畫版的部分

大逃殺 吸引人的地方在於 人性的與角色性格描述 , 而不在於中間過程的打打殺殺 ,

只是電影版 , 只能表現出外在的打打殺殺 , 所以導致有人對電影 大逃殺I 的評語不是很好

例如 , 遊戲規則 , 限定只能有一個人生存下來 , 所以你會發現 ,

有的平時性格可能很懦弱的人就會先下手為強 , 因為他怕大家會先對他下手

有的人會想要整合大家 , 聯絡大家 , 看看能不能找出一個方法 , 大家一起逃出去...

又因為規則的關係 , 所以有的人看到有其他人出現 , 就認為對方是要來殺自己的 , 就先攻擊再說

人與人之間的信任感 , 在生死關頭有時就是那麼的脆弱...

也有一對情侶檔 , 因為女方不願意為了生存下來而殺人 , 所以男女雙方一起跳海殉情...

這些都是人性的掙扎 ,...電影版中 , 可能是內容太多了 , 為了趕時間 , 這些你完全不會感受到

今天到書局去看到了 大逃殺 小說的中文翻譯 , 一時昏頭 , 竟然沒有買....後悔中

我想小說中的情節 應該會比漫畫還要多...

如何分辨不佳的程式設計網站

如何分辨不佳的程式設計網站

2007/06/03 01:38

程式設計的生涯中 , 沒有人能夠保證自己是什麼都會什麼都精 ,
所以尋找一個好的程式設計的相關參考網站也是一個重要的項目
針對學習 Java 的同好 , JavaWorld 算是一個不錯的參考網站(http://www.javaworld.com.tw)
它的討論區都有相關人員在管理 , 另外發問的人員的問題 , 以及回覆 , 品質跟等級都較高...


基於隱惡揚善的原則 , 好的組織或人事物 , 我們就直接把全名公告 , 不好的組織或人事物 , 我們只好描述其事跡 , 讓大家自己去判斷是非對錯 , 不寫出名稱
本篇的主題是: 如何分辨不佳的程式設計網站

參考一下 , 某程式設計網站 , 宣稱有 16 萬位系統開發人員 , 可彼此討論技術和解決系統開發上的問題
看一下內容 , 累積文章數 37 萬, 幫他計算一下 , 每個系統開發人員只累積了不到3篇文章
另外它宣稱的有16萬多位的系統開發人員 ,
進去討論區逛一下 , 你就會知道 , 一大堆學生在上面問問題的 , 問題類型大概是: 我們老師出了XX 作業 , 有沒有人可以寫範例給我看 , 或者是直接在上面發包的 , 要不然就是 有沒有人可以解說 XX 程式碼的意思 ,....
這些學生也都被涵蓋在 16 萬多位的系統開發人員 , 灌水也灌的太兇了吧...(比例有多少 , 看一下問作業問題的文章數有多少就可以猜猜看...)

另外如果再去看裡面的貢獻值 , 真正有解決系統開發問題的 , 只是少數的 不到 100 人
彼此討論技術?  那個站台 , 可以看到某些人直接對其他人以言論進行人身攻擊 , 已經到達觸法的情形了(例如間接的指控某些人有精神方面的疾病該去吃藥看醫生等等) 也沒有看到站台的管理人員出來管理

 (也只能說那站台的管理人員運氣不錯沒有被告 ,
 因為如果在網站上 , 有人進行犯罪 , 而網站經營管理者沒有處理 ,網站的經營者是必需要負起相關刑責的 , 也就是說 , 如果那個被進行人身攻擊的人對該站台經營管理者及 對他使用言論進行人身攻擊的人 提起告訴的話 , 那就有的看了)

會幫忙解答問題的只有少數幾個 ...但是看一下那些問題 , 有一半是學生的作業問題 , 也就是入門等級的問題 , 連技術問題或是系統開發問題都稱不上...

我看了那些失序的發言 , 只能說那個站台的參考價值不高 ,
彼此互助的氛圍也都沒有 , 看到的是某些人只在那裡耍嘴皮子打筆戰 , 不然就是講一些沒營養的內容或是 進行人身攻擊的 , 
一堆回覆內容都不是彼此幫忙解決系統開發問題或是技術問題的 ,
這種站台會被我歸為  "不佳的程式設計網站" , 因為參考價值為 0
有沒有好的回應文章或是主題 , 有 , 不過不多 , 要自己去大海撈針 , 如果你願意把 37 萬篇主題跟回應看完的話...



比較一下 JavaWorld  , 只要你公告不當的下載連結 或者是有不當的發言 , 管理人員會把你的公告刪除 , 避免違法之虞 , ...(比起某站台 , 完全是無政府狀態 , 真的是差太多了)
而JavaWorld他們的成員share 的比例比較高 , 多的是自主性的 share , 例如有人整理好的筆記 , 考試學習心得 , 或者是實用的程式及範例甚至是技術之間的討論

嗯, 舉 JavaWorld 為例只是因為老人家是用Java的 , 其他的像 ASP , PHP , ....等等其他應該也有不少不錯的站台 , 不過老人家我就沒有接觸了...

J2EE 設計樣式應用 一書的範例程式碼

J2EE 設計樣式應用 一書的範例程式碼

2007/06/02 19:23

J2EE 設計樣式應用 ( J2EE Design Patterns Applied )  一書的範例程式碼
這本書的原始出版社為 Wrox
老外寫的書 , 範例程式碼大都是放在作者的網站或者是出版社的網站上
可是這本書的範例程式碼
你到 www.wrox.com 這個網站上絕對找不到 ....

翻看 JavaWorld 的網站 , 有人提供他先前下載到的Sample Code的 個人超連結 , 不過被 JavaWorld 的管理者給刪除了(那個連結) ．[從這點可以看到 JavaWorld 是比較有在管理的 ]
(根據那篇文章的說法是 Wrox 的財務出狀況後 , 所以那本書的範例程式碼 , 就沒在 www.wrox.com 上出現了) ,

經過一番尋找 , 這本書的範例程式碼 , 可以在 Apress 這個出版社的網站上下載 ,
 ( J2EE Design Patterns Applied )
http://support.apress.com/signup.asp?bP=/books.asp?s=0%26bID=1861005288&supportFile=1861005288/5288.zip

範例程式碼就在上面請自己去抓，大小為　414 KB左右 , 國外有人反應抓下的檔只有 8KB , 後來發現是他們使用的 Proxy Server 造成的

工具軟體介紹 JAGO

工具軟體介紹 JAGO

這個軟體有兩個功能

一個是當作連線到圍棋Server的Client , 另一個功能則是當做 SGF 的編輯器

SGF 是圍棋棋譜檔案格式的一種

http://www.rene-grothmann.de/jago/

Java Go Client & SGF editor v4.9

如果你的 JAVA_HOME & PATH 有正確設定的話

只需在檔案總管 double click  這個檔 jago.jar

就可以執行

它的SGF editor 令人讚賞的地方有二 ,

一是變化圖的種類 , 它是使用圖型化表示

二是對於 sgf 裡面的棋評註解的編碼讀取 , 可以讀取使用簡體中文內容的 sgf檔

只需要設定編碼為 GB2312 就可以正常顯示 , 不需要去將 sgf 檔的內容去做任何修改

(如果你曾經在網路上有去尋找圍棋棋譜 , 然後使用其他的圍棋程式去開啟 SGF 確看到亂碼的話 , 

有一種可能是因為那個 棋譜檔案的編碼格式使用的是大陸簡體中文的編碼 , 所以開啟時顯示成亂碼 , 使用 JAGO 就可以直接檢視簡體中文)

[原始文章日期: 2007/03/03 13:24]

Web Services best practices

承續上篇關於WebServices的錯誤應用說明後 ,
來介紹一下Web Services best practices
以下內容出自 IBM Redbook : sg247257.pdf
Web Services Handbook for WebSphere Application Server Version 6.1
內容的Page.228(AdobeReader頁碼)
            Page.198(PDF頁碼)
提到關於~Generic best practices~
(1)Be WS-I compliant
(2)Use simple data types
(3)Avoid nillable primitives
(4)Avoid fine-grained Web services
(5)Avoid Web services for intra-application communication
(6)Use short attribute, property, and tag names
(7)Avoid deep nesting of XML structures
(8)Apply common sense (also known as being defensive)
第1點是要符合WS-I的標準
第2點是要使用簡單資料型別(就是一般的基本資料型別)
裡面的第4點提到 fine-grained 一般是直譯為"細粒" , 就是說到要避免過細的WebServices的使用
另外如(6)(7)就是關於XML傳輸的資料量的問題 , 太長的attributes , property , 太深的XML結構都會造成XML 資料量變大 , 而可能導致佔用大量的網路頻寬
此外還有(5)提到避免用於intra的應用程式的通訊 ,這點也說明了 , 不要濫用WebServices於系統的建議


世上沒有萬靈藥 , 沒有一種藥可以治療所有的各種病痛
技術與樣式也是一樣 , 需要看場合 , 看需要的應用 , 濫用技術與樣式不是好事
提出此篇來與前一篇 WebServices的錯誤應用來對照呼應

有興趣看完原文的人 , 可上 IBM 的紅皮書網站 , 下載上面提到的 PDF , 來看詳細內容

WebServices技術的錯誤運用

WebServices技術的錯誤運用

每當有些新的技術出來 , 就會有人把它掛在嘴邊 , 似乎是萬能丹
可是要小心不要落入錯用新的技術的陷阱中
WebService s? 現在已經不新了吧
隨便舉個應用的例子好了 ,
有些 FlowEngine的產品或是要與FlowEngine整合的系統 , 馬上想到要使用的方式就是 WebServices ,
這種想法有沒有問題呢?

首先要記得 WebServices
1.叫用遠端的服務 ,
2.參數的傳入與結果的傳回都是使用 XML 格式
叫用遠端的服務 , 看起來沒有什麼大問題啊?
事實上 , 如果你有點年紀有使用過 COM+ 跟 EJB 的話 ,
COM+ , EJB 也都是提供遠端呼叫的元件規範
在那個時候 , 就有人濫用這種方式而導致網路與系統效能的降低
舉例來說:
假設Server端有一個 COM+ 物件 X , 提供 methodA , methodB , methodC 三個 Function Call
而你有一個Client端程式的交易是需要呼叫 methodA , 然後呼叫 methodB , 然後呼叫 methodC,
那你會發現透過 TCP方式,你的網路呼叫的往返次數至少是6次,
如果你在Server端有一個 COM+ 物件 Y 提供 methodTran , method內部就是包含了 methodA , methodB , methodC的呼叫
而你的Client端程式去叫用 Y.methodTran 時 , 網路呼叫的往返次數只有 2 次
這中間對於效能就有影響了,網路往返的次數少,花費在網路上的時間就減少,積少成多,效能就變快了
此外在網路呼叫的次數上 , 也會影響網路的頻寬使用
所以在 COM+ 時代 , 就有人提出相關的使用樣式

類似的狀況, 在EJB也反映出來相關的問題 , 所以Core J2EE Patterns 樣式中 , 就出現了DTO(Data Transfer Object)
就是為了避免呼叫EJB的method 時 , 傳入傳回的都是單一的屬性值 , 但是卻要進行多次的網路呼叫,
將可以進行一次網路呼叫並且取回的結果封裝成一個物件傳回 , 為的也是相同的原因 ,
避免多次網路呼叫 , 系統效能會變差 , 並且影響網路頻寬 ,

不是要談 WebServices 嗎? , 怎麼開始講古了呢? , 講到 EJB / COM+ 去了?
再重複上面提到的 WebServices的基本要項首先要記得 WebServices 1.叫用遠端的服務 , 2.參數的傳入與結果的傳回都是使用 XML 格式當然這裡面有個潛規則就是叫用遠端服務如何叫用 是透過網路 , 看起來好像是廢話 , 沒有網路如何呼叫遠端服務?
剛剛談到了 COM+ , EJB 在提供遠端服務的 method 時 , 其中一個影響要素就是 網路
當然使用的網路協定還是基於TCP協定(HTTP/FTP/SMTP)
所以COM+ / EJB 碰到的問題 , WebService 還是一樣會碰到 , 就是不要提供過細的method服務

你可以想像有人可能會濫用過細的WebServices 然後用在可能是上千萬筆的檔案轉換上面(Ex:轉檔) ,
可能是上千萬 次的WebService Call, 這個除了帶來程式的效能很差的結果之外 ,
也可能會影響到網路的頻寬使用
記得上面提到 WebServices的要項2嗎? 2.參數的傳入與結果的傳回都是使用 XML 格式
也就是說如果你呼叫過細的method 服務 , 你需要傳入XML ,也需要傳回XML , 這樣的資料量 , 可能遠遠大於你真正要傳回的資料
這些會吃掉你的網路頻寬 , 而當網路頻寬被吃掉 , 就是其他別的系統可能也需要網路頻寬 , 卻因為網路頻寬不足而導致別的系統服務的效能
也變差
所以不要濫用WebServices ,
如果你不是把它使用在交易服務 , 而是許多細小的資料查詢上面的話 , 那你就是濫用了
回過頭來看 , 最原始的問題
"有些 FlowEngine的產品或是要與FlowEngine整合的系統 , 馬上想到要使用的方式就是 WebServices ,這種想法有沒有問題呢?"

那要看看你的 Flow Engine 的呼叫對象 , 到底是會呼叫非常多次細項的資料處理的WebServices 還是呼叫一次交易處理的WebServices
如果是前者 , 那我只能提醒你 , 你的系統可能會有效能不佳並且導致整個網路頻寬被佔用的情況
如果你的人員或是外包商中會提出這樣的系統設計的 , 也請注意 , 他們可能只是知道有個WebServices的技術可以用 , 但是卻不會進一步深思 , 用法有沒有問題

WebServices 不是不好 , 而是要小心的用 , 正確的用 ,
用的不好 , 只能說你再換一個 128顆CPU的主機(現在應該還沒有這種商用主機吧 , 誇張的說法)系統還是跑不快... 當然如果你的Server間的網路都改用光纖或許可以改善...
關於系統效能不佳 , 平台人員要求換機器那又是另外的主題了...
這篇主題中還有一個要點沒有提到的就是關於交易處理的部分 , 它也是影響系統效能表現的要點

不要說我舉的例子太蠢 , 不會有人犯這種蠢錯誤 ,
就是有看過 , 而且還不少...

分析與設計03-企業需求2

接續 分析與設計02-企業需求

上面提到了 , 有些項目是在進行系統分析與設計時 , 必須要一併考慮進去的

例如 如何降低系統維護人力的這個要求
有些系統常常只考慮正常狀況 , 但是如果發生了異常狀況 ,  則可能會需要大量的人力來進行後續的處理與作業 ,


又或者是說到了 Server 的Cluster 配置 , 這裡面就會牽扯到兩台或是多台Server 之間 , 關於 Web Session 的共用(或者是同步)等等．在進行系統設計時必須要稍微注意一下


舉例來說 , 有某廠商在設計排程程式時 , 根本沒有考慮Cluster的狀態 , 結果我們一問他們 ,
在Cluster 環境下 , 是不是會各跑各的(2台 Server上的相同工作各自執行) ,
結果廠商就說兩邊都會起來執行(有些工作是只應該被執行一次的 , 而不是兩次的)
或者是檔案的產生 , 因為有2 台Server就必須要考慮 ,

如果user由Server1 切到 Server2時 , Server2可能取不到剛剛 Server1上面的檔案 , 而導致失敗．
當然聰明的人馬上就會想到要將Server1 與 Server2 的檔案存取點是 mount 一個共用的Server3上的Share 路徑．這樣做也沒有問題．

只是這些其實是要再設計的時候就考慮進去的，因為這些細節會影響到日後各項細項的工作．