Ce que je dis, c'est qu'en entretien, si le sujet est abordé par le recruteur, il suffise que je dise que je ne soumets pas mon code à des tests unitaires pour que la plupart d'entre eux ai un à-priori négatif à mon sujet, comme si cet état de fait était limite constitutif d'une faute professionnelle et impliquait une opposition inconditionnelle de ma part à leur mise en œuvre quelle que soit la situation.
A l'image de ce qui se passe ici. L'objet du premier commentaire à mon intervention, et d'un certains nombre des suivants, a été de tenter de prouver que j'avais tord de ne pas faire usage de tests unitaires, et ce sans même s'enquérir d'éventuelles particularités dans ma manière de développer, dans ma façon d'utiliser certains outils, ou dans que sais-je quoi d'autre encore, qui eussent pu justifier leur non-utilisation.
Je me contente simplement de faire preuve d'esprit critique à l'égard des test unitaires, et cela est perçu comme une hostilité de ma part à leur usage, quand bien même j'ai explicitement affirmé le contraire dans ce commentaire-ci.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Aussi est-ce que tu as déjà développé un programme en équipe ? Je veux dire à plusieurs sur un même programme ou librairie (et je ne parle pas de pair-programming). D'après mon expérience, dans cette situation, comme chacun ne sait jamais précisément ce que l'autre a codé, les tests fonctionnels et unitaires sont le seul moyen efficace d'éviter des régressions.
Dans le mesure où il ne me semble pas avoir signifié ou laisser entendre que j'excluais formellement tout usage de tests fonctionnels et unitaires dans la situation décrite ci-dessus, je ne vois pas ce que j'aurais pu écrire à ce sujet qui aurait fait avancer le débat…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Je reprend donc la dernière phrase de ton premier commentaire :
Bref, un développeur, s'il ne se conforme pas à un certains nombre d'usages, même s'il apporte la preuve que ces usages ne sont nullement nécessaires pour faire du développement logiciel de manière efficace, n'a quasiment aucune chance de passer un entretien avec succès.
[…]
Cette phrase signifie, associée au paragraphe sur les tests unitaires, qu'il existe au moins une situation (la mienne) dans laquelle ne pas écrire de tests unitaires n'influe pas de manière significative sur la qualité globale du code produit, et que cela constitue au moins une exception à une règle qui, parce qu'elle s'est trouvée vérifiée dans leur propre situation, ou dans les situations dont ils ont eu connaissance, a été érigée en dogme par beaucoup.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Mes commentaires n'ont absolument pas pour but de jeter le moindre discrédit sur les tests unitaires ou de mettre en doute leur utilité. Au contraire, j'encourage fortement tout un chacun d'écrire des tests unitaires pour les programmes qu'ils développent. Mes propres programmes ne s'en porteraient certainement pas plus mal si je les soumettais à une batterie de tests unitaires. Seulement, il se trouve que, dans ma situation actuelle, avec les outils que j'utilise, de la manière dont je les utilise, le gain que m'apporteraient les tests unitaires est tellement faible par rapport au temps que je devrais consacrer à leur mise en œuvre que cette mise en œuvre n'est économiquement pas justifiable. Si cette situation devait évoluer, que le nombre de bogues entachant mes programmes augmentait de telle manière que cela le justifierait, je n'aurais absolument aucun état d'âme à mettre en place des tests unitaires.
Parce que j'ai l'audace de ne pas écrire de tests unitaires pour mes programmes, et surtout l'outrecuidance de m'en justifier au lieu de faire repentance, et voilà qu'on me jette l'anathème (bon, j'avoue, j'exagère un peu :-> ). Les réaction à mes commentaires vont exactement dans le sens de ce que j'affirmais dans la dernière phrase de mon premier commentaire.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Pour en revenir au C/C++, si l'on code un logiciel en utilisant directement des fonctions des bibliothèques systèmes ou standards, il est indispensable d'écrire des tests unitaires. Si on appelle, par exemple, la fonction 'memcpy()', il est nécessaire de s'assurer, par ces tests, que les paramètres passés à cette fonction, quelles que soient les circonstances, soient toujours cohérents, sous peine de se retrouver avec un 'segfault' en production ou, pire, un comportement erratique de l'application, dont il sera très difficile de diagnostiquer l'origine, et donc d'y apporter les corrections nécessaires.
Dans mon cas, je ne fais jamais appel directement à des fonctions des bibliothèques standards ou systèmes. J'utilise un framework maison qui, lui, utilise bien entendu ces fonctions. Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation, dont celles qui pourraient mener à un appel à des fonctions comme 'memcpy()' avec des paramètres incohérents, soit détectées et signalées. Ainsi, même des cas de figure qui mènerait à un appel à une fonction comme 'memcpy()' avec des paramètres corrects, mais algorithmiquement faux, sont détectés et signalés.
Ce framework est utilisé dans toutes mes programmes. Personnellement, j'utilise quotidiennement plusieurs outils, basés sur ce framework, que j'ai développés, ce qui fait que je détecte les éventuels problèmes du framework bien avant qu'ils n’apparaissent chez les utilisateurs de mes logiciels. De ce fait, à l'usage, ce framework se révèle extrêmement fiable.
Je ne sais pas si c'est cela qui fait la différence, mais, à ton expérience sur un projet mené sans écrire de tests, avec, pour conséquence, d’après tes dires, une augmentation des coûts, je ne peux que t'opposer mon expérience concernant l'ensemble des mes programmes, que j'ai développé sans écrire de tests unitaires, et qui ne présentent qu’extrêmement rarement des bugs une fois en production. Et si bugs il y a, leur correction est presque toujours triviale.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
…c'est surtout ne pas faire preuve d'originalité !
Je suis développeur professionnel depuis plus de 12 ans, durant lesquels j'ai développé moult programmes, du petit utilitaire en ligne de commande, à la grosse application client/serveur, dont j'ai réalisé, et la partie serveur, et les clients pour les différentes interfaces (native, Web…). Les programmes que j'écris, en plus d'être portables, sont conçus de manière à être fiables, performants, économes en ressources et évolutifs, et les retours que j'en ai de leurs utilisateurs m'incite à penser qu'ils répondent à ces critères de manière plus que satisfaisante.
A priori, j'ai un profil susceptible d'intéresser un certain nombre d'entreprises. Pourtant, je pense que j'échouerai dans la plupart des entretiens 'standards' de recrutement, d'autant plus si ces derniers sont réalisés par des SSII.
Douze années de développement, durant lesquelles j'ai essentiellement codé en C++. Cela ne devrait-il pas faire de moi un spécialiste de ce langage ? Sauf que, dans les faits, je n'ai pas les connaissances communément admises comme nécessaires pour pouvoir me qualifier comme tel. Par exemple, je n'ai jamais, mais alors vraiment jamais, utilisé la STL, bien qu'il n'y ai pas un seul de mes programmes qui ne fasse un usage intensif des 'template's.
A mon avis, déjà là, je suis grillé.
Plusieurs applications client/serveur, autant la partie serveur que client, multiplate-formes qui plus est ? Je devrais connaître les bibliothèques de gestion des sockets, du multitâche, des mutex et consorts sur le bout des doigts ! Que nenni ! Parce que j'utilise des bibliothèques maisons qui prennent en charge ces éléments. Par exemple, pour la partie serveur, j'ai une bibliothèque qui gère un objet prenant un numéro de port et un 'callback', et qui, à chaque requête sur le port qui va bien, appelle la fonction adéquate du 'callback'. Bien sûr, lorsque j'ai écrit cette bibliothèque, j'ai étudié les sockets, le multitâche, les mutexes et consorts de manière approfondie. Mais, depuis qu'elle est fonctionnelle, et à part quand j'y apporte des modifications, ce qui est très rare, je ne me suis plus jamais penché sur ces éléments.
Grillé une seconde fois.
Les bonnes pratiques. Je n'écris pas de tests unitaires. En soi, je n'ai rien contre ; c'est rassurant d'utiliser du code dont on sait qu'il a passé avec succès tout une batterie de tests. Seulement, je n'ai pas le temps. Le fait est que je factorise mon code le plus possible, ce qui fait que les bugs sont très vite détectés, et donc corrigés, lors de l'utilisation courante du code incriminé. Bien sûr, il m'arrive de tomber sur des bugs particulièrement ch…, emm…, ardu, genre qui se déclenche lorsque l'application est compilé en configuration 'release', mais pas 'debug', ou celui qui surgit de manière aléatoire, ou encore celui qui, bien que le même compilateur soit utilisé pour les deux, survient sur une architecture ARM, mais pas x86… Probablement que la plupart de ces bugs auraient été détectés lors de tests unitaires. Cependant, ce genre de bug est rarissime, et le temps que je prends pour les corriger est négligeable en comparaison du temps nécessaire à l'écriture systématique de tests unitaires.
Et de trois !
Bref, un développeur, s'il ne se conforme pas à un certains nombre d'usages, même s'il apporte la preuve que ces usages ne sont nullement nécessaires pour faire du développement logiciel de manière efficace, n'a quasiment aucune chance de passer un entretien avec succès.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Le Monde.fr a le plaisir de vous offrir la lecture de cet article habituellement réservé aux abonnés du Monde.fr. Profitez de tous les articles réservés du Monde.fr en vous abonnant à partir de 1€ / mois | Découvrez l'édition abonnés
mais sinon, c'est lisible sans peine.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?
Je pense notamment a une documentation d'API. Connaître toutes les directives pour chaque langage la partie xml et des documentations d'API pour leurs utilisation en C/C++ et Java.
Ah oui, la doc. sur l'API… Le problème, c'est qu'une documentation là-dessus n'aurait pas de sens sans documentation sur le framework sur lequel elle s'appuie, les deux étant imbriqués (p. ex., autant le parser XML que le préprocesseur proprement dit font partie intégrante du framework). Or, cette documentation est inexistante (même moi, utilisateur quotidien de ce framework, n'en ai pas). Et rédiger une documentation sur un framework qui existe depuis plus de dix ans, et qui n'a cessé d'évoluer depuis, représente un travail titanesque, d'autant plus que les concepts mis en œuvre sont un peu particuliers.
Je ne peux entreprendre un tel travail sans être sûr d'avoir un minimum de retour sur investissement sous une forme ou une autre. Oui, je sais, c'est le serpent qui se mord la queue ; personne ne s’intéressera au code tant qu'il n'y aura pas de doc., et je ne rédigerais pas de doc. tant que personne ne s’intéressera au code. Et, en tout honnêteté, la documentation je ne sais pas (ce qui a toujours grever mes notes de projet durant mes études d’informatique) et je n'aime pas faire (les deux étant probablement liés), ce qui n'aide pas…
Pour cet usage, pouvoir placer directement les directives de transformation dans les fichiers sources me semble plus pratique que de maintenir un fichier dédié à part, comme c'est le cas avec XSLT.
Je comprends, dans d'autres cas ça peut être considéré comme une contrainte. C'est à prendre en compte.
d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux
C'est pour ça que je te demandais le positionnement de l'un par rapport à l'autre. Pour quelqu'un qui découvre, quand on parle de transformation xml on a le réflexe de penser à XSL (du coup c'est peut être un point à ajouter dans ta FAQ ? :) ).
C'est l'éternel problème. A force d'utiliser cet outil quotidiennement, les différences entre les deux approches me paraissent tellement évidentes que j'ai du mal à concevoir que ce ne soit pas le cas pour tout le monde. Ceci dit, je pensais que l'exemple dans la page des directives était suffisamment explicite pour mettre en évidence ces différences.
J'en demande des trucs, hein ?
Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)
En tout cas je te remercie ça m'a l'aire vraiment intéressant. Je testerais quand j'aurais l'occasion de me confronter à ce genre de choses.
Merci à toi de t'y intéresser :-) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Ce que les gens viennent voir c'est ce que va leur apporter expp, l'installer c'est après avoir découvert combien c'est bien.
En effet, je vais modifier la page d’accueil en conséquence.
Je n'ai par contre pas vu de documentation exhaustive.
Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?
Comment se place expp par rapport à XSLT qui me semble a les même objectifs ? Il est plus simple ? Plus rapide ? Il permet des choses en plus ?
De l'usage que je fais d'XSLT, la finalité n’est pas du tout la même. Un document issu d'une transformation XSLT est généralement radicalement différent du document source, genre une page XHTML destinée a être affichée dans un navigateur Web avec mise en forme des données stockés dans le fichier XML auquel est appliquée la transformation.
Concernant 'expp', je m'en sers, par exemple, pour générer, pour mes applications, à partir d'un même jeu de fichiers, des fichiers de configurations différents, dont seuls quelques détails changent par rapport au contenu des fichiers d'origine. Pour cet usage, pouvoir placer directement les directives de transformation dans les fichiers sources me semble plus pratique que de maintenir un fichier dédié à part, comme c'est le cas avec XSLT.
Au final, 'expp' plus simple que XSLT ? Pour l'usage que j'en fais, oui. Plus rapide ? Étant plus simple, il y a des chances, mais je n'ai pas testé (d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux). Permet-il plus de chose ? Non, mais ce que permet 'expp' est mis en œuvre de manière différente.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
J'avais programmé la même chose sur une Casio fx-7000G (oui, ça date…) qui me donnait les résultats sous forme de nombres réels. Beaucoup de mes camarades de classe avait un programme similaire sur leur calculatrice. Par contre, j'étais le seul à avoir écris un programme qui prenait en entrée des nombres réels et en donnait les rationnels correspondants.
Nous avions quelques examens avec des exercices impliquant la résolution d'un système d'équations, et pour lesquels le détail de la résolution n'était pas demandé. Le temps que je gagnais alors à ne pas avoir à résoudre ces systèmes à la main, je pouvais le consacrer aux autres exercices, en conséquence de quoi j'avais systématiquement la meilleur note.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Juste par curiosité (j'habite hélas un peu trop loin pour pouvoir me rendre sur place), un Nokia N900 (Maemo), avec Gnumeric dessus, ça l'aurait fait pour les deux livres ?
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
En informatique musicale (notamment dans le cadre de la norme MIDI), la vélocité fait référence à la vitesse (donc indirectement à la force)
Encore vrai, tu fais bien de préciser qu'il s'agit d'informatique musicale (plus précisément de musique assistée par ordinateur, soit plutôt de musique informatisée…), mais reconnais qu'il s'agit bien de cette notion de vélocité (je devrais dire velocity…) dont parlais Tanguy.
Effectivement, dans le domaine des claviers numériques, la notion de vélocité rejoint bien celle exprimée par Tanguy. Cependant, comme il faisait référence au piano (à priori acoustique) dans son message, et que la notion de vélocité a une toute autre signification dans ce contexte, il m'a semblé utile d'apporter quelques précisions. C'est pour cela d'ailleurs que j'ai fait débuter mon message par 'Pas tout à fait', et non pas par 'C'est inexact' :-).
En tous cas tu joues super bien du piano, bravo. Tu joues depuis combien de temps ? Est-ce que tu joues/aimes Chopin ?
Je te remercie ; ça fait toujours plaisir de constater que le résultat de nombreuses heures de travail est apprécié :-) !
Ceci dit, personnellement, bien que je trouvais mes prestations tout à fait honorables au moment où je les ai publiées, je trouve maintenant la plupart médiocres à tout juste passables, à tel point que j'évite des les écouter, de peur d'être saisi d'une irrépressible envie de les effacer… Il faut dire que ma dernière publication date de plus d'un an, et que j'espère avoir fait quelques progrès dans l'intervalle ;-) !
Sinon, ça fait un peu plus de 4 ans que j'ai pris mon premier cours de piano (avril 2008). Jusqu'à présent, j'ai surtout travaillé des œuvres de compositeurs français (Debussy, Ravel, Fauré…), mais j'essaye de diversifier mon répertoire avec effectivement du Chopin (dont je suis en train de travailler une mazurka), du Liszt, du Prokofiev… justement histoire de découvrir mes préférences en la matière.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
En musique, la vélocité fait référence à la capacité d'un interprète à exécuter une œuvre à grande vitesse.
En informatique musicale (notamment dans le cadre de la norme MIDI), la vélocité fait référence à la vitesse (donc indirectement à la force) à laquelle une touche d'un clavier est enfoncée. Généralement, le générateur produit un son d'autant plus fort (en fonction d'une courbe prédéfinie) que la touche est enfoncée rapidement. Selon le degré de sophistication du générateur, le volume sonore n'est souvent pas le seul paramètre modifié ; il peut y avoir également, entre autres, modification du timbre.
Parler de dynamique me paraît plus approprié. C'est l'un des principaux apports du piano, d'où son nom originel, le piano-forte.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.
Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Comme retour d'expérience, je peux évoquer un logiciel de gestion documentaire que j'ai développé (et sur lequel je travaille encore pour apporter des améliorations), et qui est déployé chez plusieurs clients.
Ce logiciel est composé de 2 parties. Une partie prenant en charge le traitement (appelé 'backend'), et une partie prenant en charge l'interface (appelée 'frontend').
Le 'backend' est développé en C/C++ (j’entends par là en utilisant le langage C++, mais avec uniquement les bibliothèques systèmes et les bibliothèques C standards ; pas de bibliothèques C++). Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne, mais n'a pas été déployé (faute ce client en faisant la demande), également sous MacOS.
Le 'frontend' avec interface graphique native s’appuie sur XULRunner et est également développé en C/C++, avec mise en œuvre de XML, XSLT, XUL et XPCOM. Il tourne et est déployé chez des clients sous Windows. Il tourne également, sans avoir été déployé, faute de client en ayant fait la demande, sous Linux. Quand à MacOS, il y a une version en cours de développement. En fait, ça tourne, sauf qu'il n'y a pas de menus, à cause d'une particularité de MacOS (problème d'installation, qui devrait être résolu dés que j'aurais le temps de m'en occuper).
La particularité de ce logiciel, c'est qu'il a également un 'frontend' web, développé en natif (eh oui, ce n'est pas contradictoire). Ce 'frontend', qui prend la forme d'une CGI, a également été développé en C/C++, avec mise en œuvre de XML, XSLT et HTML . L'articulation des fonctionnalités étant identique pour le frontend web (CGI) et natif (XULRunner), une grosse partie du code est commun aux deux. Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne également sous MacOS, sans avoir été déployé, toujours faute de demande de la part des clients.
Concernant les plateformes mobiles, j'ai réussis à compiler et faire tourner l'application ('backend' ET 'frontend's) sous Maemo sur un Nokia N900, mais cela n'a évidemment jamais été déployé chez des clients :-> !
Pour résumer, on a donc là une application multiplateforme (Windows, Linux et MacOS) développée en C/C++, dont la partie interface graphique native s’appuie sous XULRunner. En étant discipliné et organisé, faire du développement multiplateforme en C/C++ ne pose absolument aucune difficulté. Concrètement, grâce à un framework maison, je développe mes logiciels sous Windows avec Visual C++, et, pour les faire tourner sous Linux ou MacOS, il me suffit de les recompiler sur la plateforme en question.
Petit réserve concernant 'rsync'.
Il m'arrive de faire une sauvegarde complète de fichiers sous 'Windows', en utilisant 'rsync' sous 'Cygwin', à destination de la carte mémoire de mon smartphone branché via USB, en mode UMS donc. Je réalise ensuite régulièrement des sauvegardes incrémentales, toujours en utilisant 'rsync' sous 'Cygwin', mais en me connectant au smartphone (qui est sous 'GNU/Linux') par Wi-Fi.
J'ai dû écrire un script qui recule l'horodatage de modification des fichiers de 1 ou 2 heures, selon que l'on soit en heure d'hiver ou d'été, que je dois lancer immédiatement après la sauvegarde complète, sinon la première sauvegarde incrémentale transfère l’ensemble des fichiers, et non pas seulement ceux qui ont été modifiés depuis la sauvegarde complète.
J'ai cherché dans les options de 'rsync', mais je n’ai rien trouvé qui permette de me passer de mon script. Si quelqu'un à une idée…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Il m'arrive de développer des applications WEB, et, bien que j'utilise également C++ dans ce cas (ça va encore me valoir des remarques des pro-JavaScript, ça), je n'utilise pas XULRunner pour ces dernières.
Pour faire des applications WEB, le couple XULRunner + C++ n'est peut-être pas pas le plus adapté, puisqu'il faudrait fournir le code C++ compilé pour chaque plate-forme cible, alors que si l'application n'utilise que JavaScript, elle tournera d'office sur tout les plate-formes sur lesquelles tourne XULRunner.
XULRunner, je ne l'utilise donc que pour des applications pour lesquelles je veux fournir une interface native. Et j'en n'utilise que les éléments relatifs à la gestion de l'interface graphique. Pour tout le reste (gestion des fichiers, du réseau, du multitâche...), j'ai mes propres outils. Donc, que XULRunner, Qt ou autres technologies aient de supers outils pour gérer ces éléments, ça m'importe peu...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Certes. Mais tu t'embarques dans un truc pas adapté, donc qui te prend 10 fois plus de temps à réaliser que si tu utilisais des outils plus adaptés. C'est comme si tu utilisais un rateau pour faire un trou, alors que si tu utilisais une pelle, tu serais plus efficace.
En prenant un toolkit 100% C++ (puisqu'il semble que ce soit ton langage de prédilection), comme Qt, tu pourrais te concentrer plus sur les éléments de ton framework plutôt que sur des contournements de la plateforme...
XULRunner est écrit en C++. Son SDK fournit une API C++. Je crois que, de ce fait, on peut le qualifier de toolkit 100% C++. Il ne manque que la documentation adéquate pour l'utiliser en tant que tel, et ce sans un contournement d'aucune sorte.
d'autant plus si l'on n'a aucune affinité avec JavaScript...
Oui donc tu t'es trompé de plateforme à mon sens...
Si j'ai choisi XUL pour de nombreux développements (depuis des années), c'est bien pour le coté "web" de la plateforme (donc XML/XUL/CSS ET Javascript). Si je voulais faire une appli entièrement en C++, je ne choisirais certainement pas XULRunner...
C'est clair que, avec la démocratisation des technologies WEB, c'est effectivement ce coté WEB qui a été mis en avant, car susceptible de toucher le plus grand nombre de personnes. Il n'en demeure pas moins que XULRunner, de par sa conception, est parfaitement adapté pour une utilisation avec C++ en lieu et place de JavaScript, n'était ce manque de documentation.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Tu ne nous dis pas en quoi XUL t'apporte quelque chose que ne pourrait pas t'apporter Qt avec Quick par exemple, qui permet de décrire de façon très puissante des interfaces dans un format de fichier.
Parce que c'est hors sujet et que je ne saurais répondre à cette question, ne connaissant que très peu ces technologies !
Je ne veux, par ce journal, pousser personne à préférer XULRunner à d'autres technologies, mais s'il se trouve quelqu'un qui, quelles qu’en soient les raisons, décide d'utiliser XULRunner en combinaison avec C++, ce journal l'informe simplement de l'existence d'une source d'informations, que j'espère pertinentes, sur le sujet.
Accessoirement, pour ce que j'en ai lu, Qt Quick n'existait pas lorsque j'ai été amené à choisir XULRunner.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Quel est l'avantage de XUL sur GtkBuilder ou QML si c'est pour faire une application en C++ à 100% ?
Pour ma part, ne ne connaissant guère ces deux technologies, je ne saurais répondre. Je laisserais donc aux connaisseurs le soin de répondre à cette question, si tel est leur bon plaisir...
Soit dit en passant, mon intention, à travers ce journal, n'a jamais été de laisser entendre que XUL(Runner), avec ou sans C++, puisse, ou non, être supérieur à d'autres technologies similaires ...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Donc tu passes 10 fois plus de temps à implémenter un truc (des listeners et autres trucs d'interface), pour un résultat qui n'apporte au final rien en terme de perf (au niveau de l'UI).
Sans entrer dans un débat JavaScript vs C++, il se trouve que je dispose d'outils, qui sont d'ailleurs utilisés dans l'application citée dans ce journal, grâce auxquels je mets nettement moins de temps à implémenter un 'truc' en C++ qu'en JavaScript, et que je ne suis probablement pas le seul, d'où ce journal.
disclamer : je fais du xpcom c++ depuis des années...
Moi aussi. Et ?
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
moui ok, je comprend mieux le principe de ton truc. Mais quand même, comme je dis, ça n'apporte rien en terme de perf, au niveau de l'interface utilisateur, sauf si tu manipules à tour de bras des centaines d’éléments XUL. En tout cas le rapport (productivité, facilité de dev, de maintenance etc)/performance est très très faible.
Ça apporte peut-être peu, mais certainement pas rien en terme de performances, vu qu'on évite la surcouche JavaScript. Néanmoins, les performances ne sont pas, à mon avis, le critère déterminant. Il se trouve que, pour moi (et certainement pour d'autres, d'où ce journal), la productivité, la facilité de développement et de maintenance sont nettement plus élevés en C++ qu'en JavaScript.
Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement'
Pourtant, tout est indiqué sur la doc de la balise tree, https://developer.mozilla.org/en/XUL/tree , en particulier les interfaces qu'elle utilise, et donc ses propriétés dont la view etc. Etant donné que les objets DOM accessibles en JS sont simplement un accés XPCom aux objets C++ correspondant... Et par le passé, XulPlanet.org était encore mieux documenté au niveau des interfaces etc..
Sauf que cette page est résolument orientée JavaScript, avec des exemples, alors que pour C++, il faut procéder par déduction en fouillant également dans les fichiers d'entête C++ fournis avec le SDK XULRunner.
Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?
Pour être plus productif ? Pour faciliter les contributions ? Pour avoir un outil plus performant ? pour avoir une interface web agréable à utiliser ? (le browser CVS est juste horrible).
(Je vais m'abstenir de répondre à ce propos, d'une part parce qu'il est hors-sujet, et, d'autre part, parce que ma précédente intervention sur le sujet ayant été prise au pied de la lettre).
M'enfin chacun utilise ce qu'il veut :-)
On est bien d'accord, c'est pour cela que j'utilise C++ à la place de JavaScript, et si d'autres préfère JavaScript, grand bien leur fasse :-) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
Le but de XulRunner n'est pas un framework/une plateforme pour écrire une appli entièrement en C++.
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Pourquoi ne pas utiliser QT ou autre toolkit graphique ?? Parce que si dans ton projet, l'utilisation du JS est à proscrire, tu t'es, à mon avis, trompé de framework.
Comme dit dans un précédent commentaire, étant donné que l'API JavaScript de XULRunner n'est qu'une surcouche à des objets C++, cela ne me semble totalement dénué de sens de court-circuiter JavaScript pour accéder à ces objets directement en C++, d'autant plus si l'on n'a aucune affinité avec JavaScript...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
oui, je me pose exactement la même question. D'après ce que j'ai compris, on n'a plus à utiliser de gestionnaire d'évènement ou autres trucs "webesque" de XulRunner. Et en gros, tout le code de l'appli est dans des libs externes en C/C++.
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++. Comme en JavaScript, on a toujours un gestionnaire d'évènement à implémenter, mais il sera implémenté en C++. Et tout le code de l’application est effectivement dans une bibliothèque externe.
Et au final aussi, un truc à la XPCom à été recodé en passant par XPCom. Au final on a donc une couche qui transmet des appels vers les libs externe, donc comme XPCom. -> double couche logicielle pour accéder à la lib externe. à moins d'avoir rien compris au bidule :-)
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
Bon, sinon, de la doc sur XPCOM C++, elle existe quand même https://developer.mozilla.org/en/XPCOM. Et il y a aussi une alternative, pour accéder directement aux fonctions d'une lib : js-ctypes.
Je connais cette documentation (XPCOM), et l'ai abondamment utilisée. Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement', et que pour avoir l'index de l’élément sélectionné dans ce 'tree', il fallait d'abord faire un 'GetView(...)', sur le résultat duquel il faut ensuite faire un 'GetSelection(...)', sur le résultat duquel il faut faire 'GetCurrentIndex(...)'. Quand à 'js-ctypes', c'est apparemment essentiellement pour faire du C...
(hors sujet: CVS, c'est vraiment pénible, je recommande d'utiliser un gestionnaire de source récent :-p)
(Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?)
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1. Dernière modification le 22 juillet 2013 à 17:21.
Ce que je dis, c'est qu'en entretien, si le sujet est abordé par le recruteur, il suffise que je dise que je ne soumets pas mon code à des tests unitaires pour que la plupart d'entre eux ai un à-priori négatif à mon sujet, comme si cet état de fait était limite constitutif d'une faute professionnelle et impliquait une opposition inconditionnelle de ma part à leur mise en œuvre quelle que soit la situation.
A l'image de ce qui se passe ici. L'objet du premier commentaire à mon intervention, et d'un certains nombre des suivants, a été de tenter de prouver que j'avais tord de ne pas faire usage de tests unitaires, et ce sans même s'enquérir d'éventuelles particularités dans ma manière de développer, dans ma façon d'utiliser certains outils, ou dans que sais-je quoi d'autre encore, qui eussent pu justifier leur non-utilisation.
Je me contente simplement de faire preuve d'esprit critique à l'égard des test unitaires, et cela est perçu comme une hostilité de ma part à leur usage, quand bien même j'ai explicitement affirmé le contraire dans ce commentaire-ci.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.
Je suppose que tu fais référence à ça :
Dans le mesure où il ne me semble pas avoir signifié ou laisser entendre que j'excluais formellement tout usage de tests fonctionnels et unitaires dans la situation décrite ci-dessus, je ne vois pas ce que j'aurais pu écrire à ce sujet qui aurait fait avancer le débat…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.
Cette phrase signifie, associée au paragraphe sur les tests unitaires, qu'il existe au moins une situation (la mienne) dans laquelle ne pas écrire de tests unitaires n'influe pas de manière significative sur la qualité globale du code produit, et que cela constitue au moins une exception à une règle qui, parce qu'elle s'est trouvée vérifiée dans leur propre situation, ou dans les situations dont ils ont eu connaissance, a été érigée en dogme par beaucoup.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Les tests unitaires, c'est bon, mangez-en :-)
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1.
Mes commentaires n'ont absolument pas pour but de jeter le moindre discrédit sur les tests unitaires ou de mettre en doute leur utilité. Au contraire, j'encourage fortement tout un chacun d'écrire des tests unitaires pour les programmes qu'ils développent. Mes propres programmes ne s'en porteraient certainement pas plus mal si je les soumettais à une batterie de tests unitaires. Seulement, il se trouve que, dans ma situation actuelle, avec les outils que j'utilise, de la manière dont je les utilise, le gain que m'apporteraient les tests unitaires est tellement faible par rapport au temps que je devrais consacrer à leur mise en œuvre que cette mise en œuvre n'est économiquement pas justifiable. Si cette situation devait évoluer, que le nombre de bogues entachant mes programmes augmentait de telle manière que cela le justifierait, je n'aurais absolument aucun état d'âme à mettre en place des tests unitaires.
Parce que j'ai l'audace de ne pas écrire de tests unitaires pour mes programmes, et surtout l'outrecuidance de m'en justifier au lieu de faire repentance, et voilà qu'on me jette l'anathème (bon, j'avoue, j'exagère un peu :-> ). Les réaction à mes commentaires vont exactement dans le sens de ce que j'affirmais dans la dernière phrase de mon premier commentaire.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 1. Dernière modification le 20 juillet 2013 à 11:26.
Pour en revenir au C/C++, si l'on code un logiciel en utilisant directement des fonctions des bibliothèques systèmes ou standards, il est indispensable d'écrire des tests unitaires. Si on appelle, par exemple, la fonction 'memcpy()', il est nécessaire de s'assurer, par ces tests, que les paramètres passés à cette fonction, quelles que soient les circonstances, soient toujours cohérents, sous peine de se retrouver avec un 'segfault' en production ou, pire, un comportement erratique de l'application, dont il sera très difficile de diagnostiquer l'origine, et donc d'y apporter les corrections nécessaires.
Dans mon cas, je ne fais jamais appel directement à des fonctions des bibliothèques standards ou systèmes. J'utilise un framework maison qui, lui, utilise bien entendu ces fonctions. Mais les objets gérés par ce framework sont écrits de telle manière que toute mauvaise utilisation, dont celles qui pourraient mener à un appel à des fonctions comme 'memcpy()' avec des paramètres incohérents, soit détectées et signalées. Ainsi, même des cas de figure qui mènerait à un appel à une fonction comme 'memcpy()' avec des paramètres corrects, mais algorithmiquement faux, sont détectés et signalés.
Ce framework est utilisé dans toutes mes programmes. Personnellement, j'utilise quotidiennement plusieurs outils, basés sur ce framework, que j'ai développés, ce qui fait que je détecte les éventuels problèmes du framework bien avant qu'ils n’apparaissent chez les utilisateurs de mes logiciels. De ce fait, à l'usage, ce framework se révèle extrêmement fiable.
Je ne sais pas si c'est cela qui fait la différence, mais, à ton expérience sur un projet mené sans écrire de tests, avec, pour conséquence, d’après tes dires, une augmentation des coûts, je ne peux que t'opposer mon expérience concernant l'ensemble des mes programmes, que j'ai développé sans écrire de tests unitaires, et qui ne présentent qu’extrêmement rarement des bugs une fois en production. Et si bugs il y a, leur correction est presque toujours triviale.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# Ce qu'on demande à un développeur aujourd'hui...
Posté par Claude SIMON (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 10.
…c'est surtout ne pas faire preuve d'originalité !
Je suis développeur professionnel depuis plus de 12 ans, durant lesquels j'ai développé moult programmes, du petit utilitaire en ligne de commande, à la grosse application client/serveur, dont j'ai réalisé, et la partie serveur, et les clients pour les différentes interfaces (native, Web…). Les programmes que j'écris, en plus d'être portables, sont conçus de manière à être fiables, performants, économes en ressources et évolutifs, et les retours que j'en ai de leurs utilisateurs m'incite à penser qu'ils répondent à ces critères de manière plus que satisfaisante.
A priori, j'ai un profil susceptible d'intéresser un certain nombre d'entreprises. Pourtant, je pense que j'échouerai dans la plupart des entretiens 'standards' de recrutement, d'autant plus si ces derniers sont réalisés par des SSII.
Douze années de développement, durant lesquelles j'ai essentiellement codé en C++. Cela ne devrait-il pas faire de moi un spécialiste de ce langage ? Sauf que, dans les faits, je n'ai pas les connaissances communément admises comme nécessaires pour pouvoir me qualifier comme tel. Par exemple, je n'ai jamais, mais alors vraiment jamais, utilisé la STL, bien qu'il n'y ai pas un seul de mes programmes qui ne fasse un usage intensif des 'template's.
A mon avis, déjà là, je suis grillé.
Plusieurs applications client/serveur, autant la partie serveur que client, multiplate-formes qui plus est ? Je devrais connaître les bibliothèques de gestion des sockets, du multitâche, des mutex et consorts sur le bout des doigts ! Que nenni ! Parce que j'utilise des bibliothèques maisons qui prennent en charge ces éléments. Par exemple, pour la partie serveur, j'ai une bibliothèque qui gère un objet prenant un numéro de port et un 'callback', et qui, à chaque requête sur le port qui va bien, appelle la fonction adéquate du 'callback'. Bien sûr, lorsque j'ai écrit cette bibliothèque, j'ai étudié les sockets, le multitâche, les mutexes et consorts de manière approfondie. Mais, depuis qu'elle est fonctionnelle, et à part quand j'y apporte des modifications, ce qui est très rare, je ne me suis plus jamais penché sur ces éléments.
Grillé une seconde fois.
Les bonnes pratiques. Je n'écris pas de tests unitaires. En soi, je n'ai rien contre ; c'est rassurant d'utiliser du code dont on sait qu'il a passé avec succès tout une batterie de tests. Seulement, je n'ai pas le temps. Le fait est que je factorise mon code le plus possible, ce qui fait que les bugs sont très vite détectés, et donc corrigés, lors de l'utilisation courante du code incriminé. Bien sûr, il m'arrive de tomber sur des bugs particulièrement
ch…,emm…, ardu, genre qui se déclenche lorsque l'application est compilé en configuration 'release', mais pas 'debug', ou celui qui surgit de manière aléatoire, ou encore celui qui, bien que le même compilateur soit utilisé pour les deux, survient sur une architecture ARM, mais pas x86… Probablement que la plupart de ces bugs auraient été détectés lors de tests unitaires. Cependant, ce genre de bug est rarissime, et le temps que je prends pour les corriger est négligeable en comparaison du temps nécessaire à l'écriture systématique de tests unitaires.Et de trois !
Bref, un développeur, s'il ne se conforme pas à un certains nombre d'usages, même s'il apporte la preuve que ces usages ne sont nullement nécessaires pour faire du développement logiciel de manière efficace, n'a quasiment aucune chance de passer un entretien avec succès.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# Si c'est juste pour lire l’article, ...
Posté par Claude SIMON (site web personnel) . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 1.
…dans Firefox, JavaScript désactivé :
Ctrl-A Ctrl-Cpuis, dans votre éditeur de texte préféré:
Ctrl-VIl faut chercher le début, et il y a ça dedans :
mais sinon, c'est lisible sans peine.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Doc
Posté par Claude SIMON (site web personnel) . En réponse au journal Nouvelle version de 'expp', le préprocesseur XML du projet Epeios.. Évalué à 1.
Ah oui, la doc. sur l'API… Le problème, c'est qu'une documentation là-dessus n'aurait pas de sens sans documentation sur le framework sur lequel elle s'appuie, les deux étant imbriqués (p. ex., autant le parser XML que le préprocesseur proprement dit font partie intégrante du framework). Or, cette documentation est inexistante (même moi, utilisateur quotidien de ce framework, n'en ai pas). Et rédiger une documentation sur un framework qui existe depuis plus de dix ans, et qui n'a cessé d'évoluer depuis, représente un travail titanesque, d'autant plus que les concepts mis en œuvre sont un peu particuliers.
Je ne peux entreprendre un tel travail sans être sûr d'avoir un minimum de retour sur investissement sous une forme ou une autre. Oui, je sais, c'est le serpent qui se mord la queue ; personne ne s’intéressera au code tant qu'il n'y aura pas de doc., et je ne rédigerais pas de doc. tant que personne ne s’intéressera au code. Et, en tout honnêteté, la documentation je ne sais pas (ce qui a toujours grever mes notes de projet durant mes études d’informatique) et je n'aime pas faire (les deux étant probablement liés), ce qui n'aide pas…
C'est l'éternel problème. A force d'utiliser cet outil quotidiennement, les différences entre les deux approches me paraissent tellement évidentes que j'ai du mal à concevoir que ce ne soit pas le cas pour tout le monde. Ceci dit, je pensais que l'exemple dans la page des directives était suffisamment explicite pour mettre en évidence ces différences.
Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)
Merci à toi de t'y intéresser :-) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Doc
Posté par Claude SIMON (site web personnel) . En réponse au journal Nouvelle version de 'expp', le préprocesseur XML du projet Epeios.. Évalué à 2.
En effet, je vais modifier la page d’accueil en conséquence.
Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?
De l'usage que je fais d'XSLT, la finalité n’est pas du tout la même. Un document issu d'une transformation XSLT est généralement radicalement différent du document source, genre une page XHTML destinée a être affichée dans un navigateur Web avec mise en forme des données stockés dans le fichier XML auquel est appliquée la transformation.
Concernant 'expp', je m'en sers, par exemple, pour générer, pour mes applications, à partir d'un même jeu de fichiers, des fichiers de configurations différents, dont seuls quelques détails changent par rapport au contenu des fichiers d'origine. Pour cet usage, pouvoir placer directement les directives de transformation dans les fichiers sources me semble plus pratique que de maintenir un fichier dédié à part, comme c'est le cas avec XSLT.
Au final, 'expp' plus simple que XSLT ? Pour l'usage que j'en fais, oui. Plus rapide ? Étant plus simple, il y a des chances, mais je n'ai pas testé (d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux). Permet-il plus de chose ? Non, mais ce que permet 'expp' est mis en œuvre de manière différente.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # De l'intérêt d'une calculatrice bien programmée
Posté par Claude SIMON (site web personnel) . En réponse au journal Un Ipad dans la liste des fournitures scolaires. Évalué à 2.
J'avais programmé la même chose sur une Casio fx-7000G (oui, ça date…) qui me donnait les résultats sous forme de nombres réels. Beaucoup de mes camarades de classe avait un programme similaire sur leur calculatrice. Par contre, j'étais le seul à avoir écris un programme qui prenait en entrée des nombres réels et en donnait les rationnels correspondants.
Nous avions quelques examens avec des exercices impliquant la résolution d'un système d'équations, et pour lesquels le détail de la résolution n'était pas demandé. Le temps que je gagnais alors à ne pas avoir à résoudre ces systèmes à la main, je pouvais le consacrer aux autres exercices, en conséquence de quoi j'avais systématiquement la meilleur note.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: repartir avec un livre
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche LinuxFr.org au salon Solutions Linux 2012. Évalué à 2.
Juste par curiosité (j'habite hélas un peu trop loin pour pouvoir me rendre sur place), un Nokia N900 (Maemo), avec Gnumeric dessus, ça l'aurait fait pour les deux livres ?
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Il y a Bach sans Gould et Bach avec Gould...
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 3.
Effectivement, dans le domaine des claviers numériques, la notion de vélocité rejoint bien celle exprimée par Tanguy. Cependant, comme il faisait référence au piano (à priori acoustique) dans son message, et que la notion de vélocité a une toute autre signification dans ce contexte, il m'a semblé utile d'apporter quelques précisions. C'est pour cela d'ailleurs que j'ai fait débuter mon message par 'Pas tout à fait', et non pas par 'C'est inexact' :-).
Je te remercie ; ça fait toujours plaisir de constater que le résultat de nombreuses heures de travail est apprécié :-) !
Ceci dit, personnellement, bien que je trouvais mes prestations tout à fait honorables au moment où je les ai publiées, je trouve maintenant la plupart médiocres à tout juste passables, à tel point que j'évite des les écouter, de peur d'être saisi d'une irrépressible envie de les effacer… Il faut dire que ma dernière publication date de plus d'un an, et que j'espère avoir fait quelques progrès dans l'intervalle ;-) !
Sinon, ça fait un peu plus de 4 ans que j'ai pris mon premier cours de piano (avril 2008). Jusqu'à présent, j'ai surtout travaillé des œuvres de compositeurs français (Debussy, Ravel, Fauré…), mais j'essaye de diversifier mon répertoire avec effectivement du Chopin (dont je suis en train de travailler une mazurka), du Liszt, du Prokofiev… justement histoire de découvrir mes préférences en la matière.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Il y a Bach sans Gould et Bach avec Gould...
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Les Variations Goldberg dans le domaine public. Évalué à 7.
Pas tout à fait.
En musique, la vélocité fait référence à la capacité d'un interprète à exécuter une œuvre à grande vitesse.
En informatique musicale (notamment dans le cadre de la norme MIDI), la vélocité fait référence à la vitesse (donc indirectement à la force) à laquelle une touche d'un clavier est enfoncée. Généralement, le générateur produit un son d'autant plus fort (en fonction d'une courbe prédéfinie) que la touche est enfoncée rapidement. Selon le degré de sophistication du générateur, le volume sonore n'est souvent pas le seul paramètre modifié ; il peut y avoir également, entre autres, modification du timbre.
Parler de dynamique me paraît plus approprié. C'est l'un des principaux apports du piano, d'où son nom originel, le piano-forte.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# Compiler pour le Nokia N900 (ARMv7)
Posté par Claude SIMON (site web personnel) . En réponse au journal Chaine(s) de compilation ARM. Évalué à 6.
Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.
Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# Logiciel de gestion documentaire mutiplateforme
Posté par Claude SIMON (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 10.
Comme retour d'expérience, je peux évoquer un logiciel de gestion documentaire que j'ai développé (et sur lequel je travaille encore pour apporter des améliorations), et qui est déployé chez plusieurs clients.
Ce logiciel est composé de 2 parties. Une partie prenant en charge le traitement (appelé 'backend'), et une partie prenant en charge l'interface (appelée 'frontend').
Le 'backend' est développé en C/C++ (j’entends par là en utilisant le langage C++, mais avec uniquement les bibliothèques systèmes et les bibliothèques C standards ; pas de bibliothèques C++). Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne, mais n'a pas été déployé (faute ce client en faisant la demande), également sous MacOS.
Le 'frontend' avec interface graphique native s’appuie sur XULRunner et est également développé en C/C++, avec mise en œuvre de XML, XSLT, XUL et XPCOM. Il tourne et est déployé chez des clients sous Windows. Il tourne également, sans avoir été déployé, faute de client en ayant fait la demande, sous Linux. Quand à MacOS, il y a une version en cours de développement. En fait, ça tourne, sauf qu'il n'y a pas de menus, à cause d'une particularité de MacOS (problème d'installation, qui devrait être résolu dés que j'aurais le temps de m'en occuper).
La particularité de ce logiciel, c'est qu'il a également un 'frontend' web, développé en natif (eh oui, ce n'est pas contradictoire). Ce 'frontend', qui prend la forme d'une CGI, a également été développé en C/C++, avec mise en œuvre de XML, XSLT et HTML . L'articulation des fonctionnalités étant identique pour le frontend web (CGI) et natif (XULRunner), une grosse partie du code est commun aux deux. Il tourne et est déployé chez des clients sous Windows et Linux. Il tourne également sous MacOS, sans avoir été déployé, toujours faute de demande de la part des clients.
Concernant les plateformes mobiles, j'ai réussis à compiler et faire tourner l'application ('backend' ET 'frontend's) sous Maemo sur un Nokia N900, mais cela n'a évidemment jamais été déployé chez des clients :-> !
Pour résumer, on a donc là une application multiplateforme (Windows, Linux et MacOS) développée en C/C++, dont la partie interface graphique native s’appuie sous XULRunner. En étant discipliné et organisé, faire du développement multiplateforme en C/C++ ne pose absolument aucune difficulté. Concrètement, grâce à un framework maison, je développe mes logiciels sous Windows avec Visual C++, et, pour les faire tourner sous Linux ou MacOS, il me suffit de les recompiler sur la plateforme en question.
Pour avoir plus de détails concernant la mise en œuvre de XULRunner, je renvoie à un de mes précédents journaux (http://linuxfr.org/users/epeios/journaux/xulrunner-et-c).
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Quand Windows change d'heure, les fichiers aussi
Posté par Claude SIMON (site web personnel) . En réponse au journal Bug de sauvegarde.. Évalué à 1.
Petit réserve concernant 'rsync'.
Il m'arrive de faire une sauvegarde complète de fichiers sous 'Windows', en utilisant 'rsync' sous 'Cygwin', à destination de la carte mémoire de mon smartphone branché via USB, en mode UMS donc. Je réalise ensuite régulièrement des sauvegardes incrémentales, toujours en utilisant 'rsync' sous 'Cygwin', mais en me connectant au smartphone (qui est sous 'GNU/Linux') par Wi-Fi.
J'ai dû écrire un script qui recule l'horodatage de modification des fichiers de 1 ou 2 heures, selon que l'on soit en heure d'hiver ou d'été, que je dois lancer immédiatement après la sauvegarde complète, sinon la première sauvegarde incrémentale transfère l’ensemble des fichiers, et non pas seulement ceux qui ont été modifiés depuis la sauvegarde complète.
J'ai cherché dans les options de 'rsync', mais je n’ai rien trouvé qui permette de me passer de mon script. Si quelqu'un à une idée…
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# Essai avec '<'
Posté par Claude SIMON (site web personnel) . En réponse à l’entrée du suivi caractère < qui coupe les commentaires. Évalué à 1 (+0/-0).
<fonctionne, du moins en prévisualisation. Par contre, le commentaire après<disparaît même en prévisualisation.Essai avec
<: avant < après.Essai avec
<: avantCyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 2.
Me voici ! :-)
Il m'arrive de développer des applications WEB, et, bien que j'utilise également C++ dans ce cas (ça va encore me valoir des remarques des pro-JavaScript, ça), je n'utilise pas XULRunner pour ces dernières.
Pour faire des applications WEB, le couple XULRunner + C++ n'est peut-être pas pas le plus adapté, puisqu'il faudrait fournir le code C++ compilé pour chaque plate-forme cible, alors que si l'application n'utilise que JavaScript, elle tournera d'office sur tout les plate-formes sur lesquelles tourne XULRunner.
XULRunner, je ne l'utilise donc que pour des applications pour lesquelles je veux fournir une interface native. Et j'en n'utilise que les éléments relatifs à la gestion de l'interface graphique. Pour tout le reste (gestion des fichiers, du réseau, du multitâche...), j'ai mes propres outils. Donc, que XULRunner, Qt ou autres technologies aient de supers outils pour gérer ces éléments, ça m'importe peu...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 4.
Cf. précédent commentaire.
XULRunner est écrit en C++. Son SDK fournit une API C++. Je crois que, de ce fait, on peut le qualifier de toolkit 100% C++. Il ne manque que la documentation adéquate pour l'utiliser en tant que tel, et ce sans un contournement d'aucune sorte.
C'est clair que, avec la démocratisation des technologies WEB, c'est effectivement ce coté WEB qui a été mis en avant, car susceptible de toucher le plus grand nombre de personnes. Il n'en demeure pas moins que XULRunner, de par sa conception, est parfaitement adapté pour une utilisation avec C++ en lieu et place de JavaScript, n'était ce manque de documentation.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 5.
Parce que c'est hors sujet et que je ne saurais répondre à cette question, ne connaissant que très peu ces technologies !
Je ne veux, par ce journal, pousser personne à préférer XULRunner à d'autres technologies, mais s'il se trouve quelqu'un qui, quelles qu’en soient les raisons, décide d'utiliser XULRunner en combinaison avec C++, ce journal l'informe simplement de l'existence d'une source d'informations, que j'espère pertinentes, sur le sujet.
Accessoirement, pour ce que j'en ai lu, Qt Quick n'existait pas lorsque j'ai été amené à choisir XULRunner.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 3.
Pour ma part, ne ne connaissant guère ces deux technologies, je ne saurais répondre. Je laisserais donc aux connaisseurs le soin de répondre à cette question, si tel est leur bon plaisir...
Soit dit en passant, mon intention, à travers ce journal, n'a jamais été de laisser entendre que XUL(Runner), avec ou sans C++, puisse, ou non, être supérieur à d'autres technologies similaires ...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 2.
Voir mon précédent commentaire.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 3.
Sans entrer dans un débat JavaScript vs C++, il se trouve que je dispose d'outils, qui sont d'ailleurs utilisés dans l'application citée dans ce journal, grâce auxquels je mets nettement moins de temps à implémenter un 'truc' en C++ qu'en JavaScript, et que je ne suis probablement pas le seul, d'où ce journal.
Moi aussi. Et ?
Ça apporte peut-être peu, mais certainement pas rien en terme de performances, vu qu'on évite la surcouche JavaScript. Néanmoins, les performances ne sont pas, à mon avis, le critère déterminant. Il se trouve que, pour moi (et certainement pour d'autres, d'où ce journal), la productivité, la facilité de développement et de maintenance sont nettement plus élevés en C++ qu'en JavaScript.
Sauf que cette page est résolument orientée JavaScript, avec des exemples, alors que pour C++, il faut procéder par déduction en fouillant également dans les fichiers d'entête C++ fournis avec le SDK XULRunner.
(Je vais m'abstenir de répondre à ce propos, d'une part parce qu'il est hors-sujet, et, d'autre part, parce que ma précédente intervention sur le sujet ayant été prise au pied de la lettre).
On est bien d'accord, c'est pour cela que j'utilise C++ à la place de JavaScript, et si d'autres préfère JavaScript, grand bien leur fasse :-) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Pourquoi pas un autre toolkit ?
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 1.
Je ne vois en quoi le fait que ce ne soit pas le but devrait m'empêcher de le faire...
Comme dit dans un précédent commentaire, étant donné que l'API JavaScript de XULRunner n'est qu'une surcouche à des objets C++, cela ne me semble totalement dénué de sens de court-circuiter JavaScript pour accéder à ces objets directement en C++, d'autant plus si l'on n'a aucune affinité avec JavaScript...
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Intérêt
Posté par Claude SIMON (site web personnel) . En réponse au journal XULRunner et C++.. Évalué à 7.
On code l'application exactement comme on le ferait en JavaScript, sauf qu'on utilise C++. Comme en JavaScript, on a toujours un gestionnaire d'évènement à implémenter, mais il sera implémenté en C++. Et tout le code de l’application est effectivement dans une bibliothèque externe.
Lorsque l'on code une application en JavaScript, on accède en fait à des composants écrits en C++ à travers leur interface JavaScript. L'idée c'est d’accéder à ces composants directement en C++, sans passer par JavaScript. On a donc, au contraire, une couche logicielle en moins...
Je connais cette documentation (XPCOM), et l'ai abondamment utilisée. Mais elle ne détaille pas comment manipuler un élément XUL en C++. Par exemple, je n'ai trouvé aucune documentation qui indique qu'un élément 'tree' en XUL correspond, en C++, à l'objet 'nsIDOMXULTreeElement', et que pour avoir l'index de l’élément sélectionné dans ce 'tree', il fallait d'abord faire un 'GetView(...)', sur le résultat duquel il faut ensuite faire un 'GetSelection(...)', sur le résultat duquel il faut faire 'GetCurrentIndex(...)'. Quand à 'js-ctypes', c'est apparemment essentiellement pour faire du C...
(Ça fait plus de 11 ans que j'utilise le CVS de savannah.gnu.org. Pourquoi changer quelque chose qui fonctionne ?)
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !