http://www.guende.com/index.php zh-cn http://www.guende.com/read.php?26 guende <admin@yourname.com> Fri, 22 Jan 2010 04:11:40 +0000 http://www.guende.com/read.php?26
MySQL到SQL Server的迁移分为3个步骤。首先需要将MySQL schema转换成SQL Server语法；接下来创建一个新的SQL Server数据库并加载转换后的schema；在用metadata explorer校验完新的schema之后就可以使用该工具迁移数据了。

目前的CTP 1仅支持表、索引和约束。根据微软程序经理Denis Vnukov所述，工具的最终版将会支持存储过程、函数、触发器以及视图。

现在可以从微软网站上下载CTP 1。该迁移工具还适用于Access、Oracle以及Sybase。


Tags - sql , azure, , server , 2008, , mysql, , 2005 ]]> http://www.guende.com/read.php?25 guende <admin@yourname.com> Fri, 22 Jan 2010 04:10:07 +0000 http://www.guende.com/read.php?25
正如他们所说，三个人都确信精益/看板社区本身毋庸置疑。“我们强烈地被与Chris Matts的谈话所影响，还有他对‘更少领导者，更多领导力’的呼吁”。

Liz说到：“由于本性，我们想要避免将此升格为某种人们可以签署的集权式的声明。如果你对其有足够强烈的感觉，以至于想要签署它，那么就复制它。将它发表在你自己的站点上。将它归属于你得到副本的地方——对我们来说，共享比创建更重要——然后随便地去改变它，那样它才能反映你自己的价值。我不认为任何像这样的声明会是完美的，我们也不会完美地实现它。

我是思考者社区的一名成员。

我相信社区是作为专业人士学习、讲授以及反思他们的工作的家而存在的。

我要求软件行业的每个社区都应该：
将反思和荣誉都归于使其能够存在的从业者
为它的成员提供优秀的经验。
在成员的专业交流的所有方面，支持它的成员为其客户和同事所提供的优秀经验。
作为主体，例证其成员专业且有人情味的行为。
通过对各种各样并且有分歧的观点谨慎的探究，在社区内以及跨社区进行参与和合作。
开放地拥抱进入社区的新人，主持进行中的进程；并且
通过持续的反映和提高，促进社区和成员的持续健康。
我相信每个社区中的领导者都有责任展现出这些行为，而展现出这些行为的人也会成为领导者。

我是思考者社区的成员。如果我恰好比其他人更好地起到催化剂的作用，那么我会考虑为所有启示过我的人送上礼物。



“思考者的社区”一文由Liz Keogh、Jean Tabaka和Eric Willeke撰写，它遵循创建一般的类似的特性分享的3.0许可。请将你的副本和衍生物归属于分发者。
由于最初发表的时候，很多人都在上面签名：Lisa Crispin、Olaf Lewitz、Patrick Wilson Welsh、David Bland和我自己。此外，Chris Matts 和Olav Maassen也添加了很棒的观点：

和启示我的人不同，我是一名从业者。对我来说，敏捷、精益和看板都是次要的。我的工作是要传递业务价值和由社区提供的帮助我做到这一点的工具。作为从业者，我会发现我需要解决的问题。我将这些解决方案反馈给社区。我不是领导者，并且不想成为领导者。我愿意认为我是“思考者社区”的成员。而且我愿意因为我为那些社区所做的贡献而受到尊敬。我愿意被社区所尊敬，以至于可以一直给我新的想法，而不是坚持让我订阅正统的说法。

…

那么领导者和领导能力之间有什么不同呢？

领导者感觉上像是承诺（某种在必须的时候才会喜欢的东西）

“如果你想成为我们的俱乐部的成员，那么就要这么做。”，

“我的路或者是大道”，

“你要么和我们一起，要么和我们对立”

领导能力感觉上像是意见（这是我所喜欢的，因为它允许自由选择）

“这是你所能做的方式，它在特定的环境中对我有效。”，

“你可能想要仔细检查X，因为它看起来与你所做的相关。”
你是思考者社区的一分子吗？


Tags - 敏捷宣言, , 社区 ]]> http://www.guende.com/read.php?24 guende <admin@yourname.com> Fri, 08 Jan 2010 04:53:59 +0000 http://www.guende.com/read.php?24
“我们甚至不称之为试用版（beta）——而称之为‘早期体验版’，或者‘预览版’”，Sun的开发工具工程部门的负责人David Folk在一个大会上说，“该工具的真正目的是让你能用JavaFX开发基于表单的应用程序”

这款新的JavaFX工具的基本思想类似于针对Swing的Matisse项目，它提供了与VB或Delphi非常相像的可视化编辑器，简化了Swing的开发工作。与Matisse一样（它后来变成了NetBeans 5的GUI编辑器），JavaFX工作台在你工作时为你生成代码，而且，尽管你可以查看生成的代码，但不爽的是你不能对其生产的代码进行修改。

当你从调色板（palette）中拖拽一个JavaFX组件到设计区时，你可以为它们绑定数据源。该插件目前支持JDBC数据源、HTTP (XML / JSON)、文件系统（FileSystem)、文件数据源以及内建过滤器。它还提供一些简单的转换器，通过他们你可以方便地将某数据源（比如REST或JSON数据源）绑定到一组组件上。

除了支持简单地拖放组件的功能外，该插件还有一个“状态”的概念。状态从最初的主状态（master state）开始，你还可以给这些组件或他们的布局增加新状态。应用运行时，比如鼠标点击的事件就可以引发状态转换，进而把你定义的行为自动反映在UI上。每个转换还上还能附带一个简单的动画，这样，你就能快速创建缩放，渐变和旋转等特效。

