省市聯動，之前我的玩法是每乙個select變動，都發請求到後台進行處理，後台將json發回前台，前台進行後面兩層或者一層的資料填充，後來發現這樣玩效率實在太過低下，（我寫的也不太好，會造成一些無用的請求）一開始本來還好啦，可是後來我們增加了乙個功能，根據使用者所存在系統裡得位址資訊來填充使用者資訊，世界一下子就不好了。我們要將省、市、縣三條資訊。寫入每一條資訊後面的資訊都會聯動。那麼我所遇到的問題就很麻煩了
第一步：寫入省份資訊——觸發事件，清空城市資訊——城市選擇框觸發change事件，向後台請求city=null的區縣資訊。城市資訊填充完畢觸發事件——請求city=city的區縣資訊。區縣資訊填充。
於是就在後台用json.net構造了乙個字典。（吐槽一下，.net自帶的序列化器太弱了。dictionary>這樣的物件就無法序列化了）城市的key用省份的id，區縣的key用城市的id。這樣玩我覺得是比較好的，不知道有沒有更巧妙的做法。然後後台構造資料的時候，序列化完以後記得要加個東西：在頭上，加乙個var cities= 在尾上加乙個; 這樣子就造出了乙個js的字典物件咯。區縣也一樣。然後把兩個js丟到乙個檔案裡，前台在頁面上加乙個結束。用起來效果很好的，速度很快。可以把引用放到body裡，因為我在後台構造網頁的時候填充了預設值所以不太容易出現讀值的問題。
關於效能的一點小心得
最近寫了個小程式，合併兩本英語詞典的例句。演算法很簡單，就是用個鍵值對的資料結構來儲存詞條，詞作為鍵，例句作為值，如果鍵已存在，就將例句加在已有例句的末尾。最後輸出全部鍵值對到文字檔案。因為還要用mdxbuilder將文字檔案轉成mdict格式的詞典，轉換過程中是會重新排序的，所以輸出到文字檔案時，...
github的一點小心得
很多朋友在github上建立了 倉庫後，急急忙忙的就在本地按照網上的說法，如下 cd dir git init git remote add git add git commit 但是這樣可能就會出現各種蛋疼的問題。最後發現有個更簡單的方法。在github上建立好 倉庫及專案之後，配置好git，然後...
關於晶元選型的一點小小心得
隨著電子技術的不斷發展，各種功能的晶元層出不窮。積體電路的發展基本向著高整合 低功耗方向發展。這在給我們的研發工作帶來了極大方便的同時，也為我們在實際研發過程中的選型問題帶來了不便。我從事晶元推廣工作以來，經過與客戶的討論和自己的經驗，認為研發工作中晶元的選型應考慮以下問題 第一 效能。我們選好了i...