我经常听到有人说你不应该急于采用新技术,直到它们变得稳定,经过试验和测试.关于如何正确使用3个版本甚至还有一个笑话.这可能是现实生活体验的声音,但至少有时这种姿势是自满,抵制变革和学习新技能所需的努力的结果.
但是,在我看来,软件行业的成功与创新保持同步至关重要.虽然大公司有整个部门致力于研发,但在较小的公司中,开发团队必须跟上.即使在正式推出之前就开始使用新技术 - 这将为您提供一些启动,并帮助您跟上其他技术.
这是我尽可能遵循的策略:
到目前为止,我从来没有付出过于热衷于跳上一些新技术列车的代价,但我仍然获得了好处.我想知道这只是巧合,还是早期采用者毕竟不是那么危险？
这个问题肯定是有争议的和主观的,而不是邀请就早期采用这个问题进行讨论,我希望听到现实生活中的经验,即采用早期新技术被证明是一个严重的错误,而且必须付出沉重的代价.支付.
Bil*_*ard 25
我可以编写一个非常好的Java Applet.所有技术最终都会被淘汰,但这一技术的上升与下降非常明显.
Ahm*_*eed 24
我目前正在被Microsoft Office Word 2007的CustomXML支持所灼烧.
CustomXML允许文档具有可以为业务数据建模的自定义元素等.例如,您可以使用自定义元素定义XSD,将其与docx文件关联,然后将占位符生成为CustomXML标记并使用导航/修改文档C#(或其他.NET语言)和OpenXML SDK.OpenXML的好处在于它解决了为服务器机器安装Office以实现自动化的需求,并且是购买第三方库的替代方案.
简而言之,有一项关于Word 2007能够使用自定义XML打开文档的诉讼.从这篇文章:
8月11日,该公司收到Office Word销售禁令......
"此禁令仅适用于2010年1月11日禁令日期或之后在美国销售的Microsoft Word 2007和Microsoft Office 2007的副本.在此日期之前销售的这些产品的副本不受影响."
微软的回应是从未来版本的Word中删除对CustomXML的支持,并发布一个完全删除此功能的补丁.这是官方更新的链接.根据此Microsoft OEM合作伙伴中心网站:
美国需要以下补丁.该修补程序适用于所有Office 2007语言.
安装此修补程序后,Word将不再读取DOCX,DOCM或XML文件中包含的自定义XML元素.这些文件将继续打开,但将删除任何自定义XML元素.处理自定义XML标记的能力通常与基于自动服务器的Word文档处理相关联.大多数Word的最终用户通常不使用自定义XML.
我想一小部分最终用户和开发人员都会使用它,所以我认为最后一句话是准确的.问题是目前没有任何关于如何推进利用这项技术的项目的文字(没有双关语).CustomXML是我目前正在开展的大型项目的基石.这个决定的影响并不是积极的,它有效地阻止了任何向前兼容性,因为没有相同的替代方法来维护CustomXML提供的结构.
我的一些同事和我对这个主题有很多知识...我想我们没有按照我们的计划编写关于它的博客文章很好:)我们已经完成了一些相当令人印象深刻的壮举VSTO,但这个消息令人失望.
如果有人对此主题感兴趣,请查看以下内容:
ZDNet文章:
BNet文章:
Softpedia文章:
编辑:添加了官方更新的链接.
DOK*_*DOK 21
几年前,我们大量使用了名为Notification Services的新SQL Server 2005功能.令我们失望的是,SQL Server 2008中已经停止使用.这是一个严重的问题,导致软件架构师质疑所有新的Microsoft技术.
Oak*_*Oak 10
斯卡拉.
它看起来很棒,所以我用它写了一个项目,同时确保我的Scala版本保持最新.版本号(2.7.x)及其开发年份让我感觉相对安全.
好吧,我搞错了.问题？严重缺乏文档和代码示例,以及不断变化的类库(在我工作期间两次,以前工作的代码开始得到"弃用"警告......而且我正在谈论几个月和类似版本的范围号).
我不能说我失去了很多(这是一个私人项目)但我不会在不久的将来接触Scala.不过,我仍然认为这是一种非常好的,有前途的语言.
当我的时候10,我的父亲试图以全新的方式为我播放新年歌Elektronika BK-0010-01.
毋庸置疑,合成器无法从磁带上加载,并且在邻居带着吉他之前没有歌曲.
是的,我有!使用JSF 1.0!似乎Sun在发布之前没有对它进行过很好的评估.
我们一直在努力使事情有效,但有一段时间我们发现我们的错误是由JSF错误引起的,我们不得不使用变通方法.直到JSF 1.1和myfaces-tomahawk实现的使用,项目才开始有一定的速度.
QBASIC从未真正起飞过.我花了数年时间学习它.
好吧,公平地说这是我的第一语言和学习的好方法.后来它被Visual Basic取代,然后是VB.NET.所以这并不是完全浪费我的时间.;)
大多数时候,即使一种语言没有完全"起飞",它仍然是一种可以应用于其他东西的良好学习体验.
最糟糕的是,当你使用新产品获得80%的项目并且遇到一个showstopper bug时.
早在80年代中期,我的老板建议我尝试一种名为KnowledgeMan的新dBase替代品.当我意识到我认为是我的一些重要错误实际上是他们的时候,它还远远不够.整件事必须从头开始重做; 这让我失去了工作.
我们开始在一个公共网站/网络应用程序中使用它,被单点登录的梦想所吸引,并声称能够"利用您现有的基础设施"或现在的营销说话.系统管理员可以管理的ASP.NET插件解决方案,无需开发任何工具或编写任何代码.这是双赢的,对吗？
由于我们的决定,我们学到了很多东西,我们都不想学习:
对于为公共网站提供服务的身份验证机制,Active Directory本身不是一个很好的选择.并不是说它没有能力 - 它很有能力,但它就像聘请博士写一个"Hello World"应用程序一样.这是大材小用,但它的方式超过你所能需要在这样的背景下,这是很多更难比一个普通的老SQL表的工作,并且需要大量的更多的维护.
阿兹曼很慢.非常非常慢.角色提供者必须维护一个缓存,它应该告诉你我们正在讨论什么样的性能.我从来没有完全理解为什么它如此缓慢,但我想它与大黄蜂的COM嵌套和它依赖的网络协议有关.
当你几乎无法控制它时,缓存(见上文)可能是一件非常危险的事情.当我们手动添加新用户时(即通过管理应用程序而不是站点本身),这些用户最终将获得"未授权"屏幕,直到缓存过期并且他们退出.有时这甚至会发生在网上自我注册的用户; 我们从来没有找到原因.
工具太可怕了.如果您不相信我,请简要了解一下AzMan控制台,或者如果您真的想要头疼,请阅读一些文档.为什么要这么复杂？
它很脆弱.很多时候,提供商会停止工作,吐出神秘的COM错误(每次都是不同的错误!),我们不得不重新启动IIS甚至整个Web服务器以使其再次合作.我们还设置了域信任 - 因为很明显我们不希望内部企业域上有50,000个公共用户帐户 - 只有问题是,管理员必须登录辅助域上的管理帐户来管理角色,因为控制台会失败以神秘的方式,如果您尝试从主要使用它(即使在辅助域上具有域管理员权限的企业管理员).
支持实际上是不存在的.如果您使用基本的SQL Server角色提供程序(我们没有,但仅作为示例),有1000万个教程,您可以在Google上查找任何错误消息或在任何论坛上提出任何问题.每当AzMan出现问题或我们想要做一些新的事情时,找到好的信息都是一个持续的斗争.
代码集成很尴尬.你不得不经历一堆凌乱的COM层,界面很糟糕.如果我没记错,就没有办法只进行简单的授权检查 - 你必须下载整个应用程序/角色注册表.这是很久以前的事了,所以我的记忆在这方面可能会模糊不清.
最终我们不能再拿它了,并且决定根据几个SQL Server表来删除整个系统,这可能是我们应该从一开始就做的.迁移是痛苦的(见上面两点),但我们完成了,并且从未回头.
不幸的是,它削减了两种方式.当我们第一次开始在Windows上开发一个基于Web的大型应用程序时,.NET已经开始测试 - 不久之后最终发布了.NET 1.0.
然而,因为它是新的,我们不知道会发生什么,它会有多受欢迎,以及MS是否会在六个月后放弃它.所以我们坚持使用经过试验和测试的VB6.
我们仍然需要维护VB6的遗产,并且暂时受到限制.虽然它没有在任何地方列出,但我们正在变得偏执,对VB运行时的支持将在给定版本的Windows中被撤销.
也就是说,走.NET路线可能有其自身的痛苦:1.0,1.1和2.0相继出现相当快,每个都与前一版本(某些)不兼容.因此,不得不迁移.NET平台会带来不同的风险.更少或更多？无法回答那个没有经历过的人:-)
最后,如果你这样做,你可能会被诅咒,如果你不这样做,你该死的.如果有人可以阅读内脏以确定某项技术是否会在任何时间取得成功,那么他们就不应该在软件中找到工作,而应该进入对冲基金管理,赚取大量现金并提前退休: - )
Mozilla XULRunner.
在AIR之前是Adobe AIR.我们使用它编写了人力资源管理系统.当时XULrunner"即将"作为FireFox的底层引擎发布,所以我们希望我们所要做的就是确保我们的用户安装了FireFox.
进入项目2年后,就在部署之前,一个新的XULrunner出现了,完全打破了我们的所有代码,并且Firefox部署无处可见.我们最终使用专用的桌面安装程序在我们的旧版本上部署,并且从那时起一直在使用它,没有安全性或性能更新的好处,因为我们必须重新编写太多的代码才能兼容.尽管这对我们的客户来说是一个非常成功的项目.
我们现在正在重新编写应用程序以在Ext上运行,这对我们来说是新的热点,但似乎有更多的社区支持,并且如果我们真的陷入困境,则提供商业支持.
Java的
我非常渴望在1996年开始研究并将它用于几个项目.但是对于Web开发我总是喜欢Perl,而现在是PHP.GUI开发我最终主要使用.NET.对于无法通过脚本处理的少数命令行程序,我更喜欢使用Perl,Python甚至是PHP.
我编写的Java程序很少使用很长一段时间,而我的一些pre-java应用程序仍在使用中.
我认为这样做的主要原因是,使用Java开发内容比使用其他编程语言花费的时间更长:因此生成的应用程序包含的功能更少,更容易替换.
由于开发速度通常是我的客户的问题,Java往往最终成为第二选择.