时值 2026 年 7 月, 机场订阅不稳定的问题依然显著, 所以将 VPS 也加到流量链路中.

机场订阅可用但不稳定， 私人VPS稳定但不可用， 将两者拼接起来， 就能形成一套可用且稳定的 🪜 方案。

本篇主要是分享一下在 大量数据表 下通过 dify + 简单 LLM , 实现 自然语言 -> SQL 查询的一个实现思路.

这个思路的实现门槛较低, 我们所有需要做的只是：

1. 配置一个通用的LLM（比如 qwen3.7-plus）
2. 维护一套知识库, 用于 RAG 检索（比如 dify）
3. 开发一组 MCP 工具, 用于暴露 权限围栏 与 LLM 需要使用的 Tools .

这次把博客的部署链路从 GitHub Pages 迁到了 Cloudflare Pages。

说是从 GitHub 迁移到 Cloudflare，其实更准确的说法是：GitHub 继续作为代码仓库和触发源，真正负责构建、发布、域名接入、缓存和 TLS 的部分交给 Cloudflare Pages。这样一来，GitHub 不再承担静态站点托管的职责，而是回到它更擅长的位置：保存源码、记录变更、触发部署。

这篇记录一下迁移的背景、具体改动、部署时踩到的坑，以及迁移之后能得到什么好处。

从 2025 年下半年开始，我陆续在真实项目里实践 SDD（Spec-Driven Development，规格驱动开发）。其中有两个很有代表性的项目：一个是把历史悠久（Tornado + Jinja2）的某历史平台重构到当前技术栈，另一个是开发面向非研发同学、承载多种业务需求的某新平台。

这两个项目恰好代表了两种完全不同的开发场景：某历史平台是典型的棕地项目，已有业务复杂、历史约束很多，重构时最重要的是不要破坏原有逻辑；某新平台则更接近绿地项目，需要从零开始梳理需求、设计边界，并控制项目在快速演进中的复杂度。

SDD 确实解决了过去使用 AI 开发时遇到的许多问题。但随着实践深入，我也逐渐意识到：SDD 并不是写几份 spec、plan 和 tasks 文档就结束了。它真正要解决的，是如何让 AI 在长时间、跨会话、复杂代码库的开发过程中，始终理解我们的意图、遵守系统约束，并且能够证明自己的工作是正确的。

这篇文章想结合两个项目的实践，聊一聊我对 SDD 的理解、它目前的局限，以及它接下来可能演进的方向。

本文所说的 SDD，是一种以可验证规格作为开发主线的工作方式。规格不只描述需求，还应包含业务约束、非目标、验收条件和验证方式，并持续参与任务拆分、实现、审查与交付。它与 TDD、BDD、ADR/RFC、API-first 等方法并不冲突：这些方法分别提供行为验证、决策记录和接口契约，SDD 则负责把它们组织到同一条从意图到交付的主线上。

最近在 Codex 里调用 Notion 插件时遇到一个容易误判的问题：Notion 搜索失败，报错指向的却不是页面权限、数据库或查询语法，而是 Codex App 与插件 worker 之间的传输链路。

典型错误如下：

HTTP request failed: https://chatgpt.com/backend-api/wham/apps

这个报错看起来像 Notion 不可用，但从失败地址判断，请求很可能还没有进入 Notion 查询逻辑，而是卡在了 Codex / ChatGPT 的插件通道上。

后端服务接入 Sentry 或 GlitchTip 后，线上错误通常并不缺数据，真正缺的是一条稳定的排查路径：如何从 issue 进入，拿到事件详情、请求上下文、breadcrumbs 和异常栈，再回到代码里验证根因。

这次实验的重点不是 Grafana。关键证据全部来自 Sentry Skills 对 GlitchTip 事件的读取，因此这里记录一套通过 Sentry Skills 独立完成错误排查的方法。Grafana MCP 的使用可以参考 用 Grafana MCP 排查 Redis 配置问题与迭代监控。

最近借 Grafana MCP 做了两次排查。一次是定位内容采集链路里的 Redis 配置问题，另一次是从 Playwright 服务的 zombie 进程告警出发，补齐监控面板和告警规则。

这两次经历给我的感觉是，Grafana MCP 的价值不只是“让大模型能查日志”，而是把日志、指标、代码和部署配置放到同一个排查上下文里。问题不是靠猜出来的，而是沿着 task_id、trace_id、stacktrace 和 Prometheus 指标一步一步收窄出来的。

前几篇介绍了模型、Prompt、Rules、Cursor 工作模式、注意事项与项目重构. 最后一篇记录一些使用中的常见问题、仍然值得使用的扩展工具, 以及如何量化和迭代自己的 Vibe Coding 工作流.

项目重构是检验 Vibe Coding 能力的典型场景. 它不只要求模型生成新代码, 还要求模型理解旧逻辑、识别技术债务、保持业务行为并完成验证.

