http://www.guende.com/index.php zh-cn http://www.guende.com/read.php?78 guende <admin@yourname.com> Wed, 04 Aug 2010 23:02:25 +0000 http://www.guende.com/read.php?78
与单独使用每个工具一样，可以使用Unicorn以相同的3种方式验证Web站点，也就是说，可以提交待测试页面的url、上传文件或是直接将代码输入（剪切与粘贴）到文本框中。

与单元测试一样，验证是质量保证的基础。通过验证可以保证兼容于标准，接下来又可以保证网页与Web站点的整体质量。但验证是件单调乏味的事情，又很浪费时间，尤其是想让现有的站点保持与标准的兼容性更是如此。

简化测试验证与兼容性的工具可以降低总体代价与工作量。借助于Unicorn的帮助，我们可以同时执行4种验证测试，毫无疑问，与将同样的文件提交给4个不同的验证测试器相比，Unicorn的做法可以极大地简化验证过程。

如果你要创建全新的Web站点，那么在开发每个页面时都使用验证工具进行验证的做法非常类似于单元测试。如果你要改进或是维护现有的Web站点，那么：

... 遵照标准（如HTML和CSS）或是Web Accessibility Guidelines才是正道，也是最佳的抉择。指南与工具可以帮助你创建遵循Web标准的站点，确保更多的受众、降低开发与维护的代价。
上面这段文字引用自W3C质量保证小组的一篇文章。

做正确的事情并不意味着就简单轻松。方式也很重要。

但如何将现有的站点转化为兼容于标准的格式却是个艰难的决定。你的站点可能有多种格式的遗留、没有维护的文档，或是有巨量的文档，导致更新困难。你的站点背后可能是良好的设计与灵活的技术作为支撑，这会简化转换工作，但无论何种情况，更新站点都是需要资源作为保证的。

通常有两种方式可以让现有的Web站点兼容于标准：完全从头开始（错误的方式）与手工验证每个页面（困难的方式）。
本文会继续讨论这两种方式，分析他们之所以错误的原因并给出第3种方法：一次系统性地更新一部分。

验证工具（如Unicorn）的使用在整个质量保证进程中是个必要的步骤。值得注意的是，某些验证并不遵从于自动化的验证测试，比如Americans with Disabilities Act（ADA）兼容就是一例。

Tags - 质量 , 验证 ]]> http://www.guende.com/read.php?77 guende <admin@yourname.com> Wed, 04 Aug 2010 23:01:22 +0000 http://www.guende.com/read.php?77
TIOBE在公布榜单时，以“恐龙”（Dinosaur）一词来修饰Smalltalk，点出了这个最古老OO语言的昔日辉煌和现时落寞，意味深长。TIOBE同时指出，在数月之前，另一个著名的纯面向对象语言——Eiffel也跌出了榜单，如今又轮到了Smalltalk，这从另一个侧面反映出了如今编程语言的趋势——多泛型（multiparadigm）：面向对象、面向过程、最好再来点函数式编程。

排在前5名的依旧是Java、C、C++、PHP和（Visual）Basic，它们在排行榜中的权重之和超过60%，优势明显。

另一方面，新生代语言在稳步上升。Go进入了前20名榜单，其东家Google也一直在努力推进Go的发展。前不久，Go语言创始人之一Rob Pike在O'Reilly开源大会上对Java、C++的复杂性表示了不满，并指出Go的优势：“Go试图把静态语言的安全、效率与动态语言的便捷结合起来，至于效果有多好，还需要你自己来使用、判断。”


Tags - smalltalk , delphi , cc# , c++ ]]> http://www.guende.com/read.php?76 guende <admin@yourname.com> Wed, 30 Jun 2010 23:35:14 +0000 http://www.guende.com/read.php?76
De Boor于上周四在波斯顿召开的Usenix WebApps大会上说到“HTML 5会让很多工作变得简单和高效”。“HTML 5让我兴奋不已，关键在于有多少浏览器厂商会使用它，我对IE9抱有很大的希望”。他指出HTML 5所带来的一个好处在于标准会在多大程度上提升Gmail的加载与执行时间。Google现在的目标是希望Gmail能在一秒钟内加载完毕，速度就是生命。

