无意中在网上搜罗到的这部影片。是日本07年的一部动画片，由同名漫画改编而成。

         日文原名是《ピアノの森》，网上有译作《森林中的钢琴》，很直白，甚觉很平庸的一个名字；我个人还是偏好《钢琴之森》，中文发音和《钢琴之声》同音。正因为是“之森”，才觉影片有了一种神秘之感，邃然就想一解钢琴和森林到底有何关系呢？

         正是带着这个疑问，我认真看完了这部动画片。

         和宫崎骏的动画相比，一样动人心弦，用行话说，也许缺少的只是一份大师的气质吧。从专业角度讲，什么画风，配色等等，对于我这样的门外汉来说，就不敢妄谈了。

         影片的故事平淡但绝不乏味。（我不想多嘴累述故事情节了，卖个关子，留下个小小的遗憾吧）。

         整部影片记忆最深的是三个场景。

         第一个场景是影片开始不久，那一段优美的钢琴配乐，以及那一片浓密而深邃的森林。音乐很是动听，森林更是令人神往。镜头由远而近，慢慢地，慢慢地，在一片稍微空旷的森林之中，安静的摆放着一架黑色且神秘的钢琴，在一缕缕淡淡的阳光的衬托下，像梦一般的甜美安逸,引人入胜。

         第二个场景就是海比赛的那一幕，海用力的甩掉领带，松开鞋带，用食指托起爬到他手上的一只蚂蚁，轻轻的放到了钢琴上，谈谈的一笑，轻轻的说道，一起去森林吧，然后重重的将鞋子抛向了空中，抛去了一切枷锁的束缚，赤着双脚站在地板上，弹奏起了属于自己的音乐来。那一幕，着实令人意外且震惊！想想自己，面对考试，面对生活，我会有如此的胆魄吗?

         第三个场景是海落选后站在雨中的一幕，海得知自己落选后，却没有一丝的失落，他明白，他是因为自己而弹奏钢琴，而非成绩或别人的赞美。场外下起了淋淋的小雨，那雨儿并非在为海伤感，那雨儿是想尽力洗净这尘世的浮华啊！海站立在雨中，伸展开双臂，好舒服啊……希望这种感觉会永远属于海。

         记下了故事中的两段台词。

         一段是雨宫询问母亲海为什么落选时，雨宫母亲回答的一句话：

       “因为像那样不看乐谱自作主张的演奏”。

       一段是海的老师和海的母亲的一段对话：

       “很遗憾但这些都是比赛的限制”

       ……

       “……把海推向更广阔的世界如何？对于他的钢琴来说，日本太狭窄了，所以把他推向世界吧。我会带着海走向更广阔的世界。”

       海在演奏完后获得了全场雷鸣般的掌声，却依旧没能在大赛中获胜晋级。这个世界或许不属于那些抛弃枷锁找寻自我的人，“像那样不看乐谱自作主张的演奏”怎能登上大雅之堂!喜欢音乐的人却买不起钢琴；不喜欢音乐的人却被家人逼着学钢琴，只因他们想。

       雨宫最后也明白了，他完完全全的输给了海，海让他彻底的明白了是要为喜欢钢琴而弹奏钢琴，而不是背负着那么大的包袱，抛去了自我，只是为了成为父母想成为的人而去弹奏钢琴。感谢海，他们依旧是好朋友。

       欣赏一片风景，不在乎看风景的时间，在乎的是看风景的人和看风景的人的心情。时隔2年才看到这部影片，也不觉有遗憾之意。

       按着自己喜欢的方式生活，做着自己喜欢做的事情其实就是一种幸福。依旧很是耐人寻味的一部动画片。

                                                                                                                   oliwen 2009-6-29  凌晨

         这几天都在加班，回到住处时已近10点了。

         小区里有一个圆形的广场，旁边环顾着的是一个小的池塘。以前只是一潭光秃秃的死水，不觉有一点声气，可就前不久，河面上很快就撑起了一片大大小小的荷叶，着实令知情的人觉得不可思议。如今，荷叶丛中已经窜出丰姿招展的粉红色的荷花，安睡在荷叶之上，抢尽了池塘的风光。

         拍拍脑门，恍然大悟，原来已过六月了。

         平日赶着去上班，偶尔只是会环顾一下这满塘的荷花，却从没时间驻足留连品味一番。那天加班回家，拖着疲惫的身躯，本没一点多余的奢求，只想快些回家冲完凉趟在床上舒舒服服咪上一觉。忽然想起早上的那缕遗憾，不知不觉就想着放慢脚步稍稍欣赏一番。

         城里的夜空总也看不到月亮，已经习惯了，就不觉有什么遗憾的了。凝望着这片荷塘夜色，不禁想起朱自清先生那篇柔美如画的散文——《荷塘月色》来，想起了文中的这么一段：

         “这一片天地好象是我的；我也象超出了平常的自己，到了另一个世界里。我爱热闹，也爱冷静；爱群居，也爱独处。象今晚上，一个人在这苍茫的月下， 什么都可以想，什么都可以不想，便觉是个自由的人。白天里一定要做的事，一定要说的话 ，现在都可以不理。这是独处的妙处；我且受用这无边的荷香月色好了。”

       这是独处的妙处，我且受用这无边的荷香夜色好了！全然令我忘却了回家的念头，发觉先前的那个想法竟是那么的幼稚无趣啊。

       走上一座独木桥，不禁驻足停留住了。这是木头做的一座小桥，长2米左右，白日不觉有什么特别，可此时此景，不禁让我心头一颤。情不自禁的静静地闭上了双眼，然后慢慢地低下头，少许，再慢慢地舒展开双眼，千万别去抬头眺望，就这么凝视着这片风景，你想到了什么？

       小桥流水人家，古道西风瘦马

       ……

       诚然，这是城市，但当你再次睁开双眼的时候，你所看到的不再有高楼，你所想到的不再有电脑，眼前有的是一片阿罗多姿的荷花，以及一片碧绿挺直的荷叶。就把那车笛的鸣叫当做蛙鸣吧，把楼宇中窜出的音响声当做蛐蛐的歌唱吧，把路灯的灯光当做萦绕在池塘边的萤火虫发出的光火吧……这里，是一片农田，这是农田旁的一个池塘，我，现在已经靠近了大自然，感受着晚风的抚摸，呼吸着荷花的清香，淡淡的，甜甜的，沁入心脾……

       这是独处的妙处，我且受用这无边的荷香夜色好了！

       不知不觉，竟然洗却了一声的疲劳。

       但人总归还是得回到现实中的。不禁联想到记忆中的这谭死水，如今虽然被这片美丽的荷花遮挡住了它的丑陋，但依旧不会改变我对它根深蒂固的印象。荷花固然美丽清香，但这绝非这谭死水的功劳！

       夜深了，虽然有点依依不舍，但还是得回家休息了，明天还得上班。希望明晚的夜色依旧如此。

                                                                                                             ——oliwen 09.6.22晚

         喜欢孤寂的人喜欢幻想，喜欢幻想的人喜欢文学。

         千万别用计算机中的逻辑去辩证这句话。

         1+1不一定等于2.

         千万别用计算机中的逻辑去辩证这句话。

         因为，它是文学。

         我喜欢文学，但我记不起是从何时起喜欢上的它，正如我记不起自己的第一次恋爱一样，一切都是那么的自然而然，就在那不经意的刹那发生，朦朦胧胧的留下的只是一丝谈谈的印记。

         想想文学，也许是在父亲的影响下喜欢上的读书吧。记忆最深的一本书，是自己收藏至今的一本短篇小说集，算一算，仅自己就已珍藏十多年了。

         记忆中是在父亲的书架上翻阅到的这本书。书是摆放在书架的第一层最靠右边的地方。当时这本书就已经没有了封面，书也已经快翻散了架，从书的侧边栏隐隐约约看清楚书名是叫《笑的文学》，至于是何时出版，父亲何时所买就不得而知了。

        这是我所能回忆起的最早的印记了，也许这就是这段姻缘的开始吧。

         认识文学，也学就是在糊涂吞枣似得翻阅完这本书后开始的吧。书中收录了华盛顿·欧文，欧·亨利，莫泊桑，契诃夫，马克·吐温，辛格，芥川龙之介……等文学大师们的具有代表性的短篇小说。这么多大师，能不让我认识文学吗？

       喜欢文学，也许是在自己梦想成为一位作家时开始的吧。一直以来，我不会觉得孤独，就是因为有它的陪伴。安静的时候就会翻翻书，和它聊聊天；心静的时候，就会写写敲敲和它谈谈心。可现在，我才发觉，我还是错了。也许这么久以来，这都只不过是自己的一厢情愿吧。一直以来，只是想着把它当做自己腾飞的工具而已，却从未真正的去爱过它；一直以为，自己的面具做的很真很真，殊不知竟把自己的眼睛给蒙蔽，一直都是自己在欺骗自己。

