转自：http://blog.appleap.com/?p=29

2008年被誉为中国互联网界的开放年。这一年中，校内、51、聚友、康盛创想、中国雅虎 等，都跟随facebook的脚步，各自推出独立的开放平台体系；谷歌也在积极推广自己的开放标准，天涯、一起网、MySpace都搭上了 OpenSocial的大篷车，国内也出现了一大批应用开发者和奇矩互动、热酷、Apptz等专业的应用开发公司。

但是，在繁荣的表象背后，有一些现象却值得我们关注：facebook自从2007年7月推出f8开放平台以来，到今年7月24日的f8大会，共吸 引了大约40 万开发人员为其创建了大约2.4万个应用程序，并且这个数字还在飞速增长之中。在中国，以最早推出开放平台的校内网为例，在将近半年的时间中，共吸引了 650名开发者为其创建了852个应用程序（数字来源于AppLeap.com）， 并且最近两个月的时间内应用数量增长缓慢。在美国，一些优秀的应用开发公司能够获得风投的青睐，而中等规模的应用开发者可以靠广告收入养活自己，而在国 内，应用开发者在享受了作品上线后，用户快速增长所带来的短暂狂欢之后，要开始面对昂贵的运营成本，以及缺乏有效营收手段的现实。校内、51开放平台的用 户条款不仅限制多多，而且朝令夕改，让许多应用开发者都感到无所适从，缺乏长期的安全感。最近两个月以来，随着经济形势日益严酷，开放平台似乎也步入了寒 冬的季节。

开放，忽悠了谁，又成就了谁？到底是什么原因导致开放平台没有像预期的那样成为开发者的盛宴？

来自平台方面的原因

今年7月8日，校内网举办新闻发布会，高调宣布开放平台的推出。在开始的一段时间中，新应用像潮水般涌入，校内网宣称每天提交审核的应用就有200 多个。但是，校内网出台的关于第三方应用程序开发与管理的协议，成了开发者口诛笔伐的焦点。在这份协议的第一版中，规定了第三方应用不得嵌入广告，不能引 导注册其他网站和包含跳出外站的链接，不能涉及招聘和旅游等与校内未来扩展方向相关的领域，甚至还规定了应用的产权也归校内拥有。虽然后来校内网对协议进 行了大规模的修订，去掉了一些明显不合理的条款，但从这件事情上，可以看出国内的平台经营者从一开始并没有完全摆正自己的心态。

从技术角度，对比facebook f8，可以看出国内开放平台在技术细节上的简陋。facebook一直在不断完善技术框架，提供更丰富的标记语言（FBML）和开放更多的API，努力给 应用更多发挥的空间及更紧密的嵌入体验。反观国内，开放技术标准的更新速度缓慢，校内最近一个XNML标签的添加还是在9月14日。举一个小小的例 子，facebook允许iframe型的应用通过代理的形式控制父窗口的尺寸，从而达到与父页面无缝整合的目的，这一点功能，国内任何一个平台目前都没 有提供。facebook提供的开放API共有69个，比51和校内加起来的两倍还要多。或许他们认为这些细节无足轻重，但态度的缺失使细节积少成多，用 户体验的差距就慢慢显露了出来。

来自应用方面的原因

校内开放平台的推出，让无数开发者的热情被点燃，他们的创意和激情终于找到了释放的出口，第一批应用的创意大多取自facebook，还有一些是通 过hack flash源码来实现的。国内应用开发者中有很多是刚刚毕业或在校的大学生，应用上线后用户快速增长所带来的新鲜感过后，就会因为运营压力的增大和收入手 段的匮乏而导致热情迅速冷却，一些应用经常出现无法访问的现象，这在一定程度上影响了校内网的整体用户体验。平台和应用在开放生态链当中本来是共生的关系，伤害了对方，最终也一定会影响到自己。

