simon59150 a écrit:seb625 a écrit:Bonjour,
Je te propose mon aide, si tu en as besoin.
Je suis developpeur d'applis sous vb et vb.net.
J'ai quelques outils comme par exemple installshield express.
Fais moi signe si ça t'intéresse.
et merci pour ton logiciel.
Merci bien, mais je code en C++
Bonjour,
Le fait que TVO, TVRR et CAPTVTY utilisent des programmes externes montre bien que le langage de programmation n'est pas important, contrairement aux fonctions.
Pour schématiser, les trois programmes ont une interface qui présentent : l'accès aux replays de différentes chaînes, la possibilité de visionner en direct ou de télécharger.
Comme le problème le plus courant de TVO a été l'obligation de mise à jour suite à une modification de présentation des replays sur le site des chaînes, une organisation plus modulaire aurait peut-être permis de décharger le programmeur principal (en l'occurrence Pascal) d'une telle tâche parce que d'autres programmeurs sont capables d'analyser une page web, d'en extraire une liste et de l'ordonner.
Les seules contraintes de cette coopération sont de savoir comment appeler la fonction qui construit la liste ordonnée et comment la liste est organisée.
Que la fonction soit emballée dans un exécutable, une dll ou une page web au lieu d'être liée dans un programme monolithique change la vitesse d'exécution, l'aspect "usine à gaz" du développement et la nécessité de vérifier la cohérence des dépendances des modules.
Mais en termes de maintenance, de remplacement d'un programmeur indisponible par un autre, de tests d'alternatives pour une même fonction ou de longévité du programme, il pourrait y avoir beaucoup de gains.
Exemple de possibilité de programmation hybride :
- le programme appelant (TVRR...) est programmé en C++
- il peut appeler des fonctions publiques contenues dans une dll développée en assembleur, C, BCX, FreeBasic, PowerBasic, Euphoria, FreePascal, Delphi, Windev... (et en cherchant un peu, VB !)
- il appelle des exécutables (msdl, curl, rtmp, ffmpeg, mplayer, vlc ...)
La mise à jour peut porter sur un module (comme lors de la modification de msdl...) ou sur le programme appelant (nouvelle interface de TVRR, passage d'une version à téléchargement unique à celle qui permet les téléchargement multiples...)
Je propose donc de ne pas négliger la disponibilité de programmeurs et de commencer à communiquer sur la manière de construire un programme modulaire auquel plusieurs personnes pourraient collaborer.
La définition des fonctions nécessaires, des paramètres transmis et des structures de données permet déjà l'interopérabilité, c'est-à-dire que le travail effectué pour TVRR pourrait être utilisé dans TVO ou CAPTVTY. A condition de rendre ces éléments publics, tous ces projets pourraient profiter du partage réciproque (comme l'espèrent ceux qui ont écrit les modules open-source utilisés par ces programmes) et collaborer à leur niveau à répondre à nos besoins.
Les fonctions seraient alors des "boîtes noires" dont seules les entrées-sorties seraient documentées précisément. Il est clair que mettre un moteur de 2CV sous une carrosserie de F1 permet au véhicule d'avancer, mais pas comme espéré. La construction du meilleur moteur prend du temps, nécessite de communiquer sur l'expérience pour en garder le meilleur et reconstruire ou améliorer le reste.
Moi aussi, je pense pouvoir contribuer à la construction d'un bon programme bien que je ne pratique ni le surf ni le C++. Ni l'un ni l'autre ne sont indispensables pour arriver au résultat. Mais comme le C++ est plus adapté à la programmation qu'une planche de surf... travaillons ensemble !
Posté: Lun 25 Juil 2011 22:38
: 
voir 
pour faire réfléchir, pour bien distinguer l'objectif à atteindre des fonctions à remplir en utilisant des outils. 
Un professeur d'université en psychologie du développement a dit devant moi d'un enfant que celui-ci présentait un retard de développement graphique parce qu'il était incapable d'écrire avec un crayon. La conclusion du psy : comme le développement graphique précède l'apprentissage de la lecture, un enfant dont le développement graphique est insuffisant ne peut apprendre la lecture. 
Or, cet enfant, suite à un problème cardiaque, ne supportait pas de serrer un crayon entre ses doigt et écrivait avec un feutre. Il laissait donc bien une trace codifiée destinée à communiquer. Le psy a confondu l'outil et la fonction 
. De plus, je lui ai fait remarquer que sa logique était fausse 
parce qu'elle excluait systématiquement des personnes handicapées de naissance n'ayant pas de mains ou présentant des problèmes de préhension. Or, l'expérience a prouvé que des personnes dysméliques (p.ex.victimes du softénon) étaient capables d'apprendre à lire malgré leur graphisme déficient et pouvaient même avoir un parcours universitaire.