消失了三天参加了一个北京的技术聚会，是由InfoQ这个网站召开的QCon北京站会议。会议介绍可以看这个链接 http://qconbeijing.com。我很久没有参加这类活动了，总感觉此类型的会议内容会比较泛泛，没有重点或者讲得比较皮毛。这次是因为有很多牛人来京吸引了我，他们不是这么容易见到的。像Spring的作者Rod Johnson是第一次来到中国。另外由于工作的关系，我需要关注最新前沿技术的发展方向以及趋势，出国参加会议可能性价比不高，也太耗时间了，因此这次算是性价比不错的一个会议，所以参加了。
踏踏实实的听了三天的课，居然第三天晚上在写这个总结时，觉得有些累。听课也消耗不少精力呀。
第一天的内容不是太理想，所有人说的东西都比较空，也许老外喜欢讲趋势，但他们也许不知道我们通过互联网也能获得这些趋势。更可恶的Amazon直接就是广告，推广他们的webserivce服务计划。不是说他们的服务不好，而是这就是让我们花钱来听课，还在做广告卖我们东西。我们听广告按说应该有点好处吧，起码给打个折吧，来时后的火车票给报了也行呀。就这样被硬喷了半天，十分无聊。
下午我听的是RIA专场，讨论Flex为主，我所关心的个问题是Flex的程序build后尺寸过大，最后得到一个答案，“如果你认为尺寸很重要的话，就可以暂时不选择Flex”。说了跟没说一样，所以：目前实际在互联网上跑的正式应用还是Flash＋ActionScript最靠谱。
一些Flex开发框架是可以了解一下的，毕竟现在在项目中使用框架可以加快开发的速度
- cairngorm
- pureMVC
- Mate
- Swiz
- Spring ActionScript
第一天就这样结束了，当然晚上的活动也讨论了一些技术趋势，老外云集在台中央坐着，别有一番风景。第一天我还真正的体会到Twitter的强大，体验很重要，终于知道这个东西怎么玩了，终于知道为什么它这么火了。我们一直在使用#QConBeijing这个关键词在twitter上讨论，所以，如果你去http://search.twitter.com搜索这个关键词的话，会找到我们所有有关这次会议的每个人的小广播以及心得。另外也找到一个很好用的在Mac下录音的软件Audio Hijack Pro。这东西支持很多内置效果器和VST插件，基本上是一个专业的录音棚软件了。拿它来录会议，大材小用，委屈它了。
Day 2
第二天可以说是激动人心的一天，也许会议就是这么安排的，第二天的内容很充实也很好听，上午由来自eBay的Randy Shoup讲述了eBay的系统架构中的心酸苦辣，列举了很多原则，遵循这些原则还是能继续优化自己的系统的。也能看到有哪些地方自己还做得不够。不过有个问题没有来得及抓住他问，那就是：应该尽可能的划分系统，但是划分后功能和功能之间的沟通怎么办？不能访问一个页面因为包含了几个功能的聚合，就要在后台分别调用几次程序吧。这个问题我经常遇到，看来只能找找Randy的blog或者给他发email询问了。
下午赞扬最高的是来自豆瓣的洪强宁讲述的豆瓣技术发展历程。内容有点像LiveJournal那个技术发展历程的文章。一步步的从开始到现在讲述了豆瓣发展过程中系统架构遇到的技术问题以及如果解决这些问题。大家可能更爱听这些细节的东西吧，所以都很赞。我可能只是听听，因为很多东西大家使用的都是比较类似的技术，英雄所见略同？我过滤出了一些我没有关注过的关键词，记录下来，稍后一个一个研究一下。
总结豆瓣的发展，很符合中国国情，建议很多的初创公司可以学习，一切都是一步步的扩展，没有很大很过分的规划，不断的通过运营检测到问题来改进系统，把系统看成一个生命体，在生命周期内将它做到最好。也许是最好的对软件开发的一个理解，注意，它是生命，不是一开发完就扔掉的垃圾，所以不要抱有开发完就不用再管升级维护的想法了。持续的升级维护才是生命 周期中的重头戏，只有这样才能更加迎合用户，将认可你的产品的用户留下来，留下来的用户积累多了，才能发挥威力，才能有效益。
另外豆瓣的技术选择也比较踏实，注重使用开源社区的力量并在发现并修复问题的时候将修复结果反馈给社区。以前参加过一些社区活动，参会者迫不及待的想为社区做出一些贡献，这种心情是可以理解的，但是如果你刚接触一个你不太熟悉的东西，还没有把它吃透，也没有用它去做真正的解决方案，我想恐怕很难一下子就找到很好的点来帮助社区产品增加功能或做什么改进。所以我一直建议的是，为社区做贡献会有很多途径和方法，不一定非要是提交代码。翻译文档，推荐更多的人使用这些产品也是对社区的贡献。所以初进一个社区不如选择一些简单的事情来做，循序渐进会好一些。
第二天也见到了一些老朋友，也认识了一些新朋友。这次会议参会的朋友和我的朋友圈重合不多，也许是我那些技术朋友都太忙了，第二天见到的这些也是第二天才到，不过我倒是为他们庆幸，没有接触到第一天的郁闷，看来大家都有先见之明呀。
Day 3
第二天晚上的讨论就有关模式、架构，第三天上午继续讨论了这些问题。第二天晚上走的时候我就在想，大家有必要这么好奇软件如何很规范的做出来嘛？大家都在寻求一些优秀的模式帮助大家的设计，我觉得是不是有点过度了。我还是相信抓住老鼠的是好猫，软件设计如何做重要在于你自己怎么看，只要能达到目标怎么做都行。做得时间长了，自然能总结和理解先人的模式理论。毕竟我们计算业或者互联网业都太年轻了，没有什么历史就没有什么积累，你敢保证最近谈论的事情几年后不被推翻？也许现在不会这么快定型，所以学习“敏捷”嘛，拥抱变化是王道。
高焕堂老师在上午讲的课令我很激动，激动得我录音都出了些问题，后来晚上回到家才发现是我判断出了问题，课是录下来了只是我在检查得时候发现它是在暂停得状态，以为没有录上。太激动了！他提出的很多观点我觉得30岁以下的同学可以暂时不去尝试理解，因为我们讨论的不管是历史也好，软件架构也好都需要一些工作的积淀，工作经历，工作经验，如果没有这些只是干巴巴的让你去理解他讲的东西的话，感触就没有这么深了，甚至会有很多误解。我认同高老师的一个观点：中国软件业不能都扎堆去做应用解决方案，跳出这个圈子还有很多事情可以做，大家分工合作才能把这个产业做大做强。当然这也不能我一个人在这里BB，企业也不是傻子，谁愿意做第一个吃螃蟹的人呢？很难说，所以大家肯定还会再犹豫一段时间或者很长一段时间。不过我认同，我看清了这点，我会尝试走不同的路。
下午周爱民和李伟两位前辈继续高老师的风格从一个高度上讲述了软件架构的一些看法。我还是那个意思，如果听众没有实践经验的话，很难产生共鸣。期间讲到一个细节“不变与多变”，把不变的写成程序，写成框架、superclass，变化的写成接口。其实从我个人的理解上来看，可以这么思考。我们在开发的过程中，其实处理的数据是不断变化的，但流程或者处理过程是不变的，甚至业务没有任何关联的两个事情也许过程是一样的，合理的设计就能重用这个过程。所以遵循这个原则怎么将过程重用才是从面向过程转向面向对象开发的基本，无需考虑模式，纯凭感觉也能推导出很多已有的模式，通过这样的推导你可能更容易，更深刻的理解这些模式，也就不会出现不知如何下手的境界了。
我的风格是喜欢将复杂的事情简单化，上面废话了很多有些东西也许不专业，或者有错误，但我觉得实用就好，毕竟我们所有的研究都是为了解决问题，做出东西。也许这次讲师们都是文化人居多，所以大家都往哲学呀，国学上套，听得大家晕晕乎乎感觉不错，但实际能帮助大家什么呢？不太清楚，为此我列出一些选修任务，如果大家一时性起或者有空研究一下技术之外的东西来提高自己的话，可以参考一下
- 国学还是要了解一些的；我们不能把所有的东西都实践后得出自己的体会、结论，你能活5000年吗？还有上下5000年呢？所以先人的经验总结值得学习，吸取后得到自己的东西会节省很多时间。我们这代人这方面所受的教育很少，几乎为零，应该抓紧时间恶补一下，这些东西老外想学是很难的，他没有那个底蕴。
- 经常看优秀的代码；我一直认为看代码就像作家经常看书一样，代码从技术角度是最直接描述思想的东西，它直接的表达它在做什么，所以与其干巴巴的看抽象的理论、模式，不如从代码中找到一些小技巧，应用到你实际的工作中。久而久之你自然也可以总结出很多模式。这叫浸泡。
- 偶尔停下你手头救火的任务，跳出烦恼的圈子，仔细思考一下，这样无休止的做是对的嘛？是否还有更简单的方法？或者怎么避免重复这样。给自己一个总结或者站在一个更高的高度去想事情，也许结论就变得不一样了。跳到圈子之外了解一些其它的兴趣爱好也是不错的，毕竟这个世界所有的东西都是相通的，行业，圈子只是人为的划分。
- 认识到一个问题不会只有一个答案；我们从小考试就烙下一个特别不好的习惯，大家觉得一个问题只会有一个正确的答案，导致一想到一个解决方案后就拒绝继续想了，也许会有更好的方案。我们个人的理解能力、认知能力只能是趋向于实事而不会等于实事，所以习惯性的问问自己，还有别的方案吗？
此次会议体会就写到这里吧，再写我也可以考虑出本书了 
