几天后，在 Antigravity 的帮助下，我将 Masonry-AR 后端从 PHP + MySQL 转移到 Node.js + MongoDB + Redis -> Docker。 AI 的能力确实令人惊叹，我记得 2022 年我通过 ChatGPT 在shadertoy.com 上编写了最简单的着色器，看起来这个玩具无法做任何更高的事情。
https://www.shadertoy.com/view/cs2SWm

四年后，我看到了如何在大约 10 个提示中，毫不费力地将我的项目从一个后台平台转移到另一个后台平台，并添加了容器化。
https://mediumdemens.vps.webdock.cloud/masonry-ar/

酷，真的酷。

复古科技与古老民俗的完美结合。这位身着西装、挥舞着三叉戟的 8 位恶棍已经为区块链做好了准备。

https://opensea.io/item/ethereum/0x008d50b3b9af49154d6387ac748855a3c62bf40d/7

Noski 是一个用 Rust 编写的轻量级异步 SOCKS5 代理实现。它是使用 Tokio 运行时构建的，以实现高性能非阻塞 I/O。还有 DPI 绕过机制和使用称为 Pyatki 的 Noski 客户端的加密。

https://github.com/demensdeum/Noski

复古科技与反乌托邦街头服饰的邂逅。这种独特的像素艺术 (1/1) 描绘了标志性人物，其电视头广播着普罗维登斯之眼。

https://opensea.io/item/ethereum/0x008d50b3b9af49154d6387ac748855a3c62bf40d/6

我正在开始 Demensdeum 编码挑战#2：
1. 您需要对 Web 应用程序进行 vibecode，以显示用户区域中的聚会/活动列表。
2、数据源可以是前端的网页抓取，也可以是本地/远程数据库。
3. 仅在地图上显示今天的活动/聚会。
4. 您可以更改搜索半径。
5. 作为一系列文本提示提交，这些提示可以在免费代码生成器（例如 Google AI Studio）中重现。
6. 应该可以在 iOS、Android、PC 上运行
7. 最佳设计获胜
8. 通过点击地图上的事件来显示有关该事件的详细信息。
9. 用手指或鼠标缩放地图。
10. 获奖者由评审团选出（写信给我参加评审团）
11.奖品200 USDT
12. 截止日期：7月1日。

过去的 DemensDeum 编码挑战赛#1 的获胜者
https://demensdeum.com/blog/ru/2025/06/03/demensdeum-code-challenge-1-winner/

Masonry-AR 游戏中添加了用加密货币购买硬币的功能！只需 1 美元即可获得 5000 MOS。游戏中还添加了推荐链接；好友每购买一次，推荐人即可获得 50,000 MOS。共济会维基百科中有详细信息。还添加了自动行走模式：当无法访问 GPS 模块时，梅森开始自动从世界首都之一行走，仅向前行走。

游戏链接：
https://demensdeum.com/demos/masonry-ar/client/

《Donkey Adept》是一部令人惊叹的、令人兴奋的像素化超现实主义作品。中间是一个穿着黑色皮夹克的人物，他的头是一台燃烧着、充满静电的电视，长着火热的驴耳朵。人物手持强大的灯笼，充当在喧嚣中寻找真相的孤独哨兵。这是对媒体、疯狂和对光明的不懈追求的激烈复古式冥想。

https://opensea.io/item/ethereum/0x008d50b3b9af49154d6387ac748855a3c62bf40d/5

[补充]

编程中的熵是一种强大但通常不起眼的力，它决定了软件行为的可变性和不可预测性。从简单的错误到复杂的孙子，熵是我们的程序并不总是按照我们期望的。

软件中的熵是什么？

软件中的熵是算法意外结果的量度。用户将1STTI结果视为错误或错误，但是从机器的角度来看，该算法完全执行了程序员在其中放置的指令。出乎意料的行为是由于输入数据，系统条件和交互的大量可能组合而产生的。

熵的原因：

*改变状态：当对象可以更改其内部数据时，其工作的结果将取决于其使用的整个历史记录。

*算法的复杂性：随着程序的增长，执行代码的可能方法的数量呈指数增长，从而使所有结果的预测几乎不可能。

*外部因素：操作系统，其他程序，网络延迟 – 所有这些都会影响您的代码执行，从而创建其他可变性来源。

熵的原因：

*改变状态：当对象可以更改其内部数据时，其工作的结果将取决于其使用的整个历史记录。

*算法的复杂性：随着程序的增长，执行代码的可能方法的数量呈指数增长，从而使所有结果的预测几乎不可能。

*外部因素：操作系统，其他程序，网络延迟 – 所有这些都会影响您的代码执行，从而创建其他可变性来源。

全局变量作为熵的来源

（1973年）W.A. Wulf和M. Shaw在他的作品《全球变量造成的有害》中表明，全球变量是无法预测的行为的主要来源之一。它们创造了难以跟踪和控制的隐性成瘾和副作用，这是熵的经典表现。

莱曼和熵的定律

软件系统不断增长的复杂性的想法完美地制定了曼尼·莱曼（Manny Leman）的软件进化定律。其中两个直接反映了熵的概念：

