寫給大家的平面設計書

平面設計，一項平凡又艱深的課題

隨手翻幾頁後個感想
嗯，好極了
顯然看起來大家是包含了我，


內容：

書前半是用四項原則

• 相近 Proximity
• 對齊 Alignment
• 重覆 Repetition
• 對比 Contrast

並舉出實例來展現，

後半段則是講各種字型及大小造成視覺上的差異


心得：

貫通本書，大概感覺是
掌握設計基本原則
然後大膽實驗，用心體會

再來就是多做多看
聽起來跟台上老師的廢話一樣XD...

不過我還是有感受到一些設計原則

1. 留白：眼睛是需要休息的，連續讀字也是很累的
2. 邊線：所有的圖文字，都需要一條看不到的隱形線支撐
3. 對比：要一眼就看出有差異(例如12px的字對上24px的字)
4. 字型：原來字型還有自己所屬的Family

總結：

原來平面設計這麼博大精深，我還是回去寫程式好了 ...Q口Q

FFXI

FFXI(Final Fantasy 11)
http://www.playonline.com/ff11us/index.shtml

一個我玩了6年的網路遊戲
總遊戲時數快破萬了，也經歷過大大小小事
可是居然沒替它寫過任何文章，真是詭異

不過沒關係，從現在開始好了
先貼幾張近況照片




萬事起頭難，先這樣就好

輕快好Java(Better,Faster,Lighter Java)

最近在玩RoR 10分鐘架站
突然想到一個問題，

「如果不靠框架和IDE，寫一個有購物車的網站要會多少東西？」
嗯..Web API, HTML , SQL (Java就不用說了)

「如果不靠框架和IDE，寫一個結構良好有購物車的網站要會多少東西？」
OOP? Hibernate + Spring + Structs ?

「如果不靠框架和IDE，寫一個結構良好且有分析文件的有購物車的網站要會多少東西？」

OOAD? UML? JUDE? Word + Excel (文書處理也很重要阿)

「如果不靠框架和IDE，寫一個結構良好且有分析文件且美觀的有購物車的網站要會多少東西？」

CSS ? Dreamweaver ? Photoshop ? 照相技術?

「如果...」

好吧..真是夠了
於是又把這本書挖出來懷念一下

心得：

全書就只有五個宗旨

1. 保持簡單
2. 一次做好一件事
   
3. 力求通透
4. 開放擴充
   
5. 吃什麼像什麼

是阿，我老母也懂阿，這不是看起來跟廢話一樣
可是有寫過複雜一點程式(約一萬行上下)的人就知道
每一樣都好難

說實話，這種講玄學的書，我還不夠格寫心得
不過我可以提出一個我的經驗

有天，我接到個需求，一個別人的ASP程式需要call我的Java程式，
嗯，這是個不同語言溝通的問題
答案很簡單，顯然是WebService，
是阿，但是重點是我用的是UltraEdit，如何在純文字模式下建立WebService
SOAP,xml,WSDL,UDDI,AXIS...立即排山倒海而來
　
　奮鬥了一個下午之後，我真的受不了了
　「有人知道如何不用工具直接建WebService嗎？」
「．．．」（辦公室安靜無聲）

　「有人知道如何不用工具直接建WebService嗎？」
「＃※＃※＃※＃※」（JavaWorld又好多火星文了）

　當下我只覺得用FTP傳txt才是好主意
「這怪東西實在太複雜拉...囧」

總結：

我很喜歡這本書，
就同序所寫，這本是寫給「受挫的人看的」(沒錯，就是我！)
內容不一定每人都同意，不過我相信能不同意的一定是天才

每看一次心中就無比暢快，總算有人出來發聲了

昨天,今天,明天

小時候，我媽是個銀行會計襄理
工作的銀行後門就有個幼稚園
平時就把我寄放在那，下班後就一起回家

因為古時電腦不發達，銀行少，業務相對多
傳票支票現金疊的滿滿跟山一樣，常常都要忙到六點多才能回家，
所有人都一樣

每天放學到下班中間
一個小鬼在銀行裡面活蹦亂跳

「媽咪~~偶功課寫完了 -w-//」
「乖～拿這邊的白紙去畫畫，不要吵摟」
於是我拿了一堆印壞報表紙畫無敵鐵金剛

「媽咪~~偶肚子餓了 >o< ... 」
「乖～這裡有１０塊先去買麵包吃，不要吵摟」
於是我買了四個小餐包，吃的渣掉滿地

