LLM Fine-Tune

Actuellement, tous les fournisseurs de services LLM populaires utilisent une tonnerie amende à l’aide de fichiers JSONL, qui décrivent les entrées et sorties du modèle, avec de petites variations, par exemple pour Gemini, OpenAI, le format est légèrement différent.

Après avoir téléchargé un fichier JSONL spécialement formé, le processus de spécialisation du modèle LLM sur l’ensemble de données spécifié commence, pour tous les fournisseurs LLM bien connus actuels, ce service est payé.

Pour affiner sur une machine locale utilisant Olllama, je recommande de compter sur une vidéo détaillée de la Tech de la chaîne YouTube avec un moyen le plus facile de faire affiner un LLM et nous avec Alloma:
https://www.youtube.com/watch?v=pTaSDVz0gok

Un exemple d’ordinateur portable Jupyter avec la préparation de l’ensemble de données JSONL à partir des exportations de tous les messages télégrammes et le lancement du processus d’adaptation local est disponible ici:
https://github.com/demensdeum/llm-train-example

React Native Brief Review

React Native s’est imposé comme un outil puissant pour le développement multiplateforme des applications mobiles et Web. Il vous permet de créer des applications natives pour Android et iOS, ainsi que des applications Web à l’aide d’une seule base de code sur JavaScript / TypeScript.

Fondamentaux de l’architecture et du développement

React Architecture nationale est basé sur les liaisons natives de JavaScript / TypeScript. Cela signifie que la logique métier de base et une application dans l’application sont écrites sur JavaScript ou TypeScript. Lorsque l’accès à des fonctionnalités natives spécifiques (par exemple, l’appareil ou la caméra GPS) est requise, ces liaisons natives sont utilisées, qui vous permettent d’appeler le code écrit sur Swift / Objective-C pour iOS ou Java / Kotlin pour Android.

Il est important de noter que les plates-formes résultantes peuvent varier en fonctionnalité. Par exemple, une certaine fonctionnalité ne peut être disponible que pour Android et iOS, mais pas pour le Web, ou vice versa, selon les capacités natives de la plate-forme.

Configuration et mises à jour

La configuration des liaisons natives est effectuée via la touche Plugins. Pour un développement stable et sûr, il est essentiel d’utiliser les dernières versions des composants natifs React et de toujours se tourner vers la documentation actuelle. Cela permet d’éviter les problèmes de compatibilité et d’utiliser tous les avantages des dernières mises à jour.

Caractéristiques du développement et de l’optimisation

React Native peut générer des projets résultants pour des plates-formes spécifiques (par exemple, les dossiers Android et iOS). Cela permet aux développeurs, si nécessaire, de corriger les fichiers des projets résultants manuellement pour une optimisation fine ou des paramètres spécifiques, ce qui est particulièrement utile pour les applications complexes qui nécessitent une approche individuelle des performances.

Pour les applications typiques et simples, il suffit souvent d’utiliser Bandle Expo avec des liaisons natives construites. Cependant, si l’application a une fonctionnalité complexe ou nécessite une personnalisation profonde, il est recommandé d’utiliser des assemblages personnalisés natifs React.

Eaturabilité du développement et des mises à jour

L’un des principaux avantages de React Native est la prise en charge de rechargement à chaud pour le code TypeScript / JavaScript pendant le développement. Cela accélère considérablement le processus de développement, car les modifications de code sont instantanément affichées dans l’application, permettant au développeur de voir le résultat en temps réel.

React Native prend également en charge «Silent Update) en contournant le processus de Google Play et Apple App Store, mais cela ne s’applique qu’au code TypeScript / JavaScript.

Il est important de comprendre que le code TS / JS est bandé sur une version spécifique des dépendances natives utilisant l’empreinte digitale, ce qui assure la coordination entre la pièce JavaScript / TypeScript et la partie native de l’application.

Utilisation de LLM dans le développement

Bien que la codhegénération avec LLM (modèles de grande langue) soit possible, son aptitude n’est pas toujours élevée en raison d’ensembles de données potentiellement obsolètes sur lesquels les modèles ont été formés. Cela signifie que le code généré peut ne pas correspondre aux dernières versions de React Native ou des meilleures pratiques.

React Native continue de se développer, offrant aux développeurs un moyen flexible et efficace de créer des applications multiplateformes. Il combine la vitesse de développement avec la possibilité d’accès aux fonctions natives, ce qui en fait un choix attrayant pour de nombreux projets.

Pixel Perfect: Mythe ou réalité à l’ère de la déclarativité?

Dans le monde du développement des interfaces, il existe un concept commun – “Pixel parfait dans le lodge” . Cela implique la reproduction la plus précise de la machine de conception au plus petit pixel. Pendant longtemps, c’était une étalon-or, en particulier à l’ère d’une conception Web classique. Cependant, avec l’arrivée du mile déclarant et la croissance rapide de la variété des appareils, le principe de “Pixel parfait” devient plus éphémère. Essayons de comprendre pourquoi.

Imperial Wysiwyg vs code déclaratif: Quelle est la différence?

Traditionnellement, de nombreuses interfaces, en particulier de bureau, ont été créées en utilisant des approches impératives ou Wysiwyg (ce que vous voyez est ce que vous obtenez) des éditeurs. Dans de tels outils, le concepteur ou le développeur manipule directement avec des éléments, en les plaçant sur toile avec une précision au pixel. Il est similaire à travailler avec un éditeur graphique – vous voyez à quoi ressemble votre élément, et vous pouvez certainement le positionner. Dans ce cas, la réalisation de “Pixel Perfect” était un objectif très réel.

Cependant, le développement moderne est de plus en plus basé sur miles déclaratifs . Cela signifie que vous ne dites pas à l’ordinateur de “mettre ce bouton ici”, mais décrivez ce que vous voulez obtenir. Par exemple, au lieu d’indiquer les coordonnées spécifiques de l’élément, vous décrivez ses propriétés: “Ce bouton doit être rouge, avoir des indentations 16px de tous les côtés et être au centre du conteneur.” Freimvorki comme React, Vue, Swiftui ou Jetpack composent simplement ce principe.

Pourquoi “Pixel Perfect” ne fonctionne pas avec un mile déclaratif pour de nombreux appareils

Imaginez que vous créez une application qui devrait être tout aussi bonne sur l’iPhone 15 Pro Max, Samsung Galaxy Fold, iPad Pro et une résolution 4K. Chacun de ces appareils a une résolution d’écran différente, une densité de pixels, des parties et des tailles physiques.

Lorsque vous utilisez l’approche déclarative, le système lui-même décide comment afficher votre interface décrite sur un appareil particulier, en tenant compte de tous ses paramètres. Vous définissez les règles et les dépendances, pas les coordonnées sévères.

* Adaptabilité et réactivité: L’objectif principal des miles déclaratifs est de créer des interfaces adaptatives et réactives . Cela signifie que votre interface doit s’adapter automatiquement à la taille et à l’orientation de l’écran sans se casser et maintenir la lisibilité. Si nous cherchions à «Pixel parfait» sur chaque appareil, nous devions créer d’innombrables options pour la même interface, ce qui nivellera complètement les avantages de l’approche déclarative.
* densité de pixels (dpi / ppi): Les appareils ont une densité de pixels différente. Le même élément avec la taille de 100 pixels “virtuels” sur un appareil à haute densité sera beaucoup plus petit que sur un dispositif à faible densité, si vous ne prenez pas en compte la mise à l’échelle. Les cadres déclaratifs sont résumés par des pixels physiques, en travaillant avec des unités logiques.
* Contenu dynamique: Le contenu dans les applications modernes est souvent dynamique – son volume et sa structure peuvent varier. Si nous détendions durement les pixels, tout changement de texte ou d’image entraînerait “l’effondrement” de la mise en page.
* diverses plates-formes: En plus de la variété des appareils, il existe différents systèmes d’exploitation (iOS, Android, Web, Desktop). Chaque plate-forme a sa propre conception, ses commandes standard et ses polices. Une tentative de faire une interface parfaite absolument identique et parfaite sur toutes les plates-formes conduirait à un type non naturel et à une mauvaise expérience utilisateur.

Les anciennes approches n’ont pas disparu, mais ont évolué

Il est important de comprendre que l’approche des interfaces n’est pas un choix binaire entre “impératif” et “déclaratif”. Historiquement, pour chaque plate-forme, il y avait ses propres outils et approches de la création d’interfaces.

* Fichiers d’interface natif: Pour iOS, c’était XIB / storyboards, pour les fichiers de marquage Android-XML. Ces fichiers sont une disposition WYSIWYG parfaite avec pixel, qui est ensuite affichée à la radio comme dans l’éditeur. Cette approche n’a disparu nulle part, elle continue de se développer, s’intégrant à des cadres déclaratifs modernes. Par exemple, Swiftui dans Apple et Jetpack composent dans Android se déroulent sur le chemin d’un code purement déclaratif, mais en même temps, a conservé l’opportunité d’utiliser une disposition classique.
* Solutions hybrides: Souvent dans les projets réels, une combinaison d’approches est utilisée. Par exemple, la structure de base de l’application peut être mise en œuvre de manière déclarative et, pour un positionnement précis des éléments, des méthodes impératives de niveau inférieur peuvent être utilisées ou des composants natifs développés en tenant compte des spécificités de la plate-forme.

du monolithe à l’adaptabilité: comment l’évolution des appareils a formé un mile déclaratif

Le monde des interfaces numériques a subi d’énormes changements au cours des dernières décennies. Des ordinateurs stationnaires avec des permis fixes, nous sommes arrivés à l’ère de la croissance exponentielle de la variété des appareils utilisateur . Aujourd’hui, nos applications devraient fonctionner aussi bien sur:

