ARTS 0802: 合并有序链表、AI 时代的技术断层与 TCP 200ms 延迟之谜

每周完成一个 ARTS: 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。(也就是 Algorithm、Review、Tips、Share 简称 ARTS)

Algorithm

算法这周先来一个简单难度的(好久没刷过算法了) https://leetcode.cn/problems/merge-two-sorted-lists/description/

先句一个具体的案例

  • list1: 1 -> 2 -> 4
  • list2: 1 -> 3 -> 4

并且我们需要想一下,这个 list1、list2 的大小大概率不一样,所以我们最好使用一个单独的结果和一个当前的 cur 当前 node。

第一次循环:

  • dummy: 0 -> null
  • list1: 1 -> 2 -> 4
  • list2: 1 -> 3 -> 4

第一次循环完成之后:

  • dummy: 0 -> 1
  • list1: 2 -> 4
  • list2: 1 -> 3 -> 4

第二次循环之后:

  • dummy: 0 -> 1 -> 1
  • list1: 2 -> 4
  • list2: 3 -> 4

第三次循环之后:

  • dummy: 0 -> 1 -> 1 -> 2
  • list1: 4
  • list2: 3 -> 4

先拿具体的例子举几个例子试试,比抽象的想象要靠谱的多(我个人是这样的),当然现在有 AI 如果卡住了,可以很方便的让 AI 给咱们提供思路,但是切记不要直接要答案。

