Carnet de notes

Auteur/autrice : Éric

  • Partage de fichiers en PME

    Comment parta­ger des fichiers au sein d’une PME d’une douzaine de personnes ?

    J’ai mis mes réflexions ci-dessous mais je suis preneur de recom­man­da­tions. J’ai du Mac, du Windows et du Linux, des postes fixes comme des portables (régu­liè­re­ment hors site).

    Un petit NAS

    Point parti­cu­lier : Il est diffi­cile d’ex­clure des vols dans les locaux, donc il faut que la NAS puisse chif­frer le système de fichier et synchro­ni­ser avec un service à distance.

    Je connais les Syno­logy, suivant la gamme on peut imagi­ner un DS213j et un disque unique synchro­nisé en rsync avec un serveur distant. C’est de l’ordre de 270€ mais ça me demande un disque en ligne donc empêche d’y mettre des To.

    On peut aussi imagi­ner un abon­ne­ment crash­plan, ce qui permet­trait de mettre un gros disque sans risquer de perte si jamais il dispa­rait. Pour ça il faut sauter sur le DS413 afin d’avoir les 1Go de mémoire néces­saires. On monte à 600€ plus 50€/an.

    On peut aussi imagi­ner un mini-PC avec un système d’ex­ploi­ta­tion dédié à un usage NAS, mais je n’ai aucun retour d’ex­pé­rience là dessus. Quelqu’un a déjà utilisé FreeNAS ou OpenMe­diaVault ? Au niveau prix, on risque de rester dans la même gamme que précé­dem­ment.

    Le défaut de ces solu­tions c’est qu’on va avoir des fichiers désyn­chro­ni­sés, des conflits parce que chacun édite dans son coin, des retours en arrière de version, etc. Par expé­rience c’est une horreur à gérer.

    Une synchro en ligne directe

    Comme de toutes façons il me faut une synchro en ligne, autant étudier la perti­nence que tout le monde synchro­nise ses fichiers en ligne avec un système type Drop­box. Ça permet d’évi­ter que chacun risque d’avoir une version non à jour sur son poste, ou au contraire que la version modi­fiée ne soit pas copiée sur le serveur central.

    Drop­box est clai­re­ment hors de prix pour le compte entre­prise. On parle de 1800 à 2000 € par an. Pour juste parta­ger des fichiers, ça me fait mal, quand bien même le service est très bon.

    Box.net propose 13€ par utili­sa­teur par mois, donc 2400€ par an pour 15. Ils offrent 1 To, ce qui est confor­table à condi­tion qu’un fichier partagé à 15 utili­sa­teur ne compte pas 15 fois. Ça a l’air plus complet que Drop­box mais pas moins cher.

    Wuala pour entre 10 et 15 personnes on parle de 600 € par an mais pour unique­ment 100 Go. Je ne sais même pas si un fichier partagé compte plusieurs fois.

    SugarSync n’est pas clair sur ses prix, ils parlent de 550$ par an pour 3 utili­sa­teurs et il faut passer par un commer­cial pour plus de 10 personnes. Comme je n’ai en plus aucun retour d’ex­pé­rien­ce…

    HubiC est disqua­li­fié, n’ayant pas de client Linux.

    On me dit d’ajou­ter Google Drive, qui peut effec­ti­ve­ment synchro­ni­ser sur disque des fichiers divers. Un compte pro c’est 50 € par mois, donc 750 € par an pour 15 utili­sa­teurs et 25 Go par utili­sa­teur.

  • Chan­ger de modèle

    « si votre busi­ness est propor­tion­nel au temps que vous y passez, chan­gez de modèle »

    L’objec­tif est simple : Passer plus de temps sur ce qui vous parait impor­tant (famille, amis, passion, aider les autres…) tout en conti­nuant à gagner votre vie, poten­tiel­le­ment mieux, de toutes façons pas moins bien (payer les études au petit, s’of­frir une terrasse pour profi­ter de la vie, finan­cer des voyages pour décou­vrir le monde…).

    Si le busi­ness est propor­tion­nel au temps passé, il est possible d’aug­men­ter un peu les marges mais dans l’en­semble vous êtes coin­cés, il faut choi­sir entre les reve­nus et ce qui est impor­tant pour vous (et si ce qui est impor­tant pour vous ce sont les reve­nus, peut-être devriez-vous y réflé­chir encore un peu).

    Vous pouvez aimer « juste » faire votre métier et votre rôle opéra­tion­nel. Pas de problème, c’est très bien et respec­table. L’idée est de decor­ré­ler l’en­vie et le besoin. Quand vous n’au­rez plus besoin de faire de l’opé­ra­tion­nel supplé­men­taire pour gagner vos reve­nus, vous pour­rez toujours le faire, mais vous n’en dépen­drez plus. Proba­ble­ment que votre acti­vité réelle chan­gera un peu, peut être pour faire plus d’hu­ma­ni­taire, peut être pour faire les chose diffé­rem­ment ou plus serei­ne­ment. Vous le ferez par choix, unique­ment par choix.

    Même si l’équi­libre vous convient actuel­le­ment, qu’en sera-t-il avec l’âge ? s’il vous arrive un acci­dent ? si les besoins finan­ciers augmentent ? si vous vous épui­sez ? Et puis on a beau dire que l’équi­libre nous convient, dans l’en­semble, gagner plus tout en consa­crant plus de temps à ce qui nous semble impor­tant, qui refuse de consi­dé­rer ça comme une bonne idée ?

    Chan­ger de modèle ?

    Chan­ger de modèle c’est créer un fonc­tion­ne­ment qui permette un passage à l’échelle : temps fixe pour déve­lop­per, puis ventes ou clients non limi­tés en nombre par exemple. Pour faire cari­ca­tu­ral c’est la diffé­rence entre un modèle de société de services (vous faîtes payer votre temps passé) et un modèle d’édi­teur (vous faites payer des licences ou des accès à une plate­forme qui est déjà déve­lop­pée). Dans le second cas, si vous réus­sis­sez, vous pouvez au fur et à mesure vous déga­ger de l’opé­ra­tion­nel tout en main­te­nant voire en augmen­tant les reve­nus.

    Poussé au maxi­mum ça veut bien dire finir par embau­cher des gens pour faire l’opé­ra­tion­nel obli­ga­toire ou pour produire le service qui sera ensuite vendu en modèle d’édi­teur, mais il ne s’agit pas, comme certains ont inter­prété, d’em­bau­cher des indiens peu chers et d’em­po­cher la diffé­rence.

    Je parle d’un éditeur  peut être éditeur d’un logi­ciel ou d’un service, si possible en abon­ne­ment et pas en licence payée une fois. Ce peut être auteur d’un livre, d’une musique ou d’une vidéo. C’est appli­cable partout mais bien plus réaliste dans les métiers infor­ma­tique et encore plus dans le domaine du web. Une très bonne auto­ma­ti­sa­tion peut suffire à rentrer dans un modèle SAAS. Il s’agit juste de passer un temps fixe dans le stade opéra­tion­nel pour ensuite avoir une rému­né­ra­tion variable et non limi­tée.

    Pous­ser la logique à un niveau plus macro, ce peut effec­ti­ve­ment aussi être créer une entre­prise, et s’en déga­ger au fur et à mesure en tirant le béné­fice de l’ac­ti­vité entre­pre­na­riale qu’est la créa­tion elle-même ; mais ce n’est pas le passage obligé, loin de là.

    Mais euh…

    Oui, tout ça est simple à dire, mais si vous vous placez à votre compte, si vous créez une acti­vité, c’est peut être la première chose à penser. Voulez-vous être, à terme, dépen­dant de votre temps passé ? Quel risque et quel inves­tis­se­ment êtes-vous prêts à mettre pour que ce ne soit plus le cas ? Quel modèle mettez-vous en oeuvre ? Avant même de parler renta­bi­lité, pensez mise à l’échelle.

    Bien entendu, si vous vous sentez très bien en sala­rié avec les avan­tages de stabi­lité et de moindre respon­sa­bi­lité que cela implique, ça va très bien aussi : pas de juge­ment de valeur, c’est juste que je m’adresse à ceux qui veulent tenter l’aven­ture.

  • Hyper­me­dia, quelques recherches pour JSON

    Je regarde un peu les implé­men­ta­tions hyper­me­dia pour une API. J’avoue que je pleure un peu. Qu’on soit clairs, JSON n’est pas adapté pour ça, sauf à construire des messages bien complexes à lire et à produire (ce qui tue un peu l’uti­lité de JSON). Main­te­nant si on veut garder JSON, voilà l’état de mes reflexions :

    — Ce billet est en évolu­tion constante, dernière mise à jour le 18 juin 2013 au matin —

    Déjà quelques specs liées :

    Et deux discus­sions à lire en amont (avec les commen­taires, pour les deux) :

    JSON API

    • Spec assez simple
    • Utilise URI Template
    • Réserve un terme trop géné­rique (links) pour les clefs de la racine JSON
    • Ne permet pas d’uti­li­ser des URI pour les types de rela­tion
    • Ne permet pas d’avoir plusieurs liens (de format diffé­rent par exemple) pour une même rela­tion
    • Le type de ressource ciblée par une rela­tion peut être spéci­fié (ce qui me parait super­flu : si on connait le sens de la rela­tion, on connait le type ciblé)
    • Impose JSON-PATCH

    HAL – Hyper­text Appli­ca­tion Language

    • Rendu assez moche (oui, c’est subjec­tif mais ça compte)
    • Gère des espaces de noms via Curie dans les liens et rela­tions
    • Utilise (option­nel­le­ment) les URI Template (mais ne précise pas où trou­ver les para­mètres)
    • Permet de préci­ser un profile pour quali­fier les attri­buts d’un objet (mais pas de mixer plusieurs voca­bu­laires)
    • Ne permet pas d’avoir plusieurs liens (de format diffé­rent par exemple) pour une même rela­tion
    • Beau­coup de biblio­thèques de code dans pas mal de langages, côté client et côté serveur
    • J’échoue complè­te­ment à sépa­rer ce une collec­tion ou un attri­but complexe et une ressource embarquée, donc à comprendre l’uti­lité de la clef _embed­ded
    • C’est en draft IETF

    JSON-LD

    • Semble être fait par des gens avec un esprit assez proche de RDF
    • Simple à lire, mais trop complète, trop complexe, risque d’être diffi­cile à implé­men­ter
    • Gère un des voca­bu­laire avec des URI pour quali­fier les liens, les clefs, etc. avec même des possi­bi­li­tés d’alias
    • Consi­dé­rant les indi­rec­tions possibles, trou­ver le lien avec une valeur spéci­fique de « rel » est une tâche assez complexe
    • Ne gère pas de template pour les liens, mais sait gérer les liens rela­tifs à une base décla­rée plus haut (ce qui compense un peu)
    • C’est en voie de stan­dar­di­sa­tion au W3C
    • On peut ajou­ter Hydra par dessus pour décrire les actions (petite présen­ta­tion)
    • Peu d’im­plé­men­ta­tions clientes (trouvé une PHP et un conver­tis­seur vers RDF en Ruby)

    Siren

    • Va plus loin que les autres, en décri­vant aussi les types d’ac­tions possibles sur la ressources décrite, les para­mètres pour les diffé­rentes actions, etc. (illu­sion de pouvoir coder un navi­ga­teur d’API géné­rique ?)
    • Pas de template pour les liens
    • Simple à comprendre et à relire (si on met de côté la partie « actions »)
    • Impose une enve­loppe, les clefs à la racine sont liées à Siren, pas à l’objet décrit
    • Pourquoi ici encore sépa­rer les enti­tés liées des proprié­tés ?

    Collec­tion/JSON

    Quand on pense avoir saturé, on se rend compte que ce n’est pas fini. J’ai donc trouvé Collec­tion+JSON après les autres. Il permet de défi­nit des gaba­rit d’at­tri­buts pour les ressources, ajoute les liens et les rôles des liens, la notion de collec­tion, et défi­nit les méca­nismes d’ajout/recherche.

    C’est fina­le­ment une de celes qui se concentrent le mieux sur la tâche fixée au départ, mais je ne suis pas certain d’être convaincu. Au moins on a évité la sur-ingé­nie­rie. C’est implé­men­table de bout en bout.

    Quelques pré-conclu­sions

    Certaines spéci­fi­ca­tions vont bien trop loin à mon goût, et pas toujours en sachant faire correc­te­ment la base (éviter les conflits de nommage, pouvoir utili­ser des URI pour le voca­bu­laire, voire des espaces de noms).

    Rien que les templates d’URI sont fina­le­ment inutiles. Ils permettent de grap­piller quelques octets en évitant de taper des liens complets, mais imposent de rédi­ger un code non négli­geable rien que pour recons­truire le lien final, et empêchent de copier un sous-objet en le consi­dé­rant comme auto­nome (il ne l’est pas, le template pour son URL est dans l’objet parent).

    Alors parler de décrire les actions et les inter­ac­tions possibles avec chaque objet… En voulant trop en faire on reporte beau­coup de complexité sur le client. On est parfois en train de faire des clients très complexes pour éviter de gérer des infor­ma­tions simples et qu’on va proba­ble­ment de toutes façons coder en dur quelque part. Ça en devient contre-produc­tif. De ce côté j’ap­pré­cie la peti­tesse de JSON-API.

    J’ai encore l’avis qu’i­ma­gi­ner un client HATEOAS complet et géné­rique est illu­soire. J’ai juste besoin d’at­ta­cher quelques méta­don­nées comme des liens, des rôles aux liens, et éven­tuel­le­ment un voca­bu­laire pour les types de données.

    Et puis, sérieu­se­ment, si c’est pour que le résul­tat ne soit plus éditable agréa­ble­ment et présente des struc­tures non natu­relles, quel est l’in­té­rêt d’être passé à JSON ?

    XML, ou même HTML avec des micro­data/formats est défi­ni­ti­ve­ment plus adapté que JSON pour ce que je cherche à faire. À JSON il manque au moins un moyen d’at­ta­cher des méta­don­nées à une clef/valeur (par exemple la notion d’at­tri­but sur les nœuds XML/HTML). Avec ça nous pour­rions faire un joli format, sans ça ça restera bien moche et peu pratique.

    Le problème c’est que déve­lop­per un client qui fouille des données HTML avec une struc­ture lâche à base de micro­data/formats, c’est aussi assez complexe à gérer. Reste le XML « à la main » mais si si je veux que mon API soit utili­sée, je crains que JSON ne soit le seul choix prag­ma­tique.

    Entre les diffé­rentes spéci­fi­ca­tions

    Mon cœur balance entre JSON-API pour sa simpli­cité (mais réser­ver le terme « links » me semble juste une aber­ra­tion), HAL parce qu’il semble de loin (mais ce « _embed­ded » me gêne toujours, et faire un « _links »: { « self »: { « href »: « xxxxxx » } } juste pour donner le lien du sous-objet courant me inuti­le­ment lourd), et JSON-LD parce que ça ressemble assez fort à la façon dont je pense et que ça semble permettre tout ce que je peux imagi­ner d’in­tel­li­gent (mais implé­men­ter la spec complè­te­ment risque d’être fran­che­ment diffi­cile).

    Dans une précé­dente version de ce billet j’ai tenté un subset de JSON-LD où n’im­porte quel objet peut conte­nir :

    • un attri­but (facul­ta­tif) @id, qui est le lien iden­ti­fiant l’objet
    • un attri­but (facul­ta­tif) @type, qui défi­nit l’URL du type de l’objet (par exemple un type de schema.org) et poten­tiel­le­ment le sens des sous-clefs ou sous-liens.
    • un sous-objet (facul­ta­tif) @con­text, qui contient les diffé­rents préfixes et adresses utili­sables pour les diffé­rentes clefs de l’objet (afin de pouvoir mixer plusieurs voca­bu­laires sans risquer de conflits de noms et de sens).
    • un sous-objet (facul­ta­tif) @rel, inexis­tant dans JSON-LD, qui pointe les diffé­rents objets liés par leur rôle (attri­but « rel » habi­tuel) pour les retrou­ver faci­le­ment (il y a trop d’in­di­rec­tions pour ça dans JSON-LD)

    Mais je n’aime pas réin­ven­ter la roue, et aussi moche soit-il, HAL contient peut être le prin­ci­pal. Entre une spéci­fi­ca­tion géniale mais trop complexe et sans implé­men­ta­tion cliente, et une spéci­fi­ca­tion plus simple, moche mais bour­rée d’im­plé­men­ta­tions, j’ai du mal à ne pas recom­man­der la seconde. J’ai quand même toujours un peu de mal à voir comment me servir utile­ment du _embed­ded.

  • Lumi­no­sité et gris sur liseuses e-ink

    Ayant entendu un peu de tout, je me suis pris à compa­rer les gris des écrans e-ink sur quelques liseuses. Le test à partir d’une photo shoo­tée rapi­de­ment n’est pas quelque chose de très fiable, mais ça permet de déga­ger une tendance de base.

    J’ai fait un grand shoot avec dix modèles, avec et sans éclai­rage (mais tous éteints), avant de conver­tir en noir&blanc et récu­pé­rer les valeurs de lumi­no­sité. Tel quel, les écarts entre la lumi­no­sité du gris/blanc de chaque appa­reil étaient infé­rieurs aux erreurs de mesure. Seul un appa­reil no-name était clai­re­ment sur une autre tech­no­lo­gie avec un gris plus sombre.

    Je vais tenter de faire une photo dans des condi­tions mieux contrô­lées et avec un appa­reil de meilleure qualité, mais j’ai tendance à dire que si ce n’était pas évident à partir d’une photo, ça ne le sera proba­ble­ment pas à l’usage. Tout ça est d’au­tant plus vrai qu’une diffé­rence peut sauter aux yeux en confron­tant deux couleurs côte à côte, sans qu’on soit capable de dire à laquelle on a à faire quand on en n’a qu’une seule en main. Quand même sur infor­ma­tique ce n’est pas visi­ble…

    Je vous propose tout de même une photo avec quatre appa­reils connus (Bookeen Odys­sey, Pocket­book Touch, Kobo Touch, Sony PRS-T2) dans une qualité correcte. Pas parfait, pas suffi­sant pour tirer une conclu­sion pour l’ins­tant, mais pas probant non plus pour affir­mer qu’il y a un quel­conque écart.

    À noter que je n’ai pas non plus été capable de déga­ger une diffé­rence signi­fi­ca­tive de lumi­no­sité du gris entre les liseuses sans éclai­rage et les liseuses avec éclai­rage éteint, et ça c’est plutôt une bonne nouvelle (je n’ai cepen­dant pas testé la Kindle Paperw­hite).

    liseuses4Commen­taires bien­ve­nus pour établir une procé­dure de mesure fiable.

  • Éton­nant l’es­pion­nage, vrai­ment ?

    Ces jours ci on apprend que la NSA aurait un accès sur les données de Google, Apple, Yahoo, Micro­soft, Face­book et d’autres via un projet nommé PRISM.

    Je trouve très hypo­crite tous ces gens qui se disent éton­nés et d’un coup scan­da­li­sés.

    Qui n’a pas entendu parler d’Eche­lon ? Même Jean-Pierre Pernot a du en parler à l’époque. Quel infor­ma­ti­cien un peu âgé et travaillant dans les réseaux n’a pas entendu parler de Carni­vore ? Quel geek n’a pas entendu parler de la pièce 614A utili­sée par la NSA au milieu de AT&T ? Quel infor­ma­ti­cien de plus de 30 ans n’a pas entendu parler de la polé­mique sur la clef NSA dans Micro­soft Windows ?

    Que les USA fouillent dans les commu­ni­ca­tions en ligne, ce n’est même plus un sujet. D’ailleurs les autres pays non plus. On peut parler du Great Fire­wall of China, mais aussi de Amesys en Libye, la Suède, la Suisse, et bien entendu la France. En fait quasi­ment tous les pays espionnent les commu­ni­ca­tions en ligne à leur niveau. Notre pays est même à la pointe sur ce genre d’outils d’in­ter­cep­tion à l’échelle de pays entiers.

    L’in­ter­cep­tion des lignes télé­pho­niques est main­te­nant presque un outil du passé. Qui croit vrai­ment que les États n’ont pas fait évoluer leurs outils ? Aujourd’­hui les polices et agences de rensei­gne­ment ont très offi­ciel­le­ment des batte­ries de virus et autres enre­gis­treurs de frappe. Il y a même des lois pour cadrer tout ça (au moins aux USA, en France et en Alle­magne, mais proba­ble­ment aussi partout ailleurs).

    Bref, oui c’est grave, oui il faut lutter, mais faire semblant de décou­vrir que les données privées sont proba­ble­ment inter­cep­tées, c’est juste hypo­crite. La seule chose qui change aujourd’­hui c’est que nous avons un nom et des éléments pour poser des ques­tions formelles.

  • À quoi ça sert

    Quand vous aurez tous vos conte­nus sur Amazon, toute votre commu­ni­ca­tion sur Google et toutes vos rela­tions sur Face­book, et que deux ans après l’un des trois ou les trois vous dit « vous signez ici ou vous aban­don­nez tout ce que vous avez », il sera un peu tard.

    Ce scéna­rio n’est même plus de la prédic­tion, c’est le présent et ça a déjà commencé. Le billet précé­dent sur la messa­ge­rie instan­ta­née n’est qu’une anec­dote, mais qui fait partie d’un mouve­ment de fond bien puis­sant.

    Ce qui m’agace le plus c’est que les gens laissent faire, et même semblent ne pas s’en préoc­cu­per.

    Parfois j’ai presque envie de lais­ser tomber le web à tel point je me dis « c’est foutu les gens s’en moquent ».

    J’ai l’air bien beau à résis­ter en contrô­lant mes adresses et mes iden­ti­fiants avec mon nom de domaine, voire mes services sur mon serveur perso. C’est utile pour moi mais ce n’est acces­sible qu’à une mino­rité. Mener le combat seul ne sert à rien : Si vous vous êtes tous vendus, alors pour conti­nuer à vivre en rela­tion avec vous je n’ai d’autre choix que de faire de pareil.

    Seuls nous n’avons quasi­ment aucune chance de propo­ser une alter­na­tive, pour­tant c’est juste essen­tiel pour nous, notre avenir, et celui de nos enfants. Si ça vous parait encore être une « grande phrase », c’est que vous ne réali­sez pas encore ce qui se joue aujourd’­hui.

  • Messa­ge­rie instan­ta­née et jardins fermés

    Je suis très pessi­miste sur les évolu­tions récentes dans la messa­ge­rie instan­ta­née.

    Le mieux

    Pendant un temps ça s’est un peu amélioré. Les non-tech­ni­ciens ne le voyaient pas mais on a commencé à ouvrir un peu les réseaux. Le proto­cole ouvert et stan­dar­disé XMPP s’est plus ou moins imposé comme base, et Jabber (le réseau des serveurs XMPP ouverts) commençait à prendre pas mal d’im­por­tance.

    Apple iChat, Google et même MSN savaient désor­mais plus ou moins commu­niquer entre eux via ce proto­cole, éven­tuel­le­ment avec quelques arti­fices. Chacun pouvait aussi monter son propre sous-réseau chez lui ou dans son entre­prise, avec sa propre adresse, et commu­niquer avec les gros réseaux de façon trans­pa­rente. Même Skype avait annoncé déve­lop­per un connec­teur pour la partie texte de sa messa­ge­rie. AIM avait de plus commencé à s’ou­vrir au réseau de Google, ce qui était un premier pas.

    Mais ce n’est pas tout : AIM, ICQ, Yahoo! Face­book et bien d’autres ont migré vers ce même proto­cole.Même si leurs réseaux restent isolés les uns des autres, il était possible d’uti­li­ser le même proto­cole et donc d’avoir des appli­ca­tions qui faisaient tout. C’était encore loin d’être idéal, parfois les fonc­tion­na­li­tés avan­cées des diffé­rents réseau n’étaient pas gérées, et pour certains l’im­plé­men­ta­tion était expé­ri­men­tale ou en déve­lop­pe­ment, mais la direc­tion était plus qu’en­cou­ra­geante. Même twit­ter avait une inter­face avec le proto­cole XMPP pour certains flux.

    Les appli­ca­tions Pidgin et Adium permet­taient ce qui manquait encore, en implé­men­tant tous les proto­coles prin­ci­paux. Sous réserve d’avoir un compte sur chaque réseau il était possible de centra­li­ser toute la messa­ge­rie sur une seule appli­ca­tion et de ne pas se préoc­cu­per de savoir qui est sur quel réseau (ou même qu’il existe diffé­rents réseaux).

    Il n’y a presque que Skype qui restait dans son coin mais, au moins dans nos pays, il était quasi­ment exclu­si­ve­ment utilisé pour la voix, pas pour la messa­ge­rie instan­ta­née.

    Et le moins bien

    Malheu­reu­se­ment le « je veux mon réseau social comme Face­book » semble être à la mode et on a tout détri­coté tout juste quelques mois.

    Twit­ter ? Ils ont fermé leur inter­face XMPP, et les évolu­tions montrent qu’ils tentent de contrô­ler les diffé­rentes appli­ca­tions clientes. Le nombre maxi­mum d’uti­li­sa­teurs par appli­ca­tion non-offi­cielles fait qu’il est illu­soir d’ima­gi­ner une compa­ti­bi­lité stable et pérenne avec des appli­ca­tions de messa­ge­rie instan­ta­née.

    MSN ? Ils ont racheté Skype et a annoncé migrer ses utili­sa­teurs de Windows Live vers ce réseau. Le réseau MSN fonc­tionne encore alors que sa date d’ex­tinc­tion est désor­mais passée, mais rien ne permet de dire si ça perdu­rera encore long­temps.

    Le proto­cole Skype n’est malheu­reu­se­ment pas ouvert et ce ne semble pas être la direc­tion souhai­tée en interne. Il est probable qu’il faille désor­mais commu­niquer avec les contacts MSN via Skype et unique­ment Skype.

    Il existe encore un plugin Skype pour Pidgin mais il impose d’avoir le client Skype lancé et connecté, ne couvre pas le mobile, et semble ne pas fonc­tion­ner correc­te­ment pour les utili­sa­teurs qui ont fusionné leur compte Skype et leur compte MSN.

    Google ? Google vient d’an­non­cer le passage à Hangout. Ils avaient déjà éteint un bref moment les échanges entre leurs serveurs de messa­ge­rie et les serveurs tiers, rompant l’in­te­ro­pé­ra­bi­lité. Désor­mais c’est tout le proto­cole XMPP qui est jeté. Impos­sible de commu­niquer avec des utili­sa­teurs non Google une fois que vous avez migré, pas même avec les utili­sa­teurs du réseau AIM qui avaient une liai­son spéci­fique. Impos­sible aussi d’uti­li­ser un client autre que les clients Google.

    L’an­cien réseau XMPP de Google est encore là mais on ne sait pas pour combien de temps. Toujours est-il que les utili­sa­teurs vont migrer vers Hangout au fur et à mesure (consciem­ment ou non) et ce sont autant de gens qui devien­dront injoi­gnables pour ceux qui n’y sont pas encore. Pire : Il semble qu’ils sont encore vus comme connec­tés, mais ne peuvent pas lire vos messages ou vous en envoyer.

    Là aussi, le proto­cole n’est pas connu, donc il faudra avoir un logi­ciel spéci­fique pour Hangout, impos­sible d’uti­li­ser Pidgin ou un équi­valent.

    Sans avenir

    Twit­ter, MSN et Google s’en­ferment chacun dans leur pré : impos­sible de commu­niquer avec eux depuis l’ex­té­rieur, ou d’avoir une même appli­ca­tion qui se connecte aux diffé­rents réseaux. Diffi­cile de comp­ter sur Face­book pour s’ou­vrir, et les autres qui étaient au stade de déve­lop­pe­ment ou d’ex­pé­ri­men­ta­tion ne risquent pas d’in­ves­tir pour péren­ni­ser la chose désor­mais.

    Bref : Vous appar­te­nez au réseau que vous choi­sis­sez, et vous n’êtes qu’un pion dans la guerre qui oppose les multi­na­tio­nales d’In­ter­net. Le courant domi­nant est main­te­nant de fermer les fron­tières et de capi­ta­li­ser sur les utili­sa­teurs pieds et poings liés, c’est à dire vous. Votre proprié­taire pourra vous impo­ser les conte­nus, les services ou la publi­cité qu’il souhaite (rassu­rez-vous, il atten­dra un peu que ça se calme avant de le faire, histoire de ne pas risquer une migra­tion en masse). Une société souhaite lancer des conte­nus ou inno­ver ? OK si elle paye votre proprié­taire et n’entre pas en concur­rence avec lui. Moins vous pour­rez commu­niquer avec l’ex­té­rieur, mieux ce sera car vous serez sous contrôle de votre proprié­taire de réseau.

    Sauf renver­se­ment de situa­tion ou prise de conscience excep­tion­nelle des utili­sa­teurs :

    • Jabber est mort à court ou moyen terme, sauf pour quelques geeks et inter­nautes convain­cus
    • Vous ne pour­rez plus choi­sir vos appli­ca­tions, il faudra accep­ter les appli­ca­tions offi­cielles, en leur donnant les droits qu’elles demandent, en accep­tant publi­ci­tés, mises en avant ou marke­ting qu’elles choi­sissent
    • Si vous n’ac­cep­tez pas de vous lais­ser enfer­mer et menot­ter sur un seul réseau, il faudra instal­ler et lancer simul­ta­né­ment plusieurs logi­ciels diffé­rents non inter­opé­rables
    • Le web ouvert est mal barré

     

  • ‘TEA’ recrute un déve­lop­peur ou une déve­lop­peuse

    Vous pouvez envi­sa­ger de faire de l’exé­cu­tion et de l’ex­ploi­ta­tion dans une SSII. Vous pouvez aussi voir une grande entre­prise en espé­rant poser un logo connu sur votre CV pour votre carrière toute tracée. D’autres l’ont fait, nous aussi, on fait tous des erreurs.

    Sinon vous pouvez aussi venir dans une société à taille humaine, qui travaille sur ses propres solu­tions, avec de grands projets et une équipe tech­nique sympa, le tout sur le domaine atti­rant des livres numé­riques et du mobile.

    Toujours est-il que je recrute un déve­lop­peur ou une déve­lop­peuse pour complé­ter l’équipe. Critères prin­ci­paux : Motivé(e), Curieux(se), Envie de bien faire, Approche posi­tif(ve), Exigent(e). Le reste, y compris le détail du projet, des missions et des compé­tences en jeu, se trouve sur la page dédiée.

  • Ateliers sur la docu­men­ta­tion webperf

    J’ai partagé en ligne il y a quelques temps le début de livre que j’avais rédigé à propos de la perfor­mance des sites web.

    L’objec­tif était d’avoir une « bible » qui réfé­rence toutes les tech­niques impac­tant le temps de char­ge­ment des sites web et la théo­rie sous-jacente. Une moitié du travail était déjà là. C’est sur github, dans un format acces­sible à tous.

    En le posant sur github l’es­prit est « ce contenu appar­tient à ceux qui se l’ap­pro­prient ». Si vous y parti­ci­pez, ça devient un peu le vôtre. De mon côté ce n’est déjà plus « mon livre » mais un projet commu­nau­taire, dont je ne souhaite d’ailleurs pas forcé­ment être le main­te­neur ou l’ani­ma­teur.

    Pour initier la dyna­mique néces­saire, nous avons réalisé deux ateliers : un à Paris fin avril, un dans le cadre de Sudweb la semaine dernière. Il s’agit d’ex­pliquer le projet, puis de réali­ser relec­tures, mises à jour et rédac­tion par petits groupes. Le projet avance un peu, et chacun repart avec une meilleure connais­sance ou des échanges sur un sujet pointu.

    Si vous ne savez pas par où commen­cer vous pouvez commen­cer par regar­der les tickets en cours (« issues » dans la barre de menu github). Ils sont clas­sés par chapitre et par type d’ac­tion (relec­ture, mise à jour, contenu manquant, etc.). Le fichier « HELP.md » à la racine du projet contient aussi un guide de démar­rage avec quoi et comment sur diffé­rentes ques­tions que vous pour­riez vous poser. Vous pouvez aussi simple­ment vous signa­ler et poser vos ques­tions sur la liste de diffu­sion française : https://groups.google.com/group/perfor­mance-web?hl=fr

    La suite c’est de conti­nuer avec les ateliers. Il faut prévoir un anima­teur et proba­ble­ment au moins une personne qui a déjà lu le contenu et saura répondre aux ques­tions tech­niques webperf. Je compte en propo­ser quelques uns mais n’hé­si­tez pas à en orga­ni­ser vous-même dans vos commu­nau­tés locales. Avec un peu de temps se déga­ge­ront certai­ne­ment une ou deux personnes pour animer tout cela sur le long terme.

    Retour sur les deux ateliers précé­dents

    Sur les ateliers passés il y a eu un bon travail sur les relec­tures, qui s’est traduit via quelques correc­tions, quelques ajouts, mais aussi une bonne série de tickets qui permettent main­te­nant de struc­tu­rer et guider les bonnes volon­tés.

    Un gros merci à tous ceux qui ont parti­cipé.

    Deux points soule­vés :

    • En plus de la demie-heure de présen­ta­tion du projet et du fonc­tion­ne­ment, il faut prévoir des créneaux d’au moins une bonne heure, préfé­ra­ble­ment une heure et demie. En dessous on manque de temps pour amener un résul­tat concret.
    • La licence initiale était inuti­le­ment complexe de façon à garder la possi­bi­lité d’em­barquer un éditeur papier dans l’aven­ture. Suite aux diffé­rents retours, il appa­rait plus sage de rebas­cu­ler sur une licence ouverte plus simple, peut être une Crea­tive Commons. N’hé­si­tez pas à en discu­ter ici ou sur la liste de diffu­sion webperf

    Voilà, main­te­nant c’est à vous de jouer.

  • Embauche : les patrons de PME ne cherchent pas des Bac+5

    Les hauts diplô­més à BAC+5 sont plus souvent en situa­tion précaire qu’on ne le pense. C’est navrant quand on regarde le manque de personnes pour certains postes niveau CAP.

    Et voilà qu’on déclare

    L’offre de travail doit mieux s’adap­ter aux entre­prises ; une réforme est urgente pour favo­ri­ser des forma­tions courtes et adap­tées à la demande sur le marché du travail

    Sérieu­se­ment, il faut vrai­ment qu’on soit malade en France pour imagi­ner un truc pareil. On doit être le seul pays dans l’his­toire à penser qu’il faut réduire le niveau d’édu­ca­tion. Pire, le seul à penser que ça amélio­rera l’em­ploi.

    Que les gens soient instruits n’a jamais été un problème, ou ne devrait pas l’être, sauf à vouloir créer une société de classes avec une élite instruite et un peuple qui ne doit pas penser trop loin pour éviter de faire des vagues.

    Pourquoi un diplômé d’école de commerce serait-il fonda­men­ta­le­ment moins bon qu’un BEP pour vendre en maga­sin ? Pourquoi un master en psycho­lo­gie ne pour­rait pas garder des enfants à domi­cile ? Je ne dis pas que c’est néces­saire, mais ce n’est en rien disqua­li­fiant.

    Des études pous­sées c’est une chance, pour mieux travailler, mais aussi mieux comprendre le monde qui nous entoure, amélio­rer les pratiques… Même une forma­tion longue en sciences humaines peut être béné­fique à la commu­nauté pour un poste de tour­neur/frai­seur.

    Le gros défaut c’est au contraire qu’on entraine tout le monde à penser via ce système de classe avec ceux qui « pensent » d’un côté, géné­ra­le­ment à partir BAC+4, et ceux qui « font » de l’autre. Si tu appar­tiens à la première caté­go­rie, tu ne dois jamais t’abais­ser à accep­ter un emploi dans la seconde, et si tu t’y astreins alors on pensera que tu y seras inef­fi­cace (et peut être à raison telle­ment on t’a entrai­ner à délais­ser tout ce qui peut ressem­bler au « faire »).

    Et si au lieu d’es­pé­rer dimi­nuer le niveau d’édu­ca­tion — je n’en reviens toujours pas — on tablait plutôt sur un chan­ge­ment de valeurs et d’état d’es­prit pour que les gens aient envie de « faire », et arrê­ter de se sentir « trop bien » pour ça ?