The new year.

昨天看了《叶问》、《梅兰芳》、《霸王别姬》、《非诚勿扰》。都是别人的生活。几年前觉得活着是为了经历，几年后觉得活着就是活着，不管真实还是不真实。也许生活和爱才是真正重要的，可对它们却只能顺其自然。

曾经刻意地追求着简单，不想去记录，不想去思考，可现在有时觉得不记下些什么我真会很快忘了经历过什么。可即使刻意记录，一天天还是这么过去，到后来只是成了一篇篇日志、成了一张张相片、成了一纸简历、成了回忆。

在09年，我想活得真实些，每天都做一件开心的事情，每个月都养成一个好的习惯。呵呵，这就是我新年的目标。

08年

08的流水帐：
1月：考研，确定考不上，开始做简历。浪费了半年的时间。家乡下了场大雪，过年，做鱼丸。
2月：跑亲戚、投简历，17号到上海，一周面试四家公司，第二周和宏力签约，回广州办三方协议，回上海。
3月：上班，编程。工作的无奈和孤独。
4月：继续工作，知道过了上财的复试线，准备复试，笔试基本不会，又开始等待，已不在意。准备报工程硕士。
5月：月初得知复试通过。上午离职，下午去蓝竹面试，第二天回广州。做毕设。
6月：继续做毕设，去肇庆玩，拍毕业照，答辩。
7月：蓝竹实习，继续编程，烦心而开心的日子。
8月：继续编程，生活的琐碎。
9月：月初回家，中旬回上海，开学。学习Linux+Python。由于入党较早，被任班长。
10月：十一回家，思维导图，重读《代码大全》，学SAS，烧烤。重做简历，面试。
11月：玩红警3，SNA论文，《代码大全》，Python，UNIX。
12月：英语演示，《重构》，《执行》，统计推断考试，《货币战争》，重读《设计模式》，圣诞party。复习高微、投资。听歌。

明年：
1到5月：课程学习，python，C，Matlab or SAS，DB2 Advanced，BEC Higher，LPIC。
5到8月：暑期实习，英语，Data Mining。
9到12月：论文，找工。
可能的话参加一两个开源项目。

继续卑微地努力，多多少少为自己、为他人做些事情。累些，却也不会后悔～

12.22习字_苏轼词

窗外阳光很好，不想看书，等吃午饭，有那么一点无趣，抄了苏轼的两首词。手有点冻，笔也有些差。上一次写字该是一年半以前了吧。

我不知道干嘛写字，纯粹的浪费时间，而且还显得有点酸有点作，呵呵。不过很多事都一样，是永远没有为什么这一说的。哪怕过程中有一点点所得，就不能说是浪费时间。宅男，宅男。

《Head First 设计模式》9-13章

Chapter 9：迭代器和组合模式--管理良好的集合
我们能学习如何让客户遍历你的对象而又无法窥视你存储对象的方式；也将学习如何创建一些对象超集合，能够一口气就跳过某些让人望而生畏的数据结构；还将学写到一些关于对象职责的知识。

迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而不是暴露其内部的表示。
迭代器模式让我们能游走于聚合内的每一个元素，而不是暴露其内部的表示。
把游走的任务放在迭代器上，而不是聚合上。这样简化了聚合的接口和实现，也让责任各得其所。

设计原则：一个类应该只有一个引起变化的原因。
类的每个责任都有改变的潜在区域。超过一个责任，意味着超过一个改变的区域。
这个原则告诉我们，尽量让每个类保持单一责任。

组合模式：允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一直的方式处理个别对象以及对象组合。
组合模式让我们能用树形方式创建对象的结构，树里面包含了组合以及个别的对象。
使用组合结构，我们能把相同的操作应用在组合和个别对象上。换句话说，在大多数情况下，我们可以忽略对象组合和个别对象之间的差别。
统一处理个别对象和组合对象。

空迭代器
NullIterator，返回一个迭代器，而这个迭代器得hasNext永远返回false。

要点
迭代器允许访问聚合的元素，而不需要暴露它的内部结构。
迭代器将遍历聚合的工作封装进一个对象中。
当使用迭代器的时候，我们依赖聚合提供遍历。
迭代器提供了一个通用的接口，让我们遍历聚合的项，当我们编码使用聚合的项时，就可以使用多态机制。
我们应该努力让一个类只分配一个责任。
组合模式提供一个结构，可同时包容个别对象和组合对象。
组合模式允许客户对个别对象以及组合对象一视同仁。
组合结构内的任意对象称为组件，组件可以是组合，也可以是叶节点。

在实现组合模式时，有许多设计上的折中。你要根据需要平衡透明性和安全性。


Chapter 10：状态模式--事务的状态
策略模式和状态模式是双胞胎，在出生时才分开。


策略模式是围绕可以互换的算法来创建成功业务的。
状态模式通过改变对象内部的状态来帮助对象控制自己的行为。
1 定义一个State接口。在这个接口内，糖果机的每个动作都有一个对应的方法。
2 然后为机器中的每个状态实现状态类。这些类将负责在对应的状态下进行机器的行为。
3 我们要摆脱旧的条件代码，取而代之的方式是，将动作委托到状态类。


状态模式：允许对象在内部状态改变是改变它的行为，对象看起来好像修改了它的类。

要点
状态模式允许一个对象基于内部状态而拥有不同的行为。
和程序状态机PSM不同，状态模式用类代表状态。
Context会将行为委托给当前状态对象。
通过将每个状态封装进一个类，我们把以后需要做的任何改变局部化了。


状态模式和策略模式有相同的类图，但是它们的意图不同。
策略模式通常会用行为或算法来配置Context类。
状态模式允许Context随着状态的改变而改变行为。
状态装换可以由State类或Context类控制。
使用状态模式通常会导致设计中类的数目大量增加。
状态类可以被多个Context实例共享。


Chapter 11：代理模式--控制对象访问

你是一个白脸，提供很好且很友善的服务，但是你不希望每个人都叫你做事，所以找了黑脸控制对你的访问。


控制和管理访问，这就是代理要做的事。
你的客户对象所做的就像是在做远程方法调用，但其实只是调用本地堆中的“代理”对象上的方法，再由代理处理所有网络通信的低层细节。
1 先浏览并了解一下RMI。
2 我们会把GumballMachine变成远程服务，提供一些可以被远程调用的方法。
3 我们将创建一个能和远程的GumballMachine沟通的代理，这需要用到RMI。
4 最后再结合监视系统，CEO就可以监视任何数量的远程糖果机了。


方法调用是如何发生的
1 客户对象调用客户辅助对象的doBigThing方法。
2 "客户辅助对象打包调用信息(变量,方法名称等)，然后通过网络将它运给服务辅助对象。"
3 服务辅助对象把来自客户辅助对象的信息解包，找出被调用的方法(以及在哪个对象内)，然后调用真正的服务对象上的真正方法。
4 服务对象上的方法被调用，将结果返回给服务辅助对象。
5 服务辅助对象把调用的返回信息打包，然后通过网络运回给客户辅助对象。
6 客户辅助对象把返回值解包，返回给客户对象。对于客户来说，这是完全透明的。


RMI提供了客户辅助对象和服务辅助对象，为客户辅助对象创建和服务对象相同的方法。


制作远程服务
1 制作远程接口
2 制作远程的实现
3 利用rmic产生的sub和skeleton
4 启动RMI registry(rmiregistry)
5 开始远程服务

远程代理；虚拟代理：暂时代理初建开销大的对象


代理模式：为另一个对象提供一个替身或占位符以控制这个对象的访问。
使用代理模式创建代表representative对象，让代表对象控制某对象的访问，被代理的对象可以是远程的对象，创建开销大的对象或需要安全控制的对象。

 


要点
代理模式为一个对象提供代表，以便控制客户对对象的访问，管理访问的方式有许多种。
远程代理管理客户和远程对象之间的交互。
虚拟代理控制访问实例化开销大的对象。
保护代理基于调用者控制对象方法的访问。
代理模式有许多变体，例如：缓存代理，同步代理，防火墙代理和写入时复制代理。
代理在结构上类似装饰者，但是目的不同。
装饰者模式为对象加上行为，而代理则是控制访问。
Java内置的代理支持，可以根据需要建立动态代理，并将所有调用分配到所选的处理器。
就和其他的包装者wrapper一样，代理会造成你的设计中类的数目增加。

Chapter 12: 复合模式--模式中的模式
谁料得到模式居然可以携手合作？

模式常被一起使用，并被组合在同一个设计解决方案中。
复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。

设计模式是MVC的钥匙。
MVC是由数个设计模式结合起来的模式。如果你能够看着MVC内部的各个模式，MVC的一切就会跟着开始明朗起来。

要点
MVC是复合模式，结合观察者模式、策略模式和组合模式。
模型使用观察者模式，以便观察者更新，同事保持两者之间的解耦。
控制器是视图的策略，视图可以使用不同的控制器实现，得到不同的行为。
视图使用组合模式实现用户界面，用户界面通常使用嵌套的组件，像面板、框架和按钮。
这些模式携手合作，把MVC的三层解耦，这样额可以保持设计干净，又有弹性。
适配器模式用来将新的模型是配成已有的视图和控制器。
Model2是MVC在Web上的应用。
在Model2中，控制器实现成Servlet，而JSP/HTML实现视图。
迎接一个充满设计模式的崭新世界。

Chapter 13：与设计模式相处--真实世界中的模式
模式是在某种情境(context)下，针对某问题的某种解决方案。
情境就是应用某个模式的情况。这应该是会不断出现的情况。
问题就是你想在某个情境下达到的目的，但也可以是某情境下的约束。
解决方案就是你追求的，一个通用的设计，用来解决约束，达到目的。
如果你发现自己处于某个情境下，面对着所欲达到的目标被一群约束影响着的问题，然而，你能够应用某个设计，克服这些约束并达到该目标，将你领向某个解决方案。

反模式告诉你如何采用一个不好的解决方案解决一个问题。

要点
让设计模式自然而然地出现在你的设计中，而不是为了使用而使用。
让设计模式并非僵化的教条；你可以依据自己的需要采用或调整。
总是使用满足需要的最简单解决方案，不管它用不用模式。
学习设计模式的类目，可以帮你自己熟悉这些模式以及它们之间的关系。
模式的分类或类目是将模式分成不同的族群，如果这么做对你有帮助，就采用吧！
你必须相当专注才能够成为一个模式的作家；这需要时间也需要耐心，同事还必须乐意做大量的精化工作。
请牢记：你所遇到大多数的模式都是现有模式的变体，而非新的模式。
模式能够为你带来的最大好处之一是，让你的团队拥有共享词汇。
任何社群都有自己的行话，模式社群也是如此。别让这些行话绊着，在读完这本书之后，你已经能够应用大部分的行话了。

剩下的模式

桥接模式 Bridge Pattern
不只改变你的实现，也改变你的抽象。
生成器 Builder Pattern
使用生成器模式封装一个产品的构造过程，并允许按步骤构造。
责任链 Chain of Responsibility Pattern
当你想要让一个以上的对象有机会能够处理某个请求的时候，就使用责任链模式。
蝇量 Flyweight Pattern
如想让某个类的一个实例用来提供许多虚拟实例，就使用蝇量模式。
解释器 Interpreter Pattern
使用解释器模式为语言创建解释器。
中介者 Mediator Pattern
使用中介者模式来几种相关对象之间复杂的沟通和控制方式。
备忘录 Memento Pattern
当你需要让对象返回之前的状态时，就使用备忘录模式。
原型 Prototype Pattern
当创建给定类的实例的过程很昂贵或很复杂时，就使用原型模式。
访问者 Visitor Pattern
当你想要为一个对象的组合增加新的能力，切封装并不重要时，就使用访问者模式。

《Head First 设计模式》5-8章

Chapter 5: 单件模式
独一无二的单件模式：用来创建第一无二的，只能有一个实例的对象的入场券。有些对象之需要一个：线程池、缓存、对话框、偏好设置、日志。。。
静态全局变量（一开始就创建号） <--> 单件模式（可以在需要时再创建对象）
单件模式：确保一个类只有一个实例，并提供一个全局访问点。

JVM多线程
同步：synchronized --> 可能造成执行效率的下降
急切实例化：定义时创建
双重检查加锁：volatile -- Java 5

要点
单件模式确保程序中一个类最多只有一个实例。
单件模式也提供访问这个实例的全局点。
在Java中实现单件模式需要私有的构造器，一个静态方法和一个静态变量。
确定在性能和资源上的限制，然后小心地选择适当的方案来实现单件，以解决多线程的问题(我们必须认定所有的线程都是多线程的)
如果不是采用第五版的java2，双重检查枷锁实现会失效。
小心，你如果使用多个类加载器，可能导致单件失效而产生多个实例。
如果使用JVM1.2或之前的版本，你必须建立单件注册表，以免垃圾收集器将单件回收。

Chapter 6: 命令模式--封装调用
这些绝密文件的投递箱已经促成了间谍工业的革命。我只要把需求丢进去，就有人会消失，政府一夕之间改朝换代，而我的干洗衣物也好了。我不必管何时何地或者如何完成，反正就是完成了。
在本章，我们把封装带到一个全新的境界:把方法调用封装起来。

命令模式：
将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。

命令对象将动作和接收者包进对象中。这个对象只暴露出一个execute()方法，当此方法被调用的时候，接收者就会进行这些动作。
NoCommand对象是一个空对象的例子。当你不想返回一个有一一的对象时，空对象就很有用。
客户也可以将处理null的责任转移给空对象。

命令模式的更多用途
队列请求：命令可以将运算快打包（一个接受者和一组动作），然后将它传来传去，就像是一般的对象一样。
日志请求：store(); load(); execute(); undo()
宏：顺序地执行execute();

要点
命令模式将发出请求的对象和执行请求的对象解耦。
在被解耦的两者之间是通过命令对象进行沟通的，命令对象封装了接受者和一个或一组动作。
调用者通过调用命令对象的execute发出请求，这会使得接收者的动作被调用。
调用者可以接受命令当参数，甚至在运行时动态地进行。
命令可以支持撤销，做法是实现一个undo方法来回到execute被执行前的状态。
宏命令是命令的一种简单的延伸，允许调用多个命令。宏方法也可以支持撤销。
实际操作时，很常见使用聪明命令对象，也就是直接实现了请求，而不是将工作委托给接收者。
命令也可以用来实现日志和事务系统。

Chpater 7：适配器模式与外观模式--随遇而安
适配器模式与外观模式：以不同的目的，包装某些对象，让它们的接口看起来不像自己而像是别的东西。
这样就可以在设计中，将类的接口转换成想要的接口。
将所有的改变封装在一个类中，可能需要让一个适配器包装多个被适配者。
双向适配器。

