Fwolf's Blog: 四月 2008

2008年4月22日星期二

[OGame]太电还是核电？

OGame我算是完得比较早的人了，tw u2出的时候就进去了，还是在1银河，现在cn服都出了很多了，我却很懒，一直趴在tw u2种地，中间还有近乎一年没上过，居然没被删号也没人打，倒是自己想起来再进去，发现堆了一大堆资源，开始转运的时候被发现了。。。这些烂事就不说了，言归正传吧。

我走的是超级堡垒路线，专注于发展主星（这样省事嘛），其它的星星都是太太往这边拉货，星上什么都不留，包括防御。主星位置是5，缺点就是太小（已经升了5级地形改造器了）：

直徑  12.800 公里 (  182  / 188  方圓 ) 氣溫  大約 27°C 到 67 °C

现在已经是发展的后后期（满天的死星飘啊飘）了，每一个方圆都很重要，所以，我面临着选择太电还是核电的问题。

一般来说，大家都倾向于选择太电，原因很简单，核电费重氢，太电什么都不费，并且到出引力科技的时候什么电都不够，要用一大堆太阳能卫星来补充能量(我就放了8188颗)，有了这些卫星，反倒什么电厂都不用了。所以一般的讨论中，核电都是造几级就停止的。

但现在是后后期，情况就有所不同了，首先太卫随时都有可能被打掉，到那时资源也没有电也没有，就等死了，所以不能单纯依赖太卫。

再来比较一下太电和核电，官方给出了核电产能的计算公示：

30 * [核電廠等級] * (1,05 + [能量科技等級] * 0,01) ^ [核電廠等級]

那么按照我能量技术12级来计算，15级核电产能4738.50，20级核电产能13860.00，24级核电产能31168.80。

太电产能和位置有关，我是5号星，现在24级的太电，产能4727，只相当于15级核电的产能，相差9个方圆；即使是升级到了32级，也只和20级核电产能相当，而方圆相差也到了12个。

再来看核电的消耗，现在的6级核电消耗重氢107，而我26级重氢分离器产能是3550，这还是在5号温暖的星球上，这样看来，核电的消耗是非常少，能够省出来方圆，多升一级重氢分离器，就够升几级核电用的了。

所以，出于方圆的考虑，我决定废掉太电，专门升核电，省下方圆种田，嘿嘿。

另：发现另外一款游戏特洛伊，也是仿Travian的，感觉不错，已经注册，重新开始种地中。

Source: http://www.fwolf.com/blog/post/397

2008年4月13日星期日

在新项目中继续使用ADOdb，这个是没什么悬念的了，尝试过php5自带的pdo，感觉一般，对某些数据库的支持更一般。但是数据库结构如何维护这块放不下心，从以往的开发中看，系统开发维护期超过半年之后，如果在数据库schema管理上不下点功夫，在生产服务器和多个测试服务器以及sql结构之间，难免会产生schema不一致的情况，管理情况再差的，连最后一稿schema是哪个、以及schema注释都能丢失。所以，无意中瞥到ADOdb还有一个ADOdb Data Dictionary Library for PHP以后，就想看看这个能否用在多环境数据库schema同步方面，连同自己了解的一些其它情况，记录在这里。

ADOdb Data Dictionary Library for PHP

可以用简单的字符串或者数组的方式记录数据表的结构，然后调用相关功能来生成修改数据库的sql语句，并执行之。应该是在创建数据表方面还是非常方便的，虽然数据类型简单了一些，执行和调用也略显麻烦（抱歉我的确是这么认为的），但在简单的应用中，尤其是数据表修改不是很多的情况下，应该会很好用。

ADOdb XML Schema (AXMLS)

这个其实也是包含在ADOdb中的，其介绍也是直接列在了ADOdb Data Dictionary Library for PHP同一页的下方。在仔细把这段并不多的内容读完之后，我是半喜半忧，喜的是AXMLS这个东西可真好啊，相当于能够把整个数据库的schema xml化了，然后对实体数据库进行更新；忧的方面一是，在最新的ADOdb5.04当中，依然没有完全实现AXMLS中的全部功能，我建了一个简单的xml，其中带有一句：

TYPE=INNODB

