感觉很不错的项目，商业模式从 saas 转变成开源的话，感觉合伙人好像更难找了吧。

一堆人抱怨没有中文简直让人流汗黄豆了，这种翻译 doc 的事情在哪个项目里都不会是高优先度的任务。

之前也稍微有用 Swift 来开发，感觉 Swift 和 SwiftUI 这一套技术栈确实是蛮有趣的。不过也确实目前而言有许多不方便的地方。

首先说 Swift 的话，我觉得这门语言是一个有点苦涩的语言……当然这可能和我比较偏向于 Kotlin/C#/ML 这类托管语言有关。首先就是这个 protocol 似乎和 OOP 的 interface 并不完全等价，所以在实际使用的时候会有许多小坑（例如泛型里面的`& any`），虽然也是很细枝末节的事情了。然后在实际编程的时候，虽然从 Java 过来的可能会觉得很方便，但用惯了 Kotlin/Scala 的总觉得 lambda 和流式编程缺点味道，那个 void 也比较恶心人，再加上时不时摆烂的类型推导/类型检查，经常给人一种累觉不爱的感觉。

虽然说，考虑到 Swift 也蛮老了，再加上历史包袱/性能要求还有和 ObjC 这个老古董的兼容，其实也没法要求更多就是。反过来说，Swift 至少在 Optional 和 Actor 的支持上，似乎走的比 Kotlin 这种一般通过 OOP 语言更远，那个 throws 的设计就感觉蛮惊艳的（ op 用 Rust 倒是可能会蛮习惯了）。

SwiftUI 的话，我比较喜欢的也是这种充分和背后的编程语言结合的设计，比如说 Binding 还有 Observable 的语法。

不过就我自己感觉，这个生态圈最大的问题可能还是新手不友好。稍微形容一下，大概类似于一开始有很贴心的官方教材辅导告诉你 1+1=2 和怎么解二元一次方程，但然后等你开始学微积分的时候就发现只能自己摸索了。op 提到的课程我之前也有找到过，但那时候我大概处于「课程或者书本上的东西我都会，但我不会的东西找不到教材」的程度，所以这些书或者教程一个也用不了，最后也是靠着 v2ex+stackoveflow+自己摸索来解决的。也许归根结底，还是生态圈太小了。

整体来说，感觉 Swift/SwiftUI 算是那种慢慢演进会变得越来越好用的，代价就是得丢掉低版本的软硬件，还有越来越高的配置要求了。

还是希望 SwiftUI 能越来越好吧，再怎么说，写起来还是比某框架的括号地狱好多了。而且比起某企业级状态管理和清洁架构，我还是更喜欢这种声明式代码。

reduce 里面可以是一个列表。当然 java 没有模式匹配写起来比较恶心。

普通的 sde 搭得上这班车吗，也有可能搭上的是泡沫破裂的灵车。

不含歌词的纯音乐怎么样

Java 的话可以看一下 On Java 8 ，这个算是 Thinking in Java 的后续，但旧书版本明显太老。算是相对权威的教材，但也有讨论一些比较新的话题。

书的话我觉得值得推荐的就这一本了，别的都无所谓。然后就得看 op 想要做啥，有啥想法或者有没有什么大概的思路了。

只是想练习一下算法和编码能力的话 CS61B 也不错。

apisix 这公司好眼熟，怎么感觉好像发生这种事情一点也不奇怪

果然变成了网站分享贴

@SculptureSand 语言本身不会烂大街，框架的话，除非非要死磕八十年前的 Spring 或者过时的 Python 框架其实还好。可能更重要的是看准一个方向然后学下去。Flask 学到背后也会有协程、并发、微服务，Spring 跟着培训班随便学下来也可以很浅。

培训班给不了文凭的话没啥学的必要，Spring 也好 Flask 也好应该都有很完善的文档，相关的书籍或者教学也很多。国外流行 bootcamp 主要是它毕业后会给一张 certificate ，前几年缺人的时候企业看到这张纸就招人，现在随着供需关系的反转和 bootcamp 的过度发展也不好使了。国内这群培训班从一开始就没有任何认可度，完全没必要。

比起这个，有个拿手的项目更重要。你自己做的网盘这几个其实算是不错的起点。

这个语言好像可以相对简单的写一个翻译器

@locoz 信息量充足是一回事，能通过这些信息表现出 op 什么样的形象是另一回事。考虑到 op 发了新版本我就不太纠结旧版了，但是旧版的介绍给人的感觉是，读完了知道了这个项目是做什么的，但是对 op 的认识却很浅显。另外一般读一份简历的时间也就十几秒时间，对角线扫描的读法，自然要考虑尽量精简词句。

op 讲故事这个自然是亮点，而且也看得出对项目设计和开发的思考和中间的多次迭代实验，但这些应该尽量用关键字让他们能够第一时间抓住读者的注意力。

看了第二版的话，确实精简了很多，但确实也有缺少了讲故事的环节。其实我不太清楚这个「项目简介/技术栈/项目要点」的排版是不是国内简历必须项。国外一般流行的是用 STAR 法则，每个小点对应一个 S ，T 或者 A 或者 R ，但不一定要是这种一板一眼的形式。再比如说技术栈就可以融入到其他小点里面而不是单独列出来。然后我觉得第一版里面讲故事的就可以试着改造成 STAR 的思路。另外一个思路是 XYZ ，不过这里不一定套的上。

S：设计了一个匿名、加密的文件分享网站以便在公共场合分享传输文件
T：前端使用 Vue ，部署在 Vercel ，后端使用 Flask 暴露出 REST API ，部署在阿里云 FC3.0 ，使用了 Serverless 架构并使用 GitHub 进行自动对接；数据存储方面综合使用了 SQLite 和阿里云 OSS
A：综合考虑从零开始的渐进开发体验和按需扩展的需求，结合使用阿里云的过往经验，在仔细筛选和多轮原型设计后决定上述方案；根据需求推导出架构设计，用思维导图确定之后逐渐实现各个服务模块，例如 X ，Y ，Z
R：在项目落地的同时，有特意留意状态码处理和异常捕获，也有平衡数据库读写和计算，设计负载平衡，etc

随便写了一下，可能有点乱，然后我自己语言表达也不是很好。但大概思路应该是差不多的吧（去掉前面那个字母）。其实基本上就是把第一版精简后的样子。

当然如果国内必须这样排版当我没说……毕竟也看到很多人是这么排版的。

其实我更想知道 JD 上写精通是什么情况。

比如精通 C++、精通 Rust 什么的，真是这种人公司不一定出得起钱吧。

其实我更好奇 JD 上要求精通是什么情况

怎么现在人都喜欢把简历写成项目说明书。。

挺没法理解在个人 blog 里塞一堆广告的做法

高大的建筑物和精美的衣服都是泥瓦匠和纺织工做出来的。用他们来类比程序员有什么问题吗？

更不用提许多程序员写的代码估计换个外包就被扔掉，代码质量也不咋样，哪来的底气去嘲讽实实在在地制造产品的人。

我一直在好奇这种东西和国外流行的 BNPL 有多少相关性

虽然我觉得提问的智慧这篇文章很多时候是有点过了头的，但这个场合我觉得丢一个提问的智慧的链接是最合适的回复。