掌握 Prompt、Rules 和 Agent 的基本用法之后, Vibe Coding 的主要问题就不再是“AI 能不能写代码”, 而是如何让它稳定地产出符合项目实际约束的代码, 同时避免错误被快速放大.

这一篇集中记录使用过程中的注意事项与进阶技巧.

Cursor 不只是一个带聊天窗口的编辑器. 它把补全、问答、代码编辑、任务规划和工具调用放在同一个开发环境中. 用好这些模式的关键不是让 Agent 承担所有工作, 而是根据任务规模选择合适的交互方式.

上一篇介绍了 Vibe Coding 的基础: 模型、提示词与上下文. 接下来进一步了解 IDE 中一种特殊的提示词, 即 Rule.

规则的意义在于通过持久化的项目约束将 Agent 特化. 过去需要先说“你是一个 Python 专家, 精通……”, 现在可以将技术栈、代码规范和项目结构写入规则, 日常只需要描述具体任务.

前言 ​

Alfred 是一款 MacOS 上用户基数较大的软件, 笔者主要是用它来取代原生的 聚焦搜索, 除此之外, 最近开始研究它的 工作流(workflow) 相关的功能.

本篇就是实际展示一下如何开发一个 workflow. 使用的脚本语言是 Python , 不过实际上任何脚本语言都可以完成开发工作.

前言 ​

本篇的目的是在 Python 的 Test 框架中添加一个 mock 函数使用计数器 的逻辑. 该计数器的目的是, 在调用第三方api接口时, 计算某一个流程中的调用次数是否合理. 在流程(或调用关系)比较复杂的时候实用性较高.

Data Structure That Power Your Database ​

最简单的数据库是什么样子的?

#!/bin/bash 
db_set () {     
 echo "$1,$2" >> database 
} 

db_get () {     
 grep "^$1," database | sed -e "s/^$1,//" | tail -n 1 
}

如上所示, 我们完成了一个最简单的 kv 数据库. 它的工作原理是: db_set 在文件末尾追加一个 kv 对; 如果对某一个 key 进行更新, 那么新的记录会继续追加写入文件, 而非覆盖; db_get 查询到最后(即最新)一条 key , 然后返回 value.

这个数据库的写效率极高 [ $O(1)$ ], 因为它单纯的就是向文件的末尾进行 append 操作. 但是代价是它的读效率非常低 [ $O(n)$ ].

为了解决读效率低的问题, 可以使用 索引 , 索引本质上是一个依附于主体数据的额外的数据结构. 它可以作为一个整体地被添加或者删除. 但是索引又会引发一个新的问题, 索引的变化依托于 写(write) 操作, 这意味着每次写都需要额外的一部分性能来更新这个数据结构, 如果数据结构过于复杂, 则会拖慢影响写的效率.

本节主要就是围绕这些索引结构及其演进来展开.

• Hash Index
• SSTable
• ...

本篇主要是讲如何从 Django Api 生成出 swagger 描述文件. 它具有如下的特性:

1. 基于 inspect \ (ast) 采用静态分析的思路, 不依赖业务代码, 能够文档先于项目
2. 嵌入 Django CMD
3. 生成所用到的代码不会影响生产环境性能

之前接触过 drf, 一个基于 Django 的 rest 框架. 由于深渡契合 rest, 有着严格的项目结构约束, 所以能够直接从代码文件生成出对应的 swagger 描述文件. 但是这套代码是无法直接移殖到 Django 上面的, 因为后者的结构比较松散, 没有一种万金油的生成策略.

所以, 本篇所提供的生成方案具有以下约束:

1. 需要封装一层装饰器, 并应用与所有需要生成文档的视图函数.
2. 依赖 pydantic (或者平替 cattrs \ schema 等)

本篇是关于如何在 Pycharm 和 VSCode 中使用 Docker Compose 的. 开篇比较啰嗦, 大抵是踩过的一些坑和问题的解决过程, 实际的配置内容自 转 这一节开始.

本篇主要的内容是如何对 Docker 镜像进行优化.

优化总共分为以下几步:

1. 基于项目优化
   • 缩减依赖包
2. 基于Docker优化
   • 目录结构优化
   • 构建文件优化
   • 使用 dive 进行镜像分析

以及部分 Multi-stage build 的内容.

本篇基于笔者本人的实际工作经验, 总结了一些API的设计思路, 并提供了对应的参考资料以供深入研究.

工作快一年了, 积累了很多的 代码片段(code snippet), 所以需要一个小工具来实现公司\家庭\开发\私人服务器等地方的代码片段的同步.

同步的方法有很多, 我试过onedriver \ codemass \ gist 等手段, 但是各有各的缺点(后文补充), 所以最后还是选择了一个相对折中的方案, GitHub.

