Results tagged “OpenParty”

OpenParty "荷风清韵"

By CNBorn on June 30, 2010 4:42 AM
本次OpenParty "荷风清韵"活动的话题展现出强烈的多元化色彩，涵盖了从软件助力天文学研究、社群活动、读书分享乃至笑来老师带来的时间管理话题，到类似Nginx脚本编程等前沿IT话题，难免让在场的朋友应接不暇。按照惯例将自己现场收听的三个话题做一下简单整理。

量天－软件工程如何助力天文宇宙学研究

由冬清带来的，介绍天文领域软件开发项目的介绍，让在场的各位科学爱好者大开眼界。

冬清所在的公司Gsegment作为地面应用软件开发团队，参与了目前世界上最大的空间望远镜赫歇尔卫星空间项目。 在工作中，也认识到现在我国的航天工程力量明显不如欧洲航天局/NASA等组织，所以Gsegment为团队订下了长远的目的和理想：致力于通过工程来促进科学，提高我国工程能力。

Herschel计划是Horizon 2000计划的4个Corner Stone的其中之一，包含卫星在内的整个计划从决策到交付历经10年，观测卫星于09年5月14日发射，可保障使用期3年。如果把成本均摊到使用期，相当于每天开销百万欧元。Herschel天文台是红外亚毫米波天文台，在这个波段可看到宇宙早期的情况，同时由于波长长，在大气内难以观察，才有对应的卫星观测项目。天文台的观测仪器囊括了光学观测、谱分析等多种功能，可以用来在外星球寻找水。软件中重要的部分，HCSS Hershel 通用科学系统，开发历时十年，三百万行代码，20名开发人员使用Java开发而成。天文信息需要大量分析，卫星信号首先进入科学中心，然后通过由科学家编写的系统化产品生成脚本(Pipeline)，最终产生可供分析和研究的数据。

现场还讲解了很多天文学的概念和知识，遗憾的是限于自己的知识水平有限，无法向大家做更完善的讲述了。

接下来Gsegment团队将要参与中法合作的SVOM项目，这个项目中将包括中国第一颗空间天文探测卫星。期待着他们能够帮助我们的空间科研事业更上一个台阶！另外在现场冬清还为大家演示了地面站软件开发（数据收集分析）部分的集成开发环境，同时Gsegment也在招聘技术人员，欢迎有Python或Java编程经验的，想要致力于尖端工程科研方向的朋友请与他们取得联系。


奇遇花园与社群活动：猴子屁股与社群多样性

由奇遇花园的老板詹膑带来的话题，这个话题恰恰不像他自谦的是"广告"，而从社群的概念这个角度入手，给大家讲述了社群理念，并从中建立联系、组织和活动的一些基本原则。

茫茫人海中，每个人都是独一无二的。社群多样性有助于解决社会问题。想对社群研究有深入浅出的理解，詹老师推荐《人类动物园》这本书。为什么会有新社群？旧有的社群在瓦解：班级、单位等，新的社群正在通过崭新的渠道产生，同时由于种种原因，这种讨论在学术范畴所进行的可能逐步减小。而将社群活动的理念推广，并做出有价值的活动，无疑是推动社会进步的一种良好方式。

我个人认为这个话题为在各种社区努力的组织者、参与者从概念上了解社群氛围与活动作出了很大贡献。同时奇遇花园在8月份还迎来了为众多社区提供服务的店庆开放月，这种对社区的贡献值得赞扬，欢迎大家给予更多的关注。


Nginx 脚本编程

由淘宝的 agentzh 大侠带来的Nginx脚本编程话题，由于其角度的新颖和前沿性，成为了本次活动的一个重量级话题。

Agentzh从去年9月开始研究Nginx源码，其中Nginx中高性能的实现也为阅读带来了很多障碍。遇到困难的地方就使用抄写的手法，白天抄写，在晚上一个人冥想。在研究和学习期间得出这样一个结论：Nginx远不是http server，这个软件的野心要远远超过大多数人对它的理解。

冥想和研究的最初结果就是独自开发的Nginx Echo模块，在Nginx的配置文件中实现了echo, sleep, time等功能。目前是为Nginx开发模块的开发者通常都会参考的一个典型范例。（此项目的文档之详细及深入，实在值得绝大多数的中国开源软件开发者学习)

Nginx 的核心代码大约 10W 行，就其来说，已经是很紧凑的规模了，相比之下，Apache的核心代码大约有 30W 行。而Agentzh所在的团队针对Nginx所写的的扩展的规模，都已经有3W行了。

Apache的多线程模型中，每个线程I/O阻塞，使用多线程拼并发。Nginx不支持多线程，而是使用多个进程来对应CPU 核数，从而提升在多核CPU下的性能。

而为Nginx开发子模块时需要注意的关键问题也是实现非阻塞I/O。因为实现高性能的前提，就是在处理的各个流程部分实现I/O非阻塞，如果仅仅是Nginx本身实现了I/O非阻塞，而处理的子模块却无法实现，那么整个性能的优化就变得没有意义了。

前面抛砖引玉的部分结束，接着从echo模块开始，agentzh将自己开发的众多Nginx模块逐个进行了介绍，通过在nginx.conf文件中应用这些模块，实际上就基本构成了单独使用Nginx来进行高效率非阻塞I/O服务器端开发的前提。我在这里也凭借记录将这些模块在这里简单罗列一下，具体的详情和范例可以参见 agentzh 的幻灯片：Slide1, Slide2

if statement的实现  - (ngx_dev_kit, set-misc-nginx-module)模块

array的实现 - (array-var-nginx-module)模块

子请求，一个请求中执行其它请求，可以提高服务器的并发度，提高平均相应时间，但是注意同时也增大了服务器的压力。子请求的具体应用实例：前端通过多个子请求的方式来异步获得处理结果，然后Nginx可以把结果合并并展示（比如合并成为JSON 用于AJAX)。

用C重写的Non-blocking memcached 模块 - (memc-nginx-module)，可以实现在nginx.conf中直接用非阻塞方式操作memcached

用error_page 这个命令来实现等同于程序语言中try/catch的语句

memcached 连接池 - (ngx_http_upsteram_keepalive)  来实现连接池

使用非阻塞方式来访问 MySQL - (drizzle-nginx-module, rds-json-nginx-module)

这里有个问题，就是通常使用的libmysql是I/O阻塞的，如果在这个应用场景中使用这个库则无法发挥Nginx的高效率。在这里使用了Drizzle模块中的driver可以实现非阻塞IO访问mysql, sqlite3

rds-json-nginx-module模块负责将数据库查询的结果以json格式提供输出

使用Nginx来操作memcache及MySQL所带来的一些性能优势：

  • 单机几千QPS常见，千兆网卡跑满！
  • (个别应用场景) MEMCACHED 不使用连接池 2W QPS，使用后14W QPS
  • Qunar网站上面的一个Ajax应用案例实测，单机7k-8k QPS
  • 比较Java+Tomcat平台与单纯使用Nginx来实现的相关性能对比 - Java: 50~60 QPS;  Nginx: 700~800 QPS

Nginx直接接受表单提交的信息 - (ngx_form_input模块)

Nginx非阻塞直接操作Postgre数据库 - (ng_postgre模块)， 得益于libpq API对于非阻塞的实现

srcache模块 - (srcache-nginx-module) 用来对页面和数据结果进行缓存(和前面提到的memc模块有区别，这里的sr表示SubRequest)

在Nginx配置文件中嵌入Lua脚本 - (lua-nginx-module)  很快Nginx的Lua子模块中就可以使用非阻塞IO的方式来调用Nginx的子请求了

现场讲述的一个Nginx-Lua应用实例：单纯用Nginx来实现数据库集群中用户Hash的计算

所提到的应用方式已经在淘宝量子统计以及Qunar中实际应用。

(Jul 10, 2010 更新：细节修改，感谢 agentzh 及 vipcalio 的指正)

本次活动在技术上涉及的方面很多，限于个人知识水平的限制，记录如在某些方面有什么偏差和不足，欢迎大家指正。想要了解活动详情以及本次活动其它话题的朋友，可以在此查看"荷风清韵"活动的所有话题情况。同时也请关注OpenParty网站对于此次活动的总结。

OpenParty "柳燕隙阳"

By CNBorn on May 31, 2010 3:00 AM
"柳燕隙阳"活动再度发挥去年小"QCon"的传统，请来了豆瓣的洪强宁大侠为大家讲解 Python于Web 2.0网站的应用 这个Python布道型话题。同时依旧云集了诸如：开源软件定制开发中的软件工程、持续集成最后一公里、Go语言介绍、多乐趣介绍、另一种旅行的可能----我的公益生活索引等等诸多精彩话题。简要记述下自己参与的两个话题： Python 在Web 2.0网站的应用 以及 另一种旅行的可能----我的公益生活索引 简要的记录和理解。


Python 在Web 2.0网站的应用

