AnthonyRabine a écrit 128 commentaires

Alors oui Lua est une solution tout à fait valable à ce genre de pratiques. Je l'ai fait dans le passé, avant que des moteurs JS à peu près corrects n'existent.

Sauf que je partage aussi mes algorithmes avec le monde Web. Donc voilà pourquoi j'ai basculé en JS ; l'autre raison que j'ai rencontrée c'est effectivement que beaucoup de monde sait faire du JS.

Effectivement elle est très intéressante surtout qu'ils vendent la carte double SATA et le boîtier qui va bien pour mettre deux disques.

L'ensemble revient à $160, sans les disques, en version 4Go de RAM.

Si l'Ethernet est natif ça serait vraiment bien pour un NAS.

Et dans mon cas super pour le proposer sous la forme de compute module en milieu industriel.

10 ans de retard. Je l'utilise via MPLAB, une surcouche pour du développement embarqué sur des microcontrôleurs Microcheap, c'est lent au possible, le refactoring bugué et peu puissant (il lâche l'affaire dès que c'est trop dur), l'indexeur aux fraises et facilement parti en while(1)… La navigation entre les fichiers est peu efficace.

Bref, pour du C++, QtCreator sinon Eclipse.

Oui, et encore un cas de financement réussi après avoir raté le premier essai. Le moment joue beaucoup, ainsi que le positionnement et la communication.

J'avais vu une interview du patron de CaptainContrat qui a cette problématique, c'est même au cœur de leur stratégie. De mémoire, réglée à coup de XML et de Word généré. Dommage qu'il ne publient pas leurd outils. Et ils sont une bonne armée de devs avec du support de Microsoft.

Vu le nom c'est une maison de retraite ?

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.

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.

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.

Erreur, vous avez mis le logo de Facebook.

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 …

Pas compris ta phrase.

Et j'ajouterais : il semble que beast soit en bonne voie pour devenir un standard (C++21?).

Je trouve qu'il manque de simplicité. Il faudrait un wrapper, l'écriture est bien verbeuse.

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 …

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 ?

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…

Non, il faudrait deux connecteurs SATA.

Des versions du banana pi en ont deux, mais je crois que çapucpaslibre.

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 :

1. 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…

2. 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.