Commentaires pour Le Touilleur Express http://www.touilleur-express.fr Blog sur Java, J2EE, Scrum,Apple,iphone par Nicolas Martignole Thu, 29 Jul 2010 09:52:15 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Commentaires sur Jouez les Docteurs Love, apprenez à nettoyer du vieux code par fabszn http://www.touilleur-express.fr/2010/07/28/jouez-les-docteurs-love-apprenez-a-nettoyer-du-vieux-code/comment-page-1/#comment-3606 fabszn Thu, 29 Jul 2010 09:52:15 +0000 http://www.touilleur-express.fr/?p=4099#comment-3606 Hello, @Oaz : c'est une des principales difficultés que j'ai rencontrée dans mon équipe;concernant : "Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif Ces règles ne peuvent fonctionner que si l’ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c’est parfois plus dur à obtenir qu’un budget…" Hello,

@Oaz : c’est une des principales difficultés que j’ai rencontrée dans mon équipe;concernant : « Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif
Ces règles ne peuvent fonctionner que si l’ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c’est parfois plus dur à obtenir qu’un budget… »

]]> Commentaires sur Jouez les Docteurs Love, apprenez à nettoyer du vieux code par Oaz http://www.touilleur-express.fr/2010/07/28/jouez-les-docteurs-love-apprenez-a-nettoyer-du-vieux-code/comment-page-1/#comment-3605 Oaz Wed, 28 Jul 2010 23:29:36 +0000 http://www.touilleur-express.fr/?p=4099#comment-3605 @Yannick G. Ce qu'il y a d'extraordinaire avec le métier du développement logiciel, c'est que le budget est principalement une décision venant des développeurs eux-mêmes, du temps qu'ils décident, en leur ame et conscience, à allouer à telle ou telle activité. Ce problème de budget, c'est un peu comme les éléphants de Ken Schwaber (*) : des personnes prennent des décisions qui n'ont pas de sens pour un observateur extérieur -par exemple modifier du code sans avoir pris le temps d'y mettre tous les tests qu'il fallait- parce que de mystérieuses forces les y conduisent. (*) http://kenschwaber.wordpress.com/2010/07/27/the-elephant-in-the-room/ @l'auteur Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif Ces règles ne peuvent fonctionner que si l'ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c'est parfois plus dur à obtenir qu'un budget... @Yannick G.
Ce qu’il y a d’extraordinaire avec le métier du développement logiciel, c’est que le budget est principalement une décision venant des développeurs eux-mêmes, du temps qu’ils décident, en leur ame et conscience, à allouer à telle ou telle activité.
Ce problème de budget, c’est un peu comme les éléphants de Ken Schwaber (*) : des personnes prennent des décisions qui n’ont pas de sens pour un observateur extérieur -par exemple modifier du code sans avoir pris le temps d’y mettre tous les tests qu’il fallait- parce que de mystérieuses forces les y conduisent.

(*) http://kenschwaber.wordpress.com/2010/07/27/the-elephant-in-the-room/

@l’auteur
Ce sont des régles de bon sens mais il ne faut pas sous-estimer le principal frein à leur mise en place : le collectif
Ces règles ne peuvent fonctionner que si l’ensemble des développeurs amenés à toucher au code acceptent de jouer le jeu. Et ça c’est parfois plus dur à obtenir qu’un budget…

]]> Commentaires sur Comparaison de l’approche JSF 2.0 et Play! Framework pour du CRUD par jto http://www.touilleur-express.fr/2010/07/27/comparaison-de-lapproche-jsf-2-0-et-play-framework-pour-du-crud/comment-page-1/#comment-3604 jto Wed, 28 Jul 2010 18:58:35 +0000 http://www.touilleur-express.fr/?p=4062#comment-3604 Bon j'avais copié/collé un bout de code de List.xhtml de l'article, mais il à été supprimé :( Bon j’avais copié/collé un bout de code de List.xhtml de l’article, mais il à été supprimé :(

]]> Commentaires sur Comparaison de l’approche JSF 2.0 et Play! Framework pour du CRUD par jto http://www.touilleur-express.fr/2010/07/27/comparaison-de-lapproche-jsf-2-0-et-play-framework-pour-du-crud/comment-page-1/#comment-3603 jto Wed, 28 Jul 2010 18:56:30 +0000 http://www.touilleur-express.fr/?p=4062#comment-3603 @Thibaud Le problème avec Struts, c'était pas tant l'IHM que les 4 pages de conf xml et les 12 classes Java qu'il fallait coder pour chaque formulaire de l'appli ;) A mon sens, on peut faire bien plus de chose en écrivant le HTML à la main, sans pour autant y passer plus de temps (voir même moins). Par exemple, faire un système d'onglet, avec jQuery, "$('#onglets').tabs()", ça ne me parait pas plus long qu'avec JSF, et le code sera lisible par n'importe qui, sans avoir à faire 3 semaines de formation JSF. "datatables paginées" => La c'est exactement ce que j'appel un composant sur-complexe, faire un liste paginée, même seulement avec des servlets / JSP c'est pas bien compliqué, avec Play! c'est presque trivial. En utilisant les composants par default JSF (ou asp.net, ne soyons pas raciste, j'ai touché aux deux) ça deviens soudainement complexe... Attention, je ne suis pas en train de dire, "JSF caylemal" (même si pour le coup, je suis pas fan) ou "Les frameworks web orienté composant sapu" Je pense que le principale intérêt de cette approche est la possibilité de partager des bibliothèques au sein d'une (grosse) entreprise. L'équipe A développe des composants spécialement pour la société, et les équipe B, C, et D peuvent les utiliser sans trop se poser de questions. Le principale reproche que je ferait à JSF dans les vue, c'est que parfois (voir souvent), comme dans l'exemple de Nicolas, le code deviens tres tres moche sans pour autant en tiré de la valeur ajoutée. ex: [...] qui n'apporte rien du tout par rapport à une "bete" table HTML. @Thibaud
Le problème avec Struts, c’était pas tant l’IHM que les 4 pages de conf xml et les 12 classes Java qu’il fallait coder pour chaque formulaire de l’appli ;)

