有很多人说了很多俗话，听了很多俗话和道理，但总也活不出理想的样子。有俗话说预则立不预则废，即使知道俗话没啥用，但辞旧迎新之际，总是想做一些回顾和畅想。
人总是健忘的，所以回顾到的不好，即使有一时的悔悟，对未来有所影响的概率也不大。同时，人也是贪婪和懒惰的，所以在做计划的时候总是高估自己，而在执行的时候，也总是拖沓。
再次把话说回来，即使如此，有时候，回顾和预想总还是能安慰和激励一下自己，无聊的生活总归是需要一些目标和仪式感的。
回顾总不好意思写一些吹捧自己的话，同时一些不好的话总也不想暴露人前，那么就只好写一点未来，这些都是好的，总归写起来没啥压力。
那么25年，期望的自己是什么样子的？面对贪婪而懒惰的人性，怎么解决问题？

引用来源

https://shiru99.medium.com/eye-tracking-with-arkit-ios-part-ii-2723f9bfe04e

https://github.com/Shiru99/AR-Eye-Tracker

https://github.com/virakri/eye-tracking-ios-prototype

ARKit运行简单介绍

使用ARKit追踪眼睛注视点，主要是使用 ARFaceTrackingConfiguration 、ARSession、 ARSCNView，主要的逻辑是ARSession提供了运行ARKit的环境，ARFaceTrackingConfiguration 告诉ARSession想要识别人脸，我们可以监听ARSession回调函数来获取人脸识别的结果，比如脸部位置，眼睛位置，眼睛注视点。而ARSCNView本身携带了ARSession，他继承了SceneKit的SCNView 用来展示相机拍摄到的内容和ARKit识别到的结果。

ARSession的回调会告诉我们识别到脸部的位置，眼睛的位置，注视点的位置，那么我们需要做的就是在手机屏幕上显示这个注视点，逻辑上很容易理解。那么难点在哪里？

为navidrome上传mp3之后，发现有些音频是有歌词的，有些没有，有点奇怪，就去看了一下github上navidrome上是怎么获取歌词的。

最简单的方式，当然是从api开始，追查的过程略去不讲，只说结果：

1. navidrome会通过监控文件目录的变动以及手动触发的方式，去遍历目录下所有音频文件；
2. 找到音频文件后通过ffmpeg或者taglib来获取音频文件的元数据，扫描后的信息会存储到数据库中；
3. api会查询数据库来响应请求；

桑基图（Sankey Diagram）是一种用于可视化流动和比例的图表类型，常用于展示能量、物质或成本在系统中的流动。它以其宽度可变的流向箭头来突出各个流动的相对大小。

主要由节点和流来组成，流的宽度表示流量大小，流动方向通常上是从左向右。通常上，最左侧节点的流出量相加等于最右侧节点的流入量。

这是一个很常规的桑基图示例：

最近遇到一个问题，需要跟其他小伙伴对齐一下环境，我就运行了pod install和pod update。结果发现，前者什么都没做，而后者却安装了一个依赖的新版本。 结论是： pod install 会检查 Podfile.lock文件，这个文件会列出依赖对应的具体版本和CHECKSUMS，也就是说不仅仅是版本，相当于指定了对应的commit了。 pod update则是会忽略Podfile.lock指定的内容，直接去更新依赖的最新版本，同时会修改Podfile.lock。 也就是说Podfile.lock和Podfile一样很重要，是必须要提交和保持一致的文件。

调试iOS应用的时候，编译成功，安装app到设备也成功，启动app也成功，但Xcode自动结束调试，报错如下：

Could not attach to pid : “20860”

attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries, when the attach failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)

最近碰到个在 ReactNative 里面使用 SSL pin 的坑，困扰了我许久，解决后记录下。

什么是 SSL，安全性怎么保障

https 我们很熟悉，iOS 是默认强制使用的，https 本质是运行在 ssl 加密通道上的 http，核心是 ssl 加密。ssl 加密是通过服务端下发共用证书，协商好加密方案后建立的加密通道。 安全性是通过系统内置的知名 CA 的根证书，与建立 SSL 通道时候，服务端下发的证书链进行比对，来保障。这里默认 CA 是可以信任的，那么 CA 签发的证书就是可信的。CA 下发的证书可以跟 CA 的根证书形成证书链条，用以进行证书有效性确认。安全性得以保障。

关于环境配置这个问题，其实这个问题折腾过很多次了，但每次都踩坑，可谓是坑坑不一样，一坑更比一坑深。

记录这个也不是刚发现，而是为了打自己脸，每次一碰到问题，就无脑冲，折腾了一万年的时候，发现还是这个方法香。但这个方法是自己用过无数次的啊。

作为独立开发者或者说小型开发团队，不大可能像大型团队一样在运维方面走比较安全但同时相对复杂的运维流程，但同时又需要一个相对灵活稳定且具有一定安全性的方式，来跟服务器服务进行联通。这时候，加密通道在这个场景下可能是比较好的解决方案。

虽然不想说，但这次部署的方式确实有点难受的。 之前博客部署在DO的vps上，但这台机器资源比较有限，经常会碰到运行一段时间后因为OOM被系统干掉的情况。 然后想说部署在aliyun的机器上，但问题是域名解析过来，需要进行个人备案，我不太想这么操作，避免后续某个时间这个域名不用的时候，备案还在我的名下。 我还有另外一台机器，也不需要备案，资源也算充裕，但问题是那上面运行的服务后续可能会膨胀，如果不膨胀，大概率是要删除的，又不稳定。 嗯，背景就是上面讲的这样。于是一个很诡异的逻辑诞生了： 在aliyun的机器上部署hugo运行服务，开放端口；博客域名解析到DO的vps上，流量通过nginx转发到阿里云的机器上。