@contractswif 按照作者的意思 C2 大概是 service 级别的设计，C3 大概是进程级别的设计。画图工具的话，作者在网页底部列了一些，他主推的是自己配套的 Structurizr，但是我没用过所以确实不太了解了。

两个物理 Yubikey， 异地备份

接楼上，补上链接：<一部手机失窃而揭露的窃取个人信息实现资金盗取的黑色产业链> https://www.freebuf.com/articles/network/249294.html

请不要使用手机短信作为 2FA 验证手段，因为及其不安全，难道大家忘了之前那个因为手机被盗而一夜间被开通各种网贷的事了么。

已 Block 楼上所有询问楼主性别的 id. 任何人都有脆弱 /艰难的点和时候，和性别有什么关系呢？希望楼主能过度过难关，2021 年加油。

一方面行情才刚刚开始,今年达到 ATH 远没有 17 年同期的热度 (我认为是好事), 另一方面最近电动车类股票涨得太猛了吸引了很多注意力和资金. 持(比特)币坐等起飞吧.

我司 (也算大厂了吧) 做过类似的事情, 主要针对的场景是 OLAP 的 SQL. 我们的做法是提供两套 API ,一套是 SQL 本身,另一套是类似于楼主的这种链式调用 API (不过我们是 Python), 同时我们两套 API 可以混用 .

我们做这个工作一个重要的出发点能够对 SQL 进行静态的类型检查 (以及其他的一些语义检查). 做法上和楼主不一样的是, 我们不基于宿主语言 (Java or Python) 的类型系统,而是将 SQL 或者 链式 API 的程序统一翻译成一个中间表达形式 (IR), 然后再其上做类型检查. 此外, 我们不仅仅是对单个 SQL 做类型检查, 更重要的是对整个 OLAP 链路上所有具有数据血缘的 SQL 会做全局检查, 以保证链路上任何 SQL 的修改都都不会破坏其上游及下游 SQL 的合法性.
当然类型检查只是我们做的一方面, 我们还做了很多其他的更重要的语义检查, 在这儿就先不展开说了.


另一很重要的动机是 SQL 的的提高可组合型以及复用性. 举个简单的例子, 用楼主的给的场景来说, 对于以下的这个计算(当然我们的现实中的场景比这个复杂的多):

sum(orderTable.amount) / sum(orderTable.quantity) * 100

我们的系统里, 这个计算可以定义成一个库函数 (def sum(double)->double). 这个函数可以像普通编程语言中的库函数一样在任何一个 SQL 中进行调用:

SELECT sum(1.0) FROM table1
// SELECT.PROJECT(sum(1.0)).....

同时, 我们的静态检查工具能够静态的当前调用环境中 SUM 函数时输入类型和返回类型做类型检查.

如果在海外的话，其实最大的问题是一开始很难确定对方是中国人，所以一开始都是默认英语交流，后来如果有机会发现双方都是中国人的话就切换成中文了。

"sql 的最近一个月具体包含了多少天"?
"C++ 的最近一个月具体包含了多少天"?
"Python 的最近一个月具体包含了多少天"?

和语言没有任何关系吧.

@EmdeBoas 楼主需要的是 UDTF. SQL (with recursive CTE) 是图灵完备的。

这类系统最难的是不仅仅要保证语法的正确性, 而且要保证语义的正确性. 前者很简单, 用支持 Mysql SQL 的 parser 去解析转换后的 SQL 看是否符合语法. 但是后者-语义检测很难.

感谢分享，正好想要个类似的 app。唯一的缺点是对于 VS Code 之类的 Web app，识别不了窗体内部的按钮及内容。

antlr/javascript