vendredi 18 décembre 2009

Veille technologique semaine 51

Pour le bulletin de cette semaine, je vous propose les sujets suivants :
  • la sortie de NetBeans 6.8 synchrone de l'implémentation de référence JEE 6 GlassFish V3. A noter le support de JavaFX 1.2.1.
  • le principe de l'inversion de dépendance : principe souvent mal compris et donc non utilisé. On entend parler de modularité et de re-use mais on oubli très souvent que du code fonctionnel qui dépend du socle technique (et donc du modèle de programmation du socle technique) est très peut réutilisable en dehors de ce socle technique. La meilleure traduction française trouvée est : "il ne faut pas construire le fonctionnel sur le socle technique [comme c'est le cas traditionnellement], mais il faut construire le socle technique sur le code fonctionnel". Question ; pouvez vous construire votre système et le faire tourner sans le socle technique ? Si la réponse est non, votre architecture n'est pas indépendante du socle technique, il n'y a pas d'inversion de dépendance : la probabilité de re-use s'effondre.
  • deux articles au sujet de la dette technique : c'est un sujet du bulletin de la semaine dernière, qui a intéressé quelques personnes. Je vous propose donc un complément.
  • un autre article au sujet du développement du logiciel.
  • un article sur la mesure de la productivité : c'est une question qui revient souvent.
  • la présentation d'Emmanuel Bernard faite au JUG de Paris au sujet des standards.
  • les nouvelles API de HTML 5 : le push
  • le projet Lambda intégré à OpenJDK : sur le chemin des closures pour le JDK 7
  • enfin les dernières mesures de perf des implémentation des langages les plus utilisés : le plus rapide est le C/C++ avec la valeur 1,
    Java est à 1.68 (1. 68 fois plus lent que le C/C++), Ada à 1.99, scala est à 2,8, C# mono à 3.3, l'interpréteur Java à 23, JRuby à 89 et Ruby à 94.
Bonne lecture.


Sun has released NetBeans 6.8, its open source IDE for Java. C++. PHP, and Ruby.
New features in this version include:

• EJB 3.1 support
• RESTful web services (JAX-RS 1.1), GlassFish Metro 2.0 web services (JAX-WS 2.2), JAXB 2.2
• Java Persistence JPA 2.0, deployment, debugging and profiling with GlassFish v3 application server
• Code completion, error hints, namespace completion, documentation popups, and tag auto-import for Facelets
• Editor support for Facelets libraries, composite components, expression language, including generators for JSF and HTML forms
• Customizable JSF components palette generates JSF forms and JSF data tables from entities
JavaFX SDK 1.2.1
• Editor Hints: Fix Imports, Surround With, Implements Abstract Methods, and more
• Improved navigation: Hyperlinks, Go to Type, Find Usages
• Full JIRA support
• Project dashboard with more member and project details, improved search and navigation, easier project sharing
• Improved instant messenger integration
• Improved issue tracker integration
• PHP 5.3
• Symfony Framework support
• PHPUnit, Code Coverage, FTP/SFTP integration improvements, exclude PHP project folders from scanning/indexing
• New Project from Maven archetype catalog and improved support for Java EE 6, Groovy, Scala projects
• Support for Rails 2.3.2 apps with dispatchers, JRuby 1.3.1, Ruby 1.9 debugging, and RSpec 1.2.7
• C++ Profiling: New Microstate Accounting indicator, Thread Map view, Thread Analyzer, Hot Spots view, Memory Leaks view, Sync Problems view
• C++ Parallelization Adviser
• Support for gdbserver attach and easier attaching to already running processes


Principe d'inversion des dépendances

Dependency Inversion Principle - DIP :
A. Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau.
Tous deux doivent dépendre d'abstractions.
B. Les abstractions ne doivent pas dépendre de détails.
Les détails doivent dépendre d'abstractions.


LES ARCHITECTURES CLASSIQUES NE PERMETTENT PAS LA RÉUTILISATION DES MODULES "MÉTIER"
Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :

Cela paraît naturel au premier abord mais pose en réalité deux problèmes essentiels :
• Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
• Il n'est pas possible de réutiliser les modules de haut niveau indépendamment de ceux de bas niveau. En d'autres termes, il n'est pas possible de réutiliser la logique d'une application en dehors du contexte technique dans lequel elle a été développée.


Il faut construire les parties "techniques" de l'application sur les parties "fonctionnelles",
et non l'inverse.


VERS DES FRAMEWORKS MÉTIER ?
Ce principe conduit à des applications dans lesquelles la logique "métier" est parfaitement réutilisable. Cette partie métier forme une sorte de "framework", qui permet de développer une même application dans des contextes techniques différents.


