timerri 了解规则，掌握规则，制定规则 http://timerri.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 项目中需要时刻提醒自己的六件事 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/150017  发表时间: 2007年12月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

一些心得，写下来时刻提醒自己。

1.实现优先
这个问题很明显：无论如何，你都要先做出来。技术，性能，优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。
记住：即使一天拼出的只是一个杂碎，也比闷头做一个月的“优雅”产品要好得多。

2.以人为本
充分的衡量一下整个团队的能力，按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。
记住：你必须详细的了解团队中的每一个人，说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家......

3.demo驱动开发
天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个demo，哪怕功能都是伪造的......或许你会发现其实客户要求的比你想的要少得多....
记住：让客户看到，永远比让客户听到要好

4.每天都是一个成功
与其每天气急败坏的催促手下加快开发进度，不如建立多个短期目标，每个目标都实现了，你就会发现自己腰不酸了，手下腿不痛了，客户一口气上五楼，不喘气了。
记住：让团队不被压力压倒是每一个管理者最重要的责任。

5.量力而为
如果你在上一条里的目标每个都是难以实现的，团队的士气或许很快就会降到谷底...项目的失败是可预期的。如果客户的要求也超出了团队的能力，放弃绝对比硬撑要值。
记住：别妄图在项目中保持120%的开发能力，你或许会在项目完成的前一天倒下...

6.横向储备
只要有时间，一定要留意团队中缺少的知识和人才。没准下个项目就会用到。
记住：项目总是会照顾那些有准备的人...
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 21 Dec 2007 16:27:23 +0800 http://timerri.javaeye.com/blog/150017 http://timerri.javaeye.com/blog/150017 回复: 说说业务平台这件事 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/149648  发表时间: 2007年12月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

（所谓伪问题，就是说这个问题没有意义.......）

ozz所说的平台，应该是一种实现平台，也就是说基于这个平台的业务是由平台提供的固定的功能模块组合而成。新业务的实现，是基于此种平台模块的二次开发过程..

而lz所说的平台，应该是一种抽象平台，只制定业务处理规则，而不管其实现。这样的平台更强调一种方法论。新业务的实现，是基于扩充或者替换平台自身来实现..

大家说得其实都对，对象不同而以.....

我还是对抽象平台比较看好的，只不过我认为这个东西的工业价值是远远大于商业价值的。抽象平台的优点就是规范了技术的实现，规范了分工，但其技术上的实现却没能有任何简化。如果抽象平台过多的涉及了实现，那么实现平台出现的问题，也会出现在这种抽象平台上。呵呵，这就是ozz所说的抽象与实现的矛盾。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 20 Dec 2007 11:38:27 +0800 http://timerri.javaeye.com/blog/149648 http://timerri.javaeye.com/blog/149648 用service的方式去思考问题。 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/148934  发表时间: 2007年12月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

SOA很流行，但是SOA并不确定，事实上，我们也不需要一个确定的SOA

大厂有自己的SOA,可是SOA并不只是这些。我们学习SOA最重要的就是用service的方式去思考问题。

1.SOA强迫我们去思考服务的复用性，通过复用性去正确的划分粒度。
2.SOA强迫我们时刻去想着用户，因为每个服务都可能会跟用户直接交互。
3.SOA强迫我们更加的模块化，让我们更多的考虑分布环境下各模块的协同问题。
4.SOA强迫我们一步步地去考虑，然后用流程把各个步骤连接起来。

掌握了SOA,大厂的方案就只是一个选择，或许，我们自己的实现会更加的SOA.

SOA其实很古老，ls|more 都闪耀着SOA的光辉....
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 17 Dec 2007 17:21:22 +0800 http://timerri.javaeye.com/blog/148934 http://timerri.javaeye.com/blog/148934 关于高性能网络应用的研究总结 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/148902  发表时间: 2007年12月17日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

女儿的出生中断了一段时间的开发。现在就高性能网络处理方式的问题做个总结

