游戏中的物品交换逻辑抽象
如果总结一下游戏的内部逻辑，或许会让游戏变得很无趣，不过程序员大概会很高兴，比如说我。
如果把用户的各种信息都抽象成“物品”、“个数”，那么所有的游戏逻辑都是用户之间的物品交换。
为了方便描述，我来自定义一套语法表示这种交换。这里用的是类BNF语法，如果没耐心可跳过。
物品交换 := 物品描述 “=>” 物品描述
物品描述 := 物品描述 “+” 单个物品描述 | 单个物品描述
单个物品描述 := 用户 “(” 物品 “,” 数量 附加属性 “)”
物品 := 物品名称 | 物品函数
物品函数 := rand “(” 物品列表 “)”
物品列表 := 物品列表 “,” 物品 | 物品
附加属性 :=”,” “{” 附件属性列表 “}” | “”
附加属性列表 := 附加属性列表 “,” 属性 | 属性
属性 := 属性名 “:” 属性值
数量 := 数字 | 数字函数
数字 := [...]
Amazon AWS使用体验
近几个月来简单体验了Amazon AWS大部分服务，现在分享一下使用感受。
Amazon EC2
从各方面来看，EC2应该算是Amazon的王牌产品。EC2功能全面，它可以在数分钟内launch一个实例，可以（理论上）自动提升/降低机器性能配置，可以绑定EBS成为具有高可用性特质的计算核心，可以摇身一变成为ELB成为一个load balancer。这些功能非常实用，特别适合针对国外市场且快速增长的小网站，可以在前期完全不受机器约束。
EC2机器的内核在申请时指定，有很多选择，如果有闲心，还可以做一个自己专用的，我们没用这个功能，实在太繁琐了。EC2提供了完全的root权限，可以随意安装软件，由于EC2一般带有足够的硬盘空间（Large Instance就自带850GB磁盘空间），装个mysql当数据库机器也完全没有问题。
EC2最大优势是灵活，最大劣势则是性能。EC2的IO性能欠佳，当EC2机器作为mysql数据库时，系统吞吐量只能到3~10 MB/s，相比而言，在同样数据同样程序条件下，使用真实机器则能轻松达到30MB/s。EC2的CPU是多个实例共享的，一般stolen的CPU都在10%左右，对于nginx+php-cgi这样的组合，EC2高端配置也不太能撑住压力，总是CPU吃紧。
虽说EC2劣势明显，但由于互联网应用一般都很容易做到水平扩展，它的灵活性可以很大程度缓解这个劣势，不会有太大问题。不过最终我们还是放弃了EC2，主要因为今年5月Amazon云计算服务出了大量的事故，仅5月头两周，在同一个机房就出了5起大事故，我们在3起事故中受影响，每次都很不幸的都是单点EC2出问题，最长的一次在高峰期中断了6个小时服务，损失巨大。最郁闷的是，到了5月下旬，有一台跑数据库的EC2机器莫名奇妙磁盘损坏，还有一台莫名其妙的无法ssh，让我们感觉越来越不靠谱，于是决定逃离。云计算的可用性始终值得担心。
EC2的价格相对传统IDC要贵不少，按高端机器High-Memory Double Extra Large每小时1.2US$来算，每月就要花864US$，再加上流量费，很容易达到每台服务器1000US$的水平。
Amazon RDS
RDS是一种数据库托管服务，通过RDS toolkit可以很方便的创建RDS实例并立即使用。据Amazon帮助文档说，RDS的数据库软件维护、升级、优化的工作全部由Amazon负责，用户只需要使用功能即可。
可惜，RDS纯粹是一个看起来很美的东西。首先是RDS为了同时支持异构的数据库，牺牲了很多灵活性，例如，因为无法访问RDS的物理机器或存储空间，使得跑着mysql的RDS实例连记录slow log都成了难事，更别说什么err log，出了问题只能一抹瞎。如果要获取bi/bo这样的数据需要使用专用的RDS toolkit完成，很难集成到现成的监控工具里去。其次，RDS底层使用的是类似于EBS的网络存储，其IO性能差到一个令人发指的地步。一个很感性的数据是：使用RDS Double Extra Large DB Instance跑mysql时慢查询占1%，同样数据转到EC2 High-Memory Double Extra Large实例后慢查询降为0.01%。最让人无语的是RDS价格高于同等配置的EC2+EBS价格，每小时都贵超过0.3US$，相当于贵25%，省下来的钱用来雇专业运维人员绰绰有余，而且RDS功能和灵活性还远弱于后者，不怕折腾但怕花钱的人不建议选择RDS。
如果执意要使用RDS，那么一定要注意RDS没有固定IP，每次重启实例（或过一段时间）都会变，程序连接的时候最好写域名，当然，这会损失性能。此外，RDS可用性也没宣传的那么高，我们5月最先挂的就是RDS实例，一挂就是好几个小时。
Amazon S3
S3是少有的看上去物美价廉的东西，只需要花几美元就可以拿到几十GB空间，对一般的互联网应用来说绰绰有余。
S3提供丰富的API和工具上传文件。对firefox用户来说，有一个专门的S3扩展可用，可直接上传本地文件。还有一个s3curl.pl工具，可以用命令行传任意文件，可以方便的做到自动化。
S3存储的文件可以直接通过域名从外网访问，不过比较郁闷的是文件尾部不能带“?“，一切基于文件名后面加随机串的避免缓存的做法都会失效。
Amazon CloudFront
CloudFront是一种CDN，它的访问速度据称不错，我们并没有实际使用过。
我们不使用CloudFront主要是因为很难控制文件在CloudFront中失效。根据我们的程序结构，我们需要在静态文件后面加version信息强制用户在必要时更新到最新版，现在由于CloudFront既不能手动invalidate某个文件，也不能保证CloudFront上缓存的文件及时更新（可能更新会花24小时），我们需要修改现在的策略才能使用到它。
CloudFront是根据用户所在网络来收费的，对于国内，CloudFront使用的是香港价格，贵于美洲和欧洲，不太划算。对于欧美市场，我也不清楚欧美CDN的价格究竟如何，无法比较。CloudFront在欧美的流量费用与EC2相同，不过由于没有按小时计的租费，总体价格会比EC2提供静态文件服务便宜很多。
Amazon CloudWatch
CloudWatch是一个性能数据监视器，对于这个东西我只能说太小儿科了，没看出来有什么实际的用处。一旦开启CloudWatch，Amazon就会帮忙收集开启了这个服务的instance数据，包括CPU和IO信息等。可惜，数据精度不高（大概是几分钟一次统计），数字也只是个大概值，能看的数据也很少，无论对入门者还是高手来说，都不能带来太多价值。
CloudWatch看上去比较好的是可以配合EC2/EBS/Load Balancer toolkit做一些auto scale的事情，自动提升/降低EC2/EBS参数，还可以（理论上）自动launch新实例。这些东西我们都没尝试过，有兴趣的同学可以试试。
CloudWatch价格不贵，一台机器就只用0.1US$而已，不过一般还是不建议开，装一个其他监控软件更靠谱。
Amazon Premiun Support
Premiun Support包括即时的电话支持和一个专有的提案系统。从服务质量上来说，Amazon的客服总是很热心，响应速度也很快，专业素质也不错，很不错。
Premium Support非常贵，简直是抢钱。它是按照每月总花费来算价格的，最多增加总花费的16%，最少为无限接近于10%，代价十分明显。
结语
Amazon AWS提供丰富功能，还有不少toolkit和API，适合小应用使用。对于要求较高性能或较低成本的应用来说则不太适合，折腾一下IDC应该达到更好效果。
amazon云计算服务初体验
本周第一次实际使用amazon的云计算服务，主要包括Amazon Elastic Compute Cloud (EC2) 和Amazon Relational Database Service (RDS) ，有一些感受先记在这里。
先说说EC2。它很类似网上的虚拟主机服务，拥有root权限，可以完全控制上面的服务，默认拥有一个对外的dns地址，并可以开放80和22端口。
从性能上来说，EC2的表现很不错。从功能上来说，EC2最大的限制就是端口和ip。对于端口，80和22只能满足最基本的web应用，如果要使用自定义端口/协议的socket方式提供服务，恐怕就比较麻烦了。对于ip，默认每个EC2服务器都是动态ip，最安全的方法是用自己的域名做CNAME转发来对外提供服务。有一点需要注意，EC2服务器的外部dns和ip是绑定的，一旦给它换ip，例如为它花钱绑定一个固定ip，它的外部dns也会变，这就需要修改自己域名的CNAME记录。可麻烦就麻烦在EC2实例换了ip后立即就换外部dns，而普通dns缓存则可能会很长，这将造成在换ip的这段时间内服务可能不稳定。为了长治久安，还是一开始就申请一个固定ip会比较稳妥呢。
EC2对外部流量收费，内部不收费，或者在跨区的内部服务器通信时收非常少的费用。EC2服务器单机流量上数十MB/s不成问题，不过随着提供服务的EC2服务多了起来，我们自己搭的load balancer服务器已经有点力不从心，看到EC2有专门的load balancer服务，并且还挺便宜，下周一定试一试。
相比EC2，RDS则非常的不自由，它不能用ssh登录，数据库程序也不能控制版本，还有不少数据库配置不能改。如果在RDS上使用mysql+innodb，那么有不少不爽的地方：
innodb_data_file_path配置不能自己控制。RDS会将这个设置为ibdata:10M:autoextend，且不能改，这对高并发的读写会造成问题。
没法在本地以文件方式保存slow log。
无法直观的监控机器性能，只有一些RDS专用的命令行工具能得到一些实时的数据。
无法对操作系统进行进一步调优，甚至都不知道底层跑的是什么操作系统。
不过RDS也有一些好处：
存储空间可以无限增长。就像flickr的相册一样，每月都有一定的增长额度，总存储空间可以无限增加。
数据安全性可以保证，可以方便的制作snapshot和完整备份，备份所花的存储空间只要不大于每月增长额度就完全免费。
amazon会负责数据库软件的安全性，给它及时打补丁。
综合来说，RDS提供的控制手段有限，不太适合对性能有较高要求的应用。从实际是用来看，同样的程序和网络环境之下，Double Extra Large DB Instance上的mysql+innodb明显慢于Double Extra Large EC2上自己安装并优化的mysql+innodb，一个典型的数据是：使用前者，慢查询比例是1%，使用后者，这个比例立即降为0.01%。
放弃RDS也就意味着放弃RDS的各种好处，为了弥补这个不足，可以为EC2申请Amazon Elastic Block Store (EBS) 。EC2+EBS就和RDS没什么两样了，只是管理起来还是有点费神，综合的价格应该和RDS差不多。我这里还没有真正尝试过EC2+EBS的方案，以后等存储出现瓶颈了再说了，现在EC2自带的850G存储绰绰有余。
amazon的服务还是挺让我满意，特别是phone support反应很快速，服务人员也挺专业，挺好。不过我并没有其他云计算服务的使用经验，没有比较，也不清楚amazon云计算在业界究竟出于何种地位，这个以后再慢慢去了解吧。
一个时代的终结
明远正式宣布离开，他的时代终结了。
我在明远手下做事也有一年多了，回忆一下，我们从未有过正式的交谈，他大概也不会认识我。他是我老大的老大的老大，他是一个产品人，他喜欢足球，而我只是一个沉默的程序员，对任何体育运动都不感冒，我们没有聊头。不过我还是得感谢他，在我看来，是他让我在工作中找到了久违的激情。
明远很喜欢在季度沟通大会上不断激励我们的创业激情，讲述自己对未来、对竞争对手的分析，鼓励我们勇于接受挑战，实现心中理想。他的演讲很有特点，语调平缓，语速适中，整个过程很少带有废字，逻辑十分清楚，能用平淡的语言激起他人共鸣。他在演讲方面的老成与他的年龄很不相称，哪看得出他比我还小啊。
在团队活动中，我印象最深的是有次部门全体员工集体出游的时候他穿着短裤拖鞋混迹于员工之中的形象。明远没有架子，在团队活动中他就是个小孩，不修边幅，很不起眼。这个样子的明远才是最真实的，而他的内心也许根本没有那么成熟，站在讲台上的那个过分成熟的身影终究会成为限制他自身发展的禁锢。
由于种种我不知道的原因，明远选择了离开，有点突然。东宝为明远在公司这段惊心动魄的创业历程写了篇《为了即将忘却的纪念》，可惜我只经历了这段创业旅程的最后一段。（东宝的文章已经看不到，可以看其他媒体的转载）
明远，愿你在未来能永葆激情，创造更大辉煌。我看好你。
淘宝视频和淘宝电子杂志：这葫芦里卖的什么药
淘宝最近推出了两个网站，淘宝视频和淘宝电子杂志，很有点不务正业的样子。
通过这两个网站的内部链接可以发现，它们都是淘宝与其他网站合作的结果，并不是淘宝自己提供的内容和技术。淘宝视频的内容来自激动网，淘宝电子杂志的内容来自ZCOM。淘宝只是提供一个整合的首页，在内容旁边放一些淘宝的牛皮癣广告，真正的流量则直接让给了上述两个网站。从现实好处来说，这两个本不著名的网站占了大便宜。
激动网和ZCOM为淘宝定制的网页都可以用淘宝账户登录并发表评论，这实际上意味着淘宝在变相的拓展产品线。对普通用户来说，打开淘宝视频或电子杂志首页之后，只要网页风格和登录方式统一，那么就相当于没有离开这个网站，他们不会管域名是否已经改变。未来如果淘宝真的想涉足这两个领域将变得非常自然，现在的做法只是在布局，在树立口碑。
毫无疑问，淘宝视频和电子杂志可以增加用户黏度，让用户不用离开淘宝就能找到所需要的东西，不知道这是否也是大淘宝战略中的一部分。之前淘浆糊出来的时候，就已经可以看出淘宝想利用SNS增加用户黏度的想法，现在再加上这些娱乐元素，将会继续朝这个方向发展。
从某种意义上来说，做这两个网站是淘宝的悲哀，也是中国互联网的悲哀。中国网站鲜有专注者，阿里巴巴集团一直都不专注，但如果单看淘宝网或许还算好，至少都在围绕着购物这件事情不断发展。但随着这两个网站的加入，纯粹为吸引用户的娱乐元素越来越多，淘宝越来越像门户，不知是否会变成第二个QQ.com。莫非是淘宝内部已经觉得自己在购物平台方面已经无事可做了？大概是他们的产品和研发都没空看淘宝社区吧。
究竟淘宝在这两个网站上能玩出什么花样还需要时间来证明，我等着。
Twitter Lists：Twitter新玩法
Twitter最近大规模的公测Lists功能非常有趣，跟其他平台中tag、好友分组等功能类似又不相同。
Twitter里面本没有好友的概念，所谓的follower和following也只是一种订阅关系。这个lists功能并不限于在自己的follower和following之中使用，可用于任何一个用户而不用建立关系。
Lists也可以被follow，follow之后就可以看到list里面所有用户的更新。
在这里我有一个有趣的想法，有了lists还要follower和following关系干什么？特别现在twitter用户数不断疯狂增长，对于一个twitter新人来说，该follow谁是一件非常头痛的事情。有了lists之后，新人只需要关注名人和名人创建的list就可以开始twitter生活了，这比原来好上很多。
想必twitter以后会推出热门lists，甚至于对lists进行评价和打分，增加lists的用户参与度，把lists变成一个新媒体的入口，赋予那些有话语权的著名twitter用户更多舆论导向的权利。从此以后，@Fenng大概也不用再来推友推荐计划了，只需要创建一个list然后宣传这个list就可以了。
从体验上来说，管理list里面的用户是非常困难的事情。
点击list的edit链接之后得到的是这个浮动层，不过并没有管理用户的选项。
如果只是删除用户那还好，只需要点击following链接，然后把用户从list中去掉。不过如果要新增用户就必须从find people或者其他用户的首页点击，在list界面上却完全找不到类似于add的链接。其实twitter只需要把find people包装一个接口放在list管理界面就很好了，只可以他们还没想到。
最后说说怎么推销自己的list。Twitter提供了一个Tweet about it的入口操作，同时还可以简单的使用@功能引用list，这个很赞。例如这个百付宝员工的list：@baifubao_news/staff
最后的最后，请不要问我怎么顺利的上twitter，我不知道，我只是机缘巧合的得到了twitter的信息并找到了上面的图而已。:P
Opera Unite：怎么看这个玩意也不会成功
标题说的是直白了点，不过是心里话。使用Opera Unite以后，真的觉得这个公司的努力怕是又要打水漂了。
首先，Opera Unite还在玩Web 2.0概念，这其实已经有点过时，粘度有限。特别是Opera的用户还属于小众、互动的圈子不够大的情况下，Unite的新鲜劲过去以后，使用者的孤独感会逐渐产生，最后就会使得Unite的互动圈子进一步萎缩、甚至死亡。
其次，Unite本身其实与浏览器关系不大，它更像是Opera的插件平台，能帮用户完成很多与浏览器无关的事情，如果Opera把这个当作它的killer feature，那恐怕就押错宝了。从Unite的扩展性上看，它无法与Firefox的插件体系相比。从功能上看，Flock这样的社会化浏览器就能在功能上轻松仿制Unite。
最后，Opera Unite与手机和其它设备互动的想法很好但很难实现。技术难度是显而易见的，在客户端上面动脑筋实在比Web App难很多。Opera这个公司能有这么大的号召力去推动大家在Unite平台上写应用么？如果没有，他们自己有实力搞定那么多个平台么、写出那么多引人入胜的应用？这个非常值得怀疑。同时，Unite在前期是不会有什么盈利模式的，Opera必须持续砸钱供养整个团队，并且做很多必要的宣传，这种运营成本肯定不低。那么困难同时还得不断花钱，Opera公司是否能够一直坚持也值得观察。
Opera公司10年来占有率一直在1%上下徘徊，他们的营销能力实在令人怀疑。我对他们这次放的这颗卫星不抱太多希望，静观其变，静观其慢慢消亡。
