OK，原型搞定～

从上月19号开工到现在，除去休息、跑亲戚、聚会的时间，其他时间都花在搞这个网站上。现在原型基本出来了，有些细节开学前每天花一定时间处理下应该就可以了。发现我依然是个优秀的美工，可写程序上除了精力充沛外基本没啥天分。犯了很多苦笑不得的错误。开发的一半时间在找自己整出的Bug，其他时间在不断地试着不同的解决方案。从Java整到了PHP；确定用PHP了吧，又换了两次IDE，从Eclipse到PhpED再到Netbeans。到开发临近完成，又开始了和图标、CSS之类的搏命。。。折腾。

Wordpress真是赞，如果不考虑性能方面的因素，基本可以满足一般网站的所有要求。丰富而清晰的权限设置；灵活的模板机制；丰富的插件主题资源；广大的用户群。。。这些都是其他的一些架构所难以比拟的。这次我的开发不过是对后台进行了一定剪裁，添加了一些功能；对模板进行了一定的修改；运用插件增添了一些功能。不过也有麻烦的地方，AJAX看着有点难懂；有些代码缺少注释；代码风格不大统一；有些设计过于优雅难以理解。。等等。也许是我PHP值太低的原因吧～

插件方面使用了GD Star Rating, Role-manager, WP-Pagenavi, WP-postviews, Search Everything；添了些花哨的功能，也省了不少的事情。模板是在Simple-X的基础上修改的，不过和重写基本没啥差别了。

POS开发

整个七八月，都在蓝竹做软件开发实习生，在TD的Application组。每天的事无非是学习、看文档，直到三周以后开始从两份代码拼出一个RF卡的demo。之后过了两周多，Michale让我在一个已有项目的基础上进行修改，以完成一个新的项目。最后项目完成不到80%的时候我应实习期满离开了团队。

开发是在STIP2.1(www.stip.org)上进行的，协议大体采用ISO8583标准。模块的调用采用了异步模式，再加上较为复杂的状态机模型，在编程和测试的时候都出现了很多问题，一步步解决下来，感觉自己在面对这种较为微观的问题时的能力有了一些的提高。

STIP是Small Terminal Interoperability Platform的简称，是在受限系统上进行JAVA开发的标准，目前主要应用在以下的领域，与基于C语言的开发相比，能较大地提高开发效率。
�� EFT-POS terminals(STIP EFT-POS Profile) �� ATM �� Payphones �� Parking Meters �� Utility Meters �� Mass transit terminals �� Vending Machines

STIP的架构大体如下图所示，我们Application组开发的就是Stiplet部分，也就是底层之上的应用：


STIP有专门用于界面描述的STIPML语言，类似于HTML。Stiplet的结构类似于MVC架构，其中Controller部分控制软件的状态和流程。STIP的事件模型如下图所示：

具体到项目的开发，虽然也进行总结，但由于保密协议，能贴的只有上面这些。开发中看了Michale和Command他们原来写的代码，学到了很多，也发现了自己太多的不足。很多地方只有靠扎实的基本功和清晰的思路才能完成，这些也只有在做过很多项目，经历了很多成功和失败后才能获得。

开发过程中我也发现了自己的一些缺点，总结下来由以下几点：
一是团队交流意识的欠缺，虽然在发现问题时能向老员工请教，但交流得还是不够，有些东西靠自己去发现会走很多弯路，费很多时间；在知识学习时尽量自己思考是不错的，但实际工作中有些问题还是要多多交流，对一些概念的理解上不能模糊。
二是基本功不扎实，具体体现在阅读和改写达三四千行的类和较为复杂的算法上。比如状态机和协议的解析，这些都需要有扎实的语言基础和清晰的思路。
三是在和客户沟通上应该及早发现问题，及时主动沟通，有些东西客户的文档里可能没有写，但在实际的情况下是相当重要的需求；有时用户的需求文档也许制作的流程并不规范，存在着一些相互矛盾的地方，这些都是要尤其注意的。

总得来说在蓝竹的实习学到了很多东西，也发现了自己的一些不足，不仅是在技术方面，也包括做事的态度，方式等等一些地方。谢谢帮助过我的Command、Michale和海啸。

毕业设计

一个月前离职返校，折腾了这么些日子，总算把毕业设计给鼓捣出来了。题目是《主题爬虫在WEB新闻聚合中的运用》，导师是沃焱老师。谢谢老师的信任，让我能结束了上海的实习再回广州完成毕设，不然两头奔波的日子是难以想象的。

