Forum Programmation.autre Histoire des patterns

Posté par  . Licence CC By‑SA.
Étiquettes :
-3
5
jan.
2013

Bonjour à tous,

débat pseudo-philosophique de programmeurs alcoolisé n'ayant pas trouvé de réponse, c'est donc sombre que je m'adresse à ma communauté favorite.
Aujourd'hui, "sur" le SOA on voit de plus en plus d'article élogieux sur le BPM.
Le SOA est apparu en remplacement/complément du model 3-tier(MVC/2)
Mais avant, ce n'était pas le big bang. J'essaye donc de m'y rapprocher…

Dans l'autre sens (au cas où ce n'était pas très clair): Le big bang, ensuite nous avons les application que nous pouvons appeler "monobloc", ensuite les développeur ont eu l'idée de séparer les données, puis de les centralisé sur des serveurs distants. Ensuite les développeurs ont été surtout focalisé sur les logiciels "distants", ou en plus des datas c'est toute la business logic qui était centralisé et seul l'affichage était géré par le poste client….ensuite je ne sais pas (la question est là)….puis MVC, SOA, BPM, le futur, la fin du monde.

Merci d'avance à tout ceux qui feront avancer cette tentative de rétrospective!!

Cdt

  • # En gros ...

    Posté par  . Évalué à 3.

    tous ces trucs ne servent qu'à faire consommer du CPU, de la bande passante et de la RAM pour que les fabricants de matos puissent continuer à vendre, et à générer de la complexité pour que les éditeurs de logiciels puissent vendre du support, et que les ingés en info puissent garder leur job.

    • [^] # Re: En gros ...

      Posté par  . Évalué à 2.

      Retour sur MsDos ecrire sur un Vi-like ta théorie du complot et arrête de te plaindre…

      Sans ces évolutions il serait véritablement impossible de créer les logiciels actuels. Il faudrait réinventer la roue à chaque fois. Alors oui s'appuyer sur des models et des frameworks déjà existant peut-être légèrement moins performant que de créer ses propres librairies mais c'est un mal nécessaire.

      Que celui qui n'as jamais copié-collé me jette le premier CTRL+ALT+SUPPR  !

      • [^] # Re: En gros ...

        Posté par  . Évalué à 1.

        Ou as-tu vu que je me plains ? Je ne fait que décrire des faits dont moi aussi je tire profit.

        • [^] # Re: En gros ...

          Posté par  . Évalué à 2.

          Ah, et au passage, je préfère largement coder sur des trucs bas niveau style microcontroleurs que sur des usines à gaz telles que les frameworks Java … Je ne m'arrêterai pas non plus sur les personnes (en général des personnes qui n'ont qu'une vision partielle de ce qu'est coder) qui imposent tel ou tel framework en tel ou tel langage parce que c'est le sel qu'ils connaissent, alors que la situation ne s'y prête pas forcément.

    • [^] # Re: En gros ...

      Posté par  . Évalué à 2.

      Donc selon toi, pour chaque nouvelle application, il faut recoder un OS et il faut tout coder en assembleur. Et encore il faut supprimer les appels de sous-routine, parce que les sous routine "ne servent qu'à générer de la complexité pour que les éditeurs de logiciels puissent vendre du support, et que les ingés en info puissent garder leur job".

      Non mais sans déconner, un peu de réutilisation et d'accélérateur de développement ça n'a jamais fait de mal. Faut juste pas tomber dans l'excès.

      • [^] # Re: En gros ...

        Posté par  . Évalué à 2.

        Faut juste pas tomber dans l'excès

        Tout est dit : et l'excès je le vois tout les jours.

  • # client léger

    Posté par  (site web personnel) . Évalué à 2.

    ce que tu appelles monobloc, c'est plutôt le client lourd ?
    pour logiciels distants, j'imagine que c'est les client légers ?

    au milieu il y a les applets (genre applets java ou pire, activeX).

    Désormais, c'est plutôt le web 2.0 avec du javascript ultra-lourd permettant d'exécuter on ne sait pas quoi directement dans le navigateur… avec du JSON pour conserver une connexion à chaque changement de champ.

    Le SOA est apparu en remplacement/complément du model 3-tier(MVC/2)

    moui, je ne suis pas trop d'accord, mais bon, ça peut être une utilisation on va dire… Tu peux regarder TOGAF et autres pour approfondir :-)

    • [^] # Re: client léger

      Posté par  . Évalué à 1.

      Bonjour et merci de ta réponse,

      parler de client lourd c'est déjà penser réseau. Les premiers logiciel n'étant pas connecté ils étaient pour la plupart développé dans du basic, cobol ou C sans accès réseau ni de séparation dans la conception. Un fichier "sauvé" n'était pas lisible sur une autre instance de ce même logiciel.

      En fait ma question parle des model de conception dans leur généralité, pas des technologies. Cependant TOGAF est une communauté dont j'ignorais l’existence et qui reste très intéressante mais hors-sujet. Merci pour ce lien.

      • [^] # Re: client léger

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 09 janvier 2013 à 21:56.

        oulalala…

        Les premiers logiciel n'étant pas connecté

        si si, à la main, avec des câbles pour chaque instruction comme dans l'ENIAC :) (je n'ai pas connu, je te rassure :p).

        Si tu veux plus récent, vu le coût de production des premiers ordinateurs, par nature le terminal était déporté (et donc connecté à l'ordinateur) et il y avait plusieurs terminaux, ce n'était pas (encore) du TCP/IP, ça je te l'accorde. Cela est resté vrai avec les mini-ordinateurs. L'apparition des micro-ordinateurs a obligé les connexions en mode asynchrone initialement obligeant à du partage de données par des moyens comme la cartouche, la cassette (une cassette audio fonctionnait, dénommée affectueusement K7) puis la disquette… le RS-232 (ou port série) permettait éventuellement de brancher des terminaux…

        ma question parle des model de conception dans leur généralité, pas des technologies.

        euh, ce n'est depuis peu que TOGAF présage de l'implémentation :-) (avec le rajout de la prise en compte de l'architecture technique en v9, dont il y avait des prémisses en v8).. Bien au contraire, TOGAF estse veut un peu l'ITIL pour le développement, en gros un recueil de bonnes pratiques et de patterns d'architecture (métier, fonctionnelle, peu logicielle ou pas encore on va dire, technique). Donc bon, nous n'avons peut-être pas la même définition du terme conception :-) 'fin bon, on va dire qu'effectivement TOGAF ne traite pas que de la SOA mais l'englobe (ou alors SOA ne correspond pas à architecture orientée service pour toi ?).

        Il me semble que tu as non seulement quelques lacunes en histoire de l'information voire en abstraction du métier :-) (c'est une boutade hein), je t'invite à pousser plus loin la réflexion si tu le souhaite (bon c'est un peu abscons(*) au démarrage, je te le concéderai assez facilement).

        (*) Tu peux relire http://linuxfr.org/users/baud123/journaux/la-demarche-projet-en-informatique par exemple, qui m'a àmha valu pas mal d'incompréhension, en tout cas, plus que de compréhension :-) (la question était pourtant simple :/).

  • # pipotron ?

    Posté par  . Évalué à 2.

    Celui qui peut code, celui qui ne peut pas créer des acronymes.

    "Talk is cheap. Show me the code."
    Torvalds, Linus (2000-08-25). Message to linux-kernel mailing list. Retrieved on 2006-08-28.

    • [^] # Re: pipotron ?

      Posté par  . Évalué à 1.

      Celui qui ne peux pas parler d'un concept ne maîtrise pas ce concept.

  • # abondon

    Posté par  . Évalué à 2.

    Laissez donc tomber cette question, comme a chaque fois entre les commentaires inutiles des mecs qui viennent donner leur avis sur java/microcontroleur, celui qui est tout content de placer une citation, réussir à garder un fil sérieux est impossible.

    Merci à celui qui a essayé de répondre, mais ma question était de toute façon en grande partie mal formulée car clairement mal comprise.

    Les forums de Linuxfr sont devenu pire que Yahoo Q/R! Heureusement qu'il y a encore des articles de qualité…

    • [^] # Re: abondon

      Posté par  (site web personnel) . Évalué à 3.

      mais ma question était de toute façon en grande partie mal formulée car clairement mal comprise.

      bin tu peux réessayer de la reformuler, plus ça rate, plus ça a des chances de tomber en marche :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.