Mobility

背景：一个繁琐到让人崩溃的任务最近想给自己的 Hexo 博客换个主题。用了好几年的 Next 主题，虽然经典，但想换个更现代的风格。 看起来很简单对吧？但实际操作过的朋友都知道，Hexo 主题迁移是一个极其繁琐的过程： 配置文件长达 1000+ 行，需要逐项对比新旧主题的配置格式 功能映射复杂：Next 的 leancloud_visitors 对应 Butterfly 的 busuanzi，Next 的 reading_progress 对应 Butterfly 的 preloader 两个站点要同步：中英文站都要改，而且配置略有不同 Font Awesome 版本兼容：Butterfly 默认配的 FA 7.1.0 根本不存在于 cdnjs YAML 格式敏感：缩进、换行符都可能导致配置失效 如果手动操作，估计要花一整天，而且很容易出错。 解决方案：让 AI Agent 来干这次我尝试了一个不同的方式：让 AI Agent（Hermes）全程接管这个任务。 AI Agent 的工作流程整个过程，AI Agent 自主完成了以下工作： 环境分析：检查当前 Hexo 版本（...

前几天写了篇新文章，照常往 Vercel 部署，结果 pipeline 直接报错了。一开始以为是构建问题，折腾了一会儿才发现不对——是 Vercel 账号出了状况。用 163 邮箱注册的账号怎么都登不上去了。后来才搞清楚，Vercel 把整个 163.com 邮箱根域给封禁了。 先说说 Vercel 是什么如果你是搞独立博客的，大概率听过或者正在用 Vercel。简单说，它是一个前端部署平台，支持自动从 GitHub 仓库拉代码、构建、部署，给你的网站分配一个域名，还自带 CDN 加速。很多人的博客就是 GitHub Pages + Vercel 的组合——代码放在 GitHub，用 Vercel 来部署和托管。 我自己的博客也是这么搞的。GitHub Pages 本来也能直接部署静态页面，但 Vercel 在自定义域名、HTTPS、CDN 这些方面用起来更方便，所以就选了它。 163 邮箱被封禁的来龙去脉大概在 2026 年 5 月 4 号左右，大量使用 163 邮箱注册 Vercel 的用户发现，自己的账号突然无法登录了。我在网上搜了一下，发现不只是我一个人遇到这个问题。...

最近在整理团队的安全开发规范时，遇到了一个老问题：安全规范文档越积越多，但真正用的时候却找不到。每次新人入职，都要翻遍各种文档才能拼凑出完整的安全规范；每次出安全故障，事后总结的经验也散落在各处，下次遇到类似问题还得重新排查。 我试过用Confluence、Notion、甚至Git仓库的README来管理，但效果都不理想。直到看到了Karpathy提的llm-wiki思路，才觉得这可能是个突破口。 Karpathy的llm-wiki是什么？Karpathy在Gist里提了个想法：让LLM维护一个Wiki中间层。原话是”the wiki is a persistent, compounding artifact”——这个Wiki层就像个编译器，把原始文档编译成结构化数据，这样LLM每次回答问题时就不用从头在原始文档里”找”信息，直接查Wiki就行。 我觉得这个思路特别妙。传统文档管理是”存”和”找”，而llm-wiki是”编译”和”查询”。原始文档可能很乱、有重复、甚至有矛盾，但Wiki层是干净、结构化、有交叉引用的。 举个例子：我们团队有十几份安全开发规范文档，从输入验证到渗...

后端工程师开发前端的痛点，通常来说莫过于太过繁琐，经常要为了一些很小的事查半天。Vaadin很好的解决了这个痛点，为后端工程师提供易上手、方便使用的前端代码编写解决方案，今天我们就来了解一下。 大家好，今天跟大家介绍一个对后端工程师特别有价值的工具——Vaadin。 说起来，上手前端基本的html, css开发，确实并不难，但是如果只会这些基本的东西，开发起来会很繁琐。如果想要使用前端生态中的各种轮子，虽说便利度提升了，但学习成本也会同步上升。所以，如果不是职业的全栈工程师，只是作为一个后端，想临时写点前端代码，比如自己想做点小项目，通常来说都会有个很痛苦的过程。 Vaadin很好的解决了这个痛点。通过vaadin包装好的常用前端组件，我们几乎可以零学习成本的编写出功能完备、不太难看的页面。对于后端背景的程序员来说，无疑会大幅度降低自己做些小项目的成本。 Vaadin提供的功能，就是可以直接用java代码来写页面。Vaadin提供了多种输入框、表单等等封装好的前端样式，而且与springboot做了深度的融合，使用起来非常方便。 Vaadin的实际原理并不复杂，主要是基于服...

对于hexo的多语言方案，官方并没有提供很完备的支持，但是网络上有很多人尝试过不同的解决方案。今天，我们对这些方案简单做个总结，看看我们需要的多语言方案是什么样子的。 其实，hexo的多语言方案，说白了就是两个思路，一个是在文章维度切换语言，借助hexo原生的能力和hexo-generator-i18n等插件，用一套框架维护两个语言的内容；另一个则是独立维护不同语言的样式、内容，在站点维度切换语言，只是在域名层面合并到同一个域名。 具体要选择什么方案，取决于大家想要一个什么样的多语言网站。一开始我想象中的多语言网站的是第一种，即统一的首页，在首页和每篇文章上都支持切换语言，对每篇文章，可以通过切换语言，直达对应的其他语言译文上。 这个思路，借助于hexo-generator-i18n插件，可以实现，但要做比较多的定制开发。所以，我又重新思量了一下思路，我要的多语言网站应该是什么样。重新考虑之后，逐渐觉得第二种思路才是更合理的。我们要做一个多语言网站的目的是什么？对我来说，其实就是要获取一些英文流量。作为一个未备案网站，已经很久无法获取百度的搜索流量了，google在中国占的份...

