12 factor app 是不是已经没人当回事了？

1. 基准代码
一份基准代码，多份部署
2. 依赖
显式声明依赖关系
3. 配置
在环境中存储配置
4. 后端服务
把后端服务当作附加资源
5. 构建，发布，运行
严格分离构建和运行
6. 进程
以一个或多个无状态进程运行应用
7. 端口绑定
通过端口绑定提供服务
8. 并发
通过进程模型进行扩展
9. 易处理
快速启动和优雅终止可最大化健壮性
10. 开发环境与线上环境等价
尽可能的保持开发，预发布，线上环境相同
11. 日志
把日志当作事件流
12. 管理进程
后台管理任务当作一次性进程运行

用不用 ORM 都可以避免 SQL 注入，预编译 API 也挺简单的

Discord 用得少，感觉基于频道和 thread 的模式和 Slack 差不多？而且这网站注册要手机号，还有各种风控

@ABCDiSDR
试了下还真是..平时不出门的话都是插显示器用的

人家开发自用 App ，也没有提某方面背景，那不是应该默认最好的方案就是原生吗？资料最多，坑最少。而且现在 AI 这么发达，跟着 AI 照猫画虎学起来也快。

做破坏性操作参数带*的时候，我会按 tab 把*给展开再确认一遍

编程语言界的原神

@binfreeze
我自己的工作就跟这种底层开发有点关系。但其实写真的底层软件和这类图形界面程序还是很不一样，前者面临的东西虽然难，但问题相对是比较细的，GUI 程序范围就很大，做不到关注点分离。

能够精细地管理内存处理事件很有意义，但是开发 GUI 程序似乎有些脱离这个层面的本质困难，所以直到现在都不断有人提出新概念去管理 GUI 开发里的各种复杂度。提这个问题，也是因为我感觉 Web 开发有今天的繁荣，不能完全用屏蔽底层接口来解释，它应该也是在其他方面做对了若干事情。

我接触编程比较早，那会还是在中学，刚入门的语言是 C++，那会在网上和人争论胜过学技术本身。所以我很能理解你说有些话时候的心情。那会的我发自内心不喜欢 Python 、JS 这些「上层」语言，甚至还包括了 C#、Java ，回头看，当时的自己除了上论坛吹牛，自己也没做出啥有意义的东西，也没学多少真功夫。现在看，接触不同的技术对开阔眼界还是相当有价值。

SICP 拖了好几年都没读完，但这本书真的很有意思（或者说和 Lisp 相关的那几本著名的书都很有意思），最起码来说它可以治愈一个人的 Lisp 恐惧症，以及理解「抽象」这个抽象的词（递归了这下）。

而 CSAPP 的话呢…一大作用应该是治愈很多程序员的「底层」恐惧症，即看到所谓底层相关的知识又觉得害怕，又盲目崇拜。从这个角度说，这本书当然是每个程序员都必读的（没说要读完或者全部弄懂）。

文章里面提到的操作系统教材我没有读过。但从我读过的一些操作系统书籍来看，理论背景太深厚也会导致读起来过于抽象，只适合考试。如果能够结合操作系统的若干 API ，比如创建进程线程，映射内存，会好一点。南大还是哪个大学在 B 站上有个操作系统课，那个不错。

数据库那本也没读过，当年学校用的教材是《数据库系统概念》，到今天也就记得若干 SQL 、关系代数那套理论，还有 ACID 的定义了。更进阶的一本是《数据库系统实现》，讨论了为什么数据库的索引要用 B 树，如何根据 SQL 创建查询计划等等。所以对应了两个路线的实操，一个是多写点 SQL （如果你不熟悉的话，多和聚合函数以及 HAVING 字句斗智斗勇能很快增进对关系代数的认识），一个是试着写一个数据库引擎。其实数据库实现这块知识挺有意义的，因为这可能是第一次思考内存之外的模型（比如如何优化磁盘写入），而且 CRUD 程序员很需要这个。

说到 CRUD ，后面那本《数据密集型系统设计》就更推荐了。我觉得大多数喜欢装 X 问高并发的面试官问的问题都不会超过这本书的某个子集…而且相比偏老一些的数据库教材，这本书讨论了很多 NoSQL 的内容和新的索引结构。

而学编译原理，真的不推荐龙书。《编译器设计》或者《现代编译原理》都比龙书更容易入门。或者有一本九十年代的书，叫《编译原理与实践》，这个更适合初学者。这本书国内有翻译版也有影印版，翻译翻得很垃圾。但从普通程序员的角度看，学编译原理并不代表真的要做编译器或者发明新语言（虽然这是很有意思的事），而主要是 (1) 会用编译器；(2) 了解编译器大概能做什么优化，写代码的时候心里有数；(3) 了解底层链接器、加载器、runtime 等的工作原理。1 你看编译原理书没啥用，得看你用的编译器的文档加多用； 2 的话有点用，但你也得先懂点汇编； 3 虽然做编译器都绕不开这个，但大部分编译原理的书都不会讲，CSAPP 倒是会讲，这个有用。

