开始写lbworkflow的文档

文档是一个开源项目很重要的一个组成部分，在我看来一个没有文档的开源项目不是一个合格的项目。最近开始给 django-lb-workflow 写文档。

对我来说喜欢写代码多过写文档，特别是在我英文不灵光的情况下。工作流本身就是一个挺复杂的东西，也不知道最终写出来的文档别人能不能看懂。

目前文档只完成了很小的一部分。里面有一个简单的例子，照葫芦画瓢应当也基本能知道怎么使用了。
文档地址： http://django-lb-workflow.rtfd.io/

lbworkflow预览版

django-lb-workflow 是我开发的一个工作流组件。目前还有很多工作要做，不过主体功能已基本可以使用了。在我看来还远没有到可以发布的阶段，不过还是很想先宣传一下，也希望能收到一些反馈。

关于为啥要挖这个坑，以及一下想法可以见之前的博客： 挖了一个新坑-Django的工作流引擎

演示项目地址：
http://wf.haoluobo.com/
管理员用户：
用户名：admin 密码：password
登陆后快速切换用户：
http://wf.haoluobo.com/impersonate/search/
http://wf.haoluobo.com/impersonate/stop/
流程配置信息查看：
http://wf.haoluobo.com/admin/lbworkflow/

目前还处于零文档的情况，用法只能先看代码了。
测试用例里是一个请假的演示：
https://github.com/vicalloy/django-lb-workflow/tree/master/lbworkflow/tests/leave

挖了一个新坑-Django的工作流引擎

Python和Java相比资源的丰富程度还是要差非常多。就如工作流引擎，Java下商业和开源实现都非常多，Python的就要少很多。因为工作的关系，当初将Python下的开源工作流引擎研究了一遍，始终没有找到合适的解决方案。最终系统中的工作流模块还是自己开发的。

近来决定挖个新坑，开源一个工作流引擎。我希望这是一个认真的开源项目，也希望这个项目能帮忙有相关需求的人解决具体问题。作为一个认真的开源项目，除保证代码质量外，单元测试，文档也都将是必须的。预计这个项目的工作量会有些大，前前后后应当会持续挺长一段时间，希望不要烂尾了。

目前已经开始码代码了，如果感兴趣可以先过去看看： https://github.com/vicalloy/django-lb-workflow

关于这个项目

  • 基于Django且完全不考虑移植到其他框架。
    • 如果考虑移植性系统要复杂很多，也很难保证易用性。
  • 采用半可配置方案以平衡开发及使用的便利性。（注：“半可配置”是我自己取的名字）
    • 数据模型，表单布局，数据校验规则，特殊处理采用编码方式实现。
      • 这部分如要做灵活可配置，配置工具的开发会非常复杂，且配置项非常多，在具体配置的时候也会很麻烦。
      • 这部分功能在开发后改动的情况较少，使用代码实现要灵活的多。
    • 流程节点，审批人，流转关系采用配置方式实现。在管理后台直接通过管理界面进行配置。
      • 根据公司规定，组织结构的变更流程的流转规则，审批人的变动较为频繁，使用代码实现很不灵活，也不方便。
      • 流程节点及节点间的流转这对各类型的流程来说操作都是比较一致的，比较容易采用配置的方式实现。
      • 使用配置实现可以方面的自动画出流程图。
    • 代码生成器
      • 提供代码生成器，只需要完成数据模型的编码，代码生成器会自动生成流程的提交/查看/报表等所有框架代码。

DPress更新Django 1.10支持

DPress 是我很早之前用Django写的一个博客系统。这个博客系统更接近于一个Django入门用的演示程序。管理后台直接使用Django的Admin加少量的定制。页面展示部分，Tag和翻页用的开源APP。系统后台部分的代码极少，主要工作都在前端。
系统开发的初期相关依赖库都只指定了所要求的最低版本，随着相关依赖库的升级，系统已经跑不起来了。
今天把项目重新梳理了一遍，让项目重新跑起来。主要做了下面的一些调整：

  • Django升级到1.10。
  • 原翻页APP似乎已经不再维护，进行了替换。
  • Markdown编辑组件直接使用现成的APP，进一步简化程序代码。
  • 相关的依赖库都明确指定了版本，以免再出现因相关库的升级导致系统跑不起来的情况。
  • 对项目的目录结构做了调整。除默认主题外，其他主题都以APP方式进行安装。
  • 很久没有用过SAE，不知道之前的SAE支持代码还能不能用，因此直接去掉了SAE相关支持。

调整好后并未进行严格的测试，如遇到什么问题，可以直接在GitHub上提交Issue。

迁移到linode

看了一下自己在Webfaction的余额还有23$，既然剩余的钱不是太多，倒不如直接迁移到linode。
目前迁移已经全部完成，感觉迁移后访问速度提高不少。

将服务全部重新部署一遍虽不算多麻烦，但作为纯体力劳动多少有些枯燥。之前就在想用Docker来部署自己的服务，这样迁移的时候要方便很多。考虑到主机羸弱的性能，且迁移服务器毕竟是小概率事件也就作罢。

此次迁移顺便给博客加上了HTTPS的支持，证书用的是 Let’s Encrypt 。

计划将服务器迁移到linode

一直用的是 WebFaction 的共享主机。WebFaction可能算是共享主机里功能最强大的，Python/Ruby/PHP啥的各类服务都可以支持。WebFaction总体使用还行，但总是有些不是很爽的地方。

  • 访问速度非常的慢。
  • 相比VPS自由度还是要低不少。前一段时间想给Blog加上HTTPS的支持，不过由于共享主机的限制，非常麻烦。

