Pas question ici de parler de politique de vie privée, ce débat (à ce moment précis) ne m'intéresse pas. Non, il est question de technologie ici. Google a décidé depuis quelques temps de faire des choix pour vous, ou du moins pour une petit classe de personnes qui ont fait des choix technique.

Parlons donc de deux cas. Google+ et le WebGL dans Chromium (et Google Chrome).

D'abord, Google+ puisque j'aime ce service. Je vous en ai parlé, je travaille sur Xmonad, et pour des questions d'ergonomie j'utilise un navigateur basé sur WebKit nommé Uzbl (merci WillQ du canal fedora-fr sur irc). Ce navigateur, rapide, léger, propre, sans fioritures utilise donc le même moteur de rendu que Chromium et Google-Chrome. Mais si je vais sur la page de google+... on me refuse l'accès.

Comprenez bien, je n'ai rien contre le fait que la page ne fonctionne pas "comme prévue" et qu'on me prévienne... mais me dire "non, installe toi un autre navigateur" et refuser de m'afficher la page... moyen là !

L'interdiction est limite, vraiment... parce que en changeant mon "useragent" pour faire passer mon navigateur pour un google-chromme la page apparait parfaitement bien. Donc, plutôt que d'interdire l'accès, je préfèrerai simplement qu'on me dise "on connait pas votre navigateur, donc vous savez désormais que la page que vous allez voir ne marchera pas comme prévu".

Bref, passons...

Uzbl a du mal avec WebGL, ça me parait logique et je n'en veut à personne... j'utilise donc tout bêtement mon chromium (navigateur chrome libre). Et vas y que je vais voir une page qui utilise du WEBGL... et paf ! Erreur: "votre navigateur ne gère pas le WebGL". Ah bon ? attend mais j'ai bien une carte graphique (pas la meilleure je sais, mais bon elle fait de la 3D mon ATI) alors pourquoi ça marcherait pas ?

Vérifions... on ouvre la page "about:gpu" et que vois je avec stupeur ? Ma carte est "blacklistée"... Je fouille sur le net et j'apprends qu'on peut passer outre... via l'option au lancement "--ignore-gpu-blacklist". Réouverture de about:gpu et miracle la carte est bien gérée. Tout fonctionne bien... sauf ? Google Map en 3D... un test bizarre de la part de Google et je peux même pas voir si ça marche vraiment ou pas, Google m'interdit l'accès...

D'une part, on me blackliste ma carte ce qui ne permet pas de tester vraiment sans connaitre l'option de coupure de blacklist, mais en plus on ne me permet pas de regarder si une page WebGL spécifique fonctionne, on rejette direct...

Comment peut on alors aider à trouver comment corriger une page WebGL si on ne nous autorise pas à la teste ?

Voilà, je me pose donc la question... Google a décidé de se débrouiller tout seul pour les tests ? A-t-il oublié la communauté qui peut tester et remonter des corrections ? Serait-il en train de se détacher de ceux qui ont donné toute sa valeur, c'est à dire... les geeks ?

Dommage, j'ai pas d'animosité à leur égard, mais ce "comportement" commence à me gêner fortement...

Je sais qu'il existe un outil bien sympathique nommé "tig" (git à l'envers) qui est une interface assez bien fichue pour avoir une vue assez "lisible" de votre dépôt. Mais sans avoir à installer un outils en plus, git permet déjà de voir un "graph" de vos commits, merges et branches, et ce de manière propre.

Je vous montre les étapes de tests que j'ai effectué, mais souvenez vous qu'à la fin de l'article il y a la manière "rapide" qui est ni plus ni moins que l'a création d'un alias de commande à git. Pour le moment, laissez moi vous montrer comment j'ai procédé.

En fait, tout va passer par la commande "git log" dont des options vont être ajoutées. Si vous tapez simplement "git log" dans votre console, vous aurez un log, certes lisible, mais pas très sexy. Passons par la première options que j'aime bien:

C'est déjà pas mal... nous avons ici une représentation des branches ainsi que le log de commit, l'auteur, etc... Bon admettez que c'est un peu "verbeux" et que certaines informations ne sont pas forcément "utiles". Ajoutons une seconde option "--pretty=oneline"

Ah, là on avance, bon on va réduire le checksum de commit avec "--abbrev-commit":

