自我介绍

• 我是热爱计算机和可爱的女孩子的萌萌哒吉吉
• 对计算机技术有执着的追求，喜欢写优雅的代码
• 超喜欢追番，欢迎查看我的追番列表
• 语言：中文、English、日本語（学習中）
• 共识：《提问的智慧》、 《异步沟通》、《非暴力沟通》
• 联系方式：i@mmdjiji.com

Badges

飞书日历一直以来有一个问题（其实有好多问题），例如不支持显示法定节假日，这样就会导致我在安排时间表的时候必须参考另外的日历——但飞书日历本身就是个日历，这样感觉很不优雅，直到我看到了这篇文章。但是它是采用的飞书内置的流程中心（需要付费），对于白嫖用户来说并不友好。幸运的是飞书官方支持日历的API，所以我和 Gemini 一拍即合，打算尝试一下能不能只使用 AI Vibe Coding 来完成这个功能，最后我和 Gemini 总共花了 1h42m 就完成了这个项目的开发和调试（其实主要还是调试比较麻烦，因为时区问题导致了很多bug，虽然我觉得我手工写可能用不了一个小时）。

先附上效果图：

一些小小的技术细节

我是采用的 CNB 直接进行开发，代码完全没有落地，并且配了一个 .cnb.yml 让脚本每个月自动执行，这样就可以保持日历的更新：

1
2
3
4
5
6
7
8
9
10
11
12
13

main:
  # 每月 1 日 7:30 自动执行
  "crontab: 30 7 1 * *":
    app:
      git:
        enable: true
        submodules: true
      stages:
        - name: npm start
          image: node:24
          script: |
            npm install
            npm start

需要事先创建一个应用，并配置好 app_id 和 app_secret，且给这个应用开通日历相关的权限。

在执行完成后，理论上飞书就可以在日历的搜索中找到这个日历并直接订阅，你如果是组织的管理员还可以设置为全员日历，这样就可以优雅的以边车模式把法定节假日装载到你的飞书日历了。

代码

我是在 node:24 的环境中运行的：

1
2

npm init -y
npm i axios dayis js-yaml node-ical

config.yaml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 飞书应用配置
feishu:
  app_id: "cli_xxx"
  app_secret: "xxx"

# 日历配置
calendar:
  name: "中国法定节假日"             # 想要创建/查找的日历名称
  color: -1                        # 日历颜色，-1为默认
  summary_prefix: ""               # 可选：给日程加前缀，如 "[休]"

# 数据源
source:
  icloud_url: "https://calendars.icloud.com/holiday/cn_zh.ics"

index.js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205

import fs from 'node:fs';
import yaml from 'js-yaml';
import axios from 'axios';
import ical from 'node-ical';
import dayjs from 'dayjs';

// 读取配置
const config = yaml.load(fs.readFileSync('./config.yaml', 'utf8'));

const FEISHU_HOST = 'https://open.feishu.cn/open-apis';
let TENANT_ACCESS_TOKEN = '';

// 1. 获取 Token
async function getAccessToken() {
    try {
        const res = await axios.post(`${FEISHU_HOST}/auth/v3/tenant_access_token/internal`, {
            app_id: config.feishu.app_id,
            app_secret: config.feishu.app_secret
        });
        if (res.data.code !== 0) throw new Error(res.data.msg);
        TENANT_ACCESS_TOKEN = res.data.tenant_access_token;
        console.log('✅ 获取 Access Token 成功');
    } catch (e) {
        console.error('❌ 获取 Token 失败:', e.message);
        process.exit(1);
    }
}

// 2. 获取或创建日历
async function getOrCreateCalendar() {
    const headers = { Authorization: `Bearer ${TENANT_ACCESS_TOKEN}` };
    let pageToken = '';
    let foundCal = null;
    
    do {
        const res = await axios.get(`${FEISHU_HOST}/calendar/v4/calendars`, {
            headers,
            params: { page_size: 500, page_token: pageToken }
        });
        if (res.data.code !== 0) throw new Error(res.data.msg);
        foundCal = (res.data.data.calendar_list || []).find(c => c.summary === config.calendar.name);
        pageToken = res.data.data.page_token;
    } while (pageToken && !foundCal);

    if (foundCal) {
        console.log(`✅ 找到日历: ${foundCal.summary}`);
        return foundCal.calendar_id;
    }

    console.log(`ℹ️ 创建新日历: ${config.calendar.name}...`);
    const createRes = await axios.post(`${FEISHU_HOST}/calendar/v4/calendars`, {
        summary: config.calendar.name,
        description: "自动同步的节假日日历",
        permissions: "public",
        color: config.calendar.color, 
        summary_alias: config.calendar.name
    }, { headers });
    return createRes.data.data.calendar.calendar_id;
}

// 3. 获取 iCloud 数据 (已修复日期范围问题)
async function fetchICloudEvents() {
    console.log('⬇️ 正在下载 iCloud 数据...');
    const events = await ical.async.fromURL(config.source.icloud_url);
    
    const validEvents = [];
    const now = dayjs().startOf('day');
    const oneYearLater = now.add(1, 'year').endOf('day');

    for (const k in events) {
        const ev = events[k];
        if (ev.type !== 'VEVENT') continue;

        // 处理标题
        let summaryText = '';
        if (ev.summary && typeof ev.summary === 'object' && ev.summary.val) {
            summaryText = ev.summary.val;
        } else {
            summaryText = String(ev.summary || '');
        }

        const startDate = dayjs(ev.start);
        
        let endDate;
        if (ev.end) {
            const tempEnd = dayjs(ev.end);
            // ics 协议中，全天日程 end 是独占的（即次日零点）。
            // 飞书全天日程需要的是包含的结束日期。
            // 所以，如果 end > start，我们需要减去 1 天。
            if (tempEnd.isAfter(startDate, 'day')) {
                endDate = tempEnd.subtract(1, 'day');
            } else {
                // 如果 end 和 start 是同一天（极少见），或者数据异常，保持原样
                endDate = tempEnd;
            }
        } else {
            // 如果没有 end，默认为当天
            endDate = startDate;
        }

        if (startDate.isAfter(now) && startDate.isBefore(oneYearLater)) {
            validEvents.push({
                summary: summaryText,
                startDate: startDate.format('YYYY-MM-DD'),
                endDate: endDate.format('YYYY-MM-DD'),
                uid: ev.uid
            });
        }
    }
    console.log(`✅ 解析到源数据: ${validEvents.length} 条`);
    return validEvents;
}

// 4. 获取飞书现有数据
async function fetchFeishuEvents(calendarId) {
    const headers = { Authorization: `Bearer ${TENANT_ACCESS_TOKEN}` };
    const now = dayjs().unix();
    const oneYearLater = dayjs().add(1, 'year').unix();

    const res = await axios.get(`${FEISHU_HOST}/calendar/v4/calendars/${calendarId}/events`, {
        headers,
        params: { start_time: String(now), end_time: String(oneYearLater), page_size: 500 }
    });

    return (res.data.data.items || []).map(e => ({
        ...e,
        event_id: e.event_id,
        summary: e.summary,
        startDate: e.start_time.date,
        endDate: e.end_time.date 
    }));
}

async function main() {
    await getAccessToken();
    const calendarId = await getOrCreateCalendar();
    
    const sourceEvents = await fetchICloudEvents();
    const existingEvents = await fetchFeishuEvents(calendarId);

    console.log('sourceEvents:', sourceEvents);
    console.log('existingEvents:', existingEvents);

    const toCreate = [];
    const toDelete = [];

    // 1. 找出需要创建的
    for (const src of sourceEvents) {
        const exists = existingEvents.find(
            e => e.startDate === src.startDate && 
                //  e.endDate === src.endDate && 
                 e.summary === src.summary
        );
        if (!exists) toCreate.push(src);
    }

    // 2. 找出需要删除的
    for (const exist of existingEvents) {
        const inSource = sourceEvents.find(
            s => s.startDate === exist.startDate && 
                //  s.endDate === exist.endDate && 
                 s.summary === exist.summary
        );
        if (exist.status === 'confirmed' && !inSource) toDelete.push(exist);
    }

    console.log('[toCreate]', toCreate);
    console.log('[toDelete]', toDelete);

    console.log(`📊 变更计划: 新增/修正 ${toCreate.length}, 删除/清理 ${toDelete.length}`);

    // 执行删除
    if (toDelete.length > 0) {
        const headers = { Authorization: `Bearer ${TENANT_ACCESS_TOKEN}` };
        for (const evt of toDelete) {
            try {
                await axios.delete(`${FEISHU_HOST}/calendar/v4/calendars/${calendarId}/events/${evt.event_id}`, { headers });
                console.log(`  - 已删除旧日程: [${evt.startDate} - ${evt.endDate}] ${evt.summary}`);
            } catch (e) { console.error(`  ! 删除失败: ${e.message}`); }
        }
    }

    // 执行创建
    if (toCreate.length > 0) {
        const headers = { Authorization: `Bearer ${TENANT_ACCESS_TOKEN}` };
        for (const evt of toCreate) {
            try {
                await axios.post(`${FEISHU_HOST}/calendar/v4/calendars/${calendarId}/events`, {
                    summary: evt.summary,
                    start_time: { date: evt.startDate },
                    end_time: { date: evt.endDate }, 
                    visibility: "public",
                    is_all_day_event: true
                }, { headers });
                console.log(`  + 已创建: [${evt.startDate}${evt.startDate === evt.endDate ? '' : ' -> ' + evt.endDate}] ${evt.summary}`);
            } catch (e) {
                console.error(`. ! 创建失败 [${evt.startDate}]:`, e.response?.data?.msg || e.message);
            }
        }
    }

    console.log('🎉 同步完成');
}

main().catch(console.error);

总结

感谢你看到这里！这是一个 AI Vibe Coding 的试验场景，我的确感受到了 AI Coding 的未来已到：

1. 目前 人工写需求 + AI 写代码 + 人工调试 的工作流已经初步可用，很多简单场景都可以借鉴这套模式，带来的收益是效率的绝对优势，虽然暂时不知道会不会有潜在的 bug；
2. 在一些复杂的边界问题上，AI 可能会出错，我们需要一个规范性的说明，或者引入类似 AI friendly 架构来解决；
3. 让 AI 自驱完成从需求、编码到测试的闭环，是未来非常值得期待的。

由于我使用自己的部署 GitLab，而仅仅使用一台从 ESXi 上虚拟化的 VM——我相信许多人都是这样的，甚至有些人会使用树莓派去搭建自己的 GitLab。但是这样做可能会产生数据安全问题，尤其是当存储意外损坏。我整理了一下需求，大概有以下几点：

1. 自动化，无需人工干预；
2. 冷备份，存储服务器无需持续开机，省电也省磁盘寿命；
3. 可观测，即备份结束后主动推送结果；
4. 易回滚，每次备份自动做一个快照，可以回滚到任意时间点，也可以直接查看数据。

架构

