Author Archives: demensdeum

DemensDeum 编码挑战#2

我正在开始 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 更新

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

立方体艺术项目2在线

在线遇到Cube Art Project 2 – 轻巧，快速且完全重写的电台时间表，该编辑直接在浏览器中工作。现在有可能共同创造力！

这不仅是一种工具，而且是对颜色，几何形状和冥想的3D创建的实验，您可以与朋友联系。该项目是在纯JavaScript上创建的，没有框架和WebAssembly，展示了WebGL和Shaaders的功能。

新：多人游戏！实时与其他用户合作。所有更改，立方体的添加和着色都会立即同步，使您可以一起创建站杰作。

控制：
– WASD-移动相机
– 鼠标 – 旋转
-GUI-颜色设置

在线的：
https://demensdeum.com/software/cube-art-project-2-online/

Github上的资料：
https://github.com/demensdeum/cube-art-project-2-online

该项目使用trix.js在纯JavaScript上编写。
没有框架，没有收藏家，没有WebAssembly-只有WebGL，着色器和对像素几何的一点爱。

Donki Hills Steam

唐基·希尔斯（Donki Hills）是一款喜剧恐怖游戏，在第一人称中是一种令人兴奋的叙事经历，并以意想不到的幽默感使玩家深入秘密。该游戏由Demensdeum在虚幻引擎上开发和出版，可让您控制一个普通人詹姆斯（James），他的生活在他的在线熟人玛丽亚（Maria）的神秘失踪之后，他的生活发生了不寻常的转变。他唯一的线索是一张照片，暗示着一个僻静的俄罗斯村庄，名为《宁静唐基》，位于诺瓦西比尔斯克附近。詹姆斯以不可动摇的联系和迫切需要答案的需求（可能有几次紧张的笑声）开车，詹姆斯继续史诗般的旅程，揭示了玛丽消失的真相。

该游戏可在Steam上使用：
https://store.steampowered.com/app/3476390/Donki_Hills/

编程中的熵

[补充]

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

软件中的熵是什么？

软件中的熵是算法意外结果的量度。用户将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工具和可观察性平台的帮助下，可靠的生产监控，结合对根本原因和灵活团队实践的纪律分析，可确保对新兴问题的快速响应，并创建持续的改进周期。

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

实际上没有福尔马林的框图

框图是一种视觉工具，有助于将复杂的算法转变为可理解且结构化的动作序列。从编程到业务流程管理，它们是一种可视化，分析和优化最复杂系统的通用语言。

想象一下一张地图，而不是道路是逻辑，而不是城市 – 行动。这是一个框图 – 在最令人困惑的过程中导航的必不可少的工具。

示例1：简化的游戏启动方案
要了解工作原理，让我们提出一个简单的游戏发布计划。

当一切都没有失败时，该方案显示了完美的脚本。但是在现实生活中，一切都更加复杂。

示例2：扩展的方案用于使用数据加载开始游戏
现代游戏通常需要互联网连接才能下载用户数据，保存或设置。让我们将这些步骤添加到我们的计划中。

该方案已经更现实，但是如果出现问题，会发生什么？

怎么样：一款“破产”的游戏，失去了互联网

在项目开始时，开发人员无法考虑所有可能的情况。例如，他们专注于游戏的主要逻辑，并且不认为如果玩家具有互联网连接会发生什么。

在这种情况下，其代码的框图看起来像这样：

在这种情况下，该游戏在等待数据的阶段冻结了，而不是由于缺乏连接而无法收到的数据，而不是发出错误或关闭。这导致了“黑屏”并冻结了应用程序。

如何变成：用户投诉纠正

在许多用户对徘徊的投诉之后，开发人员团队意识到我们需要纠正错误。他们通过添加错误处理单元来更改代码，该单元允许应用程序正确响应缺乏连接。

这就是校正的框图的外观，其中两个方案都被考虑：

借助这种方法，游戏现在正确地通知了用户有关问题的信息，在某些情况下，它甚至可以进入离线模式，从而使您可以继续游戏。这是一个很好的例子，说明了为什么框图如此重要：他们使开发人员不仅考虑了理想的执行方式，而且还考虑了所有可能的失败，从而使最终产品更加稳定和可靠。

不确定的行为

悬挂和错误只是该程序不可预测行为的一个例子。在编程中，存在一个不确定行为（不确定的行为）的概念 – 这是语言标准无法描述程序在某种情况下应如何行为的情况。

这可能会导致任何事情：从撤回的随机“垃圾”到程序的失败甚至严重的安全漏洞。例如，使用内存时，通常会发生不确定的行为。

语言C的一个示例：

想象一下，开发人员将线路复制到缓冲区中，但忘了添加到零符号（`\ 0`）的端，该符号标记了线路的末端。

这就是代码的样子：

#include 

int main() {
char buffer[5];
char* my_string = "hello";

memcpy(buffer, my_string, 5);

printf("%s\n", buffer);
return 0;
}

预期结果：“你好”
真正的结果是不可预测的。

为什么会发生这种情况？使用指定符的“ printf”函数期望该行以零符号结束。如果他不是，她将继续阅读突出显示的缓冲区之外的记忆。

这是此过程的框图，并具有两个可能的结果：

这是一个明显的例子，说明了框图如此重要的原因：它们使开发人员不仅考虑了理想的执行方式，而且还考虑了所有可能的失败，包括如此低级的问题，使最终产品更加稳定和可靠。

LLM Fine-Tune

当前，所有流行的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继续开发，为开发人员提供了一种灵活而有效的方法来创建跨平台应用程序。它结合了开发速度和访问本地功能的可能性，使其成为许多项目的吸引人选择。

Pixel Perfect：在声明性时代的神话还是现实？

