Recently in Event Category

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

• Card 需求存在
• Conversation 一段对话和交流
• Confirmation 用户需求的确定性

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

• 墙上贴卡片
• 直观
• 增强了管理透明度

• 不支持JOIN
• 不支持事务
• 支持其它大多数常用SQL功能
  

• 主从
• pair形式
• 有限的主－主
  

• nginx模块，可以直接读取GridFS
• fuse模块 让*nix操作系统可直接挂载 GridFS
  

----

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

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栏

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


针对不同应用程序类型，使用图形界面元素所需要注意的技巧：

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


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

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

界面上的打磨与改进：加入软件自动提示、根据用户行为提供足够反馈等细节功能的提升。但注意要避免：

• 加入动画不意味着全部界面元素都在动
• 设置有意义的动画
• 各种视觉效果要以不影响用户的主要任务为前提

总结：

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

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

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

首先是 MediaZero 带来的，关于中国纪录片发展现状的话题 ----------
另外，Peter是每年度OSCamp(OpenSourceCamp)的组织者，今年的OSCamp定于11月28日在北京召开，形式和OpenParty非常近似，欢迎各位同道前来参加。

在现场对hdcola讲的大容量高并发信息系统架构话题印象很深，虽然自己没有做过如此规模的程序，但是其中可以让我们学习到的东西有很多，我尽可能讲我所能记住和了解的细枝末节梳理一下。

hdcola构建的这个信息系统，是用于移动网络中的数据处理部分，前后分别连接移动网络的数据中心来接收用户提交的数据以及发出到用户的数据。整个系统不需要与单个的用户客户端直接打交道，但考虑到很多信息通知业务的特性，整个系统对于并发性能的要求很高。

整个信息系统应用的环境是：

• 五千万用户、数百项服务
• 网关速度最快发送也只有4千／秒
• 不同省之间的网关速度不同
• 不同的业务于服务有着不同的优先级

HD 首先给大家介绍了一下 JMS(Java Message Service) 的系统架构，这个是信息系统处理的标准架构，Sun已经总结成为Sun JMS 规范。

对于关于这个系统软件方案的选择：举例，目前流行的大负载量信息处理方案RabbitMQ，比较吃内存，在极高负载的情况下有阻塞的现象，此时消息无法接收、也无法传递。在底层上也不是十分适合这个应用，比如在传递1000个相同的信息时，就无法作为一次来传递然后分发，而是需要分别传递1000次。不过RabbitMQ这个软件可以应用于诸多领域，是一款通吃型的架构方案，未来前景很不错，只是不适合这个应用。
最终选择了通过Python来自主实现。

2002年的世界杯上，该系统用于发送进球通知短信的业务，使用硬件配置为：内存1G，硬盘带宽和CPU都是非常大的瓶颈，CPU为奔腾2代。


粗略的架构图

其中各个流程中均有Queue来进行管理，Queue的实现可以参考QMail里面的Queue实现。

信息的存储方式采用了文件系统，没有使用关系型数据库。不同的信息通过目录的形式逐级深入，最终的节点有文件，但是也不存储信息，仅用文件名来存储数据，减少IO需求。这样整个数据存储部分实际上就交给了操作系统的文件系统负责，需要调整性能的话，需要调整操作系统的文件系统参数。格式化硬盘的时候，好像要把文件结点设置大，70G硬盘格式化完以后只有30G了。


数据存储目录结构

采用的是ufs2文件系统，开始用过zfs，后来发现zfs的特性在rsync上比较好用，在这个项目中实际上用不到，所以就采用freebsd 的默认系统了。

Why not MySQL?

2002年时的这个系统

---

2009年对于此系统的重构

Subscriber Demon （用于存储订阅用户信息）的数据库化（读写分离）
    减少数据库运算负载：每隔两小时，Slave数据库就将数据Dump到一个文件，有其它一个机器通过HTTP协议来进行读取（这个文件压缩后也要有400M），读取使用普通的bzcat命令，dump使用了自己写的py脚本。