我采用了 TrueNAS 作为备份服务器，在需要备份的服务器上加载了 TrueNAS 的证书以使用基于 SSH 的 rsync 进行拉取。我单独编写了一个程序，首先在局域网里通过 WoL 唤醒 TrueNAS，再用 SSH 连接上 TrueNAS 执行 rsync，结束后调用 TrueNAS 的 API 打一个 snapshot，完成后自动关机，最后通过飞书的 webhook 推送备份结果。

需要注意的是，我备份了 /var/lib/docker 和 /home/ubuntu，原因是我的服务器都采用 Docker 管理各种服务，因此挂载点无非是 /var/lib/docker/volumes 或在 /home/ubuntu/<deployment>/data，而备份整个 Docker 文件夹的潜在目的是把镜像也备份一下，防止到时候因为找不到正确版本的镜像而被迫想办法对数据升级以匹配新的镜像。

另外，所有的 Docker 启动指令也应备份下来，这样恢复的工作流就简单许多，甚至可以启一台新的 VM，安装 Docker 后，只恢复 /var/lib/docker/volumes 和 /home/ubuntu，然后直接用原来的命令去启动新的容器即可。

讨论与展望

折腾这些的意义？

任何电子零件都是有寿命的，我们的确可以在其寿命耗尽前定期更换，但却不能预测它的意外损坏。

高可用 vs 备份？

许多人会采用 RAID 来避免因存储单点损坏造成的数据丢失，但我想说这和做备份并不冲突。

一致性问题

单纯的使用 rsync 可能会出现一致性问题，容易造成一些问题，这是当前方案的缺陷。由于在备份的同时服务器极有可能还在写入，所以最好的办法是在备份前先把 Docker 服务停掉，虽然会造成备份期间业务不可用，但确保了一致性。要想理解如何产生一致性问题并不难，因为 ext4 文件系统不是写时复制（Copy On Write, COW）的，因此不能像 zfs 或者 btrfs 一样直接对某个时刻进行快照。当然对于 GitLab 和 Webdav 来说是低风险的，因为最重要的是 volumes 里的 Git 文件夹，这些的更新都不是很频繁，因此出现一致性问题的风险不大。

针对写时复制，它通过不修改原始数据块，而是将修改后的数据写入新的位置，从而确保文件在写入过程中始终处于一致状态，并能轻松创建数据快照和历史版本。由于 zfs 是写时复制的，我们在 TrueNAS 上创建的快照就具有一致性。

解决这个问题有两个思路，一个是把服务器或者备份更换成支持写时复制的文件系统，然后备份当前的镜像，还有一个方法是在备份前停止写入，例如加锁或者关闭服务。未来我解决了这个问题还会再写博文分享。

这件事从最开始发现到现在已经有将近一年了，而直到现在也不能得出100%确定的原因，本文中所得出的结论也只是我的推测。任何复杂的系统，都难以通过单方面的判断得出有效的结论，消融实验是必要的，而很多时候又没有做消融实验的条件和时机。谨以本篇文章，还原我从发现UPS不稳定，到得出结论的心路历程，希望能带给读者一些参考。如果有读者遇到类似的事件，不妨与我讨论。

本文中涉及的UPS型号为山特 SANTAK TG-BOX 850，但本文不认为该 UPS 有质量问题，甚至这个 UPS 质量非常好，精度非常高，我们会在后文讨论。

本文一切内容均来自个人经验，并非相关品牌专业人士的官方声明，请在专业人士指导下进行相关操作。

突如其来的告警

那是一个平凡的夏天，我正坐在电脑前吹着空调看着番剧吃着雪糕，几个告警突然从手机弹出：UPS is on battery power。

正当我困惑，家里没停电啊，为什么 UPS 进入电池模式了，难道是误报？突然又收到一条告警已清除的邮件，随后就来来回回不停地收到一堆“抖动”的告警。

我开始检查 NAS 的状况，我有理由怀疑是 NAS 因为莫名其妙的原因触发了告警，而实际上 UPS 并没有发出告警，因为实际上并没有断电。但我并没有什么方法从 NAS 上找到线索，因为它的配置似乎是正常的。UPS 触发 NAS 告警的原理应该是：UPS 通过 USB 协议向 NAS 发送通知，NAS 上的服务接收到通知后，通过 SMTP 发到我的邮箱里。现在 USB 协议这段出现了莫名其妙的故障，导致了误触发，至少我当时是这么考虑的。我甚至考虑过暂时性地把联动关闭，但是风险很大，所以我一开始也只是延长了从断电到关机的时间，以在“抖动”中寻求稳定和折中。

我开始检查 UPS 的状况，发现好像确实在每次告警的时候，UPS 进入了电池模式，因为 UPS 的硬件告警灯亮了。这瞬间让我意识到没有关闭联动的必要性，如果我关闭了联动，而恰好 UPS 消耗光了电量，将会发生什么不可逆的后果。而调查也有了思路：线路故障，或者 UPS 本身故障。

消融实验

我一开始怀疑线路故障，因为插线板经常就会出现接触不良的问题，所以我在线更换了一个插线板，在更换完的一天内确实没有出现过告警，而之后又再次出现了，可以证明并非线路故障，因为该插线板在其他线路中工作正常。

随着告警越来越多，我在一次告警中观察到了长时间的 UPS 断电告警，我把 UPS 从系统中分离以进行进一步的测试。直到我把 UPS 插在我工作台的插座上，仍然提示告警，我坚信，这一定是 UPS 故障导致的。于是我立马联系 UPS 的售后，得知了这台 UPS 拥有三年质保，厂商的处理很迅速，从我寄过去到 UPS 寄回只用了不到一周时间。果然，新的 UPS 就再也没有发生过这种问题了。

然而，最近又开始断断续续地发生着告警，我很疑惑，所有的模块我都做过消融实验了啊，难道这个型号的 UPS 就有问题吗？但是既没有收到厂商对产品的召回，网络上也没有讨论相关话题的。

结论

直到我最近在小区的物业群里看到了有人在讨论最近小区电力不稳，一切都迎刃而解了。我迅速找到去年的告警，果然也是在夏天。这一切的一切，只有一个东西没有做过消融实验——那就是上游供电。我怎么就不能怀疑是它不稳导致的呢？但是我家里的另外两台 UPS 都工作正常，只有这台不正常，而且电脑也一直在持续稳定运行，因此我一开始就忽略掉了这个最不应该忽略的因素。因为电脑电源的电容很大所以稳定是正常的，而其他 UPS 可能对电压不稳并没有这么敏感，只有这台 UPS 的精度很高，对于哪怕电压出现的一丁点异常都能检测出来并及时接管供电。而都是发生在夏天，因为夏天大家都在使用，尤其是我发现天气越热就越容易出现这种情况，那一切就都解释清楚了。时间点也对得上，这些告警都是在晚上出现的，而晚上应该也是空调使用最多的时间段。

虽然我这么认为了，不过未来还会不会有其他证据推翻我的猜测呢？谁也不好说，因为没有确定性的证据，这些猜想，都只是我的一厢情愿，但姑且认为是这样子吧。我最近也开始在家里着手节能减排的规划了，先停掉了一个冰柜，然后将厨房的热水器也停掉了（冬天会改成定时运行），烧水器也改成只有白天运行了。虽然这并没有什么用，但我还是打算避免不必要的浪费。

笔者曾提到，Python 用 venv 创建虚拟环境。的确，Python 中采用 venv 来管理虚拟环境是一个很棒的局部安装方案，类似 npm 的 node_modules 目录。但是该方案还尚且不能解决 Python 版本切换的问题，幸运的是，pyenv 这个工具可以完美解决，类似 npm 中的 n，它可以使用简单的命令切换多个 Python 版本。

本文将以 Ubuntu 22.04 为例来介绍它的安装方法，虽然它原生并不支持 Windows，但是有人为 Windows 做了移植，见 pyenv-win。

值得注意的是，这个项目有趣的地方在于，无论是安装还是使用，都是以用户权限都能完成的，非常适合当今多用户共享显卡的服务器。

David Wheeler: Any problem in computer science can be solved by another layer of indirection.

安装方法 (Ubuntu)

首先安装依赖：

1
2
3

sudo apt update; sudo apt install build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev curl \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

执行一键安装脚本：

1

curl https://pyenv.run | bash

如果上面的失败可以试试下面这个：

1

curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash

然后把出现的一段放到 .bashrc 末尾：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Load pyenv automatically by appending
# the following to 
# ~/.bash_profile if it exists, otherwise ~/.profile (for login shells)
# and ~/.bashrc (for interactive shells) :

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

# Restart your shell for the changes to take effect.

# Load pyenv-virtualenv automatically by adding
# the following to ~/.bashrc:

eval "$(pyenv virtualenv-init -)"

再执行 . .bashrc 重新加载配置文件，这样就安装好了。

安装方法 (Windows)

在 PowerShell 里运行如下:

1

Invoke-WebRequest -UseBasicParsing -Uri "https://raw.githubusercontent.com/pyenv-win/pyenv-win/master/pyenv-win/install-pyenv-win.ps1" -OutFile "./install-pyenv-win.ps1"; &"./install-pyenv-win.ps1"

如果需要换源，对 ~/.pyenv/pyenv-win/.version_cache.xml 文件进行一个全局替换，把 https://www.python.org/ftp/python 替换为 https://cdn.npmmirror.com/binaries/python，然后就可以正常使用啦！

需要注意的是，pyenv-win 相比于 pyenv 有一个区别：在 pyenv 中我们可以使用大版本号去进行前缀匹配，例如 pyenv shell 3.7 就可以自动定位到 3.7.x 版本（前提是只存在一个 3.7.x 版本），而在 pyenv-win 中则需要精确提供版本，不然会报 pyenv specific python requisite didn't meet. Project is using different version of python. 的错误。

幸运的是，经过测试，pyenv-win 对于 .python-version 的前缀匹配是完美兼容的，这意味着与 pyenv 具有很好的兼容性。

用法

1
2
3
4
5
6

pyenv install --list # 列出可供安装的版本
pyenv install x.x.x  # 安装指定版本
pyenv versions       # 列出本地已安装的版本
pyenv shell x.x.x    # 切换到指定版本 (PYENV_VERSION)
pyenv local x.x.x    # 指定目录使用的特定版本 (./.python-version)
pyenv global x.x.x   # 指定全局使用的特定版本 (~/.pyenv/version)

推荐阅读

• pyenv 神器原理分析-腾讯云开发者社区-腾讯云 (tencent.com)

哦对了

千万不要手贱执行 sudo apt remove python

为了解决这个尴尬，我在博客里创建了一个追番列表，你可以访问这个网址来了解我都看过哪些番剧，这样交流起来是不是就容易多了呢？现在我每次遇到二次元同好，啥也不说，把这个网址发给人家，他就会指着这里面的番剧说：啊这个我看过，那个我也看过。对吧，有效地解决了社恐二次元的烦恼。

预览

工具

