Eucalyptus , Ubuntu 11.04 EMI and Crawlzilla (1)

UPDATE:因為 Eucalyptus 增加 EMI 容量的方式[u1]會出錯，instance 起不來，因此必須改用另一種方式。

---

因為雲端與資訊檢索課程都要求期末專題，因此選了可涵蓋兩門課程的交集計畫：建立雲端叢集上的搜尋引擎。以下是一些過程與其中遇到的問題。

此期末專題採用的組件如下

• Eucalyptus：提供 AWS EC2，S3 與 EBS 等服務相同的自建雲端平台。雖然 Ubuntu 在 11.10 時主力轉向另外一套 OpenStack ，但經過漫長艱辛的嘗試，覺得目前後者在快速佈署、運作與改設定的穩定上不如以往 Ubuntu 在 11.04 以前 Installer CD 同綑 Eucalyptus 的作法^[1]
• Crawlzilla：國網中心開發，將索引庫、搜尋引擎、爬蟲、分佈式運算的 Nutch 與 Hadoop 包在一起。雖然  Nutch 已經具備使用 Hadoop 的能力，但使用 Crawlzilla 可進一步簡化設定、佈署節點，以及管理搜尋服務的步驟。
• Ubuntu 11.04 EMI：前述 Crawlzilla 將安裝在雲端的 instances 上。 由於自製 EMI 可能有很多問題，為謹慎起見，直接下載 Ubuntu 提供可發布的 Cloud Image ，並做了一些必要的修改。至於使用11.04 是因為 12.04 與 11.10 都無法使服務正常運作，稍後會詳細提及。
• Sun Java 6 JDK：Crawlzilla 只能接受 Sun Java 6 JDK 。在有限時間的情況下，我無法完整修改與測試 Crawlzilla 是否能與 Open JDK 接軌。所以每台節點都必須安裝 Sun Java 6 JDK。
• 對各 instance 而言，可用記憶體非常重要。因為 Hadoop MapReduce 會佔據很多記憶體，因此最好主控 instance 有 1GB 以上的記憶體額度。測試中，在只有 512MB 的情況下，連搜尋都會出現 'OutOfMemory' 例外。

建置步驟

• 主控的 instance 所在 Security Group 除 SSH 外，必須要有 8080、50070、50060、50030 等 port 開放，以便查詢 Hadoop 與 Crawlzilla 網頁資訊
• 因為Ubuntu Cloud 官方提供的 EMI  預設根目錄空間不足，所以必須手動增加可用空間
• 將下載的 EMI 'tar.gz' 檔解開
• 根據 Eucalyptus 文件增加該 '.img' 映像檔大小[u1]
• 重新用 Tar 將映像檔與其他解開的組件包起來
• 使用 'uec-publish-tarball' 工具^[2]發布該 EMI
• 使用命令列方式或 Hybridfox 啟動該 EMI 的 instance 並連入。假設這第一台作主控 Controller ，並具有 Public IP 
• 若是該 Cloud 預設發的不是真的 Public IP ，而是例如 192.168.0.0/12 這種內網 IP 的位置，則要使用 Eucalyptus 類似 AWS Elastic IP 的方式去提供。
• 安裝 Sun Java 6 JDK 。為了預防使用 Script 造成額外設定與問題，我在此階段每個 instances 都使用手動安裝。注意雖然該篇指引是針對 Java 7 ，但原理相同
• 下載 Crawlzilla 安裝包，解開並按照官方指引安裝
• instance 的 '/etc/hosts' 會沒有該 instance hostname ，需先手動將 'localhost' 改成該 instance 連入時顯示的 hostname ^[3]。
• 預先修改節點安裝所需設定：因為 Crawlzilla 中佈署節點的 Scripts 預設使用密碼連回 Controller ，與 EMI 中預設使用私鑰連線不同，為了避免大量修改 Scripts 可能造成的問題，因此將 Controller 節點中，SSH 預設不使用密碼連線的設定改回。
• Controller 主控安裝完成，可以連線至該 instance 公開 IP  位置的 8080 port 網頁介面，也可以先至其 'Crawl' 頁籤中嘗試抓取一個簡單網頁，並深度設成 '1' 測試看看
• 根據多次嘗試，若完全不改動設定，Ubuntu 12.04 與 11.10 在這個簡單測試動作就會因 DFS 而出錯。這也就是為何後來要改用 11.04 的原因。
• 「簡單網頁」指內容不要太多，但最好能有中英文的網頁。如果沒問題，大致上 5 分鐘左右就可以建好索引提供搜尋 ^[4]
• Controller 安裝好後，會因為不明原因，原本應該提供子節點安裝腳本的預設目錄 '/home/crawler/crawlzilla/source/slave_deploy.sh' 中沒有該檔案，因此手動複製移至該路徑中
• 不過我是在 instance 上用 'ubuntu' 帳號安裝，可能因此路徑與 Crawlzilla 預想不同。
• 設定一台子節點：之後其他子節點都可以依樣畫葫蘆
• 如前所述進行準備工作到安裝完 JDK ，就可下命令去將該節點安裝腳本抓回此節點上：'scp crawler@[ 主控 IP ]:/home/crawler/crawlzilla/source/client_deploy.sh '
• 執行該腳本進行安裝。過程中會問是否打開 Hadoop ，可以一併開啟
• 安裝好子節點，可以在 Controller 中下命令確認：'crawlzilla'
• 進入此管理介面可以使用第一個選項確認節點確實有連上

