31.12.04
Le jouet du jour (2)
Première navigation dans la base complète du Wikipedia français. Il y a encore quelques ajustement à faire sur la taille des "blocs" de définitions pour que l'accès soit le plus instantané possible, mais au moins la lecture des dumps et l'indexation globale fonctionnent correctement.
Petit aperçu obligatoire. Les 2 zones d'affichages sont là pour comparer les performance et la qualité entre un rendu NSTextView et un rendu WebKit:
Petit aperçu obligatoire. Les 2 zones d'affichages sont là pour comparer les performance et la qualité entre un rendu NSTextView et un rendu WebKit:
30.12.04
Le jouet du jour
... avance, indexe, marne, grattouille...
En résumé: le prétraitement du Wikipedia français pour une consultation locale prend une petite minute. L'indexation plein texte une trentaine de minutes. Le tout étant plutôt encourageant.
wikihandler processed 68370 entries
En résumé: le prétraitement du Wikipedia français pour une consultation locale prend une petite minute. L'indexation plein texte une trentaine de minutes. Le tout étant plutôt encourageant.
29.12.04
Theatre - Trois jours de pluie
"Trois jours de pluie" au Théatre de l'Atelier.
Un (deux) trio(s) amoureux, à deux époques, dans chaque génération. Un joli texte, nerveux, incisif, sur l'impossibilité de connaître vraiment un père, la filiation, l'héritage des sentiments et des choses. Léa Drucker très bonne. Pour rester dans les pièces de l'an dernier de ce même théatre, peut-être moins scalpel que "5 filles couleur pêche" et moins bluffant que l'"Hiver sous la table", mais un beau moment de théatre. Très beau jeu sur un décor aux murs bruts, juste habité par de grands panneaux translucides.
27.12.04
Un épisode américain
J'ai failli avoir un peu de sang américain. Ou, plus exactement, je suis sans doute là parce que je n'en ai pas.
Mes arrière-arrière grand parents, Charles et Aline Ablitzer, ont émigré aux états-unis à la fin du 19ème siècle.
J'ai retrouvé hier leur trace sur la Ellis Island Foundation, qui a numérisé et indexé les listes des immigrants qui ont débarqué à New York entre 1890 et 1921.
Nous n'avons que peu de traces de cet épisode outre-atlantique. Quelques photos, et un petit fauteuil à bascule d'enfant, au cannage percé.
Je ne sais pas vraiment pourquoi ils ont décidé d'émigrer. La soeur de Charles Ablitzer y était partie dans les années 1880, a trouvé son mari et est restée là-bas. Peut-être ont-ils voulu suivre son exemple.
Au départ du Havre, ils sont arrivés sur "La Normandie", le 14 août 1893.
Le registre d'Ellis island n'a que peu de choses sur les quatre membres de cette famille, notés entre un mineur italien et sa femme et une famille de laboureurs. La profession des Ablitzer est marquée comme "druggist", et les âges sont reportés: Charles a 27 ans, sa femme Aline 25 ans, 3 ans et 6 mois pour Aline, mon arrière-grand-mère, et 2 ans pour la cadette Jeanne, qui n'a sans doute gardé aucun souvenir de cette arrivée.
Ils sont arrivés dans une Ellis Island toute neuve, inaugurée un an et demi avant, et avant l'application de la réforme de 1893 de l'immigration, avant qu'il soit nécessaire de savoir si les immigrants avaient plus de 30 dollars en poche, s'ils savaient lire ou écrire, ou s'ils étaient polygames ou anarchistes.
Le seul élément un peu moins bureaucratique qui me fait les imaginer en train d'arriver près d'une statue de la Liberté vieille de même pas dix ans, c'est le nombre de bagages: deux, pour toute la famille. Sans doute deux grosses malles d'émigrants. Et leur destination finale n'était manifestement pas bien assurée puisque l'officier a rajouté quelques points d'interrogation derrière St-Louis. Ils avaient sans doute une vague idée puisqu'ils se sont effectivement établis dans le Missouri, à Crystal City, à une soixantaine de kilomètre de St-Louis.
Une autre bribe, c'est cette photo, prise en Amérique. Les deux filles sont là, mon arrière-grand-mère est sans doute la plus grande, et on y voit maintenant Léon, en robe, né aux USA en 1895.
Léon qui plus tard sera tué pendant la grande guerre, dans le secteur de la Malmaison. J'ai retrouvé sur le site du ministère de la défense sa fiche, dont l'exotisme tient dans ce lieu de naissance, Crystal City (Département: "Amérique", comme l'a rempli un fonctionnaire manifestement un peu ennuyé par la rigidité des formulaires).
La mère est là, aussi. Cette photo date de 1896 à peu près, et cette année-là naîtra Charles, le 25/10, qui mourra deux jours plus tard. Sa mère décèdera deux mois après, deux jours avant la nouvelle annéee 1894. Je ne sais si c'est suite à cette naissance tragique.
L'aventure américaine des Ablitzer finira peu de temps après. Charles, veuf, ramènera ses trois enfants en France et mon arrière-grand-mère mourra finalement dans la commune où elle est née, à 91 ans. J'ai des souvenirs d'elle, mais j'étais encore trop jeune pour lui dire une phrase en anglais, et savoir si elle avait gardé des souvenirs de la langue de son enfance.
20.12.04
Theatre - A la folie
"A la folie, pas du tout" au théatre de l'Atelier. Courte pièce sur l'amour finissant d'un vieux couple, en forme de petits collages, ébauches de scènes. Très bons comédiens, texte un peu trop léger. Oubliable.
Debugging et parallelisme
Tirons sur une ambulance
Une petite nouvelle qui est passée presque inaperçue (merci huge): HP se retire du projet Itanium. Oui, HP, ceux qui ont fourni les bases du processeur en refilant l'archi de HP-PA à Intel et qui ont parié leur activité serveur sur l'Itanium. Mais s'ils le font, c'est juste pour être sympa avec les concurrents:
Encore un signe de l'avenir flamboyant de l''Itanium, un des plus beaux examples de FUD des 10 dernières années. Itanium, alias Merced dans ses jeunes années, c'est quand même ce processeur qui allait changer la face de l'informatique, réorienter la politique des constructeurs. Ce processeur né en 1994 et sur lequel tout le monde allait réorienter son activité.
Qu'on en juge:
Et heureusement, des études détaillées offraient des avis mesurés et réalistes sur le futur du processeur:
Enfin tout ceci, c'est le passé. Heureusement que certaines entreprises regardent vers l'avenir avec des paillettes de lumière dans les yeux et les cheveux au vent. Back to the future, baby !
For Palo Alto, California-based HP, cleaving off the last of its Itanium design team frees it from concern that the close relationship between HP and Intel put HP's server rivals at a competitive disadvantage, said Rich Marcello, who runs HP's business critical systems group.
"There was a disadvantage in terms of other (server manufacturers) feeling like the Intel-HP relationship was a little too close," Marcello said. "This kind of levels the playing field in terms of microprocessor development."
Encore un signe de l'avenir flamboyant de l''Itanium, un des plus beaux examples de FUD des 10 dernières années. Itanium, alias Merced dans ses jeunes années, c'est quand même ce processeur qui allait changer la face de l'informatique, réorienter la politique des constructeurs. Ce processeur né en 1994 et sur lequel tout le monde allait réorienter son activité.
Qu'on en juge:
- Solaris sur Itanium !
- NT sur Itanium !
- Irix sur Itanium !
- MacOS sur Itanium !
- Monterey sur Itanium !
- Tru64 sur Itanium !
Et heureusement, des études détaillées offraient des avis mesurés et réalistes sur le futur du processeur:
"Merced heralds a new chapter in enterprise computing. In a nutshell, it will change the way that microprocessors, memory, compilers, and applications interact to support business-critical environments."
Enfin tout ceci, c'est le passé. Heureusement que certaines entreprises regardent vers l'avenir avec des paillettes de lumière dans les yeux et les cheveux au vent. Back to the future, baby !
19.12.04
Enseignement de l'Objet
Intéressante discussion avec Jacques il y a quelques jours sur l'évolution du développement objet, et en particulier de l'enseignement de l'objet.
Constat de départ: le développement objet commence à se séparer en deux branches. Le développement de composants, et le développement de conteneurs/frameworks. Quelle est alors la place dans ce cadre de l'enseignement classique des concepts objet (classe/instance, héritage, envoi de message, aggrégation/composition, etc) ?
Bref, le monde commence à se séparer entre ceux qui vont mettre en place de quoi faire de la réutilisation, et ceux qui vont effectivement bénéficier de la réutilisation.
Les développeurs de composants
Le fait est que le boulot de développement orienté sur le composant nécessite plus et moins: plus, dans le sens où il faut une compréhension globale (pas forcément très en profondeur d'ailleurs) du framework dans lequel on s'insère. Cet apprentissage est d'ailleurs souvent assez implicite.
Comme le développeur se place dans une optique d'héritage et de spécialisation, une grande partie de la complexité du framework sous-jacent peut être masquée - plus (i.e. Swing) ou moins (i.e. J2EE). De plus en plus d'outils existent et favorisent ce style de développement. L'architecture dans ce cadre est relativement limitée, il est rare de trouver de vrais cas de réutilisations au niveau des classes, la réutilisation se fait plutôt par grands blocs fonctionnels, c'est à dire de composants eux-même, et non de portions de composants. Bref, on fait de l'objet dans le cadre du composant comme on pouvait (presque) faire du procédural, assez contraint et guidé par le modèle de composant auquel on se contraint.
Et au niveau du modèle objet, même si les bases sont nécessaires, les techniques de conception un peu évoluées ne sont pas forcément nécessaires. Par contre, il peut s'avérer très déstabilisant au départ de se retrouver face au "Principe d'Hollywood" (don't call us - we'll call you): c'est le framework autour qui contrôle le flux d'exécution, on est loin du "void main / hello world" canonique: il s'agit de réagir à des informations que va transmettre le framework, se faire appeler, persister, activer... Et l'idée forte d'Andrea Stein qu'il peut être bien plus pertinent de repenser l'apprentissage des concepts de base autour de la notion de boucle de traitement est sans doute directement applicable.
Les développeurs de frameworks
Autre grand domaine d'activité: la conception et le développement des frameworks eux-même. C'est la conception objet au sens classique, mais avec des préoccupations en plus. C'est peut-être plus le domaine des Patterns, de l'architecture. Contrairement à l'opinion générale, il est sans doute possible d'imaginer de l'enseignement dans ce domaine. Par exemple en mettant l'accent sur des préoccupation comme la montée en charge (y'a-t'il une meilleure traduction pour 'scalability' ?), la maîtrise de la charge mémoire, les préoccupations de déploiement et de distribution, la surveillance de l'applicatif résultant, le debugging.
Les outils sont assez pauvres dans ce domaine. Il y a un manque criant d'outils pour représenter, visualiser, agir sur des architectures de taille conséquente. Bref, il faudrait des techniques style LXR, mais à un cran d'abstraction supérieur. Tim Bray faisait remarquer par exemple que les outils de debugging pour les archis multithread sont dramatiquement manquant. Le développement test-based est une arme intéressante dans ce domaine-ci, mais on retombe très rapidement dans des problèmes d'expression (cf. l'exemple des threads, par exemple) ou d'exploitation (des expérimentations comme Tarantula sont à suivre).
Bref, il faudrait pour le haut-niveau des outils comme Shark pour le bas-niveau. Problème: cela nécessite déjà la capture d'une masse de donnée conséquente (il faut travailler niveau instance et ligne de code) et l'exploiter d'une façon pertinente (sans doute avec des traitements statistiques). Peut-être qu'on va finir par voir la prédiction de Daniel Hillis se réaliser
Notes annexes
Inconnues pouvant faire basculer cette distinction: la place des langages très dynamiques et leur intégration avec le monde objet classique (Groovy, IronPython, bref, les langages dynamiques implémentés dans le CLR ou une JVM), l'apparition ou non d'outils de développement véritable neutres / orientés point de vue, etc.
Une opposition intéressante vue sur le C2 Wiki
Constat de départ: le développement objet commence à se séparer en deux branches. Le développement de composants, et le développement de conteneurs/frameworks. Quelle est alors la place dans ce cadre de l'enseignement classique des concepts objet (classe/instance, héritage, envoi de message, aggrégation/composition, etc) ?
Bref, le monde commence à se séparer entre ceux qui vont mettre en place de quoi faire de la réutilisation, et ceux qui vont effectivement bénéficier de la réutilisation.
Les développeurs de composants
Le fait est que le boulot de développement orienté sur le composant nécessite plus et moins: plus, dans le sens où il faut une compréhension globale (pas forcément très en profondeur d'ailleurs) du framework dans lequel on s'insère. Cet apprentissage est d'ailleurs souvent assez implicite.
Comme le développeur se place dans une optique d'héritage et de spécialisation, une grande partie de la complexité du framework sous-jacent peut être masquée - plus (i.e. Swing) ou moins (i.e. J2EE). De plus en plus d'outils existent et favorisent ce style de développement. L'architecture dans ce cadre est relativement limitée, il est rare de trouver de vrais cas de réutilisations au niveau des classes, la réutilisation se fait plutôt par grands blocs fonctionnels, c'est à dire de composants eux-même, et non de portions de composants. Bref, on fait de l'objet dans le cadre du composant comme on pouvait (presque) faire du procédural, assez contraint et guidé par le modèle de composant auquel on se contraint.
Et au niveau du modèle objet, même si les bases sont nécessaires, les techniques de conception un peu évoluées ne sont pas forcément nécessaires. Par contre, il peut s'avérer très déstabilisant au départ de se retrouver face au "Principe d'Hollywood" (don't call us - we'll call you): c'est le framework autour qui contrôle le flux d'exécution, on est loin du "void main / hello world" canonique: il s'agit de réagir à des informations que va transmettre le framework, se faire appeler, persister, activer... Et l'idée forte d'Andrea Stein qu'il peut être bien plus pertinent de repenser l'apprentissage des concepts de base autour de la notion de boucle de traitement est sans doute directement applicable.
Les développeurs de frameworks
Autre grand domaine d'activité: la conception et le développement des frameworks eux-même. C'est la conception objet au sens classique, mais avec des préoccupations en plus. C'est peut-être plus le domaine des Patterns, de l'architecture. Contrairement à l'opinion générale, il est sans doute possible d'imaginer de l'enseignement dans ce domaine. Par exemple en mettant l'accent sur des préoccupation comme la montée en charge (y'a-t'il une meilleure traduction pour 'scalability' ?), la maîtrise de la charge mémoire, les préoccupations de déploiement et de distribution, la surveillance de l'applicatif résultant, le debugging.
Les outils sont assez pauvres dans ce domaine. Il y a un manque criant d'outils pour représenter, visualiser, agir sur des architectures de taille conséquente. Bref, il faudrait des techniques style LXR, mais à un cran d'abstraction supérieur. Tim Bray faisait remarquer par exemple que les outils de debugging pour les archis multithread sont dramatiquement manquant. Le développement test-based est une arme intéressante dans ce domaine-ci, mais on retombe très rapidement dans des problèmes d'expression (cf. l'exemple des threads, par exemple) ou d'exploitation (des expérimentations comme Tarantula sont à suivre).
Bref, il faudrait pour le haut-niveau des outils comme Shark pour le bas-niveau. Problème: cela nécessite déjà la capture d'une masse de donnée conséquente (il faut travailler niveau instance et ligne de code) et l'exploiter d'une façon pertinente (sans doute avec des traitements statistiques). Peut-être qu'on va finir par voir la prédiction de Daniel Hillis se réaliser
The second reason for believing in physical/computational model convergence is more profound and therefore more likely to be wrong. Both sciences study large systems of weakly interacting components. Such systems, with local rules of interaction, often seem to have simple macrolaws. This may be due to some "law of large systems" [...]
Notes annexes
Inconnues pouvant faire basculer cette distinction: la place des langages très dynamiques et leur intégration avec le monde objet classique (Groovy, IronPython, bref, les langages dynamiques implémentés dans le CLR ou une JVM), l'apparition ou non d'outils de développement véritable neutres / orientés point de vue, etc.
Une opposition intéressante vue sur le C2 Wiki
ObjectOrientedProgramming = Polymorphism + (Some) Late Binding + (Some) Encapsulation + Inheritance
ComponentOrientedProgramming = Polymorphism + (Really) Late Binding + (Real, Enforced) Encapsulation + Interface Inheritance + Binary Reuse
18.12.04
Eloge de la dispersion
Ou pourquoi Ocean's Twelve est vraiment réussi.
17.12.04
Treize choses terriblement datées
- JavaStation
- Monterey project
- Castanet
- OpenDoc
- "We are the dot in .com"
- Cairo
- Constellation
- Firefly
- General Magic et TeleScript
- Les CD-I
- UnitedLinux
- Altavista
- WebTV
D'autres idées ?
13.12.04
L'amusement du jour (bis)
Le jouet du jour progresse. Que la syntaxe Wikipedia est pénible à parser correctement.
Pour le moment, l'extracteur de dump est séparé, et le convertisseur de syntaxe Wiki est primitif (pas encore de traitement propre de toutes les formes de liens ou de formes en ligne), mais au moins ça affiche quelque chose.
Etapes suivantes: rajouter les syntaxes manquantes, gérer correctement le saut d'articles, donner le texte complet des articles à manger au SearchKit... et voir là où tout explose sous la charge.
Pour le moment, l'extracteur de dump est séparé, et le convertisseur de syntaxe Wiki est primitif (pas encore de traitement propre de toutes les formes de liens ou de formes en ligne), mais au moins ça affiche quelque chose.
Etapes suivantes: rajouter les syntaxes manquantes, gérer correctement le saut d'articles, donner le texte complet des articles à manger au SearchKit... et voir là où tout explose sous la charge.
12.12.04
L'amusement du jour
Faire une petite application qui permette de consulter localement Wikipedia.
Donc:
Pas de la haute voltige en terme de développement, mais ça permet de jouer avec des grosses masses de données. D'où des problèmes intéressants en terme de parsing, lazy-loading, etc.
Donc:
- Récupération d'un dump
- Extraction des fiches à partir des INSERT sql
- Indexation globale (probablement à coups de SearchKit)
- Petite appli de navigation
- Convertisseur Wikisyntax vers texte riche (probablement une NSAttributedString, ou du HTML directement).
- Réécriture des liens Wiki pour sauter vers d'autres définitions
Pas de la haute voltige en terme de développement, mais ça permet de jouer avec des grosses masses de données. D'où des problèmes intéressants en terme de parsing, lazy-loading, etc.
11.12.04
Plus c'est long, plus c'est bon
"Il suppliait Dieu que la foudre de la justice divine fulminât Fermina Daza au moment où elle s'apprêterait à jurer amour et obéissance à un homme qui ne voulait pour épouse qu'un ornement social, et il s'extasiait devant la vision de la mariée, qui serait sienne ou ne serait à personne, étendue de tout son long sur les dalles de la cathédrale auprès des fleurs d'orangers que la rosée de la mort rendait nivéennes et du torrent mousseux de son voile sur les marbres funéraires de quatorze évêques ensevelis face au maître-autel."
Gabriel García Márquez - L'amour au temps du Choléra
8.12.04
Le Wikipedia Meme
Chic, un nouveau meme, le Wikipedia Meme !
Le principe est simple: vous allez sur Wikipedia, et vous cliquez sur le lien Une page au hasard dans le cadre Navigation sur la gauche. Et vous faites ça 5 fois de suite.
Ça donne donc:
Ce qui nous donne un score, disons, de 4 sur 5.
Le principe est simple: vous allez sur Wikipedia, et vous cliquez sur le lien Une page au hasard dans le cadre Navigation sur la gauche. Et vous faites ça 5 fois de suite.
Ça donne donc:
- Macintosh 512K, ou, comment le Wikipedia Meme a démarré.
- Danny Boyle, réalisateur britannique. Trainspotting et Petits meurtres entre amis étaient sympathiques, mais depuis l'animal a l'air de se fourvoyer un peu.
- Herzog et de Meuron: une agence d'architecture suisse. Architectes en particulier de la formidable Tate Modern. Si vous passez par Londres, c'est à ne pas rater. Remarquables collections, batiment peu commun et magnifique.
- Jean-Auguste Carrie de Boissy, chef de brigade et baron d'Empire. Vous l'ignoriez, non ?
- Aligot. Mioum. Ce fait remonter, façon aligot de Proust, la saveur de l'Aligot relevé d'une pointe de bleu d'Art et Buffet sur la petite place St Roch à Montpellier, il y a quelques années.
Ce qui nous donne un score, disons, de 4 sur 5.
7.12.04
Duh
Un instant comme souvent où l'on reste admiratif devant l'innovant discours de certains grands managers.
Ou, pour faire court: "Gné ???"
Ou, pour faire court: "Gné ???"
The Playlist Meme
Trouvé via Tao Of Mac
- Open up the music player on your computer.
- Set it to play your entire music collection.
- Hit the "shuffle" command.
- Tell us the title of the next ten songs that show up (with their musicians), no matter how embarrassing. That’s right, no skipping that Carpenters tune that will totally destroy your hip credibility. It’s time for total musical honesty. You can put the list in the comment thread, or write it up in your blog or journal and then post a link in the comments.
- If you get the same artist twice, you may skip the second (or third, or etc.) occurances. You don’t have to, but since randomness could mean you end up with a list of ten song with five artists, you can if you’d like.
- Mustt Mustt, Nusrat Fateh Ali Khan - Mustt Mustt
- Facelift (Live), Soft Machine - Third
- Fugue in C major, BWV 953, Glenn Gould / J-S Bach - Partitas, Preludes & Fugues
- Widow's Walk, Suzanne Vega - Songs In Red And Gray
- Lajok, Geoffrey Oryema - Beat The Border
- Muscle Museum, Muse - Showbiz
- La rupture, Yann Tiersen - Tout est calme
- New Conception Of Jazz 2, Bugge Wesseltoft - New Conceptions of Jazz
- It's My Mind That Works, The Future Sound of London - ISDN
- Dickie's Such An Asshole, Frank Zappa - Broadway The Hard Way
4.12.04
Some mind food
Trouvailles du jour:
James Ellroy c'est plus inattendu, je n'ai pas un goût très assuré pour le noir ou le polar, mais il est vrai que j'avais retenté ce genre il y a quelques mois - un américain contemporain aussi et j'y avais retrouvé un plaisir inhabituel.
En fait pour "American Tabloid", c'est sans doute un peu plus complexe, et lié à ma fascination du moment pour les auteurs américains actuels qui explorent la face sombre du rêve américain. Bien sûr DeLillo avec "Outremonde" ou "Libra", mais aussi "L'homme dé" de Luke Rhinehart, les essais de Mike Davis, ... Et évidemment, le mélange de réalité et fiction de cette trilogie sur le revers des années Kennedy, Hoover, Howard Hugues... Ça promet.
Et "Le Dahlia Noir" ? Sur le point de prendre le second tome de la trilogie, "American Death Trip", j'ai eu le réflexe d'aller vers le moins naturel, un (vrai) polar.
- "Playmachine", Wibutee
- "American Tabloid", James Ellroy
- "Le Dahlia Noir", James Ellroy
James Ellroy c'est plus inattendu, je n'ai pas un goût très assuré pour le noir ou le polar, mais il est vrai que j'avais retenté ce genre il y a quelques mois - un américain contemporain aussi et j'y avais retrouvé un plaisir inhabituel.
En fait pour "American Tabloid", c'est sans doute un peu plus complexe, et lié à ma fascination du moment pour les auteurs américains actuels qui explorent la face sombre du rêve américain. Bien sûr DeLillo avec "Outremonde" ou "Libra", mais aussi "L'homme dé" de Luke Rhinehart, les essais de Mike Davis, ... Et évidemment, le mélange de réalité et fiction de cette trilogie sur le revers des années Kennedy, Hoover, Howard Hugues... Ça promet.
Et "Le Dahlia Noir" ? Sur le point de prendre le second tome de la trilogie, "American Death Trip", j'ai eu le réflexe d'aller vers le moins naturel, un (vrai) polar.
2.12.04
Nulla dies sine linea
Au programme de la semaine: réactivation du carnet, sur des bases un peu différentes.
L'obsession actuelle c'est le traitement de l'information personnelle. Mes notes, les articles lus, les bouquins à lire, les films vus, les griffonnages complètement personnels, les avis péremptoires, le technique, le non technique, le privé. Avec des problèmes récurrents: comment de pas mélanger l'outil personnel avec la projection personnelle qu'est un web log. Ou comment ne pas voir le simple fait de la lecture d'autrui perturber l'écriture. Lecture d'autrui qui a le mérite de forcer à écrire (cf. titre de cette note, justement).
Solutions possibles:
Le bug final serait d'avoir un blob global où mettre en vrac toutes les notes et notules, et des outils (autour de MetaMeta ?) pour envoyer/fédérer les informations sous différentes formes. Par exemple une notule MindFood a sa place ici (un peu comme ce que fait Kali), mais pas forcément sur "L'autre" carnet.
L'obsession actuelle c'est le traitement de l'information personnelle. Mes notes, les articles lus, les bouquins à lire, les films vus, les griffonnages complètement personnels, les avis péremptoires, le technique, le non technique, le privé. Avec des problèmes récurrents: comment de pas mélanger l'outil personnel avec la projection personnelle qu'est un web log. Ou comment ne pas voir le simple fait de la lecture d'autrui perturber l'écriture. Lecture d'autrui qui a le mérite de forcer à écrire (cf. titre de cette note, justement).
Solutions possibles:
- Un carnet personnel, celui-ci. Nominatif, d'une certaine façon. Sans doute avec une composante technique.
- Un carnet public, non nominatif, non lié. Objet de l'expérience: voir si un carnet-masque m'amène à écrire différement ou sur des sujets différents.
- Mon carnet totalement privé habituel.
- Potentiel: un photoblog/musicblog ?
Le bug final serait d'avoir un blob global où mettre en vrac toutes les notes et notules, et des outils (autour de MetaMeta ?) pour envoyer/fédérer les informations sous différentes formes. Par exemple une notule MindFood a sa place ici (un peu comme ce que fait Kali), mais pas forcément sur "L'autre" carnet.
