希望自己未来过得（比现在）更好，这有什么错？

生态被领先太多了。GPU 并行算法的设计、实现、验证和调优是非常艰巨的任务，其中涉及到非常多因硬件而异的细节。例如，设计一个仅仅包含数据搬运的核函数，就需要考虑如何最小化 Cache 上的 conflict、如何 vectorize 等等问题。实际应用中需要的核函数往往还包括复杂的计算任务，实现起来更为困难，调优也是耗时巨大的工作。由于 GPU 的设备间差异很大，不同厂商的设备特性很可能完全不同，这样的问题很难通过设计某种 DSL（例如 Triton）来完全解决。

CUDA（及 PTX）是目前最强大、最直接、最完备的能够直接控制 NVIDIA GPGPU 设备的一套官方应用程序编程接口，也是官方面向 C/C++ 提供的唯一核函数编程接口。

后续是去和女友玩了，烂尾

Day 16 太累了，且有别的优先级更高的事，所以没有当天立即开。现在补上。

这次的 Tasks 出奇简单，就是 JWT，纯送。笔者作为万年互联网搬砖调包侠，做这种既不恶心人又没有很多流程的题就是随便写写的事。

今天写代码有 buff 加成：室友剩了小半瓶二锅头，可以先喝再写甚至边喝边写，如有神助。如图。

看瓶子上写的 42%vol，感觉已经不低了。写代码而言的话，笔者更喜欢配不超过 15%vol 的酒，能够喝得相对频繁一点也不上头。

Day 16 挑战的 bouns task 给了 200 分，比前几天的 75 更上了一个档次，实际上难度也确实提高了。题目没有把所有的细节说清楚，而是需要一定的探索。给了一个额外的 PEM 文件作为解码 JWT 的 key，但是没有具体说使用什么算法。当然这也构不成什么阻碍，一通调试也就搞定了。

最后仍然是通关证明：

是有的，你说的游戏我也玩过

Day 12: Connect 4 小游戏，一张有意思的视觉图：

玩法就是有 4x4 的格子，每一方可以选择（未满的）某一列，在该列的顶上放上 🍪 或者 🥛 。大概像这样：

比前一次好得多的一个挑战。一顿狂写之后解决。笔者现在已经把至今为止的 solutions 全部 push 到 GitHub 上，欢迎感兴趣的朋友们来交流：

最后仍然是一如既往的通关证明，生活中需要正反馈：

现在有挺多都是 AI assisted，先用 AI 跑一个初稿再人工校对

Day 9 启动！目前耗费时长最多、调试开销最大的挑战。一个 rate limiter，缝合奇妙单位换算。先放成功截图：

要求给 endpoint 加 rate limit，每 5 秒允许 5 次，所谓的“漏桶算法”，用 leaky-bucket 即可实现。

恶心就恶心在同一个 endpoint 有多种模式，JSON 的逻辑和不带 body 的逻辑完全不一样，却要共用路由；单位换算的公式也不给，只能自己查资料，查出巨量恶心小数。

bonus part 要实现一个 refill 功能，leaky-bucket 本身没有这个功能，手搓不太可能，加 Mutex 用重初始化代替草草了事。

哪怕是娱乐玩法，公式也是可以给一给的，笔者真的一点也不想知道 liters, gallons, litres, pints 这些单位之间的关系。

文章从访问网页的场景引入，由浅入深、由表及里地介绍了计算机网络系统的部分组成单元。文章整体具有较强科普性质，内容设置基本合理。

优点

1. 选用的场景、案例十分经典，贴合实际，具体而不抽象；
2. 内容细节较多，覆盖较为全面。

不足和建议