另一方面，对于国内的应用开发者来说，在当前比较恶劣的经济环境之，像rockyou和slide那样获得风险投资非常困难，实现收入的最重要手段 只能是广告。在广告市场相对比较成熟的美国，基于社交网络的广告联盟有很多，广告客户对于新媒体的尝试热情比较高；而在中国，社交网络对广告主的吸引力还 不足以支撑起一个商业模式，应用只能依靠嵌入adsense广告来赚钱，这种低效的方式远远不能将社交媒体的商业价值最大化，也很难养活得了专业的应用开 发团队。很多开发者把应用开发看成是掘金的手段，缺乏长期运营产品的心态，希望能以最快的速度推广和获取收入，这也导致应用开发的导向过于娱乐化，复制成 本很低且不具有不可替代性。高质量应用的缺失使应用开发者相对平台的整体议价能力非常弱。

中国SNS发展的客观环境

facebook和myspace是美国乃至世界上最主流的两家社交网站，在上网人群中的到达率非常高。在中国，SNS的竞争模式演变成了“群殴 ”，校内网、51、开心网等各占据一个细分市场，但任何一家都还不具备像facebook那样庞大的用户基数和强势的影响力。留给应用开发者的施展舞台本 身就不够广阔，再加上各平台之间对用户群的激烈争夺和相互渗透，使他们没有足够的精力持续投入到开放平台的建设中去。

理想中的平台和应用关系

平台和应用之间，不应该是老板和打工者的关系，而应该是在开放的环境中共同生存和利益共享的关系。作为平台，应该注重于建立和维护良好的开放生态环 境，让应用形成优胜劣汰的竞争机制。平台本身是规则的制定者，不适合再成为应用质量的裁判，而应该让用户用脚投票来决定。诚然，由于应用运行与平台之上， 应用的体验平台也需要负责，但平台应该将自己定位于监督者的角色，不轻易越过雷池一步。我们看到facebook在一年多来也对一些应用进行了打击，但他 们针对的是那些试图用非常手段获取超额利益，对整体生态环境造成破坏的应用。

开放平台走向何方

在一个缺乏诚实和信任的开放环境中，无论平台还是应用都难以得到井喷式的发展。中国的开放平台，经过了半年时间的发展，没有迎来一个欣欣向荣的开放时代，却走到了今天这样一个重要关口：发展或是沦落。

中国的开放平台行业，急需新鲜血液的注入，需要一个能够真正以开放的心态重新制定游戏规则的重量级平台，需要重视用户体验、不急功近利、更加成熟的应用开发者群体，需要一批认同社交网络和口碑营销价值，敢于尝试的广告主。

我们看到，在最庞大的白领社交群体中，正上演着真假开心网的PK大战，从宠物认养到养眼的真人秀，从争车位到抢房子，平台们已经把应用的开发的想象 力发挥到了极致。但是，用户的需求是更加多元化的，谁能够驾驭第三方开发者的智慧和想象力为自己服务，也许就能在这场残酷的PK大战中觅得先机。无论如 何，我还是愿意相信，互联网和社交网络最终将循着开放的道路向前发展，与其顾虑重重，不如应难而上，这毕竟是一次难得的历史机遇。

以下是转帖内容。

我是2005年毕业的，偶尔来这里看看，不常灌水。
今天来随意写下一些，如果对各位有任何的帮助，是我衷心所愿。

1。考研与就业：
2004年的暑假，我和大多数人一样，艰难的抉择，究竟是考研还是找工作。
凭良心说，如果我选择考研并不是因为我真得很想读书很想深造，而是我害怕接触社会，
想再窝在学校几年。
所以，虽然我非常不喜欢我这个专业，我还是决定做个鸵鸟，情愿去干我唯一最擅长的事情-读书。
现在想起来，当时太不了解自己。呵呵。
我们寝室4个女生，两个决定考研并且每天早出晚归，整天也见不到人。
我决定效仿她们，每天大包小包的拎着啃书。
不喜欢终究是不喜欢，2个月以后，我在镜子面前看到一个憔悴的自己，
想起我这些日子以来的生活状态，究竟是为了什么？我不是一个聪明的小孩，
我没有本领过目不忘，我又没有自己想象的那么勤奋，我怕这怕那，天哪，忽然觉得，自己一无是处。。。

