Un Electron Libre...

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

WWW, NTIC & Co

Fil des billets - Fil des commentaires

vendredi 1 février 2008

Rachat de Yahoo! par Microsoft : vers un début de web libre ?

Par NiCoS le vendredi 1 février 2008, 21:28

Disclaimer : Non non, je ne suis pas tombé sur la tête avec ce titre, il faut lire jusqu'à la fin...

La nouvelle est tombée un peu partout ce jour : Microsoft prévoit une OPA sur Yahoo! pour 44 milliars de dollars. Jolie valorisation de Yahoo! (dont l'action a pris +50% environ dans la journée).

Les impacts d'une telle OPA (opération purement financière s'il en est et unilatérale) sont loin d'être négligeables sur l'écosystème du web :

  • Grosse concentration en perspective dans le secteur de la recherche, des régies publicitaires, des services (Y! Messenger/Live Messenger, Y! Mail/Hotmail, etc). D'ailleurs on peut se poser la question de l'acceptation d'une telle opération par les entités veillant au bon fonctionnement de la concurrence des deux cotés de l'océan...
  • Grosse concentration en matière de données : c'est plusieurs millions de données qui arrivent dans le giron de Microsoft. Ils auraient tort de ne pas l'exploiter d'une façon ou d'une autre.
  • Microsoft va-t-il maintenir les services Yahoo! ? les fusionner ou bien tuer les services Yahoo! pour imposer les siens ? Il ne serait pas étonnant de voir soit Microsoft prendre les services Yahoo! pour lesquels il n'a pas d'équivalent ou pour lesquels sa position actuelle est faible et au contraire tuer les produits Yahoo! pour lesquels Micorosft a une place de choix (migrer Y! Messenger vers Live Messenger par ex ou encore "encourager" les clients Zimbra à repasser sur une plateforme Exchange (certains doivent se mordre les doigts de s'être lancé dans une telle migration, surtout que Zimbra n'est pas un logiciel libre - certains utilisateurs réclament que Zimbra passe sous GPL avant le rachat effectif)
  • Microsoft met la main sur des services emblématiques du "web 2.0" comme del.icio.us ou Flickr - Sans oublier que Microsoft cherche aussi à se placer dans Facebook. Le monopole web de Microsoft pourrait être sur le point de prendre forme pour succéder au monopole logiciel ??
  • Les ingénieurs Y! vont-ils rester dans cette nouvelle entité ou va-t-on assister à une fuite des cerveaux ? Google va-t-il les récupérer ?
  • Yahoo! se lançait dans OpenID via openid.yahoo.com, Vont-ils passer sous Passport ?
  • Yahoo! s'appuie majoritairement sur des plate-forme LAMP. Vont-ils passer sous .Net ?
  • Surement encore plein d'autres hypothèses bonnes ou mauvaises... et qui se réaliseront ou pas.

De tout cela, on peut espérer que le grand public s'empare de cet événement pour prendre conscience de son manque de contrôle sur les données fournies dans/à des services tiers. A défaut du grand public, ce sera une couche déjà plus élargie que celle des "geeks" et "early adopters" qui se préoccupent de cette question (ça fait tout de suite vraiment peu de monde).

La mauvaise réponse à ce rachat serait de migrer ses données de Y!/Microsoft vers Google/Autre fournisseur de service. Rien de nous dit que le fournisseur de service ne sera pas racheté par un des grands (la tendance tendrait même à dire que c'est quasiment sur) et votre contrôle sur vos données est généralement faible, voir nul.

Pour se libérer, il va falloir que le grand public dispose de solutions leur garantissant le contrôle de leur données mais que ces solutions soient aisément déployables pour qu'elles connaissent le succès qu'elles méritent.

Le principe du SaaS est bon en terme d'adoption par le public. Toutefois, le SaaS n'offre pas nécessairement le contrôle sur ses données (Cf Twitter, Pownce, ...). Il convient alors de créer un "SaaS éthique" offrant à l'utilisateur la même facilité d'utilisation mais avec un contrôle total sur ses données.

Si une personne ne souhaite pas passer via un mode SaaS, il faut pouvoir l'aider au maximum dans sa démarche :

  • Lui proposer un service hébergeable sur le lieu de son choix,
  • Mise en place d'offre d'hébergement dédié / mutualisé offrant des assistants pour déployer tel ou tel service - Dernièrement, l'offre d'hébergement Gandi AI peut être vue comme une bonne pratique à suivre. L'hébergement étant de plus en plus accessible en termes de prix, il ne reste que la partie compétence à simplifier pour l'utilisateur lambda.
  • Travailler sur le packaging des solutions pour une instalation et un déploiement intuitif et immédiat.

Mais tout cela suppose que le service existe et surtout contrairement aux services actuels, qu'ils soient interopérables (déjà parlé ici et là). La dose de travail à fournir pour le développement de services similaires n'est pas si important que cela ; Des solutions libres existent déjà pour quasiment tout les services du "Web 2.0" à savoir micro-blogging, gestion de favoris, etc. Le seul point qu'il leur manque est l'interopérabilité entre eux et ce point est de taille car il pose des problèmes d'infrastructure (API, ressources nécessaires, etc) mais aussi et surtout de normes.

Même si ces derniers mois, de nombreux (micro-)formats sont apparus, il va falloir forcer la sélection pour ne retenir que les plus pertinents. Data portability a déjà fait une sélection. A voir si cela suffit/suffira et si Microsoft membre de l'initiative ne va pas chercher à l'empêcher de progresser.

Ce web libre ne semble pas si loin que cela. Juste "un peu de travail" et de communication sur l'initiative. L'interopérabilité est par contre plus complexe et plus longue à mettre en place à mon sens.

En tous cas, cette nouvelle ne fait que me conforter dans la construction du projet Atome, qui bien qu'en standby d'un point de vue développement, progresse dans ma petite tête...

3 commentaires

mardi 6 novembre 2007

Coup de pouce : David Larlet crée Welldev, pour des développements autour de Django...

Par NiCoS le mardi 6 novembre 2007, 10:35

Pour celles et ceux qui cherchent un indépendant familier des bonnes pratiques en matière d'accessibilité, web sémantique, développement, formats ouverts, etc, bref disons le un "passioné du web" et qui en plus fait du django (bon ça à la limite, vous vous en fichez de la solution technique, quoique...), alors pensez à David Larlet. Vous le connaissez forcément (oui oui, c'est bien celui que je cite souvent, l'auteur de Biologeek). Il vient donc de se jetter à l'eau en créant sa boite : Welldev.

Il ne manquerait qu'une corde graphique à son arc pour en faire le prestataire idéal, mais ça, je lui fais confiance pour trouver les partenaires qui vont bien en la matière ;-)

Souhaitons lui bon courage et que les formalités administratives de création d'entreprise et autres URSSAF & co ne viennent pas tuer sa motivation.

Une raison de plus pour que le Papa de Django-fr relance le projet en question... :-)

un commentaire

mercredi 31 octobre 2007

Lecture : Petit guide à l'usage du développeur agile

Par NiCoS le mercredi 31 octobre 2007, 00:06

Je n'en finis pas de mes lectures. Dernier livre donc sur ma liste : Petit guide à l'usage du développeur agile.

Le livre m'a bien plu et surtout les derniers chapitres sur le Test Driven Development (TDD), Document Driven Development (zut, pas de bon lien à mettre) (DDD) et la gestion de projet. La partie sur Python en tant que telle m'est globalement passée au dessus de ma petite tête du fait de mon niveau actuel sur le langage (j'ai néanmoins glané quelques trucs ici et là, directement applicable dans mes dev en cours).

Ce livre ne vous aidera pas à appréhender python (enfin moi, cela ne m'a pas aider) et à la limite il n'aborderait pas python, ce ne serait pas grave. L'intérêt du livre n'est pas là mais bien dans les conseils, méthodo, bonnes pratiques qui sont énumérées. Bon faut quand même l'avouer, quand on voit comment TDD et DDD s'appliquent à Python, ça laisse rêveur (et l'équivalent n'existe pas pour PHP ou même Ruby apparemment, surtout pour DDD).

Les seules choses que j'ai trouvé un peu pénible dans le livre tiennent plutôt sur la forme (le formatage du code pourrait être amélioré, pas mal de typo/fautes d'orthographe, etc.)

En tous cas, à lire pour tout (bon) développeur / chef de projet qui se respecte !

D'autres critiques du livre :

lundi 29 octobre 2007

Lecture : Internet, donne moi ce que je veux !

Par NiCoS le lundi 29 octobre 2007, 14:06

Toujours dans mes trajets parisiens, j'en ai profité pour lire cette fois ci "Internet, donne-moi ce que je veux !" de Patricia Gallot-Lavallée. Le livre présente et analyse 60 modèles de navigation selon trois critères : note, coût et accessibilité,

Je ne peux pas dire que j'ai appris beaucoup de choses pour les navigations "classiques". A la limite, heureusement vu mon métier :-) . Pendant que j'en suis aux critiques négatives, le format sur deux pages à ses limites aussi. On en voudrait plus mais l'objectif du livre ne serait plus le même.

Le livre mérite par contre d'être acheté pour les raisons suivantes :

  • Découverte de modèles de navigation originaux (même si je suis pas sur de les utiliser dans les projets sur lesquels j'interviens d'habitude),
  • Beaucoup de petites astuces de-ci de là,
  • Les témoignages utilisateurs donnant un retour concret/pragmatique et les avantages/inconvénients/limites des menus mis en place,
  • et surtout d'avoir dans un livre un condensé sur les navigations. Cela permet de se libérer le neurone des forces/faiblesses de chaque modèle mais aussi en clientèle de pouvoir présenter/éliminer rapidement un modèle de navigation pour un projet.

D'autres revues du livre sont en ligne :

vendredi 26 octobre 2007

Hors Série Courrier International : "Révolution 2.0 : Comment le Net va (encore) changer votre vie" chan

Par NiCoS le vendredi 26 octobre 2007, 10:20

J'ai profité de ma descente la semaine dernière pour acheter le Hors Série de Courrier International : Révolution 2.0 : Comment le Net va (encore) changer la vie. Je m'attendais à ne rien apprendre et regretter d'avoir dépensé 7€ et bien non. Même si je ne l'ai pas encore tout à fait fini (j'avais du travail à faire mardi en allant à Bruxelles (oui, je me la joue Globe Trotter en ce moment :-P )), je ne peux m'empêcher de vous le recommander (même pour ceux qui connaissent le Web 2.0 en long large et en travers), car pour une fois, on ne parle pas que de technique, buzz & co.

Personnellement, j'ai bien aimé :

  • La partie historique et présentation des différents éléments constitutifs du web 2.0 (ajax, user generated content, podcast, réseau sociaux, wikipedia, etc). On notera quelques approximations sur la technique mais bon c'est pas un journal de geeks non plus :-)
  • La forte conivence entre le logiciel libre et le web 2.0. Pour moi, cette conivence n'était pas aussi évidente. Je voyais plutot ça comme deux mouvements parallèles avec bien sur des interactions mais sans plus.
  • Le Web 2.0 et les enjeux en termes de développement (Afrique, projet OLPC, etc)
  • Le Web 2.0 et les démocraties/régimes totalitaires (Chine, Moyen Orient, etc)
  • ...

Ce hors série donne un coté beaucoup plus humain/interessant au web 2.0 et rend le buzz plus supportable...

A lire donc...

5 commentaires

lundi 15 octobre 2007

Ces données qu'on aime tant... (suite)

Par NiCoS le lundi 15 octobre 2007, 23:17

La nuit portant conseil et surtout ayant du mal à m'endormir et en y réfléchissant de temps à autre ou en discutant avec Niko le midi, quelques petits compléments au précédent billet "Ces données que l'on aime tant...".

Après mure réflexion, seul Flickr est un bon service dans le sens où je l'ai exprimé. En effet, contrairement à Flickr, Dailymotion ne permet pas de récupérer la version originale de la vidéo. Et paf ! Vivement que flickr supporte les vidéos...

Ensuite, se pose quelques problématiques fonctionnelles :

  • Dans le cas où j'héberge mes commentaires dans mon dépot, il ne faut pas que je puisse les éditer, sous peine de fausser totalement la discussion. Cela doit fonctionner de la même façon qu'aujourd'hui, à savoir, une fois le commentaire posté, il n'est plus éditable.
  • Par contre, contrairement au système actuel, cela veut dire que le propriétaire du blog sur lequel je commente n'est plus en mesure d'éditer mes propos s'il les juge déplacé - normal, les contenus ne sont pas hébergés chez lui, il n'a dans le meilleur des cas qu'un "cache". Du coup, cela veut dire qu'il faut implémenter un système de retrait d'une ressource de la part du propriétaire du blog (sinon, c'est le spam et le box assurés).
  • Je ne dois pas pouvoir non plus supprimer un commentaire pour les mêmes raisons. Par contre, si le propriétaire du blog a retiré de son site mon commentaire, est-ce que cela a un sens de le laisser publié dans mon dépot, j'ai un doute.
  • A l'inverse, certains types de contenus doivent être révisables (articles, tutoriels, cv, etc). Les différentes versions doivent-elles alors être accessibles ou seulement la dernière ? Faut-il que l'url de la ressource contiennt alors une notion de "timestamp" ?
  • Comment permettre à un utilisateur de dire aisément quelle ressource il veut publier à tel ou tel endroit ? Pour un commentaire, je dois en effet dire que je veux poster un "commentaire" et à une certaine url. Faire un copier coller d'url va devenir vite rébarbatif. Il faudrait pouvoir capturer l'url du billet pour lequel je souhaite poster un commentaire et être ensuite orienté vers mon dépot où je choisit le type de ressource à publier. Pour des facilités d'écriture, on pourrait même imaginer afficher le billet que l'on veut commenter dans une frame visible depuis le dépot (au dessus ou en dessous de la zone d'écriture du fameux commentaire dans notre exemple).

Se pose aussi quelques problèmes techniques :

  • Il va falloir trouver en premier lieu des schema RDF ou assimilés correspondant à mes besoins et suffisamment générique pour que d'autres puissent aussi les utiliser. Si chacun se met à faire son propre format, c'est l'échec assuré. Si un membre d'un consortium me lit, ce serait sympa de proposer un draft de norme en la matière. Dublin Core donne déjà une base solide mais non suffisante. Je suis ouvert à toute suggestion de pointeurs utiles en la matière :-)
  • L'importance du cache et de la synchronisation est primordiale. On ne peut pas aller chercher les contenus partout à chaque appel de page sous peine que tout s'écroule et d'avoir des temps de chargement de dingue. Le maillon faible serait alors le serveur non disponible / saturé / à faible bande passante.
  • Si edition il y a, et suivant si l'on utilise ou pas le timestamp, doit/peut-on fournir un différentiel ou bien prévenir de la mise à disposition d'une nouvelle version du contenu ? Doit-on faire en sorte que le lien renvoit alors vers la dernière version du contenu via des jeux d'url ? (j'ai du coup un doute sur le coté unicité d'une ressource à un instant t et que cette notion d'alias perturbe plus qu'autre chose)

Affaire à suivre...

vendredi 12 octobre 2007

Ces données que l'on aime tant...

Par NiCoS le vendredi 12 octobre 2007, 23:03

Une des facettes du Web 2.0 est la capacité pour tout utilisateur de partager des données et en retour de profiter des données partagées par les autres. Pour autant, un point me gène particulièrement, c'est le contrôle que je peux avoir sur les données que je stocke sur différents services. Je n'aborde pas ici la partie contrôle sur l'utilisation, je pars du principe que dès lors que c'est sur internet, cela peut être bien utilisé (respect des licences, etc) ou bien très mal. Sur ce sujet là, si vous voulez tout controler, ne publier rien ! L'idée est ici de voir dans quelle mesure je suis maitre de mes données.

Sur cette base, on peut dresser une typologie des services web 2.0 de deux types :

  1. Les bons services web 2.0 qui permettent un contrôle total sur les données que j'ai produites
  2. Les mauvais services web 2.0 sur lesquels je n'ai aucun contrôle sur les données que j'ai produites.

Comment différencier ses services ? Je la fais de la façon suivante : si le service venait subitement à disparaitre, qu'est ce qu'il me reste sur le volume de données que j'ai pu produire sur le dit-service.

Parmi les services que j'utilise, je vais avoir :

  • Dans le panier des bons services : des services comme Flickr ou Dailymotion ; les données présentes sur le service ne sont qu'une copie des données présentes sur mon PC et précautionneusement sauvegardées.
  • Dans le panier des mauvais services : quasiment tous les autres : Del.icio.us, Pownce, Twitter, 6nergies, Linkedin, Viadeo, Copaing, Amazon, Google Reader, Google Apps, etc. Certains sont "moins pire" que d'autres dans la mesure où ils proposent des services d'export mais bon sérieusement, qui fait une sauvegarde régulière de ces données sur ces sevices ? Pas moi et à mon humble avis, je suis loin d'être le seul.

Il ne sert à rien de parler des bons ici, surtout que leur mode de fonctionnement implique que l'on ait la donnée source sur son PC.

Parmi les mauvais services, on peut creuser un peu plus la disctinction :

  • Je n'offre aucune porte de sortie à mon utilisateur : 6nergies, Viadeo, LinkedIn, Copaing, Twitter, Pownce, ... Là, le modèle est clair, on vous veut à tout prix et une fois entré dans le service vous n'en sortez plus ou en tous cas, pas sans perte (vos fameuses données que vous avez saisi).
  • J'offre un export dans un format ouvert mais avec une structure à ma sauce : on va retrouver del.icio.us qui propose un export html de ses favoris. On peut donc quitter le service (vu que c'est un format ouvert) mais faut prier qu'un importateur existe si on va vers un service tiers
  • je m'appuie sur des formats ouverts, structurés et directement réutilisable dans un service tiers : blogmarks, google reader par ex avec des formats xml/opml ou google calendar avec l'export au format ical ou xml. Comme pour l'exemple précédent, on a des formats ouverts et structuré mais avec en plus une notion de définition/schema liés à des normes établies (et non propre au service), L'utilisation de ces données est dès lors possible aisément par tout outil capable de gérer de l'opml ou de l'ical par ex.

Il est évident que je vais préférer le troisième type de service par rapport aux deux autres. C'est d'ailleurs une des raisons pour lesquelles j'utilise Google Apps pour certains de mes domaines. Il est très facile de s'en séparer. Les seules pertes pouvant se faire lors de la migration vers une solution de mail / calendrier / aggrégation classique. A ce titre, il faudrait que je vérifie si gtalk permet une sauvegarde de ses contacts pour pouvoir être utilisé via un autre client/compte jabber par ex. J'utilise donc d'autant plus facilement ce type de service que je peux facilement en changer (ça me rappelle un des principes de l'intégration réversible tout ça).

Il me reste donc à régler le cas des deux premiers types pour avoir la main sur mes contenus. Certains diront qu'il existe une déclaration des droits de l'utilisateur du web social. Cette partie est rassurante mais pour autant pas tout à fait satisfaisante. Par contre, je rejoinds tout à fait l'analyse de David et les meta-applications ne sont qu'un élément de réponse sur la partie interopérabilité.

J'allais dire qu'il faudra admettre que pour certaines applications, on ne puisse pas contrôler les données dans leur intégralité. Cette phrase est en fait innaceptable. A court terme, oui on ne pourra pas le faire et l'exemple parfait est les réseaux sociaux, ceux là même qui ont porté les débuts du web 2.0. A moyen terme, cela ne devra plus être acceptable. On devrait pouvoir publier une seule fois son cv et le diffuser sur toutes les applications... Aie, j'en ai déjà trop dit...

Pour le formaliser, je verrais donc bien la solution suivante :

  • Centralisation de ses données dans un "dépot"
  • Gestion de la publication de ses données sur différentes services - l'inscription au service ne consisterait dès lors qu'à se doter d'un compte (ou donner son compte openid) et d'indiquer l'url de la ressource à utiliser.
  • Les spécificités d'un service (ex le champ X ne fait pas partie des champs de base chez 6nergies mais existe chez Linkedin) seraient gérées dans son dépot. Il suffirait de mettre des attributs propre au service autour de la donnée à utiliser.
  • Le service peut aspirer les contenus de votre dépot pour des problématiques de performance, cache, partage, etc mais à tout moment vous pouvez le retirer. Ex : on peut imaginer que je publie mes favoris gérés depuis mon dépot sur del.icio.us. Bien sur, del.icio.us a besoin de les stocker et de leur associer des propriétaires (comme actuellement en fait). La seule différence tiendrait à ce que c'est mon dépot qui pousse les favoris vers del.icio.us et non moi directement depuis mon extension firefox. del.icio.us ne serait alors qu'une réplication des contenus de mon dépot.
  • Le service doit aussi permettre de pouvoir synchroniser dans les deux sens. Si mon dépot tombe, je dois pouvoir récupérer mes favoris depuis del.icio.us pour les réimporter (je rêve peut être un peu là, mais soyons fous).

Délirant ? Pas du tout et c'est déjà en place pour certaines fonctionnalités. Rappelez-vous les trackbacks. Ce ne sont après tout que des commentaires postés depuis un dépot (son propre blog) et sur un blog distant. Il suffit "juste" de structurer un peu mieux le concept et de gérer le spam.

Qu'est-ce qu'il nous fait pour faire tout ça :

  • A minima du RSS - on a déjà
  • ... ou une architecture REST si on est plus exigeant - on a plus ou moins
  • Des formats ouverts de typologies de contenus : RDF, XML, FOAF, bref tout ce qui a trait au Web 3.0 Web Sémantique
  • De l'authentification : OpenID
  • Des services ouverts : bon là, c'est la misère pour le moment

Seule l'utilisation d'une architecture ouverte et de formats ouverts peut permettre la réussite d'un tel projet.

Certains pourraient dire à juste titre : certes mais alors pour un del.icio.us, quelle est leur valeur du coup ? quel est leur intérêt de fonctionner ainsi ? Ils auraient toujours des utilisateurs et des données. Seul le mode de contribution change. Ce nombre et ces données peuvent d'ailleurs augmenter puisqu'il est dès lors facile de s'inscrire à tous les services de bookmarking social.

Une fois dit tout ça, on voit que l'on contrôle à nouveau alors l'ensemble de ses données et leur publication. Personnellement, c'est la raison d'être du projet Atome que je compte bien batir sous peu (une fois que MvMo sera un peu plus stabilisé et publié). Atome ne sera certainement pas tout ce que je souhaite plus haut dans un premier temps. La seule chose sur est qu'il sera mon dépôt de données pour mon blog, un peu de micro-blogging, mes favoris, le wiki et peut être quelques snippets.Pour le reste, on verra en temps et en heure...

Le seul truc qui me chiffone pour le moment, c'est que je n'ai pas réussi à intégrer du Jabber dans tout ça et notamment la partie pubsub. Mais bon, ça devrait venir... :-)

Edit 1 : Edition suite au commentaire de Leviathan.

2 commentaires

mardi 9 octobre 2007

Comment assurer la pérénité de son projet ?

Par NiCoS le mardi 9 octobre 2007, 21:50

Etant en train de mettre à jour un site réalisé sous SPIP 1.7 vers SPIP 1.9.2c (soit un écart proche de *21* versions intermédiaires (majeures ou mineures), voici quelques retours :

  • Ne pas suivre la mise à jour de l'outil qu'on utilise, c'est très mal. Avoir en tête tous les changements qui ont eu lieu entre ces versions relèvent parfois du casse-tête. Bon en même temps, un bug sur le critère titre_mot a empêché une mise à jour de l'outil pendant longtemps (au moins la version 1.8.2e, soit déjà 10 versions d'écart).
  • Ne pas documenter le code (php ou les squelettes SPIP), c'est mal aussi.
  • Ne pas conserver les sources des animations flash, c'est mal aussi (pour le coup, cela m'a simplement obligé à utiliser un lien symbolique suite à la réorganisation du bazar)

Du coup, on peut raisonnablement se dire que pour assurer la pérénité de son projet, il faut :

  • Documenter le code de façon satisfaisante :
    • Utilisation de la javadoc, phpdoc, ...
    • Utilisation de la balise REM pour les squelettes SPIP expliquant chaque boucle ou bloc de boucle (notamment avec les boucles HIERARCHIES)
    • Documenter le fonctionnement du site, les règles de gestion, la raison d'être des différents articles, etc que ce soit dans un document externe ou au sein des squelettes par ex
  • Le code ne correspondant pas au code source de l'application doit être clairement identifiable.
    • Seul le code source spécifique au projet doit dès lors être dans le gestionnaire de source du projet
  • Suivre les mises à jour de l'outil au fur et à mesure en tirant parti des nouvelles fonctionnalités
    • Le nouveau compilateur (plus oblige a réécrire certaines boucles vu qu'il est moins laxiste que précédemment.
    • L'apparition de #DOSSIER_SQUELETTE puis de CHEMIN{} permet ainsi de centraliser tous les éléments de vos squelettes et vous donne une plus grande flexibilité (plus de chemin en dur par ex)
    • Le coût de la mise à jour est alors minime et réparti - plutôt qu'un gros coup prohibitif lors de la mise à jour 21 versions plus tard, risquant de plonger votre projet dans l'immobilisme total...
    • La transformation de certains bouts de code en plugins SPIP (notamment pour des éléments insérés dans la partie privée) est un réel plus et améliore la lisibilité de votre site/code.
  • Suivre les mises à jour pour bénéficier des correctifs de sécurité
  • Sans oublier que la mise en page par tableaux, c'est une horreur à maintenir, illisible, etc.

La liste n'est sans doute pas exhaustive mais déjà rien que pour ce projet, je peux mettre un zéro pointé partout. Alors certes, un bug SPIP corrigé en 1.8.2e empêchait toute mise à jour vers la version 1.8 de l'outil, mais depuis, cela aurait du être fait proprement.

En tous cas, ça vous donne plein de bonnes pratiques pour vos prochains projets perso / cahier des charges / mode de gestion de projet / ... ; si ça vous en donne pas, moi si !

vendredi 5 octobre 2007

Le Web 3.0 est enfin défini :-)

Par NiCoS le vendredi 5 octobre 2007, 09:45

Et non, le Web 3.0 ne sera pas le web sémantique comme on pouvait le lire ici ou là depuis quelques temps, ni la définition du web 3.0 de Google (Voir ici ou là ou encore là (perso, j'ai pas pris le temps de regarder la dite vidéo)).

C'est Jason Calacanis dans son billet "Web 3.0, the official definition"

Web 3.0 is defined as the creation of high-quality content and services produced by gifted individuals using Web 2.0 technology as an enabling platform

L'idée est que les services estampillées "web 2.0" ne sont plus une fin en soi mais un simple moyen, voir une commodités. L'autre différence tient au fait que les contenus sont évalués/triés pour faire ressortir des contenus à valeur ajoutée (ex : modération accrue des contenus chez wikipedia, contenus inéditables lorsqu'ils ont atteint un certain niveau de qualité/complétion, etc). L'expertise est donc un des mots d'ordre de ce web 3.0.

Personnellement, je dis : enfin, pas trop tôt ! J'en ai marre d'être submergé de contenus inutiles ou de passer des heures à trouver un contenu intéressant dans une masse ! Et si tant est qu'il faille donner un numéro à ce web, je lui aurais plutôt donner un Web 2.1 ou Web 2.0 SP1 ;-P

Edit du 8/10 :

6 commentaires

mercredi 26 septembre 2007

L'après web 2.0, l'heure des meta-applications ?

Par NiCoS le mercredi 26 septembre 2007, 10:30

Tout le monde est (à peu près) d'accord pour dire que :

  1. Le web 2.0 est source d'une grande profusion d'application et de clones d'applications
  2. L'utilisateur en a marre de devoir se réinscrire sur chaque nouveau service et d'y ajouter tout ses contacts.
  3. Les passerelles inter-services existent pas/peu. Les ouvertures se font généralement vers des services annexes/complémentaires. Pourtant chaque service propose (ou proposera) une API ouverte permettant l'intégration de son service sur une page ou dans une application distante.c

Partant de ce constat, je suis étonné que personne n'ait encore développé de "meta-application" qui se positionnerait entre l'utilisateur et des services similaires. On pourrait imaginer par exemple une meta-application de micro-blogging qui envoie vos messages sur Twitter et Pownce. Certains me diront que des solutions existent pour qu'un propos de Pownce soit affiché sur votre compte twitter via Twitterfeed, dont le principe est d'envoyer sur twitter n'importe quel contenu disponible via un flux RSS. Je trouve que cette solution relève plus du bidouillage et fait en outre intervenir un troisième acteur chez lequel il faut avoir un compte (heureusement, dans le cas d'espèce, il a la bonne idée de s'appuyer sur une authentification OpenId.

Revenons donc à ma meta-application de micro-blogging. Le principe est simple : "Tout message entrée dans la-dite application serait alors envoyée vers Twitter et Pownce". Cet envoi se faisant via les API des services concernés (je sais, celle de Pownce n'est pas encore disponible, faites comme si c'était le cas...)

Regardons plus en détail ce que devrait gérer cette meta-application (liste non exhaustive) :

  • Gestion de compte :
    • Gestion d'un compte au niveau de la meta-application (ou pas à la limite si c'est ma meta-application est une application desktop)
    • Création d'un compte dans chaque service retenu par l'utilisateur et ce de façon transparente. L'idée est d'éviter que l'utilisateur ait à aller se créer un compte sur chaque service puis les rentrer dans la meta-application
    • Si l'utilisateur a déjà un compte, il lui faut pouvoir rentrer ses informations de connexion
  • Envoi des messages :
    • Gestion des spécificités de chaque service (ex : Pownce permet d'envoyer différent types de messages : note, lien, événement, fichier et ce sans limite de caractères; alors que Twitter a un type de message et limité à 140 caractères)
    • Capacité à fournir une version "dégradée" des messages si les autres services ne gèrent pas les mêmes éléments (ex, un événement pownce sera traduit sous la forme d'un message simple twitter ou un message de plus de 140 caractères chez pownce est rendu sous la forme de n messages twitter, etc)
  • Gestion des contacts :
    • Capacité à ajouter des contacts utilisant n'importe quel service de micro-blogging
    • Capacité à afficher les messages des dits-contacts : simple intégration de flux RSS avec un soupçon d'authentification si on veut pouvoir accéder à des messages filtrés (message non public de Pownce ou messages protégés de Twitter

J'ai grosso modo fait le tour pour une version basique de cette meta-application et on voit bien en quoi elle résoud les trois problèmes mentionnés en début de texte.

D'un point de vue technique, cela ne me semble pas insurmontable à faire, la seule condition préalable étant l'existence d'une API ouverte et documentée mise à disposition par le fournisseur du service. Ces meta-applications pourtant tout aussi bien être déclinées en version full web qu'en version RIA, RDA (Rich Desktop Application - étonnant que wikipedia n'ait rien à ce sujet :-( )

2 commentaires

- page 1 de 6