Technical Debt
The term "technical debt" was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term. Ward didn't develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it's a useful metaphor for communicating with technical staff, but I'm more interested in the metaphor's incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.


Dette technique - Technical Debt
C'est bien connu, une chose n'existe pas tant qu'elle n'a pas de nom.

L'informatique, discipline pas si jeune que ça, n'échappe pas à la règle même si certains ont tendance à oublier certains noms pour en faire apparaître de nouveaux.

Voici un terme qui a l'avantage de mettre en avant un fléau difficile à cerner de notre discipline : la dette technique. Il s'agit de mettre un nom sur une pratique généralisée dans le métier et qui constitue le principal problème de maintenance des systèmes informatique. Une traduction de l'entrée wikipedia sur le sujet pourrait être résumée ainsi :

La dette technique est un terme inventé par Ward Cunningham pour décrire une situation où l'architecture d'un système logiciel est conçue et développée trop précipitamment. L'analogie avec une dette financière vise à montrer que du code écrit médiocrement requiert le "paiement d'intérêts" par un effort de maintenance, qui serait plus petit ou inexistant si le code fut développé plus soigneusement et avec une planification à plus long terme.

Rearchitecturer et réécrire le code pour être plus maintenable est analogue au paiement de cette dette.

L'objectif d'une telle métaphore est bien de communiquer à des personnes qui n'ont pas de bagage technique mais qui sont pourtant en charge de l'allocation des budgets informatique, un problème essentiellement visible du développeur / architecte. La communauté des développeurs / architectes a tout intérêt à faire ressortir ces coûts dans l'objectif d'améliorer la qualité des logiciels et de rendre plus intéressant et utile la profession d'informaticien.

Mais un frein à la diffusion de cette information est le flou autour de ces coûts car la dette technique est à la base de la forte rentabilité des société de service en ingénierie informatique. Une SSII a tout intérêt a construire une application peu chère mais avec une forte dette technique pour qu'elle puisse continuer à faire de la marge sur la maintenance du système.


Développement logiciel : Doit on continuer à ignorer l'évidence ?
Nous l'avons constaté encore une fois, une fois de trop sans doute. L'un de nos clients s'est mis tout seul (car les responsables d'une telle situation travaillent bien dans la même entreprise que celle où officie notre interlocuteur) dans une situation perdant / perdant avec son intégrateur dans le cadre d'un projet développé au forfait. Quels sont les faits ? Nous pourrions, sans même lui laisser la parole, nommer une à une toutes les difficultés qu'il rencontre, les yeux fermés, à la manière d'un chapelet qu'on égrène.


Comment mesurer la productivité ?
Depuis toujours, dans le monde du logiciel, on entend « Il faut augmenter la productivité des développements ». Il ne suffit pas d'en parler pour améliorer la productivité. Comment passer d'un slogan très abstrait à des actions concrètes et des résultats tangibles ?

On ne peut améliorer que ce que l'on mesure. Il est donc impératif de trouver un indicateur permettant de vérifier l'amélioration recherchée. Les mesures comme le nombre de lignes de code ou le nombre de points de fonctions, encore utilisées aujourd'hui, sont trop éloignées de la valeur produite pour être intéressantes. Un indicateur beaucoup plus proche de la satisfaction client, et donc plus pertinent, est « le nombre de fonctionnalités sans erreur ajoutées à un logiciel durant un période donnée », ce que l'on pourrait appeler le débit de fonctionnalités.
  • Nombre de fonctionnalités ajoutées à un logiciel
  • Sans erreur
  • Durant une période donnée

Présentation sur les Standards par Emmanuel Benard au JUG de Paris
L'objet de la présentation d'Emmanuel Bernard est limpide : « Les Standards : caca ou pas caca ?" .
Avec un sujet décalé, exercice imposé par Antonio, il s'en est très bien sorti. Emmanuel pour ceux qui auraient été dans une grotte ces derniers mois, travaille chez JBoss RedHat, s'occupe du Podcast « Les CastCodeurs« , blog de temps en temps et trouve aussi le temps d'être membre du Java Community Process en participant à la spécification JPA 2.0 et en étant Spec Lead de la JSR-303 (Bean Validation). Avec tout cela, il trouve le temps de venir au Paris JUG, c'était bien sympa.

La légende veut que les spécifications désignées par des comités d'experts
soient lourdes et inadaptées au marché. A l'opposé, le monde de l'open-source est un univers merveilleux où tout se passe bien, les gens s'éclatent et s'entendent super bien pour faire de magnifiques logiciels.

