现在我们知道了有向量，还有向量相关的运算——向量加减与向量数乘。可是大家可能会这个向量数乘感到不自在——这始终是一个向量与一个实数两种不同对象之间的乘法，交换律无从谈起。那像实数可以跟实数自己相乘一样，向量能不能也跟向量相乘呢？

答案是——可以有。我们来引入一种名为点乘的向量“乘法”。

我们先看两个问题：

旧卡本家灵摆怪兽的灵摆效果按下级与上级分别统一。等级为1到8，灵摆刻度为倒过来的8到1。奇数等级为偶数刻度，偶数等级为奇数刻度。偶数等级都有一个奇数刻度时相关的效果，奇数等级都有一个偶数刻度时相关的效果。

两张新本家下级刻度分别为0与9，依然是奇数等级为偶数刻度，偶数等级为奇数刻度。

由于本家的灵摆刻度和等级互不相同（但新卡与老卡等级有重复），以下也用刻度或等级简称各个本家。

没有仪式魔法的仪式卡组。下级可以场上发动效果进行仪式召唤，上级可以手卡发动效果进行仪式召唤。效果大多没有一回合一次，有在对方回合进行仪式召唤、从卡组进行仪式召唤、从墓地进行仪式召唤、出地属性结界像等时髦效果。

缺点是两卡动，吃灰死，初动要亏手，吃坑后没有补点。

与【游戏王大学习】灵摆搓澡流（二）——进化森蚺正规扎克类似，也是不通过霸王龙之魂、霸王天龙之魂或宙读的怪兽效果，让扎克正规登场的卡组。通过双门齐P检索瞬间融合，在对方回合融合霸王龙 扎克。

优点是：

• 炸P要求次数更少，容错率提高，有些场合紫眷龙可以不复制银金而是复制同调龙护航
• 大概率能做到对方回合扎克+白眷龙
• 能用到扎克的登场炸全场的效果

缺点是：

• 终场没有任何康，需要融合之后才能出风雷龙，容易被几个检索之后一张大牌清后场
• 扎克要在对方回合结束才上P，P效果相当于没有

出异色眼日焰龙，直接同调同调扎克后变身光扎克。用森蚺融合扎克，然后被风雷龙炸去P区。

双扎克贴P需要清理掉两个P区，但奇迹特召又需要齐P。而用森蚺融合扎克后不能特召，因此奇迹特召效果必须在清理掉另一个P区之前使用。

扎克默认用风雷龙效果破坏，除此之外还需要：

• 一次破坏清理P区低刻度（高刻度光眷龙在扎克在场时可以自跳）
• 一次破坏光扎克贴P 共2次破坏

用霸王门之魔术师检索灵摆进化，进行第二次灵摆召唤。终端为用异色眼绝零龙做出来的异色眼风雷龙、用霸王眷龙 光辉亚龙同调的装弹枪管狞猛龙、用零碎做出来的I：P伪装舞会莱娜。

刚炼装勇士·银金公主2效果与宙读之魔术士1效果都不是同名一回合一次，因此可以用霸王眷龙 凶饿毒复制银金、或通过不断苏生银金来不断使用。

• 提供破坏点
• 积累额外资源

莫嘲龙娘身板柔， 融合耀光加天球。 战阶变身管家炸， 资源运转鬼见愁。

下级双召赚资源，进战阶回手变大龙。融合召唤的三只大龙都有不错的效果，先攻时争取做到半龙女仆·贴身龙女 + 天球之圣刻印 ，在对方回合融合出三色康 半龙女仆·耀光龙女 。

最早，欧拉研究总结了短程线问题、等周问题等一大类类似“求取得极值时的曲线”的问题，并提出能使用了后来被称为“欧拉-拉格朗日方程”的通用的方法来求解这类问题。可惜此时欧拉的推导过程使用了大量分析与几何结合的手段，十分复杂也缺乏严谨，欧拉自己也对此并不满意。[^长河劫变分法]

后来，拉格朗日引入了变分符号 $\delta$ 来表示函数的“微小变化”，将求极值的问题转化为解微分方程的问题，使推导过程更加严谨。拉格朗日在欧拉-拉格朗日方程的基础上继续完善，发明了变分法——处理泛函极值问题的纯分析方法，并利用变分法提出了最小作用量原理的正确形式。[^长河劫变分法][^长河劫分析力学]