到此為止「理論上」雲端叢集環境下的分佈式搜尋引擎已經設定好了。但實際上接下來才是各種問題的開始。接著會把試圖解決這些問題的過程等紀錄下來，提供參考。

---

[1] 是的，我知道 Ubuntu 新提供 Orchestra + Juju 的作法。但連官方提供的教學都不能正常運作時，我對其目前 Ubuntu 力推這兩套新服務的熱情尚難認同。

[2]新版本已更名成 'cloud-publish-tarball'

[3]例如將 '/etc/hosts' 中的 "127.0.0.1 localhost" 改成 "127.0.0.1 ip-172-168-1-2"

[4]經過多次測試，發現不管目標複雜或簡單，這似乎是基本的「Hadoop 啟動時間」。我想分佈式運算是求大規模運算的時間可以降低，而非啟動的迅速。感覺有點像流言終結者中，跑車剛開始啟動的速度會輸給玩具車一樣。

小結 Java 開發學習所感之一

這篇主要是個人學習開發 Java 程式中的一些感想小結，不是也不應該成為尖銳批評與語言戰爭的新戰場。

我個人最早開始寫的語言是 C ，後來學了一陣子 C++ 。雖然將語言的學習階段定出量化標準似乎不當，但如果要取得標準，我的進展大概可歸為「正在學習使用 template 自動產生類別」的程度。學習的過程中我很認同 C++ 的某些設計，尤其是讓程設者可以在效能、機器底層與易用、安全與設計模式的高層觀點間取捨的特色，但我也認同有些程設強者討厭 C++ 複雜、難確定其行為與語法冗長等缺點。不過大致上我還頗欣賞這門當時所謂的主流語言。

但對於 Java ，那又是另一回事了。

我完全無法認同某些人所吹噓，Java 是 C++ 接棒人的說法。這兩門語言的設計思想與目標就我看來完全不一樣，其在程設市場中被使用的專案與推動軌跡也不相似；更不用說 Java 剛開始出現時，為人所詬病的效能問題。當 C 程設者已經在嘲笑 C++ 過於緩慢與臃腫時，Java 的出現使得 C++ 程式員得以站在同樣的高處。更不用說取消了指標，這對 C 與 C++ 程設者而言更是完全不可思議的。

當然後來的故事大家都知道。既然語言的設計目標完全不同，Java 以跨平台與「易用」征服了教學與商用市場的心。事實證明初學者寧願躲在神妙的全自動垃圾回收器與 reference 之後，也不願意弄髒自己的手去碰觸可怕的 Segementation Fault 。這對疲於應付作業與考試的老師而言當然是一大恩賜，對毫無意願與資源訓練新進人員的軟體公司更是萬能藥方。而對推廣 Java 的各大公司而言，如此商業性質的語言相關資源，從 JVM 到各種教材不啻為其行銷部隊開啟了一路狂飆的綠燈﹍﹍等等，我說了「商業性質的語言資源」嗎？

事實上就我的感覺，Java 語言資源的商業性質不只是單單 JDK 授權證的口水戰而已。對利用語言資源賺取利益的公司而言，最好的情況莫過於洗腦程設者「這門語言非常重要，攸關你們每個人將來的工作與人生幸福。但它如此優秀的性質代表你無法靠社群與自學的方式學好。忘了他們吧，只要購買某某商用 JVM 、商用編譯器、IDE 、商用解決方案與十幾本充斥 Buzz Word 的書，你也能成為 Java 大師！」

然後就變成我們今天這個樣子。就連最簡單的教學，以往只要 `vim foobar.cpp ; g++ ./foobar.cpp ; gdb ./a.out` 今天卻要等上數百 MB 的下載與數分鐘的時間等待第一個、往往是毫無用處的 IDE 「歡迎」介面開始。接著就像忘記程設者學習的是 Java 語言而不是 Photoshop 一樣，滑鼠與鍵盤忙碌著按照各樣指示打開各種視窗，或敲擊著連解釋也沒有的神秘字串，最後鏘鏘！印出了 「Hello, World」！連 CLASSPATH 與 PATH 都不需要知道，你已經學會了 Java！又或者是某個神秘的函式庫，在講解自己的 API 如何如何好用與威力強大，當程設者興奮的要將這個函式庫引入專案時，卻只見到第一句「如何將此函式庫與某某 IDE 作結合」...。IDE 往往成了我們的 Java 生命，泉源，愛人，甚至主子。沒有 IDE ，Java 程設者就像瞎眼的可憐人一樣站在黑暗中。更不用說如果沒有其他廠商大肆吹噓卻又複雜臃腫至極的各種技術，「一般的」Java 程設者要怎麼活在這殘酷的世界中。

