J’aime les geeks

Le 10 mai 2009 par JB Boisseau

IT crowds

N’est pas geek qui veut. Je travaille au quotidien avec de véritables specimens de geek bien trempés, et je peux dire que, malheureusement, je ne suis pas l’un d’entre eux. Et je le dis d’autant plus sincèrement que j’ai une véritable admiration pour les talents des vrais spécialistes des techniques du web moderne.

Attention, je ne vous parle pas de passionnés de warcraft, de tweeter ou de facebook, je vous parle de ceux qui maîtrisent vraiment ces technos plus ou moins bancales qui composent la toile d’aujourd’hui. Parce que quand on y regarde de plus près, tout cela n’a pas la rationnalité à laquelle pourraient s’attendre les gens s’intéressant au web sans jamais y mettre vraiment les mains :

– HTML est un langage permissif, mal structuré, parfois incohérent : c’est pourtant bien sur cette base que sont construites toutes les pages web. Il m’arrive même de souhaiter l’arrivée de sa prochaine version.

– Javascript est un langage faiblement typé, qui ne connaît pas la notion de classe et qui n’est pas supporté de la même manière par tous les navigateurs… et pourtant, on se prend parfois à imaginer que c’est le nouveau langage de référence !

– Les CSS sont un véritable cauchemar dès lors que l’on souhaite faire fonctionner quelque chose correctement sur IE6 (voir à ce sujet un article de votre serviteur à paraître dans le prochain programmez… et attendant ce site qui peut s’avérer des plus utiles)

– L’administration système relève parfois de la magie noire, surtout quand on creuse un peu trop. Heureusement, Sébastien Le Ray, collègue qui se surnomme modestement « Dieu », nous fait part du fruit de ses expériences à mi-chemin entre science et spiritisme. Au programme : administration Unix, Apache, PostgreSQL, MySQL et PHP.

A quel numéro de version pourra-t-on considérer le web comme étant stable ? Sûrement pas la 2.0…

De l’open-source à l’open-money

Le 2 mars 2009 par JB Boisseau

Dans ce blog, à la ligne éditoriale assez singulière, il est question pour l’essentiel de technologies web (on y traduisait par exemple « What is web 2.0 » en décembre 2005) et d’économie (on y annonçait le scénario de la crise actuelle dès février 2007). Rares sont les moments où ces deux sujets s’entrechoquent comme dans le post d’aujourd’hui.

openmoney

L’open-source est un mouvement définitivement lié à l’histoire du web. Le principe est simple : en mettant à disposition des logiciels dont le code source est ouvert et librement redistribuable, on crée un écosystème bien plus riche en innovation qu’avec des logiciels fermés. En effet, tout comme dans le monde scientifique, il est possible aux développeurs de s’appuyer directement sur les travaux de leurs confrères pour créer de nouvelles briques logicielles ou pour améliorer celles qui existent. Ce processus fait potentiellement d’eux -selon l’adage de Newton- « des nains sur des épaules de géants ».

Les technologies web fondatrices (HTTP, HTML) sont ouvertes, et pour cause, elles viennent du CERN, un des temples de la science moderne. Et depuis son acte de naissance, le web n’a cessé de se développer, en largant ses concurrents fermés les uns après les autres, à l’aide de technologies toutes aussi ouvertes : Linux, BSD, Apache, MySQL, PHP, Perl sont autant d’exemples de logiciels qui ont imposé leur empreinte sur le web et contribué à son essor. Un rapide coup d’oeil sur les enquêtes Netcraft montre que c’est toujours le cas.

A l’heure de la crise, le mouvement open-money propose une approche au moins aussi stimulante de l’économie que l’open-source l’est pour le monde du logiciel. L’open money, c’est la « libération » des moyens de paiement. Nos monnaies actuelles sont en effet en un sens des systèmes propriétaires : l’euro et le dollar sont gérés par des banques centrales qui décident de leur mode d’émission tout en se faisant rémunérer pour leur mise à disposition aux banques commerciales. Ces dernières redistribuent ces liquidités (avec effet de levier grâce aux mécanismes de l’argent scriptural et des taux de réserves obligatoires) aux agents économiques. Deux agents économiques voulant commercer avec de l’euro ou du dollar doivent donc nécessairement faire appel à un système commercial extérieur sur lequel ils n’ont aucun contrôle. Par ailleurs, le monopole -de l’euro par exemple- d’une monnaie sur une zone donnée oblige les agents économiques à l’utiliser de fait…à moins de faire du troc !