有种感觉，未来可能从想做独立开发者的人身上赚钱比当独立开发者赚钱更容易。

2016 年是转折点。

硬件上，这一年发布了新款带 Touch Bar 的 MacBook Pro ，机身全面轻薄，走全 Type-C 路线，换成蝶式键盘。这几点后面全部都改了回去。另外刚好遇上 Intel 的 Skylake ，续航散热表现尤其差。而且没记错的话这代还涨价了。

软件上，发布了 10.12 Sierra ，系统也从 OS X 更名为 macOS ，权限进一步收紧。这代我印象里稳定性相比 El Capitan 下降非常多。而且刚好这一年彭博发了篇报道，说苹果砍掉了专门的 macOS 团队，改由 iOS 承担 macOS 的维护任务。也许这才是后面 macOS 一代不如一代的主要原因。

但这几代 MacBook 又刚好见证了国内 Mac 用户群的快速增长。很多人一开始对 Mac 的印象就是这几代。好在那会 PC 这边也不太行，所以比比烂又还可以。

很多人觉得 Mac 续航强是从换 M 芯片才开始的，其实用 2014 MBP 那个时候续航也相当舒服，不敢说能不能和现在的 Air 比，但和同时代 PC 比真的强太多了。

@ShikiSuen
从这个视频 https://www.bilibili.com/video/BV1Xa4y1A7Gz/ 看起来好像是能在恢复模式起作用，那启动其他系统估计也悬了

Mozilla 的反对声音从来都只能表个态，这么多次，Chromium 先斩后奏 Firefox 也只能跟了，反正也不会真有多少人迁移到 Firefox. Chrome 的用户粘性是比苹果高多了，认识的 iOS 开发几乎没有不骂苹果的，但前端开发真有不少人把谷歌当爹捏。

Rust 的所有权系统其实是把 C++那套最佳实践落实到语法上，然后融合了很多函数式语言（ OCaml ）的元素。

很多人不理解 C++这类语言的痛点，或者在学校学过一点 C++但印象仅停留在 new 了东西要手动 delete ，学起 Rust 就会造成不知道为什么要这么设计的感觉。

其实这种无 GC 的原生语言确实在很多地方都不是刚需。上次还有 V 友说用 C++写项目太老土了的。

C++的复杂性来自于：

1. 像 C 一样，和底层打交道的语言天然就会有很多复杂度。C/C++工具链和系统高度耦合，要有能力在实际环境里部署 C++代码就必须得对 linker 、runtime 这些东西有一定了解。这个可以遇到某个问题了再作为切入点去学习。而且 C/C++编译器本身发展历史很长，了解各种常见选项也是一个历史负担。

2. C++融合了不同方面的各种语法，包括从 C 拿过来的、面向对象的、玩模板的，一旦这些语法要素融合在一起，语法的复杂程度就会非常高（会变成 N*M 而不是 N+M ）。不过如果只是用到某一块语言特性，其实 C++没有那么恐怖。

主要还得遇到具体情况具体看，抽象地说 C++如何复杂对写 C++代码没什么意义。

https://www.v2ex.com/t/958145

Copilot 一个是在学新技术的时候特别方便，另一个是降低了重复代码的负面价值。所以以前某些技术里的某些缺点，在 Copilot 加持下可能不再是缺点了。

glibc 支持某个语言是什么意思，Locale 吗？

Hybrid 应该和 Classic 是一样的轴体吧？我有一把 Type-S 和 Classic ，对比明显感觉 Type-S 的手感好得多，用了一段时间 Type-S 后回头摸 Classic 感觉声音和手感更接近机械键盘（虽然再摸摸真正的机械键盘发现手感差得真的很大）。HHKB 的做工倒是真不行，完全对不起这个价位。

我看到有人把空格键上下翻过来装的，为了避免大拇指被刮到。

1. Swift 在国内的热度不高，我的观察，直接原因是国内 iOS 新坑的机会很少，系统兼容性要求还高，独立开发者群体也没有欧美那样壮大，所以现存 iOS 项目很多都还是 OC 或者部分早期 Swift ，自然学 Swift 动力就少。

2. 前一点造成一个循环，就是 Swift 相关的东西，尤其是新东西，中文资料不多，乐意去学去教的可能也没那么多。

3. Swift on Server 这边，基本是小项目或者娱乐使用，极少有真正的生产项目大量使用 Swift on Server 的，而国内在后端技术这里普遍偏保守（ Go 的格外流行是另一个故事了），连 Ruby 甚至 Python 的市场都很惨淡，不可能会对 Swift on Server 这种东西产生兴趣。