在界面开发的世界中，有一个共同的概念 – “小屋中的像素完美” 。它意味着设计机对最小像素的最准确再现。很长一段时间以来，它一直是黄金标准，尤其是在经典的网页设计时代。但是，随着声明性英里的到来和各种设备的快速增长，“ Pixel Perfect”的原理变得越来越短暂。让我们尝试找出原因。

帝国wysiwyg vs.声明守则：有什么区别？

传统上，许多接口，尤其是桌面，是使用命令式方法或编辑器的Wysiwyg（您看到的）创建的。在这样的工具中，设计师或开发人员直接用元素来操纵，将它们放在画布上，以准确的像素。它类似于使用图形编辑器 – 您会看到元素的外观，并且肯定可以将其定位。在这种情况下，“ Pixel Perfect”的成就是一个非常真实的目标。

但是，现代发展越来越基于声明性里程。这意味着您不告诉计算机“在此处放这个按钮”，而是要描述您想要获得的内容。例如，您没有指示元素的特定坐标，而是描述其属性：“此按钮应为红色，从各个方面有16px的凹痕，并且位于容器的中心。”像React，Vue，Swiftui或JetPack一样，只需使用此原理即可。

为什么“ Pixel Perfect”不适合许多设备的声明英里

想象一下，您创建了一个在iPhone 15 Pro Max，Samsung Galaxy Fold，iPad Pro和4K分辨率上看起来同样不错的应用程序。这些设备中的每一个都有不同的屏幕分辨率，像素密度，派对和物理大小。

当您使用声明性方法时，系统本身会考虑其所有参数在特定设备上显示您所描述的接口。您设置规则和依赖性，而不是苛刻的坐标。

* 适应性和响应能力：声明英里的主要目标是创建自适应和响应式接口。这意味着您的接口应自动适应屏幕的大小和方向，而不会破坏和保持可读性。如果我们试图在每个设备上“像素完美”，则必须为同一界面创建无数的选项，这将完全阐明声明方法的优势。
* 像素密度（DPI/PPI）：设备具有不同的像素密度。如果您不考虑缩放率，则具有高密度的设备上的100个“虚拟”像素的尺寸将比低密度设备上的元素小得多。声明的框架是通过物理像素抽象的，与逻辑单元一起工作。
* 动态内容：现代应用程序中的内容通常是动态的 – 其体积和结构可能会有所不同。如果我们用力地将像素破烂，文本或图像的任何更改都会导致布局的“崩溃”。
* 各种平台：除了各种设备之外，还有不同的操作系统（iOS，Android，Web，桌面）。每个平台都有自己的设计，标准控件和字体。尝试在所有平台上制作绝对相同的Pixel完美界面的尝试将导致不自然的类型和差的用户体验。

旧方法没有消失，而是进化了

重要的是要了解，接口的方法不是“命令”和“声明性”之间的二元选择。从历史上看，对于每个平台，都有自己的工具和方法来创建接口。

* 本机接口文件： iOS是xib/故事板，用于android-xml标记文件。这些文件是一个完美的Wysiwyg布局，然后像编辑器一样在广播中显示。这种方法并没有在任何地方消失，它继续发展，并与现代宣言框架集成。例如，苹果和Jetpack的Swiftui在Android中构成了纯粹的声明代码的道路，但同时保留了使用经典布局的机会。
* 混合解决方案：经常在实际项目中，使用多种方法。例如，可以声明地实现应用程序的基本结构，并且对于需要准确的元素定位，可以使用较低的，命令式方法或开发的本机组件，以考虑到平台的细节。

从整体到适应性：设备的演变如何形成声明英里

在过去的几十年中，数字界面的世界发生了巨大变化。从具有固定许可证的固定计算机来看，我们来到了各种用户设备的指数增长的时代。今天，我们的应用程序应该同样擅长：

* 智能手机的所有形式和屏幕尺寸的大小。
* 平板电脑具有独特的方向模式和一个分开的屏幕。
* 笔记本电脑和台式机具有各种监视器的许可。
* 电视和媒体中心，远程控制。值得注意的是，即使对于电视，它的备注也很简单，因为 Apple TV Remote 具有最少的按钮，反之亦然，但具有许多功能，对接口的现代要求也不应需要对这些输入功能进行特定的适应。该接口应“好像自身”工作，而不必对与特定遥控器进行交互的“如何”相互作用。
* 智能手表和可穿戴设备带有简约屏幕。
* 虚拟现实头盔（VR），需要一种全新的空间接口方法。
* 增强现实设备（AR），应用有关现实世界的信息。
* 汽车信息和娱乐系统。
*甚至是家用电器：从带有感官屏幕和带有交互式显示器的洗衣机到智能烤箱和智能房屋系统的冰箱。

这些设备中的每一个都有其独特的功能：物理维度，派对比率，像素密度，输入方法（触摸屏，鼠标，控制器，手势，声乐命令），以及用户环境的微妙之处。例如，VR Shlesh需要深层沉浸，并且在旅途中进行了智能手机的快速和直观的工作，而冰箱界面应像快速导航一样简单而大。

经典方法：支撑各个接口的负担

在台式机和第一个移动设备的主导时代，通常的业务是对单个接口文件的创建和支持，甚至是每个平台的完全独立的接口代码。

* ios 下的开发通常需要在Xcode中使用故事板或XIB文件，在Objective-C或Swift上编写代码。
*对于 android ，创建了XML标记文件和Java或Kotlin上的代码。
* Web接口打开了HTML/CSS/JavaScript。
*对于 c ++应用程序在各种桌面平台上，使用了它们的特定框架和工具：
*在 Windows 中，这些是MFC（Microsoft Foundation类），带有手动绘制元素的Win32 API或使用资源文件用于对话框Windows和Control Elements。
*可可（Objective-C/Swift）或用于直接控制图形界面的旧碳API。
*在 linux/unix样系统中，经常使用诸如GTK+或QT之类的库，这些库通常通过类似XML的标记文件（例如，QT Designer中的.UI文件）或直接的软件创建元素来提供其用于创建接口的小部件和机制。