1. 文章中缺乏对于部分术语的必要解释：文章中多次提及 HTTP、HTTPS 等术语，而没有对其具体含义加以解释。适当补充高频术语的解释有助于读者加深理解。
2. URL 的介绍部分存在概念错误：参见 Wikipedia 中对于 URL Syntax 的介绍，斜杠和 host 应当都不是必须的。
3. HSTS 部分缺少必要的 Motivation 和详细说明：读者可能对 HSTS 的全称、希望解决的问题等抱有好奇和不解，并且这部分内容和上下文在逻辑上并不算连贯。
4. “发送 http 请求”一节中存在错误的因果：采用 HTTP 协议传输带来的不安全和数据泄露风险应当反映在传输过程中，即中间人能够通过 MITM 等方式窃取、篡改 payload，而非服务器日志中能看到。事实上，服务器为了处理请求，无论是否采用 HTTPS 协议都应当能够看到全部的 payload。
5. HTTP 与 TCP 的关系讲解不够深入：文章既然已经提到 TCP 的详细握手过程和时序，顺势提及 HTTP 中的 Keep Alive 机制也应当是顺理成章的。补充相关内容有利于文章整体更加协调、减少割裂感。

一个小插曲，笔者刚刚重新审视了 serde_yml，发现这玩意比较可疑。具体来讲，它干掉了 unsafe-libyaml 这个依赖，然后加上了一个 libyml。

unsafe-libyaml 和 serde_yaml 的作者是同一人，即放弃维护这些 YAML 相关项目的 dtolnay；libyml 和 serde_yml 的“作者”也是同一人，是 fork 了 dtolnay 这两个项目的 sebastienrousseau。后者的 id 也太长了，笔者暂且叫他 S 先生。

由于好奇，笔者 compare 了 unsafe-libyaml 和 libyml，先看看 Cargo.toml 都改了啥：

这可太厉害了。对于一个 fork 来的项目，S 先生完全删掉了原作者，简直是厚颜无耻；对于一个仅仅是 c2rust 翻译过来的东西，S 先生大言不惭地 claim 它 "safe and efficient"，简直是精神错乱。

S 先生把原项目 fork 过来具体加了什么新的 features 笔者暂时不得而知，maybe just "code refactoring and new unit tests"。尽管如此，它在 crates.io 中 yaml 关键词下的最近下载排名已经到达了第四位，十分具有迷惑性。

综合 S 先生的各种 overclaim，笔者做出了换回 serde_yaml 的决定。希望笔者今天所看到的这些 overclaim 只是因为 S 先生还没有完全完成他的大业，而不是另有所图。

Day 5 主要是做 manifest 解析，需要接收一个 POST 上来的纯文本 Cargo.toml 格式数据，解析出 package.metadata.orders 部分。

反应快的小伙伴可能读完 task 1 就开始用工具生成对应的 scheme 了，但笔者的习惯是先看完所有 tasks，以便确定设计到何种粒度。这里对于 scheme 的要求是“Cargo manifest”，遂 add 一个 cargo-manifest 的 dependency，这样也就不用手写 scheme 了。把 plaintext 做成一个 Manifest 对象，然后随便怎么数据操作都很 easy。

bonus part 要求推广到 YAML 和 JSON 格式，这可以简单地用对应格式的 serde integration 来实现。serde_yaml 竟然已经因为作者没有需求而不维护了，几经查找决定用 serde_yml。这一天的挑战还是比较 straightforward 的。

笔者在写代码的时候感觉到这个 scheme 里成吨的 Option<T> 有一点卡手，也许是打开方式不对，没有细想。无论如何，it works. 最后还是放一张 Day 5 的通关证明：

下一个挑战应该是 9 号开放，暂且拭目以待。

不好意思，前一条评论有一点小错误。|x| s + x 确实是 pure 的。我似乎脑补成了 |x| s += x。

“一些 rustlings 题目”这篇文章的评论区似乎没有 work，因此我评论在这里了：

c.iter().map(|x| s + x).collect();

这句话的问题在于 Iterator::collect 的返回值是泛型（受 FromIterator<Self::Item> 约束），因此编译器无法确定返回值的具体类型——究竟是 String，还是 Vec？或者 HashMap？因此 note 提示你手动指定，use collect::<String>() instead.

另外简单提一下，map 上去的函数最好是 pure 的，换句话说就是无副作用，这里按照你的思路应该用 for_each 更好，因为实际上是在把东西一点一点往里面加，而不是一对一地进行映射。map 是 lazy 的，所以不得不加上一个 consumer，也就是这里的 collect，但实际上 collect 的结果又 discard 了，没必要这样做，也不是 zero-cost 了。

一个比较简单的准则是，如果需要做带有副作用的“处理”，就用 for 相关的结构；如果只是一一对应地转换，就考虑 map 以获得更好的体验。例如：

