Ne pas croire au Père Noël peut nuire gravement à l'innovation.

Il est loin le temps où la France se targuait d'avoir des idées à défaut de posséder du pétrole. Aujourd'hui est venu d'être également à court d'idée ou d'envie d'en avoir.

Prenons l'exemple coquasse du dernier poisson d'Avril de la Poste (en 2013), qui affirmait tester des drones pour acheminer des journaux à domicile. Après une levé de bouclier des syndicats, la Poste avoue rapidement la supercherie. C'était une blague de potache. Ouf!
Sauf que quelques mois plus tard, Amazon annonce fièrement une expérimentation équivalente, mais c'est fois c'est du sérieux. Et oui, la Poste invente le Poisson d'Avril version boomerang, celui qui revient à l'envoyeur pour le ridiculiser. Dans la même catégorie, nous attendons que Renault nous avoue officiellement que leur première voiture électrique (celle livrée sans porte) était un poisson d'Avril, et non un véritable produit destiné à être vendu (cela tombe bien, personne ne l'achète).

Mais pourquoi en France nous poussons notre manque d'innovation jusqu'au bout de la plaisanterie?
L'article de ZD (ci-dessous) imagine que notre tradition est peut-être en cause: elle nous pousserait à être trop raisonnable, trop sage, alors qu'ailleurs, ils n'ont pas peur de croire au Père Noël et de s'enchanter à inventer l'avenir. Et pourtant, nous avons dans le passé, surpassé ces contraintes, avec le Minitel, Airbus, le TGV, et d'autres innovations. A cette époque, nous avons prouvé notre capacité et notre envie d'y croire jusqu'au bout. Depuis un vent de résignation souffle sur notre société: La voiture sans permis, l'ascenseur pour l'espace, le tube sous vide pour traverser les continents, ou même la voiture électrique risque bien de venir d'ailleurs. Mais aurons toujours les moyens d'en profiter?

Pauvre Père Noël.


Article relatant le coquasse de l'affaire
Les pères Noël ne sont plus ce qu'ils étaient

(Recherche internet + copier/coller) est devenu un usage normal pour les développeurs

