Aller au contenu | Aller au menu | Aller à la recherche

jeudi, septembre 1 2011

Jelix : de Mercurial à Git

Depuis deux ans déjà, j'ai complètement abandonné subversion et utilisé Mercurial pour gérer le code source de mes projets. J'avais choisi Mercurial au départ parce que je devais l'utiliser pour contribuer à Firefox. J'avais alors apprécié le produit et l'avais adopté pour mes autres projets personnels. Pour les projets professionnels comme chez Zoomorama, et ou pour Jelix, nous (moi et mes collègues ou les contributeurs) avions étudié bien sûr Git avant de choisir Mercurial. À l'époque, Mercurial paraissait plus simple d'utilisation : des commandes plus claires, plus concises, moins verbeuse. Il avait aussi un meilleur support multi-plateforme en particulier sous windows. Ce dernier critère me paraissait essentiel par exemple pour Jelix, car j'avais des contributeurs sous Windows.

Lire la suite...

mardi, juin 7 2011

Testez la beta de Jelix 1.3

J'ai sorti ce week-end dernier la beta du framework PHP Jelix 1.3. Pas mal de nouveautés sont disponibles.

Tout d'abord, quelques allègements dans la structure d'une application : il y a maintenant qu'un seul boostrap application.init.php pour tous les points d'entrées, et un seul répertoire temporaire. Ensuite, le script jelix.php pour lancer des commandes d'aide au développement, a été remplacé par un script cmd.php qui est placé dans l'application. Son utilisation est alors facilitée puisqu'on n'a plus le nom de l'application à indiquer en argument.

Il y a une nouvelle gestion des erreurs et des exceptions, plus puissante, mais aussi plus conviviale. Les messages d'erreurs sont en effet maintenant pris en charge par le système de log de Jelix, qui a lui aussi connu des évolutions (il a maintenant un système de plugin). On peut aussi fournir sa propre page d'erreur, permettant d'afficher un message "convivial" à l'utilisateur, avec le look de l'appli, plutôt qu'un message technique barbare sur une page blanche.

Deuxième grosse nouveauté : le développeur peut activer la toute nouvelle barre de debug pour avoir un affichage détaillé des erreurs, mais aussi des logs, de la liste des requêtes SQL, des messages SOAP, du contenu de la session etc. Et comme la barre est extensible, on peut développer/ajouter des plugins pour afficher d'autres informations.

Du travail a aussi été fait pour faciliter le développement de tests PHPUnit pour une appli Jelix. L'intégration de Simpletest, bien que toujours disponible, est considérée maintenant comme obsolète. D'ailleurs la migration des tests de Jelix vers PHPUnit a commencé.

Enfin le système de droits jAcl2 a vu quelques améliorations techniques, mais aussi au niveau de l'interface de gestion de droits. Et puis bien sûr, une tonne de petites améliorations ont été faite ici et là.

Pour la migration d'une application jelix 1.2, c'est une affaire de quelques minutes, grâce au système de mise à jour de Jelix, mais aussi parce que les API n'ont que très peu changé.

Cette beta a été développée et largement éprouvée lors de la réalisation d'un gros projet d'un de mes clients (et par des contributeurs bien sûr). Vous pouvez donc l'utiliser à priori sans soucis particulier :-). Et d'ici la version finale dans quelques semaines, je ne pense pas qu'il y aura de gros changements.

À propos de clients et de l'avenir de Jelix, il faut savoir qu'une bonne partie des contrats que j'ai eu au cours de ces 12 derniers mois, concernait des projets relatifs à Jelix (consulting, formations, développement d'appli...), et ce n'était pas que pour des petites boites (BNP Paribas, Transatel..). Ce framework ne cesse donc de se déployer en entreprise. Et je compte faire en sorte que pour les prochains mois, le mouvement s’accélère !

Bien souvent on me posait la question de la pérennité du framework. Après 5 ans d'existence, motorisant des gros sites comme Overblog, tout un tas d'intranets et de sites publiques divers et variés, j’espère que cette question se posera moins souvent :-) Merci à ceux qui ont fait confiance au projet, et à ceux qui contribuent, que ce soit au niveau du code ou au niveau communauté.

PS: j'ai oublié de dire que le manuel pour cette version 1.3b est disponible, complet, en français et en anglais, en ligne ou en PDF

samedi, juin 4 2011

Un an après

