仅一年,近半加密货币的“ICO”项目已死

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://csdnnews.blog.csdn.net/article/details/79777590

点击上方“CSDN”,选择“置顶公众号”

关键时刻,第一时间送达!

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

去年一年,加密货币爆炸式的增长引发了市场的大规模上涨,因此去年毫无疑问是比特币之年。一些投机者通过一个名为“ICO”(首币发行,区块链术语,类似于股市的首次公开发行(IPO)概念)的轻度管制流程进一步加大投资加密货币项目,在此过程中,一些初创公司通过出售自己的密码令牌来筹集资金。

“财富”杂志密切关注着 ICO 但对其保持怀疑态度,认为 ICO 从一开始就为诈骗做好了准备。事实证明,怀疑的理由是有迹可循的:加密货币新闻网站Bitcoin.com 对去年的 ICO 进行了调查,发现由 TokenData 跟踪的 902 次 ICO 中,在筹集资金之前就有142次失败,另有276次在筹款后失败。

失败率高达 46%,并且实际上事实更为残酷。Bitcoin.com 发现另有113个称为“半失败”的项目,因为它们的团队和社区已经消失。如果加上这些的话,总的失败率则高达59%。Bitcoin.com 表示,从2017年起,失败项目涉及的总资金为2.33亿美元。

尽管失败率很高且浪费了大量资金,但是对于那些熟悉初创公司的人来说或许并不认为这有什么。由传统风险机构投资的所有初创公司中,失败率高达75%,并且其中30%至40%的企业会损失掉投资者的所有资金。在美国的所有初创公司中,有20%的公司活不过第一年。

ICO 明显超过了这个百分比,但在这样一个新兴行业中似乎不足为奇。尽管如此,有两项发现依然令人感到不安。

首先,2017年的 ICO 狂热到今年下半年才基本稳定,ICO 的失败数量在数月之内就已经出现了不成比例的情况。其次,并非所有被关闭的项目都是真正的“失败”——许多人根本没有生产任何产品,而且很可能从未打算过要生产产品。有些甚至可以说是“诈骗”,其创始人筹集到资金就消失,而另一些人用比特币网站的话来说就是“慢慢地变得模糊不清”,但却有着同样的恶意。

除了榨取原始数据之外,Bitcoin.com 花时间筛选了所有违反承诺的数字遗骸。他们的发现令人非常失望:数字坟场、被遗弃的 Twitter 账户、空电报组织、不再托管的网站、不再维护的社区。ICO 短期不会消失,假设你想要投资一个,那么你需要做足功课并非常谨慎。

原文:http://fortune.com/2018/02/25/cryptocurrency-ico-collapse/

作者:DAVID Z. MORRIS

译者:安翔

————— 推荐阅读 —————

点击图片即可阅读

640?wx_fmt=png

640?wx_fmt=png

640?wx_fmt=png

640?wx_fmt=jpeg640?wx_fmt=gif

展开阅读全文

数据挖掘已死

02-12

