BeijingOpenParty2009.08溪窗听雨活动总结

发布于九月 11, 2009 十一月 5, 2010 http://www.beijing-open-party.org/?p=510 wp_1 cleverpig 0

秋风起兮白云飞,草木黄落兮雁南归。天气说秋就秋了,在这黄金版的时节,OpenParty2009年8月“溪窗听雨”活动也落下了帷幕。下面让我们以参与者的角度再次回顾一下这个美好的下午吧! 注:没有参加本次活动的朋友可以先预习一下本次活动话题

转载:来自CNBorn的麦克风—OpenParty "溪窗听雨"

CNBorn简介:

英语专业毕业,热爱计算机技术(Ubuntu、Python、自由软件相关)、西方电影(艺术)、DVD、Classical Music。个人博客:http://cnborn.net/blog/

开场白

这次的 OpenParty 上自己听到的话题都是期待已久的,所以对于记录这些话题有着精心的准备,随身携带的记录本基本上留住了绝大多数我想要了解的细节。以下的文章包含了我在敏 捷项目咨询、X-Moto开源游戏以及wxPython编写的个人财务管理软件三个话题中的如实记录,个别部分是当时演讲话题的细节呈现,整体可能略微缺 乏条理,还望大家海涵。如果对于本次OpenParty "溪窗听雨"活动还不甚了解,欢迎您访问本次活动的介绍页面

话题:项目敏捷集成测试

首先听的第一个话题是ThoughtWorks咨询师荣浩带来的一次敏捷的咨询经历。整个话题中牵扯到了一个软件项目开发和管理中的太多方面,同时现场还有不少热心的听众参与讨论,毕竟敏捷是一个十分热门的话题。下面我就根据自己记住的内容分要点罗列一下:

对于项目持续集成的改进:

实施多阶段的持续集成方案,从底层组件起逐步集成,这种方式适合于大型项目,上百人的团队。

对于项目测试的改进:

自动化测试部分,在该咨询项目中,原本几乎没有什么正规的测试流程,TW的咨询师们首先加入功能测试,选用了Selenium作为解决方案。但是有一个 问题是,进行功能测试的部分,应该由谁来撰写?是开发人员?还是测试人员?(在这个咨询案例中,TW认为应该该由开发人员撰写,此问题也引发了在场几位听 众的讨论,最终没有一个压倒性的结果,应该说还是根据项目的需要而有所不同) 通常情况下,自动化的测试流程覆盖了软件测试中的大多数功能,那么测试人员的角色究竟是什么呢?TW的一位测试人员说,通常在测试中会把相关的一个行为 作为一个可以被识别并评估的Story,逐一进行测试。测试人员所做的,应该说是从一个真正软件用户的角度,来使用并尝试发现问题。因为程序各种功能的测 试,可以说只是最核心的功能实现,但是要注意软件最后打交道的是人,一些需要由人在使用中在识别和认知方面引起的偏差和错误,是必须经过实际使用的测试才 能够保证相当高的质量。

程序员管理中暴露的问题:

程序员是否一直很忙?在这个测试项目中,TW咨询师发现,在开始在客户处工作之后,提交代码最多的居然是TW的人员!而通过查询版本库显示,发现这个 100个人的团队中,经常贡献代码的开发人员仅为20个左右,而这些贡献的人的平均代码量仅为10几行/每周!对程序员团队的管理不当,有可能是整个流程 存在的最大的隐患。

最终在这个项目中,应用了如下的解决方案:

  • 实践、分阶段的持续集成
  • 测试(Ant, Selenuim, Badboy)
  • 代码规范检查 StateSVN

ThoughtWorks的工作方式:

  • 结对编程,两个头脑并行工作有利于保证工作的高质量。在场很多同仁也纷纷表示,结对编程带来的好处是效率非常高,虽然在形式上看上去是降低了人员利用率,但实际上通过保证高质量所节约的成本是非常显著的。
  • 迭代、日报(给项目经理以上的领导汇报使用)、ShowCase
  • 站立会议:减少会议时间,绝对不拘泥于形式,注重解决问题。
  • 沟通、沟通、再沟通

ThoughtWorks的敏捷原则:

  • 不为敏捷而敏捷
  • 只有领导支持是不够的
  • 敏捷推进必然有组织结构的改变