Transfer Demon（存储待发送的信息） 的 Cache 内存化
    同时所有的消息同时也有持久性的存储。在硬盘上存储一个打包的数据（所谓的打包，是因为数据都相同，只是给不同的接收者，不是压缩），内存里存放的是单条的数据对应单个接收者。

信息接受（用户发来的订阅信息）和发送分离
    减少了磁盘I/O

2009年时的运行情况
    单日发送5-6千万
    订购关系超过5千万
    只有4台Server(因为单台的性能好过02年太多)
    采用Python编写

---

总结，优化性能的要点

• 让数据靠近CPU
• Cache内存化
• 队列遍历在内存中进行
• 慢I/O是系统的瓶颈

性能优化的原则

• 削减重复的计算，让计算前置（非常重要）
• 集中信息的共性，传递消息包而不是单条信息
• Task化，减少重复
• 做重复的事情是愚蠢的，即使它是计算机

---

一个成熟的协议在这个系统中非常重要

长连接 HTTP 1.1 RFC2616
异步并发 MSN协议 ISO8585


连接队列处理示意

具体实现可参考Google Code上面的 XBayTable 开源项目，由hdcola主导的项目

---

网络能做的更多：底层网络协议可以完成很多东西，二层 CARP  负载均衡等

优秀产品的核心

• 水泥+鼠标
• 软件+运营！  --> Microsoft, ThoughtWorks 的劣势
• 代码+系统
• 紧密结合

这个系统不超过20K代码，代码越少，出错几率越小

使用了Py, WSGI----httpd的一部分进程自动开成mod_wsgi，节省资源。使用Apache主要是因为追求稳定。
Python模块里使用了asynccore --> 一个原生核心模块

4台普通的PC机从硬件上换掉了JMS+Weblogic+HP小型机+Oracle的系统，硬件投资从3700W变成了40W

总共只有4个TCPIP连接，因为通向网关的发出端口也就只有4个。为什么还能完成如此大量的数据需求，因为协议选的好，这个通讯流程永远保持连接，不会断。

分析日志只使用了awk+grep+uniq，效率很高。

---

整个演讲给了我诸多方面的启发：

进行这样的系统架构设计及实施，一定要了解和深入多方面的知识，而不是懂一门程序语言就能够解决的问题。解决方案往往是融合了操作系统、文件系统、脚本语言、函数库、系统负载与维护、网络协议、网络协议底层、架构设计、计算机硬件体系等诸多的东西。对于这些东西的了解，少了哪一样也不行。

对于细致问题的把握，在高流量的系统中，任何一个细微的部分都可能成为瓶颈，所以也一定要成为考虑的元素。多一个循环或许就是很大的问题了，在编程珠玑的算法优化部分中的O(n)，如何减少n是非常重要的因素。

---
将自己思考的一点儿小东西先应用于一个数据库导入脚本的优化上进行了尝试，强化了一下自己对于上面讲到一些基本观点的印象。

这个导入脚本处理十余万条记录，中间经过数据处理，并将其导入一个格式不同的数据库中。

采用Python+SQLAlchemy编写，原始的第一稿性能非常不好，导入千条记录都要几分钟。于是开始着手进行优化。

用Python的cProfile定位性能瓶颈:

• 起先在没有优化commit 的时候，问题最大的是commit. ---> 因为每个记录添加的时候都需要查另外一个表的记录，如果不符合还要新建。解决方式是将这部分放在内存中进行，最后commit
• 后来变成了程序本身 ---> 优化循环，因为有很多记录是连续的，循环查比较浪费，在内存里设置了一个Cache，减少循环次数
• 然后变成了数据库的query ---> 优化数据库query，加入cache，后来整体数据内存化
• 直到最后的速度达到令人满意的境地

注：Python 的 cProfile 和 youxu 说的一样，只用一行语句就可以实现详尽的 profiling, 太方便了

完全应用了上面提到的性能优化原则：
    让数据靠近CPU --- 这个其实还可以把导入的原始库放在本地，并且采用效率更高的数据库引擎等方法来实现。
    Cache内存化 --- 把数据尽可能放在内存中
    队列遍历在内存中进行
    慢I/O是系统的瓶颈 --- 把读取和写入数据库的次数降到最小

