GuieA_7 a écrit 675 commentaires

Pour le coup, Spine-runtime n'est pas libre (et c'est bien dommage, j'aimerai beaucoup que Spine dans son ensemble soit libre ; enfin bref). Je ne dis pas que ton expérience (0 réponse de leur part) ne peut pas arriver avec un projet libre, mais pour le coup les auteurs n'ont pas l'air d'être des spécialistes du libre ; j'imagine que la disponibilité des sources est quelques chose d'apprécié par leurs utilisateurs, mais qu'ils ont une vision classique du développement de produit, et que la gestion des contribution n'est pas leur priorité.

Merci beaucoup. Moi aussi j'ai pas mal de contenu privé qui prenait la poussière :)

Je n'ai pas la prétention de les trouver génialissime

Je te taquinais :) c'était pour souligner que même si ton contenu est de qualité, les gens ne vont pas venir spontanément ; je te rassure tu n'es pas le seul à avoir un problème avec le "marketing".

je m'interroge sur les endroits appropriés pour le faire

Je t'ai donné quelques pistes (même si encore une fois il n'y a pas de recette du succès) dans le cas où ton contenu serait du logiciel libre. Mais comme tu n'as pas précisé ce qu'il en est réellement, il m'est difficile d'aller plus loin.

Es-tu certain que ce n'est qu'un cliché ? Je vois les gens, dans le train, le tram, même en groupe, ils sont tous rivés sur leur smartphone.

https://xkcd.com/1601/

J'ajouterai que les gens peuvent faire plein de trucs sur leur smartphone (envoyer des SMS, jouer, …) sans être sur FB/Twitter. Évidemment que ces 2 réseaux sont populaires et que beaucoup de gens sont dessus. Mais des tas de gens s'en passent aussi ; d'où mon «cliché».

Là aussi tu mets le doigt sur un de mes problèmes fondamentaux. J'associe mon bien être à mon succès (ma "popularité", l'intérêt qu'on accorde à ce que je fais, bref).

