種族滅絕 - 高野和明

在30年前，美國智庫就有一份赫茲曼報告，提出了五點人類五大存亡危機。

1. 【宇宙規模的災害】巨大隕石撞擊‧釀成毀滅性的連鎖災害
   
2. 【地球規模的環境變動】地球磁場逐步弱化，當失去磁場有害宇宙射線將侵入地表，滅絕所有生物
   
3. 【核子戰爭】輻射塵覆蓋地球表面，食物資源遭到毀滅性破壞，地球將不再適合人類居住
   
4. 【病毒及生化兵器】人類濫用生化兵器，造成蔓延感染，人類將面臨嚴重的存亡危機。
   
5. 【新種生物】人類再次進化，擁有超越人類智慧的新種生物誕生，我們將如同北京原人般就此消失
   

其中前幾個項目，經過時間的驗證，問題都已經慢慢浮現，曾經觀察過有巨大的隕石撞擊危機，磁場南北交換慢慢地一點一點地發生，核子戰爭依舊是核武武裝對抗下恐怖平衡的夢靨，HIV病毒與超級細菌的發現，而進化後人類的新種生物，也在剛果民主共和國被發現。

面對人類存亡的威脅，自居為老大的美國，依舊先一步掌握了情報主動出擊，而處理的方法，也是一貫清除與毀滅對方的方法。但是在智力超前進化的新人類面前，不但可以輕易進行PKI質因數分解，還能掌握地球的自然現狀，為了求生存，他們兩人一步一步地創造出自己的生存空間。他們不求和解，但也不反噬，而選擇以最聰明的方式，安穩地生存下去。

在確認自己生存的威脅下，除了美國選擇以對抗及消滅的處理方式，還有日本的古賀父子、皮亞斯這種接納並尋求共生的方式，但也有可能在掌握了權力與力量後，一切都會有變化。亞齊里與惠麻這兩人，從一開始就知道，在利用了古賀父子、皮亞斯等人之後，就要毀滅GIFT以及其他的工具，因為這樣才能避免人類反噬的狀況發生，不會破壞共生的條件。

這的確是一本從頭到尾就很精彩的科幻故事，最終新舊人類之間，還是選擇井水不犯河水，各自以自己的理念生活下去，這是另一種的恐怖平衡。

《種族滅絕》新書預告第一彈：「赫茲曼報告篇」

《種族滅絕》新書預告第二彈：「東京-研人篇」

[試讀心得]種族滅絕

種族滅絕：神、人與黑猩猩

閱讀/試讀226《種族滅絕》身為人類該有的省思 讀後心得

讀《種族滅絕》

種族滅絕

銀河鐵道之夜 by 宮澤賢治

每一個到了另一個世界的的人，都會幻化為天上的一顆星星，每天在高空中看著我們，照顧我們。銀河鐵道是這些人前往星星的專屬列車，同時也連接了現實跟另一個世界。

宮澤賢治詩作《不怕風雨》 讓人直接感受到的，就是一個人的堅強、自足、包容、關懷、堅持。堅強地面對風雨冰雪，自足於簞食瓢飲，不受貪慾，不改其樂，包容異己，關懷周遭社會，堅持面對自我。

作者宮澤賢治在自序中，雖然也自嘲：「在這些故事中，也許有些對您有益處，有的沒有，關於這一點，我自己也無法分辨其中差別。其中有些部份，或許您讀了會覺得一頭霧水，其實我也不知道為什麼會寫出這些內容。」

或許我們也該順應這樣的想法，把宮澤賢治的故事，當成從未知的異世界代理而來的作品集，就這樣自然地接受這些字句，然後再未來的某一天，回想起故事中人物的遭遇。

沒有艱澀的文字，但每一個字句都讓人有著深刻體會，也因為這樣，才能造就這百年的經典文學。更令人讚賞的，是能推廣並影響到每一個小學生，成就日本的文化根基。

