反应本地简短评论

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,我能够创建一个完全符合我需求的博客。

Wordex – iOS 快速阅读程序

最近我发现了一款​​速读应用,想推荐给大家。

速读是一项可以大大提高你的工作效率、提高你的阅读理解能力、节省时间的技能。市场上有许多应用程序承诺帮助您掌握这项技能,但其中脱颖而出的是 iOS 版 Wordex。在这篇文章中,我们将告诉您Wordex是什么、它有哪些功能、它适合谁以及为什么它值得关注。

Wordex 是什么?

Wordex 是一款专为培养快速阅读技能而设计的 iOS 应用程序。它可以帮助用户更快地阅读文本、专注于关键思想并避免分心。该程序基于科学方法,并提供方便的工具来提高您的阅读速度。

Wordex 主要功能

  • 快速阅读模式:文本显示经过优化,便于快速理解。用户可以根据自己的需要调整文本显示的速度。
  • 进度分析:该程序提供详细的统计数据,包括阅读速度和改进动态。这可以帮助您评估自己的进步并调整您的阅读方法。
  • 导入文本:Wordex 允许您上传自己的文本进行练习。您可以直接在应用程序中阅读文章、书籍或教育材料。
  • 直观的界面:该应用程序采用简约风格设计,易于使用。即使初学者也可以轻松理解其功能。

<中心>
Wordex Screenshot 1

Wordex 适合谁?

Wordex 非常适合:

  • 学生:需要快速阅读学习材料并准备考试的人。
  • 商人和办公室职员:希望在最短的时间内处理大量信息的人。
  • 读者:想要阅读更多书籍并享受阅读过程的人。

<中心>
Wordex Screenshot 2

Wordex 的优点

  • 移动性:借助 iPhone 或 iPad 上的应用程序,您可以随时随地学习。
  • 个性化:能够自定义文本显示以满足您的需求。

<中心>
Wordex Screenshot 3

为什么应该尝试 Wordex?

Wordex 不仅仅是一个快速阅读教学工具。这是一个培养注意力、扩大词汇量和提高生产力的计划。一旦您尝试了Wordex,您就会发现阅读不再是一件苦差事,而是变成了一项令人兴奋的活动。

结论

如果您想学习快速阅读或提高现有技能,Wordex 是一个不错的选择。该应用程序易于使用且有效,将帮助您实现目标并节省宝贵的时间。从 App Store 下载 Wordex 并立即开始训练!

应用商店:
https://apps.apple.com/us/app/speed-reading-book-reader-app/id1462633104

为什么干燥很重要

关于 DRY 主题的文章有很多,我建议阅读 Andy Hunt 和 Dave Thomas 的原始资料“The Pragmatist Programmer”。然而,我仍然看到有多少开发者对软件开发中的这一原则存在疑问。

DRY 原则指出我们不应该重复自己,这适用于我们作为程序员执行的代码和流程。违反 DRY 的示例代码:

class Client {
    public let name: String
    private var messages: [String] = []
    
    init(name: String) {
        self.name = name
    }
    
    func receive(_ message: String) {
        messages.append(message)
    }
}

class ClientController {
    func greet(client: Client?) {
        guard let client else {
            debugPrint("No client!")
            return
        }
        client.receive("Hello \(client.name)!")
    }

    func goodbye(client: Client?) {
        guard let client else {
            debugPrint("No client!!")
            return
        }
        client.receive("Bye \(client.name)!")
    }
}

正如您在greet 和goodbye 方法中看到的,传递了Client 类的一个可选实例,然后需要检查该实例是否为nil,然后您就可以开始使用它了。为了符合 DRY 方法,您需要删除类实例的重复 nil 检查。这可以通过多种方式实现;一种选择是将实例传递给类构造函数,之后就不需要进行检查。

我们在单个客户端实例上使用 ClientController 专业化来遵守 DRY:

class Client {
    public let name: String
    private var messages: [String] = []
    
    init(name: String) {
        self.name = name
    }
    
    func receive(_ message: String) {
        messages.append(message)
    }
}

class ClientController {
    private let client: Client

    init(client: Client) {
        self.client = client
    }

    func greet() {
        client.receive("Hello \(client.name)!")
    }

    func goodbye() {
        client.receive("Bye \(client.name)!")
    }
}

DRY 还涉及软件开发过程中发生的流程。让我们想象一种情况,开发团队必须自己向市场上传版本,分散他们对软件开发的注意力,这也是违反 DRY 的。这种情况可以通过连接 CI/CD 管道来解决,在该管道中,只要开发人员满足某些条件,就会自动发布版本。

