Claude SIMON a écrit 555 commentaires

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

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

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

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

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

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

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

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

Merci !

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

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

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

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

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

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

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

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

sRow Row = C.First();

while ( Row != qNIL ) {
 // Traitement sur C( Row ).

 Row = C.Next( Row );
}

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

https://github.com/epeios-q37

« Smart IoT Crafting » : l'IoT pour tous

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

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

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

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

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

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

Contenu de la note avant chiffrage :

# Test encryption

Ceci est le contenu à encrypté.

## un titre markdown
### un autre titre markdown

Un *peu* de :

- **mise** en 
-  forme.

et après chiffrage :

# Test encryption

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

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

« Smart IoT Crafting » : l'IoT pour tous

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

« Smart IoT Crafting » : l'IoT pour tous

On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?

Les applications web, c'est le même principe, me semble-t-il. Faudrait-il donc les bannir également ?

« Smart IoT Crafting » : l'IoT pour tous

D'après wikipedia :

Electron est un framework permettant de développer des applications multi-plateformes de bureau avec des technologies web (JavaScript, HTML et CSS).

Donc, à priori, ça ne paraît pas illogique qu'il s'appuie sur un navigateur web.

Partant de là, si j'ai bien compris, ceux qui sont réfractaires à Electron, ils le ne sont pas à Electron en lui-même, mais, de manière général, au principe d'utiliser des technologies web pour développer des applications bureau (ou Android). Me goure-je  ?

« Smart IoT Crafting » : l'IoT pour tous

Du coup, Atom va-t-il être abandonné, vu qu'ils ont déjà VS Code ?

« Smart IoT Crafting » : l'IoT pour tous

Juste par curiosité, c'est quoi le problème avec Electron ?

Ce n'est pas la première fois que je vois des commentaires suggérant qu'Electron présente quelques défauts rédhibitoires, mais sans préciser lesquels. Et, vu la note du commentaire, ça à l'air d'être un avis assez répandu.

Je l'utilise (pas de manière classique, il est vrai), ainsi que des logiciels qui s'appuient dessus, et je dois avouer que je ne vois pas trop quel est le problème avec Electron…

« Smart IoT Crafting » : l'IoT pour tous

Ça fait quelques temps que je cherche à remplacer Zim. Je l'avais sélectionné à l'époque parce que c'était le seul que j'avais trouvé avec lequel on peut hiérarchiser les notes, mais j'ai toujours eu du mal avec son système de mise en forme.

En soit, le système n'est pas mauvais, mais je comme je ne saisissais pas souvent de nouvelles notes, je me mélangeais toujours les pinceaux avec le balisage de Zim et celui de DokuWiki, que j'utilise nettement plus souvent.

Par ailleurs, comme j'utilise de plus en plus souvent markdown, j'ai cherché un logiciel de prise de notes qui utilise ce format. J'ai essayé Joplin et Boostnote, mais il leur manque à tout deux la hiérarchisation des notes. Mais là, je viens de découvrir QOwnNotes.

Je viens de l'installer ce matin, donc je n'ai pas beaucoup de recul. En ce qui me concerne, il me convient à priori, car les notes sont en markdown, et, bien que ce soit un peu caché, il semblerait qu'on puisse hiérarchiser les notes.

Quand aux desiderata du posteur :

• on peut exporter des notes, mais apparemment juste une à la fois,
• il y a un menu d'importation de notes Evernote,
• on peut chercher dans le corps des notes,
• tri alphabétique ou par date,
• il y a des boutons de mise en forme,
• pas de version pour mobiles, mais prend apparemment en charge ownCloud et NextCloud.

Je n'ai pas encore eu le temps de faire le tour de l'application, ni de faire des tests poussés, donc ce que j'ai écris est à prendre avec des pincettes.

« Smart IoT Crafting » : l'IoT pour tous

Le site à été un peu modifié, surtout la homepage, pour fournir un meilleur aperçu, dés la première page, de ce en quoi consiste le projet. Il peut être nécessaire de recharger la page (CTRL-F5) pour voir les modifications…

« Smart IoT Crafting » : l'IoT pour tous

Salut,

Salut !

Tu as toute mon oreille, mais pour commencer, il n'y a pas de code sur la doc (allé jusqu'à la section 4). Un exemple ? Comment ça s'articule ? Regarder un long main.js n'aide pas, et voir des fichiers .xls n'ai pas encourageant.

Le code des exemples se trouvent dans les repository dont on trouve les liens sur la homepage. Cependant, ayant fait peu de Java/JavaScript/PHP, et c'était il y a longtemps, il y a probablement moyen de rendre le code des exemples plus compréhensible. C'est typiquement le genre de retour que j'aimerais avoir de la part de personnes développant dans l'un de ces langages.