事情是怎麼變成這樣子的？在我開始手動了解如何完全不靠 IDE 與其他輔助技術，僅僅依靠 `javac` 與 `java` 讓我的「Hello World」可以執行時，我思索著。很顯然不完全是 IDE 開發者的錯，也不是 Java 語言設計者，以及任何其他出於減輕自己與他人負擔，以至於設計出更多機制、結構與算法的人的錯。至少他們的用意原本都是讓已經熟知整套機制的程設者日子更好。或許問題是出在我們身上，我們這些已經過累、過煩、過於希望只要毫不思考地按下一個鍵，世界變得更好的程設者之過。我們在心中給魔鬼留地步，那些嘶吼著利益與詭詐的瑪門就爬了進來，污染一切，以至於教給更多新來者的只剩下知道按下 IDE 上的一個鍵，卻當世界崩潰時不知所措。那也許只是一個 BUG ，或是一個細微的調整，超出了一切現成打點好的解決方案之上，卻也暴露出了現有一切舒適的抽象層是如何不可靠的一面。

我希望我不要成為那樣的 Java 開發者。即使我對 Java 並無好感，但如果開發一個語言要被過多的技術綁手綁腳，實在過於悲哀。

Gentoo + KVM + Guest OS 試安裝提要

本篇主要將安裝 Gentoo + KVM + Guest OS 的一些重點與心得摘要紀錄。

Gentoo

• 標準參考文件：Gentoo Handbook
• 採用將第一層目錄放在 LVM 分割區的作法：Gentoo LVM2 installation 。注意此份文件與主要安裝說明的步驟有些是交錯的，必須更動或插進在主說明中的某些步驟，如核心編譯挑選相關模組等。
• 時間問題：就我的電腦與雙系統使用者而言，不要將時間設定為 UTC ，否則硬體時間與系統時間（`hwclock` 與 `date`）會不一致。
• ALSA 問題：一定要將 ALSA 編成模組。如果編進核心，`alsa-base` 相關的設定工具會找不到模組。即使之後手編模組似乎也沒用。此次設定失敗的代價是為了一個模組重編整個核心。
• 中文問題：USE 要設定 `nls` 、 `cjk` 、`unicode` 等相關旗標。可參考 Gentoo 10.1 的中文後續設定 。
• 中文字型問題：修改 fontconfig 設定優先使用的字型，可修改 `/etc/fonts/local.conf` ，修改格式為
• 安裝 `fluxbox` 與 `xinit` ，並編輯 `~/.xinitrc` ，只有在必要時才手動啟動 XWindow　。
• Gentoo 中，如果網路沒有 router 就不要設定 `gateway`，系統會真的去找不存在的路由拖慢速度，連 XWindow 啟動都會因此卡住。

缺乏睡眠下處理事務的方式與能力

首先，缺乏睡眠明顯帶來的影響是積極性的減弱。這意味著非強制、迫切性的事務要執行起來更有困難。例如「自學英文」這種任務就比「完成即將截止的作業」難以執行。而且在處理事務時求完成比求好的心態更強，因此平常可能會注意的細節與要求在此種情況下都強烈變成希望省略與草草帶過。

再者，缺乏睡眠對需要創新與推理思考的事務而言是致命的。在這種情況下，思考變得遲緩不說，由於很難集中精神，因此要針對某些問題長考會變得困難。雪上加霜的是處於此種狀況下的短期記憶衰弱，意味著要作為思考材料的暫存結果難以記住，或是漏掉許多細節。有時困難甚至到無法正常推論，找問題或解法變成排列組合。

不過前述情況有一個例外：某些特別跳躍的想法常常會在極度缺乏睡眠，以致於一面努力保持清醒，又一面極短暫打盹時出現。當然也許這就是解決問題的關鍵，但就我個人的觀察而言，總體來說需要思考的工作無法在缺乏睡眠時作，甚至只是輕微缺乏睡眠都會影響。

故能從單純減少睡眠時間獲得好處的工作只有那些幾乎不需要創造、推理思考能力的工作，例如單純打字、整理文件、找資料，或不太需要技術的勞動。因為這些工作所在乎的是量的累積而非質的進步，所以可以在缺乏睡眠的情況下完成。

另外一項決定是否能在缺乏睡眠時進行事務的關鍵要素，是該事務是否具互動性。例如參與課堂討論就會比被動聽課容易強制集中精神。這也可以說明為何有人可以在已感疲倦的情況下熬夜打電動，但就是無法將注意力從具互動的電腦移開而專注在上課或解問題等無互動方的事務上。不過即使是具互動性的事務，支撐的情況也是極為勉強。只是在切換打盹與清醒的狀況下支撐著不進入真正睡眠。這也可以解釋為何疲勞駕駛如此致命，因為駕駛人其實在疲倦的狀況下是半睡半醒的，也就是某些時刻其實是極短暫、部份睡眠的狀態。

在實際觀察方面，以我個人而言，若以七小時為準少睡兩個小時就會出現疲倦感、思考能力減弱、積極性不足的情況。而且一至兩個小時缺乏睡眠在強制醒來後「感覺可用精力」反而比少睡四個小時以上的情況還差。少睡四個小時以上的情況在醒來後一至兩小時內暫時還能保持擁有精力的感覺，但隨後衰減與倦怠後就會進入一面打盹一面保持清醒的狀態。而且缺乏睡眠對健康的危害幾乎是馬上呈現：只要少睡兩個小時以上，昏沉不說，流鼻水、喉嚨腫、打噴嚏等感冒症狀幾乎必定出現。所以睡眠對人的重要是全面的，缺乏睡眠只會讓身心都受創。

另外使睡眠不足更嚴重的是其所帶來的影響需要兩三天才會逐漸消除。這也就是為何一般人所謂規律生活的重要所在。即使在缺乏睡眠後充足的補眠，影響也不會馬上消除。有時還會出現越睡越累的情況。這種時候運動就越發重要：以我自身經歷而言，在缺乏睡眠與其影響尚持續時，若能進行半小時流汗的運動，似乎對精神具有重整的效果。雖然疲倦不會馬上消除，但此時疲倦的感覺不再是強撐下煩躁的狀態，心緒會較為安定。

總結而言：只要感到精神不濟，在有可能的情況下，即使只有十幾分鐘也應立即休息。不要在這種情況下還妄想苦撐，或因為覺得睡眠浪費時間而感到罪惡。精神不濟下效率不佳而浪費的時間，或甚至是潛在的生命危害，都比短暫休息帶來的成本還高。

《如何閱讀一本書》摘要筆記

這是《如何閱讀一本書》（How to Read a Book）內中各規則、提要等筆記。由於筆記格式力求與手寫版相同，所以採用 Docx 格式。另外為了方便閱讀，轉成 PDF 格式。若日後還有相關補充會在此篇持續更新。

• 《如何閱讀一本書》主要規則整理（Docx）（PDF）

《A Rulebook for Arguments》筆記：讀後感初記

• 特別有意思：類比論證與歸納論證之比較。以前雖知道歸納的問題與極限，但不知原來類比論證在減少歸納需大量舉例的缺點上效果如此顯著。當然，類比本身亦有其自身極限的問題。
• 演繹法中所列者拓展了我對演繹論證形式的認知。不過要從日常想法改成正規推論形式仍有困難。我認為這要練習去找出適用「日常思考 - 論證」的慣用流程。
• 本書特別提出反對意見是改進自己論證的機會，而不是一味要駁倒之。因重要的是論證是否可經過考驗判定為真，而非以人的立場進行無謂的堅持。
• 個人不確定在真實世界類似論證的思考、討論過程若全採如此正規形式，他人是否能接受，或說有無可能。畢竟若在文章中採此形式，文章是否會失去「文」應有的組織、敘述性？
• 另外由於本書著重在短論證，未知長篇中，連結、長跨度等因素加入後，是否造成長或複雜論證的困難並非只是線性上升，而是有質變的現象。又如果真有，克服方法為何？（本書中最長的論證是第 30 頁中，整理福爾摩斯組合觀察和數個演繹論證者。但其仍算短篇，且其組成之論證性質相似單一）

《A Rulebook for Arguments》筆記：附錄

關於定義

若遇未知、生難字的使用，除讀者會自己使用的字典外，應在文章中解釋其字使用意義，即定義。

有時，即使是常用字的字義也不一定清楚。因此，在能有效地談論它之前，必須要先在所論為何事物上，於讀者與作者間達成一致。

而當一字多義時，要務求能清楚分辨其意思。這包括要清楚分辨同個字，是用以表達一類或是一個個體等概念。

#D1 當字義不清楚時應使其明確

• 有時，只需簡單查字典就可解決。但當議題困難化時，字典能幫上的忙便少很多。因此有些字，需要作者精確定義之。重點在盡可能減少歧異，又不致窄化該字義太多。
• 定義中不要附加褒貶在內。褒貶應該由論證推出，針對結論之事物。
• 有時要透過研究此詞如何被人使用來獲得幫助。
• 有時可能要透過測試或某些程序來判斷一字義是否適用，即力求其在特定場合時空下發揮作用。例如法律上的「會面」規定和相關禁止事項有關，因此必須以精確限定、指出其適用場合。

#D2 競合字義時應找最清楚者用之

