Sunday September 11, 2005

找對書，多執行緒不再避之唯恐不及
科學家對於人類大腦的運作方式，目前仍存在許多爭議。但是許多經過科學實驗的證據顯示，人類的大腦是以平行的方式工作。即使如此，筆者不免想起，大學時期選修作業系統（Operation System）這門課時，當老師教到Task、Process、以及Thread，一群大學生才剛搞懂哲學家的吃飯問題，緊接著關於Thread的演算法討論，搞得同學們一陣千頭萬緒，紛紛中箭倒地。

從此，計算機相關科系的畢業生，避多執行緒唯恐不及，能夠不用就不用，就算不得已一定要多執行緒一番，也不見得可以撰寫出真正發揮出多執行緒優勢的程式，大部分所見到的，都是存在著隱憂的程式碼。

Win32多執行緒應用程式開發
過去，Win32應用程式當道的時候，要學習如何使用Win32 API所提供的多緒執行功能，Addison Wesley的《Multithreading Applications in Win32：The Complete Guide to Threads》這本書絕對是眾多Windows程式設計專家推薦的好書，這本書在1997年8月的時候，曾經由侯俊傑（侯捷）老師翻譯，碁峰出版《Win32 多緒程式設計》，以侯老師在寫譯上的高品質要求，這本書自然是當時國內Windows程式設計師手頭上必備的一本書。

8年過去了，現在的系統開發主流是Web應用程式，不再是Windows應用程式，這本書也絕版了，但是其參考性，並沒有因此而降低，如果您的工作還是需要在Win32平臺上開發多執行緒應用程式，想盡辦法也該試著把這本書找出來吧。

Unix多執行緒應用程式開發
相較於Win32平臺，Unix為另外一個作業系統的主流，Unix伺服器通常肩負著關鍵性任務，尤其在這個Internet的時代，躲在背後苦命工作的伺服器，十之八九採用Unix。即使伺服器等級的機器有再多的處理器和記憶體，仍然需要善用多執行緒的伺服器軟體，才能充分發揮其效用。因此，在Unix上開發多執行緒軟體，同樣是個重要議題。

然而，Unix只是一個統稱，其分支體系之複雜，非專家無法區分出Linux、FreeBSD、Solaris、Mac OS X這些作業系統之間的親戚關係。要在這些”類UNIX”的平臺上開發一個可以跨平臺的應用程式，絕對是一件非常困難且精細的事情，所以制定了POSIX Thread（簡稱PThread）標準，藉此降低工程師的負擔，Addison Wesley《Programming with POSIX Threads》這本書，也成為Unix上撰寫多執行緒程式的必備參考書。

除此之外，O’Reilly的《Pthreads Programming》也是另外一本不錯的參考書，這本書也曾在1997年11月，由一家早已不存在的『松格資訊』出版過中譯本。現在如果有人想要買一本來保存，可能真的得到光華商場的地下一樓，中古書店一間間慢慢地找，才有可能找得到。

雖然《Pthreads Programming》的評價沒有《Programming with POSIX Threads》來的好，但是作為一本入門書，筆者比較推薦《Pthreads Programming》，除了因為這本書廢話不多，一開始就切入主題之外，有更大的原因是因為，讀者只需要懂一些簡單的Unix 程式開發，就可以很快學會如何使用PThread。這兩本書，即使出版年份距今已有8年以上，對於目前還需要在Unix上開發多執行緒應用程式的人，一樣具有非常高的參考價值。

在這個Java與.NET的時代
如本文前面所提，這是一個以Web應用程式為主的時代，而採用的開發平臺，除了PHP以外，就屬Java（Servlet/JSP）與.NET）ASP.NET）。就算要開發Unix平臺上的應用程式，也開始有許多軟體採用Java（AWT/SWING）開發，如果要開發Win32平臺的應用程式，採用.NET（Windows Form）而捨棄MFC/ Delphi的開發者也不在少數。再這個時代，開發原生（native）應用程式變成了相對少數人才具有的技能。

