我丝毫不怀疑Pylons的Middleware是不是符合WSGI的标准，那简直是一定的。我完全找不出Pylons需要重新发明一种标准的理由。从个性上来看，即使它不拥护标准，标准也会站在它那边的……

所以因此而困惑，django的middleware是什么？这个疑惑持续了很久，今天想起来，终于去看了手册。果然，并没有直接采用WSGI标准……但是，也很简单，简单到只需要一个眼神，就知道它是怎么工作的！

简单的说，就是写一个class，然后随便实现以下的几个方法之一

process_request(self, request)
process_view(self, request, view_func, view_args, view_kwargs)
process_response(self, request, response)
process_exception(self, request, exception)

我想这样的设计应该归功于Python的简单吧！

Routes是Python世界中仿rails的url dispatcher，在Pylons中被使用

使用过程中可以感受到很多魔法，很多的url参数被缓存了。比如，当前的controller是A，如果你要产生一个指向同样是A下面的另外一个view，那么A则可以省略
在一个规模不大的项目中，这样的设置极大的提高了生产力。但是随着项目的增大，我们不得不考虑重名的url参数产生的影响。

当我们不需要这样的特性的时候，在routing.py中这样写就可以了

    map = Mapper(explicit=True)

对于WPF的出现，我后知后觉

终于某一天，许多功力比我更加高深的老大们，在WPF的召唤下停止了冬眠，用睡眼朦胧的表情一脸不经意的表达着自己对于新事物的不解。他们说：

“这不是写html嘛！”

太精辟了

这个世界上的程序员们已经被折腾的要死，早知道社会如此繁荣昌盛，何必去搞那些深奥的ASM和深刻的API。其实聪明人早就看出来了，从该死的rc文件开始，那些产品的设计者就根本没把程序员放在眼里。

于是我开始开窍，虽然这一过程已经开始并且还将继续好几年，所以我已经准备好去挖煤，因为这是一项非常具有前途的基础性工作。

写pylons程序的时候，总是喜欢那些全局变量，session，request，还有h和c

尤其是c，相当于一个短小的命名空间，放入这个空间的变量，就可以暴露在模板中了。绝妙的主意，精彩的设计……

如何在django中这么做呢？django需要我们把要送到模板的变量写成一个字典，主意，是一个字典！伟大的动态的字典

v1=0
v2=0


return render_to_response('template.html',{'v1':v1,'v2':v2})

如果你有更多的参数，不久你就会厌倦了这样的写法。那么就学习pylons一样写一个c变量

c={}
v1=0
v2=0


c['v1']=v1
c['v2']=v2


return render_to_response('template.html',c)

无论有多少变量要传，最后一行都是这个样子。算得上django的小技巧吧！

周末参加了shanghaionrails的活动，认识了不少玩ruby的朋友

要说ruby，我也试图学习过。语法中有些trick，使得我一时难以适应，于是放弃……从此看ruby的语法总是怪怪的。

不过一个群体总是可以让人克服这样那样的问题。很高兴认识这样的朋友们，也很期待有一个ruby或者rails的项目机会可以让我快速的了解更多ruby

依然惊讶于ruby的美丽符号，像可以在方法名中写上问号，冒号开始的symbol