追忆年华

四年前，德国世界杯如火如荼的进行着。当时我跟茹茹的关系，可以用茹茹的一句经典的话来概括：当时谁认识你啊！月上柳   梢头，人约黄昏后，我们游走于三教和荟园开水房之间的大道，探讨着“我喜欢你，你为什么不喜欢我？你怎么样才能喜欢我 ，做我女朋友”的神圣话题。那时，世界杯的激情，似乎跟我们没有关系。

四年后，南非世界杯也同样如火如荼的举行着。现在，我和茹茹早已相知相爱，我们已经相互理解，我们的性格经过四年的磨合，对于大事上的看法也慢慢趋于一致。可以说，我们现在的人生观、价值观、世界观已经归拢。    

四年，人生最重要的四年，已经过去。这四年，包含着多少美好记忆，承载着许多酸甜苦辣，孕育了我们的爱情，催生了我的日渐成熟。这四年来，我是幸运的，我是成功的。幸运的遇到了人生中的另一半，成功的俘获了她的芳心。

我们拥有令旁人羡慕，自己永生难忘的甜蜜时光：

• 月光下散步，大学生活动中心前的竹林、南湖边有我们的身影


• 春天，学校油菜花开了，那黄灿灿的油菜花，加上我们是多么的美丽


• 南湖边，桃花园，散步感受春意


• 夏天热了，在草地买个西瓜，跟茹茹品尝


• 在体育馆前的林荫小道，学习、聊天、休息


• 篮球场上、一运，当茹茹想保持身材的时候，我们也会在这里滴下汗水


• 荟一楼下的草地，有多少等待在那里


• 游泳馆游泳，虽然只有一次，虽然我不会，但是有茹茹的陪伴，一次足以记忆一生


• 冬天满天雪花，打雪仗自然少不了我们


• 茹茹的21岁生日，野芷湖旁，我们将21根蜡烛组成心形


• 我们经常出去吃小吃，常去校门口、司门口、中南财大，酸辣粉、周黑鸭、肉夹馍、馄饨……


• 动物园、磨山、江滩，有着心爱的人，游玩的感觉无法形容


• 我头痛时，茹茹越来越唠叨，越来越像我妈时，我知道那是关心体贴


• 工作了，一到周末，茹茹屁颠屁颠过来找我


• 不管在学校，还是在广州，虽然我不喜欢逛街，虽然我当时都很不耐烦，但是现在回忆，依然很美好


• ……

当然我们也经常吵架，我们也有不合，茹茹也经常对我的举动不满意，虽然我们争吵很多，虽然我们有时候争取很凶，但是我们通过争吵更加了解对方。我依然记得在雪地里，茹茹咬着牙，使出浑身力气，将她的粉拳细腿砸向我，但我更记得我们第二天和好时的甜蜜。

虽然我现在不富裕，但我坚信：我能够给茹茹快乐幸福的生活。就像电视剧《媳妇的美好时代》里，余味反驳李若秋一样：“我跟豆豆的生活乐趣，是我们通过自己的努力，共同买辆车，我们这个月在一块存钱，能够买一个车轮子，下个月在存钱就买了方向盘，再下个月我们就买了后备箱，再下个月我们就买了一辆车了，也可能车的钱，不贵，很便宜，只是一辆QQ，这个车就全当练手了，练会了之后，随着以后越来越好，我们会买更好的车，这就是我们两人的快乐。”我想这也是我应该给茹茹的快乐，并且是我能够给茹茹的幸福。

排序

在平时项目中，排序很常见，一般情况下，采取的常见方法有：

• 在数据库查询时order by xx。


• 采用list的方法sort(), 如list.sort()

但是有写情况，上面两种情况不是那么轻易可以搞定的。内建函数sorted则相当强大。

sorted(iterable, cmp=None, key=None, reverse=False)：

• iterable是一个可迭代的对象，就是我们需要排序的对象


• cmp只是一个函数，定义了两个元素之间的比较规则。如果这个参数为None，则按照程序默认的排序规则比较iterable的元素对象。如果不为None，则根据cmp来比较。


• key也是一个函数，但是这个函数和cmp不同，key函数是用来提取iterable对象元素的索引，用这个索引来排序。如果key为None，则直接用iterable对象元素来排序。


• reverse则是指定排序的顺序，如果为False，则从小到大，为True，则从大到小，默认为False。

 

比如现在有这样一个list：

user = [
    {"name": "Juven", "age": 23},
    {"name": "fisher", "age": 22}
]

想根据age来降序排序，怎样做呢？一句话搞定：

sorted(user, key=operation.itemgetter("age"), reverse=True)

或许你对itemgetter不熟，看看这些：

itemgetter(item, [args...])

Return a callable object that fetches item from its operand using the operand’s __getitem__() method.

If multiple items are specified, returns a tuple of lookup values.

Git初学习

