De ce que j'ai pu constater, on a, d'une part, les webmails, auxquels on peut accéder d'à peu prés n'importe quel dispositif connecté à Internet, mais qui ne sont, en gros, que des frontendsIMAP, d'où le fait que l'on ne peut gérer qu'un seul compte mail à la fois, et, d'autre part, les clients natifs, qui peuvent proposer des fonctionnalités plus évoluées que celles disponibles avec IMAP, comme la gestion simultanée de plusieurs comptes en même temps, mais qui ne sont accessibles que d'une seule machine.
Ce que je cherche à obtenir, c'est le meilleur des deux mondes, c'est-à-dire pouvoir accéder à mon MUA d'un maximum de dispositifs connectés, et pouvoir cependant toujours disposer de toute les fonctionnalités de mon MUA, qui iront au-delà de celles disponibles IMAP.
C'est pour cela que mon MUA, contrairement aux MUA classiques qui accèdent directement aux serveurs POP3/IMAP, se connecte à un daemon, et c'est ce daemon se connectera aux différents comptes POP3/IMAP. Et comme c'est également ce daemon qui implémentera toutes les fonctionnalités de mon MUA, ces fonctionnalités seront disponibles quels que soient les clients utilisés (desktop, web ou mobile).
Personnellement, le compte d'origine d'un mail m'importe peu, d'autant qu'il n'est pas rare que je change le compte d'affectation de mes alias. Faire passer ce lien entre courrier et compte au second plan est même l'un des objectifs de mon application. Mais la plupart des MUA sont, en quelque sorte, orientés comptes, donc, quelque part, je pense qu'il est préférable qu'un utilisateur qui utilisait ce genre de MUA puisse retrouver ce lien auquel il est habitué, bien que ce lien ne soit qu'accessoire au niveau de l'application.
Je viens d'installer Claws-Mail et, effectivement, contrairement à ce que je supputais dans le journal (et que j'entendais par « …indépendamment les uns des autres »), au moins avec ce logiciel, il est possible de déplacer un courrier d'un compte mail à un autre. Ceci dit, je ne pense pas que ce soit propre à ce logiciel ; cela doit être lié au protocole IMAP…
Néanmoins, dans Claws-Mail (à moins que j'ai loupé quelque chose dans ses options de configuration), chaque compte mail a sa propre arborescence, même si elles ne sont pas aussi imperméables que je le pensais. Or, je préfèrerais avoir une arborescence unique et commune à tous les comptes mail, même s'il doit rester possible de différencier les courriers en fonction du compte dont ils sont issus.
Pour ce qui est de l'écriture d'un nouveau courrier, je ne me suis pas encore penché sur la question, me concentrant pour l'instant sur la lecture de courriers (protocole IMAP et connexions chiffrées), mais je prend bonne note de la fonctionnalité décrite.
Après 4 LogitechM570 (dont deux suite à un remplacement sous garantie, à chaque fois accepté sans difficulté et rondement mené par Logitech), lassé par un problème récurrent de bouton gauche devenant inutilisable au bout d'à peu prés un an, j'ai actuellement un APTICO de SPEEDLINK. C'est un trackball sans fil à commande par pouce (à l'instar de Logitech, ils ne font pas (plus) de modèle filaire).
Cela fait moins d'un an que je le possède, donc je ne sais pas s'il tiendra plus longtemps que le M570, mais, malgré le fait qu'un des pieds en caoutchouc s'est barré (ce qui, personnellement, ne me dérange pas), et que le pointeur se bloque (bah oui, ça n'arrive pas qu'aux claviers) de temps en temps (il suffit alors d'actionner le bouton gauche et ça repart), il me convient.
Sinon, en filaire, mais je ne l'ai pas essayé, il existe le SANWA MA-TB39.
Je ne suis qu'un dilettante en la matière, donc je vais peut-être sortir une grosse connerie, mais je suis un jour tombé par hasard sur ça. Ça n'irait pas dans le sens de ce que tu décris ?
Ce n'est pas parce que c'est atypique que c'est imbitable
Imbitable n'était pas le bon mot, disons qu'elle n'est pas pour l'instant réutilisable par quelqu'un d'autre que toi : quel que soit le besoin, il sera moins coûteux de créer une nouvelle appli basée sur des technologies connues que d'investir dans la tienne.
interface web fonctionne avec tous les navigateurs web graphiques modernes
Je ne sais pas quels sont tes clients, mais pour les miens « moderne » signifie plutôt « moins de 3 ans » que « moins de 3 semaines ». Et une incompatibilité avec firefox et internet explorer pour windows < 10 est invendable.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations…
Tu as visiblement la chance d'avoir des clients qui ne s'intéressent pas à la technique et qui deviennent captifs puisque tu es le seul à pouvoir maintenir ton code, mais c'est de moins en moins la réalité du marché.
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché…
Du coup je ne comprends pas l'objectif de ton POC, parce que je n'ai aucun doute que ça va fonctionner et que tu vas pouvoir l'utiliser pour tes clients, mais pourquoi le rends-tu public ?
- tu as déjà expliqué dans les commentaires des journaux précédents que tu ne visais pas un usage pour les projets communautaires
- maintenant tu sembles indiquer que même pour des projets de commande tu t'adresses à un marché très restreint
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire…
Je pense que tu as raison de continuer, visiblement ça peut te permettre d'avoir un avantage concurrentiel dans ton marché, mais je ne comprends pas quel est ton but en communiquant à ce sujet dans des journaux sur linuxfr.org.
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet…
Avant je ne comprenais pas tes technologies, mais au moins tu affichais un objectif clair : avant tout répondre aux besoins de tes clients, même si c'est au prix d'une solution imbitable.
Ce n'est pas parce que c'est atypique que c'est imbitable. Et si tu m'indiquais précisément ce qui te semble imbitable, je me ferais un plaisir de te fournir les explications pour te le rendre bitable. Et ça me donnerais de précieuses indications sur ce que je dois mettre dans la documentation que je suis en train de rédiger.
Aujourd'hui on apprend que ça ne permet de générer que des interfaces web incompatibles avec la plupart des navigateurs, ce qui serait rédhibitoire pour n'importe quel client. Maintenant je ne comprends ni tes technologies, ni tes objectifs…
Je me suis peut-être mal exprimé, mais, au contraire, depuis la mise à jour de Microsoft Edge, l'interface web fonctionne avec tous les navigateurs web graphiques modernes que j'ai pu essayer. Avec la démonstration en ligne, il y a moyen de s'en rendre compte par soi-même. Il y a juste Firefox qui pose problème dans certains cas, comme je l'ai expliqué…
Oui, le code est imbittable, parce que ça n'est pas vraiment du C++, c'est plein de macros qui définissent un nouveau dialecte, et quand on mit le code, ça ne respecte pas la grammaire du langage.
Quelles macros ? Les seules que je tape régulièrement, ce sont qRH, qRB, qRR…, et leurs consœurs qRFwk(), qRGnr()…; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.
Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages…
Ceci dit, non, ça n'est pas non plus un pur troll, puisque l'auteur du journal semble comprendre sa technologie et même arriver à en vivre. D'ailleurs, dans le journal précédent, certaines discussions techniques semblaient confirmer que plusieurs personnes comprenaient le principe.
Pour moi, c'est de l'informatique abstraite: tu as des trucs qui font des surcouches à une autre techno qui modifie du code dans un autre langage qui va te générer du HTML qu'il va falloir lire avec un navigateur, tu as besoin d'un quadricœur avec 4Go de RAM rien que pour un "Hello Word", mais soi-disant ça accélère le développement. Je ne comprend pas l'utilité d'une telle complexité, mais je dois être dépassé…
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
J'en suis parfaitement conscient. Ce n'est pas de la mauvaise volonté, c'est que je ne suis vraiment pas doué pour rédiger des documentations, ou pour communiquer sur mes projets de manière générale, comme le montre d'ailleurs les journaux que j'ai publiés, ainsi que le contenu de mon site Web.
Par ailleurs, ce genre d'application me permet d'améliorer le framework sur lequel il s'appuie, et que j'utilise, en tant que développeur freelance, pour les développements que je réalise pour mes clients. Donc, tout le travail de codage réalisé pour cette application me permet de proposer à mes clients du code de meilleur qualité et développé plus rapidement, ce qui est bénéfique, notamment financièrement, et pour moi, et pour le client. Par contre, tous les à-coté de ce genre de projet, comme la rédaction de documentation, sont, du point de vue financier, une pure perte de temps.
Ceci dit (ou plutôt écrit), cela ne m'empêche pas d'essayer de communiquer tant bien que mal sur mes projets, justement en publiant ce genre de journaux, dont certains commentaires contiennent d'intéressantes pistes d'améliorations. Ainsi, j'ai travaillé, suite au dernier journal, à l'amélioration du packaging de l'application, ce qui facilite son déploiement sous GNU/Linux et Windows (pour OS X, c'est loin d'être encore ça). J'ai prévu, en plus d'améliorer l'application, de mettre l'accent sur la documentation pour le prochain journal. Mais cela sera forcément très incomplet, vu l'ampleur de la tâche, mais il faut un début à tout.
J'ai oublié de préciser que l'on peut :
- modifier le contenu d'une fiche en cliquant sur l'entrée qui lui correspond dans la liste,
- modifier le contenu d'un champ en cliquant sur son libellé,
- modifier le contenu d'une entrée d'un champ multi en cliquant sur son contenu.
Accessoirement, on peut également afficher un A propos… avec Ctrl+Shift-A. Sur certains navigateurs, cela provoque l'affichage d'une nouvelle page ; il faut alors revenir sur la page de l'application. Je n'ai pas (encore) trouvé de combinaison de touches qui fonctionnent pour tous les navigateurs, ou (mieux) le moyen d'inhiber le comportement par défaut du navigateur…
Le document sur le site de Stroustrup visait simplement à établir, de manière indiscutable je crois, ce pour quoi les exceptions C++ ont été conçues. Maintenant, faut-il ou non les utiliser, c'est un autre débat.
Je veux bien croire que, dans certains domaines, comme ceux des jeux vidéos, de l'embarqué, du développement de drivers, etc. il y ai des contraintes qui poussent à éviter les exceptions, mais ce qui est vrai pour ces domaines-ci ne l'est pas forcément pour les autres, les contraintes n'étant pas les mêmes…
Quand au lien Google, ma compréhension de l'anglais est certainement perfectible, mais il me semble quand même qu'ils écrivent (traduction très libre) :
que les avantages des exceptions C++ l'emportent sur leurs inconvénients,
qu'ils n'utilisent pas les exceptions C++ pour leur nouveaux projets parce qu'ils ont beaucoup de code ne s'appuyant pas sur les exceptions et que :
mélanger code avec/code sans exceptions est problématiques,
réécrire le code sans exceptions pour le rendre tolérant aux exceptions est trop coûteux,
que s'ils recodaient tout from scratch, ils utiliseraient probablement les exceptions…
Donc, au final, ça m'a plutôt l'air d'un plaidoyer en faveur des exceptions C++…
En l'état, pas grand chose ; on peut créer des fiches avec des champs textes, et réorganiser les champs d'une fiche, ainsi que les entrées d'un champs, par drag & drop, et c'est à peu prés tout. Des fonctionnalités seront ajoutées petit à petit, et feront l'objet de publications ici même.
En attendant, cette application fait office de proof of concept. Elle permet d'étudier la faisabilité, entre autres :
- de coder entièrement et uniquement en C++ une interface basée sur des technos Web,
- d'utiliser un seul et même code (C++) pour l'interface Web et pour l'interface native d'une application,
- d'offrir la possibilité de modifier entièrement l'apparence d'une application sans avoir à intervenir sur son code source, uniquement en modifiant des fichiers XSL.
Je ne vois pas ce à quoi le terme dessus fait référence, et, quant au lien, je ne vois rien dans la biographie de l'auteur qui donne le moindre poids à ses écrits en général, et ces écrits en particulier. Par contre, j'ai trouvé ceci, dont B. Stroustrup lui-même est l'un des auteurs. Je pense que les deux premiers paragraphes de l'introduction sont on ne peut plus clairs quant à l'usage pour lesquels les exceptions C++ ont été conçues…
Donc, j'ai choisi la solution la plus facile et la plus rapide, à savoir de placer ces fichiers dans le dépôt.
La plus facile pour toi, et la plus rapide pour toi. Le problèmes que tu évoques est exactement celui résolu par les autotools ou autre framework du genre. Sans avoir à mettre des fichiers générées dans le VCS.
Le reste, ce n'est que l'adaptation aux particularités des différentes plateformes sur lequel il peut être lancé. Qu'est-ce qui sort donc de l'ordinaire, et par quoi peut-on le remplacer qui soit plus conforme aux standards en la matière ?
Tu pourrais simplement l'omettre si tu utilisais un des framework cités. Comme ça, queluqu'un d'autre que toi n'aurait pas à se former à ton outil. Tu trouveras ça inutile, mais c'est ce que je te disais plus haut : les solutions que nous t'évoquons sont utiles pour tout le monde, pas que pour toi.
J'ai l'impression que tu penses que mes Makefile sont plus sophistiqués qu'ils ne le sont réellement. Mes scripts de générations prennent en compte juste la nature du binaire à générer (exécutable ou bibliothèque) et la liste des fichiers sources. C'est tout. Pas de dépendances à gérer (il y a CEF maintenant, mais c'est une exception, et cela ne concerne qu'un seul Makefile). A nature de binaire identique, la seul chose qui change d'un Makefile à l'autre, c'est le tout début, qui contient la liste des fichiers source. Tout le reste est identique.
Si, d'aventure, j'avais effectivement fait le choix d'utiliser autotools et/ou consorts, au lieu de placer les Makefile générés dans le VCS, et bien j'y aurais placé les fichiers 'source' d'autotools et consorts, qui auraient également été générés, à l'instar des Makefile. Donc, cela n'aurait fait que déplacer le problème, si problème il y a, avec, en outre, une complexification induite par l'utilisation d'autotools et/ou consorts.
La principale différence avec XSL (mis à part que XPP n'est de loin pas aussi puissant que XSL), c'est que les directives XSL doivent être placées dans un fichier disjoint de celui qui contient le XML sur lequel on va appliquer ces directives, alors que les directives XPP, quant à elles, sont directement placées dans les fichiers XML sur lesquels elles portent.
Comme les feuilles de style « intégrées » (traduction pourrie de "embedded") ? https://www.w3.org/TR/xslt#section-Embedding-Stylesheets
Tu ne t'intéresses juste pas à ce qui existe, et c'est ce qui dérange un peu ici, je pense.
Je ne connaissais pas. J'ai un peu regardé, pas beaucoup, car il semble que ce ne soit implémenté que dans les navigateurs. Or, j'ai besoin, d'une part, de pouvoir utiliser ce mécanisme dans mes propres logiciels (pour l'appliquer sur les fichiers de configuration de mes logiciels), et, d'autre part, de pouvoir mettre ce mécanisme en œuvre via un utilitaire en ligne de commande. Mes deux utilitaires (sablotron et xsltprocess) ne semblent pas l'implémenter, et je n'ai pas trouvé d'utilitaire ou de bibliothèque qui implémente ce mécanisme. Donc, aujourd'hui, connaissant l'existence des embedded stylesheet, si j'étais confrontés aux même besoins que ceux qui m'ont poussés à développer XPP, je serais obligé de faire le même choix qu'à l'époque, à savoir développer ma propre solution.
Ceci dit, je n'ai jamais écrit que je ne m’intéressais pas aux solutions alternatives, mais que je n'utilisais pas ces solutions (forcément, puisque j’utilise mes alternatives), et c'est bien ce dernier point qui dérange. Comme déjà évoqué, si je ne m'étais pas intéressé à ce qui existe, je n’utiliserais pas XML, mais mon propre langage de balisage…
Utiliser gettext aurait impliqué un travail de codage supplémentaire, que j'économise avec le système que j'utilise.
Travail économisé une fois pour toi. Travail qui sera à fournir pour chaque personne qui souhaite s'intéresser à ce travail. C'est donc complètement inintéressant en terme de temps pour quiconque d'essayer de contribuer ou de s'intéresser à ton travail.
Je l'ai développée pour répondre aux besoins d'un client. Ce dernier devait pouvoir stocker des dates classiques, mais aussi approximatives.
Ah, intéressant, je n'avais pas vu cette fonctionnalité.
Ta réaction à bibliothèque DTE est typiquement celle que je ne comprends pas. Parce certains ne voient pas l'utilité de réimplémenter une telle bibliothèque, ces derniers décrètent que c'est une erreur, sans chercher à comprendre les motivations derrières.
Le problème c'est que je ne vais pas chercher des heures à comprendre ce que fait ta bibliothèque si j'ai l'impression qu'elle ne m'apporte rien. Pas de description, etc, je laisse tomber. Alors encore, si elle s'intégrait bien à l'existant, et que c'était utilisable en dehors de tout ton framework, pourquoi pas, mais je n'ai pas l'impression : tout semble très imbriqué, du coup je n'ai même pas espoir que cette fonctionnalité intéressante puisse être utilisée ailleurs. (déjà je fais du C, donc c'est niet)
Je comprends tout à fait que tu ne veuilles pas te plonger dans le code de cette bibliothèque (j'aurais la même réaction à ta place), mais alors, pourquoi ne pas me laisser le bénéfice du doute, c'est-à-dire de considérer que, peut-être, après tout, j'avais de bonnes raisons d'implémenter cette bibliothèque, au lieu de considérer d'office que c'était une erreur ?
on ne comprend pas, donc, au lieu d'approfondir, ou de demander des éclaircissement au développeur si l'on a pas envie de se plonger dans le code (ce que je comprends tout à fait), on se répand en généralités sans rapports pour discréditer le framework en question.
Essaye de penser que tu n'es pas au centre du monde : malheureusement, ton « standard » n'est pas le standard, et c'est en général plutôt à toi de t'adapter aux autres que l'inverse.
Et je ne dis pas ça pour t'embêter, mais juste pour que tu remettes les pieds sur terre et te rende compte que personne ne s'intéressera à ton travail si tu le présente et le développe ainsi. Ce n'est peut-être pas ce que tu cherches, mais tu disais vouloir au moins avoir des retours, et je t'explique pourquoi je pense que tu n'en auras pas.
Je ne comprend pas le rapport de ta réponse avec l'extrait de mon intervention que tu cites. Encore une fois, je n'ai jamais demandé à qui que ce soit de s’intéresser à mon framewok. Tu dis que j'ai demandé des retours ; je ne m'en souviens pas, et je ne vais pas relire l'ensemble des commentaires de ce journal, donc je vais supposer que c'est vrai, mais, ça serait, à priori, vu ce que j'avais à l'esprit en rédigeant ce journal, au sujet des particularités du logiciel, pas de la manière dont elles sont implémentées. Je pense qu'il est préférable d'avoir un bon logiciel, fût-il réalisé avec des solution non-standards, qu'un logiciel inutilisable, fût-il réalisé avec des solutions standards…
je n'aurais pas développé ce framework si je pouvais développer aussi vite et aussi bien avec d'autres outils.
Tu sais, tout programmeur a un jour pensé à faire ça. Puis on a appris le principe de « standard » : ça n'est pas toujours parfait, ça ne fait pas exactement ce qu'on veut, mais c'est ce qui permet de travailler en commun. Avec ta méthode, désolé mais tu travailleras toujours tout seul.
Peut-être pas, si c'est mes solutions qui deviennent les standards :-). Mais, je le concède, c'est mal parti, d'autant plus que ce n'est pas mon but à ce jour.
Et, en fait, le problème avec les standards, outre, qu'effectivement, cela ne permet pas toujours de réaliser ce que l'on veut, c'est surtout, et c'est bien plus grave, que cela ne permet pas toujours de réaliser ce que le client veut.
Quel est le problème de travailler seul ? Les clients ne se sont jamais plaints de mes délais (une fois qu'ils ont assimilé qu'on ne peut pas leur livrer le produit pour avant-hier), et j'ai toujours pu intégrer mes développements à l'environnement de production du client, quel qu'il soit.
De manière générale, les clients veulent un logiciel vite et bien fait. Que ce logiciel soit réalisé par une seule personne ou par plusieurs, (généralement, moins il y a de personnes impliquées, moins c'est cher, donc ils préfèrent), en utilisant ou non des solutions standards (je parle là des solutions de développement, pas des formats de fichiers), généralement peu leur chaut.
Bon courage quand même dans ta voie
Merci !
Développer un logiciel n'est pas trivial. Pour cette raison, la majorité des développeurs utilise les solutions qu'ils considèrent (à tord ou à raison) les plus faciles à utiliser. Pour beaucoup, apparemment, notamment au vu des commentaires ici, il s'agit des solutions 'standards'. Bien que, moi aussi, j'utilise certaines solutions standards (XML est peut-être décrié, mais c'est néanmoins un standard ; ce n'est pas une de mes inventions), il se trouve que j'ai été amené à développer mes propres solutions parce que celles existantes ne me convenaient pas. Comme toi et certains des intervenants ici n'ont pas manqués de le souligner, c'est une démarche rare. Cependant, elle n'est pas unique. Et heureusement, sinon l'écosystème informatique serait bien pauvre. Toutes les solutions considérées comme 'standards' aujourd'hui ne l'ont pas été à leurs débuts, et se sont certainement vu opposer les 'standards' de l'époque. Heureusement, cela n'a pas découragé les concepteurs de ces solutions, sinon elles ne seraient pas considérées comme les 'standards' d'aujourd'hui…
Contrairement à ce que certains pensent ici, et je me demande bien sur quel base, je n'essaie pas de promouvoir mon framewok. Je ne fais que présenter quelques logiciels que je développe, à l'instar de celui présenté dans ce journal, qui ont comme particularité d'être tous basés sur mon framework (c'est simplement un fait technique), ce qui fait qu'ils ont certains points communs (manière de gérer les traductions, les arguments de la ligne de commande, possibilité de placer des directives XPP dans les fichiers de configuration…) qui les distinguent des autres logiciels. Mon but premier est de produire des logiciels qui satisfassent ses utilisateur (et, parmi ces utilisateurs, le plus exigeant de tous : moi) , et mon framework est un outil essentiel pour parvenir à ce but. Si, parmi ces utilisateurs, il y a des développeurs qui estiment que certaines particularités de ces logiciels, et donc, par conséquent, du framework sur lequel ils sont basés, sont suffisamment intéressantes pour contrebalancer le fait qu'il ne s’appuie pas sur des solutions 'standards', alors peut-être que, de concert, on pourra mettre en place les éléments qui lui permettront de gagner en popularité. Ou pas.
De ce que je sais, les exceptions ont été conçues pour faciliter la gestion des erreurs, quelles qu'elles soient. Je ne vois pas en quoi la nature de l'erreur change quoi que ce soit, d'autant plus lorsqu'elle est basée sur ces notions d'attendu/inattendu, pour autant qu'il y ai une définition précise et univoque des ces notions. En outre, la nature d'une même erreur peut varier selon le contexte. Reprenons l'exemple ci-dessus, en supposant que l'interface soit une interface Web. On peut envisager que, lors de la validation du formulaire, avant son envoi, un script JS soit exécuté pour vérifier si le champ est bien rempli, et n'envoyer le formulaire qu'à cette condition, ou, sinon, signaler à l'utilisateur qu'il lui faut remplir ce champ. Au niveau du code C++, le contenu du champ ne peut, théoriquement, jamais être vide, mais c'est une bonne pratique que de le vérifier tout de même, on ne sait jamais. Du coup, si cette erreur se produit tout de même (il peut y avoir un bug dans le code JS), erreur attendue ou inattendue ?
Ça, ça ne va pas changer, je déteste les exceptions en C++. Et je ne vois pas bien où je pourrais en mettre.
J'ai un jour dû écrire un logiciel en C de haute disponibilité, qui devait tourner 24h/24, 7j/7, sur un PC industriel équipé d'un watchdog, histoire qu'il reboot automatiquement si mon logiciel devait planter. Du coup, la plupart de mes fonctions comportaient pléthore de if dont l'unique objet était de remonter à la fonction appelante les erreurs détectées dans les fonctions appelées. Je trouvais que cela rendait le programme presque illisible, car il était difficile de distinguer parmi tous ces if lesquels étaient 'algorithmiques', et lesquels étaient dédiés à la gestion d'erreurs.
Pour améliorer cela, j'ai implémenté en C, en m'appuyant sur la bibliothèque setjmp, un mécanisme, sous forme d'un jeu de macros, dont je me suis rendu compte plus tard qu'il s'apparentait aux exceptions C++, que je ne connaissais pas à l'époque. D'ailleurs, quand je suis passé au C++, j'ai réimplémenté ces mêmes macros en m'appuyant sur les exceptions, au lieu de la bibliothèque setjmp. J'utilise toujours ces macros pour la gestion des erreurs, et, bien que, par défaut, elles s'appuient sur les exceptions C++, on peut, à l'aide d'une option de compilation, basculer sur la bibliothèque setjmp, pour une utilisation dans un environnement où les exceptions ne seraient pas disponibles.
Quand ma production consistait essentiellement en utilitaires en ligne de commande, l'exception était interceptée grosso-modo dans le main pour afficher un message d'erreur. Par contre, depuis que j'écris des daemon, l'exception est interceptée à la fonction racine du thread dans lequel elle est lancée, pour afficher un message d'erreur dans un log, voire relayer ce message au client, avant de terminer le thread en question. Mais le thread principal continue toujours de tourner, ainsi que les autres threads, prêts à répondre aux requêtes des différents clients.
Pour les interfaces graphiques, l'exception est interceptée dans la boucle de gestion des événements. Par exemple, si l'utilisateur valide un formulaire en oubliant de remplir un champ obligatoire, une exception est lancée qui remonte jusqu'à cette boucle, affiche un message signalant la nécessité de remplir le champs oublié, et ensuite laisse tout loisir à l'utilisateur de remplir le champ en question, comme s'il ne s'était rien passé.
En ce qui me concerne, les exceptions (ou la setjmp en C) facilitent grandement le développement de logiciels…
J'ai présenté un logiciel dont j'ai commencé le développement, en mettant en exergue quelques caractéristiques. Pour ceux que cela intéresse et qui voudrait en savoir plus, je répondrais volontiers à leurs questions. Quant à ceux qui prétendent qu'il y a des outils plus adaptés que ceux que j'utilise pour coder ce genre de logiciel, je veux bien en débattre, mais il faudrait qu'il y déjà ai matière à, c'est-à-dire des éléments concrets et pas seulement des généralités ; je ne vais pas passer en revue toutes les solutions qui existent dans le domaine pour tenter de deviner ce à quoi ils font référence…
C'est tout ce qu'il y a à comprendre dans ce journal et mes commentaires. Pour ceux qui ont compris autre chose, j'en suis désolé pour eux, mais je n'y peux rien…
Donc, non, je ne veux pas que l'on me pose des questions techniques ; je signifie seulement que, pour qu'il y ai débat sur la pertinence de mon code, cela ne peut se faire sans éléments techniques. Et les commentaires dans le code, c'est généralement pour en faciliter la compréhension, et certainement pas pour y placer un argumentaire pour tenter de convaincre de la supériorité technique dudit par rapport à d'autres solutions (ceci dit, tu y mets ce que tu veux, dans les commentaires de ton code…). Au sujet de la dépréciation de mon code, je ne faisais que reformuler la notion de discrédit évoqué dans un précédent commentaire, qui n'était même pas une réponse à l'un de tiens ; il ne faut pas tout prendre personnellement. Et tu ne m'apprend rien en écrivant que je promeus mal mon code ; j'ai moi-même écrit ici, et à plusieurs reprises, que je ne sais pas communiquer sur mes projets. Et je ne vois pas où j'ai pu ne fût-ce que suggérer que je désirais que les gens investissent quoi que ce soit sur mon code. Et enfin, si je réponds des banalités, c'est uniquement aux questions auxquelles on ne peut faire que ce genre de réponses…
Il y a une contradiction dans tes propos de manière générale ; d'un côté tu expliques que tu ne pourrais pas être plus efficace avec les autres outils, et de l'autre tu avoues ne pas avoir beaucoup regardé ce qui se fait ailleurs.
Si, j'ai bien regardé ce qui se faisait ailleurs, mais, comme cela ne répondait pas à mes besoins, je n'ai pas utilisé.
Dans la mesure où il existe des tas de frameworks libres de qualité, éprouvés par des milliers de codeurs/applications depuis des années, qui eux aussi se vantent de permettre de faire des applications de qualités rapidement etc…, tu peux comprendre qu'aller se plonger dans ton code pour y trouver d'hypothétiques qualités parce que tu ne peux pas expliquer ce que ton framework apporte par rapport à la concurrence est plutôt rebutant.
Comme je l'ai indiqué dans le pénultième paragraphe de mon précédent commentaire, je comprends parfaitement que l'on ne veuille pas se plonger dans le code de mon framework. Mais alors, pourquoi affirmer que ce framework est globalement nettement moins bon que les autres (bon, il y a des aspect où il est clairement moins bon, notamment en ce qui concerne la documentation) ? Mon framework, j'en ai commencé le codage il y a plus de 15 ans. J'ai regardé tout au long de ces années ce qui se faisait chez la 'concurrence', mais j'ai à chaque fois découvert au moins un aspect rédhibitoire, dont je ne me rappelle plus à ce jour, qui fait qu'au final j'ai continué à utiliser mon framework. Et donc, je ne peux rien dire concernant les autres framework car, contrairement à certains ici, je ne parle d'un sujet que si je le connais suffisamment.
Par exemple tu aurais pu en profiter pour expliquer quelles bibliothèques de dates tu as essayées et en quoi la tienne est meilleure.
Çà fait trop longtemps que je l'ai codée pour me rappeler précisément tout ce qui a entouré sa genèse. Mais, au lieu de la déprécier, pourquoi ne pas avoir écrit "Moi, j'utiliserais telle bibliothèque, qui fait ça, ça et ça ; pourquoi ne pas l'avoir utilisée ?", auquel cas je pourrais répondre, par exemple, que je ne la connaissais pas, qu'elle n'existait pas à l'époque, ou bien encore qu'il lui manque telle ou telle fonctionnalité. Bref, on pourrait enfin avoir un véritable débat…
On me reproche des abstractions soit-disant inutiles dans mon framework, mais les commentaires eux-mêmes ne portent essentiellement que sur des abstractions ; c'est difficile d'argumenter dans ces cas là. Il y a néanmoins quelques points concrets qui sont évoqués auxquels je vais tenter de répondre.
Les noms abscons. Je m'en suis justifié plus haut. Et surtout, je ne pense pas que le problème vienne des noms en soi, mais plutôt de l'absence de documentation au sujet des binaires concernés. Je n'aime pas rédiger de la documentation, car je suis très mauvais en cela. Mais j'essaie quand même d'en écrire, tant bien que mal, comme en témoigne le contenu de mon Wiki.
Les fichiers générés contenus dans le VCS ; je pense que tu entends par là le contenu du dépôt mercurial. Les seuls fichiers générés qu'il contient sont les Makefile, et les .h contenant les APIs des backends. Ces fichiers sont générés à l'aide de scripts stockés sur ma machine de développement principale, celle avec laquelle je travaille la plupart du temps. Si je ne mettais pas ces fichiers dans le dépôt, je serais obligé de les régénérer sur chacune des mes autres machines de travail, et donc d'installer ces scripts et leur environnement d'exécution sur ces machines, ce qui est loin d'être évident vu la diversité des machines (il y a là des machines sous Windows, Linux, MacOS, Android et même Maemo…). Donc, j'ai choisi la solution la plus facile et la plus rapide, à savoir de placer ces fichiers dans le dépôt. Il y a aussi un .xml correspondant à l'API d'un backend. A vrai dire, celui-ci n'y a été mis que récemment, à l'occasion de la rédaction de ce journal ; en temps normal, je ne place pas ces fichiers dans le dépôt.
Pour le contenu des Makefile, je ne vois pas le problème, mais je n'y connais à vrai dire pas grand chose sur le sujet. Le cœur du Makefile, qui se situe à la fin du fichier, est tout ce qu'il y a de plus classique (règle de construction du binaire à partir des fichiers objets, règle de construction des fichiers objets à partir des fichiers sources). Le reste, ce n'est que l'adaptation aux particularités des différentes plateformes sur lequel il peut être lancé. Qu'est-ce qui sort donc de l'ordinaire, et par quoi peut-on le remplacer qui soit plus conforme aux standards en la matière ?
xppq. La principale différence avec XSL (mis à part que XPP n'est de loin pas aussi puissant que XSL), c'est que les directives XSL doivent être placées dans un fichier disjoint de celui qui contient le XML sur lequel on va appliquer ces directives, alors que les directives XPP, quant à elles, sont directement placées dans les fichiers XML sur lesquels elles portent. Le principe derrière XPP est le même que celui du préprocesseur C. XSL n'a pas du tout la même approche. A noter que j'utilisais XSL bien avant d'avoir écrit xppq ; je l'ai donc écrit car il répondait à un besoin auquel XSL ne pouvait répondre.
Pour les traductions, je n'utilise pas gettext, car je réutilise le même mécanisme que pour mes fichiers de configuration. Utiliser gettext aurait impliqué un travail de codage supplémentaire, que j'économise avec le système que j'utilise.
Les dates. Je pense que tu te réfères à la bibliothèque DTE. Je l'ai développée pour répondre aux besoins d'un client. Ce dernier devait pouvoir stocker des dates classiques, mais aussi approximatives. Il y a, en effet, certains personnages dont on ne connaît pas avec précision les dates de naissances et/ou de décès. Avec cette bibliothèque, on peut stocker des dates au jour prés, mais aussi seulement au mois, à l'année, à la décennie… prés. Comme le surcoût de cette bibliothèque est négligeable par rapport à celle d'une bibliothèque de gestion de dates classique, j'en ai fait ma bibliothèque standard.
Ta réaction à bibliothèque DTE est typiquement celle que je ne comprends pas. Parce certains ne voient pas l'utilité de réimplémenter une telle bibliothèque, ces derniers décrètent que c'est une erreur, sans chercher à comprendre les motivations derrières. Et c'est cette même approche de mon framework en général que l'on retrouve dans les commentaires ; on ne comprend pas, donc, au lieu d'approfondir, ou de demander des éclaircissement au développeur si l'on a pas envie de se plonger dans le code (ce que je comprends tout à fait), on se répand en généralités sans rapports pour discréditer le framework en question.
Quand à ma soi-disant méta-blague, ce n'en est pas une, méta ou non. C'est la réelle motivation qu'il y a derrière mon framework. Je suis un développeur professionnel, et je n'aurais pas développé ce framework si je pouvais développer aussi vite et aussi bien avec d'autres outils. Ceci dit, je suis tout-à-fait prêt à envisager que je me suis fourvoyé, mais, de grâce, appuyez vos écrits avec des exemples concrets ; il s'agit de Logiciel Libre après tout, et les sources sont facilement accessibles (même pas besoin de les télécharger !).
Je parle d'une hostilité envers mes technos, pas envers moi. Je ne me sens victime d'aucune cabale. Je constate simplement qu'à chaque fois que j'évoque certaines technos, comme XML/XSL(T), ou que j'associe technos Web et C++, on assiste systématiquement à une levée de bouclier, sans que jamais l'on avance le moindre argument valable justifiant cette aversion.
Et effectivement, j'emploie XML/XSL(T) depuis longtemps, bien plus longtemps que ne le suggère les journaux que j'ai publié. J'ai commencé à utiliser XML/XSL(T) en conjonction avec XUL(Runner), ce qui remonte grosso-modo à 2004. A l'époque déjà, et régulièrement depuis, j'ai étudié les alternatives, sans qu'aucune ne s'est révélée à la hauteur de mes attentes (et ceux de certains de mes clients) en comparaison avec XML/XSL(T).
Concernant la tonne de code, c'est l'ensemble de mon framework, dont les technos présentées ici ne représentent qu'une faible partie. Ce framework couvre un large éventail de fonctionnalités, d'où sa taille.
Pour ton exercice, une seule phrase suffit : me faciliter le développement de logiciels de qualité.
Comme je l'ai déjà écrit dans une de mes précédentes réponses, je suis conscient que j'ai de sérieuses lacunes en matière de communication, mais, encore une fois, pour susciter l'intérêt sur un sujet, communiquer mal est toujours mieux que de ne pas communiquer du tout. Et si le logiciel et si mal accueilli, c'est aussi parce qu'il est difficile à déployer avec les package fournis. Comme je l'ai écrit dans une autre réponse, c'est à cause de CEF, sur lequel s'appuie mon logiciel pour l'interface native. Mais je travaille à l'amélioration du packaging.
Je ne veux pas attirer du monde sur mes technos ; je la présente simplement au cas où cela intéresserait des personnes, auquel cas j'échangerais volontiers sur le sujet avec ces dernières. Et pour celles qui trouvent ces technos inadaptées, il n'y a pas de problèmes non plus, je discuterais tout aussi volontiers avec ces dernières de l'intérêt de mes technos.
[^] # Re: Trojita
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 1.
De ce que j'ai pu constater, on a, d'une part, les webmails, auxquels on peut accéder d'à peu prés n'importe quel dispositif connecté à Internet, mais qui ne sont, en gros, que des frontends IMAP, d'où le fait que l'on ne peut gérer qu'un seul compte mail à la fois, et, d'autre part, les clients natifs, qui peuvent proposer des fonctionnalités plus évoluées que celles disponibles avec IMAP, comme la gestion simultanée de plusieurs comptes en même temps, mais qui ne sont accessibles que d'une seule machine.
Ce que je cherche à obtenir, c'est le meilleur des deux mondes, c'est-à-dire pouvoir accéder à mon MUA d'un maximum de dispositifs connectés, et pouvoir cependant toujours disposer de toute les fonctionnalités de mon MUA, qui iront au-delà de celles disponibles IMAP.
C'est pour cela que mon MUA, contrairement aux MUA classiques qui accèdent directement aux serveurs POP3/IMAP, se connecte à un daemon, et c'est ce daemon se connectera aux différents comptes POP3/IMAP. Et comme c'est également ce daemon qui implémentera toutes les fonctionnalités de mon MUA, ces fonctionnalités seront disponibles quels que soient les clients utilisés (desktop, web ou mobile).
Zelbinium, la programmation ludique
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 1.
Personnellement, le compte d'origine d'un mail m'importe peu, d'autant qu'il n'est pas rare que je change le compte d'affectation de mes alias. Faire passer ce lien entre courrier et compte au second plan est même l'un des objectifs de mon application. Mais la plupart des MUA sont, en quelque sorte, orientés comptes, donc, quelque part, je pense qu'il est préférable qu'un utilisateur qui utilisait ce genre de MUA puisse retrouver ce lien auquel il est habitué, bien que ce lien ne soit qu'accessoire au niveau de l'application.
Zelbinium, la programmation ludique
[^] # Re: Si, ça existe.
Posté par Claude SIMON (site web personnel) . En réponse au journal Epeios Meta Mail User Agent : première publication.. Évalué à 2.
Je viens d'installer Claws-Mail et, effectivement, contrairement à ce que je supputais dans le journal (et que j'entendais par « …indépendamment les uns des autres »), au moins avec ce logiciel, il est possible de déplacer un courrier d'un compte mail à un autre. Ceci dit, je ne pense pas que ce soit propre à ce logiciel ; cela doit être lié au protocole IMAP…
Néanmoins, dans Claws-Mail (à moins que j'ai loupé quelque chose dans ses options de configuration), chaque compte mail a sa propre arborescence, même si elles ne sont pas aussi imperméables que je le pensais. Or, je préfèrerais avoir une arborescence unique et commune à tous les comptes mail, même s'il doit rester possible de différencier les courriers en fonction du compte dont ils sont issus.
Pour ce qui est de l'écriture d'un nouveau courrier, je ne me suis pas encore penché sur la question, me concentrant pour l'instant sur la lecture de courriers (protocole IMAP et connexions chiffrées), mais je prend bonne note de la fonctionnalité décrite.
Zelbinium, la programmation ludique
# Alternative sans et avec fil
Posté par Claude SIMON (site web personnel) . En réponse au journal Quel Périphérique de pointage ?. Évalué à 1.
Après 4 Logitech M570 (dont deux suite à un remplacement sous garantie, à chaque fois accepté sans difficulté et rondement mené par Logitech), lassé par un problème récurrent de bouton gauche devenant inutilisable au bout d'à peu prés un an, j'ai actuellement un APTICO de SPEEDLINK. C'est un trackball sans fil à commande par pouce (à l'instar de Logitech, ils ne font pas (plus) de modèle filaire).
Cela fait moins d'un an que je le possède, donc je ne sais pas s'il tiendra plus longtemps que le M570, mais, malgré le fait qu'un des pieds en caoutchouc s'est barré (ce qui, personnellement, ne me dérange pas), et que le pointeur se bloque (bah oui, ça n'arrive pas qu'aux claviers) de temps en temps (il suffit alors d'actionner le bouton gauche et ça repart), il me convient.
Sinon, en filaire, mais je ne l'ai pas essayé, il existe le SANWA MA-TB39.
Zelbinium, la programmation ludique
[^] # Re: HP !
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Création d'un multiroom audio à base de raspberry / hifiberry / max2play. Évalué à 1.
Je ne suis qu'un dilettante en la matière, donc je vais peut-être sortir une grosse connerie, mais je suis un jour tombé par hasard sur ça. Ça n'irait pas dans le sens de ce que tu décris ?
Zelbinium, la programmation ludique
[^] # Re: chromium, but not only
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 3.
Je n'ai jamais développé d'application web pour mes clients, et je n'ai pas l'intention d'en développer. L'interface de l’application présentée ici montre clairement que je n'ai pas les compétences en HTML, CSS et consorts pour cela (c'est pour cela que la facilité de modification de l'interface est un point clef de la technologie que j'emploie). D'ailleurs, si un prospect me contacte pour me demander de développer une application web, je lui dit sans équivoque qu'il lui sera facile de trouver développeur bien plus compétent et concurrentiel que moi pour cela.
Le fait est que les interfaces desktop que je développe s'appuient sur des technos web, pour les raisons expliquées dans ce journal. Du fait de l'utilisation de ces technos web, il me semblait juste logique que le même code puisse servir pour développer une version web de l'interface. Et c'est cette hypothèse qui fait l'objet d'une des POC présentés ici. L'interface web, c'est juste un bonus ; cela ne fait pas officiellement partie de mes prestations…
Au contraire, c'est parce que mes clients s'intéressent à la technique qu'ils me contactent. Ils sont bien conscients que c'est parce que les développeurs classiques n'ont pas la maîtrise des technologies qu'ils utilisent qu'ils ne sont pas capables de leur fournir une application qui réponde à leurs besoins. Avec mon framework, parce que j'en ai la totale maîtrise, je ne suis pas soumis au bon vouloir d'un éditeur pour en dépasser les limites.
Il vaut mieux une application développée dans une technologie soi-disant captive (mon framework, c'est quand même que du C++), mais qui réponde parfaitement aux besoins du client, qu'une application certes basée sur des technologies répandues, mais inutilisable à cause des limitations de ces technologies. Des clients dont les exigences sont telles que les technologies classiques ne peuvent y répondre sont peu nombreux, mais, d'un autre coté, comme on est peu de développeurs sur ce marché…
Je n'ai pas trop compris ce que tu entends par viser un usage pour les projets communautaires.
Concernant mon framework, du fait qu'il soit atypique et que la documentation est inexistante, il y a peu de chances que quelqu'un s'y intéresse ; je ne communique donc pas directement dessus. Par contre, une application telle que celle présentée ici, naturellement pas en l'état, est plus à même de susciter l'intérêt, voire de fédérer une communauté. Certes, il reste bien du travail pour que cette application soit utilisable, et c'est pour cela que j'insiste plus sur l'aspect POC que sur ses fonctionnalités. Mais, à terme, peut-être deviendra-t-elle un projet communautaire ? En tout cas, je n'y aurais rien à y redire…
Suite à ces journaux, j'observe quand même quelques téléchargements de mes logiciels. Sans préjuger de l'intention des téléchargeurs, on peut quand même supposer que mes logiciels, et donc leur évolution, les intéressent, d'où ces journaux pour communiquer à leur sujet…
Zelbinium, la programmation ludique
[^] # chromium, but not only
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 3. Dernière modification le 06 août 2016 à 09:08.
Ce n'est pas parce que c'est atypique que c'est imbitable. Et si tu m'indiquais précisément ce qui te semble imbitable, je me ferais un plaisir de te fournir les explications pour te le rendre bitable. Et ça me donnerais de précieuses indications sur ce que je dois mettre dans la documentation que je suis en train de rédiger.
Je me suis peut-être mal exprimé, mais, au contraire, depuis la mise à jour de Microsoft Edge, l'interface web fonctionne avec tous les navigateurs web graphiques modernes que j'ai pu essayer. Avec la démonstration en ligne, il y a moyen de s'en rendre compte par soi-même. Il y a juste Firefox qui pose problème dans certains cas, comme je l'ai expliqué…
Zelbinium, la programmation ludique
[^] # Re: Erreur lien 'technologie XDHTML'.
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 1.
C'est plutôt à moi de dire (enfin d'écrire) merci :-) !
Zelbinium, la programmation ludique
# Erreur lien 'technologie XDHTML'.
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 4.
Malgré mes multiples relectures, j'ai laissé passé une erreur sur le pénultième lien, celui sur la technologie XDHTML. Voici le lien correct.
Zelbinium, la programmation ludique
[^] # Re: xdhbrwq/xdhbrwq XDHTML/orgnzqxdh
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 4. Dernière modification le 26 juillet 2016 à 10:17.
Quelles macros ? Les seules que je tape régulièrement, ce sont
qRH, qRB, qRR…, et leurs consœursqRFwk(), qRGnr()…; qui sont dédiées à la gestion d'erreurs ; algorithmiquement, elles ne sont pas significatives, et elles ne sont pas nécessaires à la compréhension du code, sauf quand celui-ci s'occupe de la gestion des erreurs, évidemment. Quant aux autres macros, elles existent juste pour m'éviter d'avoir à taper du code dont j'ai fréquemment besoin, mais elles ne constituent certainement pas un nouveau dialecte.Si l'on m'indique quelles macros posent problème, je détaillerais volontiers leurs usages…
Ce n'est de loin pas de l'informatique abstraite : la preuve, il y a une démonstration accessible en ligne qui montre que c'est au contraire tout à fait concret. Quand à cette histoire de surcouche avec HTML, je n'ai pas trop compris. Cela concerne peut-être ce que j'ai décris dans ce journal.
Pour ce qui est d'avoir besoin d'un quadricœur avec 4GO de RAM, il y a un package disponible avec les binaires Windows destinés à du XP SP3 et supérieur, et un autre pour du GNU/Linux compatible IA-32 ou AMD64 natif. Ces packages sont relativement simple à déployer (mais je concède que c'est améliorable), et je suis preneur de tout retour sur leur mise en œuvre.
Soit dit en passant, comme je l'ai signalé, la CGI et le backend tournent sans problèmes sur une brique internet, à savoir une architecture ARM 32 bits dual-core à 1 GHz avec 512 Mo de RAM. Pour ceux qui disposent d'un matériel similaire tournant sous GNU/Linux, ils peuvent le vérifier ; je décris la procédure dans le journal. Et enfin, il y a la démonstration en ligne ; là aussi, je suis preneur de tout retour sur les ressources nécessaires et les éventuels problèmes rencontrés en fonction du navigateur utilisé.
Zelbinium, la programmation ludique
[^] # Re: Documentation
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 2.
J'en suis parfaitement conscient. Ce n'est pas de la mauvaise volonté, c'est que je ne suis vraiment pas doué pour rédiger des documentations, ou pour communiquer sur mes projets de manière générale, comme le montre d'ailleurs les journaux que j'ai publiés, ainsi que le contenu de mon site Web.
Par ailleurs, ce genre d'application me permet d'améliorer le framework sur lequel il s'appuie, et que j'utilise, en tant que développeur freelance, pour les développements que je réalise pour mes clients. Donc, tout le travail de codage réalisé pour cette application me permet de proposer à mes clients du code de meilleur qualité et développé plus rapidement, ce qui est bénéfique, notamment financièrement, et pour moi, et pour le client. Par contre, tous les à-coté de ce genre de projet, comme la rédaction de documentation, sont, du point de vue financier, une pure perte de temps.
Ceci dit (ou plutôt écrit), cela ne m'empêche pas d'essayer de communiquer tant bien que mal sur mes projets, justement en publiant ce genre de journaux, dont certains commentaires contiennent d'intéressantes pistes d'améliorations. Ainsi, j'ai travaillé, suite au dernier journal, à l'amélioration du packaging de l'application, ce qui facilite son déploiement sous GNU/Linux et Windows (pour OS X, c'est loin d'être encore ça). J'ai prévu, en plus d'améliorer l'application, de mettre l'accent sur la documentation pour le prochain journal. Mais cela sera forcément très incomplet, vu l'ampleur de la tâche, mais il faut un début à tout.
Zelbinium, la programmation ludique
[^] # Re: c'est bien gentil
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 1.
J'ai oublié de préciser que l'on peut :
- modifier le contenu d'une fiche en cliquant sur l'entrée qui lui correspond dans la liste,
- modifier le contenu d'un champ en cliquant sur son libellé,
- modifier le contenu d'une entrée d'un champ multi en cliquant sur son contenu.
Accessoirement, on peut également afficher un A propos… avec
Ctrl+Shift-A. Sur certains navigateurs, cela provoque l'affichage d'une nouvelle page ; il faut alors revenir sur la page de l'application. Je n'ai pas (encore) trouvé de combinaison de touches qui fonctionnent pour tous les navigateurs, ou (mieux) le moyen d'inhiber le comportement par défaut du navigateur…Zelbinium, la programmation ludique
[^] # Re: bug...
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 2.
Bon, j'ai finalement profité d'une baisse momentanée d'activité sur le serveur pour rapidement mettre la version corrigée en place…
Zelbinium, la programmation ludique
[^] # Re: bug...
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 2.
Merci pour le signalement.
Le bug est corrigé, mais il faudra attendre le déploiement de la prochaine version de l'application pour profiter de la correction.
Quand à l'option de déconnexion, elle est absente parce que je ne me suis pas encore pris le temps de l'implémenter…
Zelbinium, la programmation ludique
[^] # Re: De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 2.
Le document sur le site de Stroustrup visait simplement à établir, de manière indiscutable je crois, ce pour quoi les exceptions C++ ont été conçues. Maintenant, faut-il ou non les utiliser, c'est un autre débat.
Je veux bien croire que, dans certains domaines, comme ceux des jeux vidéos, de l'embarqué, du développement de drivers, etc. il y ai des contraintes qui poussent à éviter les exceptions, mais ce qui est vrai pour ces domaines-ci ne l'est pas forcément pour les autres, les contraintes n'étant pas les mêmes…
Quand au lien Google, ma compréhension de l'anglais est certainement perfectible, mais il me semble quand même qu'ils écrivent (traduction très libre) :
Donc, au final, ça m'a plutôt l'air d'un plaidoyer en faveur des exceptions C++…
Zelbinium, la programmation ludique
[^] # Re: c'est bien gentil
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : l'interface Web. Évalué à 6.
En l'état, pas grand chose ; on peut créer des fiches avec des champs textes, et réorganiser les champs d'une fiche, ainsi que les entrées d'un champs, par drag & drop, et c'est à peu prés tout. Des fonctionnalités seront ajoutées petit à petit, et feront l'objet de publications ici même.
En attendant, cette application fait office de proof of concept. Elle permet d'étudier la faisabilité, entre autres :
- de coder entièrement et uniquement en C++ une interface basée sur des technos Web,
- d'utiliser un seul et même code (C++) pour l'interface Web et pour l'interface native d'une application,
- d'offrir la possibilité de modifier entièrement l'apparence d'une application sans avoir à intervenir sur son code source, uniquement en modifiant des fichiers XSL.
Zelbinium, la programmation ludique
[^] # Re: De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 2. Dernière modification le 24 juillet 2016 à 17:35.
Je ne vois pas ce à quoi le terme dessus fait référence, et, quant au lien, je ne vois rien dans la biographie de l'auteur qui donne le moindre poids à ses écrits en général, et ces écrits en particulier. Par contre, j'ai trouvé ceci, dont B. Stroustrup lui-même est l'un des auteurs. Je pense que les deux premiers paragraphes de l'introduction sont on ne peut plus clairs quant à l'usage pour lesquels les exceptions C++ ont été conçues…
Zelbinium, la programmation ludique
# Le prochain épisode est paru :-).
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 1.
Pour ceux qui sont intéressés par la suite, notamment, comme annoncé, l'interface Web, avec une démonstration en ligne, ça se passe ici.
Zelbinium, la programmation ludique
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 2.
J'ai l'impression que tu penses que mes
Makefilesont plus sophistiqués qu'ils ne le sont réellement. Mes scripts de générations prennent en compte juste la nature du binaire à générer (exécutable ou bibliothèque) et la liste des fichiers sources. C'est tout. Pas de dépendances à gérer (il y a CEF maintenant, mais c'est une exception, et cela ne concerne qu'un seulMakefile). A nature de binaire identique, la seul chose qui change d'unMakefileà l'autre, c'est le tout début, qui contient la liste des fichiers source. Tout le reste est identique.Si, d'aventure, j'avais effectivement fait le choix d'utiliser autotools et/ou consorts, au lieu de placer les
Makefilegénérés dans le VCS, et bien j'y aurais placé les fichiers 'source' d'autotools et consorts, qui auraient également été générés, à l'instar desMakefile. Donc, cela n'aurait fait que déplacer le problème, si problème il y a, avec, en outre, une complexification induite par l'utilisation d'autotools et/ou consorts.Je ne connaissais pas. J'ai un peu regardé, pas beaucoup, car il semble que ce ne soit implémenté que dans les navigateurs. Or, j'ai besoin, d'une part, de pouvoir utiliser ce mécanisme dans mes propres logiciels (pour l'appliquer sur les fichiers de configuration de mes logiciels), et, d'autre part, de pouvoir mettre ce mécanisme en œuvre via un utilitaire en ligne de commande. Mes deux utilitaires (sablotron et
xsltprocess) ne semblent pas l'implémenter, et je n'ai pas trouvé d'utilitaire ou de bibliothèque qui implémente ce mécanisme. Donc, aujourd'hui, connaissant l'existence des embedded stylesheet, si j'étais confrontés aux même besoins que ceux qui m'ont poussés à développer XPP, je serais obligé de faire le même choix qu'à l'époque, à savoir développer ma propre solution.Ceci dit, je n'ai jamais écrit que je ne m’intéressais pas aux solutions alternatives, mais que je n'utilisais pas ces solutions (forcément, puisque j’utilise mes alternatives), et c'est bien ce dernier point qui dérange. Comme déjà évoqué, si je ne m'étais pas intéressé à ce qui existe, je n’utiliserais pas XML, mais mon propre langage de balisage…
Je comprends tout à fait que tu ne veuilles pas te plonger dans le code de cette bibliothèque (j'aurais la même réaction à ta place), mais alors, pourquoi ne pas me laisser le bénéfice du doute, c'est-à-dire de considérer que, peut-être, après tout, j'avais de bonnes raisons d'implémenter cette bibliothèque, au lieu de considérer d'office que c'était une erreur ?
Je ne comprend pas le rapport de ta réponse avec l'extrait de mon intervention que tu cites. Encore une fois, je n'ai jamais demandé à qui que ce soit de s’intéresser à mon framewok. Tu dis que j'ai demandé des retours ; je ne m'en souviens pas, et je ne vais pas relire l'ensemble des commentaires de ce journal, donc je vais supposer que c'est vrai, mais, ça serait, à priori, vu ce que j'avais à l'esprit en rédigeant ce journal, au sujet des particularités du logiciel, pas de la manière dont elles sont implémentées. Je pense qu'il est préférable d'avoir un bon logiciel, fût-il réalisé avec des solution non-standards, qu'un logiciel inutilisable, fût-il réalisé avec des solutions standards…
Peut-être pas, si c'est mes solutions qui deviennent les standards :-). Mais, je le concède, c'est mal parti, d'autant plus que ce n'est pas mon but à ce jour.
Et, en fait, le problème avec les standards, outre, qu'effectivement, cela ne permet pas toujours de réaliser ce que l'on veut, c'est surtout, et c'est bien plus grave, que cela ne permet pas toujours de réaliser ce que le client veut.
Quel est le problème de travailler seul ? Les clients ne se sont jamais plaints de mes délais (une fois qu'ils ont assimilé qu'on ne peut pas leur livrer le produit pour avant-hier), et j'ai toujours pu intégrer mes développements à l'environnement de production du client, quel qu'il soit.
De manière générale, les clients veulent un logiciel vite et bien fait. Que ce logiciel soit réalisé par une seule personne ou par plusieurs, (généralement, moins il y a de personnes impliquées, moins c'est cher, donc ils préfèrent), en utilisant ou non des solutions standards (je parle là des solutions de développement, pas des formats de fichiers), généralement peu leur chaut.
Merci !
Développer un logiciel n'est pas trivial. Pour cette raison, la majorité des développeurs utilise les solutions qu'ils considèrent (à tord ou à raison) les plus faciles à utiliser. Pour beaucoup, apparemment, notamment au vu des commentaires ici, il s'agit des solutions 'standards'. Bien que, moi aussi, j'utilise certaines solutions standards (XML est peut-être décrié, mais c'est néanmoins un standard ; ce n'est pas une de mes inventions), il se trouve que j'ai été amené à développer mes propres solutions parce que celles existantes ne me convenaient pas. Comme toi et certains des intervenants ici n'ont pas manqués de le souligner, c'est une démarche rare. Cependant, elle n'est pas unique. Et heureusement, sinon l'écosystème informatique serait bien pauvre. Toutes les solutions considérées comme 'standards' aujourd'hui ne l'ont pas été à leurs débuts, et se sont certainement vu opposer les 'standards' de l'époque. Heureusement, cela n'a pas découragé les concepteurs de ces solutions, sinon elles ne seraient pas considérées comme les 'standards' d'aujourd'hui…
Contrairement à ce que certains pensent ici, et je me demande bien sur quel base, je n'essaie pas de promouvoir mon framewok. Je ne fais que présenter quelques logiciels que je développe, à l'instar de celui présenté dans ce journal, qui ont comme particularité d'être tous basés sur mon framework (c'est simplement un fait technique), ce qui fait qu'ils ont certains points communs (manière de gérer les traductions, les arguments de la ligne de commande, possibilité de placer des directives XPP dans les fichiers de configuration…) qui les distinguent des autres logiciels. Mon but premier est de produire des logiciels qui satisfassent ses utilisateur (et, parmi ces utilisateurs, le plus exigeant de tous : moi) , et mon framework est un outil essentiel pour parvenir à ce but. Si, parmi ces utilisateurs, il y a des développeurs qui estiment que certaines particularités de ces logiciels, et donc, par conséquent, du framework sur lequel ils sont basés, sont suffisamment intéressantes pour contrebalancer le fait qu'il ne s’appuie pas sur des solutions 'standards', alors peut-être que, de concert, on pourra mettre en place les éléments qui lui permettront de gagner en popularité. Ou pas.
Zelbinium, la programmation ludique
[^] # Re: De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 1.
De ce que je sais, les exceptions ont été conçues pour faciliter la gestion des erreurs, quelles qu'elles soient. Je ne vois pas en quoi la nature de l'erreur change quoi que ce soit, d'autant plus lorsqu'elle est basée sur ces notions d'attendu/inattendu, pour autant qu'il y ai une définition précise et univoque des ces notions. En outre, la nature d'une même erreur peut varier selon le contexte. Reprenons l'exemple ci-dessus, en supposant que l'interface soit une interface Web. On peut envisager que, lors de la validation du formulaire, avant son envoi, un script JS soit exécuté pour vérifier si le champ est bien rempli, et n'envoyer le formulaire qu'à cette condition, ou, sinon, signaler à l'utilisateur qu'il lui faut remplir ce champ. Au niveau du code C++, le contenu du champ ne peut, théoriquement, jamais être vide, mais c'est une bonne pratique que de le vérifier tout de même, on ne sait jamais. Du coup, si cette erreur se produit tout de même (il peut y avoir un bug dans le code JS), erreur attendue ou inattendue ?
Zelbinium, la programmation ludique
[^] # De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 8. Dernière modification le 20 juillet 2016 à 15:01.
J'ai un jour dû écrire un logiciel en C de haute disponibilité, qui devait tourner 24h/24, 7j/7, sur un PC industriel équipé d'un watchdog, histoire qu'il reboot automatiquement si mon logiciel devait planter. Du coup, la plupart de mes fonctions comportaient pléthore de if dont l'unique objet était de remonter à la fonction appelante les erreurs détectées dans les fonctions appelées. Je trouvais que cela rendait le programme presque illisible, car il était difficile de distinguer parmi tous ces if lesquels étaient 'algorithmiques', et lesquels étaient dédiés à la gestion d'erreurs.
Pour améliorer cela, j'ai implémenté en C, en m'appuyant sur la bibliothèque setjmp, un mécanisme, sous forme d'un jeu de macros, dont je me suis rendu compte plus tard qu'il s'apparentait aux exceptions C++, que je ne connaissais pas à l'époque. D'ailleurs, quand je suis passé au C++, j'ai réimplémenté ces mêmes macros en m'appuyant sur les exceptions, au lieu de la bibliothèque setjmp. J'utilise toujours ces macros pour la gestion des erreurs, et, bien que, par défaut, elles s'appuient sur les exceptions C++, on peut, à l'aide d'une option de compilation, basculer sur la bibliothèque setjmp, pour une utilisation dans un environnement où les exceptions ne seraient pas disponibles.
Quand ma production consistait essentiellement en utilitaires en ligne de commande, l'exception était interceptée grosso-modo dans le
mainpour afficher un message d'erreur. Par contre, depuis que j'écris des daemon, l'exception est interceptée à la fonction racine du thread dans lequel elle est lancée, pour afficher un message d'erreur dans un log, voire relayer ce message au client, avant de terminer le thread en question. Mais le thread principal continue toujours de tourner, ainsi que les autres threads, prêts à répondre aux requêtes des différents clients.Pour les interfaces graphiques, l'exception est interceptée dans la boucle de gestion des événements. Par exemple, si l'utilisateur valide un formulaire en oubliant de remplir un champ obligatoire, une exception est lancée qui remonte jusqu'à cette boucle, affiche un message signalant la nécessité de remplir le champs oublié, et ensuite laisse tout loisir à l'utilisateur de remplir le champ en question, comme s'il ne s'était rien passé.
En ce qui me concerne, les exceptions (ou la setjmp en C) facilitent grandement le développement de logiciels…
Zelbinium, la programmation ludique
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 1.
J'ai présenté un logiciel dont j'ai commencé le développement, en mettant en exergue quelques caractéristiques. Pour ceux que cela intéresse et qui voudrait en savoir plus, je répondrais volontiers à leurs questions. Quant à ceux qui prétendent qu'il y a des outils plus adaptés que ceux que j'utilise pour coder ce genre de logiciel, je veux bien en débattre, mais il faudrait qu'il y déjà ai matière à, c'est-à-dire des éléments concrets et pas seulement des généralités ; je ne vais pas passer en revue toutes les solutions qui existent dans le domaine pour tenter de deviner ce à quoi ils font référence…
C'est tout ce qu'il y a à comprendre dans ce journal et mes commentaires. Pour ceux qui ont compris autre chose, j'en suis désolé pour eux, mais je n'y peux rien…
Donc, non, je ne veux pas que l'on me pose des questions techniques ; je signifie seulement que, pour qu'il y ai débat sur la pertinence de mon code, cela ne peut se faire sans éléments techniques. Et les commentaires dans le code, c'est généralement pour en faciliter la compréhension, et certainement pas pour y placer un argumentaire pour tenter de convaincre de la supériorité technique dudit par rapport à d'autres solutions (ceci dit, tu y mets ce que tu veux, dans les commentaires de ton code…). Au sujet de la dépréciation de mon code, je ne faisais que reformuler la notion de discrédit évoqué dans un précédent commentaire, qui n'était même pas une réponse à l'un de tiens ; il ne faut pas tout prendre personnellement. Et tu ne m'apprend rien en écrivant que je promeus mal mon code ; j'ai moi-même écrit ici, et à plusieurs reprises, que je ne sais pas communiquer sur mes projets. Et je ne vois pas où j'ai pu ne fût-ce que suggérer que je désirais que les gens investissent quoi que ce soit sur mon code. Et enfin, si je réponds des banalités, c'est uniquement aux questions auxquelles on ne peut faire que ce genre de réponses…
Zelbinium, la programmation ludique
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 0.
Si, j'ai bien regardé ce qui se faisait ailleurs, mais, comme cela ne répondait pas à mes besoins, je n'ai pas utilisé.
Comme je l'ai indiqué dans le pénultième paragraphe de mon précédent commentaire, je comprends parfaitement que l'on ne veuille pas se plonger dans le code de mon framework. Mais alors, pourquoi affirmer que ce framework est globalement nettement moins bon que les autres (bon, il y a des aspect où il est clairement moins bon, notamment en ce qui concerne la documentation) ? Mon framework, j'en ai commencé le codage il y a plus de 15 ans. J'ai regardé tout au long de ces années ce qui se faisait chez la 'concurrence', mais j'ai à chaque fois découvert au moins un aspect rédhibitoire, dont je ne me rappelle plus à ce jour, qui fait qu'au final j'ai continué à utiliser mon framework. Et donc, je ne peux rien dire concernant les autres framework car, contrairement à certains ici, je ne parle d'un sujet que si je le connais suffisamment.
Çà fait trop longtemps que je l'ai codée pour me rappeler précisément tout ce qui a entouré sa genèse. Mais, au lieu de la déprécier, pourquoi ne pas avoir écrit "Moi, j'utiliserais telle bibliothèque, qui fait ça, ça et ça ; pourquoi ne pas l'avoir utilisée ?", auquel cas je pourrais répondre, par exemple, que je ne la connaissais pas, qu'elle n'existait pas à l'époque, ou bien encore qu'il lui manque telle ou telle fonctionnalité. Bref, on pourrait enfin avoir un véritable débat…
Zelbinium, la programmation ludique
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 2. Dernière modification le 07 juillet 2016 à 21:22.
On me reproche des abstractions soit-disant inutiles dans mon framework, mais les commentaires eux-mêmes ne portent essentiellement que sur des abstractions ; c'est difficile d'argumenter dans ces cas là. Il y a néanmoins quelques points concrets qui sont évoqués auxquels je vais tenter de répondre.
Les noms abscons. Je m'en suis justifié plus haut. Et surtout, je ne pense pas que le problème vienne des noms en soi, mais plutôt de l'absence de documentation au sujet des binaires concernés. Je n'aime pas rédiger de la documentation, car je suis très mauvais en cela. Mais j'essaie quand même d'en écrire, tant bien que mal, comme en témoigne le contenu de mon Wiki.
Les fichiers générés contenus dans le VCS ; je pense que tu entends par là le contenu du dépôt mercurial. Les seuls fichiers générés qu'il contient sont les
Makefile, et les.hcontenant les APIs des backends. Ces fichiers sont générés à l'aide de scripts stockés sur ma machine de développement principale, celle avec laquelle je travaille la plupart du temps. Si je ne mettais pas ces fichiers dans le dépôt, je serais obligé de les régénérer sur chacune des mes autres machines de travail, et donc d'installer ces scripts et leur environnement d'exécution sur ces machines, ce qui est loin d'être évident vu la diversité des machines (il y a là des machines sous Windows, Linux, MacOS, Android et même Maemo…). Donc, j'ai choisi la solution la plus facile et la plus rapide, à savoir de placer ces fichiers dans le dépôt. Il y a aussi un.xmlcorrespondant à l'API d'un backend. A vrai dire, celui-ci n'y a été mis que récemment, à l'occasion de la rédaction de ce journal ; en temps normal, je ne place pas ces fichiers dans le dépôt.Pour le contenu des
Makefile, je ne vois pas le problème, mais je n'y connais à vrai dire pas grand chose sur le sujet. Le cœur duMakefile, qui se situe à la fin du fichier, est tout ce qu'il y a de plus classique (règle de construction du binaire à partir des fichiers objets, règle de construction des fichiers objets à partir des fichiers sources). Le reste, ce n'est que l'adaptation aux particularités des différentes plateformes sur lequel il peut être lancé. Qu'est-ce qui sort donc de l'ordinaire, et par quoi peut-on le remplacer qui soit plus conforme aux standards en la matière ?xppq. La principale différence avec XSL (mis à part que XPP n'est de loin pas aussi puissant que XSL), c'est que les directives XSL doivent être placées dans un fichier disjoint de celui qui contient le XML sur lequel on va appliquer ces directives, alors que les directives XPP, quant à elles, sont directement placées dans les fichiers XML sur lesquels elles portent. Le principe derrière XPP est le même que celui du préprocesseur C. XSL n'a pas du tout la même approche. A noter que j'utilisais XSL bien avant d'avoir écritxppq; je l'ai donc écrit car il répondait à un besoin auquel XSL ne pouvait répondre.Pour les traductions, je n'utilise pas gettext, car je réutilise le même mécanisme que pour mes fichiers de configuration. Utiliser gettext aurait impliqué un travail de codage supplémentaire, que j'économise avec le système que j'utilise.
Les dates. Je pense que tu te réfères à la bibliothèque
DTE. Je l'ai développée pour répondre aux besoins d'un client. Ce dernier devait pouvoir stocker des dates classiques, mais aussi approximatives. Il y a, en effet, certains personnages dont on ne connaît pas avec précision les dates de naissances et/ou de décès. Avec cette bibliothèque, on peut stocker des dates au jour prés, mais aussi seulement au mois, à l'année, à la décennie… prés. Comme le surcoût de cette bibliothèque est négligeable par rapport à celle d'une bibliothèque de gestion de dates classique, j'en ai fait ma bibliothèque standard.Ta réaction à bibliothèque
DTEest typiquement celle que je ne comprends pas. Parce certains ne voient pas l'utilité de réimplémenter une telle bibliothèque, ces derniers décrètent que c'est une erreur, sans chercher à comprendre les motivations derrières. Et c'est cette même approche de mon framework en général que l'on retrouve dans les commentaires ; on ne comprend pas, donc, au lieu d'approfondir, ou de demander des éclaircissement au développeur si l'on a pas envie de se plonger dans le code (ce que je comprends tout à fait), on se répand en généralités sans rapports pour discréditer le framework en question.Quand à ma soi-disant méta-blague, ce n'en est pas une, méta ou non. C'est la réelle motivation qu'il y a derrière mon framework. Je suis un développeur professionnel, et je n'aurais pas développé ce framework si je pouvais développer aussi vite et aussi bien avec d'autres outils. Ceci dit, je suis tout-à-fait prêt à envisager que je me suis fourvoyé, mais, de grâce, appuyez vos écrits avec des exemples concrets ; il s'agit de Logiciel Libre après tout, et les sources sont facilement accessibles (même pas besoin de les télécharger !).
Zelbinium, la programmation ludique
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . En réponse au journal 'Epeios organizer' : le commencement. Évalué à 1. Dernière modification le 06 juillet 2016 à 16:41.
Je parle d'une hostilité envers mes technos, pas envers moi. Je ne me sens victime d'aucune cabale. Je constate simplement qu'à chaque fois que j'évoque certaines technos, comme XML/XSL(T), ou que j'associe technos Web et C++, on assiste systématiquement à une levée de bouclier, sans que jamais l'on avance le moindre argument valable justifiant cette aversion.
Et effectivement, j'emploie XML/XSL(T) depuis longtemps, bien plus longtemps que ne le suggère les journaux que j'ai publié. J'ai commencé à utiliser XML/XSL(T) en conjonction avec XUL(Runner), ce qui remonte grosso-modo à 2004. A l'époque déjà, et régulièrement depuis, j'ai étudié les alternatives, sans qu'aucune ne s'est révélée à la hauteur de mes attentes (et ceux de certains de mes clients) en comparaison avec XML/XSL(T).
Concernant la tonne de code, c'est l'ensemble de mon framework, dont les technos présentées ici ne représentent qu'une faible partie. Ce framework couvre un large éventail de fonctionnalités, d'où sa taille.
Pour ton exercice, une seule phrase suffit : me faciliter le développement de logiciels de qualité.
Comme je l'ai déjà écrit dans une de mes précédentes réponses, je suis conscient que j'ai de sérieuses lacunes en matière de communication, mais, encore une fois, pour susciter l'intérêt sur un sujet, communiquer mal est toujours mieux que de ne pas communiquer du tout. Et si le logiciel et si mal accueilli, c'est aussi parce qu'il est difficile à déployer avec les package fournis. Comme je l'ai écrit dans une autre réponse, c'est à cause de CEF, sur lequel s'appuie mon logiciel pour l'interface native. Mais je travaille à l'amélioration du packaging.
Je ne veux pas attirer du monde sur mes technos ; je la présente simplement au cas où cela intéresserait des personnes, auquel cas j'échangerais volontiers sur le sujet avec ces dernières. Et pour celles qui trouvent ces technos inadaptées, il n'y a pas de problèmes non plus, je discuterais tout aussi volontiers avec ces dernières de l'intérêt de mes technos.
Zelbinium, la programmation ludique