Journal De tout, de rien, des bookmarks, du bla bla #41

Sommaire

• Introduction
• Un peu de contenu
  • Développement
  • Misc
  • Graphisme & co
• Liste des liens présentés
  • Introduction
  • Développement
  • Misc
  • Graphisme & co

Introduction

Bon, j’ai zappé encore une fois quelques numéros, mais c’était, entre autres, parce que j’ai créé Sleipnir, et ça m’a pris un peu de temps. Et je sais que vous l’attendiez tous impatiemment !

Pour cette fois, comme d’habitude, pas mal de dev’ Web, surtout autour de JavaScript.

Allez, assez de bla bla, place aux liens.

Un peu de contenu

Développement

Tout d’abord, une n‐ième surcouche à JavaSript, cette fois‐ci, en provenance Mozilla, Sweet.js. Je ne l’ai pas encore testée, mais je n’ai pas vraiment saisi l’intérêt. L’un d’entre vous a‐t‐il déjà essayé ?

Encore en lien avec Mozilla, voici LLJS. Il s’agit, d’après la doc, d’une surcouche à JavaScript orientée bas niveau, avec un système de typage à la C et une gestion manuelle de la mémoire. Idem, je ne sais pas quel est vraiment le but recherché, c’est intéressant sur le principe, mais je vois pas bien l’intérêt. En revanche, ça peut être assez marrant, et il serait intéressant de voir si l’absence de ramasse‐miettes peut avoir un intérêt quelconque (performances, par exemple).

Bon, je ne parlerai pas vraiment de TypeScript, allez juste un petit peu. Beaucoup de personnes l’ont comparé à Dart. Mais je pense que ce n’est comparable qu’en apparence. TypeScript tente de corriger des problèmes du genre typage, modèle objet. Le but est, il me semble, d’avoir un langage plus robuste, le plus propre pour aider au développement, et ensuite de l’exécuter une fois compilé en JavaScript. Dart part d’un tout autre constat : on s’approche des limites d’optimisation de JavaScript. En gros, par conception, JavaScript est complexe à optimiser et chaque amélioration coûte assez cher. L’objectif est donc de remplacer JavaScript par un langage qui peut être mieux optimisé, qui, par conception, pourra mieux répondre aux attentes de performances. Évidemment, le tout en améliorant le langage, mais sans non plus tout changer. En attendant, Dart peut tout de même être compilé en JavaScript, ce qui, pour le coup, les met un peu à égalité dans les faits.

Toujours en parlant de Dart, voici des conventions d’organisation de paquets. Même si les choses s’améliorent, c’est un point qui est souvent négligé dans le Web. Probablement parce qu’initialement il n’y avait pas besoin d’empaqueter grand chose. Mais maintenant que tout (ou presque) passe par des préprocesseurs ou compilateurs (que ce soit les feuilles de style, les modèles, les Dart, TypeScript, CoffeeScript…) les choses deviennent un peu plus complexes. Avoir une bonne structure à ce niveau est plutôt intéressant.

Et en parlant de CoffeeScript, v’la t’y pas que Dropbox migre sous Coffee pour son code client. Un retour d’expérience plutôt intéressant, sur un ensemble de code de taille correcte (environ 20 000 lignes). Je vous laisse aller voir leurs arguments et quelques exemples, mais ce qui est clair, c’est qu’ils sont plutôt tombés sous le charme. D’ailleurs, tout le nouveau code est en Coffee.

Pour rester un peu dans le Web, je ne sais pas si vous avez vu passer les nouvelles en provenance du W3C : après avoir fait de HTML 5 une version « rolling release », puis séparé HTML 5 en HTML 5 et HTML 5 (bon OK, un truc plutôt stable et un truc plutôt mobile), voici qu’ils planifient HTML 5.1. Franchement, j’ai un peu de mal à voir l’intérêt. On va en fait revenir à la même situation qu’avant, les navigateurs qui supportent des versions différentes, et un bordel sans nom pour gérer ça. Et je ne parle même pas du fait d’utiliser rapidement des nouveautés…

Je ne rentre pas dans le détail, mais voici une plutôt bonne explication des websockets.

Et également une présentation de la boucle d’évènement de node.js. Plutôt intéressant, si vous voulez vous y mettre, ou juste par curiosité.