数据挖掘已死,而预测分析将长期存在rnrn 为什么数据挖掘会死去呢?它死于一颗破碎的心,死于一次次的失望。除了受到严酷经济形势的影响之外,另外一个数据挖掘技术没有达成预期效果的原因是因为“数据挖掘“是一个含糊不明确的术语。其与数据特征化、数据仓库,甚至一些数据分析的方法比如联机分析处理(OLAP)和企业分析系统都存在着彼此的重叠。当使用特征化技术取得了几次成功之后。随之吸引了大量的模仿者,提供各种解决方案和软件,但是他们最终都没有实现最初的许诺。这些许诺基本上都是利用采矿作为比喻,仿佛赚钱真的是一件很容易的事情。这也最终导致了提供商提供的信息经常是让人迷惑的,出版商的信息经常是夸张的,而最终用户经常是失望的。rn 数据挖掘应该被重新定义为“预测分析“。其中的区别如下:rn rn 数据仓库 经典的数据挖掘 预测分析rn 查询和报表功能(SQL) 统计分析 预测性算法rn 静态分析 连续性变化 同时包含不连续的变化rn 描述当前和过去 预测过去 预测未来rn 形成假设 验证假设 发现和验证假设rnrn·预测性的,而不仅仅是描述性:对成TB的帐务数据进行扫描,然后发现其中的一些错误信息,这个就被描述成了数据挖掘。但是,它仅仅是描述性的,而不具有预测功能。当一个模型可以根据变量之间的相关性(因果分析)预测错误的时候,那么就可以根据预测结果采取相应的行动了(这个时候就具有了预测性)。请注意,在该模型中包含了一个“相关性“,而不是“因果关系“,虽然我们经常可以从中推导出因果关系。例如,施乐公司使用Oracle的数据挖掘软件进行聚集分析,然后建立了预测模型来分析使用特征历史,最终来预测图像拷贝组件故障的情况。那么其就可以利用该信息提前进行维护工作。rn·停止预测过去,开始预测未来: 在数据仓库上进行的市场趋势分析,OLAP和其他分析程序都会根据了解用户购买和使用的情况(产品或者服务),然后从过去拉一根直线到未来,以此外推出一个趋势。这个也可以被称为数据挖掘。您可以会说这里已经对未来做出了预测,因为它描述了一些未来将要发生的事情。但是,更准备的来说,应该是对过去做出了描述,然后映射到了未来。在分析过程中,并没有包含预测。更进一步来说,这里使用的数据挖掘只适用于连续的变化—将趋势从过去延伸到将来。预测分析同样也可以从模型中产生评分,并且其适用于离散变化的情况。这个在“黑盒“类型函数的时候尤其如此,例如神经元网络和遗传算法。在OLAP,查询和报表中很少将独立和依赖变量联系起来,但是这却是预测分析的本质。rn·发现假设,而不仅仅是进行验证:最后,数据挖掘区别于预测分析的地方还在于假设的形成和验证。例如,一个假设是人们拖欠贷款是因为高负债率。一旦分析师利用他的思考和想象力形成这个假设之后,利用OLAP分析就可以在数据立方体中对这个假设进行验证。预测分析的不同点在于可以寻找数据中可用于形成假设的模型。分析师可能没有考虑到年龄也是形成风险的一个因素,但是数据中的模式暗示了这可能是一个值得深入分析的假设。rn 为什么单独的数据不能称为知识的一个原因是,因为其缺乏结构,组织,方向,一致性。就好像预测模型没有数据的支持,那只能是个空;数据没有一个统一的模型,那也是没有意义的。用户必须熟悉三个领域的知识:业务的细节,数据采集和模型创建。同时我们必须明白,理解具体的含义是业务上的任务,而不是统计上的工作。根据如上的理解,当选择预测分析工具的时候,我们应该根据具体的任务来定:客户推荐,交叉销售,向上销售,个性化,发展忠诚度,流失分析,预测,需求计划,库存缩减,品牌推广和市场动态分析。rnrn 论坛

程序员已死

05-10

很多人说中国有个优势,就是人力成本低。rnrn但是这是一个彻底的谎言!!!软件产业是智力的产业,是创新的产业。国内的教育基础设施太落后了!rnrn国内一个优秀的程序员培养成本比国外,比如美国要高好几倍。首先,国内的高校看似收费低廉,但是都是彻头彻尾的垃圾学校。rnrn说他们提供了劣质的教育都是夸奖他们,简直是反教育的。拿计算机科学和软件工程两大学科来说,课程设置僵化,教师队伍平庸,教学内容落后是普遍现象。rnrn在美国,高校教授的工资大约是20~50万美元/年,相比较软件开发岗位,相当有吸引力。所以高校可以从优秀的企业聘用顶尖人才来授课。相比较而言,国内高校的师资队伍往往都是被企业挑剩的三流队伍。这些人自己都搞不懂软件开发是怎么回事,教学质量可想而知。还有些老教师,自身知识结构老化不说,还霸占了位置,导致过时的课程删不掉,新的课程开不了。rnrn如果把教育看成培养人才的工厂,那么这条生产线上生产的次品率高达90%。的确有些人才脱颖而出,但是他们自学和单打独斗,学习难度比国外的学生高很多。结果是现在高端人才大多是海龟或者被企业再培养的。rnrn海龟和企业再培养的成本是高昂的,留学生的教育投入高过了所在国当地学生。rnrn那么那些次品程序员被垃圾学校创造出来以后呢?他们没有受过良好的完备的职业训练,根本基本的素质都没有。他们被广大的小软件作坊吸收,组装那些最最初级的软件零部件。由于知识的匮乏和能力的不足,他们的生产效率非常低。rnrn比如一个小的客户资源管理系统,不过区区2、3十张表,都是些CRUD操作,这些软件作坊居然要开发半年甚至一年。由于不正确的设计方法,这些代码往往没有交付就已经完全腐败无法维护。rnrn因为语言问题,这些初级代码工人很难阅读外方的软件需求,无法沟通交流,也因为语言问题,他们学习知识的能力非常低,根本没有办法适应现代化的软件生产活动。rnrn软件人才的不足和知识产权保护的空白,使得软件开发变成了廉价的和不值钱的劳动。软件开发的机会成本居然在下降。软件市场出现了反淘汰——那些质量低劣的软件因为成本低,而优质的软因为人力成本的因素而竞争力不足,所以劣币驱逐良币。rnrn造成了恶性循环——因为盗版的泛滥,通用软件被逼迫走向消亡,而用户的定制化需求的不到满足,后果就是一窍不通的用户自行开发质量更加低劣的软件。rnrn这种低水平的重复的需求导向就是吸引了更多低端劳动力从事软件产业。于是软件从业者的数量爆增,但是真正的程序员却不增反减。让人匪夷所思的是,软件从业者的薪水已经几乎和体力劳动者持平,更赶不上销售、管理等岗位。rnrn软件企业不能合理使用和培养人才的矛盾很突出。程序员的积极性没有充分调动。rnrn社会上现在流行一种观点,如果一个人没有一技之长,学习不好,什么都不会,出路就是搞软件。颇具讽刺的是,软件业这种对从业者智力要求相对很高的产业如今已经成为社会下层和闲散无业人员聚集的行业,成为名副其实的低科技产业。rnrn程序员已死,呜呼哀哉。 论坛