使用的计算机程序将进行修改。该声明表明该软件不是静态的。它的生活，发展和变化以满足新的要求和环境。该计划生命的每个新“圆”都是熵的潜在来源。

当修改计算机程序时，其复杂性会增加，只要没有人阻止这一点。该定律是熵的直接结果。没有针对性的复杂性管理工作，每个新修改都会在系统中引入其他可变性和不可预测性。有一些新的依赖性，条件和副作用增加了虫子和毫无意义的行为的可能性。

AI和LLM世界中的熵：不可预测的代码

在人工智能和大语言模型（LLM）领域，熵特别敏锐，因为在这里我们正在处理非范围的算法。与传统程序不同，同一访问总是以相同的方式出路，LLM可以给出相同请求的不同答案。

这造成了一个巨大的问题：只能在使用作者的一组有限的输入数据集上确认该算法的正确性。但是，当使用未知输入数据（用户的请求）时，模型的行为变得不可预测。

llm 中的熵示例

创新的词汇和种族主义陈述：聊天机器人（例如Microsoft的Tay或XII的Grok）的已知案例，经过互联网的数据培训后，开始产生进攻或种族主义陈述。这是熵的结果：未知输入数据与大量训练样本结合使用导致不可预测和不正确的行为。

非法上诉：当神经网络开始发布侵犯版权或道德规范的内容时，就会出现此类问题。

游戏中的AI BOTA：在游戏中引入AI字符，例如在Fortnite中学习的可能性，导致了这样一个事实，即必须关闭AI机器人并添加以跟踪活动的正确性，以防止LLM Bot的非法行动。

技术债务：缺陷累计利息

书面代码和绕过解决方案不良
技术职责是一种有意识或无意识的妥协，在这种责任中，优先考虑迅速交付损害了长期支持和质量。快速更正和无证件旁路解决方案，通常在短时间内实施，累积，形成“雷区”。这使得代码基础甚至对微小变化非常敏感，因为很难将故意旁路解决方案与实际错误逻辑区分开，这会导致意外回归和错误数量增加。

这证明了技术义务对错误的传播和算法的完整性的直接，累积效应，其中每种当前减少所采用的每次减少都会导致将来更加复杂和频繁地误差。

测试不足及其累积效应

当未仔细测试软件系统时，它们更容易受到错误和意外行为的影响。这种不足使错误会随着时间的流逝而累积，创建一个难以支持的系统，并且非常容易受到更多错误的影响。从一开始就忽略测试不仅会增加技术债务，而且还直接有助于增加错误的数量。软件熵中的“窗户理论”表明，微不足道的，忽略的错误或设计问题会随着时间的流逝而累积，并导致更严重的问题并降低软件质量。

这建立了直接的因果关系：缺乏测试会导致错误的积累，从而导致熵的增加，从而导致更复杂和频繁的错误，直接影响算法的正确性和可靠性。

缺乏文档和信息筒仓

开发软件时通常会忽略正确的文档，这会导致有关系统如何工作以及如何支持该软件的分散或知识。这迫使开发人员“支持”进行更改的系统，大大增加了误解的可能性和不正确的修改，这直接导致错误。由于关键信息没有可用或误导性，因此它还严重使新开发人员的适应性变得复杂。

程序熵的发生是由于“缺乏知识”和“一般假设与现有系统的实际行为之间的差异”。这是一个更深层次的组织观察：熵不仅在代码层面，而且在知识层面上表现出来。这些非正式的隐性知识是脆弱的，很容易丢失（例如，离开团队成员时），这在试图修改时直接导致错误，尤其是团队的新成员，从而危害了算法逻辑的完整性，因为其主要假设停止了。

不一致的发展方法和所有权损失

人为因素是软件熵的重要，通常被低估的驱动因子。开发人员之间的各种技能，编码和质量期望会导致源代码中的不一致和偏差。缺乏用于覆盖，代码审查，测试和文档的标准化过程加剧了此问题。此外，当几个命令拥有代码的一部分或没有人拥有的一部分时，代码的不稳定代码不稳定，导致衰减的忽视和增加，这会导致复制组件以不同的方式执行相同功能，从而扩散错误。

这表明熵不仅是一个技术问题，而且是社会技术，深深植根于组织动态和人类行为。由于不一致的做法和零散的财产而引起的“集体不一致”直接导致不一致和缺陷，这使得系统无法预测和难以控制，这极大地影响了算法的完整性。

互连系统中的级联故障

现代软件系统通常很复杂，并且非常相互联系。在这样的系统中，当拒绝一个组件会导致其他故障的链反应时，高度的复杂性和密切相关的组件会增加级联故障的可能性。这种现象加剧了算法的错误和不当行为的影响，将局部问题变成系统性风险。此类系统中算法的结果变得非常容易受到远离其直接执行途径的失败的影响，这导致了广泛的结果。

建筑复杂性，熵的直接表现，可以将孤立的算法错误转变为大型系统故障，使总体系统不可靠，并且其输出数据是不可靠的。这强调了建筑稳定性的需求，以遏制熵效应的传播。

