Présentation de : TVRR

[amoyensis]

Bon travail mais j'ai quelques soucis avec le répertoire de destination. Après avoir cliquer sur "ouvrir dossier de téléchargement" j'ai un message comme quoi "le chemin d'accès.......n'existe pas ou n'est pas un répertoire" pourtant le dossier existe et j'ai bien la vidéo enregistrée dedans.
Pour Tf1 c'est toujours en version de test ?
Bonne poursuite de votre projet.

[ipefix]

Petite suggestion rapide en passant et qui concerne le forum (et TVRR aussi, évidemment) :

Il y a possibilité de mettre en post-it un sujet de remerciement à Simon ? Je ne vois pas pourquoi Pascal serait le seul à avoir ce privilège malgré l'excellent boulot qu'il a accompli avec TVO !

[sandboxie]

Petite suggestion rapide en passant et qui concerne le forum (et TVRR aussi, évidemment) :

Il y a possibilité de mettre en post-it un sujet de remerciement à Simon ? Je ne vois pas pourquoi Pascal serait le seul à avoir ce privilège malgré l'excellent boulot qu'il a accompli avec TVO !

Bonne idée !
- Topic qui vient d'être crée par CZ viewtopic.php?f=20&t=151

Merci de ta suggestion !!
Sand ...

[seb625]

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.

[simon59150]

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++

[ipefix]

Bonne idée !
- Topic qui vient d'être crée par CZ viewtopic.php?f=20&t=151

Merci de ta suggestion !!
Sand ...

De rien, et euh bah merci

[amer_du_nord]

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 !

[EGE1357]

Tout à fait raison Amer-du-Nord et c'est très bien d'en parler, je pensais en plus à un programme utilisé pour nous permettre de "fouiller les replays et même les lives pour trouver les listes et adresses, cela permettre à n'importe qui de mettre à jour les possibilités de télécharger les replays comme un TVO programmable (Boite à outils intégré directement dans les chaines).

Donc on aurais la fonction, "Créer ou modifier le téléchargement ou visionnage d'une Chaine, d'un replay, d'un live, d'une radio" et une fenêtre qui paramétrerais le lien de la chaine, de son lecteur, du ou des proxies pour y accéder, comme on programme un proxy dans un navigateur web.

Voilà ce n'est qu'une idée.

Merci pour l'info et les suggestions.

:bravo:

[amoyensis]

Bonsoir,
cela me fait penser sous une autre forme à un autre message viewtopic.php?f=20&t=67&start=30#p874; J'aime bien l'idée du Savoir/Pouvoir.

[amer_du_nord]

Bonsoir,
cela me fait penser sous une autre forme à un autre message viewtopic.php?f=20&t=67&start=30#p874; J'aime bien l'idée du Savoir/Pouvoir.

Je me sens chez moi : l'utilisation de savoir à la place de pouvoir est un belgicisme ! (http://www2.belgique.over-blog.com/cate ... 44808.html) La Belgique est un pays compliqué et surréaliste. J'ai donc un peu la tournure d'esprit d'un Shadock (pour les jeunes voir http://fr.wikipedia.org/wiki/Les_Shadoks.) L'aphorisme permanent en Belgique pourrait être : s'il y a moyen de faire plus compliqué, il faut le faire ! :bravo:

Loin de moi l'idée de prendre du pouvoir sur qui que ce soit en participant au développement d'un programme et j'attends la réciproque.

Un peu de pédagogie 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.

Je méfie donc des apparences, des certitudes qui cachent l'ignorance et des raccourcis en ligne droite qui ne tiennent pas compte de la courbure de l'espace-temps.

Pour avoir pratiqué cette activité, je peux parler du programmeur qui crée son propre programme. Il joue à être Dieu, il est seul Maître à bord, que le programme soit un jour opérationnel ou non. C'est très sécurisant. Il en va autrement lorsqu'il doit travailler en équipe, lorsqu'il devient dépendant d'autres personnes. C'est une forme de régression symbolique, un retour à la petite enfance. La sécurité de tous les programmeurs impliqués vient du dialogue : la fixation d'un objectif commun, l'assignation des tâches, des procédures de contrôle de qualité, de support mutuel en cas de difficulté. La confiance n'est pas immédiate, elle se construit dans l'expérience ressentie et le sentiment de réciprocité. Et les risques de dérapage existent tant dans la mauvaise communication que dans la mauvaise interprétation des réactions de l'autre.

Dans certaines limites (pas kamikaze tout de même !), tant que je n'ai pas essayé certaines activités, j'ignore si je pourrai m'adapter et inventer les moyens qui me manquent pour atteindre le but. Les équipes de développement de logiciels open-source ont montré que la coopération est praticable et efficace. Je suis tenté d'essayer.