作为一个程序员，获取知识是让我不断前进的动力，而读书是我获取知识的一条重要途径。在这个“经典”、“必读”过剩的年代里，大多数的书都仅仅扮演着传播知识的角色，真正改变自己对某些问题看法的书其实少之有少。限于读书时的眼界和能力，在我列表中，让我拍案惊奇的书只有几本。Martin Fowler的《重构》，严格说来，我并没有完整的读完这本书，不过，正如作者自己所说，这样的书原本就不指望能够读完，因为有一大部分其实是参考手册。正是我读过的部分让我知道了重构，让我知道这么做可以把代码写得更好。Robert Martin的《敏捷软件开发》，这是一本名字赶潮流，内容很丰富的书，这本书让我开始理解软件设计，从此不再刻意追求设计模式。Kent Beck的《测试驱动开发》，我读的是英文版，因为当时中文版还没有出版，所以，我不敢说，我通过这本书很好的理解了测试驱动开发，但它却为我打开了一扇门，让我知道了一种更好的工作方式。

有好长一段时间，这个列表没再更新过，中间虽然我也读了很多书，也学到了很多东西，但却没有哪本书如这几本书一样给我带来巨大触动。新近加入我这个列表的书是《修改代码的艺术》，英文名是《Working Effectively with Legacy Code》。

对于很多软件开发人员来说，加入一个公司，通常意味要面对一大堆之前留下的代码。而面对沉重的负担，大多数人的感觉都是无可奈何。让无奈成为往事，也就是这本书的价值所在。

在我看来，这是一本讲解如何编写测试的书。之所以遗留代码让人头痛，除了复杂的逻辑，改动会带来怎样的后果是一件让人心里没底的事，而测试的存在可以大幅度降低这种恐惧。但是，许多代码在开发时并不考虑测试，这样做的结果就是让测试几乎成为一件不可能完成的任务，一个常见的例子就是代码中访问数据库。即便写出测试代码，漫长的测试过程也会让它失去一部分应有的作用，我们希望得到的是快速的反馈。所以，对于
无测试而言，知道编写测试是一种境界的提升，写好单元测试则是一种更高的境界。如果能够让测试驱动开发，从开发之初便考虑测试，并懂得如何写好测试，开发者应该不会陷自己于一种难为的境地，这也应该成为专业程序员应该具备的基本技能。

至于这本书的具体内容，我的评价是实用。具体的手法，很难在这里一一列举，但是，以我的开发经验来看，
许多似曾相识的代码不断的出现在书中，而作者举重若轻的处理手法，正是让我有拍案惊奇的地方。实际上，回味起来，每个手法都不是什么很高超的技法，但正是因为见识过类似的代码，才能体会到这种手法的价值所在。所以，相对于程序新人，它更适合有经验的人。

之所以说这本书更适合有经验的人还因为，这本书中谈及的内容涵盖设计、测试、重构等诸多方面：通过重构，解开代码内的耦合，让其可测。这恰恰是前面提到的那三本书所讲的内容。也只有懂得了这些基本内容才能体会到那些具体手法的价值所在。依然记得当年读《重构》时，在提取和内联之间迷茫了好久，直到后来经过了许多开发实践才体会到这些做法的真正含义。

如果说不足，那么，这本书缺乏一个列表，就像Martin Fowler为《重构》所做的那样，出什么样的问题，应该采用怎样的手法进行处理。

关于中译本，总的来说，翻译得很流畅，读起来比较舒服。不过，制作上还是有一些不太让人满意的地方。
* 译注太多，而且有些是低估读者智商的译注。
* 页边标有页码，似乎是为了与英文版对照，但文中的参考页码又是以中文版为准，显得有些乱。
* 书的装订不是特别令人满意，我一直担心从中间断开。

XRuby：享用JVM上的Ruby

在InfoQ China发了一篇介绍XRuby的文章。其实，对于之前听过我介绍XRuby的人来说，这篇文章的内容并不新鲜，因为基本上，这篇文章的内容脱胎于之前介绍XRuby的讲稿。虽然讲了几次，但还是应该把这篇文章写出来。一来，到场听介绍的人毕竟是少数，写出来看到的人应该可以更多，也让更多的人有机会了解XRuby，再有，内容写成文章需要比演讲时有更多的思考。所以，整体来说，内容叙述应该会更加准确。

