随着手上要维护的内容越来越多（3个官网，2个系统，1个小程序，全部是前后端分离且数据库独立的项目），出现了很多做1次不费事，但是穿插着做很多次非常乱的工作。我之前已经尝试过用Github进行 CI，这次学习和实践了一下 CD。

在生物信息学绘图中，我们经常需要处理包含成千上万个数据点的图形，例如单细胞RNA测序的散点图。这类图形在保存为PDF等矢量格式时会面临文件过大、渲染缓慢的问题（除了AI其他软件基本都会直接死机），因为矢量图会记录每个数据点的坐标、颜色、大小等属性，导致PDF文件包含大量对象，进而影响查看和编辑的效率。

在 CI/CD 流程中，依赖管理往往是决定构建效率与可靠性的关键因素。最近，我在一个静态网站部署流水线中尝试了 setup-pixi 这个 GitHub Action，

啊, 没想到plotly这么多年了, 还是稍微一用就能触到它的能力边界, 之前是画不了时间轴图, 这次又发现地图的Marker自定义程度不够…

在使用devpod一小段时间后, 我确定, 我还是需要一个能不依赖容器, 直接通过ssh在宿主机上自动安装vscode, 然后把端口转发回来的工具. 于是我开始白嫖Copilot来给我解释devpod的代码…

短时间内，我碰到两次需要修复R函数Bug的情况了，也顺便学习了一下如何进行热替换…

只要活的够久，就会见到足够多的囧事情。

从事生物信息分析，研究方向越前沿，就要面临越多来自信息侧的问题。即使是文章发的非常好，原作者共享了代码，甚至写了现成软件工具，也不代表我们能轻松顺利的用这些现成的东西来复现或进行研究，混乱的环境设置只是一方面，更多时候，由于软件作者并不是专业的软件工程师，工具功能大致能用已经谢天谢地了，不能奢望这些软件没有一点毛病，更不能奢望有性能可言（除非开发时性能被来就是开发点）。即使这工具来自于有实力的大实验室，很多时候也不能幸免，比如… Azimuth。

我一直有下班骑车路上听视频的习惯，这周听到了差评讲 RISC-V 的视频。视频中提到一个观点：RISC-V 作为一种指令集架构，基于它的芯片产品存在严重的碎片化问题，导致应用生态发展面临很大困难，因此必须解决碎片化问题，通过统一标准才能实现快速发展。这个观点让我联想到多年来使用 Linux、安卓以及 R 语言的经历，我觉得视频中的说法可能并不完全准确。

我还是挺喜欢现在的 hexo 主题的，从 2021 年使用它的前身material-x，到2023年升级到 Volantis 5.x，主题的功能已经完全满足我个人的需求了，以至于没有继续升级作者后续的6和7了。不过上半年利用 AI 对博客进行批量英文翻译后，一直有一些界面元素还是中文的问题。今年就不大动工，直接在 AI 指导下自己动手修一修。