Contents

可爱的附录
1. 附录的附录
行者箴言
箴言凝练
1. 蠎之禅
2. 附:我们的奋起宣言
Z跋

可爱的附录

从实例开发故事，到对照解说的"初学者作弊条",行者们带领好奇的读者巡游了Python 世界的最常用领域；

自然的，还有那些更加丰富的应用领域,可是限于篇幅和行者们的能力,只能以附录的形式分享部分给小白或是曾经的小白们:

行者箴言: 此部分基于中国著名Pythoner~Limodou Blog 文章,结合笔者开发体验，分享一名靠谱的Pythoner 应该具备的思想
术语索引: 成为业内人士，就得满口术语呢，这部分列出相关的各种术语首次在图书中出现的位置，以及基础的理解；
Z践: 写本书很难，写本技术图书就更加难了，而写本受欢迎的入门技术图书简直是种逆天的行为了！各种甘苦在此说与君品；

附录的附录

不知不觉中行者们聚集的内容竟然大大超出了编辑的期望,为了图书能以适中的价格面市,不得不将部分内部迁移到网络平台中发布,特此附录:

资源索引

此部分以中国实践型Python 技术社区～啄木鸟社区的知识库为核心，给出各种方面应用的主要参考资料，以供读者按图索骥;

访问地址: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython/LpyAttach2ResIdx
精巧地址: http://bit.ly/cELq8

练习解答

在实例故事和PCS~作弊条部分都设计了有针对性的实用的小练习，在此单元整体分享一下行者们的解答;

都可以通过SVN 下载到本地研究:
1. CDays习题解答: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython/LpyAttAnswerCdays
  - 精巧地址: http://bit.ly/XzYIX
  - 用SVN下载: http://openbookproject.googlecode.com/svn/trunk/LovelyPython/exercise/part1-CDays/
2. KDays习题解答: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython/LpyAttAnswerKdays
  - 精巧地址: http://bit.ly/axi7
  - 用SVN下载: http://openbookproject.googlecode.com/svn/trunk/LovelyPython/exercise/part2-KDays/
3. PCS下载地址: http://openbookproject.googlecode.com/svn/trunk/LovelyPython/PCS/

行者箴言

光说不练徦把式, 光练不说傻把式！ ~ 所以,汇集散落在书中各处的行者"箴言"细说来由;-)

每节使用固定的述说模式:
1. 给出E文定义
2. 给出实例故事的出处
3. 讲述产生的背景
4. 展开解说相关的体验,给出进一步的阅读资料

少学,多用!

Enjoy it! don't Learnning

来自 CDay -5 Python初体验和原始需求

背景

"[编程杂谈]做个项目吧"
- 访问地址: http://blog.donews.com/limodou/archive/2004/12/10/199174.aspx
- 精巧地址: http://bit.ly/YOdMc
来自中国Python 著名行者 Limodou 的Blog,是他维护着 UliPad(当时还叫 NewEdit) 这一轻便实用纯Python 实现的编辑器项目
- UliPad工程网站: http://code.google.com/p/ulipad/
在文中 Limodou 倡导在项目开发的实际应用中学习相关知识

解说

这是本书的核心本愿!
在 CPyUG ~ Chinese Python User Group(中文Python用户组)的邮件列表长期维护过程中笔者们发现:
- "怎么可以学好Python ?" 是初学者最经常和反复提到的一个问题!
这个问题,怎么回答,其实不是简单的学习经验的分享,而是怎么传达 Pythonic 精神和自信的哲学性问题;
通过 Limodou 的倡议,大家最终确认了这一学习原则:用之,不学!
为学习Python 而学习,是最不可取和南辕北辙的;因为, Python 本来就是为了快速解决常见问题而创造出来的,不是为了印证什么编程理论或是模式;所以, "在战斗中学习战斗",是Python 学习的最合适态度,而且也只有在面对实际问题时,才可以真正感受到Python 的简便/友好/直觉!如果拉开架式,为了写出漂亮的面向对象的或是吻合什么模式的代码而去研究Python,那就失去了用Python快捷解决问题的爽快体验了!

脚注::
CPyUG的主力邮件列表地址是:
http://groups-beta.google.com/group/python-cn
精巧地址: http://bit.ly/3895ZW
啄木鸟自由软件社区,则是另外一个中国Pythoner 聚集地;
和CPyUG 的关系可以参考:
http://wiki.woodpecker.org.cn/moin/WoodpeckerAbt
精巧地址: http://bit.ly/4DHYa0

寻之,弗造!

Searching at first,Don't try creat!

寻找吧!不要先想着创造--Python 是自足的
- 来自 CDay -4 可用的首个Python脚本
你能够碰到的问题,99%的情况下其它人已经遇到过了,所以,最佳的解决方式就是找到那段别人解决相似问题的代码!
- 来自 CDay -1 中文处理完成功能的实用化

背景

图 atta1-1 漫画电池内置
Batteries Included~电池内置 是Python 的哲学之一!
- 详细说明: http://www.uselesspython.com/BatteriesIncluded.html
- 精巧地址: http://bit.ly/2vPE15
意思是Python语言本身,已经天然内置了足够多的实用模块,可以完成大多数常见任务的!
成功故事之一:
- EZTrip.com 选择Python 进行企业整合的故事: http://www.python.org/about/success/eztrip/
- 精巧地址: http://bit.ly/4TrC2
另外相关Blog一篇: "[编程杂谈]开始读源码吧"
- 访问地址: http://blog.donews.com/limodou/archive/2005/04/26/352565.aspx
- 精巧地址: http://bit.ly/nS0rE
- 同样来自 Limodou 的体验分享,文中指出,想写出好代码,就要多看其它优秀作品的源代码;这不仅仅要提取出对自个儿用有的代码,同时也是学习他人的思路和工程设计/组织经验;

解说

有自由/开源软件的世界里,解决问题的最快捷途径绝对不是自个儿堆代码解决!
嗯嗯嗯,当然的出于"程序员"的自尊,以及关键性的经济条件,一般也不允许去买软件来解决问题;-)
Python 使用开源许可证:
- 全文访问: http://www.python.org/download/releases/2.4.2/license/
- 精巧地址: http://bit.ly/1xTbla
所以,各种基于Python 的项目一般都乐于公开源代码;
加之,Python 因为有丰富的C语言接口,实际上也是种方便的胶水语言--可以平滑的直接或是通过接口模块和各种开发语言協同完成任务!
故而,用Python 来解决问题,基本上不用自个儿冥思苦想整出代码来,只要用心先搜索一下根据问题域的解决方案设想,广泛调研一下,基本都可以找到一个以上的支持模块或是软件--当然是Python 写的,下载来,稍微配置或是定制/修改一下就好! 作为Pythoner ,应该有这种自觉和自信!
不过,Python 的各种支持模块/软件都是各行其是的分散在网络中,并没有象Perl 的CPAN 那样形成统一聚集地;
当前,比较集中的 Python 作品索引中心有:
- Python Package Index
  - 访问地址: http://pypi.python.org/pypi
  - 精巧地址: http://bit.ly/2QQiMz
  - Python 官方网络组织的模块包索引,和 setuotools 工具协同,可以自动下载和升级各种己注册模块;
- The Vaults of Parnassus: Python Resources
  - 访问地址: http://py.vaults.ca/apyllo.py
  - 精巧地址: http://bit.ly/10KY2U
  - 以问题域为分类,长期收集有大量的软件包信息
- Python Starship
  - 访问地址: http://starship.python.net/crew/index.html
  - 精巧地址: http://bit.ly/eMW11

CPAN

访问地址: http://www.cpan.org/
即: Comprehensive Perl Archive Network ~ Perl 综合典藏网
它是一个巨大的Perl软件收藏库, 收集了大量有用的Perl模块(modules)及其相关的文件. 由于CPAN的收藏丰富, 使用者甚多, 在世界各地都有许多CPAN的镜站(mirror site)存在.