然后在一个空的数据库上执行，输出sql，发现CREATE TABLE的sql中并没有带上ENGINE=InnoDB，所以就停止了尝试；忧的方面二是这么好的东西，它的官方网站上最新的消息却是2004年6月17号的，一个软件不可能在4年中一点都没有改动，况且那时候还没有php5呢吧。在互联网其它方面来搜索这个AXMLS，发现只是在adodb中有，并没有在其它项目中得到运用，可惜了了。

一些商业软件的实现

很多商业软件的数据库schema管理一般都在case工具中，也有生成sql甚至直接对数据库应用schema变更的功能，比如我以前使用的PowerDesigner，不仅是最好的数据库实体模型设计工具，而且设计完成后，直接连上数据库进行更新。也可以反过来，从实体数据库中分析出数据库模型。

东西是好东西，可用了一段时间不再想用下去了，原因是多方面的，一是Sybase的东西bug总是很多，有时候莫名其妙的错误提示很头疼，二是数据库大了以后，每次连线diff的时候都很慢，最要命的是，它在更改column时喜欢用临时表，然后删除原表建新表，再从临时表中把数据读回来，一旦这个过程由于数据库兼容问题或者其它原因被中断，下次再同步的时候，很有可能数据库结构更新了，而数据却丢失了，因为它有自动删除临时表的选项，并且一般大家还都需要打开这个选项；最后一个原因，这玩意儿既没有Linux版本，我也没有正版的授权，所以能下岗就下岗了。

自己用简单的脚本来实现

其实在实际的应用开发中，数据库相关要修改的地方会很多，不仅有表、索引、视图等数据库本身的元素，还可能会有一些数据的调整和处理，比如将表中的A、B字段去掉，他们的值相加存储在一个新的C字段中，如果说前者应该会有成型的工具能够实现的话，像后面所说的这种数据库，或者更准确一点说是数据调整在任何工具中都不会涉及到的。

反过来想，无论是对数据库如何进行操作，无外乎就是DDL数据库定义语言和DML数据库管理语言，也就是通过大家常说的SQL语句来操作，那么把这些简化为一个SQL语句集合，就可以将开发过程中所有的数据库变动转化为这一系列SQL语句的管理和执行，设计这样一个工具不就得了么？

我现在就是这么作的，在svn中除了有保存数据库最终状态的schema sql文件之外，还专门有一个php文件，用数组记录每一次需要对数据库调整的SQL，然后有一个执行记录表，记录哪些SQL执行过而哪些没有。这个执行记录表在每个数据库实例中都会创建，这样，我只需要简单的调整数据库连接参数，然后就可以通过执行php代码，依次逐个的执行每个SQL了。

其它的开源软件都是怎么实现的呢？

我阅读过的开源软件源码并不多，但软件还是用了一些，在有些软件升级的时候，就会自动将数据库也升级了，他们都是怎么实现的呢？难道说只是在1.0升级到2.0的升级程序upgrade.php中，固定的、一次性执行数据库修改么？

关于同类数据备份和迁移

以前一个朋友用oracle数据库的时候，特别喜欢用tora（他管它叫蛤蟆，因为软件的about页上有只蛤蟆），但我却认为，在同类数据库，尤其是版本、配置相同的数据库之间进行数据转移，方便一点的方法是利用数据库的导出、导入功能，这样不会有DML覆盖范围以外的内容拉下，简单一点的，自己写个小程序，连上两个数据库，这边读来那边写，也不会慢到哪里去，想提前删个索引什么的也好控制。tora一类的工具，应该是在灌初始字典库的时候用最合适。另外，不是还有bcp么？

参考

Source: http://www.fwolf.com/blog/post/396

2008年4月11日星期五

防止垃圾评论的另类方法

先看这里：從 Ditz 談針對分散式版本控制的 Issue Tracker，最好是留言以后再看本文，更有切身体验啊。

防止spam评论现在流行使用问答方式，这位老兄更近一筹，评论提交的目标脚本打开了apache的认证，然后在认证提示里放上用户名和密码。一般spammer机器人只会看到401 Authorization Required或者403 fobbiden错误，达到了阻止的目的，真的很高明。

多想一点

盾1：要想定期不定期更换密码，可以用脚本定期更改apache配置文件中的AuthName，用htpasswd更改AuthUserFile，然后重启apache。

