猫鱼周刊 vol. 026 退一步海阔天空
编辑关于本刊
这是猫鱼周刊的第 27 期,本系列每周日更新,主要内容为每周收集内容的分享,同时发布在
博客:阿猫的博客-猫鱼周刊
RSS:猫鱼周刊
邮件订阅:猫鱼周刊
微信公众号:猫兄的和谐号列车
这张照片是在深圳宝安前海演艺公园拍的欢乐港湾的摩天轮,这算是在深圳我最喜欢的地标了。趁着 618 买了 a6700 作为我的第二台相机,准备重拾一下摄影这个老爱好。理想情况下,以后每周周刊都会有一张好看的图片作为点缀。
文章
X-Y Problem
原文是左耳朵耗子陈皓写于 2013 年的文章,虽然我今天要分享的内容并不是受这篇文章启发,但是我在他这里第一次知道这个概念,因此留个 coolshell 的链接。他的博客虽然不再更新,但是很多内容还是很新鲜的,值得翻阅。
X-Y 问题指的是有人想解决问题 X,他想到一个可能的解决方案 Y,但是他不知道 Y 该怎么做,于是去问别人 Y 该怎么做;在解决过程中,大家在 Y 上耗费了大量时间,才发现原始的问题是 X,而 Y 根本不是解决 X 的合适方案。
X-Y 问题最早由 Eric S. Raymond 在 How To Ask Questions The Smart Way 中提出(中文版),主要强调在提问过程中最好把事情的背景阐述清楚。很多时候,这个问题被归类成沟通技巧,但在技术方案设计中,也经常发现有人会犯这个错误。
coolshell 的文章中已经有很多工程实践中的例子,我不再赘述。我想提出一个解决这个问题的好方法:退一步。在你提出一个解决方案,并准备开始调研时,先退一步,先列出问题的背景、方案拟解决的问题,再来想这个方案是否能满足这些具体的需求点,是否把问题复杂化了。在设计中,经常会出现初始的设计不能满足所有的需求,需要给方案打各种补丁的情况。这时候,把现在方向中需要的补丁提炼成一个硬需求清单,回到原点开始重新想,有没有能满足这些需求,又比现在这个方案更优化的方案。
当然了,这个思维路径可能不是一下子就能形成,有一个很简单的方式可以帮助你:写技术方案时先写背景和目的。我知道很多技术同僚不擅长也不喜欢写文档,但是习惯了开头先写背景和目的,能够帮助你主动地去完成“退一步”的过程,站在一个更高的角度去审视当前的问题和你拟提出的方案。
F1 赛事中的旗语
最近刷到一个 F2 摩纳哥站的视频(B 站链接),后车选手在隧道中施展了一次闪避避免了事故,很多人讨论说选手的反应真快云云。实际上,在进入隧道时,赛道马修就已经向后车选手发出白色灯光信号(警告车手前方有慢速车辆,可能存在危险)。
车手自身素质确实过硬,但是赛车比赛的安全实际上是由多方保证的,从车手本身、车辆设计再到赛委指挥、赛道马修。赛车在赛道上疾驰,最靠谱的交流方式就是视觉信号,因此赛车比赛设计了多种不同旗语来达成赛道上信息交换的目的。这篇文章普及了各种旗的含义及用途,还挺有意思。
绕过证书绑定
道高一尺,魔高一丈。一般大家认为,做了 Certificate Pinning 就能防住抓包了,但实际上还有很多公开的方式可以绕过。
没有百分百的安全。没有单一的完美的安全防护方案,只有通过多种方式组合,才能使进攻难度系数直线上升,直到攻击的成本大于攻击成功的收益。
项目
为对话场景设计的文本转语音模型
这个项目这周都刷屏了,效果比之前抖音那些什么悟空的音效都要好。如果你感兴趣,这里有个 demo 可以在线生成。
我自己试了一下,英文的效果不怎么好,甚至说有点毛骨悚然,不过中文的效果确实不错。
可自建的问卷系统
滴滴开源的问卷系统,可以自建。第一次知道滴滴也有做开源。
工具/网站
深入浅出现代 Web 编程全栈公开课
一个由赫尔辛基大学(Linus Torvalds 的母校)发起的公开课,主要使用 JS/TS。内容很好,而且有中文翻译。JS/TS 可能是开源社区最喜欢的语言(见链接),用它来开发全栈项目也很适合。
最后
本周刊已在 GitHub 开源,欢迎 star。同时,如果你有好的内容,也欢迎投稿。如果你觉得周刊的内容不错,可以分享给你的朋友,让更多人了解到好的内容,对我也是一种认可和鼓励。
另外,我建了一个交流群,欢迎入群讨论或反馈。
- 0
- 0
-
赞助
微信赞赏码 -
分享