En effet, c'est un problème. Je dis ça d'autant plus que j'ai tendance à penser comme ça aussi ; mais c'est une erreur à mon avis, et il faut faire un travail sur soi-même (et c'est dur). J'ai vu passer pas mal de choses à ce sujet sur le blog de Tristan Nitot.

Ou alors, le problème vient de moi, et de mon contenu. Je ne rejette pas du tout cette idée, au contraire, je sais que, parfois, mes idées dérangent

Hum penser que "olala je suis suis subversif mes idées dérangent", désolé mais ça fait un peu "Café du Commerce". Alors oui parfois on a un génie incompris qui n'est reconnu que bien longtemps après sa mort. Mais 99% du temps, quand on pense être CE génie, en fait ses propos/œuvres sont juste inintéressants. Il y a des milliers de logiciels sans grand intérêt qui traînent sur SourceForge/GitHub/… (certains à moi hein) ; leurs auteurs peuvent tout à fait penser que leurs logiciels sont géniaux, mais qu'ils ont 20 ans d'avance sur le reste du monde et que personne ne s'en aperçoit, mais ça ne changera pas la triste réalité.

J'auto-héberge tout ce que je fais, mon problème est donc, si je suis ton raisonnement, de trouver des vecteurs pour transmettre l'information, et c'est justement là que j'ai pensé que les réseaux sociaux pourraient m'aider.

• Non seulement tu auto-héberges, mais je suis allé voir dans tes journaux, il est toujours impossible d'accéder à ton repo git de Cyca sans accepter une exception, et le http simple m'a planté dans les doigts. Il faut visiblement faire beaucoup d'efforts pour accéder à tes œuvres. Les gens feront peut-être cet effort quand ils te connaîtront (et encore), mais du coup c'est le serpent qui se mord la queue.
• Tu pars du principe que les réseaux sociaux c'est FaceBook et Twitter. Mais Internet est un réseau social, LinuxFR est un réseau social, un LUG est réseau social. Si tu veux promouvoir tes logiciels (s'il s'agit bien de ça), FaceBook n'est sûrement pas le meilleur endroit (enfin sauf si tu fait des jeux grand public pour mobile par exemple, mais ça n'a pas l'air d'être le cas). Tu peux mettre ton code sur GitHub/BitBucket/… (même si ça n'est qu'un miroir de ton repo auto-hébergé par exemple), tu peux communiquer sur LinuxFR, allez dans un LUG, aux RMLL/Solutions Linux… ; tu discuteras avec plein de gens sans être passé par FB/Twitter. Mais si tu restes sur ton blog auto-hégergé dont tu ne parles à personne, aucune chance que des hordes de gens viennent te parler de tes œuvres génialissimes.

Ce n'est pas très précis dans ton commentaire, tu parle juste d'«existence». D'un certain point de vue tu existes déjà sur Internet autant que des millions de personnes, vu que je suis là à te répondre par exemple. D'un autre côté je suis à peu près certain que ce n'est pas ce que tu as en tête, et que tu parles de «succès». Si mon hypothèse est bonne, alors:

• il faudra préciser ce que tu appelles succès. Veux-tu être connu en tant qu'homme (ex: être connu sur LinuxFR, avoir des millions de fans…), ou que tes œuvres soit plus diffusées (dans quelles mesures là encore).
• il faut voir que si la recherche du succès n'est pas forcément une mauvaise chose, il faut rester humble et se dire que des tas de gens qui font des trucs formidables reste globalement des inconnus (peux-tu citer ne serait-ce que 10 contributeurs au noyau Linux ?). Il ne faut pas que ton bien-être passe par le succès, car c'est un peu comme jouer au loto.

Il n'y a pas que facebook et twitter dans la vie ; et être dessus n'implique pas non plus de passer ses journées sur son smartphone (là tu fais juste dans le cliché). Selon que tu fasses du logiciel libre ou des vidéos humoristiques, tu ne vas pas forcément côtoyer les mêmes sites. As-tu rendu accessible ton contenu aux personnes les plus à même de les apprécier ?

Avec son salaire

Super les clichés.

Tu sais des patrons qui ne se payent pas, ou moins que leurs salariés, ça arrive souvent dans les petites boutiques (la mienne par exemple). Alors c'est sûr que si pour toi patron == 'mec avec un gros cigare et un haut-de-forme', le débat va pas être élevé…

je ne peux plus faire de journal

Si c'était pour faire un journal aussi creux que ton commentaire, c'est peut-être pas un mal…
Tu aurais pu faire une entrée dans le forum, montrer que tu peux écrire du contenu (et pas juste jeter 2 URLs), et faire un peu remonter ton karma. Tu as préféré venir polluer le journal (très intéressant lui) d'un autre et faire encore baisser ton karma. Soupir.

Oui, l'intégration de gros bouts de code écrits par un codeur externe (et qui potentiellement ne va pas continuer par la suite) est souvent problématique ; sur Blender par exemple on voit souvent des GSoC n'être intégrés que des années après. J'ai donné pour le financement participatif, et je suis donc forcément déçu par ce qui s'est passé ; mais on peut aussi voir les choses sous un autre angle et voir ces grosses contributions comme des "Proofs of concept", et qui permettent d'infirmer/confirmer que certains développements valent le coup (ou pas). Potentiellement, il auraient été trop risqué qu'un core dev passe du temps là dessus sans savoir à quoi s'attendre, donc au final ça n'est pas fondamentalement négatif (mais l'équipe de 0AD fera bien ce qu'elle voudra, bien évidemment).

OK merci pour ta réponse précise.

seront alors déjà en train de travailler sur 0 A.D. Part 2 : Empires Besieged, qui devrait utiliser un nouveau moteur au lieu du vieillissant Pyrogenesis

Cool.

Quant au GSoC, ça n'est pas non plus dans les moyens humains de WFG.

Je pensais qu'être juste mentor permettait un investissement en temps assez faible (tout est relatif évidemment).

1) Il faut optimiser le code du jeu avant de le multithreader

Oui tout à fait.

2) Le moteur de jeu est vieux et date d'avant les multicores. La séparation des tâches dans plusieurs threads est possible, mais elle ne sera jamais parfaite.

