avril 2010 (8)

lundi 26 avril 2010

Actualité de la vie privée en ligne

vendredi 23 avril 2010

En vrac

Notes

[1] En fait, le code est partiellement Libre. L'intégration avec la radio et des services comme GMail, GTalk et Market — essentiels pour un téléphone — sont propriétaires.

jeudi 15 avril 2010

En vrac

lundi 12 avril 2010

Le Smartphone de mes rêves

L'industrie du smartphone euh de l'ordiphone est en pleine effervescence. Pour moi qui suis fan de nouvelles technologies, professionnel du Web et souvent mobile[1], j'ai besoin d'un téléphone mobile qui réponde aux besoins suivants :

  1. émettre et recevoir des appels téléphoniques (si, si !)
  2. accéder au Web avec un navigateur moderne et personnalisable
  3. utiliser une application de cartographie avec GPS
  4. synchroniser mes contacts avec mes ordinateurs
  5. accéder à ma messagerie
  6. écouter de la musique stockée sur mes ordinateurs
  7. jouer quand je fais ma gym pour éviter de voir le temps passer
  8. possibilité d'ajouter des applications (natives ou Web) libres et propriétaires (et éventuellement payantes : je préfère payer que de subir la pub)

Le téléphone doit disposer des choses suivantes :

  1. une interface utilisateur bien pensée, intuitive et qui soit agréable à utiliser
  2. une autonomie correcte (2 jours ou plus)
  3. Une connexion à Internet via 3G et Wifi
  4. être hautement "bidouillable" : possibilité de créer, porter, partager, exécuter des applications sans avoir à demander la permission.
    1. possibilité de choisir son navigateur (Firefox, pour moi, avec ses extensions)
    2. possibilité de réutiliser d'une manière ou d'une autre du logiciel Libre
    3. possibilité d'utiliser la VOIP
    4. la liberté du code source du système d'exploitation est un (gros) plus.
  5. être stable
  6. avoir une bonne résolution d'écran
  7. être respectueux de ma vie privée (l'usage du téléphone ne doit pas être "logué" sur des serveurs et servir à me profiler, d'autant que je suis identifié par mon numéro de téléphone…)
  8. doit me permettre d'utiliser le ou les services que je veux dans le cloud (synchronisation, sauvegarde, réseaux sociaux, etc.) que je dois pouvoir quitter en faveur d'autres qui me conviennent mieux.

