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

Posté par  (site web personnel) . Édité par baud123. Modéré par baud123. Licence CC By‑SA.
Étiquettes :
20
23
nov.
2012
Technologie

Comme à sa presque habitude, voici un petit condensé de ma veille.

Vous l'aurez remarqué, il y a un peu de lag… mais bon, c'est aussi le principe ;-)

Comme toujours, il s’agit comme souvent essentiellement de bookmarks, très légèrement commentés. Pour cette fois, il y a un peu moins de contenu, mais pourquoi pas, je pense que ça conviendra peut-être mieux à certains. Et je ne voulais pas attendre une semaine de plus, ce serait moins intéressant.

C’est plutôt orienté développement, essentiellement côté Web, javascript, ruby, 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

Contributions

Introduction

Il m'arrivait souvent (surtout lorsque je le faisais pour mon travail) de commencer par une introduction. Ok, il m'est aussi arrivé de faire une conclusion de 3 pages…

C'est entre autre pour ce genre de contenu qu'initialement, je voulais ces contenus en journaux (de seconde pages s'ils existaient encore). À voir, si ça vous dérange ou non, de mon côté ma "veille" n'a toujours été que mon reflet personnel et absolument pas objectif / équitable / neutre.

Quoi qu'il en soit, j'aurais voulu juste reposer un lien ici, même s'il est déjà passé sur linuxfr. Il s'agit de l'article de slate sur _why. Cet article, je l'ai trouvé réellement intéressant. Non pour le côté ruby au final, non pour le côté "people", mais pour le côté "info-suicide". N'avez-vous jamais eu envie de fermer tous vos comptes et de recommencer (ou non d'ailleurs) à côté ? Au final, à quoi ça sert tout ça ? Tous ces comptes ? Toute cette vie numérique et fausse ? On voit de plus en plus de monde qui ne vit presque que pour avoir un follower de plus, un like de plus sur leur page, leur post. Et finalement, le monde du développement est pareil, regardez sur github (le facebook des dev), sur coderwall, etc. Mais tout ceci sert à quoi au final ? Quand je regarde, j'ai un compte g+, un facebook, un github, un twitter, un viadeo, un linkedin, un coderwall (et même un linuxfr). Dans chacun des cas, on a surtout une illusion d’interaction. Oui, parfois il y a de vrais interactions, mais en général c'est du vent. Et la grande majorité des interactions que j'ai via ces plateformes sont en fait avec des gens que je connais personnellement, IRL.
Bon, je ne sais pas trop comment terminer cette introduction qui n'en est pas une, mais je voulais juste ouvrir une porte sur ce sujet que je trouve plutôt intéressant et important. Il faudrait probablement le détailler un peu plus, ce que je ferai un jour (je ne le mets pas sur ma liste des choses à faire, elle déborde déjà au point que je ne la regarde plus…).

Un peu de contenu

Développement

Si vous vous intéressez un peu à HTML(5) vous aurez probablement noté que pas mal d'API voient le jour. Dans le genre plutôt pratique, il existe désormais une API de gestion de la batterie, une API de préchargement de contenu, une API permettant de savoir quand un utilisateur affiche une page, et même une API permettant d’accéder à votre matériel type webcam (en simplifiant un peu). On peut trouver ça plutôt étrange mais ça répond, pour une fois, à certains besoins intéressants et remplace réellement de plus en plus ce qui était autrefois réalisé par des greffons, tels flash. Voici donc un article vous présentant rapidement 5 API HTML5. Et pour ceux qui ne sont pas au fait je vous recommande aussi de jeter un œil à ces autres API, notamment element.classList

Dans le genre un peu plus léger, si vous faites du ruby vous serez probablement intéressés par nutella. Rien de très magique ni exceptionnel, mais simplement une petite collection d'utilitaires visant à simplifier encore un peu Ruby.