Cela fait grosso modo un an que j'ai commencé l'aventure de l'entrepreneuriat. Fin avril 2010, Zoomorama fermait ses portes. Quelques semaines de paperasserie plus tard, j'étais créateur d'entreprise, avec 4 autres anciens de Zoomorama dont un qui ne participe qu'au capital, étant parti vivre des aventures ailleurs.

Avec David Marteau, Olivier Gambier et Emmanuel Tabard, nous avons donc monté la société Innophi, qui propose du service dans le développement logiciels et applications web. Et depuis, nous ne sommes pas croisé les bras (d'ailleurs l'activité de ce blog s'en ait ressenti :-) ). Par le biais de nos réseaux respectifs de connaissances dans le milieu, nous avons pu trouver nos premiers contrats.

Après un an, les résultats sont encourageants, nous continuons donc l'aventure :-)

mardi, mai 10 2011

BlueGriffon 1.0

Septembre 2008, Daniel écrivait les premières lignes de code d'un nouvel éditeur HTML wysiwyg, BlueGriffon. L'idée du projet germait déjà depuis plusieurs mois dans le bureau (j'étais alors salarié de Disruptive Innovations), après l'arrêt du développement de Nvu. Nvu était le premier éditeur HTML de D.I, téléchargé à plusieurs millions d'exemplaires. Cependant l’impossibilité de poursuivre le développement de Nvu[1] et la volonté de repartir sur des bases neuves et saines[2], ont fait naître BlueGriffon.

Développer un tel logiciel n'est pas chose aisée. Cela demande du temps, du financement. Je me rappelle que les débuts n'étaient pas simple. Mais Daniel y est finalement arrivé ! Bravo Daniel !

Deux et demi après, voici enfin la première version stable de BlueGriffon, disponible gratuitement. Support de HTML5, de CSS3, basé sur le moteur de rendu de Firefox 4. Tout y est !

Il y a aussi plusieurs extensions disponibles pour ajouter des fonctionnalités évoluées. Elles sont pour la plupart payantes mais pas chères. N'hésitez pas, ça aidera à faire vivre le projet.

Notes

[1] pour diverses raisons, dont des raisons juridiques

[2] Nvu était basé sur le code de Mozilla Composer, datant du début de la fin des années 90, avec donc un long passif et utilisant une vieille version de Gecko

mercredi, janvier 19 2011

Jelix 1.2 et la suite

Le temps passe vite : presque un mois que j'ai sorti Jelix 1.2. Ça fait donc un mois que je me dis qu'il faudrait que j'en parle sur mon blog :-)

La liste des changements est assez conséquente. Pour faire rapide, elle comporte :

  • un nouveau système d'installation automatique des modules, ce qui est très agréable dés lors il faut installer un module tiers, ou pour mettre à jour une application en production, puisque ce système d'installation permet les mises à jour incrémentales.
  • le support de bases de données NOSQL, avec une API abstraite d'accès à ces bases
  • des améliorations dans jForms, le système de formulaire
  • le support de tout les noms des types natifs des bases SQL dans jDao (l'ORM)
  • enfin un composant de gestion de cache de donnée
  • et des dizaines d'autres petites améliorations

Sitôt la 1.2 sortie, sitôt le développement de la 1.3 commencé. Déjà fait :

  • nouvelle gestion des erreurs et des exceptions. Le logger jLog est utilisé pour les stocker. On peut maintenant fournir sa propre page d'erreur, et les erreurs ne s'affichent plus dans une div pas très jolie, mais dans une toute nouvelle debugbar, désactivable.
  • jLog, justement, accepte maintenant des plugins, pour étendre ses possibilités
  • Tout comme l'objet jResponseHtml (la "vue"). Ainsi les fonctions de "minification" des fichiers CSS/JS, reposant sur Minify, ont été migrées dans un plugin. Et la nouvelle debugbar est également un plugin.

Et il est prévu :

  • polissage de la debugbar et des plugins pour la debugbar
  • une petite refonte de la partie routage
  • des simplifications ici et là, du nettoyage de code
  • le début de la migration de Simpletest à PHPUnit pour les tests unitaires
  • et plein d'autres petites choses

Je vais essayer de sortir cette prochaine version assez rapidement, même si tout ce que j'ai prévu n'est pas développé à temps. Je veux en effet accélérer le rythme des releases. Le système de mise à jour de Jelix permettant des migrations plus douces. Et bien sûr, les mises à jour correctives pour les deux branches actives, 1.1 et 1.2, vont continuer à sortir. La 1.2.1 ne va pas trop tarder ;-)

mercredi, janvier 12 2011

Plus de H264 dans Chrome

Google vient de l'annoncer : le support du format video H264 va être retiré de Chrome (sachant que dans Chromium, la version opensource du navigateur, il n'y en avait déjà pas). Ce qui veut dire que Google va commencer à pousser fortement à l'utilisation de son propre format vidéo, WebM, déjà supporté par Firefox, Opera et d'autres navigateurs libres.

C'est une excellente nouvelle pour le web, et pour la balise video, que d'avoir un format, WebM, de qualité et non encombré de brevets logiciels connus. J'en avais déjà parlé il y a quelques mois, quand Google libérait ce format. Depuis, cette époque, même s'il n'a pas trop fait parlé de lui publiquement, WebM a progressé, tant au niveau logiciel qu'au niveau hardware, puisque des puces vont bientôt être disponibles.

Il ne reste "que" Internet Explorer et Safari (sur Macbook ou iphone) à ne pas supporter nativement WebM. Toutefois, avec IE9, il suffira d'installer le codec au niveau du système.

Attention cependant, ne crions pas victoire trop vite. Le retrait du support n'est pas encore fait, et l'annonce de ce retrait provoque une vague de mécontentement chez beaucoup d'utilisateurs et de développeurs, si on en croit les nombreux commentaires sur la news (les menaces de passer à un autre navigateur sont particulièrement risibles).

Sans parler du fait que c'est philosophiquement un peu en contradiction avec une précédente décision : celle d'inclure dans le navigateur, Flash, un produit propriétaire.

Espérons que Google tiendra bon dans sa décision sur WebM. Cela fait de lui un allié de plus à Mozilla, dans la lutte pour garder un web ouvert, dans sa volonté de ne pas supporter de formats propriétaires.

dimanche, novembre 7 2010

Mercurial/Git : ne pas "brancher" est une erreur

Et c'est une erreur que j'ai faite pour le développement de Jelix 1.2. Cela a conduit à un gros retard (presque 1 an !) sur la sortie de la version stable, avec toutes les conséquences qu'un retard de la sortie d'une version d'un projet peut avoir.

Lire la suite...

Jelix 1.2RC2, forum PHP et Rarangi

Ça fait quasiment un an que je n'ai pas parlé de Jelix sur mon blog (oups !). Ce n'est pas pour autant que le projet n'a pas avancé, bien au contraire !

Bien qu'initialement, la version 1.2 du framework était prévue il y a plus d'un an, elle ne va sortir que ce mois-ci. J'expliquerai pourquoi dans un prochain billet. Une "release candidate" est donc disponible, avec son manuel en ligne et en version PDF, le tout bien sûr, en anglais et en français. Cette version comporte une tonne de nouveautés.

Cette version 1.2 à venir est particulièrement stable car déjà utilisée sur pas mal de projets, ce qui a permis de remonter pas mal de bugs et améliorations à faire. Ainsi des préversions de Jelix 1.2 sont utilisées :

  • Dans quelques un de mes projets clients, réalisés ces derniers mois :-)
  • Dans des projets à venir d'Over-blog, réalisés donc par l'équipe d'Over-blog. Sachant que, pour ceux qui ne sont pas au courant, qu'ils utilisent Jelix depuis plusieurs années pour motoriser les blogs d'Over-blog ;-) (l'une des plus grosses plateforme européenne de blog).
  • Dans la future version 1.4 de HavefnuBB, un forum réalisé avec Jelix (et utilisé sur http://jelix.org ;-)) (la 1.3 utilise jelix 1.1)
  • Dans Rarangi, une alternative à phpdoc.

Bref, n'hésitez pas à tester et à utiliser cette RC2 !

Si vous voulez en savoir plus sur les nouveautés, rendez-vous au stand jelix au forum php, mardi et mercredi prochain. J'y serais avec d'autres contributeurs, dont Olivier "Foxmask" Demah, l'auteur de HavefnuBB.

Au sujet de Rarangi, c'est un autre projet qui me tiens à coeur et que j'avais commencé fin 2008, mais avec le manque de temps, ce n'est que maintenant qu'il commence à être opérationnel. PHPdoc commence à me gonfler sérieusement. Il est buggé de partout, compliqué à personnaliser, demande énormément de ressources. Et je n'accroche pas à doxygen. Bref, je compte m'en débarrasser définitivement sur jelix.org, en le remplaçant par Rarangi ces prochaines semaines, une fois que j'aurais finalisé les templates de détails des classes et fonctions, et amélioré la navigation. J'espère apporter une alternative sérieuse à phpdoc. Les futures versions embarqueront notamment un moteur de recherche et autres fonctionnalités inédites.

Une démo de Rarangi est visible en ligne. Il reste comme je l'ai dit, des améliorations de design et de lisibilité sur certains type de pages. N'hésitez pas à me faire part de vos impressions sur cette pre-0.1 :-) (et si quelqu'un veut bien se dévouer pour le design.. car comme vous le voyez, ce n'est pas ma spécialité :)

