分类目录归档:vicalloy的庄家

招聘网站岗位信息更新监控工具

项目地址: https://github.com/vicalloy/jobmonitor/

image codecov.io

一个监控招聘网站工作岗位更新情况并发送通知的小工具。很早之前写的一个小脚本,近期重构了一下,让这个脚本可以更方便的扩展。

目前只做了前程无忧以及V2EX的支持,欢迎添加其他网站的支持。

目的

  • 招聘网站的问题
    • 招聘网站每天都会显示大量的岗位更新,但大多岗位都是常年发布,要从这些岗位里过滤出真正更新的岗位并不容易。
    • 招聘网站的搜索功能还不够完善,做不了高度个性化的定制化搜索条件。
    • 专业论坛的招聘版块,几乎没有搜索功能。
  • 这个工具可以做什么
    • 支持定制招聘网站搜索条件,并对网站提供的标准搜索功能进行少量增强。
    • 对检索到的工作岗位进行过滤,如果该岗位之前已发布过,自动忽略。
    • 可部署在服务器上,设置定时任务方式定时推送岗位更新,支持多种消息推送方式。
    • 新工作岗位通知方式支持:显示到控制台、保存到文件、发送到 Slack (强烈推荐 Slack )。注:如果想支持微信、邮件的通知,需要自行扩展。
    • 内置了 51JOB 和 V2EX 的支持。注:如需要支持其他招聘网站,需要自行进行扩展。

使用范例

  • 初始化项目
$ mkdir jobs
$ cd jobs
$ pip install pipenv --upgrade
$ pipenv --python 3.6
$ pipenv shell
$ pipenv install lbjobmonitor
  • 创建jobs.py。使用python jobs.py执行查询。
  • 可在服务器上使用 crontab 设置定时任务,定期检查
# jobs.py
import os
from lbjobmonitor.message import CLIMessageBackend
from lbjobmonitor.message import FileMessageBackend
from lbjobmonitor.monitor import QCWYJobMonitor
from lbjobmonitor.storage import JobMonitorJsonStorage
BASE_DIR = os.path.dirname(os.path.abspath(__file__))
DATA_DIR = BASE_DIR
def qcwy():
    params = {  # 51job 的查询参数。51job 设置好查询条件后发起查询,通过 chrome 的调试功能查看请求的具体参数。
        'saltype': '',  # 薪资范围
        'keyword': 'python',  # 关键词
        'postchannel': '0000',
        'keywordtype': '2',
        'jobarea': '080200',  # 地区编码
        'pagesize': '5',  # 每页记录数
        '': ''
    }
    storage = JobMonitorJsonStorage(base_path=DATA_DIR)  # 使用 JSON 方式将工作列表保存到当前目录
    message_backend_list = [  # 显示的推送方式
        CLIMessageBackend(),  # 显示到控制台
        FileMessageBackend(fn=os.path.join(DATA_DIR, 'jobs.txt'))  # 保存到文件
    ]
    monitor = QCWYJobMonitor(
        storage=storage, message_backend_list=message_backend_list)
		# monitor.max_page_idx = 1  # 最多查询页数,设置成 1 方便调试
    skip_words = ['AI']
    monitor.monitor_jobs(params=params, skip_words=skip_words)  # 执行查询
if __name__ == "__main__":
    qcwy()

代码导航

  • monitor.py
    • JobMonitor 工作岗位监控基础类
    • QCWYJobMonitor 51JOB岗位监控实现
    • V2exJobMonitor V2EX岗位监控实现
  • storage.py
    • JobMonitorStorage 存储区基础类
    • JobMonitorJsonStorage 将信息以json方式保存到文件的存储区实现
  • message.py
    • BaseMessageBackend 消息发送处理后端基础类
    • IMMessageBackend IM类消息的后端基础类
    • CLIMessageBackend 将消息发送到控制台
    • FileMessageBackend 将消息保存到文件
    • SlackMessageBackend 将消息发送到Slack
    • TelegramMessageBackend 将消息发送到Telegram
  • models.py
    • Job 岗位信息基础数据类
    • QCWYJob 51JOB的岗位信息解析类
    • V2exJob V2EX的岗位信息解析类

注: 还为这个工具做了一个 web 前端界面 https://github.com/vicalloy/jobmonitorweb/ 可通过 web 端查看推送信息。不过个人觉得用 slack 或 telegram 接收和查看推送信息更方便。这个项目里使用了Django Channels来做Web端的实时消息推送,如果感兴趣可以参考一下。

中心化服务问题

最初也考虑过将这个功能做成服务,用户可以通过WEB界面配置自己的订阅规则和消息的接收方式。不过一般网站都会有反爬虫的处理,如果服务器对一个网站访问过于频繁很可能会被该网站给ban掉,这个方案不可行。

当然,如果真想把这个功能做成服务还是有办法的。可以将主要功能用JS实现,用户将数据抓取的规则配置和历史记录保存在服务器。用户打开浏览器手动刷新岗位信息,数据抓取通过用户的浏览器完成。

为django-lb-workflow增加Pipenv

不知道是否是有项目在用(或是计划使用)django-lb-workflow,最近陆陆续续的收到一些issue。其中大多是咨询django-lb-workflow如何使用,也有些windows平台下的bug,还有就是因为python第三方库版本问题导致跑不起来的。
我使用virtualenv来创建虚拟环境,并使用pip(requirements.txt)管理第三方依赖。在指定依赖时通常都只会指定所需的最低版本,过一段时间不维护依赖就要出问题。
近年来Pipenv开始流行,目前看来很有希望成为今后python项目的标配。
Pipenv为您的项目创建和管理Python虚拟环境,并通过Pipfile 和 Pipfile.lock这 两个文件来管理项目中的Python依赖包。对我来说Pipenv的Pipfile.lock提供了对所有依赖层级的Python包的版本锁,可以有效的避免由于requirements.txt过于简单导致的第三方库版本问题。
希望用了Pipenv后,因为第三方库版本问题导致程序跑不起来的问题可以不再出现。

从HHVM换回到PHP-FPM

之前一直用PHP-FPM作为PHP的解析器,上次在将博客迁移到linode的时候换成了HHVM。换到HHVM后博客就一直不太稳定,经常莫名其妙的down掉。
前两天博客有down掉了,重启HHVM也不解决问题,干脆换回了PHP-FPM。希望之后博客能稳定一些。

关闭“似水流年”

将服务器迁移到linode后, jstwind.com 就一直有些问题。因为没有什么人访问也懒得去改了。后来想想,既然没什么人用,也懒得维护,还是把网站关了。

“似水流年”是我做的一个用于编辑时间线的网站,用户可以在上面创建和分享时间线。网站前端用的是Bootstrap,当时Bootstrap刚出来没多久,我也是第一次使用Bootstrap,因此前端部分写的非常烂。为了保证良好的用户体验,时间线的编辑部分采用了AJAX,当时很多时间都花在了这上面。

网站关了,域名还会继续留着,说不定哪天用来做个新“玩具”。

代码托管在Github上,你可以在这里找到: https://github.com/vicalloy/timeline-site

开始写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账号注册好,就等什么时候有时间去把服务器迁过去了。