周刊第11期：扩大你的运气表面积（Luck Surface Area）

Published:

扩大你的运气表面积

想说两件事，第一件事，在上周的某天下午，我收到了一封邮件：

image-20220428231741858

这是 V2EX 上的一位老哥发来的邮件，他也在写周刊《野生架构师》，估计不少人都听过，毕竟最近在 V2EX 上比较活跃，收到这封来信让我非常开心，毕竟自己的周刊内容得到了他人的认可。

同时也让我知道了一个新的概念：运气表面积（Luck Surface Area）。

这个概念该如何理解，根据《How to Increase Your Luck Surface Area》的描述：

在你的生活中发生意外的数量，就是你的运气表面积，它与你所热爱的事情、以及被有效沟通的人数是成正比的，换句话说，你的运气是你自己创造的。

它的公式是：运气表面积 = 你采取的行动 [X] x 你沟通的人数 [X] 。

运气表面积的工作原理是这样的，当你投入精力去做某件事情，你分享出去，你就会产生价值，但很多时候，这个价值会被所影响的人放大，它有可能会以某种你未曾预料的方式回报你，比如招聘你、投资你，但无论以何种方式发生，它都是偶然的。

说回上面那封邮件，我之所以写周刊在《我为什么要写周刊》 中有提到，我希望我能够对我每周所阅读的文章做一份总结，以此巩固我自身的理解，并希望不时输出自己观点的同时也能够帮助到其他人。

正因为我写周刊，被这位老哥看到了，发来这么一封邮件，让我感受到了被认可的快乐，因此更加坚定了我继续写周刊的信心，这就是我的运气表面积在扩大，但这一切都是非常偶然的，我在做这件事情的时候，我没有预料到这一点，所以正是因为我做这件事情为我自己创造了运气。

另外一件让我感到运气表面积在扩大的事，在一直订阅的胡涂说的周刊《No.13: 周刊的周刊》发现了他推荐我的周刊，而他的原话是：

看到很多博主在写周刊，我想还是把这一传统给拾起来。

这让我想到了一件非常奇妙的事情，前段时间 V2EX 上有讨论 为什么忽然间大家都开始做周刊了，但我坦承我不是在跟风，或许别人也是如此，那么有没有可能是因为某一个人持续地在做这件事，影响了很多人，然后大家又互相影响，无形中扩大了大家的运气表面积，如果真是这样，那我认为是阮一峰影响了我，而我也可能在影响其他人。

最后从这里摘录一下以下三者的不同：

  1. 幸运是发生在你身上的事情，生在好人家是福，被雷劈是祸。
  2. 机会需要您采取行动。您需要抓住机会，例如购买彩票，或约某人出去约会，以从偶然事件中受益。
  3. 运气是成功或失败显然是偶然造成的。看起来这是一个机会，因为我们很少看到在成功或失败之前发生的一切。运气是通过发现和创造机会来实现的。这是你行为的直接后果。

所以，记住一件事情，你可以创造你的运气，只要你去做更多的事情影响别人。

本周见闻

POSSE 和 Mastodon

POSSE 的全称是 Publish (on your) Own Site, Syndicate Elsewhere，意为「在你自己的网站上发布，在其他地方联合」。

这是 2010 年首次在《Tantek Celik Diso 20 Brass Tacks》 提出的一种联合模型方案：

在你自己的网站上发布，拥有自己的 URL 和永久链接，并通过其他社交媒体、社区中公布该链接。

可以通过这段短片《Own your content on Social Media using the IndieWeb》快速了解 POSSE。

采用该模型的好处是：如果我的 Twitter 帐户被删除（被官方或我自己删除），我不会丢失任何重要内容。

其实已经不少人采用这个方案，譬如就不少博主都会将文章链接发到 Twitter、Telegram 频道上，一方面是起到推广的作用，另一方面正是因为 POSSE。

你也可以通过这个链接《POSSE - IndieWeb》 了解更多信息。

之所以越来越多人采用这个方案，都是因为对官方的不信任，所以希望把数据掌握在自己的手中，所以这里简单介绍一下 Mastodon：

Mastodon 是互联网上最大的去中心化的社交网络，它由一个非营利组织基于开放网络标准建立。

简单来说就是一个自托管的类 Twitter、微博的网站，你可以构建并部署自己的 Mastodon 实例，也可以加入他人的实例，顺便一提之前川普搞的社交媒体的 Truth Social 也是基于 Mastodon 的。

但 Mastodon 也有它的不足之处，譬如：

  1. 稳定性，毕竟只有少部分人在维护实例。
  2. 还没有一个好的策略去防止虚假信息，仇恨言论，骚扰等。

但也有不少人开始尝试从 Twitter 转向 Mastodon，比如 2ality 的博主 Axel Rauschmayer，有兴趣的同学可以从 Explore Fosstodon 开始探索。

造谣的成本有多低？

在如今的网络，造谣的成本非常低，比如我们就可以通过 Fake Details 这个网站去伪造各式各样的假信息，可以伪造下面这些社交媒体的假截图：

