序一

突然收到作者的邮件邀请,让我给新书写推荐序。由于之前对 the5fire 这个 ID 并没什么印象,所以按照老规矩加微信,一叙旧才知居然是 6 年前 BPUG 结下的善缘(详见 https://www.the5fire. com/957.html)。

BPUG(北京 Python 用户组)是 2004 年成立的 CPUG(中国 Python 用户组)的北京分会,从 2004 年到 2007 年共组织有 25 次线下活动,我发起并主持了其中绝大多数线下交流活动。全国各城市也分别成立了 Python 用户组,会不定期组织线下技术交流活动,至今已进行了总计 50多场 Python 相关的活动。而本书作者就是参加了 2012 年那次 BPUG 活动后,坚定了从 Java 转变为一名 Python 行者的决心,进而积累成本书。

受邀写推荐序,我其实很纠结,因为 Python Web 开发有太多梗可以聊了,但又不好喧宾夺主,所以只能憋住,只说最憋不住的几点。

Django 在 2005 年发布其实也是个巧合,那之前有 all-in-one 的 Web 解决方案,而且异常强大;Zope/Plone 平台如日中天,但是无论学习还是开发部署都太重了。

而从 2003 年开始,堪萨斯城的 World Online 小组在维护一堆报社官网的过程中积累了大量最佳实践,并有意识地整合为快速可定制的 CMS 系统,直到从文档到工具链都成熟时才开源发布。

简单说,Django 和其他框架的不同在于,它是先有成功案例再发布的。这导致一开始,无论技术还是社区,Django 都异常务实。它贯彻了框架本身的职责:沉淀领域工程经验,指导/辅助程序员高效地交付工程。这和以往常见的模型/库(它们专注提供功能)是根本不同的知识凝结形态。可惜到今天,依然有哪种框架更加优秀的争论。刚刚在 CPyUG 列表中爆发的争议点为:

□ Flask 集领域最优模块而成;

□ 而 Django 大而全,却什么都没做好……

这其实也是新手在选择 Web 开发框架时最容易被误导的。

而本书出版得正是时候,通过长期工程中的 Django 使用体验,来展示为什么一个发布于 13年前的框架今天依然可以站在 Web 开发一线。

背景

早在 2009 年出版的《可爱的 Python》一书中,我就对纷繁的 Python Web 应用框架进行了讨论。那之后,有关 Django 的中文图书并不多,从 z.cn 上也只能查到 5 本。

但 Django 从发布之初,就一直是最活跃和发展最好的 Web 框架。在其他大型框架逐渐不活跃后,它以其绝对丰富的产品线以及生态环境,成为 Python 世界中商业网站开发的首选框架。但是,为何对应图书出版这么不活跃?

答案可能很囧:因为 Django 官方文档太完备了,几乎一切问题从文档中都可自行解决,几乎没有什么特殊知识点需要用图书来解决。此外,Django 社区也极其活跃和友好。甚至对于想入门的妹子们,都有对应的 Django Girls 国际品牌活动。每年会组织上千场全天免费的培训活动来吸引有一定基础的程序媛从其他技术栈迁移到 Django 世界。(对了,在 PyCon 大会上,Guido 老爹还专门点名赞扬了这一针对萌妹子服务的技术活动。)

触动点

作者的立意很清晰:

降低学习 Django 时的心智负担,主要针对想学习 Django 但又无从下手,或者看了很久文档能完成新手教程,但想自己开发一套系统时却无从开始的人。

即使官方文档将技术问题详尽陈列在前了,上手具体工程时依然存在问题。

简单来说,官方文档就像学校传统计算机教育或是几乎所有在线编程课程一样:只说了语言/框架本身,并没有涉及如何编程或者怎样进行工程实践。

即使读者确定自己需要的知识点都在官方文档中,也根本无从判定应该从哪里开始,以及在不短的时间里以什么路径从头构建一个稳定可持续发展的 Web 应用系统。这也是作者为什么在正式构建博客之前,用了三分之一的篇幅详细阐述了 Django 商用工程的前期筹备以及技术栈。读者只有穿过 PM、UML、WSGI、Flask、Tornado、DBA、IDE、virtualenv 等一系列成熟技术后,才能开始构建真正可用的博客系统原型。否则,用 5 分钟完成的原型在有点儿规模的协同过程中,一定会崩溃。

说回开头提及的那场争议,经过几十封邮件的交战后,有位知名不具的老司机总结了开源世界的共识或者规则,具体如下。

选择最适合自己的工具组成工具链。如果这个工具链不能适合几个场景,那么这几个点是不是很痛?不痛就可以忍。如果很痛,是否可以通过第三方补丁/插件改进?可以的话就用上补丁/插件,然后承担一定的非标准代价。如果没有补丁/插件,是否可以通过修改解决?如果可以自己改,然后看是不是可以放出去。如果很痛并且没有第三方插件,自己修改代价又很高,那么重新选择适合自己的工具链。如果真的没有合适的工具链,那么无非是以下两种情况。

□ 用户数很多:恭喜,你撞到了一片蓝海,即发现有个场景用户数很多(或者可以预见会很多),竟然还没合适的解决方案,这绝对是一个创业的好机会。

□ 用户数很少:恭喜,你发现了一个无人来过的狭小领域,攻克不得不解决的问题很可能是你将来的核心竞争力。

但是大多数人在面对软件系统的时候,实际上是以闭源软件的思路来解决问题的。

□ 把这个问题给我解决了!

□ 要多少钱?

这种思路其实无可厚非。每家公司都要集中解决自己的核心问题,而不是先解决非相关问题,例如框架。但是如果将这个思路用到开源社区中,就不大好使,这时就需要有对应的商业公司来解决两者间的鸿沟/商机。MySQL 和 Django 当年都不约而同地选择成立基金会,用商业来维持社区发展,就是意识到开源带来的活性可以令自己活得更久、更好、更强。本书作者也一样,公开自己的经验不仅可以加深自己的理解,还可以回馈 Django 这一伟大社区。

其实“降低学习 XXX 时的心智负担”这类通用解决方案是有的,就是每一位自学成功的开发者都具备的习惯。

以最小可用作品为核心的持续迭代,即在第一个 42 分钟就完成构建并发布一个几乎没有功能但是可运行的 Django 网站,然后持续迭代,在一直可运行的基础上一点一点追加功能,在这个过程中保持开发→调试→部署→运营的循环过程。接着要确保任何一个新知识点可以立即并入运行中的功能网站,这就可以依据一个健康的开发过程持续积累知识树,同时有可视、可用、可发布、可演示、可追踪……活的真实项目来印证。

当然,这样一来,整个图书的结构就不得不包含大量重复叙述,无法形成流畅的阅读体验。我期待作者在后续电子版本中能以这种实战自学的过程为线索来写。另外,这也是 2008 年我提出的 PythoniCamp 自学模型,用于专门构建对初学者友好的课程。配合这本对有工程经验者更加友好的图书,形成 Django 实效系列图书/课程。

综上,作者从大学时代开始独自挣扎了近 10 年,终于通过个人努力完成赛道升级,进入更大的平台,开始更高、更复杂、更强技术的求索。本书是一名靠谱工程师的私人经验集成,作者通过样例仓库、私人博客、公众号等渠道,期待和读者持续交流。本书的内容也将随着读者的加入持续增订,期待慢慢变成 Django 世界中最可靠的企业工程入门资料库。而购买本书,将成为你加入这一丰饶世界的门票。

Zoom.Quiet,uSEE.tech CTO

目录

  • 序一
  • 序二
  • 前言
  • 第一部分 初入江湖
  • 第1章 需求
  • 第2章 框架基础和技术选型
  • 第3章 Django小试牛刀
  • 第二部分 正式开发
  • 第4章 进入开发
  • 第5章 奠定项目基石:Model
  • 第6章 开发管理后台
  • 第7章 开发面向用户的界面
  • 第8章 引入前端样式框架Bootstrap
  • 第9章 完成整个博客系统
  • 第三部分 第三方插件的使用
  • 第10章 使用第三方插件增强管理后台
  • 第11章 使用django-rest-framework
  • 第四部分 上线前的准备及线上问题排查
  • 第12章 调试和优化
  • 第13章 配置MySQL和缓存
  • 第14章 上线前的准备
  • 第15章 升级到Django 2.0
  • 第16章 最后总结
  • 附录A 使用Fabric 2.0
  • 附录B 使用uWSGI来启动Django程序
  • 附录C Sentry安装和配置
  • 附录D 评论验证码功能 
  • 附录E 通过signal来解耦代码
  • 附录F 实现文章置顶的几种方案
  • 附录G 以腾讯云为例演示部署流程