Et encore, on est loin du compte ...

• [^]Re: Et encore, on est loin du compte ...

  Posté par Rossel Olivier () le 08/09/2004 à 09:16. (lien). Évalué à 2.

  Je suis pas sur que ce soit Java qui interesse Google.
  Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.

  • [^]Re: Et encore, on est loin du compte ...

    Posté par Stéphane TRAUMAT (page perso, ) le 08/09/2004 à 09:18. (lien). Évalué à 1.

    Pkoi ont ils pas débaucher des mecs de chez microsoft ou des gens qui font du perl ? ;)

    [^]Re: Et encore, on est loin du compte ...

    Posté par Nicolas Delsaux (page perso, ) le 08/09/2004 à 09:25. (lien). Évalué à 2.

    Je suis pas sur que ce soit Java qui interesse Google.
    Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
    Je vais parler pour celui que je connais par mail (Cedric Beust). Lui, il m'a surtout l'air d'être une brute en Java. Peut-être qu'il connaît ces problématiques, mais ce qu'il connaît surtout, c'est le Java. Et j'ai comme l'impression que pour les autres têtes, c'est pareil.

    --
    "Putain, mais quelle fichue imagination je peux avoir ! ..."
    John Brunner - Tous à Zanzibar

    [^]Re: Et encore, on est loin du compte ...

    Posté par Stéphane TRAUMAT (page perso, ) le 08/09/2004 à 09:28. (lien). Évalué à 4.

    http://www.google.com/jobs/eng/sw.html(...)
    
    A mon avis, C'est pas Java par hasard :)

  [^]Re: Et encore, on est loin du compte ...

  Posté par Romain Guy (page perso, ) le 08/09/2004 à 09:41. (lien). Évalué à 2.

  [quote]Kwé ? D'un autre côté, Sun demande la suppression de tous les API Sun (J2SE, J2EE et J2ME) du site jdocs. Dommage ![/quote]
  
  On trouve ça tous dommage mais ce que faisait JDocs.com avec la doc de J2SE allait à l'encontre de la licence que tu acceptes lors du téléchargement de cette doc. Rick Ross et Matt Schmidt modifiait ainsi le contenu de la documentation sans permission. Heureusement il y a aujourd'hui une parade : la doc est affichée dans une frame en haut et les notes en bas. C'est moins pratique que pour les autres APIs mais c'est mieux que rien. Et ils continuent à faire pression sur Sun :)

  --
  Romain GUY
  http://jroller.com/page/gfx
  http://www.progx.org

  [^]Hasta la revolucion..

  Posté par Gabriel () le 08/09/2004 à 14:42. (lien). Évalué à 3.

  des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
  
  Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).
  
  
  J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.
  
  ça amène d'un part à des solutions plus simples à construire et à appréhender. Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
  
  Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
  Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
  
  Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
  
  Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
  
  Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
  
  Donc, oui, je pensais aussi à l' IoC :-)
  
  Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.

  --
  Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

  • [^]Re: Hasta la revolucion..

    Posté par Le Rat Puant (page perso, ) le 08/09/2004 à 17:29. (lien). Évalué à 1.

    Juste par curiosité : ça veut dire quoi "Inversion of Control" ?

    --
    Grouik!Grouik!

    • [^]Re: Hasta la revolucion..

      Posté par Gabriel () le 08/09/2004 à 17:54. (lien). Évalué à 9.

      Suppose que tu as un objet qui veut sauvegarder des données en base de données.
      Naturellement tu fera
      
      ObjetQuiPermetAccesBaseDeDonnees o= new ObjetQuiPermetAccesBaseDeDonnees()
      
      o.save (mesDonnees)
      
      C'est ton objet qui appelle ObjetQuiPermetAccesBaseDeDonnees
      
      Bref, tu as codé en dur le nom de l'objet qui te permet de faire de la persistence.
      
      Tu pourrais mettre une interface (mais bien sûr tu mets déjà une interface), mais quand même quand tu vas instancier ton objet, il faudra bien dire quelle est la classe utilisée.
      
      InterfacePersistance o= new ObjetQuiPermetAccesBaseDeDonnees()
      
      Le principe de l'inversion de contrôle (aussi appelé drôlement "syndrôme d'Holywood") est:" Don't call me I call you"
      Objet, ne demande pas une instance de ObjetQuiPermetAccesBaseDeDonnees. C'est un moyen extérieur qui va te passer la référence à cet objet- en l'occurence un framework.
      Ce framework va lire un fichier xml de config où il y aura écrit : "Voici l'objet que je vais utiliser pour sauvegarder mes données : c'est ObjetQuiPermetAccesBaseDeDonnees"
      
      Autrement dit, tu as défini ce qui relie chacune entre elles chacune des couche qui font ton appli.
      Avantage : c'est défini en un seul endroit. Tu veux changer ton appel à une base de données par une gestion via un file système : tu changes la config. Ou tu veux tester ton objet - et pas l'accès à la base de données : au lieu d'utiliser l'objet qui fait l'accès à la base (et qui ets peut-être buggé) tu crées un faux objet (Mock) qui va mimer le comportement attendu - mais que tu veux pas tester.
      
      Avantage aussi : un seul lieu pour centraliser le cycle de vie des objets. En général, un accès en base c'est un singleton. Là, c'est ton framework qui va être responsable de la vie de l'objet , donc de son unicité.
      de même tu peux du coup très facilement, par config, quand tu crées un objet, dire d'executer telle méthode (log, sécurité) et ainsi tu implémentes en un seul endroit un comportement général (aop)
      
      http://martinfowler.com/articles/injection.html(...)
      http://www.dotnetguru.org/articles/dossiers/ioc/ioc.htm(...)

      --
      Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying

      • [^]Re: Hasta la revolucion..

        Posté par Stéphane TRAUMAT (page perso, ) le 09/09/2004 à 10:29. (lien). Évalué à 1.

        Oui l'inversion de contrôle a l'air d'etre une petite révolution, ca réduit plus le couplage que de faire des interfaces et uen factory

        [^]Re: Hasta la revolucion..

        Posté par Nicolas Delsaux (page perso, ) le 09/09/2004 à 11:09. (lien). Évalué à 1.

        Inconvénient : bien souvent, l'IoC, ou injection de dépendances, utilise un fichier XML, ce en quoi je ne suis pas d'accord du tout. Mais là, on rentre dans les arcanes de l'élégance Java ...

        --
        "Putain, mais quelle fichue imagination je peux avoir ! ..."
        John Brunner - Tous à Zanzibar

        [^]Re: Hasta la revolucion..

        Posté par Laurent Sansonetti (page perso, ) le 09/09/2004 à 13:30. (lien). Évalué à 4.

        Pour les fanas de Ruby, copland est inévitable.
        
        http://copland.rubyforge.org/(...)

    [^]Re: Hasta la revolucion..

    Posté par Nicolas Delsaux (page perso, ) le 09/09/2004 à 11:20. (lien). Évalué à 2.

    J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.
    
    Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
    
    ça amène d'un part à des solutions plus simples à construire et à appréhender.
    
    Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
    
    Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
    
    Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
    
    Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
    Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
    
    Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
    
    Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
    
    Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
    
    Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
    
    Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
    
    Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
    
    Pas pour les DBAs ;-)
    Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
    
    Donc, oui, je pensais aussi à l' IoC :-)
    
    Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
    
    En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...

    --
    "Putain, mais quelle fichue imagination je peux avoir ! ..."
    John Brunner - Tous à Zanzibar

    • [^]Re: Hasta la revolucion..

      Posté par Stéphane TRAUMAT (page perso, ) le 09/09/2004 à 11:50. (lien). Évalué à 1.

      Perso, j'aime bien les ejb de sessions avec XDoclet, je trouve que c un bon endroit pour centraliser/tester la logique métier et la rendre accesible aux applis web, lourde, webservices....
      
      et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)

      • [^]Re: Hasta la revolucion..

        Posté par Nicolas Delsaux (page perso, ) le 09/09/2004 à 14:04. (lien). Évalué à 1.

        Perso, j'aime bien les ejb de sessions avec XDoclet, je trouve que c un bon endroit pour centraliser/tester la logique métier et la rendre accesible aux applis web, lourde, webservices....
        
        Excuse-moi de te dire ça froidement comme ça, mais ... tu rigoles, là ?
        
        Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise. En disant ça, est-ce que je passe pour un demi-extra-terrestre, ou est-ce que je peux éventuellement être dans le vrai ?
        
        
        et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)
        
        Tiens, c'est marrant, moi aussi. Et générallement, ces DBAs te disent que la charge de leur base est hyper-importante, avant même que quiconque ait fait le moindre test de charge de l'application sur la base, bref, ils te demandent à toi d'optimiser, parce que eux, ça les fatigue ;-)

        --
        "Putain, mais quelle fichue imagination je peux avoir ! ..."
        John Brunner - Tous à Zanzibar

        • [^]Re: Hasta la revolucion..

          Posté par Stéphane TRAUMAT (page perso, ) le 09/09/2004 à 14:15. (lien). Évalué à 1.

          Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise.
          
          C'est pareil que moi.. n'empeche que la logique métier est partagée au monde via les ejbs. c'est poru cela que j'utilise les ejbs :)
          
          Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances

          • [^]De la psychologie du DBA was Re: Hasta la revolucion..

            Posté par Nicolas Delsaux (page perso, ) le 09/09/2004 à 15:01. (lien). Évalué à 1.

            Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances
            
            Il faut les comprendre : leur dire ça revient à leur dénier leur rôle de chef d'orchestre du système d'information, pour en faire de simples administrateurs d'archives. D'un coup, c'est moins classieux. D'un autre côté, c'est exactement leur boulot : une donnée dans une base est à peu près aussi utile qu'un classeur au fond des archives.

            --
            "Putain, mais quelle fichue imagination je peux avoir ! ..."
            John Brunner - Tous à Zanzibar

            • [^]Re: De la psychologie du DBA was Re: Hasta la revolucion..

              Posté par Stéphane TRAUMAT (page perso, ) le 09/09/2004 à 15:12. (lien). Évalué à 1.

              Heurseument qu'ils ne sont pas en train de lire ce qu'on écrit