CPAN亦是一支Perl程式的名字, 其作用是让使用者容易从CPAN下载、安装、更新及管理其他在CPAN上的Perl程式,日常使用类似:

~$ perl -MCPAN -e shell
#第一次进入CPAN时, CPAN将会进行一次配置(configuration). 当配置完成后, 就可以利用CPAN来查询CPAN内的Perl模块, 并且进行安装. 一般操作如下：

CPAN> d /bioperl/

查询有关bioperl的模块

CPAN> install modulename

安装指定的模块

CPAN的成功引来很多其他编程语言社群的模仿. CTAN（Comprehensive TeX Archive Network, TeX综合典藏网）和CSAN（Comprehensive Scheme Archive Network, Scheme综合典藏网）都参考了CPAN的命名方式. 另外PEAR（PHP Extension and Application Repository）也是类似CPAN的PHP程式网站!
8卦一下: 在Perl 6 之后,因全新设计的Parrot引擎,支持其它语言的解析和字节码编译,故而,Python 有望直接使用CPAN!

变之!守之!

Keep evolution,never foget the start idea!

不断的否定自己,但是要坚持最初的妄想^{--不论战术上如何变化,千万不要忘记战略目标}
- 来自 CDay -3 通过函式进行功能化

背景

"[编程杂谈]编程就象练书法"
访问地址: http://blog.donews.com/limodou/archive/2006/04/02/808281.aspx
精巧地址: http://bit.ly/3TGsCt
还是来自 Limodou 的体验分享,文中指出:编程应该象练毛笔字--只求耕耘,不求收获;在不断的反复修订中积累经验和思路,才会有那么一天一切豁然开朗的!

解说

这是 Pythonic 重构心态的劝戒;
在PCS404 代码重构浅说中有相关的简介；
这里特别指出的: 很多时候最初那一瞬间的设想/构思/概念可能就是整个软件/项目/工程的最核心亮点,千万不要在代码展开编写后,逐渐被各种意外问题所迷惑,忘记了最初那个自个儿真正想完成的功能!
不断的否定自己,意思是否定自个儿现在的代码实现方式,而不是功能,并且,在重构/增补代码/功能时,有一个基础指标要守住 -- 确保现有所有功能是运行正常的,是可用的,通过测试的!

发布,持续!

Keep realese,Keep publish!

发布!为了全人类!因为一个人如果力求完善自己, 他就会看到, 为此也必须同时完善他人. 一个人如果不关心别人的完善, 自己便不可能完善.
发布好象不是通告一嗓子就好的事儿 ~ 分分分!学生的命根! 文档,文档,文档!软件的颜面!
- 来自 CDay 0 感受软件工程进行发布的准备

背景

一个人如果力求完善自己, 他就会看到, 为此也必须同时完善他人. 一个人如果不关心别人的完善, 自己便不可能完善. 源自庄秀丽老师(任教于北京师范大学教育技术学院)曾经的一篇Blog:
读书摘要——拔高一个层次看分享与协作

一个人如果力求完善自己, 他就会看到, 为此也必须同时完善他人. 
一个人如果不关心别人的完善, 自己便不可能完善. 

这是因为, 人要充分发展自己的天性, 必须充分发展他的人际关系, 也就是在社会之中. 

这就回到了孔子、孟子的传统, 人要想完善自己, 必须实行忠恕、仁义, 这就包含了帮助别人. 
人要想完善自己, 就必须充分发展上苍的天性, 帮助别人就是参与天地化育万物的工作. 
一个人如果真正懂得了这一切, 他就与天地合参, 成为一体了. 

《中庸》所讲的"明", 便是这个意思：人做到与天地合参, 便是完美. 

在《中庸》里, 至善被称为"诚"（真诚、纯真）和"明"是连在一起的. 
《中庸》第二十一章说："
自诚明, 谓之性. 
自明诚, 谓之教. 
诚则明矣, 明则诚矣. "一个人如果把他所领会的都付诸实践, 他也就是圣人了. 

人只有在自己的实践中, 才能懂得这些普通、寻常事的真正意义；也只有真正懂得它们的意义, 才能做得完美.

从中可以体验到分享是暗含帮助他人从而令自己完善的致理的！

另外一篇Blog:"[编程杂谈]写写Blog吧"
访问地址: http://blog.donews.com/limodou/archive/2004/12/14/202590.aspx
精巧地址: http://bit.ly/49NSOE
依然来自 Limodou 的分享文章,文中指出:"分享你的心得吧",从中不仅仅可以通过文字的形成,将自个儿的想法和设计真正厘清,同时也是获得越来越多同道中人关注和相互激发的好途径!

解说

在 WEB2.0 时代,各SNS网站都开始号称永远的beta 版本,也就是持续发布和改进;
豆瓣网就是其中的实例,在不断的和用户交互沟通过程中,不断的增/删/改网站功能,令网站服务在使用中,不断的及时的影响用户的需求,成为好用的,人们喜欢用的系统;
再小的程序开发也应该一样,软件开发的本质目标是解决问题,而程序员写程序,就应该永远想着自个儿的代码可以长久的应用下去,可以在所有相似的情景中快速得到复用!
这就要求对代码要在运行过程中不断的根据新要求/新目标/新情况,持续修订/重构,令代码逐渐变的凝练,稳固!同时,代码本身也应该是简单明晰的,借助简略恰当的注释,甚至于不用注释,任何人都可以快速理解代码的设计思路,执行脉络,实现结构,可以立即加入到其它应用中,稳定的支撑起新的软件来!
所以,发布一直以来就应该是对内对外的双重发布:
1. 对内: 为自己,通过发布和整理,以及注释更新,令开发者自身,加深对代码的理解,并及时进行再次重构迭代;
2. 对外: 为公众,通过发布和宣传,让其它人获知软件的状态,令有缘人可以及时得到我们的代码,并通过清晰易懂的代码建立起沟通渠道,可以就相似问题域的解决进行互通有无,令好代码传播出去,延长生命周期的同时,也因为及时丰富的使用反馈,令自个儿的代码可以进一步得到增补!

能用,再修!

Run! before Enhancement

没有完美的软件!够用并且容易使用的软件已经算是完美的了
- 来自 CDay -2 利用文本文件完成核心功能
没有最好,只有更合理!
- 来自 CDay +1 首次重构优化数据结构

背景

"东拉西扯：谁需要更复杂的软件 - 对牛乱弹琴"
访问地址: http://blog.donews.com/keso/archive/2005/11/18/630753.aspx
精巧地址: http://bit.ly/4d8BSN
来自著名博客 keso(洪波),文中从办公软件的对比说开去,就软件本身的品质/功能/易用性等等方面提出了尖锐的诘问;
从中笔者提纯出的概念是:"当软件或是系统再也没有任何可以放弃的功能时,软件或是系统才处于最佳状态!"
软件或是系统,并不是越大越复杂就越好的! 因为组成软件的代码,当多到一定程度时,其维护代价会突变,变成完全陌生的怪兽般无法控制! 所以,很早,在软件的远古时代先贤们就提出了好软件的艺术规范:
1. 让每个程序就做好一件事;
2. 假定每个程序的输出都会成为另一个程序的输入,哪怕那个程序还是未知的;
3. 尽可能早地将设计和编译的软件投入试用,对拙劣的代码别犹豫,扔掉重写;
GNU体系中灿若繁星的优秀软件,就是充分运用以上原则创造出来的;进一步的推荐图书: 图 atta1-2 Unix编程艺术
- 豆瓣推荐: http://www.douban.com/subject/1467587/
- 精巧地址: http://bit.ly/1xsinL

解说

以上持续改进的思想,被行者们精炼成了: Python 八荣八耻
访问地址: http://wiki.woodpecker.org.cn/moin/Py8Rong8Chi
精巧地址: http://bit.ly/4e7L5C

