CrEv a écrit 4577 commentaires

En fait c'est pas vraiment le problème, le truc c'est que parfois certains logiciels ont eu du mal à compiler à cause de ça (ou alors ce n'était que le problème de libc je ne sais plus trop).
Mais oui avec brew on a tout plein de bonnes choses et en fait je cherchais surtout des raisons de dire que c'était moins bien parce qu'en vrai j'en ai pas vraiment vu…

par des changements de libc ? (mais ça commence à dater)
parce que par défaut ça utilise clang et non gcc ?

Un minifieur non, heureusement.
Un compilateur JS->JS oui. Google Closure Compiler sait le faire (et plein d'autres choses très bien). En général ça demande juste d'instrumenter un peu le code JS, en déclarant des types et autres choses du genre, mais c'est possible et très efficace. Ça fait aussi de l'inlining par exemple.

A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.

Et en pratique, ce problème arrive avec JS, pas avec Python

C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.

Je ne suis pas du tout d'accord.

Oué mais tu interprète mal ce que je viens d'écrire. Son discours est de dire qu'il est mieux pour soit, pour son esprit, pour son développement de retenir la dépendance qui a un nom clair que le oneliner (dans le meilleur des cas) assez imbitable (dans la majorité des cas) qui va faire le même taff. Son exemple sur zéro positif/négatif est assez intéressant dans ce sens. De toute façon, s'il n'existerait pas en module npm tu ferais quoi, tu l'écrirais une première fois. Puis si tu dois l'utiliser à plusieurs endroits de ton code, tu en fais un helper, une fonction quelque part. Et comme c'est un helper tu commence à le sortir de ton métier. Puis de ton projet car en vrai tu l'utilises dans plusieurs. Et voilà pourquoi tu crées un module pour ça. C'est plutôt logique.

Après qu'il y ait un problème avec le JS et / ou npm est une toute autre chose (et je pense que c'est le cas, mais je ne parlais justement pas de ça).

tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible)

Si je ne me trompe c'est quand même l'intérêt aussi de semver. Tu as prévu ton code pour fonctionner avec telle version, tu sais que si upgrade il y a et que semver est utilisé ça ne va rien cassé (parce que tu montera que sur des mineurs par exemple). Si la montée de ton framework t'intéresse (genre django, express, etc) c'est tout autre chose, c'est un élément vraiment central. Mais dans la majorité des cas ton upgrade devrait de toute façon être motivé par une vrai raison. Tes dépendances elles ne vont pas se mettre à jour automatiquement, si tu montes en version c'est que tu le veux bien au fond.

Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?

C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.

Cet article est bien intéressant, d'autant plus que contrairement à pléthore qu'on peut lire aujourd'hui, celui-ci a été écrit il y a plusieurs mois, et donc de fait loin de la polémique actuelle.

Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.
Là où la question est beaucoup plus intéressante c'est pourquoi on a besoin de ces oneliners ?
Evidemment la réponse est dans la pauvreté de la lib standard js…

C'est con, ton commentaire commençait pas trop mal mais sérieusement j'ai arrêté de lire après "j'ai arrêté de lire".

Aucun problème, tu étais quasiment arrivé à la fin.

Y'avait ptêt du moins con après ?