这是一篇早就该写的文章，至少最初答应霍泰稳写这篇文章还是5月份的时候，7月份录我 InfoQ访问的时候，又答应了Floyd完成这篇文章，可真正发布已经是十月份了。不过，这样一拖再拖也不是完全价值。在这段时间里，我在Agile Day讲了一次Ruby on JVM，让我对这个方面有了些新的思考，特别是把Ruby放在 JVM上的价值，这一点已经体现在这篇文章里了。另外，XRuby自身在这段时间中也发生了很大的变化，特别是Annotation的加入，让代码在表现形式上得到很大的进步。至少在我看来，最终体现在文章中的示例代码是可以接受的。

我希望，这篇文章可以成为一个起点。一方面，它可以作为让更多人了解XRuby的起点；另一方面，XRuby团队把它作为一个起点，向其它人展示XRuby中非常优秀的一面。当然，XRuby现在已经有了不少不错的文档。

已经有朋友给我建议，写一些更深入的东西，这也是我所希望的，只探讨一些比较浅的东西不过瘾。在XRuby开发过程中，有很多有趣的思考，我很愿意与人分享那种开发中的快乐。再有，写东西会促使人思考，随之而来的往往是发现不足，这也是有益于XRuby进一步改进的。

如果你希望了解或参与XRuby，不妨告诉我们，你希望了解什么，也许，我们之后的文章会满足你！

如果我们想将程序设计语言编写的源代码运行起来，通常情况下，我们有两条路可以走：解释和编译。

计算机能够认识的只是01串，所以，我们编写的源代码要想真正启到应有的作用，必须经过转换，转换成一种可执行的格式，然后，由专门的执行引擎将它运行。

解释，通常是将源代码解析为一个中间形式（比如抽象语法树，AST），然后，经由一个软件的执行引擎执行这个中间形式，产生对应的结果。这种做法的好处就是可以把执行逻辑独立处理，无须为每个平台编写不同的代码，所以，这种做法的可移植性很好，于是，它成了不少程序设计语言最初的选择。不过，随之而来的问题就是这会降低执行速度，毕竟，这个软件执行引擎的性能无法与硬件相比。所以，以硬件作为执行引擎的“编译”会让程序拥有更佳的性能。

采用编译的方式，我们可以将代码编译成可以由硬件直接执行的二进制代码。因为不同硬件和不同操作系统的二进制格式是不同的，所以，如果希望语言得到广泛应用，那便需要针对不同平台实现平台相关的编译器后端，理论上说，这不是一件不能完成的任务，但这意味着巨大的工作量。虽然编译语言的数量不在少数，但事实上，真正能够跨越各种软硬平台的编译语言似乎只有C。

虚拟机的出现让人们找到了在软硬件执行引擎之间的一个折衷。一方面，编译器只要生成针对虚拟机的代码，而不必为各种各样的软硬件平台费心，另一方面，虚拟机不断的优化可以让程序在不受编译器的影响下越跑越快。所以，许多程序设计语言走上了这条路，比如Java，比如Python。这些语言大多采用的是自行设计的虚拟机，但这个做法虽然可以充分的将语言特性与虚拟机结合起来，但无疑也意味着大量的重复工作。Parrot希望成为一个集大成者，为众多动态语言搭建一个共同的平台，只是不知何年何月才能实现它宏大的目标。

Java虚拟机（JVM）的普及为这个问题提供了另外一种选择。因为主流软硬件平台上基本都有自己的JVM实现，所以，只要生成针对JVM的代码——字节码，便意味着可以运行在大多数平台上。当然，虚拟机也是一种软件实现，所以，性能上也会有一些损失。不过，从Java平台的广泛应用也证明了，这样的损失在实践中是可以接受的。随着JVM技术上的不断进步，性能损失越来越小。再者，作为一种为静态语言设计的平台，目前，JVM自身并不支持动态语言特性，所以，要想让动态语言语言运行在上面，需要额外做一些工作，搭建一套支撑动态语言的结构。不过，随着一些动态语言逐渐被移植到JVM上，人们也意识到了这个问题上，开始考虑在JVM中增加动态语言的支持。

除了执行性能之外，编译带来的好处还在于保护源代码。因为解释方式通常不会保留的其中间形式，所以，产品发布意味着将源代码也发布出去。对于需要保护知识产权的公司和个人而言，这是他们所不愿意看到的。通过编译的方式，我们将源代码转成了二进制，这样，源代码可以得到有效保护。当然，破解二进制也是有可能的，不过，那就是另外的故事了。