Sympa ! Reste deux options, dont une qui peut s'avérer utile mais malheureusement pas très visible dans mon exemple, les option "--branches" et "--color". La première, comme je vous le disais, n'est pas visible ici, par contre, la couleur oui !:

Reste alors un petit souci... cette commande est un peu longue à taper. Qu'à cela ne tienne, ajoutons notre "alias" dans notre fichier ~/.gitconfig:

Et de ce fait, les graphs sont directement utilisables de cette manière:

Notez que j'ai ajouté "--decorate" qui permet de voir les nom de branches, merges etc... en couleur.

Un dernier point, "git log" utilise le mode de lecture de log avec less, ce qui permet:

• la recherche avec la commande "/"
• enregistrer le log avec la commande "s" → la couleur est aussi enregistrée dans le fichier.

D'ailleurs, en parlant de cela, un module perl vous permet de resortir du code ansi en HTML, voici comment installer le module:

Reste alors à faire cette manipulation:

Surtout n'oubliez pas: aucun espace entre le "<" et "(git graph --all", cela à pour effet de créer un fichier "log.html".

Si vous ne voulez que le "corps" du fichier, pour l'injecter dans une page, utilisez la méthode ci-dessous:

Cela vous donnera ce résultat:

En relation avec l'auteur de la librairie http://quvi.sourceforge.net/ la discussion s'est d'abord orienté sur SWIG. Ce système permet assez facilement de créer une librairie python compilé depuis une librairie C. Or, après un test ou deux, j'ai trouvé assez compliqué de travailler avec ce système.

D'abord parce que SWIG (bien que très puissant et facile d'accès) me sort en fait les fonctions C telles quelles, sans vraiment s'adapter au langage visé, du moins pour python. Et secondo, parce que je connais bien Cython qui me permet de faire la même chose, mais en plus maîtrisable.

Si vous ne connaissez pas Cython, allez faire un tour sur mon blog fedora, j'ai écris ce billet pour proposer une introduction assez simple: http://blog.fedora-fr.org/metal3d/post/Cython-pour-optimis%C3%A9-Python

Le billet présente déjà comment compiler un "shared object" pour python, je me suis orienté alors sur la page de documentation http://docs.cython.org/src/tutorial/clibraries.html qui m'a parut assez claire pour débuter le travail.

L'idée principale a été de lire le fichier "quvi.h" pour y remonter les déclarations dont j'avais besoin, puis de préparer une classe qui me permet de récupérer les type C, pour les passer en objet python.

Le résultat a été immédiat. D'abord un ".so" bien plus petit qu'avec SWIG, mais en plus une classe que je pouvais mieux adapter au langage. Option qui ne m'a pas déplut, c'est qu'en plus j'ai un seul fichier "quvi.so" et non un "_quvi.so" et un "quvi.py" à utiliser.

Et enfin, la compilation se faisant via les "distutils" de python, la librairie est compilée et installé par un simple "setup.py".

Je vous invite donc à tester et me dire si la librairie fonctionne, non pas ici sur le blog mais sur la page du projet: https://github.com/metal3d/python-quvi

N'oubliez pas que sur github, il est préférable de forker le projet pour me proposer des pull request plutôt que des patchs. Notes enfin que je développe dans la branche "developpement" et non dans le "master".

Voilà pour la news :)

Partons d'un code python simple. Ce genre de code que vous tapez quand vous venez d'un autre langage. Ce code est évidamment juste et fonctionne. Je n'ai rien à redire à part que Python va vous permettre de le rendre plus court tout en restant optimal.

Bon, reprenons rapidement le fonctionnement de cette fonction. Si l'adresse ip commence par 192.168 alors on a une ip locale, on retourne donc True. Si elle commence par "10", idem, on retourne vrai... et enfin, 3 ième cas, l'ip comence par 172 et son deuxième élément se trouve entre 16 et 31, on retourne vraie... Pour les autres cas, on retourne False.

Le code est bon, il marche. Mais voilà, Python permet de faire un peu plus court.

Tout d'abord, nous testons des chaines de caractères... non pas que ça me dérange, mais passer par des entiers va permettre d'être un peu plus efficace, et en plus, pour le cas 3, cela évitera un double "int". Mais voilà, on ne va certainemetn pas boucler sur nos élément d'ip... on va utiliser la fonction "map" qui prend en premier argument une fonction, et en second élément une liste.

