使用 Nginx 反向代理钉钉接口

借助 Nginx 的反向代理能力，在不修改代码的前提下，使内网应用可以通过前置机访问钉钉接口。

通过RAG外挂知识库提升大语言模型的个性化能力

本文将列举几种对大语言模型进行个性化的方法，简单说明使用检索增强生成技术（RAG）外挂知识库的基本原理，最后介绍 AnythingLLM 这款高度集成且易于使用的软件。阅读本文后，如果你的应用场景恰好幸运的避开该软件现阶段存在的一些缺点，那么恭喜你将能得到一个私人定制的人工智能助手。

本地模型选择

总结一些在本地模型选择上的经验，在语言、领域、参数、评分、微调、量化等方面进行展开介绍。

在本地运行大语言模型

本文将介绍一种适合非技术人员的，在个人电脑上运行大语言模型的方法

Python 代理设置

通过环境变量或Python代码为Python程序设置代理，解决 Socks5 代理在请求 https 资源时失效的问题

Quasar中的前端代码转译

使用 Quasar 时，如何完成浏览器兼容性的配置。 制定兼容范围 在进行实际配置前，首先必须确定要支持浏览器的版本，而确定浏览器版本则需要先明确业务对象的情况。 为什么不干脆把标准定的越高越好呢？比如支持100%的用户。这是因为支持率越高，可用的新语法越少，意味着更多的转译代码和 polyfill，这会带来额外的代码量，从而导致下载数据量增加，以及运行速度变慢的问题，为了0.01%影响99.99%用户的体验并增加他们的流量开销，是否合适呢？这就需要根据实际业务进行取舍和平衡。 比如我们的业务对象既有企业用户，也有公众用户，企业用户主要使用钉钉，并可对其PC浏览器进行要求，而公众用户主要使用微信。 确定常用浏览器版本 PC浏览器可以指定，那么对浏览器版本就不需要过多考虑，但是部分客户还有XP系统，那么也就确定了 Chrome 浏览内核的版本不可以超过 49； 微信用户可能在手机登录，也可能在PC登录，而PC中的微信内置是QQ浏览器9，其内核版本是 Chrome 53; 电脑端的钉钉内置浏览器已经是 Chrome 91； 手机端的话考虑到安卓手机使

浏览器中误用Node.JS模块导致编译结果体积膨胀

以 jsonwebtoken 库为例说明在前端随意使用 Node.js 的库可能带来的问题。

合理缓存SPA应用

通过合理设置缓存级别，将不同的缓存策略应用到正确的文件上提高系统性能。

PostGraphile实战-序

两年前(2018年)，在使用 PostGrahphile 一段时间后，打算总结自己在实践中的经验，于是陆续用数周闲暇时间，写了 《PostGrahphile入门》 一文。止于2019年4月18日，完成了预计的7个章节中的前5部分，今年想要继续时，发现其中多处已跟不上最新的发展，而自己的认识也已更进一步。遂计划重来一版，先将原有部分翻新，再补上缺失的后两章。用每周更新的博客形式呈现，初步估计需要3个月左右。如果顺利，再花2-3周做成完整的电子书，最后定期迭代，使其紧跟技术更迭和个人认识的发展。 大框架暂与之前相同，不排除按需扩展。 1. 概述 2. 技术背景 3. 项目准备 4. 联机版——PostGrahphile的基本使用 5. 多用户——注册与登录 6. 多用户——访问控制、权限与隐藏 7.

服务器部署的决策与实践（4） 环境部署实践

一套环境通常不会只部署一遍，你会遇到各种需要重复部署环境的情况：也许是一个项目需要多台服务器来运行；也许是同时需要管理多个项目；也许是需要生产环境和开发、测试环境的一致性。总之，掌握高效的方法和工具是非常必要的。 这周我来讲讲自己在服务器环境部署上经历的四个阶段，以及选择背后的原因。 本文是 服务器部署的决策与实践 系列的一部分。 第一阶段 在最初的阶段，我还完全是个新手，对服务器管理的技巧和相关软件配置的方法都还在逐步深入了解的过程中，需要许多摸索和尝试，说是跌跌撞撞才部署完一台服务器也不为过。等到一段时间后，又要一台相同环境的服务器时，早忘了上次是怎么做的。先勉强凭着记忆把关键的步骤给走下来，却总是难免遗漏几处配置，有时甚至应用运行到一半报错了，才能发现少了必要的组件，通过一系列修补才终于把新服务器搞定。最痛苦的是明明记得要做某个步骤，却想不起细节，隐约记得是在一个什么网站上看到过，又无论如何翻找不到。 第二阶段 经过上个阶段的磨炼，对常用软件的安装和配置已有心得，无谓的尝试也逐渐减少。而且也学聪明了，安装的过程会写个简单的文档记录下来，下次照做错漏自然

服务器部署的决策与实践（1）服务器操作系统的选择

CentOS 8 生命周期的突然缩短，让我再次面对服务器操作系统的选择。 如果你使用一个公司的产品，但不向他付钱，那么你就只是用户，而非客户。网游行业的从业经验又告诉我，不付钱的用户是产品的一部分。 Red Hat 决定将 CentOS 8 的支持周期将从原来预计的 2029 年缩短到 2021 年年底，并劝大家都去用 CentOS Stream，或者买他们家的商业服务，就是一个很好的例证。原来的 CentOS 用户，现在要么选择成为 Red Hat 的编外测试人员，为他们的商业客户提供价值，要么选择成为“氪金玩家”。 商业行为毕竟不是慈善事业，我们没啥好说的，只是又到了做选择的时间。 本文是 服务器部署的决策与实践 系列的一部分。 首先，最容易的就是交钱，当然，在技术上也没啥好讨论。 你也可以选择 CentOS Stream ，但它是个滚动更新的发行版，官方也不推荐用于生产服务器。

读《程序员修炼之道》

久仰其大名，今年第二版面市，终于买来一本，五百页，断断续续三个月读完。 本书推崇的核心理念被简称“ETC” —— Easier to change ——即软件从设计到编码，首先要考虑“容易变更”，作者云全书其他方法皆是此原则的特例。在我看来其观点与《简约之美》异曲同工，后者写成一本书，只为教给读者一个“常识”，就是软件项目想持续成功，唯一重要的就是“降低维护成本”，至于如何实现，草草带过了，毕竟全书正文不足百页。现在看来，答案自然就是“容易变更”。 这一对比，更凸显《程序员修炼之道》的特点——“务实”。全书给出整整 100 个“提示”，供读者参考。若与读者日常工作方法直接对比，确实能揭示不足，指明提高的方向。其中部分是我日常已有感受，却无法言明的，一旦点破有豁然开朗之感；另有部分是针对一个问题，已经想过几条路可试，却没来得及逐一实践去验证各自优劣的，作者直接给你摊开了一一剖析，读后亦有收获。