9,70 € TTC
p. 06 Ruby : le pont entre ENV et votre code
p. 10 Migration de Vim à Neovim pour de la complétion efficace
p. 18 Automatisation avec Jenkins et OpenShift
p. 40 YAMS : encore un autre algorithme de tri !
p. 58 Comment détourner un programme de son chemin d’exécution ?
p. 66 Les codes fantastiques : lib et introspection
p. 68 Écrivons un module kernel pour NetBSD
« Oui, moi je programme en HTML ! »
Voici une affirmation généralement corrigée d’un vif « HTML est un langage de description, pas de programmation » par la plupart des personnes ayant un minimum d’expérience et de connaissances en ce domaine. S’en suivent généralement diverses explications plus ou moins animées autour de ce qu’est ou non un langage de programmation, qui a droit au titre ronflant de « programmeur » et qui dénigre honteusement le travail de qui...
Il y a malheureusement un paradoxe qui fait qu’argumenter n’a aucun sens. Expliquer à une personne ce qu’est un langage de programmation suppose des bases solides en informatique théorique, de part et d’autre du dialogue. La seule manière d’arriver à construire des argumentaires cohérents consiste avant tout à, au moins, se mettre d’accord sur quelques définitions claires. Partant de là, on peut évaluer le fait que HTML soit ou non un langage Turing-complet et si oui, sous quelles conditions (spoiler : l’ajout de CSS3 dans l’équation). Bien entendu, ceci à condition de définir également, sans équivoque, ce qu’est un système dit complet au sens de Turing, et nous voici repartis pour un tour dans la boucle d’un triste manège sans fin...
Bref, c’est une perte de temps. Tout comme discutailler de l’origine véritable de la phrase : « Argumenter avec des imbéciles, c’est comme jouer aux échecs avec un pigeon. Peu importe votre niveau, le pigeon va juste renverser toutes les pièces, chier sur le plateau et se pavaner fièrement comme s’il avait gagné. »
Mon conseil donc, ami développeur, en particulier depuis que les quatre lettres « YAML » ont remplacé « HTML » dans l’affirmation sus-citée, est simple, paisible et peu fatigant : souriez gentiment, acquiescez poliment de la tête et éloignez-vous discrètement.
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
Il est parfois indispensable de modifier l'exécution d’un programme, sans en modifier le code source, pour l’adapter à des besoins spécifiques. Quels sont les moyens que nous offre Linux ?
Comment centraliser la configuration d’une application, tout en permettant un ajustement au cas par cas avec des variables d’environnement, sans se répéter.
Je suis utilisateur de Vi/Vim depuis des dizaines d'années et changer ses habitudes n'est pas chose facile. Un élément déclencheur est souvent nécessaire et le mien aura été un essai de Visual Studio Code pour du développement sur microcontrôleur avec PlatformIO. J'ai donc décidé de quitter Vim pour passer à... Neovim. Hé oui, ne vous y trompez pas, car même si VSCode s'avère effectivement agréable, voire proche d'une expérience Vi avec les bons plug-ins, et qu'on s'habitue facilement au confort de la complétion « IntelliSense » et de l'affichage des prototypes de fonctions, cet IDE graphique ne sera jamais Vi. Au contraire, il pousse simplement à faire en sorte que son Vi adopte des fonctionnalités qu'il ne possède pas nativement. Et c'est précisément ce dont il est question ici.