本文主要介绍的就是如何通过自动化脚本实现GitHub代码片段的同步.

代码环境:

• macos
• ubuntu
• centos

在 django, 或者其他的 python 交互式 shell 中, 有时候需要进入到 shell 中进行调试工作, 但是当调试的代码量较大， 或者调试十分地频繁的时候, 这种操作会变得十分地痛苦, 在线上环境中的调试尤甚.

本篇会介绍一个注入脚本, 可以方便地在 python 的交互式 shell 中进行调试.

本想改造一下公司电脑的 Windows,后来干脆直接给电脑刷了个 Windows, 于是, 风扇不再是噪声源, 电脑不再是暖手宝, 一切都变得清爽了起来.

唯一美中不足的是 ubuntu 上的软件和 Windows 还是有些差异的, 所以就有了本篇, 将各个常用的软件(从程序员的角度)的安装和坑点列出来.

另附一个开发中的 Ubuntu 初始化脚本.

公司服务器上的日志文件多年积压, 已经占用了很大一部分不必要的内存空间. 所以本篇将完成一个功能性脚本, 其内容是扫描过期的日志文件, 并对文件进行对应的操作.

好久没有写过 bash 脚本了, 本篇也算是对这项技能的一个温习吧.

在使用 pdfplumber 时会出现内存递增的情况, 最终导致内存的爆炸, 这一点在高频率地调用时尤为明显. 本篇主要解决的就是 pdfplumber 这个依赖包所导致的内存泄露问题.

承接前面两篇, 字体反爬虫解决方案 和 进度条方案, 本篇是对旧版本的 Poirot 部分内容的性能优化.

主要优化内容为:

• 使用 Pillow 从字体文件中抽取出字形图片
• 使用 Tesseract 进行 OCR 识别

当然还有一些细枝末节的优化, 如 socketio 的版本升级等, 这其中又遇到了一些小问题, 会在文末一并总结.

简单地记述了一下在使用 github 时遇到的 kex_exchange_identification 错误.

在Christin 开发记录(1)中， 我们讲过了这个项目的大体的设计思路，本篇以及之后的几篇将会详细地阐述各个技术要点的具体实现方案。

本篇主要的内容是 nginx 在 前后端分离 和 多语言开发 的代理作用.

fastNLP 和 spaCy 都是自然语言处理常用的算法包,本篇将会应用的角度,分别使用这两个算法包训练一个可用的命名实体识别模型.

关于 Christin ​

Christin 是笔者本科毕业设计的伴生项目, 笔者本科毕业设计的课题叫做 基于多元异构数据的中医药知识图谱构建及应用 , 作为其实践产物的平台,我将其命名为 Christin , 选名自我所以喜爱的 ARPG 游戏系列 <伊苏> 的主角 亚特鲁-克里斯汀( Adol Christin ) 以及我第二喜欢的小说家 Dame Agatha Mary Clarissa Christie. 当然, 其对外的平台名称叫做 中医药知识图谱构建平台.

本系列将主要介绍这个项目开发的 思路 / 完善过程 与 技术栈 . (截止到毕设答辩前夕)

前言 ​

首先需要说明的一点是, 本篇并不是为了讨论 ObjectId 和自增 id 谁更好用.在笔者看来, 文档型数据库和关系型数据库的使用场景不同, 有不同的使用倾向是理所当然的事情, 没有必要拉到一块儿"关公战秦琼".

本篇单从设计的角度来说, 为什么 ObjectId 和 自增 id 分别使用于各自的使用场景.

Frankenstein 是用来搜索可用数据源的一个小工具,它包含两个主要功能

1. 友链扫描
2. 关键字扫描

这两个部分本质上都是对现存的数据源进行遍历搜索,区别在于二者的扫描侧重点不同.

本篇主要是 友链扫描 的开发记录.

Poirot 是自动将字体文件(woff\woff2\ttf)映射为结果字典,主要用于中文字体反爬虫的破解,包括 css 字体映射和图片文字反爬虫.

实现的基础思路可见于字体反爬虫解决方案-自动化通过字体文件生成映射字典.

与 Mori 同属于爬虫工作的小工具.名字取自大侦探波洛(Hercule Poirot). 与 Mori 的脚本服务不同,这次从实际使用的角度考虑,采用了 web 服务的形式.

本篇记录了 Poirot 的开发中学习到的技术和踩到的坑。

主要包括:

1. flask-websocket 的使用
2. 进度条的实现

由于之前疏于对公司电脑上面的 C 盘的管理,它的存储空间不出意外地炸了.

于是就开始了繁琐的清理工作.首先通过 设置 -> 存储 找到 C 盘占用空间的大头.也就是微信文件和 miniconda,微信由于日常的工作联系等积压了大约 5G 左右,miniconda...emmm...8G = =

