?

聲明：

Technorati 標記: IT生活

本文檔來自：http://developer.51cto.com/art/201203/321936.htm

宅男程序員給老婆的計算機課程之0：認清本質

這個系列來自一位宅男程序員，這個系列是他寫給老婆的電腦課程。以下，開始本系列的第0篇——認清本質。只要掌握了編程的思想、數據結構、算法，使用不同的語言去表達是很容易的。

【51CTO獨家特稿】從今天起將開始的這個系列來自一位宅男程序員，這個系列是他寫給老婆的電腦課程，后來經他老婆的建議，決定在51CTO這個平臺上公開出來與大家分享。

在系列開始之前，先介紹一下兩位主人公——

男主角：Wuvist（新浪微博），真名翁偉，自稱胖程序員一個，幸好已婚。學習.net出身，現常用python做服務器端開發，曾任新加坡某創業公司主程。公司被techcrunch blog過后，覺得新加坡生活太過安逸，終于于去年辭職只身回家鄉汕頭創業，活躍于珠三角技術沙龍，熱衷于與其他技術宅分享。

女主角：Katze，Wuvist的老婆，女程序員，在某跨國投行任Unix系統管理員，常被Wuvist嘲笑技術太差。

總之，因Wuvist只身回國創業，這對分隔天涯的技術宅男宅女竟然想出了定期寫技術課程、交作業這種方式來保持聯系，這何止是令人發指？簡直就是令人發指！

技術宅的你，想看看他們究竟是如何令人發指嗎？以下，開始本系列的第0篇——認清本質。

×××大學計算機系有兩門課：CS 1101 / 1102。

幾乎所有的大學計算機系課程都有兩門類似的課程；但幾乎所有的學生都誤解了這兩門課；以為前者是教C，后者是教Java；但實際上前者是 Programming Methodology 后者是 Data Structure and Algorithm。

所以這兩門課可以有選擇，1101c 或者 1101s，使用不同的語言作為媒介。語言并不重要。

只要掌握了編程的思想、數據結構、算法，使用不同的語言去表達是很容易的。

會了很多種電腦語言后，學一門新的編程語言，幾乎只要花一個晚上看看官方的語法文檔就可以立刻開始使用做東西了。最多就一個星期。

基本上，那些說長時間說自己在學C#，學java的程序員，都是2B程序員，他們完全不懂得程序開發中“思想”、“數據結構”、“算法”的本質，而將大量的時間耗費在語言實現的細枝末梢中，純粹浪費自己時間。

不同的語言會有不同的特性，有一些特性是比較重要的，普遍存在于多種語言當中的，“學習”一種新語言，實際上僅需要查看文檔，看這種語言是以怎樣的語法支持這些特性而已。

=========

OO是影響很廣的編程概念，基本上，是Enterprise Developer（注：企業級開發者）的圣經、法則。

ED認為，越OO越好。

基本上，計算機業界有兩批人，一批是真正的程序員，或者說hacker，一批就是ED。

ED實際上是企業的工具，他們很少有自己創新的想法；企業說啥米，就做啥米。所以，會有大量的vender，提供工具、支持、新技術，去train這些ED。

典型的vender有微軟、IBM、Oracle等等；這些vender為了向企業推銷產品，他們就經常會鼓吹一些新的“技術”，然后打包成為解決方案，推銷給企業。

為了鼓吹、宣傳這些技術，還有一批企業是專門在“布道”的，他們是所謂的“咨詢公司”。

這樣的咨詢公司，他們會專門聘用一些所謂“Evangelist”，屁事不做，整天四處布道，名頭都很牛逼，如XX金牌講師。

他們實質上，就是推銷員，只是，他們推銷的產品，是所謂的“新技術”而已。

微軟在新加坡好像就招了不少Evangelist 。每隔幾年，微軟所推廣的技術就會“革新”一次，Evangelist們就不斷的四處去宣傳新技術改變了一切，能夠提高效率無數倍。

Evangelist本身的技術，很多是很差的；就好像推銷員本身，是不會做產品開發、不懂技術的。他們僅僅是會宣傳、鼓吹新技術而已；滿口各種新技術名詞，但他們本身，可能僅僅只是會使用這些技術寫一個Hello World。

因為他們本身素質很差，所以，他們是無法分辨他們所推廣的技術本身是否好，他們只是復讀機。有時候，vender本身在推的技術也其實不錯，但復讀機們也會把它夸張到荒謬的地步。

OO就是一個典型。

OO僅僅是無數編程模型中的一種而已，但它被過度的夸張，詮釋。

Hacker們寫程序，基本不會去追求程序本身是否符合OO規范。Hack這個詞的意義本身就在于打破規范。

但是，大多數的ED是很笨的，他們缺乏獨立思考的能力，他們需要被Train，而無法自學。Hacker的那套，他們接受不來。

所以，才會有vender / consultant / 培訓學校一系列的產業，去鼓吹：

OO、XML、SOAP、Web Service、Silverlight等等一系列偽技術。

有的ED，一輩子都無法意識到他們實際上是中了vender的圈套；無法掌握真正的編程技術，而沉迷于vender們所鼓吹的“新技術”，一代接一代。

然后，只要有其中的一代技術ED沒能掌握，ED就立刻被淘汰了；因為這種ED，窮其一生都沒有學會真正的編程；他們僅僅是學會了一代又一代的被封裝的偽技術使用技巧而已。

偽技術的典型特征是封裝。

它本身沒有任何新的東西，只是把舊的技術封裝一下，換湯不換藥而已。

OO是最好的封裝技術；所以它被無底線的推崇。

封裝很重要；但是，對于程序員來說，掌握封裝技術本身，跟學習使用別人封裝好的技術工具；是兩回事。

“程序員從此不再需要關心XXX”，這是evangelist最常用的宣傳語句；2B ED，看了就很高興，然后拼命去學習新的“技術”，把他們曾經掌握的XXX底層技術給忘掉。

微軟所宣傳的理念被Hacker理解為“Even monkeys can code”。ED被evangelist鼓吹的新技術洗腦，最終就是成為monkey而已；所做的工作，毫無技術含量；很容易被淘汰。

所謂的程序員30歲必須轉行這種說法，便是源于ED被洗腦。

這種ED，從未掌握真正的編程技術，是必然被淘汰的。

=========

而這種ED，在大學時，就是把cs 1101 / 1102理解成為教 c / 教 java的那群人。

他們，從一開始就走錯了。

=========

作業（編輯說明：在技術宅和他老婆的故事中，只有女主人公完成作業之后，男主人公才會發出新課程。當然，身為看客的您可以無需完成這些作業，但如果您仍是學生，或者您正在帶學生或小弟的話，倒是可以做個參考）：

1. 用500字講述什么是Programming Methodology?

2. 列舉10種Data Structure.

3. 列舉10種Algorithm.

【作者聲明】Katze實際上是正宗計算機系科班出身，而且大學成績甩開Wuvist九條街，這其中還包括算法、計算機架構等傳統上被技術宅男壟斷的科目。Katze畢業后長期于投行從事Unix服務器運維工作，故研發編碼水平會被Wuvist嘲笑；但Wuvist不會寫shell腳本時，絕對是第一時間向Katze求助。

Wuvist寫的這系列教程以及作業安排，是為Katze量身定做的，像第1課的作業便因此會出現Perl這門研發中不常用，但在運維中卻非常普遍的語言。這系列Wuvist是寫給老婆的私人課程，其中充滿了各種主觀偏見，有緣發布到51CTO來，各位看官若看得不爽，請盡管拋磚頭狠踩，但是請盡量噴得準確、到位、兇狠一些～

宅男程序員給老婆的計算機課程之1：認清實際

“算法”、“數據結構”等，是本質；很重要，需要掌握，但一般開發時，很少需要自己去實現。

覺得多數開發，是“拚積木”。

即便是業務邏輯需要對一些數據進行排序，也不可能自己去實現一個quicksort算法；而是直接調用quicksort的現成類庫。

這也直接造成了2B ED窮其一生都不能掌握真正的編程能力。

他們認為，能夠“解決”問題就好，至于問題是怎么解決的，他們并不關心。

對于細節的認識、掌控能力，直接造成了水平的天淵之別。

以拍照為例子，以前人們用傻瓜相機，現在人們用iPhone去拍照；很快，很方便，還可以加濾鏡。

但是，普通人們在不了解什么是光圈、精深、背光等概念的情況下，是沒有可能成為攝影師的。