讲线性代数，被同济版线性代数毒害过的人可能都会被唤醒藏于心底的恐惧：哇！又要讲行列式、对角化、增广矩阵算来算去了！

其实线性代数没那么可怕。我们可以很直观地、很感性地去理解线性代数。

线性代数，关键当然在于“线性”。（应该没人会觉得线性代数的关键在于“代数”吧？）如果一个函数 $f(x)$ 有以下性质：

外燃内燃剑极节极…… 兄弟拿兄弟，不用叫，就能跳。 两个四，绝命导爆，你喊效果我就爆！

开场白？没有！立刻进入正题。

正如 DAODADA 中唱的一样，全部下级不用叫就能跳，大哥雷火沸动死旋爆震机有不限一回合一次的炸卡，一次代破和 3000 点的攻击力。配合场地雷火沸动交界机阴爆的效果处理时的怪效康，速攻的苏生，能用极其轻量的资源、以相对简单的过程来做成别的卡组打破头都过不去的场子。

同调杯后紧接着就来了编年史杯。

这次编年史杯环境比较舒适，没有各路神仙横跳。三套预组里六武众在这个环境可以说是风生水起。六武众预组里有新卡三张六武众的指南番和三张六武众的破戒僧，额外还放了三张真魔六武众-紫炎，足够强劲。能出真魔紫炎就赢一半，能出三个终端能赢大部分卡组。

以前算是玩过一点六武众，现在趁杯赛重新学习一下六武众卡组，这篇文章也算是我的学习笔记。可能会有很多很多谬误，如果发现了请评论指正。

这次的同调杯三个预组中，唯一算是比较有强度的就是水晶机巧了。

水机卡组刚出来的时候我也算是小小玩过，但现在的水晶机巧已经跟第 9 期那时完全不同打法了。连一刻都没有为继承玻纤的死亡哀悼，立即赶到 MD 的是 12 期的五张新卡！三位玉晶、柠晶救龙、圣天骸晶、绿阵、红阵，5张新时代的补强可以说完全重构了水晶机巧这个卡组。

为了打这次同调杯，我专门重新学习了水机卡组。这篇文章也算是学习过程中的总结笔记。可能会有很多很多谬误，如果发现了请评论指正。

试着用了一下 cursor ，感觉还不错。非技术也能半小时能做一款 App 可能是真的。但替代不了技术岗也是真的。

虽然 Cursor 基于 VSCode 二次开发，但可能为了做 AI 功能把 Editor Pooling 或者 File Watching 能力搞坏了，经常 Apply 了修改后 Explorer 和 Editor 里没有及时反馈。然后自动补全功能因为可以删内容导致手感跟 VSCode 里的 Copilot 比较不同，用起来比较 annoying 。

作为一个基于 VSCode 二次开发的编辑器，Cursor 在文件系统监控方面存在一些问题。当对文件进行修改后，Explorer 和 Editor 经常无法及时反映这些变化，这可能是因为为了实现 AI 功能而对原有的 Editor Pooling 或 File Watching 机制进行了修改导致的。

我们之前说的都是用于部署 Pod 的资源，我们接下来介绍与创建 Pod 不相关的资源：储存与网络。

其实我们之前已经接触过储存相关的内容了：在讲 Stateful Set 时我们提过 Stateful Set 创建出来的 Pod 都会有相互独立的储存；而讲 Daemon Set 时我们提到 K8s 推荐只在 Daemon Set 的 Pod 中访问宿主机磁盘。但独立的储存具体指什么？除了访问宿主机磁盘以外还有什么其他的储存？

在 Docker 中，我们可以把宿主机磁盘上的一个路径作为一个 Volume 来给容器绑定，或者直接使用 Docker Engine 管理的 Volume 来提供持久化存储或是容器间共享文件。在 K8s 里面也沿用了 Volume 这个概念，可以通过 Mount 绑定到容器内的路径，并通过实现 CSI 的各种引擎来提供更多样的存储。