A mon sens, on peut faire bien plus de chose en écrivant le HTML à la main, sans pour autant y passer plus de temps (voir même moins).
Par exemple, faire un système d’onglet, avec jQuery, « $(‘#onglets’).tabs() », ça ne me parait pas plus long qu’avec JSF, et le code sera lisible par n’importe qui, sans avoir à faire 3 semaines de formation JSF.

« datatables paginées » => La c’est exactement ce que j’appel un composant sur-complexe, faire un liste paginée, même seulement avec des servlets / JSP c’est pas bien compliqué, avec Play! c’est presque trivial.
En utilisant les composants par default JSF (ou asp.net, ne soyons pas raciste, j’ai touché aux deux) ça deviens soudainement complexe…

Attention, je ne suis pas en train de dire, « JSF caylemal » (même si pour le coup, je suis pas fan) ou « Les frameworks web orienté composant sapu »
Je pense que le principale intérêt de cette approche est la possibilité de partager des bibliothèques au sein d’une (grosse) entreprise. L’équipe A développe des composants spécialement pour la société, et les équipe B, C, et D peuvent les utiliser sans trop se poser de questions.

Le principale reproche que je ferait à JSF dans les vue, c’est que parfois (voir souvent), comme dans l’exemple de Nicolas, le code deviens tres tres moche sans pour autant en tiré de la valeur ajoutée.

ex:

[...] qui n’apporte rien du tout par rapport à une « bete » table HTML.

]]> Commentaires sur Jouez les Docteurs Love, apprenez à nettoyer du vieux code par fabszn http://www.touilleur-express.fr/2010/07/28/jouez-les-docteurs-love-apprenez-a-nettoyer-du-vieux-code/comment-page-1/#comment-3602 fabszn Wed, 28 Jul 2010 13:40:18 +0000 http://www.touilleur-express.fr/?p=4099#comment-3602 Hello, Article très intéressant! Dans les choses pas cher qui améliore considérablement la lisibilité du code et qui permet un refactoring dans de meilleurs conditions : Le renommage des variables, méthodes, etc. Avec les outils de refactoring proposés par les IDEs actuels. Le risque est quasi nul et la valeur ajoutée est énorme. Hello,

Article très intéressant!

Dans les choses pas cher qui améliore considérablement la lisibilité du code et qui permet un refactoring dans de meilleurs conditions :
Le renommage des variables, méthodes, etc. Avec les outils de refactoring proposés par les IDEs actuels.

Le risque est quasi nul et la valeur ajoutée est énorme.

]]> Commentaires sur Jouez les Docteurs Love, apprenez à nettoyer du vieux code par Benoît Courtine http://www.touilleur-express.fr/2010/07/28/jouez-les-docteurs-love-apprenez-a-nettoyer-du-vieux-code/comment-page-1/#comment-3601 Benoît Courtine Wed, 28 Jul 2010 12:25:28 +0000 http://www.touilleur-express.fr/?p=4099#comment-3601 Excellent article, comme d'habitude. J'aime beaucoup la comparaison avec la médecine. J'ai déjà mis en place ce genre de pratique dans nos développements. En ce qui concerne l'outillage (Hudson, Sonar, etc.), d'expérience, ça plait beaucoup à la hiérarchie... tant que le coût des licences est nul ! Par contre, pour ce qui est des produits propriétaires (yourKit que tu cites... mais je pense également par exemple à SonarJ pour le contrôle de l'architecture), c'est une autre paire de manches. Excellent article, comme d’habitude. J’aime beaucoup la comparaison avec la médecine.