早期的测试表明这个目标是很有希望达到的。比如说，Gmail会检查浏览器是否支持CSS 3，如果支持，那么它就会使用相应的规范渲染页面而不是传统的DOM方式。公司发现使用CSS 3可以将页面的渲染速度提升12%。

HTML 5还有助于新特性的构建。目前Gmail设计团队正在开发的一个新特性就是将文件从桌面拖动到浏览器上。该特性非常重要，因为它会使Web应用的功能特性更加接近于传统的桌面应用。

Gmail还会利用到HTML 5的数据库标准。现在的email服务使用Google Gears存储邮件以便离线阅读，但随着时间的流逝，Gmail将会迁移到HTML 5标准上。

De Boor还谈到了Gmail要增加一些无法使用HTML 5实现的新特性。一个特性就是将文件从浏览器窗口中拖动到桌面上。为了解决这个难题，团队成员正在开发一个全新的数据传输协议：downloadurl。“我们打算把这个协议加到HTML 5中，但这仅仅是个想法而已，我们办不到。”他开玩笑地说到，Google打算搞个游说团队，把这些新功能推销到HTML 6中，但现在不过是想想罢了。

既然没法加到标准当中，我们鼓励其他浏览器也使用这个协议。公司并不想重掀上个世界90年代的“浏览器大战”，我们需要汲取过去的教训，加强与其他浏览器厂商的合作。

另一个新特性就是“Magic iFrame”，用户可以将frame中渲染的页面拖出来并在新的浏览器窗口中打开。

目前，Gmail程序由443,000行JavaScript代码组成，如果加上注释则会达到978,000行。所有这些代码都是手工编写的，没有借助于任何生成工具。

在De Boor演讲的QA阶段，有人问到使用JavaScript完成这么大的一个项目，有没有什么不妥的地方呢？

De Boor承认其他语言（比如Java）可能更好一些，但他同时说到，Java实在是太冗长了。对我来说，这仅仅是语言的选择问题，但有一点，我认为JavaScript的性能没有任何问题。与JavaScript相关的各种问题很多都来自于浏览器的实现。

目前Gmail已经开始支持文件拖拽了，比如说可以将桌面上的文件拖拽到Gmai窗口作为附件发送。

Tags - google ]]> http://www.guende.com/read.php?75 guende <admin@yourname.com> Mon, 28 Jun 2010 06:23:06 +0000 http://www.guende.com/read.php?75
此次发布通过EGit项目带来了开箱即用的Git支持（Beta版），作为未来Eclipse项目的分布式版本控制系统，开箱即用的Git支持将成为未来发布的关键所在。如果还不清楚分布式版本控制系统能为你带来什么，请参考面向Eclipse用户的Git文档指南（这是地址）和Eclipse Helios London DemoCamp的视频了解一二。

嵌入的Eclipse Marketplace Client可以浏览（并安装）Eclipse Marketplace上新近发布的各种应用。这样寻找Eclipse插件的工作就变得轻而易举了，同时它还集成到了Eclipse Labs开源的托管站点上了。

Helios还包含了Xtext 1.0，Xtext 1.0荣获了今年颁布的Eclipse最具创新大奖。它的目标是提供一种机制以生成DSL解析器与编辑器；最近的Eclipse Live演示了如何创建DSL，如何生成一个基于Eclipse的编辑器（支持代码完成功能）。它使用EMF，根据一种简单的EBNF语法语言生成AST结点。感兴趣的读者可以通过该文档上手。

Web Tools Platform现在开始支持JavaEE平台，包括对Servlet 3.0、JSF 2.0和Tomcat 7的支持。此外，还通过PsychoPath XPath 2.0处理器改进了对XML编辑与处理的支持（包括XHTML编辑）。JavaScript工具也得到了改进，可以集成到不同的JavaScript调试器中了。除了现有的条件断点外，还可以创建监视表达式（watch expression），这样就可以在同一个JavaScript运行时中于不同的断点处触发不同的值了。

