分类目录归档:思考与随感

如何有效防止久坐、用眼过度和关节损伤?

无论是程序员,还是其他需要长时间使用电脑的工作者,都会面临很多健康问题,除了简单直接的猝死,更常见的是各种重复性劳损(Repetitive Strain Injury,RSI),比如颈椎病、腰背疼痛、干眼症、鼠标手等。除了保持正确坐姿、使用各种效果不一的人体工程学装备外,最重要的是避免长时间工作,每隔一段时间站起来休息和放松。

听起来很简单,但对大部分人来说,靠自觉定期休息基本不可能,所以我们需要借助外力来强迫自己休息。

让你的电脑每隔一段时间自动锁定会是一个好办法。这篇文章会介绍两个这样的工具,当你使用电脑一段时间后,它会自动显示一个休息提示,屏蔽你的任何输入,直到休息时间结束:

 

RSI-prevention 工具

 

Workrave 是 2002 年发布的开源 RSI-prevention 程序,它是目前的最佳选择:

workrave logo

Workrave 的功能很全面,不仅包含基本的休息提醒,还可以监测活动状态,并且内置了体操动作提示(别担心,不是你想象的那种体操,只是一些拉伸动作)。除此之外,你还可以在统计选项里查看你每天的活动情况,包括休息次数、鼠标和键盘使用情况。

唯一的缺点是,它不支持 macOS 系统。如果你使用 macOS 系统,在支持 macOS 的替代品里,功能稍微简单一些的 Stretchly 是个不错的选择:

stretchly logo

这两个程序都是开源项目,在对应 GitHub 项目的 releases 页面可以下载到最新版本。

休息设置

你可以将界面语言设为中文,然后尝试按照自己的工作习惯调整设置。对于核心功能的休息设置来说,这两个程序都把休息分为两类,短休息和长休息。建议把短休息设为 20~25 分钟一次,每次 2 分钟;长休息 50~60 分钟一次,每次 10~15 分钟。另外,Workrave 还支持设置每天使用电脑的总时长限制,可以根据需要进行设置。

不要把休息频率设置的太高,因为你的电脑上可能被安装了监视「空位」时间和离开电脑次数的软件……

强制休息

为了让强制效果更强一点,建议在 Workrave 的首选项里为每个休息类别都设置不在休息前显示提示,也不要显示推迟和跳过按钮;Stretchly 类似,可以勾选「阻止跳过」,并取消勾选「允许推迟」。

当然,即使这样设置,太沉迷于手头工作的时候你还是可以找到某些特殊方法跳过休息。但是,为了让工具真正发挥作用,你要有一点点遵守规则的自觉。

从今天开始,正视健康在生活中的优先级吧。祝你有个好身体!

本文首发于公众号「李辉的代码厨房」。

正常上网

这几年一直在用 Bandwagon(「搬瓦工」)的廉价 VPS 做 VPN 代理服务器,前两天突然发现没法正常上网*了。

一开始以为是 Shadowsocks 客户端的问题,但重新启动或更换版本依然不行,在手机上测试也没法访问。接着猜测是不是主机到期,不过翻了邮箱并没有找到续费通知,只有几封服务推广邮件。想登陆主机网站,却发现主机网站也被封锁了,只好找了临时的 VPN 工具访问。登录后看到套餐被取消了,而且无法续订。仔细读了前段时间接连收到的那几封「服务推广邮件」,才发现原来它们是产品下线通知**。

花了半天时间,尝试寻找替代品,发现没有这么便宜的主机了,临时在 virmach 开了 2 美元月付的主机,网速不是很好。

忙完这一通,我不禁在想:为什么我要每年额外支出一两百块,依靠某种工具才能享有正常上网这种基本权利?真是荒诞!

总有一天,这些反文明的限制将会消失。唯一遗憾的是,在这种丧心病狂的审查和封锁下,所有的书籍、音乐和电影,网络上的文章、感想和只言片语,甚至于大多数人的日常生活都丧失了本该有的完整、自由和可能性。