J’ai déjà mis en place ce genre de pratique dans nos développements. En ce qui concerne l’outillage (Hudson, Sonar, etc.), d’expérience, ça plait beaucoup à la hiérarchie… tant que le coût des licences est nul ! Par contre, pour ce qui est des produits propriétaires (yourKit que tu cites… mais je pense également par exemple à SonarJ pour le contrôle de l’architecture), c’est une autre paire de manches.

]]> Commentaires sur Jouez les Docteurs Love, apprenez à nettoyer du vieux code par fsarradin http://www.touilleur-express.fr/2010/07/28/jouez-les-docteurs-love-apprenez-a-nettoyer-du-vieux-code/comment-page-1/#comment-3600 fsarradin Wed, 28 Jul 2010 11:51:27 +0000 http://www.touilleur-express.fr/?p=4099#comment-3600 @Nicolas @hgomez: C'est en lisant des réflexions comme les vôtres qu'on fini par se dire que le logiciel à plus à faire avec la propriété intellectuelle qu'avec le brevet. @Nicolas @hgomez: C’est en lisant des réflexions comme les vôtres qu’on fini par se dire que le logiciel à plus à faire avec la propriété intellectuelle qu’avec le brevet.

]]> Commentaires sur Comparaison de l’approche JSF 2.0 et Play! Framework pour du CRUD par Thibaud http://www.touilleur-express.fr/2010/07/27/comparaison-de-lapproche-jsf-2-0-et-play-framework-pour-du-crud/comment-page-1/#comment-3599 Thibaud Wed, 28 Jul 2010 11:35:01 +0000 http://www.touilleur-express.fr/?p=4062#comment-3599 « JSF sera en mesure de construire des interfaces plus riches que Play! » Je pense que l'auteur souhaite dire que dans la logique "out of the box", JSF va plus loin que Play! framework pour l'IHM et donc propose plus de choses directement utilisables. @jto Effectivement on peut toujours faire une interface riche en HTML et Javascript(jQuery) en codant à la mimine. Ce qu'on faisait finalement quand on faisait du Struts qui ne propose pas de composants d'IHM tout fait. Je crois que la force de JSF n'est pas dans les bibliothèques de composants "sur-complexe" mais au contraire dans les composants classiques mais néanmoins difficiles à gérer en HTML (surtout si y a une pointe d'Ajax): système d'onglets, popup, captcha, menu contextuels, datatables paginées... Nous utilisons en ce moments pas mal de composants PrimeFaces parce qu'ils sont simples à intégrer et on gagne pas mal de temps. « JSF sera en mesure de construire des interfaces plus riches que Play! »
Je pense que l’auteur souhaite dire que dans la logique « out of the box », JSF va plus loin que Play! framework pour l’IHM et donc propose plus de choses directement utilisables.

@jto
Effectivement on peut toujours faire une interface riche en HTML et Javascript(jQuery) en codant à la mimine. Ce qu’on faisait finalement quand on faisait du Struts qui ne propose pas de composants d’IHM tout fait.

Je crois que la force de JSF n’est pas dans les bibliothèques de composants « sur-complexe » mais au contraire dans les composants classiques mais néanmoins difficiles à gérer en HTML (surtout si y a une pointe d’Ajax): système d’onglets, popup, captcha, menu contextuels, datatables paginées…

