2012年1月3日

一直跟信息安全较劲，曾经发过一个有关163.com密码的问题，年前又在发现QQ无数的诈骗邮件恶意套取密码，后来发现原来QQ的官方就是在帮助用户泄漏密码，所以在QQ签名上就写上了。

后来就出现了CSDN的事，然后我在微博说，很多网站都会存在这个问题，果然，密码事件愈演愈烈。

这都是笑谈，我无法预测这些事件的发生，更不能让这些事件不发生。但是我知道，安全，一直是IT的人的一块心病，无论是内部系统，外部系统，无论是桌面程序，还是迅猛发展的云计算 ，一提安全，全都很傻。所以很多以安全为己任的开发商，则可以大事渲染安全问题，让人们相信，有了他们的帮助，信息系统就安全了。

安全，很多有有很多论述，我也有一些，但是这里，我不会去说那些。

我一直希望人们所说的安全，从本质去解释一下以下的问题：

安全到底是什么，到底有没有安全；

不安全到底是什么，到底有没有不安全。

有人说安全是相对的，或是安全是绝对的，有相对安全或是绝对安全吗？

安全到什么程度人们才放心，不安全到什么程度人们不放心，或者危害到人们的利益？

从跟安全相关的人群来讲，安全涉及2个方面的人群，一个是要求安全的人群，一个是破坏安全的人群。

为什么有人要求安全，有人破坏安全，是要求在先，还是破坏在先？

为什么破坏安全的人群能够随意破坏安全而获得利益，而被破坏安全的人群却无能为力？

首先说，安全到底是什么？

这里所说的一直的信息安全，其实我们可以从现实的安全对比去说信息的安全。

在古代，一个人辛辛苦苦种了几亩麦子放在院子里，准备冬天过冬，可以晚上被另外一些人给偷跑了，那么这就是一个不安全的事件，这就产生了不安全。

抢劫的人为什么会抢别人的粮食呢？因为种田太辛苦，太耗时，风险也大，可能因为天气原因就没有收成。而偷粮食，轻而易举地就获得了收成，何乐而不为呢？

后来，种田的人就健身强体，召集一些人看护田地，如果有人偷粮食，抓到了就往死里打或者直接打死。这样，偷粮人要考虑一下，是丢了性命呢？还是稍稍辛苦一点儿自己种庄稼呢？还是勤劳致富吧，这样就少了一些偷粮人。

种田人召集的人很多，每天吃吃喝喝要吃掉很多，甚至比守候的粮食都多，种田人不能承受，就让他们散伙回家了。

为了继续保持安全，种田人自己将院子围了围墙，门上了锁，这样，抢劫的人不是很容易进来，粮食相对安全了。

可以过了不久，有人发现种田人的门锁很容易打开，就在种田人熟睡的时候，又偷走了他的粮食。

信息安全是如何产生的呢？

 （明天继续）

没有安全就不要信息化了吗？

安全问题中的内因。

法律和制裁，对于安全的破坏者，如何取证和制裁。

惩罚的力度和安全相关

诚信和安全也是相关的。商业交流的过程中，交流的是信息，而不要交流秘密

不安全的体系下的安全防护，防护还是稍稍防护，还是严加防护？

不安全的体系下如何运行信息系统？

  2011年8月20日

如果你一直使用Windows操作系统，无论是普通操作还是开发，突然转到Mac OS X，就发现有很多不适应。

因为很多概念、名词都不一样，所以像一个新的知识体系，学起来很费劲。尤其是开发人员，以前熟悉的热键在Mac OS X下，在XCode下都不一样了，让自己的开发效率大大降低。

我最近也在消耗一些时间在XCode下，但是我发现Mac的一些概念，名词都可以对应到Windows的某一特定的概念，而且名词都很相似，操作系统的操作也类似，操作热键更是大同小异，只要稍稍改变一下，就可以适应Mac OS X 和XCode的操作。这篇文章就随时记录这些对比，可能有人会找到更多的对照。

比如文件管理器在Windows中叫Explorer，在Mac OS X中叫Finder，意思相近，单词不同而已。

	Windows 按键	Mac 按键	用途
	Alt	Option	输入特殊字符，例如 é。
	Control	Command (⌘)	执行操作或快捷。例如，按下 ⌘-S 键通常会存储文稿或文件。
	Num Lock	Num Lock Shift-Clear	在一些应用程序中，控制按下数字键盘中的按键是否会输入数字或移动光标。
	Scoll Lock	Control-F14	在一些应用程序中，控制按下箭头键是否会移动光标或滚动窗口。
	Print 屏幕	请按 ⌘-Shift-3 请按 ⌘-Shift-4	拍摄屏幕的图片。按下 ⌘-Shift-3 可以拍摄整个屏幕的图片。按下 ⌘-Shift-4 可以拍摄屏幕上选定部分的图片。

（Command 键） - 在某些 Apple 键盘上，此键也可能带有 Apple 标志（）
（Control 键）
（Option 键）-“Alt”可能也出现在此键上
（Shift 键）
（Caps Lock 键）- 切换大写字母锁定开或关