敏 捷的目标,不是实施敏捷。一个问题所需要的解决方案从来不是解决方法本身。在推动一个问题解决的过程中,我们脑海中首先要谨记的是,我们的目标究竟是什 么?不为敏捷而敏捷,我们的真正目标是提高效率。而借由这些方法、工具、理念来推动我们工作的过程中,我们原有的一些观点,是要被替换掉的,比如计算程序 员的生产力水平的标尺,就不应该再使用代码行数这样的标准了。TW 举了一个例子,在某个咨询项目的过程中,经过两个月的工作,若说代码行数的变动,实际上是负值,因为整个团队在致力于将原来复杂的八个模块重构和精简为四 个,大大提高了代码的可维护性,但是这样的工作的成效,就不能简单地用代码行数来衡量的。有一个可以值得考虑的标准是价值点的评估,即完成的这些工作,可 以为最终的、客户满意的交付提供多少作用。只要是在朝着面向客户的最终交付这个方向上进行的努力,均可以认为是积极地完成了工作。 可以进 行些梳理的是第三条,敏捷作为一个涵盖企业管理的概念,在很多情况下应用起来都会对组织结构的改变提出要求。但是我们应该怎么去作?如何去推动?上来就大 刀阔斧地推动是完全不切合实际的,这些改变究竟是不是必须的?我们需要有相应的数据来支持。如果你能够有相应的证据可以表明,现有的一些体制,确实制约了 我们在提高效率,和生产力上的努力,那么组织结构上的变化也并不是不可以的。 ThoughtWorks的大牛提到了"响应式设计"这个系 统设计理念对于他个人的一个启示,即当所有的需求和限制摆在你面前时,你又尝试去完全考虑他们,那么此题目必是无解的。敏捷问题也是这样,很多时候的很多 项目,都存在非常多的问题,但是我们始终要明确目标、以及要做的是什么东西,抓住重点来出发解决。错误是允许的,不允许错误就没有成功,

话题:X-Moto游戏

接下来 Vincent Du 介绍的 X-Moto游戏话题。X-Moto 这个游戏是 Elasto Mania 类型的游戏(商业游戏的最新对应是在Xbox 360 Arcade Live上的 Trials HD),玩法很有趣。
这是一个需要很多技巧的游戏,完全免费,开源。游戏画面的感觉,是很有趣的"皮影戏"感觉,尤其是按下空格键控制摩托转向的时候,在场大家都在感叹:"哇,皮影耶"。游戏画面还有一个更加简洁的Ugly版,适用于低配置的机器。这个版本的画面,完全是用线条来表现的 :) 游 戏很细致,我开始一直认为这就是个核心如NES游戏的那种游戏,没想到物理引擎的设计贯穿了整个游戏(虽然物理整个的感觉并不完全要展示显示世界的情况, 如在游戏中为了达到很多特殊效果,引力偏小)。规则的设置也很细致,玩家的角色不能碰触任何物体,而摩托车则可以。游戏有着现代竞速和技巧类的游戏都具备 的元素,录像功能,Ghost鬼影功能,更有一个成熟的网上社区,玩家可以交流游戏技巧,比拼游戏技术(世界排名),单账户的多点信息同步、更可以交流自 制地图。 游戏的地图编辑器技术十分有趣,使用了InkScape 这 款自由的矢量绘图软件,游戏的编辑器功能被设计成了此款软件的一个插件。这是一个巧妙的、典型的自由化设计。试想对于游戏设计者来说,只要开发一个小插 件,就可以拥有一个用户繁多的全功能编辑器可以使用,而对于用户来说,为一个游戏或软件做出些创意性的设计也变得不再复杂,只需使用自己熟悉的编辑工具即 可。

技术的背后:

而在这个游戏背后的技术,有一些也值得一提:SDL 技术几乎已经是跨平台游戏的一种基础技术了,Vincent使用一个实例程序对使用SDL进行了简单的讲解。 ODE(Open Dynamics Engine)是一个开源的物理引擎,不只可以在游戏环境中使用,还可以应用于其它应用领域,如工程模拟等。采用BSD授权。现场展示了一个ODE设计者对于这个引擎的简介slide,有兴趣的朋友可以去看看。有一些商业游戏也使用了ODE引擎,包括 Bloodrayne 2, 还有 Resident Evil: Umbrella Chronicles(来源) 想了解更多关于这个游戏的信息,可以参考这个游戏的网站:X-moto

话题:用wxPython开发并理财

