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和高统，这半个月就彻彻底底地交给你们啦。爬山虎，看着还像是秋天，其实已是冬日。这植物，和我一般迟钝那。
已是十二月初，回顾这大半个学期，一直忙忙碌碌，可却第一次觉得有些迷惘，选择考研、特别是考统计也许真是一个失误；但这些都是无法改变的事实，我所能做的是尽所有的可能，将错误的成本降到最低。