今天是一个发布的日子，XRuby发布了0.3.1，Ruby Hacking Guide中文版发布了第一部分。

XRuby 0.3.1

相比于前一个版本，XRuby 0.3.1最大的进步在于完成标准库的预编译。预编译意味着什么？标准库代码无需在每次运行时编译，这意味着今后使用XRuby的标准库性能会得到一定的提升。

有一个与编译相关的话题。之前，Jon Tirsen曾经谈到JRuby的一个问题，运行在AppServer中会有占用太多内存。经过分析得知，为了提高程序的并发性，程序运行会启动多个JRuby。每个JRuby解析Ruby脚本都会建立一棵完整的语法树，这就意味着，由于这种解析模式本身的限制，对于同样的内容，内存中需要保存多份相同的语法树，这种做法意味着无谓的耗用了大量的内存。采用编译的做法，则可以很好的避免这个问题。因为在运行时，相同的是字节码，而JVM很好的帮我们解决字节码共享问题，无需耗用大量的内存。

Ruby Hacking Guide中文版第一部分

RHG终于完成了第一次发布。已经发布的第一部分介绍的是Ruby的对象模型。我正是从这个部分开始了解Ruby实现的，进而完成了XRuby的Runtime的重写。所以，我一直觉得这部分是了解Ruby实现非常好的一个起点。

从翻译Ruby Hacking Guide到现在已经超过了一年，从第一次发布消息算起也超过了9个月。相比XRuby，这个项目的进展可以用异常缓慢形容。这是一本日文书，也是一本技术书，而且是一本讲语言实现的书。任何一个点都会增加翻译的难度。几个懂日语的朋友先进行一遍初译，然后，我对再对译稿进行一遍校验，并根据自己的理解修改译稿，这样的过程无疑延长了处理的时间。这是一个业余时间的项目，而我更多的业余时间在XRuby上，没有太多精力投入上面。种种的因素造成了这个项目的一托再托。

目前，我手头已经有了第二部分全部和第三部分几章的初译稿，不过，按照之前的进度来看，这几章的发布可能要等到许久之后了。如果你有兴趣，可以加入到这个项目中来，这样，有助于加快这个项目的进度。

《管窥Ruby——类的变量》写在去年，写成之后便更新了一次，因为最初的描述存在一些偏差。即便如此，jxb8901依然指出了其中的一些不足。最近，dennis-zane再次提出了这个问题。回过头来仔细品味，确实有些地方写得不是很到位，索性把它重新写过。

管窥Ruby——类的变量

变量和方法是面向对象难以割舍的两个重要组成部分。在《管窥Ruby——类的方法》中，我们谈到方法，沿着这条路继续，我们再来看看类中的变量。

开始之前，我们还是要再次回顾RClass的定义：
struct RClass {
    struct RBasic basic;
    struct st_table *iv_tbl;
    struct st_table *m_tbl;
    VALUE super;
};
(ruby.h)

如果你看过《管窥Ruby——类的方法》，了解了方法存储方式，变量的存储方式便也一目了然了，同样的st_table，意味着同样的处理方式。

不得不承认的一点是，在讨论类的方法时，我故意忽略了一个事实：方法分为类的方法和实例的方法两种。如果对其它语言实现有些许了解，我们知道，这两种方法差别仅仅是this（C++或Java的说法），到了底层时，这个差别可以视为无物，可以统一存放。关于这点，有兴趣可以参考一下《深入Java虚拟机》，它的第五章讲解了虚拟机内方法的表现形式。在Ruby中，类的方法和实例的方法并不是存放在一起的，这里定义的实际上是实例方法，而类的方法是定义在类的Singleton类中。

遇到变量时，我们会碰到同样的问题：类的变量和实例变量是无法统一管理的。因为类的变量只有唯一的一份，而实例变量则是每个实例都有一份。所以，RClass存放的并不是真正实例变量。代码是说明问题的最好方式，下面这段代码说明了如何设置实例变量：