*我认为应该尽可能的使用一般词汇。比如,使用「正常上网」、「自由上网」或「绕过网络封锁」,而不是「科学上网」或「翻墙」,这样可以尽可能的让看到的人了解到事情的本质。

**Bandwagon 重复发送的几封提醒邮件的标题为「BandwagonHost: OpenVZ VPS Phase Out」,因为误认为 Phase Out 是「推出」的意思,所以没有在意,这件事也算是英语词汇量低导致的乌龙事件。

《Flask Web 开发实战》第二次重印

最近要进行第二次重印,花了整整两天时间整理勘误。接下来的计划是,在第二次重印的书上市前,只在晚上处理论坛问题,尽量不在 IM 上回答和书上错误无关的提问(耗费心力,沟通成本非常高),也不再更新勘误页面。等到第二次重印的书上市,做下面几件事:

  • 写一篇《Flask Web 开发实战 2019 补丁》,汇总所有额外的项目源码变动,第三方工具和库的新版变化,常见的错误和常见问题等。
  • 和豆瓣协商,再为购买旧版本的读者更新一次文件;同时了解微信读书、多看、掌阅、京东、当当几个电子书平台的更新情况。
  • 再集中清理一次盗版文件。
  • 处理 Albumy 现存的两个 bug。
  • 整理一遍所有勘误,更新勘误页面。

2019/4/15 更新:

收到出版社的新版样书,也就是说,1-3 版本的书已经上市销售,目前哪里可以买到还不清楚(估计是京东自营)。

我开了微信公众号

在年初的某篇文章下面,有朋友建议我开个微信公众号,当时我说估计不会有,并表达了对微信、朋友圈和公众号的讨厌。然而两个月不到,我就开了公众号……

我的公众号是「李辉的代码厨房」,目前的规划是写作和技术相关的话题,比如职业选择、个人品牌建设、学习方法、生产力、编程技巧、工具推荐等,不写和某个编程语言或框架相关的内容。欢迎关注!

当然,我仍然讨厌微信、朋友圈和公众号。这里的讨厌主要包括这些方面:

  • 生态环境糟糕:太多垃圾信息,对生活各方面的过度侵入和打扰。
  • 微信本身很难用:除了功能臃肿,群聊的设计和内容审查,还有很多细节不够好,比如草稿不会多设备同步,浏览某个对话时不记忆退出时的位置。
  • 公众号的反互联网设计:内容无法在互联网上被直接检索到,在文章中无法插入公众号文章以外的超链接。

那为什么还要开公众号?

主要是因为微信公众号能够触及更多的读者,和读者的距离非常近。写文章自然会想让更多人看到,也希望有更多的交流,相对于博客,公众号更容易做到这一点。

另外,和读者距离更近,会让我更认真的对待写作,何况公众号发过的文章还不能修改(发了第一篇文章才知道……)。通过创建一个独立的公众号,也会让我更有动力进行主题写作,进一步锻炼非技术写作能力。

为了对抗公众号封闭的特性,我同时创建了知乎专栏「代码厨房」,公众号的文章会同步发到专栏和博客。公众号文章末尾的“阅读原文”链接通常会指向对应知乎专栏上的同一篇文章,以便读者可以更方便的点击文中的链接。

我可能不会回复

从 2017 年以来,我处理了大量的技术提问。尤其是 Flask 书出版后,更多的提问从各个渠道向我涌来。有时,我甚至觉得自己就像是一个在各个平台开了很多工单的客服。对于提问者来说,你只是在向某人提个问题;而对我来说,则是今天又多了一个要处理的提问。这段时间经常是一天中的一半时间都在处理提问。这不是个好现象,也该是改变的时候了。我并没有成为全职答题家的想法,我也需要时间学习新技术、休息、工作挣钱(虽然还没有工作……)。

