<Request type="checkout">
<account id="??" />
<product id="??" amount="數量"/>
</Request>
傳送帳戶ID與商品ID即可。
同樣的商品若有多個，則設定amount屬性。
確認結帳的必要性再討論。
取消結帳則發送不含商品資料的結帳request即可。
2009年7月30日 星期四
2009年7月29日 星期三
定位組目前規劃
以先前所找到的paper定位方法進行實作:
架構如左圖
由client端偵測user AP強度傳給server端做定位計算
server端程式:
處理定位以及回傳位置的main
三個演算法各一class
以及一個紀錄參考點的database
三個演算法的整合想法如下:
P(x,y) = α Fun(knn) + β Fun(PDF) + γ Fun(RBFS)
目前大概模擬為 γ > α > β
(RBFN耗費以及定位精確度皆為中等 故假設加權最大，PDF計算時間最常精準度最低，到時可能會捨棄)
計劃表:
1.模擬一個database始可模擬演算法
2.先著手 KNN 以及 RBFN 演算法程式 最後PDF
(因RBFN算式較複雜，視狀況而定 可能僅採用KNN演算法( KNN是三者中定位效果最好的))
3.做好計算的main
4.做測量AP的程式(用於建立sample node 以及user的AP偵測)
5.建置sample node，完成database
6.實際測試再行修改
觸發程式時機:
定位系統發現所屬區塊變化時跳出新區塊的特價訊息(選擇性)
---為達此功能 須自動定偵測位置
使用者要求
---傳送要求時執行
2009年7月26日 星期日
2009年7月24日 星期五
Catelog XML規格(修改)
- Request
<request type="category_query" >
<category id="10000000" page="1"/>
#page屬性若沒有，就預設1
</request> - Response
成功找到：<Response type="category_found">
沒有找到：
<page current="1" all="12" />
<category id="10010000" name="汽水"/>
<category id="10020000" name="果汁"/>
</Response><Response type="category_not_found">
<category id="10000000" page="1"/>
</Response>
2009年7月22日 星期三
RFID Reader
http://tw.page.bid.yahoo.com/tw/auction/d41049462
為Reader
頻率 125hz
讀取距離 8~15cm
$1800
使用USB
http://tw.page.bid.yahoo.com/tw/auction/b48673433?r=1242889954
為Tag
頻率 125hz (適用上面的Reader)
有看到新的還會再更新
為Reader
頻率 125hz
讀取距離 8~15cm
$1800
使用USB
http://tw.page.bid.yahoo.com/tw/auction/b48673433?r=1242889954
為Tag
頻率 125hz (適用上面的Reader)
有看到新的還會再更新
2009年7月21日 星期二
2009年7月19日 星期日
2009年7月17日 星期五
Client 目前進度
Client的圖形介面聽取了 Yen 的建議，
將原本全部視窗都為Frame的方式，全改為一個主Frame來放其餘的視窗，而其餘的視窗都改為Panel來切換。
目前完成了
AccountHandler //處理登入及帳號問題
ProductionHandler //處理商品的詳細問題
FrameHandler //處理Frame切換Panel的問題
圖形化頁面有:
1. 登入畫面 (暫時還是手動輸入，等與RFID結合會用讀會員卡的方式)
2. 主選單
3. 購物清單列表 (改用JList 來表示)
4. 商品詳細頁面 (由購物清單點選想要的商品時切換)
5. 備忘清單 (待考察實用性)
6. 商品型錄 (待確定格式討論完)
核心的程式已經與 Server 進行測試過，大致上無問題
圖形化的還待測試，等測試完再PO上來
將原本全部視窗都為Frame的方式，全改為一個主Frame來放其餘的視窗，而其餘的視窗都改為Panel來切換。
目前完成了
AccountHandler //處理登入及帳號問題
ProductionHandler //處理商品的詳細問題
FrameHandler //處理Frame切換Panel的問題
圖形化頁面有:
1. 登入畫面 (暫時還是手動輸入，等與RFID結合會用讀會員卡的方式)
2. 主選單
3. 購物清單列表 (改用JList 來表示)
4. 商品詳細頁面 (由購物清單點選想要的商品時切換)
5. 備忘清單 (待考察實用性)
6. 商品型錄 (待確定格式討論完)
核心的程式已經與 Server 進行測試過，大致上無問題
圖形化的還待測試，等測試完再PO上來
2009年7月12日 星期日
MVC範例程式
給Client端介面設計人員：
不好意思，說明文越打越長，暫時是打不完了。可以先看網路上的資料，但大多都很籠統。
其實MVC骨子裡就是Observer pattern，可以找這方面的資料來參考。
目前先寫出一個範例程式，可以看看：
http://docs.google.com/View?id=dfj5vj97_379qn4xpfz
在這個範例裡，Controller就是負責接收按鈕事件的ActionListener，Model是FrameState而View就是JButton和JFrame。Model的狀態只要一更動，就會通知View更新，因此View必須實作Observer介面，才可以註冊為Model的觀察者並接收更新訊息。
以下是下面的圖和程式碼行號的對應：
事件觸發：
使用Java的內部機制，110行的 actionPerformed會在按鈕事件觸發後被呼叫。
取得View的資料：
此範例不需要取得任何View的資料。
更新資料：
111行的state.setCurrentPanel(XXX); 就是更新model裡的資料。(state在本範例裡就是model)
通知有更新：
72和77行的notifyObservers(); 會呼叫96行的notifyObservers()方法，該方法會呼叫每個已註冊的Observer的stateChanged()方法。觀察者就會執行它們各自的stateChanged()實作。
這部份很像Strategy Pattern，可以參考Wiki。
取得資料：
45行的state.getCurrentPanel()就是從state取得資料，並更新view。
如果有問題請再提出來。
--------------------------------------------------------------------------
以下是目前說明文完成的部分，全部完成後會放到言式法則上：
Model-View-Controller架構是相當被廣泛應用的架構模式之一，將物件在某一互動元件中所扮演的角色區分為Model、View與Controller，能夠有效地分離商業邏輯與使用者介面。
所謂的Model指的是資料內部表現，也就是資料結構；View是資料的外在表現，也就是與使用者互動的介面；Controller則是介於內外部資料表現之間的協調者，負責將外部要求反應到內部資料。因此MVC能用一句話概括：「內部資料表現必須直接反應到外部資料表現上，而外部要求必須經由協調者反應到內部資料表現上。」圖示如下：
必須注意這只是標準的架構。MVC有相當多變化的形式，各個物件之間不見得必須互有關連，例如MVP (Model-View-Presenter)就是一種MVC的衍伸，其Passive View的做法是將View與Model的直接關聯消除，改由Presenter去協調雙方。
如果覺得看上圖不清楚，我們生活週遭其實就有相當多MVC的例子可以現學現賣。試想你現在要使用印表機印出資料，你會在你的Word上按下列印按鈕，這個你可以看得到的按鈕，就是所謂的View(概念很簡單，因為你看得到它)。按下按鈕後，就會觸發事件，讓Word內部程序擷取Word的資料。資料經過處理後，會送到印表機的列印佇列上排隊等列印。這個內部程序就是Controller，負責把外部要求反應到內部資料。列印資料會暫存在列印佇列上等待，這個列印佇列是一種先進先出(FIFO)的資料結構，也就是Model。最後，Model會通知印表機有資料需要列印，資料就從印表機裡印出來了。印表機也是一種View。
看完這個故事，你可能會覺得很奇怪：為什麼View從一開始的按鈕變成印表機了？其實觸發事件的View與反映結果的View不需要是同一個，一切都取決於Controller怎麼協調。因此請將上圖的View、Model與Controller視為角色的集合，而不是單一物件。
不好意思，說明文越打越長，暫時是打不完了。可以先看網路上的資料，但大多都很籠統。
其實MVC骨子裡就是Observer pattern，可以找這方面的資料來參考。
目前先寫出一個範例程式，可以看看：
http://docs.google.com/View?id=dfj5vj97_379qn4xpfz
在這個範例裡，Controller就是負責接收按鈕事件的ActionListener，Model是FrameState而View就是JButton和JFrame。Model的狀態只要一更動，就會通知View更新，因此View必須實作Observer介面，才可以註冊為Model的觀察者並接收更新訊息。
以下是下面的圖和程式碼行號的對應：
事件觸發：
使用Java的內部機制，110行的 actionPerformed會在按鈕事件觸發後被呼叫。
取得View的資料：
此範例不需要取得任何View的資料。
更新資料：
111行的state.setCurrentPanel(XXX); 就是更新model裡的資料。(state在本範例裡就是model)
通知有更新：
72和77行的notifyObservers(); 會呼叫96行的notifyObservers()方法，該方法會呼叫每個已註冊的Observer的stateChanged()方法。觀察者就會執行它們各自的stateChanged()實作。
這部份很像Strategy Pattern，可以參考Wiki。
取得資料：
45行的state.getCurrentPanel()就是從state取得資料，並更新view。
如果有問題請再提出來。
--------------------------------------------------------------------------
以下是目前說明文完成的部分，全部完成後會放到言式法則上：
Model-View-Controller架構是相當被廣泛應用的架構模式之一，將物件在某一互動元件中所扮演的角色區分為Model、View與Controller，能夠有效地分離商業邏輯與使用者介面。
所謂的Model指的是資料內部表現，也就是資料結構；View是資料的外在表現，也就是與使用者互動的介面；Controller則是介於內外部資料表現之間的協調者，負責將外部要求反應到內部資料。因此MVC能用一句話概括：「內部資料表現必須直接反應到外部資料表現上，而外部要求必須經由協調者反應到內部資料表現上。」圖示如下：
必須注意這只是標準的架構。MVC有相當多變化的形式，各個物件之間不見得必須互有關連，例如MVP (Model-View-Presenter)就是一種MVC的衍伸，其Passive View的做法是將View與Model的直接關聯消除，改由Presenter去協調雙方。
如果覺得看上圖不清楚，我們生活週遭其實就有相當多MVC的例子可以現學現賣。試想你現在要使用印表機印出資料，你會在你的Word上按下列印按鈕，這個你可以看得到的按鈕，就是所謂的View(概念很簡單，因為你看得到它)。按下按鈕後，就會觸發事件，讓Word內部程序擷取Word的資料。資料經過處理後，會送到印表機的列印佇列上排隊等列印。這個內部程序就是Controller，負責把外部要求反應到內部資料。列印資料會暫存在列印佇列上等待，這個列印佇列是一種先進先出(FIFO)的資料結構，也就是Model。最後，Model會通知印表機有資料需要列印，資料就從印表機裡印出來了。印表機也是一種View。
看完這個故事，你可能會覺得很奇怪：為什麼View從一開始的按鈕變成印表機了？其實觸發事件的View與反映結果的View不需要是同一個，一切都取決於Controller怎麼協調。因此請將上圖的View、Model與Controller視為角色的集合，而不是單一物件。
2009年7月10日 星期五
測試部分part4
登入 1(一瞬間傳送多筆資料):
5000執行緒
SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 13:48:08 CST 2009
所需時間: 27 minutes 12 seconds
CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 10:44:09 CST 2009
所需時間: 7 minutes 1 second
FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 10:52:00 CST 2009
所需時間: 3 minutes 30 seconds
SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 10:56:49 CST 2009
所需時間: 9 minutes 4 seconds
SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 13:08:09 CST 2009
所需時間: 15 minutes 15 seconds
測試部分part3
商品查詢 1(一瞬間傳送多筆資料):
5000執行緒
用亂數選擇
SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 12:03:00 CST 2009
所需時間: 33 minutes 21 seconds
CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 12:39:16 CST 2009
所需時間: 3 minutes 58 seconds
FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 12:44:47 CST 2009
所需時間: 7 minutes 5 seconds
SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 12:52:32 CST 2009
所需時間: 4 minutes 49 seconds
SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 12:58:13 CST 2009
所需時間: 5 minutes 47 seconds
測試部分part2
商品查詢 2(每隔一段時間傳送一筆資料):
1000執行緒 1執行緒有5筆 間隔時間:1 second
SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 09:47:23 CST 2009
所需時間: 15 minutes 9 seconds
CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 09:24:18 CST 2009
所需時間: 1 minute 56 seconds
FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 09:17:36 CST 2009
所需時間: 3 minutes 57 seconds
SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 09:13:34 CST 2009
所需時間: 2 minutes 23 seconds
SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 08:56:48 CST 2009
所需時間: 14 minutes 47 seconds
共同的ERROR:
java.net.ConnectException: Connection refused: connect
測試部分part1
測試10000筆會有ERROR: java.lang.OutOfMemoryError: Java heap space
改測試5000筆
使用全部為0查詢，好像只列出一樣商品，即使資料庫有多筆商品
格式不符，出現錯誤結果，概念簡單但須注意
登入 2(每隔一段時間傳送一筆資料):
1000執行緒 1執行緒有5筆 間隔時間:1 second
SINGLE:
使用的Executor: java.util.concurrent.Executors$FinalizableDelegatedExecutorService
測試時間: Sat Jul 11 08:15:48 CST 2009
所需時間: 13 minutes 24 seconds
CACHE:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 08:31:20 CST 2009
所需時間: 2 minutes 0 seconds
FIX:
使用的Executor: java.util.concurrent.ThreadPoolExecutor
測試時間: Sat Jul 11 08:34:28 CST 2009
所需時間: 2 minutes 43 seconds
SCHEDULE:
使用的Executor: java.util.concurrent.ScheduledThreadPoolExecutor
測試時間: Sat Jul 11 08:39:49 CST 2009
所需時間: 2 minutes 6 seconds
SINGLE_SCHEDULE:
使用的Executor: java.util.concurrent.Executors$DelegatedScheduledExecutorService
測試時間: Sat Jul 11 08:43:23 CST 2009
所需時間: 12 minutes 11 seconds
共同的ERROR:
java.net.ConnectException: Connection refused: connect
2009年7月8日 星期三
目前完成的部分(Yen)
- 更正Server端的bug
已改正連線池的問題，詳情見http://yensrule.blogspot.com/2009/07/blog-post_08.html - 改進Server端的組態設定方式
改為以config.xml組態檔設定
密碼是我的學號，大寫。
2009年7月6日 星期一
7/7 ~ 7/20 預計做的事情(Yen)
- 更正Server端的bug
目前發現Server端連線池的設計上有點問題，導致無法正常關閉，以及回收Connection的讀秒器會造成Race Condition。前者目前已擬出解決辦法，後者則待觀察。其餘bug則待測試發掘。 - 改進Server端的組態設定方式
目前是採用hard-coded的方式寫死在Default組態類別裡，將改採以組態檔的方式設定。 - 擴大Server端錯誤回報的範圍
目前只能針對連線與資料庫連線兩部份進行logging的動作。已想到擴大範圍的辦法，待實作。 - 閱讀RFID Essentials
想先深入了解RFID的應用方式。閱讀到某個階段會將重點貼上來。
Server端目前的Javadoc，請參考http://tw-yen.no-ip.org/javadoc/rfidserver/
也煩請各位貼出這段期間的計畫，並在每件事情完成後將相關訊息貼上來。
有空閒會將一些Programming的心得寫在 http://yensrule.blogspot.com，大家有空可以看看。
第九次Meeting記錄
開會時間：
2009年 07月 06日(一)
討論內容：
報告暑假期間的各個組的進度
檢視目前Client完成的程度
硬體的需求
討論結果：
下次開會時Client主要功能完成，並與Server測試
定位組的需決定採取何種方法來實做
目前進度：
Server : 完成 (待與Client測試)
Client : 50%
定位組 :
硬體 : 暫無
細節：
阿汶今次缺席，希望今後多注意
下次開會時間：
2009年 07月 20日(一)
預計下次開會前的進度：
Client 完成
定位方法確定
2009年 07月 06日(一)
討論內容：
報告暑假期間的各個組的進度
檢視目前Client完成的程度
硬體的需求
討論結果：
下次開會時Client主要功能完成，並與Server測試
定位組的需決定採取何種方法來實做
目前進度：
Server : 完成 (待與Client測試)
Client : 50%
定位組 :
硬體 : 暫無
細節：
阿汶今次缺席，希望今後多注意
下次開會時間：
2009年 07月 20日(一)
預計下次開會前的進度：
Client 完成
定位方法確定
訂閱：
意見 (Atom)