适配器模式解析
客户 - 适配器 - 被适配器
客户使用适配器的过程如下：
客户通过目标接口调用适配器的方法对适配器发出请求。
适配器使用被适配者接口把请求转换成被是配置的一个或多个调用接口。
客户接收到调用的结果，但并未察觉这一切是适配器在起转换作用。

适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

对象适配器：

外观不只是简化了接口，也将客户从组件的子系统中解耦。
外观和适配器可以包装许多类，但是外观的意图是简化接口，而适配器的意图是将接口转换成不同接口。
外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
外观没有封装子系统的类，外观只提供简化的接口。同时，依然将系统的功能完整地暴露出来。

设计原则：最少知识原则：只和你的密友谈话。

要点
当需要使用一个现有的类而其接口并不符合你的需要时，就使用适配器。
当需要简化并统一一个很大的接口或者一群发杂的接口时，使用外观。
适配器改变接口以符合客户的期望。
外观将客户从一个复杂的子系统中解耦。
实现一个适配器可能需要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定。
实现一个外观，需要将子系统组合进外观中，然后将工作委托给子系统执行。
适配器模式有两种形式：对象适配器和类适配器，类适配器需要用到多重继承。
你可以为一个子系统实现一个以上的外观。
适配器将一个对象包装起来以改变其接口，装饰者将一个对象包装起来以增加新的行为和责任，而外观将一群对象包装起来以简化其接口。

Chapter 8：模板方法模式--封装算法
唉！在需要进入这个洞之前他原本是个好老板的，结果这全部都编程了我的工作了。你懂我的意思吧？他根本就不见人影！
我们将要深入封装算法块，好让子类可以在任何时候都可以将自己挂接进运算里。

模板方法定义了一个算法的步骤，并允许子类为一个或多个步骤提供实现。

模板方法模式：在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
对模板方式进行挂钩，影响抽象类中的算法流程

设计原则：好莱坞原则：别调用(打电话给)我们，我们会调用(打电话)你。
高层组件对待低层组件的方式是：别调用我们，我们会调用你。低层组建将自己挂钩到系统上。

要点：
模板方法定义了算法的步骤，把这些步骤的实现延迟到子类。
模板方法模式为我们提供了一种代码复用的重要技巧。
模板方法的抽象类可以定义具体方法、抽象方法和钩子。
抽象方法由子类实现。
钩子是一种方法，它在抽象类中不做事，子类可以选择要不要去覆盖它。
为了防止子类改变模板方法中的算法，可以将模板方法声明为final。
好莱坞原则告诉我们，将决策权放在高层模块中，以便决定如何已经何时调用低层模块。
你将在真实世界代码中看到模块方法模式的许多变体，不要期待它们全都是一眼就被你认出来的。
策略模式和模板方法模式都封装算法，一个用组合，一个用继承。
工厂方法是模板方法的一种特殊版本。
良好管理的集合 “当然我把集合都好好地封装起来了”

财务报表分析作业

分析对象选的是用友软件（600588），18号晚完成了分析数据的录入，19日上午完成2/3，今天上午又完成了剩下的1/3。总的花费在16个小时左右，23p，8000字。纪念。

有图片的word转到Online doc上有很多错误，Excel可以上传但还不能嵌到页面。下面只摘抄下总结吧：

在偿债能力和资本结构方面，用友软件有着不错的短期偿债能力，债权的保证程度很高，企业所有者对企业的控制力很强，企业偿还本息的压力轻，但企业没有充分利用财务杠杆举债经营，具体体现在财务杠杆指数低等方面，但在五年间有了一定高，说明该企业的业务有较好的发展，对负债经营有了一定的运用。在长期偿债能力上，用友软件的利息保障倍数处于极高的水平，且在过去的几年内又有了较大的提高。

在营运能力方面，该企业的该企业的总资产周转率和流动资产周转率处于逐年上升的态势，同时应收账款周转率也在逐年提高，说明了企业的运营能力和应收账款的管理水平在持续地提高。但是，该企业的总负债周转率呈M形波动，说明了用该企业利用负债资金创造效益的能力较弱且不稳定。同时，所有者权益周转率的稳步上升说明了企业投资者的权益基金创造收入的能力有所提高。五年间，该企业的营业周期和现金营业周期呈稳步降低的态势，说明了该企业的资金周转速度有所加快、流动性增强、资产的使用效率有所提高。

在获利能力方面，该企业的销售净利率和销售毛利率都呈先减后增的U字形趋势，总体保持稳定，主营业务利润率呈先增后降的态势，可从绝对值看仍处在较高的水平，但营业利润率的下降幅度较大，说明企业通过日常经营活动获得利润的能力减弱。该企业的该企业的主营业务成本毛利率及主营业务成本利润率在03到05年逐年下降，但其绝对值仍保持在较高的水平，体现了该企业出色的获利能力。

在投资报酬能力上我们可以看出，该企业的投资回报能力在04年后有了很大的提高，其盈利水平是稳定而又持续提高的。

在现金流量部分，从分析数据我们可以看出，企业有着不错的运用现金偿还债务的能力，和经营获现能力，现金获利能力也很出色，同时企业也有着稳定的现金流，完全能够满足投资的需要。

用友软件作为一个纯软件公司，代表了软件行业的普遍特点。首先在成本的构成上，固定资产方面的投入占的比重较少，且设备的更新换代有周期性，故导致了某些财务数据的非常规变化；其次在现金流量上，企业有着充裕的现金流，完全可以满足偿债和投资的需要；其三在资本构成上，由于处于新兴行业，创办历史较大，所以股权较为集中，所有者对企业的控制较强；其四在举债经营上，由于在软件行业，知识产权的重要性大大高于其它因素，而研发能力的提高不是光靠大的团队或者大的投入就可以做到的，加之企业的现金流较为充裕，所以并没有大量利用借债来扩大企业规模。虽然企业没有充分利用财务杠杆，但在不稳定的软件行业，保持较大的现金储备有利于企业长期稳定的发展。

Excel数据整理

今天做财务报表分析的课程作业，我选择了用友软件作为分析对象，数据上采用了该公司02-06年五年的数据。数据的来源是html格式的年报。由于五年间的会计科目有所变化，再加上实际的报表和分析用的标准报表有所差异，如果一个个数据拷贝的话工作量还是很大的。我采用了以下的数据整理流程大大提高了效率：

html --> UltarEdit[正则表达式处理特殊符号] --列编辑，拷贝标题列和数据列--> Excel临时表 --> 拷入标准表的标题列 --> 对照标准表，将临时表的标题列对准标准表 -->将临时表的数据列拷入标准表 --> 整理&填充缺失数据。

《货币战争》

今天早上七点半就起来了，窝床上看小说--《货币战争》。的确是颇有意味的一本书，抛开真实性不说--也许也不会有人认为这本书里讲的是真的，这本书让我了解了一下金融方面的历史学知识，我相信这些历史是是真实的，只是对这些历史的解读有些哗众取宠了。对于一些历史的解释作者的阴谋论也能自圆其说，可越到后来就出来了越多的矛盾，我不是指与历史现实的矛盾，而是书中的自相矛盾。于是越翻越快，翻到了十点半终于忍不住饥饿和口渴，翻完了这本书。不能不佩服作者的想象力、历史学知识和自圆其说的能力。有人在金庸的小说中推出了张三丰是小龙女和尹志平的私生子，也是引经据典，充满了想象力。

下面的网上的书评，看看也蛮有意思的。
豆瓣书评--货币战争
子虚乌有的货币战争

讲座_信息检索_统计学习

今天下午在经院楼听了马志明院士的讲座：《数学在信息检索中的作用》。介绍了PageRank和他们团队最新的研究成果BrowersRank。这种算法使用用户的浏览行为作为网页评级的依据。采用的数据有用户在一个页面的停留时间和页面之间的跳转动作。使用这种算法可以有效地防止一些网站对搜索引擎的欺骗，得出较为客观的结果。

这的确是一个很有创意而且有实际运用价值的想法。可问题是用户不一定只用IE，而且有些网站也许要很久也许永远都不能被用户所访问。这有个时效性的问题。我认为评级应该结合网络结构、页面内容和用户的浏览行为，这些方法是互为补充的，仅仅说哪种方法更好显然是没有意义的。

另外讲到的就是二重统计学习，是马院士的团队在研究“搜索学习？”时发现简单的统计学习不能满足实际的需要，进行的开创性的研究。这部分我也没听明白，该是数据挖掘方面的内容吧。马院士也提到了现在统计正为搜索引擎提供了新的创意，而搜索的实际也促进的统计理论的进一步发展。可要真正将工程方面的东西和数学融会贯通又谈何容易。

《Head First 设计模式》1-4章

《Head First》在去年初着实火了一把，我是年初买的这本书，然后回学校做毕业设计的时候看了几章，假期实习的时候看完了剩下的几章。那会烦心的事特别多，也没有读书的心情，看《重构》的时候发现很多设计模式方面的东西已经忘个精光，现在重读并做些笔记。部分内容来自CSDN下载的一份EXCEL格式的笔记，图片都来自GoF的经典。设计模式出来十年了，我却是在本科毕业以后才读的这本书，也许不用考研，我会早些接触模式，对我的编程实践应该会有很多的帮助。

学习的方法：
慢一点，思考得越多，需要记的就越少
勤做练习，自己记笔记
睡觉前不要看有难度的东西
多喝水
大声说出来
听听你的大脑怎么说
要有点感觉
设计一些东西

chapter1：设计模式入门
我们已经搬到对象村，刚刚开始着手设计模式……这里每个人都在使用设计模式。很快我们就会通过设计模式跻身上流社会。
把模式装进脑子里，然后在设计和已有的运用中，寻找何处可以使用。

CHANGE
设计原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
把会变化的部分取出并封装起来，好让其他部分不会受到影响。
结果如何？代码变化引起的不经意后果变少，系统变得更有弹性。

设计原则：针对接口编程，而不是针对实现编程。
从现在开始，鸭子的行为将被放在分开的类中，此类专门提供某行为接口的实现。
这样，鸭子类就不再需要知道行为的实现细节。
"针对接口编程真正的意思是""针对超类型supertype编程"""
执行时根据实际情况执行真正的行为

设计原则：多用组合，少用继承。
has a maybe better than is a.

策略模式：
定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。

良好的OO设计必须具备可复用、可扩展、可维护三个特性。
可维护的OO系统:随时想到系统以后可能需要的变化以及应付变化的原则。

模式不是被发明，而是被发现。

chapter 2：观察者模式：让你的对象知悉现状
喂，Jerry，我正在通知大家，模式小组会议改到周六晚上，这次讨论的是观察者模式，这个模式最棒了！超级棒！你一定要来呀，Jerry。

观察者模式： 定义了对象之间的一对多依赖，这样以来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

设计原则：为了交互对象之间的松耦合设计而努力。
松耦合：依然可以交互，但不太清楚彼此的细节。

Subject:主题 Observer:观察者

要点
观察者模式定义了对象之间的一对多关系。
主题，也就是可观察者用一个共同的接口来更新观察者。
观察者和可观察者之间用松耦合方式结合，可观察者不知道观察者的细节，只知道观察者实现了观察者接口。
使用此模式时，你可从被观察者处推push或拉pull数据，然而，推的方式被认为更正确。
有多个观察者时，不可以依赖特定的通知次序。

Java有多种观察者模式的实现，包括了通用java.util.Observable
要注意java.util.Observable实现上所带来的一些问题。
如果有必要的话，可以实现自己的Observable，这并不难，不要害怕。
Swing大量使用了观察者模式，许多GUI框架也是如此。
此模式也被应用在许多地方。例如：JavaBeans、RMI。

chapter 3： 装饰者模式
我曾经以为男子汉应该用继承处理一切。后来我领教到运行时扩展，远比编译时期的继承威力大。看看我现在光彩的样子。

装饰模式：动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
可以在不修改底层代码的情况下，给代码赋予新的职责。

设计原则：类应该对扩展开发，对修改关闭。

要点1
装饰者和被装饰者对象有相同的超类型。
你可以用一个或多个装饰者包装一个对象。
既然装饰者和被装饰对象有相同的超类型，所以在任何需要原始对象（被包装）的场合，可以用装饰过的对象代替它。
装饰者可以在所委托被装饰者的行为之前与/或之后，加上自己的行为，以达到特定的目的。
对象可以在任何时候被装饰，所以可以在运行时动态地、不限量地用你喜欢的装饰者来装饰对象。

要点2
继承属于扩展形式之一，但不见得是达到弹性设计的最佳方案。
在我们的设计中，应该允许行为可以被扩展，而无须修改现有的代码。
组合和委托可用于在运行时动态地加上新的行为。
除了继承，装饰者模式也可以让我们扩展行为。
装饰者模式意味着一群装饰者类，这些类用来包装具体组件。
装饰者类反映出被装饰的组件类型（他们具有相同的类型，都经过接口或继承实现）
装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。
你可以用无数个装饰者包装一个组件。
装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。
装饰者会导致设计中出现许多小对象，如果过度使用，会让程序变得很复杂。

只有针对抽象组件类型编程时，才不会因为装饰者而受到影响。
通常有工厂或生成器之类的模式创建。

Java String
FilterInputStream: 一个抽象装饰者。
chapter 4：工厂模式--烘烤OO的精华
认识工厂方法模式
所有工厂模式都是用来封装对象的创建
工厂方法模式通过让子类决定该创建的对象是什么，来达到将对象创建的过程封装的目的。

组成元素
创建者Creator类
它定义了一个抽象的工厂方法，让子类实现此方法制造产品。
创建者通常会包含依赖于抽象产品的代码，而这些抽象产品由子类制造。创建者不需要真的知道在制造哪种具体产品。
产品类：工厂生产产品。对PizzaStore来说，产品就是Pizza。

另一个观点：平行的类层级
为什么产品类和创建者类是平行的？都是抽象类，且都有许多具体的子类，每个子类都有自己特定的实现。
NYPizzaStore所封装的是关于如何制作纽约风味的比萨。工厂方法就是封装这种知识的关键所在。

工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

要点：
Creator是一个类，它实现了所有操作产品的方法，但不实现工厂方法。
Creator所有的子类都必须实现这个抽象的factoryMethod方法。
所有的产品必须实现一个共同的接口，这样一来，使用这些产品的类，就可以引用这个接口，而不是具体类。
ConcreteCreator实现了factoryMethod，以实际制造出产品。
ConcreteCreator负责创建一个或多个具体产品，只有ConcreteCreator类知道如何创建这些产品。
concrete具体的adj

设计原则：要依赖抽象，不要依赖具体类。
依赖倒置原则，不能让高层组件依赖低层组件，而且不管高层或低层组件，2者都应该依赖于抽象。
所谓高层组件，是由其他低层组件定义其行为的类。
例如，PizzaStore是个高层组件，因为它的行为是由比萨定义的。
依赖倒置原则，究竟倒置在哪里？
避免OO设计中违反依赖倒置原则
1 变量不可以持有具体类的引用。
如果使用new，就会持有具体类的引用。你可以改用工厂来避开这样的做法。
2 不要让类派生自具体类。
如果派生自具体类，你就会依赖具体类，请派生自一个抽象（接口或抽象类）
3 不要覆盖基类中已实现的方法。
如果覆盖基类已实现的方法，那么你的基类就不是一个真正适合被集成的抽象。基类中已实现的方法，应该由所有的子类共享。

