简言之就是ssh client更新了，不支持rsa的私钥，导致无法登陆。

ssh登陆服务器，出现类似下面的提示：

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA ... agent
debug1: send_pubkey_test: no mutual signature algorithm <-- ssh-rsa is not enabled 
debug1: No more authentication methods to try.
user@hostname: Permission denied (publickey).

本来以为是key弄错了，或者服务器被hei了。加上 -v 参数才发现问题。

解决方案也很简单，就是在 ~/.ssh/config 中增加:

Host *
    ServerAliveInterval 30
    PubkeyAcceptedKeyTypes +ssh-rsa

如果是出现：no matching host key type found. Their offer: ssh-rsa,ssh-dss 的错误，还需要配置：

HostKeyAlgorithms=ssh-rsa,ssh-dss

具体原因： https://www.openssh.com/txt/release-8.2 参考：https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

一、

前几天@Manjusaka 给我发来一个截图，如下:

自己创作/分享的内容能够帮到别人确实值得开心，尤其是别人给你直接的反馈。

这种快乐我称之为滞后的快乐，这种快乐可以持续很久，知道你的内容被从互联网抹除，或者你被从星球上抹除。

从我的写博客、分享内容的经验来说，分享本身就是让人兴奋的一件事。脑袋中空想的东西，如果不寄托到电子呈现出来的文字上，你很难把它具象化。偶尔会看过去几年十几年写的内容时会好奇自己那时的脑袋中是在想什么，处于什么样的境地，能把想法化为这样的文字。

片段的分享比较轻松，能比较快的击中你的兴奋点，反馈途径足够短。当然快乐也有限。这类经历多了，也就免疫了。所以会发现那些文字写的足够多的人，开始系统的输出。

二、

系统的输出刚开始并不是特别有趣，因为反馈路径足够漫、足够长。

比如我写的《Django企业开发实战》花了一年左右的时间。中间的过程并不是那么舒服，想象下要把一团团棉花不断的压缩成一片一片的样子，然后整理起来。

在此之前我也是花了近两年的时间录制了 《Django实战开发》的视频，时长达 2499 分钟。中间的过程也不是由快乐裹挟，而是要始终拧着一股劲才行，保持、保证足够的专注。说实话，并不容易。

不过好处就是你有了更具象的东西，视频相对于文字，更加丰富，也更由录制时的内味儿。纸质书相对于电子文字更加具象，可触摸，可感受。

三、

从开始写博客几年后通过网络结识了不少人，也收到过很多反馈。至今通过 the5fire 这个 ID 在网上还能找到各种各样的碎片信息。相对于碎片的内容，足够系统的内容显然更能产生成就感和快乐。

比如近两年的快乐就来源于《Django企业开发实战》的读者，以及对应的视频。有些是来自网友的反馈，有些是来自生活中的朋友，同事。正向的反馈会让你觉得这个事做的还不错。具体的反馈内容这里就别贴上来了。当然也有来着网络某一角陌生人的 Diss，这个确实是让人不太舒服的一点，好在属于少数，把内容保留好，激励自己也不错。毕竟这样才能看到上升空间。

四、

前段时间有同事说也要写本书，聊了一下。现在愿意写书的人，都不是冲着钱来的，这点确实遗憾，始终无法形成足够正向的飞轮。大家的目的都是整理、分享、做点实质的输出、有所贡献。

当然，技术书也不是说都不畅销（zhengqian），比如今天要送出的由图灵赞助的《Python 3反爬虫原理与绕过实战》，据说很畅销。爬虫类的内容果然适应性足够广。

本篇文章的正题是分享下我对分享反馈的想法，当反馈的碎片快乐积累的足够多，不如压缩一下，系统整理。有兴趣写书的同学可以给我留言，我推荐编辑给你。

另外捎带着发一些福利，从去年离开知乎后一直在学习新行业的业务知识，疏于书写。发现公众号读者还在不断增加。感谢各种读者的保留（当然也可能忘了还关注着这么个公众号）。

