Twitter : l’avènement de l’info médiocre ?

Jusqu’à il y a peu je trouvais le concept de twitter intéressant : on pouvait rester informé de l’actualité de ses centres d’ intérêt sans trop d’efforts. Mais mon avis a changé depuis que les institutionnelles s’en servent comme moyen de communication. En fait c’est Mon frère qui m’a convaincu à l’aide d’une remarque judicieuse : n’est ce pas dangereux de réduire l’information à 140 caractères ? Qu’on échange un lien ou que l’on annonce un fait. correspond bien à cette quantité mais est-ce pertinent pour une annonce officielle ou une réaction politique ? L’information ne peut se limiter à de simple faits, résumés qui plus est. Elle doit bien souvent s’accompagner de références et d’analyses.
D’autant plus qu’une première étape de validation de l’information passe par la structuration de celle ci. En effet c’est en rédigeant plusieurs lignes que l’on se rend compte si un énoncé tient debout ou non.

Je ne dis pas non plus qu’il faut jeter twitter aux orties mais qu’il doit rester à sa place : un outil permettant de transmettre des faits résumés à son réseau et non pas comme une source d’informations officiellle.

Economie du libre, pas si cheap que ça

J’ai fait un constat amusant récemment. Lors des débats sur les brevets logiciels, beaucoup nous disaient que le logiciel libre allait tuer l’économie du logiciel. Hors en moins d’un an trois sociétés développant des logiciels libres se sont fait rachetées plusieurs centaines de millions d’euros : Spring, mysql et Zimbra. Je n’ai pas l’impression que le business ait beaucoup souffert.

Deux adresses barcelonaises

J’ai découvert Barcelone cet été, ce qui me permet de vous conseiller deux adresses fort sympathiques.

La Macarena

La macarena est un petit club électro situé non loin des ramblas. La salle est plutôt sombre, les consommations ne sont pas excessivement chères. Jusqu’ici rien d’incroyable. Pourtant la qualité musicale des sets proposés est vraiment impressionante. De plus le club est intimiste et malgré sa proximité avec les ramblas, ne fait pas trop boite à touriste. Bref c’est bon d’y faire un tour après la fermeture des bars.

C/Nou de Sant Francesc 5
Barri Gòtic Barcelone

Le Gimlet

Parlons maintenant d’un bar nommé le gimlet. L’entrée ne donne pas l’impression qu’il s’agit d’un débit de boisson, pourtant une fois la porte poussée on aperçoit un comptoir occupant tout l’espace : pas de tables ici.
Le serveur est très distant et totalement pas aimable. Par contre il accomplit son travail avec professionalisme et vous sert des verres très chargés pour la somme de sept ou huit euros.
La déco, assez sobre, rappelle les années 70. La musique est plutôt bien choisi et jazzy. La population est principalement composée de locaux et d’habitués. Enfin on vous targue d’un salute lorsque votre verre est servi. Bref ce bar est un peu spécial, il ne plaira pas à tout le monde mais si vous voulez un peu changer de style c’est parfait !

C/ Santaló 46
Barcelona

Tombe virtuelle

Récemment sur Facebook, j’ai assisté à un phénomène plutôt surprenant. Une personne qui décède voit sa page se couvrir de messages de sympathies, un peu comme si on y déposait des plaques commémoratives. Certains dressent même des chapelles en créant un groupe dédié.

Quoi en penser ? Je n’ai pas réussi à me forger un avis dessus. D’un côté cela permet aux amis proches ou non d’exprimer leur tristesse et d’être rapidement informés, mais de l’autre j’ai l’impression que l’intimité des proches est violée. De plus le fait que le profil persiste alors que le propriétaire n’est plus est assez dérangeant. La page facebook devient alors une tombe virtuelle. Enfin, les plus optimistes diront plutôt qu’elle nous rend immortel…

WordPress et iphone

Voici un petit retour d’expérience de blogging sous wordpress via iPhone.

