日誌

今天繼續在作聊天的小程序
1.在引用hibernate的時候，讀取hibernate.cfg.xml的時候不斷地提示not found ，起初是懷疑路徑的問題，但是改了不少次
仍是沒有用，想不到爲何會報那個錯，至今還沒解決那個問題
2.界面的數據發送已經調試好了，藉助一個static 的iosession 將起初鏈接的iosession保存下來，這樣每次，界面發送數據包的
時候就能夠用這個iosession了。把界面和業務的操做分開。

體會：一個小問題可能一天都解決不了，一直卡在那裏，畢竟看到的，和本身實踐的仍是有很大區別的，明天問問其餘人
最近要加緊了。

明天計劃：
主要業務邏輯實現

這周的工做
這周是在上週框架熟悉的基礎上，在作多人聊天程序，界面編寫完成
用戶登陸，註冊已經實現，對於以前學習的框架有了實際的體會和熟悉
也發現了不少問題，須要不斷學習。

下週計劃
多人聊天程序的羣聊和私聊的實現，聊天記錄查詢，禁言功能的實現

今天主要在作聊天小程序
1.在作到羣聊的時候，服務器返回數據，客戶端接收到了，可是沒法顯示在界面上，找了不少辦法仍是沒有解決
2.在給客戶端發送在線用戶信息的時候，發送不成功，暫時沒有找到找到問題緣由

今天把羣聊和私聊的邏輯梳理了下，解析輸入框中的用戶名個消息的信息，經過傳遞給服務器消息類型信息。是羣發仍是私聊
在服務器進行解析，分別處理.

明天計劃
1.解決今天Bug
2.把羣聊和私聊作好
3.加入禁言的功能

 

 

今天主要在作聊天程序
1.解決了昨天界面顯示數據的問題，
緣由是每次都會實例一個新的對象，因此每次的界面是不一樣的，顯示不了數據
改進：將聊天類聲明改成static的類型就能夠了，保證界面是始終保存的，不會再次實例化，swing爲何會不斷實例化
界面類仍是不懂
2.解決了昨天客戶端接收來自服務器的用戶列表不成功的問題
緣由是在客戶端解析的時候解析錯誤，始終取不出來自服務器的數據，其實客戶端接收到的
改進：將發送的數據類型改成數組類型，而後在客戶端解析的時候，解析爲list。
3.完成了羣聊和私聊功能
4.完成用戶列表顯示功能
5.完成日誌記錄功能，包括羣聊日誌和私聊日誌

體會：時間是還太急，有些問題解決了，仍是對內部的深層次的緣由不是很理解，有時間仔細調試下
如今的客戶端和服務器的數據傳遞仍是有點不方便的，有些複雜類型的數據傳遞的支持不太好。

明日計劃
1.最近10條聊天記錄的查詢顯示
2.禁言功能
3.用戶列表的刷新

今天在作聊天程序
1.完成了最近10條的羣聊和私聊的聊天記錄顯示
2.禁言功能完成

明日計劃
1.定時答題

今天繼續在作聊天程序
1.對禁言進行了完善，可是仍是存在一些問題，對禁止說的關鍵字只能單個所有的匹配，若是禁止說的話
是夾雜在語句之間則不能對正確的匹配，問題在於若是用戶是單純的發送禁言能夠很好識別，可是要是夾雜在
語句中間則不必定是禁言，沒有一個標準，如今只作到了機械的徹底匹配。
2.在java中的時間類型處理有了深刻的體會，首先使用java。util.datelai 來生成一個當前時間，而後
用simpleformatdate進行轉化爲想要的形式，要想獲得一個距離當前一個間隔的時間 要用到calender
的set進行設置。
3.在進行一個數據轉換時發現 object 不能強制轉換爲string類型 由於這個還找了好長時間的bug
以下：Object aa = 11;
String bb = (String)aa;
System.out.println(bb);
轉換時會報錯：java.lang.Integer cannot be cast to java.lang.String
4.用戶增長了金幣功能。
體會：今天主要在調試bug，有不少是數據傳送的時候格式轉換出問題，禁言一開始是在客戶端作得
感受那樣簡單，並且效率高。可是有人提醒我那樣會很容易做弊，客戶端的數據玩家是能夠
改動的，爲了保證數據的安全性仍是改成在服務器作了，只是將結果傳回客戶端。一些重要的處理要在
服務器完成。

