作为一名程序猿，懂得翻墙是十分必要的。由于种种原因，天朝通往世界的网络上，被人为的设置了一道「长城」。然而，「长城」之外的我们向往的先进的技术和知识，也被无辜的给拒之墙外了，所以，我们都在努力的「翻墙」，不为别的，只为能够获得最为直接的技术和知识。

自从开学以来，玩OpenStack也已经3个月了，这段时间主要把精力投在了OpenStack的安装部署和网络组件Neutron的研究上了。这期间零零散散在安装部署和Neutron运作原理上来回切换，有点在实践中学习的味道，虽然在安装部署的过程遇到了不少的问题，也一一都给解决了。然而，总是觉得对于Neutron的机制理解的还是不够透彻。前一阵子刚刚部署好一套Havana版本的系统，并开始投入使用。这阵子又开始投入OpenStack的IPv6的试验中，因为需要对底层的路由机制进行彻底的了解，所以不得不又开始重新捋了一遍这方面的知识，在网上Google了一把资料，这次算是彻底的把Neutron的运作机制彻底的理清楚了，之前那些半懂不懂的东西，现在也是觉得豁然开朗了。

JUnit是由Erich Gamma和Kent Beck编写的一个开源的单元测试框架。它属于白盒测试，只要将待测类继承TestCase类，就可以利用JUnit的一系列机制进行便捷的自动测试了。

日志系统简介

应用程序中使用日志功能能够方便的调试和跟踪应用程序任意时刻的行为和状态。在大规模的应用开发中尤其重要，毫不夸张的说，日志系统是不可或缺的重要组成部分。由于开源的广泛性，我们不需要再去重复造轮子，我们可以直接使用众多的开源日志系统来满足我们的开发需求。

最近乘着开学的时候还没有什么事情，于是乎，开始学起了Python。Python作为脚本语言，最近一段时间真的是越来越火了，所以也有必要认真的学习一下的。毕竟多学一门语言也不是坏事，而且看上去，Python的学习门槛不是太高，只是在一些库上的学习和应用值得花些时间好好钻研一下。

最近也算是把Git相关的知识看了不少了，虽然对于Git的有些命令还是没怎么熟记，对一些更加高级的命令也是没有实践过，但慢慢理解了Git的相关的flow之后，不自然就和以前用过的SVN进行了一些对比，发现Git相对于SVN来说的确有些优势。

在之前的公司里，项目组一直是用SVN来做相关的版本管理的，当然，我这种底层的开发小兵也不需要用到SVN的版本控制层面的功能的。我所能使用的，也就是提交代码，查看提交日志等一些一线开发人员常用的功能而已。当初记得，项目组的SE经常提出新的需求，同时，测试也在不停提出bug修改要求，所以总是把代码一份一份的拷贝到不同的文件夹中，然后对于不同文件夹的代码进行不同的代码功能修复或者开发，最后合并到最初的SVN源码文件夹中。不得不说，这是一种非常原始的方式，但是这是我当时能够最有效的代码控制的方式了，因为经过自己的实践证明，这种方式可以合理规避掉各种的代码覆盖冲突等问题。至今还对于用BeyondCompare一行行比对代码的事记忆犹新啊。

今天又是翻了一下「算法导论」中的「快速排序」，在记忆中，似乎记得这是实际应用中使用的最多的排序算法了，尽管它并不是一个很稳当的排序算法。「快速排序」的平均性能看起来是非常好的，但是它不稳定，因而坏起来的话，那也是非常糟糕的。对于「快速排序」来说，我们只能对它的期望时间复杂度做出估计：Ο(nlgn)。

「算法导论」中给出了「快速排序」以下的伪码实现，说实话，我并不是很喜欢这种写法，因为有时候这种方式很容易让人看晕了，还不如实际代码来的直接明了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

PARTITION(A, p, r)
x = A[r]
i = p - 1
for j = p to r-1
    if A[j] <= x
        i = i + 1
        exchange A[i] with A[j]
exchange A[i + 1] with A[r]
return i + 1

QUICKSORT(A, p, r)
if p < r
    q = PARTITION(A, p, r)
    QUICKSORT(A, p, q - 1)
    QUICKSORT(A, q + 1, r)

最近一直都是比较闲的状态中，毕竟还是在过暑假嘛。于是拿起那本自从买来就没看过的「算法导论」看看，以前在网上总是看见将这本书推荐给入门的新人，不得不说这真的有点坑人的。

今天才刚刚拿起来，直接忽略第一部分的所谓「基础知识」，其实是看到那么多非基础的知识一下在看不下去了。看了下「堆排序」的章节，顺便回忆了一下以前学习的「堆排序」的知识。

「堆」无外乎就是一个特殊的完全二叉树，其特殊性在于堆的每个子树的根节点的值为该子树中的最大值/最小值，对应的堆就定义为「大顶堆/小顶堆」。「堆排序」的时间复杂度为O(nlgn)，这在排序算法中还是一个不错的时间复杂度的。接下来就是用代码实现了一下「堆排序」，这是不得不说下「算法导论」中的伪码还是不错的，至少比严奶奶的那本「数据结构」要强多了，但是这样的伪码有点不利于代码的实现，估计是太过于简要了吧。

最近到处折腾了一番，终于也是回到家休息一下了。这几年，一直在西安学习工作，似乎也是在家待得很少的。这回算是彻底的离开西安了，结果就是回到家暂时休整一番吧。当然，我那辆Warrior550也就跟着回家闲着了。

车子自从寄回家后，一直也就没有拆封组装，前两天闲着没事才慢慢组装起来（PS:在这儿不得不抱怨下中通快递了，车子回来后也就看看有没有什么明显的伤痕，发现没什么事也就没管了，结果装车的时候才发现前轮的快拆轴给摔弯的不成样子，只好慢慢掰直了暂时先顶着。有了此次教训，以后寄车还是小心的为好了。），昨天乘着刚下过雨，天气荫凉的，同时也是在家闲的太过无聊了，骑着车出去转了一下。没有什么特别的感受，至少觉得安庆城还是挺小的，一个多小时就把老城区给转了一圈了。

骑行途中去了母校一中逛了一下，发现还是没怎么变化，只是前面的教学楼不知是翻新还是重建中。同时跑到长江边看看，只觉得江水真的不太干净啊，估计这几年的污染还是很严重啊。

##题记
最近开始阅读《Head First设计模式》，所以有必要把自己学到的东西用blog的方式给记录下来，其中，大部分的源码和UML关系图均是来自于该书。在此，本系列的文章只是将学到的知识记录一下，必要的地方会加上个人的理解。

##正文
在我们的开发过程中，难免会遇到一种情况：存在一个主要对象，其他的对象因为由于数据的关系，必须依赖于这个对象产生的数据，但这个对象的数据总是处于不断的话当中，因此，我们希望这个主要对象的数据一旦发生变化，那么就能够及时的通知到依赖于它的对象。而当我们取消了这种依赖之后，随之而来就是不用再去通知已经取消的对象。其实，这个很像现在的微信公众平台，只要我们关注了某个公众账号后，公众账号就会不断的去推送最新的消息给关注者，而一旦取消关注后，这些推送也就中断了。在设计模式中，我们把这种行为称之为观察者模式（observer pattern）。

对于观察者模式，我们有着这样的书面定义：

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