http://www.guende.com/index.php zh-cn http://www.guende.com/read.php?90 guende <admin@yourname.com> Fri, 13 Jan 2012 00:34:57 +0000 http://www.guende.com/read.php?90
1. SOA和云将会为海量数据分析应用的部署打下坚实基础：SOA、云和社交媒体正在将商务智能转变成“协同智能”。但是，要达到这个目标，必须要以面向服务的方式来管理海量数据应用 - 例如可以采用数据虚拟化这样的策略。
2. 计算能力将会“便宜到忽略价格”：感谢SOA和云，大规模数据中心的计算能力将便宜到以分来计价：思科最新发布的全球云指数报告指出，企业的数据中心将会变为云的形式。并且，有的时候这些企业将会兼云提供商和销售商于一体。
3. 更多的商业用户将会构建他们自己的应用，而且会涉及更多的IT人员：关于人才断层、IT和商务人士的缺乏合作之类的讨论随处可见。但是现在，很多商务用户都是在谈论自己的新方案，如何将自己的技术发展成熟壮大，并用于处理自己的商务问题。另一方面，IT人士开始对商务有了更深的理解。这两种相互关联的趋势在数年前就可以看到，接下来的2012将是趋势最终转换为成果的一年。
4. 云和SOA将使IT管理人员和执行人员面临重要机遇：CA Technologies访问过685位CIO，调查结果表明，54%的CIO相信云计算将能够帮助他们将更多时间关注于商务策略和创新上。而且此项调查也发现采用了云计算的CIO要比没有采用的同僚们更好地推动着公司的进步。
5. 软件提供者和消费者之间的界线将会越来越模糊，更多的非IT公司将会成为软件提供者：Gartner相信IT公司所完成的功能最终将会被归纳为商务的一部分。但是，这并不是说IT将会逐渐解体，而是说整个企业界将会IT化。非IT公司和软件公司的界线将会越来越模糊，你甚至不能找出二者的区别。
6. 云肯定将继续影响外包模型：高度模块化的外包服务将会出现，因为云服务和组件的不断规范化以及“热交换能力”将对外包服务的模块化提出更高的要求。
7. “SOA”和“云”将会逐渐地演变成同义词 - 我们现在就正在做这件事情：我们貌似已经找到了诀窍，将所有的东西都以面向服务的形式部署。而且云现在正被认为是应用和服务的投放平台，带给我们比以前更加强烈的感觉。不过，讽刺的是，看起来它也会逐渐让人感到厌烦。就像过去两年中发生在SOA身上的那样。希望今年这些销售商能够认识到这点，更换一下新的广告词。

Joe用短短几句话总结了面向服务过程是如何主导商业行为的：

我们肯定会将业务转换成面向服务的形式。不仅如此，这些服务将会和数据源绑定的越来越牢固 - 可以是基于SOAP的服务，也可以是基于REST的服务，或者直接来自于云。我们正逐渐地接近SOA的核心本质：部署松耦合的服务来完成完整的业务流程。

这也在某种程度上解释了API数量的爆发，Apigee的Dr. Ananth Jhingran预测：在2012年，API的规模将会持续增长并且呈现出一些特别的趋势：

1. 企业级API将会成为主流：我看到大量关于Facebook、Twitter和其他公用API的讨论。这些API的兴起实际上意味着一场革命。也就是说，企业本身，无论规模大小，都将会被抽象成为一组API - 通过自身的后端系统。这将是后端系统的巨大机遇，而且，将来的后端系统的服务对象将不会仅仅局限于企业本身的应用，而且还将服务于合作者和独立开发者的应用。
2. API中心的架构将会和门户中心或者SOA中心的架构完全不同：网站（门户）是聚合用户。SOA是聚合应用。传统的网站和SOA架构关注使用“内部”API来和后端系统交互，而全新的API架构则将精力放在开发者和应用的整合，而不是用户（来自门户）或者流程（来自SOA）。
3. 数据中心API将会快速普及：Siri和WolframAlpha是数据中心API的绝好例子。企业首先要做的便是将自己的数据API化。尽管REST化数据不易，而且关于如何最佳REST化，还有各种不同流派的指导思想存在，但是，我可以看到，这股趋势不可阻挡，一些事实标准和传统做法的结合将会成为业界标准并且普及，例如开放数据协议（OData）。我不认为语义网络或者资源描述框架将会成为主流，因为这两者的采纳和使用均不容易。
4. 很多企业将会实现API并且用于数据分析：企业之间在技术上的一个广泛共识是首先将资源花费在业务自动化上，其次才会考虑业务优化。现在的情况便是企业将API的重心放在业务自动化上，但是，随着API处理越来越多的流量，对API进行分析能够更好地审视企业的表现，进而可以让技术和业务优化受益。如果最终目标是业务优化，而且能够保持这种趋势，很容易得出一个合理的结论：API是业务优化的一种重要手段。
5. API将会为移动开发者优化：在2012，许多API提供商将会认识到他们需要完成如下的工作：

能够让开发者定义API返回的内容和数据大小。
根据开发者的环境返回正确的格式 - iOS的话应该返回plist，HTML5/JavaScript的话应该返回JSONP。
6. OAuth 2.0将会成为默认的安全模型：OAuth 2.0将使得终端用户能够更加容易地使用新颖的应用程序，因为用户可以彻底检查这些应用程序。如果用户并不喜欢或者不信任某个应用，用户可以终止这个应用程序对他们账号的访问。2012年，在用户通过应用和服务交互的时候，安全将会是API的默认开启选项。

商务策略师和企业架构师Dion Hinchcliffe也赞成Dr. Ananth关于API在2012年发展趋势的观点，他认为，在2012，API将会达到一个新的高度，以下五个方面可以证明这个观点。

1. API的软因素将会和技术因素同样重要：我之前已经阐述过技术对于打造一个成功的开放式API的重要性，但是，涉及到API的选择、理解以及长期成功，那关键就在于围绕这个API所打造的架构了。而且，雇佣一名社区经理也是一个很重要的因素，他必须要有足够技术经验，能够倾听并且帮助开发者看到API的潜质。
2. 简单至上：复杂是API的大敌。当大量的服务通过API运行业务流程的时候，如何保证良好的客户体验将是非常重要（客户在这里包括了开发者和合作伙伴）。
3. API始于微末，用于内部，然后才会逐渐完善功能，并且对外开放：API将为SOA服务，而且很多API服务提供的特性使得API不得不成为私有或者半私有。
4. API即产品：现在API所提供的服务恰好能够等于某些公司整个机构能够提供的服务。但是，另外一个问题是，当前API的用户体验只是关注于和客户的网络交互，当API牵涉到多个业务时候，用户体验并没有得到足够多的重视。
5. 每个人在使用API都会有一些独到的的经验，分享它们将会促进工业界知识库的成熟：eBay API主管工程师Subbu Allamaraju就撰写了一篇博文，分享了在面对自身产品和第三方开发者的时候，他们在改善API的伸缩性和效率上所积累的经验。这是API社区经验分享的一个绝佳例子。

