De tout, de rien, des bookmarks, du bla‐bla #45

Posté par  (site web personnel) . Édité par Davy Defaud, baud123, Florent Zara, Nils Ratusznik, Anonyme, Bruno Michel et Nonolapéro. Modéré par Bruno Michel. Licence CC By‑SA.
Étiquettes :
38
7
nov.
2012
Technologie

Comme à sa presque habitude, voici un petit condensé de ma veille.
Il s’agit comme souvent (mes journaux et maintenant mes dépêches) essentiellement de bookmarks, très légèrement commentés. C’est plutôt orienté développement, essentiellement côté Web et JavaScript, mais j’essaie aussi de toujours avoir deux ou trois petites choses annexes. Le but étant juste de partager et d’initier discussions, débats, avis, touckevouvoulez.

Comme toujours, vous trouverez une liste des liens présentés en fin d’article, pour que les plus rapides puissent cliquer directement sans lire le bla‐bla qui traîne autour.

Bonne lecture !

Sommaire

Avant‐propos LinuxFr.org et espace collaboratif

Après quelques tâtonnements, puis quelques versions un peu plus sérieuses, voici la première réelle version collaborative. Cette dépêche, si elle est à mon initiative, a été rédigée dans l’espace de rédaction collaboratif de LinuxFr.org. J’ai ainsi pu bénéficier, comme pour la précédente, des corrections de certains relecteurs (comme baud123 ou xaccrocheur). Mais surtout, un certain nombre de liens ne proviennent pas initialement de moi, et c’est (presque) une première (presque, car Nyco m’avait déjà proposé quelques liens précédemment). Cette fois‐ci, ce sont NoNo, needs, xaccrocheur et Nonolapéro qui m’ont proposé certains des liens que vous trouverez dans la suite. Merci beaucoup à eux !

La première fois que j’ai utilisé cet espace collaboratif ce n’était en réalité pas pour le côté collaboratif, mais par facilité de saisie. J’utilisais précédemment soit un Google doc, soit un petit éditeur Markdown que j’avais posé sur un serveur, soit l’interface de mon blog pour rédiger mes news. Mais l’espace collaboratif est plus sympa. Et je pense que, finalement, je vais continuer à rédiger les prochaines à cet endroit. Ceux qui le souhaitent pourront donc aussi soumettre des liens comme ce fut le cas pour cette version. :)

Un peu de contenu

Développement

Si vous souhaitez créer un beau tableau de bord — dashboard —, un « panic board » ou autre, vous pouvez vous intéresser à dashing (lien envoyé par NoNo). Il s’agit d’un framework basé sur Sinatra, donc en Ruby, permettant de créer facilement des tableaux de bord à base de widgets que vous pouvez déplacer. Très pratique, par exemple dans un bureau de développement, pour avoir les dernières informations en provenance de Twitter, de l’intégration continue, etc. Vous trouverez sur le site deux démonstrations pour vous donner une idée du rendu. Personnellement, je le trouve vraiment sympa, ça a l’air plutôt simple à utiliser. Il ne me reste plus qu’à trouver le temps de le tester réellement. Si certains l’utilisent, n’hésitez surtout pas à en faire part dans les commentaires. ;)

Les programmeurs, les vrais, pas les petits malins qui font du Coffee ou du Python — Lisp est accepté d’office, si vous faites du Perl ou du Ruby c’est OK —, seront déjà au fait des résultats du plus beau concours de programmation C : le concours international de code C obfusqué (ioccc : International Obfuscated C Code Contest). Pour les autres, vous trouverez les résultats ici (lien envoyé par needs).

Go est souvent montré pour sa facilité à gérer la concurrence. Mais ce n’est pas le seul langage à le permettre, entre autres, Erlang est plutôt pas mal. Voici donc un petit article présentant un Hello World concurrentiel en Go, Erlang et C++. Sans vous indiquer le gagnant, vous trouverez facilement le grand perdant entre les trois…

Et pour rester dans l’illisibilité, voici une réflexion assez intéressante : avant, il y avait le goto, maintenant il y a les callbacks.

Que seraient ces actus sans du JavaScript ou Dart ? Rien, probablement. Voici donc, car elle a été remise à jour dernièrement, la page des synonymes Dart‐JavaScript. Si vous êtes nouveaux sur Dart, ou si vous voulez juste des infos supplémentaires et que vous connaissez un peu JavaScript, ça peut être un très bon début.

Misc

Si vous trouvez que votre terminal ou shell favori est trop limité, vous serez probablement intéressés par xiki (lien envoyé par needs). Décrire xiki est assez complexe. C’est en partie un shell, mais avec des fonctionnalités avancées, proches des interfaces graphiques. D’ailleurs, xiki ne s’utilise pas directement comme si l’on avait un xterm ou autre, mais à travers un éditeur de texte (Emacs en priorité). Finalement, le mieux est que vous alliez voir le site ou la vidéo.

Dans tous les cas, je suis toujours agréablement surpris par les quelques projets du genre qui existent (je pense notamment à TermKit, dont voici une présentation, également GateOne, surtout que vous pouvez le tester dans votre navigateur). Mais j’aimerais vraiment qu’il y ait d’autres projets du genre. Car il faut bien avouer que les terminaux n’ont que peu évolué ces derniers temps. Certes, ils sont pratiques sur de nombreux points (j’en ai moi‐même en général un certain nombre d’ouverts lorsque je bosse, entre l’exploration des répertoires, Git, Vagrant, SSH, etc.) et si des petites choses telles que oh my zsh et ses greffons sont plutôt intéressantes, je pense qu’on pourrait aller beaucoup plus loin, et surtout sortir de la contrainte purement textuelle. Ce que je veux dire par là c’est que si initialement la contrainte était qu’on était dans des consoles textes, ce n’est majoritairement plus le cas. Il serait donc intéressant de profiter de toutes les améliorations graphiques à notre disposition (ne serait‐ce que pour avoir une meilleure interactivité ou afficher des médias directement), tout en gardant le côté ligne de commande qui, lui, permet d’être régulièrement plus rapide et efficace que sur des logiciels graphiques à la souris. En fait, j’aimerais vraiment une fusion de la ligne de commande et de l’interface graphique.

Histoire de continuer un peu sur la ligne de commande, vous apprécierez probablement ls++. Il s’agit d’un petit outil, en Perl, permettant d’avoir un ls -l un peu plus sympa. Rien de transcendant, mais je trouve ça agréable. Pour ma part, je l’ai reconfiguré sur mon alias ll.

