Dans cette nouvelle revue de presse, il sera question de coût, de complexité et de sémantique. Trois leviers avec lesquels il faut souvent jouer pour atteindre le résultat tant attendu. Vaste programme !
Nous allons parler encore une fois d’un buzzword : « severless ». L’idée derrière ce terme est de ne payer que ce que l’on consomme. C’est intéressant pour quantifier les dépenses. Mais comme le rappelle l’auteur du billet ci-dessous, cela n’est pas « gratuit » et introduit d’autres problématiques qui viennent augmenter la complexité du système.
https://medium.freecodecamp.org/serverless-is-cheaper-not-simpler-a10c4fc30e49
Continuons sur le thème des frais, avec le web où le point le plus important est d’avoir un site qui soit utilisable par l’utilisateur le plus rapidement possible. L’auteur s’attache principalement au coût de JavaScript (le chargé, le compilé, l’exécuté). Il nous rappelle qu’on oublie souvent que la vitesse dépend aussi du processeur sur lequel on travaille. On peut très bien avoir des utilisateurs ayant de très bonnes connexions avec un matériel plus limité.
https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e
Dans ces liens ci-dessus, il y a beaucoup de code écrit, pour tout ce qui est branchement ou pour ce qui concerne la partie interactivité d’un site. Dans l’article suivant, il sera question de lecture de code. Qu’est-ce qui se cache derrière un code dit lisible ? Quel est le sens de l’expression « un code simple » ?
Autant de questions qui mènent l’auteur à cette dernière question : comment peut-on écrire du code compréhensible ?
http://typicalprogrammer.com/what-does-code-readability-mean
Nous allons d’ailleurs illustrer ce dernier sujet par « comment lire du haskell ». Un langage où cette notion de « simplicité » prend tout son sens si l’on prend en considération l’expérience du lecteur. Mais dans ce lien, on n’entre pas trop dans les détails, pour se focaliser sur l’essentiel.
https://soupi.github.io/rfc/reading_simple_haskell/
Je terminerai cette revue de presse par un autre article sur comment lire une « promesse » en JavaScript. Dans ce cas-là, on ne s’attarde pas sur l’écriture, mais sur la sémantique. Autrement dit quel problème va-t-on vouloir résoudre en utilisant ce type d’architecture ? Quel gain cela peut-il m’apporter par rapport à la plus grande complexité à lire ce code ?
https://medium.com/@jessitron/understanding-promises-in-javascript-with-yarn-and-legos-68034c08117c
Bonne lecture et à très bientôt pour la prochaine revue de presse !
