记录上下文相关信息可以用MDC，MDC 的用法非常简单。首先在logback.xml 里面用%X{your_key} 标记需要记录上下文信息。然后在代码中用MDC 记录your_key 的值。举例：

T.java:
MDC.put("your_key", "your_value");
logger.info("Hello World");

logback.xml
<layout class="ch.qos.logback.classic.PatternLayout">
   <pattern>%d{yyyy-MM-dd HH:mm:ss} %X{your_key} %msg%n</pattern>
</layout>

output:
   2012-12-17 23:20:45 your_value Hello World

区分不同的模块的日志，可以在getLogger() 的时侯根据logger 的名字拿到不同的logger-> appender 。不过这条路略微有点土。用SLF4J 的marker 可以相对优雅的解决这个问题。可惜，目前只有logback 才支持。

如果把所有的日志混在一起记录，只是用关键字做区分，很简单，之需要在代码中声明marker，然后在logback 中配置就可以了。举例：

T.java:
MDC.put("your_key", "your_value");
logger.info("Hello World");

logback.xml
<layout class="ch.qos.logback.classic.PatternLayout">
   <pattern>%d{yyyy-MM-dd HH:mm:ss} %X{your_key} %msg%n</pattern>
</layout>

output:
   2012-12-17 23:20:45 your_value Hello World

如果把不同模块的日志要放到不同的文件里面，还需要配合Filter 才能做到，有一点点编码的工作，继承AbstractMatcherFilter 做一个简单的匹配过滤就可以了。举例：

public class MarkerFilter extends AbstractMatcherFilter<ILoggingEvent> {
    private Marker markerToMatch = null;
    @Override
    public void start() {
        if (null != this.markerToMatch)
            super.start();
         else
        	addError("!!! no marker yet !!!");
    }
    @Override
    public FilterReply decide(ILoggingEvent event) {
    	Marker marker = event.getMarker();
        if (!isStarted())
            return FilterReply.NEUTRAL;
        if (null == marker)
            return onMismatch;
        if (markerToMatch.contains(marker))
            return onMatch;
        return onMismatch;
    }
    public void setMarker(String markerStr) {
        if(null != markerStr)
            markerToMatch = MarkerFactory.getMarker(markerStr);
    }
}

然后在logback.xml 对应的appender里做下配置：

<filter class="your.pkg.MarkerFilter">
    <marker>TEST_MARKER</marker>
    <onMatch>ACCEPT</onMatch>
    <onMismatch>DENY</onMismatch>
</filter>

这样通过TEST_MARKER 标记的appender 就能互相独立开了。比较麻烦的是如果模块很多，那么必须都要有相应的marker 做对应。

前面不分日志文件简单标记的情况，在做日志分析的时侯，前面可能需要做个预处理，以区分不同业务模块。而后面的方法，不需要预处理就已经业务模块对应日志文件，但是对应的配置起来比较麻烦。见仁见智。

References:
http://www.slf4j.org/
http://www.slf4j.org/faq.html
http://www.slf4j.org/extensions.html
http://logback.qos.ch/
http://logback.qos.ch/recipes/
http://logback.qos.ch/manual/filters.html

上一篇B文第一条说手机会是社交网络的中心节点。这篇B文就说说我为什么觉得她应该是这个中心节点，以及她应该长成什么样子。

所谓的SNS 社交网络，其实只不过是人们的社交活动，从现实到网络的一种表现方式。SNS 的流行，是因为越来越多的人能够越来越方便的连接到网络。随着smart phone的普及，各个SNS 应用都推出了手机版本。为什么？因为手机是最便捷的网络接入方式。她够小巧，可以方便地装在口袋里随身携带。她够直接，只要有3G信号的地方就能接入。她够快速，现在smart phone的平均水平已经在1+1+1之上了。她够全面，联系人的各种联系方式都能在手机上存储。

