Web架構特性及REST架構風格（部分內(nèi)容摘自網(wǎng)絡）

良好的Web架構風格：
    1. 客戶/服務器模式：  實現(xiàn)了UI與數(shù)據(jù)的分離。
    2. 服務端無狀態(tài)性：　可見性，可靠性，可伸縮性等方面的改善。
    　可見性－無狀態(tài)性使得服務器不必要維護海量的上下文（Ｃontext）。
    　可靠性－無狀態(tài)性減少了服務器從局部錯誤中恢復的任務量。
    　可伸縮性－無狀態(tài)性使得服務器可以很容易的釋放資源。
    3. 緩存：　減少服務端不必要的處理。
    4. 可伸縮性：　便于分布式和集群部署。
    　上面的2，3點也是影響4的主要因素。而隨著系統(tǒng)用戶規(guī)模的指數(shù)上升，可伸縮性將變的至關重要。

現(xiàn)在大多數(shù)應用程序都忽略或者違反了上述2, 3的風格。當然也肯定失去了４帶來的好處。
比如Java Servlet中HttpSession的應用，使服務器端保存了客戶端的狀態(tài)。
時下流行的動態(tài)頁面的做法也使得資源緩存變得困難或者不可能。
這些都直接影響了應用的可伸縮性。

改善現(xiàn)狀的思路是，把服務端的處理和狀態(tài)前移，由客戶端來實現(xiàn)。使服務端回歸到無狀態(tài)的特性。
以采用ajax技術的應用系統(tǒng)為例：因為不需要完全刷新就可以與服務器進行交互，使得有狀態(tài)客戶機成為可用選擇?；跒g覽器的應用程序代碼可以在必要時獲取新的服務器數(shù)據(jù)，并把這些數(shù)據(jù)織入當前頁面。
將處理和狀態(tài)前移到每個客戶機上后，實現(xiàn)了無狀態(tài)的服務端；同時緩存服務器可以緩存ajax引擎(比如dojo, prototype etc.)，以及狀態(tài)無關的數(shù)據(jù)。
個人理解，多種瀏覽器的plug-in技術（Sun的applet, MS的ActiveX等等），都應該是這種思路的不同技術實現(xiàn)。

經(jīng)過以上分析整理，實際上已經(jīng)涉及到了時下流行的一個概念－REST.

REST（Representational State Transfer）來源于Dr. Roy Thomas Fielding,  <Architectural Styles and the Design of Network-based Software Architectures>
當瀏覽器瀏覽訪問一個url資源時，返回的頁面即為該url資源的representation，這個representation給瀏覽器一個state，當
瀏覽器訪問下一個url資源時，瀏覽器的state就transfer了。
REST其本身只是為分布式超媒體系統(tǒng)(distributed hypermedia systems)設計的一種架構風格，而不是某個標準，框架。

REST的設計準則
    1.網(wǎng)絡上的所有事物都被抽象為資源（resource）；
    2.每個資源對應一個唯一的資源標識符（resource identifier）；
    3.通過通用的連接器接口（generic connector interface）對資源進行操作；
    4.對資源的各種操作不會改變資源標識符；
    5.所有的操作都是無狀態(tài)的（stateless）。