来自EclipseSource的Ian Bull谈到了Eclipse Helios的十大特性（类似于几 年 前所做的那样）：

Xtext
Git支持
EMF、Riena与RAP集成
Marketplace Client
P2 API与B3 Aggregator
目标平台的增强
Java IDE的改进
改进的API工具
基于特性的配置
改进的资源
除了“classic”SDK包以外，还有很多面向不同人群的包，比如C/C++开发、PHP开发、JEE开发以及BIRT报表与建模工具等等。此外，还有面向32位与64位 Cocoa的OSX包；虽说只是个Carbon版本，但Eclipse Helios将是最后一个支持Carbon运行时环境的版本了（OSX 10.7很可能不再支持Carbon了）。

感兴趣的读者可以免费参加这个Helios in Action虚拟会议；该会议包含Linux工具的演示、Web上的EMF、Eclipse EGit、JavaScript开发、JavaEE、标准支持、Marketplace Client、建模、Eclipse运行时、Mylyn和对Ian所提出的十大特性的介绍。


Tags - eclipse , birt ]]> http://www.guende.com/read.php?74 guende <admin@yourname.com> Mon, 28 Jun 2010 06:22:19 +0000 http://www.guende.com/read.php?74
第二次参加RubyConf的Matz本次的主题围绕Ruby社区展开。他认为Ruby是幸运的，因为Ruby拥有一个优秀的社区。他通过一段代码来定义什么是好的社区：

def nice
  brave &&
  passionate &&
  honest &&
  respective
end
Matz希望人们能更多地投身Ruby社区的发展，通过修正Bug、发布Gem等多种方式贡献自己的力量，甚至是为Ruby核心提交代码。

当被问及Ruby 2.0的情况时，Matz表示2.0将是1.9的一个补充，而非革命性升级。1.9到2.0的变化将少于1.8到1.9的，更主要的是提升Ruby的可扩展性，改善大团队协同开发时的体验。此外，在演讲中Matz也多次谈到了多种Ruby实现，例如JRuby和Rubinius等等。

随后，来自Yottaa公司的Jared为大家分享了他们在使用MongoDB方面的经验。Jared介绍了多种不同解决方案的优缺点，为何选择MongoDB，尤其是如何用Rails和MongoDB构建可扩展的数据处理平台。

下午，张文钿在《Designing Beautiful Ruby APIs》的演讲中带来了10个非常有用的技巧，通过大量代码范例告诉大家如何写出漂亮的Ruby代码。他认为漂亮的代码，应该满足以下要求：

易于理解
易于编写
易于扩展
同时，张文钿还介绍了台湾Ruby社区的发展情况以及4月举办的RubyConf Taiwan 2010。

来自盛大的庄表伟介绍了盛大在NoSQL方面的一些成果：基于Tokyo Cabinet，他们开发了TCDatabase，以及相应的ActiveRecord适配器tcdb-adapter。通过这些成果，开发者能够方便地（甚至是无缝地）让Rails应用程序从关系型数据库迁移至NoSQL数据库。庄表伟在现场做了精彩演示，并于演讲后给出了TCDatabase的发展线路图，他还表示待项目成熟后会将TCDatabase开源。

大会最后是两位日本朋友Arai和江渡浩一郎的演讲，尤其是江渡先生为大家演示了一些他的发明，让在场的听众十分感兴趣，有朋友通过现场的人间网大屏幕表示“这位日本演讲者绝对是资深Geek”。

本次RubyConf China大会的主题演讲还有：

黄志敏，《基于HTTP的Ruby应用程序》
王益善，《Ruby和异构系统集成的开源解决方案》
胡振波，《构建高质量的Rails Web应用程序》
Arai，《Business matters in after-Rails world》
江渡浩一郎《Introducing "Patterns, Wiki and XP"》
本次大会吸引了众多中外Ruby爱好者，中午的交流中发现除了来自无锡、杭州、北京、天津的朋友，还有香港、澳门、台湾，甚至是从维也纳远道而来的朋友。不久，大会官方将公布所有演讲的资料及视频，敬请请关注大会官方网站。

