日志

今天继续在作聊天的小程序
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.学习新知识