聲明：
本文檔來自：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的“解決問題就好”，跟沒有下過廚房的千金小姐拿着菜譜使用微波爐做菜沒啥區別。
在大廚手裏，微波爐也可以是神器；但：
“有的人，縱然神刀在手，亦無法成爲刀中之神。”
程序員要“拚好積木”，那必然需要對積木的種類、材質、特性，有深入的瞭解。
總得對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
快速瀏覽即可，無需細讀；瀏覽過後再繼續往下看。
讀後的感覺是不是：
“雖然不知道在說什麼，但是看起來很厲害的樣子！”
整篇文章的關鍵是在這句：
“作者胡某某。曾任完美時空（現更名爲完美世界）顧問，承擔互聯網方面的部分管理工作。現在主要精力研究互聯網產品設計，是Axure授權的高級諮詢顧問和高級培訓講師。”
這也就是，我在第一課中提到的“啥事不做，整天四處佈道，名頭都很響亮，如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”則努力的去把雞蛋豎起來。
注意，牛“ED”未必就不懂得可以用手。
這樣“Hacker”精神，在雲風的blog上，還有另一個體現：屏蔽垃圾評論的驗證碼。
博客有很多垃圾評論，需要屏蔽，有很多很多種方式，各種神奇的驗證碼，葉貝斯規則過濾等等。
“ED”可以設計出來很多方案，並實現。
雲風腫麼做呢？
他在評論發表的時候，增加了一個項目：爲了驗證您是人類，請將六加一的結果（阿拉伯數字七）填寫在下面
“只要能解決問題，就採用最簡單的設計。”
這個驗證碼插件是我自己寫的，只有一行 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。可以把SQL看成是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等等。
就那麼幾個，花花功夫，仔細瞭解一下這幾個，然後在實際編碼中應用一下，便可以算是掌握了。
設計模式，並不難。
它是開發中非常必要的知識，實際上，是非常基礎的知識，並不牛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