WebDev-FR

Associer Père Noël et Cloud Computing dans un titre d’article est particulièrement osé, je l’avoue.

Mais sous ce titre semblant sortir de l’esprit dérangé d’on ne sait qui (de moi en fait) se cache une vraie analyse de fond : le Père Noël fut le premier à pratiquer le Cloud Computing.

Éclaircissons un peu les choses…

La distribution de cadeaux a franchement évolué au cours des dernières décennies. Même si on s’imagine toujours le Père Noël comme un barbu quelque peu ventripotent (donc à priori jovial, j’ai peine à imaginer un barbu ventripotent grincheux) en survet’ rouge à fourrure blanche assis dans un traineau en bois tiré par X rennes (X variant de 2 à une douzaine en fonction des cultures et de la brochure marketing), il faut bien se dire que ce fantasme nourri par des hordes de publicitaires voulant nous pousser à la consommation est très probablement loin en deçà de la réalité.

Déjà, un traineau en bois, faut arrêter de planer. Vu la cadence que doit tenir le Père Noël, un traineau en bois ne pourrait pas encaisser les G lors des accélération pour aller d’une maison à une autre. Au premier départ le traineau volerait en échardes. En plus le bois, même traité, c’est pas tip top face aux intempéries que peut subir le Père Noël (surtout en cette saison). Vu la masse de cadeaux qu’il doit se trimballer, à moins de faire des aller-retours avec le Pôle Nord (peu probable), il faudrait un traineau monstrueux pour arriver à supporter le poids total. Vous rajoutez par-dessus tout ça quelques mouvements pour la sauvegarde des arbres qui risqueraient de lui coller un procès au cul et vous vous rendez compte que non, le Père Noël ne se trimballe plus dans un traineau en bois depuis longtemps.

Depuis l’invention du moteur à explosion, la révolution industrielle, etc, il est fort probable que le Père Noël fasse sa tournée à bord du dernier cri en matière de jets privés. Il est également probable que ce jet soit une petite merveille d’électronique embarqué afin d’arriver à larguer les bons cadeaux aux bons moments.

Parce que là où le Père Noël pouvait prendre son temps à une époque lointaine, aujourd’hui il est obligé de tout torpiller en un temps record. A cause de l’évolution de la société, la mentalité universelle “je veux tout et maintenant”, la révolution de la téléphonie mobile et des réseaux sociaux. La téléphonie mobile et les réseaux sociaux ? Et bien oui ! Aujourd’hui, si le Père Noël ne se met pas le turbo au cul pour faire sa distribution, il y a fort à parier qu’il va se faire tracer et n’importe qui pourra savoir exactement où il se trouve face à Twitter. Combien de temps a-t-il fallu pour que l’annonce de la mort de Mickael Jackson fasse le tour de la planète ? Si le Père Noël paraisse un peu, serait-ce pour faire une unique pause afin de manger un biscuit ou boire un verre de lait laissé là par un enfant (naïf, la faute aux publicitaires, cf plus haut), il est foutu. C’est un coup à se faire braquer par une bande de gamins de 5 ans. Que voulez-vous, après avoir appris que l’un des mots les plus recherchés par les moins de 7 ans est le mot “porn”, on ne s’attend pas à ce qu’ils fassent preuve d’état d’âme vis à vis du Père Noël.

Donc côté distribution, ça s’est fortement industrialisé.

En plus, avec la législation du travail, je ne serais pas étonné d’apprendre qu’il ne se déplace plus, que tout est automatisé. Avez-vous songé à quoi doit ressembler son contrat de travail ? La somme d’indemnités de déplacements qu’il doit toucher, même pour une unique nuit de travail doit être faramineuse. Plus les heures sup. Plus la prime de risque car voler de nuit, tous feux éteints (pour éviter de se faire détourner par des pirates de l’air), quelque soit la météo et à son âge (vue défaillante, peut-être des problèmes d’incontinence également). Non, d’un point de vue assurances et indemnités, son patron n’aurait pas pu suivre et ça aurait coulé leur business en un Noël.

La solution la plus simple aurait donc été d’investir dans la R&D afin d’automatiser tout le process. Avions drones, manufacture automatisée du début à la fin (ceux qui croient encore aux lutins qui travaillent en chantonnant peuvent aller se rhabiller, vous imaginez des lutins en train de monter une PS3 alors que le Japon fait ça via des chaînes de montage ?).

