一些心得,写下来时刻提醒自己。 1.实现优先 这个问题很明显:无论如何,你都要先做出来。技术,性能,优化甚至代码对齐等等技术人员才会想到的东西是不应该按这个标题序号去考虑的。 记住:即使一天拼出的只是一个杂碎,也比闷头做一个月的“优雅”产品要好得多。 2.以人为本 充分的衡量一下整个团队的能力,按照全队的综合能力去选型。项目负责人的任务就是把项目拆散了平摊到每个适合的人的头上。 记住:你必须详细的了解团队中的每一个人,说不定一个闷臊的程序员恰恰成为了最好的客户沟通专家...... 3.demo驱动开发 天下最“敏捷”的事情莫过于让用户经常能知道你的想法。那么正式开始之前都给他们做个dem ...
(所谓伪问题,就是说这个问题没有意义.......) ozz所说的平台,应该是一种实现平台,也就是说基于这个平台的业务是由平台提供的固定的功能模块组合而成。新业务的实现,是基于此种平台模块的二次开发过程.. 而lz所说的平台,应该是一种抽象平台,只制定业务处理规则,而不管其实现。这样的平台更强调一种方法论。新业务的实现,是基于扩充或者替换平台自身来实现.. 大家说得其实都对,对象不同而以..... 我还是对抽象平台比较看好的,只不过我认为这个东西的工业价值是远远大于商业价值的。抽象平台的优点就是规范了技术的实现,规范了分工,但其技术上的实现却没能有任何简化。如果抽象平台过多的涉及了实现 ...
SOA很流行,但是SOA并不确定,事实上,我们也不需要一个确定的SOA 大厂有自己的SOA,可是SOA并不只是这些。我们学习SOA最重要的就是用service的方式去思考问题。 1.SOA强迫我们去思考服务的复用性,通过复用性去正确的划分粒度。 2.SOA强迫我们时刻去想着用户,因为每个服务都可能会跟用户直接交互。 3.SOA强迫我们更加的模块化,让我们更多的考虑分布环境下各模块的协同问题。 4.SOA强迫我们一步步地去考虑,然后用流程把各个步骤连接起来。 掌握了SOA,大厂的方案就只是一个选择,或许,我们自己的实现会更加的SOA. SOA其实很古老,ls|more 都闪耀着SOA的光 ...
女儿的出生中断了一段时间的开发。现在就高性能网络处理方式的问题做个总结 所谓高性能,我们这里指在大量并发连接时还有相当高的请求处理速度。提高单连接的请求处理速度这里不讨论。我们这里采用 p=处理速度/连接数 作为衡量性能的指标。 java中最传统的socket处理方法是同步socket,每个连接建立一个线程阻塞等待数据的到达,这种方式很适合于低连接数的应用,但是在大量连接时会由于频繁的线程间切换导致性能大幅降低。这种方式下只能优化线程创建时间,也就是使用线程池。 jdk1.4中引入了nio处理网络连接,实际上,sun对于nio的实现也仅仅是使用了select(见jdk源代码)。socke ...
目标:取代b/s结构,提供增强的界面以及通信能力。并提供主动式和随动式支持。专用于企业OA,MIS,呼叫中心以及各种管理系统。 要求:全可视化设计,0代码编程。支持工作流,模板,可替换式界面支持。
1.提供一个统一的分布式平台。 2.提供统一的数据/模块/设备接口。 3.提供优化的数据/语音/视频/以及特殊应用的支持 4.易于管理和扩展。并提供相应界面。
1.每个模块都必须自维护,并可手动装载卸载 2.模块之间通过总线进行交互,所有模块层级一致,但是可以在请求中规定模块执行路径。 3.模块用URI形式标明自身位置。 4.模块由管理程序载入时决定其权限和可见度。 5.总线使用二进制标准传输对象。并且跨语言和平台。
2007-11-16

境界的概念

关键字: 方法
次序: 练精化气,练气化神,练神还虚,练虚合道 境界: 看山是山,看山不识山,看山还是山
2007-10-23

操作系统眼中的java

关键字: java
操作系统眼中的java: 1.这小子是个光吃不吐的货,只见他吃掉内存,何时见他吐过?美其名曰有垃圾收集,可是收集了也不见还给我一点半点。 2.这家伙算是个最弱的虚拟机了,看人家vmware,啥都能虚拟一套出来,里面还能装个系统。这东西却只能跑它的class,性能还差...... 3.真是个倒霉孩子,俺们最先进的功能这家伙都用不上,还抱着老掉牙的系统结构支撑,如同高速公路跑拖拉机,真是难为它了。幸好还能用JNI牌平板拖车来运他。 4.这小子一生下来就想淘汰c之流的前辈,也不想想他自己是拿什么写的,做vm,不能忘本阿! 5.框架,你说框架?难道说的不是回字的四种写法? 6.为什么主推j ...
近期在开发一个基于java的应用服务器。目标是在一台机器上能够支持尽量多的并发连接和可针对负载自动调整运行期资源占用量的多应用支持。 开始的想法很简单,参考jetty,tomcat和resin,能用他们的就用他们的。于是选定了jetty6(由于其结构清晰,可扩展性强)作为基础在其之上进行扩展。先作的是“可针对负载自动调整运行期资源占用量的多应用支持”部分,很顺利,新写了个jetty的contexthandler,然后建立一个线程来监视所有context的负载情况并管理加载、卸载就可以了。 可是在作压力测试的时候问题出来了,即便是空负载,系统的性能相对连接的并发数呈现指数级降低。1000并发 ...
timerri
搜索本博客
最近加入圈子
存档
最新评论