抽象工厂模式
提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
比较工厂方法和抽象工厂。。。

要点1：
所有的工厂都是用来封装对象的创建。
简单工厂，虽然不是真正的设计模式，但仍不失为一个简单的方法，可以将客户程序从具体类解耦。
工厂方法使用集成：把对象的创建委托给子类，子类实现工厂方法来创建对象。
抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中。
所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合。
工厂方法允许类将实例化延迟到子类进行。
抽象工厂创建相关的对象家族，而不需要依赖它们的具体类。
依赖倒置原则，知道我们避免依赖具体类型，而要尽量依赖抽象。
工厂是很有为例的技巧，帮助我们针对抽象编程，而不要针对具体类编程。

《UNIX》超级工具

《UNIX超级工具》也是暑假的时候买的，两本，打五五折的时候买的，可还是花了七十多。有点Geek的味道。随便地翻了很久，要说学到啥也谈不上，这两本书本来就是随便翻的。不知不觉，这两部书已经做满了记号，趁现在有些时间，做个简单的整理。

有人说程序员的七种武器是：正则表达式、编程语言、数据库、算法、软件调试、开发环境；在UNIX环境下，灵巧而强大的工具已经充斥其间，我们所缺的只是一个善于思考的大脑。在UNIX下，你可以不必关心一些细枝末节的东西，从而把注意力集中到真正的思考上，工具和思想在这里充分地协调起来。在这本书里充斥着技巧、工具和表格。简洁而实用。唯一不足的地方就是体系混乱，不过既然是随便翻翻，这个缺点也就不能称之为缺点了。

我基础还太差，看这种充满技巧的书有只见树木不见森林之感。因而要在这本书里整理出什么来还真是个琐碎而吃力的过程，打算以后系统地学习LPI LINUX教程时再结合本书做些整理。在此就先搁置吧。

《重构》1-4章_基础

上个礼拜拿到了《重构》，读了前面的几章。还是蛮有意思的一本书，作者很幽默，译的也不错，只是价钱贵了点，有那么一点心疼。经典的书大多读起来不轻松，读快了啥也学不到，可有些经典的书读着有趣，随便翻翻有意无意间就会有比较大的收获，比如《代码大全》、《重构》等等。道理简单而实用，例子也恰到好处，加之文章穿插的点点幽默，实在是大快人心。

“记性好忘性大，故凡有所的必记诸文字”，译者熊节这话说得贴切。今天拿到的Maxtor的移动硬盘，广告居然叫“Save your life”。很好。不时时记录时时备份时时回顾，像我这等愚笨之人很快就会忘记生活了啥，这不能不说是一件可悲之事。

在http://old.blog.edu.cn/user2/26669/archives/2007/1753406.shtml 上发现了《重构》的笔记，我就直接厚颜无耻得拿来，然后再稍稍加些东西吧。

译序 --熊节
快速迭代&RAD --> crack的问题解决方式，在混沌的循环往复中实现需求--解构的美。
软件开发的理想国--在设计前期使用模式往往导致过度工程
重构--空气和水

前言

设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。
重构：有纪律，经过训练的，有条不紊。
聚沙成塔，从根本上改变设计

第一章、重构：第一个案例

例子：影片出租店用的程序。操作者告诉程序：顾客租了哪些影片、租期，程序就根据租期和影片类型计算费用；还要为常客计算点数。点数的计算与是否为新片有关系。程序为每次租用打印报表。

措施：同一段代码不要出现两次，应该用函数来定义。否则将来还要修改多处，容易引进错误。

需求变化1：用html方式输出报表。
需求变化2：要改变电影的分类方式，当然会影响收费和点数的计算，但是具体方案还没确定。

经验：不论用户提出什么方案，你唯一能得到的保证就是用户会在6个月内修改。
（这条经验很好玩，相当于说，你根本无法保证用户的需求不变化，唯一能得到的保证就是用户需求一定会变化。）
如果你发现自己需要为程序添加一个特性，但代码结构使你无法方便地那么做，则先重构再添加特性

重构第一步：为即将重构的代码建立测试环境。这是永远的第一步。
修改必须依赖测试，否则很容易进入新的bug，而且非常难debug。
重构之前，首先检验自己是否有一套可靠的测试机制，这些测试机制必须有自我检验能力。

措施：修改长的离谱的函数，并把函数移动到合适的class中去。
措施：修改变量的名字，使程序更可读。

note：任何一个傻瓜都可以写出计算机可以理解的代码。只有写出人类容易理解的代码，才是优秀的程序员。

阅读代码的时候，我经常进行重构。这样我就不断地把我的理解嵌入到代码中，才不会遗忘我曾经理解的东西。

如果一个类成员函数没有用到所在类的数据成员，则要考虑这个函数是否放错了位置。

尽量消除临时变量。临时变量往往形成问题，可能导致大量参数传来传去。在长长的函数中不易读。当然会付出性能上的代价。
作者的意思是，如果临时变量需要好几行来计算得到，就把临时变量的计算抽取为函数，称为query method。

重构以微小的步伐修改程序，及时发现。

运用多态取代switch、if/else。

一部影片可以在生命周期内修改自己的分类，但是一个对象却不能在生命周期内修改自己的类型（class）。--解决办法：state pattern
建立price类以及三个子类，与价格相关的代码移动到price相关类中。movie中设置一个price类型的成员对象。
price类中设置一个虚函数getprice，再实现一个默认的getpoints，让newprice子类去覆盖它。
把类型相关的代码用state/strategy代替。

本章总结：
extract method: 把长函数中的某部分抽取出来。把临时变量的计算抽取为函数（query method）。
move method: 看method使用哪个类的信息，就移动到哪个类中去。
replace conditional with polymorphism
self encapsulate filed ？这个是啥？
replace type code with state/strategy

重构的节奏：测试、小修改、测试、小修改。。。
重构后的程序风格将十分不同于过程化的风格。

第二章 重构原则

重构定义：对软件内部结构的一种调整，目的是在不改变软件的外部行为的前提下，提高可理解性，降低修改成本。
注意，重构的目的不是提高性能。
高效且受控的代码整理模式。
两顶帽子：添加新功能和重构。
开发过程中，需要经常换帽子戴，无论何时，都该清楚你戴的是哪顶帽子，而且不能同时戴两顶帽子。

为什么要重构？
1、改进软件设计。重构就是要让所有代码回到应该在的位置。重构还可以消除重复代码。代码结构的流失是累积性的。
2、使软件更容易理解。修改代码，让代码反映我的意图。重构可以帮助你看到你以前看不到的设计层面的东西。重构带你到更高的理解层次上。
3、帮助你debug。弄清楚程序结构的同时，也很清楚地看到自己所做的一些假设。做个有着优秀习惯的好程序员。
4、助你提高编程速度。良好设计才是快速开发软件的根本。

重构应该随时随地进行。

三次法则：如果第三次做类似的事情，就应该重构。Three strikes and you refactor.
添加功能时重构
修改错误时重构
复审代码时重构。复审（code review）就是别人看你的代码。
不必想像代码应该是什么，可以看见它是什么样。

为什么重构有用？kent beck

重构的方向：容易阅读；消除重复逻辑（代码）；新的改动不会危及现有行为；尽可能简单表达条件逻辑。摆脱束缚的道路。

间接层和重构 kent beck

间接层是双刃剑，需要更多的管理，难以阅读。但是，间接层的价值是：

1、允许逻辑共享；
2、对“意图”和“实现”分开解释。class和函数的名字可以看作你的意图，其内部代码是其实现。如果class和函数以“更小的意图”来编写，则“实现”更近距离地和“意图”接触。
3、将变化隔离。
4、把条件逻辑用多态来表示，往往能增加清晰度并提高弹性。

如果增加一个异常。。。为了控制这种情况，为一个pakage定义一个super异常，这个packge下的所有异常都继承自它。这样就可以新增异常了。

重构与设计互补。重构降低了预先设计的压力。可以带来更简单的设计。在设计时仍然考虑各种可能的变化和更为灵活的设计，但是要考虑：把一个简单的方案重构为灵活的方案需要多大代价？

教训：哪怕你完全了解系统，也请实际测量它的性能，不要臆测。（或许潜台词是，你也许了解程序的架构和各种细节，但是你不一定了解系统中代码的执行率。）

要想优化性能，必须认真测量。



重构与性能：重构的确会使软件的运行变慢，但它使优化阶段的性能调整更容易。
efficient:高效；effective：有效
首先编写出可调的软件，然后调整它以获得足够的速度。
时间预算法 >> 持续关注发 >> 90%"发现热点，去除热点"

第三章：代码的坏味道

知道How不代表知道When，决定何时重构、何时停止和知道重构机制同样重要。
没有任何知识规矩能比得上一个见识广博者的直觉。

1、重复代码

同一个类里的两个函数有相同的表达式。方法：extract method

两个兄弟子类里含有相同的表达式。方法：对两个类使用extract method，然后使用pull up method，放到父类中。


2、过长函数

现在的编译器优化已经基本消除了函数调用开销。

小函数容易理解。让函数容易理解的关键是，给函数起一个合适的名字。

每当感觉需要用注释说明什么的时候，就把那部分提取成函数，以其用途而不是实现方式命名。

其实关键不在于函数的长度，而在于“做什么”和“如何做”之间的语义距离。

99%的场合下，只需要使用extract method

对于大量的参数，可以引入参数对象；对于临时变量，可以使用query method。

杀手锏：replace method with method object.


3、过大的类

很容易产生代码重复。

产生太多的临时变量。


4、过多的参数

类可以减少参数，因为成员函数需要的很多参数可以在类中找到。


5、发散式变化(divergent change)

当需求变化一点时，一个类需要修改好几个函数，则这个类或许应该被拆成两个类。


6、散弹式修改（shotgun surgery）

当需求变化一点时，需要对多个类做出小修改。应该使用move method和move field把要修改的代码放到一个类中。

原则是：将一起变化的东西放在一块儿。


7、依恋情结（feature envy）

某个函数对某个宿主类以外的类特别依赖。症结往往是数据。extract method , move method


8、数据泥团（data clumps）

常常可以看到：两个类中有一个以上的相同数据成员，许多函数中有相同的参数。这些总在一起出现的数据应该提取为一个类。

更重要的是，可以帮助寻找feature envy。


9、基本类型偏执（primitive obsession）

很多程序员懒得定义一些小类。

你可以定义一些与基本类型差不多的小class，比如字符串、日期、含一个起始值和一个结束值的range class、电话号码等等特殊的字符串。


10、swith

switch的问题在于重复。？

如果要添加一个case子句，很容易出错。


11、平行继承体系

就是两套class有相似的继承体系。当你为一个类增加子类时，必须为另一个类增加一个平行的子类。

shotgun surgery的一种特殊情况。


12、冗余类

对于没用的类、体系结构坚决消除。


13、过多考虑未来不确定的需求

如，看不到用处的扩展性。


14、很少用的数据成员

有的field可能只在极少情况下被使用。可以为这个field及其相关代码extract class。


15、过度耦合的消息链

没懂。也许后面有例子会好一点。


16、中间人

太多的delegation，就产生了中间人。中间人几乎不干实事，应该消除。


17、过分亲密

两个类过于亲密，互相探究彼此的private部分。有很多方法解决这个问题。可以move method,move field，extract class等等。


18、异曲同工的类/函数

两个函数功能一样但是签名不一样。


19、不完美的程序库

如果程序库不满足需求，可以：introduce foreign method, introduce local extension


20、纯粹的数据类

就像java bean?也挺有用的啊

只有fieild和getter setter。应该把调用它的那些代码抽取到这个类中，以隐藏一部分getter/setter


21、拒绝继承

如果子类拒绝继承父类的某些field、某些函数的实现，问题不算很大，甚至可以不用管；但是如果子类拒绝继承父类的接口，这就出现问题了。


22、过多的注释

当你需要撰写注释，请先尝试重构，试着让所有的注释都变得多余。

注释常常把我们带到之前提到的各种smell。如果注释要解释一块代码做了什么，请extract method；如果已经提取出函数但是仍然需要注释，则请rename method；如果需要说明某些入口条件，请引入断言。

注释可以写todo，why。



第四章:构筑测试体系
seft-testing Code: 确保所有的测试都完全自动化，让它们自己检验自己的测试结果。
极限编程者都是十分专注的测试者。
testing main： 每个Class都需要有一个用于测试的main()
频繁地运行测试，每次编译都把测试考虑进去。
编写测试代码时，先让它们失败--failures <--> errors
bug --> 编写单元测试
编写不完善的测试并实际运行，好过对完美测试的无尽等待。
必然有错 --> 抛出异常

《执行》--突破

刚刚考完的高等数理统计，是我进入上财以来遭遇的最大的失败，考前拼死拼活看了两天书，结果看来是挂了。觉得有些惭愧，完全违背了我读研的本意，要照这样下去，我还不如退学找个工作实在。

我不能说不努力，开学到现在三个月，我自己觉得也很累。脑子累，心累，身体也累。一直用力寻找着突破，可结果是让自己越来越累。大学时每学期或多或少都能有些收获，都能对自己的履历有所充实，可现在三个月过去了，除了累，除了不好的成绩，我好像并没有得到什么。

现在的我比任何时候都更需要一种简单的哲学，一种上进而充满张力的方式。前几天抽空看了下《执行--完成任务的学问》，现在顺便写些心得，同时也当作对自己的勉励。

Execution  --the discipline of getting things done。我并不认为执行是一个新鲜的事务，“实事求是”，“实践是检验真理的唯一标准”，这些话说了好多年，可说多了反而忘了确切的含义，到现在反而要老外来告诉我们实事求是的含义，不能不说有点可悲。在我看来，执行不光是一个企业的事情，在自身的层面上，我们更需要这种实事求是的精神。在《卓有成效的管理者》这本书中，作者认为所有的知识工作者在某种意义上来说也是管理者，在时时刻刻地管理着自己的时间、精力和行为。我目前面临的困境只有通过实事求是的分析和卓有成效的执行才能突破，我依然坚信我的选择，同时，就算我做错了，我也无路可退。

下面的读书笔记摘自“三真阁” 。

执行是一门学问，是战略的一个内在组成部分。执行是一套暴露现实并根据现实采取行动的系统化的流程。执行应当是一个组织文化中的核心元素：执行必须渗透到企业的回报系统和行为准则当中，它既是企业文化，也是塑造企业文化的方法。