Exploiter parfaitement une machine est déjà quasi-impossible, surtout avec un code ciblant des architectures diverses. Et le faire avec du code parallèle est forcément encore plus dur.
Pourtant je trouve que ce que tu dis est triste. Oui il est tout à fait possible que le moteur n'exploite jamais très efficacement les multicores ; parce que le développement, uniquement porté par des bénévoles, est lent, et que du coup le projet pourrait en effet être moribond bien avant ça. Mais dans l'absolu, le fait de voir un jeu sans cesse amélioré (plutôt que sorti une fois pour toutes, et abandonné par son studio, passé à un autre projet) est plutôt enthousiasmant, aussi je préfère ne pas dire "jamais" tant que le projet vit.

Il y a en gros 2 axes pour multithreader un jeu:

• Mettre les différentes parties (rendu graphique, moteur physique, IA,…) dans des threads différents. L'avantages c'est que c'est assez "facile" de porter un vieux moteur monothreadé. Un des soucis est que les différentes parties ne sont pas aussi gourmandes les unes que les autres, aussi on exploite pas forcément très efficacement la machine.
• Dispatcher les différentes "entités" du jeu dans les différents threads, chacun s'occupant de la physique/IA/… des entités dont il s'occupe. Évidemment c'est très complexe (les entités d'un thread doivent pouvoir interagir avec celles d'un autre efficacement—en plus des souci classique de race condition ; mais il faut quand même dispatcher de manière à ce que ça arrive le moins possible), mais si c'est bien fait c'est plus efficace que la technique précédente.

J'ai instinctivement tendance à penser que pour un RTS la 2ème technique est plus facile à implémenter que pour d'autres genre ; du fait par exemple qu'on pas mal d'entités statiques (les bâtiments) qui, si suffisamment éloignées ne vont pas interagir ensemble (évidemment ça dépend des règles) ; après lorsqu'on a plein d'unités au même endroit qui se tapent dessus ça devient peut-être assez infernal à faire efficacement, alors je ne m'avancerai pas trop non plus, il est clair que c'est complexe. Ça ferait sûrement un passionnant GSoC :)

le jeu est pour l'instant monothreadé

Et du coup le passage a du multi-thread est-il un chantier prévu ? J'imagine que le boulot doit être assez conséquent, mais on peut rêver. :)

En parlant de grammaire j'ai peut-être porté à confusion, mais c'est surtout le terme 'sémantique' qui m'importait (je n'ai pas trop su comment le formuler) ; on se tape de savoir si on fait des blocs avec des {} ou des BEGIN/END, c'est juste cosmétique. En revanche est-ce de l'impératif ou du fonctionnel (ex: 'if' peut exister dans les 2 cas, mais avoir une sémantique différente), de l'objet à classe ou à prototype, fait-on de l'héritage de type ou bien de trait, du typage dynamique/statique, avec de l'inférence ou pas, du typage fort/faible, quel est le modèle mémoire etc…

Je fais partis des gens qui pensent que celui qui ne connaît qu'un langage n'en maîtrise aucun. Et inversement un codeur qui comprend les différentes notions de mon paragraphe précédent (parce qu'il a étudié la théorie et pratiqué des langages divers) n'aura pas de mal à appréhender le langage Java, parce qu'il est assez pauvre et n'a pas de fonctionnalité qu'on ne retrouve ailleurs (et ce n'est pas forcément un défaut). Ça ne veut pas dire être un dieu du Java en 3 jours, mais ça veut sûrement dire être à peu prés opérationnel en 1 mois au sein d'une équipe.