这些增长趋势将会孕育在什么样的平台中呢？Forrester的首席分析师Holger Kisker认为2012年将会是云走向成熟的一年，如下可证：

1. 跨云将会成为一种标准。
2. 漫无目的的云采购将会终结
3. 云将会越来越舒适便捷
4. 协作将会使云计算受益匪浅。
5. 我们将会看到在PLM、BI和SCM中SaaS解决方案的下一波浪潮。
6. 云市场将会超过600亿美元
7. 私有云将会不仅仅局限于虚拟化
8. 云经纪商将会出现
9. 大型企业将会领导云市场
10. 云和本地软件授权模型的界线越来越模糊。

但是，云的使用策略越来越模糊，这非常危险。Zapthink总裁Jason Bloomberg关于GIGO原则有一番精彩的论述，GIGO原则将会是2012年架构和治理的基础。

“Garbage In，Garbage Out”（GIGO）这个原则已经存在了相当长时间，比数字计算提早出现了近一个世纪，而且对于信息科技是如此的基础。虽然现在我们已经是21世纪，正在 朝云计算转换，若是Babbage先生泉下有知，那么他对于现在某些情况也会一样的愤怒，虽然已经数百年过去，人们仍然没有牢牢记住这个重要原则。现在的 云并不仅仅像是磁铁，吸引着各种垃圾，而且它自身还迅速产生了大量的垃圾。我们应该停下脚步，仔细考虑一下匆忙迁移至云的后果。

数据质量低下 - 如果当前数据并不纯净，也就是说，如果你手头上的数据是一些不一致的客户地理信息，或者过时的产品信息，或者其他的质量问题，那么迁移到云不会给数据或者业务带来任何好处。
面条式代码（Spaghetti Code） - 你要仔细审视是否要将代码陈旧的应用首先部署到云上。它太慢了，而且伸缩性也很差，而且也庞大到现在是不太可能整合了，那么云能不能让它运行快些，伸缩性好些，而且更容易整合呢？显然不会是这样。如果你现在关注laaS方法，那么你会发现在云上，这种代码也和在本地一样难以管理。那么PaaS呢？那这些代码甚至不可能工作，要知道今日的PaaS环境已经对代码的质量有了一定的要求。
陈旧或者云不友好的业务模型 - 业务需要IT部门能够自动化一些流程，但是并不等于说“流程本身就足够好了”，其潜台词也包含了希望IT部门能够将流程做得更好，更快，更加流水线化，而且要能够兼容当前的基本业务需求。
垃圾不仅仅只是指你可能放在云上的那些代码，云本身也非常有可能产生大量的新型垃圾。

僵尸实例 - 大量创建云实例是如此的简单和便宜，只需要足够的虚拟机，存储实例等等。而且，这类实例都是非常弹性的：需要更多？没问题，云很乐意效劳。云提供商也很乐意看到你创建这些僵尸实例并且为此付费。
未治理的数据 - 你知道你现在使用的数据是否是最新的版本吗？你知道这些数据还没有被治理过吗？如果没有的话，那么这些数据比毫无用处更加可怕，因为它们可能是错误的，甚至保存这些数据可能触犯了某些法律法规。
手动或者拙劣的配置 - 如果你需要更多资源，那么就提供更多资源，不要节省。但是有一些管理员会打开你某个实例的配置文件，然后修改以使得另外一个应用可以运行在这个实例上。那么你就不得不中断你的应用来更新所有实例，更有甚者，如果管理员没有告知任何人这个修改，问题跟踪将会非常耗时。
选择非云友好的架构 - 云计算对应用的架构提出了特殊的要求，如果要将错误的架构硬塞进云的话，那么就好像灰姑娘的姐姐硬要穿上水晶鞋一样徒劳无功。
界线的逐渐模糊，数据爆炸，各种设备的出现和商品化，这些看起来都像是在2012年将会有一场巨大的变革，但是宏观经济又会是如何表现呢，是否会对此变革产生巨大影响呢？让我们拭目以待。
]]> http://www.guende.com/read.php?89 guende <admin@yourname.com> Thu, 05 Jan 2012 08:45:53 +0000 http://www.guende.com/read.php?89
一份Dice.com调查显示，65%的招聘经理预计在2012年增加IT职位。美国IT领域当前的失业率处在2.7%左右，比Reuters统计的美国国家失业率8.6%要小得多。3-4%以下的数字经常被美国劳动局当“充分就业”看待。而且，Dice.com调查指出招聘经理们普遍认为裁员是非常遥远的事儿。

Marketwatch提出的“IT已经成为领先的非技术型公司及企业的真正意义上的业务及战略的伙伴”可能推动了这一最新的技术招聘趋势。Markewatch称：

简言之，不论工程师还是有技术背景的销售人员，他们的工资都在增长。各种工作机会都充满了这样的预期，因为市场对技术有很大的需求，信息技术已经成为企业战略规划中空前重要的部分。
明确IT职位市场有持续增强的预期之后，接下来的问题自然是：现在是跳槽的好时机？薪水不是跳槽的唯一原因，一些HR专家指出，薪水往往是（跳槽的）人们最后提及的原因。根据Right Management的调查，更常见的原因有：

1. 裁员或重组（54%）
2. 寻求新的机会和挑战（30%）
3. 领导的不作为（25%）
4. 与经理之间的关系差（22%）
5. 改善工作与生活的平衡（21%）
6. 贡献未得到认可（21%）
7. 更好的福利与补助（18%）
8. 个人和企业的价值观更契合（17%）
9. 个人优势及能力不适合（原先的公司）（16%）
10. 公司财务不稳定（13%）
11. 公司和工作迁址（12%）

读者们，你们怎么看待当前的职场趋势和跳槽问题呢？您所了解的中国的情况又是怎样的呢？

]]> http://www.guende.com/read.php?88 guende <admin@yourname.com> Tue, 06 Dec 2011 06:59:01 +0000 http://www.guende.com/read.php?88
这项SKA项目的主要目的是通过遍布在澳大利亚、新西兰或贯穿南非的雷达和天线网络，对射电源进行前所未有的精确观测。一项主要的设计挑战是如何每天处理1EB（译者注：1EB=1024PB）的原始数据。这就是当这个世界上最庞大、最灵敏的射电望远镜准备就绪时，需要去处理的数据量；项目预计在2016年开始实施。IBM称该数据量已经超过了互联网每天的流量总和。相当于需要1500万多个64G的iPod才能存储这些数据。