VALUE
rb_ivar_set(obj, id, val)
    VALUE obj;
    ID id;
    VALUE val;
{
    if (!OBJ_TAINTED(obj) && rb_safe_level() >= 4)
        rb_raise(rb_eSecurityError, "Insecure: can't modify instance variable");
    if (OBJ_FROZEN(obj)) rb_error_frozen("object");
    switch (TYPE(obj)) {
      case T_OBJECT:
      case T_CLASS:
      case T_MODULE:
          if (!ROBJECT(obj)->iv_tbl) ROBJECT(obj)->iv_tbl = st_init_numtable();
          st_insert(ROBJECT(obj)->iv_tbl, id, val);
          break;
      default:
          generic_ivar_set(obj, id, val);
          break;
    }
    return val;
}，
(variable.c)

抛开前面那些复杂的东西，直接来看switch语句后面的内容。这里存在两种情况，对于存在T_OBJECT、T_CLASS和T_MODULE标记的，变量会写入iv_tbl，而其余的情况则转交 generic_ivar_set处理。iv_tbl是“实例变量表（instance value table）”的缩写，不过，如果当前对象是个类对象，这个“实例”变量实际上就是类变量，所以，这个名字多少有些名不符实。

除此之外，还有一个generic_ivar_set。下面是generic_ivar_set的实现：

static void
generic_ivar_set(obj, id, val)
    VALUE obj;
    ID id;
    VALUE val;
{
    st_table *tbl;

    if (rb_special_const_p(obj)) {
        special_generic_ivar = 1;
    }
    if (!generic_iv_tbl) {
        generic_iv_tbl = st_init_numtable();
    }

    if (!st_lookup(generic_iv_tbl, obj, (st_data_t *)&tbl)) {
        FL_SET(obj, FL_EXIVAR);
        tbl = st_init_numtable();
        st_add_direct(generic_iv_tbl, obj, (st_data_t)tbl);
        st_add_direct(tbl, id, val);
        return;
    }
    st_insert(tbl, id, val);
}
(variable.c)

同样忽略一些非主干的部分，我们看到，这段代码先在一个generic_iv_tbl中进行查找，用作查找键值的是对象实例（obj），而目标同样是一个st_table。得到这个表之后，利用变量名做键值将值插入到表中。我们便不难分析在这种做法中实例变量的存储方式。存在一个全局的实例变量表，走到这里的实例都在其中拥有一席之地，而实例变量存储在实例对应的表中。Ruby通过这样一个二级结构，解决了这些实例变量存储的问题。

了解过基本的做法之后，随之而来的一个问题就是，这些代码都会在什么情况下起作用。

代码已经说得很明白了，只有在有那几个标记的情况下，才会直接调用iv_tbl。T_CLASS和T_MODULE都很好理解，那什么情况下会有T_OBJECT呢？在C Ruby中，在Ruby层次上定义的类，生成的实例都是会标有T_OBJECT（参见《管窥Ruby——Allocator》）。所以，所有由Ruby层次上生成的对象都会走到这里来。

那generic_ivar_set呢？除了那几个标志外的其他部分都会走到这里。除此之外的标志表示什么呢？读一下代码我们便不难发现，几乎就是builtin的几个类，比如数组、字符串、正则表达式等等。那为什么这些builtin类没有一个iv_tbl。对于这些builtin而言，它们真正的实例变量都是以C的形式给出，所以，额外存在一个iv_tbl实际上是一种空间上的浪费。

虽然不是常态，但我们依然可以为这些builtin类添加自己的实例成员。为了保持Ruby的动态特性，这才有了generic_ivar_set的存在。

今天下午，和Darwin聊了一下C++单元测试框架，主要参考对象是CppUnit和CxxTest。

表现形式
因为C++不支持reflection，所以，必须要做一些额外的工作，让框架知道相关内容的存在。CppUnit的做法是用宏进行注册。这种做法要求我们每添加一个测试，就要考虑用相应的宏进行注册，这种做法很繁琐，最大的问题在于由于疏忽而遗漏，这种靠人工保证的东西不可靠。在这点上，CxxTest做得要好一些，有一个专门的脚本做这件事。通过这个脚本扫描这个自己编写的文件，生成一些新的文件，完成这个工作。从代码的表现力和可靠度来说，要好得多。唯一的问题是引入了一个脚本，而且这个脚本一般是由某些动态语言写成的（目前的CxxTest有Perl和Python的脚本），从而引入了对这种语言的依赖。不过，由于C++语言本身的限制，从接口的角度来看，这种做法已经很不错了。

