Et si l'on veut absolument ne pas utiliser les exceptions C++ (ou que l'on veut disposer de quelque chose de comparable en C), on peut utiliser la bibliothèque standard setjmp pour les simuler, mais j'ignore si c'est rentable par rapport aux exceptions en terme de coûts...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
De mémoire, pour ce que j'en ai compris, -fno-rtti ne désactive pas les exceptions. Les d'informations relevant du mécanisme de runtime type identification nécessitées par ces dernières étant de toute façon générées, -fno-rtti ou pas.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Je n'y connais absolument rien en Fortran, donc ce qui va suivre est peut-être, voire probablement, totalement inapplicable.
Le fait est qu'il y a moyen de permuter deux entiers sans passer par un troisième, avec l'opérateur XOR. En reprenant l'exemple en question, à la sauce C (^ étant l'opérateur XOR bit à bit) :
p2 = p1 ^ p2;
p1 = p2 ^ p1;
p2 = p1 ^ p2;
Suite à une recherche rapide sur le Web, Il semblerait que gfortran ai une opérateur XOR bit à bit ('IEOR', d'après ce que j'ai trouvé). Évidemment, cela ne suffit pas, car, s'il n'est pas possible d'appliquer cet opérateur directement sur des pointeurs (ce qui ne m'étonnerait pas outre mesure), il faut réussir à 'convertir' des pointeurs en entiers (sous condition que ces derniers ai la bonne taille) et vice-versa...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Je ne suis pas un spécialiste du C++ 'standard', mais, de manière générale, une méthode 'const' ne devrait appeler que des méthodes 'const'.
Je m'étais moi-même trouvé dans une situation ou une méthode, qui ne modifiait pas fondamentalement l'objet sur lequel elle s'appliquait, d'où sa qualification en 'const', modifiait néanmoins un de ses membres (dans mon cas, c'était un cache), ce que le compilateur ne manqua pas de me faire remarquer de manière péremptoire tout en refusant de mener à terme son travail. Pour résoudre ce problème, j'ai déclaré le cache en question en 'mutable', ce qui m'a permis de laisser la méthode en 'const', à la grande satisfaction de mon compilateur, qui ne pipa plus mot.
Concrètement, pour le code présenté, pour ce que j'en ai compris, je déclarerais 'is_initialzed' en 'mutable', ce qui permettrait de déclarer 'initialize()' en 'const', et il n'y aurait plus besoin que d'une seule méthode 'mean' déclarée en 'const'. Ça devrait fonctionner, mais je ne sais pas si conceptuellement ça tient la route, car un 'initialize()' en 'const' me semble bizarre...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Pour les 'simples' GPS TomTom, ils fournissent une application, appelée 'TomTom Home'. Or, cette application, du moins la version que j'en ai, est une application qui tourne sous 'XULRunner', qui est un environnement d'exécution qui existe également sous Linux. Le code de ces applications est généralement écrit en JavaScript, donc indépendant de la plateforme d'exécution.
J'ignore ce qui est fourni avec ta montre GPS, si c'est la même application, ou une autre s'exécutant également dans 'XULRunner', mais, le cas échéant, à moins qu'il n'y ai une partie en code natif, il suffit, en théorie, de récupérer sous Linux le répertoire d'installation de l'application, d'installer la bonne version de 'XULRunner', en fonction du 'MaxVersion' et du 'MinVersion' définis dans le fichier '.ini' présent à la racine de là où est installée l'application ('XULRunner' peut être installé par le gestionnaire de paquets de 'Debian' ; encore faut-il que la bonne version soit disponible), et de lancer 'XULRunner', en lui passant en paramètre ce même fichier '.ini', pour que l'application s'exécute telle quelle sous Linux...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Je ne suis pas spécialiste en la matière, mais utiliser un convertisseur 24 bits sur un signal 16 bits devrait permettre de mettre en œuvre une interpolation plus fine, donc d'obtenir un signal plus proche du signal d'origine, et cela avant que ce dernier ne subisse un éventuel traitement électronique.
Du moins, c'est comme ça que je me justifie mon achat d'un DAC 24 bits pour écouter mes CDs rippés :-).
Accessoirement, toujours lorsque c'est utilisé sur un signal 16 bits, ça devrait évite les déformations de ce dernier lors d'une éventuelle atténuation dû au ReplayGain.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
RMS, c'est pour moyenner correctement une sinusoïde par rapport à un signal continu (de mémoire, c'est une racine carré de 2 qui traine).
RMS signifie, en anglais, Richard M. Stall... euh, pardon..., Root Mean Square, c'est-à-dire, en traduisant, la racine (carrée) de la moyenne des carrés (ah, si toutes les formules pouvaient être aussi faciles à retenir...).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Pour autant que je me rappelle, GFA Basic n'était pas fourni avec l'Atari ; il fallait se le procurer à part.
En outre, nul besoin d'avoir un Atari ; GFA Basic était également disponible sur l'Amiga (bah oui, faut respecter les traditions ; on ne peut parler d'Atari sans évoquer Amiga, surtout un vendredi...).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
... quand je dis parler fort, c'est parlé très fort. Chose qu'on ne peut faire qu'en utilisant son thorax.
Ah non, on peut également, et c'est préférable, utiliser l'abdomen. C'est plus efficace et cela a un effet relaxant, contrairement à la respiration thoracique...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
New Project Submissions Re-enabled
posté par mjflick, mar. 22 nov. 2011 21:52:31 UTC - 0 réponse
Thanks to the efforts of new volunteers, we've re-enabled new project submissions.
Volunteers are still needed. If you're able and interested in volunteering please write savannah-hackers-public@gnu.org (or -private) if you prefer
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Les critiques au sujet de Sourceforge ne datent pas d'aujourd'hui, ni d'hier.
A partir de 2000, j'avais utilisé leurs services pour un de mes projets, jusqu'au jour où j'ai eu connaissance d'un article dénonçant certaines dérives de leur part. Je ne me rappelle plus quels étaient les griefs (désolé), mais toujours est-il que j'ai migré mon projet vers Savannah, apparemment en 2002, donc l'article en question devait dater de cette période...
D'après Wikipedia, Savannah, qui n'hébergeait que des projets GNU à l'origine, s'est ouvert aux projets non-GNU justement suite à ce qui fût perçu comme une dérive de Sourceforge (et de son logiciel).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
... c'est possible, avec XUL(Runner).
Pour avoir une idée de ce que ça donne en terme de portabilité et de ce que l'on peut réaliser avec, il suffit de lancer Firefox. Et pour ceux qui préfèrent utiliser C++ au lieu de JavaScript, c'est également possible. Sachant que l'on peut également utiliser C++ pour coder une application Android (ainsi que iOS), étant partisan du moindre effort, mon choix a été vite fait :-) !
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Tu comprends bien qu'on est plus trop ici dans l'optique "que faisiez vous avant ?" mais plutôt "qu'êtes vous prêt à faire avec nous ?" et que si tu insistes en disant que tu as pris l'habitude de bosser sans tests unitaires, si l'autre en face n'est pas né de la dernière pluie, va interpréter ça comme "ouais alors lui, je pense qu'il aime pas les tests unitaires, il a des années de stratégie d'évitement (pas forcément au sens négatif du terme) pour les utiliser, ça va pas l'faire avec nous car on bosse en équipe avec parfois des stagiaires qui mettent les mains dans le code, ou bien seulement des gens qui veulent optimiser une routine bas niveau la veille de la mise en prod' et paf le chien"
Je partage tout à fait cette analyse, c'est pour cela que j'ai précisé "si le sujet est abordé par le recruteur". Il est clair que si j'en parlais de ma propre initiative, cela pourrait être perçu comme une revendication, et je comprendrais que cela soit mal perçu. Mais si le recruteur me demande, voyant que j'ai quelques programmes à mon actif, si je les soumets à des tests unitaires, je ne vais pas mentir juste pour lui faire plaisir, d'autant qu'il risque de me demander de lui montrer le code correspondant, auquel cas je serais bien ennuyé. Le problème c'est que, même dans ce contexte, ben ça passe mal...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
Sauf cas extrême (Linux en est un), si tu as trouvé une manière de développer, une facon d'utiliser certains outils, ou que sais-je quoi d'autre qui permet d'avoir la même qualité à long terme en ce passant de une partie importante du cout de développement d'un logiciel, écrit un bouquin tu es riche, très riche... Autrement c'est pipo.
Je me borne à rapporter un fait. J'écris du code, je ne le soumets pas à des tests unitaires, et il fonctionne de manière satisfaisante, autant du point de vue de ses usagers dans son utilisation quotidienne, que du mien en terme de maintenabilité et d'évolutivité. Maintenant, bien que j'ai quelques idées à ce sujet, je n'ai jamais lancé d'étude approfondie visant à en déterminer les raisons. Peut-être que je devrais. En tout cas, tu comprendras je ne vais pas me lancer dans la rédaction d'un ouvrage sur le sujet, ce qui représente une tâche conséquente, sur la seule foi de tes affirmations...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
...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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Correction
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Il y a aussi fenêtre : défenestration. Il existe d'ailleurs aussi fenestration, mais c'est moins courant...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Index
Posté par Claude SIMON (site web personnel) . En réponse au journal Occupy Hollywood : libérer l’homme et son outil de travail. Évalué à 5.
Ce journal porte certes sur la libération des outils, mais l'acteur de Lawrence d'Arabie, ce n'est pas Peter O'Tool, mais Peter O'Toole...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: XML
Posté par Claude SIMON (site web personnel) . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
Mince, va falloir que je reprenne rendez-vous avec mon psy :
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable/xml.h
- http://hg.savannah.gnu.org/hgweb/epeios/file/tip/stable/xml.cpp
Ah ben non, ça ne sera finalement peut-être pas nécessaire...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: '-fno-rtti' et exceptions.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 1. Dernière modification le 23 février 2014 à 21:53.
Et si l'on veut absolument ne pas utiliser les exceptions C++ (ou que l'on veut disposer de quelque chose de comparable en C), on peut utiliser la bibliothèque standard
setjmppour les simuler, mais j'ignore si c'est rentable par rapport aux exceptions en terme de coûts...Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # '-fno-rtti' et exceptions.
Posté par Claude SIMON (site web personnel) . En réponse au journal Apple, le SSL les goto et les accolades. Évalué à 2.
De mémoire, pour ce que j'en ai compris,
-fno-rttine désactive pas les exceptions. Les d'informations relevant du mécanisme de runtime type identification nécessitées par ces dernières étant de toute façon générées,-fno-rttiou pas.Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# Permutation sans variable intermédiaire
Posté par Claude SIMON (site web personnel) . En réponse au message Permutation "sure" de pointeurs en Fortran. Évalué à 1. Dernière modification le 10 janvier 2014 à 14:21.
Je n'y connais absolument rien en Fortran, donc ce qui va suivre est peut-être, voire probablement, totalement inapplicable.
Le fait est qu'il y a moyen de permuter deux entiers sans passer par un troisième, avec l'opérateur XOR. En reprenant l'exemple en question, à la sauce C (^ étant l'opérateur XOR bit à bit) :
Suite à une recherche rapide sur le Web, Il semblerait que gfortran ai une opérateur XOR bit à bit ('IEOR', d'après ce que j'ai trouvé). Évidemment, cela ne suffit pas, car, s'il n'est pas possible d'appliquer cet opérateur directement sur des pointeurs (ce qui ne m'étonnerait pas outre mesure), il faut réussir à 'convertir' des pointeurs en entiers (sous condition que ces derniers ai la bonne taille) et vice-versa...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# 'mutable' ?
Posté par Claude SIMON (site web personnel) . En réponse au message Appeler une méthode non-const à partir de la méthode const homonyme. Évalué à 4. Dernière modification le 08 janvier 2014 à 18:22.
Je ne suis pas un spécialiste du C++ 'standard', mais, de manière générale, une méthode 'const' ne devrait appeler que des méthodes 'const'.
Je m'étais moi-même trouvé dans une situation ou une méthode, qui ne modifiait pas fondamentalement l'objet sur lequel elle s'appliquait, d'où sa qualification en 'const', modifiait néanmoins un de ses membres (dans mon cas, c'était un cache), ce que le compilateur ne manqua pas de me faire remarquer de manière péremptoire tout en refusant de mener à terme son travail. Pour résoudre ce problème, j'ai déclaré le cache en question en 'mutable', ce qui m'a permis de laisser la méthode en 'const', à la grande satisfaction de mon compilateur, qui ne pipa plus mot.
Concrètement, pour le code présenté, pour ce que j'en ai compris, je déclarerais 'is_initialzed' en 'mutable', ce qui permettrait de déclarer 'initialize()' en 'const', et il n'y aurait plus besoin que d'une seule méthode 'mean' déclarée en 'const'. Ça devrait fonctionner, mais je ne sais pas si conceptuellement ça tient la route, car un 'initialize()' en 'const' me semble bizarre...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# Exécuter l'application fournie sous Linux ?
Posté par Claude SIMON (site web personnel) . En réponse au message Communication avec montre tomtom multisport. Évalué à 2. Dernière modification le 23 décembre 2013 à 14:11.
Pour les 'simples' GPS TomTom, ils fournissent une application, appelée 'TomTom Home'. Or, cette application, du moins la version que j'en ai, est une application qui tourne sous 'XULRunner', qui est un environnement d'exécution qui existe également sous Linux. Le code de ces applications est généralement écrit en JavaScript, donc indépendant de la plateforme d'exécution.
J'ignore ce qui est fourni avec ta montre GPS, si c'est la même application, ou une autre s'exécutant également dans 'XULRunner', mais, le cas échéant, à moins qu'il n'y ai une partie en code natif, il suffit, en théorie, de récupérer sous Linux le répertoire d'installation de l'application, d'installer la bonne version de 'XULRunner', en fonction du 'MaxVersion' et du 'MinVersion' définis dans le fichier '.ini' présent à la racine de là où est installée l'application ('XULRunner' peut être installé par le gestionnaire de paquets de 'Debian' ; encore faut-il que la bonne version soit disponible), et de lancer 'XULRunner', en lui passant en paramètre ce même fichier '.ini', pour que l'application s'exécute telle quelle sous Linux...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # DAC 24 bits sur signal 16 bits.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche NwAvGuy O2 : l’amplificateur casque sous licence Creative Common. Évalué à 1.
Je ne suis pas spécialiste en la matière, mais utiliser un convertisseur 24 bits sur un signal 16 bits devrait permettre de mettre en œuvre une interpolation plus fine, donc d'obtenir un signal plus proche du signal d'origine, et cela avant que ce dernier ne subisse un éventuel traitement électronique.
Du moins, c'est comme ça que je me justifie mon achat d'un DAC 24 bits pour écouter mes CDs rippés :-).
Accessoirement, toujours lorsque c'est utilisé sur un signal 16 bits, ça devrait évite les déformations de ce dernier lors d'une éventuelle atténuation dû au ReplayGain.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Électronique
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche NwAvGuy O2 : l’amplificateur casque sous licence Creative Common. Évalué à 5. Dernière modification le 19 décembre 2013 à 13:14.
RMS signifie, en anglais, Richard M. Stall... euh, pardon..., Root Mean Square, c'est-à-dire, en traduisant, la racine (carrée) de la moyenne des carrés (ah, si toutes les formules pouvaient être aussi faciles à retenir...).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# Atari ST <=/=> GFA Basic
Posté par Claude SIMON (site web personnel) . En réponse au message Pour le retour du GFABasic. Évalué à 4. Dernière modification le 29 novembre 2013 à 17:59.
Pour autant que je me rappelle, GFA Basic n'était pas fourni avec l'Atari ; il fallait se le procurer à part.
En outre, nul besoin d'avoir un Atari ; GFA Basic était également disponible sur l'Amiga (bah oui, faut respecter les traditions ; on ne peut parler d'Atari sans évoquer Amiga, surtout un vendredi...).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: Sur les exposés
Posté par Claude SIMON (site web personnel) . En réponse au journal 3 ans de projets libre: bilan et apprentissages. Évalué à 6.
Ah non, on peut également, et c'est préférable, utiliser l'abdomen. C'est plus efficace et cela a un effet relaxant, contrairement à la respiration thoracique...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: L'histoire se répète...
Posté par Claude SIMON (site web personnel) . En réponse au journal Gimp envoie bouler Sourceforge. Évalué à 3.
J'ai finalement retrouvé l’article en question : http://www.advogato.org/article/376.html.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: L'histoire se répète...
Posté par Claude SIMON (site web personnel) . En réponse au journal Gimp envoie bouler Sourceforge. Évalué à 3.
Je ne voulais pas signifier par mon message qu'il fallait nécessairement laisser tomber Sourceforge pour Savannah...
Ceci dit, juste au-dessus (lien) :
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# L'histoire se répète...
Posté par Claude SIMON (site web personnel) . En réponse au journal Gimp envoie bouler Sourceforge. Évalué à 6.
Les critiques au sujet de Sourceforge ne datent pas d'aujourd'hui, ni d'hier.
A partir de 2000, j'avais utilisé leurs services pour un de mes projets, jusqu'au jour où j'ai eu connaissance d'un article dénonçant certaines dérives de leur part. Je ne me rappelle plus quels étaient les griefs (désolé), mais toujours est-il que j'ai migré mon projet vers Savannah, apparemment en 2002, donc l'article en question devait dater de cette période...
D'après Wikipedia, Savannah, qui n'hébergeait que des projets GNU à l'origine, s'est ouvert aux projets non-GNU justement suite à ce qui fût perçu comme une dérive de Sourceforge (et de son logiciel).
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# JavaScript sans HTML5...
Posté par Claude SIMON (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à -1.
... c'est possible, avec XUL(Runner).
Pour avoir une idée de ce que ça donne en terme de portabilité et de ce que l'on peut réaliser avec, il suffit de lancer Firefox. Et pour ceux qui préfèrent utiliser C++ au lieu de JavaScript, c'est également possible. Sachant que l'on peut également utiliser C++ pour coder une application Android (ainsi que iOS), étant partisan du moindre effort, mon choix a été vite fait :-) !
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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é à 2.
Je partage tout à fait cette analyse, c'est pour cela que j'ai précisé "si le sujet est abordé par le recruteur". Il est clair que si j'en parlais de ma propre initiative, cela pourrait être perçu comme une revendication, et je comprendrais que cela soit mal perçu. Mais si le recruteur me demande, voyant que j'ai quelques programmes à mon actif, si je les soumets à des tests unitaires, je ne vais pas mentir juste pour lui faire plaisir, d'autant qu'il risque de me demander de lui montrer le code correspondant, auquel cas je serais bien ennuyé. Le problème c'est que, même dans ce contexte, ben ça passe mal...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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 me borne à rapporter un fait. J'écris du code, je ne le soumets pas à des tests unitaires, et il fonctionne de manière satisfaisante, autant du point de vue de ses usagers dans son utilisation quotidienne, que du mien en terme de maintenabilité et d'évolutivité. Maintenant, bien que j'ai quelques idées à ce sujet, je n'ai jamais lancé d'étude approfondie visant à en déterminer les raisons. Peut-être que je devrais. En tout cas, tu comprendras je ne vais pas me lancer dans la rédaction d'un ouvrage sur le sujet, ce qui représente une tâche conséquente, sur la seule foi de tes affirmations...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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...
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
# 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.
Zelbinium: pour la génération qui crée, pas celle qui scrolle...