nlhss a écrit 56 commentaires

J'ai un solide socle scientifique et des notions de maths de niveau prépa MP.

Probabilités OK
Théorie des graphes OK

Quand je dis niveau bac+5 je suis conscient qu'il y a un spectre très étendu.

Je vise le niveau d'une bonne école d'ingénieur spécialisée en informatique mais avec un spectre suffisamment généraliste, capable d'être aussi bon technicien que théoricien de haut niveau sur certains sujets.

Je me mets à la place d'une personne en recherche d'emploi :

oui, dans ce cas c'est une excellente chose l'opportunité que tu proposes. L'empilement CDD -> CDI est légal et possible. Faire un CDD est une bonne chose et c'est un contrat de travail qui a aussi des avantages et des contreparties pour le salarié.

Ceci dit la flexibilité me semble plutôt du côté de l'employeur dans cette configuration et le risque du côté du salarié.

Par exemple, cela serait me semblerait risqué pour quelqu'un déjà en CDI de quitter son job pour l'offre que tu proposes.

je ne voulais pas dire que tu es un mauvais employeur et je sais ce que c'est les petites structures où l'activité économique n'est pas garantie :)

Je sais pas mais le CDD de six mois ça fait vraiment période d'essai déguisée ça c'est sûr.

Ça se comprend mais ça n'est pas très sexy.

Pour un jeune diplômé par contre c'est une option intéressante (six mois de moins en recherche d'emploi pour une expérience qui semble intéressante et formatrice.)

Je ne te conseille pas le C++.

Tu devrais installer archlinux et faire du Haskell.

Coucou, j'ai une certaine expérience de la remise à niveau en mathématiques, car sur la dernière année, je me suis préparé au CAPES de mathématiques, essentiellement basé sur le programme de classe préparatoire de MP/MPSI.

En fait, bien maîtriser les mathématiques c'est un sujet qui est hyper intéressant en soi car ça te donne une réserve de puissance intellectuelle. Mais c'est un savoir qui est aussi un peu laborieux à apprendre. De plus, on dit souvent que les mathématiques ne sont pas applicables à la vie réelle et donc on s'en désintéresse facilement. Rien n'est plus faux en réalité mais elles conservent cette image de discipline austère et difficile d'accès.

Pour schématiser, l'activité mathématique dans les livre est souvent présentée comme une énumération fastidieuse de théorèmes et de preuves. Savoir prouver et avoir des connaissances en logique est très important pour un développeur je pense. En fait, savoir prouver un algo est sans doute dans l'aspect mathématique le plus intéressant pour un développeur.

En terme de mathématiques appliquées, il y a aussi des choses à prendre. Les « recettes » des maths, on peut les réutiliser car un ordinateur est avant tout un calculateur.

En terme de concepts plus élaborés (algèbre linéaire, théorie des groupes) ces derniers sont extrêmement importants, à la fois comme fondation des mathématiques et en terme de culture générale, mais ils demandent aussi un travail approfondi pour être bien maîtrisés.

Tu peux sélectionner ces différents aspects pour te composer une culture intéressante. Tu ne peux pas rattraper 10 ou 15 d'inactivité mathématique comme cela, tu vas avoir besoin de temps et de respirations pour progresser.

Avant tout cela il y a tout un vocabulaire à maîtriser, mais celui ci est en général bien résumé dans le premier chapitre d'un bon bouquin de MPSI.

multiplateforme
simple d'utilisation

C'est une histoire de complexité asymptotique, de pire cas VS cas moyen VS cas favorable, etc.