• Hexo番剧页面插件: https://github.com/mmdjiji/hexo-bangumis
• 番组计划: https://bangumi.tv 或 https://bgm.tv
• 自动更新番剧代码: https://github.com/mmdjiji/hexo-bangumis/blob/main/workflows-demo/auto-update.yml

使用方法

安装

在 Hexo 文件夹下执行:

1

npm install hexo-bangumis --save

配置

将下面的配置写入 站点 的配置文件 _config.yml 中:

1
2
3
4
5
6
7
8
9
10
11
12
13

bangumis:
  enable: true              # 是否启用
  path: bangumis/index.html # 生成追番页面的路径
  show: 1                   # 想看，在看，看完
  title: '追番列表'          # 标题
  quote: '生命不息，追番不止'  # 格言
  color_meta: "#555"        # 追番项元数据的颜色
  color_summary: "#555"     # 追番项简介的颜色
  bgmtv_uid: mmdjiji        # bgm.tv的uid
  download_image: true      # 下载图片并使用本地图片，否则使用bgm.tv提供的网络图源
  image_level: c            # 图片高清等级 (l, c, m, s, g)
  lazyload: true            # 是否开启懒加载
  margin: 20px              # 封面图的偏移量微调

使用

更新追番数据:

1

hexo bangumis -u

删除追番数据:

1

hexo bangumis -d

获取 bgm.tv 的 uid

登录 bgm.tv 后打开控制台（快捷键 Ctrl + Shift + J），输入 CHOBITS_UID 后按回车，得到的数字就是 uid 啦~

CI/CD

为了配合自动化运维，我特意编写了一份 GitHub Actions 脚本。你也不想每次在番组计划上添加完番剧还要手动在博客的仓库里更新番剧然后再构建一遍再推到服务器上吧，这种重复操作我们直接用脚本解决。

在 .github/workflows 目录里创建一个名为 auto-update.yml 的文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

name: Auto update
on:
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * *' # Every day

jobs:
  meta:
    name: Update meta
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          ref: main

      - name: Do meta update
        shell: bash
        run: |
          npm install
          npx hexo bangumis -u || echo

      - name: Commit files
        run: |
          git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git config --local user.name "github-actions[bot]"
          git add .
          git commit -m "Update meta on $(date '+%Y-%m-%d %H:%M:%S')" || echo

      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.ref }}

      - name: Do build
        shell: bash
        run: |
          npm run build

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@releases/v3
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages # The branch the action should deploy to.
          FOLDER: public # The folder the action should deploy.

牛逼之处

• 使用 bgm.tv 的官方 API 来进行爬取，番剧更多，可用性更高
• 支持数据缓存及番剧封面图本地化，防止因上游服务挂掉导致连锁效应，爬取好番剧后可纯离线场景下部署
• 极端条件下可通过编辑文件来自定义番剧列表，可自定义添加 bgm.tv 没有的番剧
• 总的来说，只要你爬取过这个番剧，那么就算将来 bgm.tv 上把这个番剧删掉了，你也可以继续使用这个番剧

Dependabot

Dependabot 是 GitHub 官方的一款依赖更新工具，在配置好后，它会自动定期（周期可以自己配置）从包管理器中扫描最新依赖，与工程中使用的依赖进行比对，如果发现版本的升级，则提出一个 Pull Request 以用于更新依赖。

配置 Dependabot 的方法很简单，只需合理地编辑 .github/dependabot.yml 文件，官方参考文档在此。

例如，项目的包管理器使用 pip，要求每周扫描一次更新，就可以按照如下进行配置：

1
2
3
4
5
6

version: 2
updates:
  - package-ecosystem: pip
    directory: /
    schedule:
      interval: weekly

Auto Merge

在提出 Pull Request 后，就需要使用 GitHub Actions 执行 CI 以合并分支，编辑 .github/workflows/auto-merge.yml 文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

name: Dependabot Auto Merge
on:
  pull_request:
    types: [ labeled, edited ]

jobs:
  dependabot:
    name: Dependabot
    runs-on: ubuntu-latest
    permissions: write-all
    if: ${{ github.actor == 'dependabot[bot]' && github.event_name == 'pull_request'}}
    steps:
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

按照自动化运维的规范，应先进行测试再合并，以保证代码能适应新版本的依赖。自动化测试的代码应添加在 steps 的第一步（因为第一步也就是唯一的步骤就是合并分支）之前，确保能通过测试后，就可以放心进行分支的合并了。否则，应该 throw 一个错误出来，供开发人员查阅。

优点与缺点

优点是这种操作节约了时间，并可以持续确保依赖的最新性，非常适合模板的仓库，因为模板的仓库不是最新就没有意义了，没有人愿意从一段旧代码开始自己的工作。

缺点是如果测试不够规范，将会产生一些安全问题，包括但不限于有些开发人员在新版本的依赖中故意引入缺陷等行为。所以对于稍大规模的项目，仍然建议人工审查 Pull Request，尤其是这种由自动化方式创建的 Pull Request，它们的恶意行为最不易被察觉。

本人于2023年1月1日申请加入十年之约，于今日正式签约，特此记录。

希望本博客能持之以恒地存在十年，也希望我能在未来十年能有充足的写作动力。时光不老，我们不散，愿博客长存。

我并不是非常注重仪式感的人，有时我甚至认为结婚是不需要结婚证与婚礼的，结婚证只是离婚和给娃上户口时使用的工具，而婚礼不过是获得大家的祝福。但随着年龄的增大，我发现经历本身才是最有意义的事，你一生对事物的经历和体验，是其他人难以复制的，是任何人花钱也买不到的。我想多记录些什么，以便索引。

技术大事记

个人技术的进步，和公司、国家其实是一样的，都是螺旋式上升的过程。

• 完成家庭服务器基础设施，全面使用软路由，WiFi 6 全覆盖
• 对电子元件的贴片的探索来到了 QFN48，0402 级别
• 添置了一个新工作台，提升焊接效率，磨刀不误砍柴工
• 完成了 Jump Server 的开发，可以用它看监控了
• 对博客进行了全面升级，包括 CI/CD，CDN，图片懒加载以及全面的速度优化，把博客的组件全部解耦合
• 复现了 FabGL 的硬件
• 续费了三年的大学生活

生活大事记

我们，还是得赶快学会生活啊。——《三体》法律系的妹子

• 把老旧照片的底片数字化保存
• 添置了手办柜，可以将手办与礼物等放入展示
• 添置了扫地机器人，解放生产力
• 安装了投影仪，增加了看番体验
• 疫情终于要结束了，期待明年的春天

番剧漫谈

今年印象最深的科幻番就是《我的三体》，因为艺画开天《三体》的放送，就去补了隔壁业余组神游八方《我的三体》，但其实业余组比专业组的质量好太多。“自然选择，前进四”是我最喜欢的一句台词，致敬对人类文明的延续。

三体中的黑暗森林法则，以及众多科幻内容，其实也在我对宇宙的思考之中。我一直认为，宇宙是嵌套的，而倘若真的存在智子展开，可能展开后的智子就是内层宇宙。我认为可以这样理解：“原子核内部可能是一个宇宙，我们破坏它轻而易举，因为我们是降维打击它。但又没有那么容易，我们不会因为打个喷嚏就让原子核崩坏。所以原子核内可以稳定地存在宇宙，只要我们没有发现它。而我们发现它又如海底捞针，只要原子核里面的宇宙隐藏好自己，那么就像黑暗森林一样，哪怕高等文明，也难以发现。”

当然，今年看了很多非常可爱而治愈的动漫！《孤独摇滚》、《向山进发》、《学园孤岛》、《龙与虎》、《莉可丽丝》、《租借女友 第二季》、《柑橘味香气》、《Love Live!》系列、《邻家的吸血鬼小妹》、《来自风平浪静的明天》、《来自多彩世界的明天》、《测不准的阿波连同学》、《女孩的钓鱼慢活》、《约定的梦幻岛》系列等等……来年再拿这些做文章。

展望，2023

希望明年疫情会真正的过去，我们的生活可以恢复到 19 年之前的样子。那样，明年的春天，就可以去玉渊潭赏樱花🌸，可以去听房东的猫的演唱会，可以去二次元里圣地巡礼。

明年，也是时候为我的大学生涯画上一个逗号，为本科生涯画上一个句号了。说来也巧，我大一的时候疫情悄然而至，变成了大学生活的阴霾，如今已经大四迎来了毕业，希望疫情也就烟消云散了。

23 年对我来说也是一个奋斗之年，有很多要学习的东西，也有很多要做的事情。希望能在这一年里踏踏实实学习，不断地变强。

创建虚拟环境

先创建一个目录，这个目录作为当前 Python 工程的根：

1

jiji@play:~$ mkdir pycode && cd pycode

使用如下命令创建一个 venv 虚拟环境：

1

jiji@play:~/pycode$ python -m venv .

在 Debian/Ubuntu 系统中，需要单独安装 venv 的依赖，使用 sudo apt install python3.8-venv 为 Python 3.8 安装依赖：

1
2
3
4
5
6
7
8
9

jiji@play:~/pycode$ python -m venv .
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

    apt install python3.8-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

随后再执行该命令即可，创建完成后目录下会增加几个文件：

1
2
3
4
5
6
7
8
9

jiji@play:~/pycode$ python -m venv .venv
jiji@play:~/pycode$ ls -la
total 12
drwxrwxr-x  3 jiji jiji 4096 Dec  9 03:01 .
drwxr-xr-x 12 jiji jiji 4096 Dec  9 02:31 ..
drwxrwxr-x  6 jiji jiji 4096 Dec  9 03:01 .venv
jiji@play:~/pycode$ cd .venv
jiji@play:~/pycode/.venv$ ls
bin  include  lib  lib64  pyvenv.cfg  share

进入虚拟环境

POSIX

Windows

在输入相关脚本后，命令行前面新增了一个 (.venv)，这就表明我们当前的命令行在虚拟环境中，与全局的环境隔离：

1
2

jiji@play:~/pycode$ source .venv/bin/activate
(.venv) jiji@play:~/pycode$

我们可以在 Python 文件的第一行前加上如下代码，即可在运行时自动使用虚拟环境运行：

1

#!/.venv/bin/python

退出虚拟环境

在虚拟环境内输入 deactivate 命令就能退出：

1
2

(.venv) jiji@play:~/pycode$ deactivate
jiji@play:~/pycode$

与 VSCode 配合使用

这波与 VSCode 配合的很好捏~

在安装了 Python 的扩展后，VSCode 可以自动检测到目录下的 venv 环境并自动载入之，唯一需要注意的是请打开整个工程文件夹。

优点

我们在内部使用 pip 安装的依赖，不会被同步到全局，而是只存在于当前工程。这种设计与 npm 中的局部安装 node_modules 文件夹是类似的。