最新的例子之一是，由于2024年更新防病毒软件后出现了蓝色死亡屏幕，美国和欧洲机场的众所周知停止，Antivirus算法的错误结果和操作系统导致了世界空中交通。

实例

示例1：Unicode和Byte限制性中的熵

让我们看一个带有文本字段的简单示例，该示例受32个字节限制。

带有ASCII（低熵）的方案

如果字段仅接受ASCII符号，则每个符号为1个字节。因此，恰好将32个字符放在现场。任何其他符号都不会被接受。

@startuml
ASCII的标题示例（低熵）
演员用户
参与者“ Textfield”

用户 – > textfield：介绍32个符号ASCII
Textfield-> Textfield：检查长度（32个字节）
请注意
一切都很好。
结尾
textfield->用户：acceps输入
@Enduml

带有UTF-8（高熵）的方案：

现在，我们80年代的程序落在2025年。当字段占用UTF-8时，每个符号可以占据1到4个字节。如果用户引入了超过32个字节的线路，则系统可能会错误地剪切。例如，表情符号占4个字节。如果修剪发生在符号内，那么我们会得到一个“破碎”符号。

@startuml
带有UTF-8的标题示例（高熵）
演员用户
参与者“ Textfield”

用户 – > textfield：介绍“ hi”（37字节）
textfield-> textfield：剪切最多32个字节
请注意
突然！象征
通过字节切割。
结尾
Textfield->用户：显示“ HI”
请注意
不正确的符号。
结尾
@Enduml

在这里，熵表现为以下事实：不同输入数据的相同修剪操作会导致不可预测和不正确的结果。

示例2：CSS中的熵和浏览器的不兼容

即使在看似稳定的技术（例如CSS）中，由于对标准的解释不同，也可能发生熵。

想象开发人员已应用用户当选：无；到所有元素关闭文本输出。

浏览器10（旧逻辑）

浏览器10对输入字段有例外。因此，尽管有标志，但用户可以输入数据。

@startuml
标题浏览器10
演员用户
参与者“浏览器10”作为浏览器10

用户 – >浏览器10：输入输入
浏览器10->浏览器10：检查CSS
请注意
– 用户 – 当选：无；
忽略输入
结尾
浏览器10->用户：允许输入
@Enduml

浏览器11（新逻辑）

新浏览器的开发人员决定严格遵循规格，将规则应用于所有元素，无一例外。

@startuml
标题浏览器11
演员用户
参与者“浏览器11”作为浏览器11

用户 – >浏览器11：输入输入
浏览器11->浏览器11：检查CSS
请注意
– 用户 – 当选：无；
应用于所有元素，包括输入
结尾
浏览器11->用户：拒绝输入
请注意
用户无能为力
类型。
结尾
@Enduml

这个熵的经典示例 – 相同的规则根据“系统”（浏览器的版本）导致不同的结果。

示例3：由于含糊不清的TK 熵

模棱两可的技术任务（TK）是熵的另一种强大来源。当两个开发人员鲍勃和爱丽丝以不同的方式理解相同的要求时，这会导致不兼容的实现。

TK：“要实现斐波那契数的生成器。为了优化，必须将生成数字的列表捕获在发电机内。”

鲍勃的心理模型（条件变化的OOP）
鲍勃（Bob）专注于“清单…必须被拖延”一词。他实施了一个存储相同状态（自我序列）的类，并随着每次呼叫而增加。

    def __init__(self):
        self.sequence = [0, 1]

    def generate(self, n):
        if n <= len(self.sequence):
            return self.sequence

        while len(self.sequence) < n:
            next_num = self.sequence[-1] + self.sequence[-2]
            self.sequence.append(next_num)

        return self.sequence

爱丽丝的心理模型（功能方法）

爱丽丝专注于“返回序列”一词。她编写了一个纯净的功能，每次都将新列表返回，仅使用缓存作为内部优化。

    sequence = [0, 1]
    if n <= 2:
        return sequence[:n]

    while len(sequence) < n:
        next_num = sequence[-1] + sequence[-2]
        sequence.append(next_num)

    return sequence

当爱丽丝开始使用BOB生成器时，她希望生成（5）将始终返回5个数字。但是，如果在此BOB在同一对象处称为生成（8），Alice将收到8个数字。

底线：熵是心理模型的结果。 BOB实施中的可变状态使该系统无法预测为Alice，该系统正在等待纯粹功能的行为。

熵和多势：种族和祖父的状况

在多流动的编程中，熵特别表现出来。同时执行几个流，并且其实现过程是不可预测的。当结果取决于哪个流是第一个访问公共资源的流时，这可能会导致比赛条件。极端情况是祖父，当两个或两个以上的溪流互相等待，并且程序冻结。

Dedlok解决方案的示例：

当两个或多个流相互阻止，等待资源发布时，DEDLOK的问题就会出现。解决方案是建立一个单一的，固定的程序来夺取资源，例如，通过增加ID来阻止它们。这不包括循环期望，可以防止僵局。

@startuml
标题解决方案：统一阻止程序
参与者“流1”为线程1
参与者“流2”为thread2
参与者“为”帐户
参与者“帐户b”作为帐户