2004年9月，我很没志气放弃了考研。
两个字，怕苦。

2004年9月，我在51job上填了我完整的信息，等待工作的降临。
2004年9月中旬，我的第一份实习经验开始了。。。

2004年9月中旬，一个很甜美的声音从我的手机传来，约我在徐家汇美罗城面试。
我无比激动地。。真的是我比激动地。。。去借了正装，提早了半个多小时到。
到了以后我才发现，是一家人寿保险公司。
那个面试我的经理居然是同济毕业的，
有些人就是有这种魅力，寥寥几句话，就让周围的人围着转。
像我这样没见过世面的人，轻易的，魂就被勾走了。
在我走出那里的时候，我已经答应要留下来做做看了。
我没有考证，所以不可以接单，我就是在里面接触他们是怎样工作的。
接下来的1个多月里，我亲眼看到一群斗志高昂的人在没有任何签单以后是如何被经理骂的狗血林头。
我也亲眼看到，上海滩上一些有钱人的嘴脸。
说实在的，以前我是鄙视做保险的人的，我认为他们素质低下只会粘人。
现在，我对他们多了一份理解。
并且，他们之中确实有就算是放到任何行业也光彩夺目的精英。

也许是看出了我不是这块料，一个月以后，我被委婉的驱逐了。
呵呵。我是高兴的走的，走了以后还在徐家汇逛了一圈。
第一次社会经历，让我很真实的触摸到了钱和人的关系。

2004年10月中旬，我迎来了第二次实习，
我的一个同学的姐姐，在某知名相机公司做广告的，很急要找人来帮忙处理一个他们举办的赛事。
一行找了好几个想我这般年纪的小孩，做的工作无非是更新数据库之类的。
我当时是抱着希望，最好做着做着就能留下来的。
结果两个礼拜以后，赛事结束，我被驱逐了。。。
我拿到了600多元钱，因为我是她弟弟的同学，她算是特别有待我，给我开了一份实习证明。
上面写得我是如何如何得好，呵呵，我当时心想，我有着么好？这么好你怎么不留我？！
2004年的10月下旬，
我迎来了最好一次实习经历，这次实习决定了我的工作。

大家都有这个经验，网申一般没用。
我在51job上申请过n多网申，统统石沉大海。
有礼貌一点地会给我回一封信，说我的资料已经到了数据库，他们会慢慢核对。。。
所以我真得确实没有印象，我曾经投过这一家公司。

某天早晨当电话通的那头传来，她是某某名气很大的公司的HR的时候，我确实是呆了。
因为我根本不记得我投过什么职位。
我一路支支吾吾的，居然她也没说什么特别的，最后报了一个很远很远的地方的地址，叫我明天去面试。
我挂了电话以后想，这种公司我是肯定没戏的，那就去一次算是锻炼一下我的抗打击能力。
第2天面试，没有程序考卷，没有英语面试，什么都没有。两个经理坐在会议室里面，一个在打电话很忙的样子，一个笑容可掬。
那个笑容可掬的就问了一句话，你在XX公司（就是那个相机公司）实习过对么？
我点点头
OK, 就是你了，我们这里时薪10元钱，三个月，有问题么？
没问题。
好，明天来上班。
走出去的时候我彻底晕。
接下去的日子我不太记得是怎么过的，就是每天很忙，我就是一个小秘书，什么打杂的都干。

详情查看 »

要启用 rewrite 和 .htaccess 设置，除了开启 mod_rewrite.so、AllowOverride All 配置外
LoadModule rewrite_module modules/mod_rewrite.so
AllowOverride All

还需要注意 Options 的设置

