Catégories: "Media Web"

Charset conversions (i18n)

Yesterday, I came accross this interesting table which lets me know what conversions I need to do when I paste text from Word into a textarea and further want to use this text on the web...

To be accurate, this table is useful for conversion from the default windows charset (windows-1252 aka CP1252) to the default web charset (ISO-8859-1 aka Latin-1). Nethertheless, this allowed me to check the conversion in my b2evolution software and I noticed that it was missing one conversion (in a total of 27).

Anyway, the world actually extends way beyond cp1252 and Latin-1, so how would one deal with other languages? :?:

For example, how do I convert Latvian from Windows-1257 to iso-8859-13 (close match) ? Or Russian from Koi8-r to iso-8859-5 (funky match) ? Check out this awesome character set database provided by the Institute of the Estonian Language. (Wouldn't it make sense if unicode.org provided this? :crazy:)

By the way, how do I know what charsets are to be used for a particular language? Here's a page by the W3C, but it's a little sparse... Another one.

Webservices: pour quoi faire?

Le petit monde des technologies de l'information aime les buzzwords. Il y a eu une époque où tout le monde disait "Network Computer" autant que possible, il y a eu une époque ou "Java" devait figurer dans tout white paper ou business plan qui se respecte, il y a eu l'époque "XML", il y a eu l'époque "Open Source"...


En ce moment, l'un des mots à la mode est "webservices"... mais comme toujours, la plupart des gens qui en parlent ne savent pas vraiment ce que c'est... :>>


Bon, il faut dire aussi qu'on nous rabache systématiquement les mêmes exemples peu parlants... Dans la presse vous pouvez lire que grâce aux webservices un site web de voyages peut communiquer en temps réel avec les centrales de réservation de la compagnie aérienne ainsi que celle de l'hôtel où vous allez afin de vérifier en direct la disponibilité de votre séjour tout compris. Ca vous parle? :lalala:


Dans les tutoriaux, vous tomberez inévitablement sur un autre exemple parfaitement grotesque: comment envoyer deux nombres vers un serveur distant qui nous retourne en échange la somme de ces deux nombres! 8| Ou encore: envoyez le numéro d'un département et recevez en retour le nom du département... :|


Okay, à mon tour d'ajouter mon petit grain de sel et de tenter d'apporter des exemples plus parlants... ;D

Post complet »

Syndication, RSS, RDF and Atom in a Nutshell

Once upon a time, there was a company called Netscape who was investigating a new market: portal sites and content syndication. The idea was simple: a variety of websites produce relevant content in a (nearly) continuous flow. Portals would be designed to aggregate news and content from those sites and present it to the user all in one page…

Thus, Netscape invented a format called RSS, which stood for “Remote Site Syndication". This spec allows content producers to publish their news/content in an “RSS feed” (an XML based document) and content consumers to periodically check those feeds for updates.

When Netscape lost interest in developing portals, they abandonned their original (and complex) RSS 0.9 spec as well as their efforts in creating a more appropriate and simpler version. At that time, UserLand picked up the simpler 0.91 spec and applied it to its blog tools. RSS had become “Really Simple Syndication".

Today, the blogging community still uses RSS extensively: every (serious) blogger publishes an RSS feed of his posts and readers aggregate all their favorites blogs’ feeds in an aggregator. This, of course, makes it more convenient to check for new posts daily on all your favorite blogs…

b2evolution is an example of a blog tool used to publish RSS feeds. SharpReader is an example of a program used to aggregate RSS feeds.

Full story »

(I don't believe in) Web Standards (no more... but I wish I still had faith!)

"Web Standards"... that definitely sounds cooler than it really is...

At first we had HTML and Mosaic... Then came Netscape and Microsoft with their proprietary extensions... and so came the need for standards. We got several versions of standardized HTML, but still varying implementations (IMG align anyone?).

Then came some "really really" standard method to iron out rendering differences: Cascading Style Sheets! Well... another failed attempt: people tweak them even more than standard HTML and the rendering differences get even worse. So now, we have a collection of dirty tricks to apply different CSS to different browsers.

Okay, forget that; we have an even newer standard now: XSL. You just send pure and clean XML to the browser. Then you let the browser reformat it with an XSLT template. PLEASE! XSLT implementation differences are just as problematic as with CSS... and finally no more than with plain HTML! And regarding IE, it's definitely too slow to be really useful! >:XX

So today, I really wonder why we go through all this pain... Sending different presentations in plain HTML (okay, let's say XHTML+CSS for bandwidth and maintainability optimization) was faster than desperately trying to find the "compatibility spot" in a single "standard compliant version"! :|

Not to mention there are still old browsers that do not support a lot of standards out there... and there are more and more alternative browsers (on either desktops, appliances or mobile devices...) that all support standards in their very own way! :(

What can we do? I mean pragmatically! Apart from condemning everyone that doesn't comply 100% to the standards (just a few millions anyway...).

I think we need to remember those "best practices" we had a few years ago and get back to something like this:

  1. Identify most common targets (browsers/devices) and provide them with a specific+optimized presentation (CSS/Flash/whatever). The more targets you can handle with compatible web standards, the better. But don't forget to test all those targets! You'll undoubtly encounter nasty surprises on some of them... Note: contrary to popular belief, most common targets and their "market share" largely depend on your audience!
  2. Provide at least one "safe" presentation. One that is guaranteed to be readable by almost anyone. Alternatives would be good here: maybe one text only (HTML 2.0) and one with basic CSS and images that makes it just a little more attractive (but still avoiding any CSS/Flash showing off!)
  3. Provide a manual switch between version for the times when the user uses a browser that can do more or less than we had expected. (It would be wise to always bet on less, but you'll inevitably make false assumptions at some point.)

Okay, so what's new here? Those of you running corporate sites might think they already do that. You may want to check again: are you sure you didn't stop at step 1? :?:

Now, for personal sites... I completely realize that providing multiple versions will sound like crazy to many of you. How can I expect you to update content concurrently in several files? Well... I don't! Any hosting provider nowadays will let you use dynamic page generation (one content, several presentations). I'll get back to this topic later...

Industrialisation du web: un exemple

Pour bien fixer les esprits, je vais prendre un exemple proche de nos préoccupations quotidiennes de bloggeurs ;D : la vérification des referers.

Si vous enregistrez le referrer de chaque requête dans le but de l'afficher dans vos stats publiques, vous vous êtes sans nul doute déjà confronté au besoin de vérifier que le référant pointe bien vers votre site avant de le valider, ceci afin d'éviter le "referer spam". Il en est de même pour le comment spam.

Pour ce faire, vous devez déclencher une "contre requête" HTTP afin de récupérer et analyser la page référente. Cette opération est longue et ralentit d'autant le traitement de la requête d'affichage de votre page.

Certes, vous placerez judicieusement cette requête à la fin de votre page et déclencherez l'envoi de la page vers le client avant de commencer l'opération de vérification. Mais la connexion HTTP reste ouverte et le browser client indique qu'il continue de charger. A la limite, un utilisateur lambda pourra ne pas s'en rendre compte. En revanche, un robot d'indexation aura vite fait de classer votre site dans la catégorie des mammouths lents à la détente et donc à ne pas indexer trop fréquemment.

La chose se complique encore dans le cas d'un traitement plus évolué tel que l'enregistrement d'un nouvel article. Non seulement vous allez le stocker dans la base de données locale mais vous allez déclencher toute une série d'opérations en "cascade". Exemples:

  • Génération de pages statiques
  • Trackbakcs
  • Pingbacks
  • Pings de mise à jour d'annuaires
  • Envoi de mails aux abonnés
  • Syndication en mode PUSH

(Liste non exhaustive... :>>)

Avec une plateforme web basique (type PHP, ASP, etc...) vous laissez mouliner et vous partez boire un café (si vous êtes moins feignant, vous ouvrez une autre fenêtre). Bien évidemment, vous pouvez bidouiller. Qui a dit "pop-under"? Mais ce genre de solutions où l'on compte sur les capacités de scripting du client pour assurer la cohérence des traitements sur le serveur est vraiment tout sauf recommandable. >:XX Tout celà reste acceptable dans le cadre d'un site web perso (et à budget limité), pas dans un contexte professionnel, ni avec un minimum d'ambition.

Une plateforme telle que J2EE (à ne pas confondre avec un simple script Java) ou .NET (à ne pas confondre avec un simple script ASP) permet de traiter ce type de problème de manière tout à fait élégante.

Pour faire simple et parce que ce post commence à être long, tous les traitements énoncés ci-dessus vont être passés à une (ou plusieurs) file de messages. Cette "message queue" fera exécuter les traitements annexes et non "urgents dans la seconde afin de répondre à la reuqête" par un composant dédié à cette tâche et travaillant de manière asynchrone.

Un autre exemple est le déclenchement sans intervention de l'utilisateur de tâches telles que l'envoi d'emails de résumés quotidiens, la réindexation périodique ou encore la génération de snapshots statiques à intervalles réguliers.

Alors évidemment, les message queues et les traitements asynchrones peuvent parfaitement cohabiter à côté de technologies que j'ai qualifiées de "basiques" telles que PHP. Mais on est déjà là en train de construire une plateforme plus évoluée qui n'a plus rien à voir avec ce que l'on trouve chez un hébergeur low-cost par exemple. C'est le début d'une grosse machinerie... et on aura vite fait de préférer une machinerie standardisée, documentée et maitrisée par un certain nombre de personnes (J2EE, .NET) plutôt qu'une machinerie propriétaire, issue d'un individu isolé, aussi géniale soit-elle.