Etant un débutant iPhone j’ai tout d’abord consulté mes posts directement sur le site de WordPress. Le rendu de Safari étant plutôt bon, j’ai ensuite décidé de me mettre à écrire de nouveaux billets (ce qui est intéressant lorsque je suis dans le métro). Le site fonctionne mal sous safari, j’ai donc rapidement abandonné pour lui préférer l’application iPhone dédiée.

Au premier abord j’étais entièrement satisfait : une vue synthétique de mes posts m’était proposée ainsi que la possibilité d’en écrire de nouveaux et de les sauvegarder en local avant de les sauvegarder en ligne.

Mais les premières déceptions sont vite arrivées :

• Un bug se produit lors de l’édition en mode paysage : les lignes du bas n’apparaissent pas.
• Aucune possibilité de mise en forme n’est fournie.
• La sauvegarde en ligne fonctionne très mal, j’ai perdu beaucoup de modifications voir de posts pourtant sauvegardés en local.

Bref l’expérience est assez décevante. Je ne sais pas si la faute d’Apple ou de wordpress mais pouvoir blogger depuis son iPhone me parait une fonctionnalité basique. Hors, aujourd’hui cela n’est pas une chose aisée et démande dans tous les cas un passage par un véritable ordinateur.

Groupe F again

Bon la mairie de Paris a eu le bon goût de choisir le Groupe F pour le feu d’artifice du 14 juillet ! Très bonne idée. Ils nous avaient déjà épaté à la Villette !

REST + AJAX, quel couple ! (3/3)

Partie 1
Partie 2

5. Templates

Pas vraiment d’idées à ce sujet. On peut peut  être utiliser un language type Perl/Python/Ruby pour générer les pages statiques non dynamiquement (générées une fois pour toute) à partir de templates.

Une autre solution consiste à n’utiliser qu’un fichier html pour tout le site, mais je crains que le développement ne devienne un peu fastidieux et qu’on perde tout l’aspect structuré de l’HTML.

6. Indexation des moteurs de recherche

C’est là où le bas blesse. En fait, nos pages sans javascript ne sont pas consultables. Donc là je vais proposer de croiser les doigts bien forts et d’esprérer qu’une nouvelle balise qui tue fasse son apparaition. Par exemple :

<content html="displayArtiste(mr-tac)"  data="/playlist/artistes/mr-tac/rdf/" />

Pour le navigateur, les données sont affichées avec displayArtiste()  et pour le  moteur/analyseur syntaxique, tout est à disponible à l’URI contenue dans data. Cela ferait disparaître, l’aspect opaque du javascript tout en conservant ses qualité ergonomiques.

7. Défauts

• Un tel site demande un coût important en réalisation. Décrire chaque donnée précisément, assurer un accès propre et dans plusieurs formats n’est pas immédiat. Toutefois on pourrait se limiter à certaines formats et ne décrire avec précision que les données sensibles. De plus, un framework adapté permettrait de ne coder qu’une fois les données et de générer le format désiré automatiquement.
• Le développement en javascript n’est pas aussi trivial que le développement pur HTML.
• L’interfaçage avec les navigateurs pour aveugle n’est pas aisé.
• Enfin, les vieilles machines supportent mal le javascript, voir ne le supporte pas du tout. Ce qui peut limiter l’accès au site web ainsi réalisé.

Conclusion

Au final rien de bien nouveau à part que l’on joue aux extrêmistes du REST tout en profitant de la souplesse ergonpmique de l’AJAX. Alors, pourquoi en parler ? Tout simplement car je n’ai jamais vu un seul site fonctionner ainsi. Les frameworks en vogue sont proches de ce type d’architecture, mais poussent à servir des pages webs dynamiquement générés par du python, ruby ou PHP (ce qui reste lourd pour le serveur).

GWT avec un fonctionnement un peu différent propose de générer des applications 100% javascript. Mais là encore on tombe sur une véritable boite noîre qui produit du code HTML souvent difficile à mettre en forme et pas toujours respectueux des standards.