即便他們放下iPhone拿起DSLR。

普通人跟攝影師拍攝同樣的東西；出來的照片也許會差不多，但如果深入去比較，景深、角度、光線、取景等等等等細節，則都會有差別，而這些差別積累起來，就造成了普通照片與攝影作品的差別。

畫家要畫好畫，必然要對畫筆、顏料、紙張的特性有深入的了解。

廚師要做好菜，必然要了解食材的特性，對調味料、廚具等有嫻熟的掌控。

ED的“解決問題就好”，跟沒有下過廚房的千金×××拿著菜譜使用微波爐做菜沒啥區別。

在大廚手里，微波爐也可以是神器；但：

“有的人，縱然神刀在手，亦無法成為刀中之神?！?/p>

程序員要“拚好積木”，那必然需要對積木的種類、材質、特性，有深入的了解。

總得對quicksort的實現有認識，才能夠用好quicksort。在有的場景下，quicksort的性能反而是最差的。如果不了解，就無法去把quicksort用好。

程序開發中，有一個著名的 80 / 20 原則。

我想，這個原則也可以適用于ED。

程序員只要花20%的努力就可以成為一個混日子的ED；80%的程序員均是如此。

但如果要成為一個優秀的程序員甚至hacker，那么，需要花多至少4倍的努力。

有什么積木可以用？積木本身是怎么做的？積木A比積木B好在哪里？

這些，是需要花大量的時間去了解。

全部都是實在的經驗積累，沒有捷徑。

都是.NET語言，C# 跟 VB.Net的差別在哪里？對于ED，他們偶爾也會對這樣的問題感興趣，然后，他們會去看介紹，看比較文章。。。。但其實，這事完全是木有用的。

他們看了別人的介紹，以為自己懂的，但實際上，他們只是在復讀而已，完全木有懂。

作為一個ED，要了解C#跟VB.Net的差別在哪里，最好的方式，就是花時間去把兩種語言都學了。用這兩種語言分別去寫個幾萬行程序，然后就懂了。

當某天ED成為Hacker的時候，那就反倒可以去看各種介紹，看一眼，然后瞬間就可以悟了。

這也就是為什么很牛程序員學習新語言可以那么快，因為有太多的知識可以復用；而這些知識的積累，必然是需要通過在實際中，無數行的實際編碼，無數篇的資料閱讀中得來的。

沒有捷徑。

很多初學者，或者說，編程的偽愛好者，他們，會熱衷于去四處請教大師，下載各種經典書籍，企圖讀一本編程圣經，然后一夜脫胎換骨。

這是，不可能的。

這種偽愛好者，永遠不可能成事；在學習的過程中，抱著去“走捷徑”的心態，本身就已經是入了歧途；最終會花更多的時間。

原來Ruby / 現在 Python的一個光頭大牛Zed A. Shaw，為了表達“沒有捷徑”這樣的觀點，特意寫了本《Learn Python The Hard Way》：
http://learnpythonthehardway.org/

甚至有一個系列：http://learncodethehardway.org/

從長遠來看：The Hard Way Is Easier。

我完全同意。

作業：

1. 列舉10個Python Web框架

2. Python有多少種不同的解釋器？

3. Perl 跟 Python 有什么不同？

宅男程序員給老婆的計算機課程之2:怎么看待牛人

請看這個帖子：
http://blog.csdn.net/hu_zhenghui/article/details/7184799

快速瀏覽即可，無需細讀；瀏覽過后再繼續往下看。

讀后的感覺是不是：

“雖然不知道在說什么，但是看起來很厲害的樣子！”

整篇文章的關鍵是在這句：

“作者胡某某。曾任完美時空（現更名為完美世界）顧問，承擔互聯網方面的部分管理工作?，F在主要精力研究互聯網產品設計，是Axure授權的高級咨詢顧問和高級培訓講師?！?/p>

這也就是，我在第一課中提到的“啥事不做，整天四處布道，名頭都很響亮，如XX金牌講師”，“Evangelist本身的技術，很多是很差的；就好像推銷員本身，是不會做產品開發、不懂技術的。他們僅僅是會宣傳、鼓吹新技術而已”。

碰巧今天看到這個非常有代表性的帖子；整個帖子看下來，作者毫無海量數據處理實際開發經驗，純粹堆砌這些流行技術名詞而已。他沒有用過這些技術，隨便亂丟技術名詞，整篇似是而非，必然的結果就是：“雖然不知道在說什么，但是看起來很厲害的樣子！”

學習技術的人，如果受了這種“看起來很厲害的樣子！”的蒙騙，會走很多很多彎路。

那么，如何識別“看起來很厲害”跟“真的很厲害”？

就好像，CSDN雖然有些忽悠人的文章，但也是有些好的文章在里面，如何辨別？

1. 看得多了，自然會分辨。

研發知識的最好來源之一是技術博客，就我自己而言，看了博客園自創辦伊始前5年的所有首頁文章；外加常年訂閱400+博客，twitter fo 400余人等。

我這么做，主要是因為看得快；沒有“看不過來”的問題；但實際上是個很笨的辦法。

要保持最新技術的了解，確實是需要看很多blog；除此之外，我想不出別的途徑；但這并非必要。

2. 看書

多看，最大的好處是了解最新技術，而且這是很土的方法。很多時候，并不需要了解很多“最新技術”；很多“最新技術”都是屬于第一課中所講的“封裝技術”，不了解，也完全沒有關系。

計算機的經典好書并不多，好書是公認、經得起時間考驗的。

看完這個豆列也就差不多了：
http://book.douban.com/doulist/995755/

完全可以不去理解“最新”的浮躁，去上面的豆列挑幾本看，仔細的看，就可以脫胎換骨了。

就我自己而言，對我技術影響最大的一本書倒不在上面豆列的20本書中，而是：
http://book.douban.com/subject/1467587/

經典書，是必須看，并且反復看的；如果說有什么“捷徑”的話，看經典書就是最快的捷徑了。

這些經典書中的思想，是永遠不會過時的；任何時候看，都不會太晚。

給ED看的書也有經典：
http://book.douban.com/subject/1229954/

首先，這是本好書；而且這本500多頁書的傳奇在于它講了無數企業開發的模式，但其中的一頁半講述的：Active Record Pattern影響了過去5年多6年的Web開發潮流。

3. 寫代碼 + 看代碼

學習編程，是一定要去編程的。

書、資料再好，光看不練；也很容易把自己看成傻子。

在實際項目中寫代碼；然后看別人是怎么做的。

別人，指的往往是開源項目；而不是Google搜來的某個不知名博客中貼的代碼。哪個開源項目比較厲害，同樣是有目共睹的。

做Web開發，幾乎所有人都會去造ORM的輪子，沒事，就去造一個；然后比較自己的版本，跟優秀的開源ORM在API風格、架構設計、實現細節上，有何不同。

作者給的作業：

1. 找出一篇看上去很厲害的文章。

2. 找一本書，開始看，作為期中考書目。

宅男程序員給老婆的計算機課程之3:架構比較

本文作者：Wuvist

【51CTO獨家特稿】承接上文，12306的案例是蠻不錯的題材；看過咨詢師“很厲害的樣子”，那么，究竟要如何做好 「海量事務高速處理系統」 這個方案？

“Hacker”提出了方案：

caoz，出自百度的超低調牛人：
http://hi.baidu.com/caoz/blog/item/f4f1d7caee09b558f21fe780.html

云風，原網易杭州研究中心總監：
http://blog.codingnow.com/2012/01/ticket_queue.html

同樣的，也有另外一些“ED”在討論方案：

林仕鼎，百度首席架構師，曾任微軟亞洲研究院研究員：
http://qing.weibo.com/2244218960/85c41050330009xm.html
http://weibo.com/2244218960/y0l4S7Y1d

白碩sse，上海證券交易所總工程師：
http://weibo.com/1922397344/y0jMo9IaD
http://weibo.com/1922397344/y0jP6jNRB
http://weibo.com/1922397344/y0jUy2rkf

且不論“Hacker”跟“ED”誰更加牛，從他們的解決問題的手法、角度上看就非常不同。

“Hacker”所追求的是解決問題，只要是問題被解決，怎么解決的無所謂；并發流量太大，系統處理不過來；caoz / 云風兩種的方案，實質上都是直接去處理源頭 - 避免并發。

caoz把高并發的請求直接分流去非主業務服務器，主業務服務器無需面臨高并發；云鳳則提出排隊系統，避免高并發的出現。

