Je viens d’installer un WordPress en lieu et place du vieux dotclear.
Dotclear ne peut plus se battre à la régulière contre WordPress, donc… Je rejoint la masse.
Les archives sont disponibles sur http://archives.tominardi.fr pour un temps seulement.
Alors que je pensais à la rédaction d’un article dont le titre serait Quel est le meilleur moyen d’apprendre à réaliser des sites Internet ?, j’ai réalisé que la question du pourquoi méritait un article à elle toute seule.
Cette image n’a rien à faire ici, mais j’avais envie de mettre une image de ma création.
Lorsque j’ai commencé à faire des sites Internet, en 1999 (putain, 12 ans…), la question ne se posait pas vraiment, tant la création de pages Internet était l’une des activités principales sur la toile.
Depuis, les années ont passées, une bulle internet a éclatée, les gros ont rachetés les petits, les expertises se sont créées, le web est devenu participatif alors on l’a surnommé web2.0, les blogs sont arrivé, les CMS aussi, ont a commencé à parler de SEO et de Google, de nouvelles technologies fascinantes ont conduit à ce qu’on surnomme le web web2.0, un boutonneux est devenu milliardaire en connaissant tout de vous, tout les concepts possible et imaginables ont déjà étés développés, et, récemment, de nouvelles technologies de pointe ont conduits les professionnels à surnommer habillement web2.0 notre espace virtuel préféré.
Pourquoi, dès lors, avoir besoin de savoir créer un site Internet ?
Si je reprend les raisons qui me poussaient il y a 12 ans à faire mes premiers sites, la réponse semble être « aucune ».
À l’époque, je voulais :
Pour commencer, j’aimerais rappeler qu’une page web statique (ou agrémenté de quelques include php) est encore une bonne solution, dans bien des cas. Pourquoi, pour une « bête » présentation professionnelle, calée au pixel prêt par un ami graphiste, perdre votre temps à créer ou modifier un template wordpress ? Créer un document HTML statique sera bien plus facile, et vous permettra un résultat bien plus proche de celui souhaité.
Considéré par beaucoup comme de la préhistoire, la production de pages HTML classique reste une solution qui a bien souvent des avantages.
Ensuite, parce que même en utilisant des CMS comme WordPress ou PrestaShop, il arrive toujours un moment ou on demande plus à l’outil, et ou on doit se dépatouiller pour faire fonctionner les choses, proprement. Et, à un moment, pas le choix, il faut regarder un peu de code source. On peut voir le cas par exemple avec les contenus libres dans les sidebar de la plupart des CMS. Ils laissent en effet la possibilité d’écrire du HTML qui sera interprété à l’affichage. C’est bien pratique pour intégrer rapidement du contenu, le formulaire d’inscription à une newsletter par exemple.
De plus, pour la personnalisation d’un thème, il est ambitieux d’imaginer se passer de CSS. Des millions d’utilisateurs de MySpace, à l’époque ou ce site contait encore autant d’utilisateurs, faisaient du CSS pour chaque modification de leur page perso. La plupart n’en avaient aucune idée et ne faisaient que copier/coller du code issue d’un générateur, mais l’essentiel était là, ces utilisateurs devaient faire du CSS pour modifier leurs pages, et nombreux sont ceux qui ont touché directement à leurs codes pour éditer une couleur. (et puis il y avait les autres, ceux qui réécrivaient 15 fois la même règle, mais on en parlera pas là…)
Quand aux CMS, il faut bien qu’il y ait des communautés pour les développer. Car même si, l’expertise aidant, on évite de réinventer la roue à chaque site, les technologies évoluent, les failles sont décelées, les besoins ne sont plus les mêmes, et une bonne partie des CMS étant open-source (mes favoris en tout cas), ils ont besoin de communautés pour continuer d’exister. Le sujet est le même avec des framework javaScript comme jQuery, dont le succès dépend en très grande partie d’une communauté active. Enlevez les centaines de plugins jQuery, développés par des utilisateurs lambda comme vous et moi, et le framework si populaire perd une grande partie de son intérêt.
Enfin, il reste une raison éthique. La publication de pages personnelles, de manière indépendante de toute organisation (même orientées logicielles libres), est à la base du principe d’échange d’Internet. Si demain les fondamentaux pour publier une page se perdent auprès d’un internaute technophile moyen (j’exclus de base l’internaute moyen, de toute façon aujourd’hui trop nombreux), c’est le principe même de décentralisation du réseau qui est mis en cause. Et c’est un danger dans pas mal de domaines, la créativité entre autre. Toujours cette même histoire de minitel2.0.
XML et JSON sont deux formats de données régulièrement utilisés dans le développement web.
Si le premier est encore le plus connu, parce qu’utilisé en masse depuis plus longtemps, le second fait ces derniers temps une percée fulgurante.
Dans beaucoup de cas, les 2 formats peuvent être utilisés aussi bien l’un que l’autre, sans réels différences de performances. C’est le cas pour un traitement de réponse Ajax, par exemple.
Alors comment se décider ?
De mon côté, j’ai tendance à privilégier JSON dans bien des cas. Celui-ci est basé sur la notation objet de ECMAScript (JavaScript), et peut être utilisé par la plupart des langages de manière équivalente à un autre objet (notation à point, ou à flèche pour PHP).
Cet argument vaut ce qu’il vaut, d’autant plus qu’aujourd’hui, des interfaces XML, comme Simple XML pour PHP, rendent la tâche également très simple pour ce format de données. Mais c’est comme ça que je me sent confort, quand je fait un simple
$monJSON=json_decode(‘monFichier.json’);
echo $monJSON->maValeur;
Pour autant, si je privilégie le JSON, je n’en oublie pas le XML.
En fait mon principal critère est : Quelle est l’intervention humaine possible sur ce fichier ?
JSON est beaucoup plus difficile à lire et à écrire/créer que XML, qui est un langage à balise. Si le fichier est généré par le programme, et qu’il est destiné à être manipulé par un programme, autant utiliser JSON. On aura par exemple, pour une réponse Sonic :
{
"retour":
{
"modifications":
[{"item":"instructions","content":" Vous pouvez cliquer plusieurs fois."}],
"ajouts":
[{"item":"laListe","content":"<li>Toujours plus de gras.<\/li>"}]
}
}
Ou doivent être les virgules ? Quand ouvre t-on les accolades ? Quand utiliser les crochets ? Quand la structure de l’information vient à se compliquer, il faut être très rigoureux pour ne pas perdre le fil. Ce genre d’information peut en revanche être générée très facilement via PHP (json_encode) et interprété tout aussi facilement par JavaScript (eval).
De son côté, XML est beaucoup plus simple à écrire. Voici par exemple à quoi pourrait ressembler le document ci dessus :
<retour> <modifications> <modification item="instructions" content="Vous pouvez cliquer plusieurs fois." /> </modifications> <ajouts> <ajout item="laListe" content="<li>Toujours plus de gras</li>" /> </ajouts> </retour>
Il est ainsi beaucoup plus aisé de créer son document XML à la main, et de le modifier.
Et donc, dans le cas, à priori rare, ou il faut créer ou modifier son document à la main, j’ai tendance à préférer XML.
Il existe sans aucun doute tout un tas d’arguments pour l’un ou pour l’autre, c’est une question de pratiques et d’habitudes. Je finirais simplement en remettant une couche sur le confort d’utilisation de données issues d’un JSON, ça en devient presque transparent pour le développeur.
Dans la même rubrique que « Pourquoi certaines personnes prennent elles Wikipedia pour un site d’actualité », voici mon expérience du soir.
Alors que j’étais sur un site à fort trafique, je suis tombé sur cet article :
Comme je suis curieux, je me dis qu’on doit trouver des informations sur cette « maison du moraliste ». A quoi est-ce qu’elle ressemble ? Quand a-t-elle été découverte ? etc.
Je me suis donc précipité sur un moteur de recherche à très fort trafique, et voilà les résultats :
Le premier résultat est le classique lien vers les actualités. Mais, les 3 premières pages de résultats (je n’ai pas été plus loin) ne sont QUE des liens d’actualités ! Il semble que Google ait laissé dans ses premières pages des liens récents uniquement, sans que cela lui pose problème.
Pour trouver mon information, il aurait fallu que je fasse une recherche excluant le mot « écroulé ». Autant dire que si je suis curieux, je n’ai pas toute la nuit devant moi…
Je n’ai pas fait l’expérience avec d’autre évènements de l’actualité, mais de toute évidence, dans un cas comme celui là, c’est les pages à forte « valeur » Google qui l’emportent, ici celle des médias, alors que les petits sites parlant d’archéologie ou de voyage qui auraient pu être cohérent doivent être cachés bien plus loin.
La pertinence, c’est pas un boulot facile…
.
Contact : tominardi (le a dans un rond) gmail (le truc qu'on met à la fin d'une phrase) com
--Soyez Content--