矛1：既然浏览器能够得到AuthName提示，robot理论上也是能得到的，只是他们现在还没意识到，没有去处理罢了。

盾2：AuthName里我使用中文，或火星文，或脑残体，别说外国人了，中国人也得认真才能看明白。

矛2：人肉之。。。

至于我这里垃圾评论的情况，嘿嘿：

Akismet has protected your site from 51,241 spam comments already, and there are 33 comments in your spam queue right now.

Source: http://www.fwolf.com/blog/post/395

2008年4月10日星期四

WordPress升级后分类乱码的原因及解决

另外一个网站WordPress很久没有升级了，主要是嫌网站太慢，ssh上去操作麻烦，加上主人也很少更新。不过当Wordpress Automatic upgrade出现之后这一切都简单多了我只要在页面上点点鼠标就能升级了，顺便还能把WP的文件和数据库打包下载到本地。同时，WP的新版2.5还支持插件的自动升级，以后无论是升级WP还是升级插件，基本上就不用ssh了。

Wordpress Automatic upgrade的安装和WP的升级基本顺利，不过中间执行完upgrade.php升级数据库后，返回wpau有一个错误，没什么提示信息，直接retry后说升级不成功，清除结果再次运行就没问题了。

升级成功之后，blog标题成了？？问号，我知道这是字符集的问题，看了看wp-include/wp-db.php中已经可以自动识别字符集（原来都是自己hack这个文件），就在wp-config.php中添加了两句配置：

define('DB_CHARSET', 'utf8'); define('DB_COLLATE', '');

乱码问题解决。以为这就没什么事，又分类的名称怎么都成了"？？"了，到分类管理里面一看还是问号，编辑修改成中文保存后依然是问号，如果改成英文的就没事了，其它的内容比如文章什么的中文都正常，怎么回事呢？

左思右想，觉得还是和升级时候的那个错误有关，我是从比较旧版本的WP升级过来的，以前是通过hack wp-include/wp-db.php文件设置数据库用utf8编码连接，升级过程中这个文件被新版文件覆盖了，而wp-config.php中添加相应设置之前有一个空档，而升级数据库恰恰是在这个空档时进行的。WP 2.3添加了tag功能，后来查看分类的数据表发现分类和tag是保存在一起的，所以可以确认这些被修改了的数据表在创建时，程序并不是使用utf8编码连接的数据库服务器，而是默认的latin1_swedish_ci字符集。在这样字符集的数据表中，自然是无法保存中文的，所以原来的中文、新输入的中文就都变成了问号。

解决方法有些麻烦，因为没有用phpMyAdmin，都是直接编辑好sql命令在mysql中执行的，好在涉及到的表不多：

wp_term_relationships
wp_term_taxonomy
wp_terms
wpau_active_plugins_info
wpau_upgrade_log

修改表的字符集语法如下：

ALTER TABLE [table_name]  DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

这还没完，还得把每个表中的字符型字段的编码转换过来，这个就略微多一点了：

# 查看表中各列的详细情况，包括字符集： show full columns from wp_term_relationships;  # 更改列的字符集或类型、长度 alter table  wp_term_taxonomy change taxonomy taxonomy varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table  wp_term_taxonomy change description description longtext CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;  alter table  wp_terms change name name varchar(55) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table  wp_terms change slug slug varchar(200) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;  alter table  wpau_active_plugins_info change plugin_name plugin_name varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table  wpau_active_plugins_info change plugin_status plugin_status varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;  alter table wpau_upgrade_log change task_name task_name varchar(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table wpau_upgrade_log change task_status task_status varchar(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table wpau_upgrade_log change task_description task_description varchar(150) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; alter table wpau_upgrade_log change task_log task_log text CHARACTER SET utf8 COLLATE utf8_general_ci NULL;

其实wpau的两个表不用改的，老外设计的程序一般不会写中文进去，改过来只是好看一些。

另外WP 2.5把slug弄没了很不舒服，虽然现在我只用id作permanent link，但还是原意有个整齐一点的slug更好看，所以用上了slugshow插件，希望WP啥时候把那个貌似智能其实很傻的功能改过来。

Source: http://www.fwolf.com/blog/post/394

订阅：博文 (Atom)

Fwolf's Blog