Sommaire
- Introduction
- Liens
- XML, XSL(T) et HTML5
- Backend/frontend
- Plugins
- Epeios organizer
- Lancement
- Et ensuite ?
Introduction
Epeios organizer est développé pour répondre à deux objectifs.
Le premier objectif est la mise à disposition d'un logiciel libre qui comprendra, à terme, des fonctionnalités de prise de notes, d'agenda, de carnet d'adresses, etc. mais avec de notables différences avec l'existant. Par rapport à ce premier objectif, le logiciel est, pour l'instant, embryonnaire. Je ne vais donc pas m'attarder sur ses fonctionnalités, car elles feront l'objet de publications au fur et à mesure de leur développement.
Le second objet de ce logiciel, et le principal sujet de ce journal, s'inscrit dans la continuité de ce journal-ci, qui, lui-même, s'inscrit dans une démarche de développement d'un framework qui vise à faciliter le développement de logiciels (potentiellement libres) de qualité. Ce journal détaille certaines particularités de ce framework qui sont mises en œuvre dans l'application Epeios organizer.
Liens
L'ensemble des sources du logiciel, et les binaires correspondants pour Windows, peuvent être téléchargés à l'adresse http://q37.info/download/computing/apps/orgnzq/ . Les sources peuvent aussi être consultés directement à l'adresse :
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/apps/orgnzq pour l'application proprement dite,
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/tools/xdhcefq pour l’utilitaire prenant en charge la technologie XDHTML en tant qu'application native,
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable pour le framework.
La documentation est peu fournie pour l'instant du fait de la jeunesse du logiciel. Voici néanmoins quelques adresses :
- pour la compilation : http://q37.info/computing/epeios/compilation/,
- pour la mise en place de l'environnement d'exécution de CEF : http://q37.info/computing/epeios/tools/xdhcefq/.
XML, XSL(T) et HTML5
Pour faciliter la personnalisation de l'interface du logiciel sans avoir à intervenir sur le code de l'application proprement dit, l'interface s'appuie sur du HTML5 dont le code est produit en appliquant une transformation XSL sur un flux XML produit par le logiciel. Le fichier XSL utilisé pour la transformation est aisément éditable par l'utilisateur, ce qui lui permet de modifier à volonté et l’apparence, et la disposition des différents éléments de l'interface.
Un exemple d'un tel fichier XSL est visible à l'adresse http://hg.savannah.gnu.org/hgweb/epeios/file/c4cce94393a0/apps/orgnzq/frontend/XDHTML/XSL/FieldsLayout.xsl
Backend/frontend
La partie dédiée à l'interface est déportée dans un composant appelé frontend, et la partie traitement dans un composant dénommé backend. Ces composants sont totalement indépendants et communiquent à l'aide d'un protocole maison. Ce protocole est conçu pour pouvoir fournir les caractéristiques du backend (les objets pris en charge ainsi que leurs caractéristiques), caractéristiques qui sont sauvées dans un fichier XML. L'API C++ peut alors être généré en appliquant sur ce fichier XML une transformation XSL s'appuyant sur un fichier au format du même nom. Cela permet d'automatiser la mise à jour de cette API suite à une modification du backend, mais ouvre également ouvre la possibilité de générer l'API dans un autre langage, en s'appuyant sur un autre fichier XSL.
Ci-dessous, vous trouverez les adresse des ces différents fichiers :
- le fichier XML correspondant au backend de l'application Epeios organizer : http://hg.savannah.gnu.org/hgweb/epeios/file/3a5c361be1a0/apps/orgnzq/frontend/frdapi.xml,
- le fichier XSL utilisé pour la transformation : http://hg.savannah.gnu.org/hgweb/epeios/file/3a5c361be1a0/stable/frd4cpp.xsl,
- et le header C++ résultant : http://hg.savannah.gnu.org/hgweb/epeios/file/3a5c361be1a0/apps/orgnzq/frontend/frdapi.h.
La manière dont sont implémentées les interactions backend/frontend permet de lancer l'application dans un contexte mono-utilisateur, dans lequel le backend est directement chargé par le frontend, les échanges ayant lieu via de la mémoire partagée, ou dans un contexte multi-utilisateurs, dans lequel le backend est lancé en tant que daemon, les frontends communiquant alors avec ce dernier via une connexion réseau.
Plugins
Pour faciliter au maximum l'adaptation du logiciel aux besoins de ses utilisateurs, un maximum de fonctionnalités est déporté dans des plugins. D'une part, il est plus facile d'adapter un logiciel si ce dernier à prévu des mécanismes pour cela, et, d'autre part, le développement d’un plugin permet de n'avoir à prendre en compte qu'une partie réduite du code source du logiciel, et non pas l'intégralité (compilation plus rapide…).
Ainsi, l’authentification, le stockage des données, et chacun des types de champs est pris en charge par un plugin dédié ; cela offre virtuellement une infinité de possibilités d’adaptation du logiciel.
Epeios organizer
Quelques mots sur les (rares) fonctionnalités présentes dans ce logiciel. Comme déjà indiqué, ces fonctionnalités sont très rudimentaires, ce logiciel servant surtout, dans un premier temps, à valider certaines technologies détaillées ci-dessus.
Lors de la connexion, lorsqu'un utilisateur utilise un identifiant existant, il n'est authentifié que lorsque mot de passe fournit correspond au mot de passe associé à l'identifiant. Lorsque l'identifiant fournit ne correspond à aucun identifiant existant, alors un nouveau compte est crée, associé avec le mot de passe saisit à ce moment-là.
Une fois authentifié, l'utilisateur peut alors créer des enregistrements, avec des champs mono (composés d'une et une seul entrée), ou multi (composés d'une ou plusieurs entrées). Le seul type de champ à ce jour existant est le type texte. L'ordre des champs, et l'ordre des entrées au sein d'un champ peut être modifié en recourant au drag & drop.
Une entrée dont on efface le contenu est supprimée. Un champ dont on efface toutes le entrées et supprimé. Un enregistrement dont on efface tous les champs est supprimé.
L'ensemble des données est actuellement uniquement stocké en RAM ; lorsque l'application est coupée, tout le contenu est perdu.
On peut constater que les capacités du logiciel en l'état sont très limités, mais ces capacités évolueront bien entendu au fur et à mesure, entre autres, de l'amélioration des plugins, disponibles et par la mise à disposition de plugins plus performants.
Lancement
Par défaut, l'application est configurée pour être utilisée en mode mono-utilisateur, c'est-à-dire que le backend est directement chargé par le frontend.
Sous Windows, à partir du package binaire
Pour un lancement à partir du package binaire, se placer dans frontend\XDHTML, et lancer xdhcefq\xdhcefq.exe -m=orgnzqxdh, puis cliquez sur OK dans les deux première pages. Ce package embarque CEF ; nul besoin de le télécharger.
Si l'on veut basculer en mode multi-utilisateurs, il faut au préalable lancer le backend, en se plaçant dans processing\backend, et en lançant tool\dmnzq\dmnzq.exe dmnzq.xprj. Relancer alors le frontend comme indiqué ci-dessus, mais, à la seconde page, sélectionner Moteur de traitement local avant de cliquer sur OK.
Sous les autres systèmes, à partir du package source
Pour un lancement à partir du package source, il faut compiler l'ensemble des sources. Pour ce faire, il faut installer CEF comme indiqué à la page dont le lien est donné ci-dessus. Ensuite, à condition que vous ayez installé l'environnement de développement C++ adéquat, ainsi que la commande make, il suffit de lancer cette commande à la racine de l'archive, puis suivre les instructions de cette même page pour le lancement.
Et ensuite ?
La version Web de ce logiciel est la prochaine étape ; un seul et même code sera alors utilisé, et pour la version native, et pour la version Web, (et ultérieurement probablement également pour les versions mobiles). Et cela vaudra également pour tous les autres logiciels qui seront développés en s'appuyant sur le même framework.
Cette version Web fera probablement l'objet d'un prochain journal, avec une démonstration accessible en ligne. Bien entendu, en parallèle, les fonctionnalités de ce logiciel seront améliorées et de nouvelles seront développées.
Sinon, il y a bien évidemment la documentation à étoffer, le packaging à améliorer, ainsi que son design, mais, comme expliqué ci-dessus, pour ce dernier point, cela peut être aisément réalisé par l'utilisateur pour peu qu'il ai quelques connaissances en HTML5 et XSL.
# Troll
Posté par ʭ ☯ . Évalué à 10.
….. donc c'est un peu un agenda écrit avec un équivalent de XUL?
Je ------------->
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Troll
Posté par arnaudus . Évalué à 10.
Non, ça n'est pas un agenda, c'est pour l'instant un logiciel qui ne fait rien. Il est juste développé pour montrer la faisabilité du projet (c'est ce que j'ai compris).
Du coup, euh, ouais, d'accord. C'est un truc qui convertit des données en fichiers XML qui sont transformés en HTML par des moulinettes XSLT, et il y a aussi une histoire de fichiers XML qui servent à créer des fichiers C++ qui doivent être compilés pour faire un truc, euh. Et les fonctionnalités du logiciel sont apportées par des plug-in.
Je pense que je suis parfois un peu perdu par la complexité de tels méta-projets qui empilent les couches. L'objectif, c'est d'accéder et modifier des données à travers une interface. À moins de faire partie d'une enpreprise avec des millions de collaborateurs, il n'y a pas des To de données d'agendas, est-ce qu'un langage de script à la con ne pourrait pas gérer ça?
Après, c'est sûr, «J'ai écrit devant le match de foot un script perl qui me sort une page d'agenda en HTML à partir d'un fichier texte à trois colonnes "jour date text"», c'est moins vendeur. M'enfin, du coup, on aurait un agenda, pas un framework vide dont les technos semblent tellement tarabiscotées que la phase 1 du projet est d'essayer de mettre en place un truc qui ne fait rien pour prouver la faisabilité du truc qui fera quelque chose…
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Comme je l'ai clairement, et à plusieurs reprises, indiqué dans le journal, le logiciel fait peu, très peu, mais pas rien. Et comme c'est précisé dans le titre, ce n'est que le commencement. Il en faut bien un.
Aussi peu qu'il fasse, ça m’étonnerait que ce soit faisable avec des scripts, qu'ils soient à la con ou pas. Mais je ne connais pas tous les langages, alors il est possible que je me trompe, et je serais enchanté d'en apprendre plus sur le sujet.
Comme indiqué dans le journal, on peut télécharger les sources, voire les consulter en ligne, lancer la version Windows de l'application en quelque clics (et quelques commandes saisies dans la console, il est vrai) voire la lancer sur d'autres OS (bon, là, c'est vrai, ce n'est pas aussi simple qu'avec Windows, parce que je ne sais pas faire). Bref, il y a largement de quoi se rendre compte que le framework est loin d'être vide.
Sinon, l'objectif de ce framework est de simplifier le développement d'applications (je ne suis pas masochiste). Et je répondrais volontiers à toute question sur des points qui peuvent paraître obscurs.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par arnaudus . Évalué à 3.
Visiblement, je ne suis pas le seul à ne pas avoir compris ce qu'était Epeios, ce qu'il est censé faire, ce qu'il fait pour l'instant, ni même comment ça fonctionne. Plus bas tu dis que tu ne sais pas comment décrire le paradigme, que tu connais peu les alternatives existantes. Mais tu promets que tout plein de choses sont faisables, même si pour l'instant ça n'est pas fait.
Honnêtement, pour moi qui ne suis pas spécialiste de ces histoires de surcouches et de cascades de technologies, le concept de "framework" ne me dit rien. Visiblement, pour d'autres qui savent de quoi ils parlent, ils n'ont pas non plus compris l'intérêt du logiciel, et ils trouvent les technos un peu ringardes.
On est peut-être tous un peu cons, mais c'est aussi peut-être que tu as mal expliqué, non? Si au bout de deux pages on ne comprend pas ce que le logiciel est censé faire et comment il le fait, ça risque d'être compliqué de motiver les gens à télécharger un binaire Windows pour l'essayer (sous wine? Parce qu'ici c'est quand même un site dédié à Linux).
C'est peut-être un problème de timing, si tu n'as pas de brique de base qui fournit un service (un agenda tout bête par exemple), il est peut-être trop tôt pour essayer de communiquer.
Moi j'avais compris qu'il s'agissait de fournir un agenda au format HTML, et ça, bah si, c'est faisable avec des scripts. Si c'est fournir un framework qui transforme des fichiers XML en code C++, peut-être que ça n'est pas faisable, mais comme je ne sais pas à quoi ça peut servir, bah voila, quoi.
En gros, il y a peut-être des gens qui ont besoin de tels outils, mais ça n'est visiblement pas mon cas. Ce que j'ai compris, c'est que si je cherche un agenda, bah ça n'est pas ça du tout que fait ton logiciel.
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Comme je l'ai indiqué au début du journal, l'intérêt du logiciel, en l'état, ne réside pas dans ses fonctionnalités, très limitées pour le moment, mais des technos mis en œuvre. En l’occurrence, l'une dans les technos permet de modifier l'interface graphique du logiciel sans avoir à intervenir sur ses sources. Comme il s'agit d'un logiciel libre, il est censé offrir la liberté de le modifier, et cela par la mise à disposition de ses sources. Avec cette techno, il est encore plus facile d'appliquer cette liberté à son interface, puisque qu'il n'est pas nécessaire de modifier ses sources pour cela. N'ayant connaissance d'aucune autre techno qui offre cette possibilité, et ce site traitant des valeurs attachées au Libre, je pensais que cette techno pouvait intéresser son lectorat, d'où ce journal.
Concernant cette techno, et les autres présentées dans ce journal, toute les affirmations ne sont pas des promesses concernant de futures caractéristiques, mais la description de caractéristiques existantes, et chacun peut s'en persuader en consultant les sources. Je suis conscient que je suis loin d'exceller dans l'art de la communication, et que mes écrits en pâtissent, et c'est pour cela que je m'applique à fournir les réponses les plus pertinentes possibles aux différents points soulevés dans les commentaires.
Que ce soit dans ce journal, ou dans d'autres, on se gausse souvent que j'emploie XML/XSL, ou certaines autres combinaisons de technos, parce que, paraît-t-il, il en existe maintenant de plus récentes pour faire la même chose, mais en mieux. C'est quelque chose que je suis tout à fait prêt à admettre, mais certainement pas uniquement sur la base d'affirmations péremptoires qui ne sont étayées d'aucun élément probant. A titre d'exemple, j'attends toujours que l'on m'indique quelle est cette technologie qui est tellement mieux que XML/XSL(T), et en quoi elle est mieux.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par groumly . Évalué à 4.
Si tu parles de la possibilité de définir une UI en déclaratif, ya de quoi faire. NeXT/Apple le font depuis le début des années 90, flex le faisant ya 10 ans, Android le fait depuis un bail, qt le fait avec creator et je serais surpris si ms avait pas ca depuis un bail.
Si tu parles de la possibilité de modifier le comportement de l'appli depuis du xml, deux choses:
- on a fait plus simple qu'xml pour décrire des comportements
- ça fait un bail aussi qu'on sait que c'est pas une bonne idée (si Apple a jamais porté les bindings d'interface builder sous iOS, c'est pour une bonne raison). C'est un cauchemar à maintenir, et apporte au final tres peu.
Bref, j'ai un peu laissé tomber quand j'ai vu que le nom de l'appli était xdhqxddqt et que t'avais un autre nom de projet a peu près pareil, à 2-3 d/h/x prêt. Ça me donne vachement l'impression d'un inner platform effect si tu veux mon avis.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 1.
J'ai essayé QML (je pense que c'est à cela que tu fais référence avec Qt), et j'ai fait un peu d'Android, mais ça date d'il y a pas mal de temps. Pour Microsoft, il y XAML auquel j'ai jeté un œil, mais cela fait longtemps aussi. Or, il me semble bien que toutes ces technos nécessite une sorte de compilateur. Le mécanisme qui est mis en œuvre dans mon logiciel ne nécessite pas de compilation. Il n'est même pas nécessaire de relancer le logiciel pour voir les modifications. Comme je l'avais écrit dans un des commentaires ci-dessus, j'avais déjà fait quelque chose de similaire, bien que pas aussi poussé, en utilisant XUL, mais je n'ai jamais entendu parler d'un autre logiciel utilisant XUL dans ce but, ce qui n'a rien d’étonnant, vu que XUL n'a guère était employé en-dehors des produits Mozilla.
XML ne sert qu'à exposer les données, et quelques informations associées, qui doivent être affichées, sans même la moindre indication sur la manière dont ces données doivent être affichées.
Avec les applis que je développe pour les clients et mes applis personnels, tous contenant plusieurs binaires, ça fait un paquet de noms à trouver. Aussi, pour ne pas perdre trop de temps avec ça, j'ai établis quelques règles de nommage ; malheureusement, ces règles donnent des noms parfois un peu abscons, mais c’est le prix à payer si l'on veut des noms pas trop longs. Quand à l'inner platform effect, je ne connaissais pas, et, vu ce qu j'ai lu à ce sujet, je ne vois pas trop le rapport entre ça et le nom de mes projets/applis…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par groumly . Évalué à 5.
Ok, donc visiblement, on parle de simple définition d'ui en déclaratif? Tu fais pas de bindings (e.g. Définir dans le xml que ce champ reçoit le contenu de la variable foo du contrôleur)?
Effectivement, la plupart des technos ont une forme de compilation, ça évite de se taper le surcoût de parser du xml à la volée pour qq chose qui n'est pas censé être changé après le packaging de l'appli. L'exception, de mémoire, c'est le truc de Facebook, components il me semble, et eux ont un besoin bien précis (j'y reviendrais).
Si rares sont ceux qui le font c'est parce que le besoin est faible. Changer un storyboard et relancer l'appli sous iOS, c'est moins d'une seconde. Tu changes juste une ressource qui est rapide à compiler, tu touches pas le code, ça va vite.
Pour ceux qui veulent modifier l'ui d'un logiciel libre, c'est d'une part assez rare, et d'autre part généralement un peu plus compliqué que juste changer le layout. Optimiser pour la simplicité de compilation n'est pas un bon calcul.
Ce qu'il se passe pour Facebook est qu'ils ont une appli gigantesque, dont le contenu change en permanence et en temps réel, maintenue par des dizaines de personnes et releasee tous les 15 jours. la modifier sans tout peter est très dur. Le feed se met à jour constamment et affiche les likes/commentaires etc en temps reel.
Le modèle traditionnel "modifie la vue pour afficher les données" marche mal, parce qu'il ya trop d'état différents pour chaque vue, et donc calculer le diff est dur.
Leur solution à ce problème, c'est de partir sur un modèle 100% événementiel/stateless. C'est plus simple de tout balancer et de rerendre les vues quand les notifications de changement de données arrivent. Charge à la team du framework de recycler les vue pour que ca rende toujours à 60fps sans bouffer toute la ram du device.
Le fait que les vues se recharges automatiquement à chaud est juste un effet de bord sympa, c'est tout, c'est pas un but en soi.
Bref, assez parlé de Facebook, retournons à xdh chose.
- quel problème xdh-chose essaye de résoudre?
- en quoi ce problème est pertinent?
- en quoi la solution de xdh améliore l'état actuel?
Un des concepts de base en ingénierie est qu'on ne résoud jamais vraiment un problème. On transforme un problème en un autre, mais cet autre problème vient avec ses inconvénients. Si les nouveaux inconvénients sont moins nombreux/courants/ennuyeux que ceux qu'on avait a la base, on a gagné. En d'autres termes, on fait des compromis.
Un compilateur rend plus simple l'écriture de code, par exemple, mais le langage vient avec ses tares, et cache le fonctionnement sous jacent de la machine. En pratique, c'est un gain net.
J'ai du mal, personnellement, à voir le gain sur le compromis que tu fais ici. Tu gagnes sur le code, mais tu te retrouves avec plus de 1000 lignes de xml aride pour une appli triviale. ça coûte cher le setup de l'appli, même les monstres à là spring font tout ce qu'ils peuvent pour réduire ca le plus possible (et eux font beaucoup plus que toi avec ce setup).
Le xml est particulièrement aride à lire, très long, tres verbeux et ca se répète énormément. Ça fait 15-20 ans qu'on sait que les UI déclaratives, c'est cool, mais il faut un éditeur riche pour que ça marche. Ça va plus vite à écrire, et ça permet d'avoir une vue de l'ensemble.
Le xml pour générer les stubs back/front end, on sait depuis soap que c'est une très mauvaise idée. C'est vilain, verbeux et ca résoud quasiment aucun problème, ca en rajoute juste.
Dans l'autre sens, ça marche mieux (par exemple ce que fait jaxrs avec les wadl). La tendance "xml pour générer des stubs" avait le vent en poupe ya 15 ans, tout le monde en revenu parce que c'est un enfer à maintenir et ca ne résoud pas vraiment de problème. C'est plus simple/lisible/naturel d'écrire une interface en code directement.
Bref, désolé de tailler un costard, mais j'ai beaucoup de ma à voir un intérêt au framework, et à mon avis, ce genre d'approche diminue la qualité plus qu'autre chose.
Et bien changes les règles. Rajoutes des voyelles, ça coûte pas plus cher et ça fait des mots lisibles et prononçables.
Le commentaire sur l'inner platform effect se rapportait au framework, pas aux noms :)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Ben, au final, le code derrière l'UI, c'est simplement du bête HTML5, similaire à ce qu'on trouve dans la plupart des pages Web ; il est simplement mis en forme à l'aide de XSLT… CEF, c'est, grosso-modo, le navigateur Chromium, mais sans les éléments d'interface qui en font un navigateur Web, c'est-à-dire juste le moteur de rendu. Tout aussi grosso-modo, CEF est à Chromium ce que XULRunner est à Firefox (bon, je ne sais si ça va parler à beaucoup de monde, ça). Mon appli donne à CEF (donc Chromium) du XML et du XSL, et CEF se charge de transformer ça en HTML, dont il assure également le rendu.
Je ne comprend pas trop ta dernière phrase. Cependant, ma techno permet à tout un chacun de modifier l'interface :
- à l'aide d'un simple éditeur de texte, sans avoir mettre en œuvre d'autres outils (compilateur ou autres…),
- essentiellement juste en connaissant HTML et XSLT/XML ; à défaut, il pourra s’adresser à n'importe quel développeur Web digne de ce nom.
A priori, mais je n'ai pas encore approfondi le sujet, cela devrait permettre de modifier une application pour, par exemple, l'adapter à l'usage des mal/non-voyants, sans pour cela avoir à impliquer le développeur de l'application. Je pense que pour faire la même chose avec les autres technos citées dans ce journal, il faudrait l'intervention d'un développeur. Accessoirement, cela permet facilement au développeur de déléguer la réalisation du design de l'interface, vu qu'il ne manque pas de personnes ayant les compétences nécessaires (développeurs Web). Personnellement, n'ayant aucune affinité particulière avec HTML et consorts (CSS, JS…), c'est quelque chose qui m'arrange bien.
Bon, quand je parle de l'utilisateur, il peut aussi s'agir d'une entreprise qui adapte l’interface du logiciel à sa charte graphique, par exemple…
En effet. J'ai cité cela pour juste souligner la facilité avec laquelle on peut modifier l'interface.
Je pense que tu parle des attributs
data-xdh-.... Ça n'est pas censé résoudre un problème en particulier, c'est juste mon approche pour gérer :- pour les
data-xdh-onevent(s), la mise en place des gestionnaire d’événements,- pour les
xdh-data-cast(s), l'accessibilité (je ne trouve pas de terme adéquat pour désigner le fait qu'un élément soit hidden/disabled…).Il y a également les
data-xdh-widget, mais qui ne sont pas (encore) utilisés dans cette appli, et qui sont dédiés à la gestion des widgets basés sur jquery, qui semblent assez répandus.Tout ça permet de confier au logiciel la mise en place du code JS généralement mis en œuvre pour ces usages.
Étant le développeur de cette appli, je m'abstiendrais de me prononcer sur ce point ; on pourrait m'accuser de manquer d'objectivité :-).
Là je pense que tu parle des fichiers de configuration (les
.xcfg). Le problème vient du packaging. En réalité, mes fichiers de configurations sont plus simples que ceux qui sont fournis dans les packages (comme on peut le voir en regardant les version hébergées dans le repository mercurial dont l'adresse est donné dans le journal), car ils s'appuient sur un préprocesseur XML, ce qui permet d'utiliser des macros, et de répartir le contenu sur plusieurs fichiers. La version packagée est celle après application du préprocesseur XML ; c'est comme si on livrait les sources d'un programme C/C++ après les avoir passés par le préprocesseur C. C'est certainement quelque chose qui devrait être amélioré, mais ce n'est pas évident à réaliser. Ceci dit, ça reste du XML, mais il ne sert qu'à remplir une registry interne. On peut parfaitement envisager de remplir cette registry à l'aide d'un autre format, comme JSON par exemple…Pour le XML relatif à l'interface, et celui des fichiers de configuration, j'espère que mes réponses ci-dessus sont assez claires (sinon, ne pas hésiter de me demander des précisions). Pour celui concernant l'API des backend, il s'agit juste d'un fichier intermédiaire, qui n'est pas utilisé lors de l'exécution de l'application. A l'origine, je générais directement le
.h, mais, en passant par le XML, cela ouvrait la possibilité de générer l'API dans un autre langage, en utilisant un autre fichier XSL.Inutile d'être désolé. Pour l'instant, tout ce que j'ai lu concernant les autres technos me renforce dans mon opinion que les miennes sont parfaitement viables et légitimes, en théorie du moins. Et c'est justement l'un des buts de l'appli présentée dans ce journal de les mettre à l'épreuve de la pratique.
Là encore, c'est un problème de packaging. Si l'application était correctement packagé, l'utilisateur ne serait jamais exposé à ces noms ; il aurait juste à cliquer sur l'une ou l'autre icône, auxquelles on pourrait donner un nom plus expressif. Mais, vu l'état de l'application, il me semble plus important de me concentrer sur le fond que sur la forme…
Bon, j'ai encore regardé sur le Web de quoi il s'agissait, et je ne vois vraiment pas en quoi cela s'applique à ce projet. Pourrais-tu fournir une définition de ce concept, pour être sûr que l'on parle de la même chose, et m'indiquer un exemple de ce qui, dans mes technos, te paraît y correspondre ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par groumly . Évalué à 4.
Tu optimise pour le mauvais problème.
Le développeur web, il va préférer faire du web. Il a ses outils, sa communauté, ses navigateurs.
Le développeur natif, il va faire du natif.
Le boite qui veut modifier un soft, elle a des développeurs en interne pour faire ca, ou elle sous traite.
Le fait que ca soit modifiable avec un simple éditeur de texte ne change rien au fait que le tooling est très important. Debugger/view inspector/logger etc. Tu enlève le compilo de la chaîne, cool, mais on a toujours besoin de ces autres outils. Au final, tu te retrouves avec le même problème sur le bras (cf mon point sur les compromis, le tien est tres mauvais ici).
Quel est l'intérêt de déployer une appli native basée sur des technos web, quand on a un browsers installé sur toutes les machines, ce qui élimine entièrement le problème du deployment/packaging etc? (À nouveau les compromis, tu te retrouves avec le pire des 2 mondes si tu part sur une techno hybride).
Dit autrement, tu résouds un problème qui n'existe pas.
Les customisations qui ne sont que purement cosmétique sont par définitions triviales, et donc à très faible valeur ajoutée. Optimiser pour ce cas est une perte de temps.
Les customisations non triviales vont requérir des ingénieurs (vs bien falloir écrire du code pour gérer telle ou telle fonctionnalité différemment), qui maîtrisent donc la technologie et qui n'auront aucun problème à compiler une appli.
L'accessibilité va plus loin qu'un simple problème de contraste. Jette un œil à ce qu'ios/OS X font dans ce domaine si tu me crois pas. Ca demande systématiquement beaucoup de taff, dans la conception même de l'appli, et dans son implémentation. Même sous iOS qui premache 90% du boulot pour toi, tu te retrouves à devoir écrire du code custom à droite à gauche. C'est pas quelque chose que tu greffes après coup en changeant un peu les vues.
Soit dit en passant, ca te fait pas un peu peur de ne pas avoir approfondi le sujet? Disons que c'est un point central de ta technos, comment peut tu prétendre avoir fait les bon choix si tu n'as pas d'idée précise des cas d'utilisation?
Ce que je dit, c'est que l'api en question, c'est du code. Écrit la en code directement, plutôt que de la decrire en xml pour ensuite générer du code. T'as rien à gagner à l'écrire en xml, c'est infiniment plus verbeux et casse gueule.
La philosophie sous jacente à ce genre de technos, c'est que ca permettait de générer des stubs client et serveur automatiquement. Sauf que depuis, on s'est rendu compte que c'est vachement plus simple et pratique de juste écrire le code. Les stubs ne servent à quasiment rien, et dans les rares cas ou ils servent, t'as plus vite fait de les générer à partir de l'interface écrite en code. Cf par exemple ce que fait Jersey qui te génère ton wadl à partir de l'appli.
Tu passes beaucoup de temps à construire une plateforme qui émule de façon très pauvre la plateforme sur laquelle elle tourne.
Le concept de backend par exemple: pourquoi introduire un tel système? Ceux qui veulent parler à un backend réseau le feront plus vite et efficacement avec une api rest, tout en ayant une plus grande latitude de choix technologiques.
Le html5: les développeurs auront plus vite faite de coder pour un navigateur plutôt que d'utiliser ta version. Au final, tu construit une plateforme qui émule la plateforme sur laquelle elle tourne, et n'apporte pas grand chose, à part des contraintes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 1. Dernière modification le 05 juillet 2016 à 11:53.
Et il y a un troisième type de développeur, dont je suis peut-être l'unique représentant aujourd'hui (j'espère que non), qui veut développer du Web, et du natif, tout en maintenant un seul et unique code commun aux deux (ce qui va faire l'objet d'un prochain journal, comme signalé dans celui-ci).
Outils qui sont familiers à n'importe quel développeur Web. Donc, si l'utilisateur ne veut pas se coltiner ces outils pour la modification de l'interface, il trouvera facilement quelqu'un pour le faire à sa place. En tout cas, plus facilement qu'avec une application native classique sur MacOS, iOS, Windows…
De pouvoir déployer la même application indifféremment dans sa version Web et/ou sa version native, sans rien modifier à son code. Bon, après, reste le vieux débat Web vs natif, mais qui, dans le cadre de mon appli. est sans intérêt, puisqu'on la déploie dans la forme que l'on veut.
L'interface de mon appli. est en HTML5. J'offre à l'utilisateur la possibilité de modifier ce code HTML5 à volonté sans avoir à solliciter le développeur de l'application, et, au pire, mais ce n'est pas indispensable, en sollicitant le développeur Web de son choix. C'est tout. Maintenant, il en fait usage ou non, c'est son problème ; simplement, la possibilité existe.
Non, ce n'est pas un point central, c'est juste un des avantages. Et ce que je n'ai pas approfondi, ce sont les possibilités de HTML dans ce domaine. Si elles ne sont pas encore suffisantes, il y a de fortes chances que cela se développe par la suite. Le cas échéant, ça sera à la portée de n'importe quel développeur Web d'adapter l'appli. Mais, encore une fois, cela dépend de HTML, pas de ma techno.
L'API en question contient du code, mais pas le code du backend. En gros, elle expose les objets gérés par le backend sous forme d'objets C++, et elle sérialise simplement les valeurs des différents paramètres des différentes méthodes de ces objets pour qu'ils puissent transiter via le canal de communication avec le backend. Et ça, c'est du code
chiemmpénible à écrire, donc je préfère que l'ordinateur le fasse à ma place (c'est l'un des buts de l'informatique, non ?). Il n'y a pas l'ombre du soupçon de code du backend dans cet API, ni d'ailleurs dans le XML qui est utilisé pour la générer. J'ai mis un lien dans le journal sur un fichier contenant une telle API, ainsi que sur le fichier XML correspondant ; tu pourras t'en persuader toi-même.Ma plateforme n'émule rien du tout. Une appli. native basée sur cette plateforme est, du point de vue de l'interface, une appli. Web, mais débarrassée de tous ce qui est relatif au réseau. Son interface est rendu par Chromium, mais dans une version débarrassée de toute l'interface nécessaire à la navigation Web. Et, coté traitement, on a tous les avantages du natif, c'est-à-dire qu'il n'est nullement besoin de passer par une couche REST ; on a accès directement au backend. Et cette plateforme permet de déployer la même appli en tant que qu’application Web, sans rien changer au code, et donc toujours sans avoir à recourir à une surcouche REST.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par xcomcmdr . Évalué à 2.
Chez MS, y'a XAML qui est utilsé par WPF, Silverlight, et les applications UWP (Universal Windows Platform)
Et il y a aussi Razor pour ceux qui font des sites Web avec ASP .NET
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Troll
Posté par arnaudus . Évalué à 4.
Si tu veux parler d'une séparation frontend/backend, ou client/serveur, ça existe quand même depuis très très longtemps sous une diversité de formes impressionnate. D'une manière générale, je pense que peu de gens contestent l'utilité de séparer les algorithmes du logiciel et l'interface utilisateur.
Après, qu'il faille recompiler la partie UI ou modifier le code pour modifier l'interface, ça dépend un peu du type de logiciel, mais ça ne me semble pas forcément primordial. J'ai du mal à voir ce que ça change en termes de maintenabilité du code, par exemple. Si tu as un code super-complexe qui te génème une interface graphqiue à partir de fichiers XML super complexes, tu vas avoir des bugs de partout, et il est très improbable de motiver les gens à apprendre le "framework". Typiquement, pour un logiciel libre, ça veut dire que tu te coupes de la possibilité de recevoir des patches ; un utilisateur ne va pas passer plusieurs mois à se former sur ton framework pour corriger un bug.
L'isolement technologie a un coût, spécialement pour du logiciel libre. Si tu utilises un binding gtk pour perl, tu as de grandes chances que beaucoup de bricoleurs puissent en un coup d'œil comprendre ce que tu fais. Par ailleurs, être capable de faire tourner ton soft sans passer 3 jours à installer l'environnement de travail peut aussi aider. Au contraire, si le saut technologique est important, cette première étape est rédibitoire. Par exemple, j'ai été faire un tour sur ton github, juste pour cliquer sur quelques fichiers C++ au hasard. Clairement, ton code C++ n'est pas du C++, c'est une sorte de dialecte du C++ qui repose sur des appels de macro dans tous les sens. C'est peut-être justifié, mais ma réaction, c'est "qu'est-ce que c'est que ce bordel, c'est même pas du C++ ce truc". Entre ça et le code généré, j'ai l'impression que comprendre la logique de ton framework nécessite plusieurs semaines de travail. Si en plus tu n'arrives pas à expliquer l'intérêt d'utiliser ce type de technologie, tu vas galérer pour trouver une base d'utilisateurs à mon avis.
Répondre de manière semi-agressive aux commentaires ne risque pas forcément d'aider non plus, d'ailleurs. Tu t'attendais peut-être à ce que les gens te répondent "c'est génial ton truc, comment personne n'y a jamais pensé avant", mais visiblement, s'ils te disent qu'ils n'ont pas compris et que ça ne leur paraissait pas spécialement nouveau ni même intéressant, ça n'est pas dans le but de te blesser. Si tu es dans l'état d'esprit de répondre "vous êtes tous des cons qui n'y connaissez rien", ça ne va pas être très constructif. Il ne faut pas non plus que ça bride ton entousiasme, si tu penses que ton truc vaut le coup, fonce. Mais n'oublie pas "eat your own dog food": Si ta techno permet de développer sans effort des logiciels super facilement, alors le mieux est de fournir ces logiciels toi-même, jusqu'à ce que les gens se demandent "mais comment ce type peut-il maintenir autant de softs de qualité?", ce qui les amènera sur le côté technique. L'approche inverse me semble au contraire très risquée, pusiqu'il est normal pour quelqu'un de sain mentalement de rejeter une nouvelle technologie sans avoir une bonne raison de s'y intéresser.
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 2.
La séparation frontend/backend, je l'avais implémenté à l'époque parce que ça me semblait une bonne idée. Vu tous les avantages que cela apporte, je me doute bien que je ne sois pas le seul à mettre en œuvre ce mécanisme, sans toutefois chercher à en savoir davantage à ce sujet. Je l'ai simplement mentionné à titre informatif, sans vouloir impliquer que cela soit une exclusivité de mon framework.
Le code pour générer l'interface n'est pas complexe en soi ; ce qui peut être complexe, c'est le code HTML/CSS, et éventuellement JS (sachant que l'on peut mettre du XHTML/CSS/JS directement dans le fichier XSL), mais cela dépend uniquement de ce que veut l'utilisateur. Les fichiers XSL fournis avec l'application ne contiennent que des instructions XSL relativement basiques. Quand au XML, il n'est pas complexe non plus, car il ne contient que les données, et quelques informations associées, destinées à être affichées.
Je n'essaye pas de mettre l'accent sur mon framework, d'autant plus qu'il n'est pas documenté (pas dans le sens 'documentation pas rendue publique', mais dans le sens 'documentation réellement inexistante'). Il se trouve que j'ai développé, et que je compte encore développer, quelques logiciels que j'ai placé sous licence libre, et qui me semblent donc parfaitement qualifiés pour faire l'objet de quelques journaux sur ce site. Maintenant, que les gens ne s'y intéresse pas, ou ne s’intéresse qu'au logiciel, ou bien s'intéresse au framework sur lequel ces logiciels s'appuient, c'est leur affaire, tout en étant bien conscient que mes lacunes en matière de communication ne facilite pas les choses, sachant néanmoins qu'il y a plus de chance que les gens s'y intéresse en communiquant mal sur le sujet, qu'en ne communiquant pas du tout. Si, malgré cela, des personnes sont intéressées par ce que je fais, je leur apporterais volontiers tout éclaircissement qui leur paraîtrait nécessaire.
Pour ce qui est de l'installation du logiciel, je suis parfaitement d'accord qu'elle est, dans sa forme actuelle, quelque peu rédhibitoire. Mais ce n'est pas dû à mes logiciels proprement dit, mais à CEF, sur lequel mes logiciels s'appuient dans leur version native. Pour Windows, j'ai essayé de simplifier l'installation en fournissant un package auto-suffisant. Pour les autre environnements, je voudrais pouvoir faire la même chose, mais je ne sais pas faire (ce qui ne veut pas dire que ce n'est pas possible). Tous les autres logiciels que j'ai publié et qui ne dépendent pas de CEF sont installés après décompression de l'archive en lançant simplement un
makeà la racine de l’archive. Je suis en train d'essayer de mettre en place la même procédure pour ce logiciel-ci, mais ça nécessite de se plonger dans les arcanes de CEF, ce qui prend du temps…Il ne me semble pas avoir répondu de manière semi-aggressive. Par contre, j'ai l'impression que mon refus de me plier à certains dogmes auxquels quelques personnes semblent attachées est vécu par ces dernières comme un affront… Comme je l'ai écrit plus haut, je ne m'attends à rien du tout en publiant ce genre de journal. Je suis développeur freelance, j'adore ça, et j’utilise mon framework pour développer les applications demandées par mes clients, qui en sont d'ailleurs très satisfait. En outre, j'utilise quotidiennement avec délice, professionnellement et à titre privé, plusieurs applications, dont certaines disponibles sur mon site, que j'ai développées et qui sont basées sur mon framework (donc, le dogfooding, je connais). Quelques soient les réactions à mes journaux, elles ne changeront rien à cela, ni d'ailleurs, rassure-toi, à mon intention de continuer à développer ce logiciel et d'autres, dont les évolutions feront l'objet de journaux ici même.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Troll
Posté par Claude SIMON (site web personnel) . Évalué à 3.
Pas la peine de sortir. Le fait est que, bien avant que l'on ne parle de HTML5, j'utilisais XUL pour mes interfaces graphiques. J'ai d'ailleurs écris ce journal à ce sujet. Pour le natif, j’utilisais XULRunner ; par contre, pour le Web, comme seul Firefox était capable d'afficher du XUL, je devais faire une version de l'interface en HTML pour pouvoir l'afficher dans d'autres navigateurs.
Ce que j'appelle XDHTML n'est en fait que ce que je faisais déjà avec XUL, mais en plus avancé, et avec HTML5. Avec l'avantage, cette fois-ci, de pouvoir utiliser le même code pour la version native et la version Web
Pour nous émanciper des géants du numérique : Zelbinium !
# Archi
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
Ton archi a beaucoup de similitudes avec celle de SàT (cf. http://www.goffi.org/post/2015/11/09/S%C3%A0T%3A-Comment-%C3%A7a-marche) et d'ailleurs les prises de notes, carnet d'adresses et autre agenda sont également envisagés/eables.
Bon je suppose que c'est un projet pour le plaisir de développer ta propre solution, et puis c'est du C++ quand on fait majoritairement du Python, donc bon courage et tiens nous au courant.
[^] # Re: Archi
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Peut-être que le logiciel a des similitudes avec SàT, mais le projet faisant l'objet de ce journal ne se limite pas à ce seul logiciel.
Ce n'est pas par plaisir de développer ma propre solution que je travaille sur ce projet, mais c'est pour développer une solution qui offre des possibilités qu'aucune autre n'offre.
J'ai étudié des solutions existantes, mais aucune ne répondait à mes attentes. Maintenant, si j'en ai loupée une, je veux bien que l'on me fasse la découvrir. C'est l'un de buts de ce journal, que l'on puisse m'indiquer si, et, le cas échéant, où je me fourvoie.
Pour nous émanciper des géants du numérique : Zelbinium !
# Un peu d'aide
Posté par barmic . Évalué à 6.
C'est à dire ? La qualité logicielle ça regroupe beaucoup beaucoup de choses : la performance, la consommation, la correction, la sécurité, l'utilisabilité, la scalabilité, la maintenabilité,… Ton framework apporte quoi exactement dans ce contexte.
Je pense que manipuler du XML (ni même du HTML) ne fait pas rêver les gens… Tu n'a pas un hello world en quelque dizaines de lignes ?
À chaque fois que l'on parle d'Haiku, il y a quelqu'un pour nous vanter le modèle d’exécution des applications graphiques de BeOS avec un thread dédié à l'interface. Est-ce que c'est l'approche que tu suis ?
Sortir HTML du triptique HTML/CSS/JS me paraît un peu bancale. HTML réussi surtout grâce à son écosystème. Si c'est pour avoir des interfaces déclaratives, on a déjà ce qu'il faut en natif.
Merci de partager ton projet et bonne chance pour la continuation :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un peu d'aide
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Quand j'ai écrit ce framework, ce n'est pas parce que j'étais insatisfait de la qualité des logiciels produits de manière classique. La qualité dont je parle est celle perçue par mes clients et dont ils me font part. J'ignore lesquels des points que tu cites ils prennent en compte dans leur opinions qu'ils ont des logiciels que je développe pour eux. Quand à moi, en tant que développeur, je trouve que les bugs de jeunesse sont facilement corrigés, que je n'ai pas de difficulté particulière à faire évoluer mes logiciels, et que la maintenance requiert peu d'efforts. Ceci dit, j'ai peu d'éléments de comparaison, ayant quasiment toujours travaillé uniquement avec mon framework.
Le framewok en question, ça reste un framework C++ ; il n'y a pas de nouveau langage, ou de méta-langage. Donc, un Hello world ! ne différerait pas de manière significative avec la version écrite en C++ standard.
Pour ce qui est de Haïku, je ne connais pas donc je ne saurais dire. Si similitude il y a, elle serait totalement fortuite.
Je sais que je sors des sentiers battus (on me l'a suffisamment fait remarqué dans le journal sur XUL mentionné ci-dessus, d'ailleurs avec le même genre de remarque, mais sur le diptyque XUL/JS) ), mas ça ne m'a pas trop mal réussis jusqu'à présent.
Quoi qu'il en soit, merci pour tes encouragements !
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Un peu d'aide
Posté par barmic . Évalué à 4.
Sans chercher une nomenclature préétablie c'est dommage de ne pas en savoir un peu plus.
Je ne suis absolument pas d'accord avec ça. Il y a, en particulier en C++, pleins de façon de designer ton API : en utilisant juste des patterns objet, en utilisant passivement la métaprogrammation, en utilisant des lambdas, de manière totalement impérative,… Rien qu'en Java, qui est nettement moins expressif, il y un de très grosses différences de design entre des API proches. Après par Hello world j'entendais un programme qui affiche une fenêtre avec un widget ou 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un peu d'aide
Posté par Claude SIMON (site web personnel) . Évalué à 0.
Je ne peux pas être plus précis ; n'ayant quasiment jamais utilisé d'autres framework que le mien, je ne peux pas dire en quoi il se distingue. J'ai juste un jour commencé à coder quelques bibliothèques, regroupant des fonctionnalités que j'utilisais souvent, bibliothèques que je modifie, lorsque c'est nécessaire, pour les rendre plus faciles à utiliser et/ou plus performantes. Puis je leur ai rajouté d'autres bibliothèques, qui prenaient en charge d'autres fonctionnalités que j'avais été amené à implémenter au grès des différents développement que j'ai réalisés, histoire de pouvoir disposer de ces fonctionnalités sans avoir à les réimplémenter. Et c'est l'ensemble de ces bibliothèques qui constitue mon framework. Je n'ai pas cherché à mettre en œuvre des techniques particulières ; la forme que prend l'API est juste celle que je trouve la plus pratique à l'usage. Et la terminologie ci-dessus ne m'est pas suffisamment familière pour pouvoir dire si elle s'applique ou non à l'API de mon framework…
Pour ce qui est du "Hellow World!", c'est un peu le but du logiciel présenté dans ce journal, dans son état actuel, vu le peu de fonctionnalités qu'il implémente. Sinon, pour ce qui est de la technologie que j'appelle XDHTML et qui se concentre sur l'interface graphique, il y le logiciel que je présente à cette adresse : http://q37.info/computing/epeios/apps/xdhdq/.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Un peu d'aide
Posté par barmic . Évalué à 4.
Je suis sûr que si, par exemple tu sais que tu fais des templates quand tu en fait (quand tu utilise
<>).Globalement pour me donner envie de lire les 50k SLOC (Source Lines Of Code) de code que constitue ton xdhdq, il faut quelque chose qui parle un peu plus aux gens. Moi perso je ne développe pas en C++ depuis pas mal de temps, j'ai pas un grand plaisir à bouffer autant de code.
De l'autre coté c'est dommage de ne pas s'intéresser à l'existant parce que ça constitue une source d'inspiration importante.
Personnellement je n'appellerais pas xdhdq un hello world. C'est plus une vitrine. Le hello world, c'est le code minimal qui permet d'utiliser le cas nominal de ton framework. Par exemple c'est ce qui permet d'avoir une fenêtre avec un bouton dessus et quand tu clique dessus le bouton change de couleur (ou le texte change). Je présume que ça tiens en 3 fichiers C++ et 2 fichiers XML/XSL.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un peu d'aide
Posté par Claude SIMON (site web personnel) . Évalué à 0. Dernière modification le 04 juillet 2016 à 17:57.
Étant donné que c'est quand même du C++, je pense que la présence de templates n'a rien de surprenant…
En fait, les prémices de mon framework datent d'une vingtaine d'année. A l'époque, je voulais utiliser la STL, mais il était fortement déconseillé dans la documentation de l'utiliser en production. Du coup, j'ai développé mes propres bibliothèques. Après, j'ai regardé l'existant, mais sans aller jusqu'à regarder les détails de l'implémentation, vu que, globalement, cet existant ne m'apportait rien de plus que ce que je n'avais déjà avec mon framework…
Là, j'avoue, j'ai fauté. Le fait est que, lorsque je démarre le développement d'une nouvelle application, je lance un script qui me met en place une application avec quelques fonctionnalités de base. Ainsi, la première page de l'application permet, soit de créer un nouveau projet, soit de sélectionner l'un de ceux prédéfinis dans le fichier de configuration, soit d'ouvrir un fichier contenant un projet. La seconde page, dont le contenu est conditionné par le choix fait à la première page, permet, soit de continuer sans backend, soit d'en sélectionner un parmi ceux prédéfinis dans le fichier de configuration (ou du projet), soit de charger directement la bibliothèque dynamique correspondant au backend, soit encore de saisir l’adresse et le port du backend auquel l'application doit se connecter. L'essentiel du code de cette application correspond en fait à la gestion des ces fonctionnalités. Les fichiers C++ et XSL correspondant aux fonctionnalités au cœur de l'application sont ceux commençant par
Fields(un.h, un.cpp, et deux.xsl).Pour nous émanciper des géants du numérique : Zelbinium !
# XML + XSLT ? => Pan !
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 3.
On a quand même inventé mieux que XML et XSLT pour transformer des données avec un modèle depuis une bonne dizaine d'années !
Personnellement, j'ai toujours pratiqué XSLT en croisant les doigts, par essais et erreurs, alors que j'ai utilisé d'autres moteurs de templates sans avoir à réfléchir plus que ça…
[^] # Re: XML + XSLT ? => Pan !
Posté par Claude SIMON (site web personnel) . Évalué à 2.
L'avantage de la transformation XSL, c'est qu'elle est implémentée nativement sur la plupart des navigateurs (en tout cas, les plus populaires). C'est un élément clef dans la technologie que je présente dans ce journal.
Sinon, peut-être parce que je l’utilise quotidiennement depuis de nombreuses années, mais je n'ai aucune difficultés avec XSL ; il faut dire que, probablement parce que j'ai toujours un contrôle total sur le flux XML entrant, je n'utilise que des fonctionnalités relativement basiques.
Pour nous émanciper des géants du numérique : Zelbinium !
# anti-pattern NIH
Posté par steph1978 . Évalué à 4.
Je vais redire un peu ce qui transparaît déjà dans les autres commentaires mais tant pis.
Je ne sais pas exactement quel est le but que tu poursuis. Mais en publiant à propos de ton projet, j'imagine que tu souhaites une certaine adhésion/contribution.
Je ne sais pas ce que tu mets derrière qualité ?
J'ai l'impression que tu t'ai focalisé sur la dernière option.
Je ne crois pas - et c'est un avis purement personnel - au logiciel parfait.
Je suis pour une approche beaucoup plus pragmatique/agile:
Là tu vas mettre des années à fournir quelque chose que tes potentiels utilisateurs auront déjà trouvé (ou appris à se passer) depuis longtemps…
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . Évalué à 0. Dernière modification le 05 juillet 2016 à 18:06.
Je suis en train de développer un Logiciel Libre, que je présente ici à titre de démonstration de certaines technos, en attendant que le logiciel soit suffisamment avancé pour présenter un intérêt en lui-même. Ces technos sont incluses dans un framework, et je compte les réutiliser à travers ce framework (je les utilise d'ailleurs déjà) pour développer d'autres logiciels, ceux de mes clients, mais également des logiciels pour mon propre usage, auquel cas je placerais ces derniers sous licence libre, et ils feront probablement l'objet d'une publication sur ce site, à l'instar de ceux que j'ai déjà publiés.
En publiant ce journal, je n'attends rien en retour, mais s'il y a des retours, je les étudierais attentivement, comme je l'ai fait pour les commentaires publiés jusqu'à présent, et cela quelque soit la nature de ces retours.
Quant à la qualité auquel je fais référence, c'est celle, comme je l'ai déjà écrit, perçue par les utilisateurs de mes logiciels et dont ils me font part au travers de leurs retours. Même si certains autres critères qualitatifs sont importants, ils demeurent néanmoins secondaires face à ceux qui conditionnent la satisfaction des utilisateurs.
Quand aux principes que tu listes, ça correspond, grosso-modo, à ma pratique professionnelle. D'ailleurs, je ne vois pas ce qui, dans ce journal ou ailleurs, suggère que cela puisse ne pas être le cas. Et, plus précisément, j'ai déjà développé pour mes clients et livré des applications qui mettent en œuvre ces technos, et les retours que j'en ai sont excellents. Mais comme je ne peux pas publier ces applications, et que j'ai, en outre, envie de pousser ces technos dans leurs retranchements, j'ai commencé à développer l'application qui fait l'objet de ce journal.
Avec ce journal, et certains autres que j'ai publiés, j'ai remarqué une certaine hostilité envers mes technos, probablement parce qu'elles vont à l'encontre de certains dogmes. Mais, ni dans ce journal, ni dans aucun autre, malgré les tentatives répétées de certains, personne n'a réussi à mettre en défaut mes technos d'une quelconque manière. Tant que cela demeurera le cas, je continuerais à développer et à présenter des logiciels basées sur ces technos, et tant pis pour ceux qui les rejettent. Ce qui ne signifie pas que je ne suis pas ouvert à la critique, car je n'ai pas la prétention d'avoir crée quoique ce soit de parfait…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par steph1978 . Évalué à 6.
Quand le client d'un plombier est content, c'est parce qu'il a l'eau chaude et l'eau froide à tous les étages et pas de fuites. Et pas parce que le plombier a une belle caisse à outils et sait se servir du chalumeau.
C'est donc bien la capacité à délivrer des fonctionnalités qui ressort, et la maintenabilité. Et tu sembles avoir ces capacités.
La difficulté ici c'est que tu ne peux pas nous présenter tes réalisations et ne peux nous montrer que la caisse à outils. D'où un moindre transport de ma part…
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . Évalué à 1.
C'est tout à fait cela ; tous les logiciels développés à l'aide de cette boîte à outils ont été financés pas mes clients, et je n'en dispose donc pas librement, d'où l'impossibilité des les publier. De ce fait, j'ai commencé, à titre personnel, le développement du logiciel présenté ici. Comme je l'ai indiqué dans le titre, ce n'est que le commencement. Les toutes prochaines versions porteront sur la consolidation des mécanismes de base (version Web, développement de plugins relatifs à de nouveaux types de champs…), ainsi que sur l'amélioration du packaging, afin de faciliter le déploiement du logiciel par toute personne qui s'y intéresse. Puis seront, petit à petit, développées les fonctionnalités qui permettront à ce logiciel de remplir les objectifs que je lui ai fixé, objectifs qui pourront évoluer en fonction des suggestions de ceux qui l'auront testé (ce qui devrait prochainement être facilité par la mise en ligne d'une version de démonstration).
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par benoar . Évalué à 4.
Arrête ton char, il n'y a pas de cabale contre toi…
Tout n'est pas affrontement. Je pense juste que déjà plein de gens n'arrivent pas à comprendre l'intérêt de ton « truc ». J'aime bien XML/XSLT, mais pourtant je reste dubitatif devant ta tonne de code qui ressemble vraiment à un « inner-platform effect », comme cité plus haut. Tu vas peut-être mal le prendre, mais peux-tu nous dire quelle est ton expérience en code avec différentes technologies ? Vu que tu dis à chaque fois ne pas avoir comparé avec d'autres, je suppose que tu as peu d'années de pratiques.
Essaye cet exercice : résume en trois courtes phrases quel est le but de ton « projet ». Se perdre en route sur le « comment », ça arrive, mais là tu le fais avec une force certaine.
Il n'y a pas de problème à présenter ton travail, c'est juste que là ça fait vraiment « hermite persécuté » que personne ne comprend. Et bien ce n'est peut-être pas la faute des autres si personne n'y comprend rien, peut-être que tu devrais essayer de faire l'effort de comprendre pourquoi ton logiciel est si mal accueilli.
[^] # Re: anti-pattern NIH
Posté par benoar . Évalué à 3.
Bon, je viens de voir tes autres journaux, à priori ça fait un bout de temps que t'es dessus, sans avoir regardé ailleurs… Tu dois donc réellement être un hermite persécuté ; désolé de la méprise. Mais bon courage alors si tu veux attirer du monde sur ta techno.
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . É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.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par benoar . Évalué à 4.
Le fait que tu réinventes des choses qui existent déjà ? Le fait que tu crées une autre abstraction qui apporte peu de choses, et qu'il est souvent plus important d'utiliser des standards que de créer de nouvelles couches ? Je ne fais que reformuler ce qu'on t'a déjà dit.
Je pense qu'en fait tu ne vois pas ça comme des désavantages car tu considères juste ton programme pour toi, et pas à destination des autres, du coup tu ne vois pas de problème. Je pense que le problème principal est que tu ne comprends pas les choses qui sont nécessaires à l'utilisation de tes logiciels par d'autres. Rien que le fait d'avoir des noms abscons… je ne sais pas si tu te rends compte du coup que quand je lis ta prose, je ne sais même pas à quoi tu fais références à chaque fois que tu cites un logiciel. Du coup, ça décourage à aller plus loin.
Tu es fort en méta-blague…
Une suggestion là-dessus : ne mets pas les fichiers générés dans ton VCS. On comprendra mieux ainsi quels sont les fichiers générés par un humain. Enfin, ce que je crois être généré par un humain. Ensuite, si tu utilisais un système de build un peu plus standard… C'est des Makefile, mais avec plein de trucs spécifiques à toi.
En fait, ton problème c'est les standards, je pense : tu as plein de trucs idiosyncratiques, tu ne réutilises jamais ce qui existe déjà. Même pour les traductions, tu n'utilises pas gettext. Pour le système de build, tu aurais pu utiliser les autotools, par exemple. Ensuite, ton xppq, j'étais vraiment intrigué, j'ai regardé, et je n'ai pas compris la différence avec XSLT (xpp:define c'est xsl:variable, xpp:expand c'est xsl:value-of, xpp:attribute c'est xsl:attribute, etc). Et ton dans framework epeios, tu as même réimplémenté les dates, soit une erreur absolument rédhibitoire pour n'importe quel programmeur qui se vaut ! Bref, tes technos ne sont pas intéressantes car elles ne sont pas standards. Ça va sûrement te sembler bête comme critique, mais c'est absolument essentiel : si tout le monde faisait comme toi, l'informatique n'avancerait pas.
C'est ça qui est frustrant : ça a l'air un peu intéressant, mais je n'arrive pas à te comprendre.
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . É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 !).
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par GuieA_7 (site web personnel) . Évalué à 4.
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.
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.
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.
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . É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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Tu veux qu'on te pose des questions techniques pour faire avancer le débat, et quand on t'en pose tu ne te souviens plus des aspects rédhibitoires des autres bibliothèques (tips: ça aurait été cool de le noter dans les commentaires de code). Je n'ai jamais déprécié ton code, en revanche tu en fais une très mauvaise promotion ; je comprends que faire de la pub n'est pas ton fort (c'est aussi mon cas), mais en tant qu'outsider, si tu veux que les gens investissent du temps sur ton code (plutôt qu'utiliser les libs déjà éprouvées) il va falloir plus que des banalités du genre "développer rapidement des applications de qualités".
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . É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…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: anti-pattern NIH
Posté par benoar . Évalué à 2.
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.
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.
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.
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.
Ah, intéressant, je n'avais pas vu cette fonctionnalité.
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)
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.
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.
Bon courage quand même dans ta voie.
[^] # Re: anti-pattern NIH
Posté par Claude SIMON (site web personnel) . É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.
Pour nous émanciper des géants du numérique : Zelbinium !
# Le prochain épisode est paru :-).
Posté par Claude SIMON (site web personnel) . É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.
Pour nous émanciper des géants du numérique : Zelbinium !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.