洪大侠有些遗憾在QCon上面由于时间的限制没能将后面Python实际应用部分的例子讲解透彻。所以这次略微简化了些前面的介绍部分，直接引入那些讲述了Python语言最优秀部分的特性是如何在实战中得到应用的。不过需要注意的是，如果是对于这些特性没有简单了解的Python初学者，欣赏这部分的乐趣依然存在但是可能会降低。而鉴于洪教授的Slides上，这部分没有什么详尽的文字说明，所以自己的记录旨在能够帮助大家作为学习Slides部分的一些简单提示。欢迎大家与Slides 一起来配合学习。

Python的介绍

  • 目标：提高开发效率，降低开发成本
  • 代码比例：Slides中给出的比例描述的是豆瓣所有项目中的比例，如果只计算网站前端部分的话，那么Python的比例大概有70%多。

为什么使用Python?

  • 简单易学、开发迅速、易于协作。着重说了第三点"易于协作"。因为如果单独就开发效率来讲Perl的效率也很高，但是Python语言的特性可以避免强烈的个人风格，从而更适合团队开发。
  • 部署方便：三条语句完成上线功能
  • 适用面广：前台后台各种应用
  • 资源丰富：内置电池，应有尽有的库可以选择

概述一下讲解的Python的一些优点以及相应的库或工具

  • 简单的Web开发代码展示 － Douban后台的WebService都是用Web.py开发的
  • 使用更新颖的Flask框架，代码写起来甚至比Web.py更简单
  • Python开发Web简单得益于WSGI，该标准将一个请求分解为不同的中间件来进行处理。当然造成Python Web Framework 众多的原因也是因为这个。
  • nose - 使单元测试变得简单
  • numpy － 用于数据分析
  • iPython － 好用的命令界面扩展，幻灯中演示了直接在iPython中通过数据来绘图
  • virtualenv － 方便部署和建立一个干净的Python环境
  • Python的速度不快，基本和Perl一个量级 －用C扩展：Douban用的多的是PyRex/Cython，用类似于Python的语法去写C的扩展
  • 哲学上和其他语言的差异：做一件事情只有一种方法(Py) vs 做一件事情可以有多种方法(Perl)
  • Pythonic －http://bit.ly/pyzencn

利用Python的语言特性简化开发

案例零：本机和线上配置的不同，如何方便解决
  • 使用.py文件作为配置文件，在使用时将该文件 import 进入程序。

案例一：网站页面权限控制的 Pythonic解决方案
  • 使用Decorator把权限处理的代码部分抽象出来
  • Decorator和四人帮中的描述的装饰器模式并不完全对等
  • Py中的函数可以当作对象使用
  • 使用__call__来简化代码

案例二：从队列中提取信息调用相应的函数
  • 原始的代码设计需要在代码中放入大段的If.Else来进行处理
  • 被装饰的函数，先换个名字
  • 将函数序列化后存入队列中，Work通过名称找到相应的模块和函数执行
  • 现场观众提出的问题是，在get_attr这部分的性能损耗如何？答：可以忽略，Python内部有对这方面的考虑
  • 在生产环境中，豆瓣使用RabbitMQ作为队列系统