Cela va faire une chose simple comme tout: appliquer à chaque élément retourné par "split" la fonction "int(...)", donc ip est mainentant une liste d'entier. Voyons le code:

Bien, une petite réduction de code supplémentaire: inutile de faire un "and" sur le 3ième cas, on peut utiliser xrange() pour vérifier si la valeur est dans ce rang. C'est pas plus efficace mais plus lisible:

Voilà nous avons un code plus sympa. Passons à la suite.

Maintenant, on va tester notre fonction, mais en utilisant un lot d'ip:

Oui ça marche... mais je veux avoir la liste des ip locales, avec l'ip contenu dans la liste...:

Voilà le cas exact et très intéressant en Python. Il est en fait inutile de faire une boucle, "filter" permet de travailler plus simplement:

Et voilà, une seule ligne qui remplace la boucle. "localip" est bien une liste d'adresse locales. Alors vous allez me dire "ok, mais pour avoir l'inverse? je dois refaire une fonction, ou encore pire, virer les doublons en mergant les tableaux de..." et ho... stop !

Non, on va utiliser une fonction lambda. Un fonction lambda est une fonction en une ligne, compilée directement dans le code, un peu comme une fonction inline en C. L'intérêt est qu'elle n'entre pas dans le dictionnaire de fonctions de votre code, elle ne va servir qu'au moment où on en a besoin, puis disparaitre. C'est bel et bien le principe de la fonction jetable.

Donc, clairement, pour avoir les fonctions d'adresses publiques, il faut simplement inverser isIPLocal.

Comprennez bien, 'lambda x:" signifie que "x" est l'argument de la fonction lambda. Arpès le ":" apparait la valeur de retour, sans mot clef "return"

Ici, j'inverse avec "not" le retour de la fonction isIPLocal. De ce fait, "privateip" contient que des adresses publiques.

L'intérêt ici, c'est que nous n'aurions pas put utiliser la génération de liste python avec un "[x for x in ... ]" car un test est nécessaire. Tout du moins, cela simplifie le travail.

Vous l'aurez compris, map, filter, lambda sont très intéressants. Voyons enfin "zip" qui va encore agrémenter votre développement d'un niveau.

"zip" permet de prendre deux tableaux (liste) et d'en faire une liste de tuple dont les éléments sont mappés dans l'ordre. Exemple:

Cela va permettre de faire des manipulations très très intéressante en conjonction avec map, filter, et des lambda.

Prenons un exemple que j'ai eut à traiter. Deux tableaux de valeurs entières dont je devais récupérer les valeurs maximales en comparaison entre chaque index. Plus clairement:

Il me faut donc avoir la liste de valeurs telle avec max(val1[x], val2[x])... Donc on pourrait imaginer que je bouclerai sur les tableaux et que je testerai chaque valeur... mais non !

C'est tout !, res vaut bien "[12, 45, 22, 75, 78, 41, 48, 9]".

Oui, on aurait put faire:

En fait, la méthode "map + lambda" est juste un peu plus claire (malgré tout) et surtout plus efficace. Pour faire simple, "map" permet de ne pas trop se casser la tête sur des cas complexe... comme par exemple mapper des fonction stoquée dans un tableau à appliquer à des valeurs...

Ou encore, pour charger des modules en liste:

Voilà, à vous de voir maintenant l'intérêt de ce genre de manipulation. Je vous montrerai ensuite un petit code en python qui sera en plus sujet à un défi: un code decryptage simple à casser. L'idée principale du code est de crypter des données, mais vous remarquerez l'utilisation à foison de map, de lambda, de filters...

Voilà, bon code à vous.

Bon, clairement, on parle d'un site de Apple Addicts, je sais très bien (oui je suis pas si idiot) que les site "pro linux" ont tendances à faire pareil, et idem pour les "pro-MS". Mais là... au fur et à mesure que les pages du site défilaient devant mes yeux, j'ai pris peur... Mais vous allez voir que j'ai quand même été rassuré à la fin. Laissez moi aller jusqu'au bout.

