正確認識ruby

ruby,曾經風靡一時的腳本語言,曾經被一群教眾捧上天的語言,而現在追隨者卻少的可憐,甚至可以說更多的只是用在了ROR上.

有人說：ruby只是腳本語言,速度肯定沒有C/C 運行快.有人說：windows有C#,linux有shell,為什麼還要費勁裝環境用ruby?......

與ruby相遇還是在我同事某日和我提到python的時候,當時的我僅僅只有C的基礎,對於腳本語言只知道VB.一副天真的表情看到了ruby.它的簡單不僅符合運維人員偷懶的精神,也同時減輕了運維人員對代碼編寫的壓力.這只是我看到ruby的第一瞬間,雖然想想當時的確相當幼稚,但是ruby對於一些支持它的人來說的確大部分的印象基本如此.

經過3個多月的時間,在一邊工作一邊自己研究的情況下,寫出了第一個ruby的腳本（僅僅是實現FTP對應伺服器拉取apache和IIS日誌的功能）.在放入計劃任務的那一瞬間,我興奮至極.然而事實永遠都是在打擊人的.之後公司需要做一個校驗CRC功能的腳本或程序.當然我作為一個運維人員,這個重任並不在我這裡,而是到了後台開發同事手上.但是為了展現ruby的簡潔,我不自量力的和他們展開了競賽.結果不言而喻,雖然同時完成了編寫,但是處理速度上,ruby慢的可怕.我錯在哪裡？

之後我又自學了java以及C#,終於我了解到了ruby真正的面貌和實力.重新拿起《ruby系統管理實戰》,發現原本不清楚的地方一點點的揭開了面紗.

ruby並不是神,也不需要膜拜,更不需要狂熱的追捧,它的存在只是解放運維人員和程序員的雙手.如果說C/C 是巨人的話,ruby則是站在巨人肩膀上的一個新生兒.它可以俯視很多語言,但它並不是巨人.說ruby是腳本語言的話,其實更應該說它是兼容性語言.正如ruby現在在國際上發展的趨勢一樣,它可以滲透到每一種非腳本語言中去,而它的目的並不是要取代,而是在一定程度上解放每一個寫程序的人.

作為一個運維人員應該對下面的這個命令（或者說是方法）非常熟悉：grep,那讓我們來看看這條命令吧：ruby -ne 'puts $_ if $_=~ /foot/' /usr/share/dict/words (出此《ruby系統管理實戰》第二章)如果你有ruby環境的linux的話可以試下,效果和grep幾乎相似.這時學習shell的朋友會吐槽了,既然linux都默認有shell了,你為什麼還要用ruby呢？來考慮下下面這種情況吧,我有一個定時處理文件腳本本來是在linux上的,有一天系統要換成windows,這時ruby只需要更換下文件路徑寫法,而shell我去兼容win上的CMD或是寫成其他語言.這就是ruby的兼容性,對於不同的系統你所要做的僅僅是在參數上去匹配當前系統的樣式,而不需要去管系統是否兼容這裡的任何一個方法.我可以用更多的時間去優化這個腳本而不需要浪費在移植上.

ruby並不快,但也不會慢到你不想使用它.以我前面的CRC為例子,當時我怎麼想都找不到原因,直到看到了ruby的profile.寫得快和運行的快,永遠都是2個極端,如何權衡好才是ruby真正的魅力.當你把一個ruby代碼寫的很快並且運用了很多類的時候請好好的檢查下這些類你是否詳細直到方法的運行過程,如果在你不知道的地方存在了額外的步驟,那ruby只能給你帶來漫無止境的等待.這並不是嚇唬人,而是真實的情況,有興趣的朋友可以看下find類,我深受其害.find在查找文件或文件夾的同時還會運行test去判斷相關資源分支的大小,雖然1個文件影響不大,但是文件一旦多,目錄一深test就佔據了絕大多數的運行時間.這個時候我們可以使用另一個方法來替代find：

Dir["**/**"].each do |f|

......

end

這個代碼並不難,但是要第一時間想到用這個可能需要點時間,一般大家會很當然的去用find,這也是寫得快和跑得快的比較簡化的對比.

希望更多的人來關注ruby,無論你是否會代碼,無論你是程序員或是運維.ruby的未來只是便利與每一個人,而不是和其他語言搶佔一席之地. ruby也並不只有ror ,RpgMaker、Jruby、腳本應用都是ruby目前比較主要的用途.

PS：吐槽...其實只是看到更多認識ruby的人都在用ror用了點時間把自己對ruby的認識進行了下總結,更多的帶了點個人思想,有不同意見的也可以提出來.畢竟只有討論才能得到進步才能知己知彼.

本文出自 「芙蘭朵露斯卡雷特」 博客,請務必保留此出處http://daddy2000.blog.51cto.com/3417135/867364