该工具还有很多其他有价值的特性，如概览（通过它你可以在不同的屏幕尺度上预览应用，如同在不同的设备上一样，如桌面，移动设备和HDTV等）以及预定义模板。利用模块你可以快速构建普通的GUI模式，比如向导按钮（取消、后退、下一步和结束等）以及索引按钮（前一步，下一步）。你可以便捷地添加这些按钮并进行客户化。

可能你已经想到，早期体验版的确有一些限制。例如，对于JavaFX 1.2中新增的关键组件，如图表（Chart），尚无可视化支持；还不能对组件的某些属性进行可视化编辑；此外，预览视图偶尔会“罢工”以至于必须重启IDE才能恢复正常。然而，花一个下午的时间来玩玩它却是了解JavaFX有啥能耐的一种愉快的方式。

与众多必需的工具一样，JavaFX需要通过一些瞩目的应用才能获得更多的订单。早期尝试它的公司有Ubivent，它的整个虚拟事件平台是完全基于JavaFX构建的。另外还有WhitStone Technology，他们在其整体服务平台和IT服务管理产品的工作流组件中使用了JavaFX。然而，对于JavaFX来说最重要的单子也许就是2010冬季奥运会，它的组织委员会是Sun的大客户，它在其网站上使用了基于JavaFX的金牌展示应用

Tags - javafx , mobile, , javafx脚本 ]]> http://www.guende.com/read.php?23 guende <admin@yourname.com> Fri, 08 Jan 2010 04:51:28 +0000 http://www.guende.com/read.php?23
XQuery 1.0: 新引入的查询和函数式编程语言，为查询XML数据集合而设计。它使用XPath表达式语法来访问一个XML文档的特定部分，并且有“FOR，LET，WHERE，ORDER BY和RETURN”表达式作为补充。通常缩写为"FLWOR"的这些表达式可以被用于以类似SQL的方式执行跨多个XML流的连接。
XPath2.0: 一个用于XML文档的表达式语言。一个XPath表达式的结果通常是从输入文档选择出的节点或者是原子值。XPath 2.0现在是XQuery 1.0的一个子集。XPath 1.0到XPath 2.0最引人注意的一个改变是引入了更加丰富的类型系统：每个值现在都是一个序列，一个单一的值将被视为长度为1的序列。XPath 2.0支持“模式认知”，意味着树的元素有类型注解，可以用于XPath导航。 一个解析器必须为内建的类型比如字符串，数字，日期等等提供模式认知。作为可选项，也有可能支持用户自定义类型，这将极大的简化所要求的表达式。例如，一个因特网邮件服务公司可能有一个XML文档，内容是与客户订单挂钩的记帐地址与投递地址。如果两个地址域都有一个公共的AddressType，表达式//element(*, tns:AddressType)/postalCode将会返回两个地址的邮编。XPath同时还提供强大的功能扩展集和操作符。新的功能包括用于模式匹配的正则表达式语法，新的日期函数比如当前日期，还有新的算术函数比如floor，ceiling和round。新的操作符包括intersect和except。
XSLT 2.0：一种用于将XML转换为一种新XML格式，或其它的表示格式，比如HTML,XHTML或SVG的编程语言。如XQuery 1.0一样,XSLT 2.0也使用XPath 2.0作为路径解析语言。XSLT 2.0加入了一系列的功能，包括grouping——从一个单一的输入文档输出多个结果的能务，以及在XSLT中定义可以被XPath调用的函数的能力。 因此一个XPath 2.0解析器或者XSLT解析器可能会是“模式认知”的。这样将会带来许多优势，比如在XSLT转换前可以检验输入树，并且可以检验输出树以合格证XSLT转换产生正确的结果。 你可以可以为变量指明数据类型，输入参数，来自函数的返回值，用户自定义函数以及模板。XSLT继续成为转换XML数据的主流选择，而XQuery有望成为查询XML文档的标准。由于XQuery与XSLT 2.0两者都使用XPath 2.0作为路径解析语言，XQuery对于XPath 2.0的扩展对于XSLT开发者来说就无关了。
为了寻求该功能包的更多细节，InfoQ采访了它的首席架构师，Andrew Spyker：

InfoQ:XML显而已见已成为在企业计算中广泛应用的格式。你能给我们提供一些例子，哪一类型的应用中这些标准的新功能有可能会引起特别注意？

XML已在企业计算中非常流行的前提下，要讨论能用到这一功能包的每一个场景将非常困难。因此，下面要提到的并不是所有——而只是作个说明。
查询和表示来自于XML源数据的应用。例如，博客feed，评论以及与feed相关的分析。你可以考虑这样一个应用，它挖掘你所有的博客，查找有问题的评论内容，再将这些信息表示为web表格的形式，允许你调查其趋势并将特定的评论者标记为不受欢迎的。不断发展下去，你会选择将这一列表存储在数据库里，这样就可以先行一步判定不受欢迎的评论。由于这一场景里所有的输入源都是XML和XHTML(XSLT 2.0里新支持的序列化格式)可以方便地被用于web展示，使用基于XML的编程模型再自然不过。在功能包里有一个示例应用就演示了这一点。

使用业界标准模式的应用。几乎每个垂直行业都要与业界标准模式打交道，并且许多企业都扩展了这些模式来定制自己的业务。在过去，使用XPath 1.0(并且依赖于XSLT 1.0)，XML运行时不知道模式知识。这意味着如果你查找所有PurchaseOrder类型的数据元素，你必须在你的搜索中硬编码每一个可能吻合的名字。即使最好的情况下这也会带来代码维护的困难，而最坏的情况当企业扩展现有类型而引入新类型时，脆弱的代码就会失效。而在XPath 2.0 (以及相关的XSLT 2.0和 XQurey 1.0中)，你可以在查询中根据类型搜索。

