Tes arguments sont justes et je suis d'accord avec toi, j'ai l'impression qu'une partie des applications bascules de Java à Go. Surtout sur la portabilité de plus en plus simple et naturelle entre plateformes à l'ère des conteneurs, ça marginalise à mon sens la JVM.
Par contre est-ce qu'il y a suffisamment de bibliothèques disponibles pour lui faire une vraie "ombre" ? (vraie question)
Et après tu utilises hiera ou tout autre node classifier pour gérer les différences entre les groupes de machines ou des exceptions.
J'avoue ne pas comprendre : tu peux avoir des inventaires automatiques ou des inventaires statiques ; avec des notions de groupes hiérarchisés entre eux (idem pour la gestion des varibles). Tu peux avoir cette faculté directement au sein d'Ansible. Je ne dis pas que c'est mieux qu'un autre applicatif de la même famille, mais en soi je retrouve ce potentiel dans Ansible, sans l'ombre d'un problème.
Ansible c'est juste bien pour remplacer des scripts bash de déploiement par dessus des trucs pas forcément bien gérés/administrés (…)
Si tu navigues sur Ansible-Galaxy, tu trouveras du sale. Comme tous les produits applicatifs de la planète, qui ont l'équivalent d'une place de marché aux modules.
A titre perso, je suis plutôt content que l'outil soit permissif sur les machines à qui il s'adresse. De plus ramener Ansible à un script Bash, comme cela a été dit dans les autres commentaires, c'est oublier la notion de description d'un état désiré lors de l'appel à un module - le fonctionnement normal - plutôt qu'un script impératif avec beaucoup d'embranchements.
Derrière le code exécuté peut être le même (au sens où l'action réalisée serait la même), mais l'orchestration, la maintenance et les déploiements sont radicalement différent. Ce sujet est en préambule de la doc officielle de l'outil.
Cela permet une généralisation très forte, en segmentant le module comme une opération ou un ensemble limité d'opérations dans un but déterminé. Les rôles permettent encore de produire des ensembles qui seront contextualisés par les playbooks. Ce but peut être technique ou davantage "métier".
(…) et ça plait beaucoup aux sysadmins du dimanche parce qu'ils peuvent continuer à faire de la merde comme avant, sauf que c'est en YAML donc ils peuvent dire qu'ils sont Devops et prétendre à un salaire plus élevé parce que les RH adorent ce mot.
Jugement de valeur non ? Les salariés de chez RedHat, c'est tous des sysadmins du dimanche ?
Tu décris des états, tu ne les codes pas (enfin, tu codes si tu écris toi-même les modules sous-jacent.)
Je suis bien d'accord sur la notion d'état désiré. Pour la partie "pas coder dans le playbook", ce n'est hélas pas rare de le voir via les deux modules de l'enfer : "Shell" / "Win_Shell". Combien le font, par méconnaissance (ou flemme) ? On se retrouve avec des déploiements in-maintenables et pas d'idempotence…
Probablement qu'une partie du problème vient de là, dans la culture et l'image que renvoient Ansible.
C'est un mauvais langage de script parce que c'est justement pas censé être un langage de script.
Ça ce discute. À partir du moment où cela gère des instructions, des variables, des conditions, des entrées et des sortie, je ne vois pas ce qui le différencie d'un langage de programmation.
En soi Ansible ne gère rien, sinon du déclaratif : on lui donne une liste d'états désirés, et ce sont les modules (Python, PS1, ou autres) qui font le taff. La machine distante (qui peut être localhost à l'occasion), renvoie des états post-opération, et Ansible va donc superviser la suite en fonction de ce retour.
Ansible n'a même pas connaissance des valeurs réelles sur les machines, vu qu'il envoie une charge utile à la machine distante et qu'il n'intervient donc pas durant cette phase (à de rares exceptions près, mais subsidiaires).
Bash peut faire le même travail effectivement : tu gères tes accès à la machine distante, les commandes à envoyer, etc. Mais un dry run ou des opérations un peu complexes (au sens "métier" j'entends), dans une phase d'industrialisation du SI, c'est inimaginable avec Bash. Non que ça soit impossible - par Bash ou par le langage x -, mais parce que c'est juste imbitique par conception, car pas la finalité première.
Parfois on a du texte sans guillemet, et parfois il faut mettre des guillemets alors que ça ne sera pas du texte (!).
Ce n'est pas "la faute" à Ansible, mais au respect de la grammaire YAML. Déconcertant certes. Mais pas illogique.
L'autre aspect vraiment regrettable est qu'Ansible n'est pas du tout pensé pour être API-isable, avec simplement un ansible-runner qui fait semblant de l'être.
Tout à fait d'accord. Mais parce que le principe est d'avoir soit l'accès en une "ligne de commande" (enfin un panel restreint), soit via un outil graphique type AWX/Tower.
Après on peut automatiser Ansible en faisant un playbook Ansib-… heu… attendez…
En soi n'importe quel ordinateur est vecteur d'attaque : un serveur AWX/Tower ou un poste d'administrateur.
Si on centralise sur l'un ou l'autre, tout l'accès au SI avec des privilèges élevés, le résultat sera le même : pas bon.
Au-delà de l'usage d'AWX, le principe d'avoir un serveur dédié est de ne pas avoir l'effet oups lors que l'administrateur part en vacances, que son poste crame pour x raison(s). Un serveur peut avoir aussi ses difficultés, mais si on respectueux de ne pas lui faire porter la terre entière, et qu'on a des serveurs physiques ou VM dédiés par usage, voire des pools, ça limite la casse.
Maintenant sur le fond : un poste d'admin ou d'AWX, ça se surveille. Si la sécurité est vraiment importante, ce n'est certainement pas en direct qu'on fait pointer le poste de commandement de déploiement vers l'infra : on passe par un bastion (pour Linux hein, pour Windows… non mais faut juste retirer Windows). Là c'est ce qui est autorisé qui passe, même en commandes envoyées. Pas parfait, mais mieux que rien.
malgré tout le discours sur l'idempotence, c'est un mauvais langage de script (playbook = script, role = fonction, task = instruction)
Hum, je ne suis pas d'accord avec cette lecture. Factuellement Ansible ne fonctionne pas comme cela.
La partie script, c'est bien le module qui le porte. Une tâche est un appel de module. On retrouve l'ensemble des appels (des tâches), dans un playbook. Le rôle n'est qu'une convention d'organisation pour faciliter les échanges.
nb : Les modules ont une notion d'état désiré, et non de programmation au sens classique (c-à-d la suite d'instructions).
Pour compléter : cela permet aussi, lorsque certains éléments techniques ne sont pas centralisés, où le dry run ou une exécution réelle, retourne la "réalité" dans la définition des variables (cf. "Gather facts").
Si l'enjeu de sécurité est fort, Ansible est alors parfait pour "ré-aligner" un serveur / un service d'après un gabarit centralisé et remonter l'alerte.
À titre personnel, je mettrais en premier l'interface ok/changed/failed plus riche que le ok/ko historique du code de retour shell/C.
En Shell ou C, un processus retourne un entier (signé ou non), donc tu as par convention tu as 0 qui vaut "tout va bien"… et 255 autres valeurs pour dire qu'un truc s'est plus ou moins mal passé (ou bien passé, mais avec un truc en plus).
Cependant la richesse relative d'un entier, ne vaut évidemment l'aspect de retours complexes et faciles d'états d'Ansible.
cela dit, le journal est clair et bien présenté, j'approuve totalement, merci JulienG !
De rien :)
Sauf qu'il faut trouver le bon curseur entre complexificatifier son module pour gérer plein de cas, et traiter des cas différents depuis un bout de programmation Yaml/Jinja2, ce qui n'est pas toujours d'une complète évidence.
Beaucoup de débats sur Ansible dans les commentaires, plus que j'aurais pensé. Je pense faire un journal supplémentaire sur ce sujet (état désiré vs programmation) dès ces prochains jours.
La syntaxe de Yaml est basée sur l'indentation, et ça rend presque forcément le résultat illisible, qu'on aime ou pas, le code Yaml se ressemble, et même avec de l'habitude il faut s'y reprendre à plusieurs fois pour bien savoir quelle est la structure représentée.
Pourquoi ?
Ou plutôt : Comment avoir autant raté son design ?
Comment réussir au final à être moins lisible que du bête JSON qui n'impose rien en terme de présentation du code ?
Idem, ça nécessite un journal en soi pour répondre avec exhaustivité.
Chaque format a été prévu avec un objectif - comme toute chose -, et souvent la créature dépasse le créateur. L'usage du Yaml pour Ansible, me semble intimement lié à cette approche d'état désiré. Cependant ce n'est là qu'un avis tout personnel.
Pour le JSON justement, ce n'est pas prioritairement un langage de représentation "humain" (fusse pouvant être lu par lui), qu'un langage d'échange entre app'. Tu n'as pas non plus la complexité d'un XML : le JSON n'a peu de types, fixés à l'avance, aucune notion de définition d'élément, etc. Cette simplicité au moins apparente, le rend pour beaucoup plus lisible que le XML (et le LISP par définition).
Le Yaml a tenté le compromis entre le peu de types à la JSON, mais la représentation lisible par l'homme à la Python - ce qui conduit à une complexité effectivement.
Et franchement, faire de la programmation en Yaml/Jinja2 c'est du pur masochisme, sadique pour le reste de l'équipe.
Ces derniers mois j'ai fait plus de la moitié de mon temps pro sur un projet complexe d'intégration en Ansible. Zéro (0, mais vraiment 0) "programmation" au sein de Jinja : pas d'usage de fonctions, pas de Python dissimulé, etc.
Étant Tech Lead, j'ai pu par contre imposer à l'équipe - et elle ne s'est pas plainte, loin de là -, l'obligation d'avoir des modules dédiés pour tout (rien en Shell dans le Yaml). Le Yaml est donc là pour porter l'état désiré, jamais une commande (je bannis l'usage du module "Shell / Win_Shell"). Si un module n'existe pas, on le créé (Python ou PS1, selon la destination).
De fait je peux t'assurer que toute la complexité est ramené à des scripts (modules) parfaitement clairs et correctement découpés, avec Ansible pour les appels et l'orchestration.
Juste après l'envoi, je m'aperçois de deux boulettes :
"Si l'on voulait véritablement considéré"
-> considérER
"Ainsi voyons le passage des modifications entre les différentes recettes ("plays") : (…)"
-> la partie suivante devrait être en bloc de code "```"
Si un admin/modérateur du site a la possibilité de faire la modif ou m'indiquer comment la faire (de mémoire, on ne peut pas éditer un journal après publication ?). D'avance merci !
Oui en quelque sorte, mais pour moi c'est encore un aspect un peu différent. Le paradigme concourt à produire un développement bien au-delà des aspects algorithmiques, en définissant aussi une logique de développement / d'organisation, des types, etc.
En soi même SQL qui est l'exemple DSL type de nos échanges, permet en soi d'être "Turing-complete" et donc revêt un caractère universel (l'exemple est donné de la récursivité des requêtes SQL à partir de la norme SQL:1999, lui conférant la possibilité des embranchements, des boucles, etc.).
Je distingue donc la "possibilité" expressive de la "volonté" expressive. Et j'espère ne pas dire là un contre-sens ou une contre-vérité…
nb : 'Règle' gère les boucles, les embranchements, les états combinés (les clauses et les conditionnels des règles) peuvent permettre des comparaisons. Sa liaison pour effectuer des calculs jusqu'à sur des bits via le superviseur, rend donc l'ensemble Turing-Complete. Mais la volonté et l'usage premier est bien de représenter une logique métier.
"pour sourire, imaginez une programmation sentimentale :)"
Bien que je ne sois pas sûr que ça soit transposable directement à ce cas (peut-on résumer le programme 'Règle' à une grosse macro ? j'ai un sérieux doute : il gère des états et agit en conséquence).
Une vraie question : de ton point de vue, comment catégorises-tu Prolog, où il est aussi question de description de règles logiques et là aussi, sans être transpilé vers autre chose (à ma connaissance du moins) ?
Pour moi c'est typiquement un DSL :
- tu as une notion de programmation, avec ce que ça concerne de relative souplesse algo ;
- tu le restreints à un "domaine spécifique" (la programmation logique, très loin de l'éventail de toute la programmation possible).
"Ma remarque est sans jugement sur le bien-fondé de la démarche, il va de soit."
Aucun problème, je suis ouvert à l'échange.
"J'ai pas vraiment l'impression que ça soit ça, le low code/no code.
De ce qu'il me semble, c'est que derrière ce terme, on englobe les outils qui visent à s'abstraire :
- la programmation sous forme textuelle (donc ça inclut le code, mais aussi le pseudo-code comme tu l'utilises)
- la gestion de l'outillage attenant (pas de chaîne ou de commandes de compilation, pas de dépôt, pas besoin de lire une documentation pour se lancer, pas de configuration à gérer : un login sur un site web ou un téléchargement d'appli et ça s'utilise)"
Je te rejoins, ce n'est certainement pas du "no-code". Pour le "low-code" - en traduction littérale : "peu codée" -, par contre, la frontière me semble moins claire. Si je reprends la présentation Wikipedia : "A common benefit is that a wider range of people can contribute to the application's development—not only those with coding skills but require a good governance to be able adhere to common rules and regulations."
L'intention de permettre à une personne "métier" d'utiliser de manière simple des fonctions applicatives possiblement très complexes, compte autant à mes yeux que la seule méthode d'accès / d'édition (par une interface Web par exemple). D'ailleurs le défi de premier de ces outils est de garantir la conformité entre la volonté / ce qui est marqué, et l'application / la résolution effective.
Pour arriver à un outil purement "low code" et complet, il faudrait développer tout l'attirail autour. A mon sens, j'ai créé une brique qui s'intègre dans une logique low-code et pas n'importe quelle brique, car elle porte ce qui fait le lien le plus direct entre le métier et l'applicatif.
"Pour moi tu n'as pas fait du low/no-code, mais un PoC de métalangage (?)."
Métalangage je ne sais pas, c'est un DSL tout ce qu'il y a classique (si on considère qu'un DSL est un type de ML, alors oui).
@tankey et @ted : bonjour et merci à chacun de votre modification. Décidément ce n'est pas ma journée, je n'avais effectivement pas ajouté la page dans l'ACL. C'est désormais chose faite.
Je comprends pour la question de GIT. Effectivement ça pourrait conduire à des abus, erreur, etc. et davantage de modération encore.
Merci du retour d'expérience ! Même constat que vous : j'avoue qu'utiliser les lib de Python (notamment pour les hash, pas toujours évident de faire un code vraiment correct), ça me botte bien. Votre projet a l'air pas mal, c'est en usage pro ?
Probablement que oui pour cffi et pybind11. Là c'est une note de travail et de recherche perso que j'ai rendu publique pour ctypes, sans vraiment prétention sinon de dire "c'est possible avec les modules standards de chez Python et de chez Rust". Je vais approfondir le sujet prochainement.
Pour l'instant j'ai une autre idée farfelue : un interpréteur Lua pour Python, via Rust. Parfaitement inutile mais tout à fait sympa. Hum, ça sent le joli casse-tête du long weekend… :)
[^] # Re: Go remplace Java
Posté par JulienG . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 3.
Tes arguments sont justes et je suis d'accord avec toi, j'ai l'impression qu'une partie des applications bascules de Java à Go. Surtout sur la portabilité de plus en plus simple et naturelle entre plateformes à l'ère des conteneurs, ça marginalise à mon sens la JVM.
Par contre est-ce qu'il y a suffisamment de bibliothèques disponibles pour lui faire une vraie "ombre" ? (vraie question)
# Post-scriptum
Posté par JulienG . En réponse au journal # Du serverless au FaaS - et du Golang -, c'est l'été . Évalué à 1.
Il reste probablement plein de coquilles malgré la relecture… Par avance, veuillez m'en excuser !
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.
J'avoue ne pas comprendre : tu peux avoir des inventaires automatiques ou des inventaires statiques ; avec des notions de groupes hiérarchisés entre eux (idem pour la gestion des varibles). Tu peux avoir cette faculté directement au sein d'Ansible. Je ne dis pas que c'est mieux qu'un autre applicatif de la même famille, mais en soi je retrouve ce potentiel dans Ansible, sans l'ombre d'un problème.
Si tu navigues sur Ansible-Galaxy, tu trouveras du sale. Comme tous les produits applicatifs de la planète, qui ont l'équivalent d'une place de marché aux modules.
A titre perso, je suis plutôt content que l'outil soit permissif sur les machines à qui il s'adresse. De plus ramener Ansible à un script Bash, comme cela a été dit dans les autres commentaires, c'est oublier la notion de description d'un état désiré lors de l'appel à un module - le fonctionnement normal - plutôt qu'un script impératif avec beaucoup d'embranchements.
Derrière le code exécuté peut être le même (au sens où l'action réalisée serait la même), mais l'orchestration, la maintenance et les déploiements sont radicalement différent. Ce sujet est en préambule de la doc officielle de l'outil.
Cela permet une généralisation très forte, en segmentant le module comme une opération ou un ensemble limité d'opérations dans un but déterminé. Les rôles permettent encore de produire des ensembles qui seront contextualisés par les playbooks. Ce but peut être technique ou davantage "métier".
Jugement de valeur non ? Les salariés de chez RedHat, c'est tous des sysadmins du dimanche ?
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 5.
Je suis bien d'accord sur la notion d'état désiré. Pour la partie "pas coder dans le playbook", ce n'est hélas pas rare de le voir via les deux modules de l'enfer : "Shell" / "Win_Shell". Combien le font, par méconnaissance (ou flemme) ? On se retrouve avec des déploiements in-maintenables et pas d'idempotence…
Probablement qu'une partie du problème vient de là, dans la culture et l'image que renvoient Ansible.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.
En soi Ansible ne gère rien, sinon du déclaratif : on lui donne une liste d'états désirés, et ce sont les modules (Python, PS1, ou autres) qui font le taff. La machine distante (qui peut être localhost à l'occasion), renvoie des états post-opération, et Ansible va donc superviser la suite en fonction de ce retour.
Ansible n'a même pas connaissance des valeurs réelles sur les machines, vu qu'il envoie une charge utile à la machine distante et qu'il n'intervient donc pas durant cette phase (à de rares exceptions près, mais subsidiaires).
Bash peut faire le même travail effectivement : tu gères tes accès à la machine distante, les commandes à envoyer, etc. Mais un dry run ou des opérations un peu complexes (au sens "métier" j'entends), dans une phase d'industrialisation du SI, c'est inimaginable avec Bash. Non que ça soit impossible - par Bash ou par le langage x -, mais parce que c'est juste imbitique par conception, car pas la finalité première.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 1. Dernière modification le 24 mars 2022 à 23:22.
Ne me jetez pas la pierre, faut bien que je justifie mon salaire… ;)
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 5.
Ce n'est pas "la faute" à Ansible, mais au respect de la grammaire YAML. Déconcertant certes. Mais pas illogique.
Tout à fait d'accord. Mais parce que le principe est d'avoir soit l'accès en une "ligne de commande" (enfin un panel restreint), soit via un outil graphique type AWX/Tower.
Après on peut automatiser Ansible en faisant un playbook Ansib-… heu… attendez…
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.
En soi n'importe quel ordinateur est vecteur d'attaque : un serveur AWX/Tower ou un poste d'administrateur.
Si on centralise sur l'un ou l'autre, tout l'accès au SI avec des privilèges élevés, le résultat sera le même : pas bon.
Au-delà de l'usage d'AWX, le principe d'avoir un serveur dédié est de ne pas avoir l'effet oups lors que l'administrateur part en vacances, que son poste crame pour x raison(s). Un serveur peut avoir aussi ses difficultés, mais si on respectueux de ne pas lui faire porter la terre entière, et qu'on a des serveurs physiques ou VM dédiés par usage, voire des pools, ça limite la casse.
Maintenant sur le fond : un poste d'admin ou d'AWX, ça se surveille. Si la sécurité est vraiment importante, ce n'est certainement pas en direct qu'on fait pointer le poste de commandement de déploiement vers l'infra : on passe par un bastion (pour Linux hein, pour Windows… non mais faut juste retirer Windows). Là c'est ce qui est autorisé qui passe, même en commandes envoyées. Pas parfait, mais mieux que rien.
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 7.
Hum, je ne suis pas d'accord avec cette lecture. Factuellement Ansible ne fonctionne pas comme cela.
La partie script, c'est bien le module qui le porte. Une tâche est un appel de module. On retrouve l'ensemble des appels (des tâches), dans un playbook. Le rôle n'est qu'une convention d'organisation pour faciliter les échanges.
nb : Les modules ont une notion d'état désiré, et non de programmation au sens classique (c-à-d la suite d'instructions).
[^] # Re: Ansible
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 4.
Pour compléter : cela permet aussi, lorsque certains éléments techniques ne sont pas centralisés, où le dry run ou une exécution réelle, retourne la "réalité" dans la définition des variables (cf. "Gather facts").
Si l'enjeu de sécurité est fort, Ansible est alors parfait pour "ré-aligner" un serveur / un service d'après un gabarit centralisé et remonter l'alerte.
En Shell ou C, un processus retourne un entier (signé ou non), donc tu as par convention tu as 0 qui vaut "tout va bien"… et 255 autres valeurs pour dire qu'un truc s'est plus ou moins mal passé (ou bien passé, mais avec un truc en plus).
Cependant la richesse relative d'un entier, ne vaut évidemment l'aspect de retours complexes et faciles d'états d'Ansible.
[^] # Re: Horreur
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 1.
C'est moi qui te remercie !
[^] # Re: il faudrait le réécrire <s>en Rust</s> !
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 7.
De rien :)
Beaucoup de débats sur Ansible dans les commentaires, plus que j'aurais pensé. Je pense faire un journal supplémentaire sur ce sujet (état désiré vs programmation) dès ces prochains jours.
Idem, ça nécessite un journal en soi pour répondre avec exhaustivité.
Chaque format a été prévu avec un objectif - comme toute chose -, et souvent la créature dépasse le créateur. L'usage du Yaml pour Ansible, me semble intimement lié à cette approche d'état désiré. Cependant ce n'est là qu'un avis tout personnel.
Pour le JSON justement, ce n'est pas prioritairement un langage de représentation "humain" (fusse pouvant être lu par lui), qu'un langage d'échange entre app'. Tu n'as pas non plus la complexité d'un XML : le JSON n'a peu de types, fixés à l'avance, aucune notion de définition d'élément, etc. Cette simplicité au moins apparente, le rend pour beaucoup plus lisible que le XML (et le LISP par définition).
Le Yaml a tenté le compromis entre le peu de types à la JSON, mais la représentation lisible par l'homme à la Python - ce qui conduit à une complexité effectivement.
Ces derniers mois j'ai fait plus de la moitié de mon temps pro sur un projet complexe d'intégration en Ansible. Zéro (0, mais vraiment 0) "programmation" au sein de Jinja : pas d'usage de fonctions, pas de Python dissimulé, etc.
Étant Tech Lead, j'ai pu par contre imposer à l'équipe - et elle ne s'est pas plainte, loin de là -, l'obligation d'avoir des modules dédiés pour tout (rien en Shell dans le Yaml). Le Yaml est donc là pour porter l'état désiré, jamais une commande (je bannis l'usage du module "Shell / Win_Shell"). Si un module n'existe pas, on le créé (Python ou PS1, selon la destination).
De fait je peux t'assurer que toute la complexité est ramené à des scripts (modules) parfaitement clairs et correctement découpés, avec Ansible pour les appels et l'orchestration.
# Horreur
Posté par JulienG . En réponse au journal Test de vie et Ansible : un exemple de réalisation pour mieux comprendre l'outil . Évalué à 6.
Juste après l'envoi, je m'aperçois de deux boulettes :
"Si l'on voulait véritablement considéré"
-> considérER
"Ainsi voyons le passage des modifications entre les différentes recettes ("plays") : (…)"
-> la partie suivante devrait être en bloc de code "```"
Si un admin/modérateur du site a la possibilité de faire la modif ou m'indiquer comment la faire (de mémoire, on ne peut pas éditer un journal après publication ?). D'avance merci !
[^] # Re: Low code ?
Posté par JulienG . En réponse au journal 'Règle'. Organiser son traitement. Sans se désorganiser.. Évalué à 2.
Oui en quelque sorte, mais pour moi c'est encore un aspect un peu différent. Le paradigme concourt à produire un développement bien au-delà des aspects algorithmiques, en définissant aussi une logique de développement / d'organisation, des types, etc.
En soi même SQL qui est l'exemple DSL type de nos échanges, permet en soi d'être "Turing-complete" et donc revêt un caractère universel (l'exemple est donné de la récursivité des requêtes SQL à partir de la norme SQL:1999, lui conférant la possibilité des embranchements, des boucles, etc.).
Je distingue donc la "possibilité" expressive de la "volonté" expressive. Et j'espère ne pas dire là un contre-sens ou une contre-vérité…
nb : 'Règle' gère les boucles, les embranchements, les états combinés (les clauses et les conditionnels des règles) peuvent permettre des comparaisons. Sa liaison pour effectuer des calculs jusqu'à sur des bits via le superviseur, rend donc l'ensemble Turing-Complete. Mais la volonté et l'usage premier est bien de représenter une logique métier.
Ah ça se tente… !
[^] # Re: Low code ?
Posté par JulienG . En réponse au journal 'Règle'. Organiser son traitement. Sans se désorganiser.. Évalué à 1.
Ton argument fait mouche !
Bien que je ne sois pas sûr que ça soit transposable directement à ce cas (peut-on résumer le programme 'Règle' à une grosse macro ? j'ai un sérieux doute : il gère des états et agit en conséquence).
Une vraie question : de ton point de vue, comment catégorises-tu Prolog, où il est aussi question de description de règles logiques et là aussi, sans être transpilé vers autre chose (à ma connaissance du moins) ?
Pour moi c'est typiquement un DSL :
- tu as une notion de programmation, avec ce que ça concerne de relative souplesse algo ;
- tu le restreints à un "domaine spécifique" (la programmation logique, très loin de l'éventail de toute la programmation possible).
Qu'en penses-tu ?
[^] # Re: Low code ?
Posté par JulienG . En réponse au journal 'Règle'. Organiser son traitement. Sans se désorganiser.. Évalué à 2. Dernière modification le 14 mars 2022 à 22:02.
Aucun problème, je suis ouvert à l'échange.
Je te rejoins, ce n'est certainement pas du "no-code". Pour le "low-code" - en traduction littérale : "peu codée" -, par contre, la frontière me semble moins claire. Si je reprends la présentation Wikipedia : "A common benefit is that a wider range of people can contribute to the application's development—not only those with coding skills but require a good governance to be able adhere to common rules and regulations."
L'intention de permettre à une personne "métier" d'utiliser de manière simple des fonctions applicatives possiblement très complexes, compte autant à mes yeux que la seule méthode d'accès / d'édition (par une interface Web par exemple). D'ailleurs le défi de premier de ces outils est de garantir la conformité entre la volonté / ce qui est marqué, et l'application / la résolution effective.
Pour arriver à un outil purement "low code" et complet, il faudrait développer tout l'attirail autour. A mon sens, j'ai créé une brique qui s'intègre dans une logique low-code et pas n'importe quelle brique, car elle porte ce qui fait le lien le plus direct entre le métier et l'applicatif.
Métalangage je ne sais pas, c'est un DSL tout ce qu'il y a classique (si on considère qu'un DSL est un type de ML, alors oui).
J'espère avoir pu répondre à ta remarque.
[^] # Re: rule-based … assert
Posté par JulienG . En réponse au journal 'Règle'. Organiser son traitement. Sans se désorganiser.. Évalué à 3.
Le sujet est terriblement vaste et complexe en effet.
[^] # Re: Prenez garde en lisant ce journal
Posté par JulienG . En réponse au journal Rust et bibliothèque partagée en C. Évalué à 1.
J'ai dit une bêtise… ??
[^] # Re: Prenez garde en lisant ce journal
Posté par JulienG . En réponse au journal Rust et bibliothèque partagée en C. Évalué à 4.
Je regrette si ma publication lui a causé du tort, mais si je ne crois pas y avoir été pour grand chose ? En tout cas ce ne fut pas mon but.
J'espère que les prochains échanges, notamment sur cette publication, seront plus apaisés qu'ils ne l'ont été malheureusement sur la précédente.
[^] # Re: Merci à vous !
Posté par JulienG . En réponse au message Modération / édition de journal ? . Évalué à 1.
Merci ! :)
[^] # Re: autorisation refusée sur le lien
Posté par JulienG . En réponse au message Modération / édition de journal ? . Évalué à 2. Dernière modification le 10 mai 2020 à 18:32.
@Tankey, normalement le lien est désormais actif. As-tu la possibilité de faire la modification ? T'en remerciant par avance.
# Merci à vous !
Posté par JulienG . En réponse au message Modération / édition de journal ? . Évalué à 2.
@tankey et @ted : bonjour et merci à chacun de votre modification. Décidément ce n'est pas ma journée, je n'avais effectivement pas ajouté la page dans l'ACL. C'est désormais chose faite.
Je comprends pour la question de GIT. Effectivement ça pourrait conduire à des abus, erreur, etc. et davantage de modération encore.
Bonne soirée à tous les deux.
[^] # Re: Connection python -> C
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 3.
Merci du retour d'expérience ! Même constat que vous : j'avoue qu'utiliser les lib de Python (notamment pour les hash, pas toujours évident de faire un code vraiment correct), ça me botte bien. Votre projet a l'air pas mal, c'est en usage pro ?
Probablement que oui pour cffi et pybind11. Là c'est une note de travail et de recherche perso que j'ai rendu publique pour ctypes, sans vraiment prétention sinon de dire "c'est possible avec les modules standards de chez Python et de chez Rust". Je vais approfondir le sujet prochainement.
Pour l'instant j'ai une autre idée farfelue : un interpréteur Lua pour Python, via Rust. Parfaitement inutile mais tout à fait sympa. Hum, ça sent le joli casse-tête du long weekend… :)
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 2.
Pour compléter les exemples sur les logiciels qui s'accompagnent d'accès à ou de langages intégrés, ce serait l'automatisation de LibreOffice grâce à Python :
https://wiki.documentfoundation.org/Macros/Python_Guide/fr/Initialconcepts
(et)
https://wiki.documentfoundation.org/Macros/Python_Design_Guide/fr
… Si quelqu'un a d'ailleurs un retour d'expérience sur UNO, ça m'intéresse !
[^] # Re: Beurk, écoeurant ....
Posté par JulienG . En réponse au journal Rust et Python associés grâce au C. Évalué à 3.
Oups. Toutes mes excuses ! :/ ça m'apprendra à ne pas chercher d'abord.
Pense-bête : https://www.lua.org/history.html