基本介紹
- 中文名：范凱
- 國籍：中國
- 出生地：上海
- 職業：資深軟體工程師
- 主要成就：JavaEye技術網站創始人
- 性別：男
個人經歷,個人觀點,思維方法,個人榮譽,個人評價,
個人經歷
范凱 先生是Java諮詢專家，目前任JavaEye技術網站總經理.范凱是JavaEye網站創始人，2006年范凱決定使用ruby來開發JavaEye網站，在隨後的三年時間裡面，JavaEye網站作為中國最早的Ruby on Rails開發的網站，一直扮演著ruby在國內軟體開發社區的布道者角色。時至今日，JavaEye網站已經成長為一個每日PV超過100百萬的軟體開發入口網站，是中國規模僅次於CSDN的第二大軟體行業專業網站。
個人觀點
來自范凱的個人部落格
我的PHP，Python和Ruby之路
我2000-2001年用PHP用了兩年，那還是第一次網際網路泡沫時期，到2001年後期，Servlet/JSP流行，然後我就發現：你說用PHP寫的東西，都會被人鄙視。當時我們其實也用Java了，只不過用Java寫後端的訊息佇列。
2001年後期泡沫破滅，我跑去做企業套用，就主要寫Java寫了很多年，中間2003年開始做JavaEye網站，到2006年用Rails重寫JavaEye之前的3年，用的是phpbb搭建的，所以PHP也斷斷續續一直用到了2006年。
JavaEye
JavaEye以我2000-2006年總共六年多的使用體驗來說，我對PHP真的是深惡痛絕之，但凡做一個稍微大一點的系統，代碼就很容易失控。2002年以後，我曾經一度以為PHP這個東西快死掉了，那個時候大家都言必稱J2EE和.net了。結果Web2.0之風襲來，大家又發現J2EE太重，PHP又死灰復燃了，我其實很詫異現在PHP居然又變得如此流行。從技術上來講，PHP是個很爛的東西，但它門檻低，易部署，普及率高，好找人，實在是網際網路時代的VB，打不死的小強。
Python我大概是04-05年迷戀了一年左右，研究過Zope，plone，後來還看過wxPython，曾經一度想用Python寫JavaEye網站。記得04年Rails出來之後，還很長一段時間被我深深鄙視過。
但後來我去杭州拜訪potian，被他的Rails實踐經驗說服了，之後我和他以及其他人在JavaEye上面有一個很長的討論貼，討論Rails的運行機制，最後我又被他說服了。然後我還不死心，研究和比較了Rails和Django，不得不死心了，後來還曾經幾次想用Python，每次都死心的很徹底，現在就徹底不考慮Python了。
PHP用一句話來總結就是：quick and dirty
Python用一句話來總結就是：quick and clean,but not convenient for web development
Ruby用一句話來總結就是：code for fun and quick for web
在選擇用什麼工具開發JavaEye網站的時候，唯一的指導標準就是：用最少的人力，最少的時間開發JavaEye網站，並且後期維護和持續升級，乃至重寫的時候，代價最小。
首先排除Java和C#，代碼太多太麻煩；
其次排除PHP，項目一大，代碼一多，代碼的管理很成問題，PHP缺乏一個起碼的包管理機制；
但後來比較了Rails和Django之後，就傾向於Rails了，差距實在太大了，而且當時Django很不成熟，在很早期的版本。其實即便現在Django和Rails的差距也沒有縮小過。
但讓我最終下定決心的是potian在05年就大規模使用Rails的實際工程經驗，我曾經去杭州就我比較質疑的問題當面請教過他，和他談過以後，就決定用Rails了。
應該說，我當初用Rails的決定很英明！
Java已經過時了嗎
在三年以前，當我開始讚譽spring的時候，spring還面臨著EJB3的陰影，以及EJB2對其不登大雅之堂的指責，然而不到一年的時間，spring已經成為絕大多數Java開發人員的首選；
而當一年之前我開始採用RoR開發JavaEye的時候，RoR的置疑之聲還甚囂塵上，但當我在今年初預言07年下半年RoR在國內會被廣泛接受的時候，很多人已經笑不出來了；
今年我預言些什麼呢？我覺得會是AJAX技術走出PC的時代，證據就是iphone，與此相關聯的事情就是REST架構的流行。
但是這篇文章裡面我想談的卻不是我預言的水平準不準，而是想談Java真的會因為RoR的流行而過時嗎？目前在web開發主要套用在兩個大的領域，網際網路和企業套用，我們分別來看一下：
一、網際網路領域
2．大中型網際網路站強調穩定性，性能，大規模代碼的組織能力，而開發效率則退居次要地位，有些套用如電子商務對事務有很高的要求，顯然Java是最合適的選擇；PHP的代碼組織能力最差，RoR次之。
在網際網路領域，Java從來就不是主流，並且Java的適用領域和RoR不太重合。我們甚至可以這樣說，RoR現在在網際網路領域取代的是那些原本不適合用Java，但是被錯誤的選擇了Java的項目。
二、企業套用領域
目前企業套用領域第一大語言是Java，dotnet其次。企業套用採用的技術和行業有很大關係：例如金融行業，電子政務行業一般只採用Java。dotnet發展了6年尚且沒有進入企業高端的套用，RoR在短期之內也很難取代Java的地位。
在企業套用領域，Java是主流，並且Java的適用領域和RoR也不太重合。我們也可以這樣說，RoR將來在企業套用領域要取代的是那些原本不適合用Java，但是被錯誤的選擇了Java的項目。
至此，我想Java程式設計師大可以鬆一口氣，RoR目前有哪些不適合的場合呢：
1．對事務要求非常高的場合
RoR還是很簡單的單資料庫事務控制，缺乏精細的事務控制功能，當然也不支持跨資料庫的分散式事務。因此對於事務要求嚴格的大型電子商務網站，部署複雜的分散式資料庫場景顯得力不從心。當然也許有些plugin可以提供這些功能，但是從目前的功能完備性和成熟度來看，還不夠。
2．處理大量遺留資料庫的場合
ActiveRecord的威力很大程度上來自約定，大量命名糟糕的遺留資料庫會對RoR造成比較大的障礙。
3．龐大的項目團隊，對開發速度要求低的場合
例如日本外包項目，團隊龐大，個體開發速度要求低。但是對於代碼規範要求嚴格的項目。
雖然RoR不會取代Java，但不意味著作為程式設計師的你可以固步自封。即使在工作當中用不上RoR，多看一點新的技術，對於開闊個人視野也有很大的好處。
談談我為什麼要學習ruby on rails
挺有意思的現象
記得過去還沒有創辦JavaEye的時候，在技術社區裡面推廣Hibernate(也算不上是推廣，只是和別人交流Hibernate)，就有一大批人酸酸的跳出來說，你們今天學習這個明天學習那個框架，全都是跟風，這些框架都是浮雲，真正JDBC這種基礎知識才是實力的，我就用JDBC，我用的一直很好，我完全沒有必要去學習Hibernate……
每當看到這種話，我就覺得特別好笑，用一個我發明的說法叫做“牛逼哄哄的露怯”。沒有人逼你學習Hibernate，你不樂意關心Hibernate，那就繼續用JDBC好了，這個世界從來都不是非黑即白的。
其實這種人的心態很有意思。他一方面眼紅人家學習新的技術，另一方面自己又不想花時間和代價去學習，所以恨不得所有的人都不要去學習新技術，這樣他心裡就感覺很安全了，正因為如此，他就總是要時不時跳出來打擊一下別人，表面上很牛逼，其實虛弱的內心掙扎一覽無餘。
如果想把技術作為終身職業，那么對於技術人員的起碼要求就是不能固步自封，要始終以開放的心態接受新技術。
打好基礎知識固然重要(重要到根本無需你一遍又一遍的祥林嫂)，但是不接觸新技術，新思路，新的理念，很快就會被淘汰掉。
當然學習新技術也不是盲目的什麼都學習，什麼流行學習什麼，而是根據自身的需要，有選擇的學習。例如Java Web框架有很多很流行的，Struts，Webwork，Spring MVC，Tapestry，JSF，主流的就有5個，盲目的學習者就是人家說什麼他就學什麼了。而聰明的學習者應該對這些東西都去接觸一下，從中選擇一個值得自己投資時間成本去學習的框架。例如對這五個框架我都涉獵過一遍，最終我把時間花在了Webwork上面，事實也證明我當初的投資是正確的。
我學習ruby on rails有很現實的需要，其實即便拋開現實的需要，我也認為如果有空，Java開發人員有必要學習一下，原因是：
1、ruby語言和rails框架的社區力量正在以驚人的速度增長，甚至已經進入爆炸式繁榮的前夜，這不是曇花一現的現象，而是一個時代開始的象徵。
2．從我這段時間學習的情況來看，ruby語言有足夠的學習深度，我原來以為自己一個很快速的上手，然後就很精通了，但是ruby不像PHP那種速食麵，其知識的廣度和深度都讓我感覺這是一個完整的知識體系。也正因為如此，ruby生命力會很長。
3． ruby和rails是非常非常Unix-like的東西，經常和作業系統提供的功能有深度的依賴，這和Java這種不依賴作業系統，什麼基礎設施都自己捲起袖子自己創造的理念相比，非常非常的不同。這樣做會帶來一個很大的好處，很多在Java裡面解決方案很複雜的問題，在ruby方案中就很簡單可以搞定，相比之下，讓Java顯得頗為大而無當。
不過ruby和rails也樹立起了一堵牆，這堵牆就是Unix作業系統，要學好我，你就先跨越Unix這堵牆吧。呵呵，這也是為什麼rails core team清一色的MacOSX的原因了。
不過我覺得這是好事，我本人是Unix fans，樂意見到這種現象，況且憑藉我多年深厚的Unix功底，在ruby fans中，我又站在了一個很高的起點上領跑了。
想學好ruby嗎？先在你的電腦上面安裝MacOSX/ubuntu作為開發環境咯。
Ruby為什麼會受程式設計師的歡迎
孟岩最近寫了一篇部落格：
Ruby 1.9不會殺死Python
這篇文章很有點標題黨的意思，所以在JavaEye論壇很快被水掉了，只好鎖貼：
但我個人對於孟岩的觀點是不敢苟同的。首先我並不同意所謂魔幻語言和簡約語言的分類。其實Martin Flower論述過這個問題，他是用“人性化接口”和“最小接口”來區分程式語言的風格化差異的。
其實不用我多說，Martin論述的挺充分了。強把Ruby和C++歸為魔幻一類，其實並不準確，因為Ruby的魔幻語法和C++相比，最大區別在於：
C++的魔幻語法會導致代碼的可讀性變差，而Ruby的魔幻語法會導致代碼的可讀性大大提高。
不論是matz本人，還是整個Ruby社區，Rails社區諸多開源項目的作者，抑或整個Ruby和Rails開發者社區，在一個編程哲學問題上是高度統一的，這就是：
強調程式設計師的快樂編程，追求人性化編程，在代碼的可讀性上面有偏執的追求，拒絕難以閱讀的代碼和難用的API。也就是所謂的coding for fun!
所以你看無論是Rails，rake，rspec，甚至移植自lucene的ferret，都鮮明的體現出來這種特點，就是API簡單好用，讓你寫的代碼像英文文章，自然流暢，輕鬆愉快。要是哪個Ruby框架的API複雜晦澀，在Ruby社區簡直沒法混，大家根本不買他的帳，這也是為什麼Ruby套用於DSL領域這么熱的根本原因。
對於ruby程式設計師來說，這種追求編程人性化的哲學理念會潛移默化影響程式設計師，讓他不知不覺把代碼的可讀性越寫越好。對於程式設計師來說，誰不想coding for fun呢？ 而當你品嘗到了coding for fun的樂趣，又怎么會輕易拋棄？
所以Ruby受程式設計師歡迎的根本原因還是在於它是一種能給你帶來編程樂趣的語言。
Ruby和Rails的缺點
有人說，robbin你說了那么多RoR的優點，你啥時候說說RoR的缺點阿？你說的缺點肯定比別人說的更客觀。沒辦法，為了表現出來我不是一個RoR粉，只好總結點缺點，以饗RoR黑子們：
ruby的問題我覺得主要是：
1．ruby本身的性能是比較差的，無法直接做一些計算密集型的任務
比方說大量的分詞運算、語料訓練什麼的，用ruby寫是不行的
2．ruby的C擴展很難寫
正因為ruby性能差，所以很多情況下要依賴C寫的底層庫，但是寫ruby的擴展C庫是很困難的事情。一方面沒有特別多的資料介紹，你能參考的只有《Ruby Hacking Guide》，另外一方面Ruby是帶有GC的語言，C又是沒有GC的，所以如果你對ruby的GC機制沒有特別清楚的了解情況下，寫C擴展會出現意想不到的問題：比方說你寫的程式邏輯沒有任何問題，但是和ruby配合起來就會不定期的出現錯誤，這就是你C程式的某個賦值變數可能會被ruby GC以你意想不到的方式銷毀。
3．ruby的C擴展庫質量不高，容易出現記憶體泄漏問題
正因為上面的原因，很多第三方的C擴展庫質量不好，很容易出現記憶體泄漏問題，這是一個很頭疼的問題，你很難定位，也很難解決，只能儘量避免使用第三方擴展C庫。
Rails的問題我覺得主要是：
1．特別容易出現命名衝突
你自己寫的代碼裡面給類增加的方法，動不動就和Rails給類擴展的方法名稱衝突了。這種錯誤很隱蔽，很難發現。這也是ruby語言動態性帶來的一個負面影響
2．Rails每次升級API變動都比較大
Rails升級是不太考慮向下兼容性的，所以每次升級的話，可能你很多代碼都要改，更糟糕的是很多Rails外掛程式特別喜歡以hack rails的方式來擴展Rails功能，那么Rails一升級，外掛程式的兼容性幾乎肯定是不行的，這個是比較痛苦的事情。
3．Rails的view方面還是比較原始的erb拼接字元串方式，像JSP那樣原始，沒有一個類似Java的velocity/freemarker那樣的頁面模版庫，所以寫helper動不動要用字元串去拼html片斷，如果是特別複雜的view需要拼的話，代碼就會寫的很醜陋。
當然總體來說，RoR還是讓我感覺非常滿意的，特別適合網際網路套用。
做網際網路產品的節奏感
從無到有剛開始做一個網站或者一個產品，要非常聚焦，沒有旁的多餘功能，只有一個做的極其牛X的核心功能，牛X到別人沒有辦法模仿你，於是網站開始嶄露頭角；
等核心功能成功以後，網站開始聲名鵲起，為了擴展用戶規模，產品開始多元化，各種各樣時髦功能，各種各樣用戶要求的功能紛紛上馬，於是用戶規模開始快速擴張；
等用戶規模已經起來之後，開始聚焦商業目標，於是刪繁就簡，開始砍掉與商業目標不符合的枝節功能，加強和商業目標符合的核心功能，網站進入健康的商業循環；
大部分網站都可以做到第一個階段，但其中大部分都會倒在第二個階段，而邁過第二階段能夠做到第三個階段的就鳳毛麟角了。到了第三個階段，一個產品才真正開始成熟起來，才具有頑強的生命力，在IT垂直領域裡面，JavaEye處於第二個階段，需要向第三個階段轉變。
也曾經盲目的想把JavaEye的規模做到行業最大，於是上了各種各樣的產品和功能，很多都沒有細化和雕琢，現在想來都有些多餘，而符合商業目標的核心功能又用力不足。現在總算想明白一個道理：規模最大又如何？還是不賺錢。所以接下來怎么做就很清楚了。
另外一條思路是做平台，網際網路的未來生態系統肯定是由平台和內容提供商構成的，你要么做平台，要么做內容提供商。但在IT垂直領域，用戶規模和市場空間過於狹小，平台沒有足夠的空間生存，所以這條路不通。不要企圖做大而全的門戶，不要企圖做無所不包的平台。
定位好目標，不要做無關的功能，突出符合商業目標的核心功能和產品，足矣！
思維方法
范凱是從學習Java編程開始接觸OOP(面向對象編程)，剛開始使用Java編寫程 序的時候感覺很彆扭，因為我早以習慣用C來編寫程式，很欣賞C的簡潔性和高效性，喜歡C簡練而表達能力豐富的風格，特別忍受不了Java運行起來慢吞吞的速度，相對冗長的代碼，而且一個很簡單的事情，要寫好多類，一個類調用一個類，心裡的牴觸情緒很強。
范凱對Java的面向對象的特性琢磨良久，自認為有所領悟，也開始有意識的運用OOP風格來寫程式，然而還是經常會覺得不知道應該怎樣提煉類，面對一個具體的問題的時候，會覺得腦子裡千頭萬緒的，不知道怎么下手，一不小心，又會回到原來的思路上去。
舉個例子，要發廣告郵件，廣告郵件列表存在資料庫裡面。倘若用C來寫的話，一般會這樣思考，先把郵件內容讀入，然後連線資料庫，循環取郵件地址，調用本機的qmail的sendmail命令傳送。然後考慮用Java來實現，既然是OOP，就不能什麼代碼都塞到main過程裡面，於是就設計了三個類：
一個類是負責讀取資料庫，取郵件地址，調用qmail的sendmail命令傳送；
一個主類負責從命令讀參數，處理命令行參數，調用發email的類。
把一件工作按照功能劃分為3個模組分別處理，每個類完成一件模組任務。
