Evan's Blog

最近一個項目需要考慮多語言的用戶，自然就想采用utf-8編碼，所有JSP頁面都修改完畢，一切運行正常，由于一直使用FF來檢測瀏覽器兼容性，今天不知怎的決定用IE來跑一下，發現所有表單提交的頁面都提示JS錯誤，查了一下，發現是一個驗證身份證的方法中有一個數組的初始化中保存了各個省市的名字，類似于：var area=['上海','北京']之類的形式。一般情況下，JS錯誤我都是在FF中用FireBug調試的，可偏偏在FF中一切正常，這下就傻眼了，注釋掉這個語句自然沒問題，可怎么也想不出這么正常的一個賦值怎么會弄出個瀏覽器兼容的問題出來。折騰了一個下午，突然想到，是不是編碼的問題啊，將這個JS用utf-8編碼另存，一切ok。

另外，采用utf-8編碼之后，用WinMerge比較文件時，就會出來Information lost to encoding errors:之類的提示，心想，這個指定個編碼就可以了吧。在編輯=>選項中，果然看到代碼頁的指定，如是選擇指定代碼頁，輸入utf-8，點擊確定，被提示請輸入一個整數，估計這時候大多數人和我一樣傻眼，utf-8的代碼頁是多少？好在有Google，調整不同的關鍵字，終于找到清炒苦瓜的一篇文章中提到utf-8的代碼頁是65001，并且也是為了解決WinMerge的亂碼問題，可是改完之后，并沒有起作用，這次沒有去懷疑這個代碼頁是不是正確，再仔細看一下那篇文章，嗯，人家明明說用的是2.6.8嘛，檢查一下自己的版本，2.6.0，是不是版本問題呢？來到WinMerge的網站，發現竟然已經是2.6.12了，于是下載最新版本，然后將代碼頁改成65001，嗯，這下所有的中文注釋都乖乖出來了。

     摘要: Apache反向代理設置  閱讀全文

     摘要: 這個Blog，就象我久未清理的書桌，已經落了厚厚的一層灰塵，在這個新年的第一天，決定用這樣一個夠噱頭的標題，以一篇夠水的日志，來告訴自己，已經是2008年了......  閱讀全文

     摘要: 不要假裝我們是一個文明古國了，傳統早已割裂，我們是個無根的民族，精神一片荒蕪，偽造出的傳統只加劇了我們的虛偽，凸顯了我們的空洞與脆弱。  閱讀全文

     摘要: 你是不是從svn 1.2甚至更早的版本就開始用Subversion了？是不是在用svnserve做服務器？是不是很認真的讀了svn自帶的文檔？那么，很有可能，你也象我一樣，被它小小的忽悠了一把:)。  閱讀全文

     摘要: 在網上兜到一篇文章，從講述一個譯者和一家出版社之間的糾紛，引申出了一些待人處世的道理，主要是關于一個人碰到不公平的事情的時候，應該怎樣辦，覺得頗有道理。什么樣的人才是有力量的人呢，也許是那些能合理處理不合理的事情，甚至能讓不合理的事情最終轉化為多贏局面的人吧。人生要真能達到這樣一種境界，該是怎樣一副海闊憑魚躍（管它波濤洶涌還是風平浪凈），天高任鳥飛（管它烏云閉日還是陽光普照）的從容畫面。  閱讀全文

好久沒有更新Blog了，看到還有人在關注這個Blog，很是慚愧。發現還是有人在使用Polarion的SVN Web Client，并且碰到了一些小問題，盡管我工作中幾乎不用這個客戶端，但當初安裝的版本依然還在，所以決定稍微研究一下，但愿能給喜好這款軟件的人一些幫助。

1. 為什么老是提示“Your credentials are not correct. Please check them and try again. ”？
這個多半是svn初學者常碰到的問題，尤其在使用HTTP協議的時候。一開始大家都用svnserve來做svn的服務器，自然配置的是conf中的passwd。但如果采用HTTP協議的話，就得使用Basci HTTP Authentication了，需要用Apache提供的htpasswd來管理用戶和口令。這個的配置在svn自帶的幫助文件中第6章“httpd, the Apache HTTP Server”一節中有比較詳細的解釋。但如果你沒有通篇看完，在Apache中沒有加上Require valid-user指令的話，那是允許匿名操作的。我想，你不愿意留下這樣的安全漏洞吧。