thread1-> accounta：阻止帐户
注意螺纹1
规则如下：
块ID
结尾
thread2->帐户：等待帐户A将被释放
请注意thread2
规则如下：
等待锁定
结尾
thread1-> accountb：块帐户b
thread1->帐户：释放帐户
thread1-> accountb：发行得分b
注意螺纹1
交易完成
结尾
thread2-> accounta：阻止帐户
thread2-> accountb：块帐户b
请注意thread2
交易结束
结尾
@Enduml

这种方法 - 订购的阻塞（锁定订购） - 是防止并行编程中的Deadlles的基本策略。

太好了，让我们分析使用画布上的示例在OOP方法中可变状态增加熵，并将其与纯函数进行比较。

问题：改变条件和熵

当对象具有变化状态时，其行为就会变得不可预测。调用相同方法的结果不仅取决于其参数，还取决于与此对象的整个互动历史。这将熵进入系统。

考虑在画布上绘制矩形的两种方法：一个以可变条件的OOP风格，另一种具有纯函数的功能。

1。OOP方法：具有可变状态的课程
在这里，我们创建一个光标类，该类存储其内部状态，在这种情况下为颜色。 Draw方法将使用此条件绘制矩形。

  constructor(initialColor) {
    // Внутреннее состояние объекта, которое может меняться
    this.color = initialColor;
  }

  // Метод для изменения состояния
  setColor(newColor) {
    this.color = newColor;
  }

  // Метод с побочным эффектом: он использует внутреннее состояние
  draw(ctx, rect) {
    ctx.fillStyle = this.color;
    ctx.fillRect(rect.x, rect.y, rect.width, rect.height);
  }
}

// Использование
const myCursor = new Cursor('red');
const rectA = { x: 10, y: 10, width: 50, height: 50 };
const rectB = { x: 70, y: 70, width: 50, height: 50 };

myCursor.draw(ctx, rectA); // Используется начальный цвет: red
myCursor.setColor('blue'); // Изменяем состояние курсора
myCursor.draw(ctx, rectB); // Используется новое состояние: blue

OOP方法的UML图：

该图清楚地表明，尽管其参数可能不会改变，但Draw方法的呼声给出了不同的结果。这是由于一个单独的setColor调用，它改变了对象的内部状态。这是可变状态下熵的经典表现。

title ООП-подход
actor "Программист" as Programmer
participant "Класс Cursor" as Cursor
participant "Canvas" as Canvas

Programmer -> Cursor: Создает new Cursor('red')
note left
  - Инициализирует состояние
    с цветом 'red'.
end note
Programmer -> Cursor: draw(ctx, rectA)
note right
  - Метод draw использует
    внутреннее состояние
    объекта (цвет).
end note
Cursor -> Canvas: Рисует 'red' прямоугольник
Programmer -> Cursor: setColor('blue')
note left
  - Изменяет внутреннее состояние!
  - Это побочный эффект.
end note
Programmer -> Cursor: draw(ctx, rectB)
note right
  - Тот же метод draw,
    но с другим результатом
    из-за измененного состояния.
end note
Cursor -> Canvas: Рисует 'blue' прямоугольник
@enduml

2。功能方法：纯粹的功能

在这里，我们使用纯函数。它的任务是简单地使用传输到其的所有必要数据绘制矩形。她没有任何条件，她的挑战不会影响边界之外的任何事情。

  // Функция принимает все необходимые данные как аргументы
  ctx.fillStyle = color;
  ctx.fillRect(rect.x, rect.y, rect.width, rect.height);
}

// Использование
const rectA = { x: 10, y: 10, width: 50, height: 50 };
const rectB = { x: 70, y: 70, width: 50, height: 50 };

drawRectangle(ctx, rectA, 'red'); // Рисуем первый прямоугольник
drawRectangle(ctx, rectB, 'blue'); // Рисуем второй прямоугольник

功能方法的UML图：

该图显示drawRectangle函数始终具有外部颜色。她的行为完全取决于输入参数，这使其干净并且具有低水平的熵。

@startuml
标题功能方法
演员“程序员”作为程序员
参与者“功能\ n drawRectangle”作为drawfunc
参与者“画布”作为画布

程序员 - > drawfunc：drawredreWerctangle（ctx，recta，'red'）
请注意
- 致电参数：
-CTX
- 直肠（坐标）
- “红色”（颜色）
- 功能没有条件。
结尾

drawfunc->画布：带有颜色“红色”的洪水
程序员 - > drawfunc：drawredreWerctangle（ctx，rectb，'blue'）
请注意
- 致电新参数：
-CTX
-RECTB（坐标）
- '蓝色'（颜色）
结尾
drawfunc->画布：带有颜色“蓝色”的洪水
@Enduml

在具有纯函数的示例中，由于该功能没有条件，因此行为是完全可预测的。所有工作的信息都是通过争论传递的，这使其孤立且安全。在带有可变状态的Draw方法行为的OOP方法中，与对象的互动的整个历史可能会影响，这引入了熵并使代码降低了可靠。

模块化设计和体系结构：隔离，可检验性和RE-使用