C'est une réflexion qui m'a choquée.
Il y a plus de 20ans, on apprenait un langage en lisant un livre, en passant beaucoup de temps à apprendre la méthode et la syntaxe. Il fallait plusieurs semaines avant d'oser dire que l'on pratiquait un langage. Pour l'anecdote, mon premier langage fut le basic du ZX80 de Sinclair que j'ai appris sans jamais posséder l'ordinateur, mais en lisant tout simplement le livre associé (qu'un ami m'avait prête), car la commande de mon ZX80 n'est jamais arrivée à cause du succès de ce petit ordinateur destiné au plus grand nombre. Tout cela, c'était avant internet. Aujourd'hui, on apprend un langage en une journée, cela signifie que l'on passe à coté de nombreuses points essentiels: la méthode, la connaissances des insuffisances, les moyens de les contourner, etc..
Moi-même aujourd’hui, j'utilise internet et le copier/coller, même pour les instructions les plus élémentaires, et pour des langages que j'ai pratiqué de longue date (PHP, VBA, C). J'ai tenté de déterminer les raisons pour expliquer ce phénomène. Voici 2 des raisons me poussant à utiliser le copier/coller:
1 - Je ne suis plus un développeur à plein temps, et ma mémoire manque d'entrainement
2- Les documentations (VAB par exemple), ne sont pas agréables, ni pour l'apprentissage (c'est une catastrophe sur ce point), ni pour les développeurs (l’absence en particulier d'un moteur de recherche efficace et comparable à google).

Il faut également ajouter l'esprit "zapping" de nos cerveaux d'aujourd'hui. Le temps va trop vite, les yeux et les cerveaux ne parviennent plus à fixer les informations qui défilent devant nous. Nous sommes drogués à la quantité d'information, et nous de passons plus assez de temps à "digérer" cette quantité. A cela s'ajoute malheureusement une dilution importante des bonnes informations noyées dans un flux de très mauvaises qualités. Il est loin le temps où un livre comme le Kernighan & Ritchie (langage C), était un plaisir de lecture tant par sa clarté que par sa pédagogie donnant envie d'apprendre. Maintenant les outils sont souvent obscurs et mal documentés.

Le constat est terrible: le copier/coller est devenu primordial pour un développeur. Je ne suis même pas certain que la productivité y gagne. En revanche, une certaine paresse et un conformisme certain risquent de s'installer durablement dans nos habitudes de développement.

Excel: solution pour générer un classeur contenant plusieurs fichiers CSV

C'était un petit problème qui a ennuyé la plupart des utilisateurs de base de données :
Comment générer automatiquement un fichier Excel contenant plusieurs CSV (à partie d'une base de données par exemple).
Toutes les bases de données sont capables d'exporter une table vers un classeur Excel en utilisant le format CSV, ce format étant reconnu automatiquement par Excel. En revanche, pas moyen d'exporter plusieurs tables d'une base de données vers un unique classeur Excel, avec un onglet par table. Cette impossibilité est la conséquence (entre autre) du format propriétaire d'Excel. Voici une astuce permettant de "créer" ce fichier Excel.

Voici la marche à suivre (avec Excel 2003):

1. Exportez vos tables vers des fichiers CSV, le tout dans un même répertoire .
2. Ajoutez dans le même répertoire le fichier Excel disponible plus bas.
3. Ouvrez le fichier Excel: le chargement des fichiers CSV se fera automatiquement.

Explication:
Ce fichier Excel est un classeur contenant un seul onglet, lui-même contenant une macro en charge d'importer tous les fichiers CSV présent dans le même répertoire. Cette macro se lance automatiquement, mais uniquement si les fichiers n'ont pas été déjà importés lors d'une précédente ouverture. Par la suite, l'opération peut-être reproduite manuellement en modifiant les paramètres présents dans l'onglet 'utilitaire", comme par exemple le préfixe des fichiers à importer.

Voici la copie d'écran de l'onglet "utilitaire" permettant de reproduire l'opération, autant de fois qu'il vous plaira.

Alors me direz vous, cela ne permet pas réellement de générer automatiquement un fichier Excel incluant plusieurs CSV. En revanche, si vous avez besoin d'envoyer automatiquement ce fichier,  rien de plus simple de créer un Zip contenant tous les CSV en question, en incluant ce fichier Excel. Le destinataire (ou vous même) n'auront plus qu'à dézipper la totalité des fichiers dans un nouveau répertoire, pour permettre d'obtenir le même résultat, au moment de l'ouverture du fichier Excel du répertoire.

Ce fichier Excel est utilisable tel quel, mais est facile à adapter selon votre besoin si vous connaissez un minimum de VBA. Personnellement, j'ai ajouté la suppression des fichiers importés à postériori, un renommage du fichier Excel après le chargement, et la gestion automatique des préfixes et suffixes.

En espérant que ce petit fichier vous sera utile.

Lien:
Fichier Excel (version 2003) pour charger automatiquement les fichiers CSV présent dans le même répertoire.

Excel le problème de l'importation de fichier CSV avec le point virgule comme délimiteur

Voici un des exemples de pseudo bug qui peuvent perdre une bonne demi-journée. Mon but était d'importer un fichier CSV dans un onglet Excel, à l'aide la macro OpenText (méthode associée à Workbooks). Normalement aucun soucis: pour importer un fichier avec comme séparateur le point virgule (";"), il suffit d'écrire cela:

 Workbooks.OpenText _
   Filename:="toto.csv", _
   DataType:=xlDelimited, _
   Semicolon:=True

Et bien non, cela ne marche pas avec mon Excel 2003. J'ai tout essayé: jouer avec tous les paramètres, changer le type de fin de ligne (LF => CR-LF), et autre gris-gris. A chaque fois, l'importation ne se faisait que sur une colonne. Seul le caractère virgule fonctionnait pour délimiter les colonnes. Le pire, c'est que cela fonctionnait parfaitement avec la méthode Open (l'équivalent de la fonction 'Open' du menu) sans arguments particuliers.

En cherchant sur internet, j'ai découvert que l'extention du fichier à importer devait être .txt. En renomant l'extention du fichier de CSV en TXT, tout fonctionne:


Name  "toto.csv" as "toto.txt"
Workbooks.OpenText _
   Filename:="toto.txt", _
   DataType:=xlDelimited, _
   Semicolon:=True

Et pourquoi? J'ai même pas envie de savoir pourquoi. L'informatique est remplie de bizarreries de ce type, parfaitement illogique, mais toujours chronophage. Merci au forum qui ma donnée la solution.

Voici ce qu'il faut retenir:
Si on tente d'importer un fichier avec l’extension .CSV avec la méthode OpenText, le point virgule ne peut pas être utilisé comme délimiteur, seule la virgule simple fonctionne. Dans ce cas, l’extension .TXT est obligatoire.

Bon courage à vous pour le prochain bug de ce genre.

Doc MicroS.
Merci à ce forum

le début de la fin pour Windows?

Microsoft (MS) est-il réellement sur le déclin? Un article pertinent sur zdnet semble le dire (un peu de pub pour rendre à césar...). L'argument central de cet article insiste avec raison sur le changement d'usage, qui correspond à la mort lente de la philosophie du PC, c'est à dire un ordinateur standard logiciellement et matériellement, multi-univers mais complexe à mettre en œuvre pour les amateurs convertis à la simplicité des tablettes et Smartphones. Cet article fait preuve de pertinence, en particulier dans sa description de cette "mort du PC", raison principale selon lui du futur échec de Windows 8.  En revanche, je suis dubitatif sur la conclusion. Car les raisons présentées ne sont que partielles. Il manque, pour expliquer le fiasco annoncé, un florilège d'erreurs liés à l'arrogance de MS qui semble avoir perdu le contact avec ses clients. Voici quelques unes:

• L'esthétique très discutable. Ne sous-estimons pas ce point car Apple est une illustration de l'importance du paraitre.
• Le fait de bruler ses vaisseaux en refusant la compatibilité ascendante pourtant traditionnelle
• Refuser d'écouter ses clients "entreprises" qui ont toujours besoin d'un simple PC bureautique
• Oublier les bases de son succès, celle d'un OS robuste unifiant la fonction serveur et client
• Croire qu'un même OS peut fonctionner unilatéralement sur un smartphone, un serveur, un PC, ou une tablette low cost.

La liste ne s'arrête pas là. Cette succession d'erreurs de stratégie donne l'impression de regarder un bateau ivre. Attention à la chute: Linux commence enfin à conquérir les simples amateurs de PC. Personnellement je me suis converti à Ubuntu à cause de la laideur de Windows 8. Les entreprises sont sur le point de débuter une réflexion sur le sujet. A ce rythme, et si la défiance vis à vis de Windows 8 s'intensifie, Office sera également en danger. Et si MS perd la bataille Office, la bataille Windows 8 sera perdue définitivement.
MS aura-t-il le temps de comprendre ses erreurs et de trouver une solution, comme par exemple reprendre la philosophie d'OS/2 - PM (qu'IBM a conçut). C'est la force de Linux, même si cette approche peut paraitre brouillonne avec la grande fragmentation des distributions. Sur ce point, MS avait une carte à jouer. Dans sa chute, MS risque d'entrainer également les grands constructeurs de PC. L'omniprésence de Windows 8 sur les PC et portable en vente actuellement (Windows 7 est introuvable depuis plusieurs mois), contribue selon moi à la désaffectation des acheteur de PC: quittes à devoir abandonner Windows 7 ou XP, les utilisateurs préfèrent en final Android ou Linux pour leur nouvelle machine. Si MS voulait convaincre les derniers amateurs de PC de migrer vers concurrence, il n'aurait pas mieux fait.

