Emacs真是一个好东西，虽然上手比较难，但是一旦你开始使用它，你就发现它的强大之处，就会离不开它。

现在有一个情况，在使用Emacs编辑文件的时候，每次编辑完一组文件关闭Emacs之后，再次打开它时并不会再次打开上次编辑的文件状态，而是要自己手动再一个一个地打开，非常麻烦。好在Emacs是个非常强大的编辑器，你可以定制和命令它做任何事情。。。

打开.Emacs配置文件 加入下面几行ELISP：

;;打开上次的文件记录

(load "desktop") 

(desktop-load-default)

(desktop-read)

;;当emacs退出时保存文件打开状态

(add-hook 'kill-emacs-hook

          '(lambda()(desktop-save "~/")))

此文出处在 这里 ,作者cooldawn,有点意思..

新手A：7+8=？
老鸟A：呵呵，这个问题牵扯到我们用的十进制算数加法计算，还有进位问题，另外还要注意到.....
新手A：Stop！我就要知道7+8=？
老鸟A：7+8=15
新手A：可是为什么7+8=15？
老鸟A：搜索前面贴子，刚才回答了。
新手A：我搜了，搜不到，是老鸟就要帮助新手！
老鸟A：........ man 初级数学
新手A：我不懂英文，全都man了要你们老鸟干吗？
老鸟A从此潜水

新手B：6+9=？
老鸟B：搜索前面贴子
新手B：搜了，没答案，只有个烂人讲7+8，这哪是人能看懂的阿，我就要知道6+9=？
老鸟B：看《初级数学 handbook》，看懂就会做了
新手B：算个6+9都这么麻烦，这什么破操作系统阿！
老鸟B从此潜水

新手C：5+10=？
新手C：？？
新手C：没人？
新手C发帖：《为什么不能对初学者提供春风般的温暖》？
老鸟ABCDE群起攻之：这年头新手大爷，怎么这么难伺候，老鸟还怎么活！潜水去了！

今天心血来潮突然想试试用groovy访问一个OpenAPI,思考n纳秒后,决定拿豆瓣API来练练.

根据豆瓣API文档 http://www.douban.com/service/apidoc/reference/ 上的描述,表明可以通过简单的HTTP GET请求搜索豆瓣上的图书信息. 查询通过 tag,start-index,max-results三个参数分别传递 标签名称,返回结果的开始索引和返回的最大结果数来获取以ATOM或Json的形式返回的结果集,现在我只要求返回ATOM的结果就行了,那么 要获取一个查找图书的结果,需要发出这样的 HTTP GET请求:http://api.douban.com/book/subjects?tag=tagname&start-index=startindex&max-results=maxresult

好,现在就用一段简单的groovy代码来实现吧,

创建一个名为 doubanBooksSeachCli.groovy的文件

if(args){ 
    tagname=args[0]
    startindex=args[1]
    maxresult=args[2]
    addr="http://api.douban.com/book/subjects?tag=${tagname}&start-index=${startindex}&max-results=${maxresult}"
    feed=new XmlSlurper().parse(addr)
    feed.entry.each{ 
        println it.title
        println it.author.name
        println '-'*30
    }
}else{ 
    println 'USGAE: groovy douban books search cli'
}

使用Groovy 的 XmlSlurper 工具类可以很方便的操作XML数据,运用groovy的元编程能力,也可以使用obj.attribute的方式操作XML的标签.

然后,在命令行下输入 >groovy doubanBooksSeachCli.groovy groovy 1 10

查找标签名称为 groovy, 开始索引为1,最大返回结果为10的所有图书的标题和作者,返回结果如下:

Groovy in Action
Dierk KoenigAndrew GloverPaul KingGuillaume LaforgeJon Skeet
------------------------------
Grails入门指南
【美】Jason Rudolph
------------------------------
Groovy入门经典
（ 英）巴克莱（Barclay，K.）（英）萨维奇（Savage，J.）
------------------------------
Groovy Recipes
Scott Davis
------------------------------
Grails in Action
Glen SmithPeter Ledbrook
------------------------------
Grails权威指南
（美）瑞切（Rocher，G.K.）
------------------------------
Groovy and Grails Recipes
Bashar Abdul Jawad
------------------------------
The Definitive Guide to Grails (Definitive Guide)
Graeme Rocher
------------------------------
Programming Groovy
Venkat Subramaniam
------------------------------
Beginning Groovy and Grails
Christopher M. JuddJoseph Faisal NusairatJim Shingler
------------------------------

这段脚本只用了几行代码就完成了我的心血来潮, 现在再看看过去写的java代码,我想我还是宁愿用groovy替代它吧..

最近写了一个Dive Into Python 里的那个FileInfo示例程序,使用到UserDict,

from UserDict import UserDict

在python2.6下是没有问题的,但是在python3中却出现Import Error,开始以为也许是被移掉了,后来还是在python官网上找到了答案,

Issue2876

msg66900 - (view)
Author: Brett Cannon (brett.cannon)
Date: 2008-05-16 04:49

In Python 3.0, the UserDict module was removed and the UserDict class was 
moved to the collections module. That change-over needs to be backported 
to 2.6 so that the UserDict module can be deprecated.

看来是要统一模块名称,涉及collections的东西都统统要放在一起.

逐将代码改为

from collections import UserDict

就没有问题了

除了大家耳熟能详的4+1视图模型外,还有其他软件体系结构表示方法.Reference Model of Open Distributed Processing(RM-ODP)是ISO的一个标准,从名称就可以知道这个方法是对应于分布式系统的.从事软件开发的朋友都知道开发分布式系统是一个非常复杂和困难的任务,必须从多个方面和视点对系统进行设计.那么RM-ODP的目的就是为软件架构师提供一个参考模型.以应对日益复杂的分布式应用.

其实RM-ODP包括了四部份：

1. 概要(ISO/IEC10746；ITU-TX.901)：主要着重解释整体的概念、动机及范围，是介绍使用者如何应用RM-ODP的文件。

2. 基础(ISO/IEC10746-2；ITU-TX.902)：提供整个模型的制定及基础，提供模型的相关定义及原则，以及应用方法。

3. 体系架构(ISO/IEC10746-3；ITU-TX.903)：描述及定义ODP系统，描述ODP系统必须符合的约束条件，RM-ODP的视点定义及应用等。

4. 体系架构语意(SO/IEC10746-4)；ITU-TX.904：主要以特定的描述语言补充第二及三部份的内容。

RM-ODP是基于面向对象技术的,它定义了信息系统体系结构的含义,作为一种使我们了解软件体系结构的方法,它代表了当今成熟的软件体系结构实践.RM-ODP定义了5个基本视点并将他们用于系统建模:

企业视点(Enterprise view point) 分析系统目的、商业需求、策略和系统范围的视点。 RM-ODP处理与企业层面有关的信息，例如组织结构和政策等

信息视点(Information view point) 指信息的结构，当中包括信息的变化、流程、及不同功能上的逻辑分割。

计算视点(Computational view point) 着重于把系统的分解(decomposition)成相对的实体(entities)及接口(interfaces)。

工程视点(Engineering view point) 处理有关分布式系统对象间的交互 (interaction)，及描述如何支持有关的互换(interaction)。

技术视点(Technology view point)：定义有关系统的软件及硬件组件(components)

这5个视点为单独的信息系统提供了一个综合性的模型

至于这个参考模型的详细信息,有兴趣的朋友可以参考有关的ISO文件或浏览以下网址http://www.rm-odp.net/. 标准文档有200多页,所以就不多说了.

RM-ODP是个ISO标准,和这个组织制定的7层网络参考模型一样,有一些地方过于复杂了,它采用了CORBA的接口定义语言作为特定的计算体系结构的描述语言,对于现在流行的.NET和java分布式处理技术来说其复杂性有可能增加了.而后两者是现在实际上的技术标准,也许RM-ODP又会重走ISO7层模型的覆辙.但是作为一个软件体系结构的参考模型,RM-ODP是可以不依赖于具体技术的.将.net和java的分布式处理技术应用于RM-ODP将是一个有趣的实践.