Mais je l'ai très vite déconseillé (peut-être est-ce de l'intransigeance) en découvrant avec stupeur l'opt in de google analytics et sa lenteur par rapport aux autres éditeurs (à cause du javascript ?). Vous avez aussi remarqué comme c'est lent ?
C'est pour l'instant le point qui me bloque pour passer sur Atom. Si la vitesse n'est pas trop déconnante sur i5 récent, c'est une véritable catastrophe sur mon vieux i3. J'ai vu aussi des versions qui ne voulaient pas s'upgrader, des bugs GUI ici et la…
Même si certains plugins donnent vraiment envie, c'est pas aujourd'hui que je lâcherais ST3. Mais je teste Atom régulièrement pour voir.
De ce que j'ai pu lire à droite et à gauche, la puissance des Xeon est bien supérieure aux ARM et POWER (IBM) quand on est entre 1 et 8 cœurs. C'est seulement après que ces derniers se rattrapent, ce qui de nos jours n'est pas le plus commun (normal on sort de plusieurs décennies de conception mono-cœur).
Bref, à court terme, et de ce que j'ai compris, ARM est surtout un avantage pour les hébergeurs, pas encore pour les développeurs.
Mais qu'est-ce ? Il s'agit d'un nouvel IDE que Christian a initié et développé sur son « temps libre ». Il a pour ambition d'offrir un environnement de développement intégré pour GNOME. Il ne réinvente pas la roue mais s'appuie sur des outils comme Glade, Gitg, Nemiver, GtkSourceView, Devhelp ou autoconf/automake, qu'il intègre au sein d'une même interface en Gtk+3.
Qu'offre cet IDE que Vim, Neovim, Emacs, Sublime Text, Atom et j'en passe ne sait pas faire correctement ? Je reste sceptique sur le «Il ne réinvente pas la roue». Pour moi, on est en plein dedans, surtout que ce n'est pas les améliorations à développer qui manquent.
On n'est pas en démocratie, mais ce que l'on appelle «démocratie représentative», ce qui est bien différent. Le mot démocratie étant ici galvaudé pour faire croire que. Le fait d'avoir des représentants qui confisquent le pouvoir tout en faisant croire que c'est pour le bien du peuple est quelque chose de voulu et réfléchi (et bien plus malin qu'une monarchie), avec la révolution française et la prise de pouvoir des bourgeois au détriment des nobles.
Devops est avant une histoire de culture (organisationnelle & humaine) soupoudré de pratiques techniques, comme l'agilité (on peut le voir d'ailleurs comme une extension naturelle de ce dernier). Avoir un poste devops est aussi pertinent qu'un poste de «qualité logiciel», c'est avant tout un objectif qui doit être commun. On peut généralement mesurer la maturité d'une organisation à son rapport avec la mentalité devops :
je ne connais pas
j'en ai entendu parler, ca tombe bien j'ai un souci en prod (ben oui c'est là que les soucis apparaissent) que je n'arrive pas à regler.
j'ai des admins qui font du devops.
j'ai une équipe devops
…
Devops est autant dévoyé par des techos (qui parlent d'outillage de dev ou de prod) que par des managers pour te foutre une étape supplémentaire dans le flux (ie mettre «devops» au milieu au lieu de faire travailler dev et ops ensemble).
Le point positif du buzz devops est de faire prendre conscience à pas mal de monde de l'importance de prendre en compte le flux entier, du poste de dev jusqu'à la prod. Moi qui adore bosser sur les problématiques orga + technique, je suis fort étonné de ce changement culturel, surement du à la pression business (Internet à notamment pas mal changé la donne). Je vois même des banques s'y mettrent, c'est dire…
pkgsrc, c'est le système de paquets logiciels pour NetBSD, issu d'un fork en 1997 de celui de FreeBSD. Nos amis au drapeau orange étant adeptes de la portabilité, il est logique que leur système de paquets puisse fonctionner ailleurs et compte toujours sa vingtaine de plateformes compatibles, allant des systèmes BSD à Windows (grâce à Cygwin/Interix/Services For Unix) en passant par GNU/Linux, OS X et Solaris.
"Comme on n'aimait pas celui de Free, on a inventé un nouveau packaging." Maintenant, on a un standard de plus, que bien evidemment pas beaucoup de monde n'utilise. Je voudrais bien savoir combien de gens font exactement le même taff, c'est à dire de packager exactement les mêmes applis. La diversité à du bon, mais là.
Sachant qu'il existe des millions de dépôt Git et seulement quelques milliers de packages par distribution. Ce qui fait que j'utilise pip pour Python, Gem pour Ruby, etc, en plus du packaging natif. Fusionner les trucs sans «valeur ajoutée», ça serait quand même pas mal.
Initiative intéressante mais pour moi, acheter un portable (ordinateur principal) signifie 3 ans de garantie sur site. Je me vois mal envoyer l'ordi aux USA. S'ils trouvent des vendeurs en France, je pense que je prendrais.
Marrant cette remarque car quand un service ne se lance pas, la 1ere chose que je fais (si je ne vois rien de concret dans les logs) est de farfouiller dans les dizaines de lignes de shell pour sortir la ligne d'appel effective et de lancer moi même la commande pour avoir la sortie std / err : J'ai encore en mémoire un debug de lancement foireux de PostgreSQL, qui était un script shell qui appelle un script shell qui appelle un script Perl (simplicité Debian), ce dernier ayant un bug sur la transmission des options se trouvant dans le fichier de configuration.
Si je ne suis pas spécialement pro-Systemd, mais il a au moins le mérite de remettre sur la table des points douloureux que personne ne voulait régler. Que des gens veulent fonctionner à l'ancienne est compréhensible (pour plein de raisons, bonnes ou mauvaises), mais perso je ne peux plus voir en peinture cet amas de shell.
Ensuite pour avoir connu le Microsoft des années 90, je trouve qu'ils ont fait des progrès en allant de plus en plus vers le l'open source
Je crois surtout qu'ils n'ont plus le choix de rester seul dans leur coin, leurs technos ne guident plus du tout le monde IT : il y'a 15 ans, la moindre annonce de leur part faisait les titres, maintenant tout le monde s'en fout un peu. Pire, ils sont inexistant dans les technos Web et mobile : Silverlight / Windows Phone.
J’espère que pour Microsoft, ce n'est pas non plus une façon déguisée d'abandonner ses technos.
J'ai entendu ici et la (et j'aimerais bien une {con|in}firmation) que les équipes .Net sont en diminution.
Même constat pour D, et tu oublies les gros changements entre D v1 et D v2. J'ai vite laissé tomber.
Il y a Mozilla derrière (et Samsung pour Servo)
C'est pour moi le point qui m’effraie le plus au vue de la longue liste de managements piteux de Mozilla dans le passé (XUL, SpiderMonkey, etc). Mais le projet semble très autonome depuis le début ce qui est bon signe.
Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++" j'ai regardé les stats OpenHub de Go.
Go se focalise sur l'accessibilité, la maintenance du code et la concurrence en abaissant drastiquement les concepts à maîtriser. C'est un langage épuré, qui se veut utile dans 80% des cas en laissant volontairement tomber les 20% restant (chiffres pif-O-métrique). Il remplace NodeJS, Python, Ruby, Lua. L'atout de ce langage vient de la bonne imbrication de peu de concepts le rendant accessible et maintenable dans bien des cas (notamment quand tu as des dizaines de dev qui passent sur ton code de 200k SLOC sur 10 ans comme chez Google). Autre atout, sa simplicité sémantique permet le développement d'outils d'analyse de code (cf Vet, Lint, Oracle, Types en train d'être développés).
Rust se focalise sur la robustesse de code et la vitesse. Il intègre donc des concepts avancés le rendant bien moins accessible que Go, mais aussi plus intéressant dans des cas particuliers (bas niveau, embarqué, moteur de jeux, etc). Il remplace C/C++, Scala, Haskell, OCaml. Qui peut le plus peut le moins, un codeur Rust pourra donc utiliser son langage partout ou Go est possible.
L'objectif de Rust est donc bien plus ambitieux mais aussi bien plus difficile à atteindre. J'attends beaucoup de Rust pour cette raison : peut on en 2014 faire un langage «accessible» qui produit du code robuste (ce que ni Haskell, ni Scala, ni OCaml n'ont réussi à faire par exemple) ? Je reste curieux de leur réussite (que j’espère) mais sans trop croire à un résultat exceptionnel.
Le point intéressant est que peut potentiellement, on aura dans 10 ans 2 langages de programmation majeurs à la place de 10 :).
Note : J'utilise le mot remplacer dans le sens "peut s'utiliser à la place de" (hors bien sur des questions de librairies).
Ce n'est pas une bonne métrique car tu as ton nom dans le fichier pour une contribution ponctuelle. Dans les faits, je ne vois pas 88 dev Google committer chaque mois (et encore moins 671 dev).
Go a très peu de dev venant de Google (bien moins que Dart par exemple). L'augmentation récente de contributeurs Google vient (je pense) de l'utilisation de plus en plus importante de Go en interne.
Il y a plusieurs choses qui freinent encore l'expansion d'OCaml: cette absence de vraie bibliothèque standard
Si je ne dis pas de bêtise, il me semble que c'est la même histoire que le langage D : pas de librairie standard (je sais on dit bibliothèque mais j'ai horreur de ce terme) d’où 2 librairies principales d’où soucis pour créer des librairies tierces.
Inversement avec Python ou Go qui permet une progression rapide de écosystème. Non ?
Ce changement mineur de version n'est pas représentatif des évolutions présentes. Cette version inclut des changements dans la syntaxe du langage et des outils, pouvant casser la compatibilité avec les programmes existants.
Il change de syntaxe entre les versions mineures ? Et ben, que cela doit être pour les versions majeures :).
Si je ne dis pas de bêtise, les sites Coréens sont bourrés d'ActiveX qui obligent toutes la population à utiliser le couple IE / Windows. Je crois même qu'il existe une loi pour les sites marchands. C'est donc un gros pas en avant pour eux.
La fonctionnalité de blocage des malwares n'est elle pas en utilisant une API de Google ? Si tel est le cas, il serait bon de le mettre en avant (au lieu de faire croire que c'est une invention Mozilla).
# C'est intégré dans Python 3.5
Posté par Sébastien Douche . En réponse au journal MyPy 0.3 sort bien accompagné. Évalué à 1.
Python 3.5 possède le type hinting :
https://docs.python.org/3/whatsnew/3.5.html#whatsnew-pep-484
Le projet mypy est l'inspiration de cette fonctionnalité. D'ailleurs Guido a pas mal bossé avec Jukka Lehtosalo.
[^] # Re: Oui..., mais...
Posté par Sébastien Douche . En réponse à la dépêche Atom 1.0.x : l'autre éditeur de code. Évalué à 3.
C'est pour l'instant le point qui me bloque pour passer sur Atom. Si la vitesse n'est pas trop déconnante sur i5 récent, c'est une véritable catastrophe sur mon vieux i3. J'ai vu aussi des versions qui ne voulaient pas s'upgrader, des bugs GUI ici et la…
Même si certains plugins donnent vraiment envie, c'est pas aujourd'hui que je lâcherais ST3. Mais je teste Atom régulièrement pour voir.
# Différence de puissance entre ARM64 et Intel Xeon
Posté par Sébastien Douche . En réponse au journal Essai serveur ARM chez cloud.online.net. Évalué à 0.
De ce que j'ai pu lire à droite et à gauche, la puissance des Xeon est bien supérieure aux ARM et POWER (IBM) quand on est entre 1 et 8 cœurs. C'est seulement après que ces derniers se rattrapent, ce qui de nos jours n'est pas le plus commun (normal on sort de plusieurs décennies de conception mono-cœur).
Bref, à court terme, et de ce que j'ai compris, ARM est surtout un avantage pour les hébergeurs, pas encore pour les développeurs.
# Quel est l'interet de GNOME Builder ?
Posté par Sébastien Douche . En réponse à la dépêche GNOME 3.16 - nettoyage de printemps. Évalué à 5.
Qu'offre cet IDE que Vim, Neovim, Emacs, Sublime Text, Atom et j'en passe ne sait pas faire correctement ? Je reste sceptique sur le «Il ne réinvente pas la roue». Pour moi, on est en plein dedans, surtout que ce n'est pas les améliorations à développer qui manquent.
[^] # Re: Il y a des projets de lois mais aussi des lois déjà passées
Posté par Sébastien Douche . En réponse au journal Dark side of the law. Évalué à 10.
On n'est pas en démocratie, mais ce que l'on appelle «démocratie représentative», ce qui est bien différent. Le mot démocratie étant ici galvaudé pour faire croire que. Le fait d'avoir des représentants qui confisquent le pouvoir tout en faisant croire que c'est pour le bien du peuple est quelque chose de voulu et réfléchi (et bien plus malin qu'une monarchie), avec la révolution française et la prise de pouvoir des bourgeois au détriment des nobles.
# Systemd est prévu dans la 15.04
Posté par Sébastien Douche . En réponse au journal la prochaine ubuntu aura systemd. Évalué à 10.
La phrase laisse penser que systemd n'était pas prévu, ce qui est incorrect. Et pour info, ils testent déjà le passage à GCC 5.0.
PS : L’utilisation de «malgré que» est fréquente, bien que jugé incorrect par l’Académie française.
[^] # Re: Assis / debout
Posté par Sébastien Douche . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 10.
Le problème est plutot la position immobile, le corps humain a besoin de bouger regulierement.
[^] # Re: devops = buzzword
Posté par Sébastien Douche . En réponse à la dépêche Outscale et Openska lancent leur programme de formation Devops. Évalué à 6.
Devops est avant une histoire de culture (organisationnelle & humaine) soupoudré de pratiques techniques, comme l'agilité (on peut le voir d'ailleurs comme une extension naturelle de ce dernier). Avoir un poste devops est aussi pertinent qu'un poste de «qualité logiciel», c'est avant tout un objectif qui doit être commun. On peut généralement mesurer la maturité d'une organisation à son rapport avec la mentalité devops :
Devops est autant dévoyé par des techos (qui parlent d'outillage de dev ou de prod) que par des managers pour te foutre une étape supplémentaire dans le flux (ie mettre «devops» au milieu au lieu de faire travailler dev et ops ensemble).
Le point positif du buzz devops est de faire prendre conscience à pas mal de monde de l'importance de prendre en compte le flux entier, du poste de dev jusqu'à la prod. Moi qui adore bosser sur les problématiques orga + technique, je suis fort étonné de ce changement culturel, surement du à la pression business (Internet à notamment pas mal changé la donne). Je vois même des banques s'y mettrent, c'est dire…
[^] # Re: Et un standard de plus
Posté par Sébastien Douche . En réponse à la dépêche pkgsrc 2014Q4 est disponible. Évalué à -1.
Certes mais avoir le même outil donne plus de chance d'y arriver.
# Et un standard de plus
Posté par Sébastien Douche . En réponse à la dépêche pkgsrc 2014Q4 est disponible. Évalué à -1.
"Comme on n'aimait pas celui de Free, on a inventé un nouveau packaging." Maintenant, on a un standard de plus, que bien evidemment pas beaucoup de monde n'utilise. Je voudrais bien savoir combien de gens font exactement le même taff, c'est à dire de packager exactement les mêmes applis. La diversité à du bon, mais là.
Sachant qu'il existe des millions de dépôt Git et seulement quelques milliers de packages par distribution. Ce qui fait que j'utilise pip pour Python, Gem pour Ruby, etc, en plus du packaging natif. Fusionner les trucs sans «valeur ajoutée», ça serait quand même pas mal.
--
Seb, qui rêve parfois.
# SAV
Posté par Sébastien Douche . En réponse au journal Une campagne de Crowdfunding promet un portable utilisable avec du 100% libre. Évalué à 5.
Initiative intéressante mais pour moi, acheter un portable (ordinateur principal) signifie 3 ans de garantie sur site. Je me vois mal envoyer l'ordi aux USA. S'ils trouvent des vendeurs en France, je pense que je prendrais.
# Pas que Git
Posté par Sébastien Douche . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 10.
Faille trouvée par le créateur de Mercurial, Matt Mackall. Cela touche aussi Hg puisque le principe est identique.
[^] # Re: Hmm
Posté par Sébastien Douche . En réponse à la dépêche Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 10.
Marrant cette remarque car quand un service ne se lance pas, la 1ere chose que je fais (si je ne vois rien de concret dans les logs) est de farfouiller dans les dizaines de lignes de shell pour sortir la ligne d'appel effective et de lancer moi même la commande pour avoir la sortie std / err : J'ai encore en mémoire un debug de lancement foireux de PostgreSQL, qui était un script shell qui appelle un script shell qui appelle un script Perl (simplicité Debian), ce dernier ayant un bug sur la transmission des options se trouvant dans le fichier de configuration.
Si je ne suis pas spécialement pro-Systemd, mais il a au moins le mérite de remettre sur la table des points douloureux que personne ne voulait régler. Que des gens veulent fonctionner à l'ancienne est compréhensible (pour plein de raisons, bonnes ou mauvaises), mais perso je ne peux plus voir en peinture cet amas de shell.
[^] # Re: Une bonne nouvelle
Posté par Sébastien Douche . En réponse à la dépêche Microsoft libère le cœur de .NET et cible GNU/Linux. Évalué à 10.
Je crois surtout qu'ils n'ont plus le choix de rester seul dans leur coin, leurs technos ne guident plus du tout le monde IT : il y'a 15 ans, la moindre annonce de leur part faisait les titres, maintenant tout le monde s'en fout un peu. Pire, ils sont inexistant dans les technos Web et mobile : Silverlight / Windows Phone.
J'ai entendu ici et la (et j'aimerais bien une {con|in}firmation) que les équipes .Net sont en diminution.
[^] # Re: Rust vs Go
Posté par Sébastien Douche . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
Même constat pour D, et tu oublies les gros changements entre D v1 et D v2. J'ai vite laissé tomber.
C'est pour moi le point qui m’effraie le plus au vue de la longue liste de managements piteux de Mozilla dans le passé (XUL, SpiderMonkey, etc). Mais le projet semble très autonome depuis le début ce qui est bon signe.
[^] # Re: Rust vs Go
Posté par Sébastien Douche . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 6.
Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++" j'ai regardé les stats OpenHub de Go.
Go se focalise sur l'accessibilité, la maintenance du code et la concurrence en abaissant drastiquement les concepts à maîtriser. C'est un langage épuré, qui se veut utile dans 80% des cas en laissant volontairement tomber les 20% restant (chiffres pif-O-métrique). Il remplace NodeJS, Python, Ruby, Lua. L'atout de ce langage vient de la bonne imbrication de peu de concepts le rendant accessible et maintenable dans bien des cas (notamment quand tu as des dizaines de dev qui passent sur ton code de 200k SLOC sur 10 ans comme chez Google). Autre atout, sa simplicité sémantique permet le développement d'outils d'analyse de code (cf Vet, Lint, Oracle, Types en train d'être développés).
Rust se focalise sur la robustesse de code et la vitesse. Il intègre donc des concepts avancés le rendant bien moins accessible que Go, mais aussi plus intéressant dans des cas particuliers (bas niveau, embarqué, moteur de jeux, etc). Il remplace C/C++, Scala, Haskell, OCaml. Qui peut le plus peut le moins, un codeur Rust pourra donc utiliser son langage partout ou Go est possible.
L'objectif de Rust est donc bien plus ambitieux mais aussi bien plus difficile à atteindre. J'attends beaucoup de Rust pour cette raison : peut on en 2014 faire un langage «accessible» qui produit du code robuste (ce que ni Haskell, ni Scala, ni OCaml n'ont réussi à faire par exemple) ? Je reste curieux de leur réussite (que j’espère) mais sans trop croire à un résultat exceptionnel.
Le point intéressant est que peut potentiellement, on aura dans 10 ans 2 langages de programmation majeurs à la place de 10 :).
Note : J'utilise le mot remplacer dans le sens "peut s'utiliser à la place de" (hors bien sur des questions de librairies).
[^] # Re: Rust vs Go
Posté par Sébastien Douche . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 3.
Ce n'est pas une bonne métrique car tu as ton nom dans le fichier pour une contribution ponctuelle. Dans les faits, je ne vois pas 88 dev Google committer chaque mois (et encore moins 671 dev).
Go a très peu de dev venant de Google (bien moins que Dart par exemple). L'augmentation récente de contributeurs Google vient (je pense) de l'utilisation de plus en plus importante de Go en interne.
# Bon timing :)
Posté par Sébastien Douche . En réponse à la dépêche Sortie de 0 A.D. Alpha 17 Quercus. Évalué à 7.
Ah ben moi qui voulait me lancer dans le jeu, voila un dépêche qui tombe à pic. Merci bien pour le travail.
[^] # Re: Tant de changements pour une version mineure
Posté par Sébastien Douche . En réponse à la dépêche OCaml 4.02. Évalué à 2.
Il y a plusieurs choses qui freinent encore l'expansion d'OCaml: cette absence de vraie bibliothèque standard
Si je ne dis pas de bêtise, il me semble que c'est la même histoire que le langage D : pas de librairie standard (je sais on dit bibliothèque mais j'ai horreur de ce terme) d’où 2 librairies principales d’où soucis pour créer des librairies tierces.
Inversement avec Python ou Go qui permet une progression rapide de écosystème. Non ?
# Tant de changements pour une version mineure
Posté par Sébastien Douche . En réponse à la dépêche OCaml 4.02. Évalué à 8.
Ce changement mineur de version n'est pas représentatif des évolutions présentes. Cette version inclut des changements dans la syntaxe du langage et des outils, pouvant casser la compatibilité avec les programmes existants.
Il change de syntaxe entre les versions mineures ? Et ben, que cela doit être pour les versions majeures :).
# Active X obligatoire
Posté par Sébastien Douche . En réponse à la dépêche Turin et la Corée du Sud passent au libre. Évalué à 10.
Si je ne dis pas de bêtise, les sites Coréens sont bourrés d'ActiveX qui obligent toutes la population à utiliser le couple IE / Windows. Je crois même qu'il existe une loi pour les sites marchands. C'est donc un gros pas en avant pour eux.
# Rendre à César ce qui...
Posté par Sébastien Douche . En réponse à la dépêche Firefox sur son 31. Évalué à 1.
La fonctionnalité de blocage des malwares n'est elle pas en utilisant une API de Google ? Si tel est le cas, il serait bon de le mettre en avant (au lieu de faire croire que c'est une invention Mozilla).
[^] # Re: Un peu de bike shedding: je n'aime pas leur syntaxe des format string
Posté par Sébastien Douche . En réponse à la dépêche Encore une couche de rouille avec Rust 0.11. Évalué à 1.
Ah ?! Moi c'est leur x::y::z que je ne peux pas voir en peinture :).
# Forum officiel Rust
Posté par Sébastien Douche . En réponse à la dépêche Encore une couche de rouille avec Rust 0.11. Évalué à 7.
En plus des différents lieux cités (mls, IRC…) il existe maintenant un forum officiel : discuss.rust-lang.org.
Personnellement j'aurais préféré une ml, je hais les forums (push vs pull).
[^] # Re: Rust vs Go
Posté par Sébastien Douche . En réponse à la dépêche Rust s’oxyde en version 0.10. Évalué à 10.
Cela étant dit, chapeau a l'auteur de prendre du temps pour ses news sur Rust. J'apprécie :).