默认设置是：Options Indexes FollowSymLinks

如果改成以下设置后，就会出错
Options Indexes FollowSymLinks MultiViews Includes    （出错）

如果要启用

目录浏览 MultiViews
服务器端包含 Includes （<!–#include virtual=”top.htm” –>）

可以考虑使用
Options All

作者：老王

问题：主从服务器表类型的选择

一般的共识是主服务器使用innodb，从服务器使用myisam，以便各尽其能。

问题：主从服务器字段类型的选择

字段类型对于分页等操作有很大影响。主服务器一般是innodb，因为不涉及查询，所以可以使用varchar等来存储字符串来节省空间，从服务器一般是 myisam，因为涉及查询，所以必须在char和varchar之间仔细权衡，没有varchar, text, blob字段的表是静态表，反之是动态表，静态表的检索效率要比动态表好若干倍，一般来说，所有涉及大结果集的查询都应该尽可能保证在静态表上完成，这里 说一个例子：比如说常见的articles表有title(varchar), body(text)等字段，在做文章列表的时候，因为不是静态表，所以查询不会很快，下面开始重构解决方案：把原来的articles表拆分成 subjects表和contents表，title字段设置为一个足够的char类型放在subjects表里，body字段还保持是text类型放到 contents表里，subjects和contents表之间的关系是一对多，这样，顺带着也方便的实现了多页文章的功能，而且更重要的是在查询文章 列表的时候，操作都是在subjects静态表里完成，效率肯定会比前一种方案提升很多。

问题：主从服务器NOW()函数造成数据不一致

假设在主服务器上执行一条INSERT …. VALUES ( …, NOW())，那么在从服务器上也会同样执行一条的SQL语句，但是一来主从服务器各自的时间设置可能就不一致，二来主从服务器间的SQL同步也可能存在 时间上的的延迟，这样，NOW()在两台服务器上的结果就可能不一致。解决方法是显而易见的，就是不要使用NOW()，时间的计算在应用程序里完成。这里 介绍一个额外的小技巧：在PHP里如果想获得当前时间的时间戳，不要用time()，而应该使用$_SERVER[‘REQUEST_TIME’] （PHP版本大于5.1有效），这样少做了一次系统调用，更有效率。

问题：主从服务器读写分离时读操作失败

先重现一下问题：比如说添加一条新数据，添加成功后根据last_insert_id跳转到新添加数据的浏览页面。在此过程中添加新数据的操作是在主服务 器上完成的，浏览新数据的操作实在从服务器上完成的，不过由于主从服务器间SQL同步存在延迟，所以当使用last_insert_id在从服务器上查询 的时候，从服务器很可能还没有还没来得及同步到此记录，所以读操作失败。解决思路也不复杂，在代码里加入一个缓存层（可以使用memcached），新添 加的数据都顺手放到缓存层里一份，新数据的读操作也先查询缓存层，这样就不会再有读操作失败的问题了，当然删除或者更新数据的时候也要顺带着处理好缓存数 据，可以使用观察者模式来搞定。不过这样缓存方案只限于读取单一的记录，对于读取列表的记录的情况，则是无效的。

问题：主从服务器索引是否有必要保持一致

一般都是利用主从服务器完成读写分离，从服务器上进行读操作，主服务器进行写操作，这样的话，主服务器上仅保留主键，外键，唯一索引等必要的索引即可，以 便保持数据合法性，而对于那些原本用于优化SELECT操作的索引，可以全部删除，如此的话主服务器的写操作效率会提升很多。

转自：http://hi.baidu.com/thinkinginlamp/blog/item/5d72dd5469b1885fd0090633.html

如题所述

例，重写规则为：

RewriteRule ^show/(\d+)(/?)$                show.php?id=$1

当地址栏输入 http://www.d5s.cn/show/18 的时候，

重写规则，写在.htaccess中，

$_SERVER['PHP_SELF'] = /show.php?id=18