「媽咪~~好無聊想回家睡覺了 zzz ... 」
「乖～先去後面趴著回家在叫你，不要吵摟」
於是不知誰的辦公桌被我沾滿口水

沒錯，是每天


連帶童年也分非常的銀行文化

那時不過六歲，我知道傳票跟支票的差別(因為叔叔都叫我幫忙拿)
那時不過六歲，我知道什麼叫會計年度(因為那天都好晚才能回家)
那時不過六歲，我知道開關金庫的方法(因為關好門才能回家)
那時不過六歲，我知道哪些數字容易混淆，比方說:17,06 (因為阿姨都叫我幫忙抓)
那時不過六歲，我知道會計襄理的章要蓋在支票的哪格(因為我媽蓋不完叫我幫忙蓋)

幼小的記憶真是好蠢，是吧
但我相信不只我一個


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


歲月不饒人，今天，銀行滿街而立，科技進步，網路發達，
每個行員加班都是推業務，
誰還對帳？誰還對傳票？誰還戴眼鏡仔細看17跟06？

我以為不會有這種故事了，那只是個時代的悲劇

直到我看到ＸＸ軟體公司的一個精美桌上月曆，
每個月份都有一幅員工子女畫的圖，還有寫給父母的話

爸爸都很晚回家／媽媽在家還工作／一星期見不到幾次面／假日都沒辦法帶我出去玩
1-12月都差不多內容

我驚覺，故事不過換個地點罷了
而且內容更加驚心動魄，
只慶幸，演員數目少了一點點


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


最近有個在軟體公司上班的朋友離職了，
每天工作超過１４小時，程式一改再改，CMMI也只是助纣為虐
舊的人一直跑，新人一直補，整間公司不知道再幹麻．．．

罄竹難書

跟他聊天的時候又回憶到此事，
我把故事說給他聽，再一直感謝他的英勇奮鬥
「時代考驗青年，青年創造時代」這種都出來了

「放屁！」他只回我兩個字


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


很多人跟我說，寫程式的宿命就是這樣，加不完的班，改不完的Code
(如果還加上補不完的文件...)

如果有時光機回到２０年前，你跟我講會計年度結帳那天能準時回家
六歲的我會笑你不懂

所以我不相信宿命之類的，既然電腦能改變別人人生，為何不能改變我們自己的？

看看每個新技術背後，不都是想多擺脫一些這種"宿命"？
看看每個方法論背後，不都是想多解脫一些這種"包袱"？
[Mythical Man-Month][Peopleware]兩本書加起來都50年了

沒有銀彈，還是要尋找，最少我們有好幾顆銅彈了

或許有天我發覺我自己也是被宿命玩弄，
也許有一天我會很累想放棄，
但是不在此時，不在此地

人月神話

這是一本軟體專案開發的書
而且是40年前的
嗯？40年前？那時候我都沒出生勒，
而且我懷疑那時候的字典根本沒有「Computer」這個單字！

站在書店翻著這書心中還一直唸「這我早知了」
但是不爭氣還是買了

心得概要：

其實都是一些很古老的"老梗"
一直到今天 ,該死人類還是玩不出新把戲

1. 程式設計有苦也有樂，樂趣在能輕鬆創造，就跟魔法一樣；苦在必須事事完美，最常出現的bug總是很蠢 ,etc:大小寫,正負號,if先後順序
2. 人月是個神話：人多並不會贏，因為寫程式工作大都是連續且不可分割 ，十幾個人一起做再加上溝通的時間，搞不好比兩三個人做慢
3. 系統需要整體概念，這個讓一個人決定就好
4. 為何進度會落後這麼多，因為每天落後一點點；所以定mileStone的時候要夠明確，明確到自己騙不了自己
5. 文件的寫法？該寫那些？總是配合人類需要，而不是電腦需要：直覺，經濟，人性
6. 越成功的系統，開發者與客戶間的互動越頻繁
7. 沒有銀彈：其實拿來打電腦那一個現在不錯了(雖然java裡面那些api，還是多的跟怪物一樣，一堆還要套Design Pattern，看懂Design Pattern也要花不少時間，不過總比跟記憶體跟CPU排程搏命好)，可是打人類的那把卻越來越噁心(一堆怪方法論，怪工具，怪技術都出來了)
   
8. 軟體工程這條路還很漫長XD

總結：

其實書的內容比我寫的還多很多，像是跟預估跟第二系統之類的，有些則是我太年輕沒辦法體會(OS/360??組語寫薪資系統???)，但每每看到某個片段，就好像看到人生以前的走馬燈，歷歷在目，又好像能預測接下來的歲月，如猶在耳，只能說這條路還很漫長，但我相信走下去一定有終點，一定有！