所谓高性能，我们这里指在大量并发连接时还有相当高的请求处理速度。提高单连接的请求处理速度这里不讨论。我们这里采用 p=处理速度/连接数 作为衡量性能的指标。

java中最传统的socket处理方法是同步socket,每个连接建立一个线程阻塞等待数据的到达，这种方式很适合于低连接数的应用，但是在大量连接时会由于频繁的线程间切换导致性能大幅降低。这种方式下只能优化线程创建时间，也就是使用线程池。

jdk1.4中引入了nio处理网络连接，实际上，sun对于nio的实现也仅仅是使用了select(见jdk源代码)。socket函数中的select实现了一个基于事件的解决方案，可以只用一个线程去等待多个socket事件的发生，在一定程度上解决了多线程切换带来的性能降低。它的缺点是一次只能处理一个事件，而且其监视的句柄也有限制。实际使用中它对性能的提升也非常有限。(winsock和bsd的select区别这里也暂不讨论)

纯java中能够使用的方法基本上只有上述两种，所以如果选择使用纯java，是很难应付高性能的应用的。所幸我们还有JNI.....

超越了java,我们不得不谈到本地平台的区别上来.....

windows平台下比较先进的模型是完成端口+重叠IO,完成端口可以看作增强版的select，它可以支持更大量的句柄，并且可以一次返回多个事件。重叠IO是另一个强大的工具，它允许用户异步的进行通讯操作，而且还能允许用户自己管理传输缓冲。使用这二者的组合，完全可以把所有端口的所有传输数据分成一个个等长的小块，让cpu进行基于定长数据块的处理。看起来像什么？是不是更像流水线？这种方式可以处理大量的连接而不会使性能降低很多。

linux平台下使用的是epoll,功能很像完成端口，也支持一次返回多个事件。只不过没有重叠io的支持，不知道这种模型赶不赶得上windows下的方案？

（补充一点：jdk1.5 update9 之后，linux下的nio已经支持了epoll)

无论是完成端口还是epoll,我们的程序中都不再需要大量的线程了，但是仅仅使用一个线程完成所有请求的处理这种方式也是不可取的，因为很多情况下，系统都可能会对某些资源进行等待，这样就会降低综合的连接处理速度。比较好的方法是按需使用线程，在不大可能出现等待的逻辑中使用单独线程完成，在可能出现等待的逻辑中建立少量线程用多条流水线的处理方式去完成任务。

使用完成端口或者epoll的解决方案，java在大连接处理上的能力将会大大提高，只不过这时候java就不会再成为项目中的主导，看起来会更像一个嵌入式的解释器...
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 17 Dec 2007 15:59:35 +0800 http://timerri.javaeye.com/blog/148902 http://timerri.javaeye.com/blog/148902 通用UI框架 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/148302  发表时间: 2007年12月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

目标：取代b/s结构，提供增强的界面以及通信能力。并提供主动式和随动式支持。专用于企业OA,MIS,呼叫中心以及各种管理系统。

要求：全可视化设计，0代码编程。支持工作流，模板，可替换式界面支持。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 14 Dec 2007 12:14:34 +0800 http://timerri.javaeye.com/blog/148302 http://timerri.javaeye.com/blog/148302 CUBIK的作用 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/148295  发表时间: 2007年12月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1.提供一个统一的分布式平台。
2.提供统一的数据/模块/设备接口。
3.提供优化的数据/语音/视频/以及特殊应用的支持
4.易于管理和扩展。并提供相应界面。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 14 Dec 2007 11:46:15 +0800 http://timerri.javaeye.com/blog/148295 http://timerri.javaeye.com/blog/148295 模块化设计需求 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/148293  发表时间: 2007年12月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

1.每个模块都必须自维护，并可手动装载卸载
2.模块之间通过总线进行交互，所有模块层级一致，但是可以在请求中规定模块执行路径。
3.模块用URI形式标明自身位置。
4.模块由管理程序载入时决定其权限和可见度。
5.总线使用二进制标准传输对象。并且跨语言和平台。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 14 Dec 2007 11:41:44 +0800 http://timerri.javaeye.com/blog/148293 http://timerri.javaeye.com/blog/148293 境界的概念 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/141283  发表时间: 2007年11月16日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