重写规则，写在httpd.conf中，

$_SERVER['PHP_SELF'] = /show/18

如果有需要从 $_SERVER['PHP_SELF'] 变量中取值的时候，需要注意这两者写法的区别。

以下是前一段时间，在UCD讨论组上面，和一些朋友进行的讨论。

现在整理出来和大家分享一下。

——————————————————————–

无影说：

程序员总是想尽量精简或者是按照自己的程序编写方便来完成一些功能，有时候就是，为了完成功能，并没有考虑到产品设计上，未来可能会发生的变化，等到变
化来临时，又找出借口来说，这个功能会影响XXX，无法做，或者很难做，以此来刁难。

做产品的时候，总是想一开始就做一个大而全的东西，别人有的我要有，别人没有的我也要有，总是先模仿同类的其他网站，这样很难有自己的特色。

程序员做的不是自己想做的，所以他们总是消极怠工，或者是代码考虑不周全，留下了未来的一大堆隐患，或者是本来可以很快完成的任务，他说是很复杂，这个
需要做很久，以此来表达自己的不满和抱怨，反正我又没打算一直干下去。

如果是程序员自己给自己写程序，就不会这样，开发速度很快，考虑也很细致，倾尽自己所能，以表现自己的技术高超。

或许是技术团队，没有一个顶尖的leader来领导程序员？
或许是没有一个优秀的产品经理来让程序员信服？
还是有其他一些矛盾？

好像每个公司，都有一些和程序员的矛盾，这个如何能尽量避免呢？

moneya说：

我想可以让部分关键程序员前期介入，参与产品需求分析和设计。这样的设计也兼顾了
很多实际的条件，更有实现的可能性。程序员的参与度高，对需求的理解也到位些，责
任感、成就感也强吧。

liyi2008说：

是有这样的问题，我们现在的做法是，产品设计阶段就让技术人员参与，然后经过多次和技术人员讨论形成最终的开发文档，技术人员根据开发文档制定开发计划，这样的好处是不会让技术人员觉得产品与我无关，没有体现我的价值，其实技术的前期参与也可以提出很多建设性的建议。

另外，对于不同类型的程序员需要不同的对待，有些程序员在产品开发过程中有非常多的建议和想法，对产品的控制欲望很强，这样的程序员需要我们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发，对产品本身没有太多的想法，这样就需要我们把文档写的尽量详细，因为如果有考虑不周全的地方，他们也会按文档开发。

总之，遇到这样的问题还是多找自身的问题，充分调动大家的积极性把产品做好才算一个合格的产品经理

张锐说：

同意。做好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让所有人都发挥其最大的力量。所以，我觉得“控制”对产品经理来说至关重要。

设计的前期我觉得要经常和技术人员沟通，可以让一些对设计有兴趣有想法的开发人员加入进来，他们可以从技术可行性上给予帮助。不过有个问题就是，技术人员也许不懂UCD，而且他们经常是从程序的角度去思考和设计产品，这个时候就需要我们去把握和掌控产品设计。

有些程序员对产品设计可以说丝毫兴趣没有，他们只管自己的代码是否漂亮，这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。

wangjuea说：

顶一下liyi2008，对于不同的研发，是要有不同的协调方法。
我还有一个个人的小经验，就是不仅要和研发的同学协调好，更应该先和测试的同学搞好关系。在我的工作圈子里，我了解到大多数研发对于产品消极的处理都是与测试team的考核有直接关系。
所以，我平时会和测试、研发同学经常一起沟通，最大的目的就是期望大家在遇到问题的时候首先能一起了解问题，而不是互相推卸责任。
当然，在这个过程中PM要把握测试的纬度和实现的程度。

无影说：

产品、设计、前端工程师、程序员相互之间责任的推卸是一个很严重的问题，随着分工的越细，这种矛盾有些时候就越明显，但是不分工又没有办法达到相对的专业化。身兼多职的人，就会有所抱怨。