Ou alors de basculer vers du cloud computing. Le coeur de métier du Père Nöel, à savoir collecter les demandes, préparer les cadeaux et effectuer la livraison, est effectué dans le nuage. Au coeur du réseau. Le réseau de quoi ? Le réseaux des parents bien entendu ! Le Père Noël sous-traite son taf aux parents des gamins ! Il se charge de collecter les demandes (qui sont directement retournées aux parents vu que ce sont eux qui font les achats) et ça s’arrête là. En fait, le Père Noël n’est plus qu’un maillon du système : il vend son image et ne s’occupe plus du tout du business des cadeaux. D’un point de vue stratégie de groupe, ça a un vrai intérêt, ça évite de se disperser dans de multiples domaines au risque de perdre sa spécialisation et de se focaliser sur un seul métier.

Enfin bref, le Père Noël a pas mal changé. Je sais pas si c’est vraiment un changement positif, les nostalgiques diront probablement que c’est affreux.

Mais bon, les nostalgiques auraient l’air malin si on leur offrait un simili d’IPhone taillé dans du bois par un lutin sous-payé.

Que ça ne vous empêche pas de passer un Joyeux Noël et une bon début d’année 2010.

Via un billet posté sur le blog de Rebecca Murphey (découverte grâce au lancement de JSMag), je suis tombé sur une présentation de Nicole Sullivan concernant les bonnes pratiques à adopter lors du développement de la couche CSS d’un site, pratiques qu’on pourrait plus ou moins assimiler à de la conception orientée objet appliquée aux CSS.

Ce qu’il faut en retenir (ce que j’en ai retenu)

L’un des principaux problèmes des feuilles de styles est leur tendance à gonfler, gonfler, gonfler ce qui les rend plus coûteuse en bande passante mais aussi en maintenabilité (sans compter les risques liés aux styles s’écrasant mutuellement).

La raison est relativement simple : il n’est pas forcément évident de réutiliser des styles déjà existants. On a tendance à concevoir les règles CSS par rapport au contenu d’une page, éventuellement à réutiliser ce qui a été fait sur une page similaire si les similitudes sont flagrantes.

Nicole recommande une approche bien plus pérenne : séparer la structure et le design (ce qui ne veut pas uniquement dire avoir une feuille de style externe mais se baser sur des classes CSS et non sur des balises particulières) et séparer le contenu du contenant.

En fait, il vaut voir une bonne conception CSS comme un assemblage de Legos : commencez par créer votre collection de briques. Une fois que la collection de brique est prête, vous pouvez commencer à créer vos pages, autrement dit vous pouvez commencer à assembler vos briques ensemble pour aboutir au résultat graphique attendu.

Les 10 best practices qu’elle cite :

1. Créez une bibliothèque de composants
2. Utilisez des styles en accord avec la sémantique
3. Concevez des modules avec un fond transparent
4. Soyez flexible
5. Apprenez à aimer les grilles
6. Minimisez l’emploi des sélecteurs
7. Séparez la structure et le design
8. Séparer le contenu et le contenant
9. Etendez les objets en appliquant plusieurs classes sur un élément HTML
10. Utilisez des feuilles de style de reset et de gestion des polices

Et les 9 choses à éviter :

1. Evitez les styles dépendants de l’endroit où vous vous trouvez sur le site
2. Evitez de créer des styles qui dépendent des balises utilisées
3. Limitez l’utilisation d’IDs : ils doivent se limiter aux zones principales, pour le reste utilisez des classes
4. Fuyez les coins arrondis ou les ombres appliqués par-dessus des fonds non-unis (image de fond ou dégradé).
5. Evitez de faire un sprite contenant toutes vos images, à moins que vous ayez qu’un faible nombre de pages
6. Tentez d’éviter les alignements sur la hauteur
7. Le texte c’est du texte, pas une image contenant du texte
8. Evitez la redondance
9. Evitez l’optimisation prématurée

Maintenant si on va un peu plus dans les détails pour certaines parties…

Séparez le contenu du contenant

Ca veut dire qu’un module est composé :

• d’une brique pour la gestion de la bordure (coin arrondis ou carrés, couleur, ombre)
• d’une brique pour le fond (fond uni, image de fond en filigrane, dégradé)
• d’un ensemble de briques pour le contenu

Autrement dit, un module devrait avoir 3 classes afin de définir à quoi doit ressembler sa bordure, quel est le fond à appliquer et comment le contenu doit être organisé.

Séparez la structure et le design

Prévoyez à l’avance la structure basique d’un bloc : faut-il un header dans un bloc ? faut-il un footer ?

De cette manière, créer un bloc se limitera à appliquer les bonnes classes (”block”, “hd”, “ft”, “bd”) au contenu du block.

Une fois que cette structure est définie, vous pouvez alors concevoir les différents design qui s’appliqueront sur cette structure : une brique avec des coins arrondis, une brique pour gérer le fond en dégradé, etc.

Faites des modules transparents

Si vous voulez des coins arrondis, préférez une solution où le coin est créé par l’extérieur et non par l’intérieur, autrement dit une solution où l’image du coin est transparente à l’intérieur et unie à l’extérieur. Cette solution vous permettra d’appliquer n’importe quel fond à l’intérieur de votre bloc, que ce soit une couleur unie ou une image en arrière-plan.