由JiaKuan朋友带来的"用wxPython开发并理财",这个话题本来就是我关注的重点,因为我打算使用wx来开发一些GUI程序,想要学习些技巧。不过最终这个话题带给我的收获远远不限于wxPython技术,而是多方面的收获。

为什么选择wxWidgets

Jiakuan在开发这个软件之前,已经使用Java技术开发了三个版本,但都遇到了效率、可维护性等的问题。决定开始一个更好的版本。 为 什么选择wxWidgets 而不是QT? QT也是不错的选择。进行过简单的比较,感觉wx的原生控件会给用户更好的体验,而且整个库打包起来会比较方便。正是因为存在这些问题,在确定了使用wx 库进行开发之后,所要实现的目标都十分简单,使用wxPython版本要实现的几个目标:10M大小以内的安装包 。

遇到的技术问题和解决方式

接下来JiaKuan分段落讲解了一下整个软件在几个不同部分中遇到的技术问题和解决方式。 程序的国际化部分: 使用了Python的 getText模块PO/MO 国际化部分翻译 应用程序的字符串,使得程序可以支持多种语言。自己写了一个小脚本在每次发布的时候对翻译的字符串文件进行合并,自动处理好之前存在的翻译,这样每次只需处理新的翻译就可以了。 GUI设计: 我 自己(CNBorn)在开始GUI项目的时候,而令我最为头痛的是wxPython的界面设计。我使用过wxGlade来进行设计,但是真是感觉很难用。 虽然去年的Gnome Asia 08峰会上专门有一个话题来帮助大家学习使用Glade,但是时间长了以后,这个软件又变得很难用了。JiaKuan在设计这个软件时,先使用的是 Sizer,后来变成了使用XRC方式进行构建,即先使用程序生成XML代码,然后根据XMl代码来生成wx的窗体代码。wxFormBuilder这个工具使得设计工作更为简单直观。使得设计流程更加快捷。 在界面设计上,JiaKuan使用了一个叫做GUI Design的软件来生成界面原型,十分漂亮,不过显然这个软件是个商业软件。 自动化发布: 使用了PyInstall来生成发布文件夹,这个工具十分方便,可以自动复制相关的依赖库直接到文件夹里。然后在通过脚本调用来生成安装程序。这整个过程完全来通过脚本执行,完全自动(的确是《卓有成效的程序员》所推崇的观点:让计算机来完成重复的工作。) 封装时的脚本做了一个Hack:有打包和生成的过程中,一些地方需要输出日志信息,但是无法同时在屏幕输出,又向日志文件输出,于是就自己写了个函数,来通过另一个线程来判断日志文件的增量,基本达到同步输出。设计时考虑到可能会有效率问题,但是实际使用中发现不明显。 单元测试: 应用了不少的Unittest,主要都集中在程序的核心部分,作为一个需要严谨的技术软件,核心部分的质量必须过硬。一般来讲,先写出单元测试,然后在与其结果进行调试,这种做法符合TDD的要求。单元测试也是逐步增多的。 DB应用及大数据量测试: 很多问题只有在大数据量的时候才能够暴露出来,那么如何进行大数据量测试?大数据量有两个来源,一个是JiaKuan细心记账的几年间积攒的数据,还有就是写了一个机器人,基本根据人们消费、收入的习惯生成了一个7万条左右的数据。 数 据库使用SQLite。基本上,在大数据量的情况下,程序会暴露出问题,如果没有问题,说明测试可能有问题 :) 在 几万条的情况下,有些功能速度明显特别慢。如何优化?优化SQLite,索引的使用很关键,如果你在一个表中建立了多个索引,那么通常其实只有一个索引是 有效的,要注意这点。另一个就是在一个非常复杂的查询语句中,尽量保证所有的Condition都有效地运用到索引,这样可以大幅度提高速度。应用了这些 之后,软件中有一个查询的速度从39秒提高到0.29秒。 程序中实现了一个简单的ORM,这个并不是本意,本来是打算采用SQL语句进行操作,随后在系统逐渐变化的过程中,数据库操作也逐步复杂,在把相关部分的处理重构以提高复用性以后,就成为了一个简单的ORM,传入的是对象,输出的也是对象。 自动生成站点 生成静态文件供用户展示。采用Maven+Python,使用了自己设计的类似模板的技术来生成静态文件。

软件与理财