jeudi, octobre 14 2010

Diantre ! Un billet !

Quatre mois presque, sans blogger[1] . Et là, d'un seul coup, paf, je publie un billet sans prévenir !

Désolé cher lecteur pour cette absence prolongée. Mais j'étais très très occupé ces derniers mois. La cause : après mon licenciement économique de chez Zoomorama, je me suis lancé dans un projet fou, un truc qui me trottait dans la tête depuis des années : créer une boîte. Et depuis, ça n'arrête pas, les journées sont plus que remplies. C'est du délire complet ! :-D

Je vous en reparlerai plus longuement une autre fois :-)

Notes

[1] Si on ne compte pas mes micro billets sur twitter :-)

Le moteur Javascript de Firefox rattrape son retard

Connaissez-vous http://arewefastyet.com/ ? C'est un site mis en place par l'équipe des développeurs du moteur javascript de Mozilla, SpiderMonkey. Il permet de suivre l'évolution des performances de ce moteur, en exécutant deux tests : sunspider et v8bench.

Il y a quelques jours, SpiderMonkey avait dépassé Apple Nitro (le moteur js de webkit) sur v8bench. Depuis hier, il est sur le point de le dépasser sur sunspider ! Il reste maintenant à battre le moteur de Google, V8. (Ce sont les versions de développement de ces moteurs javascripts qui sont testés)

