12 2009 檔案
【原】RSS工具開發(fā)手記(12)---Informa的parsers包
摘要: 可以看到，對于這個解析過程，一般的步驟就是：
A.獲取channnel下的某個子節(jié)點元素
B.如果該子節(jié)點元素有子元素或屬性，則繼續(xù)遞歸訪問
C.調用該channnel子元素的createXxx方法加載或創(chuàng)建該子元素
D.調用Channel的setXxx方法添加該子元素到channel實例中
閱讀全文
posted @
2009-12-30 10:45 Paul Lin 閱讀(252) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(11)---Informa的parse包
摘要: FeedParser是一個facade類，這個類的工作就是根據(jù)讀入的RSS Feed的協(xié)議系和版本“委托(delegate)”給已經(jīng)硬編碼的規(guī)則(concrete rules)指定的解析器，而且這些解析器是私有的。這意味著：用戶不能直接調用一個RSS_0_91_Parser類的實例來進行解析工作。
閱讀全文
posted @
2009-12-29 15:56 Paul Lin 閱讀(1488) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(10)---Informa的impl.hibernate包
摘要: ChannelBuilder對channel object的創(chuàng)建原則就是：
A.如果能夠從持久層中找到對應的記錄，那么從持久層返回
B.如果找不到，則創(chuàng)建它并持久化它，然后返回該對象(已持久化)
只要記得的一點就是：從ChannelBuilder返回的對象都是已經(jīng)持久化的。
閱讀全文
posted @
2009-12-28 15:57 Paul Lin 閱讀(1240) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(09)---Informa的impl.hibernate包
摘要: 經(jīng)過和impl.basic包中Channel的比較，發(fā)現(xiàn)兩者的實現(xiàn)有如下的不同：
A.構造方法中多了3個方法，其中兩個是使用title和location來構造的，最后一個是使用Element，title，location來構造的
B.從Hibernate中檢索出來的是不用設置ID的，而從內(nèi)存中生成的必須使用IdGenerator產(chǎn)生唯一ID
C.basic實現(xiàn)中沒有getLocationString方法和setLocationString方法
D.basic實現(xiàn)中沒有getSiteString方法和setSiteString方法
E.basic實現(xiàn)中沒有getGroup方法和setGroup方法
F.basic實現(xiàn)中沒有getFormatString和setFormatString方法
G.basic中沒有setItems方法，而且getItems方法中的實現(xiàn)不同(basic采用了同步的hashset，而hibernate沒有)
H.basic中的addItem方法是添加到hashmap，而hib
閱讀全文
posted @
2009-12-28 10:51 Paul Lin 閱讀(233) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(08)---Informa的build.xml
摘要: 其中dbscheme是關鍵，它的主要工作包括：
A.創(chuàng)建用于保存DDL輸出結果的scripts目錄
B.定義一個名為schemaexport的Ant task，用于把hbm文件導出為ddl文件
C.執(zhí)行schemaexport任務，把classes目錄下的hbm文件export成DDL，并輸出到指定的位置
D.輸出執(zhí)行結果信息
閱讀全文
posted @
2009-12-23 10:45 Paul Lin 閱讀(1343) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(07)---Informa的impl.basic包
摘要: 這個ID生成類采用了系統(tǒng)當前時間作為隨即數(shù)產(chǎn)生的種子，這個并不難理解。但是有一個地方需要我們注意的就是關鍵字transient的使用。這個關鍵的作用是告訴編譯器假設該類的對象被序列化了，這個值不需要被保存。因為它是“瞬時”的。
閱讀全文
posted @
2009-12-23 00:03 Paul Lin 閱讀(1338) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(06)---Informa的impl.basic包
摘要: 在ChannelBuilder下有幾種類型的方法：
★構造方法和初始化方法：即創(chuàng)建Channel對象的方法及初始化的方法
★元素構建方法：即構建Channel子元素的方法
★事務控制方法：即控制構建，析構過程的方法
閱讀全文
posted @
2009-12-22 23:52 Paul Lin 閱讀(1271) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(05)---Informa的impl.basic包
摘要: 總結起來，channel的創(chuàng)建，更新過程如下：
①接收經(jīng)過ChannelParser解析后的XML Element元素，和其他一系列屬性，調用構造方法
②構造方法為channel生成一個全局唯一ID
③構造方法創(chuàng)建item列表，觀察者列表，設置好分類(Category)，首次更新時間
④如果有新item到來，則添加到item列表，同時更新item的channel歸屬
⑤如果現(xiàn)有channel更新，則設置最新更新時間
⑥通知每一個已注冊的觀察者有事件發(fā)生
閱讀全文
posted @
2009-12-22 23:31 Paul Lin 閱讀(1257) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(04)---Informa的core包
摘要: Informa的core包介紹如下：
“This package contains interfaces for the news channel objects, it builds the core API for all news channel storage implementation. ”
從上面這句話來看，core包里面定義的都是關于“news channel objects”的接口---實際上就是RSS協(xié)議中的channel和item元素。經(jīng)過一個多小時查看源代碼和閱讀API，發(fā)現(xiàn)Informa對core包的設計有如下特點：
core包中的元素被分為標記接口、實體接口、行為接口
閱讀全文
posted @
2009-12-21 22:09 Paul Lin 閱讀(1246) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(03)---初始Informa
摘要: Informa的API結構如下：
★core包：
核心包。訂閱了RSS中channel,item等一系列元素和元數(shù)據(jù)的接口
★impl.basic包：
基本功能包。使用in-memory模式實現(xiàn)了core包訂閱的接口
★impl.hibernate包：
基于hibernate實現(xiàn)的包，使用關系型數(shù)據(jù)庫模式實現(xiàn)了core包定義的接口
★parsers包：
定義了永遠解析channel,item的解析器工具
★exporters包：
定義了一組把channel,item導出成各種協(xié)議格式的工具
★search包：
定義了用于全文搜索channel,item的工具
★utils.manager.memory包：
定義了一組用于管理“in-memory”模式持久化的工具
★utils.manager.hibernate包：
閱讀全文
posted @
2009-12-21 15:39 Paul Lin 閱讀(1259) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(02)---工欲善其事，必先利其器
摘要: 選擇一個開源框架，我的標準有幾條：
★良好的文檔和源代碼管理：這是最基本的一條，想RSSLibJ這種連文檔、官網(wǎng)都沒有的一律pass掉
★持續(xù)的改進：這是第二個重要的，像上面某些工具從02年后就不再更新了，出了問題你找誰訴苦去
★簡單和易上手：在短時間內(nèi)可以迅速依樣畫葫蘆
★活躍的社區(qū)：參與的人越多軟件成長得越多。我不是特別在乎軟件目前的使用率，因為好的軟件都是慢慢出名的
閱讀全文
posted @
2009-12-21 11:52 Paul Lin 閱讀(1362) |
評論 (0) 編輯
【原】RSS工具開發(fā)手記(01)---Kick off
摘要: ◆軟件必須適應不同的終端，不同的訪問方式，不同版本的協(xié)議。對設計通用性要求較高
◆軟件必須解析和生成XML，涉及到大量的字符串和格式處理。對XML和性能要求較高
◆軟件必須具備實時監(jiān)控功能，且具備主動推送功能，對多線程和異步通訊要求較高
◆軟件必須支持不同的持久化方式，對緩存和持久化要求較高
◆軟件必須支持基于全文的搜索，對搜索技術有一定要求
◆軟件界面必須是支持拖拽功能的，對GUI和Ajax有一定要求
閱讀全文
posted @
2009-12-18 12:14 Paul Lin 閱讀(310) |
評論 (0) 編輯
【原】SVN In Action系列發(fā)布
摘要: SVN是一個開放的、免費的版本控制管理工具，相比CVS，Perforce等其他工具，SVN在版本模型，鎖定策略方面要更加靈活高效。下面就讓我們開始一步一步地學習如何使用SVN，如何把版本控制融入到日常工作中，更重要的是在學習版本控制的過程中樹立起團隊合作的理念。
關于SVN的參考資料，最好的莫過于其官方文檔《Version Control with Subversion》，作為新手一定要看的是里面的第一章《Fundamental Concepts》和第二章《Basic Usage》以及第九章《Subversion Complete Reference》。
為了做到真正的In Action，我采用了Step-by-Step的方式，模擬一個項目從檢出項目開始，到修改本地副本，再到提交變更，解決沖突等一系列的實際工作中會遇到的場景，期望通過這些場景和任務來對SVN和版本控制、團隊合作有一個基本的認識
閱讀全文
posted @
2009-12-13 12:29 Paul Lin 閱讀(3469) |
評論 (5) 編輯
【原】SVN In Action(23)
摘要: SVN日常操作基本命令總結
1. 導入/導出資源：svn import、svn checkout
2. 更新工作副本： svn update
3. 添加變化：svn add、svn delete、svn copy、svn move
4. 檢查變化：svn status、svn diff
5. 撤銷變化：svn revert
6. 解決沖突：svn resolved
7. 提交變更：svn commit
閱讀全文
posted @
2009-12-11 18:23 Paul Lin 閱讀(444) |
評論 (0) 編輯
【原】SVN In Action(22)
摘要: 這時就需要用到SVN提供的清理功能了。清理功能是通過svn cleanup 命令來完成的。當執(zhí)行這個命令時，SVN會首先完成log文件中沒有完成的剩余工作，釋放鎖定，最后刪除log文件。通常我們都是在項目的根目錄來執(zhí)行這個命令
閱讀全文
posted @
2009-12-11 18:19 Paul Lin 閱讀(353) |
評論 (0) 編輯
【原】SVN In Action(21)
摘要: 什么時候是Branch？什么時候是Tag？原則如下：
如果你還需要繼續(xù)向目錄提交變更，它就是個分支。如果一旦拷貝后不再提交任何改變哪就是標記。實際上SVN不會強制你不能對名為***tag的目錄進行commit操作，這只是通常上約定。即便因為誤操作我們也可以輕易的使用update操作回滾到當初創(chuàng)建Tag時的快照版本
閱讀全文
posted @
2009-12-11 17:39 Paul Lin 閱讀(364) |
評論 (0) 編輯
【原】SVN In Action(18)
摘要: svn merge的命令用法有三種：
A.svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
B.svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
C.svn merge[[-c M]...|[-r N:M]...] [SOURCE[@REV][WCPATH]]
Step 1:確定要從哪個版本開始~那個版本結束
Step 2: 執(zhí)行集成
Step 3: 提交集成結果
閱讀全文
posted @
2009-12-11 12:02 Paul Lin 閱讀(455) |
評論 (2) 編輯
【原】SVN In Action(17)
摘要: svn switch [--relocate] URL。該命令有兩種用法：一種是不使用參數(shù)relocate的，一種是使用relocate參數(shù)的。它們的使用原則如下：
A.如果切換后的版本庫路徑還是在同一個版本庫，只是在不同的路徑下。那么使用svn switch URL
B.如果切換后的版本庫位置已經(jīng)改變(主機遷移，版本庫遷移)，但是目錄結構不變。就需要加relocate參數(shù)
閱讀全文
posted @
2009-12-10 19:02 Paul Lin 閱讀(396) |
評論 (0) 編輯
【原】SVN In Action(16)
摘要: 我們看到“創(chuàng)建分支”居然和普通的拷貝動作一摸一樣！是的對SVN來說，主干、分支、標記都是普通的目錄而已，這些都是人為加上的意義。
閱讀全文
posted @
2009-12-10 17:04 Paul Lin 閱讀(398) |
評論 (0) 編輯
【原】SVN In Action(15)
摘要: SVN提供了幾種解決沖突的建議：
A.(p) postone 延遲解決
B.(df) diff-full 顯示所有沖突的內(nèi)容
C.(e) edit 啟動編輯器解決沖突
D.(r) resolve 標識沖突已經(jīng)解決
E.(mf) mine-full 用我的版本覆蓋他人的修改
F.(tf) theirs-full 用他人的版本覆蓋我的修改
G.(l) lanuch 啟動其他工具來解決沖突
H.(h) help 啟動幫助信息
雖然SVN提供了比較差異和解決沖突的方法，但避免沖突的最好方法永遠只有一個：明確的分工和良好的溝通，盡量避免多個人同時修改同一份文件。如果不能避免，那么最好指定一個人在提交前負責合并各人的更新，然后一次性提交。
閱讀全文
posted @
2009-12-09 23:25 Paul Lin 閱讀(593) |
評論 (0) 編輯
【原】SVN In Action(14)
摘要: ●使用svn update -r 命令
●使用svn copy命令
●使用svn cat命令配合重定向
閱讀全文
posted @
2009-12-09 17:19 Paul Lin 閱讀(426) |
評論 (0) 編輯
【原】SVN In Action(13)
摘要: 默認情況下如果svn log不加任何參數(shù)，會顯示當前目錄下所有資源的變更歷史，我們可以通過PATH，URL來限定顯示范圍，還可以通過URL PATH來顯示某個URL下的某個(些)文件的變更歷史，甚至還可以指定版本號，版本范圍。
各種svn log的用法看似復雜，實際上離不開兩樣東西：
A.資源路徑：本地路徑(PATH)或遠程路徑(URL/URL PATH)
B.版本號或版本范圍：-r 18:HEAD或者@19
閱讀全文
posted @
2009-12-09 16:01 Paul Lin 閱讀(306) |
評論 (0) 編輯
【原】SVN In Action(12)
摘要: A.因為SVN為了保護用戶不小心update操作而覆蓋自己本地的修改，不會對已經(jīng)被修改但尚未提交的資源進行update操作。像這種情況下只能用svn revert而不能用svn update。
B.和svn update不會對已修改而尚未提交的資源進行update之外，svn del同樣不會刪除已修改但尚未提交的資源---除非你強制加上--force參數(shù)。
C.不要把所有變更都放在最后一次性提交，提交要及時、多次。否則一旦回滾所有其他修改都會跟著撤銷。
閱讀全文
posted @
2009-12-09 11:19 Paul Lin 閱讀(554) |
評論 (0) 編輯
【原】SVN In Action(10)
摘要: 實際上svn revert命令是一把“雙刃劍”。它有幾個需要特別小心的地方：
A.回滾是不可恢復的。由于svn revert回滾的是任何未提交的操作，內(nèi)容，屬性。所以意味著SVN不會為你保存任何回滾前的歷史版本
B.回滾是不止于一點而是一段時間的。只要你沒有提交版本，那么不論你多久之前所做的修改都會被回滾，而不僅僅是最近一次的修改
閱讀全文
posted @
2009-12-09 09:47 Paul Lin 閱讀(746) |
評論 (0) 編輯
【原】SVN In Action(9)
摘要: show-updates參數(shù)會令客戶端顯示本地工作副本那些文件是out-of-date的。它并不會立即更新本地副本，而是告訴你那些文件會在下次的svn update中被更新
閱讀全文
posted @
2009-12-08 21:50 Paul Lin 閱讀(340) |
評論 (0) 編輯
【原】SVN In Action(8)
摘要: A. svn cat 命令是客戶端命令，在客戶端運行。而svnlook cat 命令是服務器端命令，只能在版本庫所在的機器上運行
B. svn cat 命令可以查看本地工作副本(PATH)或版本庫(URL)資源的內(nèi)容，而svnlook cat 命令只能使用REPOS_PATH PATH_IN_REPOS形式
閱讀全文
posted @
2009-12-08 17:04 Paul Lin 閱讀(471) |
評論 (0) 編輯
【原】SVN In Action(7)
摘要: 整個目錄的忽略
Step 1: 把目錄export到其它目錄下
Step 2: 把版本庫上的對于目錄刪除并同步到本地
Step 3: 把原有目錄添加回原來的位置下，并加入SVN ignore列表
Step 4: 檢查忽略是否生效
閱讀全文
posted @
2009-12-08 16:29 Paul Lin 閱讀(501) |
評論 (0) 編輯
【原】SVN In Action(6)
摘要: 一次性忽略多個文件：
Step 1: 在本地任意目錄下創(chuàng)建一個文件，名字假設為ignore.txt
Step 2: 編輯該文件，添加想要忽略的文件名列表
Step 3: 通過文件一次忽略多個條目
Step 4: 提交變更
Step 5: 檢查忽略是否生效
閱讀全文
posted @
2009-12-08 16:15 Paul Lin 閱讀(543) |
評論 (0) 編輯
【原】SVN In Action(5)
摘要: 單個文件的忽略：
Step 1: 把文件備份到其他位置
Step 2: 把版本庫對應的文件刪除
Step 3: 從版本庫更新到本地工作副本
Step 4: 把文件拷貝回原有位置
Step 5: 把文件添加到SVN的全局屬性svn:ignore
Step 6: 提交屬性變更
閱讀全文
posted @
2009-12-08 14:51 Paul Lin 閱讀(364) |
評論 (0) 編輯
【原】SVN In Action(4)
摘要: 關于svn add命令我們有2個需要注意的地方：
A.和svn status命令一樣，svn add命令只能使用PATH，而不能使用URL作為參數(shù)
B.當svn add命令執(zhí)行完畢后，相關資源并不會馬上立即被加入版本控制中，需要再執(zhí)行一次commit
我們需要在每次commit后立即update，已保證我們最新代碼被上傳到版本庫的同時，他人的最新代碼能夠被及時更新到本地
閱讀全文
posted @
2009-12-08 11:09 Paul Lin 閱讀(358) |
評論 (0) 編輯
【原】SVN In Action(3)
摘要: 使用svn info命令可以查看項目版本控制的靜態(tài)信息
使用svn status命令可以查看項目版本控制的實時變更信息
閱讀全文
posted @
2009-12-08 10:09 Paul Lin 閱讀(447) |
評論 (0) 編輯
【原】SVN In Action(2)
摘要: 把項目import到版本庫之后，項目并不會立即就被加入到版本控制中，還需要再從版本庫中check out到本地原有位置才是真正地吧項目加入到版本控制。這一點和TCP/IP協(xié)議的三次握手過程類似。必須確保雙方都知道對方的存在和聯(lián)系。
閱讀全文
posted @
2009-12-07 16:37 Paul Lin 閱讀(414) |
評論 (0) 編輯
【原】SVN In Action (1)
摘要: 下面我們把svn list和svnlook tree命令的用法總結一下：
A.svn list PATH：列出PATH對應的版本庫路徑下的目錄內(nèi)容
B.svn list URL： 列出URL對應的路徑下的目錄內(nèi)容
C.svnlook tree REPOS_PATH：遞歸地列出REPOS_PATH對應的版本庫路徑下的目錄樹內(nèi)容
D.svnlook tree REPOS_PATH PATH_IN_REPOS： 遞歸地列出REPOS_PATH下子目錄PATH_IN_REPOS路徑下的目錄樹內(nèi)容
閱讀全文
posted @
2009-12-07 16:12 Paul Lin 閱讀(693) |
評論 (0) 編輯