Pour l'instant, j'ai testé beaucoup de solutions en essayant les téléphones des collègues, et autant le dire tout de suite, rien ne me convient. J'ai un iPhone 3GS, qui est le moins pire des téléphones que j'ai pu essayer. Certains vous diront, sanglots dans la voix, à quelle point leur iPhone a changé leur vie. C'est effectivement un joli téléphone, plutôt stable (quoique), ergonomique, bien pensé… Mais il a des limitations regrettables qui sont d'autant plus affligeantes qu'elles découlent directement de décisions prises par l'entreprise qui a conçu le produit. Par exemple :

  • Toutes les applications doivent être acceptées par Apple, qui multiplie les bévues
    • Obligation récente d'utiliser un langage approuvé par Apple pour le développement
    • Censure d'applications pour des raisons prétendument "morales"
    • Interdiction des applications qui "dupliquent les fonctionnalités déjà disponibles" et fournies par Apple
    • Contrat de licence aberrant
    • Passage obligé par l'AppStore d'Apple, qui est payant.
  • Il se synchronise uniquement via iTunes (qui ne fonctionne pas sur ma machine Linux), et cette application est devenue horriblement lourde et complexe.
  • Un certain nombre de fonctionnalités sont bridées (Voix sur IP, synchronisation entre les versions mobiles et desktop d'applications impossible via le câble de synchro)
  • Dédain avoué pour la notion de "bidouillabilité" (même le changement de batterie doit être fait par le SAV certifié !).

J'ai aussi testé le BlackBerry (esthétique à la Windows 3.1, pas d'applications disponibles, navigateur consternant). Reste Windows Mobile (stabilité lamentable, ergonomie d'un autre siècle), mais on voit que Microsoft a décidé de ne plus ouvrir la plate-forme aux applications natives pour les futures versions (donc pas possible de choisir son navigateur).

Reste Android. Le navigateur de base est correct (c'est du Webkit, comme Safari d'Apple), et on pourra bientôt (mais quand ?) faire tourner Firefox et ses extensions. Le Nexus One est joli, son écran a une bonne résolution, il est basé sur Linux, il n'y a pas l'obligation de passer par un AppStore centralisé. Par contre, en terme de respect de la vie privée, c'est une catastrophe. Tous les contacts sont stockés chez Google, chaque utilisation de la commande vocale passe par les serveur de Google (associée à votre identifiant, bien sûr)… En substance, le Nexus One est un terminal Google qui fait aussi téléphone (et qui vous permet d'accéder à d'autre services, qui sont probablement surveillés par Google Analytics de toute façon).

A coté, l'iPhone — qui est le smartphone qui répond à tous vos besoins à condition que Steve Jobs les aient pris en compte — ferait presque figure d'innocent aux mains pleine en ce qui concerne notre vie privée. Alors, que choisir ? Google ou Apple ? Nexus One ou iPhone ?

Donner les clés de notre vie privée à Eric Schmidt ou se laisser enfermer dans une prison aux barreaux dorés par Steve Jobs ?

Aucune des deux solutions ne me convient, et si j'ai titré "le smartphone de mes rêves", je dois dire que pour l'instant, c'est un peu le smartphone de mes cauchemars…

Et vous, comment imaginez-vous le futur de l'informatique mobile avec une telle alternative ? Existe-t-il un téléphone qui pourrait répondre à mon cahier des charges ?

Quelques liens sur l'iPad et l'iPhone

Mise à jour, le 17/4/2010

Merci à tous ceux qui m'ont proposé différents modèles de téléphones.

  • FreeRunner OpenMoko. Venant de l'iPhone, j'ai peur que la marche soit juste infranchissable : c'est un peu comme si on proposait à un utilisateur de Mac de passer à une machine sous Gentoo ;-) . Bien sûr, coté bidouillabilité, il a tout ce qu'il faut. Mais c'est au dépend du reste, en particulier de l'expérience utilisateur. J'étais sur le stand Hackable Devices lors du dernier Solutions Linux, et même si je trouve le concept génial, je ne suis pas prêt à utiliser un tel téléphone...
  • Nokia N900. Grâce à Greg de MaemoFrance, Nokia m'a fait parvenir un N900, que je suis en train d'essayer. On en a plusieurs au bureau, mais ils sont réservés aux développeurs qui travaillent sur Firefox pour Maemo.

Notes

[1] Et amateur de musique pour faire bonne mesure.

samedi 10 avril 2010

En vrac

Voici quelques liens glanés par-ci, par-là au fil de mes lectures.

Je me rends compte que le Standblog perd en puissance alors que je perds en motivation pour le maintenir... Ca fait déjà 8 ans que je me surprends à le faire vivre. Peut-être ai-je juste un coup de mou passager ? Est-ce le syndrome micro-blogging ? Toujours est-il que le sentiment d'urgence qui m'habitait pour écrire s'efface peu à peu.

jeudi 8 avril 2010

Interview avec Fabien Cazenave, auteur de Kompozer

Tristan : Bonjour Fabien, tu peux te présenter rapidement ?

Fabien Cazenave : Bonjour Tristan. Je travaille comme développeur depuis 15 ans, j’ai commencé dans l’instrumentation virtuelle avant de plonger dans les joies des technologies Mozilla en 2005. Kompozer représente l’essentiel de ma contribution au projet Mozilla.

Tristan : Parle-nous de Kompozer : dans un récent entretien, Daniel Glazman le définit comme étant une version de maintenance du projet NVU dont il est l'initiateur mais qu'il a abandonné il y a 5 ans, faute de financement. J'ai bien conscience que c'est bien plus que ça... Tu peux nous en dire plus ?

Fabien Cazenave : Kompozer 0.7 était effectivement une version de maintenance de Nvu 1.0. À l’époque j’étais modérateur sur le forum de support Nvu de Geckozone, et j’ai fini par me dire que ça serait plus simple de corriger les bugs les plus souvent rapportés plutôt que de répondre encore et toujours les mêmes choses. Malheureusement, et à ma grande surprise, cette proposition de bugfix n’a pas été reprise par Linspire et/ou Daniel.

De ce constat, on en a conclu qu’il ne suffisait pas de proposer des patches, mais qu’il fallait animer un projet complet… chose qu’on a commencé à faire à la suite de l’EuMozCamp de Barcelone. On est donc repartis d’un noyau Gecko « propre », et on a cherché à ré-implémenter les fonctionnalités de Nvu en XUL/JavaScript plutôt qu’en maltraitant le noyau Gecko…

L’expérience sur les forums de support nous a conduits à implémenter des nouvelles fonctionnalités qui sont intéressantes pour la productivité mais qui ont un but essentiellement didactique : là où Nvu cherchait à masquer la complexité du HTML / CSS à l’utilisateur, Kompozer 0.8 *propose* en plus à l’utilisateur des outils pour comprendre la syntaxe HTML, l’arbre DOM, les sélecteurs CSS, etc.

Tristan : donc il n'est pas exact de dire que Kompozer, c'est NVU à 99% ?

Fabien Cazenave : C’est effectivement inexact et un poil agaçant. ;-)

