deniscope

Aller au contenu | Aller au menu | Aller à la recherche

2014 fév. 1

MediaEntity de Émilie et Simon

Titre: MediaEntity
Auteur: Émilie et Simon
Catégorie:bd ado
Avis éclair: J'aime
Détail technique: Première bd avec de la réalité augmenté
Citation: "Nous jurons de trouver tous les infectés du monde et de leur montrer le chemin vers la liberté"

Ma critique:
Plus qu'une bande dessiné c'est tout un univers, une communauté qui a été créé autour de cette histoire. La bande dessinée est accessible sur le net ici: http://www.mediaentity.net/ , on peut évidemment l'acheter en papier (ce que j'ai fait) et profiter des contenus en réalités augmenté (c'est très bien fait). L’histoire est sympa, c'est bien ancré dans notre société numérique. Les personnages sont intéressants, j’attends la suite (le 4ieme et dernier volume doit sortir au printemps 2015).

2013 nov. 9

La fin de javascript ?

Aujourd'hui javascript est un langage incontournable pour la construction d'un site web même modeste. De plus en plus utilisé, possédant une grosse communauté de développeurs, javascript a le vent en poupe et on trouve maintenant de nombreux frameworks l'utilisant. Et pourtant. Pourtant, si on regarde quelques années en arrière, javascript était déjà présent dans les pages internet. Plutôt alors réservé aux développeurs expérimentés, il était souvent délaissé au profit de technologies lourdes (java ou flash) pour rendre "dynamique" une page. L'internet grandissant, les navigateurs ont également évolué. Ce qui prenait plusieurs kilos de lignes de code javascript avant, peut aujourd'hui s’exécuter en quelques instructions. Cela a pris du temps, le marketing aidant, on a même pu nommer les différentes périodes de cette évolution (DHTML, Ajax, Web2.0...) et petit à petit des choses se sont mises en place. Ces choses vont toutes dans le même sens : une mise en œuvre plus rapide et plus soignée du modèle MVC (Model View Controler).

Aujourd'hui toujours, javascript a beaucoup de mal à trouver sa place dans le système MVC. Trop souvent employé pour le 'V', heureusement rarement pour le 'M', il ne devrait apparaitre que dans le 'C', et encore. La prochaine grande évolution du web ne semble laisser que peu de place à un langage tel que javascript. Déjà HTML5/CSS3 remplacent avantageusement certains frameworks d'animation d'éléments visuels. Combien de temps faudra-t-il au web pour pouvoir se passer de javascript ?

La grande force d'un langage client puissant et d'une "bidouillabilité" exceptionnelle est qu'elle permet de faire une foultitude de choses d'une foultitude de manières. Mais le développement du web est aussi (et avant tout) un milieu réservé à des professionnels. Avec l’essor de l'internet mobile, les périphériques se multiplient et donc les clients web qui poussent vers une normalité des pratiques car il est toujours plus facile d'interpréter une norme selon ses spécificités (petit écran, tactile, noir et blanc...) plutôt que de compiler un code souvent complexe pour finalement seulement se rapprocher du comportement voulu. C'est pourquoi, même s'il sera toujours amusant à utiliser, le javascript devrait, en toute logique, disparaitre peu à peu de nos clients web.

2010 janv. 24

Les petits secrets de nos navigateurs: Partie 7

BrowserShot printscreen

Commentaires conditionnés

Le secret du jour n'est pas vraiment un secret puisqu'il s'agit d'une technologie liée à Internet Explorer que l'on appelle les conditional comments.

Je me rappelle la première fois où j'avais vu une page utilisant cet techno, j'avais trouvé la chose on ne peut plus "crade". Bon cela dit, je n'ai pas vraiment changé d'opinion sur ce genre de pratique qui consiste à utiliser quelque chose d'existant (ici, les commentaires) et de les bidouiller pour complétement en changer la nature (ici, ajouter un filtre à navigateur).

