神作。
看完后，脑海中第一个能浮现的词就是这个了。
三体的前两部很早就看了，直到最近才想想，把第三部看了，好的东西我是不介意往后放一放，不然看了之后会觉得很长一段都没有什么追求了。
有几类读者群体是会非常高傲的，一类是看科幻小说（硬科幻）的，一类是看推理小说的，很不幸，这两类书我都很喜欢看。
我还记得我第一次有自我意识的时候的恐惧，三个终极的哲学问题也一直困扰着我们“从哪里来？到哪里去？我是谁？”。这一切指向了一个终点，一个结局。
写一部好的硬科幻小说是需要想象力的，也需要非常严谨的逻辑性，这是个矛盾，而《三体》将二者结合，构造了一幅瑰丽的宇宙毁灭画面。
三体3——死神永生，中的童话故事写的实在精彩，令人拍案叫绝，而后一个个结论出现，又被推翻，令无数人想从中推导出线索的欲望彻底破灭，在绝望之时，作者又能另辟蹊径，给出合乎逻辑的推理过程，且指向唯一的结果。难，太难了。
除了对作者的顶礼膜拜，再无其他。
我看科幻小说20年，无论中外，谈笑间宇宙灰飞湮没的小说太多了，可是硬科幻能硬到如此
最近要写工作总结了，无意中翻出了当年（2011年初）写的一份未曾发表的工作总结，拿出来给大家看看，你问我什么叫未曾发表？或者说为什么没发表，相信你看过了就知道了。
2011-02-02
总结是给自己和别人看的，如果自己不看，别人也不看，那么他的意义则存在于敲打文字过程中的自我感悟，仅此而已。
关于实施总结的内容我已经写过太多了，这一篇我想多写写技术之外的事，也希望跳出LIS乃至医疗行业的小圈圈，让我们看看外面的世界。我也希望写的更加通俗些，何为通俗？也就是说，这篇文章即使写给办公室扫地的老大妈看，她也应该能能看得懂。
恩？好像没有人质疑我上面说的要跳出小圈圈的话，实际上这是不对的。民族的就是世界的，窥一斑而见全豹，盲人摸象。好像比喻的不太对，但是，“你懂的”。
很久之前就想写这样一个话题的文章，久到我学会写程序之前，当然就更不用说设计程序了。所以下面的内容不是我最近的感悟，而是想了好久，只是现在才写出来而已。
在某些时候我承认我是一个特立独行的人，但我不想哗众取宠，我相信我的确对程序设计进行了所谓的认真思考，看到很多IT书籍中打着各种不切实际的比喻来描述程序设计的过程，至少在中国的这种国情状态下，很多比喻我认为是不切实际的，所以我觉得有必要将我自己的理解写一下，至少这是一种声音。
希望多年以后我再看到这段文字的时候，还能觉得我是对的。
我认为程序设计过程和土木建筑工程不同，并且几乎没有可比性。
很多貌似正规的教材中教导我们，做程序要像盖房子一样，先搭好地基，然后再一层一层盖。可是，我们是怎么做的？还没等打地基呢，先开始进行装修了，不是吗？
产品还没出来，销售已经开始去卖了，难道这不是实情吗？
盖楼要先画好图纸，程序呢？有图纸吗？图
今日：2011-10-03，回想起为了写这篇影评，我曾仔仔细细的又看了一遍《上帝掷骰子吗》，写了一些文字，有些是成段的文字，有些是散碎的思绪，一直觉得不成熟，怕误导大家，就放入了草稿箱没有发表，现在发现，写作的时间对我来说实在是有些奢侈，希望将来的某一天，我可以将这篇文章写完，这只是我无数坑中的一个，所以大家也别抱什么期望。
前言：此文开始写于2011年7月24号，由于同时在构思MDE平台双向通讯插件的实现机制以及需要回顾量子力学中的一些关键性内容，因此，陆陆续续写到了现在。虽然不愿意承认，但我勉强也算是一个程序员吧，这也是为什么我独独为这篇电影写影评的原因。
今天北京又是大雨，微博上满是关于高铁事故的言论，我凑巧看了这个发生在火车上的故事，恰恰也是车祸，我想冥冥中可能有什么是注定的吧。在此，希望逝者在另一个平行宇宙中还好好的生活着，生命也还在延续着。
关于平行空间和时间旅行，一直都是科幻界乐此不疲的题材，《科幻世界》中也有无数这类题材的
有感于跟很多人争论了很多次的问题，这次就做个了结吧。
先要说一下，我的观点可能不是正确的，但我相信在大部分时候、大部分情况下是正确的。即使是真理也有一定的局限性不是吗？牛顿定律在微观物理学上也是不成立的，对吧。
从简单到复杂可以理解为是做事的一个步骤，这是我所建议的。反之，就是从复杂到简单。
好，论点出来了，我说说论据。
我们出生后为什么先爬，再走，再跑，在学骑自行车？——从简单到复杂。相信很多人明白这个道理，并且会说，你说的没错啊，大家都是这么想的，从简单到复杂吗！
可是事情做起来就不是这样了，这样的错误我也常常犯。
复杂的东西是个怪物，令人望而生畏，看到它扭头就想跑；简单的东西倒是都挺可爱的。但我标题中所说的简单，是复杂中的简单，并不是与复杂相对立的简单，不是独立于复杂之外的另一件事物，它和复杂是一体的。
这篇文章的框架是我三年前所写的，最近闲来无事又将它翻了出来，仔细研读，更改了其中部分内容，更符合时代感，以此做为“游戏人生”的一个纪念。
我曾经做过项目经理，在闲暇之余我喜欢玩点游戏，尤其是
思考了很久，要不要开始写这样一个专题，最终我决定还是把它写出来，这里边的很多内容是一些思考问题的逻辑，以及一些做事的方式、方法问题，希望能够对工作时间不长的朋友们有所帮助。
因为，帮人打鱼，是没有什么成就感的，教人渔鱼才是我的所愿。
虽然我写了MDE这样一个用于通讯数据交换的平台，但我非常不愿意听到别人问，你的程序支持多少台仪器的接口啊？能支持双向通讯么？支持读图片吗？……这类的问题。
我可以很坦率的说，MDE平台对于上述问题的回答，通通是不支持。
但为什么你可以看到MDE又是支持上述内容的？矛盾么？不矛盾。
MDE之所以看起来能支持串口通讯、TCP/IP通讯，可以读数据生成图片，生成指定的结果格式，发送特定格式的字符串给第三方（我们专业的讲法叫双向通讯）这是插件令其实现的，而插件，是每个人都可以写，都可以在其上进行扩展的。
对于很多的程序员而言，面对着具体需求写
之前的一篇博文我提到了实施的重要性，因为需求很多时候是我们在实施过程中，客户抱怨这个功能没有，那个功能不好用时产生的。
我们听到了客户的需求，在这之后我们可以做很多事：
- 认为客户的需求是异想天开，然后拍拍屁股走人就当没听见；
- 认为需求合理，自己研究下看能否在软件现有情况下满足这个需求；
- 报告给项目经理或者相关程序开发人员，然后等待……；
- 等待……等待……
我必须承认，等待是痛苦的，无助的等待更加痛苦。
技术问题，是的，客户提出需求时我们的第一反应是在技术上能否实现的问题，在这里，如果实施人员能够多迈一小步，从市场、销售的角度也去想想这个需求能够带来什么，我想事情也许会容易解决一些。
都说现在行业的竞争是同质化竞争，如果想让自己公司和公司的产品脱颖而出，除了理念的不同，还有就是细节的差异了。其实我们每家公司的产品在细节实现上都有很大不同，有些公司在这个问题上解决的思路好一些，有些公司在另一个问题上想的更加深入，但问题是，我们无法让客户知道这些不同。对于细
|
接口 |
插件实现 |
插件说明 |
| IPlugin |
通信单元插件接口
插件文件存放于
\Plugins\CellPlugins
或是
\Plugins\CellPlugins \CellID
|
IB |
IBS
起始边界 |
BS.Serial |
串口通讯 |
| BS.Tcpip |
TCP/IP通讯 |
| IBP 过程 |
BP.Stream |
数据流内容解析 |
IBO
结束边界 |
BO.SaveResultIntoFile |
将结果保存到文件 |
| BO.SaveResultIntoDatabas |
- MDE程序设计规范遵循 《.NET 设计规范 约定、惯用法与模式》第2版
人民邮电出版社 一书中所指明的规范。
- 主程序配置性信息保存在主程序路径 Config.xml 文件中，log4net配置信息也保存在此文件中。
- 每个通信单元的配置信息以XML文件保存，一个通信单元对应一个XML文件，文件保存在主程序路径
XML/Cell下。每个插件的配置信息需要保存到指定结构的节点内容中，不允许随便放置。
- 数据库中不保存任何配置性的信息，数据库仅作为业务数据存储容器使用，当数据库无需保存日志和业务数据时，可无视其存在。
- 为了保证程序执行效率，在通讯单元启动时，应将所有配置性信息从XML文件加载到内存中。
- 主程序与插件，插件与插件之间的通讯通过接口引擎间接进行；
- BS、BP、BO插件间的通讯数据交换通过缓冲区管理实现，缓冲区名称命名需要体现出其自身性质；
-
通信单元的插件可分为公共插件和私有插件，这两种类型并不是插件本身的属性，而是由插件文件所存放的位置决定的。在主程序路径 Plugins\CellPlugins
下存放的是公共插件，即每个通信单元都可以使用的
加载中…
发博文
添加到我的博客