缩减Python应用的镜像体积
背景
当你为 LLM 应用构建镜像时，发现整个过程很慢，一看镜像体积：好家伙，1.76 G！
能不能减少镜像体积，缩短打包时间啊？本文将分享两招实用的技巧，让 Python 应用的镜像体积减少 50%。
大约 2 分钟
Docker 构建镜像、推送、启动实用脚本
misc
存储多份 docker 认证信息：
mkdir "~/.project1"
mkdir "~/.project2"
docker --config ~/.project1 login registry.example.com -u <username> -p <deploy_token>
docker --config ~/.project2 login registry.example.com -u <username> -p <deploy_token>
大约 1 分钟
使用 pytest 为LLM应用添加回归测试
回归测试的必要性
基于 LLM 的 Chat 应用大量依赖了 Prompt Engineering，而用户的输入又千奇百怪，调整了 Prompt 模板，很可能会有意想不到的效果：满足了新需求，却破坏了旧功能。
因此，LLM应用比任何时候都需要回归测试，确保在迭代过程中，不破坏旧功能、不让已修复的bug复现。
而回归测试，当然是自动化执行效率才高。本文交分享如何使用 pytest 对 LLM 应用进行自动化的回归测试。
大约 3 分钟
给LLM应用添加日志
logging替代print
目前公司的LLM应用开发使用的是 Python 技术栈，观察源码，发现没有多少日志，纵使有，也是用的 print。
print 的作用，就相当于 Java 的 System.out.print，相当于 Node.js 的 console.log，一般只适合在本地调试，不适合作为日志输出的。
大约 3 分钟
生产教训：测试环境要与生产环境一致
事件还原
业务流程：
- app-a 上传文件
- app-b 下载文件后使用文件
其他信息：
- 开发、测试环境使用 MinIO
- 生产环境使用 Amazon S3
问题：
- app-a 上传文件成功
- app-b 使用文件报错
逐步分析定位问题：
- app-a 与 app-b 配置是否一致？——确认都是使用 S3
- S3 是否正确配置？有没权限问题？——确认配置正确，没有权限问题
- app-a 是否真的上传成功？——确认文件已在 S3
- app-b 是否下载成功？——根据日志，判断下载失败，得到的信息是：文件不存在。
大约 2 分钟
避免密码明文传输
说明
密码加密是很常见的安全性需求，但由于涉及前后端，前后端分离的情况下，开发人员容易只关心自己熟悉的领域，最终导致“知道要加密，实际还是没明文”的情况发生。
本文分享实际可运行的前后端代码，以减轻大家实现密码密文传输的负担。
流程说明：前端加密，后端解密。
当然，数据库存储的肯定是密文。这里后端解密的意思是：需要使用密码的时候，如获取数据库的连接，由后端解密后使用。
大约 2 分钟
检查名字是否重复
检查名字是否重复是很常用的业务需求，本文推荐一种更省心、更少bug的做法。
大约 1 分钟
复制代码也许不是罪
前言
熟悉我的人都知道，我对代码是有追求的。
正式参加工作后，我就知道，复制粘贴是坏的实践，自己一直极力避免做这样的事。要是遇到了别人复制粘贴，要么喷，要么自己改。
我早期认为：复制代码就是菜。
后来认为：复制代码可能不是菜，而是懒，没有素养，自我要求。
而现在：代码其实也没那么重要；某些情况下复制粘贴是可以接受的。
编码经过七个年头，我思想上为何会有如此改变？难道这就是传说中的七年之痒?
大约 2 分钟
技术点评：别每张表都加tenant_id
前言
系统满足多租户需求，是很常见的场景。本文主要聊一下在维护旧系统过程中，发现的前人多租户方案中设计、实现不合理的地方。
大约 3 分钟
使用 Postman 进行 API 测试
前言
虽然之前分享过 RestAssured 进行接口测试的教程，但实践起来，会有阻碍：研发同学还是对 Postman 更熟悉，更倾向于使用 Postman 调试接口，而不是写 Java 代码对 Controller 层进行测试。
而笔者在针对旧的 Java 项目添加接口测试时，又遇到了另一个问题：那就是由于模块依赖，进行接口测试时，还在把旧的测试代码一并带上。虽然说有办法解决，但究竟是麻烦不断。
还有就是，Java 的类型检查，在写接口测试时十分束缚手脚。如下述代码：
大约 6 分钟
...