Arewefastyet ? v8bench 20101013 arewefastyet ? sunspider 20101013

Légende: courbe violette : spidermonkey (Tracemonkey + JaëgerMonkey); courbe rouge : apple nitro. courbe verte : google v8. courbe noire : spidermonkey (JaëgerMonkey seul)

À noter que ces résultats sont obtenus en lançant les tests non pas dans un navigateur, mais avec les versions "autonomes" des moteurs javascripts (hors navigateur donc). On a donc ici des performances pures, qui ne sont pas impactées par d'autres choses comme un moteur de rendu ou des scripts d'autres sites etc. Il est évident donc que vous n'obtiendrez pas des résultats comparatifs du même ordre, en les lançant dans un navigateur.

C'est ainsi que ce n'est pas encore parfait du coté Mozilla, puisqu'on obtient encore des écarts en lançant ces tests avec Firefox. Probablement que les tests dans Firefox sont biaisés à cause de l'exécution de code JS en dehors de la page de tests, puisque l'interface de Firefox est développée en partie en javascript.

Cependant, les améliorations entre Firefox 3.6 et Firefox 4 sont énormes, et les performances des moteurs javascripts des principaux navigateurs (IE9, Chrome, Safari et Firefox 4) sont maintenant équivalentes. On arrive à des différences qui ne seront pas perceptibles par l'utilisateur.

Je pense que d'ici quelques mois, on aura atteint les limites sur les améliorations dans les moteurs javascript.

la bataille des navigateurs va pouvoir aller se focaliser sur d'autres sujets :-) (accélération matériel etc..)

jeudi, juin 24 2010

Pourquoi Firefox n'aura probablement jamais 100 au test acid 3

Parce que. Je vous l'ai déjà dit, ce test est débile ! :-)

Ok, plus sérieusement, et ça fait un bon moment que je voulais en parler (je sais je lag), la raison est toute simple : les trois derniers points à passer concernent le support des fontes SVG. Et Mozilla n'envisage pas de les implementer, au moins dans un avenir proche. Des développeurs, dont Roc, de Mozilla, en donne les raisons, sur son blog et dans les commentaires du bug. En gros :

  • Globalement les fontes SVG n'apportent techniquement rien par rapport aux fontes TTF ou WOFF
  • On peut faire des glyphes multi coloré et animé avec les fontes SVG, mais en fait, la spécification sur ces points est un cauchemar. D'ailleurs Opera et Webkit n'implémentent pas ces choses, et ont apparement un support très minimal des fontes SVG (juste pour passer le test acid3 ? ;-) )
  • Les autres types de fontes ont plus d'avantages :
    • techniquement plus riche ("Hinting, rasterization with subpixel antialiasing, far richer support for glyph selection and text shaping") puisqu'elles permettre de créer des glyphes pour des caractères aussi complexes que les caractères arabes par exemple
    • énormément plus de fontes déjà disponibles
    • plus compacte
    • support beaucoup plus large dans les logiciels (outils auteurs etc)