以动手实践为荣 , 以只看不练为耻;
以打印日志为荣 , 以单步跟踪为耻;
以空格缩进为荣 , 以制表缩进为耻;
以单元测试为荣 , 以人工测试为耻;

以模块复用为荣 , 以复制粘贴为耻;
以多态应用为荣 , 以分支判断为耻;
以Pythonic为荣, 以冗余拖沓为耻;
以总结分享为荣 , 以跪求其解为耻;

这其中有很多Python的方言性经验,如果没有使用过Python 的读者,可能无从想象,笔者特此对其中一个要点进行简述,其它的就得读者自行在实践中印证进而和鸣了:-)
- 以空格缩进为荣 , 以制表缩进为耻; ~ 这是因为Python 是世界上唯一成功的将代码排版和语法结构融合的语言!例如:

   1 def formatCDinfo(root,dirs,files):
   2     export = "\n"+root+"\n"
   3     for d in dirs:
   4         export+= "-d "+root+_smartcode(d)+"\n"
   5     for f in files:
   6         export+= "-f %s %s \n" % (root,_smartcode(f))
   7     export+= "="*70
   8     return export

其中的函式声明,for 循环体等语法结构的划分,就是使用 :配合缩进完成的,这比其它主流语言使用{以及}来标识,要科学和人性的多!因为这样一来:

任何人写的Python 脚本有统一的排版,方便他人理解程序思路;
禁止了任何人写出极其丑恶的非人性代码来!比如说:

#include <stdio.h>
main(t,_,a)char *a;{return!0<t?t<3?main(-79,-13,a+main(-87,1-_,
main(-86,0,a+1)+a)):1,t<_?main(t+1,_,a):3,main(-94,-27+t,a)&&t==2?_<13?
main(2,_+1,"%s %d %d\n"):9:16:t<0?t<-72?main(_,t,
"@n'+,#'/*{}w+/w#cdnr/+,{}r/*de}+,/*{*+,/w{%+,/w#q#n+,/#{l+,/n{n+,/+#n+,/#\
;#q#n+,/+k#;*+,/'r :'d*'3,}{w+K w'K:'+}e#';dq#'l \
q#'+d'K#!/+k#;q#'r}eKK#}w'r}eKK{nl]'/#;#q#n'){)#}w'){){nl]'/+#n';d}rw' i;# \
){nl]!/n{n#'; r{#w'r nc{nl]'/#{l,+'K {rw' iK{;[{nl]'/w#q#n'wk nw' \
iwk{KK{nl]!/w{%'l##w#' i; :{nl]'/*{q#'ld;r'}{nlwb!/*de}'c \
;;{nl'-{}rw]'/+,}##'*}#nc,',#nw]'/+kd'+e}+;#'rdq#w! nr'/ ') }+}{rl#'{n' ')# \
}'+}##(!!/")
:t<-50?_==*a?putchar(31[a]):main(-65,_,a+1):main((*a=='/')+t,_,a+1)
  :0<t?main(2,2,"%s"):*a=='/'||main(0,main(-61,*a,
"!ek;dc i@bK'(q)-[w]*%n+r3#l,{}:\nuwloca-O;m .vpbks,fxntdCeghiry"),a+1);}

注意,这是正确可运行的C代码哪, 而且世界上有专门的网站(http://www.ioccc.org),每年评选出最令人尖叫的正确代码!

但是,Python 这一精心设计,在使用中,有不小的阻力,因为大家心爱的编辑环境各不相同,养成的缩进习惯也不一样,经常造成别人的代码,到自个儿这儿打开一看缩进非常的大(因为TAB~制表符在不同的编辑器中自动处理后表现出来的空格数目是不同的)!又或是将另外的代码复制过来就出错~因为TAB和空格混用时,Python 就无法正确的判定出语法结构了!
所以,行者们建议,使用四个空格来代替所有的TAB(当然的好的编辑器是可以配置成TAB是自动替换成4个空格的!)

以总结分享为荣 , 以跪求其解为耻; ~ 这是因为,Python 是面向实践的语言,Pythonic 是导向实践的思想;
- David Heinemeier Hansson (Ruby on Rails创造人) 在一次谈话中提及:"人们学习PHP是因为要得到一份工作；人们学习Java是因为他们选修了计算机科学这门课；人们学习Python是因为他们爱这门语言, 因为他们追寻美(我相信这对Ruby也是适用的)"
  - 详细说明: http://wiki.woodpecker.org.cn/moin/WhyPython
  - 精巧地址: http://bit.ly/3DUQWW
- 只是想着解决问题,从来不主动尝试理解问题搜寻化解方法;只是想从社区获得代码,从来不想着分享自个儿的体验;持这种态度将无法真正体验到Python 的美好! 行者们的倡导是:

感到不爽,自个儿尝试相应工具解决了,并及时分享出来,是态度0！
感到不爽,自个儿尝试找到解决方案了,并及时分享出来,是态度1！
感到不爽,自个儿尝试修订代码搞定了,并及时分享出来,是态度2！
感到不爽,自个儿未经尝试直接出来吼,期望行者来解决,是最不靠谱态度!

网站.软件.

Site is Software!

网站软件化绝对不是空话! 来自 CDay +2 用户界面友好化

背景

SaaS(Software as a Service,软件作为服务, 或称为软件即服务)是应用软件的一种销售方式, 客户按使用时间或使用量付费. 这些应用软件通常是在企业管理软件领域, 并通过互联网来使用.
它是目前一种新型软件服务形式, 是从 ASP(ApplicationServiceProvider, 应用服务提供商)模式演变而来, 是一种通过Internet提供软件的模式. 用户不用再购买软件, 而改用向提供商租用基于Web的软件, 来管理企业经营活动, 且无需对软件进行维护, 服务提供商会全权管理和维护软件.
对企业来说, SaaS的优点在于：
从技术方面来看：企业无需再配备IT方面的专业技术人员, 同时又能得到最新的技术应用, 满足企业对信息管理的需求.
从投资方面来看：企业只以相对低廉的"月费"方式投资, 不用一次性投资到位, 不占用过多的营运资金, 从而缓解企业资金不足的压力；不用考虑成本折旧问题, 并能及时获得最新硬件平台及最佳解决方案.
从维护和管理方面来看：由于企业采取租用的方式来进行物流业务管理, 不需要专门的维护和管理人员, 也不需要为维护和管理人员支付额外费用. 很大程度上缓解企业在人力、财力上的压力, 使其能够集中资金对核心业务进行有效的运营.

解说

GUI~图形用户界面 (Graphic User Interface)的简称;也指代所有工作在各种图形化操作系统中,通过各种图形化窗口控件和用户交互的软件; 这类软件必然的依赖操作系统提供的图形控制接口,以便实时绘制,采集用户反馈等等;
当然的Python 也可以开发这类软件的,而且可以使用的图形接口和框架也不少,这方面推荐前面"Eurasia ~ 关注高性能的原创框架" 一节的作者沈崴的文章:Python 史书·GUI 部
- 在线阅读: http://wiki.woodpecker.org.cn/moin/PyHiStory/PyGuiHistoric
- 精巧地址: http://bit.ly/3R8nHK
不过,现在的趋势是:"网站软件化",从Google桌面搜索(http://desktop.google.com)开始利用本地网页当搜索引擎的交互和控制界面,到Yahoo!mail 也使用Ajax 技术将邮箱作的象outlook;进一步的,百度的安全中心,更是利用网页安装杀毒引擎到用户桌面,但通过本地的Web服务,使用网页作为查杀病毒的控制界面!
因为,人们越来越多的将时间化在网络中,通过浏览器,在网页中写作/沟通/购物/工作/学习/游戏,,,网页作为操纵信息的界面,人家已经非常非常习惯和熟练了;
而且,网页,基于简单的HTML设计和解析,比使用操作系统的图形接口来绘制用户界面要轻松的多的多!
所以,行者也建议,能愉懒使用网页作为GUI时,千万不要客气!

王道:简洁!

Kingcraft means simple!

KISS 才是王道!来自 CDay +3 应用多线程再次优化

背景

KISS = Keep It Simple, Stupid! = 保持简单,傻瓜化！ ~= Simple is better
定义在:What is KISS Principle?(什么是KISS原理?)
访问地址: http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci521694,00.html
精巧地址: http://bit.ly/11ApDO
保持简单是敏捷开发中非常重要的一项实践, 但是这条原则说起来简单却做起来难. 因为每个程序员其实都是一个有完美主义的艺术家, 所做软件其实都是一件自己的艺术品, 同时受到许多关于设计方面的资料的影响, 所以在做设计的时候会情不自禁的加上许多"优雅特性"和"灵活性". 另一个很重要的原因在于, 在产品推出后又不得不疲于应付客户频繁提出的许多新增加的需求的时候, 会自然而然的想到：当时要是在做软件的时候能考虑到这些需求该多好啊, 现在来改实在是太麻烦了. 要是当初改的话, 也只用添加几条代码就可以了,,,
其实,这两种原因都能归结为一个：程序员总希望自己所设计的系统能最大范围内适应变化！
这种想法的出发点是非常好的, 可是在实际中却往往不是降低了工作量, 反而增加了巨大的工作量. 根本原因就在于：用户需求是无限量的, 你永远也无法预测客户的需求变化.
所以, Python 倡导简单即是美 ~ 大道至简! 简单直白的代码,好理解易维护,实在不成,堆倒重新写一点也不心痛;) 对永远在变化的需求, 心态上要拥抱变化,不能预防变化,简单稳固的小功能函式,其实是非常容易组合在一起,支持另外一个需求的,这种代码实现方式,永远比用一个理应精致细巧智能有前瞻性的模块来支持现有的简单需求,要舒服和可控的多!

解说

此箴言是相关软件设计的,基于的理论是:"少即是多" ~ 由建筑大师密斯·凡德罗（Ludwig Mies van der Rohe 1886-1969)提出的："少即是多（Less is more）.", 被广泛引用于各个领域;
与之交相辉映的是由14世纪逻辑学家、圣方济各会修士奥卡姆的威廉（William of Occam）提出的一个原理,即,"奥卡姆剃刀原理"（Occam’s razor）,通常的应用理解如下：
- 如果你有两个原理，它们都能解释观测到的事实，那么你应该使用简单的那个，直到发现更多的证据。
- 对于现象最简单的解释往往比较复杂的解释更正确。
- 如果你有两个类似的解决方案，选择最简单的。
- 需要最少假设的解释最有可能是正确的
这个原理最早至少能追溯到亚里士多德的"自然界选择最短的道路";甚至于爱因斯坦,他本身也是一位格言大师,曾警告说: "万事万物应该尽量简单,而不是更简单."
在软件行业,Pythonic 秉承了以上的思想:让代码保持简单!
因此, Python 语言本身,已经为简单的完成功能,预先内置了丰富的模块--Batteries Included~电池内置就是出于此目标; 另外,极少的关键字设计,通过排版来划分语法结构的设定,无一不是为了令Python 代码更加象自然语言的表述,鼓励大家将软件都设计的很直白小巧,模块功能单一,函式不超过50行(即,一屏的高度),如此这般,就会发觉,自个儿的代码是越写越少,多数情况下都是复制自个儿以前的某份代码过来小修订一下就立即可用了,到最后用的最多按键将是:delete

