Tomoko RD - 动态

🔖 If you don't tinker, you don't have taste | seatedro #pinboard 太酷了，这个网站 https://seated.ro/posts/tinkering-a-lost-art.html

seated.ro

If you don't tinker, you don't have taste

programmer by day, programmer by night.

Tailscale 推出了一个 Peer Relays 功能测试，可以将网内的任何节点直接设为中继节点，在直连不通时候的连接优先级高于 DERP 中转服务器，用于提供更低的延迟和更高的吞吐量。 https://tailscale.com/blog/peer-relays-beta https://tailscale.com/kb/1591/peer-relays

Tailscale

Tailscale Peer Relays: High-throughput relays for secure, flexible networks

Tailscale Peer Relays provide predictable, performant access, entirely within your own tailnet.

在家庭社会失权的年轻一代，更热衷互联网表态。（JK罗琳VS爱玛跨性别争议的背后） @天真的和感伤的小说家:

发布视频-人文历史-社会观察播放量:12.43万弹幕:601 评论:681 点赞:6488 投币:3161 收藏:2498 转发:476 发布日期:2025-10-21 09:30:00 上传日期:2025-10-21 07:28:02

印度人也太猛了，整篇下来，India 出现了 13 次，China 0次 https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/

POLEBUG - WHAT ARE YOU THINKING?

最近我发现了一种极其适配的方式消磨这段时间：看书！

Tomoko RD pinned «📝 2510-日本七日记-大阪-京都-东京 #blog 更新了，是半年记（伪）。写到最后，都不知道要起什么标题了😢。 https://niracler.com/2510/»

看过世界计划：无法歌唱的初音未来评分: ★★★★☆ 备注: 7/10 没有什么困难是一场 Live 不能解决的。如果有，就同时开五场。再不行还有 After Live。（完全不懂 https://movie.douban.com/subject/36982741/

📝 2510-日本七日记-大阪-京都-东京 #blog 更新了，是半年记（伪）。写到最后，都不知道要起什么标题了😢。 https://niracler.com/2510/

Niracler

2510-日本七日记-大阪-京都-东京

完美结局至少需要二周目，青春没有二周目，故青春必定有缺陷。这篇游记主要写给十年后的自己和同行的林克克，也写给有 0-1 次日本旅游经验的朋友，以及爱看八卦的网友。

kimi cli 可以发 D-Mail (不是) source

🌟 starred Afilmory/afilmory #github #star https://github.com/Afilmory/afilmory

GitHub

GitHub - Afilmory/afilmory: Modern photo gallery for photographers, with S3/GitHub sync, EXIF details, maps, and a WebGL viewer.

Modern photo gallery for photographers, with S3/GitHub sync, EXIF details, maps, and a WebGL viewer. - Afilmory/afilmory

Tomoko RD

今天3个 Offer 🙂

Vibe-Code => Myself-Code 最近将自己写了几个月的代码，挑了一部分逻辑（1/5）往大项目提了 PR。在经历了 Conversation 100+、Commit 90+ 、Time 50d+ 之后，总算是将 1400 行的代码改好，进入等待最终合并的阶段。 --- 这周将 PR 中的反馈整理成文档，并重构原有仓库。接近少了一千行….

过度设计 : 有的功能明显是想多了，用 200% 的复杂度实现了 105% 的功能，以至于维护起来像是穿着重甲在水中行走。因为 PR 中要给人说清楚，就索性直接删掉了。
没有遵守 Best Practice ：有很多逻辑既可以「这样写」也可以「那样写」，但这种视角一般是入门者才会这样。若是经验丰富的开发者他们眼中的方案或许就会收缩到少有的一两种，然后再根据项目的「惯例」来确定唯一的方案。而一般这样做的话，很自然就会发现有不少趁手的工具直接复用从而减少代码。（其实他们的文档中都有提到的）
其他：删除过多的 log 以及混乱的 try-catch

--- 四舍五入，这些都是 Vibe-Coding 的副作用了，「我没有足够的能力审查大模型编写的代码」。因为言出法随，动动嘴皮子就能写好功能，自然多了许多无法掌控且不必要的功能；由于全程依赖大模型总结开发文档，只有在进度受阻时才查阅原文，很自然就不知道很多 Best Practice；至于过多 log 和混乱的 try-catch 就是处理各种无法控制的 BUG 频多的代码所遗留下来的。 --- 我无疑走了弯路。但鉴于这是我第一次在工作上写 python 项目，且是单兵作战，且该大项目的要求确实挺多的。我挺怀疑有没有更好更快速的成长方法？（不过多看文档原文、多看别人的实现方案，这总归没错的）有感于: The Programmer Identity Crisis #自说自话