"IDE 插件 AI Translate 经过几个小版本的迭代，目前已经支持市面上主流的 LLM 服务提供商，主要有以下几个服务提供商：\nOpenAI Anthropic DeepL 智谱 GLM 字节跳动 DeepSeek Alibaba GitHub Gemini Ollama 除此之外，还有两个智能体服务商\n阿里云百炼 扣子 基本已经满足了大多数开发者的翻译需求。\n下载地址：\nJetBrains: https://plugins.jetbrains.com/plugin/25313-ai-translate VSCode: https://marketplace.visualstudio.com/items?itemName=cfanbo.ai-translate 特别是最近对 Ollama 的支持，允许用户使用本地的大模型提供服务，无需像其它几个 provider 一样，还需要注册会员和身份主证。只需要填写一个 URL 地址即可使用，非常的方便。\n由于目前使用的 prompt 是统一的，因此不同 provider 的翻译效果可能不一样，后续有可能提供针对不同 provider …"

"在Zed IDE中，默认只支持以下几种 providers :\nZed AI (Configured by default when signed in) Anthropic GitHub Copilot Chat 1 Google AI 1 Ollama OpenAI 这对于国内开发者来说，由于政策原因，想使用起来可能需要借助一些科学上网的方法，这就有点麻烦了。另外国内几个大模型公司也都提供了一定的免费额度的 tokens，如果可以在 Zed 里集成国内几家的大模型，也是一个不错的主意。\n几个月前试图通过自定义Endpoint 的方法绕过官方对使用区域的限制，但一直没有成功。今天重新试了一下仍是无效，本想打算在官方仓库里开发一个自定义provider的功能，就是感觉着有点麻烦，另外更担心个人电脑过旧，编译是一个大问题，于是重新在issue里找到了一个解决办法 https://github.com/zed-industries/zed/pull/13276，就是设置起来有点麻烦。\n本文将其设置方法整理如下。\n配置 settings.json 首先配置 settings.json …"

"AI Translate 是一款基于LLM实现的IDE专用翻译插件，主要为开发人员在查看项目源码时，可以快速对一些代码英文注释进行中文翻译，这对于英文有些弱的同学很有帮助，下面讲一下为什么开发这款IDE插件，以及它比其它同类翻译插件有什么好处。\n为什么开发这款翻译插件 在以前使用IDE看项目源码时，经常遇到长段的英文段落注释信息，理解起来经常会吃力。当时找了一些翻译插件，但都感觉多多少少有些缺陷。\n主要表现以下几点：\n翻译质量差，有些翻译软件可能将一些专业术语翻译成了其它名词，整体翻译后的语句读起来很让人头疼 由于在源码文件里，多数源码说明 信息都是以注释方式出现的，多数翻译软件无法做到忽略注释符后连贯起来翻译。 目前市面比较好用的翻译插件“沉浸式翻译”，可惜只支持浏览器，并不支持IDE 曾有一段时间的做法是手动从IDE里复制信息、删除注释符、重新整理段落，再到网页翻译里进行翻译，有时翻译的效果不太好，可能同时会用两个翻译软件。\n去年看kubernets源码时，再次被折腾一番，当时花了两三个小时开发了一款基于chrome浏览器的插件，主要实现功能是在软件翻译前，将注释符移除和重新整理段 …"

"今年又一次重新学习RUST这门编程语言，并从零开发了一个kv存储系统 minKV，慢慢的越来越有感觉了。\n本篇主要将日常学习中收集的一些入门教程进行一下汇总，希望对于一些想学习这门开发语言的同学有所帮助。\n下面教程按照推荐顺序，由浅到深依次列出。以下内容将不定期的更新，请自行收藏。 如果您有更多好的教程的话，也可以在评论区列出，大家相互学习。\n入门教程 Rust 程序设计语言 https://doc.rust-lang.org/book/ / (中文版)\n官方教程，强烈推荐，同时还有非官方翻译的中文版。遗憾的是这个教程有许多概念介绍的都有点不清不楚，只能通过下方的一些资料自行补习。\nhttps://play.rust-lang.org/ 在线 RUST 程序 Playground，类似golang的 Playground，非常的方便\nRust Language Cheat Sheet 看完官方的教程后，紧接着就看这篇，先了解一些内存布局，后面再看其它教程就更容易理解了\nThe Cargo Book Cargo 是RUST 中的包管理工具， …"

"上一篇 我们介绍了一些错误处理的最基本的用法，主要是指对 panic! 、unwrap、expect 和 ? 这些宏或函数的介绍。但这仅仅是一些最基本的处理方法，对于自定义错误这一块并没有做任何介绍。\n实际开发中可能默认的错误类型，并无法满足我们的业务需求，这时一般需要通过定义自己的错误类型来实现。在rust中错误类型是通过 enum 枚举定义的，对此官方文档也做了一些简介，本文主要介绍一些业务开发过程中对错误的处理方案，当然主要是一些最基本的用法。\n自定义 Error 在 Rust 中，自定义错误类型是一种常见的类型，特别是当你需要提供比标准错误类型更具体的错误信息时。Rust 中的错误处理是通过 Result 和 Error trait 来实现的。以下是如何实现一个自定义错误的示例：\n定义一个错误枚举类型。 实现 std::fmt::Display 为自定义错误提供用户友好的错误信息。 实现 std::error::Error trait，这通常是通过派生 Error trait 来完成的。 下面是一个简单的示例：\nuse std::fmt; use …"