深入淺出SQL(Head First SQL)

這本書出的時候，已經工作兩年多了

SQL也差多不用兩年了，大概不用深入淺出了？
但我只能說
「相見恨晚」

要是能早點看到就能少走點冤枉路

我讀了多少：

速讀了一遍，但是除了正規化、Subquery、join、union，這幾部分有仔細看

關於此書：
這是我看過的第四本HeadFisrt，所以我對裡面的詭異內容已經很習慣了XD
這系列的書除了易讀還有一個好處，會做一遍錯的事給你看
而且這本寫的不該在SQL做的事..我100%全部幹過,

....而且不只錯一遍

心得：

1. 資料與表：基本的格式跟資料型態，還有那該死的DB Null，他原來不是真的Null(相對於物件世界)
2. Select,Update,Delete：我的青春阿.....
3. 正規化：我從沒看過一本SQL書在講正規化的時候，花１６頁講一個沒正規化的Table，然後在本章最後一頁才完成正規化定義，真的很瘋狂，但是很有效率
4. Alter：我都用GUI工具調整Table格式，從沒用過Alter，我錯了對不起
5. order,group,sum,count,limit：常用，看看而已
6. 複數Table設計，複數Table操作：Table與Table之間到底該怎麼互連，也是跟Excel最大的差異(我認為!)，我自己寫過很多爛Table，就是因為沒考慮好互相之間的關聯，最後才會遇到複雜一點的指令就兵敗如山倒，我終於懂了！
7. subquery：比較少用，算是重新認識一下
8. outer join,union,except：這是數學！這是集合！

結論：

想當初我再上課的時候，老師都教的好難
或者我該說，太正常了，可是工作的時候通常大部分時間在處理不正常
所以變的學校教的好像沒用？

其實並不是，只是我還不曉得如何避開危險
看完後最大收穫，我對這些危險又有更多認識

Don't Make Me Think

好吧，我承認我買這本書的原因是我很喜歡這句話

「Don't Make Me Think ！」

腦殘才是王道！

本書內容：

大概是在講網站的使用性跟親合力之類的，一些以使用者角度來看的網站設計原則


心得：

1. 別讓我思考：使用性(usability)最高原則，用語越簡單越好
2. 人讀網頁跟讀報紙差不多，都是用掃描的，不太可能有人真的一字字看
3. 導覽列(Navigator)很重要，要在網頁上造出人類的空間概念都得靠他
4. 首頁應該如何配置？放上使用者覺得重要的東西，而不是業務單位(這裡我的想法又被證實一次，讓讀資工這種腦袋放磚頭的人管首頁，是很危險的！)
5. 如果遇到使用性的問題，找個人試試看好不好用，比在會議桌上爭論來的好

結論：

Yes, Dont make me think!

火箭說明(Retro-specification)

火箭說明(Retro-specification)：

在項目已經啟動之後才開始寫技術、功能說明

By wiki

白話一點就是先寫程式才後生文件

不過其實英文原文(Retro)字義並不是要講火箭，而是只另外一個"倒退";"追溯"的意思
但是我很喜歡
因為這種文件通常跟火箭一樣看起來很炫，但是實用價值很低

我不太會寫文件，
但是我知道不是跟Code一起或是早一步出來的文件，基本上都沒參考價值
(逆向工程不算)

好的文件通常說明「人類做什麼」，是表達人的心智模型
大部分的都是火箭說明都變成在說明「電腦做什麼」，是參考程式碼
所以說我不看文件，直接程式碼一行行看，搞不好更快能弄懂程式再寫什麼

現在很多大公司都搶著通過什麼CMMI，ISO之類的東西
讓我想到國中歷史課教的滿清末年的自強運動
改革只學外人船堅砲利，而不是其思想文化
最後結果大家都知道是失敗收場

我許多同學的公司都有通過，
在下資歷尚淺，不敢妄談成功失敗
但是就我聽到的而言，沒半個有學其精神

歷史老師都會說要記取歷史的教訓
諷刺的是，歷史的教訓告訴我們歷史只會一再重複

對寫程式的人而言，
文件的目的在於能節省了解或撰寫系統的時間，而不是浪費更多

寫給SA的UML/MDA實務手冊

學UML到底有什麼用？