Bémol : le bloc ne pourra être placé que sur un fond correspond à la couleur extérieure de vos coins arrondis (typiquement le fond de votre page).

Soyez flexible

Faites de la gym. Faites en sorte que vos briques puissent s’adapter en largeur et en hauteur. En hauteur pour pouvoir s’adapter à la hauteur du contenu, en largeur pour pouvoir réutiliser votre brique dans n’importe quelle zone de votre grille même si la largeur varie.

C’est la grille qui doit gérer la largeur, les blocs doivent ignorer pour quelle partie de la grille ils ont été conçus.

Tentez une approche UML

Tentez de mettre en place un système d’héritage à vos briques.  Certaines briques seront compatibles ensemble (par exemple certaines briques de gestion de bordure ne pourront pas forcément être appliquées à n’importe quel brique d’arrière plan ou même de mise en forme du contenu).

Ces relations entre vos briques peuvent donner lieu à un schéma plus ou moins UML pour faciliter la compréhension des briques existantes.

Un exemple d’approche UML conçue par Nicole :

Approche UML pour la couche CSS d'un projet

Bref, plein de bonnes suggestions à tenter de mettre en pratique…

Changement du thème du blog pour adopter un thème (très connu) plus classique pour un blog plutôt que le précédent affichage sous forme de vignette en homepage.

Il reste quelques soucis par rapport aux exemples de code, mon module de coloriage syntaxique est pas très adapté, je vais le changer…

Dans son livre Object-Oriented JavaScript, Stoyan Stefanov propose pas moins de 12 méthodes pour mettre en place de l’héritage en JavaScript.

Nous allons reprendre ces méthodes une à une afin d’en lister les avantages et les inconvénients… Nous allons réutiliser l’exemple de Stoyan pour montrer la syntaxe de chaque méthode : son exemple consiste à mettre en place un héritage entre trois classes FormeGeometrique, FormeGeometrique2D et Triangle.

Cet article est divisé en de nombreuses pages, chaque page traitant une méthode d’héritage différente.

• Chaînage de prototype
• Héritage des propriétés partagées uniquement
• Utilisation d’un constructeur temporaire
• Héritage par copie de propriétés
• Copie en Surface
• Copie en profondeur
• Héritage par prototypage
• Mélange d’héritage par prototype et de copie de propriétés
• Héritage multiple
• Héritage par Parasitage
• Emprunt de constructeur
• Emprunt de constructeur et copie de son prototype
• Conclusion

Le gros problème de Silverlight, c’est qu’il nécessite un plugin sur le navigateur du client pour fonctionner.

Pour éviter ce désagrément, l’auteur de pleased precariously propose une librairie JavaScript appelée Firelight (toujours en cours de développement) dont le rôle est de prendre du XAML et du WPF en entrée et de générer à aprtir de ça du SVG / JavaScript / DOM équivalent.

Une petite démo ? ça se passe ici (fonctionne pour l’instant sous Firefox 3.x, Safari 3.1.2 et sous Ipod).
La démo se base sur ce fichier XAML.

A force de lire des blogs en anglais sur le développement web, on finit par se dire que ça pourrait être pas mal de lancer son propre blog pour enrichir un peu plus la communauté française gravitant autour de ce domaine…

A l’heure actuelle, le web bouge très très vite. Déjà du côté des navigateurs avec des acteurs variés et proposant des applications à fort potentiel. Le monopole d’Internet Explorer s’effrite petit à petit et nous sommes dans les balbutiements d’une nouvelle guerre de navigateurs, en particulier depuis que Google a annoncé son entrée sur ce terrain de jeu.

Mais ça bouge aussi du côté du développement, même sur des technos ayant plusieurs années : le lent abandon des vieux navigateurs a obligé les développeurs à conserver une compatibilité avec de vieilles technos et à limiter l’utilisation de versions plus récentes. On utilise toujours les vieilles marmites mais on a appris à les maîtriser, à en connaître la moindre imperfection. On peut le voir par exemple avec l’explosion de l’Ajax il y a quelques années ou encore l’actuelle panel de frameworks JavaScript pour enrichir et faciliter la création d’une interface.

Bref ça bouge beaucoup, ça bouge très vite et il n’est pas forcément évident de suivre tout ça.

Alors voilà, le blog est lancé, pour le meilleur comme pour le pire. Il sera avant tout orienté sur le front-end et plus particulièrement sur le JavaScript et les CSS, deux technos qui me font frétiller les neurones au quotidien.

J’espère que les articles et les tutoriaux vous plairont et que vous pourrez trouver ici des informations qui vous seront utile dans vos réalisations de tous les jours.

Loïc