功利的思想是跳跃不出动人心弦的文字的。如今，写下这些文字的时候，我才只是浅薄的明白了这段话的含义。相爱的路上，难免有对有错，希望它能够原谅现在明白这些的我。        

下班回家，坐在公交车上，一个人，静静的，又想了许多许多。

                                                                                                          ——oliwen 09.6.22

1。使用 Flex Builder 3.x 分析工具 Profile 
      冰山上的播客 http://xinsync.xju.edu.cn , 原文地址：http://xinsync.xju.edu.cn/index.php/archives/3649

2。Flex应用程序启动详解

     原文地址：http://www.jexchen.com/?p=45

3。Flex Custom Component LifeCycle

     原文地址：http://www.jexchen.com/?p=107

4。FLEX内存优化技巧集合 (2篇)

     原文地址：http://hi.baidu.com/hlxwell/blog/item/84266e90e4b4ef85a977a483.html

     原文地址：http://www.jb51.net/article/13736.htm

         今天杭州下起了小雨，久违的一场雨。

         已经有2个多星期没有更新日志了。一直想写，可一直又没写，心中一直就这么矛盾着。

        17号av米兰输球，提前2轮送国际米兰登上了意甲冠军。18号凌晨国际米兰3：0取胜，用胜利庆祝了第17个意甲冠军。而今年的我，却一直没有激动过。

         今天已经是国际米兰夺冠后的第三天，直到今天也没高兴起来。已经4连冠了，从以前的渴望到现在的习以为常，不知不觉就伴随国际米兰度过了8个年头。现如今还令人惋惜的就只有冠军杯了，今年又是一个铩羽而归，只能期待明年再战了。

         现在的工作激情也似乎消减了不少。富甲西游已经内测了3个多月的时间了，然而效益却令人大失所望。现如今还在不停的修改bug，优化性能。而现在也开始在为以前的匆忙付出代价了，作为一个大型项目，前期就没做什么规划，更别谈什么架构，只为了功能，不断的赶工，导致现在越改越乱，越改也越郁闷......算了吧，就当作一种宝贵的经验财富好好收藏起来吧。现在大家还在为富甲西游努力着，马上要换新的UI了，真情的希望富甲西游能够成功。不想自己完全参与开发的第一款游戏就这么失败了。该打起精神工作了。

         之前项目中做分页显示的时候，为了方便，于是将一个vo 同时存储到了一个字典和一个数组中，用字典存储是方便索引，用数组存储是方便搜索分页数据，因为关联的都是同一个vo 对象，所以改变任何一个存储容器中对应的vo，另一个存储容器中的对应的vo也会改变，之后由于维护数据的疏忽，将一个新new的vo 对象替换了数组中原有的一个vo，而字典对应的vo只做了数值上的更新，实例却没改变，这样就导致数组中和字典中对应的vo数值相同，但对应的实例却不同而无法关联了，后果可想而知，两个存储容器中对应的这个vo就会出现数据不同步的错误了。咳，就这么一个常识问题，还花费了自己一天的时间找原因。

        博客中着笔记下以示提醒。以后再维护两套数据的时候建议封装2个方法，负责存储容器的更新删除，这样以后找问题的原因也好找。

先看下代码：

flash舞台上有一个mc1和一个mc2。

this.stage.addEventListener(MouseEvent.MOUSE_DOWN,mouse_Down);

function mouse_Down(e:Event):void{
 mc2.startDrag(true);//或则写成 mc2.stopDrag();
}

mc1.startDrag(true);

现象： 开始鼠标是拖动mc1的，当按下鼠标后mc2开始拖动，mc1停止了拖动。

想用startDrag()控制2个元件拖动的梦想破灭了，也是一个很简单的细节问题，之前也是一直都没注意到这个问题，富甲由于新加了一个拖动地图的功能导致其它地方的鼠标拖动失效后才发现是这个startDrag方法在作祟。一直闹不明白，既然startDrag方法是movieClip继承而来的，那为什么只能控制一个mc拖动呢？暂时给bug加个引号，勉强作为一个bug以示提醒吧。

2009年4月16日，上海：

