Category: 似水流年
Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable. Cloud native technologies and […]
Life is a pure flame, and we live by an invisible sun within us 生命是一团纯净的火焰, 我们依靠自己内心看不见的太阳而生存 The vast, th unbounded prospect lies before us.
Overview 要与 Spring 一起使用 MyBatis，你至少需要一个 SqlSessionFactory 和一个 mapper 接口。 MyBatis-Spring-Boot-Starter 将会： 自动探测存在的 DataSource 将使用 SqlSessionFactoryBean 创建并注册一个 SqlSessionFactory 的实例，并将探测到的 DataSource 作为数据源 将创建并注册一个从 SqlSessionFactory 中得到的 SqlSessionTemplate 的实例 自动扫描你的 mapper，将它们与 SqlSessionTemplate 相关联，并将它们注册到Spring 的环境（context）中去，这样它们就可以被注入到你的 bean 中 MyBatis-Spring-Boot-Starter 是一个开箱即用的解决方案，用于将 MyBatis 与 Spring Boot 集成。它简化了 MyBatis 的配置和使用，同时充分利用了 Spring 的依赖注入和生命周期管理功能。以下是它的实现原理的详细解析： 自动配置的实现 MyBatis-Spring-Boot-Starter 利用了 Spring Boot 的自动配置机制，通过 @EnableAutoConfiguration 和 spring.factories 文件实现自动化配置。 spring.factories MyBatis-Spring-Boot-Starter […]
在软件开发的江湖中，C/C++ 和 Java 就像少林与武当，一个偏向“硬功夫”，刀枪棍棒样样能打；另一个更讲究“以柔克刚”，推崇灵活多变的内功。而 Python、Go 和 Rust 则是近年崛起的少年高手，一个擅长速成、一个拥抱云原生，还有一个以内存安全闻名，都在争夺编程江湖的“武林盟主”之位。 尤其是在企业开发的武林中，Java 堪称“中原武林盟主”，它的招式（术）浩如烟海，从简单的“打狗棒法”（工具类库）到深奥的“九阴真经”（分布式架构）。门下弟子修炼轮子（第三方库）无数。然而，纵然 Java 的术法浩如烟海，如果只沉迷于术，终究如蜻蜓点水，难入武道真谛。只练招式不修内功，就像拿着绝世神兵却没有力气挥动，最终难逃江湖纷争的淘汰法则。 正如古人所言：“术乃器，道为心。器可换，道难变。” 术是什么？术是刀枪剑戟的武器。 术是工具、框架、库、配置文件。你可以把术看成是你手中的菜刀，某个问题来了，直接拿出来用，快速解决，效率拉满。 比如： • Spring：一个开箱即用的武林秘籍，简直是厨师的多功能锅，煎炒烹炸样样行。 • MyBatis：数据库操作的助力，能让你用 SQL 潇洒如风，甚至可以用 XML 来写代码。 • Spring Security：防盗、防抢、防 SQL 注入三件套。 • WebFlux：响应式编程的“闪电五连鞭”，性能杠杠的。 术学起来很爽，用起来很炫，解决问题很快，但如果你只会用术，可能就像一个拿着高级武器但内功薄弱的武者，风吹草动就可能翻车。 道是什么？道是你的内功心法。 道是一种理念、一种本质，超脱于术之上。它是程序员的大局观，是问题背后的普适法则。懂得了道，你就能从根本上理解术为什么存在、怎么优化甚至怎么重写它。 比如： • 依赖注入和控制反转（IoC） 是道，理解了它，你就能明白 Spring 为何如此设计。 • ORM 的本质 是道，懂了它，你就知道 JPA 和 MyBatis 的优劣。 • CAP 理论 是道，掌握了它，分布式系统中的“妥协艺术”尽在掌握。 • 响应式编程的多路复用原理 是道，搞懂了它，WebFlux […]
陷阱 在 Python 中，类成员在所有实例之间是共享的，例如以下代码，friends 是一个类成员（而不是实例成员），所有 User 实例都会共享同一个 friends 列表。也就是说，对一个实例的 friends 列表进行修改，会影响到其他实例的 friends 列表。 这是因为 friends 是在类定义时定义的，是一个类级别的属性。 示例代码 from datetime import datetime from pydantic import BaseModel class User(BaseModel): id: int name: str = "Walter Fan" signup_ts: datetime | None = None friends: list[int] = [] user1 = User(id=1) user2 = User(id=2) user1.friends.append(2) print(user1.friends) # [2] print(user2.friends) […]
在 C++ 中，“奇异模板”（Curiously Recurring Template Pattern, 简称 CRTP）是一种常用的模板编程技巧，主要用于实现静态多态（static polymorphism）或为派生类提供通用的功能。它的名字来源于其递归的结构：一个类使用自己作为模板参数传递给基类。 CRTP 的基本结构 CRTP 的核心是定义一个基类模板，并让派生类作为模板参数传递给这个基类。 基本代码示例 #include <iostream> // 基类模板 template <typename Derived> class Base { public: void interface() { // 调用派生类的方法 static_cast<Derived*>(this)->implementation(); } // 默认实现（可选） void implementation() { std::cout << "Base implementation\n"; } }; // 派生类 class Derived : public Base<Derived> { public: void implementation() { […]
你有信仰就年轻，疑惑就年老。 有自信就年轻，畏惧就年老。 有希望就年轻，绝望就年老。 岁月刻蚀的不过是你的皮肤， 但如果失去了热忱， 你的灵魂就不再年轻。
在一个 Jupyter Notebook 中引用另一个 Notebook 的 Python 函数或类有以下几种常见方法。选择合适的方法取决于你的需求和项目结构： 方法 1: 使用 import_ipynb 模块 这是专门为导入 Jupyter Notebook 中的代码而设计的方法。 1. 安装 import_ipynb pip install import-ipynb 2. 导入另一个 Notebook 假设有一个 helper_functions.ipynb，你想在当前 Notebook 中使用它的内容。 import import_ipynb import helper_functions # 使用 helper_functions 中定义的函数或类 result = helper_functions.some_function() my_class = helper_functions.SomeClass() 方法 2: 将 Notebook 转换为 Python 文件 将另一个 Notebook 转换为 .py […]
最近重新复习了 Java 这门我曾经非常熟悉的语言 , 翻阅到 Bruce Ekecl 的 ON JAVA 一书, 他在卷首就引用了维根斯坦(Ludwig Wittgenstein)的名言: ‘The limits of my language means the limits of my world.’ 我的语言的局限即我的世界的局限. 作为程序员, 一种语言会悄然无息的引导你进入某种思维模式, 同时远离其他思维模式. 看到这里, 我深有同感, 我现在用的最多的编程语言是 Python , 而 C++ , Java 和 JavaScript 也是我熟知的语言, 我用它们来谋生, 写过许多正式项目和 side project. 在语言之间我也曾经有过好恶, 对 JavaScript 我还写过一篇吐槽的文章 C++程序员眼中丑陋的 JS 可是随着年岁的增长, 我也渐渐领悟到不应局限于语言的边界, 很多编程语言为了解决机器语言的复杂性, 引入了更多的自身的复杂性, 当看到 […]
大模型的“幻象问题”是指它们生成的回答可能看起来合理但实际上错误或虚构的现象，也被称为“AI 幻觉” (AI hallucination)。这种问题的根源在于大模型是概率生成模型，缺乏对事实的真正理解或对内容的验证能力。以下是一些可能的解决策略： 1. 提供高质量的上下文 大模型的输出质量高度依赖输入内容。如果输入信息模糊或不完整，模型容易生成虚构的回答。 解决方法 明确提示 (Prompt Engineering): 设计更具体、更详细的问题，减少模型的推测空间。 示例： 错误：解释一下宇宙的起源。 改进：根据当前主流科学理论解释宇宙的起源，例如大爆炸理论。 提供上下文：将相关的事实或背景信息直接提供给模型。 示例：在提示中明确说明所用的数据来源，例如 “基于 2021 年的全球人口统计数据”。 2. 结合外部知识库 大模型本身没有实时更新的知识，但可以通过结合外部知识库或 API 来增强准确性。 解决方法 知识增强 (Retrieval-Augmented Generation, RAG): 使用像 Pinecone、Weaviate 或 Elasticsearch 的向量数据库存储知识，然后根据输入从数据库中检索相关内容，再将其提供给模型生成回答。 示例工具： LangChain: 支持从外部知识库检索信息并增强生成内容。 Haystack: 支持文档检索和基于上下文的生成。 检索工具集成： 通过搜索引擎或领域专用的 API 来验证模型的生成内容。 3. 设置事实验证机制 在生成结果后，通过额外的步骤验证其准确性。 解决方法 事实检查模块： 在生成答案后，添加一个独立的模块验证模型输出是否与真实信息一致。 示例： 使用规则库、专家系统或查询外部数据库对模型生成内容逐项核实。 链式推理验证： 模型可以逐步输出推理过程，每一步都进行自检或外部验证。 示例：通过 […]