今天和zy結隊程式設計了一天，討論了很多問題。主要是圍繞詞庫的開放式、實時的基本特性討論的。
下面是對這兩個特性的基本描述：
註冊使用者可以在查詢出來的詞彙中提交自己的詞彙解釋。這個解釋將被遞交到詞庫審核組，由審核組的工作人員審核這個提交。
例如，使用者daniel查詢了beyond這個詞彙，但是對這個詞有著自己的理解，他可以提交這個理解給審核組。
當乙個新的詞彙定義被審核組審核通過後，這個定義將被加入到詞庫中。
例如，使用者daniel提交了beyond的乙個定義，審核組通過了這個提交，則把這個新的定義追加到詞庫中的beyond詞下。
考慮了詞庫的權威性，要完全做到開放式很困難，其最困難的地方就是詞庫的維護。
權衡利弊，我們選擇了由專門的審核人員審核的做法。
詞庫分為兩種：
由使用者提交的查詢請求都集中在這個詞庫中進行查詢，如果詞庫中不存在使用者要查詢的詞彙，則說明詞彙未找到。這個詞庫內的單詞是不能重複的。
由使用者提交的新詞或者是對已有詞彙定義的新增
都放入這個詞庫，等待審核人員的審核。如果審核通過，則將該詞加入查詢詞庫：
新詞直接新建乙個詞彙記錄；對於已有詞彙定義的新增附加到該詞彙的定義後。同樣地，這個詞庫內的單詞也是不能重複的。
無論是查詢詞庫還是待審核詞庫都採用資料庫儲存。經過測試，乙個43w詞彙的詞庫，檢索乙個單詞可以在3－4s內完成。如果再建立快取服務的話，效率可以保證。
目前，xml格式的詞彙檔案作為核心交換檔案格式。例如從查詢詞庫中返回的詞彙記錄，採用xml格式直接傳輸到web介面，由web伺服器解析後顯示；從其他詞彙**／服務提供的單詞轉換成xml格式，並儲存進入待審核詞庫。
整個應用以osgi作為底層框架，以面向服務的元件模型構建。這樣可以做到很好的模組化，把耦合降到最低限度，為將來的擴充套件打下堅實的基礎。
基本的查詢詞庫由http://stardict.sourceforge.net/dictionaries.php">style="color: rgb(0, 0, 255);">stardict詞庫
轉換而來，測試轉換了乙個43w詞彙的英漢詞庫，耗時5小時。
由於詞彙量很大，做快取是必須的。不過現階段還沒有做，還處於研究階段。
在確定以上方案後，還有乙個方案可以選擇：
1. 每個使用者都有自己的詞庫，詞庫中的每個詞彙都有乙個得分
2. 查詢詞彙時從所有使用者詞庫中查詢
3. 按詞彙得分大小降序顯示各個使用者的詞彙解釋
4. 使用者可以對詞彙進行評分
5. 使用者可以提交對某個詞彙的修改，修改由該詞彙的擁有者審核
這個方案是建立在詞彙評級以及詞彙審核開放的基礎上的，有一定的可行性。
現階段學習計畫
資料結構與演算法 c python 程式設計之法 資料結構中各種樹 技術面試寶典 常用資料結構及複雜度 演算法複雜度速查表 15道使用頻率極高的基礎演算法題 常用的十大程式設計演算法介紹 面試中的排序演算法總結 資料庫 資料庫的最簡單實現 資料庫的原理 儲存過程簡介 漫談資料庫索引 mysql 索引...
PPP發現階段
ppp 發現階段 初始化pppoe 會話時，cpe路由器必須首先執行發現階段，以識別與其建立對等關係的裝置的 mac位址，建立乙個 pppoe session id 發現程序實質上是乙個客戶端 伺服器關係，在發現階段，路由器會發現服務提供商的接入集中器。cpe路由器可以在發現階段找到所有可用匯聚裝置...
DP現階段優化
長度 n 逆序對為 k 的排列有幾鍋？k 200 k 2000 排列計數問題經典套路 滿足排列套路，把1 n往後查，dp i j 前 i 個數 產生 j 的逆序對的方案數,因為新插入的數是更大的所以,分別考慮插在最後邊，次後邊.dp i 1 j x dp i j x belong 0,1,2,i 1...