• 當同字多義競合時，人們會爭辯適用哪個。如果真的發生，要按照三步驟確定其適用範圍
1. 納入所有其切合的事物（如「鳥類」必定包含「麻雀、白頭翁……」等)。
2. 排除明顯不合的事物。即有差異者，找其本質明顯被認為不同者（「鳥類」就一般普遍認知而言不包含蝙蝠）。
3. 藉由前述判斷在範圍內外的事物，描述出此字義適用的清楚界線，並解釋為何如此劃定。因此前兩點是先找出明顯是與不是者，然後再從其中找出界線（因此，依據上述二例項，「鳥類」的定義應由「是否有羽毛」去劃定）。
# 注意如果界線不能解釋清楚或無法解釋（例如「法律就是如此規定」)，則不應用其當作界線

#D3 別期待定義完成論證該做的事

• 定義可幫助組織想法、找出異同的關鍵。
• 有時在清楚的定義後，人們可能發現自己並非真正反對該議題。
# 但定義不能解決問題，也無法替困難的問題下定論。定義可以澄清概念，但想得出問題解法仍要視被定義事物之性質，並施以一連串相關推論才可。

《A Rulebook for Arguments》筆記：第十章

謬誤

本章介紹各種常見謬誤，以及如何防止這些謬誤產生。

1. 以偏概全

• #8 要求多舉例、#9 要求舉例要有代表性、#10 要求需有背景知識、權威論證被要求該權威必須與問題領域相關、#19 警告因果不能簡單判定 等都是在對抗此種謬誤。

2. 忽略其他解釋

• 兩事件之間不一定有因果。而 #20 至 #23 言明相近事件之間不見得有因果，可能有其他解釋。
• 人作決定時常犯此謬誤，忽略除簡單的二分法或「唯一選擇」以外還有其他可能性。
# 這提醒我們不要窄化自己所能看見的選擇，要考慮更多可能！

3. 人身攻擊

• 見 #17 人身攻擊無礙來源資格

4. 訴諸無知

• 爭辯、強辯一宣告為真只因其未被確認為偽。最有明的例子即是美國麥卡錫曾控告某人為共產黨，卻自承「除情報單位在他檔案內找不到他不是共產黨的證據外，我對此並無太多證據」。

5. 訴諸同情

• 特別指即使毫無道理，也要他人因著同情而獲取特別待遇。

6. 訴諸群眾

• 煽動大眾、以「所有人都如此作」作為「證據」去「證明」為真。
# 事實上此推論仍錯：無法證明「所有人」都如此作。

7. 若結果則前提

• 典型演繹謬誤。即下雨路會濕，但路溼不代表一定下雨，除非兩命題互為充要條件。謬誤者會認為因為路溼了，所以一定可逆推至下雨的前提成立。

8. 結論變前提

• 即循環論證：A 為真是因為 B 言及其為真；而 B 之所以具權威是因 A 證明之；因此 B 是權威。
• 上述例子中 A 與 B 互相「證明」且依賴於對方為真，結果對事實毫無幫助。

9. 不單純的問題

• 即不管回答者的答案如何，都會被套入預設立場。
• 例如「你是否仍如以往一般自私？」。若回答是，代表自私；若回答否，代表以前很自私。並無此人其實從來不自私的考慮。

10. 拒絕前因

• 即下雨路會溼，但沒下雨不代表路不會濕。謬誤者會認為如果沒有下雨，路一定不會濕。

11. 歧義

• 見 #7 不要抽換字義(或用模稜兩可的字)
  

12. 偽因

• 找因果關係失敗、得出錯誤因時的情形。見 #20 至 #23 中除因果外還可能的事件關聯。
  

13. 偽二分法

• 將選項過度簡化二分，忽略有其他可能的選項。此謬誤也常包括刻意忽視或貶抑反面、其他意見者。
  
• 例如斷言國家會滅亡一定是因為外國入侵「XOR」內部叛亂，卻沒有想過有國家是因為海平面上昇、天災、乾旱而滅亡。

14. 貶抑反面意見

• 參照 #5 避免情緒化。

15. 未能推至結論

• 常見於壞論證中：提了一個未能由證據合理推出的結論。

16. 未知的權威

• 見 #10 背景資訊至關重要 。此謬誤表示未能提出足夠的背景資訊。

17. 具暗示的定義

• 詞彙的定義本身就含有褒貶之意在內。例如定義「信仰」是「狂熱於未能證實事物的一種表面情緒」。見附錄有更多定義有關的規則。

18. 井裡下毒

• 用貶抑之字句去中傷一個論證，如批評該論證「一無是處」、「任何神智正常的人都不會發表如此言論」等。甚至是在提及其內容之前就下如此斷言。

19. 輕率認定原因

• 尤指根據很少確認事實時下關於原因的定論。

20. 偷天換日

• 利用人們具有強烈意識的子議題(甚至與主議題無關者)去引開他人的注意。例如在談論車子之間不同安全程度時，引至哪些車是美國所產之上。

21. 諷刺一個反對意見以駁倒它

• 見 #5 避免情緒化。

22. 抽換字義

