Open Source

什么是 Vibe Coding？ Vibe Coding（氛围编程）是指完全信任 AI，不自己写代码，只通过自然语言描述需求，让 AI 完成所有编程工作。这种方式最近在开发者社区引发了广泛讨论。 我想做一个实验：完全不使用手工代码，能否完成一个可用的 Web 应用？ Remote File Editor 是什么？ 一个轻量级的 Web IDE，VS Code 风格，功能包括代码编辑、文件管理、图片查看和终端面板。 为什么做这个项目？ 我最初的需求很简单：方便查看和修改 OpenClaw 的配置文件和工作目录。 作为一个经常在不同 VPS 之间切换的开发者，我需要一种方式来： 快速浏览和编辑服务器上的文件 不需要每次都用 vim/nano 登录 SSH 有一个可视化的界面 但我不想花太多时间从头构建一个完整项目——这正好是测试 Vibe Coding 的完美场景。 100% AI 生成的体验 技术栈 前端：React + TypeScript + Vite + Monaco Editor 后端：Node.js + Express + JWT 认证 部署：支持 systemd 和 PM2 AI 生成的内容 整个项目从设计到实现，几乎每一行代码都是 AI 生成的： 架构设计 - 描述需求，AI 给出技术方案 前端代码 - React 组件、状态管理、样式 后端 API - Express 路由、文件操作、JWT 部署配置 - Nginx 反向代理、systemd 服务 遇到的问题 当然不是一帆风顺的： ...

Directus APP使用VUE 3， Typescript，用Vite构建。 本文记录在评估Directus APP过程中了解到的前端相关知识。 1. vite 构建工具，类似webpack。 1.1. 原理 使用了浏览器的ES6模块加载功能，所以前端可以按需加载JS模块。开发过程中不需要打包了。 <script type="module" src="./foo.js"></script> 以上 module类型加载的 foo.js 中可以再import其它的模块，也可以export。浏览器认识js中的import和export命令，会按需向后台发请求加载。 1.2. 应用 在vite.config.ts中配置开发服务器，例如下面监听8080端口，API请求发送到8055端口。 server: { port: 8080, proxy: { '^/(?!admin)': { target: process.env.API_URL ? process.env.API_URL : 'http://localhost:8055/', changeOrigin: true, }, }, fs: { allow: [searchForWorkspaceRoot(process.cwd()), '/admin/'], }, }, 2. VUE 把js/css/html组织起来的方式。 运行环境（js库）提供数据绑定，改状态就会更新显示，方便JS更新页面。 2.1. 基本概念 data 一个函数，返回组件实例的数据对象。 props 一个数组，或者对象。是父组件调用此组件时候的可配置参数。 data和props都可以在template中访问，区别是 data不是通过父组件传递的，是子组件私有的，是可读可写的。 props中的数据，都是通过父组件传递给子组件的，是只读的。 data存储组件的状态， 没有data的组件就是无状态组件。 mixin， 为了DRY，为了减少重复，把组建脚本部分相同的地方（data，props,method…)抽离出来，单独放到一个对象里面。 然后在组件中mixin进去。 setup函数， 用来替代mixin，实现Composition API。 其输入为props, context，输出是一个对象。对象的所有属性都可以在组件中访问。 2.2. 组件生命周期 ...

1. Collection 一个Collection对应数据库的一张表。directus的collection里面有一些独有的概念，例如alias域， sort属性等。 1.1. alias Fields that do not map directly to an actual database column are called “alias” fields. For example, presentation fields (such as dividers and groups) and certain relational types that display data stored elsewhere (such as One-to-Many (O2M) and Many-to-Many (M2M)). O2M, M2M, M2A 等，都不会在表里面有实际的列。称其为alias域。 alias虽然在实际数据库表里面没有列，但是在direct_fields表里面有记录。例如上面pages集合的element域，是m2a类型的alias。 direct_collections表里面描述系统所有受directus管理的表，direct_fields里面描述所有表的所有属性。 通过这种非侵入的方式， 数据库中原有的表结构可以不做改动。 1.2. sort 属性 如果collection建立时候，选择了支持sort，表里面就会多一个sort列。 这一列的作用是支持在app上手工拖拽的方式调整记录的顺序。 原理很简单，表里面加了一个number类型的sort列， 当拖拽的时候，会导致该列的值根据记录的位置产生变动。 1.3. share APP的一个功能， 可以把模型中的一个记录生成一个链接，发送给其它人只读访问。 可以设置密码，有效期，以哪一个身份读取等。 ...