五、赠书 三本

参与方式：

关注公众号：Python程序员杂谈，

在本篇文章（公众号对应的文章）下留言即可，我会随机抽出三位读者，截止日期：2020-03-21 08:00，中奖读者会收到我的回复，需要在2020-03-23 08:00 前发送邮寄地址给我。

中奖名单|《代码里的世界观》赠书活动

经过一周的沉淀，这次的数据看起来比较正常，从文章阅读量上就能看出来。恭喜这次中奖的读者：

前两名：

随机两名：

{'侯国威', '青鸟'}

随机代码：

import random

readers = [
    '刘玉龙',
    'testercode',
    'RuntimeError',
    'PaperSheep',
    '独角兽男孩',
    '侯国威',
    'MrLi',
    '镇上村树',
    '朝菌',
    'DouWo',
    '(X_X）',
    'JAMI',
    '青鸟',
    'orangleliu',
]

final_readers = set()
while len(final_readers) != 2:
    final_readers.add(random.choice(readers))

print(final_readers)

关注最早的读者：

orangleliu

请所有中奖读者 {'星辰', 'Guang', '侯国威', '青鸟', 'orangleliu'} 尽快把邮寄地址和电话发给我，通过公众号回复的功能（注意不是留言）。

没中奖的读者可以保持关注，福利还会有。当然也可以直接去购买这本书:

https://item.jd.com/12501348.html

最近在做大量的代码 Review 的工作，尝试整理出一些大家在写代码时要避免的一些问题，同时也在读《代码整洁之道》和《代码里的世界观》。也在知识星球（同公众号名：Python程序员杂谈）中发了一些关于代码设计的内容。

1. 不做需求翻译器

绝大部分程序员在入门编程时学习的第一门课程/书籍差不多都会是《 XXX 程序设计》，但是很多人在实际写代码时却完全不做任何设计的工作，只是单纯的把产品的需求翻译为可执行的代码。对于软件开发来说，这是入门阶段，毕竟程序员的第一要务还是要把产品的需求转变为可运行的系统/软件。 这种做法就像我们刚开始学习写作文时那种流水账式的写法，能表达信息（实现功能），但是内容冗余，不易维护。

所以我们在接需求时，需要做的是充分理解产品需求，什么叫充分理解产品需求呢？实际工作中很简单，你能给其他人讲明白要做的产品需求是啥即可。之后需要做的是根据产品需求思考应该怎么实现，对其中的逻辑做一些抽象。

单纯讲可能不太容易理解，举个例子，有这么一个需求，写一个函数判断用户上传图片文件的是否合法。需求描述是，如果后缀是.txt则返回不合法，如果后缀是.gif返回不合法，如果后缀是.mp4返回不合法。（等一系列不合法的后缀）。

那么怎么实现呢，如果不加思索的写代码就会出现这么个状况：

def is_valid_filetype(suffix):
    if suffix == 'txt':
        return False
    if suffix == 'gif':
        return False
    if suffix == 'mp4':
        return False
    return True

这样写代码的问题是什么？暂且不说需求问题。代码的问题在于，如果我需要新增一个不支持的类型，那就要新增一个if判断。显然更好的做法是:

invalid_suffix_set = {'txt', 'gif', 'mp4'}


def is_valid_filetype(suffix):
    return not suffix in invalid_suffix_set

这么一改看起来简单多了，消除了if分支语句（这个是代码设计中很重要的部分），并且改成了基于配置的方式，新增不合法后缀只需要去修改配置invalid_suffix_set即可，不涉及代码逻辑改动。

但是我们再回过头来看下需求，是不是有什么不妥。写一个函数判断用户上传图片文件的是否合法。相信读者已经看出来了，这个需求其实有问题：需要枚举出所有不合法的后缀，鬼知道有多少中文件后缀。虽然我们做了不合法后缀的配置，但是还需要经常去做修改来支持新发现的文件后缀。