而林仕鼎、白碩則是正兒八經的去討論在有這樣高并發的前提下，要怎么處理。

哥倫布的雞蛋。

能夠用手去扶住雞蛋，“Hacker”絕對不會猶豫；而“ED”則努力的去把雞蛋豎起來。

注意，?！癊D”未必就不懂得可以用手。

這樣“Hacker”精神，在云風的blog上，還有另一個體現：屏蔽垃圾評論的驗證碼。

博客有很多垃圾評論，需要屏蔽，有很多很多種方式，各種神奇的驗證碼，葉貝斯規則過濾等等。

“ED”可以設計出來很多方案，并實現。

云風腫么做呢？

他在評論發表的時候，增加了一個項目：為了驗證您是人類，請將六加一的結果（阿拉伯數字七）填寫在下面

“只要能解決問題，就采用最簡單的設計?！?/p>

這個驗證碼插件是我自己寫的，只有一行 perl 代碼。就是判斷輸入是不是 '7' 。

結果它很管用。從后臺 log 看，攔截了幾萬條 spam ?！?
http://blog.codingnow.com/2012/01/dev_note_7.html#comment-42161

注意，牛的“Hacker”未必就不懂得做出龐大架構并實現。

“要如何做好「海量事務高速處理系統」這個方案”本身就可能是個偽命題，

「海量事務高速處理系統」這個需求本身可能根本就不存在。

作業：

1. 林仕鼎是百度首席架構師嗎？

2. 看完caoz所有的blog。

宅男程序員給老婆的計算機課程之4:SQL vs NoSQL

本文作者：Wuvist

在幾乎所有的web應用中，數據庫都是核心的一環。

Web應用往往都是“Database driven”，業務、數據都是由數據庫完成，而前端頁面僅僅是演示、修改數據的一個“殼”。

因此很多web框架，都會標榜自己能夠兼容多少多少數據庫，做CRUD多么多么容易。

一般上，提到數據庫的時候，指的都是關系型數據庫；但關系型數據庫并非唯一的一種數據庫類型。

關系型數據庫，一開始便是設計為通用，并有ACID支持的。

Atomicity 原子性、 Consistency 一致性、Isolation 隔絕性、Durability 持久性

殺手歐陽盆栽說：“每件事都有它的代價”。上述四個特性，都是有代價的。

對于嚴謹的商業應用，如銀行、交易系統；為求業務的安全，他們不得不，或者說，能夠并且愿意付出這些代價。

回到12306，后端數據庫傳說使用的是Oracle，而站出來說吐槽12306的行家往往都會提到 redis \ mysql 這樣的替代。

有些菜鳥“ED”看到這些吐槽就出來噴了，說這些行家不懂神馬業務安全性的重要，這幫做互聯網的弱爆了，票務是必須使用 Oracle才能搞定云云。

好像還有人專門去噴了Fenng，這實在是太諷刺了。Fenng實際上是Orcale ACE Directorhttp://www.hudong.com/wiki/%E5%86%AF%E5%A4%A7%E8%BE%89，國內屈指可數的Oracle專家。

很多人，特別是弱“ED”、“專家教授”，沉寂在自己所在的領域，然后就以為“悟”了；實際上，僅是把自己變成了井底之蛙。

知識的廣博、全面性非常重要。

在某個領域，通用的東西成熟之后，往往就會有專用的解決方案出現。而專用的解決方案多了之后，又會有新的通用解決方案出現。

天下大勢，分久必合，合久必分。

計算機，最早有很多專用系統，如王安打字機；個人電腦通用之后，這些專用設備就湮滅了；而iPad、手機的涌現，則又是專用系統。

是的，傳統上需要去購買 Orcale、DB2 等巨貴無比的數據庫系統，去滿足業務需求；不是因為它們把問題解決到了極致，而是因為沒有別的選擇。時代已經變了，井底之蛙若把Oracle當成是王道，那只能被時代淘汰。

關系型數據庫作為通用解決方案，是非常非常好的；它是一把神刀。

但是，它有以下問題：

===== ED總是要寫爛SQL ====

首先. 還是那句話，有的人縱然神刀在手，亦無法成為刀中之神。關系型數據庫提供的SQL能力，是高度抽象的，封裝了無數層的。寫SQL的人，太多太多根本不了解SQL背后所執行的事情；爛“ED”都是如此。

這甚至造就了一個職業：DBA。DBA去負責數據庫微調、優化，聽起來很高級，但實質上，就是給濫用SQL的“ED”擦屁股而已。

對于龐大的企業來說，管理者是知道大部分ED都弱爆了，他不期望也不需要ED去了解數據庫，他只需要ED去完成最基本的業務功能，然后讓DBA去給ED擦屁股。

大部分的ED，并沒有意識到這一點；他們拼命去追求方便快捷的“搞定”；濫用SQL的各種高級功能；甚至，他們把分享SQL的復雜使用當成是樂事。

ED所努力的，是把自己變笨，把活盡可能的都交給神奇的數據庫去解決；數據庫怎么解決的，他們不關心；這實質上，是在削弱自己工作的技術含量，自我貶值而已。

工程師如果能夠把數據庫給用好了，哪里還有DBA什么事？

DBA所謂的數據庫優化，往往就是把工程師不負責任寫下的2B SQL查詢找出來，然后改寫為文藝方式罷了。

不要濫用數據庫，一點都不難。

===== 通用數據庫性能有極限 =====

其次，關系型數據庫作為通用解決方案，它提供了太多的東西，它做了太多的事，而所有的事情，都有它的代價，直接而言，就是犧牲性能了。

所以，DBA的另一個職責，則是把數據庫的各種參數調配好，讓其能夠發揮最高的性能。

從這個意義上去說，DBA的工作就不僅僅是給ED擦屁股了。

但，這樣的微調，是有極限的。DBA拚了命去把雞蛋豎立起來，考慮了桌面摩擦、空氣流動、手指顫抖等等因素，雞蛋雖然可以豎立一會，但終究還是會倒下去；這也就是微調的極限。

在某些場景下，是可以用手的：把業務中沒有用到的數據庫功能都去掉；甚至，去掉完整的ACID支持。

這樣一來，數據庫的性能就可以有數量級的改善了。

===== 關鍵在于靈活性 ====

最后，上面兩點，其實都是跟性能相關的；關系型數據庫即便作為通用方案，它的性能有極限，但也能夠滿足絕大多數應用場景了。關系型數據庫的軟肋，是在靈活性上。

數據庫有表、而表有結構；而表的結構，在應用上線之后，很難修改。

這同樣造就了一些專業學問：嚴密的業務分析、設計數據庫結構、如何在數據庫上線之后修改結構等等。

這些問題或者說學問之所以存在，是植根于關系型數據庫表結構不靈活的前提之上。

再次”Think out of the box“，如果數據庫可以做到靈活、隨時修改的表結構呢？

====== NoSQL ======

關系型數據庫的三個問題，被NoSQL全部解決了。

（同樣的，所有事情都有它的代價；NoSQL在解決SQL固有問題的同時，也引入了新的問題；另一方面，NoSQL解決的也不僅僅是SQL的這三個問題。）

ED要寫爛SQL？沒有關系，徹底不讓他們寫SQL好了。

數據庫支持功能太多？砍功能還不容易么？

Schema不靈活？那就schema-less好了。

目前，NoSQL的實現方案很多，MongoDB、Redis、Carssendra等等等等；每一個都可以非常不同，是專用解決方案：有自己獨有的特性，去解決特定場景的特定問題。

（當然，像MongoDB，已經很有NoSQL通用解決方案的意味了。）

普通程序員用SQL，文藝程序員用NoSQL，2B程序員把NoSQL當SQL用。

普通程序員在從SQL切換去NoSQL時，會受固有的SQL知識限制，總有把NoSQL當成SQL去用的沖動，但這是非常2B的行為。

從微觀的角度講，原來SQL查詢中所支持的各種神奇joining / groupby都不見了；拼命的想要去找在NoSQL數據庫環境下同樣的神奇工具。

這徹底違背了使用NoSQL的初衷：為了就是不讓你濫用SQL的這些神奇功能。

濫用SQL會造成嚴重的性能問題，而在性能問題浮現之后，需要耗費更大的力氣去糾正。

是的，信用卡透支購物很方便；但付賬單的時候就×××了；所以，換成無法透支的借記卡。

固然沒有了透支的便利，會有不方便，但徹底杜絕了還不起賬單，被收取高額利息的問題。