语法
有一种C++的单元测试框架叫TUT，Template Unit Test的缩写。顾名思义，它是用模板完成的（其实，CppUnit和CxxTest都有模板的部分）。随着C++编译器的进步，在大多数情况下，模板都是可以顺利通过编译的。但是，不要忘了，还有一种环境叫嵌入式，那里的编译器基本上还是很原始的，模板并不见得能够顺利的通过编译。

此外，模板还会带来另外一个问题，编译时间的增长，相信有过模板编程经验的人都会对此深有体会。编译时间增长意味着什么？我们接下来讨论。

编译时间
有一种敏捷实践叫做测试驱动开发（Test Driven Development）。测试驱动开发的基础是单元测试。测试驱动开发希望达成的一个目标是快速反馈，所以，站在C++语言的角度，如果执行时间受限于代码本身无法缩短，那么我们希望编译时间尽可能短，这样，才不会把生命都浪费在等待代码编译上。

除了刚才提到的模板问题之外，CppUnit会把所有测试编译生成一个可执行文件，这意味着什么？几乎修改任何一个文件都会造成这个文件的重新生成。随着目标文件的增加，这个过程时间就会增长。相对于修改范围（可能只是某一个文件），还是显得有些长了。为什么Java语言不会存在这种现象？因为Java是动态连接的，所以，Java生成.class就结束了。对应到C++上，这只是完成了目标文件的生成，而在C++我们不得不再进一步生成可执行文件。从道理上，CxxTest可以为不同的测试文件生成不同的可执行文件，不过这么做又少了总体的过程，统计起来又显得心有余力不足了，而且通常不会这么做。

个人而言，对这几个单元测试框架都不是非常了解，如果前面的讨论存在谬误，欢迎有识之士指出。

一年前，yawl将自己用业余时间做了一年的项目开源了，这就是XRuby。
XRuby project is now hosted on Google Code
有人愿意做Ruby Compiler么？

我就是那时加入XRuby的，依然记得最初见到这个项目时的兴奋，转眼，一年过去了。从2007年1月29日0.1.0发布至今，我们一共发布了7个版本。XRuby正逐渐变得越来越有样子：代码越来越干净，功能越来越强大。

XRuby是我第一次真正全身心投入参与的一个开源项目：常常为自己漂亮的解决了一个问题而自豪，也时常为解决方案不够优雅而寝食难安。依然记得有几次，为了实现一个功能而熬夜；也有本来已经躺在床上，却难以抑制兴奋爬起来继续编码。这一年里，XRuby在成长，我也随着这个项目在成长，对Ruby语言的实现理解越来越深，从最开始的照搬C实现，到现在逐渐有了一些自己的想法在里面。在与大家合作的过程中，从其它人身上学到了许多足以让我受用终身的东西，尤其是yawl。相信其他深入参与XRuby的人与我有着类似的经历和感受吧！

其实，在这一年里，我也并非始终如一的对XRuby付出着。从项目最初开源到发布0.1.0之间有大约4个多月时间，完成了那个新runtime之后，很长一段时间，我并没有写太多代码。那段时间，应该是我参与XRuby过程，感觉最为黑暗的一段时间，因为确实看不到这个项目的方向，没有版本发布，漫无边际的代码等待着编写，而我写的新runtime又很难集成到XRuby里面。这个状态一直持续到0.1.0的发布，我似乎一下子看到了光明，尽管XRuby看起来那么不成熟，但我们的努力终于得到了一丝回报，于是，我兴奋的写下了《XRuby发布了！》 。

在我找回动力之后，XRuby也逐渐开始得到了越来越多的关注，项目成员也逐渐增多，XRuby也逐渐步入开发的正轨。每隔一个多月，我们就会发布新版本，每次新版本的发布，都增强着我们对XRuby的信心。XRuby的成员也通过各种途径向大家介绍着XRuby，也有人开始讨论XRuby。

做开源，最艰难的是什么？技术吗？似乎是，尤其像XRuby，仅仅一个“编译器”的名头，就足以让许多人望而却步了。其实不然，技术这东西，只有不愿意学的，少有难以学会的。参与XRuby并不需要一开始就掌握复杂的编译器技术，因为XRuby包括了许多部分，编译器只是其中的一个部分。时至今日，XRuby中的某些部分对我来说，依然是陌生的，但这并不影响我为XRuby编写代码。从个人的经历来看，builtin是一个很好的入手点，而那里并不多数情况下并不需要了解编译器，甚至几乎不需要了解Ruby内部实现。