En conclusion
Pour terminer, Emmanuel explique qu'un bon standard doit être stable, extensible, ouvert sur le futur et surtout adopté par la communauté. L'objectif de Java EE 6 est de proposer un socle normalisé, afin que maintenant la communauté mette son énergie sur de nouveaux problèmes. Et là, mesdames et messieurs, il a raison. Bon sang quel temps perdu pendant 3 ans, nous devons maintenant passer à autre chose, et commencer à réfléchir à des serveurs de 4ème génération.


Le point sur les nouvelles API HTML 5
  • Le point sur les technologies actuelles
  • WebSockets
  • Server-sent events
  • XmlHttpRequest v.2
  • Cross-document messaging
  • Conclusion

Le projet Lambda apparaît au sein d'OpenJDK
Mark Reinhold annonce la création d'un nouveau sous-projet au sein d'OpenJDK : le Projet Lambda. Son but est d'apporter une implémentation des closures pour le JDK 7. Dans la mesure où il est prévu que cette fonctionnalité soit implémentée dans un premier temps pour être spécifiée par la suite, il sera particulièrement intéressant de suivre l'évolution de ce projet dans les prochains mois afin de découvrir à quoi pourraient ressembler les closures dans la prochaine version de Java.

Un premier document de travail a été mis à disposition. Il présente de manière non formelle la proposition pour l'implémentation des closures qui est retenue pour le moment. Cette proposition se base sur les trois principales bases de travail qui s'étaient dégagées lors des débats précédents, à savoir la BGGA, la CICE et la FCM. Elle met en avant principalement :

• La syntaxe retenue pour la définition de fonctions anonymes qui se base sur le caractère #, ainsi #()(42) définit une fonction retournant toujours 42.
• La définition d'un type Java pour ces fonctions. Ainsi la fonction #()(42) prise en exemple précédemment a pour type#int().
• Les fonctions anonymes peuvent être converties automatiquement lorsqu'elle sont passées en argument d'une méthode attendant une instance d'une classe anonyme. En clair, il sera possible de créer une nouvelle thread avec new Thread(#() { ...some code... } ) plutôt que de fournir au constructeur une classe anonyme implémentantRunnable pour définir la méthode run(). Cette possibilité permettra donc aux closures d'être utilisées directement dans les APIs existantes !
• Dans certaines conditions, les closures sont à même d'utiliser les variables accessibles dans le contexte dans lequel elles sont définies.
• Le mot clé this peut être utilisé si la closure est déclarée depuis une méthode d'instance, il référence alors l'instance à laquelle est attachée la méthode concernée.

Enfin, pour faciliter les évolutions des APIs existantes que pourraient justifier ces nouvelles possibilités du langage, la notion de méthodes d'extensions est introduite. Il s'agit de permettre la définition de méthodes au sein des interfaces dont l'implémentation par défaut serait une méthode statique indiquée en argument.

Pour plus de détails sur cette proposition, n'hésitez pas à lire le document de travail, volontairement très didactique, du projet Lambda.


Project Lambda: Straw-Man Proposal
This is a straw-man proposal to add first-class functions, function types, and lambda expressions (informally, "closures") to Java.
1. Lambda expressions
2. Function types
3. Function conversion
4. Variable capture
5. Instance capture
8. Extension methods


Les expressions lambda (closures) se dotent de méthodes d'extension !
C'est fait, le projet Lambda est né de la volonté d'intégrer un système de closures, que l'on nommera désormais "expressions lambda".

On y retrouve donc une liste de diffusion mais surtout un prémice de la proposition : Project Lambda : Straw-Man Proposal.


Computer Language Benchmarks Game

1 commentaire:

Anonyme a dit…

RsgYrv [url=http://www.outletmonclerspacciopiumini.com/]outlet Moncler[/url] VzbQbz http://www.outletmonclerspacciopiumini.com/

AjnEuq [url=http://www.vnikefree.com/]Nike Free Run Danmark[/url] RafOqf http://www.vnikefree.com/

GefDgc [url=http://www.outletmonclerspaccio.com/]Moncler Piumino[/url] LzqZro http://www.outletmonclerspaccio.com/

HxdWwr [url=http://www.Jakker2canadagoose.com/]Canada Goose From Canada[/url] OvzYkh http://www.Jakker2canadagoose.com/

CxaUsj [url=http://www.parkajakker4canadagoose.com/]Canada Goose Jakke[/url] WwhUjp http://www.parkajakker4canadagoose.com/

IjfCzf [url=http://www.jakke2canadagoose.com/]Canada Goose[/url] YbwRrr http://www.jakke2canadagoose.com/

UrlXor [url=http://www.canadagoosefromcanada.com/]Canada Goose Parka[/url] QeeAiv http://www.canadagoosefromcanada.com/