要透支的便利？ED，請先去掌握好理財技能，徹底了解透支的影響，然后我們再來談便利。

從宏觀的角度講，會有人企圖去給NoSQL做封裝，讓NoSQL表現得跟SQL一樣；甚至，去把NoSQL去掉的那些SQL功能加回去。

SQL已經是一個非常非常成熟的方案，它所能夠解決的問題范疇里面，幾乎沒有辦法做得比SQL更好。

在NoSQL的基礎上，去試圖模擬SQL，只能成為SQL的蹩腳模擬；還不如直接用回SQL。

在網路編程里面也有類似的例子，TCP跟UDP?？梢园裇QL看成是TCP，它是可靠、神奇的。UDP雖然不可靠，但是會比TCP更快。要做視頻、語音通訊，UDP是更好的選擇。但要去做“不丟包、不失幀”的可靠視頻通訊，選擇在UDP的基礎上添加確認、重發機制模擬TCP，那就是2B了。不是天才，沒法做得比TCP更好，直接用TCP就好。

作業：
1. NoSQL的方案，如MongoDB還解決了SQL的什么問題？

2. NoSQL的應用場景有啥米？

宅男程序員給老婆的計算機課程之5:設計模式

設計模式，應該是很多ED心目中牛B的編程方式。

上回說到ED的好書POEE，實際上便是一本專門講企業開發中使用的設計模式中的書。

設計模式，并不多，基本上看完GoF的這邊《Design Pattern》便可以有足夠了解了。

而實際開發中常用的設計模式更是屈指可數，Singleton，Factory，Facade，Active Record、Provider等等。

就那么幾個，花花功夫，仔細了解一下這幾個，然后在實際編碼中應用一下，便可以算是掌握了。

設計模式，并不難。

它是開發中非常必要的知識，實際上，是非?；A的知識，并不牛B。

開發的時候，需要時刻明確自己的目標：解決問題。

解決問題才是最重要的。

設計模式的存在，是為了更好的維護、管理代碼，或者是為了擴展性；絕對不可以為了設計模式而模式。

在Java程序中，為了模式而模式的現象蠻普遍的。

我猜想這是因為Java是一門工業語言，有大量的ED使用的緣故。

ED把設計模式的使用，當成是一種可以炫耀的編程技巧，或者說，他們遵從的編碼規范中，要求他們去使用某某設計模式。

至于為什么要使用設計模式，最常見的理由便是：為了將來可以XX，或者YY。

程序開發中，有一句名言：“Pre-mature optimization is the root of all evil”。

過早優化，是萬惡之源。

非常多的情況下，將來預想中的XX或者YY；并不會發生。大部分代碼，寫了之后就會被丟棄掉，再也不會有人去維護。

當XX或者YY發生的時候，往往，都是會推倒重來。

除非你很牛B，只有牛到一定程度，才有可能對將來可能發生的情況做好合理的預測，并預留出改善、調整的空間。

但非常諷刺的是，為將來做設計的最好方法就是：什么都不做。

只有空白，才能夠留下最大的發揮空間。

現在為將來可能發生的情況，做了編碼，任何一行編碼，都是很可能是在為將來添加限制、制造麻煩。

現在寫下去的代碼，將來，都是要被刪掉的；能夠不寫，就不寫。

在任何時候，都應該保持代碼簡潔。

函數，盡可能的短；當一個函數的長度，超過一個屏幕的時候，便應該考慮重構、拆分。

牛B的程序，都應該是簡單、易懂的；采用大量的設計模式，復雜得讓人無法直接看懂，或許有它的意義以及應用場景，但這絕對不是編程功力牛B的表現。

打個比方，設計模式就是武術招式。

學徒，必然需要熟悉什么“有風來儀”或者“屁股朝后平沙落雁式”。

但更高的境界是：無招勝有招。

簡單、直接的把代碼搞定。

Python大牛沈崴有云：“得道的程序員，既不封裝，也沒有重復代碼?！?
http://eishn.blog.163.com/blog/static/6523182010102342531684/

作業：

1. 使用一種編譯語言實現 Singleton 模式

2. 使用一種動態語言實現 Singleton 模式

3. 說說對 Provider 模式的理解。

宅男程序員給老婆的計算機課程之6:模版引擎

【51CTO獨家特稿】設計模式再“高級”一點，便是所謂的“框架”了。

從事Web開發，一般都會接觸到MVC框架這個概念。

M：也就是Model，直接跟網站數據庫相關。

V：也就是View，是網頁的模版，跟顯示數據相關。

C：則是Controller，相當于網站的業務邏輯。

MVC也不僅僅是應用于網站開發，它的概念實際上植根于桌面軟件，并且在手機軟件開發上也有應用。

MVC本身是一個設計模式，是一個被驗證過的，可以用來很好歸納、管理代碼的軟件開發方式。

基于這樣的設計模式，提供了很多相關的類庫實現，則“設計模式”升級為“框架”。

MVC的任何一個方面，擴展出去講，都可以講上幾天幾夜。

今天只講V。

傳統的ASP / PHP網站開發，V是很混亂的。

默認只有一種文件，html與業務邏輯代碼混雜在同一個文件；相當難以維護。

ASP.NET相對于asp做出了很大改進，提出了code-behine的概念：默認將html的模版代碼，以及c#或者vb.net的邏輯代碼切分到兩個不同的文件。

這樣的方式算是有很大進步。

微軟平臺上做開發是比較苦逼的，微軟掌控了整個開發平臺的前進速度。

asp跟PHP在開始的時候，是相似的技術。有類似的便利，以及類似的麻煩。

微軟推出了.net，推廣了code-behind的模式；然后，所有的微軟程序員都超著微軟指定的這個方向去邁進。

asp被拋棄了，自從ASP.NET誕生之后，就不再有任何改進。

而PHP，在開源世界中，則不斷的得到各式各樣的改進。

各種模版引擎層出不窮；不僅可以實現code-behind這樣簡單的模版、業務代碼分割；很多還直接引入了MVC的概念；實現了三層的分割。

而ASP.NET，則長期止步于web form的code-behind，在開源世界中的MVC方案大放光彩若干年后，才推出 ASP.NET MVC。

模版技術，最初的目的就是要把業務代碼，也就是說，把獲得數據的代碼跟html分割。

在模版實現上，因此涌現了不少不同的設計哲學。

Python的Django框架中的模版，是一種典型。

它徹底的禁止程序員在模版中嵌入任何代碼；模版中，只可以出現html；以及一些跟業務邏輯無關的控制標簽，如：

1 {% If XXXX %} foo {% else %} bar {% end %}

條件XXXX，必須是一個數據值，不可以是一個復雜表達式、不可以包涵函數調用等等。

模版中，也不可以聲明任何新的變量，下面的做法是被禁止的：

2 {% set i = 0 %}

3 {% foreach item in items %}

4 {% i += 1%}

5 <div>

6 ` item `

7 {% if i mod 2 == 0 %}

8 <hr />

9 {% end %}

10

11 {% next %}

Django的模版，從技術上徹底禁止程序員添加任何邏輯，強迫程序員必須在controller中去寫各種邏輯，以確保模版內容的純潔干凈。

所以Django的模版，一般都非常簡單，有很好的移植性，并且可以讓網頁設計人員直接編輯。

ASP.NET則是另一種典型；雖然有了code-behind，但是它沒有對前端代碼，以及后端代碼做任何限制。

在前端aspx頁面中，可以嵌入任意的邏輯代碼，而code-behind的code，為空白；這種偽“code-behind”的方式，跟原來的asp沒啥區別。

ASP.NET從框架本身，并不阻止程序員去做這樣的事情，實際上，它還標榜它這樣的特性：方便原有的asp項目直接升級到.NET的平臺上。

也有另外一種奇葩的做法，前端aspx頁面保持空白，然后在code-behind的code中去拼接所有的html。這樣的方式，ASP.NET框架本身也不禁止。

只要ASP.NET程序員喜歡，沒有什么不可以的。

ASP.NET把對模版使用方式的選擇權留給了程序員，如果程序員自律，他們可以按Django模版那樣的方式去使用模版，并擁有Django一樣的優點；如果程序員自律？！

在某些可以通過嵌入代碼去快速處理的場景，ASP.NET的模版也保留了程序員去hack的能力。

還有一些模版技術，則是折衷的（如tornado的模版）：允許嵌入單行代碼，如聲明變量，調用函數等等；但是不允許整塊、整塊的業務代碼出現模版中。