贯彻执行文化的基础是要在企业中推行坦诚、实事求是的交流活动和企业文化，而这就要求领导者通过亲身参与推动文化变革、战略制订乃至运营计划 落实和跟进，充分了解自己的企业和员工，尽一切机会对管理人员进行影响和指导，但这不等于要求领导者事必躬亲，而是要按照一个事先制订的跟进计划，对关键 点和关键环节的执行进行关注、对结果及时评估和应变，就像柳传志在专文推介中说的，“有效的执行是需要领导者亲力亲为的系统工程，而不是对企业具体运行的 细枝末节的关心。”
　　
执行的关键就在于把战略与企业的实际情况、实际能力结合起来，建立相辅相成、近乎一体的战略、人员与运营流程。

人员流程的关键是，在战略的高度进行人力资源管理，把人员的招聘、评估、培养和调动与岗位需求切实的统一起来——而岗位需求恰恰是建立在企业的战略和运营要求之上的，以坦诚的态度、统一透明的评估标准、及时并集思广益的评估和沟通活动，来推动人员流程发挥作用。

战略流程的关键是，在制订的时候就充分考虑其可执行性，也就是人员的要求是否满足，是否能够落实为运营计划。战略制订和评估过程中，要充分调 动真正的执行者参与讨论，确保对竞争环境和执行能力已经具有充分准确的了解，保证战略在执行部门得到充分的理解和支持，在人员和运营计划的落实上没有问 题。领导者还可以通过此过程指导员工，推动文化变革，凝聚团队，激发斗志。领导者还要在战略评估结束之后的跟进中确认讨论共识，并将其作为战略实施过程中 的进程指标，强调在战略、人员和运营之间建立必要的联系。

运营流程的关键是，通过更广泛的参与（各部门的执行团队，甚至所有成员），对竞争环境和未来变化假设进行更仔细的考察讨论，对可能开展的项 目对照战略方向进行取舍，将战略计划落实为更详细的企业目标、行动计划和跟进措施（及时的评估和应急计划），为工作开展提供明确的指导方向。通常情况下， 一份运营计划包括了你的企业准备在一年之内完成的项目——与企业预算和财务目标相结合，而预算和财务目标恰恰应该根据企业的运营计划来确定。

本书其他细化内容其实就是各门科管理科学的论述、操作实务和案例分析，有益于对照自查。

Life is light

今天看了《布拉格之恋》，很长的一部电影，讲述着冗长无奈而又无从逃避的生活。《生命中不能承受之轻》，高中时看过这本书，以后逐渐淡忘，相信命运靠的是实实在在的打拼。进了大学就远离了诗歌、散文、小说。参考手册几乎成了我最喜欢的书。

上海的确是一个容易诞生小资情感的地方。因为在这个地方，人太容易发觉自己的无足轻重，太需要麻醉。我依旧是个无趣而又无足轻重的人，小资离我实在太远，生命是轻的，也许没有意义。但我依然会选择打拼，更实在，更踏实。既然原本就没有意义，我也自然不用为之悲伤。

这学期看了很多书，却什么也没做，依旧卑微地努力，只希望今天的自己比昨天能多些什么。却也许什么都没得到。我们都在赶路，只有在回忆中才能寻找偶尔的满足。

喝杯咖啡，继续战斗。

Cute Communism

英语口语课的演示，胡乱搜集了些图片，拼凑了几张slide。

爱、策略、重构

每次上金融博弈那个个性的老头总会给我些启发，如下：

今天的开篇词是“爱”，老头摘了圣经中的一段话作为阐释，具体记不清了，反正是大爱无形的那种爱。然后他坦承了他老婆逼着他说爱，那老头勉勉强强婚前说了一次，然后就再也没说过。他很坦诚地说他也不知道啥是爱，他觉得对别人的爱说到底是爱自己。那老头一定是水瓶座的，反正我也这么觉得.


然后是正题，讲到了策略设计，很有意思的话题，我觉得工资的定价机制也是个策略问题，也就是个博弈论的问题。一般企业都有固定的职级和工资级别，职级是公开的而工资的基本却不透明，这肯定有着其中的道理，而且也许不那么简单，不仅仅是激励和士气的权衡。以后空了再找些相关内容看看。


然后今天又到了一批书，《重构》、《编程之美》、《执行力》、《卓有成效的管理》等等。这两天买书花了300多块钱，都是计算机、经管、投资方面的经典之作。愿读完能有些提高吧。


昨天参加竞选失败，总体来说一是由于开学以来一直忙着自己的事情，和大家有些脱节；二来是个平衡问题，一些无意的因素让我处在不利的位置；三来竞选演讲做得实在很烂，犯了一些大忌。虽然有点郁闷，但我并没损失什么，对我的现在和将来也不会有什么影响，其次我也发现了自己存在着一些问题，需要调整，用傻一点的话就是“重构”；个性的调整也是个迭代的过程。

时间

忽然间就要考试了，这学期天天忙碌，却不知忙的啥，所谓结构化混日子，说的就是我现在这样子吧。还坚信努力总有回报吧，SNA和高统，这半个月就彻彻底底地交给你们啦。爬山虎，看着还像是秋天，其实已是冬日。这植物，和我一般迟钝那。
已是十二月初，回顾这大半个学期，一直忙忙碌碌，可却第一次觉得有些迷惘，选择考研、特别是考统计也许真是一个失误；但这些都是无法改变的事实，我所能做的是尽所有的可能，将错误的成本降到最低。

Code Complete PART 6

System Considerations

chapter 27: How program size affects construction
随着项目的增大交流需要加以支持
放大轻量级的方法要好过缩小重量级的方法，最好使用适量级的方法

1. Commmnication and size

2. Range of project size
3. Effect of project size on errors
4. Effect of project size on productitivity
5. Effect of project size on development activite
交流、计划、管理、需求分析、设计、架构、集成、测试、文档的非线性增长
程序 -- 产品 -- 系统 -- 系统产品
Methodology and size 方法论和规模

Chapter 28: Managing construction
一般管理 > 软件管理 > 构件管理
贯彻标准，使用更为灵活的方法 --> 好的编程实践
程序员和管理人员都是人
1. Encouraging good coding
Techniques for encouraging good coding
逐行检查、要求代码签名、安排好的代码示例、代码是公有财产、奖励好的代码
2. Configuration management
SCM: Software configuration manangement
Requirements and design changes
遵循某种系统化的变更控制程序
成组地处理变更请求
评估变更成本
提防大量的变更请求
变更控制委员会
Tools:
cvs, svn, Machine configurations, Backup plan
降低程序员的额外负担；避免对项目的过度控制
3. Estimating a construction schedule
Estimation approaches
评估软件；算法方法：Cocomo 2
建立目标
为评估留出时间并做出计划
清楚说明软件需求
在底层细节层面进行评估
使用不同的评估方法并进行比较
定期做重新评估
Estimation vs. Control
what to do if you are behind:
项目并不能在后期把时间补回来，只会越拖越坏
扩充团队？缩减项目范围。
4. Measurement
留心度量的副作用
反对度量就是认为最好不要知道真实
5. Treating programmers as people
程序员并非只是与硅芯片打交道的有机物。
How do programmers spend their time
Variation in performance and quality
Individual variation
Team variation
Religious issues 信仰问题
编程语言、缩进风格、大括号、IDE、注释风格、效率 vs. 可读性、方法的选择、编程工具、命名习惯、goto、全局变量
6. Managing your manager
人性的弱点

Chapter 29: Integration
1. Importance of the integration approach
结果也许正确，但错误的过程依然会导致失败
2. Integration fraquency -- phased or incremental
Phased integration
测试、编码、测试、调试。单元开发
将这些类组合成系统（system integration）
测试调试（system dis-integration）
Incremental integration
开发模块，测试调试模块，集成到系统
Benefits of incremental integration
易于定位错误
及早在项目中取得系统级的成果
改善对进度的监控
改善客户关系
更充分地测试系统的各个单元
能在更短的开发进度计划内建造出整个系统
3. Incremental integration strategies
Top-down Integration
能较早地测试系统的控制逻辑
Bottom-Up Integration
容易定位错误
要求在开始前，已经完成整个系统的设计工作
Sandwich integration
Bottom-UP + Top-down
Risk-Oriented integration
困难部件优先集成法
鉴别风险级别
Feature-Oriented Integration
以一组构成一项可确认功能的类为单位进行集成
T-Shaped Integration
选中特定的竖直块，及早地进行测试和集成
4. Daily build and smoke test
使一些工作及早地浮出水面
每日构建（daily build）
检查失败的build
每天进行冒烟测试
编译自动化
但有意义时，才将修订加入到build
代码添加到系统前进行冒烟测试
为即将添加的代码准备暂存区

Note of Excel Function

以前一直没有系统学过Excel，可最近发现Excel和VBA编程在财务的各个方面都是非常重要的。正好最近要做财务报表分析的大作业，趁此机会先学习下Excel的函数，以后有时间再看下VBA。
教材是张迎新的《Excel 2003 函数应用完全手册》，很简洁，很手册的一个东西。下面的笔记是书的一些摘录：

函数和公式
Excel 函数可以分为内置函数和扩展函数两大类。前者只要启动了Excel，用户就可以使用它们；而后者必须通过单击“工具→加载宏”菜单命令加载，然后才能像内置函数那样使用。
函数的参数
数组：
Excel 中有常量和区域两类数组。
前者放在“{}”(按下Ctrl+Shift+Enter 组合键自动生成)内部，而且内部各列的数值要用逗号“,”隔开，各行的数值要用分号“;”隔开。{56,78,89;90,76,80}
区域数组是一个矩形的单元格区域，该区域中的单元格共用一个公式。“B1:B3,A1:A3”
错误值：
ERROR.TYPE(error_val)
单元格引用：
相对引用：=SUM(A2:E2)
绝对引用：=SUM($A $3:$E $3)
混合引用：混合引用有“绝对列和相对行”，或是“绝对行和相对列”两种形式。前者如“=SUM($A3:$E3)”，后者如“=SUM(A$3:E$3)”
三维引用：=SUM(Sheet2!A1:A6,Sheet3!B2:B9)
=SUM([Book2]Sheet1! SA S1: SA S8,[Book2]Sheet2! SB S1:SB S9)
三维引用的要受到较多的限制，例如不能使用数组公式等。
名称和标志：
=AVERAGE(B2:B46) --> =AVERAGE(物理分数)
创建好的名称可以被所有工作表引用，而且引用时不需要在名称前面添加工作表名(这就是使用名称的主要优点)，因此名称引用实际上是一种绝对引用。但是公式引用“列标志”时的限制较多，它只能在当前数据列的下方引用，不能跨越工作表引用，但是引用“列标志”的公式在一定条件下可以复制。

Code Complete PART 4

Statements
Chapter 14. Organizing Straight-line code
主要原则：按照依赖关系进行排列
1. Statements that must be in a sepcific order
设法组织代码，使依赖性变得非常明显
利用子程序名、子程序参数显示依赖性
用注释对不清晰的依赖关系进行说明
2. Statements whose order doesn't matter
making code read from top to buttom
localized --> short live time
grouping related statements
不应该交叠，但可能嵌套

Chapter 15: Using conditionals
1. if statements
plain if-then statements
先处理正常情况，然后其它
确保对于“==”是正确的
把正常的情况处理放在“if”后面
让if语句后跟随一个有意义的子句
chains of if-then-else statements
用布尔函数简化复杂的检测
最常见的放最前
2. case statements
choosing the most efficitve ordering of cases
字母序、正常放最前、频率序
tips for using case statements
简化每种情况对应的操作
不要为使用case刻意制造一个变量
default子句只用于检查真正的默认情况
避免代码执行跨越一条case子句的末尾

Chapter 16. Controlling Loops
1. selecting the kind of loop
counted loop; coutinously evaluated loop; endless loop; iterator loop
when to use while loop
预先不知道迭代的次数
with test at the beginning & end
when to use a loop-with-exit loop
终止条件出现在循环的中部
break; goto
把所有的退出条件放在一处，用注释阐明意图
when to use a for loop
执行固定次数的循环，不需要循环内部控制
when to use a foreach loop
消除了循环内务处理
2. Controlling the loop
减少影响循环的因素数量，把循环内部当作子程序
entering the loop
只从头部进入
初始化代码紧反正循环前
用while表示无限循环
在while适用的时候，不使用for
processing the middle of the loop
避免空循环
循环的内务操作反正循环的开始或结尾
一个循环只做一件事
exiting the loop
终止确认条件
避免依赖循环下标的最终取值
考虑使用循环计数器
小心break&continue
带标号的break
checking endpoints
using loop variables
使用有意义的名字：提高可读性，避免下标串话
把循环下标的作用域限制在本循环内
how long should a loop be
尽可能短，嵌套在三层以内
把长循环的内容移到子程序内
3. Creating loops easily - from the inside out
inside out; 使用字面量
4. Correspondence between loops and arrays
密切联系但不是必然的

Chapter 17: Unusual contorl structures
1. Multiple returns from a routine
如果能增强可读性，就使用return
用guard clause（早返回或退出）来简化错误处理
2. Resursion
tips for using recursion
确认递归能够停止
使用安全计数器防止无穷递归
限制在一个子程序内
递归 or 循环 -- 阶乘
3. goto
万不得已才使用goto
goto导致的效率的提升需可以估量
尽量在每个子程序中最多使用一个goto
尽量让goto先前跳转而不是向后
goto标号
确认goto不会产生执行不到的代码

Chapter 18: Table-driven methods
Table-driven is a scheme -- 从表里查找信息而不是用if or case
复杂逻辑和复杂继承结构的替代方案
1. General considerations of using Table-Driven methods
查询记录的方法：
Direct access
Indexed access
Stair-step access
2. Direct access tables
Date-in-Month example
Flexible-Message-Format Example
Logic basied vs. Object-Oriented vs. Table-Driven
Fudging lookup keys
复制信息从而能直接使用键值
转换键值使之能直接使用
把键值转换提取成独立的子程序
3. Indexed Access tables
4. Stair-step Access tables
把每一区间的上限写入表中，使用循环按照各区间的上限检查分数
留心端点
二分法查找，索引访问？
最好是去选择一个好的方案同时避免灾难，而不是试图寻找最佳的方案。
5. Other Examples of Table loopups

Chapter 19: General Control Issues
1. Boolean expressions
Using the true and false for boolean tests
Making complicated expressions simple
拆分复杂的判断并引入新的布尔变量
将复杂的表达式做出布尔函数
用决策表代替复杂的条件
Forming boolean expressions positively
I ann't not no undummy. 我并非不是一个不傻的人。
用狄摩根简化
Using parantheses to clarify boolean expressions
Knowng how boolean expressions are evaluated
Writing numeric expressions in Number-line 2order
Guildines for comparisions to 0
隐形地比较逻辑变量
和数值表达式相比使用显示写法
指针 -- NULL
Common problems with boolean expressions
C家族中，应该把常量反正比较的左端

2. Compound Statements(Blocks)

