31 juillet 2006

Lafraise.com : Success Story

1er mars 2004 :
Voir : en bas de la page d'archives http://www.lafraise.com/blog/2004/03/index.php


19 juillet 2006 :
(...) je viens de signer la vente de Lafraise, à Spreadshirt et qu'une page va bientôt se tourner, dans ma courte vie.
Voir : l'article intitulé «Ma retraite à 35 ans», au milieu de la page d'archives http://www.lafraise.com/blog/2006/07/index.php


Lafraise.com. Voir les détails magnifiques de la création de la boîte en plongeant dans ledit blog. Après 3 ans d'activité commerciale web personnalisée -- eh oui, c'est ça la technologie au service des gens -- Patrice arrivait à 80 kEUR de CA mensuel, et finalement revend.

Cette histoire est exemplaire, magnifique. Bien, bien, avant les 80 kEUR de CA, c'était tout simplement un exemple, THE exemple, de comment on pouvait comprendre internet. La revente de ces derniers jours clôt le chapitre de façon pragmatique.

27 juillet 2006

Achats IRL vs. achats online

L'autre jour j'achète une imprimante(*).
Je prends la voiture, je vais chez Surcouf, j'achète, je repars.
Au moment de déballer l'engin, pour une sombre histoire de détails sur les caractéristiques, je regarde sur surcouf.fr. J'y vois la bête 70 EUR moins chère qu'en ville. Mazette me dis-je.
Je reprends la voiture, je vais me faire rembourser, puis je me fais livrer par le net.

Quelques jours plus tard j'achète un disque dur(**).
Donc là j'ai bien compris le truc, je regarde d'abord sur le net, et je vais au magasin pour comparer. L'appareil y est à 10 EUR moins cher que sur le net, mazette.

Çà alors !


(*) Brother HL-5250DN, laser N&B, réseau, compatible MacOS / MacOS X / Win XP, silencieuse, stable, 20ppm recto-verso, imprimante que je vous recommande du reste.
(**) Non, je ne prévois pas mes achats à l'avance, quelle idée.

25 juillet 2006

Blogger : publication différée

C'est quoi ce bug ? On ne peut pas faire proprement de publication différée sous Blogger ?
Si je prépare des notes le 23/07, ce n'est pas pour les voir apparaître comme datées du 23 alors que je les publie le 25 !

23 juillet 2006

Quand une plateforme blog tombe en panne: le cas TypePad

Via pointblog : Panne mondiale pour TypePad ?

En deux mots, les blogs TypePad étaient accessibles en lecture, mais les auteurs ne pouvaient pas poster de nouveaux messages. C'était le 12 juillet, et ça a duré moins d'une journée.

C'est exactement ce qui se passe quand la consultation des messages se fait depuis un cache applicatif réparti mais avec une publication de messages centralisée. C'est le choix suivi pour le lancement des Fûts. Ce n'est pas le cas d'un système NNTP comme Usenet par exemple.

Tout ça pour dire qu'intégrer toute la logique NNTP au phénomène des blogs, serait une bonne grosse révolution. Redondance, fiabilité, pérennité.

Sans parler du cross-blogging dans les commentaires, qui est une sous-partie de ce qu'apporte NNTP, et qui pour le coup est dans les principes initiaux des Fûts. Mais c'est applicatif. La révolution devrait porter sur l'infrastructure, pas seulement sur l'applicatif.
Et qu'on ne me parle pas de RSS ! cette espèce de tam-tam XML, où «chacun» est responsable de faire la réplication des informations. RSS est applicatif. Ce n'est pas du transport, il faut arrêter cette confusion.

Un peu de distribution PHP/Java

On teste la publication d'un message sur un forum des Fûts, avec des appels synchrones uniquement, en mode DEBUG et en mono-thread.
Les appels distants pour la publication d'un message sont les suivants :
  1. PHP notifie Java que des commandes sont à traiter
  2. Java récupère auprès de PHP les commandes à traiter (en lot)
  3. Java réserve auprès de PHP une nouvelle version des données («locked rev»)
  4. Java sollicite PHP pour chaque message posté : prise en compte des données dans la rev applicative, calcul des threads
  5. Java relâche la rev auprès de PHP
  6. Java indique à PHP que les commandes sont traitées (une par une. Petit bug)