这种设计可以更方便而干净的导出依赖。我们在完成一个工程时可能会用到一些依赖，为了方便其他人安装，通常都需要导出 requirements.txt 以便于其他人复现，但如果采用全局安装，导出时通常会导出一些不必要的依赖（除非你为每个项目都安装了自己的 Python），因为 Python 的依赖是全局安装的，所以导出时总会把全部依赖导出。倘若在虚拟环境内部导出，就只会导出当前项目的依赖了，这样就方便而干净。

这种设计更便于处理依赖冲突，倘若我们需要在 A 项目中使用 flask==1.0 而在 B 项目中使用 flask==2.0，就最好使用 venv 进行管理，为每个项目都创建一个独立的虚拟环境而安装不同的模块版本，这样就可以同时运行多个项目而不会冲突。

优雅地使用

虽然您认为 venv 是个好用的工具，使用 Python 的最佳实践就是用它来管理依赖，但您不能假设所有人都使用它，因为它仍未成为行业的标准，仍然有不少人在使用全局安装或者 Anaconda 等方案进行依赖管理。

由于 venv 本身和系统环境耦合，为了解耦合，在使用 Git 时，您的最佳实践是将 .venv/ 写入 .gitignore，避免将 .venv/ 提交到 Git 上。

您可以在 venv 环境中使用如下命令以导出依赖：

1

pip freeze > requirements.txt

您可以指导用户（当然，您也可以在 venv 中这么做）使用下面的命令来安装依赖：

1

pip install -r requirements.txt

包管理的哲学

依赖是包

任何情况下依赖就是包，所以任何一个工程也可以变成依赖。依赖暴露一些接口，而工程导入这些接口就可以调用。

可索引的依赖

所有的依赖都应该通过一个文件来索引，这个文件应该具有可读性，可以手工编辑，并且可通过包管理器安全地一键安装依赖。安全地安装依赖指，在安装完成之后，当前的代码应能访问到索引文件中依赖的正确版本，且安装过程中不应该影响到任何其他文件夹的项目。

依赖的具体文件不同步

任何时候，依赖的具体文件应该由包管理器通过索引文件来进行安装，不应被同步到其他设备。只有依赖的索引文件可被同步。

英文官网 | 中文官网 | 中文文档

K3s 是一个轻量级的 Kubernetes 发行版，它针对边缘计算、物联网等场景进行了高度优化。本文将安装并配置一个 K3s 集群，并测试其的使用。

值得注意的是，与 Kubernetes 不同，这里的 Master 节点叫 Server 节点，而 Slave 节点叫 Agent 节点。

环境

网络与端口

k3s-server 需要 6443 端口才能被所有节点访问。

其他参考这里。

部署 Server 节点

1

root@k3s-server:~# curl -sfL https://get.k3s.io | sh -

使用如下命令查看节点运行状态：

1
2
3

root@k3s-server:~# kubectl get node
NAME         STATUS   ROLES                  AGE   VERSION
k3s-server   Ready    control-plane,master   20s   v1.24.4+k3s1

使用如下命令获取 node-token：

1
2

root@k3s-server:~# cat /var/lib/rancher/k3s/server/node-token
K101e23ad4c6b37c9fdf****::server:****f7538ded6

这个 node-token 一会在部署 Agent 节点的时候需要用到。

部署 Agent 节点

对于每个 Agent 节点，使用如下命令安装 K3s 并直接加入集群：

1

root@k3s-agent-1:~# curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken sh -

例如：

1

root@k3s-agent-1:~# curl -sfL https://get.k3s.io | K3S_URL=https://10.0.0.39:6443 K3S_TOKEN=K101e23ad4c6b37c9fdf****::server:****f7538ded6 sh -

执行完成后，到 Server 节点查看所有节点状态：

1
2
3
4

root@k3s-server:~# kubectl get node
NAME          STATUS   ROLES                  AGE   VERSION
k3s-server    Ready    control-plane,master   25m   v1.24.4+k3s1
k3s-agent-1   Ready    <none>                 18s   v1.24.4+k3s1

同样，对于 k3s-agent-2 也做同样的部署，完成后节点状态如下：

1
2
3
4
5

root@k3s-server:~# kubectl get node
NAME          STATUS   ROLES                  AGE     VERSION
k3s-server    Ready    control-plane,master   31m     v1.24.4+k3s1
k3s-agent-2   Ready    <none>                 3m36s   v1.24.4+k3s1
k3s-agent-1   Ready    <none>                 6m19s   v1.24.4+k3s1

设置 K3S_URL 参数会使 K3s 以 worker 模式运行。K3s agent 将在所提供的 URL 上向监听的 K3s 服务器注册。K3S_TOKEN 使用的值存储在你的服务器节点上的 /var/lib/rancher/k3s/server/node-token 路径下。

创建 Pod

将以下代码写入 nginx-pod.yaml：

1
2
3
4
5
6
7
8
9
10

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

使用如下命令应用：

1
2

root@k3s-server:~/k3s# kubectl apply -f nginx-pod.yaml
pod/nginx created

查看运行状态：

1
2
3

root@k3s-server:~# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          11h

与 Docker 不同，这里进入容器的需要在命令前加上 --

进入 Pod 并测试访问：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

root@k3s-server:~/k3s# kubectl exec -it nginx -- /bin/bash
root@nginx:/# curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

到此为止，我们创建了一个功能正常的 Pod。

创建 Deployment

将以下代码写入 nginx-deployment.yaml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

使用如下命令应用：

1
2

root@k3s-server:~/k3s# kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx created

查看运行状态：

1
2
3

root@k3s-server:~/k3s# kubectl get deployment
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   2/2     2            2           29s

此时再查看 Pod，如下：

1
2
3
4

root@k3s-server:~/k3s# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-544dc8b7c4-lzvz9   1/1     Running   0          3m4s
nginx-544dc8b7c4-5nbcw   1/1     Running   0          3m4s

可以看到，由 Deployment 产生的 Pod 命名规则如下：

1

${DeploymentName}-${DeploymentUid}-${Hash}

在查看 Pod 的时候，如果加上 -o wide 参数，就可以查看更多信息：

1
2
3
4

root@k3s-server:~/k3s# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP          NODE          NOMINATED NODE   READINESS GATES
nginx-544dc8b7c4-lzvz9   1/1     Running   0          9m30s   10.42.1.4   k3s-agent-1   <none>           <none>
nginx-544dc8b7c4-5nbcw   1/1     Running   0          9m30s   10.42.3.3   k3s-agent-2   <none>           <none>

可以看到，该 nginx 被创建了两个 Pod 副本，分别部署在了 k3s-agent-1 和 k3s-agent-2 上面。

创建 Service

Service，将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。

Service 定义的抽象能够解耦这种关联。

Service 有两种类型，一种是 NodePort，选择该种类型的可直接通过 ${serverIP}:${nodePort} 访问内部的服务；另一种是 ClusterIP 类型，它只会在集群内部可以访问到该 Pod，不会把 Pod 的内容映射在某一个外网可以访问的端口上，但这并不意味着不能对外提供服务，而是需要 Ingress 的帮助，来将外网的流量转发到 Service 上来。

NodePort

将以下代码写入 nginx-service-nodeport.yaml：

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080
  type: NodePort

这里 nodePort 的范围是 30000-32767。

使用如下命令应用：

1
2

root@k3s-server:~/k3s# kubectl apply -f nginx-service-nodeport.yaml 
service/nginx-service created

现在访问 http://10.0.0.39:30080、 http://10.0.0.31:30080 与 http://10.0.0.32:30080，都可以正常访问到内容：

查看 Service：

1
2
3
4

root@k3s-server:~/k3s# kubectl get service
NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.43.0.1      <none>        443/TCP        12h
nginx-service   NodePort    10.43.74.219   <none>        80:30080/TCP   7m21s

ClusterIP

Service

将以下代码写入 nginx-service-clusterip.yaml：

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

使用如下命令应用：

1
2

root@k3s-server:~/k3s# kubectl apply -f nginx-service-clusterip.yaml 
service/nginx-service created

这样就创建了 Service，但外部还不能访问，所以需要 Ingress。

Ingress

先做个 DNS 解析：

将以下代码写入 nginx-ingress.yaml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
spec:
  rules:
    - host: nginx.k3s.jiji.pro
      http:
        paths:
          - path: /
            pathType: Prefix
            backend: 
              service:
                name: nginx-service
                port:
                  number: 80

使用如下命令应用：

1
2

root@k3s-server:~/k3s# kubectl apply -f nginx-ingress.yaml 
ingress.networking.k8s.io/nginx-ingress created

现在访问 http://nginx.k3s.jiji.pro 即可访问到部署的服务：

尝试关掉 k3s-agent-1：

1

root@k3s-agent-1:/home/jiji# shutdown -h now

证实 k3s-agent-1 确实下线了：

1
2
3
4
5

root@k3s-server:~# kubectl get node
NAME          STATUS     ROLES                  AGE   VERSION
k3s-server    Ready      control-plane,master   13h   v1.24.4+k3s1
k3s-agent-2   Ready      <none>                 12h   v1.24.4+k3s1
k3s-agent-1   NotReady   <none>                 12h   v1.24.4+k3s1

再访问 http://nginx.k3s.jiji.pro，服务出现不可用，但刷新后也可访问正常。经过两次连续的 ping，我们发现 DNS 解析由原本失效的 10.0.0.31，变为了 10.0.0.39。这也就保证了在 Agent 宕机的情况下服务高可用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ ping nginx.k3s.jiji.pro

正在 Ping nginx.k3s.jiji.pro [10.0.0.31] 具有 32 字节的数据:
来自 10.0.0.1 的回复: 无法访问目标主机。
来自 10.0.0.1 的回复: 无法访问目标主机。
来自 10.0.0.1 的回复: 无法访问目标主机。
来自 10.0.0.1 的回复: 无法访问目标主机。

10.0.0.31 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，

$ ping nginx.k3s.jiji.pro

正在 Ping nginx.k3s.jiji.pro [10.0.0.39] 具有 32 字节的数据:
来自 10.0.0.39 的回复: 字节=32 时间=3ms TTL=63
来自 10.0.0.39 的回复: 字节=32 时间=5ms TTL=63
来自 10.0.0.39 的回复: 字节=32 时间=5ms TTL=63
来自 10.0.0.39 的回复: 字节=32 时间=12ms TTL=63

10.0.0.39 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 3ms，最长 = 12ms，平均 = 6ms

但当我关闭 k3s-server 的时候，服务出现了不可用，且无自动切换。或许对于高可用 K3s 集群来说，需要至少两台 Server 节点。

HTTPS

1
2
3

root@k3s-server:~# kubectl create secret tls my-tls-secret \
  --cert=path/to/cert/file \
  --key=path/to/key/file

在 nginx-ingress.yaml 中追加：

1
2
3
4
5

spec:
  tls:
  - hosts:
    - nginx.k3s.jiji.pro
    secretName: my-tls-secret

高内聚，低耦合

哲人：是的。即使你能将其带到水边也无法强迫其喝水。——岸见一郎《幸福的勇气》