IBM于11月10日宣布原型系统完成。

这一新的自动化数据管理软件架构，很可能会使研究者更方便的从那些超大规模的数据收集项目中搜集有用信息，比如这个平方公里阵列全球天文望远镜，有了它我们可以探索宇宙中那些未解之谜。

在Melanie Johnston-Hollitt博士的帮助下，IBM创建了信息密集框架（IIF）。IBM提到，该软件采用国际虚拟天文协会本体论方法把收集到的数据分类为天文学家能够理解的概念，并且提供智能的“导引搜索”功能。该本体论的技术基础是网络本体语言（OWL）。天文学家们希望能够通过自动分类来提高工作效率和创造性。

虽然IIF最初是为SKA项目开发，但它也可以在其他领域得以应用。Douglas Watt，IBM新西兰首席技术官，解释道：

虽然一开始为SKA项目开发，但最终的项目成果也可以应用到其他面临“数据洪流”的企业组织。我们已经确定了几个本地场景，无论从自动化性能数据分析还是到监控趋势变化、异常识别以及提高决策力等等方面，都能从中受益。潜在的客户范围包括从独立制造厂商以及电信企业到整个运输网络和医疗系统。

除了上述主题，IIF未来的工作还将包括通过利用并行处理来提升性能。

对SKA项目感兴趣的读者可以在Flicker上观看图片，上面详细解释了一些令人印象深刻的SKA细节。

]]> http://www.guende.com/read.php?87 guende <admin@yourname.com> Mon, 05 Dec 2011 07:02:11 +0000 http://www.guende.com/read.php?87 开发平台持续演变和改进，这常常导致我们只见树木不见森林。从正在进行的关于Microsoft Silverlight和HTML5的争论中就能够看到这种困惑。

有人认为由于HTML5持续增长的势头，微软将会放弃Silverlight。但这似乎不太可能。尽管微软对于Silverlight的战略已经转变，不再吹捧将Silverlight作为提供跨平台运行时的承载工具，但是微软在继续推动Silverlight成为Windows Phone以及一些媒体和业务线（line-of-business）应用程序的开发平台。Silverlight并未消失。事实上，最终形式的Silverlight 5将于今年推出，而且那些用于维持微软传奇的工具也将证实这个观点。

虽然HTML5标准仍处于草案阶段，但是它在将来肯定会成为主导的跨平台解决方案，甚至连微软也承认，称HTML是“唯一适用于所有应用的、真正的跨平台解决方案。”

基本上，Silverlight和HTML5都有各自的位置和用途，我们可以对两种工具之间的相似性和差异进行仔细观察，这样就会找到答案。

表面的相似性
乍看上去，在许多方面HTML5和Silverlight都很相似。此类相似性与易于部署、丰富的用户界面、以及交互模型等联系在一起。

桌面程序担忧的问题之一是部署，特别是那些工作在Windows环境下的Windows开发者尤为关注。部署对于那些工作在中大型企业的人们来说也是一个问题。桌面应用程序的部署足迹对于他们而言是相当麻烦的，因为他们必须确保某个确定版本的运行库可以正常工作，而且他们必须将更新安装到每台机器上。因此部署对于功能丰富的桌面应用程序而言已成为痛点。

在某些情况下，因为业务原因，企业还将坚持使用桌面应用程序，它们具有更好的性能，并且能够更好地利用本地硬件——只是以更加简单、无缝的方式来做事。此外，对于桌面程序平台的开发场景而言，有着杰出程序员的知识积累。这些原因能够胜过对于简单部署的需求。

对于那些将部署置于核心优先级位置上的客户而言，完全的Web解决方案可能更可取，尽管所交付的丰富功能相对于在桌面应用程序中等同的功能而言还不能让所有客户感到满意。虽然我们正在寻找替代解决方案，但是必须平衡此类问题。

一般情况下，Adobe Air和Silverlight都是不错的解决方案。在微软的工具库中，Silverlight是非常好的解决方案，因为尽管存在运行库，但是在构造之初就考虑到无缝部署，而且便于用户更新。基本上，微软很注重更新体验。你不必为将应用程序下载到最终用户的机器上而担心。

HTML5提供了类似的部署方案；然而由于它依赖浏览器，因此存在一些隐藏的陷阱。使用HTML5解决方案的团队必须可以相当肯定，他们的客户可以访问并安装最新版本的浏览器。此外，HTML5有着广泛的浏览器支持：IE9、Chrome以及Firefox；在IE10上HTML 5会更有效地工作。未来所有的移动客户端都会支持HTML5，尽管现在它们还不支持。

简而言之，虽然Silverlight和HTML5之间存在细微的部署差异，但是二者的部署模型基本上是无缝的。

就用户界面（UI）的丰富程度而言，Silverlight则具备一些优势。如果是为了更快地完成丰富的用户界面，那么Silverlight可能是更好的解决方案。不过，HTML5在这方面正迎头赶上Silverlight。用不了不久，HTML5就将拥有更多预先封装的内容，从而使我们可以更便捷地构建丰富的用户界面环境。

这两款工具在交互模型方面也是类似的。二者都不要求用户等待页面刷新，而且二者的使用方式都与桌面应用程序类似。

更仔细地研究
更仔细地研究一下，我们就会发现，HTML5和Silverlight之间强烈的功能相似性正在趋于消退。首先，与真正基于Web的部署比较而言，Silverlight更适合于拥有部署环境相对控制权的企业内部网应用程序。

如果你更深入地了解Silverlight的部署方案，那么你会发现Silverlight还不是真正的最终用户解决方案。因此，如果开发者的目的是让应用程序的用户下载Silverlight并在用户的机器上运行Silverlight的话，那么开发者需要知道对于客户的清晰描述。客户是否将拥有可以运行Silverlight的系统？某些操作是否被允许？

例如，如果用户访问Amazon.com的时候，弹出了下载Silverlight客户端程序的提示，这可能并不是良好的体验。对于网站使用者而言，无缝体验越多越好。

然而，对于企业内部网解决方案的情况——开发者对于机器拥有更多控制权，并且知道都是装有Windows操作系统的机器——尽管开发者可能并不需要对桌面应用程序拥有相当程度的控制权，但是他们知道那些机器有能力运行Silverlight。这就为开发者提供了极大的灵活性。