将复杂系统分为较小，独立，自给自足的模块，简化了设计，开发，测试和维护。每个模块都会处理某些功能，并通过明确定义的界面进行交互，从而减少了相互依赖性并有助于责任分离。这种方法可提高可读性，简化维护，促进并行开发，并通过隔离问题来简化测试和调试。至关重要的是，这会减少错误的“失败半径”，阻止在单独的模块中阻碍缺陷并防止级联故障。微服务体系结构是一种强大的方式实现。

模块化不仅是组织代码的一种方式，而且是一种包含缺陷和稳定性提高的基本方法。限制误差在一个模块中的影响，模态增加了系统对熵衰减的总体稳定性，确保一个拒绝点不会损害整个应用程序的正确性。这使团队可以专注于系统的较小，更受控的部分，从而导致更彻底的测试和更快的检测和纠正错误。

纯代码的实践：可靠性的亲吻，干燥和坚实的原则

亲吻（保持简单，愚蠢）：
这种设计理念代表简单和清晰，积极避免不必要的复杂性。简单的代码本质上更容易阅读，理解和修改，这直接导致倾向的趋势和改善支持的趋势。复杂性清楚地定义为错误的营养环境。

KISS不仅是一种审美偏好，而且是故意的设计选择，它减少了错误的攻击表面，并使代码对未来的变化更具抵抗力，从而保持了算法的正确性和可预测性。这是在详细的代码级别上反对熵的主动措施。

干燥（Donat重复自己）：
该干燥原则旨在减少信息的重复和代码的重复，用抽象替换或使用数据归一化。其主要立场是“每个知识的片段都应在系统中具有一个单一的，明确的，权威的代表。”这种方法消除了冗余，从而减少了不一致的情况，并防止了错误的传播或在重复的逻辑的几个副本中的不一致校正。它还简化了代码库的支持和调试。

代码的重复导致不一致的变化，这又导致错误。 Dry可以防止这种情况，从而为逻辑和数据提供了一个真实的来源，这直接有助于算法的正确性，确保一般逻辑在整个系统中均匀且可预测地行为，以防止稀薄，难以输入错误。

固体原理

该助记符的首字母缩写提出了五个基本设计原则（统一责任，开放性/亲密性，替代liskin，界面的分离，依赖性倒置），这对于创建面向对象的项目至关重要，这些项目清晰，灵活和支持。遵守固体软件实体变得更容易支持和适应，从而导致较少的错误和更快的开发周期。他们通过简化服务（SRP）来实现这一目标，确保可扩展的添加功能无需修改（OCP），确保行为一致性（LSP），最小化相干性（ISP）并增加了由于抽象（DIP）而提高灵活性。

坚实的原理为结构完整性提供了一种整体方法，这使得系统本质上更能抵抗变化的特技效应。促进模块化，分离和明确的责任，它们可以防止层叠错误并保留算法的正确性，即使系统是不断进化的，它是对抗熵的基本措施。

熵和域驱动设计（DDD）

域驱动的设计（DDD）不仅是一种理念，而且是一种成熟的方法，它提供了将应用程序分解为域中的特定模式，这使您可以有效地控制复杂性和战斗熵。 DDD有助于将混乱的系统变成一组可预测的孤立组件。

四个设计的帮派模式作为单个概念设备

“设计模式：可重复使用的对象软件的元素”（1994年），由“四个团伙”（GOF）（GOF）撰写，为典型问题提供了一系列可靠的解决方案。这些模式是打击熵的绝佳工具，因为它们创建了结构化，可预测和受控的系统。

模式的关键影响之一是创建单个概念设备。当一个团队中的开发人员谈论“工厂”或“孤独者”时，他的同事立即了解我们在谈论哪种代码。这大大减少了通信的熵，因为：

歧义降低：模式具有清晰的名称和描述，这些名称和描述不包括不同的解释，如鲍勃和爱丽丝的示例中。

加速加速：新团队成员被倒入该项目，因为他们不需要猜测复杂结构背后的逻辑。

重构的促进：如果您需要根据模式更改系统的部分，则开发人员已经知道它是如何布置的，并且可以安全地修改哪些零件。

GOF模式及其对熵的影响的例子：

模式“策略”：允许您封装单个类中的各种算法并使它们可互换。这会减少熵，因为它使您可以在不更改其主代码的情况下更改系统的行为。

模式“命令”（命令）：Inkapsul将方法的方法归为对象。这使您可以推迟执行，将命令放入队列或取消它们。模式减少了熵，因为它将团队的发件人与接收者分开，使其独立。

观察者模式（观察者）：确定“一对多”的依赖性，其中一个对象状态的变化会自动通知所有依赖它。这有助于控制副作用，使其显而易见，可预测，而不是混乱和隐藏。

模式“工厂方法”：定义用于创建对象的接口，但允许子类决定要建立哪个类。这会减少熵，因为它使您可以灵活地创建对象而无需了解特定类，从而降低连接性。

这些模式可帮助程序员创建更可预测的，测试和受控的系统，从而减少熵，这不可避免地发生在复杂的项目中。

DDD控制熵的关键模式

