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

更新 3.4 后,将 release 日志合并到本文。

3.4

2018-10-06

  1. 前后端组件更新
  2. 图片

    默认显示缩略图,避免图片太大导致加载过慢和爆流量等问题。

    限制图片高度,避免手机截图太长带来阅读不便。

  3. 邮件

    邮件发送服务切换到阿里云,解决 qq 邮箱拒收的问题。

    发件邮箱改为 [email protected]

  4. UI 微调

  5. 修复文章发布页 safari 加载 javascript 报错的问题

  6. 加强 CI,自动上传静态文件到对象存储

3.3

2017-06-18

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

在考完试未开始搬砖之际,整理了一下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),于是我就悲剧地躺坑了。

3.2

2017-01-22

从3.1起,功能和界面都不会进行大改了,也没什么TODO日程了,主要是对日常使用中发现的bug进行修补,然后每年更新下release。

基于3.1,改进了以下问题:

  1. 全站HTTPS

    Letsencpty + Cloudflare Full SSL

    因为贫穷付不起500刀每月的自定义证书,前段还是用共享的证书。

  2. HTTP/2

    全站HTTPS的原因。

  3. 界面调整

    • 更新友链
    • 更新年份
    • 调整tag颜色
    • 解决文章数超过100导致修改页表格拉伸的问题
  4. 功能调整

    • 实现回复时引用文本框
    • 支持emoji
    • 文章中链接改为在新页面(tab)中打开
    • markdown代码块支持旁注式指定高亮语言
    • 框架和依赖模块升级到最新,好像没啥大变化
  5. CI调整

    原来的架构是这样子的:push代码后,触发git的hook,于是docker hub进行build,完成后通过hook触发服务器,服务器pull image后通过docker-compose移除并重新创建拉起nginx+mysql+binsite server。

    但随着使用,该方式的问题逐渐暴露出来:每次服务器通过docker-compose移除原有容器时往往会失败,然后不得不手动登录进行移除,说好的CI呢。

    其次是每次push代码docker hub都会花费若干分钟重新build,然后服务器重新pull image,但大多数情况下只是代码变了而运行环境没变,这种做法实在是浪费时间和流量。

    实际上,将nginx、mysql和binsite server捆在一起也是不合理的,虽然binsite server依赖于mysql,需要nginx作为反代,但并不意味着后两者要被binsite server所“独占”。这个问题直到我上次在该机器上部署一个依赖于mysql的签到服务时才发现,此后一直耿耿于怀。

    这两天对部署方案进行了一番思考,决定还是打破三者之间的耦合,将mysql和nginx作为独立的服务,新架构如下:

    mysql和nginx独立存在,其中binsite通过link连接mysql,nginx通过ip和port连接binsite。为了固定binsite的ip来保障nginx能够反代,因此新建了bridge,写死binsite的ip。

    当binsite代码变化时,只触发git去pull代码,然后restart容器。

    当binsite环境变化时,需要手动pull镜像,然后重新创建容器。

3.1

2016-06-03

binsite版本迭代实在是太快啦。今年1月底才上线3.0,并立下flag:

由于人生即将跨入新阶段,因此可能不会有4.0了

没想到在短短几个月里修修补补Commit了十几次,非常不爽,恰逢做完毕设没啥事干,又顺利拿到驾照心情愉快,嗯,那就拿出两天稍微重构下吧~