除了SNS 这种半虚拟的社交方式，手机还是完全真实的社交活动的节点。在网络不存在的时候，人们用书信，用电报，用电话联系着。他们的生命周期从几千年几百年到最近几十年，人们一直追求的就是更快速直接的与人沟通。书信现在有了Email和IM，电报的方式已经被抛弃了，电话从固定电话发展到现在的手机。我想象不出将来会有什么东西取代手机。在我看来手机的形式基本已经到了极限。打电话、发短信、Email、IM和SNS，她都可以很方便的解决。也行将来人们的联系方式可以更简化，但是估计不会有比手机更便于携带的工具了。嗯，我得说，天线宝宝的帽子其实也是个好东西。

现有的手机通讯录只是存储了个人的信息。从老的feature phone 到现在的smart phone 逐渐发展中，有一点已经很明显了，就是个人的联系方式增多，对应的通讯录存储的信息也增多，固话，移动电话，Email，IM 等等。但其实在通讯录中这些信息都是孤立的。Feature phone从通讯录中只能打电话发短信。当然，必须得承认在今天的smart phone时代，这点正在发生变化。以我的Android手机为例，在通讯录中已经可以直接调用Email发送功能了。但是其他的还不直接联系起来。当然这跟各个IM、SNS都几乎采用不同的协议有关系。然而，如果采用插件的方式，允许第三方开发与IM、SNS对应的插件，又会如何呢？

我观察过Android 和iOS 两种最流行的手机操作系统。至少在这两种系统中，各个交流工具之间是互相孤立的。这里的交流工具指电话、短信、Email、IM和SNS所有的沟通方式。比如，在通话记录中，没有办法知道我是否给刚打过电话的人发过短信。在IM 里，我也不知道对方是否在SNS 中给我留下过什么。腾讯的QQ 做的不错，她的客户端能提醒联系人通过各种方式留下的信息。腾讯有一个大的数据平台，她可以知道各种信息。我有一个智能手机，我也需要知道各种信息。

智能手机其实已经能够知道各种信息了。电话短信不用说了，是个手机就行。安装各种应用也能支持Email、IM和SNS 这类应用。但问题是，我很懒，我也不会自己装那么多乱七八糟的应用；我的朋友很多，他们都有各自喜欢的表达自己向外界传递信息的方式。现在的矛盾是，个人懒惰的天性和众多联系人诸多的喜好之间的矛盾。我只想每次直接打开一个应用，在里面就能看见所有联系人，不论是虚拟的还是现实的，他们最近的动向；以及我和他们之间的联系。

每个人的朋友都很多，但其实这些虚拟的或者现实的朋友，他们与你的联系方式一般不会超过三种以上。现实的朋友一般是电话短信，接触网络多的，可能会是电话和IM。虚拟的朋友一般是IM和SNS，关系亲密的，可能会加上电话。商务关系一般是电话和Email，可能会有CRM通知。所以在单一应用中组织三种联系来源是有合理性的，而且从技术上来说完全有可能的，并不会显得特别复杂。可能存在的问题是，由于生物多样性，在总数上，这个信息来源可能不是收敛的。但是，滚滚历史的车轮，真扯，是主流力量推动的。所谓主流，其实也就那么几种。所以基本上来说，这事靠谱。

我被自己说服了，我打算先做出这么个东西来看看，先从Android开始，刚买了个水货，不能白花银子。如果你也感兴趣，可以联系我。

天然的联系人，人类一直都是社会化的。人与人之间一直互相联系，烽火，信件，电报，电话，手机。联系工具不断进化，到今天的手机功能已经极其强大了。SNS 现在是一个很流行的趋势，而手机以其天然的特质，自然而然倍受关注。这也是移动互联网一个很好的创业方向。

1/ 随时随地与世界沟通钥匙

3G /4G 时代手机联网速度飞快，接受最新信息，表达自己。墙外的Twitter，墙内的t.xx 都是这类快速简洁的沟通方式。黑莓最流行的邮件服务，随时随地让别人抓得住你。坐公共交通工具，经常听见小企鹅叫唤，嗯，山寨机也一样叫唤，可见所有的人都是要与世界沟通的。手机以其便于携带的特性，基本成为了行走江湖的首选。

2/ 闲散时间娱乐工具

现在手机上最流行的应用就是游戏类的了，这些游戏基本全是休闲小游戏，可就广大劳动人民抓空休息的需求是多么迫切啊。智能手机现在有个普遍的趋势是大屏，这样的一个结果就是拿手机来阅读也很方便了。看看现在的手机，前后摄像头，普遍的500w像素，几年前的数码相机的水平，随手拍随手分享，也日益流行。著名的Instagram，cool。

