Michaël a écrit 2935 commentaires

J'ai juste accolé deux demi-photos (dont une avec les lunettes Trip Glasses de Mitch Altman, testées lors d'un CCC à Berlin).

C'est donc un Selfrankrenstein plutôt qu'un selfie, alors?

Merci pour ta réponse, cependant je ne suis pas sûr de ce que tu appelles un RAR, s'agit-il d'un rappel au règlement? Dans ce cas celui de l'entreprise?

whatsapp s'ils sont pas si jeunes. si ils sont trop jeunes ils débutent direct sur le dark web :)

Et ils achètent du crystal à leurs parents sans le savoir. :-)

Tu vas un peu vite, comment sauter par dessus chan95, et chanXP, chan Millenium Edition et chan2000 avec tant de négligence?

• Il y a plein de façons d'évaluer le résultat, et l'erreur moyenne n'est pas forcément le meilleur. La variance ajoute une courbure à l'erreur moyenne en pénalisant les fortes erreurs par rapport aux faibles, c'est peut-être plus intéressant?

• Le prix de vente n'est clairement pas fonction de ces trois paramètres: si Alice
  et Robert (enlève ton masque Bob, on t'a reconnu!) ont acheté la même voiture la même année au même prix et roulé le même nombre de kilomètres, il n'y pas de raison qu'ils souhaitent
  la vendre au même prix. Si cela arrive dans te données, tu demandes de deviner une fonction “qui n'existe pas” dans tes données initiales, du coup ça a peu de chances de marcher. Pour t'en sortir tu as trois pistes: “lisser les données en moyennant les points proches” – définir une notion d'exception qui te permet de jarter ou pénaliser les points gênants – et finalement changer (raffiner…) la variable que tu veux modéliser. Mais bon ce qui est sûr, c'est que le problème n'est pas très bien conditionné.

(Un exemple de raffinement – que je préfère à prendre des moyennes – serait d'estimer de le “min” ou le “max” sur des points proches par exemple.)

• Il faut vérifier que la date soit comprise contre une variable continue – car on y pense comme à l'âge – une erreur banale est de l'utiliser comme une variable classifiante (comme rouge, vert, bleu par exemple) ce qui fragmente l'échantillon.

• Il y a une phase d'analyse des corrélations (où on parle des facteurs explicatifs qui permettent de reconstruire les corrélations). Est-ce que cela démontre une corrélation du prix de vente au prix de mise sur le marché par exemple?

• Ta question de variables à ajouter est très pertinente, est-ce que par exemple la cote ARGUS mérite d'être dans le jeu de données?

soit il n'y a pas de corrélation entre mes features

Si tu utilises un paquet d'apprentissage automatique il y a certainement une petite analyse toute prête qui traîne quelque part qui te dira ça.

Il me semble qu'un article écrit avec quelques captures est plus indiqué.

Je suis essentiellement d'accord avec toi mais j'aimerais apporter un autre éclairage: la vidéo a ses raisons d'être et ses spécificités et si on se donne la peine d'y réfléchir et de s'en servir on peut compléter utilement un contenu écrit.

Par exemple, la vidéo d'introduction de SLIME, le “Lisp-Mode” de Emacs est très pertinente: https://www.youtube.com/watch?v=_B_4vhsmRRI, surtout si on considère le ratio édition/contenu. Pour apprendre un outil par nature interactif, c'est bien plus simple de voir comment une certaine personne interagit avec plutôt que de lire un tutoriel.

Pour moi les deux raisons d'utiliser une vidéo comme support à de la documentation technique en informatique sont justement d'illustrer l'utilisation de programmes interactifs, et l'effet “feu d'artifice” par exemple dans le scenario fictif:

J'ai préparé un environnement Docker Git/Trac/Jenkins/Prometheus/Grafana/Nexus et tu peux bootstrapper un nouveau projet en faisant:

% git clone @monsuperenvironment-docker
% cd monsuperenvironment-docker
% ./tool/environement_setup monsupernouveauprojet

Avec une petite vidéo qui montre ce qu'on obtient à la fin (les feux d'artifices) peut renforcer l'effet de conviction.

Mais faire des vidéos pour tout est n'importe quoi est idiot car c'est dans de nombreux cas le plus mauvais support possible.

"Si je sais combien j'ai sur mon compte bancaire ? Mais c'est une question de pauvre, ça !"

Ça me fait tout autant peur qu'à Louis Cole:

 ♫ I don't want to… check my bank account!
   I'm too scared to… check my bank account!
   Oh, check it! ♩

https://www.youtube.com/watch?v=dAH4zGd_W1s

qu’il serait temps d’essayer de résoudre collectivement plutôt que de s’enfermer dans un individualisme de plus en plus méfiant jusqu’à faire des choix finalement contraires à nos propres intérêts

Tu oublies que travailler dans une association pour faire valoir ses droits est nettement plus fatiguant que rester assis sur son canapé et de résoudre ses problèmes n'importe comment.

En plus la défiance envers le pouvoir donne l'air malin.

Tu peux récupérer les dépendances aux headers via le compilateur, par exemple avec gcc -M et gcc -MM
Cf. https://stackoverflow.com/a/2394651/518853

La meilleure façon de capturer les dépendances – meilleure parcequ'elle est exhaustive et indépendante du compilateur – est de tracer les appels système.

C'est ce que fait le make de NetBSD et de FreeBSD qui est bmake. avec son meta-mode. L'intérêt de cette méthode est qu'elle permet d'avoir les vraies dépendances et donc paralléliser au mieux.

Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.

C'est peut-être un énorme TP sur le cadre législatif des fichiers informatiques?

Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.

Ce qui augmente la confiance c'est d'avoir un contenu cryptographiquement signé avec un checksum publié séparément.

Rien n'interdit par exemple de faire un serveur qui publie un script différent en fonction des paramètres du client (IP, user agent, plage horaire) ce qui pourrait constituer un vecteur d'attaque.

Avec un paquet hébergé ad-hoc c'est un peu mieux – faire confiance à une clef GPG est plus restrictif que de faire confiance à un serveur web – l'idéal serait d'avoir des sources différentes pour le checksum et pour le paquet.

Le format des paquets n'a aucun lien avec le problème présenté ici.

Le rapport c’est que distribuer son logiciel proprement en créant un dépôt ad-hoc et des packages pour une distribution est déjà chiantissime alors le faire pour toutes les distributions est inimaginable hormis pour les plus gros projets.

Le plus simple moyen de distribution est MacPorts mais la cible est spécifique au possible.

Le vieux combo «configure && make all install» est largement délaissé — pour de bonnes raisons, l’investissement temps-bénéfice pour apprendre les Auto-Tools est assez décourageant, et même si on a tout bien fait, créer son package pour une distribution de premier plan comme Debian ou Ubuntu est absurdement difficile.

Comme n'importe quel langage interprété non ?

Non c'est loin d'être le cas. En Lisp si je définis ma fonction nb-browse-to-url et que je l'appelle depuis nb-open-bookmarks-in-tabs et bien il me suffit d'envoyer la nouvelle définition de nb-browse-to-url à l'interpréteur pour que open-bookmarks-in-tabs utilise la nouvelle version. Dans la plupart des langages interprétés, la fonction nb-open-bookmarks-in-tabs se souviendrait de la vieille définition de nb-browse-to-url jusqu'à ce que nb-open-bookmarks-in-tabs soit elle-même redéfinie.

Ce n'est pas parceque c'est possible que c'est toujours la bonne chose à faire mais en pratique cette possibilité permet de considérablement réduire la durée de la boucle de développement.

À la page 130 on aura vu docker run -t -i et quelques commandes de base.

C'est une prise en main bien tardive… ;)

C'est dans l'avant-dernier chapitre qu'on parlera de persistance de données, de volumes, etc. J'appris des choses, mais vous savez ma frustration de ne pas avoir vu de cas d'usage plus réaliste pour un développeur web.

Mon expérience pour ton cas est qu'il vaut largement mieux “se faire son expérience soi-même” car la plupart des sources que j'ai eues sous les yeux ne sont pas terribles.

Les problèmes récurrents que l'on repère dans les exemples facilement accessibles sont:

• Un mauvais usage du cache. – Cela produit des temps de compilation trop long.

• Un trop grand nombre de layers produits. – Cela ralentit les opérations push, pull et create.

• Une trop grande dépendance à des ressources en lignes. – Chaque source différente augmente le risque qu'on ne puisse déployer à un moment critique à cause d'une ressource indisponible.

Je sentais que je perds trop de temps à re-compiler tout le machin au moindre changement de fichier, je n'ai pas de bonne pratique pour construire une image python&node.js

C'est un problème assez difficile, j'ai à propos d'un autre problème rédigé quelques conseils pour améliorer ses Dockerfiles.

Dans le cas d'une application node.js ces conseils se résument en gros à dire que la fin du Dockerfile doit ressembler à:

ADD src/package.json /opt/my-project/var/src/my-package/package.json
RUN cd /opt/my-project/var/src/my-package\
 && yarn install
ADD src/. /opt/my-project/var/src/my-package/
RUN cd /opt/my-project/var/src/my-package\
 && yarn build

ou un truc du genre qui sépare bien l'installation des dépendances de la préparation du fichier JavaScript final.

Mais ceci dit il n'y a aucune bonne raison pour que l'environnement de développement utilise les mêmes images que l'environnement de test ou de production. C'est parfaitement légitime d'utiliser un environnement spécifiquement destiné au développement qui favorise une boucle de développement rapide quitte à prendre quelques raccourcis.

Un autre point très important est qu'il est absolument nécessaire d'écrire des petits scripts qui implémentent les “verbes” du développement. De bons candidats sont “reconstruire toutes les images” ou bien ”ouvrir un shell root dans un container pour voir ce qui s'y passe” etc.

C'est fou le nombre de livres d'informatique où des pages entières de captures d'écrans sont désormais nécessaire là où quelques caractères suffisaient amplement autrefois.

Dans mon ancienne entreprise mon chef s'éclatait à essayer des logiciels pour représenter “rôles” et ”ownerships” dans l'entreprise… vu qu'on était 25 employés et qu'ils n'ont recruté personne depuis un an et demi, ça aurait été torché en 14 minutes en faisant un dessin à la main.

J’avais netbsd dans un radio-réveil »connecté«.

J'ai toujours eu un faible pour trac, par exemple voilà le formulaire de création de ticket.

Les gros plus de trac sont:

• La simplicité.
• La bonne intégration du système de tickets avec le wiki et les autres ressources du web (voir TracLinks)
• Une procédure de sauvegarde et de restoration intégrée.
• Les rapports de tickets super faciles à utiliser
• Une API facile à utiliser

Le gros moins est pour les utilisateurs non techniques l'utilisation du wiki-formatting à peu près partout, mais on peut aussi partir du principe que ce n'est pas grave si les utilisateurs veulent juste entrer quelques lignes de texte.

J'ai du reste une image docker pour trac dans un projet qui intègre Jenkins, Trac et bientôt d'autres choses. Là je travaille pour qu'on puisse utiliser uniquement ce dont on a besoin (Jenkins sans Trac ou vice-versa).

Je ne l'ai jamais utilisé mais il me semble que RedMine est le seul produit libre qui a un “look & feel” de bonne grosse ”corporate software” si on m'autorise cette flopée d'anglicismes.

Mais si ton datacenter est français mais que les gens qui l'exploitent travaillent pour IBM, Accenture, HP, tes données sont-elles vraiment en sécurité d'un point de vue national?

Si j'ai bien compris le patriot act la réponse est “non mes données dans un datacenter en France géré par une entreprise américaine ne sont pas en sécurité.” Et indépendamment du GRPD/DSGVO, les multinationales qui sollicitent mon entreprise ne veulent pas entendre parler de IAAS américain – parcequ'ils ne veulent aucune donnée sensible affectée par le patriot act.

La solution, ce serait d'avoir un cloud européen de l'administration, mais cela obligerait l'Union européenne à redévelopper tout ce qu'Amazon ou Google ont déjà, tout en étant plus cher et moins performant (car moins de clients) - ce qui peut être acceptable pour le RGDP. Mais "une bonne VM avec un bon ingé" n'est certainement pas une bonne alternative.

Euuuh, alors franchement tout ce qu'Amazon ou Google ont déjà c'est largement plus que ce qui est nécessaire. Et quand on pense à cloud pas cher ce n'est pas forcément Amazon ou Google qui viennent tout de suite en tête.

Des fournisseurs de IAAS il y a en des dizaines en Europe, plus ou moins grands, plus ou moins gros et plus ou moins OpenStack.

qui se règle en bougeant un seul point.

Elle est réglée même sans rien faire, si je m'autorise des jeux de mots moisis.

La limite pointée ne permet pas de faire facilement la différence entre une discontinuité vraiment sale du genre de sin(1/x) en x=0 d'une discontinuité un peu artificielle comme la fonction

La bonne notion à regarder c'est plutôt l'ensemble des valeurs d'adhérence pour la fonction.

Donc bon. L'utilisation de la limite pointée simplifie les trucs très simples,

C'est, plutôt que les “trucs très simples”, les énoncés de topologie générale qui “marchent mieux” avec la limite pointée (sinon on s'emmerde à devoir distinguer le cas “point d'accumulation vs. point isolé”, c'est tarte. Par exemple l'énoncé

Soit une suite réelle à valeurs dans et soit une fonction. Si , si et si alors .

est faux si on a comme notion de limite la limite “épointée” – à la place il faut dire que est continue en .

(essentiellemet équivalents à la limite épointée)

À aucun moment il ne s'agit de dire que la limite épointée ne sert à rien, au contraire c'est aussi une notion fondamentale (cas de N et des suites, limite à l'infini, limite au bord du domaine de définition, dérivées à gauche, à droite, par exemple) et on est bien obligé de manipuler les deux.

Tel qu'écrit dans le Frido, il y a (je crois) une incohérence pour limite et continuité d'une fonction définie sur un singleton ou plus généralement sur un espace contenant un point isolé.

En gros c'est un peu le sujet de la discussion – cf. ma remarque concernant le théorème 1. Et quand on passe l'agreg on n'a pas le droit de se prendre les pieds dans le tapis sur des notions aussi fondamentales que la continuité et les limites.

Dites les gars, si quelqu'un voulait un jour «défendre» la limite épointée en citant autre chose que de sources françaises …

Perso je m'en fiche de la nationalité des mathématiciens en question, ce qui compte est d'avoir un outil efficace. (PS. Du reste l'école mathématique française et particulièrement celle des années 60-70 jouit d'une réputation internationale. PS2 Si le but est de préparer des candidats à l'agreg de maths, c'est quand-même important de considérer le point de vue français sur la question.)

M'est avis qu'il ne faut pas deux définitions de limites, parce que la définition pointée demande quand même de prendre l'intersection entre le voisinage et le domaine de la fonction.

En fait ce qui unifie les définitions, c'est la notion de filtre.

Je crois que le seul cas où les deux définitions ne sont pas complètement interchangeables, c'est quand la fonction existe au point considéré, comme pour

Ou, pour le dire plus correctement, lorsque le point considéré est dans le domaine de la définition.

Notamment, lorsqu'on étudie les fonctions continues et la notion de limite, on montre des théorèmes comme (définition de limite ”avec le point”)

THÉORÈME 1. Une fonction est continue en ssi a une limite en .

THÉORÈME 2. Soit et , si a une limite en et si est continue en alors a une limite en et cette limite est .

et ces théorèmes sont plus pénibles à énoncer ou utiliser avec la définition de limite “sans le point”. (Dans le THÉORÈME 1 il faut ajouter que que est un point d'accumulation du domaine et quand on utilise le THÉORÈME 2 il faut traiter à part les points qui ne sont pas des points d'accumulation.)

Roger Godement, Analyse mathématique, t.1, p. 65 et Gustave Choquet, Cours de topologie, p. 26. Je n'ai pas Bourbaki sous la main, mais d'après le papier de Daniel Perrin suscité, c'est également la définition dite pointée qui est adoptée dans son traité. Je ne pense pas que Daniel Perrin ait inventé cela. Si je comprends bien ton commentaire, tout cela n'est en somme que des « sources secondaires » ?

Ce serait étonnant de voir une forte déviation entre Choquet et Godement d'une part et Bourbaki de l'autre. ;)

La définition “où on enlève le point“ donne des théorèmes plutôt moins jolis (par exemple la caractérisation d'une fonction continue par les limites) mais évite de devoir travailler avec deux définitions de limites (limite en un point du domaine et limite en un point extérieur adhérent au domaine) ce qui est peut-être un avantage “dans les petites classes”.

C'est un petit extrait dans la boucle d'interaction:

(cl-ppcre:parse-string "((?<small>[a-z]*)(?<big>[A-Z]*))")

J'appelle la fonction cl-ppcre:parse-string sur la chaîne de caractères "((?<small>[a-z]*)(?<big>[A-Z]*))"). Son métier est de compiler une expression rationnelle écrite en notation “perl-esque”. Le nom vient de PCRE pour Perl-Compatible Regular Expressions, une bibliothèque qui a été liée ou implémentée dans un bon paquet de langages.

La partie

(:REGISTER
 (:SEQUENCE
  (:NAMED-REGISTER "small"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\a #\z))))
  (:NAMED-REGISTER "big"
   (:GREEDY-REPETITION 0 NIL (:CHAR-CLASS (:RANGE #\A #\Z))))))

est la valeur de retour, c'est donc l'arbre syntaxique qui correspond à l'expression rationnelle. La partie (:CHAR-CLASS (:RANGE #\a #\z)) correspond visiblement à [a-z] et l'opérateur étoile est noté (:GREEDY-REPETITION 0 NIL …) et ainsi de suite.

La notation :REGISTER signifie juste un symbole ad-hoc – c'est en gros une chaîne de caractère immutable et c'est à peu près la même idée que les const REGISTER = 'REGISTER' qu'on peut lire en Javascript, mais en moins lourdaud. L'intérêt est que deux occurrences de :REGISTER sont toujours physiquement égales, ce qui permet de comparer rapidement les valeurs de ce type.

Dans le problème qui nous occupe, le module Lisp cl-ppcre permet de “lexer” à l'avance son expression rationnelle comme je viens de le montrer, pour ne plus avoir besoin de le faire à l'exécution.

Si on voulait vraiment compiler l'expression rationnelle à la compilation, on pourrait le faire en utilisant eval-when mais c'est un opérateur d'usage légèrement avancé.

Si je suis bien la conversation il y a une confusion entre deux choses:

• Les fonctions (pour faire simple) d'une bibliothèque qui ne sont jamais citées par une partie du code. Cela se teste en lisant le code.

• Les fonctions d'une bibliothèque qui sont citées mais dont on peut démontrer qu'elles ne seront jamais vraiment appelées pendant l'exécution du programme.

Dans le premier cas c'est un problème relativement facile à résoudre. Dans le second, il y a bien-sûr des heuristiques utiles qui permettent de traiter plein de cas intéressants en pratique, mais c'est impossible à faire “parfaitement” puisque c'est plus difficile que le problème de l'arrêt.