• 尤指在字彙本身涵蓋意義較大，因而被人從所涵蓋事物中挑出反對例子時常做的反應。
• 例如：言明所有學習都是折磨；反對者說了聲明者所喜愛的學習科目；聲明者立刻縮減「學習」定義至不包含自己喜愛科目的範圍。
• 見 #7 不要抽換字義(或用模稜兩可的字)、有關定義的附錄部份。

《A Rulebook for Arguments》筆記：第九章

組織論證性論文 -- C. 寫作

記住這應該是最後一步，而不要先作。

C.1. 遵循大綱

• 不要在論點間迷失，應按大綱之順序。若發現要將論文組織起來很困難，應重改大綱。

C.2. 簡介部份應保持簡潔

• 不要用不相干的文字介紹自己的論文，應只關注在文章重點議題、所持觀點等。

C.3. 一次一個論點

• 每段落中只放一個重點。在本頁例子三段論法的使用中，其每段落都只放一個前提，或最後段落為結論。若有提出的前提需要解釋為真者，可用一或多個段落去捍衛這個前提(接在前提出現後)。
# 捍衛前提，則可舉更切實與更多的例子等。

C.4. 明確澄清

• 在作者看來很清楚的事實關係，讀者看來可能如霧裡看花。因此說明想法之間，或各前提間是如何組織因而關聯到結論的結構是很重要的。
• 甚至有時作者其實對自己的思想也瞭解的不夠透徹，因而此種加細解釋的作法對作者也有好處。另外也應該將普通但被特化使用的字眼作詳細解釋。

C.5. 以論證支持反面意見

• 如此使該意見能清楚呈現其結構、內容，然後再以自己的意見回應或駁倒之。

C.6. 宣稱的言論不要超過所呈現出來的事實

• 即不要已偏見，或個人色彩太重的方式結尾，保持態度為「可能自己所寫仍未完全，但已呈現最好、最正確或最應該採取之行動」。因無人能完全預見其他人對自己的論文有何批評。

《A Rulebook for Arguments》筆記：第八章

組織論證性論文 -- B. 關於論文的重點

在找到可確立的結論後，接下來要組織全文，其中包括所有能有效呈現論證的部份。

B.1. 解釋問題

• 解釋所要回答的問題：此問題重要度為何、答案取決何事物等。也要使其他人知道確實有此問題。另外，還要使潛在讀者知道除作者外，尚有其他人也一同關心此問題。此即喚醒他人對問題的重視度。
• 同一問題，因應潛在讀者背景的不同，解釋的方式也不同。例如論文是要成為大學論文，或是要在公共場合發表，對喚起讀者意識的作法自然不同。
• 有時要訴諸共同標準或價值觀來衡量問題。

B.2. 明確訂出宣告或提案

• 明確是重點。例如「美國內戰以經濟衝突為主要原因」即是定義明確的宣告。
• 若是要評估或對抗某些提議或宣告，例如認為其未能令人信服，則應明確表示自己的結論。例如「此篇文章中我認為某某論證無法令人信服」
# 否則，此篇論文自己也將無法令人信服！

B.3. 全面發展自己的論證

• 在明確表明了問題的重要度與宣告在文中的主要目標後，可開始發展自己的論證。
• 計畫很重要：不要過度擴張，也不要把所有曾考慮過的論證都放入。
• 若為提案，要解釋此提案可解決一開始提到的問題。在論證方面，要解釋此提案為何為真(問題因果關係，以及提案解決的方式生效方式)。
• 也就是此時要全面發展、解釋細節，以及說明理由。當然，此處使用的論證要合於之前規則的要求。

B.4. 考慮反對面

• 提案是否適切？是否太長？之前是否已經嘗試過？提案的可行度為何？
• 很多提案都不只具正面效果，也有負面效果。
• 以預先處理、宣稱與詮釋的方式來處理反對面。例在寫大學論文時，於小組閱讀中尋找可能的批評意見。若先前於 A. 探索議題 階段時夠仔細，則從不同觀點與背景知識中閱讀時就能發現負面意見。
• 挑出負面意見中最健全者，並回答之。

B.5. 考慮替代方案

• 若論文類型為提案，只展示自己方案能解決問題是不夠的。還要說明為何自己的提案好過其他備選者。
• 在本頁游泳池擁擠解決方案的例子中，問題之一在於未能詳細說明泳池擁擠的原因。但即使能詳細確立其原因，也不夠好：未能明示擴張泳池的方案好過其他解決過度擁擠的方案。
• 而在宣告或詮釋性的論文中，若詮釋文本或事件，要考慮的替選方案即為其他可能的詮釋方式，並說明其不如自己論文採用者適切之處。例如在詮釋事件因果時，利用 #19 提出最有可能原因 中的規則，說明其他原因都不如自己所提出者有說服力。

《A Rulebook for Arguments》筆記：第七章

組織論證性的論文 -- A. 探索議題

論證性的論文是由短論證，或大設計分別由短論證落實構成。
三個步驟：A.探索議題 B.關於論文的重點 C.寫作 。

A.1. 探索各方面關於議題的論證

