Subscribe: Jy[B]log
http://ljouanneau.com/dotclear/atom.php
Added By: Feedage Forager Feedage Grade B rated
Language: French
Tags:
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Jy[B]log

Jy[B]log





Updated: 2016-06-04T05:38:18+02:00

 



Défi 2016 redéfinit

2016-05-20T18:43:02+02:00

En début d'année, je m'étais lancé un défi : un commit par jour sur des projets open-sources. Ça fonctionné... pendant 86 jours. Au bout de 86 jours j'ai arrêté de vouloir commiter tous les jours, pour plusieurs raisons. Même si je suis un indécrottable geek dans l'esprit, et que je ne peux pas m’empêcher de coder même pendant les vacances, il y a des jours où je n'ai pas envie, où je suis trop fatigué, ou que l'emploi du temps (en particulier celui relatif à la vie familiale) ne me permet pas d'avoir du temps à consacrer au code. Il y a des jours comme ça où ce n'est pas possible. Cela serait possible si je vivais seul, sans ami, dans une cave coupée du monde. Mais ce n'est pas le cas. C'est le souci que j'avais crains en me lançant ce défi, et j'ai eu raison. Il y a des commits qui demandent plusieurs heures de travail. Je parle des vrais commits, ceux qui apportent un plus, des fonctionnalités complètes. Pas des commits "WIP", "WIP", "WIP", "DONE!!". Et donc il était très compliqué certains jours de produire un commit, faute d'avoir plusieurs heures devant soi à consacrer aux projets open-source. Il m'arrivait des jours où j'avais du temps, mais que j'oubliais (carrément) d'aller contribuer sur un de mes projets, et du coup je m'y mettais dans l'urgence à 23h. Pas vraiment l'heure idéale pour avoir les idées claires et pour produire du bon code. Vers la fin de cette série de 86 jours, je commençais donc à avoir de plus en plus de mal à avoir ce commit quotidien, voir même à avoir d'envie de le faire. Je commençais alors à ruser : si je savais que le lendemain je n'allais pas avoir de temps, mais que j'en avais le jour même, je préparai un patch et le lendemain je n'avais plus qu'à lancer la commande commit. Et j'avais ainsi mon petit carré vert sur github pour la journée, même si je n'avais finalement contribué que 30 secondes. Il m'arrivait aussi de bosser sur un long truc sur un projet précis, sur plusieurs jours, et je prenais alors 5-15 minutes chaque jour pour aller committer un truc facile sur un autre projet, afin d'avoir mon petit carré vert du jour. Ça faisait avancer (un tout petit peu) cet autre projet, mais ça m'obliger à me concentrer au final sur 2,3 4 projets à la fois. Vous trouvez peut-être cela ridicule ? Je vous rassure, moi aussi. Limite honte d'ailleurs de vous avouer tout ça. C'est pourquoi j'ai arrêté cette idée d'avoir un carré vert tous les jours. D'autant plus qu'au final, ça me mettais autant de pression, sinon plus, que lorsque je ne faisais rien. Durant ces 86 jours, j'ai fini par oublier l'objectif premier (celui de faire avancer les projets) et me suis finalement focaliser sur la manière de dérouler le tapis vert github. Bref, au bout de 86 jours, c'est à dire le 26 mars, j'en ai eu marre. J'ai même fait une pause de quelques jours avant de m'y remettre plus sagement. La reprise s'est faite attendre, mais c'est reparti depuis disons fin avril. Sans me mettre la pression du "un commit par jour". Cette expérience a quand même eu un gros bénéfice de mon point de vue : j'ai vraiment avancé sur les projets qui me tiennent à cœur. Par exemple, j'ai pu sortir enfin une nouvelle version de SlimerJS pour le plus grand bonheur de ses utilisateurs. J'ai sorti aussi une version de maintenance de Jelix. Le "un commit par jour" n'est finalement qu'une métrique permettant de se rendre compte que "ça avance". Mais ça n'indique pas si ça avance bien et vite. Et au final, il n'y a que le résultat qui compte. Il faut donc trouver un juste milieu et trouver la motivation pour faire avancer les choses. L'objectif "avancer sur mes projets open-source" est un peu vague. Changeons donc l'objectif en un objectif plus précis : sortie de Slimerjs 1.0, Jelix 1.7 et WikiRenderer 4.0 avant décembre 2016. Voilà. C'est à priori atteignable sans trop me mettre la pression. Les retours des utilisateurs reste une motivation importante, mais il faut leur montrer que le projet vit. Fai[...]



Release of SlimerJS 0.10

2016-05-02T12:51:05+02:00

I'm pleased to announce the release of SlimerJS 0.10!

SlimerJS is a scriptable browser. It is a tool like PhantomJS except it is based on Firefox and and it is not (yet) "headless" (if some Mozillians could help me to have a true headless browser ;-)...).

