前言

到这里，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 原生的点击是如何实现的?

前言

星空浩瀚.熠熠繁星,哪一颗会是我,亦或是哪一颗都不会是我.
一瞬之间,思绪漾开,仿佛脚尖所点过的每一处,摇曳生莲.

– 2019.10.19 于合肥

这是 Linux 课程的大作业…

[美]Ron Jeffries

价值

80/20 法则:每个人想要的功能特性可能都不相同,但是没有人想要所有的功能特性.

首先推出能够产生价值的功能特性.

引导团队构建不仅对我们有意义,同时对用户也有意义的特性,即, 最小可市场化功能特性
与最小可市场化功能特性相比,在更细的粒度上提供商业方向更能使我们受益.

价值的最大化在于频繁交付小的\以价值为中心的功能特性.