Outre les 50 pages que j'ai dut me taper en ayant des sourires en coin, cette page m'a fait flipper tellement elle démontre à quel point un adorateur de Mac ou Apple plus généralement peut être fourbe dans ses propos: http://www.macgeneration.com/unes/voir/130002/android-et-les-brevets-une-lettre-ouverte-de-google-en-forme-d-ecran-de-fumee

Clairement ici, l'auteur y va à grand coup de délires. Il explique que d'une part Apple a un stock de propriété intellectuelle plus importante que Google (ha bon ? (ironie...)).

Oui... et ? justement... allo ? c'est pile poil le reproche que fait Google à Apple et consort là... le fait d'avoir un pack de brevet où on pourrait presque vous demander des royalties pour aller aux toilettes... Donc défendre la critique en appuyant sur le point noir... heu pas compris.

Bred, je continue. L'auteur dit

"De par la nature même de son cœur de métier, Google n'a pas besoin de brevets — mieux, elle est à l'opposé de ce système. Son grand succès est en effet un algorithme mathématique à la base de son moteur de recherche et de son système de publicité ciblée — un algorithme secret, alors que le brevet est la publication d'une invention."

Heu... rien ne vous choque ?

D'une par, Google n'a jamais dit qu'il a "besoin de brevet", il dit bien clairement qu'il veut que les concurrents arrêtent de brandir ce bout de papier pour empêcher les autres d'avancer dans la concurrence. Ensuite, seconde fourberie de l'auteur, l'algorithme de recherche de Google n'est pas secret...

Puis le fait que le brevet soit une publication d'un invention est un leurre qui cache le fait qu'il sert avant tout à empêcher les autres d'utiliser l'idée.

Pire:

"... faire fabriquer un smartphone, c'est à un moment ou à un autre marcher sur les platebandes intellectuelles de quelqu'un d'autre."

Et donc ? si j'ai envie de manger un Hamburger je vais devoir obligatoirement reverser une partie de mon pognon à MacDonald ? Je pense pas que Quick ou Burger King reverse des droits pour ça... ou alors le monde est pire que je ne le pense...

Et là, le coup de grâce (parmis le reste d'inepsie dont je vous épargne..) est là:

"Google tient la position de la France : elle a une grande gueule mais n'a pas les moyens de ses ambitions, quelques bombes nucléaires mais rien comparé à l'arsenal d'en face et pas le manuel pour les utiliser."

Heu, les ambitions ne demandent pas d'arsenal. Google a le manuel justement, mais on va l'empêcher de l'exploiter pour des questions judiciaires. Rien de technologique là dedans.

Et allons-y pour maintenant critiquer un point de vue débile de l'auteur. Donc si on le suit, le mec qui a le plus de brevets et le dominant du sujet. Or, iPhon, iPad... qui a les brevets ? et bien non, c'est pas Apple, mais Samsung

Samsung qui se voit attaquer par Apple quand il a voulu sortir sa nouvelle galaxy tab pour des question de... brevets...

J'adore, magnifique !

Outre les conneries que j'ai lu, je suis étonné de voir sur cette page une photo de "vieux google phone" pour donner une image bien ridicule de Android... alors que:

• le galaxy S2 a de meilleures capacité techno que iPhone 4
• il se vend plus de Android que de iPhone
• iPhone a bénéficié d'avancés proposé par Android (par exemple pour la notification)

Bref, on voit bien là un article pro apple, sans cracher sur le principe de l'auteur qui sur un site "pro apple" ne va pas écraser son idole, j'avais envie de donner mon point de vue.

Chose qui m'a rassuré, je vous le disais en début de billet, c'est quand j'ai lut les commentaires sur les pages de ce site. Apparement beaucoup de lecteurs ne sont pas dupes et critiquent souvent ce que les auteurs expliquent. Ça me rassure beaucoup.

Bref, j'espère juste que le procès lancé par Google aura un temps soit peu de contenu propre: http://www.01net.com/editorial/536950/concurrence-google-vise-par-neuf-plaintes-a-bruxelles/

Je ne dis pas qu'il faut tout excuser, je ne suis pas d'accord sur l'intrusion possible d'une firme à connaitre tout de ma vie, mais sans Google je pense que beaucoup d'entre nous auraient laissé tomber pas mal de technologies et je pense même qu'on aurait pas mal de retard sur les capacités actuelles du Web.

Pourquoi je me fais avocat du diable... s'il en est un... ? Parce que j'ai fait un bilan de ce que m'a permi de voir Google.

Tout d'abord, les fameux GSOC (Google Summer Of Code) qui permettent à des étudiants doués de bosser 4 mois environ sur un projet libre pour lui apporter des choses nouvelles. Par exemple je m'intéresse ces temps-ci à Blender Tomato, une branche de Blender développé par Sergei qui permet de faire de la reconstruction 3D à partir d'une Vidéo. Jusque là, aucun logiciel libre ne permettaient de le faire correctement, et nous étions donc forcé d'utiliser voodoo cam tracker (franchement pas terrible), pftrack (très cher)...

Ces GSOC donnent donc beaucoup à nous, développeurs et utilisateurs du libre. Mais ce n'est pas tout.

Android, basé sur un noyau Linux, me permet d'avoir enfin un téléphone branché, avec lequel je peux développer des applications sans avoir à me prendre la tête avec un PC spécifique et un langage imbuvable (vous voyez de qui je parle, faites pas les innocents)

Et dernièrement, indirectement, le fait que Adobe commence à se pencher vraiment sur HTML5 en sortant une préversion de Adobe Edge. A la longue, je suis certain qu'il va remplacer Flash...

Pourquoi indirectement ? clairement, depuis que Chrome est sorti, c'est fou le nombre de sites que je vois qui utilisent les capacité de HTML5. Vidéo, audio, 3D (webgl) ou utilisation de canvas... tout cela a vraiment explosé depuis que Google a pris le projet Chromium sous son aile.

Et ne parlons pas de Google+ qui eclatte doucement en s'opposant à Facebook (en ayant certainement un autre type d'utilisateur, mais justement il tape au bon endroit) ou encore VP8 qui est le codec vidéo qui signe doucement l'arrêt de mort de H.264 (sur le Web tout du moins...)