今天细细琢磨了一个git。git很火，慢慢会流行起来。git有什么特点，能够在众多版本管理系统中杀出一条血路呢？这是git官网对于git的介绍：What is git?

Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.

Git is used for version control of files, much like tools such as Mercurial, Bazaar, Subversion, CVS, Perforce, and Visual SourceSafe.

所以先可以得出git有两个特点：

• 快，据说比小李飞刀还快。我想git快，其中一个原因还是和git的分布式分不开，因为很多情况下不需要在网络环境中进行，本地就OK。一部分的原因是因为git是建立来用在linux核心上的，这表示git从一开始就必须有效率的处理非常大的repository。此外git是采用c写的，减少了使用其他高级语言在执行器的开销。


• 分布式。git是分布式SCM，每个开发者本地都有一套git库，每个人都维护自己的版本(或者合并其他人的版本)。这样带来的好处就是：离线情况下也能做好版本控制，不用时刻连网，随时随地coding。另外，分布式的SCM更加健壮，不像SVN，服务器一挂掉，后果不堪设想。

Git当然还有很多优点：

• 强大的branch和merge的能力


• 操作更加简洁、方便

bzr最慢，cvs太老，svn主流，git新潮。今天看文档，觉得学习git的确比其他版本控制，更难些。但是这个怎能阻止我的步伐？

参考：

http://hilbert.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=cat%3Dgit

http://wiki.guoshuang.com/Git_svn_%E6%AF%94%E8%BE%83

http://blog.csdn.net/colorant/archive/2008/10/31/3193820.aspx

http://www.robinlu.com/blog/archives/191

http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/

The Apache Paltform and Architecture

上个星期算是将APUE粗略看了一遍，写了个简易的http server(算是弥补下实习时候的遗憾)，写完后发现自己对文件描述符的理解还不是特别透彻，特别是多进程共享的时候(很早以前觉得APUE必须重新精读一遍)。很想知道Apache是如何实现多进程并发，无奈源代码苦涩难懂，不知从而看起(应了linus的那句话Read The Fuck Soucing Code)。进而转向看文档The Apache Modules Book。看完第二章The Apache Paltform and Architecture，我彻底拜服，拜服于apache的架构。下面就谈谈对apache architecture的了解。

Apache HTTP server由APR、Apache HTTPD、mpm、modules、The Third Libraries几部分构成。《Apache 源代码全景分析》中分的更细，将Apache划分为四个大的层次：

1. 可移植性运行库层(APR)


2. Apache核心功能层(Apache CORE)


3. Apache可选功能层(Apache Optional Module)


4. Apache第三方支持库

《Apache源代码全景分析》为何没有列出mpm？我想是把Apache HTTPD、mpm和一些必要的modules归结成Apache CORE。Apache为何这样设计，下面就详细说说各个层次的用处和这样设计的目的：

• APR。由于各个操作系统提供的底层API是不同的，甚至存在着很大的差异。如果没有APR，Apache设计者就必须关心各个操作系统API细节之间的不同。采用APR就是将不同操作系统的底层细节封装起来形成操作系统API的适配并将其隐藏起来。这样Apache CORE建立在APR上，能够满足不同操作系统的要求。(说明：APR并不是只为Apache使用，任何想跨平台的软件工程，都可以拿来用)


• Apache HTTPD的主要功能是启动和停止Apache，处理配置文件，接受和处理HTTP连接，读取HTTP请求并对该请求进行处理、处理HTTP协议等。

Apache HTTPD和modules之间的关系是调用和被调用的关系，所有的模块都直接和核心进行交互。调用是通过Apache HOOK实现的，这样处理的好处是：Apache HTTPD不用关心模块的多少，模块到底如何实现，直接调用即可，用户可以随时加载新的模块或者卸载模块，不仅降低耦合，并且扩展性极好。

The zen of python

在python的命令行的交互解释器上，输入import this便可以得到:

The Zen of Python, by Tim Peters

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!

下面是中文的解释，觉得很赞：

优美胜于丑陋（Python 以编写优美的代码为目标）
明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
间隔胜于紧凑（优美的代码有适当的间隔，不要奢望一行代码解决问题）
可读性很重要（优美的代码是可读的）
即便假借特例的实用性之名，也不可违背这些规则（这些规则至高无上） 
不要包容所有错误，除非你确定需要这样做（精准地捕获异常，不写 except:pass 风格的代码） 
当存在多种可能，不要尝试去猜测
而是尽量找一种，最好是唯一一种明显的解决方案（如果不确定，就用穷举法）
虽然这并不容易，因为你不是Python之父（这里的 Dutch 是指 Guido ）
做也许好过不做，但不假思索就动手还不如不做（动手之前要细思量） 
如果你无法向人描述你的方案，那肯定不是一个好方案；反之亦然（方案测评标准）
命名空间是一种绝妙的理念，我们应当多加利用（倡导与号召）