　　美国暴雪娱乐公司和网易公司（NASDAQ：NTES）今天宣布，在中国大陆地区《魔兽世界》现有运营权协议到期后，将其独家运营权授予网易旗下关联公司，为期三年.

　　去年夏天，双方业已宣布联手合作暴雪娱乐旗下《魔兽争霸III》、《星际争霸II》和战网游戏平台。今天的声明进一步加强了暴雪娱乐和网易的合作关系，并有利于统一和提升这一合作中暴雪娱乐游戏的质量和服务。

　　暴雪娱乐首席执行官兼联合创始人Mike Morhaime表示，“我们衷心感谢广大中国玩家长年来对我们的热忱支持，也一直和我们的合作伙伴一起，全力保证向他们提供与其他地区一致的高质量的服务和游戏体验。和网易的这一新协议将支持我们未来继续履行对中国玩家的承诺。接下来我们期待着与他们合作推动《魔兽世界》的平稳过渡。”

　　网易首席执行官丁磊表示，“我们很高兴在继《魔兽争霸III》、《星际争霸II》和战网之后，再次与暴雪娱乐合作《魔兽世界》。我相信，暴雪娱乐世界级的游戏开发专长与网易的在线游戏运营优势结合在一起，必将把当今最好的游戏体验带给广大玩家。”

　　有关《魔兽世界》中国大陆地区过渡计划的更多消息，请登陆http://wow.163.com。该网站在接下来的数周月内将随着更多细节的确定不断更新，敬请关注。

以上内容转自http://wow.163.com。虽然早在两个星期前就在公司内部已有耳闻，但当正式看到这个消息的时候还是惊讶了一把，我不是wow的玩家，但我最早玩的一款网游就是"九城"代理的《奇迹》，咳，也没什么可同情九城的，市场竞争，弱肉强食嘛，以前和盛大比拼的公司，现在失去了最大的摇钱树，不知以后会如何。作为一个局外的玩家，就不多啰嗦了。......

         既然能在高楼林立的城市中听到蛙鸣！

         杭州这几天的气温似乎又开始调皮起来，夏天还未到，就开始心急着展示它上乘的内功起来，可能是功力还没到火候，致使天气变得闷沉沉的，闷得人心里只惶惶。

         住的小区旁边就有一条小沟，算了，还是文雅点给点面子称呼成小池塘吧。小池塘不是很宽，只有点点长，河水很浅，但依旧看不到底，打断稍作庆幸下吧，幸亏我还没形容成很脏很脏（-_-就当是我手下留情吧）。前几天，就又开始尝试习惯着熬夜了。夜深了，人静了，夜也静了的时候，没想到人尝试着反常，那些从未发觉过的青蛙也跟着来凑热闹，竟然耐不住寂寞，"呱呱"地叫嚷起来。起初只是隐隐约约，断断续续听到几声蛙鸣，还以为是自己的错觉，后来夜真的很深的时候，成群结队的青蛙一起叫嚣起来，"呱呱地"叫个不停了。这才发觉听到的是真真的蛙鸣！心真的不由得一惊，掐指一算，又听蛙鸣，而这次的"又"似乎是时隔有4年了。

       情不自禁的钩忆起童年的点滴。记忆深处的蛙鸣也只有农村才有。记得小的时候，武汉的夏天很热很热，一直都是这样。那时的用电也比较紧张，gr的村政府为了保证城里的供电，每每到了晚上，没记错的话就是6点左右，就会准时停农村的电。害得我们连动画片都看不成。咳，大人们也都只能嘴上骂骂，我们那群小家伙还敢咋样哩。为了不至于摸黑，家家户户都很早就吃起晚饭，收拾完一切，天黑了，就不约而同地搬个靠凳或是扛张竹床，带把蒲扇，到村里一个比较空旷的地方乘凉，我们小孩子就总跟着凑热闹，大人们在一起夸天（聊天的意思，土话），谈天说地，我们小孩子就在一旁或躲猫猫，或玩老鹰捉小鸡等。农村的房子一般都离田地很近，那时的青蛙也很多很多，多得就像那时天空中的星星一样数也数不清，农村的夜静得很快，只待夜深，一群一群的青蛙，一段接一段的"呱呱"声不绝于耳，偶尔夹杂着几声蛐鸣，偶尔也会飘来大人们时不时发出的哄笑声，自然，纯真......是啊，再伟大的音乐师也无法和大自然相比，在大自然面前，特别是此时此声，再伟大的音乐师也一定会汗颜自愧不如一声。很是庆幸，那时没钱也能参与一场如此美妙的音乐会！正因为有了如此美妙的音乐，大人们在一起聊得如痴如醉，我们这群小孩子纵然玩得一身臭汗，也都未觉得天气的闷和热，时间就这么不知不觉中流逝着。夜真的很深的时候，大人们就开始四处叫唤着自家的孩子回家睡觉了。洗个澡，再躺在床头静静听下蛙鸣，玩累了，不知不觉就很快在这样的催眠曲中进入了梦乡。

        童年永远就像是一场梦境一样。长大出去工作后也就只能过年回趟老家，之后就再也没回农村过个夏天了。不过想想也不会去觉得可惜，现在的农村基本都装上了空调，也很少停电了，再回老家，肯定也找不回童年时候的那份心境了。虽然蛙鸣只是小时生活中的一首插曲而已，如今的这阵阵蛙鸣，也没农村的纯真，只是忽然一阵惊喜，后来的几天，也特别留意过，想用"此时无声胜有声"来感叹一下时又顿觉不妥，心中似乎感觉差了什么作料，也许是少放了点"盐"，也许是忘了放"味精"，至今也未曾有什么新的感触，也许是麻木了吧。但此时的蛙鸣，至少还勾起了自己童年的一段记忆，也算上一功，就此记下吧。

                                                                                                                            oliwen 2009-4-13  凌晨

         富甲西游web版也已经内侧了快一个月了，这段时间bug不断，修修补补虽然未曾停过，但没叫以前那么忙了。开发web网游也快1年了，谈不上什么经验，难的东西写不出来，只能啰嗦点简单的，随便侃侃项目开发中的一些细节问题吧，算是经验分享下。

1.关于配置文件的管理。这里提供2种方法：

   a.硬编码在一个类中，作为静态方法提供。

       优点：效率高。 缺点：更新起来麻烦，修改了配置文件就得重新编译一次项目。

   b.对于配置文件比较多，且修改频繁的项目，就可以采取将所有配置文件打包到一个swf文件中，一个类对应一个

      配置文件，在文档类中提供这些配置类的调用接口，这样初始化的时候也只需加载一个swf文件，且容量比总xml

     文件也小很多，这样也方便以后更新维护了。

      一般项目中都是将两者结合起来用的。这里就只浅尝辄止的提供一点思路而已。