不管是Java或.NET的Web應用程式開發人員，多半很少體會到多執行緒的好處，這是因為底層的Container已經充分利用多執行緒增加系統效能，而位於更上層的開發人員，雖然工作簡單了，但是也無形間喪失了學習多執行緒的能力。相較之下，使用AWT/SWING或Windows Form的開發人員，非得好好學習多執行緒，才能做出有效率的使用者介面。

教導如何在.NET下使用多執行緒的書本來就不多，筆者推薦MANNING的《.NET Multithreading》，如果是採用Java開發，那麼O'Reilly 的《Java Threads, 3/e》一樣是不錯的選擇。《Java Threads, 3/e》已經由歐萊禮臺灣分公司翻譯成中文版《Java Threads 深度探討》，雖然在翻譯上，很多英文長句都沒有經過斷句，就直接翻成一串很長的中文句子，但是整體而言，品質仍然不錯。

需要注意的是，《.NET Multithreading》非常適合新手入門，但《Java Threads, 3/e》並非如此，即使是第一章，採用的範例也稍嫌複雜，初學者可能看了老半天，仍會丈二金剛摸不著腦袋，筆者建議可以先讀讀Prentice Hall PTR的《Core Java 7/e, Volume2》裡面關於Thread的章節，然後再回頭看《Java Threads, 3/e》，如此才會效果顯著。

由於J2SE 5.0之後，Java在Thread上不再只是簡單的synchronized關鍵字配上wait（） 、notify（）、sleep（）等函式，還引進了Concurrency Utility，讀者在購買這兩本暢銷書時，別忘了購買最新講解J2SE 5.0的版本，才能學習到Java在Thread上的最新變化。

Thread人人會用，巧妙各有不同

話說戲法人人會變，巧妙各有不同。獨孤求敗用木劍就能夠與對手大戰七天七夜，平常人拿了倚天劍屠龍刀，恐怕也只能任人宰割。雖然多執行緒程式在撰寫上較為困難，但是本身並非一個非常大的議題。光知道每一種平臺對多執行緒的支援並非難事，但是如何運用這些基本元素，充分利用多執行緒的優點，恐怕在上述的書籍中著墨不深。

多半的人會認為，J2SE 5.0以前的Java，雖然支援多執行緒，但卻只是簡單的支援，只有J2SE 5.0之後，Java對多執行緒的支援才算完整，也才能做到許多過去很難完成的工作。但是當您看了博碩文化出版的《Java Multithread Design Pattern-Java多執行緒與平行處理》之後，有這樣觀念的人就會發現既有觀念大錯特錯。

這本原著以日文寫成，專門探討Java Thread的書籍，使用JDK 1.3為基礎，即使沒有J2SE 5.0所提供的花俏功能，一樣變出許多戲法。尤其是第一章後面的練習題，就算許多自認懂得使用Java撰寫多執行緒程式的人，或是為了認證考試熟讀Java Thread的人，非常有可能在做完練習題之後，才發現自己原來根本不懂Java Thread。

Thursday September 08, 2005

即 使目前手機內建的處理器運算能力已經高於幾年前的個人電腦，連線速度也比過去還要快，但是手機永遠是手機，在目前的手機設計無法突破之前，手機永遠只能有 一個無法滿足人類視覺需求的小螢幕，鍵盤上的按鈕永遠比需求少一個，更無法使用滑鼠來操控。這一點大大地限制了手機上所能開發的應用程式類型，因此，即使 理論上可以開發各式各樣的應用程式，礙於手機先天的特性，導致Java遊戲幾乎就是Java手機應用程式的代名詞。

Martin J. Wells所撰寫的《J2ME Game Programming》，正是一本可以滿足Java手機開發人員需求，又沒有上述書籍缺點的好書。這本書以MIDP內建的LCDUI為基礎，說明如何應用標準LCDUI API之中的低階模式來設計遊戲，本書也提到如何擅用Game API，減輕遊戲開發的負擔。

本書最有特色的部分，在於說明『如何讓您的Java手機程式賺大錢』，不像典型技術書籍只教導我們如何發揮某種技術的最大功能（當然，技術好與賣的好，本身還是有某種程度的關聯）。因此這本書有特別的章節介紹移植（porting）相關議題，因為程式能夠在越多手機上執行，目標市場才會越大，才會有越多人購買。本書亦有章節特別介紹本地化（Localization），我們所開發的程式如果能用越多國家的語言呈現，您的客戶就不會僅侷限於中文使用者，使用日文、俄文等其他國家的人，一樣會讓您賺進更多鈔票。