这种方法可确保对每个平台的最大控制，从而使您可以考虑其所有特定功能和本机元素。但是，他有一个巨大的缺点：重复的努力和支持的巨大成本。设计或功能的最小变化需要引入几个独立代码库的权利。对于开发人员团队来说，这变成了真正的噩梦，减慢了新功能的输出并增加了错误的可能性。

声明英里：多样性的单一语言

正是为了回应这种快速的并发症，声明性的里程似乎是主要的范式。像 React，Vue，Swiftui，JetPack构成之类的Framws不仅是编写代码的新方法，而且是思维的根本转变。

声明性方法的主要思想：我们没有说“如何”绘制每个元素（势在必行），而是描述了“我们想看到的（声明性）。我们设置了接口的属性和条件，框架决定如何最好地在特定设备上显示它。

由于以下主要优势，这可能是可能的：

1。从平台的详细信息中抽象：声明的fraimvorki专门设计为忘记每个平台的低级别详细信息。开发人员使用单个传输的代码以更高的抽象级别描述了组件及其关系。
2。自动适应性和响应能力： freimvorki负责自动缩放，将元素的布局和适应性更改为不同尺寸的屏幕，像素密度和输入方法。这是通过使用灵活布局系统（例如Flexbox或Grid）以及类似于“逻辑像素”或“ DP”的概念来实现的。
3。用户体验的一致性：尽管存在外部差异，但声明的方法使您可以在整个设备家族中维护行为和交互的单一逻辑。这简化了测试过程，并提供了更可预测的用户体验。
4。开发和降低成本的加速：具有能够在许多平台上工作的相同代码，大大减少了发展和支持的时间和成本。团队可以专注于功能和设计，而不是重复重写相同的接口。
5。未来的准备就绪：从当前设备的细节中抽象的能力使声明代码更具对新型设备和形式因素的出现的抵抗力。可以更新Freimvorki以支持新技术，并且您已经编写的代码将获得此支持相对无缝。

结论

声明的英里不仅是一种时尚趋势，而且是由用户设备快速开发（包括物联网（IoT）和智能家用电器）引起的必要进化步骤。它允许开发人员和设计师创建复杂，自适应和统一的接口，而不会淹没每个平台的无尽特定实现。从对每个像素的命令控制到所需状态的声明性描述的过渡是一种认识，即在未来的世界中，无论显示哪种屏幕，都应灵活，传递和直观。

程序员，设计师和用户需要学习如何生活在这个新世界。 Pixter Perfect的额外细节，设计为特定设备或分辨率，导致不必要的时间成本进行开发和支持。此外，这种刺激性的布局可能根本无法在具有非标准界面的设备上使用，例如有限的输入电视，VR和AR Shifts以及未来的其他设备，我们仍然不知道今天。灵活性和适应性 – 这些是创建现代世界中成功接口的关键。

为什么程序员即使在神经网络上也无能为力

如今，神经网络无处不在。程序员使用它们来生成代码，解释其他解决方案，自动化日常任务，甚至从头开始创建整个应用程序。看来这应该导致效率提高，降低错误和发展的加速。但是现实要平淡得多：许多人仍然没有成功。神经网络无法解决关键问题 – 它们仅阐明了无知的深度。

完全依赖LLM而不是理解

主要原因是，许多开发人员完全依靠LLM，而无视对他们使用的工具的深入了解。而不是研究文档 – 聊天请求。而不是分析错误的原因 – 复制决定。而不是建筑解决方案 – 根据描述产生组件。所有这些都可以在表面上起作用，但是一旦出现了非标准任务，就可以与真实的项目集成或需要进行微调，一切都在崩溃。

缺乏上下文和过时的实践

神经网络生成代码概括。他们没有考虑到您的平台，库的版本，环境限制或项目的架构解决方案的细节。生成的东西通常看起来合理，但与真实的，受支持的代码无关。即使简单的建议属于框架的过时版本或长期以来一直被认为是无效或不安全的使用方法，它们也可能行不通。模型不了解上下文 – 他们依赖统计信息。这意味着在开放代码中流行的错误和反植物将一次又一次地复制。

冗余，效率低下和缺乏分析

生成的AI代码通常是多余的。它包括不必要的依赖性，重复的逻辑，不必要地添加了抽象。事实证明，一个难以支撑的无效结构。这在移动开发中尤其重要，在移动开发中，帮派的大小，响应时间和能耗至关重要。

神经网络不进行分析，不考虑CPU和GPU的限制，也不关心内存的泄漏。它没有分析代码在实践中的有效性。优化仍然是手工制作的，需要分析和检查。没有它，即使从结构的角度来看，应用程序就会变得缓慢，不稳定和资源密集型。

脆弱性和对安全性的威胁

不要忘记安全。当成功使用LLM成功地破解项目的项目部分或完全创建时，已经有已知的情况。原因是典型的：使用不安全功能，缺乏输入数据的验证，授权逻辑中的错误，通过外部依赖性泄漏。神经网络仅仅是因为它是在开放存储库中找到的，才能生成脆弱的代码。没有安全专家的参与和完整的修订，此类错误很容易成为攻击的投入点。

法律是帕累托，缺陷的本质

Pareto Law与神经网络明确合作：由于20％的努力，结果的80％是实现的。该模型可以生成大量代码，创建项目的基础，传播结构，安排类型，连接模块。但是，所有这些都可以过时，与当前版本的库或框架不兼容，并且需要大量的手动修订。自动化在这里而不是作为草稿，需要检查，处理和适应项目的特定现实。