Total pour un message : un appel distant de PHP vers Java, 5 appels distants dans l'autre sens.

En cible, 1./2. forke.
Pour les tests, 1./2. est synchrone.

Voici les temps de réponse :
  1. PHP/PC ---(local)---> Java/PC
    moyenne 1356 ms, écart-type 64 ms (5 %)
  2. PHP/PC ---(LAN)---> Java/minimac
    moyenne 6988 ms, écart-type 2828 ms (36 %)
  3. PHP/free.fr ---(internet)---> Freebox ---(LAN)---> Java/PC
    moyenne 3266 ms, écart-type 1191 ms (36 %)
  4. PHP/free.fr ---(internet)---> Freebox ---(LAN)---> Java/minimac
    moyenne 7778 ms, écart-type 3672 ms (47 %)
Axes d'améliorations :
  • Mettre une vraie machine en frontal SOA DMZisé. Le «minimac» PPC patine quand on veut lui faire faire du J2EE.
  • Penser à un serveur hébergé.
Urgence :
  • Aucune. Depuis quand 10 secondes pour poster un message sont-elles un délai rédhibitoire sur le web ? ;-)

21 juillet 2006

Tests de mini-scénarios web

Pour le développement, il y a une catégorie de tests qui se déroulent sur des scénarios, c'est-à-dire des enchaînements de pages. On procède ainsi :
  1. on décrit la suite de pages du site web à tester. Soit en donnant explicitement les URLs, soit en indiquant quel clic simuler, soit en indiquant quel formulaire soumettre.
  2. pour chaque page, on donne la série de tests à passer sur le HTML : validité du HTML, contenus attendus, contenus interdits...
  3. pour chaque page, on donne la série de tests à passer sur l'état de la base : le test le plus simple étant de contrôler le nombre de lignes dans certaines tables.
Note : c'est assez différent de la «fermeture Hyper Texte», qui valide que tous les liens à l'intérieur d'un site sont cohérents, mais qui concerne davantage un site statique qu'un site dynamique.

Voici les écrans qui résument les résultats des tests sur scénarios.

Tout d'abord l'écran global, qui montrait dans sa première version les résultats de validation HTML, et qui montre maintenant en sus les résultats de validation DB :


La colonne «v.» donne le nombre total de tests pour chaque page, HTML et DB confondus.
En rouge, le nombre de tests qui ne passent pas.

Puis l'écran qui résume l'évolution de la base au fil du scénario :


En lignes les tables, en colonnes les étapes du scénario (les actions SUBMIT sont indiquées), et à l'intérieur du tableau les nombres de lignes dans chaque table. Quand le test ne passe pas (en rouge), on indique le nombre de lignes attendu et le nombre réel.

16 juillet 2006

Les joies de l'intégration

Une servlet avec du joli code Java qui marchait bien sur de l'Intel Core Duo, ne fonctionne plus après déploiement sur un Mac mini PowerPC G4.

Je n'arrive plus à lui dire de lire plusieurs octets à la fois en HTTP :
final InputStream is = socket.getInputStream();
// Ne fonctionne pas sur le Mac mini :
// final int byteCount = is.read(bytes, 0, 4096);
// --> SocketException: Illegal Argument
final int b = is.read(); // Pour le Mac Mini.

Résultat de ce changement : perfs -11%


Ah, et incidemment, toujours sur des tests en LAN, le déploiement de la servlet sur le PowerPC G4 rend l'ensemble 2,6 fois plus lent qu'avec le déploiement sur le Core Duo.
  • PC : Core Duo 2,8 GHz / 2 Go, Windows XP, JDK Sun 1.4.2_11, Tomcat4
  • Mac : G4 1,25 GHz / 512 Mo, NetBSD 3.0, JDK Blackdown 1.3.1, Tomcat4

12 juillet 2006

Associations et Web Agencies

Je vois en ce moment des associations se faire démarcher de façon assez agressive par des Web Agencies françaises, qui leur proposent de monter des sites web rapidement, facilement, et économiquement.