fn print_iter<T>(it: T)
where
    T: Iterator,
    T::Item: Display,
{
    it.for_each(|x| {
        println!("{x}");
    });
}

trait MyTransform {
    fn transform(self) -> Self;
}

fn transform_iter<T>(it: T) -> impl Iterator<Item = T::Item>
where
    T: Iterator,
    T::Item: MyTransform,
{
    it.map(|x| x.transform())
}

详细可见 Playground。

既然 B 和 C 都得用 A，那肯定不是 B 或者 C 拥有 A 的所有权，而是 B 和 C 的所有权拥有者拥有 A 的所有权。

Troubleshooting any problem without the error log is like driving with your eyes closed.

点进去之前没想到写得这么好

游戏内容不评价，但是有一说一，宣发是真到位了，广告打的挺足，钱花到了刀刃上

我记得 🏆️ 家的 IDE 支持学信网直接解锁，难度比 gh stu pack 还低

能对目标时代的有识之士起到启发作用。

路线有点过时了，jQuery 这种已经淘汰的东西建议是碰都不要碰，别的不知道质量如何看标题也许还能看。如果有授课用的库版本落后 latest 很多这种现象就建议赶快跳车了。Stack Overflow Developer Survey'24 已经发布了，可以参考参考。

maybe related to: AttributeError: Can't get attribute 'NewsSummaryDataset' on <module '__main__' (built-in)> · Lightning-AI/pytorch-lightning · Discussion #15350

说明 codebase 太老了，应该降级依赖

dazidazi.com

用处不能说是没有，但也绝对不大。如果运维已经到了需要依赖这些东西的地步了，那有没有这些东西绝对也是无关紧要的。

一写一个不吱声，项目周期极长，破玩意极难写，意义也不大，感觉不如大模型套壳直接开骗

看个图就上头了？

看个人喜好吧，买什么其实都无所谓。我是粉丝，电脑手机壁纸一直都是亚托莉，之前玩的是盗版，趁五折入正了。

没一个好用的，各有各的问题，我可能更倾向 RN 一点。所谓的跨平台更多是一种噱头，除非就做 SPA 这样的 Web App，用终端设备的浏览器保证跨平台性，否则注定会陷入 API 不同所带来的泥沼之中。

这个机制就不可能实现，所以注定是沦为形式的。

我们给客户的建议一般是别用，该面板所需权限较高，可能引入额外的安全风险。

还敢用删库塔？（仅锐评，不构成医疗建议）

饿殍：明末千里行

百炼始成钢。

感谢楼主分享！ 😘

严选 Pro 会员可以叠，直接送了我两年；黑胶 VIP 不能叠，只拿到三个月。

在 os.system 中直接 sudo 可能会被要求输入密码？

caddy 配置就没几行，不懂为什么会出问题。国内访问想解决必须备案。

我简单梳理一下，你的 app 在 docker 里面 listen 了一个端口 X，这个端口需要通过 docker 映射出来到 Y，那么对于宿主机上的 caddy，需要把 Y 反代到 80/443。假设 Y = 8000，下述 Caddyfile 我感觉应该有效：

ilovebread.buzz {
  reverse_proxy http://localhost:8000
}

ilovebread:8000 是什么玩意，一般不是 http://localhost:8000 吗

量化给的本来就多，只去实习的话肯定是有比没有好，远大于软院集中实习。

这个确实挺搞笑的，一出问题就开摆喊“请立即接管” 🤣

准确地说，如果内存是未初始化的，编译器可以在每次引用这部分内存时假设它是任意值（一般是对于求值来说更“方便”的值，以便进行优化），并且不需要保持前后任意次对同一块未初始化内存区域的这种假设的一致性。

但是这可能还并不能完全解释清楚程序的结果在 1 和 4 之间反复横跳的全部原因，个人建议使用 -fsanitize 编译选项，指定适当的 Sanitizer，以便更为严格地捕获异常行为。

有一点，所以我现在比较不喜欢搓 UI，感觉这样对我来说没有什么创造性，是一种机械的劳动

建议阅读："What The Hardware Does" is not What Your Program Does: Uninitialized Memory