1. 起因 在配置Directus使用钉钉扫码登录时候，发现钉钉的免密登录（OAuth 2）和RFC规范不一致。 需要做协议转换后才能和Directus正常通信。 需求比较小众，没有现成的软件，只好自己动手了。 2. 主要功能 能作为API通信的中间人， 转发客户端和API服务器之间的通信， 记录LOG，方便分析协议； 作为中间人，能修改请求的内容， 修改响应的内容；可以做协议适配，转换。 APIPROXY is a RESTFUL API proxy, monitor and adaptor. Forward RESTFUL API to another host. It’s man in the middle who can monitor and modify the header and body of the API Request & Response. Good for protocol study and adaptation. Features API proxy: forward any incoming API to remote sever and return the response back to client. API monitor: you can get detailed log of the API req and res in the log file. API adpator: modify the request and response on the fly while forwarding, including parameters, body, http headers etc. API mock server: you can add your own API for testing purpose easily. 3. 目前状态 初步实现了对钉钉OAuth2协议的RFC6749兼容封装。 目前Directus已经可以通过它的翻译支持钉钉免密登录。 ...

Directus本身是NodeJS实现的API服务器。 其能支持多大的TPS取决于数据库系统，API查询设计等多个因素。本文提供一些架构上的考虑，目的是使得Directus应用能随着业务的增长，通过增加硬件等方式，同步提高系统处理能力，在性能上具有好的扩展性。 1. 如何规划可扩展的Directus应用 Directus 对于高负载情况的处理有以下两个关注点： 横向扩展应用服务器（directus实例多部署几个） 数据库服务器采用高性能方案，例如Amazon Aurora或者CockroachDB Rijk van Zanten: That being said, I do highly recommend horizontally scaling your Directus instance if you’re planning on running it at scale. Make sure you use Redis for caches / rate limiter, and S3 or another shared file storage for the file storage. At that point, the bottleneck will become the amount of allowed connections and the overall server performance of the database. That being said, there’s a lot of database services nowadays that scale virtually endless, like Amazon Aurora or CockroachDB. ...

