Des contributeurs ?

• [^]Re: Des contributeurs ?

  Posté par Le Pnume () le 25/07/2007 à 14:35. (lien). Évalué à 8.

  D'ailleurs, il parait que seul les contributeurs prénommé Serge sont accepté.

  --
  "D'accord" (Sam Seaborn)

  • [^]Re: Des contributeurs ?

    Posté par chl (page perso, ) le 25/07/2007 à 15:42. (lien). Évalué à 4.

    Ah ouais ? Moi j'aurais plutôt dit que seules les contributeuses prénommée Jeanne seraient acceptée.

• [+] [^]Re: Des contributeurs ?

  Posté par Nikoo () le 25/07/2007 à 18:45. (lien). Évalué à -4.

  Bon sang ! Très très fine, comme je les aime. Je plussoie !!

  --
  http://nikoolinux.zeblog.com/

Spring

• [^]Re: Spring

  Posté par Robert Bakic (page perso, ) le 25/07/2007 à 16:28. (lien). Évalué à 2.

  Les différences sont nombreuses, mais les points les plus importants :
  
  - Une approche pragmatique et simple de la programmation avec des composants considérés comme des services et non des entités.
  - L'encapsulation de toutes les fonctions du composant (code s'executant sur le serveur, éditeur de paramètre, fichier d'aide , monitoring...) au sein d'une même archive re-livrable, tel un plug-in.
  - Une gestion intégré et évolué du pool de thread et des queues de traitements sur l'acces au composant.
  - La programmation événementielle
  - etc ... (j'en passe).
  
  Certes, je ne connais pas très bien Spring et sans doute est-il possible d'arriver au même résultat, mais certainement pas avec la même facilité : il faut essayer l'exemple du tutoriel pour bien s'en rendre compte.
  
  Pour ne considèrer que l'AOP et l'injection de dépendance, ce qui frappe le plus par rapport à Spring c'est la simplicité du tissage qui se fait par simple glisser-déposer dans l'éditeur graphique a comparer avec le fichier de config XML de l'IoC de Spring...

  • [^]Re: Spring

    Posté par gazbhan () le 25/07/2007 à 17:59. (lien). Évalué à 3.

    Je ne comprend pas trop ce que tu entends par :
    

    des composants considérés comme des services et non des entités

    
    
    Je ne suis pas particulièrement fan de spring, mais je trouve la config xml particulièrement bien foutue : je ne la troquerai certainement pas pour une interface graphique faisant la même chose.
    
    Je crois que j'ai pas compris grand chose aux principes d'Azuki (faut dire j'ai pas tout lu), mais grosso modo quand est il intéressant de l'utiliser ? Le concept de "Context Objects" est intéressant, mais est il réellement utile ? De même pour la partie du framework orientée event : qu'apporte t'elle ?
    
    Merci de bien vouloir éclairer ma modeste lanterne, j'aime beaucoup essayer de nouveaux frameworks mais la j'ai vraiment du mal à en saisir l'intérêt ...

    • [^]Reponses

      Posté par Robert Bakic (page perso, ) le 25/07/2007 à 21:25. (lien). Évalué à 10.

      Je ne comprend pas trop ce que tu entends par : des composants considérés comme des services et non des entités
      
      Les Azuki bean ne sont pas destinés à encapsuler les données de la base de donnée (comme pour JDO, EJB entity et hibernate) mais simplement du code procédurale
      qui peut être considéré comme un service, en ce sens que le code est generalement thread-safe et que les attributs du bean servent uniquement à son parametrage lors de son initialization.
      
      
      Je ne suis pas particulièrement fan de spring, mais je trouve la config xml particulièrement bien foutue : je ne la troquerai certainement pas pour une interface graphique faisant la même chose.
      
      A chacun sa methode. l'interface graphique ne fait que renseigner un fichier de config XML. L'utilsateur d'Azuki à le choix de modifier le fichier de tissage "manuellement" si il le souhaite.
      L'utilisation de l'interface graphique permet de controler l'integrité du fichier de tissage et de fournir une aide à ceux qui ne maitrise pas encore parfaitement la notion de pointcut et d'aspect.
      Ses differentes vues permettent de s'abstraire du fichier de tissage en donnant une vue d'ensemble de la structure de l'application.
      
      
      Je crois que j'ai pas compris grand chose aux principes d'Azuki (faut dire j'ai pas tout lu), mais grosso modo quand est il intéressant de l'utiliser ?
      
      Le framework est surtout destiné à créer des applications contenant un volume de code conséquent (par exemple un PGI) necessitant des adaptations fréquentes
      et l'ajout de code spécifiques chez le client. Le decoupage de l'application sous forme de composant permet de substituer un composant 'standard" de l'application
      par un autre 'specifique" en isolant les developpements specifiques.
      
      Les larges organisations, éditrices de logiciels et autres intégrateurs on des équipes dédiées aux compétences distinctes (SoC) :
      
      * Des spécialistes techniques maitrisant parfaitement la plate-forme de dev.
      * Des developpeurs un peu moins pointus mais connaissant le métier du client.
      *Des équipes projets chargé de déployer l'application.
      
      Ces personnes ne se cotoient pas réellement et, dans une approche "classique" de developpement, travaillent pourtant sur les mêmes fichiers avec le risque de modifier du code qu'ils maitrisent mal.
      
      Dans l'approche Azuki, les spécialistes techniques travaillent sur leur propres beans qui sont pour la plupart de type "Aspect". Les developpeurs produit codent les beans de type "Business Service". Les équipes projets tissent l'application finale qui sera installée chez le client en remplaçant certain "Business Service" par des beans spécifiques ou encore en ajoutant des connecteurs (également conçu sous forme de bean) sur les points d'entrée et de sortie de l'application (cf prochaine réponse).
      
      Le but avoué du framework est de permettre à l'équipe projet (ou intégration) de pouvoir assembler et parametrer l'application, pour un client, sans avoir à se pencher
      sur le code des composants qui doivent, idéalement, être vu comme des boîtes noires.
      
      De même pour la partie du framework orientée event : qu'apporte t'elle ?
      
      La partie orientée evenement du framework sert a plusieurs choses :
      
      - Definir des points d'entrées et de sorties dans l'application.
      Par exemple, on peut imaginer que le composant qui gere la reception des commandes ai été conçu afin d'envoyer le numero de cette commande reçue sous la forme d'un évenement.
      Cet evenement n'est pas traité dans l'application standard mais sert de point de sortie afin de permettre lors de l'installation chez un client d'ajouter une fonction spécifique comme l'envoi
      immédiat d'un courriel au service livraison suite à la reception de cette commande. il suffit donc d'abonner le composant chargé de cette tâche à la reception de l'evenement pour pouvoir chainé
      les deux actions sans avoir à modifié le code du premier composant (pour y ajouter une fonction d'envoie de mail par exemple).
      
      - Traitements parallèles et asynchrones :
      Le framework possède qui pool de thread qu'il utilise pour exécuter les méthodes des composants. Dans l'exemple précédent l'envoie du mail sera traiter par un second thread de façon asynchrone de façon totalement transparente pour les composants. Il n'y a donc pas de surcout en temps de traitement pour le composant gérant la reception de commande.
      
      - Ferme de traitements
      En couplant ces evenements à des connecteurs vers des brokers de messages (tel que ceux livré avec le framework), il est aisé de mettre en place une ferme de traitement en répartissant les traitements sur differents serveurs et cela juste en changeant le tissage de l'application à l'aide du weaver.
      
      - Chaîner des traitements en créant des points de synchronisation.... etc...
      
      Le concept de "Context Objects" est intéressant, mais est il réellement utile ?
      
      Il est utile et nous l'utilisons dans nos propres developpements.
      Par exemple nous gerons la transaction avec la base de données au travers du context d'execution, cela permet par exemple de definir la base de données de travail en
      fonction du programme qui a invoqué la methode de notre composant.
      
      On peut egalement stocker dans le context d'execution des variables ayant un "scope" propre au traitement effectué sans avoir à les passer en paramètre et sans avoir recours
      au variables globales (problème de collision de nom). En outre, le fait de ne pas avoir à passer ces variables en paramètres simplifie la réutilisation des composants.
      
      L'avantage de ces objets est que leur cycle de vie est géré par le framework. On peut même définir si un object sera hérité par une second thread lors d'un "fork" (lancement
      d'un traitement asynchrone).
      
      L'utilisation d'objets contextuels (propre au thread en cours d'execution) permet de rendre le code d'un composant thread-safe, ce qu'il ne pourrait être si on devait modifier
      ses attributs.
      
      
      Merci de bien vouloir éclairer ma modeste lanterne, j'aime beaucoup essayer de nouveaux frameworks mais la j'ai vraiment du mal à en saisir l'intérêt ...
      
      Merci à toi, pour ces questions pertinentes.

      • [^]Re: Reponses

        Posté par gazbhan () le 25/07/2007 à 22:49. (lien). Évalué à 4.

        
        1) Les Azuki bean ne sont pas destinés à encapsuler les ...
        

        
        Si je comprends bien, ce concept de bean permet (à la manière de Spring, désolé si je me répète mais c'est à peu près tout ce que je connait en la matière :) ) de rendre disponible un objet pour d'autres objets ? Apporte t'il quelque chose en plus ? De plus, tu fais référence aux EJB, JDO et hibernate, peut on les intégrer facilement ?
        
        

        
        2) Ses differentes vues permettent de s'abstraire du fichier de tissage en donnant une vue d'ensemble de la structure de l'application.
        

        
        Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup !
        
        3) et 4) : ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
        
        

        
        Dans l'approche Azuki, les spécialistes techniques travaillent sur leur propres beans qui sont pour la plupart de type "Aspect". Les developpeurs produit codent les beans de type "Business Service". Les équipes projets tissent l'application finale qui sera installée chez le client en remplaçant certain "Business Service" par des beans spécifiques
        

        
        
        Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ).
        
        

        
        
        - Chaîner des traitements en créant des points de synchronisation.... etc...
        
        

        
        
        Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;)
        
        5) La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
        
        En tout cas, merci pour tes réponses : tu m'a au moins convaincu d'essayer par moi même. Bon, pas tout de suite vu qu'entre les projets pro et perso j' ai du pain sur la planche mais bon ...
        
        PS: hors sujet, mais quelqu'un connaitrait il un bon framework javascript en remplacement de dojo ?

        • [^]Re: Reponses

          Posté par Robert Bakic (page perso, ) le 26/07/2007 à 10:13. (lien). Évalué à 5.

          Si je comprends bien, ce concept de bean permet (à la manière de Spring, désolé si je me répète mais c'est à peu près tout ce que je connait en la matière :) ) de rendre disponible un objet pour d'autres objets ? Apporte t'il quelque chose en plus ? De plus, tu fais référence aux EJB, JDO et hibernate, peut on les intégrer facilement ? »
          
          Spring n'a inventé ni le bean ni l'AOP, personnellement je me suis initié à l'AOP avec le très bon livre de Renaud Pawlak , Jean-Philippe Retaillé & Lionel Seinturier : Programmation orientée aspect pour Java / J2EE.
          N'ayant jamais utilisé Spring, je peux pas te faire une comparaison exhaustive des différences, car de mon point de vue, il n'apporte rien de nouveau (cependant j'avoue mon ignorance sur le sujet)
          J'espère que parmi nos lecteurs ceux connaissant les deux environnements, pourront donner leur avis sur les avantages et inconvénients de chacun (de façon argumenté, pas de troll SVP) .
          Mon but ici, n'est pas de démontrer la supériorité d'une approche par rapport à une autre, mais de proposer une alternative au développeur afin de l'amener à confronter les approches, à se poser les bonnes questions et enfin à éclairer d'un autre jour ses connaissances en programmation .
          
          Nous avons un composant Hibernate fourni avec le framework permettant de récupérer une session. Nous avons fait des tests concluants de mise a jour de base de donné il y a plus d'un an, mais le bean est un peu en stand-by car nous n'avons pas les ressources suffisantes pour mener tous les projets de front. C'est pour cela que nous recherchons des contributeurs, y compris pour reprendre le projet/bean hibernate.... à bon entendeur....
          
          Enfin, rien n'empêche les concepteurs de bean Azuki d'utiliser Spring au sein de leur composants (même si cela peut paraître bizzare). Ils peuvent ainsi utiliser Spring pour l'IoC ou l'integration avec les autres API et profiter egalement du framework Azuki (par exemple : la gestion avancé des threads et les evenements).
          
          
          « Je vais regarder ca parce que si ca permet de tisser facilement ses aspects ca vaut le coup ! »
          
          Tout a fait d'accord :-) Surtout que dans la réalité, le code AOP ne constitue qu'un minorité du code généré pour une application et l'on ne doit pas forcer l'ensemble des développeurs à maîtriser des concepts qui leur sont inutiles pour développer leur business service.
          
          ok je comprend mieux parce que comme décrit rapidement sur le site ça n'avait pas l'air d'aporter grand chose aux Observers ... Concernant la remarque sur les threads, il est vrai que j'utilise plutôt spring en environnement web donc je n'avais pas vraiment saisi l'intérêt. En fait il est possible de spécifier simplement dans une conf que les méthodes de tel bean seront exécutées dans un thread séparé ?
          
          Tout à fait, cela est paramétrable via le weaver (ou directement dans le fichier de config azuki.xml)
          
          « Si c'est applicable (appliqué), cela présente un intérêt certain. Mais ici aussi , en quoi est-ce plus simple qu'avec spring ? (ok, je pousse un peu la, pour un mec qui a pas encore essayé le framework ! je te promets d'y regarder de plus prêt mais je peux pas résister à l'envie de poser des questions et de "chercher la ptite bête" ). »
          
          C'est plus simple dans le sens que nous souhaitons que l'intégrateur ne s'occupe pas de l'implémentation du code mais seulement de la documentation et des annotations fourni avec les composants pour réaliser son tissage. Notre approche est que le composant doit rester une boite noire.
          
          « Tu pourrais aprofondir ce point ? Avec la possibilité de fermes de traitements, ca me donnerait presque envie de développer un ETL ... ;) »
          Par exemple : Un composant peu initier deux traitements qui s'exécutent en parallèle, suite à la génération d'un événement par exemple. Le framework permet de créer un point de synchronisation, CaD de ne lancer l'exécution d'une troisième méthode que lorsque les deux précédentes sont terminées.
          
          
          La encore , étant plutôt développeur web, ca ne me parle pas trop puisque j'ai l'impression que J2EE et spring me fournissent tout les contextes (avec les scopes appropriés) dont j'ai besoin pour stocker mes objets.
          
          Encore une fois, rien ne t'empêche de continuer à utiliser Spring avec Azuki.
          
          « PS: hors sujet, mais quelqu'un connaîtrait il un bon framework javascript en remplacement de dojo ? »
          Nous utilisons pour nos dev une librairie basé sur GWT de google. Notre lib apporte quelques fonctions supplémentaires comme la gestion des Datasets et des tableaux de données coté client. Elle sera fournie à la rentrée (octobre?) avec la version 1.1 d'Azuki --> pas si hors sujet que cela ! :-)

          • [^]Re: Reponses

            Posté par gazbhan () le 26/07/2007 à 17:15. (lien). Évalué à 1.

            Merci pour toutes ces patientes explications. Je regarde ca de plus près et si ça me plait j'essairai de contribuer (meme si à mon niveau je suis pas sur de bien pouvoir aider ... )

            • [^]Re: Reponses

              Posté par Robert Bakic (page perso, ) le 26/07/2007 à 20:48. (lien). Évalué à 1.

              Merci à toi. Toute contribution est la bienvenue d'autant qu'Il n'est pas necessaire de connaitre toutes les fonctionnalités du framework et de maîtriser l'AOP pour apporter quelquechose à la plate-forme. Il suffit d'avoir l'idée d'un bean utile et de vouloir le partager.
              Cordialement.

        • [^]Re: Reponses

          Posté par Flupke () le 27/07/2007 à 18:20. (lien). Évalué à 1.

          PS: hors sujet, mais quelqu'un connaitrait il un bon framework javascript en remplacement de dojo ?

          
          Y a jQuery qui est vraiment très puissant et beaucoup moins lourd.

  • [^]Re: Spring

    Posté par reno () le 25/07/2007 à 18:10. (lien). Évalué à 2.

    >avec des composants considérés comme des services et non des entités
    ?? Ca ne me parle pas cette phrase.
    
    >Pour ne considèrer que l'AOP
    Donc si je comprends, Azuki est basé sur l'AOP, ça ne cause pas trop de problème d'un point de vue maintenance?
    
    Aussi a propos du site web: je me demande s'il y a une différence entre 'Event Based Programing' et le signal/slot à la Qt?

    • [^]Re: Spring

      Posté par Robert Bakic (page perso, ) le 25/07/2007 à 21:33. (lien). Évalué à 1.

      Je reponds à la question sur services et entité dans ma réponse à gazbhan (cf ci-dessus)
      
      L'AOP ne pose de pb de maintenance dans Azuki car le code n'est pas intrusif, l'AOP est effectué à l'aide de design-pattern très simple a appréhender.
      
      Je connais pas la Qt est donc ne peux te répondre.