甜是挺甜的，就是籽有点多，感觉一瓣里就有 2~3 个籽，我个人觉得是很影响体验的，不知道门友在不在意这个 👻

调研还是很重要的，不知道怎么做的时候就去看看别人会怎么做。例如你的这俩需求就能找到不少现成的 solution。

其实，想不到思路本质上还是因为见得不够。问题都是可以被分解的，例如“拖动图片直接上传”就很容易分解成“上传文件”和“捕获拖动的图片”这两个问题，前者也许可以用关键词“js upload file”之类的去搜，后者其实叫 Drag and drop API，简称 DnD。

相比之下，解析 Markdown 可能更单纯一点，具体来讲就是输入 Markdown 格式文本输出 HTML 格式文本这样的一个转换器。自己造轮子的话可能工作量比较大，因为 Markdown 语法其实还挺多的，如果需要语法扩展就更多了；但是像这样的需求往往可以找到很多现成的轮子用，JS 的 markdown-it、marked、PHP 的 parsedown、Rust 的 pulldown-cmark……

不用跟别人比，每个人的情况都是不一样的。

调整 CSS 很困难，一般也脱离了正常意义的编码范畴。可以试试各种 UI 库，例如面向 React 用户的 MUI 或致力于简化 CSS 的 Tailwind。调整 CSS 需要熟练利用开发人员工具，直接在页面上对照着调，然后保存自己满意的结果。

不要畏惧“屎山”，对于个人项目而言，重构尽管听起来很难，做起来却是非常容易的，当你觉得做不下去的时候，大胆推翻就是了，Git 的各种功能允许我们放手做这些，just -> git checkout -b next 🎉

我举一个很简单的例子，应用程序的登录状态（包括当前用户的必要数据）和计数器组件的当前值就是两类不同的状态。

应用程序的登录状态是一个全局的状态，组件树的各个层次都会有使用它的需求，例如 Navbar 右侧到底是显示头像框还是显示登录和注册按钮、内容区到底是显示回复按钮还是显示“登录以回复”。这样的状态通过 props 传递就会非常不合理，因为真正的 state 在最顶层组件上挂着，下级组件要用就必须一路透传下去，哪怕中间某个组件用不到（这样的组件远远多于用得到的），它也得给它的后继传递。对于这种状态，很显然 context 是更好的。

计数器组件的当前值就不一样，它是很典型的局部状态，它就是维护它自己功能用的，别的组件根本不会 care 这个，那它就是一个小小的 state。

我个人更喜欢“以随心所欲写自己想写的程序”为起点，在这个过程中就会自然而然地学到如何去做这个事情。整个流程做一遍下来，就会理解得更深入一点。然后随着不断迭代/做新的东西，每一次都能反思之前的设计存在什么问题，迭代的次数多了就会逐渐地学会。

具体一点来讲，我会更倾向于一边做，一边阅读文档学习我需要用到的部分，而不是先学完了再做。

“边写边学”会损失“系统性”吗？其实是不会的，开发是一个与实践强相关的事情，系统化、有体系的知识一定是在实践中建立起来的。实际上，在实践中经常会反复阅读文档数遍，这样建立起来的认识无论是在深度还是在熟练程度上都是远超“先学后写”的。

redux 之类的库做的是更复杂的状态管理（state 只能相邻层级传，context 没有原生持久化），需要管理什么状态、需要什么样的逻辑去管理状态、需要管理多大的状态，决定了状态管理的方式。

我反正觉得 yyx 的更烂，不懂为什么那么多人尬吹（纯个人意见，不作为医疗指导，我就是个 sb 没必要把我说的当回事）

我们在做一些商单的时候为了快都是能用就行，什么 React 什么 Vue 都是混着用的，实在没什么美感。但是从开发体验来讲，最近因为莫名其妙的原因 Volar 一直炸，而且 Volar 启动远远慢于 ts 的 ls，不得不黑 Vue 了。

yyx 这波锐评“被框架 PUA”其实是毫无道理的，React 实际上是形成了一种设计模式，这个文档是对这种设计模式的解读，这种模式在 Vue 中也是无所不在的（所谓的 Composition API），喷这个框架艰深复杂，多少有点牵强了。