* Smartphones de tous les facteurs de forme et tailles d’écran.
* tablettes avec leurs modes d’orientation uniques et un écran séparé.
* ordinateurs portables et ordinateurs de bureau avec divers permis de moniteurs.
* TVS et centres de médias , contrôlés à distance. Il est à noter que même pour les téléviseurs, dont les remarques peuvent être simples en tant que Apple TV Remote avec un minimum de boutons, ou vice versa, surchargée de nombreuses fonctions, les exigences modernes pour les interfaces sont telles que le code ne doit pas nécessiter une adaptation spécifique pour ces caractéristiques d’entrée. L’interface doit fonctionner “comme si elle-même”, sans une description supplémentaire de ce que “comment” interagir avec une télécommande spécifique.
* montres intelligentes et appareils portables avec des écrans minimalistes.
* Casques de réalité virtuelle (VR) , nécessitant une approche complètement nouvelle d’une interface spatiale.
* Dispositifs de réalité augmentés (AR) , appliquant des informations sur le monde réel.
* Informations automobiles et systèmes de divertissement .
* Et même appareils ménagers : des réfrigérateurs avec des écrans sensoriels et des machines à laver avec des écrans interactifs aux fours et systèmes intelligents de la maison intelligente.

Chacun de ces appareils a ses propres fonctionnalités uniques: dimensions physiques, rapport des parties, densité de pixels, méthodes d’entrée (écran tactile, souris, contrôleurs, gestes, commandes vocales) et, surtout, les subtilités de l’environnement utilisateur . Par exemple, un VR Shlesh nécessite une immersion profonde, et un travail rapide et intuitif pour les smartphones en déplacement, tandis que l’interface du réfrigérateur doit être aussi simple et grande pour une navigation rapide.

Approche classique: le fardeau de soutenir les interfaces individuelles

À l’ère de la domination des ordinateurs de bureau et des premiers appareils mobiles, l’activité habituelle était la création et la prise en charge de de fichiers d’interface individuels ou même un code d’interface complètement séparé pour chaque plate-forme .

* Développement sous iOS nécessite souvent l’utilisation de storyboards ou de fichiers XIB dans Xcode, en écrivant du code sur objectif-c ou Swift.
* Pour Android Les fichiers de marquage XML et le code sur Java ou Kotlin ont été créés.
* Les interfaces Web activées sur HTML / CSS / JavaScript.
* Pour les applications C ++ sur diverses plates-formes de bureau, leurs cadres et outils spécifiques ont été utilisés:
* Dans Windows il s’agissait de MFC (classes Microsoft Foundation), de l’API WIN32 avec des éléments de dessin manuel ou à l’aide de fichiers de ressources pour les fenêtres de dialogue et les éléments de contrôle.
* Le cacao (objectif-c / swift) ou l’ancienne API carbone pour le contrôle direct de l’interface graphique a été utilisé dans macOS .
* Dans Systems de type Linux / Unix , des bibliothèques comme GTK + ou QT ont souvent été utilisées, ce qui a fourni leur ensemble de widgets et de mécanismes pour créer des interfaces, souvent via des fichiers de marquage de type XML (par exemple, des fichiers .UI dans le concepteur QT) ou une création de logiciels directs d’éléments.

Cette approche a assuré un contrôle maximal sur chaque plate-forme, vous permettant de prendre en compte toutes ses caractéristiques spécifiques et ses éléments indigènes. Cependant, il a eu un énorme inconvénient: duplication des efforts et des coûts énormes de soutien . Le moindre changement de conception ou de fonctionnalité a nécessité l’introduction d’un droit à plusieurs bases de code indépendantes, en fait. Cela s’est transformé en un vrai cauchemar pour les équipes de développeurs, ralentissant la sortie des nouvelles fonctions et augmentant la probabilité d’erreurs.

Miles déclaratifs: une seule langue pour la diversité

C’est en réponse à cette complication rapide que les miles déclaratifs sont apparus comme le paradigme dominant. Les framws comme react, vue, swiftui, jetpack compose et d’autres ne sont pas seulement une nouvelle façon d’écrire du code, mais un changement fondamental dans la pensée.

L’idée principale de l’approche déclarative : Au lieu de dire que le système «comment» de dessiner chaque élément (impératif), nous décrivons «ce que« nous voulons voir (déclaratif). Nous définissons les propriétés et l’état de l’interface, et le cadre décide comment l’afficher au mieux sur un appareil particulier.

Cela est devenu possible grâce aux principaux avantages suivants:

1. L’abstraction des détails de la plate-forme: Les Fraimvorki déclaratifs sont spécialement conçus pour oublier les détails de bas niveau de chaque plate-forme. Le développeur décrit les composants et leurs relations à un niveau d’abstraction plus élevé, en utilisant un seul code transféré.
2. Adaptation et réactivité automatique: Freimvorki assumez la responsabilité de la mise à l’échelle automatique, de la mise en page et de l’adaptation des éléments en différentes tailles d’écrans, de densité de pixels et de méthodes d’entrée. Ceci est réalisé grâce à l’utilisation de systèmes de disposition flexibles, tels que Flexbox ou Grid, et des concepts similaires aux “pixels logiques” ou “DP”.
3. Cohérence de l’expérience utilisateur: Malgré les différences externes, l’approche déclarative vous permet de maintenir une seule logique de comportement et d’interaction dans toute la famille des appareils. Cela simplifie le processus de test et offre une expérience utilisateur plus prévisible.
4. Accélération du développement et réduction des coûts: Avec le même code capable de travailler sur de nombreuses plateformes, est considérablement réduit par le temps et le coût de développement et de soutien . Les équipes peuvent se concentrer sur la fonctionnalité et la conception, et non sur la réécriture répétée de la même interface.
5. Prépité pour l’avenir: La capacité de résumer des spécificités des appareils actuels rend le code déclaratif plus plus résistant à l’émergence de nouveaux types de dispositifs et de facteurs de forme . Freimvorki peut être mis à jour pour prendre en charge les nouvelles technologies, et votre code déjà écrit recevra ce support relativement transparent.

Conclusion

Le mile déclaratif n’est pas seulement une tendance de la mode, mais l’étape évolutive nécessaire causée par le développement rapide des appareils utilisateur, y compris la sphère l’Internet des objets (IoT) et les appareils de ménage intelligents. Il permet aux développeurs et aux concepteurs de créer des interfaces complexes, adaptatives et uniformes, sans se noyer dans des implémentations spécifiques sans fin pour chaque plate-forme. La transition du contrôle impératif de chaque pixel à la description déclarative de l’état souhaité est une reconnaissance que dans le monde des futures interfaces devrait être flexible, transféré et intuitif quel que soit l’écran qu’ils sont affichés.

Les programmeurs, les concepteurs et les utilisateurs doivent apprendre à vivre dans ce nouveau monde. Les détails supplémentaires du Pixel Perfect, conçu pour un appareil ou une résolution particulière, conduisent à des coûts de temps inutiles pour le développement et le support. De plus, de telles dispositions sévères peuvent tout simplement ne pas fonctionner sur des appareils avec des interfaces non standard, telles que les téléviseurs d’entrée limités, les changements VR et AR, ainsi que d’autres appareils du futur, que nous ne connaissons même pas aujourd’hui. Flexibilité et adaptabilité – Ce sont les clés de la création d’interfaces réussies dans le monde moderne.

Pourquoi les programmeurs ne font-ils rien même avec les réseaux de neurones

Aujourd’hui, les réseaux de neurones sont utilisés partout. Les programmeurs les utilisent pour générer du code, expliquer d’autres solutions, automatiser les tâches de routine et même créer des applications entières à partir de zéro. Il semblerait que cela entraîne une augmentation de l’efficacité, réduisant les erreurs et l’accélération du développement. Mais la réalité est beaucoup plus prosaïque: beaucoup ne réussissent toujours pas. Les réseaux de neurones ne résolvent pas les problèmes clés – ils n’éclairent que la profondeur de l’ignorance.

Dépendance complète sur LLM au lieu de comprendre

La raison principale est que de nombreux développeurs comptent complètement sur LLM, ignorant la nécessité d’une compréhension approfondie des outils avec lesquels ils travaillent. Au lieu d’étudier la documentation – une demande de chat. Au lieu d’analyser les raisons de l’erreur – copier la décision. Au lieu de solutions architecturales – la génération de composants selon la description. Tout cela peut fonctionner à un niveau superficiel, mais dès qu’une tâche non standard survient, l’intégration avec un vrai projet ou le besoin d’un réglage fin est nécessaire, tout s’effondre.

manque de contexte et pratiques obsolètes

Les réseaux de neurones génèrent le code généralisé. Ils ne prennent pas en compte les spécificités de votre plate-forme, de votre version des bibliothèques, des restrictions environnementales ou des solutions architecturales du projet. Ce qui est généré semble souvent plausible, mais n’a rien à voir avec le code réel et pris en charge. Même des recommandations simples peuvent ne pas fonctionner si elles appartiennent à la version obsolète du cadre ou utilisent des approches qui ont longtemps été reconnues comme inefficaces ou dangereuses. Les modèles ne comprennent pas le contexte – ils dépendent des statistiques. Cela signifie que les erreurs et les antipattères, populaires en code ouvert, seront reproduits encore et encore.

Redondance, inefficacité et manque de profilage

L’IA générée par le code est souvent redondante. Il comprend des dépendances inutiles, des doublons la logique, ajoute des abstractions inutilement. Il s’avère une structure lourde inefficace qui est difficile à soutenir. Ceci est particulièrement aigu dans le développement mobile, où la taille du gang, le temps de réponse et la consommation d’énergie sont essentielles.