À l'adresse de ces agences, je pense que le secteur de marché est bon ;-)

Cela dit, au vu des sites de ces boîtes, ce qu'elles proposent relève davantage du CMS que de l'outil collaboratif.

Où est la plus-value ?

1. Dans la qualité ?
Les associations s'en fichent un peu.

2. Dans le prix ?
Leur prix est standard : 3000 ~ 3500 EUR pour un site institutionnel d'une dizaine de pages.
L'approche commerciale agressive est de proposer un «partenariat». En gros : donne-moi ton fichier client et je te fais une méga-ristourne.

Je ne mettrai pas de lien vers les sites de ces agences. Ce n'est pas pour éviter de leur faire de la pub, mais par respect des contacts associatifs qui m'en ont parlé.

J'ai quand même le droit de mettre un lien, celui de Médiacité, qui a la bonne approche à mon avis : «Notre vocation est de répondre aux besoins de communication publique et de promotion territoriale».

Ils ne font pas partie des agences qui démarchent, donc je peux en parler :-)

Pourquoi est-ce la bonne approche ? Parce qu'en étant spécialisé dans la promotion territoriale, le financement peut être mixte. Et ça, c'est très clairement un élément différenciateur :-) Cela dit pour des petits sites, je ne sais pas si le modèle reste bon. Ah, on me fait signe que oui. Alors oui.

Techniquement, d'après ce que j'en ai vu, eux aussi font du CMS.

Plateformes de blog : Gandi

Je viens de créer un blog chez Gandi, vu que j'y gère le domaine halfj.com.

L'URL : http://blog.halfj.com/.

Ma première impression est plutôt mitigée.