Par exemple, sur un tableau déjà trié, un algo asymptotiquement en O(n²⁾ peut être plus efficace qu'un algo en O(Nlog(N)) car ce dernier va faire des tas d'accès inutiles, voire même éventuellement déplacer des éléments alors que ce n'était pas nécessaire.

When the list is already sorted (best-case), the complexity of bubble sort is only O(n). By contrast, most other algorithms, even those with better average-case complexity, perform their entire sorting process on the set and thus are more complex. However, not only does insertion sort have this mechanism too, but it also performs better on a list that is substantially sorted (having a small number of inversions).
(wikipédia).

En gros le tri par insertion, malgré sa plus grande complexité que le quick sort, est plus efficace sur des ensembles déjà trié ou partiellement triés.

La complexité n'est pas le seul facteur. Souvent un algo en log(N) prendra plus de mémoire, ou sera moins robuste/plus long à implémenter, ou encore en moyenne ce sera du O(log(N)) donc dans la plupart des cas satisfaisants.

Dans tous les cas les algos linéaires ne sont pas tellement des problèmes, ce sont plutôt les algos en O(n²) dont il faut se méfier.

La maintenabilité est un facteur important. On peut coder rapidement en java (pas aussi rapidement qu'en python mais quand même, ça va assez vite).

Et tu finis avec un gros cluster de trucs totalement hétérogènes. N'oublie pas que la communication entre services est aussi coûteux du point de vue de la maintenance et de l'architecture. Tu avances un modèle « bazar » alors que Java permet de construire des applications complexes de manière nettement plus sûre et surtout dont les performances à l'exécution sont meilleures que nombre de langages de script.

Oui, je suis d'accord. On peut faire des casts aussi en java mais en règle générale, il vaut mieux éviter. Si on veut du code générique, mieux vaut éviter les cast de toutes façons.

J'ai avancé un argument mais je pense qu'il est bon. Le typage statique est une sécurité pour des très gros projets. Ses inconvénients sont ses forces si tu vois ce que je veux dire. Bon je pense qu'il faut essayer pour être convaincu de l'intérêt du typage statique.

Évidemment :)
C'est même un très gros avantage du point de vue génie logiciel.

Oui, je suis d'accord.

La première conf' , de Quentin est vraiment, vraiment sympa. J'ai beaucoup apprécié son franc parlé et sa vision managériale sur la place du développeur dans une petite boîte.

Morceau choisi
Interlocuteur : Ça doit être dur, quand même, de recruter des dév Scala
Quentin : J'entends ça souvent. Mais en fait, mais non, mais pas du tout. Quand je demande un dév Scala, j'ai trois CV qui atterrissent sur mon bureau. Trois ! Sur une techno standard, j'en aurai environ 50. Imagine le boulot de tri à faire. Ensuite, un dév Scala, il fait ça comme hobbyiste, le soir, chez lui. Donc il est motivé. En fait le salaire il s'en fout, je peux le payer comme je veux puisque lui il aime ce truc. (Résumé : choisis une techno « marginale », tu auras des mecs compétents, motivés, pour un salaire modique et qui aiment ça).

Une analyse du point de vue du cynique patron mais qui laisse à réfléchir, mais le point principal de cet argument, c'est qu'en effet, les bons programmeurs sont en majorité des gens qui aiment ce qu'ils font (L. Torvalds).

J'ajoute en passant qu'on connaît tous l'adage « un bon travailleur a de bons outils ». Si 90% des dévs travaillent avec l'outil A, et que l'outil B rend plus compétitif, alors l'outil B est une plus-value essentielle (bon sens élémentaire).

Toute la conf' est comme ça (ou presque) et franchement bien marrante, donc vous pouvez y aller, si vous avez 60 minutes à perdre :).

Bonjour,

je pense que faire des pull request sans avoir un vrai contact avec l'auteur n'est pas forcément très pertinent. Ce qui va déterminer si l'auteur accepte tes contributions, c'est s'il les juge utiles pour le projet initial, et le seul moyen de faire cela et d'en parler avec lui.

Je connais peu de développeurs/mainteneurs de logiciels libres qui soient totalement injoignable. Créer un fork est potentiellement intéressant, mais cela va te créer du travail supplémentaire en terme de maintenance (git est fait pour ça en fait, si tu veux merger a posteriori tout en conservant ta fonctionnalité dans une branche locale au fil des évolutions du soft initial).

Est-ce que tu es bien certain que l'ajout d'une simple fonctionnalité justifie un fork du projet initial ? Cela serait vrai si tu avais une vision à long terme pour ce projet et que l'auteur ne veut plus/ne peut plus s'en occuper. Autrement tu peux, comme je le disais, garder une branche spéciale du projet initial et merger les mises à jour régulièrement.

Si le projet initial est GPLv2, tout ce que tu peux faire c'est licencier sous GPLv2 je crois, éventuellement si tu te sers uniquement des interfaces du projet initial, tu peux créer un module qui change de licence par rapport au soft principal (mais pas expert sur la question donc à prendre avec des pincettes).

J'ai jeté un coup d'œil à Grav. Ça a l'air vraiment très très bien comme CMS, et ça a l'air de correspondre vraiment de très près à l'idée que je me faisais de ce que je voulais utiliser. Le seul petit détail technique qui ne me convient pas, c'est qu'il est en PHP. Mais ce CMS a l'air tellement sympa que je suis prêt à apprendre PHP + javascript pour l'adapter à mes besoins.

Merci pour ton conseil.

J'avais testé pelican il y a quelques mois (années ?). Je ne sais pas vraiment ce qui me retient de l'utiliser. À l'époque, le système de build n'était pas aussi mature que maintenant. Peut être que j'y reviendrai en fin de compte, je vais voir. Merci pour ton conseil.

Je suis passé sur le site de ce CMS, je me demande ce qu'il vaut en vrai. Je vais peut être le tester en local.

Si je veux commencer il va me falloir aussi trouver un hébergeur qui accepte les git push et cætera.

Peut être pas évident à trouver du premier coup.

Salut,

J'ai quelques questions en fait, pour mieux comprendre à quel besoin répond ce logiciel.

Si j'ai bien compris, il ne permet que de faire de la représentation de graphes déjà produits, (par exemple avec matplotlib) mais il ne permet pas de prendre des données brutes et de modifier leur représentation.

Merci pour ta réponse. En effet, le plus gros problème se situe dans le « hook » comme tu dis, c'est à dire la compilation d'éventuelles modifications faites « on-the-fly » pour chaque commit. Et là, je n'ai aucune idée de comment faire ni si une telle solution existe déjà. Je sais que la plupart des générateurs de site statiques que j'eus essayé nécessitaient une fastidieuse re-compilation manuelle (avec un système de cache pas nécessairement au point) à l'époque où je les ai essayé.

Je pensais aussi un système de thèmes CSS éventuellement, à lier directement dans chaque poste (éventuellement dans l'en-tête, pourquoi pas).

Le problème de compiler du Latex en html se pose cruellement, parce que le latex est déjà un système de macros bien évolué mais que de nombreux packages ne pourront pas être supportés nativement. Un filtre latex->html qui fonctionne bien, a priori, je ne connais que pandoc.

Tu sais il y a déjà 3 ou 4 possibilités pour faire des citations en latex, demander à un moteur de conversion de toutes les comprendre me semble impossible. Et puis Latex n'est pas franchement fait pour le web.

C'est pour cela qu'un sous-ensemble (« minimal subset ») répondant à l'ensemble des contraintes ci-dessus me semble nécessaire. Par exemple, ResT sait faire pas mal de choses.

Effectivement, tout ce qui est listé plus haut existe déjà. Je continue de fouiner un peu partout pour dénicher une solution qui tienne la route :)

Mmh j'ai d'énormes doutes sur ce que tu racontes, je suppose que c'est partiellement humoristique. Si seulement c'était vrai, ça ne devrait pas durer plus longtemps que la période de boot, et ce n'est pas suffisant comme temps pour chauffer le CPU.

Non, la cause peut être plurielle : l'ordonnancement, ou même, plus précisément, la façon de gérer le ventilateur du CPU qui peut dépendre du paramétrage du BIOS, mais aussi d'un daemon en espace utilisateur. Remarque pour la plupart des machines récentes, la vitesse du CPU se contrôle directement depuis le BIOS, ça n'a donc rien à voir spécifiquement avec Linux.

Dans ce cas tu pourrais penser à des processus qui bouffent trop de CPU (exemple typique : flash) et qui font ramer ta machine.

Remarque avec un processeur un peu sérieux (type quad-core) l'utilisation comme machine de bureau ne devrait pas franchement mettre le CPU dans le rouge.

Bonjour, est-ce qu'un dispositif technique ne permettrait pas d'avoir des fonctionnalités similaires tout en étant décentralisé (ie pas de BDD centralisée mais un moteur de recherche collaboratif) ?

Bonjour, salut et éventuellement je peux tenter une explication. En fait, je m'étais fait la réflexion qu'un frein à l'adoption d'un langage est l'absence de standard explicite. Parce que si tout le monde fait son truc dans son coin, on arrive pas à avoir une masse critique d'utilisateurs qui fera que la communauté prendra son essor.

Tu parles de la communauté python, je suis vraiment désolé, mais je suis en désaccord avec ce que tu dis :

il y a des communautés qui n'ont pas de processus de standardisation et qui ont une communauté très large (beaucoup plus large que Haskell)—par exemple Python, Ruby, Node.js, etc.

Python au contraire me semble faire des efforts considérables pour atteindre un très haut degré de standardisation. Les infinies précautions prisent par le consortium pour passer de python 2 à python 3, le « preferably one way », ce sont des prises de position qui incitent à penser que python, c'est un processus de maturation de qualité. Les acteurs industriels dans python sont bien plus nombreux¹ que dans GHC par exemple².

Pourquoi la standardisation est-elle intéressante pour développer une large communauté ? Parce qu'une infrastructure logicielle, on n'a pas forcément envie de la voir voler en éclat à chaque mise à jour du compilateur. On sait tous que ce qui coûte cher dans un soft, c'est la maintenance. L'erreur classique dans un cycle de développement est de négliger le coût de la maintenance/évolution initialement, pour le voir ensuite exploser parce que les décisions initiales ont été incorrectes. Il suffit d'aller un peu trop vite pour voir la facture devenir ensuite beaucoup plus salée³.

D'après les quelques échanges que j'ai eu sur IRC, Haskell ne vise pas une stricte standardisation. La communauté et le noyau des développeurs souhaite incrémenter tranquillement les fonctionnalités du compilateur, tout en restant dans l'esprit langage fonctionnel pur (c'est un des seuls langages avec ce degré de pureté fonctionnelle pourrait-on dire). Forcément cela ralentit l'adoption massive mais j'ai l'impression que de plus en plus de personnes se tournent vers ce langage⁴. Si tu lis l'anglais je te conseille ce lien.