Le réseau neuronal ne mène pas le profilage, ne prend pas en compte les restrictions du CPU et du GPU, ne se soucie pas des fuites de mémoire. Il n’analyse pas l’efficacité du code en pratique. L’optimisation est toujours faite à la main, nécessitant une analyse et un examen. Sans cela, l’application devient lente, instable et à forte intensité de ressources, même si elle semble «correcte» du point de vue de la structure.

Vulnérabilité et menace pour la sécurité

N’oubliez pas la sécurité. Il existe déjà des cas connus lorsque les projets sont partiellement ou entièrement créés à l’aide de LLM ont été piratés avec succès. Les raisons sont typiques: l’utilisation de fonctions dangereuses, le manque de vérification des données d’entrée, les erreurs dans la logique de l’autorisation, la fuite à travers des dépendances externes. Le réseau neuronal peut générer un code vulnérable simplement parce qu’il a été trouvé dans les référentiels ouverts. Sans la participation de spécialistes de la sécurité et une révision complète, de telles erreurs deviennent facilement des points d’entrée pour les attaques.

La loi est Pareto et l’essence des défauts

La loi de Pareto travaille clairement avec les réseaux de neurones: 80% du résultat est obtenu en raison de 20% des efforts. Le modèle peut générer une grande quantité de code, créer la base du projet, répartir la structure, organiser des types, connecter les modules. Cependant, tout cela peut être dépassé, incompatible avec les versions actuelles des bibliothèques ou des cadres, et nécessite une révision manuelle importante. L’automatisation ici fonctionne plutôt comme un projet qui doit être vérifié, traité et adapté à des réalités spécifiques du projet.

Optimisme de mise en garde

Néanmoins, l’avenir semble encourageant. Mise à jour constante des ensembles de données de formation, intégration avec la documentation actuelle, vérification de l’architecture automatisée, conformité à la conception et aux modèles de sécurité – tout cela peut radicalement modifier les règles du jeu. Peut-être que dans quelques années, nous pouvons vraiment écrire le code plus rapidement, plus sûr et plus efficacement, en nous appuyant sur LLM en tant que co-auteur technique. Mais pour l’instant – hélas – il faut vérifier, réécrit et modifié manuellement.

Les réseaux de neurones sont un outil puissant. Mais pour qu’il travaille pour vous, et non contre vous, vous avez besoin d’une base, de la pensée critique et de la volonté de prendre le contrôle à tout moment.

Windows prototype de Gingerrita

Je présente à votre éditeur de texte Kate Fork Kate appelé Gingerrita. Pourquoi Fork, pourquoi, quel est l’objectif? Je veux ajouter la fonctionnalité dont j’ai besoin dans mon travail, afin de ne pas attendre la correction, d’ajouter des fonctionnalités de l’équipe Kate ou de l’adoption de mes corrections à la branche principale.
Pour le moment, une version prototype de Windows est actuellement disponible, presque vanille de Kate avec des modifications minimales. Pour Gingerita, j’ai développé deux plugs – une image des images directement de l’éditeur et du navigateur intégré, pour déboguer mes projets Web ou pour interagir avec l’IA avec des assistants tels que ChatGpt.

La version de Windows peut être testée par le lien ci-dessous:
https://github.com/demensdeum/Gingerita/releases/tag/prototype

Prise en charge des produits Demensdeum

Bienvenue sur la page d’assistance!

Si vous avez des questions, des problèmes avec les produits Demensdeum ou si vous souhaitez offrir des améliorations, nous sommes toujours prêts à vous aider.

Comment nous contacter:
support@demensdeum.com

Nous essayons de répondre aux appels dans les 3 à 5 jours ouvrables.

Quoi indiquer dans la lettre:

Le nom du produit
Version (si connu)
Une description détaillée du problème
Captures d’écran ou vidéos (si possible)
Dispositif et système d’exploitation sur lequel le problème s’est posé

Nous vous remercions pour l’utilisation de nos produits et nous nous efforçons de rendre votre expérience aussi pratique et agréable que possible.

Sincèrement,
Équipe Demensdeum

Astuces de core de vibration: pourquoi LLM ne fonctionne toujours pas avec un solide, sec et propre

Avec le développement de modèles de grandes langues (LLM), tels que Chatgpt, de plus en plus de développeurs les utilisent pour générer du code, une architecture de conception et une intégration accélérée. Cependant, avec une application pratique, elle devient perceptible: les principes classiques de l’architecture – solide, sec, propre – s’entendent mal avec les particularités de la codgendation LLM.

Cela ne signifie pas que les principes sont obsolètes – au contraire, ils fonctionnent parfaitement avec le développement manuel. Mais avec LLM, l’approche doit être adaptée.

Pourquoi LLM ne peut pas faire face aux principes architecturaux

Encapsulation

L’incapsulation nécessite de comprendre les frontières entre parties du système, des connaissances sur les intentions du développeur, ainsi que des restrictions d’accès strictes. LLM simplifie souvent la structure, rend les champs publics sans raison ou dupliquent la mise en œuvre. Cela rend le code plus vulnérable aux erreurs et viole les limites architecturales.

Résumé et interfaces

Les modèles de conception, tels qu’une usine abstraite ou une stratégie, nécessitent une vision holistique du système et la compréhension de sa dynamique. Les modèles peuvent créer une interface sans objectif clair sans assurer sa mise en œuvre ou violer la connexion entre les couches. Le résultat est une architecture excessive ou non fonctionnelle.

sec (donolt répétez-vous)

LLM ne cherchez pas à minimiser le code de répétition – au contraire, il leur est plus facile de dupliquer des blocs que de faire une logique générale. Bien qu’ils puissent offrir une refactorisation sur demande, par défaut, les modèles ont tendance à générer des fragments «auto-suffisants», même si cela conduit à une redondance.

Architecture propre

Clean implique une hiérarchie stricte, une indépendance des cadres, une dépendance dirigée et une connectivité minimale entre les couches. La génération d’une telle structure nécessite une compréhension globale du système – et du travail LLM au niveau de la probabilité de mots, et non de l’intégrité architecturale. Par conséquent, le code est mitigé, avec violation des directions de dépendance et une division simplifiée en niveaux.

ce qui fonctionne mieux lorsque vous travaillez avec LLM


Mouillé au lieu de sec
L’approche humide (écrivez tout deux fois) est plus pratique pour travailler avec LLM. La duplication du code ne nécessite pas de contexte du modèle de rétention, ce qui signifie que le résultat est prévisible et est plus facile à corriger correctement. Il réduit également la probabilité de connexions et de bogues non évidents.

De plus, la duplication aide à compenser la mémoire courte du modèle: si un certain fragment de logique se trouve à plusieurs endroits, LLM est plus susceptible de le prendre en compte avec une génération plus approfondie. Cela simplifie l’accompagnement et augmente la résistance à “l’oubli”.

Structures simples au lieu de l’encapsulation

Éviter l’encapsulation complexe et s’appuyer sur la transmission directe des données entre les parties du code, vous pouvez considérablement simplifier à la fois la génération et le débogage. Cela est particulièrement vrai avec un développement itératif rapide ou une création de MVP.

Architecture simplifiée

Une structure simple et plate du projet avec une quantité minimale de dépendances et d’abstractions donne un résultat plus stable pendant la génération. Le modèle adapte un tel code plus facile et moins souvent viole les connexions attendues entre les composants.

Intégration du SDK – fiable manuellement

La plupart des modèles linguistiques sont formés sur des versions obsolètes de la documentation. Par conséquent, lors de la génération d’instructions pour l’installation du SDK, les erreurs apparaissent souvent: commandes obsolètes, paramètres non pertinents ou liens vers des ressources inaccessibles. La pratique montre: il est préférable d’utiliser la documentation officielle et le réglage manuel, laissant LLM un rôle auxiliaire – par exemple, générer un code de modèle ou une adaptation des configurations.

Pourquoi les principes fonctionnent-ils toujours – mais avec le développement manuel

Il est important de comprendre que les difficultés de solides, sèches et propres concernent la codhégénération par LLM. Lorsque le développeur écrit le code manuellement, ces principes continuent de démontrer leur valeur: ils réduisent la connectivité, simplifient le soutien, augmentent la lisibilité et la flexibilité du projet.

Cela est dû au fait que la pensée humaine est sujette à la généralisation. Nous recherchons des modèles, nous apportons une logique répétitive dans des entités individuelles, créons des modèles. Ce comportement a probablement des racines évolutives: la réduction de la quantité d’informations permet d’économiser des ressources cognitives.

LLM agit différemment: ils ne ressentent pas de charges du volume de données et ne visent pas d’économies. Au contraire, il leur est plus facile de travailler avec des informations fragmentées en double que de construire et de maintenir des abstractions complexes. C’est pourquoi il leur est plus facile de faire face au code sans encapsulation, avec des structures répétitives et une gravité architecturale minimale.

Conclusion

Les modèles de grandes langues sont un outil utile en développement, en particulier dans les premiers stades ou lors de la création d’un code auxiliaire. Mais il est important de s’adapter à l’approche: pour simplifier l’architecture, limiter l’abstraction, éviter les dépendances complexes et ne pas compter sur eux lors de la configuration du SDK.

Les principes du solide, du sec et de la propreté sont toujours pertinents, mais ils donnent le meilleur effet entre les mains d’une personne. Lorsque vous travaillez avec LLM, il est raisonnable d’utiliser un style simplifié et pratique qui vous permet d’obtenir un code fiable et compréhensible qui est facile à finaliser manuellement. Et où LLM oublie – la duplication du code l’aide à se souvenir.

Demens TV Heads NFT

Je veux partager ma nouvelle collection NFT «Demens TV Heads».