好文章共享:设计已死?

03-19

英文原文版权由Martin Fowler拥有 rnOriginal text is copyrighted by Martin FowlerrnrnMartin FowlerrnChief Scientist, ThoughtWorks rnrn原文出处| 繁体版 | 译者:Daimler Huang rnrn对很多粗略接触到 Extreme Programming 的人来说,XP 似乎 宣告了软件设计的死刑。不只很多的设计被嘲笑为 "Big Up Front Design"[译注1],连很多技术像UML、富有弹性的程序架构 (framework),甚至连模式 (pattern) 都不受重视,或是近似忽略了。事实上,XP内含很多设计理念,但是它与现有的软件流程有着不同的运作方式。XP藉由多种实务技巧 (practice) 赋予演进式设计 (evolutionary design) 崭新的风貌,让演进变成一种实用的设计方法。它也让设计者 (designer[译注2]) 面临新的挑战与技巧,学习如何使设计精简,如何使用重构来保持一个设计的清楚易懂,以及如何逐步地套用模式。rnrn 近期重大更新:2001年2月rnrn (这篇文章是我在 XP2000 研讨会发表的演说,它会公布在研讨会讲义中。)rnrn Planned and Evolutionary Design (经过规划的设计与演进式的设计)rnrn The Enabling Practices of XP (XP有效的实作技巧)rnrn The Value of Simplicity (简单的价值)rnrn What on Earth is Simplicity Anyway (究竟什么是简单)rnrn Does Refactoring Violate YAGNI? (重构违反了YAGNI吗?)rnrn Patterns and XP (模式与XP)rnrn Growing an Architecture (发展结构)rnrn UML and XP (UML与XP)rnrn On Metaphor (关于隐喻)rnrn Do you wanna be an Architect when you grow up? (你将来想成为一个软件结构师吗?)rnrn Things that are difficult to refactor in (很难重构的东西)rnrn So is Design Dead? (所以,设计死了吗?)rnrn Acknowledgements (致谢)rnrn Revision History (修订的记录)rnrn Extreme Programming (XP) 挑战很多软件开发常见的假设。其中最受争议的就是极力排斥 up-front design,而支持一种比较属于演进的方式。批评者说这是退回到了 "code and fix" 的开发方式,顶多只能算是一般急就章的程序设计罢了。支持者也常看到 XP 对于设计方法 (如 UML)、principle(设计准则)、patterns 等的排斥。别担心,仔细注意你的程序代码,你就会看到好的 design 浮现出来。rnrn 我发现自己正陷于这个争论当中。我的工作着重在图形化设计语言 - UML 以及 patterns,事实上我也写过 UML 和 patterns 的书。我如此的拥抱 XP 是否表示我放弃了这些理论,或是将这些反渐进式 (counter-revolutionary) 的概念从脑中清除了?rnrn 嗯... 我不想让你的心悬荡在这两种情境中。简单的说并不是;接下来的文章就让我来详细说明。rnrn rnrnPlanned and Evolutionary Designrnrn rnrn我将在这篇文章中说明软件开发的两种设计方式是如何完成的。或许最常见的是演进式设计。它的本质是系统的设计随着软件开发的过程增长。设计 (design) 是撰写程序代码过程的一部份,随着程序代码的发展,设计也跟着调整。rnrn 在常见的使用中,演进式设计实在是彻底的失败。设计的结果其实是一堆为了某些特殊条件而巧妙安排的决定所组成,每个条件都会让程序代码更难修改。从很多方面来看,你可能会批评这样根本就没有设计可言,无疑地这样的方式常会导致很差劲的设计。根据Kent的陈述,所谓的设计 (design) 是要能够让你可以长期很简单地修改软件。当设计 (design) 不如预期时,你应该能够做有效的更改。一段时间之后,设计变得越来越糟,你也体会到这个软件混乱的程度。这样的情形不仅使得软件本身难以修改,也容易产生难以追踪和彻底解决的 bug。随着计画的进行,bug 的数量呈指数地成长而必须花更多成本去解决,这就是 "code and fix" 的恶梦。rnrn Planned Design 的做法正好相反,并且含有取自其它工程的概念。如果你打算做一间狗屋,你只需要找齐木料以及在心中有一个大略的形象。但是如果你想要建一栋摩天大楼,照同样的做法,恐怕还不到一半的高度大楼就垮了。于是你先在一间像我太太在波士顿市区那样的办公室里完成工程图。她在设计图中确定所有的细节,一部份使用数学分析,但是大部分都是使用建筑规范。所谓的建筑规范就是根据成功的经验 (有些是数学分析) 制定出如何设计结构体的法则。当设计图完成,她们公司就可以将设计图交给另一个施工的公司按图施工。rnrn Planned Design 将同样的方式应用在软件开发。Designer 先定出重要的部份,程序代码不是由他们来撰写,因为软件并不是他们 "建造[译注3]" 的,他们只负责设计。所以 designer 可以利用像 UML 这样的技术,不需要太注重撰写程序代码的细节问题,而在一个比较属于抽象的层次上工作。一旦设计的部份完成了,他们就可以将它交给另一个团队 (或甚至是另一家公司) 去 "建造"。因为 designer 朝着大方向思考,所以他们能够避免因为策略方面不断的更改而导致软件的失序。Programmer 就可以依循设计好的方向 (如果有遵循设计) 写出好的系统。rnrn Planned design 方法从七○年代出现,而且很多人都用过它了。在很多方面它比 code and fix 渐进式设计要来的好,但是它也有一些缺点存在。第一个缺点是当你在撰写程序代码时,你不可能同时把所有必须处理的问题都想清楚。所以将无可避免的遇到一些让人对原先设计产生质疑的问题。可是如果 designer 在完成工作之后就转移到其它项目,那怎么办?Programmer 开始迁就设计来写程序,于是软件开始趋于混乱。就算找到 designer,花时间整理设计,变更设计图,然后修改程序代码。但是必须面临更短的时程以及更大的压力来修改问题,又是混乱的开端。rnrn 此外,通常还有软件开发文化方面的问题。Designer 因为专精的技术和丰富的经验而成为一位 designer。然而,他们忙于从事设计而没有时间写程序代码。但是,开发软件的工具发展迅速,当你不再撰写程序代码时,你不只是错失了技术潮流所发生的改变,同时也失去了对于那些实际撰写程序代码的人的尊敬。rnrn 建造者 (builder[译注3]) 和设计者之间这种微妙的关系在建筑界也看得到,只是在软件界更加凸显而已。之所以会如此强烈是因为一个关键性的差异。在建筑界,设计师和工程师的技术有清楚的分野;在软件界就比较分不清楚了[译注2]。任何在高度注重 design 的环境工作的 programmer 都必须具备良好的技术,他的能力足够对 designer 的设计提出质疑,尤其是当 designer 对于新的发展工具或平台越来越不熟悉的状况下。rnrn 现在这些问题也许可以获得解决。也许我们可以处理人与人之间的互动问题。也许我们可以加强 designer 的技术来处理绝大部份的问题,并且订出一个依照准则去做就足够改变设计图的流程。但是仍然有另外一个问题:变更需求。变更需求是软件项目中最让我感到头痛的问题了。rnrn 处理变更需求的方式之一是做有弹性的设计,于是当需求有所更改,你就可以轻易的变更设计。然而,这是需要先见之明去猜测将来你可能会做怎样的变更。一项预留处理易变性质的设计可能对于将来的需求变更有所帮助,但是对于意外的变化却没有帮助 (甚至有害)。所以你必须对于需求有足够的了解以隔离易变的部份。照我的观察,这是非常困难的。rnrn 部份有关需求的问题应该归咎于对需求的了解不够清楚,所以有人专注于研究需求处理,希望得到适切的需求以避免后来对设计的修改。但是即使朝这个方向去做一样无法对症下药。很多无法预料的变更起因于瞬息万变的商场,你只有更加小心处理需求问题来应付无法避免的情况。rnrn 这么说来,planned design 听起来像是不可能的任务。这种做法当然是一种很大的挑战。但是,跟演进式设计 (evolutionary design) 普遍以 code and fix 方式实作比较起来,我不觉得 planned design 会比较差。事实上,我也比较喜欢 planned design。因为我了解 planned design 的缺点,而且正在寻找更好的方法。rn(未完)rn rnrn 论坛

