写了几天的Online Judge，手上也算是有了感觉。这次相比第一次做的应该是好多了，在FleaPHP框架的帮助下，开发效率很高。尽管我并没有使用Zend Studio这样完善的IDE，而只是使用免费的编辑器Notepad++，但这似乎并没有带来什么困难。虽然没有采用TDD所提倡的自动化测试，但在编码过程中不停地手工测试也能把很多的Bug消灭在摇篮中，也不错。
另外，因为做的时候需要一个小功能——下拉列表的联动，居然让我提前学了一点Ajax。多亏了我以前了解一点儿Ajax，知道那东西有什么用。我一向认为平时的眼界开阔些总会有好处的，这次我就有收益了。同时，因为参考了FleaPHP自带的Ajax演示，还发现了以前所不知道的技术——JSON。本来是想采用JSON做Ajax服务端和客户端的通信的，但JSON只支持Unicode编码，对GB2312不支持，PHP的编码转换功能也不知道为什么总是无法正常工作。为这个小问题我郁闷了一天，最后我索性直接传HTML代码。却又发现IE的浏览器不支持select元素的innerHTML属性，查来查去得知这是IE的一个Bug，还是个很出名的Bug。郁闷，这么多年过去了，居然MS的人也不修复。无奈的我只好用Javascript来判断浏览器的类型，针对IE编写“特殊代码”。
Javascript、CSS、Ajax、HTML、PHP这些东西一但能信手拈来，写代码也就不觉得累了。对于这次做的OJ，在设计方面我认为还是可以的，代码的冗余比较低，模块的划分也比较清楚。感觉不好的地方是界面和数据处理的代码耦合得还不够松。我这次没有采用现成的模板引挚（比如smarty）可能是一个决策失误。一开始我认为PHP语言本身就是一个不错的模板引挚，但做着做着就发现界面部分总会把多余的复杂性成分引进来，所以做界面时心理感觉就不是很轻松，生怕给日后的维护工作带来麻烦。虽然采用的FleaPHP是一个MVC模式的框架，但我目前对MVC领悟得还不够，有时突然发现原来的设计有问题……
这时PHP框架的优势就体现出来了。设计不合理的地方在编码过程中更正也并不是很烦琐的事，我就小心地重构代码。不幸的是因为没有采用自动化单元测试的框架，每次重构完成之后都要进行枯燥的“手工测试”。没有采用TDD实在是一大遗憾。
目前题目管理的模块已经做完并整合进去了。接下来要实现的功能有测试数据的管理、用户信息的管理和整个Online Judge的设置模块。今天没有写OJ的代码，只是测试了一下已完成部分的效果，再者是因为我在想测试数据的管理模块应该怎么设计。我的初步想法是放弃在线编辑测试数据的功能，因为那样极其容易出错，而采用直接上传数据文件的方式——这样开发起来的难度也会小一些。但测试数据的制作仍然是个问题，它可不是那么容易做的。我想着是不是有必要开发一个在本机上运行的能自动生成测试数据的小程序，作为Online Judge的附属品？
这几天比较“另类”的工作是做了一个Banner，其实到目前为止我也就做了这一个图片。我真的不会使用图像处理软件吗？我自己是觉得自己缺少一些图形设计的细胞了。下图是Online Judge的管理员登录页面，那个简陋的Banner：