现在我们可以选择追随Silverlight；当与HTML5比较时，Silverlight无疑是一种更富生产力的开发体验。

微软有些能够让创建和部署Silverlight应用程序更轻松的优秀工具。虽然Silverlight更有条理——相关工具位于他们自己的分类之下，而HTML5还需要多做一些工作。如果你确信你对自己的部署环境比较熟悉的话，或许你可以对那些关系亲密的客户这样说，“这些是最低要求。”；那么Silverlight则更适合。而且将进一步得到高质量Silverlight工具的支持，那些工具使开发者能以一种快速拖拽的方式来创建Silverlight应用程序。通过使用内建的控制抽象模型以及微软已经提供的本地控件，Silverlight还使用户界面开发和大多数其他开发具有更高的生产力。

HTML5另一方面需要得到你当前使用的Web应用程序开发工具的支持。如果你正在ASP.NET环境下开发，那么工具就是Visual Studio .NET，而VS并未提供任何对HTML5的工具支持，目前许多开发平台可能也存在着类似情况。

选择通用语言还是尽力理解？
编程语言是另一个考虑因素。C#（Silverlight）比JavaScript（HTML5）更易于使用和调试。回归到工具和语言的本质。JavaScript使用起来真的是很不一样；即便是经验丰富的JavaScript程序员也知道，由于JavaScript生来就是过程式的、类型不安全的语言，因此JavaScript理解起来确实有点儿困难，然而C#则是一种面向对象、类型安全的语言。这基本上是说，与JavaScript相比，使用C#可以更好地编写和维护大量代码。

Silverlight的局限性和其他考虑因素
如果需要移动部署，那么Silverlight是有限制的。目前，只有Windows Phone支持Silverlight。其他平台未来可能支持Silverlight，但是这还不一定。而且在短期内不可能发生任何改变。目前，要想开发移动客户端可使用的Silverlight应用程序，那么相应Windows Phone设备必须先获得授权才行。

如果开发者无法控制移动客户端，而又希望支持那些设备，那么HTML5就是个切实可行的选择。由于iOS、Android 3已经支持HTML5，并且Windows承诺在IE10下支持HTML5，因此HTML5现已成为明确之选。

然而，Silverlight可以提供比HTML5更好的性能。在过去的几个月里，微软实现了针对Silverlight 5的硬件解决方案，因此在一些新型号的机器上Silverlight 5相对HTML5具有轻微的性能优势。但是HTML5肯定会在将来赶上来。例如，IE9对于HTML5做了许多改进，因此这个性能差异只是暂时性的，而非决定性的。这算不上多大的差别。

很显然，HTML5是一种基于标准的环境，这是一些开发者极为关注的事情，而其他人却不大关注。如果是使用微软工具库的开发者，那么他就会理解并欣赏那些标准；然而，通过理解微软将在一段时间后也会遵循这一标准，这种态度会有所缓解，因此他们并不是不愿采用微软的专利技术。

在许多情况下都存在遵循标准的推动力，所以如果情况发生改变，那么迁移路径也很容易。HTML5是基于标准的，并且随着HTML5的到来，它正在被传播到全世界。使用HTML5的前途是很光明的——使用Silverlight却并非如此。

相对于HTML5，Silverlight有一个相当大的优势，即Silverlight程序中90％至95％的代码可以与桌面应用程序共享。如果你拥有一款成熟的桌面应用程序以及相应的Web移植解决方案，那么使用Silverlight模型则会更容易实现。

使用HTML5，开发者可以保持用户界面的独立，并且拥有一个业务层；然而，必须在两个平台上编写大量的用户界面代码，这么做会付出更多精力而且几乎无法共享任何代码。

想个有根据的目的
最后，在选择工具时心中必须有着明确的目的，从而避免爱因斯坦所发现的混乱。选择正确道路是基于人们希望尽可能减小发生重大错误的可能性。例如，开发者可能熟悉WPF和Silverlight，并因此选择了这条道路。但是在对想做的应用程序进行探索后，他们发现可能希望在六个月到一年内推出某种移动客户端。更重要的是，他们想让人们能通过多种设备进行访问。

此时，只要他们准备最终转到HTML5或者为每个移动平台编写本地应用程序，即使之前选定了Silverlight解决方案也没有关系。如果并非如此，那么这将是一个非常昂贵的选择。

从另一方面来说：由于每个人都在说，“这是未来的趋势。”，那么这可能成为一种追随HTML5的推动力；因此，即使客户的所有开发者都拥有Visual Studio，而且被授权可使用那些最新和最好的微软工具，只要做出了决定，就要坚持朝着确定的方向走下去。

如果他们可以很好地控制部署环境，并且在接来下的六个月内他们将不引入任何Linux或Mac设备，那么他们也许正在犯下昂贵的错误。当然他们可以追随Silverlight，这将使他们能够更快地进入市场，也可以更有效地利用他们当前的技能和工具集。

归根结底：只要开发者能做出明智的选择，无论Silverlight还是HTML5都不错。

应用最佳选择
既然微软必须强烈支持HTML5，那么现在微软已经无法控制移动市场。他们不再发号施令，而值得怀疑的是如果他们能做到的话，是否会那么做呢。微软的策略是尽可能地应用最好的工具和平台，无论它是否是专有的。

根据微软的声明，“在网络上，Silverlight的用途从来都不是要替代HTML；它做的是一些HTML（以及其他技术）不能以方便开发者的方式去深入了解的事情。微软仍然致力于使用Silverlight通过使HTML尚未涉及的解决方案成为可能来扩展Web。从HTML页面中简单丰富的数据孤岛，到浏览器中完全类似于桌面程序的应用程序，甚至更强大，Silverlight使得应用程序可以提供各种用户所需的丰富体验。”

显而易见，在可预见的未来Silverlight和HTML5将共同繁荣。 ]]> http://www.guende.com/read.php?86 guende <admin@yourname.com> Mon, 05 Dec 2011 06:56:45 +0000 http://www.guende.com/read.php?86
Date4j为在Java中处理日期提供了一套新的解决方案，但与Joda Time所关注的范围完全不同。对比如下：

Joda Time                                      Date4j
拥有的类的数量: 140+                     拥有的类的数量< 10
包含可变和不可变类                        仅包含不可变类
强调速度和功能                              强调简单和有效
支持格里高里历（Gregorian）、
科普特语日历（Coptic）、
伊斯兰教历（Islamic）、
佛历（Buddhist）等等                     只提供对格里高里历的支持
可以完全取代JDK日期类                   和JDK日期类配合使用
精确到毫秒级操作                           支持到纳秒（十亿分之一秒）级操作
修复了天“溢出”的问题                      天“溢出”的问题可配置
针对的是通常意义的日期维护             适用于通过数据库来维护的日期
采用Apache 2.0授权许可                   采用BSD授权许可

虽然乍一看Date4j只具备了Joda中一部分的特性，但它有两个主要的特点是Joda所不具备的。

首先，Date4j的开发者宣称类库不应莫名其妙地将日期截断。Joda只支持毫秒级的精度而且在将来可能也不会改善。一些数据库也已经有了更好的解决方案。比如流行的PostgreSQL数据库对时间戳精度就已经支持到微秒级（百万分之一秒）。Date4j可在处理日期时对精度毫无损伤。

第二个特征是日期“溢出”的问题，例如向某个日期增加一段时间后，日期落在下月的情况。最简单的例子就是在3月31日增加一个月的计算：

DateTime dt = new DateTime("2011-03-31");
DateTime result = dt.plusMonths(1);
System.out.println(result.toString());当使用Joda Time时，会输出4月30日，但这也许并不是你想要的结果。

鉴于这种不确定性，Date4j为您提供了4种选择：

1. 第一天
2. 最后一天（与Joda Time相同）
3. 日期顺延
4. 抛出异常

以下通过举例的实例来说明，用Date4j替换Joda后的输出差异：

DateTime dt1 = new DateTime("2011-03-31");
DateTime result1 = dt1.plus(0,1,0,0,0,0,DayOverflow.FirstDay);
System.out.println(result1.toString());
//会输出 2011-05-01 (5月的第一天)
    
DateTime dt2 = new DateTime("2011-03-31");
DateTime result2 = dt2.plus(0,1,0,0,0,0,DayOverflow.LastDay);
System.out.println(result2.toString());
//会输出 2011-04-30（4月30日，与Joda输出结果相同）

DateTime dt3= new DateTime("2011-03-31");
DateTime result3 = dt3.plus(0,1,0,0,0,0,DayOverflow.Abort);
System.out.println(result3.toString());
//抛出运行时异常（Runtime Exception） 下面的代码展示了DayOverflow.Spillover中的选项：

//Joda Time代码
DateTime dt = new DateTime("2010-12-31");
DateTime result = dt.plusMonths(2);
System.out.println(result.toString());
//输出2011-02-28（2月的最后一天）

//Date4j代码
DateTime dt1 = new DateTime("2010-12-31");
DateTime result1 = dt1.plus(0,2,0,0,0,0,DayOverflow.FirstDay);
System.out.println(result1.toString());
//输出 2011-03-01（3月的第一天）

//Date4j代码
DateTime dt2 = new DateTime("2010-12-31");
DateTime result2 = dt2.plus(0,2,0,0,0,0,DayOverflow.LastDay);
System.out.println(result2.toString());
//输出 2011-02-28 （2月28日，与Joda输出相同）

//Date4j代码
DateTime dt3= new DateTime("2010-12-31");
DateTime result3 = dt3.plus(0,2,0,0,0,0,DayOverflow.Spillover);
System.out.println(result3.toString());
//输出 2011-03-02（3月第二天）如果应用对精度要求较高并且在处理数据库日期时不想对精度有所损失，或者在处理跨月份日期时想有更灵活的方案供选择，Date4j会是一个不错的选择。现在，源代码已可直接下载。

]]> http://www.guende.com/read.php?85 guende <admin@yourname.com> Fri, 02 Dec 2011 00:38:13 +0000 http://www.guende.com/read.php?85
JQuery Mobile的主要特性列举如下：

针对触摸优化的布局与UI Widget，能够自动适应不同设备
Themable设计
跨平台与跨设备——支持iOS、Android、Blackberry、Bada、Windows Phone、webOS、symbian与Meego
渐进增强，使用JQuery Mobile构建的应用在能力较弱的设备上能够做到优雅降级
JQuery Mobile 1.0构建在JQuery 1.6.4之上，最新版的JQuery 1.7有一些突破性的变化，JQuery Mobile 1.1将会支持这些新变化。

人们对此次发布的反响 不一——Sencha Touch是个流行的替代方案，在哪个框架更好这个问题上人们也是众说纷纭。JQuery Mobile拥有更广泛的设备支持，但Sencha在所支持的设备上却表现出了更好的性能。你可以在移动设备上体验这两个框架提供的示例并自己做出决定。 ]]> http://www.guende.com/read.php?83 guende <admin@yourname.com> Sun, 23 Jan 2011 01:02:10 +0000 http://www.guende.com/read.php?83
Python已经成为系统脚本“事实上”的标准（在这个领域，它是Perl的后继者），但现在它还应用到了各种不同类型的应用当中。Python是Web开发者热衷的语言，特别是与Django框架的结合。由于Python易学性，越来越多的大学开始将Python作为教学语言了。
虽然2010年Java、C、C#以及Ruby的地位依然稳固，但PHP、Visual Basic和JavaScript却呈现出下滑的趋势。相对而言，Objective-C的使用率上升的最快（增速超过100%），但从绝对角度来看，Python则拥有最大的市场份额增长率。

Erlang和Scala等语言落后于Prolog，位列50名左右。Groovy处于36名，市场占有率为0.358%，但考虑到SAP的ABAP位列29名，拥有0.5%的市场份额这个事实，Groovy还算是不错的了。

虽然.NET与动态语言的占有率不断攀升，但我们也看到Java、C和C++的地位在过去十年还是非常稳固的。

面向对象语言则拥有压倒性优势：

Object-Oriented Languages   55.8%   +1.4%
Procedural Languages           39.2%   -2.1%
Functional Languages           3.5%   +0.4%
Logical Languages           1.5%   +0.2%
从2007年开始，静态类型语言重新获得了人们的青睐。

你最喜欢的编程语言是什么？什么原因呢？你认为编程语言在未来十年的发展方向是什么呢？