大部分在Windows下的Ctrl键变成了Command键（虚机中可以使用windows键代替）

最常用的拷贝粘贴和剪贴，使用（Command 键）替换Ctrl键就可以了（虚机中可以使用windows键+Key，仅仅将小指从Ctrl键向右移到Windows键）

拷贝 Ctrl+C,

粘帖 Ctrl+V,

剪切 Ctrl+X,

全选 Ctrl+A,

Undo Ctrl+Z,

保存 Ctrl+S

  2011年7月18日

上周听收音机，主持人调侃说，她到了一个单位，保安问了她三个问题：你是谁，从哪里来，要到哪里去？保安出于职责，却问出了三个哲学终极问题，其实的确值得每个人去思考。

我突然觉得，我们身边的每一件事，是不是都要问一下，你是谁，你从哪里来，要到哪里去呢？

我正在准备一个技术课程的资料，突然对Web Service，尤其是Windows环境下的Web Service，发生了很多疑问，而且，这些疑问很久萦绕在思绪中...

Web Service，你是谁？你从哪里来，要到哪里去？

最初，作为系统互操作的一个简单解决方案，随着internet的兴起，Ws进入了我们的应用，可以简单说明Ws从哪里来。

但是，如今的Web Service，被MS包装起来，成了WCF的一个分支，让以前清楚的WS是谁变得不再清晰，那么WS要到哪里去，也变得模糊起来。

那么，WS到底要到哪里去，如果搞不清楚，我们是否还要让WS进入我们的应用？

  2011年6月26日

敏捷可以解决了开发模式的官僚问题，从行动角度应对用户业务需求的变化；

构架可以从设计角度应对业务需求的变化问题，甚至在需求调研阶段，能解决需求的收集和确认。

需求的变化，一般可以从3个领域发生，界面、流程和规则、组织结构和权限。

界面问题一般表现在界面的元素发生改变，如一个订单，原来有几项，关联了一些子表。现在要多加几项，修改其中几项，还要加入一个新的关联，等等

流程问题一般表现在一个界面的提交后，可能要跳到一个特定的界面。现在要跳转到另外一个界面，并且有一些新的规则；或者这个用户跳转到这个界面，那个用户跳转到另外的界面；或者根据界面上的某个输入，大于某个条件，就跳到这个界面，小于某个条件，就跳到另外界面。

规则问题有很多包含在流程问题中，但是有些是单独的规则问题。如这个输入框必须输入，这个输入框必须大于多少。规则的变化会改变这些。

组织结构变化更是非常频繁，建立新部门，增加新成员，成员的调动等；权限的设置有通过组的设置，有通过职务的设置。

变化的源泉是什么呢？业务变化，人员变化，这些都是业务活动必需的，一个信息系统不可能指责业务的变化，而是必须服从业务的变化，否则本末倒置，信息系统会被业务遗弃。

只有适应业务的变化，才是一个信息系统必须要面对的。

那么适应变化，至少可以有2类单独的人可以完成，完成的方法也不同。

第一类是开发人员，第二类是业务人员。

第一类的开发人员的修改是通过在系统源代码基础上，修改代码对业务进行修改。每次业务改动后，都需要业务人员传递给开发人员后，经过开发人员绞尽脑汁的思考后，才能进行修改，并且需要进行测试后才能交给业务人员使用。复杂一点儿的修改可能会涉及到很长的周期。

第二类业务人员的修改可以通过业务修改工具，在业务改动后，业务人员可以通过开发或维护人员进行修改，也可以自行修改，修改后，仅需要业务的测试，而不需要源代码级的编译和测试，所以相应速度要快。

第二类就是我们说的构架带来的敏捷，业务的敏捷是通过业务工具，让业务人员实施的，抛却了中间的开发过程，所以会非常灵活和快捷。

如何实现这样的敏捷构架？

当然可以使用很多商业的构架，但是完全可以通过简单的设计，在自己系统中原生的实现。

一、首先一些系统设计的原则可以使系统更高效

各司其职。各司其职就是要让业务清晰，从业务对象到业务方法、业务规则，可以将业务对象映射到程序对象，从而完成设计过程，只有业务清晰了，才能够变化自如。

一个业务的源头只有1个，就更容易维护、修改、测试，也就越稳定。

如有那些业务，业务之间的关系，业务中的信息和流程、权限，等，有哪些类是固定的，那些类是变化的。

逻辑分开。各司其职的原则可能有很多手段，其中的逻辑分层就是其中一个。

逻辑分层不同于物理分层，物理分层是为了部署和性能等逻辑之外的需求，逻辑分层是为了逻辑的清晰。

如我们要在所有商店都可以使用这个软件，每个店面的店长可以在这个程序中录入最新促销信息，这些促销信息的一部分可能会通过网络传到广告中心进行发布。

这里，录入最新促销信息到数据库，是一个业务需求，而所有商店都可以使用这个软件，保存的信息传输到广告中心发布，属于部署需求；而店长可以录入，则属于规则需求。

当我们建立设计时，一定会将促销信息，使用者，商店，这些要素提取，形成要实现的类，而不去管哪些信息信息传输到广告中心。