En conclusion, le support des fontes SVG ne leur semble pas très important pour le web, et pas très utile en fait.

Bien entendu, les supporters des fontes SVG pensent le contraire, et ne sont pas d'accord avec les arguments de Roc et cie. Honnêtement, je ne suis pas assez calé en typographie et sur les formats de fontes pour vous dire qui a raison et qui a tord.

Le fait est que Mozilla ne veut pas implémenter un truc qui leur semble peu utile et qui servirait juste pour avoir un meilleur score à un test. Ils préfèrent dépenser leur énergie à des choses plus importantes. Techniquement, je trouve que ça fait sens, très pragmatique, mais au niveau marketing, c'est sûr, c'est dommage.

Cependant, rien n'interdit à quiconque de proposer un patch. Si il est bon, il n'y a pas de raison (à mon sens) qu'il soit rejeté. Qui veut faire passer Firefox à 100 au test acid3 ?

Mise à jour 25/01/2011 : Alexander Limi, un des développeurs de Firefox, confirme le fait que Firefox n'aura pas 100%. Il rapport aussi, des propos de Boris Zbarsky (un des core-developers de Mozilla), expliquant que le support des fontes SVG dans les autres navigateurs est très minimes et tout juste suffisant pour afficher un score de 100% au test Acid3 (ce qui confirme les propos de Mitch 74 dans son commentaire plus bas).

IE9 a quasi rattrapé son retard

La troisième preview de IE9 est sortie. J'avoue être plutôt impressionné par toutes les améliorations qu'ils ont encore apporté. IE9, une fois que la version finale sera sortie, sera vraiment dans la cour des grands et aura rattrapé tout son retard technologiquement parlant.

Une partie des questions que je me posais il y a quelques mois ont maintenant une réponse : c'est implémenté.

  • Support de SVG (en partie)
  • éléments HTML5 <video>, <audio>, <canvas>,
  • support DOM largement amélioré: DOM traversal, DOM level3 core, DOM level3 events,
  • fontes téléchargeable WOFF, support complet CSS 2.1, support des media queries CSS3, selecteurs CSS3, bordures CSS3, background CSS3
  • un moteur javascript complet et aussi rapide que celui des autres navigateurs (je ne tiens pas compte des pouillèmes de milli secondes de différences entre chacun, à ce niveau, ce n'est plus tellement significatif)

Bref, tout plein de choses à se mettre sous la dent, avec un score acid3 qui grimpe à 83[1]. Sans parler d'un support très avancé de l'accélération graphique matérielle.

Il lui manque toutefois encore des technologies qu'ont déjà les concurrents, comme :

  • les WebWorkers
  • les WebSockets
  • formulaires HTML5, HTML5 File API, et autres éléments de sections HTML5 probablement
  • transitions CSS3, transformations CSS3, animations CSS3, gradients,
  • WebGL
  • SMIL
  • Évènements DOM multi touch, support accéléromètre, support géolocalisation
  • base IndexedDb
  • API Drag and drop (à vérifier)

Et j'en oublie certainement[2]. Ils ont donc encore du chemin à rattraper, et je ne doute pas que certaines de ces technos seront implémentés dans la version finale de IE9. Pour moi, on pourra qualifier IE9 de navigateur moderne. Car une chose est sûre, les développeurs web auront déjà suffisamment de technologies pour faire des sites modernes qui soient compatibles avec la majorité des navigateurs.

Le rouleau compresseur Microsoft a mis du temps à se mettre en route. Il est maintenant en marche, et pas qu'un peu. Mozilla, Apple, et Google ne devront pas s'endormir sur leurs lauriers. Cette nouvelle guerre de navigateurs initiée par Mozilla devient vraiment intéressante.

Notes

[1] Même si, comme je l'ai déjà dit, ce test n'est pas vraiment significatif

[2] je me suis en partie basé sur la liste des fonctionnalités qui sont implémentés dans Firefox 3.6 ou 4

mercredi, mai 19 2010

WebM, le nouveau format video du web

Le petit monde des formats videos, et le web sont en pleine ébullition, avec l'annonce du nouveau format WebM. Mais avant de voir ce que nous promet WebM, faisons d'abord un petit retour en arrière dans l'histoire des codecs pour la balise video de HTML5.

Lire la suite...

samedi, mai 15 2010

Batterie de macbook morte

Depuis quelques semaines, la batterie de mon macbook ne durait plus que 45 minutes environ, sachant que neuve, je pouvais facilement pianoter pendant 3 heures. En fait, la durée de fonctionnement a littéralement chuté en quelques semaines, puisqu'il n'y pas si longtemps, je pouvais encore tenir 2 heures.

Cela m'étonnait, car la batterie aujourd'hui n'a que 16 mois. Sur twitter, Nicolas m'avait suggéré de faire un reset du SMC mais je n'ai pas vu d'amélioration perceptible.

Et puis depuis ce matin, impossible de rester plus de 10 minutes avec la batterie. Bien que l'indicateur indique qu'elle est chargée à 75%, le macbook s'éteint au bout de 10 à 15 minutes, sans prévenir évidement.

Il y a eu par le passé des problèmes de ce genre, avec des batteries quasi neuve, et il fallait mettre à jour le firmware du SMC mais le mien est déjà à jour. On peut aussi calibrer la batterie mais des charges et des décharges complètes, c'est ce que je fais quasi tout le temps (ce qui n'est pas bien, voir plus bas).