看了一下,pytorch、tensorflow 等一系列的包、环境,这个手术动起来还是挺麻烦的,牵连太多了.

不过随着工作任务的固定,有些包和环境确实也不需要了,于是就有了接下来的一些迷惑操作.

最近在寻找一些毕设要用到的数据，医药相关的，恰好在某个网站上面找到了备份数据库(手段不太光彩，这里就不细说了)，省去了写爬虫的麻烦。

不过这些备份文件是 .MYD / .MYI / .frm 这样的后缀，emmmmm，对于用惯了 .sql 的我来说，还是很头大的。

本篇的主要内容就是如何使用 .frm / .MYI / .MYD 文件来恢复数据库，同时，做了一些关联的延申。

字体反爬虫 ​

初级的字体反爬虫可以参照字体反爬的解决方案——突破抖音反爬虫机制这边文章.

类似的文章教程不胜枚举,所以这里对于 字体反爬虫基础 就不做赘述.本篇要讨论的是如何处理在多大数百、数千个自定义字体的复杂情况下完成从字体文件生成映射字典的工作.

上面提到的文章,采用的是人工映射,这在只有 0~10 这样的简单情况下自然是最方便的处理办法,但是对于大量字体的情况,就捉襟见肘了.并且,即使花了半天时间将这些字体一一映射,万一网站的字体库发生变化,或者网站本身就采用动态字体库,就很麻瓜了.

本着"花半天时间做重复性的苦力工作,不如花一天时间做创造性工作"的原则(预估的开发时间比较充裕,才有时间来实践这些突发的灵感),决定搞一些懒人方法.

上周在外网搭建了一个服务,主要是用来对 Mori 的各种处理状态做测试.

今天在看网站统计的时候,发现请求的次数不太正常,主要表现就是出现了下面这种画风的请求.

INFO:     174.49.25.36:51271 - "GET / HTTP/1.1" 200 OK
INFO:     14.139.155.142:41680 - "GET /currentsetting.htm HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:58868 - "GET /wp-content/plugins/wp-file-manager/readme.txt HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:58844 - "GET /?XDEBUG_SESSION_START=phpstorm HTTP/1.1" 200 OK
INFO:     91.241.19.84:42642 - "GET /console/ HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:36206 - "POST /api/jsonws/invoke HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:55124 - "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:36174 - "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:42156 - "GET /index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21 HTTP/1.1" 404 Not Found
INFO:     91.241.19.84:52646 - "GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 200 OK
INFO:     91.241.19.84:53606 - "GET /solr/admin/info/system?wt=json HTTP/1.1" 404 Not Found
INFO:     203.205.34.139:47518 - "GET / HTTP/1.1" 200 OK
INFO:     182.185.14.56:62446 - "GET /currentsetting.htm HTTP/1.1" 404 Not Found

随手摘了一个 ip (219.149.212.74) 查询了一下,竟然是国内的 = =|||

又想到从大二下接触 web 开发,到现在两年多,部署了几个服务,但是却没有好好分析过网站的日志文件,正好就趁着这个机会看看吧.

前言 ​

距离 Mori v0.1 成形已经过了一周.这一周里面对这个代码进行了进一步的优化.

在 Mori Kokoro 开发记录 中已经对上个阶段开发中遇到的问题进行了一次汇总.本篇是对本阶段的问题的汇总.

另外.将一些实用的代码摘出.并进行注释说明.

前言 ​

目前主要接触的爬虫开发主要有两种：

1. 静态网页
2. api

我司已经有静态网页的检测工具,不过随着 api 类爬虫日益增加,需要一个新的可以用来检测 api 变动的脚本.

这里我选择开发一个命令行工具,而非 web 平台服务.理由是前者更加 geek && cool.并且前者只要稍作改动,就可以很好地兼容后者.

我将其命名为 Mori Kokoro , 取自柯南的 毛利小五郎 . 就一个检测脚本而言,它的工作与侦探 🔍 相类似(发现坏家伙 😀).同时这个脚本算是我第一个开发的命令行脚本,无论是代码质量,还是功能实现,都缺乏信心,所以就以毛利为名.

Mori 项目地址

在爬虫实习中遇到了这样一个情境：对一个给定的队列进行数据爬取(比如说是一个公司名称的队列，爬取对应的公司信息)，当然不是开发结束就算是完成了，代码无法保证能够应对所有的突发情况，而且我们也需要一个半透明的，甚至是透明的爬虫监控系统，了解爬虫的任务进度，以及过程中遇到的一些问题。

这个监控系统并不难实现，使用 flask 写了一个服务平台，不过是几个小时的事情，但是我在实现过程中遇到一个很有趣的问题：用什么样的数据库来保存这些数据？