在阿德勒看来，我们做任何事都应该“课题分离”，说白了就是不要多管闲事，自己管好自己的事。这种思想我相信没有人不知道，但是往往效果不是很好。很多情况下，你不得不去管别人的事——因为那件事切身地影响了你的利益，你和别人在某种程度上是一个命运共同体，无论是自愿还是被迫组成的。

在计算机工程中我们通常会把“课题分离”说成是“高内聚，低耦合”。什么是“高内聚”呢？就是尽可能只让一个模块负责一个功能。“低耦合”就是在说不要让两个负责不同业务的模块产生太多联系，应该尽可能地分离。这是一种设计模式——单一责任原则，其实就是计算机工程实践中的哲学。

之所以提出“高内聚，低耦合”，其实不难想象。计算机发展的这么些年里，肯定出现过很多糟糕而难以维护的代码，它们大多都是依赖于bug运行的，牵一发而动全身。想向这种烂代码里添加一个功能，就要冒着巨大的风险，有时候甚至还会把整个系统搞崩。其实这不是计算机的问题，这是人脑的缺陷，人脑很难同时处理太多的信息，而一个巨大的工程往往不可能被大脑同时处理，换句话说就是人脑的思考没有穷举代码的执行路径（当然这就需要测试），只是选择了当前认为的最优解（类似于贪心算法），所以经常会出现bug。

命运共同体

理性人，都喜欢博弈论。而命运共同体，就是建立一个组织，组织内的人具有相同的目标，这样获得的利益最大，甚至大过背叛。这是一种非常好的合作形式，因为它往往比较稳定，适合长期协作。例如合作伙伴关系的公司，夫妻二人，甚至是原为冤家但因利益临时结盟的团体，都可以组成这种命运共同体。这种命运共同体甚至可以推广到大国博弈，有核国家之间都不愿发动核战争，因为核捆绑的缘故，所以不发动核战争的都是赢家。

要想保障这个命运共同体的可靠，就需要让这个命运共同体能为加入者带来的利益足够大。这就像“零信任网络”一样，之所以要建立安全加密的可信网络，就是因为我们身处“零信任”之中，我们的报文在每一级的路由转发中都是透明的，要想保证不被窃听、重放，就需要加密。正是因为利益足够大，所以命运共同体就足够可靠。是啊，我们信不过人性，还信不过利益吗？

尊重和爱

哲人：例如，假设公司的领导是强势的独裁者，的确，员工们也许会无条件地服从命令，假装顺从。但是，这是基于恐惧的服从，根本没有一丁点尊重。即使领导高呼“必须尊重我”，也不会有人尊重，只会越来越离心。——岸见一郎《幸福的勇气》

尊重和爱，就是一种充分地接纳。一个人并不完美，往往他具有的优点，而缺点并不都是有意的，很多也是由潜意识支配的。我们无法要求一个人能够支配潜意识，如果你能理解潜意识和意识的区别，想必也更能接纳一个人的缺点吧。要先尊重，再学会爱，要尊重ta的差异，并爱ta的所有。

认知差别

如果我问你：“一部智能手机和一束百合花（不是 Lesbian）哪个更简单？”你会如何回答？

有的人会回答，那必然是百合花啊。花开花落，无非就是那么一束花，而智能手机结合网络，能够迅速了解时事。

也有的人会回答，那比如是手机啊。手机是人造的，总共也就那么些零件，而花是非常神奇的，我们至今都没有研究透所有花朵细胞与所有信号的传递过程，甚至对它的基因学研究也很有限。

这可能就是认知上的差别，不同的人对待同一事物的认知是不一样的，这可以说是思考角度的不同，但这必然是一个人的习惯的角度。每个人都有其自己独特思考问题的角度，如果不去相互尊重这种区别，非要步调一致地去思考问题，我想，那很多人思考和一个人思考又有什么区别呢？所以说我们需要充分尊重认知上的差异。

任何人都可以随时获得幸福

转变观念，即可获得幸福。阿德勒心理学，其实更像是一种哲学。既然人的一切烦恼都来源于人际关系，那么我们就用课题分离的方法来解决这个问题，从而解决我们的烦恼。

推荐阅读

• 岸见一郎 《被讨厌的勇气》
• 岸见一郎 《幸福的勇气》

区区一只亚麻大

简介

最近看了一部番，叫《山田君与7个魔女》，非常值得推荐给你。这部番与我之前看的《Charlotte》、物语系列、《青春猪头少年》都有一些共性，我们一会谈。我想先讲一下这部番的大致内容，第一集大概是讲述了一个不良少年，与校花在走楼梯的时候摔了不小心接吻了，然后这两人的身体就发生了互换，后来经过实验证实男主和谁接吻都可以进行身体互换，也就是说，交换身体，这是男主的超能力。

表面来看，男主的超能力是和别人交换身体，但是实际上拥有这个能力的却是校花，男主的能力更为强大，是可以复制别人的能力。这点与《Charlotte》就比较类似，男主的能力最初大家都认为是附身，但是最后发现男主只是通过附身别人来夺取别人能力的超能力。

深入

所以这部番的重点开始渐渐浮出水面，原来有7位魔女，她们拥有超能力，而校花的超能力是交换身体。于是在好奇心的驱使下他们便开始对超能力进行研究。他们逐渐认为，拥有超能力是因为一个人有痛苦的经历，拥有的超能力恰恰是为了弥补自己的痛苦，或者说是自卑。比如校花女主原本性格孤僻，没有朋友，经常受欺负，为了打发生活只好默默学习。但其实她特别希望交到朋友，也不希望受欺负，所以就获得了与他人交换身体的超能力，大概是希望可以和一个能帮助她的人交换，然后实现自己的愿望。而小田切宁宁想与别人竞争学生会长，于是获得了俘获的能力，可以俘获别人加入自己的势力。

就这个角度而言，每个人获得能力是因为自己需要得到救赎，作者行文思路与物语系列可以说是有异曲同工之妙。为什么我说物语系列？因为物语系列产生怪异的根本原因还是个人内心原因，比如说阿良良木君之所以遇到894然后迷路就是因为他不想回家，所以跟着迷途之牛走，自然也就会迷路。

超能力与我的思考

再来说说超能力的问题。《山田君与7个魔女》这部番和《Charlotte》这部番里面的超能力很是相似。前者男主的超能力是复制别人的能力，后者男主的超能力是夺走别人的能力。而最开始男主都并没有想到这一点，只是以为自己能进行身体交换或者是附身。

关于这个超能力，我有个疑问吧算是，是不是只要出现了超能力，一定会有人利用超能力去统治他人，而还有一些人只会用超能力去解决苦痛，带来幸福呢？我注意到好像大多数的番剧都是这样的，只要出现了超能力，就一定会有好人和坏人，他们的界限就是，是不是在用超能力为人民谋幸福，为民族谋复兴。我觉得不只是超能力，只要有了权力，就必然会有“好人”和“坏人”，好人实现大家的欲望，坏人只实现自己的欲望。

那么我不禁开始思考，如果一个人遭遇痛苦经历，那么出现超能力对这个人来说是好事还是坏事呢？我想既然超能力在这里是一种补偿机制，我又想到了心理学中的一个观点：“一个人越是自卑，越是需要变得比别人更强大来证明自己”但这种补偿机制真的会让这个人更健康地发展吗？我个人认为短期内可能有好处，长期肯定百害而无一利。

阿德勒说过，一切烦恼都来源于人际关系，其实这部番也正面地直接印证了这个观点。而解决这个烦恼的方法，同样也很简单，那就是不要为了别人而活，不要为了成为父母口中的乖孩子，成为老师口中的优秀生，成为公司里的好员工而活，而是要为了自己的幸福而活。好像有点儿跑题了，总之就是如果用阿德勒的观点来看待这件事，那么其实要获得幸福是不需要借助这些超能力的工具的，只要改变观念，就可以获得幸福。

而在番剧中，这个超能力的设定无疑是一个非常有趣的的卖点，同时也是一个将心理问题具象化的工具。说白了就是，超能力的使用过程，就是在弥补自己的自卑。而到了最后，超能力一定会消失，因为自己用不到超能力了，心结已经被解开了。所以不论是《山田君与7个魔女》、《Charlotte》、物语系列还是《青春猪头少年》，到最后超能力也好、怪异也好还是青春期综合症也好，都因为问题的解决而消失。

尾声

就我个人而言，对这部番评价很高。就包括我对这个《Charlotte》、物语系列和《青春猪头少年》的评价都很高，它们给我们带来了非常多的思考。这些思考可能是沉重的，尚未解决的问题，有时候给我感觉真的是两难问题。但无不带来感动，就像《Charlotte》的男主一样：“我拯救了全世界，却唯独忘记了你。”

所谓科幻小说家，就是研究现在的宇宙，并提出了颠覆性的观点，但又不想被别人看成是疯子，于是写成小说以启示后人。而科学家，便是直视了这些颠覆性的观点，认为它们无不道理，展开激烈的证明与证伪，所以才会有人认为科学家是疯子。——吉吉

我既没有科幻小说家的文笔，也没有科学家的能力，我只有一些一直以来坚信的想法。我认为我们研究宇宙的理论其实意义不大，并不能带来实质的改变，也就是满足我们的好奇心罢了。当然，你们不能认为我是疯子，至少当你阅读这篇文章时不会这么想，因为我会叫这么想的人不要阅读这篇文章，这样他就不能说我是疯子了。

嵌套宇宙观

宇宙是可以被创造的。自从我玩 Minecraft 以后，就对这个观点深信不疑，虽然直到今天我也还想不明白意识究竟是如何与人进行绑定的，但是我至少能够解释普遍的宇宙观了，当然一些其实都基于了一个数学原理——图灵完备，当然在理解宇宙这个层面的时候，你可能需要把它推广。

当然就要提出这两个论断:

1. 图灵完备的性质：如果已知宇宙U图灵完备，那么由宇宙U可派生宇宙U’.
2. 图灵完备的判定：如果存在宇宙U派生的宇宙U’，则宇宙U图灵完备.

要想证明上面的两个论断，我们必须要明确宇宙的定义，根据维基百科上对宇宙的定义:

The universe (Latin: universus) is all of space and time and their contents, including planets, stars, galaxies, and all other forms of matter and energy.

但是我觉得这个定义格局小了，凭什么宇宙里就必须得有planets, stars, galaxies之类的东西，凭什么宇宙里就必须要有能量。在我看来，就算是 Minecraft 里面的世界，也配称作一个宇宙，就算是生命游戏，也配称作一个宇宙。因此我们格局要大，所以我修改了它的定义，并以此来论述后文:

The universe (Chinese: 宇宙) is all of space or time or information, or each of their combination.

是的，宇宙，是一切空间、时间、信息，或它们每一个的组合。这包含了生命游戏中的宇宙，是由信息+时间组成的，也包含了 Minecraft 中的宇宙，是空间+时间+信息。

