我又双叒叕遗失了我的 Kindle Voyage。
上一次遗失，还是我在医院住院时，找不到了我的 Voyage，于是我买了一个 Kindle Oasis 2。但后来出院时又找到了我的 voyage，Oasis 进入吃灰状态。
相比于 Paperwhite、Oasis，Voyage 算是我最喜欢的阅读器了：他的体积刚刚好，可以直接放进口袋里（这也是为什么我总是带着 Voyage，以及为什么这一次 Voyage 会丢掉）。
Voyage 我买于刚上大学的时候，彼时 Kindle Voyage 刚出，我便直接购买了最贵的 Voyage。从 2015 ，到如今的 2023 ，Kindle Voyage 陪伴我了 8 年时间，陪伴我走过了几百本图书的风风雨雨。
感谢 Voyage ！感谢你的陪伴，让我的生命从不孤单。
接下来的日子里，就要让 Kindle Oasis 来陪伴我了（以及微信读书阅读器 2 代）。
ChatGPT 火了一段时间了，我自己也玩了一段时间，但说实话，在 ChatGPT 的官网上使用这个东西实在是不方便，要切换机器，挂代理才能使用，于是，我便起了心念，想着可以做一个简单的飞书机器人，配置一下，这样我就可以在飞书里使用了。于是便写了一个这么个项目。
刚好 ChatGPT 又确实非常火， 于是便考虑把这个项目开源出去，于是便在 2 月 9 日的晚上，吃完饭的我打开电脑，开始了写 ChatGPT-FeiShu 的代码。
在写的过程中，我开了视频的录制，将整个开发的过程记录了下来，顺便，把项目开源出去 & 录制成一个 Vlog ，来作为我自己的记录，挺好。
当我录制完视频，写完代码之后，便将项目发出去睡了。接下来的几天里，我倒是没有太过费心的去研究这个项目，而是等待其自然发酵。直到今天，写下了这个复盘。
我觉得这个项目做的好的有以下几个点：
对于那些已经很擅长开发的人来说，其实我提供这个机器人并没有太大的价值。如果你仔细看我这段代码的话，会发现，这段代码并不复杂，核心就是解析飞书发过来的消息，并发给 OpenAI，然后将 OpenAI 的消息通过飞书返回回去。但他对于降低 ChatGPT 之类的产品的使用门槛有极大的帮助 —— 不再需要了解如何注册 ChatGPT 账号，一个企业只需要一个人配置， 就可以让整个企业的人用起来。
在后续和其他人交流时，大家对于我这个产品最大的感受是“牛，小白也可以用起来”，这个属性让我的项目得到了广泛的传播，被更多的人看到、使用，从而带来了更多后续的反馈。
这也让我更加认清出我的优势 —— 虽然我可能不是最聪明的工程师，但我可能是聪明的工程师里写教程写的最好的。虽然我可能不是写教程写的最好的工程师，但我可能是写过教程，写过代码， 还做过运营和产品的工程师，非常独特。
这个项目发布于 2022 年 2 月 10 日，距离百度指数 ChatGPT 指数级别最高的巅峰相比，稍微晚了一些。但总体来说，也不算太晚，还算是峰值比较高的时候，吃到了一波流量的红利。再加上本身简单易用，得到了不少关注和 Star。
回溯 NESHouse 时期，会发现媒体的介入帮助我快速破圈。而这次我没有寻求媒体的帮助，也让我没能完美的吃到这一波红利。暂且不说能不能帮忙去推广，我没有主动推，就没有了可能，媒体老师也是很忙的。
后续还是要多去找一些媒体老师沟通，这样有了好的项目，也可以让他们帮忙推一下，对于我来说，有更多的好处。对于他们来说，也是更好的。
说实话，这个项目因为没有什么收益的点（我并不打算做一些明确的付费服务），所以我对于项目的推进并不上心，大部分时间还在看书写字，研究自己喜欢的事情。不过得益于这个项目本身难度并不大，再加上上手很容易，还是有不少朋友进来做贡献的。感谢各位朋友参与到项目中贡献 & 在群内帮助解答问题，给我留出来了不少的空间。
后续启动一个新的项目还是要快速做投入，而不是像这次这样慢吞吞的进入，如果我可以更多的投入，或许这个项目还可以更好。
做这个项目本身也只是临时起意，半夜用了一个半小时做的，再加上当时处在十分兴奋的状态，主要还是希望能够在预定时间范围内完成开发。所以其实没有太过仔细的去设计各种 Roadmap。比如，我完全可以上一次 Product Hunt 来推广一下，但当时完全没有做。
后续还是需要提前设计，或许，我应该给自己一个明确的 Checklist 清单。
以下数据均截止于 2023 年 2 月 19 日晚 21 点。
飞书群 733 人，比想象中的要多，好在是群里的大家可以帮忙互相解决问题，降低了我的群内回复的成本。
项目一周多，有接近 400 Star 。
从前一个周期的周安装量 100 + 暴涨到 1600+，可以看得出来，拉量的效果非常不错。
借着 ChatGPT 的热点，这个视频一跃成为我所有视频当中播放量第二的视频。如果从互动数据（点赞收藏投币）来看，应该是第一的视频。
展示量 13 万，参与量和链接转化都很不错。
我在开发 ChatGPT-Feishu 这个项目的时候，并没有选择使用网页版的 chat.openai.com 的服务来进行 Hack。我在社区里看到大量通过 Hack 的方式，来提供了 ChatGPT 的 API 能力。
不可否认，网页版的能力是要比其通过 API 的方式提供的产品能力更强（毕竟模型更新），但对于一个成型的产品而言，稳定是远比能力更强更重要的。能力更强，我们可以通过一些技术手段来实现 — 比如通过数据库来实现多轮对话，可能功能不够强，但确是一个明确可以演进的方向。
Hack 官方未开放的 API ，虽然可以使用，但也带来了极高的维护成本。你可能需要不停的去更新和维护未开放的 API 的实现方式，与官方斗智斗勇。
作为一个 Side Project，没必要做的那么累。
在帮 @MikeyWei 搭建 Beyond-the-World 的网站时，他希望我能够实现 Hexo 自动的部署能力，这样作为一个写作者，他可以只关注于写作（只需要复制粘贴 Markdown）本身，不需要去处理 Hexo 本身的配置问题。所以我便借助 GitHub Action 来实现自动部署，帮助他实现想要的目标。
不过，在执行过程中遇到了一个问题，Github 提示 remote: Permission to xx x denied to github-actions[bot]
但我使用的是 Github 默认的 Secret Token ，并没有手动配置，所以并没有发现有配置权限的地方。而过去同样方式又是可以的，所以可能的问题便是 Github 提供了新的配置，导致这个 Token 默认没有权限了。
仔细研究后发现， Github 的确是新增了一个配置，在项目的 Settings – Actions – General 当中，新增了一个选项 workflow permissions。你可以通过直接修改这个选项，来为你的 Flow 提供默认的读写权限。
不过，由于我不是组织的管理员，所以没办法设置，所以我选择了另外一个方式，在 Action 的 yaml 中添加了 permission 的描述，为这个 Job 新增了写权限，默认的 Token 便拥有了写权限。
ChatGPT 与聊天软件的结合会是一个不错的爆点。因为机器人的出现，可以让你在不丢失上下文的同时，完成你的工作，这样的形态会帮助 ChatGPT 快速的完成拓展。
网页版的 ChatGPT 虽然更强，但终归还是可以通过 API 来体验到的，但集成在各种工作的上下文当中，可以帮助机器人达成更强的能力。
对于 ChatGPT 来说，飞书、Slack、Telegram、Discord、Teams 来说，都有一定的空间可以用来做一些事情。
值得你去进行一定的投入。
独立开发者很大的一个问题是能力范围有限，但有了 ChatGPT，你可以成为一个更强大的独立开发者。
自立的这条 Tweet 给了我灵感。
作为一个独立开发者，我们其实会面临很多不同场景下的需求，比如我们需要写软件的更新日志、写用户教程、做活动推广，这些对于独立开发者来说，都是需要耗费精力才能完成，有了 ChatGPT，我们（可能）可以快速获得一个80分的对应角色的人，我们可以问他们各种需要的能力，从而来提升我们做事的效率。
AI 不会让专业的人失业，但的确可能会让半吊子失去了工作。但对于 AI 的用户来说，真的是科技普惠众生了。
由于我并不在大型生产环境使用 Ruby on Rails，都是在一些自己的 Side Project 上使用 Ruby On Rails，所以一直以来，我都是使用 Homebrew 来安装最新版本的 Ruby & Gem。
最近升级了 M1 以后，重新在配置 Ruby ，突然发现之前的配置失效了。在配置 Rails 时，发现报了个错： Rails is not currently installed on this system. To get the latest version, simply type:。
但我可以肯定的是，我已经执行过了 gem install rails，所以出问题的不可能是我没安装，唯一的可能便是我安装的 Rails 没有安装到 PATH 当中。
所以想要解决这个问题，只需要将我安装 gem 的路径添加到 path 中即可。
执行 gem info rails 来获取到我的 rails 安装的路径，这里可以看到，被安装在了 /opt/homebrew/lib/ruby/gems/3.2.0 路径。
使用 cd /opt/homebrew/lib/ruby/gems/3.2.0 进入到 gem 目录。你可以看到这里有个 bin 目录，bin 目录就是我们具体要用的可执行文件。
你可以执行 ./rails -v 来确认版本正确。
接下来就是修改你的 PATH 环境变量了。在你用的 Shell 的配置文件当中，加入相应的 path 配置，并重启终端，即可完成配置。
重启终端后，随便找个目录，执行 rails -v，查看其结果，来验证我们的配置已经生效。如果你可以看到类似下面的结果，则说明你的配置已经生效了～
自大学以来，我便常年在外，每年回家的时间，不过是过年那七天。其他时间，我大多在一线城市奋斗。
而对于我来说，家也成了一个陌生的词汇 —— 焦作是我家，我在焦作生长，我熟悉我家附近的道路。但焦作也不是我家， 我早已不知道家门口的商铺是什么？他们在卖些什么、他们的生活里都是什么样的日常。
对于我来说，家是我生活的地方，它可能很大，如天津我租的房子一般；它可能很小，如我在深圳住的 10 平米的小隔间。
家是你生活的地方 —— 而不是家乡的地方。你在村里修建再好的房子，可那终究不是你的家 —— 那里只有一座气宇轩昂的房子，却没有你。你在城里住的再落魄，那终究是你的家，因为它有你。
那么，为什么一年只住几天的地方可以是家呢？
继之前体验 Obsidian ，如今我在使用 Logseq 作为我的日常信息记录：
在使用 Logseq 的时候，必然会涉及到需要做数据同步的问题 —— 没有同步万一跪了怎么办？
好在是 Logseq 提供了 Git 版本控制的能力，你只需要在设置当中开启 Git Commit 的能力，就可以让其自动使用 Git 来添加版本，从而实现将你的变更通过 Git 本身的能力来记录。
当完成了 Logseq 的 Git 初始化后，自然而然的，我们便会想 —— 我能不能将其上传到 GitHub 上来完成存储？即使不分发协作，也可以很好的用来存储。答案当然是可以的，配置版本控制之后，Logseq 的仓库就是一个标准的 Git 仓库，你直接推送即可。
当发现可以推送之后，也就不担心数据的版本化问题了。那随之而来的便是 —— 我如何做数据同步？如何不让我手动上传数据到 Github 当中？
你可以借助 Git 的 Hooks 机制来完成：Github 上的开发者 CharlesChiuGit 有一个项目 Logseq Git Sync 101，其中介绍了如何实现自动的 Git 同步。
你只需将其仓库中的 Pre-commit 和 Post Commit 两个文件放置在 Logseq 目录下的 .git/hooks 目录中，即可借助 Git 自身的 Hook 能力，实现在 Commit 前主动拉取配置，避免出现数据冲突的问题，并在 Commit 之后自动推送结果，实现数据的及时上 Github。
具体操作也不复杂，只需要在 Logseq 根目录的 .git/hooks 目录下创建 pre-commit和post-commit文件即可；随后，将 Logseq-Git-Sync-101 中的文件内容复制到这两个文件中；最后执行 chmod a+x post-commit pre-commit 来实现给其添加可执行权限，即可实现在 Logseq 当中执行操作提前推送一次更新 & 拉取一次内容。
有了 Git Sync 101 ，我几乎可以不用担心同步数据了 —— 毕竟做研发的人，谁电脑上还能没有个 Git 了？
不同的人性格是不同的。
以我为例，是一个偏社牛的性格，什么活动总想去凑一下。什么样的事情都希望去了解一下，因此也造就了我什么都知道一点的习惯。对于这样性格的我来说，参与社交活动是一种享受。
而对于社恐来说，我所做的一切，可能都是令他反感的。
而现实生活中可能并不一定能总能如愿，比如可能社牛并不会被邀请到活动当中，而社恐则总是被带到各种不同的场合当中去锻炼。
社牛和社恐都不能如愿，这大概就是社会与个人预期的错配。