Les utilisateurs peuvent s’en rendre compte avec les fonctionnalités et l’interface utilisateur. Les développeurs remarqueront que sous le capot, Kompozer 0.8 est plus proche de SeaMonkey Composer que de Nvu. Quant à la version 0.9 qui est en gestation, elle est développée en collaboration directe avec l’équipe SeaMonkey et il n’y a plus que quelques rares traces de code Nvu.

Tristan : Daniel Glazman affirme "Il faut refondre totalement l'architecture du produit, pour utiliser des modules JSM augmentant drastiquement l'extensibilité du produit." Finalement, tu est en train de me dire qu'elle a déjà eu lieu, sur la base de SeaMonkey Composer ?

Fabien Cazenave : Oui et non. Kompozer 0.9 utilise une base SeaMonkey Composer « pure » afin de factoriser les efforts de développement entre les deux projets. On a donc d’ores et déjà tous les bénéfices du noyau Gecko 1.9.3 : HTML5, CSS3, performances JS, etc. Pour améliorer l’extensibilité, on réfléchit essentiellement à nous rapprocher techniquement des extensions Firefox. Ça passera par une barre latérale type "xSidebar" et quelques ajustements internes. Vu le nombre d’extensions Firefox qui sont orientées développement web, c’est clairement la priorité pour avoir rapidement des extensions intéressantes.

Par contre, il n’est pas question pour nous de ré-écrire le code d’une interface dont le fonctionnement a été débuggé au fur et à mesure de l’évolution de SeaMonkey et Thunderbird. Je reconnais que ça peut être tentant intellectuellement, que le code serait bien plus agréable à lire, mais notre opinion sur la question est qu’il nous faut avant tout de la stabilité et de la pérennité sur l’ensemble du projet si on veut attirer les développements d’extensions. A l'inverse, BlueGriffon s'oriente vers la ré-écriture du code de l'interface utilisateur.

Tristan : Donc tu t'orientes vers une approche où tu suis Firefox et SeaMonkey, de façon à bénéficier au maximum du travail déjà effectué sur ces projets qui sont bien staffés. C'est ça ?