• 不要只在乎第一個從想法浮現的論證。重點應擺在具有充分資訊、可被堅實論證所捍衛的見解。
• 因此要先藉由閱讀有關文章，或與擁有不同觀點者談論，以得出不同方面的最堅實的論證作為開始。
• 在檢驗一個議題時，將有各方面正反面的論證，以及以前數章所提規則所建立、屬於自己的論證。
# 應使用不同形式，去為各方面看法建立論證，並以前述規則批評它們。
# 有時前述 #26 假設三段論法 可以在不知前提與結論之間關聯時協助看出關係。

A.2. 質疑與捍衛每個論證的前提

• 在確認前提與結論都被認為形式有效的情況下，還必須去確認前提事實為真。特別要以論證討論那些易被質疑的前提時。

A.3. 重省思思想中浮現出來的論證

• 前述 A.1 與 A.2 描繪了一個過程：應不停嘗試各正負面論證，直到最終找到可被強健論證支持的結論。
• 即使在結論確立之後，仍要以不同形式之論證與規則去確認這些方式中哪個可有效導到結論。也許嘗試不同論證可以發現比最初得結論版本更為健全者。
# 即是利用前幾章所述規則與改進方式去增強自己論證的健全度。例如增加例證、標明出處與說明權威背景等。此種修改論證的工作越早在此階段作，就能以越低成本在發現論證有誤或說不通時改變主意。若是在已經準備動筆時，甚至是動筆後才發現論證不足，則修改的成本將很高，且效果不佳。

《A Rulebook for Arguments》筆記：第六章

演繹論證

演繹的好處在於只要確保前提為真，則結論必定為真。其他論證法則多少無法保證這點。

然而真實世界很少能確保為真的前提，因此真實世界的演繹論證仍有風險。但即使前提未能確立，演繹也是組織論證的好方法，特別對於論證性的論文而言。

本章將介紹演繹論證常用的幾種形式。

#24 若 P 則 Q

• 形式：P 導致 Q ；而今 P 存在；因此 Q 必為真 ( 存在 )。
  
• 「P 導致 Q」與「P 存在」兩個前提都要以論證方式解釋與證明。且針對兩個前提，需要用不同形式的論證去解釋與證明 ( 前者是因果，後者是存在性。兩者要注意的規則不一樣，因此方式也不一樣 )。
  

#25 若 ~Q 則 ~P

• 形式：P 導致 Q ；而今 Q 不存在；因此 P 必為偽 ( 不存在 )。
  

#26 假設三段論法

• 形式：P 導致 Q ；Q 導致 R ；因此 P 導致 Q
  
• 此連鎖推論的長度可以不停延伸，且此形式可作為因果論證中，解釋因果關係的良好模式。其結果「因此 P 導致 Q」可在因果論證中作為結論，連結因果。
  

#27 分離三段論法

• 形式：P 與 Q 必存在其中一個，但不能同時存在；今不存在 P ；因此 Q 必存在
  
• 此處英文用「OR」其實比較不好，應該是「XOR」比較正確。
  

#28 二分法

• 形式：P XOR Q ；P 會導致 X ；Q 會導致 Y ；因此結果不是 X 就是 Y 。
  
• 也有可能 X == Y ，因此兩個原因會造成相同結果。此處要注意是 X 與 Y 除 P 與 Q 外不能有其它原因，否則推論會不完全而失敗。
  

#29 歸謬法

• 論證順序如下
1. 欲證明 P
2. 故意設為 ~P
3. 因為 ~P 必會導致 Q
4. 但 Q 顯然為偽
5. 所以 P 必定為真
• 歸謬法的重點在於證明 Q 在 ~P 之下必定為偽，因此使前提 P 必須正確不可。

#30 組合演繹

• 組合演繹是一段論證，透過 #24 至 #29 之各種演繹法組成。通常是前面演繹的結果作為後面演繹的前提，因此環環相扣證明正確。
# 似乎重點在於要從平常對話式的推論中拆出前提結論等元素，並要適當加上「如果…則」這樣的輔助字眼。重整後的論述有時順序可能與對話相反。

《A Rulebook for Arguments》筆記：第五章

關於因果之論證

因果之論證，即找尋二或多個事件之間的因果關聯。要達成此目標，通常很難，也應避免濫認事件間有因果關係。因大多數的事件，即使時間相近或總是伴隨出現，也不見得有因果。因果關係是「有關係」當中較難確認的一種。

找出因果的嚴謹過程可能使得相關人物，因為必須要有大量研究而成為權威專家。而一般人推論因果的工具與想法通常都有不足。

#18 解釋為何因能成果

• 不是只有說明 A 與 B 有關係，而是要證明 A 如何造成 B 。即是要解釋其中的影響機制。
  

#19 提出最有可能的原因

• 大多數事件都有多個可能造成的原因。因此，要找「最」有可能者。就如同醫學院「如果你聽到了馬蹄聲，你第一個想的會是馬，而非斑馬。」，超自然或其他類似最不可能的原因應該放到最後再考慮。
  