Seul l'avenir le dira, mais pour l'instant MS semble suivre inexorablement les pas de Nokia vers le panthéon des anciennes gloires d'entreprises ayant perdu violemment leur place de numéro un.


Liens:
Article pertinent à l'origine de cette réflexion

Notebook Androïd Dust: à la recherche du menu perdu, l'onglet Développeur

Voici la suite de ma quête pour trouver les clés de cette petite machine.
Actuellement je bute sur le menu "Paramétres" (settings en VO). Ce menu permet de configurer son terminal Androïd. Malheureusement le menu dont j'ai hérité semble avoir été "bridé", car impossible d'y trouver le fameux onglet "Développeur", qui permet entre autre d'activer le mode "USB debug", qui est un moyen permettant d'accéder à des fonctionnalités étendues, et qui est parfois la première étape pour "rooter" son terminal.

La version de mon Androïd : 4.0.3 n'a rien d'extraordinaire (icecream sandwich). J'ai tenté sans succès toutes sortes de manipulations décrites pour les versions suivantes d'Androïd, comme par exemple les 7 pressions sur le n° de build dans l'onglet "A propos de la dispositif" (sic, le traducteur embauché pour la version française est quelque peu chatouilleux sur la détermination du genre dans la langue de Molières). Cela a très bien marché pour mon HTC One SV (mon autre Androïd), mais inopérant sur le Dust. J'ai même tenté cela sur toutes les options du menu "A propos...". J'ai même fini par tomber par hasard sur un "œuf de pâques". J'ai même cru au début que c'était un moyen pour activer un menu caché. Heureusement la recherche d'image de google m'a permis de comprendre la signification de cette image (une "private joke" entre développeurs).
Voici donc le menu qui me manque désespérément. J'ai bien tenté de faire toute sorte de recherche sur la toile, mais la aussi sans succès. Je commence à me poser des questions sur la possibilité de trouver le commencement d'un début de réponse.

