无责任乱评

Mark-关于技术发展趋势

前一段时间和朋友讨论技术的发展趋势。
在这里做个记录,等3年之后再回过头来看看今天的预测。

我认为:

  • 近几年JS(HTML5)的发展速度很快。虽然JS有各种天生的缺陷,但JS在进化,在特定的场合中JS的某些缺陷问题不是太大。
  • JS或许并不是一个完全体,但JS是目前的各种开发技术中很有潜力的一个(特指UI部分)。至少目前还未看到比JS在UI方面更有潜力的东西出现,在今后几年会不会有也很难说。
  • 今后JS的应用还会持续走高。采用存JS开发或是混合应用(或类似React Native的技术)会越来越多,很占领很大一部分的开发市场。
  • 不太看好JS在服务端的发展,至少我不是很喜欢写Node.js。

朋友认为:

  • JS有很多天生缺陷,成不了主流
    • 注:我个人觉得目前JS已经很主流了。
  • 巨头间的博弈。一旦跨平台,平台独占的优势将不再明显。处于优势地位的巨头不欢迎跨平台技术。
    • 注:iOS和Android已不存在谁是绝对优势。且即使是Apple平台也有桌面和移动端的跨平台需求。或许巨头们不是很心甘情愿的跨平台,但也很难阻止。

注:

有一种说法是当你做出选择后就会在潜意识里不自觉的强化自己的选择。
在我看来因为朋友是做Apple平台的Native开发,因此会不自觉的对Web技术有所抵触。
我Web和Native开发都做过,自我感觉会相对公正些。

vicalloy的庄家

开始写lbworkflow的文档

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

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

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

vicalloy的庄家

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

vicalloy的庄家 编程

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

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

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

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

关于这个项目

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

DPress更新Django 1.10支持

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

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

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

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来猜些图。