Plus ou moins (ben oui j'ai lu, mon commentaire étant plutôt une figure de style)

cette mode d'arrêter de lire un texte / commentaire parce qu'on est tombé sur une connerie

• Je ne vois pas bien en quoi ce serait une mode.
• Tout dépend de la taille de la connerie

Vous ne lisez que ce qui vous flatte ? Un écrit se doit d'aller dans votre sens du début à la fin et la moindre connerie suppose qu'il faut tout jeter ?

Qu'est-ce que tu racontes ?
Ce n'est pas une histoire d'avoir un écrit qui flatte ou qui aille dans un sens. Juste qu'un trop plein de généralisations emprunt de condescendance sur un ton si sur ne donne clairement pas envie de poursuivre.

Elle me fait penser à cette autre masse de citoyens/consommateurs/salariés qui fait des enfants et achète des voitures.

C'est con, t'on commentaire commençait pas trop mal mais sérieusement j'ai arrêté de lire après ça.

http://devmag.fr/meilleur-dev-de-france-2016-erreur-503/

Ça ne donne absolument pas envie :/

Il dénonce la corruption au sens large (mais il manque un peu de données pour ça, non ?) ou une corruption ?
Ce n'est pas vraiment la même chose.

Là n'est pas la question en fait.

Son action vise-t-elle à mettre au grand jour une fraude à l'assurance-chômage plus ou moins massive/organisée ou c'est juste quelqu'un qui a révélé que quelqu'un plus haut que lui fraudait ?
Si c'est le premier cas alors je veux bien entendre le terme de lanceur d'alerte. Si c'est le deuxième non, ce n'en est pas un.

Encore une fois, histoire que les propos ne soient pas mal interprétés, je ne juge absolument pas l'intérêt d'avoir dénoncé cette situation, c'est juste une histoire de terme. Je trouve qu'il manque un poil de vision global pour passer dans le cadre de lanceur d'alerte. Le problème c'est que sinon ça va faire comme beaucoup d'autres choses, ça va juste devenir un terme fourre-tout qui ne voudra plus rien dire.

Sans dénigrer aucunement ce que ces gens font, peut-on vraiment parler de "lanceur d'alerte" ?
Si je prend le dernier cas, celui du lien, il y a là une personne qui dénonce la fraude d'une autre personne officiant dans la même structure. Ok. Mais est-ce vraiment un lanceur d'alerte ?
Si je prend la définition wikipedia de lanceur d'alerte :

le lanceur d'alerte désigne une personne ou un groupe qui estime avoir découvert des éléments qu'il considère comme menaçants pour l'homme, la société, l'économie ou l'environnement

Que cette personne soit un dénonciateur (et donc sincère, sans mauvaises intentions au contraire d'un délateur) oui. Mais je ne vois pas en quoi c'est un lanceur d'alerte.

c'est par ce qu'ils ont compris qu'ils peuvent en tirer de l'argent…

S'ils ont compris qu'ils pouvaient tirer des revenus en portant des outils sous linux c'est plutôt une bonne nouvelle, non ?

Pourquoi pas imaginer l'utiliser pour faire du développement cross platform par exemple ?

Ne serait-ce pas une hype passagère ?

Exactement comme chaque langage en son temps.

80% de son argumentaire ne tient pas la route car ce sont des problèmes inhérent au monde de l'opensource

Mais encore une fois en quoi ça ne tient pas la route ? Ce n'est pas parce qu'un certains nombre de problèmes sont présent de manière plus globale dans le monde opensource que ce n'est pas un problème au global et que, appliqué au cas de javascript, ce n'est pas un problème en particulier.

Mon ressenti final, c'est que ce développeur à du mal avec la manière dont le code js est exécuté. Mais dès qu'on a compris, si on code comme dans tout langage, de manière classique, js n'est pas plus compliqué

Désolé, mais j'ai ri :-)

Et pour le reste, ce n'est pas parce que certains problèmes se retrouvent ailleurs que ça n'en fait pas des problèmes

• il est basé sur Java

Si je ne me trompe il est basé sur la JVM (ce qui est différent).
Et sinon, en quoi c'est un grand défaut ? Parce que là comme ça on dirait surtout du troll ;-)

En substance ton journal me fait penser à ce que j'écrivais ici même il y a un peu plus de 2 ans :

Il faut dire que j'ai été un peu moins passionné par le monde du web ces derniers temps. Ok, on trouve beaucoup de choses sur AngularJS par exemple, sur du CSS, sur des bibliothèques JS, etc. Mais je dois dire que j'ai un peu l'impression que ça tourne en rond. Certes c'est toujours plus mieux, certes il y a des nouveautés. Mais il y a aussi beaucoup de réinventage de roue, de NIH. Depuis que j'ai commencé à vraiment coder sur le web, il y a une petite dizaine d'année, j'ai l'impression que ça n'a pas beaucoup évolué par certains côtés. On se retrouve à, encore aujourd'hui, refaire une énième bibliothèque de composants html/js pour, par exemple, styliser des listes déroulantes. Le style à changé, c'est vrai. On est d'ailleurs passé par pas mal de choses, des biens lourdes pendant un temps, et on s'oriente vers du minimalisme, avec des couleurs bien utilisées et un accent sur la typographie. Les outils ont changé aussi, on voit maintenant fleurir le code utilisant des pré-processeurs malgré l'aversion de certains (less et sass, mais aussi stylus pour le css, coffeescript pour le javascript par exemple). On voit aussi les systèmes de build, de gestion de dépendance (bower et requirejs).

Tout ça c'est bien, ça va dans le sens d'une industrialisation dont le web (et plus généralement malheureusement le développement) manque cruellement. Mais se retourner et voir qu'on fait par certains côtés toujours la même chose depuis 10 ans, c'est tout de même un peu triste, non ?

Je n'imaginais pas alors qu'entre ce message et aujourd'hui il y aurait d'une part de réelles avancées du langage mais surtout une explosion des outils "nécessaires" à mettre en oeuvre pour faire une application web aujourd'hui. Comme tu le dis, grunt, gulp, browserify, webpack, babel, etc. Le setup d'un projet contenant du javascript aujourd'hui me hérisse le poil à un point que je cherches par tous les moyens de ne plus en faire de cette façon. Et je ne suis pas non plus pour l'usage immodéré de générateurs qui vont tout faire, on est souvent obligé de mettre la main dedans et ce n'est pas toujours joli.

Quoi qu'il en soit je vais juste parler de ma propre expérience. Peut-être y a-t-il quelque chose à en tirer.
Après des années à faire du web et principalement du js j'en ai eu marre. Attention, j'adorais le langage, je le maitrisais plutôt bien, pas de problème. Mais j'ai fini par faire overdose de l'écosystème immature (et on voit que ça ne s'est pas arrangé).

J'ai donc choisi de simplement pivoter. J'ai toujours aimé beaucoup d'autres langages. J'ai donc commencé (professionnellement j'entends, ça reste une façon d'y consacrer plus de temps) à m'orienter vers d'autres domaines. Ces dernières années (en gros depuis quelques mois après le message du début du commentaire) j'ai donc réalisé des projets utilisant :
- clojure côté backend (ok, plus angularjs en front)
- C++/Qt
- Ruby/Qt
- Ruby
- Dev mobile Android avec un gros coeur cross platforme en C++ (durant 1.5 ans full time)
- Go/Clojurescript

Aujourd'hui je reviens sur du web mais retour aux fondamentaux : Ruby on Rails + juste ce qu'il faut de js par endroits.

Il faut surtout voir l'ensemble de ces changements, l'ensemble de ces projets comme un chemin. Un chemin vers d'autres langages, d'autres façons de faire, d'autres écosystèmes. Ce chemin m'a au fond conforté dans l'idée que j'avais du monde javascript. Mais quand on commence à détester le langage qu'on utilise tous les jours, il est temps de regarder ailleurs, vraiment.

Au final je continue à utiliser Javascript mais plutôt à contre courant. Je l'utilise là où il est bon, c'est à dire apporter du dynamisme dans une page web. Je l'oublie pour absolument tout le reste.
Si j'ai réellement besoin de faire une application web basée sur du javascript, aujourd'hui je me tournerais sur du clojure/reagent ou du elm. Je ne vois javascript presque que comme un langage intermédiaire cross-plateforme.

Tout ça me fait aussi penser à un tweet de Sam Stephenson :

Some things we don’t use in Basecamp 3: Angular. React. Ember. Backbone. jQuery UI. ES6. Babel. Browserify. Webpack. Anything from NPM. Grunt

Personnellement j'adore JavaScript

Ok, pour avoir fait du js full time pendant plusieurs années de taff je peux comprendre :-)

c'est pour moi le langage le plus abouti qui soit à l'heure actuelle

Heu, par contre faut quand même garder les yeux ouverts :-D

Certes javascript évolue, dans un sens plutôt agréable, mais le plus abouti je ne pense pas.

Après oui, pas mal de gens ont du mal avec la gestion par évènements et se retrouve piégé dans un callback hell, ou à devoir faire des promesses de promesses.

A mon avis ce n'est juste parce que les gens ont du mal. Il y a des gens très compétents qui trouvent cela absolument horrible.

les fans de C++/Ruby

Mouai…

Un article parmi d'autres qui évoquent certains problèmes de node/js The Node.js Event Loop is a Damn Mess

Et si javascript ne devenait simplement pas un langage intermédiaire ?
Je me posais justement la question de pourquoi les nouveaux langages qui sont traduits en javascript ne ciblent-ils pas plus asm.js ?
Ainsi les performances seraient meilleures, asm.js ne serait qu'un langage intermédiaire, comme un bytecode au fond.

Il manque un langage dans ta liste, Clojurescript. Fonctionnel, élégant, concis, lisible. Certes c'est un dérivé de lisp et donc est plein de parenthèses.

On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d'async/await. Il n'empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

C'est un des points que j'apprécie vraiment le moins aujourd'hui dans le monde javascript. Ok, avant il y avait des callbacks et c'était pas terrible. Mais ce qu'on fait aujourd'hui avec les promises n'est pas tellement mieux, au prix d'une lourdeur d'écriture et de, en général, une difficulté à avoir quelque chose de proprement testable. Certes async/await va dans le bon sens, mais il y aura encore des Promises.

Dans mon taff je bosse parfois sur un projet basé sur Electron. Au final nous avons choisis de faire un backend Go et un frontend à base de clojurescript. Tellement plus agréable. Et l'utilisation de core.async répond tellement mieux à la gestion asynchrone que les promises que ça donne encore moins envie d'aller voir du côté de javascript "classique".

(go (let [results-from-first-request (<! (get-first))
          results-from-second-request (<! (get-second results-from-first-request))]
      (.log js/console results-from-second-request)))

Ok, en brut comme ça c'est pas simple et ça nécessiterait un article entier (à venir) mais pour faire simple j'ai deux requêtes asynchrones, la deuxième dépendant du résultat de la première. Et pourtant je l'ai écrit quasiment comme si c'était synchrone, à part go et <!.

Si je ne me trompe ce ne sont pas les types qui calment, mais la preuve.
Après le non merci, c'est rapide comme jugement. Parfois tu veux vraiment prouver que ton code fait ce que tu lui as demandé. Et oui ça a un coût.
Ce qui est intéressant dans SPARK (en tout cas le 2014) c'est que tu peux alterner en disant que telle portion est uniquement couverte par des tests unitaires, telle portion est prouvée. Justement dans le but de réduire le coût total.
Mais ce que je trouve intéressant c'est que justement, même pour un cas hyper trivial comme chercher un élément dans une liste on se rend compte que ce n'est pas trivial au final. Rien que la valeur de retour lorsqu'on ne trouve pas d'élément est un vrai problème.

Merci, c'est très sympa comme journal.

Moi qui n'ai pas (encore) appris Haskell (mais qui joue en clojure) ça permet de se plonger dedans petit à petit à partir d'un exemple "simple" et c'est plutôt cool.
Bon par contre je vais le re-lire à tête reposée par ce que je ne suis pas sur d'avoir tout capté :-)

Au temps pour moi, en plus on m'avait fait la remarque avant que je publie (c'est ça d'avoir aussi des collègues qui moulent ici :-))
Je me suis fait avoir par l'article qui comparait ES7 et ES6 et j'ai indiqué ES6 mais en effet ça date d'ES5. Merci de la précision.

Sinon pour le moment j'utilise plutôt reagent que Om. Faut dire que ça marche plutôt bien.

hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.

Étant donné que sous Git il faut fetcher pour récupérer ces commits, même si ce n'est pas exactement la même chose que sous mercurial ça fait le job.

De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.

Oui, le l est pour local dans chacun des alias

Après ces alias sont quand même très simple.
Si je prend lout qui est celui que j'utilise le plus souvent dans cette liste :

lout = log --pretty=oneline --abbrev-commit --stat --graph @{u}..

--pretty=oneline --abbrev-commit --stat --graph ne sont que des commandes de mise en forme mon log. En gros ça permet d'avoir un arbre (et donc de visualiser les branches), de n'avoir que la première ligne du message de commit et d'avoir les stats sur les changements.
La seule chose vraiment intéressante est @{u} qui correspond à la branche d'upstream.
La commande demande donc le log (avec mise en forme) de la différence entre la branche upstream (depuis le dernier fetch) et la version qui est dans ma copie de travail.

Genre :

❯ git lout
* b48c7f0 Plop
* 42144f6 Update mk
|  iOS.mk | 51 +--------------------------------------------------
|  1 file changed, 1 insertion(+), 50 deletions(-)
* 60ea549 Update readme
   Makefile | 1 +
   1 file changed, 1 insertion(+)

Où je vois que je peux pousser sur mon upstream une branche contenant deux commit qui a été mergée.