Et dans le genre utilitaire pratique (bien que je ne l’ai pas testé), vous pouvez vous intéresser à byobu (envoyé par xaccrocheur) . Il s’agit d’un wrapper au‐dessus de tmux/screen, afin d’en faciliter l’usage. Aux dires de ceux qui l’utilisent, ça semble vraiment sympa, à vous de nous le dire en commentaire ;).

Si vous cherchez des ressources (livres) gratuits (et si possible libres), The Hacker Shelf (lien par needs) devrait vous intéresser. Vous y trouverez un certain nombre de livres, comme, par exemple, The Art of Unix Programming de Eric S. Raymond.

Pour rester dans les livres (ou presque), voici un (long) article qui me semble plutôt sympa. Il y est question d’écrire des documentations de qualité. Je n’ai pas eu le temps de le lire, mais ça semble intéressant. Si certains l’ont déjà lu, je ne suis pas contre leur retour ;).

Histoire de changer un peu de thème, voici un article qui pose une question intrigante et intéressante : Pour réussir, faut‐il être intelligent ou motivé ? Je ne vais naturellement pas vous dévoiler la conclusion, ça gâcherait tout, mais l’article est plutôt intéressant. Et la question de la motivation est quelque chose de très important. Quand on est enfant, élève, évidemment, mais finalement même lorsqu’on est employé. Par exemple, motivation au salaire. Mais ce qui est intéressant est surtout l’effet, ou le non‐effet, de ces motivations (à rapprocher d’un TED talk que j’avais déjà envoyé dans les journaux).

Graphisme, design & co

Si vous vous intéressez au design des sites/applications Web, vous avez déjà entendu parler du responsive design. Voici un article sur le sujet, non pas d’un point de vue développeur, mais plutôt du côté designer, The Responsive Designer. L’article est plutôt bien réalisé (il s’agit en gros de diapos commentées) et assez clair. Pas grand chose de plus à dire dessus, allez le lire ;).

Si vous souhaitez visualiser (ou proposer à vos utilisateurs) des grosses images, vous serez peut‐être intéressés par HUGEpic (lien envoyé par Nonolapero). Il s’agit d’une application Web dédiée à cet usage. De mon point de vue, c’est assez similaire à ce qui se fait dans la cartographie (pour y avoir bossé quelques années). D’ailleurs, Google avait utilisé leur technologie dans Google Maps pour afficher des œuvres d’art.

Pour changer un peu et s’éloigner du développement, voici quelques paysages géométriques plutôt sympas. Ça change un peu, et je trouve ça plutôt bien fait. J’aime bien, entre autres, la référence aux Lego.

Liste des liens présentés

Développement

Misc

Graphisme, design & co