次序：

练精化气，练气化神，练神还虚，练虚合道

境界：

看山是山，看山不识山，看山还是山


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 16 Nov 2007 20:56:10 +0800 http://timerri.javaeye.com/blog/141283 http://timerri.javaeye.com/blog/141283 操作系统眼中的java timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/134627  发表时间: 2007年10月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

操作系统眼中的java:

1.这小子是个光吃不吐的货,只见他吃掉内存，何时见他吐过？美其名曰有垃圾收集，可是收集了也不见还给我一点半点。

2.这家伙算是个最弱的虚拟机了，看人家vmware，啥都能虚拟一套出来，里面还能装个系统。这东西却只能跑它的class,性能还差......

3.真是个倒霉孩子，俺们最先进的功能这家伙都用不上，还抱着老掉牙的系统结构支撑，如同高速公路跑拖拉机，真是难为它了。幸好还能用JNI牌平板拖车来运他。

4.这小子一生下来就想淘汰c之流的前辈，也不想想他自己是拿什么写的，做vm,不能忘本阿！

5.框架，你说框架？难道说的不是回字的四种写法？

6.为什么主推java的都是ibm,sun之流作服务器硬件的厂家？因为对于他们来说，越慢越值钱！


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 23 Oct 2007 00:01:26 +0800 http://timerri.javaeye.com/blog/134627 http://timerri.javaeye.com/blog/134627 开发高性能的j2ee应用服务器，或许只有舍弃掉现有servlet架构 timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/130798  发表时间: 2007年10月10日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

近期在开发一个基于java的应用服务器。目标是在一台机器上能够支持尽量多的并发连接和可针对负载自动调整运行期资源占用量的多应用支持。

开始的想法很简单，参考jetty,tomcat和resin，能用他们的就用他们的。于是选定了jetty6（由于其结构清晰，可扩展性强）作为基础在其之上进行扩展。先作的是“可针对负载自动调整运行期资源占用量的多应用支持”部分，很顺利，新写了个jetty的contexthandler，然后建立一个线程来监视所有context的负载情况并管理加载、卸载就可以了。

可是在作压力测试的时候问题出来了，即便是空负载，系统的性能相对连接的并发数呈现指数级降低。1000并发条连接下，每秒处理请求数仅仅只有30个不到。而在1个连接下，每秒处理请求数能达到1000个。本以为是jetty的网络部分有问题，可是测试了tomcat,resin后，发现他们在同样连接条件下的性能都差不多。为了比较，我又测试了一下iis的性能，可是结果让我很吃惊，1000连接下iis每秒能处理的请求数是1200个......

看来问题相当严重，我不得不静下心来研究问题出现的根源。

一切的矛头都指向了j2ee请求处理的架构~~~~~~~

众所周知，j2ee应用服务器必须实现javax.servlet包下面的接口，简略来说，主要就是Request,Response和Servlet接口。所有的请求都会通过Servlet.service(request,response)进行处理。

换句话说，就是应用服务器必须准备好了request和response才能调用servlet去处理。这是啥子意思？这就是个典型的多线程处理架构。每个连接一个线程，每个线程去处理自己拿到的请求。

可是当高并发的时候，还能给每个request开个线程去处理么？大量的线程足够拖垮你的服务器。

而现在网络高并发开发已经不再是一个线程对应一个连接的时代了。现在高效的是异步并按块处理数据。windows下使用完成端口，linux下使用epoll,都是接到一个数据块就直接处理一个数据块，最多开少数几个工作线程去处理数据就足够了。这才是高效的处理方式。

javax.servlet在结构上根本就不支持异步处理的方式，也不支持按块处理。而多数java应用服务器为了支持javax.servlet，也不得不使用多线程的处理架构。