• 如何得知何為最有可能的原因？可以先以合於我們所信、可靠，如自然科學體系下的事物。
  
• 在任一事件被卻認為原因前有時要有多量的證據，尤其是有多個可信度相近的解釋時。
  

#20 關聯事件可能並無因果：巧合

• 看來時間相近或有關聯的事件要確立、要靠實驗，有確實的解釋與證據才能認為是因果，否則很可能只是巧合。

#21 關聯事件可能因共同因素而造成

• 有時看來有因果關係的兩個事件實際上可能並無因果聯繫，而是因為其更深層的共同因而一同產生。例如開放心胸與好讀可能並非因果，兩者可能都是因為「上過學」這個因素而共同產生。因此。
• 另外，看來有正比、反比關係的事件也未必為因果事件。

#22 關聯事件可能互為因果，或可能倒果為因

• 最好能確定 A 可以造成 B ，而 B 不可能造成 A ，才不會發生倒果為因或互為因果的現象。
  

#23 因果可能很複雜

• 例在危險路口畫斑馬線，反而使得人口上升，結果交通意外總數不減反增。這例子當中有多個因果、影響者存在。
  

研究事件因果的重要不僅在於確認，而在於現實中可以利用。即使因果並不強烈而僅是「有可能」，也足以使人們採取行動避免這些可能導致危險的原因。

《A Rulebook for Arguments》筆記：第四章

訴諸權威的論證

權威論證的形式： X (可靠的權威來源) 言及 Y -> 因此 Y 為真。

此種論證的風險在於每個人都有個人偏見，會因此誤導人。

#13 來源應具可受檢之出處

• 所說的事物無法並非明顯為真實，應附上來源出處。包括誰、何時、何形式等言明某前提的背景知識，而不是模糊地用「自己曾經看過」之類的來源。
  
• 附上來源的重點在於讓其他人可以公開找到同出處，以檢查論證是否有誤。
  

#14 尋找來源之背景知識

• 若權威的知識背景、經歷不是顯為人所知時，論證中應簡要解釋。可放在前述標明出處的註腳說明。
  
• 注意若前提並非權威能知或非其專業領域，則不可靠，還不如非權威但是為直接調查者之來源。
  
• 有時權威因為立場或既得利益因素不可靠 ( 如政府不公開或扭曲事實 )，因此要依賴不完美但更好的來源 ( 如人權組織 )。此種情況要使讀者知道，使其能自身判斷來源可信賴與否。
  
• 最後，要小心那些宣稱不可能為外人所知事實 ( 如名人醜聞或軍事機密等 ) 的權威。其所言通常充滿猜測等不可確定之事。
  

#15 尋找較全面的來源

• 雖說有利害關係者本就不可靠，但由於「真相」可能有多個面相，即使完全誠實者所說事實也不全面。
  
• 所以，不要只依賴於一方的來源，尤其對那些有利害關係之來源要謹慎。
  
• 獨立來源要檢視其是否真為「獨立」，或僅掩人耳目。這包括要檢查其受資助之情形，即其他有關此來源的報告或資訊
• 對於有出處 ( #13 來源應具可受檢之出處 ) 的論證而言，還要確定其並未斷章取義。
  

#16 交互檢查來源

• 當專家有不同意見時，不要只依賴其中一位或一部分意見。例如針對政府人權情況，應該從多個人權組織綜合出報告，而非僅依賴一個組織的資料。
  
• 對大而難的事物要求專家意見都一致更為困難。此種情形下，只選擇部份專家觀點是不對的。
  

#17 人身攻擊無礙來源資格

• 未知經驗與學術背景、不全面等會損害來源的品質、資格，但針對權威人身攻擊並不會使其言論可信度下降。

《A Rulebook for Arguments》筆記：第三章

類比論證

前述 #8 ( 不要以孤證導出結論，多舉例子 ) 有例外：若有可類比事物可支持結論，則不需大量舉例。此種方式在於從特別的例子，透過類比作為可用且確實的前提。其重點在於證明所要證之事物與類比事物之間的相似姓。

#12 類比要有可比的例子

• 形式：X 為一普遍認可為真的前提，Y 為要引至結論 Z 的事物，X 事物與 Z 並無關。今證明 Y 「相似」於 X，因此 Z 應正確無誤。故由類似於 X 的 Y ，導出 Z 正確的結論。
• 前述的形式中，可舉例如下：汽車需要定期檢查，否則容易出毛病 ( X ) ； 人體 ( Y ) 與汽車兩者都是複雜系統，因此人體在這方面類似於汽車；所以人體需要定期檢查，否則容易出毛病 ( Z ) 。
• 作為類比的事物物如果與要證明的事物有不同處，只要該不同性質無礙於推至結論則無妨。

用類比的好處是類比物的性質以被判定為真後，就不需要舉出大量的例子，也可以避免其中的危險 ( 偏頗 )。但若不具可比性則論證將一無是處。