在諸多遊戲類型中，可以讓人隨時開始享受樂趣，又可以充分娛樂的遊戲類型，莫過於動作遊戲，動作遊戲中，最吸引人的，大概就是射擊類遊戲了，筆者想起學生時代，總會被射擊遊戲的華麗聲光效果吸引，無論是家裡的遊戲卡帶，或是貢獻給外面遊樂場的硬幣，都以射擊遊戲最多。

要如何設計好的射擊遊戲，如何完成裡頭超炫的武器及特殊技，都可以在松浦健一郎所撰寫的《射擊遊戲演算法與程式原理（Shooting Game Algorithm Maniax)》書中，得到很好的答案。絕大多數的人都可以同意，日本人對於射擊遊戲的設計，已經到了爐火純青的地步，這本書原文以日文撰寫成，本來就是一本開發射擊遊戲的必備寶典，加上林世榮、黃政凱先生優質的翻譯，讓中文讀者可以享受到和原文一樣的品質。

本書雖然以C/C++為開法語言來實做演算法，但是幾乎沒有用到C/C++的特性（例如:函式庫、指標），這些程式碼大部分可以在不經修改的情況下，全數通過Java編譯器的編譯，這對Java語言的使用者是一個福利。

最後，我們講到手機平臺的不一致性。許多人會問，Java不是號稱跨平臺嗎? 為什麼還會有不一致的情形發生呢? 這是因為手機先天上的多樣性，比方說螢幕的大小，按鈕的配置，解析度，色深等，處於百家爭鳴的情形，這是一個很難改變的現實（如果所有的手機都跑Windows，外觀都大同小異，這個世界肯定無趣許多）。因此，即使Java有再好的架構，也無法讓程式完全的跨平臺（可以執行，但是會怪怪的），這也是為什麼《J2ME Game Programming》這本書需要花許多篇幅討論移植問題的原因。

再者，每家手機廠商都會為自己的Java執行環境增添特殊的功能，一來綁住開發人員和使用者，一來可以讓Java程式更能夠發揮手機的特性（例如:照相機、藍芽、多媒體等），貼近手機的特色。因此，如果只想開發一般的Java手機程式，上述的書籍就已經足夠，但是要發揮各廠牌手機的特色，就必須多閱讀官方釋出的技術文件，Nokia的手機就到Forum Nokia尋找技術文件、SonyEricsson的手機就到SonyEricsson官方開發網站、Motorola的手機就到MotoCoder網站。

但是，藉由技術文件取得的資訊畢竟是離散的，要學習完整的知識，還是需要一本專門介紹的書才可以。市面上唯一一本專注特定廠商的Java開發專書《Developing Scalable Series 40 Applications : A Guide for Java Developers》，以Nokia Series 40手機的特性為基礎，說明如何開發Java應用程式。

Tuesday September 06, 2005

IT的世界，真的進步了嗎?

『在過去的這10年之中，IT界大體上沒有什麼太大的變化。』

大多數朋友聽到以上這句話，或許會深深不以為然。『誰說變化不大? 每天推出一些新技術、新名詞，把我們技術人員搞的昏頭轉向，東西學也學不完! 已經心中已經萌生放棄一切改賣鹹酥雞的念頭了!』。如果您一樣無法同意筆者的論點，那麼底下我想試著說服您。

萬變不離其宗