是很多人的疑問，我也是
我剛開始工作的時候，UML一個也不會，程式照樣寫的出來
後來多會一點，其實也是半知半解，畫出來的東西殘破不堪，也毫無參考價值

這本是我看過的UML書裡面，最感覺是有真的用uml在解決問題，整個就很有質感

本書內容：

用OOAD/UML的做法，來實作一個分析設計案例，
大部分都在畫圖跟跟使用者對談
換句話說，程式碼一行也沒有

我看了多少：

看到第八章就沒看了，大約４／５吧

心得：
一個基金的申購 從Use Case開始，一直到商業邏輯的Class Diagran跟Sequence Diagram，一直"很順利"做下去
(為何我做的都沒發生過這種事？大概是程度差吧....囧)

滿難形容的，大概看了才知道


結論：
我對分析不是很拿手，所以也不太看的很懂
只知道有個高手秀了一手給我看，就當看看熱鬧Ｑ

別說你忘了他

「這段程式在寫什麼？」

「我忘了，要Trace一下看看...」

這段故事有沒有很熟悉？
上一次出現這台詞的時候，你是問的人還是答的人？
還是自問自答？

人類本來就很健忘，所以應該無時無刻留下提醒自己的紀錄
文字也好，uml也好，註解也好，便利貼也好，
總比看一行行的神秘符號來的好

剛開始工作時，我也沒寫註解的習慣，
仗勢自己的小聰明，只管Code能Run就好，管他啥註解跟文件的
不過久了後，覺得老是自己在整自己，昨日之我永遠比今天之我還聰明

試著寫一點註解以後，才發現這樣以後看起Code來快多了
我才了解到，與其浪費生命在Trace火星文，到不如多花時間留下點記憶

有些人會說，註解/文件寫的濫的要死，有跟沒有還不是一樣
不過我覺得這是做與不做的問題，而不是好跟不好的問題
註解/文件寫的好是一種藝術，那需要很多的經驗跟天份
但是，有或沒有是一種態度，程式人該有的責任

為自己的程式負責，能動的不代表完成

UML2.0 學習手冊

UML的書很多，有很難也有簡單，或是特別偏重某部分，尤其帶有完整範例的，很容易會變成 UML for XP , UML for SA , UML for SD ....

本書特點：

簡單易讀，但是都是關鍵且重要的部分

我讀了多少：

讀完一遍，似乎沒什麼不懂，但是要用的時候還是要查一下

重點心得：

1. UML來自於OO，不用OOP威力大減
2. Use Case(使用者案例)：UML裡面最沒定義的東西，算是最接近人類需求的一個，盡量也讓使用者看的懂
3. Activity Diagram(活動圖)：表達工作處理的過程，通常表達重要的商業邏輯
4. Class Diagram(類別圖)：其實本章都在講OO概念，不過有趣的是配上UML看起來格外搭
5. Obejct Diagram (物件圖)：表達物件實際上怎麼工作的，或為Class Diagram舉個實際例子
6. Sequence Diagram(循序圖)：表訊息的流通方式，或物件之間互相合作的情形
7. Timing Diagram (時序圖)：第一次看到這個，沒用過不太懂
8. Internal-Structure Diagram (內部結構)：表示複雜的內部結構，跟package不一樣的是要表達物件的合作關係
9. Package Diagram (套件圖)：表達package之間的合作關係，尤其依賴性要注意，如果沒弄好，往高階就變Jar地獄，往下就會變程式不好改且難以追蹤，
10. Deployment Diagram (配置)：把實體的系統和機器畫成圖，看起來簡單卻意外有用，我把跟我有關的系統之間的關係畫一遍，變的很容易掌握
11. 附錄C的UML簡史滿有趣的
    

結論：

簡單易懂的好書

深入淺出設計模式(Head First Design Pattern)

「什麼是Design Pattern？」同學問

「不知道ㄟ，教授沒教過，應該不重要．．．吧？」我回答

「很重要吧」

「沒差拉，考試又不考，Case Study啦～～」

那時的我，大學三年級

=============ｎ年後===============

「連Factory Pattern跟Observer Pattern都不會？」我歇斯底里的怒吼

「咦？這些是什麼東西？」學弟滿臉疑惑說道

「就是說$!@#%$~~~~~，瞭了嗎？」

「....？」

「....orz」我放棄了

但其實回過神來仔細想想，跟當年的我不也是這樣嗎

所以說，Design Pattern到底是什麼？

Ｗｉｋｉ說：是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案
本書說：是種可再利用的經驗與智慧
良葛格說：是在解決問題的過程中，一些良好思路的經驗集成
我說：是經過無數血與淚所堆砌出的智慧結晶