效率：刚写出来时的版本（完全没考虑速度）估计导入全库的时间要10余个小时，更改了数据库操作的方式后，所需时间为原来的1/3，加入内存Cache以后，速度又快了一倍, 最后把所有数据内存化，整个导入完成的速度是6-6.5分钟。目前源数据库和目标数据库都在远程，如果搬到本地，再进行下数据库引擎的优化，应该还有优化的余地。我想用这个简单得不能再简单的小东西来描述和体验一下让程序高效率的原则，还是十分合适的。

---

谈回 CPyUG。我在当天还听了qingfeng关于Tokyo Cabinet的内容，讲得非常好，我记录得也很详细。但是自己没有深入接触过TC，发现记录的很详细的信息在几乎完全不了解的情况下，也无法阐述的十分清晰，怕是难免有误导。于是就先将这部分记录留着，等着日后对这个话题或者其中的一些部分有着更多的了解和认识的时候，再分别做些讲解和学习。还请大家期待。

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

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

---

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

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

---

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

六月份再度归来的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的开放本色。当然这个部分可以和三分钟讲话一起，只需要主持人稍加说明即可。

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

上周日参加了BetaCamp 这个活动。这是个延续了TED精神的活动（鼠标移到链接上查看什么是TED？），从它的命名方式就可以看出来。不知是刻意还是碰巧，上周末的几天里，仅我所知就有所三个与TED相关或类似的活动在举行。其中TEDxShanghai 和TEDxSYSU 似乎都是TED官方授权的活动。还有一个就是与TED的形式和概念都接近的BetaCamp 了，作为一个TED迷，我决定去看看。

BetaCamp 从总体上讲，是个很有意思的活动。参与的题目有着一定的广度，从城市规划到创意工作室创业史，从文化品牌的推广策略到处于一个更高层次的盲人摄影公益活动，在不长的时间里，听众确实能够了解到跨越多个行业的一些经验、观点和想法。印象比较深的是盲人摄影的演讲者郝曦先生，作为一名弱视人士（他在北京近30年，普通话好到惊人），他推动的盲人摄影活动旨在向世人证明即使弱视人群无法再体验视觉，但是作为视觉的感觉却可以存在并加以利用和练习。现场也展示了几幅作为弱视摄影者十分令人惊奇的作品。另一个令我印象深刻的是"陈幸福"品牌创始人的介绍，在一个精彩有趣的个人经历陈述中，展现了作为一个创意玩具品牌，从每天晚上下班后一个人在超市买的缝纫机前的创造，到三里屯Village旗舰店创意店铺的过程。其中一些令人印象深刻的经历：天桥下等人时卖出的第一个玩具、在税务大厅里因欠税而哭泣。深切有趣的经历、幽默的演讲风格，令人耳目一新。

事实上，对于TED类型的，主旨在与观点交流的活动，是否成功的标准并不取决于是否有多少个人撰写了无数篇Blog Post来描述它是多么的好，而是经过这样的一次活动，可以给予多少人全新的观点以启迪，并激发他们来行动。所以内容非常重要。而我认为同样重要的，还有另外一点，环境。

从最早看TED开始，那个聚光灯笼罩的、漂亮的讲台就成了我最喜欢的场景之一。我想TED的组织者们一定怀着类似这样的想法："给最棒的头脑以最好的舞台"。的确，能够在那样的讲台上演讲，无疑是最令人振奋的事情。而且舞台上明星般的打光确保了背后硕大的屏幕不会削弱演讲者的主题感。同时最令人称赞的是演讲时摄像的多机位设计。这确保了每一个TED视频都是一部在镜头上雕琢的佳作，而不是简单的DV录影。是一个既能体现演讲者个人魅力与风格，又能为演讲内容阐述提供帮助的极佳表现。

说完了演讲舞台，再谈谈讲台下的环境。我没能有幸到过TED会场，但其会场家具赞助商SteelCase的广告，却向我们展现了TED环境之优雅。不必做过多描述，大家可参考如下的TED视频（一个非常短小的介绍视频，包括SteelCase的广告一共才两分钟）

