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