Windows 10 : Microsoft fait une mise à jour des couleurs dans la console de Windows

Citation:

---

Envoyé par redcurve

WCF n'est pas extrêmement compliqué simplement il faut lire la doc avant de se lancer dans du paramétrage hasardeux bref se former quoi. REST permet d'aller plus vite car il n'y a pas besoin de réfléchir.

En outre REST et SOAP ne sont pas forcément interchangeable suivant les contraintes du projet ou le métier du client.

---

Oui bien sur, reaction classique du gars qui s'accroche comme il peut a ce qu'il connait (je comprends, comme moi vous avez passé un temps fou a vous former et vous pensiez faire une carriere la dessus mais vous allez devoir apprendre qu'en informatique, rien n'est acquis, ne jamais se reposer sur ses lauriers et se croire le roi du monde parce qu'on sait configurer un fichier config d'endpoints WCF).
Va raconter a d'autres tes lecons de "il faut lire la doc ... bref se former". Je parle par experience pas pour dire des choses gratuitement. Quand j'ai commencé WCF il y a 7 ans il fallait voir les tonnes de pb de bases rencontrés par tout le monde. Par la suite j'ai largement developpé dans ce contexte (REST/JSON n'ayant pas le vent en poupe a cette epoque mais deja je trouvais XML/SOAP d'une lourdeur sans nom) et dans des contextes securitaire poussé a y laisser des cheveux.

Reaction classique du dev WCF qui va cracher sur les developpeurs REST, 'pas besoin de reflechir'... tout est dit. Entre une usine a gaz pour rien et quelque chose de coherent et logique, simple et plutot bien foutu il n'y a pas photo.
C'est le propre de l'informaticien d'avoir un avis critique sur ce qu'il fait, comme je l'ai dit je ne suis fanboy de personne. 30 ans que je fais du Microsoft. Il y a eu du bon, tres bon et du mauvais. Le non fanboy sait faire la part de choses et reconnaitre ce qui n'est pas bien.
J'ai beaucoup d'attente sur ASPnet Core car le cahier des charges est idéal: plus qu'a esperer que MS ne s'egare pas.

Citation:

---

Envoyé par redcurve

Perso j'ai eu a réapprendre de 0 ... tu dois confondre avec la sous implémentation spécifique silverlight et comme tu n'as pas pris la peine de lire complètement la doc de la v1 bah tu n'étais pas ou courant qu'une fois html5/ecma script 6 ok SL allait sauter mdr. Je trouve ça assez comique tu ne peux t'en prendre qu'à toi même.

---

non non je parle bien de WPF (j'ai fait du WPF avant SL qui s'est revelée etre notre cible au final).
Je me rappelle bien m'etre tapé les +1200 pages de Pro WPF Apress. Un pavé comme celui la secoue (et a l'époque je n'avais pas encore evalué précisement le cycle d'apprentissage colossal (et donc couteux)). Sur nos projets on s'en est vite rendu compte en explosant les budgets (une 15 aine de developpeurs).

et pour revenir sur le sujet initial, rien a dire car news pas fondamentale.

Ca fait longtemps que quel que soit l'environnement, si l'outil n'existe pas on trouve une parade
(ex : Cygwin il y a quelques années pour faire du vrai shell - pas eu a attendre powershell ni supporter les limites du cmd.exe).

Citation:

---

Envoyé par GilbertLatranche

J'ai la fâcheuse impression de m'être fait troll à mon tour.

Si c'est vrai, c'est fort, très fort.

---

J'avoue mais le partage des connaissances est plus important. Nous n'avons pas tous la meme experience, l'informatique est un monde si vaste et j'avoue trouver ca insupportable cette condescendance frequente dans les echanges entre les developpeurs (generalement ce sont des insultes, 'idiot', etc.).

Citation:

---

Envoyé par Aeson

C'est fou cette haine envers Microsoft...

---

En fait, c'est moins envers microsoft ou apple que je susi énervé qu'envers les institution qui les laisse faire n'importe quoi.

Citation:

---

Pas une reecriture, un portage