正如我之前所述，在一个主旨是"观点"的活动中，环境若是优异，是大可为思想提供积极的帮助的，否则Google也就没有理由创造它那如此优秀的办公环境了。

目前在我们身边的活动，我以为尤其是在环境上还有很大的改进空间。BetaCamp 的环境对于这样的活动来说还是较为拥挤，演讲区域的屏幕太突出，削弱了演讲人的感染力。另外对于本次的BetaCamp的环境以外的问题是，演讲者没能按照时间限制进行发言是一大遗憾。因为就我自己演讲的体会感觉到，限时演讲是一种更加能够保证演讲效果、同时也对演讲者能力提出更高要求的措施。不少演讲者的幻灯以及演讲中还犯有很多初级错误，说明我们这里的演讲风格还有待成熟。TEDxShanghai 我通过网络观看了当天下午的直播。感觉这是在是目前最贴近TED精髓的活动。演讲的题目和感觉都和TED的感觉十分相似。从照片来看，现场的环境也很不错。唯一值得诟病的是摄像时的镜头：从演讲开始，就没有改变过，只对着演讲者的头部一动不动。这大大减少了视频的感染力。中山大学的TEDxSYSU活动没有看视频，就不对环境等做太多评价了。

当然，我完全理解在当前的中国，举办这样一个活动的辛苦和艰难。我所谈到的对于环境的要求难免苛刻，以至于几乎是吹毛求疵，但无非是想让大家在更好的环境中取得更好的效果。我始终相信，生活中积极、新颖的观点和活动越来越多，我们的生活就越有希望。最后向在过去、现在和未来举办类似活动的组织者和贡献者致敬。

参加了6月5日的 Google Developer Day 2009, Beijing，这是一个迟到的总结。

总体来说，会议期间的课程倒是并没有给我太大的收获，认真听的两个课程(AppEngine)全都中规中矩，没有提供什么特别新颖的东西。反倒是开场时演示的Google Wave快速吸引了包括我在内的大多数与会者的眼球。融合了电子邮件、即时通信，便于交流和分享的协作系统，是一个很多年前就诞生(想想2001年时的Groove)并开始发展的概念，但Google把它作为一项可能会对未来互联网产生深刻影响的标准来发展，成功的机会显然要比单独的产品要大很多。Google 已用它内心深藏的科学家气质把自己的战场直接开在了未来IT行业的基础之上。GDD09大会，给我的最大感觉是"标准为王"。无论是HTML5，还是Google Wave，都以Web未来基础的面貌出现。在竞争对手仍在以老旧的方式和产品来挑战这个行业的机会时，Google却在面向未来的更遥远的起跑线上。

另外在这次GDD上，我没有在第三方应用开发者的展示中，看到什么真正具有革命意义的，震撼的东西。基本上都是一些小点子和API的mashup，OpenSocial 依然占了不小的比重。因为我十分不喜欢反生产力的webgame，所以可剩下的让人印象深刻的生产力工具可谓少之又少，可记起来的，怕只有晚宴演讲排在我前面的北大美女的Gtalk-SSH应用了。

那天对我来说真正的亮点，是晚上的"谷歌技术开发晚宴"。这才是一场真正的Geek狂欢盛会。布满灯光的硕大会场、具备Google风格，肆意拜访的沙包椅、酒水饮料...... 实在是众多Geek们少有的体验。说那里是个充满Geek风格的Woodstock应该不为过。

自己还有幸参与了Google的开发者演讲。短小的演讲讲述不了太多的东西，而且正如我之前说的，真正具有震撼效果的开发者应用还太少，所以我对于讲述自己的产品如何通过具体的代码来实现一个小功能也十分不以为然。我更关注这个产品以后的潜力。于是就着重描述了未来的构想。(可以透露的是，在不长的时间里大家就可以看到 CheckNerds 的这个更新) - "已经做了什么"并不重要，重要的是"我们还能做什么"。现在回想起来我猛然发现，这也是Google的观点，所以它们一直在向新的标准迈进。

另外自爆一下，想看这次我的演讲是什么样子的朋友，请猛点这里，如果footbig当掉了看不到，还可以猛点这里

这次的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的见闻文章这样。