最近的趋势是使用nio做网络处理，nio理论上的确能提高并发处理性能，但是为了javax.servlet,后面还是挂了个线程池去每个请求分配一个线程。所以性能还是无法有质的提高。

痛定思痛，javax.servlet的结构已经不适合作高性能的应用服务器了。既然不适合，那我可能就只有抛弃掉它。虽然前面的道路可能会很艰苦.......

作为替代方案，我计划采用异步型接口重写应用服务器架构，网络部分先用isapi直接使用iis（linux下计划用lighttpd的mod）.request,response必须要能够分数据块在用户扩展中进行处理。

现在还没有完整的方案，很多事情要边做边测试才能知道。希望工作量没有大到无法承受。

希望听到朋友们的建议，或者不需要那么大动干戈....欢迎指教
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 10 Oct 2007 15:44:45 +0800 http://timerri.javaeye.com/blog/130798 http://timerri.javaeye.com/blog/130798 socketchannel性能不如serversocket? timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/127835  发表时间: 2007年09月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今天在扩展jetty 6.1的时候发现在jetty中使用socketchannel 居然性能还不如用serversocket

我用的是微软的web application stress tool.

先用用20个线程并发访问，

serversocket 能达到1000次访问/秒
socketchannel 只能达到600次访问/秒

当我把测试线程数增加到200个时
他们都下降到了20次访问/秒

我也测试了resin,数据跟使用serversocket的相差不大。

现在还不知道到底是jetty的问题还是socketchannel的问题。还需要再研究
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 28 Sep 2007 11:14:52 +0800 http://timerri.javaeye.com/blog/127835 http://timerri.javaeye.com/blog/127835 ok，TDD只是一个coder的工具! timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/126249  发表时间: 2007年09月23日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

TDD热度在上升，我这里给它降降温
——"TDD只是一个coder的工具!"

不得不承认，TDD是一种比较一石二鸟的思想，将需求与测试统一，即能严格满足需求，又能对实现进行测试。可是，在能TDD之前，和TDD之后，还有太多的事情要做....

通常，一个开发周期至少要包括:分析，设计，编码，测试4个步骤，其中，分析和设计阶段将会占用一个项目中的大部分时间（这里我不想讨论毫无技术含量的重复开发），可是在分析和设计阶段，tdd基本是毫无用处的。tdd只有在设计的后期，基本完成至少精确到接口的设计后，才能依赖于设计进行测试驱动的编码。而且，作为设计人员，是很难在这个阶段进行测试驱动编码工作，因为没有人能保证第一次设计的粒度能直接精确到可以编写测试驱动的地步（你说你能保证？ok,地球太危险，您还是回到火星去吧...）。最后，测试驱动就只能由进行实现的coder编写。。

在coder们惊叹tdd在数十次迭代后居然给他节省了那么多时间的时候（或者很后悔在一个十分简单的项目里用了tdd的时候），很不幸，真正的测试要开始了。（如果你还认为tdd后不再需要测试的话，您最好期待您的客户都是冤大头）

对于测试最正确的方法，是从需求开始，这个阶段需要回顾需求（如果有专门的测试部门的话，这个阶段会和开发部门的需求分析一起开始。），根据需求写出测试用例，根据测试用例写出测试代码或者手动进行测试。在这个阶段，测试驱动的代码能用么？当然是不行的，测试人员必须验证项目是否直接符合需求。如果你想说tdd代码就代表了需求，那么谁来保证你的tdd代码就真正能代表需求？软件测试不是要测试你的代码质量，而是要保证项目质量！

在掐头去尾以后，tdd能够服务于项目的时间只剩下了code阶段。可惜，在这个阶段，无论是测试驱动code,还是code完再写测试，已经没有本质的区别了（你要硬说有区别，那也只是先有鸡和先有蛋的区别，没什么值得讨论的。），换句话来说，你是想用tdd还是做好单元测试，都是随你的意，喜欢哪种就用哪种。