REST中的資源所指的不是數(shù)據(jù)，而是數(shù)據(jù)和表現(xiàn)形式的組合。
REST是基于Http協(xié)議的，任何對資源的操作行為都是通過Http協(xié)議來實現(xiàn)。以往的Web開發(fā)大多數(shù)用的都是Http協(xié)議中的GET和POST方法，對其他方法很少使用，這實際上是因為對Http協(xié)議認識片面的理解造成的。Http不僅僅是一個簡單的運載數(shù)據(jù)的協(xié)議，而是一個具有豐富內(nèi)涵的網(wǎng)絡軟件的協(xié)議。他不僅僅能對互聯(lián)網(wǎng)資源進行唯一定位，而且還能告訴我們?nèi)绾螌υ撡Y源進行操作。Http把對一個資源的操作限制在4個方法以內(nèi)：GET, POST,PUT和DELETE，這正是對資源CRUD操作的實現(xiàn)。由于資源和URI是一一對應的，執(zhí)行這些操作的時候URI是沒有變化的，這和以往的 Web開發(fā)有很大的區(qū)別。正由于這一點，極大的簡化了Web開發(fā)，也使得URI可以被設計成更為直觀的反映資源的結(jié)構，這種URI的設計被稱作 RESTful的URI。這位開發(fā)人員引入了一種新的思維方式：通過URL來設計系統(tǒng)結(jié)構。當然了，這種設計方式對一些特定情況也是不適用的，也就是說不是所有的URI都可以RESTful的。
REST 之所以可以提高系統(tǒng)的可伸縮性，就是因為它要求所有的操作都是無狀態(tài)的。由于沒有了上下文(Context)的約束，做分布式和集群的時候就更為簡單，也可以讓系統(tǒng)更為有效的利用緩沖池(Pool）。并且由于服務器端不需要記錄客戶端的一系列訪問，也減少了服務器端的性能。

       Java語言編程中更新XML文檔的四種方法。第一種方法是直接讀寫XML文件。第二種方法是使用Apache Crimson的XmlDocument類,這種方法極為簡單,使用方便,如果你選用Apache Crimson作為XML解析器,那么不妨使用這種方法,不過這種方法似乎效率不高(源于效率低下的Apache Crimson),另外,高版本的JAXP或者是Java XML Pack、JWSDP不直接支持Apache Crimson,亦即這種方法不通用。第三種方法是使用JAXP的XSLT引擎(Transformer類)來輸出XML文檔,這種方法也許是標準的方法 了,使用起來十分靈活,特別是可以自如控制輸出格式,我們推薦采用這種方法。第四種方法是第三種方法的變種,采用了Xalan XML Serializer,引入了串行化操作,對于大量文檔的修改/輸出有優(yōu)越性,可惜的是要重復設置XSLT引擎的屬性和XML Serializer的輸出屬性,比較麻煩,而且依賴于Apache Xalan和Apache Xerces技術,通用性略顯不足。除此之外，實際上應用別的API(比如dom4j、JDOM、Castor、XML4J、Oracle XML Parser V2)也有很多辦法可以更新XML文檔。

概念介紹
        Xerces/Crimson是XML解析器，Xalan是XSLT處理器，xml-apis.jar實際上是JAXP。
        Apache Crimson的前身是Sun Project X Parser, 至今Apache Crimson的很多代碼都是從X Parser中直接移植過來的。早期的JAXP是和X Parser捆綁在一起的。后來的 JAXP和Apache Crimson捆綁在一起,比如JAXP 1.1。最新的JAXP 1.2 EA(Early Access)改弦更張,采用性能更好的Apache Xalan和Apache Xerces分別作為XSLT處理器和XML解析器,不能直接支持Apache Crimson了。
        dom4j(dom4j.jar)是一個Java的XML API，類似于jdom，用來讀寫XML文件的。dom4j是一個非常非常優(yōu)秀的Java XML API，具有性能優(yōu)異、功能強大和極端易用使用的特點，同時它也是一個開放源代碼的軟件，可以在SourceForge上找到它。在IBM developerWorks上面可以找到一篇文章，對主流的Java XML API進行的性能、功能和易用性的評測，dom4j無論在那個方面都是非常出色的。

.NET垃圾收集器的過去、現(xiàn)在和未來（一）

Patrick Dussud介紹：
Patrick Dussud在微軟工作了11年，曾經(jīng)負責VBA、Jscript、MS Java等語言運行時的垃圾收集器（Garbage Collector）的設計，目前負責.NET CLR垃圾收集器的設計。他是.NET CLR的架構師，WinFX的首席架構師，Windows架構師組的成員。
在微軟之前，Patrick是德州儀器（TI）Explorer工作站系統(tǒng)的主要設計人，Lucid公司Energize產(chǎn)品的首席架構師。

關鍵內(nèi)容摘要

1. 微管理 / 內(nèi)存的顯式管理 ---  手動內(nèi)存管理（new/delete）
        你必須保證在釋放之前內(nèi)存沒有被別人使用，如果你把內(nèi)存給了別人，往往你就不確定應該何時釋放內(nèi)存了。當你釋放了內(nèi)存，不知道別人正在使用這塊內(nèi)存時，就產(chǎn)生了程序崩潰的問題。所以，當你顯式進行“new”和“delete”時，內(nèi)存管理是一個復雜的問題，并且，此時你的代碼不可組合。要么你必須確定對自己的內(nèi)存有完全的控制，因此，要達到這種完全隔離的目的，你必須在將內(nèi)存?zhèn)鬟f給別的模塊時進行完全拷貝，這樣，別的模塊就只對這個完全拷貝的內(nèi)存負責。要么你就得在某個地方形成對整個內(nèi)存池的統(tǒng)一的管理，這就是自動化內(nèi)存管理，這就是垃圾收集器的工作。