在物件導向語言(C++,Java,C#.Net,VB.Net)中
它已經是個隨處可見的真理

我讀了多少：

次數多到不清，不過會用才是真的會

重點心得：

1. Obersver(觀察者)：愛稱為電台模式，通常是為解決一個Model對應到多個View之間的互動，寫Swing常用到 －－『甲愛貢，那Ａ謀企電台貢厚全台灣聽』
2. Decorator(裝飾者)：又稱之為裝甲模式，通常我用都會包太多層並難以理解，不過卻相當程度能動態調整　－－『你妝會不會化太濃了』
3. Factory(工廠)：我第一個用的Pattern，是拿來解決，不同資料來源搭配到同一個介面上的問題　－－『又到了開分公司的時候了』
4. Singleton(獨體)：個人覺得是最簡單也最困難的一個，我只拿來做紀錄Log到檔案用過
   
5. Command(命令)：愛稱遙控器模式，我常拿來做權限部分，拿來分離登入物件及功能 －－『不要亂拿遙控器，很危險的』
6. Adapter(轉接)，據說能解決銜接舊系統的問題，沒用過
7. Facade(表象)，愛稱幻覺，整理一駝亂的好幫手，趕時間或感覺Class拆太多的時候不錯 －－『雖然一切都是幻覺，但是真的嚇到我了』
8. Template(樣板)，整理很相似的Code時候用的，我不太常用
9. Iterator(反覆)，有效做重複的事，看到很多for - if - for -if 能考慮用這個，看起來沒什麼了不起，但常常意外的有效果 －－『下一位，下一位，下一位』
10. Composite(合成) ，樹狀結構跟XML的好朋友，在複雜的加總或計算中算好用 ，尤其是用for loop或SQL指令會做很亂的那種 －－『無.敵.合.體.』
11. State(狀態)，通常改變狀態代表邏輯行為也要改變，這個Pattern能讓人先專注在狀態變化，而不是行為 －－『Oh！It is another Final State Ｍachine！』
12. Proxy(代理人)，也是個看起來簡單但變化很多的Pattern，不是很常用
13. Model -View -Control (MVC) ，每個寫過網頁的都號稱會用MVC，但其實MVC沒這麼簡單，有時候把Code要放在 Model or View or Control 不是非常直覺的事，我很懷疑都沒人有這種煩惱嗎？

結論：

Design Pattern不是萬能的，但是看不懂可是萬萬不能，使用的太普遍了

生平不識模式趣，寫盡程式也枉然

推薦本書：

Design Pattern 一直被當作很難或很高深的理論(起碼對我而言)，但是Head First系列的變態作者，加上大師級的翻譯，就是有辦法寫到連我這笨蛋都看的懂，還帶我看到不一樣的世界，我衷心佩服且感恩
不管懂不懂Design Pattern，一定要看一次

操作介面設計模式

「我忘記我選到什麼了？」

「我找不到確定鍵在那！」

「為什麼點這個沒反應？」

「這顏色好亂，我看的眼睛好累」

很多人都遇過，使用者抱怨介面太花，配置很亂，操作不夠Friendly
但如果遇到一個讀資工的宅男，要求介面簡直是緣木求魚，或者我該說雪上加霜？ XD

工作以後，我就一直被介面問題煩惱
也找過幾本書，但都只是只會其型，不知其意

直到我拿到這本為止

本書內容：

介面設計的型錄，多半以人的角度思考，並講解其原理

人類到底看見了什麼，人類到底想做些什麼

我看了多少：

全讀完，基本上不太可能看不懂，只是有沒有練熟的問題

重點心得：

1. 使用者做什麼：使用者為什麼要用這個程式，會做何種程度的嘗試，利用基本原則引導使用者熟練系統，因為文件沒人會去看
2. 組織內容：空間的規劃，不同類型的資料，在人類心中有各自適合的心智模型，再對應到介面上擺放方式
3. 到處走走：路徑的規劃，一步步走向正確的地方，不能讓使用者迷路，好的路標不是強迫到正確的位置，而是指出使用者前進的方向
4. 組織規畫：頁面的配置，視覺流的影響，物件型態(這裡指的是視覺外觀)的所造成的關聯性，應該有系統的分門別類，而不是雜亂無章，看網頁或視窗時，人不會照順序看，而是憑感覺
5. 做事：如何讓[按鈕]/[選單]/[連結]看起來是能用的，讓不同的元件負擔起不同責任，例如下拉式選單(DropDownList)負責"選擇"，按鈕(Button)負責"執行"，拖放(Darg-and-Drop)負責"移動"等等，還有得注意文字盒(TextBox)的使用，這東西通常很難用
6. 資訊圖形：千言萬語不如一張好圖，圖形的力量比想像中的還可怕，把形狀放大或是顏色改辦一下，對看的人而言就意義完全不同，利用大小顏色聚焦資訊，不重要不代表不需要

結論：

其實嚴格來說，這應該算是心理學家跟藝術家的事，而且是很抽象的東西，我們搞技術的人大部分都不擅長這些，但程式畢竟是要給人用的，既然如此，那我們就看些簡單的基本原理，然後用抄的就好，本書不但提共抄襲的好材料，又沒有困難的理論，值得一讀

ＳＱＬ之美學

「ＳＱＬ不就是ＳＱＬ？哪來什麼美學」我看到本書的第一個想法

不過聳動的標題，還是促使我從架子拿下來翻幾頁，

「喔喔！？我好像遇過這件事？」

「原來學校教的離散數學跟檔案結構不是在騙我！？」

於是我把它買回家

本書內容：

ＳＱＬ的理論，但是是對於實作極度重要的理論
實作以戰爭比喻，而理論部分以兵法比喻
很多內容，會提出某SQL指令或Table設計，為何資料庫會這麼做，它到底在想些什麼，進而產生對應的效率問題

讀了多少：

全精讀完，讀懂約七成

重點心得：

1. 正規化的重要性，與Null的潛藏危險：『以正合，以奇勝』，正規化跟非Null是「正」，反正規化跟允許Null是「奇」，問題是何時該反正規化，而不是為何要正規化，正規化跟非Null是必備
2. 索引是雙面刃，在特定條件下會增加Select效率，但是一定會降低Insert效率
3. SQL的本質是集合理論，跟資料庫核心接近程度為資料＞關聯式(如join,union,group by)＞非關聯式(如 order by, case when )，Query指令越接近核心速度越快，所以當有複雜的查詢時，關聯度高子查詢要先放在內層
4. 最佳化處理器(SQL Optimizer)，跟前三點有正相關，跟理論背離的Query指令會無法達成最佳化，甚至有時候會搞砸更多事
5. 鎖定(Lock)是為了保持資料同步下正確，但是ＳＱＬ通常是處理＂整批＂資料；所以換句話說，反正規化，條件限制少的Query指令，或牽涉超出集合理論能做的部分，為了保持資料正確性，SQL會加大鎖定範圍
6. 效率跟前面有前五點必然相關，通常不佳的效率來自於反覆執行的小型指令
7. 階層式(hierarchy)結構或樹狀結構不適合關聯式資料庫，可以的話盡量用程式解
8. SQL結構彈性取決於與真實世界符合程度，而非過度動態的表格或高深莫測的語法

結論：

其實這本書不像封面看起來的無趣，只是有些地方必須要先學過相關的數學或電腦知識，在配上相關實務經驗，才會有豁然開朗的感覺

SCJP5.0猛虎出閘

「看，SCJP」我好友拿出張卡片

「嗯嗯．．」

「Java的國際證照，酷吧，跟你說$#@!!!$5.... 」他滔滔不絕的講著

「嗯嗯．．」.....有個愛炫燿的朋友真受不了

於是受個刺激(誘惑?)的我也買本書去考

考試買這本書到底有沒有用：

有

讀書心得：

• １到４章為基本語法－感覺還都能了解，只是很多小地方沒注意到，特別是三章物件導向，我才知道所謂的"物件"原來是這樣用
• ５章執行緒－如同惡夢般的mutilthread被講的很簡單
• ６章資源回收－讓用不到的物件早點超生
• ７章集合與泛形－看完後有恍然大悟的感覺，發現自己的程式能少用點陣列，有更適合的資料結構
• ８章ＩＯ－我後來才知道，看起來很複雜，其實一切都是DecatorPattern
  
• ９章其他－雖然考試不考，但是實際中很常用到，也很常遇到
• 模擬考題－想考高分就多做吧

結論：

看完後第一個感想：「XX娘的，原來我這麼不懂Java」

算是帶我重新認識Java的一本好書，從此以後我也對物件導向有比較深的了解
也是算開始"覺悟"到要擺脫結構化程式語言的開始


炫燿一下XD：

我是2007年8月考的，87分，但是說實在不重要就是 ~3~;