Note : Comme d'habitude ce contenu est cross-posté sur linuxfr

Introduction

Bon, j'ai zapé encore une fois quelques numéros, mais c'était entre autre 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 nième surcouche à javascript. Cette fois ci en provenance mozilla, Sweet.js. Je ne l'ai pas encore testé 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, avec 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. Par contre, ça peut être assez marrant et il serait intéressant de voir si l'absence de garbage collector 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, 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 design, 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 design, pourra mieux répondre aux attentes de performances. Evidemment 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 mets un peu à égalité dans les faits.

Toujours en parlant de Dart, voici des conventions d'organisation de paquet. Même si les choses s'améliorent, c'est un point qui est souvent négligé dans le web. Probablement car 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 templates, 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 leur 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 allez voir leurs arguments et quelques exemples, mais ce qui est clair est qu'ils sont plutôt tombé 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 news en provenance du w3c : après avoir fait de html5 une version "rolling release", puis séparé html5 en html5 et html5 (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 meilleurs bibliothèques javascript. L'article commence, à raison, sur le fait qu'on passe beaucoup plus de temps à utiliser une bibliothèque qu'à l'écrire. Par contre, s'il y a des choses plutôt intéressantes, je suis mitigé par rapport à 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 c'est malheureusement pas ce que beaucoup de développeurs (à tord) 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 terme 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 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 :

javascript 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 :

javascript 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° 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 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, ... 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

Développement

Misc

Graphisme & co