想象;无垠!

Imagine Unlimited!

想象力才是 Pythoner 的唯一界限 来自 CDay +N 基于Python的无尽探索

背景

Python的动态性真是让人吃惊^{来自 limodou的学习生活(在百度的新博客)}
访问地址: http://hi.baidu.com/limodou/blog/item/83f4b21937ed174043a9adb5.html
快速访问: http://tinyurl.com/43teuz
利用Python 天然的深度动态性,其实是解放了我们的想象力,允许我们在任何时候对程序都有完全的控制!
优雅型修饰~decorator的另一种写法^{来自 CPyUG 讨论列表的一次爽快的分享}
访问地址: http://wiki.woodpecker.org.cn/moin/MiscItems/2008-04-17
快速访问: http://tinyurl.com/4urfmx
这里可以体会出,Python 的所谓密技是不存在的,一切都是公开透明的,只要愿意去理解,很快就可以整明白!

解说

在Python 世界中很多时候作起来比想象中要来的容易!
因为从教育学角度的研究,人在同一时间内可以关注和处理的事儿只有7~9个,再多就有些顾此失彼了; 然而一个再小的软件涉及到的方方面面很容易就超过这个心理容量,而且在头脑中推演数据处理流程时,人脑的堆栈深度是非常浅的(不是所有人都可以作到象棋/围棋运动员那样儿可以在头脑中对弈的!)-- 所以,在想象中,就非常有可能越想越乱,越想越不敢动手作了;
反而,先不管3721,趁着念头还鲜活,先将可以完成的部分快速变成可以运行的代码,一时无法想通的,变成空函式,伪类等等可以执行通过但是没有实际行为,仅仅标识出想法的有效代码来! 这样,下次的尝试,永远有可用的代码基础,每次我们就可以仅仅关注没有完成的部分,有可用的代码打底儿,每次尝试,都令我们真实的向目标进行了一步! 没有比这样由成就感累积而成的开发体验最舒服的了! 而且一直有真实不虚的代码可以运行和测试,比在头脑里空想要靠谱的多,安心的多;-)
Pythnoic 的感觉/体验/自信,就是鼓励大家不要顾虑自己是否对问题域有足够的知识积累己达到成竹在胸游刃有余的程度,直接去尝试! Python 脚本是轻松可得的,放弃,重构,从头再来,都不是难事儿;
如果总是期待自个儿非得达到一个完美的积累状态再去动手实际开发,结果可能就是一直陷入积累的状态无法自拔. 其实,技术的发展已不是日新月异的级别了,可以说是每时每刻都有新的技术/框架/模块/思想的出现,想积累到一定程度再动手,可能积累的东西已经过时了,要抢在自个儿的想法没有过时之前变成代码,可用的软件,释放出来,抢占先机,才可能在这一过程中,及时发现最新技术/代码/思想同步应用进来,令自个儿永不过期
所以,在Python 中,如何作? -- 不应该是个山门~ Python 隐密的规则/技巧/陷井相比C++/C#/JAVA 等等主流语言来说,实在太少了,而且知道与否对于我们完成系统,几乎没有影响; 作什么? -- 这才是不同Pythoner 间的最大差异,这就取决于想象力,观察力,对周围事物的敏感程度,是否"足够懒惰","没有耐心" 随时都想着将人工反复作的事儿,利用Python 形成工具来帮助自个儿完成 -- 进而形成爽快的工具/系统,成为其它有类似需求的人们的最爱

箴言凝练

上述箴言,是中国Python 行者们的部分最佳体验,总结而成的; 但是!其实!一切早已包含在Python自言中:

蠎之禅

图 atta1-2 Python 内置的哲学诗文

试译:

美丽好过丑陋,
浅显好过隐晦,
简单好过复合,
复合好过复杂,
扁平好过嵌套,
稀疏好过密集,
可读性最重要,
即使祭出实用性为理由,特例也不可违背这些规则.

不应默认包容所有错误,得由人明确的让它闭嘴!

面对太多的可能,不要尝试猜测;应该有一个(而且是唯一)直白的解决方法;
当然,找到这个方法不是件容易的事~谁叫你不是荷兰人呢?
但是！现在就做永远比不做要好;

若实现方案很难解释,那么它就不是一个好方案;反之也成立!

名称空间是个绝妙想法.

--立马来共同体验和增进这些吧!

-- by Tim Peters

汉译集注

访问地址: http://wiki.woodpecker.org.cn/moin/PythonZen
精巧地址: http://bit.ly/2h4f5T
这一内置在 Python 语言内部的小诗,集中的隽永的,将 Pythonic 思想,具象的表述了出来;但是影射太多的实践体验,不是所有人一时间都有感应能够理解的; 不过,可以确信,通过 Guido 老爹的认可,编译包含进Python 内核的东西,准没错!努力去体验吧!

