[---------二分流掌门人]2010 ECUG大会，第一天记录。

lin_style 2010-10-16 10:41:24

简单的记录，里面的很多点扯出来都能扯一篇出来。

第一日
9点总算及时赶到，签到等扒拉扒拉。以下记录分段式，按笔记本上的稍做整理。不过，去这种大会前，能有20%值得听的就很满足了。
这个是前提

第一场生不逢时的 WEB OS

大概说了之所以10年发展的WEB OS失败原因有终端不统一，用户体不对(连入网络基本都在电脑)。
作者介绍了他们公司失败的WEB OS架构
前端 html,css,flash

后段数据持久化，mysql

然后巴拉巴拉了大堆,结果就是WEB OS失败了，最后转向CLOUD OS. 简单的说过去十年根本没有合适载体来存放WEB OS.我对CLOUD OS的观念还是和一样，是业务巨头的大戏，关个人PC很小的事。没听到什么很有价值的东西。反而对前端有个疑惑了，WEB OS这么些年来，就尽用FLASH,css折腾了?如果纯粹是模拟一个UI界面，那对以后游戏界面怎么办？一开始WEB OS如果关注功能说不定还有一丝希望，界面其实只是服务器传递当前的界面图片，然后加以热点判断，当前点了什么，鼠标动作。更多的是辅助以功能，最后才是UI的统一等等。

第二场 Erlang游戏开发
因为我也是做游戏的，很注意的听了下。作者是耗费3个月时间(后台)，做了个SNS的游戏。不过盈利不影响，快放弃了。这个兴趣所产生的东西它的组合也很牛，中间7、8页PPT都是讲要选择哪种开源程序等等。最后比较着重讲了数据存储格式，key-value这样的映射存储。我本来想提问可以尝试png的格式，最后还是放弃了。关键是跟游戏性能关联不大，也没什么兴趣了

第三场美地存储
一个分布式的存储。通俗点就是网盘^_^.听作者介绍土豆网就是用它的，04年开发的。我主要问了几个问题
1.用户和机器投资的比例。因为听他介绍用的机器蛮多的。后来见是给土豆网类似用的，就略过了。
2.同步更新。比如一个用户更新成功后，是在其中的一台机器更新成功，还是已经分布到所有机器上了。换个思路就是，从逻辑上讲一个用户虽然对应着一个服务器组，但是物理上是否也是一致。最后结果2者一致。本来想继续问如果上传失败不是所有的机器都要回滚？后来觉得这个问题挺傻，就没继续追问
3.负载均衡。作者提到一个可以根据机器硬件配置来调节，好奇。得知是有个专门的管理机器来做这个平衡。我理想中的是每个机器是对等的，可以互相平衡通知，至多有一台机器来管理下当前机器列表。本来想继续追问如果管理机器有负载问题了，咋办？后来觉得挺傻，就没继续追问。不过现在想起来，还是支持每台机器是互相平衡的观点。
4.交叉恢复。问这个问题，我对磁盘的牛B的I/O不太了解，后来得知是利用raid完成的。于是疑惑解开

午饭，照相时间和许大（许式伟）、余大（余锋）打了个招呼，闷头吃饭。不过排队的时候听到一个挺有意思的(没有任何第三方色彩的描述)：一哥们出面试题的时候，要求对方说出大学时《数据结构》这本书的版本号和封面色。这个，这个。。。。我觉得说VC6的SP1补丁补了那些更专业。

第四场面向状态编程模式
扒拉扒拉，对这种语言上的东西兴趣不是很大。不过反响却很激烈，大部分程序员的G点都被触到了^_^.埋头看赞助举办方发的内部杂志。讲的是把青春留在盛大的伟大女性们。。。。扒拉扒拉翻完书，闭目养神会，等待下面的场次。

第五场 Bob Ippolito的演讲
特邀嘉宾。MochiMedia CTO & 创始人之一。著名 Erlang Web 服务器框架 MochiWeb 的作者。
一个外国CTO哥们，不认识，英语也听不懂。努力的看PPT，装听懂津津有味中。。。得知明天还有位外国友人的，担忧中。。

中间茶点时间，装了盘水果等点心，角落狂吃中。。。