使用XPath 1.0和XSLT 1.0的应用。这似乎是显而易见的，但也值得单独提出来。XPath 2.0和XSLT 2.0考虑了业界使用7年以来积累的经验。新功能提供了许多新的功能性场景(一些例子是：多种语言的比对支持以及XSLT 2.0的多输出)，这些之前是不可能做到的。 同时，这些能力还加入了对模式的支持，而这些模式用XSLT 1.0表达则过于复杂(例如，grouping的支持)，这些支持将会使得代码减少，易于维护并会比以前执行得更好——因为现在是运行时提供支持而不是在运行时之上编码。

跨多个数据源查询数据的应用。尽管一些原生支持XML的数据库有时也支持XQuery(DB2 pureXML即是一例)，但在中间件级别支持XQuery可以允许在这些XML数据库与数据库之外的XML存储之间进行连接。 一个例子是一个批处理文件，处理一个XML数据库的数据，并通过调用Web 2.0 API来丰富数据，然后将其存储到另一个数据库。 该XML功能包通过一个可以在服务器JVM环境之外的标准Java SE应用瘦客户端来支持这一场景，只要它以支持应用服务器功能的方式被使用。

如我之前所说，有很多可能的应用场景。所有可能的应用只局限于企业所存储的XML数据或文档——而这是非常巨大的。

InfoQ: XSLT 2和XQuery 1这样的语言处理XML相比Java DOM模型在多核或者云计算的环境里有什么优势呢？

使用如XML功能包所支持的声明式(vs.命令式)的以XML为中心(vs.以语言为中心)的语言主要有两大方面的优势。
首先，声明式编程询问用户他们想要做什么事。这与命令式编程是相反的(例如，操作DOM或JAXB API的Java代码)，询问的是用户想要如何实现他们想做的事。Declarative programming leads to smaller, 声明式编程带来的是可适应快速变更的更精简，更易维护的代码。它同时还支持用户向XML运行时表达他们的兴趣，或者是他们想要如何查询或转换数据，这种方式运行时可以进行优化，而如果用户直接告诉运行时具体怎样执行则无法做到优化。这一区别在多核及云计算的环境下非常重要，你可以想像得到，优化不仅仅能认出可以单核CPU下执行更出色的模式，在多CPU或跨虚拟环境的条件下也能出色的执行。 还有，因为XSLT和XQuery是函数式并且无副作用，你可以完全安全地执行这样的优化——而在命令式语言里使用典型的编程API是无法做到这一点的。另外，我个人相信，从长远来看，高级的声明式语言会更加迎合云计算，因为它们比那些假设特定运行时环境的低级语言可移植性更强。

第二点，以XML为中心(vs. Java或C#等其它语言)，就是将XML类型系统作为核心类型系统。 将XML类型系统映射为原生语言的类型系统有两方面的劣势。首先，有一个XML保真性的问题。将XML映射为对象表示十分困难，稍不注意就有可能造成信息的丢失。像JAXB2.0这样的API处理这类问题非常棒，但到最后映射成一个完美的无损的XML表示，对比纯XML模型并不见得有什么好。 其次，因为我们转换了类型系统或转换成DOM模型，我们加入了显著的性能开销。本质上这意味着数据拷贝，这在中间件是十分昂贵的操作应当予以避免。而以其原生的表示使用XML数据，我们可以保证没有数据丢失而且性能最优。鉴于XML作为业务与企业间的数据交换格式如此流行，拥有这两个益处是十分重要的。

我应该说明我们理解人们不会将现有的应用全盘转变成XML编程模型。 因此，我们允许以一种简单的方式来将现有的Java数据和逻辑添加到XML运行时的执行。这一扩展是通过同一个一致的API来完成的，而不管使用的是哪一种XML语言。这一一致性是重要的，它统一了跨三种语言的编程体验，并且支持数据可以从XQuery 1.0到XSLT 2.0有效的流水。 我们同时还设计了API，以保证这一技术简单高效的多线程服务器应用。 之前的XML API是为客户端环境而设计的，相对于支持高效多线程编码而言更倾向于单一调用的简洁性。我们的API为所有的共享对象加入了线程安全，使得为服务器运用编程更加自然高效。

InfoQ：就操作XML而言，W3C标准与微软的LINQ相较而言如何？

一个关键的区别在于XML功能包实现的是公开制定的W3C XML处理标准。有着这样的一个标准作为根基，组织和开发者就可以更好的跨该标准的多种具体实现而利用这种一致的XML编程模型技术和工具。
InfoQ: 该功能包相对于Michael Kay的Saxon实现有什么优势？

先让我首先解释一下我观察到的所有来自业界的反馈——Saxon是非常优秀的XPath 2.0，XSLT 2.0以及XQuery 1.0实现。同时，Michael Kay与来自IBM和其它公司的贡献者一道，在驱动XML的W3C标准化方面作了许多工作。
Saxon及XML功能包都是实现的相同的标准集。所以从编程模型的角度来看这里保持了一种一致性。从运维的角度，WebSphere客户可以得到一个背后有IBM支持的XML实现，他们现有的WebSphere Application Server V7权利范围内的测试及支持也将得到保证。 就像我们上面所谈到的一样，我们可以看到许多客户想要在WebSphere之上实现基于XML的解决方案的应用场景。意识到这一点，我们想要以这样一种形式来提供支持这些标准的新功能，那就是我们的客户不管是现在还是将来都可以信赖它们。

InfoQ：你觉得什么时候我们可以看到这些技术能够融入Java平台而得以标准化？到那时你的实现将会怎样呢？

目前，Java通过JAXP支持XPath 1.0和XSLT 1.0，但不支持XPath 2.0和XSLT 2.0。同时，还有一个支持XQuery 1.0的JSR叫作XQJ。今后我们应当考虑在Java中实现普遍化的XQuery。 个人而言，我比较担忧面向连接的XQJ API以及用户要多大的需要去学习多种API(JAXP和XQJ)来运用XML标准。 Java平台正逐渐变得更加应变，这也是业界对它的要求，因此基于业界的支持和用户的需求我期待着这些标准能够被吸纳进该平台。IBM将会继续驱动XML的Java标准化过程，为用户创造价值。 如果Java平台的进展到可以处理XPath 2.0，XSLT 2.0以及XQuery 1.0，我们的实现仍可以保留。目前IBM的JVM也是用的自己的XPath 1.0和XSLT 1.0实现。IBM有这样的历史，在支持Java标准的同时，JVM的XML部分还提供高效的，可靠的，功能性的附加值。这些改进将会持续为整个WebSphere系列产品在XML处理，web服务和SOA等方面提供有力支持。

Tags - xslt, , w3c, , xml, , xquery, , websphere ]]> http://www.guende.com/read.php?22 guende <admin@yourname.com> Wed, 02 Dec 2009 08:51:09 +0000 http://www.guende.com/read.php?22
在使用ASP.NET MVC框架构建Web应用程序时，一个很常见的需求便是构造面向某个特定Action方法及参数的URL。老赵原本在他的MvcPatch项目（一个基于ASP.NET MVC进行改造以提高生产力的框架）中提供了一种基于表达式树的构造方式，但经过测试之后发现这种方式有很大的性能问题。因此老赵后来又提出一种流畅接口（Fluent Interface）：