A votre bon cœur messieurs/dames. Si jamais vous avez une petite idée, n'hésitez pas, vous ferez une bonne action.




Liens:
Easter eggs Androïd

Une copie d'écran du menu incomplet provenant du notebook DUST :

DUST, Notebook vendu en grande surface < 100€: peut-on le rooter?

 

C'est toujours étonnant de trouver des Notebook pour moins de 100€. C'est tellement intrigant que cela donne envie d'en acheter un rien que pour tester la bête. Mon idée était d'utiliser cette machine pour tester certaines distributions Linux..

 Celle-ci a été achetée dans une grande surface spécialisée dans l'électronique à bas-coût (je ne vous donne pas le lien pour un produit qui aura disparu des rayons aussi vite que sera publié cet article). Il s'agit d'un modèle chinois, muni d'une puce tout en un. Il s'agit donc d'une puce SoC (System on a Chip), principe popularisé par la Raspberry, et qui permet de bénéficier d'un ordinateur ou d'une tablette pour moins de 50$ (voir pandawill ou autre site marchand distribuant une multitude de produit pas cher et exotique). Dans la fiche produit, il est mentionné Cortex A9, ce qui correspond à la famille ARMv7 (famille d'instruction). En réalité, ce processeur Cortex est inclus (AMHA) dans le SoC directement.

.

Voici l'étiquette du constructeur:
Première chose, essayons de décrypter cette étiquette, car la documentation livrée avec est réduite à sa plus simple expression, et en recharchant sur internet, aucune trace de ce modèle (en dehors de très nombreux clone vendu par alibaba par exemple).
Premier élément: P/N: VN10-V8850/4G
Le P/N signifie product (ou part) number), cad l'identifiant du produit selon le constructeur ou le distributeur (ou équivalent). La aussi, aucune trace sur google. A noter que le code barre du magasin est inutile sur ce point. Le but est de déterminer l'origine de cette machine pour déterminer les moyens de rooter cette machine (cad posséder les privilèges root pour par exemple exécuter des commandes interdites). La finalité est de modifier ou bidouiller cette machine et, pourquoi pas, y installer une distribution linux.

