tao of yue^1.1

家里的Wii闲置有好长一段时间了，一个方面是似乎近期一致没有空玩，另一方面则是害怕Wii变砖所以一直没有去尝试新游戏。不过最近听说出了新超级马里奥兄弟，还可以双打(一直想找Wii上好玩的双打游戏来着，之前双打还比较好玩的感觉就一个马里奥银河)，终于忍不住决定去下载来玩玩了。
不过要玩这款游戏(的D版)还是颇为麻烦的，很多人报告说由于各种问题没法玩。看了一些文章之后，发现要想顺利玩上这游戏，必须得用所谓的软破解Wii。于是立即开始想办法研究到底怎么来做这个事情，结果网上看了一个小时也没看懂到底怎么样是一个最新的、最可靠的软破解的方法。很多方法里面列举的术语、工具也没出处，作用是什么也写的不清楚，看了也是一头雾水。但是又不甘心就这样放弃，于是花了整整一个下午来研究相关的名词解释，终于有点头绪，现把一些我看到的重要的链接以及概念归纳一下。
1) 软破解。所谓软破解就是homebrew，就是利用Wii的一些漏洞来执行不被任天堂所官方支持的应用程序的方法。常见到的Twilight Hack就是一种漏洞的利用，但是太麻烦，现在一般都不用。
1.1) http://wiibrew.org
2) dol和wad文件。这两种格式的文件都是Wii的程序文件，但是格式有所不同。
2.1) http://wiibrew.org/wiki/DOL
2.2) http://wiibrew.org/wiki/WAD
3) Wii上面有很多的channel，主菜单一共有四个屏幕，每个屏幕里面可以放4×3=12个channel。每个channel就是一个应用程序。Wii的系统里面自带了几个channel，最常用的就是Disc Channel，用来读游戏盘的那个。还有Mii Channel，用来画头像的那个。等等。
4) Homebrew channel。其实就是一个dol格式的程序，安装后会显示成一个channel。通过这个channel，又可以安装和加载其他的应用程序。所以它算是一个homebrew loader。
4.1) http://wiibrew.org/wiki/List_of_homebrew_loaders
5) USB Loader。最初的USB Loader是由一个叫waninkoko的人写的，他是个西班牙人，有个blog，但是由于是西班牙文的，所以Google似乎感觉根本搜不到（一般结果显示的都是英文结果）。在这个之后，有无数人根据这一USB Loader写了自己的衍生产品，比如USB Loader GX，Configurable USB Loader, USB Loader by Brisma等等。大多数作品都没有什么官方网站，也很少文档，看起来都很猥琐。我最后用的是Configurable USB Loader，原因就是它的文档写的还比较好，有一个有顺序的步骤能勉强看一看。
5.1) http://www.teknoconsolas.es/blogs/waninkoko
5.2) USB Loader列表，http://gbatemp.net/index.php?s=f6ac5855f839b5706ad8d6a40327a3be&showtopic=154465&pid=2446584&st=90&#entry2446584
5.3) gwht.wikidot.com/usb-loader，Configurable USB Loader的文档，需翻墙才能访问
6) Wii System Menu，我开始以为这个就是固化在Wii里的操作系统，说的什么3.1J，4.0什么的就算是操作系统的版本。结果最后发现不能算是这样。这个玩意似乎只是个图形界面，真正的操作系统叫IOS，有另外的一个版本号。
6.1) http://wiibrew.org/wiki/System_Menu
6.2) http://wiibrew.org/wiki/IOS
7) WBFS，专门用于Wii的游戏备份的文件系统。WBFS manager是用来管理这个文件系统的图形界面，可以把Wii的游戏的ISO镜像直接安装到WBFS文件系统的USB磁盘中。
7.1) wbfsmanager.codeplex.com
7.2) wbfs.codeplex.com

我最后的homebrew步骤:
1) 安装Homebrew channel。http://wiibrew.org/wiki/Homebrew_setup
2) 安装Configurable USB Loader。http://gwht.wikidot.com/usb-loader
3) 在Windows机器上安装WBFS Manager，把USB盘格式化为WBFS，然后把下载的游戏镜像安装到USB盘中。
4) 进入Homebrew channel，然后运行Configurable USB Loader，然后读取USB盘中的游戏。

expensr.com是一个在线的个人记账软件，我从2007年下半年开始用它，感觉很符合我的需要 – 简单易用，能够有基本的统计报表功能。我在2007年7月底的时候还给它们发了个邮件，提了点关于它的报表显示的建议。在我发邮件的第二天expensr就给了我答复，说它们正在做帐户之间转帐这一功能，这个如果做好的话报表这方面的显示就ok了。我当时对它的响应速度很满意。