public static class UrlHelperExtensions
{
    public static ActionOf Of(this UrlHelper helper) where TController : new()
    {
        return new ActionOf(helper);
    }
}

public class ActionOf
{
    public string Action(Func> action, T1 arg1, T2 arg2) {...}
}
他认为，这是一种用于构造URL的DSL，可以这样使用：

Url.Of().Action(c => c.Post, blog, post)
以上这行代码表示的含义是“URL of HomeController’s action ‘Post’ with parameter ‘blog’ & post.”，它将会生成一个URL。针对这个URL的请求便会被转化为HomeController.Post方法的调用，并且提供DSL中所指定的blog和post的值作为参数。老赵认为，这个做法从性能上比原本基于表达式树的构造方式要高出许多，并且充分利用C#编译器的类型推导能力，拥有较好的可读性。而更关键的是，这种做法可以在编译期对URL构造进行静态检查。

不过在随后的评论中，网友装配脑袋提出，这个API不适合VB，不能算是真正优美的解决方案，而且更重要的是，语言元素应该用做原本职责所在的事情（即“委托”应该用于方法调用）：

这种Url.Of().Action(c => c.Post, blog, post)的语法，真正给别人使用的时候，没有人会从方法签名或类的定义中快速看出它的使用方法。

另外你也应该能从我的代码里看出，在VB里，从方法名获得委托需要AddressOf运算符，你的代码就会变成Url.Of(Of HomeController).Action(Function(c)AddressOf c.Post, blog, post)。这其实代表了委托和方法语义上的差异。用这种语法，将造成滥用语义的倾向。

我觉得这条路彻底走歪了。从方法名获得委托，仅仅在用户明确知道是委托的上下文才有意义。你们不能滥用这个语法。

老赵则解释道：

其实我觉得API还是针对特定语言来说可能比较合适，否则的话，就算以前的Lambda表达式写法：Url.Action(c => c.Post(blog, post))放在VB里写起来还是麻烦。但是这种方式，其实微软本身也很推崇，在ASP.NET MVC 2里也有类似的API（不过不是做同样的事情）。

如果思考“非C#语言”语法的话，很多东西就不好办了，比如Moq。还比如F#的API也不会考虑C#的使用方式，语言特性不同么……我现在就好比是在为80%占有率的语言设计API，而只能忽视20%了，这是准备中的，除非有更好的设计，否则只能先满足这80%了……

另一网友Ivony则认为这似乎也不能算是走歪了：

委托不仅仅是方法的调用包装（透过委托可以调用方法），同样也可以是方法的信息包装（透过委托找到方法）。我们一般用前者，但不见得后者就歪了呀。

老赵又作了补充：

其实，是否可以从方法的签名中得出使用方式，这个我也不太在意。尤其是在视图中，我一般都把这些东西当作是DSL来看待，所以我会设计出“url of HomeController's action Post with...”这种语义的API。而使用的时候只要记住“用法”就行了，不关心“签名”究竟如何，就像使用不动点组合子来生成递归形式的HTML，从签名也实在看不出来。

的确，如果可以从签名看出来那自然最为理想，但是在DSL面前，这点还是让步吧，比如在FsTest里：

"foo" |> should equal "foo"
true |> should be True
这种东西，看should函数，be函数，not函数（的签名）……都是搞不懂该怎么用的，但就是为了让别人看明白写出来的代码，让别人知道该怎么写。

装配脑袋也进一步阐述了他眼中这种API的坏处：

用户不会想到这里是要写c => c.Detail，你没法限制用户第一层必须使用Lambda表达式，所以用户不可能思考到诸如Func<..,Func<>>是做这个目的的。

至于DSL，我觉得大部分尝试真的是玩具。论坛上好多人也热衷于折腾。但如果你想让你的类库有实用性，做API的时候正的必须要好好考虑所用语法的语义。

用奇技淫巧来写代码的时代已经过去了，C++的同僚们都开始清醒了……

Ivony认为，这种API虽然有问题，但其实也并非完全不可接受：

老实说我是没觉得这样优美的……不过我觉得这样也不算是特别的那啥。我明白你的意思了，如果这个东西作为API提供的确是不太合适的。的确是不能“自然”的直接悟出使用方式。

好吧，我的确没用API的高度去约束它。但实际上现在.NET的一些API的风格也在变，也有一些不是那么严谨的开始出现。我觉得这个度还是很难去把握。也同意你的观点。