有限的上下文：这种模式是DDD基础。它提供了将大型系统分为小的自主零件。每个上下文都有自己的模型，术语词典（普遍语言）和逻辑。这会产生严格的边界，以防止变化和副作用的传播。例如，在一个有限的上下文中进行更改，例如，在“订单的上下文”中不会影响“交付上下文”。

聚合（聚合）：该单元是相关对象的群集（例如，“顺序”，“顺序”线），被认为是整体。该单元具有一个根对象（聚集根），这是所有更改的唯一入口点。这提供了一致性，并确保单位状态始终保持不可或缺。通过仅通过其根对象更改单元，我们控制条件发生变化的方式和何时会大大降低熵。

域服务：对于不属于主题区域任何特定对象的操作（例如，在帐户之间的货币转移），DDD建议使用域服务。它们协调几个单元或对象之间的动作，但不要保持状况本身。这使逻辑更加透明和可预测。

DDD提供了使用事件的主题区域（域事件）的事件（域事件）：而不是来自不同上下文的直接调用方法。当某种情况下发生重要的事情时，他会“发布”该事件。其他上下文可以订阅此事件并响应它。这会在组件之间产生微弱的联系，这使系统更具可扩展性和对变化的抵抗力。

DDD帮助控制熵，创建清晰的边界，严格的规则和孤立的组件。这将一个复杂的，令人困惑的系统变成了一组独立的，受控的部分，每个部分都有自己的“法律”和可预测的行为。

复杂而活泼的文档

维护有关代码更改，设计解决方案，架构图和用户手册的详细和相关文档至关重要。这种“实时文档”有助于开发人员了解系统的复杂性，跟踪更改并正确进行未来的修改或正确的错误。它大大减少了在“重新打开”或系统的反向设计上所花费的时间，这是常见的错误来源。

程序熵的发生是由于“缺乏知识”和“一般假设与现有系统的实际行为之间的差异”。该文档不仅是指导，而且是

维护知识的关键机制，直接与“知识的熵”作斗争。通过明确和负担得起的隐性知识，它减少了误解以及由于对算法或系统交互行为的错误假设而犯错误的可能性，从而保护了功能正确性。

严格的测试和持续质量保证

自动测试：模块化，集成，系统和回归测试
自动测试是一种不可或缺的工具，可软化软件熵并防止错误。它允许尽早发现问题，确保代码更改不会违反现有功能，并提供快速，一致的反馈。关键类型包括模块化测试（用于隔离组件），集成测试（用于模块之间的交互），系统测试（用于完整集成系统）和回归测试（以确保新更改不会导致旧错误的重复出现）。自动测试大大降低了人为因素并提高了可靠性。

自动测试是防止隐藏缺陷积累的主要保护。它积极地将发现错误的发现转移到了开发周期中，这意味着当校正是最便宜和最简单的问题时发现问题，从而阻止了它们对熵昏迷的影响的贡献。这直接影响算法的正确性，不断检查几个详细级别的预期行为。

通过测试开发（TDD）：在检测错误时向左移动

通过测试开发（TDD）是软件开发的过程，其中包括在编写代码本身之前为代码编写测试。这个迭代的循环“反射”可促进快速反馈，从而可以尽早发现错误，并大大降低了后来发展阶段的复杂问题的风险。结果表明，TDD导致较小的错误和代码的最佳质量，很好地协调了干燥的理念（Donat重复自己）。 IBM和Microsoft的经验研究表明，TDD可以将误差密度降低到令人印象深刻的40-90％。测试示例还用作实时文档。

TDD充当主动质量控制，直接构建在开发过程中。强迫开发人员在实施之前确定预期行为，它最大程度地降低了逻辑错误的引入，并确保有目的创建代码以符合要求，从而直接提高算法的正确性和可预测性。

连续集成和交付（CI/CD）：早期反馈和稳定版本
CI/CD实践对于现代软件开发至关重要，有助于确定早期阶段的错误，加速开发并确保不间断的部署过程。将小型代码软件包经常集成到中央存储库中，可以通过自动组件和测试来尽早发现错误并持续改进代码质量。此过程提供了快速的反馈，使开发人员能够快速有效地消除问题，并显着提高代码的稳定性，从而阻止了未经验证或不稳定代码的积累。

CI/CD传送带起减少熵的连续机制。通过自动化集成和测试，它们可以防止集成问题的积累，提供不断发展的条件并提供回归的立即可见性。这种系统和自动化的方法直接抵消了连续变化，维持算法的稳定性并防止错误在整个系统中的传播的疾病。

技术债务的系统管理

增强重构：战略代码改进

重构是重组现有代码以改善其内部结构而不改变其外部行为的过程。这是打击软件腐烂和降低复杂性的直接手段。尽管重构通常被认为是减少错误数量的一种方法，但重要的是要承认，某些折射可以无意中造成新的错误，这需要严格的测试。但是，研究通常证实，折射的代码少于错误，而不是未经培训。将债务管理集成到当前发展过程中并且没有推迟的重构对防止技术债务的指数积累至关重要。

重构是一项故意减少熵，主动代码重组以使其对变化更具抵抗力的行动，从而减少了未来错误的可能性并提高了算法的清晰度。这将反应性的灭火变成了对结构健康的积极管理。