Tags - erlangpython , groovy ]]> http://www.guende.com/read.php?82 guende <admin@yourname.com> Wed, 24 Nov 2010 08:47:53 +0000 http://www.guende.com/read.php?82 ARPARNET(Internet) ：阿帕网
ICCC ：国际计算机通信会议
CCITT ：国际电报电话咨询委员会
SNA ：系统网络体系结构(IBM)
DNA ：数字网络体系结构(DEC)
CSMA/CD ：载波监听多路访问/冲突检测(Xerox)
NGI ：下一代INTERNET
Internet2 ：第二代INTERNET
TCP/IP SNA SPX/IPX AppleTalk ：网络协议
NII ：国家信息基础设施(信息高速公路)
GII ：全球信息基础设施
MIPS ：PC的处理能力
Petabit ：10^15BIT/S
Cu芯片: ：铜
OC48 ：光缆通信
SDH ：同步数字复用
WDH ：波分复用
ADSL ：不对称数字用户服务线
HFE/HFC：结构和Cable-modem 机顶盒
PCS ：便携式智能终端
CODEC ：编码解码器
ASK(amplitude shift keying) ：幅移键控法
FSK(frequency shift keying) ：频移键控法
PSK(phase shift keying) ：相移键控法
NRZ (Non return to zero) ：不归零制
PCM(pulse code modulation) ：脉冲代码调制
nonlinear encoding ：非线性编程
FDM ：频分多路复用
TDM ：时分多路复用
STDM ：统计时分多路复用
DS0 ：64kb/s
DS1 ：24DS0
DS1C ：48DS0
DS2 ：96DS0
DS3 ：762DS0
DS4 ：4032DS0
CSU(channel service unit) ：信道服务部件
SONET/SDH ：同步光纤网络接口
LRC ：纵向冗余校验
CRC ：循环冗余校验
ARQ ：自动重发请求
ACK ：确认
NAK ：不确认
preamble ：前文
postamble ：后文
ITU ：国际电信联合会
character-oriented ：面向字符
bit-oriented ：面向位
SYNC ：同步字符
HDLC ：面向位的方案
SDLC ：面向位的方案
bit-stuffing ：位插入
STP ：屏蔽双绞线
UTP ：非屏蔽双绞线
RG-58A/U ：标准
RG-11 ：用于10BASE5
RG-59U ：75欧 0.25INCH CATV
RG-62U ：9欧 0.25INCH ARCnet
10BASE5 ：IEEE802.3
RG-59U ：0.25inch CATV
RG-62U ：0.25inch ARCnet
LED(light emitting diobe) ：发光二级管
ILD(injection laster diobe) ：注入型激光二级管
PIN ：检波器
APD ：检波器
intensity modulation ：亮度调制
line of sight ：可视通路
CCITT V.28(EIA RS232C) ：非平衡型
CCITT V.10/X.26(EIA RS423A) ：新的非平衡型
CCITT V.11/X.27(EIA RS422A) ：新的平衡型
TD ：发送数据
RD ：接收数据
XON/XOFF ：流控制
Automatic Repeat Request Protocol ：自动重发请求
Send and wait ARQ:continuous ：ARQ停等ARQ
Ward Christensen ：人名
Kermit ：协议
circuit switching ：线路交换
packet switching ：分组交换
virtual circuit ：虚电路
ATM(asynchronous transfer mode) ：异步传输模式
ATDM ：异步时分多路复用
packetizer ：打包器
VPI(vritual path identifier) ：虚路径标识
VCI(virtual channel identifier) ：虚通道标识
syntax ：语法
semantics ：语义
timing ：定时
OSI(open system interconnection) ：开放系统
session ：会话
synchronization ：同步
activity management ：活动管理
AE ：应用实体
UE ：用户元素
CASE ：公共应用服务元素
SASE ：特定应用服务元素
VT ：虚拟终端
JIM ：作业传送和操作
reverved ：保留
echo ：回送
discard ：丢弃
active users ：活动用户
daytime ：白天
netstat(who is up of NETSTAT)
qotd(quote of the day)
日期引用
chargen(character generator)
字符发送器
nameserver(domani name server)
域名服务器
bootps(bootstrap protocol server/client)
引导协议服务器/客户机
tftp(trivial file transfer)
简单文件传送
sunrpc(sun microsystems RPC)
SUN公司
NTP:network time protocol
网络时间协议
SNMP(SNMP net monitor)
SNMP网络监控器
SNMP traps
陷井
biff
unix comsat
daemon
e.g timed daemon
syslog
system log
URG
紧急字段可用
ACK
确认字段可用
PSH
请求急迫操作
RST
连接复位
SYN
同步序号
FIN
发送方字节流结束
Manchester
曼彻斯特编码
FDDI(fiber distributed data interface)
光纤分布数据接口
TTRT
目标标记循环时间
aggregation of multiple link segments
多重链接分段聚合协议
MAN(metropolitan area network plus)
城域网
CSMA/CD(carrier sense multiple access/collision detection)
载波监听
Token bus
令牌总线
Token ring
令牌环
SAP
服务访问点
request indictaion response confirmation
LLC PDU
LLC协议数据单元
DSAP address
目地服务访问点地址字段
SSAP address
源服务访问点地址字段
XID
交换标识
SABME
置扩充的异步平衡方式
DISC
断开连接
DM
断开
FRMR
帧拒收
solt time
时间片
AUI
连接单元接口
MAU
介质连接接口
MDI
介质相关接口
PMA
物理介质接口
SFD
起始定界符
PAD
填充字段
FCS
帧校验序列
PLS
物理层收发信号
slot time
时间
Inter Gap
帧
attempt limit
最大重传次数
back off limit
避免算法参数
Jam size
阻塞参数
max size
最大帧
address size
地址
collaspsed backone
折叠式主干网
BSS
基本服务集
ESS
扩展服务集
DFW-MAC
分布式基础无线MAC
IFS
帧间空隙
SIFS:
短
PIFS
点协调
DIFS
分布协调
CTS
发送清除
DQDB(IEEE802.6)
分布式队列双总线
TDM
时分复用
TMS
多时分交换
TSI
时间片互换
TST
网络机构
TSSST STS SSTSS TSTST
网络机构
PSTN
公用交换电话网
public switched telephone network
详细
PBX:private branch exchange
专用交换网
PABX;private automatic branch exchange
自动交换机
CBX:computerized branch exchange
程控交换
SLIP:serial line IP
串行IP
LCP(link control protocol)
链路控制协议
NCP:network control protocol
网络控制协议
BRI
基本速率接口
PRI
群速率接口
LAPB:line access protocol balanced
链路访问协议平衡
registration
登录
interrupt
中断
LAP F link access procedure for -mode bearer serives
太长了
rotate
不知道
recovery
恢复
discard
丢弃
retransmission
重传
switched access
交换访问
intergated access
集成访问
alerting
警告
progress
进展
AAL
ATM适配层
GFC
总流控
cell rate decoupling
信元率去耦
SDH
同步数字级
PDH
准国步数字级
GSM:group special mobile
移动通讯
NSS
网络子系统
OMC-R
操作维护中心
BSS
基站子系统
BSC
基站控制器
BTS
基站收发信机
MS
移动站
SIM:subscriber identity module
标识模块
MSC
移动交换机
HLR
归属位置寄存器
VLR
访问位置寄存器
AUC
鉴权中心
EIR
设备识别寄存器
OMC-S
操作维护中心
SC
短消息中心
WAP
无线应用协议
WAE
无线应用层
WSP
会话层
WTP
事务层
WTLS
安全层
WDP
传输层
MAP
移动应用部分
WML无线标记语言
SSL:secure sockets layer
安全套接层
PCS
个人通信业务
PCN
个人通信网
GEO
对地静止轨道
NON-GE0(MEO,LEO)
不清楚
ITU
国际电信联盟
VSAT:very small aperture -terminal
甚小天线终端
LEOS
低轨道卫星通信系统
repeater
中继器
bridge
网桥
router
路由器
gateway
网关
ONsemble stackable 10BASE
可叠加组合型集线器
transparent bridge
传输桥
source routing bridge
源路径桥
broadcast storm
广播风暴
encapsulation
封装
translation bridging
转换桥接方式
SRT
源地址选择透明桥
offset
偏移
more flag
标识
ICMP
INTERNET控制报文协议
SPF:shortest path first
最短路径
IGP:interior gateway protocol
核心网关协议
EGP:exterior gateway protocol
扩展网关协议
RIP:routing information protocol
路由信息协议
OSPF
开放最短径优先协议
acquisition request
获取请求
acquisition confirm
获取确认
cease
中止
poll
轮询
IPX/SPX internetwork packet exchange/sequented packet exchange
NOVELL
interpreter
解释器
redirector
重定向器
SFT system fault tolerant
系统容错
ELS entry level solution
不认识
ODI
开放数据链路接口
NDIS network device interface specification
网络设备接口...
DDCS
数据库管理和分布数据库连接服务
DCE:distributed computing environment
分布计算环境
OSF:open software foundation
开放软件基金
PWS:peer web service
WEB服务器
OEM
原始设备制造商
RAS
远程访问服务
IIS:Internet Information server
INTERNET信息服务
WINS:windows internet name system
WINDOWS命名服务
NTDS:windows NT directory server
NT目录服务
TDI
传输驱动程序接口
schedule++
应用程序,预约本
COSE:common open software environment
普通开放软件环境
RPC
远程过程调用
SNMP:simple network management protocol
简单网管协议
SMI:structer of management information
管理信息结构
SMT:station management
管理站
SMTP:simple mail transfer protocol
简单邮件传输协议
SNA:system network architecture
IBM网络
SNR:signal noise ratio
信噪比
SONENT:synchronous optical network
同步光纤网络
SPE:synchronous payload envelope
同步PAYLOAD信
CMIS/CMIP
公共管理信息服务/协议
CMISE
公共管理信息服务
agent
代理
IMT:inductive modeling technology
不知道
plaintext
明文
ciphertext
脱密
encryption
加密
decryption
解密
symmetric key cryptography
对称加密
asymmetric key cryptography
不对称加密
public key
公钥
private key
私钥
DES:data encryption standard
数据加密标准
IDEA:international data encryption algorithm
国际加密算法
PIN:personal identification number
个人标识符
session key
会话层密钥
KDC:key distribuetion center
密钥分发中心
sign
签名
seal
封装
certificate
证书
certificate authority CA
证书权威机构
OSF
开放软件中心
AFS:andrew file system
分布式文件系统
ticket
凭证
authenticatior
身份认证
timestamp
时间标记
reply attack
检测重放攻击
realm
域
PKI
公钥基础设施
certificate hierarchy
证书层次结构
across certificate
交叉证书
security domain
安全领域
cerfificate revoke list(CRL)
证书层次结构
LDAP:light weight directory access protocol
协议
access matrix
访问矩阵
ACL:access control list
访问列表
reference monitor
引用监控器
course grained
粗粒度访问控制
medium grained
中粒度访问控制
fine grained
细粒度访问控制
CORBA
面向对象的分布系统应用
MQ
报文队列
VPN
虚拟专网
IPSEC:IP security
安全IP
SA:security association
安全??
encopulation security payload
封装安全负载
AH:authentication header
鉴别报头
IKE:Internet key exchange
交换
rogue programs
捣乱程序
IPSP:IP security protocol
安全
IKMP:internet key managemetn protocol
协议
IESG
Internet工程领导小组
SHA
安全散列算法
MAC:message authentication code
代码
CBC
密码块链接
SSL
安全套接层协议
cerfificate verify
证书检验报文
PEM
私用强化邮件
PGP:pretty good privacy
好的
private
保密
authenticated
已认证
SEPP
安全电子付费协议
SET
安全电子交易
middleware
中间件
GSS-API
通用安全服务
SNP
安全网络编程
BWD:browser web database
浏览WEB
plugin
插入件
basic authentication scheme
不知道
digest authentication scheme
摘要认证方法
open group:the open group research institute
研究所
DCE:distributed computing environment
分布式计算机环境
SLP:secure local proxy
安全局部代理
SDG:secure domain proxy
安全域代理
OMG:object management group
目标管理组
CORBS:common object request broker architecture
不清楚
authentication
鉴别
access control
访问控制
data confidnetiality
保密
data integrity
数据完整性
non-reputation
防止否认
enciphermant
加密机制
digital signature mechanisms
数据完整性
authentication mechanisms
路由控制机制
notarization mechanisms
公证
trusted
可信
security labels
安全标记
event dectection
事件检测
security audit trail
安全审计跟踪
security recovery
安全恢复
TCSEC:trusted computer system uation criteria
标准
TCSEC TNI:trusted network interpretation of the TCSEC
标准
TCSEC TDI:trusted database interpretation of the TCSEC
标准
ITSEC:information technology security uation
标准
CC:command criteria for IT security uation
安全
classified criteria for secruity protection
中国安全
of computer information system
中国安全
GB17859-1999
国标
TCB:trusted computing base
SNMP:simple network management protocol
网管
ICMP:internet control message protocol
互联网控制信息协议
ARP:address resolution protocol
地址解析协议
TCP:transmission control protocol
传输控制协议
UDP:user datagram protocol
用户数据报协议
SMTP:simple mail transfer protocol
简单邮件传输
DNS:domain name service
服务器
NSP:name service protocol
服务器
TElnet:telcommunication network
TEL
EGP:exterior gateway protocol
外部网关连接器协议
IGP:inter gateway protocol
内部网关连接器协议
SLIP
串行接口协议
PPP
点对点协议
UNICAST
单播地址
cluster
群集地址
multicast
组播地址
scable model
可伸缩模型
integrated model
集成模型
OLAP
联机分析工具
NAS:network applications support
DEC公司的工具
NWC:newwave computing
HP工具
OCCA:open cooperative computing architecture
开放合作计算体系结构
DAA:distributed application architecture
DG的分布应用体系结构
COSE:common opensystem enviroment
通用开放系统环境
CDE:common desktop enviroment
通用桌面环境
DCE
分布式计算环境
RPC
远程过程调用
DME
分布管理环境
OSE/APP
开放系统环境应用可移植框架
ODA
开放文件体系结构
ODL
开放文件语言
]]> http://www.guende.com/read.php?81 guende <admin@yourname.com> Wed, 24 Nov 2010 08:45:58 +0000 http://www.guende.com/read.php?81
    大家知道，Linux系统源于“仿真”Unix操作系统，体格强壮，稳健异常，很像非洲的大河马，你根本别想把它“搬倒”。但是，它的图形界面使用的却是X.org系统，笨重无比，就像QQ那样，这是客观事实。X.org是二十多年前的老系统了，比Linux本身还要“老资格”，一老一小，两者不“般配”。X.org过于复杂，过于沉重，系统文件太多，致使Linux桌面系统运行速度上不去（当然，目前已经算是很快了），拖住了Linux桌面进一步提高品质的后腿。

    2008年11月3日，Kristian Hogsberg提出一个大胆设想，给X“瘦身”，用C语言重写X服务器的全部源代码，搞一套轻型的X服务器，同时，Kristian给它其了个很好听的名字：Wayland（美国地名）显示服务器。那时，他为Wayland显示服务器搭起了一个非常粗糙的框架，只有3,200行C源代码。但是，Wayland开发计划的方向对头，思路正确，后面立即跟上一大帮追随者，大家动手干了起来。（注：请见“Wayland: A New X Server for Linux”，2008年11月3日）

    现在的互联网“可牛”了，即时通讯（ICQ、IRC）非常便利，无论你在世界何处，干起活儿来就如同在一间办公室里面，说说笑笑真愉快，多人干活不觉累。如今两年才过去了，Wayland开发计划已经初见成效，展露头角。今年11月4日，Wayland轻型显示服务器就被Ubuntu奠基人Mark Shuttleworth先生“一眼看中”，决定吸收到Ubuntu 11.04新版本（2011.04.28发布）里面。对此，有不少人大发议论，“太冒进了”，“不可思议”，“简直是发疯”，……可见，老外也有这种“拖后退腿”的人。

    刚才，我查看了几幅用Wayland制作的截图，感觉就是不一般，有一种很“轻快”的感觉，我以前从来没有见过这种类型所“人造图形”。我十分惊叹人类的智慧，竟然能够运用极为抽象的C语言编写出如此美妙的人间从来没有过的“图画”（或画面），真是绝了！11月14日，在最近召开的“Linux Plumbers Conference”（“Linux开发者大会”）上，又传出消息，Fedora 15（2011.05.10发布）新版本亦将采用Wayland显示服务器。如此一来，各种不同的声音就要少多了。但是，摆在Wayland前面的工作（或道路）还是很艰巨的，知难而上，这才是Linux开发者的本色！

    说明：在不久将来（或在1～2年之后），Linux桌面的“容貌”必定会越来越漂亮（或亮丽），比Win 7更加漂亮（比苹果也不差！），就像一位体格健美的大姑娘，不愁嫁不出去，连XP用户也得瞅上一眼，说不准儿也会偷偷地把XP黄脸婆踢出去另寻新欢呢！