接着，对于老赵眼中“较好的可读性”，装配脑袋也有自己的看法：

读着很通顺并不等于很容易地理解其行为。用户一般视方法为动作，每一步应该有每一步的语义。

Url.Of...这一步你想让用户看出什么语义呢？将Url转化为???类型吗？如果想让这个稍微有点语义的话，我看只能设计成这样：Url.CreateForType....

对此，老赵解释道：

我是看整句的：“Url of HomeController's action Post with paramters blog, post...” 其中只有“'s”和“with...”是我补充上去的，这也是我选择用Of作为方法名的原因。就像FsTest中：true |> should be True，它是作为一句话看代，而不是认为should作了一件事情，be又做了另一件事情。

还有比如Fluent NHibernate中：Reference().Not.LazyLoad()，我觉得这也是在从整句进行考虑，而不是一个方法便是一个步骤。

最后，Ivony也系统阐述了他对于API设计的思路：

嗯，其实我觉得应该说只是有分歧没矛盾。

你要我说，我欣赏老赵这样的语法么？老实说我不欣赏，虽然部分方法虽然是我提出的，但这种语法要我接受我还需要一些时间。我在考虑这个方法的时候，也过分的追求Action(c.Post)( blog, post )而不是Action( c.Post, blog, post )的形式，因为我觉得前者才像是函数调用，后者看起来就不像是函数调用了，这样会造成一些阅读障碍。对前种形式过分的追求还使得我竟然没发现后种形式是成立的（真是个低级错误）。

至于老赵所用的这样两个方法的配合，你要我说，我真的说现阶段在API我还是不能完全认同。……但我也觉得，虽然现在还难以接受，却也真的不是有什么强有力的根据说这种方式有多么不可取。诚然，这种方法如果按照传统的从方法签名参数含义来阐述，基本上100个人99个不知道怎么用。不给Demo几乎没办法正确的理解使用方式。

但是尽管我觉得别扭，却也不得不承认这样的方案不错。我并没有放弃语义更明晰的方案的探索和寻找，却也真找不出什么特别有份量的理由否决这种方式。

……

所以这种事情是个见仁见智的问题，接受是需要一些时间的，老实说我是比较传统的程序员。我坦白第一次看到XElement的构造函数的时候，我都觉得不是很舒服。这种事情怎么说呢，可以说现在双方的观点我都认同，所以说我觉得没有矛盾，只有分歧。从这个角度来说，A是合理的，从另一个角度来说，B是合理的。不存在一个角度A和B存在非此即彼的关系。

API的设计是个永远的话题。尽管语言不断增强，但对于人们对于优秀API依旧进行着不断地追求。对于这个话题，您能给出自己的见解吗？


Tags - 语法,领域特定语言 ]]> http://www.guende.com/read.php?21 guende <admin@yourname.com> Wed, 19 Aug 2009 12:18:49 +0000 http://www.guende.com/read.php?21
百度推出的“框计算”是要把所有用户的需求无论是在找信息，还是要求各种各样的应用，还是有什么其他的需求，都集成到一个框里，用一个框来满足用户的需求。

“框计算”为用户提供基于互联网的一站式服务，是一种最简单可依赖的互联网需求交互模式。用户只需要在搜索框中提出需求，系统就能明确的识别到这种需求，并同时将该需求分配给最优秀的应用或内容资源提供商处理，最终返回给用户相匹配的结果。
这个全新的概念收到了诸多专家的肯定。著名经济学家、国务院发展研究中心高级研究员吴敬琏教授表示：

中国增长模式陈旧，不可持续，在当前新的产业革命正在孕育的形势下，我们必须急起直追，迎头赶上。寄望于“框计算”能在振兴我国产业和实现新的产业革命中崭露头角，做出贡献。
而微软亚洲搜索技术中心工程总监刘激扬则认为：

“框计算”将为技术开发者提供更广阔的互联网技术开发舞台。
与专家们反应有所不同的是，技术社区内对该概念传出质疑的声音。有众多网友表示，该概念与当前流行的“云计算”太过接近。还有网友表示“框计算”听起来只是“产品用户界面的整合”，并无任何创新之处，甚至被部分网友戏谑为“‘诓’计算”。早在此之前，谷歌便提出“搜索一次到位”的整合搜索技术，该技术从描述上看与“框计算”并无本质不同之处。而且，该技术也并非百度原创：

2004年7月，Autonomy通过其位于美国旧金山的控股公司推出搜索工具Blinkx。这一工具可以提供类似“模糊搜索”或“语义搜索”的功能。该系统经过 “学习”积累了一定“经验”后，可以满足用户类似“最便宜的笔记本电脑是什么”“中国队能否赢得世界杯”这样的搜索需求。

Autonomy 公司是智能搜索技术发明者，目前在商用搜索市场居绝对领先地位，占这一市场55%以上的份额，英国警察署、美国本土安全局、国防部、航天局等政府部门，以及通用电器、通用汽车等企业，都是它的客户。但在民用搜索方面作为并不大，远不如Google、百度这么有名。
近期，谷歌又推出了当前搜索引擎的修订版“Caffeine”，据称谷歌工程师重新编写了搜索引擎的部分基础架构，而且速度更快。对于谷歌在技术上的步步紧逼，雄霸中文搜索市场的百度公司拿出创新技术加以应对，也是理所应当。

相似的是，前段时间百度强势推出的“阿拉丁”开放搜索平台，也被质疑和Google Base太过接近。虽然同为用户自定义提交结构化数据的产品，Google Base支持包括CSV、RSS和Atom在内的多种提交格式，而百度的阿拉丁平台则只支持百度自定义的XML格式，因此被指并不如名字一般“开放”。而百度方面则表示，“阿拉丁”作为“框计算”的重要部分，能够应对“暗网”的收录和检索，是“搜索引擎的未来”。