J'ai ajouté unes petite section sur la structure d'une application basée sur le toolkit Atlas. Et c'est des fichiers .xsl, pas .xls :-), mais j'y reviendrais plus tard.

Ces infos importantes que je cherchais apparaissent tard (section 2): c'est pour écrire des SPA, il y a un binaire C++, on doit qd même avoir node.js (aïe, mais voyons), l'interface est en fait Électron (…mmh. Autant dire qu'on peut envoyer sur Électron facilement), il y a un client et un serveur.

Je ne voulais pas être trop technique dés la première page ; ceci dit, j'y parle déjà de SPA. Quant au fait qu'il y ai un binaire C++ (en fait, il y en a même plusieurs), c'est juste pour justifier certains choix en terme de packaging, dont l'utilisation de Node.js. En outre, le serveur web est actuellement basé sur Node.js.

Le problème, c'est que je ne connais actuellement pas suffisamment les outils entourant PHP ou Java pour, d'une part, packager le toolkit, surtout les binaires, juste en utilisant les outils propres à chaque langage, et, d'autre part, mettre en place un serveur web sans procédure d'installation compliquée. C'est pour cela que j'utilise Node.js pour le serveur web, et le package manager de Node.js, à savoir NPM, pour packager le toolkit. Mais, à terme, Node.js ne sera plus nécessaire pour les bindings Java et PHP (et les autres langages qui seront pris en charge à l'avenir). Évidemment, pour le binding Node.js, Node.js sera toujours requis, puisque c'est la finalité de ce binding…

Avant d'utiliser Electron, je m'appuyais sur CEF (et même avant cela, pour ce qui n'était encore que les prémisses de ce qui allait devenir le toolkit Atlas, XULRunner), mais Electron est beaucoup plus facile à déployer que CEF, et plus populaire. J'aurais aussi pu utiliser les composants dédiés à l'affichage de contenus web de bibliothèques comme GTK(+)/Qt/wxWidget/…, mais le déploiement aurait aussi posé problème. À terme, Electron sera mis en œuvre de façon à ce que le développeur ne remarquera même pas que c'est ça qui est utilisé. Déjà maintenant, le développeur n'interagit pas directement avec Electron…

Quant à l'architecture client/serveur, c'est ce qu'il y a de plus simple pour faire communiquer Electron ou le serveur web, qui est basé sur Node.js, avec un logiciel Java ou PHP. Bien qu'il soit intéressant de pouvoir garder cette configuration, la communication se fera peut-être, à terme, également via d'autres canaux…

Je n'ai pas compris si on édite les fichiers xls. Perso, e n'ai jamais approché xlst, je t'invite à expliquer un peu plus dans ta doc.

Comme dit, c'est XSL(T), pas XLS(T); rien à voir donc avec le format Microsoft :-).

En fait, j'aurais pu utiliser un autre moteur de template, comme ceux utilisés dans certains framework JavaScript, mais l'avantage avec XSL, c'est que c'est implémenté dans la plupart (totalité?) des navigateurs web graphique (et dans Electron), donc la transformation est réalisée coté client, en n'ayant rien à installer, tout en pouvant être réalisée coté serveur si nécessaire.

Le principe est de créer un arbre (ce qui est facilité avec l'objet Tree du toolkit Atlas) contenant les données à afficher, et de générer le HTML à afficher dans le navigateur/Electron en appliquant une feuille de style XSL sur l'arbre en question. La structure de l'arbre est totalement libre ; on organise les données absolument comme l'on veut. Si les données sont issues d'une base de données, la structure de l'arbre reflète généralement celle de la base de données. Maintenant, bien que XSL ne soit pas très populaire, la documentation sur le sujet ne manque pas, écrites par des personnes bien plus compétentes sur le sujet que moi. Cependant, s'il y a des points précis qui ne sont pas clairs dans les fichiers XSL fournis avec les exemples, je les expliciterais bien volontiers.

Pas clair pour moi: est-ce que le site a été écrit avec ? Y a-t-il une sorte de routeur (pour avoir de belles urls) ? Dans la démo le filtre est "statique", on doit appuyer sur entrée, est-il possible d'en avoir un dynamique ? (type select2, ajax-based)

Le site est basé sur un CMS qui se contente de servir des pages écrites en markdown.

Il n'y a pas de routeur. D'après ce que j'en ai compris, cette notion de routeur est surtout associée à l'architecture MVC, mais comme je n'ai pas approfondi le sujet, ma compréhension de la chose est très parcellaire. En tout cas, je n'en ai pas vu l'utilité, donc cela n'est pas implémenté, tout en n'excluant pas la possibilité d'une implémentation future, le jour ou j'en aurais compris tout les tenants et aboutissants.

Honnêtement, j'ai fait au plus simple, mais avoir un filtre dynamique devrait déjà être possible. Cependant, je réfléchis à une solution ou le filtre ne se déclencherait pas en cours de saisie, mais un court délai après que l'utilisateur ai saisi le dernier caractère.

Dans la démo j'ai cliqué sur Create, j'aurais bien eu un bouton retour (pas d'intégration avec le navigateur ?), j'ai mis du tps à voir Cancel, tout en bas. Dans un TodoMVC généralement on peut marquer une tâche comme faite, pas vu ici.

Je n'ai pas trop compris l'histoire de l'intégration au navigateur. Je suis d'accord que la démo n'est pas très ergonomique, mais mes compétences en HTML et CSS ne me permettent de faire guère mieux (contributeu(rs/ses) bienvenu(e)s…). Mais attention, la démo en ligne n'est pas celle du TodoMVC. À l'époque où j'ai commençais à écrire une démo, je ne connaissais pas le projet TodoMVC. J'en ai donc écris une en m'inspirant vaguement d'un truc que j'ai trouvé sur le web. Je n'ai écrit les versions de l'application TodoMVC que plus tard, pour que les gens puissent avoir un élément de comparaison (ce qui est le but du projet TodoMVC), mais je ne voyais pas l'intérêt de la mettre en ligne, vu qu'elle fait exactement ce que font les version présentes sur le site du projet TodoMVC et dont on peut facilement voir une démonstration en ligne…

Je vais regarder et viens donner des nouvelles dans un moment :)

Merci déjà de ce premier retour, et je suis bien sûr preneur de tout autre à venir…

ps: ah mais oui, le "hide descriptions" est dynamique lui ! J'aurais bien vu un filtre dynamique, de suite ça claque plus.

J'ai spécialement mis cette case à cocher pour que justement on comprenne que la page n'est pas régénérée à chaque action. C'était plus simple à mettre en œuvre que le filtre dynamique, mais je vais réfléchir à l'implémentation de ce dernier.

« Smart IoT Crafting » : l'IoT pour tous

Dans ton message, la première ligne de ton code c'est :

<ul>

Il faut simplement la remplacer par :

<ul style="letter-spacing: normal;">

(l'attribut avant le > fermant, pas après…).

C'est le plus simple. Dans ce cas de figure, passer par une classe n'apporte vraiment pas grand chose…

« Smart IoT Crafting » : l'IoT pour tous

Le problème, c'est que le code ci-dessus est imbriqué dans un div sur lequel est appliquée une classe CSS nommée pure-g-r. Or, cette classe, définie dans https://cdnjs.cloudflare.com/ajax/libs/pure/0.3.0/pure-min.css, fixe letter-spacing à -.31em, d'où l'apparence du texte. Une solution serait de placer un attribut style="letter-spacing: normal;" directement dans le code ci-dessus, par exemple dans l'élément ul, ou alors de définir dans un fichier CSS une classe définissant cette même propriété et de l'appliquer à ce même élément ul. Je suis plutôt un béotien en matière de CSS, donc je ne garantis pas que ce soit la bonne façon de procéder pour résoudre ce genre de problème…

« Smart IoT Crafting » : l'IoT pour tous

M'est avis que Zobzob a quand même de de bonnes chances de se réveiller à temps, parce que l'araignée, aussi maligne soit-elle, n'a absolument aucun repère pour pouvoir suivre précisément la bonne trajectoire. Sauf pour le dernier, elle doit parcourir chaque segment, soit en visant un point situé à une certaine distance de son coin le plus proche, soit en suivant un angle déterminé. Je n'ai pas fait le calcul, mais, l'un comme l'autre ont l'air d'avoir des valeurs difficiles à suivre au jugée. Pas sûr qu'elle parvienne à suivre la trajectoire en restant dans la marge d'erreur lui permettant d'arriver à temps. Ceci dit, si elle est équipée d'un télémètre laser, par exemple, c'est tout à fait jouable…

« Smart IoT Crafting » : l'IoT pour tous

Bien sûr que si, sauf que ce savoir, je l'ai acquis et je m'en sers en-dehors du cadre de Marp (comme, par exemple, la rédaction de contenus pour ce site), alors que le savoir que j'aurais à acquérir pour me servir d'Impress ne me servira que pour Impress, ou, au mieux, pour d'autres logiciels du même type (PowerPoint ?)…

« Smart IoT Crafting » : l'IoT pour tous