猛禽的归档8挂
貌似mblogger已经升级了半个多月快一个月了吧，但是还是不稳定啊。
昨天晚上上来看看，结果打开一个页面要等好几分钟，好不容易打开了，写了一堆回复，结果一提交又要等半天，更可气的是等了半天的结果是看到那个恶心8拉黄8拉J的.net出错页面。
简直要抓狂。
偶已经关停或废弃N个BLOG，包括：blogcn, blogchina, blogdriver, blogsome, uublog, yahoo360, msn space…
现在还在用的就剩下mblogger, csdn和donews了。
对于blogger来说，BSP的稳定性和速度是最重要的两个因素，其它都是可以接受的。
快点搞好吧，老大，拜托了。
昨天临下班前跟猎手讨论了一个技术问题。今天令狐看了，指出这个解决方法治标不治本，属于头痛医头脚痛医脚的解决方案：
但要是你直接取parent的ActiveControl，这个窗体不嵌入其他窗体的时候不是又错了？换句话说，这个窗体跟它的使用环境发生了耦合。有没有比较好的办法来解决这个问题？
我说了三个方法，前两个都不算是通用的办法，就不说了。第三个就是我在《杂而不精》一文里我提到过的MVC模式。在这一点上，我和令狐达成一致。针对猎手这个问题使用MVC，可以把这部分功能从View剥离到Control上去处理。
关于MVC，令狐有一段说明：
VCL中有一个Action的概念，但光有这个，支持MVC开发是远远不够的。这也是我在《杂而不精》中说过，我一直在思考的问题，早就想写一个文章来说的，不过感觉想法还不够成熟。今天既然拿来讨论了，就先简单空谈一下。
RAD让人养成很多坏习惯。比如，即使有Action这样的，做出MVC也会不伦不类，V和C的耦合度会很高的，这很不好。我设想的是RAD只做V的部分，将C部分完全剥离，这样GUI应用就会成为可测试的，用单元测试覆盖C和M。
令狐指出其中可能存在的一个问题：
VCL的问题我以前也想过，我觉得是因为VCL本身对MVC的支持就不够好。因为VCL中，已经将C的东西融合到控件本身去了，这样你再想剥离就很困难。我以前在CSDN上帮人写过一个MVC的演示，就碰到过这个问题。
举个例子，比如TMemo的Lines，存储了Memo中的内容，而这个Lines是跟TMemo本身的操作又是相关的。我那时候是自己用一个List去记录数据，但是这样一来，就会造成Lines和我自己那份数据的重复，而且有不同步的潜在可能。后来我的解决方法是完全放弃Lines，每次我自己的list更新之后，将Lines清空重新设置。不过这样对显示效果又有影响。
但我认为还是可以剥离的，这跟VCL的关系不太大。我在最近写的一个BLOG备份程序的GUI部分里就尝试用MVC的思想，感觉还可以。至于令狐上面的说的问题，也是可以解决的。
Memo的Lines属性是一个TStrings *。在Control里维护一个TString *成员指向Memo的Lines即可，由Control直接去维护Memo的Lines，这样就不存在一式两份的问题。因为Memo的Lines属性是不可更改的，所以只能通过Control去操作。不过程序中的其它代码不能直接对Memo的Lines进行操作，而是要通过Control进行。
把我的思路总结一下就是这样：
我把V和C之间的关系简化为三种：Action, State, Contraint
Action代表对界面的操作，调用Control的相应函数处理
State代表界面状态的改变，由Control去执行
Constraint代表约束，即Action和State的关联，比如在某种状态下不能出现某个Action
这个Constriant又有两种，强约束和弱约束
弱约束可以在View中实现
强约束可能在Control中实现，也可能在Model中实现
有必要补充一下：其中关于Constraint的想法，最早来自于去年与Chechy讨论他的一个基于XML的框架时受到的启发。
实际上弱约束的情况很少，它通常不能算作业务逻辑的一部分，为了简单起见才把它放在VIEW这边实现。如令狐所说，弱约束差不多就是指控件Disable或者Invisible这种。不过有些Disable/Invisible可能还是要放到Control里的。
令狐作了一下归纳：
用户对界面元素进行一个操作，发出一个request，实际触发一个控件事件，这个事件将会调用Control，Control继续调用业务模块，业务模块完成实际业务逻辑并返回，根据返回值，Control做两种可能的操作：转向另一个页面，或改变当前页面的某些状态（或两者兼具）；而页面上的控件由View类负责，View类接受到状态改变后，对控件实际的表现形式进行对应修改。
整个流程是：
View’sEvent->Process Control->Business Control->Model->Modelreturn->Business Control return->Process Cotrol’s state change ORopen new view->View class(change form’s control)
基本上就是这样，这样做还有一个很大的好外就是，可以比较方便地更换VIEW层。比如从PC移到PDA，或移到WEB。
令狐补充了一点：
这样的话，View层由两部分组成：Form和View class，Form负责可视化、用户事件接收，Viewclass负责处理状态的改变。然后，你所谓的强约束，可以几乎肯定是做在Process Control或BusinessControl层；而弱约束，几乎肯定是做在View Class
如果考虑到View层的更换，是必须加入View Class的，这是我开始没有考虑到的，我原来设想中这部分功能是在control里的。所以还是有很多不够成熟的地方，需要再讨论讨论。最主要的是需要经过实践的考验才行。
令狐又提了两个重要的问题：
1、Windows的控件有的时候是界面相应先于逻辑处理，比如Checkbox，你一点它就直接改变状态了，但是后端的逻辑处理可能又会重复修改它的状态。
2、还有个更严重的问题，对某些控件状态或内容的修改，会触发一些事件，这样会造成一些事件的递归调用或Control的难以控制
在传统的Web程序中，这个问题比较不明显，因为你在View上做的操作都不会产生实际的影响，直到Submit才会去服务器进行MVC的流程，但是客户端就没这么简单了，每个操作都可能会这样跑一圈
事实上，这两个问题在传统RAD开发中都存在，特别是第二个问题尤其严重，并且都很难解决。我起初考虑在GUI应用开发中采用MVC模式，很重要的一个原因就是为了解决如上面的第二个问题。
对于第一个问题是这样：当check时就会产生Action，它调用到control这边时就可以根据情况处理，如果知道这是一个需要Model做长时间处理的，就可以先改变界面的状态，比如把光标设置成hourglass，在Model处理完成之后再更新checkbox状态，并恢复光标。当然，最终的状态要以Model的处理结果而定，由control去更新view的state。
而第二个问题的解决之道就在于所有的Event都会转为Control的Action请求，当第一个请求到达Control时，就会启动相关的Constraint。之后的请求就会根据Constraint发生不同的作用——比如有些就会被屏蔽掉。
令狐又提出第三个技术问题：还有一个问题就是环境上下文如何传递
这个问题在GUI应用中还是比较好解决，但在WEB应用中就麻烦一些。在GUI应用中，上下文可以直接或间接（通过指针指向View中的控件属性，如前面说的那个Lines）记录在Control中。但因为Web应用是无状态的，所以需要额外的持久化机制。
令狐说：持久化机制在服务器端利用数据库、在客户端利用Cookie，都有办法可
以做到。
但实现方法肯定是与GUI应用不同的，要麻烦一些。
我那个试点程序对上面说的这些没有全部实现，只尝试了一下V和C的分离，所以说我还要再考虑考虑。
我同意令狐说的：看看实现在讨论比较实际，否则是空对空的。试着用上面的理论作个实现出来，如果能提升到框架是最好不过了。就算只是个思想也是好的，不过要实现出来有些问题才好讨论。
提升到框架还是有难度的，我的目标是整理出一套切实可行的做法，以改进GUI应用开发。
太长了，还是放到文章里吧：
其实偶没有看过《梦的解析》，不过还是不懂装懂地尝试了一把：
某MM在QQ群里说：我经常梦见偶在水里欢快的游来游去。
偶在后面很8挂地解了一把：
先是用MSN机器人上的周公解梦，有人说其中有自相矛盾之处。那偶只好硬着头皮来给她做一下精神分析：
女生梦到水，通常是性高的潮的隐喻。水，意味着“湿了”。而“在水里欢快的游来游去”则意味着一种满足的情绪。结论就是：
■■■■■■■■■■■
（以上内容需要刮开才能看到，或发送短信至：898989-即“8挂8挂8挂”，每月10元）^O^
刚看了熊的一篇《做软件堪比搞装修》，感觉这个比喻的确很不错，现在中国的软件业与装修业的确是很大的相似之处，特别是在混乱程度上极为相似。
但是拿软件与建筑相比也绝不是没有理由的。且不说GoF的设计模式源自于建筑师C.Alexander的理论，在整个软件开发的过程，也是与建筑设计的过程极为相似——注意，是建筑设计，而不是建筑过程。刚好前几天我曾经工作过的一家公司就是做建筑设计行业软件的，所以也接触过一些建筑设计院，大致知道一些。
建筑设计阶段基本上相当于软件的开发过程，而建筑的建设阶段则相当于软件的应用过程。而“图纸制订后基本不做更改”的猜测是不正确的，绝大多数建筑设计图纸都会在建设阶段作少量的修改的。
而且建筑设计大体上分为两个部分：建筑设计和结构设计。在建筑设计阶段是需要很多的创造性的。不可否认“建筑业是一个已经非常成熟的工业,有非常多的规范和经验”，但这些，更多的是存在于结构设计部分，而在建筑设计部分，同样存在着巨大的变数。
——顺便说一句：前一段国内很多的大项目，如大剧院、奥运场馆等的设计搞招标，那些国外设计机构能胜出，很大程度上是由于他们的建筑设计才能。事实上他们把这些项目拿下后，拿了大笔设计费，然后基本上都是用其中很少的一部分钱把繁琐的结构设计任务外包给国内的设计院去做的。
建筑业的成熟更多地表现在流程上：比如建筑和结构的分工，多次校审，会签……这些才是软件业最需要向建筑业学习的部分。
熊最后说道：
当然,装修和软件一样,同样也在规范中,但什么时候能规范到和建筑行业一样(暂时先放过建筑行业&IT硬件业的不规范行为),那可真是个不定数了.
这虽然有点悲观，不过的确是很困难的事。毕竟建筑业有了数千年的积累，而软件业的历史不过数十年。但是也要看到，软件业的发展是很快的，建筑业的变化需要十年甚至百年的时间才能看出来，而软件业的发展只能用日新月异来形容。
希望还是很大的。
有人说了这么一个故事：
一对男女在某度假地邂逅了，彼此爱上了，相谈甚欢，晚上在宾馆各居一室，都很想去敲对方的门，但终于还是谁都没有这么做。第二天早晨，两人同往机场，各乘班机回到原来的城市、各自的生活中去……
这样的爱情不是更美吗？
我很不厚道地回复说：
这样的爱不一定更美，但一定更加滴让宁念念8忘：
TNND，那天晚上咋就木有去敲TMD门捏。
另一个不厚道的宁接着说：
猛禽大叔估计会去踹门吧，hoho
这个……很难说。没办法，俺就是酱紫的一个俗宁。-_-|||
没踹过之前谁也不能肯定“不踹”就一定比“踹了”好。
偶还看过一个故事，题目好像是叫做《其实昨天晚上我也想QJ他的》，大意是：
一个寂寞难耐的MM看上了邻居的一个GG。某天晚上停电，那MM欲火焚身地想去敲邻居的门，但是却一直鼓不起勇气。结果没一会，她听到阳台有响动，接着楼下就有很大的动静。她跑出去一看，原来是邻居那个GG从阳台摔下去了。不一会有警察过来调查，最后的结论是：那个GG想趁停电时从阳台爬过QJ这个MM，结果失足坠楼身亡。第二天，MM看到报纸报道了这则消息，心里想：其实昨天晚上我也想QJ他的。
多么不美好的爱情故事啊。
======不厚道的分割线================
将不厚道进行到底
（本来想另起一篇来写的，后来想想不厚道的东东还是表弄得太多了，就续一下吧）
上面引用的第一个故事出自我在《BLOG是什么东东》中已经说过的那位低调的筒子。由此可见偶是个非常小心眼的人，仅仅因为对他怀恨在心，就多次跟他过不去，给他穿小鞋，揪他小辫子……-_-|||
其实事情的起因是因为这位筒子也在他的BLOG发了征婚广告，这种事情是一定要广而告之的嘛，怎么可以低调呢。所以我一定要炒作一下。而且介种欲盖弥彰的行为是非常非常地那什么。看看人家心光明媚幸福万丈MM的行动，你还是不是男淫啊。
推荐向下面二位学习一哈。^O^
晚上几个人吃饭，菜足饭饱之后便谈起前两天的伦敦恐怖事件。
然后自然讨论到中国如果遭受这样的恐怖袭击，后果将可能严重得多得多。幸好中国没有，也不大可能会有这样的事。
这当然不是因为幸运。首先，中国在外部环境上，与拉登等人没有什么必要的冲突，他们也没有袭击中国的必要，所以不大可能招致这样的外来袭击。其次，有可能与中国存在冲突的势力——如东突及其它分裂分子、XX功等也不成气候。
但是同样必须看到，其它内部矛盾还是很激烈的，否则也不会有最近这么多的所谓“群体性事件”了。
就如《东邪西毒》里欧阳锋的一句台词所说：
……其实要搞恐怖活动并不是很困难的事……
因为现在技术先进，很多民用高科技都可以很方便地运用到恐怖活动中去。我们随便就设想一个很完美的恐怖活动计划——是针对日本鬼子的，详情就不说了，要教坏小朋友的-_-|||。但是，这又是偶们普通人几乎不可能去实施的。除非是由拉登大叔的专业团队来做。-_-|||
其实最关键的问题是：
真想干的人缺乏必要的知识和技术，并且“无组织，无纪律”。会干而且能干的人又不愿意去干。
这用吴思的“血酬定律”很好解释：
因为这些会干而且能干的人一般已经拥有比较不错的生活条件，他们的“命价”比较高，如果不是因为什么更有价值的事情，他们是不会去干这种亏本生意的。而那些“命价”低的人不会干，也干不了。
在某种程度上说，这是一种幸运。
但是写到这里，我忽然又想到了日趋严重的就业问题。如果这一问题在有限的将来里不能得到较好的解决，则必将成为影响社会稳定的重要因素。
扯远了，就此打住。