“框计算”作为一种占领用户终端的手段，对于未来用户终端的发展也将起到深远影响。CNET（中国）媒体总编刘克丽在会上表示：

李彦宏的“框计算”听起来很朴实，相信未来它终将改变所有的终端界面。
目前业界普遍认为，浏览器是未来终端的主力技术，无论是谷歌的Chrome OS，还是微软的Gazelle，都是遵照该理念进行技术创新。尚不知百度的“框计算”是否能成功颠覆这一思路，创造出新的终端技术。

另外，有媒体质疑该技术会影响互联网的生态环境，增加百度对中文互联网的垄断：

有了“框计算”，百度便不再是搜索引擎了，而是互联网世界的“南天门”。用户需要什么，都由百度这个“框”一手操办，要么是把百度自有的服务推给用户，要么是把商业合作伙伴推给用户。这个“框”不仅是用户进入互联网的大门，更像是一个绳索，绑架了用户，绑架了市场需求，绑架了合作伙伴。从这个角度来看，“框计算”似乎更像是垄断的代名词，打算对用户的互联网世界进行“包办”。
作为全新的概念，“框计算”究竟是中国领先的自主创新，还是山寨抄袭，请读者朋友们留下你们的一家之言吧？


Tags - 互联网 , 搜索 , 云计算 ]]> http://www.guende.com/read.php?20 guende <admin@yourname.com> Tue, 18 Aug 2009 00:43:10 +0000 http://www.guende.com/read.php?20
许多公司和开发人员正在从Java转向其他编程语言：Ruby、Python、Grrovy、Erlang或Scala等等。不过你可能做不到这一点。即便如此，你也可以改变你的编程风格，获取这些新语言的优势。事实上，在过去的15年中，Java编程风格也已经有明显变化了。

Stephan在文章中提出了以下几点：

尽可能地标注final：让所有东西不可变，把变量标为final可以阻止改变它的值。很多时候，重新为变量赋值会引入bug，你应该使用新的变量。除此之外，final可以提高代码的可读性。我针对这个话题还写过一篇文章：《Java中所有变量都应该是final的》
没有setter：许多Java程序员会自然而然地为类中所有的字段加上setter。思考一下，真的每个字段都需要修改吗？更好的方法是创建包含改变后状态的新对象。此外，也试着去除getter，我们应该遵循“Tell, don't ask”的思想。
避免使用循环来操作List：从函数式编程那里获得的经验，循环并不是进行集合操作最好方法。例如，我们可以使用Google Collections提供的过滤功能。 Predicate canDrinkBeer = new Predicate() {
     public boolean apply(HasAge hasAge) {
         return hasAge.isOlderThan( 16 );
    }
};

List beerDrinkers = filter(persons, canDrinkBeer);
使用单行代码：Java是一门繁杂（noisy）的语言，我们应该编写更精确的代码。尝试将代码写为一行。例如： public int add(int a, int b) { return a + b; }
使用大量接口：领域驱动设计已经大行其道，一个应该拆分为多种“角色”，即实现多种接口，提高复用程度。方法应该面向“角色”，而不是面向特定的类。我在《不要在Java中使用String》一文中讨论了更多这方面的内容。
使用Erlang风格的并发：Java的并发特性（如lock和synchronized）过于低端，难以使用。Erlang风格的并发是一种更好的做法。Java平台上已经有了Akka和Actorom。此外，也可以使用java.util.concurrent中的Join/Fork和数据结构进行编程。
使用Fluent Interface：Fluent Interface可以使代码更短，更容易编写。Google Collections中的MapMaker是个不错的示例： ConcurrentMap graphs = new MapMaker()
    .concurrencyLevel(32)
    .softKeys()
    .weakValues()
    .expiration(30, TimeUnit.MINUTES)
    .makeComputingMap(
        new Function() {
            public Graph apply(Key key) {
                return createExpensiveGraph(key);
            }
        });
避免在DTO中创建getter和setter：如果你拥有简单的DTO（Data Transfer Object），不要耗费精力去编写getter和setter，直接使用公开的字段吧。不过在你无法完全控制代码的使用情况时，还是小心为上。
这篇文章发表之后，有许多人发表了不同的看法。其中Cedric Otaku发表了文章《下一代Java与现在差不多》予以回应，其中反对了Stephan提出的大部分观点。

尽可能final：太多final会降低代码的可读性，它无法代码额外的好处。我已经不记得上次因为重新给变量赋值而造成错误是什么时候了。值得一提的是，在字段以外的成员上标记final违反了Google的风格指南。
避免setter：看上去不错，不过这不现实。有些时候你不愿把所有的参数都通过构造函数传入。此外，如果使用对象池的时候，可变的对象会让编程更为方便。Stephan不是第一个提出要将访问器（accessor）从OO编程中移除的人，不过这个说法很明显不可行。
避免循环：Java并不适合函数式编程风格，所以我认为使用Predicate的代码反而难以读懂。我估计大部分的Java程序员会同意我的观点，即使他们已经熟悉了闭包风格。
单行代码：这要视情况而定。并引入临时变量把一个表达式拆开可以提高代码可读性，也容易为其设置断点。
使用接口：不错的建议，但也不能过火。过去我也争论过类似的话题，不过引入太多接口会导致细小类型的爆炸，使你高端的类型意图变得模糊。
Erlang风格并行：重申一点，使用Java设计以外的编程风格是危险的做法。java.util.concurrent中包含了非常有用的功能，我遇到过不少基于这些元素的Java抽象，它们要优于Erlang风格的actor架构。
Fluent Interface：这个建议比较有趣，它与Stephan提出的另一个建议“避免setter”相违背。Fluent Interface制式setter的另一种形式，不是吗？
使用公有字段：不，千万别这么做。你不会因为加了访问器而后悔，但是我能保证你会因为一时偷懒，使用了公有字段而后悔莫及。
在Cedric的文章之后，Stephan又对他的说法进行了补充：