最后加上一句：没有最好的方法，只有最好的人！
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sun, 23 Sep 2007 02:11:26 +0800 http://timerri.javaeye.com/blog/126249 http://timerri.javaeye.com/blog/126249 oodb该是什么样~~~ timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/126007  发表时间: 2007年09月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前期在用db4o作小型web项目的数据库。感想如下：

1.使用起来很方便，基本上储存用set就可以了，适合任意对象，就是插入速度有点慢。
2.检索比较麻烦，语法感觉比较复杂。特别是复杂的检索
3.配置起来还算简单，也有索引。
4.我大量的使用了ext().getBYID()之类的方法直接得到对象。
5.getById后必须active这点比较无聊。
6.用id取对象的话，就一定不能碎片整理，否则id会变

总的来说，经过再次包装后，db4o已经比较适合我使用了。它小巧，速度还行，还有一定的缓存机制，确实很适合数据量不大的小型web应用。不过另外的问题也有，比如说现在的6.3就不支持6.1的文件了。

再说一下我对oo数据库的需求。
1.需要一个直接定位对象的方法，用id或者命名都可以，根据id直接取出对象速度一定要快，最好为常数。
2.外置索引，并且独立。也就是说索引和数据库本身解耦，可以根据需要随意选择索引的实现，而不会影响数据库。这里可能需要数据库本身提供触发器的接口。其实彻底分开也没什么不可以的，由应用本身去协调索引和数据库的关系。
3.事务，其实也就是提供一个缓存机制处理对象的储存。很好实现
4.储存方式可扩展，不再仅限于文件。
5.使用内存量可配置

大家有什么看法？
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 21 Sep 2007 17:38:53 +0800 http://timerri.javaeye.com/blog/126007 http://timerri.javaeye.com/blog/126007 表现层该由谁来做！？ timerri 作者: timerri  链接：http://timerri.javaeye.com/blog/125881  发表时间: 2007年09月21日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

发言要等3天阿,终于等过了阿.....

表现层该由谁来做！？程序员，还是美工，还是会美工的程序员，还是会程序的美工？

现在在java中流行的表现层处理方法，基本分为以下几种：
1.用jsp的tag
2.velocity之类的脚本
3.javascript填充数据

从技术上讲，可能大部分程序员都会习惯第一种方法，众多的框架也在用第一种方法扩展自己的表现层能力。比如struts等等。可是大家用了这个以后有没有一种感觉，那就是页面要改起来太难了，特别是给一般的美工进行修饰的话，美工基本拿那些tag没有办法。所以，最后的整合工作还是落在了程序员的头上。可是要找到一个审美观优秀的程序员，基本跟找到一个会写程序的美工一样难。呵呵，产品的结果就不必多说了，一般只能达到“看得过去”这个档次。

用velocity之类的，也同样有第一个方面的问题，虽然语法较为简单，但是毕竟是一门新的语法。要美工掌握的话，还是需要培训。

用javascript可能就会比较灵活，基本上页面如何变化都能适应，不过问题也是明显的，只要客户端不允许运行javascipt，或者客户端使用怪异的浏览器，表现层就彻底歇菜。

我们现在项目中采用的方法，是仅在jsp中使用el和jstl的部分语法，这样美工很轻松就能掌握，美工也能用所见即所得的工具（frontpage或dreamweaver）直接进行页面编辑。而逻辑部分我们使用了类似struts的action来进行处理（实际上，我们有一个自己的框架，包括orm,rro，json等功能,而且基本不用配置）。这样，美工和程序员只要约定表单内容，工作基本上就可以完全分开，各做各的。最后只需要用美工的页面覆盖程序员自己的测试页面，作一遍整合测试就可以了。

不知道各位在这方面是如何协调专职美工和程序员的工作呢？
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 21 Sep 2007 11:12:07 +0800 http://timerri.javaeye.com/blog/125881 http://timerri.javaeye.com/blog/125881