整个一个月，我都窝在宿舍，除去做毕设，就是闲极无聊地打游戏。大学的最后一个月，过得着实不咋样。说是做毕业设计，其实和文科写论文没啥两样，由于时间有些紧，基本是边写论文边做毕设，说个好听点是文档先行，说个不好听点就是能不能鼓捣出这软件心里还没啥底。

论文排版话了一半的时间，用Latex，在清华的学位论文模板上进行了些修改，然后用了listing、beamer之类的宏包；总得来看效果还是可以的。只是写论文的过程中没有找到得心应手的工具，先是用CTEX集成的写作环境，之后又换了叫SciTE的编辑器，最后使用了Eclipse+Texlipse，用得还算顺手。之后还尝试了下在Linux下用Emacs写latex。只是原来写好的论文编译时出现了乱码，只得作罢。

总得来讲，一旦熟悉了几个基本的宏包，使用latex排论文、简历之类的东西能大大提高生产率。并能轻易获得专业的外观。后来估计也是因为这个原因，鼓捣出来的80p的论文评了优，还是有些得意的。

下面摘抄了些开题报告的内容：
当今网络信息资源急剧增长，面对这个海量、异构、半结构化的信息库时，人们常常会面临“信息过载、知识匮乏”的困窘，为了避免这种情况，我们需要以合适的方式对Web资源进行检索和呈现。Web知识发现是是几年内兴起的一个被广泛关注的研究课题。它是从Web数据中发现有用的知识和模式的过程，而如何高效地获取相应主题的信息也就成了Web知识发现至关重要的一步。

在寻找相关主题的页面时使用主题网络爬虫可以根据一定的网页分析算法过滤与主题无关的链接，可以提高抓取的准确性并减少计算资源的浪费。同样，随着网络信息的增长，人们为了及时方便地得到所关心的信息，希望从被动的上网查看新闻更新转变为主动地接收新闻信息。新闻聚合应运而生，而Atom和RSS是新闻聚合最流行的实现方式。

鉴于以上原因，我打算结合网络爬虫的主动搜索和新闻聚合的推送模式开发X-Info软件，首先利用主题爬虫定期从网络上收集新出现的相关主题的新闻网页，将其内容经过分析整理，构成按时间及主题相关度组织的新闻序列。同时对页面信息进行分析整理，得出可供统计的有用数据，并且提取出其中的部分信息生成符合RSS规范的聚合文件，让相关主题最新信息可以在普通的RSS阅读器中使用。

GSMC&Struts

从三月十号到现在，我在张江高科的GSMC（Grace Simiconductor Manufacturing Company）做软件工程师，分在系统咨询部的SCM组。两个月里为已有的系统增加了两个子模块，一是订单组合查询，二是查询定制。使用JSP开发，用到了Struts、XML；此外，由于系统使用了iBATIS，对它也进行了一些学习。开发过程中使用了Eclipse和一些数据库操作软件。由于涉及比较复杂的SQL查询，这方面的基本功也有了较大的提高。

开发过程中我也发现了自己的一些缺点，总得来讲有点工具崇拜，比如新版本的开发工具等等。实际上费了很多时间精力，对生产率基本没有提高，开发靠的还是基本功。

GSMC的气氛很好，没有太大项目的压力，员工也都爱玩，再加上不错的伙食和点心，工作得还是蛮开心的。

基于socket的简单语音聊天软件

基于socket的简单语音聊天软件是分布式的作业之一。下文摘抄了概要设计和详细设计的开头部分。

背景
软件名称：Xchat
开发者：04 双语 许一尊 200433099266
开发平台：JDK 1.5 + Eclipse3.3M6
本软件只采用了基本的Java sound API，即javax.sound中的内容，没有使用JMF和开源代码。

参考资料
《分布式计算原理与应用》
Java API
Java Sound Resources http://www.jsresources.org/apps/am.html

需求
1. 基于基本的Client/Server模式，实现一个text画板，提供一个多人的chat空间。在此模式下，每个人发出的message都通过server的中心控制，由server组播（multicast）给一个chat组的其他会话人。
2. 语音的录取、打包、传输、播放，从而将text chat空间变成了voice chat空间。
3. 通过server的中心控制实现会话的记录和交互式回放。

