C'est une histoire de choix, pour le moment, on préfère servir plus d'utilisateur que de monter une couche TLS qui nous semble bien inutile dans notre cas.
Y'a des statistiques et des tests qui montrent que le(s) serveur(s) actuel(s) tomberaient avec "une couche TLS" et autant d'utilisateurs quotidiens ?
Si ce n'est pas le cas, il n'est jamais trop tard. Ca se met en place en production en moins d'une heure. Surtout avec les nouveaux venus du genre Let's Encrypt.
Je juge pas hein, mais perso', e-commerce ou non, password chiffré client-side ou non, c'est niet si pas de SSL. Trop de possibilités de MITM, sans grand intérêt certes, mais question de principe.
Sinon, l'idée est vraiment bonne. Reste à voir si ça prendra, étant donné que ce genre de concept est (me semble ?) de plus en plus courant.
Pour le moment, le workaround qui me convient le plus est Immutable.js
Un coup, ce sont des require CommonJS, l'autre des import/export d'ES6. Et je ne parle même pas du temps fou qu'il faut passer pour réussir à les compiler. Et quand vous avez un outil qui marche, vous pouvez être sûr que dans quelques mois, ses plugins pour faire du sass ou générer des sprites ne seront plus maintenus.
Rarement eu ce genre de problème sur un projet sérieux…c'est sûr que celui qui clone n'importe quel skeleton fait à l'arrache sur github, et qui n'utilisera même pas 10 % de ce que propose ledit skeleton, il va se heurter à ce type de souci. Je suis partisan de minimiser au maximum l'aspect build d'un projet. Webpack + Babel + ESLint + WhateverTestTool, ça permet déjà de faire énormément de choses.
Celui-ci continue de gagner en popularité, mais aussi en complexité.
Tout dépend AMHA de la définition donnée à "complexité". Pour moi, ES6 est plus "simple" que jamais, et franchement, il était temps. Non pas que je n'aimais pas les surcouches type CoffeeScript, mais tendre vers l'unification, je trouve ça bien.
Il est pour moi clair que Javascript a accumulé une dette technique considérable. Ca s'améliore petit à petit…..vraiment petit à petit (un bon support ES6 natif sur les navigateurs, ce serait déjà pas mal). C'est le revers de la médaille. A côté de ça, on a un langage exécutable à peu près partout (une application mobile tout en Javascript c'est très faisable), et un écosystème assez exceptionnel (merci CommonJS, merci AMD).
Et vous, quels sont vos langages du moment ? Et que font-ils mieux que JavaScript ?
A titre personnel, je préfère cent fois écrire du ScalaJS. Mais avec ES6, je ne me sens plus obligé de le faire, même si je reste frustré par certains manques. Et quand je vois mes builds ScalaJS saturer mes 4GB de mémoire (oui ok on est en 2016…mais quand même), quand Webpack et Babel tournent comme des fleurs, ça me fait vraiment mal au coeur.
Et si j’installe drone c’est pas pour me taper la maintenance de drone ET de gitlab
Perso' Gitlab(-ci) j'ai fini par laisser tomber. Je trouve le combo Gogs + Drone beaucoup plus léger et simple à maintenir. Tout ça sur du Docker, c'est juste parfait =).
Entièrement d'accord, mais ce serait bien de justement tirer les choses vers le haut plutôt que vers le bas. Vouloir proposer un écosystème cohérent, c'est bien. Bricoler et forker à sa sauce, c'est la pire méthode pour y parvenir dans la mesure où ça impacte directement la stabilité de l'ensemble.
Le couplage est une problématique inhérente au développement. Le but étant de le minimiser. Je ne dis pas que Gnome fait dans la perfection de ce côté là, je dis que Gnome (et KDE, et XFCE, et beaucoup d'autres) fait (font) mieux que Pantheon et Unity.
Y'a quand même un monde entre un environnement de bureau utilisable partout, et un environnement de bureau qui, de l'aveu même des devs, risque de poser des soucis en dehors de leur écosystème. Là je parle pour Pantheon, mais Unity, c'est loin d'être la panacée en dehors d'Ubuntu (en tout cas sur Arch', c'est catastrophique).
[…] Nous ne décourageons pas les utilisateurs d'installer Pantheon sur leur OS favori, nous ne le soutenons simplement pas officiellement et nous ne serons pas surpris s’ils rencontrent quelques soucis.
Ouaip. Autrement dit, "notre environnement de bureau est fortement couplé à notre distribution, ne l'installez pas ailleurs".
Bizarrement, cette maladie touche également Unity. Faut' croire que quand un projet est mal vu par une bonne partie de la communauté, y'a parfois des raisons techniques derrière.
Pour le reste, je ne comprends toujours pas l'intérêt de la distribution. Développer une base lourde, par dessus une base lourde, c'est pas un peu prendre le risque que tout s'écroule ? Pourquoi ne pas "juste" proposer un environnement de bureau, quitte à y greffer quelques softs forkés et adaptés ?
Je suis bien d'accord avec toi sur Sublime. Il a lancé la "mode" de l'éditeur léger, graphique (par opposition à console), et avec plein de commandes au clavier ! Mais je n'ai jamais réellement compris pourquoi Sublime tentait de relancer une autre mode un peu moins "clean" : celle du shareware.
LightTable je m'en suis servi pendant un temps. Jusqu'à il y a quelques mois j'avais la désagréable impression que le projet était en train de mourir…visiblement ils partent plutôt sur un gros refactoring à base d'Atom-shell aka Electron à la place de Node webkit.
Brackets, les features sont assez poussées en ce qui concerne l'intégration d'un design en HTML / CSS (d'ailleurs l'éditeur à été pensé pour ça à la base). Pour le reste, je le trouve en dessous d'Atom, mais je ne m'en suis pas assez servi sur la durée pour donner un avis pleinement objectif.
Zed et Lime, jamais utilisés (tout au plus lancés et testés pendant cinq minutes). Mais j'ai entendu beaucoup de bien sur Zed.
Pour moi, c'est effectivement une bizarrerie liée à la stack. A la limite tu peux essayer d'autres applications basées sur Electron et voir ce que ça donne.
Je comprends mal les commentaires critiquant la lenteur présumée d'Atom…je m'en sers tous les jours (je ne développe plus qu'avec ça en fait) sur un i3, et j'ai pas tous ces problèmes =/. Je trouve que ça marche même très bien.
Perso' j'arrive tout droit des IDE "old-gen" type Eclipse, Netbeans, Idea, et tous les autres, ce qui peut expliquer en partie mon ressenti. C'est sûr que ça reste plus lent que Vi(m) ou Emacs, mais dans mon utilisation au quotidien, cette "lenteur" n'a jamais été au point de pénaliser ma productivité.
Effectivement, j'aurais pu essayer directement la commande, ça aurait épargné la double idée inutile .
Pour le YAML, sans rajouter de dépendance, je pense que ça peut se faire à grands coups de grep / sed. Mais évidemment, c'est moche. Je proposais ça surtout dans l'optique d'un utilisateur qui écrirait le fichier lui-même. Avec le gws init, c'est carrément pas indispensable de toute façon :).
Je connaissais pas myrepos. Ca a l'air de supporter pas mal de choses, mais actuellement j'ai pas le temps de comparer.
Idées en vrac pour plus tard (j'ai pas creusé le README, c'est peut être déjà possible) :
- Possibilité de générer le .projects.gws à partir d'un répertoire existant ? Du genre "gws init ." ?
- Possibilité de se passer carrément du .projects.gws si on souhaite uniquement utiliser le fast-forward ? En utilisant l'idée d'avant, celle-ci devient moins intéressante.
- Utilisation d'un format pré-existant (YAML ? JSON ? Autre ?) pour le .projects.gws ?
Même si ça reste du bash, le code a l'air relativement clean. Après je me mets à ta place : ça doit être sacrément pénible à maintenir.
Je jetterai un oeil, c'est quand même bizarre, je vois pas pourquoi ma banque bloquerait les transactions internet juste pour ce prestataire (remarque vu les organismes tentaculaires que c'est ça me surprendrait pas). Merci pour le relai et les infos en tout cas :).
Premier post sur LinuxFR pour moi . Mieux vaut tard que jamais…
C'est normal que le truc qui sert de système de paiement m'explose à la figure avec un beau "paiement refusé" ? Le numéro de CB vous le rentrez à la standard, sans espace, ni tirets, ni machins ésotériques ? Dans le doute j'ai essayé de payer en ligne un tout autre truc, et tout fonctionne…
[^] # Re: Rootme et du ssl ?
Posté par mikael.vallerie . En réponse à la dépêche Root-me: Rémunération des challenges de hacking et naissance de Root-me.pro. Évalué à 1.
Y'a des statistiques et des tests qui montrent que le(s) serveur(s) actuel(s) tomberaient avec "une couche TLS" et autant d'utilisateurs quotidiens ?
Si ce n'est pas le cas, il n'est jamais trop tard. Ca se met en place en production en moins d'une heure. Surtout avec les nouveaux venus du genre Let's Encrypt.
Je juge pas hein, mais perso', e-commerce ou non, password chiffré client-side ou non, c'est niet si pas de SSL. Trop de possibilités de MITM, sans grand intérêt certes, mais question de principe.
Sinon, l'idée est vraiment bonne. Reste à voir si ça prendra, étant donné que ce genre de concept est (me semble ?) de plus en plus courant.
# Ca va en s'améliorant
Posté par mikael.vallerie . En réponse à la dépêche Et si JavaScript allait droit dans le mur ?. Évalué à 5.
Pour le moment, le workaround qui me convient le plus est Immutable.js
Rarement eu ce genre de problème sur un projet sérieux…c'est sûr que celui qui clone n'importe quel skeleton fait à l'arrache sur github, et qui n'utilisera même pas 10 % de ce que propose ledit skeleton, il va se heurter à ce type de souci. Je suis partisan de minimiser au maximum l'aspect build d'un projet. Webpack + Babel + ESLint + WhateverTestTool, ça permet déjà de faire énormément de choses.
Tout dépend AMHA de la définition donnée à "complexité". Pour moi, ES6 est plus "simple" que jamais, et franchement, il était temps. Non pas que je n'aimais pas les surcouches type CoffeeScript, mais tendre vers l'unification, je trouve ça bien.
Il est pour moi clair que Javascript a accumulé une dette technique considérable. Ca s'améliore petit à petit…..vraiment petit à petit (un bon support ES6 natif sur les navigateurs, ce serait déjà pas mal). C'est le revers de la médaille. A côté de ça, on a un langage exécutable à peu près partout (une application mobile tout en Javascript c'est très faisable), et un écosystème assez exceptionnel (merci CommonJS, merci AMD).
A titre personnel, je préfère cent fois écrire du ScalaJS. Mais avec ES6, je ne me sens plus obligé de le faire, même si je reste frustré par certains manques. Et quand je vois mes builds ScalaJS saturer mes 4GB de mémoire (oui ok on est en 2016…mais quand même), quand Webpack et Babel tournent comme des fleurs, ça me fait vraiment mal au coeur.
[^] # Re: Sujet du commentaire
Posté par mikael.vallerie . En réponse à la dépêche Sortie de la version 0.4 de Drone. Évalué à 0.
Perso' Gitlab(-ci) j'ai fini par laisser tomber. Je trouve le combo Gogs + Drone beaucoup plus léger et simple à maintenir. Tout ça sur du Docker, c'est juste parfait =).
[^] # Re: C'est vendredi...ah non !
Posté par mikael.vallerie . En réponse à la dépêche Sortie d'elementary OS Freya. Évalué à 4.
Entièrement d'accord, mais ce serait bien de justement tirer les choses vers le haut plutôt que vers le bas. Vouloir proposer un écosystème cohérent, c'est bien. Bricoler et forker à sa sauce, c'est la pire méthode pour y parvenir dans la mesure où ça impacte directement la stabilité de l'ensemble.
Le couplage est une problématique inhérente au développement. Le but étant de le minimiser. Je ne dis pas que Gnome fait dans la perfection de ce côté là, je dis que Gnome (et KDE, et XFCE, et beaucoup d'autres) fait (font) mieux que Pantheon et Unity.
Y'a quand même un monde entre un environnement de bureau utilisable partout, et un environnement de bureau qui, de l'aveu même des devs, risque de poser des soucis en dehors de leur écosystème. Là je parle pour Pantheon, mais Unity, c'est loin d'être la panacée en dehors d'Ubuntu (en tout cas sur Arch', c'est catastrophique).
# C'est vendredi...ah non !
Posté par mikael.vallerie . En réponse à la dépêche Sortie d'elementary OS Freya. Évalué à 2.
Ouaip. Autrement dit, "notre environnement de bureau est fortement couplé à notre distribution, ne l'installez pas ailleurs".
Bizarrement, cette maladie touche également Unity. Faut' croire que quand un projet est mal vu par une bonne partie de la communauté, y'a parfois des raisons techniques derrière.
Pour le reste, je ne comprends toujours pas l'intérêt de la distribution. Développer une base lourde, par dessus une base lourde, c'est pas un peu prendre le risque que tout s'écroule ? Pourquoi ne pas "juste" proposer un environnement de bureau, quitte à y greffer quelques softs forkés et adaptés ?
# J'attends la suite avec impatience
Posté par mikael.vallerie . En réponse à la dépêche Du matériel libre qui a besoin de vous !. Évalué à 7.
J'en serai :). Une vraie solution libre est tout ce que j'attends pour me mettre à la domotique.
[^] # Re: D'autres éditeurs dans la lignée de sublime text
Posté par mikael.vallerie . En réponse à la dépêche Atom 1.0.x : l'autre éditeur de code. Évalué à 1.
Je suis bien d'accord avec toi sur Sublime. Il a lancé la "mode" de l'éditeur léger, graphique (par opposition à console), et avec plein de commandes au clavier ! Mais je n'ai jamais réellement compris pourquoi Sublime tentait de relancer une autre mode un peu moins "clean" : celle du shareware.
LightTable je m'en suis servi pendant un temps. Jusqu'à il y a quelques mois j'avais la désagréable impression que le projet était en train de mourir…visiblement ils partent plutôt sur un gros refactoring à base d'Atom-shell aka Electron à la place de Node webkit.
Brackets, les features sont assez poussées en ce qui concerne l'intégration d'un design en HTML / CSS (d'ailleurs l'éditeur à été pensé pour ça à la base). Pour le reste, je le trouve en dessous d'Atom, mais je ne m'en suis pas assez servi sur la durée pour donner un avis pleinement objectif.
Zed et Lime, jamais utilisés (tout au plus lancés et testés pendant cinq minutes). Mais j'ai entendu beaucoup de bien sur Zed.
[^] # Re: Lent ?
Posté par mikael.vallerie . En réponse à la dépêche Atom 1.0.x : l'autre éditeur de code. Évalué à 1.
Pour moi, c'est effectivement une bizarrerie liée à la stack. A la limite tu peux essayer d'autres applications basées sur Electron et voir ce que ça donne.
[^] # Re: Lent ?
Posté par mikael.vallerie . En réponse à la dépêche Atom 1.0.x : l'autre éditeur de code. Évalué à 3. Dernière modification le 18 août 2015 à 13:36.
Tu as un gros souci quelque part à mon avis :). Non sérieusement, c'est vraiment pas normal. Idea plus rapide qu'Atom…
Ceci étant c'est un problème récurrent pour plusieurs users d'Atom selon les issues github. Quel système ? Si *Linux, quel kernel ?
Le seul truc que l'éditeur met plusieurs secondes à effectuer chez moi, c'est son lancement.
# Lent ?
Posté par mikael.vallerie . En réponse à la dépêche Atom 1.0.x : l'autre éditeur de code. Évalué à 2.
Je comprends mal les commentaires critiquant la lenteur présumée d'Atom…je m'en sers tous les jours (je ne développe plus qu'avec ça en fait) sur un i3, et j'ai pas tous ces problèmes =/. Je trouve que ça marche même très bien.
Perso' j'arrive tout droit des IDE "old-gen" type Eclipse, Netbeans, Idea, et tous les autres, ce qui peut expliquer en partie mon ressenti. C'est sûr que ça reste plus lent que Vi(m) ou Emacs, mais dans mon utilisation au quotidien, cette "lenteur" n'a jamais été au point de pénaliser ma productivité.
[^] # Re: Cool =)
Posté par mikael.vallerie . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 0.
myrepos a l'air mort depuis un certain temps quand même…et pour YAML en bash, y'a bien ce truc immonde à base de sed / awk.
[^] # Re: Cool =)
Posté par mikael.vallerie . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1. Dernière modification le 27 juillet 2015 à 14:39.
Effectivement, j'aurais pu essayer directement la commande, ça aurait épargné la double idée inutile .
Pour le YAML, sans rajouter de dépendance, je pense que ça peut se faire à grands coups de grep / sed. Mais évidemment, c'est moche. Je proposais ça surtout dans l'optique d'un utilisateur qui écrirait le fichier lui-même. Avec le gws init, c'est carrément pas indispensable de toute façon :).
Je connaissais pas myrepos. Ca a l'air de supporter pas mal de choses, mais actuellement j'ai pas le temps de comparer.
# Cool =)
Posté par mikael.vallerie . En réponse à la dépêche Gérer son espace de travail git avec "gws". Évalué à 1. Dernière modification le 27 juillet 2015 à 12:40.
Bon outil qui va définitivement me servir.
Idées en vrac pour plus tard (j'ai pas creusé le README, c'est peut être déjà possible) :
- Possibilité de générer le .projects.gws à partir d'un répertoire existant ? Du genre "gws init ." ?
- Possibilité de se passer carrément du .projects.gws si on souhaite uniquement utiliser le fast-forward ? En utilisant l'idée d'avant, celle-ci devient moins intéressante.
- Utilisation d'un format pré-existant (YAML ? JSON ? Autre ?) pour le .projects.gws ?
Même si ça reste du bash, le code a l'air relativement clean. Après je me mets à ta place : ça doit être sacrément pénible à maintenir.
Question bonus : ça c'est quoi https://github.com/StreakyCobra/hws ?
PS : merci pour les paquets AUR ;).
# Top !
Posté par mikael.vallerie . En réponse à la dépêche Histoire Mondiale 2.0. Évalué à 4. Dernière modification le 09 juillet 2015 à 19:45.
Vraiment une super idée et un super projet ! Rien que pour ça et pour le boulot accompli, félicitations.
J'ai juste une remarque (je sais, j'aurais dû attendre minuit…mais bon :p) : pourquoi Swing ? Mais pourquoi ?!
(Faut' avouer que pour du client lourd sur la JVM, c'est pas la panacée niveau bibliothèques…)
[^] # Re: Paiement refusé...
Posté par mikael.vallerie . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 1.
Je jetterai un oeil, c'est quand même bizarre, je vois pas pourquoi ma banque bloquerait les transactions internet juste pour ce prestataire (remarque vu les organismes tentaculaires que c'est ça me surprendrait pas). Merci pour le relai et les infos en tout cas :).
# Paiement refusé...
Posté par mikael.vallerie . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 2.
Premier post sur LinuxFR pour moi . Mieux vaut tard que jamais…
C'est normal que le truc qui sert de système de paiement m'explose à la figure avec un beau "paiement refusé" ? Le numéro de CB vous le rentrez à la standard, sans espace, ni tirets, ni machins ésotériques ? Dans le doute j'ai essayé de payer en ligne un tout autre truc, et tout fonctionne…