笔者写爬虫时常用的数据有 MySQL、mongoDB、Redis，这三个各有长处，用来针对不同的业务需求；而在写 web 服务时，则常用 MySQL、SQLite。

这些数据库在不同的情境下各有优劣，正巧最近有些闲工夫，就在这个问题上做了一些发散。

Factory Function for Tuples with Named Fields

Python 除了大家熟知的，可以直接使用的 list、dictionary、tuple 等容器，还有一些放在 collections 包中的容器，这些容器的泛用性不及普通容器，但是在特殊的场景下，有着超过普通容器的性能与便利性。

本篇就在官方文档的基础上，结合笔者的学习工作经验，于管中窥得 nametuple 之一斑。

前言 ​

在 Mac 上面安装了 iTerm2 之后，逐渐难以忍受 Windows 上面简陋的终端界面，CMD 就不谈了，即使了 Windows10 加入的 PowerShell ，也依旧差强人意。

PowerShell 强化了 Windows 命令，并且能够让电脑使用部分的 Linux 命令，这是一个重大的进步。其缺点依旧明显，Linux 命令并不完整，对于习惯了使用 Linux 命令行来实现一些骚操作的人来说，难免有点束手束脚。其次，PowerShell 的界面也不太令人满意。

所以这次按照 Windows Terminal Docs , DIY 一个美观的 Terminal。

个人介绍 ​

now：大三在读(2021 毕业)

email:[email protected]

base:南京

求职意向：后端开发、测试

个人总结：

• 大三在读，参加过多项比赛并且获奖
• 拥有良好的沟通和协调能力，善于应变，能够快速适应新环境
• 具有团队协作精神，能够承受工作压力，有较高的执行力
• 曾在工作室的项目中负责的总体规划设计和业务功能开发
• 熟悉 windows、linux、macOS 三端开发

个人网站：Zaxon

前言 ​

惯例的前言，这次这个小玩具又是一个来源于生活的东西了。

上次写了一个基于 linux 的自动打卡机，但是最近又有了新的需求。。。

其一是学校的每一次表单变更都需要进入项目进行代码级别的修改、测试、部署，实在是太过麻烦。

其二是以往的自动化需求太高，而对于没有服务器的同学只能看着眼馋。

于是这次写了一个基于 flask 的自动打卡网站，emmm，暂时没啥 bug。

感觉已经一万年没有更新博客了。。。这次是制作一个简单的爬虫。

前言 ​

本学期有一门纯文科的课程，名唤“医疗仪器原理”。谓之纯文科，自然是要背诵的题目太多了，多到了梦回高中历史的地步= =。

授课老师喜欢使用雨课堂发布习题，但是雨课堂没有办法导出题目和答案，想要整理就只能一条一条地复制粘贴，更骚的是，这个网站的题目默认被转成了图片格式(？？？)。好嘛，复制粘贴都做不到了。

这种复习的效率实在是太低了，于是准备重操旧业，开始爬虫工程（面向监狱编程）

难得遇到一道困难的打卡题，就在这里写一下过程吧（虽然并不是很困难。。。）

给定 n 个非负整数表示每个宽度为 1 的柱子的高度图，计算按此排列的柱子，下雨之后能接多少雨水。

上面是由数组 [0,1,0,2,1,0,1,3,2,1,2,1] 表示的高度图，在这种情况下，可以接 6 个单位的雨水（蓝色部分表示雨水）

德黑兰王国西部边境，少年兵团营地，夜。

道恩静静地躺在床上，脑海中意识不断地翻腾汹涌，他虽然无法从中捕获到任何有用的信息，但是他清楚，这是自己的灵性在面对危机时的主动预警。而他也正是因为无条件地信任这种虚无缥缈的东西，现在才能以一个活人的身份躺在这里。

数据库学习笔记(1)

前言 ​

随着开发的深入，使用 vim 的频率渐次提升，但是技巧却始终停留在初见阶段（一些技巧虽然学过但是都忘了。。。），极大地影响了开发的效率，所以，再次学习 vim 势在必行。

完成一个自动打卡的脚本 ​

前言 ​

由于近期疫情猖獗，学校开始要求大家进行每日的健康打卡。

但是对于笔者这种死宅，根本不会出门的那种，每日的打卡基本上都是一模一样的内容。这种情况下打卡反而成了一种负担，如果哪天忙忘了，又免不了被一顿批评。

程序员自然有程序员的解决办法。所以这里就做了一个自动打卡的脚本，托管在服务器上，这样就可以不用去管这件事情咯。

前言 ​

"酒香不怕巷子深"，这样的想法在这个时代已经算是非常地消极和落伍的一个思想了。

就像是一部电影，如战狼、哪吒这样，优秀的宣发能够带来远超电影本身质量的收益；而反过来，如闪光少女这样的电影，质量足以称为上乘，但是票房确差强人意，这就是典型的忽视了市场规则的下场。