3. Null statements

4. Taming Dangerously deep nesting

重复检查条件中的某一部分来简化嵌套的if

使用break来简化

if --> if-then-else

if --> case

抽取并放入子程序

对象和多态派分

5. A programming foundation: Structured Programming

structured goofing off 结构化混日子

The three components of structured programming

sequence; selection; iteration

6. Control structures and complexity

应用程序的复杂度是由它的控制流来定义的

General guidelines for reducting complexity

How to measure: decision point

if; while; repert; for; and; or; case

0-5: good; 6-10; 10+

冬日

今天朋友过生日，下午三点出发，到晚上快十一点才回了宿舍。四个刚工作的女孩子和四个IT男，80、82、85的加上最小的86的我。四个女人吵的不闲累，我听着都心力憔悴。。原本以为去了就吃，结果被叫去了买菜。。辛辛苦苦做好了难吃的又都成了我做的。。这世道。

路上无聊的公交时间拍了一些照，冬天真的来了，可正因为冬天来了，有了冷也就有了暖。大千世界滚滚红尘真是很神奇的一个东西。让人时而逃避时而依赖。平凡的人们一日又一日地或忙碌或闲适，游戏着生活，也被生活游戏。

四个IT人，一个比一个冷，无聊间又说起了水瓶的坏话，我同意。某些角度看，我的确是个自由自私同时无趣的人。过去、现在和将来，我都会努力做个个自信、事实求是而又卑微的工程师。呵呵，努力！

WALL.E

WALL•E 全名叫Waste Allocation Load Lifter-Earth Class, 700年来日日尽忠职守的留在地球清理垃圾，唯一伴侣就是一只生命力超强的小强。每天做着同样的事情，寂寞无奈却又乐在其中。
这周一直在看UNIX，基本无序但每天都学到很多，大学时如果选择C和UNIX这方向的话，对计算机应该能有更好的理解。可惜我过早选择了Java。
晚上在china-pub上买了《编程珠玑》的两册，打算好好拜读。然后，差不多要考试了，继续浑浑噩噩地努力吧。

课程论文的LATEX模板

上午费了些劲李果正（Edward G.J. Lee）的《由TEX/LATEX 制作中文PDF文档》中的样式和清华毕业论文的样式结合，做了一个适合一般课程论文的Latex模板。比较简单清爽。

源码如下：
\documentclass[dvipdfm,11pt]{article}
\usepackage[paper=a4paper,dvips,top=2.5cm,left=2.8cm,right=2.8cm,foot=1cm,bottom=3.2cm]{geometry}
\usepackage{CJK}

% 控制标题的宏包
\usepackage[sf]{titlesec}
% 控制目录的宏包
\usepackage{titletoc}

%引用上标
\makeatletter
\def\@cite#1#2{\textsuperscript{[{#1\if@tempswa , #2\fi}]}}
\makeatother

\newcommand{\song}{\CJKfamily{song}} % 宋体 (Windows自带simsun.ttf)
\newcommand{\fs}{\CJKfamily{fs}} % 仿宋体 (Windows自带simfs.ttf)
\newcommand{\kai}{\CJKfamily{kai}} % 楷体 (Windows自带simkai.ttf)
\newcommand{\hei}{\CJKfamily{hei}} % 黑体 (Windows自带simhei.ttf)
\newcommand{\li}{\CJKfamily{li}} % 隶书 (Windows自带simli.ttf)

\newcommand{\yihao}{\fontsize{26pt}{36pt}\selectfont} % 一号, 1.4倍行距
\newcommand{\erhao}{\fontsize{22pt}{28pt}\selectfont} % 二号, 1.25倍行距
\newcommand{\xiaoer}{\fontsize{18pt}{18pt}\selectfont} % 小二, 单倍行距
\newcommand{\sanhao}{\fontsize{16pt}{24pt}\selectfont} % 三号, 1.5倍行距
\newcommand{\xiaosan}{\fontsize{15pt}{22pt}\selectfont} % 小三, 1.5倍行距
\newcommand{\sihao}{\fontsize{14pt}{21pt}\selectfont} % 四号, 1.5倍行距
\newcommand{\banxiaosi}{\fontsize{13pt}{19.5pt}\selectfont} % 半小四, 1.5倍行距
\newcommand{\xiaosi}{\fontsize{12pt}{18pt}\selectfont} % 小四, 1.5倍行距
\newcommand{\dawuhao}{\fontsize{11pt}{11pt}\selectfont} % 大五号, 单倍行距
\newcommand{\wuhao}{\fontsize{10.5pt}{10.5pt}\selectfont} % 五号, 单倍行距

\newlength \CJKtwospaces \CJKtilde

\titleformat{\section}[hang]{\sf \hei \sihao}
{\sihao \thesection}{0.5em}{}{}
\titlespacing{\section}{0pt}{-0.2em}{0.8em}

\titleformat{\subsection}[hang]{\hei \sf \banxiaosi}
{\banxiaosi \thesubsection}{0.5em}{}{}
% {\banxiaosi \thesubsection}{0pt}{}{}
%\titlespacing{\subsection}{0pt}{1.5ex plus .1ex minus .2ex}{\wordsep}
\titlespacing{\subsection}{0pt}{-0.25em}{1em}

\titleformat{\subsubsection}[hang]{\hei \sf}
{\thesubsubsection }{0.5em}{}{}
%\titlespacing{\subsubsection}{0pt}{1.2ex plus .1ex minus .2ex}{\wordsep}
\titlespacing{\subsubsection}{0pt}{0.25em}{0pt}

% 缩小目录中各级标题之间的缩进
\dottedcontents{chapter}[0.0em]{\hei\vspace{0.5em}}{0.0em}{5pt}
\dottedcontents{section}[1.16cm]{}{1.8em}{5pt}
\dottedcontents{subsection}[2.00cm]{}{2.7em}{5pt}
\dottedcontents{subsubsection}[2.86cm]{}{3.4em}{5pt}

% 颜色的设定要引进 color package。
\usepackage[dvips]{color}
\definecolor{webbrown}{rgb}{.6,0,0}
\usepackage{times}
\linespread{1.4}