Tags - linux , 图形界面 ]]> http://www.guende.com/read.php?80 guende <admin@yourname.com> Wed, 29 Sep 2010 08:35:02 +0000 http://www.guende.com/read.php?80
首先，David Chou鼓励开发人员把Azure看作“另一个基于Windows服务器的开发环境，你可以往上部署代码... 其模型可以理解为一个巨大的zip文件。如果你能把应用放入一个闪存驱动器，而且还能从驱动器中启动应用，那么就可以在Azure上运行你的应用了”。理论上这意味着只要Java开发人员为自己的应用绑定完整的JRE，然后写个小的C#引导程序就可以在Azure上运行Java了。

但实际上，一个典型的Java程序必须克服一些障碍才能运行。据Chou先生所言，依赖Java的NIO功能或使用了内部网络通信（例如Jboss集群）的应用是不能在Azure的网络沙箱内运行的。

为了说明这些限制，Chou先生描述了他是如何让一个基于Jetty的应用程序运行在Azure上的：

使用Visual Studio创建Azure应用框架；
把Jetty NIO ChannelConnector换为阻塞的IO ChannelConnector；
以C#程序员的视角编写逻辑代码找到内部和外部端口，并用正确的端口参数启动Jetty；
在Java应用的包内绑定Jetty应用容器和JRE；
把Jetty的配置中涉及写文件系统的信息全部注释掉（这是个可选项，但如果你想绕过它，就需要编写更多的C#代码）。
Chou先生认为目前在Azure上进行Java开发具备如下特点：