所以应该去反问下产品，哪些文件是合法的？显然这是一个可以有限枚举的内容。最终可能得到的代码是这样：

valide_suffix_set = {'png', 'webp', 'jpg', 'jpeg'}


def is_valid_filetype(suffix):
    reutrn suffix in valide_suffix_set

2. S.O.L.I.D 原则

SOLID 这个词很多人可能没有听说过，这是程序设计时经常用到的一些原则，如果你看过设计模式，应该知道，所有的设计模式都会基于这些原则。SOLID 什么意思呢？为了避免不了解的读者此时关闭文章去搜索（笑），我列到这里：

在程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在21世纪早期[1] 引入的记忆术首字母缩略字[2][3]，指代了面向对象编程和面向对象设计的五个基本原则。

- S 单一功能原则  认为对象应该仅具有一种单一功能的概念。
- O 开闭原则    认为“软件体应该是对于扩展开放的，但是对于修改封闭的”的概念。
- L 里氏替换原则  认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。
- I 接口隔离原则  认为“多个特定客户端接口要好于一个宽泛用途的接口”[5] 的概念。
- D 依赖反转原则  认为一个方法应该遵从“依赖于抽象而不是一个实例”[5] 的概念。 依赖注入是该原则的一种实现方式。

摘自：https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)

看到这些描述后，想必很多读者会叹一口气 —— 原来说的是这个。

我在 Review 代码时突然想到，如果每个程序员在设计程序，编写代码时，先念一串这样的「咒语」—— 「用 SOLID ，写好代码」，会不会能写出更好维护的代码。有些戏谑的成分，但是在写代码、做设计时需要一些原则来支撑。

关于这些原则，这里不做详细解读，对于知道的人可以经常拿出来 Review 下你写的代码，对于不知道的，需要去找几个例子，指导你写出更好的代码。

3. 最后

本次要赠的书就是《代码里的世界观》，看书名以为是偏软技能类的，但从内容上来说，软件设计的内容占大头。这本书可能理解为一个架构师的思考，因为各章节篇幅比较短，读起来相对容易。

感谢图灵出版社，本次赠书：5 本。

参与方式：老规矩——留言说下「你写代码、设计程序时的一些原则是什么」？

抽奖方式(去公众号留言)：

1. 点赞排行前两名
2. 前两名之外的留言中随机抽出两名
3. 没中奖的留言中抽出关注最早的一名

开奖时间：下周二（05.21 晚上 10:30)，可以关注公众号: Python 程序员杂谈 的文章

工作中几个能力是要有的：

• 算法能力，尤其是面试前需要刷一段时间的算法；
• 代码能力，对自己用到的语言/库/框架能够熟练到拿来即用；
• 设计能力，是指程序设计能力，除了能实现某个需求外，还需要考虑程序的健壮性和可维护性；
• 业务能力，能够知道需求方确切的想要什么，并且能够很好的沟通出需求方的需求。

怎么提高呢？个人看法如下：

• 算法的话，刷题会比较快，很多人都会以刷 LeetCode 为乐，挺好的事；
• 代码能力，只能是多写，做不同类型的项目，但是都需要做的足够完整，完成后需要总结下项目中用到的技术有哪些，以及有没有类似的技术；
• 设计能力，需要深入一个项目，足够完整，不断的迭代。只有一个项目不断迭代（不断啃自己之前写过的「烂」代码）的情况下，才能知道之前的设计有什么问题，以后如何避免；
• 业务能力，需要对自己所涉及的业务领域有足够多的了解，绝大部分情况下，技术只是支撑业务实现，只有当你掌握了足够的信息时，才能快速的 Get 到对方的点是什么，以及对方可能缺了什么。

回答链接：https://www.zhihu.com/question/321425347/answer/661430245