案例三：Memcache
  • 用的是Python-libmemcached (由豆瓣开源的），在这个页面 http://code.google.com/p/memcached/wiki/Clients#Python 可以查到不同库的比较。
  • 变化的key使用decorator如何处理？
  • 传进去一个可以解释的表达式
  • 使用inspect.getargspec
  • get_key 这个返回值，是一个函数，产生memcache的key时使用的
  • hint 中说的是生成KEY的方式：如果你有更好的方式，欢迎发给Douban，这个会为应聘豆瓣加很多分值

案例四：使用迭代器减少不必要的性能开销
  • iterator和generator
  • itertools 供迭代器所使用的库
  • 通过迭代器来减少遍历时数据库访问产生的性能开销
  • imerge把一组迭代器按照顺序进行排序（不在标准库中）
  • generator是简化代码的利器

案例五：序列化操作时间优化，元类操作
  • 简单对象，需要处理的量太大（豆瓣的收藏对象）反序列化的速度太慢，造成瓶颈
  • CPickle vs Marshal 性能对比，Marshal的性能大约提升7倍，同时空间还有43%的节省
  • Marshal只能处理内部类型，怎么才能使用其来处理Python中的自定义对象呢？
  • 从Python 2.6中增加的namedtuple得到启发，使用类似的方法来完成这个工作
  • 首先要明确Python中类的观念，类也是从元类派生出来的
  • 使用元类，在实例化这个类的过程中进行一个序列化该对象信息的操作，而这部分可以很方便地被Marshal所使用
  • 需要注意的是：Meta操作如果处理不当，容易被滥用，从而导致很多可维护性上的问题。推荐只将其用于框架类的实现上，而避免在应用层运用此类实现。

案例六：Descriptor的简单讲解
  • 使用Descriptor
  • 将对应变量名称作为类中的属性

案例七：让urllib库实现通过代理翻 墙

Python的一些实现：
  • Stackless Python：微线程，类似Erlang，高效并行
  • IronPython, PyPy：据说效率都已经超过CPython 了

Q&A环节：
  • 关于框架的选择问题：历史原因，如果现在从头开发新的网站，使用现代化框架
  • 变量命名规范：遵守 PEP8 规范，尽管不是必须
  • BeansDB应用于：图片、MP3、大文本字段


"寻找失落的螺丝钉"

由自然之友的张文桦带来的，讲述了她多年以来参与公益项目及活动的一些经历，让人受益匪浅。

无意中踏入公益，听说有学姐在做黑熊保护这类的公益工作，很是羡慕。于是她自己的第一份工作，就是从NGO开始的。

讲解了"生态工作假期"这种独特的旅游类型。这种活动形式旨在让出门旅游的游客利用假期中的一部分时间，作为志愿者参与到当地社区的一些生态计划当中。当然，整个计划也为旅行者进行了比较周全的计划：选取风景优美的地点，毕竟前来的游客的首要目的还是旅游，为旅游者为游客创造优美、适宜的环境，还是必须的。

这种活动形式在台湾已经有了一定的规模，在当地社区的参与下，选取符合上述条件的，需要劳力（志愿者的投入）的项目来开展此项计划。

参与完成了：
  • 台湾阳明山外来种清除计划
  • 花莲南华街区旧烟楼修复

不过生态工作假期这种形成花费较高，适合中产阶层。尽管这种旅游公益的形式在自己身边还处于闻所未闻的状态，但是看看台湾相关组织和民众能够达到的高度，无疑能够给我们更多启示。

另一种方式是参与"静会"这种项目，通常是处于某种目的的公益项目（如宣扬和保存原住民文化），需要来访者用专业知识进行相关的项目工作。但是此项目无须收取费用，适合囊中羞涩的公益旅行爱好者。

当时文桦参与的是原住民文化馆：原住民做的文化小铺项目。有很多这样的项目是由台湾的一些有心做此项事业的中产阶层推动的。志愿参与者们问一个NGO的活动主办者："你们做这个事情有意义吗？" 对方的回答是："这个问题被无数人问了八年，具体的答案我们不清楚，只不过，八年以后的现在，我们还在做这件事。" 我想这才是意义所在。

文桦后来又讲述了在美国的圣路易社区参与的服务计划。

计划开始的前三天，组织者给大家时间来融入和了解社区：第一天学习使用$1来买一件东西，旨在通过买东西这个活动与当地人产生更多的交流和理解。第二天在当地人家吃午饭，了解到当地人居住的房子也都是先前志愿者计划帮助的。

第三天开始正式的工作：在工厂搬废钢铁和废家具。由于工作内容实际上是需要相当强健的体格才能完成的体力工作，文桦因为各种原因不能做到和其他人一样好而沮丧。而这时团队中一个瘦小的女孩Sarsh讲述了她在宏都拉斯进行志愿工作中类似的经历，身体并不强健的她要去铲土，从而心里对自己产生了怀疑：如果不能胜任这份工作，那么自己为什么要付出那么多的辛苦来做呢？自己继续做下去还有什么意义呢？后来自己想通了："为当地人提供更多是心理上的支持，让当地人感觉有其它人关心和参与"。至于自己可以做多少工作，不要勉强，因为会有其它志愿者来帮忙完成。我认为这也是我们参与许多志愿类工作的时候，所应该享有的一种心态。

当地因为就业率低，当地人在开始时不理解这样一个志愿工作的组织。但后来了解了情况，看到情景以后就有了很大的变化，也都积极热心地投入到社区的建设中来。

以上是我根据当时记录下的零散笔记所整理的，文桦自己有一篇更详细的文章记录了在圣路易的经历，欢迎大家查看：http://whitewoods.blog.sohu.com/151525631.html

最后讲到参与望安岛上面的生态旅游计划，整个计划是社会企业类型。由志愿者们推动的生态旅游计划，试图为岛上的生态建设及环境保护提供帮助。文桦最后展示给大家的照片，无疑为人们投入生态项目而努力的原因做了最好的概括：自然可以包容一切，人们将废旧的玻璃瓶作为垃圾丢在海里，而大海返还给我们的，却是冲刷得光滑完整，无比美丽的玻璃片。


自己能够记录和参与的活动必然有限，想要了解活动详情的朋友，可以在此查看"柳燕隙阳"活动的所有话题情况。同时也请关注OpenParty网站对于此次活动的总结。

本期活动筹备，进行的同时，由OpenParty Developer开发团队发起的OpenParty新网站项目也正式开始了线上运转。这个项目设计的初衷是将OpenParty活动中一些必要的部分都放在网站上来进行（如话题提交、活动报名等），目前虽然已经上线运行，但是还处于非常初期的阶段，未来我们还会进一步把一些计划和设想融入其中，欢迎大家提出宝贵意见。本项目为遵循GPLv3协议的开源软件，项目位于 http://code.google.com/p/openparty，欢迎大家关注，并且我们非常期待有时间、有兴趣的朋友能够参与到 OpenParty 开发者的团队当中来，感兴趣的朋友，可以发送邮件到 dev [at] beijing-open-party.org 与我们联系。

OpenParty "熙春暖意"

By CNBorn on March 31, 2010 11:21 PM
"熙春暖意"是农历新年后的第一期OpenParty活动。当天北京的天气虽不像活动的标题一样美丽----迎接我们的是一个寒意依旧，沙尘满天的日子，不过这不能阻挡众多热爱分享和交流的朋友的脚步。此次活动话题众多，还有一位前辈史无前例地贡献了一连三场话题，实在佩服。参与人数再度达到百人，现场到处都可以看到三两一组对技术/文化/其它各种各样话题进行交流的人，气场还是那么足。

还是简要叙述下自己参与的三个话题：

UI/UE设计讨论

这个是个现场讨论的话题，在话题组织者的带领下，大家针对UI/UE设计领域的问题各抒己见，自己在不少方面也有了更新的了解。限于讨论性话题的分散性，在这里仅简单记录下印象比较深刻的观点。

话题组织者引导大家做了这样一个用户体验试验：请一位用户扮作盲人，另一位用户帮助他读出鼠标所指处的文字来引导'盲人'用户完成某一个特定的任务。在这个看似简单的实验里，却能发现很多平常难以窥见的细节，如屏幕阅读会读出很多不需要的东西，从而给用户造成困惑等。事实上这个实验也是行业中的实际案例，在国外的某个网站项目中，有盲人用户致电客服，提出了很多实用性上的问题。其实不只是针对盲人，一个文字冗余、不直观、不对用户友好的界面设计，也是用户体验产品的直接障碍。
抓住用户目标性和随意性浏览的特点，达到用户和网站需求的平衡
通过调查、用户测试、观察、客观反馈、访问数据等方式进行用户的研究，"提升正面反馈，消除负面反馈"。
用户体验的度量。

现场参与的朋友也谈到了很多：

新版本上线前实施AB测试，引导 10％的用户到新版本设计。查看用户是否"尖叫"（即对新设计有尖锐的抵触），如果存在尖叫状况，新设计下线->进入Rollback设计流程。
谈到现今互联网领域的UI/UE问题，除了一些设计以及体验上的问题以外，还有一位朋友提出了"网站的服务意识差，用户的被服务意识也很差，如果更好地沟通以及交流反馈，在有些时候也是问题。用户积极参与的意识很重要。"

--------

把街机搬回家

由 @gokeeper 带来的，当天让无数技术男燃起的话题。讲述了如何把原汁原味的街机搬回家，要注意：使用的不是寻常的模拟器、PC摇杆，而是真正的街机硬件、街机框体和摇杆，当然还包括投入代币这种可勾起无数人美好回忆的体验。

其实如果想照葫芦画瓢实现一个也不是什么大问题，gokeeper的解决方案也说明了，山寨产品＋淘宝＋用心实现的激情基本上可以解决全部的问题。

自己简单记录下来的几个要点，供大家参阅：

  • 街机主板的游戏卡槽上，连接一款通过电脑来提供游戏的转接卡，价格不贵。
  • 山寨厂街机框体可定制，价格 1200 元左右，包括框体、29寸CRT、定制的摇杆和按钮。注意相较之下日本原厂的使用近十年的框体还要万余元，山寨厂的街机框体，价格便宜量又足。
  • 电视的扫描频率问题。显卡默认输出的刷新率过高，需通过更换驱动等特殊方式，降到15KHz左右
  • 淘宝上订购的精巧的投币装置 40元
  • 整套设备还具备传统街机难以想象的扩展能力，可以通过KAI与网上的玩家进行对战，还可以与Xbox 360进行连接，在庞大的街机框体上执行家用机游戏。

--------

网页正文提取初步

宋进亮博士带来的话题，整个话题其实也是自然语言识别领域的一小部分内容，不过宋博士的开场就先声明："整个应用不限定特定行业，演讲中不用忽悠人的词"，于是整个话题也就在轻松的环境下讲述了众多非常有料的内容。

现场演示的实例： 从Blog以及网站页面里面抓取正文

大体上看，目前的文字抓取方式，无外乎以下三种方法：
  • 通过正则表达式抓取：通过诸如 BeautifulSoup 这样的工具进行。
    • 方法简单，但是性能可能会有问题。与所抓取的目标网页依赖过大，一旦网页格式发生变动，就需要对抓取的方式进行一些更新。出于偷懒的原则，如果程序能够自动识别变化，那样才比较完美。
  • 标签特征，本话题所述方法即属于此类别
  • 基于视觉的处理，跨越标签领域，有一些的技术门槛，此话题暂不涉及。
    • （在2009年2月的OpenParty"有狐"活动中，有位来自雅虎中国的朋友分享了一篇在服务器端使用Firefox进行网页抓取和内容识别工作的话题，实际上就是基于视觉的处理实现）

基于文本密度算法的实现，是上述的标签特征类别的方法。
基本公式：纯文本字符数/HTML源码字符数

原始方法
  1. 记录HTML标签起始位置
  2. 统计HTML源码首尾包括的字符数和其中的文本字符数

使用Python的matplotlib对统计的结果进行图示查看，从直方图中直观地可以发现，网页中有一部分的文本密度明显高于其它部分。在整个过程中还可以使用Tidy软件包来清理HTML代码，实例中演示的Sina页面，使用Tidy进行清理后进行识别的效果要好很多。

从实际状况出发，对算法进行小调整：从以前的文本前后判断，变成标签前后判断

优点：数据的整体性更好。
缺点：数据的分布情况不够直观，有干扰。可以适当地加入一些值的过滤方式来实现

整个实现方法所使用的代码量：加入注释以及模式过滤的原脚本大约有200多行Python代码，如果是根据网上论文的原始实现，大约100多行Python代码

所参考的论文中描述的人工智能文本识别方法：
  • 使用神经网络模型
    • 可使用FANN库，有相应的Python封装
  • 采用原始的一刀切方式，会有丢行的现象产生。    
  • 个别行的密度会比较小。

神经网络模型的算法，可以采用机器进行学习的方式进行。不过要注意，学习所采用的原料和实际使用中所针对的目标相似度的关系也很重要。学习的量较少，可能会达不到完成任务所需的精度；而学习量过大，出现"过学习"的状况，也可能会出现过度吻合，从而导致对目标数据的变化非常敏感。

其它智能方法

针对HTML标签序列
  • 统计方法
  • 贝叶斯
  • 马尔可夫
  • CRF

不过为了达成我们的目标，找到最窍门的地方，才是最关键的。比如在很多应用场合下，看似粗旷的'一刀切'方法可能效果也非常不错。

这里介绍的自然语言识别只是一个具体的分支应用，而这个大领域还包括很多其他的内容，如逐渐变热的分词技术，也是值得关注的。

总的来说，自然语言识别技术需要根据应用领域、应用环境来提供相应的解决方案。没有银弹！

我一知半解的记录肯定略有偏差，想要详细了解此内容的朋友（如查阅上文提到的论文等内容），欢迎访问宋博士"提取HTML文档正文"的页面以及他的Blog访问详情。 

------

依旧分身乏术，本期活动还有很多其它大牛带来的精彩话题，只好期待其它参与朋友的记录了。现在每次在活动现场的事情越来越丰富：与各方朋友交流信息、控制话题时间安排、拍照、结识新朋友...... 诸多事情精力有限，再加上 OpenParty 的话题越来越多元化，自己对各个话题基于简单了解的记录，难免粗浅以至问题多多，还望大家多多包涵（了解细节请多参考来自演讲者的第一手资料）。我只希望自己这些简单的记录是引导大家进入某个话题或领域的一小步，就好像 OpenParty 帮助大家结识、了解和交流一样，我们没有奢望这种简单的事情能够立即带来什么翻天覆地的变化，但是这些却打开了无数的门，孕育了无数种可能。这就是最让我们兴奋的事情。


OpenParty "聚萤"

By CNBorn on January 31, 2010 11:51 PM
2010年开场的OP活动依然精彩，此次活动吸引了近百名朋友前来参加。此篇文章仍像以往一样，简要描述下在本次活动中，自己聆听的几个话题。

首先是ThoughtWorks咨询师钱钱带来的"敏捷需求分析"话题。此话题分量很足，在此简要呈现下我的零星记录，作为个人对整个话题思路(不完整)的简单梳理。

敏捷软件需求

软件需求遇到的最大问题是什么？基本上都是沟通和交流的相关问题
需求从哪里来：客户（市场）、用户
我们需要确定的是：谁是用户？当前业务流程情况？业务目标是什么？
项目需求确定中遇到的最大问题是什么？需求文档驱动的过程不堪重负


ThoughtWorks如何进行需求分析

项目启动：QuickStart
    概要的需求分析，初步估算规模
不是不需要文档和需求分析：但是也不期望一次弄清楚所有需求。在项目启动阶段，先实行粗粒度的计划，暂时不考虑远期偏向细节的东西。
粒度最好可以控制到，单一发布中，每两周一个迭代。
这期间最重要的，是了解业务、分解业务。这在各个领域、各个公司、各种情况下都不同，没有规则可以遵循。


项目启动阶段（概要分析阶段）

产出：
    1 愿景和动机、驱动力，业务价值
    2 需求列表
    3 可视化项目原型

同时评估项目风险、成本，提供可视的、便于评估的文档。
通过需求分析师、客户面对面的信息交流，把需求、目标具体化，最终创建大家一致、认可的目标和分析。可以通过一些具体的东西来实现，比如财务流程图，业务流程图，功能分解图。


在文档不堪重负的情况下，如何表述需求？使用 User Story (用户故事)卡片


为什么用卡片：单一的需求文档只是信息的聚合，而分解为可以量化和检索的知识，更加便于我们评估和分析。
每个 User Story的基本定义为：一小块对客户有价值的功能。
这个原则是如何产生的呢，通过角色流程（ Role-Process）的方法，绘制出流程图， User Story是该图上基本的元素

Story的3C原则：
  • Card 需求存在
  • Conversation 一段对话和交流
  • Confirmation 用户需求的确定性

如何分辨 User Story的质量呢？好的User Story遵循INVEST原则

  • Independent 可以独立开发
  • Negotiable 可以协商
  • Valuable 有价值
  • Estimate 大小可评估
  • Sized appropriately 合适的粒度 （1~3天为最合适的粒度）
  • Testable 可测试性


需求可以分解为：产品、模块、特性、用户故事、开发任务五种不同的的类型，逐步细化。

举例：
产品：电子商务系统
模块：电子商务模块
特性：购物车、在线支付
用户故事：添加到购物车，查看购物车
开发任务：更改数目、计算总额
任务分解后，先排出优先级，对技术可行性作出验证。


UserStory的生命周期：使用Mingle管理，建立 StoryWall
可视化管理：
  • 墙上贴卡片
  • 直观
  • 增强了管理透明度

总的来说，敏捷＝开发实践＋项目管理实践

简单谈两句我个人对于敏捷的非常粗浅的理解：
    这其实更是一种管理技巧与方法，而不是具体的技术问题。如果仅从一个(懒惰的)程序员自身的角度出发，那么整套东西基本是很多看起来奇怪、有些还打破了日常工作习惯的行为准则的堆砌。但如果你有幸能够参与多个角色（如同时作为产品的销售、开发、决策人员其中的数职），来从一个更高的高度来审视并经历过一个或数个软件项目的时候，就会发现这些行为准则完全都是为了一个清晰的目标：为了按时、高质量地完成软件项目。同时竭力避免软件项目各个过程中各种由于人员、交流以及其它问题所造成的不利影响。

结尾的时候钱钱推荐了一本书：User Stories Applied ---- TW敏捷需求分析师必读，欢迎感兴趣的朋友参阅。

----

Mozilla在会场展示了火狐中文版本的一个功能，"火狐魔镜"。简单的说，就是可以把任何网站页面上单独的一部分取出作为Widget放在桌面的功能。整个演示很眩。

我个人认为整个话题最好的地方在于异常良好的互动性。整个话题是一次互动的交流、这个产品的走向、发展以及未来开源的情况，在场观众都得到了即时的了解。同时通过和在场观众的互动，Mozilla方面也更好的获得了开发需求的反馈，用户也可以窥见未来产品的方向。我认为这种形式非常值得借鉴，是参与开源社区产品的公司，与开源产品的用户一种非常好的交互模式。

----

接下来就是超群带来的MongoDB介绍。通过超群抛砖引玉的介绍，让听众对于MongoDB的特性有了比较好的了解。

具体的信息可以参考当时演讲的slides: MongoDB in Action 很适合入门，同时MongoDB 项目的 Tutorial 也值得推荐。

我再次简要描述一下大家普遍关注的几个方面：

性能Benchmark
    可以参考这个页面，http://www.mongodb.org/display/DOCS/Benchmarks

比较值得记录的如下：
  • 不支持JOIN
  • 不支持事务
  • 支持其它大多数常用SQL功能
提供了三种Replication的方式
  • 主从
  • pair形式
  • 有限的主－主
便捷、自动Sharding (这点很Cool!)

GridFS 内建的文件系统
两个应用：
  • nginx模块，可以直接读取GridFS
  • fuse模块 让*nix操作系统可直接挂载 GridFS
提问时间，我根据自己最近对kv的一些肤浅了解提了如下问题：Tokyo Cabinet 最近的版本增添了table存储功能，也已经跨越了kv的阶段，与TC的table相比，MongoDB的优势在哪里？
回答：首先，tc 的table诞生比较晚，相较其它部分，有不够成熟的风险；tc的库还是单文件库，倘若要分库，没有MongoDB的sharding 方便。

不过MongoDB占用磁盘过多，我个人觉得如果磁盘IO可以提高的话，性能或许还有提高的可能。超群目前的应用情况是，几百万条记录，占用磁盘空间几百兆。

由于自己现在在做Django，特别关心了下MongoDB和Django的结合，有如下项目可供感兴趣的朋友参考：

两个Django结合MongoDB应用的例子

DjanMon
Using PyMongo

django-mumblr
Mumblr is a basic Django tumblelog application that uses MongoDB.
Using MongoEngine

另外这里还有一个非官方的MongoDB Django Backend:

Django MongoDB Backend

总的来说， MongoDB在我看来，是用来在使用基本SQL功能又想要获得类似KV存储数据库性能的领域，同时又希望尽可能降低转换成本的合适选择。感兴趣的朋友不妨尝试看看。

----

一月份的活动也是我加入OpenParty核心团队后的首次活动，可以向大家透露的一点是，现在OpenParty团队正在努力在各个方面进行改进，力争为大家创造更好的交流、学习环境。感兴趣的朋友也可关注OpenParty 官方Blog，了解最新的详细情况。大家一直以来的支持，是活动组织者最大的动力。

OpenParty "岩上"

By CNBorn on December 21, 2009 1:44 AM
12月份的活动聚集了来自Apple、设计、架构、出版等行业的大牛们前来分享话题，所以来到现场参与活动的人数达到了 OpenParty 活动的新高峰，100多人几乎坐满了宽敞的ThoughtWorks办公室。

恰逢 OpenParty 成立两周年，现场还播放了温馨的回忆片花，感谢长期以来大家对于OpenParty的热爱与支持。

重点讲述一下资深的Apple专家 @hengdm 带来的重量级话题，iPhone软件开发设计流程。（现场投票58票，为 OpenParty 活动历史以来最高，可见此话题多么受欢迎）

---

"用设计Windows软件的心态去做OS X应用软件，下场必然失败；
用设计Windows软件的心态去做iPhone应用软件，下场必然失败"

设计师以及设计团队的灵光闪现，固然可以促成一款好软件的诞生，但是这种灵光闪现却可能带来更多无法管控的内容，影响软件的整体质量和体验。所以，苹果公司在软件产品设计流程的管理中，严格控制了规范流程，尽力避免软件受到这些灵光闪现的影响，而从一个理性、量化、可以阐述的角度，来规范软件的用户体验和质量。

如果用一种苹果独有的体验标准来衡量软件的体验和质量的话，那就是"让用户感觉自己使用这个软件的动作都变得十分优雅"。


总体上说，iPhone User Interface Design分为四个部分

  • 平台的范例：了解用户的使用情景和使用习惯
  • 软件产品定义：明确软件的功能目标
  • 设计及原型
  • 对软件的打磨与改进

Coding 的部分，所耗费的时间在整个的设计流程中，绝对不是最多的。通常夹杂在第三步和第四步之间。


"我们造就工具，工具也造就我们"

作为产品设计人员，一个必要的宗旨是做有水准的产品，对用户负责。用户从来就不是你所想象的那样，会因为"素质低"而使用并习惯设计不好的产品。现实的情况是，如果产品的设计人员足够认真地进行产品的设计和打磨，那么就会有足够多认真的用户，来一起使用并且认同一款产品，从而形成正常的良性循环。端木非常不赞同国内脑残产品的做法，对用户的不负责，就是对自己的不负责。

iPhone的革命性创新，对于软件以及交互式体验设计提出了新的需求。内置电子罗盘、GPS、Internet浏览器等各种功能和设备的结合，为产品设计者带来了更多的用户信息，而如何应用、认知这些信息从而产生有价值的产品及用户体验，是关键所在。

从操作体验上进行阐述：软件的操作界面，从1970年至今经历了打孔纸带→终端界面→图形界面这三个大的演变，总体的发展历程来看，用户的行为，离直接操作数据越来越接近，操作方式也逐渐由抽象变得更加直接。iPhone更是第一次给用户以"直接用手来触控数据"的体验，而非像传统的操作方式还需要一个中介媒介（输入设备）来进行，这个技术上的不大的变化，带来了感知体验上巨大的提升。

从一些具体的设计细节来看iPhone给用户界面体验带来的变化：

  • 鼠标点击，所影响的尺寸为1x1px
  • 手指触摸，所影响的尺寸为22x22-55x55px
  • 滚动条在以往的手持移动设备中（如Windows Mobile)，还存在。但是在苹果的概念中，滚动条的设计与用户直接的体验设计向背离。用户可以用手指直接滚动屏幕，与常识性的概念完全一致。同时滚动条的样式还存在，但是仅仅作为一个信息指示用的工具（提示页面位置）的工具而存在了。
  • 同理，下拉菜单也变成了转轮，完全摒弃了在大屏幕系统上常见的各种GUI控件先入为主的概念，而完全从用户操作的角度考虑，来达到用户可以直接操作并反馈的效果，而不是纠结与细小的，难以控制的组件中。

