Differences between revisions 2 and 32 (spanning 30 versions)
Revision 2 as of 2007-11-03 15:21:24
Size: 3128
Editor: ZoomQuiet
Comment:
Revision 32 as of 2009-12-25 07:09:18
Size: 31056
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
#pragma section-numbers on #acl WoodpeckerAdminGroup:read,write,delete,revert LovPyBookGroup:read,write,delete,revert All:
#pragma section-numbers off
Line 4: Line 5:
||'''status'''|| 草稿 || ZoomQuiet || 完成度~10%;初始化内容结构,期待Limodou 上架跟进 ||


[[
TableOfContents]]

= 箴言 =

||'''status'''|| 校对 || ZoomQuiet || 完成度~101%; 根据其它章节增补而修订微小文字||

<<TableOfContents>>
##startInc


= 行者箴言 =
Line 11: Line 13:
''' 光说不练徦把式,光练不说傻把式! '''
 * 汇集本书散落在各处的程序员 箴句 细说来由

== 用之,不学! ==
 * '''Use it! do not learnning'''
  * 来自 [:ObpLovelyPython/PyDay-5:PyDay-5]
  
=== 背景故事 ===
''' 光说不练徦把式, 光练不说傻把式! '''~ 所以,汇集散落在书中各处的行者"箴言"细说来由;-)
 * 每节使用固定的述说模式:
  1. 给出E文定义
  1. 给出实例故事的出处
  1. 讲述产生的背景
  1. 展开解说相关的体验,给出进一步的阅读资料