2.关于资源的合理利用。因为现在快被flash的垃圾回收烦透了，所以这里强烈建议项目中的一些资源尽量做到重复

   利用，这里有两个思路。

   a.比如游戏中的道具，基本上都是一张图片，对于那些唯一的组件，比如装备栏，确保只实例化一个，这样就可以

      以一个唯一的窗口作为一个资源池，将加载过的图片保存到一个字典中，当字典中没有对应的图片的时候才加

      载。这样做的优点：1>可以减少和服务器的连接次数节约带宽，2>减少图片的加载，从而尽可能少的降低垃圾

      回收的频率。缺点：这样做的话，内存占用会比较大，这个就可以根据项目的需求来定了，比如道具图片，都比

      较小，基本上可以采用这种方法，提醒一下，数据缓存的清理这个时候就比较重要了。

   b.这个方法就类似于flex中的皮肤处理了。将所有多次重用且容量较小的图片打包到一个swf中，给每个资源图片（

      这里不仅仅包括图片，也可以是一些动画mc等）对应一个链接名，项目中调用的时候，由于映射的是一个Class

      ，所以可以只加载一个资源包，就可以取之不竭的调用对应的资源了，这个方法对于那些矢量动画比较合适。优

     缺点基本同上，补充一个缺点就是这个方法比较的麻烦，资源多的话工作量可能会增加不少。

    当然，采用这两种方法的前提是，当你很在乎内存的占用情况，而且无视垃圾回收时带来的短暂的性能影响（ms

    现在的player10垃圾回收有点点变态),并且确定某些资源清空了引用能够被垃圾回收后就可以ws上面的2个方法。

3.关于代码中注册的事件侦听。这里似乎是在啰嗦了，不过还是多嘴插一句，一定记得要将不用的事件侦听器 

    remove掉，当项目做大的时候，当你烦恼资源没被回收的时候，你再想在海量的代码中来找那些引用没被清掉

    的时候，你就会感受到大海捞针的痛苦了。当然事件侦听器只是引用的一种情况，但这也是只做过小项目后最容

    易被忽视的一个问题了，最后一句话，编程习惯最重要。

4.对于外部加载的swf，场景中有动画的时候，加载进来后播放完毕时一定记得将播放的动画stop掉，flash9导出的

   动画是会自动重复播放的，如果移除的swf动画没被垃圾回收的时候，那些重复播放的动画虽然没在你的眼前跳

   动，但是它却依旧抢占着你的cpu，当你发现显示界面中没有什么动画，也没有什么复杂的逻辑在处理的时候，发

   觉cpu有规律的时高时低的时候，就先想想这种情况吧。我是被这害过一次，以前发现当没做任何计算处理的时候

   cpu竟然会间隔性的跑到30%左右了，之前一直以为是哪些地方写的定时器忘记停掉了，费劲九牛二虎之力后才发

   现竟然是那些存留在内存中的swf动画在搞恶作剧，着实郁闷了一段时间。

    哇，发觉夜很深了，就先唠叨这些吧，都没有什么难点，其实就是项目开发中的一些细节总结而已，个人认为，对于项目中的算法逻辑等，其实理清了思路，查查资料都可以解决掉，决定一个项目开发进度的其实就是那些最容易被忽视的细节问题，而这些就需要经验的不断的积累总结了。但愿我的总结能够给你一些帮助。

1.第一首，肯定是我最喜欢的最终幻想系列了。这里推荐《最终幻想X（10）》主题曲“素敌だね ”；其实个人最喜欢的是《最终幻想8》，只可惜主题曲是王菲唱的英文歌曲《eyes on me》，不过也挺好听的。下面附上歌词：

素敌だね  
艺人:Rikki 
专辑: 
素敌だね               －－最终幻想10主题曲 
风か寄せた言叶に                                        寄语风中 
泳いだ心                                                      游荡的心中 
云が运ぶ明 日に                                          游着云彩的明天 
弹んだ 声                                                    急促的声音 
月が摇れる镜に 震ぇた心                             在月光晃动的镜中有一颗颤栗的心 
星が流れ                                                     流动的繁星 
こぼれた柔らかぃ泪                                      洒落饱含柔情的泪 
素敌だね 多美好 
二人手をとり步けたなら                                如果两人能够携手同行 
行きたぃょ                                                    想和你同行 
キミの街家腕の中                                        携手漫步在你家的街道 
その胸からだあずけ                                     依偎在你的怀中 
宵にまぎれ                                                  恍若夜晚 
梦见る                                                        模糊的梦 
AYUMI HAMASAKI 17TH.2.2002 
风は止まり言叶は                                        风停了 
优しぃ まぷろし                                            温柔的话语 
幻云は破れ                                                在幻云破碎的明天 
明日は远くの声                                           传来遥远的声音 
月がにじむ镜を流れた心                             月光似水的镜中流动的心 
星が摇れてこぼれた                                    闪烁的星星流淌出 
隐せなぃ泪                                                  难以隐藏的泪 
素敌だね                                                    多美好 
二人手をとり步けたなら                               如果两人能够携手同行 
行きたぃょ                                                   想和你同行 
キミの街家腕の中                                       携手漫步在你家的街道 
その胸からだあずけ                                    依偎在你的怀中 
その颜 
そっと触れて                                               轻抚你的面容 
朝に溶れる 
梦见る                                                        仿佛清晨的梦

2.“君が好きだと叫びたい （好像大声说爱你）”这个不用多介绍了吧。热血跟着歌曲一起沸腾吧。