没有setter并不代表你不能修改这个对象，我只是说纯粹的setter不是面向对象的思维方式。例如，你觉得stop()和setStop(true)哪个更好一些？

（针对Predicate代码不易读）我认为你的假设有误。循环是“程序化”的代码，而Predicate是经过封装的，可以重用的，易于理解的“对象”。这里并没有函数式编程，这里是纯粹的OO - 我提起FP只是因为我从那里“引入”了这个方式。

还有许多人对Stephon和Cedric的文章发表了评论，例如有人支持Stephan的观点，认为final的可以更好的表示出代码的意图。甚至有人提出：

更简单的解决方案是使用Scala :) - 不可变的状态、统一访问原则（字段、属性、方法看上去一样）、单行代码、使用monads或函数来替代循环……这些特性都已经在Scala中优雅地体现出来了。

您的Java编程风格是什么样的，和过去相比有什么改变吗？


Tags - 编程 , 语言 ]]> http://www.guende.com/read.php?19 guende <admin@yourname.com> Sat, 15 Aug 2009 15:01:22 +0000 http://www.guende.com/read.php?19
超过70家公司已经开始更新他们的网站，当用户使用IE6访问时会看到如下信息：

(略)

“拒绝IE6”邀请所有兼容过IE6的网站通过添加这些信息来加入此运动。

据CNN报道，现在仍有15-25%左右的用户还在使用IE6，虽然与鼎盛时期的80%差距悬殊，但也足以让支持这场运动的人发表如下说明：

微软IE6发布于2001年末，在当时是相当好的浏览器，但现在已经是2009年了，仍有很大一部分网民还在使用，是时候让它下岗了。

web开发人员普遍认为，在IE6下工作是每天最困难最痛苦的事，花费大量时间却得不到足够的回报。除此之外IE6对最新web标准的支持也不够，限制了开发人员的创造力。

对IE6的主要抱怨有：

不支持CSS 2
不稳定 － 下面这行会搞死IE6：prototypebindbindAsEventListener
安全问题 － 2009年1月10日，Secunia宣布IE6有142个安全隐患，其中22个还没有任何对应的补丁
不支持透明PNG
不支持HTML 5
主流网站如YouTube、Digg、Orkut、Facebook等正在抵制IE6，如果可能，更希望IE6能在一夜之间消失。例如，当用户通过IE6访问Facebook时，将会收到提示，建议他们升级浏览器。

2009年愚人节，具有讽刺意味的拯救IE6运动展开，运动的目的是：

让每个人都使用IE6
将IE6移植到更多的平台
修改W3C标准以适应IE6
在另一个类似的运动中，Jeff Zeldman号召大家联合起来抵制IE6：

IE6就像是另一个Netscape4，为支持IE6而作的hack已经太多了。就像2000年的Netscape4，IE6正在拖累web。

这项运动看起来好像是一个反微软运动，UK网页设计杂志.net的编辑Dan Oliver说：

这不是一个反微软的运动。微软有很好的产品，最新版的浏览器也是一个好浏览器。但是IE6……是一个糟糕的浏览器，不应该有人用它。

最后，我们已经等待的太久了，这也解释了为什么支持这项运动的人数大大增加了，因为大家对此已经忍耐多年了，只是在等待主流站点领头推动下去。

据CNN报道，微软也希望用户离开IE6：

“微软一贯建议用户升级到最新版本的微软浏览器，IE8在速度、安全和稳定性上进行了改进，并为方便用户添加了众多新功能。”

IE团队经理Dean Hachamovitch解释了为什么让人们离开IE6很困难：

是否升级计算机上的软件取决于负责此计算机的人。

许多PC不属于个人所有，而是组织所有。组织中的人负责决定如何处理。这些人要保证成百上千台计算机在预算内工作良好……对他们来说，升级的成本不仅仅包含购买软件的费用，还包含部署、维护以及确保能和其它IT资源一同运行的费用。

我们不会放弃对IE6的支持，因为我们曾经承诺过对Windows自带的IE提供产品寿命内支持。我们要遵守我们的承诺。

IE6是PC World 2006年评选的历史最差高科技产品的第8名，或许是时候让它退休了。它曾有过它的时代，现在我们有了更好的替代者。

Tags - 浏览器 , internet , explorer ]]> http://www.guende.com/read.php?18 guende <admin@yourname.com> Thu, 06 Aug 2009 13:57:36 +0000 http://www.guende.com/read.php?18 保存 => 刷新）的同时，提高构建复杂AJAX或RIA应用程序的生产力。在Gestalt网站中写到：

我们创建Getalt项目是因为它符合MIX Online的精神。我们会在Web领域中挑选有趣的场景或问题，然后设法为它创建一些应用程序、服务，或提出一些解决方案的建议——Gestalt也是这么一回事儿。我们发现，Web开发人员经常会在基于标准的前端Web开发以及RIA（如Flash/Silverlight）两种开发模型之间摇摆不定，Gsstalt的目标便是解决这个问题。值得一提的是，选择Ruby和Python作为脚本语言，也是未来浏览器中有趣的话题之一。

Gestalt主要有以下几个特点：

使用Ruby和Python作为前端脚本语言：有了Gestalt，开发人员便可以在页面中添加

