夜游长空

最近流行一种游戏，叫做“数独”，英文叫Sudoku，听着应该是从日本那边过来的。我曾经做过几个，发现这个东西如果纯粹用眼睛和大脑来解决确实有很大的难度。但是如果你加上纸和笔，那么难度就会降低95%，而如果你借助于更先进的Excell，那么难度就会降低99%。我最终的结论就是，这个东西是个体力劳动。
如果有人还没有接触过数独，那这里就来大概介绍一下：数独应该算是一种九宫格游戏。他是由3*3个九宫格组成的一个大正方形。要求你在9*9个格子里面分别填入适当的1..9的数字，然后让每一行，每一列中的9个数字都包含1..9。另外，每个九宫格中也要包含1..9。下图就是一个数独。

我曾经和LP说过，这个东西实在变态，是一个纯粹的浪费时间的东西。我就异常后悔曾经花了几个人时去做数独。不过，这个月买了《新知客》后，遇到了更变态的事情，那就是，它变态到附赠了一个增刊，其中有28个数独。而且说：“空前震撼！28道数独让你过足瘾！”。更过分的是，其中有些数独本身就是错的（比如，一个九宫格内竟然出现了两个8～）。答案更是错误百出。不知道这些编辑们都是不识数呢，还是不明白数独的规则。
学习Ruby也有一段时间了，突然就想，正好拿这个练习一下。所以花了3个晚上和一个白天的时间用Ruby写了一个解决数独的程序。目前经过我做的一些基本测试，工作还算正常。如果有兴趣，可以在这里下载玩一玩。当然，因为是Ruby，所以还需要Ruby的Interpreter。然后在命令行窗口运行ruby sodoku.rb就可以了。（我是在Windows下写的，所以没有shebang。）
我的感觉就是，用Ruby写程序真的是一种享受。感觉需要用到的东西都是非常straightforward，没有什么要用到的东西需要你自己去费劲配置和研究的。而且大多数API，都可以直接猜出来。比如我写这个的时候，很多用到的API都是先猜着写，然后再看Ruby的API文档，竟然发现没有什么错误。证明了我是一个聪明的人。。。更证明Ruby的API和语法设计的非常友善。呵呵。
我用的算法应该也不是最优的（类似于判别树的算法），但应该比纯粹的枚举要好多了。欢迎讨论，如果大家对算法有兴趣。我正在打算专门写一个网页来介绍我的程序逻辑，不出意外，应该下周一之前写完。欢迎大家提意见。
另外，也有一个计划就是把它变成一个网络应用。不过那就需要更多的测试和调优了。

module OutputHelper
def print_line(msg)
print msg + “\\n”
end
end

class SayHello
include OutputHelper
private :print_line
def initialize(name, &sayHello)
@name, @sayHello = name, sayHello

if @sayHello == nil
@sayHello = proc { |msg| print_line msg }
[...]

今天看到railschina论坛上一篇贴子在讨论在Ruby中，puts str是不是等于print str + “\n”。因为一位同学做了实验，在irb中，在多线程环境下使用puts似乎有问题，有的时候字符串和换行的顺序会乱，而用print就没有问题，所以得出结论，认为puts是不等于print + “\n”的。又有人提出质疑，因为做了另外的实验，在非irb环境下，puts和print都没有问题，所以认为多线程问题只是主观臆测，有可能是irb的问题。甚至还有人写信给Dave，结果Dave也没有给出明确的答复～
正好手头上有Ruby的源代码，所以翻出来看了一下，在io.c中，明确的写明了Ruby中ios.puts方法的实现：

