“换汤不换药”的技术概念或者理念
或许这个标题不太能够贴切地表达我想说的意思，不过， 先暂且“挂羊头”在这里，下面是我们的“卖狗肉”时间，呵呵…
这几天脑子里老是有一些碎片，说多不多，说少也不少，但很不容易整理成一个话题来说， 正好前几天撞见JDK7发布的一些功能说明，确切的讲是JSR166y， 也就是新的Fork-Join框架，顺藤摸瓜又走了一遍这个主题的相关资料，脑袋里慢慢浮现出这篇“意识流”文字， Things never change…
NOTE
其实那，各位达人，尤其是年岁较长的，应该早就对我这篇文字要扯的东西有所感悟了，所以，我这里估计也是重新“编造”一篇文字而已，各位看官随兴观之即可。
当Ruby On Rails风风火火的在中国大地上宣传推广的时候，俺没有去赶那个风潮，只是默默地观望，顺便抽时间瞅瞅它的基本理念，也就是那个Convention Over Configuration， 然后就没有再耗费过多精力于其上，毕竟，没有应用的场合嘛。然后，08年底的时候，实在让那些RORer吵吵的心痒（或者是“心烦”）， 俺就把之前自己买的， 加上出版社送的有关Ruby和ROR的书都过了一遍，然后你猜我最后下了一个什么结论？ 没错，就是标题上那个“换汤不换药”，呵呵，语言形式换一下，同样的理念用不同的形式包装一下罢了， 不信？我们拿Java平台上的东西与ROR提供的东西对比一下萨：
- 都是基于buzzword模式MVC， 是吧？相应的MVC组件完成的使命一样吧？只不过是实现的语言或者说表现形式不同，Right?
- .jsp和.erb.rhtml又什么本质的不同嘛？没有，都是tmd的模板，还是表现形式不同而已。
- ROR里面的那些Helper是干啥的？跟JSP的custom tag能不能扯上关系？看官您心里比我有数。
- Convention Over Configuration， nnd, Junit刚出道的时候， 是不是需要我们把单元测试的方法名都以test开头？当然了， ROR把范围扩大得更大了…
blablabla… 诸如此类，呵呵， 这都是从某些侧面上来说， 现在让我们扩展一下…
刚才我提到Fork-join框架，让我们东拉西扯一把，来看一下这几个概念: * Divide-and-Conquer * Fork-and-Join * Map-and-Reduce * SEDA(Staged Event Driven Architecture)
呵呵，实际上， 前面三个概念都可以归属于divide-and-conquer的范畴之下，说白了，为了能够并行处理，“大家”都是将各种处理任务分解成合适的粒度，然后再分给不同的“人”去处理， 处理完了要是需要汇总啥的，那再收集一下进行后继处理， 小的ForkJoin， 大的MapReduce， 概莫如是。至于说SEDA，跟前面几个放在一起有些牵强，不过，也还说得过去啦， 如果说前面是横向分解，那SEDA只是纵向分解罢了，还是打散再想办法分工一下嘛。
再说说架构这东西， 看看各大著名网站的架构设计，Caches， Server Farms的身影从来就没有被埋没过，因为他们要完成的使命几乎是一样的， 虽然可能各个产品的实现语言啦，算法啦会有所差异。昨天看到袜子的blog上新添加了Terracotta的entry，正好再借这扯远点儿，Terracotta是个啥？ 用它的行话来说，那叫作NAM（network attached memory），这个理念应该早就有了把，Terracotta把它跟JVM一结合，哎~，新的秘密武器诞生了，呵呵 不过，还是没有超脱多少啊， 依然“抽象理念”的体现，依然是原来就有的系统架构，客户端跟服务器端之间的通信模式，并不少见吧？至于说Server端做Cluster， 跟你再其它架构里出于类似的原因（比如HA， Partition等因素考虑)所作的，又有什么本质上的不同哪？ 要么中央集权，要么平等自治，政治上这样的把戏不知道玩了多少年…
胡扯了这些，其实我也不知道自己要扯些什么， 有个成语叫“触类旁通”是吧？ 当我说我就知道Java这个平台的时候，请不要以为我就知道个Java编程语言，谢谢！（我没受刺激， 只是最后想起一个小片断，哈哈）
「福强私学」来一个？
「福强私学」, 一部沉淀了个人成长、技术与架构、组织与管理以及商业上的方法与心法的百科全书。
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