可以说，抛弃以往由输入设备、遗留GUI设计等原因的操作定式，而将对于用户的操作变得更直接以后，带给用户的提升和震撼，是可以想象的。

不过请注意，上面讲述的都是将操作界面变得更直接更加易于使用。但是这种情况并不适用于100%的应用程序。合理应用间接操作的设计，也可以达到良好的效果。那么什么样的应用需要并不那么直接的，也就是刻意被复杂化的操作呢？举个例子，比如在游戏中，如果玩家可以通过手指快速点击游戏中的目标，那么游戏就变得毫无挑战性了，所以游戏中，将操作间接处理，让玩家需要左右摇摆位置变换目标，再按发射按钮开火，这样以来，间接的操作就给游戏带来了挑战性，组成了游戏乐趣的核心。由此可见，针对不同的应用，提供不同的设计思想和操作模式，是十分重要的。


明确软件设计的目的：不是功能的大集合，而是明确要解决一个怎样的困难，为用户提供一个具体的解决方案。

界定应用程序的三大基本要素：这个应用程序与其它应用程序的不同之处／需要解决的问题／所面向的用户群

Context/使用情景：不同的用户所需要的使用界面的差异。列举了商务人士／消防员这两个不同的职业，倘若使用iPhone应用程序的话，对于应用程序界面感受的具体需求会是怎么样的。