明日計劃
1.定時搶答完成
2.代碼邏輯優化

 

今天繼續作聊天程序
1.完成了計劃完成很久的定時在線搶答
2.優化了部分代碼

體會：服務器和客戶端的網絡通訊是須要時間的，若是在服務端對這個時間不考慮很容易在成錯誤的發生
，當一塊兒發送兩個報文，是不肯定那個是確定先到達服務器的，有的順序在前面發送的也不能確定
服務器必定會先收到他，這就容易形成不少問題，例如搶答狀態的肯定，是經過發送報文來通知
客戶端的，若是此時還有數據在發往客戶端，就會對這個狀態的判斷形成錯誤，明明服務器翔客戶端發送
不能再答題了，但是發送題目的報文先到了，或者是這個不能再發送題目的報文會丟失，都會形成服務器
一直不斷地發報文。網絡通訊在必定程度上很難保證正確，要在程序裏多作些由於網絡緣由形成的錯誤的
判斷，對重要的數據尤爲如此。

今天主要在對以前的聊天程序作優化
修改bug
1.修正了在線聊天用戶不能所有顯示的問題
2.搶答問題，修正了答對了的用戶的界面不能顯示最新的金幣數量的問題
3.對於登陸時 帳號密碼錯誤不能登陸，給予界面提示
4.修正了關閉聊天主界面不能關閉與服務器鏈接的問題
代碼優化
1.刪除了多餘無效的註釋
2.對部分變量進行修改

體會：在 程序的易用性，穩定性方面還要多作工做，對於頗有可能的錯誤應給與提示，對於代碼的邏輯應清晰處理
對於繁瑣無用的邏輯應簡化處理，一個類或者函數應簡化掉與它不相關的功能，使模塊化更強
耦合性更小。

明日安排

閱讀遊戲源代碼


今天主要是看源代碼和改bug
1.學習了java線程池方面的內容
2.修正了聊天程序當用戶退出時，其餘用戶在線用戶列表不能實時更新的問題
3.看了萬炮捕魚程序代碼。

體會：服務器後臺數據發送如今是經過線程池的機制去處理的是，當服務器接收到數據以後，放入隊列，
從隊列中不斷循環取出數據，進行發送。可是如今線程池的corepoolsize是1，對於cpu的利用率是不夠，
由於發送線程的任務仍是有不少計算的，要是能夠在線程池中多建立幾個線程，可能會時cpu利用率提升。
以前的聊天程序對於用戶退出的後續操做作的仍是不夠仔細，形成用戶列表的更新有問題，今天修改了下
在用戶下線後，廣播一個新的用戶列表給其餘的用戶，使得用戶列表能夠真實反映在線用戶的狀況。
看了萬炮捕魚的代碼，和以前的的demo的結構很像，處理的過程也是類似的，只是有些邏輯複雜了點
還有些spring注入和註解的看不懂，以後要看看spring的深刻的東西。

明日計劃
看代碼

37 頁

今天主要在看struts2的內容
對strut2的基礎作了瞭解
1.struts是基於MVC的WEB開發框架
2.MVC：是Model、View、Controller這三個英文單詞的縮寫。
「Model」表明的業務邏輯這塊由Java實現的組件。「View」則表明了表示界面，
「Controller」表明的是處理流程控制，主要功能是實現業務邏輯如何和表示界面相關聯的技術
3.起初的開發模式是直接在jsp裏面寫邏輯，裏面代碼會很複雜，頁面之間的代碼複雜，複用維護困難
MVC的開發模式是把程序分爲輸入，處理，輸出三個部分進行處理，頁面顯示，邏輯控制是相互分離的
能夠對他們進行修改而不影響其餘。
4.Struts2基本範圍幾大塊：標籤庫，filterdispatcher和action，配置文件，校驗規則，類型轉化
sitemesh頁面佈局，國際化和本地化。

