大概前后花了两天半的时间，终于顺利完成了Anthill Pro平台的搭建。从查阅文档，到尝试搭建；从遇到很多莫名其妙的问题，到一一解决之后的首次Force Build成功，再到连续自动构建的顺利实现。整个过程，不能说饱偿辛酸，但也是颇费周折，不过其中的成就感也是蛮大的。并且，我还完成了一份看起来不错的文档，作为工作小结。
不过，Anthill Pro在有些地方还是不太让人满意的，比如文档滞后就是一个“严重”问题。另外，最新的beta版有几个bug，我在这上面折腾了好长时间，最后才发现是bug。
Anthill Pro可以做什么
Automate anything if possible，我想这大概是《Java Development With Ant》一书所带给我的最大影响了。让机器自动处理，流程自动运转，事情变得尽可能简单，这便是Ant的精髓。 (more…)
ant中的property有一个immutable特性，即：property一旦设置，就再不能更改。因为有了immutable，所以就产生了很多flexible，例如针对不同场景的环境配置。
考虑通常情况下的代码开发，属性被预先赋予缺省值。当我们需要根据环境，对这些已有缺省配置的属性进行再设定时，我们的设置行为是位于缺省设置之后的。因而这样的“property”是“mutable”的。而这样的配置往往也是深处于代码之中的，需要你对代码逻辑有所了解。有点类似于“白盒”。
回到ant，假如你很想让build.xml变得更灵活更易于复用，一些属性配置必然在提供缺省值的同时，也提供针对不同环境的再配置手段。假如你不希望因此而改动逻辑颇为复杂的build.xml（几百行的build文件对于一个稍大规模的project而言是家常便饭），假如你对build.xml的内部实现并没有半点兴趣（将它看作“黑盒”，你只关心那些有点像接口一样的可配置的property），那么property唯有immutable，才能做到“外部的再配置覆盖内部的缺省配置”。
这就是immutable property的幕后故事。
The steps that a team needs to cover when preparing a release usually include:
1 Writing the documentation
2 Writing any platform-specific bootstrap scripts, batch files, or programs
3 Writing any installer scripts, using installation tools
4 Checking all the source, documentation, and sundries into the source repository
5 Labeling the source in the source code repository
6 Running a clean build directly off the source repository image
7 Running the complete test suite
8 Packaging the software in a form suitable for distribution and installation
from Java Development with Ant
Teamwork里的成员彼此使用的词汇时常千差万别，不知道这种现象是否普遍。这是混乱之源，每每看到这样的现象心里总是会生起一股莫名的愤怒。有时想想真该花点时间来统一一下用词，最好能形成一个词汇表。不求包罗万象，至少也应该在一些关键词汇上有统一的说法，这样也便于形成风格一致的文档化的东西。
代码的风格需要规范，交流的词汇同样也需要规范。另外，组员们也应该尊重词汇表制定者的劳动成果，而不是无视其存在，照样我行我素，麻木不仁，否则就难免Babel塔的下场。
上周有个同事在向我抱怨功能测试用例说明书太枯燥，用例彼此间太孤立。这里面有我的原因，毕竟我还算是个新手，并且我也希望不要遗漏任何待测的功能细节。不过，这到是启发了我。也许作为测试人员，应该采用如下的测试方式：首先通读用例文档，以理解测试意图（当然，此前对待测系统的使用更是要熟悉）。然后，选用几个典型案例进行测试，而不是照着文档顺序式的逐个测试，几番折腾之后，大概有若干测试条目已经完成，或打勾或打叉。至于剩下的，则再进行针对性的测试。我想这样的话，或许同事的抱怨会少一些。
周末将第二篇文章发了出去，今天得到编辑的确认，终于可以轻舒一口气了。接下来就是等着杂志付印出版，或者是之前被告知文章内容有误。不过，一个多星期来的辛劳，不能说深入理解，总算也将Tiger的JSR166和JSR114了解了个大概。当然还包括.NET Framework的System.Threading，以及ADO.NET。自觉收获不小。撰文的好处就是可以逼迫自己认真对待。每一个技术细节都要仔细推敲，多方引证，否则就会冒毒害读者的大不韪。一番折腾之后，自己的认识与理解也有了长进，所学所知也更为牢固与扎实。
平台的比较历来就是极为艰深的。这需要当事人对平台有着长期实践与深刻理解，需要有高屋建瓴的眼光与认识。即使如此，也未必能引来下面满堂喝彩，想想真是吃力不讨好啊。尤其是需要从大跨度的角度，在有限篇幅里，说清楚自己的观点，这更是难上加难。好在我自知能力有限，更不想成为众矢之的。因而选择的是类库的两个局部：多线程和数据库访问，也算是审时度势吧。不过就算是局部，字数也依然超出了预算，可见要是来个统观全局的大手笔，恐怕真要将自己了陷进去。还好自己没有“上了”编辑的当:)
优秀的国外图书出版商，总是喜欢将一个系列的书，做成统一的风格。专业、考究而又严谨的设计，捧在手里，就让人感到一种亲近感和敬畏感，而对于书中正文，即使还未曾读过，对其质量就已经有七八成把握了。当然，很多外版书籍在引进过程中由于翻译的问题，也给国内读者造成了错误的不良印象。 (more…)
Powered by WordPress
