Il y a les deux styles :
- Soit des histoires où tu choisis les éléments au début, puis tu écoutes sans intervention
- Soit une histoire avec des embranchements à choisir en cours de route
Sur le Luniistore, il y a encore deux autres catégories de pack : des quizz et des musiques.
Disons qu'il y a un nombre limité de combinaisons ; par exemple le pack d'histoires de sorcières que j'ai acheté dure 1h30 et permet de composer 18 histoires différentes.
Pareil, encore des gens qui restent bloqués dans le passé. Moi systemd je ne peux plus m'en passer, en deux lignes je crée des deamon et je automount des disques, j'adore. Je gagne un temps fou avec mes clients.
Je n'ai pas bien saisi ton introduction ; c'est peut-être moi qui ne pige pas bien, mais les technologies que tu présentes sont complémentaires aux framework front-end. On ne peut pas les comparer. Leurs grandes forces sont effectivement la gestion des templates, le routage, le binding des données, la modularité du code en composants et la gestion centralisée des données (flux) … mais pas de savoir faire du dessin sur un Canvas ?
Donc ton article bien qu'intéressant en soit est un peu troublant ; par exemple on pourrait faire également tout ça en SVG !
Hormis cela, j'aime bien ton essai en WebAssembly ; ça donne quoi le draw.js généré ? Je suis développeur C++ et ça me permettrait de réutiliser du code …
Cette architecture est intéressante car elle rend le code serveur C++ agnostique ;il devient serveur TCP/IP générique et on peut imaginer une foule de clients pouvoir se connecter dessus, quelque soit le langage ou la technologie. Not only HTML …
Personnellement, pour le projet d'un client, j'ai choisi de faire toute l'interface Web côté navigateur avec Vue.js, le serveur en C++ ne se contentant que de fournir une API REST en JSON. Du coup, ça fait beaucoup moins de bazar à gérer du côté C++…
Côté serveur, j'ai choisi le micro serveur CivetWeb largement suffisant pour mon application embarquée, sur lequel j'ajoute une petite surcouche C++ (fournie, en partie d'ailleurs).
C'est ce qui est fait sur le Linky, seul le nouveau code est présent normalement en mémoire externe. Et il y a 30 millions de compteurs. On envoie le stagiaire lancer l'upgrade et on tremble en regardant les stats de re-connexion monter doucement…
Chouette projet, je ne pense pas en avoir l'usage sauf peut-être comme tablette de contrôle domotique que je placerais à l'entrée. Du coup il faudrait pas mal de place autour des ports USB pour placer les divers dongle Zwave et RF. Je serais toi je ferai un intérieur encore plus modulaire pour s'adapter à plusieurs form factors de cartes. Un système de plaques crantées et prédécoupées.
Bref, moi mon besoin assez récent est un NAS libre, refroidissement passif ; tu voudrais pas faire une version ? Un belle mécanique, et trouver la bonne carte (car le raspb, bof bof il n'a pas de SATA).
Non c'est pas un débat, c'est nul d'attendre 5 secondes pour afficher du texte, point barre. C'est une grave erreur de design. Perso la première fois je croyais que le site avait planté et j'ai fermé l'onglet.
C'est simple, tu ne veux pas comprendre deux problématiques majeures, qui te paraissent mineures pour toi mais que la majorité des entreprises / développeurs prennent en considération :
tu mélanges tout dans le back-end. Demain tu changes de techno, t'es coincé, tout est à jeter. Et tu as un gros risque de tout faire péter à la moindre modification. Tes exemples simples sont naïfs : ils fonctionnent, mais pas lorsque l'application est gigantesque et que tu as 20 développeurs. Personne ne veut plus travailler comme cela. On veut des composants, des couches de liaisons, des interfaces agnostiques etc…
Les performances : il faut faire travailler le client, pas le serveur. L'avancée du JS et de ce genre de designs c'est génial pour des développeurs C/C++ embarqués comme moi, ça soulage le processeur et tu peux sous traiter le HTML/JS/CSS de merde à quelqu'un d'autre, et garder pour toi la noblesse et l'élégance du C embarqué.
Ok, de mon point de vue c'est une très mauvaise architecture.
Mon serveur "back-end" n'a pas une once de HTML, et il ne veut même pas savoir que c'est un site web qui demande des choses. Tout est en REST, et ça renvoie du JSON. Demain, c'est une application Android, un démon en C ou un script bash qui lancera des requêtes. Peut importe.
L'avantage des nouveaux frameworks est qu'ils intègrent un routeur côté client, c'est vraiment le truc super important : ainsi, le découpage "rendu" et "données" est parfait. J'ai développé 100% de mon appli web dans aucun backend, que du JSON fake, avec plein d'écran différents.
J'ai commencé à me mettre à Vue.js dans le cadre "embarqué" (genre borne interactive écran tactile et sorte de Raspberry PI), et j'ai choisi pour simplifier les dépendances et le déploiement de ne pas utiliser NPM/Webpack et autres bidules qui font peur. On peut tout à fait s'en passer. On inclut les composants dans le index.html comme toute autre librairie JS.
Ansi, je maîtrise totalement les dépendances. Côté back-end, je fais ça en C/C++, là encore pas de NPM et compagnie, il existe de bons frameworks compatibles C++0x11 permettant d'écrire du code facilement (RegEx, fonctions anonymes etc. sont maintenant en standard, les frameworks ajoutent une dose de design REST et fournissent des utilitaires type JSON), sinon il y a toujours ce bon vieux CivetWeb en C qui est très sympa pour de l'embarqué un peu plus limité.
Au final, pour déployer :
- make pour compiler le serveur
- 2 lignes de systemd pour le mettre en démon
- et yolo on lance Chromium en mode kiosque
J'ai personnellement adoré le développement en Vue.js, c'est assez simple d'accès et bien puissant. Ne pas hésiter à faire "beaucoup" de composant et créer un bus d'événements.
Oui c'est vrai il a changé la forme, mais le fond est toujours aussi brumeux. Une nouvelle API à apprendre en sommes. L'argumentaire principal, le prototypage rapide, est à mon sens contradictoire, personne ne va chercher à apprendre une nouvelle API pour un prototype.
Dommage de politiser ce mouvement que je trouvais assez agnostique jusqu'à maintenant… Tu acceptes mal ton passage de la quarantaine ou frustré de voir tes copains startup qui lèvent des millions ?
[^] # Re: Il était une fois un lapin qu'on prie
Posté par AnthonyRabine (site web personnel) . En réponse au journal Lunii, la boîte à histoires sous Linux. Évalué à 4. Dernière modification le 18 janvier 2019 à 13:36.
Il y a les deux styles :
- Soit des histoires où tu choisis les éléments au début, puis tu écoutes sans intervention
- Soit une histoire avec des embranchements à choisir en cours de route
Sur le Luniistore, il y a encore deux autres catégories de pack : des quizz et des musiques.
[^] # Re: Merci pour l'info
Posté par AnthonyRabine (site web personnel) . En réponse au journal Lunii, la boîte à histoires sous Linux. Évalué à 5.
Je dirais entre 3 et 7 ans, et ça dépend de l'histoire. Le pack de base est plutôt de bonne qualité et à partir de 3 ans ça devrait le faire.
[^] # Re: Il était une fois un lapin qu'on prie
Posté par AnthonyRabine (site web personnel) . En réponse au journal Lunii, la boîte à histoires sous Linux. Évalué à 1.
Disons qu'il y a un nombre limité de combinaisons ; par exemple le pack d'histoires de sorcières que j'ai acheté dure 1h30 et permet de composer 18 histoires différentes.
[^] # Re: Devuan ASCII
Posté par AnthonyRabine (site web personnel) . En réponse au journal Remède au problème démarrage devuan ascii sur raspberry pi 2 . Évalué à 6.
Pareil, encore des gens qui restent bloqués dans le passé. Moi systemd je ne peux plus m'en passer, en deux lignes je crée des deamon et je automount des disques, j'adore. Je gagne un temps fou avec mes clients.
# Mauvais logo
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Appel à rejoindre l’association Borsalinux-fr. Évalué à 4.
Erreur, vous avez mis le logo de Facebook.
# Complémentaire à AngularJS/Vue.js/React ...
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Comparaison de technologies Web pour implémenter une application de dessin basique. Évalué à 1.
Je n'ai pas bien saisi ton introduction ; c'est peut-être moi qui ne pige pas bien, mais les technologies que tu présentes sont complémentaires aux framework front-end. On ne peut pas les comparer. Leurs grandes forces sont effectivement la gestion des templates, le routage, le binding des données, la modularité du code en composants et la gestion centralisée des données (flux) … mais pas de savoir faire du dessin sur un Canvas ?
Donc ton article bien qu'intéressant en soit est un peu troublant ; par exemple on pourrait faire également tout ça en SVG !
Hormis cela, j'aime bien ton essai en WebAssembly ; ça donne quoi le draw.js généré ? Je suis développeur C++ et ça me permettrait de réutiliser du code …
[^] # Re: Cutelyst
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (2/2). Évalué à 1.
Pas compris ta phrase.
[^] # Re: Beast
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (2/2). Évalué à 1.
Et j'ajouterais : il semble que beast soit en bonne voie pour devenir un standard (C++21?).
[^] # Re: Beast
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (2/2). Évalué à 1.
Je trouve qu'il manque de simplicité. Il faudrait un wrapper, l'écriture est bien verbeuse.
[^] # Re: Alternatives
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (1/2). Évalué à 3.
Cette architecture est intéressante car elle rend le code serveur C++ agnostique ;il devient serveur TCP/IP générique et on peut imaginer une foule de clients pouvoir se connecter dessus, quelque soit le langage ou la technologie. Not only HTML …
[^] # Re: Alternatives
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (1/2). Évalué à 2.
Yep, c'est toujours bien d'avoir un aperçu de ce qui existe.
Mon avis tout à fait personnel est que le rendu côté client va gagner la bataille.
Il y a quelques framework modernes qui me font de l'oeil (cpprestsdk, Pistache.io …), vas-tu les tester ?
# Alternatives
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Quelques cadriciels Web C++ (1/2). Évalué à 8.
Personnellement, pour le projet d'un client, j'ai choisi de faire toute l'interface Web côté navigateur avec Vue.js, le serveur en C++ ne se contentant que de fournir une API REST en JSON. Du coup, ça fait beaucoup moins de bazar à gérer du côté C++…
Côté serveur, j'ai choisi le micro serveur CivetWeb largement suffisant pour mon application embarquée, sur lequel j'ajoute une petite surcouche C++ (fournie, en partie d'ailleurs).
[^] # Re: Pas forcément un casse tête
Posté par AnthonyRabine (site web personnel) . En réponse au journal Mettre à jour l'embarqué. Évalué à 0.
C'est ce qui est fait sur le Linky, seul le nouveau code est présent normalement en mémoire externe. Et il y a 30 millions de compteurs. On envoie le stagiaire lancer l'upgrade et on tremble en regardant les stats de re-connexion monter doucement…
[^] # Re: Usage domotique et version NAS
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Financement participatif de la tablette tactile libre Diskio Pi. Évalué à 1.
Non, il faudrait deux connecteurs SATA.
Des versions du banana pi en ont deux, mais je crois que çapucpaslibre.
# Usage domotique et version NAS
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Financement participatif de la tablette tactile libre Diskio Pi. Évalué à 2.
Chouette projet, je ne pense pas en avoir l'usage sauf peut-être comme tablette de contrôle domotique que je placerais à l'entrée. Du coup il faudrait pas mal de place autour des ports USB pour placer les divers dongle Zwave et RF. Je serais toi je ferai un intérieur encore plus modulaire pour s'adapter à plusieurs form factors de cartes. Un système de plaques crantées et prédécoupées.
Bref, moi mon besoin assez récent est un NAS libre, refroidissement passif ; tu voudrais pas faire une version ? Un belle mécanique, et trouver la bonne carte (car le raspb, bof bof il n'a pas de SATA).
[^] # Re: Bien
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Première version stable pour WeasyPrint. Évalué à 2.
Non c'est pas un débat, c'est nul d'attendre 5 secondes pour afficher du texte, point barre. C'est une grave erreur de design. Perso la première fois je croyais que le site avait planté et j'ai fermé l'onglet.
[^] # Re: compilation
Posté par AnthonyRabine (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 8.
C'est simple, tu ne veux pas comprendre deux problématiques majeures, qui te paraissent mineures pour toi mais que la majorité des entreprises / développeurs prennent en considération :
tu mélanges tout dans le back-end. Demain tu changes de techno, t'es coincé, tout est à jeter. Et tu as un gros risque de tout faire péter à la moindre modification. Tes exemples simples sont naïfs : ils fonctionnent, mais pas lorsque l'application est gigantesque et que tu as 20 développeurs. Personne ne veut plus travailler comme cela. On veut des composants, des couches de liaisons, des interfaces agnostiques etc…
Les performances : il faut faire travailler le client, pas le serveur. L'avancée du JS et de ce genre de designs c'est génial pour des développeurs C/C++ embarqués comme moi, ça soulage le processeur et tu peux sous traiter le HTML/JS/CSS de merde à quelqu'un d'autre, et garder pour toi la noblesse et l'élégance du C embarqué.
[^] # Re: compilation
Posté par AnthonyRabine (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 8.
Ok, de mon point de vue c'est une très mauvaise architecture.
Mon serveur "back-end" n'a pas une once de HTML, et il ne veut même pas savoir que c'est un site web qui demande des choses. Tout est en REST, et ça renvoie du JSON. Demain, c'est une application Android, un démon en C ou un script bash qui lancera des requêtes. Peut importe.
L'avantage des nouveaux frameworks est qu'ils intègrent un routeur côté client, c'est vraiment le truc super important : ainsi, le découpage "rendu" et "données" est parfait. J'ai développé 100% de mon appli web dans aucun backend, que du JSON fake, avec plein d'écran différents.
# Alternatives
Posté par AnthonyRabine (site web personnel) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 6.
J'ai commencé à me mettre à Vue.js dans le cadre "embarqué" (genre borne interactive écran tactile et sorte de Raspberry PI), et j'ai choisi pour simplifier les dépendances et le déploiement de ne pas utiliser NPM/Webpack et autres bidules qui font peur. On peut tout à fait s'en passer. On inclut les composants dans le index.html comme toute autre librairie JS.
Ansi, je maîtrise totalement les dépendances. Côté back-end, je fais ça en C/C++, là encore pas de NPM et compagnie, il existe de bons frameworks compatibles C++0x11 permettant d'écrire du code facilement (RegEx, fonctions anonymes etc. sont maintenant en standard, les frameworks ajoutent une dose de design REST et fournissent des utilitaires type JSON), sinon il y a toujours ce bon vieux CivetWeb en C qui est très sympa pour de l'embarqué un peu plus limité.
Au final, pour déployer :
- make pour compiler le serveur
- 2 lignes de systemd pour le mettre en démon
- et yolo on lance Chromium en mode kiosque
J'ai personnellement adoré le développement en Vue.js, c'est assez simple d'accès et bien puissant. Ne pas hésiter à faire "beaucoup" de composant et créer un bus d'événements.
# Python....
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche E.T. téléphone Meson. Évalué à 2.
C'est dommage de l'avoir codé en Python pour le coup, et cela fait une dépendance, pas petite en plus.
[^] # Re: Bravo
Posté par AnthonyRabine (site web personnel) . En réponse à la dépêche Publication de l’Atlas toolkit 0.4 avec démonstrations en ligne. Évalué à 5.
Oui c'est vrai il a changé la forme, mais le fond est toujours aussi brumeux. Une nouvelle API à apprendre en sommes. L'argumentaire principal, le prototypage rapide, est à mon sens contradictoire, personne ne va chercher à apprendre une nouvelle API pour un prototype.
[^] # Re: Mon avis
Posté par AnthonyRabine (site web personnel) . En réponse au journal La compote de pommes en gourde n'est PAS un truc de fainéant.. Évalué à 2. Dernière modification le 26 octobre 2018 à 07:48.
Je possède ces poches réutilisables et aucun problème pour les laver au lave vaisselle en les ouvrant un peu en effet.
L'étanchéité est bien assurée, bref ça fonctionne bien. Remplissage un poil délicat.
Sauf que ma fille préfère les poches industrielles, c'est déprimant.
# Mon avis
Posté par AnthonyRabine (site web personnel) . En réponse au journal Une galerie pour site web - des images plein écran - LigthFullscreenGallery. Évalué à 3.
Alors il manque :
- les deux flèches latérales pour parcourir en avant ou en arrière
- sur mobile le slide du doigt est plus naturel
[^] # Re: Ecriture inclusive
Posté par AnthonyRabine (site web personnel) . En réponse au journal « Changer le monde, un octet à la fois » - Campagne de don Framasoft. Évalué à -10.
Dommage de politiser ce mouvement que je trouvais assez agnostique jusqu'à maintenant… Tu acceptes mal ton passage de la quarantaine ou frustré de voir tes copains startup qui lèvent des millions ?
[^] # Re: Vraie question : que faire de ce genre de commentaire ?
Posté par AnthonyRabine (site web personnel) . En réponse au journal « Changer le monde, un octet à la fois » - Campagne de don Framasoft. Évalué à -1. Dernière modification le 20 octobre 2018 à 22:42.
Ben crée ta startup ! Tu as le même vocabulaire que les business angels vous devriez bien vous entendre, à défaut de produire utile.
Sinon tu fais quoi dans la vie ? Ça se passe comment à la machine à café avec Anette de la compta ?