但是到了2008年春节期间，expensr进行了一些更新，但是引入了一个bug – 中文输入的所有的字符显示都不正常了，这直接导致了我没有办法继续使用这一系统，我的所有的帐户名称和大多数的开支名称都是使用中文填写的。这次，我再次给它们发了邮件报告了这一bug，但是过了很久都没有反馈。我在这之后的一段时间又发了两封邮件报告这一bug，但是都没有得到答复。现在，2008年3月18日，距离我发现这一bug已经45天了，系统没有任何的更新来修复这一严重的bug，对我的三封邮件也没有任何的响应。我看了expensr的官方blog，从2007年12月11日之后就没有任何更新了，虽然从网上搜索的结果看来，expensr.com很有前途，但是就目前我的使用和观察，expensr.com命不久矣
update:
果然一个月之后expensr.com宣布被收购，expensr.com的用户都会转到moneyStrands，希望转移之后的应用能够比较好。

Leopard发布的那段时间,看到最多的消息就是批评Leopard没有对Java 6的支持,但是没有想到它对Java 5的支持也倒退了一步.

在升级到Leopard之前,在Tiger上一直使用jVi + Netbeans 6 Beta 1,用着感觉非常爽,比Eclilpse下面那些vim的集成或者插件都感觉要好.但是在升级到Leopard之后,使用了Netbeans Beta 2,发现有一个最基本的功能失效了–用”:”切换到命令模式下无法使用回车键执行.开始还以为是jVi对Netbeans Beta2的支持有问题.等了一段时间,直到jVi和Netbeans 6都发布了新版本之后,发现用最新版本还是不行,这才到jVi的论坛上面去看,结果发现有其他人也遇到了相同的问题,是Leopard的Java 5问题导致的.还不知道有什么work around或者Apple什么时候才能完全支持Java 5,只能天天用Command+S来保存文件了,真是郁闷.

唯一值得欣慰的是Apple还没有把Java给完全抛弃,希望猜测是对的.

Update: 有人高兴有人愁。可惜我不喜欢all in one的一站式采购。

Rails的file_column插件是一个简单但是功能比较完备的文件上传插件。这一插件已经有很长时间没有更新了（最后一次更新是在2005年），但是就其功能和兼容性来说，一般的使用似乎没有什么问题。其用法也相当简单，大致的看看网站上面的文档即可。但是如果要做一些自定义的工作的话，就需要直接看它的源代码了。代码量不多，包括测试代码也就10多个文件。

最容易碰到的自定义需求应该就是定制上传文件存储的位置了，默认是在public目录下根据不同的模型名称来建立目录，明显的，这很容易造成“污染”，导致public目录下面生成大量的子目录。在看了其源码之后，注释中说明是可以通过给file_column这一方法传入参数:root_path来覆盖默认值的。我将root_path设置到public目录的file子目录下，试了之后在开发模式下上传文件确实没有问题，但是进行functional testing的时候发现并不正确。我在模型中设置了对文件大小进行验证的validates_filesize_of。这一方法在测试运行时验证查找的路径是在public目录下查找，这明显是不正确的，也即，仅仅覆盖root_path参数虽然能够在开发模式下正常工作，但是functional testing有些不同，按照其注释中的说法以及源代码，进行单元测试时file_column会把RAILS_ROOT/test/tmp/file_column这一目录作为根目录，而不是RAILS_ROOT/public/。单元测试时应该在setup方法中调用setup_fixture_files，在teardown中调用teardown_fixture_files，这两个方法会把文件fixtures复制到RAILS_ROOT/test/tmp/file_column目录下测试，测试结束后就移除。但由于根目录被我们传入的参数root_path覆盖，导致测试时的代码无法通过。解决的办法有两个，一个是按照不同的运行h环境来设置根目录，代码如下： 

if RAILS_ENV != "test"
  file_column :image, {:root_path => File.join(RAILS_ROOT, "public", "files")}
end

if RAILS_ENV == "test"
  file_column :image, {
  :root_path => File.join(RAILS_ROOT, "test", "tmp", "file_column", "files")
  }
end

但是这样做也有一个缺点，那就是如果在测试模式下进行集成测试的话（如使用selenium进行测试），file_column又会到test/tmp/file_column下查找文件。这也是明显不正确的，会导致文件无法访问。另外一个做法，可以做到万无一失的–直接修改file_column这一插件的代码:-)