2. 怎樣配置多個repository
這個也是實際中需要的，當然，在它的readme中其實是說得很清楚的。但我們有些同志就是喜歡拿來就試，尤其是在有些類似于我這種其實語焉不詳的文章時，更是就喜歡照葫蘆畫瓢，而不去看最權威最原始的英文文檔了。要配置多個repository，以HTTP協議為例，在web.xml中要刪掉RepositoryUrl、Username、Password這3個參數的設置，然后加上ParentRepositoryDirectory參數，值自然是指向svn倉庫的父目錄了，比如http://localhost/svn/，這個東西又是哪里來的呢？自然需要在Apache中配置，用SVNParentPath來指定svn倉庫的父目錄，Apache會自動解析其下所有的倉庫的。這里要注意一下AuthzSVNAccessFile授權文件的寫法，這里將配置所有倉庫的存取權限，對于每個倉庫，需要用[倉庫名:/module]的方式來配置。

3. 怎樣使用svn協議
前面我一直用http協議做例子，實在是因為我在其2.5.0下沒有配置出來過svn協議:(。這次去其網站下載了個最新的nightly版本，發現其已經能夠支持http, svn, svn+ssh, ssl和proxy等6種協議了。看看其代碼結構，好象也發生了很大的變化，估計應該有比較大的改進。于是，用這個版本試了一把，呵呵，輕而易舉就把svn協議給連通了，包括多倉庫的情況。并且其還改進了原來設置父目錄地址時一定要在最后添加/的要求，估計原來在這個地方卡殼的朋友也不少吧:)。不過，新版本還是不支持中文文件名，看我以前的帖子自己改吧。

Important: 由于svn webclient采用的javasvn（現已更名為svnkit）版本較低，用svn協議在提交老的文件時會失敗，但添加新的文件時沒有問題，所以，大家就不要再嘗試svn協議了。如果不采用SVN協議，則其官方發布的版本就沒什么問題了，已經有網友重新打包了一個解決了中文文件名的版本，到這里下載。(Updated: 2007.1.20)

     摘要: 使用Jarkata FileUpload最新版本解決SVNWebClient提交中文文件名或注釋時出錯的問題。  閱讀全文

     摘要: 在我的“[推薦]兩款好用的SVN Web Client”一文中曾經提及我所看好的sventon中文支持不好的問題，于是在其論壇中提了個問題，今天收到他們的郵件，稱在其最新的代碼中已經解決了中文的問題，今天下載更新后，發現的確解決了這個問題，呵呵，更新速度挺快的。  閱讀全文

     摘要: 　　Everything is meaningless...假設你突然死掉，世界將會怎樣？世界將一樣絢麗，地球轉的一樣快，太陽系每天在宇宙中換一個位置。大海還是大海，波濤還是波濤，一樣的花開花落，潮起潮落。...你是多么可憐的小蟲子，在活著的短暫歲月里，在最美好的青春里，都不曾快樂過，用盡心力去聚集一大堆外在和心靈沒有關系的小東西，只是出于對未來的沒有信心，小小的心靈在接近熄滅的一天還在發出那個愚蠢的聲音，讓你忙碌，讓你憂慮的聲音：我要，我還要。天底下充滿了這樣的小蟲子，當一個離開了，又有一個來了，做著同樣的事情，洶涌著同樣的小小念頭，受著同樣的煎熬。于是上帝要感慨了：虛空的虛空，凡事都是虛空。已有的事，后必再有；已行的事，后必再行。日光之下，并無新事。