接着JiaKuan谈了很多和这个软件理念上的东西。如何利用科学的会计管理方法来管理你个人的财务信息。我简单地记录了如下要点: 在个人会计、理财方面,数据记录是为了分析,而分析是为了观察是否在哪里存在问题。如果你希望通过数字来证明自己的生活水平至少是从帐面上看是逐步提高的,那么一个增长的财务分析曲线可以帮助你更清晰地来看到你目前的情况。从报表统计中发现规律,从而发现问题。 不了解会计怎么办?会计是一种规则,不需要什么创造性和灵活性,只要遵循这个规则来操作就可以了,并不是很难掌握。 还不明白软件中与会计术语相关的条目?软件内建的大众模式可以用普通用户很好理解的模式来录入信息,同时软件将数据映射到与理解会计相关知识的用户使用的专业模式一致,最终都可以生成符合会计原理的报表,同时在接触这些报表中,不太理解的用户可以学习其中更多的概念。 关于这个软件的更多信息,欢迎访问官方网站 : 家宽理财

个人体会

关 于每次OpenParty回顾文章规模的问题:我开始使用一个笔记本来记录所有一切我认为值得记录的细节,便于自己回忆和理解。但是写下来之后,发现最终 总结到文章的很多东西都是简单的堆砌。一般来讲,自己选择去听的项目都有着相应的准备和充分的理解,所以即使是细节积累的记录,都是于自己比较有意义的。 但是我不清楚对于一个对此话题不甚理解的读者,这样的意义是否还重要。这样的方式还有一个缺点就是文章会非常地长,文章会长到我的众多朋友实际上都很少看 完我写的整篇文章...... 除此篇幅本身的结构以外,我能想象到的一个形式上的改进就是适当分清主次,着重针对一个话题梳理出脉络,随 后进行延展,而其它的话题则可以忽略掉一些细节,只着力于主题即可。这样也避免了自己对于某些技术了解的不甚深入(譬如本篇的敏捷话题部分,我于此的实际 经验要小于书面上的理解,如果有误欢迎指出),而堆砌细节反而可能弄巧成拙的情况。 自己也考虑在未来多多尝试几种风格,尽量让大家更有效率地获取知识。既不是迷失在字数近乎无限的冗长的细节迷宫中,又不是在精简到渺渺几行的语录体文章中揣摩技术细节的痛苦,这个介于两者之间的程度,我会努力找到更适合的方案。 所以我很希望听听大家的意见,这样的细节大餐或者主次分清的形式你更喜欢哪种?如果有什么更好的建议欢迎提出,谢谢!

转载:“用wxPython开发并理财”话题的演讲者家宽的感受

参后感,这个词好像有点别扭,解释一下就顺了呵呵,意思就是参加这个OpenParty活动之后的感想。

愿与志同道合者谋

BeijingOpenParty每个月举行一次,这似乎非常符合自然规律,月亮都是每个月圆一次,这个周期的设定可以说是完美的。Open Party的组织模式很新颖,鼓励有相关经验的人士分享IT相关话题,参与者也可以是话题的分享者,首先从话题的产生开始就很Open。在活动进行的时 候,每个话题分享者需要用简短的介绍来吸引票数,最后根据投票结果划分场地,高票数的话题有效利用空间大的场地,票数少的话题,志趣相投的朋友们也能凑到 游戏室聊个火热。这个真正的体现了参与者的意愿,让每个参与者能够找到自己真正感兴趣的话题,有机会认识到同个领域的朋友,互相学习和交流。每次活动结束 的时候,都是组织者拿着鞭子赶人,大家才依依不舍的边讨论边向门外移动脚步,可见大家聊的多High,收获不言自明。

“三进宫”与“家宽理财”

昨天也参加了BeijingOpenParty交流活动,是我第三次参加这个活动,前两次都是听众,听多了别人分享,自己嘴也痒痒,所以这次参加的时候我也分享了一个话题:Python的桌面应用——家宽理财(jiakuan.net)。在这个话题中,我从三个方面的分享了这个免费软件的开发经历和心得: 从随便玩一玩到发布一个真正能够用户带来价值的免费软件的历史过程,并且分享了免费软件的模式中难以衡量的个人收获。 Python/wxPython的桌面应用技术细节,分享了Python/wxPython在这个软件的重点应用实例和分析。家宽理财的功能介绍,在这个 环节,我介绍了如何科学的进行个人理财,不少朋友对会计学产生了兴趣,这是一个有意义的事情呵呵。 从我分享的这个话题来说,首先我自己足足过了一把说话的瘾,分享经验和知识本身就是一种享受,在这个话题讨论的过程中我尤其享受了这个过程。在讨论的过程 中,不知不觉发现了大家的新点子,同时不知不觉认识了不少有相同兴趣并且异常优秀的朋友。

