遗憾最小化框架 —— 如何做决定
对于我来说，我一直认为自己缺少做决策的能力。成年人的生活不像学生时代，所有的题目都有固定答案。所有的选择都不存在绝对的对和错，它只是在人的一生 checkout 了一个新的 branch. 我总是不知道应该如何做决定。
刚好看到了 Jeff Bezos 曾经谈到了自己是如何做决定的，他称之为 Regret Minimization Framwork (遗憾最小化框架) —— 他会想象自己到了 80 岁的时候，是否会认为不做这件事情会让自己遗憾。尽量让人生的遗憾数量最小化。即使当时的选择后来看来是错误的，但也不会后悔尝试过。
我很受启发。想起在 4 年前，我曾经问 Cycle.js 的作者 staltz 一个 问题, 我问他是否也会因为自己做的库没有像 React / Vue 那样火起来而感到气馁。他说他偶尔也会感到气馁，但他一直以来做事遵循一个 guideline:
via Randy's Blog
对于我来说，我一直认为自己缺少做决策的能力。成年人的生活不像学生时代，所有的题目都有固定答案。所有的选择都不存在绝对的对和错，它只是在人的一生 checkout 了一个新的 branch. 我总是不知道应该如何做决定。
刚好看到了 Jeff Bezos 曾经谈到了自己是如何做决定的，他称之为 Regret Minimization Framwork (遗憾最小化框架) —— 他会想象自己到了 80 岁的时候，是否会认为不做这件事情会让自己遗憾。尽量让人生的遗憾数量最小化。即使当时的选择后来看来是错误的，但也不会后悔尝试过。
我很受启发。想起在 4 年前，我曾经问 Cycle.js 的作者 staltz 一个 问题, 我问他是否也会因为自己做的库没有像 React / Vue 那样火起来而感到气馁。他说他偶尔也会感到气馁，但他一直以来做事遵循一个 guideline:
Ask yourself: in 10 years from now, will you be proud of having done this? ... Do things that your future self will be proud, is my motto for the time being.记得在一年前决定是否接收微软的 offer 的时候我非常犹豫，因为微软给出的 offer 比其它国内「大厂」给的少非常多。但是我回想起初中的时候，读了很多关于比尔盖茨的传记、微软的创业故事，十分向往。那时候的我没有预料到我将来有一天竟然有机会加入这家公司。也不会想到作为一个大学没有毕业的人竟然也得到了这样的机会。我也咨询了很多朋友我是否应该接受这个机会，他们有的会说其实在微软写的代码甚至没有在国内的公司那么 fancy. 但是我想，在加入了微软之后即使在后来可能发现这未必能得到我想象中的东西，但如果在很多年后回想起来我曾经放弃了这个机会，我一定会后悔没有尝试体验一下在这家公司工作。所以最后我决定接受了这个 offer.
via Randy's Blog
我给自己设立了每月 $20 的开源捐赠预算
Babel 官方最近发布了一篇博客 称 Babel 团队的 funding 已经不够了。一直以来我零碎地捐赠过一些开源项目和个人，在卖贴纸和 T 恤的时候也把大部分的利润捐赠给了 Vue. Babel 这件事让我有了固定每月捐赠一些开源项目的想法。
目前设定的是每月至少 $20 (约 130 多元人民币) 的预算，这样平均至少可以捐赠 4 个不同的项目。我可以在这个预算内根据我的技术栈灵活地选择我对哪些项目进行捐赠。
我个人会选择一些这样的项目进行捐赠：
● 我在做 side-project 的时候经常会用的项目
● 项目没有融资背景（例如我非常喜欢 Prisma, 可是它已经有了 $12M 的 A 轮融资）
● 做了一些我用到的工具的个人开发者
目前我捐赠的项目和个人
● EGOIST 在全职做开源的好朋友
● chakra-ui 我用 React 写 side-project 必用的 UI component 库
● dayjs 我经常会用的 moment.js alternative
● react-query 我经常会用的 React 请求库
● next-auth 非常好用的 Next.js OAuth 库
● Logseq 开源的 Roam Research alternative
你可以在 OpenCollective 和 GitHub Sponsor 看到我对哪些项目和个人进行了捐赠。
国内用户捐赠的方法
国内用户捐赠只要具有以下其中一个条件即可：
● 注册 Paypal 账号和国内银行卡绑定
● 持有一张 Visa 信用卡
OpenCollective 支持 Paypal 和信用卡，甚至支持银联的信用卡，因此一般国内用户都能很容易通过 OpenCollective 进行捐赠。GitHub sponsor 不支持 Paypal, 需要 Visa.
除了每月固定的捐助，还可以选择一次性的捐助。
我对开源的看法
我从开放的源代码学到了非常宝贵的知识，这些知识帮助我成为了更好的程序员。功利一些来说，我通过使用这些开源项目得到了可以谋生的岗位，这些开源项目竟然是开放和免费的。
有些人认为，做了一个成功开源项目，即使没有钱，也收获了名气。对我个人来说，我确实也通过做开源项目得到了非常多的机会，但是正是自己做过开源项目，才深知维护一个开源项目的成本不是靠「名气」就可以支撑起来的。
关于这个话题，强烈建议收听牛油果烤面包的这一集 Podcast: 《#70. 和Vue.js的创造者尤雨溪聊开源软件》
也可以读一读这本 Working in Public: The Making and Maintenance of Open Source Software, 里面有很多开源软件维护者面临的问题。
我们可以为开源做什么？
● 根据自己的经济情况，设立一个捐赠预算（$1 也很不错），给自己生活中、工作中用到的开源工具进行捐赠。
● 和我一样写一篇文章介绍你对哪些项目进行了捐赠，鼓励更多的开发者对开源项目捐赠。
● 贡献有意义的 PR，即使只是文案的修改。
via Randy's Blog
Babel 官方最近发布了一篇博客 称 Babel 团队的 funding 已经不够了。一直以来我零碎地捐赠过一些开源项目和个人，在卖贴纸和 T 恤的时候也把大部分的利润捐赠给了 Vue. Babel 这件事让我有了固定每月捐赠一些开源项目的想法。
目前设定的是每月至少 $20 (约 130 多元人民币) 的预算，这样平均至少可以捐赠 4 个不同的项目。我可以在这个预算内根据我的技术栈灵活地选择我对哪些项目进行捐赠。
我个人会选择一些这样的项目进行捐赠：
● 我在做 side-project 的时候经常会用的项目
● 项目没有融资背景（例如我非常喜欢 Prisma, 可是它已经有了 $12M 的 A 轮融资）
● 做了一些我用到的工具的个人开发者
目前我捐赠的项目和个人
● EGOIST 在全职做开源的好朋友
● chakra-ui 我用 React 写 side-project 必用的 UI component 库
● dayjs 我经常会用的 moment.js alternative
● react-query 我经常会用的 React 请求库
● next-auth 非常好用的 Next.js OAuth 库
● Logseq 开源的 Roam Research alternative
你可以在 OpenCollective 和 GitHub Sponsor 看到我对哪些项目和个人进行了捐赠。
国内用户捐赠的方法
国内用户捐赠只要具有以下其中一个条件即可：
● 注册 Paypal 账号和国内银行卡绑定
● 持有一张 Visa 信用卡
OpenCollective 支持 Paypal 和信用卡，甚至支持银联的信用卡，因此一般国内用户都能很容易通过 OpenCollective 进行捐赠。GitHub sponsor 不支持 Paypal, 需要 Visa.
除了每月固定的捐助，还可以选择一次性的捐助。
我对开源的看法
我从开放的源代码学到了非常宝贵的知识，这些知识帮助我成为了更好的程序员。功利一些来说，我通过使用这些开源项目得到了可以谋生的岗位，这些开源项目竟然是开放和免费的。
有些人认为，做了一个成功开源项目，即使没有钱，也收获了名气。对我个人来说，我确实也通过做开源项目得到了非常多的机会，但是正是自己做过开源项目，才深知维护一个开源项目的成本不是靠「名气」就可以支撑起来的。
关于这个话题，强烈建议收听牛油果烤面包的这一集 Podcast: 《#70. 和Vue.js的创造者尤雨溪聊开源软件》
也可以读一读这本 Working in Public: The Making and Maintenance of Open Source Software, 里面有很多开源软件维护者面临的问题。
我们可以为开源做什么？
● 根据自己的经济情况，设立一个捐赠预算（$1 也很不错），给自己生活中、工作中用到的开源工具进行捐赠。
● 和我一样写一篇文章介绍你对哪些项目进行了捐赠，鼓励更多的开发者对开源项目捐赠。
● 贡献有意义的 PR，即使只是文案的修改。
via Randy's Blog
做这个世界的生产者
偶尔看到这篇名叫 Consume less, create more 的文章，是作者从「消费者」转变为「生产者」的心路历程。他每天在巴士上面用 iPhone 写点什么，最终写出了这篇文章。
我从懂事开始就一直觉得自己在这个世界上与众不同，觉得自己的出生一定是背负了某个特殊的使命。后来发现原来每个人年轻的时候都是这么想的，随着年纪渐长，大多数人开始接受自己只是个普通人的事实。我也不例外。
但唯一没有变过的是我没有因为意识到了自己的平凡而停止了试图变得不平凡。其中的一个表现就是我希望在这个世界上，我是作为一个生产者存在的，而不只是一个消费者。
写博客、编程、做音乐都是我的生产，即使我写的博客没有让我成为几十万粉丝的 KOL, 我写的代码没有几万的 star, 唱的歌的观看数只是几百，我还是保持生产，因为对于这个世界，能让我有那么一点与众不同的是我的生产，而不是我的消费。
我讨厌抖音，不是因为它的内容，是因为它默默地把人驯化成了贪婪的信息消费者。如果我什么都不创造，那么我每天看 Hacker News 和别人每天刷抖音没有任何区别。
这个世界的每个人都是消费者，但不是每个人都是生产者。如果你也希望为这个世界留下点什么，就去创造，别担心你创造的是不是垃圾，只要创造了，是一定会有收获的。
via Randy's Blog
偶尔看到这篇名叫 Consume less, create more 的文章，是作者从「消费者」转变为「生产者」的心路历程。他每天在巴士上面用 iPhone 写点什么，最终写出了这篇文章。
我从懂事开始就一直觉得自己在这个世界上与众不同，觉得自己的出生一定是背负了某个特殊的使命。后来发现原来每个人年轻的时候都是这么想的，随着年纪渐长，大多数人开始接受自己只是个普通人的事实。我也不例外。
但唯一没有变过的是我没有因为意识到了自己的平凡而停止了试图变得不平凡。其中的一个表现就是我希望在这个世界上，我是作为一个生产者存在的，而不只是一个消费者。
写博客、编程、做音乐都是我的生产，即使我写的博客没有让我成为几十万粉丝的 KOL, 我写的代码没有几万的 star, 唱的歌的观看数只是几百，我还是保持生产，因为对于这个世界，能让我有那么一点与众不同的是我的生产，而不是我的消费。
我讨厌抖音，不是因为它的内容，是因为它默默地把人驯化成了贪婪的信息消费者。如果我什么都不创造，那么我每天看 Hacker News 和别人每天刷抖音没有任何区别。
这个世界的每个人都是消费者，但不是每个人都是生产者。如果你也希望为这个世界留下点什么，就去创造，别担心你创造的是不是垃圾，只要创造了，是一定会有收获的。
via Randy's Blog
这个月我将离开阿里巴巴，结束至今 4 年的阿里生涯。
在阿里的 4 年我体验到非常多的东西，了解到了作为一个「职业程序员」的工作状态，认识了很多很靠谱的同事。尝试了一些东西，创造了一些东西，也吸收了一些东西。
我很幸运，这几年我遇到的老板都对我非常好。在 UC, 甄子给了我很大的自由度，让我得以在技术上做很多的探索 。在花呗，完颜和我一起做了很多次难忘的乐队演出。我很喜欢 花呗前端团队 ，这里的同事很有趣，在一起工作非常快乐，他们在面对复杂且繁忙的业务时展现的专业性是我难以企及的。
Why leave?
在大公司，成为一个优秀的业务型程序员要做的更不仅仅是理解业务需求。而我更擅长的是用技术解决效率问题、通过设计降低软件复杂度（Programming complexity）。但在业务 deadline 面前，这些仿佛是次要的。很少人有精力在 deadline 和加班面前能保持追求代码质量和软件设计，但这却是保证软件稳定和快速迭代的基础。为了快速上线而忽视代码质量的代价是很沉重的，但没人会指出这些技术债的根本原因就是太着急了，整个环节都太着急了。
我也不擅长画大图，把事情说得很宏大。阿里是一个很大的公司，有很多内部系统（所谓的「中台」）已经很完善，不是每个人都有机会遇到「大」问题。但是如果不做点什么大事，在阿里的仕途不会很顺利。所以我目睹了许多因为 KPI 和职级晋升产生的内耗。它潜移默化地使人做事变得功利，它就像一把声音在你做事的时候默默地提醒你：要把事情做大。
我从 Apple 和乔布斯身上理解到了在做同一件事时，不同的目的会导致做出来的东西天差地别。钱很重要，但如果乔布斯做产品的目的是钱而不是用户体验，那么 Apple 不会是今天的这个 Apple. 我认为做技术产品也是一样的道理，「做好」应该是目的。但能遇到适合「做大」的技术产品的场景是很靠运气的，在这样的情况下，绩效和晋升的压力会让人不得不把「做大」变成了目的，这就导致了：
● 简单的事情复杂化，增加使用者的理解成本（ Cognitive Load ）
● 能使用现有的技术，偏要自己再做一套。由于「做大 -> 晋升」是目的，这样的产品有很大的机率在达成了目的后被放弃。
● 做事态度变成「能用就行」，不关心用户体验。
这样的做事方式不适合我，也违背了我做技术的理念。
What’s next
我还没有一个很确切的计划，但我希望能去一个地方，定义我价值的不仅仅是因为我用了多牛逼的技术，做了一个多大的「平台」，而是我用技术的手段，给用户创造了什么他们觉得有价值的东西，如何改进了用户体验。又或者我用技术解决了哪些效率问题。
更具体的目标是成为 Tech Lead 的角色。同时我对 Growth Hacking 有很大的兴趣，希望可以结合技术和数据找出产品增长的瓶颈、把产品做得更好，帮助产品实现增长。
我会回到广东，离开杭州。
Conclusion
离职不是什么苦大仇深的事，我对阿里没有任何的怨念，阿里有很多很好的地方，只不过不属于这篇文章要讨论的范围。无论在哪个地方，我想要的都是和一群有想法的人一起打磨一个有价值的产品，而不是不同职能的团队都只做对自己 KPI 有利的事。每个公司都有其独特的生存法则，但这个生存法则也应该让那些务实和纯粹的人能很好地生存下去。也许这就是我作为一个技术人的理想主义吧。
via Randy's Blog
Invalid media: image
在阿里的 4 年我体验到非常多的东西，了解到了作为一个「职业程序员」的工作状态，认识了很多很靠谱的同事。尝试了一些东西，创造了一些东西，也吸收了一些东西。
我很幸运，这几年我遇到的老板都对我非常好。在 UC, 甄子给了我很大的自由度，让我得以在技术上做很多的探索 。在花呗，完颜和我一起做了很多次难忘的乐队演出。我很喜欢 花呗前端团队 ，这里的同事很有趣，在一起工作非常快乐，他们在面对复杂且繁忙的业务时展现的专业性是我难以企及的。
Why leave?
在大公司，成为一个优秀的业务型程序员要做的更不仅仅是理解业务需求。而我更擅长的是用技术解决效率问题、通过设计降低软件复杂度（Programming complexity）。但在业务 deadline 面前，这些仿佛是次要的。很少人有精力在 deadline 和加班面前能保持追求代码质量和软件设计，但这却是保证软件稳定和快速迭代的基础。为了快速上线而忽视代码质量的代价是很沉重的，但没人会指出这些技术债的根本原因就是太着急了，整个环节都太着急了。
我也不擅长画大图，把事情说得很宏大。阿里是一个很大的公司，有很多内部系统（所谓的「中台」）已经很完善，不是每个人都有机会遇到「大」问题。但是如果不做点什么大事，在阿里的仕途不会很顺利。所以我目睹了许多因为 KPI 和职级晋升产生的内耗。它潜移默化地使人做事变得功利，它就像一把声音在你做事的时候默默地提醒你：要把事情做大。
我从 Apple 和乔布斯身上理解到了在做同一件事时，不同的目的会导致做出来的东西天差地别。钱很重要，但如果乔布斯做产品的目的是钱而不是用户体验，那么 Apple 不会是今天的这个 Apple. 我认为做技术产品也是一样的道理，「做好」应该是目的。但能遇到适合「做大」的技术产品的场景是很靠运气的，在这样的情况下，绩效和晋升的压力会让人不得不把「做大」变成了目的，这就导致了：
● 简单的事情复杂化，增加使用者的理解成本（ Cognitive Load ）
● 能使用现有的技术，偏要自己再做一套。由于「做大 -> 晋升」是目的，这样的产品有很大的机率在达成了目的后被放弃。
● 做事态度变成「能用就行」，不关心用户体验。
这样的做事方式不适合我，也违背了我做技术的理念。
What’s next
我还没有一个很确切的计划，但我希望能去一个地方，定义我价值的不仅仅是因为我用了多牛逼的技术，做了一个多大的「平台」，而是我用技术的手段，给用户创造了什么他们觉得有价值的东西，如何改进了用户体验。又或者我用技术解决了哪些效率问题。
更具体的目标是成为 Tech Lead 的角色。同时我对 Growth Hacking 有很大的兴趣，希望可以结合技术和数据找出产品增长的瓶颈、把产品做得更好，帮助产品实现增长。
我会回到广东，离开杭州。
Conclusion
离职不是什么苦大仇深的事，我对阿里没有任何的怨念，阿里有很多很好的地方，只不过不属于这篇文章要讨论的范围。无论在哪个地方，我想要的都是和一群有想法的人一起打磨一个有价值的产品，而不是不同职能的团队都只做对自己 KPI 有利的事。每个公司都有其独特的生存法则，但这个生存法则也应该让那些务实和纯粹的人能很好地生存下去。也许这就是我作为一个技术人的理想主义吧。
via Randy's Blog
Invalid media: image
说说 React 和 Vue
争论框架是个无聊的事情，有一天在开车的时候我突然想到选框架和选车是一样的。
React 就像手动挡，Vue 就像自动挡。你不能因为你会开手动挡就看不起开自动挡的，我想正常的驾驶员在城市代步都会选择开自动挡。我只想代个步，为什么不把复杂的事情交给变速箱呢。
当你要下赛道，你可能要选择手动档。因为你相信你的人脑比变速箱要聪明得多。你需要由你自己的大脑控制最重要的事 —— 赛车里是速度，软件开发是性能。useMemo 或者shouldComponentUpdate 就是你车里面的那根档棍。
用手动档的没有必要看不起用自动档的，人家根本不在意这车能不能开到极速，只想安心开开车顺便摸摸副驾驶的大腿；用自动档的也没必要在路上看到别人开手动档的就骂别人傻逼，人家一个老司机开手动档多年，可能从心智上开手动档开得跟你开自动档一样轻松，自己也享受手动档的乐趣。也有可能是因为他想开的车只有手动档的 —— 比如他因为想用 Ant.Design 所以选了 React.
就像选择自动 GC 和手动 GC 的语言，作为一个成年人，应该知道什么是 trade-off.
作为专业的程序员，更重要的是知道你面对的是赛道还是公路，你的伙伴到底会不会开手动档。
最怕的是硬要让只会开自动档的人开手动档的车，轻则红绿灯起步死火被疯狂按喇叭，重则…
via Randy's Blog
争论框架是个无聊的事情，有一天在开车的时候我突然想到选框架和选车是一样的。
React 就像手动挡，Vue 就像自动挡。你不能因为你会开手动挡就看不起开自动挡的，我想正常的驾驶员在城市代步都会选择开自动挡。我只想代个步，为什么不把复杂的事情交给变速箱呢。
当你要下赛道，你可能要选择手动档。因为你相信你的人脑比变速箱要聪明得多。你需要由你自己的大脑控制最重要的事 —— 赛车里是速度，软件开发是性能。useMemo 或者shouldComponentUpdate 就是你车里面的那根档棍。
用手动档的没有必要看不起用自动档的，人家根本不在意这车能不能开到极速，只想安心开开车顺便摸摸副驾驶的大腿；用自动档的也没必要在路上看到别人开手动档的就骂别人傻逼，人家一个老司机开手动档多年，可能从心智上开手动档开得跟你开自动档一样轻松，自己也享受手动档的乐趣。也有可能是因为他想开的车只有手动档的 —— 比如他因为想用 Ant.Design 所以选了 React.
就像选择自动 GC 和手动 GC 的语言，作为一个成年人，应该知道什么是 trade-off.
作为专业的程序员，更重要的是知道你面对的是赛道还是公路，你的伙伴到底会不会开手动档。
最怕的是硬要让只会开自动档的人开手动档的车，轻则红绿灯起步死火被疯狂按喇叭，重则…
via Randy's Blog
好产品帮助用户变得更好 - 读 Badass: Making Users Awesome
如何让用户愿意花钱购买你的软件 / 服务 ？
如果你也在思考这个问题，那么你一定要读一读 Kathy Sierra 写的 Badass: Making Users Awesome (中文译作《 用户思维+ 好产品让用户为自己尖叫 》)
想象一下，有一天，你看到有人在网上写了一篇如何记账和理财的文章，读罢，备受鼓舞，文章的作者在里面提到了如何用一个 App 高效做记账，于是你买下了这个 App.
背后驱使你买这个 App 的原因是什么？是因为你觉得这个 App 很不错？不，是因为你想成为那个善于理财的人。
这就是这本书的观点 —— 用户购买你的产品，他在意的是用了你的产品，他成为了什么样的人。所以，如何打造一个可以持续获得用户的产品，秘诀在于如何让用户通过你的产品成为他想成为的人。
这个观点让我耳目一新，我可以从自己或者从别人的购买行为看出这样的本质。我忽然发现，以往在思考如何打造一个用户觉得有价值的产品，我太专注在思考工具本身的功能应该怎么做，完全忽略了我的产品如何帮助我的目标用户变得更好。
例如，我总是在想着做一个博客平台，读完 Kathy 的这本书，我发现，我太过于思考从功能上，我要提供给用户什么。我想，我要提供 Podcast 托管，我要提供最快的 CDN, 我要支持自定义域名。但是，整个互联网，博客平台已经有很多，这些功能，别的平台可以提供。用户为什么选择我？
读完这本书，我会这样去思考：我如果做一个新的博客平台，用户可以因为我的平台，成为一个什么样的人？这样一来，问题就变成了：我的博客平台如何让用户成为一个优秀的独立博客主？我的博客平台如何让用户成为一个成功的 Podcast 节目主？
我们总是提供工具，但是往往忽略了如何让用户用好我们的工具，使他们变得 Awesome.
让用户用好我们的工具，是零经济成本但最有效的宣传工具。因为这一些 Badass User (通俗来说就是「玩得溜」的那些用户，我姑且称为「用家」)，他们自己会帮你宣传。
当一个玩摄影的朋友告诉你，「这个镜头太牛逼了，你看我用它拍的这些照片，太好看了。」你可能会对这个镜头心动，晚上就回家搜一搜这个镜头，然后下单。
这位朋友嘴上说的是「这个 xx 太牛逼了，我用它 xxx」，事实上他想表达的是「我太牛逼了，我用它 xxx」。
只要你帮助你的用户通过你的产品变得更「牛逼」，就会有越来越多这些「用家」帮你宣传，就会有更多人购买你的产品，希望自己变得「牛逼」。也就是常说的「种草」。
然而他们宣传的方式不一定是直接跟身边的人说这个工具有多好，而是自己如何使用这个工具，做出了什么样的事。如果你有关注「少数派」这个媒体，少数派是这种案例的典型。你会发现上面几乎所有的文章，比如关于 Ulysses 这个 App 的文章，这些作者不会单纯去写这个工具怎么样，而是：
● 《为什么我选择用 Ulysses 写了一本小说》（我如何用 Ulysses 写了一本小说）
● 《搭建 Ulysses 学术写作之公式输入》（我如何用 Ulysses 学术写作）
越来越多的人会因为看到这些分享，希望自己可以用 Ulysses 也成为像他们这样成为一个写作者。
简单地来说，就是想一想，你的产品如何让你的用户在和朋友聊天的时候体现自己的 Awesome.
这本书也提到了在帮助用户成为「用家」的过程中遇到的问题以及解法，还从如果成为某个领域的专家作了一些科学上的分析（但我觉得这一部分的知识可以通过读 Atomic Habits 学到更多）。
我知道这本书是在翻 Egghead.io 的创始人 John Lindquist 的这条 Retweet无意中看到的，我觉得一定是本很好的书，他才会给每一个 Egghead 讲师送这本书。
我早在读 Egghead 的讲师指南的时候就发现 Egghead 会直接给每个讲师一套完整的录音设备（因为做 screencast 录音质量很重要）。我当时震惊于 Egghead 的阔绰。读完这本书，我就明白，即使需要成本，一套好的录音设备可以让这些用户（讲师）录制高质量的 screencast. 创始人就在践行这本书的理念。
注：本书的作者 Kathy Sierra 也是 Head First Java 的作者。
● 《 用户思维+ 好产品让用户为自己尖叫 》购买链接
via Randy's Blog
如何让用户愿意花钱购买你的软件 / 服务 ？
如果你也在思考这个问题，那么你一定要读一读 Kathy Sierra 写的 Badass: Making Users Awesome (中文译作《 用户思维+ 好产品让用户为自己尖叫 》)
想象一下，有一天，你看到有人在网上写了一篇如何记账和理财的文章，读罢，备受鼓舞，文章的作者在里面提到了如何用一个 App 高效做记账，于是你买下了这个 App.
背后驱使你买这个 App 的原因是什么？是因为你觉得这个 App 很不错？不，是因为你想成为那个善于理财的人。
这就是这本书的观点 —— 用户购买你的产品，他在意的是用了你的产品，他成为了什么样的人。所以，如何打造一个可以持续获得用户的产品，秘诀在于如何让用户通过你的产品成为他想成为的人。
这个观点让我耳目一新，我可以从自己或者从别人的购买行为看出这样的本质。我忽然发现，以往在思考如何打造一个用户觉得有价值的产品，我太专注在思考工具本身的功能应该怎么做，完全忽略了我的产品如何帮助我的目标用户变得更好。
例如，我总是在想着做一个博客平台，读完 Kathy 的这本书，我发现，我太过于思考从功能上，我要提供给用户什么。我想，我要提供 Podcast 托管，我要提供最快的 CDN, 我要支持自定义域名。但是，整个互联网，博客平台已经有很多，这些功能，别的平台可以提供。用户为什么选择我？
读完这本书，我会这样去思考：我如果做一个新的博客平台，用户可以因为我的平台，成为一个什么样的人？这样一来，问题就变成了：我的博客平台如何让用户成为一个优秀的独立博客主？我的博客平台如何让用户成为一个成功的 Podcast 节目主？
我们总是提供工具，但是往往忽略了如何让用户用好我们的工具，使他们变得 Awesome.
让用户用好我们的工具，是零经济成本但最有效的宣传工具。因为这一些 Badass User (通俗来说就是「玩得溜」的那些用户，我姑且称为「用家」)，他们自己会帮你宣传。
当一个玩摄影的朋友告诉你，「这个镜头太牛逼了，你看我用它拍的这些照片，太好看了。」你可能会对这个镜头心动，晚上就回家搜一搜这个镜头，然后下单。
这位朋友嘴上说的是「这个 xx 太牛逼了，我用它 xxx」，事实上他想表达的是「我太牛逼了，我用它 xxx」。
只要你帮助你的用户通过你的产品变得更「牛逼」，就会有越来越多这些「用家」帮你宣传，就会有更多人购买你的产品，希望自己变得「牛逼」。也就是常说的「种草」。
然而他们宣传的方式不一定是直接跟身边的人说这个工具有多好，而是自己如何使用这个工具，做出了什么样的事。如果你有关注「少数派」这个媒体，少数派是这种案例的典型。你会发现上面几乎所有的文章，比如关于 Ulysses 这个 App 的文章，这些作者不会单纯去写这个工具怎么样，而是：
● 《为什么我选择用 Ulysses 写了一本小说》（我如何用 Ulysses 写了一本小说）
● 《搭建 Ulysses 学术写作之公式输入》（我如何用 Ulysses 学术写作）
越来越多的人会因为看到这些分享，希望自己可以用 Ulysses 也成为像他们这样成为一个写作者。
简单地来说，就是想一想，你的产品如何让你的用户在和朋友聊天的时候体现自己的 Awesome.
这本书也提到了在帮助用户成为「用家」的过程中遇到的问题以及解法，还从如果成为某个领域的专家作了一些科学上的分析（但我觉得这一部分的知识可以通过读 Atomic Habits 学到更多）。
我知道这本书是在翻 Egghead.io 的创始人 John Lindquist 的这条 Retweet无意中看到的，我觉得一定是本很好的书，他才会给每一个 Egghead 讲师送这本书。
我早在读 Egghead 的讲师指南的时候就发现 Egghead 会直接给每个讲师一套完整的录音设备（因为做 screencast 录音质量很重要）。我当时震惊于 Egghead 的阔绰。读完这本书，我就明白，即使需要成本，一套好的录音设备可以让这些用户（讲师）录制高质量的 screencast. 创始人就在践行这本书的理念。
注：本书的作者 Kathy Sierra 也是 Head First Java 的作者。
● 《 用户思维+ 好产品让用户为自己尖叫 》购买链接
via Randy's Blog
从「后端现在已经看不懂前端了」说起
V2EX 这两天有一篇这样的帖子：《说句实话，我后端现在已经看不懂前端了，太难了》
原文内容是：
对于那些抱怨前端「看不懂」的网友，我们应该问他们一个问题：为什么前端就应该是谁都能看懂？
这些网友从来不会抱怨别的领域的代码看不懂，比如他们不会说「我一个前端已经看不懂后端了」，或者「我一个后端已经看不懂 iOS」了。
所以在这些网友心中，前端代码就是要谁都看得懂才是正常的。因为谁都应该看得懂 HTML, 谁都看得懂 CSS.
显然，这群人对前端的认知还活在过去，他们一边享受着用 Web 技术做出来应用，一边意淫着这些包含复杂业务逻辑的 Web 应用靠 HTML 和 Vanilla JS (原生 JS) 就能写成。
换句话说，这群人最大的问题在于，他们意识不到 GUI 开发 (Graphic User Interface Programming) 是一个从图形界面被发明开始就一直在被研究的独立领域，而 Web 前端只是 GUI 开发的其中一个分支而已。
这群人没有意识到到底什么是「前端」。前端就是写 HTML / JavaScript / CSS 吗？不，前端应该泛指那些需要编写 GUI 的技术。在我看来，写 iOS / Android 应用和写 Web 前端没有本质上的区别，区别只是语言和平台，背后处理的问题是一模一样的：如何实现视觉和交互 -> 交互如何触发逻辑 -> 逻辑如何影响视觉的变化。
所以，如果认为浏览器识别的是 HTML 所以认为前端应该谁都能看懂、门槛低，进而得出前端目前的工作流是问题复杂化的结果，就如同因为 Android 的 UI 是用 XML 写的就认为 Android 门槛低一样不成立得可笑。
对 GUI 开发难点的不了解是导致这种误解的最主要原因，以网友「 avastms 」提出的评论为典型：
但是，这位网友大概更愿意读这样的代码：
觉得这样的写法恶心，多数是因为不知道 JSX 这个语法糖的背后是什么。
事实上没有人阻止任何人不用 JSX, 或者看看 Flutter 就大概知道没有 JSX 的 React 会是什么样子。
作为补充，这是希望 Flutter 引入 JSX 的相关讨论：Consider JSX-like as React Native · Issue #15922 · flutter/flutter · GitHub
至于提到的 Redux 和 Vuex, 证明这位网友根本不知道 EventEmitter 和 Reactive 的区别。这里就不展开讨论了。
为什么我们宁愿用 JSX 这种折中方案也不愿意放弃函数式编程，是因为声明式(Declarative) 是编写 GUI 最好的方法。复杂的 GUI 应用包含复杂的状态，人脑在处理复杂的状态绝对不比计算机在行，我们尽可能地把这些状态交给计算机做，函数式编程就是我们实现这个目标的工具。
Elm 的作者写过一篇名叫 Concurrent FRP 的论文，讲述了函数式响应式编程 (Functional Reactive Programming) 在 GUI 开发中的历史背景和应用。
那些喜欢说「jQuery 一把梭」的网友，要么遇到的业务很简单，要么是在自虐。我见过写外挂用易语言一把梭的，但没听说过 Adobe 写 PhotoShop 用 Visual Basic 一把梭。
有些人，能接受 Maven, Gradle 的不完美，也知道什么场景应该用什么技术栈，但一旦开始写点前端代码，就认为应该有一个神一样的、完美的、还没有学习成本的构建工具，然后 Twitter, V2EX 抱怨一番，却不愿意认真学一学前端这个领域的知识。
不要妄想有一个睡醒就突然会用的构建工具。说实话，Webpack 不需要任何配置就能用，再不行试试号称 zero configuration (零配置) 的 Parcel, 用 TypeScript, 引入 CSS / LESS / SASS 通通不需要配置，跑起来就行。但那又如何呢，那些不愿意学习又想出活的网友们不懂的不是运行
一个人要锤子锤个钉子，结果大家都说雷神的锤子很牛逼。这个人听了，上来就要用雷神的锤子，结果拿都拿不起来。然后网上发个贴：「根本不懂为什么雷神要搞个这么重的锤子，给爷整蒙了都」。底下评论：「我工具锤一把梭！」楼下再附和：「雷神搞这个锤就是为了装逼」。
希望各位把抱怨转化成求知，没有一个领域是不需要学习成本的，不管是做技术还是技术以外的领域，是分工和市场经济让各位觉得一切理所当然，然而像磨刀这样看上去简单的动作，也不是每个人都能磨好一把刀。
via Randy's Blog
V2EX 这两天有一篇这样的帖子：《说句实话，我后端现在已经看不懂前端了，太难了》
原文内容是：
看不懂惹，肿么办，最近在学 react，完全抓瞎。然后又附加了内容：
一直用的 jquery，手动找位置然后对应 dom 操作，现在各种前端各种依赖，一会 route 一会 webpack 的 给爷整蒙了都。类似这样的帖子多年来数不胜数，但这次评论区的评论比较典型，所以我决定这次不再沉默。当然，本文并非针对帖子作者。
对于那些抱怨前端「看不懂」的网友，我们应该问他们一个问题：为什么前端就应该是谁都能看懂？
这些网友从来不会抱怨别的领域的代码看不懂，比如他们不会说「我一个前端已经看不懂后端了」，或者「我一个后端已经看不懂 iOS」了。
所以在这些网友心中，前端代码就是要谁都看得懂才是正常的。因为谁都应该看得懂 HTML, 谁都看得懂 CSS.
显然，这群人对前端的认知还活在过去，他们一边享受着用 Web 技术做出来应用，一边意淫着这些包含复杂业务逻辑的 Web 应用靠 HTML 和 Vanilla JS (原生 JS) 就能写成。
换句话说，这群人最大的问题在于，他们意识不到 GUI 开发 (Graphic User Interface Programming) 是一个从图形界面被发明开始就一直在被研究的独立领域，而 Web 前端只是 GUI 开发的其中一个分支而已。
这群人没有意识到到底什么是「前端」。前端就是写 HTML / JavaScript / CSS 吗？不，前端应该泛指那些需要编写 GUI 的技术。在我看来，写 iOS / Android 应用和写 Web 前端没有本质上的区别，区别只是语言和平台，背后处理的问题是一模一样的：如何实现视觉和交互 -> 交互如何触发逻辑 -> 逻辑如何影响视觉的变化。
所以，如果认为浏览器识别的是 HTML 所以认为前端应该谁都能看懂、门槛低，进而得出前端目前的工作流是问题复杂化的结果，就如同因为 Android 的 UI 是用 XML 写的就认为 Android 门槛低一样不成立得可笑。
对 GUI 开发难点的不了解是导致这种误解的最主要原因，以网友「 avastms 」提出的评论为典型：
他说：「模板混代码里这种 PHP 宗教行为就别提了」，想必他在说 JSX. JSX 刚开始出来就充满争议，但人们最终会发现，JSX 是函数式 GUI 开发最易读写的方案。实际上，他完全可以选择不使用 JSX，这样去写代码：
这是前端圈长期逆淘汰的结果。
模板混代码里这种 PHP 宗教行为就别提了。
个人认为因为 javascript 语言的部分原因，前端很少有人懂什么是继承，什么是类，实例到底啥意思，更别谈良好维护引用了。
什么 redux,什么 vuex 根本就是莫名其妙，不就是事件监听吗，像 Node.js 那样 EventEmitter 多么清晰，非得自己造概念。
画虎不成反类犬，凡是有这套什么状态管理逻辑的，代码完全不可读。
前端自己也是不争气，不用别人的这些狗概念，自己就不会写代码了吗？
没有什么 redux，自己就不会管理自己的属性了吗？
const Component = h(‘div’, null, [h(‘p’, null, ‘hello world’), h(‘p’, null, ‘I am Randy’)])
但是，这位网友大概更愿意读这样的代码：
const Component = (
<div>
<p>hello world</p>
<p>I am Randy</p>
</div>
)
觉得这样的写法恶心，多数是因为不知道 JSX 这个语法糖的背后是什么。
事实上没有人阻止任何人不用 JSX, 或者看看 Flutter 就大概知道没有 JSX 的 React 会是什么样子。
作为补充，这是希望 Flutter 引入 JSX 的相关讨论：Consider JSX-like as React Native · Issue #15922 · flutter/flutter · GitHub
至于提到的 Redux 和 Vuex, 证明这位网友根本不知道 EventEmitter 和 Reactive 的区别。这里就不展开讨论了。
为什么我们宁愿用 JSX 这种折中方案也不愿意放弃函数式编程，是因为声明式(Declarative) 是编写 GUI 最好的方法。复杂的 GUI 应用包含复杂的状态，人脑在处理复杂的状态绝对不比计算机在行，我们尽可能地把这些状态交给计算机做，函数式编程就是我们实现这个目标的工具。
Elm 的作者写过一篇名叫 Concurrent FRP 的论文，讲述了函数式响应式编程 (Functional Reactive Programming) 在 GUI 开发中的历史背景和应用。
那些喜欢说「jQuery 一把梭」的网友，要么遇到的业务很简单，要么是在自虐。我见过写外挂用易语言一把梭的，但没听说过 Adobe 写 PhotoShop 用 Visual Basic 一把梭。
有些人，能接受 Maven, Gradle 的不完美，也知道什么场景应该用什么技术栈，但一旦开始写点前端代码，就认为应该有一个神一样的、完美的、还没有学习成本的构建工具，然后 Twitter, V2EX 抱怨一番，却不愿意认真学一学前端这个领域的知识。
不要妄想有一个睡醒就突然会用的构建工具。说实话，Webpack 不需要任何配置就能用，再不行试试号称 zero configuration (零配置) 的 Parcel, 用 TypeScript, 引入 CSS / LESS / SASS 通通不需要配置，跑起来就行。但那又如何呢，那些不愿意学习又想出活的网友们不懂的不是运行
webpack dev 这个命令，而是根本不懂这个命令背后解决的是什么问题。一个人要锤子锤个钉子，结果大家都说雷神的锤子很牛逼。这个人听了，上来就要用雷神的锤子，结果拿都拿不起来。然后网上发个贴：「根本不懂为什么雷神要搞个这么重的锤子，给爷整蒙了都」。底下评论：「我工具锤一把梭！」楼下再附和：「雷神搞这个锤就是为了装逼」。
希望各位把抱怨转化成求知，没有一个领域是不需要学习成本的，不管是做技术还是技术以外的领域，是分工和市场经济让各位觉得一切理所当然，然而像磨刀这样看上去简单的动作，也不是每个人都能磨好一把刀。
via Randy's Blog
2019 年终总结：慢慢变成别人眼中「食古不化」的「怪人」
总结
2019 年 3 月我来到杭州，在蚂蚁金服开始了新的工作。这是我第一次在广东省外的地方生活。
新的环境，新的工作，对我来说是一个很大的挑战。挑战不在于如何适应一个新的环境，而在于在一个技术基建完备的环境里，如果业务难关不是技术可以解决的，那我的价值在哪里？在这个方面，我让很多对我抱有期望的人失望了。
「我的价值是什么」是我不断寻找答案的命题，我不满足只作为一个消费者活在世上。只有作为生产者创造自己独特的价值，才让我觉得自己是这个世界的一员。
我创造了很多，但好像只有写博客算是对别人来说稍微有价值的东西。现代的人又不怎么喜欢认真地看文字了，写好一篇文章的阅读量也不比同样内容的一个视频高。就连我一个关注了很久的独立博客博主，也转了型做视频。
「写博客」似乎已经是一件看上去「食古不化」的事，而我竟然越来越「食古不化」了。有时候到一家餐厅，被告知没有餐牌，只能扫码点餐，我会反问，「如果我没有手机呢？」。
我想，如果旁边正好有一位比我年轻十岁的客人听到我这样问，他心中也许会暗想，「x, 这个食古不化的傻x」。
今年下半年我又因为不能忍受国内社交网络的反智内容和评论，微信和微博都变成了只写的状态，除非收到消息，微信几乎不怎么打开。此举极大地改善了我的心理健康。但在别人眼里，就是一个不合群的怪人。
告别 2019，我就 25 岁了。这是一个不算年轻，也不算不年轻的岁数。如果开始「食古不化」是变老的征兆，那么我已经开始变老了。但如果不懒惰、不犬儒、不圆滑、不反智就是年轻，那么我将会永远年轻下去。
音乐
今年做了 6 首翻唱，上传在 YouTube 和 Bilibili:
播放量最高的是《奉献》和《黄昏》。
阅读
今年读的书里有以下几本想推荐给大家：
《学会提问：批判式思维指南》（豆瓣 | 购买）
《非暴力沟通》（豆瓣 | 购买）
《颓废与沉默》（豆瓣 | 购买）
消费
● Kindle Oasis ( 购买 ) 替换了我的 Kindle Paperwhite. 手感很好，放裤袋很轻松。是我今年买得最值的产品。
● 黑卡 3 ( 购买 ) 替换了我的黑卡 1, 有可以旋转的屏幕，自己拍视频的时候轻松多了。
● iPad Pro ( 我的评测 ) 替换了我的 iPad mini 2. 主要用来看微信读书，睡前浏览各个咨询网站。最后悔是没有买蜂窝版。
每天都看的内容
● V2EX
● Hacker News
● 端传媒
● Podcast (睡前听)
● Feedly (只订阅一些独立博客)
● YouTube
● Twitter
● Instagram
放空的时候看的内容
● 少数派
● 数字尾巴
关于 2020
创造更多价值吧。
via Randy's Blog
Invalid media:
image
image
总结
2019 年 3 月我来到杭州，在蚂蚁金服开始了新的工作。这是我第一次在广东省外的地方生活。
新的环境，新的工作，对我来说是一个很大的挑战。挑战不在于如何适应一个新的环境，而在于在一个技术基建完备的环境里，如果业务难关不是技术可以解决的，那我的价值在哪里？在这个方面，我让很多对我抱有期望的人失望了。
「我的价值是什么」是我不断寻找答案的命题，我不满足只作为一个消费者活在世上。只有作为生产者创造自己独特的价值，才让我觉得自己是这个世界的一员。
我创造了很多，但好像只有写博客算是对别人来说稍微有价值的东西。现代的人又不怎么喜欢认真地看文字了，写好一篇文章的阅读量也不比同样内容的一个视频高。就连我一个关注了很久的独立博客博主，也转了型做视频。
「写博客」似乎已经是一件看上去「食古不化」的事，而我竟然越来越「食古不化」了。有时候到一家餐厅，被告知没有餐牌，只能扫码点餐，我会反问，「如果我没有手机呢？」。
我想，如果旁边正好有一位比我年轻十岁的客人听到我这样问，他心中也许会暗想，「x, 这个食古不化的傻x」。
今年下半年我又因为不能忍受国内社交网络的反智内容和评论，微信和微博都变成了只写的状态，除非收到消息，微信几乎不怎么打开。此举极大地改善了我的心理健康。但在别人眼里，就是一个不合群的怪人。
告别 2019，我就 25 岁了。这是一个不算年轻，也不算不年轻的岁数。如果开始「食古不化」是变老的征兆，那么我已经开始变老了。但如果不懒惰、不犬儒、不圆滑、不反智就是年轻，那么我将会永远年轻下去。
音乐
今年做了 6 首翻唱，上传在 YouTube 和 Bilibili:
播放量最高的是《奉献》和《黄昏》。
阅读
今年读的书里有以下几本想推荐给大家：
《学会提问：批判式思维指南》（豆瓣 | 购买）
《非暴力沟通》（豆瓣 | 购买）
《颓废与沉默》（豆瓣 | 购买）
消费
● Kindle Oasis ( 购买 ) 替换了我的 Kindle Paperwhite. 手感很好，放裤袋很轻松。是我今年买得最值的产品。
● 黑卡 3 ( 购买 ) 替换了我的黑卡 1, 有可以旋转的屏幕，自己拍视频的时候轻松多了。
● iPad Pro ( 我的评测 ) 替换了我的 iPad mini 2. 主要用来看微信读书，睡前浏览各个咨询网站。最后悔是没有买蜂窝版。
每天都看的内容
● V2EX
● Hacker News
● 端传媒
● Podcast (睡前听)
● Feedly (只订阅一些独立博客)
● YouTube
放空的时候看的内容
● 少数派
● 数字尾巴
关于 2020
创造更多价值吧。
via Randy's Blog
Invalid media:
image
image
为了你爱的人，读一读《非暴力沟通》
我和父母的关系很糟糕，在小时候，我们之间的「交互」方式大部分是命令、教训，严重的时候甚至打一顿。我很讨厌被命令去做家务。
成年以后，即使脱离了原生家庭，但无论是工作伙伴之间的合作，还是处理亲密关系，都偶尔会出现矛盾，形成无效的沟通，甚至产生情绪。
很幸运我读到了《非暴力沟通》这本书，让我发现我在日常接触到的沟通中，多少隐藏着无形的暴力。
全书围绕非暴力沟通的四个要素进行讲解：观察、感受、需要、请求。如果沟通没有这些要素，那么这些沟通最终的结果很可能是情绪化的收场，又或者成为了压死骆驼前的每一根稻草，总有一天爆发。
在一段亲密关系中，我们很容易听到或自己说到过这样的话：「你怎么每次都这样」。这样的一句话，很容易使对方产生抵触情绪，导致情绪化的争吵。因为这句话也只是单纯的情绪发泄和评价，不能指望用这样情绪化的沟通去解决实际存在的问题。它缺少了非暴力沟通的四个要素。
如果读完《非暴力沟通》，你可能再也不会说出「你怎么每次都这样」这样的话。你会先说出你的观察：在这个月，你已经是第 3 次这样做了。然后说出你的感受：我觉得你这样做让我觉得你不是一个靠谱的人。再说出你的需要： 我想要一个靠谱的另一半而不是这样的人。最后说出你的请求：你可以不再这样了吗？
很多人没有区分「观察」和「评论」，像有人常说「那个产品经理真是个脑残」，这是一种评论。评论对于沟通是没有帮助的，他只会让别人厌恶，抵触。我们应该说出具体的观察：那个产品经理做的大部分需求都会改很多次，而且功能上线后用户基本都是负面反馈。
我们也常常忽略、或者故意隐藏了自己的感受和需要。在沟通中，让对方清楚自己的感受和需要是很重要的。最常见的就是在亲密关系当中，一方总会把自己的感受和需要埋在心中自己消化，另一方事实上并不知道对方的感受，潜移默化就造成了关系破裂的危机。
但如果不说出感受和需要，直接说出请求，就会像一种命令。例如我小时候母亲让我做家务的时候，对我只有一句话：「快去做清洁！」。对我来说是一种不得不服从的命令，服从只是因为她是我母亲，而不是她的感受和她的需要，会让我十分抵触。
除了非暴力沟通的四个要素，书里最后也提到了充分表达感激的重要性。对别人表达感激也有三个要素：说出对我们有益的行为；我们哪些需要得到了满足；我们是什么样的心情。
这就是为什么对于我来说，比起别人说「你真牛逼」，我更愿意看到博客读者来信告诉我，我的哪篇文章的哪一个点，让他得到了什么样的启发。
有一次我在看 React Conf, 很喜欢其中一位讲师，在 Twitter 上提到了他，他说「That means a lot to me」, 我意识到，不能吝啬表达自己的感激。
我想，如果在我的成长环境中，我的父母也掌握了非暴力沟通的技巧，我们彼次都懂得表达彼此的观察、感受和需要。也许不至于让我对原生家庭有那么多负面的情绪。
所以，为了你爱的人，应该读一读《非暴力沟通》。
via Randy's Blog
Invalid media: image
我和父母的关系很糟糕，在小时候，我们之间的「交互」方式大部分是命令、教训，严重的时候甚至打一顿。我很讨厌被命令去做家务。
成年以后，即使脱离了原生家庭，但无论是工作伙伴之间的合作，还是处理亲密关系，都偶尔会出现矛盾，形成无效的沟通，甚至产生情绪。
很幸运我读到了《非暴力沟通》这本书，让我发现我在日常接触到的沟通中，多少隐藏着无形的暴力。
全书围绕非暴力沟通的四个要素进行讲解：观察、感受、需要、请求。如果沟通没有这些要素，那么这些沟通最终的结果很可能是情绪化的收场，又或者成为了压死骆驼前的每一根稻草，总有一天爆发。
在一段亲密关系中，我们很容易听到或自己说到过这样的话：「你怎么每次都这样」。这样的一句话，很容易使对方产生抵触情绪，导致情绪化的争吵。因为这句话也只是单纯的情绪发泄和评价，不能指望用这样情绪化的沟通去解决实际存在的问题。它缺少了非暴力沟通的四个要素。
如果读完《非暴力沟通》，你可能再也不会说出「你怎么每次都这样」这样的话。你会先说出你的观察：在这个月，你已经是第 3 次这样做了。然后说出你的感受：我觉得你这样做让我觉得你不是一个靠谱的人。再说出你的需要： 我想要一个靠谱的另一半而不是这样的人。最后说出你的请求：你可以不再这样了吗？
很多人没有区分「观察」和「评论」，像有人常说「那个产品经理真是个脑残」，这是一种评论。评论对于沟通是没有帮助的，他只会让别人厌恶，抵触。我们应该说出具体的观察：那个产品经理做的大部分需求都会改很多次，而且功能上线后用户基本都是负面反馈。
我们也常常忽略、或者故意隐藏了自己的感受和需要。在沟通中，让对方清楚自己的感受和需要是很重要的。最常见的就是在亲密关系当中，一方总会把自己的感受和需要埋在心中自己消化，另一方事实上并不知道对方的感受，潜移默化就造成了关系破裂的危机。
暴力的根源在于人们忽视彼此的感受与需要，而将冲突归咎于对方。非暴力沟通的第四个要素：请求，也很重要。对方即使清楚你的感受和需要，但不一定知道应该怎么做。恋爱中，一方需要陪伴，那么应该直接说出具体的请求：工作日每晚至少花两个小时在一起。
我们将自己想要的回应讲得越清楚，就越有可能得到理想的回应。在工作中「请求」同样重要。如果在会议中，发言的人在最后不明确说出想要得到与会人员怎么样的反应，只问大家「有什么想说的」，那很可能大家就没有什么想说的。但如果明确地问：「对于这个方案，大家有没有想到可能存在的缺点？」，那么就更有可能得到你想要的回应。
但如果不说出感受和需要，直接说出请求，就会像一种命令。例如我小时候母亲让我做家务的时候，对我只有一句话：「快去做清洁！」。对我来说是一种不得不服从的命令，服从只是因为她是我母亲，而不是她的感受和她的需要，会让我十分抵触。
除了非暴力沟通的四个要素，书里最后也提到了充分表达感激的重要性。对别人表达感激也有三个要素：说出对我们有益的行为；我们哪些需要得到了满足；我们是什么样的心情。
这就是为什么对于我来说，比起别人说「你真牛逼」，我更愿意看到博客读者来信告诉我，我的哪篇文章的哪一个点，让他得到了什么样的启发。
有一次我在看 React Conf, 很喜欢其中一位讲师，在 Twitter 上提到了他，他说「That means a lot to me」, 我意识到，不能吝啬表达自己的感激。
我想，如果在我的成长环境中，我的父母也掌握了非暴力沟通的技巧，我们彼次都懂得表达彼此的观察、感受和需要。也许不至于让我对原生家庭有那么多负面的情绪。
所以，为了你爱的人，应该读一读《非暴力沟通》。
via Randy's Blog
Invalid media: image
来自 2014 年给未来的我的一封信
这是一封 2014 年我写给未来的自己的信。当时在上大一，是上职业规划课时老师布置给我们的一个作业，写完我们就交给老师保存，他会在我们大学毕业后返还。
老师通过微信联系我说有封信在他那里，并拍了这张照片（图为我用 Office Lens 处理后）。我早已忘掉我曾写过这封信，看完后我就全记起来了。
记起来刚上大学时对未知的憧憬，记起来在教室听无聊的网页设计课，记起来退学那天给宿舍阿姨还了钥匙后坐上中巴回广州市区的时候听的那首《一路向北》。
via Randy's Blog
Invalid media: image
这是一封 2014 年我写给未来的自己的信。当时在上大一，是上职业规划课时老师布置给我们的一个作业，写完我们就交给老师保存，他会在我们大学毕业后返还。
老师通过微信联系我说有封信在他那里，并拍了这张照片（图为我用 Office Lens 处理后）。我早已忘掉我曾写过这封信，看完后我就全记起来了。
记起来刚上大学时对未知的憧憬，记起来在教室听无聊的网页设计课，记起来退学那天给宿舍阿姨还了钥匙后坐上中巴回广州市区的时候听的那首《一路向北》。
via Randy's Blog
Invalid media: image
为什么无法坚持写博客
如果你被本文的标题吸引，那么你应该已经试过很多次雄心勃勃地开始选择你喜欢的静态网站生成器 (Static Site Generator), 然后精心挑选或者自行手写一个你钟意的主题，写下一篇题为 “Hello World” 的博客，宣称从今天起重新开始写博客。几个月后就再也不更新了。
为什么你总是无法坚持写博客？和很多「为什么无法坚持做某事」的问题一样，我们得先弄清楚为什么要写博客。
我听过很多人想建博客的理由是想把博客当成笔记本，记录自己学到的东西、遇到的问题和解决方法。这是一个让博客最终走向荒废的理由，因为你在笔记本就可以做到类似的事，除非你记录的问题有你自己独到的思考，否则网友们更愿意去看 StackOverflow.
写博客的第一个意义是让陌生人通过博客了解到你是什么人、你在想什么、你做了什么。不妨试想一下，如果你正准备找工作，一位素不相识的 HR 如果要了解你，光是一份简历就能让 HR 知道你的价值吗？如果你有一个精彩的博客，HR 也许能通过你的博客了解你对技术的属于自己的思考、你在业余时间在想的事情是什么。这比简历本身更像一份立体的简历。
以下是一些你可以选择的题材：
● 你对某个技术的看法
● 你读了某本书的书评
● 你职业之外的一些生活感悟和记录
● 你的对于生活、职业的哲学思考
这些题材的共同点是它们都是属于你的独特的内容。
当然，这一切的前提是你本身需要有一定的表达欲，你才会想不断地去写博客。博客只是其中一个表达渠道。我自己是一个很有表达欲的人，我乐意分享我的想法，我的生活。然而，试图通过建立博客去培养表达欲不是一个行之有效的方法，这就像很多本身不喜欢读书的人试图通过 Kindle 培养自己的读书习惯，大多数都是失败收场。你应该是因为喜欢读书所以买 Kindle, 正如你应该是想表达你的东西所以你写博客。
不是每个人都有表达欲，但很多有表达欲的人不敢表达，因为在担心一些不应该担心的问题。
文章没有深度
除非你的博客的定位就是追求思想深度，否则不必苛求每篇文章都有所谓的深度，有时候即使是日常生活的小记也有其价值，读者能从中发现很多自己不知道的东西。例如 JustZht 的 一些生活小记 .
记得多年前我刚开始写博客的时候知道了罗磊和 罗磊的博客。虽然当时罗磊是一个前端工程师，但博客大多数文章都不是技术，而是一些数码产品和生活方式，例如 他跑马拉松的记录。
这些内容没有所谓的「深度」，但让我看到了不同的生活方式。每个人都有自己独特的生活方式，不妨把它分享出来让更多人从中获得借鉴。
文章写不长
并非写长文章才叫写博客，李如一的 一天世界 也不见得每篇文章的篇幅都长，但内容有其独特的思维方式，也能引发思考。这就够了。
没什么人看
写独立博客和写公众号不同，你不必追求「十万加」。你要追求的是一个陌生人只要进入一个网站就能知道你是什么人。你不靠写博客吃饭。人们总说 You are what you read, 当人们无法得知你在读什么的情况下，那么我更要说： You are what you write.
文章写完，分享给你喜欢的圈子，论坛，回复一些评论。慢慢地就会在你的圈子积累一些读者。
做不到一直更新
JerryQu 的博客 已经两年没有更新，但两年后的现在依然可以说这是一个很好的博客。
你的博客不是资讯网站，不必在意更新频率。
希望本文可以引导各位潜在的博客作者决心建立自己的独立博客。独立博客有免于献媚的自由，有排版自由，有修改删除自己说了算的自由。维护一个有意义的博客不是一件难事，用现成的平台或用框架，在网站主页写上你的个人简介，然后保有分享生活和想法的习惯，不限篇幅，不限频率（即使是一年一篇），按时续费域名，保持网站正常访问，
记住，一个博客的死掉不是不再更新，而是无法访问。
延伸链接
● 中文独立博客列表
via Randy's Blog
如果你被本文的标题吸引，那么你应该已经试过很多次雄心勃勃地开始选择你喜欢的静态网站生成器 (Static Site Generator), 然后精心挑选或者自行手写一个你钟意的主题，写下一篇题为 “Hello World” 的博客，宣称从今天起重新开始写博客。几个月后就再也不更新了。
为什么你总是无法坚持写博客？和很多「为什么无法坚持做某事」的问题一样，我们得先弄清楚为什么要写博客。
我听过很多人想建博客的理由是想把博客当成笔记本，记录自己学到的东西、遇到的问题和解决方法。这是一个让博客最终走向荒废的理由，因为你在笔记本就可以做到类似的事，除非你记录的问题有你自己独到的思考，否则网友们更愿意去看 StackOverflow.
写博客的第一个意义是让陌生人通过博客了解到你是什么人、你在想什么、你做了什么。不妨试想一下，如果你正准备找工作，一位素不相识的 HR 如果要了解你，光是一份简历就能让 HR 知道你的价值吗？如果你有一个精彩的博客，HR 也许能通过你的博客了解你对技术的属于自己的思考、你在业余时间在想的事情是什么。这比简历本身更像一份立体的简历。
以下是一些你可以选择的题材：
● 你对某个技术的看法
● 你读了某本书的书评
● 你职业之外的一些生活感悟和记录
● 你的对于生活、职业的哲学思考
这些题材的共同点是它们都是属于你的独特的内容。
当然，这一切的前提是你本身需要有一定的表达欲，你才会想不断地去写博客。博客只是其中一个表达渠道。我自己是一个很有表达欲的人，我乐意分享我的想法，我的生活。然而，试图通过建立博客去培养表达欲不是一个行之有效的方法，这就像很多本身不喜欢读书的人试图通过 Kindle 培养自己的读书习惯，大多数都是失败收场。你应该是因为喜欢读书所以买 Kindle, 正如你应该是想表达你的东西所以你写博客。
不是每个人都有表达欲，但很多有表达欲的人不敢表达，因为在担心一些不应该担心的问题。
文章没有深度
除非你的博客的定位就是追求思想深度，否则不必苛求每篇文章都有所谓的深度，有时候即使是日常生活的小记也有其价值，读者能从中发现很多自己不知道的东西。例如 JustZht 的 一些生活小记 .
记得多年前我刚开始写博客的时候知道了罗磊和 罗磊的博客。虽然当时罗磊是一个前端工程师，但博客大多数文章都不是技术，而是一些数码产品和生活方式，例如 他跑马拉松的记录。
这些内容没有所谓的「深度」，但让我看到了不同的生活方式。每个人都有自己独特的生活方式，不妨把它分享出来让更多人从中获得借鉴。
文章写不长
并非写长文章才叫写博客，李如一的 一天世界 也不见得每篇文章的篇幅都长，但内容有其独特的思维方式，也能引发思考。这就够了。
没什么人看
写独立博客和写公众号不同，你不必追求「十万加」。你要追求的是一个陌生人只要进入一个网站就能知道你是什么人。你不靠写博客吃饭。人们总说 You are what you read, 当人们无法得知你在读什么的情况下，那么我更要说： You are what you write.
文章写完，分享给你喜欢的圈子，论坛，回复一些评论。慢慢地就会在你的圈子积累一些读者。
做不到一直更新
JerryQu 的博客 已经两年没有更新，但两年后的现在依然可以说这是一个很好的博客。
你的博客不是资讯网站，不必在意更新频率。
希望本文可以引导各位潜在的博客作者决心建立自己的独立博客。独立博客有免于献媚的自由，有排版自由，有修改删除自己说了算的自由。维护一个有意义的博客不是一件难事，用现成的平台或用框架，在网站主页写上你的个人简介，然后保有分享生活和想法的习惯，不限篇幅，不限频率（即使是一年一篇），按时续费域名，保持网站正常访问，
记住，一个博客的死掉不是不再更新，而是无法访问。
延伸链接
● 中文独立博客列表
via Randy's Blog
我在 UC 做的前端工程化探索
我在 2016 年初加入 UC 的国际业务部，负责为 UC News 搭建运营后台。随着前端团队人数越来越多，我开始推动团队的前端技术栈统一以及前端工程化，开发了一个叫 Cans 用于快速搭建中后台前端应用的框架。直到了 2019 年我离开 UC, Cans 仍然服务于 UC 的国际业务。
本文主要记录了我如何从 UC News 运营后台孵化出这个内部框架，以及其背后的设计理念。虽然 Cans 没有开放源代码。但我认为相比这些工具的源码，那些我在开发这些工具背后的理念、思考，更有被分享的价值。也算作是对我在 UC 工作的一个总结。遂有此文。
----------------------
我们在做 UC News 运营后台的时候，面临的最大问题是：当有新的业务需要我们团队支撑开发一个新运营后台的时候，我们应该怎么做？
这种情况在不断地发生。2017 年我们的 UC News 运营后台趋于成熟，业务需求响应的速度在不断提高。越来越多业务方问我们同一个问题：「我们 xxx 业务想有一个运营后台，我们可以快速接入吗？」
如何让 UC News 运营后台的开发经验可以被快速地复制出去，帮助更多业务？在回答这个问题之前，我想先说说我是怎么设计 UC News 运营后台的前端工程以提高需求响应速度的。
第一点是保证业务开发尽量不被构建环节干扰，只须关注业务逻辑本身。这一点很好保证，因为构建配置基本是不需要更改的。
第二点是降低新页面接入的成本。所谓的成本指的是：
● 页面绑定对应的路由
● 在左侧菜单栏添加菜单项并指向对应的路由
我把这两点变成配置项，可以直接在项目里的 routes 文件配置。这样新页面接入只需配置菜单项的标题和路由，以及对应的页面组件即可。
第三点是规范项目目录结构。这一点我在 Egg 上受到很大的启发。在内部，我们的 Node.js 系统都使用 Egg. 我借鉴 Egg 把项目配置、路由配置、应用启动代码等作了规范：
要用这一套模式赋能更多不断冒出的新业务，首先要做的是统一。
在社区上做开源软件和做公司内部的软件不同，前者通常需要考虑兼容性。处理兼容性的代价是越来越复杂的配置项。但做内部软件，则可以通过「统一」简化配置（甚至无需配置）。例如，两个业务如果分别使用 less 和 sass, 那么在新建项目时，两个业务都要各自配置。相反，如果早已约定所有业务都使用 less, 那么 less 的配置可以固化到统一的工具里，两个业务都不需配置。
首先是技术栈的统一：
● React
● 组件库：Ant.Design
● 构建工具：Webpack
● 语言：TypeScript
● css 预编译：Less
技术栈的选型背后没有什么高深的思量，不过是这一套在 UC News 运营后台经过了考验：Ant.Design 的组件覆盖了 90% 的需求；纯 EcmaScript 写运营后台这种复杂应用是灾难，尤其在新人接手的时候；
技术栈的统一带来的是构建配置可以全部收敛，当然除了技术相关的工具，还有业务层面的工具可以统一收敛：
● 构建产物发布到 cdn
● 打点、错误监控的封装
● 网络请求库统一
● i18n 方案统一
做好了这些统一的准备，我开始开发一个叫 Cans 的前端解决方案，它的宗旨是快速搭建中后台类的项目。
框架设计
「开箱即用，没有多余的东西」是我从 zeit.co 领会到的软件设计哲学。如果说一个框架设计得美，那么其实是说它用最简单且符合直觉的接口封装了最复杂的逻辑。
和 next.js 一样，我希望开发者只要用
在最基本的应用，
也就是收集所有运行时将要用到的数据，然后生成一个入口 js 文件。
另外，在构建中还引入了 tree shaking, code splitting (with react-loadable) 等等优化手段。
构建时分析的应用数据，可以在运行时、页面中通过 import app 实例来获取：
这种注入机制是为了提供扩展性，为了通过这种扩展性建立「生态」，Cans 引入了 addon 机制，以一个打点 addon 为例：
开发者可以在 npm 发布以
Cans 自带了一些业务常用的 addon:
● cans-addon-cookies ● 通过
● cans-addon-storage ● 通过
● cans-addon-http ● http 请求方法封闭
虽然中后台的布局千篇一律，但为了尽量覆盖所有定制化的需求，Cans 也开放了 theme, 开发者可以定制自己的主题，用
而在业务层，尽可能将可复用的业务组件封装出去，让更多业务可以使用。如 antd-data-table 这个业务组件，就是从 UC News 运营后台独立出来的。
以上是 Cans 这个框架的大概模样, 或有其它细节，但不是本文的重点。
在设计这个框架的时候，我无时无刻在考虑的是如何使开发者要写的代码越来越少，同时开放的接口是要符合开发者直觉的。就像「建立一个页面就是创建一个页面文件然后运行
几年前我读了《乔布斯传》，使我对用户体验有了极致的追求，也把这种追求带到了软件开发。这种体验不是一句 Simple is better 就可以说明的。你在同时面对一堆电路板和一台 Macintosh 的时候可能才会体会到所谓的「科技与人文的十字路口」，但，软件设计同样有这样的十字路口，它可能出现在一份完整、漂亮的文档（像 Vue）, 可能出现在一个屏蔽了所有复杂细节 (and it just works!) 的命令（像 next.js）, 可能出现在它的小而美，可以接入到任何地方。
后来蚂蚁金服发布了 Umi, 比 Cans 做得更全面，但两者的思路都如出一辙。我想这证明了这套模式背后的价值所在。最近看到《Umi 架构、生态和未来》 ，让我更确信当初的想法和 Umi 在做的是契合的。推荐各位在下一个项目可以试试 Umi.
记得有一次面试的时候，我提到我主要是做一些前端基建的工作，面试官问我，觉得什么样的前端基建是做得好的基建？我回答说，如果我做的基建可以让同事少加班，那么我做的基建就是好的。
via Randy's Blog
Invalid media:
image
image
image
image
image
image
image
image
image
image
image
我在 2016 年初加入 UC 的国际业务部，负责为 UC News 搭建运营后台。随着前端团队人数越来越多，我开始推动团队的前端技术栈统一以及前端工程化，开发了一个叫 Cans 用于快速搭建中后台前端应用的框架。直到了 2019 年我离开 UC, Cans 仍然服务于 UC 的国际业务。
本文主要记录了我如何从 UC News 运营后台孵化出这个内部框架，以及其背后的设计理念。虽然 Cans 没有开放源代码。但我认为相比这些工具的源码，那些我在开发这些工具背后的理念、思考，更有被分享的价值。也算作是对我在 UC 工作的一个总结。遂有此文。
----------------------
我们在做 UC News 运营后台的时候，面临的最大问题是：当有新的业务需要我们团队支撑开发一个新运营后台的时候，我们应该怎么做？
这种情况在不断地发生。2017 年我们的 UC News 运营后台趋于成熟，业务需求响应的速度在不断提高。越来越多业务方问我们同一个问题：「我们 xxx 业务想有一个运营后台，我们可以快速接入吗？」
如何让 UC News 运营后台的开发经验可以被快速地复制出去，帮助更多业务？在回答这个问题之前，我想先说说我是怎么设计 UC News 运营后台的前端工程以提高需求响应速度的。
第一点是保证业务开发尽量不被构建环节干扰，只须关注业务逻辑本身。这一点很好保证，因为构建配置基本是不需要更改的。
第二点是降低新页面接入的成本。所谓的成本指的是：
● 页面绑定对应的路由
● 在左侧菜单栏添加菜单项并指向对应的路由
我把这两点变成配置项，可以直接在项目里的 routes 文件配置。这样新页面接入只需配置菜单项的标题和路由，以及对应的页面组件即可。
第三点是规范项目目录结构。这一点我在 Egg 上受到很大的启发。在内部，我们的 Node.js 系统都使用 Egg. 我借鉴 Egg 把项目配置、路由配置、应用启动代码等作了规范：
要用这一套模式赋能更多不断冒出的新业务，首先要做的是统一。
在社区上做开源软件和做公司内部的软件不同，前者通常需要考虑兼容性。处理兼容性的代价是越来越复杂的配置项。但做内部软件，则可以通过「统一」简化配置（甚至无需配置）。例如，两个业务如果分别使用 less 和 sass, 那么在新建项目时，两个业务都要各自配置。相反，如果早已约定所有业务都使用 less, 那么 less 的配置可以固化到统一的工具里，两个业务都不需配置。
首先是技术栈的统一：
● React
● 组件库：Ant.Design
● 构建工具：Webpack
● 语言：TypeScript
● css 预编译：Less
技术栈的选型背后没有什么高深的思量，不过是这一套在 UC News 运营后台经过了考验：Ant.Design 的组件覆盖了 90% 的需求；纯 EcmaScript 写运营后台这种复杂应用是灾难，尤其在新人接手的时候；
技术栈的统一带来的是构建配置可以全部收敛，当然除了技术相关的工具，还有业务层面的工具可以统一收敛：
● 构建产物发布到 cdn
● 打点、错误监控的封装
● 网络请求库统一
● i18n 方案统一
做好了这些统一的准备，我开始开发一个叫 Cans 的前端解决方案，它的宗旨是快速搭建中后台类的项目。
框架设计
「开箱即用，没有多余的东西」是我从 zeit.co 领会到的软件设计哲学。如果说一个框架设计得美，那么其实是说它用最简单且符合直觉的接口封装了最复杂的逻辑。
和 next.js 一样，我希望开发者只要用
cans start 这一条命令，就能开始开发一个页面。在最基本的应用，
cans start 的背后会做这样的工作：也就是收集所有运行时将要用到的数据，然后生成一个入口 js 文件。
另外，在构建中还引入了 tree shaking, code splitting (with react-loadable) 等等优化手段。
构建时分析的应用数据，可以在运行时、页面中通过 import app 实例来获取：
这种注入机制是为了提供扩展性，为了通过这种扩展性建立「生态」，Cans 引入了 addon 机制，以一个打点 addon 为例：
开发者可以在 npm 发布以
cans-addon- 为前缀的库贡献生态。Cans 自带了一些业务常用的 addon:
● cans-addon-cookies ● 通过
app.cookies.get 和 app.cookies.set 读写 cookies● cans-addon-storage ● 通过
app.storage 做离线数据持久化（如本地数据缓存）● cans-addon-http ● http 请求方法封闭
虽然中后台的布局千篇一律，但为了尽量覆盖所有定制化的需求，Cans 也开放了 theme, 开发者可以定制自己的主题，用
app.theme() 引入。也可以在 npm 上贡献主题。像我们最常用的运营后台 theme：而在业务层，尽可能将可复用的业务组件封装出去，让更多业务可以使用。如 antd-data-table 这个业务组件，就是从 UC News 运营后台独立出来的。
以上是 Cans 这个框架的大概模样, 或有其它细节，但不是本文的重点。
在设计这个框架的时候，我无时无刻在考虑的是如何使开发者要写的代码越来越少，同时开放的接口是要符合开发者直觉的。就像「建立一个页面就是创建一个页面文件然后运行
cans start 一样简单。几年前我读了《乔布斯传》，使我对用户体验有了极致的追求，也把这种追求带到了软件开发。这种体验不是一句 Simple is better 就可以说明的。你在同时面对一堆电路板和一台 Macintosh 的时候可能才会体会到所谓的「科技与人文的十字路口」，但，软件设计同样有这样的十字路口，它可能出现在一份完整、漂亮的文档（像 Vue）, 可能出现在一个屏蔽了所有复杂细节 (and it just works!) 的命令（像 next.js）, 可能出现在它的小而美，可以接入到任何地方。
后来蚂蚁金服发布了 Umi, 比 Cans 做得更全面，但两者的思路都如出一辙。我想这证明了这套模式背后的价值所在。最近看到《Umi 架构、生态和未来》 ，让我更确信当初的想法和 Umi 在做的是契合的。推荐各位在下一个项目可以试试 Umi.
记得有一次面试的时候，我提到我主要是做一些前端基建的工作，面试官问我，觉得什么样的前端基建是做得好的基建？我回答说，如果我做的基建可以让同事少加班，那么我做的基建就是好的。
via Randy's Blog
Invalid media:
image
image
image
image
image
image
image
image
image
image
image
回顾了一些读者来信
从 2014 年开始写博客以来，因为不设评论区，我收到不少读者的 Email 来信。透过 Email, 来信的人比评论区直接评论要更严谨一些。来信中的大部分是请教问题，其它则是一些感谢的话。
几天前我购买了一块软木板挂在自己的房间，想到可以把一些有意思的读者来信打印出来钉到软木板上。于是在收件箱整理了 2014 年至今 5 年来收到的所有读者来信。
其中我发现一封 2015 年的已经被我淡忘的邮件：
这是一位在国外当老师的妈妈，特意来信想为她的儿子寻问关于编程的问题。当时我回信尽可能地写了很多浅薄的意见和经验分享，后来就再没有通信。这位母亲让我感动。
时隔几年再看来往的信件，无论是提到的这位母亲，还是其它特意发来感谢的读者，他们让我收获到的是，我写的文字确实帮助了一些人；五年来我坚持写独立博客是有意义的；这些来信让我意识到我活在世上还是有一点微不足道的贡献。所以我最开心的是看到来信里面提到的，我对读者的影响是什么。
对我来说，有没有活下去的勇气，取决于我在世界上有没有创造价值。这些读者来信是我写博客收获的最宝贵的财富。
via Randy's Blog
Invalid media:
image
image
image
image
image
从 2014 年开始写博客以来，因为不设评论区，我收到不少读者的 Email 来信。透过 Email, 来信的人比评论区直接评论要更严谨一些。来信中的大部分是请教问题，其它则是一些感谢的话。
几天前我购买了一块软木板挂在自己的房间，想到可以把一些有意思的读者来信打印出来钉到软木板上。于是在收件箱整理了 2014 年至今 5 年来收到的所有读者来信。
其中我发现一封 2015 年的已经被我淡忘的邮件：
这是一位在国外当老师的妈妈，特意来信想为她的儿子寻问关于编程的问题。当时我回信尽可能地写了很多浅薄的意见和经验分享，后来就再没有通信。这位母亲让我感动。
时隔几年再看来往的信件，无论是提到的这位母亲，还是其它特意发来感谢的读者，他们让我收获到的是，我写的文字确实帮助了一些人；五年来我坚持写独立博客是有意义的；这些来信让我意识到我活在世上还是有一点微不足道的贡献。所以我最开心的是看到来信里面提到的，我对读者的影响是什么。
对我来说，有没有活下去的勇气，取决于我在世界上有没有创造价值。这些读者来信是我写博客收获的最宝贵的财富。
所以这些人呢，不管是什么借口，最终选择了去做恶心的成年人社会中的一个恶心的人，最可气的是他们之后还产生了幻觉，说这就是“成熟”。于是又过来毒害年轻人，跟他们说，你看，我年轻的时候也像你这样，现在我这叫成熟，你这叫幼稚。
我现在看到很多我的同龄人变成这样，很多人都是我小时候的好朋友，也曾经充满了理想，充满了美好的这些东西，然后相信自己可以改变世界，最后却变成了这种恶心的人。
我回家吃饭心情好就敷衍一下，有时候心情不好就忍不住当场戳穿他们。我说：“你看你们这帮兔崽子，年轻时候我们在一块儿聊，都说要改变世界，现在你，你改变个屁了。”然后他们就有点不好意思，说：“哎呀，行了，老罗，咱们那时候不是幼稚吗？谁能改变世界？谁也改变不了世界。”我就跟他们说：“你别客气了，你已经改变这个世界了，因为你变成了一个恶心的人，这个世界多了一个恶心的人，因此它变得恶心了一点点。”
每一个生命来到世间，都注定改变世界，这是你的宿命，你别无选择。你要么把世界变得好一点，要么把世界变得坏一点。
你如果走进社会，为了生存或是为了什么不要脸的理由， 变成了一个恶心的成年人社会中的一员，那你就把这个世界变得恶心了一点点。 如果你一生耿直，刚正不阿，没做任何恶心的事情，没有做任何对别人造成伤害的事情，一辈子拼了老命勉强把老婆、孩子、老娘，把身边的这些人照顾好了，没有成名，没有发财，没有成就伟大的事业，一生正直，最后梗着脖子到了七八十岁死掉了，你这一生是不是没有改变世界？你还是改变世界了，你把这个世界变得美好了一点点。因为你，这个世界又多了一个好人。
—— 罗永浩
via Randy's Blog
Invalid media:
image
image
image
image
image
爱情是愿意为你放弃寻新鲜
昨天在回杭的飞机上看完《Newness》, 一部探讨开放性关系的电影。男女主角都喜欢新鲜感，最后因为约炮堕入爱河，但很快开始感到关系平淡和厌倦，于是尝试开放性关系. 各自一番经历后最终决定放弃自由，认真经营这段感情。
我很喜欢探讨这种两性哲学问题，因为我在看待两性关系中有些犬儒主义 —— 我不相信人性，不相信忠诚，世界上充满诱惑。更愿意相信大多数的婚姻是一场交易。
当两人初试开放性关系时，遇到一位专家在谈论「外遇」和「开放性关系」的成因，她说：
有意思的是，在片中，男主角对开放性关系的底线，是只有自己可以令女主角高潮。所以每次女主角回家，他都会问女主角 Did you come (你高潮了吗)? 后来，女主角被一位成熟、事业有成的大叔深深吸引，她在他身上得到高潮后，男主角才感到他们的这段关系，已经彻底崩坏。
片尾，男女主角决定承受平淡、怨怼，回到对方身边。因为在各自经历过后，更加清楚彼此为何在一起。
或许最可靠稳固的关系就是双方愿意为对方失去那个原本的自己，而且是亲身经历告诉他们为何值得这样牺牲。
正如片中的两性专家所说，「开放性关系只是一个过程，千万不要把它作为你们的终点」。
via Randy's Blog
Invalid media: image
昨天在回杭的飞机上看完《Newness》, 一部探讨开放性关系的电影。男女主角都喜欢新鲜感，最后因为约炮堕入爱河，但很快开始感到关系平淡和厌倦，于是尝试开放性关系. 各自一番经历后最终决定放弃自由，认真经营这段感情。
我很喜欢探讨这种两性哲学问题，因为我在看待两性关系中有些犬儒主义 —— 我不相信人性，不相信忠诚，世界上充满诱惑。更愿意相信大多数的婚姻是一场交易。
当两人初试开放性关系时，遇到一位专家在谈论「外遇」和「开放性关系」的成因，她说：
When I go to look for someone else, it’s not always because I wanna get away from you, it’s because I wanna get away from the person that I have myself become. And it’s not that I want to find somebody else, but I want to find another self.
当我开始想寻找另外一个人的时候，不是因为我想离开你，而是想逃离这个状态的我。我想寻找的不是另一个人，而是另一个我。我想，这就是除了厌倦、诱惑之外，外遇的核心原因 —— 无法接受这个安定的自己。
有意思的是，在片中，男主角对开放性关系的底线，是只有自己可以令女主角高潮。所以每次女主角回家，他都会问女主角 Did you come (你高潮了吗)? 后来，女主角被一位成熟、事业有成的大叔深深吸引，她在他身上得到高潮后，男主角才感到他们的这段关系，已经彻底崩坏。
片尾，男女主角决定承受平淡、怨怼，回到对方身边。因为在各自经历过后，更加清楚彼此为何在一起。
或许最可靠稳固的关系就是双方愿意为对方失去那个原本的自己，而且是亲身经历告诉他们为何值得这样牺牲。
正如片中的两性专家所说，「开放性关系只是一个过程，千万不要把它作为你们的终点」。
Think of it not as the destination, but the layover.
via Randy's Blog
Invalid media: image