---

Donc t'arrive a porter une application WPF en HTML sans la ré-écrire toi ? :ptdr:

De meme pour le portage SOAP => REST. Je l'ai deja fais et si tu veus faire dur vrai REST level 3 il faut meme modifier la DAL. Faire passer du JSON ne fait pas de tes api des api REST. Desolé de te l'apprendre.

Citation:

---

Comment on le justifie ? par les couts de maintenance/devpt pour les nouveaux developpeurs.

---

Donc aucun avantage Business. Que des problemes pour le business a cause des probleme de maturité. Tu n'as jamais du faire de budget car le budget explosera et les cout de maintenance seront de toute facon plus haut car l'app sera jeune. Encore une fois ce que tu dis montre bien que tu n'as aucune experience dans le sujet. Personne n'aprouvera ce type de budget.

Si tes besoins business ne changent pas il n'y a AUCUNE raison de decomissioner ou de ré-écrire les app WPF/WCF

Citation:

---

Plus facile a un dev (meme moyen) de coder des API Rest directement que de se former a WCF

---

Pour les nouveau projet ok pour du WebApi.

Citation:

---

Meme l'equipe WebAPI chez microsoft a preferée choisir ASPNetMVC au lieu de WCF

---

Tu compare MVC a WCF ? Vraiment ?

Citation:

---

Reaction classique du dev WCF qui va cracher sur les developpeurs REST,

---

Non reaction d'un personne qui sais qu'il faut justifier les budgets et faire les choses comme il faut. Faire les choses n'importe comment avec un petit budget est finalement beaucoup plus cher.

Citation:

---

En fait, c'est moins envers microsoft ou apple que je susi énervé qu'envers les institution qui les laisse faire n'importe quoi.

---

oui le libre marche ca ennuie certain. Sinon il y a la Russie, le Venezuela ou Cuba. La tu sera beaucoup mieux...

Citation:

---

Envoyé par Aeson

Donc t'arrive a porter une application WPF en HTML sans la ré-écrire toi ? :ptdr:

De meme pour le portage SOAP => REST. Je l'ai deja fais et si tu veus faire dur vrai REST level 3 il faut meme modifier la DAL. Faire passer du JSON ne fait pas de tes api des api REST. Desolé de te l'apprendre.



Donc aucun avantage Business. Que des problemes pour le business a cause des probleme de maturité. Tu n'as jamais du faire de budget car le budget explosera et les cout de maintenance seront de toute facon plus haut car l'app sera jeune. Encore une fois ce que tu dis montre bien que tu n'as aucune experience dans le sujet. Personne n'aprouvera ce type de budget.

Si tes besoins business ne changent pas il n'y a AUCUNE raison de decomissioner ou de ré-écrire les app WPF/WCF



Pour les nouveau projet ok pour du WebApi.



Tu compare MVC a WCF ? Vraiment ?



Non reaction d'un personne qui sais qu'il faut justifier les budgets et faire les choses comme il faut. Faire les choses n'importe comment avec un petit budget est finalement beaucoup plus cher.

---

1. Lis ce que j'ecris n'interprete pas, et non désolé mais jusqu'a maintenant tu ne m'apprends rien.
J'ai parlé de la partie LOGIQUE METIER (la seule partie reutilisable dans un tel portage puisque IHM => poubelle); maintenant ton logiciel est concu selon le modele MVVM donc je comprends ton soucis d'avoir un logiciel sac de nouilles lol

