按正常的作息時間，現在已經睡着了，但今天加了點班，回到家又吃吃飯喝點啤酒，就不太困了。 既然無事，就寫些閑話雜談吧，反正也好久沒更新過了。
剛才看博客園一篇文章《記一次面試經歷》，里面談到zookeeper分布式協調，很高深的樣子，就百度科普了一下，原來是和大名鼎鼎的Hadoop有聯系的。
此處也附帶幾個鏈接，為以后查看做個標記。
分布式服務框架 Zookeeper -- 管理分布式環境中的數據
就在上一年，這些分布式之類的概念都離我很遠，只存在我的念想中。因為之前是做企業或學校內部管理系統的，對分布式的需求幾乎沒有，或者那時候我還沒有意識到什么是分布式。但自從進了互聯網公司之后，會越來越多的接觸這些概念。公司在成長，數據在變大，個人也要跟着成長，要不然跟不上時代的腳步就被遺棄了。現在一些數據量大，耗時的動作，為防止網頁超時，需要發送指令給后台處理，還要涉及不同系統之間的信息共享，又要防止因各種錯誤中斷，不影響任務的繼續執行。這些都是現在或以后需要考慮的事。
以前覺得自己的技術還行，除了設計無感，前后端都可以，接觸了更多的同事之后，發現自己的js水平還很初級。去年剛來公司時，連chrome的js調試工具也不會用，以前完全即使alert或者IE的debugger調試的。chrome的這個F12 console調試更加方便。之前我也封裝過各種彈窗，表格插件，提醒等，但和新同事的比起來，規范性和維護性都有些差距，認識到不足，才能提升。
以前做查詢的時候，還是一個一個的拼接字符串，是多么的浪費時光。后來發現asp.net MVC自身的Model綁定，然后利用一些ORM或泛型或反射來處理好查詢條件，節約了不少精力。這是對去年的自我檢討，今年已經再漸漸改正了，逐漸采用3.0，4.5以后的操作方式，lamuda表達式，List的查詢，C#的表達式樹等，來提高工作效率。新版本的特性也要更多的了解。
以前聽說高內聚，低耦合，只知道模糊的概念，並不知道有什么好處，也沒有具體的案例來分析。現在總算有一個大體的認識了（或許也很基礎）。如果新建了一個項目，要引用老項目里面的一個小接口，卻需要把老項目很多地方都引用進來，一層套一層，這就是比較坑的地方。老項目有些地方耦合太深，解耦任務經過不斷的嘗試和修改，已經有了很大的提升。說起這里，我想起過去一個項目的二次開發，那里面一個方法里面一層套一層，最后能套幾十層，再加上里面一層層的接口實現，橫跨大半個仙姑，最后都不能確定某個方法是誰調的了，維護性非常差。經歷了這些坑，就能理解高內聚，低耦合的重要性了。高內聚就是要模塊內的各個元素盡量緊密結合，低耦合就是要各個模塊之間盡量減少依賴。
工作（生活）就是不斷填坑（需求）的過程，有的人懂的多，已經預先填好了，走的路就順暢些，有的人走一步填一步，沒有規划，走過的路就坑坑窪窪的，一下雨就完全癱瘓。彌補這種情況的好方式，就是多學習，多思考，多看牛人的解決辦法。
計算機界有個出名的摩爾定律：當價格不變時，集成電路上可容納的元器件的數目，約每隔18-24個月便會增加一倍，性能也將提升一倍。摩爾定律雖然不是萬能的，但生活也應該像摩爾定律一樣，在相同的工作時間，產出的效率和工資，約每隔18-24個月便會增加一倍。如果還沒有做到，一定是還不夠努力，努力學習新知識吧，在合適的情況下，多投投簡歷，試試自己的水平。比如金三銀十階段，即使不打算換工作，也可以試試水，畢竟如果一年半換一次工作的話，貿然提高一倍工資會心虛，但如果換成三個階段，每半年廣撒網一次，探探水，看看外界都是需要什么水平的，實時調整自己的方向，每次試投提價30%，一年半后就真的翻倍了。摩爾定律作為一種指導思想還是不錯的。隨着年齡的增大，步入中年期，就有瓶頸了，畢竟IT是個吃青春飯的活。
最近盛傳36歲IT男加班猝死，園子里也多有文章辯論，所以大晚上的還是好好休息吧！。