对于论断1，我采用的证明就是举一个正例，因为我们知道一切图灵完备的宇宙中都可以编写一个生命游戏，而生命游戏是一个宇宙，所以论断1就得证了。

对于论断2，它可以算是宇宙图灵完备的一个定义，我不知道该怎么去证明它，也许它就是个公理。如果有高手知道，不妨教教我，在此提前感谢。

换句话说，图灵完备就是可派生宇宙的充分必要条件。

光速

如果你充分理解了我的宇宙观，那么解释光速是很容易的事。因为宇宙是嵌套的，所以我们假设我们所处的宇宙是U1，则必然存在我们的父宇宙U0。光速就是，U0给U1分配了多少计算资源。

如果你不理解计算资源，那么你一定用过电脑吧，有个叫 VMware Workstation 的软件，可以创建虚拟机，其虚拟机和实体机，都满足我们对宇宙的定义。所以你可以理解成，现在有一个人想创建一个虚拟机，它分配资源的时候，给这个虚拟机分配了2个CPU核心，总共3.6GHz，那么这个虚拟机的“光速”就是3.6GHz，里面不管怎么折腾，都不会超过这个数值。

我们的宇宙由谁创造？为什么要被创造？

如果我们可以创造宇宙的话，那么我们就可以换位思考一下。我们可以创作一部电影，制作一款游戏，发明一种规则，那么我们玩什么要做这些事呢？没错，大多数情况下是为了娱乐。那么不妨猜想，我们的宇宙之所以被创造，就是有某种娱乐行为所带来的效果，换句话说，我们的宇宙是被在我们宇宙的上一级的一个实体（可能是生物也可能是别的什么物质）创造的，也许是为了娱乐，也许是为了进行某种研究。

有人说这是有神论，也不能算严格的错。但需要和现在的所谓的宗教信仰区分开，宗教是一种信仰，可能信仰的是神，但神一定是神，不会是某种机器或者数学原理。但我这里的宇宙观给出的结论是，宇宙确实是由某种“神”创造的，但是这种“神”不一定是那种人们想象中的观音菩萨状的神或是如来佛祖状的神，这种“神”很可能不会听你的愿望行事，也许这种“神”根本不理解人类的情感，但它创造了我们整个宇宙，给我们分配了约30万公里每秒的计算资源。

如何解释外祖母悖论？平行宇宙观和以“我”为中心的宇宙观

平行宇宙观与嵌套宇宙观并不冲突，不如说嵌套宇宙观是基础，平行宇宙观是让宇宙丰富多彩的一个工具。对于平行宇宙的解释网上有很多文章，也有人提出以人的能力根本无法对平行宇宙证明或证伪，因此这是个假说。我们认为这个假说具有合理性，因为使用它就可以解释之前不能解释的一些悖论，比如外祖母悖论。

世界上最遥远的距离，是你在存档A，而我在存档B。——知乎网友

但是要解释外祖母悖论，可能就会和我之前的理论产生冲突了，因为我之前说过，光速是无论如何都不可能超过的，那既然这样，也就不可能发明时光机，不可能回到过去杀死外祖母。但是这里可能是一种特殊情况，也就是我后文提出的沙盒逃逸，如果我们真发明了时光机，一定是钻了个现在宇宙的空子，而不是采用正经的宇宙定律发明出来的（或者说是没有遵循宇宙设计者的意愿，有“黑客”发现了宇宙的某个漏洞）。正如命运石之门这个番里面采用了微波炉莫名其妙发明了时光机一样，当然这个番里面也有很多有意思的关于宇宙的观点，推荐读者观看。

如果说，真有人找到了宇宙的某个时间漏洞，发明出了时光机，然后坐着时光机（也有可能只是意识坐着时光机，或者只有短信坐着时光机回去了），在自己父母出生前把他们的父母杀死，你还会存在吗？我给出一个结论：会存在，并且不构成悖论。可以理解成，存档A的你跳跃到了存档B杀死了一个人，然后回到了存档A，这样存档A除了你的心理没有什么改变，存档B就是一个人莫名其妙地被杀死了，这两个存档是独立且隔离的。所以时光机的产生，并不会出现悖论，只是需要寻找到一个宇宙的时间漏洞。

平行宇宙是可能的，但无疑对计算资源是一个挑战，因为同时计算无穷级的宇宙，就算是上一层宇宙，我想也需要很大的算力吧。我在此又提出一个以“我”为中心的宇宙观。

什么叫以“我”为中心的宇宙观，就是除了“我”以外的人都是NPC，都是陪着“我”玩“地球OL”的一个个NPC。而这些NPC设计地非常真实，有的叫“动物”，有的叫“植物”，还有一些环境因素，这些全部都是为了“我”一个人虚拟出来的。所以说我们不知道是否身处某个“缸中之脑”，但却足矣提出这个假说。我这个观点是不可能被证伪的，因为你无法确定别人是不是NPC，你无法通感别人的意识（因为你所见到的别人，都是自己眼中的别人，自己意识感知到的别人的投影，并非真正的别人，当然我这里的“别人”除了指代人，还指代一切生物）。在这个观点中，我不认为任何除了“我”以外的生物具有意识，他们的表现机器人也可以胜任。哪怕有一天，就算将大脑研究地明明白白，你也只是知道，原来人类大脑是可以用工程学的方法去制造的，甚至可以直接3D打印，这还能更加印证我的观点。当然，你就是“我”，读者需要自行代入“我”，以体会我的言论是否合理。

如何解释蝴蝶效应？线性同余法与随机链

蝴蝶效应是指一个微小的变化能影响事物的发展，证实了事物的发展具有复杂性。

一只南美洲亚马逊河流域热带雨林中的蝴蝶，偶尔扇动几下翅膀，可以在两周以后引起美国得克萨斯州的一场龙卷风。

但是在我看来，不管这只蝴蝶扇不扇动翅膀，两周以后美国得克萨斯州都会刮起龙卷风。或许在扇动翅膀的那个平行宇宙中，刮龙卷风的直接原因就是蝴蝶扇动翅膀导致的多米诺骨牌效应，但在那个蝴蝶未扇动翅膀的平行宇宙中，刮龙卷风的直接原因又恰恰是蝴蝶没扇动翅膀导致了蜻蜓扇动翅膀，又导致了多米诺骨牌效应，从而刮起龙卷风。这有点像宿命论，但比宿命论格局要大，因为宿命论只针对的是人的命运与当前的宇宙，我将其推广到了平行宇宙中。并且在这种观点里，也不完全是这样的，因为平行宇宙也存在了嵌套关系。

如果我们从家去学校，可以搭乘公交车、地铁或是开私家车，那么我们就有两个状态结点，一个是家，一个是学校，连接这两个结点的至少有三种交通工具:

而这种结点组存在很多，现实中可能存在多组这样的结点:

我们都学过线性同余法生成随机数，本质上就是去计算这个式子:

1

RandSeed = (P * RandSeed + Q) % M

所以我认为，上图中A结点就是最初的种子，B、C、D都是由A结点派生的。这种子结构，会在宇宙中频繁出现，递归出现。就像计算机中的二叉结构明明只定义了左孩子和右孩子，居然可以出现非常复杂的二叉树。使用这种子结构来回嵌套，便可以具有丰富多彩的平行宇宙。这个链，我给它取了个名字，叫随机链。

沙盒逃逸

后来我就在思考，我们的宇宙会不会发生沙盒逃逸现象？也就是我们的宇宙是否存在某个漏洞，能让我们逃逸到上层宇宙？对此我给出的解释是，如果你发现了0day，不妨卖给我，作为回报，我会教你如何利用好这个0day。

意识从何而来？

根据宇宙嵌套理论，意识的来源是上一层宇宙的递归调用。如果不能理解的话，请允许我用docker来说明问题。

启动一个宇宙:

1

jiji@server:~$ sudo docker run -itd --name universe mmdjiji/universe

进入到一个宇宙:

1
2

jiji@server:~$ sudo docker exec -it universe /bin/bash
root@7bac35555ef3:/# 

离开一个宇宙:

1
2
3

root@7bac35555ef3:/# exit
exit
jiji@server:~$ 

因此，意识来源于我们调用了上一层宇宙的 docker exec ，死亡意味着离开现在的宇宙。

当我再次醒来，只见我回到了原始的宇宙，我逐渐想起了自己是谁。站着，看着眼前显示屏中的按钮，一动也不动：确认出生在“地球”上，基因随机选择。

至于为什么进入了我们现在的宇宙没有了原始宇宙的记忆，我想这可能是上一级宇宙刻意做的某种隔离机制，类似于CPU进行堆栈调用时的寄存器保护机制。它这么做可能有它的原因，我推测就大概是为了能充分体验这个宇宙。

预言

我预言，不远的将来，人类会发明出来人造细胞，单器官克隆，实现脑机接口。人类未来的很长一段时间，物理学将没有什么质的突破，除非到发现宇宙漏洞的那一天。而人类医学领域将会有前所未有的突破，因为这些都是不违反物理定律的。人类光刻机技术会得到突破，计算机与虚拟化领域也会得到突破，很快就会出现成熟的自动驾驶，未来甚至可能有一些爱好者，常年生活在虚拟的宇宙中。你觉得长生不死是好事吗，但是意识大概是有寿命的，在没有研究明白意识之前，人类仍然不能长生不死。

开始之前，想分享我去云南昆明吃过的米线，无图无真相，上图！

生肉生菜，放进这刚出锅的热汤，不一会的工夫就熟了。但这个时候还不能直接喝汤，因为汤还很烫。您想想，把生的东西放进去就能煮熟的汤，它能不烫嘛！这个时候，适合夹起几片肉、几片菜来吃，非常的香啊。最后，汤已经逐渐冷却到了可以喝的温度，这时双手抱起大碗，吨吨吨。鲜美的味道流经了喉咙，我对云南美食的记忆，也就从米线开始。

魔女之旅

在和平国罗贝塔，出现了史上最年轻，十四岁就在魔法考试中合格，成为魔女见习生的少女。没错，就是我。——伊蕾娜

那么，问题来了。正准备前往充满杀戮的山岳地区，有着令人惊叹之美貌的魔女，究竟是谁呢？没错，就是18岁的我。——伊蕾娜

我很喜欢这部番，并且非常期待这部番能有续作。这部番就非常像《小王子》，我不多说了想看的就自己去看吧，懂的都懂。做个白日梦，哪天自己能够去到世界各地旅游，能够经历许多故事，哪怕是以一名旁观者的身份，我想也可以从中学到很多。

旅行

所以什么才是旅行呢？在继续往后阅读之前，不妨你也来思考一下这个问题，对于你来说，什么是旅行？旅行有什么意义？

在我看来，旅行就是去体验与平时不一样的事，吃平日里没吃过的食物，接触不熟悉的风土人情。所以说，旅行也是一种学习的过程，所谓“读万卷书，行万里路”，其实不无道理，这句话一方面可以广义地理解成我们学习了很多理论知识还要动手去实践，另一方面，从狭义的角度上，对于旅行本身就是可以学习到很多东西的。旅行，收获了知识、又收获了快乐，这才是最纯粹的学习啊。