今天去 linode 看了一眼，居然出了 5美元/月 的方案。其实很早之前就已经考虑过linode，只是当时 20美元/月 还是感觉有些小贵。一时心动，立马把linode账号注册好，就等什么时候有时间去把服务器迁过去了。

最好的技术构架

最近看到一篇文章，里面谈通过Java替换之前的Python实现使服务的响应速度得到了很大的提升。同时又看到有公司通过Go替换Scala，取得了不错的效果。

似乎是Go>Java>Python？显然不是。

在项目启动的初期你很难预计到自己的项目最终将长成什么样子，最终能达到多大的规模。你能做的只是给出一个较清晰的中短期规划以及一个较模糊的长期规划。然后思考如何在满足要求的情况下尽快的把东西做出来。毕竟事情不会不完全按照你的预期发展，看上去在完美的构架也不可能一直完美下去。根据需求持续的演进才是正道。

关于性能：

由于需要服务海量用户，因此在提到互联网应用的时候很多人都对高性能有着异常的执着。经常听到有人说XX语言慢，XX框架慢。但实际上脱离了需求和构架单纯谈的语言/框架性能是没有意义的。就如Instagram至今依旧用着以慢著称的Django（注：其实我也挺好奇为啥没有将Django换掉。按照我的理解Django的有点是功能及资源丰富，性能方面确实没啥优势。按说Instagram对Web框架的功能需求应当非常少，换个更轻量高效的似乎会更好些？）。

另外优化的成本实际上也挺高，在早期用户不多的时候对性能的优化或许还不如直接加硬件来的实惠。

12306刷票工具

项目地址： https://github.com/vicalloy/12306-ticket-checker

只是在刷出票后发送提醒消息，并不能自动购票。在收到消息后还是得拼手速。 脚本用 Python3 实现，可挂到服务器上 24 小时刷。

前言

总体来说火车票应当是越来越好买，因此一直没怎么太操心。哪知道今年票似乎没有很好买，最近在 12306 刷了几天一张票都没看到。广大抢票软件又都只支持 Windows 系统，作为 Mac 用起来不是太方便。
弄了一个小脚本挂到服务器上，在查询到有符合条件的车票后将通过Slack将消息推送给我。

注意事项

  • 脚本采用python3开发，请使用python3运行该脚本。
  • 在刷到票后，采用 Slack 发送通知消息，因此请先创建Slack的Team。在创建好Team后，创建一个名叫ticket的channel,并申请一个Bot用于发消息。如希望采用其他的通知途径，请自行修改12306.py中的send_message实现。

后记

一大早就刷出了一大波票，不过等我兴冲冲的打开手机客户端一查，连个票的影子都没看到。可能是经过几年的发展抢票市场也日渐成熟，所有的票都在第一时间给抢票软件给刷走了。

TODO

目前这个脚本只能实现余票的提醒功能，但理论上要实现自动购票的功能并会太难。buy.py中给出了登陆的基础实现，不过考虑到实现所有功能所要付出的时间成本因此不打算继续了。
注：也是因为票被秒光的速度太快，估计折腾完也用处不大。

自动购票最大的障碍还是来自于12306的验证码。

验证码的处理思路

手动处理验证码

手动处理验证码应当是最简单有效的处理方式，当前缺点也很明显，无法做到全自动。Slack的API非常强大且易用，通过Slack的”Real Time Messaging API”，我们可以利用Slack实现交互。在需要输入验证码的时候，通过Slack将验证码推送到用户，用户在完成验证码输入后，系统自动处理之后的业务逻辑。

自动识别

要做好验证码的自动识别时间就比手动处理要麻烦多了。如果不是想卖给黄牛我个人是觉得没必要打自动识别的主意了。

12306的验证码可以分为2部分，最顶部的文字以及下方的8张图片。

文字的变形其实并不算太大，相信以现在OCR的水平识别率还是挺高的，重点是下发的8张图片。12306的验证码图小分辨率低，不说机器，要人来识别都不容易。如果纯粹根据机器学习来做图片识别，即使学习库再大效果也不会好到哪去。

最有效的还是”笨方法”，让系统频繁的去请求12306的验证码，然后手工将所有图片打上Tag。考虑到12306的图库不会太小，给图片打Tag必然会有很大的工作量，如果没有利益驱使是百分百做不来的。
另一方面，即使前期做了非常多的准备工作也很难保证12306不会添加新的图片。在遇到不认识图片的时候最简单的方法自然是先将图片记录下来等待手工加Tag，另一方面重新刷新验证换个自己认识的。
Google有提供上传图片进行搜索的功能，可以把图片上传到Google然后得到图片的关键字(当然精确度不会太高)。在图片资料库不够完整的时候也可以利用Google来猜些图。

Django 2.0放弃Python 2的支持了

Django的master分支已经正式切换到Django 2.0了，其中的一个commit就是去掉Python 2支持的相关代码。这意味着从Django 2.0开始，Django将要放弃Python 2.x的支持。
对于这个消息，Reddit上一片喜大普奔。对我而言这绝对是一个好消息，毕竟我还是非常喜欢Python 3的type hints。如果放弃Python 2的支持，他们还是很有希望会加入type hints的支持。
从去年开始，不少最新的Python库只支持Python 3。另外type hints加入让甚至可以说让Python更像一个新的语言。或许Python 2终于要开始淘汰出局了。对我而言，除了老项目的维护外，新项目似乎没有什么理由再支持Python 2。

注：根据Reddit上的回复，由于model里用了太多的magic，model这部分要加入type hints还有很多问题要解决。不过可以肯定的是type hints绝对会是今后Python库的大方向，Django也是会支持的。