君が好きだと叫びたい
（灌篮高手主题曲）
演唱：B A A D
Mabu xi i heso xi o seri Hashiri dasu machi no naka
眩 し い阳差 し を 背に 走 り 出す 街 の中（顶着耀眼的阳光，我在街头奔跑著）
Tatakareta i cimo no yo u ni kata o
たたかれた い つも の よ うに 肩を（你像平时一样地拍打我的肩头）
Kimi ni muchuu na koto ni wake nan te nai no ni
君 に 梦中 な こと に 理由 なんて ないのに（不知从何时开始，我毫无理由地迷恋上你 ）
Sono ude wa karamu koto wa nai
その 腕 は 络 む こと は ない（你却从来不曾挽上我手臂）
i su no ma ni ka hitomi U ba wa re te haji ma su ta
いつ の 间 に か 瞳夺 わ れ て 始 ま つた（我的眼睛总是追寻着你，离不开你 ）
Hanasa nai Yu ruganai Crazy for you
离 さ ない摇るがない crazy for you（我已经无药可救地crazy for you ）
★Kimi ga suki da to sakebi tai Ashita o ka e te miyo u
★君 が 好き だ と 叫 び にい 明日 を 变 えて みすう（好想大声说爱你，试着去改变明天）
Koo ri su i te ku toki o Bu qi kowa shi tai
冻 り つ いて く 时间を ぶ ち 坏 しにい（打破逐渐冻结的时间）
Kimi ga su ki da to sake bi tai Yuuki de fumida so u
君 が 好 き だ と 叫 び たい 勇气 て 踏み出そう（我好想大声说我喜欢你，鼓起勇气踏出第一步吧!）
Kono asu i omo i o U keto me te ho shi i
この 热 い想 いを受け止 め て ほ しい（希望你能接受我这热切的思念）
Za wa me i ta furoa ni Ni gi wa u teeburu goxi
ぎ わ め い たフロアに に ぎ わ うテ-ブル 越し（越过热闹的桌间，嘎嘎作响的地板）
Nanigenai Kimi no shisen ni yo i shire
なにけない君 の 视 线 に 醉 いしれ（我无意间沈醉在你的眼神里）
Koi o shite i ru yo u de odo rasereteru yo u na
恋 を し て いる よう て 耀 らされてる ような（彷佛正在恋爱一般）
takanaru kodou ni mo u u so wa su ke nai
高鸣 る 鼓动 に もう うそ は つ けない（为你而剧烈跳动的心已不再说谎）
i su ni nareba kawaru Kono modokashii yuujou
いつ に なれぽ 变わる この もどかしい友情（到底要到何时，才能改变这令人不耐烦的朋友关系）
Todoketai Tashikametai I take you away
届 けたい确 かぬたい i take you away（我想得到你，我想确认彼此的心）
Kimi ga suki da to sakebitai Nanimo kamo nugisute
君 が 好き だ と 叫 びたい何 も かも脱ぎ舍て（好想大声说爱你，什么我都不管了）
Kokoro tokasu kotoba o Misuke dashitai
心 どかす 言叶 を 见つけ 出したい（我只想找出能融化你心的话）
Kimi ga suki da to sakebitai Konya wa kaesanai
君 か 好き だ と 叫 ぴたい 今夜 は 归さない（我好想大声说我喜欢你，今天我不回家）
Mi sume ru dake no hibi nan te O wari ni shiyou
见 つめる だけ の 日マ なんて 终わり にしよう（让我们结束仅仅彼此注视的日子吧!）
i wanna cry for you

3. “地球儀” 又一部动画片——《圣斗士-冥王篇》的主题曲。从某种程度上来说，这首主题曲比起动画本生获得了更好的口碑，歌词也写得像诗歌一样。就让这柔美的旋律带我们回归那热血的年代吧……

         其实早在3.9号就开始内侧了。这些时着实有点点累了，n天没更新日子，写点自己的东西了。今天也还是敷衍下吧，做个小小的宣传。

         内侧地址： http://game.163.com/fj

         富甲西游官方地址： http://fj.163.com/index0.html

         富甲西游官方博客： http://blog.163.com/fjxy_admin/?fromgame163

         (貌似现在不能激活账号了。)

       发个游戏截图吧:

游戏大概开发了4个月，由于服务端直接用的是广州那边已经写好的，所以省去了不少开发时间，但同时也额外的增加了不小的工作量，由于开发服务器的同事不在杭州，期间和广州那边的开发人员沟通通讯协议花费了不少时间。游戏一直在赶，似乎一直是在为完成任务一样做这款游戏，功能是模拟客户端版完成了，但架构却一团乱麻，咳，只希望网易以后的项目不要如此盲目了。（ps:仅是个人意见，发下牢骚而已)。不过和olj,zb，还有几位美工,策划一起工作还是挺和睦开心的，呵呵，也算是一种小小的收获吧...^-^

目前游戏也不稳定，网页客户端还是老出错。接下来的工作就是补漏洞，修bug，当篱笆匠了。唯一可以稍稍庆幸下的是，目前不会向前些日子那么赶了，稍稍可以轻松下了。

要想从一名普通程序员发展成为优秀的架构师，“个人特性”与“技术技能”缺一不可；而“技术专业能力”、“人际关系能力”和“业务能力”更是优秀架构师重要的三种能力。

文 / 周爱民（《程序员》2008年4月刊）

引子

究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐忑。

如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。

你能不能做一个好的架构师？

架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。

所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需。架构师这个职务，同时要求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做人、做事，做架构师。

因此“模型”由“个人特性”和“技术技能”两个方面构成，在第一张图中，我特别说明“个人特性”既包括人际关系的能力，也包括（具体）业务能力；“技术技能”也是如此。所以个人特性主要与“做人”有关，部分地也包含“做事”的要素。

                                            图1 架构师能力模型

“有效沟通”以及“学会谈判”与做具体的事无关，是个人能力特性的公共方面。前者是过程，后者是知道如何定目标与求结果。而“风险与防备”是做事过程控制的关键，与前面两项正好构成了一个做事基本能力的完整体系。基本上，这三项个人特性都是一个“普通程序员”所不具备的，甚至在大多数情况下，普通程序员并不愿意去具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟通总是会使事情变得更加麻烦，谈判则徒耗时间而无济于事。然而事实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判。将“架构”变成“决策”的过程，其实就是对各个技术角色（及其思想）兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也需要面对各种投资者（时间、资金、人才等方面的决策者）进行谈判，以确定项目的规模——没有规模也就没有范围，没有范围如何展开设计呢？

一部分开发人员会认为上述过程是“项目经理”的事情，但真的如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策将先于项目的启动，或者说你已经不单单是一个技术角色了。

设计是架构能力的一部分，但架构师不是设计师——看清楚二者之间的不同，你才真正迈出了架构师职业生涯的第一步。

抽象是思维能力、模型化是表达能力

个人特性中另一个非常重要的方面是“抽象思维”，而这是与架构师角色直接相关的一种能力。这种能力既有职业技能特征，又是普遍性的能力。

所谓普遍性的能力，是指“抽象”在我们——作为人这种个体的——生活中无处不在。例如我们说花、草，说桌、椅……我们用语言去指称任何一个既已存在的（可以脱离我们的语言而自然存在的）事物时，就用到了抽象。说“桌子”的时候，既没有描述桌子的具体形式，也没有说明它的规格，但我们用这个名词时，所有人都知道“桌子是什么”。所以，名词概念是整个抽象逻辑系统中的主体。如果失去了这些名词定义，我们基本上不能说话，也不能描述任何东西——那便到了“只可意会不可言传”的境地。

