Michaël a écrit 2929 commentaires

Puisqu‘on fait des efforts de traduction «homme de paille» a un sens en français (grosso modo celui de «prête nom» ou de «faux-nez») qui est assez différent de celui de «strawman» dans le contexte d‘un débat. Peut-être que contre-feu ou enfumage pourraient mieux faire l‘affaire?

Un expédient facile consiste à créer un script shell privilégié qui exécute la seule commande autorisée pour l'utilisateur puis à permettre à l'utilisateur d'utiliser ce script (par exemple via sudo) tout en lui interdisant de lire les codes d'accès à la BDD.

Il faut un peu de soin et quelques groupes/utilisateurs intermédiaires si tu ne veux pas que tout tourne en root mais toute l'implémentation ne présente pas de difficulté particulière.

Voici une excellente introduction à sudo:

https://www.bsdcan.org/2014/schedule/attachments/283_2014-04-29%20sudo%20tutorial%20-%20bsdcan%202014.pdf

Et comme disait mon ancien boss : "la différence entre perl et whitespace, c'est que dans whitespace, l'obfuscation c'est fait exprès". La même marche aussi avec lisp, évidemment.

Blage à part, écrire des programmes illisibles ou difficiles à modifier pour d'autres raisons est plus une question d'état d'esprit que de langage.

Qu'il s'agisse de Java, Perl, Lisp, C, Python ou quoique ce soit d'autre. Même en Shell on peut écrire des programmes propre et maintenables, c'est dire!

J'ai des notions en Python et je ne cesse d'apprendre plus

Salut, les autres ont déjà suggéré des outils, j'élabore en te proposant un “mini plan de travail”:

1. Choisi un outil (par exemple Python + openpyxl comme suggéré)
2. Fait un petit programme qui démontre que ton outil peut parcourir ta fiche excel, par exemple fait un “print” des noms des onglets puis des contenus de chaque onglet – ainsi tu es sûr que ton outil te permet de lire toutes les données.
3. Fait un petit programme qui te permet de générer un nouveau fichier excel, avec un contenu de ton choix, similaire à celui que tu veux générer – mais tu peux partir d'une donnée statique au lieu du résultat d'un traitement conpliqué. Ainsi tu démontres que ton outil te permet de générer le document que tu souhaites.
4. Implémente ton traitement qui traite une structure de données adaptée (celle qui te permet de vérifier rapidement que ton traitement fait ce que tu veux!) et la transorme en une autre.

Un fois que tu as tout ça, tu as traité chaque problème difficile de façon isolée et tu as aussi réduit le risque de passer trop de temps à programmer une solution qui ne marche pas (en commençant par 2 et3 au lieu de faire “1 4 3”).

Bon courage et amuse toi bien!

Si tu veux trouver la voie je te suggère la vidéo de la présentation de Aaron Bieber:Evil Mode: Or, How I Learned to Stop Worrying and Love Emacs

C'est l'histoire d'un mec qui va au “Boston Vim user group” pour dire “ben maintenant j'utilise Emacs”. Son raisonnement est que le evil-mode donne une bonne partie de la puissance de vim et que Emacs est bien plus simple à configurer que Vi.

XMPP C'est bien mais il convenir d'un RDV pour tchatcher un peu. Par exemple ce soir dimanche pourquoi pas, ou bien lundi matin vers 9:30 par exemple?

Salut comme je viens de démissionner et que je joue à l'ingénieur DevOps / consultant infrastructure depuis quelques années, je peux prêter main-forte pour faire une belle pipeline d'intégration et déploiement continus, si ça peut aider. :)

Houaaa, CDE, je l'ai utilisé sur des stations UNIX (je ne sais plus lesquelles).

À la fac de Rennes cela tournait sur des stations Sun Solaris au début des années 2000. :)

Je trouve qu'il est très souvent plus pertinent d'utiliser un éditeur WYSIWIG utilisant un sous-ensemble bien réduit du HTML qu'un texte Markdown, par exemple CKeditor5.

C'est un contresens historique. Le format, ou plutôt les formats, Markdown sont en gros une formalisation du marquage informel qu'on utilise ou utilisait dans les courriels et les messages Usenet, formalisation à laquelle s'ajoutent des extensions (notamment pour les hyperliens les images et les tableaux). Mais le cœur de la syntaxe (le gras, l'italique, les listes, les citations et les “snippets”) sont compris depuis longtemps par certains clients mails, et n'a pas été définit a priori mais résulte d'une pratique existante.

Le Markdown est né d'un usage légitime puisqu'il s'agissait d'ajouter un peu de formatage à un support purement textuel.

Sinon il me semble que le Rich Text Format est sémantiquement équivalent à un sous-ensemble du HTML et si on tient à préparer son texte avec un éditeur WYSIWYG ce serait peut-être un choix plus intéressant qu'un sous-ensemble du HTML, à cause du nombre d'éditeurs disponible.

Le truc, c'est que j'essaie de cultiver des idiomes, et l'usage de printf me semble en être un bon: […]

C'est exact, personnellement je préfère aussi utiliser printf systématiquement. echo n'a presque que des inconvénients… pourtant on l'utilise et le rencontre encore souvent.

Il me reste tant à apprendre, et ce n'est pas en me croyant bon que je le deviendrais.

Ce que je voulais dire est que le fait de programmer le shell n'a pas forcément à voir avec celui d'être admin! Les sources qui m'ont fait faire beaucoup de progrès sont la lecture des divers scripts shell qu'on trouve dans FreeBSD notamment.

une ligne de bash "illisible" (de mon point de vue, ce concentré de caractères sans espaces est pénible à lire du moins) et qui risque de se retourner contre moi, je préfère les 50 lignes de C standard.

Pour bien connaître (ou avoir connu) les deux, chacun se défend bien en termes d'illisibilité. Pour améliorer les choses quand on programme le shell, il faut utiliser des fonctions dont les noms sont explicatifs, je fais la traduction:

listen_udp()
{
  nc -u 12345 -l
}

sendto_udp()
{
  # Sur ma version de NC j'ai besoin du -w 0
  #  pour que NC arrête d'essayer de lire STDIN après
  #  la fin du message.
  nc -w 0 -u 127.0.0.1 12345
}

Et le programme s'écrit

listen_udp & echo "le résultat" | sendto_udp

Cela démarre en arrière-plan (&) un serveur qui écrit tous les messages reçus sur UDP puis envoie un message sur ce serveur.

Aussi, j'ai appris à me méfier d'echo, et une pratique que j'essaie de faire au max est de toujours utiliser printf, pour éviter les surprises.

La “bonne pratique” est de n'utiliser echo que sur un texte constant (c'est le cas ici) qui de plus ne commence pas par un tiret. Pour tout le reste on utilise printf en utilisant une chaîne de format constante.

a doit être lié au fait que je suis un dev qui joue aux admins, et pas un vrai admin

On a le droit de bien connaître le shell même sans être admin. :-)

Je ne comprends pas trop quel problème tu veux résoudre, est-ce que tu peux en dire deux mots? (Quitte à changer, pourquoi pas simplement “publié”?)

Je pense que l'approche d'effacer n'est pas la meilleure, il vaudrait mieux déplacer les fichiers ARW dans le même dossier que les fichiers JPEG qui leur correspondent. L'intérêt est que c'est une fonction qui a son utilité en soit, et qu'elle résout le problème: il suffit de déplacer les fichiers JPEG qu'on ne veut pas dans un dossier spécial, d'e faire suivre les fichiers ARW puis des procéder à l'effacement.

La logique serait, étant donné SRCDIR (dossier où étaient tous les fichiers) et TARGETDIR (fichier d'arrivée):

• On examine TARGETDIR et con construit la liste de tous les fichiers JPG qui n'ont pas le fichier ARW correspondant.
• On examine SRCDIR à la recherche des ces fichiers, lorsqu'ils existent on les déplace à côté du fichier JPG et dans le cas contraire on afficher un avertissement.

Des points bonus pour l'écriture d'un fichier “undo”, un shell script qui permet d'annuler la dernière opération! :-)

L'azerty amélioré a l'air d'être une galère pour les dev/ops, (double)quote, dollar & co passent forcément par alt-gr.

Cela fait depuis plus de dix ans que je suis passé au QWERTY – avec la touche compose de Xorg, tous les accents sont faciles à faire, et si d'aventure on travaille sur un Mac, les caractères nécessaires au français – y compris guillemets et œ, æ – sont faciles à faire.

Pour programmer, le QWERTY US est le clavier le plus facile, probablement. L'AZERTY est peut-être plus utile pour la dactylographie, mais pour la programmation j'ai toujours trouvé que c'était un inconvénient.

En pratique, c'est utilisé pour, justement, utiliser des variables du shell. Sinon, l'intérêt est limité.

Ça dépend des pratiques, et ça dépend des occurrences du caractère $ ou des contr'apostrophes dans le document.

Dans ma pratique, j'utilise très souvent la forme “qui ne remplace pas les variables.”

en utilisant l'astuce

Pourquoi astuce? :-)

Il y a deux choses à améliorer:

cat << EOF | python
…

Est plutôt

python <<'EOF'
…

Pas de cat et apostrophes simples autour du EOF dans l'ouverture du document ad hoc. Les apostrophes simples disent au shell de ne pas toucher au contenu – pas de remplacement de variables notamment. Par contre la marque de fin reste EOF sans apostophes simples.

Si si, tu en apprend que si tu es en face d'une bande d'illuminés armés jusqu'aux dents, eh bien t'as intérêt à vénérer le barbu imaginaire comme il faut.

Vu l'actualité troublée de l'Église (notamment France, Allemagne, USA et Australie) cette phrase semble être à double, tripe voire quadruple tranchant!

Caster c'est un fanpôme, mais un gentil.

C'est vrai mais Caster reste un anglicisme, en français ce serait Gastard.

Et puis de toute façon on peut pas faire confiance à une carte où le Groenland est presque aussi gros que l’Afrique.

Les angles y sont corrects. ;)

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.