Mais non, ce n'est pas compliqué.
La session, c'est l'endroit où l'utilisateur fait ses actions.
Elle sert à logger les actions qui ont lieu dans une « unité de connexion », c'est-à-dire entre le moment où l'utilisateur se connecte -- il peut même s'identifier, on ne lui en voudra pas --, et le moment où il se déconnecte -- avec un beau timeout si besoin.
La session permet de rapprocher des actions entre elles, en disant en gros qu'elles sont l'œuvre du même utilisateur.
Les sessions inactives sont effacées au bout de, euh... d'un certain temps.
Le contexte de... données ? de page ? Ce sont des données mises dans un cache temporaire, au sein de la session.
Ce sont des données qui ne bougent pas au sein d'une « unité de consultation ».
Par exemple, lorsque l'utilisateur rapatrie une liste de messages, soit en se connectant une première fois, soit en cliquant sur « Rafraîchir », soit en effectuant une recherche, cela crée un contexte au sein de la session. L'utilisateur peut naviguer dans la liste, y lire des messages, la liste reste immuable. En particulier, elle n'est pas impactée par l'arrivée éventuelle de nouveaux messages dans le système. Il faut pour qu'il y ait un tel changement, un rafraîchissement explicite.
Pour ne pas dupliquer les données, ces contextes s'appuient sur des données « versionnées ».
Et pour ne pas faire exploser la base applicative, les contextes de données sont effacés au bout de, euh... disons que quand ça explose c'est trop tard.
Le contexte de... navigation ? de page ? Ce sont des informations de type contexte, qu'on accepte de véhiculer de page en page, pour éviter d'avoir à stocker trop d'informations en base.
Ce contexte suit une « unité de navigation ».
C'est typiquement un type de tri, qui peut être changé à l'affichage, même s'il impacte la navigation, sans avoir à recharger la liste.
Les contextes de navigation sont propagés de page en page, à condition de ne pas s'être vautré dans le code HTML.
Seule la session peut être suivie par un cookie. Et encore, ça coince dans le cas où deux sites sont sur le même serveur.
Le cookie sert donc davantage à la session multi-serveurs.
Hrem... Vaste sujet.
Ainsi, avec les contextes de données on peut faire du multi-écran et naviguer dans deux listes de résultats de recherches différentes, et avec les contextes de navigation on peut naviguer de façons différentes dans une même liste.
C'est super simple, non.
26 juin 2006
Onduleur
Installation de prises parafoudres pour les postes de travail, et d'un onduleur pour le serveur.
Modèle : MGE, UPS SYSTEMS, Protection Center 500. Acheté à la Fnac.
Modèle : MGE, UPS SYSTEMS, Protection Center 500. Acheté à la Fnac.
25 juin 2006
Entreprise > Association > Startup
Comment dire... Entre Paul Graham qui explique dans ses articles comment et pourquoi créer sa startup avec le minimum vital, Jean-Hubert qui détaille avec humour et pédagogie les étapes de la création d'une SARL en France en 2006 -- on fera avec profit également un tour chez Jean-Luc Watine, «Entrepreneurs: Créer et choisir son statut» --, et Laurent Samuel, qui vient de sortir une chronique intitulée L'association 1901 au service d'un projet d'entreprise» sur Envie d'entreprendre (mais si, rappelez-vous, l'infatigable Olivier Marone !)... il y a comme des super prémices, là.
C'est fou comme tout s'enchaîne parfaitement.
Il n'y a qu'à relier les points.
Et sinon, le blog de Laurent Samuel, «Créer et animer une association Loi 1901», me semble tout à fait bien, en ce qui concerne les associations.
C'est fou comme tout s'enchaîne parfaitement.
Il n'y a qu'à relier les points.
Et sinon, le blog de Laurent Samuel, «Créer et animer une association Loi 1901», me semble tout à fait bien, en ce qui concerne les associations.
22 juin 2006
Report annoncé
Diantre, comme le temps passe. Déjà fin juin et pas de béta publique ?
Entre les réunions avec les associations, le développement, l'écriture des statuts, et d'autres choses qui n'ont rien à voir avec les Fûts mais qui ont bousillé le planning, ça n'avance pas comme prévu.
Donc cette semaine j'ai annoncé à deux associations intéressées que la sortie publique de la plateforme Les Fûts était reportée à la rentrée de septembre.
Entre les réunions avec les associations, le développement, l'écriture des statuts, et d'autres choses qui n'ont rien à voir avec les Fûts mais qui ont bousillé le planning, ça n'avance pas comme prévu.
Donc cette semaine j'ai annoncé à deux associations intéressées que la sortie publique de la plateforme Les Fûts était reportée à la rentrée de septembre.
Bugzilla
En termes de bug tracking, Bugzilla est installé sur le PC pour «évaluation». Entendre : on va clairement utiliser le produit, mais on ne le migrera que plus tard sous NetBSD.
Petite remarque, ça commence à faire beaucoup d'outils indispensables qui sont installés ou auprès desquels on est inscrits, mais qui ne sont pas reliés les uns aux autres ! Basecamp, Blogger, forums NNTP, Google Groups, mails, halfj, CruiseControl, Bugzilla, dbdoc, codegendoc, Antdoc...
À part ça, l'installation sous Windows d'une appli web écrite en Perl est encore et toujours un poème. Un poème sale et douloureux, mais un poème.
Petite remarque, ça commence à faire beaucoup d'outils indispensables qui sont installés ou auprès desquels on est inscrits, mais qui ne sont pas reliés les uns aux autres ! Basecamp, Blogger, forums NNTP, Google Groups, mails, halfj, CruiseControl, Bugzilla, dbdoc, codegendoc, Antdoc...
À part ça, l'installation sous Windows d'une appli web écrite en Perl est encore et toujours un poème. Un poème sale et douloureux, mais un poème.
20 juin 2006
Consultations multi-serveurs
Un utilisateur peut faire suivre sa session d'un serveur à l'autre.
Quand il y a des modifications métier, pas de problème, les impacts sont redistribués par le back-end vers les différents serveurs applicatifs.
Mais que se passe-t-il quand il y a des modifications applicatives ? Par exemple l'utilisateur a lu tels messages d'un forum sur tel serveur, ils apparaissent donc comme «lus». Il navigue jusqu'à un autre serveur, qui, pas de bol, donne accès au même forum. Les mêmes messages y apparaissent donc comme «non lus». Et c'est bien le principe : les tâches de consultation se font en local sur les serveurs applicatifs, sans allers-retours vers le back-end. Les deux serveurs sont donc désynchronisés.
Pour permettre de récupérer au cas par cas la cohérence entre les états applicatifs des différents serveurs front-end, il y aura un bouton «Synchronize», qui demandera au back-end de mettre à niveau tous les états applicatifs de l'utilisateur.
Quand il y a des modifications métier, pas de problème, les impacts sont redistribués par le back-end vers les différents serveurs applicatifs.
Mais que se passe-t-il quand il y a des modifications applicatives ? Par exemple l'utilisateur a lu tels messages d'un forum sur tel serveur, ils apparaissent donc comme «lus». Il navigue jusqu'à un autre serveur, qui, pas de bol, donne accès au même forum. Les mêmes messages y apparaissent donc comme «non lus». Et c'est bien le principe : les tâches de consultation se font en local sur les serveurs applicatifs, sans allers-retours vers le back-end. Les deux serveurs sont donc désynchronisés.
Pour permettre de récupérer au cas par cas la cohérence entre les états applicatifs des différents serveurs front-end, il y aura un bouton «Synchronize», qui demandera au back-end de mettre à niveau tous les états applicatifs de l'utilisateur.
Versions des objets métier
Gérer les contextes de navigation, c'est bien. On permet ainsi à l'utilisateur de changer ses modalités d'affichage d'une fenêtre à l'autre. Mais que se passe-t-il quand les données elles-mêmes changent pendant ce temps ?
On voit qu'il faut que chaque contexte de navigation pointe explicitement vers un «jeu de données figé», une baseline, afin de rester cohérent quand on navigue au sein des pages.
Par ailleurs, que se passe-t-il quand les données sont en maintenance ? Par exemple, de nouveaux messages ont été postés, et le back-end effectue en tâche de fond le calcul de tous les threads. Il a besoin pour cela de réserver la totalité des messages, car potentiellement tous les threads vont être modifiés.
On peut utiliser des verrous, que ce soit des verrous applicatifs ou des verrous techniques (les fameuses «transactions». Mouarf). Mais cette solution a le léger inconvénient d'interdire toute autre modification des données pendant la maintenance. Cet inconvénient est léger en effet, car le fait le back-end sert entre autres à ordonnancer les tâches de modification.
Cependant, les verrous ne permettent pas de gérer correctement les contextes de navigation. En effet, quand le verrou est relâché, les données courantes ont été modifiées. Le contexte de navigation est alors invalide.
Et donc... on en revient aux versions, aux baselines.
Les versions correspondent à des «états cohérents» des données. Cette cohérence est assurée par le back-end. Il n'y a jamais de versions concurrentes, jamais de merge.
C'est toujours le back-end qui incrémente les versions, jamais directement l'utilisateur. L'utilisateur ne fait que poster ses demandes d'actions, et c'est le back-end qui en fait la résolution.
On voit qu'il faut que chaque contexte de navigation pointe explicitement vers un «jeu de données figé», une baseline, afin de rester cohérent quand on navigue au sein des pages.
Par ailleurs, que se passe-t-il quand les données sont en maintenance ? Par exemple, de nouveaux messages ont été postés, et le back-end effectue en tâche de fond le calcul de tous les threads. Il a besoin pour cela de réserver la totalité des messages, car potentiellement tous les threads vont être modifiés.
On peut utiliser des verrous, que ce soit des verrous applicatifs ou des verrous techniques (les fameuses «transactions». Mouarf). Mais cette solution a le léger inconvénient d'interdire toute autre modification des données pendant la maintenance. Cet inconvénient est léger en effet, car le fait le back-end sert entre autres à ordonnancer les tâches de modification.
Cependant, les verrous ne permettent pas de gérer correctement les contextes de navigation. En effet, quand le verrou est relâché, les données courantes ont été modifiées. Le contexte de navigation est alors invalide.
Et donc... on en revient aux versions, aux baselines.
Les versions correspondent à des «états cohérents» des données. Cette cohérence est assurée par le back-end. Il n'y a jamais de versions concurrentes, jamais de merge.
C'est toujours le back-end qui incrémente les versions, jamais directement l'utilisateur. L'utilisateur ne fait que poster ses demandes d'actions, et c'est le back-end qui en fait la résolution.
19 juin 2006
Sessions et contextes de navigation
Tout d'abord, les sessions doivent être multi-serveurs.
Bonjour la contrainte technique !
Toute la gestion des sessions doit pouvoir se faire en callback, par l'intermédiaire de services Web. Les timeouts sont multi-serveurs, les authentifications-zet-identifications sont multi-serveurs, les purges sont multi-serveurs.
On en arrive au final à implémenter la gestion des sessions à la mimine.
Chaque serveur front-end a son identifiant public de session (un hash sur 32 caractères, passé en paramètre HTTP «?session=» dans les URLs, avec un jour l'utilisation de cookies), mais des «rapprochements» se font depuis le serveur centralisé back-end.
Ensuite, on implémente les contextes de navigation.
En deux mots, il s'agit de permettre le multi-fenêtrage, ou plus simplement de repérer si l'utilisateur fait du multi-fenêtrage. Il y a en particulier un impact sur les paginations de listes.
Ainsi, si l'utilisateur affiche une liste paginée de messages dans la fenêtre #1, navigue un peu dedans, charge la même liste dans la fenêtre #2, y fait «Refresh» pour récupérer les nouveaux messages, puis revient à la fenêtre #1, s'il reprend sa navigation dans la fenêtre #1 on doit au moins lui dire «Désolé, le contexte a changé, la liste a été rafraîchie» et on le repositionne d'office en première page.
Pour certaines listes, on permet au contraire les deux navigations simultanées, en gérant les deux listes. Par exemple, lorsque les fenêtres #1 et #2 affichent des résultats de recherches : il ne faut pas que la fenêtre #1 soit rafraîchie avec les données de la fenêtre #2. L'intérêt de l'utilisateur était peut-être, justement, de comparer les deux listes de résultats.
Accessoirement, le Back&Reload sera géré avec une notion proche du contexte de navigation. Il devrait simplement y avoir en sus un timeout en clair dans les identifiants publics de formulaires.
Les identifiants publics des contextes de navigation sont des hash de 32 caractères, passés en paramètre HTTP «?context=» dans les URLs.
Note : impossible d'utiliser les cookies pour cette notion, puisqu'elle dépend de la page affichée, et non de la session.
Bonjour la contrainte technique !
Toute la gestion des sessions doit pouvoir se faire en callback, par l'intermédiaire de services Web. Les timeouts sont multi-serveurs, les authentifications-zet-identifications sont multi-serveurs, les purges sont multi-serveurs.
On en arrive au final à implémenter la gestion des sessions à la mimine.
Chaque serveur front-end a son identifiant public de session (un hash sur 32 caractères, passé en paramètre HTTP «?session=» dans les URLs, avec un jour l'utilisation de cookies), mais des «rapprochements» se font depuis le serveur centralisé back-end.
Ensuite, on implémente les contextes de navigation.
En deux mots, il s'agit de permettre le multi-fenêtrage, ou plus simplement de repérer si l'utilisateur fait du multi-fenêtrage. Il y a en particulier un impact sur les paginations de listes.
Ainsi, si l'utilisateur affiche une liste paginée de messages dans la fenêtre #1, navigue un peu dedans, charge la même liste dans la fenêtre #2, y fait «Refresh» pour récupérer les nouveaux messages, puis revient à la fenêtre #1, s'il reprend sa navigation dans la fenêtre #1 on doit au moins lui dire «Désolé, le contexte a changé, la liste a été rafraîchie» et on le repositionne d'office en première page.
Pour certaines listes, on permet au contraire les deux navigations simultanées, en gérant les deux listes. Par exemple, lorsque les fenêtres #1 et #2 affichent des résultats de recherches : il ne faut pas que la fenêtre #1 soit rafraîchie avec les données de la fenêtre #2. L'intérêt de l'utilisateur était peut-être, justement, de comparer les deux listes de résultats.
Accessoirement, le Back&Reload sera géré avec une notion proche du contexte de navigation. Il devrait simplement y avoir en sus un timeout en clair dans les identifiants publics de formulaires.
Les identifiants publics des contextes de navigation sont des hash de 32 caractères, passés en paramètre HTTP «?context=» dans les URLs.
Note : impossible d'utiliser les cookies pour cette notion, puisqu'elle dépend de la page affichée, et non de la session.
15 juin 2006
Présentation à Graine d'école (suite)
Graine d'école est une association de parents sur Pessac, qui propose une approche participative dans l'animation d'un jardin d'enfants (enfants de 2 à 5 ans, lundi, mardi, jeudi et vendredi) et d'un centre de loisirs (à partir de 3 ans, mercredi et vacances scolaires).
Adresse : 12 avenue de Bardanac, La Paillière, Pessac
Téléphone : 05 56 84 99 69
E-mail : grainedecole@wanadoo.fr
Site web : ben, justement...
[Edit du 25/07 : grainedecole.fr est en ligne]
Leur besoin web est d'avoir une visibilité, d'afficher les informations institutionnelles, de permettre de télécharger des documents, et d'afficher le calendrier des événements.
La réunion a été sympa, riche, et constructive.
La présentation des Fûts a évoqué :
Ensuite, l'association a parlé d'un besoin prégnant et urgent, à savoir être référencée, être « trouvable » sur internet. On a décidé que l'association ferait les choses suivantes d'ici fin juin :
Actuellement l'assocation elle-même est connectée à internet via une connexion Wanadoo 56K.
On est partis ensuite sur ce qui pourrait être mis en oeuvre dans un site dédié à l'association. Je pensais qu'il y aurait deux ou trois pages institutionnelles, et un calendrier, mais en fait...
On est arrivés à ceci :
Comme on le voit, on est loin du bête blog + forum + 2 pages de wiki. La structure du site n'est pas énormissime, mais elle existe, et il faut prévoir des formulaires plus élaborés que ce qui était prévu à l'origine.
Adresse : 12 avenue de Bardanac, La Paillière, Pessac
Téléphone : 05 56 84 99 69
E-mail : grainedecole@wanadoo.fr
Site web : ben, justement...
[Edit du 25/07 : grainedecole.fr est en ligne]
Leur besoin web est d'avoir une visibilité, d'afficher les informations institutionnelles, de permettre de télécharger des documents, et d'afficher le calendrier des événements.
La réunion a été sympa, riche, et constructive.
La présentation des Fûts a évoqué :
- l'organisation des Fûts, le prix
- la maintenance technique par les Fûts, les serveurs
- le choix de l'hébergement frontal (et éventuellement du nom de domaine) par l'association
- la gestion de contenu par l'association
- les fonctionnalités de blog, forum, et wiki
- vu l'ampleur de la tâche, quelle est la capacité des Fûts à réaliser
quelque chose pour fin juin ? - pourquoi tout redévelopper en PHP/Java, alors qu'il existe déjà des produits tout faits, comme Joomla!, qui répondent à 95% des besoins d'une association ?
- qui, en pratique, a besoin que ses sites associatifs soient reliés par une infrastructure commune en back-office ?
Ensuite, l'association a parlé d'un besoin prégnant et urgent, à savoir être référencée, être « trouvable » sur internet. On a décidé que l'association ferait les choses suivantes d'ici fin juin :
- choisir une URL (en .free.fr, en perso.wanadoo.fr, en .com, peu importe)
- publier une page HTML minimaliste (il y a déjà une petite plaquette de l'association, au format Publisher)
- acheter des Google AdWords sur les deux mois d'été pour être visible sur Google
- les Google Groups (forums / listes de diffusion) pour échanger par petits groupes
- l'e-mail direct, pour communiquer des documents, des infos
Actuellement l'assocation elle-même est connectée à internet via une connexion Wanadoo 56K.
On est partis ensuite sur ce qui pourrait être mis en oeuvre dans un site dédié à l'association. Je pensais qu'il y aurait deux ou trois pages institutionnelles, et un calendrier, mais en fait...
On est arrivés à ceci :
- Page d'accueil, présentation
- Mettre le journal de l'association en téléchargement (PDF, très bien)
- Deux sous-sites : le jardin d'enfants, et le centre de loisirs
- Afficher les tarifs, et ce pour chaque sous-site (noter que du PDF en téléchargement suffirait)
- Afficher des photos, et ce pour chaque sous-site
- Donner un planning-type, et ce pour chaque sous-site
- Permettre de demander une inscription, et ce pour chaque sous-site
- Permettre de demander une réservation pour les vacances
- Annuaire privatif, groupes de diffusion
- Trombinoscope ? Complet ? Public ? De l'équipe ? Des membres ? Des enfants ? (question du droit à l'image)
- Calendrier : vacances scolaires, périodes de réservations pour les vacances, programme d'activités, événements de la vie de l'association, tâches participatives
- Besoin que l'association puisse valider des réservations, etc. avant affichage
- Pouvoir envoyer un e-mail en lieu et place d'une participation à un forum, pouvoir être notifié par e-mail de tel type d'événement
- Vie associative : statuts, règlement intérieur, CA, débats
- Fêtes
Comme on le voit, on est loin du bête blog + forum + 2 pages de wiki. La structure du site n'est pas énormissime, mais elle existe, et il faut prévoir des formulaires plus élaborés que ce qui était prévu à l'origine.
12 juin 2006
Présentation à Graine d'école
Jeudi 15, présentation des Fûts à l'intention de l'association Graine d'école.
Milestone sur Basecamp.
Milestone sur Basecamp.
La Mêlée Numérique
Une association dans le Sud-Ouest qui se mêle de NTIC :
http://www.meleenumerique.com/
Trouvé via DebitCredit.fr
http://www.meleenumerique.com/
Trouvé via DebitCredit.fr
Specs
Voici le lien pour les specs de base concernant la plateforme Les Fûts : http://halfj.free.fr/resources/spec/lesfuts/
Le lien permanent est sur la sandbox halfj-site v1.4...
Pour imprimer, ily a bien la version RTF, mais elle doit être un peu buggée. Je corrigerai ça plus tard, quand j'aurai le temps, et accessoirement quand j'aurai Word !
Le lien permanent est sur la sandbox halfj-site v1.4...
Pour imprimer, ily a bien la version RTF, mais elle doit être un peu buggée. Je corrigerai ça plus tard, quand j'aurai le temps, et accessoirement quand j'aurai Word !
11 juin 2006
Encodages
Sal*peries d'encodages.
Quand on fait proprement de l'UTF-8, tous les navigateurs, de Cyberdog sous MacOS 7.6.1 à Firefox sous Windows XP, en passant par Safari sous MacOS X et Netscape 4.5 sous MacOS 8.6, tous les navigateurs, l'affichent proprement. Pour être plus juste, disons que le latin étendu passe à peu près. On peut par exemple écrire « à cœur ouvert », et non « à coeur ouvert », ou je ne sais quel «cÅŋur ouvert»
Mais... comment faire de l'UTF-8 propre ? me direz-vous. N'entend-on pas souvent dire que c'est difficile ? À s'arracher les cheveux ? Sal*peries d'encodages, p*urritures d'accents, diacritiques de mes *, vous voyez le genre.
Eh bien voyez-vous, c'est drôle comme tout devient simple quand :
En effet, il a été décidé de ne pas tester l'application avec Konqueror.
Quand on fait proprement de l'UTF-8, tous les navigateurs, de Cyberdog sous MacOS 7.6.1 à Firefox sous Windows XP, en passant par Safari sous MacOS X et Netscape 4.5 sous MacOS 8.6, tous les navigateurs, l'affichent proprement. Pour être plus juste, disons que le latin étendu passe à peu près. On peut par exemple écrire « à cœur ouvert », et non « à coeur ouvert », ou je ne sais quel «cÅŋur ouvert»
Mais... comment faire de l'UTF-8 propre ? me direz-vous. N'entend-on pas souvent dire que c'est difficile ? À s'arracher les cheveux ? Sal*peries d'encodages, p*urritures d'accents, diacritiques de mes *, vous voyez le genre.
Eh bien voyez-vous, c'est drôle comme tout devient simple quand :
- les données sont réparties sur un système de fichiers Linux et une base de données 8bit MySQL 3,
- les navigateurs sont Firefox, Netscape 4, Netscape 7, Opera, IE 4.01, IE 4.5, IE 5.2, IE 6, Mozilla, Cyberdog, Amaya, iCab, Safari, OmniWeb, Camino, et Cyberdog
- les systèmes d'exploitation sont Windows XP, MacOS 7.6.1, MacOS 8.6, MacOS « Classic » 9.1, et MacOS X
- certains navigateurs veulent voir arriver des octets masqués à 0x7F, c'est-à-dire qu'ils comprennent bien les entités HTML ou XML comme «ŋ», mais pas des octets arbitraires comme « Åŋ »
- le langage de programmation est PHP 4, où les String sont en 8bit
- sur un autre serveur le langage est Java, où les String sont obligatoirement en Unicode
- il y a des appels distribués dans l'architecture (re-masquage à 0x7F, etc.)
- les feuilles XSLT qui doivent cracher de l'UTF-8 sont écrites en ISO-8859-1
- on développe à la fois sous Windows et MacOS, dont les encodages sont incompatibles (Windows CP1252 et MacOS Roman), et les sources sont en ISO-8859-1
- la gestion de conf se fait avec Subversion sous NetBSD
En effet, il a été décidé de ne pas tester l'application avec Konqueror.
08 juin 2006
Bouffe : Les Fûts
La prochaine bouffe des Fûts, partie architecture, se tiendra à Pessac lundi 12 juin.
Ordre du jour :
Ordre du jour :
- Est-il encore pertinent d'espérer des spécifications après une semaine de retard ?
- À quoi servent des timezones dans une application franco-bordelaise ?
- Faut-il vraiment un annuaire LDAP pour gérer 10 utilisateurs ?
- La politique de stockage des données est-elle cohérente ?
- L'absence de procédure de backup est-elle réellement une source de
« bon stress » ? - Comment se fait-il que certains de nos concurrents payants qui ont démarré un an plus tôt que nous avec plusieurs millions de dollars et une dizaine de gourous de Ruby on Rails à plein temps, aient déjà vu leurs startups mourir ? Alors que nous ne sommes ni payants, ni riches, ni on Rails ?...
- Est-on sûr que la prise en compte des timezones dans notre application soit un bon facteur de différenciation par rapport à ces startups ?
07 juin 2006
Rédaction de documentation
C'est ballot, je devais écrire une première mouture des specs des Fûts pour la semaine dernière, et... rien.
C'est que, croyant bien faire, j'ai bloqué les phases de rédaction, qu'il s'agisse de documentation, de spécifications, de manuels d'utilisateurs, de manuels de développement... le jeudi.
Eh oui, chaque jeudi, ni plus, ni moins, est une journée entièrement bloquée pour la rédaction, ou plus exactement la mise au propre de notes éparses. Vu la nécessité d'avoir des docs, et en même temps la priorité accordée aux développements, ce Time-boxing hebdomadaire me semble adéquat.
Manque de bol, ce premier jeudi était le 1er juin, et ça faisait à peu près 4 mois qu'il était prévu chômé.
Elle est bien partie, cette documentation.
C'est que, croyant bien faire, j'ai bloqué les phases de rédaction, qu'il s'agisse de documentation, de spécifications, de manuels d'utilisateurs, de manuels de développement... le jeudi.
Eh oui, chaque jeudi, ni plus, ni moins, est une journée entièrement bloquée pour la rédaction, ou plus exactement la mise au propre de notes éparses. Vu la nécessité d'avoir des docs, et en même temps la priorité accordée aux développements, ce Time-boxing hebdomadaire me semble adéquat.
Manque de bol, ce premier jeudi était le 1er juin, et ça faisait à peu près 4 mois qu'il était prévu chômé.
Elle est bien partie, cette documentation.
Productivité
Au programme de réalisation ces temps-ci : un module de forum.
Je m'inspire évidemment du développement que j'avais fait en 2001, Fontguinews.
L'architecture pour les Fûts est à peu près claire dans ma tête : un vague cache applicatif chez free, et un serveur J2EE centralisé avec un protocole très proche de NNTP dans l'esprit.
Pour Fontguinews, c'était parti sur du 100% PHP chez free, puis les Web Services de distribution avaient vu le jour un an après, toujours en PHP. Cette solution était pratique pour partager rapidement des forums entre applis (voir le forum de Mobiles Sans Gêne, qui fait des accès distribués sur Fontguinews. L'aéro-club de Bordeaux s'en était servi également), mais peu satisfaisante en termes d'arthitecture.
Je m'étais dit que pour refaire un système de forums, je penserais de suite à la distribution. Je dois avoir dans un coin des schémas de ce système qui datent de 2003.
Donc, distribution. Donc, découplage. Donc, communication asynchrone.
Et donc aujourd'hui... la partie applicative peut être maquettée à 90% en ne s'intéressant qu'aux fonctionnalités de consultation des messages. Tout ce qui concerne la publication des messages sera déportée sur le serveur J2EE. Les 10% manquants sont la gestion par l'applicatif des erreurs de publication.
Pour le maquettage de la consultation, évidemment, la transformation des données de présentation en XHTML se fait par XSLT, et les cas à valider sont décrits en XML.
On verra par la suite pour une solution PHP, si, vraiment, les perfs sont si mauvaises que ça.
Les principes étant mis en place, et ma machine de développement étant très rapide, je n'aurais qu'un mot de constat : productivité.
J'avais déjà été efficace pour fontguinews, mais là je dois être dopé.
Est-ce la sieste récupératrice obligatoire de l'après-midi ? (il fait chaud, en juin)
Sont-ce les symphonies de Beethoven ? (c'est pourtant simple : en phases de maquettage ou de prototypage, Beethoven flamboyant, et en phase de débuggage, Chopin mélancolique. Je ne comprends pas pourquoi cette pure pratique n'est pas davantage répandue. M'enfin ! Quant au style de musique pour les phases de codage, eh eh, suspense).
Je me demande si tout cela ira aussi vite pour la suite.
Je m'inspire évidemment du développement que j'avais fait en 2001, Fontguinews.
L'architecture pour les Fûts est à peu près claire dans ma tête : un vague cache applicatif chez free, et un serveur J2EE centralisé avec un protocole très proche de NNTP dans l'esprit.
Pour Fontguinews, c'était parti sur du 100% PHP chez free, puis les Web Services de distribution avaient vu le jour un an après, toujours en PHP. Cette solution était pratique pour partager rapidement des forums entre applis (voir le forum de Mobiles Sans Gêne, qui fait des accès distribués sur Fontguinews. L'aéro-club de Bordeaux s'en était servi également), mais peu satisfaisante en termes d'arthitecture.
Je m'étais dit que pour refaire un système de forums, je penserais de suite à la distribution. Je dois avoir dans un coin des schémas de ce système qui datent de 2003.
Donc, distribution. Donc, découplage. Donc, communication asynchrone.
Et donc aujourd'hui... la partie applicative peut être maquettée à 90% en ne s'intéressant qu'aux fonctionnalités de consultation des messages. Tout ce qui concerne la publication des messages sera déportée sur le serveur J2EE. Les 10% manquants sont la gestion par l'applicatif des erreurs de publication.
Pour le maquettage de la consultation, évidemment, la transformation des données de présentation en XHTML se fait par XSLT, et les cas à valider sont décrits en XML.
On verra par la suite pour une solution PHP, si, vraiment, les perfs sont si mauvaises que ça.
Les principes étant mis en place, et ma machine de développement étant très rapide, je n'aurais qu'un mot de constat : productivité.
J'avais déjà été efficace pour fontguinews, mais là je dois être dopé.
Est-ce la sieste récupératrice obligatoire de l'après-midi ? (il fait chaud, en juin)
Sont-ce les symphonies de Beethoven ? (c'est pourtant simple : en phases de maquettage ou de prototypage, Beethoven flamboyant, et en phase de débuggage, Chopin mélancolique. Je ne comprends pas pourquoi cette pure pratique n'est pas davantage répandue. M'enfin ! Quant au style de musique pour les phases de codage, eh eh, suspense).
Je me demande si tout cela ira aussi vite pour la suite.
05 juin 2006
Le nom « Les Fûts »
FÛT [fy] n.m. (lat. fustis, bâton).
1. Partie du tronc d'un arbre dépourvue de rameaux.
2. Corps d'une colonne, entre la base et le chapiteau.
3. Tonneau.
4. Monture servant de support. Fût en bois d'un fusil. Fût d'un candélabre, d'un rabot.
5. Caisse (d'un tambour).
Et donc, voici l'explication a posteriori du choix de ce nom :
Il fallait un terme rattaché à l'architecture (c'est le cas de la définition 2.) ; on était également partis sur des métaphores sylvestres, le foisonnement d'arbres en forêt évoquant la multiplicité des gens qu'on trouve en associations. Et le projet se charge bien de donner un socle aux sites web associatifs, pas de s'y substituer. Donc ne parler que du tronc (1.), sans toucher aux frondaisons, ça collait.
Et puis, ben, on est de Bordeaux, ne l'oublions pas (3.).
Ah, et il faut dire qu'on avait une autre idée, mais elle était déjà prise.
Maintenant, hein, comme on dit le débat reste ouvert :-)
1. Partie du tronc d'un arbre dépourvue de rameaux.
2. Corps d'une colonne, entre la base et le chapiteau.
3. Tonneau.
4. Monture servant de support. Fût en bois d'un fusil. Fût d'un candélabre, d'un rabot.
5. Caisse (d'un tambour).
Et donc, voici l'explication a posteriori du choix de ce nom :
Il fallait un terme rattaché à l'architecture (c'est le cas de la définition 2.) ; on était également partis sur des métaphores sylvestres, le foisonnement d'arbres en forêt évoquant la multiplicité des gens qu'on trouve en associations. Et le projet se charge bien de donner un socle aux sites web associatifs, pas de s'y substituer. Donc ne parler que du tronc (1.), sans toucher aux frondaisons, ça collait.
Et puis, ben, on est de Bordeaux, ne l'oublions pas (3.).
Ah, et il faut dire qu'on avait une autre idée, mais elle était déjà prise.
Maintenant, hein, comme on dit le débat reste ouvert :-)
02 juin 2006
Projet associatif
Pour démarrer, « Les Fûts » est une organisation à but non lucratif, qui s'occupe de mettre à disposition auprès d'associations françaises de type loi 1901, un site web.
Chaque association concernée peut demander l'ouverture d'un site web à son nom, site web qui sera géré d'un point de vue technique (mise en place des serveurs, etc.) par les Fûts, et qui sera alimenté et maintenu en termes de contenu par l'association elle-même.
C'est l'association elle-même qui édite ses articles, met en forme ses pages, rajoute ses photos, organise des discussions, etc.
Les Fûts ne s'occupent que de la partie technique.
Les sites associatifs seront dans un premier temps constitués de briques de base très populaires actuellement : blogs, forums, wikis... L'ambition des Fûts est de faciliter l'accès aux technologies répandues de l'internet grand public, à des petites associations qui n'ont pas forcément le temps ni le budget d'investir directement dans ce domaine.
Pourquoi penser à un statut associatif pour les Fûts ?
Le projet a pour ambition de donner un accès minimal à internet, à des petites associations. Le projet est donc délibérément à but non lucratif, pour pouvoir être totalement centré sur la philosophie du service.
Deuxièmement, la solution technique choisie est une mutualisation des moyens techniques pour héberger les sites associatifs. Cette mutualisation se traduit par une certaine homogénéité des sites. Il faut donc que les associations puissent exprimer leurs préférences, et décider ensemble des orientations.
La forme associative semble être un bon candidat.
Chaque association concernée peut demander l'ouverture d'un site web à son nom, site web qui sera géré d'un point de vue technique (mise en place des serveurs, etc.) par les Fûts, et qui sera alimenté et maintenu en termes de contenu par l'association elle-même.
C'est l'association elle-même qui édite ses articles, met en forme ses pages, rajoute ses photos, organise des discussions, etc.
Les Fûts ne s'occupent que de la partie technique.
Les sites associatifs seront dans un premier temps constitués de briques de base très populaires actuellement : blogs, forums, wikis... L'ambition des Fûts est de faciliter l'accès aux technologies répandues de l'internet grand public, à des petites associations qui n'ont pas forcément le temps ni le budget d'investir directement dans ce domaine.
Pourquoi penser à un statut associatif pour les Fûts ?
Le projet a pour ambition de donner un accès minimal à internet, à des petites associations. Le projet est donc délibérément à but non lucratif, pour pouvoir être totalement centré sur la philosophie du service.
Deuxièmement, la solution technique choisie est une mutualisation des moyens techniques pour héberger les sites associatifs. Cette mutualisation se traduit par une certaine homogénéité des sites. Il faut donc que les associations puissent exprimer leurs préférences, et décider ensemble des orientations.
La forme associative semble être un bon candidat.
Inscription à :
Articles (Atom)