和产品打交道最直接的不知道是不是设计师？

产品 -> 设计师 -> 前端工程师 -> 程序员 -> 测试人员

整个的流程是并行，还是串行有交叉？我认为应该整个Team对项目都有所理解，而不是仅仅是各司其职。

同意张锐说的”这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。”

不过产品的改动或变更，直接影响到，后续所有人的变化，这也可能是大家比较抵触的原因，但是有些时候，某些改动又是必须的。

整个Team成员的相互认知，认可，对矛盾的激化能起到很好的降温作用，多沟通是一个很好的解决办法，只是这种沟通是通过会议，还是私下的午餐、上下班路上、闲聊，还是其他方式呢？

有时候，程序员的一个建议，产品无法拿出很好的建议来反驳，但是产品又不想按程序员的想法来做；
或者是程序员提出一个改动，可以省下不少的开发时间（无论省下来的时间，他干什么了。），同时对产品的影响不大，他都希望产品能做出让步，如果这个时候产品说，你必须这么做，很强势，程序员就会有抵触情绪，对于这种程序员如何沟通？

liyi2008说：

“有时候，程序员的一个建议，产品无法拿出很好的建议来反驳，但是产品又不想按程序员的想法来做；”一般遇到这种情况我会根据建议用原型开发工具把建议用原型实现，然后和程序员一起站在一个使用者的角度去走流程，看看是否合理，这时可以多找几个人，马上大家就会发现哪种方案更好，我们公司主要做手机软件开发，一般程序员的建议可以反应到产品的表现层，所以这个方法好用，如果原型开发可以实现一些交互效果会更好，但是不知道这个办法是否具有通用性。程序员不是我们的敌人，不要总想着驳倒对方，如果大家都能站在最终产品的角度很多问题都会解决，这需要我们做产品的多去包容，明确自己的的最终目标是什么。

j.chen@oocl.com说：

如何与程序员沟通有时候是一个相当棘手的问题，不管是UI guideline得制定还是实施过程中，由于UI的一个决定可能需要程序员大量工作来解决，碰到比较强硬的程序员就不得不要求PM来进行支持，但是这终究不是完善的解决办法，完善的解决办法是，对于一些道理很明显而程序员出于自身利益的考虑而拒绝合作的可以书面详细列举利弊直接要求PM来支持你UI的工作，而对于两难选择，可以通过建立目标用户群来反馈用户的意见，这个是程序员永远无法反驳的，当然有时候用户群可能会站在程序员这一边，我们自然以用户意见为最终指导，起码可以循序渐进。真正重视用户体验的公司是会支持你建立目标用户群并进行Usability调查的，而这也是我们很多UI 目前缺乏的经验。希望大家能多多共享这方面的实际经验。与用户站在一起才会使软件真正为人所称赞而不是成为用户发泄怨愤的替罪羊。

张锐说：

恩，我就碰到过程序员在设计上坚持自己的建议，这个时候最有力的说服根据就是用户反馈—一个以目标用户群的可用性测试结果。

不然就只能是高层定夺了

ronaldo说：

我也经常碰到这样的问题。
这样的问题不仅仅发生在产品和技术之间，同样也会发生在市场和产品之间

我觉得在流程上应该可以解决一部分问题，在形成产品相关文档的时候，比如MRD，PRD，这些文档出来后，可以跟市场部门的运营计划一起讨论，或者产品
部门内部讨论PRD的时候，可以让技术人员参与进来，这样其实在产品需求确定的过程中，就同时考虑了产品运营需求和技术调研，也能让市场和技术的同事更
有了解产品本身。