技术债务的积压：资源的优先和分配

维护当前的技术债务是系统管理和消除技术债务的关键实践。该积压是确定的技术义务和需要改进领域的要素的全面登记，确保不会忽略这些问题。它使项目经理可以根据其影响力和潜在风险的严重性来确定债务要素的优先级。在项目期间，Bablog的整合确保了重构，错误校正和代码清洁是项目日常管理的常规部分，从而降低了长期还款成本。

技术债务的Baclog将一个抽象的，越来越多的问题变成了一组受控的，有效的任务。这种系统的方法使组织能够在新功能的发展和质量投资之间采取合理的折衷，从而阻止了不明显的债务积累，这可能会导致关键错误或算法生产率的降解。它提供了对关键熵功率的可见性和控制。

静态和动态代码分析：问题的主动识别

静态分析

该技术包括对源代码的分析，而无需实施，以确定诸如错误，代码气味，安全漏洞和编码标准受损的问题。它是“第一线保护”，在开发周期的早期阶段确定问题，改善了代码的整体质量并通过在执行过程中出现在错误之前，通过识别出有问题的模板来减少技术债务。

静态分析充当自动化的“代码质量警察”。在执行之前识别潜在问题（包括影响算法逻辑的问题），它以错误或建筑缺点的形式防止其表现。这是确保编码标准并确定有助于软件熵的常见错误的可扩展方法。

动态分析

此方法在执行过程中评估软件行为，提供有关仅在执行过程中表现出的问题的宝贵信息。它在执行过程中出色地发现了错误，例如记忆泄漏，比赛状况和零指针的排除以及性能和安全性脆弱性的狭窄位置。

动态分析对于在执行过程中识别行为劣势至关重要，这无法通过静态分析检测到。静态分析和动态分析的结合确保了对代码的结构和行为的全面概念，从而使团队能够在出现严重问题之前识别出缺陷。

监视生产和事件办公室

APM（应用程序性能监控）：
APM工具旨在监视和优化应用程序性能。它们有助于识别和诊断性能的复杂问题，并检测错误的根本原因，从而减少停机时间和退化的收入损失。 APM系统监视各种指标，例如响应时间，资源和误差频率的使用，提供实时信息，这使您可以在影响用户之前主动解决问题。

APM工具对问题和维持服务水平的主动解决方案批评。它们在生产环境中提供了深厚的可见性，使团队能够快速识别并消除可能影响正确的算法或导致错误的问题，从而最大程度地减少停机时间并改善用户体验。

可观察性（日志，指标，示踪剂）：

可观察性是指根据其输出数据和资产之间的相互作用来分析和测量系统内部状态的能力。可观察性的三个主要支柱是指标（有关生产力和资源使用的定量数据），日志（事件的详细时间记录）和跟踪（跟踪通过系统组件的请求流）。他们共同帮助识别和解决问题，提供对系统行为的全面理解。可观察性超出了传统的监控，有助于理解“未知未知”，并改善了应用程序的无问题应用。

可观察性使团队可以灵活地研究正在发生的事情，并迅速确定他们可能没有预见的问题的根本原因。这提供了对系统行为的更深入，灵活和主动的理解，使团队能够快速识别和消除不可预见的问题并保持应用程序的高度可访问性。

根本原因（RCA）分析

根本原因（RCA）的分析是一个基于数据的结构化过程，该数据揭示了系统或过程中问题的基本原因，从而使组织能够实施有效的长期解决方案，而不仅仅是消除症状。它包括对问题的定义，相关数据的收集和分析（例如，指标，日志，临时量表），使用诸如“为什么”和Ishikawa图的工具确定因果关系和相关因素，以及纠正措施的开发和实施。 RCA对于防止问题和事件的培训至关重要。

RCA对于长期预防问题和事件培训至关重要。系统地识别和消除主要原因，不仅症状，组织还可以防止错误和算法失败的发生，从而降低了系统的整体系统并提高其可靠性。

灵活的方法和团队实践

敏捷中的错误管理：

在敏捷环境中，错误管理至关重要，建议在冲刺中分配时间以纠正它们。错误应记录在产品的单个产品中，并与相应的历史记录相关联，以促进根本原因的分析并改善随后的冲刺中的代码。团队应努力尽快纠正错误，最好是在当前的冲刺中，以防止其积累。错误统计数据的收集（已解决的数量，注册的数量，用于更正的时间）有助于了解代码质量并改善过程。

这强调了立即纠正的重要性，对根本原因的分析和持续改进。灵活的方法为主动控制错误提供了一个框架，以防止其对系统熵的贡献，并通过持续的验证和适应来保持算法的正确性。

devops 练习

DevOps实践有助于减少软件缺陷并通过多种关键方法提高质量。其中包括发展合作文化和毫无疑问的交流文化，采用持续整合和交付（CI/CD），自动测试的配置，将注意力集中在观察力和指标上，避免手工工作，包括在开发周期的早期阶段的安全性和事件上的培训。这些实践减少了错误的数量，提高质量并有助于不断改进。