为了回归正常的生活,我做了一个决定:从现在开始,所有通过电子邮件、微信、QQ(及群内@我)、Telegram(及群组内@我)、Twitter、知乎私信、文章评论(和文章本身无关的提问)、博客留言板、豆邮等渠道发来的技术提问我可能不会回复。(从明天起,做一个冷漠的人……)

除了书籍勘误以外,所有的技术问题,如果自己搜索相关信息并尝试后仍然无法解决,请在 HelloFlask 论坛发帖子提出(发帖前请阅读论坛帮助了解提问规则),我有时间会看,但不一定回复。(如果因为网络问题无法访问 HelloFlask 论坛,那就在 GitHub 上的 镜像仓库创建 issue)

有两个原因促使我做出这个决定:

1. 处理糟糕的提问浪费了大量的时间和精力。在这些提问里,除了少部分给我带来一些启发外,大部分都是一些简单的马虎问题,比如依赖没有安装、虚拟环境没有激活、环境变量没有设置、函数名写错、语法错误等等。大部分提问都是寥寥几句,既没有相关代码,也没有完整的错误回溯信息或命令行输出。所有相关内容都需要你一句一句的追问,看到新提供的一小块截图,你还要再次追问没截到的那部分内容。而且,因为大多数提问者热衷于用截图提供信息,如果你想在网上搜索相关内容,或是执行他的代码进行测试,还得手动把截图里的内容打出来。

还有些干脆是 XY 问题

  1. 有人遇到了问题 X。
  2. 他觉得问题 Y 可能是解决问题 X 的方法。
  3. 于是他去问别人问题 Y 怎么解决。
  4. 别人费劲力气浪费了大量时间教他处理问题 Y 后,才发现他只是想处理问题 X,而问题 X 和问题 Y 基本没什么关系。

举个简单的例子:

  1. 某个人买了一只鸡(这只鸡是公鸡,但是他不知道),发现他的鸡不下蛋。因为他不知道他的鸡是公鸡,所有真正要解决的问题 X 是“我的鸡是公鸡还是母鸡?”。
  2. 他错误的把问题 X 想成了问题 Y——”我的鸡得了不下蛋的病,应该怎么治?“
  3. 于是他上网发了一个帖子,求助问题 Y。
  4. 别人详细询问了鸡的健康状态,最近的饮食情况,居住环境等信息,并给出了各种治疗建议。在浪费了其他人大量时间后,他上传了鸡的照片……

除此之外,最让人崩溃的情况是这样的,在你像个侦探一样,进行了一系列追问,思考研究了半天之后,对方突然发过来“哦,我知道了,XXX 没有安装”。还有一些,在你认真思考,搜索了相关内容,最后给出回复之后却没有回音了。

2. 这些回答除了解决提问者的问题外,没有再产生更大的价值。因为大部分交流都被封闭在某个特定的程序内(一对一的交流无法被其他人看到,而 IM 群组里的消息检索起来非常麻烦),不能在互联网上搜索到,所以也无法帮到后续遇到同样问题的人。

更重要的是,IM 和 IM 群组(QQ 群、Telegram 群组、微信群)是非常糟糕的技术问题讨论工具,我甚至觉得 IM 只适合用来闲聊灌水。IM 本身的特性塑造了很多人的交流和思考方式,让人变得不会认真组织语言:喜欢发零散的多条信息,而不是一条长消息;面对多个人发来的多条回复时,没法专注思考其中的某一条。这些都让交流的效率变得非常低。在 IM 群组里投入任何有价值的信息都只会在短时间内发挥很少的价值,不久就会被扔到聊天记录里。而且在这些不支持代码高亮和预格式化的工具里交流技术问题是非常痛苦的体验。