3/ 小巧的便利性电器

我们一直拿来幻想IPv6 美好时代的故事就是，家里所有能通电的都分一个IP，都能远程控制。在智能手机之前，这事其实挺能的，因为控制过程不是连续的。但是有了移动联网设备之后就不一样了，目前来看最方便的移动联网设备就是智能手机了。

4/ 整个互联网世界的神经元

云端服务是一个个的中枢，电脑、平板和手机就是无数的神经元，其实以数量来说最多的就是手机了。而且随着智能手机的处理能力越来越强，手持智能手机，能做到的事情越来越多了。

–TBD–

最近在做技术概念验证，为下一个项目做准备。碰巧，这次主要目的就是要检验SOA 适不适合我们下一个项目。由于整个团队对SOA 理解不多，而且选择的目标平台也多少有点灰煮牛，所以这个验证过程多多少少出现了一些问题。本文把这个平台叫做J 记SOA 平台。

J 记有配套的开发工具，有要钱的商业版，也有不要银子的社区版。因为没钱，所以只能拿免费的社区版来用。对我来说这个社区版有两个问题，首先配置约束不够，很多可视化的配置文件编辑，各个配置项属性之间的前后约束都没有，如果不是对J 记平台非常熟悉的话，光靠这个社区版的开发工具，恐怕很难折腾出一个能运行的例子出来。其次，和服务器结合有问题，经常不能直接在IDE 内部迭代发布，严重影响开发效率。也许商业版不会有类似的问题，可惜我没用过，没有发言权。

如果非要加上第三个问题的话，那么我会选择配套的示例和文档。即使我们这个团队和J 记稍微有点关系，拿到了很多收费文档，这些文档的价值也不是那么明显，很多地方版本对应不上，例子不够详细，参数介绍不全面。例子其实还可以，都能正常运行 -_-! 我只是觉得多少有点不够丰富。

总得来说，这个J 记SOA 平台在我看来多少有些山寨。当然这很大程度上是因为我潜意识的就不看好J记 的SOA 平台，希望看到本文的兄弟姐妹们不要受我影响。

老实说，用J 记平台之前，我没想到过居然会花好几天才稍微折腾起来这个东西，虽然我之前一眼都没看过这个平台，但我以为以自己对SOA 的了解，很快上手应该不是件难事。现实是，SOA 确实是个很宽泛的概念，每个平台都有很多自己的技术细节，虽然大体方向是一样的，但是在细节上也很难做到一通百通。所以我觉得，对新手来说，培训真的是一个必要的过程。尤其是对像我们这次这样，想要初次接触就要完整得采用SOA 平台来作为技术解决方案的团队来说。当然培训要有针对性。其实用基本不熟悉的东西来做方案真的是很有挑战性的一件事，不管是对干活的人，还是对客户。干活的人在孤立无援的状态下承担了工期的压力，客户在呗蒙在鼓里的情况下承担了产品是否稳定可用的风险。

还有一个问题之前没有在意过，只是在我们这个特定的技术验证的情形下我才觉得这是个问题。也许是为了清楚也许是为了什么，老外要求每个模块打个包放到J 记平台去部署。我们只是要搞个技术验证，几个很简单的服务，在这个打包思路下，居然有将近二十个包要部署，EJB，ESB，WAR等等。简直无法想象如果生产环境沿用这个思路会是个什么样子。如果真的那样，我一定会在精神病院发个B 文记录一下。

多少有些类似，不过我们这个简单的验证没考虑这么多。在你的生产环境中，你的诸多服务是怎么管理的？是散落在世界各个角落？还是分类整理在一个地方？你知道各个服务运行的情况吗？等等，等等，等，等等等。希望结合上面那个我认为不是问题的问题，会让你联想到服务治理多多少少还真有那么点必要。