"Il y a du potentiel" (façon 2.0 de dire que l'interface est compliquée).

09 juillet 2006

Outil de diaporama

Une des demandes du Jardin Sauvage (tiens, ça me fait penser qu'il faudrait publier un compte-rendu de la réunion, un jour) était de pouvoir mettre en ligne des diaporamas. Avec fond sonore s'il vous plaît.

J'ai trouvé Lightbox JS V2.0, ça a l'air assez fort.
C'est du pur JavaScript, uniquement côté client, non intrusif pour le reste du code HTML de la page.
Voir des exemples d'utilisation sur le blog de parapente Le rêve d'Icare.

Qu'en pensez-vous ?

Connaissez-vous d'autres produits pour faire des diaporamas ?


Quant à la lecture des MP3, le Dewplayer s'impose, à mon avis.

Perfs de la couche présentation

Avant de passer aux appels distribués PHP/Java, voici quelques mesures de temps de traitements applicatifs PHP sur le forum en l'état.
Ces mesures font apparaître les temps hallucinants dus à la couche de présentation.

Pour rappel, aujourd'hui :

1. Le traitement applicatif PHP remplit des DataBeans, c'est-à-dire des objets qui n'ont que des méthodes getXxx() et setXxx().

2. Le relais est ensuite passé à la couche de présentation, qui sérialise les DataBeans en XML par la méthode «toXml()». Pour de sordides raisons de limitations de PHP, on normalise le résultat en UTF-8 propre, avant d'appliquer la XSLT qui a servi au maquettage XHTML. On renormalise ça en UTF-8 propre, puis on formate le XHTML en HTML 4.01 «optimisé». Cela fait 5 passes où l'on utilise XML.

Ce sont ces passes qui prennent du temps.


Les mesures ont été faites en une heure, sur des écrans de consultation en mode debug, avec le jeu de données «dataset-005» (ça, c'est pour les intimes).
On a testé l'affichage d'une liste de 3 forums, l'affichage d'une liste de 38 messages dans un forum, en tri par date puis en tri par enfilade, l'affichage d'un message, avec une liste sous-jacente en tri par date puis en tri par enfilade.



1. Liste de 3 forums

XML du DataBean sérialisé : 13 Ko
HTML : 14 Ko
Temps total : 612 ms
Couche applicative : 226 ms (37%)
Couche de présentation : 374 ms (61%)

2. Liste de 38 messages, tri par date

XML du DataBean sérialisé : 29 Ko
HTML : 70 Ko
Temps total : 1400 ms
Couche applicative : 341 ms (24%)
Couche de présentation : 1042 ms (74%)

3. Liste de 38 messages, tri par thread

XML du DataBean sérialisé : 29 Ko
HTML : 59 Ko (il y a moins de lignes de séparation dans la table qu'en tri par date)
Temps total : 1275 ms
Couche applicative : 335 ms (26%)
Couche de présentation : 925 ms (73%)

4. Un message, avec liste sous-jacente triée par date

XML du DataBean sérialisé : 18 Ko
HTML : 23 Ko
Temps total : 924 ms
Couche applicative : 307 ms (33%)
Couche de présentation : 605 ms (65%)

5. Un message, avec liste sous-jacente triée par enfilade

XML du DataBean sérialisé : 18 Ko
HTML : 23 Ko
Temps total : 943 ms
Couche applicative : 340 ms (36%)
Couche de présentation : 587 ms (62%)

6. Répartitions moyennes détaillées :
  • Couche applicative : 31%
  • Couche de présentation : 67%
    • Sérialisation du DataBean en XML : 2%
    • Transformation XSLT : 29%
    • Formatage du HTML : 22%
    • Temps total des deux renormalisations en UTF-8 : 14%




Les pistes d'optimisations sont les suivantes, :

1. Ne plus s'appuyer sur XML pour la couche de présentation.

C'est-à-dire construire directement le HTML en PHP en une passe, au lieu d'utiliser XML sur 5 passes. C'est fou comme c'est plus rapide le PHP, si, si. On devrait gagner entre 50% et 60%.

Néanmoins il faut garder la skin XSLT, est passer des UAT avec, car c'est la seule qu'on ait aujourd'hui qui soit corrélée à un maquettage hors serveur.

2. Faire la mise en page davantage en CSS plutôt qu'en HTML.

On gagnera évidemment d'autant plus de temps que le HTML sortant sera proche d'un bête dump du DataBean.

2.1. Passer à des entités numériques (é) plutôt que codes (é) quand on y gagne. Sur «é» (é), on gagne 2 octets.

Le fait de ne transférer que des octets sur 7 bits n'est pas négociable. Donc autant gagner sur la taille des entités.

3. Afficher plusieurs messages par page.

S'il faut une seconde en dev (2 sec. en prod) pour afficher un message, ça va faire cher de la discussion.
Il faut impérativement permettre de lire les messages par lots.




Quand seront faites ces optimisations :

4. Pas avant l'automne.

Les optimisations 1 et 2 ne sont même pas critiques pour les premiers utilisateurs. On a des temps de réponse de l'ordre de 1,5 sec. sur poste de développement, donc de 3 sec. en production. Je parie que ça passe.

Pour l'optimisation 3, là, c'est sûr, ça va se voir. Cela dit, arrivons d'abord au béta-test.

08 juillet 2006

Navigation structurelle

Je ne parle pas là de la localisation dite «chemin de fer» de type «a -> b -> c» en haut des pages qui indique à quel niveau de l'arborescence du site on se trouve.

Je veux parler des facilités de navigation au sein d'un site ou d'un sous-site offertes par certains navigateurs.

Dès qu'on navigue dans une liste, on doit avoir des liens «Premier élement», «Élément précédent», «Élément suivant», «Dernier élément», et «Retour à la liste».

Les liens <a> correspondants doivent avoir un attributs«rel», respectivement à "first", "prev", "next", "last", et "up".

Et la partie <head> de la page doit contenir des <link> avec les mêmes attributs. Cela permet à iCab, Opera ou Mozilla, d'afficher ces liens de façon uniforme, dans leur «Site Navigation Toolbar» (Mozilla), encore appelée «Navigation bar» (Opera).

L'article de Jajob Nielsen sur iCab sur le sujet : http://www.useit.com/papers/icab.html

Je me demande : qui utilise ces liens pour surfer sur le net ?

Pour un intranet, ça a davantage de sens à mon avis. What do you think?

03 juillet 2006

Passage facile à Eclipse 3.2

Eclipse 3.2 : 120 Mo en téléchargement.
Copier/coller du plugin pour Subversion depuis la 3.1.2, et redémarrage sans aucun problème.

C'est beau, la technique.