體會：剛接觸struts ，MVC的思想仍是以前熟悉的，對於struts的處理流程仍是不太清楚，接下來
要作點小程序加以熟悉。
明日計劃：
繼續看struts2，作點小demo

今天主要在看struts
作了小demo對struts的運行流程有了直觀的瞭解
1.開發struts進行的基本步驟
導入struts包
配置struts.xml文件
配置web.xml文件
在struts.xml中進行action的配置
編寫java類和jsp文件
2.一個jsp中的form對應於一個pojo類
3.struts.xml中的package應該和類的包名對應
4.驗證功能是在execte執行前進行的，驗證失敗，程序流程會跳轉到struts.xml中配置的result的input
指定的頁面中

體會：struts對請求和響應進行很很大程度的封裝，之前的網頁開發模式是瀏覽器請求到服務器，服務器得到
請求對象request ，解析request中的數據，根據請求數據進行相應的處理，而後把要返回給瀏覽器的數據
分裝成爲response對象進行返回，實現B/S的結構。在struts中把請求和響應的原始形式進行了屏蔽，咱們只要
配置action，寫主要的處理業務邏輯，就能夠實現業務，簡化了解析和封裝的步驟，更加的高效，可是
必須按照struts的流程來作，在它指定的流程中加入本身的邏輯。

 

周志

這周主要是
1.修改了聊天程序中的一些bug
2.看了下萬炮捕魚的代碼
3.學習struts2

體會：聊天程序仍是有一些bug好沒有解決，有時間仍是要解決下，萬炮捕魚代碼結構上是瞭解了，具體的一些
細節仍是要仔細看看。struts2剛接觸，基本概念和流程這兩天明白了，接下來要對其中一些具體的功能細節學習

下週計劃：
1.前一兩天繼續學習struts2的內容
2.以後的時間作web的開發，針對之間的聊天程序作統計功能。
3.爲遊戲的統計作準備工做

49頁

 

今天主要在學習struts2的內容
攔截器方面
1.攔截器：普通的java對象，做用是動態的攔截action調用
2.配置攔截器 <interceptor></interceptor>
3.配置攔截器棧：<interceptor-stack><interceptor-ref></interceptor-ref></interceptor-stack>
4.攔截器和攔截器棧之間能夠嵌套使用
5.能夠定義本身的攔截器，繼承abstractinterceptor 重寫interceptor方法便可
6.文件上傳下載攔截器的使用
7.在struts.xml中使用本身的攔截器的時候，若是本身的攔截器和struts默認的攔截器同名的話，
要把本身定義的攔截器寫在默認的攔截器的前面，由於struts中的同名攔截器只調用一次
8.<default-interceptor-ref>默認的全局攔截器，對全部的action都起做用
標籤庫
1.在struts-tags.tld中定義了strut2的標籤，也能夠本身定義本身的標籤
2.append標籤， generator標籤，if、else、elseif標籤， iterator標籤， merge標籤，sort標籤
subset，action標籤，bean標籤，date標籤， debug標籤， include標籤， push標籤，url標籤，基礎表單標籤
複雜表單標籤

velocity部分
在普通的HTML代碼里加入動態的數據

體會：對於頁面的顯示，最好是使用標準的html5標籤。

明日計劃：
繼續學習struts2 的內容

125

今天在學習struts和作demo
上午把struts的大部份內容看完，對於標籤，國際化，界面顯示技術作了瞭解
下午結合本身以前的聊天demo 進行ssh的開發，把以前的聊天程序中的數據庫中的相關信息取出來
展現在頁面上
體會：在進行ssh的整合的時候，出現不少的問題，不能運行起來，解決了一個下午，總算能夠運行起來
在一個框架中進行開發時沒有遇到的問題都出來了，不少錯誤感受莫名其妙，總結看來仍是對
框架的熟悉不夠，只能循序漸進的照着文檔demo使用，在幾個框架整合的時候就凸顯出了問題，簡單的
jar包報錯都不知道緣由，之後多作些實例，熟悉起來這些框架

