AI 领域真是风头正劲，各种概念扑面而来，像 AGI, RAG, AI Agent, Agentic AI 等，目前的 MCP(Model Context Protocol, 模型上下文协议) 又随处可见。MCP 是 Anthropic 于 2024 年 11 月底推出的一种开放标准，旨在统一大模型与外部数据源和工具之间的通信协议。MCP 使用 LLM 应用能安全的访问和操作外部资源，轻松的实现了 Function Calling 的功能。
试想一下，以前问大语言模型一个复杂一点的计算题12345 的 6.7 次方是多少？
光语言模型只会在自己的向量数据库里找简单的碰到过的计算题，如 100 的 2 次方，但看到偏门的计算就会出现幻觉了，因为它没有实际的计算引擎。下面是在 LM Studio 中使用 qwen2.5-7b-instruct-mlx 模型时的结果 Read More
昨天单列了 Java 17 新特性之密封类型, 继续刷 What's New in JDK 17 - New Features and Enhancements.switch 模式匹配(预览)
在 Java 21 才正式放出，主动就是原来的 switch...case 语句可以写成表达式的方式，有返回值, 无需每个分支的 break, 并增加模式匹配功能，比如匹配类型，带约束子条件，匹配 record 的字段值等，这里不展开说明，待到详细了解 Java 21 新特性时再深入研究。新的 macOS 渲染管道
英文是 New macOS Rendering Pipeline, 主要是 Swing API 如果配置系统属性-Dsun.java2d.meta=true就可以用 Apple Metal 替代 OpenGL 加速渲染界面，很少写 Java Swing 桌面应用的略过。新的 API 可访问大图标
同样是在对 Swing 的改进，可用 FileSystemView 加载解析度的图标 Read More- 工作中所有项目都已升级到了当前的 LTS 版 Java 21, 眼看 Java 快要来到了下一个 LTS 版本 - Java 25，将于今年 9 月份发布。四年前记录过一篇 Java 10 ~ 16 一路向前冲(新特性一箩筐)，其中夹杂着孵化，预览中的以及正式的特性。现在继续跟随着 Java 16 之后版本的特性，主要讲述正式的，可直观体验到的特性，孵化与预览中的特性只会简单提及。
先还是看下 Java 的发布日期安排 Oracle Java SE Support Roadmap版本 发布日 原定支持至 延期支持至
也就是每两年(9月份)会有一个 LTS 版本，中间若干过度版本。在正式项目中尽可能只用 LTS 版本，因为 LTS 版更稳定，且有长期的补丁，不能项目进行中不得不在进行非 LTS 主版本升级。 Read More
Java 17(LTS) 2021/9 2026/9 2029/12
Java 18-20 2022/3 - 2023/3 2022/9 - 2023/9 N/A
Java 21(LTS) 2023/9 2028/9 2031/9
Java 22 2024/3 2024/9 N/A
Java 23 2024/9 2025/3 N/A
Java 24 2025/3 2025/9 N/A
Java 25(LTS) 2025/9 2030/9 2033/9 
SpringBoot Web 项目要支持响应数据的自动压缩只需要在application.properties中配置server.compression.enabled=true即可，默认为 false. 这样对于默认server.compression.min-response-size=2KB达到 2KB 大小的响应，并且请求头中有Accept-Encoding: gzip或deflate就会压缩响应数据。
相关的配置请参考：SpringBoot Server Properties- server.compression.enabled: 默认为 false
- server.compression.excluded-user-agents: 针对哪些 user-agents(逗号分隔) 不压缩，默认为空
- server.compression.mime-types: 会对哪些响应的 content-type 进行压缩，默认为 text/html, text/xml, text/plain, text/css, text/javascript, application/javascript, application/json, application/xml
- server.compression.min-response-size: 默认为 2KB
文本数据压缩比可达到百分之七八十，对于节约网络消耗来说是非常可关的，不过要些许 CPU 资源。说完了响应的自动压缩，如果请求数据较大也应考虑对请求进行压缩。比如客户端发送请求时带上Content-Encoding:gzip, 并且请求内容是 gzip 压缩的。
提示：如果 SpringBoot Web 是放在 AWS API Gateway 后端，那么 AWS API Gateway 会在看到请求头 Content-Encoding 的值为 gzip, compress, deflate, 或 br, 会自动解压缩请求数据，然后转发解压缩后的数据到后端，这时候 SpringBoot Web 无需进行请求数据的解压处理。不过对响应数据的压缩是 SpringBoot Web 要做的，AWS API Gateway 并无该功能。
SpringBoot 默认不支持自动解压缩请求内容，如果手动在 Controller 方法中，可以接收字节数组，然后自行解压缩。比如定义如下的 Controller 方法 Read More
前面整一篇只讲了 Python 3.11 的新语法特性，异常组与except*, 这篇说其他的。可为异常添加备注
在 BaseException 上新加了一个实例方法 add_note(self, note)，在捕获到异常后可进一步润色而无需创建一个新的异常再次抛出。内置 tomllib 支持 TOML 配置文件
TOML 是 Tom's Obvious Minimal Language, 像 INI 文件，但表述性更强，支持丰富的数据类型。现代新型的 Python 项目依赖管理构建工具都使用了 pyproject.toml 文件，如 Poetry, uv, 以及 PDM。pyproject.toml 在 Python 3.6 就引入了，见 PEF 518，但似乎一直被顽固的 Python -m venv 忽略。
从 Python 3.11 开始新加了对 TOML 配置文件的编程接口，像使用 JSON 和 Pickle 一样的 load() 和 loads() 反序列方法，没有序列化方法 Read More- 还是在三年前记录的 Python 3.10 关键新特性，一晃 Python 3.13 都出来了。Python 遵循着主版本每 12 个一更新，并提供 5 年支持的节奏。所以自 Python 3.10 于 2021 年 10 月发布以来，又有了 3.11, 3.12, 3.13，还得紧紧跟一跟，踏实的了解每个版本新特性，总由着 AI 帮忙恐难得到自己想要的最优代码。学习必要实践，不然在 Google 或是 ChatGPT 中一问 "Python 3.11 key new features", 到的结果无疑是漂亮的，但只粗略一读，并无半点体会。
学习 Python 3.11 新特性的入口是官方的 What's New In Python 3.11. 同时结合 Google 的相关资料，拣些确实对自己有大益处的学。
官方说的 Python 3.11 比 Python 3.10 要快个 10-60% 估计不是我们升级 Python 的主要动力，一般来说语言或组件能升级的话尽量跟着形势跑，不然越是滞后便越难升级，最终只能原地等死。 Read More 
前一篇 尝试 FastAPI WebSocket 写简单的聊天应用 刚体验了 WebSocket, HTTP 可以共用下层的 TCP 连接保持网页与服务器的双向连接。先简单作个回顾，也是为了解释后面关于 Nginx 反向代理 WebSocket 作准备，比如说下面的 WebSocket 服务ws://localhost:8000/ws
当在浏览器中用 JavaScriptvar ws = new WebSocket("ws://test.exmple.com:8080/ws");
后，浏览器首先会发送一个 GET /ws 的 HTTP 请求，如下(不相关的 HTTP 头省去) Read More
来到稍微复杂一点的流程，虽说 DAG 不能有循环但分支还是可以有的。比如下面的分支流程start >> [task1, task2] >> end
在 Airflow UI 中展示出来就是
Airflow 默认下游 Task 的 trigger_rule是all_success, 即要求上游的所有 Task 都必须成功才会执行，否则跟随着失败或跳过，这对于并行处理然后汇集结果的应用是合理的。
本文将要使用到的是分支(BranchPythonOperator), 比如共用一个 DAG, 周中与周末执行不同的分支，或根据条件从不同的数据源采集数据，下流的任务则需在任何一个分支成功即可触发。对上面的流程加上辅助任务，使其表达性更强 Read More
使用 Tomcat 时应根据服务器的负载和客户端能接受的等待情可适当的调节 maxThreads, acceptCount, maxConnections 的值。这三个参数只有 maxThreads 是最容易理解，即 Tomcat 当前最大同时处理请求的数目，其他两个参数有些模糊。而搜索网络相关的解释发现一些相互矛盾的地方，本文将通过调整这几个值，实际体验它们对请求连接的影响。
在测试之前，先看看 Tomcat 官网的解释，你可能不信 AI 的胡说八道，官网仍然是最可信的。在关于 The HTTP Connector 一章中，找到它们三者之间的说明原文是Each incoming, non-asynchronous request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the
用 Google 翻译后 Read MoremaxThreadsattribute). If still more simultaneous requests are received, Tomcat will accept new connections until the current number of connections reachesmaxConnections. Connections are queued inside the server socket created by the Connector until a thread becomes available to process the connection. OncemaxConnectionshas been reached the operating system will queue further connections. The size of the operating system provided connection queue may be controlled by theacceptCountattribute. If the operating system queue fills, further connection requests may be refused or may time out.
