Category Archives: Réflexions

L’idée serait-elle supérieure à sa réalisation ?

Le rangement des archives de numerunique a sorti de l’ombre un document qui invite à la réflexion. C’est ni plus ni moins que le manuel de référence du premier serveur web de l’histoire !

Il date de mai 1994 ; il a donc tout juste plus de 24 ans. A l’époque c’était simplement un document de travail, à la pointe de la technologie. Aujourd’hui, à l’échelle de temps de l’informatique, il tient davantage du fossile préhistorique que du manuel de référence. Il est numérisé et partagé ici : httpd1994.

Un détail attire l’attention : il a été écrit par Ari Luotonen et Tim Berners-Lee.

Une recherche rapide sur Internet révèle que ce serait Ari, alors étudiant au CERN, qui aurait réalisé cet élément crucial de l’idée de Tim à qui est pourtant universellement (et à juste titre) attribué l’invention du Word Wild Web.

Ari, comme la plupart de ceux qui ont contribué à la concrétisation de l’idée de Tim, a complètement disparu de l’histoire. Pour celle-ci c’est donc incontestablement l’idée qui prime sur sa réalisation.

Pourtant, avoir une idée c’est très facile mais la réaliser beaucoup moins ! Et une idée “en l’air” c’est juste rien. C’est sa réalisation qui lui donne tout son intérêt.

Chez numerunique, des idées il y en a plein et l’on sait pour le vivre les difficultés auxquelles on se heurte à vouloir les concrétiser. Mais là, peut importe si l’on retient l’inventeur ou les réalisateurs : c’est le même.

La spirale infernale des mises à jour

C’est désormais bien entré dans les mœurs : les matériels, systèmes et logiciels doivent être régulièrement mis à jour. Au point qu’il est fréquent d’entendre que tel ou tel logiciel ne vaut plus rien puisqu’il n’est plus mis à jour ! Ce genre de principe érigé en dogme est le plus souvent colporté par ceux qui cherchent désespérément à palier leur incompétence par des règles faciles à comprendre.

Le problème avec les mises à jour est qu’elles sont la plupart du temps (mais pas toujours) inutiles voire préjudiciables : certaines apportent davantage de bugs ou de failles de sécurité qu’elles n’en corrigent.

Le plus pénible avec les mises à jour de système d’exploitation est qu’elle impliquent en général la nécessité d’un changement d’ordinateur. Le plus horripilant est d’avoir à redécouvrir le nouvel accès à une commande, un service ou une fonctionnalité par ailleurs identique ou même dégradée…

Et si un programme qui n’est plus mis à jour était tout simplement arrivé à maturité ?

C’est encore pire pour les équipements.

Acheté il y a 2526 jours à la date ce cette photo, ce téléphone (un HTC desire 2010) suppliait d’être remplacé.
HTCdesire

Aujourd’hui on a un choix incroyablement riche pour un téléphone :

  1. Android
  2. iOS

Dans le premier cas, on confie toutes ses données personnelles à google, dans le second à Apple. Et en plus, on paye (cher) pour le faire, c’est quand même génial tout ça.

En l’occurrence, c’est le choix 2 qui a été fait. Il en résulte un problème intéressant pour un informaticien : transférer 419 contacts d’un téléphone Android vers un iPhone.

Pour pimenter un peu la chose, on veut éviter de passer par iCloud. A priori il n’y a rien d’ultra secret dans ces contacts mais c’est une question de principe, alors si c’est une question de principe…

L’extraction des contacts depuis un Android de 2010 est simple, en quelques touch on a un .vcf standard sur la carte SD que l’on peut même récupérer par Bluetooth.

L’import sur l’iPhone se présente moins bien : le modèle choisi n’est pas “résistant aux éclaboussures et à l’eau” mais il est parfaitement étanche à toute forme d’échanges de données, quel qu’elles soient, sauf à passer par iCloud ou iTunes, bien sûr.