设计思路
客户端设计参考MVC模式，由一个核心控制模块处理语音发送接收、聊天信息和控制信号的发送接收、音频点播及界面的显示更新。
文本消息和控制信息合二为一，格式为：用户名>>>命令>>>参数
语聊信号通过建立音频管线截取语音包，直接广播到所以客户端，由客户端各自播放。客户端接收到控制信息时，提取出其中的用户名、命令和参数，如果该命令针对所有客户端，则执行该命令；如该命令针对特定用户，只有当用户检测到控制信息中的用户名项为其自身时才发生相应。
音频点播实现是由客户端通过有连接socket发送请求，服务器受到后发送确认信号，将文件以流的方式发送至客户端播放。

特殊性说明
由于只使用基本Java sound API，Java音频的一下局限性觉得了本系统一些特殊的设计：
首先，java平台的音频播放性能有限，当一次写入的数据过小是，声音容易出现断续的现象，而一次截取的包过大时，又会导致较大的延时。所以，必须在音频质量和声音延时上做出选择。最终的权衡结果是以1/4秒为单位截取声音，总的延时为0.5秒+网络延时，在局域网中，网络延时可以忽略不计，所以总的延时在0.5秒左右，可以接受。
其次，Java音频由于其性能问题，不能提供良好的混音效果，所以如两人同时发言，接收到声音的断续现象较为严重，如果多人同时发言，网络条件下4个音源的混音效果根本不能接受，所以本软件设定同一时间只能由一人发言，由一系列控制信号来达到所以客户端的同步。
其三，java保存音频文件方法较为单一，虽然可以通过InputStream保存成音频文件，但要预先制定音频文件的大小，这显然是不可实现的；所以唯一的办法就是在音频采集是直接保存成音频文件，在一次发言结束后上传到服务器，由于java本身没有音频合并的方法，所以音频文件的保存是以发言为单位的，点播时自然也只能以发言为单位。

系统结构
客户端

客户端设计参考MVC模式，由一个核心控制模块处理语音发送接收、聊天信息和控制信号的发送接收、音频点播及界面的显示更新。

服务器端

服务器端以一个控制中心为核心，处理客户端传来的消息和控制信号，执行相应操作并返回控制信号。

类图
客户端

a. 客户端以ClientAction为中心，该类处理界面相应并调用相应模块。由于ClientFram（界面类）的类中元素过于繁杂，在此图中已删除此类。
b. SocketMessageManager是文本消息处理的中心，建立messageSendThread和PacketReceivingThread处理消息包的发送和接收，受到消息包并提取其中信息后，将其交与ClientAction处理。
c. SoundCapture处理音频的截取和广播；SoundPlayer负责接收音频包并播放。
d. SoundRecoder负责讲语音保存在临时文件中，SoundSendThread负责发送该音频文件。
e. SoundRequestHelper与SoundRequest负责音频点播。

服务器端

a．服务器端以ChatServer为中心，处理客户端传来的消息和控制信号，并执行相应操作。
b．MessageServerThread负责调用RecervingThread，RecervingThread接收文本消息包并分离出其中的控制信号，交由ChatServer处理。
c．MulticastSendingThread负责相客户端广播聊天消息和控制信号。
d．SoundSaveServerThread负责处理客户端的保存聊天音频文件的请求，建立AudioSaveThread保存文件。
e．SoundRequestServerThread负责监听客户端的聊天记录点播请求，受到请求后，新建AudioPlayThread处理相应请求。

OA开发日记2

对开发环境渐渐熟练了，觉得weblogic这种模式在有较多因素可以复用的情况下，是能较大地提高效率的，开发一个模块可能体现不出来，但在开发多个相似模块时就能较大地节省时间，但前提还是要有比较好的面向对象的思想，也就是说如果在其它模式下能较多地考虑封装问题，自然，用weblogic那种基于控件的封装技术能较大地简化操作，提高效率；但如果没有封装的想法，只会加大工作量。不过workshop8.1的代码编辑是做得不好，但在使用过程中，手写代码的能力也有了一些提高，比原先细致了很多，毕竟不能过多地依赖IDE，也不是每个IDE都能做得eclipse的水准。

大体收尾在望，但不知细节上的修改要持续到什么时候，我是极不喜欢在一件事情上粘太久，在这个OA费了一个多月，早想停下干些别的。

OA开发日记1