　　...
　　不要憂慮“不要為明天憂慮，天上的飛鳥，不耕種也不收獲，上天尚且要養活它，田野里的百合花，從不憂慮它能不能開花，是不是可以開得和其它一樣美，但是它就自然的開花了，開得比所羅門皇冠上的珍珠還美。你呢，憂慮什么呢？ 人比飛鳥和百合花貴重多了，上帝會棄你不顧嗎？”  閱讀全文

     摘要: 推薦兩款純Java的SVN Web Client軟件。其安裝使用均比ViewVC要好！  閱讀全文

     摘要: 前幾天好奇，也剛好得了點空閑，然后就想看看ViewVC對Subversion的支持程度，于是就想裝個玩玩。好死不死的，在我的VMWare Workstation上剛好有個Windows Server 2003，心想，就它吧，可就這么一偷懶，折騰了我好幾天，最終還是只能算將就著把它給裝上了。  閱讀全文

常常能從galeer(嘎荔兒)的網絡日志里聽到一些比較好聽的歌曲，并且那些點評也不錯。今天聽到U2 - With or Withou You，首先，這首歌還真不錯；其次，不知是這首歌原來就帶的呢，還是galeer自己加上了這樣幾句詩：

“我雖然行過死蔭的幽谷，
也不怕遭害；
因為你與我同在；
你的杖，你的竿，都安慰我。”
--《詩篇第二十三篇第四節》

當然，一開始我不知道這是《舊約全書·詩篇》中的內容，于是就Google了一把，找到下面這篇文章《因為你與我同在》：

“

我去一個鄉村教會講道，在接待的弟兄家休息。看見弟兄的兒子學習很用功，很是喜愛。我請小朋友將他的語文課本借給我看。這是人教版小學四年級語文課本。當中有一篇文章吸引了我——

1989 年美國洛杉磯大地震，30萬人在不到4分鐘時間里受到不同程度的傷害。這其間一個小學的慘況讓人心酸。多少孩子的父母因在地震中痛失愛子而哀聲聞天，面對 地震后的學校廢墟只能絕望離去。但一個父親卻在廢墟中不斷地挖掘尋找自己那才七歲的叫阿曼達的兒子。救火隊長擋住他，“太危險了，隨時可能發生大爆炸，請 你離開。”別的學生家長也勸說，“太晚了，沒有希望了。”可這位父親不顧這些勸阻，在廢墟中不斷地尋找。就在他挖了整整八個小時后，父親聽見瓦礫堆底下傳 出他十分熟悉的聲音，“爸爸，是你嗎？”這時他發現有14個孩子在當中，因為這是在教室墻角的位置，當房頂塌下時架成大三角形，孩子們才沒被砸著。“我告 訴同學們不要害怕，說只要我爸爸活著就一定會來救我，也能救大家。因為你說過，不論發生什么，你總會和我在一起！”孩子對爸爸說。“爸爸，先讓我的同學出 去吧，我知道你會跟我在一起，我不怕。不論發生了什么，我知道你總會跟我在一起。”

14個孩子獲救了！

我們不禁會問，如果因為大爆炸的危險而絕望地放棄，如果這個父親和其他的家長一樣絕望地離開，如果阿曼達沒有“因為你與我同在”的信念，那結果又將如何？

我想說的是，絕望讓生命失去，希望使生命存留。

詩人說，“因為你與我同在。”（詩篇23：3）這樣的信心使詩人在人生的黑夜里依然有生命的曙光，在人生的冬天里可憑信宣告說，冬天來了，上帝的春天也不再遙遠。

“因為我與你同在，要拯救你。這是耶和華說的。”（耶利米書1：8）

    阿曼達對父親單純的信念應一如我們對天上的父親執著的信仰。

”

