由于最近一直在使用thinksns，所以相对关注的就比较多了一点。BUG偶尔也会发现一些，小的就不提了，没意义，偶尔也有可能是手误的关系，但一些稍大一点的。我还是写下来做个记录。。
比如这个插件配置的BUG。
一般来说，项目的配置要覆盖原始配置都是array_merge就结束了。于是乎，ThinkSNS在每个插件的Conf目录下的Config文件里也都有这么一行。
然而。。。问题就出来这里，插件的作者好象都没有注意过Array_merge的作用范围。
大多情况都是这样写的：
PHP代码
- $miniConfig = array (
- 'DEBUG_MODE' => false,
- 'DEFAULT_ACTION' => 'index',
- );
- $array = require_once( SITE_PATH.'/config.inc.php' );
- $array = array_merge( $miniConfig,$array );
OK，让我们来温习一下array_merge函数。
XML/HTML代码
- array_merge() merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.
-
- If the input arrays have the same string keys, then the later value for that key will overwrite the previous one. If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.
-
- If only one array is given and the array is numerically indexed, the keys get reindexed in a continuous way.
看到第二段没？如果有相同的KEY，后面的会覆盖前面的。。那么。。上面第6行的array_merge，和没运行有什么区别？？？
把参数顺序颠倒一下就OK了。。。
MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择
第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM
作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm
MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。
下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？
思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。
数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小 决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。
您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。
所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方 式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。
第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择
作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm
两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。
我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。
原因如下：
1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。
2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。
3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据 库实例的数据量基本都是几十G大小。
4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。
5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让 他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。
6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。
7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。
当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。
另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十 多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。
文章都不太长，适合着看看就行了。。
designMode，这个被我遗忘三年的变量。连名都忘了。想了好久好久才想起来。。。
OK，设置这个变量为ON，那么页面上的元素就全可以编辑了，功能是用来干嘛的呢？好象有点忘了。当初是想用来直接COPY文章的。如今想起来，却不知道用来干嘛 了。
参考：
1、http://www.mozilla.org/editor/ie2midas.html
2、http://www.nirsoft.net/utils/ie_design_mode.html
BUG管理给开发人员带来了方便，但，如果你描述的不合理，或者无法让开发人员重现BUG，那么，你其实是在给开发人员带来困惑。。。
一般情况下，我们使用bugzilla来记录BUG，有时候也用 mantis，毕竟这两个都算是开源软件了。bugzilla被使用的更多，因为有很多IDE，都有插件支持，但对于开发人员来说，更重要的是BUG产生的情况，所以淘宝的QA TEAM 这样谈BUG描述时，我觉得有必要记录一下，以后也可以让同事看看，HOHO，可以报BUG更精确一点：
清楚准确的描述BUG，这是测试人员的必备的基础。但是针对各种问题，我们又如何使自己提交的BUG让开发人员看一遍就明白呢？我相信大部分人都会碰到以 下这种情况，我们提交上去的BUG在某些特定的环境下存在，这时候如果没有写清楚具体产生BUG的前提条件的话，BUG难以重现，这个时候开发就会说： “为什么我测试的时候没有出现这个问题呀，人品问题。：）”。还有就是开发经常说：“为什么在我的机器上没有出现这个问题呀？”。“这个BUG是什么意 思”等等问题，出现以上一些问题还是追究其根源：
1． 测试与开发理解需求有偏差
2． BUG的出现是有概率性的
3． BUG受环境影响
4． BUG在一定条件下存在
5． BUG受数据影响，数据量达到一定量时才存在。
6． 测试人员提交的BUG，描述不清楚，让开发人员不明白其意
为了尽量避免以上问题的出现，我们测试就要尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象等。下面讲一讲BUG的描述规则：
1．摘要主要用于指明Bug发生的地点、在什么条件下发生什么现象。
2．描述字段：
1）描述Bug发生的地点、所用账号类型、操作步骤、期望值、实际值， 如果Bug与浏览器相关，需尽量描述更多的环境参数，如操作系统等。
2) 一个Bug不会包含多个问题，会尽量单一化，便于跟踪处理及统计
3) 对于很难描述清楚的Bug需截屏作为附件上传，并在描述中写明参照附件。
4）尽量减少重现的步骤以达到用最少的步骤来重现问题；
5）不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。
6）不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。
7）在BUG提交前，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤。
8）测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。
9）如有必要可以把产生结果的SQL语句放上去，不过需要开发人员在短时间内定位问题，否则测试人员不能保证数据的完整性。
10）如果是概率性的BUG，尽量重现BUG，找到BUG产生的条件，如果找不出BUG产生的原因必须写明BUG发生的概率大约是多少。
11）BUG如果在特定条件下产生的，必须写明BUG产生的条件和操作步聚。
对了，本文来源：http://rdc.taobao.com/blog/qa/?p=5168，作者是pingyan
O&O的软件，让人记忆犹新的应该是磁盘整理吧？想不到，居然还有这样的软件，它，最起码，看上去很美。
感谢国内汉化人员的努力，可惜我的服务器已经转为ubuntu，不过，我的台机和笔记本都是用的windows，所以，我还是想尝试一下。
以下为内容介绍：
O&O CleverCache 可以优化你的 Windows NT/2000下内存和文件缓存管理。这可以导致性能的大幅度提高，可以加速你的系统速度，而不需要任何硬件上的更新，也不会限制系统的稳定性。安装它不 需要任何的配置和重启动，只要5 分钟就可以激活系统中未使用的资源。
在使用较长时间不中断服务器往往会造成问题。应用程序和操作系统更容易崩 溃，因为主存储器超载或太多的程序在同一时间运行。O&O CleverCache 7 服务器版不断监控您的服务器，优化调整Windows 的文件存储，以适应其要求。因此，你就可以防止系统崩溃，停机时间，甚至数据丢失。
可用于 Windows NT/2000/XP/2003/Vista/Win7
汉化使用说明：
1、此为汉化版，安装后即可直接使用。
2、制作安装包时，已将专业版和服务器版同时打包在内，请
在运行安装时自己选择所需要安装的版本类型。
3、两种版本安装后均已注册。
4、此汉化无捆绑。
下载：http://www.hanzify.org/index.php?Go=Show::List&ID=9613
