Quand les closures nous facilitent la vie
Aujourd’hui j’ai une devinette pour vous. Elle est très simple, mais je suis obligé de l’introduire par une mise en situation un peu pénible. Soyez courageux, il n’y a rien à gagner.
Imaginez une application capable de recevoir des messages du réseau. Lorsqu’un message de type A est reçu, l’application doit afficher à l’utilisateur une fenêtre assez complexe construite à partir des données du message. L’utilisateur peut ensuite interagir avec la fenêtre en question, avant de la fermer.
Les contraintes :
- Les fenêtres doivent être affichées très rapidement, l’utilisateur devant être averti le plus tôt possible de l’arrivée d’un message de type A.
- Les fenêtres ne sont pas modales, il peut donc y en avoir plusieurs affichées simultanément.
- La construction des fenêtres (création des différents contrôles graphiques) est relativement longue.
- Les opérations de binding entre les données du message et les contrôles existants d’une fenêtre sont rapides.
Je ne t’aime plus, ordinateur
Il faut absolument que je remplace mon PC actuel. Il est dépassé, bruyant, et moche. Et bruyant. Je n’ai pas attendu de déballer l’iMac de Grozeille pour décider ça. A vrai dire, ça fait plus de 6 mois que je dois absolument remplacer mon PC actuel.
Je voudrais trouver, aux alentours de 55 000 roubles, une machine assez silencieuse et suffisamment puissante :
- Pour que je puisse dormir dans mon appart sans avoir à fermer toutes les portes ou éteindre la bête.
- Pour que VisualStudio se lance aussi rapidement que notepad et que je puisse enfin faire tourner Firefox UnrealEditor 3.
Au delà de l’Intégration Continue : le Monitoring Continu
Je viens de terminer l’écoute d’un des derniers podcasts de Scott Hanselman, dans lequel il échange avec Owen Rogers. La discussion tourne autour de l’intégration continue. Owen est assez au courant : il est l’un des créateurs de CruiseControl.NET, le serveur d’intégration continue sans doute le plus utilisé dans le monde .NET.
Ce que j’ai trouvé intéressant, voire original dans cette discussion, c’est le développement qui a eu lieu autour de l’idée du monitoring.
En introduction, Scott joue l’ingénu et demande à Owen pourquoi on aurait besoin d’un serveur d’intégration continue alors qu’un pauvre script planifié pourrait très bien faire l’affaire. Owen lui fait la liste des principales caractéristiques et avantages d’une solution comme CruiseControl, et insiste tout particulièrement sur la capacité d’un tel système à produire et agréger différents rapports concernant les builds et les projets. Il explique également qu’au delà des fonctionnalités de journalisation et de statistiques, un outil d’intégration continue offre des mécanismes de notification pouvant informer les équipes en temps réel, et leur fournir des détails sur l’état des différentes builds.
En effet, la notion de feedback est indissociable de l’intégration continue.
L’effet Tetris en informatique
Quand on est au niveau 3, ça va, on peut encore placer les pièces comme on le veut. Je veux dire par là qu’il est possible de les placer de façon presque optimale, pour faire un gros bloc bien compact sur la gauche de l’écran en attendant une grande barre pour dégager 4 lignes d’un coup. Les 4 lignes d’un coup, ça s’appelle un Tetris, d’ailleurs.
Lorsqu’on arrive au niveau 10, par exemple, il devient plus dur d’enchainer les Tetris. Je suis certain qu’on peut trouver un japonais sur YouTube qui y parvient en chantant le générique de Naruto à l’envers, mais nous ne nous laisserons pas distraire pas les exceptions de ce genre aujourd’hui. Au niveau 10, on ne peut pas enchainer les Tetris, c’est tout. Pourtant, il y a pas mal de gens qui arrivent à tenir un moment au niveau 10, jusqu’au niveau 11 même, et beaucoup plus loin encore.
Parce qu’ils ne cherchent pas à enchainer les Tetris, justement. S’ils essayaient, le temps de réflexion nécessaire au placement de chaque pièce serait largement supérieur à celui qui leur serait accordé. Les pièces tomberaient alors les unes après les autres sans avoir été pilotées, en formant un petit tas famélique qui atteindrait rapidement le haut de l’écran.
La conclusion est la suivante : Le choix d’une solution « assez bonne » peut s’avérer plus rentable que d’investir beaucoup de temps et d’efforts dans la recherche d’une solution « très bonne », ou « parfaite ».
Et ça a même un nom : l’effet (ou stratégie) Tetris. On en trouve quelques bons exemples d’application dans le monde de l’informatique.
(more…)
Constructeurs statiques en C#
On m’a posé une question il y a quelques temps :
« Et en C#, il y a l’équivalent des blocs static de Java ? »
La réponse est oui. En C# on peut définir des constructeurs statiques qui seront exécutés lors du premier des deux événements suivants :
- Une instance du type est crée.
- Un membre statique du type est accédé.
La Veille Technologique et le Génie Logiciel
Tous les informaticiens ont conscience de faire partie d’un monde en permanente évolution. C’est tellement évident que même les plus obtus et les moins à jour arrivent à le reconnaitre. Tous ne prennent pas la peine de trouver des excuses ; l’essentiel étant surtout de conserver sa petite bulle de confort. Je me demande si tout ça est encore possible aujourd’hui, ou pire, inévitable.
Au XVIème, Léonard de Vinci imaginait des machines volantes. En 1903, les frères Wright faisaient décoller (et voler un peu) le premier avion. Quelques 65 années plus tard, l’Homme marchait sur la Lune. Ce matin, j’apprends en lisant un article sur Futura-Sciences qu’on aurait retrouvé les protons manquants de l’univers. Formidable.
Et bien pour moi, l’ingénierie logicielle, c’est un peu pareil.
La vitesse d’évolution des techniques et la multiplication des outils dans ce domaine atteignent des proportions vertigineuses et continuent de croitre de façon exponentielle. Cela pourrait même poser un problème à tous ceux qui veulent garder la tête hors de l’eau. On en arrive à se demander si dans quelques années, la veille technologie sera encore possible à l’échelle de l’individu sans que d’importants compromis soient faits.
(more…)
Continuer l’optimisation avec la Lightweight Code Generation (LCG)
Cet article est un complément du précédent. Vous pouviez y lire dans la conclusion :
Nous nous sommes contentés d’évoquer la solution d’optimisation impliquant la génération de code IL. Dans le contexte de la problématique discutée, elle n’offrait aucun avantage par rapport à celle que nous avons exposée. Pire, elle imposait une étape inutile. Toutefois, certains besoins plus complexes dépassent le cadre des invocations dynamiques de méthodes et peuvent tout de même être adressés efficacement en recourant à la génération de bytecode.
S’il existe des scénarios dans lesquels le recourt à la LCG est inutile voire pénalisant, il n’y a parfois aucune autre alternative lorsqu’il s’agit de mettre en place une solution où les performances sont aussi importantes que la dynamicité.
Vous ne trouverez pas ici un tutorial sur l’utilisation de Reflection.Emit, mais plutôt un exemple d’utilisation de cette technique pour répondre de façon optimale à un besoin bien spécifique. Nous essaierons en parallèle de faire ressortir quelques guidelines relatives à l’usage de la LCG.
(more…)
Optimisation des invocations dynamiques de méthodes en C#
Je travaille actuellement en tant que consultant .NET sur un projet d’une certaine taille.
Travailler sur un projet d’une certaine taille ne signifie pas forcément que l’on travaille sur un projet intéressant, mais ça augmente sensiblement les chances de rencontrer de nouveaux problèmes. Il n’est pas question aujourd’hui de définir ce qu’est un projet d’une certaine taille, ni même de démontrer le postulat précédent ; il s’agit plutôt de parler d’une des dernières problématiques auxquelles j’ai dû faire face :
Comment éviter que les invocations dynamiques de méthodes via la réflexion rendent les performances d’une application ou d’un module catastrophiques ?
Réponse : En minimisant l’utilisation de la réflexion. C’est ce que je vais tenter de développer à travers un exemple directement inspiré du projet réel, quoiqu’adapté pour les besoins de l’article. Le langage utilisé sera C# 3.0, mais rien n’empêche d’utiliser C# 2.0.
(more…)
Le mot clé yield et les itérateurs en C#
Cet article est un peu particulier. D’une part, il s’agit de mon premier vrai post, et d’autre part, j’ai choisi de traiter en détail un sujet pas forcément nouveau et surtout très spécifique : les itérateurs et le mot clé yield de C#.
C’est pas ma faute, tout le monde (ou presque) s’en fout, ou ne sait pas qu’il existe.
Pourtant, ce mécanisme n’est pas seulement troublant, il est également puissant lorsqu’on l’utilise en maitrisant son fonctionnement. S’il me fallait trouver un exemple, je parlerais de l’implémentation principale de LINQ, basée sur les itérateurs et le mot clé yield.
yield. Par contre, si vous cherchez à comprendre le fonctionnement réel des itérateurs, il peut s’agir d’un bon point de départ. C’est un peu le parallèle que l’on pourrait faire entre la MSDN et le livre des spécifications de C#.Je ne suis pas Jeff Atwood
Je suis beaucoup moins riche connu que lui. Mais nous avons tous les deux eu envie d’avoir un blog ; j’ai juste un peu de retard.
Comme le fait remarquer Jeff, le meta-blogging est quelque chose d’assez pénible. Je suis d’accord, et pourtant je pense qu’on a le droit de le commettre au moins une fois, la première.
Articles
Codingly 
3 comments