谨慎乐观

然而，未来看起来令人鼓舞。不断更新培训数据集，与当前文档的集成，自动化体系结构检查，符合设计和安全模式 – 所有这些都可以从根本上改变游戏规则。也许几年后，我们可以真正依靠LLM作为真正的技术公司作者来更快，更安全，更有效地编写代码。但是现在 – a-必须手动检查，重写和修改很多。

神经网络是一个强大的工具。但是，为了使他为您工作，而不是反对您，您需要一个基础，批判性思维和愿意随时控制。

生姜原型窗口

我引起了您的注意，凯特·凯特（Kate）的文本编辑称为gingerita。为什么叉，为什么，目标是什么？我想添加我工作中需要的功能，以免等待校正，添加凯特团队的功能，或者对主分支的采用。
目前，目前可为Windows提供一个原型版本，几乎变化的凯特（Kate）几乎是香草版本。对于Gingerita，我开发了两个插头 – 直接从编辑器和浏览器中的图像的图像，用于调试我的网络项目或与AI与AI与Chatgpt等助手进行交互。

Windows版本可以通过以下链接进行测试：
https://github.com/demensdeum/Gingerita/releases/tag/prototype

支持Demensdeum产品

欢迎来到支持页面！

如果您有疑问，Demensdeum产品的问题，或者您想提供改进，我们将随时准备帮助。

如何与我们联系：
support@demensdeum.com

我们尝试在3-5个工作日内回答上诉。

在信中表明什么：

产品的名称
版本（如果已知）
问题的详细描述
屏幕截图或视频（如果可能的话）
出现问题的设备和操作系统

我们感谢您使用我们的产品，并努力使您的体验尽可能方便而愉快。

真挚地，
Demensdeum团队

Vibe核心技巧：为什么LLM仍然无法与固体，干燥和干净一起使用

随着大型语言模型（LLM）的开发，例如ChatGpt，越来越多的开发人员使用它们来生成代码，设计体系结构和加速集成。但是，通过实用的应用，它变得明显：建筑的经典原理 – 固体，干燥，清洁 – 与LLM Codgendation的特殊性相同。

这并不意味着原理已经过时了 – 相反，它们与手动开发完美合作。但是使用LLM，必须适应该方法。

为什么LLM无法应对建筑原理

封装

不合时间需要了解系统部分之间的界限，对开发人员意图的知识以及严格的访问限制。 LLM通常会简化结构，无缘无故地公开字段或重复实现。这使得代码更容易受到错误的影响，并违反了架构边界。

摘要和接口

设计模式，例如抽象工厂或策略，需要对系统的整体视图并了解其动态。模型可以在没有明确目的的情况下创建一个界面，而无需确保其实现或违反层之间的连接。结果是过量或非功能架构。

干（托管重复自己）

LLM不要寻求最大程度地减少重复代码 – 相反，与制作一般逻辑相比，他们更容易复制块。尽管他们可以根据要求提供重构，但默认模型倾向于生成“自给自足的”片段，即使它导致冗余。

干净的体系结构

清洁意味着严格的层次结构，远离框架，定向依赖性以及层之间的最小连接性。这样的结构的产生需要对系统的全球理解，而llm则以单词概率而不是建筑完整性的含义来起作用。因此，该代码混合在一起，违反了依赖的方向和简化的划分。

使用LLM 时效果更好

湿而不是干
在与LLM合作时，湿（写两次）方法更为实用。代码的重复不需要保留模型中的上下文，这意味着结果是可以预测的，并且更易于正确纠正。它还减少了非明显连接和错误的可能性。

此外，重复有助于补偿模型的短记忆：如果在多个地方发现了某些逻辑片段，LLM更有可能将其考虑到进一步的生成中。这简化了伴奏，并增加了对“忘记”的抵制。

简单结构而不是封装

避免复杂的封装并依靠代码部分之间的数据直接传输，您可以大大简化生成和调试。通过快速的迭代开发或MVP的创建，尤其如此。

简化体系结构

该项目的简单，平坦的结构具有最少的依赖性和抽象，从而在生成过程中产生了更稳定的结果。该模型可以更轻松地调整这样的代码，并且较少违反了组件之间的预期连接。

SDK集成 – 手动可靠

大多数语言模型接受过过时的文档版本培训。因此，当生成用于安装SDK的指令时，通常会出现错误：过时的命令，无关参数或链接到无法访问的资源。实践显示：最好使用官方文档和手动调整，而LLM则是辅助角色 – 例如，生成模板代码或配置的改编。

为什么原理仍然有效 – 但是手动开发

重要的是要了解，固体，干燥和清洁的困难与LLM有关的CODHENELISERALION。当开发人员手动编写代码时，这些原则继续证明其价值：它们降低了连接性，简化支持，提高项目的可读性和灵活性。

这是由于人类思维容易概括的事实。我们正在寻找模式，将重复的逻辑带入单个实体，创建模式。可能，这种行为具有进化的根源：减少信息量可节省认知资源。

LLM的行为不同：他们没有从数据量中体验到负载，也不会努力储蓄。相反，与构建和维护复杂的抽象相比，他们更容易使用重复的，分散的信息。这就是为什么他们更容易在没有封装的情况下应对代码，重复结构和最小的架构严重性。

结论

大型语言模型是开发中的有用工具，尤其是在早期或创建辅助代码时。但是，重要的是要适应它们的方法：为了简化体系结构，限制抽象，避免复杂的依赖关系，并且在配置SDK时不依赖它们。

固体，干燥和清洁的原则仍然是相关的，但它们在人的手中赋予了最佳效果。使用LLM时，使用简化的实用风格是合理的，该样式使您可以获取可靠且易于理解的代码，该代码易于手动完成。 LLM忘记的地方 – 复制代码可以帮助他记住。