2. 對象終止器的調(diào)用時機由垃圾收集器決定，這些對象的析構函數(shù)被調(diào)用的先后順序是無法預先確定的。提出了“關鍵終止化對象”的概念。當有一系列對象需要終止化時，關鍵終止化對象最后被終止化，直到上層對象干完工作前。

3.  工作機理： 垃圾收集器首先遍歷所有的棧和靜態(tài)變量，然后返回最初的樹集。然后遍歷樹集對程序能夠到達的每一個對象作標記。此時，我們就能逐個對象地檢查內(nèi)存，發(fā)現(xiàn)它被標記了，好的，留下。沒有被標記？喔，我們有一個垃圾了。

4.  垃圾收集器的絕大部分速度和效率都來源于對回收策略的調(diào)整。通過保持內(nèi)存緊湊，形成緩存本地化，頁面本地化等等優(yōu)勢，很可能其效率甚至高于傳統(tǒng)“new”和“delete” 操作，尤其是對于非常難以管理的服務器內(nèi)存來說更是如此。

如下代碼：
class A{
    public void foo(){print（"aaaaa"）;}
}

class B extends A{
    public void foo(){print("bbbbb");}
}

如果想通過B的實例化變量來調(diào)用被override的父類的方法foo（）：

B b = new B();

在C++中（VC 6）可以兩種途徑；
1.  (（A）b).foo();
2.  A a = B();

在java中類似做法則行不通，依然訪問的是子類方法。
而且，在java中好像達不到這個目的。

web常用的功能性測試方法

發(fā)布時間: 2007-9-20 12:13    作者: 未知    來源: 網(wǎng)絡轉(zhuǎn)載

      
        1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，并且頁面之間切換正確。

        2. 相關性檢查：刪除/增加一項會不會對其他項產(chǎn)生影響，如果產(chǎn)生影響，這些影響是否都正確。

        3. 檢查按鈕的功能是否正確：如update、cancel、delete、save等功能是否正確。

        4. 字符串長度檢查：輸入超出需求所說明的字符串長度的內(nèi)容，看系統(tǒng)是否檢查字符串長度，會不會出錯。

        5. 字符類型檢查：在應該輸入指定類型的內(nèi)容的地方輸入其他類型的內(nèi)容(如在應該輸入整型的地方輸入其他字符類型)，看系統(tǒng)是否檢查字符類型，會否報錯。

        6. 標點符號檢查：輸入內(nèi)容包括各種標點符號，特別是空格、各種引號、回車鍵。看系統(tǒng)處理是否正確。

        7. 中文字符處理：在可以輸入中文的系統(tǒng)輸入中文，看會否出現(xiàn)亂碼或出錯。

        8. 檢查帶出信息的完整性：在查看信息和update信息時，查看所填寫的信息是不是全部帶出，帶出信息和添加的是否一致。

        9. 信息重復：在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統(tǒng)有沒有處理，會否報錯，重名包括是否區(qū)分大小寫，以及在輸入內(nèi)容的前后輸入空格，系統(tǒng)是否作出正確處理。

        10. 檢查刪除功能：在一些可以一次刪除多個信息的地方，不選擇任何信息，按”delete”，看系統(tǒng)如何處理，會否出錯;然后選擇一個和多個信息，進行刪除，看是否正確處理。

        11. 檢查添加和修改是否一致：檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規(guī)定為整型的項，修改也必須為整型。

        12. 檢查修改重名：修改時把不能重名的項改為已存在的內(nèi)容，看會否處理，報錯。同時，也要注意，會不會報和自己重名的錯。

        13. 重復提交表單：一條已經(jīng)成功提交的紀錄，back后再提交，看看系統(tǒng)是否做了處理。

        14. 檢查多次使用back鍵的情況：在有back的地方，back，回到原來頁面，再back，重復多次，看會否出錯。

        15. search檢查：在有search功能的地方輸入系統(tǒng)存在和不存在的內(nèi)容，看search結(jié)果是否正確。如果可以輸入多個search條件，可以同時添加合理和不合理的條件，看系統(tǒng)處理是否正確。

        16. 輸入信息位置：注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。

        17. 上傳下載文件檢查：上傳下載文件的功能是否實現(xiàn)，上傳文件是否能打開。對上傳文件的格式有何規(guī)定，系統(tǒng)是否有解釋信息，并檢查系統(tǒng)是否能夠做到。

        18. 必填項檢查：應該填寫的項沒有填寫時系統(tǒng)是否都做了處理，對必填項是否有提示信息，如在必填項前加* 

        19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不允許輸入信息的字段，如選人，選日期對快捷方式是否也做了限制。

        20. 回車鍵檢查：在輸入結(jié)束后直接按回車鍵，看系統(tǒng)處理如何，會否報錯。

