搬家完成

17 Jul 2017 - 12 minute read

至此，我从 https://epipolar.tumblr.com/ 到这里的搬家就告一段落了。过程真的是无比漫长和艰辛。

为什么搬家

之所以想到要搬家，是有几方面的原因的：

Tumblr 常年被墙，为我写文和浏览都带来了障碍，虽然 ghpages 也偶尔会被照顾，相比之下还是比 Tumblr 友好的。
Tumblr 的功能比较局限，特别是我的文章偶尔会用到代码，此前只能用引用块儿将就。虽说实现代码高亮的方式也有，但还是比较绕弯。
Tumblr 文章的地址采用了一个 ID ，很不直观。相较之下 ghpages 中就可以用比较友好的 permalink 。
在 Tumblr 上使用自定义的 assets 比较繁琐。我在利用 P5.js 制作一些内容时深深地感受到了不便。
Tumblr 自带的 Archive 采用的是块状的布局，这就使得按标题找文章非常得不方便。如果图像内容居多，采用 Tumblr 就更加合适了。
Tumblr 上一些“另类”内容太多，具体是什么大家心里有数。

因此，在朋友阅读我的 Tumblr 文章时发出了对索引不便的感叹后，我就决定搬家了。

搬家的过程

如一开始所说，整个过程充满了艰辛。对于 ghpages/jekyll/static site 这些，我几乎都很陌生，可以说从零开始。因此一切都在摸索和试错中进行。

事实上，可以搭建本地的 jekyll （或者 hexos，听说是个更加易用的平台），在本地将页面输出好然后只把最终的静态页面 push 到 ghpages 上。这样，各种事情都可以在本地调试好。

但我最终没选择这么做，而是采用了最简单粗暴的提交到 ghpages 然后浏览的方式。一方面是懒，另一方面是如果在本地搭建 jekyll 环境，还要再接触 Ruby ，这又是个相对陌生的事物。此外，我终归是在 Windows 上工作居多，在 Windows 上搭建 Ruby/jekyll 环境又会带来额外的复杂性……

为了减少工作量，我尝试了利用 Tumblr 官方的 API 自动抓取全部文章和文章中的图片。但由于 Tumblr 文章采用了 HTML 编码，我基本只保留了抓取到的文章元信息，例如标题、时间、标签。文章内容则是复制粘贴后利用 Markdown 重排。期初尝试的是 Node.js 的 API ，却发现 Node.js 不支持全局代理，后改用了 Python 。Node.js 也算是初次尝试，不过总地来说，在 Windows 下尝试使用任何脚本语言都会伴随着痛苦。

ghpages 采用的是 jekyll+kramdown 。kramdown 自称支持 MathJax ，但实际上还是要在模板上做很多的工作。在 Tumblr 中书写公式时，为了避免 Tumblr 自作聪明的各种转换，需要额外 escape 一些字符。到了 kramdown 中，同样要做类似的事情，而两边需要做的又不相同，这就意味着所有数学文章要经过一番转换……这一过程，我基本采用了人工操作，以保证质量。另外，代码块也要从 Tumblr 里的引用改成正经的高亮块，也是一番工作。图片通过自动抓取实现了本地导出，可是图片的名字都是一塌糊涂。因此在文章里插入图片时就要重新把图像名字美化，又是很大一块的开销。

模板方面，采用了 Hyde 。在它的基础上进行了一些修改以适应我的需要。例如加入了 Disqus 评论，Post 列表，Tag 列表，删除了一些无用的元素，为 MathJax 加入了自动重排版的功能。一些可直接套用内容的 Post 模板正在设计中，应该今后会加入。此外目前模板上对 Hyde 的版权还没有标注出来，也是因为懒，很快会修正。

搬家之后

虽说是搬家，并不意味着旧的 Blog 就完全放弃了，在今后一段时间里两边会平行地使用。不过内容上会出现一些区分：

ghpages 会更侧重原创文章以及各种非文章形式的页面
Tumblr 上会更侧重一些有趣内容的转载，同时同步更新部分 ghpages 上的文章。

在目前的搬家中，我已经忽略了一些 Tumblr 上的转载文章内容。在 Tumblr 内发现的，就留在那里不要搬过来了。

