|
Size: 489
Comment:
|
Size: 11025
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from ObpLovelyPython/BackGround | |
| Line 5: | Line 4: |
| ||'''status'''|| 草稿|| ZoomQuiet|| 完成度15%|| | ||'''status'''|| 草稿|| ZoomQuiet|| 完成度50%|| |
| Line 12: | Line 11: |
| ''简述'' | `满纸轻松事儿,一把辛酸泪` |
| Line 15: | Line 14: |
| "写本给不知道Python 的人,或是想学习Python 的人的有用的书" 从来没有想到这个忽然间的念头能成为现实... |
|
| Line 17: | Line 19: |
| 成书的经过,当然就得追溯历史了... 就我个人来讲,从 2000 年通过PHP接触到Python,到 2002 年才真正开始使用,再到2004 年掺合 python.cn社区开始大规模接触同好的行者们,对 Python 的兴趣和信心是一直增长着的, 但是发觉世人对这一优秀语言的认知识非常非常的有限,不许在各个综合技术社区中专门板块的兴起,又或是Google 公司的成功,在中国都没有促动起 Python 的发展; 这才开始思考 Python 的推广,反思自个儿的 Python 学习体验, 寻找是否有有好书可以促进Python 在中国落地生根; 又通过对社会化学习方面的参考,才意识到: 学习的阶级:: 从高到底是: ''知己不知<知己知<不知己知<不知己不知'' 为什么这么说? * 开始涉及一个全新技术领域时,我们不知道我们对这个领域的任何信息,也就是连不知道什么都没有概念 * 后来,通过不自学的,或是继续的学习,已经获得了部分相关信息,但是从来没有考虑使用这领域的知识来解决问题,所以,不知道自个儿已经知道了哪些领域内的实用信息 * 再来,通过实践,切实掌握了领域的关键知识,并对领域内的所有方面都有所了解,明确在领域内自个儿掌握了什么;好比举着油灯进在一个大图书馆中,刚好照亮了一整书架,但是不清楚在光圈以外还有多少书架; * 最后,推而广之,对领域相关的所有知识领域都有所了解,掌握了领域间的关系,明白自个儿究竟还有多少知识不知道;好比那个大图书馆中,打开了所有的电灯,明白自个儿身边这一整书架同整个图书馆其它书架的关系; 感觉,只有快速达到`知已知`的阶段,才可能事半功倍的高效率/自信/自觉的继续学习下去; 幸好,Python 又的确是个易学好用的语言,怎么向其它没有摸到 Python 秉性的人们宣传这种体验呢? developerWorks 中 David Mertz 创作的“可爱的 Python”系列 ： http://www.ibm.com/developerworks/cn/linux/theme/special/index.html#python 就成为我想成书的原型了: 将 Python 最可爱的方面,以小篇幅的形式组织发布出来; == 社区 == `那些风花雪夜` 2007.2.1 在邮件列表中一个小白苦恼的心聲 http://wiki.woodpecker.org.cn/moin/ObpBroadview/2007-02-01 激发出了行者们成书的狂想,经过讨论,定名,定内容,定大纲, 可爱的 Python 就在社区活跃分子的相互鼓励中开始了: 建立维基主页: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython 在会课中专题讨论,建立工程环境,建立专用邮件列表,建立进度讨论IRC聊天室,建立项目管理网站... 一点点,一滴滴,一页页,就积累起来了... 本来以为是可以快乐的轻松组织完成的,没有想到博文注意到了我们的想法... |
|
| Line 19: | Line 61: |
| 编辑主动找到我们,并快速由副总出面在北京宴请当时的主创人员,确立了图书的基本思路和网络/图书双版权发布的基调,将社区视作独立的单位进行协商,一下子,游击队变成了正规军...这感觉,怎么说呢?... 蝙蝠侠说:"能力越大，责任越大" 我们则是:"期望越大，压力越大" 我们期望写出 第一本中文Python 原创图书，第一本原创入门Pythonq图书,第一本原创畅销Python 技术图书... 但是！我们只能 `快乐并痛苦着写`: * 一想到这些文字是要付梓成书的，就不敢象邮件列表中痛快的表白 * 但是又想到得将快乐的Python 体验原味传达给未来的读者,这又得表白的痛快... 林林总总,在对自个儿对编辑对文字对代码对截屏,等等纷繁的矛盾中努力的码字的同时,还要完成各种工作任务,挣来口粮,才能支持自个儿继续 `快乐并痛苦着写`... |
|
| Line 20: | Line 74: |
| == 社区 == | 甚至于在不断的"煎熬"中总结出了: 如何组织在线图书工程 :: '''态度决定一切!'''~兴趣才是网络团队的最稳定动力 * 在线分布式团队的构成,更加要求臭味相投,最好是一个稳固的社区中的老朋友们 * 选题的有趣和有用,也是图书成功的绝对必要条件 `图书也是工程!`~在资源方面,要大力使用基于互联网的服务 * 就按照软件工程的方式来组织大家都习惯且有效! * 网络中的对应免费服务是齐全的: * 版本控制~ code.google 等等免费工程管理服务 * 日常沟通~ groups.google 等等免费列表服务 * 知识积累~ wikidot.com 等等免费维基服务 * 实时讨论~ IRC at freenode.org 等等聊天服务 * 项目管理~ Everydo 等等免费管理服务 * 进度计划~ google.com/calendar 等等在线日历服务 `没有规矩不成方圆`~有了团队,一直要组织和管理的 * 定期的IRC会议非常有助于鼓励士气,協商进度,调节任务 * 一定要有热心的核心人物来協調和决定所有变更(前期应该是发起人,后期由编辑分担比较合理) * 200页以内的小书,团队有多少人是没有关系的,因为任何偏差都可以快速修订 * 大于300页的图书,写作团队应该控制在5人以内,否则,沟通将是没有尽头的事儿了: * 合理的团队构成: * 2~5人的撰写成员 * 3~10 人的校对成员 * 随便多少人的关注/宣传成员 * 1~2 个稳定的跟随编辑 * 一定不要使用任何 Office 格式文档来进行交互组织!这是无法进行版本控制的二进制东西! * 结构化文本 * 纯文本 * HTML * TeX文本 * 等等都是可以良好的通过版本控制环境进行充分管理的格式!一定要坚持使用! * 即使在交付前统一倒入 Word 之流来统计字数,也要坚持使用! `出版是不比撰写轻松的复杂工程!`~理解出版社的工作方式后,才可能有良好的配合 * 国家法令法规,行业潜则,市场反应,目标人群,流行模式,排版风格... 都是出版方面的专业知识,不是软件行业行者可以轻易体悟的到的! * 有技术背景的编辑是个宝! * 固定的编辑是永远的朋友! * 固定的编辑追随进行田间管理是种幸福,否则是很郁闷的事儿~你得将相同的话,不断的反复说给不同的负责编辑 * 不使用 M$ Office 的编辑在中国是神话! 但是,技术社区撰写,完全不应该使用 Office 工具来进行... 教训:: * 一定要有合同，有社区背景中，出版社对署名的理解是不同的，一定要事先沟通好，否则，会有解释不清的麻烦，对社区贡献也是个隐患 * 签定合同时,一定要有法人资格的社区出面来交涉,出版社会比较重视... * 沟通比一切都重要,让所有人知道所有事儿,是在线分布式社区化写作的最基础原则! |
| Line 23: | Line 124: |
| 在图书完成的后期,发觉几个技术图书出版社也有各自的专题邮件列表了,也是从技术图书出版社列表中,知识了图书编辑的"田间管理".. 在图书从想法到成书过程中,适时的配合,反馈,沟通,促进.. 这是编辑保证图书不跳票的有效手法,也是作者们写作的动力之一..就和写Blog 类似,有人追着看,评论的Blog 作者总是积极一些的.. 毕竟网络团队化社区式群体写作,存在沟通不直接,大家的时间无法保证的问题,和自由软件不同,软件的版本发布时机是社区主动把握的,而簽定了合同的图书工程,是不能轻易跳票,改发布日期的哪... 所以,除了一直在关注图书的社区行者们,掺合撰写的伙伴们,最令人感动的就是那些"摧生婆"们了: 杨编:: 是最早关注了社区动向,并将其作为一个图书选题来进行主动沟通的"摧生婆" 正是他的促动,从而令图书正式的成为博文的图书立项,开始了这次成书之旅,可惜,从来不是本书的责编,而且不久离开了博文,没能看到图书成型... 方编:: 是最早的责编,因为同是程序员出身,是最明白技术的编辑,在内容方面给出了非常多的建议,很大程度上使我们这本内容很另类的技术入门图书被出版社接受,方编居功致伟!不久也离开了博文,没能看到图书完成... 彭编:: 是临危受命的责编,虽然跟的时间不长,但是非常耐心的全盘接受并理解了我们的意图!尽而也非常开放的共同使用我们建议的网络服务进行编辑事务的透明沟通... 赵编:: 是最后一位责编,跟的时间不是最长的,但却是跟的最紧的,在他的任期,合同以哲思自由软件社区的身份签定了,版权的分离也成功达成了理解,而且美术编辑的跟进,也是赵编从中艰难的在共同摸索全新的模型... |
|
| Line 25: | Line 140: |
| = 成了?! = | == 成了?! == biu~~的一声,从吃过接风宴,开始写,到现在一下子快两年了,这其间,俺从北京跳到了珠海,到完成了过程改进专员到过程改进经理的飞跃,同时,间杂的,还利用组织 可愛的Python 一书的经验,组织了另外两本Python 技术图书的翻译校对和另外一整本原文图书的快速翻译... |
| Line 27: | Line 143: |
| 时间,真的在不知不觉中飞速的消逝了,真的非常敬佩博文出版社的执着,所以,`冲刺!不断的`,每次,都在社区列表进行倡议,摇旗声援的不少，真正投入到撰写的也着实不多，但是，书是真正在不断的完善中，可是，随着完成度的增长，也越来越对内容，有所挑剔，总是感觉有更加好的表达方式... 另外一方面,Python 也在不断的进步,两年里版本增长了三次,而是象周蟒这样的项目,更加是从无到有的成长了起来, 对图书的内容也更加的惶恐:"足够有趣,足够有用嘛?会有人买来看嘛?" 幸好,编辑一直在肯定的说,这样整一定成的,但是什么时候是真正的成了? 突然的有一天,在不断的相互督促中,焦虑中,突然发现,成了,所有章节都完备了,可以了... 这种意外的巨大的惊喜,不比那日意识到自个儿在使用 Pythonic 来编程时的快乐... "发表是最好的记忆" ~ 台湾候捷 老师的感想,也是我们的感想,成书的那一刻,就是我们忘记这本书 ,向下本书进发的时候,成了的书已经属于读者了! |
|
| Line 29: | Line 155: |
| ## 留给过往编辑们追忆成书体验 | |
| Line 31: | Line 158: |
| ## 留给过往掺合的行者们追忆成书体验 |
status |
草稿 |
完成度50% |
1. 后记故事
满纸轻松事儿,一把辛酸泪
1.1. 成书感言
"写本给不知道Python 的人,或是想学习Python 的人的有用的书"
- 从来没有想到这个忽然间的念头能成为现实...
1.2. 缘起
- 成书的经过,当然就得追溯历史了... 就我个人来讲,从 2000 年通过PHP接触到Python,到 2002 年才真正开始使用,再到2004 年掺合 python.cn社区开始大规模接触同好的行者们,对 Python 的兴趣和信心是一直增长着的, 但是发觉世人对这一优秀语言的认知识非常非常的有限,不许在各个综合技术社区中专门板块的兴起,又或是Google 公司的成功,在中国都没有促动起 Python 的发展; 这才开始思考 Python 的推广,反思自个儿的 Python 学习体验, 寻找是否有有好书可以促进Python 在中国落地生根; 又通过对社会化学习方面的参考,才意识到:
- 学习的阶级
- 从高到底是:
知己不知<知己知<不知己知<不知己不知
- 开始涉及一个全新技术领域时,我们不知道我们对这个领域的任何信息,也就是连不知道什么都没有概念
- 后来,通过不自学的,或是继续的学习,已经获得了部分相关信息,但是从来没有考虑使用这领域的知识来解决问题,所以,不知道自个儿已经知道了哪些领域内的实用信息
- 再来,通过实践,切实掌握了领域的关键知识,并对领域内的所有方面都有所了解,明确在领域内自个儿掌握了什么;好比举着油灯进在一个大图书馆中,刚好照亮了一整书架,但是不清楚在光圈以外还有多少书架;
- 最后,推而广之,对领域相关的所有知识领域都有所了解,掌握了领域间的关系,明白自个儿究竟还有多少知识不知道;好比那个大图书馆中,打开了所有的电灯,明白自个儿身边这一整书架同整个图书馆其它书架的关系;
感觉,只有快速达到知已知的阶段,才可能事半功倍的高效率/自信/自觉的继续学习下去; 幸好,Python 又的确是个易学好用的语言,怎么向其它没有摸到 Python 秉性的人们宣传这种体验呢? developerWorks 中 David Mertz 创作的“可爱的 Python”系列 ：
http://www.ibm.com/developerworks/cn/linux/theme/special/index.html#python 就成为我想成书的原型了: 将 Python 最可爱的方面,以小篇幅的形式组织发布出来;
1.3. 社区
那些风花雪夜
- 2007.2.1 在邮件列表中一个小白苦恼的心聲
http://wiki.woodpecker.org.cn/moin/ObpBroadview/2007-02-01 激发出了行者们成书的狂想,经过讨论,定名,定内容,定大纲, 可爱的 Python 就在社区活跃分子的相互鼓励中开始了:
建立维基主页: http://wiki.woodpecker.org.cn/moin/ObpLovelyPython 在会课中专题讨论,建立工程环境,建立专用邮件列表,建立进度讨论IRC聊天室,建立项目管理网站... 一点点,一滴滴,一页页,就积累起来了... 本来以为是可以快乐的轻松组织完成的,没有想到博文注意到了我们的想法...
1.4. 撰写
- 编辑主动找到我们,并快速由副总出面在北京宴请当时的主创人员,确立了图书的基本思路和网络/图书双版权发布的基调,将社区视作独立的单位进行协商,一下子,游击队变成了正规军...这感觉,怎么说呢?... 蝙蝠侠说:"能力越大，责任越大" 我们则是:"期望越大，压力越大" 我们期望写出 第一本中文Python 原创图书，第一本原创入门Pythonq图书,第一本原创畅销Python 技术图书...
但是！我们只能 快乐并痛苦着写:
- 一想到这些文字是要付梓成书的，就不敢象邮件列表中痛快的表白
- 但是又想到得将快乐的Python 体验原味传达给未来的读者,这又得表白的痛快...
林林总总,在对自个儿对编辑对文字对代码对截屏,等等纷繁的矛盾中努力的码字的同时,还要完成各种工作任务,挣来口粮,才能支持自个儿继续 快乐并痛苦着写...
甚至于在不断的"煎熬"中总结出了:
- 如何组织在线图书工程
态度决定一切!~兴趣才是网络团队的最稳定动力
图书也是工程!~在资源方面,要大力使用基于互联网的服务
- 就按照软件工程的方式来组织大家都习惯且有效!
- 网络中的对应免费服务是齐全的:
- 版本控制~ code.google 等等免费工程管理服务
- 日常沟通~ groups.google 等等免费列表服务
- 知识积累~ wikidot.com 等等免费维基服务
- 实时讨论~ IRC at freenode.org 等等聊天服务
- 项目管理~ Everydo 等等免费管理服务
- 进度计划~ google.com/calendar 等等在线日历服务
没有规矩不成方圆~有了团队,一直要组织和管理的
- 定期的IRC会议非常有助于鼓励士气,協商进度,调节任务
- 一定要有热心的核心人物来協調和决定所有变更(前期应该是发起人,后期由编辑分担比较合理)
- 200页以内的小书,团队有多少人是没有关系的,因为任何偏差都可以快速修订
- 大于300页的图书,写作团队应该控制在5人以内,否则,沟通将是没有尽头的事儿了:
- 合理的团队构成:
- 2~5人的撰写成员
- 3~10 人的校对成员
- 随便多少人的关注/宣传成员
- 1~2 个稳定的跟随编辑
- 合理的团队构成:
- 一定不要使用任何 Office 格式文档来进行交互组织!这是无法进行版本控制的二进制东西!
- 结构化文本
- 纯文本
- HTML
- TeX文本
- 等等都是可以良好的通过版本控制环境进行充分管理的格式!一定要坚持使用!
- 即使在交付前统一倒入 Word 之流来统计字数,也要坚持使用!
出版是不比撰写轻松的复杂工程!~理解出版社的工作方式后,才可能有良好的配合
- 国家法令法规,行业潜则,市场反应,目标人群,流行模式,排版风格... 都是出版方面的专业知识,不是软件行业行者可以轻易体悟的到的!
- 有技术背景的编辑是个宝!
- 固定的编辑是永远的朋友!
- 固定的编辑追随进行田间管理是种幸福,否则是很郁闷的事儿~你得将相同的话,不断的反复说给不同的负责编辑
- 不使用 M$ Office 的编辑在中国是神话! 但是,技术社区撰写,完全不应该使用 Office 工具来进行...
- 教训
- 一定要有合同，有社区背景中，出版社对署名的理解是不同的，一定要事先沟通好，否则，会有解释不清的麻烦，对社区贡献也是个隐患
- 签定合同时,一定要有法人资格的社区出面来交涉,出版社会比较重视...
- 沟通比一切都重要,让所有人知道所有事儿,是在线分布式社区化写作的最基础原则!
1.5. 摧生婆们
- 在图书完成的后期,发觉几个技术图书出版社也有各自的专题邮件列表了,也是从技术图书出版社列表中,知识了图书编辑的"田间管理".. 在图书从想法到成书过程中,适时的配合,反馈,沟通,促进.. 这是编辑保证图书不跳票的有效手法,也是作者们写作的动力之一..就和写Blog 类似,有人追着看,评论的Blog 作者总是积极一些的.. 毕竟网络团队化社区式群体写作,存在沟通不直接,大家的时间无法保证的问题,和自由软件不同,软件的版本发布时机是社区主动把握的,而簽定了合同的图书工程,是不能轻易跳票,改发布日期的哪... 所以,除了一直在关注图书的社区行者们,掺合撰写的伙伴们,最令人感动的就是那些"摧生婆"们了:
- 杨编
- 是最早关注了社区动向,并将其作为一个图书选题来进行主动沟通的"摧生婆" 正是他的促动,从而令图书正式的成为博文的图书立项,开始了这次成书之旅,可惜,从来不是本书的责编,而且不久离开了博文,没能看到图书成型...
- 方编
- 是最早的责编,因为同是程序员出身,是最明白技术的编辑,在内容方面给出了非常多的建议,很大程度上使我们这本内容很另类的技术入门图书被出版社接受,方编居功致伟!不久也离开了博文,没能看到图书完成...
- 彭编
- 是临危受命的责编,虽然跟的时间不长,但是非常耐心的全盘接受并理解了我们的意图!尽而也非常开放的共同使用我们建议的网络服务进行编辑事务的透明沟通...
- 赵编
- 是最后一位责编,跟的时间不是最长的,但却是跟的最紧的,在他的任期,合同以哲思自由软件社区的身份签定了,版权的分离也成功达成了理解,而且美术编辑的跟进,也是赵编从中艰难的在共同摸索全新的模型...
1.6. 成了?!
- biu~~的一声,从吃过接风宴,开始写,到现在一下子快两年了,这其间,俺从北京跳到了珠海,到完成了过程改进专员到过程改进经理的飞跃,同时,间杂的,还利用组织 可愛的Python 一书的经验,组织了另外两本Python 技术图书的翻译校对和另外一整本原文图书的快速翻译...
时间,真的在不知不觉中飞速的消逝了,真的非常敬佩博文出版社的执着,所以,冲刺!不断的,每次,都在社区列表进行倡议,摇旗声援的不少，真正投入到撰写的也着实不多，但是，书是真正在不断的完善中，可是，随着完成度的增长，也越来越对内容，有所挑剔，总是感觉有更加好的表达方式... 另外一方面,Python 也在不断的进步,两年里版本增长了三次,而是象周蟒这样的项目,更加是从无到有的成长了起来, 对图书的内容也更加的惶恐:"足够有趣,足够有用嘛?会有人买来看嘛?" 幸好,编辑一直在肯定的说,这样整一定成的,但是什么时候是真正的成了? 突然的有一天,在不断的相互督促中,焦虑中,突然发现,成了,所有章节都完备了,可以了... 这种意外的巨大的惊喜,不比那日意识到自个儿在使用 Pythonic 来编程时的快乐... "发表是最好的记忆" ~ 台湾候捷 老师的感想,也是我们的感想,成书的那一刻,就是我们忘记这本书 ,向下本书进发的时候,成了的书已经属于读者了!
2. 编辑故事
3. 行者故事
::-- ZoomQuiet [DateTime(2008-04-26T06:35:09Z)] PageComment2