感謝oschina為我們提供了這麼好的共享與交流平台。
感謝蕃薯及oschina管理團隊所有打過沒打過交道同仁對tiny一直以來的支援與幫助。
感謝所有鼓勵和批評我的同學們，鼓勵者為我們添加勇氣，批評者讓我們彌補不足。
感謝那些關注或點選過我的同學們，你們每一次的點選都會給我們力量，讓我們堅信我們做的是有意義的；也感謝那些從來沒有點選過我的同學們，因為你們讓我知道我們還需要做得更多，更努力，更紮實。
當然尤其要感謝我的團隊，正是我的團隊們幾年來對我的強力支援，才使我的夢想慢慢一步步變成現實。
讓我們回顧一下，我們的幾個重要時間與數字：
我們把源碼庫遷入osc git的時間是2014-2-21日，到目前為止，主工程已經有1014個commits，算上其它工程，commits應該在2000以上。
加入oschina的時間是2013-08-09，到目前為止，寫的部落格是124篇 ，其中被osc推薦的有32篇，其它的沒有被推薦，但并不妨礙它們大多數都是精品。
到目前為目在osc上的項目已經有18個之多，一部分是開放的，一部分是私有的，總共代碼行數已經接近30萬行，我們自己寫的大概有28萬行左右。
我們入駐sourceforge的時間是：2013-06-20 09:30:18 ，從開始到我們遷入oschina，我們一共有3451個commits
代碼複雜度：2.5 /method，15.1 /class，17.5 /file
代碼重複率：2.8%
sonar品質規則完成度：80.8%，如果去除我們引入的第三方的代碼，應該在90%左右
以上品質資料可以與任何高品質項目相比較。
2014-3-1 tiny
2013-6-30 tiny架構有了第一個客戶，
2012-3-14，tiny架構正式開始啟動編碼
2011-6-4，tiny架構正式開始啟動，并逐漸開始驗證其中的技術難題
當然，再向前推進一點，那就是我策劃并開發一個公司的j2ee的開發平台，雖然取得了相當的成績，但是我總是感覺它距離我理想的架構還有相當的距離，但是由于項目是在公司體系下開發的，有時候想改變，卻有心無力，而此時開源氛圍愈加深厚，于是就催生了我通過開源方式來建構一個開發平台的想法。
她應該是小的、簡單的，滿足simple is beautiful
她應該是成長性好的，随着不斷的擴充，她可以越來越豐滿
她應該是有良好工具支援的，為什麼要花時間做工具可以完成的事情呢？
她應該是自組裝的，也就是盡可能的脫離配置，而是用一種依賴即可用，取消依賴即消失的全自動處理模式
她應該是子產品化的，所有的内容都可以被打入jar包而作為一個整體進行釋出，并且能支援熱部署的，可以開着車兒換輪胎的
她應該是支援水準部署的，想加伺服器就加，想減伺服器就減
她應該是有良好知識積累體系的，使得使用tiny架構的人們越用越強，越用越爽
她應該是便于企業降低開發成本的，便于技術經理控制開發進度的，便于開發人員快速上手的
她應該是避免重複勞動的，所有軟體參與者都不應該做重複的事情
她應該是自管理的，最好不要讓程式員配置這個配置那個
她應該是讓人有種"衆裡尋他千百度,蓦然回首,那人卻在,燈火闌珊處”的開發架構
雖然整體體量比較大，但是它的每個子產品都分得非常小，是以非常容易掌握
它的各種元件都可以友善的進行擴充，通過擴充可以不斷的提升系統的處理能力
它的工具已經非常強大，而且它還是變得更加強大。
不管是管理台還是過濾器、servlet，不管是流程元件還是ui元件，還是ui元件包等等都是可以自組裝的
在tiny的世界中web工程隻是個集合，除了配置檔案和pom依賴，不應該有其它東西
支援水準擴充，同時可以支援7*24小時運作
開始團隊由金字塔向啞鈴型轉變，高低水準者各司其職
絕大多數情況下，要做的隻是依賴，而不需進行配置
"衆裡尋他千百度,蓦然回首,那人卻在,燈火闌珊處”，這一點是我們永遠追求的目标
架構者十幾年平台架構經驗，避免了n多已經走過的坑
工程結構細化使得一切都可以非常容易了解及掌握
高内聚、低耦合、高品質的代碼
完善的文檔，快速入門在130頁左右，全部文檔接近600頁，還在不斷增加當中
與第三方平台的良好內建能力，想用什麼就用什麼，有非常低的侵入性
核心、前台、背景、ui、工具一應俱全
可以提供一站式應用開發支援，大多數的情況下都已足夠
專職的團隊，可以保持項目持續不斷的前進
基于架構者設計的開發架構及tiny上的産品的銷售額累計有5個億左右的銷售額
正在建構的tiny生态圈，上百個ui元件及流程元件已經足夠你日常使用，還會有更多被不斷加入
在校學生，經常會做畢業論文啥的，如果需要搞點有深度的，到tiny架構中挖挖，可以有不少猛料
soho一族，整合ssh/i之類架構來做做應用一般是夠的，但是tiny架構依然可以給你不一樣的選擇
個體或小型企業，很明确，光是ssh/i已經不足讓你的方案看起來高大上，也不足以支援業務資料量比較大的時候的應用場景，也不足以支撐居高不下的軟體開發實施成本。
中型企業，個體或小型企業碰到的問題你都會碰到，尤其還要考慮是的多系統內建、體系化規範建設、人員複用、資産複用等等諸多問題，自己建立團隊需要解決合适的人、巨大的成本，巨大的風險。
我相信，肯定也會有諸多質疑的聲音，這是非常正常的，不過在質疑之前，請先參考一下如下事實：
tiny建構了遠超過velocity性能和功能的模闆引擎
tiny建構了基于jdbc driver的資料庫分區分表引擎
tiny建構了高性能的xmlparser、htmlparser
tiny建構了網絡爬蟲
tiny建構了dbf讀寫程式
tiny建構了高效、強大的中文分詞引擎
tiny建構了虛拟檔案系統，簡單、高效、且不存在記憶體洩露(apache vfs中存在)
tiny解決了子產品化問題，可以把一切資源放入jar包，甚至jsp
tiny解決了前端ui元件化問題，所有js,css,img都可以打入jar包，而讓程式員避免關心ui元件的依賴關系
tiny解決了每次更新的資料庫腳本更新問題，程式員可以告别編寫更新腳本的生活
tiny解決了緩沖從業務代碼中完全剝離的難題
tiny解決了服務的一次開發到處使用難題，webservice,json,xml,etc統統不是問題
tiny解決了流程編排全自動排列問題(此項已申請專利)
tiny解決了業務單元熱部署的難題
tiny解決了業務對象自動建構
tiny解決了還有許多的技術難題
是以，我要說的是，我們和一般的二貨還是有差别的。
<a href="http://www.tinygroup.org/" target="_blank">tiny官網</a>
<a href="https://git.oschina.net/tinyframework/" target="_blank">tiny源碼git倉庫</a>
<a href="http://www.tinygroup.org/tinyadmin/" target="_blank">tinyadmin線上示範網站</a>
<a href="https://git.oschina.net/tinyframework/tiny/issues" target="_blank">issue填寫</a>
當然，也可以看看下面的快速入門文檔，了解一下tiny的開發模式。
<a href="http://pan.baidu.com/s/1bnd5ekf" target="_blank">tiny快速入門手冊</a>
tiny架構目前的版本号是1.2.0-snapshot,現在正式對外開放，tiny社群正在建構當中，将于近日開放。
經過社群驗證一段時間之後，将正式釋出tiny2.0。
親，你還在等什麼？
![Bugku-WEB-web33[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)