Quocirca直言:编程已死?

05-06

http://www.umlchina.com/News/Content/132.htmrnrnQuocirca直言:编程已死? rn rn rn rn[2004/4/23]rnrn有一些软件工具厂商已经走在了OMG的前面。比如说,新出来的Quovadx公司在应用模型生成代码方面已经到了崭新的水平上,书写代码已经变得越来越失去需要。不可否认的是,Quovadx目前的大部分示例都是和特定的行业相关,例如医疗和金融服务等。但是它使人们再次关注-我们离完全告别代码的时代还有多久?rnrnrnrn答案是,实际上已经不远了,如果Select Business Solutions提供的最新信息可信的话。SBS,曾经是Rational Rose公司在英国的最大竞争对手,他们目前已经把MDA的概念和设计模式结合在一起,设计模式实质上就是将过去你写过的不错的代码结构,详细地说明并以建模术语的形式进行复用。通过选择这些设计模式并作为代码生成器的输入,就有可能生成绝大部分的代码,即使不是全部。SBS并不是唯一一家这么想的公司。但是,它是第一个实际实现了这个思路的公司。rnrn当然,事情总是说起来容易,要做结论还得进行仔细的测试。也许问题不是谁获得了胜利,SBS还是Quovadx,Rational还是Borland。而是,他们将我们置于这一无情的事实中:大部分的代码都将自动生成。当然,会有人抱怨(自动生成的代码)效率太低,也就是说总是需要专家来开发高质量的代码的。但是,对其余(非专家)的人而言,无疑是致命一击。rnrn同样,代码自动生成也意味着程序员不需要考虑甚至不需要知道这些代码。由于IBM的软件部门包括软件开发和企业管理,这时候它的优势就显示出来了:比如说,他们可以关注标准的事件日志如何内建到代码生成器中,支持自动的计算系统。rnrn同时,我们应该在主要的应用开发商的角度来考虑这些。他们都会停止开发那些可以集成在应用中的功能。另外,一些独立的解决方案提供商将会致力于提供面向特定领域和市场的垂直解决方案。他们都将从MDA以集成为中心的观点中受益,在这一观点中,模型就是那些预制的组件和从专门机构那里购买的服务之间的粘贴剂。rnrn没有程序员会因为MDA丢掉工作,原因很简单:总是有新的有趣的事情等待开展。但是,MDA将会带来非常大的变化。未来,如果模型是国王(译者注,以模型为中心),编程的责任就会转移到业务上,并进入IT客户的市场。这不是坏事:保险公司关心保险的事情,制药公司努力研制新药品,而不是花掉大半的预算去重新升级旧的代码或者努力开发新员工喜欢的新的系统。rnrnMDA还有路要走-随着MDA被各种决心使用的它的业务领域所采用及接纳,MDA将会获得一致认可,但,还是需要时间。rnrnrn(自 silicon,UMLChina袁峰 摘译,不得转载用于商业用途) rn rn 论坛

