Archives par mot-clé : Technologies Web

Programmation performante des serveurs web

La performance des serveurs web est un vrai sujet : on a besoin de sites qui répondent vite, pour vendre plus 😉

Et un serveur web peut être amené à répondre à « pleins » de requêtes simultannées.

On peut palier de manière superficielle à ces problèmes avec du cache. Bonne idée… mais les sites doivent de plus en plus être personnalisés, dynamiques. On peut donc « cacher » certaines ressources, mais pour les parties dynamiques, il faut faire autrement.

Au coeur des serveurs web se pose donc la question de la programmation parallèle : faire tourner plusieurs programmes en parallèles pour répondre en même temps à plusieurs utilisateurs.

Quand on programme avec les technologies « normales », on ne se rend pas compte de tout ça : c’est le serveur web qui gère, de manière transparente pour le programmeur. en fait, à chaque appel au serveur web, un fork est créé. Un fork, c’est une unité d’exécution indépendante. Chaque programme, pour chaque appel, est donc « dans son coin ».

C’est une bonne idée, parce que on masque ce problème technique… Sauf que la gestion des forks n’est pas très optimisée, et qu’à créer trop de forks, on fait rapidement tomber les serveurs.

D’ou l’idée de faire autrement. C’est en particulier ce que propose certains environnements, tel node.js, basés sur des serveurs webs spécifiques (autre que apache donc).

Dans ces environnements alternatifs, les différents programmes ne sont pas exécutés dans des forks indépendants.

Pour gérer la continuité entre les différentes fonction, le programmeur doit mettre en place des procédures de call back, …

Bref, je ne veux pas trop rentré dans les détails (d’ailleurs, je ne suis plus programmeur, j’atteints vite mes limites 😉 ).

Mon sentiment sur cette histoire :

Je comprends le chemin emprunté par ces solutions, c’est pragmatique : puisque les serveurs web rament avec les technos de forks, on descend d’un niveau, et on gère la programmation parallèle directement.

Mais sur le fond, je suis convaincu que la solution n’est pas là. Cela me semble complètement indispensable de masquer ces problématiques au programmeur, qui a déjà bien de quoi s’occuper. Et si la programmation parallèle n’est pas efficace, et bien il faut revoir l’architecture du système !

Javascript comme langage universel ?

Javascript est aujourd’hui très populaire pour une bonne raison : c’est le langage de programmation utilisé côté client : inclus dans les pages HTML et interprété par les navigateurs.

Mais Javascript est un langage informatique à part entière : rien n’empêche de l’utiliser pour d’autres choses.

On pourrait par exemple imaginer un environnement de développement de services web en Javascript…

Avantage : le programmeur ne doit apprendre qu’un seul langage de programmation : le Javascript. Ce langage serait utilisé côté client et côté serveur.

(Bon, le programmeur web doit toujours en plus bien maîtriser les différents langages du Web : HTML, CSS).

Cette approche existe, via plusieurs projets.

C’est par exemple ce que propose wakanda, framework de développement d’applications Web, basé sur le Javascript.

Pour info, ce Framework a pour initiateur 4D, et un certain Laurent Ribardière…

Voici un exemple de vidéo de présentation de l’outil :

Vous pourrez trouver toutes les vidéos sur l’outil ici.

Je n’ai pas testé l’outil, mais je pense que l’approche est intéressante.

Et vous ?

 

La fin du combat pour Flash, mais quel avenir pour HTML5 ?

La news est tombée pendant les vacances : Adobe arrête de supporter Flash sur Android.

Plus de Flash sur Android, et bien sûr toujours pas de Flash sur les terminaux mobiles Apple : une bonne partie du Web doit maintenant se débrouiller sans Flash.

Plus intéressant encore est la raison de cet abandon : Adobe reconnait que l’avenir est du côté du HTML5.

La messe est donc dite : le Flash va disparaître, et être remplacé par les technologies incluses dans le HTML5.

Tout serait simple si…

Si le HTML5 avançait bien. Ce qui n’est pas du tout le cas : aux dernières nouvelles, les équipes se disputent, ce qui va rendre le processus de normalisation plus lent et plus complexe…

Aujourd’hui, rien ne garanti qu’on arrive dans les temps, c’est à dire en 2014, avec une norme bien aboutie.

Ce qui est a peu près clair, c’est que ce sont les éditeurs de navigateurs qui font principalement évoluer les choses : Google, mozilla, Microsoft, Apple.

Bon, concrètement, il ne me semble plus très raisonnable de démarrer un site avec des composants Flash. Le HTML5 est de rigueur !

Les agences vont devoir accélérer leurs mutations, et, surtout, on attend des outils d’éditions HTML5 à la hauteur des enjeux.

A suivre de prêt !