逻辑没啥大改,因此不好意思叫4.0,嗯,就叫3.1吧~相对于3.0,主要做了以下修改:

  1. SAE开始坑爹了,花式新增收费条目,一个月算下来还贵过租一台VPS,我辛辛苦苦积累了两年多的云豆在两三个月内瞬间烧完,无奈只能搬家。不过也好,本来就有台机器利用率不高,就把binsite迁到上面去了。这样做好处在于在代码上不用受平台限制而作出妥协,坏处在于部署还是挺麻烦的,还要担心被别人爆菊。
  2. 代码迁移Python 3(原受SAE限制只能用2)。
  3. 使用独立邮件模块(原使用SAE的MAIL服务,非常辣鸡,发封邮件慢时延迟达到一小时)
  4. Docker化部署,集成到Compose
  5. 修正访客无法评论的问题(之前由于疏忽忘记对访客下发token,导致提交的评论因缺少token被服务端拒绝)
  6. 修正文章图片无法放大的问题
  7. 修正访客提交评论时邮箱不合法导致页面错乱问题
  8. 修正移动设备点击navbar后页面自动滚动到页首的问题
  9. 移除照片模块
  10. 前端重写,使用侧边单导航条,调整整体风格为暗色调。由于侧边栏不够位置展示分类,因此换用TAG块来展示。
  11. 更换编辑组件。之前采用富文本编辑+markdown结合的编辑模式,发现不好用,用着用着都是在Quiver写好后粘上来,所以干脆改成纯markdown+预览的编辑模式:
  12. 一些SEO优化

最后按照惯例,截一张旧版本的首页图:

如果您发现binsite3.1的bug,欢迎在本文评论或直接发邮件给我([email protected])。感谢。

3.0

2016-01-25

不知不觉中,binsite已经迭代到第三个版本了。距离binsite2.0的发布,已经一年了呢,截了一张2.0的首页作为纪念:

3.0版本,无论是设计、前端,还是后端,都重构了一遍。历时14天,于昨天部署上线,今天修了bug后在Google提交sitemap,写下此文。

问题

设计

用了一年,有点厌倦了深色背景+毛玻璃的设计。此外对Bootstrap的圆润风格也审美疲劳了,希望换换口味。

前台

  • 由于网页用到了几张深色大图作为背景,在网络较差的情况下背景图load不出来,然后字又是白色,导致什么都看不见

  • 编辑器不支持markdown

  • 冗余代码过多(看自己一年前的代码真有种吐槽的冲动)

  • 完全没考虑SEO

后台

  • 评论模块偶尔失灵

  • 通知模块长期失灵

  • Django框架版本老旧(1.5)

于是闲得蛋疼的我就开始开发3.0版本了。

特性与改进

设计

如你所见,毕竟是业余的,见仁见智了。

引入本站形象代言人——小北方:

前台

  • 重写代码,模版继承关系上更合理

  • 去除首页、工具、项目管理等页面

  • 修改文章页面重写

  • 文章目录按时间排序,取消分页,改为一页展示完

  • 更换照片流组件

  • 更换富文本编辑器,二次开发以支持markdown和富文本双向转换

  • 弃用Bootstrap,换用纯CSS的Pure

  • 代码高亮

  • 把各个库更到最新稳定版本

  • 压缩静态文件

  • 添加favicon

  • 添加sitemap

后台

  • Django框架升级到1.9

  • 重构,精简代码,模块按APP解耦

  • 重写评论和通知模块

  • 建立文章插图索引,维护文章和插图之间的映射

  • markdown文本渲染

  • 上传授权签名

  • 加强管理页面验证

  • 引入文章版本管理,可以回滚到某个历史版本或者恢复删除文章

  • 文章和照片添加状态字段,便于控制

  • 页面压缩

  • 更换静态文件存储方案,目前是七牛+腾讯云的对象存储(多的是流量,哈哈哈哈哈)

吐槽

如果上天给我一次重来的机会,我绝对不会用Pure框架而是继续用Bootstrap!!

为啥?

组件不齐全,比如说进度条、浮动栏、模态框等等等等都没有~~~响应式做得太烂,官网给出的几个响应式导航条非常简陋,缺乏fix-top、align-right等等等等特性~~~简陋也就算了,关键还卡,在电脑上还好,在IOS9.2的Safari浏览器上一点,过渡动画卡得哭爹喊娘(ipad air2、iphone 6s实测)。卡也就算了,关键是还有bug,当页面快速滚动的时候,竖直导航条下部神秘消失。天啊,这些问题难道都是我第一个遇到吗?

github一看,果然有相关issue,然而并没有什么卵用,项目已经n年没有实质上的更新了。反观Bootstrap,4.0的Preview已经出了,真是呵呵哒。