== 少学,多用! ==
##用之,不学!
`Enjoy it! don't Learnning`
  * 来自 [[ObpLovelyPython/CDay-5|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 是自足的'''
  * 来自 [[ObpLovelyPython/CDay-4|CDay -4 可用的首个Python脚本]]
 * '''你能够碰到的问题,99%的情况下其它人已经遇到过了,所以,最佳的解决方式就是找到那段别人解决相似问题的代码!'''
  * 来自 [[ObpLovelyPython/CDay-1|CDay -1 中文处理完成功能的实用化]]

 背景::
  图 atta1-1 漫画电池内置
  * {{attachment:atta1-1.jpg}}
  * `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::
  {{attachment:cpan.jpg}}
  * 访问地址: 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!`
 * '''不断的否定自己,但是要坚持最初的妄想'''^ --不论战术上如何变化,千万不要忘记战略目标^
  * 来自 [[ObpLovelyPython/CDay-3|CDay -3 通过函式进行功能化]]

 背景::
  '''"[编程杂谈]编程就象练书法"'''
  * 访问地址: http://blog.donews.com/limodou/archive/2006/04/02/808281.aspx
  * 精巧地址: http://bit.ly/3TGsCt
  * 还是来自 Limodou 的体验分享,文中指出:编程应该象练毛笔字--只求耕耘,不求收获;在不断的反复修订中积累经验和思路,才会有那么一天一切豁然开朗的!
 
 解说::
  这是 Pythonic 重构心态的劝戒;
  * 在[[ObpLovelyPython/PCS404|PCS404 代码重构浅说]] 中有相关的简介;
  * 这里特别指出的: 很多时候最初那一瞬间的设想/构思/概念 可能就是整个软件/项目/工程的最核心亮点,千万不要在代码展开编写后,逐渐被各种意外问题所迷惑,忘记了最初那个自个儿真正想完成的功能!
  * 不断的否定自己,意思是否定自个儿现在的代码实现方式,而不是功能,并且,在重构/增补代码/功能时,有一个基础指标要守住 -- 确保现有所有功能是运行正常的,是可用的,通过测试的!
  

== 发布,持续! ==
`Keep realese,Keep publish!`
 * '''发布!为了全人类!'''因为'''一个人如果力求完善自己, 他就会看到, 为此也必须同时完善他人. 一个人如果不关心别人的完善, 自己便不可能完善. '''
 * 发布好象不是通告一嗓子就好的事儿 ~ '''分分分!学生的命根! 文档,文档,文档!软件的颜面!'''
  * 来自 [[ObpLovelyPython/CDay0|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. 对内: 为自己,通过发布和整理,以及注释更新,令开发者自身,加深对代码的理解,并及时进行再次重构迭代;
   1. 对外: 为公众,通过发布和宣传,让其它人获知软件的状态,令有缘人可以及时得到我们的代码,并通过清晰易懂的代码建立起沟通渠道,可以就相似问题域的解决进行互通有无,令好代码传播出去,延长生命周期的同时,也因为及时丰富的使用反馈,令自个儿的代码可以进一步得到增补!
   

== 能用,再修! ==
##先用,再修, -> 先動, 再修!
`Run! before Enhancement`
 * '''没有完美的软件!够用并且容易使用的软件已经算是完美的了'''
  * 来自 [[ObpLovelyPython/CDay-2|CDay -2 利用文本文件完成核心功能]]
 * '''没有最好,只有更合理!'''
  * 来自 [[ObpLovelyPython/CDay1|CDay +1 首次重构优化数据结构]]


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


== 寻找吧!不要先想着创造 ==
 * '''寻找吧!不要先想着创造--Python 是自足的'''
  * 来自 [:ObpLovelyPython/PyDay-4:PyDay-4]
  
=== 背景故事 ===
以动手实践为荣 , 以只看不练为耻;
以打印日志为荣 , 以单步跟踪为耻;
以空格缩进为荣 , 以制表缩进为耻;
以单元测试为荣 , 以人工测试为耻;

以模块复用为荣 , 以复制粘贴为耻;
以多态应用为荣 , 以分支判断为耻;
以Pythonic为荣, 以冗余拖沓为耻;
以总结分享为荣 , 以跪求其解为耻;
}}}
  * 这其中有很多Python的方言性经验,如果没有使用过Python 的读者,可能无从想象,笔者特此对其中一个要点进行简述,其它的就得读者自行在实践中印证进而和鸣了:-)
   * `以空格缩进为荣 , 以制表缩进为耻;` ~ 这是因为Python 是世界上唯一成功的将代码排版和语法结构融合的语言!例如:{{{#!python
def formatCDinfo(root,dirs,files):
    export = "\n"+root+"\n"
    for d in dirs:
        export+= "-d "+root+_smartcode(d)+"\n"
    for f in files:
        export+= "-f %s %s \n" % (root,_smartcode(f))
    export+= "="*70
    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!`
  * '''网站软件化绝对不是空话!''' 来自 [[ObpLovelyPython/CDay2|CDay +2 用户界面友好化]]

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

 解说::
  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 才是王道!'''来自 [[ObpLovelyPython/CDay3|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 的唯一界限'''
  来自 [[ObpLovelyPython/CDayN|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 内置的哲学诗文

{{attachment:atta1-2.png}}

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

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

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

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

名称空间是个绝妙想法.

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

-- by Tim Peters
}}}

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

== 不断的否定自己,但是要坚持最初的妄想 ==
 * '''不断的否定自己,但是要坚持最初的妄想'''^ --不论战术上如何变化,千万不要忘记战略目标^
  * 来自 [:ObpLovelyPython/PyDay-3:PyDay-3]
  * 有关重构的心态经验
  
=== 背景故事 ===
{{{
#!python
Python code
}}}


== 没有完美的软件! ==
 * ''',够用并且容易使用的软件已经算是完美的了'''
  * 来自 [:ObpLovelyPython/PyDay-2:PyDay-2]
  * 有关需求控制经验
  
=== 背景故事 ===
{{{
#!python
Python code
}}}

== 你能够碰到的问题,99%的情况下其它人已经遇到过了 ==
 * ''',所以,最佳的解决方式就是找到那段别人解决相似问题的代码!'''
  * 来自 [:ObpLovelyPython/PyDay-1:PyDay-1]
  * 有关资源利用经验
    
=== 背景故事 ===
{{{
#!python
Python code
}}}

== 发布!为了全人类! ==
 * 因为'''一个人如果力求完善自己,他就会看到,为此也必须同时完善他人。一个人如果不关心别人的完善,自己便不可能完善。'''
  * 来自 [:ObpLovelyPython/PyDay-0:PyDay-0]
  * 有关社区体验经验

=== 发布好象不是通告一嗓子就好的事儿 =
 * '''分分分!学生的命根! 文档,文档,文档!软件的颜面!'''
  * 文档化开发体验
 
=== 背景故事 ===
{{{
#!python
Python code
}}}


== 没有最好,只有更合理! ==
  * 来自 [:ObpLovelyPython/PyDay1:PyDay+1]
  * 有关重构的进一步经验
    
=== 背景故事 ===
{{{
#!python
Python code
}}}

== 网站软件化绝对不是空话! ==
  * 来自 [:ObpLovelyPython/PyDay2:PyDay+2]
  * 有关桌面软件开发趋势体验
    
=== 背景故事 ===
{{{
#!python
Python code
}}}

== KISS 才是王道! ==
  * 来自 [:ObpLovelyPython/PyDay3:PyDay+3]
  * 有关软件设计经验
    
=== 背景故事 ===
{{{
#!python
Python code
}}}

== 想象力才是 Pythoner 的唯一界限 ==
  * 来自 [:ObpLovelyPython/PyDayN:PyDay+1]
  * 有关资源深度利用经验~ 社区,交流,搜索,知识管理策略 ...
    
=== 背景故事 ===
{{{
#!python
Python code
}}}


== 小结 ==
## 总体语法等等叙述,注意给出相关知识的阅读指导


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

只要我们每个人都坚持下去……
10年!就足以改变中国软件的整体风貌!
}}}
 * 访问地址: http://wiki.woodpecker.org.cn/moin/RouseChina
 * 精巧地址: http://bit.ly/DSYYt

##endInc
Line 132: Line 392:
::-- ZoomQuiet [[[DateTime(2007-11-03T11:46:56Z)]]]
[[PageComment2]]
::-- ZoomQuiet [<<DateTime(2007-11-03T11:46:56Z)>>]
<<PageComment2>>

status

校对

ZoomQuiet

完成度~101%; 根据其它章节增补而修订微小文字

行者箴言

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

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

少学,多用!

Enjoy it! don't Learnning

背景
解说
  • 这是本书的核心本愿!
  • 在 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 是自足的

  • 你能够碰到的问题,99%的情况下其它人已经遇到过了,所以,最佳的解决方式就是找到那段别人解决相似问题的代码!

  • 背景
    解说
    • 有自由/开源软件的世界里,解决问题的最快捷途径绝对不是自个儿堆代码解决!
    • 嗯嗯嗯,当然的出于"程序员"的自尊,以及关键性的经济条件,一般也不允许去买软件来解决问题;-)
    • Python 使用开源许可证:
    • 所以,各种基于Python 的项目一般都乐于公开源代码;
    • 加之,Python 因为有丰富的C语言接口,实际上也是种方便的胶水语言--可以平滑的直接或是通过接口模块和各种开发语言協同完成任务!
    • 故而,用Python 来解决问题,基本上不用自个儿冥思苦想整出代码来,只要用心先搜索一下根据问题域的解决方案设想,广泛调研一下,基本都可以找到一个以上的支持模块或是软件--当然是Python 写的,下载来,稍微配置或是定制/修改一下就好! 作为Pythoner ,应该有这种自觉和自信!
    • 不过,Python 的各种支持模块/软件都是各行其是的分散在网络中,并没有象Perl 的CPAN 那样形成统一聚集地;
    • 当前,比较集中的 Python 作品索引中心有:
    CPAN
    • cpan.jpg

    • 访问地址: 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!

  • 不断的否定自己,但是要坚持最初的妄想 --不论战术上如何变化,千万不要忘记战略目标

  • 背景
    解说
    • 这是 Pythonic 重构心态的劝戒;
    • PCS404 代码重构浅说 中有相关的简介;

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

发布,持续!

Keep realese,Keep publish!

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

  • 发布好象不是通告一嗓子就好的事儿 ~ 分分分!学生的命根! 文档,文档,文档!软件的颜面!

  • 背景
    • 一个人如果力求完善自己, 他就会看到, 为此也必须同时完善他人. 一个人如果不关心别人的完善, 自己便不可能完善. 源自 庄秀丽老师(任教于北京师范大学 教育技术学院)曾经的一篇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

  • 没有完美的软件!够用并且容易使用的软件已经算是完美的了

  • 没有最好,只有更合理!

  • 背景
    • "东拉西扯:谁需要更复杂的软件 - 对牛乱弹琴"

    • 访问地址: http://blog.donews.com/keso/archive/2005/11/18/630753.aspx

    • 精巧地址: http://bit.ly/4d8BSN

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

      unix-art.jpg

    解说

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

以模块复用为荣 , 以复制粘贴为耻;
以多态应用为荣 , 以分支判断为耻;
以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也是适用的)"
    • 只是想着解决问题,从来不主动尝试理解问题搜寻化解方法;只是想从社区获得代码,从来不想着分享自个儿的体验;持这种态度将无法真正体验到Python 的美好! 行者们的倡导是:

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

网站.软件.

Site is Software!

背景
  • SaaS(Software as a Service,软件作为服务, 或称为软件即服务)是应用软件的一种销售方式, 客户按使用时间或使用量付费. 这些应用软件通常是在企业管理软件领域, 并通过互联网来使用.
  • 它是目前一种新型软件服务形式, 是从 ASP(ApplicationServiceProvider, 应用服务提供商)模式演变而来, 是一种通过Internet提供软件的模式. 用户不用再购买软件, 而改用向提供商租用基于Web的软件, 来管理企业经营活动, 且无需对软件进行维护, 服务提供商会全权管理和维护软件.

  • 对企业来说, SaaS的优点在于:
  • 从技术方面来看:企业无需再配备IT方面的专业技术人员, 同时又能得到最新的技术应用, 满足企业对信息管理的需求.
  • 从投资方面来看:企业只以相对低廉的"月费"方式投资, 不用一次性投资到位, 不占用过多的营运资金, 从而缓解企业资金不足的压力;不用考虑成本折旧问题, 并能及时获得最新硬件平台及最佳解决方案.
  • 从维护和管理方面来看:由于企业采取租用的方式来进行物流业务管理, 不需要专门的维护和管理人员, 也不需要为维护和管理人员支付额外费用. 很大程度上缓解企业在人力、财力上的压力, 使其能够集中资金对核心业务进行有效的运营.
解说
  • GUI~图形用户界面 (Graphic User Interface)的简称;也指代所有工作在各种图形化操作系统中,通过各种图形化窗口控件和用户交互的软件; 这类软件必然的依赖操作系统提供的图形控制接口,以便实时绘制,采集用户反馈等等;
  • 当然的Python 也可以开发这类软件的,而且可以使用的图形接口和框架也不少,这方面推荐 前面"Eurasia ~ 关注高性能的原创框架" 一节的作者沈崴的文章:Python 史书·GUI 部

  • 不过,现在的趋势是:"网站软件化",从Google桌面搜索(http://desktop.google.com)开始利用本地网页当搜索引擎的交互和控制界面,到Yahoo!mail 也使用Ajax 技术将邮箱作的象outlook;进一步的,百度的安全中心,更是利用网页安装杀毒引擎到用户桌面,但通过本地的Web服务,使用网页作为查杀病毒的控制界面!

  • 因为,人们越来越多的将时间化在网络中,通过浏览器,在网页中写作/沟通/购物/工作/学习/游戏,,,网页作为操纵信息的界面,人家已经非常非常习惯和熟练了;
  • 而且,网页,基于简单的HTML设计和解析,比使用操作系统的图形接口来绘制用户界面要轻松的多的多!
  • 所以,行者也建议,能愉懒使用网页作为GUI时,千万不要客气!

王道:简洁!

Kingcraft means simple!

背景
  • 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!

背景
解说
  • 在Python 世界中很多时候作起来比想象中要来的容易!
  • 因为从教育学角度的研究,人在同一时间内可以关注和处理的事儿只有7~9个,再多就有些顾此失彼了; 然而一个再小的软件涉及到的方方面面很容易就超过这个心理容量,而且在头脑中推演数据处理流程时,人脑的堆栈深度是非常浅的(不是所有人都可以作到象棋/围棋运动员那样儿可以在头脑中对弈的!)-- 所以,在想象中,就非常有可能越想越乱,越想越不敢动手作了;

  • 反而,先不管3721,趁着念头还鲜活,先将可以完成的部分快速变成可以运行的代码,一时无法想通的,变成空函式,伪类等等可以执行通过但是没有实际行为,仅仅标识出想法的有效代码来! 这样,下次的尝试,永远有可用的代码基础,每次我们就可以仅仅关注没有完成的部分,有可用的代码打底儿,每次尝试,都令我们真实的向目标进行了一步! 没有比这样由成就感累积而成的开发体验最舒服的了! 而且一直有真实不虚的代码可以运行和测试,比在头脑里空想要靠谱的多,安心的多;-)
  • Pythnoic 的感觉/体验/自信,就是鼓励大家不要顾虑自己是否对问题域有足够的知识积累己达到成竹在胸游刃有余的程度,直接去尝试! Python 脚本是轻松可得的,放弃,重构,从头再来,都不是难事儿;
  • 如果总是期待自个儿非得达到一个完美的积累状态再去动手实际开发,结果可能就是一直陷入积累的状态无法自拔. 其实,技术的发展已不是日新月异的级别了,可以说是每时每刻都有新的技术/框架/模块/思想的出现,想积累到一定程度再动手,可能积累的东西已经过时了,要抢在自个儿的想法没有过时之前变成代码,可用的软件,释放出来,抢占先机,才可能在这一过程中,及时发现最新技术/代码/思想 同步应用进来,令自个儿永不过期 ;-)

  • 所以,在Python 中,如何作? -- 不应该是个山门~ Python 隐密的规则/技巧/陷井 相比C++/C#/JAVA 等等主流语言来说,实在太少了,而且知道与否对于我们完成系统,几乎没有影响; 作什么? -- 这才是不同Pythoner 间的最大差异,这就取决于想象力,观察力,对周围事物的敏感程度,是否"足够懒惰","没有耐心" 随时都想着将人工反复作的事儿,利用Python 形成工具来帮助自个儿完成 -- 进而形成爽快的工具/系统,成为其它有类似需求的人们的最爱

箴言凝练

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

蠎之禅

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

atta1-2.png

  • 试译:

    美丽好过丑陋,
    浅显好过隐晦,
    简单好过复合,
    复合好过复杂,
    扁平好过嵌套,
    稀疏好过密集,
    可读性最重要,
    即使祭出实用性为理由,特例也不可违背这些规则.
    
    不应默认包容所有错误,得由人明确的让它闭嘴!
    
    面对太多的可能,不要尝试猜测;应该有一个(而且是唯一)直白的解决方法;
    当然,找到这个方法不是件容易的事~谁叫你不是荷兰人呢?
    但是!现在就做永远比不做要好;
    
    若实现方案很难解释,那么它就不是一个好方案;反之也成立!
    
    名称空间是个绝妙想法.
    
    --立马来共同体验和增进这些吧!
    
    -- by Tim Peters
  • 汉译集注
    • 访问地址: http://wiki.woodpecker.org.cn/moin/PythonZen

    • 精巧地址: http://bit.ly/2h4f5T

    • 这一内置在 Python 语言内部的小诗,集中的隽永的,将 Pythonic 思想,具象的表述了出来;但是影射太多的实践体验,不是所有人一时间都有感应能够理解的; 不过,可以确信,通过 Guido 老爹的认可,编译包含进Python 内核的东西,准没错!努力去体验吧!

附:我们的奋起宣言

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

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


::-- ZoomQuiet [2007-11-03 11:46:56] <<PageComment2>>

ObpLovelyPython/LpyAttach1motto (last edited 2013-04-07 03:05:48 by ZoomQuiet)