上述三種模版設計哲學，各有它們的道理，以及應用場景。

需要根據具體的業務、應用場景，才能說其中哪種比較合適。

開發人員的能力也是直接相關的，如果團隊中，普遍不自律；缺乏將業務、模版代碼分割、以提高代碼可維護性的意識，那么Django的做法是最好的，它直接禁止去濫用模版，強迫他們去使用更好的開發風格；即便在某些場景下會更麻煩。

武斷的認為任何一種模版設計哲學是“最佳”的想法是極其膚淺的。

各種成熟的模版技術，一般也都會有包括以下特性：

1. 嵌入

也就是說，編寫各種可以復用的小模版塊，然后供多個不同地方調用；比方說，用戶頭像（甚至名片）的顯示。

具體頁面不需要重復編寫這些重復的模塊。

并且，這些模塊需要調整時，只需要修改一個地方，便可以在所有地方生效。

2. 繼承

能夠編寫一些基礎模版，定義常見的頁面結構。

具體頁面繼承這些基礎模版，便不需要重復編寫那些結構代碼。

同樣的，當頁面結構需要調整時，也是修改一處，所有生效。

3. i18n

網頁模版的國際化支持是一個模版引擎是否成熟的表現。

如果沒有，當網站需要同時提供多種不同語言支持的時候，會很麻煩。

成熟的模版，都會提供內置的支持。

因為網頁模版實現實在是太多了，大家功能也都差不多，那么性能，也就成為了相當重要的比較指標。

有的模版，能夠“編譯“，渲染起來快些。

一般可以簡單認為，功能越多的模版，性能會約低。有的模版，甚至將i18n的支持變成可配置的，不需要的時候就可以關閉，以提高性能。

也有的模版認為，寫 {% %} <%%> {{}} 這樣的符號太麻煩了，可以直接忽略，它可以自動聰明的識別 html，以及模版控制代碼。簡單的說，就是以極其華麗的方式，去方面程序員少打幾個字符。

還有的模版，在實現嵌入功能的時候，還可以選擇所依賴的的css / js文件。

比方說，要顯示用戶的名片，需要引入 namecard.css；那么，可以在 namecard的模塊文件中指定這個依賴，然后模版渲染的時候，自動把這個css的引用，放在html的頭部。

直接在模塊文件中寫 namecard.css 的引用是很傻的，因為模塊可以在模版中引用多次。重復引用同一個css文件是沒有道理的。

種種模版功能細節，實際上，都是可以在沒有模版支持的框架中去實現。

想想PHP，它本來是非常簡單的，默認只能夠在同一個文件中混雜邏輯與代碼。

但一旦程序員有了追求，它也可以有模版實現。

模版不支持 i18n，程序員一般也是有辦法在現有模版實現中添加相應的支持的。

并不復雜，關鍵是看程序員的態度；看程序員是否有把事情做得更好、更優雅的態度。

一般情況下，程序員選擇去實現更多的模版功能的時候，必須先看看別人是怎么做的。比方說，如果完全不知道什么是gettext就去自行實現模版的 i18n 功能，是非常2B的。

絕大多數情況下，程序員面臨的問題，都不是自己獨有的，一定是別人已經解決過的問題。

是否有足夠的見識，有足夠的知識廣度，了解別人的解決同樣問題的做法是程序員能力的表現。

是否有快速的搜索出類似的解決方案，也是能力的表現。

1. PHP的Smarty 模版的設計哲學是什么？

2. Perl的Mason 模版的設計哲學是什么？

3. 什么是gettext?

4. 前端Javascript實現的模版中，目前最成熟的是哪個引擎？

宅男程序員給老婆的計算機課程之7：運維的重要性

【51CTO獨家特稿】先摘錄一段話勉勵一下生日寶：

截止2010月6月，Facebook接近2000雇員。10個月時間從1100人增長到2000，一年時間員工人數翻了一番！

最大的兩個團隊是開發工程師和運維，都是400-500人的規模

豬頭寶，在Facebook，運維跟開發是一樣重要的。運維才不是用vender提供的軟件，然后按manual去step by step的做事情。

有很多創造性的工作可以做。

豬寶你知道twitter是腫么更新服務器的么？

Twitter有幾千臺服務器，一旦網站要跟新，這幾千臺服務器上面的代碼部署都要更新。

腫么讓這幾千臺服務器快速的獲得新代碼呢？逐臺服務器下載太慢了，數千臺服務器同時向代碼中央服務器獲取新代碼又會把中央服務器的帶寬擠爆。

腫么辦？

Twitter的運維工程師直接用了BT的協議，使用p2p下載來解決這個問題：
http://engineering.twitter.com/2010/07/murder-fast-datacenter-code-deploys.html

它們就這樣把部署的時間從原來的40分鐘大幅減少到只要12秒～～

運維，很多時候都是要編寫腳本，把很多原本需要人手工做的事情通過腳本自動化管理起來。

這些腳本乃至系統的編寫與開發，都是需要能力的。

運維的投入，都是為了節約別人的時間；而時間節約、效率提高、穩定性提高，這些都是有意義的。

之前豬寶去廣州參加技術沙龍，有一個人人網之類的運維去講自己的工作木有意義，是“花×××的心，賺賣白菜的錢”；當場就被金山的過程改進經理周琦 Zoom.Quiet給吐槽了。

說他的態度不對，運維部門應該是一個盈利的部門，而不應該是一個被無視的部門；運維，應該是通過提高技術水平，提高效率，節約成本；以達到“賺錢”的目的。

caoz很推崇的一個技術牛人楊建；便是做運維的，在新浪、騰訊呆過，現在應該是被caoz收去4399了：http://blog.sina.com.cn/iyangjian

如果木有楊建這樣的運維高手，新浪是木有可能支撐起一小時近20億實際http請求處理量的：http://blog.sina.com.cn/s/blog_466c66400100cfrj.html

Facebook的有9個級別的代碼發布流程：http://www.dbanotes.net/arch/facebook_how_facebook_ships_code.html 這些都是運維的工程師牛B才有可能的；并且也確實解決了實際業務問題。

如果僅僅是做普通的SA，那么工作是很routine，很無聊，很沒有技術含量的；但是如果能夠提高，面臨的問題是完全不一樣的。

這跟爛ED與Hacker的區別也是一樣。

實際上，很多職業都是一樣；如果是做那底層的普通工作，都必然是無聊的，木有意義的。但一旦有進步，層次提高，面臨的就是完全不一樣的環境。

有做文書工作，收集、整理資料的律師；也有Alan Shore。

工作是否有意義，在于職位的層次。

親親豬頭寶～

宅男程序員給老婆的計算機課程之8：控制器

設計模式再“高級”一點，便是所謂的“框架”了。

從事Web開發，一般都會接觸到MVC框架這個概念。

M：也就是Model，直接跟網站數據庫相關。

V：也就是View，是網頁的模版，跟顯示數據相關。

C：則是Controller，相當于網站的業務邏輯。

MVC也不僅僅是應用于網站開發，它的概念實際上植根于桌面軟件，并且在手機軟件開發上也有應用。

MVC本身是一個設計模式，是一個被驗證過的，可以用來很好歸納、管理代碼的軟件開發方式。

基于這樣的設計模式，提供了很多相關的類庫實現，則“設計模式”升級為“框架”。

MVC的任何一個方面，擴展出去講，都可以講上幾天幾夜。

今天只講C。

傳統上，php / asp / asp.net web form等，使用的是所謂的 Page Controller Patterns:http://martinfowler.com/eaaCatalog/pageController.html

Page Controller簡單的說，便是一個網址對應一個程序文件。

所以，我們會看到大量類似： show.php / show.asp / show.aspx 的網址存在，這樣的網址，背后都有相應同名的文件。

這樣的模式，是網站從靜態轉向動態是最自然的改變方便，也最為容易讓初學者接受。

但隨著網站的復雜化，這樣的模式會慢慢顯得不夠方便；比方說，多個不同的網址，映射到相同的處理；比方說，處理的時候，復用共同的資源。

頁面內容的動態化，同一個程序文件，顯示的內容是動態生成的 - 根據不同的query string，生成不同的內容，如：show.php?id=1234

網頁程序內部，實際上是需要解析網址中的query string，并做不同的操作。

這實際上是一個映射的過程，將網址映射到相應的處理。

為了方便做這樣的映射，慢慢的出現了所謂的 Front Controller Patterns:
http://martinfowler.com/eaaCatalog/frontController.html

