這是筆者從七年前剛離開學校至今,經歷當兵和人生第一份工作(在xXxxxx週刊擔任三年半技術編輯兼系統技術召集人),一直想開卻遲遲未開的專欄。剛好最近熊熊看到fangji開闢PCADV實驗室第一個專欄系列,和電腦王總編輯bobo在MSN上聊了幾句,就…拍板定案了。XD
問題來了,為何三太子上身的痴漢水球會突然發神經做這種吃力不討好又傷身多寫也沒稿費領的事情?
開門見山,如同筆者在達人之路專欄x86處理器發展史東施效顰自日本好友的核心信念:being technical editor for technical editors,不只為了想從「樹大招瘋」的敏感題目切入以溫故知新、奠定屬於自己判斷基準的高階電腦玩家,或資訊科班背景讀者,更寫給為了他們日以繼夜焚膏繼晷埋首測試辛苦工作的「正統」技術編輯。
套句bobo的名言:電腦王的讀者都很機車,愛找麻煩,具備強烈的社群性,並不是一票看看美女正妹照片和勸敗廣告文章就可心滿意足乖乖關掉電腦上床睡覺的人,更不乏標準資訊科班背景甚至技術狂熱者,這大概是我看過最特殊的族群,連純粹企業IT導向的xXxxxx都沒這麼誇張,超級難搞。
要應付難搞的讀者,特別在複雜的技術性議題,要有效的解釋給讀者,沒有很深的認知與理解,是絕對做不到的。我知道很多人喜歡把「雜誌內容就是要讓讀者輕鬆閱讀便於吸收新知」、「編輯心中要有讀者」之類的slogan掛在嘴邊照三餐念,但在無數國外專業資訊媒體司空見慣、耳熟能詳,某些人眼中看似信手拈來、理所當然的精彩圖解,可不是嘴巴隨便講講,就會平白從天上掉下來砸到編輯頭上。以Network World為例,其被視為經典中經典的每週技術名詞圖解Technology Update,還得煩請「該IEEE委員會的規格制定者」親自操刀,作者欄位就掛著一排知名業界大廠的大頭,其難度與門檻,由此可見一斑。
姑且先不論不方便在這邊批評昔日的同行,博觀而約取,厚積而薄發,身為真正專業的編輯或作者,需要起碼讀者「十倍以上的知識基礎」,在醞釀、構思、研究、測試、驗證、撰文、編輯到文章付梓的過程中,也需要持續的自我成長、自我挑戰,講的更白一點,這些更是你日後換跑道的本錢。更重要的是,你有義務協助讀者建立基本的觀念,培養日後足以挑戰你權威的知識根基,而不是把讀者當白痴,貼一堆照片簡報,隨手寫一堆風花雪月不著邊際的騙稿費廢話大玩愚民遊戲(糟糕,我好像砍到自己了 XD)。
總而言之,本「讀書時間」專欄,重點如下:
- 不限定領域與深淺,也不侷限「教科書」,從計算機組織結構、作業系統、系統程式、程式語言、計算機圖學、商用應用軟體架構、資訊安全、系統程式、編譯器、各類網路及儲存技術與網路處理器,都有可能(這餅會不會畫太大了?),不過初期還是先以硬體為主。值得一提,業界人士的回憶錄也不會放過,這可讓讀者熟悉某技術的時代背景和商業策略考量。
- 優先選擇具備完整圖解、規格介紹、歷史資訊與解釋發展脈絡者,除了用來自我充電,也方便設計版面規劃與圖解資訊來節省燃燒腦細胞的時間。這部份將基於筆者個人的經驗,推薦給雜誌的技術編輯和有志於學習相關技術的讀者,甚至稱為「工具書」用來讓讀者自己確認某篇文章到底資訊正不正確也不誇張。
- 不僅限原文書與紙本,或著講的更精確點,其實台灣本地不乏內容精彩詳實聚焦在單一主題的「絕版老書」,國外更不缺讓筆者看到自慚形穢五體仆地的個人網站,只是少人知悉。
- 拜網站之所賜,整理其原作者的相關文章連結與延伸閱讀。其實近年來不少頗具歷史的經典教科書,因內容疊床架屋,為了減少頁數便於裝訂與利於學生教授隨身攜帶,將部份章節與附錄弄成可從出版社網站下載的pdf檔當然有些理論上是非法的,而這些資訊都有極高的實用性。
- 一定筆者徹頭徹尾真正讀過,實際分析全書結構,絕非拍幾頁照片就開始說文解字看圖說故事順便蓋棺論定。
- <秘>我會教各位如何「使用」這些資訊。</秘>
最後,先拋磚引玉,讓各位預知筆者的書評大概有何種「文風」,歡迎提出改進意見(因網站自由度較高,字數就不會這麼少了…可能用詞也不會太拘謹):
好吧,寫再多也不會有稿費領的嘴砲抱怨預告到此結束,謝謝收看。
曾經也是現在,一直希望可以對電腦有一個很紮實的認識,而不是只是玩玩,只是有時候看雜誌或國外的網站,總是覺得好像在門外看,而不知道該如何學,才能至少有和他們一樣的水準,一直在找尋一個適合自己學電腦的方法,希望可以在許多同好的拋磚引玉下,能有更多的心得和啟發,期待作者的「讀書時間」專欄發表。
P.S.
第5點後面…是順便還是「隨便」蓋棺論定啊~~
筆者不會也是01的愛好者吧
期待你的讀書心得報告啦。
但還是得先勸你,有心想看的人未必看的懂(像敝人在下我),而看的懂的人大概沒時間回應,所以回應帖的部份可能會有點冷清吧。
我的意思很清楚,這一開始會針對兩種族群:
一、方便技術編輯查詢資料、設計圖解與清楚整理歷史脈絡的「工具型」教科書。
二、推薦給大學科班的「輔助用書籍」,特別是計算機組織結構。(這種推薦我從十年前就開始做了)
然後也不限定深淺和語言(最起碼,天下雜誌也出過不少很不錯的翻譯科普書)。反正還是一句話:我絕對不會說我可以「普渡眾生」,但我最起碼可以對其他的技術編輯,野人獻曝自己過去的經驗。講的更白一點:現在的電腦王編輯部和認識的昔日同行,他們想要的是什麼。
白熊啊,你知道後藤大叔畫那些圖解,要花了多大的功夫啊?害我和他吃飯時都好想把他的notebook搶過來了。XDDDD
最後,那張照片是我週日上午拍的,我很久很久以前也就沒上Mobile 01了。
看你的文章,還不如看真正的教科書來的清楚明瞭,也不會喇一堆低賽。寫在電腦王blog,還是寫給普羅大眾看吧,沒多少人想要在blog上看硬梆梆的教科書啊?醒醒吧,別在活在自己的世界裡了,技術編輯們並沒有想看你的文章。
書籍的選擇,也會和認識的技術編輯討論過(要不然電腦王也不會同意我開這個專欄),才會動筆,沒有比較強烈的工具性,方便找到想要的資料和現成的圖解範例,大概也會被打回票吧。
我不知道我有沒有活在自己的世界,不過昨天已經有過去的同事,看到我的預告,要我有新文章就MSN他,這樣起碼算已經有一個讀者了吧?
事實上,我甚至可以承認,我的文章或多或少,就是應要求,故意寫給電腦王編輯部和昔日認識的同行與同事看的。
最後,有人會認為,我過去寫過的幾篇書評,看過後會認為「自己嗨、自己爽,別人看不看的懂、想不想看都無所謂」嗎?假如真的有看過,不以人廢言的話。
如同我之前和你提的,「笨事總是要有人去做」;是不一定要發「普渡眾生」這種願啦,以我個人的經驗,能有少數人覺得這件事是「值得的」,也已經很不錯了。
目前網路上的確充斥了很多不同來源的聲音,一般網友很難去分辨孰對孰非。你們有著編輯的背景,又在業界工作,能貢獻心得是件很值得讚許的事。
在業界工作的人都知道,每天被客戶盯的滿頭包趕進度已經是很累人的事了,更別說要再花時間花工夫整理,把知識整理出來,以微薄的稿酬 (甚至是沒有) 和大家分享,基本上這已經算是做功德了。
我沒有這麼深的功力,可以把知識分門別類分享給大家,但是很衷心的期望,這個想法和做法是可以對一部份的人產生正面影響的。加油囉。
訪問已經實作出一些偉大成品的人
他們看了哪些書 查了哪些文件 用了哪些工具
例如訪問 pcman 的作者
問他當初高中是怎麼學 c++ / OO / software development 的?
(聽說是自修) 看了哪些書?
怎麼知道 bbs 的 protocol? 去哪查? 問了誰?
怎麼知道要如何跟 Internet Explorer / Firefox 整合?
開發過程遇到了哪些困難?
就我個人學 C++ 的經驗是
念 C++ How to program 搭配 CodeGear C++ Builder (IDE)
先把 imperative programming 學好
然後念 MIT 出版的那本演算法
然後才開始學物件導向
我看了
1.世紀末軟體革命
2.Headfirst OO
3.UML 相關的書
4.OCL 相關的書
然後用 Together 工具來逆向產生 Class Diagram / Sequence Diagram
等等 研讀別人的 code
然後念 Design Pattern / Refactoring
學習 UML Modeling 裡 Design pattern 的用法
以及 IDE 的 Refactoring 功能
然後把一本資料結構的書好好念完
(推薦 Data Abstraction 那本)
並學習 Tororise SVN 等團隊合作開發軟體的技巧
看 Headfirst software development
學習怎麼測試自己的 code
怎麼管理configuration
怎麼知道程式的 bottle neck 在哪裡
然後學習開發 GUI 程式
最後念 Large Scale C++
往開發大型軟體邁進
總而言之 電腦王的讀者應該都很有興趣
但是不一定有天份 也不一定是科班出身
所以寫出完整的專案製作過程
不僅可以讓非科班出身的人理解資工人在幹嘛
也可以讓讀者去仿效這樣的成功模式
既可以知道方法論 有甚麼書好看
也可以學到一些電腦的小撇步
水球先生的CPU專欄...都是理論
比較像讀書心得 或是高級的資工科普文章
對有考試需要的人來說 很有幫助
但如果能加上一些 Live Demo 會更好
好比說寫一些 MIPS 程式碼
讓讀者可以實際操作或修改等等
個人淺見 希望水球兄能參考
很抱歉最近很忙,一直沒時間回應這寶貴的建議。(事實上,我正在北京出差,出發兩天內公司的信箱累積了233封電子郵件,目前還有57封未讀)
說來慚愧,我並不是正統科班背景,也不是programming專門,大學時代修中興電機系的OOP更是勉強低分過關,上面提到的書,我也只確定讀過世紀末軟體革命,C++ How To Program好像有又好像沒有。
不過有一個方向,我想先拋磚引玉一下,事實上,這是一年多前,我對電腦王總編輯bobo主動提出討論,但後來兩邊就忘了,magicfx的留言讓我想起了這件往事。
簡而言之,教讀者如何在自己的電腦上,編譯出最適合自己電腦架構的最高效率程式。這觀念其實並不新鮮,畢竟Unix世界的老玩家早就習慣make install、編譯專屬的kernel,但今天不分作業系統,越來越多的應用程式都open source了,換言之,理論上,一般的電腦玩家,也可以像使用LINPACK和SPEC CPU一樣,透過DIY的過程,自行壓榨出原始程式碼的最高效率。
我舉一個例子:痴漢水球一直百思不得其解,為何eMule每次啟動都跑這麼久,這麼慢,會讓機殼內的Intel QX6700溫度激增,但eMule卻是一個open source的東西,水球就在想,他能不能用一套Intel compiler加上對Kentsfield最佳化的參數設定,或著更好的函式庫,在自己的電腦上編譯出一個可以跑最快的eMule。甚至水球繼續想,我能不能自己打造出針對手邊電腦架構的最佳化Firefox/Thunderbird?
Intelㄧ就常常宣傳用他們家compiler弄出來的MySQL效能多麼偉大。
當然,要做到這件事情並不容易,因為你可能不知道這應用程式的make file長得怎樣、使用哪套編譯器、用到哪些特殊的函式庫、作者有沒有公佈完整的程式碼等等,但這個過程是非常有意義的。讀者可以學到以下的內容:
1. 程式的大體結構。
2. 編譯器的使用法,如有如有字天書的最佳化參數。
3. 編譯器最佳化的手段、對應參數,與為何可以最佳化,如預先編譯執行部份code,收集資訊建立profile,再次反覆編譯,直到二進位執行檔達到最高的效能為止。
4. 為何編譯器可以針對不同的處理器架構與指令集最佳化。
5. 你該怎麼做?
6. 最後,讀者可以親手打造出能在自己的電腦上跑的飛快、更節約記憶體的應用程式,享受DIY的快感。
這DIY的流程,可衍生出的題目實在太多太多了。即使讀者自己不是programmer,也可從中獲益,最起碼,就算那種碰到那種自己看不懂或不想看的文章,就抱怨這篇文章沒人看不尊重讀者怎樣怎樣應該天打雷劈的人,也絕對找不出找麻煩的理由。
這題目,我會繼續思考可行度,歡迎各位提出意見。搞不好到後來,這只是一場大夢也說不定。
和被gcc一統江湖、孕育open source天堂的Unix世界相比,Win32/Win64環境open source的東西,大多數都是不能直接compile的,常常要想辦法裝個跟原作者寫的時候同樣的IDE才行,不同的IDE生出來的makefile格式就不一樣了, 更不用說還要把所有的source/lib擺對目錄。
就算目前Windows世界的IDE幾乎都被Visual Studio支配了,最起碼還有一個Borland在,兩邊的處理方式就不同,更何況,Visual Studio不同版本的搞法大概就不一樣了。
唯一的好消息是,Intel compiler和這兩者都有極高的整合度(我不清楚PathScale和PGI的現況,脫節一段時間了)。即使無法更動compiler,光重新編譯這點,就有機會讓應用程式的效能脫胎換骨了,這就是最實際的價值。
就是用同一套IDE的不同版本來編譯
然後比較效率
例如 Visual Studio 從 6 到 2008 版都編譯看看
然後想辦法去測試效率
並說明為什麼會有這樣的差異
或許水球兄可以試試 Open PCMan
Compiler 可說是 Computer Science 的精華阿!
期待水球兄能夠完成這部份的實驗
即使如此,我還是覺得...意義不大,因為programmer選擇compiler,往往不是performance為先,「介面」和「使用的人數」影響還更大。
更何況,現在managed code這麼普及,純粹產生native code的compiler,重要性已經沒有過去那麼明顯了,如果沒有「實用性」,電腦王也不會接受這樣的內容。