通过iPhoto软件桌面版和iPhone版本的设计区别来重点讲述，设计软件中基本要素的体现：

iPhoto桌面版作为一款功能全面的软件，其基本的功能介绍有几十项之多，基本覆盖了一个通常用户对于一个好的相片管理软件的需求。其功能可以主要概括为以下三个项目，组织照片、编辑照片、分享照片。

那么，iPhone的版本，是否也应该照搬这个设计呢？答案是不，有如下的几个原因：

  • 首先，单单就界面元素的设计来说，很多在桌面版本中应用得十分出色的界面元素，如操作面板、照片显示风格等，都不适用于直接搬入iPhone版本中，画面太小，会导致操作起来不友善。
  • 从功能上来说，用户时候需要在移动中，从手持设备上认真的组织自己的照片？是否需要在路上用手指细细地编辑自己的照片呢？答案基本上是否定的。不过，分享照片这个功能，确实是iPhone版本可以大放异彩的地方，所有人的都会有分享照片的场合，而一个随身携带的设备，恰恰是这个功能应用最好的载体和实现者。

思考到这里，这个软件就有了一个明确的设计方向。iPhone版本的iPhoto软件，应该有清晰、流畅的浏览体验，并且可以让用户迅速和别人分享该照片。

这就体现了iPhone软件设计的一个很重要的宗旨，选取最少的功能，简单就是美。但注意这一切是在了解用户需求，并集中精力去解决用户所遇到的问题的基础之上。而与之理念相反的、功能复杂、冗长的产品，绝称不上是个好产品。

整个设计中，还包含了无数的细节，而高的价值，往往都体现在这些细节中。通常来讲，AppStore中的优秀软件，都用了大约60%-70%的时间来进行产品的设计和定义，实际的编码时间所占的比例，要远远少于通常的软件项目。这就意味着，iPhone平台上的优秀软件在用户交互以及满足用户需求的方面做的更好。从而让整个平台以及平台生态系统的易用性体验，达到一个新的高度。而苹果这些设计理念，都注入到了 iPhone Human Interface Guideline 这部文档中，此文档堪称iPhone开发人员的圣经，不单单介绍了iPhone开发中这些元素、以及针对用户体验相关的要求，更是把与此相关的来龙去脉全部呈现并细致讲解，是苹果无数理念的结晶。


提供优秀操作特性的基础元素：
  • 多点触摸
  • 虚拟键盘，可根据应用需求进行定制，摆脱了实体键盘在体积以及直观程度上的困扰
  • 可隐藏的控件
  • 减少用户输入操作，自动提示和补全，提供默认选择

根据掌上设备的特点，捕捉用户的行为习惯，为用户提供最好的体验。端木在讲述时举了这样一个例子：用户在早上的某个时段、特定位置经常查看一些内容；晚上在某个位置特定时段查看一些其它内容，在几天之后，软件自动识别出相应的规律，并自动为用户展现相应的内容。用户会觉得软件的人性化程度非常高，从而对产品有着更强的投入感。所以，利用好获得的用户信息资源，可以有很好的成效。

具体到控件设计应用的一些指示：
  • 工具栏加材质，图标一定要保持简单
  • 可点击的控件都带有触感
  • 导航
    • 指示层级位置，直观
    • 显示目标，回退按钮名称为上一级内容名称
    • 使用标准控件
  • 列表
    • 使用图标，便于用户记忆
    • 两种不同的展开箭头：进入新界面和不进入新界面的
  • Tab的使用可以减少层级结构，有效组织内容，可以参考iPod应用程序下面的Tab栏

苹果的设计美学体现在很多细小的地方，一个非常明显的例子就是联系人管理中的联系人详细信息页面：这个页面设计中的行间距、颜色搭配、版式等等都是苹果美学元素的最佳体现。端木限于时间关系没有过多描述，简单的说，行间距中文字实际上并不是居中的，而是下方比上方空白多出一个像素，原因是这样的视觉效果给人以更加稳妥的感觉。


针对不同应用程序类型，使用图形界面元素所需要注意的技巧：
iPhoneDesign.png
严肃类工具：直观的界面，便于操作，使用标准化的控件
有趣类的工具：可以加入些个性活泼的因素
有趣的娱乐软件（如游戏）：不能使用标准控件，在界面上提供足够的新意和感觉
严肃的娱乐软件（如iTunes商店）：可以适当使用一部分图形来提高体验认知。可以用动画来帮助用户理解行为，接受反馈


创造实用的小工具：最受欢迎的工具都是单一工具，只做一件事，数据不要太复杂。

讲述设计过程中的纸上原型设计时，讲到了Things团队精彩的设计过程。而细致的设计流程通常需时一个月，这是非常重要的过程。

界面上的打磨与改进：加入软件自动提示、根据用户行为提供足够反馈等细节功能的提升。但注意要避免：
  • 加入动画不意味着全部界面元素都在动
  • 设置有意义的动画
  • 各种视觉效果要以不影响用户的主要任务为前提


总结：
  • 产品给予用户直接的操作体验，在可操作元素上进行视觉反馈。
  • UE>UI
  • 最好产品的元素定义，经过仔细的设计流程，最终生产、发布软件产品，如此才能保证有一个良好用户体验的产品设计


总体来说，这个话题从主旨上强化了很多我在 Getting Real 里面学习到的理念，又经历了一个打破条条框框，从新的方向开拓思维的旅程。也感受到了苹果的团队，对于细节已经不再是一种要求，而几乎就是一种痴迷，绝对的痴迷。这种乔布斯气质领导下，很难出现质量不高的产品。当然，细节只是关键环节的其中一环：正确的方向和思路，完善而严谨的细节设计，良好的用户体验，这些要素缺一不可，而成功地把握它们，并在其中找到绝对的平衡，才是苹果的成功之道。端木恒的演讲非常精彩和有感染力，slide的设计更是出色。实为一次绝佳的收获。

接下来又收听了西乔带来的"理性的设计"话题，由于时间和精力有限，无法做非常细致的呈现了，感兴趣的朋友可以移步这里查看现场视频录像。

OpenParty "秋色连波"

By CNBorn on November 3, 2009 10:28 PM
阔别了两个月的 OpenParty 于十月的最后一天再次到来，此次非技术类话题占了主力，我自己也贡献了长假期间独自柬埔寨背包旅游的话题。像以往一样还是谈谈自己经历的内容。

首先是 MediaZero 带来的，关于中国纪录片发展现状的话题

"一个国家没有纪录片，就好像一个家庭没有相册" -- MediaZero 的这句口号很有力

实际上较早前的一次 OpenParty 就在一位纪录片爱好者朋友口中得知了MediaZero ，了解到这是一个经常举办纪录片沙龙的地方。觉得很有意思，通常自己看电影比较多，纪录片也看过不少，但是没有特别去留意纪录片这种类型，自己心里还是都将其作为电影来看待。所以看到有人对一种特殊的形式充满了热忱，还是很好奇的。

