Claude SIMON a écrit 566 commentaires

  • [^] # Re: ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -1.

    Je n'ai jamais prétendu qu'il n'est pas possible d'utiliser MVC pour une interface native, mais il me semble que MVC, c'est plutôt presque la règle pour les interfaces web, alors que c'est plutôt l'exception pour les interfaces natives…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Mais il n'y a vraiment pas de quoi...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 0.

    Sommaire

    Salut !

    Salut !

    Je vais prendre le temps de te dire ce que je pense de ton approche :) Ça va peut être être rude, mais comprends bien que si je prends du temps pour écrire un commentaire c'est bien que je veux être constructif. De plus je distingue totalement ton travaille de la personne que tu es (c'est important). Mais il y a pas mal de choses à dire je trouve.

    Super ! Je n'attend que ça, des commentaires constructifs !

    Ton approche

    Background

    Tu connais le C++, tu vis le C++ en autarcie, tu nous explique à longueur de journée que les pratiques classiques comme les tests ne sont pas pour toi.

    Bon, on ne va pas reprendre cette discussion ici, mais je n'ai jamais dit que les tests ne sont pas pour moi. Tout ce que j'ai dit, c'est que, comme tout un chacun, je me sentirais bien mieux si je pouvais prendre le temps de soumettre mon code à des test, mais que, ce n'est pas, pour moi, en l'état actuel des choses, économiquement viable de passer du temps à écrire des tests. Peut-être qu'un jour, le temps que je gagne à ne pas écrire de tests sera significativement inférieur au temps que j'aurais gagné en soumettant mon code à ces tests. Ce jour-là, j'écrirais des tests. Quoiqu'il en soit, j'encourage tout un chacun à écrire des tests auxquels soumettre leur code.

    En informatique comme ailleurs affirmer que l'on est plus malin/différents/le cas à part, c'est se tromper.Tu as des centaines de milliers de personnes dans le monde qui après une cinquantaine d'années à tenter de construire une certaine qualité logicielle. Arriver et dédaigner leur travail, par un « bof c'est pour les autres », c'est forcément se tromper.

    Où ai-je affirmé de telles choses ? Le fait est que, moi, je n'ai absolument aucun problème avec les personnes qui ne codent pas uniquement en C++. Par contre, il semble que, parmi ces personnes, il y en a à qui cela pose un gros problème que je code uniquement en C++

    On exerce une science dure, pour affirmer des choses il faut avoir des arguments autre que « je fais de la factorisation poussée » (personne d'autre ne factorise ?). De tout ce que tu nous as décrit ça "fonctionne" parce que tu es le seul à coder et que tu accepte de voir très tard les bugs (tu reconstruit les autres logiciels et tu teste s'il plantent).

    Si tu relis la partie que tu cites, tu constateras que j'ai explicitement parlé d'hypothèse, et que donc je reconnaissais implicitement que ce que j'avançais n'était peut-être pas la bonne explication. Quand aux bugs, je les découvre peut-être plus tard que si j'utilisais une batterie de tests, mais toutefois suffisamment tôt pour qu'ils ne gênent pas mes clients. Et c'est le plus important, non ? (Par contre, ton histoire de reconstruire les autres logiciels et de tester s'ils plantent, là, je n'ai pas trop compris…)

    Tu pars donc très très très mal : tu nous propose d'utiliser un code pas tester (yay !), mais pour quoi donc ?

    Je n'écris pas explicitement de code de test, mais je lance toutefois quand plusieurs fois même mon application au cours de son développement pour voir si elle se comporte correctement, et, en outre, sur plusieurs plate-formes (notamment GNU/Linux, macOS et Windows)…

    Objectif

    Tu ne sais faire que du C++, quelqu'un te demande de faire du web, tu fais du web en C++. Très bien. Mais la populace fais déjà du web avec un tas d'autres choses. Il va falloir nous donner une raison d'abandonner nos stack libres bien plus fiables que la tienne (dont le copyright est partagé, supporté par une communauté, testée, testée massivement,…).

    Pourquoi devrais-je donner une raison ? Je donne à tout un chacun le moyen de tester ma bibliothèque pour qu'il puisse se forger sa propre opinion à son propos. Après, libre à lui d'en rester à sa stack bien-aimée ad vitam æternam, peu me chaut…

    En plus du web, il existe un énorme paquet de techno qui apparaît. Ça signifie qu'il y a déjà énormément d'idées qui ont étaient essayée. D'autant que ça fais des années que ça dure !

    Euh… Soit ! Et ?

    Tu ne nous a pas donné d'autres arguments sur le pourquoi utiliser ta pile autre que c'est du C++ et c'est simple… oui mais.

    J'ai surtout donné un moyen, que j'ai essayé de rendre le plus simple possible, pour tout un chacun de l'essayer et ainsi de pouvoir se forger sa propre opinion… (oui, je sais, je me répète).

    Alternatives

    Tu n'a aucune idée de si c'est simple, tu en ai l'utilisateur-codeur et tu n'es même pas allé voir ce qui se fait ailleurs. On ne souffre pas la comparaison quand on en fait pas mais on va forcément la faire pour toi. Qu'est-ce que ça donne comparé à du CGI ? Qu'est-ce que ça donne face à Wt ? Pourquoi les gens choisiraient le code d'un développeur dans son garage (pas testé) par rapport à tout ce qui peut exister ailleurs ?

    Si, je suis allé voir ce qui se faisait ailleurs, mais cela ne me convenait pas. Et comme c'est déjà les principes de base qui ne me convenaient pas, je n'ai pas essayé, donc je suis particulièrement mal placé pour émettre une comparaison objective de ma bibliothèque avec l'existant. Et encore une fois, je n'essaie de convaincre personne d'utiliser ma bibliothèque…

    J'ai parlé de techno C++, mais alors j'ai pas de doute qu'en PHP, Java et JS c'est pire encore.

    Pas compris ce tu essayes d'exprimer, là…

    Finalement

    En vrai je ne sais pas pourquoi tu nous présente des plus ou moins portages dans d'autres langages, tu ne les utilise pas et tu n'explique pas en quoi les développeurs de ce langage gagneraient à utiliser ton code.

    Déjà, ce ne sont pas des portages, mais des bidings, c'est à dire que le cœur de la bibliothèque est le même, quelque soit le langage utilisé. Et, encore une fois, pourquoi j'essayerais de convaincre qui que ce soit par quelqu'argument que ce soit des qualités de ma bibliothèque s'il existe un moyen, que j'ai essayé de rendre le plus simple possible, de l'essayer (bis, ou plutôt, ter repetita) ? S'il n'est alors pas capable de se forger sa propre opinion, je ne peux rien pour lui…

    Pire encore, tu nous parle d'une bibliothèque C++, je sais pas ce qu'elle fais. Si je vais voir http://atlastk.org/ (pas de https ?), tu nous dis que c'est du C++ donc c'est rapide. Si tu ne le corrobore pas avec des benchmarks c'est du vent. Tu nous explique pas en quoi ta bibliothèque est performante. Quelle archi est-ce que tu utilise ? Comment-est-ce que tu t'assure que tes bindings restent performant ? Tu connais netty ? C'est ce qui permet à Java d'être performant sur le réseau, il faut vraiment avoir des arguments pour pouvoir dire qu'on est plus performant que ça.

    (Si, il y a du https, mais je ne force personne à l'utiliser.)

    Sérieux, tu veux vraiment que je développe, ou fasse développer, ma bibliothèque dans tous les langages disponibles juste pour pouvoir faire des benchmarks ?

    La bibliothèque étant à l'état de prototype, il est inutile de rentrer dans les détails techniques, vu que ces derniers ont de grandes choses de considérablement évoluer…

    Concernant le C++, je ne pense que beaucoup considère que ce soit un mauvais choix si on cherche à obtenir les meilleures performances possibles…

    La mise en œuvre

    D'un point de vu utilisateur

    Ton code nous montre du html dans des String. Donc on peut dire au revoir à la validation du html. On peut faire autrement ? Très bien montre nous et c'est là dessus qu'on évaluera si c'est facile ou pas.

    Comme j'ai dit dés l'introduction, je ne suis pas familier avec Java. Certaines fonctions prennent une String devant contenir du HTML, et j'ai donc créer le contenu de ces String à la main pour éviter d'avoir à installer un outil tiers (il y a peut-être un outil fournit en standard ; n'ayant pas cherché, je l'ignore), et cela fonctionne très bien. Maintenant, s'il y en a qui sont incapables d'écrire du code HTML valide à la main, libre à eu de passer par l'outil de leur choix…

    Tu nous montre aussi des manipulation de DOM, c'est affreux à utiliser… et c'est extrêmement lent ! C'est bien pour ça que toutes les techno utilisent un DOM virtuel… Aie…

    Les goûts et les couleurs…

    Perso., je préfère manipuler le DOM que de passer systématiquement par un moteur de template et de me farcir du MVC. Mais ça, c'est mon choix personnel, que je n'impose à personne.

    Et je rappelle que ce qui est présenté ici, comme indiqué dans l'introduction de ce journal, c'est un prototype, donc quelque chose de largement améliorable. Il est tout à fait possible qu'à partir d'une des prochaines version de cette bibliothèque s'appuie sur un DOM virtuel.

    D'un point de vu conception

    Si je regarde Atlas.jar c'est ta classe principale, hein ? Tu as des chemins codés en dur dans ton code… C'est pas une question de java, il n'y a pas de langage dans le quel c'est une bonne pratique…

    Les chemins en dur ne sont utilisés que dans mon environnement de développement. Si ma bibliothèque est installé en suivant la procédure indiquée dans ce journal, ces chemins ne sont pas utilisés.

    Tu lance des Threads non managés. Tu ne les nettoie pas. Ton code explose, c'est une garantie.
    D'après toi qu'est-ce qui est affiché par ce code ?
    java
    public void foo() {
    System.out.println("start");
    new Thread(() -> {
    try {
    Thread.sleep(1_000);
    } catch (InterruptedException e) {
    e.printStackTrace();
    }
    System.out.println("Hello");
    }).start();
    System.out.println("end");
    }

    Même si tu ne lançais un thread qu'à chaque connexion, ça exploserais à quelques dizaines de milliers de connexions. Le problème ce n'est pas que tu refuserais des connexions, mais bien que le serveur tombe à ce moment là…

    Encore une fois, la version présentée ici n'est qu'un prototype. Si une meilleure gestion des threads est requise, elle sera implémentée..

    Et je n'ai aucune idée de ce qui est affiché par ton code (et je m'en contrefiche un peu…).

    Tentons de voir s'il n'y a pas un truc que je rate dans ton code. Si je tente de lancer ton premier exemple :

    michel@MBA:/tmp/tmp.msaUgm9EXO % java -cp .:Atlas.jar Hello
    java.lang.UnsupportedOperationException: The BROWSE action is not supported on the current platform!
       at java.awt.Desktop.checkActionSupport(Desktop.java:225)
       at java.awt.Desktop.browse(Desktop.java:381)
       at info.q37.xdhq.dom.DOM_DEMO.<init>(DOM_DEMO.java:154)
       at info.q37.xdhq.DOM.<init>(DOM.java:48)
       at info.q37.atlas.DOM.<init>(DOM.java:24)
       at info.q37.atlas.Atlas.<init>(Atlas.java:28)
       at Hello.<init>(Hello.java:3)
       at Hello.main(Hello.java:48)
    Exception in thread "Thread-0" java.lang.NullPointerException
       at info.q37.xdhq.DOM.getAction(DOM.java:62)
       at info.q37.atlas.Atlas.run(Atlas.java:38)
       at java.lang.Thread.run(Thread.java:748)
    

    Mais ça continue à s'exécuter, mais il n'écoute pas de port. Awt c'est une bibliothèque graphique, je ne sais pas ce que ça vient faire là, je pensais lancer un serveur web… Le code lance, une classe démo de ta bibliothèque ?…

    En fonctionnement normal, un serveur est effectivement lancé, mais ce fonctionnement, tel que la bibliothèque est codée, nécessite l'installation de code natif en local. Pour éviter cela, et, du coup, simplifier la procédure d'installation, le fonctionnement pas défaut ne lance pas de serveur.

    Je vais un peu plus loin. Tu tente silencieusement d'accéder à "http://atlastk.org/atlas.php?_token=c6f39490-1d1d-4e1d-9f21-b7eec4935e5d". Là ça commence à vraiment être mauvais tu piste potentiellement les gens qui utilisent ta techno…

    Je tente tellement silencieusement d'accéder à cette adresse qu'elle est normalement affichée en clair dans la console à partir de laquelle l'application est lancée… Mais elle ne s'est probablement pas affichée chez toi à cause du message d'erreur.

    Cette adresse est en fait celle à laquelle on doit se connecter avec un navigateur web pour accéder à l'application qui vient d'être lancée. Normalement, un navigateur pointant sur cette adresse est automatiquement lancé, mais ça échoue chez toi, peut-être parce que tu as lancé l'application dans un environnement sans interface graphique (quoique ce cas est normalement prévu).

    Quand à l'erreur, je pensais avoir traité le cas de figure où le lancement d'un navigateur n'est pas possible, mais apparemment pas. Normalement, dans ce cas de figure, un message est affiché dans la console invitant à ouvrir un navigateur à l'adresse que tu as relevée.

    Je passe sur une partie de ton message, car, malgré le message d'erreur, l'application fonctionne probablement. Il suffit de se connecter avec un navigateur web à l'adresse que tu as relevée (attention : elle change à chaque lancement de l'application). En tout cas merci pour le pointeur pour corriger le problème concernant le lancement d'un navigateur.

    Pour ma première partie :

    garde l'humilité d'aller voir ce qui se fait ailleurs

    Ne t'en fait pas, je regarde volontiers ce qui se fait ailleurs, non par humilité, mais par simple curiosité…

    si tu veux qu'on passe du temps à apprendre ton truc explique nous ce qu'il a de plus et être en C++ ça n'est pas une bonne raison (surtout si c'est pour tout coder en java)

    Entièrement d'accord, le fait d'être codé en C++ n'est absolument pas un critère en soi pour utiliser une bibliothèque (et je n'ai jamais prétendu le contraire), fût-ce à travers un binding Java ; en fait, ça serait même une raison de ne pas utiliser cette bibliothèque pour tout autre langage que le C++, compte tenu de l'inaptitude du gestionnaire de paquets de la plupart des langages (s'il existe !) à gérer correctement le déploiement de code natif. Mais, comme dit, avec la procédure d'installation telle que détaillée dans ce journal, il n'y a pas ce problème, puisque il n'y a pas de code natif qui est installé localement.
    Le seul but de ce journal, c'est de présenter un projet et de fournir un moyen simple de l'essayer. Si ce projet ne vous intéresse pas, il vous suffit de passer votre chemin (si possible, sans essayer de me convaincre de ne pas utiliser C++ pour faire du web ; ce n'est pas le sujet, et ça n'apporte absolument rien au débat). S'il vous intéresse, libre à vous de l'essayer, et de me faire remonter vos observations, que je lirais attentivement, via les commentaires.

    Et, encore une fois, tout n'est pas codé en Java. Ce qui est codé en Java, c'est uniquement un wrapper (en fait, c'est un peu plus qu'un simple wrapper).

    J'ai passé du temps a regarder ce que tu as fais et à rédiger mon commentaire (il est mieux construit au début qu'à la fin, mais c'est la fatigue), je sui réellement allé cherché ton code et j'ai tenté de le lancer. Comprends que si ton truc ne marche pas en y aillant passé environ 1h30 à 2h, c'est qu'il y a un vrai problème. Je connais le java et je peux aller voir ce qu'il s'y passe. J'aurais pu lancer n'importe quel hello world vu, angular, react, elm, python ou brainfuck en 10 minutes. En terme de qualité c'est très loin de ce que l'on peut attendre d'un truc qu'on voudrait réutiliser (dans un cadre professionnel ou pas).

    Désolé que tu y ai passé tout ce temps, alors que ça fonctionnait probablement dés le début… Et encore une fois, c'est indiqué dans le journal, ce qui est présenté ici, c'est un prototype, donc quelque chose qui est uniquement mis à disposition pour quiconque voudrait l'essayer, et absolument pas pour être utilisé dans un cadre professionnel…

    En tout cas, merci d'avoir pris le temps d'essayer ce logiciel, et de rédiger un commentaire qui soit plus constructif que la plupart de ceux que j'ai pu lire jusqu'à présent… Il me confirme que je suis vraiment pas doué en terme de communication…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Lapin compris

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 0.

    J'avais prévenu que je n'y connaissais pas grand chose à Java

    Si j'ai bien compris, comme déjà indiqué dans un précédent commentaire, je suppose qu'il faut que le new rende la main de suite, et qu'il y ai une fonction genre launch() qui, elle, soit bloquante…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 0.

    Je ne dis pas que MVC n'est pas utile dans certains cas, mais de là à l'utiliser systématiquement…

    En outre, ce n'est pas parce que des toolkits offrent des facilités pour faire du MVC que ces facilités sont utilisées…

    À moins que tu ne suggères qu'il y ai des toolkits dédiés au développement d'interfaces natives qui fonctionnent, en interne, selon le modèle MVC. Je serais curieux de voir un tel toolkit de prés, pour peu qu'il soit un tant soi peu populaire…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -3.

    Être obligé de jongler avec plusieurs langages en fonction du type d'application à développer ? Non merci, je préfère pouvoir développer tout type d'application en utilisant un seul langage ; c'est beaucoup plus efficace.

    Ou pas.
    Mon stage de fin d'études c'était justement la migration d'une application mono-langage (Progress 4GL) à une pile de langages plus spécialisés (Java, HTML, JS, SQL). Eh bien la pile de langages était infiniment plus facile à comprendre et utiliser que l'espèce de soupe qui prétendait tout faire, des requêtes à la BDD aux effets présentés à l'utilisateur.

    Non mais, sérieux, comparer le C++ avec cette horreur de PROGRESS

    Après, je n'impose à personne de n'utiliser qu'un seul et même langage. S'il y en a qui préfèrent en utiliser plusieurs, grand bien leur fasse, mais je ne vois pas au nom de quel principe, parce que à eux, ça leur réussit, il ne serait pas possible de faire tout aussi bien avec un seul langage, à fortiori lorsqu'il s'agit du C++

    Ça fait la troisième fois (en comptant la version Node.js) qu'ont dit que mon code est nettement perfectible (ce dont j'ai parfaitement conscience, comme je l'ai à maintes fois indiqué). Je veux bien, mais est-ce que quelqu'un aurait la bonté de me montrer ne fût-ce qu'un exemple de ce qui ne va pas, et comment le corriger, histoire que j'ai l'occasion d'améliorer mon code ? Ou alors je vais finir pas penser que mon code n'est peut-être pas aussi mauvais que certains le prétendent !

    Je vais être sec aussi, mais en ce qui concerne ton code Java, il n'y a tellement rien qui va que te l'expliquer en détail est un travail si énorme que c'est décourageant.

    J'avais prévenu que je n'y connaissais pas grand chose en Java !

    Si je prends juste en exemple le TODO MVC :

    Le fichier s'appelle main.java mais ne contient pas de classe publique qui s'appelle main.

    OK.

    Le fichier n'est pas dans un package.

    OK.

    Deux classes (package-protected) dans le même fichier.

    Là, je ne comprend pas trop.

    Tu utilises des new String("…").

    Ah. Ça pose problème ? Si je fais String toto = "tutu", je suis bien obligé de faire un toto = new String("...") si je veux réutiliser toto, non ?

    int index = this.index; ?!

    D'ailleurs tu passes ton temps à masquer la variable de classe index avec des variables locales index.

    Comme je modifie this.index juste après, il fallait que je stocke sa valeur. Bon, j'aurais pu modifier this.index à la fin, et l'utiliser à la place de la variable locale, mais je ne trouvais pas ça conceptuellement très propre.

    Tu n'utilises pas les possibilités de l'API standard (l'itérateur ligne 43, le while ligne 197 par exemple, ou tout le bloc de if / else if à partir de la ligne 230).

    Pour l'itérateur, je ne connaissais pas. Pour la boucle if/else, je pense que c'est par rapport au switch. C'est pour rester compatible avec Java < à 1.7, vu que les switch avec des String ne sont disponibles qu'à partir de cette version. Bon, maintenant, si on me dit que ce n'est pas la peine de rester compatible avec ces versions-là, je switcherai volontiers du if/else au switch.

    if ( false ) { !?

    Je mets à true pour certains essais, comme ça la todo list n'est pas vide au lancement.

    La ligne 273 ressemble beaucoup à une boucle infinie.

    Parce que c'en est une. Si j'ai bien compris, il faudrait que le new rende tout de suite la main, et qu'il soit suivi d'une fonction genre launch() qui, elle, serait bloquante.

    Ton main lance Exception, ce qu'il ne devrait pas faire, et en plus rien dans ton code ne déclare que cette Exception devrait être lancée.

    Il devait y avoir une méthode qui lançait Exception dedans à un moment, je pense…

    Tu appelles des méthodes avec leur package complet au lieu de les importer (info.q37.xdhq.XDH.readAsset).

    Ah, je ne savais pas que c'était déconseillé.

    Tout est ultra-manuel : génération de XML à la main en dur dans le code, méthode escape que tu as réinventé, etc.

    Toute la partie XML a été fait en mode quick and dirty, parce que je n'ai pas trouvé de bibliothèque simple à installer qui le prenne en charge, et que, de toute manière, rien n'est imposé à l'utilisateur, pour peu qu'il fournisse à la fin une chaîne contenant du XML valide. Par contre, s'il existe une méthode toute faite pour remplacer mon escape(), je suis preneur…

    Tout est en vrac dans un seul fichier : personnellement je ne comprends pas ce que fait ce code à sa simple lecture.

    Je voulais éviter la multiplication des fichiers, vu que ça a tendance à effrayer…

    J'imagine que le index de la classe TodoMVC pourrait être nullable pour gérer le cas particulier au lieu d'utiliser la valeur spécifique -1.

    Je pense que oui… Ceci dit, je ne pensais pas qu'on pouvais nuller un type primitif…

    Dans la méthode push tu modifies ton paramètre xml.

    C'est sûr que la méthode que tu proposes est mieux, mais il me semblait avoir essayé un truc similaire, et cela ne fonctionnait pas. Peut-être un problème dû à l'utilisation d'une version antérieure de Java ?

    La logique contient des triples négations : dans handleCount tu as un else sur une condition négative qui active un truc qui s'appelle HideBidule. Au final ça fait quoi ?

    Si le nombre de todos actifs est différent du nombre total de todos, alors ça signifie qu'il y a des todos achevés, et donc il faut afficher le bouton permettant leur effacement, sinon il faut le cacher.

    D'ailleurs le projet s'appelle TODO MVC mais n'est pas du tout du MVC ?!

    C'est le but. Le projet dont est tiré l'application s'appelle TodoMVC et met effectivement en œuvre une architecture MVC, parce que c'est requis par la plupart des frameworks les plus populaires. Mais pourquoi utiliser cette architecture si l'on peut s'en passer ?

    Je passe sur les détails comme le formatage, la présence d'un System.out, l'import de packages complets ou le manque d'accolades.

    On utilise quoi, alors, à la place de System.out pour afficher quelque chose dans la console ?

    Je passe aussi sur ton API qui me semble très étrange, comme ces méthodes qui attendent un tableau de tableau de String.

    En fait, c'est pour passer des paires de Strings, chaque paire étant une clef associée à une valeur. Si on passe deux tableaux de String, un pour les clefs, l'autre pour les valeurs, on perd le lien direct clef/valeur. Du coup, qu'est-ce que je peux utiliser à la place d'un tableau de tableau de String ?

    (non testé).

    (et pourtant, il n'y a vraiment pas grand chose à installer pour ça…).

    En tout cas, merci d'avoir pris le temps de suggérer des améliorations. Je modifierais les fichiers concernés en conséquence, une fois que j'aurais terminé le binding PHP (je préviens d'avance, je ne m'y connais pas plus en PHP qu'en Java).

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -2.

    La quantité ne fait pas la qualité…

    La plupart des solutions les plus populaires s'appuient sur une architecture MVC, et je n'en vois pas l'intérêt. Ça fait des décennies que l'on développe des application avec une interface native, sans qu'on ai jamais eu besoin de recourir à MVC. Pourquoi cela serait différent avec les applications web ?

    Pour répondre à ta question, oui, je compte vendre du service, mais cela ne constitue qu'une partie du business model envisagé…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -4.

    Alors, je ne suis pas sûr que tu apprécies des masses ce message mais ça fait plusieurs fois que ce que tu dis me choque un peu. Et comme tu en remets une couche régulièrement, je vais me permettre.

    Oh, ne t'en fait pas. Je suis habitué à ce genre de message. Il n'y a qu'à voir les commentaires en réponses aux journaux dont j'ai donné la liste dans mon précédent commentaire. Beaucoup ont essayé de me convaincre, avec des arguments à l'emporte-pièce, que je faisais fausse route, sans jamais réussir à étayer leurs affirmations avec des éléments concrets. On va voir si ça va être différent cette fois-ci…

    Or, les SSII (pardon, les ESN) ne veulent pas de moi, à cause de mon profil atypique (C++, ce n'est pas ce qu'il y a de plus populaire et, en plus, j'utilise mes propres bibliothèques, et pas celle fournies en standard), bien qu'ils reconnaissent que j'ai une approche qui me permettent d'être bien plus polyvalent que la majorité des développeurs.

    Ben oui, c'est un problème de ne vouloir utiliser que ses propres bibliothèques plutôt que ce qui est universellement reconnu comme standard. C'est contre productif et je ne pense pas que cela t'aide à progresser non plus.

    OK, c'est un problème d'utiliser mes propres bibliothèques plutôt que celles standards. C'est bien ce que j'explique dans mon commentaire. Par contre, vu mon historique par rapport au C++, que je détaille dans ce commentaire, je ne vois pas en quoi c'est contre productif et que cela ne m'aide pas à progresser…

    Et je ne pense pas que ce soit ce qu'on peut appeler être polyvalent…

    Ce que j'appelle être polyvalent, c'est être en mesure de développer n'importe quel type d'application. Et je pense qu'on est plus efficace si l'on utilise toujours le même langage quelque soit le type d'application, plutôt que d'avoir à jongler entre plusieurs langages selon le type d'applications à développer… On maîtrise plus facilement un langage seul que plusieurs…

    C'est aussi un problème de vouloir utiliser un marteau (le C++) pour visser (faire du web). Il y a un moment, il faut savoir choisir un outil adéquat. D'autant qu'entre PHP, Ruby, Python, NodeJS, Java… il y a quand même un sacré choix de composants pour faire du web avec énormément de saveurs différentes. Alors, oui, je suis sûr qu'on peut trouver des frameworks C++ pour faire du web mais cela reste hyper confidentiel et mon humble avis est que ce n'est pas hyper adapté.

    Les outils C++ existants ne sont en effet guère adaptés pour faire du développement web. Mais cela ne signifie pas que le C++ lui-même n'est guère adapté pour faire du web. D'ailleurs, la bibliothèque que j'ai développé, moi, je la trouve parfaitement adaptée au web. Bien plus que celles qu'on trouve (et qui sont d'ailleurs plus souvent des frameworks) pour, je cite, PHP, Ruby, Python, NodeJS, Java… Et question diversité, on repassera. Avec ces langages, soit on fait du web à l'ancienne, du type CGI, soit on est obligé de se coltiner du JavaScript pour le front-end ou un des ces encombrants frameworks MVC. Il y en a qui trouve ça adapté, mais, désolé, je ne suis pas de cette avis. Et je ne suis pas le seul…

    Un autre souci, c'est que, même si tes technologies sont libres, tu ne libères pas tes clients mais tu les enfermes car personne d'autre que toi ne les maîtrise. Et vu la manière dont elles sont conçues, je ne pense pas que cela change ni que ce soit un problème de communication seulement.

    Tes arguments sont applicables à toute technologie naissante, y compris tous les langages que tu as cités précédemment. À leur lancement, peu de personnes les maîtrisaient. Si leurs concepteurs s'étaient arrêtés à des arguments comme les tiens, aucun de ces langages n'aurait percé…

    Rien que le fait que tu essaies de marier du C++ et du NodeJS, ça va faire fuir la majorité des gens : très peu de développeurs web font du C++. Et encore moins du C++ custom avec tes bibliothèques à toi. Recoupe ça avec les développeurs NodeJS et tu comptes tes potentiels utilisateurs sur les doigts de la main.

    Node.js, c'est développé en C++, donc ma bibliothèque n'est pas une union contre nature ! Et ma bibliothèque n'est qu'un module de plus parmi tout ceux que l'on trouve sur http://npmjs.com/, et elle s'utilise comme n'importe lequel de ces modules. Les utilisateurs n'ont pas plus à se préoccuper du fait qu'elle soit codée en C++ que pour n'importe lequel des modules fournis en standard avec Node.js.

    Si tu veux répondre au mieux aux besoins de tes clients, essaie d'utiliser des projets Open Source existants avec une vraie communauté : tu te concentreras sur leur besoin et ils auront une solution plus pérenne et plus de capacité à changer de presta si nécessaire. De plus, ce sera l'occasion d'apprendre plein de choses, je ne jugerai pas ton C++ vu que je n'y connais rien mais pour ce qui est du Java, il y a énormément de lacunes et pas que des lacunes dues à la méconnaissance du langage.

    Déjà, mes clients sont tout à fait satisfait de mes prestations ; ce n'est donc pas ça le problème. Surtout parce que, avec ce que je leur ai réalisé, je répondais mieux à leur besoin que ce que n'importe quel autre développeur a pu leur proposer (je sais que ça fait prétentieux, mais je ne fais que répéter ce qu'ils m'ont dit). Entre un logiciel pérenne qui ne répond pas à leurs besoins, et un autre, peut-être moins pérenne, mais qui répond parfaitement à leurs attentes, ils ont vite choisi…

    Ça fait la troisième fois (en comptant la version Node.js) qu'ont dit que mon code est nettement perfectible (ce dont j'ai parfaitement conscience, comme je l'ai à maintes fois indiqué). Je veux bien, mais est-ce que quelqu'un aurait la bonté de me montrer ne fût-ce qu'un exemple de ce qui ne va pas, et comment le corriger, histoire que j'ai l'occasion d'améliorer mon code ? Ou alors je vais finir pas penser que mon code n'est peut-être pas aussi mauvais que certains le prétendent !

    Dans une veine assez proche de ce que tu veux faire, il y a Wicket, qui est un petit projet Apache très sympa dont les principes sont assez simples et qui est très bien conçu. Ca et du Spring Boot et tu auras quelque chose de plus attrayant.

    Possible, mais j'aimerais savoir en quoi c'est plus attrayant. Et, pour aussi attrayant que ce soit, ça n'a pas l'air d'être beaucoup utilisé (comparativement à d'autres solutions). Donc, il est tout à fait possible que, pour certains, ma solution soit plus attrayante que la plupart de celles qui existent, y compris Wicket.

    Ca n'est évidemment que mon avis mais je pense que tu devrais t'ouvrir à d'autres choses et t'ouvrir à apprendre et à être plus flexible, plutôt que rester arquebouté sur ce que tu connais.

    À travers cette bibliothèque, et parce qu'elle est implémentée en C++, j'ai pu m'ouvrir à Java, Node.js, PHP. Et ce n'est qu'un début. Comme le C++ s'interface avec quasiment la totalité des langages existants, j'ai des perspectives d'ouverture (pour moi, et pour ma bibliothèque) quasi infinies. Alors, désolé, mais je reste à mon C++. Je ne pense pas qu'il y ai beaucoup de développeurs Java qui peuvent s'ouvrir à PHP de cette manière…

    C'est ça la polyvalence.

    Être obligé de jongler avec plusieurs langages en fonction du type d'application à développer ? Non merci, je préfère pouvoir développer tout type d'application en utilisant un seul langage ; c'est beaucoup plus efficace.

    Désolé si c'est un peu dur mais je pense que c'est important que ça te soit dit.

    Encore une fois, beaucoup d'affirmations sans aucun élément concret pour les étayer.

    Rien que pour revenir à ma bibliothèque, celle-ci étant un binding Java d'une bibliothèque C++, C++ qui n'est soit-disant pas adapté au web. Il ne devrait pas être difficile de coder l'équivalent de l'application Hello, World! présentée dans ce journal, en Java, ou d'ailleurs avec n'importe quel autre langage, en s'appuyant sur les technos existantes, et qui mette en évidence la supériorité de cette implémentation sur à celle que j'ai réalisée avec ma bibliothèque. Ça ne devrait pas prendre plus de cinq minutes, vu que mon implémentation se code en moins de temps que ça, installation comprise… Bien entendu, il faut que cette implémentation offre les mêmes possibilités d’accès aux ressources du langage sélectionné que mon implémentation. Une page web, avec du code JavaScript, ça se réalise en moins de cinq minutes, mais ça ne répond pas au cahier des charges…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Il vaudrait mieux te mettre en contact avec quelqu'un qui connait Java

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 1.

    Je te conseille de te rapprocher d'un développeur Java […]

    Je voudrais bien, mais je n'en connais point…

    Parce qu'il existe déjà un outil qui fait ça, c'est GWT – et que donc tu y seras obligatoirement comparé.

    Je n'ai pas étudié GWT en détail, mais, puisqu'il est cité, j'en profite pour exposer quelques différences notables que j'ai cru déceler :

    • c'est un framework
      • qui vient avec tout un ensemble d'exécutables à utiliser, notamment pour la création d'une application et pour son lancement,
      • qui met en place toute une arborescence de fichiers,
    • au final, ce n'est pas du Java qui est exécuté, mais du JavaScript compilé à partir du Java,
    • l'interface est construite programmatiquement, et non pas à l'aide d'un fichier descriptif,

    Tout ces points ne sont pas nécessairement des inconvénients. Cependant, avec ATK (c'est le petit nom de la bibliothèque décrite dans ce journal) :

    • c'est une simple bibliothèque ; un import info.q37.atlas.*; et ça roule,
    • on peut construire l'interface avec un simple fichier HTML (on peut aussi le faire programmatiquement),
    • on code/lance une application web avec ATK comme n'importe quelle application Java (utilisation de javac/java ; pas besoin d'exécutables maisons),
    • pour la tester, un simple .jar à télécharger (~22 Ko) au lieu d'une archive de ~90 Mo pour GWT,
    • suffit de connaître HTML, CSS, DOM pour l'utiliser (en théorie, mais, vu le premier commentaire, ça n'a pas l'air aussi évident que ça), l'API s'inspirant fortement de celle en JavaScript pour manipuler le DOM.

    Comme dit, je n'ai jamais utilisé GWT, et je ne suis pas familier avec Java, donc s'il y a des inexactitudes, n'hésitez pas à les signaler…

    Parce que ton code ressemble tellement peu à du Java que tes exemples te desservent au lieu de te vendre.

    Je m'y attendais un peu, d'où mon texte introductif dans le journal. Mais, hélas, je ne connais pas de développeur Java, donc si une bonne âme pouvait m'indiquer les améliorations à apporter…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Lapin compris

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à -1.

    Je ne suis pas spécialiste de Java, donc il y a peut-être effectivement un problème.

    Ceci dit, le code lancé lors du new (https://github.com/epeios-q37/xdhq-java/blob/ee418c808a0cb64c8559e8e31ff51cf6459a2c28/src/DOM_DEMO.java#L135 ne rend la main que lorsqu'il y a une nouvelle connexion. En tout cas, ça à l'air de fonctionner ; il suffit de l'installer pour le constater.

    Zelbinium: Your Devices, Your Rules!

  • [^] # ... et pas qu'un ...

    Posté par  (site web personnel) . En réponse au journal Du développement full-stack en Java. Évalué à 2. Dernière modification le 03 août 2018 à 10:02.

    Il y a clairement un problème de communication. Le problème, c'est que je n'ai aucun talent en la matière. En outre, les technos que j'expose dans ce journal, d'une, c'est moi qui les ai développées, et, de deux, je les utilise quotidiennement. C'est donc difficile pour moi de me mettre à la place de quelqu'un qui les découvre, tant il y de choses qui me semblent être évidentes les concernant, et qui ne le sont en fait pas du tout.

    Le problème est le même pour d'autres de mes technos, au sujet desquels j'ai écrit plusieurs journaux. En terme de communication, un site comme http://q37.info/ est clairement inadapté.

    J'ai donc changé de stratégie en me concentrant sur une seule technologie, accessible à partir de plusieurs langages (Java, Node.js et PHP ; d'autres langages sont prévus), et en lui consacrant un site mieux structuré que http://q37.info/, à savoir http://atlastk.org/. Malgré mes efforts (et aussi mon manque de connaissances en matière de SEO), ce n'est pas suffisant, comme on peut le constater à l'activité des forums.

    Je suis freelance. Or, les SSII (pardon, les ESN) ne veulent pas de moi, à cause de mon profil atypique (C++, ce n'est pas ce qu'il y a de plus populaire et, en plus, j'utilise mes propres bibliothèques, et pas celle fournies en standard), bien qu'ils reconnaissent que j'ai une approche qui me permettent d'être bien plus polyvalent que la majorité des développeurs. Or, hors SSII ESN, la prospection est difficile, déjà que ce n'est pas une activité qui me passionne.

    Cette bibliothèque me sert donc de vitrine commerciale, pour me faciliter la prospection. Mais surtout, j'envisage de monter une structure commerciale pour la valoriser d'une manière ou d'une autre. Malheureusement, vu notamment mes talents de commerciaux et en marketing, et comme souligné dans ces commentaires, c'est le genre de projet qu'on ne peut monter seul. Et les partenaires adéquats ne se trouvent pas sous le pas d'un cheval.

    D'un point de vue technique, il faut savoir que le cœur de cette bibliothèque s'appuie sur du C++. Or, les gestionnaires de paquets, comme npm pour Node.js ou composer pour PHP, ne sont pas conçus pour déployer du code natif. Ce qui rend l'installation de cette bibliothèque compliquée.

    Pour contourner ce problème, j'ai conçu un mode de fonctionnement de cette bibliothèque qui permet de déporter sur un serveur la partie native, à laquelle accède la partie (non native) de la bibliothèque déployée localement. Ça facilite son installation, le but étant de fournir un moyen facile de tester cette bibliothèque, notamment en évitant d'avoir à déployer un serveur. Le code natif installé sur le serveur est celui des repository xdhwebq-cli et xdhq, et le code (non natif) installé localement par l'utilisateur est celui des repository atlas-java et xdhq-java (atlas-node et xdhq-node pour la version Node.js).

    Avec maintenant une procédure d'installation simplifiée, qui évite aux utilisateurs d'avoir affaire à du code natif, je me concentre sur la mise au point de l'API telle que décrite dans https://atlastk.org/api/java/0.2 (https://atlastk.org/api/node/0.2 pour Node.js).

    J'envisage d'animer, à la rentrée, des ateliers de développement qui s'appuient sur cette bibliothèque. Pour quelqu'un qui soit un tant soit peu familier avec un des langages pour lesquels cette bibliothèque est disponible (Java, Node.js ; PHP sous peu, et d'autres langages plus tard), ces ateliers seront l'occasion de mieux comprendre les technos au cœur du web (HTML, CSS et DOM) en apprenant à les manipuler grâce à cette bibliothèque. Cette bibliothèque est donc conçue pour un très large public, et si elle n'est pas perçue comme telle, c'est clairement qu'il y a un souci de clarté (si je puis dire).

    N'hésitez donc pas à signaler précisément ce qui manque de clarté, même si c'est des points très techniques ; ça me sera certainement très utile pour améliorer le contenu du site ainsi que le contenu des ateliers…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: C++ mon amour

    Posté par  (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 1.

    Merci pour ces renseignements.

    Je n'ai pas encore regardé en détail, mais

    • Wt semble conçu pour développer des applications web monopage,
    • CppCMS, c'est pour des application de type CGI,
    • Beast, c'est juste pour le back-end, donc, pour le front-end, soit on passe par JavaScript, soit par un moteur de template.

    Ils ne sont pas vraiment interchangeables…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Facilité

    Posté par  (site web personnel) . En réponse au journal Le développement full-stack facilité. Évalué à 1. Dernière modification le 28 juillet 2018 à 18:06.

    Dans les deux derniers repository dont les liens sont donnés dans le journal (xdhq et xdhwebq-cli, répertoire src). C'est ce qui tourne sur le serveur auquel se connecte le module Node.js installé en local. Il y a aussi du C++ dans le repository xdhq-node, mais il n'est pas utilisé dans ce mode de fonctionnement de la bibliothèque.

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: C++ mon amour

    Posté par  (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3.

    Nous utilisons même Wt, une bibliothèque qui propose la création d'applications Web que l'on code comme en QT, pour nos interfaces utilisateurs.

    Intéressant, je ne connaissais pas. Pourtant, j'ai cherché. En fait, j'étais tombé dessus, mais je me suis fait avoir par alternativeTo, qui présente Wt comme une alternative à Apache, nginx, lighttpd… donc j'ai cru que Wt est un serveur web…

    Est-ce que Wt propose un langage descriptif d'interface, comme QML pour Qt, ou est-ce qu'il faut construire l'interface programmatiquement, élément par élément ? Personnellement, je préfère partir d'un fichier qui décrit globalement l'interface (j'utilise HTML(/CSS)), même pour des applications avec interface bureau. C'est cette approche que j'ai choisie pour le projet dont j'ai donné le lien dans mon précédent commentaire, et qui à le même but que Wt, sauf qu'il n'a pas (encore) d'API C++, bien que ce soit le langage avec lequel il est codé. Si j'avais eu connaissance de Wt, peut-être que je ne me serais pas lancé dans ce projet…

    Zelbinium: Your Devices, Your Rules!

  • # Mon histoire avec le C++

    Posté par  (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10. Dernière modification le 27 juillet 2018 à 18:05.

    Avec mon premier ordinateur (un Sinclair ZX81), ainsi qu'avec ceux que je me suis offerts par la suite (y compris mes calculatrices HP), mon activité principale a toujours été la programmation. Durant un certains temps, j'ai papillonné entre différents langages, essentiellement différentes versions de BASIC.

    Lors de ma première année de mon cursus informatique, on a vu plusieurs langages, mais essentiellement à titre d'information (Fortran, LISP, Prolog, divers assembleurs…), pour finalement se concentrer sur le Pascal. Dés lors, je développais tous mes logiciels en GFA Basic sur mon Amiga, avant de les transcrire en (Turbo-)Pascal, pour pouvoir les faire tourner sur nos PC du lycée, qui faisait tourner MS-DOS.

    Puis j'ai découvert le C. Enfin pouvoir faire tourner (après recompilation, évidemment) tous mes programmes développés sur mon Amiga sur les PC du lycée sans avoir à les transcrire. Bon, évidemment, j'ai été confronté a quelques problèmes de portabilité, mais qui ont vite été résolu avec quelques directives préprocesseurs bien senties.

    Puis j'ai été amené à choisir entre le C++ (oui, on y arrive) et Java. J'ai hésité pendant assez longtemps pour finalement choisir le C++. Rétrospectivement, je me rend compte que j'ai choisi le C++ pour des mauvaises raisons, dû à une certaine méconnaissance de Java, mais que j'ai finalement quand même fait le bon choix.

    Je suis quasiment resté au C++ de mes débuts. Les seules nouveautés que j'ai adoptées sont les mutables (parcimonieusement), mais surtout, et c'est relativement récent, les variadics templates (je ne connais pas le terme français). J'étais souvent tenté d'utiliser les fonctions variadiques, issues du C, mais je me réfrénais car ce sont de vrais appeaux à bugs. Mais, depuis que je peux utiliser les variadics templates à la place, je me lâche. Ceci dit, il m'arrive encore d'utiliser les fonctions variadiques, car il y a des situations où l'on ne peut les remplacer par des variadics templates.

    Quand je fais référence au langage que j'utilise pour développer, je parle de C/C++, mais pas au sens donné dans la dépêche. Je signifie par ce terme que je développe en langage C++, mais sans utiliser les bibliothèques C++, ni même C, standards. Comment ce fait-ce ?

    J'ai, un jour, était engagé sur une mission durant laquelle je devais développer un logiciel en C++, logiciel destiné à être utilisé en production. Comme compilateur, je disposais d'une des premières versions de Visual C++ (sur cette version, le multitâche était une option expérimentale qui devait être explicitement activée ; par défaut, lorsqu'on lançait une compilation, on ne pouvait pas manipuler les fichiers sources en même temps !). Je prend donc la documentation papier officiel sur la STL, et voit, en première page, une notice enjoignant de ne pas utiliser la STL en production car celle-ci n'est pas suffisamment stable. Donc, exit la STL.

    Pour les autres bibliothèques, j'ai été un jour été confronté à une fonction de la bibliothèque C++ standard qui ne se comportait pas de la même façon sur mon Amiga que sur un PC sous Windows. Du coup, je l'ai recodée en m'appuyant sur des fonctions de la bibliothèque C standard. Malheureusement, l'une de ce fonctions était sérieusement buguée. Du coup, j'ai recodé ma fonction en utilisant les bibliothèques systèmes, et j'ai constaté un net gain en matière de performance par rapport à la même fonction proposée par la bibliothèque standard. C'est là que j'ai commencé à développer et à utiliser mon propre jeu de bibliothèques basées sur des fonctions des bibliothèques systèmes, et à définitivement tourner le dos aux bibliothèques C et C++ standards.

    Je n'ai jamais regretté d'avoir choisi le C++, car j'ai toujours pu compter sur lui pour développer de nouvelles fonctionnalités. Je me suis longtemps cantonné aux daemons et aux utilitaires en ligne de commande, puis j'ai du développer des interfaces bureau. Pour ce faire, je me suis appuyé sur XULRunner (https://linuxfr.org/users/epeios/journaux/xulrunner-et-c), codé en C++, et donc avec une API C++, bien que mal documentée, l'API officielle étant celle en JavaScript. J'ai également développé mes premières applications web, de type CGI, en C++, bien que, déjà à l'époque, on prétendait que le C++ n'était pas adapté à cet usage.

    Cependant, les applications web CGI ne sont pas adaptées à certains types d'applications qui réclament un minimum de réactivité, et je me suis demandé si, encore une fois, je pouvais compter sur le C++ pour réaliser une bibliothèque me permettant de développer des applications web du même niveau que celles réalisés avec les meilleurs technologies actuelles. Là, j'avoue que ça n'a pas été facile, mais, encore une fois, il ne m'a pas laissé tombé, et je peux ainsi prétendre être un développeur C++ fullstack, pour reprendre un terme à la mode (c'est important les termes à la mode pour trouver du boulot !).

    En outre, le C++ est relativement facilement interfaçable avec à peu prés n'importe quel langage. J'en ai donc profité pour écrire des bindings de la bibliothèque ci-dessus pour différents langages (https://linuxfr.org/users/epeios/journaux/le-developpement-full-stack-facilite).

    Pour en revenir au sujet de la dépêche, est-ce qu'aujourd'hui encore, avec tout le choix de langages actuel, choisirais-je encore le C++ ? Si c'est pour parvenir au même confort d'utilisation que j'ai aujourd'hui grâce à mes bibliothèques, et sachant qu'il n y a rien qui ne puisse être fait avec les langages actuellement disponibles que je ne puisse faire en C++, la réponse est oui.

    Mais, d'un autre coté, le développement de ces bibliothèques prends du temps. J'ai eu de la chance de pouvoir développer les fonctionnalités relatives à certaines technologies au fur et à mesure qu'elles se sont répandues. Quand j'ai commencé à travailler sur mes bibliothèques, Internet n'était pas démocratisé, et le web n'existait pas. J'ai testé mes bibliothèques réseaux sur un réseau constitué de ma machine de développement reliée à l'une de mes vieilles machines, n'ayant pas alors accès à Internet.

    Bref, j'ai pu entreprendre à l'époque, vu le contexte, une démarche qui est inenvisageable aujourd'hui, car elle me prendrait trop de temps avant de pouvoir être concurrentiel par rapport à la plupart des développeurs au regard de toutes les fonctionnalités disponibles en standard avec la plupart des autres langages. Donc, aujourd'hui, le C++, juste avec les bibliothèques standards ou des bibliothèques tierces, ne me parait plus être le plus adapté pour certains types de logiciels, surtout si l'on peut apprendre plusieurs langages pour choisir lequel on utilise en fonction du type d'application à développer…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Non moi j'aime bien ...

    Posté par  (site web personnel) . En réponse au journal Le développement full-stack facilité. Évalué à 3.

    Merci !

    Un des objectifs de cette bibliothèque, c'est qu'il suffit d'avoir des notions de HTML et de CSS, ainsi que de savoir ce qu'est le DOM d'un navigateur web, pour pouvoir l'utiliser. Le développement d'une interface web avec cette bibliothèque présente beaucoup de similitudes avec le développement d'une interface bureau, ce qui, je pense, en facilite son utilisation…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Facilité

    Posté par  (site web personnel) . En réponse au journal Le développement full-stack facilité. Évalué à 3.

    L'initiative est sympa mais un Hello World "moderne" qui me demande d'apostropher chaque ligne de mon langage de balisage comme il y a 15 ans en faisant fi des modèles de libellés ne m'inspire pas forcément confiance dans un milieu qui ne manque pas de projets très bien organisé.

    Les fonctions de l'API prennent un string comme paramètre. Ces strings peuvent être construites comme on le désire, pour peu qu'elles contiennent, au final, du HTML valide. La manière dont c'est fait ici n'en est qu'une parmi d'autres. Pour l'application TodoMVC, le contenu de ces strings est récupéré à partir d'un fichier. Pour le Hello, World!, j'ai préféré embarqué le contenu de ces strings directement dans le code source pour éviter de multiplier les fichiers. Si il y a une meilleure manière de faire, je suis preneur. L'un des buts de ce journal est justement de recueillir ce genre de renseignements.

    Ton exercice de TODO n'est pas vraiment un exemple de facilité et de modernité non plus, à comparer avec celui de VueJs par exemple, bien plus clair et plus agréable à lire.

    Pareil. La façon de faire n'en est qu'une parmi d'autre. S'il y a une meilleure façon de faire, quitte à modifier l'API, je suis tout à fait preneur.

    Y a-t-il un avantage ou une spécificité par rapport à tous les cadriciels listés sur Todomcv (un site pratique d'ailleurs merci pour le pointeur) ?

    Je n'ai jamais utilisé ce genre de cadriciel, vu que, à la base, le but de cette bibliothèque est d'offrir la possibilité de développer une application web entièrement en C++, ce qui n'est pas faisable avec ces cadriciels. Il m'est donc difficile de répondre de manière précise. À priori, je pense que quelqu'un qui développe des applications bureau sera plus à l'aise pour développer des applications web avec ma bibliothèque qu'avec ces cadriciels. En tout cas, j'espère que, avec les procédures décrites dans ce journal, que j'ai essayé de simplifier au maximum (les procédures, pas le journal, quoique), chacun devrait facilement pouvoir tester cette bibliothèque, et, avec l'application TodoMVC, pouvoir la comparer avec l'existant, pour pouvoir se faire sa propre opinion…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 2. Dernière modification le 24 juillet 2018 à 20:26.

    Comment tu factorise ton code ? J'essaye de factoriser mon code mais parfois je ne sait pas trop quelle partie séparer d'une fonction dans une autre fonction. Combien de ligne il faut au maximum pour une fonction ?

    Alors là, pour le coup, je vais perdre le peu de crédibilité qui pouvait me rester.

    En fait, je n'ai pas de règle. C'est purement intuitif.

    Parfois, je regarde juste mon code, et il ne me plait pas, sans que je puisse dire pour quelle raison. Je ne tarde alors pas de découvrir que je peux remplacer des groupes d'instructions par des appels à des fonctions de mes bibliothèques.

    D'autres fois, j'écris du code et tout d'un coup je me dis "(censuré), mais j'ai déjà écrit ça. Bon sang, mais c'est bien sûr, c'est pour (une autre fonctionnalité présentant des similitudes avec celle que je suis en train d'écrire)". J'isole le code commun, je l'embarque dans une fonction, et je le déporte généralement dans une de mes bibliothèques. Souvent, cette fonction existe déjà, et il ne me reste plus qu'à l'utiliser.

    Du coup, il m'arrive de réécrire du code parfaitement fonctionnel juste parce que, uniquement sur une intuition, je le trouve perfectible. Et je n'ai de cesse de le retoucher jusqu'à ce qu'il ai atteint une certaine forme de perfection. Oui, je sais, ça s'apparente plus à un travail d'artisan qu'à celui d'ingénieur, mais c'est viscérale, je ne peux m'en empêcher.

    Tout ça ne t'est sans doute pas très utile, mais je ne vois pas trop ce que je pourrais dire de plus…

    Comment tu gère la remontée d'erreur ? Parce que un de mes programmes que je développe en C++ à peu ou pas de gestion d'erreur. J'aimerai m'améliorer sur ce point là.

    Les exceptions. C'est un mécanisme qui m'a semblé très tôt idéal pour gérer les erreurs. À tel point que j'utilisais ce mécanisme lorsque je développais encore en C, avant que je me mette au C++, alors que les exceptions n'existaient pas encore (la gestion des erreurs en C reposait ou repose encore essentiellement sur le traitement des valeurs de retour des fonctions). L'astuce, c'est que j'avais implémenté un mécanisme similaire aux exceptions du C++ à l'aide de la bibliothèque setjmp.

    Généralement, mes fonctions ont un paramètre optionnel qui, si absent, lance une exception lorsqu'une erreur survient. Si l'exception n'est pas interceptée, mes bibliothèques sont conçues pour afficher le nom du fichier et le numéro de la ligne à l'origine de l'exception. Alternativement, soit j'intercepte l'exception et réalise l'action adéquate, soit je passe une valeur à la fonction qui lui indique de ne pas générer d'exception si une erreur survient, mais de retourner une valeur dédiée que je teste au retour de la fonction pour, encore une fois, réaliser l'action adéquate, généralement l'affichage d'un message informant l'utilisateur d'un problème.

    Il y a un certains nombre de fonctionnalités dont je n'ai plus besoin de m'occuper de le gestion d'erreur. Par exemple, si j'ai un logiciel susceptible d'écrire un fichier qui existe déjà, j'ai tout un mécanisme qui crée automatiquement une copie du fichier avant de l'écraser, et qui rétablit automatiquement ce fichier si une erreur survient. Donc, si le programme échoue, j'ai le contenu du fichier comme si je n'avais jamais lancé le logiciel, même si le logiciel avait déjà commencé à écrire des données, soit, si le logiciel s'exécute sans problèmes, j'ai la nouvelle version du fichier, plus une copie de l'ancien fichier avec une extension du genre .bak. Et tout cela est géré automatiquement par mes bibliothèques.

    Et j'ai ainsi toute une série de mécanismes qui se mettent en œuvre automatiquement avec une gestion adéquate des erreurs sans que j'ai à m'en préoccuper (gestion des arguments de la ligne de commande, gestion de la base de registre de mes logiciels, gestion des fichiers de configuration et des locales…).

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 3.

    Alors, mon hypothèse, et ce n'est rien de plus qu'une hypothèse, c'est que, plus un code est ancien et factorisé, plus rapidement les bugs introduits pas des modifications interagissant avec ce code sont détectés. J'ignore dans quelles proportions chacun de ces critères influe sur le résultat final, en admettant mon hypothèse fondée, mais mon code étant très ancien (informatiquement parlant) et très factorisé, il cumule de toute manière les deux avantages. Je ne sais pas en quel langage tu développes, mais, en terme de factorisation, il y a moyen d'atteindre des sommets avec les templates du C++.

    Du code réputé mature, pour moi, ce n'est non seulement du code qui fait exactement ce pourquoi il est conçu, mais également qui te fournit une information pertinente si on lui demande de réaliser des choses qui n'ont pas de sens. Au début du développement de mes bibliothèques, il m'arrivait d'avoir des bugs que j'imputais en premier lieu à mes bibliothèques pour me rendre compte qu'au final le bug se situait dans le code appelant ces bibliothèques. J'ai donc modifié mes bibliothèques de telle manière que, si cette situation se reproduit, elles produisent un message qui me permette facilement de détecter l'origine du bug.

    Il m'arrive également d'introduire des, disons, comportements indésirables lorsque je modifie une de mes bibliothèques, mais, sans doute parce que le code est très factorisé (encore une fois, ce n'est qu'une hypothèse), le code fautif est rapidement mis à contribution et donc son comportement erratique détecté.

    Il faut savoir que, chaque jour, de manière automatisé, des utilitaires que j'ai développés, et qui sont donc basés sur mes bibliothèques, sont utilisés de manière intensive. Ces utilitaires, je les recompile régulièrement. Aujourd'hui, il est rare qu'un bug induit par des modification de mes bibliothèques ne soient détectés qu'après recompilation de ces utilitaires, mais peut-être qu'auparavant, c'était eux qui faisaient office de tests, rendant inutile l'écriture de tests spécifiques…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 1.

    L'argument de dire que quand on utilise de vieux algo / structure de données donne moins de bug ne prouve rien ! D'autant plus que les contraintes de l'époque ne sont plus les mêmes aujourd'hui …

    Mais je n'entend rien prouver du tout. J'expose un fait, et j'avance une explication. Si tu en as une meilleure, je suis preneur.

    Les problèmes d'allocation mémoire, ce n'est qu'une infime partie des bugs qui ne sont pas détectés par les outils d'analyse de code généralement …

    Possible, mais les bugs que j'ai exposé dans mon précédent commentaire constituent la quasi-majorité de ceux que je rencontre, et le fait est qu'ils sont relatifs de manière générale à la gestion de la mémoire dynamique.

    Il y a tout un tas de problèmes que tu ne peux pas détecter même en diversifiant les contextes de combinaison d'appel de tes fonctions, avec en vrac :

    • les effets de bord de ré-utilisation des ressources déjà utilisées
    • les effets de bord dû aux accès concurrentiels
    • les effets de bord dû au fait que tu ne contrôle pas l’environnement d’exécution ou les entrés de tes fonctions
    • etc.

    Problématiques que j'ai prises en compte lors du développement de mes bibliothèques. Et les problèmes qui m'auraient échappés, vu depuis combien de temps j'utilise ces bibliothèques, il y a belle lurette que les bugs afférents se sont révélés et que je l'ai ai corrigés (là encore, c'est juste une hypothèse, mais je n'en vois pas d'autre ; et je le rappelle : l'élément-clef de ma méthode de développement, c'est la factorisation).

    Bref, tout ça pour dire qu'à mon humble avis, me concernant, c'est très difficile et peu rassurant de ne pas avoir à minima du test unitaire à l'intérieur des API qu'on écrit soit même.

    Je ne vois pas où est la difficulté, mais je suis parfaitement d'accord ; savoir que du code a passé une batterie de tests, unitaires ou autres, est très rassurant pour celui qui l'a développé, et je ne fais pas exception. Peut-être suis-je le développeur le plus chanceux de l'univers, mais pourquoi diable irai-je écrire des tests qui, en l'état actuel du code que je développe, ne me servirait qu'à me faire perdre du temps ?

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 1.

    Ben déjà, je compile systématiquement (avant livraison) avec Visual C++, g++ et clang sous GNU/Linux, macOS et Windows, pour IA-32, AMD64 et AArch(32|64) (ARM), et je ne laisse passer aucun warning. Ça doit déjà éliminer pas mal de bugs. Ensuite, je n'appelle jamais les fonctions C de la bibliothèque d'allocation dynamique de la mémoire (malloc, calloc, free…), et c'est rarissime que je fasse appel (au sens propre et au sens figuré) aux opérateurs new et delete. Et quand je les utilise, là je fais extrêmement attention, notamment pour éviter les fuites mémoires.

    Lorsque j'ai besoin de mémoire dynamique (dont la gestion est reconnu être à l'origine de nombreux bugs), j'utilise des objets dont le développement a débuté il y a plus de 15 ans, et que j'utilise systématiquement. Après tout ce temps, la probabilité qu'il subsiste un bug est très faible. Les seuls bugs liés à la gestion de la mémoire lorsque j'utilise mes bibliothèques sont au nombre de deux : soit je n'ai pas initialisé un objet, soit je passe un objet par valeur au lieu de le passer par référence. Et le système de gestion d'erreur de mes bibliothèques me permet de rapidement déterminer quel est l'objet concerné, et de corriger ce qui ne va pas.

    Je ne manipule jamais directement la mémoire ; pas de tableau de pointeur, ou de pointeur sur un tableau. Je n'utilise jamais l'opérateur [] pour accéder à un élément de tableau ; j'utilise à la place des opérateurs de mes objets.

    Le corollaire de ceci, c'est que, pour les boucles, je ne me rappelle même plus la dernière fois que j'ai écris un for (en fait, si, mais ce n'était pas du C/C++). Si je veux parcourir un conteneur, nommons-le C par exemple, c'est toujours de la manière suivante :

    sRow Row = C.First();
    
    while ( Row != qNIL ) {
     // Traitement sur C( Row ).
    
     Row = C.Next( Row );
    }

    Du coup, jamais de bug lié à un dépassement de limites. À noter que les indexes des conteneurs sont typés, ce qui fait que, si jamais j'utilise l'index d'un conteneur pour accéder à un élément d'un autre conteneur, j'ai tout de suite une erreur lors de la compilation.

    Lorsque je livre une nouvelle version d'un logiciel suite à l'implémentation d'une nouvelle fonctionnalité, je le fais juste après quelques tests manuels pour voir si la fonctionnalité est implémenté correctement. Il se peut que parfois le client découvre un cas de figure pour lequel le logiciel ne se comporte pas comme il faut, mais c'est généralement très vite corrigé. Et là, écrire des tests ne servirait à rien, puisque si je n'ai pas pensé à tester ce cas de figure manuellement, je n'aurais pas non plus penser à écrire le test correspondant.

    Quant aux régressions, dont l'un des but des tests est de faciliter la détection, le fait est que c'est rarissime que j'y sois confrontés. La seule explication que je vois c'est que je suis extrêmement rigoureux, notamment en ce qui concerne la factorisation, que j'applique dés que la possibilité s'en présente.

    Honnêtement, à chaque fois que je livre un logiciel, j'ai un peu mauvaise conscience, vu que, contrairement à ce qui semble se pratiquer à la lecture des différents commentaires, je ne le soumets qu'à quelques tests manuels. Mais tout mes clients ont toujours été satisfait de mes prestations, ce qui permet de me consacrer exclusivement au développement de nouvelles fonctionnalités et à leur amélioration, tâche autrement plus intéressante que de coder de tests. Le jour où cette absence de tests devient problématique, et bien je m'y mettrais aussi, ou peut-être changerais-je de métier…

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 5.

    https://github.com/epeios-q37

    Zelbinium: Your Devices, Your Rules!

  • # Faire des tests, c'est bien, mais...

    Posté par  (site web personnel) . En réponse au journal Faites des tests !. Évalué à 2. Dernière modification le 22 juillet 2018 à 16:18.

    Je vais sans doute me faire lyncher, d'autant plus que l'on n'est pas vendredi, mais comme chacun y va de son expérience personnelle pour ériger en règle absolue qu'on ne saurait produire du logiciel de qualité sans le soumettre à une batterie de tests, il n'y a pas de raison que je ne fasse pas part de la mienne comme exception à cette règle.

    Alors, que ce soit bien clair : FAITES DES TESTS ! Vos développements logiciels ne s'en porteront que mieux ; les miens n'y font pas exception.

    Comme tout un chacun, j'aurais l'esprit plus tranquille si je livrais mes logiciels après leur avoir fait passer avec succès une batterie de tests. Mais le fait est que le codage de ces tests prend plus de temps qu'il ne m'en ferait gagner. C'est donc une activité que je ne peux me permettre en tant que développeur professionnel, car, le temps étant de l'argent, elle est économiquement non justifiable. Pour être honnête, il me faut aussi avouer que je préfère de loin coder de nouvelles fonctionnalités que des tests (et je ne suis probablement pas le seul)…

    J'ai bien été confronté à quelques bugs qui auraient été détectés nettement plus précocement, et donc corrigés plus facilement et plus rapidement, si j'avais pris la peine de soumettre le logiciel concerné à des tests, mais cela m'est arrivé tellement rarement que cela ne peut justifier l'écriture systématique de tests pour tous mes logiciels. Oui, même l'exception à la règle a son exception :-).

    Mon cas est sans doute exceptionnel, voire unique, mais c'est probablement dû à la manière unique, ou du moins exceptionnelle, que j'ai de développer.
    Je suis développeur C++, mais je n'utilise aucune bibliothèque C++ (en particulier, je n'ai jamais utilisé la STL), ni même C standard. J'utilise mes propres bibliothèques. Et à chaque fois que je développe une nouvelle fonctionnalité, j'essaie de la généraliser au maximum, ou d'en extraire un maximum de sous-fonctions, pour les inclure à ces bibliothèques. Ce qui fait que je n'utilise que du code factorisé au maximum. Or, plus un code est factorisé, plus il est utilisé, et ses bugs sont donc d'autant plus rapidement détectés et corrigés. Ce qui rend probablement les tests superflus dans mon cas.

    Encore une fois, même si moi j'arrive à m'en passer, FAITES DES TESTS !!!

    Avant de vous lancer dans des commentaires enflammés, en voici quelques-uns sur le sujet déjà publiés en ces lieux : https://linuxfr.org/users/fredx/journaux/ce-qu-on-demande-a-un-developpeur-aujourd-hui#comment-1471811

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Pareil

    Posté par  (site web personnel) . En réponse au message Logiciel d'écriture de texte/journal chiffré.. Évalué à 4.

    Comme Zim est évoqué, et que je suis passé de Zim à QOwnNotes pour les raison suivantes, peut-être que ce dernier peut convenir, vu qu'il a un menu Encryption.

    Contenu de la note avant chiffrage :

    # Test encryption
    
    Ceci est le contenu à encrypté.
    
    ## un titre markdown
    ### un autre titre markdown
    
    Un *peu* de :
    
    - **mise** en 
    -  forme.

    et après chiffrage :

    # Test encryption
    
    <!-- BEGIN ENCRYPTED TEXT --
    LCJ6QbKhajOIUgg3xsfEUrNNfkcwYPGsCNjEhxoLZ6cYQHFX451dAvTsPT6MlyxmAFDFSZ35xv/1IgP/G0mvea5aczIT3scl2riEiyq/59URMACd6r7mPA1AElxiwv/5zKMUVFOtOUh3p7jOUH5uIZXfdoMdK2FM8rcSsJVOtZk=
    -- END ENCRYPTED TEXT -->
    

    Après chiffrage d'une note, il y a un sous-menu Edit encrypted note qui demande le mot de passe, puis permet d'éditer la note chiffrée, sans avoir à la déchiffrer au préalable, la note modifiée restant chiffrée.

    Zelbinium: Your Devices, Your Rules!

  • # Dernier jour !

    Posté par  (site web personnel) . En réponse à la dépêche Les RMLL 2018 Strasbourg arrivent à grand pas !. Évalué à 2.

    Demain (mercredi 11 juillet) est le dernier jour des RMLL 2018, qui ont lieu à Strasbourg. Donc, si vous êtes dans le coin, c'est l'occasion ou jamais d'y assister.

    Accessoirement, c'est également ce jour que j'y donnerais 3 conférences (mes premières !) sur le toolkit Atlas (http://atlastk.org/), à propos duquel j'ai publié cet article : https://linuxfr.org/users/epeios/journaux/atlas-toolkit-sur-la-route-du-libre.
    Si cela vous intéresse, n'hésitez pas : https://2018.rmll.info/users/114 ; je serais enchanté de vous y accueillir !

    Zelbinium: Your Devices, Your Rules!

  • [^] # Re: Mon expérience à deux balles

    Posté par  (site web personnel) . En réponse au journal Un petit tour des systèmes de build. Évalué à 2.

    Ce qui manque à JSon, et à Yaml aussi, qui fait que je leur préfère XML pour les fichiers de configuration, ce sont les espaces de noms

    Zelbinium: Your Devices, Your Rules!