第六场软件工程&架构
许大的。
分为两大块，一个是软件的代码以KISS原则进行讲解，一个是单元测试。对于单元测试我基本没很专业的使用过，重点介绍前面吧。
介绍了一个很重要的时间图:
开发阶段--------------维护阶段----------------------------------------
1.开发阶段时间差异不是很大，差1倍很多了。而且老手的开发时间甚至比新手用得还多。但是这中间投入的时间对维护阶段至关重要。
2.差别，在维护阶段所进行的投入
3.如果加入一个新功能，应该在原来的代码上扩充，比如继承，封装，而不是去修改原来的代码
4.复杂度。人为的加入，自己乱想。
我对自己乱想深有体会。对于一个前期开发阶段的需求预测，要么你是很NB的人，要么就乖乖的按自己能力来制定，不要胡思乱想。那有人会问，那怎么确定后期的需求扩展？我觉得这就是一遍遍重写，用时间换来的经验。但是切忌，不要胡思乱想超出自己能力之外的需求。特别NB的除外。
5.工程语意的制定
这是我自己加的，语意包括比如大小返回用size,拷贝第一个参数是目的地址，初始化时固定的名称init,分配对象newObject等等。我觉得代码规范什么都是其次，一个有一定经验的程序员写出的代码不会难看到哪儿去。更重要的是不要对语意造成偏差。记得一回改代码，我都初始化得好好的，偏偏有个值超出了预期。仔细跟踪发现，不知道谁直接memset(0)了一下。大怒！
6.重构
当进行到这一步的时候，其实就是一个擦屁股的阶段。比如对之前代码的理解等等。更体现出了开发阶段的重要性。
这里我要说的是游戏中的开发：策划+程序。2者的质量管理肯定不能一个模式。在质量管理上不能简单的依赖当前功能的完成度来判断程序的好坏。而是应该以该模块出现的BUG率；以及当别人引用到该模块功能时，对该模块的修改率。否则有时候是非常不公平的，一个功能需要另一个功能的代码，结果发现不能复用，造成时间延迟，这能怪当前开发的程序员吗？

7.模块>框架
框架的定义，限制你的业务流程。比如MFC的框架，你要加个什么东西，需要在这里加个什么代码，那里加个什么代码。这样就对一些移动、重构造造成困难。而你写的模块，应该充分抽象出业务的接口，而不应该直接调用框接的接口导入数据,造成复用的困难等等。以wps举个例子：
WPS需要接受各种不同的格式输入，那么

输入1格式输入2格式输入3个格式
内核IO接口
输出文档

那么内核的框架有时候会进行重构等调整，影响了全部的上层代码，于是引入中间格式

输入1格式输入2格式输入3个格式
中间格式
内核IO接口
输出文档
那么，只要维护好中间的格式。WPS直接使用了WORLD的格式。而且能够即时查看中间格式转换的是否正确（WORLD可以直接打开），这也进一步说明大家再存储格式的时候，优先采用肉眼可以直接观察的格式

8.单元测试
这个我确实没怎么用过。但是根据许大的描述，似乎非常自动化。这边代码一编译完，另一边就将所有的单元测试自动炮了一遍。并且给出忠告，保留你的测试用例。

第七场并行计算
比较丰富。对并行的介绍，现场的演示，舞台控制系统的讲解。
并行库、工具:openmp, bbt
开头语，免费的午餐已经结束。欣然同意啊。并行计算其实很简单，重要的是对任务的分解，cache的利用，CPU的演变。任务的分解没什么好说的，根据各个业务来分。cache要求开始变高，比如要求各个线程都需要独立的内存分配池，假共享的问题，Scatter,Gatter.

独立内存分配池这个没什么好说的，比如linux中的slab对numa等节点也有考虑到，我也仿写了个windows的，所以对这个深有同感；

假共享问题指什么呢，比如有个int[5]的数组，你分别让线程1-5分别对其中对应的下标进行操作。结果在读cache的时候实际读了int[5]整个的内存，并且修改也是。结果在返回的时候需要对整个数组段进行刷新，并且性能上损失很大，作者给出了数据性能图，这个是我以前没考虑到的；

Scatter,Gatter这个暂时还没找到资料。粗略的说就是离散的地址对连续地址赋值，连续地址对离散的地址赋值。一会补上

作者讲到舞台系统的精度控制，需要毫秒级的。我刚想记录问题，windows的sleep最小单位是20ms，那么。。。刚想着，作者翻到下一页就讲到系统层的不足，需要驱动进行如何如何。唉，幼稚了下。

中间演示了个图片光照渲染，不熟悉，略过。

最后是介绍了CPU和GPU的一些演变。GPU之所以如此快就是采用了并行计算，其中的流水线(是这么叫吧？)的数量级等等。而CPU的发展开始多核化，但是是以异构系统发展(一个全功能核、计算核),以及L1,L2...我想我至多只用了L1，至于L2,L3就没细想了。

提问环节上，受到介绍的异构系统启发，我在想游戏中单场景的构造，问了个全功能核、计算核数据竞争的问题。得知还是需要汇总，关键还是看任务分配的算法；
看作者对CPU很了解，继续问了个乱序的问题。比如1,2,3,4传入，计算顺序可能是4,2,3,1，最后汇总是1，3,4，这部分当时资料没找到，一个口气问了。给出的解答是一样有个指令缓存，如果指令时有前提依据的依然要等待。

记录这段文字的时候，总觉得当时自己还问了个什么问题，但是想不起来了。。。

最后两场还是很符合胃口的，期待明天。

...全文