对于这两个问题,最终的解决方案就是 HelloFlask 论坛。很早就想创建一个论坛,这些提问让我终于下定决心做这件事。一方面,论坛是最佳的技术问题讨论工具,论坛编辑器对代码的支持很好,每个问题作为单独的主题更方便讨论,而且可以被其他人方便的检索到。在此之前,我曾尝试将 GitHub Issue 作为问题讨论工具,但参与的人很少。有了论坛后,我就可以拒绝来自其他工具和网站的提问,让提问者到论坛发帖。另一方面,论坛可以吸引更多兴趣相投的朋友加入,大家可以一起讨论和解决问题,这样就不会让我一个人超负荷。

至于让提问者学会提问,还有很长的路要走。

我的书终于重印了

盼了几个月,《Flask Web 开发实战》终于重印了。为什么这么期待重印?当然是因为重印可以修正书中的错误!假如你经常写博客的话,你可以想象一下这样的场景,你在昨天发布的一篇文章里发现大量的错误,但是却没法更新文章,而你的读者还在不停的找出更多的错误……而面对一本已经付印的书,除了感到愧疚,努力整理勘误,告诉读者阅读勘误外,你什么也做不了。这种感觉真是太糟糕了!

这次重印的 1-2 版本主要有下面这些变化:

  • 修正了 1-1 版本 11 月前已知的所有勘误。
  • 更新前言开始介绍 Flask 时的 GitHub 仓库 stars 和 watchers 数量。
  • 前言最后添加了初稿被删掉的后记(稍作修改)。
  • 在前言、附录、封底的作者简介下面添加了勘误页面网址。
  • 完善了多处内容,包括为新版本 Pipenv 和 PyCharm 的变化添加说明,去掉附录中过时的项目等,具体见可改进实现文件
  • 修正了 42 处断行连字符错误。
  • 比 1-1 的封面更好看,封面文字的颜色变淡了,纸张变白了。

尽管修正了这么多的错误,1-2 版本的勘误表仍然还有不少内容。不过,我相信,如果还有下一次重印,那么大部分错误都将得到修正。希望这一天早点来到!

顺便说一句,据出版社编辑的消息,电子书文件已经相应更新,如果没有接收到推送,可以联系各平台客服手动更新文件。

出版社寄了两本 1-2 版本的样书,稍后会在知乎专栏 Hello, Flask! 送出,也算是稍稍填补一下我的愧疚。

HelloFlask 论坛上线

很早的时候就想弄一个 Flask 论坛,但一直没有时间,最近终于下定决定完成这件事。

简单对比了目前比较流行的论坛程序,发现 Flarum 的界面最符合我的审美,功能也不差。不过安装的时候花了很大功夫,各种出错,最后实在不想继续下去。何况 Flarum 目前还没有发布稳定版,可以再等一等,最终决定先用 Discourse。安装 Discourse 的过程倒是很顺利,大部分时间都花在了安装完成后的设置和主题调整上。

这个 HelloFlask 论坛目前已经开始试运行,网址是 discuss.helloflask.com,欢迎对 Flask、Python、Web 开发等话题感兴趣的朋友加入。

它将会用来替代下面这些程序和群组的大部分功能:

  • HelloFlask Google+ 群组
  • HelloFlask QQ 群
  • HelloFlask Telegram 群组
  • HelloFlask GitHub 仓库
  • Flask-China GitHub 仓库

如果你遇到了自己无法解决的技术问题,请在这个论坛发帖子,而不是直接通过邮件、私信等途径联系我。

Tips:

  • 注册时请尽量不要使用 QQ 邮箱(验证邮件会被拦截,需要手动到“收信记录”里取回),建议使用 GitHub 登录。
  • 因为部署在 DigitalOcean 上,如果无法访问可以尝试使用 VPN。

慎用 OneTab 扩展

新年第一天就发生了一件让人沮丧的事情,在电脑和浏览器都没有出现异常的情况下,OneTab(一个用来管理浏览器标签的扩展)保存的 3000 多个标签页突然全都不见了。这个问题也许和最近的一次 Chrome 自动更新有关(没错,就是那个界面非常难看而且不允许恢复旧样式的版本)。