我在旅行时有一些小爱好，比如给美丽的景色拍照，记录一下我还去过这么美丽的地方。或许过了一段时间再去翻看之前的照片，可以怀着某种心情，与人分享自己的经历。当然到不同地方旅行时可以品尝当地美食，谁又能拒绝美食呢？这也是我在文章一开始就举出了云南米线的例子，除此之外我喜欢的还有杭州的红烧肉（非常精致）、北京的烤鸭（鸭皮蘸白糖绝了）、内蒙的奶茶（不是那种奶茶店里买的特别甜的奶茶，是咸咸的味道）……

旅行的乐趣，除了美食，还可以了解当地人的生活方式。或许有的人并不满足于自己当下的生活方式，想要有所改变，又或者有的人比较喜欢钻研什么才是真正适合自己、适合他人的生活方式。去经历、去体验，可以为建立自己的成熟想法提供素材。当然，由于我旅行的经历也并不丰富，下面的例子也都是我结合了经历与传闻所举出的。像我去过上海，也去过北京，对比这两个城市，我发现在上海可以经常看到穿着洛丽塔服装的小姐姐，也有穿着汉服的小姐姐，我当时在夏天还看到了一个穿着羽绒服的小姐姐，而在北京却很少看到这些场景，大概上海的文化包容性要更强一点。可能，喜欢上海的这种生活方式的人，在接触新鲜事物时可能更容易上手吧。另外我还觉得南方人的生活节奏比北方人普遍要慢，当然这一点我觉得我能举出的例子不够充分，或许也有很多反例吧。

正如旅行的伊蕾娜一样，游历不同的国家，在实践中可以学习到很多，也可以认识志同道合的人，例如伊蕾娜认识了沙耶小姐。在旅行的路途中，一定会走出“舒适圈”，从而带来更多能力的增长。当然这也只是旅行意义的一部分，旅行最本质的意义就是让你知道别人在干什么，你评价一下别人干的怎么样，然后决定自己该做什么。我也很想骑着一把扫帚，来一场说走就走的旅行，如果没有会飞的扫帚，就请用任意门代替它。以后再来分享我的旅行经历吧，如果有机会。

最后，我想听听你对旅行的看法。如果没有什么成体系的想法，也不妨和我分享你的一次旅行见闻，也让我长长见识。

上次思考这个问题，还是在上次。

第一次思考这个问题，还是在高考结束时。不知道你能不能明白，高考结束之后，压力突然小了很多，有时候会迷茫，不知道该做什么。

我来分享一下我高考结束后总共做了什么吧。首先我先去看了个电影，当时热播的《哆啦A梦：大雄的月球探险记》，虽然《哆啦A梦》剧场版的质量一直处于下降态势（《伴我同行》系列除外），但是作为一个资深哆啦粉还是不能错过每一场电影。后来我去初中和老师聊了很多过往，还帮当时的数学老师批改起了学生的作业。毕业典礼过后，我报名了业余无线电A类资格证的考试，随后当然顺利拿到执照。后来我买了台3D打印机，打印了一些想打印的东西。和朋友打了几天GTA5，和家人一块去浙江上海旅游，和朋友在北京自行车专用道上骑行。

但我一直是有信念的，曾经的我一直把研究计算机技术和电子技术作为第一要务，因此就算是失去了高考的压力，我也并没有陷入无事可做的局面，反而可以专心的做我想研究的事。所以我从高考结束到今天，技术方面的进步非常大，并且还长期保持很大的进步空间。

思考

也就是最近吧，我开始批判性地思考，我人生中最重要的事就是研究计算机技术和电子技术吗？

现在我可以给出一个确切的回答：否定。

我得出了一个结论：技术只是实现理想的工具，可以热爱某项技术，但人生不应该只有技术，人生应该活得更精彩些。

Charlotte

说起来这部番脑洞奇大无比，而又十分感人。故事的女主叫友利奈绪，男主叫乙坂有宇。起因是超能力莫名其妙地在青春期少年中出现，男主的超能力是夺取别人的超能力（事实上男主前期误以为自己的超能力是附身别人身上5秒，但这只是夺走别人超能力的方法），超能力听起来本来是一件很酷的事情，但总是有邪恶的组织盯上这群有超能力的孩子并想要利用他们，这会给孩子们带来不幸。为了摆脱这个局面，男主决定把世界上所有人的超能力都夺走，这样就能保护所有超能力者。

女主在男主出发前给了男主一个单词本，还说“等你回来，我们就在一起”。男主一路上多次差点忘记自己要做什么，甚至差点黑化。这个单词本，正是男主最后的信念，让男主最终完成任务回到友利奈绪身边。

我刚开始对此是持怀疑态度的，一个人怎么会忘记自己要做什么呢？那种事想一想不就记起来了吗？但是经过深思熟虑，我悟了。男主并非是真的忘记了自己要做什么，而是在思考，事到如今，自己这么做下去真的有意义吗，不如趁着现在的机会做点别的事情，至少可以得到暂时的满足。但男主选择了继续下去，我不能说这是正确的，我只能说这是善始善终，不忘初心。

因为失去我们伤怀，但也因为失去，我们才可以拥有新的未来。

如果从一开始就可平平淡淡过一生多好，何必经历那么多磨难？
经磨难后方知平淡是真。
还好，未来还在。

我的一些想法

之前和一位朋友聊过这件事，她当时告诉我大学最重要的可不一定是学习哦，还有很多很多别的事。

后来我就打算开始把精力多放在生活上一点，不为别的，咱不能为了追求技术而忽略了生活，毕竟咱是热爱生活的人。

我脑海里一直有一幅理想的图景，那是在遥远的2077年的将来，我和恋爱了50年的老伴住在我亲手装修的精致的小屋里，温馨而亲切。里面有一个房间叫实验室，桌上放着热风枪、烙铁、加热台以及我的短波电台，旁边放着一个机柜，里面有家庭网络的交换机、UPS以及我心爱的戴尔服务器。还有一个房间叫书房，里面有我和老伴的各种藏书，用我亲手开发的图书管理系统来统一管理。还有一个房间是我和老伴一起睡觉的房间。要是我们都喜欢小孩，那我还得给未来的小孩准备一个房间。客厅中摆放着我亲手种的绿萝，还摆放着一架黑色钢琴。早上起床了，我便开着车带着老伴一起去呼伦贝尔的草原上，一起去捕捉天空中最纯粹的星空，一起去聆听动物的叫声，以及从我电台里发出的阵阵背噪。拿起电台，按下PTT键，向宇宙呼叫CQ，得不到任何回应，那想必是外星人在说：“不要回答！不要回答！不要回答！”

我要用接下来的时间，亲手实现这一切。

现有以电阻 $r_1=r_2=r_3=1\Omega$ 构成的一个无限长梯形网络（如图所示），求 $a,b$ 之间的等效电阻.

常规解法

将 $R_{ab}$ 去掉一个循环节的网络看作 $R_{ab}’$ ，如下图所示.

根据电阻串并联的规律知 $R_{ab}=r_1+\frac{r_2R_{ab}’}{r_2+R_{ab}’}+r_3$ .

由于有无穷多节，相差一节对电阻的影响微乎其微（可看作是无穷小），因此 $R_{ab}’=R_{ab}$ .

将 $r_1=r_2=r_3=1\Omega$ 代入后求得 $R_{ab}=1+\sqrt3\ \Omega$ .

常规解法的缺陷

常规解法虽然有一定道理，但使用“微乎其微”等形容词来描述不具有很强的说服力。另外，常规解法不能解决有限节梯形网络的问题，如果我们要求解的等效电阻并不是无穷多节的循环，而是有限节 $n$ 时的等效电阻，那么就不能使用常规解法来解决.

新型解法

我们不妨设这个梯形网络的节数为 $n$ ，此时 $a,b$ 之间的等效电阻为 $R_{ab}|_{n}$ ，观察下列情况

• 当 $n=1$ 时，$R_{ab}|_{n=1}=r_1+r_2+r_3$

• 当 $n=2$ 时，$R_{ab}|_{n=2}=r_1+\frac{r_2R_{ab}|_{n=1}}{r_2+R_{ab}|_{n=1}}+r_3$

• 当 $n=3$ 时，$R_{ab}|_{n=3}=r_1+\frac{r_2R_{ab}|_{n=2}}{r_2+R_{ab}|_{n=2}}+r_3$

• ……

• 当 $n=n$ 时，$R_{ab}|_{n}=r_1+\frac{r_2R_{ab}|_{n-1}}{r_2+R_{ab}|_{n-1}}+r_3$

由此，我们发现了对于一般的 $n$ ，存在 $R_{ab}|_{n}$ 与 $R_{ab}|_{n-1}$ 之间的递推关系式.

为简化计算，我们将 $r_1=r_2=r_3=1\Omega$ 代入，获得 $R_{ab}|_{n}$ 与 $R_{ab}|_{n-1}$ 之间的常量递推关系，并写以数列形式.

设$a_n=R_{ab}|_{n}$ ，则$a_{n-1}=R_{ab}|_{n-1}$ ，有 $a_n=\frac{3a_{n-1}＋2}{a_{n-1}＋1}\ (n≥2)$ ，其中 $a_1=3$ .

令 $x=\frac{3x+2}{x+1}$ ，即 $x^2-2x-2=0$ ，此方程存在两根 $x_1=1-\sqrt3,\ x_2=1+\sqrt3$ .

由于 $x_1≠x_2$ ，有 $\frac{a_{n}-x_1}{a_{n}-x_2}=q\frac{a_{n-1}-x_1}{a_{n-1}-x_2}$ ，其中 $q=\frac{3-x_1}{3-x_2}$ .

根据等比数列通项公式，知 $\frac{a_{n}-x_1}{a_{n}-x_2}=(\frac{3-x_1}{3-x_2})^n=(2+\sqrt3)^{2n}$ .

化简后求得 $a_n=\frac{(2+\sqrt3)^{2n}(1+\sqrt3)-(1-\sqrt3)}{(2+\sqrt3)^{2n}-1}\ (n≥2)$ ，为 $a_n$ 的封闭表达式.

因此 $R_{ab}|_{n}=a_n\ (\Omega)$ ，取极限 $R_{ab}=\lim\limits_{x\rightarrow\infty}a_n\ (\Omega)$ 即为无穷多节梯形网络的等效电阻.

$\lim\limits_{x\rightarrow\infty}a_n=\lim\limits_{x\rightarrow\infty}\frac{(2+\sqrt3)^{2n}(1+\sqrt3)-(1-\sqrt3)}{(2+\sqrt3)^{2n}-1}=\lim\limits_{x\rightarrow\infty}\frac{1+\sqrt3-\frac{1-\sqrt3}{(2+\sqrt3)^{2n}}}{1-\frac{1}{(2+\sqrt3)^{2n}}}=1+\sqrt3$ .