附:我们的奋起宣言

每日至少抽一刻钟,解答邮件列表中初学者的问题, 
每周至少抽两小时,整理新学知识将体验发表/分享出去, 
    通过Blog/Wiki/MaiList/个人网站……
每旬至少抽四个小时, 来翻译自个儿喜爱的自由软件的文档, 
每月至少抽八小时, 快乐的编程, 推进自个儿的项目, 
每年至少参加一次, 自由软件的活动, 传播自由软件思想, 
    发展一名"自由人"……

只要我们每个人都坚持下去……
10年！就足以改变中国软件的整体风貌！

访问地址: http://wiki.woodpecker.org.cn/moin/RouseChina
精巧地址: http://bit.ly/DSYYt

Z跋

Z含义

Z 是最后一个E文字母;
Z 也是 "the last" 的缩写;
Z 还是发起人 Zoom.Quiet 的首字母
Z 又是"Zen"的首字母 ,,,
故而, Z跋,是最后的序文,是Zoom.Quiet个人想跟大家分享的图书之外的好things

免责

不过,首先是得免责:

尽管已经全力核查本书提供的信息/代码,但是仍无法保证完全没有瑕疪,而且技术世界的变化之快,也使得本书内容永远无法追赶上Python 的发展;
作为主创人员,俺得承认,错误一般都是 Zoom.Quiet 引入的,和其它人无关;

因为

  一切资料来自网络互动挖掘
  一切想法来自日常学习工作
  一切体悟来自各种沟通交流
  一切知识来自社区分享印证
  一切经验来自个人失败体验

动机

一个人如果力求完善自己,就会意识到,为此也必须同时完善他人. 一个人如果不关心他人的完善,自己便不可能完善. ~ 这是从一位教育研究者的个人Blog中看到的; {{{注意:: 北京师范大学庄秀丽老师; 访问地址: http://wiki.woodpecker.org.cn/moin/SkSig/ruminant/CompletSelf 精巧地址: http://bit.ly/15aDa }}} 在自学并进而喜爱上这门动态脚本语言的过程中,笔者深切的体验到这句话的内涵.

所以,一有成书的机会,立马纠集一批行者将真实的日常需求开发切身体验,组织起来,尝试使用一个个简单实用的代码片段来直觉的表现Python 的美好;

如果可以令读者认同并开始学习使用Python,善之善也;
如果现在没有感觉,但是得个印象－－Python 是个好学易用的工具性开发语言,亦之善也;
就算读者最后对Python 依然无视,可也开拓了视野,知道世界上不仅仅只有C++和JAVA语言,在今后的学习/工作中也开始关注不同与主流的更加敏捷的解决方案来,善也亦是;-)

所以本书不是教材,请不要试图通过本书成为合格的Python程序员,但是应该可以透过本书成为Python 的FANs

为什么要学习Python?

Ruby 不好嘛?Perl 不够用嘛?JAVA 还不够强大嘛?脚本语言运行的很慢吧?...

嗯嗯嗯,这些都可能是从未听说过Python 的读者的自然反应,毕竟从来没有在主流媒体中听到过这一语言哪;

好吧,本书决定不解答这类问题,只是期望当读者不知不觉中能够使用Python轻松的快速解决日常问题后,自个儿就可以给出个说法;-)

感谢

想找到本轻松,言之有物的技术入门书,是非常困难的事儿;反推之,想写成一本有趣并有用的入门书也一准是非常困难的一件事儿; 这本书之所以可以诞生,不是个人的意志决定的,是由Python 这门优秀语言自身的巨大吸引力凝聚而成的一大批中国Pythoner 共同意识促生的!
真的!这本书的完成,要感谢的太多了! 所以,专门进行认认真真的感谢:

人物

Guido van Rossum

后排穿"人生苦短我用Python" 字样T裇的帅大叔就是!
饮水不忘挖井人,如果没有 Guido 蟒爹一时兴起挖出的这泓灵泉,就没有这本书了;-)
- 让我们一齐感谢他！支持他！推广他的 "Simple is better" 世界观！