把自己過去所學拿出來，靜心地想一想，這些所謂的新技術、新名詞，真的是讓人耳目一新的東西嗎? 有人說Web Services是新東西，其實只是過去的RPC (Remote Procedure Call)技術，如CORBA、COM、RMI等的變種，基本原理根本沒改變，幾乎僅是將原來二進位的資料傳輸方式改用XML罷了。有人說JDO、EJB、Hibernate是新技術，其實這些不過是基於O/R Mapping概念的實現與改進。有人說Struts、JSF(JavaServer Faces)是新技術，然而這些Framework的設計，卻沒有偏離過MVC Design Pattern的概念，也從來沒有脫離過HTML的大門。還有最近幾年最困惑各公司CIO以及CTO的問題:『該選用Java Solution或.NET Solution?』、資訊相關科系學生最常問的問題:『該學Java或.NET?』，殊不知Java跟.NET本質上幾乎是一樣的東西，縱然應用上互有消長，卻沒有人會因為學了另外一個東西，導致難以融入另外一種技術，君不見國內某位Java界大師級人物，並非一開始就進入.NET領域，可是他對.NET技術的領悟卻高於其他早已進入的技術人員。更有趣的是，原本設計給Java的開放原始碼工具，也都跑出了.NET版，如Ant變成NAnt、JUnit變成NUint、Hibernate變成NHibernate。表面上水火不容的技術，私底下卻不斷地發生『和親』事件，眼光銳利的開發人員，一眼就看破假象，不會被官方的行銷語言唬的一愣一愣的。

那麼，到底什麼東西改變了?

那麼，為什麼會出現那麼多的新名詞困擾IT從業人員呢? 答案很簡單 – 因為抽象層越來越多。這些年來，改變的並不是技術的本質，而是為了讓開發工作更簡單，更有效率、更容易維護，所以不斷出現各式各樣的抽象層。什麼叫做抽象層呢? 簡單的來說，只要您所撰寫的程式碼，需要經過轉換才能執行，那麼這個轉換的工具就稱為抽象層。舉例來說，現在網頁上最火熱的Flash，裡面所使用的ActionScript，最後經過Flash的Runtime Engine解譯才能執行，所以Flash Runtime Engine就是一種抽象層。有人嫌Flash還是太難，所以發展了Flex、或是開放原始碼的Open Laszlo，開發人員撰寫的是XML，可是最後卻轉換成Flash呈現在網頁上，所以Flex和Open Laszlo就是一種抽象層。

抽象層的實例俯拾即是。

組合語言太難寫，那就發明更高階的C語言。C語言的指標太難搞，就搞個沒有指標概念的Java。Java還是太難，再用Java寫個Script語言，例如BeanShell。一層包一層，即使最後執行的指令還是與組合語言指令相距不遠的機器語言，但是開發人員至少與機器相隔了三重天。CGI太難寫，所以發展了Servlet。Servlet還是太複雜，沒關係，有JavaServer Pages。開發人員覺得JavaServer Pages還是太難，那設計一堆可以重複使用的Tag Library總行了吧。可是開發人員更希望像開發VB程式一樣，拖拖拉拉就可以寫出程式，只好再發展JavaServer Faces滿足開發人員的胃口。誰知道接下來還會以這些為基礎，發展出什麼新玩意兒呢? 開發人員所開發的動態網頁，哇~ 隨便講講又和最基本的HTML隔了四重天、五重天。於是，開發人員和機器隔離的越來越遠，真實地成為了世界上最短又最長的距離。而太多的層次，最大的缺點就是效能，不斷地轉譯，耗費更多的記憶體，也讓 2GHz的CPU，執行應用程式的速度，好像沒有比過去DOS時代的486快多少。就好像一個國家，如果政府機構一層又一層，行政效率肯定不高，而且還會浪費公帑。

抽象層帶來了什麼好處?

雖然說抽象層會造成效率的下降，系統資源的耗損，可是卻帶來了一個很大的優點 – 彈性。彈性可以展現在很多面向上，對Java開發人員來說，展示彈性最基本的地方莫過於Java本身的Reflection機制，乍看之下，Reflection和C++所具備的RTTI(Runtime Type Information)類似，不過Reflection機制卻可以帶來更有威力的應用。一般而言，實作系統程式(Application Server、Container、IDE等)的工程師比較有機會用到Reflection，一般的開發人員很少有機會體驗Reflection所帶來的好處。甚至因為誤用，以為做出了一個非常有『彈性』的系統，結果卻是一個太過『鬆散』，難以維護的系統。知道Reflection能夠怎麼用，以及如何正確地使用，就是一個重要的課題。Manning出版社所出版的Java Reflection in Action正是一本這樣的書籍。薄薄的273頁。道盡所有和Reflection有關的議題，很多深入的知識讓其他書籍難以望其項背。