访问量、点赞、收藏、投币等要素共同决定了一个视频的热度。但是，除了前者之外，都需要一个确切的 B 站账户，笔者目前还没有能力来维持一个基数庞大的 B 站账号池，所以就只能在第一个要素，点击量 上下文章咯。

3 进阶功能 ​

3.1 慢查询 ​

1. 基础 ​

1.1 常识 ​

Redis 是用 C 语言开发的一个开源的高性能键值对（key-value）数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求，目前为止 Redis 支持的键值数据类型如下：

• 字符串类型
• 散列类型
• 列表类型
• 集合类型
• 有序集合类型

在进行网页爬虫的项目时，常常会因为爬取的频率过高而触发 反爬虫机制 ，这时候，面临两个选择：

1. 休息片刻。一般反爬虫机制不会进行永久的 IP 封禁，只是暂时限制访问而已，等待封禁时间结束再进行爬取即可。当然对于某些拥有黑名单机制的网站，如果封禁次数过多，封禁的时间也会随着这个次数而提高。
2. 更换 IP。既然我的 IP 被封了，那么我换一个其他的 IP 不就行了。

显然，第二种方法更优于第一种，并且更加符合 geek 的风格。但是问题在于，从哪里寻找这样一个 IP 地址呢？

关于疫情 ​

各地的疫情警报使得今年的春节有一种别样的味道。

我看到有人心系灾区捐款捐物，也看到有人趁此机会将自己推上舆论的风口攫取利益；我看到有人抱着舍身取义的心态奔赴一线，也看到有人仅将其作为茶余饭后的谈资不值一哂。

灾难面前众生百态，精彩如同一部小说，却远比我看过的任何小说都要精彩。对人的刻画，对社会的刻画，名为现实的大作家，以它的春秋笔法，将一切尽书于人前。

感慨就到这里吧，作为一个程序员，我们能做什么呢？

开启这个项目的起因是 severchain 发起的一个疫情推送功能，但是由于请求次数过多，服务器负载超限，不得已又停止了服务。我虽然不会做推送，但是搭建一个简单的疫情实况 api 还是很熟练地。

正好可以将寒假的两大技能 爬虫和 Flask ，做一个综合运用。

前言 ​

到这里，python 爬虫部分的复习也就告一段落了，当然，除了 scrapy，老实说，对于平常爬取几千条这种小打小闹的爬虫，并没有去深入研究 scrapy 的必要（当然，了解还是要了解一下的）。

之前学习爬虫，因为需求的原因，只学习了网页爬虫。趁着寒假有空，再来看一看 app 爬虫是啥样的吧。

文件 && 目录 ​

目录大小 && 浏览和切换目录 ​

• pwd 当前路径

• which 搜索可执行文件路径

• ls 列出当前目录

  • -a all
  • -l list
  • -h 便于人类阅读
  • -t 按最近一次修改时间排序
  • -i 显示 inode

• cd 切换目录

• du 显示目录包含的 文件 大小 du 会深入遍历目录的每个子目录

  • -a 显示目录和文件的大小
  • -h
  • -s 只显示总计大小(summary)

引入 ​

根据笔者以往的爬虫经验，大部分的爬虫是在静态网页上完成的，爬虫所要做的只不过是提交请求，然后分析返回的页面即可。当然，api 本质上也可以作为静态页面来处理。这意味着只要掌握 requests 就可以完成 60%-80%的爬虫任务。

这是一个很惊人的占比，这里解释一下，静态页面可能听起来很 low，但是有着以加载速度更快、易于维护为核心的一系列优势，尤其是引入了 ajax 之后，实现了动态加载，通过更加频繁的前后端交互，使得用户的使用更加丝滑流畅。

但是总有一些网站是静态爬虫无法应付的。它们就是与 js 耦合度较高的，需要 js 进行渲染的页面，与上文所述的情况（前端只接收数据，而不用对数据进行计算层面的处理）不同，这类网站将部分的计算工作交托给前端，牺牲部分的用户体验来实现缓解服务器压力等一系列目的。

这就是剩下的 20%了。如何处理这些刺头呢？这就引出了本文的主角--splash。

提高爬虫效率主要从三个方面开始复习。

1. 并发
2. ip
3. cookies

并发必然引发的一个结果就是反爬虫机制，这种时候爬虫的效率不会因为并发而提高，反而会因为网站的防御机制拖累爬虫的速度。

自然而然地就引出了 2，代理爬虫。代理爬虫能够从多个 ip 发送请求，减小了单个 ip 的请求频率，自然触发反爬虫机制的概率也就小了很多。

但是新的问题又出现了，对于需要 登录 的网站，需要提交 cookies 来模拟登录情况，模拟登录不难，但是同一个 cookies 从不同的 ip 同时发送请求很明显不合常理，依然会触发反爬虫机制。