软件SOA 化，也可能带来另一个问题。SOA 是以服务为基础的，把提炼出的服务组织在一起，快速影响业务需求，这是SOA 的初衷。我所说的问题就是，如果团队划分比较细，夸张的说，一个团队只支持一个服务。会出现什么情况？各家自扫门前雪，不管他人瓦上霜。又或者说一叶障目不见泰山，一个团队只看眼前，对整体失去了把握。不管是从优化业务的角度，还是从性能分析的角度，都是不利的。

当然我举的例子多少有些夸张了。但我认为，在以上示下的团队组织中，这种情形早晚都会出现。所以给所有团队予应用的整体概念是很必要的。让每个人都知道在做什么，发挥全体人民群众的智慧。

杂记一篇，不知所云。

Scala flexible syntax: bad or good?

Scala 风格太多变了，做一件事可以有N 条路。

比如声明一个方法：

val multiply = (x:Int) => x * x
def multiply(x : Int) : Int = {
  return x * x;
}

这方法都可以用multiply(3) 来调用。当然你完全可以说前一种是把匿名方法赋值给常量multiply。但是在我看来，这只是修辞上的问题，对结果并无影响。如果说上面这种还有说辞，那请看下面的代码：

val aaa = 1 to 3
val bbb = 1.to(3)

这两种形式是完全等价的，只是在写法上有区别而已。

在语句分割上Scala 也采取了比较灵活的方式，一行是一条语句，如果想把两条语句放在同一行，可以用分号分隔。上面的常量声明可以像下面一样写在一行：

val aaa = 1 to 3;    val bbb = 1.to(3);

当然即使分开写成两行，也可以把分号用作一条语句的结束。

上面只是最基本的两点，还有其他的一些诡异的地方。老实说这很大程度上是因为我对Scala 还不是那么熟悉，以致我在刚开始摸Scala 的时候无所适从，嗯，其实刚开始摸什么都是一样-_-!

只有一个参数的方法调可以用 object method argument 的方式，Python 也有类似的情形。不过对Scala，我采用了对待Python 同样的方式，直接忘记这种写法，只记得object.method(argument)，毕竟这和多个参数的写法一致。

还有一处乍看起来很迷惑，但是如果糊里糊涂起来却很自然的地方，Scala 的类型推断。大部分的强类型语言中，我们都习惯于先声明变量的类型，然后再进行操作，像继承自C 的编程语言，基本都是这个路子。弱类型语言不是这样的，弱类型基本是采用了推断的方式，即看变量被赋予了什么样的值。比如看下面的循环：

for ( i <- 1 to 2 ) {
  println( "No." + i )
}

变量i 并没有指定是何类型， 但是完全可以通过1、2 来推定是Int 。 很自然不是吗？

使用Scala，既可以写命令式的代码，也可以写函数式的代码。命令式的代码就不用说了，C家族的语言到现在基本都是命令式的。函数式的代码可以把函数作为方法传到函数内，下面是个简单的例子：

val sqr = (ss : String, x : Int) => ss + x * x;
def call(f : ((String, Int) => String), s : String, n : Int) : String = {
  f(s, n);
}
// sqr is a function
println(call(sqr, "3*3=", 3));

这个例子很简单，就是定义了一个方法，然后作为另一个方法的参数来调用。这个方法只能示例函数式大概的样子，函数编程的强大完全体现不出来。函数式编程最大的特点应该是每个变量只能初始化一次，一旦初始化之后就再也不能改变它的值，在Scala 中这样的变量用val 来定义。下面是另一个稍微复杂点的例子：

val nn = (0 to 10);
val whatisthis = nn.reverse.map(e => e + 10).foreach(x => print(x + ","));
println(); // just for a new line
nn.foreach(e => print(e + ","));

输出结果是：

20,19,18,17,16,15,14,13,12,11,10,
0,1,2,3,4,5,6,7,8,9,10,

稍微解释一下，nn 的类型为scala.collection.immutable.Range。这里，我们先把集合反转，再把每个元素加10，回头坚持最开始的nn，却发现没有改变。（whatisthis 什么都不是）

函数式的编程语言可以写出非常强大，但是短小精悍的代码，当然前提是习惯了函数式的思路。