用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达的含义，例如我们说“这个系统设计为一个三层结构”。然而架构师面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必须自已构建一个抽象系统，这就需要概念抽象能力、概念表达能力和基于概念的逻辑表达能力。

概念抽象能力是一种思维能力。简单地说，就是“把目标分解或概括清楚”：你要么概而言之“它是什么”，要么详细地说明“它包括什么”。必须使用大量的语汇来陈述这个“什么”，这不单单是表达为文字，也表达为你在思想过程中的一个完整系统。通常用的方法是“映射系统”。例如你可以用数学中的“数轴”来映射“实数域”。将目标系统形式化为一个概念化的、可讨论的结构系统后，你的抽象过程就基本结束了。

                                            图2 能力模型中的个人特性

然而这个“抽象系统”可能只构建在你的思维意识里，还必须把它描绘出来。因为不能只是你自己思考清楚，系统就能设计完成。这个“描绘”就依赖于后面两种表达能力，一种是描绘概念实体，一种是描绘实体上的逻辑——有趣的是，这似乎又回到了“程序＝结构＋算法”。

现在大家回过头来看看UML，或者更多种类的ML（建模语言），他们就用于表达这两个方面的东西：要么是概念实体（例如用一个框表明系统边界），要么是实体上的逻辑（例如用箭头表明逻辑时序）。

所以大家应该清楚，我们再如何称赞UML，它也只是一种对模型化系统的“表达能力”，你只能把它当一种辅助表达的工具去使用，它本身既不能帮助思考，也不见得能作为抽象过程中的或抽象思维环境中的参考。

任何一个优秀的架构师都有自己独特的思考方式，这决定了他如何抽象系统，以及如何“创造性地”设计与构画这个系统。这种“独特的思考方式”贯彻他从孩童开始的整个成长过程，直至他形成独立的社会观、人生观与世界观。他认识世界的方式和接受世界的能力决定于他如何思考，也反映了他这种思考方式的“独特性”。但这并不表明他有特立独行的行为特性（我们这里只说他的思考方式），我们不应介意他是否用某种语言（例如UML或者形式化编程语言）来表达他的思考结果。

推动：设计做大，实施做小

架构师首先是把问题的真正目标确定下来，然后变成系统设计、平台设计或架构设计。而在此之后设计输出将会有两个方向的发展，一是被忠实地贯彻下来，二是被变形地发展下去。两个方向都存在致命的危险：架构最终能否被完整实现。对前者来说，可能是架构设计过度，或设计本身出现了错误；后者则是对架构直接的伤害。

所以架构师必须参与实施的全程——尤其是在架构被映射为目标系统的前期。在这个阶段中，架构师的任务就是推动架构实施，以保证在项目全程的设计／架构／体系的一致性。除了直接跟设计师或设计团队沟通，以保证他们的设计在你可以控制的范围之内以外，架构师还必须有阶段化设计的能力。这种能力用于将一个原本规模宏大的架构设计，变成较小的、易于实施的、对开发团队来说可控的关键点。例如在体系层次的规划上，设计可能是独立、异质的、可迁移的存储框架来实现数据层，但在（前期的）实施上，这里可能被表达为本地数据库，并要求前端开发人员必须通过一个清晰的数据交互层来访问——例如一组数据存取接口，或一个独立数据服务组件。开发人员可能在这里遇到障碍：因为要通过这些中间层来访问本地数据库，纯粹是多余的。然而，正是这“多余的工作”提供了系统弹性，为并行团队开发公共存储服务争取了周期，也为将来的灵活部署与数据迁移提供了可能。

这里的关键就在于，无论原始系统设定有多大，实施时总是在“做小”。每一个局部的实施块都是可控的，并为它在整个体系空间中留下了位置和接口，这样才可能由“小的部分”做大。一个大系统的架构师可能同时在考虑许多个项目中的、不同位置的架构，并且清楚这些项目最终的总体规模。而这，就是平台架构师和体系架构师所涉的领域。

                                            图3 架构师模型图中的“实现能力”

架构真的是“好不好”的问题吗？如同我对工程的理解一样，架构问题的根本，也并不在于它是否完美或漂亮，而是在于是否合用。因此架构师必须对实施架构的团队以及实施过程有充分了解，知道他们的能力缺陷，知道实现过程要消耗的资源，清楚每个环节可能的故障以及先兆。只有这样，架构师才能设计一个让这个团队能实现，而且在实现过程中能受控的架构。

要知道，你作为架构师被请来，不是画几张图纸交给项目经理，说：你们去做吧，做不出来是你们不会做。即使你可以身体力行，在这个团队中教大家、培养大家，那么公司的开销呢？风险呢？这些东西难道就不考虑了？项目的周期因为实现的复杂程度而无法控制时，项目就死掉了。那么，追根究底来说，是不是架构师的问题？是啊，你为什么会做了一份“不合用”的架构呢？——你都不知道项目如何开发、由谁实施、如何管理等等，又如何能面对这些实际环境去设计架构呢？

所以这一部分能力，是要在你的开发经验、团队经验以及用人识人的经验中去找的。参考模型图的“实现能力”下的“设计能力→了解你的主要沟通对象”和“架构推行”等分支，对你或有一些可用的提示。

局部与全局

架构是一个从全局到局部的过程，而实施正好反过来，是从局部到全局。这也正是“设计做大，实施做小”的另一个层面的含义。设计大才可以见到全局，才知道此全局对彼全局的影响；实施小才可能关注细节，才谈得上品质与控制。

事实上，大多数情况下架构是在为“当前项目之外”去考虑，这可以看成全局关注的一个组成部分。因此我们需要界定所谓“全局”的范围：超出公司或整个产品系列、产品线或规划的范围才是多余的。

所以当架构决策谈及“全局”时，其目标并不见得是“保障当前项目”，而又必须由当前项目去完成。

一个经常被用到的例子是：如果仅为当前项目考虑，那么只需要做成DLL模块；如果为产品线考虑，可能会是“管道＋插件”的结构形式。而“管道＋插件”的形式显然比做成DLL模块更费时，这个时间成本（以及其它成本）就变成了当前项目的无谓开销。