在我現在能想出來的印象中，經典的華人童話故事，似乎都是一些神話故事，例如封神榜，還有一些節日相關的故事，例如中秋節的嫦娥、年獸、老鼠娶親等等。想不出來有類似宮澤賢治這樣淺白但又發人深省的故事或文章，中小學的課文文章中，小學課文都是一些很奇怪的短文，一直到了中學，才開始有一些文言文的賞析。

看了小朋友國語課文學習的東西，除了最基本的識字、寫字、認詞之外，有一部分成語，有一部分我最不能接受的，就是要學習十幾種修辭法，那些單純是文學研究者整理出來的一些修辭專有名詞。

對小朋友來說，從文字裡面去思考作者背後的隱喻，或是引申出來的含意，才是文學賞析的重點，也是讓文化內化影響至每一個人的方式，但是考試引導教學的結果，就是得被迫接受一些學者包裝出來的一些知識。

用童詩去搜尋得到的結果，最知名的作者是林良老爺爺，例如：我喜歡：林良x貝果，孩子的第一本詩歌繪本日記，詩文也一樣淺白，但卻感覺是白描日常的生活，少了一些引導人們思考的空間。

宮澤賢治 wiki

銀河鐵道之夜

久石讓- 銀河鐵道之夜.wmv

久石讓非主流專輯之一：銀河鐵道之夜

Markdown

Markdown 是簡化的 html 語法，主要目的是用來作為一種網路內容的寫作語言。

曾經看過 Zen Coding ，他的目的是簡化Programmer撰寫 html code。Mardown是類似的概念，但目的是讓網頁撰寫更直觀。

html 是遵循了 xml 的格式的一份純文字文件，但因為 well-formated 的格式規範，直接用文字編輯器撰寫時，需要很辛苦地鍵入很多 tag 標籤，還要 close 標籤，整份文件也全被 tag code 搞亂了，不能很直接快速地看到內容。

一份簡化的撰寫規則，不但能減少打字的effort，還能在檢閱文字內容時，更容易發現一些錯字或語意的問題。

常用的語法

#  這是標題 H1  
## 這是次一層的標題 H2  
>  這是引言 blockquote  

[網址的標題](網址) 這是網址 href   
<網址>  這是沒有標題的網址 href  
![圖片替代文字](圖片網址)  

* 沒有排序清單第一項  
* 沒有排序清單第二項  
* 沒有排序清單第三項  

- 沒有排序清單第一項  
- 沒有排序清單第二項  
- 沒有排序清單第三項  

1. 有順序的清單第一項  
2. 有順序的清單第二項  
3. 有順序的清單第三項

_斜體字_  
**粗體字**  

[^1]  註腳

行末加上兩個空白就會換行
一個空白行，就視為一個新段落
縮排 4 個空白或是 1 個 tab 就可以變成程式區塊  
*******  三個或以上的星號、減號、底線來建立一個分隔線

支援的工具

Emeditor 有支援 Markdown 的語法高亮顯示，可以到 http://www.emeditor.com/files/markdown-esy/ 下載 markdown.esy，然後根據下列步驟匯入資料。

1. 點擊 Tools -> Select Configuration -> Define Configurations

2. 點 New，然後直接點 OK

3. 修改 "New Configuration" 為 "Markdown"

4. 選擇 "Markdown"，點擊右邊的 Properties

5. 點擊 "Hightlight(1)"

6. 點擊下方的 "Import"，選擇 markdown.esy

編輯文件時，只要選擇 Markdown 的 configuration，就可以看到 markdown 語法的高亮顯示。

Windows 有另一個工具 MarkdownPad，可以直接在左邊編輯 markdown文件，右邊就看到 html 結果。但是，我在使用右鍵裡面的 Copy HTML 功能一直發生 Open ClipBoard 的錯誤，把Markdown文字框起來，直接點選單 Edit, Copy Document as HTML 就可以避掉這個問題。

其他參考文件

相關的語法說明文件也可以參閱

Markdown 文件

Markdown

簡單易學的Markdown文字標記語法

Markdown 语法精简版

史上最強哲學入門：解答你人生的疑惑 & 東方哲人 by 飲茶

「哲學」對大家來說，並不是一門得以自然地親近的學問，沒有重複不斷地反省思考的習慣，就很難體會為什麼會產生這些哲學理論。以哲學入門為出發點的這兩本東西方哲學書，最重要的是作者「飲茶」把枯燥的哲學理論跟說法，換到了生死格鬥的舞台，在哲學思想的對抗舞台上，以個人的得意格鬥技來一較高下。

內文雖然寫得還蠻精彩的，把每一個人的名言，重要的中心思想都交代地很清楚，可惜的是，就哲學格鬥這個主題來看，僅僅到了人物介紹這個階段，整本書就結束了。既然要格鬥，如果能在最後一章，看到所有出場人物在同一個場景或是故事下，互相較勁，那就更完美了。不過光這一章，可能就得花一段很長的時間才有辦法寫出來。

作者的哲學格鬥概念是從漫畫刃牙得來的，但中文版並沒有把這個部份翻譯出來，史上最強哲學入門 這篇文章提到了：作者飲茶表示，唯一小小的遺憾，便是藏在書封下「最想傳達給讀者的訊息」，卻沒有出現在中文版，所以另外做了翻譯。

哲學格鬥的概念很有趣，但實際上寫出來，卻好像是好幾個哲學家在那邊打嘴砲而已。這也沒辦法，哲學思想只能用文字或語言表達出來，這是沒辦法形於外，轉換成武打動作或是行為的。換個角度來看，或許用 Liar Game、賭博默示錄 這種，用個人的人生去下賭注，在過程中體悟出必殺技，心理戰格鬥系比較適合哲學格鬥的題材。

作者說「飲茶」這個筆名是隨手拈來的，但也應該沒那麼隨便，飲茶這個動作，背後代表著這個拿起茶杯的人，正在思考與消化接收到的資訊或問題，拿起茶杯喝下一口，緩和了對答的緊張氣氛，創造出一些思考的時間，最後才能放下茶杯，給出一個說法或答案。

《刃牙》~暴力美學極致的漫畫

史上最強哲學入門──東方哲人
書名：『 史上最強哲學入門：東方哲人』
書名：『 史上最強哲學入門：解答你人生的疑惑』
史上最強哲學入門讀書心得
光憑飲茶解讀「方便法門」這一點，你就不該錯過《史上最強哲學入門~東方哲人篇》
史上最強哲學入門：西方哲學家VS.東方哲人大集合

來自程式的試煉 Cracking The Coding Interview by Gayle Laakmann McDowell

作者以她自身第一手與數百位求職者的面試經驗，加上由求職者與面試人員提供的數千個問題，整理出一套 Programmer 的求職攻略本，正如作者在前言中一開始就提到的，即使擁有一份完整的履歷，完整第複習了CLRS，如果不熟悉現場面試時可能會發生的狀況，也會在面試中敗北。

這樣的狀況體現出學校教科書的教育，跟職場中實用的技能與規則，的確有不少落差，換句話說，學校的教授自己也只是一直在學術界打滾，怎麼能期待能從教授那邊學到什麼實用的技能？怎麼會知道，屏除了教科書的限制之後，在實務上，最常遇到的問題與狀況是什麼。最重要的原因就是，面試人員只會問他最常用，也認定最一定要會的東西，先反過來瞭解面試人員的生態與狀況，就能掌握一部分求職的最佳技巧。

作者明顯是把求職這件事作到某個極致，除了出一本書持續改版之外，還開立了一個專門收集與討論所有求職相關問題的網站CareerCup，包含了面試會遇到的問題、薪水、履歷表。但最受大家關注的，還是指標科技公司 Apple、Amazon、Facebook、Google、MicroSoft、Yahoo 的面試內容。