En faisant une recherche sur une partie du P/N, je découvre une référence à WonderMedia. Il semblerait après quelques recherches que Wondermedia soit le "fondeur" de cette puce, et qu'il s'agisse d'une puce SoC, c'est à dire une puce réunissant en un seul composant les éléments nécessaires pour faire fonctionner un ordinateur (le microprocesseur, la RAM, la ROM, la carte Graphique et l'équivalent d'une carte mère et du Bios). Cette Puce semble être référencée différement selon les modèles:

   WM8850, VIA8850, V8850 (si j'interprête la référence de mon propre notebook.

La confusion concernant WM et VIA semble être la conséquence d'une approximation : le premier est une filiale (ou un sous-traitant) du deuxième. Et comme VIA est un peu plus connu, la référence VIA peut apparaitre. Ensuite, voici les éléments que l'on observe au moment du boot:

     Androïd OS:    4.0
     Build Number : V1.5.5
     Kernel :       3.0.8

Intéressant, mais insuffisant.

Voici les points bloquants:
1- je ne parvient pas à trouver le nom et la référence exacte de ce produit (ni même son constructeur).
2- je ne trouve pas l'option développeur dans les paramètres Androïd.
En conclusion, je suis toujours aux prémices de ma quête des clés de cette machines. Incroyable qu'aujourd'hui, alors que les machines sont basées sur des OS ouverts (à l'instar d'Androïd) qu'il soit terriblement difficile (voir impossible) de simplement booter sur une disquette (c'est une expression de vieux) pour exécuter l'équivalent d'un 'live CD' sur une clé USB ou une carte SD.

Suite au prochain épisode, en espérant le succès dans ma recherche du Graal. Il me reste quelques quelques pistes à explorer.

"Dans un voyage, l'important n'est la destination, mais le cheminement pour y parvenir"

Quelques liens:
Wonder Media
SoC

(Nouveau lien)
Lien vers un forum qui semble avoir la solution (Merci pour le commentaire)

Inkscape: conversion en format plt impossible suite à une erreur Python

L'informatique réserve toujours des misères cachées dans les usages les plus élémentaires. Ma dernière galère concerne mon plotter chinois (grandeur et décadence des imprimantes à découpe pas cher venant directement de Chine) que je pilote avec Artcut, un logiciel si peu pratique. Lui-même pourrait donner lieu à des dizaines d'articles pour commenter les problèmes qu'il représente. Confronter à ces soucis, j'ai logiquement choisi Inkscape pour concevoir les différentes formes à découper, Artcut n'étant plus utilisé que pour piloter l'imprimante. (A noter qu'Inkscape ne semble pas pouvoir piloter le plotter directement).


Pour importer dans Artcut, j'utilise l'importation de fichier PLT. C'est le seul format qui ne posait pas de soucis. Le PLT est le format de fichier traditionnel pour les plotters. Malheureusement Inkscape plante au moment de sauvegarder le fichier dans le format PLT: j'obtiens systématiquement une erreur Python (mais que fait donc cet animal dans cette galère). J'ai eu beau essayer les mises à jours, rien n'y faisait. La solution est heureusement relativement. Merci au forum qui m'a donné la solution.

Il suffit d'installer sur sa machine le convertisseur qui permet de convertir un SVG (fichier Inkscape) en fichier PLT -plotter). Voici donc la liste des éléments à installer (en plus d'Inkscape):

• - Python 2.6.6  (se limiter à une V2)
• - PIL 1.1.7
• - reportlab 2.5
• - uniconvertor 1.1.4