Le système monétaire classique est donc bel et bien verrouillé comme l’est, dans un autre genre, un logiciel propriétaire. Partant de ce constat, l’open money reprend l’héritage des LETS (Local Exchange Trading Systems, en français SEL pour Systèmes d’échanges locaux) pour proposer des circuits monétaires alternatifs « libres » : il s’agit d’implanter au sein d’une communauté donnée une ou plusieurs monnaies que les membres gèrent directement. Les échanges entre membres ne sont dès lors plus soumis à des conditions extérieures à la communauté telle que la quantité et la qualité de la monnaie en circulation.

Bien entendu, tout comme le développement open-source exige certaines bonnes pratiques pour être efficient, il est nécessaire que ces « monnaies libres » ainsi que les communautés qui les utilisent aient des règles de fonctionnement efficaces. Or, comme le montre le faible développement des LETS jusqu’à présent (malgré un certain âge et un nombre d’initiatives assez important), ces règles sont très loin d’aller de soi… d’où la pertinence des recherches menées par les membres de l’open money sur le sujet !

Produire du code sécurisé pour le web… une bonne blague ?

Le 4 février 2009 par JB Boisseau

Le 12 janvier a vu la parution d’un document qui vaut le coup d’oeil et même un peu plus : « les 25 erreurs de programmation les plus dangereuses » qu’on ne trouve pour le moment qu’en VO.

On y trouve en particulier les 3 failles majeures d’un très grand nombre d’applications web :

– Vulnérabilité aux injections SQL

– Vulnérabilité aux attaques de type « Cross Site Request Forgery »

– Vulnérabilité au Cross Site Scripting (attaques XSS)

A l’occasion d’une petite discussion avec François Tonic (rédac chef du magazine Programmez) et quelques collègues sur ce sujet, plusieurs réflexions sur la place de la sécurité dans les projets web nous sont apparues d’une actualité criante :

– les développeurs sont, de manière générale, assez inconscients des problématiques de sécurité posées par leurs applications

– les chefs de projet ayant un profil insuffisamment technique (chose plus que courante sur les projets web…) sont au mieux incapables de contrôler le boulot des développeurs, au pire complètement ignorants de la problématique de la sécurité.

– les clients sont, eux aussi, insuffisamment sensibilisés à la question et tombent souvent des nues quand ils voient apparaître un budget « sécurité » conséquent dans une proposition commerciale

– trop souvent, la sécurité est vue comme une question annexe qui pourra être réglée après coup à l’aide d’un audit et de quelques patches… ce qui est en réalité un très mauvais calcul : la sécurité doit être une problématique quotidienne pour les développeurs, le contrôle a posteriori est moins efficace et plus coûteux

Pas convaincus ? Regardez donc ces quelques exemples :

Une belle attaque CSRF sur le site d’une banque permettant à un attaquant de faire des transferts sur des comptes qui ne lui appartiennent pas

Une petite injection SQL pour hacker un site d’un éditeur d’antivirus

Une faille XSS qui ouvre la voie à une belle opération de phishing sur un système de paiement sécurisé

Toujours pas convaincus ?

Sous le capot de Google Chrome

Le 4 septembre 2008 par JB Boisseau

Je ne vais pas en rajouter sur ce que chacun pourra constater de lui-même sur Google Chrome, je me contenterai de dire qu’il est désormais mon navigateur par défaut (hors développement). Je ne vais pas non plus parler de la stratégie de Google : la société l’explique assez clairement et j’ai pour ma part la naïveté de la croire.

Je veux vous parler de ce que Chrome a dans le ventre et de pourquoi ça marche si bien… et surtout si vite. Un navigateur web, c’est essentiellement 4 choses :

  • un moteur de rendu HTML pour afficher les pages, 
  • un moteur d’exécution Javascript,
  • une interface utilisateur pour permettre l’accès aux fonctionnalités du navigateur
  • une architecture qui fasse tenir le tout debout (y compris les plugins, comme Flash, qui s’y rattachent).

Or, sur chacun de ces points, Google a fait ce qu’il fallait, en appliquant simplement des recettes connues par à peu près tous les développeurs s’intéressant de près aux navigateurs. 

Le moteur HTML utilisé par Google n’est autre que Webkit (bon, le moteur en lui-même s’appelle « Webcore », mais comme tout le monde dit « Webkit », je vais pas me la jouer puriste…) . C’est le moteur de rendu de Safari, de l’iPhone, d’Android et de nombreux navigateurs pour mobile. Webkit est simple, rapide et léger : précisément ce que cherchait Google. 

