http://ithelp.ithome.com.tw/ironman5/player/tony1223/alll/3

http://ithelp.ithome.com.tw/ironman5/player/tony1223/alll/3

 

因為這兩天把老文章翻出來，所以撰文紀念一下這系列。

 

 

當初鐵人賽寫這系列其實寫鐵人賽是假，真心是想作為指引新手上路的教材。大概就是把我腦袋的東西倒一倒，再用新手的濾鏡濾一濾、看最後會剩什麼。我還記得那時候每天都快死了（我必須說，這輩子真的是不想再來一次了，所以 @Brecht Huang 不要再來拉我了。XDDD）。上班做事下班想範例，真的是無窮無盡的範例地獄。

 

 

像這個例子http://ithelp.ithome.com.tw/question/10101321

 

 

對我來講這種資料表的 SQL 真的是很白痴等級，就算是大學生也應該可以在課堂上學到基本的東西，但我還是把他寫出來了，因為他是我心中知識脈絡的一環。我覺得這就叫系統性的知識，把一件事情所有用到的週邊都要一一列出整理，這樣新手才能夠有所謂的全局觀、大局觀。事實上這多少就是過去書本的作用。現在的書我覺得專注內容的多、但講解脈絡的少了。

 

然後寫作這樣一篇文章，我那時候每篇文章大概短的至少一個小時，長的大概四個多小時。我有時多少會覺得花時間寫太基礎的教學，不如多寫幾個系統創造更多 content。但我也很清楚，基礎性的教學必須有人去做。

 

作為一個業餘技術講者，我必須說我已經花了很多時間在思考什麼是技術的基礎，但要把他表達出來到能夠實用的程度，因為某個程度上我也不太認同目前學校的那一種單一領域專注的教法，所以我一直在挑戰的是混搭式的入門。就像是這二十七篇一樣，從廣度的角度去展開一個技術領域的脈絡，雖然這個作法我覺得是蠻有挫折的。要表達的好很難，光是怎麼從中去蕪存菁就是一個問題。

 

以 css 來講，在有限的時間與篇幅裡面我只挑了 box model ，因為我注重 layout 的構成。但是不管你挑了什麼，永遠都會有別人覺得 ooo 更重要、xxx 也應該提一下。這就是這類問題的困境。然後談 web 一定要談個 backend，我不可能把 JavaEE 拿出來講（光介紹就又過了一個月了），所以就拿我心中的最小單位 php + CodeIgniter 出來講。效果是蠻好的，約三四篇就可以結束動態網頁的基礎回合。

 

 

但這就會限制使用者對於這件事情瞭解的背景跟他們入門的方式。PHP 是個優美的語言，作為已經在上面打滾至少三年的工程師而言，我頗認同 PHP ，但是他只不過是廣大 server side language 中的一環。我還是會呼籲一個工程師應該至少有兩種以上的 server side 語言的經驗，這樣才能夠理解不同語言之間的真正差異。以我而言，我有過 JavaEE 經驗、.Net MVC 經驗、rails 經驗，其中不同語言最重要的差異在於 precompile 跟 static/daemon 的存在與否，當然還有語言本身的生態系也很重要。那種東西是很難透過說明或簡單的比較去指出兩者的不同，親身去體驗看看就能明白這是多麼有趣的一件事情。

 

我認為作為一個深入與資深的 web developer 的條件之一，能夠理解不同語言之間的差異，並且明白自己該往哪裡深入與怎麼利用現有技術補強既有語言的弱點，這是很重要的。在我心中的網頁技術之路，有如銀河一樣，綿延到宇宙的盡頭。

 

 

對於未來我還是以身為一個 front-end 自居，這之中要理解的東西不能說比 backend 多，但就是不同領域，我會去注意視覺動線、去考慮可用性、可靠性跟相關的問題，盡力去對抗因為需求而對使用者造成的干擾。（順帶一提，我現在的想法是我認為任何需求只要是蓄意透過增加使用者不便，以此來達成廣告效果的都只是在消費前端的成果，為生存是難免的。以前端的角度來講，我們必須知道這件事情是不是能確實的把他該死的部份賺回來，但我發現去做評估的其實很少。）

 

 