Fabien Cazenave : Exactement. Dans un premier temps ça profitera avant tout à SeaMonkey Composer, mais à moyen terme ça donnera à Kompozer une bien meilleure stabilité que ce qu’une équipe isolée peut faire seule.

Tristan : Alors avec BlueGriffon qui arrive avec un développeur payé à temps plein, comment vois-tu l'avenir de Kompozer ?

Fabien Cazenave : Si le développement de BlueGriffon était articulé autour de la base de code Mozilla existante, je serais ravi d’abandonner Kompozer et de contribuer à BlueGriffon. Si, par contre, BlueGriffon est un nouveau fork du code Composer, fatalement ça va complètement à l’encontre de ce que j’essaye de faire avec Kompozer 0.8 et 0.9, à savoir centraliser le développement de l’éditeur sur comm-central[1].

Tristan : NVU a fini par s'arrêter tout seul une fois la version 1.0 achevée. Tu ne penses pas qu'il pourrait arriver la même chose à BlueGriffon ?

Fabien Cazenave : C’est effectivement ce qu’il faut craindre. Tout dépendra de l’activité économique que Daniel arrivera à générer avec les extensions.

Tristan : Finalement, ce sont deux modèles qui s'affrontent : d'un coté une communauté qui développe du logiciel Libre de façon bénévole, de l'autre une entreprise qui développe un modèle "freemium” avec du propriétaire sur une base Libre, pour rassurer ses investisseurs. Ne pourrait-on pas envisager une solution hybride, avec un appui aussi large que possible sur une communauté ? En effet, il existe déjà une communauté Kompozer...

Fabien Cazenave : les deux modèles ont leurs avantages et sont complémentaires. Eclipse fait un heureux mélange de libre et de proprio dont personne ne se plaint, parce qu’il y a une grosse communauté derrière et que le noyau a démontré sa longévité. La communauté Kompozer n’est certes pas comparable à celle d’Eclipse mais elle a l’avantage d’exister depuis 2006, avec les forums de support, les testeurs, les équipes de loca (Kompozer a deux fois plus de locales que Nvu), les développeurs. J’ai longtemps cru qu’aucun contributeur Mozilla ne voulait bosser sur l’éditeur, et je me rends compte en ce moment que la fusion de Kompozer et de SeaMonkey suscite pas mal d’enthousiasme. Jamais je n’aurais tant d’aide si le code n’était pas destiné à finir dans le tronc Mozilla !

Pour le développement d’extensions aussi, la plate-forme est gratifiante : tout ou presque a déjà été fait en matière d’extensions Firefox, alors que pour Kompozer on peut encore proposer des extensions innovantes. Pour le projet CoMETE (formation Mozilla à Évry), on m’avait demandé de proposer un sujet de travail : j’en ai proposé cinq, et les cinq ont été retenus. Les étudiants qui ont bossé sur ces projets étaient ravis de voir que leurs extensions Kompozer fonctionnaient « out of the box » sur SeaMonkey.

Tristan : Tu crois qu'on pourrait avoir le meilleur des deux mondes ?

Fabien Cazenave : Oui. Le risque d'avoir deux projets d'éditeurs WYSIWYG basés sur Gecko, c'est de diviser les efforts et donc limiter les chances de succès. Si Daniel voulait accepter un compromis et faire du code qui pourrait finir dans comm-central, il gagnerait une communauté motivée (et bénévole), mais en plus l’essentiel de la maintenance de l’application serait effectuée par les contributeurs. Et ça ne remettrait pas en cause son modèle d’extensions payantes, bien au contraire !

Notes

[1] Comm-central est le référentiel Mercurial de code pour les projets Thunderbird 3.0 et SeaMonkey 2.0.

vendredi 2 avril 2010

Rencontre autour de HTML 5 avec le W3C

