最新

我创建了 rapid-rs，以消除在启动新的 Rust 网络服务时所需的冗余代码。<p>只需一条命令即可获得： - 自动配置的数据库、日志记录、CORS - 在 /docs 提供的 OpenAPI/Swagger UI - 请求验证 - 适用于生产环境的可观察性<p>基于 Axum 构建。初步基准测试显示每秒约 50,000 个请求，内存占用在 10-20MB 之间。<p>这是 v0.1 版本，欢迎反馈！<p>库链接：<a href="https://crates.io/crates/rapid-rs" rel="nofollow">https://crates.io/crates/rapid-rs</a>

我正在考虑迁移一台Windows服务器（Windows Server 2012 R2 Standard），想了解是否有办法查看哪些文件正在被读取。我知道操作系统会保存这些元数据，但我也了解到这些元数据并不可靠。请问是否有第三方工具或某种PowerShell脚本可以用来跟踪这些数据？

嗨，HN， 几个月前，我发布了这个Chrome扩展的早期版本。从那时起，我对其进行了优化，修复了一些稳定性问题，并且最近它在Chrome Web商店的“推荐”栏目中被展示，这让我感到很惊喜。 这个扩展的功能： - 直接在浏览器中检测活动的推文或线程 - 收集相关上下文（父推文、作者信息、线程结构） - 格式化提示并发送给OpenAI API - 将生成的回复直接插入Twitter的原生回复框 所有这些操作都在X.com的DOM内部进行，不会存储任何用户数据。 技术细节： - 使用MutationObserver跟踪X.com不断变化的DOM - 处理动态插入的推文节点、影子DOM和线程扩展 - 防抖上下文提取，以避免不必要的重复运行 - 模拟原生输入事件来注入回复，使其感觉像是内置的 - 避免后端状态；除了最终的API调用，所有操作都在客户端读取 挑战： - X.com经常改变UI结构，因此选择器会不稳定 - 防止在DOM重新渲染时重复注入 - 保持提示大小足够小以实现快速生成 - 减少开销，以免扩展拖慢页面速度 最近的改进： - 更稳定的推文/线程检测 - 更好的上下文选择逻辑 - 回复弹窗中的UI更简洁 - 小幅性能修复和竞争条件修复 Chrome商店页面：[链接](https://chromewebstore.google.com/detail/xinsightai-ai-reply-assis/ngppfaclmbaaagondnfjkigkmacfphhc) 希望能收到那些有构建浏览器扩展或处理X.com DOM模式经验的人的反馈。欢迎讨论任何细节。