在网上搜索后才发现有那么多人有同样的经历,在 Reddit 和 Stack Overflow 上有大量的帖子在讨论如何恢复丢失的标签数据。而在 Chrome 商店也可以看到很多一星评价,它们大都是这样开头的:“I love this extension until I lost all my saved tabs suddenly…”。

真是荒唐,一个用来保存标签页的工具,却没有提供一个可靠的存储机制。从大量评论来看,维护者是不负责任的,从来没有回复过反馈信息,官方文档也没有任何相关说明。OneTab 将数据存储在浏览器的本地存储中,文件位置大概在 AppData\Local\Google\Chrome\User Data\Default\Local Storage\ 目录下,而浏览器有可能会重写这里的文件。旧版本使用 SQLite 存储数据,新版本换成了 LevelDB,数据保存在 leveldb 目录下。或许可以尝试从这个目录下的文件导出数据,但暂时不清楚是否还存储了其他扩展的数据,尝试了几个工具,没能打开文件。因为不想为它浪费更多的时间,就此作罢。

这个扩展不值得信任,对于正在使用这个扩展的朋友,建议每次存档标签页以后都手动导出到本地文件进行备份或改用其他同类工具(比如 Tab OutlinerQlearly)。扩展本身提供了导出的功能,但导出的数据为纯文本,会丢失时间戳、分组名称、锁定和加星状态,也有人建议将 OneTab 页面作为网页保存来备份,或是使用网盘同步 leveldb 目录。

虽然是件坏事,但也有积极的一面。保存了几千个待读的标签页本身就说明了处理信息方式的不合理。这些“觉得有用但是目前没有时间处理”的标签页,在过一段时间后重新来看,大部分都变得没用了,不会再去浏览。尽管我一再提醒自己尽快处理掉这些积攒的标签页,但是却迟迟没有动身,直到 OneTab “自我了结”。这次数据丢失可以看做一个改变信息处理方式的契机,我决定停用这个扩展,尝试养成每晚清空标签页的习惯,并试着建立一个更好的信息处理机制。

忽然想起来,在使用 OneTab 之前积攒的大量书签还没有处理,而 Pocket 里面还躺着几百个待读的网页……


Update 2019/10/23

换了新电脑后又开始继续用 OneTab 了(同时搭配 Tab Outliner),不过这次采取了备份措施,每次点完存档后都会手动导出标签页信息到网盘同步的文本文档里。打开大量标签页直到电脑死机、存档大量标签页但不再回顾处理的坏习惯还没有改掉。目前标签页数量 963。

Update 2020/11/24

弃用 OneTab 大概有半年了,目前在用 Tab Outliner,免费版也支持备份数据到 Google 硬盘(不过需要手动备份)。同时也开始定期清理用不到的标签页,不过此前用 OneTab 备份在 TXT 文件里等待整理的几千个标签页也许再也不会打开了。

再见,新浪微博!

从今年上半年注册新浪微博以来,频繁出现“被点赞”的情况,赞的微博都是各种各样的营销内容。每一次都要一个一个的取消点赞,有的微博已经删除还无法取消,试了修改密码等方式均无效。不知道这些“被点赞”的微博会不会被关注我的朋友们看到,如果会出现在时间线上,那实在抱歉了。谢谢各位朋友的关注和支持,顺便还要说声再见,因为我已经决定不再用它了。

除了“被点赞”之外,新浪微博不论从产品设计、功能逻辑、界面 UI 和交互、价值观都有很多让人不舒服的地方,甚至让人厌恶。昨天忘记登出账户,晚上一看又冒出来几十个“被点赞”微博,终于下定决心要注销它。