Je n'ai aucune certitude concernant les n° de versions, moi-même je n'ai pas suivie ces numéros. Ensuite, il vous suffira de lancer uniconvertor pour transformer votre svg en PLT. Le fichier PLT est accepté par Artcut. Comme quoi, il suffit parfois de peu de chose. Je n'ai pas vérifier si les 4 items étaient nécessaires, ou seulement le dernier. Tous ces logiciels semblent être libres et répandus pour la plupart des plateformes.

Je peux enfin découper mes créations réalisées sous Inkscape. C'est pratique pour contourner les limitations d'Artcut comme par exemple l'incapacité à gérer les accents pour les textes. C'est ce genre de détail qui vous font regretter un logiciel venant de Chine.

Liens
Le lien donnant une solution
Pourquoi Inkcape
Quid de Python

Python, succès étonnant d'un langage si peu orthodoxe

Langage populaire.
Ayant pratiqué de nombreux langage (Fortran, clipper, C, VBA, JSP, PHP, et j'en passe) mais sans jamais devenir expert, j'ai pu réaliser une grande variété de programmes pour répondre à toutes sortes de défis. A chaque fois, c'est uniquement pour m'adapter au besoin (exemple un site Web), que j'ai dû apprendre un nouveau langage. C'est en me plongeant dans l'univers du Raspberry (projet d'un ordinateur à 25$), que j'ai tenté d'apprendre Python, car la petite communauté à l'origine de ce projet utilise et popularise avec beaucoup d'énergie ce langage. J'ai donc tenté de sauter le pas, en partant à la découverte de ce langage. Ma première surprise fut de découvrir sa grande popularité dans différents domaines (site Web, batch, logiciel graphique, et même pour le HTML5). Inkscape en particulier utilise Python pour la partie conversion.

Premier pas.

Je tiens en premier lieu à rendre hommage à un livre PDF qui m'a enchanté, me rappelant le bon vieux temps de la micro-informatique, un temps où les livres et documentations étaient superbement écrits et constituaient un plaisir de lecture et de pédagogie. Actuellement pour apprendre un nouveau concept, nous sommes écrasé sous la quantité de document mal écrit et oubliant la dimension pédagogique. C'est donc grâce à l'ouvrage de Gérard Swinnen que j'ai pu débuter mon apprentissage. Heureusement qu'il existe encore aujourd'hui des documents pédagogiques donnant envie d'apprendre. A noter que pour moi la référence reste le Kernighan & Ritchie écrit pour apprendre et faire connaitre le langage C.




Caractéristiques (analyse personnelle).
Je définirais Python comme un langage de programmation orienté ligne de commande. En d'autre terme, un langage permettant la réalisation d’algorithmes complexes en ligne de commande (comparable à un shell unix). Pour caractériser concrètement ce langage, voici quelques particularités:
Le mode console qui permet d'exécuter en mode interactif des lignes codes. Ce mode console me semble-t-il relativement inutile car non persistant (les lignes de codes ne sont pas mémorisées) et rend difficile les interactions complexes.
Une autre caractéristique est son mode exécution en commande en ligne ("python script.py" par exemple), fort pratique.
Ce langage appartient à la très grande famille des langages interprétés.
Mais la caractéristique la plus étonnante (vis à vis de mon parcours de développeur) est la méthode de gestion des blocs logiques. Un bloc logique, comme par exemple un bloc conditionnel du type "If() ...endIf", est déterminé par les indentations de chaque ligne. En d'autre terme c'est le nombre d'espace en début de ligne qui détermine si cette ligne appartient à un bloc logique ou un autre.