Scala 是一门溶命令式和函数式为一身的编程语言。这当然是一个优势，熟悉命令式或者函数式编程方法的兄弟，都可以充分利用Scala 强大的库。但是对新手来说，如果陷入对两种编程方式的艰难选择而不能自拔，那么Scala的这种优势基本上就变成了一个灾难。所以，我强烈不建议新手们把Scala 用到生产环境中。只有对Scala 非常熟悉，能够熟练的应用两种思路最直接地解决问题，这时候才能真正把Scala 用于生产。毋庸置疑的，Scala 生产力非常强大，绝对值得投资。(非广告)

在使用Scala 时有这么多可用的方法可以选择，改如何是好呢？其实每种方法都有她的优点，不能说哪种是最好的，因为每个人看法不一定一样，而且不同的方式在特定的情况下可能分别都是最优方案。就我个人来讲，我倾向于在一份代码中采用相同的编码方式。在多人（甚至只要超过两个人）团队中，代码风格泛滥一定会成为障碍，尤其是对新加入团队的成员来说。在我的团队中，我会要求以下几点：
0/ 要么命令式、要么函数式，只能有一个主流，另一个严格限制在很小范围内
1/ 用大括号分割代码段，光凭换行不能充分利用文本编辑器
2/ 用分号结束语句
3/ 只有在非常明显的地方才省略类型声明，比如前面for 的例子
4/ 不用object method argument 这种方式，统一函数调用方式
5/ 变量统一用val 声明
6/ 不省略函数返回的return 关键字

最近在琢磨着整个BlazeDS的SCA binding出来，Tuscany 用的顺手了，自然就用Tuscany 来做SCA 实验。虽然因为从BlazeDS 中扒代码出来遇到了点困难，但是扩展Tuscany Biding 的思路已经理清，所以先写这么一篇来灌水。本文不涉及BlazeDS 的部分，只是列出几个兄弟在实现Tuscany Biding 中遇到的容易被忽略的地方。

0/ targetNamespace 在各处要保持一致

其实理由很简单，目标命名空间一致才能找到东东嘛。但问题是这个targetNamespace 分散在各处，而又没有统一的维护工具，目前的IDE 工具做的也不够好。嗯，当然也可能是我比较圡，没找到好用的工具。我的case 比较简单，就三处有targetNamespace：composite 配置文件，/META-INFO/services底下的ValidationSchema 和 StAXArtifactProcessor。

1/ 是否真有必要实现StAXArtifactProcessor

如果扩展的binding只要配置一些基本的属性，完全可以用org.apache.tuscany.sca.assembly.xml.DefaultBeanModelProcessor 来完成配置的解析，没有必要实现自己的StAXArtifactProcessor。比如，我的就一个uri 要配置，DefaultBeanModelProcessor 完全可以做这事了。注意：此项配置要保留，否则会杯具的。

2/ 尽量提供ValidationSchema

ValidationSchema 是用来保证Binding 使用者正确使用你的扩展的校验机制。如果提供了足够多的校验，并且提示信息都很友好，使用者很容易就能完成一个自我学习的过程。

3/ 实现ModuleActivator 不是必须的

ModuleActivator 是模块加载过程的第一步。如果扩展模块在加载过程中不作什么特殊动作，比如注册扩展点，完全可以不提供自己的ModuleActivator，用默认的就可以了。

4/ 心思细致

自定义扩展模块时必须要心思细致，因为有太多的配置，而且都是约定性的。

ps: 推荐两个参考资料
0/ 这是极少的参考之一， http://tuscany.apache.org/sca-java-extension-development-guide.data/ExtendingTuscany1.pdf
2/ Tuscany 源代码，各类扩展都可以找到对应的模块来参考。

中小企业如何开展SOA？这是最近半年来我经常被人问起的一个问题。看来经过铺天盖地的宣传攻势之后，大家都认识到SOA 确实可为、确实有价值，现在都想着怎么把它变现了。

考虑这个话题之前，我们先把公司分个类。对于厂商，其实没什么好说的。找准自己的路子，做的比对手更好就是了。嗯，实在找不到可以偷偷给我发个邮件-_- 好了，观众走了大半，只剩下IT 系统买家了。下面几段正是给软件软件使用者提供建议的。