Il s’agit d’une série d’œuvres d’art numériques, ils reflètent des personnes de personnages et de professions différents, dans le style du logo Demensdeum.
Le premier travail est féroce “Grozny” Il s’agit d’un auto-portrait stylisé.

Je prévois de libérer seulement 12 NFT, un chaque mois chaque mois.

Chaque travail existe non seulement dans la blockchain Ethereum, mais est également disponible sur le site Web Demensdeum et dans les routes GitHub, avec Metadan.

Si vous êtes intéressé, voyez ou évaluez simplement visuellement, je serai heureux:
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

Super programmeur

Qui est-il – ce super programmeur mystérieux, éphémère, presque mythique? Une personne dont le code est compilé la première fois est lancée à partir de demi-tike et entre immédiatement dans le prod. La légende a transmis en octets de Senor à Jun. Celui qui écrit des bugs spécifiquement pour que les autres ne s’ennuient pas. Honnêtement, avec la chaleur et l’ironie, nous verrons quels superpuissances il doit avoir pour porter ce manteau numérique.

1. Écrit sur C / C ++ sans vulnérabilité unifiée
Débordement de tampon? Jamais entendu parler de cela.
Le super programmeur en C ++ n’a pas de variables gênantes – elles sont elles-mêmes initialisées à partir du respect. Il écrit un nouveau char [256], et le compilateur ajoute silencieusement un contrôle des frontières. Là où d’autres ont mis un point de rupture – il regarde. Et le bug disparaît.

2. Écrit les fiches sans bugs et tests
Il n’a pas besoin de tests. Son code se teste la nuit quand il dort (bien que … dort-il?). Toute ligne est une version stable finale, immédiatement avec le support de 12 langues et le niveau accessible de la NASA. Et si le bogue a toujours rencontré, alors l’univers le teste.

3. Cela fonctionne plus vite que l’IA
Alors que Chatgpt imprime «Quelle bonne question!», Le super programmeur a déjà verrouillé le nouveau système d’exploitation, l’a porté sur le grille-pain et a tout documenté dans Markdown avec des diagrammes. Il ne demande pas à Stackoverflow – il le soutient avec ses questions du futur. GPT étudie sur ses communautés.

4. Il comprend mieux le code de quelqu’un d’autre que l’auteur
“Bien sûr, je l’ai écrit … mais je ne comprends pas comment ça marche.” – un auteur ordinaire.
“Oh, cela est dû à l’appel récursif à la ligne 894, qui est lié à l’effet secondaire dans le filtre regex. Smart.” – Super programmeur sans clignoter.
Il lit Perl sur la première tentative, comprend les abréviations dans les noms des variables et les bugs capturent par vibration du curseur.

5. Écrit le code de la plate-forme croisée sur l’assembleur
Pourquoi écrire sur Rust, si possible sur Pure X86, ARM et RISC-V tout de suite, avec un drapeau “fonctionne partout”? Il a sa propre table des opodes. Même le processeur pense avant de gâcher ses instructions. Il n’optimise pas – il transcende.

6. Il répond aux questions sur les délais jusqu’à une seconde
“Quand sera-t-il prêt?”
“Après 2 heures, 17 minutes et 8 secondes. Et oui, cela prend en compte les insectes, une pause de fumée et une question philosophique dans le chat.”
Si quelqu’un demande à faire plus rapidement, il reconstruit simplement l’espace-temps via des jives.

7. Doches et réparation des cadres propriétaires
Le SDK propriétaire est tombé, API sans documentation, tout est chiffré par Base92 et toux de Segfault? Pour un super programmeur, c’est un mardi ordinaire. Il ouvrira un hex binaire, inhale, et une heure plus tard, il y aura un patch avec une correction, des améliorations des performances et un mode sombre ajouté.

8. Designer et spécialiste UX pour lui-même
L’interface utilisateur sort pour lui que les gens pleurent de beauté, et les boutons sont devinés par intuition. Même les chats se comportent – vérifié. Il ne dessine pas d’interface – il ouvre son essence intérieure, comme un sculpteur en marbre. Chaque presse est ravie.

9. mène des recherches marketing entre commits
Entre Git Push et le café, il parvient à collecter l’analyse du marché, à construire un entonnoir de vente et à repenser la stratégie de monétisation. Le week-end, teste les hypothèses. Il a des tests A / B est lancé automatiquement lorsqu’il ouvre un ordinateur portable.

10. Répondre Microsoft seul
Cela pour les sociétés de 10 ans et mille ingénieurs, pour lui – vendredi soir et bonne pizza. Windows 11? Windows 12. Office? Déjà là. Exceller? Il travaille sur la gestion des voix et aide à planifier des vacances. Tout fonctionne mieux et pèse moins.

11. Déplient et soutient les infrastructures pour 1 million d’utilisateurs
Son NAS fait maison est une calibre Kubernetes. Surveillance? Grafana avec des mèmes. Il déploie l’API plus rapidement que certains parviennent à ouvrir un facteur. Il a tout documenté, automatisé et de manière fiable comme une théière soviétique.

12. Le support technique n’est pas requis
Les utilisateurs n’en plaignent pas. Ils l’utilisent simplement avec révérence. FAQ? Pas nécessaire. Tutoriels? L’intuition le dira. Il est le seul développeur qui a le bouton “Aide” à la page de gratitude.

13. Il ne dort pas, ne mange pas, n’est pas distrait
Il se nourrit de caféine et d’un pur désir d’écrire un code. Au lieu de dormir, refactoring. Au lieu de manger – des forfaits Debian. Son cycle de vie est un cycle de développement continu. CI / CD n’est pas un pipeline, c’est un style de vie.

14. Communique avec les clients sans douleur
“Nous devons faire Uber, mais seulement mieux, dans deux jours.” – “Regardez: voici la feuille de route, voici les risques, voici le MVP. Et nous décidons d’abord des objectifs.”
Il sait dire non “afin que le client répond:” Merci, maintenant je comprends ce que je veux. ”

15. Programmes instantanément les réacteurs nucléaires
Combien de chaleur est libérée lorsque le noyau d’uranium est divisé? Le Super-Programmer le sait. Et il sait comment le voler dans Rust, C, Swift, même à Excel. Son réacteur n’est pas seulement sûr – il est également mis à jour par OTA.

16. A des connaissances dans tous les domaines possibles
Philosophie, physique, reportage fiscal de la Mongolie – tout dans sa tête. Il participe à des quiz, où il est un leader. S’il ne sait pas quelque chose, il a simplement éteint temporairement la mémoire pour faire de la place pour de nouvelles connaissances. Maintenant, il reviendra.

17. Connaît tous les algorithmes et les modèles de conception
Pas besoin de lui expliquer comment fonctionne un *, dijkstra ou singleton. Il est venu avec eux. Avec lui, les modèles se comportent correctement. Même les antipattères sont corrigées elles-mêmes – de la honte.

18. A travaillé à Apple, Google et en ennui gauche
Il était partout: Apple, Google, NASA, IKEA (testé l’interface de l’armoire). Ensuite, j’ai réalisé que c’était déjà trop bon et je suis allé développer des projets open source gratuits pour le plaisir. Il n’a pas besoin d’argent parce que:

19. Il a Pontid Bitcoin et il est Satoshi Nakamoto
Oui, c’est lui. Ne dit pas. Tous les portefeuilles avec des millions de BTC sont en fait sur son lecteur flash, mural en béton. En attendant, il écrit Backend pour une coopérative d’agriculteurs dans l’Outback, car “c’était intéressant d’essayer Kotlin Multiplateform”.

Conclusion: un peu de sérieux
En fait, les programmeurs sont des gens ordinaires.
Nous nous trompons. Nous sommes fatigués. Parfois, nous sommes tellement confiants en nous-mêmes que nous ne voyons pas l’évidence – et c’est alors que les erreurs les plus chères de l’histoire sont commises.

Par conséquent, il convient de se rappeler:

* Il est impossible de tout savoir – mais il est important de savoir où chercher.
* Travailler dans une équipe n’est pas une faiblesse, mais un chemin vers une meilleure décision.
* Les outils qui nous protègent ne sont pas des «béquilles», mais une armure.
* Demandez est normal. Douter est juste. Faire des erreurs est inévitable. L’apprentissage est nécessaire.
* L’ironie est notre bouclier. Le code est notre arme. La responsabilité est notre boussole.

Et les légendes sur un super-programmeur sont un rappel que nous nous efforçons parfois tous pour l’impossible. Et c’est précisément dans ce domaine de la magie de programmation.

Pourquoi la documentation est votre meilleur ami

(Et comment ne pas être un gourou dont les conseils cessent de travailler après la mise à jour)

“Les applications ne peuvent utiliser que des API publiques et doivent fonctionner sur le système d’exploitation actuellement expédié.” Lignes directrices sur la revue des applications Apple

Si vous avez déjà commencé à travailler avec un nouveau cadre et que vous vous êtes surpris à penser: “Maintenant, je comprendrai tout, la documentation est pour les alésages” – vous n’êtes certainement pas seul. De nombreux développeurs ont un instinct naturel: d’abord, et seulement alors – lisez. C’est bien.

Mais c’est à ce stade que vous pouvez facilement désactiver la bonne voie et vous retrouver dans une situation où le code fonctionne … mais seulement aujourd’hui, et seulement “j’ai”.

Pourquoi est-il facile de «le comprendre» – n’est-ce pas suffisant?

Freimvorki, en particulier fermé et propriétaire, est complexe et multi-réparties. Ils ont beaucoup de fonctionnalités de logique, d’optimisation et de mise en œuvre cachées, qui:

* Non documenté;
* non garanti;
* peut changer à tout moment;
* sont un secret commercial et peuvent être protégés par des brevets
* Contient des bugs, des défauts connues uniquement des développeurs du cadre.