本書一開始就介紹Method Object，以及Method Object所帶來的動態呼叫(Dynamic Invocation)功能，讓開發人員可以在程式執行時期，先查詢類別所具備的Method，然後再決定叫用哪一個Method。充分讓讀者享受到Reflection的強大威力。接下來，作者為大家介紹Field Object，這是一個可以在執行時期得知物件所具有的欄位之功能。此功能的重要性在於，Java的序列化永續儲存功能(Serialization)，或是我們在整合開發工具之中所看到的Property Sheets，都是原自Field Object所具有的功能。從這裡開始，讀者開始接觸系統程式(System Programming)的實作。

作者在本書中，花了兩個章節，解釋類別載入器(Class Loader)以及動態載入的功能，可以讓讀者更了解Reflection功能的來龍去脈。在本書中，最重要的，莫過於講述Java Dynamic Proxy的章節，這大概是眾多Java相關書集中，將Dynamic Proxy解釋的最清楚的一本書。正常的Java程式設計師，會接觸到Dynamic Proxy的少之又少，可是，它卻又在我們的生活中扮演重要的角色，舉凡EJB技術與JAX-RPC技術中常常用到的Stub/Proxy，或是單元測試工具JUnit，都有Dynamic Proxy的存在，如果您想知道這些技術如何運作，那麼這一章是絕對不能省略的。