Et puis j'ai découvert cette page qui donne des informations et conseils pour la durée de vie des batteries macbook.

Les batteries récentes d'Apple sont en lithium-polymère, et donc ont des caractéristiques différentes des batteries classiques Lithium-Ion :

  • elles n'aiment pas le chaud, ça réduit la durée de vie.
  • la durée de vie chute rapidement quand elle approche de la fin de vie, contrairement aux autres types de batteries, qui faiblissent sur une plus longue periode.
  • Apple considère qu'après 300 cycles de charges, la batterie est usagée et doit être remplacée. Même si à 300 cycles de charge, une batterie correctement entretenue devrait être à 80% de sa capacité de charge originelle, toujours selon Apple.
  • Il faut éviter des cycles de charge et décharge complète, contrairement à ce qu'il faut faire pour des types de batteries plus anciennes. D'une part, cela est inutile car elles n'ont pas ces problèmes d'effet mémoire que l'on trouve souvent, et d'autre part, ça reduirait en fait leur durée de vie.

J'ai installé le petit logiciel Coconut Battery pour avoir des informations sur l'état de ma batterie :

  • 304 cycles de charges (en 16 mois)
  • capacité de charge : 1662 mAh au lieu de 4100 mAh pour une batterie neuve, soit une capacité qui n'est plus que de 40% (au lieu de 80%)

En tenant compte du fait que j'ai bien "tabassé" le macbook pendant 16 mois, avec des compilations à répétitions (donc fortes chaleurs), et un fonctionnement d'au moins 12h par jour (dans la semaine), que j'ai régulièrement fait des charges/décharges complètes (au moins 1 jour sur deux, parce que je bosse souvent dans le rer), ces chiffres ne m'étonnent finalement pas.

Je dois me rendre à l'évidence : ma batterie est morte.

Je vais attendre un peu avant de la remplacer, car il n'est pas certain que je garde le macbook, il n'est en fait pas à moi mais à Zoomorama. Ça va dépendre du commissaire priseur qui est en charge de liquider le matériel et mobilier de Zoomorama, si il va accepter ou non qu'on lui rachète directement nos machines.

vendredi, avril 30 2010

Zoomorama, the end