Nous utilisons en ce moments pas mal de composants PrimeFaces parce qu’ils sont simples à intégrer et on gagne pas mal de temps.

]]> Commentaires sur Comparaison de l’approche JSF 2.0 et Play! Framework pour du CRUD par Crocky http://www.touilleur-express.fr/2010/07/27/comparaison-de-lapproche-jsf-2-0-et-play-framework-pour-du-crud/comment-page-1/#comment-3598 Crocky Wed, 28 Jul 2010 11:28:08 +0000 http://www.touilleur-express.fr/?p=4062#comment-3598 J'ai adoré PHP. J'ai apprécié le côté pro et cadré de Struts et de J2EE sur les gros projets. J'ai souri en voyant comment les spécialistes de Java ont levé la tête du guidon pour découvrir avec 10 ans de retard les facilités d'utilisation des langages comme PHP ou Python. J'ai assisté à l'essor de Javascript et des librairies <b>jQuery</b> et autres <b>Dojo</b> et <b>YQL</b> qui permettent aujourd'hui de faire des applis autrement, pour un simple navigateur ou directement pour un iPhone, Android ou Blackberry (<b>PhoneGap</b> par exemple). Pour moi Play! s'intègre parfaitement dans ce tableau. Original dans sa démarche et dans sa conception - ce sont des scripts Python qui génèrent le code Java - facile à comprendre (pour s'en convaincre il suffit de parcourir les sources), facile à utiliser, non invasif, léger, modulable, évolutif, bref idéal pour quiconque souhaite être efficace au quotidien (certains bien pensants de Java appellent ça parfois du <i>prototypage</i>, les développeurs PHP et Ruby ne comprennent pas ce terme...). L'article de Nicolas montre bien qu'il y a de la place pour tout le monde. De la place pour les frileux, pour les respecteux des normes, pour ceux qui gèrent des gros projets et/ou des effectifs conséquents, pour ceux qui n'ont pas le choix, ou encore pour ceux qui voient dans le changement uniquement une forme de continuité. Mais aussi de la place pour les équipes qui ont un objectif autre que d'implémenter telle ou telle JSR dans le dernier server JBoss qui met 2 minutes à se lancer ou encore pour ceux qui partagent leur temps entre Javascript et Java parce qu'ils considèrent qu'il y a une vie en dehors du Server. J'ai pris une matinée pour découvrir Play! et une seconde pour m'apercevoir que les tests unitaires, les "Validators", et les appels type WS sont intégrés. Une troisième pour tester rapidement différents modules - dont MongoDB. Et définitivement Play! est tout simplement une autre façon de concevoir et de travailler. @Piwaï: Play! dispose aussi d'un mode de déploiement sous la forme d'un <i>war</i>, une bonne vieille servlet quoi ! ;) J’ai adoré PHP. J’ai apprécié le côté pro et cadré de Struts et de J2EE sur les gros projets. J’ai souri en voyant comment les spécialistes de Java ont levé la tête du guidon pour découvrir avec 10 ans de retard les facilités d’utilisation des langages comme PHP ou Python. J’ai assisté à l’essor de Javascript et des librairies jQuery et autres Dojo et YQL qui permettent aujourd’hui de faire des applis autrement, pour un simple navigateur ou directement pour un iPhone, Android ou Blackberry (PhoneGap par exemple).
Pour moi Play! s’intègre parfaitement dans ce tableau. Original dans sa démarche et dans sa conception – ce sont des scripts Python qui génèrent le code Java – facile à comprendre (pour s’en convaincre il suffit de parcourir les sources), facile à utiliser, non invasif, léger, modulable, évolutif, bref idéal pour quiconque souhaite être efficace au quotidien (certains bien pensants de Java appellent ça parfois du prototypage, les développeurs PHP et Ruby ne comprennent pas ce terme…). L’article de Nicolas montre bien qu’il y a de la place pour tout le monde. De la place pour les frileux, pour les respecteux des normes, pour ceux qui gèrent des gros projets et/ou des effectifs conséquents, pour ceux qui n’ont pas le choix, ou encore pour ceux qui voient dans le changement uniquement une forme de continuité. Mais aussi de la place pour les équipes qui ont un objectif autre que d’implémenter telle ou telle JSR dans le dernier server JBoss qui met 2 minutes à se lancer ou encore pour ceux qui partagent leur temps entre Javascript et Java parce qu’ils considèrent qu’il y a une vie en dehors du Server. J’ai pris une matinée pour découvrir Play! et une seconde pour m’apercevoir que les tests unitaires, les « Validators », et les appels type WS sont intégrés. Une troisième pour tester rapidement différents modules – dont MongoDB. Et définitivement Play! est tout simplement une autre façon de concevoir et de travailler.
@Piwaï: Play! dispose aussi d’un mode de déploiement sous la forme d’un war, une bonne vieille servlet quoi ! ;)

]]> Commentaires sur Générer une application type CRUD en JSF 2.0 avec NetBeans 6.9 par Thibaud http://www.touilleur-express.fr/2010/07/25/generer-une-application-type-crud-en-jsf-2-0-avec-netbeans-6-9/comment-page-1/#comment-3597 Thibaud Wed, 28 Jul 2010 11:20:50 +0000 http://www.touilleur-express.fr/?p=4027#comment-3597 Article intéressant! Étant moi-même en train d'explorer JEE 6 et les JavaServer Faces, je me suis empressés de suivre ce tuto. NetBeans est bluffant pour le coup. A noter que le code généré fonctionne (presque) en utilisant les annotations proposé par CDI (JSR 299) sur GlassFish: - @Named (javax.inject) au lieu de @ManagedBean - @SessionScope du paquetage javax.enterprise.context => Faut simplement ajouter "implements Serializable" à la classe MicroMarketController Article intéressant!

Étant moi-même en train d’explorer JEE 6 et les JavaServer Faces, je me suis empressés de suivre ce tuto. NetBeans est bluffant pour le coup.

A noter que le code généré fonctionne (presque) en utilisant les annotations proposé par CDI (JSR 299) sur GlassFish:
- @Named (javax.inject) au lieu de @ManagedBean
- @SessionScope du paquetage javax.enterprise.context

=> Faut simplement ajouter « implements Serializable » à la classe MicroMarketController

]]>