暴力切换clang++的gcc版本 作者: liesauer 时间: 2020-03-19 分类: 开发 评论 ## 当前已安装的gcc版本 ```shell liesauer@LA-Tower:/mnt/o/Projects/core-setup$ clang++-3.9 -v clang version 3.9.1-19ubuntu1 (tags/RELEASE_391/rc2) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5 Candidate multilib: .;@m64 Selected multilib: .;@m64 ``` ## 常规方式切换 通过网上大量查阅资料，发现都是通过设置环境变量或者传递参数到clang++实现gcc版本切换，但由于我是使用提供的脚本进行编译，各种环境变量都被脚本控制得死死的，而且编译前都要进行`git reset --hard HEAD`，所以修改编译脚本也不现实。 - 阅读剩余部分 -
如何使用Travis CI来做GitHub的Release自动发布 作者: liesauer 时间: 2020-02-13 分类: 开发 评论 ## 起因 由于GitHub在国内越来越难访问了，甚至于Release都是托管在亚马逊AWS下，访问起来更是问题了，十几KB甚至几KB的速度已经是惯例了，想上传个Release都得上传半天。其实这个上传脚本我很早之前就在用了，近期有空就刚好做成一个傻瓜式自动脚本供给其他的项目用。 ## 食用演示 注意，本文不会对`git` `github` `travis-ci` `yaml`等相关知识做过多解释，需要读者有一定的基础。 ### 创建仓库 首先我们新建一个测试演示的空仓库  - 阅读剩余部分 -
记抖音爬虫中所遇到的坑 作者: liesauer 时间: 2020-01-08 分类: 开发 15 条评论 ## 常规问题 一些常规问题在此就不做记录了，比如怎么获取某加密参数、需要访问哪些接口、哪些接口无水印等等就不说了，善用搜索引擎。 ## 坑一：判断接口是否成功 由于接口的原因，接口返回的`aweme_list`列表有可能是空的且`status_code`还为`0`，不能通过这两个数据判断接口是否调用成功，可使用`min_cursor`和`max_cursor`判断，当请求成功时，返回的数据必有这两个字段，必然不是`null`或者`undefined`。 ## 坑二：判断是否还有更多 还是接口的问题，当请求失败时，返回的`has_more`还是为`true`，需要通过判断接口是否成功以及`has_more`共同判断，调用成功并且`has_more`为`true`才是真正的还有更多，否则稍有不慎就会出现死循环抓取。 - 阅读剩余部分 -
axios较完美的超时以及重试失败解决方案 作者: liesauer 时间: 2020-01-06 分类: 开发 评论 ## 代码引用 1. [Retry Solution From KyleRoss@github](https://github.com/axios/axios/issues/164#issuecomment-327837467 "Retry Solution From KyleRoss@github") 2. [Timeout Solution From aarcangeli@github](https://github.com/axios/axios/issues/2143#issuecomment-495994940 "Timeout Solution From aarcangeli@github") ## axios 的 retry 解决方案 见：[Retry Solution From KyleRoss@github](https://github.com/axios/axios/issues/164#issuecomment-327837467 "Retry Solution From KyleRoss@github") ## axios 的 timeout 问题 在`0.18.0`版本中`axios`的`timeout`并没有被正确实现导致有可能在弱网环境或不稳定环境或代理环境下`timeout`无效、程序卡住的情况（见：[Axios will not timeout on idle sockets](https://github.com/axios/axios/issues/2143 "Axios will not timeout on idle sockets")），虽然这问题在`0.19.0`版本中修复了，但是`0.19.0`版本中对配置合并的规则的阻断性更新导致我们的重试失败解决方案失效（见：[Axios 0.19.0 issue](https://github.com/axios/axios/issues/2397 "Axios 0.19.0 issue")），所以我们无法升级到`0.19.0`来解决这个问题。 - 阅读剩余部分 -
为 Python 项目生成 requirements.txt 以及使用 作者: liesauer 时间: 2019-12-13 分类: 开发 评论 # requirements.txt 的作用 `requirements.txt`就如同其他语言项目中的`package.json`或`package.lock`等，用于记录该项目的基本信息以及对第三方库的依赖信息，当我们项目在别的地方进行开发时，我们就能根据这些信息安装所需要的第三方库，并且精确到具体版本，而不会出现依赖库不存在导致编译失败或运行失败的情况，也不会因为安装了较新版本而出现与开发环境不一致而出现向下兼容等问题。 - 阅读剩余部分 -