此外，部分文章在搬运时也重温了内容，进行了细微的修改，添加了一些后记来补充撰写文章后的新认知。这些在 Tumblr 一侧不会再更新了。

总而言之，这里将会是以后我记录和分享自己学到的知识的场所。风格上，还会一直坚持走浅显易懂的路线。利用 ghpages 的灵活性，今后还会尝试加入各种有趣的内容，还请多多关注。

发在这边的文章，一些文章的 permalink 中藏了一些微妙的 puns ，算是一些小彩蛋，这也是在 Tumblr 发文无法享受的乐趣 :)

我叫酋酋，酋长的酋，酋长的酋

22 May 2017 - less than 1 minute read

酋酋是朋友在路边发现的，一伸手就凑了过来。阴差阳错地，它就成为了我家的新主人。

照片是朋友带她出去玩时拍的，对了，她是她。

因为长得黑，所以是酋长，所以叫酋酋……

VAO 和 VBO

19 May 2017 - 4 minute read

OpenGL 中有两个对象一直傻傻分不清楚，一个叫 VertexArrayObject (VAO) ，另一个叫 VertexBufferObject (VBO) 。

在现代的绘制管线中，一般要把顶点数据整块传递给图形硬件，而不是采用老旧的逐条命令指定顶点数据的方式。这种方式下，我们会建立一块内存来存储顶点数据，然后将它传递给一个 VertexBufferObject 。也就是说 VBO 做的是下面的事情（伪代码）：

Vertex vertices[n_vertices]; // VBO

而将若干个 VBO 的信息集合在一起，方便在绘制时一次性调用的，则是 VAO 。例如可以在 VAO 中预先将顶点位置、法向等 VBO 分别绑定好。用伪代码表示就是：

struct Geometries {
    Vertex *vertices;
    Normal *normals;
    // …
};
Geometries g; // VAO
g.vertices = vertices; // bind VBO to VAO (via glVertexAttribPointer)

可以发现，VBO 表示的是具体的数据，VAO 则是这些数据对象的集合容器。类似的，Texture/RenderBuffer 是具体的数据，FBO 则是若干 Texture/RenderBuffer 的集合。如这篇文章¹ 中介绍的，OpenGL 对这两类对象进行了划分，表示具体数据的可以称为 Regular Objects，而代表 Regular Objects 集合的则对应 Container Objects 。

What are Binding Points in OpenGL? ↩

微分方程与能量守恒（三）

11 May 2017 - 4 minute read

在计算增量时，如果 $\dot{x}$ 和 $\ddot{x}$ 都来自新一时刻的估计，我们就得到了后向欧拉法（Backward Euler）。根据我们前两篇文章的内容，很容易猜测后向欧拉法会使得系统能量稳定或者减小。

后向欧拉法的形式是这样的：

\[\begin{aligned} \begin{pmatrix} x_{t+\Delta t} \\ \dot{x}_{t+\Delta t} \end{pmatrix} &= \begin{pmatrix}x_{t} \\ \dot{x}_{t} \end{pmatrix}+ \begin{pmatrix} 0 & \Delta t \\ -K\Delta t & 0 \end{pmatrix} \begin{pmatrix} x_{t+\Delta t} \\ \dot{x}_{t+\Delta t} \end{pmatrix} \\ \Rightarrow \begin{pmatrix} 1 & -\Delta t \\ K\Delta t & 1 \end{pmatrix}\begin{pmatrix} x_{t+\Delta t} \\ \dot{x}_{t+\Delta t} \end{pmatrix} &= \begin{pmatrix}x_{t} \\ \dot{x}_{t} \end{pmatrix} \end{aligned}\]

此时新一时刻的状态向量需要满足已知旧时刻时的线性方程，通过求解这一线性方程得到新一时刻的状态。

可以见到，这一线性方程的系数矩阵与前向欧拉法的递推矩阵相同，但由于求解方程对应于求它的逆，这使得结果的能量被缩小。

在复杂/非线性场景下的微分方程比我们这里的单个线性弹簧问题要复杂很多，我们关于能量守恒的讨论需要更加精确地刻画。我们先在这里告一段落，更复杂的内容以后有机会再介绍。

Cat-Oriented Programming

10 May 2017 - less than 1 minute read

——通过命令使设备以预期相反的方式工作的一种编程范式。

Older Newer