明天計劃
ssh的demo繼續作，加入具體的邏輯。

 

今天主要在看大廳服務器的代碼
1.安裝了管理後臺的客戶端，推廣員APP ，測試了管理後臺客戶端和大廳服務器的通訊過程，其過程
相似以前作過的聊天demo ，總的過程是 客戶端發報文 ，服務器解析報文，根據請求去作處理，而後給予客戶端
一個應答報文。推廣員APP和大廳服務器通訊的過程是相同的
2.閱讀了大廳服務器的部分代碼，大廳服務器啓動時會讀取applicationContent文件，進行注入，開啓相應的端口監聽
，客戶端選定一個端口和服務器的相同端口進行鏈接的創建，而後就能夠進行通訊了。
3.服務器增長一個端口服務的過程，在applicationContext裏配置一個新的socket，指定端口號，和handler的處理類
增長一個sockethandler的類 ，其繼承iohandler，在其中的messageservice中進行反射，調用相應的servive類，進行處理
在service類中調用dao，util等進行具體的邏輯處理，servive類將處理結果，進行發送。而後客戶端接收處理。一個基本的
客戶端服務器交互就完成了。

體會：大廳服務器開啓多個端口，每一個端口提供相應的遊戲服務，如果服務請求太多，能夠再分到不一樣的計算機，都是很容易的。
客戶端其實也能夠這樣作，在功能上進行分開，每一個功能部署到不一樣的機器上

明日計劃：
看大廳服務器代碼 深刻了解處理的邏輯

 

今天看了大廳服務器的代碼
對於socket，service ，dao和配置文件詳細看了下，對於spring的註解進行了學習
對於hibernate的查詢深刻了學習
1.socket中數據的傳輸協議如今是 服務的類名/方法，客戶端發送報文發送的是 服務的類名/方法 加上請求參數
客戶端收到後進行一系列的解析 ，提取出了類名和方法 運用反射得到結果，進行發送返回，返回前的數據是map的
類型，發送前的數據封裝也是這樣的。爲何用map 多是map取值容易。
2.service 中有一些方法提供具體的服務，方法中大可能是調用dao中的方法進行數據庫的操做，複雜一點的加點判斷和邏輯
本質仍是數據庫的操做
3.dao 採用了hibernate提供的方法 進行操做數據庫 ，代碼簡潔
4.配置文件 ：開始時候不太能看懂 ，而後看了些spring的註解方面的文檔才明白，整個項目採用了大量的註解，進行bean的定義
和自動注入，感受spring確實強大，節省了不少人力工做。
5.hibernate的查詢 開始只是簡單的使用 ，在看dao的代碼的時候 學習了不少了新的用法，搞清楚了幾個基本的問題，總結以下：
delete uodate insert 通常使用 createquery（）.executeupdate
select 若是查詢的結果是單個值 例如：select sum(filed) from table 用createquery().uniqueresult就能夠了
若是查詢的是比較多的東西：能夠分幾類：
查詢所有的字段 select * from table 要用到 createquery（）.list,此時list裏面
都是具體的對應於表的類對象，這種方式仍是比較容易的
查詢的是一個字段 如 select name from table createquery（）.list 此時list裏面
是object的對象，遍歷取出就好。
查詢的是幾個字段 好比：select name， pwd，age from table createuery().list裏面
則是數組，這時候不方便取出使用，這時候可使用 select new 包名.類名（屬性列表）from 實體類
進行查詢，而後在實體類裏面加入相應的構造函數，此時list裏面仍是實體類的對象，方便使用

體會:關於spring的註解的使用，對於類級別並且不會發生變更的配置有較好的便利性 ，若是對於容易發生調整的類最好仍是
使用傳統的xml的配置,易於更改，就像socket的配置那樣。

明日計劃
學習hibernate的註解
看下其餘部分的代碼