Lorsque vous agissez “sur une intuition”, vous pouvez facilement construire une architecture dans des observations aléatoires, au lieu du support sur les règles clairement décrites. Cela conduit au fait que le code devient vulnérable aux mises à jour et aux cas de bord.

La documentation n’est pas une restriction, mais le support

Les développeurs de cadres créent des manuels pour une raison – il s’agit d’un accord entre vous et eux. Pendant que vous agissez dans le cadre de la documentation, ils promettent:

* stabilité;
* soutien;
* Comportement prévisible.

Si vous allez au-delà de ce cadre – tout ce qui se passe ensuite devient exclusivement votre responsabilité.

Expériences? Certainement. Mais dans le cadre des règles.
La curiosité est la super-via du développeur. Explorez, essayez les limites de test non standard – tout cela est nécessaire. Mais il y a un “mais” important:

Vous devez expérimenter dans le cadre de la documentation et des meilleures pratiques.

La documentation n’est pas une prison, mais une carte. Elle montre quelles opportunités sont vraiment planifiées et soutenues. Ce sont de telles expériences qui sont non seulement utiles, mais aussi sûres.

ATTENTION: Guru

Parfois, vous pouvez rencontrer de vrais “experts”:

* Ils organisent des cours
* Percer aux conférences,
* Écrivez des livres et des blogs,
* a partagé “leur approche” du cadre.

Mais même s’ils semblent convaincants, il est important de se rappeler:
Si leurs approches sont contraires à la documentation, elles sont instables.

Ces «modèles empiriques» peuvent:

* Travaillez uniquement sur une version spécifique du cadre;
* être vulnérable aux mises à jour;
* Break dans des situations imprévisibles.

Le gourou est cool lorsqu’ils respectent les manuels. Sinon, leurs conseils doivent être filtrés grâce à la documentation officielle.

un peu solide

Trois idées de principes solides sont particulièrement pertinents ici:

* Principe ouvert / fermé: élargir le comportement via une API publique, n’entrez pas à l’intérieur.
* Principe de la substance Liskov: ne comptez pas sur la mise en œuvre, comptez sur le contrat. Troubles – Tout va se casser lors du remplacement de la mise en œuvre.
* Inversion de dépendance: les modules de niveau élevé ne doivent pas dépendre de modules de niveau bas. Les deux types devraient dépendre d’abstractions. L’abstraction ne devrait pas dépendre des détails. Les détails devraient dépendre d’abstractions.

Qu’est-ce que cela signifie dans la pratique? Si vous utilisez un cadre et directement lié à ses détails internes – vous violez ce principe.
Au lieu de cela, vous devez renforcer la dépendance à l’égard des interfaces publiques, des protocoles et des contrats que le cadre soutient officiellement. Cela donne:

* La meilleure isolement de votre code à partir des modifications du cadre;
* La capacité de tester et de remplacer facilement les dépendances;
* Comportement prévisible et stabilité de l’architecture.

Lorsque votre code dépend des détails et non des abstractions, vous vous intégrez littéralement dans une implémentation spécifique qui peut disparaître ou changer à tout moment.

et si le bug?

Parfois, il arrive que vous ayez tout fait correctement, mais cela fonctionne mal. Cela se produit – les cadres ne sont pas parfaits. Dans ce cas:

* Rassemblez un exemple minimum reproduit.
* Assurez-vous d’utiliser uniquement l’API documentée.
* Envoyer un bug-port-ils vous comprendront certainement et, très probablement, vous aideront.

Si l’exemple est construit sur des hacks ou des contournements, les développeurs ne sont pas tenus de le soutenir, et très probablement votre cas manquera simplement.

comment serrer le maximum du cadre

* Lisez la documentation. Sérieusement.
* Suivez les guides et recommandations des auteurs.
* Expérience – mais dans le décrit.
* Vérifiez les conseils (même les haut-parleurs les plus célèbres!) À travers le manuel.
* Pliez des insectes avec un minimum de cas et du respect du contrat.

Conclusion

Freimvorki ne sont pas des boîtes noires, mais des outils qui ont les règles d’utilisation. Les ignorer signifie écrire le code “au hasard”. Mais nous voulons que notre code vive pendant longtemps, ravit les utilisateurs et ne se détache pas de la mise à jour mineure.

Donc: faites confiance, mais vérifiez. Et oui, lisez les manuels. Ils sont votre superpuissance.

Sources

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

Cube Art Project 2

Meet – Cube Art Project 2

La deuxième version de l’éditeur de station, entièrement réécrite sur Pure JavaScript sans WebAssembly.
Léger, rapide et commence directement dans le navigateur – rien de plus.

Ceci est une expérience: cubes, couleur, liberté et une petite géométrie 3D méditative.
Vous pouvez modifier les couleurs à l’aide de RVB-Sloders, Enregistrer et charger des scènes, se déplacer dans l’espace et simplement jouer.

Contrôle:
– wasd – déplacer la caméra
– Mouse – Rotation
– GUI – Paramètres de couleur

En ligne:
https://demensdeum.com/software/cube-art-project-2/

Sources sur github:
https://github.com/demensdeum/cube-art-project-2

Le projet est écrit sur Pure JavaScript en utilisant trois.js.
Sans frameworks, sans collectionneurs, sans webassembly – seulement Webgl, shaders et un peu d’amour pour la géométrie des pixels.

Les scènes peuvent être enregistrées et chargées – créez vos mondes, sauf en JSON, partagez ou retournez plus tard dans le raffinement.

Docker Safety: Pourquoi le lancement de Root est-il une mauvaise idée

Docker est devenu un outil indispensable dans les DevOps et le développement modernes. Il vous permet d’isoler l’encerclement, de simplifier la tenue et de mettre à l’échelle rapidement les applications. Cependant, par défaut, Docker a besoin d’une racine, ce qui crée une zone potentiellement dangereuse, qui est souvent ignorée dans les premiers stades.

Pourquoi Docker fonctionne-t-il à Root?

Docker utilise les capacités du Linux: CGroups, des espaces de noms, des iptables, du mont, de la mise en réseau et d’autres fonctions système. Ces opérations ne sont disponibles que pour le super utilisateur.

C’est pourquoi:
* Dockerd Demon commence à partir de la racine,
* Les commandes Docker sont transmises à ce démon.

Cela simplifie le travail et donne un contrôle total sur le système, mais en même temps, il ouvre des vulnérabilités potentielles.

Pourquoi est-il dangereux: Breakout de conteneurs, CVE, RCE

Breakout de conteneur

Avec une isolation faible, un attaquant peut utiliser Chroot ou Pivot_Root pour entrer l’hôte.

Exemples d’attaques réelles:

* CVE-2019-5736-Vulnérabilité à Runc, autorisé à réécrire l’application et à exécuter le code sur l’hôte.
* CVE-2021-3156-Vulnérabilité à Sudo, autorisé à obtenir une racine à l’intérieur du conteneur et à sortir.

RCE (exécution de code distant)

Si l’application dans le conteneur est vulnérable et commence à partir de root, RCE = contrôle complet sur l’hôte.

docker sans racine: solution du problème

Pour minimiser ces risques, le mode sans racine est apparu dans Docker. Dans ce mode, le démon et les conteneurs sont lancés au nom de l’utilisateur habituel, sans aucune privialité racine. Cela signifie que même si un attaquant reçoit le contrôle du conteneur, il ne pourra pas nuire au système hôte.
Il y a des restrictions: vous ne pouvez pas utiliser les ports inférieurs à 1024 (par exemple, 80 et 443), le mode priviled, ainsi que certains modes de réseau, n’est pas disponible. Cependant, dans la plupart des scénarios de développement et Docker sans racine CI / CD, il fait face à sa tâche et augmente considérablement le niveau de sécurité.

Historiquement, lancez à partir de Root – Antipattern

Dès le début, le principe des plus petits privilèges a été appliqué dans le monde Unix / Linux. Moins les droits du processus sont moins élevés, moins il peut faire de mal. Docker a initialement exigé un accès root, mais aujourd’hui, il est considéré comme une menace potentielle.

Sources

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

Le problème non évident des conteneurs Docker: Vulnérabilités cachées

Le problème non évident des conteneurs Docker: Vulnérabilités cachées

Qu’est-ce que “Enfer endensky” (DH)?

“Dependency Hell” (DH) est un terme indiquant un problème qui se pose lors de la gestion des dépendances dans le logiciel. Ses principales raisons sont dans le conflit de versions, les difficultés d’intégrer diverses bibliothèques et la nécessité de maintenir la compatibilité entre eux. DH comprend les aspects suivants:

– Conflits de versions: les projets nécessitent souvent des versions spécifiques de bibliothèques, et les différents composants peuvent dépendre de versions incompatibles de la même bibliothèque.
– Difficultés de mises à jour: la mise à jour des dépendances peut entraîner des erreurs inattendues ou une rupture de compatibilité, même si une nouvelle version contient des corrections ou des améliorations.
– L’environnement: Le désir d’isoler et de stabiliser l’environnement a conduit à l’utilisation d’environnements virtuels, de conteneurisation et d’autres solutions visant à simplifier la gestion de la dépendance.

Il est important de noter que bien que l’élimination des vulnérabilités soit l’une des raisons de la publication des versions mises à jour des bibliothèques, ce n’est pas la principale force motrice de DH. Le principal problème est que chaque changement – qu’il s’agisse de corriger les bogues, d’ajouter une nouvelle fonctionnalité ou d’éliminer la vulnérabilité – peut provoquer une chaîne de dépendances qui compliquent le développement stable et le support de l’application.

Comment la lutte contre DH a-t-elle conduit à la création de Docker?