亢奋之下的随听

除了我分享的话题之外,我也参与另外两个话题,这两个话题从开始到结束,我都始终处于亢奋状态。 听的第一个是关于敏捷的话题,这个话题的分享者是thoughtworks几位专家,他们结合了一个真实的案例,讲解了一个问题多多的大型开发团队,如何正确应用敏捷的开发模式,逐步提高开发效率的。身临其境,感受良多,尤其现场讨论十分火热。 听的第二个是段练同学讲的关于GWT的话题,这个就更不用说了。从分享者提交这个话题到OpenParty的时候,我就被深深的被吸引了。原因很简单,我 个人和GWT 有着千丝万缕的关系,从1.1版本开始使用,后来也发生过很多和GWT相关的故事,呵呵,可以用“深爱”两个字来形容。所以对于这个话题,当会议室一个人 都没有的时候,我就一个人早早坐进去了,默默的等待话题分享者的来临。话题分享者的讲解给我印象非常深刻,非常全面的分析,尤其是他还仅仅是一个学化学的 实习生,让我很佩服,不过细想也很正常——兴趣是最好的老师,可以看出他很Enjoy,所以很优秀。
好东西总是不能用简单的言语就可以描述得完整,先在此草草停笔,下次有时间再细细分享。OpenParty也在继续前进,我也会继续乘坐这辆D字头的列车,继续和大家一起向前进。

转载:糖醋鼻子的“黑白会”—非黑,即白?溪窗听雨”后记

惊艳!现场有人宣布大婚!

本次最震撼 party 的新闻就是,俺们可耐的鼠标童鞋和他在 openparty 上认识的王菲女士已经顺利领到了小本本啦!看到没,参加咱们 party ,不但能学到东西、认识高手,连老婆都有得得(大家别挤别挤~~),这足以振奋俺们程序员的精神啦!让我们用最真诚的祝福和掌声祝福两位百年好合,一生幸福!

饕餮大餐前的“洗手礼”

接着是我们的topic时间,此次party一个重量级话题是 Ophone 社区带来的Ophone平台和程序开发,确实,大象跺跺脚就能震起点什么来,大手笔,不含糊。虽然扛着相机游走在人群里,但在各位听客讨论的字里行间中,也能感受到这个平台与众 不同的一面,至于细节,期待各位更详细的报道。 之后是连续几次参加我们 party 的来要水大夫,实话说,每次听到来大夫的topic ,都有一种几乎忍不住的冲动,像郭德纲说的那样冲过去喊一声“来大夫!你咋~才!来!尼!!”。身体是革命的本钱,健康对我们来说实在太重要了,多的不 说,就让我们在感谢组织者和来大夫的同时,好好享受每个月一顿的健康餐吧。

AgileChina2009之前的热身

在另一个厅里, thoughtworks 的荣浩继续着持续集成的话题。经过这么长时间的应用和业内交流,我们已经开始使用这种自动化的策略来辅助开发了,但是就跟其它的技术一样,持续集成在日常应用中依然是问题重重。 经常听人说起的就是,对于小团队来说,让自动化环境管理不很频繁的提交是一件非常爽的事情,它给我们带来了合适的节奏。但随着团队中人员的增加,频繁提交、 复杂故障带来的集成混乱和滞后开始困扰着开发者,但是,我们是不是就说持续集成不好或者它阻碍了我们的工作呢?或者说持续集成只适合小团队?答案已经由这 个 topic 回答了:工具永远是工具,人的工作是合适的使用合适的工具。 其实,问题出在我们自己。我们过分依赖了工具,过分依赖了它对提交的管理,当工程的集成过于频繁时,则意味着,我们项目的划分粒度需要做出调整,因为持续集成并不能提供集成频率的智能优化,它仅仅是一个最小粒度的提供者而已。 那这个时候我们就可以采用逐级集成(比如用版本控制的分支管理)的策略,将粒度有机的划分成不同层次,让每一层次存在合适的粒度,代码级别越小,集成粒度越小越频繁。 依然是那句话,工具终究是工具,它在合适的地方的存在才是有意义的,所以,非黑即白的想法是很容易让我们变得懒惰――是真正的懒惰。

