Devoxx 2011 – Utilisation du GPU pour les applis Android

Par | Classé dans Conférence, Intermédiaire | Le 25/11/2011

Tags « »

0

Chet Haase et Romain Guy nous ont présenté pendant Devoxx lors de la conférence Graphics goodies in Android, les nouveautés d’Android pour développer des applications qui tuent. Nous allons voir dans cet article l’utilisation de l’accélération graphique pour les rendus 2D des applications Android 3.0 et supérieures.

L’openGL existe depuis les premières versions d’Android pour les jeux et certains autres composants mais l’interface graphique des applications a toujours été “SOFTWARE”.
Depuis Android 3.0 il est possible d’activer l’accélération graphique pour chaque application ce qui nous permet d’avoir une meilleur expérience utilisateur, avoir des animations plus fluides et de libérer un peu le CPU.

Lire la suite…

Ou comment reporter à plus tard…

Par | Classé dans BRMS, Intermédiaire | Le 15/06/2011

Tags « »

0

Tel que l’analyse Neal Ford à travers son concept d’Emergent Design, plus un projet (informatique) avance, plus les connaissances sur celui-ci sont avancées, ce qui demande à reculer au maximum toute prise de décision concernant ce projet.

La connaissance acquise est essentiellement métier et ergonomique (pour autant que la technologie employée est maitrisée). Si pour les aspects ergonomiques, un prototypage graphique peut (ou devrait) être proposé, comment faire de même avec le code sous-jacent, le code représentant les connaissances métier ?

Un première approche se base sur un processus itératif, suivant un processus dit “agile”. Cela est toutefois rarement compatible avec des langages de développement “classiques”. En effet, il faut alors prendre très tôt des décisions majeures et structurantes. De plus les changements deviennent de plus en plus difficiles et coûteux. Il conviendrait donc de pouvoir poursuivre le plus tardivement possible la phase de conception, ce qui peut apparaître contradictoire avec cette approche “agile”. De plus, l’expérience montre que même les meilleures des conceptions ne peuvent prévenir de nécessités de correctifs en phase de réalisation.

L’idéal serait donc de pouvoir disposer d’un langage tout à la fois de spécification tout en étant exécutable pour pouvoir valider cette même spécification à travers des cas de test. Cela est rendu possible par des langages de type “règles métier”. En effet, ceux-ci permettent pour la plupart de construire des modèles objets (dits “BOM”) de façon souple, voire dynamique, tout en proposant (plus ou moins automatiquement suivant le Business Rule Management System utilisé) un langage de type DSL permettant d’exprimer et d’exécuter des règles métier s’appliquant sur ces objets.

À noter que les principaux BRMS proposant une couche d’interfaçage entre le code décrivant les règles et le framework sous-jascent (Java, .NET, xml, Cobol, etc.), il est tout à fait possible de ne faire le choix de ce(s) framework(s) (plusieurs pouvant cohabiter) que tardivement en fonction des contraintes finales de l’application à développer.

On s’aperçoit également que cette technologie permet de gérer beaucoup plus facilement les cas particuliers. En effet, ces “cas” sont en général caractérisables par un ensemble de contraintes, pouvant être soit directement exprimées au niveau des règles, soit être gérées par le ruleflow. De plus, le fait d’exprimer clairement le domaine métier au sein de règles fait ressortir beaucoup plus facilement ces cas “hors normes”.

Enfin, il est bien rare que la première mise en production d’une application soit la dernière pierre de l’édifice. Les phases de maintenance et de migrations sont primordiales dans la vie d’un logiciel. Des correctifs et évolutions sont donc à prévoir. Ici aussi, les points soulignés ci-dessus (changement de framework sous-jascent, traitement des cas particuliers, etc.) pourront être mis à profit. Avec de plus un avantage décisif par rapport aux langages informatiques traditionnels : le code des règles étant tout à la fois le code exécuté (et donc évoluant avec les mises à jour) et les spécifications de l’application, il y a alors garantie de non divergence entre ces deux aspects, ce qui bien qu’essentiel pour la maintenance est rarement le cas pour la plupart des applications informatiques.

En conclusion, l’usage d’une approche “règles métier” permet de changer radicalement le mode de développement d’applications informatiques, tout particulièrement en permettant de retarder les prises de décisions au moment où la connaissance du sujet est enfin suffisamment avancée, tout en facilitant les ajustements rendus nécessaires dans les phases ultérieures du projet.

WPF & Silverlight : L’état de l’art au Microsoft TechDays 2011 (partie 2)

Par | Classé dans .NET, Avancé, Conférence, Intermédiaire | Le 05/04/2011

Tags « »

0

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…

Détecter les deadlocks en C# / .NET grâce au pattern IDisposable

Par | Classé dans .NET, Avancé, Intermédiaire | Le 09/02/2011

Tags « »

5

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

  1. Pouvoir détecter les deadlocks
  2. Proposer une syntaxe claire et concise
  3. 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 :

  1. Un thread T1 acquiert une ressource R1
  2. Un thread T2 acquiert une ressource R2
  3. T1 demande la ressource R2
  4. 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…

BRMS, But When?

Par | Classé dans BRMS, Intermédiaire | Le 04/11/2010

Tags « »

0

“When should we, or not, use BRMS?” is the Question that arises almost every time Business Rules Management Systems are under discussion. Well, that’s a decision making, which may be handled by rules, in the form of a Decision Table…

The proposed rules to answer that question are not only based on technical aspects of BRMS, but also on organizational ones. In fact, those organizational aspects are often more important than the technical ones in the adoption of BRMS. Of course, those rules are not well formalized and their “Right Hand Side” (“then” part) may vary depending on the case. However, we hope that the following table could help in choosing or not a BRMS to develop an application.

Lire la suite…