笔记

1. 关于反向引用的RegEx匹配的想法：应该对目标串根据一定的规则总结特征进行无损压缩，压缩后的结果是一个新的串和辅助信息。初步设想，通过这样一个预处理，能识别出很多多项式的情况。问题：

a) 是否有一个方法能识别出所有的情况？

b) 是否需要多个不同的压缩方法？

可行的实验：设计一个压缩和提取特征的算法，观察它的表现。其中模式经过一定处理后，直接作用于这个压缩后的串。

其实这个事情相当SB。为了支持反向引用，必然就不支持输入流，因为支持了也没意义：就像上次笔记记录的，我们总要记录大规模的线索信息，而这些信息很多时候代表了大多数已经读过的内容（对于回溯式的算法往往就是串本身）。只处理完整串必然能带来更多的优化（虽然现在流行的RegEx引擎全都没有进行任何优化），但是匹配器能够处理的输入规模必然就要缩小了。

看来从适用性的角度来讲，匹配器应该分为两个：正则（或者更强一点的上下文无关）和RegEx（同理，上下文相关），用在不同的场合；反正用户总是知道自己要处理的是流还是串，很多人想找一个用于流的纯正则only匹配器也不至于找不到了。

 

2. 关于Android和其它基于Linux的操作系统的一些想法。

a) 能否把Android的Java运行时单独提取出来。能否简单的给这个运行时适配上其它不那么SB的语言。

b) 可行的一个实验：移植Meego到一个Android的机器，看看是否很容易用同一个内核和同一原生组库支撑各种Linux Based“操作系统”。考察Meego做兼容和二次开发的难度。

c) 实际上这里只有两部分：一个能提供全部硬件功能的内核（及用户态硬件支持库）和多种上层运行时。这两部分中间是一些适配工作。

 

3. 关于手头的事情。掌握好实现、和合理的设计之间的平衡。如果一味追求实现，不要说到长远，很重要的一个事情是也许眼前很快就要遭受报应：比如复杂的解决方案；但也不能总是认为合理的设计是最重要的，因为开发过程中总会因为具体需求的进一步挖掘发现先前设计上的不足。

a) 另外一个需要仔细考虑的问题是统一的界面和背后的真实机制。一个界面后面可以同时由不同的机制来支持，统一界面的好处是降低其它组件的复杂性；不过必须注意分辨的是，不同的机制是否真的不需要暴露自己的特性；对于其它组件，是否存在可能性需要知道具体机制的某些信息。

如果答案是不需要，目前的实践来看，似乎在其它组件上分别处理并不导致更快的开发速度，哪怕仅有很少的两、三个机制要分别处理。因为协议本身要变复杂，这就成了一个双向的东西：提供机制的一方也会因为处理这些约定和协议变复杂。不过对“不需要”的答案要慎重，避免类似于抽象泄露的情况带来更大的麻烦。

b) 在项目的大多数的阶段，设计一定是会变化的，甚至在某些情况下会趋于频繁。但由于设计和实现总是同步进行的（而且目前的认识是必须同步进行），其结果就可能造成心理上的影响，对已经有相关实现的部分、尤其是外围部件有实做的部分的设计，很不愿意变动。这一方面是因为惰性：我们都不愿意重新适配实现好的部分；另一方面可能是害怕设计的变动引入新的不确定因素。

不过看起来目前对设计和实现这一对儿相互促进的活动的安排还是合理的，虽然心态上受了影响，但并没有发现在设计变动时会有太多的工作量产生。这是由于整体切割、自底向上的开发方式在很大程度上即避免了自底向上的随意性又避免了自顶向下频繁出现意料之外所带来的好处。不过要注意的一点是，具体某部分从胶水式或实验性设计向有规划的设计的演变，其时机要抓准。早了就会产生和自顶向下同样的问题，晚了就会使具体设计和实现两方面的复杂性同时上升；关于后者的部分讨论见(a)。

 

4. 关于在线富文本编辑器。能否直接自己实现一个更小、更符合需求的？毕竟eidtable以后其实并没有什么工作要做；而且现在其它的足够小的似乎在质量上总有不少这样那样不大但烦人的缺陷。在这里确实不能体会很多网站包括大型网站为啥用第三方的，搞的这个活儿很有技术含量或者工作量（包括维护和扩展）非常大似的。

说实话这个小问题却让我比较烦恼。因为更深层次的，我如何决定并且最终取得什么结果，预示着我在技术上是太自负了，还是信心有点不足。关键是用合适的心态处理这些鸡零狗碎的问题。不过现在跨圈子看过了这么多不同的产品，也都有一些实践，我觉得这个发现还是真实的：真正难的没什么人搞；没太大价值的虽然车轮很多，却没一个真正让人舒心的。

前者是水平问题，后者并不是：谁又能猜中和覆盖每一个人的使用场景呢？所以我的想法是为啥大家不多深造一下，多解决些更难的问题或者创造些没见过的东西呢？