Septembre 2009

Intro : J'ai décidément du mal à tenir ce blog à jour... Pourtant, il y a bien des sujets dont je souhaiterais parler ici ; mais entre les articles demandant trop d'investissement en temps et ceux qui seraient trop courts, au final, je ne publie pas. Donc j'ai décidé de me lancer dans une série mensuelle, listant rapidement des petites choses intéressantes, tout domaine confondu (enfin, surtout ceux habituellement traités ici...). En espérant donner un petit coup de fouet à ce blog qui refuse de mourir.

Logiciels :

Découvert au taf, Launchy est un petit lanceur d'application bien sympathique, disponible sous Windows et Linux. Très pratique (et libre).

M'étant mis tout récemment à la musique assistée par ordinateur (voir plus bas), je vous conseille Audacity (libre et multi-plateforme) que je découvre pour tout ce qui est enregistrement et montage audio. J'avoue que j'ai toujours eu peur des logiciels de MAO à cause de la complexité de certaines références (genre Cubase), mais là ça se présente de manière plutôt simple, même s'il faut creuser un peu pour certaines fonctionalités.

Enfin, j'ai récemment commencé à utiliser Eclipse au travail... Contre toute attente, je sens que ce soft va me réconcilier avec les IDE : bien que lourd, il fait un nombre de tâches hallucinant et facilite vraiment la vie du développeur sur pas mal de points assez peu intéressants (conventions syntaxiques, intégration du gestionnaire de configuration, génération automatique de méthode, commentaires, détection d'erreurs en live, etc...). J'ai sans doute l'air de découvrir la roue, mais bon... quand ça tourne bien, faut pas bouder son plaisir.


Musique

Certains le savent, d'autres non. Je suis un gros fan de Blues, et je joue depuis "presque" un an de l'harmonica diatonique (blues harp donc). Comme je l'avais déjà dit ici, je pense que ce sujet est un peu loin des thématiques habituelles de ce blog, et donc j'en parle chez Lefty.
Notamment ce mois-ci : un article sur une compilation de Blues très bien foutue pour ceux qui veulent découvrir, et un premier essai d'enregistrement avec Lefty à la gratte (d'où l'utilisation d'Audacity).


Pro

