文章 链接到标题

技术 链接到标题

Less: Quickly Jump to Line Number in Large File - Super User

[[less]] 命令小技巧: less +100g 跳转到 100 行开始; less +50p 跳转到文件的 50% 开始。


网络中的环路和防环技术 | 卡瓦邦噶!

上一篇 网工闯了什么祸? | 卡瓦邦噶! ,当时我只看出 ARP 没有响应,没有看出更多细节。可以通过 [[WireShark]] 打开 Delta time Displayed 列,Delta time 的含义是这个包抓到的时间距离上一个包过去了多久,比如可以看到同样是 ARP request,但是可以看到距离上一个“请求”过去 5us 就有了下一个请求,所以这个包不是发出去的包而是收到的包,说明网络出现了环路。

可以使用 [[tcpdump]] -Q in/out/inout 来抓取指定方向的包。


MacRumors Buyer’s Guide: Know When to Buy iPhone, Mac, iPad

[[Apple]] 家产品的购买建议指导,会标明产品的上一次发布周期,平均发布周期,最近更新时间等等。


Kubernetes 与 Cybernetics (初稿)

海剑同学的文章,关于控制论和 [[kubernetes]] 的关系。

kubernetes 是一个典型的负反馈控制系统,它基于负反馈等控制方法实现了高效实时稳定的容器编排管理。一个控制系统可以由多个子控制系统组成。一个大的目标可以拆分成多个小目标,并由不同的子控制系统协作完成每个小目标,直至整个大的目标达成。


生活 链接到标题

Do not try to be the smartest in the room; try to be the kindest. | Jorge Galindo’s blog

不要试图成为房间里最聪明的人;努力成为最善良的人。

只有少数人会想念房间里最聪明的人,但每个人都会想念善良的人。

  • 保持倾听
  • 保持尊重
  • 富有同理心
  • 下定决心

The Science of Having a Great Conversation | WIRED

与他人建立有意义的联系可以改善您的健康,使您思维更加敏锐,并激发创造力。交朋友可能会令人畏惧,但研究表明有很多方法可以建立更好的联系。

对话的艺术既是倾听的艺术,也是被倾听的艺术。实现这一目标的最简单的方法就是多问问题,提问题的数量与好感度有正向关系,提出问题,表示你想要建立互相了解的想法。后续问题如果是带有之前聊天中的一些信息,比直接改变话题更容易吸引人。 在对话中,可以通过一些方式来表示自己的注意力在对方身上,比如通过一些肢体表达(前倾,点头),或者更进一步,直接复述对方的观点。你可以在确认他们所说的内容后,提供另一种解释,这可能会让对方以一种新的角度看待情况。在提出你的替代方案之前,你必须表明你至少尝试以他们的方式看待事情。 自我表露甚至可以增加来自不同社会群体的人之间的联系,增加亲密程度。

这篇文章让我想到之前黄执中说过,“上堆下切”,向上总结,向下细分。我不喜欢上堆式的沟通,会让我完全失去聊天的动力。


书影 链接到标题

《何以当归》,食贫道的记录片,讲述当下台湾社会现状和意识形态的发展。连续看了几个食贫道的视频,观点是明确的,呈现出来的内容还是太少了,无论是叙事角度还是叙事深度,都容易让人产生在影响观众的潜在想法。可能适合 B 站。

碎碎念 链接到标题

  • 有时候沟通费劲到,我想把《提问的智慧》打印初到快递给对方面前。
  • 测试的时候没问题,大家都说理论没问题,但是实际操作,理论根本不管用,顶多给你叠加一些经验,处理问题的经验吧,所以我们以前特别害怕一句话,就是理论没问题,根据墨菲定理,基本就要出事,所以每次运维,其实都是一次新的开始,每个人都一样~

  • 所以作为测试,我也是巨讨厌说理论上没问题的。要是没问题数据说话。

  • 有时候看到一些 Startup 公司,相较于他们的产品,更喜欢看他们的博客。

理论上没问题 链接到标题

最近在开发的一个产品进入到了准备发布阶段,产品经理使用该产品在 Dogfood 上进行了主要路径的执行,遇到了一些问题,这些问题如果让我从研发角度来解释,都可以解释的通,也都会觉得是”合理“的,只是从最终用户的角度来看,肯定是无法被接受的。

一个老运维说,虽然研发都说”理论没问题“,但是实际变更上,都是问题,测试老版说”巨讨厌说理论上没问题的“。

我自己之前没注意过,于是去 Slack 上搜索了一下,发现我确实说过不少“理论上没问题”,通常是问了一个边界场景是否支持,我自己没有测试过,从代码角度看确实是没问题,但实际是否可以不确定,这个时候我好像只能说“理论上没问题”。 但是从测试角度看,可能是:“你提供了一个功能,但是自己不清楚功能的边界,让我去测试”,可能会给人留下敷衍的态度,不喜欢这样的句式可以理解。

是否需要改善?目前看这样的句式会给人带来困扰,应该需要改善的,至少要具体一些?我能想到的可能改善方式:

  • 我不清楚这个场景,需要验证一下;
  • 理论上没问题,但是实际上要考虑 xx 的影响;

好像也没好到哪里去。。。