Beijing Open Party - IT Community Unconference

公平、开放、自由

OpenParty来到了2.0.1.0版本！我们在刚刚建好的OpenParty组织团队博客上发布了活动的Roadmap：其中包含核心价值观和发展愿景、改进方案。希望各位朋友多提意见。

作为活动组织者之一，我对OpenParty所设想的一个目的就是：把技术带回家、带到工作中，把分享种植于心田，怀着开放的胸怀去爱、帮助他人和认识世界。

路还很长，少说多做一直是OpenParty组织者们的风格，我喜欢这种朴实~

下面我们来重温一下这份来自1月聚萤活动的温暖记忆吧～

郭慧：OpenParty开眼

很 感兴趣一位女孩（雨嘉）分享的主题，又正好时间和我是错开的，所以第一场就去听了她的内容。女孩是做传播的，她以3本书的推介为方式，来推出自己的主 线：网络的崛起，网络中的民主，媒体在传播中需要把握的关键节点。有一本书，通过她的介绍就觉得很好，《网络共和国》一位美国作家在90年代分析的网络中 的民主，如何去理解新形式下的民主，如何发挥网络中的民主，想到了antme推荐的一本书《民主的细节》，这两本应该可以更全面的让人了解美国对于民主的 理解吧！逐渐的，话题的重点放在了媒体在传播中的形式，新媒体（amazon的XXX与传统媒体的对比），在大家不断提到新媒体会给人们带来诸多便利以及 各种人性化设计、节约资源等优势后，突然想到了一个问题。去年boju在长白山分享会上的话，当人们到达旅行目的地的方式变得越来越容易时（原来的几天路 程到现在的飞机直达），对于目的地的渴望向往程度是否会降低呢？于是想到了读书，当新兴的阅读方式逐渐变为时尚或者趋势时，原来的去书店淘书，图书馆借 书，网上购书欣喜盼望得到书的过程，也许会变成过去时，但轻松的获得一个电子书，拿着阅读器阅读时，会不会使对于这本书的渴望降低呢？没有众里寻她千百度 的过程，是否还会有突然看到在灯火阑珊处的欣喜？阅读者对于读书变成了书籍生产线的一个最终环节，那最初的环节制作书籍的作家们是否也会失去了些许热情， 而是书的阅读质量降低呢？这会不会变成一个恶性循环？而最终使世界变得更是速食，缺少了一些人文的东西呢？本来想提问这个问题的，可是时间到了，所以它也 变成了我心底的一个大问号，也许这是需要时间去证明的吧！

我 的分享被安排在第二时间段的大办公室里，是个开放的空间，这让我有些吃不准，是否能够很好的抓住大家的情绪，实际证明这一点考虑是多余的了， 因为我连最起码的内容分享都做得不够好。因为不能确定参与者的接受程度，以及他们对我要分享内容的了解程度，我始终不能确定要把重点放在哪里，以至之后的 分享内容很杂乱，一些可以一概而过的东西被复杂化，让自己陷于其中，不能跳出来。而且太去解释一些东西，反倒没有解释清楚。不该拿出来的东西，却被自己的 主观情绪反复揪出。时间也因此没有控制好。近几次无论是对于这个熟悉的话题还是其他的话题，都可以做到简明扼要，重点突出，但今天却出了很大的差错。。。 结束后心里不断的晦啊晦~也实在不能找出一个合适的理由来。。。

open-party，是个很好的分享社区，虽然我不懂IT，但却能感受到那种ITer们在工作之余聚在一起分享的快乐，其实各个行业的人，都有自己去执着追求的东西，那都是一种信念，能把持着信念随自己人生成长，这本身就是很有意义的，让人感动且鼓舞的！

www.beijing-open-party.org，希望有着类似信念的你，也一起去开眼！

CNBorn：OpenParty“聚萤”

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

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

敏捷软件需求

软件需求遇到的最大问题是什么？基本上都是沟通和交流的相关问题
需求从哪里来：客户（市场）、用户

我们需要确定的是：谁是用户？当前业务流程情况？业务目标是什么？

项目需求确定中遇到的最大问题是什么？需求文档驱动的过程不堪重负

ThoughtWorks如何进行需求分析

项目启动：QuickStart
概要的需求分析，初步估算规模

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

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

产出：

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

同时评估项目风险、成本，提供可视的、便于评估的文档。

通过需求分析师、客户面对面的信息交流，把需求、目标具体化，最终创建大家一致、认可的目标和分析。可以通过一些具体的东西来实现，比如财务流程图，业务流程图，功能分解图。

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

（卡片范例）

来自：http://www.agilemodeling.com/artifacts/userStory.htm

为什么用卡片：单一的需求文档只是信息的聚合，而分解为可以量化和检索的知识，更加便于我们评估和分析。

每个 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放在桌面的功能。整个演示很眩。

魔镜3采取更酷的小窗口方式，可对网页上的任何模块进行剪切和收藏，制作属于你自己的“剪报”。

魔镜3支持全新的视频单放功能，在独立的窗口播放网页视频。拖放图片可轻松保存至本地；更含在线音乐、天气、股票等实用内容。

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

MongoDB In Action

接下来就是超群带来的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
http://github.com/mdirolf/DjanMon
Using PyMongo

django-mumblr
http://github.com/hmarr/django-mumblr
Mumblr is a basic Django tumblelog application that uses MongoDB.
Using MongoEngine

另外这里还有一个非官方的MongoDB Django Backend:
Django MongoDB Backend
http://bitbucket.org/kpot/django-mongodb/

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