{{{注意:: 此T裇由哲思自由软件社区设计并发售: 访问地址:http://www.zeuux.org/community/fashion/fashion.cn.html 精巧地址:http://bit.ly/1QjO0K }}}

社区

啄木鸟Python社区

由来自五湖四海,为了一个共同的革命目标--推广Python在中国的学习和应用--聚集在一起的行者形成. 今天已经领导着超过5000人口的根据地,但是相对中国的程序员群体而言还不够,还需要更大些,才能真正促成全国软件界的思想解放.

访问地址: http://www.woodpecker.org.cn
在此基础上又成立了以 *PyUG 为名的一批区域性Python用户组,主要的活动形式是线上列表讨论,项目组织,以及线下的会课--在各个城市的Python 爱好者自发组织的一种线下进行的会面及技术课题交流活动--主要在北京和上海进行,从08年起珠三角/南昌/安徽/武汉各地也相继开展;比较活跃的有:
- CPyUG ~ 中文Python 用户组,是最早成立的邮件列表之一,因其开放自由热情的讨论风格逐渐形成最有人气的中文Python 技术讨论列表!
  - 访问地址: http://groups-beta.google.com/group/python-cn
  - 精巧地址: http://bit.ly/13BJb
- BPyUG ~ 北京Python 用户组,形成了良好的不定期会课制度,组织Python 行者们当面交流
- ZPyUG ~ 珠三角地区Python 用户组,由 Zoom.Quiet 南下发起,同样以会课为主要形式进行线下交流

CZUG.org

China Zope User Group ~ 中国Zope用户组;

访问地址: http://czug.org
Zope是一个开放源代码的Web应用平台.Plone是Zope上的一个用户友好、功能强大的开放源代码内容管理系统. Plone适合用作门户网站、企业内外网站、文档发布系统、协同群件工具,Plone也是一个应用开发平台. CZUG.org 里是Zope开源web应用服务器和Plone开源内容管理系统的中文技术社区.
几乎所有啄木鸟Python社区的早期成员都来自 CZUG.org,可想此社区的历史;

新浪网

新浪在全球范围内注册用户超过2.3亿,各种付费服务的常用用户超过4200万,日浏览量超过7亿多次,是中国大陆及全球华人社群中最受推崇的互联网品牌. 是啄木鸟社区的主要赞助商.

访问地址: http://sina.com.cn

行者

行者~中国Python 社区中的自称,这本书就是由众多华蟒行者们完成的(按照掺合图书工程的先后顺序排列简述贡献):

Zoom.Quiet

贡献: 图书创意/工程管理;实例故事;书/谢/Z序;部分PCS^{简述/PCS301~303/PCS304(引述及章节设计)/PCS400~404};附录引言;行者箴言;资源索引;后记故事;
工作: 珠海,金山软件股份有限公司,过程改进经理
经验: 2000年从Zope开始接触Python;主要进行Web应用/数据分析;组织以Trac为核心的敏捷开发支持平台;关注社会化学习和知识管理;学习PyPy并尝试和Erlang 结合ing;
环境:
- HP 520(GQ349AA)
- Ubuntu 8.04 - Hardy Heron
- Python 2.5.2 (r252:60911, Jun 21 2008, 09:47:06)

清风

贡献:PCS模块篇200~207,209~214;PCS300部分(回收的章节:Py常见任务处理);SVN到维基自动批量更新脚本;
工作:新浪网
经验:学习使用Python 5年左右.目前是某个Python+Django项目的leader
环境:
- iBook G4
- Mac OS X
- Python 2.4.3

XYB

贡献:(回收章节:实例CookBook索引)
工作: 豆瓣，软件工程师
经验: 2000年接触Python，用它来写系统维护脚本；2003年开始以Python开发谋生。
环境:
- Mac Book Pro
- OS X 10.5
- Python 2.5

黄毅

贡献: PCS300;PCS304.Django~最流行框架快速体验教程+深入探索Python的Web开发;
工作：腾讯，程序员，主要是web前后台。
经验：2003年末，大三的时候开始接触Python，通过 Python 学习到很多很多好东西，在大学期间也用Python完成了几个web/gui的项目赚点零花钱很可惜目前工作跟Python没有什么关系。
环境：thinkpad x61; ubuntu8.10; Python2.5.2

张沈鹏

贡献: (回收章节:Py2.5 绝对简明手册)
工作: 北京,豆瓣,程序员
经验: 从一个抓网页的小程序开始结识Python，关注Python在互联网方面的应用，并喜欢用Boost:Python给Python写扩展。常在博客上记录一些Python学习心得,访问地址: http://zsp.javaeye.com/ (路过打酱油的,曾尝试写一个章节,因种种原因最终未完成.但Zoom.Quiet大人居然把我列在这里,博文视点的编辑还亲自打电话来,让我很汗颜...)
环境: Dell INSPIRON 2200 + WindowsXP + SSH远程登陆Gentoo编程

盛艳(Liz)

贡献: 实例故事练习题设计/附录:故事练习解答;PCS环境篇/语法篇(除PCS114 FP初体验);术语索引;Py资源索引等等文字校对;
工作: 扬州大学信息学院计算机系研二学生,主研究方向是数据挖掘,概念格.
经验: 从2007年10月开始学习Python,非常喜欢她的风格,目前还在不断深入学习中.主要进行Web应用开发和编写些小脚本,非常高兴能够掺合"可爱的Python"的编写,以后会继续努力,为社区贡献一份力量.
环境: 当前日常工作环境(软硬件)
- 方正尊越A360
- Ubuntu 8.04
- Python 2.5.2

刘鑫

贡献: PCS114 FP初体验;
工作: 珠海,金山软件股份有限公司,软件架构师
经验: 从2002年接触Python,现在使用Python搭建中间服务器，曾经尝试在己有的游戏服务器中嵌入Python进行功能扩展。也一直使用Python编写各种开发过程中所需的辅助工具。
环境:
- HP 520(GQ349AA)/组装PC(AMD2300+/1G)
- Ubuntu 8.04 - Hardy Heron
- Python 2.5.2 (r252:60911, Jun 21 2008, 09:47:06)

Limodou

贡献: PCS208;PCS304.UliWeb ~ 关注平衡感的自制框架;
工作: 北京,程序员;
经验: 2000看开始学Python，从此之后Python成为我掌握最熟练，最喜欢的语言了。曾担任Linuxforum.net的Python版版主。CPyUG(Chinese Python User Group，2005年创建)创始人之一，也是Python-cn邮件列表(2004年创建，目前为CPyUG的主力邮件列表)创建人。
- 喜欢编程，喜欢分享，喜欢与人交流，喜欢技术博客，到目前为计，已经写了近1000篇左右Blog。在CPyUG的多次会课中进行心得的分享。
- 参与过多项开源项目，并于2004年开始开发NewEdit，后改名为UliPad，此作品曾参加第一届中国开源软件竞赛银奖。还自主开发过其它小型开源项目。目前Python仍然是业余爱好，但是会一直坚持下去。
环境:
- 主要是在Windows下，有时在Ubuntu下。
- Python 2.4+

沈崴

贡献: PCS304.Eurasia ~ 关注高性能的原创框架
工作: 上海, 高级架构师
经验: 1993 年的程序员, 2001 年初完全转到 Python。
环境:
- 硬件: IBM Thinkpad (数个型号)、EeePC、AMD64、MIPSEL 等机型
- 系统: Debian 系 (包括 Ubuntu 704-810)、BSD 系、OpenWRT 等操作系统, 使用 Stackless Python 2.5.2

洪强宁/QiangningHong/hongqn

贡献：PCS304.Quxiote ~ 豆瓣动力核心
工作：北京豆瓣互动科技有限公司，技术负责人
经验：C背景程序员，2002年开始接触Python，2004年开始完全使用Python工作。2006年加入豆瓣以来，用Python作为网站开发的利器，得心应手，十分快活。
环境：
- 桌面：
  - MacBook Pro 133
  - Mac OS X 10.5.5
  - Python 2.5.2 (r252:60911, Sep 30 2008, 12:02:56)
- 服务器：
  - 自攒AMD64服务器二十余台

潘俊勇

贡献: PCS304.Zope ~ 超浑厚框架
工作: 上海润普广州公司(zopen.cn)技术总监
经验: 2002年开始折腾zope至今，李木头(Limodou)当年就是俺崇拜的对象，俺专一一点就这个优点。在CZUG.org 中提供了Zope/Plone上的全套中文/阴历支持包；
环境:
- Ubuntu 8.04 - Hardy Heron
- Python 2.5.2

特别要指出的是:核心撰写团队成员大多使用非 Windows 操作系统作为日常工作环境的,所以,如果在截屏或是代码运行结果上和你在本地的尝试结果不同时不要惊讶,应该惊喜--Python 是跨平台的! 不论大家工作/生活在什么操作系统中,都可以友好快捷的協助完成你想要的功能!

校对

在图书工程的最后时刻哲思社区的西安邮电学院成员,主动担当了技术校对,并高效及时的进行了3遍复查,为保证图书质量作出了重大贡献,特此感谢:

孔建军(kongove)

贡献: 负责审校团队工作协调;完成CDays\KDays\模块篇等章节的审校;PCS215/216;
工作: 就读于西安邮电学院，网络工程专业，热衷于Web应用和系统开发
经验: 接触Python不到一年，做过一些网络编程和GUI程序，目前正在关注哲思系统的开发
环境:
- 组装AMD 2800+/1.5G内存台式机
- Ubuntu 7.10 - Gutsy Gibbon
- Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40)

高辉(aurthmyth)

贡献: 实例故事练习题设计和解答，环境篇\语法篇等审校;PCS217;
工作: 就读于西安邮电学院计算机系
经验:接触Python不到一年,正在深入学习中，很惊叹她的高效和风格.非常幸运地参与"可爱的Python"的校对,为Python在国内的推广贡献一份力量.
环境: 当前日常工作环境
- Ubuntu 7.04 - Feisty Fawn
- Python 2.5.2

还有...

更多的感谢

感谢博文视点(武汉)出版社的编辑们,他们前赴后继的鼓励我们,不断的鞭策我们坚持不懈的撰写这部小书,要没有他们的奋斗,这本书可能还得等几年!
感谢CPyUG/BPyUG/ZPyUG等等相关列表中不知名的朋友们的意见和鼓励,本书作为一个开放图书工程,没有他们的参与是无法成功的!

后记

满纸轻松事儿,一把辛酸泪

以 Zoom.Quiet 个人的视角分享一下如何通过靠谱的社区撰写技术图书的经验;-)

{{{注意:: 感言: "写本有用的书,给那些不知道Python 的人,或是想学习Python 的人!"

从来没有想到这个忽然间的念头能成为现实!更加没有想到的是成为现实的过程竟然如此简单和艰难,,,

}}}

社区!

那些风花雪夜

2007.2.1 在邮件列表中一个小白苦恼的心声
访问地址: http://wiki.woodpecker.org.cn/moin/ObpBroadview/2007-02-01
精巧地址: http://bit.ly/UJRm 激发出了行者们成书的狂想,经过讨论,定名,定内容,定大纲,《可爱的Python》就在社区活跃分子的相互鼓励中开始了:
建立维基主页: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython
在会课中专题讨论,建立工程环境,建立专用邮件列表,建立进度讨论IRC聊天室,建立项目管理网站...
一点点,一滴滴,一页页,就积累起来了... 本来以为是可以快乐的轻松组织完成,然后在圈子内部发布就流传就好的,没有想到博文注意到了我们的想法...

撰写,

因为一直在邮件列表中混,知道大家想法的舟编辑主动找到我,并立即由副总出面在北京宴请当时的主创人员,确立了图书的基本思路和网络/图书双版权发布的基调,将社区视作独立的单位进行协商,一下子,游击队变成了正规军...这感觉,怎么说呢?...
蝙蝠侠说:"能力越大，责任越大"
我们则是:"期望越大，压力越大" 我们期望写出:第一本中文Python 原创图书!第一本原创入门Pythonq图书!第一本原创畅销Python 技术图书...
但是！现实只能是 快乐并痛苦着:
- 一想到这些文字是要付梓成书的,就不敢象在邮件列表中那般痛快的表白
- 但是又必须得将快乐的Pythonic体验原味传达给读者,这又得表白出痛快...
  林林总总,在对自个儿对编辑对文字对代码对截屏对章节等等纷繁的矛盾中努力的码字的同时,还要完成各种工作任务,挣来口粮,才能支持自个儿继续 快乐并痛苦着...甚至于在不断的"煎熬"中总结出:

如何组织在线图书工程

态度决定一切!~兴趣才是网络团队的最稳定动力

分布式在线团队的构成,要求绝对的臭味相投~最好是一个稳固的社区中的老朋友们
选题的有趣和有用,更是图书成功的绝对必要条件~这是聚集起团队的充分先决条件

图书也是工程!~在资源方面,要大力使用基于互联网的各种免费服务

就按照软件工程的方式来组织大家是习惯且有效的!
网络中的对应免费服务其实是齐全的:
- 版本控制~ code.google 等等免费工程管理服务
- 日常沟通~ groups.google 等等免费列表服务
- 知识积累~ wikidot.com 等等免费维基服务
- 实时讨论~ IRC/GTalk 等等实时沟通服务
- 项目管理~ Everydo.com 等等免费管理服务
  - 进度计划 ~ google.com/calendar 等等在线日历服务

没有规矩不成方圆~有了团队,一直要组织和管理的

定期的IRC会议非常有助于鼓励士气,協商进度,调配任务
一定要有热心的核心人物来協調和决定所有变更(前期应该是发起人,后期由编辑分担比较合理)
200页以内的小书,团队有多少人是没有关系的,因为任何偏差都可以快速修订
大于300页的图书,写作团队应该控制在5人以内,否则,沟通将是没有尽头的事儿了:
- 合理的团队构成:
  - 2~5人的核心撰写
  - 4~15 人的技术校对
  - 尽可能多的关注/宣传成员
  - 1~2 名稳定的责任编辑
绝对绝对绝对不能使用任何 Office 格式文档来进行交互组织!这是无法进行版本控制的二进制专有格式物件!
- 结构化文本/纯文本/HTML/TeX 文本等等都是可以良好的通过版本控制环境进行充分管理的文本格式!一定要坚持使用!
- 即使在交付前统一倒入 Word 之流来统计字数,也要坚持使用!

出版是不比撰写轻松的复杂工程!~理解出版社的工作方式后,才可能有良好的配合

国家法令法规,行业潜则,市场反应,目标人群,流行模式,排版风格... 都是出版方面的专业知识,不是软件行业行者可以轻易体悟的到的!
有固定的编辑追随进行田间管理是种幸福,否则是很郁闷的事儿~你得将相同的话,不断的反复说给不同的责编;
不使用 M$ Office 的编辑在中国是神话! 但是,技术社区撰写,本质上不应该使用 Office 工具来进行...所以,这个矛盾需要有大智慧和大勇力的编辑配合完成!

经验

沟通:沟通比一切都重要,让所有人及时知道所有事儿,是分布式在线社区化写作的最基础原则!

因为社区式工程,无法象公司式组织,人员/时间/场地是固定的,所以,面对不断流动的团队成员,作为图书工程主持人,我发布的维基文章/列表邮件/IRC聊天沟通/MSN協商/会课谈话记要等等沟通用文字总量比图书本身的内容要多10倍有余!深深感受到:
- 沟通需要代价,改进由我作起!~想进行有效图书工程沟通得注意:
  - 自个儿首先得有谱,有整体的图书内容思路,想法,设计,原则,规范,,,
  - 有统一的文档发布,将以上的整体设想,及时发布成在线文档,有助于全体及时理解
  - 确定固定时间段来沟通,在同一时刻大家同时来解读相同的内容比较有效率,因为人的注意力不是那么简单的可以随时集中在某件事儿的,在约定的时间,大家相互激励,比较容易专注
  - 对于沟通的结论,最好统一格式统一地点统一发布!以便形成积累,给后来加入的新人一个有时间顺序的学习资料集
资源:
- 用于工程的各种资源/工具,最好是基于互联网的,这样可以吸收最大范围内的力量,有网络,就有可能!
法律:
- 一定要有合同! 在有社区背景的图书工程中,出版社对版权/署名的理解是不同的,一定要事先沟通好,否则,会有解释不清的麻烦，对社区贡献也是个隐患
签定合同时,最好授权给有法人资格的社区出面交涉,以便获得出版社的重视并获得更好的条件...

以上,期望给有社区背景的读者一点启发,可以尝试聚集社区知识原创技术图书,为中国的软件事业作出自个儿的推动!

摧生,,,

图书得以付印,从始至终,编辑的作用就象耐心而专业的摧生婆,没有他们的帮助,成书是无法想象的,,,

毕竟团队化网络社区群体写作,存在沟通不直接,大家的写作时间无法保证等等问题,和自由软件不同,软件的版本发布时机是社区主动把握的,而签定了合同的图书工程,是不能轻易跳票的...
- 所以,最令人感动的就是那些"摧生婆"们了:

福编

是最早关注了社区动向,并将其作为一个图书选题来进行主动沟通的"摧生婆" 正是他的促动,从而令图书正式的成为博文的图书立项,开始了这次成书之旅,可惜,从来不是本书的责编,而且不久离开了博文,没能看到图书成型...

舟编

是最早的责编,因为同是程序员出身,是最明白技术的编辑,在内容方面给出了非常多的建议,很大程度上令这本内容和目标都很另类的技术入门图书被出版社接受,舟编居功致伟! 只是不久也因为个人原因主动离开了博文,没能看到图书完成...

俊编

是临危受命的责编,虽然跟书的时间不长,但是非常耐心的全盘接受并理解了我们的意图!尽而也非常开放的共同使用我们建议的网络服务进行编辑事务的透明沟通...

士编

是后期一位责编,跟的时间不是最长的,但却是跟的最紧的,在他的任期,图书合同用哲思自由软件社区的身份签定了,版权的分离也成功达成了理解,而且美术编辑的跟进,也是赵编从中协调艰难的共同摸索出了全新的模型...

绣编

是最后一位责编,是位非常有经验而且专业的老编辑,以最快的速度把握住了图书的特质以及问题所在,紧密而不紧迫的持续不断的将图书的进度一直保持在可控状态中,并最终完成了交付!

Yeka

是所有责编的后盾!作为博文的领导,在多如牛毛的新技术中关注到Python 在中国的挣扎,而且在如此漫长的时间里一直不放弃散漫的社区式撰写,一直坚持要将本书作出来,实在不是简单的敬佩可以表达大家的谢意的!!!

细细回顾一下在不到两年的时间里,竟然先后有4名责编,数名文字/美术/业务编辑,以及一位出版社总裁关注和支持过本书,实在是非常非常不可思意的事儿!

成书?!

Biu~~的一声,从吃过接风宴,开始写,到现在一下子两年了,这其间,俺从北京跳到了珠海,完成了从过程改进专员到过程改进经理的飞跃,同时期,还利用组织 "可爱的Python" 一书的经验,组织了另外两本Python 技术图书部分翻译/校对和另外一整本原文图书的快速翻译...
时间,真的是在不知不觉中飞速消逝的! 真的非常敬佩博文出版社的执着,所以,冲刺!不断的;每次,都在社区的邮件列表中倡议; 虽然摇旗声援的不少，但是真正投入到撰写的也着实不多，然而,书到底是在不断的完善中，可是，随着完成度的增长，也越来越对内容，有所挑剔，总是感觉应该有更加好的表达方式...
另外一方面,Python 也在不断的进步,两年里版本增长了三次,对图书的内容也更加的惶恐:"是足够有趣/有用嘛?会有人买来看嘛?"
幸好,编辑一直在肯定的说:"这样整一定成的!" 但是什么时候算是真正的成了呢?
突然的有一天,在不断的相互督促中,焦虑中,突然发现,所有章节都完备了,可以了,成了?!... 这种意外的巨大的惊喜,不比那日意识到自个儿在使用 Pythonic 来编程时顿悟般的快乐...
"发表是最好的记忆" ~ 台湾候捷老师的感想,也是我们的感想,一直坚持要纠集尽可能多的行者们来共同撰写,就是想分享这最好的记忆;
但是成书的那一刻,如的确就是我们必须忘记这本书,向下本书进发的时候! 因为成了的书已经属于读者了!也属于社区,将在网络中长久的由读者们修订/增补/完善下去!

故事

收集追忆成故事作为纪念

夫复言无Python入门之佳作

福编者说

原始版本: http://docs.google.com/Doc?id=ah9sz7kfxfhz_131hpn9gvgk
精巧地址: http://bit.ly/Ktmf

夫复言无Python入门之佳作

前247年，李斯跪别恩师荀老夫子及好友韩非，只身向西，奔赴秦国，只为实现己之伟大理想。辗转艰辛，蒙贵人郑国之荫，终成秦相国吕不韦3000门人之一。此去无多日，李斯才华尽显，遂被吕(不韦)拜为上宾。
为安息同僚（3000门人），李斯以四大公子为前鉴，说服吕不韦召3000门人合力著书，历时七载，终成《吕氏春秋》，实为亘古未有之壮观。此工程之浩大，为万众瞩目，真乃秦600余年划时代之大事。书成之后，吕（不韦）大摆宴席，广邀百官，共襄盛事。酒过三巡，始于席间传阅《吕氏春秋》，百官们管窥锥指，难尽全貌，无不为之称奇，以为万世之盛举。然众人皆贺之时，唯李斯（此时李斯已贵为客卿）不贺相国。众人无不惊讶，吕(相国)亦尴尬难当，风景大煞。李斯见状，慢道：”李斯不贺相国，只因《吕氏春秋》历时七载，一朝告竣，非相国之喜——实为大秦之喜也。大秦得此书足堪传诸久远，子孙受益······，李斯贺我大秦，再贺后世学子······“
时六国兵强不如秦，法制不如秦，民富不如秦，而素以文化蔑秦，笑秦为弃礼仪而上首功之国。自《吕氏春秋》著成，驰传诸侯，广布天下，六国不复言。
公元2006年，吾入行未久，因工作之需，终日闲游于CPyUG，幸识得周老夫子。是时，Python之作寥寥，而从之者甚众。吾遂生请周老夫子著书之念。待告知周老夫子吾之所想，岂料二人皆有同感，只叹相议恨晚。然此后时日，吾因他事，未能续与周老夫子议书，抱憾至今。
其间，周老夫子行吕（不韦）之事，履吕（相国）之职，召CPyUG众人合力著书，两载后终成《可爱的Python》。著述此书工程之浩大，若论之功，周老夫子当居首也。书成之日，众人皆来贺，贺周老夫子，贺CPyUG之同仁，贺莘莘Python学子······
过往，众人皆怨无Python入门之佳作，而今《可爱的Python》不负众望而出，万人空巷之盛景可期矣！是也乎？

盛艳

从讨厌到享受~ 最后阶段加入的MM感言

英语中的Python是一种动物——大蟒蛇，我一直都非常讨厌、害怕这类生物。
而在计算机世界中，Python是一种非常优秀的语言。对于我个人而言，自从师兄那儿听说，到学习Python基础，再到现在不断的实际运用，这大半年时间的接触，使我一步又一步的陷入到了Python的精彩世界。
期间也经历了很多的第一次，第一次加入社区，第一次认识到自己的幼稚，第一次实际体会到团结合作的力量，第一次走出学校的小小世界，第一次参与这种方式的交流与合作...种种都让我受益匪浅，再一次深刻体会到Python的可爱之处。
也是由于加入CPyUG，认识了各位牛人大哥们，认识了主创作者Zoom.Quiet，之后加入OpenBookProject，参与LovelyPython计划。由于是第一次的这种方式的合作，很多规则，注意事项都不懂，而且加上书中相当一部分内容还是不熟悉，比如说CDays中的线程，发布及注视规范，KDays中整个KarriGell未曾接触过，虽然不懂但只能不断适应和学习，经过不断的鼓励和改进完善顺利完成练习设计。
之后参与校验，学会提交issue，接着又摻和一部分PCS的书写，这又让我更完善的学习Python基础，同时也看到了前辈们的很多优秀代码，另外加入啄木鸟社区，知道了什么是wiki，如何使用等等。
一点一滴的参与其中，体会着苦与乐，一句话，非常值得。也非常清楚的记得当初Zoom.Quiet的一次又一次的鼓励和提醒我：try and enjoy！最终坚持到现在，学到非常多的知识，更主要学到的是一种做事的态度。所以非常感谢有这个机会让我参与，让我在枯燥的学术生涯中不断体会到Python世界的无限精彩！

孔建军

~社区新人感言

2008年9月16日下午，收到哲思社区徐继哲大哥的一份电子邮件，希望我能组建一个五人的审校团队对《Lovely Python》一书进行技术审校，虽然Python学习了快一年了，但来做一本书的审校确实心里没底。我和高辉、张斌沟通后立马确认接收审校任务，后来潘猛、龚民、冯立强也参与了进来。龚民由于工作繁忙没能参与多少具体审校，但也解答了我们很多关于审校流程的问题。刚开始参与审校，工具的使用和流程都不是很清楚，多亏以前王聪他们参与过《Python源码剖析》一书，中间我们犯了很多错误，Issue主题规范问题、重复提交错误、错误描述不准确、wiki更新问题、沟通问题～～后来慢慢适应了。我们根据书本内容和一些具体情况，准备进行三次审校（初审、对换审校、最终审校），并把任务明确到wiki上面，方便与编辑等沟通交流。还有Zoom.Quiet做事很高度认真、负责，值得学习。
审校此书感受最深的就是团队的沟通和交流，没有这些是没法异地合作的。还有相互之间的工作协调，这样才能事半功倍。参与审校也是对Python的重新学习过程，弥补了很多知识上的漏洞。也再次感受到了Python语言的魅力和精髓。审校过程中，框架篇也在不断更新，调整比较大，感觉在审校的同时没有给书本创作提供太多建议，这也与自身能力有关，以后再努力吧。
这次参与审校算是以哲思成员的身份，算是给社区做小贡献。希望有更多的人参与到社区当中，体验共享、奉献的快乐。
在参与审校的同时，也用Python编写了一些实用的程序，用KarriGell框架做了一个自动生成配置文件的工具，用于我们西邮Linux兴趣小组实验室的实名上网。还有一个用wxPython开发的图形界面的拼音查询工具，我把她放到了facebook上，也得到了很多人陌生人的改进建议，看来还是开放源码好还有一个调用telnetlib库实现的高速端口扫描工具。很是兴奋～～！有同学都叫我“高产作家”了，呵呵～玩笑;)
总的来说收获都很大，Happy Hacking

最后的最后

感谢老婆--丸子--要不是她容忍我最后的几个月每日都得下零点的艰苦修订,这本书很可能继续难产! 感谢她身怀六甲也认劳认怨的照顾我的生活,令我可以全力完成最后的冲刺!

请允许我将此书在奉献给全球华人程序员之余, 搭车送给可爱的老婆和更加可爱的马上到来的金牛宝宝~盼盼!