De tout, de rien, des bookmarks, du bla bla #42

Posté par (page perso) . Édité par Davy Defaud, Nÿco, baud123, Christophe Guilloux, patrick_g, Bruno Michel et Florent Zara. Modéré par baud123. Licence CC by-sa
33
17
oct.
2012
Technologie

NdM : Nous (modérateurs) avons demandé à CrEv s’il souhaitait poster sa série en dépêches plutôt qu’en journaux, car elle nous plaît et elle aura plus de visibilité ainsi. Nous sommes tous preneurs de vos retours, veuillez commenter cette dépêche. D’autre part, l’étiquette « veille technologique » vous permet de retrouver les journaux précédents.

Pour cette première en dépêche, j’ai essayé de faire plutôt soft. Comme d’habitude (mes journaux), vous trouverez pas mal de choses côté développement, essentiellement côté Web et JS, mais aussi deux ou trois petites choses annexes.

Une liste de l’ensemble des liens présentés est accessible à la fin de l’article.

Bonne lecture !

Sommaire

Un peu de contenu

Développement

Vous avez toujours regardé Go, mais n’avez jamais franchi le pas ? Vous ne savez pas faire des choses toutes bêtes en Go ? Alors, Go by Example est fait pour vous. Il vous présente les bases à connaître au travers de petits exemples clairs et documentés.

Chaque semaine, je vois passer des nouvelles migrations vers Go. Ce que je trouve intéressant est que ce sont régulièrement des codes importants, et l’on y retrouve souvent les mêmes arguments : c’est simple, agréable à coder, ça fonctionne simplement bien. Cette fois‐ci ce sont les DNS de la réserve NTP qui viennent de migrer sous Go. Et les sources sont sur GitHub.

Ah oui, et évidemment c’est développé avec SublimeText et GoSublime. ;)

Je suis sûr que vous avez toujours rêvé de pouvoir écrire du code comme vous pensez. C’est désormais une réalité pour les développeurs Ruby (car de toute façon « il y a une gem pour ça ») avec fsck.

Pour illustrer, voici un petit exemple tout simple :

# all i want is to sum the goddamn elements
sum = 0
(1..10).each_fucking_element { |e| sum += e }

Alors, cool, non ? Bon, en fait, c’est pas méga compliqué, ça utilise surtout method_missing, qui va être appelé à chaque fois qu’on essaie d’exécuter… une méthode manquante. Sympa et totalement inutile, donc absolument indispensable !

Restons dans les langages intéressants. Tout d’abord avec The State of JavaScript. Il s’agit d’une présentation sur JavaScript assez intéressante. Ça parle entre autres d’ES 6 (EcmaScript 6). S’il y a plein de bonnes choses, je suis très perplexe quant à son adoption par l’ensemble des navigateurs. Et sans cette condition, ça ne servira pas à grand chose ; en fait, ça deviendra simplement un de plus parmi TypeScript, Dart

Toujours en JS, j’ai découvert melonJS. Il s’agit d’un framework JavaScript orienté jeux vidéo (par tuile). Plutôt sympa, ça donnerait presque envie de coder des jeux (mais bon, c’est pas trop mon truc les jeux…).

Et côté nouveautés langage, Rust vient de sortir la version 0.4. J’ai l’impression que par certains côtés ça s’oriente vers les mêmes solutions que, par exemple :

Classes are replaced with simpler structs