这种全局策略对局部计划的影响是大多数公司不能忍受的，也被很多团队所垢病。然而这却是架构师角色对体系的“近乎必然”的影响——如果你试图在体系中引用架构师这个角色的话。一些情况下，体系能够容纳这种影响，例如“技术架构师”试图推动某种插件框架，而正好开发人员对这项技术感兴趣，那就顺其自然地花点工夫去实现了。但如果不是这样，实施者或实施团队看不到“多余的部分”对他们的价值时，来自局部的抵触就产生了。

这种情况下，平衡这些抵触就成了架构推行的实务之一。在我看来，“平衡”是全局的艺术和局部的技术。也就是说，一方面架构师要学会游说，另一方面也要寻求更为简洁的、成本更小的实现技术。只有当整个体系都意识到（你所推行的）架构的重要性，而且实施成本在他们可以接受的范围之内时，他们才会积极行动起来。

所以所谓平衡，其实也是折衷的过程。构架师只有眼中见大，才知道哪些折衷可以做，而哪些不能。所谓设计评估（模型图中的实现能力->设计能力->设计评估分支）并不是去分析一个设计结果好或不好，而是从中看到原始的需求，看到体系全局的意图，然后知道在将设计变得更为“适当”时可以做哪些折衷。同样的原因，架构师也必须知道自己的决策会产生的影响，才能控制它们，以防它们变成团队的灾难。有些时候，架构师甚至需要抛弃一些特性，以使得项目能够持续下去。因为产品的阶段性产出只是整个战略中的一个环节，而不是全部。

其它

“怎么做一个架构师”这个问题得分成两个部分来看，一个是“做到”，一个是“做好”。由于架构师本身不过是一个技术职位，所以时机成熟了自然会做得到。但问题是，真有一天你被放在这个位置上了，你能做得好吗？

我浏览过几套所谓培训机构的有关架构师的教程，也翻阅过一些讲架构的书。我发现他们普遍地是将架构作为一种“职业技术”来讲，就像培养程序员或者缝纫工一样来教育。但就我的经验来说，架构并不是一件纯粹表现技术能力的工作，所以并不是翻几本书学几种方法就可以投入“实战”的。更深层的问题是，架构师其实不是“战”出来的。昨天跟同事讨论这个话题，他把我们这几年来的一些思考用了三句话来概括，非常精彩：从无到有的，是架构；从表到里的，是抽象；从粗到细的，是设计。

那么到底什么是架构呢？从上面的概括中你是看不到答案的。到底如何做架构呢？从本文中你也是看不到答案的。然而我说，“你看不到答案”的根源其实是在于你的眼光与心性——后面这个词换成现代白话，就是“思想”。真正阻碍了你成为优秀架构师的，也许正是你既有的知识与思想方法，扔掉它们，接受一些全然有别的信息，也许正是良好的开端。

或许你现在正愤愤然：这篇文章怎么空洞无物？——我甚至能想象到一些读者的表情。然而请在问题面前停下来，不要急于给出答案。正如你将“?”稍微变下形，它就成为了“!”一样，问题的本身，就是答案。

作者简介

周爱民（aimingoo），具有十余年的软件开发、项目管理和团队建设的经验，现担任盛大网络的平台架构师，著有《大道至简》、《Delphi源代码分析》等。

原文地址： http://vipnews.csdn.net/newscontent.aspx?pointid=2008_05_30_150239242

         地址： http://www.rongshuxia.com

         记不得多久没上榕树下了，回忆起来估计要追溯到很久很久.....以前了。今天上午不知道是哪根神经痒痒了，忽然又想起曾经的记忆，想起了榕树下。今日一看，果真吓了一跳，没想到这次竟然是耳目全然一新的震撼，看看截图，界面做得还真的挺贴近大自然的，第一感觉就像是喝了一杯清茶，清新无比。

         还是继续支持榕树下吧，毕竟那里曾经也留下过自己文学的梦想。

         今日也快被同事同化了，也开始慢慢迷恋起音乐来，纯粹的音乐，听着听着，心就静了下来，静得真的能让自己忘记一切。同化就同化吧，也挺好的，心静了，或许写出来的文章，彰显的才是真正的自我吧。哈哈.....期待一下属于自己的文字吧。

国际米兰取胜第270次米兰德比！

 (阿德上帝之手，伊布助攻坦克锁定胜局!)

(注：语法as3)

package
{
 import flash.events.TimerEvent;
 import flash.utils.Timer;
 
 /**
  *我相信上帝的存在，是上帝创造了万物
  * */
 public class God
 { 
  private var _timer:Timer;     //上帝是时间的主宰,他控制着时间
  private var _personList:Array;   //上帝创造的人，其实只是上帝的一个个棋子而已
  private var _luck:uint;       //这是个随即数，是上帝的恩赐
  
  public function God(){
   //上帝出现的同时，时间也开始了它永不停息的流逝
   _timer = new Timer(1000);
   _timer.start();
   _timer.addEventListener(TimerEvent.TIMER,timerFun);
  }
  
  /**
   * 世间万物都要由上帝来控制，这个就叫命
   * */
  public function set addPerson(person:Person):void{
   _personList.push(person);
  }
  
  /**
   * 上帝控制着时间
   * */
  private function timerFun(e:TimerEvent):void{
   //上帝控制着时间的同时，也掌握着万物的命运，包括人
   var _person:Person;
   for(var i:uint=0;i< _personList.length;i++){
    //上帝在不断的恩赐机遇给万物，当然有好也有坏
    _luck = Math.random()*10000000000000000000000000000000000000;
    
    _person = _personList[i];
    _person.time = _timer.currentCount;
    _person.lunk = _luck;
   }  
  }
 }
}

package
{
 import flash.utils.Timer;
 
 /**
  * 上帝创造了人
  * */
 public class Person
 {
  protected var _time:uint;
  protected var _luck:uint; //这就是所谓的运气
  protected var _age:uint;
  
  public function Person()
  {
  }
  
  /**
   * 人有了生命后，就要跟着上帝的臣子（时间）不断的变化，永远也逃脱不了这个事实，除非你就是上帝
   * */
  public function set time(value:uint):void{
   _time = value;
   _age++;
  }
  
  /**
   * 其实人生中无时无刻都在得到上帝的恩赐，而这些转瞬急逝的机会要看你能不能把握住了
   * */
  public function set lunk(value:uint):void{
   _luck = value;
  }
  
  /**
   * 人无时无刻都在工作着,这里的工作包括很多很多的事情，有为自己的，有为别人的

   * 有的是被别人所逼，有的是为生活说迫
   * */
  public function doThing(ting:String):String{
   trace("我在做的事情：",ting);
   return thing;
  }
 }
}