1. 项目简介 这个小项目预期结果是让 Directus 支持使用钉钉账号来登录。 在了解OAuth2协议后(参见上一篇blog，参考资料1），已经有足够知识储备来实施。 Directus 原生支持使用GitHub登录， 所以，解决思路是先从GitHub入手。按下面步骤进行： 配置Directus使用GitHub账号登录，熟悉Directus对OAuth的标准支持功能 配置Directus使用钉钉账号登录，由于钉钉的协议实现和RFC6749/GitHub有不同，这里有可能需要见招拆招 上线Directus到服务器环境，在钉钉的PC版和手机版验证 2. 环境配置 在本地用ngrok暴漏出一个服务，来接受OAuth服务器的redirect。 ngrok http 8055 得到 https://445a-240e-47c-30b0-3b10-600e-ea25-cde5-2334.ngrok.io/ 作为外网域名来访问本机8055端口的directus。 3. Directus 使用 GitHub账号登录 按参考资料2中配置参数。以下配置中，对每一个新的GitHub授权用户，Directus在登录过程中会使用用户email自动创建一个Directus用户，并且将其角色赋值为AUTH_GITHUB_DEFAULT_ROLE_ID。 A A A A A A A A A A # # U U U U U U U U U U T T T T T T T T T T A A H H H H H H H H H H U U _ _ _ _ _ _ _ _ _ _ T T P G G G G G G G G G H H R I I I I I I I I I _ _ O T T T T T T T T T G G V H H H H H H H H H I I I U U U U U U U U U T T D B B B B B B B B B H H E _ _ _ _ _ _ _ _ _ U U R D C C A A P A D I B B S R L L U C R L E C _ _ = I I I T C O L F O E I " V E E H E F O A N M D g E N N O S I W U = A E i R T T R S L _ L " I N t = _ _ I _ E P T g L T h " I S Z U _ U _ i _ I u o D E E R U B R t K F b a = C _ L R L O h E I " u " R U = L I L u Y E t 7 E R " = C E b = R h e T L h " _ _ " " _ 2 . = = t h R I e K " . " " t t E D m E . d h p t G = a Y . 5 t s p I " i = a . t : s S 0 l " e . p / : T f " e " . s / / R 5 m . : g / A f a . i a T 1 i . t p I b l . g h i O 5 " d i u . N a 9 t b g = - " h . i " 1 u c t t 0 b o h r 6 . m u u f c b e - l . " 4 m c e g o c l i m 7 o n - g u a i o s 8 n a e b / u r 8 o t " - a h 6 u / f t a 1 h c 1 / c 4 a e 8 u s 2 t s a h _ 0 o t 6 r o 0 i k f z e " e n " " 重启Directus让配置生效后，可以看到登录界面的GitHub选项。 ...

1. 原理 假设有一个APP，要我使用GitHub授权登录。 在这个登录场景中： 我作为数据的所有者告诉系统（GitHub），同意授权第三方应用（App）进入系统，获取某些数据（我的ID，头像等）。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用（APP）访问数据使用。 token是短期有效的，我可以随时通过GitHub把这个Token注销，从而使得APP不再能访问我的ID/头像等信息。 这里面有四个角色：用户，应用，系统，资源。 用户是资源所有者，应用是资源的使用者，系统是资源管理者。 现实生活中， 应用和系统各自有一个实例， 用户有多个实例。 应用和系统之间通过OAuth2协议通信。 用户在通信过程中参与（授权）。 把上面时序图对应到一个生活中的场景，业主授权快递公司出入小区送快递： Client Req Auth： 顺丰快递员打电话给业主，有你的快递，得送进去，给办个出入证吧 Resource Owner Grant Auth： 业主联系小区物业， 我是业主，这是我的证明，我允许顺丰最近两天可以进小区物业给我送快递 小区物业告诉业主，OK，你让顺丰联系我拿临时出入证，就说3号楼201房间，授权码：核酸检测利国利民 Client Sends Auth Grant 快递公司联系小区物业说，我是顺丰，这是我的证明，需要给3号楼201房间送快递，业主的授权码是核酸检测利国利民 Auth Server Sends Access Token 小区物业说好，授权码没问题，这个是临时出入证，两天有效。 Clients Sends Access Token 快递员用临时出入证开小区大门 Protected Resoure sends resource 快递员进入小区 注意： 第二步，业主联系物业时候， 要证明自己的确是业主（用小区app登录） 第三步，顺丰联系物业时候，需要证明自己的确是顺丰（报小区物业预先给顺丰分配的client_secret让物业核对). 物业还要检查3号楼201业主的确允许了（通过查授权码）。 如果快递员直接到小区门卫那里说 “核酸检测利国利民”，是没有作用的。“核酸检测利国利民”承载的信息是3号楼201业主允许顺丰在2天内进小区。 快递员给门卫报这个授权码没用，门卫只认出入证。再说，门卫也不知道快递员是不是顺丰的啊。这个授权码只有在快递公司把它换成临时出入证后才可以进小区。 换临时出入证需要验证顺丰的身份。“核酸检测利国利民”承载的信息是可以公开的，其它人听到了也不会有安全风险，因为其他人没有顺丰在物业处注册得到的client_secret, 没办法用授权码换临时出入证。 临时出入证需要妥善保管，任何人拿着都能进小区了。 OAuth2的过程是当有快递时候，业主授权小区物业给快递公司分配临时出入证，在一定的时间内可以出入小区。在同一时间，会存在很多个不同业主授权的有效临时出入证，但一个业主对一家快递公司，在同一时间只有一个有效临时出入证。 角色间的类比关系如下。 中文术语 时序图中的概念 GitHub授权登录APP场景 业主授权顺丰进小区场景 用户 Resource Owner GitHub用户 业主 应用 Client GitHub OAuth APP 顺丰 系统 Authorization Server GitHub 小区物业 资源 Protected Resource GitHub用户名称，头像 小区内部道路 授权 Authorization Grant code 核酸检测利国利民 令牌 Access Token token 临时出入证 下图出自RFC6750， 实际实现时候，Client是APP， Auth Server/Resource Server在同一个域名后面（GitHub，钉钉，Facebook…)， Resource Owner也是在这个域名下完成授权（Auth Grant）。 ...

