fplanque: Techno

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.

Mon coeur de métier c'est la conception et le développement de systèmes d'information. Mais c'est quoi, au fait, un "système d'informations"?

Si vous aussi vous trouvez que c'est une notion un peu abstraite, voici la définition que je donne habituellement pour tenter de clarifier: ;)

On peut prendre comme point de départ un site web. Tout le monde connait les sites webs. Des sites tels que celui de la sncf, de la fnac, de météo france ou même celui des impôts... :roll:

En fait, ces sites web ne sont que la partie visible de l'iceberg. L'iceberg, ici, c'est le système d'information. Ce système reçoit et centralise des informations provenant de différentes sources. Il peut s'agir de références et caractéritiques de produits, d'horaires, de données météo, de commandes, de transactions financières ou plus généralement de textes, tableaux, images et même vidéos... (on peut alors parler de systèmes d'information multimédias).

Toutes ces informations, le système les traite, les transforme, les stocke puis les redistribue en fonction des besoins des utilisateurs et sur différents canaux...

Ces dernières années, les canaux privilégiés étaient le web et l'email.

Il y a une dizaine d'années c'était, le Minitel.

Dans les années à venir, les canaux privilégiés seront sans nul doute à destination des terminaux mobiles tels que téléphones portables et ordinateurs de poche. Le SMS est un exemple de technologie déjà largement utilisée dans ce domaine.

On peut également s'attendre à un développement de la télévision interactive grâce à l'ADSL.

Alain Lefebvre dans JDNet:

Je n'ai pas peur d'affirmer que Firebird est le browser Web tel qu'ils devraient tous être : léger, propre, bien fait, focalisé sur ce qui est utile et raisonnablement personnalisable. La fonction de blocage des pop-ups n'est pas anecdotique, elle est tout à fait significative de l'avantage majeur que possèdent désormais les projets Open Source par rapport aux équipes commerciales : ils ne sont pas entravés par des conflits d'intérêts et eux travaillent vraiment à améliorer le confort de l'utilisateur.

When you develop a piece of software or a website up to a certain point, there comes a time when you try to reach an international audience.


No doubt your first move will be to provide an English version of your software or website.


However, you will soon realize this is not enough. Of course, many people do understand English to some extent; but you have to realize how painful it can be for them. Maybe you don't even realize how easily you can understand English compared to the average. Of course, if you are yourself a native English speaker, you need to try and imagine that every software you use comes in French or German by default! How would you feel about that? :P


Furthermore, you may have spent some time on making your software or website accessible. Users can now change the font size and enhance contrast if they have trouble reading those lines of funky rendered text... That's fine... but what's the use if their problem is not with the formatting but with the language!? :?:

Read more »

Via David Watson:

This is the first instance of a training class targeted at businesses who want to use blogging to improve communication.