vicalloy的庄家

迁移到linode

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

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

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

vicalloy的庄家

计划将服务器迁移到linode

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

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

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

vicalloy的YY 编程

最好的技术构架

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

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

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

关于性能:

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

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

岁月的痕迹

bye,2016

希望2017可以有些新气象,愿2017可以更好。

vicalloy的庄家

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也是会支持的。

编程

Python 3的type hints

近年来新出的语言Go、Rust、Swift都无疑例外的是静态类型。随着软件的越来越复杂,动态语言“太过随意”的缺点也越来越明显。此外随着IDE的发展,静态类型语言“繁琐”的缺点也得到了很好的规避。
在学习Swift的时候,Swift的类型推导给了留下了很深的印象。类型推导或许是现阶段兼顾类型检查以及动态语言简洁的最佳解决方案。
Python从3.5开始加入了type hints(类型注释)。

从名字“type hints”就可以看出,只是类型注释并不是强制要求。由于只是“注释”,“type hints”需要第三方工具的配合。你需要使用Mypy来对代码进行语法检查。另外PyCharm在新版本中也加入了对“type hints”的支持。

对我而言“type hints”无疑是一个非常棒的特性,让Python也具备了类似Swift的类型推导功能。希望日后的各类Python都能加入type hints的支持。另外就希望各类开发工具可以充分的利用type hints特性。

注:
Swift中使用“?”表示option,Python里则需要写成Optional[str]相比之下有些太过繁琐。

路过

亚庇

第一次是同老婆一起,这次多了一个宝宝。之前一直想去长滩岛,考虑到带着父母和宝宝,长滩岛还得车船联运有些麻烦,最终还是选择了亚庇。

水上清真寺。只在外面拍了个照,并没有进去。

沙巴大学里的码头。

由于宝宝要睡觉,很晚才上岛,几乎没怎么玩就回来了。

传说中的最美落日。不过在我看来海上落日似乎都差不多,并未感觉有什么特别的。

编程

Docker

很早之前就听过Docker,当时感觉对个人使用而言Docker似乎派不是太大的用场。

  • Docker非常类似虚拟机。如果单纯出于统一开发环境的考虑,直接用虚拟机似乎还更直接一些。
  • 虚拟机+ Vagrant也可以方便的对虚拟环境进行管理,Docker在这方面似乎也木太占优势。
  • Docker通过仓库分发Images,似乎同直接复制虚拟机的镜像效果也差不了太多。
  • 由于并不需要管理大量的服务器,直接手动部署或用部署工具操作也不会太过复杂。用Docker还得学习Docker的使用,似乎也不太值得。

近期由于Discourse的缘故,实际用了一下Docker。感觉Docker确实是个不错的东西,不论是开发还是运维Docker都是值得使用的。

Docker有啥好处

  • Puppet, Chef等传统的运维工具可以实现应用的批量以及自动化的部署。但实际工作中,用户的系统千差万别,可能换个系统环境你的脚本就挂了。
  • 对开发人员,可以使用统一的虚拟机作为开发环境。但虚拟机无法直接部署到生产环境。生产环境、测试环境、生产环境无法做到统一。很可能开发环境跑的好好的,一到生产环境就出各类莫名其妙的问题。
  • Docker 容器的启动可以在秒级实现,这相比传统的虚拟机方式要快得多。 其次,Docker 对系统资源的利用率很高,一台主机上可以同时运行数千个 Docker 容器。
  • 使用Docker可做到“各类环境”的完全统一。不论用户原始的环境是什么,真正跑应用的环境都是一样的。由于在开发阶段就已经把环境完全整好了,只需要简单的几个命令即可完成部署,Docker的部署异常简单。由于不用考虑系统的差异,Dockerfile写起来相对来是比较简单的。

相关资源

见闻

黄山

第一次自驾出行,第一次带着爸妈,拉着宝宝一同出行,也是第一次重装露营。

呈坎

徽派村落的代表无疑是宏村。不过不管是宏村还是呈坎现在去的都不是季节。之所以去呈坎完全是因为顺路,看地图呈坎就在去黄山的路上,而且在高速边上。

人文的景点更多看的是文化及历史,就如我当初看《人间词话》时也曾对文中的白石很感兴趣,甚至想去探访白石在杭州所留下的痕迹。我终归不是一个文化人,少了对文化及历史的好奇后呈坎只是一个普通的小村落。

论名气,呈坎完全无法同宏村西递相媲美,因此商业化程度也好低很多。里面的村民对游客都有些过于热情,这个热情多半来源于经济目的,他们的讲解收费是10¥。作为非文化人,对村子背后的故事并无多少兴趣,反倒觉得有些打扰自己游玩的兴致。

呈坎

汤口

黄山脚下的小镇。
想09年第一次来黄山的时候,大巴把我放到一个鸟不拉屎的地方,旁边只有一个不起眼的小店。当时我都怀疑是否是司机把我放错了地方。短短的几年,汤口已经变得有些过于繁华了,这次都开始堵车了。
黄山作为一个固定的景点,接待能力终归有限,能拓展的周边也极为有限。简单的说整个旅游市场的规模也只能这么大,能开发的潜力极为有限。汤口依托黄山发展起来,不知能走多远。

DSC06641

黄山

黄山本身并无太多变化,和第一次见时一样美,但人多。这次的时间并不是周末,虽受免票的影响人会多些,但有些太多。到处都是排队,连天都峰都排队。
至少近期几年是不会再去黄山了,黄山虽美,但人多到有些影响体验了。

DSC06694

露营

帐篷、睡袋、背包都已经买了很久了,一直几乎着要去露营却一直没机会。这次也算是作死,带着一大家子,抱个宝宝,背个大包去黄山露营。本还想继续做死背包徒步上山,老婆不同意才改为索道。没有爬山,外加一路排队,虽是重装但并未感觉太累。

DSC06707