Tags - 会议 , rubyconf ]]> http://www.guende.com/read.php?73 guende <admin@yourname.com> Mon, 28 Jun 2010 06:21:25 +0000 http://www.guende.com/read.php?73
WindowBuilder Pro最初由Instantiations于2003年发布并很快被众多的开发者所用，现在已经成为占市场主导地位的Java GUI构建器。WindowBuilder包含了SWT Designer、Swing Designer和GWT Designer，可以无缝集成到任何基于Eclipse的Java开发环境中。借助于其提供的拖拽功能，开发者可以轻松增加组件并迅速创建复杂的界面，同时会自动生成Java代码。

此次发布的WindowBuilder Pro v7.6提供了如下增强：

WindowBuilder Pro（所有设计器）

Eclipse 3.6支持：Instantiations履行了自己的承诺：与每年发布的Eclipse保持同步。新版的WindowBuilder Pro完全支持Eclipse 3.6（Helios）

SWT Designer

XWT支持：现在，SWT Designer支持Eclipse XML Window Toolkit（XWT）。XWT是个面向Eclipse的直观、强大、轻量级、声明式的UI框架，基于XML标记语言。XWT通过将XML中的UI定义与编程语言中的运行时逻辑分离开来简化了UI开发。SWT Designer中的XWT支持包括：

创建XWT应用与复合组件的向导
支持所有的SWT与JFace组件和属性
支持所有标准的SWT布局管理器，如GridLayout和FormLayout
支持SWT事件处理器
设计视图与XML源代码之间的双向编辑
GWT Designer

Smart GWT v2.2：Smart GWT框架基于GWT，开发者不仅可以在应用的UI中使用其提供的大量widget，还可以将这些widget绑定到服务端以进行数据管理。Smart GWT构建在强大、成熟的SmartClient库之上，兼容于GWT 1.5.3+

GXT v2.1数据绑定支持：Ext GWT（GXT）v2.1中的数据绑定功能提供了如下特性：

模型与表格之间基本的绑定
根据所选的网格绑定模型与表格

Tags - eclipse ]]> http://www.guende.com/read.php?72 guende <admin@yourname.com> Sat, 26 Jun 2010 03:33:45 +0000 http://www.guende.com/read.php?72 我之所以放弃PHP，原因首先是语言。PHP实际上不是一种语言，而是一种巨大的插件结构，以一种高层的形式来展示低层的库。而大部分开发者使用的 语言实际上是对C功能 (curl, mysql, gd, etc.)的包装，通常情况下它们的库展示得很简单。因而这导致了PHP的API不一致。

PHP语言的第二个问题是语言的管理问题。PHP语言实际上是由委员会来设计的，而且没有人来制定任何共识性的标准。PEAR有自己的标准，PHP有自己的标准，这导致SPL classes更具Java风格，而PEAR却截然不同。

从事PHP开发11年来，我认识了很多PHP领域的专家级开发者，它们对PHP也有很多看法。除了上文提到的委员会问题以及标准混乱问题之外，由于PHP 的使用范围非常广，向后的不兼容对代码造成了很大的破坏。

还要提到的一点是PHP缺乏很多现代语言的特性。现在再来说说Python：

Python语言的创建方法几乎与PHP的完全相反。首先，Python是由Benevolent Dictator和Guido van Rossum领导的，语言的开发由单一的人员主导，因此它的开发、管理以及长期运营会保持很好的连续性。Guido和Python的核心开发者通过PEP 创建标准，而且通过公共接口展示标准是如何创建的。而且，Guido如果想到的语言特性不够好，也不会出现在语言层中（如没有++运算符，而且比较符中没 有分配）。

延续性的特点也延伸到了整个Python社区，所以你很难发现不同项目中的Python截然不同。

我最喜欢的Python的一个特点就是它的清晰。当打开Python中的一个文件的时候，我会清楚地知道里面大概有什么样子的代码，联想到很多次我被 PHP的这一点搞得焦头烂额，我觉得这个特性非常有用。