纪录片的生态环境：在中国，制作和播放成为一体（CCAV，同时具备政治宣传作用），这就造成了没有一个生态体系可以保障纪录片可以作为一种有市场的产品持续运作。国外的情况是纪录片的制作和播放分离，更有成熟的院线保证放映渠道，形成了一个生态链  ，保证了市场。

MediaZero 只有8个人，在行业里坚持做了9年，也只是勉强可以生存下来。通常纪录片很难卖出播放权，一般来说央视来买就算是大单了，很多地方电视台更是用白菜价来收购，为了生存往往也只能这样卖。中国的大陆桥公司引进了很多批量生产的纪录片，如Discovery, National Geography，而 MediaZero 认为自己首要的任务是向世界展示优秀的中国纪录片，同时将世界上的优秀纪录片带入中国。

实际经验：纪录片在中国走音像制品的道路会很惨。若干年前一个成绩十分不错的纪录片被乐观地制成大量音像制品，但是却只能在随后的若干年中被当成赠品送出......

在传播渠道非常狭窄的情况下，开始举办纪录片沙龙，地点就在 MediaZero 公司，迄今已经举办超过700场，在这个领域有着非常大的影响。

对这个事业的追求，整个团队倾注了很多理想。在发展过程中所遇到的困难主要是想要发行却没有相应的市场、渠道狭窄、同时纪录片本身的质量也会成为一个问题。从片源的质量着手，于是MediaZero又办起了纪录片工作坊，做相关纪录片从业人员的咨询业务，同时请来业内资深人士如贾樟柯等来授课（贾樟柯获奖之前就来讲过课，据悉课程十分精彩，而讲稿可以在她们的网站上面下载）。对业内人士的培训，可以提高国内纪录片的质量，从长远的角度上来看，也是在改变一个行业的生存土壤。

介绍中来自MediaZero 的 Coraline推荐了三个纪录片

神秘球 － 一个男子跨越国界追求自己最想从事的事情（缅甸的一种竞技项目）从而发现自己的故事
输家赢家 － 中国公司收购德国工厂，并将其整个迁出德国的故事。中西文化的强烈对比。
（以上两个片，据Coraline本人讲，是那种"看完就要咬桌子"般精彩的纪录片，强烈推荐）
Mad for English (看了一部分片段，很精彩，手法漂亮的纪录片，有着和一般电影一样甚至超越一般电影的精彩程度）

12月MediaZero倾注极大心血的国际纪录片论坛（筹备期间有着很多困难：资金不足、筹办资格需要挂靠上级单位，广电总急发话......），是一次该领域的盛事，很多资深人士都会到场，同时也有许多精彩的纪录片会届时放映，欢迎大家关注。纪录片赏片沙龙每周四晚7点举办，地点在MediaZero办公室。

----------

09年9月27日－10月8日我在柬埔寨独自背包旅行，此次的OpenParty上我针对自己的所见所闻、以及一些总结出来的背包客感受，进行了一个"高棉文化背包客之旅"的演讲。

在做这个话题之初，我首先考虑的是分享旅行经验的意义。旅行的宝贵经历和经验，是旅行者自身的、永恒的。如果你想让别人也一同分享你旅途中的体验，那就应该精心提供尽可能多的东西来帮助受众们了解和体会。所以单单照片是不够的。分享给别人的东西，应该首先是具备尽可能完整信息的介绍，你需要有简单的线索和结构，并且一定要确保提供给别人足够的信息量，又要保证整个架构非常清晰。从这次我准备和进行分享的过程来看，我觉得并不容易。

一位台湾朋友的柬埔寨之旅的slideshow（链接）给了我非常深刻的印象。其中对于线索和照片的处理，让人不用聆听他现场的讲解，就能非常完美地回归他的旅程。我虽然参考了他的制作，但是还远远没有到他那样的高度（OP上我用的slide主要是为了现场讲解，日后我会对这个幻灯片进行进一步的修改，以更适合在网上共享，目前的版本可以在这里查看)。

总的来说，这个足够吸引人的话题，现场的反响还是不错的，没有白费一个星期的熬夜准备。具体的内容我就不在这里详述了，我会陆续把正在撰写的游记发布到cnborn.net/blog，欢迎大家关注。不过我想简单说一个问题，就是在人们听到你要去一个遥远的国家独自旅行的时候，有无数的人都会问你："怎么想要去哪里的？听说......不危险么......" 等等等等的话，其实我觉得回答这样的问题是最简单的：困难无数，但你要明确的，是在自己心里，是否有一个清晰的声音和愿望在指引你，而事实却在很多时候比想象的要简单，借用Lonely Planet的老板Tony Wheeler的一句话："只要你迈出了第一步，恭喜你，你就已经成功了一半！"

很巧的是，去年在此分享柬埔寨、越南、老挝三国旅行的前辈朋友也在场，给我的介绍还做了一些补充，十分感谢。事实上正是去年12月的OpenParty的这个话题激发了我对这此旅行的计划，我用了9个月的时间把它变成了现实。同时我也希望有更多的朋友能被这种传递下来的激情所感染，慢慢去走得更远、看得更远。这种精神上的传播、分享和启迪，才是OpenParty最大的价值所在。

在演讲交流以及后来和 @diamondtin 的交流中，也发现了自己作为初级背包客还欠缺的一些经验：原来在潮湿的地区，除了需要用塑料袋包相机外，还需要干燥剂，我当时却什么都没有用，导致单反不仅仅在旅行期间不好用，还差点废掉。需要学习的东西太多了。

这里旅行的照片，我已经开始陆续在几个地方上传，感兴趣的朋友请查看 我的Footbig，我的豆瓣相册， 以及未来这里发表的游记文章。不同网站相册中的图片基本上不重复，欢迎观赏。

----------

Peter的话题"社区商业模式"我很感兴趣，是一个以社区模式为导向的创业指南谈。可惜时间的原因，只听了很少的一部分。有一些观点值得简要记录一下。

"看一个公司的战略，可以简单地从它网站的栏目看出来。一个社区导向的公司，必然会有Communities这样一栏"

"在芬兰有很多1－2个人的小公司，而这些公司的基本生存状态是由几个公司合作，组成项目团队给像Nokia这样的大公司做项目。"

"创业的顾问团队非常重要，有重量级人物的话，对外可以显著提升整个团队的给别人的印象及信用程度，对内也可以汲取到资深人士的一些宝贵经验。所以，不要吝惜创业时的那些share。"

"不要去做大而全的产品，而要让自己的产品最大化地贴近细分市场。"

坚持生存下去就是胜利。

另外，Peter是每年度OSCamp(OpenSourceCamp)的组织者，今年的OSCamp定于11月28日在北京召开，形式和OpenParty非常近似，欢迎各位同道前来参加。

OpenParty "溪窗听雨"

By CNBorn on September 1, 2009 12:05 AM
这次的 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的大牛提到了"响应式设计"这个系统设计理念对于他个人的一个启示，即当所有的需求和限制摆在你面前时，你又尝试去完全考虑他们，那么此题目必是无解的。敏捷问题也是这样，很多时候的很多项目，都存在非常多的问题，但是我们始终要明确目标、以及要做的是什么东西，抓住重点来出发解决。错误是允许的，不允许错误就没有成功，

-----

接下来 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

-----

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

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回顾文章规模的问题：我开始使用一个笔记本来记录所有一切我认为值得记录的细节，便于自己回忆和理解。但是写下来之后，发现最终总结到文章的很多东西都是简单的堆砌。一般来讲，自己选择去听的项目都有着相应的准备和充分的理解，所以即使是细节积累的记录，都是于自己比较有意义的。但是我不清楚对于一个对此话题不甚理解的读者，这样的意义是否还重要。这样的方式还有一个缺点就是文章会非常地长，文章会长到我的众多朋友实际上都很少看完我写的整篇文章......

除此篇幅本身的结构以外，我能想象到的一个形式上的改进就是适当分清主次，着重针对一个话题梳理出脉络，随后进行延展，而其它的话题则可以忽略掉一些细节，只着力于主题即可。这样也避免了自己对于某些技术了解的不甚深入（譬如本篇的敏捷话题部分，我于此的实际经验要小于书面上的理解，如果有误欢迎指出），而堆砌细节反而可能弄巧成拙的情况。

自己也考虑在未来多多尝试几种风格，尽量让大家更有效率地获取知识。既不是迷失在字数近乎无限的冗长的细节迷宫中，又不是在精简到渺渺几行的语录体文章中揣摩技术细节的痛苦，这个介于两者之间的程度，我会努力找到更适合的方案。

所以我很希望听听大家的意见，这样的细节大餐或者主次分清的形式你更喜欢哪种？如果有什么更好的建议欢迎提出，谢谢！


OpenParty "夏暮观海"

By CNBorn on July 28, 2009 9:59 AM
文章开场要首先感谢cleverpig及其他OpenParty同仁赠送的OpenParty Tee，十分Geek, 十分感谢！

多的不谈，还是先来谈谈本期OpenParty听到的演讲。

---

首先听的是杜文山朋友关于使用Sphinx的演讲。

