本週的策劃工作會議上，方舟指出，有本書稿目前還存在著比較嚴重的問題，還不能開始編加。
我有些納悶是什麼問題，結果方舟給大家在電腦上一講，我馬上就明白了。因為這本書稿和我春節期間在審閱的一本書稿的問題是類似的，那就是，作者是以技術文件的風格在寫，很多環節都直接跳過去了，上下文嚴重缺乏銜接。無論目錄還是正文，都只是給少數懂行的人看的，而不是給更為廣大的讀者看的。從技術文件到成書，其實還有很長一段路需要走。尤其是目錄，方舟說的對，如果這種目錄和正文拿去成書，讀者會覺得莫名其妙的，雖然作者心裡很清楚他在寫什麼，但畢竟書是給讀者看的，如果不能貼著讀者的需要來寫，就不可能得到讀者的支援。
這個完全不怪作者，人家是第一次寫書，我們不去設想對方會缺乏經驗，卻想當然地以為他會寫得很合要求，這顯然是我的問題。因為這個選題是孟巖推薦的，孟巖非常稱讚作者的水準，而我一向信任孟巖的眼光。我也到作者的部落格上看了作者的文章，覺得不錯，只是別字有一些，但因為想到是孟巖推薦的，就想當然地認為會非常不錯。殊不知，孟巖說的「非常不錯」指的是內容，而我不能把這種對內容的高度評價與「已達到出書水準」給弄混了。但我偏偏就給弄混了，所以，就交待給編輯來聯絡這位作者。編輯上報選題的時候，我也只是大致看了看編輯填寫的**，對這本書稿的目錄和樣張根本沒有認真看就放過了。接手的是新編輯，人家沒有經驗，我怎麼說，他也就是照著做，所以不能怪編輯，責任完全在我。
現在，需要認真和作者談應該如何把乙個技術文件經過努力，達到成書的要求，這中間甚至會是一道很寬的溝，編輯需要做的就是幫助作者跨越這道溝。這次去上海出差，我會和編輯們當面與作者溝通，首先會認真做檢討，為自己的想當然向作者道歉，求得原諒，然後和作者一起**，如何讓乙個有些零散的文件集合變成一本結構嚴謹、適應讀者閱讀心理的成書。而今後，無論是誰推薦的選題，如果目錄和樣張沒有經過我們內部流程的審定，都不能隨便上報和通過。
昨天的例會上，我和xiaofei、linux一起做了檢討，為我們做事上的不求甚解、想當然做深刻反省。大家都認識到，無論來自什麼樣的權威的推薦，都不能代替我們自己用眼睛去看，用頭腦去分析，用心靈去感悟。想當然的根子是思考方面的懶惰，存在僥倖依賴心理。
多虧我們在流程上尚有多層把關機制，而且多虧在技術初審這個環節有方舟這樣的編輯的認真把關，否則這樣的書稿交給新編輯來負責，對新編輯也是很不負責的，會讓新編輯無從下手來編輯。
昨天，我們三個做檢討的人都感到十分慚愧，但我們也都會好好用心改進的。
是我想當然了
這是我第1個帖子關於rails的帖子。其實，聽到rails有好些日子了。2年了吧。不過，從沒有實踐。早兩天，想看看rails的activerecord，因為我想看看它的sql是如何產生的。原因是 如此orm?看源 我才發現原來我錯了。是我想當然了。我想當然，它能支援多資料庫。應該同hibernate...
c ,要細心不能想當然
兩段想當然寫下的 你看出問題了吧 1class data 2data finddata 3void getdata data dataptr 47 data data null 8getdata data 9data somefunction 第二段 更得仔細點 1classa 2 classb 3...
測試小故事48 想當然
想當然是一種託詞，是不明事理的妄加揣測。我覺得，我認為，我以為。想當然，乙個團隊中總是或多或少的存在著一些想當然的因素，軟體專案也存在同樣的問題。專案過程中，總有人想當然的認為專案經理會對專案過程負責，也就有了偷懶和渾水摸魚的現像存在 專案管理者想當然的認為任為分配下去了，一切都會按計畫進行，所以萬...