Michaël a écrit 2935 commentaires

morts parce que pas contre le mode de vie occidental

Le terroriste ne leur a rien demandé, ils sont morts par un funeste hasard sans aucun égard à qui ils étaient ou ce qu'ils pensaient.

Comme quoi une connaissance fine des standards C permet de temps à autre de briller en société! ;)

note : il a à ma connaissance toujours été discret la dessus […]

Au temps pour moi: “je croyais savoir et je m'a trompé”

Pour Mr Obama, ça se compte en millions même.

C'est vrai du coup j'ai fait un petite recherche vite-fait, pour trouver quelques chiffres sur les ventes de livres en France pour tomber sur un article du point pour 2016 et celui-ci du Figaro pour Sarkozy en 2015 et il s'en dégage que des ventes de plus de 200.000 exemplaires sont carrément cannons. Pour en revenir à Macron on peut en déduire que l'éditeur espère que le livre se vende bien et donne plus de 1 EUR par bouquin à l'auteur.

Le candidat anti-riches source de tous les maux […]. A sa décharge il ne faut pas oublier qu'il a eu plus de temps (c'est le plus vieux) et que c'est cohérent par rapport à ses revenus

Je crois savoir qu'il n'a pas fondé de famille ce qui rend encore plus grande la part de ses revenus qu'il a pu investir.

À part ça j'ai sauté sur ma chaise en entendant hier que Macron aurait reçu 274.000 euros d'avances sur droits d'auteurs pour son libre “Révolution” – Je connais des auteurs qui sont super heureux d'en avoir 15000: il n'est pas un peu “gros” ce chiffre?

Ton analyse à plusieurs faiblesses. La plus grave est que tu ne fais pas tout l'analyse des menaces sur l'utilisateur de la banque en ligne et ne peut donc pas critiquer la solution que tu prétends analyser au regard de son efficacité. Le second point est que ton discours, purement technique, entame rapidement ta crédibilité: il n'y a aucun intérêt à hasher des chiffres: il n'y a que dix chiffres et donc autant dix valeurs de hashs possibles.

L'intérêt du procédé est qu'il demande à l'utilisateur de montrer qu'il connaît un secret, sans dévoiler l'intégralité du secret à la connexion. Il y a de nombreuses situations où cela se montre utile, par exemple si on se connecte en public (sur son portable) ou si l'ordinateur est surveillé informatiquement (par exemple via une vulnérabilité du navigateur).

(Ceci dit il faut rappeler que cette procédure de connexion permet d'accéder aux relevés bancaires mais ne permet de réaliser aucune transaction, pour lesquelles une authentification supplémentaire est nécessaire.)

Bien-sûr que non. En revanche ça répond assez bien à la question “existe-t-il des cas où bash est nécessaire?”

Qu'est-ce que tu cherches au juste dans cette discussion? De l'aide?

existe-t-il des cas où bash est nécessaire ?

Oui, par exemple pour lancer un script bash, c'est-à-dire le cas qui t'intéresse ici.

bash est un interpréteur pour un langage spécifique, qui est différent des autres shells, même si à l'instar des ksh, zsh, dash, fish ou le sh de BSD, il interprète correctement les script écrits pour le shell de Bourne (le /bin/sh historique).

Il y a plein de façon de prouver cette différence, par exemple en comparant les docs où en faisant comme toi une expérience un peu amère. Maintenant que tu as compris l'erreur, c'est le moment de commencer à réparer.

Ben, si tu veux pas t'embêter sur ce genre de détail, lances plutôt ton script en ./script.sh (après l'avoir rendu exécutable), non ?

Le plus simple serait sûrement de se conformer aux instructions du fabriquant, qui donne une ligne de commande à recopier dans le terminal!

pourquoi avoir fait une partition /usr separée,

Tu poses la question dans l'absolu ou dans le cas particulier du PI?

Pour faire du télé travail depuis plus de 4 ans, la productivité est pas aussi bonne, et c'est usant pour le mental. […]