这是漫长旅途中的第一步，我感觉又回到了刚开始用Java开发的时候，而且我们没有IDE集成开发环境。构建客户端应用时我们不得不使用文本编辑器处理AWT。现在的阶段是：我们可以使用Java和部署一个完整的Java应用，但事实上还有很大的改进空间。

4季度会发布SDK1.3版本，Chou先生保证开发人员会更容易使用网络沙箱，减少限制，并提供更多的管理回调机制，用来启动进程、解压缩、用C#脚本引导应用。当问道哪种类型的用户试图把Java部署到Azure上时，Chou先生介绍了Domino's Pizza项目，微软提供帮助把基于Tomcat的应用迁移到了Azure上。除了把应用迁移到Azure的计算资源上，同时也把数据存储迁移到了微软的云存储中。这次迁移的动机是为了解决晚餐期间超过50%的交通高峰期，特别是在周五和周日的超级杯（美式足球冠军）。当问及这个试点项目是否着手实施了，他表示该项目仍处于构思阶段。

总的来说，如果你是个Java开发人员，而且安装了Visual Studio，同时还有一个对网络需求不敏感的Web应用，该应用没有使用太多的J2EE特性，那么你可以尝试将其部署到Azure的云上。其他人最好等年底SDK1.3的发布。想了解更多信息，请参加JavaOne周四早八点Chou先生的演讲。

Tags - azure , jetty微软 ]]>