我们知道 K8s 利用了容器虚拟化技术。而说到容器虚拟化就要说 Docker 。可是，容器到底是什么？ Docker 又为我们做了些什么？我们又为什么要用 K8s ？

要把一个不知道打过多少个升级补丁，不知道经历了多少任管理员的系统迁移到其他机器上，毫无疑问会是一场灾难。 —— Chad Fowler 《Trash Your Servers and Burn Your Code》

"Write once, run anywhere" 是 Java 曾经的口号。 Java 企图通过 JVM 虚拟机来实现一个可执行程序在多平台间的移植性。但我们现在知道， Java 语言并没能实现他的目标，会在操作系统调用、第三方依赖丢失、两个程序间依赖的冲突等各方面出现问题。

简化了一万倍来说，线性变换主要是在描述符合这两种性质的变换：一是要可加，二是要能数乘。 也就是说，对于空间中所有向量 $\vec{v_1}, \vec{v_2}$ ，以及任意数量 $k_1, k_2$ ，如果有：

符合这种规律的 A 就叫线性变换。而一次矩阵乘法正好可以代表一次线性变换。

为什么叫“线性”变换呢？感性地来说，因为它很“线”。

我们可以直观地从下面这张图看出原因：

1. 这篇文章参考了曼昆的《经济学原理》与北京大学王辉老师的《微观经济学》课程，内容上会有部分相似。
2. 这篇文章中的图使用 3Blue1Brown 的动画生成工具 manim 的 Community Edition 制作，源代码之后会上传到 GitHub 。

上一篇讲供给，这一篇讲需求。 其实供给与需求有很多相似的地方，有时只需要套一下上一篇中给出的模型就能求解。因此各位如果还没有看过上一篇，可以先看完再回来看这一篇内容也不迟。

讲需求曲线的时候，我们会先假设消费者是一个理性人，做决策时会将成本与收益作比较。比如在买冰酒这个场景，我们就会比较冰酒的价格与我们喝冰酒爽到的满足感（意愿支付价格），如果冰酒价格低于意愿支付价格我们就会去买这瓶冰酒。

1. 这篇文章参考了曼昆的《经济学原理》与北京大学王辉老师的《微观经济学》课程，内容上会有部分相似。
2. 这篇文章中的图使用 3Blue1Brown 的动画生成工具 manim 的 Community Edition 制作，源代码之后会上传到 GitHub 。

我们先不讲课，先来带个货。

德国和加拿大有一种特别的葡萄酒，叫冰酒。这种葡萄酒制作工艺比较特殊，必须要在严冬葡萄被霜冻在藤曼上时采摘下来，再经过发酵、压榨酿造而成。 在冰酒压榨过程中，大量的冰被去除，使得葡萄的成分得到浓缩，因此冰酒口感偏甜。但加工过程对温度要求十分苛刻，温度过高、过低、变化太过剧烈等都会对口感产生影响。由于冰酒工艺特别，主要只有德国、加拿大等少数地区生产。

我平时使用 vscode-memo 插件写笔记，其中插入图片使用 ![[]] 语法，显示简短，也有较好的预览支持，体验极佳。希望这种特性也能在写 hexo 博客的时候使用。

可能有很多人不熟悉 vscode-memo 这个插件，我先来简单介绍一下。

vscode-memo 定位是一个 knowledge base ，对标的是 Obsidian.md 等软件。其功能包括且不限于：

GitHub Action 自动化构建发布到 GitHub Pages 大家都见得多了，甚至 Hexo 官方自己都有相关的文档。 但我今天要做的不是发布到 GitHub 这么简单，而是要同时发布到 GitHub 和自己的域名下。

我们需要构建一个 CI/CD 过程。这个过程需要做到以下目标：

1. 将文章 push 到 GitHub 的 master branch 后，自动触发。
2. 我们博客使用 Hexo 引擎，需要先构建静态文件。
3. 需要将静态文件部署到 GitHub Page 。
4. 需要将静态文件部署到自己域名下。 这里我们使用 AWS 的 S3 服务与 CloudFront 服务直接部署到 CDN 上。 CloudFront 直接通过 OAI 访问 S3 ，不允许用户直接通过 S3 访问。
5. 博客在 GitHub Page 与 S3 需要处于不同的路径下。 为了延续以往的情况，博客在 GitHub Page 需要部署在 /blog/ 下。 而在 AWS 上我则希望直接部署在根目录下，这就导致需要两份配置文件。 当然弄两份配置文件我是不乐意的，于是就需要从模板自动生成配置文件...