Sphinx简单来说，是一个文档生成工具，用于把reStructuredText 格式的源文件生成诸如HTML, PDF, LaTex一类的格式。编辑者无须亲自处理文本的格式, 程序会自动根据源文件里的设置产生格式, 以及自动生成章节链接等工作。

和DocBook一样，Sphinx可以看做是一个把文本格式处理和文字编辑分开的工具。举个例子来说吧，大家一定都曾有过上学时用Word痛苦地修改论文的经验（没办法，在中国LaTex太小众），其中Word里面千奇百怪的可见或不可见的格式符、控制符一定玩弄了大家很久。而类似DocBook或reStructuredText 一类的格式则完全采用文本文件来记录文字格式，各种格式控制字符完全可见，不会出现如Word里某个隐藏在段落末尾的莫名控制符导致文章之后的某些部分完全乱掉，而完全找不到这个控制符的情况了。同时，完全采用纯文本文件进行记录，使得使用版本控制软件对编辑工作进行全程追踪和记录成为了可能。而最终通过文本的源文件生成具有格式和样式的文本则完全是程序所进行的工作，避免了一切出错的可能。

使用Sphinx的项目有很多，著名的包括 Python , Django 的文档，全部是使用Sphinx 生成的。

我在场询问了作者选择Sphinx而非另一个非常有名的工具DocBook的原因，得到的答案很简单。Sphinx更Pythonic，reStructuredText 语法相较DocBook 使用的XML语法也更加简洁, 简单来说，reStructuredText 语法更类似于wiki。

关于reStructuredText的基本格式，以及Sphinx的基本用法，大家可以参考杜文山的slide，点击这里下载

接下来，杜文山又介绍了使用两个自行修改的Firefox 扩展来帮助用户更好地完成Sphinx文档的编辑工作。这个在slide里面没有详细提及，我觉得很有意思，值得说一下。

Scrapbook是一个知名的Firefox扩展，杜文山修改了这个扩展，从而使得这个扩展非常适合于编辑一个 Sphinx 项目。也就是说，Firefox 从此就变成了一个好用的Sphinx编辑器。该定制版本经过修改，如果需要，还可以方便地调用Vim来进行文件内容的编辑。

为什么要这么做？因为 Scrapbook存储数据的格式使用的是XML，杜文山通过自己编写Python 脚本来处理这些数据，从而实现了服务器端的全文搜索。Sphinx自己也可以生成一个基于前端的搜索，据作者说对于中文支持不好。所以他采用了自己另外编写脚本的做法。效果不错。

还有一个有趣的东西就是Firefox 上面的一个Vim风格扩展，作者由 vimperator 精简而成。这个扩展完全不像vimperator 那么难于上手，仅仅是保留/增加了一些自定义的快捷键和键盘浏览方式，甚至没有: 的命令行（因为太占用系统资源）。适合需要一个简单的Vim键盘控制扩展的朋友可以选用。

杜文山把这两个项目以及他自制的Sphinx在Windows上的打包都放在了这个页面，欢迎大家前去下载。另外打包的Sphinx文件里面包含一些本地化的内容，我十分期待这些修改可以提交回给开源社区，欢迎有兴趣的朋友在作者提交到开源社区以后大家一起参与完成！

此外杜文山还介绍了下自己的网站项目，里面提供一个很有意思的功能，是一个MoinMoin（一个著名的使用Python编写的Wiki系统，Ubuntu 论坛 Wiki使用的就是这个系统）的Service Provider, 通常大家都习惯了BSP，这个网站则可以为你提供一个记录知识与信息的Wiki，十分有创意。

期待作者把他的这些精彩作品回馈社区，调动更多的人参与。我稍后也将用Sphinx来创建我需要的一些文档

---

这期听到的第二个题目就是关于德国一个基金会将办公系统由Windows迁移至Ubuntu的介绍，受益良多。我的记录比较零散，在这里就跳跃性地谈一些让我印象很深的东西。

总体迁移过程从技术上对于广大Geek来说，其实都没有太多新奇的东西。针对办公环境，一言概括，就是从Openoffice.org、Thunderbird的普及开始，直到最后完成操作系统的迁徙。当然了，这个过程看似简单，所谓难点也完全不在技术上。而是在于人。技术上的问题，实际上解决的方式要比人的问题简单许多。要知道，人员基本上算是在企业的这种工作中，不可替换的部件。所以，人为因素对于类似这样的项目来说，至关重要。

整个案例由在这方面很资深的一个软件公司来完成。关于更多地在政府或企事业单位中推行自由、开放的系统，创始人张韡武讲述的一点很值得品味：关于这个行业，从实施公司的角度来说：如果要进行所谓的开源软件推广，仅仅是花钱采购其实并不能解决实际问题，如何对迁移和部署的风险对于业务的影响进行评估、使用合理的方案，让提供相关服务的供应商在可承受风险的情况下介入。说得很有道理。

对于如何进行开源软件的宣传，以下几点我认为非常值得学习。
  • 避免宣传一些技术人员对于Linux及开源技术的先天感觉。如免费、邪恶的商业软件等理念。真正的用户，关注的永远是如何关注业务，而不是建立一种偏见。任何使用偏见建立起来的观点，都是无法得到更高一个层次的信任的。
  • 关注用户需求的提议：Linux应该是一个解决方案的一部分，是成熟的产品，换用它是为了解决实际的问题，带来效益，而不是图新颖，搞新名词。
  • Linux并不比Windows高端，反而倘若在用户首先接触Linux 的前提下，实际上掌握Windows系统反而要学习和接触更多的感念

确保项目实施成功的过程中，有一个小白鼠环节特别值得大家注意。即实施团队会预先选择一些实验用户，先于其它同事尝试新的系统。而事实上对于实施企业来讲，选择的这个小白鼠用户，是预料到必然会获得成功的用户。这个策略可以大大提高项目实施的信心，确保整个项目的整体成功。也就是说小白鼠用户的成功，就是整个项目成功的敲门砖。大家通常会以为小白鼠用户一定是最信赖和支持这些新技术的用户，其实这并不是最重要的。相反小白鼠用户最需要的潜质往往是以下列出的几点，如关心业务、了解需求、有影响力，这些可以有效确保小白鼠用户在整个项目的推进过程中发挥实际的作用。我对此的思考是实际上在所有的软硬件项目实施中，都可以参考这个选择小白鼠的策略。

还有一点十分让我震撼，作为一个专业的IT服务公司，那些我们看似反复、琐碎的工作也一定要做到非常严谨和一丝不苟。迁徙后为单个用户需求所提供的检查表，就有几十项之多，细致程度令我惊讶。其中的那些细小功能都要和用户一一核实；我们大家相信已经习惯了自己鼓捣等同于这些Geek们的玩具的操作系统，但是把它们变为生意，严格地实施，显然需要另一种味道才行。

总的来说，我对于整个演讲的理解，可以归类于以下几点：

  • 整个项目的成功，可以总结为 把我需求，要做什么 专注这些
  • 把过程流程化，对于细节的把握非常重要
  • 未来行业的趋势，是IT外包
  • 如何确保一个项目成功的实行，是一件需要深入到企业内部流程的东西。

---

第三个是番茄树的介绍，简单谈几句

番茄树是个引人注目的网站，清新如豆瓣的风格，市场宣传也很到位，我经常去的网站上都有它的广告。

其对于界面用户体验的研究，以及对于客户服务认真的态度，非常值得学习。

有个小缺点是整个演讲前面讲了很多关于"轻公司"的概念，以及Amazon作为一个底层服务商的伟大。但难免让人找不到重点，因为番茄树只是在等待那个中国的"Amazon"的出现，而不是成为它。以后可以考虑在移些篇幅给用户体验优化、以及技术上概略的简介，对于OpenParty这样的群体来说，这些应该更吸引人 :)

番茄树吊了大家半天的胃口，最后介绍了一下其推荐算法的核心。不出所料，算法核心使用的是SVD算法。不过番茄树对于此的讲解有些简单了，关于这个算法的话题，在上次的OpenParty上fuchaoqun朋友进行了一个详细的讲述，并且还附有实例程序。我在这篇文章中有比较详细的介绍，欢迎点击访问《OpenParty "柳岸寻鱼"》。

---

此外本期还在OpenParty的介绍环节推广了一下我和朋友们发起的 411shot.net 一次性相机网站/活动项目，推广一下这个作为我们业余爱好的项目，也更凸显OpenParty的开放特性。还有幸成为了首个在OpenParty上进行推广和海报宣传的社区项目，很是荣幸。欢迎大家访问 411shot.net 了解详情。未来我也会进行特别详述。

随着自己involve 的项目逐渐增多，开始有了每次活动都介绍自己参与的一个项目的计划。自己数了下，可以撑很久一段时间而不重复。所以，欢迎大家期待。

---