Les communications électroniques sont effectivement beaucoup plus fatigantes (pour l'attention) que les communications orales et elles prennent plus de temps – et puis c'est moins cordial.

Là où je travaille on a un “flex-friday” où on peut travailler d'où on veux, donc ça peut-être au bureau, mais aussi chez soi, chez des amis qu'on va voir pour le weekend (comme ça on peut partir le jeudi soir et paser plus de temps chez eux), efin, où on veut quoi.

Je trouve ça super sympa, ça permet d'éviter la fatigue du trajet (je prends le train les autres jours, c'est pas la mort mais c'est quand-même un peu stressant), de caler ses rendez-vous genre toubib, administration, ou même juste le coiffeur ou faire ses courses à des moments où ces services ne sont pas blindés de monde, et quand on aime bien sa maison c'est super chouette.

Ma situation est donc une situation hybride et je la trouve très agréable. J'ai connu la situation “full-remote” (comme on dit dans le patois d'ici) dans un contexte un peu différent, celui où je faisais la thèse, et quand l'environnement de vie est mélangé à celui du travail, on devient zonzon – en somme c'est aussi sain que si on prenait l'habitude de prendre ses repas dans sa salle de bain!

Alors là, je rigole !!

Un jour où on rit est une belle journée, non? :)

Simplicité …

Simplicité veut dire beaucoup de choses, dans mon propos c'est “simple” comme dans “pas beaucoup d'instructions”. Et puis ça n'a aucune intérêt de pinailler là-dessus, je continue de voir une seule solution plausible postée elle est en awk et elle est courte. C'est tout ce que je veux dire et c'est un simple constat.

L'auteur n'a d'ailleurs pas répondu aux questions de guppy qui avait présenté son aide…

Ce n'est pas une raison pour en tirer des déductions hasardeuses!

je ne prendrais pas ça à la légère

Qui parle de prendre ça à la légère? Ce n'est pas parcequ'une solution utilise un langage plus puissant qu'elle est intrinsèquement meilleure: il y a plein de gens qui n'écrivent pas leurs programmes en OCaml et je peux concevoir qu'ils aient leurs raisons.

c'est juste que de mon point de vue, ce genre de solution convient plus pour dépanner, et que pour le besoin en question

Encore une fois, tout ce dont il est question ici, c'est de faire un traitement bien déterminé une fois sur deux fichiers bien déterminés. On peut appeler ça dépanner ou pas, ça ne change rien à l'affaire. Dans cette situation il est parfaitement légitime d'utiliser “le plus petit programme” qui fait le travail (pas maintenable, pas débogable, pas extensible ne sont ici pas des inconvénients).

Je ne suis le premier à privilégier une solution bien structurée et généralisable si elle semble nécessaire, mais utiliser sed et awk (ou ce qu'on veut d'autre) pour effectuer des traitement uniques sur des fichiers c'est le pain quotidien de l'utilisateur d'Unix que je suis, et je n'ai pas la place dans mon salon pour encadrer et afficher toutes les descriptions de traitement!

C'est certainement utile de connaître awk mais dans le cas présent, la solution donnée répond à un exemple très simple (quelques lignes à traiter) mais ne m'apparaît ni réutilisable ni compréhensible par un non-expert.

L'idée que la solution doit être réutilisable et utilisée sur d'autres fichiers que les deux montrés est inventée par toi.

La solution tient sur 4 lignes, la belle affaire

C'est pas un challenge, c'est une mesure de simplicité.

Encore une fois, ce qu'on peut voir c'est un visiteur paisible et constructif qui a proposé une solution plausible en awk et deux autres visiteurs qui préfèrent pontifier sur ce qu'il faudrait beaucoup mieux utiliser un langage de plus haut niveau, que ce na doit pas bien être compliqué, mais qui se gardent bien de joindre le geste à la parole.

que de bricolages «quick & dirty», le genre de choses que tu utilises quand tu n'as besoin que de faire quelque chose une fois et oublier à jamais