Google a certes beaucoup de choses à se reprocher, tout comme Apple ou MS... mais une chose est certaine, Google au moins présente des outils libre, gratuits pour la plupart, aide le développement du libre, propose du hosting de code... Cela peut un temps soit peu abaisser les critiques fortes et engagées que l'on porte à son égard.

Personnellement, j'ai presque toute ma vie sur Google: un profil Google+, mes vidéos sur Youtube, mes photos sur Picasa, j'utilise beaucoup Chromium, et je suis un vrai adorateur de Google Docs. Quand à mes mails, je les ai sur Gmail (et comme je suis connecté via Evolution, je ne vois pas de pub... je vous rapelle qu'à l'inverse de MS, Google propose un serveur IMAP...) Je n'y vois pour le moment pas de problème, je suis sur Google depuis 2004 et je n'ai pas encore eut de souci... tout ce qui est vu de moi sur Google je l'ai bien voulu... rien de compomettant.

D'ailleurs, petite parenthèse, MS a sorti une vidéo très drôle anti-Gmail.

le GmailMan

Elle est très réussit et vraiment marrante, mais il faut quand même être un peu réaliste: en général, une entreprise ne devrait pas aller sur le site Gmail mais utiliser un client lourd (Evolution, MS Office Outlook...) Donc bon... bref...

Voilà donc selon moi Google est tout de même un acteur utile qui permet à bon nombre d'entre nous d'avoir de nouvelles technos utilisables sans attendre 10 ans que MS daigne les utiliser. C'est mon avis à moi.