一般来说,DRY 是指流程和代码中不存在重复,这也很重要,因为人为因素的存在:包含较少重复、噪声代码的代码更容易检查错误;自动化流程使人们在执行过程中不可能犯错误,因为没有人参与。

史蒂夫·乔布斯(Steve Jobs)有句名言:“你永远不必编写的一行代码就是你永远不必调试的一行代码。”

来源

https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/
https://youtu.be/-msIEOGvTYM

我将帮助您为 Swift 或 Objective-C 开发 iOS

我很高兴地宣布,我现在以 iOS 开发人员的身份在 Fiverr 上提供服务。如果您需要帮助开发优质 iOS 应用程序或改进现有项目,请查看我的个人资料:
https://www.fiverr.com/s/Q7x4kb6

我很高兴有机会参与您的项目。
电子邮件:demensdeum@gmail.com
电报:https://t.me/demensdeum

macOS 上 Qt 应用程序的动态链接

今天,我发布了适用于配备 macOS 和 M1/M2/M3/M4 处理器(Apple Silicon)的 Apple 设备的 RaidenVideoRipper 版本。 RaidenVideoRipper 是一款快速视频编辑应用程序,可让您将视频文件的一部分剪切成新文件。您还可以制作 gif 并将音轨导出为 mp3。

接下来,我将简要描述我使用了哪些命令来完成此任务。这里发生的事情的理论,实用程序的文档,可以在以下链接中阅读:
https://www.unix.com/man-page/osx/1/otool/
https://www.unix.com/man-page/osx/1/install_name_tool/
https://llvm.org/docs/CommandGuide/llvm-nm.html
https://linux.die.net/man/1/file
https://www.unix.com/man-page/osx/8/SPCTL/
https://linux.die.net/man/1/chmod
https://linux.die.net/man/1/ls
https://man7.org/linux/man-pages/man7/xattr.7.html
https://doc.qt.io/qt-6/macos-deployment.html

首先,在 macOS 上安装 Qt,并安装 Qt 桌面开发环境。之后,例如在 Qt Creator 中组装您的项目,然后我将描述在将应用程序分发给最终用户时确保正确处理与外部动态库的依赖关系所需的内容。

在应用程序的 YOUR_APP.app/Contents 文件夹中创建 Frameworks 目录,并将外部依赖项放入其中。例如,RaidenVideoRipper 应用程序的框架如下所示:

Frameworks
├── DullahanFFmpeg.framework
│   ├── dullahan_ffmpeg.a
│   ├── libavcodec.60.dylib
│   ├── libavdevice.60.dylib
│   ├── libavfilter.9.dylib
│   ├── libavformat.60.dylib
│   ├── libavutil.58.dylib
│   ├── libpostproc.57.dylib
│   ├── libswresample.4.dylib
│   └── libswscale.7.dylib
├── QtCore.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtCore -> Versions/Current/QtCore
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtGui.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtGui -> Versions/Current/QtGui
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtMultimedia.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtMultimedia -> Versions/Current/QtMultimedia
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtMultimediaWidgets.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtMultimediaWidgets -> Versions/Current/QtMultimediaWidgets
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtNetwork.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtNetwork -> Versions/Current/QtNetwork
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
└── QtWidgets.framework
    ├── Headers -> Versions/Current/Headers
    ├── QtWidgets -> Versions/Current/QtWidgets
    ├── Resources -> Versions/Current/Resources
    └── Versions

为了简单起见,我只打印了第二层嵌套。

接下来,我们打印应用程序当前的动态依赖关系:

otool -L RaidenVideoRipper 

RaidenVideoRipper 二进制文件的输出,位于 RaidenVideoRipper.app/Contents/MacOS:

RaidenVideoRipper:
	@rpath/DullahanFFmpeg.framework/dullahan_ffmpeg.a (compatibility version 0.0.0, current version 0.0.0)
	@rpath/QtMultimediaWidgets.framework/Versions/A/QtMultimediaWidgets (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtWidgets.framework/Versions/A/QtWidgets (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtMultimedia.framework/Versions/A/QtMultimedia (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtGui.framework/Versions/A/QtGui (compatibility version 6.0.0, current version 6.8.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2575.20.19)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 367.4.0)
	@rpath/QtNetwork.framework/Versions/A/QtNetwork (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtCore.framework/Versions/A/QtCore (compatibility version 6.0.0, current version 6.8.1)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

从 RaidenVideoRipper 中的 Qt 和 dullahan_ffmpeg 依赖项中可以看出。 Dullahan FFmpeg 是 FFmpeg 的一个分支,将其功能封装在动态库中,能够使用 C 例程获取当前执行进度和取消。
接下来,使用 install_name_tool 替换应用程序和所有必需库的路径。

执行此操作的命令是:

install_name_tool -change old_path new_path target

使用示例:

install_name_tool -change /usr/local/lib/libavfilter.9.dylib @rpath/DullahanFFmpeg.framework/libavfilter.9.dylib dullahan_ffmpeg.a

输入所有正确的路径后,应用程序应该正确启动。检查库的所有路径是否都是相对的,传输二进制文件,然后再次打开它。
如果您看到任何错误,请通过 otool 检查路径并通过 install_name_tool 再次更改。

当您替换的库在表中没有符号时,还会出现依赖关系混乱的错误;您可以像这样检查是否存在符号:

nm -gU path

执行后,您将看到库或应用程序的整个符号表。
也有可能您复制了错误架构的依赖项,您可以使用文件检查:

file path

文件实用程序将向您显示库或应用程序属于哪个体系结构。

此外,Qt 需要 YOUR_APP.app 目录的 Contents 文件夹中有一个 Plugins 文件夹,将插件从 Qt 复制到 Contents。接下来,检查应用程序的功能,之后您可以通过从此文件夹中删除项目并测试应用程序来开始优化插件文件夹。

macOS 安全性

复制所有依赖项并更正动态链接的路径后,您需要使用开发人员的签名对应用程序进行签名,并将应用程序版本发送给 Apple 进行公证。

如果您没有 100 美元的开发人员许可证或不想签署任何内容,请向您的用户编写有关如何启动应用程序的说明。

此指令也适用于 RaidenVideoRipper:

  • 禁用网闸:spctl –master-disable
  • 允许从“隐私与安全”中的任何来源启动:允许应用程序切换到任何地方
  • 从 zip 或 dmg 应用程序下载后删除隔离标志:xattr -d com.apple.quarantine app.dmg
  • 检查隔离标志 (com.apple.quarantine) 是否丢失:ls -l@ app.dmg
  • 如有必要,请在“隐私与安全”中添加启动应用程序的确认信息

隔离标志的错误通常会通过用户屏幕上出现的“应用程序已损坏”错误来重现。在这种情况下,您需要从元数据中删除隔离标志。

为 Apple Silicon 构建 RaidenVideoRipper 的链接:
https://github.com/demensdeum/RaidenVideoRipper/releases/download/1.0.1.0/RaidenVideoRipper-1.0.1.0.dmg

使用 ffmpeg 实现视频稳定

如果您想稳定视频并消除相机抖动,“ffmpeg”工具提供了强大的解决方案。借助内置过滤器“vidstabdetect”和“vidstabtransform”,您无需使用复杂的视频编辑器即可获得专业的效果。

准备工作

在开始之前,请确保您的“ffmpeg”支持“vidstab”库。在 Linux 上,您可以使用以下命令进行检查:

bash  
ffmpeg -filters | grep vidstab  

如果未安装该库,您可以添加它:

sudo apt install ffmpeg libvidstab-dev  

通过brew安装macOS:

brew install libvidstab
brew install ffmpeg

现在让我们继续该过程。

第 1 步:运动分析

首先,您需要分析视频的运动并创建带有稳定参数的文件。

ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -  

参数:

抖动:视频抖动级别(默认为 5,对于更复杂的情况可以增加到 10)。
精度:分析精度(默认15)。
transfile:保存运动参数的文件名。

第 2 步:应用稳定化

现在您可以使用转换文件应用稳定性:

ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

参数:

input:指向带有转换参数的文件(在第一步中创建)。
缩放:用于消除黑边的缩放系数(例如 5 – 自动缩放直至消除伪像)。

使用 Bistr 自动代码分析

如果您需要分析项目的源代码,但希望自动化该过程并使用计算机的本地功能,Bistr 实用程序可能是一个很好的解决方案。在本文中,我们将了解该实用程序如何帮助使用 Ollama 机器学习模型分析代码。

什么是 Bistr?

Bistr 是一个源代码分析实用程序,允许您集成本地 LLM(大语言模型)模型(例如 Ollama)来进行代码分析和处理。使用 Bistr,您可以解析各种编程语言(例如 Python、C、Java、JavaScript、HTML 等)的文件。

Bistr 使用该模型根据某些查询检查文件,例如,找到有关代码或其部分功能的问题的答案。这提供了有助于开发、测试和维护项目的结构化分析。

Bistr 如何工作?

  • 加载状态:当您开始分析时,实用程序会检查之前是否已保存分析状态。这可以帮助您从上次停下的地方继续,而无需再次解析相同的文件。
  • 代码分析:使用 Ollama 模型分析每个文件。该实用程序向模型发送请求以分析特定代码段。该模型返回有关响应查询的代码相关性的信息,并且还提供了为什么给定片段与任务相关的文本解释。
  • 状态保存:分析完每个文件后,状态都会更新,以便您下次可以继续使用最新信息。
  • 结果输出:所有分析结果都可以导出到 HTML 文件,其中包含一个表格,其中按相关性对文件进行排名,这有助于了解代码的哪些部分对于进一步分析最重要。

安装和启动

要使用 Bistr,您必须安装并运行 Ollama,这是一个在本地计算机上提供 LLM 模型的平台。下面介绍了在 macOS、Windows 和 Linux 上安装 Ollama 的说明。

从 git 下载最新版本的 Bistr:
https://github.com/demensdeum/Bistr/

安装Ollama和Bistr后,您可以运行代码分析。为此,您需要准备源代码并指定包含要分析的文件的目录的路径。该实用程序允许您从上次中断的地方继续分析,并且还提供以 HTML 格式导出结果的功能,以便于进一步分析。

运行分析的示例命令:


python bistr.py /path/to/code --model llama3.1:latest --output-html result.html --research "What is the purpose of this function?"

在这个团队中:

–model 指定用于分析的模型。
–output-html 指定 HTML 文件中分析结果的保存路径。
–research 允许您通过分析代码提出您想要回答的问题。

使用 Bistr 的好处

  • 本地执行:分析在您的计算机上进行,无需连接到云服务,从而加快了流程。
  • 灵活性:您可以分析不同编程语言的代码。
  • 自动化:所有代码审查工作都是自动化的,这可以节省时间和精力,尤其是在处理大型项目时。

使用 ollama 的局部神经网络

如果您希望推出像 ChatGPT 这样的东西,并且您有一台相当强大的计算机,例如配备 Nvidia RTX 显卡,那么您可以运行 ollama 项目,该项目将允许您使用现成的 LLM 模型之一您的本地机器,完全免费。 ollama 提供了与 LLM 模型进行通信的能力,以 ChatGPT 的方式进行;在最新版本中,还宣布了读取图像并将输出数据格式化为 json 格式的能力。

我还在配备 Apple M2 处理器的 MacBook 上运行了该项目,并且我知道 AMD 最新型号的显卡受到支持。

要在 macOS 上安装,请访问 ollama 网站:
https://ollama.com/download/mac

单击“下载 macOS 版”,您将下载 ollama-darwin.zip 形式的存档,存档内有 Ollama.app,需要将其复制到“应用程序”。之后,启动 Ollama.app,安装过程很可能会在您第一次启动时发生。之后,在托盘中您可以看到 ollama 图标,该托盘位于时钟旁边的右上角。

之后,启动常规 macOS 终端,然后键入命令来下载、安装并运行任何 ollama 模型。可用模型、描述及其特征的列表可以在 ollama 网站上查看:
https://ollama.com/search

如果启动时不适合您的显卡,请选择参数最少的型号。

例如运行 llama3.1:latest 模型的命令:


ollama run llama3.1:latest

Windows 和 Linux 的安装通常是相似的,在一种情况下,会有一个 ollama 安装程序,并通过 Powershell 进一步使用它。
对于 Linux,安装是使用脚本完成的,但我建议使用特定包管理器的版本。在 Linux 上,还可以通过常规 bash 终端启动 ollama。

来源
https://www.youtube.com/watch?v=Wjrdr0NU4Sk
https://ollama.com

修复 WordPress 中的移动菜单


document.addEventListener('DOMContentLoaded', function() {
    new navMenu('primary');
    new navMenu('woo');
});

如果您在使用 Seedlet 主题时也已经好几年没有在您的 WordPress 博客上打开 iOS/Android 上的博客菜单,那么只需添加:
将文件 wp-content/themes/seedlet/assets/js/primary-navigation.js 关闭到函数中,在默认订阅窗口 addEventListener ‘load’ 旁边。