接下来就是漫长的注销之路了。越是糟糕的产品,注销 / 卸载越是难,注销新浪微博经历了下面这些步骤。

  1. 在账户设置是找不到注销按钮的,只好去帮助中心搜索,提示注销账号要到手机客户端操作。
  2. 下载、安装、登录手机客户端,根据指示七绕八绕在某个角落里找到注销入口。
  3. 提示注销要满足 7 个条件,进入后显示有 2 个条件未满足:一是“未在常用手机操作:需在经常使用微博的手机上提交注销账号的申请”;二是“存在于其他APP、网站的授权或绑定关系”。这两条都很有意思,对于第一条,我从来就没在手机上用过微博,哪来的经常使用微博的手机。难不成,我还要在手机上经常使用一段时间微博以后才能注销它?对于第二条,完全没有提示和那些网站存在绑定关系,只能自己找。
  4. 搜索后才明白,第一条的解决办法是在手机客户端上开启“双重登录验证”(提示信息故意混淆不说,有些客服真的会告诉你需要多用一用,保持活跃状态一段时间才能满足条件)。第二条中的绑定关系则可以在网页端主页 – 管理中心 – 我的应用 – 我的应用找到,大多是我根本没有用过的程序。
  5. 现在条件都已满足,原以为这样就可以了,没想到“惊喜”还在后面。点进下一个页面,提示注销需要提供相关材料并发送邮件进行申请。对于普通用户要提供的资料包括注册时间、注册地点、完整曾用密码以及个人手持身份证照片。简直有病,我都要注销了,还要把手持身份证照片给你?

正当途径不行,那就试试别的方法吧。先删除了所有微博,移除了所有粉丝。接着参考知乎某答案的方法,换了一个卖粉头像,轮番给新浪微博上的官方账号和明星发私信和评论,内容类似“1000 fen 1 元 +V BBXET99”这种。不出几分钟,果然提示账号异常。最终的效果是:账号主页无法访问,搜索结果也不再出现。这样就足够了。

最后祝新浪微博早日完蛋。

写一本Flask入门教程

第一次萌生出这个念头是在2016年,刚开始写知乎专栏《Hello, Flask!》的时候。写了几篇文章后,原来计划的系统性的教程就变成了一堆零散主题的文章。一年后,又有过一次写教程的念头,那是在《用Flask实现豆瓣相册(一)》;只不过,刚刚完成第一篇,就开始写《Flask Web开发实战》了。书写完到现在,又是一年过去了。

为什么要写这个教程

《Flask Web 开发实战》整个写作以及后续的出版过程有太多的不愉快:

  • 写作要使用 Word,编辑起来非常痛苦
  • 写作语言要很谨慎,不能说太多无关的话
  • 内容太多,涉及的源码太多,常常需要进行大量的更新和改写
  • 书中包含的笔误无法及时更新到书上,只能写在勘误里等待重印

而写作开源电子书就没有这些痛苦了:

  • 使用 Markdown 写作
  • 可以让更多的人一起来完善它
  • 内容可以随时更新

另外,《Flask Web开发实战》作为一本书,必然要尽可能的包含详尽的相关知识。而有的人更希望能有一个简单的入门教程,用来快速对Python Web开发建立一个基本的概念,为后续的学习打下基础。如果你在阅读《Flask Web开发实战》的时候感到吃力,那么这个入门教程就是为你准备的。

教程的名字暂定为《Flask入门教程:使用Python和Flask开发你的第一个Web程序》。

暂定的目录如下:

  • 准备工作
  • Hello, Flask!
  • 模板和静态文件
  • 表单
  • 数据库
  • 用户认证
  • 组织你的代码
  • 测试
  • 部署上线

新的编写形式

这个教程采用了一种新的编写模式,我计划在教程里完整的呈现开发一个Flask程序的基本过程,包括每一个需要执行的命令,每一个文件的编写内容。因此,它不会像一本书一样包含大量解释和提示,除了开发流程外,尽量只保留入门所需的最简信息量,同时优化所有术语的描述。

