搜索機哭人的麻煩，“偷”blogger的界面

老婆始終不願意讓豬豬單獨睡小床，怕給豬豬弄醒，所以睡到了地上，即使是如此，感覺也比前幾晚好得多了，睡得深了，但仍給豬豬間斷性的器鬧弄醒，早上六點半就起床了實在再也睡不下去了。

昨晚上實際上拖到很晚的時侯dep才恢復正常，這就讓我不敢輕易地對萬維服務器進行昇級了。
在 連接運行到60個小時後，萬維服務器的內存也沒有很好地得到釋放，出現了outofmemory的反應，而實際上負載並不多。這不知是意外還是意料之內 了，原來衹是打算看看主頁對象，但搞錯了服務器，卻發現萬維上不正常，隨後發現有記錄是內存溢出；反正已經改了不少的dep，於是決定昇級到萬維；但是昇 級完畢後，發現仍有不穩定，特別是，許多文章欄不見，由於已經全部昇級，連對照的版本也沒有，決定重新用回老的版本，而更新dao和相應的classes 目錄。……最後發現，是虛驚一場。但是，即使是從萬維早上溢出看，原因也是極度不明的。因為當時沒有修改過文件，也沒有很大的負載量，原因的確不明；唯一 的可解釋的地方就是由於數據結構修改與CLASS不同，可能造成大量的錯誤溢出。

目前存在著兩種選擇，其一是弱改寫而強目錄；其二是強改 寫，弱目錄。目前使用後者看來有點困難，很難做 到百分百的匹配它的目錄和文件，如果要看起來象是一 個獨立的文件目錄就 更不容易，看來，既然已經要修改它的重寫文件，不如改用強目錄。目前的科室同樣是使用強目錄，這樣就需要通過系統腳本生成和刪除所涉及到的目錄了。

午 飯前的一點時間收集了一點代理服務器，近來有點奇怪的是大陸的代理服務器越來越難收集了，其他地方的菜機反而是越來越多。還在用餐時高就來了電話，說專科 操作不起來，我再看看吧。非常明顯地，無論如何總是很難從目錄結構中得到充分的信息，所以既然已經使用系統腳本維護，那就需要生成一個global的文件 放置這些信息，對於一個複雜的站點，這個信息文件還是有必要的。

本來對Googgle想寫一份總結性的隨筆，但結果成了一篇文章，花了一點時間再貼出去。下面是做一個彈出的登錄窗口，這個很簡單，不過隨後打算“順手”為論壇加上Googgle廣告條，卻花了點時間，由於看不到出現的效果，顯得搞起來頗為勉強。

再 下面是搞妥那個後臺管理。結果花了一大堆時間“偷blogger的後臺界面”，因為我喜歡。界面組織其寮也並不是我的弱項，實際上，由於我的建模演算能力 很強，所以用例都很有針對性，較之一般的“好看”明顯高出一籌。衹不過我覺得把時間花在這些地方好象不太值，另一方面，我本身比較傾向內容驅動，非界面花 梢的原則——事實上我認為對於網站這樣缺乏忠實消費者的場所，界面越花梢，消費者的注意力越是分散，越是不會在這個網站消費。但由於高等人不配合，與其左 等右等出不來合用的界面，不如我自已直接采納好了。而最簡單的就是把合用的東西直接偷過來，改成自已的東西。

Blogger的界面幾乎全 部使用div/css編制，普通的另存為一點作用也沒有，害得我花了好久時間才把它的圖片一一弄下來——圖片是我真正的弱項， 我現在還不會用PS。曾經有爭論說table的濫用，但我覺得table沒有什麼不好用的，衹要注意不要整個大範圍的表格，就不會有問題；div/css 這樣可以把一些圖片以背景的形式在css文件中定義（另外這裡還看到了一個從前沒有見過的在css中定義適應不同的瀏覽器的方式），這樣大概是針對某種團 隊組織形式設計的，把圖片的更替可以由界面人員處理，而不會出現：“某某程序員，把某個圖片換一下”，顯然，目前是由於我們的美工太業餘——HTML代碼 是她們提供的，她們如果真懂得運用CSS，其實簡單的界面標簽也不會太困難的。

DEP由於outofmemory再次停機。但是在日志中沒有發現有大量的訪問讀數。有一個可能性，是由於訪問其他附從應用導致高負載停機，這是可能的，這樣在主負載應用上就沒有大量的訪問記錄了。看來，要抽時間把內存加上去了，這樣會可靠一點。

晚上好象很旺，顯然是有幾個搜索引擎在湊熱鬧，但同時登錄的也不是少數，居然速度還不算慢，已經1500個會話了，還在不停地增加，觀察內存似乎還有許多。看來的確是有現寮的意義對搜索引擎限時訪問，這點可以使用防火牆很容易地達到的。統計下來

這 個數字真是可怕，足以讓幾乎全部數據失真了。看來那個計數有很大程度上是把我們自已也給騙了，真實的點擊數減去這個就衹有一半左右。把這個清除去，看看計 數情況如何？會話記錄仍在發瘋似地上昇，已經達到了1700了。看來承受的能力也是相當強的。而把搜索引擎??的??剔除后，就意味?真正??的人?只有 原???的十分一以下，而平均每人??的??也就大幅增加了，?到10-20。??，整?估算都要?行更?。

?在已?禁止搜索引擎白天??，看看?果如何吧。