Cela fait en fait des mois que j'amuse avec node.js. J'ai beaucoup travaillé sur le coté "parallélisation" et intégration système. Je me suis monté un petit serveur HTTP complètement autonome, qui répond entre 5 et 400 fois plus vite que Apache (je vous montrerai ça quand j'aurais un peu plus avancé sur le projet).

Alors node.js c'est quoi ? c'est un système permettant de faire en Javascript, coté serveur, des applications serveurs. Il se base sur le moteur "V8" de Google (intégré dans Chromimum/Chrome) qui a l'avantage d'être très rapide. Mais vous allez me dire "quel avantage ?" car si c'est juste pour coder dans un autre langage, il n'y a aucun intérêt...

Et bien des avantages, on en trouve plein... je vais vous exposer les plus intéressantes, et surtout les plus impressionnantes. On va commencer par les performances, basiques, du simple calcul... Testons simplement une bonne vieille suite de Fibonacci en PHP, en Python et en Node/JS:

Pour le python:

Pour le PHP:

et enfin en node/js:

Ok, donc on lance les tests:

Non vous ne rêvez pas... 200ms contre 9 secondes avec PHP et 2.8 secondes pour Python.

Je ne suis pas là pour critiquer les performances des langages su-cités, mais pour montrer que Node.js est très rapide, contrairement aux préjugés qui disent que Javascript est lent. Rappelez vous que JS n'est qu'un langage, l'implémentation est la cause des preformances, pas le langage lui même.

Bref, passons au second avantage, et pas des moindres, node.js permet de coder des applications asynchrones, tirant parti du système d'exploitation qui fait tourner le projet. Je vais préciser un peu plus.

En fait, tout est asynchrone dans node.js. Lire un fichier, écrire un résultat, envoyer les données au client... tout ! Cela implique que la programmation sera évènementielle, et non pas purement procédurale. Cela entraine deux choses à bien assimiler quand nous codons sous node.js:

• le code en parallèle peut devenir compliqué si vous ne maitrisez pas les technique asynchrone
• il faut penser à traiter les évènements courants

Par exemple, la lecture d'un fichier se fera de la sorte:

Contrairement à ce que l'on peut croire, "end..." apparaitra avant la lecture effective du fichier... et oui, car le callback est lancé après ouverture du fichier, si il a réussit. Cela peut arriver après un instant de latence, donc le code qui suit l'appel à readFile peut s'exécuter avant le callback.

Et j'en passe... il est possible de lancer une commande unix et d'envoyer en continue le flux de sortie au client:

En se connectant avec un navigateur sur le port 8000 du serveur, on reste en attente de données... chaque fois que vous entrez des données dans le fichier "messages" il apparait dans le navigateur... Et l'intérêt dans tout ça ? Et bien ce système asynchrone peut répondre à des miliers de clients en simultanée.

En effet, node.js est prévu pour répondre à des requêtes en masse. Vous pourrez même travailler en grappe de serveurs, faire du long-polling ou encore travailler sur plusieurs ports...

En gros, node.js est en phase de faire front à pas mal de middleware python ou à Apache/PHP... Je vous conseille de voir un peu la documentation de l'API et de tester un peu les possibilités de ce système.

Et enfin, pour vous donner un peu plus de lumières à l'aptitude de node.js, je vous conseille de l'utiliser pour répondre rapidement à des client réseau "limités", par exemple pour les Iphone et Android (en 3G) ou encore pour des réponses Ajax/Json en long-polling (comme le fait le projet APE).

En ce qui concerne la gestion de site complet, il faudra encore bosser un peu pour avoir des frameworks... même si je suis plutôt porté sur le micro-framework et/ou l'implémentation directe.

Voilà pour la présentation.

Je me suis posé des centaines de questions sur ces projets, notamment depuis les évènements judiciaires portant sur nos données privées. Et à force de suivre les nouvelles, de lire les commentaires ou encore de voir quelles impacts sont provoqués par ces sites... je me demande si nous ne nous trompons pas dans nos jugements.

Oui, vous me voyez venir, me voilà avocat du diable. Mais je pense avec conviction que l'erreur judiciaire est bien là. Je vais vous expliquer ma pensée et peut-être me suivrez vous dans cette optique. Ou alors, peut-être que je conforterai votre opinion. Dans tous les cas, le but n'est pas d'offencer ou de prendre les utilisateurs et détracteurs pour des idiots mais de donner un point de vue contraire, et bien réfléchis aussi, d'un regard qui se porte de l'autre coté de la barrière.

Parlons donc de l'incrimination très poussé de certains "géants" de ces systèmes, j'ai nommé: Marl Zuckerberg, jeune fondateur à la tête de Facebook. Facebook, vous le savez certainement, est un site qui permet à des personnes de constituer un réseau d'amis et de propager des inforamtions plus ou moins pertinantes à l'ensemble de son réseau. Photos, nouvelles, jeux, questions, sondage, ou simple remarques... tout est simple et possible. Ce site permet de tchater, faire de la visio conférence, avoir une boite mail, des groupes sur certains sujets... Finalement, il n'y a rien de mal à utiliser Facebook.

Pourquoi est-il dans le colimateur des détracteurs ? parce que la question des règles de vie de privée est baffouée sur certain points. Or voilà... l'utilisateur est (doit être) conscient du fait qu'il s'expose au monde. Soyons plus précis, si je décide de mettre des affiches dans la rue expliquant que je suis telle personne et que j'ai telle opinion, je suis conscient que les gens vont savoir des choses sur moi. Si je fais cela, je sais pertinament que certain vont mal comprendre, ou peuvent utiliser mon affiche pour se moquer de moi. Donc, comme pour ce blog ou je place pas mal de mes opinions, je sais que je suis soumis au regard des autres et à leur critiques.

C'est donc pour cela que je fais attention, je ne met pas n'importe quoi sur mon blog. Tout comme Google+, twitter ou Facebook.

Alors pourquoi s'attaquer à M.Zuckerberg ? Parce que ce jeune homme est le fondateur. Il aura beau faire ce qu'il peut, toute critique du site, toute utilisation détournée, toute profit que cela engendre est et sera dû à cet homme.

Mettez vous à sa place une minute. Vous avez créé un site qui permet à l'humain de communiquer sans trop de contrainte, puis en quelques années la vanité et la méchanceté de certain détruise le concept sympa pour le rendre néfaste. Et on vous dit "ton site est minable, tu vois un peu ce qu'on peut faire avec ? t'as vu comme notre vie peut être pollué ?"... Est-ce vraiment de la faute de Zuckerberg ? non, clairement non...

M.Zuckerberg est devenu un homme d'affaire, posé sur le grill, il est certes devenu très riche, il n'en reste pas moins humain et doit se défendre contre l'image que nous, les utilisateurs, pouvons transposer de ce que nous faisons du système Facebook.

Google+ est arrivé, et encore une fois c'est M.Zuckerberg qui est pris pour cible pour continuer à attaquer les dérives de Facebook, puisque Google+ est un peu moins "ouvert" à l'utilisation de données personelles par les utilisateurs.

Là où Google fait fort, c'est qu'ils ont éliminé depuis des lustres les cibles potentiels... Je vais être plus précis:

• je vous dis "Apple" vous me répondez : Steve Jobs
• je vous dis "Microsoft" vous me répondez : Bill Gates (pourtant à la retraite) ou Steve Ballmer pour les plus avertis
• je vous dis "Facebook" et vous me répondez: Mark Zuckerberg

Mais les deux systèmes les moins critiqués sont Twitter et Google+... et là personne ne me donne de nom, ou du moins, très peu de gens connaissent les noms des dirrigeant, fondateurs... Pourtant, Larry Page ou Dick Costolo sont bien là, à prendre des décisions pour des gros systèmes qui engendrent beaucoup d'argent.

En fait, je me rend compte que nous sommes simplement en manque de cibles humaines. Tout ce que nous critiquons est pourtant bien une conséquence de l'utilisation des systèmes utilisés, et non pas des fondateurs.

Sitôt qu'un système commence à engendrer beaucoup d'argent et rameute beaucoup d'utilisateurs, il devient alors un système dangereux, imprécis, mal vu par la communauté intellectuelle qui connait très bien les risques encourus... mais ces risques sont exploités par ceux qui les connaissent.

Pour ma part, je me range du coté du pragmatisme désormais. Bien que je n'aime pas Facebook pour des raisons de fonctionnement, je me suis décidé à ranger un peu le sarcasme contre ce genre de système car j'estime que l'homme qui est derrière tout ça n'est pas forcément la cause de tout. Avant tout, celui qui peut fracturer un principe de site communautaire et social reste l'utilisateur lui même.

Mais j'ai tout de même une idée qui trotte dans mon esprit depuis bien longtemps. Je conçois parfaitement que tout à chacun imagine avoir le meilleur système de site social en son pouvoir, mais à l'arrivé on fait tous pareil: on envoit des photo et des news à nos amis.

Le principe est le même pour tout les sites, alors si vraiment tout cela fonctionne de la même manière, du moins en terme de propagation, pourquoi ne pas avoir une spécification commune et l'utiliser là où bon nous semble ? Que j'envois la nouvelles "Je mange un paquet de gateau" sur Twitter, Facebook ou Google+ je le fais de la même manière...

Oui, il existe des "hub" qui permettent de faire cela, mais cela reste marginal ou déporté... Je parle d'un vrai système basé sur OpenID et un format global... car finalement, le net se base sur des normes... pourquoi ne pas en avoir une pour ce qui est aujourd'hui l'un des vecteurs majeur de l'utilisation du net ?

Et pour finir, oui: finalement je comprend bien les problématique de tous les acteurs du grand monde comme le sont Ballmer ou S.Jobs... il est difficile pour eux pour changer de politique quand celle ci est imposé par des années de travail... Je ne vois pas Microsoft développer en libre Windows après 30 ans de travail fermé, ou Apple changer sa politique de matériel et de fermeture de code après tant de travail sur leur système sur ce modèle.

Je ne me bats que contre une seule chose: la libre concurrence. L'affaire qui a opposé Google et Intel contre le consortium Apple, Microsoft, EMC, Ericsson, RIM et Sony me déçoit fortement. Le ponion emprisonne l'utilisateur et la libre concurrence. Des marchés peuvent se perdre non pas parce que la technologie est mauvaise, mais parce qu'elle dérange ceux qui ont une techno moins fiable mais qui a bien plus d'argent.

Bref, entre l'humain et sa politique, j'ai décidé de bien posé la démarquation.

Mootools est un framework très abordable et pensé pour être implémenté à la manière des projets de développement que nous connaissons tous: des setters, des getters, des accesseurs... mais au delà de ce concept existe une notion objet très bien implémenter pour créer des interfaces, des dérivations de classes etc... en bref, le fontionnement de mootools est une merveille pour tout développeur qui veut coder en Javascript proprement.

La dernière mouture permet de ne plus entrer en conflit avec d'autres frameworks. La solution est simple:

C'est la méthode abordée par tous les autres frameworks JS. L'intérêt et que la fonction "$" est mappée dans document.id

Cette dernière version a aussi un mode de compatibilité ascendant et descendant bien conçut, bien mieux que le script de compatibilité qu'on a connu entre la version 1.1 et 1.2. De ce fait, vous allez pouvoir passer à mootools 1.3 sans modifier votre code...

Il existe de nouveau attributs et relais, comme par exemple le click:once ou des pseudos évènements (pause, throttled...) que vous pouvez tester ici http://mootools.net/demos/?demo=Element.Event.Pseudos

A ce propos, une nouvelle page de démo http://mootools.net/demos/ qui est très bien faite, est enfin de retour. On note aussi améliorations en terme de performances... bref tout y est !

Je vous conseille de jetter un oeil dessus: http://www.mootools.net

Le cahier des charges est le suivant:

• une icone simple, juste un drag and drop
• encrypte ou décrypte le fichier selon le type
• mot de passe demandé, écriture sur le bureau

C'est le second point qui m'a posé un petit souci mais je me suis rendu compte qu'on pouvait tricher. D'abord voyons comment on encrypte avec openssl (j'ai choisi un cryptage des3, assez fiable):

Ici, le fichier fichier2 est le fichier encrypté, si je veux le décrupter:

le fichier fichier3 est alors le résultat, c'est à dire le même fichier que fichier1

Pour savoir reconnaitre un fichier crypté, j'ai triché. Comme j'ai utilisé l'option -salt un sel est ajouté. Cela enrichi le fichier à sa première ligne d'un "Salted_" qui apparait... par contre le type de fichier est "data":

Voilà comment je sais si le fichier est encodé par ma méthode. Et bien faisons un script:

Ce script prend un fichier en argument et écrit le fichier résultant dans le bureau. Vous allez le sauver dans $HOME/bin/encrypter.sh et le rendre exécutable:

Reste alors à faire un lanceur dans le bureau, tapez cette commande:

Dans le bureau apparait une icone nommé Encrypter, glisser un fichier (pas un répertoire) sur cette icone, on vous demande un mot de passe pour encrypter le fichier. Dans le bureau apparait alors un fichier suffixé par ".encrypted"

Reglissez ce fichier sur l'icone, on vous demande le mot de passe et si l'opération à marché vous voyez le fichier apparaitre.

Bref, c'est juste un bricolage là, mais c'est intéressant de voir à quel point on peut jouer avec Linux sur ce genre de travail.