作为阅读者,则需要自己动手敲出教程里的每一个命令和每一行代码,最终部署一个完全由自己编写的Flask程序。我想这个学习方式大概可以叫做“肌肉复制学习法”,或者是“自己动手跟着做一遍学习法” :p

通过自己动手开发一个程序,初学者可以对开发过程中涉及的概念建立一些自己的理解,后续的深入学习可以进一步加深或是纠正这些理解。

这个想法参考了ZED A. SHAW的《Learn X the Hard Way》系列。如果你对于这个教程的形式设计和内容安排有什么想法和建议,欢迎评论提出来。

写作计划

也许有人已经开始期待了,不过很抱歉,这个教程还没有诞生……好消息是,我已经开始写了,预计会在11月底完成所有内容。教程会连载在专栏,到时也会提供各类电子书文件的下载。

相关链接

 

写作一本技术书,能给一个社区带来哪些改变?

写作《Flask Web开发实战》花费了一年多的时间,在这期间,除了编写5个项目实例和写作外,我还花了一部分时间来和书中涉及的Python库(主要是Flask扩展)打交道。这篇文章总结了这本书的写作给整个Flask社区带来的一些改变。

国内第一本Flask书

虽然国内已经有几本书介绍过Flask,但都是顺便介绍,而不是真正意义上的Flask书。因此,这本书可以说是国内第一本Flask书,很高兴能为国内的Flask社区带来这样一本书。希望这本书能够推动更多人了解和使用Flask,进而为社区贡献更多的力量。

完善多个开源项目

在实际介绍和使用某个库时,总会遇到各种各样的问题,主要有两类:

  • Bug
  • 不完善的用法或实现

Bug不用多说,肯定要处理。对于不完善的用法和实现,如果沿用原来的代码,一来不容易读者理解,二来还需要在书中加进很多不必要的内容。所以,我更倾向于让这些代码变得更好一点。

如果把不完善的实现写到书里,我会觉得非常不舒服。比如说,WTForms本身是支持设置内置的错误消息的语言的,我们可以设为中文,而不用手动写错误消息。但是在Flask-WTF中,因为内部重写了相关方法,导致没法在不使用Flask-Babel的情况下使用内置的翻译。问题来了:如果在第4章介绍Flask-Babel和i18n等相关概念的话,这显然需要占据大量篇幅,并不合适,而且这部分内容已经计划加入到第10章。

为此,书的安排没法改动,那么只好调整Flask-WTF的内部实现,所以就有了这个PR。类似的情况还有很多,比如Firefox支持headless模式后,Selenium中却没有提供和Chrome相同的导入接口;Flask-OAuthlib中,传入access令牌只能使用元组或字典类型,而不能使用更直观的字符串变量传入……

下面是一些写作期间提交的开源贡献:

当然,如果加上其他没有太大意义的文档更新,这个列表还可以更长。
 