Tu penses que je suis très théorique, et c'est sûrement le cas ; mais l'entreprise que j'ai créée avec 3 associés a fêté ses 10 ans il y a peu, alors peut-être me croiras-tu si je te dis que je suis aussi pragmatique. J'ai eu l'occasion de briller à des entretiens avec mes (petites) connaissances théoriques, et sans avoir à démontré que je connais par cœur telle ou telle API ; mais il s'agissait de recruteurs intelligents cherchant de bons techniciens (spoil: ce n'était pas des SSII :) ). J'ai aussi pu mener un certains nombres d'entretiens du coté recruteur ; et j'ai toujours été content de mes choix, que j'ai fait avec des entretiens ouverts et assez théoriques, et jamais portant sur la maîtrise de tel subtilité d'un langage ou de sa lib standard ; les personnes recrutées ont toujours rapidement été efficaces sur le terrain en peu de temps. Je pense qu'une personne qui connaît bien un, et un seul, langage et sa lib standard, ne pourra jamais envisager une solution optimale si son langage se prête mal au problème rencontré.

Les formules sont mathématiques et le recrutement s'est fait pour des compétences poussées en ce sens. Si je leur parle de XOR, je ne suis même pas sûr qu'ils me répondront

Je n'ai pas compris ce passage. Tes collègues sont brillants en maths mais ne connaissent pas XOR ?! Si oui, alors j'imagine qu'ils connaissent le concept de 'ou exclusif' sans connaître le sobriquet que lui donne les informaticiens, ce qui n'est pas vraiment un souci à mon sens ni une lacune théorique (ils trouveront le jour où ils en auront besoin). Si c'est autre chose alors explique plus clairement stp.

Par contre, pour être opérationnels, ils doivent avoir l'écosystème en main pour fournir un logiciel fini.

En ce qui me concerne, si les gens ne sont pas opérationnels dans l'heure, ça ne me semble pas choquant s'ils ont les bases pour le devenir rapidement (pour moi c'est ça un bon informaticien). "Quoi tu as fait du Qt/GTK/… mais jamais de Swing ! Tu ne dois sûrement pas être capable de faire une GUI, car pour ça il faut connaître par cœur la signature du constructeur de JButton !". En ce qui me concerne une boite qui me dirait ça, je n'aurai probablement pas envie de travailler pour elle dans tous les cas ; après je ne sais pas quels sont les plans de notre posteur, car sa demande était assez vague, nous sommes d'accord.

1) Je pense que l'incompréhension vient que ce ce j'appelle langage, c'est seulement le langage (sa grammaire, sa sémantique), mais :

• j'ai fait systématiquement l'effort de parler du langage Java quand il je parlais du langage.
• j'ai fait systématiquement l'effort de parler de l'écosystème Java (qui comprend le JDK) le reste du temps. J'ai précisé dans mes 2 derniers messages que le maîtriser était difficile, donc je ne comprends pas pourquoi tu tiens tellement à me l'expliquer vu qu'on est d'accord…

J'ai aussi dit que coder correctement était difficile dans tous les langages, et que maîtriser même un langage simple était difficile. Je fais du Python, langage simple, depuis plus de 10 ans, il m'arrive encore d'apprendre des choses dessus ; et je ne parle pas de fonctions de la lib standard (il est évident que je ne la connaît pas par cœur), mais bien d'aspect du langage lui-même. Là encore on est d'accord mais tu me le réexpliques quand même.

J'ai aussi dit que l’excès de simplicité du langage pouvait justement être une source de difficulté pour le programmeur (il manque des notions qui auraient permis que le langage fasse les choses à notre place, donc le programmeur doit faire plus d'efforts). Donc le fait que le langage soit simpliste n'implique pas que coder des choses complexes soit simple, c'est très exactement le contraire.

2) La phrase originelle disait que le langage Java faisait partie des plus savants. C'est faux il fait partie des langages les plus simples parmi les langages les plus utilisés. Et c'est normal Java a été conçu dans cet optique :

"Le langage Java reprend en grande partie la syntaxe du langage C++, très utilisée par les informaticiens. Néanmoins, Java a été épuré des concepts les plus subtils du C++ et à la fois les plus déroutants, tels que les pointeurs et références, ou l’héritage multiple contourné par l’implémentation des interfaces. Les concepteurs ont privilégié l’approche orientée objet de sorte qu’en Java, tout est objet à l’exception des types primitifs (nombres entiers, nombres à virgule flottante, etc.)."

"L’équipe envisageait initialement d’utiliser le langage C++, mais l’abandonna pour différentes raisons. Tout d’abord, ils développaient sur un système embarqué avec des ressources limitées et estimaient que l’utilisation du C++ demandait un investissement trop important et que cette complexité était une source d’erreur pour les développeurs. L'absence de ramasse-miettes impliquait que la gestion de la mémoire devait être programmée manuellement, un défi mais aussi une source d’erreurs."

