孙秀楠的网站

博客

  • 丰富多彩的一天

    傍晚，走到家附近卖鱼汤包的店铺就有点拿不动腿了，中午吃得不多，下午消耗太大，看小潘潘发短信来说饿了，我也突然感觉饥肠辘辘，走进去要了碗馄饨边用手机上网边等，还真是饿了，感觉时间那么漫长，百无聊赖中发现了座上的“魔力星座宝贝”，突然就来了兴致，别说，一块钱没白花，讨了个吉运，哈哈。虽然上面只有四项有关运势的，说的却挺准。

                                       *运势：想放轻松，让自己悠哉一下。                               准确  最近的确有点儿疲惫，工作太努力：）

                                        *爱情：何不安排玩乐的节目，有机会遇到艳遇。             胡扯  已婚妇女艳遇就算了

                                        *财运：财运一般，没什么大的开销。                               精辟  除了晚上买菜没有额外花费，吃饭洗澡有人请啦，哈哈

                                        *工作：完全把工作抛诸脑后。                                          神了  压根儿就没干活，相当于翘班一天

    一大早就跑到关系单位报到，简单整理数据后就聊天上网，这所谓的工作真是轻松加愉快啊，哈哈。和小潘潘一起跟着人家去吃川菜，当然也可以说成被请，细节自不必言表，反正席间总总挺搞笑。

    酒足饭饱后跑去高档洗浴中心，美美地洗澡喝茶，因为特殊时期，麦饭石那个屋子俺喜欢，恨不得把自己全埋起来才好。我右边的膝盖受到了我特别优待，谁让它阴天下雨和特别日子之前总是酸溜溜难受，不知往哪里搁呢？小潘潘回去值晚班，我又大大地高兴一把，上次录数据我吭哧瘪度回去的不爽抛诸脑后咧。这一高兴又蒸了会儿，算是彻底透了，出来在大堂坐了半天脸还是红通通的，鼻尖的汗也是渗了一层又一层，担心感冒足足做了一半个小时，又是手机上网偷菜加回复留言。没忘顺手拍了几张照片留着得瑟……

    我这成倒叙还是插叙了，馄饨快吃完时发现邻座八九岁男孩戴着眼镜在昏暗的灯光下看书，职业病犯了，跟他妈妈叨咕了几句近距离用眼和用镜的注意事项，有点儿好为人师了，不知人家是否领情呢，怎么跟小潘潘似的，哎!去菜场买一大堆东西，居然顺手还买了坠子，明儿去配个挂绳，嘻嘻。看着它我就喜欢就想跟着笑……

    人一开心就爱管闲事儿，看见楼梯上一十一二岁的女孩儿哄她两三岁的弟弟，不免怜惜起来，小小儿啼哭不止，鼻涕横流，小归宁手足无措，满头是汗，我弯下腰帮着哄哄，拿出湿巾让小姐姐给弟弟擦鼻涕，小小儿可能对那味道比较满意，止住了哭声，又对我手里大包小卷儿的东西有点儿垂涎，我立刻心领神会，拿了块儿蛋糕给他，姐姐说不好意思，弟弟却笑嘻嘻，在姐姐的要求下，男孩儿说了谢谢，我摆摆手乐颠颠儿往电梯跟前走去，这也算助人为乐吧，哦？

    一人吃饱全家不可能不饿啊，那个赚大钱的还没回来呢，水果是命菜饭也不能少啊，营养餐咱是少不了的。晚上青菜豆腐伺候着，不知人家满意否，瞧我多不容易，还得看人脸色活着，上班得给人家做饭，休息得给人家做饭，出去吃喝玩乐回来还得给人做饭，不管人家都说我贤惠呢，行了，今天得瑟得不轻，记账也没力气了，很久不写估计回头检查又得被批，还是贴照片，收工吧。

     

    P29-06-11_15.37[01]P29-06-11_15.44P29-06-11_20.07P29-06-11_20.08P29-06-11_23.13P29-06-11_23.14

  • Lua编程、弱引用、招DotNet程序员

    Lua社区最近有很多值得关注的新闻，第一条毫无疑问是Lua5.2.0接近release，最新一版Lua 5.2.0 (beta-rc4)（http://www.lua.org/work），按照作者Luiz Henrique de Figueiredo的说法，大概还有一个多月时间就应该能看到release版本了。Lua5.2.0比较值得关注的是增加了一个关键字（goto），可以通过goto实现continue的功能，所以不出意料的依然没有continue，在twitter上云风回复说他统计了一下自己某个代码，里面好像也是continue远远少于goto的使用。另外还是要赞叹Lua作者的牛逼，现在Lua大概还是二十几个关键字，其它语言上百个关键字的伤不起啊！你都记不全！

    另一个新闻是LuaJit也接近release版，现在是2.0.0 Beta8，http://luajit.org/download.html 对于性能追求者来说，LuaJit是一个很好的选择，但是支持平台不够多（比如我的PowerPC啊）。最新一版对于ARM的支持是亮点，啥Android、iPhone的，统统都支持。另外FFI Library也是亮点，这个功能可以极大地提高对C API的开发支持。

    在新浪微博上（我的微博是http://weibo.com/sagasw ）有人问我，学习Lua与C交互，什么项目比较好。下面是我的建议：

    1）主要用Lua，想用C作为模块支持某些特性。如果你想完成类似程序，那么Lua自己的module毫无疑问是最好的学习项目，比如5.2.0中的lbitlib.c、ldblib.c、lstrlib.c、ltablib.c，都是通过Lua API开发出来的。另外比如LuaSocket、LuaFileSystem都是很常用的模块，学学也都不错。

    2）主要用C，想用Lua作为动态支持。如果想达到这个目的，可以参考Programming In Lua（可以在网上免费阅读下载）中的示例。与1）也差不多，基本上都是通过Lua stack来与Lua访问。1）和2）基本上编程方式是共通的。

    另外可以参考这个项目http://labix.org/lunatic-python，可以实现Lua与Python互操作，类似项目还有http://pypi.python.org/pypi/lupa/0.17 

     

    Weak Reference是一个编程领域通用的概念，在http://en.wikipedia.org/wiki/Weak_reference 这里可以看到比较详细的介绍。DotNet中就有WeakReference这个概念，另外Lua有Weak Table概念。弱引用是指在有垃圾收集机制的程序语言中，常规情况下对某个对象的引用都是强引用，比如a=b，a就引用了b，如果b在其它地方不再被使用，但是a依然存在有效，那么b就仍然是可达的（reachable），或者用引用计数这方式来讲，就是reference count仍然大于0。但是这有一点问题，是我以前碰到过的。

    我在某个项目的性能改进中引入了cache机制，有一个全局的对象缓存管理器。我的实现很简单，就是用一个vector保存对象指针，在类析构函数中查找对象缓存管理器，决定是否真正释放对象，还是说仅仅把对象放到管理器中。

    由于代码写得不是很完美，其中有一个问题，就是指针在缓冲管理器中放着，但是实际对象实例已经被释放了。也就是说，为了真正释放对象实例，需要做两步才正确：第一步是查找缓存管理器，查找删掉里面的指针引用，第二步是真正释放对象。

    很麻烦是不是。对于C#这样的没有确定析构时间的编程语言来说，也有类似问题。我们举一个很典型的例子，如下图所示（from http://diditwith.net/2007/03/23/SolvingTheProblemWithEventsWeakEventHandlers.aspx）：

    EventLeak

    可以看到当myForm释放，但是没有移除handler，那么handler指向就有问题。

    强引用的另外一个问题是会影响垃圾收集。比如我前面那个需要，如果把引用存放到某个全局对象管理器，那么GC会认为这个对象是可达的（reachable），没法正确的释放了。

    弱引用就是完成这个目的，一个弱引用对象，可以通过对Target是否为空来判断引用对象是否已经释放，而且不会影响垃圾收集有效性。实现方式（好像是）与我前面提到的也很类似，对象析构时，先从某个全局的弱引用队列中把相关Target删掉，然后再析构（所以弱引用是会影响一点点性能）。

     

    最近在找两个DotNet程序员，最好是有两三年开发经验，如果有WPF/SilverLight经验最好，要求DotNet知识牢固，对编程有兴趣，另外有较强的自学能力，英语能够进行基本对话交流。有意者请发简历到sagasw#gmail.com（替换#哦）。

  • 五月二号的一些照片

    五月二号，我们一家人跑到星海广场去玩，拍了几张照片。

     

    IMG_0225

    IMG_0242

    IMG_0247

    IMG_0283

    IMG_0288

    IMG_0296

  • 我的新技术生活、培训学校及六一儿童节

    第一件事，最重要。

    四月初，我换工作了。离开了工作八年的罗克韦尔，到了另一家单位。生活变得忙碌，但是感觉很充实。

    罗克韦尔这是一家好单位，可惜的是我没有随之一起成长，走了不少弯路。如果能穿越或者回溯，估计很多事情可以做的更好。感想很简单：如果你在某公司，觉得呆着没意思或者不受重视，早点离开为好。另外建议大家多看看《职来职往》这个节目，里面达人提供的经验很宝贵，我后悔没早看到。

    第二件事，关于做人的底线。

    最近在csdn上看到“著名的”传智培训的老师张孝祥替人写技术面试题，以至于都累病了。这件事太让人感动了。一个没有底线，不知什么是对错好坏，逻辑思维混乱，善于偷换概念转移话题的人都可以创业成功，还在微博上受到csdn某大腕的吹捧，那还有什么不能做的？只要敢做，错事都能都敢吹的全世界都知道。最可贵的是，还有很多人鼓吹叫好，为之呐喊助威，所以说现在，成功真的很容易复制，只要你没有底线。

    第三件事，关于孙秀楠。

    六一那天中午给家里打了个电话，萌萌接电话告诉我她在看书。我感觉很难过，六一没法带她出去玩。其实我应该请假领她出去的。好在也没必要后悔，周末好好出去玩玩，补偿她一下。

  • 不同系统（C#/Python/IronPython/Jython/C++)之间的技术整合（续一）

    上一次讨论http://sunxiunan.com/?p=1854 发出去以后提问者回复了一些问题，然后也提出一些新问题，觉得这种总体设计还是挺有趣的，值得发出来一起看看。

        首先说明下为什么会有这样的想法吧—-公司里面有很多不同部门, 部门之间有不同的产品, 对于不同的产品和项目都有着自己的测试方案, 有手工的也有自动化的, 自动化的里面又有使用各种语言的(包括Tcl, Python, Lua等), 即使使用同一种语言, 也有使用各种框架的, 这样就导致了不同产品间很难沟通(最典型的案例就是需要互相借人的时候, 发现要重新学习一套测试方式, 周期太长), 同时也不便于管理. 于是呢, 领导们就突发奇想, 是不是可以统一一种语言和框架呢?为了能满足领导们以及测试部门等各方面的诉求,就有了以上的想法…..

        再来说说我的想法吧. 目前领导要统一已经是一个不可避免的问题了, 因此我非常希望可以引导到Python上面来(其实有些部门是使用Python的), 这里大概和我的个人喜好, 同时我也相信Python可以胜任这种情况. 于是为了证明这个, 所以我就有了以上的尝试. 所有的一切都是为了尽量少改动现有的代码而实现新的统一的目标，想调用Java的原因是有大量的类库目前可以使用，希望调用C/C++的原因是因为其他部门非常有可能需要与硬件相关的C/C++的扩展来实现框架，要尽量满足大家的需求大家才会支持你 。。。。。。

        至于框架方面，说实话，现在Python的测试框架好像还没有特别成熟的，相对来说见得多的是Robot Framework，不过其实我自己的构想是重新创建的一个可以将各个部门完全分离同时又可以分别集群的架构，不过这些都是后话了。

    至于这位仁兄说的这条：

    3）IronPython无法调用C扩展，但是很容易调用C#，可以考虑将其作为C#与CPython的包装层，仅此而已，不要用的太多。
    4）Jython也是一样，仅用于Java与CPython的包装。

    鉴于我才疏学浅，不大理解具体怎么做，因为我的理解是Jython和IronPython都是重新实现的解释器，如何去包装CPython呢？（类似Pyhon For .net的做法？如果是这样的话，这个难度还是相当大的。。。。）

    希望能进一步解释。

    ============================

    我的回答如下：

    包装层（wrapper）是一个抽象概念，有句名言说：编程问题大多数可以通过引入新的抽象来解决（当然，同时也产生新的问题）。

    我们以IronPython和CPython以及现有的C# DotNet程序、C++程序为例来做个探讨好了。在上一次讨论提问者描述以后，我的感觉就是他对性能要求不高，交互紧密性要求不高（也就是未必有IronPython必须不得不直接调用C编写的Python扩展要求），只要把异构系统整合起来能够互相通讯就好。

    整合异构系统，需要分清主次，我这里的设计方案，是以CPython为主，其它编程语言的应用程序或者以DLL形式存在或者被CPython程序调用激活，或者是驻留系统中等待CPython主程序的消息。如果你的方案不是这样，建议你重新考虑一下，没有主次之分的系统设计是有问题的。

    另外看这位提问者的描述，他对于系统之间传递的内容，以及交互的紧密程度，要求不是很高，甚至感觉上就是只要Python能调用一下这些系统就行了。

    这也是设计者需要考虑的，真正需要整合起来做什么，把方案做得细致一些，多考虑一些。

     

    类似这种不同语言的系统进行通讯，基本上有这样几个办法：

    1，基于消息Message Queue通讯

    定义通用格式消息或者使用通用现成格式（比如ProtocolBuffer、Thrift、Json、XML、MsgPack等等），使用跨开发平台通讯方式比如zeromq、http web service进行通讯支持。这是扩展性最好、实现也不麻烦的解决方案，在Python-cn中Zoom.Quiet也提出同一种方案。

    http://en.wikipedia.org/wiki/%C3%98MQ

    http://nichol.as/zeromq-an-introduction

    关于数据序列化比较，可以参考这里

    http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

    另外在Windows下，如果是本机，也可以通过Windows自定义消息在不同系统之间传递。

    Python、IronPython也好，C#也好，或者是C++、Lua、Java，它们都很容易建立Web Server，这种方案可以优先考虑。而且scalablity比较好，容易扩展。

     

    2，基于COM

    这个对开发者要求比较高，另外只能用于IronPython和Python以及C++之间，不能用于Jython和Java。但是如果不需要考虑Java系产品，可以考虑COM，其实COM技术即使在DotNet发展到4.0的现在，依然有强大的生命力。而且开发其实也不难。

     

    3，基于数据库或文件系统传递

    这种方案也是比较通用的，如果你不需要序列化对象，只关心结果（比如数字、字符串、时间等等），这个方案也可以参考。优点是相比第一种，更容易学习使用。可以使用SQLite这样轻量的数据库。

     

    4，基于Python序列化传递对象

    这是针对Python编程语言特定的办法。同时也回答了这个问题：怎么叫用IronPython作CPython和C#之间的包装器？

    如果了解Python，应该知道Python有个序列化方法pickle，可以把对象保存到文件中，以后载入。

    幸运的是，经过我的实验，IronPython2.7支持pickle，与CPython之间通过pickle文件传递对象，那是非常容易。

    也就是说，C#程序运行完毕，或者通过IronPython运行完毕，可以将结果保存到pickle文件中，CPython载入以后继续运行，装得跟直接一样。

    通过我的描述可以看出，IronPython和CPython还是没关联，你是你我是我。这的确没办法，因为它们各自都是完整的系统，设计初衷也没考虑到直接交互，但是IronPython发展前景不错，值得跟进。相比Python.Net而言，我还是建议使用CPython和IronPython。

    iron_cpython

     

    最后要说的是，这种大一统的方案，如果没有强力领导介入和长期支持，基本上不能成功。但这不是技术方案需要考量的。