这是到目前为止我所遇到的影响爬虫效率的问题，就在这里做一个总结吧，如果后续遇到新的效率相关的问题，再做补充。

写在前面 ​

selenium 虽然是新手友好型的爬虫工具，但是个人觉得绝对不是适合新手入门的爬虫。 推荐在了解了 requests 体系 的爬虫，有了爬虫的一些常识之后，再来看 selenium。

事实上，requests 体系的爬虫已经足够满足现阶段大多数网站的爬虫需求

echarts 节点点击事件 ​

由于项目需要在点击 echarts 的 items 或者 labels 的时候,修改 DOM 树,所以要做一个 echarts 的点击事件.

在网上找了很久,大多是没有解答的空问题. 然后试图用 js 的原生方法来解决问题,发现确实有点麻烦,因为 echarts 在初期构建的时候,滤掉了冗余的信息,最后只给出了一个精简的绘图结果.

思考:echarts 原生的点击是如何实现的?

No. 136 出现的数字问题(简单)

给定一个非空整数数组，除了某个元素只出现一次以外，其余每个元素均出现两次。找出那个只出现了一次的元素。

说明： 你的算法应该具有线性时间复杂度。 你可以不使用额外空间来实现吗？

No. 137 出现的数字问题 II(中等)

给定一个非空整数数组，除了某个元素只出现一次以外，其余每个元素均出现了三次。找出那个只出现了一次的元素。

N0.151 翻转字符串里的单词

给定一个字符串，逐个翻转字符串中的每个单词。

No.77 组合

给定两个整数 n 和 k，返回 1 ... n 中所有可能的 k 个数的组合。

No.85 最大矩形

难度：困难

给定一个仅包含 0 和 1 的二维二进制矩阵，找出只包含 1 的最大矩形，并返回其面积。

No.84 柱状图中最大的矩形

难度：困难

给定 n 个非负整数，用来表示柱状图中各个柱子的高度。每个柱子彼此相邻，且宽度为 1 。

求在该柱状图中，能够勾勒出来的矩形的最大面积。

以上是柱状图的示例，其中每个柱子的宽度为 1，给定的高度为 [2,1,5,6,2,3]。

图中阴影部分为所能勾勒出的最大矩形面积，其面积为 10 个单位。

No.80 删除排序数组中的重复项 II

给定一个排序数组，你需要在原地删除重复出现的元素，使得每个元素最多出现两次，返回移除后数组的新长度。

不要使用额外的数组空间，你必须在原地修改输入数组并在使用 O(1) 额外空间的条件下完成。

No.72 编辑距离

难度：困难

给你两个单词 word1 和 word2，请你计算出将 word1 转换成 word2 所使用的最少操作数 。

你可以对一个单词进行如下三种操作：

插入一个字符
删除一个字符
替换一个字符

No.71 简化路径

以 Unix 风格给出一个文件的绝对路径，你需要简化它。或者换句话说，将其转换为规范路径。

在 Unix 风格的文件系统中，一个点（.）表示当前目录本身；此外，两个点 （..）  表示将目录切换到上一级（指向父目录）；两者都可以是复杂相对路径的组成部分。更多信息请参阅：Linux / Unix 中的绝对路径 vs 相对路径

请注意，返回的规范路径必须始终以斜杠 / 开头，并且两个目录名之间必须只有一个斜杠 /。最后一个目录名（如果存在）不能以 / 结尾。此外，规范路径必须是表示绝对路径的最短字符串。

No.68 文本左右对齐

难度：困难

给定一个单词数组和一个长度 maxWidth，重新排版单词，使其成为每行恰好有 maxWidth 个字符，且左右两端对齐的文本。

你应该使用“贪心算法”来放置给定的单词；也就是说，尽可能多地往每行中放置单词。必要时可用空格 ' ' 填充，使得每行恰好有 maxWidth 个字符。

要求尽可能均匀分配单词间的空格数量。如果某一行单词间的空格不能均匀分配，则左侧放置的空格数要多于右侧的空格数。

文本的最后一行应为左对齐，且单词之间不插入额外的空格。

No.65 有效数字

难度：困难

No.64 最小路径和

给定一个包含非负整数的 mxn 网格，请找出一条从左上角到右下角的路径，使得路径上的数字总和为最小。

No.48 旋转图像

给定一个 n×n 的二维矩阵表示一个图像。

将图像顺时针旋转 90 度。

No.56 合并区间

难度：中等

给出一个区间的集合，请合并所有重叠的区间。

No.49 字母异位词分组

难度:中等

给定一个字符串数组，将字母异位词组合在一起。字母异位词指字母相同，但排列不同的字符串。

待补充

No.34 在排序数组中查找元素的第一个和最后一个位置

