梦想风暴

做了一件让自己觉得不可思议的事情，在班加罗尔的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，作为纪念。

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

在ThoughtWorks工作已经有三个月了，快乐的事情在blog上体现了不少。找点让我头疼的话题聊聊吧！

ThoughtWorks是个外企，所以，必然要大量的使用外语，而外语偏偏是我的弱项。当然，我没有不堪到一点英语不懂的份上。我的英语对付日常的读写没有什么问题，主要就是在听说上。我就是那种传统英语教导出来的哑巴英语，要不是之前和两个朋友曾经专门学过一段时间，我的英语恐怕到现在还是完全张不开嘴的水平，也就不可能能通过TW的面试。现在在北京的办公室里有不少来自其他办公室的同事，所以，不得不与他们进行交流。平时，有时还会有电话会议，原本听力就不那么好的我，再加电话里有些杂音，经常不知道对方在说什么。不过，自我感觉，这几个月下来英语还是有提高的，但为了如果想更好的与外国同事交流，英语还要进一步提高，这样的话，才可能讨论一些相对深入的话题。

前两天，和老大聊天，他提到了中国人同其他国家人的一个差别。我们比较含蓄，通常会在深思熟虑之后，才提出自己的问题，他们通常会把自己想到的都摆在台面上。所以，这就造成了一些沟通上的障碍，有些时候，我们本来已经发现了问题，但常常会考虑该不该把问题提出来，把问题提出来会带来什么样的影响。结果，往往是在思前想后的阶段，就耽误了一些事。当然，完全展现自己的想法也并不一定就是好事，有一些明显错误的东西还是有些浪费大家时间。和一个在微软的同学聊天，他也提到，他们公司也是鼓励大家想法说出来。只有把想法说出来了，它才是存在的，否则，最后的结果可能就是消亡在自己的大脑中。

现在在做的其实是一个产品方向，这就需要人有更加全面的能力。因为做项目的时候，我们往往只要关注特定的平台（OS、数据库、浏览器……），但是做产品要兼顾的内容就要广泛得多，有不少问题只有在特定的平台上才会显现出来，比如MySQL的数据库表名在Ubuntu下需要区分大小写，而在Windows上则不区分。这就暴露出我在这个方面的不足，我做过开发的平台其实并不多，所以，有些时候，我经常需要找同事来帮忙，还好，大家通常是只要自己知道，就会不遗余力的帮助你。

现在我实际上是在一个分布式的团队中工作。说实话，我并不太喜欢这种工作方式，因为可能一个和你工作了很长时间的人，甚至都不知道长成什么模样。道理上没什么，但总不如直接在一起工作，那样的话，交流成本更低。我现在更容易理解为什么我们公司要让大家围坐在一起，这样，有话就说了，即便是一些无聊的话。再有，不熟悉的人总不如熟悉的人交流起来得自然，公司经常会有一些team building的活动，而且通常会鼓励不熟悉的人坐在一起，其目的就是为了大家增进了解，这样的话，在工作中就可以更好的进行沟通。而对于一个分布式团队来说，这一点就很难实现。

之前做项目的时候，大多数时间都是拿到一个比较明确的任务，然后进行开发。而现在有些时候，某些任务并不是那么明确，虽然大的方向一直在那。仅仅拿远景说事，是不能完成任务的。这样的时候，是需要一些主管能动性让那些大目标变成一个个具体可行的目标。由于适应了之前那种工作方式，我经常会在那里等待。这在无形中就是一种浪费，对公司来说，也是一种损失。

这样那样的问题，只能说明一点，对于我现在所从事的工作而言，我在某些方面还存在一些不足。发现不足是进步的基础，努力让自己成为一个更加合格的ThoughtWorker。

XRuby0.3.0发布了！恰好今天是奥运倒计时一周年，所以，这个版本顺理成章的成了纪念版。

在这个版本中，除了让更多单元测试通过之外，最大的变化是在Annotation的应用上。关于Annotation的工作，我已经在自己的blog上讨论过一些，这里再整理一下。

Ruby的方法总要有一个对应的底层语言实现。在C Ruby中，这个对应就是一个C的函数，而定义的时候，直接使用函数指针去做这个关联。而在Java中，因为没有函数指针，作为替代方案，我们可以使用一个对象。在XRuby的实现中，RubyMethod的存在就是为了这个目的。所以，在XRuby中对应到Ruby的方法都源自RubyMethod，比如下面这段代码：

public class String_to_f extends RubyNoArgMethod {
   protected RubyValue run(RubyValue receiver, RubyBlock block) {
       return ((RubyString)receiver).to_f();
   }
}

从上面展示的代码中，我们可以看到，为了实现这段方法，最终需要访问receiver的内容，而且，在事实的开发中，我们经常发现一个两难的抉择：究竟把方法的具体实现放在RubyMethod中还是放在Java的方法中。

有了对应的实现，我们还需要将它注册到系统中：
StringClass.defineMethod(“to_f”, new String_to_f());

这段虽然不复杂，重复编写也不是一件让人愉快的事情。

通过Annotation，我们可以更好的解决这个问题，下面便是对应于上面实现的代码：

@RubyLevelClass(name="String")
public class RubyString {
    @RubyLevelMethod(name="to_f")
    public RubyFloat to_f() {
        ...
    }
}

在这里，我们使用RubyLevelMethod将一个Java的方法和Ruby的方法绑定在一起，这个Annotation表示，一方面会生成一个对应于这个方法的RubyMethod实现满足调用规则，另一方面会在Ruby的类中定义出这个方法，减少了一些重复编码的工作量。使用Annotaion避免了前面提及的那种两难，所有的方法都实现在Java方法中即可，这样，便可以有效的减少设计上的迷惑。再有，这个Annotation可以让Java方法和Ruby方法的关联一目了然。

一如既往的欢迎对XRuby有兴趣的人加入到XRuby的开发中来，在这里，总是有一些有趣的问题可以解决。