Demens电视负责人NFT

我想分享我的新项目 – NFT系列“ Demens TV Heads”。

这是一系列数字艺术作品，它们以Demensdeum徽标的风格反映了不同角色和专业的人。
第一批作品是凶猛的“ grozny”，这是一种风格化的自画像。

我计划每个月只发布12个NFT。

每项工作都不仅存在于以太坊区块链中，而且还可以在Demensdeum网站和Github-roads上与Metadan一起使用。

如果有兴趣，请参见或只是视觉评估，我会很高兴：
https://opensea.io/collection/demens-tv-heads
https://github.com/demensdeum/demens-tv-heads-collection
https://demensdeum.com/collections/demens-tv-heads/fierce.png
https://demensdeum.com/collections/demens-tv-heads/fierce-metadata.txt

超级程序员

他是谁 – 这个神秘的，短暂的，几乎是神话般的超级程序员？第一次汇编的代码的人是从一半开始启动的，并立即进入产品。传奇人字节从参议员传播到jun。专门编写错误，以使其他人并不感到无聊的人。老实说，以温暖和讽刺的态度，我们将弄清楚他必须戴上这个数字斗篷的超级大国。

1。在没有统一漏洞的情况下写下C/C ++
缓冲区溢出？从来没有听说过。
C ++中的超级程序员没有不便的变量 – 它们本身是从尊重中初始化的。他写了新的char [256]，编译器默默地添加了边界检查。其他人提出了断点 – 他一眼。错误消失了。

2。写英尺没有错误和测试
他不需要测试。他的代码在晚上睡觉时对自己进行测试（尽管…他睡觉了吗？）。任何行都是最终稳定版本，立即得到12种语言和NASA访问级别的支持。如果该错误仍然遇到，那么宇宙正在测试他。

3。它的起作用速度比AI快
当Chatgpt打印“多么好问题！”时，超级程序员已经锁定了新的操作系统，将其移植到烤面包机上，并用图表记录了Markdown中的所有内容。他不问Stackoverflow-他将未来的问题支持他。 GPT正在研究他的社区。

4。他比作者更好地了解别人的代码
“当然，我写了……但是我不明白它是如何工作的。” – 普通作家。
“哦，这是由于第894行中的递归调用，该汇编与Regex过滤器中的副作用相关。 – 超级程序员无眨眼。
他在第一次尝试中阅读了Perl，以变量的名称了解缩写，并通过振动来捕获光标。

5。在汇编程序上写入交叉平台代码
为什么要在Rust上写下纯X86，ARM和RISC-V，立即用旗帜“无处不在”写？他有自己的对手桌。甚至CPU都会在破坏他的指示之前进行思考。他没有优化 – 他超越了。

6。他回答了有关截止日期的问题，直到一秒钟
“什么时候准备好？”
“经过2个小时，17分8秒钟。是的，这考虑到了臭虫，烟雾中断和聊天中的一个哲学问题。”
如果有人要求更快地做，他只是通过make-jives重建时空。

7。反向和修理专有框架
专有的SDK掉落了，没有文档的API，所有内容都由Base92和咳嗽Segfault加密？对于超级程序员来说，这是一个普通的星期二。他将打开一个二进制吸气的六角形，一个小时后，将有一个带有修复程序的补丁，性能的改善和添加的黑暗模式。

8.设计师和UX专家
UI为他出来的是人们用美丽哭泣，并且按直觉猜测了按钮。甚至猫COPE-经过验证。他没有画一个界面 – 他像大理石中的雕塑家一样打开了内在的本质。每媒体都很高兴。

9。在提交之间进行营销研究
在GIT推挤和咖啡休息时间之间，他设法收集市场分析，建立销售渠道并重新考虑货币化策略。在周末测试假设。当他打开笔记本电脑时，他会自动启动A/B测试。

10。单独重复微软
对于他来说，这是10年和一千个工程师的公司 – 星期五晚上和好披萨。 Windows 11？ Windows 12。办公室吗？已经在那里了。 Excel？他从事语音管理工作，并有助于计划度假。一切效果更好，重量更少。

11。展开并支持100万用户的基础架构
他的自制Nas是Kubernetes Clister。监视？带有模因的Grafana。它比某些人设法开放邮递员更快地展现了API。他的一切都像苏联茶壶一样记录在案，自动化和可靠。

12.不需要技术支持
用户不抱怨它。他们只是尊敬它。常问问题？不需要。教程？直觉会说明。他是唯一在感恩页面上拥有“帮助”按钮的开发人员。

13。他不睡觉，不吃饭，没有分心
他以咖啡因为食，并纯粹希望编写代码。而不是睡眠，重构。而不是进食 – Debian包裹。他的生命周期是一个连续的发展周期。 CI/CD不是管道，这是一种生活方式。

14。与客户沟通而没有痛苦
“我们需要在两天内使优步，但只能更好。” – “看：这是路线图，这是风险，这是MVP。让我们首先决定目标。”
他知道如何拒绝：“客户回答：“谢谢，现在我明白了我想要的。 “

15。立即编程核反应堆
当铀核分开时，释放了多少热量？超级程序员知道。他知道如何在Rust，C，Swift，甚至在Excel中偷走它。它的反应堆不仅是安全的 – 它也由OTA更新。

16。在所有可能的领域都有知识
蒙古的哲学，物理，税收报告 – 他脑海中的一切。他参加了领导者的测验。如果他不知道某事，他只是暂时关闭记忆，以腾出空间以获得新知识。现在它将返回。

17。知道所有算法和设计模式
无需向他解释一个*，Dijkstra或Singleton的工作方式。他想着他们。与他一起，模式的行为正确。即使是对抗植物也可以从羞耻中纠正自己。

18。在苹果，谷歌工作，觉得无聊
他无处不在：苹果，Google，NASA，宜家（测试了机柜界面）。然后，我意识到它已经太好了，并去开发免费的开源项目以娱乐。他不需要钱，因为：

19。
是的，是他。只是不说。实际上，所有拥有数百万BTC的钱包实际上都在他的闪存驱动器上，并在混凝土中围起来。同时，他在内陆地区为农民合作社写了后端，因为“尝试Kotlin Multiplatform很有趣”。

结论：有点严肃
实际上，程序员是普通人。
我们误会了。我们很累。有时我们对自己充满信心，以至于我们看不到显而易见的事物 – 那时犯了它历史上最昂贵的错误。

因此，值得记住：

*不可能知道一切 – 但是重要的是要知道在哪里看。
*在团队中工作不是一个弱点，而是做出更好决定的途径。
*保护我们的工具不是“拐杖”，而是装甲。
*问是正常的。怀疑是正确的。犯错是不可避免的。学习是必要的。
*具有讽刺意味的是我们的盾牌。代码是我们的武器。责任是我们的指南针。

关于超级程序员的传说提醒我们，我们有时都为不可能而努力。这正是在此 – 真正的编程魔术。

为什么文档是您最好的朋友

（以及更新后的建议不再工作的大师）

“应用程序只能使用公共API，必须在当前运输的操作系统上运行。” Apple App评论指南

如果您曾经开始使用一个新的框架，并让自己思考：“现在我会理解一切，文档是针对孔的” – 您绝对并不孤单。许多开发人员有一个自然的本能：首先尝试，然后才能阅读。这很好。

但是，正是在这个阶段，您可以轻松地关闭正确的道路，发现自己处在代码有效的情况下……但是只有今天，只有“我有”。

为什么“弄清楚”很容易 – 还不够吗？

Freimvorki，尤其是封闭和专有的，是复杂的，多层次的。他们具有许多隐藏的逻辑，优化和实现功能，其中：

*未记录；
*不能保证；
*可以随时改变；
*是商业秘密，可以受到专利保护
*包含错误，仅在框架开发人员中知道的缺陷。

当您“直觉”行动时，您可以轻松地在随机观察中构建体系结构，而不是对清晰描述的规则进行支持。这导致了以下事实：代码变得容易受到更新和边缘案例的影响。

文档不是限制，而是支持

框架的开发人员创建手册是有原因的 – 这是您和他们之间的协议。当您充当文档的一部分时，他们保证：

* 稳定;
* 支持;
*可预测的行为。

如果您超越此框架 – 接下来发生的一切都将完全成为您的责任。

实验？当然。但是在规则的框架内。
好奇心是开发人员的超级视频。探索，尝试非标准，测试边界 – 所有这些都是必要的。但是有一个重要的“但是”：

您需要在文档和最佳实践的框架中进行实验。

文件不是监狱，而是卡。她展示了真正的计划和支持的机会。这种实验不仅有用，而且安全。

谨慎：guru

有时您可能会遇到真正的“专家”：

*他们开展课程
*在会议上表演，
*写书和博客，
*分享了对框架的“方法”。

但是，即使他们听起来令人信服，也要记住：
如果他们的方法与文档相反，则它们是不稳定的。

这样的“经验模式”可以：

*仅在特定版本的框架上工作；
*容易受到更新的影响；
*在不可预测的情况下打破。

当宗师尊重手册时，他们很酷。否则，必须通过官方文档过滤他们的提示。

有点固体

来自扎实原则的三个想法在这里特别重要：

*开放/封闭的原则：通过公共API扩展行为，不要进入内部。
* Liskov的变态原则：不要依靠实施，依靠合同。疾病 – 替换实施时，一切都会破裂。
*依赖关系反转：高级别模块不应取决于低级别的模块。两种类型都应取决于抽象。抽象不应取决于细节。细节应取决于抽象。

这在实践中意味着什么？如果您使用框架并直接与其内部细节绑定 – 您违反了此原则。
相反，您需要建立对框架正式支持的公共接口，协议和合同的依赖。这给出了：

*与框架更改中代码的最佳隔离；
*容易测试和替换依赖项的能力；
*架构的可预测行为和稳定性。

当您的代码取决于详细信息，而不是抽象时，您将自己嵌入到可能随时消失或更改的特定实现中。

是否错误？

有时您会做正确的事情，但是它起作用了。发生这种情况 – 框架并不完美。在这种情况下：

*收集一个最小复制的例子。
*确保仅使用已记录的API。
*发送一个错误端口 – 他们肯定会理解您，并且很可能会有所帮助。

如果该示例是建立在黑客或旁路上的，则不需要开发人员支持它，并且很可能您的案件会简单地错过。

如何从框架挤压

*阅读文档。严重地。
*遵循作者的指南和建议。
*实验 – 但在所述。
*通过手册检查技巧（甚至是最著名的演讲者！）。
*折叠漏洞，案件最小并尊重合同。

结论

Freimvorki不是黑匣子，而是具有使用规则的工具。忽略它们意味着“随机”编写代码。但是，我们希望我们的代码长期生活，使用户满意，并且不会从次要更新中脱颖而出。

因此：信任，但是检查。是的，阅读手册。它们是您的超级大国。

来源

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

立方体艺术项目2

见面 – 立方体艺术项目2

车站编辑器的第二个版本，在没有WebAssembly的纯JavaScript上完全重写。
轻巧，快速，直接在浏览器中开始 – 仅此而已。

这是一个实验：立方体，颜色，自由和一些冥想的3D几何形状。
您可以使用RGB-Sloders更改颜色，保存和加载场景，在空间周围移动并播放。

控制：
– WASD-移动相机
– 鼠标 – 旋转
-GUI-颜色设置