其中，一二三点都很好解决，而第四点会是一个比较难又比较坑爹的地方。

最近使用 hexo 搭建了一个博客，并打算挂载在 github page 上。 对之前的那个博客进行替代，并将之前的文章逐渐搬移过来。

使用的这个主题功能还是比较完善的。

我们可以尝试一下代码块高亮：

在参加如AtCoder等算法竞技，或是刷Leetcode等算法题时，我们总是不可避免地遇到堆这种数据结构。

当然，一般来说我们只要理解堆，知道堆的性质，知道怎么样用堆就足够了。在做题时只需要调用系统类库即可——在参加AtCoder时你甚至不会有时间去自己实现一个堆。

但是，如果哪一天你把编程语言的类库全忘光了，又遇到一题需要频繁求最值的题目——你明知这里要用堆，却又忘记该调用的类名了，咋办？我还真遇到过这问题：三年没刷算法，只能对着一道自己明显会的题干着急，愣是想不起PriorityQueue的名字。这时候，只能自己实现一个堆出来了。

从7个方面评价代码的好坏：

1. 易维护性：根本
2. 可读性：最重要
3. 易扩展性：对修改关闭，对扩展开放
4. 灵活性
5. 简洁性：KISS
6. 可复用性：DRY
7. 可测试性：TDD，单元测试，控制反转与依赖注入

设计模式之美这一课程不单止讲设计模式，而会讲包括设计模式在内的指导我们进行代码设计的方法论。包括以下5个方面：

我们知道排序是算法入门基本功，排序算法有多重要想必也不需要我在这里说明了。因此这一篇就按着我的理解，聊一聊排序算法。

当然我不打算随便弄个什么十大排序算法或是经典排序总结之类响当当的名头，各个算法走马看花一样拉出来遛一遍，最后变得跟网上搜索到的其他讲排序的文章一样换汤不换药。你会发现这篇文章的结构跟在网上搜索到的任何讲排序的文章都有所不同：

在这篇文章里，你会发现你找不到冒泡排序——因为我认为冒泡排序只不过是一种低效率的选择排序。

CPython从3.6开始，字典（dict）不再是无序的了——字典的修改了原先的底层实现，变得能按字典插入的顺序进行遍历。而Python从3.7开始将字典的有序性写入语言特性，不管是Jython、IronPython还是其他Python实现，从3.7开始大家的字典都是有序的了。

以前参加Python相关的面试时，面试官经常都会问一个问题：Python里的字典（dict）是有序的吗？

这自然难不倒我，我也照本宣科地讲：Python的字典底层是用哈希表实现的，在不发生冲突时读写的时间复杂度是O（1），比读写时间复杂度为O（logn）的红黑树要更快。但红黑树可以按下标的大小顺序进行遍历，而Dict遍历时是无序的。

1. 引入整个命名空间中的成员

不引入命名空间时，使用其中变量需要使用<命名空间名>::<变量名>的方式使用。 如此会将命名空间foo下所有的成员名称引入，可在直接以 <变量名> 的形式使用。但如此做有可能会使得命名空间foo中部分变量与当前定义的变量名冲突，违反命名空间隔离编译时名称冲突的初衷，因此不建议如此使用。

2. 引入命名空间中的部分成员

“Stop Trying to Reinvent the Wheel.”

参考[BruceZhao][BruceZhao]提供的中文翻译：[README.zh.md][READMEzh]，先将[Huxpro][Huxpro]提供的[博客模板仓库][origin_repo]fork出来，git clone到本地。

整个网站文件夹大致结构如下：

“Hello World!”

自己盲人摸象折腾了一两天，终于利用GitHub Pages，把自己的博客搭好了。

感谢[Huxpro][Huxpro]提供的博客模板，以及[BruceZhao][BruceZhao]编写的中文ReadMe。