這是通過某種機制，將符合各種規則的網址請求映射到程序中的一個類，或者是一個函數處理。

一般上，是使用正則表達式解析網址，并映射。

將網址映射到一個類；

1 urls = ("/home", "hello")

2 app = web.application(urls, globals())

3

4 class hello:

5 def GET(self):

6 return'Hello, world!'

將網址請求映射到類，是相對較“重”的處理方式，比方說，需要處理類的初始化等等。

有的框架，也可以是一個函數，則相對“輕量”一些：

7 (r'^$', 'home'),

8

9 def home(request):

10 return HttpResponse("Hello, world.")

類、函數，均各有優劣，但實際差異很小：

映射到類的方式，往往還會根據不同的HTTP header映射到類里面中相映的函數，比方說，將對 /home 的HTTP GET請求映射給 hello 類的 GET 函數；而對 /home 的 HTTP POST請求映射給 hello 類的POST函數。

這部分 url routing的設計與實現，各種語言、平臺上的功能均向正則表達式靠攏，大同小異。

有的可能專門為 restful 做了優化，但即便木有，自行實現也并不復雜。

很多請求，都會有一些常用的默認處理，比方說，檢查用戶是否登陸，檢查用戶是否有權限等等。

這些業務控制邏輯，是完全可以復用的。

在Page Controller的場景下，一般是通過繼承來實現；而Front Controller場景下，而一般通過函數修飾符的風格實現，如：

11 class UploadImgHandler(BaseHandler):

12 @tornado.web.authenticated

13 def post(self):

14 XXX

(上述代碼，實際上既使用了繼承，也使用了修飾符。)

Controller的改進，目的在于更加方便的維護代碼、修改業務邏輯。

如果程序員有良好的開發風格，基本是使用最基礎的php page controller，也可以達到類似的效果。

各種“先進框架”，實際上是將常用的模式抽象出來，并通過便利的約定方式向程序員開放；如果程序員缺乏維護代碼的意識，也很可能將良好的約定習慣用濫。

需要了解的，是為什么各框架的controller設計會有這樣的設計，并用好；而不是死板的遵循“開發指南”。

在簡單業務場景下，實際上page controller會更加方便。

有這么一個“定理”：概念越簡單的模式，在處理簡單場景時，是越便利；但隨著場景復雜化，簡單的模式會越來越難以維護。

而概念相對復雜、高級的模式，處理簡單場景時，會相對麻煩；但隨著場景復雜化，則比簡單的模式容易維護。

“復雜度是守恒”的：
模式簡單，維護則復雜。
模式復雜，維護則簡單。

一個復雜的地方變簡單了，則另一個地方會變復雜；保持代碼結構的清晰，不要自己給自己添麻煩。

什么叫自己給自己添麻煩？

普通復數形式，加s: pigs / cats / dogs

已經可以很好了，但偏生有人要增加不規則復數：

sheep / mice / wives

這種就是自己給自己添麻煩。

作業：

1. 說說對 restful 的理解

2. 什么是 reverse proxy ?

宅男程序員給老婆的計算機課程之9：數據模型

這次來講MVC中最后的M。

Model，幾乎可以說是網頁應用的核心。

之前課程提到過網頁應用是由數據庫驅動，而在很多場景，數據庫 = M ； M = 數據庫。

所謂的ORM； object relational mapping。

現在新的網頁開發框架，特別是MVC框架，都會提供ORM支持，避免程序員直接寫SQL、操作數據庫。

傳統上，ASP/ php臭名昭著的sql注入問題，便是因為菜鳥程序員直接在程序中根據用戶輸入拼接數據庫造成的；而使用ORM框架，則可以徹底避免這種問題。

ORM有兩種風格，一種是 R => O；一種是 O => R 。

====== R => O ======

傳統上，程序員也都是先完成數據庫設計（甚至是由DBA完成），然后再考慮相應的對象生成，也就是所謂的 R =＞ O。

在這樣的場景下，整個軟件的框架，還是以數據庫為核心，業務的設計思維是以關系型數據庫的表結構為基礎去考慮的，具體應用實現上，會考慮很多關系型數據庫的功能特性，比方說，外鍵，joining等等，并且，程序員需要直接考慮“數據庫設計三范式”，以及冗余字段等面向數據庫的優化手段。

并且，程序員也很可能會采用數據庫的一些高級特性，如視圖、存儲過程、甚至觸發器等等以方便使用。

O的存在，僅僅是為了方便操作數據庫表。

====== O => R ======

這種設計哲學則是相反，程序員做業務分析、實現架構設計的時候，并不過多考慮數據庫的特性與限制；程序僅考慮自己的業務對象：編程語言中的對象。

數據庫僅僅只是作為一個對象持久層來考慮：

* 程序運行的時候，對象是自動保持在內存中。

* 但在對象狀態改變、程序退出的時候，將對象保存進數據庫。

* 程序重新啟動的時候，則從數據庫中獲得原先數據，并還原為內存中的對象。

在這樣的場景下，數據庫是一個可以被替換的存儲層，它可以是關系型數據庫，也可以是NoSQL，甚至是硬盤文件；所以，即便使用關系型數據庫，一般也不會使用其高級功能。

設計哲學的不同直接造成了使用技術的不同。

====== 比較 ======

在ED開發圣經PEAA中，列舉了下面三種方案：

1. Trascation Script

也就是直接拼接SQL啦～

2. Table Module

R => O；并且，O非常簡單，直接以類似數組的方式讀取表數據。

.net中ADO.net的DataTable / DataRow對象便是這種設計的典型實現。

3. Domain Model

O => R，直接設計業務領域(Domain)的對象，然后在考慮對象的持久化方案。

針對上面3中方案，Martin Fowler畫了下面這張著名圖解：
http://www.hamishgraham.net/page/Work-Habits.aspx/Architecture/Business-Layer

他的結論是：

使用Table Module的方式，永遠比直接寫SQL簡單；在簡單的業務場景下，Table Module也會比Domain Model簡單，但Table Module的方案復雜度會隨著業務復雜化而快速增長。

反之，Domain Model的復雜度跟業務復雜度相比始終保持水平增長；它雖然一開始最復雜，但隨著業務復雜度超過一定程度后，它反而會成為最簡單的方案。

就我自己的開發經驗，基本與Fowler的描述吻合；但隨著ORM技術的成熟，Domain Model，未必如他在圖中畫的那樣，一開始就有那么高的復雜度。

關鍵是看程序員是否習慣于關系型數據庫的實現方案，如果是，那么，切換去Domain Model，確實會比較麻煩，各種不適應。

但如果是一個沒有關系型數據庫經驗的程序員，或者說，沒有強制使用SQL思維習慣的程序員，使用Domain Model，也可以是很自然的方案。

下一課，講繼續詳細說明Domain Model。

作業：

1. ED開發圣經PEAA究竟是哪本書？

2. 數據庫三范式是什么？

3. 關于Domain Model，什么是充血模型？什么是貧血模型？

宅男程序員給老婆的計算機課程之10：做，就對了！

?

【51CTO獨家特稿】學以致用，很多時候，學習一樣東西最好需要能夠在實際中應用起來。

所以我在第2課"怎么看待牛人"中強調的必須“看代碼 + 寫代碼”。

不過我在里面提到的例子“ORM”卻并不好，ORM太過龐大。實際編碼，應該是從小開始。

運維工作中更經常使用的是腳本語言，腳本程序甚至是shell命令都可以完成很多有意義的事情。

這些豬頭應該在工作中體驗很多；但作為程序員，程序能夠發揮的作用也可以體現在生活上。

玩Draw Something單詞想不出來，是完全可以寫個程序來輸出單詞列表的。

上網下載一個英文單詞詞庫；然后甚至可以用最傻X的方式去逐個單詞檢查，看Draw Something給出的字母是否能夠組成各個單詞。

程序首先是要完成需求，這里的需求僅僅是要方便玩游戲，猜出朋友的單詞謎語。

程序運行慢點完全無所謂，千分之一秒輸出結果，還是10秒輸出結果，都不會影響這個需求的實現。

（當然，如果是玩Facebook上的限時拚單詞游戲那需求又是不同。）

這種“程序”是所謂的Throw-away code，寫完就扔。

像Draw Something這樣的游戲，樂趣就在于努力去想、努力猜成功之后的成就感。有了這樣一個程序，那就不用努力去想，游戲的樂趣也就會在瞬間喪失，“破解工具”自然也就得扔掉了。