Avant de clore la partie développement, voici un lien particulièrement instructif. Il s’agit d’un article sur le fait d’écrire de meilleures bibliothèques JavaScript. L’article commence, à raison, sur le fait qu’on passe beaucoup plus de temps à utiliser une bibliothèque qu’à l’écrire. S’il y a des choses plutôt intéressantes, je suis plutôt mitigé concernant certains points. Un exemple parmi d’autres : Generating accessors. Je vois bien leur problème de duplication de code, mais je trouve que l’usage de générateurs est quelque chose qu’il est souvent (pas forcément tout le temps) préférable d’éviter. Déjà, on commence à s’approcher de la méta‐programmation, et ce n’est malheureusement pas ce que beaucoup de développeurs (à tort) connaissent et utilisent. Ensuite, je trouve que la lecture du code de la bibliothèque en est très fortement perturbée. On ne voit plus vraiment les méthodes existantes, et ça en termes de maintenance, c’est plutôt mauvais. La documentation est également tout de suite plus complexe à réaliser (et pourtant, pour une bibliothèque, c’est quand même super important). En fait, j’utilise les principes de générateurs dans un tout autre contexte, qui, je trouve, est beaucoup plus pertinent : les méthodes cross navigateurs. Typiquement, les méthodes de gestion d’évènements. Beaucoup de méthodes du genre sont bourrées de tests, pour savoir si l’on a attachEvent ou addEventListener. Pour le coup, il est vraiment intéressant de créer, à l’exécution, la bonne méthode. L’avantage étant que le code exécuté sera plus simple, plus performant, car supprimant pas mal de tests. Juste pour représenter ce que je dis (grossièrement). En général, on a :

myCoolApi.addEvent = function(target, eventType, ...) {
  if ("attachEvent" in window) {
    // bla bla bla
  } else if ("addEventListener" in window) {
    // bla bla bla
  } else {
    throw new Error("unsupported")
  }
}

alors qu’on pourrait pour le coup avoir :

myCoolApi.addEvent = (function() {
  if ("attachEvent" in window) {
    return function(target, eventType, ...) {
      // do the ms way
    };
  } else if ("addEventListener" in window) {
    return function(target, eventType, ...) {
      // do the right way
    };
  } else {
    return function() {
      throw new Error("unsupported");
    }
  }
}()

Je trouve ça relativement clair, tout en étant meilleur à l’exécution. Et vous, vous en pensez quoi ?

Et pour terminer, je vous laisse sur une vidéo bien cool, présentant quelques subtilités de Ruby et JavaScript.

Misc

Voici une « petite » analyse très sympa sur les codes PIN. Allez vraiment la voir, ça pourra répondre par exemple à la question « pourquoi 2580 est en 22^e position des codes les plus utilisés, alors que sur votre clavier ça ne ressemble pas à grand chose ? ».

Je me suis mis récemment à irssi (en fait, je suis même passé sous i3 mais c’est encore une autre histoire). Et de mes recherches, voici deux liens qui peuvent vous intéresser. Tout d’abord un thème sympa, solarized. Normal qu’avec ma CSS LinuxFr.org, je l’utilise. ;) Ensuite, voici un article sur l’utilisation de irssi et screen. Je ne l’ai pas encore complètement lu, mais il semble plutôt complet et intéressant.

Et vous, avez‐vous des ressources, astuces, etc., pour un débutant sous irssi (ou sous i3, d’ailleurs) ?

Graphisme & co

Si vous vous demandez quels sont les principes derrière l’interface de Firefox OS, en voici une présentation.

Un peu de graphisme dans ce monde de brutes ! Voici une série de logos plutôt intéressants par leur utilisation de l’espace négatif. On y pense malheureusement peu souvent, c’est pas toujours évident à manier mais c’est plutôt agréable et permet d’avoir des logos à deux lectures.

Liste des liens présentés

Introduction

• Sleipnir : https://linuxfr.org/users/crev/journaux/sleipnir-proxy-quick-dirty-pour-bien-coder

Développement

• Sweet.js : http://sweetjs.org/

• LLJS : http://mbebenita.github.com/LLJS/

• TypeScript : https://linuxfr.org/users/gnumdk/journaux/nouveau-projet-opensource-chez-microsoft-typescript

• Dart : http://www.dartlang.org/

• conventions d’organisation de paquets Dart : http://www.dartlang.org/docs/pub-package-manager/package-layout.html

• Dropbox migre sous Coffee : https://tech.dropbox.com/?p=361

• HTML 5.1 : http://dev.w3.org/html5/decision-policy/html5-2014-plan.html

• websockets : http://lucumr.pocoo.org/2012/9/24/websockets-101/

• la boucle d’évènement de node.js : http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

• écrire de meilleures bibliothèques JavaScript : http://coding.smashingmagazine.com/2012/10/09/designing-javascript-apis-usability/

• subtilités de Ruby et JavaScript : https://www.youtube.com/watch?v=kXEgk1Hdze0&feature=player_embedded

Misc

• étude des codes PIN : http://www.datagenetics.com/blog/september32012/index.html

• irssi : http://www.irssi.org/

• i3 : http://i3wm.org

• thème Solarized pour irssi : https://github.com/huyz/irssi-colors-solarized

• irssi et screen : http://quadpoint.org/articles/irssi/

Graphisme & co

• Firefox OS UX : https://blog.mozilla.org/ux/2012/09/mozcamp-warsaw-design-principles-behind-firefox-os-ux/

• logos avec utilisation de l’espace négatif : http://designspartan.com/info_generale/26-logos-avec-espace-negatif-pour-votre-inspiration/