在本書最後兩個章節，作者利用一個章節說明Reflection所帶來的缺點 – 效能降低，該如何去量測與面對，讓開發人員不至於『言必稱Reflection』，結果造成一個沒有效率的系統。而最後一個章節，作者說明了J2SE 5.0之後，JSR 14 Generic以及JSR 201 Language Extension在Reflection所帶來的對應改變，更談到了各種具有Reflection特性的Java競爭者(最大的當然是C#)，讓大家了解其他語言在Reflection機制上與Java的差異性。作為一本介紹Java Reflection的書籍，本書可以說是『鞠躬盡瘁』。 

更多的抽象層，最後世界會變得如何呢?

Monday September 05, 2005

國內有一家知名的老牌出版社，過去出版了很多經典的老書，包括Windows作業系統核心、CPU保護模式等，幾乎每本都膾炙人口，可是近幾年卻沒有類似的出版品問世。筆者對該出版社的轉變感到非常疑惑，所以逮到機會就詢問該出版社的朋友，他們給我的答案是，過去的IT從業人員，看到任何講述特殊技術的書籍，或是看不懂的書名，不管如何，一定會買一本回家，找機會學習。而現在的IT從業人員，見到看不懂的書名就避之唯恐不及，買書都是以可以最快找到他們所要的結果為主，而這些朋友在學生時代，通常只購買能夠最快找到課堂作業答案的書籍。

其實這種情況的演變，並非現代IT從業人員的錯。在過去，開發人員可以直接在DOS下叫用中斷，直接和機器溝通，在Windows下，最有效率的方法就是直接呼叫Win32 API。而隨著時代的進步，軟體越來越複雜，整個資訊科技的分枝越來越細，再也沒有任何一個人有能力搞懂所有的技術，就像現代西方醫學的分類，內科醫生對泌尿系統的了解比不上泌尿科醫生，泌尿科醫生對腎臟的了解，也比不上專攻腎臟的腎臟科醫生。懂得作業系統運作的人不見得了解Java虛擬機器如何運作，而知道如何實做Java虛擬機器的人，也不見得可以寫出好的Java應用程式。所有的開發人員和真正運作的機器之間，隔了一層又一層的抽象層。這些抽象層之所以產生，就是為了讓開發人員『不要管底層怎麼做』，可以快快樂樂地開發應用程式。於是，Java和.net變成顯學，在這個以Web應用程式為主的時代裡，ASP.net和JavaServer Faces變成顯學中的顯學，卻鮮少人會問『那麼CLR Hosting怎麼實現?』、或是『如何實作一個J2EE Web Container?』因為這些問題沒有急迫性，就算不懂，對薪水根本沒影響，如果花時間去窮究，反而專案惠趕不上時程進度。

即使如此，作業系統還是每天出現在我們生活中，我們買來的硬體要能夠幫我們做點事，非得先灌好作業系統才行，不管是Windows、Linux、FreeBSD、或是Solaris x86版。撇開組合語言不談，要在每種平台上開發出最有效率的應用程式、或是發揮該平台所賦予的所有功能、甚至想要產生一個抽象層讓其他人快快樂樂地開發應用程式，那麼C或C++無疑是最佳選擇，這是一個與機器隔閡最少的位置。當您選擇了這條路，雖然少了現代高階程式語言所附的豐富函式庫(Java Class Library、.NET Framework)，很多功能都要自己親自動手，但是也進入了一個前所未有的發揮空間。既然這是一個離機器最近的位置，開發人員跟機器之間只隔了一個作業系統，這個時候，了解作業系統的運作就變得非常重要。

市場佔有率最高的作業系統

如果您所從事的平台是目前佔有率最高的Windows平台，Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server 2003, Windows XP, and Windows 2000這本書就是必備書籍。這本書經過四個版本的演進:

Windows NT for Open VMS Professionals

Inside Windows NT, Second Edition

Inside Microsoft Windows 2000, Third Edition

Microsoft Windows Internals, Fourth Edition

每一次改版，作者都將Windows作業系統最新的改變與資訊做了詳盡的說明。作者之一的 David A. Solomon，早期在Digital Equipment Corporation，將近10年的時間從事VAX/VMS的開發工作，後來全心轉移至Windows NT開發人員的教育訓練工作(曾經有人說，WNT就是從VMS三個英文字母各自向後偏移一個字母而來)，業界一直認為Windows NT和VMS關係匪淺，因為Windows NT的開發人員很多來自Digital Equipment Corporation，尤其是VMS的首席設計師，也是Windows NT設計小組的成員。從這本書的版本演進，大體上可以看出一個輪廓。

來勢洶洶的小企鵝

除了Windows作業系統之外，市場上公認最具有淺力的大概就是Linux作業系統，要能夠理解Linux Kernel，首推Understanding the Linux Kernel, 2^nd Edition這本書，不過這本書於2002年出版，講解的是2.4版的Kernel，而目前最新的Kernel版本為2.6，因此稍嫌老舊了些，即使如此，並不影響這本書的可讀性，作為一本介紹Linux Kernel的入門書，這本書有其獨特性。閱讀此書的時候，建議可以搭配O’Reilly的另外一本書Linux Device Drivers, 3rd Edition為輔助，這本書第三版於2005年2月出版，講的是2.6版Kernel上的驅動程式開發，大家都知道驅動程式的開發和作業系統內部運作有密不可分的關係，因此這本Linux Device Drivers, 3rd Edition，有很多地方足以和Understanding the Linux Kernel, 2^nd Edition相輔相成，彌補一些新舊版Kernel上的差異，或者作為彼此書中主題的輔助和延伸。

專家們喜愛的小惡魔

另外一個廣為人使用的Unix作業系統，就是以一個小惡魔為圖騰的FreeBSD了。FreeBSD以嚴謹著稱，雖然並非各種新軟體都能夠立刻找到FreeBSD的版本，但是FreeBSD的穩定性，讓很多專家們愛不釋手，尤其是目前火熱的MacOS X作業系統，其核心Darwin，有很大的部分也是來自於FreeBSD的Kernel。所以不管是想研究FreeBSD或是MacOS X作業系統的朋友，這本The Design and Implementation of the FreeBSD Operating System肯定可以帶來最多幫助，專門介紹Linux Kernel的書有許多，但是介紹FreeBSD Kennel的書僅此一本。

開放的太陽

Sunday September 04, 2005

什麼? 拿Java來開發遊戲!!

        如果有一天，某個軟體開發人員對遊戲軟體設計產生了興趣，想找個業界的朋友詢問遊戲軟體的開發經驗，第一個問題一定是:『我該選擇哪一種程式語言呢?』，通常得到的答案只有三個:

1.      C

2.      C++

3.      C 或 C++

這是非常合理的答案。開發人員不想接觸太低階的組合語言，可是又希望搾乾硬體的每一分資源，C或C++是最能滿足這個條件的語言。Java語言出現在1995年左右，當時的硬體條件，加上早期Java本身的成熟度的不足，導致『Java == 龜速』這個恆等式烙印在很多開發人員的心裡。所以自然無法成為遊戲開發的主流語言。

Java可以拿來開發遊戲嗎?

        筆者常常開玩笑說:『Java是帶業出世的!』，所謂的『業』指的就是『業障』，也就是Java需要JVM才能夠執行，與生具來就很難在正常的情況下，擁有比C或C++還要出色的效能。這幾年來，JIT Compiler技術的改良、HotSpot技術的精進，還有許多探討如何撰寫更有效率Java的書籍充斥於書店，加上硬體的進步，其實Java早就具備開發遊戲的實力了，只是需要更多成功範例來說服開發人員。關於成功範例，可以在SUN官方網站 http://java.com/en/games/ 看到各種以Java開發遊戲的精采範例。如果您是遊戲開發人員，那麼SUN官方針對開發人員所成立的技術論壇http://community.java.net/games/，也是一個必去的好地方。

        如果讀者仍然對Java是否能夠製作遊戲心存疑惑，筆者必須說:『只要有心，人人都可以用Java製作出好遊戲』。就如同大多數人認知的Script語言，也是一種速度很慢的語言，很少人拿來製作遊戲，如果您看過使用JavaScript所設計的的星海爭霸(http://elf.jsgame.net/sc/)，多少可以體會，語言的原罪並非無法克服。

講解Java開發遊戲的好書

主流的C、C++行之有年，許多工具、函式庫、關於遊戲設計的書等，都是以C、C++為主，像是著名的Game Programming

Gems 系列(目前原文書出到第五集，中文翻譯書名《遊戲程式設計精華》，目前出到第二集)。Java遊戲設計的書，在原文書方面雖然比不上C、C++來的多，但是也夠令人耳花撩亂，品質差異甚大。反倒是中文翻譯書，通常挑選品質較佳的原文書進行翻譯，在台灣也大多由品質受到肯定的出版社進行翻譯，這算是身處台灣的幸福。筆者挑出幾本原文與翻譯品質一樣好的幾本書，與讀者分享。

英文原文翻譯書:

從做中學：手機遊戲程式設計 (Beginning Mobile Phone Game Programming) /上奇

大師談 Java 遊戲設計 (Developing Games in Java) /上奇

日文原文翻譯書:

Java Game Programming 建立遊戲的演算法與框架 (Java Game Programming Algorithm and Framework) / 博碩

還有更全面性的好書嗎?

        目前市面上的遊戲，不管是PC遊戲，或是遊樂器遊戲，除了講究2D、3D、聲光效果、更強調善用網路，好比目前最風行的線上遊戲(On-Line Game)，就充分運用了網路，達到多人共樂的效果。然而，恐怕得買上5-6本書，才能夠學到開發這些現代遊戲所需要的技術。O’Reilly所出版的Killer Game Programming in Java就是這樣一本書。本書接近1000頁，共有四大主題: Java 2D、Java聲音處理、Java 3D、Java網路程式設計，並在附錄介紹如何利用install4j或Java Web Start，讓使用者方便地安裝所撰寫好的遊戲軟體。除了人工智慧(AI)之外，這本書幾乎涵蓋了所有遊戲開發所需要的知識，而這本書的不足，可以用O’Reilly的另外一本好書AI for Game Developers (O’Reilly台灣分公司有翻譯計畫，中文版名稱為《遊戲人工智慧》) 彌補之。

        Killer Game Programming in Java的作者，在第一章就列出了所有開發人員對於Java是否可以開發遊戲軟體的疑惑，包括『使用者較難安裝Java程式』、『Java速度太慢』、『Java太高階了，很難發揮硬體效能』、『有人真的拿Java開發應用程式嗎?』等議題，一一釋疑，並列出了許多相反的觀點，以及可以實證的網路資源。接著，作者就從遊戲的基本程式結構開始，介紹Java影像處理、2D圖形處理、聲音處理。到此，讀者對遊戲開發會有個基本的認識，也可以寫出一個簡單、並具有聲光效果的Java遊戲。接著作者採用標準的Java 3D API，講解3D圖形處理，這一個部分，是所有關於Java 3D的相關書籍之中，講述的最精采的一個部分，筆者認為這也是本書最有價值的部分。最後，作者介紹Java網路程式設計，並延伸前面章節所介紹的3D遊戲，改良成網路3D遊戲。作為一本介紹Java遊戲設計的書籍，筆者相信這是目前市面上就有參考價值的一本書。

筆者認為,Regular Expression是非常值得學習的東西,

從簡單的UNIX指令,程式語言,到XML Schema,SQL都有.

如果花點時間研究Regular Expression,會發現這是

投資報酬率很高的一種玩意兒

充斥於計算機領域的Regular Expressions

        筆者第一次接觸到Regular Expressions(中文翻譯為『正規表示式』，接下來的內容接採用中文翻譯名稱)，是在大學時期選修編譯程式(Compiler)的時候。後來開始學習Unix作業系統管理，常常用到的Unix指令，也都支援正規表示式。因為工作的關係，常常需要處理文字檔，所以開始學習Perl，這時發現正規表示式真是個好東西，當大量機械化的文字處理工作迎面而來，正規表示式大幅減少了工程師的負擔。現在最重要的兩個平台 - .net與Java，也不約而同地提供可以支援正規表示式的API(Java在JDK 1.4之後才開始支援)。對於一個IT從業人員，正規表示式異常地重要，連Oracle 10g資料庫都開始可以在SQL/PLSQL語法中支援正規表示式，可見正規表示式是一個多麼有趣，具有多用途的工具，堪稱『IT從業人員必備武器』之一。

什麼是正規表示式?

正規表示式並非一個程式語言，而是一種專門用於比對以及置換文字的機制，幾乎各種程式語言，或是涉及文字處理的軟體工具都支援正規表示式。舉例來說， 我們在想要搜尋或取代某個檔案(或字串)當中的滿足某些條件的部分，我們就可以利用正規表示式，指示計算機以較嚴格或較寬鬆的條件去處理。一般Windows使用者所使用的編輯器的『搜尋』、『取代』功能只能單純地找出某個數字文字序列的存在(例如:搜尋”port”，可能找出”important”)；或者我們想一次找出Sun、SUN、sun三種大小寫狀態不同的文字，並忽略掉其他大小寫狀態的文字(sUN、suN…等)，這些都是傳統的搜尋取代很難做到的，但是只要利用正規表示式的機制，這些複雜的搜尋條件都可以迎刃而解。

學習正規表示式的好書

正規表示式發展了很長的時間，卻由於缺乏一個統一標準，造成各種環境下的正規表示式語法都不盡相同，無法達到『只寫一次，到處通用』的境界。雖然正規表示式的學習曲線不長，但是即使有了正規表示式的基本觀念，卻往往因不同環境之間的語法差異，讓工程師傷透腦筋。要一次學好正規表示式，O’Reilly的出版的Mastering Regular Expressions絕對是上上之選，要應付未來各式各樣不同語法的挑戰，同一個作者所撰寫的Regular Expression Pocket Reference(O’Reilly中文翻譯本 - 正規式速查手冊)更是不可或缺的工具書。

作者在書中第一章，就展示了正規表示式解決『實際問題』的能力，並建議我們把正規表示式當作是一種簡單的語言來學習。所以把正規表示式的結構和語法做了詳細的解釋，讀者可以發現，只要需要對文字做搜尋或取代，正規表示式就可以派上用場，而且幾乎無所不能。從第二章開始，作者讓正規表示式結合Perl，做點實際的應用，像是處理Email的內文(過濾、搜尋)、或是程式設計師常常需要對使用者所輸入的參數做處理，這些過去我們直覺需要寫程式來完成的工作，其實很多都可以用正規表示式漂亮地幫我們解決掉。第三章到第五章，作者帶我們深入正規表示式的運作規則，並介紹許多實用的技巧。第六章之後，開始介紹正規表示式在各種程式語言上的運用，由於可以運用正規表示式的範圍實在太大，作者僅僅挑選了Perl、Java、以及.net進行深度解說，其實已經可以滿足目前大多數工程師的需求。

一輩子都可以受用的東西

趕羚羊的世界總部是專門發表軟性文章的,

而這裡是發表技術文章的. Orz