Comme nous le montre le test 7, cela ne fonctionne que sous IE (et pour cause, c'est une techno propriétaire) et on peut d'ailleurs voir avec le test browsershot que cela ne fonctionne qu'à partir d'IE 5.

Je n'ai rien a ajouter sur ce secret, si ce n'est qu'une fois de plus c'est le navigateur Internet Explorer qui se distincte des autres.

2009 juin 11

Les petits secrets de nos navigateurs: Partie 4

BrowserShot printscreen

Absolutely URL

Je m'apprête à écrire mon quatrième "petit secret de navigateur" lorsque je m'avise de n'avoir pas encore définit le terme. Pallions donc ce grave manquement.


> "petit secret de navigateur":
(expression)
  1. Comportement inattendue d'un navigateur pour une situation qui ne l'est pas moins (inattendue).
  2. Action surprenant d'un navigateur devant une situation d'exception (rare).

Oui, je suis bien conscient que ce genre de définition n'aide pas vraiment, et je vais donc passer à l'exemple qui n'est rien de moins que le secret numéro 4. Voyez vous même dans l'image ci-dessus, à une situation burlesque, certain navigateur donne un résultat inattendue.

Résultat du test 4 avec Internet Explorer

Vous l'aurez sans doute comprit, le secret numéro 4, qui a également sa propre page test, concerne les url relatives. Si le rectangle vert apparait, c'est que l'url est correctement interprétée. Je ne m'étendrais pas plus sur ce secret tellement il est simple, je vous invite à voir les résultats browsershots ci-dessus.

2009 mai 22

Les petits secrets de nos navigateurs: Partie 3

BrowserShot printscreen

Une livre sinon rien

Lorsqu'un navigateur communique avec un serveur, ils utilisent des codes pour être sûr de bien se comprendre. Ces codes sont naturellement les mêmes pour tous et ne permettre guère l'improvisation. Il n'en reste pour autant pas moins qu'une requête HTTP (car c'est bien de cela qu'on parle) peut être constitué d'une entête et de données. En règle général et sauf contre ordre, les navigateurs affiches les données quelques soient le code envoyé.

Pour illustrer ces communications, j'ai créé une petite page test avec les principaux codes HTTP. Comme le montre le détail de la page test ci dessous, chaque code est appelé deux fois. La première fois (à gauche) avec peu de donnée, la seconde (à droite) avec plus de 512 octets de donnée, les deux pages affichant un carré vert.

Code HTTP 200 OK, zoom

Alors pourquoi cette limite des 512 octets? Et bien c'est là que réside le secret (et le jeu de mot foireux du titre également). Si vous regardez de plus près le résultat donné par le site broswershots (ci dessus), le navigateur Internet Explorer réagit différemment aux réponses HTTP en fonction du nombre d'octet envoyé. J'avoue que même si vous pouvez cliquer sur l'image des résultats pour zoomer, la chose n'est pas flagrante, c'est pourquoi, dans ma grande mansuétude, j'ajoute une copie d'écran (ci-dessous) d'une partie de la page test sous Internet Explorer. Détail des résultats d'Internet Explorer Encore une fois, Internet Explorer se démarque des autres navigateurs par un comportement que je n'arrive pas vraiment à comprendre. Concrètement, Internet Explorer n'interprète les données envoyées seulement si elles sont assez nombreuses...

Vous avez une explication?

2009 mai 20

Quand l'ergonomie tue l'ergonomie

Durant mes éparses études, on m'a appris que l'ergonomie était la science qui adaptait les choses à l'Homme (avec un grand H comme dans Femme). Les sites, en règle générale, regorgent de fonctionnalités ergonomiques et bien pensées qui font que nous, pauvres humains, arrivons à les utiliser.

Une petite astuce ergonomique bien connue consiste à rediriger un utilisateur qui utilise un navigateur français (ou autre), vers le site français (ou autre). Cela ne vaut bien entendu que pour les gros sites internationaux qui ont une couverture en plusieurs langues. C'est pratique et ergonomique.

Par contre, à trop vouloir bien faire, parfois, on obtient l'effet opposé à celui escompté. C'est le cas d'AOL. Si vous utilisez un navigateur français (par exemple) et que vous contactez la page aol.com, vous allez automatiquement être redirigé sur la page d'accueil française, et c'est bien. Par contre, vous n'avez pas du tout la possibilité d'aller sur aol.com qui est la page états-unienne d'aol. Même en cliquant sur le lien disponible pour s'y rendre, vous allez encore et toujours être redirigé, ce qui est vraiment mal. Cela mériterait presque un bannissement à jamais de ce site pour faute grave. Cela dit, je ne vais jamais sur aol.

2009 mai 9

Les petits secrets de nos navigateurs: Partie 2

BrowserShot printscreen

No comment

S'il y a quelque chose dont les bloggeurs sont friands, c'est bien des commentaires. Mais cela n'a rien à voir avec notre sujet, je ne parlerais pas des commentaires de blog (même si je les apprécie) mais bel et bien des commentaires HTML.

Un commentaire HTML débute par les caractères "<!--" et termine par "-->", voilà pour la théorie.

Comme je suis joueur, j'ai essayé plusieurs autres façons d'écrire des commentaires sur cette page test. Lorsque le carré rouge apparait, c'est que le commentaire n'est pas pris en compte.

Les tests sont les suivants:

<!--   -->   <!--   --!>
<!--       <--   -->
<!-   -->   <!--   ->

Comme vous pouvez le constater sur l'image des résultats ci-dessus (toujours obtenus grâce au service en ligne BrowserShots), les commentaires HTML n'ont pas toujours le comportement auquel on s'attend.

Si vous oubliez de refermer votre commentaire, ou si vous le fermez mal (selon les navigateurs), il sera automatiquement fermé au prochain caractère supérieur (>) de votre page. Pour reprendre une expression des expressions régulières, on pourrait dire que les commentaires HTML sont "non greedy" (ou "lazy"). C'est à dire que si le tag de fermeture (-->) n'est pas trouvé, le navigateur fermera "au plus tôt" le commentaire, en l'occurrence au prochain caractère supérieur (>).

Cela laisse sans voix non? (ou plutôt sans commentaire).

2009 avr. 27

Les petits secrets de nos navigateurs: Partie 1

Si Champollion m'était conté.

browsershot1.jpg On a tous nos petits secrets, des comportements inavouables que la décence nous fait cacher aux yeux du grand public. Mais voilà, Internet n'est pas constitué seulement du grand public et, immanquablement, tout secret finit par être percé et exploité. Regardons de plus prêt une méthode javascript largement utilisée sur le web: document.write.

Si je me fis à cette documentation en ligne, il est dit:

Do not use the write method or the writeln method on the current document after the document has finished loading unless you first call the open method, which clears the current document window and erases all variables.

Comme je suis taquin, j'ai écrit une petite page pour vérifier cette information. Cette page est constituée de deux pages tests. Chaque page test est constituée d'un gros carré rouge et d'un appel à une méthode qui écrit un gros carré vert. Seul l'appel à cette méthode n'est pas placé au même endroit. Voici le code de la méthode:

 function beGreen(){
     document.write('<div style = "width: 100%; height: 100%; background: green" />');
     document.close();
 }

La première page test appelle la méthode document.write juste après le chargement de la page.

window.onload = beGreen;

L'effet est immédiat, le gros carré vert apparait.

La seconde page test est un peu plus complexe. Le code est également situé dans l'événement onload mais ressemble à ca:

window.onload = function(){    var obj=document.createElement("script");obj.src="onload.js";document.body.appendChild(obj);}

On construit un élément SCRIPT dont la source sera onload.js qui lui contient exclusivement un appel à la méthode beGreen. L'effet n'est pas si immédiat, mais le gros carré vert apparait tout de même, mais... Mais le gros carré vert n'apparait curieusement pas avec tous les navigateurs.

En utilisant l'excellent service en ligne BrowserShots sur la page test, vous obtenez les résultats présentés sur l'image ci-dessus (vous pouvez cliquer sur l'image pour la voir en plus grand). Que passa? Il y a encore du rouge avec les navigateurs Internet Explorer? Pour des raisons qui m'échappent Internet Explorer se refuse à écraser le document sur la seconde page test. Alors pourquoi? Et bien, pour tout dire, je n'en sais rien...

2009 avr. 20

izzyway.com, tech'it izzy

izzyway Il ne vous a surement pas échappé qu’izzyway était un peu partout dans ce site. Je n’ai pourtant pas réussi à garder les services que j’avais mis en place il y a deux ans. Il y a une telle pollution dans les envois d’email que les emails envoyés à cette époque n’arrivaient jamais à destination, bloqués par un serveur zélé qui les considérait comme SPAM.

Aujourd’hui izzyway existe toujours et propose des services un peu moins sophistiqués mais rigolos tout de même (pour ceux qui ont de l’humour).

  • Server Information : Cette page résume les principales informations qu’un serveur peut utiliser quand vous, client, vous le contactez. Sinon vous pouvez toujours utiliser BrowserHawk qui est bien plus exhautif.
  • Navigation introspection : Ce service énumère les différents objets fournis par votre navigateur, il détaille également les méthodes et les propriétés. Cela peut être utile pour comparer les différents navigateurs.
  • Broken links : Ce service permet de lister les liens défectueux d’un site ou d’une page. Exactement ce que propose aussi Link checker en somme.
  • HTTP Method: Le service, que je trouve le plus marrant, permet de créer une requête http et de l‘exécuter. La requête sera exécuter du serveur (free) et la réponse sera alors affichée sans aucune modification (même les chunks apparaissent tels quels).

Le site est en anglais car j'adore me la péter.

J’ajouterais sans doute, au fil du temps, des nouveaux services.

2009 avr. 16

Silverlight, la lumière est belle

On peut dire que Microsoft sait trouver les arguments pour augmenter les utilisateurs de Silverlight. Cela s'appelle PlayboyArchive, ça ne fonctionne qu'avec le plugin Silverlight et ça porte bien son nom ("PlayboyArchive" pour ceux qui suivent pas). Bon évidemment ce n'est pas directement lancé par Microsoft mais c'est tout de même un joli coup marketing.