透明编译，高速运行：借助Silverlight中DLR的强大动态编译功能，gestalt.js可以在页面加载完成后动态获取其中的Ruby或Python代码，并使用IronRuby或IronPython加以编译执行。与JavaScript相比，Ruby和Python代码在加载时会有毫秒级别的延迟，但是页面的整体性能（尤其对长时间运行的页面而言）则会有显著的提高。
使用XAML应对复杂样式需求：面对如今愈发复杂的应用程序，HTML和CSS已经略显疲态。在Gestalt中，开发人员可以为页面从外部引入XMAL文件，或使用内嵌XAML的方式来开发复杂的交互式应用程序。Gestalt网站建议使用Expression Blend编辑XAML程序，并提供了Adobe Illustrator的XAML生成插件和TextMate Bundles来辅助其他工具或平台上的XAML开发。
天然SEO支持：与传统HTML页面相同，所有的代码和文字都显示在页面上。因此，开发人员无须任何额外的工作，便可以将所有的页面信息暴露给搜索引擎。
自由的开发和运行环境：只要一个文本编辑器（如记事本或TextMate），开发人员便可以在任意的平台上编写Gestalt网页，而Gestalt网页其实也只是一个最为普通的(X)HTML页面而已。Gestalt借助Silverlight插件中的DLR来执行Python或Ruby代码，这意味着Gestalt页面也可以在多种平台上运行。
Gestalt也有一些问题需要解决，例如：

Gestalt基于传统的前端开发模型，页面会像执行JavaScript那样执行Python和Ruby脚本，但目前还不支持import和require的功能。如果您想从外部引入Python和Ruby类库，可能就要通过内嵌XAP的Silverlight模型来实现了。我们对于您理想中的require或import的方式非常感兴趣，请给我们反馈。

至于Gestalt是否最终会成为一个成熟的产品，MIX Online团队认为：

（产品化）并不是我们的目标，但是你永远无法知道它是否会融入某个应用或概念之中。目前我们感兴趣的是推广Gestalt，并希望从社区中获取灵感。这也是我们公开Gestalt源代码的原因。我们希望您可以下载Gestalt类库并把玩一番，再把您的看法告诉我们。

您可以访问Gestalt的主页获取更多信息，或下载其类库和示例进行更深入的尝试。

Tags - 语言 , 脚本 ]]> http://www.guende.com/read.php?17 guende <admin@yourname.com> Sat, 01 Aug 2009 12:53:20 +0000 http://www.guende.com/read.php?17
其实微软在今年3月的MIX大会上发布ASP.NET MVC RTM的时候，就已经公布了部分ASP.NET MVC 2的计划，并且在官方代码源中包含的MvcFutures项目中实现了V2的部分功能雏形。在沉寂了4个多月之后，现在微软终于发布了ASP.NET MVC 2的Preview 1版本，并在论坛中向社区征求反馈意见和建议。令人放心的是，ASP.NET MVC 2 Preview 1能够与ASP.NET MVC 1.0 RTM共存，不会影响后者的正常使用。

Scott Guthrie一如既往地在第一时间内撰写博文，详细而又简单地介绍了Preview 1中的新特性。ASP.NET MVC 2的“主题”是“提高生产力”，Preview 1的主要功能有：

区域（Area）：Area提供了将Controller和View分组的功能，这个特性可以构建一个大型应用程序中相互独立的部分。每个Area可以独立放在不同的ASP.NET MVC项目中，并且由主应用程序共同引用。这个特性可用于应对大型应用程序所带来的复杂性，也使多个团队能够更方便地同时开发同一个应用程序。
数据标记验证（Data Annotation Validation）：ASP.NET MVC 2提供了内置的数据标记验证功能。这个功能利用了.NET 3.5 SP1中加入的自定义属性（Required，StringLength，Range，RegularExpression等），并且已经运用在ASP.NET Dynamic Data框架与.NET RIA Services中。利用这一功能，开发人员可以为Model或ViewModel添加验证规则，ASP.NET MVC框架则会自动进行数据绑定或UI验证。
强类型UI辅助方法：ASP.NET MVC V2包含了新的HTML UI辅助方法，它利用了强类型的Lambda表达式来操作View模板的Model对象。这样在编写视图代码时便可以充分获得IDE的智能提示。更重要的是，它为视图带来更好的编译期检验能力。
模板化辅助方法（Templated Helper）：这一功能可以根据数据类型自动选择相关的模板。例如，在视图中生成一个System.DateTime输入功能时，将会运用一个日期选择器模板。这与ASP.NET Dynamic Data框架中的Field Template有些接近，不过Preview 1中的模板化辅助方法是专为ASP.NET MVC框架而设计的。
此外，微软还公布了ASP.NET MVC 2的路线图。除了Preview 1中已经公开的内容之外，Preview 2中会包括以下功能：

客户端验证：在Preview 1中模板化辅助方法及数据标记验证功能的基础上，构建一个客户端验证功能。
强类型输入（input）辅助方法：使用强类型的表达式构建出针对Model的输入元素。这些辅助方法还会利用数据标记验证功能来减少错误（如拼写错误）。
强类型链接（link）辅助方法：在IDE智能提示的辅助下，使用强类型的表达式来生成面向特定Controller和Action的链接。
异步Action：提供开发不阻塞线程的Action的方法，这可以显著提升站点的伸缩性，尤其是在需要访问外部资源的情况下。
区域（Area）功能增强：可以在同一个项目中更好地组织应用程序，而不必分拆成多个项目。
其他改进：继续修复ASP.NET MVC 1.0及ASP.NET MVC 2 Preview 1中已知的问题，并根据用户反馈进行API增强，以及一些细微的新功能。
除了Scott Guthrie之外，Scott Hanselman以及ASP.NET MVC团队的Phil Haack也在博客中介绍了ASP.NET MVC 2 Preview 1的情况，MSDN和Channel 9还为“模板化辅助方法”这一重要功能提供了进一步的讲解和演示。更多消息请参考ASP.NET MVC 2 Preview 1的Release Notes，您还可以下载源代码对其进行深入了解。


Tags - web框架 ]]>