即便寫完就扔，但寫這樣的程序卻有其意義。寫與不寫是差別是0與1的差別，這是本質的區別。

我會非常鄙視那些熱衷于看各種語言的介紹但卻一行程序都不寫的人。

有的人，聽說erlang很牛B，上網搜了一堆介紹，不斷的感嘆“哇～Erlang確實很牛！”，“哦耶！Facebook Chat跟Web QQ都是在用erlang，果然erlang才是王道！”

但是，他自己卻不寫任何一行erlang程序；有時，還會抱怨公司的管理層都是×××，這個項目用erlang再合適不過，為什么不用，為什么不給團隊使用erlang的機會呢？

一定要寫程序，沒有機會，也要創造機會。

而在我看來，生活中這種“玩游戲”的機會再合適不過。

寫了Draw Something的“破解工具”，會使得猜單詞沒有成就感，喪失游戲的樂趣；但，完成了一個程序去破解一個游戲，這本身也是一件有成就感的事情啊～

并且，游戲的樂趣會轉移為編程的樂趣；而樂趣，是讓自己變厲害的最大動力。

Geek享受這樣的機會；而ED則等待別人享受這樣的機會。

“做，就對了” - 慈濟宗創始人 證嚴法師

作業：

1. 使用Perl 實現一個程序輸入若干字母，輸出這些字母所能組成的所有單詞列表。素，就是要寫個 Draw Something的“破解工具”。

2. 比較Perl的實現跟云風的lua實現有何不同：https://github.com/cloudwu/guess-word

宅男程序員給老婆的計算機課程之11:域模型

