这种脑残程序员应该拉出去续 200s

所以说它不该被滥用

Kotlin 提供了 check, require 和直接 error
assert 只有 jvm 提供了，这就造成不一致性
而且 assert 的居然还不是接受 block！这一点咱不喜欢。

其实 assert 这个东西只能算是一种甜点上的糖霜，也没啥大不了的，差不多是运行时的「条件编译」。
Java 1.4 就加上了，很可惜 Kotlin 居然也继承了它这个……

其实 pomodoro 不是特别难开发，只是有几个状态。

beginWork, pausedBreak, beginBreak
initial beginWork

1. beginWork -> beginBreak
2. beginBreak -> pausedBreak
3. pausedBreak -> pausedBreak
4. beginBreak -> beginWork

每个状态的转移都有信号：

(1) 可以提示『休息一下吧』
(2)、(3) 可以提示『休息已被中断』
(4) 可以提示『请恢复您的工作』

每个状态转移都是由定时或者外部信号导致的：

1. 定时『下次休息』超时
2. 3. 光标焦点移动、击键什么的
4. 定时器『休息时间』超时

此外，

beginWork 就要设置定时器『下次休息』为『下个休息时长』
beginBreak 就要设置定时器『休息时间』为『下个休息时间』

这是我们的基本抽象，可以做成 daemon。

然后是『下次休息』和『休息时长』，我们说的是「下个」，这就是说休息时长是一个序列。

可选 微休，每隔 time 休息 time
建议时间 6min : 30sec
可选 全休，每隔 time 休息 time
建议时间 40min : 6min

定时器的使用上就随便用吧，几个时间可以一起定，但状态转移都在 (1) 或 (4)
在第一个定时器响铃时，就必须撤销所有其他定时器了。

正在重构 Qt 官方的一个示例，顺便学习一点音频信号生成和 C++ Qt 开发。

这个等式就应该重构，为什么我们不先算每个 channel 的 byte length，再求总共的积？那样不是更符合正常思路吗？

void repeat(unsigned n, void(*op)(unsigned) ) {
for (unsigned i=0; i<n; i++) op(i);
}

不喜欢 C++

我数学不好，但还是了解了音频的 format、int channel、sample rate、sample size 什么的

不愧是 C++ 呢，各种 const noexcept override 让人感觉莫名其妙，stl 各种可以用的烂代码，保持傲慢与偏见，我从来不写没有用的代码，一个字符也不。
一个字符都不多写，刚刚好够用、明确就足够，C++ 新建抽象太麻烦，根本比不上 Kotlin 的安逸。
不是像大部分人，一个字符的解释也不多给、一条使用模型总结也不弄，只有自己写出来了就足够，也是刚刚好。

STL，是是，设计和算法非常好，但就是代码风格不能让正常人看，我不知道 _M_name 对人类可读性来说有什么好的，看起来什么东西都往一个文件放，不加任何解释和 brief，很 UNIX。

我都不知道同时弄什么客户 header 啊、实现啊，它给逻辑抽提制造的麻烦与那一点点『实现无关性』『简洁性』相比是熟轻熟重，看起来好像 header 和 preprocessor 这两个不得了的东西比程序员对代码维护的便利性还重要，C++ 就是不让你重构的，一开始就想好了嘛。

UNIX 和 C 就是一大堆意义不明的下划线，尤其是几个下划线连在一起的最为邪门，每天晚上 make 的时候啥玩意像 int 几个字节宽都重新检查一遍，就像那个啥每个项目的 automake.m4 都复制一遍，美其名曰 repeatable，一个小项目编译三分钟，真是妙不可言，尤其是令打包者心悦诚服。

程序员只应该考虑一件事情，就是脑子，就是要实现最重要的事情，最终对应到各种各样的抽象模型——时序、高阶流程控制、状态机、文件树、列表处理、数学计算、图形控件、2D画布，不是说七国语言精通各种运行环境和奇技淫巧，如果有，就让少数人解决、多数人享受解决方案。伺候什么构建系统啊？构建系统和依赖关系就该由工具解决，可工具偏偏还足够有『扩展性』弄得描述个软件包依赖都那么麻烦，什么 node_modules 啊、automake.m4、configure.ac 啊。

说白了就是 (rate * size) * channel 还是 rate * (size * channel) 的区别。
之前没那么弄是因为它有一个特别蹩脚的生成循环，我不得不尝试抽提出 SoundBuffer。

我还以为可以有很多 QApplication 实例呢，原来这都是静态方法啊，还好 clang-tidy 指出了这一点。

真的搞不懂如此混淆，只为写短点是有什么好处，那么多本来是 unsigned type 的东西非得用 int，还不统一，真是让人费解，Rust 是解决了这一点。

还是 clang 开发者懂得如何编程，至少比那一群只会算法的工程师代码风格强。

就命名而言，我还是觉得 byte short int long 这样的命名方式好一些的，唯一的例外是 Rust 那样 i8 u32 的命名方式，CLR 和 Qt 这种 uint8 真的会让非英语母语的人很困扰的。

C++ 不能随便 extension 真心累，Kotlin 里用惯了的。

我讨厌把非关键的东西写长，一个字符也不行，所以我用 C++ 的 using(typedef) 给 Qt 的 core primitives 都起了 Rust 式别名

这些写 sample 的程序员脑子很聪明，就是差点编程习惯……