值得特别说明的是Werkzeug的这个PR,这个PR对应的bug困扰了我很长一段时间。一开始我把问题归咎到python-dotenv身上,还创建了一个PR(#101),但是维护者迟迟没有回复。后来再次研究,发现可以直接在Werkzeug内部解决,于是创建了#1320,然后被lepture用更好的实现取代了(#1321)。不过,在python-dotenv创建的那个PR倒是促成了Pipenv的这个PR(#2386)。

推动发布新的版本

除了让PR被合并,还要让这些项目发布新的release,这样才能在项目源码公开后,让读者可以正常使用。在我的推动下,Flask-OAuthlib、Flask-Whooshee和Flask-Moment都发布了新的版本。

其他的项目,除了Werkzeug以外,大部分都在整个写作的时间跨度发布了新的版本。尤其重要的是Flask的1.0版本。从书一开始写作,我就直接采用了主分支的代码,书中我直接将版本号写为0.13。如果Flask迟迟不发布新版本,那我会陷入一个很尴尬的境地:要么大胆采用主分支代码,但是可能会出现变动,导致书中的内容不可靠;要么采用旧版本,那书出版后可能会很快面临过时的危险。还好,在写作接近尾声的4月末,新版本1.0发布了。

4个Flask扩展

用于集成Bootstrap的扩展Flask-Bootstrap目前的维护状态很糟糕:上一次release是17年1月,上一次合并commit是17年3月,而且已经很长时间不再处理PR和Issue。

原项目还存在很多问题:Jinja语法不标准、内置基模板引入不必要的复杂度、分页宏不支持传入URL片段值。除此之外,让我决定写新的扩展替代它的最主要原因是因为它不支持Bootstrap 4,而我不能接受在书中引入一个这样过时的项目。

为了解决这些问题,只好写了Bootstrap-Flask。最终决定写替代扩展的时候,书已经完成了三分之二,大量旧的内容和源码都要改写。把书稿和源码从Flask-Bootstrap和Bootstrap3迁移到Bootstrap-Flask和Bootstrap4是一个非常痛苦的过程,到现在还记忆犹新……

对于某些空白的领域,我写了三个扩展来简化集成操作:

5个Flask开源项目

在此之前,完善的Flask开源项目屈指可数,除了Flask官方提供的两个示例程序外,就只有Miguel Grinberg的两个程序。而这本书带来了5个相对比较完善、所有依赖都基于最新版本的开源项目(严格来说,第1个程序比较简单,可以排除在外):

参加北京 PyCon China 2018

说来惭愧,我在北京场开始前一个月才知道国内也有PyCon。9月16号,在聊天群里有朋友建议我去参加PyCon。从考虑去不去,到决定演讲主题,报名闪电演讲,再到变成主题演讲,只花了两天的时间。此时距离大会开始还有26天。

与此同时,新书《Flask Web开发实战》刚刚开始正式发售,有很多事情要做:整理新书的勘误、处理各个渠道读者的问题、写宣传新书的文章、处理淘宝上的盗版书、在知乎和v2ex送书并寄出,这些杂务花费了很多时间,导致幻灯片和对应的演讲稿在大会前一天晚上才最终定稿,原计划的多次试讲练习最终也只完成了1次。

因为练习太少,再加上很久没有演讲了,导致说错不少话,哈哈。演讲的过程也状态连连:幻灯片忘记打开注释窗口,忘记带水上去喝……不过,从后续的反馈来看,整体上来说还不错。我的演讲主题是《自由的Flask》,内容比较简单,主要还是想推介一下Flask,让更多的人了解它。

至于活动本身,对比往年的评价,今年可以说是最好的一届。无论如何,都要感谢组织者们的无私投入。但这并不意味着没有缺点,从我个人的体验来说,主要有这些不足:

  • 文件协作方式很糟糕,会场拍摄的照片没有发送给讲师,而演讲视频既没有在网络上公开分享,也没有发送给讲师,只是被几个提供录像服务的赞助商握在手里。

  • 各个会场的投影设备和尺寸不一,分会场A、B是16:9的电子屏幕,而分会场C则是4:3的投影。我的幻灯片一开始使用默认的4:3,后来问了组织方的老师,改成了16:9……

  • 场地和设备不好,尤其是 C 会场,因为是投影而不是电子屏幕,为了录制效果就关掉了讲台的灯,导致会场很黑,没有拍一张正常的照片。而录像也只录了黑漆漆的幻灯片,看不到讲师。

  • 形式太单调,可以在中间穿插一些聊天、座谈、编程等类似的活动,增加一些面对面的交流和互动,而不仅仅是严肃的讲和听。

除此之外,最开心的事情是和华章出版社的杨福川老师以及其他读者见了面,面对面的交流要比网络上的对话有趣的多。在我那场演讲,有一些我的读者来听,很感谢他们的支持!

下次有机会的话,希望能够带来一场更好的分享,也祝PyCon China能够越办越好。

blank