Tes impôts servent à financer plein de choses utiles et d'autres moins utile. Dans la seconde catégorie on pense aux politiques inconstantes qui coulent les entreprises dont l'État est actionnaire (transport ferroviaire et éléctricité par exemple)
Construire une machine à voter, pour attirer l'attention des élèves sur les problématiques de la confidentialité et de la vérifiabilité du vote, peut-être un projet intéressant sur plusieurs plans!
On trouve des métronomes-accordeurs avec 5-6 fonctions, même si le produit fini (par exemple Korg MA-1, c'est le mien) vaut dans les 10-15 euros, ça peut avoir le côté sympa de “je l'ai fait moi-même” même pour ceux qui pourraient en avoir l'usage et en possèdent très certainement déjà un.
Comme on a un baby-foot dans notre salle de détente (cliché de start-up? Oui ;) ) un collègue pensait fabriquer un détecteur de buts qui pourrait publier des résultats sur un gestionnaire de championnats en ligne, comme https://www.kicker.cool Je n'ai aucune idée de la faisabilité, de la complexité, etc. mais l'idée est en tout cas marrante.
Je programme en METAPOST – c'est si on veut l'ancêtre, toujours bien vivant, d'asymptote et de tikz – pour produire diverses sorte de diagrammes. Voir Blueprint. C'est un langage plutôt déclaratif (pour les équations linéaires) et basé sur des remplacements de macros, donc une chose assez bizarre à programmer. Mais lorsqu'on s'y met on peut produire des interfaces déclaratives pour les diagrammes, qui sont assez sympa à utiliser, voir par exemple:
Si tu as des choses concrètes à partager n'hésite pas à le faire. Pour ma part j'ai eu l'occasion de travailler pour une entreprise qui utilisait la stratégie décrite par le premier commentaire, et c'est essentiellement ce qui m'a poussé à démissionner. Je suis parti parceque d'une part je ne cautionne pas cela, d'autre part parceque les gens qui baisent leurs clients baisent aussi leurs employés. L'expérience montre que ce n'est pas partout comme cela.
La vraie naïveté c'est de croire que le pessimisme peut tenir lieu d'expérience.
Plutôt du commercial que tu ne veux pas dans ta boîte parcequ'il ne s'intéresse visiblement pas trop à la relation avec le client ni à la bonne réputation de l'entreprise. Ne pas savoir dire “désolé j'ai merdé je n'ai pas tenu les dates, on a eu tel et tel problème“ est la signature de l'amateurisme.
Ça me paraît aussi bizarre. Ce qu'il faut faire – il me semble – c'est plutôt préparer une mini API http-json et un petit serveur qui la fait tourner, plutôt que d'ouvrir comme ça les entrailles de la bêbête!
Je milite également pour que l'on soit plus rigoureux dans l'expression de certaine proposition, et que l'on ne dise plus : « la terre est ronde », mais plutôt : « d'un certain point vue, une équipotentielle du champ de gravitation terrestre est homéomorphe à la sphère S_2 ». :-D
Homéomorphe, c'est un peu faible, il vaudrait sûrement mieux demander qu'on puisse coincer cette équipotentielle entre deux ellipsoïdes de rayons pas trop différents. :)
Oui bien demander un difféormorphisme avec une borne sur l'intégrale de la divergence.
C’est déjà ce qu’il fait, mais ça risque de ne pas suffire.
Si il est prêt à aller à l'étranger il trouvera sans problème du travail, en Allemagne par exemple (là où je vis) on n'a pas du tout la même culture du recrutement qu'en France – ceci dit il paraît que ça s'améliore progressivement en France. Les entreprises qui pourraient s'intéresser à son profil de physicien intéresse par le numérique sont probablement les institutions financières – chercher si elles ont une section “risk management”, “operating desk of derivatives” ou un truc du genre – l'industrie automobile, ou bien tout ce qui utilise beaucoup de simulations – c'est à dire quasiment n'importe quelle industrie suffisamment grosse. En plus des “gros” acteurs les plus évidents il y a plein de petites entreprises qui font du conseil technique sur des points spécialisés et qui ont elles beaucoup plus de mal à recruter que les gros acteurs.
J'ai un profil vaguement semblable à celui de ton ami, je suis mathématicien de formation et même si j'ai beaucoup programmé pour mon plaisir personnel ou de temps en temps pour ma recherche, et même si j'ai fait quelques modules “info” pendant mes études (programmation en Scheme, calcul scientifique, algorithmique) je n'avais pas d'expérience solide en programmation en cherchant des emplois hors du monde académique.
Les entreprises ne vont en général pas s'attendre à trouver des gens qui soient à la fois des bons physiciens et des bons programmeurs, et puis la plupart des gens sont tout à fait capable d'apprendre à programmer, et les physiciens pas moins que quiconque. Donc pour commencer, je conseillerais de faire fi de toute inhibition et de poser des candidatures pour les offres qui l'intéressent, en étant tout à fait honnête sur le niveau de programmation qu'il peut avoir – qui n'est pas nul, même s'il n'est pas très élevé. S'il choisit de travailler dans une grosse structure, il aura de toutes façons un programme de novice, éventuellement de plusieurs mois, pour se former.
Ce qui est important pour ton ami, c'est d'une part d'être sûr qu'il est réellement intéressé par le travail auquel il présente son dossier, et en particulier qu'il est réellement intéressé par la programmation. C'est le point qui me semble le plus délicat.
Pour moi ce qui fait un bon programmeur, ce n'est pas tant sa capacité à écrire des programmes en elle-même, qui bien-sûr doit être là, mais la capacité à écrire du code robuste, maintenable et testable, et très franchement je ne connais pas d'autre école que celle de l'expérience. Quand je programmais chez moi je n'écrivais pas des programmes qui tournent pendant des mois et manipulent des TB de données. :)
Si ton ami veut étudier la programmation en autodidacte, le mieux pour lui est de dénicher un projet libre teinté de calcul scientifique qui l'intéresse et auquel il pourrait envisager de modifier un peu ou même de contribuer. Quelques exemples:
En comparaison la documentation de OCaml est beaucoup plus simple. Elle est écrite de façon assez “matheuse” mais à un niveau beaucoup plus élémentaire: le côté matheux de la documentation est plutôt utilisé pour décrire brièvement une fonction par une phrase générale qui inclut aussi les cas particuliers (de type liste vide, etc.). Après pour l'exemple que tu cites, je ne sais pas ce qui pousse les gens à écrire des documentations comme ça… je ne dis pas que les phrases “Formally, the class Bifunctor represents a bifunctor from Hask -> Hask. Intuitively it is a bifunctor where both the first and second arguments are covariant.” ne sont pas intéressantes mais elles sont plutôt à mettre en remarque, ou en tout cas, après la description de ce que “font” concrètement les fonctions du module.
La plupart de temps, ce qui m'agace c'est de lire de la mauvaise documentation. Voici les principales défauts que je retrouve dans les documentations avec lesquelles je dois le plus souvent travailler:
Documentation qui hésite entre la référence, l'introduction du manuel de l'utilisateur et le manuel de l'utilisateur lui-même. L'information y est mal structurée, pas au bon endroit, etc.
La documentation mal présentée, l'exemple typique est la documentation de NodeJS ou celle de l'API AWS JavaScript. La documentation n'est pas assez espacée, pas assez bien structurée – on a des descriptions d'éléments 'APIs obsolètes qui s'étendent sur plusieurs écrans au beau milieu de la description, et comme il n'y a pas d'espaces verticaux ou de mises en retrait bien visibles, on ne se s'y retrouve pas. À la rigueur le seul moyen de s'en sortir à peu près, serait de l'imprimer! Et puis comme on est en 2016 le concept de page est has been et on écrit tout dans un seul document – alors que la page est une bonne unité pour délimiter et hiérarchiser le texte.
La documentation ambigüe, où les descriptions des fonctions laissent place non pas à une interprétation possible mais à plusieurs, ou bien qui laissent en suspens des questions essentielles que tout programmeur expérimenté se pose dans certaines situations. Par exemple la documentation du SDK AWS n'arrive pas à traiter proprement les cas de “valeur”, “null” et “membre non défini” – alors que quand on documente du JavaScript, c'est évidemment la chose avec laquelle il faut être le plus propre! – ce qui oblige à faire des essais. Autre exemple la documentation de NodeJS qui, lorsqu'elle aborde les streams se garde bien de décrire, lorsqu'on utilise des streams lisant la sortie d'un processus fils, le comportement bloquant ou non de l'écriture par le processus fils. Quand on lit en détails on peut deviner ce qui se passe et essayer pour vérifier, mais ce ne devrait pas être nécessaire.
La documentation bavarde, qui au lieu d'utiliser une langue technique claire et concise se livre à des bavardages incessants. Exemple typique le manuel de GNU Make qui arrive à dire en plus de 205 pages essentiellement la même chose que les 8 pages de man du BSD Make. Pour moi c'est beaucoup plus facile de retrouver une information dans 8 pages de documentation que dans 205.
Alors évidemment tu peux dire que toutes tes fonctions te renvoient une GeneralException, mais au final ça ne donne aucune information.
Je pense que ce qu'essaie de dire barmic, c'est que certaines exceptions n'ont pas le droit d'être propagées en dehors de leur domaine et qu'on doit mettre en place des “superviseurs” qui montent la garde à la frontière d'un domaine et qui traduisent les erreurs d'un domaine en erreurs génériques, qui peuvent mentionner tous les détails utiles à l'utilisateur (sous forme d'un texte) ou bien proposer un option de récupération. Pour le cas particulier de l'UI d'une application habituelle, tout ce qui compte c'est de savoir qu'il y a eu une erreur, quel contexte afficher et si on peut récupérer l'erreur. Et c'est uniquement des erreurs de ce type que doit voir le code de l'UI.
C'est pas la première fois que la méthode scientifique passe après la propagande, mais ça n'en reste pas moins désolant.
Oui, ceci dit, les articles ne font pas cette propagande, ils sont détournés et on leur fait dire ce qu'ils ne disent pas. Ces textes cherchent surtout – du moins c'est ce que je comprends – à trouver protocole expérimental pertinent, ce qui correspondrait à un état très précoce de l'élaboration du savoir. Peut-être que certaines de ces expériences ont été menées à plus grande échelle (et pas sur un échantillon d'une centaine d'étudiants d'une fac nord-américaine, échantillon on ne peut plus biaisé de la population étatsunienne) et plusieurs fois, est-ce que ariasuni sait cela?
Salut, et bravo pour ton projet! J'ai une remarque à la limite de l'impertinence: c'et mieux d'utiliser le souligné _ que le tiret - dans les noms de programme. Hum, hum, mais pourquoi donc, te demandes-tu? La raison est que le souligné est un caractère valide dans une nom de fonction shell et pas le tiret. Donc par exemple, si dans un script shell qui utilise gfsec_split j'ai envie de tracer les appels à cet outil, simuler des conditions d'erreurs, ou plus généralement faire du “mocking” sur cet outil je peux définir une fonction gfsec_split qui ajoute le comportement souhaité, et ce de façon transparente. Mais si le programme a un tiret dans son nom, cette technique est plus laborieuse à mettre en œuvre.
Sinon une petite question mathématique: tu utilises des corps finis pour faire ton interpolation de Lagrange? Comment est-ce que tu choisis la caractéristique? Z/pZ ou bien des extensions?
Et comme je le disais, de nombreuses études ont montré que le masculin utilisé pour désigner les deux genres introduit des biais genrés qu’il me semble sain d’éliminer.
Encore et toujours, elles ne démontrent pas, elles semblent indiquer. Par exemple dans l'article de Gastil on peut lire ceci (p. 632):
The experimenters presented the results of six experiments that attempt- ed to avoid these three pitfalls. In five of these experiments, students read job descriptions from which they visualized a hypothetical person. The stu- dents then completed a 25-item Sex Stereotype Scale (SSS), rating the femi- ninity/masculinityof the hypothesized people. The first experiment validated the SSS; students rated a "flight attendant" as very feminine and a "chemi- cal engineer" as very masculine. Using the pronoun (either he, he~she, or they) as the independent variable and the SSS as the dependent measure, their second and third experiments found no significant correlation between pronoun condition and SSS score. This proved true regardless of whether the job description alluded to stereotypical or neutral occupations. The results of their fourth experiment suggested that Kidd's study (1971) was biased due to her generic use of man in conjunction with he. The fifth replicated Moul- ton et al.'s (1975) findings, then repeated their experiment using the SSS and found no significant pronoun effect. Their sixth experiment rebutted Creech and Wilson (1979), whose findings had implied that occupation type was de- termining SSS score attenuating any possible pronoun effect.
Il existe aussi des expériences qui semblent indiquer que l'usage du pronom n'*introduit *pas de biais de genre, mias Gastil continue en pensant que ces expériences induisent un biais d'observation et prétend que la sienne n'introduit pas de biais d'observation. Or pourtant, cela semble être une des difficultés majeures qu'introduit l'utilisation des statistiques dans les sciences-sociales: il faut construire un énoncé qui est susceptible d'être invalidé par une mesure puis construire une expérience qui permet de réaliser la mesure, or il n'y pas de choix univoque de la quantité à mesurer et pour chaque mesure que l'on peut se représenter, on peut imaginer 1000 expériences, qui auront toutes leurs défauts et leurs avantages. Et encore une fois, une seule mesure est insuffisante à prouver quoique ce soit, en l'absence de reproductibilité on est obligé de penser que les résultats de l'expérience sont essentiellement aléatoires.
Détruire ces idées fausses sont utiles pour cesser de considérer homme et femme comme deux idéaux opposés et complémentaires, mettre en lumière les violences exercées sur les personnes intersexes et combattre les rhétoriques transphobes qui nous pourrissent la vie.
Justement le passage du “Malentendu du Deuxième sexe” que cite Annie Le Brun est
“Seule la thèse qui émancipe le Féminin de la femme pour en étendre partiellement la sollicitation à l'autre sexe est compatible avec le maniement correct du concept d'altérité.”
Autrement dit – et semble-t-il contrairement à ce qu'écrirait Beauvoir dans le “Deuxième sexe” – il n'y a pas de “spécificité féminine” qui soit irrévocablement associée à la femme, mais au contraire féminin et masculin sont des adjectifs – et peut-être les idéaux opposés et complémentaire dont tu parles – et comme adjectifs ils sont des idées distinctes des noms homme et femme et peuvent indifféremment qualifier l'un ou l'autre.
Je réitère: ce passage est incompréhensible (en tout cas pour moi) et n’a pas de consistance (où alors je n’arrive pas à la saisir). En tout cas ça n’est clairement pas accessible à n’importe qui. Es-tu capable de me résumer clairement ce que tu comprends de passage?
Je me prête au jeu:
Le Deuxième sexe marque une date incontestable dans l'histoire du féminisme. Ce livre développe un discours médiocre mais clinquant s'articulant autour de l'existentialisme et la notion de “sensibilité féminine”. En dépit de ses carences structurelles, ce livre s'est imposé comme un ouvrage de référence de la pensée féministe. Que cela puisse arriver n'est-il pas le signe de l'affaiblissement de la révolte féminine? Ce serait une explication du silence qui a accueilli le remarquable travail de Suzanne Lilar Le Malentendu du Deuxieme Sexe.
L'idée que développe Annie Le Brun dans ce chapitre, et qui explique ce qu'elle entend par “affaiblissement” est que à l'époque de Simone de Beauvoir un petit groupe de personne s'est accaparé la parole féministe et transformé la révolte féminine, auparavant diverse et audacieuse, en mouvement politique fortement idéologique, organisé, et très peu “révolte”. Pour le dire en quelques mots “dès lors que le féminisme s'est organisé en combat il a cessé d'être une révolte”.
[…] . Et en vérité je préfère les langues qui ne m’obligent pas à préciser le genre […]
Avoir une préférence est une chose, prétendre qu'elle est la direction inéluctable, c'est une autre chose et c'est celle que je contredis.
Avoir une langue genrée nous oblige à connaitre le genre d’une personne pour en parler
Tu peux utiliser le genre non marqué, comme dans “le médecin” par exemple. C'est ta perception et ta compréhension de la langue qui te fait croire que tu dois connaître le genre d'une personne pour en parler. Mon médecin généraliste et mon pharmacien sont des femmes mais je leur dit toujours “mon médecin m'a dit que” ou “mon pharmacien m'a dit que” lorsque je parle à l'un ou l'autre puisque le fait que le médecin ou le pharmacien soit un homme ou une femme ne change rien à la qualité de ses jugements – et du reste ne regarde que moi dans cette communication.
D’ailleurs un des premiers trucs que j’ai fait dans ce fil, c’était d’affirmer que tous les hommes n’étaient pas XY et toutes les femmes n’étaient pas XX
Faire référence à des catégories aux contours flous n'est pas le privilège des mots ”femme” et “homme” mais le lot de pratiquement tous les mots du lexique.
C'est parfaitement faux - va dire ça aux patrons de nos entreprises partenaires qui recherchent des développeurs. Mais c'est comme pour toute activité pointue : ils cherchent des gens compétents ou susceptibles de le devenir rapidement, et malheureusement beaucoup de gens anciennement formés ont perdu le fil de l'évolution des techniques.
Le fait d'avoir perdu le fil de l'évolution des techniques n'est pas un problème en soi, la plupart des techniques nouvelles ou à la mode sont plutôt dans la continuité de ce qui se faisait il y a dix ans ou quinze ans. (Ce qui a beaucoup changé en revanche, c'est la guerre sans fin à la prétendue innovation que se livrent les grosses entreprises par logiciel libre interposé pour asseoir une forme de domination de leurs idées et technologies.) Très franchement aucun développeur aguerri ou même un débutant assez ambitieux ne devrait avoir de mal à se raccrocher aux branches,
Dans l'entreprise où je suis nous avons des difficultés à recruter des développeurs, pas tant à cause de l'absence de dossier, mais de la difficulté qu'il y a à identifier les profils intéressants. Par la force des choses on ne peut pas inviter tout le monde à un entretien or c'est là qu'on commence vraiment à savoir si on a envie de travailler avec le candidat à l'embauche. Malheureusement trop peu de candidats ont le courage ou la force de caractère, ou même peut-être tout simplement l'idée, de montrer vraiment qui ils sont dans leur lettre de motivation ou de mettre en lumière quelques points qui démontrent leur capacité à apprendre et s'adapter, leur capacité à produire un résultat et leurs compétences sociales. Cela paraît bête de le rappeler mais pour un employeur qui s'intéresse à une relation longue avec ses employés, ce sont des points importants pour les décisions de recrutement. (Après on peut dans des cas particuliers rechercher un sénior avec beaucoup d'expérience sur un sujet particulier, mais c'est loin d'être le gros des recrutements.)
[^] # Re: budget ?
Posté par Michaël (site web personnel) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 5.
Tes impôts servent à financer plein de choses utiles et d'autres moins utile. Dans la seconde catégorie on pense aux politiques inconstantes qui coulent les entreprises dont l'État est actionnaire (transport ferroviaire et éléctricité par exemple)
# Une machine à voter
Posté par Michaël (site web personnel) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 10.
Construire une machine à voter, pour attirer l'attention des élèves sur les problématiques de la confidentialité et de la vérifiabilité du vote, peut-être un projet intéressant sur plusieurs plans!
# Un métronome-accordeur de guitare
Posté par Michaël (site web personnel) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 3.
On trouve des métronomes-accordeurs avec 5-6 fonctions, même si le produit fini (par exemple Korg MA-1, c'est le mien) vaut dans les 10-15 euros, ça peut avoir le côté sympa de “je l'ai fait moi-même” même pour ceux qui pourraient en avoir l'usage et en possèdent très certainement déjà un.
# Un détecteur de buts pour un baby-foot
Posté par Michaël (site web personnel) . En réponse au journal Appel à idées pour prof(s) de lycée. Évalué à 6.
Comme on a un baby-foot dans notre salle de détente (cliché de start-up? Oui ;) ) un collègue pensait fabriquer un détecteur de buts qui pourrait publier des résultats sur un gestionnaire de championnats en ligne, comme https://www.kicker.cool Je n'ai aucune idée de la faisabilité, de la complexité, etc. mais l'idée est en tout cas marrante.
[^] # Re: firefox
Posté par Michaël (site web personnel) . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 2.
Celui qui utilise Linux depuis 1923? (Entre autres sujets de fierté.) On a du mal à vous suivre!
[^] # Re: dans un marchand de BD à Montrouge
Posté par Michaël (site web personnel) . En réponse au journal Pepper et Carrot. Évalué à 5.
C'est probablement une manière subtile de nous faire part de ce qu'il pense de la transaction! :)
[^] # Re: Rien de neuf
Posté par Michaël (site web personnel) . En réponse au journal Java dans le navigateur : ce n'est pas fini, ça sera pire !. Évalué à 3.
Chouette, on va bientôt pouvoir utiliser Gnus comme lecteur de messagerie dans un navigateur! :)
# En Metapost
Posté par Michaël (site web personnel) . En réponse au journal Écrire des diagrammes de séquences. Évalué à 4.
Je programme en METAPOST – c'est si on veut l'ancêtre, toujours bien vivant, d'asymptote et de tikz – pour produire diverses sorte de diagrammes. Voir Blueprint. C'est un langage plutôt déclaratif (pour les équations linéaires) et basé sur des remplacements de macros, donc une chose assez bizarre à programmer. Mais lorsqu'on s'y met on peut produire des interfaces déclaratives pour les diagrammes, qui sont assez sympa à utiliser, voir par exemple:
Un morceau de code source est
[^] # Re: re:
Posté par Michaël (site web personnel) . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 8. Dernière modification le 13 septembre 2016 à 21:40.
Si tu as des choses concrètes à partager n'hésite pas à le faire. Pour ma part j'ai eu l'occasion de travailler pour une entreprise qui utilisait la stratégie décrite par le premier commentaire, et c'est essentiellement ce qui m'a poussé à démissionner. Je suis parti parceque d'une part je ne cautionne pas cela, d'autre part parceque les gens qui baisent leurs clients baisent aussi leurs employés. L'expérience montre que ce n'est pas partout comme cela.
La vraie naïveté c'est de croire que le pessimisme peut tenir lieu d'expérience.
[^] # Re: re:
Posté par Michaël (site web personnel) . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 5.
Plutôt du commercial que tu ne veux pas dans ta boîte parcequ'il ne s'intéresse visiblement pas trop à la relation avec le client ni à la bonne réputation de l'entreprise. Ne pas savoir dire “désolé j'ai merdé je n'ai pas tenu les dates, on a eu tel et tel problème“ est la signature de l'amateurisme.
[^] # Re: Et la sécurité dans tout ça?
Posté par Michaël (site web personnel) . En réponse à la dépêche EveConnector, connectez des applications SaaS aux périphériques des postes clients. Évalué à 3.
Ça me paraît aussi bizarre. Ce qu'il faut faire – il me semble – c'est plutôt préparer une mini API http-json et un petit serveur qui la fait tourner, plutôt que d'ouvrir comme ça les entrailles de la bêbête!
[^] # Re: Le code impératif
Posté par Michaël (site web personnel) . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 3. Dernière modification le 13 septembre 2016 à 09:50.
Homéomorphe, c'est un peu faible, il vaudrait sûrement mieux demander qu'on puisse coincer cette équipotentielle entre deux ellipsoïdes de rayons pas trop différents. :)
Oui bien demander un difféormorphisme avec une borne sur l'intégrale de la divergence.
[^] # Re: Mon expérience (similaire)
Posté par Michaël (site web personnel) . En réponse au message Quelle formation en C++ pour un physicien ?. Évalué à 2.
Si il est prêt à aller à l'étranger il trouvera sans problème du travail, en Allemagne par exemple (là où je vis) on n'a pas du tout la même culture du recrutement qu'en France – ceci dit il paraît que ça s'améliore progressivement en France. Les entreprises qui pourraient s'intéresser à son profil de physicien intéresse par le numérique sont probablement les institutions financières – chercher si elles ont une section “risk management”, “operating desk of derivatives” ou un truc du genre – l'industrie automobile, ou bien tout ce qui utilise beaucoup de simulations – c'est à dire quasiment n'importe quelle industrie suffisamment grosse. En plus des “gros” acteurs les plus évidents il y a plein de petites entreprises qui font du conseil technique sur des points spécialisés et qui ont elles beaucoup plus de mal à recruter que les gros acteurs.
# Mon expérience (similaire)
Posté par Michaël (site web personnel) . En réponse au message Quelle formation en C++ pour un physicien ?. Évalué à 2.
J'ai un profil vaguement semblable à celui de ton ami, je suis mathématicien de formation et même si j'ai beaucoup programmé pour mon plaisir personnel ou de temps en temps pour ma recherche, et même si j'ai fait quelques modules “info” pendant mes études (programmation en Scheme, calcul scientifique, algorithmique) je n'avais pas d'expérience solide en programmation en cherchant des emplois hors du monde académique.
Les entreprises ne vont en général pas s'attendre à trouver des gens qui soient à la fois des bons physiciens et des bons programmeurs, et puis la plupart des gens sont tout à fait capable d'apprendre à programmer, et les physiciens pas moins que quiconque. Donc pour commencer, je conseillerais de faire fi de toute inhibition et de poser des candidatures pour les offres qui l'intéressent, en étant tout à fait honnête sur le niveau de programmation qu'il peut avoir – qui n'est pas nul, même s'il n'est pas très élevé. S'il choisit de travailler dans une grosse structure, il aura de toutes façons un programme de novice, éventuellement de plusieurs mois, pour se former.
Ce qui est important pour ton ami, c'est d'une part d'être sûr qu'il est réellement intéressé par le travail auquel il présente son dossier, et en particulier qu'il est réellement intéressé par la programmation. C'est le point qui me semble le plus délicat.
Pour moi ce qui fait un bon programmeur, ce n'est pas tant sa capacité à écrire des programmes en elle-même, qui bien-sûr doit être là, mais la capacité à écrire du code robuste, maintenable et testable, et très franchement je ne connais pas d'autre école que celle de l'expérience. Quand je programmais chez moi je n'écrivais pas des programmes qui tournent pendant des mois et manipulent des TB de données. :)
Si ton ami veut étudier la programmation en autodidacte, le mieux pour lui est de dénicher un projet libre teinté de calcul scientifique qui l'intéresse et auquel il pourrait envisager de modifier un peu ou même de contribuer. Quelques exemples:
Toi tu peux l'aider à tout mettre en place sur sa machine, et à faire ses premières compilations. :)
[^] # Re: Fake !
Posté par Michaël (site web personnel) . En réponse au journal RemindAt : programmer un rappel pour ses courriels. Évalué à 3.
Ah oui, tu as raison! :)
[^] # Re: Fake !
Posté par Michaël (site web personnel) . En réponse au journal RemindAt : programmer un rappel pour ses courriels. Évalué à 3.
Si la banque te fait un prêt avec un taux négatif, cela veut dire que tu dois payer pour placer ton argent chez eux. :)
[^] # Re: Le code impératif
Posté par Michaël (site web personnel) . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 4.
En comparaison la documentation de OCaml est beaucoup plus simple. Elle est écrite de façon assez “matheuse” mais à un niveau beaucoup plus élémentaire: le côté matheux de la documentation est plutôt utilisé pour décrire brièvement une fonction par une phrase générale qui inclut aussi les cas particuliers (de type liste vide, etc.). Après pour l'exemple que tu cites, je ne sais pas ce qui pousse les gens à écrire des documentations comme ça… je ne dis pas que les phrases “Formally, the class Bifunctor represents a bifunctor from Hask -> Hask. Intuitively it is a bifunctor where both the first and second arguments are covariant.” ne sont pas intéressantes mais elles sont plutôt à mettre en remarque, ou en tout cas, après la description de ce que “font” concrètement les fonctions du module.
# Lire la documentation
Posté par Michaël (site web personnel) . En réponse au sondage Ce que je déteste le plus en informatique / programmation / codage c'est... :. Évalué à 10.
La plupart de temps, ce qui m'agace c'est de lire de la mauvaise documentation. Voici les principales défauts que je retrouve dans les documentations avec lesquelles je dois le plus souvent travailler:
Documentation qui hésite entre la référence, l'introduction du manuel de l'utilisateur et le manuel de l'utilisateur lui-même. L'information y est mal structurée, pas au bon endroit, etc.
La documentation mal présentée, l'exemple typique est la documentation de NodeJS ou celle de l'API AWS JavaScript. La documentation n'est pas assez espacée, pas assez bien structurée – on a des descriptions d'éléments 'APIs obsolètes qui s'étendent sur plusieurs écrans au beau milieu de la description, et comme il n'y a pas d'espaces verticaux ou de mises en retrait bien visibles, on ne se s'y retrouve pas. À la rigueur le seul moyen de s'en sortir à peu près, serait de l'imprimer! Et puis comme on est en 2016 le concept de page est has been et on écrit tout dans un seul document – alors que la page est une bonne unité pour délimiter et hiérarchiser le texte.
La documentation ambigüe, où les descriptions des fonctions laissent place non pas à une interprétation possible mais à plusieurs, ou bien qui laissent en suspens des questions essentielles que tout programmeur expérimenté se pose dans certaines situations. Par exemple la documentation du SDK AWS n'arrive pas à traiter proprement les cas de “valeur”, “null” et “membre non défini” – alors que quand on documente du JavaScript, c'est évidemment la chose avec laquelle il faut être le plus propre! – ce qui oblige à faire des essais. Autre exemple la documentation de NodeJS qui, lorsqu'elle aborde les streams se garde bien de décrire, lorsqu'on utilise des streams lisant la sortie d'un processus fils, le comportement bloquant ou non de l'écriture par le processus fils. Quand on lit en détails on peut deviner ce qui se passe et essayer pour vérifier, mais ce ne devrait pas être nécessaire.
La documentation bavarde, qui au lieu d'utiliser une langue technique claire et concise se livre à des bavardages incessants. Exemple typique le manuel de GNU Make qui arrive à dire en plus de 205 pages essentiellement la même chose que les 8 pages de man du BSD Make. Pour moi c'est beaucoup plus facile de retrouver une information dans 8 pages de documentation que dans 205.
[^] # Re: Mauvaise connaissance du c++
Posté par Michaël (site web personnel) . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 5.
Je pense que ce qu'essaie de dire barmic, c'est que certaines exceptions n'ont pas le droit d'être propagées en dehors de leur domaine et qu'on doit mettre en place des “superviseurs” qui montent la garde à la frontière d'un domaine et qui traduisent les erreurs d'un domaine en erreurs génériques, qui peuvent mentionner tous les détails utiles à l'utilisateur (sous forme d'un texte) ou bien proposer un option de récupération. Pour le cas particulier de l'UI d'une application habituelle, tout ce qui compte c'est de savoir qu'il y a eu une erreur, quel contexte afficher et si on peut récupérer l'erreur. Et c'est uniquement des erreurs de ce type que doit voir le code de l'UI.
[^] # Re: J'ai déjà entendu ça quelque part
Posté par Michaël (site web personnel) . En réponse au journal Tout simplement E P I Q U E. Évalué à 7.
Le stylo bille permet d'écrire lorsque le clavier se blo
[^] # Re: Tiptop le sexisme
Posté par Michaël (site web personnel) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 4.
Oui, ceci dit, les articles ne font pas cette propagande, ils sont détournés et on leur fait dire ce qu'ils ne disent pas. Ces textes cherchent surtout – du moins c'est ce que je comprends – à trouver protocole expérimental pertinent, ce qui correspondrait à un état très précoce de l'élaboration du savoir. Peut-être que certaines de ces expériences ont été menées à plus grande échelle (et pas sur un échantillon d'une centaine d'étudiants d'une fac nord-américaine, échantillon on ne peut plus biaisé de la population étatsunienne) et plusieurs fois, est-ce que ariasuni sait cela?
# Le nom des programmes
Posté par Michaël (site web personnel) . En réponse au journal Gfsecret, le secret réparti en pratique. Évalué à 5.
Salut, et bravo pour ton projet! J'ai une remarque à la limite de l'impertinence: c'et mieux d'utiliser le souligné
_que le tiret-dans les noms de programme. Hum, hum, mais pourquoi donc, te demandes-tu? La raison est que le souligné est un caractère valide dans une nom de fonction shell et pas le tiret. Donc par exemple, si dans un script shell qui utilisegfsec_splitj'ai envie de tracer les appels à cet outil, simuler des conditions d'erreurs, ou plus généralement faire du “mocking” sur cet outil je peux définir une fonctiongfsec_splitqui ajoute le comportement souhaité, et ce de façon transparente. Mais si le programme a un tiret dans son nom, cette technique est plus laborieuse à mettre en œuvre.Sinon une petite question mathématique: tu utilises des corps finis pour faire ton interpolation de Lagrange? Comment est-ce que tu choisis la caractéristique? Z/pZ ou bien des extensions?
[^] # Re: Tiptop le sexisme
Posté par Michaël (site web personnel) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 5. Dernière modification le 04 septembre 2016 à 22:48.
Encore et toujours, elles ne démontrent pas, elles semblent indiquer. Par exemple dans l'article de Gastil on peut lire ceci (p. 632):
Il existe aussi des expériences qui semblent indiquer que l'usage du pronom n'*introduit *pas de biais de genre, mias Gastil continue en pensant que ces expériences induisent un biais d'observation et prétend que la sienne n'introduit pas de biais d'observation. Or pourtant, cela semble être une des difficultés majeures qu'introduit l'utilisation des statistiques dans les sciences-sociales: il faut construire un énoncé qui est susceptible d'être invalidé par une mesure puis construire une expérience qui permet de réaliser la mesure, or il n'y pas de choix univoque de la quantité à mesurer et pour chaque mesure que l'on peut se représenter, on peut imaginer 1000 expériences, qui auront toutes leurs défauts et leurs avantages. Et encore une fois, une seule mesure est insuffisante à prouver quoique ce soit, en l'absence de reproductibilité on est obligé de penser que les résultats de l'expérience sont essentiellement aléatoires.
Justement le passage du “Malentendu du Deuxième sexe” que cite Annie Le Brun est
Autrement dit – et semble-t-il contrairement à ce qu'écrirait Beauvoir dans le “Deuxième sexe” – il n'y a pas de “spécificité féminine” qui soit irrévocablement associée à la femme, mais au contraire féminin et masculin sont des adjectifs – et peut-être les idéaux opposés et complémentaire dont tu parles – et comme adjectifs ils sont des idées distinctes des noms homme et femme et peuvent indifféremment qualifier l'un ou l'autre.
[^] # Re: Tiptop le sexisme
Posté par Michaël (site web personnel) . En réponse à la dépêche Ouverture du site Libre Games Initiatives. Évalué à 6.
Je me prête au jeu:
L'idée que développe Annie Le Brun dans ce chapitre, et qui explique ce qu'elle entend par “affaiblissement” est que à l'époque de Simone de Beauvoir un petit groupe de personne s'est accaparé la parole féministe et transformé la révolte féminine, auparavant diverse et audacieuse, en mouvement politique fortement idéologique, organisé, et très peu “révolte”. Pour le dire en quelques mots “dès lors que le féminisme s'est organisé en combat il a cessé d'être une révolte”.
Avoir une préférence est une chose, prétendre qu'elle est la direction inéluctable, c'est une autre chose et c'est celle que je contredis.
Tu peux utiliser le genre non marqué, comme dans “le médecin” par exemple. C'est ta perception et ta compréhension de la langue qui te fait croire que tu dois connaître le genre d'une personne pour en parler. Mon médecin généraliste et mon pharmacien sont des femmes mais je leur dit toujours “mon médecin m'a dit que” ou “mon pharmacien m'a dit que” lorsque je parle à l'un ou l'autre puisque le fait que le médecin ou le pharmacien soit un homme ou une femme ne change rien à la qualité de ses jugements – et du reste ne regarde que moi dans cette communication.
Faire référence à des catégories aux contours flous n'est pas le privilège des mots ”femme” et “homme” mais le lot de pratiquement tous les mots du lexique.
[^] # Re: Le manque d'informaticiens est un mythe
Posté par Michaël (site web personnel) . En réponse à la dépêche À Toulouse, ouverture d'une formation de développeur d'Applications « full-stack ». Évalué à 5. Dernière modification le 01 septembre 2016 à 10:43.
Le fait d'avoir perdu le fil de l'évolution des techniques n'est pas un problème en soi, la plupart des techniques nouvelles ou à la mode sont plutôt dans la continuité de ce qui se faisait il y a dix ans ou quinze ans. (Ce qui a beaucoup changé en revanche, c'est la guerre sans fin à la prétendue innovation que se livrent les grosses entreprises par logiciel libre interposé pour asseoir une forme de domination de leurs idées et technologies.) Très franchement aucun développeur aguerri ou même un débutant assez ambitieux ne devrait avoir de mal à se raccrocher aux branches,
Dans l'entreprise où je suis nous avons des difficultés à recruter des développeurs, pas tant à cause de l'absence de dossier, mais de la difficulté qu'il y a à identifier les profils intéressants. Par la force des choses on ne peut pas inviter tout le monde à un entretien or c'est là qu'on commence vraiment à savoir si on a envie de travailler avec le candidat à l'embauche. Malheureusement trop peu de candidats ont le courage ou la force de caractère, ou même peut-être tout simplement l'idée, de montrer vraiment qui ils sont dans leur lettre de motivation ou de mettre en lumière quelques points qui démontrent leur capacité à apprendre et s'adapter, leur capacité à produire un résultat et leurs compétences sociales. Cela paraît bête de le rappeler mais pour un employeur qui s'intéresse à une relation longue avec ses employés, ce sont des points importants pour les décisions de recrutement. (Après on peut dans des cas particuliers rechercher un sénior avec beaucoup d'expérience sur un sujet particulier, mais c'est loin d'être le gros des recrutements.)