今天看了hiberbate註解，java 線程池方面的介紹 ，前端bootstrap框架介紹
1.以前用hibernate 在進行表和類的映射使用的是hbm.xml的文件 按照表字段和類字段一一對相應創建關係，若是有
不少的表和類會有不少的配置文件，spring一開始也是這樣，須要在配置文件裏寫不少的bean，很不方便，hibernate和
spring同樣引入註解的，在實體類上加入一些簡單的註釋，就能夠不用寫那麼多的配置文件，並且還能夠根據註解直接生成數據庫表
。
2.如今的服務器框架中的線程池以前以爲有點問題，今天深刻看了下文檔，發現如今的服務器線程池確實是有問題的
首先 線程池 corePoolSize設置是1 ，這裏的corepoolsize 文檔裏面解釋的是 the number of threads to keep in the pool, even if they are idle
也就是池內保持運行的線程數目，後面的一個參數maxpoolsize在 緩存隊列滿的時候和線程池運行的線程數目和設置的
corepoolsize相同的時候，會再次生成線程，當達到最大線程數目的時候 再來的線程會根據handler 的定義去處理
可是如今設置的boolckqueue是 SynchronousQueue<Runnable>，查了下文檔，這種隊列的意思是它將任務直接提交給線程而不保持它們，也就是
不會放入緩存隊列，直接建立線程去處理。
如今的服務器的線程池簡單來講是：每次接受一個數據發送的請求，就生成一個線程去處理，沒有線程池的做用了
不會緩存任務，而後開啓線程去處理。和使用messagesend.send效果是相同的
如今想到的辦法是，將線程池的 BlockingQueue改成 ArrayBlockingQueue 而後設置 一個和合理的大小，建議是線程池的
corepoolsize設置的大點 緩存隊列設置的小點，這樣有利於cup使用率的提升，可是也會產生調度的開銷變大，這個要折中
設置，通過測試，取一個比較合理的值，讓cpu的使用率提升。從而服務器的效率變高。

採用這種發時候能夠進行拒絕策略的設置 也就是線程池初始化的handler 能夠定義本身的RejectedExecutionHandler用於處理
拒絕的任務

3.瞭解了點前端的bootstrap 可能要用到。

 

 

 

周志
這周主要是學習新知識和看代碼
1。看了大廳服務器的代碼
2.hibernate，spring的深刻了解
3.學習struts2基礎

下週計劃
新項目開發
sturts2學習

今天主要在作水滸傳的管理後臺功能
1.完成遊戲桌列表的獲取
2.霍城遊戲桌的更新和刪除
3.完成遊戲桌的新增

體會：如今的管理後臺的代碼所在結構上是有點混亂的，一個類裏面的功能太多，代碼上千行，
對於維護很不方便，此次在增長水滸傳的功能時，分離了功能，全部關於這個遊戲代碼在單獨的類
文件裏面寫，類的功能簡單，代碼少，之後維護起來也容易，建議管理後臺的代碼要以遊戲來劃分代碼，每一個類功能精簡專注,而不是
以如今的大的功能模塊來劃分。

明日計劃
1.獲取桌上的會員清單
2.獲取桌上的數據信息
3.清零桌上的會員清單
4.獲取桌上的遊戲結果信息清單

今天在作水滸傳的管理後臺功能
1.完成獲取桌上的會員清單
2.完成獲取桌上的數據信息
3.完成清零桌上的會員清單
4.和遊戲那邊的數據庫實體類進行了統一

體會：今天功能上開發的少，不少時間花費在了交流上，有些數據庫方面的表遊戲方面和管理後臺方面的定義的不一致
到後期勢必會引發融合的問題，在遊戲設計方面，沒有造成一個相對固定的文檔，致使在管理後臺和遊戲那邊在一些
基礎的問題上沒有達成一致。在開發中一有修改，致使多方都要修改，很麻煩。最好在詳細設計的時候，在一些類上
保持一致，不要隨便修改，即使要修改也必定要告知其餘相關開發，以避免後期的大的改動。設計文檔最好詳細，多方都要
用到的文檔，必定要一塊兒設計，肯定下來。

