Vous connaissiez probablement can i use, voici mobile html 5, dont la présentation est un peu plus claire et simple. Passer du natif au pur web est une évolution impossible à arrêter désormais. Si vous voulez être plus en avance qu’en retard, c’est le point de départ de vos réflexions.
Catégorie : Développement informatique
-
Disparition du temps en HTML 5
Il semble qu’on tende à remplacer le projet de balise
<time>
par une balise générique<data>
en HTML 5. L’idée est de pouvoir accrocher des microformats sur autre chose qu’une date, et leur donner une balise moins spécialisée.Sauf que, derrière, mon
<time>
disparaît, alors qu’il a un rôle bien plus naturel dans HTML. (suite…) -
Bon développeur, question d’attitudes
Je viens de lire « Être un bon développeur c’est aussi une question d’attitude personnelle » chez Thomas. Ceux qui me connaissent le savent, le titre a forcément un écho chez moi et je m’attendais à dire « encore un qui a tout compris, prenez-en de la graine ». Sauf qu’en fait, sans rire, le prochain qui écrit un truc pareil se retrouvera avec une malédiction sur 15 générations.
Le texte de Thomas prend fondement dans le fait que l’évolution technologique du salarié n’est pas le problème de l’employeur, et pour moi ça rend caduque toute l’argumentation.
(Attention c’est long) (suite…)
-
Recrute : Développeurs et développeuses PHP de talent
Attiré(e) par les défis techniques, vous êtes curieux(se), pragmatique, sociable, autonome et sensible aux questions d’architectures ouvertes et open source, vous êtes attaché(e) à réaliser des applications de qualité sur base PHP. Experts, confirmés et débutants. (suite…)
-
Recrutement : Développeur / développeuse HTML 5 et Javascript orienté mobile
Attiré(e) par les défis techniques, vous êtes curieux(se), pragmatique, sociable, autonome et sensible aux questions d’architectures ouvertes et open source, vous êtes attaché(e) à réaliser des applications de qualité orientées mobile sur base HTML 5 et Javascript. (suite…)
-
Recrutement : Développeur / développeuse PHP Magento
Attiré(e) par les défis techniques, vous êtes curieux(se), pragmatique, sociable, autonome et sensible aux questions d’architectures ouvertes et open source, vous êtes attaché(e) à réaliser des applications de qualité sur base Magento. (suite…)
-
Recrutement : Intégrateur / intégratrice web de talent
Attiré(e) par les défis techniques, vous êtes curieux(se), pragmatique, sociable, autonome et sensible aux questions d’architectures ouvertes et open source, vous êtes attaché(e) à réaliser des interfaces web de qualité.
-
Où doit-on mesurer la capacité réseau
Nos FAI tiennent comme à la prunelle de leurs yeux à leur obligation de moyen, par opposition à une obligation de résultat. Cette obligation de moyen a du sens quand on parle de questions techniques où les responsabilités sont multiples et où rien n’est tout blanc ou tout noir.
Toutefois, pour qu’une telle obligation de moyen fonctionne, il faut être capable de l’évaluer. À défaut on continuera à avaler des publicités pour du 24 ou du 100 Mb/s alors que la connectivité vers Youtube et les autres fournisseurs de contenu est trop mauvaise pour arriver à quoi que ce soit sur 5 Mb/s.
Le FAI ne contrôle pas tout l’Internet
Stéphane Bortzmeyer pose les bonnes questions. Mesurer le débit réel vers l’extérieur est difficile. « Le FAI ne contrôle pas tout l’Internet » et ne peut garantir une bande passante de bout en bout.
Je me permets de tout de même d’arrêter là l’exonération de responsabilité. Le FAI ne contrôle pas les débits une fois sorti de son réseau, mais il contrôle tout à fait à quel nœud ou quel opérateur de transit il fait transiter ses données. Charge à lui d’utiliser un nœud ou un opérateur efficace. Parfois le FAI n’a réellement aucun contrôle, mais parfois ça peut ne tenir qu’à changer de route.
Mais il n’est pas impuissant non plus
Si ça ne suffit pas, l’obligation de moyen c’est aussi de mettre en œuvre un peering raisonnable et bien dimensionné avec les gros fournisseurs de contenus, ou une connectivité plus directe. Parce que finalement je le paye bien pour ça mon FAI.
Il est un peu trop facile de se décharger « ce n’est plus ma responsabilité une fois sorti du réseau ». Si effectivement le FAI ne peut contrôler toutes les routes, la connectivité vers les réseaux principaux, vers les peerings, vers les fournisseurs de contenus majeurs, ne lui est pas étrangère.
Faire quelques mesures
Plus exactement si ça rame vers Youtube, Gmail, Dailymotion, Megaupload, Facebook, Flickr, TF1 ou je ne sais quel service majeur, votre FAI en est très souvent responsable. Si ça rame ailleurs chez votre FAI mais pas celui d’à côté, même sanction. Entendons nous bien, il ne s’agit pas de dire que le FAI est responsable d’un choix du fournisseur de contenu, mais il est responsable de ne pas faire remonter le problème, de ne pas utiliser ou faire utiliser des routes alternatives, de ne pas mettre en place un peering ou une connectivité directe, etc.
Faire des mesures de latence et débit vers une cinquantaine de gros hébergeurs fournisseurs de contenus, ça ne suffit pas (il ne faudrait pas segmenter Internet avec les gros d’un côté et les petits de l’autre) mais ça ne coûterait pas si cher et ça donnerait déjà des résultats intéressants.
En ajoutant pas mal de tests de petits sites, variables chaque mois, en relevant les FAI qui ont une connectivité sensiblement inférieure vers un réseau ou un autre, on finirait par donner une bonne image de ce qu’offres les FAI, non ?
Responsabilité, faute et mesure
Il faut tout de même noter que si je parle de responsabilité, je ne parle pas de « faute ». Il ne s’agit pas de dire que tel ou tel FAI est en faute. Par contre, du point de vue utilisateur, avoir un retour sur ce que sera la réalité de sa connexion me parait bien indispensable.
-
Déclencher le cache applicatif HTML 5 par javascript
Parfois je me pose des questions existentielles. Hier c’était de savoir si le cache applicatif de HTML 5 pouvait être activé dynamiquement par javascript lors de l’exécution de la page, au lieu d’être déclaré de façon statique dans le code HTML.
L’idée derrière cette interrogation est que le cache applicatif ne soit activé que sur certains critères (compatibilité du navigateur avec le code javascript utilisé, requête spécifique de l’utilisateur, etc.).
Petit test :
<!DOCTYPE html><html> <head><meta charset=utf8><title>TEST offline</title></head> <body><script> document.documentElement.setAttribute("manifest", "cache.manifest") ; window.applicationCache.update() ; </script><body> </html>
J’ai été agréablement surpris par Mozilla Firefox, qui accepte le tout sans broncher. La déconnexion permet de vérifier que le cache applicatif fonctionne sans heurs.
Mes espoirs se sont arrêtés là, Chrome déclenche une exception sur la mise à jour à seconde ligne de script. Il faut déclarer le cache de façon statique dans le HTML. Pas le choix, dommage.