#566 我不喜欢通过视频学习

2021-07-19

最近看了腾讯课堂和开课吧的几个 IT 方面的教学课程,都是视频 + 资料分享,可能还有课后作业之类的。

最后我的感受就是,这种学习方法非常不适合我,有可能是不适合大多数人。

如果我看书,当然,应该是合适的书,效率会更高。我浏览目录就可以知道应该重点看哪里,而跳过我知道的,或者对我帮助不大的地方,而现在的视频却很难做到通过一个大纲来实现跳转。更要命的是培训方希望教学能够覆盖更多的人,往往在一些基础知识方面花费太大力气,而直播又无法跳过,简直是谋财害命。更更要命的是,经常在深入之后,对正式的专业知识的讲解,进度又拉的很快,几句话带过(可能体验课也就只能这样吧)。

我也看到有一些课程是类似抖音短视频的风格,一个短视频一个知识点,然后通过播放列表可以实现跳转,我觉得这种方式会好的多。

经过反复思考,我觉得适合我的学习方式,还是先整理出一个大纲,然后找到合适的资料,一边看资料,一边敲代码。
如果有第三方组织真的有真材实料,然后可以给我合理的建议,设计出恰当的学习计划,给我做答疑和指导,我会付费,价格合理的话。
在自学方面,往往会摸索很久才会找到一条合适的路,如果可以得到正确的引导,那么效率就会提升很多。

#565 requests 遇到的错误:Failed to parse

2021-07-15

今天使用 requests 时发现居然报错:Failed to parse: http://xxxxx

重要的是我不是直接是用 requests,而是使用另一个工具库,然后它来使用 requests 发起网络请求,所以我就完全没有想到着一层。更重要的是代码之前运行的好好的,没有任何问题。而且 requests 这样一个通用的库,谁能想到它会有问题呢?

我怀疑了好多情况,比如防火墙,代理,网络环境等等,但是没有找到原因。最后开始看工具库的源码,看到头都大了,也没有一点发现。

最后还是在 StackOverflow 上看到有人提醒,可能是 requests 下面的 urllib3 依赖里面有点什么问题,建议先升级一下看看。一试果然好了。

我没有仔细分析其具体原因,留给记录,下次遇到类似问题要小心。

#564 redis 批处理

2021-07-15

先将命令写在 commands.txt 中,一行一个,不用分号结尾,然后:

echo commands.txt | redis-cli -h 127.0.0.1 -p 6379

#563 scp 拷贝文件引发的一次故障

2021-07-15

背景:有一个服务会定时读某个目录下的文件,然后逐个进行处理。

今天出于某些原因,我通过 scp 拷贝文件到那个目录下,结果意外的发现服务挂掉了,就是因为读到了一个空文件,抛出一个没有被处理的错误。

我知道这是程序设计上存在的一个缺陷,但之前我们一直通过 rsync 在传输文件,从来没有遇到过这样的问题。

我查了文档并进行了实验,确认了 rsync 会在文件传输时创建一个 .文件名.随机串 的临时文件,然后在传输完成后重命名。而 scp 则不会这样做,它会创建空文件,然后逐渐填充内容。

If the target file does not yet exist, an empty file with the target file name is created, then filled with the source file contents. No attempt is made at "near-atomic" transfer using temporary files.

我的理解是,文档里面说的 near-atomic 应该就是指 rsync 那种模式,而 atomic 的意思应该是指连临时文件都不用创建的模式。也不知道有什么文件系统支持这种模式。

#561 GitHub Copilot 争议

2021-07-14

七月二号发了一篇《吊炸天的 GitHub Copilot》,我表示非常期待这种技术的到来。
但是我并不知道他们是怎么弄的,没有考虑到其 AI 采用的训练集可能涉及的版权问题。
可以看到最近针对 Copilot 产生了巨大的争议,当前开发者社区的这种申讨氛围可能会让 GitHub 放弃 Copilot。

首先,GitHub 承认 Copilot 采用公开仓库代码做训练,不论其授权协议是 GPL 还是啥。
这里面有巨大的版权风险,虽然 GitHub 官方声称不会直接复制粘贴代码,但这种可能看起来就是 “洗代码” 的行为,无法说服别人他们拥有新代码的支配权。
更何况有人拿出了一些证据来证明 Copilot 会直接 Ctrl C + Ctrl V。

最近我使用 vscode 的时候,可以看到有时它会给我一些提示,真的感觉很棒。我不想 Copilot 被抛弃,希望 GitHub 或者 Google、IBM、阿里,或别的公司或组织,能解决所有争议,提供类似的产品,更好的服务开发者。

#560 Supervisor 最大打开文件数问题

2021-07-13

LOGO

线上服务日志中看到 Too many open files,于是检查了一番。

一、过程

确认:进程最大打开文件数

首先确认了系统没有限制最大打开文件数,但进程的最大打开文件数是限制的:

ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 30007
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 655350
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 327675
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

cat /proc/29749/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            10485760             unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             30007                30007                processes
Max open files            1024                 1024                 files
Max locked memory         65536                65536                bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       30007                30007                signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

解决方法

最后网上搜索之后,有人说 supervisor 有限制,我一检查果然是 supervisor 服务器的最大打开文件数问题:

[supervisord]
...
minfds = 65535
...

改成 655350,之后再看 proc 信息,就好了。

PS: 好像 reloadrereadrestart 都没用,需要关闭 supervisor 重启服务才能生效。(有待进一步确认)

二、minfds 配置

官方解释:

The minimum number of file descriptors that must be available before supervisord will start successfully. A call to setrlimit will be made to attempt to raise the soft and hard limits of the supervisord process to satisfy minfds. The hard limit may only be raised if supervisord is run as root. supervisord uses file descriptors liberally, and will enter a failure mode when one cannot be obtained from the OS, so it’s useful to be able to specify a minimum value to ensure it doesn’t run out of them during execution. These limits will be inherited by the managed subprocesses. This option is particularly useful on Solaris, which has a low per-process fd limit by default.
Default: 1024
Required: No.
Introduced: 3.0

这个名字很有迷惑性,怎么看也想不到进程的最大打开文件数上面去,不过官方文档也能自洽:这是保证 supervisor 正常启动的一个最小值,相当于一个检查点。然后它会调用 setrlimit 设置子进程的最大打开文件数。

#559 去除噪点的简单实现

2021-07-10

最近在学习图像处理,然后看到一个概念:连通域,并且了解到了一些相关的算法:two pass,seed filling。
学习的时候是自己写方法实现,今天了解到了 CV 中有一个方法可以简单的计算连通域,然后写了一个简单的函数作为 Demo。

#557 使用 git push --force-with-lease 替代 git push --force

2021-07-05

今天注意到了 git push 的一个参数 --force-with-lease,可以在 Remote 有更新的时候不执行强推。
我之前考虑过会有这样的情况发生:我准备强推之前,会做最后一次拉代码检查,无误之后 force push。但是这个检查和 push 之间有一个时间差,会不会在这期间有别的小可爱提交了代码呢?
这种情况是完全可能存在的,就像是线程安全问题,只是团队的规模消减了我对这种情况的担心。
但是 --force-with-lease 参数可以彻底化解我的这种担忧,我决定以后就改用这个参数了。