Pourtant, la plupart des outils sont là pour développer une telle architecture. L’établissement de certains standards sur le format des URI permettrait le développement de frameworks optimisés pour ce type de site web. De plus, l’engouement des interconnexions entre les sites webs dotés d’une telle organisation pousserait les autres à s’y mettre. Enfin, REST et Ajax sont très à la mode, il ne manque donc pas grand chose pour que leur union se démocratise.

REST + AJAX, quel couple ! (2/3)

Partie 1
Partie 3

2. Accès aux données

REST permet d’effectuer les opérations classiques CRUD (Create, Retrieve, Update, Delete) sur chacune des ressources issues de la base de données. On va donc pouvoir mapper toutes les opérations classiques du SQL avec des méthodes de reqête HTTP sur des URI bien définies. Par exemple l’URI du domaine dolebrai.net renvoie les informations sur l’artiste Mr Tac lorsqu’on lui transmet une requête de rappatriement (méthode GET) :

dolebrai.net/playlist/artistes/mr-tac/

Il m’est aussi possible de supprimer l’artiste Mr Tac en envoyant une requête de type DELETE ou de le mettre à jour avec une requête UPDATE.

Enfin, j’aurais très bien pu envoyer une requête POST accompagnée des données nécessaires à l’URI suivante pour créer un nouvel artiste :

dolebrai.net/playlist/artistes/

Pour en savoir plus, je vous renvoie aux nombreuses documentations à ce sujet. Point de vue technologies, nombre de possibilités vous sont offertes : MERB, django-rest, Restlet…

Pour aller plus loin et donner un accès complet aux données du site, on peut également renvoyer les données sous plusieurs formats :

dolebrai.net/playlist/artistes/mr-tac/xml/
=> pour une information bien structurée
dolebrai.net/playlist/artistes/mr-tac/html/
=> pour l'afficher sans traitement
dolebrai.net/playlist/artistes/mr-tac/json/
 => pour une manipulation facile via javascript
dolebrai.net/playlist/artistes/mr-tac/rdf/
 => pour que les moteurs de recherche saisissent le sens des données

La communication entre sites web en ressort facilitée, n’importequel site voulant récupérer les informations sur Mr Tac contenue sur dolebraï.net au format de son choix pourra ainsi le faire.

3. Accès fichier statique

Les fichiers statiques sont aussi des données. Il faut donc aussi qu’ils soient caractérisés par une URI pertinente et qui ne se termine pas par une extension du type .mp3, .html, .xml… On aura par exemple :

dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/tracks/01-my-first-song/file/mp3/
=> fichier 01_myfirstsong.mp3
dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/tracks/01-my-first-song/file/ogg/
=> fichier 01_myfirstsong.ogg
dolebrai.net/playlist/artists/mr-tac/releases/my-first-album/cover/front/
=> fichier myfirstalbum_front.png
dolebrai.net/playlist/artists/mr-tac/
=> artist.html

NB : Le problème d’une telle redirection est qu’on perd le côté instantané du rappatriement d’un fichier statique.

4. Navigation

Le site web se résume à une simple série de fichiers html. D’ailleurs, un seul suffirait. Pour raison de commodité et pour éviter une effet d’opacité comme dans GWT, on préférera plusieurs fichiers HTML décrivant les sections du site. Disons que pour chacun des fichiers templates qu’on aurait créé avec un framework classique , il faudrait un fichier HTML. Ainsi notre redirection serait un peu plus complexe :

dolebrai.net/playlist/artists/mr-tac/
=> artist.html?artist=mr-tac

ou plutôt :

dolebrai.net/playlist/artists/mr-tac/
=> playlist.html?type=artiste&artist=mr-tac

Le layout serait codé en HTML statique et les données seraient fonction des paramètres. Un clic sur un artiste n’entrainerait pas un rechargement complet de la page mais seulement la partie données dynamiques.

Conclusion de la deuxième partie

En résumé, votre interface REST devient le centre de l’application. Que ce soit un intervenant externe ou vos pages AJAX, tout le monde emprunte ce chemin pour accéder aux ressources de votre site web, et ce quel que soit leur type.

REST + AJAX, quel couple ! (1/3)

Partie 2
Partie 3