几乎过了一个月了，这一月里，虽然进度不理想，总体而言比较失败，但还是学到了很多。现在，每天写挺多代码，已经觉得有点象个程序员了。基本是用weblogic的页面流开发的，和struts类似的一个东西，也是MVC模式，分得比较清楚，就数据库控件读数据，java控件进行逻辑整合，页面流控制导航，jsp显示。

内容显示都用的数据绑定，不用管连接池等细节，这是它的好处，但也丧失了很多灵活性，大量时间都耗费在细节的处理上，而且进行修改的话，很可能要在数据库控件，逻辑控件，页面流等几个地方修改；自然，为了用数据绑定，数据的初始化，更新就散布在页面流的个个角落，不清晰，必须照顾到多个元素。后来用rowSet控件，用xml传，简化了一些，不过还是有些麻烦。

有人说开发方式分"quick & dirty"和"clean & slow"两类，无奈，觉得我们现在是"slow & dirty",weblogic有些东西封装得很好，虽然看了教程就能用下，但要合理、有效率地使用，必须对J2EE有所了解。我现在基础太菜，还停留在对名词的了解，这次也是第一次写J2EE的程序。一知半解就照着教程做，自然低效。昨天看了一些SunOne的ppt，看了一些简介，清楚了一些，weblogic的那套东西和J2EE的体系是对应的，只是封装了一点细节，让人更好理解，从开发效率而言，并没有所宣传的那么好。

等这搞完了，我要认真看下J2EE，看看weblogic那套东西对应的开源实现。毕竟喜欢明了地看东西。之后还会看下设计模式，边看边总结下这次的经验教训，看能从失败中学到什么。实在不喜欢workshop的开发环境，有些东西都是在Notepad++里写好在拷过去，代码编辑环境比eclipse差太远，现在9.X已经迁到eclipse平台了，应该有大的提高。我们这次封装做得很失败，基本一个页面流对应几个数据库控件，控件里重复实现了一些方法，很多逻辑就直接塞到页面流里，一陀陀，难看。

基于j2me和B/S架构的新闻定制阅读平台

该软件是我们orz team参加广东省高校杯的比赛项目，最后该软件在比赛中获二等奖。由小牛、frienky和我开发，下文将摘抄部分概要设计和UML图。

系统功能设计
2．1 系统总体结构设计：
系统由手机软件和服务器端两部分组成
手机端提供新闻阅读、订阅等功能
服务器端提供两个主要功能：
让用户通过个人电脑上的浏览器对新闻进行定阅，这一部分采用传统意义上的B/S架构
让用户通过手机从网站上下载自己定义的新闻列表，这部分相当于传统意义上的C/S架构

2. 2子系统划分及描述：
手机端
手机端采用MVC模式划分功能模块
Model部分将数据读取，RMS操作，列表根新封装在各自模块内。
View部分定义各个功能界面。
Controller部分根据当前状态及用户的不同操作来显示界面、调用方法。
服务器端
服务器端由以下部分组成：
新闻订阅子系统
用户管理子系统
列表生成子系统（列表供手机下载）

系统逻辑设计
手机端
采用MVC模式，由Controller负责界面类和数据操作类的调用。手机端通过网站实行列表更新时，根据网站传回的对应帐户的新闻列表，写入手机本地存储结构。用户要浏览新闻时，根据新闻列表中记录的RSS地址，从互联网上读取新闻，并将新闻描述呈现给用户。用户要阅读具体的新闻时，系统再连到对应的网址，下载信息并滤去不重要的内容（如图片，动画等），然后将信息呈现给用户。
服务器端
用户通过浏览器对自己的目录和种子进行定制，系统将用户当前订阅的内容及目录结构写入数据库。当用户通过手机进行列表更新时，系统再根据对应用户数据库中的内容生成一个规范的，用xml描述的文件，传给手机。


开发环境搭建
针对手机端软件的开发，我们使用开源开发环境eclipse，配合j2me平台开发插件“WTK-Midlet EclipseMe”。该开发环境免费、灵活而强大，可以方便地进行代码编写，版本控制和重构。
针对服务器端的开发，我们搭建了Apache＋php＋mysql平台，该平台免费而且拥有不错的性能和丰富的系统函数，便于快速开发。开发中结合了所见即所得的网页编辑软件和php代码编写软件（eclipse + php开发插件）。在开发环境免费的条件下保证了快捷的效率。