一直看GoogleChinaBlog,很想在上面留个言,不过那里好像不提供留言功能的说,唯一的留下自己痕迹的方法好像就剩下Backlink了.今天就借个机会backlink一下,本来还想顺便给自己的blog也加上backlink的功能的,不过好像本人RP实在太差,导致PR值也不高,”link:blog.niyue.com“在Google上面搜索了一下居然一个站点也没有链接到这里,加到这里反而变成自取其辱了,实在不能满足本人blogger ego的需要,于是就放弃了.
本来还想借这篇文章顺便提高一下PR值的(backlink了GoogleChinaBlog之后也会被link到GoogleChinaBlog上,不知道Google自己的网站连出去的站点会不会特地提高一下PR^_^),不过发现这种SEO的策略是行不通的,只能希望Google的爬虫还爬的到这里能够找到这个backlink,这样还能够借GoogleChinaBlog带点人气呵呵,如果你是通过GoogleChinaBlog上的信息指纹及其应用这篇文章surfing到这里来的,麻烦请留个名让我知道一下:-)

我本身对模式识别和自然语言处理了解不多，不过这几天冒出来的似乎都是和它们相关的一些想法。前段时间买了一台打印机，主要目的是想把要看的一些论文什么的打出来，这样在车上或者在路上或者在那些没有电脑的时候看起来方便一些，另外paper-based的文档看起来也习惯一些。也不知怎么晚上突然又想到，假如有一个Text to Speech的软件，把我要打的论文转成语音文件，比如mp3或者wav这些格式的，这样就可以直接用mp3播放器来听而不用看了，毕竟听读的速度比阅读的速度要快的多（当然，e文的话听力好像会有点要求:( ）。也就是说如果可行的话，我需要买的应该就是mp3播放器而不是打印机了。
在Wikipedia上面一下就找到了想到的东西，大致看了一遍以后决定用FreeTTS试试看，它是Sun公司下面的一个Media Lab的员工建立的项目，应该还是质量不错的。试用了一下，用起来还是满简单的（虽然在我的Ubuntu下面声音设备有些问题似乎），但是结果确不是很好。输出输入只有英语也还算了，关键声音质量实在不敢恭维，听起来就像电影里面的机器人的声音。不知道机器人发声是怎么样的过程呢？好像应该也是类似先软件编程robot.speak(”Hello World”),然后语音合成这样的方式吧，基本和这个FreeTTS的工作方式一样了，也就是说，你现在在电影中听到的机器人的声音，很可能现实中未来的机器人的声音就是这样的:)，赶快想象一下Start War里面的金属机器人的声音吧。

Update:

最近想买一个iPod听podcast,突然发现网上有提供将text-based的feed转化为podcast的服务,其实和我上面的想法很一致，尤其是audiolicious,等我买好了再来用。

• Audiolicious: Turn Any RSS Feed Into A Podcast, Using Text-To-Speech
• Feed2Podcast
• Talkr

要是以前问我programming以来碰到的最困难的bug，我可能一下回答不出，但是今天碰到了一个bug，解决之后回想一下，发现最困难的就是这类的bug－与时间相关的数据问题。这类问题由于和数据计算的时间有联系，导致了这类问题发生的上下文往往无法重现，根本没有办法进行调试。

这次碰到的问题是企业生产系统中计算的外购数量发生错误。外购数量根据订单订购数量以及企业当时该种货物的库存计算得到的，也即与特定的时间点相关。生成的外购数量中部分正确，部分有问题，由于将所有数据恢复到当时情况进行重新计算与调试，很难有地方可以入手查找问题的根源（当然，这里也可能是因为我们的日志做的还不够好）。程序代码检查了没有发现问题，直接查数据库中的数据也没有办法得到答案，后来碰巧发现两张出错订单的制单日期均是在20日之前，于是猜想20日之前的那个版本中程序有问题，但是现在已经解决。但是这一猜想也无法证实，因为正确的版本的发布时间已经想不起来了。终于通过FTP上的文件（文件中包括了发布时间，15日和20日均发布了一个版本）以及JIRA中对于这一bug的记录（记录日期为15日，解决日期为17日），确定了正确的版本肯定是在17日之后发布的，也即20日发布，在20日之前的数据都存在问题，但是20日之后的数据均正确。

解决这一bug一共查找了系统源码，db数据，ftp发布文件，jira中bug记录等四处的信息才定位到问题原因所在。和做数学题一样，其实题目并没有超纲，只是多拐了几个弯的话做起来就很难了。而这里会需要多拐弯的原因正是在于时间信息无法重现，只能通过多个信息源共同来确定问题的可能原因。