Suite à une discussion avec un ami, je me lance dans ce billet qui a pour but de décrire une architecture intéressante de  site web. Il n’y a pas de révolution dans celle-ci : on reprend les principes de base des sites modernes en les poussant un peu.

1. architecture générale

Le site web se base sur deux technologies bien connues :

• REST pour l’accès aux ressources.
• AJAX pour la gestion dynamique des pages web.

Pour un site web, REST propose de donner une URL ayant du sens à chaque ressource : pages web, images, données… REST sera utilisé principalement par les « machines ». Nos pages web consulteront le serveur REST pour les données et les fichiers utilisés. De même les autres sites  web voulant exploiter les données du site web s’adresseront à lui ainsi que les moteurs de recherches (URL propres).

AJAX gère le contenu dynamique, c’est donc via du code javascript que l’accès aux données se réalisera. Toutes les pages seront des pages statiques HTML et non générées par du code PHP, Python, Perl…  Ce qui a pour  avantages :

• Une navigation plus fluide entre les pages d’un même thème ;
• La complexité visuelle  déporté du côté client ;
• Une diffusion plus aisée des pages statiques.

C’est la vue de notre site web, c’est l’utilisateur qu’on souhaite satisfaire en priorité. On cherchera ensuite à guider les moteurs de recherche vers nos services REST.

NB : Côté technos, il y a déjà tout ce qu’il faut , par exemple Django ou MERB. Ensuite un serveur apache suffit pour tout supporter. Pour le code Ajax, on peut se baser sur un framework type JQuery.

Chez Ploum (Ploum), ça ne sera pas toi

Hier, on devait aller à la Fidélité, une nouvelle brasserie en vogue (tenue par La Clique).  Arrivé sur place, ça n’avait de brasserie que la carte (et encore sans les prix). A l’intérieur on découvre un grand restaurant à la déco travaillée et animé par une musique lounge. Pourtant on est dans le 10ème dans un coin pas vraiment folichon. Moi qui m’attendait à un remix de Chez Janette… Bon tant pis, ça ne sera pas pour ce soir, car comme vous pouvez vous en douter, sans réservation c’est cuit.

Là, improvisation, notre choix se tourne vers le Chateaubriand, une table réputée. Le problème est qu’il se fait tard, il y a la queue, ça ne passera pas non plus. Notre dévolu se jète alors sur Ploum, un restaurant japonais du coin : 20 rue Alibert dans le 10ème. Ils servent jusqu’à 23h, ça tombe bien. On mangera sur un bar près de la fenêtre.

Entrée

Morceaux de poissons à la sauce magique et soupe miso. Rien de formidable, c’est bon mais pas transcendental.

Plat

On a fait classique, assiette de sushis et de makis. Rien à dire le poisson est bon et fond dans la bouche. Le riz est bien cuisiné.  Le gingembre n’est pas rose et le wasabi est fort. Par contre ce dernier n’est pas directement incorporé au sushi. On se régale, c’est bien meilleur qu’un japonais de base.

Dessert

Décevant, pourtant j’ai sélectionné la spécialité, le ô Ploum : totalement occidental, sucré et à base de caramel. Ca jure avec la finesse des sushis, le goût est trop fort. Le feuilleté dissimulé sous la boule de glace n’est pas mauvais mais sans plus.

Conclusion

Bon dans l’ensemble on mange  bien quand même.  Je n’ai pas parlé du vin car le Chablis que nous avions pris n’allait pas du tout avec nos assiettes. Va falloir que je me renseigne sur quel vin se marie avec quoi. Là ou le bât blesse c’est au moment de l’addition : 86 euros à deux. C’est le prix que nous avions payé chez Paul Bert, avec un dessert en moins et trois verres de vin au lieu d’une bouteille. Ca fait mal, parce qu’on en est quand même bien loin. Vous me direz qu’on a mangé du poisson, mais quand même… Honnêtement j’ai mieux dîné chez Yasube ou au Nakagawa et pour moins cher. Alors non, je ne recommande pas cette adresse.

Bon allez, on finit sur un bon point : l’accueil y est plutôt sympathique.