Algorithm
本周选择的算法题是：Number of Strings That Appear as Substrings in Word。
impl Solution {
pub fn num_of_strings(patterns: Vec<String>, word: String) -> i32 {
let mut count = 0;
for p in patterns {
if word.contains(&p) {
count += 1;
}
}
count
}
}
Review
An example of LLM prompting for programming
这篇文章分享了如何利用 ChatGPT 生成高质量的代码，核心是背后的 chain of thought，总结一下过程：
- 仔细描述自己的意图、限制条件
- 要求 ChatGPT 给出思路，并在 Review 思路的过程中不断对齐思路
- 基于思路给出一份更为详细的 plan，plan 包含了主要的输入、输出
- 基于 plan 给出代码
此外文中还分享了几个技巧，比如 ChatGPT 受到 token 限制输入不全的话，可以通过 you are not finished or go on 解决，实测 continue 也可以。
Tip
Mojo，大佬的新作，AI 时代专用的编程语言，集 Python 的可用性与 C 语言的速度于一体（语法和语义完全基于 Python，Python 工程师可以轻松使用），号称比 Python 快 35000 倍，目前还在预约阶段，值得期待一下~
Share
从 QQ、Teams 架构变迁看桌面客户端的技术选型
最近有两篇文章介绍了 QQ、Teams 桌面客户端的一些变化：
它们的架构分别是这样的：
以 Teams 为例，新的架构包含如下几个角色：
- 由 Fluent UI 驱动的 UI 组件库，响应式 + 跨平台，确保在所有设备上有一致而连贯的体验和性能，Fluent UI + React 构成了完整的 View 层
- 由 Client Data Layer 驱动的 DAO 层，这是从原本主线程中拆分出来的模块，独立的守护进程既有助于提高软件的健壮性，也能将针对数据的操作放在主线程之外进行，避开 JavaScript 单线程的问题；Teams 采用了 GraphQL 作为 DAO 的查询语言，进程之间用 IPC 通信。多进程 + IPC 是目前的主流设计，比如 IDE 就采用了这样的方式解耦编辑器和语言能力（包括 debugger），渲染服务也是由 render client + render server 组成，极大的提高了健壮性和可扩展性
- 由 WebView2 承载的渲染引擎，抹平因环境不同、运行时不同产生的差异；Teams 选择了从 Electron 切换到 WebView2，一是为了减少内存使用和磁盘占用率，二是可以和 Edge 共享资源，从整体的解决方案上看，WebView2 不只是一个单纯的 View，它其实是一个用于构建混合跨平台应用程序的 SDK，提供了本地能力和集成底层平台，借此抹平宿主间的差异
Teams 和 QQ 的架构图在逻辑上稍有不同，Teams 更侧重于分工逻辑，Host 和 Web Client 就像传统的 C/S 软件，把团队和事情做了隔离。但无论是 QQ 还是 Teams，它们的架构理念是一样的，从 QQ 角度来看：
- 功能与应用 UI 和 Fluent UI + React 的角色一致
- Electron 的作用和 WebView2 一样，渲染引擎 + 执行 JS 的引擎
- 基于 C++ 的 NT 跨平台框架是整个架构的核心，在 Teams 里则是由 WebView2 和 Client Data Layer 共同组成
QQ 在腾讯项目制下倾向于什么都自己闭环，但又拿不出类似 WebView2 的东西，也没必要基于 Chromium 再额外封装一个，直接采用 Electron 是显而易见的选择，所以这两篇文章看似一个选择了 Electron，一个放弃了 Electron，但它们本质上没有区别，“Electron” 是很薄、很容易替换的一个角色，这套架构真正核心的是三个关键选择：
- 基于前端生态，Node、React 提供了很多共享资源，大幅减少了开发者的工作量，开发团队都可以享受到这样的便捷
- 跨平台解决方案，和生态解耦，无论上层生态是哪种技术栈都可以面向未来迁移，把不变的部分和变化的部分隔离出来了
- 高度集成的系统平台，比如 QQ 的后台，Teams 提供的 MSIX、从轮询转向推送、利用 Windows 和 WebView2 定期清理未使用的内存页等，跨平台开发的难点在于处理平台差异性
还有一个从架构图看不到的地方，即与 DevOps 的融合，只有在整个生产环节与跨平台结合，才是实现真正的跨平台，从这个角度看，跨平台不一定是低成本的方案，其核心诉求也不是开发效率（或者说是次要的），动态化的灵活性、快速迭代助业务先赢才是跨平台的主要意义，它追求的是生产效率，而不仅是开发效率，因此不要期望引入跨平台的同时不对已有的架构、生产、发布等环节做出调整，如 Teams 在文末所说，这将是一段漫长的旅程，需要持续改善性能、可靠性和架构方面的体验，防止在达到一致性表现的过程中，出现越来越高的工程上的填坑成本。