在我看来，最难的是坚持。用业余时间，无偿为一个项目付出着。回报？除了知识和技能上的提升，其他都是不可预期的。在这种情况下，坚持着实是一件困难的事情。其实大家可以很清楚的看出来，这个世界上，开源项目不计其数，但真正能让人知道的少之又少，许多开源项目在开始后没多长时间便死去了。在国内论坛中，很多开源项目的发起者都在抱怨，开源环境很差，没有人参与他们的项目。当然，这其中也有项目本身吸引力的因素。其实，做开源是需要一些理想主义的，这样，才能在一条未知的路上前行。XRuby中也存在类似的问题，许多参与者一开始总是兴致勃勃的要求加入，好一些的，贡献了一些代码之后，便很长时间没有声音，有的则在加入之后，一行代码都没有写，便无声无息了。从加入开始一直比较稳定的贡献代码的人，屈指可数。不过，从另一个角度，这也说明了，当一个开源项目具备了一定的生命力之后，并不会因为某个人的不作为而死去。

不管一路上有多少阳光和风雨，XRuby走过了它的第一个生日，步入了第二个年头，大家已经开始尝试着进行Rails的支持，我们会努力让它走得更好。在班加罗尔讲XRuby时，有人问过我，现在XRuby面临的主要问题是什么，我说，我们没有足够的资源。其实，现在可以看到的很多问题对我们来说，并不是非常困难，但却需要投入大量时间来完成。这也是我们始终如一的欢迎有兴趣的人加入我们的原因。如果你愿意和XRuby一起成长，欢迎加入我们！

做了一件让自己觉得不可思议的事情，在班加罗尔的Geek Night用英文讲XRuby。

这周早些时候，在办公室遇到了Sidu——我在西安办公室见过他。周五有个班加罗尔Ruby User Group的活动，叫 Geek Night，Sidu是活动的组织者。之前，他知道Ola会来，于是安排Ola介绍JRuby。当他看到我的时候，才知道我也来了班加罗尔，于是邀请我也一起参加活动。我问他，我是否需要准备什么，他建议我做一个XRuby的介绍。Ola会有一个45分钟左右JRuby方面的介绍，所以，我需要做的只是一个简单的XRuby介绍。很合我意，因为要用英文讲，所以，如果讲多了，我恐怕自己不成。我很快就准备好了一个很短的介绍。

ThoughtWorks做事总是要敏捷的。今天，我发现Ola没来，后来才知道Ola病了。所以，Ola的部分就取消了。Sidu问我怎么办，我只好硬着头皮答应由我讲一个长一点的，一个比较完整的XRuby介绍。晚上六点的活动，商量好这些的时候，已经是四点多了。所幸之前讲过XRuby的介绍，我把讲稿翻出来修改了一番，更新了一些状态，准备用在活动中。XRuby介绍这个稿子居然得到了反复应用，第一次在北京Java User Group，第二次在 敏捷西安，据说，XRuby的其他成员也用过。无论如何，我没想到，我个人的第三次居然是在班加罗尔，而且是英文。

其实，最让我头疼的绝对不是介绍XRuby，而是用英文。这周在班加罗尔上课，对我来说，简直就是一周的英文课。所有课程所有讨论都是英文，我的英文水平让我经常就不知道大家在说什么。不过，自我感觉，经过一些锻炼之后，还是略有提高的。

活动开始，我开始了第一次用英文在比较公开的场合讲东西。我的开场白是，这是我第一次用英文讲。起初，活动在一个小会议室进行，在我讲的过程中，进来的人越来越多，所以，我们又换到了一个比较大的会议室。因为用英文，我只能说，我尽量把我要表达的意思说出来，至于是否大家听懂了，我不好说。好在有讲稿，即便我讲得不够清楚，讲稿也会帮助大家多一些理解的。当翻到讲稿最后一页的时候，我长出了一口气。如果是用中文的话，我可以说得更多，至少我可以胡扯一些东西。对我来说，更大的挑战是Q&A。我的听力本来就不是太好，印度口音更是经常让我犯晕。开始之前，我找了几个同事，如果我听不懂的话，他们可以为我解释一下。在提问者的宽容和几位同事的帮助之下，我成功的度过了Q&A。问题倒不算太难，唯一让我不敢确认的是，我说的是否真的是我要表达的意思，希望没有大错。

