1. 首页加载速度优化。

弃用 https://github.com/naver/egjs-infinitegrid，改用 css 原生的 columns 实现瀑布流。

这个 infinitegrid 乍一用还挺不错的，瀑布流布局、无限加载，完全符合我的需求。但是它的默认行为是阻塞式的，即在所有项（我的是图片）加载完成后再一次性渲染。虽然其文档上有提到异步加载方式，我简单尝试了下，没成功。

columns 默认会打断（break）元素。比如我的元素是这样的：

1
2
3
4

<div class="container">
	<div class="top"></div>
	<div class="bottom"></div>
</div>

下游就是这么苦，上游一句“我这没事啊”，问题就成了你的了。拼了老命、挠破头皮地搞了一天，发现实在是找不出问题，还得想尽办法把问题定位到上游的“黑盒盒”里，人家才会不疾不徐地开展工作。

遇到这种同事能怎么办？我只能在心里暗爽：嘿嘿，又“帮”儿子解决了一个 bug。

这次的故事是这样的。

前言

最近在搞的一个 Unity 项目是以插件形式运行在服务端的，对内存碎片问题有比较高的要求，正好有机会深入学习了下 Unity 的 GC。这篇文章便是从 Unity 2019.4 官方文档 Garbage collection best practices 翻译、摘要而来。

正文

自动内存管理让你写起代码时又快又简单，还能减少出错。但是这种便利有可能带来性能影响。为了优化代码以提高性能，你必须避免频繁触发 GC 的情形。

本文基于官方 v18.1.0 文档。

Introducing Hooks

They let you use state and other React features without writing a class.

Motivation

It’s hard to reuse stateful logic between components

现在可以通过自定义 Hook 提取封装带状态的逻辑。

Complex components become hard to understand

useEffect 可以把复杂逻辑分拆到多个小的函数中。

Classes confuse both people and machines

本文基于官方 v18.1.0 文档。

Code-Splitting

Code Splitting

You need to keep an eye on the code you are including in your bundle so that you don’t accidentally make it so large that your app takes a long time to load.

Code-Splitting is a feature supported by bundlers like Webpack, Rollup and Browserify (via factor-bundle) which can create multiple bundles that can be dynamically loaded at runtime.

Code-splitting your app can help you “lazy-load” just the things that are currently needed by the user, which can dramatically improve the performance of your app.

本文基于官方 v18.1.0 文档。

Introducing JSX

Why JSX?

React embraces the fact that rendering logic is inherently coupled with other UI logic:
how events are handled, how the state changes over time, and how the data is prepared for display.

Instead of artificially separating technologies by putting markup and logic in separate files,
React separates concerns with loosely coupled units called “components” that contain both.

这是当初 React 最吸引我的地方，不执著于将 UI 和逻辑分开。MVC 大行其道几十年后，Android 跟 iOS 也都在尝试返濮了。
在我实际工作经验中，进行视图子类化定制的出发点往往就是为了将 UI 和其逻辑写在一起。这个需求越靠近业务层就越强烈。

ubuntu 上安装完 nginx 后发现默认首页不能访问，可以优先检查 ufw 防火墙：

1

sudo ufw status

结果显示 status: active，说明 vultr 上的防火墙是默认开启的。

执行命令将 http、https 端口加入到白名单：

1
2

sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'

可以了。

参考：

How to Set Up Nginx on a Ubuntu Server with Vultr: https://coderrocketfuel.com/article/how-to-set-up-nginx-on-a-ubuntu-server-with-vultr

白名单

https://vultr.com/

黑名单

1. https://flaunt7.com/

垃圾，会无故下线服务器，各种反馈渠道没有响应。

2. https://hostus.us/

不能购买 VPS，直接把我标记为了 fraud（诈骗），要求我提供身份证明信息。

3. https://www.linode.com/

同上，说我行为、模式像诈骗。

4. https://www.time4vps.com/

同上，需要提供驾驶证、身份证或者护照。

HOPL 是 History of Programming Languages（编程语言历史）的缩写，是 ACM 旗下的一个会议，约每十五年举办一次。
这是我父的第三篇 HOPL 论文，发表于 2021 年。中文译本 出自 Boolan 之手，不胜感激。

7. 错误处理

使用包含 (值,错误码) 对的类会带来巨大的成本。除了检测错误码的成本外，许多 ABI（应用程序二进制接口）甚至不使用寄存器来传递小的结构体，所以 (值,错误码) 对不仅传递了更多的信息（是通常数量的两倍），而且也使传递的性能有数量级的降低。可悲的是，在许多 ABI 中，尤其那些针对嵌入式系统的 ABI（专为 C 代码设计），这个问题直到今天（2020 年）依然存在。

这些年来，异常处理的性能相对较慢，是因为我们在优化非异常方面花费了大量精力。

具有讽刺意味的是，那些坚定支持异常规约的人转而去帮助设计 Java 了。

HOPL 是 History of Programming Languages（编程语言历史）的缩写，是 ACM 旗下的一个会议，约每十五年举办一次。
这是我父的第三篇 HOPL 论文，发表于 2021 年。中文译本 出自 Boolan 之手，不胜感激。

Concepts—我父最大的执念，也算是我父的滑铁卢了吧……大约是十年前吧，就看过我父亲自上阵“路演” Concepts 主题的 PPT。念念不忘，必有回响。终于还是标准化了。
这是一篇夹在 C++14 和 C++17 时间线中间的大幅文章，远不到 C++20 内容出场的时候，可见我父的急不可耐……

我的看法？我是一个反模版者（注意不是反泛化），语法笨重，强制的实现可见，乱七八糟的错误信息。一群四六不懂的 TMP 至高无上鼓吹者直接让我把这种理性的反对变成了冲动的反感。所以这么些年我都没怎么系统地学习过模版。

Concepts 当然是出于善意，能解决“乱七八糟的错误信息”问题，在正向使用模版的时候也能对编译器做出正确的指示。但是！不管是优柔寡断或是市场的原因，引入新特性的同时依然保留了旧的、坏的实现路径，恰恰是我父前文提到的 N+1 问题：为了解决前边 N 种方案存在的问题引入了第 N+1 种方案。隔代的 C++ 程序员们该怎么沟通、共事？（此刻，我突然理解了那些依然坚持使用 C++98 的程序员们。）而且 Concepts 引入的长长的前缀语法抵消了 auto 所做的简化努力，语法笨重的问题反弹了。

为时晚矣……模版依然是特定人群（专家？）、特定领域（开源？）的小众选择。