vendredi 4 janvier 2008

Veille techno semaine 1

    Meilleurs vœux à vous et à vos proches pour cette nouvelle année 2008.

    Pour cette première semaine, et pour bien commencer l'année,
    je vous propose les articles suivants :

    • pourquoi les projets logiciels sont en échec, par Bruce Eckel,
    • pourquoi la séparation du code métier et du code technique est fondamentale ? : il faut être technologie agnostique,
    • pourquoi le développement du logiciel centré sur le domaine ?,
    • vous préférer la configuration par fichier XML ou par annotations ?
    • les annotations et la programmation par aspects : article d'IBM,
    • le résultat des vote fait à JavaPolis au sujet des proposition d'évolutions du langage Java pour le JDK 7

    Bonne année à tous et bonne lecture.

    The Mythical 5%

    • 50-80% of programming projects fail.
    • 5% of programmers are 20x more productive than the other 95%.
    • Roughly 80% of programmers don't read books, don't go to conferences, don't continue learning, don't do anything but what they covered in college.
    • So how do you become one of these mythical 5%?

    So you must learn continuously and teach yourself new technologies, but it's not that simple. It's definitely good to learn more about programming, but you can't just learn more about programming. For example, just in the world of code, here are two of the biggest pain points:

    • Code is read much more than it is written. If people can't read your story, they can't improve it or fix it. Unreadable code has a real cost, and we call it "technical debt."
    • Code reviews are the most effective ways to find software defects, and yet we usually "don't have time for them."

    Coming from the world of ones and zeroes we'd like to believe that things are deterministic, that we can provide a set of inputs and get the same outputs every time!

    Separating business logic from technology:
    Separating business logic from user interface code was one of important lessons that legacy Visual Basic programs taught us. Kathleen Dollard actually argues that business logic should be separated from any technology to avoid rewriting everything when a new technology comes up. And, according to Kathleen, code is technology, thus business knowledge has to be isolated from it as well:

    such approach requires a fundamental shift in the way we conceive programming.

    Aspects of Domain Model Management
    As can be learned from books such as Domain Driven Design [Evans DDD] and Applying Domain Driven Design and Patterns [Nilsson ADDDP], introducing the Domain Model pattern (Patterns of Enterprise Application Architecture [Fowler PoEAA]) into your application architecture may promise many benefits, but they do not come for free.

    Take care of your domain model
    Today, many projects focus on Domain-Driven Design, but it is not always easy. One of the most important things are to separate the domain code from the code that only exists for technical reasons.

    The argument for avoiding infrastructure code in the domain model classes is strong: The domain model is supposed to represent the core business concepts that our application is dealing with. Keeping these classes clean, lightweight and maintainable is an excellent architectural goal for an application that intends to make heavy use of its domain model.

    On the other hand, as we will go on to see, taking the extremist route of keeping our domain model classes completely free of infrastructure code - often referred to as using a Plain Old Java/CLR Objects (POJO/POCO) domain model - can also prove problematic.

    Configuration en Annotations Java ou en XML ?
    L'arrivée de Guice dans le monde des frameworks de dependency injection a entraîné pas mal de questionnements. Google a adopté dans Guice la configuration tout en Java : tout ce fait à base d'annotations et de l'API. De fait, il n'y a plus de fichier de configuration XML.

    C'est encore un des reproches que l'on entend sur Spring : on déporte beaucoup de choses dans un fichier XML qui ne compile pas et pour lequel on n'est pas assisté.

    Dans le même ordre d'idée, Les nouvelles annotations créées avec JPA (Java Persistence API) changent aussi notre façon de configurer Hibernate. Avant, on configurait tout dans le bon vieux hibernate.cfg.xml, maintenant on a la possibilité de le faire avec les annotations. Maintenant que nous avons le choix : quelle solution doit-on préférer ? Java ou XML ?

    Spring JavaConfig
    Reference Documentation
    Annotations, available in JDK 5+, constitute such a type as they allow source code components to provide additional metadata which can affect the runtime semantics, making them a great configuration candidate.

    AOP@Work: AOP and metadata: A perfect match
    In this second half of his two-part article on combining metadata and AOP, author and AOP practitioner Ramnivas Laddad suggests a novel way to conceptualize metadata as a signature in a multidimensional concern space. He also introduces a series of guidelines for effectively combining metadata and AOP and discusses the impact of metadata annotations on the adoption of aspect-oriented programming.

    • The tyranny of the dominant signature
    • Signature tangling
    • Untangle me, metadata!
    • Metadata as a multidimensional signature
    • Mapping signature space to concern space
    • Enabling multidimensional interfaces
    • Guidelines for using metadata correctly
    • Wisdom comes with experience
    • Metadata and obliviousness
    • Metadata and AOP adoption
    • Conclusion

    Java Language change survey: the result
    Two whiteboards were dedicated to language changes, with 10 ideas considered. A short example of each change was given, with votes being taken. The question each time was "Do you support this language change?".