不管怎样，我用英文讲了一次XRuby，一次很有趣的经历。

在ThoughtWorks里，交流是工作中非常重要的一个部分，在这里工作时间越长，这一点感觉得越加明显。今天，和我们团队中的一个人聊天，他教了我一些交流上的技巧，这里做一个简单的备忘。事实上，他教给我的远不止这些。

交流中，最大的障碍就是双方是否真的理解了对方的意思。造成误解的原因可能有很多：
* 双方都认为自己理解了问题，但这种理解可能并不一致。
* 因为背景不同，所以，双方对达成一致所基于的假设是不同的。
* 语言之间的障碍，这点我最近颇有体会
* 双方对问题理解的深度不一致

同事交给我的解决方案就是不断问问题，不断解释自己对问题的理解，对方接收到反馈就会判断与他的理解是否一致，然后再给出他的看法，这样几个来回下来，双方基本上就可以达成一致。有些人可能认为反复的问问题，反复澄清自己的理解似乎会让自己的看上去很傻，所以，听得差不多就不愿意问了。我们的根本目的是完成工作，如果因为前面不愿意看上去丢人，后面可能就要真正的丢人了。其实，没有人会认为把问题搞清楚是丢人的。

再有一点，交流之后要尝试总结，通过总结：
* 确定真正理解问题所在
* 确定双方对问题有一个共同的接收标准
* 确定双方能够在进度上达成一致

学到了，争取用起来！

写下这篇blog时，我在迪拜机场。没错，阿联酋迪拜。

起因是要到印度参加培训。ThoughtWorks通常会对入司的新员工进行一些培训，使其更加了解公司的文化和做事的风格，其中很著名的是TWU。不过，TWU是给毕业生预备的，所以，我没有机会参加。我去参加的是另外一个课程。不同于TWU固定在印度，这个课程的培训地点是变化的，这次刚好在印度的班加罗尔。

要去印度，我却出现在阿联酋，是的，我是来转机的。只要有些地理常识都会发现这条路线极其诡异。据 Jessie的blog记载，她是这条诡异路线的始作俑者。早几天去TWU的几位同事是通过新加坡转机，至少从常识和心理上来说，更容易接受一些。

这次坐飞机让我见识了一些新鲜的东西。我乘坐的是A340-300，很大的飞机，一排有八个人。每个面前都有一个小电视，配有一个遥控器，居然这个遥控器还是个游戏手柄，所以，在路上，我还自行娱乐了一下。一上飞机，就可以发现，每个人的座位上，都预备好了一些东西，比如小枕头，毯子和一些小东西。我以为大夏天的可以不用毯子，结果充足的空调还是让我决定把自己盖上，以免感冒。这次旅行是我第一次在飞机上过夜，因为起飞的时间就是23:55。个人而言，我不是特别喜欢长途旅行，尤其需要过夜的，身体会很疲劳。飞机会比火车舒服一些，但要在飞机上过夜，还真的不如火车的卧铺，无论我怎样调整姿势，总是不如躺着的感觉舒服。当然，比火车硬座要好得多。同机的有一群要到塞浦路斯去表演的小朋友，有他们在，飞机上热闹了许多。人家航空公司想得还真周全，每个人送了一个小玩具，孩子们很高兴的给周围的人展示着自己的玩具。

到迪拜的时候是当地时间早上五点多，一下飞机却让我感到了桑拿天气，长期生活在这里的人真的要有很好的耐热能力才成。从我下飞机到再次上飞机，之间的间隔有六个小时。所以，我和同行的同事在机场可以活动的区间里转了一大圈，了解周边的环境。在一个免税的店里，他拿起一个Sony的耳机，我居然看到了中文，仔细一看，Made in China。在这里，中国人（至少是中国人面孔的）很多，让人误以为只是在国内的机场，经常可以听见有人在用中文聊天。当我们在一个地方喝水聊天的时候，竟然还有人用中文来向我们问路。就在写这篇blog的时候，后边过去的两个人在议论大连如何如何。迪拜的机场地上铺有地毯，这让我想起了我们公司的办公室。在办公室时，我时不时的就会坐在地上办公。在这里，可以看到很多人席地而卧，悠然入梦。

就在刚刚，同事奇迹般的发现，居然有无线网可用，于是，赶紧打开机器，在迪拜机场发一篇blog，作为纪念。

还有一段时间我才能再度起飞，若干小时之后，我会出现在印度。