"Il faut noter que les évolutions successives du langage ne portent guère sur sa syntaxe -relativement stable depuis le début- mais principalement sur l'enrichissement de ses fonctions, avec l'embarquement et l'optimisation de bibliothèques logicielles (API) dans des domaines très variés de l'informatique : bases de données, gestion XML, informatique distribuée et web, multimédia, sécurité…"

Tiré de https://fr.wikipedia.org/wiki/Java_%28langage%29

Note que le fait qu'il fasse partie des plus simples n'implique pas qu'il soit simple dans l'absolu. Donc oui il a des subtilités, mais il y en a aussi dans les autres langages (et particulièrement en C++).

Hmm, t'as jamais testé jni ou quoi ?

• JNI fait parti de la lib standard, pas du langage en tant que tel. Il y a des API complexes dans tous les langages.
• Il y a des API comparables dans tous les langages ; tous les langages bien conçus permettent de s'interfacer avec du C, et quand il y gestion automatique de la mémoire ça peut être source de complexité oui, mais ça reste vrai dans plein de langages 'simple' (ex: Go, Python). Donc ça ne rend pas Java plus complexe que les autres, désolé.
• As-tu essayé de maîtriser la STL ? :)
• Programmer avec un GC facilite globalement la vie du programmeur (c'est pour ça qu'il y en a un dans Java—cf l'historique plus haut) ; maintenant chaque solution amène aussi des problèmes. Donc l'existence de problèmes ne prouve pas qu'on est plus complexe que le reste du monde.

Et tu te limite à un seul langage dans tes applis ?

Quel rapport avec Java au juste ? Oui programmer c'est difficile ; oui mélanger des langages c'est difficiles ; oui si certains ont un GC ça va provoquer un certain type de problème, mais Java n'est pas le seul à avoir un GC (anecdote: on peut mettre un GC en C++, mais pas gérer sa mémoire manuellement en Java) et le GC facilite la vie 99% du temps, donc encore une fois ça ne rend pas Java plus complexe que les autres.

De quel "java" parles-tu, et à quel "C++" le compares-tu ?

Même les dernières versions de Java sont loin d'être aussi expressives que l'état de l'art d'il y a 15 ans (youpi il y a enfin les lambdas, la concurrence tremble), donc peu importe la version du langage Java, cela reste un langage plutôt simple. Rien que le langage de template de C++ déja présent il y a 20 ans (mais pas toujours implémenté par les compilateurs C++ tellement il est complexe), face aux generics poussifs de Java permet de voir l'abîme de complexité qui sépare les 2 langages. Note que je dis juste que C++ est plus complexe, je ne dis en aucun cas si un des 2 langages est mieux que l'autre (ils sont différents, avec des qualités différentes), ni s'ils sont bien (là c'est l'assurance de lancer une discussion interminable, ce n'était pas le but).

Faire un itérateur ou une fonction lambda, un hash personnalisé, ça te semble à la portée de n'importe qui ?

• Dans un langage qui gère automatiquement la mémoire (comme Java), si écrire un itérateur ou une fonction lambda s'avère difficile, c'est éventuellement parce le langage utilisé n'est pas très puissant, par exemple s'il est simpliste. En gros, langage simpliste implique que le programmeur doive en baver pour faire des choses non triviales. En C++, c'est différent, on doit se soucier de plus de choses comme la mémoire (où est-ce qu'on alloue, qui désalloue…), les difficultés viennent de l'aspect bas-niveau.
• Écrire une bonne fonction de hash est difficile dans tous les langages.

Et les GUI, le modèle MVC, c'est si simpliste ?

C'est quoi le rapport avec les langages ? Ce sont des choses qu'on peut être amené à coder dans n'importe quel langage. Le fait que cela soit difficile, c'est parce que coder c'est difficile, cela n'a rien a voir avec le côté simpliste ou non du langage.