1. 引言 开源软件已是信息社会的基石。 GitHub上软件种类众多，市场定位和成熟度也各不相同。 对于成熟的通用软件，例如Linux，NGINX等。将这类软件引入自研项目中不存在太多顾虑，因为通用所以用的人多。可以找到大量的成功案例，众多的开发维护人员。一旦碰到问题，也容易在网上搜到答案。 但还有一类开源软件， 定位相对没有那么通用，虽然其在细分领域已经做的比较好了，但由于生态环境较小，在项目中引入时候，还是有很多因素需要考虑： 现有的开发人员有能力掌握并承接后续开发吗？ 如果使用中出现问题， 有没有合适的开发人员去解决？或者去做二次开发？ 系统上线后，有没有合适的人员去长期维护？ 对这类软件，在引入到项目中前，有两种办法增强信心： 找到合适的人 成为该软件开源社区的一员 2. 找到专家 有如下几个方法。 在软件的开发者中搜索是否有中国开发者，尝试建立联系。 百度该软件相关的讨论区，QQ群等。 加入并倾听，识别出专家。 寻找并参加该软件相关的培训。 寻找GitHub上该软件的相关软件。 例如引用该软件的软件，该软件的Plugin等等。并合作者建立联系。 以上的目的都是在现实世界建立起和专家的联系。 然后通过和专家的电话，邮件，吃饭喝茶等各种交流来进一步了解该软件在国内的生态情况，以及软件的优缺点。 为后续引入打好基础。 和专家建立起联系后， 后续也方便和专家进一步在项目上合作共赢。 3. 融入开源社区 如果国内找不到专家。 就只能撸胳膊上，让自己成为专家了。 3.1. 学习使用 主要看如下几方面的内容： 软件自身的官方文档 Youtube上的介绍视频，以及第三方教程 软件的单元测试 以上，结合大粒度的源码分析，可以掌握软件的大体脉络。 3.2. 和同行讨论 一般开源软件社区有如下几个地方。 GitHub项目Issues GitHub项目Discussions Discord或者Slack等讨论组 Email邮件组 通过加入并查看大家在讨论哪些问题，能了解到软件的一些使用细节和适用场景。 在学习的同时，也要多思考，多提问题， 多回答社区的问题。 回答社区的问题可以针对和自己项目相关的领域问题，积极回答问题有两点好处： 驱动自己认真深入思考，如果我在项目中碰到这个问题，该怎么处理？ 和其它社区用户，以及软件开发维护者们建立联系 以上是 Headless CMS Directus 的项目讨论社区。 我最近在调研用Directus来做API中间件，watch了该项目的讨论区，GitHub会把所有讨论实时发到我一个特定的邮箱里面。 通过查看大家的讨论，有很多收获。我也把自己学到的经验总结提炼出来帮助其它用户， “Most Helpful”榜单排名第5的就是我。 3.3. 小规模MVP验证 在看的基础上，也需要动手做。 按照自己项目的特点，定义一个和该软件相关的最小MVP流程，尝试引入该开源软件实现。 以上三点，相辅相成，可以同步进行。 理想的结果是： 自己变成了专家，后续在项目中引入 研究过程中发现软件不适用，果断放弃

Leo 要停止开发了 早上在邮件列表里面读到EKR的一封信： Leo 6.6 may be the last substantial release in Leo’s history. At present, the 6.6 to-do list contains five items. There are no items at present on the 6.7 to-do list. Many open items remain, but I have little desire to do any of them. Expect 6.6 final in a month or so. The leojs project now seems like the future of Leo. Indeed, it melds Leo with vs code, an unbeatable combination imo. ...