总之，Python的系统级特性非常不错。

Python另外一个很棒的特性是直白性。需要namespace(命名空间)？文件的名字就是命名空间；需要模块？只需要用一个__init__.py 文件代替；需要重命名功能？只需要new_func = old_func。

Tags - php , python , 国外 , 开发者 ]]> http://www.guende.com/read.php?71 guende <admin@yourname.com> Wed, 23 Jun 2010 01:16:25 +0000 http://www.guende.com/read.php?71
目前的原型支持如下特性：

函数型语法
函数型子类型
完整支持type1（无状态）与type2（终态捕获）的lambda表达式
推断lambda中的thrown类型与return类型
通过v0.1.5草案中的规则实现的lambda转换
支持“this”引用（包括显式与隐式）
使用方法句柄实现的转换
下面的代码片段声明了一个简单的lambda表达式，该表达式接收一个整型，加一后返回：

int i1 = #()(3).();
assertTrue(3 == i1);
Integer i2 = #()(3).();
assertTrue(3 == i2);
int i3 = #(int x)( x + 1 ).(3);
assertTrue(4 == i3);
int i4 = #(Number x)(x.intValue()).(new Float(3.0f));
assertTrue(3 == i4);
Object o = #()(3);
assertTrue(o != null);

该原型支持规范草案所描述的语法，如果想要更好地了解语法，读者可以看看衰退 测试。

因为Java通常使用长单词而非符号，因此有很多人觉得这种语法太笨拙，并不符合语言本身的感官。

来自Ajaxian的Dion Almaer认为这种语法更接近于Perl而非Java：

Integer i2 = #()(3).(); //i2 = 3
int i4 = #(Number x)(x.intValue()).(new Float(3.0f)); //i4 = 3 Erm, Java? Or Perl!!
无独有偶，Ruby on Rails的创始人David Heinemeier Hansson认为这种语法太乱：

Java 7新的闭包语法：int i4 = #(Number x)(x.intValue()).(new Float(3.0f));——这一行也太长了吧！
不少Java开发者在论坛和讨论组上抨击这种lambda语法：

Java Posse Group

“吼吼，这也太恶心了吧。源代码乱的一团糟”。

“恩，这种恶心的语法倒是能够减轻编译器开发者的工作量。一定还有更好的方案能够解决这个问题。即便是Obj-C的块都比这强（至少语法比这强）”。

”为了保证向后兼容，Java没法实现更优雅的解决方案，但现在这其实根本不算什么问题“。

Baptiste Wicht的博文

”一看到int i1 = #()(3).();这一行我就无语了，第一眼还以为代码写错了呢“。

”肯定还有改进的空间。如果用adder(1, 2)代替adder.(1, 2)，我觉得会好很多，把点放在中间并不符合Java风格“。

Hacker News

“这种语法太丑陋了”。

“从实践上来说，Java并不会使用过多的符号。他们这帮人为什么要这么做呢？我并不是说反对他们（相对于长单词来说，我也更偏爱符号，虽说这会导致更长的学习曲线），但这与Java规范格格不入”。


另一方面，Nick Wiedenbrueck认为该提案由来已久，Java社区应该认识到将要发生什么：

现在有几个提案，上次的Devoxx大会上也宣布了提案草案与规范草案，但社区并没有对此进行过充分的讨论。什么原因呢？我有一些假设。lambda项目太安静了么？根本就没有几篇博文或是示例介绍lambda。社区出什么问题了么？社区领域跑哪儿去了？难道都忙着学Scala去了？静态类型语言（没有类型推断）中的闭包就应该这么复杂么？
最后，该原型的创建者之一的Brian Goetz说到，在进入到产品阶段前还会继续改进语法：

记住，这只是早期的概念验证阶段。这里面的语法都是暂时的，随着Lambda项目的不断发展，语法也会发生很大的变化。同时，还有很多比语法重要的东西，我们的全部精力都放在这上面了——语法要为之让路。

