我們似乎陷入僵局了。
我先從最初的計畫來一遍：這個系統是用來減少動物尤其是珍稀野生動物穿越公路時與過往車輛相撞事故的，是保護珍稀野生動物的乙個方案；這個系統乙個典型的監控-資訊處理-發布的控制模型，資訊的處理和控制必須是系統核心功能環節，並且以****為處理單元，這是符合要求的。這個系統的資訊採集是應當比較單一化的，採集節點不能做得很複雜，要求體積小，功耗低，可靠性高，適合野外自然環境下、長期無人值守的情況下工作，自我維護。由於資訊採集與資訊需求的地理距離（一般情況下不在同乙個地方），所以需要通過某種途徑將資訊從採集點傳遞到發布點，然後從發布點遞交到接收點。這種資訊傳播不必是一直保持忙碌的，而應當是應對式的——有請求才有忙碌。因為該系統監控的事件和資訊的請求不是在時間軸上均勻分布，大多數時間是空閒的，某些時間區間是密集的，某些情況下有大量零星突發點……（考慮各種環境下動物穿越公路的可能模型）這樣可以控制住節點的最低必要功耗。採集到了資訊後，首先是資訊的傳播-處理，處理可以集中，也可以就地處理，也可以協作式處理。單個節點處理量的減少，可能會導致節點間的通訊量增大，比如目標資訊需要多個節點資訊進行綜合考慮時。如果目標資訊由單個節點提供足以滿足，那麼問題落到資訊的發布這乙個環節，我們需要一種途徑，將資訊傳送到需要這個資訊的地方，或者說，我們需要一種機制，能對臨時的請求作出響應，將有用的資訊（在哪？）回答給請求者（誰？在哪？）這裡的設計目標是，這種傳送或者說響應要快，才能起到預防的作用。資訊在發布點發布到請求者，請求者需要根據資訊採取適當的響應。根據簡單原則，請求者不應當很快的又發出另乙個請求，保證資訊渠道的暢通和高效使用。請求者請求的資訊應當是足夠的，沒有冗餘的，並能迅速計算出對策的，通過乙個介面到達終端使用者。
---------tiresome
團隊專案進展（六）
團隊專案進展 這兩天主要進展就是配置好了hadoop和sqoop環境，sqoop主要是將hdfs的檔案匯入到資料庫中。前台介面設計方面也在進行中，目前已經完成了從資料庫中取值，而後顯示在使用者介面中。在顯示的方式上，我們摒棄了以往單調的 顯示方式，即把資料統統顯示在 中，每一行只是乙個值，這樣的資料...
090807專案進展
10.44.112.180 10.44.112.222 1，昨天的執行緒搞在for迴圈的裡面，但是入參卻只有乙個，顯然是太離譜了 2，第一步的多執行緒只是想達到主視窗能接受滑鼠訊息，所以只需要乙個worker執行緒即可，把ondirectbutton的處理內容全部搬到threadfunc中來，入參是...
together專案進展報告4
上次更新寫到了首屏輪播圖的實現與優化，到現在為止，更新了一些另外的內容，包括側邊banner的滑動效果 登入註冊介面的設計，布局，以及部分js 的實現。首先是側邊banner欄的滑動實現 側邊欄的選項為乙個ul列表，為了讓使用者明確現在所處的位置，我將所示的欄目的選項定義乙個類 listfoc 並將...