老实说，一个老板几条枪的特小公司，其实真的没什么必要这么早考虑SOA。也许只需要一个Excel 做好账务工作就够了。先把脚跟站稳，生存下来是关键。

现在生存已经不是问题了。业务多了，人也多了，也采购了几套不同的系统。倒霉的是光图便宜，只买贱的不买合适的。同样的东西，这个系统一遍，那个系统一遍，搞的大家天天抱怨。怎么办，买个大而全的NB 系统？把整个公司都搭进去都不够。回过头来想，还是只好在老系统上做文章。一面安抚众人，一面怒斥搞IT 的：赶紧解决，还想不想要饭碗？搞IT 的苦啊，兄弟。好在现在很多软件卖出去都送源码，不知道为什么要送，反正我没送过，恩，当然我的软件也就没人要了。IT 哥们在代码中发现了解决方法，我在这个系统提交的时候，给另一个系统一份不就行了？用数据集成？饶了IT 兄弟吧，那俩系统里的数据比代码还乱呢，一时半会研究不明白。看到这就哦了，套SOA的官话，那边提供一个服务，这边调用就好了。

暴露服务，最开始的入手点。

从上面这一步开始，逐渐的有更多的服务交叉在各个系统之间。这玩意多了就是烦，IT 大哥最近要辞职，临走之前想做个好事，把之前所有的服务都写了个word 文档。敬业啊！其实，这确实是治理的开始，实现了最基本的服务记录和说明。但是这种方式确实又比较原始，查找起来比较累。过来交接的哥们，看着十几页的文档冷汗都下来了。正好交接有半个月的时间，趁这半个月俩人研究了几天有什么好办法把系统玩转。要说人多就是力量大，俩人找了个开源的服务治理工具，把这些都扔里面了。有了规范的工具，立刻世界变得美妙起来，一切都很方便。而且治理工具还带来了监控服务状态等等等等更多的好处。这就是专业的力量。

服务治理，世界美妙的开始。

然后该干嘛了呢？整个企业的IT 系统里已经有大把大把的服务在那了，企业的规模在也上来了，再上新系统那是大把大把的银子出去了。领导就想啊，我现在在都这么多系统了，能不能利用已经有的东西实现新的需求呢？上个月系统流程觉得还很好，这个月又要改了，能不能不重新做，利用已有的东西改吧改吧就适应新的流程呢？要说搞IT 的就是聪明，很快就找到了解决方案。因为之前服务定义的比较合适，暴露的服务也很充分，这些需求都能够通过重新组织服务来完成。这就是服务编排编制的工作。往大里说，做到后面就是很好的业务流程管理（BPM）。

管理流程，快速响应业务需求。

企业变大了。从IT 系统来说，很多系统，很多有用的服务。这些服务在治理系统里面都有注册，但是却分散在多个独立的系统里，系统之间的连接单拎出来还算清晰，如果画个完整的图，就是可怕的错综复杂的网络。从性能上，从管理上，从多个系统交互上，都有很多问题，真是牵一发动千钧啊。有没有办法把这么多服务整合在一起呢？有的，搞IT 的人真是聪明啊—企业服务总线(ESB)。搞过自动化的对总线太熟了，一块板子，一堆插槽，来个新的东西插上去就OK了。往简单里想，其实ESB 也差不多。当然隐藏在简单表面的背后，还有很多复杂的技术细节。不过没事，聪明的IT 伙计能搞定一切。

服务总线，由繁入简统筹交互。

流程管理和服务总线这两者的引入顺序，可以比较灵活。大致的思路是，如果IT 系统是业务流程为主，那应该优先考虑流程管理；如果IT 系统是消息集成为主，那应该优先考虑服务总线。满足最紧迫的需求是第一位的，给将来打下坚实的基础可以稍微往后靠一点。

现在回头来看整个系统的情况，从技术上来说已经是基本完备的了。但是请注意，SOA 不是一个技术问题，SOA 是搭建IT 系统的方法论问题。就是首要的是对服务的理解，用适当的技术完成服务的暴露，然后通过这些服务响应业务变化，满足应用需求。所以，技术基础具备之后，不应该停滞不前，而应该善用这些工具，按照能快速响应需求变化的方向，去逐步演进IT 系统。用SOA 看问题，不是各个孤立的系统，而是各个有价值的服务的集合。它只是手段，赚钱才是目的。