% 由于把行距加大，要把脚注的行距缩成预设的，这个设定采自吴聪敏教授的
% 《cwTeX 排版系统》修订二版一书，页 143。
\let\oldfootnote\footnote
\renewcommand\footnote[1]{\oldfootnote{\renewcommand\baselinestretch{1.0}%
\large\footnotesize\ignorespaces#1}}
\addtolength{\footnotesep}{1pt}
\begin{document}
\begin{CJK*}{GBK}{song}
\newcommand{\bigfive}{\textrm{Big-5}~码}
\renewcommand{\figurename}{图~}
\renewcommand{\tablename}{表~}
\renewcommand{\contentsname}{目~录~}
\renewcommand{\appendixname}{附~录~}
\renewcommand\refname{参~考~文~献}
\newcommand\prechaptername{第}
\newcommand\postchaptername{章}
\renewcommand\indexname{索~引}
\renewcommand\abstractname{摘~要}
\renewcommand{\today}{\small \number\year~年~\number\month~月~\number\day~日}
\title{\textcolor{webbrown}{\Huge \sf \kai 质疑的质疑}\\{\Large 对~ What's Happening to China's GDP Statistics? 的分析}}
\author{\small Sunix.Xu~~~~Email:xuyizun@gmail.com\\ \small SHUFE Statistics~~~~NO:XXXXXXXXX}
\maketitle
\tableofcontents
\newpage
% 调整段落间距离
\parskip=0.2cm

\section{前言}
\label{sec:introduction}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

\begin{thebibliography}{99}
\bibitem{thomas} Thomas G. Rawski:
《What's Happening to China's GDP Statistics?》,
China Economic Review
2001.12
\end{thebibliography}
\end{CJK*}
\end{document}

质疑的质疑

下文是国民经济核算的案例论文，对Thomas G. Rawski的文What’s Happening to China’s GDP Statistics? 所做的分析。

质疑的质疑
--对What’s Happening to China’s GDP Statistics? 的分析

1 前言
美国匹兹堡大学经济学教授Thomas G. Rawski在2001年12月在《中国经济评论》发表了著名的《What’s Happening to China’s GDP Statistics?》[1]一文。他通过研究中国各省市的经济统计资料，发现这些资料与中国国家统计局发表的数字有不相符合之处，因而提出了对中国统计数据的质疑，他根据中国经济增长与能源消费相反的变动趋势并对比亚洲其它国家后认为，中国自1998年以来的经济增长速度是不真实的。
而在这同时，国外和国内的很多经济学家对Rawski的质疑提出了反质疑，从GDP统计、能源统计、中国经济结构转型等多个方面回答了GDP数据和能耗数据间的矛盾。
本文将本着客观的立场，首先概述Rawski教授的质疑，之后简述国内外学者对此问题的观点，然后进行对比分析并给出我的见解，最后将对GDP统计存在的问题作出总结。
需要说明的是Rawski只是从客观的角度对问题进行了描述和分析，并不带有政治色彩，他的分析对于我国发现并分析发展中遇到的种种问题有着很大的帮助。

2 Thomas教授的质疑
Thomas G. Rawski教授通过以下三个方面对中国GDP统计的真实性提出质疑[1][4]：
2.1 数据之间的不一致性
经济增长率数据与能源消耗、就业和消费价格数据之间的不一致性
中国经济增长与能源消费变动趋势相反，这不符合人们的常识，1997年到2001年间，官方公布的GDP增长了24.7%而能源消耗却降低了12.8%，同时，一些数据表明，中国在97/98年的能源利用率依旧停留在83/84年水平。
对比亚洲其它国家及中国在97年以前10年的数据，能源消耗和GDP一般存在着同向运动的规律。而中国在97年到2001年间的数据却明显违背了这一规律。
生产数据之间以及生产数据与投资数据之间的不一致性
1998 年,水灾是20 世纪中国十大自然灾害之一，但除一个省之外，所有省的农业产出
都是增加的；94 种主要工业产品中只有14 种产品获得两位数增长，工业生产却上升
了10. 75%；钢材消耗和水泥产出增长不到5% ,投资却猛增13. 9%。
消费数据之间的不一致性
除2000 年外,全国社会消费品零售额增长比人均消费支出增长快得多。
消费数据与收入数据之间的不一致性
社会消费品零售额的增长比住户收入的增长快得多，这意味着平均消费倾向在上升。
然而,最近的研究发现,消费支出占收入的比率呈下降的趋势。
2.2 来自中文评论文章的信息
Rawski在文章中摘引了几篇评论中国官方统计数据的中文文章的观点，并声称，大量的中文评论文章表明在整个商业社会和各级政府，经济发展指标的虚报浮夸成为一种普遍现象。
文中指出，从1998 年开始,国家统计局抛弃了省级经济增长数据；虽然国家统计局近些年努力创造跨越地方和省级政府的统计网络，但它不具备在正常的信息渠道以外搜集数据的能力。
2.3 经济增长率的上限
中国航空客运业的客户主要是国内收人最高的阶层，而他们的收入增长水平应超过平均增长水平。因此，航空客运的增长应该高于居民可支配收人的增长，而后者是的计算基础。但罗斯基却计算出在97、98年间乘客里程的增长只有2.2%，而同期GDP的增长率却分别为8.8%和7.8%。
基于以上几点，Rawski认为地方官员迫于政绩的压力，或因为编造数据的收益超过了因编造数据带来的风险从而欺骗中央，所以最终的统计数据是不真实的；然而统计资料中有些数据却反映了经济的实质，比如能源消耗和民航业的发展。97年到01年，GDP增长了，而能源消耗却在下降，Thomas认为能源利用效率的提高不足以解释这巨大的反差。

3 对质疑的反质疑
对于Rawski的质疑，国内外的专家学者纷纷给出了自己的见解，对他的质疑提出了各自的观点。主要集中在以下几个方面：
GDP和能耗并不一定存在严格的规律
经济增长模式的转变导致了数据的不一致性
3.1 GDP和能耗的非一致性
任若恩教授认为，经济增长率与能源消耗增长率应该大致相等，这一假设要求满足一个国家在经济发展过程中是同质的，能源消耗的产业结构和使用能源的技术不变。针对罗斯基依据经济增长率与能源消耗数据之间的不一致性对中国经济增长率数据的质疑，任若恩考察了德国、英国、美国、日本和韩国的经济增长与能源增长数据之间的关系。他发现，这些国家都曾经出现过经济增长与能源增长数据不同步的现象：从经济发展历史看，在不同国家的经济发展中，如日本、德国、英国等，能源增长低于经济增长的数据出现频率不在少数。美国大概两次，日本一次，都出现过GDP增长而能源下降的历史的差距[3][5]。
如果因为能源增长率低于经济增长率，因此就认为经济增长率数据可能出现高估，那么，当能源增长率高于经济增长率时，就可以怀疑经济增长率数据出现低估，而这显然是没有依据的。
能源总产和总消费与中国经济增长之间从来不存在十分密切的关系，在1978–2000年间，有13年能源的消费弹性（消费增长率与GDP增长率的比例）是低于+0.5的，而在1978–2001年间也有14年能源的生产弹性（产量增长率与GDP增长率之比）低于+0.5。最关键的是, 并不是只有以往几年才是如此，连公认的中国经济过热的1992–1994年间，能源增长和消费均跟GDP没有什么关联。此期间同步伴随中国大规模的能源供给结构调整，煤炭供给受限严格，而电力消费有所上升，煤炭严格限制可能是导致统计内能源消费萎缩的主要原因[6]。
3.2 经济增长模式的转变导致了数据的不一致性
张新和蒋殿春在《中国经济的增长――数据的可信度以及增长的微观基础》[6]中对近年来中国经济增长速度及其与企业微观绩效之间的关系进行了理论和实证性的分析研究，结果表明：首先，我国近年来的经济增长数据墓本可靠；再者，我国宏观和徽观经济之间并不存在本质性的背离。
我国目前仍然处于粗放式经济增长阶段，主要是依靠物质资源、人力资源的大投入和规模的快速扩张来推动经济的高速增长；但只要以后中国整个经济体系的效率是逐步上升，单位能耗逐渐降低，那么电力等生产资料产量的增长速度在一个很长的时间内将慢于整个经济的增长速度。正是能源效率的改进导致能源消耗持续下降。

4 统计数据存在的问题
事实上，中国经济增长率的统计的确存有问题，在计算水平、方法与范围等方面有待进一步改进提高。一些省份有多报的动机，同时也有一些省份有瞒报的动机。统计数据，尤其是GDP数据，没有一成不变的，随着时间的推移，基础资料和统计方法会不断完善，为了保持客观性和可比性，历史数据需要不断进行调整。美国就曾经对它的GDP历史数据作过11次调整。
在《南方周末》对国家统计局国民经济核算司司长许宪春的访谈中，许宪春揭示了统计数据存在的一些问题[10]：
4.1 统计数据来源及其对比
数据来源
– 国家统计局独立调查的数据
内容：全国的粮食产量、棉花产量、主要畜禽产品产量；规模以下的非国有工业企业、小型商业企业、个体工商户的产值和增加值；农村固定资产投资、城乡居民住户收入和支出、商品和服务的价格。
– 地方汇总的数据
内容：全部国有企业和年产品销售收入500万元以上的非国有企业。
数据源对比
地方汇总数据统计方法以全面报表为主，基层单位向地方政府统计部门报送报表，然后层层汇总到国家统计局。一般来说，这种调查方法由于涉及的单位多，需要的人员多，因而难以保证基层统计资料的准确性。抽样数据抽样调查涉及的单位少，需要的人手相对少，因此有可能对统计人员进行较全面的业务培训，从而能够提高基层统计资料的质量。
综合统计数据来源及其对比，我们可以发现国家统计局可以控制质量的数据仅占到国民经济的很少部分，全部国有企业和规模以上的非国有企业的数据要靠地方汇总，这部分的数据质量难以得到十分的保证。
4.2 数据质量评估及数据调整
在数据评估方面，由国家统计局评估省一级的数据，省统计局评估地市一级数据。但由于《统计法》是一种行政法规，加之统计局在行政机构中的地位，对于一些地方官员并没有很强的约束力。
目前各省公布的GDP加总后都要高于国家统计局公布的全国GDP，国家统计局需要挤出其中的“水分”，主要采用以下的方法：
² 采取抽样调查的方法
² 实行超级汇总方法排除中间层次的干扰
² 加大执法力度，查处统计违法现象
² 建立数据质量评估制度
从中，我们可以看到国家统计局对于挤出“水分”并没有真正强有力的方法。从以上内容我们可以分析得出，国家统计局对于数据的质量没有十分可靠的保障，地方政府官员可能出于自身利益的考虑多报或少报数据。东部沿海的省分由于以民营经济为主，可能会低报经济增长数据以减少上缴中央税收。[3]。

5 中国崩溃论？
自20世纪90年代以来，国际上关于中国问题的较大争论有过四次。第一次是1994年，美国世界经济研究所布朗提出“谁来养活中国人”，引发了一场大争论；第二次是1992年以来，国际上泛起一股“中国威胁论”，已经直接影响西方大国的对华政策的重新制定；第三次是去年开始出现的“中国崩溃论”，无限放大中国目前经济社会中存在的一些问题，并得出草率的结论；第四次则是这次的“中国统计水分论”[9]。
这些争论，有的纯属学术范畴，有的则带有国际政治角力的背景，但无论从哪个角度、用哪种眼光来审视中国的发展，有一个基本事实不容忽视，这就是在近年来世界上发生的各种危机面前，在中国自身宏观经济运行面临诸多深层次困难的情况下，中国不但没有衰退和崩溃，反而保持连续多年的经济高速增长。即使GDP数据存在着一些问题，这也不能代表中国经济仅有数字上的辉煌，而实质上已经走到了崩溃的边缘。
GDP是考察经济的实际运行情况的一个重要的指标，但不是唯一的指标。任何一个国家的经济增长都是由多种因素决定的，没有一种单独的经济活动能够解释像现代经济这么复杂的情况，尤其像中国这样大规模的经济。下面将引述Klein和Lardy关于中国经济的评论[4]。
5.1 Lawrence R. Klein对中国经济的评论
为了从一个新的视角研究中国的GDP ，并利用独立的信息检验中国GDP 估计的一致性，论文收集了以下15 个变量：电力(千瓦时) ；煤炭(吨) ；原油(吨) ；钢产量(吨) ；货运(吨公里) ；民航运输(吨公里) ；第三产业就业比重( %) ；粮食产量(吨) ；出口(美元不变价) ；进口(美元不变价) ；政府支出(经过价格缩减) ；实际工资；长途电话(次数) ；通货膨胀率(消费价格指数) ；畜产品(吨) 。这些变量概括了能源、交通、通讯、劳动力、农业、公共部门、工资、通货膨胀情况。利用1980～2000 年年度数据，论文对这15 个指标进行了主成分估计[7]。
论文指出,概括地说,主成分反映了从不同资料来源相当独立地收集的15 个指标的变动，对中国经济来说有广泛代表性。这些指标的变动与中国官方估计的实际GDP 的变动是一致的。
5.2 Nicholas R.Lardy对中国经济的评论
Lardy列举了两个经济指标，一个是进口额，另一个是财政收入。中国官方数据表明，1997～2001 年，进口额增长了70 % ，财政收入增长了90 %。Lardy认为，进口额不可能被夸大，因为负责贸易统计的海关必须向财政部缴纳进口关税。财政收入也不可能被夸大，因为政府处于日益增加的社会资金需求的巨大压力之下，包括失业补贴、国企下岗工人退职金、缓解环境恶化和为军事现代化提供资金，等等。Lardy说，对所有国家来说，在经济增长率明显下降的情况下，由于企业利润减少，个人收入和消费停滞，税收的增长几乎不可避免地会更加放慢。中国经济增长在过去的四年里严重衰退与税收如此强劲增长是难以吻合的[8]。
虽然能源消耗降低、失业率上升等因素来说明中国经济并没有获得快速增长的观点一时还很难被完全驳倒。但事实证明了中国经济的确在强劲增长。同时也表明，单凭一两个指标来判断复杂的经济形势是没有任何科学依据的，也是和事实相违背的。

6 对Thomas Rawski观点的综合评述
综合以上的信息，我认为Thomas G. Rawski的质疑是有理由的，能源消耗和增长之间的不对应的原因缺乏进一步的分析；但他质疑中国统计数据造假的观点是站不住脚的；他得出的结论过于轻率，具体说体现在一些方面：
1. Rawski对于GDP数据的质疑是有的一定道理的
虽然说经济增长率与能源消耗、就业和消费价格数据之间存在着不一致性，且中国正在进行着较大的产业结构调整，但30%的差距依然很难被解释。一方面，能耗的统计存在着一些问题。由于非国有煤炭发展较快，因此20世纪90年代中期以后中国的能源统计一直存在一些问题[2]；另一方面，由于统计制度等多方面的原因，GDP数据的确可能存在着一些误差，而事实上，国家统计局也的确对某些年份的GDP进行了修正。
2. Rawski对于中国官方统计数据来源的质疑较为片面
对于数据来源的质疑，许宪春在《中外经济学家对中国经济增长率的评论》中指出：“中国自从1985 年开始计算国内生产总值时起，就采取国家统计局统一制定方法制度，地区与国家分级核算的方式，即国家统计局计算全国国内生产总值，省、自治区、直辖市统计局计算本地区国内生产总值。全国国内生产总值从来就不是省级国内生产总值数据的汇总。”“所以不存在国家统计局抛弃省级经济增长数据的问题”[4]
这说明了Thomas对数据来源的质疑是片面的，但从《许宪春详谈中国GDP统计数字来源》[10]我们可以看出，省级汇总的数据的确存在着一些问题，比如1995年第三次全国工业普查发现乡镇企业的工业总产值数据高报了40%[10]。
3. Thomas对于真实GDP的估计是没有依据的
Thomas认为四年累积经济增长率不会超过官方公布数据的1/ 3 ， 甚至可能更低。Rawski以国内航线的民航客运周转量的增长率为依据，确定中国1998 年经济增长率的上限为2 % ，但是，2000 年国内航线的民航客运周转量的增长率为13. 2 % ，他却认为中国2000 年的经济增长率在2 % ―3 %之间，从而上限仅为3 % ，这显然是自相矛盾的[4]。
中国GDP统计数据确实存在着许多问题，但在一些地区多报的同时，也有一些地区少报了产值，因而认为中国GDP增产率被整体严重高估是没有道理的。东部沿海的省分由于以民营经济为主, 可能会低报经济增长数据以减少上缴中央税收。同时，由于这些省分市场经济发展较快, 数据统计是比较完善和可信的[3]。

7 总结
本文首先简述了Thomas G. Rawski对中国GDP数据的质疑，之后描述了其它学者对其观点的反质疑；然后，结合《南方周末》对许宪春司长的访谈，揭示了我国在GDP核算上存在的种种问题；同时，本文结合了Klein和Lardy的观点，说明了GDP并不是衡量经济现状的唯一的指标，复杂的经济形势也不是光靠几个指数就能说明的；最后，我综合上述的观点给出对Thomas观点的评述。我们只有综合各方面的信息进行全面的考虑，才能做出准确的判断。

参考文献
[1] Thomas G. Rawski: 《What’s Happening to China’s GDP Statistics?》, China Economic Review 2001.12
[2] Jonathan E. Sinton, 《Aeeuraey and Reliability of China’s EnergyStatistie》, China EconomieReview, 2001, (12)
[3] 姜辉: 《崩溃与威胁—简析近年来国际上对中国经济的若干观点》, p49-p52, 2003
[4] 许宪春(国家统计局国民经济核算司司长): 《中外经济学家对中国经济增长率的评论》,《财贸经济》, 2002 年第二期
[5] 任若恩, 《中国GDP 统计水分有多大――评两个估计中国GDP 数据研究的若干方法问题》, 《经济学季刊》, 2002 年第2 卷第1期
[6] 张新蒋殿春, 《中国经济的增长――数据的可信度以及增长的微观基础》, 《经济学季刊》, Vol 2, No. 1, Oct., 2002
[7] Klein L. R. and Ozmucur S. 《The estimation of China’s economic growth rate》, 2002
[8] Lardy , N. R. , 《China will keep on growing》, 《Asian Wall Street Journal》, June 14. 2002
[9] 《中国GDP增长统计存在水分》, home.xjtu.edu.cn/teacher/yandw/macro/reference/65.doc Mar 6. 2003
[10] 《许宪春详谈中国GDP统计数字来源》, 《南方周末》, 2002.08.01

Note of SAS coding style

Guidelines for Coding of SAS® Programs
--by Thomas J. Winn Jr., Texas State Auditor’s Office, Austin, TX

SAS language is like a script but with more flexiblility and less limitation. Sometimes it is useful but as a programmer, I always confused by program writen by SAS, though sometimes the problem is not complex.

Luckily, I found a paper by Thomas, provide some idea which is practical and beautiful, Though most of them is just a basic law in normal programming. And Law is Freedom.

And the following material is just copy from the paper.

“This paper presents a set of guidelines that could be used for writing SAS code that is clear, efficient, and easy to maintain.”
you can write SAS code in a particular way does not mean that you should do so.

Name
• In naming, avoid cuteness, single-letter names, and names that too closely resemble one another.
• Names should be unique, short, and descriptive – in that order of importance.
• If longer names are needed, underscores may be used to separate words, in order to enhance readability.
• If a user-defined format applies to only one variable, then name the format with a readily-recognizable form of the variable-name plus the suffix FMT .

READABILITY & APPEARANCE
♦ Insert a blank line between SAS program steps; that is, before each DATA or PROC step.
♦ Be consistent with your indentation increments.
♦ Indent all statements in a logical grouping by the same amount.
♦ Left-justify all OPTIONS, DATA, PROC, and RUN statements. Indent all of the statements within a DATA or PROC step.
♦ Indent conditional blocks and DO groups, and do it consistently, The logic will be easier to follow.
♦ Align each END statement with its corresponding DO statement. This will make it easier to verify that they match.
♦ Remember to preface major blocks of code with explanatory comments.
♦ Consider inserting PAGE statements to force the SAS Log to begin tracing the execution of new modules on a new page.

REUSABILITY
Since most of the operations of the SAS macro facility are carried out in the background, sometimes debugging them can be fairly mysterious.
• Write code that can be re-used, with different parameters. Keyword parameters are preferable to positional parameters, because they are less likely to be specified incorrectly.
• Write the code you use repeatedly as a macro, and then, instead of repeating your code, invoke the macro.
• Avoid using global macro variables.
• If a macro is used by more than one program, put it into an AUTOCALL macro library.

EFFICIENCY
Avoid jumping to statement labels by GO TO, or LINK statements and RETURN statements,
♦ If possible, replace logic which jumps between subroutines with DO ...END and IF ... THEN ... ELSE ...-logic,
♦ End every DATA and PROC (except PROC SQL) step with a RUN statement,
♦ End every PROC SQL step with a QUIT statement.

Place most of the non-executable statements in a DATA step before all of the executable statements.
In particular, place variable attribute and other declarative statements near to the top of the DATA step, and ahead of the executable statements.

• In a DATA step, place most of the non-executable statements before the executable statements – exceptions include the DROP or KEEP statements, which may be placed after the executable statements.
• Define INPUT and PUT variables one per line, using @ pointer control.
• Screen data for unusual circumstances.

reduce the number of times the data are read:
♦ Minimize the number of passes through the data,
♦ Minimize the number of DATA steps,
♦ Read and store only the data that are needed,
♦ Sort the data only when it is absolutely necessary.

When you read in an external file, use pointer controls, informats, or column specifications in the INPUT statement, to read only those fields you actually need.
• Store only the variables you need by using DROP or KEEP statements, DROP= or KEEP= options (eliminate variables from the output data set which are needed only during DATA step execution, and not afterward).
• When only one condition can be true for a given observation, use IF ... THEN ...ELSE ... statements (or a SELECT group), instead of a series of IF ... THEN ... statements without ELSE statements (In a sequence of IF-THEN statements without the ELSE, the SAS System will check each condition for every observation).
• When using a series of IF ... THEN ... ELSE ... statements, list the conditions in descending order of probability. This will save CPU time.,
• Use the LENGTH statement to reduce the storage space for variables in SAS data sets.
• Minimize workspace usage by using the DELETE statement in a PROC DATASETS step, to eliminate temporary data sets that are no longer needed by the program.
• Use the IN operator instead of a series of multiple logical OR operators.

Code Complete PART 3

Variables
chapter 10. General issues in using variables
1. Data Literacy
2. Making variable declarations easy
3. Guidelines for initializing variables
在声明变量时初始化
靠近变量第一次使用时初始化
理想情况下，靠近第一次使用的位置声明和初始化
final & const
counter & accumulator  --- i, j, k, sum, total
在constructor中初始化类的数据成员
检查是否需要重新初始化
一次性初始化具名常m量--使用可执行代码
使用编译器设置
利用编译器警告
检查输入参数合法性
初始化工作内存。 0xCC & 0xDFADBEEF
4. Scope
visibility -- 可见性 作用域
Localize references to variables
span -- 跨度
生存时间
General guidelines for minimizing scope
在循环开始之前再初始化循环中使用的变量
直到变量使用时才为其赋值
把相关语句放到一起
提取子程序
开始时采用最严格的可见性，之后再扩充
Comments on minimizing scope
intellectual manageablility -- 智力可管理性
5. Persistence
数据的生命期
6. Binding time
绑定时间：
编码时 -- 神秘数值
编译时 -- 具名常量
加载时 -- 外部数据源读取
对象实例化时
即时
绑定时间越早灵活性越差，但复杂度越低。
7. Relationship between data types and control structures
Jackson.
Sequential data
selective data
interative data
8. Using each variable for exactly one purpose
每个变量仅有单一用途
避免让变量有隐含意义
确保使用了所有已申明的变量

Chapter 11. The power of variable names
1. Considerations of choosing good names
完全 && 准确
problem orientation
what, not how
length: 10 - 16
限定词放在变量名的最后：
Total, sum, average, max, min, record, string, pointer...
NumXXX: a total number
XXXNum: 下标
begin/end
first/last
locked/unlocked
min/max
next/previous
old/new
opened/closed
visible/invisible
source/target
source/destination
up/down
2. Naming specific types of data
Naming loop indexes
i, j, k
XXXindex, XXXCount
to avoid index cross-talk
Naming status variables
'flag' is not good
Naming temporary variables
警惕临时变量，弄清其实际用途
Naming boolean variables
典型的boolean名：
done, error, found, success or OK.
Naming enumerated types
使用前缀
3. The power of naming conventions
why:
when:
degrees of formality:
4. Informal naming comventions
Guidelines for a language-independent conventions
区分变量名和子程序名
区分类和对象
标识全局变量
标识成员函数
标识类型申明
标识具名常量
枚举类型的元素
格式化命名
Guidelines for language-specific conventions
5. Standardized perfixes
User-defined type abbreviations
UDT: user defined type
ch, doc, pa, scr, sel, wn
Semantic perfixs
c: count
first & last
g: global var
i: index
lim: limitation -- first <> last <> lim : llim = last + 1
m: class var
max && min
p: pointer

Chapter 12: Fundamental data types
1. Numbers in genaral
avoid Magic number.
avoid mixed compare
be careful of warning
2. Integers
检查整数除法。地板除，真实除
检查整数溢出
检查中间结果溢出
3. Floating-point Numbers
避免数量级相差巨大的数之间的加减
避免等量判断
处理舍入误差问题 --使用更高的精度，使用BCD
4. Characters and strings
避免使用神秘字符及神秘字符串
Unicode
在程序生命期中尽早决定国际化/本地化策略
ISO 8859 or Unicode
采用某种一致的字符串转换策略
5. Boolean variables
用布尔变量来简化复杂的判断
需要的话创建自己的布尔类型
---typedef int BOOLEAN;
6. Enumerated Types
提高可读性，可靠性，可修改性。作为布尔变量的修改方案。
7. Named constants
single-point control
在数据申明中使用具名常量
避免使用文字量
用具有适当作用域的变量或类来模拟具名常量
统一地使用
8. Arrays
考虑用容器来代替数组，或将数组当作顺序化的容器来处理
检查数组的边界点
提防下标串话
9. Creating your own types

千与千寻

这个周末窝宿舍看了6部电影：辛德勒的名单，战争之王，千与千寻，马克思佩恩，我是传奇和风云诀。辛德勒的名单和千与千寻原先就看过，不过都是很多年前了；战争之王也是部优秀的电影；其它三部就很soso了。很久很久没这么看电影了，有时是因为没时间，有时是因为没心境。

一些优秀的东西不管在哪个时代，那个年龄段的人看来都是优秀的。人性、关爱和对心灵的探求让人在并不温暖的初冬感到丝丝暖意。

人在成长的过程中必然会丢失一些东西，有些时候甚至很难说这种成长值不值得，长大了，就很难再听见心灵里的某种声音了，那是种至真至诚的感动，明静而通澈。

不得已，人长大了总要负担些什么了，可以说是上进，可以说是责任感，也可以说是欲望。又有什么差别呢。不过有时候是要静下来听听自己心灵的声音，不要被自己彻底地蒙蔽。就像乔布斯说的，把每天当成最后一天来过，这样，自然会听从心底最本真的声音。

上外的猫

阴错阳差到了上外，一个比上财还小的学校。不过有趣的是发现了黑猫白猫和它们的仔儿。女生多的学校就是猫多，而且都有两个特点——肥，胆大。

人走过去，它不动；有吃的，立马哈过来；没吃的，扭过头不看你；你吓它吧，有时象征性地跑两步，有时干脆就不跑。简单的说，就是嚣张、厚颜无耻，彻底丧失了作为一只猫的优良传统。
#ReadMore#
 

The Zen of python

PEP is short for Python Enhancement Proposals, and PEP0 is the index of these files.
http://www.python.org/dev/peps/pep-0000/

The Zen of python -- May be simple, but practical. It is in PEP20.

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

And I think Simple is beautiful.

I like python, for its liquid, simple and prowerful.

Debian note, installation

Today, I installed debian in my virtual machine. To learn more about development in Linux environment. And from now on, I will try my best to write blog in English, it is a good practice for my write skill. :)

First, download a ISO file form http://www.debian.com/;
the path of the ISO file is http://cdimage.debian.org/debian-cd/4.0_r5/i386/iso-cd/debian-40r4a-etchnhalf-i386-netinst.iso, It is a image for net installation.

Finished installation, edit /etc/apt/sources.list, add an update source in the following form:
deb http://host/debian distribution section1 section2 section3 deb-src http://host/debian distribution section1 section2 section3
for example:
deb http://http.us.debian.org/debian stable main contrib non-free

I select a mirror in Taiwan to do the installation. Use the command like: apt-get install package.

Install R language. It is a free statistical programming language.
apt-get install r-base

Install mySQL:
#apt-get install mysql-server mysql-client libmysqlclient15-dev

And Vim should also be reinstalled to get full version.

一年中最好的时节

冬至，凉爽而清澈的天气，阳光艳丽慵懒。一年中最好的时节。
从一点睡到八点，阳光正照到我的床上，醒来，穿衣，刷牙。咖啡加蜂蜜面包，懒洋洋地开机，下载。
编程。所有东西都有它内在的优美，特别是当它无序的时候。从无序到有序，从混杂到简洁。然后Simple && beautiful。
自然，自在，自由。一些东西就由着它生长吧。

数据挖掘——技术 or 艺术？

今天在MYDB2.CN上发现了IBM讲师张英做的slide，《数据挖掘——技术 or 艺术？》。觉得最好的隐喻相当地恰当，copy如下：

1 取景（寻找业务问题－寻找业务增长空间）
2 构建画面的背景（定义业务问题）
4 根据天气和光线的情况调整曝光程度等（调整建模方法和参数）
5 冲洗选择一张最佳的照片（选择一个最佳的模型）
6 后期美化处理（业务含义解释和建议）
7 装裱起来，挂在该挂的位置例如床边，书桌或者客厅什么的（模型部署，用于改善实际的业务）

会找：发现问题，以及解决问题的数据挖掘方法
会用：处理数据，操作软件
会说：对挖掘结果给出解释分析
会试：需要不断的调优，改进挖掘效果

希望能成为一个信息管理和商务智能方面的专家，愿意为之付出持续而谦卑地努力，因为professional && free往往是相互依存的。

Rubik's Cube

Rubik's Cube也就是魔方，昨天晚上在地摊上买了一个，魔方不是一个好的玩具，特别是对于我这样的笨小孩来说，很能打击自尊心。现在长这么大了再次上手魔方，看看是不是长大聪明了还是继续印证“痴长白大”这句家乡的古话。

在地铁上玩了一把小时，还是没个头绪，我也意识到了中心块、棱块和角块的特殊，可还是没发现什么。我知道我笨，只是一次又一次地验证这个事实还是蛮让人沮丧的。

今天google了一下，发现了下面的入门教程http://www.rubik.com.cn/beginner.htm，另外百度百科上也有魔方的详细介绍：http://baike.baidu.com/view/35837.html?wtp=tt。真不知道，原来魔方还有这么多的故事。解魔方也有系统的方法，就是一些特定的步骤和所谓的魔方算法，一路看下来，即使是最简单的7步法也有一些东西要记，虽然跟着教程很快就完成了魔方的复原，可要我自己重新操作也是搞不来的。人老了的最大的缺点就是懒的思考。

rubik.com.cn的站长还分享苹果CEO Steve Jobs在斯坦福的演讲：“听从自己心灵的指示；把每天当做最后一天”。这样的人无疑是快乐的，而且是强大的。

RA3

终于出了RA3了，从RA2到现在，十多年了吧，可惜的是红警依旧，西屋不再，让人不得不感叹沧海桑田，世事难料。。^_^红警是个蛮好的发泄游戏，没什么技巧，不用动脑，只要疯狂造兵，一下扔过去就是了。
RA3里面原来的特色兵种大都还在，只是好像少了火箭飞行兵和尤里。不过多出来个日本，邪门得很。上午下有些，然后玩了下战略，下午拿美俄日一个个和日本打了下，玩得腻了，删！
红警兵种都加了技能，这么着有点不像红警了，模仿的结局就是沦落。

10.30

开学一个半月，看着时间花花地流过，而且越流越快，可面前还有很多问题没有解决，也许到了重新评估一下的时候了。

主要的问题还是课业太重，自己的基础比较差，而且又花了很多时间在非课程的东西上，导致一时跟不上进度。想想课前预习课后复习才是效率最高的办法，以后多多注意。光统计就已经是科目繁杂，再加上对应的经济金融知识，以及数据管理、分析工具的掌握，这些对我这一年多学习时间来说，根本没有完成的希望。

还是思想和工具的问题，没有思想，再多的工具也没有用；可决定思想的往往就是工具。就像思想和语言的关系，思想往往被语言所限制，如果一个思想不能表达，它就不能称之为一个思想。现在我也是面临着这样的困境，金融经济分析是商务决策的工具；数据挖掘是经济分析的工具；而SAS等基础软件则是统计的工具。但现在，这些不同层面上的思想和工具在我面前都是脱节的，这是我现在面临的最大的困惑。记得在GSMC实习的时候，Lin曾经和我说，要做数据挖掘至少要5年的从业经验，现在看来，五年的学习曲线并不是很夸张，如果把业务方面的东西也加上去的话。

专注与学业及SAS和IBM的相应解决方案。如果可以的话，再加强些英语吧～～

Code Complete PART2

PART2: 创建高质量的代码
chapter 5: Design in Construction 软件构建中的设计
1. Design Challenges
Design --> wicked: 只有通过解决或部分解决才能明确的问题 现实<-->理论
Sloppy process --> tide result
方法论；优劣的差异；good enough?
Tradeoffs & priorities
Restrictions
Nondeterministic
Heuristic process
Emergent 自然而然
2. Key Design Concepts
Primary Technical Imperative: Managing Complexity
Accidental and Essential difficulties
失控的复杂度 --> 失败 --尽量减少在任一时间需要考虑的程序量
Desirable characteristics of a design
Minimal complexity --避免“聪明”
Ease of maintenance --self-explanatory
loose coupling
extensibility
reusablity
high fan-in --good use of utility classes
low fan-out --7
portability
leanness --完成->不能删除任何东西：伏尔泰
stratification
standard techniques
Level of design
System --> subsystem 子系统：业务规则、GUI、DB、对象依赖性
--> classed --> routines --> internal routine
3. Design Buildng Blocks: Heuristics
find real-world objects
辨识对象及属性 --> 确定自身操作 --> 对其他对象的操作 --> 可见性 --> 公开接口
Form consistent abstractions
抽象是一种让你关注某一概念的时候可以同时放心地忽视其中一些细节的能力--在不同的层次处理不同的细节。
Encapsulate Implementation details
房屋建造
Inherit -- when inheritance simplifies the design
Hide secrets (Information Hiding)
封装，模块化 冰山
隐藏复杂度、隐藏变化源
障碍：信息分散 循环依赖 类内数据->全局数据 性能损耗
价值：修改 设计
Identify areas likely to change
寻找 分离 预防
易变化的区域：业务规则 输入输出 非标准语言特性 困难的设计和构建 状态变量
anticipating different degrees of change
让变化的影响范围和发生变化的可能性成反比
有用的最小子集 --> 扩充
keep coupling loose
criteria: 规模（连接数） 可见性 灵活性
kinds of coupling:
simple data parameter coupling
simple object coupling
object-parameter coupling
syntictic coupling: 控制标志 假设。。。
Look for common design patterns
现成抽象 --> 减少复杂度
细节制度化 --> 减少出错
多种方案 --> 启发
高层次 --> 简化交流
4. Design Practices
Iterate Divide and conquer Top-down and botton-up design approaches
top-down: 易上手，但易受底层复杂度影响
botton-up: 复杂，但可早期鉴别出系统的复杂度，设计出更好的高层类
experimental prototyping collaborative design How much design is enough
最大的设计失误在于自我认为做的很充分，事后却发现做得不够。
最大的悲哀莫过于大厦快要完工时地基出了问题。 ——罗素
Capturing your work
doc in source, wiki, mail, DC, picture, CRC(类、职责、合作者), UML
5. Comments on popular methodologies
Big design up front --> little design up front or enough design up front
Design in General
Couceptul Blockbusting: A Guide to Better Ideas
How to Solve it: A New Aspect of Mathematical Method
How to Solve it: Modern Heuristics

chapter 6: Working Classes 可以工作的类
1. Class Foundations: Abstract Data Types(ADTs)
Benefits: 隐藏实现细节 支持改动 接口提供更多信息 易提高性能 正确性验证 自说明性 数据传递 实体操作
ADT + 继承、多态 --> 类
2. Good Class Interfaces
Good Abstraction
抽象是一种以简化的形式看待复杂操作的能力 混杂-->一致
类接口应展现一致的抽象层次
理解类所实现的抽象 精确！
提供成对的服务
转移不相关信息 --> 模块内聚
让接口可编程，而不是表达定义
谨防破坏接口的抽象
抽象性 and 内聚性
Good Encapsulation
限制类和成员的可访问性（accessibility）
不公开暴露成员数据
避免把私有的实现细节放入类的接口
不要对类的使用者做出任何假设
避免使用友元类（friend class）
让阅读代码比编写代码更方便
警惕在语义上破坏封装性：针对接口编程 --> 透过接口针对内部实现编程×
3. Design and Implementation Issues
Containment("has a" relationships)
使用包含 万不得已使用private继承 警惕超过七个数据成员的类
Inheritance("is a" relationships)
更精简的代码
成员函数：对派生类可见？有默认实现？能被覆盖？
数据成员：对派生类可见？
要么对继承做详细的说明，要么不使用继承
Liskov替换原则：派生类必须能通过基类的接口被使用，且使用者无需了解两者之间的差异
确保只继承需要继承的部分
注意：继承接口 --> 继承实现 继承实现 --> 继承接口
只想要实现 继承？包含！
不要“覆盖”（语法角度）一个不可覆盖（语义角度）的成员函数！
把共用的接口反正继承树尽可能高的地方
只有一个实例：新的对象？新的类？
只有一个派生类：提前设计？
覆盖但没做任何操作：怀疑！
类型检查？多态！
让所有数据都是private
对继承持有歧视的态度！
Member functions and data
子程序的数量 类调用子程序的数量 对其它类的子程序的间接调用： 尽可能少！
尽量减少类与类间相互合作的范围。
Constructors
尽可能在构造函数中初始化所以数据成员
private constructors --> singleton property
deep copies >> shallow copies
4. Reasons to Create a Class
建模 降低复杂度 隔离复杂度 隐藏实现细节 限制变动的影响范围 隐藏全局数据 让参数传递更通畅 建立中心控制点 易于重用 为程序族做计划 包装相关操作 实现特定重构
Classes to avoid
god class; 无关紧要的类; 用动词命名的类

chapter 7: High-quality Routines 高质量的子程序
small intimate viaible flexible
1. Valid reasons to create a routines
降低复杂度 引入中间、易懂的抽象 避免代码重复 支持子类化 隐藏顺序 隐藏指针操作 提高可移植性 简化逻辑判断 改善性能
创建类的理由也是创建子程序的理由。
2. Design at the Routine Level
functional cohesion: 只执行一项操作
sequential cohesion: 步骤 共享数据 完成完整功能
communicational cohesion: 同样的数据，无其它联系
temporal cohesion: 需要同时执行
procedural cohesion: 子程序的操作按特定顺序
logical cohesion: 控制或“逻辑”是子程序组织的原因
coincidental cohesion
3. Good Routine Names
描述子程序所做的所有事情
避免使用无意义、含糊、表意不明的动词
不使用数字形成不同的子程序名
函数命名时对返回值有所描述
过程命名时使用语气强烈的动宾形式
准确使用对账词
为常用操作确定命名规则
4. How long can a routine be
适中最好 一屏 打印1到2页
5. How to use routine parameters
按输入-修改-输出组织
一致的排列顺序
使用所有的参数
状态或出错变量放最后
不要把子程序的参数用于工作变量
在接口中对参数的假设做出说明：I or M or O? unit? scope?
个数限制在大约7个以内
IN Modify OUT的命名规则
子程序的接口要达到何种抽象？
6. Special considerations in the use of functions
函数 vs 过程
如果一个子程序的用途是返回由其名字所指明的返回值，那么就应该使用函数，否则使用过程
检查所有可能的返回路径
不要返回指向局部数据的指针
7. Macro routines and Inline routines
把宏表达式整个包含在括号内
把含有多条语句的宏用{}包围
节制使用inline: 暴露细节

chapter 8: Defensive Programming 防御式编程
1. Protecting your program from invalid inputs
garbage in, garbage out
in: 检查源于外部的数据 检查数据输入 决定如何处理错误的输入数据
2. Assertions
开发时使用的让程序在运行时进行自检的代码
assert a != 0 : "a is unexpectedly equal to 0"
IN and OUT, state, value of variable, pointer check, container
Guidelines for using assertions
错误处理代码：预期会发生 断言：绝对不应该发生
避免把需要执行的代码放在断言中
用断言来验证前条件（运行前确保为真）和后条件（运行后确保为真）
先使用断言后使用错误处理代码
3. Error-Handling Techniques
返回中立值 下一个正确的数据 与前次相同的数据 最接近的合法值 log error-code
Robustness vs. correctness
correctness: 永远不返回不准确的结果
robustness: 尝试采用。。继续运转
4. Exceptions
通知机制
只有在真正例外的情况下才抛出异常：由于调用子程序的代码需要了解被调用代码可能发生的异常，因而弱化的封装
不能用异常来推卸责任
避免在构造和析构函数中使用异常，除非在同一地方捕获
在恰当的层次抛出异常：抛出的异常也是程序接口的一部分
在异常消息中加入导致异常发生的全部信息
避免使用空的catch语句
集中的异常报告机制 异常使用标准化 考虑异常的替代方案
5. Barricade your program to cotain the damage coused by errors
让软件的一部分处理“不干净”的数据，另一部分处理“干净”的数据，大部分代码就无需承担错误检查的任务
outside error-handling | assertions inside
6. Debugging Aids
Use offensive programming
对待异常：开发时--显现，运行时--自我修复

chapter 9: the Pseudocode Programming Process (PPP) 伪代码编写过程
1. Summary of steps in building classes and routines
steps in creating a class
类的总体设计 类中的子程序 复审并测试整个类
steps in building a routine
设计 检查 编写 检查
2. Pseduocode for Pros
类似英语，精确描述
避免使用目标语言的语法元素
在意图的层次编写伪代码
在足够低的层次上写伪码
3. Constructing routines by Using the PPP
Design the Routine
检查先决条件
定义问题：要隐藏的信息，输入输出，前条件后条件
子程序命名
决定如何测试
在标准库中寻找可用的功能
考虑错误处理
考虑效率问题
研究算法和数据结构
编写伪代码：头部注释+目的
考虑数据
检查伪码
Code the routine
写出子程序的声明
将伪码转为高层次的注释
在注释下填充代码
检查代码：重构？递归应用routine编写方法
收尾
check the code
脑海中检查：
桌面检查（desk checking）
同行评审（peer review）
走查（walk-through）
详查（inspection）
编译子程序
hacking and compiling 拼凑加检查×
将编译器的警告级别调到最高
使用验证工具(validators)，C: lint
消除错误消息和警告的所有根源
在调试器中逐行执行代码 测试代码: 测试用例 消除程序中的错误
clean up leftovers
检查接口 检查整体设计质量 检查变量 检查语句和逻辑 检查布局文档及注释
4. Alternatives to the PPP
Test-first development
refactoring
design by contract
hacking×

卑微地努力

人类的行为取决与自身的知识，因为你无法知道自己将来知道什么，所以无法知道自己将来会做什么。

人类所做的新的发现不过是自己刚刚塞进去的东西而已。

今天上金融博弈的时候老师又开始讲起了哲学，我蛮喜欢那个不修边幅的老头的，“老年版的哈利波特”，宁同学是这么称呼的。数学、哲学、宗教，其实都是人类思维构造的体系，本质上有着想通之处，其实软件有何尝不是如此，“纯脑力的构建活动”—— Code Complete中是这么说的。简洁和优美，可能是所有科学都追求的一样东西。不过在实践的角度看，quick & clear往往是要着很深功力的，刚开始的时候也许quick & dirty比clean & slow要更好些，在尝试的过程中再慢慢向着quick & clean进步。

下午上财务报表的时候上课的老师也给了我很多感触，他原来师范毕业后在大学教书，过了几年考了硕士，出来在银行做了几年，又去读了博，现在在上财教书。从他的经历看来并算不上一个牛人，但他走的路可以说是一个普通人的成功之路。比如天天记日记，年年做总结，整理简历……心怀希望，能够坚持的人相信都是能成功的。

上海博物院

第一次去上海博物院是初中，之后是高中毕业那会，接着就再没去过了。今天正好去火车站配眼镜，在等磨镜片的那会功夫就顺便去博物院转了圈。

据说全国能称上博物院的只有三家：故宫博物院，上海博物院和南京博物院。“馆”和“院”虽然只是一字之差，可也体现了些身价的不同吧。上博院的藏品还是蛮丰富的，只是展厅里展出的只是其中的一部分，而且有些展厅也是时开时关，所以要看一些一些精品还是要有一定缘分的。但据说现在书画馆的画都已不是真迹的了，而是现代科技的复制品。##ReadMore##



这次在书画馆多呆了一些时间，有好些书画是很有名的，以前只是在画册中见过，现在一睹真容还是很有些感动的。只是也有些遗憾，看到宋元明清画作之精美高雅逸趣。想到现在社会上所谓名家的一些画，一些字，真不知该说是创新还是倒退。在陶瓷馆也呆了很久，康乾盛世的一些作品做工之精美真可以说是绝伦，经历了数百年的岁月依然灿然如新。

本来还拍了一些照，只是发现J10不愧是很低端很傻瓜的相机，变形严重而且高ISO下噪点严重。不过用picasa调下暗部加简单的模糊后效果还可以接受。

武东校区

上财的所谓武东路校区原来是，现在还是同济的校园。住着不多的学生，有一些陈旧荒芜的气息。
##ReadMore##

敬畏耶和华是智慧的开端

一天无事。
上午看Code Complete，有感时间的匮乏，用Google Calender排了下这学期的日程。现在又是一个人了，该慢慢习惯泡图书馆的日子吧，可能这就是我的Style，刻意追求着简单，简单得什么都不要。
研究生就这两年，在明年找工那会仅仅一年时间，要是从明年五月报暑期实习的时间来算，时间更少。Less is more。尽量集中精力吧。
下午上财务报表分析，书上看到了财务预警分析的简介。多元逻辑分析、神经网络和概率预测在财务预警分析上都有可用的模型，但却都存在着这样那样的问题。我进一步坚信统计、计算机相结合在商务智能上必将有开阔的应用前景。
晚上上的是金融博弈，也是选修的第一节，老师一看就是理科出身。学工学理学文对一个人的气质真的影响很大，如果潜心学过的话。
课程的引言就是“敬畏耶和华是智慧的开端”。
我并不是宗教的信徒，但也不是无神论者。冥冥之中自有定数。我一直相信，如果有上帝的话，他创造的该不是物的世界，而是公理和规律；而且，他可能是程序员。
前几天在Code Complete上看到了下面的一些话，发觉虽在不同的领域，真正优秀的思想其实是相通的：
你思考的能力取决于你是否知道能够表达该思想的能力
《The Humble Programmer》：大部分编程工作都是在弥补我们有限的智力。承认自己智力有限并通过学习来弥补。
谦卑的人那，努力吧。

Learning python 读书笔记 PART 6

PART 6: Classes and OOP
Chapter 19. OOP: The Big Picture
classes: instance factories, data + function
Instances: represent the concrete items in a program's domain
attributes searching at runtime, lower level to higher level
Coding Class Trees
Class C1(C2, C3): multiple inheritance
Attributes --> class  :  assignments made within class statements
Attributes --> instances  :  assignments to self inside class statements
>>> class C1:
    def setname(self, who):
        self.name = who       
>>> I1 = C1()
>>> I1.setname('xyz')
>>> print I1.name
xyz
initialization: def __init()

Chapter 20. Class Coding Basic
Class: namespace, generating multiple objects, namespace inheritance, operator overloading
Module: namespace
Classes VS. Instances
Class objects probide default behavior:
attributes functions --> class <-- a class name
Instance Objects are concrete items:
call a class object like a function makes a new instance object
each instance object inherits class attributes and gets its own namespace
a new attribute can be generated on the instance
Classes are customized by Inheritance
classes and modules:
from module1 import Class1
class Class2(Class1): ...
Classes can intercept Python Operators
def __init__(self, value): ...
def __add__(self, other):
    return ...
def __mul__(self. other):
    self.data = ...

Chapter 21. Class Coding Details
The Class Statement
class <name>(superclass,...):
    data = value
    def method(self, ...):
        ....
Methods
instance.method(args...) == class.method(instance, args ...)
Calling superclass constructors:
class Sub(Super):
    def __init__(self, x):
        Super.__init__(self, x)
        ......
Inheritance
Abstract superclasses:
class Super:
    def method(self): ...
    def delegate(self):
        self.action()
    def action(self):
        assert 0, 'action must be defined!'
Operator Overloading
__init__: Constructor
__del__: destructor
__add__, __radd__, __iadd__: +, right-side + , +=
__or__:  |
__repr__,__str__ : printing
__call__ : X()
__getattr__ : X.a
__setattr__ : X.a = value
__getitem__ : X[key], for loops, in tests
__setitem__ : X[key] = vlaue
__len__
__cmp__, __lt__, __eq__
__iter__
user-defined iterators
def __init__(self, start, stop):
def __iter__(self)
    return self
def next(self)
    ....
__getattr__ and __setattr__ catch attribute references
__getattr__: is not called if Python can find the attribute, used to deal with undefined attributes
__setattr__: if defined, self.attr = value --> self.__setattr__('attr', value)
    self.__dict__['name'] = x
__repr__ VS. __str__
>>>x  :  run __repr__
>>>print x  :  run __str__
add:
>>>x + 1 #__add__
>>>1 + y #__radd__
__call__:  x(attr)
__del__: run automatically when an instance's space is being reclaimed
Namespaces: The Whole Story
instance -- __class__ --> class
class -- __base__ --> higher superclasses

Chapter 22. Designing with Classed
Python and OOP
inheritance polymorphism encapsulation
Overloading by Call Signatures
*class C:
     def meth(self, x): ...    #a
     def meth(self, x, y):...  #b
 a will overwrited
*class C:
     def meth(self, *args):
          if len(args) == 1: ...
*class C:
     def meth(self, x):
          x.operation()
Classed as Records
OOP and Inheritance: "is-a" relationship
OOP and Composition: "has-a" relationship
OOP and Delegation
Multiple Inheritance
search process depth-first all the way to the top
Classes are objects: Generic Object Factories
apply function:
def factory(aClass, *args)
    return apply(aClass, args)
Methods are objects: Bound or Unbound
Unbound: class, no self
object1 = Spam()
t = Spam.doit
t(object1, 'lalal')
bound: instance, self + function pairs
object1 = Spam()
x = object1.doit
x('lalal')
Documentation String Revisited
import docstr
a.__doc__, a.b.__doc__
Class Versus Modules
they are both namespacefiles
Modules:
Are data/logic packages
Are created by writing Python or C extensions
Are used by imported
Classes:
Implement new objects
Are created by class statements
Are used by being called
Always live within a module

烤

从9月16号开学，到现在已经差不多一个月了，终于逮着机会，浩浩荡荡50人聚一起吃烧烤啦～～
记下帐先：
费用：
烤炉：40元/次 小凳子：2元/把 铁网：5元/块 夹子：5元一把 木材：5元/打  门票：15元×八折  结论：黑，相当地黑。
原料：（摘自。。。。忘了。。）
餐具及辅助用品：一次性桌布（厚）、一次性筷子和碟子、纸杯、餐巾纸、竹签、毛刷、废报纸h、小刀及叉子
烧烤主食类：鸡翅 骨肉相连 肉串 馒头 蘑菇 年糕 玉米肠 贡丸 土豆 菜椒
其他：蜂蜜、香辣粉、辣椒面、番茄酱、盐
饮料：可乐、果汁、纯水
食物是昨天晚上去十人去沃尔玛买的，花了一千多，然后再加门票五百多，再加上烧烤用具的租金，七七八八倒也勉强够用。
然后。。。很郁闷，在搬木头的时候我踩到了钉子，而且扎得很深，回来的时候又在公园迷了路。折腾着五点总算到了学校，医务室又没破伤风针打，537路坐到了长海医院，大个破伤风针三块五，七七八八硬是整到了70多，然后又打车回了学校，霉。
http://picasaweb.google.com/shufe08/081012#

J10

今天在京东的库存品展销会上买了富士的J10，入门得不能再入门的相机，早日换单反，努力！！！##ReadMore##