DPress 是我很早之前用Django写的一个博客系统。这个博客系统更接近于一个Django入门用的演示程序。管理后台直接使用Django的Admin加少量的定制。页面展示部分，Tag和翻页用的开源APP。系统后台部分的代码极少，主要工作都在前端。
系统开发的初期相关依赖库都只指定了所要求的最低版本，随着相关依赖库的升级，系统已经跑不起来了。
今天把项目重新梳理了一遍，让项目重新跑起来。主要做了下面的一些调整：
调整好后并未进行严格的测试，如遇到什么问题，可以直接在GitHub上提交Issue。
看了一下自己在Webfaction的余额还有23$，既然剩余的钱不是太多，倒不如直接迁移到linode。
目前迁移已经全部完成，感觉迁移后访问速度提高不少。
将服务全部重新部署一遍虽不算多麻烦，但作为纯体力劳动多少有些枯燥。之前就在想用Docker来部署自己的服务，这样迁移的时候要方便很多。考虑到主机羸弱的性能，且迁移服务器毕竟是小概率事件也就作罢。
此次迁移顺便给博客加上了HTTPS的支持，证书用的是 Let’s Encrypt 。
一直用的是 WebFaction 的共享主机。WebFaction可能算是共享主机里功能最强大的，Python/Ruby/PHP啥的各类服务都可以支持。WebFaction总体使用还行，但总是有些不是很爽的地方。
今天去 linode 看了一眼，居然出了 5美元/月 的方案。其实很早之前就已经考虑过linode，只是当时 20美元/月 还是感觉有些小贵。一时心动，立马把linode账号注册好，就等什么时候有时间去把服务器迁过去了。
最近看到一篇文章，里面谈通过Java替换之前的Python实现使服务的响应速度得到了很大的提升。同时又看到有公司通过Go替换Scala，取得了不错的效果。
似乎是Go>Java>Python？显然不是。
在项目启动的初期你很难预计到自己的项目最终将长成什么样子，最终能达到多大的规模。你能做的只是给出一个较清晰的中短期规划以及一个较模糊的长期规划。然后思考如何在满足要求的情况下尽快的把东西做出来。毕竟事情不会不完全按照你的预期发展，看上去在完美的构架也不可能一直完美下去。根据需求持续的演进才是正道。
关于性能：
由于需要服务海量用户，因此在提到互联网应用的时候很多人都对高性能有着异常的执着。经常听到有人说XX语言慢，XX框架慢。但实际上脱离了需求和构架单纯谈的语言/框架性能是没有意义的。就如Instagram至今依旧用着以慢著称的Django（注：其实我也挺好奇为啥没有将Django换掉。按照我的理解Django的有点是功能及资源丰富，性能方面确实没啥优势。按说Instagram对Web框架的功能需求应当非常少，换个更轻量高效的似乎会更好些？）。
另外优化的成本实际上也挺高，在早期用户不多的时候对性能的优化或许还不如直接加硬件来的实惠。
希望2017可以有些新气象，愿2017可以更好。
项目地址： https://github.com/vicalloy/12306-ticket-checker
只是在刷出票后发送提醒消息，并不能自动购票。在收到消息后还是得拼手速。 脚本用 Python3 实现，可挂到服务器上 24 小时刷。
总体来说火车票应当是越来越好买，因此一直没怎么太操心。哪知道今年票似乎没有很好买，最近在 12306 刷了几天一张票都没看到。广大抢票软件又都只支持 Windows 系统，作为 Mac 用起来不是太方便。
弄了一个小脚本挂到服务器上，在查询到有符合条件的车票后将通过Slack将消息推送给我。
ticket的channel,并申请一个Bot用于发消息。如希望采用其他的通知途径，请自行修改12306.py中的send_message实现。
一大早就刷出了一大波票，不过等我兴冲冲的打开手机客户端一查，连个票的影子都没看到。可能是经过几年的发展抢票市场也日渐成熟，所有的票都在第一时间给抢票软件给刷走了。
目前这个脚本只能实现余票的提醒功能，但理论上要实现自动购票的功能并会太难。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的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也是会支持的。
近年来新出的语言Go、Rust、Swift都无疑例外的是静态类型。随着软件的越来越复杂，动态语言“太过随意”的缺点也越来越明显。此外随着IDE的发展，静态类型语言“繁琐”的缺点也得到了很好的规避。
在学习Swift的时候，Swift的类型推导给了留下了很深的印象。类型推导或许是现阶段兼顾类型检查以及动态语言简洁的最佳解决方案。
Python从3.5开始加入了type hints（类型注释）。
def greeting(name: str) -> str:
return 'Hello ' + name
从名字“type hints”就可以看出，只是类型注释并不是强制要求。由于只是“注释”，“type hints”需要第三方工具的配合。你需要使用Mypy来对代码进行语法检查。另外PyCharm在新版本中也加入了对“type hints”的支持。
对我而言“type hints”无疑是一个非常棒的特性，让Python也具备了类似Swift的类型推导功能。希望日后的各类Python都能加入type hints的支持。另外就希望各类开发工具可以充分的利用type hints特性。
注：
Swift中使用“?”表示option，Python里则需要写成Optional[str]相比之下有些太过繁琐。
第一次是同老婆一起，这次多了一个宝宝。之前一直想去长滩岛，考虑到带着父母和宝宝，长滩岛还得车船联运有些麻烦，最终还是选择了亚庇。
水上清真寺。只在外面拍了个照，并没有进去。
沙巴大学里的码头。
由于宝宝要睡觉，很晚才上岛，几乎没怎么玩就回来了。
传说中的最美落日。不过在我看来海上落日似乎都差不多，并未感觉有什么特别的。
很早之前就听过Docker，当时感觉对个人使用而言Docker似乎派不是太大的用场。
近期由于Discourse的缘故，实际用了一下Docker。感觉Docker确实是个不错的东西，不论是开发还是运维Docker都是值得使用的。