在合理的流程下，还需要的，就是产品经理对产品的把握和控制了，产品经理一定要考虑到多方面的因素，至少在这个团队里，你就是这个产品的专家，你需要说
服你的同事怎么去做这个产品，需要提出运营的建议，需要及时的跟进，改进产品。不管技术人员怎么怠工，或者思想怎么懒散，只要产品真正是在向好的方向发
展，比如是在赢利，或者使用人数是在增加，或者其它相关数值是在大家的努力下一步步上升，那么这就是一个成功的流程，大家合作就是成功的。相信有过一两
次这样的成功合作的经验，以后，技术部门的同事们也不会再消极怠工了，对于代码的热情也会一步步提起来。市场部的同事也一样，对于产品来说，所有与产品
相关的人就是一个团队，产品经理需要很好的去调动大家，使产品的开发过程变成一种良性的成长过程，只有这样，才会越做越好。

赵宁说：

这个问题我的做法：
1 PM与RD本就应该关系非常密切，如果PM和RD关系不好，那只能说PM沟通交际能力不过关，
问下自己：和RD交往多不多，经常一起吃饭吹牛不，别说作为PM你连交际费都木。

2 RD有一个惯性：就是如果PM不懂技术，他就会有点瞧不起你的想法，所以嘛，我都十分关注技术，
对技术也很熟悉，公司很多小工具，小程序都是偶自己开发的，偶虽然不是一个优秀的CODER，但是
对技术了解很广泛，这样你经常和技术交流，其乐融融载，还会有啥矛盾，当然让技术参与产品前期
是非常必要的。OVER。。

刘丰说：

良好的沟通、充分调动大家积极性都是很有必要的。但是问题依然会出现，我们如何解决？

下面有一些工作心得与大家分享，FIY。

或许是技术团队，没有一个顶尖的leader来领导程序员？
我们来看一下产品经理的的职责：
1、市场调研
2、产品定义及设计
3、项目管理
4、产品宣传
5、产品市场
6、产品生命周期管理
……
仅靠产品经理个人来解决问题，显然不够现实。有必要在相关工作环节制定相关可用性工作流程。无规矩不以方圆！有了工作流程的保证，才能够更好的解决现有问题和后续未知问题。

FIY：以下流程比较适合软件开发团队，针对团队大小，可适当调整流程。

1、规划需求阶段可用性工作流程
可用性规划、界面原型、可用性概要需求、可用性需求评审、可用性详细需求
2、设计开发环节可用性工作流程
详细需求、界面和交互支持、界面和交互检查、可用性专题、专题分析设计、可用性需求评审
3、测试环节可用性工作流程
可用性发版指标、可用性测试、可用性缺陷修复、可用性问题支持、可用性缺陷验证、可用性发版报告
4、可用性实验工作流程
制定计划、实验准备、可用性实验、实验分析

以上的流程，也是在工作中慢慢总结理出来的。问题每个开发团队都会有，仅靠良好的沟通和调动大家积极性去处理问题，肯定会被累死，效果也不明显。可用性工作的开展不是一两个人的工作，我们需要用我们专业的可用性知识，在合理的工作流程中去影响规划、需求、开发、测试人员甚至是老板。

再搬出一个老问题：
请问一下你周围的需求、开发、测试人员、老板，可用性在你们公司是做什么的？如果他们回答不出，那你就需要好好思考思考，该如何开展这项工作了！o(∩_∩)o

搜狗输入法是我目前用过的输入法中，最方便的输入法，不得不鼎力推荐。
目前只支持Symbian S60 第三版，支持第二版的即将发布，期待中，我的Nokia6600就是第二版的系统，我等着你。

短信下载
发送“2”至“10666666”获取下载地址，即可轻松拥有最新版的搜狗手机输入法。
WAP下载
通过手机浏览器访问http://shouji.sogou.com，根据版本支持型号选择适合您手机的搜狗手机输入法下载。
电脑直接下载
通过电脑下载适合您手机的sis安装包，再传输到您的手机上进行安装。
http://shouji.sogou.com/download.php

mysql 分组 group by, 排序 取每条记录中，时间最大的一条记录

SELECT A.* FROM test A,
(SELECT aid, MAX(day) max_day FROM test GROUP BY aid) B
WHERE A.aid = B.aid AND A.day = B.max_day
ORDER BY a.install DESC

