一般的车上的电视放的都是什么东方明珠移动电视，这个江桥一路上面装备的居然是一个像GPS导航仪一样的系统，应该主要是给乘客看的。很赞，尤其是像这种偶尔乘坐的线路其实是很有用的，现在坐到哪站大致方位如何都一目了然。一路上我盯着这个屏幕看了老半天，发现定位还是挺准确的，汽车前方快拐弯都能一下就能够从地图上看出来并有所准备。

车上的终端装的居然是Windows，然后看样子是用了MFC写了一个客户端(看图标像…都什么年代了)。通讯似乎是通过EDGE信号，估计里面还得有个GPS的芯片，光用基站定位的话似乎没这么准，我的iPhone还号称又是WiFi又是GPS又是基站画三角形什么的，结果还是一直差出几条马路…

我最后的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盘中的游戏。

但是到了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之前,在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的一站式采购。

最容易碰到的自定义需求应该就是定制上传文件存储的位置了，默认是在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这一插件的代码:-)

Update:

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

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

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

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

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

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?

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就不会有问题了。