調(diào)整完/usr的掛載點后，出現(xiàn)了一個奇怪的現(xiàn)象，原來正確的系統(tǒng)時鐘現(xiàn)在出故障了，提前了8個小時。
鼓掌現(xiàn)象具體表現(xiàn)為：每次啟動系統(tǒng)，ubuntu會用BIOS的時間＋8后作為系統(tǒng)時鐘，同時會把新的時間重新同步到BIOS中。所以每啟動一次，時間就會快進8小時。很是怪異。
網(wǎng)上一通google才搞定。

原因是因為/usr的掛載時間被滯后了，由于/etc/localtime（時區(qū)信息）是連接到/usr/share/zoneinfo/下的某個設定好的時區(qū)文件。在系統(tǒng)獲取時區(qū)信息時/usr尚未掛載，所以系統(tǒng)始終就錯了。

修復辦法很簡單:
1.  rm /etc/localtime(取消原來的符號連接)
2. 把/usr/share/zoneinfo/下的某個設定好的時區(qū)文件copy到/etc/localtime.
3. 重新啟動，故障消除。

相關概念：
UTC（Universal Time Coordinated)  = GMT  (Greenwich Mean Time)
hwclock :   query and set the hardware clock (RTC)
hwclock通過/etc/default/rcS的UTC（＝y(tǒng)es/no）來認定BIOS時鐘是UTC還是localtime。

參考文章：
http://blog.chinaz.com/u1/5830/archives/2006/36628.shtml

昨天由于ubuntu的/分區(qū)空間緊張，決定把/usr掛載到別的分區(qū)。
掛載步驟(root權限執(zhí)行)：
1.   init  1  －－ 切換到單用戶模式。
2.   cp -ax /usr/*  /mnt/tmp  (tmp為新的/usr分區(qū))。 －－ 拷貝現(xiàn)在/usr下的內(nèi)容到待切換的分區(qū)。
3.   ls -l /dev/disk/by-uuid    －－ 查看分區(qū)的UUID。
4.   修改/etc/fstab中/usr的掛載方式，掛接到新的/usr分區(qū)。
5.   mv /usr /usr.old   －－ 重命名現(xiàn)有的/usr為/usr.old, 為第6步做準備，重啟動后可以刪除之。
6.   mkdir /usr   －－ 創(chuàng)建新的/usr掛載點，啟動時自動掛載/usr分區(qū)到此處。
7.   restart

/home 分區(qū)是最常移動的分區(qū)之一。某些時候，/home 中的全部空間都用完了，而且需要增加一個硬盤驅(qū)動器。另一些時候，/home 被設置為根分區(qū)的一部分，為了提高性能或便于備份，可能需要將它移動到別的地方。我會針對每種情況說明如何安全有效地移動 /home。

please visit the address:
http://www.ibm.com/developerworks/cn/linux/l-tip-prompt/tip05/index.html

網(wǎng)上常見的推薦是tora. 地址: http://sourceforge.net/projects/tora/
但由于License關系，二進制版本剔除了對oracle的providor. 所以需要下載源碼自己編譯。
感覺比較麻煩。

最近又找到一個比較好的東東－－ Aqua Data Studio。 (http://www.aquafold.com/index.html)
而且也有免費版本。
下載試用了一下，非常方便易用。
推薦給有此需要者。

如何臨時增加交換空間。

1.產(chǎn)生一個64M的空文件

#dd if=/dev/zero of=/swapfile bs=1024 count=65536

2.初始化該文件為交換文件：

mkswap /swapfile 65536

sync

3.激活這個交換文件：

swapon /swapfile