以下是 test 表，测试sql

CREATE TABLE IF NOT EXISTS `test` (
`id` int(10) unsigned NOT NULL auto_increment,
`install` int(10) unsigned NOT NULL,
`day` int(10) unsigned NOT NULL,
`aid` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=12 ;

INSERT INTO `test` (`id`, `install`, `day`, `aid`) VALUES
(1, 1232, 20080808, 1),
(2, 2321, 20080809, 2),
(3, 1236, 20080810, 3),
(5, 4212, 20080809, 1),
(6, 2312, 20080810, 1),
(7, 1432, 20080811, 1),
(8, 2421, 20080808, 2),
(9, 4245, 20080811, 2),
(10, 5654, 20080810, 2),
(11, 412, 20080808, 3);

还是看实际代码吧？

http://www.d5s.cn/example/js/js_flash.html 正常

http://www.d5s.cn/example/js/jquery_flash.html 出错

一个使用的是 document.getElementById(’XXX’).innerHTML = str;

另一个使用    $(”#XXX”).html(str);

结果，使用了jquery方法，会出现一些BUG在IE，其他浏览器未发现。

我之前也写过一篇文章： http://www.d5s.cn/archives/79

我以为 是使用jquery造成的，看来是jquery对object做了特殊处理，到底做了什么处理呢？我还不清楚，希望哪位js达人告诉我。

可以先看看这里的简介 DBA数据库 （这里没有提到db4，现在应该使用db4）

安装：

打开php.ini 确定 php_dba.dll 已经载入。

之后就可以使用dba函数库了。

这个数据，就是简单的 key=>value模式，和memcache差不多。

写入和查询速度都是非常快的。

如果是本机简单测试，可以使用 inifile 模式。

不过正式服务器上，一定要使用db4模式读写，因为其他模式比较慢，inifile就更慢了，还没有fopen快，所以inifile只能测试。

现在测试一下dba数据库的写入速度

每条数据是1k，写入速度分别是： 
10000条       1.71057009697
100000条      21.7869038582
1000000条    765.130697012

每条数据是2k，写入速度分别是： 
10000条       1.13584280014
100000条      25.066011906
1000000条     704.676019907

每条数据是3k，写入速度分别是： 
10000条       0.865121126175
100000条      24.7635490894
1000000条     745.992260933

每条数据是6k，写入速度分别是： 
10000条       4.17641997337
100000条      102.979793072
1000000条     1891.55883002

 可以看出，如果每条数据不超过3k的情况下，写入速度还是非常快的，而且大致都在一个范围内。（当然，这个速度还和服务器性能有关系）

 这是对测试结果做出的压力测试：

读取1000000数据的bdb库（3.9G左右），每次读取10-100条数据，每条数据的键，分别是1-1000000之间

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking si.adtest.com (be patient)
Server Software:        Apache/2.2.9
Server Hostname:        si.adtest.com
Server Port:            80

Document Path:          /test_bdb/r.php
Document Length:        37 bytes

Concurrency Level:      700
Time taken for tests:   2.558 seconds
Complete requests:      700
Failed requests:        555
   (Connect: 0, Receive: 0, Length: 555, Exceptions: 0)
Write errors:           0
Total transferred:      193705 bytes
HTML transferred:       26405 bytes
Requests per second:    273.62 [#/sec] (mean)
Time per request:       2558.262 [ms] (mean)
Time per request:       3.655 [ms] (mean, across all concurrent requests)
Transfer rate:          73.94 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.4      2       7
Processing:    82  471 118.6    517     559
Waiting:       26  443 118.9    484     544
Total:         82  473 119.2    519     559

Percentage of the requests served within a certain time (ms)
  50%    519
  66%    524
  75%    528
  80%    533
  90%    539
  95%    542
  98%    547
  99%    552
 100%    559 (longest request)