余味悠然

接下来的session2 是百度的 cat 为大家带来的 javascript 异步编程。因为对 javascript 高级应用是七窍通了六窍,所以这个话题我只看到了上下翻飞的代码和黑乎乎的底色 … 细节还是由各位专家继续了。
最 后一个是家宽带来的家宽理财,说实话,一个财务软件一直做了多年,用到各种各样的工具,一路走下来的路程也够写一本厚厚的成长记录了。在slide上跟着 家宽一步步走过来,我认识了wxPython,重新认识了自己曾经用过和没用过的各种技术,认识了一个挖井就要挖到白宫的坚定的信徒。嗯,最后只想说一句 话,能够踏踏实实的在一个目标上坚持、进步才 是我们最宝贵的财富。 由于google picasa被关了禁闭,所以照片暂时传到了flickr上,各位慢慢欣赏!

精彩摘抄:来自林健的化学出身的计算机达人

昨天的 BeijingOpenParty上,我听了段炼同学介绍 GWT 的主题。上个月认识他时,我还误以为他是北理工新闻中心专职摄影的段炼老师,但他的真实身份却是华东理工大学制药工程专业的学生,计算机只是其“业余爱好”。段炼的 ID“chemhack”不禁让我猜想他是不是有像刘未鹏的“mindhacks”那样的风范。听了他的演讲、看了他的 blog,发现他确实是一个有 hack 精神的人。

精彩摘抄:来自火种的OpenParty溪窗听雨见闻

第一次参加BejingOpenParty的活动,没想到地方那么好找,到了东直门没费什么劲就找到了。介绍一下会上见闻,顺道贴上几张用手机拍的“印象照”。 GWT 早有接触,一直没去尝试,这位大学没毕业的同学已经是GWT老手,对各类与GWT相关的应用与第三方包,都耳熟能详,开了眼界。GWT就是对于类似 于Gmail、GDocs那样大规模的富网络应用一个工程化的解决方案:写JAVA来代替写JS。我最关心的JAVA编译成JS后的文件体积:一个 helloworld也要上百K,不过一个功能丰富的富应用也才100多K。GWT的功能以及基于GWT的扩展的界面都非常地诱人,只可惜我对JAVA不 太来电。如果只是简单的JS应用,用jquery已经很爽了,如果开发类似于Gmail那样的应用,管理JS无疑是个噩梦,这种情况下用GWT是个很不错 的选择。 校内网的litaocheng(成立涛)带来了couchDB和erlang,这也是我来这里的其中一个目的。前阵子用过一会, 想等1.0版出来后再用用。couchDB方面讲的我基本都了解,就是演讲完后我逮着问了好几个问题,解开了好几个迷惑。这东西很酷,在国外应用很多,但 在国内使用的不多,litaocheng所在的校内网也没有在生产环境过多的使用。如果它再成熟一点,我倒很有兴趣再用一用。

twitter回响收录:

  • @turingbook: 这次 #openparty 上演讲的 @jiakuan 同学用wxPython所做的理财软件看上去不错啊。
  • @jiakuan: #openparty 上分享了一些,有空再整一篇文章出来详细描述一下我的个人理财心得,以抛砖引玉,向各位学习。
  • @CNBorn:我正在进行 #OpenParty 文章记录的工作,报告下进度:目前字数3763,三个话题还只填上了两个话题的内容,完整的语言还没有几句…… 要赶工了。
  • @jiakuan: 我自己是个狂热爱好者,我自己已经有五年的财务数据,数据通用性也不是问题,将会以各种形式导出。手机版没办法,个人业余精力有限,如果有人投资,一定能做出一个优秀的出来呵呵
  • ...

照片聚合:

陶蠡拍摄:http://www.flickr.com/photos/cleverpig/sets/72157622097092931/ 糖醋鼻子拍摄:http://www.flickr.com/photos/41954905@N06/sets/72157622206110814/

现场视频:

正在处理中,敬请期待!

本次活动特别鸣谢

更多活动动态

请随时访问OpenParty活动网站,或者在Twitter.com上搜索关键字#openparty!

BeijingOpenParty2009.08溪窗听雨活动总结的评论

如要发表评论,请先 登录