Ce qui fait qu'hélas, l'argument "c'est plus facile à tester" perd beaucoup de sa superbe face à "c'est plus facile à livrer en production".
Je ne suis pas d'accord et je me battrais avec mon chef de projet pour que ce ne soit pas le cas.
Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée. Classiquement l'équipe de dev sait quel partie est correctement testée et la quelle ne l'est pas et c'est systématiquement quand il y a des tests que les évolutions sont plus rapide. Je ne fais presque plus de refactoring, sans avoir créer de test de cette partie. D’expérience ça crée beaucoup trop facilement de bug autrement.
"c'est plus facile à livrer en production"
Je n'ai pas encore réagi à ça, mais c'est vraiment problème d'organisation plus que d'architecture. Tu bousille tes données aussi bien avec l'un qu'avec l'autre, utiliser cette différence, c'est juste jouer sur l'incompétence de ton client. Il y a des millions de façons pour réduire le temps de mise en production. Il n'y a que la politique comme goulot d'étranglement et pour faire face à ça, je joue sur 2 plans :
améliorer la confiance en montrant la qualité des tests effectués ;
modifier la responsabilité en montrant que le problème/bug qu'ils ont en prod est corrigé depuis N temps de notre coté et que la balle n'est plus dans notre camps, qu'il n'est pas besoin de nous en reparler tant qu'ils n'ont pas fait de mise à niveau. Sur le long terme mettre en évidence les temps de cycle, ça a était payant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'avais des templates pour faire ce genre de choses, mais je me dis que tu peux très bien y mettre un UUID et tu te pose plus la question. Il n'y a pas de logique particulière à mettre sur cet identifiant donc autant prendre un vrai identifiant. Il n'a jamais à être lu ou compris par un humain, il faut juste s'assurer que c'est le même sur les 2 lignes. Comme c'est aligné ça se fait très bien :
avec explosion de la combinatoire… je crois simplement que nous ne sommes pas en train de parler de la même chose.
Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.
Effectivement, je ne suis pas devin. Je vais le dire autrement, cela expliquera mieux ma pensée.
L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.
C'est plutôt une méthode Agile dans la mesure où le client est présent tout du long du processus.
(Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.
Si à un instant donné, l'adaptateur peut être bien conçu (bonne synergie entre le métier et les techno) cela ne sera pas forcément le cas par la suite (et tu le disais toi même plus haut dans ton commentaire "Non, un bon choix à un moment donné n'a pas de raison de le rester.").
Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Tu te trompes. Je ne fais pas cette affirmation. Je réponds à la tienne (il faut pouvoir changer), sous-entendant donc que le choix initial est mauvais.
Non, un bon choix à un moment donné n'a pas de raison de le rester.
Les tests unitaires n'ont jamais remplacé les tests d'intégration.
Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).
Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.
Il faut anticiper au maximum.
C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.
Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)
Avoir plus de tests, oui. Il faut les écrire !
Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.
Et pour ma part, les feedbacks, ce ne sont pas les tests qui me les donnent, mais les utilisateurs.
Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :
écriture
compilation
exécution
retour à l'étape 1
Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh… comment dire… :)
Sauf que tu fais tout cela justement pour ne pas être lié à une technologie sous-jacente. Ainsi, ton choix (pertinent) d'aujourd'hui peut être une véritable plaie quand tu devras changer de techno demain.
Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pour le 3), je veux bien des explications. Que les tests ne se déroulent pas de la même manière, je le conçois. Que cela soit "moins testable"…
Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,… Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.
Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.
Pour le 2), il est lié au 1). C'est un problème uniquement si le choix initial est mauvais.
Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.
Pour le C, rien à voir. Au contraire, j'aurais plutôt tendance à dire que cela ralenti les livraisons !
Avoir plus de tests et un feedback rapide, ça ralenti ?
un coût financier tout d'abord, par le temps supplémentaire nécessaire pour les développements ;
je suis pas certains que ça prenne plus de temps
tu maîtrise mieux ton langage de base que le langage de ton bd (tu écris plus de code avec le premier)
tu as une boucle de feedback plus rapide (test unitaire vs test d'intégration) donc ça te fais aller plus vite
un coût technique, dû au surcoût (processeur, ram, etc…) lié à l'utilisation massive d'adapteurs
C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.
Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
CLion ne fournit pas d'éditeur de gui, contrairement à XCode, QtCreator ou Glade
Je connais beaucoup de développeurs web qui n'utilisent pas d'éditeur HTML graphiques. Ça ne dois pas arrêter tout le monde. AMHA avoir une boucle de feedback rapide est suffisant pour beaucoup de gens (et pas mal préfèrent du code et une boucle de feedback rapide que d'apprendre une nouvelle UI).
Une fois cela dis, je ne sais pas ce qu'il en ai pour swift (mais go est-il bien différent à ce niveau là ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je sais pas si c'est une super idée. C'est pas standard donc quand le langage va avoir sa solution. Soit ça va casser soit on va se coltiner des trucs non standard pendant encore longtemps après que ça n'est plus d'intérêt.
Par contre c'est vachement plus pratique si tu l'oblige et que tu veux valider tes sources, tu peux facilement tester que toutes tes entêtes l'ont (c'est un peu plus compliqué mais tu peux aussi vérifier de la même façon que tu n'a pas 2 fichiers avec le même marqueur ifndef).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'en ai jamais ressenti le besoin. Je fais un ctrl+z pour lancer ma commande et un fg pour repasser sur vim. Ça ne fonctionne pas si tu veux vraiment avoir un processus dans ton terminal qui tourne longtemps et continuer à éditer ton fichier.
Soit j'ai jamais rencontré ce cas soit naturellement j'ai utilisé un second shell sans y faire attention.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça pourrait fonctionner pour tout un tas de trucs : les films, les livres, les enfants, les maisons, les logiciels, etc etc.
Oui, mais justement. Quand tu présente ton travail, que ce soit ici ou ailleurs et que ce soit dans l'informatique ou non, il vaut mieux passer très vite sur ce que tu as fait pour mettre vraiment en évidence en quoi tu te distingue des autres et pourquoi est-ce que tu l'a fait. Venir expliquer qu'un éditeur de texte existe c'est gentil, venir expliquer que le nouvel éditeur de texte intègre alphago et sera capable de te poutrer au jeu de go pendant que tu essaie d'éditer ta configuration ça en dit beaucoup beaucoup plus.
C'est de la communication de base. Peu de monde ira se renseigner de lui même si on ne lui donne pas un minimum de grain à moudre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est ça la réponse des concepteurs de compilateur a cette horreur que sont les templates?
C'est la réponse de gcc au temps de compilation désastreux. La précompilation des headers est un détails d'implémentation non-couvert par la norme si je ne m'abuse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
« Après la bataille » ? C'est du libre s'ils veulent contribuer il n'y a pas de soucis (ce qu'ils font), s'ils veulent utiliser des clients alternatifs (comme celui éventuellement proposé dans leur IDE, le client lourd de github, l'excellent sourcetree ou Hg-Git) il n'y a pas de problème.
Linus a écrit git pour les développeurs du noyau linux, lui reprocher que ça ne fonctionne pas sous un OS donné (que ce soit Windows ou AIX) c'est assez risible. Ce qu'on remarque, c'est surtout que git fonctionne très bien sur tout ce qui se rapproche d'un unix. Windows est une exception, ses utilisateurs en paient le prix. C'est très utile quand on est la plateforme qui a le leadership comme pour les jeux vidéos, mais quand on ne l'est plus c'est tout de suite moins rigolo. Les annonces de ses derniers temps semblent montrer que c'est de moins en moins rigolo.
Cette peine que tu as, ne semble surtout ne pas vraiment être partagée. Si c'était si douloureux d'utiliser git sous windows, je doute que github aurait pu s'imposer avec git.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
La possibilité de réutiliser tes sources en C++, de tous ces avantages, tout en profitant des évolutions positives des nouveaux langages.
Ça rend les choses vachement complexes. Se permettre d'intégrer du C dans du C++ quand tu sais qu'historiquement le C++ a démarré comme une sur-ensemble du C, pourquoi pas. Mais créer un langage plus simple et se fader un langage complexe comme module en rab', c'est pas génial je trouve.
Par ailleurs si à chaque fois que quelqu'un décidait de créer un nouveau langage se voyait dire "pas la peine, choisis-en un parmi les autres" on serait pas aller bien loin.
Euh… Il y a une différence entre « créer un langage » et « créer un nouveau langage pour être compatible avec un existant ». Même en se plaignant que le C++ n'évolue pas assez vite au goût de chacun, il évolue. Crée un langage qui va t'apporter ce que tu aura quelques années plus tard directement en C++, ça ne me semble pas particulièrement pertinent. AMHA la première fonction d'un langage c'est d'occuper un scope clair (faire du fonctionnel) et pas la compatibilité source avec un langage existant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
À mon avis tu t'avance pas mal. L'organisation même des noyau peu être très différent et ta surcouche risque d'être pas mal intrusive dans linux. Tu n'a quasiment aucune chance d'être intégré dans l'arbre des sources du noyau et survivre en dehors de la LKML c'est une gageur (regarde les OpenVZ et autre grsecurity).
Bref le développement dans le noyau ou en tout cas pour le noyau linux est très contraignant et ce n'est pas forcément une gynastique à la quelle les développeurs de ReactOS veulent se plier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
C'est le « pragmatique » qui fait la différence. Comme tu le dis ça peut être une bonne solution pour en faire plus avec un langage donné. Mais en soit si tu as besoin de ce genre d'artifices c'est que tu a besoin d'exprimer quelque chose que ton langage en est incapable ou incapable de la façon dont tu le souhaite. C'est bel et bien un manque de ton langage.
Après c'est massivement utilisé notamment dans les technologies JS.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pareil
Posté par barmic . En réponse au journal Les interfaces tablettes. Évalué à 1.
Tu préfèrent qu'ils augmentent leur dividende ? Qu'ils achètent des machines HPC pour faire du trading haute-fréquence ?
Du moment qu'ils ne te le donne pas et qu'ils ne font pas quelque chose d'immoral/illégal avec est-ce que ça a vraiment une importance ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
Je ne suis pas d'accord et je me battrais avec mon chef de projet pour que ce ne soit pas le cas.
Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée. Classiquement l'équipe de dev sait quel partie est correctement testée et la quelle ne l'est pas et c'est systématiquement quand il y a des tests que les évolutions sont plus rapide. Je ne fais presque plus de refactoring, sans avoir créer de test de cette partie. D’expérience ça crée beaucoup trop facilement de bug autrement.
Je n'ai pas encore réagi à ça, mais c'est vraiment problème d'organisation plus que d'architecture. Tu bousille tes données aussi bien avec l'un qu'avec l'autre, utiliser cette différence, c'est juste jouer sur l'incompétence de ton client. Il y a des millions de façons pour réduire le temps de mise en production. Il n'y a que la politique comme goulot d'étranglement et pour faire face à ça, je joue sur 2 plans :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par barmic . En réponse à la dépêche ReactOS 0.4.0. Évalué à 9.
D'après google translate, ils se demandent si le projet est mort ou pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Extension
Posté par barmic . En réponse au journal Les interfaces tablettes. Évalué à 7.
Tu n'a pas besoin de stylish. Tu peux te contenter de passer par contentchrome.css.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par barmic . En réponse à la dépêche ReactOS 0.4.0. Évalué à 3.
De quel aspect commercial parle tu ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:réinventerla roue ?
Posté par barmic . En réponse à la dépêche ReactOS 0.4.0. Évalué à 5.
Si tu as un support de cette imprimante sous linux, c'est une vraie option d'utiliser un RPi et de partager l'imprimante par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 5.
J'avais des templates pour faire ce genre de choses, mais je me dis que tu peux très bien y mettre un UUID et tu te pose plus la question. Il n'y a pas de logique particulière à mettre sur cet identifiant donc autant prendre un vrai identifiant. Il n'a jamais à être lu ou compris par un humain, il faut juste s'assurer que c'est le même sur les 2 lignes. Comme c'est aligné ça se fait très bien :
C'est bourrin, mais au moins tu ne te pose plus de question. C'est de la technique, ça n'a pas besoin d'être lu par l'humain moyen.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 5.
Bof c'est la dernière ligne du fichier, tu sait que c'est pour ne pas l'inclure 2 fois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Explosion est peut être fort, mais je suis même pas sûr. Parce que tu va aussi devoir tester l'intéraction entre un bout de ton code métier (celui de la procédure stockée avec le reste du code métier). Un cas d'usage peu impliquer tes 2 parties par exemple.
L'idée ce n'est pas d'anticiper, c'est de ne pas se fermer des portes (c'est différent). C'est différent. On ne fait pas quelque chose parce qu'on sait que dans 6 mois il y aura X, on le fait parce qu'il y aura X, X', X" ou rien du tout. On présume le moins possible de ce que sera X et de ce qu'il impliquera, parce que les besoins peuvent changer beaucoup trop entre temps.
(Au passage Martin Fowler est l'un des co-auteur du manifeste agile)
Les méthodes agiles expliquent clairement que ton scope correspond à une itération et que tu n'a pas à hésiter à refactorer profondément ton code. Ton scope ce n'est pas un contrat de 18 mois, mais une itération d'un mois par exemple.
Le job ça va être de trouver la techno qui permet de réduire cette glue, mais tu ne fais pas ça rien. As toi de mettre en balance ce que ça va t'apporter par rapport à ce que ça te coûte (mais ça ne te demande pas de revalider le métier c'est déjà pas mal :) ).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Non, un bon choix à un moment donné n'a pas de raison de le rester.
Oui mais c'est précisément l'inverse dont il est question : tester du fonctionnel via des tests d'intégration. Les tests d'intégrations sont longs par nature, c'est pour cela qu'ils couvrent moins (et aussi parce qu'ils font exploser la combinatoire).
Je ne dis pas qu'il ne faut pas faire de test d'intégration, je dis que c'est dommageable d'essayer de tester le métier par des tests d'intégration.
C'est un bon moyen de se planter. Parce que je doute que tu sois meilleur devint que moi. Ton client non plus, lui refourguer cette responsabilité ne change rien au problème (ça change juste la responsabilité). C'est le principe même de l'over-engenering imaginer beaucoup et surtout beaucoup trop.
Au contraire réduire ton scope de décision au minimum et remettre à plus tard tout ce qui peut l'être jusqu'à être assez mûre pour choisir. Ce que tu propose est typiquement le cycle en V dans le quel les erreurs sont très chères ! (à tous point de vu)
Ça dépend de ce que tu entends par livrer. Si on entend par là, la livraison où l'utilisateur est satisfait de sa fonctionnalité, les tests ne coûtent rien. Ils ne coûtent rien face au temps que te coûte un bug dans la livraison et que la perte de confiance de l'utilisateur envers ton logiciel.
Ça n'a rien avoir. Il s'agit lors de ton développement du temps que tu as entre l'écriture d'une ligne et la vérification qu'elle fait ce que veux. C'est le cycle (dans la majorité des cas) :
Si ton exécution c'est des tests, tu vérifie plus rapide l'ensemble de test cas que. Si tu le fais manuellement, tu n'aura tendance à vérifier que le cas que tu es entrain de traiter (en oubliant éventuellement les cas qui sont impactés) et tu perd du temps à revenir dans l'état qui te correspond. Si tu attends que le client t'envoie un mail, euh… comment dire… :)
Ton métier évolue généralement peu. L'abstraction devrait donc rester pertinente. Cette abstraction n'est pas quelque chose qui est artificiel, elle est dépendante de ton métier. Donc elle ne doit pas être remise en cause par la technologie, mais par le métier (c'est l'idée à travers l'inversion de dépendance). Si ça devient une plaie, c'est soit que tu as mal conçu ton abstraction (ça arrive) soit que tu dois remettre en cause ta techno.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3. Dernière modification le 16 mars 2016 à 14:44.
Tu pars d'une hypothèse « j'ai fais un bon choix dès le départ » et je ne vois pas comment tu peux l'affirmer.
Je peux ajouter d'autres ressources de gens qui affirment la même chose : https://www.thoughtworks.com/talks/agile-architecture-rethink-2014 et qui ne font pas parti d'une SS2I (Martin Fowler c'est déjà un peu plus respectable ?)
Je l'ai déjà dis, l'article redis la même chose presque mot pour mot (je ne travail pas chez Xebia) : t'a boucle de feedback est grande, tes tests sont longs (à écrire comme à exécuter), t'a donc tendance à en faire moins,… Je vais pas redire encore une fois tout le tralala. Les tests d'intégration n'ont pas la même complétude que les tests unitaires.
Une expérience qui peut être intéressante est de faire du DDD. C'est de ce que je connais la manière la plus efficace de tester la logique métier.
Pas forcément. Ton logiciel évolue ces contraintes aussi donc les technologies que tu utilise n'ont plus forcément la même pertinence. Même sans changer de technologie, ta techno sous-jacente peut évoluer et ce que tu faisais d'une manière à une époque peut avoir était déprécié 5 ans plus tard.
Avoir plus de tests et un feedback rapide, ça ralenti ?
C'est le choix de la bonne abstraction. Je serais joueur, je t'expliquerais que tu choisi la bonne abstraction au départ et donc que ça va (c'est comme choisir des techno). Comme je ne le suis pas je te dirais qu'avoir des abstractions dirigés par ton besoin métier est vraiment intéressant, parce que la taille de ton adaptateur va dépendre de la pertinence de ta techno sous-jacente. Ça te donne un élément très utile sur comment choisir tes technologies.
Je suis tout à fait d'accord ce n'est pas une solution miracle, mais c'est une solution intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Facile!
Posté par barmic . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
Si ça t'intéresse, je me permet d'ajouter un lien qui montre que je ne suis pas le seul à avoir rencontré ce genre de problème :
http://blog.xebia.fr/2016/03/16/perennisez-votre-metier-avec-larchitecture-hexagonale/
Sans même aller jusqu'à la description de l'architecture, l'introduction présent exactement les problèmes que j'ai décris plus haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pourquoi pas ? Parce queeeeeee !
Posté par barmic . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 3.
Je connais beaucoup de développeurs web qui n'utilisent pas d'éditeur HTML graphiques. Ça ne dois pas arrêter tout le monde. AMHA avoir une boucle de feedback rapide est suffisant pour beaucoup de gens (et pas mal préfèrent du code et une boucle de feedback rapide que d'apprendre une nouvelle UI).
Une fois cela dis, je ne sais pas ce qu'il en ai pour swift (mais go est-il bien différent à ce niveau là ?).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bien pour débuter, et plus…
Posté par barmic . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 5.
L'idée n'est pas forcément d'innover mais de comprendre l'ambition du projet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 4.
Je sais pas si c'est une super idée. C'est pas standard donc quand le langage va avoir sa solution. Soit ça va casser soit on va se coltiner des trucs non standard pendant encore longtemps après que ça n'est plus d'intérêt.
Par contre c'est vachement plus pratique si tu l'oblige et que tu veux valider tes sources, tu peux facilement tester que toutes tes entêtes l'ont (c'est un peu plus compliqué mais tu peux aussi vérifier de la même façon que tu n'a pas 2 fichiers avec le même marqueur
ifndef).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Donc en résumé
Posté par barmic . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 7.
J'en ai jamais ressenti le besoin. Je fais un ctrl+z pour lancer ma commande et un fg pour repasser sur vim. Ça ne fonctionne pas si tu veux vraiment avoir un processus dans ton terminal qui tourne longtemps et continuer à éditer ton fichier.
Soit j'ai jamais rencontré ce cas soit naturellement j'ai utilisé un second shell sans y faire attention.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Donc en résumé
Posté par barmic . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 10.
Oui, mais justement. Quand tu présente ton travail, que ce soit ici ou ailleurs et que ce soit dans l'informatique ou non, il vaut mieux passer très vite sur ce que tu as fait pour mettre vraiment en évidence en quoi tu te distingue des autres et pourquoi est-ce que tu l'a fait. Venir expliquer qu'un éditeur de texte existe c'est gentil, venir expliquer que le nouvel éditeur de texte intègre alphago et sera capable de te poutrer au jeu de go pendant que tu essaie d'éditer ta configuration ça en dit beaucoup beaucoup plus.
C'est de la communication de base. Peu de monde ira se renseigner de lui même si on ne lui donne pas un minimum de grain à moudre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 3.
C'est la réponse de gcc au temps de compilation désastreux. La précompilation des headers est un détails d'implémentation non-couvert par la norme si je ne m'abuse.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Expérience enrichissante
Posté par barmic . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 4.
« Après la bataille » ? C'est du libre s'ils veulent contribuer il n'y a pas de soucis (ce qu'ils font), s'ils veulent utiliser des clients alternatifs (comme celui éventuellement proposé dans leur IDE, le client lourd de github, l'excellent sourcetree ou Hg-Git) il n'y a pas de problème.
Linus a écrit git pour les développeurs du noyau linux, lui reprocher que ça ne fonctionne pas sous un OS donné (que ce soit Windows ou AIX) c'est assez risible. Ce qu'on remarque, c'est surtout que git fonctionne très bien sur tout ce qui se rapproche d'un unix. Windows est une exception, ses utilisateurs en paient le prix. C'est très utile quand on est la plateforme qui a le leadership comme pour les jeux vidéos, mais quand on ne l'est plus c'est tout de suite moins rigolo. Les annonces de ses derniers temps semblent montrer que c'est de moins en moins rigolo.
Cette peine que tu as, ne semble surtout ne pas vraiment être partagée. Si c'était si douloureux d'utiliser git sous windows, je doute que github aurait pu s'imposer avec git.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cppfix ?
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 3.
Il en est où question performance ? Je présume que les optimisations du compilateur n'étaient pas la priorité au début.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: cppfix ?
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 5.
Ça rend les choses vachement complexes. Se permettre d'intégrer du C dans du C++ quand tu sais qu'historiquement le C++ a démarré comme une sur-ensemble du C, pourquoi pas. Mais créer un langage plus simple et se fader un langage complexe comme module en rab', c'est pas génial je trouve.
Euh… Il y a une différence entre « créer un langage » et « créer un nouveau langage pour être compatible avec un existant ». Même en se plaignant que le C++ n'évolue pas assez vite au goût de chacun, il évolue. Crée un langage qui va t'apporter ce que tu aura quelques années plus tard directement en C++, ça ne me semble pas particulièrement pertinent. AMHA la première fonction d'un langage c'est d'occuper un scope clair (faire du fonctionnel) et pas la compatibilité source avec un langage existant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ReacOS
Posté par barmic . En réponse à la dépêche ReactOS 0.4.0. Évalué à 9.
C'est un jeu de mot entre ReactOS et réactionnaire…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: réinventer la roue ?
Posté par barmic . En réponse à la dépêche ReactOS 0.4.0. Évalué à 10.
À mon avis tu t'avance pas mal. L'organisation même des noyau peu être très différent et ta surcouche risque d'être pas mal intrusive dans linux. Tu n'a quasiment aucune chance d'être intégré dans l'arbre des sources du noyau et survivre en dehors de la LKML c'est une gageur (regarde les OpenVZ et autre grsecurity).
Bref le développement dans le noyau ou en tout cas pour le noyau linux est très contraignant et ce n'est pas forcément une gynastique à la quelle les développeurs de ReactOS veulent se plier.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 3.
C'est le « pragmatique » qui fait la différence. Comme tu le dis ça peut être une bonne solution pour en faire plus avec un langage donné. Mais en soit si tu as besoin de ce genre d'artifices c'est que tu a besoin d'exprimer quelque chose que ton langage en est incapable ou incapable de la façon dont tu le souhaite. C'est bel et bien un manque de ton langage.
Après c'est massivement utilisé notamment dans les technologies JS.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C'est bien dommage
Posté par barmic . En réponse au journal C++17 est sur les rails. Évalué à 4.
Comment ça arrive ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)