Dans une tentative de résoudre les problèmes DH, les développeurs cherchaient des moyens de créer un environnement isolé et stable pour les applications. Docker a été une réponse à ce défi. La conteneurisation permet:

– Isoler l’environnement: toutes les dépendances et bibliothèques sont emballées avec l’application, qui garantit un travail stable partout où Docker est installé.
– Simplifier le déploiement: le développeur peut une fois configurer l’environnement et l’utiliser pour se déployer sur des serveurs sans paramètres supplémentaires.
– Minimiser les conflits: Étant donné que chaque application fonctionne dans son propre conteneur, le risque de conflits entre les dépendances de divers projets est considérablement réduit.

Ainsi, Docker a proposé une solution efficace pour lutter contre le problème DH, permettant aux développeurs de se concentrer sur la logique de l’application et non sur les difficultés de configuration de l’environnement.

Le problème des dépendances obsolètes dans Docker

Malgré tous les avantages de Docker, une nouvelle direction des problèmes est apparue – l’obsolescence des dépendances. Cela se produit pour plusieurs raisons:

1. Le conteneur se fige dans le temps

Lors de la création d’une image Docker, un certain état de tous les packages et bibliothèques est corrigé. Même si après assemblage dans l’image de base (par exemple, `Ubuntu: 04.20,` Python: 3.9`, `Node: 18-Alpine`), des vulnérabilités sont trouvées ou de nouvelles versions sont produites, le conteneur continue de fonctionner avec les versions initialement installées. Si l’image ne doit pas être envoyée, l’application peut fonctionner avec des composants obsolètes et potentiellement vulnérables pendant des années.

2. Manque de mises à jour automatiques

Contrairement aux serveurs traditionnels, où vous pouvez configurer la mise à jour des packages automatiques via les gestionnaires système (par exemple, `APT Updgrade` ou« NPM Update »), les conteneurs ne sont pas mis à jour automatiquement. La mise à jour ne se produit que lors de l’élection de l’image, qui nécessite une discipline et un contrôle régulier.

3. Dépendances fixes

Pour garantir la stabilité, les développeurs corrigent souvent la version des dépendances dans des fichiers comme `redirements.txt` ou« package.json`. Cette approche empêche les changements inattendus, mais gèle en même temps l’état des dépendances, même si des erreurs ou une vulnérabilité sont détectées par la suite.

4. en utilisant des images de base obsolètes

Les images de base sélectionnées pour les conteneurs peuvent également être obsolètes au fil du temps. Par exemple, si l’application est construite sur l’image de «Node: 16», et que les développeurs sont déjà passés au «nœud: 18» en raison d’améliorations et de corrections, votre environnement restera avec une version obsolète, même si tout fonctionne correctement à l’intérieur du code.

Comment éviter les problèmes de dépendances obsolètes?

Inclure des inspections régulières pour les dépendances et vulnérabilités obsolètes dans le processus CI / CD:

– pour Python:

pip list --outdated

– pour node.js:

npm outdated

– Utilisez des outils pour analyser les vulnérabilités, par exemple, «TRIVY»:

trivy image my-app

Surveillez les mises à jour des images de base

Abonnez-vous aux mises à jour des images de base dans Docker Hub ou des référentiels correspondants sur GitHub afin de découvrir en temps opportun les corrections et les mises à jour critiques.

Conclusion

Le problème de l’enfer de dépendance est survenu non seulement en raison de la nécessité d’éliminer la vulnérabilité, mais aussi en raison de difficultés à gérer et à mettre à jour les dépendances. Docker a proposé une solution efficace pour lutter contre la DH, fournissant un environnement isolé et stable pour les applications. Cependant, avec l’avènement de la conteneurisation, une nouvelle tâche est survenue – la nécessité d’un renouvellement régulier des images afin d’empêcher l’obsolescence des dépendances et l’apparition d’une vulnérabilité critique.

Il est important pour les spécialistes modernes de DevOps non seulement de résoudre les problèmes de conflits de versions, mais aussi d’introduire régulièrement et automatisé les pratiques de contrôle pour la pertinence des dépendances afin que les conteneurs restent sûrs et efficaces.

Modèle du générateur: en phase de création d’un objet dans le temps

Introduction

Le dernier article a examiné le cas général de l’utilisation du motif du constructeur, mais l’option n’a pas été touchée lorsque l’objet est créé par étapes dans le temps.
Builder Pattern (Builder) est un modèle de conception générateur qui vous permet de créer progressivement des objets complexes. Il est particulièrement utile lorsque l’objet a de nombreux paramètres ou diverses configurations. L’un des exemples intéressants de son utilisation est la possibilité de séparer le processus de création d’un objet dans le temps.
Parfois, l’objet ne peut pas être créé immédiatement – ses paramètres peuvent être connus à différentes étapes du programme.

Un exemple sur Python

Dans cet exemple, l’objet de la voiture est créé par étapes: d’abord, une partie des données est chargée à partir du serveur, puis l’utilisateur entre les informations manquantes.

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)

Imaginez un appel API, la saisie de données se produit dans différentes parties de l’application, ou même dans différentes bibliothèques. Ensuite, l’utilisation du motif du constructeur devient plus évidente que dans un exemple simple ci-dessus.

Avantages

– La sortie est une structure immunitaire qui n’a pas besoin de stocker des données facultatives pour l’assemblage temporaire
– L’objet est collecté progressivement
– Éviter des concepteurs complexes
– Le code d’assemblage de l’objet n’est pas incompétent uniquement dans une essence de constructeur
– commodité de comprendre le code

Sources

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

Défi de codage Demensdeum # 1

Commencer Demensdeum Coding Challenge # 1
Prix ​​100 USDT
1. Nous devons écrire des photos de rendu pour Windows 11 64 bits
2. Rendre
https://demensdeum.com/logo/demens1.png
3. L’image doit être intégrée dans l’application
4. API graphique – Direct3d ou DirectDraw
5. gagne que la demande s’est avérée être la plus petite taille en octets
6. L’image doit être de 1 sur 1 positif comme original, enregistrez les couleurs
7. Tous les langues / camers ne nécessitent pas d’installation supplémentaire -> afin que vous puissiez démarrer immédiatement à partir de l’application. Par exemple, si la solution n’est qu’un seul script Python, une telle solution ne convient pas. L’installation de Python, Pygame et lancement manuellement sont nécessaires. Bon exemple: script python enveloppé avec Python et Pygame dans EXE, qui démarre sans installations supplémentaires.
8. Donnez sous la forme d’un lien vers un référentiel public avec le code source, des instructions pour assembler l’application. Bon exemple: un projet avec les instructions d’assemblage de Visual Studio Community Edition

Date limite: le 1er juin résumant le concours

Solution de référence sur zig + sdl3 + sdl3_image:
https://github.com/demensdeum/DemensDeum-Coding-Challenge-1

Contacts fantômes

Dans l’application GhostContacts, vous pouvez ajouter des contacts à la liste secrète, il y a une prise en charge des sujets sombres et brillants, de la localisation, de l’exportation et des importations de contacts CSV, un mot de passe d’urgence est pris en charge pour réinitialiser la liste des contacts si l’utilisateur nécessite soudainement un mot de passe régulier pour entrer.

Application en ligne:
https://demensdeum.com/software/ghost-contacts/

Github:
https://github.com/demensdeum/GhostContacts

Pourquoi j’ai choisi WordPress

Lorsque j’ai commencé à réfléchir à la création de mon propre blog en 2015, j’ai été confronté à la question : quelle plateforme choisir ? Après de nombreuses recherches et comparaisons, j’ai opté pour WordPress. Ce choix n’est pas le fruit du hasard, mais le résultat d’une analyse des capacités de la plateforme, de ses avantages et de ses inconvénients. Aujourd’hui, j’aimerais partager mes réflexions et mon expérience avec WordPress.

Avantages de WordPress

  • Facilité d’utilisation
    L’une des principales raisons pour lesquelles j’ai choisi WordPress est son interface intuitive. Même si vous n’avez jamais travaillé avec un CMS auparavant, vous pouvez maîtriser WordPress en quelques jours.
  • Un grand nombre de plugins
    WordPress donne accès à des milliers de plugins gratuits et payants. Ces extensions vous permettent d’ajouter presque toutes les fonctionnalités liées au blogging, de l’optimisation SEO à l’intégration des médias sociaux.
  • Évolutivité
    WordPress est idéal pour les blogs de toutes tailles. Ayant commencé avec un simple blog personnel, je sais que je peux facilement le développer en ajoutant de nouvelles fonctionnalités et capacités.
  • Large choix de sujets
    Il existe un grand nombre de thèmes gratuits et payants disponibles sur WordPress qui vous permettront de créer un blog de très belle apparence en peu de temps. Créer un design personnalisé nécessite la main sensible d’un designer.
  • Optimisé pour le référencement
    WordPress est conçu pour être convivial pour les moteurs de recherche. Avec des plugins comme Yoast SEO, vous pouvez facilement optimiser votre contenu pour améliorer son classement dans les recherches.
  • Communauté et support
    WordPress possède l’une des plus grandes communautés au monde. Si vous rencontrez un problème, vous trouverez presque certainement une solution sur les forums ou blogs dédiés à la plateforme.
  • Support multilingue
    Grâce à des plugins comme WPGlobus, je peux bloguer dans plusieurs langues, ce qui est particulièrement important lorsque l’on travaille avec un public de différents pays.

