本文发自 http://www.binss.me/blog/binsite-3.3-release/,转载请注明出处。

终于考完读书阶段的最后一门考试,心如死灰,如同当前高考考完数学那般绝望。

在考完试未开始搬砖之际,整理了一下TODO list,发现不断修修补补的binsite又累积了一些问题,遂决定迭代一个小版本😁。

  1. 迁移至Python 3.5

    看了今年instagram在今年PyCon上的 演讲

    由于使用的就是 uwsgi + django 的方案,心情澎湃地迁移到Python3.5。虽然框架已经完全支持Python3.5,但业务代码果段GG,出现了传说中的UnicodeEncodeError

    折腾了一个晚上,总结下来:

    如果logging需要输出到文件,则需要在相应handler添加'encoding': 'utf8',,如:

    'handlers': {
        'log_access_file': {
            'level': 'WARNING',
            'class': 'logging.handlers.WatchedFileHandler',
            'filename': '/var/log/binsite/django-access.log',
            'formatter': 'verbose',
            'encoding': 'utf8',
        },
        ...
    }

    输出到控制台则需要在uwsgi配置文件中添加环境变量:

    env = LANG=C.UTF-8
    env = LANGUAGE=C.UTF-8
  2. 前端代码端串行

    有用户评论,说我的指令有误( https://www.binss.me/blog/learn-docker-with-me-about-commands/ ),我一开始怀疑是docker又瞎JB更版本导致不兼容,但之后试了却发现指令没问题,因此也就没有重视。

    在本次开发中,偶然发现某些代码段会串到其它代码段。随后进行了多次访问测试,出现概率约为十分之一。我首先怀疑是自己魔改的后端markdown解析扩展出了问题,但调试后发现无论在中间节点的翻译还是最终生成的结果都正常,返回给前端的数据也一致。因此推测是前端代码高亮显示插件的锅。更新rainbow到最新版本后问题不再复现。

  3. 组件更新

    前后端组件更新到最新的稳定版。其中jQuery不再兼容古董浏览器,直接上3。

  4. 回复评论

    原来实现的回复评论功能比较simple:用户点击回复按钮后,自动获取该回复信息并将 回复 xF 的 xxx: 插入评论框,但由于这些内容是用户可编辑的,导致用户不小心可能把这些内容给改了。于是在新版本中,实现为:点击回复按钮后,直接生成新的readonly input显示回复 xF 的 xxx:,后端进行处理生成最终评论。用户点击其它回复的回复按钮会更新内容,点击该input会移除内容:

  5. 评论和通知

    说到以往版本最大的问题,莫过于经常收不到用户评论的通知邮件。往往到若干天后去翻后台,才发现新增了几条评论,显然这样的博客毫无互动可言。

    在之前的版本中,用户评论后,前端产生两个POST请求,一个触发记录评论,一个触发发送通知邮件。之所以用那么蠢的方法是因为评论组件用了别人的库,它从接收请求到返回全都一手包办了,没有机会插手。于是这次读了一下库的代码,采用了比较dirty的办法来解决:将请求发给到自己的handler,由其进行pre handle后再手动调用库的handler记录评论,最后再post handle流程中发送通知邮件,保证了请求的atomicity。

    此外,这次重新思考了 评论的是否需要填写邮箱 这个问题。在3.0之前邮箱都是必填项,然后发现基本都是乱填。于是在3.0,干脆把邮箱这一栏去掉了,当时的想法是,反正没用。

    但此次考虑到博客的互动性:当我回复了用户的评论时,应该如何告知它我已经回复了?难道要他们总是来binsite翻翻作者回复没?

    因此在3.3中,又把邮箱加了回去,但只作为选填项。如果用户填写了邮箱,那么在我对其进行回复后,将发送一封邮件到其填写的邮箱中:

    实现完毕,本地测试通过后,将其部署到server上发现邮件发不出去,返回错误554 DT:SPM。显然是被认为是SPAM然后拒收了,因为我的邮件通知是通过smtp登陆自己的163邮箱然后发送邮件来实现的。

    这时我才恍然大悟,这才是丢邮件的罪魁祸首。

    解决办法自然是使用专门的邮件发送服务。我选择了AWS的SES,开通后会处于sandbox,需要提交工单申请开放。出乎意料的是工单不到一小时就批了,还主动帮我提额到每天50000封邮件,赞。

    经测试,除了QQ邮箱之外其它邮箱基本都可以送达且不会被当成SPAM扔进垃圾箱,基本达到预期目标。

  6. 更新图片上传API

    当我将功能测试完毕,愉快的写下本文时,发现无法上传图片到腾讯云。一开始还以为是不小心改了什么代码,结果回滚到3.2发现依然失败!

    返回的错误是ERROR_CMD_BUCKET_NOT_SUPPORT_OPTIONS,根据文档的意思是bucket不支持跨域访问,检查发现没问题。

    浪费了两个小时后,发现原来是腾讯云COS升级到4后,上传URL中的v1竟然改成v2了。然后它在2017-05-10默默更新了文档:https://mc.qcloudimg.com/static/qc_doc/db1c5b13d0b955ccc91ba5a896ec6daa/7368.pdf),留下了我这样懵b的去趟坑,也是服气。