对于我这个业余到不能再业余的前端来说,各种前端问题折腾得我死去活来,耗费了80%以上的时间来搞布局和样式,最终搞出目前的版本:是不是很简洁呢?其实是复杂的我不会搞啊T T。

这次3.0版本之所以能在那么多坑的情况下两周搞完,多亏了贯彻面向Google、面向Github、面向StackOverflow的开发观(滑稽),大大提高了开发效率。可悲的是这三剑客,有一个曾经被墙过,有一个一直被干扰,还有一个至今在墙外,不得不说是一种悲哀。有了他们,码农们可以少走多少弯路(滑稽)。

不管怎么说,3.0还是在这个2.0版本发布一周年之际上线了。由于人生即将跨入新阶段,因此可能不会有4.0了。所以我会努力完善这个版本。如果您发现binsite3.0的bug,欢迎在本文评论或直接发邮件给我([email protected])。感谢。

2.0

2015-01-26

binsite2.0全新改版,终于在今天(非)正式上线啦!

本来打算拖延一个星期将一些功能完善后再上线的,结果由于昨晚整理SCS的时候错误地执行了递归删除命令导致整个bucket被清空了,这意味着binsite的css,js,尤其是文章里的图片统统都没啦!!!

请允许我作一个悲伤的表情。js和css丢了就丢了,但是文章里的图片这么办啊啊啊。Oh,找找缓存?不好意思,昨天上午刚用Cleanmymac清理完,最终只抢救到6幅。于是我花了整整一个晚上在补截以前文章里的图。至于有些实在是补不回的,就只能修改文章结构去掉了。

由于js和css丢了的缘故,还处于beta的binsite2.0不得不提前上线(1.0已经崩得不成样子了)。But,新版本的上线总是一件高兴的事情。

binsite1.0截图

binsite2.0 新特性

  1. 前端重构

    • 适配移动设备

    • 优化模版继承与渲染

    • 重新设计界面

    • 增加文章修改页面

    • 优化评论模块,添加回复功能

    • 移除tag功能

    • 重写相册

  2. 后端优化

    • 代码精简

    • 取消对图片的签名,允许缓存

    • 实现回复提醒功能

  3. 更换图片上传方式

    • 更换了图片上传组件,由原来的前端->server->SCS改进为前端->SCS,节约了一倍的流量。

    • 原来受到限制只能上传大小不超过1M的图片,如今无限制。

更新记录

2015-1-27

  1. bug修复

  2. 改变文章的url形式,旧形式url依然可以访问

2015-1-29

  1. 相册缩略图延时加载

  2. 增加文章修改页面

  3. ipad竖屏适配

2015-2-17

  1. 首页侧边滑块在PC浏览器访问时允许点击并导航到相应页面

  2. ipad和手机一样始终显示顶部导航条

  3. bug修复

2015-2-25

  1. 首页侧边滑块在动画完成之前屏蔽hover

  2. 重写rgb转换工具,移除剩余两个工具(使用频率太低)

2015-2-26

  1. 修复文章列表的第五页按钮不右移的bug

  2. 将之前买U2414H写的屏幕亮点工具加入工具栏

  3. 重写项目管理页面

2015-2-28

  1. 修复评论页面允许评论者信息为空的bug

  2. 增加评论页面admin标识

  3. 过滤所有评论的html标签

  4. 实现评论提醒

2015-3-30

  1. 和广告哥作斗争,动态添加csrf

  2. 优化手机浏览界面

2015-5-11

通过响应式方法调整图片大小,解决当调整浏览器宽度时,可能出现图片越界的问题。

2015-6-20

新增发表文章的API。

如果您发现binsite2.0的bug,欢迎在本文评论或直接发邮件给我([email protected])。感谢您的访问。

1.0

2014-09-16

本地调试完毕后,做了一下工作:

  1. 将网页中引用到的js和css库链接到CDN上

  2. 将引用图片存放到新浪云存储并外链引入

  3. 对图片添加url签名防止盗链

  4. 将代码部署到SAE

相关应用的整合工作暂时搁置,接下来首要任务实现图片上传功能。

另外。。。由于BUG众多,陆续修复中。