Et qu'est-ce qui te laisse penser que ce n'est pas le cas? L'OP parle de deux fichiers et d'un traitement, rien de plus.

Après, on peut discuter éternellement sur l'adéquation d'un outil à faire quelque chose. Si l'argument c'est simplement que c'est possible, alors oui, mais c'est aussi possible en Brainfuck.

Oui mais personne n'a publié de solution ni en Brainfuck (ça ne suffisait pas l'assembleur) ni en Python ou autre chose et quelqu'un a publié quelque chose qui résout le problème posé, et tient en 4 lignes de awk. Après évidemment qu'un langage de plus haut niveau permet de déboguer ou de faire évoluer le programme. Rien dans le contexte ne laisse penser que ça peut avoir une importance ici, pourtant tu décides de lui en donner.

La question, c'est un peu la même que si tu appelles un plombier pour une fuite. […]

La question c'est une personne qui a une fois besoin de faire un traitement sur deux fichiers bien précis.

Du coup, perl, ruby, python, R, on s'en fout un peu, mais à mon avis il faut changer d'outil.

Donc du coup, les solutions vaporware qui n'existent pas sont mieux que celles proposées?

Quelqu'un qui connaît bien awk s'est donné la peine de prendre 5 minutes pour écrire une solution qui marche et qui tient sur 4 lignes, j'ai un peu du mal à y voir une preuve de l'inadéquation de awk pour faire ce traitement.

Ils veulent publier une forme neutralisée: qui ressemble assez à l'original pour que les experts puissent en évaluer l'authenticité mais qui est assez modifiée pour ne pas être utilisée.

Il doit perdre du temps à expliquer au client pourquoi telle ou telle chose n'est pas souhaitable, lui montrer les incohérence qu'elle produit etc.

“Consacrer” me semble plus judicieux que “perdre”, notamment pour la raison que rendre compte de ses choix techniques devant son client est une manière comme une autre de les mettre à l'épreuve, ce qui créé de la confiance.

Quelqu'un peut m'aider please ?

Oui, qu'est-ce que tu as commencé à faire? Où est-ce que tu coinces? Tu as essayé avec awk?

Exemple de code trop concis :
msg = "Hi " + ("there" if not name else ("Neo" if name == "Anderson" else name))

Le problème n'est pas la concision, c'est l'imbitabilité. Il y a aussi des formes longues qui sont imbitables, c'est complètement indépendant de la concision.