Suite à la fin de ma mission précédente, j'ai enchainé cet été sur un nouveau truc en... Java. Et plus précisément en Java3D.
Ce nouveau job me plait beaucoup, en bonne partie parce que j'apprends énormément de choses nouvelles, et que l'environnement est assez différent de mes expériences précédentes.
D'abord le domaine de la géométrie algorithmique (que je connaissais déjà dans un contexte de calcul scientifique/modélisation mathématique) qui est bigrement intéressant. Pour l'occasion, je me suis d'ailleurs (enfin) payé le Computational Geometry (de Berg - Cheong - van Kreveld - Overmars) que je ne saurais que trop conseiller à ceux qui s'intéressent à ces problématiques (attention cependant, il n'existe pas de traduction).
Ensuite, l'environnement très libre/open source : même si c'est en bonne partie des outils classiques de développement en Java, c'est toujours agréable de bosser avec des choses comme Eclipse (voir plus haut), Ant, TestNG, SVN, TRAC, plein de bibliothèques libres, etc... (plutôt que Visual Toto, des scripts batch halakon, des outils de test et des libs internes foireux, Clearcase et Rhapsody...). Ah oui, et un wiki pour la doc : si c'est pas cool ça...
Bon, et le Java, c'est pas si terrible.


IoGraphViz := Io + GraphViz

Comme je voulais depuis longtemps m'investir dans un vrai projet libre, et qu'en parallèle je voulais me pencher plus sérieusement sur le langage Io, je me suis lancé dans le projet IoGraphViz.
Il s'agit d'un binding, pour le langage Io, de l'outil de génération de graphes GraphViz. Il n'est pas encore stable/mature, mais j'espère sortir assez rapidement une première version fonctionelle. Pour l'instant je me base fortement sur l'équivalent en Ruby : RubyGraphViz, mais je compte diverger de plus en plus de ce (très bon) point de départ.
Ce qui est intéressant en se lançant dans ce genre de projet, c'est que ça implique de nombreuses contraintes qui sont assez formatrices :

• Mieux maitriser le(s) langage(s) utilisé(s) bien sûr
• Héberger son projet/maitriser un gestionnaire de configuration et/ou de version (dans mon cas, je me suis mis à Git via Github - sous Windows, c'est pas de la tarte au début mais on s'en sort...)
  
• Et surtout rechercher toutes ces petites choses auxquelles on ne pense pas : de la doc sur des points ultra pointus, un générateur de documentation, tests unitaires, etc...

Je compte faire un vrai article d'introduction (in English if you please...) à la lib quand elle sera présentable.


Curiosités du web

International Dialects of English Archive propose des petits fichiers audio à l'écoute illustrant les accents (en anglais) de gens des quatre coins du monde. Amusant et pratique pour bosser son oreille.

Journée Mondiale présente une liste (non exhaustive mais impressionante) des journées mondiales/internationales/européennes/nationales de... tout et n'importe quoi (genre là on est entre la Journée Européenne des Langues et la Journée Mondiale de la Surdité... touss touss).

Buzzerl : un reddit pas bien, fait par des gens biens, utilisé par des gens biens et des gens pas biens (en Erlang).

Fin de projet SCADE

La fin d'une mission, ou d'un projet, c'est toujours une bonne occasion de faire le point. Je viens de terminer tout récemment une mission de quelques mois en tant que développeur logiciel, en SCADE, pour un système embarqué sur avion. Cette mission a été plutôt enrichissante sur plusieurs points.

SCADE

SCADE est un environnement de développement propriétaire édité par Esterel, et basé sur le langage Lustre. Il cible principalement les applications dites "critiques", dans des domaines divers comme le ferroviaire, le nucléaire, le spatial... et bien sûr l'aéronautique.
Ce que les gens du milieu appellent un peu pompeusement de la "spécification formelle", j'aurais tendance à l'appeler du "codage graphique" (pour un certain nombre de raisons, les ingénieurs systèmes apprécient peu le terme "code"...). En effet il s'agit ici non pas de coder avec des fichiers textes, mais directement avec une représentation graphique (c'est cette représentation, qui se veut le pendant visuel de la spécification textuelle, que d'aucun nomme la "spécification formelle"). Par la suite, cette représentation graphique est convertie en langage Lustre (langage de programmation textuel, "classique"), celui-ci étant à son tour interprété afin de générer le code C (ou Ada, au choix) qui sera finalement executé sur cible.

Alors en pratique, à quoi ça ressemble ? Pour des raisons évidentes de confidentialité, je n'ai pas d'images de mon projet sous la main, mais en gros c'est un espèce d'hybride entre des représentations de fonctions logiques (notation américaine), de machines à état, et de certains schémas UML. Un exemple de chez Esterel ici (machine à état en haut,"workflow" en bas).

N'ayant jamais utilisé ce type d'outil avant, j'avoue que l'adaptation se fait assez rapidement, même si certains aspects restent déroutants (la représentation des machines à états est à mon avis assez peu intuitive par exemple), et si certains côtés sont un peu frustrants (gestion des types...).
Par contre, clairement l'outil possède des avantages sur du codage manuel normal :

• Tout l'aspect concurrent et synchrone est épargné au développeur, évitant de nombreuses erreurs
• Abstraction également de la gestion de la mémoire (ce qui n'est bien sûr pas le cas en C ou en Ada - de longues heures de debug gagnées...)
• Représentation du code sous une forme lisible par quelqu'un ne sachant pas coder (un ingénieur système par exemple)
• Annulation du besoin de vérification manuelle sur de nombreux points (revue du code généré notamment)

DO-178B

C'est mon second projet dans ce que les commerciaux aiment appeler "un contexte de DO-178B". En pratique, la DO-178B, est une norme aéronautique pour le développement d'applications critiques (le plus souvent embarquées sur avion). C'est une norme très sévère qui imposent de nombreuses règles pour la conception et le développement logiciel. Notamment :

• La gestion de configuration obligatoire
• La traçabilité "parfaite" entre les spécification et le code
• Les différents aspects de la validation et vérification (revue de code, indépendance entre le codeur et le testeur, couverture des tests...)

Bizarrement, on s'habitue... Quand j'ai découvert cette norme, j'ai plus eu l'impression de la subir que d'en profiter, mais là, ayant participé à la mise en place du process de validation (l'ensemble des règles et documents pour les tests, entre autres), je dois avouer que travailler dans un cadre très strict a ses avantages. De bonnes pratiques sont obligatoires au niveau de la traçabilité par exemple : "Quel bout de code correspond à une spec donnée ?". Ou encore : "Jusqu'à quel point dois-je tester mes fonctions ?", etc...


Au niveau dev...

C'est la première fois que je me retrouvais seul, en milieu pro, à prendre en charge le développement complet d'un soft. C'est un peu flippant au début, surtout quand on a été habitué à avoir des gars très bons techniquement à côté de soi, mais c'est aussi extrêmement enrichissant.
En particulier, le fait de devoir faire soi-même des choix au niveau de l'architecture du logiciel, des conventions techniques, du design, etc... c'est l'une des parties les plus intéressantes du développement (l'implémentation est sympa aussi, hein !).