This new release brings new features and compatibility with Firefox 46. Among of them:

  • support of PDF export
  • support of Selenium with a "web driver mode"
  • support of stdout, stderr and stdin streams with the system module
  • support of exit code with phantom.exit() and slimer.exit()
  • support of node_modules with require()
  • support of special files (/dev/* etc) with the fs module

This version fixes also many bugs and conformance issues with PhantomJS 1.9.8 and 2.x. It fixed also some issues to run CasperJS 1.1.

See change details in release notes. As usual, you can download SlimerJS from the download page.

Note that there isn't anymore "standalone edition" (with embedding of XulRunner), because Mozilla ceased to maintain and build XulRunner. Only the "lightweight" edition is available from now, and you must install Firefox to run SlimerJS.

Consider this release as a "1.0pre". I'll try to release in few weeks the next major version, 1.0. It will only fix bugs found in 0.10 (if any), and will implement last few features to match the PhantomJS 2.1 API.




Défi 2016 : un commit par jour

2016-01-27T16:27:17+01:00

Fin 2015, période de fête, et période "faisons le point". Pas folichons ce point, concernant mon blog et mes projets open-source. Je n'ai pas écris un seul billet en 2015, et l'activité sur mes projets libres n'a pas été terrible.

Sur github, voici comment mon activité était représenté il y a quelques semaines :

(image)

Parmi toutes ces contributions, indiquées par des carrés verts, il n'y a pas que des évolutions sur le code de mes projets mais aussi des évolutions sur l'extension Opquast Desktop (une mission financée par Temesis, afin qu'elle fonctionne sur les dernières versions de Firefox), et également des ouvertures de tickets, des commentaires...

Cette baisse d'activité sur mes projets libres, en particulier sur Jelix et SlimerJS n'est pas terrible pour moi dans la mesure où ça n'avance pas beaucoup alors que ça m'est utile et que c'est utile pour des utilisateurs.

J'ai donc décidé que cette année, premièrement, j'essaierai d'écrire plus souvent sur mon blog (voilà un premier billet), et deuxièmement, j'augmenterai l'activité sur mes projets libres ou d'autres projets libres, avec un défi : au moins 1 commit par jour sur un dépôt. Et pendant mon temps libre bien sûr.

Un commit, ça peut paraitre beaucoup parce que parfois, pour ajouter une fonctionnalité ou corriger un bug, et donc aboutir à un commit, cela peut prendre plusieurs heures (et je n'ai pas "plusieurs heures" de temps libre chaque jour), et cela peut paraitre peu, parce que, juste "un" commit...

Donc, est-ce réalisable ? Est-ce utile ? Est-ce que cela va apporter vraiment un plus sur mes projets ? Est-ce que cela va être compatible avec mes autres activités ?

J'ai trouvé des réponses dans le post de John Resig, qui s'est lancé le même défi en 2014. Depuis presque deux ans, il arrive à coder tous les jours sur des projets libres, comme on peut le constater sur son tableau de bord github.

Et finalement, pour moi aussi ça fonctionne : depuis presque un mois, j'arrive à committer tous les jours sur mes dépôts Github, en y passant une heure ou deux, le soir principalement. C'est une question d'organisation et d'entrainement. Comme je travaille tous les jours sur un de mes projets perso, je perd moins de temps à me remémorer où j'en suis. Je ne perds pas le fils. Du coup je passe moins de temps que je pensais au début, tout en restant efficace. Je ne sacrifie pas tellement ma vie de famille : mon temps libre est mieux utilisé, tout simplement. Il "suffit" d'aller moins sur les réseaux sociaux, de moins regarder la télé...

Pendant les vacances, ça sera plus compliqué à cause des activités familiales, mais je trouverais bien quelques minutes par-ci, par-là pour coder un peu.

Effets secondaires, en parti énoncés par John :

  • stress et sentiments de culpabilité par ce que ça n'avance pas : envolés.
  • l'envie et la motivation sont revenus. Pour de multiples raisons :
    • parce que mes projets avancent (doucement mais sûrement)
    • satisfaction "du devoir accompli"
    • voir ce tapis vert se dérouler sur ma page github, même si c'est idiot :-)



20 ans

2014-09-18T20:42:56+02:00

Il y a 20 ans (en septembre 1994 donc), je faisais ma rentrée à l'IUT informatique d'Orsay. Cela faisait déjà quelques années que j'avais découvert les ordinateurs et appris à programmer : Basic sur Thomson TO9, C/C++ sur PC (avec Borland ;-)), assembleur/RPL sur HP48... Bref, j'entrais dans un monde qui ne m'était pas totalement inconnu. Ou presque. J'ai tant appris en fin de compte à l'IUT : les bases de données, les réseaux, Unix, la programmation système sous Unix, la modélisation de données et plein d'autres choses encore. Dont une qui a changé le monde. J'ai découvert Internet. Internet à l'époque, on n'en parlait quasiment pas au niveau grand public. Dans les magazines SVM de l'époque (je les ai encore !), ils commençaient tout juste à en parler, une ligne ou deux par numéro. Et encore. L'actu c'était plutôt la commercialisation grandissante des PC à base de Pentium, "l'informatique multimédia" avec la technologie hype de l'époque : les CD ROMs ! Ou alors de temps en temps on trouvait deux trois trucs sur les BBS. Bref, Internet, j'en avais vaguement entendu parlé, mais jamais vu, jamais pratiqué. À l'IUT, il y avait donc Internet. L'université venait tout juste d'être relié à Renater (si je ne dis pas de bêtises). Nous avions dans les salles non pas des PC (trop peu évolués), mais des stations X (sous X-Windows donc) HP, reliées à un bon gros serveur BULL sous AIX. Cependant mes premiers TP avec AIX, je les ai fait sous de simple terminaux vert sur noir de type VT100. Premier challenge : utiliser Vi. Attention, je ne parle pas de Vim. Mais de son ancêtre. Aux commandes imbitables. Et puis on est vite passé sur ces fameux terminaux X. Grâce à X-Windows, ils disposaient d'une vraie interface graphique, des vraies fenêtres graphiques. Un peu comme le Windows 3.1 de l'époque. Mais en mieux évidemment ;-). Hop hop hop, vas-y que je t'ouvre des fenêtres dans tous les sens, pour compiler, lancer mes projets, discuter sur IRC, se connecter sur la machine du voisin pour lui changer son fond d'écran, comprendre la technologie TCP/IP, les sockets réseaux. Et puis. Et puis. Et puis bien sûr : Mosaic ! Ahh Mosaic, le premier navigateur web que j'ai utilisé. Le premier navigateur web public tout court même. Le Web. Les pages Web. Je découvrais un univers fantastique, même si un peu "rugueux" à l'époque. CSS n'existait pas. La présentation des pages était minimaliste. Et d'ailleurs il fallait les trouver ces pages, parce qu'il n'y avait pas beaucoup de sites web, et même pas de moteur de recherche (pas dans mes souvenirs en tout cas), Altavista n'étant arrivé qu'un an plus tard... Mais avec cette superbe invention que sont les hyperliens, on arrivait à aller de sites en sites, et découvrir tous les jours des nouvelles choses. Sauf si on arrivait sur perdu.com (certes, apparu en 1996). Même si les débuts étaient balbutiants et la technologie très sommaire, je trouvais déjà le web extraordinaire. J'assistais à l'explosion de cette nouvelle forme de diffusion du savoir. Rendez-vous compte, grâce aux possibilités du réseau et la présence d'un serveur Web à l'IUT, je pouvais, gratuitement et sans effort (autre que celui d'apprendre les quelques balises HTML de l'époque), publier du contenu et le partager avec n'importe qui dans le monde. C'était magique. Révolutionnaire. Oui oui, révolutionnaire. Quelques temps après Netscape 1.0 était installé sur le système. Il avait de plus grandes possibilités HTML que Mosaic. malheureusement il était plus gourmand en mémoire et nos stations X avaient plus de mal à l'afficher. Et c'est ainsi que j'appris le HTML, en allant voir le code source des pages grâce au "view source" des navigateurs. Et je commença à produire quelques pages web, sans grand intérêt il faut dire. 5 ans après, je débutais ma carrière professionnelle dans le développement web, domaine que je[...]



Release of SlimerJS 0.9.2

2014-08-18T22:24:09+02:00

Few days ago, I released a minor version of SlimerJS, my scriptable browser based on XulRunner: SlimerJS 0.9.2.

If you discover my project: this is a browser which is controlled by a script, not by a human. So it has no user interface. In fact this is a browser like PhantomJS, which proposes the same API as PhantomJS. But it is based on Gecko, not on Webkit. See my previous post about the start of the project.

This new version fixes some bugs and is now compatible with Gecko/Firefox/Xulrunner 31.

Next big work on SlimerJS:

  • fix last issues that prevent GhostDriver to work well with SlimerJS
  • support Marionette(https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette)
  • try to implement remote debugging, to allow to debug your script from Firefox Dev Tools
  • try to have a true headless browser (so to have a browser without visible windows)

Help is welcomed, See you on Github ;-)




Outils d'integration continue, retour d'expérience

2014-03-06T11:33:08+01:00

Dans un billet précédent, j'avais fait un comparatif d'outils d'intégration continue. Après quelques jours d'utilisation, revirement de décision, j'ai finalement abandonné Jenkins...

J'avais testé peut-être un peu trop rapidement les différentes solutions. Il s'avère que je n'avais pas assez approfondi l'utilisation de Jenkins. L'une des premières tâches à implémenter, était de récupérer les sources d'un site statique à partir d'un dépôt git, et de les pousser via un rsync ou un scp vers le serveur de prod ou de dev en fonction de la branche. J'ai bien mis 2-3 heures à trouver les bons plugins, à les configurer et à faire en sorte que ça fonctionne. Et encore, le résultat me paraissait un peu bancal. J'ai ensuite regardé pour une autre tâche de test / déploiement plus complexe. Je me suis battu contre l'outils. Usine à gaz.

J'ai abandonné. Quand on se bat trop contre un outils, il faut le changer.

J'ai alors ré-installé Gitlab-CI et écrit un petit script bash pour le déploiement du site statique. En à peine une heure, tout était opérationnel. Le site se déployait à chaque push, sur le serveur de test ou sur le serveur de prod suivant la branche modifiée. J'ai essayé un truc plus complexe. Idem, je ne me suis pas battu. J'ai juste écrit plus de code. C'est moins sexy qu'un clickodrome, mais au moins ça fait exactement ce qu'on veut.

J'ai ré-installé également Strider-CD, en me disant que puisqu'il faudra que je me tape des scripts de tests/déploiement à la main, pourquoi ne pas ré-essayer Strider-CD. Rappelez vous, je disais qu'un de ses défauts était le manque de plugins, mais il en a un par défaut qui permet de lancer simplement des scripts, comme Gitlab-CI. Son autre souci est que l'intégration avec Gitlab ne se fait pas en un click. Il faut comprendre à quoi correspond chaque paramètre de la conf. Au final, ça n'a pas fonctionné à 100%, à cause de problème de certificats. Car cette fois-ci, contrairement à mes essais précédents, le gitlab et le strider sont accessibles via HTTPS, avec des certificats signés par une autorité "non officielle". J'ai eu beau mettre le certificat racine au niveau du système, toujours ces problèmes de certificats. Bref, j'ai lâché l'affaire au bout d'un moment. Par contre j'en ai profité pour tester son intégration avec Github : déclaration de l'appli Strider-cd dans le compte github, stockage des clés dans la conf, clic sur le bouton github dans l'interface : j'ai accès à tout mes projets github. Quelque autres clics plus tard, j'avais une tâche qui clonait le projet et pouvait exécuter des scripts sur les sources. Simplissime au final.

Conclusion :

  • Je laisse de coté Jenkins, finalement trop usine à gaz. Peut-être convient-il mieux pour des processus de tests très complexes ou projets java. Je ne sais pas. Mais en tout cas, à l'heure actuelle, il ne me plait pas du tout en tant qu'admin.
  • Gitlab-CI : le compagnon idéal quand on utilise Gitlab. Noter qu'il ne peut travailler qu'avec Gitlab. Il a quelques limitations comme je l'ai mentionné dans le billet précédent, mais on peut éspérer des améliorations dans un futur proche
  • Strider-CD : la solution la plus simple pour des projets se trouvant sur Github ou Bitbucket, que j'utiliserais probablement pour mes projets comme Jelix ou SlimerJS



Comparatif des outils d'intégration continue

2014-03-06T11:26:18+01:00

En ce moment j'ai pour mission de mettre en place une plateforme de développement. Gitlab a été choisi pour héberger les sources des projets internes et clients. Il faut maintenant mettre en place un outils d'intégration continue, open source si possible. Le premier qui vient en tête est Jenkins. Mais il a des défauts, aussi je suis allé à la recherche d'alternatives, que j'ai installé et testé. Gitlab-CI Nous utilisons GitLab, alors pourquoi ne pas utiliser Gitlab-CI ? Interface épuré, forte intégration avec Gitlab, il semble être un bon candidat, même si, en lisant les caractéristiques sur le site, il semble léger. Vérifions tout cela. C'est parti donc pour une installation. Il faut savoir que c'est réalisé avec Ruby On rails et utilise mysql ou Postgresql pour ses données. Première déconvenue : autant la documentation de Gitlab est très précise et claire (vous tapez toutes les commandes indiquées, dans le bon ordre, ça s'installe sans accro, en 20 minutes à peine), autant celle de Gitlab-CI est incomplète. Une impression de doc inachevée. Du coup ça a été un peu plus sport, avec, au hasard, des problèmes de création de la base de donnée avec PostgreSQL, l'absence totale de doc pour l'installer derrière un Apache (j'ai finalement pris le vhost créé pour Gitlab, renommé 2-3 trucs et ça roulait), des problèmes de configurations avec Puma, le serveur http utilisé par Gitlab-Ci (alors qu'ils utilisent Unicorn pour Gitlab...). M'enfin, on s'en sort quand même, avec un peu de temps et de patience. Deuxième déconvenue : le manque de fonctionnalité s'est confirmé. C'est un outil trés, trés, trés simpliste par rapport à la concurrence. Ce n'est au final qu'un super hook pour git : Gitlab-ci se "branche" sur un dépôt Gitlab (pour des dépôts hébergés par d'autres outils, oubliez) à l'arrivée des commits, il clone ou fetch le dépot, et lance un script (que vous devez écrire) via un des "runners" installés en local ou sur d'autres machines. selon le code de sortie du script, alors la tâche est considérée comme un succès ou un échec. le rapport d’exécution se limite à la sortie console de votre script. pas de prise en charge des sorties xunit etc une notification du résultat par email peut être faite. Et... c'est tout. Cela veut dire que vous devez tout faire à la main dans le script de la tâche : lancement des tests, déploiements etc... Il n'y a pas de système de plugins pour lui rajouter des fonctionnalités. Le seul intérêt est son intégration avec Gitlab : il partage le même système d'authentification, il sait lister tout les projets, et la création d'une tâche se fait en cliquant sur un bouton en face du projet dans la liste. (Mais une seule tâche par projet). C'est vraiment très light. Trop light pour nos besoins. Strider-CD Pendant mes recherches, je suis tombé sur cet outils que je ne connaissais même pas de nom : Strider-CD. Il a attiré mon attention grâce à quelques aspects originaux : il est basé sur NodeJS et utilise MongoDb pour le stockage de ses données il met en avant l'aspect déploiement d'un projet Et il semble un peu plus riche en fonctionnalité que Gitlab-CI. L'installation pour un simple essai est plus simple (si nodejs et mongodb sont déjà installés) : clonage des sources un coup de npm install strider addUser pour créer un premier utilisateur strider pour lancer le serveur qui est disponible alors sur le port 3000 Par contre la documentation ne donne aucune instruction supplémentaire pour une installation sécurisée en production, la conf Apache pour faire du reverse proxy etc... Mais on s'en sort avec Google. Je n'ai pas essayé de configuré l'appli en HTTPS... Strider-cd est orienté pas uniquement tests et intégration, mais aussi déploiement. Cela veut dire que les t[...]



Tada! Here is SlimerJS!

2013-07-16T14:04:58+02:00

Once upon a time, on the december 10th, 2012, I discovered CasperJS and PhantomJS and this was the beginning of a great history.... I was very impressed by this tools and I began to use it to do some tests on my PHP framework, Jelix [1]. But what is PhantomJS? This is a scriptable and an headless web browser. It means that it is browser which you can interact with a web site, only through a javascript script. No user interface, no window, no button. You write a script which call some functions like open() to open a web page, sendEvent() to "click" or "type a key" on the web page and so on. You can retrieve the content of the web page, you can take screenshots, listen all loading events etc. At the end, with PhantomJS, you can do automatic processing like functionnal tests or network monitoring. You already have many scripts to do many things, and one of them is CasperJS, which is a testing framework. The advantage of PhantomJS over similar tools like ZombieJS, is that it is powered by a well known and a true web engine. Here, this is Webkit (with JavascriptCore). It means that it has almost the same behavior of Safari (or Google chrome), and so you can test your web site as if you were into Safari or Chrome. In this tweet discussion, Anthony, a friend at Mozilla, has pointed out to me that with PhantomJS, I could not test with Gecko, the rendering engine of Firefox. And Nicolas, the author of CasperJS (I already met him in the past in some conferences) confirmed to me that some of his users would like to use CasperJS to test their web sites with Firefox. At the end ot the discussion, these following conclusions appears to me: On a one side: Because PhantomJS is only built on top of Webkit, some web developers cannot launch their tests on Gecko although they would like to use these great tools to test their projects with Firefox-like browser. PhantomJS and CasperJS have a great success, and are more and more used by web developers. It's great but it as a negative side-effect from my point of view: it increases the "webkit monoculture". I began to contribute to the Mozilla project, ten years ago, by doing tech evangelism, (and before, I did web standards evangelism with Tristan Nitot and others passionnate). So, you understand that these last months, I was very annoyed by this growing "webkit monoculture". I think this is bad for the Web. On the other side: The API of PhantomJS is not really complex, and there are not many API: it could be easy to implement a such API in a similar tool (well, it was I thought :)), even if some features would not be there, like the "headless" behavior, because Gecko needs a graphical interface to display web content. I played with Mozilla technologies (XUL, XulRunner, Gecko internals) for many years, in personal and professional projects. So it was clear to me that something should be done. I was be able to create a PhantomJS-like tools base on Gecko. I could do a concrete thing to fight this webkit monoculture. Am I The One for this work? :-) Ok, so, let's try, let's go. Two days later, I started the project. I found a name, SlimerJS, [2], I bought a domain name slimerjs.org, I opened a new project on Github, and I created the first commit. I then developed SlimerJS during my spare time. I released two versions, SlimerJS 0.6 and SlimerJS 0.7. It was pretty usable if you did not search to have a full compatibility with PhantomJS. The goal for SlimerJS 0.8 was to be able to launch CasperJS. With its tests suites, I have fixed many compatibility issues, and implemented all needed API that was not implemented yet. I had also improved CasperJS so it "knows" SlimerJS, and it can react correctly to some specifics behaviors. The result is a full compatibility with CasperJS, a new version of CapserJS, 1.1 beta and of course SlimerJS 0.8, released 7 months after the first line of cod[...]



Openweb a dix ans

2013-03-21T18:51:59+01:00

Il y a tout juste dix ans, le premier site français entièrement dédié aux standards du web ouvrait ses portes : Openweb.eu.org. Il fut le résultat du travail de 11 passionnés du web : Tristan Nitot, Laurent Denis, Pascale Lambert-Charreteur, Florian Hatat, Fabrice Bonny, Emmanuel Clément, Mathieu Pillard, Denis Boudreau, Olivier Meunier, Samuel Latchman et moi même. Nous publions tous un peu de notre coté des articles sur les standards (je venais d'ouvrir mon blog deux mois auparavant), et un jour nous nous étions dis que cela serait bien de rassembler toutes ces ressources en un seul lieu.

La magie du web a permis cela, bien que nous soyons tous aux quatre coins de la France (et du canada !).

Je me rappelle encore de certains soirées à coder chez moi dans mon bureau, ou encore cette seule et unique réunion IRL pour discuter du projet, dans les locaux d'AOL où Tristan travaillait. J'y rencontrais donc pour la première fois celui qui allait devenir le président de Mozilla Europe. Je crois aussi que j'avais croisé très furtivement à la cantine d'AOL celui qui allait devenir mon patron 1 an et demi plus tard, Daniel, chez Disruptive Innovations. En effet, les locaux abritaient ce qui restait de Netscape France (Daniel, Tristan, Peter...), filiale de la société à l'origine du projet Mozilla.

Depuis la publication des premières pages d'Openweb.eu.org, de l'eau a coulé sous les ponts. Les personnes qui animent le site ont changé, mais le site est toujours là et est encadré par des gens tout aussi passionnés par le web. Et malgré des périodes d'inactivité il y a quelques années, des articles continuent à paraitre régulièrement. Avec cette "monoculture" webkit qui menace, les standards du web sont plus que d'actualité.

Pour ma part, j'ai tourné la page "openweb" depuis quelques années. Mais j'en suis toujours aussi fier et je continue à soutenir les standards du web. Ce projet fut pour moi le départ de beaucoup de choses, comme mon aventure dans le projet Mozilla, qui démarra avec l'ouverture de xulfr.org dont je fêterai aussi les 10 ans cette année.

Bon anniversaire Openweb !




Firefox OS le grand challenger

2013-03-21T17:23:56+01:00

Le Mobile World Congress se termine aujourd'hui, et on peut dire que Mozilla a fait beaucoup parler de lui avec son nouveau système d'exploitation pour mobile, Firefox OS. Ça a démarré par une conférence de presse la veille de l'ouverture du salon. Mozilla annonçait alors que 18 opérateurs téléphoniques de par le monde, et 4 fabricants de mobiles (Alcatel, LG, ZTE et Huawei) allaient proposer à leurs clients, dans les mois à venir, des téléphones utilisant Firefox OS. Durant le salon, Sony a aussi déclaré se joindre à la partie, en publiant sur un blog comment installer Firefox OS sur un XPeria. Bref, Mozilla, avec son stand impressionnant, n'est pas passé inaperçu. Et c'était le but. Par contre, comme à l'accoutumé, à coté des gens approuvant à 100% le nouveau système de Mozilla, j'ai pu remarquer pas mal de scepticisme parmi les commentateurs en tout genre, la presse etc. 1) Face à Google (Android) et à Apple (IOS), Mozilla a peu de chance Mozilla aurait peu de chance si la fondation attaquait de front ces deux mastodontes, c'est à dire sur le même marché, ciblant les mêmes clients. Ce n'est tout simplement pas le cas. Mozilla cible en priorité les marchés émergents : Amérique du sud, certains pays d'Asie, et probablement l'Afrique. Elle cible les pays où le taux d'équipement en smartphone est très bas, voir quasi inexistant. Ce sont des pays où un Iphone ou un Galaxy SII n'ont que peu de chance de s'y vendre, à cause des revenus plutôt bas dans ces régions du monde. On pourrait dire donc que Mozilla vise la complémentarité. La fondation vise surtout à promouvoir le choix sur le mobile, comme elle l'a fait sur le desktop au temps où IE était utilisé par 95% des internautes. Elle avait Firefox Mobile sous Android. Elle a maintenant un système d'exploitation alternatif pour les mobiles, qu'elle propose aux intégrateurs, sans royalties. 2) Je suis déçu des spécifications des téléphones Firefox OS, ça ne me tente pas d'en acheter un Si vous vous dites cela, c'est que vous n'êtes tout simplement pas la cible. Malgré les bonnes ventes des Iphone et autre Galaxy, n'allez pas croire que tout le monde a autant les moyens que vous pour en acheter un. Certes, les téléphones annoncés avec Firefox OS ne sont pas très puissants (1GHz, mono-core ou dual-core maxi, 512Mo de RAM..). Mais rappelez-vous : Mozilla vise les marchés émergents. Donc nécessité de fournir des téléphones bas prix, donc peu puissants. Il se pourrait même que ces téléphones intéressent des gens dans nos pays "riches". D'une part à cause de la crise, et d'autre part, je suis persuadé que beaucoup de gens n'ont pas besoin d'un quad-core dans leur poche. En les observant dans le train ou ailleurs, que font-ils la plupart du temps : téléphoner, envoyer des sms ou des mails, jouer à des petits jeux, lire leurs messages facebook ou twitter. Très franchement, y-a-t-il vraiment besoin d'un dual-core, voir un quad-core pour faire ces tâches toutes simples ? Si le système est optimisé et peu gourmand, NON. Vous rappelez-vous des machines d'il y a 15 ans ? Elles étaient 10 fois moins puissantes, prenait 10 fois plus de place, mais on pouvait y faire le même genre de tâches sans aucun souci. Même moi je trouve que mon téléphone, un Galaxy SII, est "overkill" pour l'usage que j'en fais. 3) C'est motorisé par Firefox ? encore un téléphone qui va laguer lol mdr ptdr webkit roxor Vous savez quoi ? Vous devriez essayer un smartphone motorisé par Firefox OS. Là où un système Android devient vite pénible à utiliser sur les téléphones ciblés par Mozilla, FirefoxOS est plutôt véloce ! Moins de surcouches logiciels et un moteur (celui de Firefox), qui a connu d'énormes prog[...]



Firefox OS, ça va dépoter

2012-12-10T16:45:07+01:00

Depuis 3 ans, dans le cadre d'un partenariat entre Mozilla et la Miage d'Evry, je donne des cours sur les technos Mozilla, accompagné de Fabien Cazenave les deux premières années, et de David Rajchenbach-Teller en cette 4ième année. C'est le projet CoMETE. Jusqu'à maintenant, on enseignait les technologies pour réaliser des extensions pour Firefox (XUL, XBL, XPCOM etc...), mais cette année, nous avons décidé d'enseigner le développement web ++, avec les toutes dernières technologies proposées non seulement par Firefox, mais aussi par Firefox OS. Autant dire que les étudiants auront des cours à la pointe (pas comme moi quand j'étais à la Miage d'Orsay en 1996-98, où on nous enseignait encore du Cobol alors que Java faisait fureur :-/ ). Je suis le projet Firefox OS (aka Boot 2 Gecko) depuis le début. Vivien, l'un des développeurs de Firefox OS, m'avait fait l'honneur de me montrer les toutes premières versions de Firefox OS fonctionner sur un smartphone. C'était en Octobre 2011, 3-4 mois après le démarrage du projet et il y avait déjà des applis 100% HTML, dont celle pour lancer un appel téléphonique ! (bon, un bug empêchait de raccrocher :-) ). Cependant, je n'ai pas non plus suivi le projet de très près (comprendre : je ne suis pas les commits comme autrefois sur Firefox, et je ne contribue pas - encore ?- au projet). Mais pour préparer ces cours, je suis bien obligé de me plonger dans toutes ces webAPI, dans la réalisation d'une WebApp, ou encore compiler/tester Firefox OS sur mon laptop. Pour rappel, Firefox OS est un système d'exploitation pour smartphone (et dans le futur pour tablette), dont la particularité est que toutes les applications, y compris le "bureau", sont des applications HTML. En gros, Firefox OS, c'est seulement trois principales couches logicielles : un noyau linux et des drivers adéquates Gecko, le moteur de rendu de Firefox, accompagné de son moteur Javascript des applications 100% HTML5/JS Et bien sûr, pour que les applications puissent accéder au matériel (comme démarrer un appel téléphonique, envoyer un SMS, utiliser le capteur photographique...), il faut des nouvelles fonctions JS utilisables dans le fichier HTML de l'application. Ce sont les fameuses WebAPI, que Mozilla ne se contente pas d'ajouter, mais aussi de proposer à la standardisation au W3C. Je dois dire que je suis de plus en plus enthousiaste sur Firefox OS. On va pouvoir réellement tout faire, y compris dialoguer avec les autres applis via les WebActivities. On va pouvoir porter tout ces nouveaux Jeux HTML reposant sur WebGL, vers FirefoxOS, en profitant de nouvelles api (faire vibrer le téléphone, utiliser l’accéléromètre...). L'interface actuelle de Firefox OS montre ce que l'on peut faire avec les transformations et animations CSS3 pour tout les petits effets graphiques. Bref, on va pouvoir refaire le monde avec des technologies que finalement bon nombre de développeurs maitrisent déjà (HTML, JS, CSS), à savoir des technologies standards. Plus je vois Firefox OS avancer, évoluer, plus je me dis que Mozilla va réussir son pari, celui d'offrir une réelle alternative à IOS et à Android, comme Mozilla l'avait réussi avec Firefox dans un tout autre contexte. Les sceptiques diront que d'autres ont déjà essayé (WebOs par exemple), mais comme l'a écrit Daniel, Firefox OS n'est pas qu'un simple navigateur posé sur un noyau, Firefox OS va plus loin, car Mozilla standardise. De plus, Mozilla ne fait pas ça dans son coin, il a des partenariats avec des opérateurs, en particulier Telefonica, qui vendra des abonnements+téléphones avec Firefox OS préchargé, dés le premier trimestre 2013 , au Brésil. Vivement que je puisse m'acheter un smartphone et une tablette F[...]



FakeServerConf, une nouvelle lib pour vos tests PHP

2012-12-04T12:34:00+01:00

Pour tester certains composants du framework Jelix, comme la partie "routage", j'ai besoin d'avoir des paramètres serveurs correctement définis, en particulier dans la variable globale $_SERVER. En effet, les tests étant lancés en ligne de commande avec PHPUnit, $_SERVER ne contient pas du tout la même chose que lorsque le script PHP est lancé par un serveur HTTP. Pire, pour une même URL, nous n'avons pas la même chose selon si PHP est lancé en CGI/FPM, ou si c'est le module PHP pour Apache qui est utilisé.

Bref, cela devient fastidieux dans un environnement de tests en ligne de commande de simuler un contexte HTTP.

C'est pourquoi j'ai crée cette petite bibliothèque, FakeServerConf. On lui indique le type de serveur que l'on veut simuler, et l'url que l'on demande (avec la méthode GET, POST, DELETE...), et FakeServerConf rempli correctement $_SERVER, $_GET et $_POST avec les bonnes valeurs. Vous n'avez plus qu'à tester vos classes qui utilisent ces variables. Et vous pouvez de plus tester avec les différents types de serveurs pris en charge par FakeServerConf. Pour l'instant il n'y a qu'Apache+mod_php et Apache +cgi ou fpm.




Experience de désinfection d'espionnage web

2012-12-01T12:42:43+01:00

Quand on surf sur le web, il faut savoir que l'on est de plus en plus pisté, tracké. Notre parcours est analysé, et permet alors aux régies publicitaires de vous afficher des pubs ciblées, ou encore à d'autres sociétés de compléter votre profil qu'elles ont déjà en partie, comme facebook,et google. Ces grosses entités commencent à tout savoir de vous. Et de moi. Et le gros souci, c'est que l'on ne sait pas ce qu'elle font de toutes ces données (en dehors des pubs). Vous avez des doutes sur le fait d'être pisté ? Lisez la suite. En mars dernier, à sa sortie, j'ai installé l'extension Collusion. Elle permet de visualiser justement tout "ces espions" et leur liens avec les sites web. Après l'installation, je trouvais ça rigolo de voir ses graphiques, Et puis je l'ai oublié jusqu'à aujourd'hui. Cependant, Collusion n'a pas oublié de faire son job, et a continué à faire ses statistiques. Ce matin, je l'ouvre. Et voici le résultat : (cliquez dessus pour voir en grand). Les ronds représentent les sites web que vous visitez, et surtout ceux que vous ne visitez pas explicitement. Cette deuxième catégorie de site web sont les sites auxquels font appels les sites que vous visitez, pour leurs statistiques, pour afficher des pubs, pour afficher les boutons twitter, facebook, google+ etc. Plus un site à de liens avec d'autres sites, plus le le rond est gros. Sur mon graphe, devinez quels sont les sites que les plus gros rond représentent ? Du plus gros au moins gros: Google Analytics, "l'espion" de google installé par les développeurs sur leurs sites pour savoir les statistiques de visites. Mais qui profite aussi à Google pour vous pister (faut pas se leurrer) Google.com : il est vrai que j'utilise google comme moteur de recherche principal. Mais ici on parle de liens entre site. Il s'agit donc très probablement la faute aux boutons "google+" installés un peu partout. Facebook.com : c'est "très rigolo" de le voir là, je ne vais JAMAIS sur facebook. Je n'aime PAS Facebook. J'en déduis que sa "popularité" dans les stats de Collusion est due aux boutons "facebook" installés partout sur les sites que je visite. Twitter : j'utilise le site twitter au quotidien. Mais il y a aussi des boutons "twitter" partout, la preuve en est sa présence dans ce top 5 des sites les plus liés. Googleapis.com : représentent tous les outils google utilisées par les sites web Et il y aussi Facebook.net (le retour), quantserve.com (outil statistique), Xiti, autres sites annexes de google etc. Bref, beaucoup des rond moyens et gros sont des sites de stats, de collectes d'informations, de trackers pour les régies publicitaires. Il y a aussi Gravatar qui est pas mal lié aux sites web, dans mon graph. Par contre peu de site de régies publicitaires en elles-même, probablement parce que j'ai depuis longtemps installé l'extension AdBlock+ pour bloquer les pubs dans les sites web. Je ne supporte pas les pubs. Mais Collusion montre déjà que le nombre d'espions installés sur les sites web sont faramineux, sans même que les développeurs qui installent ces bouts de scripts JS n'aient conscience du potentiel qu'ils apportent à ces entreprises de collectes d'informations. Et si vous pensez que je crois trop aux théories du complot, il y a plein d'articles sur le web et même des reportages à la télé (Jeudi dernier dans Envoyé Spécial par exemple), où les annonceurs avouent ces pratiques. Je vais maintenant tenter de ne plus laisser mes traces sur le web. Parce que ça me dérange que l'on me piste ainsi. Les actions que j'ai dés maintenant entrepris : effacer les données de Collusion, pour voir l'impact de cette expérience [...]



La nouvelle API password dans Jelix

2012-12-01T00:25:36+01:00

Il y a un mois je sortais les dernières versions correctives de toutes les branches actives du framework Jelix. Et ça fait un mois que je pensais à écrire ce billet :-).

La raison de ce billet est que ces versions correctives inclues non seulement quelques corrections de bugs comme d'habitude, mais aussi une amélioration dans le système d'authentification de Jelix : il peut désormais utiliser la nouvelle API de mot de passe que proposera PHP 5.5. Une bibliothèque en PHP, password_compat permet de l'utiliser dés maintenant en attendant la sortie de PHP 5.5 et est incluse dans Jelix. J'y ai d'ailleurs apporté quelques modifications pour l'utiliser sur Debian Squeeze.

Pourquoi utiliser cette API ? Parce qu'elle est très simple à utiliser, tout en apportant un hachage fort des mots de passe en utilisant l'algorithme Blowfish par défaut. Dans PHP, on a déjà des fonctions pour encrypter fortement du contenu. Mais il faut avouer que c'est particulièrement compliqué à utiliser.

Pour en savoir plus sur cette nouvelle API, voir l'article de Pascal Martin.

Abandonnez md5, sha1 pour hacher vos mots de passe et les stocker en base de données, ou au moins ajoutez un sel aléatoire. Préférez SHA2 ou supérieur, bcrypt, blowfish, qui sont plus robustes aux attaques de type "brute force", aux "rainbow tables" etc...




Sous utilisation de la freebox

2012-09-30T15:06:51+02:00

J'ai une freebox depuis quelques années. J'ai migré vers la V5 quelques mois avant la sortie de la v6. C'est bête me diraient certains. Ou pas. En fait, j'aurais mieux fait de rester avec une V4. Car le constat après 2 ans d'utilisation est amère : j'aimerais bien moins payer si je le pouvais.

En effet, je n'utilise au final que la partie "modem" et "routeur" de la freebox : pour faire du web, lire mes mails, faire du ssh, irc etc..

Le téléphone ? je ne l'ai jamais utilisé. Bon, faut dire aussi que je n'ai transmis le numéro à personne. Mais mon mobile étant suffisant....

Les centaines de chaînes télé ? Je ne les regarde pas. Déjà avec la V4, j'avais vite arrêté de zapper tellement il y a de chaînes, et tellement il y a de programmes inintéressants. Ou alors il faut passer à la caisse pour avoir accès aux chaînes susceptibles de m’intéresser. Et encore faut-il que la qualité d'image soit là. Je constate trop souvent des "patés" dus à de trop fort taux de compression. La TNT est de meilleure qualité globalement. Donc je reste avec les chaînes de la TNT, en passant par ma télé en direct bien sûr, parce que le module TNT de ma freebox n'a jamais fonctionné.

Le magnétoscope numérique ? comme il y a 20 ans pour mon magnétoscope VHS, ça m'est arrivé d'enregistrer un épisode d'une série par exemple, mais j'oubliais toujours de regarder l'enregistrement. Bref, je n'utilise pas.

Les jeux et autres applications : qualité trop moyenne. Et puis ça commence à faire quelques années que je ne joue plus et que je n'ai plus vraiment de temps pour ça.

Le wifi ? pas de wifi chez moi. Le filaire (ethernet 1Gb) me suffit.

Le NAS de la V6 ? Il me serait inutile car J'en ai déjà un. Et puis "bizarrement", je n'ai pas envie de confier mes données à une boite noire,

Bref, je paye au final des services dont je ne me sers pas. D'ailleurs j'ai fini par débrancher le boitier multimédia.

J'ai bien pensé à changer de fournisseur d'accès internet, mais le souci est que plus aucun ne propose une offre ADSL simple, à un prix inférieur. Il y a quelques jours encore, OVH en avait une, mais elle a disparu. Avec FDN, le tarif est à peine inférieur qu'une offre triple play (certes, on a une neutralité totale du réseau..). Et free reste le moins cher parmi toutes les offres "machinbox". Alors voilà, je suis "condamner" à utiliser une "freebox".




Sortie de Jelix 1.4

2012-08-30T23:40:30+02:00

Diantre ! 10 mois que je n'ai pas parlé de mon framework PHP Jelix sur mon blog ! Cela date de... la sortie de Jelix 1.3 :-) Et dire que quelques semaines après la 1.3, j'avais annoncé sur la mailing-list que j’accélérerais la cadence des sorties à 2-3 mois. C'est raté. Il faut croire que le rythme est bloqué à 10 mois.

Donc voilà Jelix 1.4 avec sa tonne de nouveautés : cache HTTP, autoload PSR0, templates virtuelles, amélioration de la prise en charge des codes langues, des modules de plus en plus autonomes etc...

Le retard de cette sortie est due à plusieurs choses :

  • Déjà, les vacances d'été, chantiers chez moi etc : j'ai été souvent offline ces dernières semaines :-)
  • La faute à pas de temps
  • La mise en place de docs.jelix.org
  • La libération du code source des sites de Jelix.org

La faute à pas de temps : en effet, j'ai eu un contrat de plusieurs mois (qui se termine), sur un projet hyper intéressant (à base de XUL/javascript), mais plutôt éloigné de chez moi. Donc beaucoup de temps de trajets et de fatigue. Résultat, avec les autres tâches à coté, le projet n'a pas avancé aussi vite que j'aurai voulu

La réalisation du site http://docs.jelix.org a permis de migrer les manuels, du wiki Dokuwiki vers un nouveau système de wiki basé sur Git, et que j'ai développé avec Jelix bien entendu : Gitiwiki. J'en parlerai plus longuement une autre fois. Basculer la documentation sur Git a permis d'accélérer les améliorations du manuel : je peux maintenant écrire en offline (dans le RER par exemple). Par contre, plus en online...Temporairement... Gitiwiki fonctionne pour le moment en lecture seule. Il faut encore que je développe la possibilité d'éditer en ligne :-) (c'est en cours). Cependant, cela ne devrait empêcher personne de contribuer au manuel : il est sur github.

Enfin, comme je disais, j'ai aussi passé du temps à libérer le code source du site jelix.org et bien sûr le code du nouveau site docs.jelix.org, dans l'espoir d'avoir plus d'aide sur tout ce qui fait tourner le projet ;-).

Et puis comme je ne suis pas toujours discipliné, j'ai préféré ces 2-3 derniers mois, à commencer à développer Jelix 1.5 plutôt que de paufiner Jelix 1.4 !




Ma période HP48, Minitel et RTC-ONE

2012-07-13T14:02:26+02:00

Au début des années 90. Je délaissais mon TO9, pour commencer à manipuler le PC flambant neuf de mon père, en découvrant le langage C. Mais j'étais aussi à fond sur la programmation de la calculatrice HP48. Une pure merveille cette machine. Elle avait un écran large, des touches inusables, un port série et infrarouge pour communiquer, et pour la version SX, deux ports pour mettre des cartes mémoires. Elle n'était pas encombrante, du coup, elle ne me quittait quasiment jamais. Je pouvais coder n'importe où. Chez moi, dans le bus, au lycée. Je me rappelle de mon prof de math en terminal, qui me faisait remarquer en classe, au début de l'année, qu'il serait bon de suivre les cours, plutôt que de coder à longueur de temps. Mais il avait fini par m'ignorer, me laissant tapoter sur ma machine, sous son nez, au premier rang. J'ai tout de même été puni : j'ai raté mon bac cette année là (1992). Mais cela ne m'a pas calmé, loin de là, parce que cette même année, j'ai découvert les capacités insoupçonnées de cette machine. J'utilisais jusqu'alors le langage de haut niveau intégré au système de cette machine, le RPL, On arrivait à faire pas mal de trucs, mais ce n'était tout de même pas très performant. Ça commençait d'ailleurs limite à me lasser. Mais le destin, dans sa grande bonté, ne m'a pas laissé dans ce marasme geekesque... Comme tout bachelier en préparation, j'allais passer quelques concours pour tenter de rentrer dans des écoles supérieures. Avec la HP48 bien sûr. Et voilà qu'à la sortie d'une des épreuves, un petit groupe d'étudiant se forme, tous avec une HP48 à la main. Ah ? Tient ? des HP ! Mais que font-il ? Ah tient, ils s'échangent des programmes. Faites voir les gars ! Et là le choc. Tellement un choc d'ailleurs que je m'en souviens encore, 20 ans après. L'un d'eux me montre un clone de Pacman.Oui oui, le petit jeux des années 80. Ça vous fait rire hein ? Mais attention, ce n'était pas un truc laid et lent fait en RPL. Non non. C'était un jeu bien fluide, super jouable. C'était comme sur une Game Boy, la console portable phare de l'époque. Mais comment était-ce possible ? "C'est programmé en assembleur" m'a t-on répondu. Et voilà comment j'ai basculé dans la programmation très bas niveau. Je me suis renseigné, je me suis procuré plein de nouveaux programmes que j'ai récupéré au fil du temps, dont le seul outil de l'époque pour faire de l'assembleur, ASMFlash (j'ai fini par faire le mien, J-Asm). J'ai acheté les bouquins "voyage au centre de la hp48", détaillant tout le fonctionnement des processeurs Saturn des HP, les instructions assembleurs, allant même jusqu'à indiquer le nombre de cycle d'horloge que prenait chaque instruction. Et pour faire des prouesses en termes de performances, je n'hésitais pas à calculer le nombre de cycle d'horloge que me prenait telle ou telle partie du programme. Un peu cinglé quoi :-). Mais je n'étais pas le seul cinglé. J'avais eu l'occasion de retrouver d'autres passionnés à des "HP parties", organisées dans des écoles informatiques, ou même carrément dans les locaux de Hewlett Packard sur Paris. HP en a ainsi organisé quelques unes - avec des concours de programmation, dont un où j'avais terminé 2ième \o/ -, très intéressés qu'ils étaient par ce que cette petite communauté de développeurs pouvait faire avec cette calculatrice. Intéressés à un point qu'ils finiront par embaucher quelques un d'entre eux, Cyrille de Brebisson et Jean-Yves Avenard, qui étaient les créateurs du "Meta Kernel", un firmware[...]



De retour avec KDE

2012-06-14T09:13:50+02:00

Il y a un peu plus d'un mois et demi, j'avais tenté un truc. Mon laptop a deux cartes graphiques, une intégré au chipset intel, et une carte séparée, NVidia. Cela permet, pour les systèmes d'exploitations qui prennent en charge, de pouvoir utiliser l'une ou l'autre carte graphique en fonction des besoins des applications, et donc optimiser la consommation en énergie. C'est la fameuse fonctionnalité "Optimus". Sous Windows, pas de souci. Sous Linux par contre, aucun support (j'étais alors sur une Ubuntu 11.04 32bits). C'est soit la carte faiblarde Intel, soit la carte puissante NVidia, mais il faut alors désactiver l'Optimus dans le bios pour pouvoir l'utiliser. Et l'ennui c'est que, bien qu'il n'y ait qu'une carte utilisée par le système, la deuxième est toujours active, donc pompe du courant pour rien. Et comme j'ai choisi la NVidia, j'ai alors une autonomie plutôt limitée, à peine deux heures :-/ Il y a toutefois un projet pour apporter ce support : Bumblebee. Cela semble prometteur même si un peu embêtant à utiliser puisque si on veut le support NVidia pour une application, il faut la lancer avec un utilitaire fourni. Cependant, fin Avril, je tente le coup, j'avais du temps, je passais des vacances en Bretagne. J'installe les paquets, mais au final rien ne fonctionne. Problème au redémarrage au niveau de X-Windows. Pire, la désinstallation des paquets ne règle pas le souci. J'essaye de régénérer les fichiers de boot etc, rien. Que dalle. Mon système est flingué. Merci Bumblebee. Je n'avais pas envie de passer toutes mes vacances à tenter de régler le problème. J'aurai plus vite fait de tout réinstaller. Et ça tombe bien, il fallait que je mette à jour vers une version plus récente d'Ubuntu. Cependant, Unity ne me plaît pas du tout, les dernières avancées dans Gnome ne me satisfont pas. Et si je retentais KDE ? KDE, mon environnement de bureau fétiche jusqu'à la sortie de sa version 4. J'avais été pas mal déçu par KDE 4.1, et j'étais alors resté sous Gnome (qui était pré-installé sur le laptop que je m'étais payé quelques mois auparavant). Depuis 4 ans, tous les problèmes ont dû être réglé, me dis-je. Hop, c'est parti pour la dernière Kubuntu. Et je ne suis pas déçu. Effectivement la plupart des reproches que j'avais n'ont plus lieu d'être. C'est réactif, fluide, agréable à utiliser. Il y a bien quelques petits trucs qui me chiffonne (comme le fait que dès qu'on approche une fenêtre du haut de l'écran, KDE met cette fenêtre en plein écran, et je n'ai pas encore trouvé comment désactive ce truc, Merci à Hello dans les commentaires, c'est réglé :-) ), mais ça reste supportable. Depuis un mois et demi donc, je suis très satisfait de KDE4. Bon, par contre, malgré que je profite d'un noyau plus récent, toujours pas de prise en charge d'Optimus. Ni d'ailleurs de mon lecteur d'empreinte, ni de mon touchpad multitouch (pour ce dernier, j'ai ouïe dire que c'était réglé dans le tout dernier noyau...). Cependant, depuis un an que j'ai ce portable [1], le lecteur de carte SD, le firewire et les diverses fonctions de mise en veille fonctionnent enfin sans bugger ! Avec Linux, il faut être patient :-) Aller Dell, un petit effort pour fournir des drivers linux (même proprio, je m'en fiche) avec vos nouvelles machines, comme dans le temps... Notes [1] un Dell latitude e6520 avec toutes les options au maximum :-) [...]



jsDatasource, a component for XUL templates

2013-03-21T17:23:56+01:00

I just released publicly a new version of a component : jsDatasource.

This component allows to use javascript objects as datasource for XUL templates. You can use it in your own extension or XUL applications. It becomes easy to use XUL templates with js datasources!

I started this component in 2009, for a software, ZoomCreator, when I worked for Zoomorama. Even if it was written under a free licence, I didn't release it at this time (well, I had so much work..). And for a recent customer project, I need it with some improvements, like the support of recursion or the support of sorting. So I improved it, and I just open a public repository :-)

I hope it will help some XUL developers :-)




Un serveur pour des tests ? Node bien sûr !

2012-03-17T00:07:38+01:00

Pour une grosse extension pour Firefox (un projet client), j'ai réalisé entre autre chose un composant qui agit sur des pages web. Pour tester ce composant (avec des tests unitaires bien sûr !), j'avais besoin d'un serveur web servant des pages HTML statiques.

J'avais bien pensé à apache, mais ça m’embêtait de déployer toute une artillerie comme WAMP, surtout sur la machine de travail que l'on me prête, pas très performante (et sous windows mais bon, c'est une autre histoire... :-) ). Et puis ça m’embêtait de configurer un serveur web tout court. Donc exit aussi Nginx.

Bref, je voulais un truc très simple, très light. Je me suis alors tourné très vite vers node. Téléchargement, lancement de l'installateur, click, click, c'était installé.

J'ai choppé ensuite un script JS implémentant un serveur http de fichiers statiques, pour node, comme on en trouve par dizaine sur le web. Une ligne de commande plus tard, j'avais un serveur qui écoutait patiemment le port 8080.

En moins de 5 minutes, j'étais prêt à écrire mes tests. J'ai trouvé ça génial :-) Ça c'est de la productivité !