Codingly

Tous les développeurs savent qu’il faut être prudent lorsqu’on est en Corée du Nord ou lorsqu’on s’amuse avec les Winforms dans un contexte multi-threads. On ne doit pas, plus précisément, accéder à un contrôle graphique à partir d’un thread différent de celui dans lequel il a été créé. Ceux qui ont essayé (tous, je crois) ont découvert qu’une InvalidOperationException était levée :
(Lire la suite…)

Les développeurs passent souvent du temps à configurer et personnaliser leur environnement de travail (système, outils, etc.). On peut même croire parfois qu’ils en font trop.

J’en fais sans doute trop, mais peu me chaut. Après tout c’est mon environnement de travail.

Aujourd’hui je vous donne un aperçu du thème que j’utilise dans Visual Studio. En fait je le rends même disponible en téléchargement, bien que je ne sache pas vraiment s’il s’agit d’un cadeau. Il est basé sur l’excellente font de Damien Guard : Envy Code R et c’est un grey background theme. Pour ceux qui codent en plein écran, c’est assez reposant.
(Lire la suite…)

Si certains d’entre vous trouvent pénible le fait de devoir s’assurer qu’un évènement est non null avant de le lancer, voici une idée :

Profitez de la contravariance sur les delegates et initialisez votre event de la sorte :

(Lire la suite…)

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.

(Lire la suite…)

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 accès à un membre statique de la classe.

(Lire la suite…)

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.
(Lire la suite…)

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.
(Lire la suite…)

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.

(Lire la suite…)