Blog Arolla

Coût, complexité et sémantique : la revue de presse de février

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 !

bye

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *