Cela fait plusieurs années que vous faites des applications de bureau en .NET / C# / Winform / WPF / SQL Server / EF, avec tous les patterns qui vont avec, et vous vous intéressez depuis peu au web ?
Si c'est le cas, vous avez surement découvert ASP .NET et son fameux MVC 4 et 5.
Lors de cette découverte, vous avez apprivoisé rapidement l'ensemble de l'écosystème coté "Backend" tant les concepts et méthodes sont proches de la programmation orientée objet traditionnelle.
Seulement voila, lorsque vous avez commencé a regarder la partie "Frontend", vous n'avez pas pu vous empêcher de gerber tant les principes et outils qui dominent sont chaotiques, improductifs, soumis au monde de la bidouille et sans aucune foi ni loi.
Si le monde informatique est plein de logiciels qui sont en interaction direct avec l’utilisateur, d’autres types de programmes s’exécutent dans l’ombre et permettent le bon fonctionnement de plusieurs services indispensables.
Ces logiciels fantômes qui servent à traiter vos mails, acheminer vos documents vers une imprimante, lancer des sauvegardes automatiques et bien d’autres choses sont appelés dans le jargon informatique des « démons systèmes ». Ils travaillent en arrière-plan et ont pour vocation à faire des traitements critiques, il est donc primordial que ceux-ci soient les plus robustes possibles.
Or, la plupart du temps, les concepteurs de ces programmes n’appliquent pas les bonnes pratiques comme ils pourraient le faire avec des logiciels de gestion traditionnels, et ce pour plusieurs raisons :
Les programmeurs travaillent souvent seul sur un démon système
Le .NET framework fourni des API natives très peu adaptées à la mise en place de design SOLID
Les démons systèmes sont (de premier abord) des programmes simples qui ne font que des choses répétitives.
De plus, il n’existe pas vraiment de bonnes pratiques quant à
l’exploitation d’un démon système, ainsi chaque programmeur y va de sa
créativité (enregistrement de logs dans des fichiers ou dans l’observateur
d’événements, interface de contrôle obscure, configuration sous forme de fichier
XML, INI ou base de registre, suivi des opérations à travers un fichier de
sortie, …)
Tout cela peut rendre complétement fou ceux qui sont chargés
d’installer, configurer et maintenir ces programmes, c’est pourquoi j’ai créé
« SystemHell », un Framework Open Source permettant de mettre au
point rapidement et facilement des services systèmes (démons) en .NET, avec
l’avantage de donner plus de souplesse aux administrateurs pour les installer,
les configurer et les maintenir.
Nous allons voir ensemble comment manipuler cet outil pour
mettre sur pied des démons avec une vraie qualité professionnelle.
Plutôt que de lire, écoutez cet article avec ASTREAD
Chaque jour dans le monde, des milliers de personnes se jettent
dans un nouveau projet de développement logiciel : Que ce soit une startup
qui veut lancer un concept avec son site web, une entreprise qui veut développer
un logiciel de gestion ou un étudiant qui désire créer une application mobile,
tous voient en la technologie un moyen simple et rapide de réaliser leurs
ambitions.
Mais savez-vous que selon « l’observatoire des
projets » qui a réalisé une étude sur le taux d’échec dans le domaine de
l’informatique en 2012, 55% des responsables sondés estiment qu’entre 16% et
50% de leurs projets stratégiques sont purement et simplement abandonnés !
L’histoire que je vais vous raconter parle de l’un de ces millions
de projets qui a bien failli finir dans les oubliettes de l’informatique, tout
en entrainant avec lui l’avenir d’une société et des salariés qui la composent.
Loin d’être un cas isolé, nous allons voir comment ce projet
hautement stratégique a lentement dérivé, pour arriver à une situation
tellement catastrophique que tous ceux qui y ont participé de près ou de loin
s’en sont retrouvés profondément affectés.
Comme la fin du projet signifiait la fin de la société, il
n‘était pas question pour la direction de l’abandonner.
C’est dans ces
conditions difficiles que j’ai été désigné pour en reprendre les rênes.
Or, l’équipe était tellement accablée par cet échec qu’elle
ne pouvait accepter de recommencer.
Seule une profonde remise en question des méthodes de
travail tant sur le plan technique que humain pouvait les convaincre de
remettre le couvert.
J’ai donc été obligé de revoir ma façon de penser et d’aller
à contre-courant de tout ce qui se faisait jusqu’alors, allant parfois à
l’encontre d’un certain bon sens et des directives données par les
dirigeants même de la société !
Et figurez-vous que ça a marché.
Je vous propose donc de vous faire revivre cette expérience
qui a changée à jamais notre façon de gérer des projets de développement…
Mon incompétence en terme d’IHM étant assez importante,
j’ai suivi récemment une formation sur les outils de modélisation WPF, et je
dois dire que cela m’a assez bien réconcilié avec le monde de l’interface
graphique.
Cela a surtout démystifié pas mal d'aprioris que j’avais sur
le sujet, et il est vrai que Microsoft a fait de très gros efforts pour
permettre à tout un chacun de créer de jolies interfaces, même pour les
amoureux des programmes en mode console comme moi.
Avec cet article, je vais tenter de vous montrer comment on
peut facilement faire un contrôle graphique en partant d’une page blanche, et
ce sans aucune compétence particulière en graphisme.
Lorsqu’on est en France et que l’on travaille dans les
logiciels de gestion pour le domaine de la santé, les questions de comment
remonter tous les numéros de sécurité sociale « non valide » d’une
table d’identifiants ou comment vérifier la validité d’un NIRPP dans un trigger
arrivent assez rapidement.
Or, le contrôle d’un NIR n’est pas si facile lorsque l’on
veut couvrir un maximum de cas (numéro temporaire pour les étrangers, département
d’outre-mer, corse, calcul de clé, …) .
Pour ceux qui veulent éviter de perde plusieurs heures (voire plusieurs jours) sur la meilleure solution à adopter pour ce problème très
franco-français, je vais essayer de vous synthétiser ma solution pour que vous
puissiez la réutiliser dans votre base de données grâce à une bonne vielle
requête SQL.
Si la programmation est une activité déjà bien complexe
lorsque l’on travaille seul, la difficulté est largement amplifiée quand le
programme nécessite d’y travailler à plusieurs, car ce dernier cas nécessite en
général une architecture divisée en modules à périmètre restreint pour
permettre une bonne séparation des concepts.
Bien que ce type d’architecture soit souvent mis en
œuvre, l’interdépendance entre les modules constitue rapidement le point faible
qui oblige les développeurs à bafouer toutes bonnes pratiques de séparations pour
arriver à leur fin.
Dans cet article, je
vais traiter d’une solution évoluée de « Transformation de données »
pour garantir à votre architecture modulaire de rester le plus intègre possible
au niveau des principes SOLID.
Il y a quelques semaines, j'ai dû mettre en place un script qui doit envoyer un email à la fin de son traitement. Rien de plus normal me direz-vous ?
Le truc fun de l'histoire c'est qu'en cherchant sur le net, je suis tombé sur un très vieux soft que j'avais écrit en C++ en l'an de grâce 2006 nommé HazyMail.
Cet outil permettait d'envoyer des mails sans avoir besoin d'un serveur SMTP, ce qui est quand même bien pratique.
Je me suis donc empressé de l'utiliser, et j'ai pu constater quelques disfonctionnements, notamment sur la partie pièce jointe. Je me suis alors dis qu'il serait pas mal de lui donner un petit coup de jeune en le redéveloppant en .NET 2.0 histoire que celui-ci soit Cross plateforme !