Un bon exemple de bavardages inutiles est l'utilisation de curseurs pour explorer les structures de données, qui dans de nombreux cas peuvent avantageusement être remplacés par des fonctions d'ordre supérieur. (Dans certains cas, les curseurs sont indispensables, par exemple si l'exploration doit être contrôlée finement, avec des pauses, des reprises, des bifurcations par exemple.) Qu'on juge:

/* Itérateurs à la C++ de la vieille école */
for(x = set.begin(); x != set.end(); ++x){
   cout << x;
}

contre

(* Fonctions d'ordre supérieur, à la OCaml *) 
StringSet.iter set print_endline

La second version est plus claire, car l'intention est directement mise en évidence, alors que dans la première il faut d'abord réduire la boucle for pour comprendre ce qu'elle fait, ce qui est rendu complexe par une variable supplémentaire, le x, qui a disparu dans la seconde version.

Un autre exemple très frappant est l'utilisation du pattern matching, ici pour définir l'évaluation d'expressions booléennes:

type expr =
| Atom of string
| Not of expr
| And of expr * expr
| Or of expr * expr

let rec eval truthtable = function
| Atom(a) -> truthtable a
| Not(a) -> not(eval truhtable a)
| And(a,b) ->  (eval truhtable a) && (eval truhtable b)
| Or(a,b) ->  (eval truhtable a) || (eval truhtable b)

C'est un code très concis, surtout en comparaison de l'équivalent C++ qui demande d'implémenter un visitor pattern sur 2-3 pages pour faire la même chose, et de faire de chaque cas du type une classe à part, ce qui ajouteau bavardage. Sur cet exemple, le code plus court gagne sur toute la ligne: plus facile à écrire, et surtout à lire: l'intention est claire, la vérification est immédiate et la maintenance aisée.

Bien-sûr, on peut aussi utiliser les possibilités d'un langage pour écrire des choses absconses et difficiles à maintenir, mais existe-t-il un seul langage où cela n'est pas possible? Même des langages relativement pauvres en termes d'expressivité, comme le C ou Java par rapport à OCaml, Python ou Javascript, offrent tout ce qu'il faut à un programmeur pour écrire n'importe comment. Roedy Green et ses coauteurs ont d'ailleurs abondamment documenté ces techniques!

Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.

Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.

Ainsi donc, si on fait l'hypothèse que “le temps de travail utile” contribue soit directement à l'élaboration du produit final, soit à apprendre des choses on conclut qu'on peut réduire les coûts sans sacrifier la qualité sans pour autant arriver à une situation plus enviable pour l'entreprise: c'est le cas où on a rogné sur l'apprentissage.

Ceci dit, je peux passer l'âme tranquille à la suite de mes remarques, encore moins intéressantes que la première:

Technique n°2 — se limiter strictement au cahier des charges

Parfois, en tant que développeur, on se dit "ah mais si je fais ça de telle manière, ça prend juste quelques jours de plus et ça permet d'avoir un système plus évolutif". Et en général plus complexe, donc plus fragile.

Oui et non, vu que très certainement il va falloir faire la maintenance du logiciel, cela peut être une bonne chose de s'y préparer – avec discernement, mais c'est justement ce discernement que peut apporter l'expérience au travers d'une palette de techniques éprouvées et validées qui résolvent justement ce problème.

Disons que si on se limite strictement au cahier des charges de façon la plus littérale qui soit, on peut dans certains cas torcher un programme tout mal fichu “qui fait le job” mais dont les évolutions sont impossibles à partir de 4-5 itérations, et là on se retrouve dans la pire situation, avec un bug en prod et un logiciel tellement mal conçu que réécrire tout ou partie est un a priori nécessaire à la réparation! (Vécu.)

Technique n°4 — faire du « test-driven » sur les interfaces

J'ai l'impression que tu cantonnes le “test-driven” aux test unitaires automatiques. C'est un exemple important, mais je trouve l'approche “test-driven” particulièrement utile pour la conception du logiciel, et même dans le cas où on n'automatise pas les tests. Privilégier les tests oblige à concevoir des modules qui ne font pas référence au contexte global de l'application, ils sont donc plus facilement réutilisables. Je trouve aussi particulièrement utile de déléguer tous les accès au système à des classes spécialisées: le reste du code est alors essentiellement pur et peut-être testé avec des classes simulant les appels système (mockup). Cette technique réduit la complexité de mise en œuvre du test et accélère la boucle de développement.

Technique n°6 — Diviser pour mieux régner

Bien souvent les jeunes diplômés (en particulier) ne veulent pas faire de maintenance mais veulent concevoir un logiciel entier. Et lorsqu'il s'agit de reprendre du code, plutôt que le faire évoluer ils préfèrent souvent tout refaire de zéro.

Ils ont bien tort, faire de la maintenance est une des meilleures écoles pour apprendre à programmer simplement et efficacement! (Si on se donne la peine de tirer les leçons de chaque opération de maintenance.)

Technique n°7 — Écrire du code simple

« Ce qui se conçoit bien s'énonce clairement » — Nicolas Boileay-Despréaux.

… et les mots pour le dire viennent aisément!

Souvent les développeurs veulent faire des choses compliquées, et exploiter les fonctionnalités d'un langage au maximum. Mais la réalité c'est qu'un logiciel qui est écrit simplement fonctionne aussi bien qu'un logiciel exploitant toutes les particularités d'un langage.

C'est exact, mais cela néglige complètement l'aspect maintenance (et aussi l'aspect apprentissage). Si une version, en plus d'être plus courte, est plus facile à maintenir, il n'y a aucune raison de ne pas la retenir!

PS.: Bon, évidemment c'est de l'humour et donc parfaitement exagéré, mais si c'est drôle, c'est parceque cela éxagère quelques chose de vrai.

Les accolades sont inutiles dans ce cas, ceci est suffisant :

C'est exact, cependant lorsqu'on programme beaucoup en shell, on utilise souvent les modificateurs :?, :-, :+ etc. qui eux nécessitent les accolades, on prend alors l'habitude d'utiliser systématiquement les accolades.

Je sors

Mais non, mais non, c'est sympa. Quelqu'un le fait en APL?

Quelques remarques:

1. Attention à la protection des variables, tout explose si les variables ont plusieurs mots!

[[ "${valeur}" == "${ancienvaleur}" ]]

Et puis quitte à utiliser des mots français, autant accorder l'adjectif, non? :)

1. echo n'est ni robuste ni portable et ne doit être utilisé que pour des messages fixes.

printf '%s,%s\n' "${ancienvaleur}" "${anciencommentaire}"

1. Ton programme a un petit problème d'IFS, il lit le # dans anciencommentaire.

2. Il crée une ligne supplémentaire , au tout début!

En traduisant le code en sh cela devient donc

    sort -nk1 fichier_source | while IFS='# ' read valeur commentaire
    do
      if [ "${valeur}" = "${ancienvaleur}" ]
      then
        newcommentaire="${anciencommentaire},${commentaire}"
      elif [ -n "${ancienvaleur}" ]
        printf '%s,%s\n' "${ancienvaleur}" "${anciencommentaire}"
        newcommentaire="${commentaire}"
      fi
      anciencommentaire="${newcommentaire}"
      ancienvaleur="${valeur}"
    done

(Il y a un petit problème de mathjax dans le bloc de code avec tripe contr'apostrophe, désolé pour le formatage.)

Mon point de vue est que le shell est très bien pour combiner des traitements ensemble mais qu'il est plutôt à éviter pour implémenter ces traitements eux-mêmes. Les raisons sont que le langage rend la description de ces traitements difficile – même si certains dialectes comme bash ou zsh améliorent un peu la situation. Voici donc une procédure awk qui fait le travail, mais beaucoup d'autres langages peuvent être utilisés à sa place:

BEGIN {
    FS=" #"
}

{
    if($1 in seen) {
        origin[$1] = origin[$1] "," $2
    } else {
        origin[$1] = $2
    }
    seen[$1]
}

END {
    for(result in seen){
        printf("%s #%s\n", result, origin[result]);
    }
}

Le cœur du programme est la partie

{
    if($1 in seen) {
        origin[$1] = origin[$1] "," $2
    } else {
        origin[$1] = $2
    }
    seen[$1]
}

qui est appliquée sur toutes les lignes de l'entrée. Les variables $1 et $2 renvoient à la première et deuxième colonne de la ligne en cours de traitement, la déclaration BEGIN { FS=" #" } dit justement comment ces colonnes sont délimitées. La phrase seen[$1] est peut être un peu bizarre, elle correspond à l'ajout d'une clef sans valeur dans un tableau associatif.

Lorsque toutes les lignes ont été traitées, awk* passe au bloc END dont le contenu est lui aussi explicite.

Mais voilà, c'est la vie. Je vais pas en faire une sorte de conclusion générale (et négative) sur le processus de développement dans le logiciel libre, ni me faire une opinion générale (et très négative aussi) sur une équipe de gens que je ne connais simplement pas, encore moins aller la diffuser dans un post.

Oui mais il faut bien reconnaître que c'est toujours plus facile de croire que la source de ses propres problèmes ou déconvenues réside exclusivement dans le comportement et les appréciations des autres! Dans une relation il y a deux personnes (au moins) et si la relation ne se passe pas bien, en l'absence de pathologies, la responsabilité est partagée et c'est aux deux de faire des efforts pour améliorer la relation.