明日計劃
1.獲取桌上的遊戲結果信息清單
2.遊戲運行統計
3.調試以前的代碼

今天在作水滸傳管理後臺
1.完成獲取桌上的遊戲結果信息清單
2.重構了下以前寫代碼，消除了一些冗餘。
3.修正了開啓桌，剩餘桌數量的顯示錯誤
4.增長了開啓桌數量的限制

明日計劃
1.遊戲運行統計
2.代碼優化

 

今天在作水滸傳管理後臺
1.修正添加桌子，桌排序字段始終是0的錯誤
2.對以前寫的代碼進行了部分優化
3.完成遊戲運行統計

 

周志
這周主要是在作水滸傳管理後臺的功能
1.水滸傳的後臺管理 桌子方面的功能完成
2.配合張賀調試了後臺管理中新增長的水滸傳的功能。

體會：水滸傳的後臺管理功能在編碼上工做量很少，主要是對以前的代碼的熟悉和對開發過程當中的溝通交流。

下週計劃
1.根據後臺管理的需求繼續作後臺管理的工做
2.對大廳的代碼的閱讀和重構

今天在作水滸傳管理後臺
1.添加了桌新增，刪除，參數修改，清除數據的操做記錄的功能。
2.協助管理後臺客戶端作功能大的調試
3.發現basedao中的update 函數的問題 ，basedao中update函數若是要使用的話，必須加入getseeion（）.clear（），將
原有的緩存清除，不然會報異常：a different object with the same identifier value was already associated with the session。

體會：儘可能精簡代碼，儘可能使用hibernate對數據庫進行操做，減小繁瑣的sql語句和應爲實體類的改變而引發的大量的修改
就像update對象，簡單的hibetnate.update(object)就能夠解決問題，而不須要很長的sql語句。

明日計劃
配合張賀作管理後臺服務器的工做

今天在作水滸傳管理後臺
1.完成運行統計的功能

體會:運行數據獲取，水滸傳和其餘的遊戲不相同增長了幾個字段，選擇修改了數據庫，可是運行統計的以前代碼寫
的太死，開始一直不知道怎麼加入新的遊戲，後來想到了方法，基本解決了問題，可是代碼結構更加的亂了。
之後寫代碼仍是靈活點，給之後的想不到的擴展留下餘地，也不用今天這麼費時費力了。

明日計劃
配合張賀作管理後臺服務器的工做

 

今天主要在作大廳服務器和水滸傳的服務器的通訊
1.對於後臺管理客戶端作得修改 ，返回給遊戲服務器。
2.梳理大廳服務器和水滸傳服務器的通訊報文。

明日計劃
1.大廳服務器和水滸傳的服務器的通訊繼續編寫
2.大廳服務器和水滸傳服務器的通訊報文文檔整理

 

今天主要在作大廳服務器和水滸傳的服務器的通訊
1.大廳服務器和水滸傳服務器的通訊基本完成
2.瞭解下mina的線程模型
3.瞭解 java 虛擬機監控軟件jvisualvm
4.梳理了下大廳服務器的結構

明日計劃
1.和梁遠遠那邊進行遊戲服務器和大廳服務器的通訊的調試
2.學習其餘知識

今天主要在作大廳服務器和水滸傳的服務器的通訊
1.完成了大廳服務器對水滸傳服務器發送的報文的整理
2.完成了大廳服務器接收水滸傳遊戲服務器報文到來的相應功能

體會：在實際的作的過程當中慢慢明白了大廳服務器的結構和相關的功能。大廳服務器相對比較雜，和多方通訊，起控制和
報文轉發的功能。鏈接客戶端和遊戲服務器。

周志
這周主要在作大廳服務器和管理後臺客戶端，水滸傳遊戲服務器的功能
1.完成大廳服務器和管理後臺客戶端的報文通訊的功能，進行了功能的測試
2.基本完成大廳服務器和水滸傳服務器的通訊功能
3.整理了相關通訊的文檔

下週計劃1.和水滸傳服務器進行調試2.完善大廳服務器和遊戲服務器的通訊文檔3.學習新知識