Depuis le courant de la semaine, Zoomorama est en liquidation. Nous n'avons pas su trouver le bon modèle économique à temps, et du coup, plus d'argent pour continuer l'aventure. C'est assez dommage car je suis intimement convaincu que la technologie était très bonne. Les développeurs web avaient à leur disposition une technologie de zooming, non pas sur une simple photo, mais sur un document entier, document en XML et CSS, et avaient accès au DOM du document pour le modifier dynamiquement, comme n'importe quel page web. David Marteau et Olivier Gambier avaient donc réussi le tour de force d'avoir une technologie de zooming proche de la philosophie des standards du web (ce que n'avaient pas nos concurrents).

J'ai passé un peu plus d'un an et demi dans une équipe formidable, composées de véritables talents. Une dream team. Merci à eux. C'est donc avec un certain regret d'être obligé de s'arrêter là.

Certains membres de l'équipe sont déjà dans les starting blocks pour enchaîner dans d'autres sociétés, comme Akamai. Et d'autres, comme moi, ont des projets plein la tête. Mais je vous en parlerai en temps utile ;-)

Vous pouvez aller lire le billet d'Olivier et celui de Franklin pour en savoir un peu plus sur cette fermeture.

lundi, mars 29 2010

Modifier un fichier ini en php

J'aime bien utiliser les fichiers ini pour tout ce qui est configuration. En php, c'est très rapide à charger avec la fonction parse_ini_file (beaucoup plus rapide qu'un fichier de conf en php, avec un facteur 10 je crois), et puis c'est très simple à modifier, la syntaxe étant minimaliste.

C'est pourquoi j'utilise des fichiers ini dans jelix, et pas des trucs du genre yaml, syntaxe que je trouve hyper compliquée [1], en tout cas trop pour l'utiliser pour un fichier de conf [2].

Dans Jelix, il y a des outils pour le développeur pour l'aider à construire son appli, et il arrive donc que ces outils aient à modifier un fichier ini. J'avais fait une première implémentation naïve dans une classe, jIniFile permettant d'enregistrer un fichier ini : une méthode pour lire (avec parse_ini_file), une autre pour écrire en lui passant un tableau de clés/valeurs, et le nom du fichier.

Problème de cette classe : on perd tous les commentaires et les sauts de lignes à la lecture avec parse_ini_file. C'est assez fâcheux pour un fichier de configuration, où les commentaires peuvent être nécessaires.

D'où une autre classe jIniFileModifier, qui permet de charger, modifier et enregistrer un fichier ini, sans perdre les commentaires et les espacements. Elle permet même de supprimer une clé/valeur, avec le commentaire qui lui est associé (le commentaire qui la précède). Cette classe supporte les sections et les tableaux de valeurs. En fait, j'ai fait en sorte qu'elle soit compatible au maximum avec le format ini utilisé par parse_ini_file[3].

Vous pouvez l'utiliser seule dans vos projets, elle est totalement indépendante de Jelix. Par contre, ne l'utilisez pas pour une simple lecture, ce n'est pas son objectif principal, parse_ini_file est beaucoup plus performante pour ça.

Notes

[1] pour preuve : la spécification YAML : 77 pages A4, celle du XML : 30 pages...

[2] si j'avais à choisir un format pour stocker des options de manière arborescente, je choisirais json

[3] il y a en effet quelques variantes, suivant les logiciels

vendredi, mars 19 2010

Surcouf, c'etait mieux avant...

Hier, je me suis fait une petite balade au magasin Surcouf, avenue Daumesnil à Paris. Ça fait au moins un an que j'y suis pas allé. Et j'ai découvert un magasin refait à neuf, avec des beaux stands au design moderne. Et du vide.

Qu'ont-ils fait de mon magasin préféré des années 90, avec ses allées étroites, ses stands et rayons bondés de gens, mais aussi rempli de matos ? Elle est où ma caverne d'ali-baba de centaines de m2 où j'étais sûr de trouver mon bonheur ? Il est passé où le royaume du geek, où j'écarquillais les yeux tous les deux mètres à la vue d'une nouveauté ou d'un truc dont j'ignorais l'existence ? Elle est où cette ambiance "circus", totalement décalée, originale, qui existait auparavant ?

Surcouf est devenu un magasin aussi aseptisé que ces autres magasins des chaînes d'électroniques grand public (boulanger, saturne ou autre, voir même la fnac). Je n'y vois plus trop grand d'intérêt d'y aller en fait. Mis à part le fait qu'ils ont peut être quand même encore un peu plus de choix que les grandes chaînes et qu'ils sont dans un quartier encore dédié aux geeks avec tout ces petit magasins d'informatiques autour.

Fini la magie en tout cas.

M'enfin ça ne m'a pas empêcher d'y faire une petite emplette...

dimanche, mars 7 2010

Open To Choice

Depuis quelques années, le web se démocratise énormément. Chaque jour des milliers de nouveaux internautes débarquent sur la toile. Bien entendu, la grande majorité d'entre eux ne sont absolument pas au fait des techniques. C'est ainsi que bon nombre d'entre eux ne savent pas qu'il y a autre chose que facebook sur la toile (la preuve avec ce billet de readwriteweb, qui est apparu quelques heures en tête de la recherche "facebook login", et des internautes débarquant alors sur ce site croyant à faire à une refonte du site facebook), ou encore ne savent pas ce qu'est une URL.

Mais ce n'est pas tout, bon nombre d'entre eux ne savent pas ce qu'est un navigateur, ou ne savent pas qu'ils peuvent choisir leur navigateur.

Depuis quelques jours, les utilisateurs européens de windows 7 se voient proposer une page permettant de choisir leur navigateur web. C'est déjà un pas, mais peut être pas suffisant, puisque cela n'explique pas ce qu'est un navigateur, et comment faire le bon choix.

Aussi Mozilla a lancé le site http://opentochoice.org, afin de combler ce manque d'information, et tente de réponde aux questions, et explique notamment pourquoi choisir son navigateur est important.

jeudi, février 11 2010

Faire du drag and drop avec flash en utilisant canvas

À Zoomorama, Flash nous rend bien service. De par ses performances au niveau rendu, il nous permet de développer notre navigateur de documents zoomable, notre "ZoomViewer", que l'on peut intégrer dans une page web. Seul souci avec Flash : il ne connait pas le drag and drop.

Lire la suite...

mardi, février 2 2010

La puissance de HTML5 dans vos applis web

Paul Rouget vient de sortir une nouvelle démo montrant les possibilités techniques de Firefox pour les développeurs web. Ici cependant, c'est plus qu'une démo, c'est une véritable petite application concrète.

Il s'agit d'un outil, qui permet d'envoyer des images sur twitpic et comportant un éditeur d'image. Vous sélectionnez les images que vous voulez envoyer, vous les retouchez éventuellement, et vous les envoyez. Visualisez la video, c'est carrément génial, d'un point de vue technique. C'est du jamais vu dans une application web HTML (je ne parle pas d'applet java ou flash, souvent lourdes et peu ergonomiques).

demo_editeur_twitpic.png

Coté technique donc, voici ce qui est utilisé :

  • HTML5 Canvas: on ne présente plus l'élement <canvas>, qui permet d'avoir une zone dans la page web où l'on peut "dessiner" programmativement. Les images que l'on a glisser dans l'application sont "injectées" dans un canvas. Cela permet alors de les modifier, de proposer à l'utilisateur une mini application de retouche, avec des fonctions de découpage, de décoration, de mirroir etc. Avec Canvas, on peut aller très très loin. Voir par exemple cet outil, sketchpad, un paint-like bien plus beau que l'original :-)
  • HTML5 Drag and Drop: Paul utilise les évènements drag-and-drop, pour permettre, d'une part, de glisser des fichiers de votre bureau ou explorateur de fichiers vers l'application, mais aussi de glisser les images à l'intérieur de l'application entre les différentes fonctionnalités (glisser une image précédemment sélectionnée vers la poubelle par exemple).
  • File API : permet dans l'application d'avoir des informations sur les fichiers, à partir de ce qui est indiqué dans un <input type="file"> ou un évènement drag and drop qui concerne un fichier. Ça permet à l'application de réagir ensuite en fonction du type du fichier, de sa taille etc..
  • HTML5 localStorage: localStorage est un objet javascript qui permet de stocker ce que l'on veut, durablement, coté client. Il est utilisé ici pour stocker les images sélectionnées, en attendant de les envoyer vers twitpic. L'image, affichée en fait via un canvas (ce qui permet de la modifier), est en fait transformée en data URL. Cette URL est alors stockée dans localeStorage.
  • HTML5 Application Cache : toute la machinerie permettant de continuer à faire fonctionner l'application même en étant déconnecté, est utilisée. En particulier, un manifest "offline" est utilisé pour indiquer les fichiers de ressources (js, css) à stocker durablement dans le cache du navigateur, de manière à pouvoir recharger l'application, même en étant déconnecté. En fait, c'est comme si l'application était stockée en local. De plus, les évènements offline et online sont écoutés, pour pouvoir autoriser ou non la publication des images.
  • Cross Site xmlHTTPRequest, un mécanisme http permettant d'autoriser ou non à une application web (ici la demo) de communiquer avec une autre application web (ici twitpic).

Toutes ces technologies, dorénavant présente dans Firefox 3.6 et déjà plus ou moins dans d'autres navigateurs (je n'ai pas vérifié, ça ne va pas tarder en tout cas), offrent de bien belles perspectives en matières d'applications web puissantes et agréables à utiliser. À quand de telles fonctionnalités dans mon outil de blog préféré, pour faciliter l'insertion et la retouche de nouvelles images dans un billet sans ouvrir de lourdes applications graphiques desktop ? ;-)

Cerise sur le gâteau : cette application fonctionne parfaitement dans la version mobile de Firefox, qui est sortie hier pour Maemo :-)

- page 2 de 46 -