是啊，“絕望讓生命失去，希望使生命存留”，不過呢，對于我這個不信教的人來說，大可抱著象故事中的小阿曼達相信他父親只要活著就一定會來救他的希望一樣，也不一定非要抱著耶和華會來救我們的希望的。不過，不管信什么教，基督也好，佛陀也好，其實所有經典中的智慧都是值得學習的；當然，如果你在這個浮躁的物質社會中實在找不到可以依賴的東西時，信個把教也未嘗不可。

     摘要: SVN會取代CVS嗎？這個雖然不是我們這種小程序員能決定的大事，但學學總無妨吧，這里有一些我搜集的資料。  閱讀全文

     摘要: 你是不是為了高的測試覆蓋度而在為每個函數添加多個測試方法，甚至連getX()和setX()都不放過呢？或者，你一看到覆蓋度達到100%的代碼，景仰之心就開始“有如滔滔江水綿綿不絕，又有如黃河泛濫，一發不可收拾”了呢？那么，你應該讀讀Andrew Glover在最近的developerWorks上發表的這篇文章。  閱讀全文

     摘要: 《Java Threads》的第5章“Minimal Synchronization Techniques”，是這本書中到現在我認為最差的一章了，當然主要是我不喜歡JDK 1.5新推出的Atomic Class，而這一章卻花了不少篇章來介紹，且牽強地改造打字程序，又語焉不詳地指出這種改造的困難之處和可能帶來的副作用，但卻又不能從代碼的實際運行中看到這種副作用，很有誤導初學者的嫌疑。不過，我想，沒有哪個初學者會冒風險為了用Atomic Class而將原本簡單明了的算法改造得如此晦澀難懂，并且還有潛在的出錯風險。所以，對于Atomic Class，我建議跳過不讀，絕對沒有什么損失。不過對于其中“5.1.3 Double-Checked Locking”和“5.3 Thread Local Variables”這兩節倒要著重讀一讀，尤其是Thread Local，應該說是Java中一個比較重要的多線程工具。  閱讀全文

     摘要: 快來看“洋本山”怎樣忽悠一個只想買一把錘子的人最后買了一個工具工廠的建造工廠的通用建造工廠。很別扭是吧，但如果你是個開發Web應用的Java程序員，你也許已經或者正在被忽悠。  閱讀全文

看到《Java Threads》第5章，介紹了JDK 1.5新加的一些所謂原子類(Atomic Classes)，總感覺有點為原子而原子，實際操作中，又有多少人會為了少許的性能提升而刻意去用這些別扭的操作而放棄直觀的synchronize關鍵字或者Lock類呢？不過，這里不是想討論這個，而是當其用Atomic Classes來改造它的打字程序后，解釋用原子類只是保證類似遞增、遞減、賦值等操作的原子性，而不能保證其所在的方法一定是線程安全的，然后說，有可能按鍵事件的處理可能需要等待resetScore()處理完才能執行，而這會導致錯誤的評分（被當成多敲了鍵）。由于前幾章的內容相對比較簡單易懂，所以也沒有很仔細的運行那些例子。這里為了驗證一下，就運行了一下第4章的例子，然后發現，基本上第一次的評分總是錯的。這就引起了我的注意，因為，一般情況下，如果是race condition導致的錯誤是很難重現的，這么明顯的錯誤很可能是程序邏輯上的錯誤。仔細看了一下代碼，發現在start按鈕的事件處理方法里，有下面這樣一段代碼：
注意重置成績的調用放在了最后，此時，隨機生成字符的線程應該被喚醒并產生了第一個字符，然后，resetScore()將需要輸入的字符又設成了-1，所以，當你第一次輸入字符時，總是被認為是多擊了一次鍵而扣1分:(。既然這樣，那停止然后再啟動也應該會發生這個錯誤啊。而事實上的確是這樣。我想，這不應該看做是race condition吧，有什么樣的同步技術能夠避免這個問題呢？除非另外弄個標志，當成績沒有被重置前，不能產生第一個字符。當然，這是不需要的，只要將score.resetScore()放到第一句就可以了。

然后又運行了第3章的例子，發現基本上沒有這個問題。難道第3章的代碼是正確的？打開源代碼一看，重置成績的方法還是放在最后，那這里為什么又是正確的呢？我想，大約是第3章的例子中，每次點擊start按鈕，都重新創建一個線程對象的原因吧。由于創建對象和初始化線程需要一定的時間，剛好給了主線程重置成績的機會。

不知道作者有意為之呢，還是疏忽，不過，這樣的錯誤不能算是race condition的例子。