今天在考虑键盘抽象和机器人问题。
为设备按键映射和键盘种类抽象并不难。键盘只有两种，数字键盘和QWERTY键盘，前者内嵌字母；后者内嵌数字。QWERTY的变种键盘，BB7100那种，就是一个减少了字母表的键盘。只有在全QWERTY的时候，能采用自动分隔composition的办法来处理，即使有模糊音的时候也是如此，因为前置模糊音并不会破坏分隔原则；但是其它的情况都只能被动匹配，即把字词的编码翻译成键盘码（字母或数字）然后匹配composition，这能处理字数>=或=问题（Longer），但是无法快速处理尾码渐进匹配（progressive），需要额外的数据表才行，否则就要遍历拼音表，这需要再考虑一下，暂无很好的解决方案。
现有的代码把匹配分到了不同的对象中完成，譬如字数过滤和Alpha过滤（允许匹配非拼音规则的英文、符号、网址、Email地址等等）在数据库搜索中解决。但是看起来这个代码得挪个地方了。因为在被动匹配的情况下，字数是在匹配之后才知道的。:(。这回到了我昨天写的C++封装心得：把类拆小，每个只实现单一功能。
按照你告诉别人的东西去做，你就成功了－－米兰·昆德拉
不过在现阶段，似乎没有必要把这个问题搞的很复杂。基本上考虑两种键盘就可以了，一种是Qwerty，包括Treo, HP65/69，Nokia E61，Moto Q，BenQ，Dopod，BB等都是这种键盘，区别只是内嵌数字键的方法不同；另外就是手机上的Numpad，好在手机上的Numpad内嵌字母的方式都是一样的，数据库无需更改。至于BB7100的键盘，其实也是不错的设计，可惜支持的手机不多，但是随着SE M600系列的发布，这种情况也许会有改观，毕竟SE品牌有着大批拥趸而且UIQ是Symbian最好的分支，只是不知道内置的中文输入法会不会让中国用户接受。
机器人问题比较麻烦。汉字分隔和拼音标注不是在一个小小的巨硬程序中能实现的，事实上，前者是中文搜索引擎的核心技术之一，后者是汉语言计算机处理上的难点课题。好在我要求并不高，前者在网上找到了一个免费程序，而后者可以购买拼音大师。除此之外还需要对格式做一些简单的正则表达式替换，工作量不大，用Editplus就可以解决，或者用Turbo C++写个简单的命令行程序就可以了。不过，这基本上可以让巨硬II具有主动学习功能（根据用户的短信和Memo来学习词频）的想法破灭了。:(。或者退一步，只能根据已有词组调整词频，不能通过学习自动造词了。
机器人问题还涉及到英文，数字，和符号的自动处理。其实这也和巨硬II中的保留History问题类似，只是以前没仔细考虑过。数字用通配符是比较好的做法。英文可以考虑成自动造词。但是符号问题比较棘手，尤其是混合在英文数字之中的符号。大致来说，符号分为三类，一类是中止符，比如逗号句号，会清除History；另一类是含义符，比如$，可以当作英文字符处理，还有一类是强制分词符号，可以当作是词与词之间的分隔，包括引号双引号书名号等等。在最初的时候，我只会考虑处理ASCII中的所有可打印符号和GBK中定义的可打印符号，至于Unicode中浩如烟海的符号，以后再说吧。:(
2006/05/31
2006/05/30
C++封装
巨硬的进度令人满意，不过在进入Debug之前，就进入了Refactoring阶段。Refactoring是软件工程的一个术语，我不知道怎么翻译，它的意思是在不改动需求和主体数据结构的情况下，对软件做优化，包括更清晰的组织代码，划分类功能，组织函数，重命名类和函数名等等。
Wikipedia的解释在这里：en.wikipedia.org/wiki/Refactoring (如果你能访问这篇Blog，那你也应该可以看到Wikipedia)。
之所以这样做是因为我并不着急launch这个程序，就像和newaa以及evan在网上聊天时所说到的，我本身并不把这个程序当成一个商品－－确切的说是仅仅当成一个商品。巨硬带有很多实验主义的色彩，也倾注了我对手持计算设备的热爱，也是我不断学习软件开发乃至软件工程的一个课程，同时它还是WEB2.0时代的一个契机－－虽然这只是一个输入法，但是它带来的更快捷的输入会改变人民对文字沟通的使用方式，而通过网络的文字沟通无疑是我们生活的这个时代发展最快的沟通手段之一。
一些软件工程高手常挂在嘴边的一句话是：软件工程从发布才开始。它指的是软件的功能维护，代码树维护，以及开发新的应用，拓展新的市场等等。至少到现在为止，我是打算接受这个挑战的，这也是我愿意重新打开CodeWarrior，重写巨硬II的最主要动因。从我的个性来说，我相当懒惰，而且不喜欢做重复的事情，如果只是用C重新写过巨硬并继续卖28元（或者一个美元）的话，我大概是不会做的。:)
Anyway，言归正传，如果你在看这个Blog的话，请不要催促我尽快发布巨硬II，也不要宣传巨硬II即将诞生。我会在适当的时候－－当我觉得它很完美的时候，虽然事实上它不可能是完美的－－发布它。这个时间不会很远，但是我不承诺一个严格的Deadline，这种压力只会使我在射门的时候动作变形，没什么其它的益处，我喜欢在最自由的空间里踢出最漂亮的弧线球－－相信我，我会踢出来的。我能承诺的只是，我每天至少拿出3个小时在代码工作上，无论工作和生活多紧张，事实上在过去的2-3个星期我就是这样做的，我还会继续这样做下去，直到巨硬II的诞生。
好了，回到今天Blog的主题，说说我对C++封装的浅薄理解－－你千万不要把它当作高手箴言，如果你想看高手箴言，我推荐你看豪杰解霸作者梁肇新撰写的《编程高手箴言》，或者10余年畅销不衰的Code Complete。我愿意写在这里，或者说写在这个几乎没人能看到的Blog里，就是颇有露怯之意，但是我还是愿意写下来，让明天的我看看昨天的我在想什么－－这也是Blog的原本之意吧。
C++的结构非常灵活，你可以用很多种方式封装类，但是不幸的地方在于类是静态的，而实际的程序中要考虑对象的生存周期。所以第一个原则就是，生存周期不同的功能组，应该封装到不同的类里面去。
常常会遇到这样的情况，很多不同的功能都和一个资源有关，所以容易产生这样的想法，把所有和该资源有关的功能都统统放到这个类里面去，渐渐的，这个类就膨胀起来了，会出现很多的工作状态，这些状态之间彼此制约，结果不但是容易产生错误，而且对使用这个类的对象来说，要深刻理解这个类的对象的工作状态，这就违反了封装的本意－－封装就是要只看到界面，而不必深入内部。
在一个类中留一个另一个类的指针并且在类初始化的时候赋值并不是什么坏主意，虽然这让人担心在指针实效的时候发生种种错误，但是在代码角度看，处理这些错误并不麻烦，而好处是，可以把对象的状态分开，容易理解。事实上那些被很多类调用的、用于封装排他资源的对象往往只有一个，在程序开始的时候初始化一下，然后传递给所有需要用到该资源的类，在这个类中可以很容易处理资源冲突情况，最后在程序退出前销毁；这是应付资源冲突的最好办法。资源冲突往往就像操作系统中的死锁问题一样，很多时候是不可避免的，用简单的失败处理代码来应付这种情况就可以了，这远比把事情搞的很复杂最终还是没有解决问题强。
C++中提供了虚函数和多态，这让代码看起来很优雅，但是虚函数往往需要实现该函数的类了解在基类中该函数被调用的具体过程，所以，不要写那些看起来很不易懂的虚函数，也不要让虚函数之间产生逻辑上的关联，不要为了让代码看起来更优雅一致或者更高深，而牺牲代码的易读性，易维护性，以及留下更多的犯错误的机会。通常在资源访问的问题上，虚函数是一个好主意，比如流，缓冲，或者数据库，它增加了代码的移植能力，因为大多数程序都必须和这些东西打交道。但是把程序自身的数据结构层层封装起来就不象是一个好主意，这需要使用者了解很多数据结构的含义和数据对象的状态－－和状态打交道是程序设计中最复杂的事情，尽量不要处理组合状态，否则一定会死的很难看。
在参数的传递上，要避免传递复杂的数据结构，应该只传递三种基本的东西：(1)基本数据类型，含义和范围明确(2)简单的数据结构，它们封装了程序的核心数据，到处都用得到(3)对象指针，这些对象是作为一个占有资源的"服务器"存在的，很多时候要用到它们提供的服务，但是，不要试图了解对象的状态。这可能会破坏过程的原子性，在多线程或者多进程的环境下产生莫名其妙的错误。
总而言之，不要惧怕写很多的类，类越小越好；也不要惧怕类之间的依赖性，这是很常见的，而且它是由程序的核心逻辑决定的，不是说你少写了几个类就可以让问题变得简单；类之间的关系应该是松散集成的，彼此了解的越少越好。状态之间不要关联，不要在多个对象之中试图维护步调一致的数据。多画一些图来研究状态之间的关联性，直到你确定可以把每种状态都分离出来，再开始Coding，如果在Coding过程中发现了状态之间的耦合问题，那就应该回到设计上来解决这个问题，然后再开始Coding。
好了，该去写代码了。
Wikipedia的解释在这里：en.wikipedia.org/wiki/Refactoring (如果你能访问这篇Blog，那你也应该可以看到Wikipedia)。
之所以这样做是因为我并不着急launch这个程序，就像和newaa以及evan在网上聊天时所说到的，我本身并不把这个程序当成一个商品－－确切的说是仅仅当成一个商品。巨硬带有很多实验主义的色彩，也倾注了我对手持计算设备的热爱，也是我不断学习软件开发乃至软件工程的一个课程，同时它还是WEB2.0时代的一个契机－－虽然这只是一个输入法，但是它带来的更快捷的输入会改变人民对文字沟通的使用方式，而通过网络的文字沟通无疑是我们生活的这个时代发展最快的沟通手段之一。
一些软件工程高手常挂在嘴边的一句话是：软件工程从发布才开始。它指的是软件的功能维护，代码树维护，以及开发新的应用，拓展新的市场等等。至少到现在为止，我是打算接受这个挑战的，这也是我愿意重新打开CodeWarrior，重写巨硬II的最主要动因。从我的个性来说，我相当懒惰，而且不喜欢做重复的事情，如果只是用C重新写过巨硬并继续卖28元（或者一个美元）的话，我大概是不会做的。:)
Anyway，言归正传，如果你在看这个Blog的话，请不要催促我尽快发布巨硬II，也不要宣传巨硬II即将诞生。我会在适当的时候－－当我觉得它很完美的时候，虽然事实上它不可能是完美的－－发布它。这个时间不会很远，但是我不承诺一个严格的Deadline，这种压力只会使我在射门的时候动作变形，没什么其它的益处，我喜欢在最自由的空间里踢出最漂亮的弧线球－－相信我，我会踢出来的。我能承诺的只是，我每天至少拿出3个小时在代码工作上，无论工作和生活多紧张，事实上在过去的2-3个星期我就是这样做的，我还会继续这样做下去，直到巨硬II的诞生。
好了，回到今天Blog的主题，说说我对C++封装的浅薄理解－－你千万不要把它当作高手箴言，如果你想看高手箴言，我推荐你看豪杰解霸作者梁肇新撰写的《编程高手箴言》，或者10余年畅销不衰的Code Complete。我愿意写在这里，或者说写在这个几乎没人能看到的Blog里，就是颇有露怯之意，但是我还是愿意写下来，让明天的我看看昨天的我在想什么－－这也是Blog的原本之意吧。
C++的结构非常灵活，你可以用很多种方式封装类，但是不幸的地方在于类是静态的，而实际的程序中要考虑对象的生存周期。所以第一个原则就是，生存周期不同的功能组，应该封装到不同的类里面去。
常常会遇到这样的情况，很多不同的功能都和一个资源有关，所以容易产生这样的想法，把所有和该资源有关的功能都统统放到这个类里面去，渐渐的，这个类就膨胀起来了，会出现很多的工作状态，这些状态之间彼此制约，结果不但是容易产生错误，而且对使用这个类的对象来说，要深刻理解这个类的对象的工作状态，这就违反了封装的本意－－封装就是要只看到界面，而不必深入内部。
在一个类中留一个另一个类的指针并且在类初始化的时候赋值并不是什么坏主意，虽然这让人担心在指针实效的时候发生种种错误，但是在代码角度看，处理这些错误并不麻烦，而好处是，可以把对象的状态分开，容易理解。事实上那些被很多类调用的、用于封装排他资源的对象往往只有一个，在程序开始的时候初始化一下，然后传递给所有需要用到该资源的类，在这个类中可以很容易处理资源冲突情况，最后在程序退出前销毁；这是应付资源冲突的最好办法。资源冲突往往就像操作系统中的死锁问题一样，很多时候是不可避免的，用简单的失败处理代码来应付这种情况就可以了，这远比把事情搞的很复杂最终还是没有解决问题强。
C++中提供了虚函数和多态，这让代码看起来很优雅，但是虚函数往往需要实现该函数的类了解在基类中该函数被调用的具体过程，所以，不要写那些看起来很不易懂的虚函数，也不要让虚函数之间产生逻辑上的关联，不要为了让代码看起来更优雅一致或者更高深，而牺牲代码的易读性，易维护性，以及留下更多的犯错误的机会。通常在资源访问的问题上，虚函数是一个好主意，比如流，缓冲，或者数据库，它增加了代码的移植能力，因为大多数程序都必须和这些东西打交道。但是把程序自身的数据结构层层封装起来就不象是一个好主意，这需要使用者了解很多数据结构的含义和数据对象的状态－－和状态打交道是程序设计中最复杂的事情，尽量不要处理组合状态，否则一定会死的很难看。
在参数的传递上，要避免传递复杂的数据结构，应该只传递三种基本的东西：(1)基本数据类型，含义和范围明确(2)简单的数据结构，它们封装了程序的核心数据，到处都用得到(3)对象指针，这些对象是作为一个占有资源的"服务器"存在的，很多时候要用到它们提供的服务，但是，不要试图了解对象的状态。这可能会破坏过程的原子性，在多线程或者多进程的环境下产生莫名其妙的错误。
总而言之，不要惧怕写很多的类，类越小越好；也不要惧怕类之间的依赖性，这是很常见的，而且它是由程序的核心逻辑决定的，不是说你少写了几个类就可以让问题变得简单；类之间的关系应该是松散集成的，彼此了解的越少越好。状态之间不要关联，不要在多个对象之中试图维护步调一致的数据。多画一些图来研究状态之间的关联性，直到你确定可以把每种状态都分离出来，再开始Coding，如果在Coding过程中发现了状态之间的耦合问题，那就应该回到设计上来解决这个问题，然后再开始Coding。
好了，该去写代码了。
2006/05/26
巨硬II，pDatabase & pRecord
又是一个不眠之夜。
巨硬的代码进度令人满意，虽然不快，但是在MM（MindManager）的帮助下清晰有序的进行着。先前写的一些基本类都派上了用场，对PalmOS Programming的理解也小有收获。
大致说来有这么几个问题：
1) PalmOS的存储方式非常特殊，高效，但不太适合C++封装，用C写怎么都思如涌泉，用C++就经常犯愁：尤其是用指针还是用集合类的问题。
2) CodeWarrior里面自带的POL类库是MFC风格，但有些封装过渡，大量的使用模板，提供RTTI能力，丰富的Stream类，对于大多数Palm风格的小程序来说，这个封装过于臃肿，反而带来不变，譬如弹出式程序就不能使用全局变量，POL的类就根本没办法使用；窗口也不能想弹就弹；截取硬按键也是个麻烦。还有就是对于Record的流式存储，乍一看，形式上很漂亮，但是不符合Storage Heap的数据库本质，密集访问的时候效率也成问题。
3) 自己从POL中抄袭篡改而来的pDatabase/pRecord类，个人认为更符合PalmOS的数据访问要求，提供的Insert，Overwrite，Replace，Erase等直接对Record写入的函数，远比流方便，效率也更高。
4) 数据库程序有个完整性要求，应避免多步更新永久存储数据，所以更新数据时务必要使用DmAttachRecord，而不是使用DmWrite多次写入；除此之外，pRecord类中还包含了一个MemHandle，允许用户多次写入然后一次提交生效，如果在写入过程中程序遇到错误，则不会修改任何存储数据。
5) 这种Commit方式，在不得不同时更新多个记录的时候更加重要，尤其是在遇到低内存的时候，如果依次更新，那可能DmNewHandle都会失败；如果要同时更新多条记录，可以用多个pRecord执行更新操作，然后全部CommitCheck－－这个步骤是检查内存Lock情况，如果全部通过就一次全部Commit，虽然不是说绝对不会出问题，但是做到这个地步，出错的可能性和彗星撞地球差不多了吧。
6) PalmOS的数据库信息操作异常烦琐，pDatabase中规划的InitAppInfo通过三次调用才实现了高效封装－－这是从POL里学来的。不过封装之后，派生类只要实现虚函数就可以了，用起来还是很方便的。
7) C++中的错误处理机制在PalmOS中不易实现，出了问题Debug也麻烦；所以还是使用了传统的返回Err方式。不过要小心的是构造函数和析构函数是不能返回值的，所以不要在构造函数和析构函数中调用任何可能返回Err的操作，包括打开数据库读写或者申请内存之类，可能后果严重。应该为类提供单独的Init或者Open函数来完成这个要求。
8) 数据库的工作模式很值得探讨。如果为了方便从pDatabase派生或者包含了该数据作为成员，很有可能为了提高速度把一些记录或者AppInfo锁定，但是这样就会给数据库的维护造成麻烦，把数据库的维护函数都写成static并不是好办法，这就走回C的老路上去了。更好的办法是把函数分为两类，一类工作在normal模式下，该模式下可以锁定数据库中的记录；另一类是维护模式，即把所有锁定记录的指针全部release掉，这在pDatabase中通过两个虚函数来实现，一个是InitInternals，一个是DeinitInternals。
9) 从效率出发的话，Normal模式下应该尽量多的锁定和传递指针；而Maintenance模式下，尽量避免使用指针，取而代之使用C++类，是更好的办法，依据这个原则就可以混合C/C++代码，写出既高效又易维护的代码来。
10) 最后一个问题是PalmOS的排序，如果使用C++，没办法传递动态的DmComparF函数给系统，这挺头疼的，不然在pDatabase里写一个Compare虚函数是非常漂亮的；如果非要这样用的话，没办法的办法是写一个Find虚函数，反正最终继承的数据库类知道自己的数据格式，不过这样做给人的感觉总象苹果里的虫子，所以，还是尽可能在数据库设计的时候把排序的Field直接写在Record头上，以避免需要从记录中提取出对象才能比较。
这两个类代码，在写完巨硬II之后好好整理一下，然后可以共享出来大家探讨了。
巨硬的代码进度令人满意，虽然不快，但是在MM（MindManager）的帮助下清晰有序的进行着。先前写的一些基本类都派上了用场，对PalmOS Programming的理解也小有收获。
大致说来有这么几个问题：
1) PalmOS的存储方式非常特殊，高效，但不太适合C++封装，用C写怎么都思如涌泉，用C++就经常犯愁：尤其是用指针还是用集合类的问题。
2) CodeWarrior里面自带的POL类库是MFC风格，但有些封装过渡，大量的使用模板，提供RTTI能力，丰富的Stream类，对于大多数Palm风格的小程序来说，这个封装过于臃肿，反而带来不变，譬如弹出式程序就不能使用全局变量，POL的类就根本没办法使用；窗口也不能想弹就弹；截取硬按键也是个麻烦。还有就是对于Record的流式存储，乍一看，形式上很漂亮，但是不符合Storage Heap的数据库本质，密集访问的时候效率也成问题。
3) 自己从POL中抄袭篡改而来的pDatabase/pRecord类，个人认为更符合PalmOS的数据访问要求，提供的Insert，Overwrite，Replace，Erase等直接对Record写入的函数，远比流方便，效率也更高。
4) 数据库程序有个完整性要求，应避免多步更新永久存储数据，所以更新数据时务必要使用DmAttachRecord，而不是使用DmWrite多次写入；除此之外，pRecord类中还包含了一个MemHandle，允许用户多次写入然后一次提交生效，如果在写入过程中程序遇到错误，则不会修改任何存储数据。
5) 这种Commit方式，在不得不同时更新多个记录的时候更加重要，尤其是在遇到低内存的时候，如果依次更新，那可能DmNewHandle都会失败；如果要同时更新多条记录，可以用多个pRecord执行更新操作，然后全部CommitCheck－－这个步骤是检查内存Lock情况，如果全部通过就一次全部Commit，虽然不是说绝对不会出问题，但是做到这个地步，出错的可能性和彗星撞地球差不多了吧。
6) PalmOS的数据库信息操作异常烦琐，pDatabase中规划的InitAppInfo通过三次调用才实现了高效封装－－这是从POL里学来的。不过封装之后，派生类只要实现虚函数就可以了，用起来还是很方便的。
7) C++中的错误处理机制在PalmOS中不易实现，出了问题Debug也麻烦；所以还是使用了传统的返回Err方式。不过要小心的是构造函数和析构函数是不能返回值的，所以不要在构造函数和析构函数中调用任何可能返回Err的操作，包括打开数据库读写或者申请内存之类，可能后果严重。应该为类提供单独的Init或者Open函数来完成这个要求。
8) 数据库的工作模式很值得探讨。如果为了方便从pDatabase派生或者包含了该数据作为成员，很有可能为了提高速度把一些记录或者AppInfo锁定，但是这样就会给数据库的维护造成麻烦，把数据库的维护函数都写成static并不是好办法，这就走回C的老路上去了。更好的办法是把函数分为两类，一类工作在normal模式下，该模式下可以锁定数据库中的记录；另一类是维护模式，即把所有锁定记录的指针全部release掉，这在pDatabase中通过两个虚函数来实现，一个是InitInternals，一个是DeinitInternals。
9) 从效率出发的话，Normal模式下应该尽量多的锁定和传递指针；而Maintenance模式下，尽量避免使用指针，取而代之使用C++类，是更好的办法，依据这个原则就可以混合C/C++代码，写出既高效又易维护的代码来。
10) 最后一个问题是PalmOS的排序，如果使用C++，没办法传递动态的DmComparF函数给系统，这挺头疼的，不然在pDatabase里写一个Compare虚函数是非常漂亮的；如果非要这样用的话，没办法的办法是写一个Find虚函数，反正最终继承的数据库类知道自己的数据格式，不过这样做给人的感觉总象苹果里的虫子，所以，还是尽可能在数据库设计的时候把排序的Field直接写在Record头上，以避免需要从记录中提取出对象才能比较。
这两个类代码，在写完巨硬II之后好好整理一下，然后可以共享出来大家探讨了。
2006/05/23
MindManager & 巨硬II (continued)
MindManager果然不是盖的，是我目前用过的最适合我的辅助设计工具，虽然它没有针对开发设计功能，但是在辅助设计方面非常棒。下周有时间的时候我写个详细的评测出来。
巨硬II在MindManager的帮助下迅速走上正轨，很快就可以再度回到代码阶段。大部分算法问题现在都有了着落。唯一遇到的问题是，新的巨硬设计大量统计汉语的词序相关性，目前找不到这方面的资料和数据，恐怕在完工之后得写个机器人程序才行。因为仅仅在设备上Training的话，多数用户的输入量很小，很难快速进入较好的预测状态。这是个不大不小的麻烦。
在巨硬II的设计过程中，我对新算法越来越有信心。举个例子，下班的时候我想发这样一条短信：晚上回来吃饭吗。在现有的巨硬中，
1)先按w键，出现候选字[我，为，完，晚，王]，这里至少有两个明显的问题(1)[完]字出现在一句话的句首，是不是很罕见的情况？(2)[晚]其实是一个很少单独使用的字，为什么不能直接出现[晚上]呢？
2)输入[晚上]之后按h键，出现候选字[和，号，很，好，还]，这里的[号]字几乎是不可能出现在[晚上]一词之后的，[和，很，还]也是可能性很低的。
3)输入[回来]之后按c键，出现候选字[陈，吃，车，从，程]，除了[吃]字之外，其它几个字也相当莫名其妙。
4)输入吃饭之后按m键，出现候选字[吗，卖，买，没，马]，同样，[买，卖，马]出现在[吃饭]一词之后也是不合常理的，象[买]和[卖]这样几乎只会单独使用的动词很容易以高词频姿态出现在前面，但是其实只有非常少的词可以放在前面搭配的。
在使用简码的情况下，这句话键入了ws#hl#cf#m，一共10键。而巨硬II追求的目标是：w#h#c#m，而如果这句话你经常写，那么最好的情况应该是w####，:)。能做到吗？现在还不知道，但是这绝对worth a trial。你觉得呢？
注：#代表选字键，在巨硬上可以是四大天王加空格键中的一个，视目标词语出现的位置而定。
巨硬II在MindManager的帮助下迅速走上正轨，很快就可以再度回到代码阶段。大部分算法问题现在都有了着落。唯一遇到的问题是，新的巨硬设计大量统计汉语的词序相关性，目前找不到这方面的资料和数据，恐怕在完工之后得写个机器人程序才行。因为仅仅在设备上Training的话，多数用户的输入量很小，很难快速进入较好的预测状态。这是个不大不小的麻烦。
在巨硬II的设计过程中，我对新算法越来越有信心。举个例子，下班的时候我想发这样一条短信：晚上回来吃饭吗。在现有的巨硬中，
1)先按w键，出现候选字[我，为，完，晚，王]，这里至少有两个明显的问题(1)[完]字出现在一句话的句首，是不是很罕见的情况？(2)[晚]其实是一个很少单独使用的字，为什么不能直接出现[晚上]呢？
2)输入[晚上]之后按h键，出现候选字[和，号，很，好，还]，这里的[号]字几乎是不可能出现在[晚上]一词之后的，[和，很，还]也是可能性很低的。
3)输入[回来]之后按c键，出现候选字[陈，吃，车，从，程]，除了[吃]字之外，其它几个字也相当莫名其妙。
4)输入吃饭之后按m键，出现候选字[吗，卖，买，没，马]，同样，[买，卖，马]出现在[吃饭]一词之后也是不合常理的，象[买]和[卖]这样几乎只会单独使用的动词很容易以高词频姿态出现在前面，但是其实只有非常少的词可以放在前面搭配的。
在使用简码的情况下，这句话键入了ws#hl#cf#m，一共10键。而巨硬II追求的目标是：w#h#c#m，而如果这句话你经常写，那么最好的情况应该是w####，:)。能做到吗？现在还不知道，但是这绝对worth a trial。你觉得呢？
注：#代表选字键，在巨硬上可以是四大天王加空格键中的一个，视目标词语出现的位置而定。
2006/05/22
MindManager & 巨硬II
周末卸载Visual Studio的时候，电脑的IE被击落，重装了系统。
巨硬没有任何进展。
和一个程序员朋友谈了巨硬II的构思，没有得到肯定也没有被否定，最后定位在实验主义程序上。
虽然一直极力想摆脱Palm的C-Style，但是考虑到最后发现，在PalmOS上还是用C最好，C++的封装益处并不大。这会导致前面很多代码要重新写过，不过好在工作量并不大。
遵循PalmOS的C-Style，原本设计的核心存储结构被推倒重来，用紧凑的C指针风格来处理最常见的数据库查询与遍历，而且有可能核心算法的代码可以写成Armlet，这会进一步提高执行速度。
还有一个搞笑且让人惭愧的事情。我企图在网上搜一些汉语字频词频的统计资料，发现很少，唯一找到的一个83年的资料，几乎没有任何价值，革命主义一类的词遥遥领先的排在前面，估计是用人民日报统计的。后来灵机一动，想到老外也要学汉语的，还要过有中文托福之称的HSK考试，于是以HSK Vocabulary作为关键词GooGle，找到了一份词汇表，共有1900个单字，6200个双字词，200个三字词和300个四字词，非常口语化，很适合巨硬。
最后应该记下来的一件事情是，为了让巨硬的开发比较有条理，试用了一下MindManager，第一印象非常不错，比用Word或者PPT写大纲方便多了。体现在两个方面：
1. 可以对整个项目有个总览。
2. 可以方便的Cut/Paste，用文本做这个很辛苦。
3. MindManager的设计很贴心，有大量的图标可用，标记优先级，进度，决策，状况。
4. 可以任意设定Relationship，这对程序设计来说非常重要，很多功能模块之间都有制约。
5. 直观。
I Love Colors!
巨硬没有任何进展。
和一个程序员朋友谈了巨硬II的构思，没有得到肯定也没有被否定，最后定位在实验主义程序上。
虽然一直极力想摆脱Palm的C-Style，但是考虑到最后发现，在PalmOS上还是用C最好，C++的封装益处并不大。这会导致前面很多代码要重新写过，不过好在工作量并不大。
遵循PalmOS的C-Style，原本设计的核心存储结构被推倒重来，用紧凑的C指针风格来处理最常见的数据库查询与遍历，而且有可能核心算法的代码可以写成Armlet，这会进一步提高执行速度。
还有一个搞笑且让人惭愧的事情。我企图在网上搜一些汉语字频词频的统计资料，发现很少，唯一找到的一个83年的资料，几乎没有任何价值，革命主义一类的词遥遥领先的排在前面，估计是用人民日报统计的。后来灵机一动，想到老外也要学汉语的，还要过有中文托福之称的HSK考试，于是以HSK Vocabulary作为关键词GooGle，找到了一份词汇表，共有1900个单字，6200个双字词，200个三字词和300个四字词，非常口语化，很适合巨硬。
最后应该记下来的一件事情是，为了让巨硬的开发比较有条理，试用了一下MindManager，第一印象非常不错，比用Word或者PPT写大纲方便多了。体现在两个方面：
1. 可以对整个项目有个总览。
2. 可以方便的Cut/Paste，用文本做这个很辛苦。
3. MindManager的设计很贴心，有大量的图标可用，标记优先级，进度，决策，状况。
4. 可以任意设定Relationship，这对程序设计来说非常重要，很多功能模块之间都有制约。
5. 直观。
I Love Colors!
2006/05/20
巨硬II
昨天和Newaa聊了很久，被拍了很多受用的MP，心里甜蜜蜜的。
但是他竟然是在用Treo和我MSN了两个小时，我都没有发现。这让我越发觉得有义务把巨硬的代码重新写过－－无论自己对代码是多么的不在行。
话说回来，虽然很多人把巨硬推举为革命性的输入法，但是事实上它不是。受到用户追捧的原因是在巨硬之前没有一个手机或者PDA上的输入法可以把输入速度推向PC上输入速度的50%左右－－这是我实际比较的结果，尽管一些热爱巨硬的用户声称巨硬的输入速度可以媲美PC，但是事实上它还做不到。如果把巨硬硬碰硬的和紫光或者拼音加加相比，它在算法上并没有明显高明的地方，也许里面有些自以为得计的小Trick，但是我相信每个程序中都有这类的东西，每个程序都是凝聚了程序员心血的东西－－如果程序员思考的时间超过了编码时间的话。
作为作者，我认为巨硬在过去的两年中被追捧并不是软件本身的水平有多高，而是反映了这个领域的程序员缺乏钻研精神。用陈道明的话说，这属于水落石出，而不是水涨船高。
巨硬中真正有原创性的地方只有一个，就是用上下两排五个按键映射选字，这在手持设备上是革命性的，而且巨硬也充分利用了五向键，保持了Treo引以为毫的兼顾单双手操作特性，为掌上设备输入设立了标准。
巨硬的代码丢了之后，一直有想法重写，但是缺乏动力，尤其是650出来之后竟然巨硬仍然能用，这更加给了我偷懒的理由。
不过我是个手懒但是脑子不懒的人，在过去的两年中，我花了大量的时间考虑巨硬二代应该带给用户什么，曾经考虑过很多方向，也写了大量的文档，但是这个问题的真正答案，直到最近6个月才越来越清晰，直至驱动我心甘情愿的做下来，为了一个美好的愿景进入艰苦的编码工作。
Jobs说，你应该喜欢你的IDEA。窃以为然。
在原来庞杂的规划中，包括拓展平台和拓展输入法框架等等，都不会在巨硬二代中出现了，这些东西不该是目前一个个人程序员该做的，如果要做，或者有机会有资源来作，那我也会考虑成立一家公司来做这个事情，但是不是现在。
现在让我们仍然回到起点上来，我现在可以说的就是巨硬二代在界面上绝不会带来更多的视觉或者功能因素，它可能看起来比巨硬一更简陋（这取决于我有多懒）。巨硬二代的进步将是内在的，但是它绝对是你可以感觉到的，它可以在Qwerty设备上比巨硬一代提高50%左右的速度，可以在数字键盘设备上达到接近一代巨硬的速度。而且我很有把握的说，它把中文输入法带入一个全新的领域。这个飞跃就像从Windows内置全拼过渡到拼音加加一样。它会全面超越现在流行的拼音加加或者紫光拼音输入法。我不敢说我是第一个这样做中文输入法的人，中文输入法不下500种，但是在目前我用过的各种输入方法中，我从未见过这样的产品。
但是他竟然是在用Treo和我MSN了两个小时，我都没有发现。这让我越发觉得有义务把巨硬的代码重新写过－－无论自己对代码是多么的不在行。
话说回来，虽然很多人把巨硬推举为革命性的输入法，但是事实上它不是。受到用户追捧的原因是在巨硬之前没有一个手机或者PDA上的输入法可以把输入速度推向PC上输入速度的50%左右－－这是我实际比较的结果，尽管一些热爱巨硬的用户声称巨硬的输入速度可以媲美PC，但是事实上它还做不到。如果把巨硬硬碰硬的和紫光或者拼音加加相比，它在算法上并没有明显高明的地方，也许里面有些自以为得计的小Trick，但是我相信每个程序中都有这类的东西，每个程序都是凝聚了程序员心血的东西－－如果程序员思考的时间超过了编码时间的话。
作为作者，我认为巨硬在过去的两年中被追捧并不是软件本身的水平有多高，而是反映了这个领域的程序员缺乏钻研精神。用陈道明的话说，这属于水落石出，而不是水涨船高。
巨硬中真正有原创性的地方只有一个，就是用上下两排五个按键映射选字，这在手持设备上是革命性的，而且巨硬也充分利用了五向键，保持了Treo引以为毫的兼顾单双手操作特性，为掌上设备输入设立了标准。
巨硬的代码丢了之后，一直有想法重写，但是缺乏动力，尤其是650出来之后竟然巨硬仍然能用，这更加给了我偷懒的理由。
不过我是个手懒但是脑子不懒的人，在过去的两年中，我花了大量的时间考虑巨硬二代应该带给用户什么，曾经考虑过很多方向，也写了大量的文档，但是这个问题的真正答案，直到最近6个月才越来越清晰，直至驱动我心甘情愿的做下来，为了一个美好的愿景进入艰苦的编码工作。
Jobs说，你应该喜欢你的IDEA。窃以为然。
在原来庞杂的规划中，包括拓展平台和拓展输入法框架等等，都不会在巨硬二代中出现了，这些东西不该是目前一个个人程序员该做的，如果要做，或者有机会有资源来作，那我也会考虑成立一家公司来做这个事情，但是不是现在。
现在让我们仍然回到起点上来，我现在可以说的就是巨硬二代在界面上绝不会带来更多的视觉或者功能因素，它可能看起来比巨硬一更简陋（这取决于我有多懒）。巨硬二代的进步将是内在的，但是它绝对是你可以感觉到的，它可以在Qwerty设备上比巨硬一代提高50%左右的速度，可以在数字键盘设备上达到接近一代巨硬的速度。而且我很有把握的说，它把中文输入法带入一个全新的领域。这个飞跃就像从Windows内置全拼过渡到拼音加加一样。它会全面超越现在流行的拼音加加或者紫光拼音输入法。我不敢说我是第一个这样做中文输入法的人，中文输入法不下500种，但是在目前我用过的各种输入方法中，我从未见过这样的产品。
Axosoft OneTime & MSDE 2000
今天想找一些软件开发用的项目管理软件。在网上看到了一些选择，不过大多不容易找破解版，而且目前几乎没有单机版的这类软件了。
最后选择了axosoft的OnTime 4.2.6，最新版是6.x，可惜没破解。
该软件需要MSDE或者其他版本的SQL Server作为数据库后台，于是下了一个MSDE装上，却不懂配置。照例GooGle了一下，发现需要运行svrnetcn.exe来配置。另外设置的时候如果setup.exe后没有配置security mode，那缺省就使用windows认证，而不是SQL认证。
下面这个链接是很不错的参考，对只是用MSDE作为程序后台的用户来说，够用了。
http://www.codeproject.com/database/ConfigureMSDE.asp
最后选择了axosoft的OnTime 4.2.6，最新版是6.x，可惜没破解。
该软件需要MSDE或者其他版本的SQL Server作为数据库后台，于是下了一个MSDE装上，却不懂配置。照例GooGle了一下，发现需要运行svrnetcn.exe来配置。另外设置的时候如果setup.exe后没有配置security mode，那缺省就使用windows认证，而不是SQL认证。
下面这个链接是很不错的参考，对只是用MSDE作为程序后台的用户来说，够用了。
http://www.codeproject.com/database/ConfigureMSDE.asp
Subscribe to:
Comments (Atom)
