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 -> 4list2:1 -> 3 -> 4
并且我们需要想一下,这个 list1、list2 的大小大概率不一样,所以我们最好使用一个单独的结果和一个当前的 cur 当前 node。
第一次循环:
- dummy: 0 -> null
list1:1 -> 2 -> 4list2:1 -> 3 -> 4
第一次循环完成之后:
- dummy: 0 -> 1
list1:2 -> 4list2:1 -> 3 -> 4
第二次循环之后:
- dummy: 0 -> 1 -> 1
list1:2 -> 4list2:3 -> 4
第三次循环之后:
- dummy: 0 -> 1 -> 1 -> 2
list1:4list2: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 ----------------->| | |
