14,90 € TTC
p. 06 Côté livres
p. 08 Générer votre site statique pour GitHub Pages
p. 24 Introduction au dossier
p. 26 Initier un projet Symfony
p. 40 Abstraction de base de données avec les entités Symfony
p. 58 Interface utilisateur avec Twig
p. 76 API Platform : développez une API REST et GraphQL avec Symfony
p. 88 Formulaires efficaces avec Symfony
p. 106 Tailwind CSS : une brise fraîche dans le monde des frameworks CSS
Je n’aime pas le développement web.
Voilà qui est dit et clairement dit. Sans doute est-ce parce que j’ai une sorte d’obsession pour l’aspect système. Un genre d’affection toute particulière pour le bas niveau et la proximité avec le matériel, qui fait que les multiples niveaux d’abstraction, le typage dynamique ou encore l’objet me gâchent mon plaisir de programmer presque instantanément. Or, les caractéristiques précitées, et bien d’autres encore, sont omniprésentes dans le monde du Web, que ce soit en front ou en back.
Me voici donc passablement handicapé lorsqu’il s’agit d’attaquer un projet proposant potentiellement une interface utilisateur, car il est vrai que de nos jours, les « vraies » applications desktop, comprendre « avec GUI », subissent une forte concurrence des technologies web, grignotant sans cesse de nouveaux territoires. Personnellement, j’ai réglé le problème : je ne touche pas au Web, je ne touche pas aux toolkits graphiques (sauf Go/Fyne qui sait séduire les plus rustres d’entre nous, jetez un œil au numéro 263 toujours chez votre marchand de journaux) et je me complais sans scrupule dans la ligne de commande, getopt et readline.
Mais, parce qu’il y a un « mais », forcément... si je devais m’engager dans un projet impliquant du développement web, je ne le ferais certainement pas « tout nu » en PHP. Vous verrez, dans les pages qui vont suivre, qu’un framework comme Symfony change réellement la donne. Et même s’il ne peut impacter des préférences bien ancrées, et de longue date qui plus est, il rendra effectivement votre vie plus vivable, le ciel plus bleu et votre poil plus brillant (too much?)...
Plus sérieusement, ne faites pas du PHP comme un sauvage, utilisez un framework, ils sont là pour ça.
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...

Soyons clairs, je ne suis pas fan de Lua en tant que langage de programmation. Le simple fait que les tableaux débutent à l'indice 1 me perturbe totalement et constitue pour moi une véritable aberration. Mais, d'un autre côté, Lua est aussi le langage par excellence lorsqu'il s'agit d'embarquer des fonctionnalités de scripting au sein d'une application ou d'un outil. Du moins, c'est ce que tend à montrer sa popularité dans ce domaine et, si l'on n’a jamais tenté l'expérience, on peut se demander pourquoi. La réponse est évidente après quelques lignes de code et on se surprend soi-même à dire, à haute voix qui plus est, « Ah ! Mais c'est excellent, en fait ! ».
Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.
Au détour d'un petit projet incluant des échanges USB avec un adaptateur série utilisant une puce FTDI FT232R, j'ai rencontré un problème susceptible de survenir dans diverses situations. Même si aujourd'hui UTF-8 semble avoir toujours été présent dans nos terminaux, éditeurs, codes et que sais-je encore, les utilisateurs et programmeurs les plus aguerris se souviennent sans peine de la souffrance vécue lors de la transition depuis le bon vieux Latin1 (alias iso-8859-1). Mais la dure réalité est la suivante : UTF-8 n'est pas partout !