Tags - 闭包 , closures ]]> http://www.guende.com/read.php?70 guende <admin@yourname.com> Tue, 22 Jun 2010 00:05:12 +0000 http://www.guende.com/read.php?70
公司的此次声明刚好在Apple宣布其iAds之后，但却采取了完全不同的方式：

我们的广告解决方案可与Apple最近宣布的iAds相提并论，但与iAds不同的是，该方案需要使用Adobe® Flash®的授权工具，价位也非常低，既有可展开的banner条形式，也有整屏形式。由于Flash是开发富媒体数字广告的标准，品牌广告商和数字媒体可以通过这些解决方案实现对广告开发的完全控制，通过保留现有的工作流并且支持HTML 5来降低成本，这样广告商就可以触及到所有主流的桌面与移动平台，降低了广告概念诞生与发布之间的时间延迟。
由于关于该平台的信息较少，因此InfoQ就产品的技术方面与Greystripe的代表进行了一次交流：

问：能否向那些想要使用该平台的开发者介绍一下开发流程？这是设计工作还是开发工作呢？

Greystripe：我们认为广告应由富于创造力的设计人员而非开发人员完成。在我们的工作流中，富于创造力的媒体机构按照他们习惯的方式创建Flash广告。平台会在必要的情况下转换Flash文件（swf格式）以便在设备上呈现出来。
问：你会在某一时刻转换ActionScript和JavaScript么？是一条命令接着一条命令地转还是先构建出完整的抽象语法树并对其优化呢，就像GWT将Java转换为JavaScript那样？

Greystripe：富有创造力的媒体机构将二机制的swf文件提供给我们，而不是fla源文件。我们的转换层操纵ActionScript字节码，而不是ActionScript源代码，因此它并不会使用AST。我们会重新装配ActionScript字节码并将其重新编译为Javascript源代码。比如说，低层分支的Actionscript字节码序列会被恰当地编译为Javascript的if/while/for源代码语句。
问：你们的平台只能用于Safari么，会为所有浏览器提供兼容层么？

Greystripe：我们目前的计划是支持移动Safari，因为只有它没有（或者说近期不会）提供原生的Flash支持。我们会在未来考虑其他浏览器。
问：那有什么限制么？

Greystripe：对Flash的支持有些限制，但根据我们过去两年的经验来看，这些支持涵盖了大多数广告内容。从高层次来看，这种限制类似于Flash Lite和完整的Flash之间的区别。
问：如何处理视频、音频等内容呢？

Greystripe：在预处理阶段抽取出音频和视频，然后使用原生的HTML 5媒体控件进行渲染。

Tags - iphonehtml , 5 , actionscript , flash , adobe , ipad ]]> http://www.guende.com/read.php?69 guende <admin@yourname.com> Sun, 20 Jun 2010 23:42:38 +0000 http://www.guende.com/read.php?69
最近InfoQ有幸采访到了Architexa的创建者Vineet Sinha以深入了解该工具，同时明晰了它为何能帮助开发者处理日益膨胀的代码基。

Architexa是如何在其他UML工具欠缺的地方帮助开发者的？

我们将精力放在了代码需求而非设计需求上，希望能帮助开发者更快地理解代码，理解好相关的任务、相关的文档并能轻松地讨论这些重要的代码概念，然后与同伴分享这一切。
在一开始探索代码基时可以使用层次图这一强大的工具。能否向读者做个简单的介绍？这个想法来自于现有的工作还是经过了不断的演变才得出的？你是如何想到它的呢？