DevOps通过自动化，快速反馈和普遍责任文化有助于持续改善和减少熵。整合开发和操作的过程，DevOps创建了一个环境，在该环境中，可以快速检测和消除问题，从而阻止其系统的积累和降解，从而直接支持算法的完整性。

结论

程序熵是不可避免的力量，它不断努力降级软件系统，尤其是在算法和错误的正确性下。这不仅是身体上的衰老，而且是代码，其环境和人为因素之间不断造成混乱的动态互动。这种衰减的主要驱动力包括越来越复杂，技术债务的积累，文档不足，外部环境不断变化以及不一致的开发方法。这些因素直接导致算法工作的结果不正确，可预测性丧失以及可能通过互连系统散布的错误数量增加。

与软件熵的斗争需要一种多方面，连续和主动的方法。仅仅纠正错误时，这还不够；有必要系统地消除生成它们的主要原因。采用模块化设计，清洁代码（亲吻，干燥，实心）和复杂文档的原理对于创建稳定的系统至关重要，这些系统本质上不太容易受到熵的影响。严格的自动测试，通过测试（TDD）开发（TDD）和连续集成/交付（CI/CD）起到了早期检测和预防缺陷的关键机制，不断检查和稳定代码库。

此外，通过偶然的重构和技术债务的障碍者以及使用静态和动态代码分析工具的系统债务的系统管理，使组织能够在导致关键失败之前积极识别和消除问题领域。最后，在APM工具和可观察性平台的帮助下，可靠的生产监控，结合对根本原因和灵活团队实践的纪律分析，可确保对新兴问题的快速响应，并创建持续的改进周期。

最终，确保算法的完整性并最大程度地减少软件熵条件下的错误 - 这不是一个时间的努力，而是在动态且不断变化的环境中保持秩序的持续义务。采用这些策略，组织可以显着提高其软件系统的可靠性，可预测性和耐用性，从而确保算法能够按计划进行，即使它们的发展也是如此。

当前，所有流行的LLM服务提供商都使用JSONL文件进行微调，该文件描述了模型的输入和输出，例如Gemini，OpenAI，格式略有不同。

在下载了专门成立的JSONL文件后，开始指定数据集上LLM模型的专业化过程开始，对于所有当前众所周知的LLM提供商，这项服务已支付。

对于使用Ollama在本地计算机上进行微调，我建议依靠YouTube频道技术的详细视频，并以最简单的方式微调LLM，并与Alloma一起使用Alloma：
https://www.youtube.com/watch?v=pTaSDVz0gok

jupyter笔记本电脑的一个示例，并从所有电报消息的导出中准备JSONL数据集并启动本地微调过程：
https://github.com/demensdeum/llm-train-example

React Native已将自己确立为跨平台开发移动和Web应用程序的强大工具。它允许您使用JavaScript/tyspript上的单个代码库来为Android和iOS创建本机应用程序，以及Web应用程序。

建筑与开发的基础

React国家体系结构基于JavaScript/Typescript的本机绑定。这意味着该应用程序中的基本业务逻辑和应用程序是在JavaScript或Typescript上编写的。当需要访问特定的本地功能（例如，设备或GPS摄像机）时，使用这些本机绑定，这使您可以调用iOS的Swift/Objective-C上写的代码或用于Android的Java/Kotlin。

重要的是要注意，最终的平台可能在功能上有所不同。例如，根据平台的本机功能，某些功能仅适用于Android和iOS，但不能用于Web，反之亦然。

配置和更新
本机绑定的配置是通过插件密钥进行的。对于稳定且安全的开发，使用最新版本的React本机组件并始终转向当前文档至关重要。这有助于避免兼容性问题，并使用最新更新的所有优势。

开发和优化的功能

React Native可以为特定平台生成产生的项目（例如，Android和iOS文件夹）。这使开发人员在必要时可以手动修补结果项目的文件，以进行精细的优化或特定的设置，这对于需要单独的性能方法的复杂应用程序特别有用。

对于典型和简单的应用程序，通常将Expo Bandle与内置的本机绑定使用通常足够。但是，如果应用程序具有复杂的功能或需要进行深度自定义，建议使用React Antive自定义组件。

开发和更新的饮食性

React Antial的关键优势之一是在开发过程中对Typescript/JavaScript代码进行热重载支持。这大大加速了开发过程，因为代码更改在应用程序中立即显示，从而使开发人员可以实时查看结果。

React Native还支持“静音更新）绕过Google Play和Apple App Store的过程，但这仅适用于Typescript/JavaScript代码。这使您可以快速发布错误或小型功能更新，而无需通过应用程序商店进行完整的出版物。

重要的是要了解TS/JS代码是使用指纹在特定版本的本机依赖版本上包裹的，这确保了JavaScript/Typescript部分与应用程序的本机部分之间的协调。

在开发中使用LLM

尽管使用LLM（大型语言模型）的CodheCeneration是可能的，但由于对模型的培训可能过时的数据集，其适用性并不总是很高。这意味着生成的代码可能与最新版本的反应本机或最佳实践对应。

React Native继续开发，为开发人员提供了一种灵活而有效的方法来创建跨平台应用程序。它结合了开发速度和访问本地功能的可能性，使其成为许多项目的吸引人选择。