框架設計
提供framework design guideline.
摘要: 從以下幾個方面進行比較：
1.從技術方面對框架的優點和缺點進行分析
2.從IDE支持的情況進行對比分析
3.從精通那個框架更有利于找到工作進行分析
4.從用人單位招聘的Job數據進行分析，看那個框架出現在招聘要求中的次數更多
5.從亞馬遜上的看那個框架出的書最多
6.從Google 搜索分析Google trends看那個框架搜索最多
閱讀全文
摘要: Oracle一直致力于全文檢索技術的研究，當Oracle9i Rlease2發布之時，Oracle數據庫的全文檢索技術已經非常完美，Oracle Text使Oracle9i具備了強大的文本檢索能力和智能化的文本管理能力。Oracle Text是Oracle9i采用的新名稱，在Oracle8/8i中它被稱作Oracle interMedia Text。使用Oracle Text，可以方便而有效地利用標準的SQL工具來構建基于文本的新的開發工具或對現有應用程序進行擴展。應用程序開發人員可以在任何使用文本的Oracle數據庫應用程序中充分利用Oracle Text搜索，應用范圍可以是現有應用程序中可搜索的注釋字段，也可是實現涉及多種文檔格式和復雜搜索標準的大型文檔管理系統。Oracle Text支持Oracle數據庫所支持的大多數語言的基本全文搜索功能。
閱讀全文
摘要: Ibatis在項目開發中，無論是企業管理還是電子商務，Productivity作用都非常的大，淋漓盡致的體現了模板的好處，將sql的繁雜的語法和查詢條件參數數據清晰的剝離出來，無論是開發速度和代碼的易維護性上，都是無可比擬的。我對于ibatis的源碼進行了改造，起名為XIbatis。主要在分頁上做了增強，并以后會在模板語法上做改進。
閱讀全文
摘要: 基于Struts2的開發，如果沒有足夠的經驗和規范做支撐，并不能帶來還多的好處，如果失控，一樣和JSP+servlet泛濫，這一點需要警示。
閱讀全文
摘要: Ext.form.ComboBox 是基于輸入框封裝的widget，很靈活，代價是易用性非常差，特別是針對復雜的多級級聯框。
調用者需要針對自己的需求做一下靈活的封裝，來降低復雜度，讓開發人員更容易調用，同時代碼復用的程度更高。
無論是省市鄉鎮，還是商品分類，無論是兩級，還是多級，還是同級多個Child, API的行為都應當保持一致。
閱讀全文
摘要: 框架畢竟是框架，沒有最完美的，只有相對合適的，使用者需要分析知道自己的問題在那里，然后去設計開發、使用合適第三方的框架，或直接使用、或二次封裝、開發、修改源代碼，來解決自己的問題，總之，不要做一個問題的抱怨者，等著別人煮米下鍋。
閱讀全文
摘要: 最近，負責客戶的一個項目設計的審計工作，是一個短信平臺的項目，上行和下行通信都有，之所以叫平臺，是想將客戶的很多的業務系統，涉及到短信的部分都統一掛接到者一個服務平臺當中，只要一家服務提供商，量大從優，避免各自為戰，浪費資源。業務系統多是遺留系統，當中對短信需求各不一樣，客戶從自己的vendor List中找了一個短信服務提供商（SP）。一般的要是能進入vendor list中，說明實力還是有的。
閱讀全文
摘要: 對于business rule, 一般的情況是， 好的BA，可能更善于發現、抽取business rule ，并用結構化的方式描述、記錄下來， 普通的BA可能更是一種流水賬式的、吃那拉那的描述方式。
不管怎樣，BA在寫文檔，use case的時候，那些business rule被分布在文檔中不同的部分，然后這些rule，在分工時，有被理所當然的分給不同的開發人員來開發。
閱讀全文
摘要: 設計者高高在上，不食人間煙火，只是提供約束，不要這樣，必須那樣，而不是提供方法和可以復用的API。
開發者是處于解決問題的一線，飽嘗重復造輪子的疾苦，他們最需要的是快速的解決問題，以更恰當的方式工作，尋找更容易構建系統的技術和方式。
Jquery給設計者上了很好的一課。
Jquery就像一個魔法師一樣，$()就像魔法棒一樣，隨手一指，一個木偶變復活了，一瞬間具備了各種各樣的復雜的能力。
閱讀全文
摘要: 技術是基礎，積累才能提高，用戶是目的。成熟的架構+創新的擴展，server端，團隊應當繼續構建、成熟以spring為基礎的企業應用開發平臺，深度挖掘、孵化、封裝，同時將精力轉向客戶端。努力實現客戶端與server端的粘合劑開發提高開發效率，建議的平臺是spring + jquery
閱讀全文
摘要: full-stack 的設計，意味著各層能夠無縫的集成在一起，遵循的DRY原則（don't repeat yourself)，將各層共用的東西，抽取出來，并通過自頂向下的設計，無縫的集成在一起，粘合在一起，達到更高層次、更粗粒度的重用，同時為了保證靈活的可擴展性，在更高、更粗的粒度上遵守開放-封閉的原則，在各層的各個關鍵點，要提供諸多的鉤子，回調的接口，供使用者擴展。full-stack的設計，在層與層之間，并不一味的追求松散的機制，而是相反，在層與層之間增強一定的內聚性，粘合力，以此來達到粗粒度的封裝與重用。
閱讀全文
摘要: 最近做一個比較大的電子商務項目，預計每天訂單量將在５萬多單，客服人員需要頻繁的下單、查詢訂單、操作訂單，客人預訂完訂單后，會立即進入處理流程，為了提高服務質量，要求流水化作業，平均要在４０分鐘－８０分鐘內處理完訂單。所以訂單在創建后，會在短時間內，被頻繁的修改和查看.
閱讀全文
摘要: 我覺得現在技術換代很快，使用一項技術，首先是要快速的解決問題，然后要學習他的思想，那些整天死抱著Hibernate，自認為學習到ORM的設計技巧的人，就去繼續的學吧。
我已經會用Hibernate的一些方面，我覺得夠用就行了，犯不上，天天鉆研HSQL，如果有時間，我覺得躺在草坪上看看Unix的編程藝術，看看代碼大全，看看Oracle的編程藝術，比看Hibernate的SB書要愜意多了。
閱讀全文
摘要: 我認為避談代碼是可恥的，只要編碼有意義，我們在任何階段，都應當投入到編碼當中。
閱讀全文
摘要: 所以對于框架來說，職責的分擔，是很重要的，完成你該完成的，該擴展的地方，即要提供默認實現，也要提供接口，供調用者二次開發。這才是框架的可擴展性、靈活性所在。
很多人在開發框架時，總期望做很多東東，自己給自己加套，反而喪失的靈活性，同時提供了很多不能擴展的實現，等于強加意志給使用者，愛用不用。
閱讀全文