一个优化知乎显示的油猴工具 之前在 小众软件 上看到一个知乎评论区时间展示混乱的吐槽，有大佬立刻就给了一个油猴脚本。 用了一段时间很舒服，然后前几天知乎做了个更新，导致展示开始混乱。研究了一下，做了更新，想着就发布到GreasyFork上吧，后边知乎再有调整，可以直接从线上更新。 脚本地址： 安装地址 大家感兴趣的话，欢迎留言，后边考虑做个油猴脚本的开发教程。 原文地址: http://lichuanyang.top/posts/44912/

这篇教程不会关注 kubernetes 的部署、架构、实现方式等内部原理，而是完全从一个使用 kubernetes 的开发人员的视角去介绍kubernetes是什么，从而帮助了解如何更好的去利用 kubernetes 的特性。 基本介绍对于kubernetes是什么，一个比较官方的定义，Kubernetes是一个开源容器编排平台，管理大规模分布式容器化软件应用，简称为k8s. 通俗一些来讲，k8s 的核心理念是以应用为中心，向下屏蔽基础设施的差异，向上通过容器镜像实现应用的标准化，帮助开发人员在仅需关注应用本身，无需考虑部署、容灾、伸缩等运维细节的情况下，开发出大规模、可靠的分布式应用。 优势如上所述，k8s的核心优势就是降低运维成本，让应用开发人员能够专注于应用本身。具体来讲，包括如下几点： 便捷的部署流程和大规模的复制分发能力：应用提供标准化的容器镜像，之后的部署发布流程都可以做到自动化；应用也无需再做更多的事情就可以实现跨平台、跨区域的部署。 服务自愈能力：自动摘除不健康的节点并做恢复。 敏捷的自动伸缩：根据设定的系统负载，做快速的自动伸缩，实现系统处理能力和成本之间...

知乎是个什么样的网站，大家都比较了解，今天我们分享个小工具让我们更开心的使用知乎摸鱼。 之前我在看我自己账号知乎数据的时候，发现一个挺有意思的事情，就是PC端的流量居然有40%以上，这在移动互联网时代，简直是不可想象的。后来也从一些其他渠道了解到，知乎周末、节假日的流量是不如工作日的。 这说明什么呢？上班刷知乎的你，不是一个人。对相当一部分人来说，知乎主要是在上班摸鱼的时候使用的。 知乎这个网站，的确挺适合摸鱼，毕竟以文字内容为主，而且还有相当多的专业性内容，所以工作时上知乎还真的有可能是在查资料。 但是，知乎有些小体验，对摸鱼就不太友好了。比如说图片尺寸太大，还有浏览问题的时候标题浮窗总是会出现，还会很显眼的展示出来。所以，我就写了个简单的油猴脚本，优化了这两个问题，顺便把知乎的logo也给去掉了。 脚本地址： 安装地址 大家感兴趣的话欢迎使用。对知乎的使用有什么痛点也欢迎提出来。 原文地址: http://lichuanyang.top/posts/23393/

这本书的作用主要是教大家面对现实中的复杂问题，如何更有效的去思考。书本身偏重系统的基本概念，这些概念其实都比较好理解。另外，作者举了非常多的例子。初读这本书时，会感觉理论和实际例子有那么些割裂。 但是后来逐渐感觉到，这个话题确实是没那么容易讲的通俗易懂的，需要读者自己付出更多的思考，才能有实质性的收获。而作者举的这些例子，就是非常好的引导读者去思考的引子。通过跟着作者一起思考这些例子，我们就可以帮助自己更好的理解书中的概念和逻辑。 所以，这篇笔记中，我主要其实就是比较机械化的把书中的一些核心概念提炼出来，同时会尝试举一些身边的例子。 而若想更好的理解书中每一部分，还是推荐去读一遍书，并且跟着作者的思路一起去好好思考那些例子的逻辑。 基本概念系统是一组相互连接的事物，在一定时间内，以特定的行为模式相互影响。 任何一个系统都包括三种构成要件：要素、连接、功能或目标。 存量是所有系统的基础，比如浴缸中的水、人口数量、书店中的书、树木的体积、银行里的钱，等等。但是，存量不一定非得是物质的，你的自信、在朋友圈中的良好口碑，或者对世界的美好希冀等，都可以是存量。 存量会随着时间的变化而不...

之前翻译过一篇关于分布式系统的文章 https://lichuanyang.top/posts/3914/ ，在各个平台都取得了不错的反响。因此，最近又重新整理了一下相关的知识，结合一些这一年多里新的理解，重新整理了下这篇文章。 首先我们需要明确本文要讨论的分布式系统是什么，简单的说，就是满足多节点和有状态这两个条件即可。多节点很好理解，有状态则是指这个系统要维护一些数据，不然的话，其实我们无脑的水平扩容就没有任何问题，也就不存在分布式系统的问题了。 常见的分布式系统， 无论是mysql, cassandra, hbase这些数据库，还是rocketmq, kafka, pulsar这样的消息队列，还是zookeeper之类的基础设施，其实都满足这两个条件。 这些分布式系统的实现通常来说主要需要关注两个方面：一是自己本身功能的实现，二是在分布式环境下保持良好的性能与稳定性；即便是两个功能完全不一样的系统，其对第二类问题的处理方式也会有很多相似之处。本文的关注重点也即在对第二类问题的处理上。 接下来，我们列举一下分布式系统都有哪些常见目标，包括而不限于： 大量普通的服务器通过...