Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J’en entends déjà pester « encore un truc de geek »…Le pilotage par les tests se résume à ces deux points clés:

• remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l’ambiguïté du langage courant par des spécifications exécutables c’est à dire vérifiables concrètement et fournissant une réponse sans appel: « vert » ou « rouge ».

• Piloter non pas sur un « reste à faire » – concept obscur car que met on dans le « reste à faire »? – mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d’avoir un outil permettant aux « fonctionnels » d’écrire simplement – c’est à dire dans leur vocabulaire – les spécifications exécutables et permettant aux « managers » de piloter les développements.

(Lire la suite…)

Le texte suivant est extrait du livre « Une Politique pour le Système d’Information – Descartes – Wittgenstein- (XML) » publié par OCTO Technology :

SOA est l’archétype de la régression collective. Rien de grave, cela arrive dans tous les secteurs. Après DCE, Corba, l’urbanisme des SI et les outils d’EAI, voici le serpent de mer resurgir encore.

Et il y a une bonne raison à sa résurrection : toute réalisation informatique qui implique plus d’une application est un cauchemar : coordination, construction à plusieurs, tests à plusieurs, stress à plusieurs…

Alors les solutions fusent, toujours les mêmes : il faut diminuer le nombre de boîtes et le nombre de fils entre les boîtes.

(Lire la suite…)

Tout d’abord il faut préciser une petite chose : le périmètre fonctionnel des deux frameworks est totalement différent :

Spring est un framework qui entend couvrir l’ensemble des problématiques allant de la simple application CRUD à l’application d’entreprise :

• Injection de dépendances (Spring Core)
• Programmation orientée aspect, Transactions déclaratives (Spring Core & Spring AOP)
• Couche d’abstraction des framework ORM, proposant des Templates (méthodes CRUD, Finders,etc…) et exceptions typées selon le code retour de la base de données (Spring DAO)
• Composants permettant l’utilisation de JMS, JMX, WebServices, Scheduling (Spring JEE)
• Technologie de présentation MVC (Spring Web, Spring Web Flow…)

Google Guice couvre principalement l’injection de dépendances (également l’AOP, mais cela reste assez basique). C’est donc sur l’IoC qu’il est opportun d’effectuer une comparaison avec Spring.

Google Guice s’appuie principalement sur les fonctionnalités de JAVA 5, et plus précisément sur les annotations pour la configuration.

Les principaux reproches fait à Spring concernent la configuration, principalement sur les fichiers XML qui deviennent complexes et difficiles à maintenir dès lors que l’application devient conséquente. Même avec la version 2, sortie tout récemment, Spring n’a pas véritablement simplifié cette configuration qui reste basée sur du XML.

(Lire la suite…)

Vous concevez une architecture distribuée en utilisant des services Web ?

Bien ! Mais vous êtes-vous posé la question du style architectural, c’est-à-dire du choix entre une approche orientée appel de procédure à distance ou une approche orientée manipulation de ressources ?

Et celle du choix entre une pile de protocoles lourde ou une pile légère pour les échanges avec les services Web ? Vos décisions auront un impact important sur les propriétés de votre système : complexité, facilité d’évolution, obsolescence technique, capacité à monter en charge, stabilité, ouverture.

Nous proposons ici un tour d’horizon des grandes options architecturales… et quelques précieux conseils…

Téléchargez la suite sur www.octo.com

Mars 2006. La comète Grails fait son entrée dans la galaxie Java en sortant sa première version publique. Inspiré par le succès du framework Ruby on Rails, Grails propose alors d’en adapter la recette à la sauce Java. Sa promesse ? Fournir une solution simple, rapide et élégante pour développer des applications Web J2EE pour l’entreprise.

Mars 2007. A quelques jours du premier anniversaire du framework, force est de constater que l’engouement autour de Grails reste intact. Chez OCTO comme chez nos clients, de premières références significatives voient le jour en production. On commence à y croire : Avec Grails, ca va vite.

Grails venant enrichir une panoplie de solutions déjà à notre disposition pour nos développements Web, des questions se posent : Choisir Grails, pourquoi pas, mais dans quels cas ? Est-il adapté aux contraintes d’un SI d’entreprise ?

Dans quels contextes et de quelle manière Grails peut-il faire la différence ?

(Lire la suite…)

Le texte suivant est extrait du livre « Une Politique pour le Système d’Information – Descartes – Wittgenstein- (XLM) » publié par OCTO Technology :

Pour la DSI, l’off-shore consiste à sous-traiter des activités de build dans des pays à plus faible coût. Il s’agit donc d’un modèle de faire-faire tout à fait identique au mode d’achat de prestations au forfait en France. Un pur réflexe sécuritaire nous défend encore de sous-traiter massivement les activités d’hébergement du run [1], a priori pourtant plus simple à contractualiser. Nous nous en tenons donc pour l’instant aux fonctions de support (H24, multi-langue, etc).

Ce modèle de construction de SI peut s’appliquer à la zone rationalisée, mais assez mal, nous l’avons vu dans  » La Frontière « , dans les activités d’innovation, par essence in situ, car riches d’interactions orales rapides.

(Lire la suite…)

Les annonces dans la communauté maven étant très riches, nous vous fournirons désormais en début de chaque mois un récapitulatif des annonces du mois précédent.

(Lire la suite…)