Auteur : Fathi Bellahcene

Introduction à la programmation distribuée avec Akka.Net

  Akka.Net est un framework qui vous permettra de faire de la programmation distribuée en appliquant le pattern « Actor Models ». Comme son nom l’indique, c’est un portage de la librairie java Akka <troll> c’est la preuve qu’il reste encore des choses sympa à pomper côté Java </troll> et nous vous proposons donc une petite présentation du pattern, du Framework et d’un exemple.   Le pattern Actor Models Selon Wikipédia, « le modèle d’acteur est un modèle mathématique qui considère des acteurs comme les seules fonctions primitives nécessaires pour la programmation concurrente. Les acteurs communiquent par échange de messages....

Read More

[Clean Code] Indentation… une histoire de bosses

Parler de l’indentation pourra vous sembler futile, voire même inutile : nos IDE sont en mesure de formater convenablement notre code… Inutile donc d’aborder le sujet. Cependant, l’indentation reste un élément fondamental dans la compréhension du code : il permet d’arranger les blocs de code pour en faire ressortir des morceaux cohérents : on arrive ainsi a mieux s’extraire des détails (les sous blocs) et rester concentré sur un niveau précis d’abstraction (en général positionné au même niveau d’indentation). Mais, au-delà de l’aspect organisationnel, la forme de votre code vous permet de détecter certains défauts de celui-ci. Je vous...

Read More

Clean code/commentaires : le bon, la brute, le truand

Sous ce titre racoleur et dans la lignée du premier article qui parle du sujet « clean code : writing code for humans », je vous propose d’aborder le sujet des commentaires… Très souvent, cela déclenche un débat polémique interminable entre les pros et les antis… C’est comme ça dans notre noble métier, on s’ennuie tellement que quand l’occasion de troller se présente, bah on saute dessus. Signal to noise ratio ? Ce qui est important quand on aborde un sujet qui, « à priori », est sans grande valeur et ne mérite pas un blog-post, c’est de préciser notre objectif. Quelle est la finalité attendue ? En quoi les commentaires (ou l’absence de commentaires) m’aide à l’atteindre ? Notre objectif ici est d’améliorer le ratio signal/bruit de notre code. Pour produire du code facilement compréhensible et accessible par tous, nous devons réduire au minimum tout ce qui ne porte pas d’information utile (le bruit) pour ne conserver que la partie utile (le signal) et donc éviter à notre petit cerveau d’avoir a faire le tri, en plus de comprendre le code de Michel. Paradoxalement, les commentaires peuvent être considérés comme du bruit, voire parfois comme du vacarme… C’est ce que je vais tenter de vous montrer dans ce blog post. Après avoir lu pas mal de choses sur le sujet, je répertorie 3 catégories de commentaires : les bons,...

Read More

Clean Code : nommer vos variables

Clean Code : le Bon Codeur et le Mauvais Codeur Au jour le jour, nous – les développeurs – passons notre temps à geindre : « C’est quoi ça !?? » « Pourquoi il a fait ça comme ça ?!!???? » « Je comprend rien à ce bout de code » « ### !1%%$$$££ !!! » « Ca, c’est encore du code à Michel* !! » J’ai donc décidé de passer du temps à essayer de comprendre pourquoi on en arrive à cet état et comment faire pour ne plus être aigri au travail… Je suis tombé sur l’ouvrage d’Oncle Bob, « Clean Code », dans lequel il dit justement : « The ratio of time spent reading (code) versus writing is well over 10 to 1… (therefore) making it easy to read makes it easier to write. » Je me suis rendu compte que notre problème n’est pas tant un manque de connaissances ou de skills (quoi que…) mais davantage un manque de communication : nous écrivons du code « opérationnel » au lieu d’écrire du code destiné à être lu et compris par des humains (pas seulement des codeurs). En lisant plusieurs ouvrages sur le sujet j’ai été déçu… et surpris : déçu, car je m’attendais à des techniques de ninja de super haut niveau pour devenir un killer, mais j’ai constaté que la majorité des axes d’amélioration était simple...

Read More

Design pattern Decorator (décorateur)

Quand utiliser le Design Pattern Decorator ? Très souvent, lorsque l’on souhaite ajouter des fonctionnalités à une classe, on pense héritage – et c’est un bon réflexe ! Mais, très souvent également, cette solution n’est pas réellement adaptée : on peut souhaiter ajouter plusieurs fonctionnalités à la même classe de manière dynamique (runtime) et pas à l’écriture du programme (ajout de fonctionnalité statique), en choisissant les nouvelles fonctionnalités pour chaque instance et non pour la classe. Dans ce cas, on doit faire appel au design pattern Decorator (pattern du GoF de type structure). La modélisation de glaces Prenons un...

Read More

NOS DERNIERES RESSOURCES

Téléchargement Livre blanc Architectures topologies modernes réseau Azure

Derniers tweets

S’abonner

Au blog
RSS Flux RSS