在线的：
https://demensdeum.com/software/cube-art-project-2/

Github上的资料：
https://github.com/demensdeum/cube-art-project-2

该项目使用trix.js在纯JavaScript上编写。
没有框架，没有收藏家，没有WebAssembly-只有WebGL，着色器和对像素几何的一点爱。

可以保存和加载场景 – 创建您的世界，保存为JSON，共享或返回以后进行改进。

Docker安全：为什么root的发射是个坏主意

Docker已成为现代Devops和Development中必不可少的工具。它使您可以隔离包围，简化服装并快速扩展应用程序。但是，默认情况下，Docker需要一个根，这会产生一个潜在的危险区域，在早期阶段通常会被忽略。

为什么Docker从根起作用？

Docker使用Linux的功能：CGROUP，命名空间，Iptables，Mount，网络和其他系统功能。这些操作仅适用于超级用户。

这就是为什么：
* Dockerd恶魔从根开始
* Docker命令传输到此恶魔。

这简化了工作，并完全控制了系统，但与此同时，它打开了潜在的漏洞。

为什么危险：集装箱突破，CVE，RCE

容器突破

由于绝缘弱，攻击者可以使用Chroot或Pivot_root进入主机。

真实攻击的例子：

* CVE-2019-5736-Vulnerability to runc，允许重写应用程序并在主机上执行代码。
* cve-2021-3156-对sudo的视频，允许在容器内扎根并脱下。

RCE（远程代码执行）

如果容器中的应用程序脆弱并从根开始，则RCE =对主机的完全控制。

无根的码头：问题的解决方案

为了最大程度地减少这些风险，在Docker中出现了无根模式。在这种模式下，恶魔和容器都是代表通常的用户启动的，没有任何根特性。这意味着，即使攻击者得到对容器的控制，他也将无法损害主机系统。
有限制：您无法使用低于1024的端口（例如80和443）， – 私人模式以及某些网络模式不可用。但是，在大多数开发方案和CI/CD无根的Docker中，它可以应付其任务，并大大提高了安全水平。

从历史上看，从根-Antipattern 发射

从一开始，最小特权的原则已在UNIX/Linux世界中应用。该过程的权利越少，危害所做的损失就越少。 Docker最初要求根源访问，但今天被认为是潜在的威胁。

来源

https://docs.docker.com/engine/security/rootless/
https://rootlesscontaine.rs/

Docker容器的非明显问题：隐藏的漏洞

Docker容器的非明显问题：隐藏的漏洞

什么是“ Dectionensky Hell”（DH）？

“依赖性地狱”（DH）是一个术语，表示在管理软件中的依赖项时出现的问题。它的主要原因是版本的冲突，整合各种库的困难以及它们之间保持兼容性的需求。 DH包括以下方面：

– 版本的冲突：项目通常需要特定版本的库，并且不同的组件可能取决于同一库的不兼容版本。
– 更新困难：更新依赖项可能会导致意外错误或兼容性故障，即使新版本包含更正或改进。
– 周围环境：隔离和稳定环境的愿望导致使用虚拟环境，容器化和其他旨在简化依赖管理的解决方案。

重要的是要注意，尽管消除漏洞是发布库更新版本的原因之一，但它不是DH的主要驱动力。主要的问题是，每种更改（无论是纠正错误，添加新功能还是消除漏洞）都可能导致一系列依赖关系，使应用程序的稳定开发和支持复杂化。

与DH的战斗是如何导致Docker创建的？

为了解决DH的问题，开发人员正在寻找为应用程序创建孤立稳定的环境的方法。 Docker是对这一挑战的回应。容器化允许：

– 隔离环境：所有依赖关系和库都与应用程序一起包装，这保证了安装Docker的任何地方稳定的工作。
– 简化部署：开发人员可以一旦配置环境并使用它在没有其他设置的情况下将其部署在任何服务器上。
– 减少冲突：由于每个应用程序都在其自身的容器中起作用，因此各个项目依赖关系之间发生冲突的风险大大降低了。

因此，Docker提出了一种有效解决DH问题的有效解决方案，使开发人员可以专注于应用程序的逻辑，而不是设置环境的困难。

Docker中过时的依赖性问题

尽管Docker具有所有优势，但出现了一个新的问题方向 – 成瘾的过时。发生这种情况是有几个原因：

1。容器及时冻结

创建Docker映像时，修复了所有软件包和库的某个状态。即使在基本图像中组装后（例如，`ubuntu：04.20，`python：3.9`，`node：18-alpine’），也会发现漏洞或产生新版本，该容器仍继续与最初安装的版本一起使用。如果不发送图像，该应用程序可以多年来与过时且潜在的脆弱组件一起使用。

2。缺乏自动更新

与传统服务器不同，您可以通过系统管理器配置自动软件包更新（例如，“ APT升级”或“ NPM Update”），容器不会自动更新。更新仅在重新选择图像时才发生，这需要纪律和正常控制。

3。固定依赖