java
复制代码
/** * Definition for singly-linked list. * public class ListNode { * int val; * ListNode next; * ListNode() {} * ListNode(int val) { this.val = val; } * ListNode(int val, ListNode next) { this.val = val; this.next = next; } * } */ class Solution { public ListNode mergeTwoLists(ListNode list1, ListNode list2) { ListNode head = new ListNode(0); ListNode cur = head; while (list1 != null && list2 != null) { if (list1.val > list2.val ){ cur.next = list2; // 这里需要注意向后移动 list2 = list2.next; } else { cur.next = list1; list1 = list1.next; } cur = cur.next; } // 最后需要加上其他不需要进行判断的节点 if (list1 != null) { cur.next = list1; } if (list2 != null) { cur.next = list2; } // 最后需要返回 next 因为头节点是 0 return head.next; } }

Review

文章:https://berthub.eu/articles/posts/ai-for-decision-makers/

我自己大概印象比较深的点:

  • 很短时间就能产出高质量文章,让人没办法分辨,到底是人写的还是 AI 写的
  • vibe coding 很多 C 端用户,自己 vibe 的程序自己不知道如何判断程序是否真的是“好”的,不仅仅需要看能否运行还要看代码的维护、质量等等,C 端用户说 AI 真的好不一定是真的好
  • 还有一件事就算是最强的 AI 也是会犯错误,会一本正经的胡说八道
  • AI 不是黑魔法,需要高质量的输入才能有高质量的输出
  • 人才断层,不培养初级工程师那么等到现在高级工程师都退休了之后,还会不会有匹配的人才

Tips

1、AI 改好代码之后可以让他把线上网站的信息进行截图,和当前修改进行对比进行判断。是否有破坏性的修改,如果有的话再让 AI 进行 review 代码!有可能会发现很明显的问题

2、kill 某一个端口的服务,一行命令都搞定

text
复制代码
kill -9 $(lsof -t -i:port)

3、Windows 查询服务器端口可用 telnet,Mac 需改用 nc(netcat)。

bash
复制代码
nc -vz 192.168.1.100 8080
  • -v:输出详细信息
  • -z:只扫描端口,不发送数据

Share

文章:https://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/ 关于 TCP 的文章,讲来一个具体的案例使用代码 POST 请求使用代码请求服务器的时间普遍会比 curl 单独请求长 200ms。

主要原因是因为客户端的 POST 请求会分成两部分发送:request header、request body,当 requst header 发送给服务端之后,客户端再等待服务端的 ack 才能发送 request body 但是服务器由于有 delay ack 的设置所以不会立刻 ack 需要等待 200ms 左右才进行 ack,客户端收到 ack 之后才发送 request body。

完整示意图:

text
复制代码
客户端 服务端 (Delayed ACK) | | |---- TCP pkt1: headers -------------->| | (等 ACK 才能发 body) | (故意不立刻 ACK) | | | ≈ 200ms 空等 | | | |<------------- ACK -------------------| (delayed ack 超时) |---- TCP pkt2: body ----------------->| | |
0个评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
leikooo
作者分享
ARTS 0815: 分隔链表、大删除是加活不是减负与协议栈如何一层层拆信封
3
DeepSeek Harness 缓存命中率太惊人了,有时候竟然能到 99%,看鱼皮哥的视频竟然还出现过 100% 😱 https://www.bilibili.com/video/BV1VkgK6NEZS
7
ARTS 0809: 反转链表、Shopify 如何用 MySQL 解决超卖与 AI 时代程序员的价值
5
译文:《SwiftUI 七年:平庸的故事》 SwiftUI 在 2019 年高调发布,本应成为苹果全平台成熟、可量产的 UI 未来。七年过去,到了 2026 年,它仍像一场永不结束的 beta:布局难预期、性能不稳、数据流混乱,还几乎没有可靠的向后兼容,开发者被迫写一堆 shim 和 workaround。 作者用苹果官方教程(甚至是有问题的)以及与 UIKit 的对比说明:SwiftUI 用“看起来方便”换掉了精确的工程控制。更深一层,他认为这反映了苹果从 Cocoa、Aqua、Auto Layout 那种不妥协的工艺,转向“够用就行”的企业文化。 SwiftUI 为何存在 苹果并非单纯想提供更好工具,而是不得不应对竞争:React、React Native、Flutter 让“一套代码多端跑”变得诱人;Mac 上原生应用又日渐被网页和 Electron 吃掉。SwiftUI 要同时拴住原生生态、并降低移植到 Mac 的成本。卖点是:响应式数据流、声明式布局、跨平台复用。 数据流 “单一数据源”听起来很美,实际却是 @State、@Binding、ObservedObject,再到 Observation / @Observable 的不断换代。你很难确定视图会更新几次、为何更新;它该忽略的变化会反应,该关心的变化又可能忽略 - - 像个黑盒。 布局系统 基于尺寸协商的布局在 Keynote 里很合理,做浮动视图、自定义侧边栏时却极度不稳定。官方教程里一个很普通的侧边栏,多年仍有问题。布局脆弱到最后往往只能上 GeometryReader - - 一旦用了,声明式优势就没了,还要手算坐标,而且下一版布局规则一变,数学还得重写。 API 稳定与功能对等 代码里满是 if #available。滚动收起键盘要到 iOS 16;工具栏定制很晚才来;网络图片 AsyncImage 要到 iOS 15,缓存相关 API 到 2026 年 7 月仍在 beta。旧 API 常被换掉(如 NavigationView → NavigationStack),开发者要维护多套实现,等于替苹果做 QA。对比 Android 的 Jetpack Compose 可作为依赖打包回退到旧设备,SwiftUI 做不到“写最新 API、稳定回退”。 性能 在真实对比里,即便做了后台解码等优化,SwiftUI 图片网格滚动仍明显不如 UIKit。若展示一堆 JPEG 都得靠顶级芯片撑,架构本身就有问题。 跨平台神话 苹果说的是“学一次、到处用”,不是“写一次、到处跑”。iOS 上学到的布局很少直接适用 Mac;同一套 view 跨平台实现也不一致。结果常变成:学一次、再学一次、某处能用、处处要调。 哲学转向 最大的问题是“够用就行”:覆盖 90% 用例就算成功,用 velocity 掩盖质量下降。作者列举系统与一线应用中的各种瑕疵,认为这不是偶然,而是苹果主动降低质量门槛 - - 所以即使过了七年,他仍不信任 SwiftUI。 结论 对构建稳定、高性能、可维护系统真正重要的部分,SwiftUI 几乎都有问题。它不是“极差”,而是平庸 - - 用假便利换真精度,要么你花时间给框架打补丁,要么把半成品发出去。作者更宁愿继续用“遗留”的 UIKit / AppKit。 最后小总结: 最让人不能接受的不是“SwiftUI 还有 bug”,而是它把“看起来很快”当成了工程上的完成态。声明式、预览、跨平台,每一项都在秀高级感,可真正写进业务后,你面对的是难预测的重绘、脆弱的布局、层层 #available,以及把兼容和排错外包给业务方的现实。七年够长了,若还靠“框架还年轻”解释,那更像是对标准的侮辱。技术选型从来不只是语法偏好,而是你选的是可预期性、可维护成本,以及对用户体验的态度。平庸的“成功”往往比明显失败更危险 ,你说它能上线、能 demo、能交差,但是却在细节里一点点磨损信任。工具可以换代,但对质量的要求不该跟着一起降级。
4
Spring 团队开发者布道师 Josh Long,从 2011 年起每周二坚持写 This Week in Spring https://spring.io/authors/joshlong,大概 15 年半从未间断,到现在大概写了 800 期以上😱 大佬在采访里他说,写博客不是额外负担,而是逼自己整理每周所学的「强制机制」——反正本来就会刷社区动态,写出来既方便自己,也帮到别人。更重要的是 Spring 一直在变:微服务、AI……永远有新东西可聊,停一周就容易掉队。一旦养成习惯,坚持往往比重新开始更容易。 这种级别的大佬都还在用周更逼自己不掉队,我更没理由再拖了。还有之前左耳朵耗子大佬说的 ARTS 打卡,我老实说只撑了两周,真的需要捡起来了,加油✊
10
下载 APP