Trois membres du W3C seront présents à La Cantine le mercredi 7 avril à 19h00 pour parler de HMTL 5 :

  • Philippe Le Hégaret
  • Daniel Glazman
  • Dominique Hazaël-Massieux

J'allais vous annoncer la bonne nouvelle (en évitant la date malheureuse du 1er avril, histoire d'être pris au sérieux). Et puis je viens de voir que c'est complet !

Voici bien la preuve qu'il y a une immense demande autour de HTML 5, et que le W3C peut sans hésiter investir ses ressources (certes trop limitées) dans de telles opérations : elles seront couronnées de succès...

Interview avec Daniel Glazman, auteur de BlueGriffon

Ceci est une interview de Daniel Glazman réalisée par messagerie instantanée le 31 mars 2010 alors que Daniel était à Cupertino (Californie) pour une réunion du CSS Working Group du W3C dont il est le co-chairman.

Tristan : Bonjour Daniel. Est-ce que tu peux te présenter rapidement ?

Daniel : Je suis un développeur tombé dans la babasse dans son enfance, et qui a eu dans sa vie deux chances immenses : travailler sur le Web avant que le Web ne soit connu d'une part, être un jour embauché par le rêve de tout développeur à l'époque, Netscape, pour travailler sur leur éditeur et leur moteur CSS. Quand AOL a fermé Netscape et que mes camarades de débauche Tristan et Peter se sont lancés dans l'aventure Mozilla Europe, j'ai préféré créer ma propre société Disruptive Innovations pour continuer mon travail sur l'éditeur, ce que je pouvais faire grâce à la licence MPL.

Tristan : Qu'est-ce que BlueGriffon ?

Daniel : A travers mon premier client Linspire, j'ai écrit Nvu, le seul éditeur WYSIWYG (x)html cross-platform conforme aux standards et open-source. Aujourd'hui, il est temps de faire apparaître un outil d'édition plus moderne, offrant la puissance des versions récentes de Gecko et les fonctionnalités de CSS 3 et HTML5. Cet éditeur est BlueGriffon. BlueGriffon est donc un éditeur (x)html moderne, basé sur les dernières versions de Gecko à travers Mozilla Xulrunner, le runtime de Firefox.

Tristan : Qu'annonces-tu aujourd'hui ?

Daniel : L'annonce, c'est que nous avons enfin trouvé des investisseurs pour nous libérer du service, et que la roadmap de BlueGriffon ne souffrira plus de notre besoin de trouver des contrats de service pour financer notre R&D. BlueGriffon est désormais la priorité numéro 1, au lieu d'être le produit que l'on développe quand on a le temps et qu'on a eu du service pour payer ce temps.

Tristan : Félicitations ! Comment vois-tu l'avenir de BlueGriffon, d'un point de vue fonctionnel ?

Daniel : Sa version de base reste un produit open-source distribué sous tri-licence MPL/GPL/LGPL et nous allons vendre des extensions (au même sens que les extensions à Firefox) pour l'éditeur de base. Il y aura de tout, des choses très simples mais cependant très utiles à très bas prix, et des extensions orientées bien plus "pro" pour des prix un peu plus élevés mais toujours à des coûts restant très faibles par rapport par exemple au coût d'un produit "on the shelf". Du côté des fonctionnalités innovantes dans BlueGriffon, je peux d'ores et déjà en lister quelques-unes:

  1. intégration de jQuery
  2. intégration des YUI grids
  3. éditeur de CSS offrant les dernières nouveautés de CSS 3 (transformations, ombres, transitions, animations, ...)
  4. full-screen
  5. possibilité d'éditer non seulement les styles en -moz-* mais tous les styles y compris pour webkit, opera ou ms
  6. un wizard de création de documents bien plus intuitif que ce que permettait Nvu
  7. l'intégration de Bespin pour l'édition des sources
  8. un éditeur de scripts, etc.

Tristan : Qu'est-ce qui différencie BlueGriffon d'autres éditeurs ?