"gitig 是一款基于 https://github.com/github/gitgnore 仓库开发的.gitignore 客户端CLI 管理工具，也是每个开发者必不可少的提高工作效率的必具工具。\n它基于官方仓库 https://github.com/github/gitgnore 丰富的 .gitignore 数据源，帮助开发者快速实现添加各类开发项目的git版本控制忽略文件清单。\n开发背景 工作中，经常需要开发各类项目，如基于 vscode 编写 rust 项目，这时为了方便进行Git管理控制，有些项目文件可能并不需要提交到git仓库，需要将一些文件写入 .gitignore 文件进行忽略。\n如果手动编辑 .gitignore文件可能有些麻烦，另外也能会有一些文件项被遗忘或写错，这时如果有一些工具可以将行业能用的忽略配置项一键写入 .gitignore 文件似乎是一个不错的主意。\n其中著名的 https://github.com/github/gitignore 就是一个专门收集各类开发语句或IDE 需要忽略的 .gitignore 推荐配置的仓库，目前star …"

"Rust 中错误可分为两大类：可恢复的（recoverable）和 不可恢复的（unrecoverable）错误。\n对于一个可恢复的错误，比如文件未找到或权限不足的错误，我们很可能只想向用户报告问题，让用户来决定后续操作。\n不可恢复的错误总是 bug 出现的征兆，比如试图访问一个超过数组末端的位置，因此我们要立即停止程序，主要通过 panic! 实现。\npanic! panic!属于不可恢复错误类型，一旦发生程序将立即退出。\nfn main() { panic!(\u0026#34;crash and burn\u0026#34;); } 这里由用户调用 panic! 宏来实现程序的中止，同时自定义错误信息。\n➜ cargo run Compiling hello-world v0.1.0 (/Users/sxf/workspace/rust/hello-world) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.68s Running `target/debug/hello-world` thread …"

"在 Rust 中有 包、crate、模块 概念，本文我们介绍一下它们之间的关系和调用方法。\n包 和 Crate 在Rust中，包（package）是提供一系列功能的一个或者多个 crate。一个包会包含一个 Cargo.toml 文件，阐述如何去构建这些 crate。\n我们先看一下通过 cargo new 创建一个 my_project 包。\n➜ cargo new my_project Creating binary (application) `my_project` package note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html ➜ rust tree my_project my_project ├── Cargo.toml └── src └── main.rs 2 directories, 2 files 它将创建一个 Cargo.toml文件，内容：\n[package] name = …"

"官方文档将一个模块拆分成多个文件时，介绍的是将原来多个模块写在同一个文件中，拆分成了每个模块一个文件。不过还有一种情况没有提到，如果一个模块中的某个 struct 实现代码过多时，仍写在同一个模块文件的话，维护成本就显的比较高了，这时我们可能还需要对这个 struct 的实现按某种粒度拆分成多个文件来实现。\n✗ tree . ├── main.rs ├── model │ ├── article.rs // 文章相关 │ └── user.rs // 用户相关 └── model.rs 这里是按官方教程拆分后的样子\narticle.rs 是文件模块相关实现 - user.rs 是与用户相关的实现 model.rs 公开模块 model.rs // src/model.rs pub mod article; pub mod user; pub 关键字表示该模块是公开的，可以被其他模块访问。\nmod article 声明了一个名为 article 的模块，并且 Rust 编译器会在同文件名的目录下( src/model/ )找到一个名为 article.rs …"

"今天收到一个项目重构的需求，项目源码使用私有 gitlab 托管平台，但由于考虑安全原因，必须通过vpn软件才可以访问。公司用的vpn客户端是 Pritunl, 看了一下项目主页 https://github.com/pritunl/pritunl-client-electron，发现它是一个 OpenVPN 客户端，是基于Golang+Electron 框架开发的一个跨平台的客户端。\n以前主要接触的是 wireGuard 和 openvpn 这两个项目，这个客户端还是第一次听说。不过后面发现使用这个客户端会经常出现DNS无法解析的情况，不清楚具体是什么原因引起的，因此不推荐这个客户端。另外从性能方面考虑openvpn也不是推荐方案，推荐优先考虑 wireGuard 这个项目，它的客户端也是跨平台的，而且性能要比openvpn好太多，代码也少很好，无论维护和开发成本都要低的多。个人有很长一段时间一直用wireGuard作为内网穿透方案，不过此方案需要一个公网IP地址，所以后期换成了更节约成本的解决方案，当然这是另一个话题了，不是本文要介绍的内容。\n遇到问题 当在macOS上安装好客户端 …"