La boîte à prog

Vers 2014, j'ai entamé avec un ami, Jonathan Bastien  , la conception et développement d'un ordinateur de plongée. Les choix techniques se sont arrêté sur le microcontrôleur STM32F4. Le MS5803-05BA est un module de capteur de pression absolue et d'altimètre numérique 24 bits fabriqué par TE Connectivity. Le microcontrôleur peut fonctionner à l'aide de 4 batterie AA. À la base, gcc 4.9 a été utilisé. Étant sous Linux en x86, faire de la compilation croisée était pas évident, surtout quand on a d'autre version plus récente. Cette année, j'ai décidé de reprendre le projet, mais je voulais impacté le moins possible mon environnement de développement en local. Je me suis mis à la recherche d'un docker et j'ai trouvé cette image. docker pull wischner/gcc-arm-none-eabi:1.2.0 docker build -t stm32-divecomputer . Quelques modification on script de build et je pouvais compiler et envoyer l'image sur mon ordinateur de plongée docker run --rm --device-cgr...

Historique: des composants côté serveur, des templates aux composants modernes Des JSP aux frameworks front-end modernes, la manière de construire des interfaces web a beaucoup évolué. Pourtant, une question reste la même : comment produire du HTML dynamique, réutilisable et facile à maintenir ? Les premiers templates Java : générer du HTML depuis le serveur Les premiers templates Java : générer du HTML depuis le serveur Au début du web dynamique en Java, les servlets permettaient de répondre aux requêtes et de générer des pages. Fabriquer une page HTML en concaténant des chaînes Java devenait vite pénible : le code applicatif et le balisage se retrouvaient entremêlés. Les JSP (JavaServer Pages, arrivé en 1999) ont popularisé une approche inverse : écrire du HTML dans lequel on insère des éléments dynamiques. Elles ont rendu la création de pages plus naturelle pour les développeurs front-end, mais l’usage de code Java directement dans le template pouvait vite brouiller la séparation en...

  Ordinateur de plongée D-TWIN D-TWIN  est un ordinateur de plongée conçu par BlueEdge . Une entreprise Italienne qui a aussi développé un logiciel (win/linux) qui permet de télécharger les fichiers de plongées, mettre à jour le firmware de l'ordi. L'entreprise a cessé ses activités. J'ai toujours eu des problèmes à télécharger les plongées. C'était très long, arrêt du téléchargement au milieu d'une plongée, timeout. Analyse du traffic La communication se fait via bluetooth. J'ai décidé d'analyser le traffic réseau afin d'être en mesure de définir le protocole et refaire l'application. La commande suivante a été lancé: btmon -w dtwin-capture.btsnoop J'ai lancé leur application et j'ai cliqué sur Search devices. HCI Event: Remote Name Req Complete (0x07) plen 255                                                              ...

Une seule requête, un graphe d'objets complet — ce n'est pas de la magie, c'est du SQL. La base du problème Dans le monde JPA, quand on gère une relation un-à-plusieurs, le chargement LAZY par défaut semble élégant… mais cache une bombe à retardement. Imaginez un scénario e-commerce classique :  Client → Commandes → Lignes de commande → Produits.  Quand vous appelez orderRepository.findAll() , si Open Session in View est activé (plus de  701 allers-retours vers la base de données : 1 requête pour les commandes, 100 pour les clients, 100 pour les lignes, 500 pour les produits. En dev, tout peut bien aller, mais en production il y a risque d'effondrement des performances. Ce n'est pas la faute d'Hibernate. C'est le prix inévitable du modèle de navigation par objets face à des hiérarchies complexes. Limite du join fetch de JPA Beaucoup pensent résoudre le N+1 avec JOIN FETCH . Mais il y a un mur contre lequel tout le monde finit par se cogner : on ne peut pas...