习惯了在每次的OpenParty后写上一篇文章。为什么热衷写OpenParty 的文章？事实上现在OpenParty对我个人来说，提供了一个非常好的学习的平台。每次会议听取的三个题目，可以从中汲取非常多的知识，还可以和非常多不同的人进行交流，实在是得益于Openparty太多太多。简单写些文章也算是个贡献。而且自己撰写文章还有一个非常好的好处，就是一个可以非常详细的知识总结。在一个时间内掌握的东西，随着时间的流逝，肯定会淡忘，但是一篇自己写就的详述文章，可以帮助自己以及更多的朋友分享和回顾知识，意义巨大。可以想象，几位朋友的详述记录，综合起来就可说是一份OpenParty完整的记录了，可以弥补很多朋友在现场无法分身法术参加多个会场的情况。相当于让整个会议的延展范围无限延长，分享话题的朋友也可以获得非常广阔的交流范围。使得一次活动不仅仅局限于一个会场，更是一次全体分享者、聆听者聚集的厅堂。

OpenParty "柳岸寻鱼"

By CNBorn on June 21, 2009 3:03 PM
六月份再度归来的OpenParty "柳岸寻鱼"，话题依然很足料。 大家只消看一下话题投票时的题目，就可知道这会是怎样一个观点和知识激情碰撞的下午：题目涉及包括技术管理、Mozilla Fennec、译言带来的翻译版权话题、催眠体验、信息存储转发架构、智能推荐系统、企业开发中的RoR、IT眼保健、中国内家拳法...

还是简要谈一下自己参加的话题：

Mozilla Fennec 项目，作为Firefox 的移动版本自然得到关注。同时由于自己也在进行移动版网站的开发工作，所以对这个浏览器也很感兴趣。Mozilla中国的这位朋友讲述很有意思。同时在交流中也了解到了不少关于Mozilla的逸事：许多重要部件如Gecko核心等的开发者有很大一部分并不是Mozilla的雇员，而都是由分散在各大IT公司的技术大牛完成的（不过目前Fennec是完全由Mozilla Labs里面的设计大牛们做的）；被大家诟病最多的网银问题也曾有一个在技术上和观念上非常妥协的解决计划，但是由于和Mozilla 的主旨完全背离而不得不放弃，这点我十分理解。

言归正传谈谈Fennec，Fennec目前支持三大移动平台：Linux(Maemo, 即Nokia N810的平台), Windows Mobile, Symbian。目前Windows Mobile平台的版本最为稳定（同样其中有着占有率的因素）。Fennec的创造者，Mozilla Labs里面的大牛们为其提出的主旨是，Web只有一个，用户在不同设备上应该有一致的体验，而不必为一个网站创建多个版本。整个软件的界面设计和目前的移动版Safari不同，控制部分分置左右，默认隐藏，通过滑动可以显示。左侧是带有预览的Tab标签，Mozilla的工程师还曾为需要有多少个标签进行过激烈讨论。整个项目完全从底层开始构建，所以相较代码耦合度非常高的Firefox有着更好的执行效率。

这个项目很让我惊奇的地方在于，未来会完美支持Firefox的插件在本地运行，也就是说Firefox的插件可以无须修改（现阶段需要很少量的修改）即可在Fennec上面执行，我认为这是把Firefox这个平台无限延伸的很大一步。另外还看到了Fennec现阶段在PC/Mac上面的原生版本，也就是可以直接安装使用的浏览器版本、以及Mozilla没有详细说明的，我认为可能会大大改变移动网站设计的一些技术。不知未来能否拿到Fennec的原生版本和更加详细的信息，如果我可以拿到并且那些信息可以公开的话，我十分愿意和大家共享。

参与的另一个话题是智能推荐算法。相信大家都对这个东西很感兴趣，但是若谈起算法的实现难免会觉得艰深晦涩。我一开始对此的兴趣只是"能否有一个简单的Python库来让我调用呢？"。没想到，这个话题讨论不但让我这个数学门外汉都理解了SVD的基础知识，并且还实现了我一开始的想象！

新浪音乐的超群朋友带来的这个话题经过精心准备，完全不晦涩。完整的幻灯片可以看这里。三种常用算法：关联规则、Slope One、SVD的分别介绍，随后就是激动人心的实践，而一开始我的设想，也在幻灯的第26页得到了解答：Python智能推荐的完整解决方案DIVISI库，只要几行代码就可实现相关功能！数学真的是强大和巧妙的，更多详细信息大家可以仔细研究那个slide，很有启发。另外我最后咨询了一下关于机器学习的算法，那是一个叫做RSVD的算法，和SVD不相同，对此还有兴趣的朋友请自行Wikipedia吧。超群还谈到了Netflix的智能推荐竞赛，Netflixprize，悬赏100万美元来改进其搜索结果。虽然已经有队伍很快就要接近胜利，但其竞赛公开的资料是不错的数据挖掘和智能推荐的演示材料（超群讲述时特别注明：1、不同应用不可能采用相同的策略均达到最佳效果（没有银弹！）2、Netflix的数据很庞大，该公司使用256GB内存机器来跑相关应用，即使是网站上的公开测试资料也很重量级，配置一般的机器跑不动）。

遗憾的是，每次参加OpenParty，都希望自己强烈拥有的分身技能仍然没有出现。此次很想听的主题，基本大都被排在了一起。分身乏术导致自己很感兴趣的信息：存储转发架构设计和译言关于翻译版权的话题都没听成，期待未来可以看到相关内容的介绍。

此外有个想法，不知道以后的OpenParty是否会采纳。增添一个白板区域，供大家以文字信息的形式进行交流。这可以说是三分钟讲话的文字版本。参加的朋友可以提前准备好关于自己的作品/想法/观点的介绍，附上自己的联系方式，然后在粘贴OpenParty上白板上。我认为这样为大家又增添了一个交流的途径，而且几乎不增加什么时间及物质上的成本。另外还是希望可以添加关于首次参加的朋友的自我介绍。就我个人几次参与的经验来看，很多第一次来参加的朋友，很多都有一些很有意思的想法和主题，也渴望和大家分享。多多给予他们热情的反馈和认同，更彰显OpenParty的开放本色。当然这个部分可以和三分钟讲话一起，只需要主持人稍加说明即可。

最近的一个体会是，时间越来越紧凑，听各种话题的时间，和朋友交流的时间，基本上在一个下午很难安排，很是纠结。没聊够的只好放到下回，与大家七月再见。

OpenParty "晚春夜曲"

By CNBorn on April 26, 2009 3:21 PM
这次的OpenParty活动，内容异彩纷呈。更重要的是，有了豆瓣架构技术路线等QCon等会议上的精彩演讲，这次的OpenParty被大家戏称为"小QCon"

简单谈一下，认真聆听的两个Topic。

豆瓣技术架构演变，相信基本上这次来OpenParty的朋友基本也是冲着这个话题来的。开始自己还有些担心，这个毕竟是在需要门票才能参加的QCon上面 的王牌演讲，会完美地搬到免费的OpenParty来么？结果自然出乎我的意料，豆瓣的洪强宁大牛毫无保留，为我们带来了一场原汁原味的精彩讲演。至于为 什么这个演讲到哪里都会受到欢迎，我想一个最主要的原因是，这个说明从豆瓣最初的架构实例开始，直到现今豆瓣的架构，整个介绍没有任何枯燥的说教、概念， 对于任何对Web构建有一点经验的人员就可以很容易地明白和了解整个的框架结构，非常难能可贵。

豆瓣从上线到现在，随着用户的增长，期间出现的问题可以说覆盖了各种在网站架构需要扩展时所需要的问题，从I/O、CPU、架构到机房，这些实战的经验， 对于立志做Web的人来说，无比宝贵。从Lighttpd到Nginx，从Spread到rabbitMQ，从MogileFS到DoubanFS，期间 豆瓣实际上没有使用任何非常前沿甚至过激的技术，"使用熟悉的技术来解决问题"作为豆瓣的宗旨，可以感觉出整个团队对于技术把握的自信，很一种真真正正的 脚踏实地的感觉。

糖醋鼻子的"卡片机摄影"专题在上次的OpenParty上就已经十分期待，这次成功登录，终于如愿以偿。出乎我意料的 是，糖醋朋友的整个话题讲解，实际上完全不是局限于"卡片机"这个概念，而首先，从"摄影"这个活动最基本、没有人轻易想到的核心方面开始谈起，把摄影与 中国文化传统定义的琴棋书画统一起来，成为我们在新时代追求的文化元素之一。其间所包含的构图等原则更让我觉得糖醋在摄影这些基本功上的研究和努力非常值 得一般爱好摄影的朋友学习。这对于图片的修改一节，糖醋更是放出了很多非常精彩的图片修改，很多技巧非常简单，如剪裁、对比等，但是综合到之前提到的构图 等原则，就可以十分简单地作出一些让人震惊的效果，非常值得推崇。

期待糖醋同学可以早日放出介绍的slides，也欢迎大家到他的Google PicasaWeb上参观学习：http://picasaweb.google.com/zhmocean

离开的时候和OpenParty的组织者之一，icecloud聊了下OpenParty现在的情况。我认为现在OpenParty的状态非常的好，有着很高的知名度。但想起以前看cleverpig的 那篇文章，清楚这些都是由默默地为大家提供帮助的OpenParty组织者们，牺牲了无数的时间和经历做到的。我想在这里向他们致敬，同时在未来，尽可能 用自己力所能及的方式，来帮助OpenParty，就像上次我的Bugzilla演讲，以及这几次OpenParty的见闻文章这样。
1