其實我真正想說的事情是，這幾年不管是 web 也好、backend 也好、front-end 也好，面對著那些剛入門的小朋友，問我們到底該怎麼入門。除了回答"去找你想做的事情，然後靠這個熱情爬過那條荊棘路"，而且"過程得問正確的一個個技術問題，我們才能一個個正確的就你的問題給予回應" 以外，我能給他們的基礎入門資訊，大概不會比這 27 篇文章更多了。

 

而關於問題的部份，一年在網路上能回應到有看得出來他真的想過但想不通的問題，應該是個位數。絕大多數都是不得其門而入的問題，也就是提問的藝術一文中寫到 "我該怎麼做"、"他怎麼就壞掉了"（壞什麼、怎麼壞、你想做什麼都沒提） 這種等級的問題，絕大多數的時候我都只能回提供程式碼、想法，我有時候可以憑經驗猜到問題，但我真的不是通靈師。

 

我對於知識與脈絡的要求是很嚴格的，對於問題我沒有那麼嚴格，但至少得要敘述明確到能看到問題點。

 

 

我當初一年半前寫那二十七篇的中途是對自己的產出還蠻滿意的，覺得就是有點瑕疵，但應該還能靠修正補充，但寫到中後期我就覺得很痛苦，這個領域太大，我無力濃縮所有細節。雖然說最後斷掉的結果是在 yahoo hackathon (另一個榨乾技術與精神的競賽)，但憑良心講，這個系列我當時仍然是無力收尾的。越接近後面我就越覺得收什麼尾啊，內容根本才正要展開而已啊。

 

所以讓他停在這個位置，我覺得算是合理的。

 

 

這二十七篇都是每天要求自己一定要產出內容做出的成果，也很大幅度的在時間壓力下影響了品質，所以我對品質並不滿意；但這二十七篇後來我再也沒去動過，我覺得這某個程度上就是我的極限了。如果沒有時間壓力，很有可能我根本寫不出這系列，而對於品質雖然我有能力對於其中專章論述非常多細節，但要在這種鋪陳脈絡的文章下還要埋進更深的品質，這也是我的極限了。所以，我覺得對我而言我該承認這就是我的極限，來蓋棺論定這件事情。

 

The tutorial of web ，我覺得這個問題還是個該解決與值得解決的問題。即使強者如 Head First 系列，我認為他仍然沒有解決好 Web 的入門問題。

 

 

無論如何，我永遠不後悔花時間寫任何一篇我覺得事後看起來很蠢的文章，每一篇文章都成就我的知識，每一篇文章也都讓別人更瞭解多一些了，不論我當時的知識正確與否，他們總是多知道一些（或者未來會多懷疑一些）。

 

 

而且為了讓自己更有動力做技術寫作，我從不太想把技術文章自己的 blog，不去整理我的技術文章，我跟每個人一樣，都是靠 search engine 紀錄我的文章，然後提供所有人任意轉載與紀錄的權限。（這幾年來有幾十個人問我有沒有自己的技術 blog ）

 

我覺得寫自己的技術 blog 不是不好，就這行的夥伴而言，累積豐富的技術 blog 意味著強大的 credit ，這是毋庸置疑的，我也鼓勵所有這行的新進夥伴去做這件事情。但我很清楚知道，對我的個幸而言擁有一個這樣的 blog ，只會讓我把所有時間都丟進去 refine 每一篇文章（基本上我對於自己所有的技術文章都是不滿意的），然後讓我自己覺得很痛苦。

 

我寧願讓這些文章投進社群討論裡面，該塵封的就塵封、該沒人理的就沒人理、會被戰的也就來戰吧，會被轉載的就是會被轉載，而會被人記得的就會被人記得。

 

 

一件事情如果真的重要，自然會有人去保存與傳閱。那種東西不是我們能強求來的。

 

 

作為一個技術文章的作者，這篇文章紀錄我自己對於技術寫作與技術推廣目前的矛盾。然後再重新省思，對於技術推廣與技術實踐，我們需要與實踐的到底是什麼。當初見林不見樹、後來見樹不見林、接而見山不是山，現在見山又是山。路還遠著很。