Architexa中的层次图会根据现有的代码基作出最接近于层次架构图的估算。我们注意到大多数层次架构图都是团队或项目所用的高层次图表的主要形式，通常不太容易从众多的代码基中找出层次架构图的踪迹。如果这类图可以帮助开发者找到他们最感兴趣的部分代码基，我们打算快速实现一个版本以满足开发者所需。
Architexa通过分析代码并展示模块来构建层次架构图，如果某个模块依赖于另一个模块，那么就会将它放在图表的上面。除此之外，我们还需要猜——默认情况下，模块基本上是根据代码基的目录结构创建的。而且，大多数代码基经常包含循环，我们使用了复杂的算法来处理这种循环，但依然能保证提供高效的层次图。
大多数工具套件都是我在MIT（CSAIL）读博士时尝试并开发的，我们想要的是一个卓越的工具。主要的想法来自于很多地方：我在下面这些地方花了大量的时间： (i)阅读了多个项目的软件文档以了解共通的东西，(ii)分析了目前提供有效的代码视图的工具：虽然这些工具都非常复杂并且需要培训，但他们各有千秋，我们可以从中了解到这些工具常见的使用模式，这样就能通过几次鼠标点击来简化工具的使用了，(iii)典型的树形widget，通常他们都会收起并显示大量信息，(iv)大量优秀的工具，以便从中找到适合我们的图表的技术。
在构建好了第一个原型后，我们发现了很多问题。虽说实现了大多数主要的想法，但我们意识到了真实世界中的问题（代码经常有循环），我们开发这些技术不仅是为了解决这些问题（通过层次来忽略掉一些代码循环），更是为了减轻用户的负担，这样他们就能轻松处理问题了（用户可以根据这种循环依赖进行扩展、使用彩色高亮显示当前模块之上、使用了当前模块以及与当前模块之间存在循环的模块）。
用户可以借助于Architexa白手起家，无需对代码基有任何了解就能起步并不断探索。在探索代码基时你发现了自己的使用模式了么？你是如何在每天的开发/设计工作中使用这个工具的？

我们发现了大量的使用模式并积极地探求这些模式来不断提升工具的品质。但大多数使用模式还是取决于用户所要完成的任务：
如果开始查看项目（或是项目的一部分），用户通常都需要高层次视图，在这种情况下，他们会使用层次架构视图从上开始，然后双击视图深入到代码内部。
如果想要查看项目（或是子项目）的核心，用户通常都需要了解多个类之间的交互关系，因此想要看到多种关系图（继承、方法调用、属性访问等等），他们尤其喜欢使用类图。
如果想要了解一个重要的用例，用户则需要看到控制流程，在这种情况下，序列图是个不错的选择。
有没有什么办法可以比较现有的图表和改变后的代码基呢？

在代码基发生变化时，图表的使用有多种可能。我们支持两种用例：
在用户创建好图表后又修改了代码基时：如果再一次打开图表就会看到一个红色的错误标识，标识类/关系缺失。
在用户修改完代码基后又想创建图表时：用户可以右键单击项目，转到team菜单并让Architexa根据变更构建一个新图表而非检入代码。这么做的好处在于可以考虑到代码评审问题，因为生成的图表通常都是修改后功能的最好总结。
我们还会在这个地方增加更多支持。
手工生成图表是探索代码基的好办法，但在构建过程中自动生成（类似于JavaDoc）则可以更好地描绘系统的演变过程。Architexa也能实现该功能么？

重要的图表通常会跨越多个类，每个重要的类也会跨越多个图表，因此把他们放到JavaDoc中没什么意义。我们允许用户将图表上传到一台简单的类似于wiki的服务器上。这样，用户不仅可以与其他人共享这些图片（只需使用浏览器即可），还使得我们可以增加额外的信息，这样使用Architexa客户端的其他用户就可以继续探索其他人写的代码了。这些图表代表了代码基中的重要概念，因此他们不仅支持用户添加注释，还可以在不同的地方嵌入这些图表，还有版本的概念，这样就能反映出主要概念的演变过程了。我们还会在这个地方增加更多支持。
该工具目前支持哪些语言？

此次发布只支持Java，但我们还有C++原型。
该工具是否有助于说明组件以及核心类的交互呢（比如说MVC/Web框架交互）？

当然了。该套件的目标就是展示代码中显露出来的关系（方法调用、继承等等）和运行时出现的关系（对接口或基类的调用）。我们通过静态关系实现这一点，但允许用户以任何可行的方式修改图表。
能否说说第一版中尚未包含但即将发布的特性，读者对此可能很有兴趣？

此次发布包含了大量的特性。虽然我们实现了很多特性，但目前主要的目标还是倾听用户的想法。
Tags - uml , 图表 ]]>