为了确保稳定性，开发人员经常在“redirements.txt`或’poffage.json”等文件中修复依赖项的版本。这种方法可以防止意外变化，但同时冻结了依赖状态，即使随后在其中检测到错误或漏洞。

4。使用过时的基本图像

随着时间的推移，选择用于容器的基本图像也可以过时。例如，如果该应用程序是基于`node：16`的图像构建的，并且由于改进和校正，开发人员已经切换到“节点：18”，那么即使在代码中一切正常运行，您的环境也将保留在过时的版本中。

如何避免过时的依赖性问题？

在CI/CD过程中包括定期检查过时的依赖性和漏洞：

– 对于Python：

pip list --outdated

– for node.js：

npm outdated

– 使用工具来分析漏洞，例如“trivy”：

trivy image my-app

监视基本图像的更新

订阅Docker Hub中基本图像的更新或GitHub上的相应存储库，以便及时了解关键更正和更新。

结论

依赖地狱的问题不仅是因为需要消除脆弱性，而且由于难以管理和更新依赖关系。 Docker提出了一种有效的解决方案来对抗DH，为应用提供了孤立且稳定的环境。但是，随着容器化的出现，出现了一项新任务 – 需要定期更新图像以防止依赖性过时和关键脆弱性的出现。

对于现代DevOps的专家而言，重要的是，不仅要解决版本冲突的问题，而且要定期和自动化的控制实践，以使成瘾的相关性，以便容器保持安全有效。

构建器模式：分阶段及时创建对象

介绍

最后一篇文章研究了使用构建器模式的一般情况，但是当对象在及时创建对象时，该选项没有被涉及。
构建器图案（Builder）是一个生成设计模板，可允许您逐渐创建复杂的对象。当对象具有许多参数或各种配置时，它特别有用。它使用的有趣示例之一是能够分离及时创建对象的过程。
有时无法立即创建对象 – 它的参数可以在程序的不同阶段已知。

python的一个例子

在此示例中，汽车的对象是分阶段创建的：首先，数据的一部分是从服务器加载的，然后用户输入丢失的信息。

import requests

def fetch_car_data():
    response = requests.get("https://api.example.com/car-info")
    return response.json()

builder = CarBuilder()

# Backend API data
car_data = fetch_car_data()
builder.set_model(car_data["model"])
builder.set_year(car_data["year"])

# User input
color = input("Car color: ")
builder.set_color(color)

gps_option = input("GPS feature? (yes/no): ").lower() == "yes"
builder.set_gps(gps_option)

car = builder.build()
print(car)

想象一下API调用，数据输入在应用程序的不同部分，甚至在不同的库中。然后，与上面的简单示例相比，构建器模式的使用变得更加明显。

优势

– 输出是一种免疫结构，不需要存储临时组装的可选数据
– 逐渐收集对象
– 避免复杂的设计师
– 对象的组装代码仅在一个构建器的一个本质上是不完整的
– 理解代码的便利性

来源

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8
https://demensdeum.com/blog/2019/09/23/builder-pattern/

Demensdeum编码挑战＃1

开始Demensdeum编码挑战＃1
奖品100 USDT
1。我们需要为Windows 11 64位编写渲染图片
2。渲染
https://demensdeum.com/logo/demens1.png
3。图片应集成到应用程序中
4。图形API -direct3D或DirectDraw
5。赢得其应用程序的尺寸最小的字节。
6。图像应为原始的1分之一，保存颜色
7。任何语言/框架都不需要其他安装 – >您可以立即从应用程序开始。例如，如果解决方案仅是一个python脚本，则这种解决方案是不合适的。需要安装Python，Pygame和手动启动。很好的例子：Python脚本与EXE中的Python和Pygame一起包裹在一起，该脚本没有其他安装。
8。以源代码的链接形式给出源代码，用于组装应用程序的说明。很好的例子：Visual Studio Community Edition中带有大会说明的项目

截止日期：6月1日总结比赛

ZIG + SDL3 + SDL3_IMAGE上的参考解决方案：
https://github.com/demensdeum/DemensDeum-Coding-Challenge-1

为什么我选择 WordPress

当我在 2015 年开始考虑创建自己的博客时，我面临着一个问题：我应该选择哪个平台？经过多次搜索和比较，我选择了 WordPress。这不是一个随机的选择，而是对该平台的功能、优点和缺点进行分析的结果。今天我想分享我使用WordPress的想法和经验。

WordPress 的优点

  • 易于使用
    我选择 WordPress 的主要原因之一是它的直观界面。即使您之前从未使用过 CMS，您也可以在几天之内掌握 WordPress。
  • 大量插件
    WordPress 提供数以千计的免费和付费插件。这些扩展允许您添加几乎任何与博客相关的功能，从 SEO 优化到社交媒体集成。
  • 可扩展性
    WordPress 非常适合各种规模的博客。从一个简单的个人博客开始，我知道我可以通过添加新特性和能力轻松地发展它。
  • 广泛的主题选择
    WordPress 上有大量免费和付费主题，可让您在短时间内创建一个非常漂亮的博客。创建定制设计需要设计师的敏锐双手。
  • 搜索引擎优化
    WordPress 在设计上对搜索引擎友好。使用 Yoast SEO 等插件，您可以轻松优化您的内容以提高其搜索排名。
  • 社区和支持
    WordPress 拥有世界上最大的社区之一。如果您遇到问题，您几乎肯定会在专门针对该平台的论坛或博客上找到解决方案。
  • 多语言支持
    借助 WPGlobus 这样的插件，我可以用多种语言写博客，这在与来自不同国家的受众合作时尤为重要。

WordPress 的缺点

  • 易受攻击
    WordPress 的流行使其成为黑客的目标。如果没有适当的保护，网站可能会成为攻击的受害者。但是，定期更新和安装安全插件有助于最大限度地降低风险。
  • 插件依赖
    有时您想要添加的功能需要安装多个插件。这会降低您的博客速度并导致扩展之间的冲突。
  • 性能问题
    在大型博客上，WordPress 可能会开始变慢，尤其是在您使用大量插件的情况下。为了解决这个问题，您必须优化数据库，实现缓存并使用更强大的托管。
  • 部分功能的成本
    虽然 WordPress 的基本版本是免费的，但许多专业主题和插件都需要付费。有时您必须进行投资才能获得最大收益。

结论

WordPress 是一个在简洁性和强大性之间实现完美平衡的工具。对我来说，它的好处大于坏处，尤其是考虑到有大量的解决方案可以克服它们。感谢 WordPress，我能够创建一个完全符合我需求的博客。