7,90 € TTC
p. 06 Empaquetez (facilement) votre projet avec upt
p. 12 Après le code source, le code moral !
p. 16 Faut-il nécessairement réfléchir pour programmer ?
p. 24 Confrontation de plans cadastraux et de photos satellite avec OpenCV
p. 42 Retrouvez le plaisir du test HDL avec Cocotb
p. 52 Une introduction à LuaJIT
p. 58 Chroot, machine virtuelle ou Kubernetes ?
p. 71 Imprimer en ligne de commandes
p. 78 Le langage Dart et les Web Apps
p. 92 Découvrez ou redécouvrez Ansible-Vault
Pendant longtemps je n'ai utilisé que les commandes « naturelles » du Shell. Jamais un alias ni de scripts ne contenant ne serait-ce que deux ou trois lignes pour être certain d'être opérationnel en toute situation, sur n'importe quelle machine. Pourtant il est possible de devenir beaucoup plus productif en utilisant ces outils correctement. Pourquoi alors se restreindre à un usage somme toute fort limité du Shell ?
Pendant mes études, dans ce qui s’appelait alors une Licence d’Informatique (et qui est maintenant un L3), j’ai eu la chance d’avoir un professeur en « Système et Réseau » qui nous a obligés à n’utiliser que les commandes naturelles du Shell, à n’écrire nos programmes qu’à l’aide de Vi (ou à l'extrême rigueur avec Xemacs), à utiliser Awk, Sed et autres outils indispensables, mais peu engageants de prime abord. S’il n’avait pas été là à nous pousser dans cette direction qui n’était pas la voie la plus simple, aurions-nous réellement découvert tout le potentiel de ces outils ? Les aurions-nous simplement utilisés alors qu’ils semblaient si rébarbatifs ? Bien entendu, comme dans chaque promotion il y a bien eu le groupe des « petits rigolos » qui utilisaient nedit en douce et faisaient semblant d’employer Vim. Les mêmes qui, passant de Pascal à C, ajoutaient des macros pour pouvoir continuer à écrire du Pascal, mais en C :
Oui, c'est horrible, mais il y a vraiment des gens qui ont fait ça dans leur vie et ne se sont jamais remis en question… et même certains qui ont eu leur diplôme et continuent probablement à sévir en contribuant au développement de diverses applications et services que nous utilisons (et là ça fait peur, même si tout de suite on comprend mieux bon nombre de dysfonctionnements).
Je pense en tout cas que pour la majorité des étudiants de l'époque, le fait d'être contraints à une utilisation stricte de ces outils a été bénéfique. Et tant pis pour les autres...
Ce n'est pourtant que 20 ans après (ouch !) que je me rends compte de l’intérêt pédagogique de cette approche... mais j’en ai peut-être été tellement marqué que j'ai tardé à utiliser des scripts et des alias. La peur de ne pas être capable de se débrouiller sans Internet (qui en était à ses balbutiements à l'époque), d’oublier les commandes ? Et puis un jour ce fut la révélation : il était désormais trop tard pour oublier ces commandes, elles étaient ancrées en moi. Ma décision fut prise et je passai aux alias et aux mini-scripts qui me firent gagner un temps non négligeable !
Cette réflexion m’a amené plus loin : dans mes enseignements, je propose régulièrement à mes étudiants de les aider pour tester Linux (ils sont bien sûr majoritairement sous Windows), de les accompagner dans l’apprentissage de Vim ou de LaTeX. Sans succès ! Mes UEs portent sur des projets algorithmiques, de la Programmation Orientée Objet ou du développement Web et je me voyais mal imposer quelque chose sans lien direct avec le cours. Mais finalement, il y a des cas où si personne n’est là à nous pousser, à nous faire « mal », nous n’avançons pas. Donc cette année mes étudiants vont souffrir : ils rendront leur projet sous LaTeX ! Ainsi, ils pourront choisir en connaissance de cause avant d’utiliser LibreOffice ou même Word. Une fois dans leur vie, ils auront goûté à LaTeX et peut-être qu’un jour, après m’avoir haï pour certains, ils me remercieront...
Apprendre, ça fait mal. Espérons que vous ne souffriez pas trop à lire GNU/Linux Magazine :-) !
Tristan Colombo
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...
Cela ne vous frappe pas que tout le secteur informatique ait les yeux rivés sur Kubernetes ? Moi, ça me donne à réfléchir. En quoi est-ce qu'un chroot ne ferait pas aussi bien le travail ? Les machines virtuelles seraient donc en fin de vie ? Quels sont les cas d'usage des conteneurs, et aussi quand ne pas les utiliser ? Je peux sûrement amener ici quelques éléments de réponse.
Nous allons nous prêter à un exercice amusant avec OpenCV qui somme toute n'est pas si facile qu'il y paraît. Il s'agit de superposer un plan cadastral sur une photo satellite de manière totalement automatique. À partir de là, nous pouvons envisager une multitude d'applications. Par exemple, rechercher les piscines ou bâtiments présents sur la photo satellite qui ne sont pas sur le plan cadastral. Voyons comment faire…
Écrire les stimuli permettant de tester un composant HDL (Hardware Description Language) est beaucoup plus facile et plaisant avec un langage moderne comme Python qu’avec les vénérables langages Verilog et VHDL. La librairie Cocotb permet d'écrire ces tests en Python et de piloter un simulateur du commerce qu'il soit libre ou non (Cosimulation).