基本上没有什么办法能够避免此类问题的发生，唯一的比较好的解决办法是在系统中进行完善的日志记录，保证能够捕获系统中大多数时间点上发生的事件情况，从而能够较好的重现bug发生时的现场使得bug能够快速定位。

这段时间想找一个Wiki来帮助大家协作编辑一些文档，试了好多个，都不是特别满意。大致列举如下，也为后人节省点时间。主要参考文章：

How To Start A Wiki

1. PeanutButterWiki

优点：界面很简洁，速度也很快。

缺点：用户权限管理过于简单，一个Wiki只能大家共享一个账号编辑。没有所见即所得的编辑器，必须使用特定的语法。

结论：个人使用的话是个不错的选择，不过可能要忍受一下编辑时的繁琐，不知道编辑多了会不会习惯。

2. Schtuff.com

优点：速度也很快，权限可以配置的很详细，界面也不错。

缺点：也没有所见即所得的编辑器，必须使用特定的语法。

结论：多人协作的话使用这个不错。

3. SeedWiki

优点：相比的话优点不多，不过知名度比较高，Google很容易就搜到了。

缺点：界面设计有些问题，很难搞清怎么创建页面。

结论：不推荐

4. Wikicities

看起来不错，不过注册以后一直没办法登录:(

5. wikihost.org

优点：界面做的很好，使用十分方便，有所见即所得的编辑器，就是编辑选项稍微简单了一些。

缺点：权限有问题，都是public的。

结论：个人使用还是不错的，要是有什么privacy的话就算了。

6. XWiki

优点：功能很多，提供了除了Wiki之外的许多功能，如Calendar等。界面也还算易用。

缺点：组织方式不是很好，更类似blog而不像一个一般的Wiki。另外编辑的入口不是很容易找。最大的缺点是–中文支持有些问题，显示没有问题，但是再次编辑的时候中文都转化为\uxxxxx的Unicode了。

结论：如果不使用中文的话是个不错的选择，附加的功能很不错。

Update:

今天看到Informit上面的一篇文章也是介绍Wiki Hosting的,在这里链一下。

Which Hosted Wiki is Right For You?

这几天准备开始一个新项目，由于要求多个人的协作，所以准备使用一个源代码管理系统，很自然的选择了现在很热的Subversion。原来一直没有很好的使用过类似的系统像CVS，只是偶尔用CVS去checkout一下sourceforge或者java.net上面一些项目的代码，但是自己从来没有checkin过。大致看了几篇文章：

Version Control with Subversion

Subversion快速入门

《使用 Subversion 进行版本控制》附录D

然后就开始动手了，中间碰到不少麻烦，最后的步骤总结如下（我是采用Subversion Stand Alone的方式安装的，不是作为Apache的一个模块安装的）：

1. 当然是去subversion.tigris.org下载Subversion了

2. 下载以后安装，建立一个目录repository，然后使用subversion安装目录下的bin子目录中的svnadmin将目录repository创建为一个文档库（我是用TortoiseSVN直接创建的，所以具体的命令行参数我也不太明）

3. 修改repository目录下面的conf文件夹中的两个文件以配置可以使用这一文档库的用户权限，具体的配置方法看看里面的那两个文件很容易就知道了

4. 运行bin子目录里面的svnserve.exe -d -r repository 开启Subversion服务，也可以使用SVNService将Suversion包装为一个Windows服务运行

5. 使用Subversion的客户端如TortoiseSVN或者Subclipse等等连接刚刚开启的Subversion服务就可以了

注意：我原来从来没有正式使用过CVS或者类似的工具，犯了一个大错误，浪费了不少时间。我把我的项目的编译输出（Eclipse里面可能是bin目录这种目录，里面有无数的.class文件）也包括在了版本控制的范围内，结果从Subversion服务器checkout之后的项目Eclipse会自动进行Automatically Build。在构建的过程中会将bin目录下的所有的文件或者目录删除（也包括Subversion进行控制所依赖的.svn目录，应该是一个隐藏目录，里面包括了Subversion要用到的版本控制的信息），这一目录删除了之后，客户端便丢失了版本控制的信息，新建的目录名字又是和原来Subversion中一样的文件名，提交的时候一直出现某某目录“阻碍（obstructed）”或者某某目录不在版本控制之下，导致提交失败。很郁闷的弄了一天多时间终于意识到了问题的原因，解决方法也很简单，就是在创建版本库的时候不要将编译器输出的这些类的目录导入到Subversion上去，在checkout之后构建生成了新的bin或者classes这些目录，也不要将其加入到Version Control，而是选择“add to ignore”忽略这些输出，以后提交或者update就不会有问题了。