Sans trop rentrer dans les détails techniques (qui seraient de toute façon une redite de pas mal de principes de base de conception logicielle), voici ce que j'en ai retenu :

• Les spécifications, quand elles sont écrites par quelqu'un d'autre qu'un codeur, sont forcément en décalage par rapport aux réels besoins, et par rapport à leur mise en oeuvre. Ce qui veut dire que celui qui code doit participer, et influencer au maximum cette phase de spécification. En gros : participer à cette expression des besoins plutôt que la subir ensuite.
• Avant même de réfléchir à la façon d'implémenter les fonctions demandées, identifier les problèmes à venir, d'un point de vue software (pas d'un point de vue système, ou métier), qui se posent et proposer une solution. Par exemple dans mon cas : grand nombre de variables en entrée et en sortie => création de façades ; uniquement des variables booléennes => créations de types structurés utilisés dans les interfaces de chaque fonction ; besoin temporaire de certains modes de fonctionnement => design pattern Strategy (non, il n'y a pas de POO dans SCADE, pour autant ça reste applicable) et séggrégation des fonctions par mode ; etc...
• Essayer de piquer les bonnes pratiques des langages modernes et/ou fonctionnels : pas de variables globales, éviter tant que possible les effets de bord, composer ses fonctions, etc...
  
• Le typage, c'est la vie.
• Communiquer au maximum : "Mon code est dans tel état là, maintenant.", "Telle partie sera disponible le tant.", "On va avoir des problèmes à tel niveau sur telle spec.", "Je suis en retard par rapport au planning à cause de tel problème.", etc... et de façon systématique et quotidienne. Cela permet d'éviter bien des mauvaises surprises.
• Séparer ce qui change de ce qui ne change pas (formulation honteusement pompé à Russ Olsen)
  
• Et les classiques : KISS, DRY, YAGNI, etc...
  

credits : photo de nacelle par Eric E Johnson

Les promesses de la programmation fonctionnelle

Disclaimer : Je me permets un post cours et un peu dans l'urgence pour vous proposer un document qui risque de ne pas être éternellement disponible librement... Si le lien ci-dessous ne vous permet pas d'accéder à la version PDF (ici) de cet article, c'est qu'il est trop tard... Désolé.

Juste un petit message pour signaler la publication récente d'un article (scientifique) qui me semble intéressant, à propos de programmation fonctionnelle :