甚至只需要在某个完全不相关的视频上面截个图，就可以张冠李戴地套在另外一件时事上面，而我们该如何去辨别这些假信息呢？

在《周刊第4期：独立思考》 曾推荐过几个比较可靠的事实核查网站，这里再贴一下：

除了看以上这些网站给出的结论，我们还可以通过这些网站提供的核查工具箱，自己去学习如何做事实核查。

一些 tips

Chrome 用户体验报告比较工具

你只需要在 Chrome UX Report Compare Tool 这个网站上输入一个或多个 URL，它将会列出它们的各项性能指标，如下图：

image-20220505221453130

然而当我输入本 Blog 的域名时，它提示我：Chrome 用户体验报告中没有足够的数据，这是访问人数不够多的缘故。

如果想要了解背后的技术细节，可以看这篇文章《使用 Chrome 用户体验报告 API》。

使用 Javascript 的可选操作符可能会破坏你的代码

熟悉 JS 的同学都知道我们可以通过 obj?.x 这个语法来更安全地访问对象属性等，但是如果盲目地使用这个语法，可能会导致一些意想不到的事情发生，比如以下例子：

function test(value) {
    console.log(`${value && value.length}, ${value?.length}`);
}

test(undefined);       // undefined, undefined
test(null);            // null, undefined
test(true);            // undefined, undefined
test(false);           // false, undefined
test(1);               // undefined, undefined
test(0);               // 0, undefined
test({});              // undefined, undefined
test([]);              // 0, 0
test({ length: "a" }); // a, a
test('');              // , 0
test(NaN);             // NaN, undefined

通过这个例子我们发现，仅当值为 undefined 的时候，Optional Chaining 才有可能按照预期运行，所以我们编写代码的时候一定要多加注意，什么时候应该用 && 做短路判断，什么时候使用 Optional Chaining 语法。

在 git 仓库中使用 find . -exec sed 是很危险的

如果你想在 git 存储库中全局替换某个字符，那么你很有可能会遇到这个问题：Find and replace with sed in directory and sub directories，这是因为 find 命令没有忽略 .git 目录，运行该命令可能会导致 .git 目录损坏，所以更好的方式是使用 git ls-files：

git ls-files | xargs sed -i -e 's/apple/orange/g'

分享文章

凯文 · 凯利 70 岁生日写的 103 条人生忠告

2022年4月28日，凯文·凯利（Kevin Kelly）在他的网站上发布了 70 岁生日的文章：103 Bits of Advice I Wish I Had Known，意为：103 条我希望早点知道的人生忠告。

此为中译版，非常推荐阅读，在这里摘录我个人认为有启发的几句：

  1. 99%的时间里，真正关键的时刻就是此刻。
  2. 除了你以外，没有人会真的记得你拥有什么东西。
  3. “但是”之前的话都是废话。
  4. 当你原谅其他人的时候，他们不一定会知道这件事，但你自己却会被治愈。原谅不是我们给予他人的东西；而是我们给自己的礼物。
  5. 教育的一半作用是学习哪些东西可以被忽略。
  6. 不要相信你认为你相信的一切。
  7. 为了丰厚的回报，请对你完全不感兴趣的事物保持好奇。
  8. 重复别人是一个很好的开始。重复你自己则是一个令人失望的终点。
  9. 如果你对于一个主题的意见可以根据你另一个主题的意见预测得出，那你可能陷入了某种意识形态的掌控。如果你认真审视你自己的意识，你的结论其实是无法预测的。

质疑和信任

这是 Jeremy 两篇文章，主要讨论了本文作者发现的一个奇怪现象，Web 开发者普遍存在这样一种心态：他们会在项目中优先选择安装 npm 依赖，然后隐式地引入了更多的依赖，也就相当于完全地信任这些 npm 包以及它们的作者。

但作者认为更应该直接使用浏览器的原生特性，比如 HTML 元素、CSS 功能和 JavaScript API，虽然它们并不总是完美的，并且在开发过程中需要额外花费很多心思，但原生的特性更值得被信赖。

而关于这个话题的讨论将由此展开，有些人认为之所以普遍存在这样一种心态，是因为浏览器兼容性的缘故，譬如在 MDN 的 Overall Needs Ranking 中排名前 5 的需求有 4 个属于兼容性问题，以前的 jQuery 和 Bootstrap 就是在这样的需求下产生，而现在这种情况已经逐步得到改善，越来越多人开始倾向于使用浏览器原生特性，而不是借助第三方库，总得来说，Web 开发者对浏览器的信任正在恢复。

最后提出了一个设计原则：如果可用，请默认使用浏览器原生功能，而不是第三方库。

使用 Rust 开发单页应用程序

这是一篇使用 Rust 和 Yew 从 0 到 1 开发单页应用的文章，对于想要学习 Rust 和 Wasm 的同学可以看看。

有趣的链接

作者 : 4Ark

地址 : https://4ark.me/posts/2022-05-05-weekly-11/

来源 : https://4ark.me

著作权归作者所有，转载请联系作者获得授权。