On voit très vite que faire du code propre (je ne parle pas d'un programme sur un bout de serviette), donc maintenable, réutilisable, n'est pas si direct que ça. Dans aucun des deux.

Ça sera difficile dans tous les langages, parce que faire de la qualité c'est difficile par principe.
Après selon le projet, le langage choisi pourra être plus ou moins adapté (et donc rendre ça un peu moins difficile), et les difficultés techniques seront de natures différentes (ex: se battre avec les cycles de références en C++ qui provoquent des fuites mémoires, se battre avec le GC qui défonce les performances en Java).

Il est possible d'écrire du code non trivial (voire très complexe) même avec un langage simpliste. Et Java est relativement simpliste ; par exemple il a fallut attendre des plombes pour avoir des lambdas, alors que tous les langages avec gestion automatique de la mémoire les avaient depuis longtemps ; avoir des classes anonymes était une solution simple à ce manque, mais en pratique avoir un concept de moins pour garder le langage simple obligeait les codeurs à écrire plus de code moche ; ce qui s'appelle être simpliste (trop simple, la simplicité n'est plus une force, mais une faiblesse). Et le fait d'avoir des lambdas aujourd'hui ne ramène pas Java au niveau de l'état de l'art, ca le rend juste moins simple. Au contraire C++ dispose de beaucoup de concepts, ce qui le rend très (voire trop) complexe.

Maintenant un codeur qui veut maîtriser Java devra au final connaître l’écosystème Java, et cela sera difficile aussi (parce que devenir compétent c'est difficile).

Pour le C++ et le Java, qui sont parmi les langages les plus savants

C++ est clairement très complexe, voire compliqué.

Java le langage en revanche est plutôt simple, voire simpliste (ce qui ne veut pas dire non plus qu'on en connaît les moindres subtilités en 2 heures évidemment). Après il existe tout un tas de bibliothèques/outils permettant justement de pallier les lacunes du langage. Du coup c'est l'écosystème Java qui est assez complexe.

Ça ne remet pas en cause ce que tu dis, et mixer pratique et théorie est effectivement la bonne approche.

Mercurial est lui-même écrit principalement en Python (et donc du Python 2.X, le passage en Python 3 étant sujet à débats).

Il y aussi Zulip libéré par DropBox il y a quelques mois ; après je ne l'ai jamais testé, et si des gens ici l'ont fait, des retours seraient intéressants.

https://docs.python.org/release/2.7/library/stringio.html#module-StringIO

le pire qu'il puisse arriver c'est qu'il n'existe plus qu'un seul langage informatique.

C'est vrai, mais personne ici n'a soutenu le contraire en même temps.

Il m'a permis de comprendre la différence entre une variable et un objet grâce à son mot clé bless par exemple

En gros Perl t'a appris les idiomes du Perl. On pourrait en dire autant de n'importe langage donc.

Cela deviendra peut être devenu un langage de vieux

Soit un langage est utilisé par les gens, et il devient forcément un langage de vieux (en ayant au passage plus ou moins inspiré son ou ses successeurs), soit tout le monde s'en tape.

Aussi Perl6 a quoi cela peut servir ? à découvrir, à apprendre, à explorer

On peut faire tout ça avec n'importe quel langage.

… à penser différemment

On peut faire ça avec n'importe quel langage éloigné des autres langages qu'on connaît déjà. Entre C, Python, Rust, Erlang, Haskell, Prolog, Ada (par exemple) on a déjà des concepts très différents à appréhender. Les concepts de Perl6 apportent-ils tant de choses que ça (c'est une vraie question) ?

Il existe des tas de très bons langages libres (ou avec au moins une implémentation libre). On peut donc demander quel est l'intérêt de Perl6 de toute bonne foi, sans sous-entendre qu'il ne sert à rien. Et par exemple "faire un langage pour s'amuser" peut être une réponse acceptable (mais pas forcément très motivante).

Je faisais surtout référence à l'usine à gaz Java

En effet, c'était subtile. Peut-être même un peu trop ! :)

je ne suis pas un grand fan de Python

C'est un peu connu maintenant, ceci expliquant cela…

Hum …. Python, un langage pour l'embarqué ?

En 2008/2009, j'ai bossé dans une boite qui fait un firmware de centre multi-média (qu'on retrouve dans une box internet d'un des 4 grands FAI français par exemple). La GUI était faite en Python, et s'appuyait sur des widgets en C et des briques en C++ pour les parties bas niveau. Ça marchait plutôt bien, et ça permettait de facilement faire évoluer l'interface du produit et de l'adapter spécifiquement pour les différents clients.

C'était d'ailleurs une source de tension en interne, et à chaque problème de réactivité de l'IHM, l'équipe C++ rappelait son envie de réécrire la GUI en C++. Là où c'est cocasse, c'est que 9 fois sur 10 lesdits problèmes venaient en fait… du code écrit en C++. Pour la bonne raison que la clé est d'écrire du code asynchrone avec de petites actions facilement annulables, et qu'en Python c'est assez facile à faire.

Conclusion: Python est très bien pour faire du prototypage ; mais régulièrement le prototype s'avère suffisamment bon pour que la réécriture ne s'impose pas vraiment.

Plutôt que

list(my_dict.values())[0]

je trouve plus élégant:

next(iter(my_dict.values()))

Remarque: du coup si c'est vide on se tapera une exception StopIteration à la place d'une KeyError. J'imagine qu'il faut gérer ce cas.

Question pour Marotte: es-tu sûr que dans le dictionnaire la première valeur (s'il elle existe) est forcément la bonne ?

Ok, et donc que veux-tu ?

• Que quelqu'un écrive le code à ta place.
• Avoir plus de précisions sur comment le coder toi-même.
• Une solution qui ne nécessite pas de code (auquel cas la réponse donnée plus bas par j_m me semble très bien).

Tu n'as pas à te justifier d'être débutant, le forum est là pour ça (sinon je ne me fatiguerai pas à répondre). En revanche, dans la mesure où tu vas faire évoluer ce code, il va bien falloir le comprendre un minimum; ça tombe bien car Python est plutôt simple à appréhender, et ce code ne fait pas grand chose non plus. L'améliorer est donc tout à fait possible pour un débutant, et c'est un bon moyen d'apprendre (potentiellement plus que d'écrire du code trivial au kilomètre).

La question est donc de savoir si tu as compris comment implémenter la solution numéro 1 que je t'ai donnée (sûrement la plus adaptée).

Avec un peu d'imagination les solutions sont nombreuses :

• Comme suggéré au dessus tu passes le nom du fichier en paramètre, tu récupères la dernière ligne (par exemple http://stackoverflow.com/questions/3346430/most-efficient-way-to-get-first-and-last-line-of-file-python ) et tu n'écris que si la nouvelle ligne est différente.
• Tu stockes les dernières valeurs dans un fichier caché (bon dans l'absolu, pour faire les choses proprement, il faudrait faire attention et prévoir les cas où le script est lancé plusieurs fois en parallèle), tu lis les nouvelles valeurs, et si elles sont égales aux anciennes tu renvoies 'N/A' (même si un simple None ferait l'affaire mais c'est une autre histoire).
• Plutôt qu'un script lancé par cron, tu fais un daemon qui tourne en permanence (et peut garder les dernières valeurs dans une variable). ici c'est sûrement overkill, mais si voulais faire un truc plus intelligent qui se met par exemple à lire les valeurs plus souvent s'il s'aperçoit qu'elles changent rapidement (grosse fuite :) ) ça serait une piste.

Sinon quelques remarques sur ton code:

i=0
for test_output in range(10):
    i+=1
    ...

s'écrit en Python idiomatique:

for i, test_output in enumerate(range(10), start=1):
   ...

f = open(sensorFile, "r")
text = f.read().strip()
f.close()

gagnerait à être écrit (plus court, le fichier est fermé même en cas d'erreur):

with open(sensorFile, "r") as f:
    text = f.read().strip()

Ça serait mieux que tes tas de text.split("\n") soit fait une seule fois au début et stocké dans une variable.
Il n'y a pas besoin de 'parenthéser' les return ou les if.
'/'+str(cptA)+'/'+str(cptB)+'/'+str(i) devient en plus concis/lisible (et plus rapide je pense) '/%s/%s/%s' % (cptA, cptB, i) (les string ont aussi une méthode format() mais je suis resté à mes vieilles habitudes).
Ça fait longtemps que <> est obsolète au profit de !=.