Inconvénients de WordPress

  • Vulnérabilité aux attaques
    La popularité de WordPress en fait une cible pour les pirates informatiques. Sans protection adéquate, un site peut devenir victime d’attaques. Cependant, des mises à jour régulières et l’installation de plugins de sécurité contribuent à minimiser les risques.
  • Dépendance du plugin
    Parfois, la fonctionnalité que vous souhaitez ajouter nécessite l’installation de plusieurs plugins. Cela peut ralentir votre blog et provoquer des conflits entre les extensions.
  • Problèmes de performances
    Sur les gros blogs, WordPress peut commencer à ralentir, surtout si vous utilisez beaucoup de plugins. Pour résoudre ce problème, vous devez optimiser la base de données, mettre en œuvre la mise en cache et utiliser un hébergement plus puissant.
  • Coût de certaines fonctions
    Alors que la version de base de WordPress est gratuite, de nombreux thèmes et plugins professionnels coûtent de l’argent. Parfois, il faut investir pour en tirer le meilleur parti.

Conclusion

WordPress est un outil qui offre l’équilibre parfait entre simplicité et puissance. Pour moi, ses avantages l’emportent sur ses inconvénients, surtout compte tenu du grand nombre de solutions pour les surmonter. Grâce à WordPress, j’ai pu créer un blog parfaitement adapté à mes besoins.

Wordex – programme de lecture rapide pour iOS

J’ai récemment trouvé une application de lecture rapide que j’aimerais vous recommander.

La lecture rapide est une compétence qui peut considérablement augmenter votre productivité, améliorer votre compréhension en lecture et gagner du temps. Il existe de nombreuses applications sur le marché qui promettent de vous aider à maîtriser cette compétence, mais celle qui se démarque est Wordex pour iOS. Dans cet article, nous vous expliquerons ce qu’est Wordex, quelles sont ses fonctionnalités, à qui il convient et pourquoi il mérite votre attention.

Qu’est-ce que Wordex ?

Wordex est une application iOS conçue spécifiquement pour développer des compétences en lecture rapide. Il aide les utilisateurs à lire les textes plus rapidement, à se concentrer sur les idées clés et à éviter les distractions. Le programme est basé sur des approches scientifiques et propose des outils pratiques pour améliorer votre vitesse de lecture.

Principales fonctionnalités de Wordex

  • Mode de lecture rapide : le texte est affiché de manière optimisée pour une compréhension rapide. Les utilisateurs peuvent ajuster la vitesse d’affichage du texte en fonction de leurs besoins.
  • Analyse des progrès : le programme fournit des statistiques détaillées, notamment la vitesse de lecture et la dynamique d’amélioration. Cela vous aide à évaluer vos progrès et à ajuster votre approche de la lecture.
  • Importer des textes : Wordex vous permet de télécharger vos propres textes pour vous entraîner. Vous pouvez lire des articles, des livres ou du matériel pédagogique directement dans l’application.
  • Interface intuitive : l’application est conçue dans un style minimaliste, ce qui la rend facile à utiliser. Même les débutants peuvent facilement comprendre la fonctionnalité.


Wordex Screenshot 1

À qui Wordex convient-il ?

Wordex est idéal pour :

  • Étudiants : qui ont besoin de lire rapidement du matériel d’étude et de se préparer aux examens.
  • Hommes d’affaires et employés de bureau : qui souhaitent traiter une grande quantité d’informations en un minimum de temps.
  • Lecteurs : qui souhaitent lire plus de livres et apprécier le processus.


Wordex Screenshot 2

Avantages de Wordex

  • Mobilité :Vous pouvez étudier n’importe où et n’importe quand grâce à l’application sur votre iPhone ou iPad.
  • Personnalisation :la possibilité de personnaliser l’affichage du texte en fonction de vos besoins.


Wordex Screenshot 3

Pourquoi devriez-vous essayer Wordex ?

Wordex n’est pas seulement un outil pour enseigner la lecture rapide. Il s’agit d’un programme qui développe la concentration, élargit le vocabulaire et augmente la productivité. Une fois que vous aurez essayé Wordex, vous remarquerez que la lecture ne sera plus une corvée et se transformera en une activité passionnante.

Conclusion

Si vous souhaitez apprendre la lecture rapide ou améliorer vos compétences existantes, Wordex est un excellent choix. Simple d’utilisation et efficace, l’application vous aidera à atteindre vos objectifs et à gagner un temps précieux. Téléchargez Wordex depuis l’App Store et commencez à vous entraîner dès aujourd’hui !

App Store :
https://apps.apple.com/us/app/speed-reading-book-reader-app/id1462633104

Pourquoi SEC est important

Il existe de nombreux articles sur le thème DRY, je recommande de lire la source originale “The Pragmatist Programmer” d’Andy Hunt et Dave Thomas. Cependant, je vois encore combien de développeurs se posent des questions sur ce principe dans le développement de logiciels.

Le principe DRY stipule que nous ne devons pas nous répéter, cela s’applique à la fois au code et aux processus que nous effectuons en tant que programmeurs. Exemple de code qui viole 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)!")
    }
}

Comme vous pouvez le voir dans les méthodes greet et goodbye, une instance facultative de la classe Client est transmise, qui doit ensuite être vérifiée pour zéro, puis vous pouvez commencer à travailler avec elle. Pour vous conformer à la méthode DRY, vous devez supprimer la vérification nulle en double pour l’instance de classe. Cela peut être implémenté de plusieurs manières ; une option consiste à transmettre l’instance au constructeur de classe, après quoi aucune vérification n’est nécessaire.

Nous nous conformons à DRY en utilisant la spécialisation ClientController sur une seule instance Client :

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 concerne également les processus qui se produisent lors du développement de logiciels. Imaginons une situation dans laquelle une équipe de développement doit mettre en ligne elle-même une version sur le marché, ce qui la détourne du développement de logiciels. Cela constitue également une violation de DRY ; Cette situation est résolue en connectant un pipeline CI/CD, dans lequel la version est publiée automatiquement, sous réserve du respect de certaines conditions par les développeurs.

En général, DRY concerne l’absence de répétitions à la fois dans les processus et dans le code, ceci est également important en raison de la présence du facteur humain : le code qui contient du code moins répétitif et bruyant est plus facile à vérifier pour les erreurs ; Les processus automatisés empêchent les utilisateurs de commettre des erreurs lors de leur exécution, car aucun humain n’est impliqué.

Steve Jobs avait un dicton : « Une ligne de code que vous n’avez jamais eu à écrire est une ligne de code que vous n’avez jamais à déboguer. »

Sources

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

Je vais vous aider à développer iOS pour Swift ou Objective-C

Je suis heureux d’annoncer que j’offre désormais mes services en tant que développeur iOS sur Fiverr. Si vous avez besoin d’aide pour développer des applications iOS de qualité ou améliorer des projets existants, consultez mon profil :
https://www.fiverr.com/s/Q7x4kb6

Je serais heureux d’avoir l’opportunité de travailler sur votre projet.
E-mail : demensdeum@gmail.com
Télégramme : https://t.me/demensdeum

Liaison dynamique des applications Qt sur macOS

Aujourd’hui, j’ai publié une version de RaidenVideoRipper pour les appareils Apple équipés de processeurs macOS et M1/M2/M3/M4 (Apple Silicon). RaidenVideoRipper est une application de montage vidéo rapide qui vous permet de couper une partie d’un fichier vidéo dans un nouveau fichier. Vous pouvez également créer des gifs et exporter la piste audio au format mp3.

Ensuite, je décrirai brièvement les commandes que j’ai utilisées pour accomplir cela. La théorie de ce qui se passe ici, la documentation des utilitaires, peut être lue sur les liens suivants :
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

Pour commencer, installez Qt sur votre macOS et installez également l’environnement pour Qt Desktop Development. Après cela, assemblez votre projet, par exemple, dans Qt Creator, puis je décrirai ce qui est nécessaire pour garantir que les dépendances avec des bibliothèques dynamiques externes sont traitées correctement lors de la distribution de l’application aux utilisateurs finaux.

Créez un répertoire Frameworks dans le dossier YOUR_APP.app/Contents de votre application et placez-y des dépendances externes. Par exemple, voici à quoi ressemble le Frameworks de l’application 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

Pour plus de simplicité, j’ai imprimé uniquement le deuxième niveau d’imbrication.

Ensuite, nous imprimons les dépendances dynamiques actuelles de votre application :

otool -L RaidenVideoRipper

Sortie pour le binaire RaidenVideoRipper, qui se trouve dans 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)

Comme on peut le voir dans RaidenVideoRipper dans les dépendances Qt et dullahan_ffmpeg. Dullahan FFmpeg est un fork de FFmpeg qui encapsule ses fonctionnalités dans une bibliothèque dynamique, avec la possibilité d’obtenir la progression et l’annulation de l’exécution en cours à l’aide de routines C.
Ensuite, remplacez les chemins de l’application et toutes les bibliothèques nécessaires à l’aide de install_name_tool.

La commande pour cela est :

install_name_tool -change old_path new_path target

Exemple d’utilisation :

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

Après avoir saisi tous les chemins corrects, l’application devrait démarrer correctement. Vérifiez que tous les chemins d’accès aux bibliothèques sont relatifs, transférez le binaire et rouvrez-le.
Si vous voyez une erreur, vérifiez les chemins via otool et modifiez à nouveau via install_name_tool.

Il y a aussi une erreur de confusion des dépendances, lorsque la bibliothèque que vous avez remplacée n’a pas de symbole dans le tableau vous pouvez vérifier la présence ou l’absence d’un symbole comme ceci :

nm -gU path

Une fois exécuté, vous verrez toute la table des symboles de la bibliothèque ou de l’application.
Il est également possible que vous ayez copié les dépendances d’une mauvaise architecture, vous pouvez le vérifier à l’aide du fichier :

file path

L’utilitaire de fichiers vous montrera à quelle architecture appartient la bibliothèque ou l’application.