1. Python vient d'être adopté comme langage de programmation officiel pour la nouvelle mouture du CAPES de mathématiques (site officiel).
2. Ni Ruby ni Node.js (que je connais mal en passant) ne me semblent avoir la même visée ni la même généricité que python
3. Ça me fait penser à l'EPR de Flamanville.
4. Cette page est tout de même assez éloquente sur les potentialités du langage.

Dans l'absolu le langage bénéficierait tout de même d'une standardisation un peu plus poussée je pense, et sans doute qu'une plus large communauté s'y intéresserait, mais ce n'est pas l'objectif du projet, en tous cas pas à moyen terme.

Bonjour, je me suis mis à Haskell il y a quelques semaines. C'est un langage particulièrement difficile à apprendre, surtout si on vient d'un monde impératif, paradigme qui constitue celui de la majorité des langages en production au 21ème siècle.

En particulier faire des IO est un peu délicat lors d'un premier jet. En fait, pour être productif, il faut y passer beaucoup de temps, un apprentissage sérieux prendra plus de six mois.

Je trouve l'exemple donné ci-dessus un peu élaboré, et il manque les déclarations de type. Celles ci ne sont pas obligatoires en Haskell mais vivement conseillées car elles permettent de mieux comprendre le code et évitent aussi les erreurs lors de la rédaction d'un programme.

Voici quelques exemples de fonctions élémentaires réalisées avec Haskell :

{- Prends un argument qui supporte '*' et retourne le double -}
dbl x = x*2

{- double chaque élément dans une liste (list comprehension) -}
dbll lx = [ dbl k | k<- lx ]

{- renvoie la liste des digits dans une base donnee (attention dans l'ordre inverse) -}
get_digits_basis n b = if n<=0 then [] else m:(get_digits_basis (quot (n - m) b) b) where m = mod n b

{- Même chose mais avec des guards -- plus lisible -- et avec une déclaration de types -}
get_digits_basis2 :: Int -> Int -> [Int]
get_digits_basis2 n b
    | n <= 0     = [] 
    | otherwise = m:(get_digits_basis2 (quot (n - m) b) b) 
    where m = mod n b

{- application en base 10 -}
get_decimal n = reverse(get_digits_basis2 n 10)

{- application en base 2  -}
get_binary n = reverse(get_digits_basis2 n 2)

{- renvoie la somme des digits d'un nombre entier quelconque -}
sumDigits [] = 0
sumDigits (x:y) = sum (get_decimal x) + sumDigits y

Être productif en Haskell demandera sans doute de longs mois d'apprentissage, en tous cas je n'en suis pas au bout.