Restons un peu dans le monde Ruby pour vous présenter rapidement le module Benchmark de ruby 1.9. Honnêtement je n'ai pas testé ceci, mais ça peut répondre à certaines problématiques de recherche de performances.

Vous vous êtes probablement toujours demandé (si, si) comment convertir des nombres en chiffres romains… heureusement, il y a une gem pour ça ! Et oui, c'est le boulot (mais aussi pour l'inverse) de roman-numerals.

Bon, quittons ceux qui font mumuse avec Ruby pour retourner vers le vrai monde web, PHP ! Vous le savez probablement, PHP c'est pas vraiment toujours rapide… Pour corriger ce problème, certains se sont mis en tête de créer, par exemple, des serveurs optimisés pour servir du PHP. C'est, entre autres, le cas de Pancake (dont vous trouverez les sources ici). Ha oui, histoire de rigoler un peu, Pancake est un serveur PHP… écrit en PHP ;-) Sans cela, ça aurait été beaucoup moins drôle ! Plus sérieusement, il y a certaines choses qui semblent réellement intéressantes, notamment le fait de ne pas avoir à recharger le code PHP (ce qui est fait en général), tout en évitant certains problèmes liés aux éléments statiques. Ben oui, il faut bien comprendre que vu que PHP est rechargé tout le temps, la gestion des éléments statiques est "un peu" différente… et genre, pas forcément besoin de fermer des handler, puisque l'exécution n'est pas persistante… (et sinon, j'aime les projets qui ont des noms sympa).

Je ne sais plus trop d'où je sors ce lien (j'espère que ça ne provient pas d'ici ;)) mais il est plutôt intéressant. Il s'agit de la découverte d'un mauvais effet de bord sur le site de twitter lors du passage de jquery 1.4.2 à 1.4.4. Suite à cette mise à jour mineure, une baisse significative des performances s'est faite ressentir. Qu'est-ce qui a bien pu causer se problème ? Tout simplement, l'utilisation de querySelectorAll à la place des classiques getElementsByTagName et getElementsByClassName. Faites bien attention à tout ça, on a tendance (surtout lorsque c'est masqué par des bibliothèques comme jquery) à utiliser des opérateurs de recherche plutôt flous, tel querySelector (comme on le ferait en CSS), alors qu'une simple petite combinaison des opérateurs classiques serait plus propre et plus performante. C'est sûr que les sélecteurs sont vraiment sympa, mais il faut faire attention à ce qu'on fait. Attention aussi à ne pas tomber dans l'excès inverse, les "micro-optimisations" peuvent avoir un gain utilisateur totalement nul et une perte de lisibilité/maintenance du code importante. Pour lire l'histoire, intéressante, c'est ici : learning from twitter

Avant propos : dans le paragraphe suivant je vais parler de Go. Je sais très bien que Go n'a pas tout inventé, beaucoup de choses qui sont présentées en Go (que ce soit langage ou les outils créés avec) peuvent déjà exister par ailleurs (outils existants, langages implémentant les mêmes fonctionnalités, etc). Maintenant que c'est précisé, je traite donc le sujet suivant comme je traite tous les autres en réalité.

pandastream est une société qui développe une API d'encodage vidéo. Afin de faciliter leurs déploiements et surtout le rechargement d'applications réseau sans perte de paquets, ils viennent de développer (en libre) socketmaster. Socketmaster est un petit utilitaire en Go qui va permettre de mettre en attente les demandes arrivant sur le service en gardant les sockets ouvertes le temps que le service réel redémarre. Bon, je sais pas si c'est super clair, mais c'est vraiment pratique. En gros, lorsqu'un demande arrive, elle arrive au niveau de socketmaster et non au niveau du serveur réellement. Si le serveur peut répondre, la demande lui est transférée. Si ce n'est pas le cas (par exemple pendant un redémarrage) les demandes sont mises en attente et transmises au serveur dès qu'il redevient disponible. Vous trouverez sur le blog de pandastream un article présentant socketmaster. Dans cet article, ils présentent entre autre certaines raison qui les ont fait utiliser Go :

The tool is written in Go which allowed me to shorten my development time considerably compared to C. Go allowed me to tap into the lower-level POSIX constructs while also having access to handy higher-level abstractions. For you, it means that it can easily be cross-compiled and distributed in a binary form.

En gros, Go permet d'aller beaucoup plus vite que C. C'est plus mieux en étant à la fois bas niveau, avec des structures de haut niveau. Et ça permet de faire des binaires facilement.

Toujours côté développement, voici quelques présentations que je vous conseille :

  • Making the Web Faster at Google and Beyond : présentation sympa sur les performances du web, temps de réponse, etc. Lorsque je vois la rapidité de certains sites (c'est évidement malheureusement ironique), je me dis par contre que cette présentation est réellement loin de la médiocrité (pour ne pas dire pire) de certains :-(
  • A Gentle Introduction to Ember : une introduction sympa à Ember, entre autres, montrant comment créer un lecteur de RSS.

Graphisme, design & co

Dans le genre étrange, voici les photos de 25 endroits sur Terre qui ne semblent pas normaux… et pourtant ils sont bien réels ! J'en connaissais déjà certains (comme la Namibie), mais d'autres sont réellement impressionnants. Si vous voulez vous extasier quelques instants, prenez le temps d'aller voir ces 25 photos, c'est intriguant mais agréable.

Pendant un temps il m'arrivait de placer des lego dans quasiment toutes mes news. Cette fois-ci (grâce à xunfr) voici une image du brevet de ces petites briques. Ok, ça ne sert pas à grand chose mais moi j'aime bien :)

Liste des liens présentés

Développement

Graphisme, design & co

Aller plus loin

  • # HTML5

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

    Pourquoi parle-t-on d'HTML pour ces API-là ? C'est du JavaScript, ce serait dommage de le retreindre à une utilisation dans des pages en HTML5…

    • [^] # Re: HTML5

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

      Par abus de langage, en partie.

      Mais ce n'est pas non plus "simplement" un API Javascript car en général lié à HTML, Dom. Ce n'est pas pur javascript.

      En fait (en tout cas c'est comme ça que je le prend) HTML5 regroupe en fait tout ce qui est langage HTML, Dom, CSS, JS. C'est vague est peu défini, mais ça correspond pas mal à ça.

  • # Benchmark de pancake

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

    J'aime beaucoup le benchmark de Pancake : l'auteur configure tous les serveurs avec 4 workers mais lance le benchmark avec une concurrence de 1 (le défaut pour ab). Puis, l'auteur ne donne ni la version de PHP utilisée ni la configuration des serveurs, j'imagine que ça ne doit pas être très important pour reproduire le benchmark. Bref, du joli n'importe quoi !

    • [^] # Re: Benchmark de pancake

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 24 novembre 2012 à 00:22.

      Peut-être PHP 5.4.8 ? (au hasard)

      Mais bon, ça me semble curieux qu'en PHP on puisse faire plus rapide qu'en C/C++.
      Enfin, plus exactement, il serait plus intéressant de comparer son serveur web à un serveur classique + n'importe quel système de cache habituel avec PHP, pour voir quel est le gain apporté par l'absence de parsing (et autres) à chaque page.

      Et je me demande quelle sera la différence de perf (même sans cache PHP) quand il voudra prendre en compte des configurations HTTP consommant du CPU, comme du HTTPS (avec authentification TLS mutuelle) avec Kerberos…

      • [^] # Re: Benchmark de pancake

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

        Ce qui m'intrigue le plus, c'est l'intérêt de la chose par rapport aux fameux caches d'OpCode, tels qu'APC / eAccelerator / X-Cache.

        Parce que parser le code PHP à chaque hit, ça fait un moment qu'on ne le fait plus… sauf peut-être en cas d'oubli d'activation de la part de l'admin ?
        Me semble qu'il était d'ailleurs question d'intégrer et activer APC par défaut dans les futures versions de PHP, mais que cela avait été refusé afin de laisser le choix du soft à l'admin…

        Bref, pourquoi aucun cache d'OpCode ne semble être présent dans son bench ?

        alf.life

  • # En infosuicide

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

    Dans la communauté Python, il y a Mark Pilgrim qui a disparu du net en octobre 2011.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: En infosuicide

      Posté par  . Évalué à -3.

      L'auteur de "why's (poignant) guide to ruby" a disparu d'Internet aussi y'a pas mal de temps.

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

      • [^] # Re: En infosuicide

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

        Ha oui, genre un gars avec comme pseudo _why, non ?

        tip : retourner voir le lien posté dans l'introduction ;)

        • [^] # Re: En infosuicide

          Posté par  . Évalué à -2.

          Ha. Ben c'est super vieux, j'ai appris ça sur Wikipedia y'a 8 mois. :p

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

  • # Islande...

    Posté par  (Mastodon) . Évalué à 6.

    25 photos cadrées et retouchées de façon à sembler totalement extra-terrestres, et trois prises sur une petite île aride et tourmentée. Et encore la Grand Prismatic Spring à Yellowstone peut se voir en plus sauvage là-bas aussi, ça aurait pu faire 4 sur 25 ! Aller à Yellowstone après être allé là-bas, c'est fade, je ne le conseille pas…

    S'il y a un pays au monde où aller pour changer complètement de planète, c'est bien l'Islande.
    C'est indescriptible parce qu'il y a trop à en dire.
    C'est unique au monde.

    C'est beau l'Islande, sauvagement beau, sans pitié, sans concession, la nature brute, splendide, et majestueuse.

    Yth, on peut être gique et lyreek à la fois.

    • [^] # Re: Islande...

      Posté par  . Évalué à 3.

      J'y étais la semaine dernière, et on ne peut pas dire mieux que ce que tu dis : dépaysant, sans pité, exceptionnellement beau. C'est frustrant de ne pas y rester des semaines tellement il y a à faire et voir… Du coup, match retour prévu pour l'hiver 2013.

  • # go

    Posté par  . Évalué à 2. Dernière modification le 23 novembre 2012 à 14:22.

    "En gros, Go permet d'aller beaucoup plus vite que C. C'est plus mieux en étant à la fois bas niveau, avec des structures de haut niveau. Et ça permet de faire des binaires facilement."

    s/Go/C++/
    </troll>

    • [^] # Re: go

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

      s/C/C++ lui-même permettant d'être plus rapide qu'en C/

      De rien ;)

    • [^] # Re: go

      Posté par  . Évalué à 2.

      s/Go/C++/

      Nimrod(parmi les rares langages avec un GC 'temps réel'), D, Rust, etc.

    • [^] # Re: go

      Posté par  . Évalué à 3.

      La traduction est foireuse. Quand il dit aller beaucoup plus vite, il parle de temps de développement et non pas de la vitesse du programme compilé…

      Dans ce sens là, je sais pas si C++ s'applique vraiment pour ton raisonnement…

      • [^] # Re: go

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

        La traduction est foireuse

        Approximative, pourquoi pas.
        En tout cas c'était bien dans ce sens (rapidité de développement) que je l'entendais.

        Dans ce sens là, je sais pas si C++ s'applique vraiment pour ton raisonnement…

        Ben étant donné que du code C++ ne sera pas plus rapide que du C mais que C++ peut être plus rapide a développer que du C, je pencherais pour le fait que ça s'applique à son raisonnement. Non ?

  • # Commentaires sur les liens

    Posté par  . Évalué à 2.

    A noter que sur les APIs web/html5/javascript sont très fortement poussées par Mozilla pour son OS mobile Firefox OS puisque les applications natives seront des applications Web: https://wiki.mozilla.org/WebAPI

    Il semble que Pancake n'est pas libre. Bouuuhhhh!

Suivre le flux des commentaires

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