Qt nécessite également un dossier Plugins dans le dossier Contents de votre répertoire YOUR_APP.app, copiez les plugins de Qt vers Contents. Ensuite, vérifiez la fonctionnalité de l’application, après quoi vous pourrez commencer à optimiser le dossier Plugins, à supprimer des éléments de ce dossier et à tester l’application.

Sécurité macOS

Après avoir copié toutes les dépendances et corrigé les chemins pour les liens dynamiques, vous devrez signer l’application avec la signature du développeur et envoyer en outre la version de l’application à Apple pour légalisation.

Si vous ne disposez pas de 100 $ pour une licence de développeur ou si vous ne souhaitez rien signer, écrivez des instructions à vos utilisateurs sur la façon de lancer l’application.

Cette instruction fonctionne également pour RaidenVideoRipper :

  • Désactiver Gatekeeper : spctl –master-disable
  • Autoriser le lancement à partir de n’importe quelle source dans Confidentialité et sécurité : autoriser les applications à basculer vers n’importe où
  • Supprimez l’indicateur de quarantaine après le téléchargement à partir d’une application zip ou dmg : xattr -d com.apple.quarantine app.dmg
  • Vérifiez que l’indicateur de quarantaine (com.apple.quarantine) est manquant : ls -l@ app.dmg
  • Ajouter une confirmation pour lancer l’application si nécessaire dans Confidentialité et sécurité

Une erreur avec l’indicateur de quarantaine est généralement reproduite par l’erreur « L’application est corrompue » apparaissant sur l’écran de l’utilisateur. Dans ce cas, vous devez supprimer l’indicateur de quarantaine des métadonnées.

Lien pour créer RaidenVideoRipper pour Apple Silicon :
https://github.com/demensdeum/RaidenVideoRipper/releases/download/1.0.1.0/RaidenVideoRipper-1.0.1.0.dmg

Stabilisation vidéo à l’aide de ffmpeg

Si vous souhaitez stabiliser les vidéos et supprimer le bougé de l’appareil photo, l’outil « ffmpeg » offre une solution puissante. Grâce aux filtres intégrés « vidstabdetect » et « vidstabtransform », vous pouvez obtenir des résultats professionnels sans utiliser d’éditeurs vidéo complexes.

Préparer le travail

Avant de commencer, assurez-vous que votre `ffmpeg` prend en charge la bibliothèque `vidstab`. Sous Linux, vous pouvez vérifier cela avec la commande :

bash  
ffmpeg -filters | grep vidstab

Si la bibliothèque n’est pas installée, vous pouvez l’ajouter :

sudo apt install ffmpeg libvidstab-dev

Installation pour macOS via Brew :

brew install libvidstab
brew install ffmpeg

Passons maintenant au processus.

Étape 1 : Analyse du mouvement

Vous devez d’abord analyser le mouvement de la vidéo et créer un fichier avec les paramètres de stabilisation.

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

Paramètres :

tremblement : niveau de tremblement de la vidéo (par défaut 5, peut être augmenté à 10 pour les cas plus complexes).
précision : précision de l’analyse (par défaut 15).
transfile : Nom du fichier pour enregistrer les paramètres de mouvement.

Étape 2 : Appliquer la stabilisation

Vous pouvez maintenant appliquer la stabilisation à l’aide du fichier de transformation :

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

Paramètres :

input : pointe vers le fichier avec les paramètres de transformation (créé lors de la première étape).
zoom : facteur de zoom pour supprimer les bords noirs (par exemple 5 – zoom automatique jusqu’à ce que les artefacts soient supprimés).

Analyse automatique du code avec Bistr

Si vous avez besoin d’analyser le code source d’un projet, mais que vous souhaitez automatiser le processus et utiliser la puissance locale de votre ordinateur, l’utilitaire Bistr peut être une excellente solution. Dans cet article, nous verrons comment cet utilitaire permet d’analyser le code à l’aide du modèle d’apprentissage automatique Ollama.

Qu’est-ce que Bistr ?

Bistr est un utilitaire d’analyse de code source qui vous permet d’intégrer un modèle LLM (grand modèle de langage) local, tel qu’Ollama, pour l’analyse et le traitement du code. Avec Bistr, vous pouvez analyser des fichiers dans divers langages de programmation tels que Python, C, Java, JavaScript, HTML, etc.

Bistr utilise le modèle pour vérifier les fichiers par rapport à certaines requêtes, par exemple pour trouver une réponse à une question sur la fonctionnalité du code ou d’une partie de celui-ci. Cela fournit une analyse structurée qui aide à développer, tester et maintenir des projets.

Comment fonctionne Bistr ?

  • Chargement de l’état : lorsque vous démarrez une analyse, l’utilitaire vérifie si l’état de l’analyse a été précédemment enregistré. Cela vous permet de reprendre là où vous vous étiez arrêté sans avoir à analyser à nouveau les mêmes fichiers.
  • Analyse du code : chaque fichier est analysé à l’aide du modèle Ollama. L’utilitaire envoie une requête au modèle pour analyser un morceau de code spécifique. Le modèle renvoie des informations sur la pertinence du code en réponse à la requête et fournit également une explication textuelle de la raison pour laquelle un fragment donné est pertinent pour la tâche.
  • Sauvegarde de l’état : après l’analyse de chaque fichier, l’état est mis à jour afin que vous puissiez continuer avec les dernières informations la prochaine fois.
  • Sortie des résultats : tous les résultats d’analyse peuvent être exportés vers un fichier HTML, qui contient un tableau avec un classement des fichiers par pertinence, ce qui permet de comprendre quelles parties du code sont les plus importantes pour une analyse plus approfondie.

Installation et lancement

Pour utiliser Bistr, vous devez installer et exécuter Ollama, une plateforme qui fournit des modèles LLM sur votre ordinateur local. Les instructions d’installation d’Ollama pour macOS, Windows et Linux sont décrites ci-dessous.

Téléchargez la dernière version de Bistr depuis git :
https://github.com/demensdeum/Bistr/

Après avoir installé Ollama et Bistr, vous pouvez exécuter une analyse de code. Pour ce faire, vous devez préparer le code source et préciser le chemin d’accès au répertoire contenant les fichiers à analyser. L’utilitaire vous permet de poursuivre l’analyse là où vous l’avez arrêtée et offre également la possibilité d’exporter les résultats au format HTML pour faciliter une analyse plus approfondie.

Exemple de commande pour exécuter l’analyse :


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

Dans cette équipe :

–model spécifie le modèle à utiliser pour l’analyse.
–output-html spécifie le chemin d’enregistrement des résultats d’analyse dans un fichier HTML.
–research vous permet de poser une question à laquelle vous souhaitez répondre en analysant le code.

Avantages de l’utilisation de Bistr

  • Exécution locale : l’analyse est effectuée sur votre ordinateur sans qu’il soit nécessaire de se connecter aux services cloud, ce qui accélère le processus.
  • Flexibilité : vous pouvez analyser le code dans différents langages de programmation.
  • Automatisation : tous les travaux de révision du code sont automatisés, ce qui permet d’économiser du temps et des efforts, en particulier lorsque vous travaillez sur des projets de grande envergure.

Réseaux de neurones locaux utilisant ollama

Si vous aviez envie de lancer quelque chose comme ChatGPT et que vous disposez d’un ordinateur assez puissant, par exemple avec une carte vidéo Nvidia RTX, alors vous pouvez exécuter le projet ollama, qui vous permettra d’utiliser l’un des modèles LLM prêts à l’emploi sur votre machine locale, absolument gratuite. ollama offre la possibilité de communiquer avec les modèles LLM, à la manière de ChatGPT également dans la dernière version, la possibilité de lire des images et de formater les données de sortie au format json a été annoncée ;

J’ai également exécuté le projet lui-même sur un MacBook équipé d’un processeur Apple M2 et je sais que les derniers modèles de cartes vidéo AMD sont pris en charge.

Pour installer sur macOS, rendez-vous sur le site ollama :
https://ollama.com/download/mac

Cliquez sur “Télécharger pour macOS”, vous téléchargerez une archive du formulaire ollama-darwin.zip, à l’intérieur de l’archive il y aura Ollama.app qui doit être copié dans “Applications”. Après cela, lancez Ollama.app, le processus d’installation se produira probablement la première fois que vous le lancerez. Après cela, dans le plateau, vous avez vu l’icône ollama, le plateau se trouve en haut à droite à côté de l’horloge.

Après cela, lancez un terminal macOS standard et tapez la commande pour télécharger, installer et exécuter n’importe quel modèle ollama. Une liste des modèles disponibles, leurs descriptions et leurs caractéristiques sont disponibles sur le site ollama :
https://ollama.com/search

Choisissez le modèle avec le moins de paramètres s’il ne rentre pas dans votre carte vidéo au lancement.

Par exemple des commandes pour exécuter le lama3.1:latest model :


ollama run llama3.1:latest

L’installation pour Windows et Linux est généralement similaire, dans un cas, il y aura un programme d’installation ollama et travaillera davantage avec lui via Powershell.
Pour Linux, l’installation se fait à l’aide d’un script, mais je recommande d’utiliser la version de votre gestionnaire de packages spécifique. Sous Linux, ollama peut également être lancé via un terminal bash classique.

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

Unreal Engine sur Macbook M2

Si vous avez pu exécuter Unreal Engine 5 Editor sur un Macbook équipé d’un processeur Apple, vous avez peut-être remarqué que cette chose est assez lente.

Pour augmenter les performances de l’éditeur et du moteur, définissez les paramètres d’évolutivité du moteur -> Moyen. Après cela, le moteur commencera à tout dessiner de manière moins belle, mais vous pourrez travailler normalement avec le moteur de votre MacBook.