给定一个按照升序排列的整数数组 nums，和一个目标值 target。找出给定目标值在数组中的开始位置和结束位置。

你的算法时间复杂度必须是 O(log n) 级别。

如果数组中不存在目标值，返回 [-1, -1]。

The sinking of the RMS Titanic is one of the most infamous shipwrecks in history. On April 15, 1912, during her maiden voyage, the Titanic sank after colliding with an iceberg, killing 1502 out of 2224 passengers and crew. This sensational tragedy shocked the international community and led to better safety regulations for ships.

One of the reasons that the shipwreck led to such loss of life was that there were not enough lifeboats for the passengers and crew. Although there was some element of luck involved in surviving the sinking, some groups of people were more likely to survive than others, such as women, children, and the upper-class.

记录在实际操作过程中遇到遇到的一些有意思的使用法.

本篇是笔者在学习 "Introduction to data mining"(《数据挖掘导论》)的英文最新版所记录的一些学习笔记。

2020.10.10 更新

很可惜的是，在多次迁移的过程中，本章的图片都丢失了。

食之无味，弃之可惜。所以暂且先保留在这里，以后再补全吧。

分为迭代器、文件读写、函数式编程三个部分，其中，前二者来源于 cookbook，其中加入了一些个人的理解和补正。函数式编程作为个人的扩充添加进来，主要参考了一些文章和书籍，因为很杂，就不一一列出。

参考 《第一本 docker 书》《docker 深入浅出》

Be a better pythonista 是新开的一个坑，如其名，根本目的是为了成为一个更棒的 python 开发者。

如何成为一个 better pythonista？个人认为，是 python 的特性、高级语法还有对 python 形式的编程思维的理解和贯彻，这也是本系列的侧重点。

Be a better pythonista 计划用前四部分完成对 cookbook 的重读，中间会对一些代码进行修正处理，并且会穿插一些个人的理解。同时，还会加入一些在开发中所遇到的一些事情、写作同时遇到的一些值得分享的东西，以为 dessert。

应用性学习置于构造性学习之后，在理解 sklearn 的构造，各种参数的理论依据的基础上，进行实践性的学习。

本篇主要针对监督学习进行浅尝。

应用性学习置于构造性学习之后，在理解 sklearn 的构造，各种参数的理论依据的基础上，进行实践性的学习。

本篇主要针对无监督学习进行浅尝。

构造性学习中，以理论为主，并结合一定的例子

本篇是机器学习的入门篇，主体的脉络差不多近似于 《数据挖掘导论》 一书

上一篇的部署是用的 uwsgi，这次听说 gunicorn 很方便，就试了一下

No.31 下一个排列

实现获取下一个排列的函数，算法需要将给定数字序列重新排列成字典序中下一个更大的排列。

如果不存在下一个更大的排列，则将数字重新排列成最小的排列（即升序排列）。

必须原地修改，只允许使用额外常数空间。

以下是一些例子，输入位于左侧列，其相应输出位于右侧列。

1,2,3 → 1,3,2
3,2,1 → 1,2,3
1,1,5 → 1,5,1

NumPy 是 Python 语言的一个扩展程序库。支持高阶大量的维度数组与矩阵运算，此外也针对数组运算提供大量的数学函数库。

本篇记载了如何在 python 中使用数据挖掘的相关的模块。 都是基础级的东西了。

参考：
    《python数据科学入门》
    在学习时零散地从网站、博客上获得的相关的知识

No.51 N 皇后问题

n 皇后问题研究的是如何将 n 个皇后放置在 n×n 的棋盘上，并且使皇后彼此之间不能相互攻击。

上图为 8 皇后问题的一种解法。

给定一个整数 n，返回所有不同的 n 皇后问题的解决方案。

每一种解法包含一个明确的 n 皇后问题的棋子放置方案，该方案中 'Q' 和 '.' 分别代表了皇后和空位。

No.79 单词搜索

给定一个二维网格和一个单词，找出该单词是否存在于网格中。

单词必须按照字母顺序，通过相邻的单元格内的字母构成，其中“相邻”单元格是那些水平相邻或垂直相邻的单元格。同一个单元格内的字母不允许被重复使用。

关于 python 的内置函数以及一些高阶的技巧的学习

基于 Ray 的阿里云部署 Flask + WSGI + Nginx 详解 对我所做的选课模拟系统进行了服务器端的部署。 环境：flask uwsgi Ubuntu Nginx

经过半个月额折腾，终于完成了 P 站爬虫 v2.0，现在可以根据关注列表来爬取关注对象的图片，唯一要做的只是输入账号密码而已。

基于参考资料《Python 网络爬虫从入门到实践》改编而成的用于爬取 typecho 框架下 handsome 主题的主标题信息的爬虫代码。

这里将会记载做蓝桥杯的题目时的一些感悟以及灵感（还有一些无聊的吐槽啦。