曾经的我，对于电子产品有极度的热爱，出了新品，会想尽办法尝试。
可如今的我，已经不再是当年的自己了。现在的我，拿到新手机不会再兴奋的去尝试各种新功能；拿到新的设备不会兴冲冲的给朋友看。
现在的我，拿到一个设备，平淡无奇，看一眼“哦，就这样“，就结束了。
真的老了。
感觉自己老了
发表评论
分类目录归档：随笔
灵感：一个基于 Github 的 Twitter 用户数据分析工具
这两天在研究 Twitter 的增长。在想有没有可能做一个开源的 Twitter 用户数据分析工具。奈何暂时没空，所以先把灵感记录下来。
特色
- 使用 Github 存储数据，无需另行创建数据库
- 项目无需服务器
特性
- 使用 Github Action 获取数据
- 使用 Github 存储数据
- 使用 GitHub Pages 展示数据
一些实现的思路
- Github Action 支持定时触发，可以设定每小时/每分钟启动一次，这个应该是一个配置参数。
- 数据应该是两种，一种是分块数据，按日切片/按小时切片。同时应该还有一个合并后的数据，用于 Web 展示。这部分的实现思路可以参考之前做的 opensource menu
- 页面应该是自动构建然后放置在
gh-pages分支，然后可以默认访问。 - 页面应该可以看到数据和在数据前后的 tweet （所以需要调用多个 API）
宋冬野背后的“人治”问题
前几天，宋冬野在微博上发了一张长图，大意是，自己跑去参加活动，结果被人举报，不让他参加。断了他自己的财路，希望大家能给他一个活路。
后来有不少自媒体提到：“给了你一次机会，谁来给哪些逝去的缉毒警一个机会呢？“
我倒是觉得，这个问题，大家都过于看重了毒品，却忘记了到底谁才能评判一个人的罪。
我们常言，警察是只有执行权，没有司法权的。也就是说，警察只能陈述事实的真相是什么，而不能评判一个人是否有罪。所以警察永远说的“犯罪嫌疑人”，只有法院才能判定一个人是罪犯。
但当这些事情变成“民意”后，大家却觉得这个事情，理所当然，但普通人和个体不应当拥有司法权。不然，便是滥用私刑。这便是我们在遭遇事情后，我们不应自行处理，而是应当将其交给法律。即使可能在我们看来，法律可能并不足以惩戒这个“罪犯”。
回到宋冬野的这个事情身上，这个点我觉得最重要的是，当初司法机构给出的判决是“禁演三年”而非“终生禁演“，而宋冬野也在遵循来自法律的判决，三年禁演。那么三年后，我们作为看客，就应当放下我们内心的不适，去接受这个事实。
而普通民众的举报，也很正常，因为大家并不懂法，所以觉得“为什么吸毒的人可以出来公演”，所以举报。但执法机关却去强制禁演，甚至在社交媒体上禁言，就有点“滥用职权”的意思了。
毕竟，在这个事情上，作为主要人员的宋冬野除了三年前的判决以外，是再无其他过错的。而禁演的三年，就是为了偿还他的过错。我们始终以一个人过去的错误来惩罚他，便忘记了，刑罚除了“惩戒罪犯”以外，还有“教育罪犯”，希望其不要再次犯错。如果一个人以莫须有的罪名而被惩戒，那他如何从中学到呢？毕竟被惩戒的原因可能都是不存在的。
倘若我们认为“无法给缉毒警一个机会”，我们应当做的是，在一开始，就直接终身禁演，而非在法律作出判决之后，一而再，再而三的去践踏法律。
当然，我想，当初之所以没有给终身禁演，司法机关也在考虑是否量刑过重的问题。应当让法律发挥其应有的效力，而不是仅仅凭民意。
回到宋冬野本身，我倒是觉得，司法机关应该尽可能的增加毒品相关的量刑，比如，直接所有的艺人涉毒终身禁演，那对于每一个娱乐圈人士，可能都会在吸毒之前，认真思考一下。
养猫如养子
我养了三只猫，朋友笑称，我以后一定是四年抱三个娃。
但对于我来说，不是这样的。虽然他们只是猫，不是人，但依然是我的亲人，我如同孩子一般看他们。和我亲生孩子的区别，只有一个需要上学，一个不需要上学的区别。
孩子生病了，我很紧张；猫生病了，我一样紧张；
孩子生病了，该做的检查，能做的起的就做。实在做不起的就算了。猫生病一样的待遇。
对我来说，猫并不是一个宠物，而是一个生孩子/养孩子的前置训练。但并不意味着前置训练，我就可以置猫的生命而不顾。我会努力的让他们可以过的更好。享受美好的猫生。
但是，养猫也让我思考，生几个孩子才是最好的，目前来看，我的答案是 ： 1 个。猫生病我尚且很难，更何况是人呢？
作为自由职业者，你需要放弃的东西
绝大多数的人，提起自由职业者，都会不断的宣传自由职业者的好处（比如我也是这样的），但确实很少有人会提及自由职业者的问题。所以，我觉得有必要写一篇文章，来说明自由职业者的问题。
收入不稳定 & 收入锐减
对于绝大多数行业来说，自由职业都意味着收入锐减。即使你是软件工程师，也不可避免的会遇见收入减少的问题。
这个锐减大概是什么情况呢？对于绝大多数人来说，可能你在企业内的收入，会是你自由职业收入的 2-3 倍。
所以，对于很多已经工作的人来说，自由职业并不是一个靠谱的方案，因为对于他们来说，房贷、车贷等已经背上的杠杆，无法轻易的抹去，如果他们选择了自由职业很有可能会带来无法还贷，致使资金链断裂，房产等被收回。
这也是很多时候我们发现，自由职业者往往是年轻人的选择，因为无贷一身轻。
职业前景暗淡
这个点其实是比较有争议的，因为如果你自由职业了大概率回不去坐班的生活，但如果你还有可能回去坐班上班，那么这个就是给你看的。
自由职业和职场的发展的一个很大的不同便是是否有明确的进阶路线，很显然，自由职业属于没有进阶路线，完全自由自主的。
你的发展可能是全方面的，但是不均衡的。对于需要一个螺丝钉的大企业来说，可能无法找到那个适合你的位置。
当然，如果你始终在自由职业的路上走，那么这是一个不需要你考虑的问题，因为自由职业的路是一个没有常规升级方案的路。从某种意义上，你和创业没什么区别。
与社会生活隔绝
如果你是一个很宅的人（比如像我一样，一周可能都不出门一次），那么意味着你很有可能会和社会隔绝。
山中无历日，寒尽不知年
唐代诗人太上隐者的《答人》
你需要给自己找一些事情去做，主动去与社会沟通、接轨。比如参与到一些社会活动之类的，以获得明确的时间感、界限感。
毕竟，对于你来说，周一和周日没有区别，都是一样的。你可以尽情享受自由的逛街、自由的出游，但同样的，也要忍受一个人出去玩的孤独，因为所有的朋友都在上班。
无法实现资产的增值
我们常说，对于每一个人来说，这辈子最大的杠杆就是你在买首套房的时候，可以用30%的资金，撬起 100% 的资产。
自由职业的话，因为收入不稳定，给自己上杠杆是一个不太保险的手段，选择一些杠杠没有那么高的投资方式，可能是一个更好的选择。
需要生活在小地方
自由职业者，因为职业的原因，可以生活在一些成本更低的地方，来实现地理套利。但同样的，也会因为你的收入低，不得不生活在一些成本更低的地方。
你通过降低生活成本、降低生活满意度，获得一个更加自由的生活。
孰轻孰重，自己判断吧。
总结
自由职业并不是全都是好的方面，同样也有坏的方面，我能给出的建议就是这些，你在做出选择的时候，需要考虑清楚自己想要的是什么，再作出最后的决定。
越来越好的轻量应用服务器
这几天规整我手头的 VPS、云主机，意外发现腾讯云推出了 LightHouse DB，激起了我的兴趣，刚好也对比一下其他几家的产品。
在 You don’t NEED scaling 中，我提到，对于绝大多数的企业来说，根本用不到云计算厂商提供的产品，他们需要的仅仅是一个简单的 VPS即可。
各家云厂商也意识到了这个问题，纷纷推出了低配版的云主机（VPS），亚马逊的叫 Lightsail，阿里云的叫轻量应用服务器，腾讯云的叫轻量应用服务器 LightHouse。
名字接近，定价也相差无几，起步定价均在 24 元/月附近，直逼 Digitalocean 的 $5/月的定价，和 Vultr 的 $2.5/月的定价也没贵多少。可以看出，这类产品的对标，便是 Do、Vultr、Linode 之类的 VPS 厂商。
而过去，国内的轻量应用产品都是处在不能用的场景下，因为
- 没有独立的数据盘：这导致无法实现系统和数据的分离，在数据安全性方面，有所问题。
- 内网与其他云产品不互通：这导致无法使用云数据库类型的产品，数据安全方面得不到保障。
这两点让使用这类产品的时候，都会面临需要自己做更加细致的运维的工作。
不过，我现在发现，各家的产品都在变好了。如，阿里云针对数据盘问题，提供了独立的数据盘的能力（但之前购买的轻量云服务器无法添加数据盘）。
腾讯云则针对内网不互通的问题进行了优化，提供了内网互联和LightHouse DB 的能力，让用户可以自行配置所使用的云资源。
经过这么一优化，我觉得，这两者基本都达到了可用的层次。
阿里云用户可以通过数据盘来规避数据安全的问题，为数据提供更高的保护等级；腾讯云用户则可以通过内网互联，将用户上传的文件，托管到 COS 对象存储中；将用户数据放在 LightHouse DB 中；将缓存放在云 Redis 中。
相比之下，我更倾向于使用腾讯云的 LightHouse（希望能早日支持数据盘），要不是我的博客服务器续费了一年，我现在就打算切换到腾讯云了。
2022.03.11 更新
- 阿里云轻量应用服务器已经支持了内网互通能力：https://help.aliyun.com/document_detail/323545.htm
- 腾讯云轻量应用服务器也已经支持了挂载数据盘：https://cloud.tencent.com/document/product/1207/63919
You don’t NEED scaling
云计算成为当下时代的主流，云计算的“弹性伸缩”，把创业者搞的五迷三道。似乎云计算成为了当下的唯一选择，没有使用云计算，你就是 Low B ，你的公司就会在出现问题以后，一夜崩塌。
但，事实真的是如此的么？
世界上做云最早的，是 AWS，亚马逊的 AWS 是云计算行业的先驱和老大哥。国内做云最早和最专业的事，是阿里云，阿里巴巴旗下的阿里云成为国内初创企业的云计算必选项。
但，你有没有想过为什么会是他们？
这是因为作为一个电商企业，云计算是他们所必须的。每逢黑色星期五/双十一/六一八，电商企业就需要采购大量的基础设施，以应对节日的流量洪峰。但除了电商企业以外，很少有企业需要面对那么极致的弹性伸缩。
对于电商企业来说，节日的流量可能是日常的 100 倍、1000 倍。而对于绝大多数的业务，即使出现了流量爆炸，往往也是在 10 倍、20倍的变化。正常情况下，流量的变化也是一个可以预期的事情。
对于这些没有那么强弹性诉求的企业来说，云计算提供的弹性伸缩能力很好，但确实没有什么应用场景。倒是让企业为此付出了不少的代价。
对于绝大多数的企业来说，他们需要的仅仅是一个 VPS，甚至，仅仅需要一个虚拟主机，但云计算的洗脑，让你感觉你”好像需要弹性伸缩能力“，让你感觉，你”好像拥有了和 AWS 同等级别的弹性伸缩能力“。
但是，别忘了，弹性伸缩不仅仅是云计算的事情，还需要你的业务架构能支持、你的运维人员能搞定，你的钱包能 Cover 住。
你真的需要云计算么？你真的需要弹性伸缩么？
升级到 Windows 11
我一直都有一台 NUC10i7FNH，刚好最近发布了 Windows 11。
对于我来说，似乎发生了变化，但似乎确实也没发生啥变化。除了开始菜单变到了中间，其他并没有差异。
但我并不使用开始菜单启动应用，而是更加习惯于使用 PowerToys 提供的 Power Toys Run 来启动应用，因此比较无感。
如今的我，对于 iOS 的更新会追最新，但已经很少再去关注具体的细节了。顶多体验一下最新的一些特性，然后就不再关注了。
类似的，如今的 Windows 11 ，对于我来说，也变得普通了。
大概是因为我已经老了，不再去关注那些最新奇的东西了，反而是更加关注新奇的东西所带来的价值。
给知名项目提 Typo 修复有什么问题？
昨天在 V2ex 看到一个帖子，吐槽掘金上有人教别的程序员去给知名的开源项目提交 Typo Pull Request。
「掘金上居然有文章教人怎么给开源软件提 typo issue」
刚好，我也之前写过类似的文章，一篇《如何成为Golang贡献者》，另一篇《如何为任何开源项目做贡献？》，其实内容相差无几。就也来以“当事人”的身份聊聊这个问题。
Typo 有意义么？
答案是肯定的，任何对于开源项目有帮助的 Pull Request ，都是有意义的。因为他帮助开源项目变得更好，哪怕这个更好只是一个字、一句话的更好。
从项目的层面来看，项目是鼓励每个人去做贡献的。
而从项目开发者的角度来看，每一个 Pull Request 背后都是一个希望加入社区的开发者，如果开发者可以做好贡献者培养，对于项目的持续运行是有很大帮助的。所以我们可以看到，每年都有项目参加 Google 的 GSOC，都有项目参加 Digital Ocean 的 Hacktoberfest。
唯一可能出现的问题是：大量的 Typo Pull Request 会侵占维护者的心力，使得维护者无暇处理更加重要的事情。
当然，这样的问题是可能存在的。但换句话说，这也是一个开源项目维护者群体壮大的好机会。如果不堪其扰，有很多种方式来处理：
- 提拔已有的 Commiter 为 Contributor，由某个 Contributor 来处理 Typo 类型的 Pull Request。
- 慢慢合并 Typo Pull Request，开源项目的 Pull Request 的合并并不一定是很快的，事实上绝大多数项目的合并都不会很快，特别是一些大型项目。在这种情况下，你大可以慢慢处理。
所以，Typo 的 Pull Request 所产生的坏处大概率是可以通过一些方式规避掉，而让项目可以进一步的发展。
对于贡献者来说，Typo 有意义么？
对于新手来说， Typo 类型的 Pull Request 是有意义的。
正式的开源项目往往会有很多规范和流程上的东西，这些东西是需要开发者通过参与开发才能慢慢熟知的，比如 pull request 的格式、信任的建立。从这个角度来看， Typo 类 Pull Request 可以帮助开发者快速熟悉一个开源项目的规范、约定俗成的习惯。
对于老手来说，Typo 类型的 Pull Request 没有意义。
除非你的企业需要按照 Pull Request 数量来帮你计算 KPI，不然提 Typo 类型的贡献对于你来说，百害而无一利。
我们现在在简历上会看你的 Github，因为 Github 能够证明你的实力。但你是否想过，如果你是面试官，你会看好一个给某个项目只提 Typo，而不做任何 Bugfix、Feature 更新的开发者？ 我想大多数人都是 No。既然如此，你为什么会觉得提交 Typo 类型的 Pull Request 能够帮助到你自己呢？
总结
固然，提交 Typo 类型的 Pull Request 会占据开发者的心力，但通过简单处理就可以绕过的情况下，我还是鼓励开发者去提交贡献的。
你愿意帮助 Paul Graham 做本地化么？
发现了一个空白，如果有人做的话，大概率会被不少国内的大佬看到。对于求职应该有帮助。
Paul Graham 的博客是欢迎翻译的，作为一个初入行的同学，你大可以翻译帮助 Paul Graham 翻译他的文章， 并提供链接给他，这样你自己的网站的链接也会得到关注度。
Paul Graham 是《黑客与画家》的作者。
只差一个有心人。
