夜宴和满城尽带黄金甲

昨天在迅雷上下了张艺谋的“满城尽带黄金甲”，个个都是爆乳。。嘿，就差乳头了。。
夜宴比满城尽带黄金甲好看。。
夜宴的故事比满城尽带黄金甲丰满一点点，虽然满城女人个个爆乳。。。。
叔叔杀了侄子的老爸，呵呵，大家能想到什么？？莎士比亚的汉姆雷特啊。。。
同父异母的兄妹发生关系？？这可是乱伦。。。大家应该更熟悉了。。根本就是曹禺的雷雨嘛。。
黔驴技穷的老谋子。。

我的blog计划

以后坚持每周写2-3篇blog，记录自己的一些想法，记录开发心得，记录自己的成长轨迹（呵呵。。），记录自己的感情经历（八卦一下。。）。。。
呵呵。。希望大家都来坐坐。。。

合理利用gmail、google reader、google docs、google notebook等服务

现在互联网提供的免费服务实在太多，比如提供blog服务，随便一个稍微有点人气的网站都提供blog服务。。太多了反而令人眼花缭乱，不知道究竟用哪个好了。。
我用的google的服务就有gmail、google文件、google reader、google notebook、google书签，差不多都用了，只是这么多一直都没有充分利用起来，并且有很多功能有重叠，有些时候选择多了，反而不知道选什么好！
1、gmail：用英文的gmail，将gmail帐号和公司的邮箱帐号绑定在一起，这样收发邮件就可以都在gmail里，抛弃outlook客户端了。最重要的是可以用gmail的会话功能把邮件组织起来，也不用把邮件都保存在硬盘上占磁盘空间了。。
2、google reader：一直都在用，还不错，订阅了很多rss。。不爽的是订阅csdn的blog，显示的都是乱码。。
3、google文档：支持中文了，并且能发布到blogger上，以前发布到blogger上中文乱码问题也没有了，可以放心使用。gmail的附件可以用docs来打开，这个功能不错。。家里公司都可以用。。
4、google notebook：这个小东西其实挺有用的，以前没有好好使用，刚开始一条字数太少。可以随时记录一些问题的解决方法，也可以在看网页时把一些网页片段随时摘录下来（用firefox的notebook插件），省的以后忘了，可以隔段时间做个整理，现在支持导出到google docs了。。
5、google calendar：这个玩意发布之后一直不知道怎么用才好，平时用的话反而嫌麻烦，可以把一些计划性的、长期的、规划的目标和计划弄在上面，定时来提醒查看进度，也能督促自己，省得有时候订个计划，比如要在一段时间内做什么，往往不能坚持，久了也容易忘。。
6、blogger：这个不用多说了，现在国内访问基本正常，也去掉beta了，可以和google docs集成，以后得坚持写blog，都用google文档写，然后发布到blogger上。。
7、google pages：不知道怎么用才好，觉得有了blogger，就没有精力来用了。。
8、google toolbar：一直都是用firefox，原来是用google sync来同步公司和家里电脑firefox上的书签，但是发现sync不是太好用，并且刚开始不稳定也占资源、老链接不上，就把所有的书签都放在google书签里，通过toolbar来访问，还不错。。也抛弃firefox的书签了。。
除了google的，还有一些其他的服务：
1、rememeber the milk：一个提供todo list功能的web2.0网站，界面简洁，就用他来记录平时的想法，或者有些要实现的小功能，几天内要做的一些事情，可以定时来整理。。最重要的是在家里公司都可以看。。
2、

需求规格说明书

一、引言
1.1 编写目的
为了更好的确定和明确需求，减少以后可能重复的设计和编码，最好的满足客户需求，也作为设计文档、测试文档的依据。
1.2 项目背景
简单描述遗留系统、要做的新系统，以及和其他系统的关系。
1.3 参考资料
参考的资料，可包括政府、地区的相关规定和行业的相关标准，遗留系统的相关文档等等。
1.4 变更历史

版本	修改日期	变更申请人	变更内容描述	备注
v 1.0	2007-02-05		初始版本

二、业务需求（商业需求）
反应组织机构或客户对系统及产品高层次的目标要求。一般从企业的技术部门得到。

三、用户需求
描述了用户使用产品必须要完成的任务。必须从真正使用系统的用户那里得到。用户需求也是对用户的具体需求进行调研才能得到。

四、功能需求
定义了软件开发人员必须实现的功能。是从用户需求转化而来的。
总结出具体功能设计的方法：根据高层次的需求总结设计出完整的使用方案，所谓的使用方案设计就是，将用户会怎样使用你的软件为解决某个具体问题的整个过程给想象和设计出来，而且是一个完整的从头到尾的使用过程。有了这个过程的总结，再从它的基础上进一步确定每个功能的具体需求。
4.1 功能模块1
4.1.1 子功能1
4.1.1 子功能2
4.2 功能模块2
4.2.1 子功能1
4.2.2 子功能1
4.3 功能模块3
4.3.1 子功能1
4.3.2 子功能1

五、非功能需求
系统应该达到的效率要求、可扩展性、可维护性要求、对外接口等等。

六、性能需求
系统应该达到的可靠性、压力等等。

七、质量需求
系统应该达到的质量、稳定性等等。

八、系统需求
定义系统运行的硬件平台、操作系统、网络环境、软件环境，运行的支撑系统，以及系统是否24*7运行等等。
8.1 硬件平台
8.2 操作系统
8.3 网络环境
8.4 软件环境
8.5 运行支撑系统

九、开发局限
因为技术原因不能满足的需求或者不能实现的地方。

附录一：可能出现的泥潭
1、只有业务需求，没有功能需求
需要对需求进行分类，界定每种需求的范围，其实需求分析的过程也是逐步细化的过程。
2、需求描述含有二义性
用简洁、无歧义的语言来描述需求，避免描述性的词语，尽量对描述性词语进行量化，并且给出具体值或范围。
3、需求细化程度不够
需求都是一个从概括性需求刀低层次需求的过程，一般都是知道高层次概括性较强的需求。需要将需求细化，直到消除所有不确定因素为止。需求是越详细越好，但是也不能过于详细。需要做到的是，将一个需求分割成不同的小需求，每个需求都能想出测试用例来测试这个需求。细化到这个程度也就可以了。
4、需求过程缺乏沟通
需求评审是一个非常重要的沟通方式。并且沟通应该贯穿在整个需求过程中，整个需求过程也是系统分析人员（职责是做需求分析）和设计人员（职责是做设计）不断反复沟通的过程。