Pourquoi je n'aime pas.
Les goûts et les couleurs sont difficiles à expliquer. Pour Python, je vais tenter de donner des exemples de choses qui me dérange et qui me pousse à ne pas investir de temps. Je vais en citer deux :
Le système d'indentation et la syntaxe légère. Il s'agit bel et bien d'impression, car n'ayant pas approfondi mon étude et l'apprentissage de ce langage, je ne puis en prendre toute la mesure. Mais l'avantage du monde d'aujourd'hui, c'est le luxe formidable dont jouit le développeur, avec la possibilité de choisir son langage. Il n'y a pas si longtemps, quand vous vouliez réaliser un certain type de traitement ou utiliser certains équipements, vous étiez contraint d'utiliser un système et nul autre. Heureusement les hackers et autres bénévoles ont développé les moyens de pouvoir choisir. Voici donc deux exemples qui me pousse à ne pas choisir ce langage.

Les blocs délimités par indentation.
C'est le point le plus grave. Ayant passé des centaines d'heure à débugger ou décrypter des programmes, je connais l'importance de la délimitation des blocs logiques décrivant des tests ou des boucles. L'idée de délimiter visuellement par indentation les blocs est intéressante théoriquement, mais dans la pratique c'est un cauchemar pour ceux aimant les choses biens rangées. Le plus grave est l'incapacité de "voir" la différence entre un espace, une tabulation ou les différents caractères exotiques de l’ASCII qui s'apparente à un espace (Je me souviens à ce propos avoir un jour perdu beaucoup de temps à cause du caractère ASCII SUB). Quid d'un mélange (invisible sur un éditeur classique) de tabulation et d'espaces. Les conséquences sont terribles: les algorithmes peuvent devenir erratiques et complexe à décrypter. La goute d'eau est le fait d'avoir étendu ce système de bloc à la notion de fonction. On crée déjà soi-même assez de bug, pas besoin d'en générer encore plus avec son éditeur de texte à cause de cette gestion de blocs logiques.

Syntaxe légère.
Sur ce point je ne suis pas un farouche opposant. Mais il existe la aussi des risques difficiles à évaluer. Voici un petit exemple de suite de Fibonacci, justement présenté dans le livre ci-dessus:

Cet exemple présente le dépouillement de la syntaxe. Cette dernière ligne en particulier :
     a, b, c = b, a+b, c+1
est en fait la contraction élégante de trois affectations.
Malheureusement, cette syntaxe pour un langage interprété destiné au plus grand nombre, pose un grave problème d'interprétation. Ce petit bout de code peut être "traduit" (ou plutôt interprété) de deux manières en algorythmie simplifié.
Interprétation 1: avec des valeurs évoluant au fil des affectations:
cela donnerait cela pour "traduire" la dernière ligne:
  a=b
  b=a+b
  c=c+1
Interprétation 2: avec des valeurs figées juste avant les affectations:
  temp_a= a
  temp_b= b
  temp_c= c
  a= temp_b
  b= temp_a + temp_b
  c= temp_c + 1

Chaque méthode d'"interprétation" donne des séries de trinômes (a,b,c) différentes:
  Trinômes      Trinômes
  Interpr. 1    Interprétation 2
  (1, 1, 1)     (1, 1, 1)
  (1, 2, 2)     (1, 2, 2)
  (2, 4, 3)     (2, 3, 3)
  (4, 8, 4)     (3, 5, 4)
  (8,16, 5)     (5, 8, 5)
  ......
On remarque d'ailleurs que les deux premières lignes sont identiques, ce qui peut impliquer des risques de camouflage de ce bug d’algorithmie, si seules les premières lignes sont testées. Cela montre le danger de type de syntaxe.

Conclusion
Ma première expérience n'étant pas convaincante, je n'utiliserais pas Python pour un certain temps. J'aime encore mieux les rigueurs et les dangers d'un langage C plutôt que de me lancer dans l'investissement d'un langage si peu orthodoxe. Le plus important pour un langage de programmation n'est pas sa facilité de programmation (syntaxique ou autre) mais sa facilité à debugger. Personnellement je passe bien plus de temps à chercher la "petite bête" que d'écrire des lignes de code. Cette gestion des blocs logiques risquerait bien trop de me procurer des sueurs froides lors de mes recherches quotidiennes de la grosse "petite bête".