如何挽救已死的站点

12-23

网站挂了,内部没有错误,google管理平台,分析得到的结果是有几个简单的短元错误,这样都不是什么大的问题,但是不知道什么原因让搜索引擎给摒弃了。rnrn在建站之初,网站排名优越,放上网站以后,不到一周的时间google收录,而且排名不错,首先选取的关键词是“砂光机”“不锈钢砂光机”“宽带砂光机”“不锈钢磨砂机”“木工机械”。rnrn前期推广相当顺利,而且排名很有效果,不到20天的时间,搜索砂光机,已经排名到了 google 的第二页第十的位置。比的没有什么踪迹。22天,开始有了起色,其它几个关键词开始现形,纷纷上扬,不锈钢砂光机到了首页第六,不锈钢磨砂机第二页第一,快带砂光机,第一页第七的位置,唯独没有木工机械的影子。rnrn搜索关键词排名的时候,才知道关键字密度太低,预示改了模板,加大木工机械的密度,结果…… 痛苦的事情来了,不但木工机械没有提升排名,所有的关键词都在掉落,一时间搜索引擎上,基本淡出了前70名。rnrn今后的一个月时间,有些彻底放弃的意味,不是想是服务器问题,经常的抱出500错误,没有办法进行更新,这样的情况延续了一个月,现在的网站排名,就一个字“惨”!rnrn因为是一个试验站,所以怎么搞都在我了,现在重新布局了模板,重新沟起他来,老大给了点意见,就是狂拉ip,尽量的把流量拉大,这样还能起到一些作用,这也是没落的方法了。www.tianshangtong.cn有些惨,现在正寻求更好的方法,如果谁有妙招,请不吝赐教了。rn本篇文章来源于 - http://www.itokit.com - web开发技术 原文地址是:http://www.itokit.com/bbs/viewthread.php?tid=11869&extra=page%3D1&frombbs=1 论坛