VALUE
rb_io_puts(argc, argv, out)
int argc;
VALUE *argv;
VALUE out;
{
int i;
VALUE line;

/* if no argument given, print newline. */
if (argc == 0) {
[...]

一直以来没有系统的学习过Windows编程，到了CA后，工作的要求，所以必须学习一下。买了一本《Windows核心编程》来看，最近刚刚看完。个人觉得还是收获很丰富的，充分证明了这本书确实是本好书。
这本书一直就被称作Windows平台下开发人员的必读书之一，确实是名不虚传。它就像是一个Quick Tour，带着你游历Windows编程的各个方面，但是又不仅仅是简单的浏览，在重点的地方，还会给你详细的解读。看这本书的时候，能深切的感觉到作者对Windows平台的理解非常透彻。这本书确实是可以帮助人快速的进入Windows编程世界。
不过，中文技术书籍的通病：翻译质量问题在这本书上显现得也非常明显。我本以为一本如此经典的书，翻译质量应该能在平均水平之上了吧，结果大失所望。如果我之前一点Windows编程知识都没有的话，可能看某些句子会猜不出意思。毕竟懂技术的翻译人员太少了～
想看这本书的，建议读英文原版的。

Wordpress2.2.x开始正式把widgets作为内部功能之一。这说明了widgets的成功和人心所向，也说明了大家对于添加一个小功能就要修改theme的template的厌倦。widgets最初是一个wordpress的plugin，叫dynamic sidebar，顾名思义，就是动态生成sidebar而不需要修改代码。而现在功能强大，不仅仅可以动态生成sidebar，页面的任何位置，只要设置了支持widgets就可以使用拖拽的方式来控制布局。
在安装了widgets插件后（wordpress2.2.x及以上版本无需安装），在Admin->Presentation->Widgets中，就可以看到所有页面上的widgets container和所有可以使用的widgets，需要做的就是将widgets拖拽到理想的区域就可以了。而且大多widgets还支持基于AJAX的设置页面，用户友好度也非常好。
实现一个widget也是非常惬意的一件事情。如果你有一个非widgetized的plugin那么只需要做很少的改动就可以把它变成一个widget。比如有一个plugin叫做recent_comments，原来你必须在sidebar.php中修改代码，加上相应的get_recent_comments()函数。现在只需要做一些改动，让这个plugin支持widget就可以直接拖拽了。大概是这个样子：

很久以前看到过一篇解释HTML中DOM的Box Model的文章（好像是在MSDN，有图示，很清楚）。最近在写Windows程序，遇到了一个要resize一个window，并且要相应移动它里面的controls的需求。趁这个机会研究了一下Windows的Box Model，发现竟然和DOM的Box Model是如此的相似。
首先介绍一下与其相关的一些API:

在来到新公司之前，对于Windows编程实在不熟悉，更别说VC++中的Resource的实现了。工作的时候，同事提到了StringTable实现本地化的问题。当时我也很模糊，说不出个准确答案。周末回家研究了两天，算是搞明白了。
先说说我之前比较困惑的几个问题：

在编译完成的二进制文件中，StringTable到底是按照什么方式存储的，简单说，就是按照什么编码方式存储的？
Windows已经支持了Unicode，为什么在VC++的StringTable Editor中，还要选择语言？
如果使用了Unicode，怎么有的时候，应用程序还会出现乱码？
如果是Unicode编码，那么是按照什么格式存储的，UTF-8，UTF-16？

当然，对于这些问题，可能对于一些牛人来说不算什么，都是很简单的问题。不过，对于我来说，还是很麻烦的，因为网上没有很直接解释这些问题的文章，最终还是自己一点一点研究出来的。
首先，需要复习和学习一些知识：
在计算机诞生的初期，操作系统只支持最多256个字符，就是著名的ASCII字符集。但是随着计算机在世界上各个国家的发展，本地化的需求越来越多，256个字符明显不够，就有一些国家发明了自己的字符集，也可以说是编码标准，不过这些编码方式都是只考虑自己国家的语言（当然不会有一个国家为了发展自己的科技，还要替别人着想），比如，ISO-8859-1，GB2312等等，在Windows里面，这类编码的体现就是我们熟悉的Code Page。在VC++中，Code Page是使用数字来代表的，比如：936是简体中文Code Page，1256是阿拉伯语言的Code Page。这样显然不爽，随着计算机的普及，Code Page会越来越多，并且很多Code Page可能相差不多，但是为了支持相应的用户，应用程序（包括操作系统）就不得不对之提供支持，这大大提高了软件的成本。终于，一些软件业的巨头决定做一件一劳永逸的事情，就是创造一个字符编码方式，能支持世界上所有的字符，这个字符集编码叫做Unicode。它设计可以支持11万多的字符，被认为足够放下世界上已知的所有字符（其中，中文字符占了2万多，英文只占52个）。而我们经常看到的UTF-8，UTF-16，UTF-32都是Unicode的一种存储方式。
言归正传，回答自己的四个问题：

从Windows2000开始，Windows已经完全支持了Unicode，所以StringTable在二进制文件（*.dll、*.exe）中确实是以Unicode编码存储的。
在StringTable Editor中，之所以要为StringTable选择相应的语言，是因为StringTable Editor中不是以Unicode存储的，而是基于Code Page编码存储的。所以必须对自己的StringTable选择正确的Code Page，否则系统将不能正确处理。因为在编译的时候，VC++的Resource Compiler会自动调用MultiByteToWideChar这个API，将字符串从Code Page编码方式转化为Unicode，如果Code Page选择不正确，那么转换也就必然不正确了。
出现乱码一个原因是操作系统不支持Unicode，比如Windows98之前的版本。或者是没有将默认编码设置为Unicode。
在Windows中都是使用UTF-16来存储Unicode的。UTF-16正好是两个字节，也就是我们使用的WCHAR类型。

需要说的是，StringTable Editor不是使用Unicode来存储，是因为历史原因。早期的VC++是不支持Unicode的。