【51CTO獨家特稿】在前面的課程中提到PEAA中只有一頁半的Active Record Pattern (http://martinfowler.com/eaaCatalog/activeRecord.html )影響了過去5年多6年的Web開發潮流。

這個潮流是由Ruby On Rails引領的。

RoR的作者DHH David Heinemeier Hansson是Hacker，他因為RoR在2005年被Google跟O'Reilly選為年度***。

他在設計RoR時，選用了Active Record作為RoR的M層。

Active Record非常簡單，一個類對應一個表，一個對象實例對應一行數據；并且有簡單的有Save / Delete以及查詢等簡單的函數操作。

嚴格的說，Active Record不是福勒所推崇的充血Domain Object模型 （http://martinfowler.com/bliki/AnemicDomainModel.html ），Active Record對象提供的功能函數太少，只有通用的數據操作方法，而不包涵業務邏輯；但它又不像POJO （http://martinfowler.com/bliki/POJO.html ） 那樣完全的貧血。

（充血、貧血Domain Object之爭，可以去iteye翻帖子）

從福勒 AnemicDomainModel 一文看，他在當年（2003）是推薦了充血Domain對象跟POJO，但過去幾年在Web開發領域所流行的卻是 Active Record這樣兩邊都沾點，但卻又不全是的中間妥協方案。

不搞教條主義，什么實用用什么，POJO不夠，那么就加一點；充血太復雜，那么就減少一點。

從互聯網的發展看，我一時間完全想不出有什么在理論上被設計得很好的模型，能夠最終經歷時間考驗成為事實標準。

因特網的7層模型，實際用到的遠不到7層；Java的EJB掛了；XML被JSON取代等等等等。

也許學院派提出的理論有他們的應用場景，只是，這樣的場景，在快速發展互聯網似乎很難找到例子。

互聯網產品的業務相對簡單，Active Record已經足夠好，足夠方便，因此大行其道。

另一方面，互聯網產品做大后，也往往有著極大的性能要求，一個復雜的模型，是難以做性能優化的。

像Active Record，因為足夠簡單，Twitter在當年遇到性能問題的時候，便直接Hack掉RoR的實現，增加了 Cache-Money （ https://github.com/nkallen/cache-money ） 這么一個透明的緩存層。

如果RoR使用的是充血對象模型，對象中有復雜的業務邏輯，如何增加透明的緩存呢？

Active Record的實際上是對數據庫操作做了抽象。

封裝、抽象是一門藝術。

什么該封裝，什么該暴露，什么徹底不可見，需要拿捏得很準確。

最容易犯的錯誤是過度封裝，使得一些本來很簡單的底層操作，到了上層變得完全不能用；或者說，很難用。

開發者需要用到hack的方式，才能去做這些簡單的操作。

Active Record便是一個抽象封裝得恰到好處的例子。過度設計、過度封裝的數據操作層？EJB。

按照教科書對OO的定義，OO的核心特性之一是：encapsulationhttp://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29

Private屬性、方法，對象外部是完全不能訪問的。

但如果遇到了需要訪問的場景怎么辦？！

有的人會說：“這樣的場景本來就不應該出現，這是對象設計一開始沒有做好造成的，錯誤的應該設成Public的屬性設成了Private”。

ORM，采用O => R的映射的設計哲學，只考慮業務對象，完全不考慮底層數據庫，數據庫僅僅是一個可以被替換掉的持久層，它可以是關系型數據庫、也可以是NoSQL，甚至是硬盤文件。

也就是說，Domain Object是把后端數據庫給設成“Private”了，即便底層是關系型數據庫，你也不可以直接去寫SQL。

即便你使用的是MS SQL Server，你也不能去調用它特有的SQL特性。

Asp.Net剛出來的時候，微軟曾經鼓吹過一個叫 N-Tiers 的架構：http://msdn.microsoft.com/en-us/library/ms973279.aspx /http://msdn.microsoft.com/en-us/library/bb384398.aspx 。

我曾經以為這是王道，直到我膝蓋中了一箭……呃，不，直到我看了Joel Spolsky寫的 The Law of Leaky Abstractions：http://www.joelonsoftware.com/articles/LeakyAbstractions.html

理想很豐滿，現實很骨感。

ORM工具再怎么封裝都好，底層用了數據庫，就是用了數據庫。

開發者必然需要了解數據庫的特性，能否直接調用數據庫的特性，是一個選擇。

是否要徹底對上層屏蔽掉數據庫的存在，也是一個選擇。

N-tiers架構推薦一層又一層的封裝，如果錯誤使用，把選擇當成教條，是會有噩夢的。

========

Python是一門很有趣的語言，它支持繼承，能實現OO，但是缺乏 encapsulation 的語言支持。

Python根本就沒有public / private這樣的關鍵字，然后呢？

然后可以回過頭再去看：“這樣的場景本來就不應該出現，這是對象設計一開始沒有做好造成的，錯誤的應該設成Public的屬性設成了Private”。

這句話，這話說得對嘛？

作業：

1. N-tiers架構的噩夢場景是？

2. 什么系統/場景需要充分使用特定數據庫的特性？

宅男程序員給老婆的計算機課程之12：作業點評

【51CTO獨家特稿】h1. 作業分析

作業是課程的一部分，實際上，還是這個課程最重要的部分。

如我在前面課程中提到的一樣：

很多初學者，或者說，編程的偽愛好者，他們，會熱衷于去四處請教大師，下載各種經典書籍，企圖讀一本編程圣經，然后一夜脫胎換骨。

這是，不可能的。

同樣的，如果僅僅是看了這個課程，而不做作業，那么在看課程前后，個人的能力是不可能有變化的。

充其量，跟看了一部或許好玩的小說差不多。

作業并不是考試，而是課程的延伸，是沒有可能參照著課程的內容，然后對作業做出回答。

每節課，僅僅只是指出一個方向，然后需要大量時間的去朝這個方向做學習、探索，然后以作業的形式做出對這個方向的回答。

這才是學習。

花幾分鐘看幾眼課程，然后就期待自己技術能力有變化？能夠有改變，從不會做作業變成會做作業？

別開玩笑了，如果能夠這樣，那么程序開發會是一門非常沒有技術含量，非常沒有含金量的行業。

只有用心好好完成了作業之后，才有可能獲得知識。

這個課程的作業，也完全不是：

小明有5個蘋果，他吃了一個。然后給小寒了一個，求太陽到地球的距離。

這樣無厘頭的題目。

每節課的作業，都是跟課程有直接關系的。

h2. 第一課

1. 用500字講述什么是Programming Methodology?

2. 列舉10種Data Structure.

3. 列舉10種Algorithm.

這課的作業實際上是在問，你對“編程本質”的內容掌握了多少，如果不夠熟悉，了解得不夠多，要趕快去學習。

h2. 第二課

1. 列舉10個Python Web框架

2. Python有多少種不同的解釋器？

3. Perl 跟 Python 有什么不同？

這課的作業，同樣是在問具體到Python這個語言平臺，在實際開發中可供挑選的現成工具有哪些？問的是對自身工作所使用的平臺熟悉程度。這課的作業，也完全可以根據使用的語言不同，而改成別的技術題目。

這課講的是實際中對工具掌控的熟悉程度這個方向，如果熟悉，那么這三個問題是很容易回答的，如果不熟悉，而為了做作業去打開Google，搜“python web框架”，然后填名字。那么就完全木有做作業的意義。

h2. 第三課

1. 找出一篇看上去很厲害的文章。

2. 找一本書，開始看，作為期中考書目。

這課講的是閱讀的重要性，兩項作業，一個要求閱讀的廣度，一個是要求閱讀的深度。

作業是要做的。OK，這課講了閱讀的重要，明白了，然后就洗洗睡了？自身的閱讀的東西，無論是廣度還是深度，都跟以前一樣，那學這課程有個毛用？

宣稱喜歡這個課程，并且表示關注、期待的同學，請問，你選擇的期中考書目，已經翻了幾頁？

如果一頁還沒有翻；那么請好好問一下你自己，你究竟是不是要學習提高改變自己的？

h2. 第四課

1. 林仕鼎是百度首席架構師嗎？

2. 看完曹政所有的blog。

這一課其實還是在講閱讀的重要性，以及對事物的好奇心。

如果，你對技術有熱情，有追求，課程中居然出現了“百度首席架構師”這樣的字眼，你必然會對他有無限的好奇，會去刨根問底的了解他。

那么，是很容易就發現林仕鼎根本就不是百度首席架構師，相反，caoz曾經更符合這個身份。

我列舉了兩個hacker風格的IT人物，一個是caoz，一個是云風。

作業有一項是看完caoz的所有blog，他的blog很好看的。如果你真的看完了，那么，請問你是否有完成這課實際上還有另一個隱藏的“作業”，“看完云風的所有blog”？

如果沒有，那是什么阻止了你？一個非常優秀的技術博客知識就放在你眼前，你，為什么不去看？

OK，沒有時間，很忙，這些我很了解。

我只問一個：是否有過要把云風的blog也看完的念頭？

如果連這基本的好奇心、求知欲都木有的話，那還是洗洗睡吧。

h2. 第五課

1. NoSQL的方案，如MongoDB還解決了SQL的什么問題？

2. NoSQL的應用場景有啥米？

這課是講數據庫，分析、比較了SQL、NoSQL，同樣的，需要課后去做更加深入的了解并且思考SQL、NoSQL的適用場景。

h2. 第六課

1. 使用一種編譯語言實現 Singleton 模式

2. 使用一種動態語言實現 Singleton 模式

3. 說說對 Provider 模式的理解。

如果連最簡單的Singleton模式實現都是上網google的現成代碼，那。。。還是那句話，洗洗睡吧。。。

這課講的是設計模式的必要以及局限，如果只是看到后面對設計模式局限的調侃，而無視了前面提到的：“開發中非常必要的知識，實際上，是非?；A的知識”。

你究竟對非?；A的設計模式了解得多深入了？第三題換個模式，你說得出理解么？

h2. 第七課

1. php 的 Smarty 模版的設計哲學是什么？

2. perl 的 Mason 模版的設計哲學是什么？

3. 什么是gettext?

4. 前端javascript實現的模版中，目前最成熟的是哪個引擎？

這課是講模版，模版有很多現成的實現，作業純粹就是在要求去了解、認識各種模版技術的實現。

h2. 第八課

1. 說說對 restful 的理解

2. 什么是 reverse proxy ?

restful / reverse proxy等，都是跟controller相關，但延伸出去的相關知識。

相關性究竟在哪里？這個可以做為獨立的一課去講述，但也完全是可以自學了解的。但這絕對不是在跟小明講了1+2=3后，問太陽與地球的距離。

h2. 第九課

沒有作業。

h2. 第十課

1. ED開發圣經PEAA究竟是哪本書？

2. 數據庫三范式是什么？

3. 關于Domain Model，什么是充血模型？什么是貧血模型？

第一題純娛樂，第二題是確認課本知識掌握；第三題則又是在要求延伸閱讀，實際上，也是在為下一課做預習。

h2. 第十一課

1. N-tiers架構的噩夢場景是？

2. 什么系統/場景需要充分使用特定數據庫的特性？

這課作業是在要求對課程做思考，寫課程時，我實際上是碼了很多字，去描述N-tiers的噩夢場景。但后來我又全部刪除。

因為，我前面已經講了很多關于分層、封裝的問題，也提供了The Law of Leaky Abstractions的連接，對N-tiers有了解，對分層的問題有了解，那么如果還不能認識到N-tiers這么一個多分層的技術的噩夢場景是什么的話；那么我還是只能說：洗洗睡吧。

整個課程，是在強調對數據庫的封裝。為了避免產生封裝就是好的教條思想產生，所有我又加了“使用特定數據庫的特性”這個作業，要求去思考一下相反的場景。

作業：

1. 補做之前的所有作業

宅男程序員給老婆的計算機課程之13：再談ED

【51CTO獨家特稿】ED是Enterprise Developer的縮寫，我是刻意用這個縮寫的，因為它還可以被解釋為Ejeculation Disorder。盡管我使用的名稱不一樣，但類似的概念是一直都有的。

像Joel Spooky則是稱他們為“In-house programmer”:http://www.joelonsoftware.com/items/2007/12/04.html 并極力勸說計算機系畢業生不要成為這樣的程序員。

Joel認為“In-house programmer”是“恐怖的”，并列舉了三條理由：

1. 永遠不會有機會用正確的方法做事。
2. 沒有機會做優雅的產品
3. 升職空間有限

我完全同意Joel的看法，實際上，我猜想很多“ED”也非常清楚了解他們的處境，經?？梢钥吹揭恍┚W文，諸如：

程序員們 不要想一輩子靠技術混飯吃http://developer.51cto.com/art/201111/299998.htm

這位作者對ED職業發展的描述非常真實，對于那些走在ED路途上的人做出了誠摯建議：不要一輩子都做技術。

我覺得他的建議跟Joel建議畢業生不要成為"In-house programmer"的出發點是一致的。ED是死路一條，不同的是，Joel建議畢業生去參與那些優秀的技術公司的研發工作，而這位作者則干脆建議ED們徹底不要做技術。

任何行業，都會有做得好，跟做得不好的人；因為自己做得不好，而否定整個行業，我覺得是挺可悲的。

即便在中國，純粹靠技術做得好，而獲得“穩定的生活和高的薪水待遇”的程序員大有人在，當然，做市場開發而賺得盆滿缽滿的人也有無數。

365行，行行出狀元。

在自己的行當里面混得不好，就指著別的行當的狀元說，看，別的行業比我們好多了～這挺沒出息的。

軟件行業有軟件行業的問題，也有它的優越；這構成了軟件行業的“風格”。關鍵是，自己是否喜歡軟件行業的風格。

若不喜歡，趁早換去別的行當；若是喜歡，那么應該努力的去做到最好；而不是發牢騷、抱怨這個行業中的不好。

關鍵在于自己的態度以及努力，想要有快感，首先是自己需要勃起啊！自己心態上不投入，沒有激情，ED是必然的。

作為職業發展，首先必須是自己真心喜歡、熱愛這個行業，即便沒有薪酬，沒有回報，自己也能夠在做事的過程中獲得精神上的滿足。

只有這樣才能夠在技術發展路途上精益求精，不斷進步；是的，即便“做到技術最強，也不可以成為100%受尊重的人”，但這并不是不把技術做到最強的理由。熱愛技術，“做到技術最強”，本身就是一個充滿誘惑的目標。

把技術視為敲門磚，自己本身就不尊重技術，那必然是沒有辦法成為別人尊重技術人。

無論外人怎么看，技術人都應當尊重自己。

豬頭時常跟我辯解即便是在銀行內部做IT也有升職空間，并且自己也不斷的在銀行內不斷提升、轉向更高的技術職位，其實是很厲害的。

Premier ne puis, second ne daigne, Mouton suis.

作業：
1. 這篇課程最后的法文的下句是什么？

2. Almaviva是什么？

3. 猜我為什么出上面兩道無厘頭的作業？

轉載于:https://blog.51cto.com/sleepgod/1352039

總結

以上是生活随笔為你收集整理的宅男程序员给老婆的计算机课程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。