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

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

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

示例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-必须手动检查，重写和修改很多。

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