Daniel : Un des buts de BlueGriffon est clairement d'offrir à la communauté l'éditeur WYSIWYG qui aujourd'hui manque. Nvu - et Kompozer qui est son bugfix[1] - sont aujourd'hui fondés sur une codebase ancienne, et obsolète. Il faut refondre totalement l'architecture du produit, pour utiliser des modules JSM augmentant drastiquement l'extensibilité du produit. Il faut disposer d'une documentation stable pour les éditeurs d'add-ons et surtout il faut offrir des personnalisations adaptant le produit à l'ensemble des usagers qui ont craqué pour Nvu et qui étaient TRES différents: des écoliers, des universités, des entreprises, etc.

Un des buts de l'amélioration de l'extensibilité est clairement la distribution au moment de la 1.0 de BlueGriffon d'un premier jeu assez étoffé d'add-ons d'une part, et l'ouverture de notre plate-forme de vente à des tiers d'autre part (que les add-ons soient gratuits ou pas, pas de ticket d'entrée chez nous). Nous voulons attirer un maximum d'auteurs d'add-ons, car l'écosystème du produit compte autant que le produit de base.

Un des effets de bords pourrait être une pression accrue sur les éditeurs de navigateurs : si un outil d'édition intuitif offre une UI permettant la création de documents utilisant les dernières nouveautés, il va falloir que la standardisation et l'harmonisation accélèrent un peu pour répondre aux demandes des Web Authors. Bref, c'est du gagnant-gagnant.

BlueGriffon est clairement un produit, édité par une entreprise. Mais c'est aussi un produit open-source, qui a un but pour la communauté. On reste fidèles à nos principes Etonnant, non ?

Tristan : Te connaissant, non :-) . Quid de la concurrence avec Kompozer ? Ne crains-tu pas que les deux logiciels se gênent mutuellement ?

Daniel : c'est une bonne question. Si KompoZer a un succès mérité aujourd'hui, il reste que c'est Nvu à 99%. Nvu est obsolète. Son éditeur CSS que j'avais écrit encore chez Netscape, Cascades, est obsolète et son interface peut être TRES grandement améliorée. Son extensiblité est faible parce que son architecture n'offre pas de Helpers documentés. Bref, et malgré l'énorme boulot de ses contributeurs, je pense que c'est une voie de garage.

De temps en temps, et on connait bien le problème chez Netscape et Mozilla, il faut reprendre les choses depuis la base et reconstruire du neuf sans oublier l'ancien. C'est ce que se propose de faire BlueGriffon, qui n'oublie pas Nvu et sera clairement son successeur.

Tristan : Quels systèmes d'exploitation vises-tu ?

Et bien, vu que BlueGriffon est basé sur Xulrunner, ce sera évidemment cross-platform ! Windows, Mac OS X et Linux... Non je n'ai pas de version iPad sous le coude, en tous cas, pas encore.

Tristan : Quand verra-t-on la version 1.0 de BlueGriffon ?

Ce sera prêt quand ce sera prêt, mais le but est clairement 2010.

Tristan : On aura des extensions disponibles à ce moment là, si oui, lesquelles ?

Daniel : Oui il y en aura, des payantes et des gratuites. Exemple payant : l'éditeur avancé de CSS (l'éditeur de base sera gratuit) et d'autres trucs tout aussi sexy

Tristan : Et donc le code en sera propriétaire ?

Daniel : Les extensions commerciales, oui. C'est un modèle un peu particulier, mais il faut bien que Disruptive Innovations vive pour offrir BlueGriffon en MPL. Il est important pour nous de conserver absolument l'open-source et la gratuité de l'éditeur de base pas seulement parce que Nvu a fait le chemin, mais surtout parce que c'est notre philosophie de la chose.

Tristan : Merci Daniel, et longue vie à BlueGriffon !

Notes

[1] Note de Tristan : je pense que Daniel veut dire "version de maintenance''.