Le moteur Javascript, V8, est lui une nouveauté : son principal atout est la reprise de l’idée de compilation juste-à-temps de Tracemonkey, le moteur utilisé par le futur Firefox 3.1. En d’autres termes, il a une longueur d’avance sur tous les autres (même si avec Brendan Eich, le concepteur de Javascript, chez Mozilla, la partie risque d’être serrée) ! En générant des pseudo-classes pour mieux mutualiser les comportements des objets et en mettant ou point un ramasse-miette efficace, les concepteurs de V8 ont dégagé de nouvelles marges de manoeuvre pour larguer la concurrence dans la course à la performance. 

L’interface utilisateur est dépouillée au maximum, ce qui limite bien entendu la consommation de ressources. De plus, Google a réalisé un kit graphique sur mesure afin de maitriser au mieux cet aspect (plutôt que d’en laisser la responsabilité à Windows ou à un kit graphique tiers comme le fait la majorité la majorité des applications). 

L’architecture qui tient le tout a un principe directeur : compartimentation ! Ce qui dans la BD de présentation de Chrome aux journalistes est résumé sous l’expression « un onglet, un processus » est en réalité plus complexe comme le montre le schéma ci-dessous : architecture chrome

Pour faire « simple » : un processus-maître coordonne des processus de rendu propre, chacun de ces processus étant lui-même multi-threads.  Cette architecture segmente parfaitement les responsabilités et évite qu’un problème ne bloque l’ensemble de l’application. Elle permet également de paralléliser les traitements ce qui peut s’avérer plus efficace dans certaines configurations.  

Ce même principe de compartimentation est appliqué en matière de plug-in : en utilisant astucieusement le motif de conception « proxy », Chrome parvient à isoler les plug-ins en dehors des processus de rendu de la page web. Une source de crashes et de ralentissement des plus importantes se trouve fixé par ce tour de passe-passe qui, espérons le, sera repris par la concurrence.

Pour aller plus loin, je vous recommande l’excellente documentation de Chromium (le projet libre derrière Chrome) ou encore un article de votre serviteur à paraître dans le numéro de Programmez qui sortira à la fin du mois… D’ici là, des questions ?

Retour sur Terre

Le 4 août 2008 par JB Boisseau

Après quelques mois d’activité intense mais sans publication, ce billet est l’occasion de prendre un peu de recul sur l’actualité de cette belle industrie qu’est le web… recul certainement salvateur à l’heure de proférer analyses et prédictions que les faits prendront, quoi qu’il arrive, un malin plaisir à contredire.Au niveau de l’innovation, qu’a-t-on vu de franchement renversant depuis avril ? Pas grand-chose de mon point de vue, si ce n’est :

  • L’accélération de la maturation du web mobile avec bien entendu du nouvel iPhone, mais aussi la multiplication d’offres 3G qui deviennent peu à peu abordables. C’est là un terrain, qui sans être vierge, offre une myriade de surprises fonctionnelles, techniques, dans les usages et les enjeux économiques… de quoi faire retrouver une nouvelle jeunesse au web tant les concepts du web 2.0 (qui n’étaient pourtant pas du buzz) ont été usés et abusés depuis près de 4 ans.
  • La redécouverte d’un hack Javascript qui peut s’avérer bien pratique : « window.name »

Au niveau de l’économie et des trop funestes prévisions de votre serviteur, le bilan est là aussi contrasté :

  • Comme annoncé en avril, l’inévitable rechute de l’action Google s’est produite, malgré des résultats que beaucoup pourraient envier.
  • Les résultats de l’économie américaine prennent une tournure de plus en plus compliquée à analyser : on nous annonce que le PIB a décru au dernier trimestre 2007 (chiffre revu à -0,2% contre +0,6% annoncés initialement) mais que le second trimestre 2008 fait ressortir une belle croissance (+1,9%) alors que l’industrie est au plus bas, que la crise financière est loin d’être finie, que le chômage grimpe encore et que l’immobilier n’a pas encore touché le fond… difficile à comprendre ! Faut-il y voir l’effet des chèques Bush ?

Le constat peut donc paraître morose, mais les temps qui viennent s’annoncent quant à eux passionnants… car lorsqu’une ère semble s’achever, c’est à coup sûr qu’une autre est sur le point de naître !