Va pour iTunes, officiellement cela reste local. D’ailleurs, il faut même utiliser une connexion par câble pour une synchronisation avec iTunes. Les fonctionnalité Bluetooth supportées entre un Mac et un iPhone sont très économes… seule une connexion réseau est possible. Quelle valeur ajoutée !

Hélas, le MacBook air du propriétaire du vieux HTC et du nouvel iPhone réclame une mise à jour d’iTune en préalable à toute tentative de synchronisation. iTune étant à jour, il faudrait commencer par faire une mise à jour du MacOS. L’opération est risquée, le MacBook air en question est d’une autre époque (i.e. vieux de quelques années).

Alors on passe par un autre mac plus récent, sur lequel on crée un compte temporaire. Il faut quand même y faire une mise à jour d’iTunes. Et là ? On découvre que la synchronisation des contacts ne peut se faire désormais que par iCloud :-((

Moralité, lorsqu’on change de téléphone, il faut aussi changer d’ordinateur. Ils devraient proposer un lot.

Heureusement, il y a un moyen de contourner le blocage : un simple mail (d’une messagerie étrangère à Apple ou google) avec le .vcf en pièce jointe et hop, on récupère ces 419 contacts sur l’iPhone, sans passer par iCloud, comme promis.

PS : c’est impressionnant comme la touche i s’use plus vite lorsqu’on parle de Mac.

Why frameworks suck?

ol1

OPEN LOOK, once it was a must, now it’s but a mug – a nice and dear one though.

ol2

This is just an example of a wonderful framework: in 1990, it allowed building homogeneous UX for applications on top-of-the-moment desktop workstations.

As all really powerful frameworks, it required a long and tedious learning time – often with a steep initial learning curve – but with a beautiful result. The problem is that all the knowledge acquired to master it is now lost and this is the fate that doom all frameworks, thousands of framework since 1990.

The core of the problem is that frameworks provide high-level functionalities that don’t last more than the underlying fashion. As a programmer, one should look after learning how to build complex tools with low-level instructions: that will last forever.

Of course it is worst to reinvent the wheel; except for very special cases, nowadays nothing useful can be achieved with machine language. Using a higher-level language – whatever – is better. And while working within a team, frameworks provide a strong common context.

So yes, frameworks are useful somehow. But then use them scarcely, staying aware that you will soon need to forget all about them and learn the next one.

Beside, there is another drawback to the use of frameworks: they constrain what you can do with them. If your specifications is close to what a framework is meant for, you will probably benefit of its use. If not, then the challenge to adapt the framework to your need is so expensive that you end in adapting your specification to what the framework allows.

Framework are definitely incompatible with specific developments.

Le forfait est un forfait pour les prestations informatiques

Forfait :

  • contrat dans lequel un prix global est fixé à l’avance,
  • crime atroce.

Ceux qui ont eu une enfance malheureuse (condamnés à aller au ski tous les ans) ont sans doute découvert la notion de “forfait” comme une libération : le passage immédiat et illimité au remonte-pente comme alternative aux multiples tickets à prélever laborieusement dans le stock fastidieux d’un ruban de papier perforé plié en accordéon. Avec les moufles, c’était encore pire et sans c’était glacial. En plus dans ce contexte, le prix des tickets était tellement onéreux que le calcul était vite fait : quelques tours de pistes avaient vite fait de “rentabiliser” le forfait.

A l’opposé, l’avènement du téléphone portable a donné un nouveau sens au “forfait” : on paye un prix fixe obligatoire pour une durée de communications limitée. Si on consomme moins  : tant pis, c’est perdu, si on consomme plus : tant pis, on paye un prix encore plus exorbitant pour chaque minute supplémentaire dès la première seconde…

En réalité dans les deux cas, l’usage est borné : le forfait de ski ayant une validité limitée qui implique un nombre nécessairement limité d’utilisation des remonte-pentes. De plus le très grand nombre de skieurs et leurs niveaux très différents entraîne une compensation des usages intensifs (et peu rentables pour la société des remonte-pentes) par les usages faibles (et très rentables) des skieurs débutants. Sur un gros volume, on s’y retrouve forcément.

Dans un tout autre contexte, poser du carrelage par exemple,  le coté répétitif et prévisible du travail à accomplir permet de vendre avec une bonne marge de bénéfice la prestation au forfait d’après des mesures simples à faire : la surface à couvrir en l’occurrence. Certes, les bords d’une pièce ne sont pas toujours d’équerre et la surface à couvrir n’est jamais un multiple précis de celle de chaque carreau, sans compter les inévitables petits imprévus tels que les quelques carreaux qui cassent lorsqu’on les coupe. Mais globalement, le carreleur s’y retrouve avec un prix de revient maîtrisé.

Et le client est content car il sait sur quel montant il s’engage et il peut comparer les devis des prestataires plus facilement.

Le contexte des prestations informatiques est bien moins favorable, d’autant plus lorsqu’il s’agit d’obtenir un résultat original et dans un contexte novateur, sans parler des objectifs  flous ou revus au fur et à mesure de l’avancement du projet.

En informatique, la seule façon fiable de savoir combien de temps il faudra pour atteindre un objectif est de le réaliser. C’est aussi souvent la seule façon de définir précisément l’objectif…

Pourtant, aucun client ne veux s’engager sur un chèque en blanc. On les comprend. D’où l’inévitable conjecture du devis où l’on essaye désespérément d’imaginer la charge précise pour un résultat vaguement défini.

La marge de manœuvre est faible : trop cher et le client préfère la concurrence, trop optimiste et le prestataire travaille à perte. C’est le plus souvent la deuxième solution qui prévaut. Ce qui entraîne se nombreux dépôts de bilans et autant de clients abandonnés par leur prestataire et contraints d’en trouver un autre, avec des frais supplémentaires et un effet amplificateur : un travail fait à la hâte est souvent plus simple à refaire totalement qu’à reprendre.

Pour l’EURL Barme cette problématique est résolue selon deux approches.

Pour les projets modestes, le travail est fait d’emblée et un devis a posteriori est proposé au client. S’il le refuse, la perte est limitée et ne compromet donc pas l’avenir de la société. Si le client accepte le devis a posteriori, il fait une bonne affaire puisqu’il ne finance aucune marge de sécurité et paye le juste prix.

Pour les projets plus importants, les aléas du devis se compensent : les parties sous-estimées sont financées par celles qui sont surestimées. On retrouve en fait le principe du gros volume évoqué plus haut.

Et les meilleurs clients, les plus fidèles, ceux qui savent que la satisfaction des clients est prioritaire par rapport à la rentabilité à court terme, acceptent les prestations facturées au temps passé, celles qui permettent à la fois de gagner beaucoup de temps et d’atteindre le meilleur rapport qualité / prix.

Encore mieux que le SaaS

On ne présente plus le SaaS (Software as a Service). Le aaS est devenu aussi tendance que le oo (orienté objet) des années 90. D’ailleurs cela fait bientôt 8 ans que l’EURL Barme est entrée dans le SaaS, avant même que le concept soit nommé ainsi.

Mais pas question de se reposer ; on a trouvé encore mieux, le RESTful (representational state transfer)!

SaaS_RESTTout en conservant tous les avantages du SaaS, l’API REST permet de déléguer juste les droits nécessaires pour mandater une application un service proposé par un tiers pour réaliser des actions sur des informations par ailleurs privées (et confidentielles).

Dans l’exemple illustré par la figure ci-dessus, c’est l’EURL Barme qui fournit un service permettant à un utilisateur d’automatiser des actions sur son compte chez OVH sans donner à l’EURL Barme le contrôle sur ses produits chez OVH.

Le mieux pour le comprendre est de l’essayer sur un cas concret : https://barme.fr/services/ABL/

Ce service permet de se protéger contre les appels téléphoniques importuns en seulement 2 clics :

  1. un premier clic pour récupérer le numéro de la plateforme d’appel qui vient de vous appeler,
  2. un deuxième clic pour ne plus recevoir d’appel de cette plateforme.

En plus cela rend service à tout le monde :

  • l’utilisateur ne reçoit plus d’appel importun,
  • le “conseiller” ne se fait plus jeter comme un malpropre,
  • la plateforme d’appel évite de perdre son temps à appeler une personne réfractaire.

C’est beaucoup mieux comme cela.

Charge et décharge

Ceux qui ont eu l’occasion d’avoir à surveiller la charge et la décharge de batteries lorsque leur vie en dépendait savent qu’il y a 2 valeurs importantes :

  • la tension (en Volt) durant l’utilisation de la batterie (décharge),
  • l’intensité (en Ampère) durant la recharge.

En pratique, la tension est le bon indicateur de charge de la batterie. Elle décroit lentement au début puis de plus en plus rapidement lorsqu’on approche de l’épuisement. Il faut prendre garde à ce qu’elle ne descende pas en dessous d’un certain seuil.

Et l’intensité est un bon indicateur de la charge. Très importante au début, elle décroit de plus en plus pour tendre vers 0 lorsque la batterie est presque totalement chargée. En dessous d’un certain seuil, ce n’est plus la peine d’attendre plus longtemps pour un gain de charge insignifiant.

A l’époque où presque tout se charge par des prises USB, on trouve donc une pléthore d’appareils qui mesurent et affichent ces deux informations et plus encore.

Le choix est vaste !

USBVA

C’est l’occasion d’en comparer 3 modèles :

Modèle Prix Délai V A W mAh Total mAh Durée Plus
Drok  15.19 € 4
Keweisi  10.99 € 6
Carchet  3.61 € 14

Ils ont tous été commandés en même temps ; le délai est le nombre de jours entre la commande et la réception. Oui, c’est amusant, le délai est inversement proportionnel au prix.

Le premier modèle est celui qui est le moins lisible, avec une diode bleue mal placée qui éblouit plus qu’elle n’éclaire. Un bouton permet de faire défiler les informations, une à la fois. C’est aussi le plus complet, le seul à donner la puissance instantanée (inutile) et la durée depuis le début de la charge, à la seconde près (superflue). Il permet en plus de couper automatiquement la charge lorsque l’intensité est devenue inférieure à un seuil paramétrable, ce qui présente un gain de sécurité important pour éviter une surcharge dangereuse.

Le deuxième modèle est le plus lisible ; tout est affiché simultanément. Tout est utile. Il mémorise la charge totale, même débranché, jusqu’à ce qu’on appui sur un bouton pour la remettre à zéro.

Le troisième modèle a un affichage trop lumineux qui alterne entre V et A. La valeur affichée est asses instable. C’est pratique pour surveiller l’alimentation instantanée d’un Raspberry Pi.

Tous ces appareils ont une précision non vérifiée et consomment eux aussi de l’énergie…

On apprend rapidement quelques informations intéressantes en utilisant ce type d’appareil pour surveiller l’efficacité objective d’une alimentation par une prise USB :

  1.  un câble supplémentaire utilisé comme rallonge consomme une partie non négligeable de la puissance disponible,
  2. les prises USB des alimentations directement branchées sur le secteur sont les plus stables en tension et ampérage et sont nettement plus puissantes que les prises USB des ordinateurs,
  3. la charge absorbée par une batterie complètement rechargée après avoir été complètement déchargée est nettement inférieure à sa capacité annoncée. Le phénomène s’accentue au fil du temps.

Et pour un geek, c’est très branché.

What is better than open source?

No one will contest that open source has become the de facto standard in successful new IT stuffs. But who cares to read the code that is given in git depositories? So what is better than open source? A concise documentation, definitely! Actually, a small example of code is even better. It is worth 1000 pages of documentation – and 106 man pages.

TL;DR

A few weeks ago, OVH gave a very interesting goody to the attendees of its Summit: a small beacon connected to SigFox, an emerging network for the Internet of Things. It looks intensely promising. It gives access to temperature and movement detection every 10 minutes anywhere under the coverage of the network, without any external energy supply and for an unlimited lapse of time compared to similar beacons depending on GSM network.

goodyAlong with the goody, a new special account is offered on RunAbove labs.

Great! Another gift!

RunaboveIoTWait. There ends all excitement: just two pair of key/password, one obviously for reading and another for writing. How one is supposed to read or write anything on the goody is mysteriously hinted by a link to the IoT tutorials.

IoTTutorialsFour articles wait deciphering. Let’s start the quest of reading whatever data is recorded by the goody through the one titled How to get data from the RunAbove IoT metrics storage.

ReadIoTApart from incomplete excerpts of code, another link is proposed to the complete documentation of the underlying standard: the official OpenTSDB documentation.

apiAlas, this last link gives access to a complete reference, an ideal source of inspiration for knowledgeable users but still frustrating for early beginners.

Hopefully, RunAbove Labs has an access to its community. On its online interface, a search of the keyword goody allows to spot a single contribution.

ComunitySearchHurray, there is the list of the metrics, the keyword to access the goody’s data. This is the kind of precious arbitrary knowledge that defies intelligence.

CommunityHelpThere is also an example of 84 lines of PHP code that suggests you are first supposed to catch the data sent by the goody by setting a callback, write it to the OVH’s Internet of Things account before reading it… In this example, different metrics are used: confusing. But those lines of code eventually give another clue for retrieving the goody’s data.

Eventually, its summaries in:

curl -u hereisyourkey:anditscorrespondingpassword \ 
   -XPOST https://opentsdb.iot.runabove.io/api/query \ 
   -d '{ 
     "start":1443052800, 
     "queries":[ 
       { 
       "metric": "ovh.goody.temperature", 
       "aggregator":"avg" 
       } 
     ] 
   }'

If only I had that at the beginning, I would have saved hours of useless guesses and your time for reading this post.

Quel langage utilisez-vous ?

P4123008Cette question, posée à un développeur, comporte plus d’un problème. A commencer par le faux sens induit par le terme langage.

Evidement, on imagine bien un développeur donner ses directives à un ordinateur de la même manière que l’on demande au barman de remplir à nouveau son verre : au moyen d’un langage. A Paris, ce serait quelque chose du genre : “un de plus !“.

Dans un langage informatique évolué, en C par exemple, en admettant que le nombre de verres soit mémorisé par une variable identifiée par la lettre c, ce serait l’instruction c++; (remarquez comme cet exemple est  limpide et ne prête pas à confusion).

Seulement voilà, l’ordinateur ne traite en réalité qu’avec deux niveaux électrique : 0 et 5V (ou moins mais quand même différent de 0) que l’on traduit, en binaire, par 0 ou 1. Converti en assembleur, par exemple pour le microprocesseur Z80, en admettant que le nombre de verre soit inférieur à 255 et mémorisé à l’emplacement de la mémoire identifié par l’adresse notée 3301h (en hexadécimal), notre exemple “un de plus !” devient quelque chose du genre :

LD A,(3301)
ADD A,01
LD (3301),A

Et pour finir, en langage machine cela devient  :
00111010 00000001 00110011 11000110 00000001 00110010 00000001 00110011

Il faut bien reconnaître que c’est nettement moins clair. Imaginez ce que cela donne pour une application un peu plu complexe que “un de plus !“…

Une langue qui n’est pas parlée s’appelle une langue morte mais on peut néanmoins s’y exercer par des versions ou des thèmes. Que dire alors d’une langue qui n’est même pas parlée et avec laquelle on ne peut faire que des thèmes ?

Parler de langage informatique est donc un abus de langage. En réalité, il faut parler de jeu d’instructions ; c’est beaucoup mieux et en plus, avec jeu, c’est nettement plus ludique. Les informaticiens sont des joueurs, c’est bien connu.

Le travail d’un développeur consiste à traduire une action plus ou moins complexe en une série d’instructions élémentaires. Elémentaire au sens où chaque instruction correspond à une action toute simple. Exécutées méthodiquement et très rapidement par un ordinateur, on obtiendra avec cette série d’instructions élémentaires le résultat voulu, avec les bugs en plus.

Le deuxième problème avec la question “Quel langage utilisez-vous ?” est le singulier pour langage. Il manque un s. Hé oui, de nos jours, un seul jeu d’instruction ne suffit plus. Développer demande la maîtrise combinée de plusieurs jeux d’instructions. Et par une chance qui n’a rien à envier au hasard, le pluriel de jeu s’écrit avec un x.

Sinon, pour ce qui concerne la réponse à la question “Quel langage utilisez-vous ?” la meilleure réponse pour l’EURL Barme serait : le htmlcssjavascriptphpsqlapachelinux.

Mise en œuvre de la base de données économique et sociale

A lire le décret d’application n° 2013-1305 du 27 décembre 2013 relatif à la base de données économiques et sociales (BDES ou plus simplement BDU pour base de données unique), on jurerait qu’il a été rédigé par un informaticien ! Les dispositions qu’il expose :

  • ne résolvent en rien les complexités administratives et humaines liées au partage des informations concernées par ce décret,
  • laissent une très grande liberté aux solutions techniques pour sa mise en œuvre,
  • ouvrent un immense potentiel de traitement de ces informations.

Et quelles informations ! Il s’agit ni plus ni moins que de tous les indicateurs économiques et sociaux, passés, présents et futurs d’une société…

Il a deux facteurs qui donnent un contexte extrêmement favorable à la réalisation de ce décret. La base de données économique et sociale apportera certainement une réelle plus value à ses utilisateurs et le contexte technique actuel, d’un point de vue informatique, offre un cadre idéal à sa mise en œuvre.

L’obligation de mettre à disposition les éléments d’analyse ou d’explication mentionnée dans le décret indique que les données numériques brutes ne seront pas suffisantes. Le recours à un ensemble de documents s’impose donc naturellement, au moins dans un premier temps.

La première solution qui émerge alors est l’adaptation, plus ou moins hâtive, d’un GED (système de gestion électronique de documents). Cette solution trouvera vite ses limites. Il y a d’autres fonctionnalités à satisfaire que celles proposées par ses systèmes, par exemple la gestion des délais qui courent à compter de la communication des informations.

La solution technique à la mise en œuvre de la base de données unique justifie le développement d’un outil ad hoc, simple et utile.

Cependant, les besoins seront communs à toutes les entreprises. Ces développements pourront être ainsi mutualisés ; ce qui permettra de réduire les coûts de mise en œuvre de manière très conséquente.

Faire simple est plus compliqué qu’il n’y paraît

Le titre de cet article illustre le contraire de son propos : l’apologie de la simplicité. Ca commence bien !

La tendance naturelle est d’ajouter de la complexité superflue. Cette propension est d’autant plus importante que les capacités sont limitées. De magnifiques exemples se trouvent dans le monde de la recherche où quelques médiocres se donnent de l’importance par le recours à un argot qu’ils sont les seuls à connaître ; ils en déduisent que leur travail est de très haut niveau puisque personne ne les comprend… A l’inverse, les vrais sommités du même contexte vous présentent leurs résultats avec une telle limpidité que l’on s’étonne que le problème soit resté sans solution pendant des siècles !

Revenons à un monde plus quotidien. En informatique l’intérêt de la simplicité est tout autre. Cela en est la raison même : rendre la vie plus facile aux utilisateurs de ce merveilleux outils aux potentiels infinis. Dans ce domaine la simplicité apparente est très souvent inversement proportionnelle à la complexité cachée. Bien sûr il faut parfois mettre en œuvre des algorithmes très complexes pour simplifier les tâches les plus fastidieuses au point de les rendre ludiques. Mais la simplicité, en informatique, c’est d’abord une philosophie. Il ne faut rien ajouter à la complexité inhérente des problèmes abordés.

Cela commence par la liste des fonctionnalités proposées. Combien de commandes, cachées profondément dans les menus, sous-menus, sous-sous-menus, de votre traitement de texte préféré utilisez-vous ? Hum ? Du coup celles qui vous intéressent sont noyées parmi les superflues. Faut-il en dire plus ?

Aller à l’essentiel, éviter le moindre clic, même si cela demande des semaines de travail, proposer des solutions simples et utiles, voilà l’objectif.