再进一步会怎么样？SaaS 是个方向，或者再进一步叫她云计算。我见过的最贴切的对云计算的定义是：虚拟存储+SaaS。但是对中小企业来说一下就考虑这么远其实没什么必要。当然这里有个快速的切入点，那就是，如果你有一个对全球人民都很有用的内部服务，那不妨把她放到大庭广众之下，按SaaS的路子暴露出去。

闻名不如见面-南山坡专题技术讨论活动Submitted by 竹十一 on Mon, 01/11/2010 – 15:19闻名不如见面
在QQ群里扯久了，就纷纷有了见面对砍的冲动。我觉着这就和上个世纪末，（说起来很远，其实也就十年），聊天软件刚刚盛行之际纷纷扯“网友见面”差不多。这次应该算是我第三次掺和面对面的群扯活动了。第一次嘛，是十多个帅的和不帅的哥，围坐在避风塘的一个大桌子周围，挤在一个小屋里了。不知道周围那些人，看我们的眼神是什么样子，只是觉得第一次嘛，激动、害羞、向往，诸多感觉纷纷砸向晕乎乎的大脑，人多，屋小，气闷，缺氧。第二次嘛，是美女up 组织的怀柔远足吃鱼。我带着老婆在其他单身帅哥美女嫉妒的眼神中，着实吃了不少鱼。爬红螺寺太累，吃饱了才有力气啊。那是和老婆第一次爬山了，依然回忆幸福中。今次嘛，没有帅哥没有美女了。当年的帅小伙俊姑娘，在打磨技术的同时，也把打扮化妆的时间都扔在了一边。倒是技术上都沉淀的非常夯实。
Alex，对技术对整个市场环境都保持了非常非常高的激情。实在是令我汗颜啊，我已经心态老矣，经常自觉不自觉的得过且过了。这点要经常拿出来检讨一下。轮子同学集成的经验那叫一个丰富，各种项目背景信手拈来，比我纸上谈兵要强过N 倍。UP美女是巾帼不让须眉，RIA 的经验实力，不来几个筋斗云那是甭想有歪心思的。当然，想有歪心思，也得先看看旁边她的御用小奴Rosen，Rosen当年携db4o，席卷诸多技术网站之际，我还在一个角落默默的啃着咖啡豆。满帅依然显得很谦虚，但真的很man，每次发问都问在要穴。Gopher越发彪悍了，一搭眼眼就知道是东北人，一搭手估计就飞出天外了，当然我也没敢搭手。还有一位Gopher的同事，不太熟悉，也显得比较腼腆，不过我相信下次再坐在一块的时候，肯定就能放得开了。
本来这次准备了四个topic，但是一开始大家扯的比较开，再加上轮子严重迟到，鄙视之，结果真正开始topic的时候已经快三点了。我的SOA，基本是纸上谈兵的多，好在轮子和Alex项目经验很丰富，让我的topic 血肉大大丰满了。Alex很实际，着眼现实，对SOA 成功案例有多少的发问，让我做为一个SOA粉丝，着实尴尬了不少。UP美女的RIA，确实让我学习了不少，虽然离UI久矣，但是仍然让我震惊于互联网应用对UI细节的精益求精。轮子的Portal案例共享确实大大丰富了我贫乏的项目经验，希望下次有人再问到项目经验的时候，我可以把学到的东东转述出去。本来Rosen还要分享一下最近他们尝试Scrum 的经验，可惜时间有些晚，只好期待下次了。
基本上来说，这次见面会，算是比较成功，对个人来说也比纯粹的扯淡会更吸引我。以后还要在条件允许的情况下多多搞这样的活动。好消息是满帅说他们那里也可以有会议室用，真好，希望不要想轮子这这么冷。下次大家坐在一起的时候，相信Rosen的Scrum 经验就更丰富了。比较期待他对这个流行的Agile 方法论的看法。
ps:附件是我这次topic 的pptx，本来想要OpenOffice的，结果发现就我用，而且做出来的东西也不漂亮，只好作罢。待我审美提高能做出漂亮东东的时候再用吧。