Aller plus loin

  • # Merci!

    Posté par  (site web personnel) . Évalué à 4.

    Merci à vous pour cette collection très intéressante comme d'habitude!
    A propose de HUGEpic, la technique est effectivement similaire aux technique de carto en ligne comme GMap ou OSM…
    D’ailleurs, ils utilisent leaflet ( http://leafletjs.com/ ) une lib JS développé pour des cartes … un concurrent de OpenLayers quoi.

    • [^] # Re: Merci!

      Posté par  (site web personnel) . Évalué à 3.

      Bien vu, je me disais bien que les boutons me faisaient penser à quelque chose…

      Pour ceux qui veulent faire des cartes, leaflet est vraiment une bonne lib.

  • # Hello World concurrentiel

    Posté par  . Évalué à 5.

    Pour compléter le comparatif, voici une version en Common Lisp

    • [^] # Re: Hello World concurrentiel

      Posté par  (site web personnel) . Évalué à 2.

      cool, merci
      Bon, j'ai toujours un peu de mal avec lisp, mais je trouve ça pas trop mal

    • [^] # Re: Hello World concurrentiel

      Posté par  (site web personnel) . Évalué à 7.

      Peso je trouve que la version en C++ est pas top. Déjà, il utilise un bibliothèque que je ne connais pas, alors qu'il y avait moyen de faire plus simple avec Qt par example et ses signals/slots.

      Mais je peux faire plus simple sans utilisé de bibliothèque tièrce. (J'ai du réimplémenter ma propre queue concurrencielle, mais c'est pas si compliqué.
      (Et je fait avec une queue plutôt qu'avec une sémaphore pour rester dans l'esprit du code original)

      #include <thread>
      #include <condition_variable>
      #include <queue>
      #include <iostream>
      
      template<typename T> class concurrent_queue {
          std::mutex mtx;
          std::condition_variable cond;
          std::queue<T> q;
      public:
          void push(T t) {
              std::unique_lock<std::mutex> lock(mtx);
              q.push(t);
              cond.notify_one();
          }
      
          T pop() {
              std::unique_lock<std::mutex> lock(mtx);
              cond.wait(lock, [&](){return !q.empty();});
              T t = q.front();
              q.pop();
              return t;
          }
      };
      
      int main() {
          enum Action { SayHello, SayWorld, Quit };
          concurrent_queue<Action> queue1, queue2;
      
          std::thread t1([&]() {
              for (int i = 0; i < 1000; ++i) {
                  std::cout << "Hello ";
                  queue1.push(SayWorld);
                  queue2.pop();
              }
              queue1.push(Quit);
          });
      
          std::thread t2([&]() {
              while(queue1.pop() != Quit) {
                  std::cout << " World\n";
                  queue2.push(SayHello);
              }
          });
      
          t1.join();
          t2.join();
      }
      
      

      Ça ressemble déjà un peu plus au Go. Qui dit mieux ?

      • [^] # Re: Hello World concurrentiel

        Posté par  (site web personnel) . Évalué à 10.

        #!/bin/bash
        set -eu
        
        fd="$(mktemp -d --tmpdir dlfp.XXXXXXXXXX)"
        mkfifo "$fd/1"
        mkfifo "$fd/2"
        
        function hello {
                seq 1 1000 | while read
                do
                        echo -n "Hello, "
                        echo "COIN!" > "$fd/1"
                        read < "$fd/2"
                done
                echo "PAN! PAN!" > "$fd/1"
        }
        
        function world {
                while read act < "$fd/1"
                do
                        [ "$act" = "PAN! PAN!" ] && return
                        echo "World!"
                        echo "\_o<" > "$fd/2"
                done
        }
        
        hello &
        world &
        wait
        
        

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Hello World concurrentiel

        Posté par  (site web personnel) . Évalué à 6.

        #!/usr/bin/perl -w
        use strict;
        use feature 'say';
        use IO::Handle;
        $|++;
        
        pipe HELLOR, HELLOW;
        pipe WORLDR, WORLDW;
        HELLOW->autoflush(1);
        WORLDW->autoflush(1);
        
        my $worldpid;
        if ($worldpid = fork) {
                for (1..1000) {
                        print "Hello, ";
                        say WORLDW "PING";
                        <HELLOR>;
                }
                say WORLDW "DIE";
        } else {
                while (<WORLDR>) {
                        last if /DIE/;
                        say "World!";
                        say HELLOW "PONG";
                }
        }
        
        

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Hello World concurrentiel

          Posté par  . Évalué à -1. Dernière modification le 09 novembre 2012 à 15:53.

          Ruby (http://ruby-doc.org/stdlib-1.8.7/libdoc/monitor/rdoc/monitor_rb.html) :

          require 'monitor.rb'
          
          buf = []
          buf.extend(MonitorMixin)
          empty_cond = buf.new_cond
          
          # consumer
          Thread.start do
            loop do
              buf.synchronize do
                empty_cond.wait_while { buf.empty? }
                print buf.shift
              end
            end
          end
          
          # producer
          while line = "hello world!\n"
            buf.synchronize do
              buf.push(line)
              empty_cond.signal
            end
          end
          
          

          Output:

          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!
          hello world!

          Usage CPU : mes deux cores à ~66% chacun dans htop :o
          (j'aurais peut-être atteint 100% avec deux processus à l'aide de IO.popen, par exemple ?)

          Bref, qui se dévoue pour Python ?

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Hello World concurrentiel

            Posté par  . Évalué à 2.

            Hum, le message "hello world" n'est pas séparée entre les deux threads, mauvaise réponse…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Hello World concurrentiel

        Posté par  . Évalué à 4.

        +1 pour la version C++/Mindroid pourrite.
        En C++11 avec zeromq, du coup, on fait exactement la même chose qu'en go, de la concurrence par passage de messages, le sucre syntaxique en moins (mais le sucre ça fait des caries)

        #include <iostream>
        #include <thread>
        #include <zmq.hpp>
        
        
        int main() {
          zmq::context_t ctx(1);
        
          std::thread t1([&] {
              zmq::socket_t sock1(ctx, ZMQ_REQ);
              sock1.connect("tcp://localhost:5555");
        
              for (int i = 0; i < 1000; ++i) {
                std::cout << "Hello ";
                zmq::message_t request(2);
                memcpy(static_cast<void *>(request.data()), "OK", 2);
                sock1.send(request);
                zmq::message_t reply;
                sock1.recv(&reply);
              }
              zmq::message_t request(2);
              memcpy(static_cast<void *>(request.data()), "KO", 2);
              sock1.send(request);
            });
        
          std::thread t2([&] {
              zmq::socket_t sock2(ctx, ZMQ_REP);
              sock2.bind("tcp://*:5555");
        
              while(true) {
                zmq::message_t request;
                sock2.recv(&request);
                std::string msg(static_cast<char*>(request.data()), request.size());
                if (msg == "KO")
                  break;
                std::cout << "World\n";
                zmq::message_t reply(2);
                sock2.send(reply);
              }
            });
        
          t1.join();
          t2.join();
        }
        
        
        • [^] # Re: Hello World concurrentiel

          Posté par  (site web personnel) . Évalué à 1.

          zeromq

          Hahaha.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Hello World concurrentiel

          Posté par  . Évalué à 2.

          Pourquoi ne pas utiliser un pipe à la place de zeromq ? Je comprends bien l'intérêt de zeromq pour des systèmes distribué mais là on reste sur une même machine. C'est probablement un peu plus lourd à écrire mais ça simplifie les dépendances et la distribution.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Hello World concurrentiel

            Posté par  . Évalué à 2.

            Pourquoi ne pas utiliser un pipe à la place de zeromq ?

            Je te concéde que pour cet exemple particulier, ça n'a pas tellement d'intérêt.
            Néanmoins l'avantage de ZeroMQ est de pouvoir passer à l'échelle plus tard, si tu as bien architecturé ton application que tes workers soient des threads, des process locaux ou distants (voire les mixer), tu as très peu de retouches à apporter à ton code.
            Sans compter que zeromq offre également des patterns de communications de plus haut-niveau (ie: pub-sub, distribution de jobs dans un pool de workers etc …).

      • [^] # Re: Hello World concurrentiel

        Posté par  . Évalué à 4.

        Une version go un peu simplifiée, sans la dépendance:

        package main
        
        func main() {
            sayHello := make(chan bool)
            sayWorld := make(chan bool)
            quitter := make(chan string)
        
            go func() {
                for i := 0; i < 4; i++ {
                    print("Hello ")
                    sayWorld <- true
                    <-sayHello
                }
                sayWorld <- false
            }()
        
            go func() {
                for reply := range sayWorld {   // We can range over chans.
                    if reply == false {
                        break
                    }
                    println("World!")
                    sayHello <- true
                }
                quitter <- "Done"
            }()
        
            println(<-quitter)
        }
        
        

        J'aime beaucoup ce langage que je trouve très facile à lire. Avec ce code, je comprend très vite que la seule chose que j'ai à comprendre, c'est le cheminement des signaux, et l'ordre des print. Sur cet exemple, c'est très facile, mais il n'y a rien qui dépasse, on peut difficilement faire plus minimaliste, ce qui fait que le code utile qui sera ajouté ne sera pas encombré.
        A essayer sur http://play.golang.org/p/QM5xdqKr2f

        • [^] # Re: Hello World concurrentiel

          Posté par  . Évalué à 3.

          On peut éliminer la nécessiter de tester la réponse en fermant le channel. Cela donne :

          package main
          
          func main() {
              sayHello := make(chan interface{})
              sayWorld := make(chan interface{})
              quitter := make(chan string)
          
              go func() {
                  for i := 0; i < 4; i++ {
                      print("Hello ")
                      sayWorld <- nil
                      <-sayHello
                  }
                  close(sayWorld)
              }()
          
              go func() {
                  for _ = range sayWorld {    // We can range over chans.
                      println("World!")
                      sayHello <- nil
                  }
                  quitter <- "Done"
              }()
          
              println(<-quitter)
          }
          
          

          http://play.golang.org/p/sBtjttvPRJ

          Je ne vois pas comment simplifier encore en éliminant le channel quitter. Il n'y a pas à ma connaissance de primitive pour attendre la fermeture d'un channel. On pourrait utiliser les WaitGroups mais c'est un peu plus lourd conceptuellement que le channel quitter, cf http://play.golang.org/p/Iv5TC6Bgrk .

  • # ioccc

    Posté par  . Évalué à 5.

    Ça vaut le détour de regarder les *.c proposés lors de l'iocc. Il y a quelques esprit torturés qui y participe car bien que difficilement compréhensible, le C ASCII-art c'est agréable à regarder.

  • # Autre article intéressant sur le "responsive design"

    Posté par  . Évalué à 1.

    Je suis tombé dessus aujourd'hui et j'ai trouvé les réflexions de l'auteur très pertinentes (même si je ne travaille pas dans le domaine du web). C'est long mais facile à lire:

    http://www.newfangled.com/contentmgr/showdetails.php/id/24561

  • # Concernant l'article de Jacob Kaplan-Moss

    Posté par  . Évalué à 1.

    Voici mon retour sur la lecture de ton lien (un peu long pour être posté en commentaire, et aussi en faire profiter les lecteurs, je l'ai mis en journal) :

    http://linuxfr.org/users/xunfr/journaux/jacob-kaplan-moss-ecrire-une-bonne-documentation

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: man byobu

      Posté par  (site web personnel) . Évalué à 2.

      Parce que ton man est plus court que celui-là ?

      Oui, c'est vrai pour la page. Mais je trouvais que la page n'apportait pas grand chose (comme quasiment toutes les pages launchpad) et je me suis dit que le man apportait plus d'infos.
      Mais merci pour le lien, j'aurais du mettre les deux tout simplement.

  • # Firefox Uniquity

    Posté par  . Évalué à 2.

    En fait, j'aimerais vraiment une fusion ligne de commande / interface graphique.

    Mozilla a ça avec le plugin Ubiquity pour Firefox: https://blog.mozilla.org/labs/2008/08/introducing-ubiquity/

    C'est assez sympa!

    • [^] # Re: Firefox Uniquity

      Posté par  (site web personnel) . Évalué à 1.

      hum, mouai, mais bon c'est limité au web ça, et on parle plutôt de le langage. c'est pas vraiment sur le même plan, je parle plutôt d'une fusion ligne de commande / navigateur / visualiseur de fichier (il suffit de voir les exemples présentés dans les liens, termkit étant le bon exemple)

  • # Pour réussir, faut-il être intelligent ou motivé ?

    Posté par  . Évalué à 2.

    Pour réussir, faut-il être intelligent ou motivé ?

    Paul Graham a écrit un essai très intéressant sur ce même sujet: http://www.paulgraham.com/determination.html

  • # Bonjour l'infobésite™

    Posté par  . Évalué à -3.

    Non sérieusement, ça fait beaucoup ces journaux bookmarks/veille techno. Certes, on peut vite apprécier certains sujets mais d'autres demandent du temps et vu les journaux intéressants qu'on trouve par ici, les précédents "points" de tes journaux boormaks et nos propres centres d'intérêts, on arrive plus à suivre.

    Évitons de tomber dans les travers des sites techniques/informations et toi de tourner au narcissisme. :)

    Donc, moins de sujets, espacés dans le temps et plus détaillés, ça c'est du bon!
    Après je pourrais les ignorer, mais ce n'est pas évident car on partage pas mal d'intérêts.

    • [^] # Re: Bonjour l'infobésite™

      Posté par  (site web personnel) . Évalué à 5.

      Merci pour ce commentaire (sincèrement).

      Initialement j'avais commencé par le message suivant :

      note préliminaire : si les journaux de seconde page existaient encore, je l'aurais classé comme tel. A vous de le lire comme tel.

      toi de tourner au narcissisme. :)

      en quoi je tourne au narcissisme ? (vrai question hein)

      En fait, pour expliquer un peu, ces "news" bookmarks remontent de mon côté à assez loin dans le temps (de fin 2010 à presque mi-2012). Mais elles étaient essentiellement réservée à mon entreprise. Elles sont ensuite devenue progressivement publiques (sur mon blog) puis en journal et maintenant en dépêche.

      Par contre, pour bien comprendre le "style", ça a toujours été bookmark. Avec le temps un peu de blabla s'est rajouté dessus, mais c'est vraiment un lien avec au mieux quelques phrases présentant mon avis sur le sujet. Ce n'est, volontairement, absolument pas objectif. Ce qui m'intéressait dans l'histoire est justement l'avis, le point de vue, l'envie, l'énervement, la joie, etc liée à un sujet, une histoire, etc.
      Si "narcissique" car c'est présenté de manière subjective alors c'est en effet réellement le but. C'est d'ailleurs exactement le cas lorsque je balance sur le métro de Paris au début d'un journal du genre. Ca n'a en effet aucun lien, et ça n'en a pas le but. Le but est juste de partager les liens que j'ai pu découvrir, à travers mon regard.
      Sinon, ce serait une bête liste de liens, totalement froids et impersonnels.

      Ensuite, pour le traitement "survol" des sujets : c'est justement le pure côté bookmark. D'ailleurs à la base c'était juste un condensé des bookmarks que j'ajoutais à mon navigateur. Et il faut le voir comme ça : je partage mes liens. Et cela n'empêche absolument pas d'en prendre certains et de les traiter en profondeur, à côté.
      C'est d'ailleurs ce que je fais personnellement, je reviens parfois sur certains liens (typiquement les conférences, articles de fond, etc) plusieurs semaines / mois plus tard car je traite réellement le sujet à ce moment. Mais si je ne les avaient pas gardé à ce moment, je ne l'aurais probablement pas retrouvé.

      Le problème de les espacer est que certaines informations ont une pertinence lorsqu'elle sort, pas 3 semaines plus tard. Et honnêtement, détailler des sujets ça prend beaucoup beaucoup de temps. La je m'en sort pas trop mal car je peux traiter les points un par un, séparément. Traiter un sujet de fond ne serait pas vraiment compatible avec le temps que je peux y allouer actuellement.

      • [^] # Re: Bonjour l'infobésite™

        Posté par  (site web personnel) . Évalué à 4.

        D'ailleurs à la base c'était juste un condensé des bookmarks que j'ajoutais à mon navigateur. […] je reviens parfois sur certains liens (typiquement les conférences, articles de fond, etc) plusieurs semaines / mois plus tard car je traite réellement le sujet à ce moment. Mais si je ne les avaient pas gardé à ce moment, je ne l'aurais probablement pas retrouvé

        J'en déduis que tu conserves un collection importante de bookmarks chez toi. Comment gères-tu cette masse d'informations ? Simplement avec le gestionnaire de bookmarks de ton navigateur ? Via un gestionnaire de favoris en ligne ? Autre solution ?

        • [^] # Re: Bonjour l'infobésite™

          Posté par  (site web personnel) . Évalué à 3.

          J'ai, grossièrement, 1600 liens (c'est pas encore énorme)

          Initialement c'était dans les marques pages de chrome, l'avantage étant surtout qu'ils sont synchronisés entre mes diverses machines et mon téléphone.
          Mais le classement par dossier a ses limites (très vite) et je ne pouvais y mettre des descriptions.

          Je suis donc passé à shaarli, sur mon serveur perso.
          Les avantages :

          • hébergé chez moi
          • hébergé chez moi (oui je trouve ça plutôt intéressant)
          • accessible de partout
          • tag (vraiment mieux pour classer)
          • description

          Par contre, c'est pas super ergonomique, et en fait je voulais aller plus loin. J'avais d'ailleurs commencé un projet en ce sens mais je ne l'ai pas fini (probablement parce que je l'avais commencé en php…). La grosse différence était surtout la possibilité d'écrire les descriptions en markdown (avec prévisu en temps réel). Le but était de pouvoir ensuite presque simplement sélectionner les liens intéressants et d'avoir automagiquement le contenu d'un journal du type de celui-ci.
          Mais j'aurais voulu aller encore plus loin (comme quoi dès qu'on oublie le release early, release often ça ne se passe jamais vraiment bien…) pour rajouter un vrai côté éditorial, ligne directrice. Et ça demande pas mal de choses, notamment pas seulement sélection des liens mais aussi réorganisation, catégories, etc.

          Bon, je m'égare un peu, mais voilà le principe en gros.

          • [^] # Re: Bonjour l'infobésite™

            Posté par  . Évalué à 2.

            Pourquoi ne pas passer par http://www.delicious.com/ ? Le coté auto hébergé ne me semble pas si primordial vu que tu cherche à partager. Si ce que tu cherche c'est à pouvoir sauvegarder l'ensemble je ne sais pas ce que propose delicius pour la libération des données.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Bonjour l'infobésite™

              Posté par  . Évalué à 2.

              Donc tu proposes l'utilisation d'un service centralisé propriétaire plutôt que sa solution libre, décentralisée et auto-hébergée, pour gagner en ergonomie ? Je ne dis pas que l'ergonomie n'est pas importante, mais vu la perte en liberté ça ressemble plutôt, tout compte fait, à une régression…

              • [^] # Re: Bonjour l'infobésite™

                Posté par  . Évalué à 4.

                Je demande en quoi la décentralisation est quelque chose de primordiale. Sinon tu peut aussi lui expliquer que poster sur linuxfr alors qu'avant il postait sur son blog (maintenant c'est devenu un lien vers la solution centralisée) c'est une sacrée régression vu l'aspect centralisé de linuxfr et la perte de liberté qu'il crée. Le coté libre est un problème mais la problématique importante réside plutôt dans la libération des données, c'est pour ça que j'en ai parlé.

                De plus je n'ai pas parlé d'ergonomie, je pensais plus à la visibilité.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Bonjour l'infobésite™

                  Posté par  . Évalué à 1.

                  J'insiste sur le fait que tu lui proposes un service propriétaire au lieu d'un service libre. Pour profiter de la décentralisation il faut utiliser des technologies qui permettent d'agréger l'audience (par exemple… des flux de syndication), donc il y a un intérêt à passer (ou se dupliquer) sur un service centralisé pour capter son public. Ce qui m'importe dans le message ci-dessus, c'est avant tout le côté libre ou propriétaire du service.

                  Mais pour qu'un service libre soit vraiment bon il faut qu'il supporte de la décentralisation avec agrégation. C'est bien d'avoir les sources de LinuxFR et de pouvoir les modifiers, mais tout l'aspect "modifier pour soi et diffuser les modifications aux autres" est difficile à mettre en place si tu ne peux pas proposer ta propre porte d'entrée sur le contenu de LinuxFR (donc du contenu agrégé). Ça reste utile pour proposer des améliorations à LinuxFR, et pour créer d'autres sites sur la même base de code, mais le top ce serait de pouvoir proposer aux gens qui le souhaitent d'accéder au même contenu en utilisant une autre version du code.

                  • [^] # Re: Bonjour l'infobésite™

                    Posté par  . Évalué à 2. Dernière modification le 08 novembre 2012 à 16:02.

                    […] c'est avant tout le côté libre ou propriétaire du service.

                    Un service ce n'est ni propriétaire ni libre, c'est un service. Ce dont tu parle c'est de la possibilité d'autohébergement et ça demande :

                    • d'avoir un code à exécuter (donc libre) ;
                    • d'avoir les données : c'est ce dont je parle avec la libération des données.

                    Comme tu le dis Linuxfr possède une seule de ses deux caractéristiques donc tu as précisément les même contraintes qu'un service propriétaire (c'est cool tu monte ton instance mais c'est tout). Si tu as les données tu peut en faire quelque chose, les données sont, à mon humble avis, plus importantes que le code. C'est souvent quelque chose de totalement ignoré par les logiciels libres (allez hop un -10), l'exemple de github et gitorius est flagrant. Il en résulte que des services propulsé par des logiciels libres n'offrent aucun avantages face à leurs concurrents.

                    Pour ce qui est de delicius, j'ai juste demandé s'il avait regardé de ce coté là et j'ai fais mention de la possibilité ou non de libérer les données.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Bonjour l'infobésite™

                      Posté par  . Évalué à 3.

                      Un service ce n'est ni propriétaire ni libre, c'est un service.

                      Je ne suis pas d'accord. Un service c'est du logiciel qui tourne, et ce logiciel peut être libre ou propriétaire. Quel est le différence aujourd'hui entre faire tourner du logiciel dans une page web (que l'exécution se fasse chez le client ou le serveur) et dans un "logiciel lourd" ? Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées. Quand j'utilise un service je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.

                      T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.

                      Le passage aux logiciels distribués ajoute une nouvelle problématique d'accès aux données qui était moins forte dans le logiciel tout-client. Et encore, les formats fermés posaient déjà ce problème; selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX). Je ne dis pas que c'est tout le temps faux, au contraire je pense que dans certaines situations tu as raison, mais il n'empêche que le code reste un point important et que dire "c'est un service donc on s'en fout" est un sacré aveuglement.

                      Donc avec le logiciel distribué il faut donc demander :

                      1. (comme avant) du logiciel libre
                      2. (comme avant) des données dans un format ouvert
                      3. (nouveau) l'accès facile à ses données pour (comme avant) éviter le verrouillage technologique
                      4. (nouveau) le fait que les vilains n'aient pas accès à nos données privées (soit on choisit où les stocker, soit elles sont chiffrées en local)

                      Le choix de la décentralisation me paraît plutôt être un choix technique indépendant, mais ça reste intéressant (du point de vue de la robustesse et pour faciliter l'ouverture), et qui est au passage une bonne façon de garantir un certain respect des points (2), (3) et (4).

                      • [^] # Re: Bonjour l'infobésite™

                        Posté par  . Évalué à 3.

                        Quand j'utilise un logiciel je veux pouvoir l'utiliser librement, étudier son fonctionnement et tester des versions modifiées.

                        Qu'est ce qui te garantie que le code qui s'exécute sur le serveur est le code que tu trouve dans le dépôt ?

                        T'es juste en train de dire "oui mais c'est pas grave si je pousse les gens à répondre à leur besoin en utilisant du code qu'on n'a pas le droit de voir, ça se passe à travers un navigateur donc ça va". Ce qui nous fera une belle jambe quand tout se fera à travers un navigateur.

                        Non je pousse à la rigueur à se poser la question des données, c'est elles qui ont de la valeur. C'est cette question qui prend le plus d'importance avec le SaaS.

                        selon ton principe de "données mieux que code" il vaut mieux utiliser un logiciel propriétaire qui comprend un format standard qu'un logiciel libre qui utilise son propre format maison (au hasard LaTeX).

                        Il faut que tu reste maitre de tes données ou que tu sache qu'elles libertés tu perd. Utiliser du code sur un serveur qui ne t'appartient pas c'est une perte de liberté que le mainteneur te dise que le code est sous licence libre ou pas.

                        Le choix de la décentralisation me paraît plutôt être un choix technique indépendant […]

                        On est d'accord, j'ai juste demandé s'il avait regardé cette option pour partager sa veille rien de plus.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Bonjour l'infobésite™

                  Posté par  (site web personnel) . Évalué à 3.

                  Je demande en quoi la décentralisation est quelque chose de primordiale

                  En fait ce n'est pas vraiment la décentralisation qui m'intéressait, mais juste le fait de l'avoir chez moi. Je n'ai pas envie, pour le coup, de dépendre d'un produit externe. Et ce choix était réalisé bien avant de publier sur linuxfr.

                  De plus je n'ai pas parlé d'ergonomie, je pensais plus à la visibilité.

                  Visibilité de quoi ?
                  Mes bookmarks ne sont pas publiques et personne n'en connait l'adresse. Et je ne tiens pas à ce que ça change. Je ne partage pas les bookmarks en tant que tels de toute façon.

                  Sinon tu peut aussi lui expliquer que poster sur linuxfr alors qu'avant il postait sur son blog

                  C'est vrai que les première fois je dupliquais le contenu. Je ne l'ai pas fait ces dernières, mais il est vrai que la licence me le permet. Donc je pense que je fais le refaire (même si ça n'a que peu d'intérêt à part le fait d'être chez moi, d'ailleurs quand je dis chez moi c'est hébergé derrière ma tv :) )

                  • [^] # Re: Bonjour l'infobésite™

                    Posté par  . Évalué à 2.

                    C'est vrai que les première fois je dupliquais le contenu. Je ne l'ai pas fait ces dernières, mais il est vrai que la licence me le permet. Donc je pense que je fais le refaire (même si ça n'a que peu d'intérêt à part le fait d'être chez moi, d'ailleurs quand je dis chez moi c'est hébergé derrière ma tv :) )

                    Ce n'était absolument pas une critique, tu le fais comme tu veux. Personnellement, je suis ton blog et linuxfr donc ça ne me change rien :)

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Bonjour l'infobésite™

                      Posté par  (site web personnel) . Évalué à 2.

                      T'inquiète, je ne l'avais pas pris comme une critique ;)
                      en fait j'ai surtout fait par facilité et rapidité pour cette fois

                      (je savais même pas que certains suivaient mon blog :) )

            • [^] # Re: Bonjour l'infobésite™

              Posté par  . Évalué à 1.

              Personnellement, j'ai longtemps utilisé http://www.delicious.com/ et je l'utilise encore un peu.

              J'ai un peu souffert après que Yahoo ait lâché le truc. Le site a été un peu chaotique pendant une période. L'abandon du plugin pour Firefox (peut-être, existe t'il de nouveau quelque chose de fonctionnel maintenant).

              Tu peux récupérer les bookmarks via un export et je crois qu'il existe des moulinettes pour remonter cela dans les bookmarks firefox et les bookmarks chrome.

              Par contre, j'avoue que shaarli me plaît pas mal et je pense que je vais bientôt m'y mettre car j'aime bien le côté auto-hébergé justement et le fait que je reste maître de ses données m'attire pas mal.
              Il est vrai que l'interface n'est pas parfaite (je contribue pas donc …) mais les qq essais que j'ai fait m'ont séduit.

              Par contre, j'avoue que justement je me poste souvent la question des bookmarks de "veille" que je mets dans delicious et des bookmarks de tous les jours que je mets dans mon navigateur via Firefox sync.

              Et vous faites comment pour gérer vos bookmarks de veille ?

              Merci.

              • [^] # Re: Bonjour l'infobésite™

                Posté par  . Évalué à 0.

                Par contre, j'avoue que shaarli me plaît pas mal et je pense que je vais bientôt m'y mettre car j'aime bien le côté auto-hébergé justement et le fait que je reste maître de ses données m'attire pas mal.
                Il est vrai que l'interface n'est pas parfaite (je contribue pas donc …) mais les qq essais que j'ai fait m'ont séduit.

                J'allais demander "Y a-t-il y a moyen de synchroniser de manière transparente avec une instance privée de Shaarli?"
                Et après une petite recherche dans les "addons", voilà: Shaarli sur Firefox

                À essayer.

                • [^] # Re: Bonjour l'infobésite™

                  Posté par  . Évalué à 1.

                  L'extension ne fait que remplacer le bookmarklet, pour l'avoir dans la barre de modules, mais il n'y a pas de synchro.

      • [^] # Re: Bonjour l'infobésite™

        Posté par  . Évalué à -1.

        en quoi je tourne au narcissisme ? (vrai question hein)

        J'aurais dû rajouter "malgré toi".
        Bien, sans te juger toi, ça fait un peu le gars content de lui, le gars toujours au fait, à la pointe de l'info et qui se sent obligé de le faire savoir. :)
        Sentiment complètement faux d'où le "malgré toi" ci-dessus.

        Cela étant dit, je ne critique pas ta démarche comme "mal", mais j'ai l'impression qu'au final, on n'y voit plus rien et qu'on ne fait qu'empiler les liens sans vraiment explorer la chose ou que ça serve tout simplement.
        Et là, comme ça devient collaboratif, tout le monde s'y met et c'est l'overdose.

        J'apprécie vraiment les sujets que tu partages car ils me correspondent assez souvent mais perso, cette orgie d'information devient difficile à supporter.
        Je ne tiens à influencer personne, il semble qu'il y ait pas mal de gens, ayant une meilleure tolérance que moi, qui apprécient et qui en redemandent.

        • [^] # Re: Bonjour l'infobésite™

          Posté par  . Évalué à 4.

          Je lis souvent ces brèves et je n'ai jamais eu ce sentiment de "personne qui veut montrer son savoir". Je pense que le texte envoyé par CrEv est neutre de ce point de vue-là, et que cette lecture psychologique est ajoutée de ton côté : sans vouloir faire de la psychologie à la con, je parierais que ça se comprendrait plutôt à partir de tes propres peurs que du contenu réel de ces dépêches.

          Si je peux fournir une explication sur la quantité de lien : l'idée est un peu que chacun va y piocher ce qui l'intéresse vraiment au lieu de se forcer à tout lire. L'auteur (ou les auteurs) li(sen)t tout car ça correspond exactement à ses/leurs centres d'intérêt. Pour toi c'est périphérique donc il faut s'investir moins. En ces temps où l'information est facilement accessible, il faut se forcer à filtrer et s'investir avec soin.

          • [^] # Re: Bonjour l'infobésite™

            Posté par  (site web personnel) . Évalué à 9.

            Je tiens à défendre cette dépêche et les suivantes.

            CrEv a l'immense avantage de savoir faire de sa veille technologique un texte agréable à lire, alors que la matière ne s'y prête pas facilement (des liens, encore des liens).

            Les veilles technologiques sont pertinentes sur linuxfr. Ça profite à tous. Je regrette pour ma part de ne pas lire de veilles technologiques sur d'autres thèmes que ceux qu'aborde CrEv.

  • # terminal amélioré

    Posté par  . Évalué à 3.

    Je te rejoins sur le point des terminaux améliorés, je pense aussi que l'on pourrait faire des trucs vraiment sympa (et il faudra donc que je teste ces trucs).

    J'ai notamment un truc qui me trotte dans la tête depuis pas mal de temps (et pas seulement des mois) et qui, en soit, semble faisable, encore faut-il le temps de commencer…
    En gros, une ligne de commande surmontée d'un explorateur de fichiers tout à fait classique, dont la particularité serait que lorsque l'on écrit un "modèle" de fichiers (genre *.cpp) le modèle de la ligne de commande ET les fichiers lui correspondant adoptent un signe distinctif. Et, tant qu'a faire, quand on sélectionne à partir de la vue graphique (quoiqu'un menu textuel, avec les couleurs termcap, ça serait aussi faisable) un modèle est saisi automatiquement sur la ligne de commande.

    Ca serait vraiment utile, mais à chaque fois que je m'y colle, je pense à de nouvelles fonctionnalités et je n'arrive pas à me concentrer sur une base qui fonctionne :S

    Accessoirement, il faudrait identifier réellement les points qui sont améliorables sur une ligne de commande… je crois que ce qui m'ennuie le plus, c'est de devoir toujours alterner ls ou l'auto-complétion (qui n'est malheureusement pas en couleur) et les cd quand je me souviens plus des fichiers présents. Il y a aussi les modèles pas toujours rapides à écrire alors que visuellement on pourrait aller plus vite (avec une interface dans le même style que celle de cgdb en somme), ou le fait qu'on ne puisse pas associer aisément un nom de fichier à une action (enfin, si, on peut, via xdg-open et un alias, mais ce serait plus confortable si il n'y avait pas besoin de taper de commande).

    Bref, il y a du boulot, mais il faut faire attention à ne pas tomber dans le bloatware comme les interfaces graphiques le font régulièrement.

  • # Précisions historiques nécessaires

    Posté par  (site web personnel) . Évalué à 3.

    Go est souvent montré pour sa facilité à gérer la concurrence. Mais ce n'est pas le seul langage à le permettre, entre autre Erlang est plutôt pas mal.

    J'imagine que tu n'as pas voulu mal faire, mais en lisant ça, on dirait que Go est révolutionnaire. Je tiens à préciser qu'Erlang existe depuis 1986, et Go depuis 2009 : on savait déjà faire de la concurrence proprement 23 ans avant Go, et on s'en est pas privé ! Alors qu'un partie des moules ici découvraient le Basic ou le C, il y a fort à parier qu'Erlang était déjà utilisé dans l'industrie justement parce qu'il facilite la vie des gens qui font de la concurrence, en réseau ou en téléphonie.

    • [^] # Re: Précisions historiques nécessaires

      Posté par  (site web personnel) . Évalué à 3.

      en lisant ça, on dirait que Go est révolutionnaire

      Ben non, on dirait que j'ai écris que Go est souvent montré pour sa facilité à gérer la concurrence.
      Ca ne veut absolument pas dire que c'est le seul, d'autant plus que je cite par exemple erlang (j'ai vraiment l'impression de paraphraser là…)

      Maintenant, si on ne peut plus décrire les points forts d'un langage sans être taxé de fanboy ça devient bien lourd quand même.
      En fait j'ai l'impression qu'à chaque fois qu'on sort un truc sur go (par exemple) il y a toute une bande d'aigris (c'est une remarque générale hein) qui viennent pleurer sur leurs langages qui font certaines choses du même genre depuis plus longtemps. Le problème, entre autre, c'est que ces langages sont en général beaucoup moins connus et beaucoup moins utilisés. Erlang, par exemple, a beau être là depuis bien plus longtemps il a quand même une "part de marché" faible (comparé à la majorité des langages classiques, avec syntaxe type c, ou même perl, ruby, python, etc)

      Faudrait ptetre arrêter de prendre la mouche comme ça.

      • [^] # Re: Précisions historiques nécessaires

        Posté par  (site web personnel) . Évalué à 1.

        Tout d'abord, ne dis pas "non". Le fait que tu ne considère pas une interprétation ne signifie pas qu'elle n'est pas visible par autrui : c'est bien parce que je trouvais la formulation suggestive que j'ai écrit mon commentaire.

        Je commente le fait que la manière dont Erlang était présentée était potentiellement trompeuse. C'est pas un problème de fanboy que je dénonce, mais d'ignorance. Parce qu'Erlang est moins connu et conçu pour la gestion de la concurrence, j'estime qu'il était nécessaire de préciser qu'il est efficace bien que beaucoup plus ancien. Et qu'il est utilisé par l'industrie depuis longtemps justement pour résoudre des problèmes de concurrence qu'on aurait été bien en peine de résoudre avec d'autres outils.

        Quant à Perl, Ruby ou Python, quelles que soient leurs parts de marché, si je devais me pencher sur un problème de concurrence et/ou distribution, je réfléchirais à deux fois avant de les choisir à la place Erlang, justement à cause de leur conception et objectifs. Et la syntaxe, puisque tu mentionnes la syntaxe C, n'a rien à voir avec le tralala : on pourrait très bien écrire de l'Erlang avec une syntaxe proche du C ; c'est la sémantique qui importe.

        • [^] # Re: Précisions historiques nécessaires

          Posté par  (site web personnel) . Évalué à 2.

          Je commente le fait que la manière dont Erlang était présentée était potentiellement trompeuse.

          Je n'ai toujours pas saisi en quoi ça pouvait être trompeur…

          mais d'ignorance

          De la part de qui ? De mon côté en tout cas je savais très bien avant cela qu'Erlang est doué pour ces problématiques depuis longtemps…

          Parce qu'Erlang est moins connu et conçu pour la gestion de la concurrence, j'estime qu'il était nécessaire de préciser qu'il est efficace bien que beaucoup plus ancien.

          Attends, je comprend pas bien.
          Parce que Erlang n'est pas bien connu j'aurais du en écrire une tartine pour le présenter ? Et pourquoi ?

          Si je reprend ce que j'ai écris :

          Go est souvent montré pour sa facilité à gérer la concurrence. Mais ce n’est pas le seul langage à le permettre, entre autres, Erlang est plutôt pas mal. Voici donc un petit article présentant un Hello World concurrentiel en Go, Erlang et C++. Sans vous indiquer le gagnant, vous trouverez facilement le grand perdant entre les trois…

          1. "Go est souvent montré pour sa facilité à gérer la concurrence" Ben, c'est le cas
          2. "Il est pas tout seul, entre autre Erlang est bien pour ça" Ça tombe bien j'introduis Erlang en disant qu'il est plutôt pas mal pour ça (ok j'aurais pu rajouter "puisqu'il a été conçu pour ça" mais ça ne change pas grand chose je trouve)
          3. Et si on les comparait sur un hello world ?
          4. C++ est le grand perdant, par contre je ne me prononce pas sur le gagnant (entre autre car je ne fais pas d'Erlang)

          Au final je n'ai toujours pas réellement saisi en quoi ça met excessivement Go sur un pied d'estale, surtout par rapport à Erlang. Oui j'ai choisi de prendre l'article par le côté Go car je le connais plus qu'Erlang. Mais il reste, je trouve, plutôt neutre et factuel. En tout cas si on oublie C++.

          • [^] # Re: Précisions historiques nécessaires

            Posté par  (site web personnel) . Évalué à 1.

            Je n'ai toujours pas saisi en quoi ça pouvait être trompeur…

            La mise en avant de Go (première partie de la phrase), suivi du "entre autres" et du "pas mal" qui, eux, ne mettent pas en avant Erlang, bien qu'ils le mentionnent, mais le placent plus en position de remplissage, me parait négligente à l'égard d'Erlang, surtout avec le tapage médiatique autour de Go depuis sa sortie.
            Je ne demande pas de faire une tartine sur Erlang, je trouve juste la formulation mal tournée.
            Si tu me dis "Le langage Machin (sorti en 2010) est connu pour sa rigueur. Mais c'est pas le seul, Ada, entre autres, est pas mal." j'ai l'impression que tu passes sous silence le fait que de très importantes industries, paradoxalement de niche, utilisent Ada et ne sont pas prêtes pas passer à Machin pour autant. Le lecteur a plus de chances à aller voir Machin qu'Ada, et de passer à côté de nombreuses années d'expertise accumulée dans le domaine du logiciel sûr/critique.

            mais d'ignorance
            De la part de qui ?

            Du lecteur, bien sûr.

            1, 2, 3, 4

            1/ oui
            2/ Le point débattu.
            3, 4/ Non concernés par mon commentaire.

            • [^] # Re: Précisions historiques nécessaires

              Posté par  (site web personnel) . Évalué à 2.

              3, 4/ Non concernés par mon commentaire.

              Justement.
              Si j'avais indiqué que Go était le gagnant je comprendrais. Mais en l'état je les mets à l'égalité en ne me prononçant pas.

              Sinon, je comprend là où tu veux en venir.
              Alors oui, évidemment, je passe pas mal de choses sous silence. Entre autre je ne décris absolument pas Erlang.

              A choisir j'aurais pu le formuler comme ceci :

              Go est souvent montré pour sa facilité à gérer la concurrence. Mais ce n’est pas le seul langage à le permettre, entre autre Erlang a été créé pour répondre à ce type de problème.

              (ou un truc du genre, c'est jeté à la vas-vite)

              Mais je ne serais pas allé plus loin que remplacer le "pas mal" par quelque chose d'un peu plus précis.

              Maintenant, si j'étais tombé sur un lien intéressant au sujet d'Erlang, j'en aurais probablement parlé et présenté d'avantage, comme je le fais pour pas mal de sujets. Mais ce ne fut pas le cas. Il faut bien voir que ce que je présente est une liste de lien, que je collecte dans mes flux, contacts, etc, en fonction de mes intérêts propres, et de manière subjective (surtout lors des choix).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.