Après, il y a eu beaucoup de renommage, c’est assez marrant (mais doit être perturbant pour ceux qui ont écrit du code) :

  • ret became return and alt became match ;
  • import is now use; use is nowextern mod` ;
  • extern mod { ... } is now extern { ... } ;
  • use mod is the recommended way to import modules ;
  • pub and priv replace deprecated export lists.

Avez-vous déjà essayé Rust ? Un petit retour ?

Si vous utilisez AngularJS et SublimeText, vous serez probablement intéressés par deux extensions permettant d’ajouter le complètement automatique. Tout d’abord AngularJs.tmbundle, qui rajoute simplement quelques snippets. Mais surtout, Sublime-AngularJS-Coffee-Completions, qui rajoute pas mal de complètements, que ce soit en HTML ou en CoffeeScript.

Dans un autre registre, je viens de découvrir Codiad. Il s’agit d’un IDE (bon OK, un éditeur surtout) Web. Il est donc possible de le placer sur un serveur plutôt basique (seul PHP 5.3+ est requis, pas de base de données, entre autres) et pourra donc vous permettre d’éditer vos fichiers, directement depuis votre navigateur.

Même si ça peut être risqué (ne pas le laisser accessible surtout), je trouve que c’est intéressant. Il faut avouer que les éditeurs en ligne commencent à être de plus en plus performants et pratiques à utiliser (voir aussi, par exemple, The ACE Editor, l’éditeur de Cloud9 IDE). À noter que ces deux éditeurs sont libres.

Voici en revanche un nouveau concurrent dans les « forges », dans l’hébergement de dépôts de code source : PikaCode. C’est marrant comme la conception me fait penser à une bibliothèque qu’on rencontre souvent, et à un site très connu dans le domaine. ;) J’ai pas testé non plus, mais un point fort, je trouve, est d’héberger du Mercurial et du Git.

Misc

Évidemment, vous avez suivi l’histoire du gars qui monte très très haut, juste pour sauter dans le vide (bon en même temps ayant déjà sauté, de beaucoup moins haut, je comprends l’intérêt ;))… Voici un petit résumé en vidéo du saut.

Voici, comme souvent, une petite présentation agréable sur How do you build great software? chez GitHub. Pas grand chose à dire, juste que j’aime bien, que ce soit le fond ou la forme.

Liste des liens présentés

Développement

Misc

  • # Methode

    Posté par (page perso) . Évalué à  8 .

    Mais, comment tu fais pour trouver tous ces trucs de malade? T'es abonné aux top X de GitHub ou quoi?

    Sérieusement, j'ai 50 ou 60 RSS que je suis régulièrement, et je trouve même pas la moitié de ce que tu décris.

    • [^] # Re: Methode

      Posté par (page perso) . Évalué à  7 .

      Alors, comment dire… le pire c'est que c'est juste une "petite" news. Entre le moment où j'ai posté la dépêche et le moment où elle est sortie de modération j'ai du retrouvé encore 4 ou 5 liens intéressants (qui seront donc dans le prochain numéro)

      Après, comment je trouve tous ces liens ? Ben un mix de rss et de twitter. Lorsque j'étais vraiment actif dessus (en fait je le faisais pour mon taff à la base) j'avais entre 20 et 40 liens par semaine.

      Mais par contre non, pas abonné à github, juste en général ce qui me plait et souvent fonction de mon travail. Après, beaucoup de lecture.

      Ca pourrait peut-être être intéressant d'ailleurs que j'indique la provenance, pourquoi pas…

  • # précisions

    Posté par (page perso) . Évalué à  3 .

    Tout d'abord, merci :)

    Sinon, juste une petite coquille :

    D’autre part, l’étiquette « veille technologique » vous permet de retrouver les 41 journaux précédents.

    Je vous rassure, il n'y a pas 41 journaux précédents ;) le #41 ou #42 étant simplement la semaine courante.

    Sinon, comme dit dans le NdM n'hésitez surtout pas à donner votre ressenti, initialement j'étais plutôt journaux (de seconde page) à cause du côté marque-page, donc passer en dépêche était pas quelque chose d'initialement envisagé (mais qui peut être sympa)

  • # Rust

    Posté par . Évalué à  10 .

    Rust est en effet un langage très intéressant (à mon humble avis ce qui se fait de mieux en ce moment niveau collaboration entre l'industrie, la communauté du logiciel libre et la recherche). Les changements de la 0.4 sont variés et plus intéressants pour la plupart que des renommages de mots-clés. Quelques détails (essentiellement une traduction de mon message reddit à ce sujet):

    • comme évoqué dans la dépêche, les développeurs sont en train de s'éloigner de la présentation des langages objets typiques (les valeurs sont la combinaison d'un état privé et des opérations qu'elles gèrent) vers une présentation séparée, avec d'un côté des records pour les données, et un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits (mettons Printable) et que chaque type peut dire ensuite "je sais être Printable, voilà comment m'afficher"; ensuite le compilateur passe ces implémentations avec les valeurs de façon implicite, en utilisant les types des valeurs. Il n'est pas encore clair de savoir comment les programmeurs vont s'organiser, mais pour l'instant ça ressemble à un mouvement vers des types abstraits de données plutôt que des objets (selon le sens de l'article On Understanding Data Abstraction, Revisited de William Cook en 2009)

    • les développeurs et développeuses de Rust ont pas mal réfléchi aux question d'export de modules, de résolution des noms (à quoi fait référence tel nom ?), et bougent vers un système plus propre avec des séparations entre les différentes étapes de résolution

    • l'utilisation de types de méthodes où apparaît explicitement l'argument self, comme en Python, permet de mettre des quantificateurs de type sur cet argument pour indiquer comment la méthode se comporte avec l'état interne de l'objet : si elle le considère comme immutable, le passe en référence, etc. C'est une évolution intéressante.

    • les notions d'état mutable / non mutable / const, et de fonctions pure, continuent à évoluer en Rust. C'est un point de conception délicats des langages mainstream qui essaient de combiner effets de bords et bonnes propriétiés (D a eu le mêmes genre d'errances): on essaie de ne pas utiliser un système explicite trop compliqué comme peuvent le faire les chercheurs du domaine, mais d'avoir un truc pas totalement stupide non plus, et le compromis est difficile à trouver—à mon avis on n'a pas fini de voir des changements sur ce front là.

    Rust est un langage qui essaie d'apporter des idées nouvelles à la programmation système (… contrairement à Go qui fait un best-of des anciennes idées déjà bien connues, ce qui est très utile en soi mais quand même moins excitant), les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.

    • [^] # Re: Rust

      Posté par (page perso) . Évalué à  2 .

      Merci pour ce message instructif qui permet de mieux voir les choses.

      Par contre, je suis perplexe à la lecture de

      Rust est un langage qui essaie d'apporter des idées nouvelles à la programmation système (contrairement à Go qui fait un best-of des anciennes idées déjà bien connues, ce qui est très utile en soi mais quand même moins excitant)

      Ben déjà Go n'est finalement plus un langage orienté système (en tout cas pas que). Mais que penser par exemple des goroutines ?

      En fait je te trouve assez sévère, et j'ai pas forcément bien compris pourquoi…

      • [^] # Re: Rust

        Posté par . Évalué à  1 .

        Ben déjà Go n'est finalement plus un langage orienté système (en tout cas pas que).

        Je trouve tout de même que si. D'une part c'est la volonté initiale des développeurs de Go, d'autre part les projets dont j'entends parler en Go c'est :

        • un proxy d'image pour linuxfr
        • les DNS de NTP dont tu parle
        • la gestion du loadbalancing de youtube

        C'est pas un mal (bien au contraire), mais j'ai l'impression que ce langage amène les développeurs Python/Ruby à faire du développement système compilé.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Rust

          Posté par (page perso) . Évalué à  2 .

          Oui, c'est vrai qu'on voit pas mal de choses du genre.
          Par contre, de là à écrire par exemple un os en go, je sais pas (c'est finalement le summum de la prog système, non ?)

          Maintenant, j'ai l'impression que des bindings vers des toolkits graphique arrivent. Mais normal que ce soit plus lent.

          Il est vrai que la cible toute trouvée est quand même l'équivalent de pas mal de scripts ruby/pythons mais en compilé, comme tu le dis.
          Mais je ne vois pas en quoi, dans le langage, on ne pourrait pas faire beaucoup plus (contrairement au C par exemple où c'est quand même lourd de faire autre chose que de la programmation système)

          • [^] # Re: Rust

            Posté par . Évalué à  2 .

            Mais je ne vois pas en quoi, dans le langage, on ne pourrait pas faire beaucoup plus (contrairement au C par exemple où c'est quand même lourd de faire autre chose que de la programmation système)

            Je n'ai pas dis le contraire. Ce qui va faire la différence ce n'est pas le langage, mais ce que les gens vont en faire (qu'elles bibliothèques/framework vont arriver ? quels projets à forte visibilité vont y passer ou être construit avec ?). D'après ce que j'ai compris les créateurs de Go l'ont pensé pour les développeurs C/C++ et finalement c'est des développeurs python/ruby qui s'y mettent, mais je ne pense pas que ces derniers vont lâcher leur langage de prédiction pour autant. Ils utiliseront un langage dynamique pour tout ce qui est web et interface utilisateur et utiliseront go pour faire du système.

            Mais ce n'est là que mon avis « nostradamusien » et « pifometrique » (reconnu « pif le moins fiable » par meteo France 3 années de suite).

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Rust

        Posté par . Évalué à  3 .

        Et côté nouveautés langage, Rust vient de sortir la version 0.4. J’ai l’impression que par certains côtés ça s’oriente vers les mêmes solutions que, par exemple :

        Je pense qu'il manque un mot dans la dépêche (je présume que c'est « Go »).

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: Rust

        Posté par . Évalué à  1 .

        Les goroutines, c'est pour gérer des problèmes de concurrence et de parallélisme gérés à bas niveau traditionnellement par des mutex, sémaphores et autres qu'on trouve à la pelle dans le noyau Linux par exemple. C'est des problèmes qu'on retrouve énormément dans la programmation système.

        • [^] # Re: Rust

          Posté par . Évalué à  3 .

          Hum je suis pas sûr que les goroutines te dispensent d'utiliser des primitives de synchronisation, sauf dans les cas simples. Si tu veux ordonner l'accès à une ressource partagée (par exemple un cache), il faut bien un mécanisme de synchronisation (fût-il caché au sein d'une file par exemple).

      • [^] # Re: Rust

        Posté par . Évalué à  6 .

        Les goroutines n'ont rien de nouveau dans le sens où elles étaient déjà présentes sous des noms un peu différents dans toute la famille de langages de Rob Pike basé sur le formalisme CSP de Hoare (en gros, avec des canaux; cf. ici pour un historique). Newsqueak (qui a été développé en gros entre 1985 et 1990) avait un mot clé begin qui faisait comme go aujourd'hui, et ces fonctionnalités ont été repris par les langages Alef puis Limbo utilisés sur les systèmes basés sur Plan9. Le fait que ces langages aient bénéficié de moins de publicité que Go ne fait pas des goroutines une idée nouvelle : c'est quelque chose de bien connu des concepteurs de Go qui ont repris dans ce nouveau langage une idée qui marche bien. C'est bien ce mode "best-of" dont je parle, et je ne critique pas forcément, c'est utile d'avoir des langages qui consolident les acquis des développements précédents.

        Pour les traitements de la concurrence, j'apprécie personnellement beaucoup ce qui se fait dans le langage Oz/Mozart sorti en 1991, où le mécanisme de communication entre fils concurrents est une unification à la Prolog. Je trouve aussi intéressant ce qui se faisait sur le Join calculus (1995-2000), où on utilise une communication par canaux avec des conditions de réception sur plusieurs canaux simultanés (si machin, truc et bidule ont reçu des données et que l'entrée de bidule est de la forme chose), qui est une primitive expressive et assez intéressante.

    • [^] # Re: Rust

      Posté par . Évalué à  2 .

      […] les concepteurs n'ont pas peur d'expérimenter et de faire encore longtemps des changements fondamentaux. Ça veut dire qu'il ne faut pas vouloir l'utiliser pour des projets sérieux à maintenir sur le long terme aujourd'hui, mais plutôt le voir comme un véhicule en déplacement.

      C'est ce qui fait qu'il est si bas dans ma liste des langages à tester. Je comprends bien leur volonté mais ça a tendance à m'exaspérer de voir de gros changements à prendre en compte dans le code.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Rust

      Posté par . Évalué à  4 .

      un système de "traits", qui correspondent en fait assez exactement aux type classes de Haskell, pour transporter les implémentation. L'idée est qu'on définit des interfaces/traits

      Euh, tu peux préciser?
      Si j'en reviens à la base(C++) de l'héritage multiple, le problème principal est l'héritage en diamant quand les super-classes ont des variables, donc la règle de codage de C++ est de ne pas utiliser de variable dans les classes utilisée pour l'héritage multiple, en Java ils ont "résolu" le problème en faisant des interfaces sans implémentation ce qui est bien pénible car à chaque fois qu'on implémente une interface on doit l'implémentation, donc retour en arrière depuis on implémente avec des tas de noms différent (trait, mixin, etc) la "régle de codage" de C++: une classe ne contenant que des fonctions.

      J'ai bon? Ou c'est autre chose?

      • [^] # Re: Rust

        Posté par . Évalué à  2 .

        Les traits de rust sont en fait assez éloignés des traits/mixins des langages objets habituels puisqu'ils peuvent s'implémenter sur un peu n'importe quel type. Mais oui il y a l'idée qu'il s'agit d'un ensemble de fonction, que les traits ne portent eux-mêmes pas d'état, c'est le type sur lequel on implémente le trait qui doit porter l'état nécessaire.

        Si tu veux te renseigner sur les traits de Rust tu peux regarder la documentation (lire sur "impl" aussi en dessous, c'est lié) mais c'est un peu court en explications, ou alors ce billet qui explique l'état actuel après le changement du système de traits cet été, ou éventuellement ce document de travail qui explique les choix de conception.

  • # c'est la tuile

    Posté par (page perso) . Évalué à  3 .

    La plupart des frameworks, des jeux et des éditeurs de niveaux sont orientés "tuiles". Ce qui est dommage, car les tuiles sont un héritage des composants graphiques et des mémoires limitées des machines ancestrales.

    Aujourd'hui, les tuiles n'ont plus de raisons d'être, elles peuvent même être contre performantes, mais on continue à les utiliser pour plusieurs raisons, l'une des plus importantes, selon moi, étant l'absence d'un bon (et libre) éditeur de niveau générique "non orientés tuiles".

    Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

    • [^] # Re: c'est la tuile

      Posté par (page perso) . Évalué à  2 .

      N'est-ce pas également plus simple d'utiliser les tuiles ?
      On a une grille et on pose dessus, pas très complexe, alors que ne pas gérer des tuiles est plus compliqué, non ?

      • [^] # Re: c'est la tuile

        Posté par (page perso) . Évalué à  2 .

        Les tuiles, c'est bien si tes niveaux sont tout carré, mais dès que tu veux gérer des formes différentes, c'est vite pénible.

        Par exemple dans le niveau sur lequel je travaille pour Newton Adventure, j'ai mis des plateformes qui sont des lignes obliques:

        http://opengameart.org/content/color-tileset

        Si tu télécharges le tileset, tu verras que pour dessiner une ligne, il me faut 3 tuiles: un pour le corps de la ligne, deux autres pour les raccords.

        Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

  • # Deux merci, un paquet de platitudes, une question sans intérêt, bref c'était complément inutile !

    Posté par . Évalué à  1 .

    Merci pour ces liens !

    Concernant The State of Javascript, je comprends bien le but recherché. Re structurer ce langage pour faire face aux nouveaux défis qu'on lui demande.
    Mais ceci dit, l'autre jour j'ai regardé ceci https://www.youtube.com/watch?v=v2ifWcnQs6M et je ne peux que m'étonné par ce désir, maintes fois exprimé, de vouloir re structurer un langage qui veut être déstructuré/versatil/bordélique[, ou ce qui te plait], le fameux concept du prototypage Vs déclaration de classe.

    Bref, ce ES6 n'est il pas plutôt entrain de créer un nouveau langage sur lequel ils vont posé le nom javascript afin de surfer sur la vague ?
    Mais bon la relation entre ecmascript et javascript me laisse un peu perplexe depuis longtemps déjà, je n'ai peut être donc pas tout compris.

    Rust ou Go, mon désir se déchire au regard du temps disponible pour m'y investir…. Rust j'en avais lu la doc, je m'étais dis super ! Mais lorsque j'ai voulu coder je me suis refroidit devant les IDE disponible (note pour bientôt, chercher un IDE rust).
    Go == Java == Javales pas bien… Le goût, la texture, vas savoir. Mais Sublime me fais bander alors je pourrais ptet bien me laisser faire :o

    Enfin merci pour ces deux petits liens sur github/StratosJump, c'est bon pour les mirettes, c'est bon pour le moral.

  • # Bout de code en ruby

    Posté par . Évalué à  0 .

    Pour le bout de code en ruby :

    # all i want is to sum the goddamn elements
    sum = 0
    (1..10).each_fucking_element { |e| sum += e }
    
    

    C'est exactement le cas d'utilisation de la méthode #inject :

    (1..10).inject(&:+)
    
    

    Pour expliquer :

    • (1..10) est une énumération des entiers de 1 à 10
    • On applique la méthode inject est bien expliquée dans la doc mais en résumé :
      • on a un accumulateur (qui correspond à la variable sum du code précédent) et on fait une opération avec cet accumulateur et les valeurs du tableau.
      • Quand on ne précise pas la valeur de l'accumulateur, elle vaut le premier élément du tableau (1 ici)
      • On peut donc faire : (1..10).inject { |accu, val| accu += val } qui peut être condensé en (1..10).inject(&:+)

    PS : Un matheux aurait dis que c'est Somme des n premiers termes

    "Never trust a statistic you haven't faked yourself."

    • [^] # Re: Bout de code en ruby

      Posté par (page perso) . Évalué à  1 .

      Le bout de code était là pour illustré la bibliothèque fsck. Il vient d'ailleurs du README.

      L'exemple suivant est d'ailleurs :

      # inject rocks!
      (1..10).awesome_inject_is_awesome(&:+)
      
      

      L'idée est de pouvoir écrire la méthode comme on veut, et la bibliothèque se débrouille pour appeler la bonne.
      Àma, à part pour le PoC, ça ne sert à rien :)

      • [^] # Re: Bout de code en ruby

        Posté par . Évalué à  1 .

        Oui, je pense qu'il ne trouvera pas les méthodes par magie non plus, par exemple :

        `(0..10)`.fucking_transform_that { |i| i**2 }
        
        

        Après ça peut être amusant d'écrire des scripts avec des "fucking" partout.

        "Never trust a statistic you haven't faked yourself."

      • [^] # Re: Bout de code en ruby

        Posté par (page perso) . Évalué à  2 .

        Àma, à part pour le PoC, ça ne sert à rien :)

        C'est bien pour ça que c'est absolument indispensable !

Suivre le flux des commentaires

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