Github

gemini3 发布几天了。都说很叼，前端很叼，画页面很牛。那就帮我画个工具箱吧 设计 于是打开 chatgpt 和他讨论一下，主要思想就是我希望前端能够非常的模块化 写一个工具的时候，不需要关注太多和我网页的配合。按照一定的规范写完工具后放在指定位置就行了。基于 git 我就可以审核后发布，前端就可以在某个目录某个地方看到这个工具，搜到这个工具。暂时不考虑性能问题 gemini3 目前我两个用的地方，一个在 ai studio 里面直接用，另一个就是在 cursor 里面用了，姑且信一把 cursor 开搓 接一杯水的功夫出来了。这个设计很符合我的概念（但是我本能的觉得性能影响很大，以后堆积越来越多的工具，一打开我的网站，啪的一下要下载好几十MB 的内容。） 编译预览一下，这期间有一点小问题，反正我也不是很懂前端，他给修好了 随后上点强度，一口气提了 9 个比较常见的网页工具，一次性完成。 可以，很满意哦，回头做个深色浅色模式随系统切换 部署 那么想把它部署起来，在这整个工具箱的设计里，是存在后端的，因为对于我的需求而言 有一些工具我是希望他有历史记录的，当然量不是很大。所以一开始我是想部署在自己的 VPS 上。但是想了一圈后犯懒了（原本想基于 github 的 webhook 或者 actions build & push docker images，服务器搞个小 deploy agent 等着更新就行）有 github pages，不如直接放在 pages 里就好了 叫 g 老师给写个 actions 关于 actions 的文档和介绍 GitHub Actions 入门教程 - 阮一峰的网络日志 GitHub Actions 文档 - GitHub 文档 因为我的仓库内有前后端的代码。所以 working-directory 指定 frontend ...

阿里云 ubuntu 服务器 * 1 windows 11 家里电脑 * 1 有开发环境在家里电脑。需要在公司调用，简单搭一个 在ubuntu上部署frps（服务端） 查看 github 最新的 release 版本 下载 1 2 3 wget https://github.com/fatedier/frp/releases/download/vX.Y.Z/frp_X.Y.Z_linux_amd64.tar.gz tar zxvf frp_X.Y.Z_linux_amd64.tar.gz cd frp_X.Y.Z_linux_amd64 我的阿里云下不了 github.不知道啥情况。换个命令 wget https://sourceforge.net/projects/frp.mirror/files/v0.64.0/frp_0.64.0_linux_amd64.tar.gz/download -O frp_0.64.0_linux_amd64.tar.gz 下载后解压 配置 frps.toml 调整端口和 token 防火墙放开对应端口 服务器或者云服务安全组 配成系统服务(可选) 不做演示。 windows 安装 frpc 我去 拦在第一步。说release 的 exe 有问题。自己编译的比较靠谱是吧 安装 go 环境。自己编译出 frpc 客户端 启动后可以看到 配置改成下面的足够了 显示已折叠代码（19 行） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [common] server_addr = XXXX server_port = 7000 token = "XXX" # 比如映射一个本地 web 服务（假设端口 8080） [[proxies-lout]] name = "proxies-lout" type = tcp local_ip = "127.0.0.1" local_port = 8080 remote_port = 8080 [[proxies-ai]] name = "proxies-ai" type = tcp local_ip = "127.0.0.1" local_port = 8081 remote_port = 8081 写了个 start.bat ...

使用 Git 的 amend 功能，将未保存的文件修改后“补充”到你刚刚的那次提交中，而不会增加新的提交记录。 ✅ 1. 保存你漏掉的那个文件 先确保你已经保存了那个文件的最新修改。 ✅ 2. 添加这个文件到暂存区 1 git add path/to/your/file ✅ 3. 使用 –amend 修改上一次提交 1 git commit --amend --no-edit –no-edit 表示不更改上一次的提交说明。 如果你想修改提交说明，可以去掉 –no-edit，然后在打开的编辑器里改。 ✅ 4. 如果已经推送到远程仓库（GitHub 等） 如果你 已经推送过 这次提交，需要强推（⚠️ 要小心）： 1 git push --force

前几天给同事分享文档的时候一直在用 语雀啥的。突然想到，如果要维护一个像 vue 或者vite 那一类的文档给用户看该怎么快速搭建的。理应有前辈完成这种工作。让 grok 搜了一下。顺便解惑原来对于 wiki doc 等的认识，有兴趣的小伙伴们自己搜搜，我这里就不贴 grok 的长篇大论了 总之找到了 vite press。确实是曾经认识过它（好像是在鱼皮那里） 那么这篇博客就记录一下搭建过程（跟官方文档一致）Getting Started | VitePress 首先准备 node 环境。因为最近在开发 mcp 应用。所以心血来潮用了 bun 1 2 3 bun add -D vitepress bun vitepress init 随后会有一次互动式的初始化 显示已折叠代码（30 行） 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 ┌ Welcome to VitePress! │ ◇ Where should VitePress initialize the config? │ ./docs │ ◇ Where should VitePress look for your markdown files? │ ./docs │ ◇ Site title: │ My Awesome Project │ ◇ Site description: │ A VitePress Site │ ◇ Theme: │ Default Theme │ ◇ Use TypeScript for config and theme files? │ Yes │ ◇ Add VitePress npm scripts to package.json? │ Yes │ ◇ Add a prefix for VitePress npm scripts? │ Yes │ ◇ Prefix for VitePress npm scripts: │ docs │ └ Done! Now run pnpm run docs:dev and start writing. 这里对于初始化的目录结构会对后面有一定的影响。由于我是使用的./作为默认目录，也可以在已有的项目中构建 docs 目录跟项目结合在一起 ...