package
{
 /**
  * 最先有的是我自己的家
  * */
 public class MyFamily
 {
  private var _granddad:Person; // 有爷爷
  private var _grandma:Person; //奶奶
  private var _father:Person; //有父亲
  private var _mother:Person; //有母亲
  //......还有很多
  
  public function get granddad():void{return _granddad;)
  
  public function get grandma():void{return _grandma;)
  
  public function get father():void{return _father;)
  
  public function get mother():void{return _mother;)
  
  public function MyFamily()
  {
  }
 }
}

package
{
 /**
  * 这就是我
  * */
 public class MySelf extends Person
 {
  /**
   * 我自己的家,在家里我可以听爷爷奶奶讲故事，爸爸可以给我钱买好多自己喜欢的东西......
   * 这里都是我们最亲，最值得信任的人了
   * 当然，不同的人，有不同的家庭，也许，他的家庭是个无法实例化的对象
   * */
  private var _family:MyFamily;
  
  public function MySelf()
  {
   _family = new MyFamily();
  }
  
  /**
   * 人，都逃不开时间的控制，也就是上帝的控制
   * */
  override function set time(value:int):void{
   super.time = value;
   
   //我们都在按照既定的程序生活着
   switch(_age){ //时间，现在代表的是年龄
    case 1: case 2: case 3: case 4:
    case 5:
     doThing("要准备上学学知识了."); //学会了说话，走路，就要开始学习更多有用的知识了
     break
    case 6: //.......
    case 23:
     doThing("读小学");
     doThing("读中学");
     doThing("读高学");
     doThing("读大学"); //这些都是父母预定好的人生路程，他们说这样人才会有用，才可能挣很多很多的money
     break;
    case 24:
    case 25: //......
     
     //现在才是属于我们自己的人生，现在算晚吗？
     //现在我们才能开始很多的if，开始自己选择人生
     if("放弃奋斗"){
      if("普普通通过一生"){
       doThing("结婚算了"); //
      }
      
      if("过得体面一点"){
       doThing("找亲戚.父母借钱贷款买个车，买个房吧"); //
      }
     }else{
      /**
       * 决定先放弃一切，努力工作，虽然努力的结果不肯能让自己成为比尔.盖茨，也不可能成为爱因斯坦,
       * 也许你会得到成功，也许你最终还是失败
       * */
      doThing("努力工作！"); //
      //其实，那么多机会中，如果自己把握住了一个转瞬急逝的机会，可能就能成功
      if(_luck == "成功"){
       trace("end 对于成功的定义人者见人，智者见智，但无论如何，这个是人生最理想的结局。");
      }else{
       trace("end 失败或平庸,但无论结果如何，这一生至少为自己的人生拼搏过，虽然不曾灿烂过，但也曾为之努力过" +
         "其实也不枉此生了！");
      }
     }
     break;
   }
  }
  
 }
}

var god:God = new God();
var myself:MySelf = new MySelf();
god.addPerson(myself);      //人的一生就此开始

人生就是这样一段程序。

在走完既定的程序后，人生无非就是在追寻成功，在找寻幸福。

成功就是得到你所热爱的，幸福就是热爱你所得到的。自己收录的一句话，就用这么一句朴实的话结束此文吧。

后记： 年前回家坐在火车上，百无聊赖中忽然想到的，想了很多很多，可到了真正决心用文字动记录下来的时候，却发现不知从何下笔，之后整理了将近二个星期，才写下上面那点，也算是与职业的结合，一种新的尝试吧。

                                                                                                                             2008-2-15 oliwen

                                                                                            (晚 小雨 明天凌晨米兰德比,祝福国际米兰)

         puremvc的确是个不错的框架，至少比cairngorm用起来简便，官方宣称也是一个跨平台的轻量级框架，除了方便外，个人认为puremvc比cairngorm最大的一个优势可能就是puremvc是通过Mediator（中介类）和Proxy（代理类）完完全全的将视图和逻辑分开了，这一点，个人很是欣赏，视图多了，就会发现维护起来真的很是方便的。有优肯定也有缺，下面主要谈谈自己在使用这个框架中感觉很是不爽的几点：

         1.整个框架是基于观察者模式的，event（事件）在框架中起到的是举足轻重的作用，而令人有点点失望的是这个框架摒弃了as中的Event类，取而代之的是自己实现的Notifier，也许是官方考虑到跨平台移植的缘故吧，但使用起来的确有点点不爽。

         2.看下core包中的类就不难发现，notification和Mediator等既然都是用数组来存取的，这点是最不爽的，完全无视了as中Dictionary的效率，幸好puremvc面向的都是一些中小型的项目，这点在效率上的区别还不能区分开来，但个人认为，这点绝对是puremvc的一个不足之处，一直用的都是官方提供的类包，不知道这点有没高手改过。

         3.个人认为Mediator和Command的作用有点重复，呵呵，这点是和同事讨论是体会出的，两个类的起到的都是一个中间层的作用，在Mediator中一样可以对Proxy的引用，用Command的作用可能就是方便以后的重用吧，个人认为考虑到方法的重用的话，麻烦点写个Command还是不错的，但是有些情况直接在Mediator中对Proxy的引用操作数据其实也不会破坏整个框架，这点就看自己把握了。

          以上就是自己的几点理解，至于这个框架的使用方法，有很多高手都写过教程，自己就不多啰嗦了，个人认为中小项目用puremvc还是一个很不错的选择，包括游戏，如策略类的网游。话又扯回来了，做游戏的话最好不要死套框架，框架只是提供一个定义号的规范，方便团队合作开发，但是该变通的地方还是要变通下的。

        就写这么多吧，有不足的地方欢迎高手拍砖，留言一起讨论。

一.配置。

   1. 下载eclipse     版本：我用的是：3.4.0 中文

   2. 下载最新的python3.0 安装包并安装。这个过程很简单，不多说。

       下载地址：http://www.skycn.com/soft/5251.html

   3. 安装 PyDev   插件地址：http://pydev.sf.net/updates/ 插件安装方式就不啰嗦了。

   4. 安装成功之后打开参数设置面板，如图：

安装成功后会看到pydev选项. 选择 interpreter -Python, 最上面一栏选择 新建(W)  找到python3.0的安装目录，选择python.exe。一切配置成功后的截图如下：

ok~~~~完成到这一步就可以新建python工程，开始写python啦~~~~~^_^~~~~~第一次写这样的教程，讲解得应该还算清晰吧~~~~~~~~

python是个好东西，还在学习中...............哈哈~~~~~~~好好学习，天天向上！