所以，对于有无穷多节的等效电阻 $R_{ab}=1+\sqrt3\ \Omega$ .

新型解法的优缺点

优点：对无限长梯形网络等效电阻问题给出了严谨的证明，且适用于一般有限节的情况.

缺点：过程较为复杂，求解难度大.

慢节奏==摸鱼?

不知道你有没有看过这部番剧：《打了300年的史莱姆，不知不觉就练到了满级》，没有的话可以点进去看。

普通的OL·相泽梓因过量工作而过劳死，在异世界转生成为不老不死的魔女亚梓莎。出于对前世的反省，她开始在边境的高原度过悠闲的慢生活。打倒史莱姆赚点小钱，像个魔女一样制作魔药提供给山麓的村子。其他就没什么特别的了。在持续过着这种生活的过程中，她开始被人称作「高原的魔女大人」并受到人们的喜爱。

在这之后过了300年。凭借不断打倒史莱姆获得的经验值，亚梓莎不知不觉间已经LV99=成为了世界最强。这个传言开始扩散，对能力有自信的冒险者自不必说，就连前来挑起决斗的龙女以及称亚梓莎为母亲的怪物少女都找上门来——！？

慢节奏可以成事。大多数情况下，事不是一朝一夕就能完成的，而是要经过长期量的积累，质变源于量变。因此成不成事与生活节奏的快慢无关，只与你能否坚持下来有关。慢节奏可以让你变得不那么浮躁，用心地把事做好。

但是呢

慢节奏不等于做什么事都不着急，总是等到deadline的时候才想起来去做 （这叫拖延症） 。这部番剧中的主人公之所以得以成为世界最强是因为她可以活300年！（事实上她可以活的更长）你我皆不能活这么长，因此在有限的时间内，我们要合理地分配，这样才能成为我们想成为的自己。

读万卷书，行万里路

以前我不能理解这句话的意义，可能是因为我对生命的意义不够理解。当时我就在想啊，我们人生的终极目标是什么。赚钱？搞研究造福全人类？成为明星在人群中闪耀？不，都不是，至少对我来说。之前看到过两位老人在地铁站，弹一架钢琴，我觉得，人生的意义也就是这了，操劳半生，只为了最后，能无忧无虑地，做着自己喜欢的事。

所以我觉得我开始渐渐理解为什么要行万里路了，那是去体验不同的生活方式，这样就能知道自己喜欢什么了，然后在无忧无虑的年纪，沐浴着美好的夕阳，做着自己最喜欢的事。

学长的话

偶然和学长聊起这个话题，他说：

快节奏和慢节奏是相对的。什么叫快节奏呢？就是，你给别人干事儿，干了一整天。忙忙碌碌一个接一个，没有什么时间做自己的事儿，我个人理解啊，这就叫快节奏。

你比如说我小的时候，我喜欢做纸模型。就是拿一些纸壳去做一些赛车坦克飞机大炮啥的。这种事儿，你让我干一天，我也不觉得累。所以，即使我忙碌了一整天，我也依然觉得这个节奏是慢的。

但是你要是说今天去银行，明天跑科委，操碎了心，磨破了嘴，身板差点没累毁，还得给寡妇挑水，这种生活儿都是给别人忙活，你这一天才会觉得非常忙碌。

这个就得涉及到节奏快慢的定义，不同人可能对它的理解不同。我觉得什么叫快节奏，什么叫慢节奏，就是如果一个环境，一个气氛不能够让你紧张起来了。即使你很忙碌，这也是慢节奏。

在我看来，学长对慢节奏的理解就是，做自己喜欢的事，就是慢节奏。我觉得这种观点挺好的，因为做自己喜欢的事，会令人舒适，心旷神怡。

慢节奏生活

慢节奏生活，可能是一种心态，包含着你对自己喜欢做的事的向往。哪怕一时半会不能进入这种慢节奏的生活，但我希望有生之年，来到自己喜欢的事情面前，无忧无虑地忙碌起来。

明天就是清明节了，今天我想聊聊这个节日。以下是我从《百度百科》上摘取的一段文字：

清明节，又称踏青节、行清节、三月节、祭祖节等，节期在仲春与暮春之交。清明节源自上古时代的祖先信仰与春祭礼俗，兼具自然与人文两大内涵，既是自然节气点，也是传统节日。扫墓祭祖与踏青郊游是清明节的两大礼俗主题，这两大传统礼俗主题在中国自古传承，至今不辍。——《百度百科》

说起来这个节日的主旋律是“扫墓祭祖”和“踏青旅游”。

扫墓祭祖

天下没有不散的宴席：人，出生了就会死，只有信息是得以永恒存在的。我们继承了祖先的知识，譬如牛顿的微积分、麦克斯韦的电磁波理论以及爱因斯坦的相对论，没有他们，我们就不可能有今天。扫墓祭祖时，我想也是为了表达对祖先的怀念与感谢。

踏青旅游

踏青旅游则是扫墓之余，感受春回大地、万物复苏的景象。说起来清明虽然是祭祀死者的节日，但也未必过于沉重。逝去的祖先们，想必一定希望自己的子孙，能够在自己死后，生活的健康幸福吧。在这样的日子，去感受春天，感受生命，感受万物的复苏，你便会得知，生命的沉重。

敬畏生命

前几天我骑自行车的时候发现了一对夫妇，他们逆行骑着车，每个人的左手都提着一个精致的花篮，没有看清是什么种类的花，但是是纯白的，我想那应该是扫墓用的吧。

于是我瞬间就开始思考他们是怀着怎样的一种心理去这么做的。为什么可以做到这种程度？后来我设身处地地去思考，假设我死了，有幸留下后代，如果我的儿子女儿或是孙子孙女在路上出了什么事，仅仅是因为来给我扫墓，那我会觉得很愧疚。我应该并不会希望他们能为我做什么，我只是希望他们能够好好地，幸福地生活下去，这样就够了。

最近我的一个朋友去世了，我从来都没有想到过。我非常懊悔，为什么他生前就没有留下一张两个人的合照呢？果然，人只有失去了才会懂得珍惜。

我的宠物

我曾经养过一只狗，他非常可爱非常乖，虽然有时候很调皮不听话，叫他出来洗澡的时候还钻到沙发底下，用扫把扫沙发底下的时候还会咬住扫把，似乎在告诉我：这里是我的地盘。

后来在我上完OI的课回家后，听到了他去世的消息，痛哭了很多天。我那时就在想，彩虹桥是不是真的存在呢？

在天堂靠近这里的一侧，有个地方叫彩虹桥。当一个动物死去的时候，要是他被这里某个人深爱着的话，他就会去彩虹桥。

那里有草地，有山坡，让我们深爱着的朋友们在一起奔跑和玩耍。那里阳光明媚，水草肥美，我们的朋友们过着温暖又舒适的日子。所有曾被疾病和衰老折磨的，都恢复了健康和活力。那些受伤或残疾的，又变得健全和强壮，就如同我们梦中。

在那些逝去的日子里，他们曾经的那样，他们快乐又幸福。只有一个小小的不足，他们每一个都在思念一个人啊，对他特别的那一个，却不得不被留在了那一边，他们整日在一起奔跑和玩耍。

直到有一天，其中的一个突然停下，凝视着远方。他明亮的眼眸变得热切，他渴望的身躯开始颤栗，突然他离群而出，开始奔跑，飞跑过草地，越来越快。他看见了你！你和你深爱的朋友终于相见，你们拥抱在一起，再也不分离。他快乐地不停舔着你的脸，你的手再次抚摸着他的头。你又能看着他的眼睛，那充满信任的眼睛，虽然曾经失去了那么久，却不曾片刻离开你的心。然后，你们一起跨过那彩虹桥。

虽然我并不迷信，但我宁可希望有朝一日，我来到这座桥，一眼就看到了他，那金黄色的身躯，傲娇的脸庞，扑到我怀里。我抱着他，一起跨过这座桥。

可塑性记忆

愿你有一天能和你最重要的人重逢。——《可塑性记忆》弹幕

就算是娱乐性的作品，也存在思想价值，例如《缘之空》就表达了不被他人理解的少数群体是否应该被伦理等规矩约束。有一部动漫作品，名为《可塑性记忆》，则表达出了对生命的敬畏。我体会到了艾拉离开男主时，男主的感觉，和我的小狗离开我时我的感觉是一样的，何等的不舍。

水果篮子

《水果篮子》是一部动漫作品，它讲述的是关于十二生肖的故事。很久很久以前，有一位神明，这位神明非常非常孤独，因为没有人陪他玩。有一天，他还是一个人孤零零地，有一只猫向他走去，陪他玩，他们非常快乐。于是这位神明就在想，既然人类不陪我玩，那么动物是不是会陪我玩呢？于是他向动物们写信，邀请他们来参加宴会。宴会上来了十二个动物，第一个来的是老鼠，第二个来的是牛。他们经常开宴会，动物们一起和谐相处，神明非常开心。但是，天下哪有不散的宴席，猫的寿命到了，快要不行了。大家发现，这样下去，总有一天，大家都会一个个死去。于是神明将大家联系在一起，纵使转生，也能再次团聚。

这样的故事令人感动，但神明做的事给大家带来了困扰。猫在最后说，它不需要永远，它想让神明勇敢地接受这种结束。这话一出，神明听了很出乎意料，动物们很伤心，开始唾弃猫，认为猫背叛了他们。在他们转生后，认识了许多新的朋友，大家一起玩，也会十分快乐。而这种联系，似乎成了一种束缚、一种枷锁，转生后的十二生肖虽然变成了人，却无法挣脱，只能接受命运，和大家一起团聚，再次举办宴会。直到有一天，每个十二生肖都成长了，他们各自找到了陪伴自己的人，这种联系就断掉了，故事戛然而止。

于是我就在思考，生命到底应该何去何从，我们究竟要勇敢地接受结束，还是要永恒地活下去。

宠物克隆

我也不知何时听说有宠物克隆，后来查了一下确实是真的，并且已经民用了。有一家公司，叫“希诺谷”，目前就在搞这个产业。我也不评价这家公司怎样，我只是想谈谈“宠物克隆”这件事。

据我了解，宠物克隆，并不能克隆宠物的记忆。也就是说，当你接走克隆后的宠物，样子和原宠物小时候的样子一模一样，虽然基因一样，但如果经历不同，之后的性格也可能不同。但就算这样，也有许多人克隆他们心爱的宠物。这些人是放不下失去的心情，就算不是同一只，也要欺骗自己，这是它生命的延续，作为自己的精神寄托。

敬畏自然

我希望我的家人能够身体健康，我希望自己有能力，保护自己和爱的人、动物以及植物。说起来我还挺贪心的呢。

自然界非常神奇，直到现在我都没有想明白这个宇宙的运行原理。自然界存在了太多未知，如果我们还没有对它足够熟悉，就要心存敬畏。