Liens:
L'excellent livre d'apprentissage de Python de Gérard Swinnen.
Pour alez plus loin sur ce langage.
Raspberry

UTF8, BOM, PHP, un mélange indigeste pour les fichiers à télécharger.

En PHP, il est recommandé d'écrire vos scripts en UTF8 sans BOM. Jusqu'à présent, je n'avais jamais prêté attention à cette recommandation. Pour ceux qui douteraient du bon sens de ce conseil, voici un exemple illustrant l'usage malencontreux de ce fameux tiercé de caractères, parfois placés en début de fichier UTF8.


Voici l'exemple PHP en question, et qui permet le téléchargement d'un fichier XML :


header("Content-Type: text/xml"); 
....
$buffer =file_get_contents('fichier.xml');
echo ($buffer);
exit();

Le but est de pouvoir télécharger coté client un fichier 'fichier.xml', sans en modifier un seul octet. Et pourtant, le fichier téléchargé se trouvait (coté client) augmenté de trois caractères parasites, le tristement fameux BOM. Mais pourquoi donc la fonction echo(), ou la fonction file_get_contents() ajouterait ce BOM parasite. J'ai perdu une bonne heure à éplucher la documentation de ces deux fonctions sans succès. Pour finir, j'ai vérifier le format du script PHP lui-même. Merci d'ailleurs à Notepad++ qui permet en un simple click, de connaitre et de changer le format de ses fichiers: 

Le problème fut résolue en supprimant le BOM. Il semble donc que le moteur PHP interprète ces trois caractères, présents au début du fichier PHP, comme des caractères à afficher. Ces trois caractères se retrouvent ainsi et involontairement dans le flux binaire du fichier à télécharger.

Le BOM (Byte Order Mark) est l'une des plus mauvaises idées imaginées pour résoudre la problématique des multiples charsets. Bonne continuation @vous dans le monde merveilleux de l'encodage des caractères.

Lien vers le wiki BOM

  

Inkscape, un choix évident.

J'ai choisi comme logiciel de référence pour le dessin vectoriel, Inkscape. Pour rentabiliser et capitaliser son apprentissage, il est important de se limiter à un et un seul logiciel. Pour parvenir à maitriser les subtilités d'un tel logiciel, il faut du temps, et ce temps est précieux.
Alors pourquoi Inkscape?
Cela se résume en quelques mots:
- Gratuit (autant éviter de pirater ou de dépenser une fortune pour quelques dessins)
- Ergonomie simple (certain logiciel souffre d'une ergonomie complexe longue à assimiler)
- Logiciel stable (pas de grande révolution à chaque version qui obligerait à se remettre en question)
- Communauté importante (pour progresser et surpasser les écueils c'est important).
- Multi-plateforme (Entre Microsoft qui change tous les deux ans d'OS et la fragmentation de Linux, c'est pas un luxe d'avoir le choix).

Inkscape n'est pas parfait pour autant, mais au moins, le difficile et douloureux temps du choix est révolu. On peut alors en toute quiétude investir du temps et de l'énergie à comprendre et apprendre ce superbe logiciel. Félicitation à toute l'équipe d'Inkscape.

PS: j'ai choisi comme image d'illustration une image présente sur le site officiel, autant pour l'esthétique indéniable que la symbolique de l'immersion. En revanche cette image est peu adapté pour décrire un logiciel vectoriel, puisque que s'agissant d'une image plutôt adapté à un logiciel "bitmap' à l'instar de Gimp. Mais le cœur a ses raisons.... Tout cela pour vous signaler l'importance de bien comprendre les différences d'un logiciel "Bitmap" et vectoriel, avant de vous lancer vous-même dans le grand bain des dessins sous Inkscape.

Lien vers le site d'Inkscape