新看到的....EJB2.X已死??

12-23

EJB大势已去,指的是EJB2.x的那种重量级的EJB架构技术,而不是指全新的POJO based的EJB3.0。 rnrn其实围绕 EJB这个话题,已经讨论的口水都干了,我在2002年的时候还是相当推崇EJB的,但是在当年的EJB项目中已经深切体会到了EJB的致命缺陷。到 2003年基本上对EJB持一个谨慎的态度,即支持Session Bean,反对Entity Bean,然而仅仅就是这种谨慎的置疑态度已经遭到全面的疯狂围攻和人身攻击。2004年以后,可以说EJB2.x在IT行业已经得到了绝大多数公司的共同否定和抛弃,特别是EJB3.0 SPEC的发布,已经完全是另外一个东西,只不过披着EJB的外衣而已。EJB专家组对EJB2.x模型的彻底抛弃,已经宣判了EJB2.x的死刑,现在唯一不确定的只不过是EJB2.x还能苟延残喘多久的问题而已。 rnrn昨天我和jlinux约nuke吃饭,谈一些出版的事情,席间谈到一些技术上面的话题。nuke是IBM公司的technical Consultant,一向负责IBM对金融行业的业务。我和nuke上次见面还是在今年4月份JBoss Core Team的Ben Wang访华的饭桌上。我还记得上次我们席间也谈到EJB的话题。大家,包括Ben对Entity Bean否定态度都是一致的,所不同的就是对Session Bean在分布式业务上的作用而已,当时nuke提到他接触过的一些业务又大规模的EJB集群的,几百台的EJB集群。 rnrn然而这次聚会, nuke却提到一个非常令我吃惊的消息,他说现在即使在IBM面向客户的业务中,也已经没有EJB的位置了,EJB成了一个典型的反模式。他还特别提到,他们的很多客户,例如新加坡客户首先就会问你项目用了EJB没有,如果用了EJB,那么我们不要,如果没有用EJB,OK,pass。 rnrn这个消息对我来说还是非常吃惊的,我没有想到EJB现在市场萎缩的这么厉害,我还以为EJB2.x还只是在开发人员当中被大面积的抛弃,在大客户的应用中还将生存很久的时间,现在连IBM的客户都已经态度鲜明的拒绝EJB了,这是非常可怕的事实,这说明了EJB2.x现在已经没有任何市场了,宣告EJB2.x 事实上的彻底死亡。 rnrn可笑的是,国内的某些个别人,出于不可告人的,为了谋求个人金钱利益的目的,不遗余力的鼓吹EJB2.x,毁人不倦的误导可怜的Java初学者。当这些Java初学者将很快发现他们花了不菲的培训费之后,只学到了一堆报废的知识,甚至被人为的,有目的的引入了歧途,到那个时候,被欺骗了的人们将如何宣泄他们的愤怒呢?让我们拭目以待吧。rn 论坛

没有更多推荐了,返回首页