The Promises of Functional Programming,
de Konrad Hinsen (CNRS Orléans)

L'auteur axe sa réflexion autour des qualités de ce type de langages, s'attardant sur la famille "LISP - Clojure" (dans laquelle il inclut implicitement Erlang, pour ceux qui se demanderaient où le placer...) et "ML" ; à savoir robustesse et compacité du code et surtout facilité de parallélisation, un aspect aujourd'hui crucial en calcul scientifique (domaine de l'auteur).

J'espère reparler rapidement ici de programmation fonctionnelle, mais sous un angle un peu particulier, puisque je ne pratique aucun langage fonctionnel à proprement parler...

Bonne lecture !

Algorithme naïf de cryptage d'entrée

Je vous propose aujourd'hui un petit algorithme dans le domaine de la cryptographie, implémenté en Ruby. Comme vous allez le voir, il s'agit d'un algorithme à clef secrète générée aléatoirement au moment du chiffrement. Cette méthode est assez peu intéressante pour la plupart des applications de cryptage (transfert de message notamment) de par le fait que la clef doit être transmise afin que le destinataire puisse décrypter le message. Dans ce cadre, on utilise plus volontiers la cryptographie asymétrique (RSA, etc...), ou, pour des raisons de performances, une méthode symétrique dont la clef est cryptée de façon asymétrique.

En revanche, cet algorithme me semble utilisable pour un autre genre d'applications : de façon locale, afin de crypter une réception de donnée par exemple.

Contexte

Plusieurs hypothèses tout d'abord. La donnée à recevoir peut être accédée par morceaux (bits, lettres, chiffres, lignes, pages, etc...). On ne connait pas à priori sa taille. On suppose également que l'on peut pareillement accéder à un nombre important de données similaires.



Principe : Se fondre dans la masse

Le coeur de la méthode consiste à noyer l'information que l'on souhaite recevoir (notée A dans la suite, data dans le code) la recevant par morceaux, au milieu d'une foule d'autres informations similaires, de façon aléatoire.
Pour cela, on construit des "cycles" de taille aléatoire, dont seuls certains index (aléatoires eux-aussi) contiennent des parts de données intéressantes. La clé consiste en la liste des cycles utilisées (plus simplement, la liste des couples [occurences de part de A, taille du cycle]).

Le code

Dans mon implémentation en Ruby, j'applique l'algorithme à un tableau. L'input dummies correspond donc à une liste de données. La sortie est la paire [données cryptée, clé]

Cryptage :



A noter que je clone l'entrée data afin que la méthode soit non destructive sur celle-ci.

Décryptage :



On décrypte par morceau correspondant chacun à un cycle de la clef.

Exemple :

Pour tester cette méthode :



Ce qui donne un résultat du genre (pour rappel, la clef est profondément aléatoire...) de celui-ci.


Conclusion

Encore une fois, il s'agit d'une méthode naïve, à utilité limitée (je suis un grand débutant en crypto). Cependant, pour un usage local, elle me semble adaptée, bien que probablement peu performante en terme de vitesse (celle-ci étant conditionnée par l'ampleur des cycles et le nombre d'occurrences par cycle, ici en dur).
J'ai du mal à me figurer de grosses failles dans cet algorithme, si ce n'est pour ce qui est de l'utilisation de la randomisation : 1/ sa complexité étant dans l'absolue aléatoire, elle ne peut être calculée que par majoration dans le meilleur des cas (le meilleur des cas en crypto étant en fait le pire des cas en algorithmique), 2/ des failles existent sur des implémentations standards des méthodes random (présence de cycles, etc... Des méthodes plus abouties existent cependant, notamment celles utilisant des propriétés physiques du matériel informatique, comme la température par exemple).

Notes :
1/ Crédit photo : Jan Chipcase
2/ Ceci n'est pas un poisson d'Avril. J'aime pas cette tradition de clampes.