Accéder à la partie 1
Après une première partie qui s’est concentrée sur l’organisation d’un projet WPF/Silverlight, attaquons-nous à quelque chose de plus compliqué avec les techniques avancées…
Silverlight et WPF en entreprise : retours d’expérience, bonnes pratiques et techniques avancées par Luc Vo Van (Microsoft Services) et Thomas Lebrun (Access-IT)
Architecture type
WPF et Silverlight nous offrent la possibilité de développer des applications composites. Le pattern Models-Views-ViewModels dit MVVM est favorisé.
Lire la suite…
A chaque événement TechDays, c’est l’effervescence au sein de la communauté Microsoft. Pour commencer cette nouvelle année, c’est le Cloud qui était à l’honneur. Mais nous allons ici évoquer un sujet un peu moins brumeux et qui, nous, les développeurs .NET, nous concerne plus particulièrement : WPF & Silverlight.
A travers une série d’articles, nous ferons le point sur les principales conférences autour de WPF & Silverlight…
Changer la vie de vos utilisateurs en intégrant du design et de l’ergonomie par Olivier Courtois (Bewise)
De nos jours, nous avons affaire à des “superutilisateurs” qui ont des attentes surdéveloppées. Bien plus que par le passé, les applications doivent se soucier davantage du confort d’utilisation : on parle alors d’ergonomie. Pour pallier à des surcoûts postproduction, cette réflexion doit être posée en amont.
Le travail général de l’ergonomie s’effectue dans le cadre d’une réflexion centrée autour de l’utilisateur. Cette réflexion, auprès d’utilisateurs réels -dans le meilleur des cas- ou auprès d’utilisateurs fictifs, donne naissance aux exigences ergonomiques.
Lire la suite…
Je suis devenu un adepte du framework Play!. Je ne le pratique pas depuis longtemps, seulement depuis 10 mois environ. Mais la courbe d’apprentissage est vraiment rapide. Une semaine est suffisante pour être à l’aise et être autonome. J’ai la modeste prétention, dans cet article, de montrer 2 ou 3 trucs qui font de ce framework une nouvelle manière de voir le web en Java.
Pour commencer, Play! est très simple à installer. Il suffit de décompresser le zip dans un répertoire, et de créer une variable PLAY_HOME qui pointe sur ce répertoire. Play! a uniquement besoin de Java comme pré-requis pour fonctionner. Et c’est tout ! Pour rappel, la plupart des autres frameworks web Java ont au moins besoin d’un serveur d’application…
Comme Play! embarque un serveur web, il se suffit à lui-même. Cette notion est appelée “full-stack”. Elle signifie que Play! est autonome à la fois dans son mode de développement en proposant tout ce qu’il faut pour faire une application web, de la couche présentation à l’accès aux données, et également lors de l’exécution des applications Play! qui tournent grâce au serveur web intégré.
Play! propose de nombreuses fonctionnalités peu répandues dans le monde du web en java. Par exemple, le code modifié est pris à chaud par le serveur web, il suffit de rafraîchir le navigateur pour voir sa modification ! La gestion d’erreur est également poussée. Lorsqu’une exception se produit, l’erreur s’affiche très clairement dans le navigateur. Comme le montre l’image suivante :
Cliquez sur l'image pour l'agrandir
Le développement rapide est une des caractéristiques de Play! On passe beaucoup plus de temps à coder qu’à faire de la configuration ou de l’installation. Et ce n’est pas tout, Play! propose beaucoup de moyens d’accélérer le développement. Je vais donc vous en montrer quelques uns. Je ne compte pas énumérer tout ce qui fait que Play! permet de développer rapidement, mais seulement donner un aperçu.
Play! propose sur son site, une documentation très complète, ainsi qu’un tutoriel bien fait qui permet de se familiariser avec les notions principales du framework. Si on peut paraître sceptique devant tant de d’enthousiasme, faire le tutoriel permettra à quiconque de se rendre compte de la rapidité avec laquelle le développement se fait avec Play!.
Lire la suite…
Détecter les deadlocks en C# / .NET grâce au pattern IDisposable
Si vous êtes développeur en environnement multithread, alors vous vous êtes déjà posé cette question : Où est ce deadlock ? !
Bien sûr, ce deadlock est non-reproductible, il survient chez l’utilisateur, et l’on peut passer des heures à le chercher. Sans jamais être sur d’avoir trouvé LE deadlock qui pose problème !
Vous trouverez dans ce post un exemple de lock qui a pour objectif de
- Pouvoir détecter les deadlocks
- Proposer une syntaxe claire et concise
- Ajouter un overhead minimum en terme de performance à la syntaxe lock C# classique
Petit rappel : qu’est-ce qu’un deadlock ?
Un deadlock (interblocage dans sa version française que personne n’utilise) est la situation dans laquelle 2 threads s’attendent mutuellement. Cas concret :
- Un thread T1 acquiert une ressource R1
- Un thread T2 acquiert une ressource R2
- T1 demande la ressource R2
- T2 demande la ressource R1
Avec un schéma :
Exemple de code provoquant un deadlock
void CreateDeadLock()
{
Object R1 = new object();
Object R2 = new object();
Thread T1 = new Thread(delegate() { Work(R1, R2); });
Thread T2 = new Thread(delegate() { Work(R2, R1); });
T1.Start();
T2.Start();
}
void Work(Object acquire, Object demand)
{
lock (acquire)//T1 take R1 and T2 take R2
{
Thread.Sleep(1000);//To ensure that the ressources are taken
lock (demand)
{
}
}
}
NB : Bien sûr, les situations réelles sont souvent plus compliquées, impliquant par exemple plus de 2 threads ou des locks implicites (écriture dans un fichier…).
Lire la suite…
Les fondamentaux
En java, la comparaison s’effectue principalement en utilisant 3 méthodes qui n’ont pas les mêmes buts :
- L’opérateur == est utilisé pour comparer les types primitifs et les objets. Il compare uniquement les références. Cela signifie que l’opérateur retournera “true” uniquement si les 2 objets comparés sont les mêmes en mémoire.
- La méthode ‘equals()’ permet de comparer 2 objets. Toutes les classes ont une méthode ‘equals()’ héritée de la classe Object. Cette méthode compare la valeur de 2 objets. S’ils représentent la même chose, alors la méthode doit renvoyer “true”. Cette méthode est plus difficile qu’il n’y paraît à implémenter. Je pourrais revenir dessus ultérieurement dans un prochain article.
- La méthode ‘compareTo()’ permet de comparer 2 objets comme la méthode ‘equals()’. Contrairement à ‘equals()’, les classes ne définissent pas toutes cette méthode. Pour cela il faut hériter de l’interface Comparable. Cette méthode est utilisée pour pouvoir trier les objets l’implémentant. Si les 2 objets sont égaux, alors la méthode doit renvoyer 0 ; si un object O1 est considéré précédent un autre object O2 alors il faut renvoyer -1, si O2 précède O1 alors il faut renvoyer 1.
int i = 5, j = 5, k=8;
Integer int1 = new Integer(42) ;
Integer int2 = new Integer(42) ;
String str1 = "Blog";
java.util.Date t1 = new java.util.Date();
Thread.sleep(1000l);
java.util.Date t2 = new java.util.Date();
System.out.println (i == j); // print true
System.out.println (int1 == int2); // print false
System.out.println ("Blog".equals(str1)); // print true
System.out.println (str1 == "Blog"); // déconseillé mais écrit true
System.out.println (t1.compareTo(t2)); // print -1
Les comparaisons faites avec ‘equals()’ ou ‘compareTo()’ entre une variable et une constante doivent être réalisées comme à la ligne 13 de l’exemple précédent, c’est-à-dire qu’il faut comparer la constante avec la variable à tester. Ceci permet d’éviter une potentielle NullPointerException si l’on faisait ‘str1.equals(“Blog”)’.
Le cas particuliers des enum
Depuis java 5, les enum ont été introduits dans java. Les enum pourraient faire l’objet d’un article complet, mais il est bon de savoir que les enum ont été créés pour être comparés avec l’opérateur ‘==’. N’hésitez donc pas à les utiliser ! En plus d’être très lisibles, ils sont performants à l’usage.
Lire la suite…
L’effet corner
Lorsque des acteurs du marché parient à la baisse sur un titre du marché français, ils peuvent vendre ce titre à découvert au SRD (service de règlement différé) si ce titre y est éligible. Ceci leur permet de vendre des actions qu’ils n’ont pas encore, sans transfert d’argent.
Puis le jour de la liquidation (5ème jour ouvré avant le dernier jour du mois civil, pour le calendrier des liquidations c’est ici), ils doivent décider :
- de racheter les titres et donc encaisser (si le cours a baissé) ou payer (si le cours a monté) la différence
- ou de différer la livraison au mois suivant
Lire la suite…
