2024-10-27 22:59:30
动漫《虫师》中，有一种会吃掉声音的虫，这种虫会导致宿主什么都听不到；还有一种会释放声音的虫，会让你的耳朵里充斥着各种声音，让人在声音的嘈扰下无法好好休息。
最近这几天耳朵又开始嗡嗡响，心说遭了，我的耳鸣又复发了。这几天只能早早睡觉，不敢再熬夜了。
倒不是危险耸听，我也没有经常耳朵塞个耳机一直听歌，但我好像这辈子都要笼罩在耳鸣的阴影之下了。
两年前，在我还不清楚耳鸣这个名词之前，我熬夜是比较随意的。
凡此种种，一不留神，就跨过了凌晨这个熬夜的门槛。
持续最久的时候，可能会连续好几天都在熬夜，结果就是右耳朵开始嗡嗡响，也就是所谓的 “耳鸣” 开始折磨我。
可能很多人没有经历过耳鸣，我简单说一下，我的属于神经型耳鸣，以我浅薄的理解，就是硬件（耳朵、耳膜）没有任何外部损坏，出问题的是耳朵到大脑的神经传导部分。我能感觉到的就是：耳朵一直在响，类似有人一直在我耳边 ‘滋滋滋—’。
如果你想知道是什么声音，那可以找一个安静的环境，用手捂住你的耳朵，完全捂住之后，耳朵是不是可以听到一些低沉的嗡嗡声？耳鸣声，就跟这个声音类似，但是声音更尖锐。
最开始我还不以为然，因为带上耳机后，这种声音就基本上消失了。
但又过了两天，耳鸣声音越来越大，戴上耳机也消除不了了，更恐怖的是，两只耳朵听歌的时候，音乐的音量在我听来已经不一样大了，耳机没有坏，那就是耳朵坏了，我赶紧去医院检查。
在医院耳鼻喉科做了详细的听力测试，结果如我所料 — 神经性耳鸣，听力已经损耗很严重了。
心里开始害怕，问医生：有办法治好吗？
医生的回答是：大概率能治，但没办法完全治好。而且因为是神经性的，需要用到激素治疗，每个人体质不同，激素作用效果也因人而异，所以需要多次复检来调整激素用量。
放在大腿上的手开始微微发抖。
医生这时又警告我：近半个月，不准听歌，绝对不准熬夜和加班，神经性耳鸣最忌讳的就是熬夜和劳累。
肯定很多 “肝帝” 说：我天天熬夜玩游戏也没啥啊，怎么你这么菜？
确实，我也这么问医生的，毕竟谁高中大学没有经常熬夜，怎么我之前天天通宵去网吧也没事？
医生也帮我分析了一下，大概意思：最近是不是工作上的压力比较大？神经性耳鸣都有一个发病的临界点，当你的压力突破了这个临界点，就会开始触发神经性耳鸣，熬夜会加重你耳鸣的程度，但不是你发病的原因。
我突然想起我最近，我的确是被公司外派到某个项目现场出差，白天调试设备，晚上盯生产，连续干了两天，每天工作强度在十八小时以上。
现在想来，可能在现场超负荷工作的时候，耳鸣已经开始了，只是现场设备 80 分贝的工作环境下，我又怎么可能听得到耳朵的嗡嗡声呢？
出差回来之后仅仅睡了一个懒觉，白天继续上班工作，晚上又熬夜看信息流，看小说，“恶补” 我出差时没能享受的信息流洗礼。这一系列的操作下，神经性耳鸣，发作了。
回到现在，正如当时治疗我的医生所言，神经性耳鸣无法完全治愈，当我每天可以获得正常的休息时，耳朵是比较正常的。
但当我开始熬夜，哪怕只是跨过了凌晨这个槛，第二天起床，耳朵就一定会开始嗡嗡响，如果我第二天晚上还不收敛，第三天醒来，耳鸣的声音还会越来越大。
而想要完全恢复这个耳鸣，就要持续一周以上的充足睡眠，也就是说晚上十一点之前就要熄灯睡觉，这对于生活在 21 世纪当下的我来说，确实不容易。
但我不得不这样做，因为熬夜要看的东西，第二天可以找时间看，但听力如果丧失了，那我失去的就太多了。
希望我的经历，对大家有所警觉，也希望大家除了努力工作，也要好好注意自己的健康。
2024-09-09 18:40:12
上周在公司突然接到一个电话。
喂，是 X 先生吗？
是
我这边是 XX 云，工号 XXX，您名下有一个 gadore.top 的备案，经查证该备案的服务没有运行在国内，需要您迁移到国内，否则将会吊销您的备案；还有您的备案号悬挂格式有误，末尾少了一个 “号” 字，请在 30 天内完成整改，否则将会吊销您的备案许可。
你是 XX 云的还是工信部的？
我是 XX 云的，以上也是根据工信部要求进行的排查。
哦，那我不要这个网站了，就这样吧（很颓废的声音）
嗯……（可能这家伙被我的态度搞蒙了），先生我可以先取消您的网站备案，稍后您有需求再重新备案就行了，有什么疑问都可以再咨询我们。
行吧，无所谓了
之前备案的动机是为了开通国内的服务器的 80 和 443 端口，为了给我的一些线上服务提供必要的方便的。所以就算流程复杂我也一步步走完了域名备案和公网 IP 的实名认证。
但现在，域名需要备案、网站需要备案、开端口需要备案、上架 App 需要双重备案（App
要备案、后端服务需要再备案一次），还要求所有服务必须运行在国内的服务器上？？？
国内服务器有 Github 这样全功能的托管平台吗？有 Cloudflare 这么好用的 DNS 厂商吗？是我不愿意用回国内吗？
那假如作恶的人有 1 个，非作恶的人有99个，这样麻烦 99% 的人真的划算吗？
2024-08-11 05:29:52
这是我的上一篇文章iPhone 5 在 2023 年生存状况报告的 DLC 更新，毕竟对于现在的人来说，手机最最重要的工作，除了让你听歌、聊天、刷新闻、等任务之外，还有一个高频的使用场景：看视频。
先上结论：当然能。
我自然不是说那种使用 iTunes 或者是用 USB 线、无线网拷贝视频文件到 iPhone 5 上边，这谁都能做到。
当然，iPhone 5 推出这么多年，而最经典的 iOS 6 系统也已经停更了这么久，能下载到的运行在 iOS 6 系统上的在线流媒体平台也都基本上不能用了，包含但不限于我们常用的 B 站、爱优腾等。
那我还做了什么尝试呢？
该方法使用的前提，是你需要有一个类似 NAS 的设备一直在线，为你提供稳定的视频来源。
而配合 WEBDAV 协议的 GoodPlayer ，也是我最近找到了兼容性和流畅度最好的视频播放器。
可以看到，它实在是支持太多协议了，各种意义上的神～
读过我的上一篇文章的自不必多说，对 Reeder 这个 RSS 届的老大哥肯定很耳熟。
而借助 RSSHub 的帮助，我就可以直接在 Reeder 中订阅我想看的视频博主，进而可以直接在 Reeder 中在线观看视频。
可以从顶部进度条看到正在进行的缓存进度条，它真的还可以正常查看在线视频！
已经第 N 次向大家推荐 RSS 了，毕竟这是一个可以让我们主动去决定信息来源的东西，每一次在关注的博主那里关注到新的有趣的新闻源、博客网站的时候，手动把他们的 RSS 链接加入到我的 RSS 订阅中，会感觉非常有仪式感。
与之相反的就是各种算法推荐的泛资讯的信息爆炸，让人看着上瘾，不停点击下一个，期待算法能推荐更多感兴趣的东西。
我很反感后者。
2024-07-02 03:31:53
小的时候没有智能机和游戏机，我就跟同村的伙计天天在外边疯跑，直到其中一个人发现各家各户的烟囱都在冒烟做饭了，我们才悻悻散去，各回各家，我妈为了杜绝我这种一出去玩就不知道回家吃饭的行为，给我买了第一块表，告诉我记得看时间回家吃饭。
它便宜，耐摔，走时精准，一定程度上也很防水，从现在的眼光看来，也是一个性价比非常不错的手表。
从上学开始，学校的铃声就代表时间，下课铃响，回家吃饭，替代了手表的功能，手表也逐渐被我所淡忘，这种情况一直持续到大学。
虽然大学的每个月生活费只有两千块钱，但我还是从牙缝里抠出了点儿钱，买了人生中的第一款机械手表。
它支持自动上链，有可能 30 小时的动储，而且还有背透，可以看到机芯运作时的样子。
「商品图片找不到了」
这款表也陪伴我了一两年的生活，但有一次好像是下雨的时候沾水较多，这种价格水平的手表，根本就没有任何防水的能力，表镜表面很快就覆盖了一层水雾，机芯也随着进水而变得更加不准，只能留在抽屉里吃灰了。很遗憾，他没能跪碎我走到毕业。
对于学习计算机专业的人来说，科技设备还是非常有吸引力的，我也在大学期间和毕业后也先后买了几款智能穿戴设备。
大学期间正好是国内智能手机和智能穿戴快速发展时期，小米手环一代当时发布的时候对我冲击还是挺大的。
什么？只要几十块钱，就能检测我的跑步运动量？买了买了。
买回来好像是带了不到一个月，开始吃灰。
现在想来，应该是带着它不够酷吧，哈哈。
毕业两年后，我开始心水 Apple Watch 这款设备了，因为当时的 Apple Watch 居然可以脱离手机独立使用了，这是什么特工 007 专用设备！！！必须买！！！
买回来后我也带了相当长一段时间（有一两年）
Apple Watch 仍旧是当前最为先进的民用穿戴式设备的最优秀产品，但它也有非常致命的缺陷。
这个大家都懂，Apple Watch 系列是续航非常差的一款产品，设计之初就没有考虑长续航的场景；况且它使用的是磁吸式充电方式，我戴着它出了两次差，需要分别带着我的 Lighting 线给 iPhone 充电、带着磁吸充电线给手表充电，带着 Type-C 充电线给电脑充电，体验一次就够了，关键我体验了两次（两次出差），这也就让我下定决心以后再也不在出差的时候戴它了。
戏剧性的是，出差不戴它之后，我平时生活也不再习惯再戴了。
虽然手表可以通过开通 esim 来使用流量，但它的逻辑是：如果手机在附近，优先使用蓝牙连接手机，使用手机的网络进行信息通信；如果手机不在附近，那就使用 wifi 来连接互联网，如果手机不在附近，也没有 wifi 的情况下，再使用 esim 进行流量通信。那也就是说，大部分情况下，这个手表的存在，都会极大消耗我的手机电量。
想想我的手机吧：iPhone 12mini，iPhone 家族里续航最差的一代。
既然手表褪去了科技的光环，那如果它足够好看和时髦，也可以当成一种装饰物戴在手上啊，但，它真的还时髦嘛？
光是我身边的同事就有三个戴着它。
被智能腕表折腾的 PTSD 之后，我又回想起了非智能腕表的好了，它虽然没有各式各样的功能，但考虑到我们去到任何地方都需要手机，智能腕表的功能几乎都可以被手机所替代，而非智能腕表这两年大有复兴之意，前有 Swatch，后有卡西欧，在时尚界各种明星联名。
这是我重新审视机械腕表后买的第一款手表，从表款也可以看出，我有点儿冲动了。
Prospex 罐头系列是精工的潜水系列腕表的明星产品，但作为我步入工作的第一支机械腕表，我应该更多关注腕表的休闲属性和佩戴舒适性的，而不是他的 “防水 200M”，我猜测我可能是因为第一支机械腕表因为防水能力过弱，从而在潜意识里想买一个防水性能好的手表吧
购入一块精工腕表，几乎把我对机械腕表的爱消磨殆尽，为了防止这类事件再发生，我打算购入一款不同类型的腕表先抚慰一下我被精工伤透的心，这时候我就看到了它：卡西欧。
记得小时候买了故事会等报摊杂志的时候，我都会翻到购物页看一下机械手表区域的各种新表，当时看到上千块上万块的机械腕表，小时候的我就在内心感叹：什么时候才买得起这种手表啊？
日子还长呢，如果你看到了这里，也喜欢腕表，那就评论、关注我吧，本站后期会不定期更新更多腕表相关的文章的。
2024-05-31 18:46:59
长期主义？我？哈哈哈，先看两年吧。等我到时候没放弃的时候，那应该可以 review 一下。
在 2020 年刚开始疫情封控的时候，我也被封在家里了，那段时间公司也没办法展开任何业务，所以我就开始寻找一些能消磨时间的事情做，学习 SwiftUI 在我看来就是一个不错的契机。
但在当年的时间节点，ChatGPT 还没出现在大家的视野，SwiftUI 本身也一大堆问题，很多地方还需要 UIKit 来解决问题，所以当时学习的时候也非常的痛苦，更不要说当时 SwiftUI 的文档也是一坨，但在被封控的这段时间里，好像也没那么难地去攻坚下去，算事因祸得福吧。
当年开发了一个多月时间，也磕磕绊绊地开发出来了一款 App，「农小记」，功能超级简单，但它免费、轻量（安装包不到1M）、没广告，你现在依旧可以在 App Store 下载到（非国区才有）。
从 App 的名称来看，大家应该也大概猜到了它的主要使用场景，在这种场景下其实同类型应用特别多，倒数日、生日提醒、Happy Days 等等，我为什么还要单独开发一个这样的产品出来呢，首先，在 2020 年刚开始开发的时候，作为练手项目，要么就是笔记类软件，要么就是 TODO 类软件，要么就是番茄时钟，没别的选择，再选的话上手难度就太高了。
但其实当时我第一个目标是做一个网易云音乐第三方，这个另找时间再聊吧，都是泪。当时名气比较大的就只有倒数日这一家，而且当时他也没办法设置一项生日记录循环计算下一个生日的到期时间，而且倒数日在当时的小组件只能显示一个日子，我就想做一个显示列表的，一切好像都很合理，诉求也很简单，那就开始做吧。
我在 2020 年刚开始开发第一版的时候，其实同类型产品（我能搜索到的）还不算太多，跨平台的同时提供云同步的更是只有倒数日一款，再说倒数日的那个 UI 真的欣赏不能，但它免费，你还能说什么呢。
当时间来到了 2024 年之后，虽然在 iOS 平台上，跟我功能类似的产品已经非常多了，很多产品的 UI 和精致程度已经超过了我这款，但大部分产品是跟苹果平台强关联的，脱离 iOS 平台就无法使用了，这其实也是我第一款产品的问题，2021 年当我的苹果开发者账号到期之后，我预感接下来一年可能没时间继续开发这款产品，就没有续费开发者账号，于是你猜怎么着，之前曾经下载过我 App 的人，也无法使用 iCloud 进行数据同步了。。。苹果，你下架我的 App 我能够理解，但你直接禁止已经下载的用户使用 iCloud 同步这一点，就不太地道了吧。
所以我在对第一款产品升级的重点，就是要做一款长期主义的 App。
我做的时候，做一切决策，只考虑一个问题：这个 App 如何稳定使用 10 年，即使我已经不再做开发者，用户依旧可以正常使用？
考虑到苹果 CloudKit 这个大坑，云同步肯定不能用了，更何况如果后期我要开发 Android 平台，更没发对接 iCloud，最开始我使用的是 fastify 框架，这样的话就要接数据库，就需要租服务器，这样的话，成本就非常大了。而当我接触到 Cloudflare D1，我就知道，我必须要用，这真的太棒了！
简单来讲，D1 就是基于 Api 的数据库服务，你只需要写好接口层的内容，然后交给 D1，一切就都就绪了，它不是一个实时运行的服务，但当你访问指定的路由时，D1 会根据路由找到指定的执行文件，执行后发给你执行结果。他有日 10W 的免费调用额度，5GB 的存储空间，对于一个记录和同步用户生日和纪念日的信息来说，绰绰有余了，即使后期用户群起来了（大概率不会），也可以通过简单的弹性套餐来增加调用次数和存储空间，这太适合低成本的 Startup 项目了！
同样的，自从被苹果 CloudKit 坑过之后，我算是 PTSD 了，其实如果我能继续使用 CloudKit 的话，那第一版 App 的大部分逻辑代码都能复用，我只用重新写写 UI 装饰一下就好了，但既然后期有 Android 版本，所以干脆在移动端就用 SQLite 了。
其实在开发到一半的时候，Flutter 是一个更优解，因为可以一套代码多平台发布，但整个项目毕竟是从学习 SwiftUI 开始，所以也舍不得放弃当前已经构建了 80% 的 iOS App，所以下个产品，一定直接走 Flutter ！
BB 了这么久终于要说功能了
中国生日用农历，所以肯定要兼容的，但结婚纪念日、恋爱纪念日这种，正常使用公历的当然也要支持。
这里小小吐槽一下，SwiftUI 的 bug 真的奇奇怪怪的，他自带 DatePicker ，并且可以指定为 LunarCalendar，但不同的SwiftUI版本，在使用这个组件的时候，实际的展示效果千奇百怪，这种 bug 真的把我逼疯了，我只好自己做一个 LunarDatePicker。
同时支持苹果和安卓端的应用我知道的只有倒数日，但它的小组件真的一言难尽，所以这也是我打算开发多端的重要原因，希望我可以开发一款好看的安卓小组件吧～
如题，无须多言，国内备案实在是太恶心了，所以这款 App 近期不打算上架国区了，等以后再说吧。
如题，同样无须多言，因为使用的 XCode 工程标准的多语言支持方式，所以后期适配日语啊、德语啊，也是非常轻松的。
作为一个以长期主义为主要宗旨的 App，云通知的方式是万万不行的（主要是云服务器计算压力比较大），那在 iOS 本地的 LocalNotificationSchedule 就非常香了，它是可以在本地预约通知的 Api，估计很多通知笔记都是经过这个 Api 进行开发的。
但我现在还不知道 Android 有没有类似的接口来实现（找到了，有方式实现），毕竟 Android 实在是太乱了。。。希望有吧。
iOS端：App Store
Android端：新建文件夹中，可能需要一段开发时间。
只要用户量在当前 Cloudflare 免费调用额度以下，那就可以永远免费地使用下去，如果用户量激增（怎么可能），那就是早用早享受啦～