L'architecture en couches m'a posé quelques problèmes au début, mais elle est bonne, les couches sont nécessaires et bien faites.
Ca fait plaisir...
C'est mon côté "systèmes embarqués": j'aime bien découper en couches indépendantes.
C'est un bon principe de génie logiciel.
Le nombre de couches présent semble rarement apprécié de ceux qui mettent le nez dans la base de code pour les premières fois, nous trouvons tous l'assemblage trop complexe. Et c'est tout à fait exact si on ne considère que le besoin restreint de communiquer avec une seule famille de machines. Plus de la moitié de la base de code est superflue si on ne s'intéresse qu'aux Nspire, j'avais fait un exercice assez rapide de trim à gros grain il y a longtemps:
https://github.com/debrouxl/strip_tilp_nspire .
Mais si on cherche à gérer plusieurs familles de machines qui offrent toutes des opérations similaires, et qu'on veut le faire avec une seule base de code plutôt qu'avec plusieurs qui dupliquent du code, les couches existantes sont ce qu'il faut, à peu de choses près.
La seule exception notable que je voie, dont je me suis rendu compte assez récemment, est le logging + dissection automatique des paquets...
Je te rassure, j'ai toujours trouvé que ce truc était une verrue mais c'était tellement pratique pour débugger.
Jusqu'à un certain point, en effet... mais la façon dont l'implémentation est réalisée, en sérialisant tout vers un fichier puis en cherchant à reparser le dump hexa sérialisé, élimine l'info de direction des paquets. J'ai mal réinterprété les données, et ça m'a déjà fait perdre un temps certain quand j'ai voulu utiliser le dump DUSB libticables comme source d'info pour réimplémenter du code de communication sur 89T... du coup, je n'étais pas content
Un nouveau use case est apparu ces dernières années: la possibilité de communiquer avec les machines sans avoir à installer de logiciel supplémentaire au préalable, ce qui simplifie la vie des utilisateurs peu avancés / motivés de l'informatique, de plus en plus nombreux, et des utilisateurs qui n'ont pas de droits d'administration sur leurs machines, assez nombreux eux aussi. Une des technologies les plus pratiques serait WebUSB + une UI Web, s'exécutant dans le browser habituel, mais les APIs correspondantes sont asynchrones, alors que l'API libti* est synchrone... C'est non seulement plus simple, plus facile à comprendre et maintenir (le code asynchrone et/ou événementiel peut être moins lisible et plus difficile à modifier), mais naturel pour implémenter des protocoles synchrones requête(s)-réponse(s). J'aurais fait la même chose à l'époque de la création de libti* 2 en 2005, où je ne me serais peut-être même pas posé la question, et encore pendant plus de 10 ans après ça, puisqu'en 2015, WebUSB n'était pas dispo.
Mais refaire en asynchrone une bonne partie de la base de code serait un travail considérable, bien plus que ce qu'on peut se permettre de faire pour un logiciel maintenu sur notre temps libre, sans être payés pour ce faire. Et encore, toi (à la fin) comme moi n'avons déjà pas à acheter les machines sur notre argent, même si je l'ai fait avec 4 machines avant d'en récupérer 15 chez toi...
Pour simplifier légèrement la réécriture asynchrone, on pourrait envisager de laisser tomber tous les câbles non USB ou réseau (ces derniers n'étant pas réellement implémentés), et les plus vieux modèles de machines comme 80, 82, 83, 85, 86 et 92, mais le code de gestion de ceux-là ne représente qu'une petite partie du travail qu'il faudrait réaliser.
et ça ne sera bientôt plus un problème parce que vu qu'il y a un nouveau protocole
Ah bon ?
Ouais. Comme je l'ai rapidement écrit plus haut, le CX II utilise un protocole "nouveau" au sens où il n'a jamais été implémenté par libticalcs, mais il existe depuis un certain temps sur les équipements spéciaux pour l'enseignement, de type réseau (on voit des référence à "NWB", ce que j'interprète comme Network Bridge ou Network Wireless Bridge). Que je sache, dans la communauté, on l'ignorait tous.
Pour aller plus en détail: il y a des headers de 12 octets, un peu plus simples que ceux de NavNet, et pour un certain nombre de paquets, une variante de NavNet capable de gérer des paquets plus gros que 16 octets de header + 254 octets de données est wrappée dans ce protocole. L'endpoint USB fait 512 octets, et les libs de TI gèrent des paquets jusqu'à 0x5C0 (1472) octets de header + header wrappé + données wrappées - pas loin de MSS/MTU sur les segments réseau habituels.
De mon côté, j'ai fait 1 an de thèse (biblio terminée + position paper en cours d'écriture) et il me reste encore 2 ans.
Perso, j'en bave un peu pour écrire, c'est pas mon truc. J'ai un peu l'impression "d'enculer les mouches" !
Ah, tu as donc commencé la thèse que je me souviens t'avoir lu évoquer par le passé
Après l'agreg, c'est encore beaucoup de boulot... mais c'est ton travail principal, contrairement à ce qui se passait pour l'agreg, que je me souvienne.
L'écriture,
sous format académique (problématique de recherche, diverses contraintes de forme), d'un aussi gros papier qu'une thèse, plus d'autres papiers au long de la thèse, est aussi un gros problème pour moi. Je m'étais rendu compte de ça lors du stage de Magistère M1, avec un rapport beaucoup plus petit qu'une thèse et pour lequel j'ai demandé trop de travail de relecture. Ecrire de la doc technique, oui, je le fais parfois au boulot, mais écrire des papiers académiques, non. C'est pour ça que j'ai bifurqué vers un M2P, alors qu'en M1, je n'étais pas sûr.
Et la petite famille ?
by Adriweb » 01 Mar 2018, 18:08 
;
;