2. "Tu n'as jamais du faire de budget car le budget explosera et les cout de maintenance seront de toute facon plus haut car l'app sera jeune"
Je suis Architecte systeme et chef de projet sur des projets moyens depuis pas mal d'années donc c'est pas a moi que tu vas apprendre a faire un budget et encore moins a ne pas le maitriser. J'applique la methode KISS au quotidien sur toutes les conceptions et ca permet justement de detecter rapidement les gens qui font des trucs qui ne servent a rien. Les gens qui me pondent des archis tordues pour bluffer on les detecte rapidement et ceux la sont voués a l'echec question maintenabilité.
Mon experience se base sur une paire d'experts WPF "des gourous" comme on disait a l'epoque. Refactoring, intégration de la moindre nouvelle lib MS en v0.x, EF et autres pour "essayer" et au final des logiciels complexes pour rien -donc maintenabilité tres couteuse.
avec WPF il est TRES FACILE de faire des logiciels tres complexes (binding + dependancies properties et on n'y comprend plus rien - meme au debogage).
Le fait que je developpe egalement certaines parties me permet de ne pas me faire enfler par le moindre developpeur qui chercherait a se faire plaisir dans son coin.

Ce que tu n'as pas compris c'est qu'on ne chiffre pas EN PLUS, on chiffre le fonctionnel demandé on challenge l'equipe pour faire le boulot dans le cadre des delais/budgets. Une appli maitrisée fonctionnellement se porte assez facilement (on a developpé un framework IHM REST HATEOAS complet - en etude sur fond propres). Il nous permet de coder des APIs tres tres simplement (inclus DAL qui est la partie la plus simple) jusqu'a la logique IHM. Pour les applis classiques types gestion c'est presque du RAD (meme le typescript, WS, jsquery est en generation automatique).

3. Bien sur que ca se justifie car dans ma boite tout le monde fuit ces technos donc quand tu ne trouves plus de developpeurs pour faire la maintenance, tu ne te lances pas dans de nouveaux devps.
Je sais que le dev WPF a tendance a se perdre dans son code (je ne sais que trop le plaisir d'un dev a complexifier son code et surtout en WPF ou chaque commande/structure devient illisible au dela du 20eme caractere).
En 2017 les methodes de productivité sont toujours les memes, developpement moteur de rendu (ce qu'on a developpé en HTML5/BOOSTRAP/TypeScript + WebAPI HATEOAS) ou generation de code.

4. "Tu compare MVC a WCF ? Vraiment ?"
=> pas ce que j'ai dis encore une fois, ou l'art d'interpreter a sa maniere - change de logiciel il est buggé.
Relis la phrase; je dis que meme Microsoft n'a pas utlisé WCF pour les services hosted sous IIS mais s'appuie sur ASPNET MVC. Desolé mais je ne suis pas la pour faire ton education, va faire un tour un peu sur les sites techniques MS.

Citation:

---

J'applique la methode KISS

---

Mais tu preconise de 'migrer' des applications WPF/WCF en disant que le cout de maintenance sera moin haut ? Vraiment ?

Vu ce que tu dis, a mon avis t'es qu'un developeur medior ou senior. Rien de plus.

Citation:

---

Envoyé par Aeson

Mais tu preconise de 'migrer' des applications WPF/WCF en disant que le cout de maintenance sera moin haut ? Vraiment ?

Vu ce que tu dis, a mon avis t'es qu'un developeur medior ou senior. Rien de plus.

---

Tu le fais expres, serieux ?

je te dis que comme on maitrise :
a/ Le fonctionnel de l'appli de depart (WPF/WCF) - appli stable qui fonctionnellement evolue tres peu
b/ Framework maison (avec toutes la batterie de tests unitaires si tu veux que je sois plus precis) permettant de realiser un equivalent FONCTIONNEL rapidement,
les couts de finalisation de ce "portage" (appelle le comme tu veux) sont mineures et surtout au niveau evolutivité/maintenance on se retrouve sur une plateforme qu'on maitrise totalement; et ca se retrouve au final sur les REX projets. C'est du vecu.
Alors les quelques 10aines d'heures passées a faire cette "migration" est sans conteste valorisée tres rapidement.
On a passé 3 ans a maintenir une usine a gaz ecrite en WPF (avec MEF etc.) et un flot incessant de developpeur WPF (experts MS pour certains) qui y ont laissé des plumes. Donc la maintenabilité n'est pas bonne sur WPF. C'est notre REX et il s'est verifié sur d'autres applis qu'on maintient peniblement encore maintenant (mais plus pour longtemps).

Maintenant on repond aux demandes de nos clients mais ces derniers veulent des logiciels homogenes (ex : nos applis sont accessibles via un portail unifié s'appuyant sur le framework maison).
Comme 90% de nos applis sont en HTML/BOOTSTRAP/webapis, edge ne supportant pas nos applis restantes WPF... le choix est contraint et forcé.

Je n'ai rien a te prouver tu crois ce que tu veux; je pourrai te dire que tu me sembles un developpeur WPF lambda (un dinosaure comme on en a quelques uns encore chez nous) qui s'accroche. Plus dur sera la chute le jour ou tu t'en rendras compte.
Les technos passent, encore plus vite maintenant tu ne peux envisager faire une carriere sur une seule techno; tu pourras toujours continuer mais le monde du travail ne t'attendra pas. Juste un conseil.

Petit lien retrouvé qui resumé justement WCF notamment :
https://blog.tonysneed.com/2016/01/0...ng-live-mvc-6/

Citation:

---

e pourrai te dire que tu me sembles un developpeur WPF lambda

---

Justement non. Cela doit bien faire 4 ans que je n'ai plus fait de WPF. Je m'occupe justement des techno WEB/MicroServices. Donc WebApi/Rest, RabbitMQ, ASP.Net Core et le passage vers Docker.

Je ne dis certainement pas que WCF est l'avenir. Juste qu'il n'y a encore AUCUNE raison de tuer une application WCF/WPF si les besoins business ne change pas. L'application fonctionne et le cout n'est absolument pas justifiable sans changement business.

De plus porter des services SOAP en REST comme tu dis n'est simplement pas possible si tu veus le faire comme il faut.

Citation:

---

Juste un conseil

---

Un conseil en retour : Assure tes arrieres car quand la personne qui signe les budgets comprendra qu'elle a depense de l'argent pour rien il faudra te justifier. Tu ne sera pas le premier....

Citation:

---

edge ne supportant pas nos applis restantes WPF

---

J'ai peur de comprendre. Tu parle du Browser ? WPF ne tourne pas dans un browser... et Silverlight c'est pas WPF...

Citation:

---

nos applis sont accessibles via un portail unifié

---

Donc tes applis tournent dans un Browser. C'est un requierment Et comme les portal WPF ca n'existe pas.

A moin qur t'utilise de l'App Streaming via des ferme RDS. Dans ce cas la d'accord. Le cout des fermes RDS est enorme et le passage a HTML est justifiable.

Citation:

---

Envoyé par Aeson

Un conseil en retour : Assure tes arrieres car quand la personne qui signe les budgets comprendra qu'elle a depense de l'argent pour rien il faudra te justifier. Tu ne sera pas le premier....

J'ai peur de comprendre. Tu parle du Browser ? WPF ne tourne pas dans un browser... et Silverlight c'est pas WPF...

Donc tes applis tournent dans un Browser. C'est un requierment Et comme les portal WPF ca n'existe pas.

---

1. T'inquiete je chiffre bien moins que ceux qui chiffrent les evolutions de nos applis WPF et au final les applis sont livrées et fonctionnent;
Nos chiffrages sont passés a la loupe (vu les delais qui se raccourcissent et les budgets).
challenger les equipes et la meilleure methode pour changer les technos sans surcout. Tout le monde est gagnant.

2. Oui on a 2 grosses applis qui fonctionnent dans le navigateur - contrainte tres forte de nos clients qui ne voulaient pas de client lourd
(d'ou mon allusion au client semi leger/semi lourd de tout a l'heure).
Seulement nos applis accedent a de nombreux peripheriques (et systeme de fichier entre autre) donc necessitent d'etre en mode FULL TRUST donc avec deploiement de certificats (et là on met le pied dans quelque chose d'inextricable et on se rend compte de l'usine a gaz que cela est).
Ceci impose des deploiements de certificats sur tous les postes clients ce qui est considerable et lourdingue (les applis sont des machines de ventes en guichet).

Au final une appli client leger/webapi (avec notre framework intégrant SSO etc.) est beaucoup plus "simple" a deployer que ces applis WPF puisqu'il n'y a rien a deployer.

Citation:

---

Envoyé par kilroyFR

Oui bien sur, reaction classique du gars qui s'accroche comme il peut a ce qu'il connait (je comprends, comme moi vous avez passé un temps fou a vous former et vous pensiez faire une carriere la dessus mais vous allez devoir apprendre qu'en informatique, rien n'est acquis, ne jamais se reposer sur ses lauriers et se croire le roi du monde parce qu'on sait configurer un fichier config d'endpoints WCF).
Va raconter a d'autres tes lecons de "il faut lire la doc ... bref se former". Je parle par experience pas pour dire des choses gratuitement. Quand j'ai commencé WCF il y a 7 ans il fallait voir les tonnes de pb de bases rencontrés par tout le monde. Par la suite j'ai largement developpé dans ce contexte (REST/JSON n'ayant pas le vent en poupe a cette epoque mais deja je trouvais XML/SOAP d'une lourdeur sans nom) et dans des contextes securitaire poussé a y laisser des cheveux.

Reaction classique du dev WCF qui va cracher sur les developpeurs REST, 'pas besoin de reflechir'... tout est dit. Entre une usine a gaz pour rien et quelque chose de coherent et logique, simple et plutot bien foutu il n'y a pas photo.
C'est le propre de l'informaticien d'avoir un avis critique sur ce qu'il fait, comme je l'ai dit je ne suis fanboy de personne. 30 ans que je fais du Microsoft. Il y a eu du bon, tres bon et du mauvais. Le non fanboy sait faire la part de choses et reconnaitre ce qui n'est pas bien.
J'ai beaucoup d'attente sur ASPnet Core car le cahier des charges est idéal: plus qu'a esperer que MS ne s'egare pas.

---

Tu ne connais manifestement pas ton boulot, SOAP et REST répondent à des problématiques différentes. Mon client actuelle ne fait que du SOAP, pourquoi ? Authentification par certificat, système de sécurité avancé, validation des données en entré, etc. bref tout un tas de champs non couvert par REST qui est un système orienté web. Ils font du stockage de données à titre probatoire, et donc REST ne répond pas à leurs problématiques, on va pas utiliser une techno où il n'est même pas possible de valider proprement les données attendu et ou la notion de contrat est inexistante. La souplesse de REST en limite le champs d'action il est en est de même pour SOAP. Chacun son boulot.

Bref suivant les problématiques tu utilise l'un ou l'autre. Pour le reste tu es manifestement un ingénieur du dimanche qui ne comprend pas le champs d'application des outils à sa disposition.

Citation:

---

Envoyé par kilroyFR

et pour revenir sur le sujet initial, rien a dire car news pas fondamentale.

Ca fait longtemps que quel que soit l'environnement, si l'outil n'existe pas on trouve une parade
(ex : Cygwin il y a quelques années pour faire du vrai shell - pas eu a attendre powershell ni supporter les limites du cmd.exe).

---

Il ya des tes de "shell" alternatif, j'utilisais posh à une époque le runtime powershell pouvant être hébergé dans facilement dans n'importe quelle appli avec le niveau de sécu qui va bien

Citation:

---

Envoyé par Aeson

Donc t'arrive a porter une application WPF en HTML sans la ré-écrire toi ? :ptdr:

De meme pour le portage SOAP => REST. Je l'ai deja fais et si tu veus faire dur vrai REST level 3 il faut meme modifier la DAL. Faire passer du JSON ne fait pas de tes api des api REST. Desolé de te l'apprendre.



Donc aucun avantage Business. Que des problemes pour le business a cause des probleme de maturité. Tu n'as jamais du faire de budget car le budget explosera et les cout de maintenance seront de toute facon plus haut car l'app sera jeune. Encore une fois ce que tu dis montre bien que tu n'as aucune experience dans le sujet. Personne n'aprouvera ce type de budget.

Si tes besoins business ne changent pas il n'y a AUCUNE raison de decomissioner ou de ré-écrire les app WPF/WCF



Pour les nouveau projet ok pour du WebApi.



Tu compare MVC a WCF ? Vraiment ?



Non reaction d'un personne qui sais qu'il faut justifier les budgets et faire les choses comme il faut. Faire les choses n'importe comment avec un petit budget est finalement beaucoup plus cher.

---

Ce type est un guignol il ne maîtrise du tout de quoi il parle. Déjà il n'a pas compris que SOAP et REST répondent à des problématiques différentes ça laisse songeur sur la qualité de son travail. En outre, le ne maîtrise manifestement par les architectures des frameworks qu'il utilise, il mélange tout. Bref il ne sait rien.

Citation:

---

Envoyé par Aeson

Mais tu preconise de 'migrer' des applications WPF/WCF en disant que le cout de maintenance sera moin haut ? Vraiment ?

Vu ce que tu dis, a mon avis t'es qu'un developeur medior ou senior. Rien de plus.

---

Il doit encore être en première année

Une fonctionnalité intéressante serais d'avoir aussi des onglets dans cmd et powershell (voir aussi dans explorer et notepad)

Citation:

---

Envoyé par redcurve

Tu ne connais manifestement pas ton boulot, SOAP et REST répondent à des problématiques différentes. Mon client actuelle ne fait que du SOAP, pourquoi ? Authentification par certificat, système de sécurité avancé, validation des données en entré, etc. bref tout un tas de champs non couvert par REST qui est un système orienté web. Ils font du stockage de données à titre probatoire, et donc REST ne répond pas à leurs problématiques, on va pas utiliser une techno où il n'est même pas possible de valider proprement les données attendu et ou la notion de contrat est inexistante. La souplesse de REST en limite le champs d'action il est en est de même pour SOAP. Chacun son boulot.

Bref suivant les problématiques tu utilise l'un ou l'autre. Pour le reste tu es manifestement un ingénieur du dimanche qui ne comprend pas le champs d'application des outils à sa disposition.

---

Normal vous avez quelques retard; la notion de contrat n'existe pas en REST ? lol
Json Schema tu ne connais pas (trop recent pour toi surement).

Arf vous faites pitié quand je lis ca; c'est ca la releve de l'informatique; on est mal.
Perdurez dans vos certitudes PTDR; vous insultez les gens parce que vous etes arrivé au bout de vos pitoyables arguments. reaction classique de quelqu'un qui n'a plus d'argument pour essayer de se justifier.

Citation:

---

Envoyé par RyzenOC

Une fonctionnalité intéressante serais d'avoir aussi des onglets dans cmd et powershell (voir aussi dans explorer et notepad)

---

CMD n'est qu'une appli console donc tu ne peux pas la hoster. Par contre powershell est hostable tu peux donc juste créer une petit appli qui va hoster différent runtime powershell. Sinon il y a posh qui fait déjà ça.

Citation:

---

Envoyé par kilroyFR

Normal vous avez quelques retard; la notion de contrat n'existe pas en REST ? lol
Json Schema tu ne connais pas (trop recent pour toi surement).

Arf vous faites pitié quand je lis ca; c'est ca la releve de l'informatique; on est mal.
Perdurez dans vos certitudes PTDR; vous insultez les gens parce que vous etes arrivé au bout de vos pitoyables arguments. reaction classique de quelqu'un qui n'a plus d'argument pour essayer de se justifier.

---

JSON Schema n'est pas utilisable il est trop frais, on en reparlera quand il sera éprouvé et certifié, ce qui amènera à des évolutions majeure du machin. Je ne suis pas entrain de développez des services expérimentaux, on a une liste de 60 normes ISO/NAF à suivre. Et elles sont trop poussés pour REST, qui n'est pas capable de répondre à ces problématiques, ce qui n'est pas son objectif qui plus est. Ce qui est assez logique SOAP étant un protocole et REST un style d'architecture.

En outre, je suis à jour sur ce type de technos, que j'utilise quand il le faut et pas à toutes les sauces sans raison, aucune technologie ne répondant à toutes les problématiques. J'ai commencé à m'intéresser à REST vers 2002 ... ça fait un bout de temps.