用了差不多五年了，博客的样式和功能都有些落后了，所以决定稍微改进一下。
本来想用按照这个 打造 Github Issue 到 Hexo 部署自动工作流 来改造，也很喜欢 github issue 这样的形式，既解决了评论和图片的问题，又解决了博客的部署问题。
但是想想编辑有点麻烦，还必须用网页登陆，没有顺手的编辑器，所以还是在原来的基础上进行改造。

基于 github 的评论

使用 o1 翻译，然后稍微整理下。

翻译

之前项目用过但是是针对 ios 和 android 的，现在需要针对 web 的，所以需要重新记录下。

deploy

看来新的项目有用到之前没用过的库，所以需要了解一下。

各个状态库描述

source_gen:combining_builder on xx.dart:xx.g.dartmust be included as a part directive in the input library with:

经过一个多小时的 chatgpt o1 和 claude 3.5 sonnet 的轮番使用，都没解决的问题，最后靠 4o 的联网能力解决了。

描述下，其实从人的成长轨迹来看，达到最成熟的人具有的一个品质，成长肯定是一个类似的轨迹，你当下的疑问其实代表了你的当前的高度，如果疑问有了答案，你就潜入了下一层次的成长，如何描述这个过程，又说最成熟会是一个什么样的状态和答案

cloude normal

一年一度的换套餐服务开始后，有一点额度可以提前来个 mini。稍微记录下过程，友都八喜的 point 和 switch 换购然后現金。

选择

研究了一圈 x 的 api，有点不合适，还是用开源替代方便。

一句话总结：

本来名字是 2025 小目标，但是感觉有点小，有点涉及某些梗，然后想成 2025 特重大目标，有感觉太俗，随后改成了 2025 的目标，平平淡淡才是真。

目标

工作中用了m2的macbook pro，然后使用了一个虚拟机 virtualbuddy，虚拟macos还是挺好用的，所以记录下基本的装机流程。

常用

也是借着 GitHub Copilot 免费额度的东风，我最近开始尝试自定义 Git 的 Commit Message 格式。这样可以让团队的 Commit Message 更加统一，也方便后续的代码 review 和版本管理。
这里顺带说下，这个东风也是靠着 cursor 等的竞争，而且截止到今天 2024-12-24，自动生成的功能确实离 cursor 差的不是一点点，尤其是上下文的能力。
比如一个变量的修改，width 和 height，如果你改成了 aWidth，基本上 Copilot 只能识别到一行也就是光标行的内容，而 cursor 可以识别到后续三四处的地方，这个差距还是很明显的。更厉害的是，还没移动到紧接着的 height 行，也是改成 aHeight，Cursor 就已经能识别到了，这是代差啊。

目前 GitHub Copilot 并没有提供一个「一键式」的配置项来固定生成某种格式的 commit message，但我们可以通过一些技巧来“引导”Copilot 生成符合预期格式的提交信息。

之前项目用过provider，但是最近看到riverpod和GetX也很火，所以想对比一下这三个状态管理库。

下面我们用「计数器」这样一个简单的例子，分别展示 Provider、Riverpod 和 GetX 在 Flutter 中如何做状态管理，并在最后进行对比总结。这些示例都力求最小可运行，方便你快速上手。

我们来“抽丝剥茧”地分析一下 _updateTransformation 方法是如何工作、为什么要这样计算，以及其中涉及到的数学原理（主要是平面几何、线性代数的知识），并在此过程中看看它是如何帮助我们在 Flutter 中实现「可缩放和可平移」的功能。

libgo.so not found

flutter 项目运行安卓版本的时候，Failed to load dynamic library ‘libgo.so’: dlopen failed: library “libgo.so” not found
需要编译 go 模块

貌似 aws 的所有 api 都要经过 api gateway，从 api gateway 到后端服务，可以有多种方式，比如 restful 接口，websocket 接口，lambda 函数，s3 等等。

aws 里的 api gateway socket 的 gate 有两个 url