对于促销信息中的字段，我们可以放在一个单独字典表中，以备业务变化时可以修改字典进行扩充。

而录入界面，则可以通过模板或界面设计文件进行设计和呈现，当界面变化时，可以修改界面文件达到目的。

这样，业务变化时，我们就可以根据变化种类的不同，找到相应可以变化的部分，修改后，就可以重新运行。

避免了编译系统，带来了直接的效率。但是由于系统会执行解释方式，可能会造成效率的降低。

适应变化，开发要降低效率。

适应变化，系统也要降低效率。

二、构架还可以降低分布系统的开发工作量

分布系统在各个层次要写很多重复代码，而统一业务后，可以节省在各个层次间写多次业务代码或者传递。

属于物理逻辑的层次，其实是为了部署和扩展使用的，他们不属于业务逻辑，所以不需要由开发人员开发，甚至不需要开发代码。

所以，通过设计，可以即实现灵活的部署方式，又减少代码量，实现业务统一。

类似于单机版或C/S构架的开发方式，而分布式的部署方式是最理想的状态。

三、良好的构架设计可以轻松评估工作量和开发时间

由于对于系统分析透彻，对于系统隐含需求更加清晰，所以可以更容易掌握系统的重点，难点和开发量，也更容易在系统前期同客户交流，确定系统需求，避免因为用户考虑不周带来的变化。

  2011年6月18日

敏捷开发从宣言到原则，再到实践，也有组织开始进行敏捷的认证活动。

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

前几天听得一个敏捷基础类的介绍，已经将过程加到敏捷开发时间中，认为可以将Fast同Process联系起来，认为流程或工具是使团队更快速。

还是那句个体和交互胜过过程和工具，就是说，过程和工具的作用是不可忽视的，谁要是忽略甚至摈弃过程和工具，那就进入一个教条主义的泥潭中。

说起敏捷，经常会被人问起同CMM这个软件成熟度模型（Capability Maturity Model for Software）之间的关系

为了容易比较，我可以将敏捷软件开发中的思想，理解为软件能力“敏捷度”模型，CAM-Capability Agile Model for Software。这样，就可以把敏捷开发同相对传统的软件过程管理下的开发简单地区别，并可以更容易对比。

1，CMM更注重过程，认为过程可以保证软件开发能力的成熟度，就是说，可以通过过程保证一个软件在各个阶段更加可控，获得的结果更加可靠，就是说可以更容易计划，按时间完成计划，在规定时间内获得高质量的成果。

CMM认为软件开发虽然不可以度量，但可以根据科学的方法，通过量化数据发那个是尽量准确地将软件的需求，计划，开发，效率，测试，结果，以及人力、成本等需要管理的要素加以约束。

CAM 更注重开发者的个体和软件本身，注重客户业务和软件需求的变化，从而以更快速的方式适应这些变化，从而达到软件的最终结果更适合业务需求。

CAM也同意软件开发过程中的各个要素，如需求、设计、构架、开发、测试，但是更强调分阶段呈现，先运行起来，然后再重构，使用户和各环节可以在最快时间内看到运行的系统，从而避免方向的偏差和交流的错误，以最小的代价获得这些，而不是过度设计，过度计划，过度管理带来的高成本。

2，从自然规律上讲，一个事物成熟度越高，其敏捷性就会降低。如一艘大船，在稳定，安全，容量，速度等方面占有优势，其具有很高的成熟度，但是其敏捷性就不如小船。人类也是这样，个体和团队，当其稳定成熟后，抗风险等能力提高，单会使成员变得官僚，决策和执行力稳定但不适合变化。

所以，软件开发的过程的成熟度和敏捷性，是两个互斥的选择，可以通过两个方面的改进模型，以适合特定规模的项目或特定规模的开发团队。

3，从软件开发管理科学的不断探索可以看到，在CMM类的过程管理方法理论和实践中，不断将长周期的开发方法改变为短周期和螺旋式的开发，这点在Agile的演讲中一般不会提到，Aglie的演讲总是将瀑布式开发作为其攻击的目标，让人们认为Agile解决了长周期的弊端。

所以，长周期还是短周期都不是Agile和CMM的区别焦点，而是设计和重构成为他们重要不同之处。即通过不断实现-重构的是敏捷方法，而通过设计-实现-重构的是过程式的方法。由于加入设计的环节，成熟度自然要比简单设计的Agile要成熟，迭代周期要少，开发进度要可能要快一些。

4，CAM类的开发认为文档也不是很重要，所以，除了必要的文档外，描述构架、设计、代码的设计认为可以不要了，认为代码就是设计。

随着软件开发工具的不断升级，开发语言更加自然语言化、图形化，的确很多既不能及时更新的文档可能会造成更坏的后果，所以可以不要。

简要结论：

成熟度还是敏捷度，到底要哪一个？成熟度可能会将敏捷度包含进来，成为一个分支；还是敏捷度将成熟度解决在过程之外。

还是两者本来就是融为一体的，可以共存，只是需要一个过程。

只是这些方法都形成各自的利益链后，再融合起来就比较困难了。