從這本書的內容可得知，在求職的過程中，最在意的是首要是履歷，再來是要準備回答行為式問題，然後是技術問題，最後則是工作條件的評估與協商。

對我們公司來說，面試的時候會分先區分為兩種求職者，第一是有經驗的轉職人員，第二種是沒有經驗的畢業生，在履歷中很快就可以得知這方面的資訊，接下來，就是行為式問題的部份，有經驗的轉職人員可快速根據他履歷中披露的專案經驗，來設定一些問題的內容，沒有經驗的畢業生就比較麻煩，因為沒有經驗，如果再加上在學校中沒有做過什麼專題研究，就很難形成一些行為式的問題。

接下來，通常我們就會詢問求職者，興趣、社團活動等等活動的內容，藉此取代專案的項目進行行為式問題的問答，在問答的過程，我們通常會觀察求職者的個性與習慣動作，藉此判斷究竟他適不適合進入這個團隊中。最重要的一點，就是要問自己，願不願意跟這位求職者一起工作，這部份在問答的過程中，就能很明顯地感受到，彼此之間的溝通與互動有沒有障礙。但或許是目前公司還不大，其實能夠容忍的成員個性與範圍就比較狹窄，如果公司大一些，相信這個部份的考量，接受度會高一些。

行為式問題的內容，通常是根據不同的專案，再搭配以下這些最常會被問到的問題項目：

1. 最大的挑戰
2. 獲得什麼、學習到什麼
3. 最有趣的部份
4. 最困難的程式錯誤
5. 最享受的部份
6. 與團隊成員間的衝突
7. 你的缺點是什麼，如何克服它

書本提到了 Situation Action Result（SAR）環境、行動、結果 法則，來判斷求職者的表現，求職者必須在回答問題時，能夠很明確地，思慮與邏輯清晰的狀態下，把自己的答案與意見表達出來。

這些行為式問題，對我們來說，影響的範圍佔了一大部分，甚至比求職者的技能高低還重要。不過。

轉換角色，假設我現在是求職者的身份，當面試者要評斷我的職能等級時，當然得準備基本必備的 programmer 常識問題，關於架構、Pattern方面的問題，看了很多，但或許我應該要花些時間，重新的去review關於資料結構、概念與演算法的東西，即使是 Java 某些時候，也該盡可能地去節省資源，不過還得先判斷 OO 設計跟資源節省之間的得失，在書本裡提到四類技術方面的面試考題：
資料結構、概念與演算法、知識型、其他

資料結構方面，必備常識列表為

1. Linked List
2. Binary Tree
3. Tries
4. Stack
5. Queue
6. Vector/ArrayList
7. Hash Table

演算法方面，必備常識列表為

1. Breadth First Search
2. Depth First Search
3. Binary Search
4. Merge Sort
5. Quick Sort
6. Tree Insert/Find/etc.

觀念方面，必備常識列表為

1. Bit Manipulation
2. Singleton Desgin Pattern
3. Factory Design Pattern
4. Memory [Stack vs. Heap]
5. Recursion
6. Big-O Time

對應到實際上的工作內容，我們實務上會遇到很多邏輯上的先後與條件判斷的問題，但是卻比較少遇到特別的演算法問題，資料結構的部份就常常遇到，因為總是得思考，在該功能開發的過程中，應該怎麼在記憶體中存放足以描述問題的資料，得選擇並決定要使用什麼樣的資料結構，這時候，就會需要有 Collections Framework 的知識，在 Server Side 的程式設計考量中，還得加上要判斷會不會有多個 Thread 來存取這個資料，當遇到 multi-thread 的狀況時，判斷什麼時候要同步處理就很重要了。

Design Pattern 跟 Refacting 我們視為是 Software Design 的基本常識，我不需要也沒辦法記得所有 Pattern 的名字跟 Refacting 的方法，但是必要時，我會查到應該使用什麼 Pattern，在什麼時機，應該適時地進行 Refacting。