Linux France

S'abonner à flux Linux France
Mis à jour : il y a 15 min 54 sec

Caranille 4.5.1, un éditeur de MMORPG en PHP

Jeudi 13 Mars

Caranille est un projet qui vient de fêter ses trois ans d’existence. C'est un logiciel qui a pour but de vous aider à bâtir rapidement et gratuitement votre propre MMORPG. Voici un aperçu de toutes les fonctionnalités de ce logiciel :

  • création d'un mode histoire ;
  • création de mission (en parallèle avec l'histoire) ;
  • création de monstres ;
  • création d'armes, de boucliers, de casques, de bottes et de gants pour personnaliser toujours plus votre personnage ;
  • messagerie privée entre joueurs ;
  • chat public ;
  • possibilité de modifier le design directement depuis le panel d'administration ;
  • possibilité de bannir un utilisateur.

Voici certaines des modifications apportées depuis la version 3.5 :

  • une revérification du code ;
  • une optimisation de celui-ci ;
  • une traduction des variables qui étaient en français et qui pouvaient gêner les joueurs/développeurs non francophones ;
  • la possibilité de bannir un joueur ;
  • une sécurité qui indique à l'utilisateur s'il y a eu des connexions suspectes.

Ce logiciel, entièrement codé en PHP, va vous permettre de créer un RPG/MMORPG entièrement en PHP et de façon gratuite.

Le logiciel est sous licence Creative Commons Attribution 4.0 International CC BY 4.0 ce qui va vous permettre de modifier entièrement le programme que ce soit en terme de design ou de fonctionnalités.

Je tiens à remercier la communauté de LinuxFr.org qui m'a bien aidée lors de la publication de la dépêche sur la version 3.5. N'hésitez pas à me laisser un commentaire avec des suggestions, voire des critiques fondées.

De plus j'anticipe en précisant que je ne compte pas utiliser de framework en PHP pour Caranille.

Télécharger ce contenu au format Epub

Lire les commentaires

Un DevCamp Alternc à Paris du 26 au 28 mars

Mercredi 12 Mars
Un DevCamp ?

Pour rappel l'objectif d'un DevCamp est de rassembler périodiquement toute personne intéressée et voulant aider à améliorer un même projet. Cela concerne donc tant les développeurs que ses testeurs, utilisateurs, traducteurs, conjoint(e)s, … Chacun à notre niveau pouvons contribuer, que ce soit durant une demi-journée ou bien durant plusieurs jours. Ce qui compte c'est d'apporter sa pierre à l'édifice.

Alternc ?

Alternc est un projet libre dont la vocation est d'aider la gestion de l'hébergement de vos noms de domaines, emails, sites webs, mailing lists, etc. Il est utilisé tant par des sociétés d'hébergement que par des particuliers, des associations ou toutes autres entités voulant héberger plus d'un projet Internet.

Contexte

Quand ? Du 26 au 28 mars 2014
Qui ? Ouvert aux développeurs, et bien sur mais aussi aux testeurs dont nous avons grand besoin pour cette nouvelle version, aucun niveau de base requis !
Où ? Paris

Nous avons la possibilité d'accueillir jusqu'à une trentaine de personnes. Comme nous souhaitons un lieu convivial et adapté au nombre de présents, ni trop grand, ni trop petit, le lieu définitif est encore à préciser.

Que faire ?

La liste précise des tâches pour les trois jours n'est pas définitive. Néanmoins, nous avons déjà un certain nombre d'idées :)
Pour vous donner des pistes, voici notre liste au moment de la rédaction de cette dépêche :

  • améliorer la gestion des tests unitaires ;
  • compléter ou ouvrir de nouvelles traductions ;
  • tester l'ergonomie utilisateur et remonter tous les problèmes d'usage ;
  • corriger les problèmes d'ergonomie détectés ;
  • améliorer le paquet Debian ;
  • tester et corriger les régressions lors des montées de version ;
  • améliorer la documentation (doxygen…).
Comment participer ?

Comme vous l'avez deviné, si nous publions cette dépêche c'est parce que nous souhaitons que vous, lecteur, puissiez participer à cet événement. N'oubliez pas que même venir au moins une demi-journée, c'est déjà essentiel !
Nous vous invitons à nous envoyer un petit courriel sur devcamp@alternc.com pour nous indiquer votre participation. Pensez à nous indiquer ce que vous intéresse et combien de temps vous pensez être présent.

Merci à vous lecteur d'être arrivé à cette dernière ligne, nous espérons qu'à votre tour vous prendrez votre clavier pour nous aider :)

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Beyond Linux From Scratch v7.5 (et elle est traduite !)

Mercredi 12 Mars

Beyond Linux From Scratch (BLFS) est le livre à lire après avoir construit LFS. En effet, si LFS se propose de vous guider dans l'installation d'un système très basique, BLFS vous donne la possibilité d'installer environ 750 paquets.

En utilisant BLFS 7.5, vous êtes certain que l'ensemble des instructions données dans le livre fonctionne avec une LFS 7.5. Cela peut paraître normal, il faut savoir qu'en l'espace d'environ 2 semaines, la petite équipe des rédacteurs de la version anglaise a testé les 750 paquets environ pour valider ces instructions.

Il est possible de transformer sa LFS en serveur LAMP, en serveur de fichiers, en PC de bureau avec KDE, LXDE ou XFCE, et il est possible en se basant sur BLFS de construire un OS simplifié avec seulement les fonctions que vous utilisez.

Tous les paquets sont présentés dans leur dernière version stable publiée.

Le devise de [B]LFS, « votre système, vos règles », résume à mon sens la philosophie du projet.

L'équipe française publie cette version française quelques jours après la VO.

Si vous souhaitez des renseignements, de l'aide, en discuter, vous pouvez venir nous rejoindre soit sur la liste de diffusion, soit sur le salon IRC (#lfs-fr sur irc.freenode.net).

Je remercie également l'association traduc.org, qui soutient le projet en l'hébergeant.

Télécharger ce contenu au format Epub

Lire les commentaires

Le Translathon 2014, session de traduction de GNOME à Paris

Mardi 11 Mars

Dix jours avant la sortie de GNOME 3.12, l'équipe de traduction francophone de GNOME se retrouve le temps d'un week-end (15/16 mars) pour en assurer la meilleure des traductions. Cela se passe à Paris et c'est l'occasion pour toute personne intéressée de venir découvrir le travail d'internationalisation et de localisation, ainsi que les outils utilisés, et de prêter main-forte à cette importante œuvre.

Contexte
  • Quand ? Le week-end du 15 et 16 mars 2014
  • Qui ? Ouvert à tout le monde, aucune connaissance préalable requise.
  • Où ? Les bureaux de Mozilla, à Paris
Objectifs

Assurer la traduction de l'interface et de la documentation de GNOME 3.12, traduire de nouvelles applications, commencer à traduire les notes de publication, réduire la liste de relectures en attente, corriger des bugs de localisation et d'internationalisation, montrer aux nouveaux venus comment tout cela fonctionne et documenter cela par la même occasion.

Comment participer

Il suffit de venir frapper à la porte, à partir de 10h (et pas après 18h), c'est au 16b boulevard Montmartre et nos amis de Mozilla fournissent les instructions pour y arriver.

Vous pouvez également vous inscrire sur la page correspondante du wiki de GNOME, ça aidera un tout petit peu l'organisation.

Télécharger ce contenu au format Epub

Lire les commentaires

Nouveau site communautaire de la forge libre Tuleap

Mardi 11 Mars

Tuleap est une forge logicielle libre publiée sous licence GPL, proposée par la société Enalean.
Depuis une plateforme centralisée, Tuleap permet aux équipes de développement de planifier et gérer leurs projets logiciels (agile ou non agile) avec une palette d'outils : un système de suivi de tickets (bugs, tâches, et.) personnalisable par projet, une intégration poussée avec Git et SVN pour le code source, Jenkins-Hudson pour l’intégration continue, Gerrit pour la revue de code, un plugin avec Mylyn pour suivre les tâches depuis Eclipse, ainsi qu'un gestionnaire de document par projet et des outils de collaboration.

Le projet Tuleap a mis en ligne un nouveau site communautaire www.tuleap.org qui présente les fonctionnalités de la forge et explique l’état d’esprit de la communauté qui promeut les principes agiles, la transparence des développements en cours et les livraisons continues.

Sur tuleap.org, vous trouverez notamment :

En parallèle de tuleap.org qui a un caractère informatif, la forge tuleap.net est l’environnement de développement du projet Tuleap proprement dit. Sur tuleap.net, vous trouverez :

Télécharger ce contenu au format Epub

Lire les commentaires

FOSS4G-fr 2014 - appel à propositions

Mardi 11 Mars

Le FOSS4G-fr 2014, événement dédié à la géomatique libre et aux données, se déroulera du 20 au 22 mai 2014 à Marne-la-Vallée.

Au programme : trois jours de conférences et ateliers, abordant des sujets techniques mais aussi des retours d'expériences, permettant de découvrir les dernières tendances et technologies du domaine, ainsi que leurs applications concrètes.

Suite au succès de la conférence FROG 2013, ces nouvelles rencontres seront l'occasion pour la communauté de se rencontrer, d'échanger et de partager projets et expériences.

Vous êtes expert sur un domaine lié aux SIG libres ? Vous avez utilisé les outils de l'OSGeo dans un contexte spécifique (projet d'envergure, données très volumineuses, client reconnu, projet innovant, etc.) ? Vous participez à un projet libre lié à l'OSGeo ? Alors venez présenter les dernières tendances et technologies Open Source pour les Systèmes d'Information Géographique, et proposez une conférence, avant le 15 mars 2014 minuit (heure de Paris) : http://foss4g.osgeo.fr/Programme

Pour toute information ou question, vous pouvez contacter les responsables à l'OSGeo-fr : conferences CHEZ osgeo.asso.fr

À propos de l'OSGeo-fr :

L’association OSGeo.fr est la représentation Francophone de la fondation Open Source Geospatial dont la mission est d’aider et de promouvoir le développement collaboratif des données et des technologies géospatiales ouvertes. L’association est une entité légale grâce à laquelle les membres de la communauté peuvent contribuer au code, aux finances et aux autres ressources, et s’assurer que leurs contributions seront maintenues au bénéfice du public.

L’OSGeo.fr sert également d’organisation de référence et d’assistance pour la communauté géospatiale libre, et fournit un forum commun et une infrastructure partagée pour améliorer la collaboration entre les projets.

La participation est ouverte à l’ensemble de la communauté open source. Tous les travaux de l’association sont publiés sur des forums publics au sein desquels peut s’investir une communauté libre de participants. Les projets de la Fondation OSGeo sont tous librement disponibles et utilisables sous une licence open source certifiée par l’OSI.

Télécharger ce contenu au format Epub

Lire les commentaires

Apéro Python/PHP à Lyon le mardi 25 mars

Mardi 11 Mars

Les antennes lyonnaises de l’AFPy et de l’AFUP organisent ensemble un apéro le mardi 25 mars à partir de 19h à l'Antre-Autre (11 rue Terme, Lyon 1er).

Une présentation sera donnée sur la sécurité web. Après un aperçu des principales failles présentes dans les applications web, une réflexion sur les failles XSS sera exposée et une méthode de protection efficace contre une partie de celles-ci sera présentée. Enfin, le thème de la sécurité sera abordé de façon plus générale (politique de sécurité, bonnes pratiques…).

À l’issue de cette présentation, nous pourrons échanger librement sur ces deux langages de programmation, autour d’un verre et/ou d’une assiette.

Télécharger ce contenu au format Epub

Lire les commentaires

Quelques nouveautés sur votre site web préféré

Mardi 11 Mars

Pour fêter ma millième entrée de suivi fermée sur LinuxFr.org, j'ai décidé de faire une petite dépêche mettant en avant quelques nouveautés récentes.

Premier changement, la feuille de style par défaut a été un peu revue. La largeur maximale est maintenant limitée pour les grands écrans afin de rendre la lecture plus confortable.

La version personnalisée de Markdown utilisée pour saisir du contenu sur le site permet maintenant d'inclure des formules mathématiques, en ligne à l'intérieur d'un paragraphe ou dans un bloc séparé. Par exemple, ou, pour la version longue :

Autre nouveauté, il est possible de récupérer une version markdown des contenus du site, grâce à un lien « Markdown » en bas de ceux-ci. Vous pouvez notamment essayer sur cette dépêche pour voir à quoi ressemblent les formules mathématiques :p

Enfin, le moteur de recherche du site a été revu. Il fonctionne désormais avec ElasticSearch 1.0. Il devrait être un peu plus pertinent et propose maintenant le filtrage par tags.

NdM: Pour fêter cela, Nono a décidé d'envoyer une coupe de champagne aux 1000 premiers lecteurs qui en feront la demande.

Télécharger ce contenu au format Epub

Lire les commentaires

Revue de presse de l'April pour la semaine 10 de l'année 2014

Lundi 10 Mars

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

[Le Monde.fr] Et si les implants médicaux étaient sous licence libre?

Par Alexandre Léchenet, le samedi 8 mars 2014. Extrait:

Lors d'une présentation à «South by Southwest», Karen Sandler a expliqué comment la pose d'un pacemaker l'avait poussé à s'interroger sur le logiciel le faisant fonctionner.

Lien vers l'article original: http://www.lemonde.fr/technologies/article/2014/03/08/et-si-les-implants-medicaux-etaient-sous-licence-libre_4379783_651865.html

[lepopulaire.fr] Un mois consacré au logiciel libre à la BFM de Limoges

Par Marion Buzy, le vendredi 7 mars 2014. Extrait:

Si vous souhaitez avoir un minimum de main mise sur ce que fait votre ordinateur, le mois du logiciel libre, qui commence le 8 mars à la BFM, est fait pour vous.

Lien vers l'article original: http://www.lepopulaire.fr/limousin/actualite/2014/03/07/un-mois-consacre-au-logiciel-libre-a-la-bfm-de-limoges_1903834.html

[Les Echos] Agitation à Bruxelles autour de la réforme du droit d'auteur

Par Renaud Honoré, le jeudi 6 mars 2014. Extrait:

La Commission avait lancé une consultation auprès de toutes les parties intéressées par une réforme d'un régime du droit d'auteur que remet en question le développement de l'économie numérique. La procédure s'est achevée hier, avec plus de 8.000 réponses, ce qui fait partie des records en la matière

Lien vers l'article original: http://www.lesechos.fr/entreprises-secteurs/tech-medias/actu/0203353817280-agitation-a-bruxelles-autour-de-la-reforme-du-droit-d-auteur-654919.php

Et aussi:

Voir aussi:

[PC INpact] Mozilla enquête sur une installation de Firefox facturée 20 euros chez Dell

Par Vincent Hermann, le jeudi 6 mars 2014. Extrait:

Récemment, une option sur le site anglais de Dell permettait pour au moins une machine d’installer Firefox contre la modique somme de 16,25 livres, soit 19,65 euros environ. Or, il apparaît que Mozilla et Dell n’ont aucun contrat de ce type, ce qui a conduit l’éditeur à démarrer une enquête.

Lien vers l'article original: http://www.pcinpact.com/news/86326-mozilla-enquete-sur-installation-firefox-facturee-20-euros-chez-dell.htm

[Silicon.fr] Les experts de l’open source s’affichent contre les brevets logiciels

Par David Feugey, le jeudi 6 mars 2014. Extrait:

L’affaire qui oppose Alice Corp. à CLS Bank ouvre la voie à une possible réforme des brevets logiciels outre-Atlantique. Les acteurs de l’open source affichent leur soutien auprès de la Cour suprême des États-Unis.

Lien vers l'article original: http://www.silicon.fr/les-experts-americains-de-lopen-source-montent-au-front-contre-les-brevets-logiciels-93100.html

Et aussi:

[cio-online.com] Entretiens avec les DSI et les dirigeants du secteur informatique

Par Bertrand Lemaire, le mardi 4 mars 2014. Extrait:

Autant il est impossible d'imposer un logiciel propriétaire dans un appel d'offres, autant cela ne pose pas de problème pour un logiciel libre qui peut être intégré par qui le souhaite. Le Conseil d'Etat a donné raison à une structure publique qui avait fait le choix explicite a priori d'un logiciel libre.

Lien vers l'article original: http://www.cio-online.com/entretiens/lire-le-sill-vise-a-harmoniser-le-recours-au-logiciel-libre-par-l-etat-521.html

[Numerama] Des DRM sur les capsules de café

Par Guillaume Champeau, le mardi 4 mars 2014. Extrait:

En Amérique du Nord, un concurrent de Nespresso a décidé d'ajouter un DRM à ses cafetières, pour qu'elles n'acceptent que les capsules officielles.

Lien vers l'article original: http://www.numerama.com/magazine/28647-des-drm-sur-les-capsules-de-cafe.html

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Reqflow pour tracer vos exigences

Lundi 10 Mars

Reqflow est un outil open-source, sous licence GPL, de traçabilité d'exigences entre documents. Ce genre de traçabilité s'avère utile dès que la taille d'un projet devient conséquente : plusieurs centaines d'exigences.

J'avais plusieurs fois cherché et mentionné le besoin d'un tel outil open-source et, ne trouvant rien, je l'ai réalisé.

NdM : merci à goeb pour son journal.

Sommaire Reqflow Le concept d'exigence

Pour résumer le concept d'exigence à ceux qui n'en ont pas l'habitude, une exigence (requirement en anglais) est typiquement une fonctionnalité, décrite en quelques lignes. De cette exigence peuvent découler :

  • des exigences plus fines, décrivant comment on va réaliser la fonctionnalité
  • des tests, qui décrivent comment la vérifier sur le produit fini.

On dit que les exigences en aval couvrent les exigences en amont.

L'intérêt de décrire un système par exigences est de fragmenter la complexité en portions de dimensions réduites, plus faciles à maîtriser humainement (comprendre, discuter, vérifier, tester). Cela oblige également à synthétiser les documents de spécifications. On a trop souvent vu des documents de plusieurs centaines de pages verbeux, imprécis, et confus. Pour bien travailler avec les exigences, il faut que ceux qui écrivent les spécifications aient dès le début une approche par exigence, ce qui n'est malheureusement pas toujours le cas.

La manière de travailler ensuite peut grossièrement se résumer ainsi : on vérifie qu'on n'a oublié aucune exigence en réalisant le système.

Les entreprises industrielles qui conçoivent de gros systèmes (véhicules, avions, etc.) utilisent la fragmentation en exigences pour définir et réaliser leurs systèmes.

Exemple de spécification

Prenons l'exemple d'un logiciel de navigation Internet qui souhaite se conformer à la norme CSS2 (dans la vraie vie, les navigateurs web ne s'encombrent pas de traçabilité d'exigences, car c'est un procédé coûteux qui n'est pas justifié pour ce genre de logiciel non critique).

Le document de spécification est donc la norme CSS2, extrait :

15.6 Font boldness: the 'font-weight' property 'font-weight' Value: normal | bold | bolder | lighter | 100 | 200 | 300 | 400 | 500 | 600 | 700 | 800 | 900 | inherit The 'font-weight' property selects the weight of the font. The values '100' to '900' form an ordered sequence, where each number indicates a weight that is at least as dark as its predecessor. The keyword 'normal' is synonymous with '400', and 'bold' is synonymous with '700'.

Ici, il n'y a pas de marqueur d'exigence dédié. Donc, on prend le numéro du paragraphe "15.6" pour cet exemple (mais ce n'est pas une manière très rigoureuse de procéder et il va être difficile pour l'outil de traçabilité de capturer les exigences).

Et on code le navigateur web, avec ses petites mains. Pendant ce temps un testeur va écrire le plan de test, comme ceci :

Exemple de plan de test T_FONT_01 1. écrire une page HTML utilisant un mot avec font-weight 'normal' 2. vérifier que le navigateur affiche ce mot avec un poids 400. Ref: 15.6 Font boldness: the 'font-weight' property T_FONT_02 1. écrire une page HTML utilisant un mot avec font-weight 'bold' 2. vérifier que le navigateur affiche ce mot avec un poids 700. Ref: 15.6 Font boldness: the 'font-weight' property

Ensuite la méthode va consister à dérouler les activités suivantes :

  • on exécute le logiciel de traçabilité :
    • pour vérifier si aucune exigence de la spécification n'a été oubliée;
    • pour générer la matrice de traçabilité (utile aux étapes suivantes).
  • quelqu'un va ensuite vérifier pour chaque exigence de la spécification, si les tests indiqués par la matrice de traçabilité, couvrent effectivement l'exigence dans son intégralité. C'est une étape manuelle et fastidieuse pendant laquelle la matrice de traçabilité générée est une aide précieuse car elle sert de support au suivi de l'avancement (on coche les exigences que l'on vérifie au fur et à mesure, jour après jour.
  • ensuite quelqu'un effectue les tests à partir du plan de test. Mais ce n'est plus du domaine de la traçabilité des exigences.
  • si tous les tests sont OK, alors le logiciel est conforme à la spécification.
Principe de Reqflow

Reqflow est un outil en ligne de commande. Il analyse les fichiers d'entrée (au format Open XML, Open Document, etc.), capture les exigences, capture les liens entre exigences, et génère un rapport (format texte, CSV ou HTML), indiquant si toutes les exigences en amont sont couvertes par des exigences en aval.

Pour fonctionner, on a besoin de placer dans les documents des marqueurs d'exigence, comme dans l'exemple CSS ci-dessus. Et via des expressions régulières on indique comment capturer les exigences :

-req [1-9][0-9]*\..*

Et pour le plan de test :

-req T_.* -ref "Ref: .*"

Reqflow indique ensuite :

  • les exigences de la spécification qui ont été oubliées dans les tests
  • les erreurs (exigences en double, références vers des exigences inexistantes, etc.)
  • les matrices de traçabilité entre exigences et documents

Exemple de rapport HTML : http://goeb.github.io/reqflow/reqReport.html

Analyse des PDF

Pour analyser les fichiers d'entrée au format PDF, Reqflow utilise la bibliothèque Poppler, que l'on retrouve dans plusieurs lecteurs PDF open-source.

Autant pour analyser les fichiers HTML, texte, ODT, DOCX, c'est relativement simple (bibliothèque libxml2 et analyse manuelle), autant pour le PDF c'est compliqué.

Car le format PDF, s'il est bien pour transférer un document en gardant le rendu visuel, n'est pas du tout adapté pour être traité informatiquement. En effet les mots que l'on voit se suivre sur l'écran ne sont pas toujours consécutifs dans le fichier. Et ils peuvent même être inversés.

Je crois (mais ne suis pas certain) que Poppler est capable de remettre les mots dans l'ordre en se basant sur leur emplacement dans la page.

Expressions Régulières

J'avais commencé avec la bibliothèque POSIX regex. Puis je me suis réorienté vers la bibliothèque PCRE car elle me paraissait plus conviviale (pas besoin d'échapper les parenthèses notamment). Heureusement, la bibliothèque PCRE fournit une interface identique à la lib regex (libpcreposix), donc je n'ai pas eu à changer mon code source.

Autres outils du marché

D'autres outils propriétaires dominent sur le marché.

Reqtify, outil graphique et qualifié selon certaines normes de développement aéronautique (DO178-B je crois), présente une interface graphique assez pratique.
Reqtify capture les exigences des documents par des expressions régulières, ou par les styles Word.
Il a une fonctionnalité intéressante : cliquer sur une exigence, dans son interface graphique, provoque l'ouverture du document Word ou Excel associé et le positionnement au paragraphe de cette même exigence.

DOORS (IBM® Rational® DOORS®) ne capture pas les exigences à partir des documents, mais possède les exigences dans une base de données et a une interface graphique. Il peut toutefois importer des documents externes dans sa base de données. Ensuite DOORS peut génèrer les matrices de traçabilité et éventuellement les documents (au format Word par exemple) pour échanger avec d'autres parties prenantes qui ne possèderaient pas DOORS.

En comparaison de ces outils, Reqflow est très petit, très rustique car il a moins de convivialité, moins d'ergonomie, moins de fonctionnalités. Mais Reqflow a les atouts suivants :

  • il est simple
  • il est possible de générer les matrices de traçabilité par un bête script shell ou batch
  • il est gratuit et open-source et a tout le temps devant lui pour s'améliorer
  • il est en ligne de commande, et greffer une interface graphique au-dessus est possible
Conclusion

J'utilise Reqflow dans mon travail, pour tracer 750 exigences de 8 documents de spécifications en amont, et il me rend bien service.

Page web de Reqflow: http://goeb.github.io/reqflow
Code source sur Github: http://github.com/goeb/reqflow

Télécharger ce contenu au format Epub

Lire les commentaires

Romaine Lubrique sur OxyRadio

Dimanche 9 Mars

Véronique Boukali et Alexis Kauffmann (Framasoft), du projet « Romaine Lubrique », animent depuis janvier dernier sur OxyRadio une émission radio mensuelle d'une heure dédiée au domaine public.

Il s'agit de valoriser culturellement le domaine public mais également de s'interroger sur le partage à l'ère du numérique. Ici toute œuvre évoquée se trouve être immédiatement et légalement disponible sur Internet.

Chaque émission propose un dossier ponctué d'un point d'actualité et d'une question juridique. Elle est également rythmée par une lecture, une respiration musicale et la présentation d'un film, tous dans le domaine public.

Le dossier de la première émission était consacré à Apollinaire, celui de la deuxième à Courteline et la troisième à Camille Claudel, récemment entrée dans le domaine public. Quant à la chronique cinématographique, il s'agissait du film noir Detour, de la comédie musicale Mariage royal et de la Nuit des morts-vivants. Ils présentent la particularité d'être entrés rapidement dans le domaine public américain pour défaut ou non renouvellement du copyright.

OxyRadio est une webradio associative basée à Cergy. Elle a été souvent évoquée par le passé sur Linuxfr parce qu'elle diffuse majoritairement de la musique sous licences libres et ouvertes mais aussi parce qu'il était souvent question de logiciels libres dans l'émission Les Enfants du Web animée par Mathieu Pasquini (InLibroVeritas). À noter qu'après une longue période d'hibernation, l'émission a repris du service.

P.-S. Les animateurs étant novices en radio, ils sont preneurs de tout conseils et critiques dans les commentaires pour améliorer les prochaines émissions.

Télécharger ce contenu au format Epub

Lire les commentaires

Badges VIP pour le prochain salon Solutions Libres & Open Source 2014

Dimanche 9 Mars

Le prochain salon Solutions Libres & Open Source (ex Solutions Linux) se tiendra sur deux jours comme l'année passée : les 20 et 21 mai prochains, toujours au Centre des Nouvelles Industries et Technologies de Paris - La Défense, plus connu sous son acronyme CNIT. Et cette année, LinuxFr.org sera encore présent au sein du village associatif, stand C39. Comme les autres années, nous essayons de vous réserver quelques surprises à gagner directement sur le stand. Nous travaillons dessus et nous vous en dirons plus le moment venu.

Comme tout exposant, LinuxFr.org a un quota de badges VIP pour le salon. Comme vous, chers contributeurs et lecteurs, êtes nos VIP à nous (si, si), nous vous proposons donc de vous faire parvenir un badge VIP. Selon l'organisateur, cela donne accès au Club VIP, vestiaire gratuit, accueil spécifique, accès prioritaire aux conférences… Pour ce faire, rien de plus simple, il suffit de remplir ce petit formulaire de demande avant le mardi 6 mai prochain à 16h00.

Seules les 300 premières demandes seront honorées. Nous nous engageons juste à transmettre, (sous format libre OpenDocument !) les formulaires complétés à Tarsus (l'organisateur du salon)… ou pas. Toute demande manifestement farfelue ne sera pas prise en compte.

Données personnelles

Concernant les informations personnelles demandées, il y en a moins que pour un badge classique. Quant à la politique d'utilisation des données personnelles transmises, merci de consulter les sites web de Tarsus et du salon Solutions Libres & Open Source. LinuxFr.org ne conservera pas ces données une fois envoyées à Tarsus.

Informations pratiques

Le salon sera ouvert les

  • mardi 20 mai de 9h00 à 19h00 ;
  • mercredi 21 mai de 9h00 à 18h00.

Il se tiendra dans le hall Marie Curie du CNIT à Paris la Défense. Les moyens d'accès pour ceux qui ne connaissent pas la Défense (on peut vite s'y perdre) :

  • Métro : ligne 1, station La Défense - Grande Arche
  • RER : ligne A, station la Défense – Accès Parvis
  • Voiture : boulevard circulaire (Parking central sortie la Défense 4 / Parking CNIT sortie la Défense 6)
  • Tramway : T2 - arrêt Esplanade de la Défense
Télécharger ce contenu au format Epub

Lire les commentaires

IEUFI - prochaine conférence (et vidéos des dernières) + nouveau site

Dimanche 9 Mars

La prochaine conférence aura lieu le vendredi 11 avril à l'Institut Mines-Telecom (46 rue Barrault - Paris, 13ème arrondissement). Elle portera sur comment devenir un FAI, résoudre (facilement) le problème des zones blanches, et bien plus encore. L'intervenant pour cette conférence est Bruno Spiquel, aussi connu sous le pseudo de turblog et/ou Spyou.

Elle fait partie du cycle de conférences «  Il Etait Une Fois Internet » (IEUFI), qui a déjà vu passer les personnes suivantes :

  • Stéphane Bortzmeyer sur le DNS,
  • Benjamin Sonntag sur le SSL/TLS,
  • Joël Mau sur l’infrastructure physique d’Internet,
  • Philippe Aigrain et Lionel Maurel sur la création, le partage et le droit d'auteur,
  • Benjamin Sonntag sur l'email,

L’entrée est, bien entendu, libre, les conférences sont enregistrées et (normalement) disponibles en direct. Les transparents et les vidéos sont disponibles sur http://iletaitunefoisinternet.fr http://data.confs.fr/ peu de temps après chaque conférence, le tout sous licence Creative Commons By-SA.

Si vous voulez plus d’informations, proposer des idées, faire une conférence, ou dénoncer quelqu’un qui pourrait en faire une : contact (a) iletaitunefoisinternet.fr.

Ah, et comme vous pouvez le voir, il y a un nouveau nom de domaine, et même un twitter !

Télécharger ce contenu au format Epub

Lire les commentaires

LUTIm 0.2 : le retour

Dimanche 9 Mars

18 jours après la version 0.1 présentée dans une dépèche précédente, voici venir une nouvelle version de LUTIm !

Pour rappel, LUTIm (à prononcer comme lutin) est un service web d'hébergement d'images, gratuit, libre et anonyme. Il est écrit en Perl, est utilisable avec ou sans JavaScript et possède une API, permettant son usage depuis d'autres logiciels comme par exemple Shutter, un logiciel de capture d'écran (rappelons qu'une des principales raisons du développement initial de LUTIm est le partage simple de captures d'écran).

Les trolls discussions ont été âpres sur certains aspects de LUTIm mais fort enrichissantes, aidant LUTIm à évoluer pour le meilleur (tout du moins, je l'espère).

Les changements ont été nombreux, comme en témoigne le Changelog mais les deux principaux changements, vraiment visibles de tout un chacun sont la possibilité de chiffrer les images et les miniatures des images dans la réponse.

L'instance officielle, https://lut.im, bénéficie bien évidemment des derniers développements, éventuellement avant les releases officielles quand il s'agit de bugs graves.

Sommaire Les nouveautés Chiffrement

Pour avoir un service d'hébergement d'images garantissant la vie privée, outre la question des logs, il y a la question de qui peut voir ce que l'on a déposé et bien souvent les administrateurs des services le peuvent (All your base are belong to us comme dit le dicton). C'est pourquoi LUTIm propose désormais la possibilité de chiffrer ses images (l'administrateur peut forcer l'usage systèmatique du chiffrement).

À propos du chiffrement, deux écoles s'opposent : le chiffrement côté serveur ou côté client. Chacune d'entre elles possède des avantages et inconvénients dont voici les principaux :

  • côté client, le JavaScript est obligatoire, mais le serveur ne peut pas connaître la clé ;
  • côté serveur, il faut faire confiance au serveur pour ne pas stocker la clé, mais l'interface peut se passer de JavaScript.

LUTIm utilise un chiffrement côté serveur pour plusieurs raisons :

  • LUTIm est codé de façon à être utilisable même sans JavaScript. Cela n'a pas toujours été simple, mais c'est un point essentiel de ce logiciel, donc renoncer à cette fonctionnalité était exclu ;
  • les images déposées sur LUTIm sont utilisables directement : vous pouvez déposer des images sur LUTIm et les inclure sur LinuxFR comme c'est le cas dans cette dépèche. Un chiffrement JavaScript aurait empêché une telle utilisation ;
  • Le développeur principal (moi :p) préfère de loin le Perl au JavaScript.

L'algorithme de chiffrement est Blowfish et les clés sont générées aléatoirement par le serveur. Les clés font 8 caractères de long et les caractères sont choisis dans [a-zA-Z0-9], ce qui représente 2 821 109 907 456 combinaisons possibles. La longueur de la clé sera paramètrable (par l'admin) dans un futur proche.

La clé n'est bien évidemment jamais stockée sur le serveur, de même que l'image non chiffrée. Elles ne font que transiter en mémoire le temps du chiffrement pour l'image et jusqu'à l'affichage de la réponse pour la clé.

L'instance officielle chiffre désormais systématiquement toutes les images (les anciennes images non chiffrées étant toujours accessibles).

Et si vous avez toujours peur d'un serveur malveillant, installez votre propre instance, c'est si simple :)

Miniatures

Un des reproches gentiment fait à LUTIm était qu'il était difficile de savoir à quelle image correspondait telle URL lors de l'envoi simultané de plusieurs images. Si le module Perl Image::Magick est installé, une miniature de l'image est générée (avant un éventuel chiffrement) et renvoyée encodée en base64, prête à être utilisée en tant que source dans une balise img. L'absence d'Image::Magick ne pose aucun problème à LUTIm qui fonctionnera normalement, juste sans les miniatures.

L'encodage en base64 permet de ne pas garder la miniature sur disque pour garantir la confidentialité de l'image (si l'image est chiffrée et pas la miniature, quel intérêt ?) ainsi que pour éviter l'encombrement de l'espace disque.

La création de la miniature et son encodage en base64 ne nécessitent à aucun moment d'enregistrer l'image dans un fichier.

Statistiques

Stocker les images des autres est fort gentil, mais il est bon de garder un œil sur l'évolution du service. Aussi une page de statistiques a fait son apparition. Si elle ne fournit pas la taille du répertoire des fichiers, elle permet toutefois d'appréhender d'un coup d'œil le nombre total d'images déposées, le nombre d'images déposées par jour et l'évolution du nombre total d'images.

La période de statistiques est paramètrable par l'administrateur et il faut mettre en place une tâche cron pour générer les statistiques.

Si le JavaScript n'est pas activé, l'utilisateur verra apparaître un tableau des données utilisées pour la génération des graphiques.

Les graphiques sont générées avec le plugin jquery SimpleGraph et la bibliothèque Raphael mais d'autres modules sont actuellement à l'étude.

Vous pouvez voir les graphiques de l'instance officielle.

Tâches cron

Outre la génération des statistiques, d'autres actions peuvent être activées via cron :

  • suppression des IPs des envoyeurs dans la base de données après un délai paramètrable ;
  • suppression des images expirées (les images étaient auparavant supprimées lors d'une tentative d'accès) ;
  • surveillance de la taille du répertoire des images avec 3 actions possibles si la taille maximale configurée est dépassée :
    • émission d'un message sur la sortie standard (cron enverra ce message par mail) ;
    • création d'un fichier bloquant tout nouvel envoi d'images (avec avertissement aux utilisateurs. Le fichier est supprimé si on repasse sous la limite lors de l'exécution de la tâche) et émission d'un message ;
    • suppression des images les plus anciennes par paquet de 50 jusqu'à avoir une taille de répertoire en dessous de la limite et émission d'un message (non recommandé) ;
Autres ajouts

Un peu en vrac, voici d'autres nouvelles fonctionnalités :

  • possibilité de diffuser un message sur les pages d'accueil, d'informations et de statistiques ;
  • possibilité de bloquer manuellement l'envoi d'images en créant un fichier spécifique à la racine du répertoire de LUTIm (ce n'est pas le même fichier que celui posé par la tâche cron de surveillance du dossier d'images) ;
  • meilleure détection des types MIME ;
  • barre de progression des envois d'images ;
  • autorisation de requêtes cross-domain (la liste des domaines autorisés est configurable ou désactivable) ;
  • documentation de l'API (celle-ci doit encore être mise à jour, mais l'essentiel est décrit) ;
  • Ajout d'en-têtes HTTP pour les images en cohérence avec leur durée de vie ;
  • possibilité d'envoi d'images en donnant leur URL. L'image est alors téléchargée sur le serveur.
Le futur

Si LUTIm est jeune, il n'en a pas moins déjà démontré sa robustesse face à l'effet Korben (le pic de plus de 2 000 images envoyées sur la page des statistiques) et les retours sont encourageants, que ce soit par les utilisateurs, par les administrateurs désireux d'installer leur propre instance, ou par la communauté Perl francophone (coucou les Mongueurs) voire anglophone (via la liste de diffusion du framework Mojolicious).

Le développement de LUTIm ne s'arrêtera donc pas là. Des demandes de fonctionnalités sont toujours en attente sur github et il ne tient qu'à vous d'en ajouter d'autres !

Entre autres choses, la priorité de la version 0.3 sera l'écriture de tests (non, il n'y a pas encore de suite de tests, et c'est mal, je sais) ainsi que l'ajout de la possibilité d'utiliser une base MongoDB plutôt que SQLite (ça sera une possibilité, pas une obligation, SQLite sera toujours supporté).

Divers

L'instance officielle est disponible en connexion sécurisée, avec un vrai certificat, permettant d'embarquer les images provenant de LUTIm sans soulever le problème de Mixed Content.

LUTIm est disponible en français et en anglais. Le choix de la langue est fait par les préférences de langue du navigateur (en-tête HTTP Accept-Language). Si vous voulez proposer une nouvelle langue, toutes les contributions sont les bienvenues ! Voir ici pour les fichiers de langue.

La concurrence est là (https://img.bi/, libre et écrit en node.js.) mais un LUTIm sait se montrer courageux et résister à l'adversité !

Maintenant que le chiffrement est de la partie, le petit frère de LUTIm, Lufi pourrait faire son apparition relativement vite. Lufi sera un service d'hébergement de fichiers basé sur ±90% du code de LUTIm.

Vous pouvez soutenir LUTIm avec flattr, bitcoin (1K3n4MXNRSMHk28oTfXEvDunWFthePvd8v) ou encore dogecoin (DFDpahcHFBf2rGMGe49H7m3USw6JMhmwGo).
Vous pouvez aussi simplement parler de LUTIm autour de vous et utiliser le hashtag #Lutim lorsque vous en parlez sur les réseaux (a)sociaux.

Télécharger ce contenu au format Epub

Lire les commentaires

Sortie de Perfwatcher 2.0

Samedi 8 Mars

La nouvelle version majeure de l'outil de métrologie Perfwatcher vient de sortir, Perfwatcher 2.0. Perfwatcher est un frontend pour Collectd (un outil de mesure de performances du système) écrit en PHP, HTML, JavaScript et C.

Présenté sur LinuxFr.org lors de sa sortie en version 1.2, le fonctionnement interne de Perfwatcher a subi un profond remaniement amenant une modularité permettant aujourd'hui son déploiement sur des grilles de calculs de plus de 20000 nœuds.

Pour rappel, Perfwatcher est une interface utilisateur pour Collectd, il permet d'afficher les graphes RRD générés par ce dernier et étend ses fonctionnalités par l'apport de nombreux modules et patchs.

Parmi ceux-ci, le module Top permet l'affichage de la totalité de la liste des processus à la façon de la commande top et ce, à la date et heure de son choix ainsi que l'affichage des processus sous la forme d'une frise chronologique (timeline).

Perfwatcher permet, en outre et ce fut son premier but, d’agréger les données de Collectd par groupes de serveurs afin de, par exemple, visualiser la charge moyenne de parties d'une grille de calcul.

À ce remaniement et la traditionnelle correction de bogues, s'ajoute un lot de nouveautés parmi lesquelles nous pouvons trouver :

  • l'accès à distance à Collectd rendant l'installation encore plus modulaire,
  • la possibilité d'accéder à plusieurs instances de Collectd,
  • un système de presse-papier permettant de sélectionner des graphes puis de les comparer,
  • des onglets éditables via l'utilisation d'un langage de balisage (Markdown),
  • un zoom des graphes amélioré.

Télécharger ce contenu au format Epub

Lire les commentaires

Les femmes dans l'informatique

Samedi 8 Mars

Le 8 mars est la journée internationale des droits des femmes. Le rouge à lèvre cadeau-bonus du marchand de cosmétique, les cartes de crédit rosifiées du banquier (ou le fleurissement inopiné de blagues sexistes) n'ont pas vocation à faire partie des droits fondamentaux des femmes.

C'est l'occasion de faire un tour d'horizon de leur place dans le monde de l'informatique, notamment dans le logiciel libre. En effet, elles sont sous-représentées parmi les acteurs de l'informatique: étudiants, salariés, enseignants, etc. Si on écarte l'hypothèse qu'il existe une essence (masculine ou féminine) prédisposant les individus à choisir un domaine professionnel en fonction de leur sexe, on peut se demander pourquoi un tel déséquilibre existe, depuis quand, et quels sont ses effets au sein du milieu de travail et dans les relations professionnelles?

Sommaire Contexte et situation Historique des femmes en informatique Avant l'info…

La méfiance voire l'opposition radicale à l'égard de l'instruction des filles a fait l'objet de théories philosophiques aussi diverses que celles d'Aristote à Proudhon en passant par Saint-Paul ou par Rousseau, pour qui « toute l'éducation des femmes doit être relative aux hommes. Leur plaire, leur être utile (…) voilà les devoirs des femmes (…). » Malgré ces réticences, de tous temps, quelques femmes se sont distinguées en sciences ; on peut mentionner Hypatie, Ada Lovelace inévitable à citer, Sophie Germain, Sofia Kovalevskaïa, Marie Curie.

La croyance qui associe la femme à la nature, la rendant incapable de transcender et de dépasser son corps tandis que l'homme est un être de culture tourné vers la réflexion, se retrouve sous diverses formes dans toute la philosophie occidentale. Elle est encore vivace aujourd'hui, en attestent les déclarations régulières d'Aldo Naouri par exemple. Sa critique a été entreprise en premier lieu par Simone de Beauvoir, et trouve son prolongement dans les études de genre, qui visent à montrer comment se construit l'identité sexuée des individus à travers les interactions sociales et les rapports de forces qui les structurent.

La transmutation des maths en info…

À ses débuts, dans les années 50, l'informatique et ses différents métiers étaient plutôt considérés comme féminins car peu qualifiés (par exemple, programmer n'était pas considéré comme une tâche intellectuelle ; c'était la continuation du métier de calculatrices, femmes qui effectuaient les calculs entre autres dans les observatoires astronomiques). Par ailleurs, sa proximité avec les mathématiques permettait à des mathématiciennes de s'y intégrer : à ce titre, le cas de Grace Hopper est emblématique. La progression des femmes dans l'informatique a été sensible jusque dans les années 80, puis s'est inversée, jusqu'au taux de féminisation très faible que l'on connaît aujourd'hui.

Cela s'explique de différentes façons. D'après l'ouvrage Gender Codes dirigé par Thomas J. Misa, les métiers ont connu une très forte demande de main-d'œuvre. Pour y répondre, une solution a été de revaloriser ces métiers, ce qui a eu pour conséquence d'augmenter la proportion d'hommes. Isabelle Collet met aussi en évidence l'émergence d'une culture propre à l'informatique dans les années 1980, très masculine, qui a fortement contribué à écarter les filles dans ces filières. Ce mouvement est indissociable des représentations scolaires, qui poussent les garçons dans des métiers techniques et scientifiques, et les filles dans des filières littéraires et médico-sociales.

La situation présente Un marché du travail français qui reflète les inégalités de genre

Des études, comme celles de la Direction de l'Animation de la Recherche, des Études et des Statistiques, DARES, mettent en lumière la forte concentration des femmes dans certains métiers. Aujourd'hui, près de la moitié des femmes (47%) exerce dans une dizaine de métiers comme infirmières (87,7% de femmes), aides à domicile ou assistantes maternelles (97,7%), agents d’entretien, secrétaires ou enseignantes.

Du côté des hommes, la répartition est plus dispersée, les 10 professions les plus répandues parmi les hommes n’employant que 31% d’entre eux. Les professions les plus masculines sont: conducteurs de véhicules (près de 90% d’hommes), l’armée, la police ou les pompiers (environ 75%), ouvriers du bâtiment, manutentionnaires, ainsi que l'ingénierie informatique. (source)

En outre, les secteurs les plus féminisés sont souvent les plus précarisés, les moins valorisés et conséquemment les moins bien payés, comme le montre les études du marché du travail genré conduites par Margaret Maruani. (source, source)

Tout cela a des conséquences sur les inégalités salariales comme le montre cette étude récente de l'Institut National de la Statistique et des Études Économiques, INSEE.

Ceci se répercute dans les métiers de l'informatique; les chiffres donnés plus bas en rendent compte.

Quelques chiffres

En France :

  • école / enseignement supérieur
    • 11% d'étudiantes dans les écoles d'ingénieur en informatique
    • 20% en Licence professionnelle Métiers de l'Informatique, du Traitement de l'Information et des Réseaux

La raréfaction des étudiantes dans les filières universitaires d'informatique est telle que des groupes entiers sans filles, rares avant 2005, sont de plus en plus courants. La tendance se confirme depuis lors.

  • professionnelles (dans des entreprises info et non info)
    • 30% dans les SSII

D'après une étude du Cigref, elles sont moins représentées dans le développement, mais aussi dans les directions et dans le conseil, positions les plus intéressantes financièrement. La proportion de femmes dans ces métiers va vraisemblablement diminuer dans les prochaines années, faute de jeunes diplômées.

  • logiciel libre

La participation des femmes dans le logiciel libre est plus difficile à évaluer précisément, faute de statistiques officielles. En recoupant diverses sources, on constate que leur part a atteint 10% depuis 2010 environ, alors qu'elle était de l'ordre de 1% ou 2% dix ans plus tôt.

Cette tendance se retrouve dans d'autres pays occidentaux, notamment aux États-Unis.
Ce phénomène ne se retrouve pas dans les pays asiatiques, par exemple en Malaisie où l'on retrouve à peu près autant d'hommes que de femmes dans les départements d'informatique.

Organisations et initiatives Pourquoi des initiatives spécifiques / non-mixtes ?

Lorsqu'on parcourt les différentes interventions qui traitent de la façon d'inciter plus de femmes à collaborer au libre, des lignes de force apparaissent et notamment :

  • l'ambiance exclusive générée par l'entre-soi qui rend peu propice l'arrivée d'une femme dans la communauté
  • les contraintes sur le rythme de travail différencié entre femmes et hommes qui empêchent les femmes de mener un projet sur le long terme de façon continue ; ceci fait écho à la répartition sexuée des rôles dans le couple
  • la préférence des femmes pour un travail étroitement collaboratif, ainsi que pour une organisation moins hiérarchisée et moins imprégnée de compétition.

Liens :

Cette liste n'est pas exhaustive mais permet de mettre en évidence quelques-uns des obstacles à la participations des femmes dans le libre. Ceux-ci sont de natures diverses et tiennent tout autant à une organisation du travail qu'à des mentalités, des comportements, une culture.

Toutes ces raisons amènent à former des groupes non-mixtes et/ou avec des règles de conduites qui garantissent une ambiance de travail plus sereine.

Recensement d'organisations et d'initiatives visant à promouvoir la participation des femmes dans les domaines scientifiques et l'ingénierie En sciences

Diverses initiatives ont pour but de :

  • rendre visibles les disparités des situations dans le milieu scientifique selon le genre (par exemple, le Centre National de la Recherche Scientifique, CNRS publie des statistiques genrées montrant la répartition hommes/femmes selon les métiers, les hiérarchies ainsi que les différences de salaires. Il organise également des journées thématiques)
  • encourager les jeunes filles à poursuivre des études scientifiques ( Nota : la contraposée n'est pas vraie: à ce jour, il n'y a pas ou peu d'incitation à masculiniser les métiers féminisés. Pourtant des secteurs comme les métiers liés à la petite enfance auraient beaucoup à gagner à une égale représentation des genres: cela donnerait aux enfants un modèle d'éducation et de soin plus diversifié et améliorerait les conditions de travail des hommes y travaillant, car les préjugés et les réticences à leur encontre sont forts.)

Il existe ainsi des bourses d'études ou de projets dédiées aux femmes scientifiques.

Parmi ces initiatives :

En info

Parmi les initiatives concernant l'informatique, on notera l'Ada Lovelace Day lancé par Suw Charman-Anderson. Il s'agit, par un hommage notamment à Ada Lovelace, de faire reconnaître la place des femmes dans l'histoire et l'actualité de la discipline. En effet, depuis la masculinisation de l'informatique, les femmes n'y sont même pas visibles à hauteur de leur participation.

Systers, actif depuis 1987, est un forum regroupant les informaticiennes impliquées dans les aspects techniques de l'informatique, leur permettant de s'entraider. Il compte 4000 membres, de tous âges et tous niveaux; elles y organisent une entraide technique, mais aussi professionnelle, sur les relations dans le milieu de travail, ou la meilleure façon de conduire sa carrière.

On trouve désormais dans les principaux projets libres des groupes féminins. Debian women par exemple est une initiative relativement ancienne pour le libre (c'est-à-dire récente). Elle date de mai 2004 et « cherch[e] à équilibrer et diversifier le projet Debian en contactant les femmes intéressées et en les encourageant à s'impliquer davantage dans Debian ». On retrouve aussi PyLadies, Fedora women ou encore KDE women. Les activités de ces divers groupes prennent différents aspects.

Face aux difficultés que rencontrent les femmes dans ce milieu, ces groupes ont mis en place plusieurs types d'actions :

  • codes de conduite mis en place avec les communautés pour les rendre moins hostiles aux femmes,
  • lobbying pour la présence de femmes dans les conférences et actions publiques
  • interventions dans des conférences, et sensibilisation à la place des femmes dans le monde du logiciel libre: ainsi, la proportion d'oratrices à pyCon, la conférence Python la plus importante est passée de 1% en 2011 à 33% en 2014,
  • accueil des contributrices débutantes, orientation et aide technique,
  • gratifications financières pour les contributrices, par exemple avec le programme Gnome Outreach for Women.
Conclusion : quels enjeux?

Les enjeux sont importants et variés. La liste qui vient est subjective et partielle, il ne tient qu'à vous de la compléter.

  • stratégiques: accueillir plus de femmes dans le libre c'est agrandir la communauté, donc mieux diffuser ses idées et lui donner plus de poids
  • éthiques: la communauté a vocation à accueillir tout le monde, ou plutôt de n'exclure personne
  • sociaux: la mixité a un impact sur l'ambiance dans les collectifs de travail, elle permet d'apporter des éclairages différents sur les sujets et sur la méthodologie comme le soulignent les différents blogs à ce propos.

On peut également lire le deuxième chapitre de cette publication de l’Agence nationale pour l'amélioration des conditions de travail (ANACT) à ce sujet.

  • La faible représentation des femmes dans le logiciel libre et plus largement dans l'informatique pérennise les stéréotypes sexistes qui sont à la fois une cause et une conséquence de la désaffection des femmes pour ce domaine.

On retrouve une observation faite par Françoise Héritier au cours de ses travaux en anthropologie : dans toutes les sociétés observées, l'outil est exclusivement fabriqué par les hommes, même s'il est utilisé par les femmes. C'est aussi un enjeu de pouvoir et on comprend qu'il soit difficile d'y renoncer : ce mécanisme est symétriquement à l'œuvre dans les métiers liés à la petite enfance, comme en témoignent les travaux de Nicolas Murcier et de Yves Meunier et Daniel Chetoui

  • démocratiques : cela rejoint le premier point. Minorer les femmes dans un domaine, c'est non seulement se priver de points de vue originaux, mais aussi les priver de la possibilité de prendre la parole sur des sujets qui concernent la société dans son ensemble ; c'est donc ne pas prendre en compte les attentes particulières qu'elles pourraient avoir. Si les idées défendues par le libre ne leur sont pas connues, comment pourraient-elles se former une opinion éclairée sur les enjeux qui traversent tout le secteur du numérique?

À ce propos : ce sera le 70ème anniversaire du droit de vote des femmes en France en avril 2014, utilisé effectivement le 29 avril 1945.

Quelques chiffres :

  • 5,6% de femmes à l'assemblée nationale française en 1947, 5,7% en 1993, ce qui motive la mise en place des quotas.
  • En 1997 il y a 90% d'hommes parmi les députés et en 2014 ils représentent 75% des députés.
Bibliographie Sur l'informatique et le genre
  • Isabelle Collet: l'informatique a-t-elle un sexe?
  • Thomas J Misa: Gender Codes
Ouvrages plus généraux Télécharger ce contenu au format Epub

Lire les commentaires

Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1)

Vendredi 7 Mars

«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.

Dans l'épisode 09, on a vu comment C++11 procurait des constructions bien pensées qu'on pouvait utiliser dans les systèmes à entités. Cette fois, on attaque dans le dur à travers un double épisode qui va nous permettre de générer une carte pour du RPG. Dans la première partie, on va voir comment générer une «carte d'altitude» (heightmap). On va passer en revue plein de techniques qui permettent d'arriver à ce résultat. Avec tout plein d'images pour illustrer. Attention les yeux !

Sommaire Généralités sur les cartes d'altitude

Une carte d'altitude est une image en niveaux de gris qui indique la hauteur d'une surface virtuelle représentant un terrain de jeu. Généralement, le noir indique une altitude basse et le blanc indique une altitude haute. En pratique, on utilise une matrice où chaque case de la matrice représente un pixel de la carte. La matrice contient généralement un flottant, normalisé entre 0 et 1, ou entre -1 et 1. Chez moi, ça sera entre 0 et 1.

Les cartes en niveaux de gris, c'est marrant mais pour vous en mettre vraiment plein les yeux, je vais plutôt générer des cartes en couleur en utilisant le gradient suivant (0 à gauche, 1 à droite, le niveau de la mer étant à 0,5) :

Trouver un gradient correct est assez difficile. Et ce n'est pas mon sens du graphisme inné qui m'aide beaucoup. J'ai récupéré ce gradient sur un site, j'aurais pu en choisir d'autres mais je les trouvais moins jolis. Si vous avez des talents pour améliorer ce gradient, n'hésitez pas à apporter votre aide.

L'idéal quand on génère ce genre de carte, c'est de pouvoir l'affiner à l'envie. En pratique, on essaie de générer un terrain fractal, c'est-à-dire un terrain qui présente un comportement fractal. Affiner le terrain (en pratique, avoir une carte de plus grande taille) ne va pas changer la physionomie générale du terrain, juste sa précision.

Ensuite, une fois que le processus de génération est en place, on cherche à avoir des cartes intéressantes, c'est-à-dire avec du relief mais qu'on puisse jouer. Pour cela, on va définir deux scores pour nos cartes, le score d'érosion et le score de jouabilité. Ces deux définitions sont issues de l'article Realtime Procedural Terrain Generation de Jacob Olsen, écrit en 2004. C'est un excellent article qui m'a beaucoup servi, notamment pour les algorithmes d'érosion décrits plus loin.

Comment mesurer l'importance du relief ?

Pour mesurer le relief, on utilise le score d'érosion. Le principe est, pour chaque case, de calculer la pente maximale, c'est-à-dire la différence d'altitude en valeur absolue, par rapport aux voisins. On ne considère que les voisins parallèles aux axes, c'est-à-dire les voisins du haut, de droite, du bas et de gauche. Ensuite, on calcule la moyenne de ces pentes et l'écart-type, puis enfin, le coefficient de variation, c'est-à-dire le rapport entre l'écart-type et la moyenne. C'est ce coefficient de variation qu'on appelle score d'érosion.

Un score d'érosion de 0 indique une carte plate. Plus le score est élevé, plus il y a de relief. En pratique, dès qu'on atteint 1, on constate des cartes avec pas mal de relief. Tout au long de cet article, j'essaierai de donner les scores d'érosion des différentes cartes générées pour vous donner un ordre d'idée.

Par exemple, pour la carte du début, le score d'érosion est de 0,970156. On constate qu'elle présente pas mal de relief, avec de grands plateaux qui permettent de délimiter des zones intéressantes.

Comment mesurer la pertinence d'une carte ?

Pour mesurer la pertinence d'une carte, c'est-à-dire sa jouabilité, l'idée est de regarder si les unités peuvent se déplacer et les bâtiments peuvent être placés sans encombre. En effet, on va considérer qu'une pente trop importante ne permet pas aux unités de passer ou aux bâtiments d'être placés. En plus, on considère qu'une unité a une certaine taille, de même que les bâtiments.

En pratique, on va d'abord calculer une carte binaire qui indique les cases qui ont une pente inférieure à Tu, la pente maximale franchissable par les unités, puis on va enlever de cette carte binaire toutes les cases qui ne peuvent pas contenir un carré de côté Nu, la taille des unités. Enfin, on calcule la plus grande zone connectée dans cette carte ce qui donne une carte d'unités. Pour la suite, on a pris Nu=1.

Ensuite, on fait de même avec les bâtiments, on prend une pente Tb maximum (généralement inférieure à Tu parce qu'un bâtiment supporte moins bien la pente) et une taille Nb (généralement supérieure à Nu parce qu'un bâtiment prend plus de place qu'une unité) et on calcule la carte binaire de la même manière, sauf pour la plus grande zone connectée (les bâtiments ne se déplacent pas). Enfin, on garde dans cette deuxième carte les zones accessibles dans la carte d'unité, ce qui donne la carte de bâtiments. Pour la suite, on a pris Nb=9.

Pour calculer le score de jouabilité, on va calculer la proportion de cases accessibles dans la carte d'unités, ainsi que la proportion de cases disponibles dans la carte de bâtiments. Et on va les multiplier par le score d'érosion pour obtenir le score de jouabilité. On comprend alors qu'une carte plate donnera des cartes d'unités et de bâtiments excellente mais un score d'érosion nul. Inversement, si on a trop de pente partout, on aura des cartes d'unités et de bâtiments mauvaises, voire très mauvaises, mais un score d'érosion excellent. Dans les deux cas, le score de jouabilité est mauvais. Il faut donc trouver un compromis entre les deux.

Voici la carte d'unités associée à la carte de début.

Voici la carte de bâtiments associée à la carte du début.

Le score de jouabilité pour cette carte est de 0,233147. Avec un score d'unité de 0,834806 (ce qui signifie que 83% des terres émergées sont accessibles aux unités (NdM : capables de voler ou d'y accéder par la mer, les terrains n'étant pas forcément tous accessibles uniquement par la terre) et un score de bâtiment de 0,287874 (ce qui signifie qu'on peut placer des bâtiments sur 28% des terres émergées), on a une carte tout à fait jouable.

Comment afficher une carte avec du relief ?

Avant de continuer, il faut expliquer que les cartes que je vais présenter sont représentées avec un relief ombré. Ça a l'air simple mais ça ne l'est pas. Sans relief ombré, la carte ressemblerait à ça.

Après beaucoup de recherches, j'ai utilisé l'algorithme simple utilisé dans le tutorial de génération de cartes polygonales d'Amit Patel (Red Blog Games). J'ai juste modifié un peu les couleurs. Plutôt que d'utiliser du gris, j'ai utilisé un jaune très léger pour le côté soleil et un violet très sombre pour le côté ombre. J'ai aussi conservé la convention de la lumière venant du nord-ouest (ce qui est impossible en réalité mais aide à discerner les trous des bosses).

Pourquoi est-ce difficile d'avoir un bon relief ombré ? Parce que sur les cartes réelles, cet ombrage est fait à la main, c'est un art en tant que tel chez les cartographes. Il existe des algorithmes pour le faire automatiquement mais il est difficile de les trouver écrits de manière claire, et leur résultat est souvent moins bon que les tracés à la main. Dans ma longue route à la recherche d'informations, voici quelques liens intéressants sur lesquels je suis tombé.

Tout d'abord, deux sites avec plein d'informations : Shaded Relief et Relief Shading. On y voit plein d'exemples de cartes ombrées à la main. On a également accès à tout un tas d'articles sur les techniques à utiliser, dont beaucoup utilisent le logiciel propriétaire de traitement d'image leader du marché. Pour les allergiques au logiciel propriétaire, Wikipédia francophone propose un tutoriel pour créer un relief ombré avec des outils libres.

Cette petite digression étant finie, passons aux choses sérieuses.

Bruit cohérent

Une carte d'altitude est par nature constituée de bruit cohérent. On peut définir le bruit cohérent comme une fonction (informatique) de Rn dans R avec les propriétés suivantes :

  • les mêmes valeurs d'entrée produisent la même valeur de sortie
  • un petit changement dans les valeurs d'entrée produit un petit changement dans la valeur de sortie
  • un gros changement dans les valeurs d'entrée produit un changement aléatoire dans la valeur de sortie

Dans notre cas, nous voulons produire une carte en deux dimensions (n=2), donc nous nous intéresserons uniquement aux techniques pour produire du bruit en deux dimensions. Beaucoup de ces techniques s'adaptent à des dimensions supérieures.

Parmi les algorithmes de génération de bruit qu'on rencontre souvent, il y a deux grandes classes d'algorithmes :

  • les générateurs à base de bruit de Perlin (au sens large)
  • les générateurs à base de placement de point
Bruit de Perlin

Dans la catégorie bruit de Perlin, je classe toute une série de bruits qui ne sont généralement pas mis sous ce vocable mais qui utilisent globalement une même procédure. Le vrai bruit de Perlin utilise le bruit à base de gradient, comme on le verra par la suite.

La procédure dont je parle est parfois appelée fractional brownian motion, ou fBm pour les intimes. Je l'ai nommée plus simplement fractal.

Elle consiste, à partir d'une fonction de bruit «simple» à combiner plusieurs octaves de différentes amplitudes et de différentes fréquences. Plus précisément, pour chaque octave supplémentaire, on divise par deux l'amplitude, on multiplie par deux la fréquence, et on additionne toutes ces octaves.

On peut appliquer cette technique à plusieurs types de bruit que nous allons détailler.

Bruit à base de valeur (value noise)

Le principe du bruit à base de valeur est simple. On génère une grille dont les coordonnées entières contiennent une valeur aléatoire fixe. Ensuite, pour un point (x,y), on regarde dans quelle case de la grille se trouve le point (éventuellement en répétant la grille de valeurs), puis on détermine les coordonnées (rx,ry) de ce point dans la case (c'est-à-dire qu'on enlève la partie entière de chaque coordonnée).

Ensuite, on effectue plusieurs interpolations avec les quatre points situés aux coins de la case de la grille correspondante. On fait d'abord une interpolation entre la valeur en A et la valeur en B avec comme coefficient rx, puis entre la valeur en D et la valeur en C avec la valeur rx, puis enfin entre les deux valeurs obtenues avec la valeur ry.

Comment interpoler deux valeurs ? Généralement, on utilise une interpolation linéaire. On utilise une fonction appelée traditionnellement lerp, définie de la manière suivante :

double lerp(double v0, double v1, double t) { return v0*(1-t)+v1*t; }

Pour t=0, on aura v0 et pour t=1, on aura v1. Et entre les deux, on aura une valeur intermédaire. Mais dans le cas de bruit, ça ne donne pas de beaux résultats. On va donc lisser la courbe d'interpolation et utiliser une fonction qu'on va appliquer à t :

double lerp(double v0, double v1, double t) { t = g(t); return v0*(1-t)+v1*t; }

On va choisir la fonction g pour qu'elle ait de bonnes propriétés. En particulier, si on ne veut pas d'angles, on va plutôt choisir une fonction dont la dérivée en 0 et en 1 est nulle. Si on prend une fonction polynômiale alors, on tombe sur un polynôme de degré 3 : -2 x3 + 3 x2. Si on veut en plus que la dérivée seconde soit nulle en 0 et en 1, on tombe sur un polynôme de degré 5 : 6 x5 - 15 x4 + 10 x3. On peut aussi choisir une fonction trigonométrique comme (1 - cos(pi * x)) * 0.5 mais cette fonction se rapproche beaucoup de notre polynôme de degré 3. Voici l'ensemble de ces fonctions dessinées sur un même graphe :

Voici le résultat sur les mêmes valeurs :

linear cubic quintic cosine

Généralement, le polynôme de degré 3 donne des résultats satisfaisants. On garde donc celui-ci :

Et avec 10 octaves, on obtient une carte tout à fait convenable (score d'érosion : 0,429078) :

Voir l'implémentation du bruit à base de valeur.

Bruit à base de gradient (gradient noise)

Le buit à base de gradient est le vrai bruit de Perlin, décrit dans Making Noise, que Ken Perlin a inventé pour le film Tron et qu'il a par la suite décrit en 1985. C'est une amélioration du bruit à base de valeur. L'idée au départ n'est pas de créer des cartes d'altitude mais des textures. Et de manière générale, on peut appliquer beaucoup des techniques vues ici pour créer des textures procédurales assez bluffantes.

Mais revenons à notre bruit à base de gradient. Par rapport au bruit à base de valeur, on ne définit pas des valeurs (aux coordonnées entières de la grille) mais des vecteurs, également appelés gradients. Ensuite, pour déterminer une valeur aux quatre coins de la case, on calcule un produit scalaire. Pour le point A, on calcule le produit scalaire entre le gradient défini au point A et le vecteur PA. Et pareil pour les trois autres. Enfin, on interpole ces quatre valeurs comme pour le bruit à base de valeurs.

Le résultat est meilleur qu'avec le bruit à base de valeur, où on distinguait bien les contributions des quatre coins. Maintenant, on a des formes plus variées :

Le résultat avec 10 octaves n'est pas mal du tout (score d'érosion : 0,433705) :

Voir l'implémentation du bruit à base de gradient.

Bruit à base de simplexe (simplex noise)

Le bruit à base de simplexe est une évolution du bruit à base de gradient et proposé par le même Ken Perlin. Le problème du bruit à base de gradient est qu'il requiert O(2n) interpolation pour un bruit à n dimensions. Ceci vient du fait qu'on utilise un hypercube qui a 2n sommets. Pour avoir moins de points, on va utiliser un objet à n dimensions qui possède le moins de points possible : c'est ce qu'on appelle un simplexe. En dimension 2, c'est un triangle. En dimension 3, c'est un tétraèdre. Et ainsi de suite. De manière générale, c'est un objet à n+1 points.

Ensuite, l'implémentation proposé par Ken Perlin est assez complexe. La difficulté consiste à calculer le triangle dans lequel on se situe. L'idée est d'appliquer une sorte de transvection qui va transformer nos triangles en demi-carrés. De cette manière, savoir si on est dans le demi-carré du dessus ou du dessous revient à savoir si rx est plus grand ou plus petit que ry. Dernière subtilité, c'est qu'on ne va pas avoir d'interpolations, ni de gradients tirés au hasard. Chaque coin va apporter une contribution qu'on va ajouter les unes aux autres. Ceci est fait pour accélérer la génération.

Au final, le résultat est plutôt convaincant :

Et avec 10 octaves, on observe des artefacts obliques. Je ne sais pas si c'est une erreur dans l'implémentation, mais ça se pourrait parce que ce type de bruit est supposé donner de bons résultats (score d'érosion : 0,452591) :

Voir l'implémentation du bruit à base de simplexe.

Bruit à base de cellule (cell noise)

Dernier bruit de la série, le bruit à base de cellule. Il porte aussi le nom de bruit de Worley (du nom de son inventeur, Steven Worley) ou de bruit de Voronoï (parce que visuellement, on observe un diagramme de Voronoï). L'algorithme général est bien différent de ce qu'on a pu voir jusqu'ici.

L'idée est de générer n points Qi dans l'espace, puis pour un point P, on définit les fonctions Fi qui représentent la distance au i-ème point le plus proche parmi Qi. Ensuite, le bruit est défini par la somme C1 * F1(P) + C2 * F2(P) + … + Cn * Fn(P) où les Ci sont des constantes prédéfinies.

Suivant les constantes qu'on choisit et la fonction utilisée pour la distance, on obtient des résultats assez différents les uns des autres. On a le choix entre prendre la distance euclidienne (distance associée à la norme 2), la distance de Manhattan (distance associée à la norme 1) ou la distance de Tchebychev ou Chebyshev (distance associée à la norme infini).

Examinons d'abord quelques ensembles de constantes classiques. On va utiliser dans ce cas une représentation en niveau de gris, parce que la représentation en couleurs ne rend pas bien. Le choix le plus logique est C1=1 et tout le reste à zéro, c'est là qu'on distingue le mieux le diagramme de Voronoï. Et en fait, on prend plutôt C1=-1 histoire d'avoir des bosses plutôt que des creux. On peut ensuite penser à C2=1 et tout le reste à zéro, ou C3=1 et tout le reste à zéro, et on voit apparaître des formes assez originales. Mais en fait, on obtient de bons résultats avec C1=-1 et C2=1 où on a l'impression d'avoir des collines les unes à côtés des autres. La distance utilisée est la distance euclidienne.

C1=-1 C2=1 C3=1 C1=-1, C2=1

Pour la suite, nous prendrons C1=-1 et C2=1. Et nous allons voir l'influence de la distance.

euclidean manhattan chebyshev

On constate que les distances de Manhattan et de Tchebychev produisent des formes très géométriques, avec des artefacts horizontaux et verticaux très présents.

Si on représente la combinaison gagnante en grand, ça donne :

Et on peut évidemment appliquer une fractale (score d'érosion : 0,386916). À noter que pour ces deux cartes, j'ai placé le niveau de l'eau à 0,1 plutôt que 0,5, et j'ai ajusté l'échelle présentée au début, sinon la majorité de la carte est sous l'eau.

Il faut faire attention à l'implémentation pour que la fractale marche bien et ne donne pas des trucs horribles. Il faut en fait répéter nos points à l'infini de manière virtuelle de manière à avoir une continuité dans le bruit, sinon les discontinuités apparaissent et on n'a pas un bruit cohérent. La conséquence, c'est que notre texture peut se répéter également (le haut joint avec le bas et la gauche joint avec la droite) et ça se voit assez clairement.

Voir l'implémentation du bruit à base de cellule.

Méthodes à base de placement de point

Voilà pour les méthodes à base de bruit de Perlin. Passons maintenant aux méthodes à base de placement de point. Il y en a deux, et la seconde est une amélioration de la première. La particularité de ces méthodes est qu'elles génèrent des cartes de tailles 2k+1. Pour avoir des tailles arbitraires, on génère une carte plus grande de la bonne taille et on prend une sous-partie de ce qui a été généré.

Déplacement du point médian (Midpoint displacement)

La première méthode s'appelle le déplacement du point médian. Elle est assez simple à décrire. On part d'un carré pour lequel on a défini quatre valeurs aux coins. Puis, on fait la moyenne des quatre coins, à laquelle on ajoute une petite variation proportionnelle au côté du carré, et cela définit la valeur du centre du carré. Reste alors à compléter les quatre carrés par quatre points, chaque point étant entre deux points du carré initial pour lesquels on va faire la moyenne et ajouter à nouveau une petite variation. Puis on recommence récursivement sur ces quatre carrés jusqu'à arriver à un pixel.

On obtient ce genre de carte (score d'érosion : 0,385764)

Le résultat montre des artefacts horizontaux et verticaux bien visibles. C'est la raison d'être de la méthode suivante.

Voir l'implémentation du déplacement du point médian.

Diamant-Carré (Diamond-Square)

La seconde méthode s'appelle l'algorithme du diamant-carré. Elle ressemble à la précédente mais elle est partagée en deux phases : la phase diamant et la phase carré. Pendant la phase diamant, on procède comme précédemment, on fait la moyenne des quatre coins, à laquelle on ajoute une petite variation proportionnelle au côté du carré, et cela définit la valeur du centre du carré. Puis on passe à la phase carré pour définir les quatre derniers points. La différence par rapport à précédemment, c'est qu'on utilise pas seulement les points du carré initial mais aussi les points des centres des carrés adjacents. La phase diamant a créé des diamants et chacun des points restants est donc au centre d'un de ces diamants, donc on utilise les quatre coins du diamant pour recréer des carrés en faisant la moyenne, à laquelle on ajoute une petite variation proportionnelle au côté du carré. Ainsi, on a partagé notre carré initial en quatre carrés et on peut appliquer la même méthode récursivement.

Et voici le résultat (score d'érosion : 0,382071)

L'impression visuelle est bien meilleure. Les artefacts ont complètement disparu. Cette carte servira de base pour la section suivante de cet épisode.

Voir l'implémentation de l'algorithme diamant-carré.

Autres méthodes

À côté de toutes les méthodes décrites précédemment et qui sont assez standard, il existe d'autres méthodes qu'on arrive à débusquer au hasard de la navigation. En voici une qui construit une carte à base collines. L'idée est de générer des collines, c'est-à-dire des demi-sphères de manière aléatoire. On les accumule et ça donne des formes assez sympas même s'il y a des artefacts visibles (score d'érosion : 0,480934).

Voir l'implémentation de l'algorithme des collines.

Modification de la carte

Maintenant qu'on a de jolies cartes, on va les modifier. En effet, ces cartes rendent bien mais elles n'ont pas forcément les bonnes caractéristiques. En particulier, aucune des cartes présentées précédemment n'a un score de bâtiments non-nul, ce qui signifie qu'elles ont toutes des pentes beaucoup trop importantes. Si on veut qu'elles s'approchent d'un relief réel ou qu'elles soient plus lisses, on peut appliquer divers filtres que je vais vous présenter.

Érosion

Pour rendre une carte plus réaliste, la première technique est de simuler de l'érosion. Voici trois techniques, présentées dans l'article Realtime Procedural Terrain Generation.

Érosion thermique

La première technique permet de simuler une érosion thermique. L'érosion thermique est celle qui provoque des éboulements. À cause de l'action des températures, le sol va se fissurer, puis s'effriter puis s'effondrer et va glisser si la pente le permet. On simule cette érosion de la manière suivante : pour toutes les cases, on regarde si la pente est supérieure à une limite fixée, puis si c'est le cas, on enlève une fraction de matière de la case qui va s'accumuler sur les cases adjacentes les moins élevées. On répète ce processus un certain nombre de fois et voilà ce qu'on obtient (score d'érosion : 0,475935).

On observe le tassement surtout sur les côtes qui ont pris un peu d'embonpoint.

Voir l'implémentation de l'érosion thermique.

Érosion hydraulique

La seconde technique permet de simuler une érosion hydraulique. L'érosion hydraulique est dûe à l'action de la pluie et du phénomène de sédimentation. On le simule avec quatre étapes. Première étape, de l'eau tombe du ciel uniformément sur le terrain. Deuxième étape, une partie du matériel présent sur le terrain se dissout dans l'eau. Troisième étape, l'eau ruisselle sur les pentes. Quatrième étape, l'eau s'évapore et le matériel qu'elle transportait se dépose au sol. De la même manière qu'avant, on répète ce processus un certain nombre de fois et voilà ce qu'on obtient (score d'érosion : 0,446365).

Malgré un temps de calcul bien plus élevé que pour l'érosion thermique, les différences sont assez imperceptibles visuellement. L'article montre qu'en fait, l'érosion thermique aplanit les zones à peu près plates et renforce les pentes, ce qui accroît le score d'érosion.

Voir l'implémentation de l'érosion hydraulique.

Érosion rapide

On a donc une technique rapide mais qui aplanit les pentes, et une technique lente qui renforce les pentes. Et on aimerait bien un mélange, c'est-à-dire une technique rapide qui renforce les pentes. Pour ça, un nouvel algorithme, appelé fast erosion, a été développé par l'auteur de l'article. Il reprend le principe de l'érosion thermique mais plutôt que de considérer des éboulements quand la pente est forte, il considère des éboulements quand la pente est faible. Et le résultat est conforme à celui qui était voulu. Voici le résultat (score d'érosion : 1,271748).

On constate bien que le résultat diffère vraiment de l'original. On voit bien de grandes zones planes apparaître. Et pour la première fois depuis le début, on a un score de bâtiment non nul sans être démentiel (score de bâtiment : 0,032020).

Voir l'implémentation de l'érosion rapide.

Transformation en île

Une des caractéristiques voulues pour un jeu vidéo est que l'univers de jeu doit être limité. Et pour cela, la méthode la plus courante, en particulier dans les RPG, est de jouer sur une île. Jusqu'à présent, notre terrain n'était pas une île. Nous allons voir deux techniques pour transformer un terrain quelconque en île.

Par les bords

La première technique, que j'ai imaginée moi-même (pour une fois), consiste à replier les bords de la carte. Mais pas n'importe comment. Si on applique un facteur linéaire en fonction de la distance au bord, on obtient des côtes droites. Sans compter que ça peut créer une discontinuité là où on a commencé à appliquer le repliement. J'ai donc essayé plusieurs fonctions.

J'ai commencé par la racine carré qui donnait des résultats plutôt satisfaisants mais on observait toujours cette discontinuité à la limite du repliement. Il me fallait donc une fonction qui ait une dérivée nulle en 1 (ce n'est pas obligatoire en 0, puisque c'est le bord de la carte donc la discontinuité ne se voit pas). Et là, on pense de suite à une fonction trigonométrique et en l'occurrence, sinus qui présente le bon profil. Le résultat commençait à devenir intéressant même si on observait des côtes droites. Cela vient du fait que la pente de la courbe sinus est supérieure à 1, ce qui fait que de petits changements sur la carte d'origine sont complètement occultés. L'idéal est donc d'avoir une pente inférieure à 1 mais un truc genre sinus. Et donc, j'ai combiné le sinus et la racine carrée pour obtenir le résultat que je souhaitais.

Voir l'implémentation de la transformation en île par les bords.

Par le milieu

La seconde technique, qui m'a été inspirée, consiste à multiplier notre carte par une fonction gaussienne en deux dimensions, la fameuse cloche. Simple, efficace, on peut également régler l'écartement pour ajuster l'île comme on le souhaite. Le principal inconvénient est que ça force quand même les îles à avoir une forme… de cloche.

Voir l'implémentation de la transformation en île par le milieu.

MapMaker

MapMaker est un logiciel que j'ai concocté pour expérimenter toutes ces techniques. Il permet à partir d'un fichier YAML de décrire un pipeline d'algorithmes, en partant d'un générateur puis en appliquant des modificateurs et enfin éventuellement un finaliseur.

Actuellement

Actuellement, toutes les techniques décrites ici ont été implémentées et fonctionnent (enfin, j'espère). MapMaker produit des fichiers au format portable pixmap qui a l'avantage d'être facile à générer même s'il n'est pas très optimal. Ensuite, convert est votre ami. Vous pouvez d'ailleurs voir les fichiers correspondant à tous les exemples présentés dans cet épisode si vous voulez une idée de comment ça se présente en vrai.

Pour la carte du tout début, j'ai commencé par la carte issue du diamant-carré. Puis j'ai appliqué une érosion rapide, puis un léger aplatissement (flatten) qui a tendance à creuser les vallées et que j'ai piqué ailleurs. Ensuite, j'ai appliqué un peu d'érosion thermique, histoire de créer des passages entre les plateaux créé par l'érosion rapide. Puis un petit lissage (smooth) qui est le lissage trivial que l'on fait en traitement d'image. Enfin, j'ai transformé mon terrain en île, en utilisant l'algorithme par les bords. Bon, on peut sans doute faire mieux, et j'ai tâtonné pour arriver à ce résultat, mais ça me convient.

Je n'ai pas cherché à optimiser la vitesse de génération ou la taille des cartes. Quand on manipule des cartes de 512x512, composé de double, ça fait la carte à 2Mio. On peut considérer que c'est beaucoup, ou que c'est peu, suivant le contexte. Pour avoir un ordre d'idée, en utilisant mon laptop de développement (Dell latitude E5530), voici quelques chiffres pour la génération de la carte du début. Pour le temps de génération :

generator: 'diamond-square' size: 513 x 513 duration: 43 ms modifier: 'fast-erosion' duration: 1064 ms modifier: 'flatten' duration: 21 ms modifier: 'thermal-erosion' duration: 19 ms modifier: 'smooth' duration: 6 ms modifier: 'islandize' duration: 11 ms

Ce qui est tout à fait raisonnable. Valgrind me dit que j'utilise un peu moins de 158Mio de mémoire (en cumulé). Là en revanche, ça pourrait être mieux.

Sur la même carte mais en version 8193x8193, c'est-à-dire 256 fois plus grande :

generator: 'diamond-square' size: 8193 x 8193 duration: 8772 ms modifier: 'fast-erosion' duration: 324826 ms modifier: 'flatten' duration: 5662 ms modifier: 'thermal-erosion' duration: 5691 ms modifier: 'smooth' duration: 1920 ms modifier: 'islandize' duration: 3143 ms

Il faudrait faire plus de tests mais ça a l'air de passer à l'échelle de manière linéaire. Je n'ai pas fait de Valgrind mais je pense que en mémoire ça passe à l'échelle également de manière linéaire, ce qui nous ferait dans les 40Gio (en cumulé). Bon d'accord, pour la prochaine version, je vais m'occuper de cet aspect.

Possibilités

Les possibilités d'extension sont nombreuses. Je ne sais pas si je vais les implémenter, mais je les mets ici pour mémoire.

Tout d'abord, on peut expérimenter des bruits plus récents, tel que le wavelet noise (qui a quand même l'air assez difficile à implémenter). On peut aussi expérimenter des méthodes alternatives de génération ou de modification si on a beaucoup d'idées.

La limite la plus visible, c'est le pipeline. En vrai, on aimerait bien avoir un graphe d'opérateurs qu'on pourrait manipuler et brancher à travers une interface graphique. Et bien, bonne nouvelle, ce genre d'outil existe ! Ça s'appelle World Machine mais malheureusement, c'est propriétaire. Mais ça permet de faire des choses assez complexes. Je dois avouer que je n'ai pas les capacités pour faire ce genre de choses, je suis parfaitement inexpérimenté en interface graphique, mais, il existe des tutoriaux pour Qt5 qui pourraient servir de base.

Bon, mais c'est bien gentil ces cartes d'altitude, mais pour l'instant, ce n'est pas très exploitable en l'état. C'est l'objet de la deuxième partie de cet épisode : voir comment transformer une carte d'altitude en un truc jouable. Et du coup, je pourrai remplacer ma vieille île toute pas belle en quelque chose de plus joli. Mais ça, ça sera la prochaine fois (et ça sera sans doute moins long) !

Pour aller plus loin

Pour finir, voici quelques liens pour ceux qui veulent aller plus loin.

Tout d'abord, je ne saurais trop vous conseiller d'aller voir la libnoise. La bibliothèque en elle-même est un peu vieille et l'implémentation est faite pour du bruit 3D, ce qui n'est pas toujours adapté pour du bruit 2D (ça complexifie et ça alourdit les calculs). Mais les tutoriaux sont très pédagogiques pour bien comprendre ce qu'est le bruit cohérent. De même que l'exemple d'une planète complète construite avec de multiples générateurs et modificateurs.

Pour ceux qui ne maîtrisent pas la langue de la perfide albion, il y a le tutoriel de Jérémy Cochoy qui est très bien fait. Il décortique le bruit de Perlin mais aussi le bruit à base de simplexe. C'est très progressif, il y a beaucoup d'illustrations, bref, un bon point d'entrée.

Notons aussi le projet Fractal Terrain Generation sur Google code qui, à défaut de fournir beaucoup de code, a un excellent wiki avec des explications sur comment implémenter divers types de bruit ainsi que les méthodes à base de placement de point.

Enfin, pour tout savoir sur la notion de bruit, il y a toujours le tutoriel du Red Blog Games qui vous fera voir du bruit de toutes les couleurs. Le même Red Blog Games fournit également un tutoriel pour la création de cartes polygonales dont j'ai déjà parlé mais qui est un véritable délice.

Télécharger ce contenu au format Epub

Lire les commentaires

Retrouvez « Les Ateliers Python » de l'AFPy, au NUMA de Paris, lundi 24 mars à 19h

Jeudi 6 Mars

Le lundi 24 mars 2014, de 19h00 à 22h00, l'AFPy organise un évènement au NUMA (39 rue du Caire, 75002 Paris, https://www.numaparis.com/). Cette première édition consiste en 4 présentations de 20 minutes chacune autour du thème :

Python pour DevOps : Ansible & SaltStack

Au programme :

19:00 — Présentation #1 (20 minutes + questions)

« Commencer petit : Ansible et Vagrant, une recette simple. »
par Mathieu Lecarme

19:30 — Présentation #2 (20 minutes + questions)

« Scaler avec Ansible : Faire évoluer son architecture. »
par Mathieu Lecarme

20:00 — Pause et annonces de l'Afpy

20:15 — Présentation #3 (20 minutes + questions)

« Notre boîte à outils Saltstack : déploiements, compilations et tests automatisés, clefs privées, réseau. »
par Feth Arezki, avec Julien et Gaston

20:45 — Présentation #4 (20 minutes + questions)

« Utilisations avancées de Salt: QA, supervision, Test-Driven Infrastructure. »
par Nicolas Chauvat

21:15 — Mise en pratique et discussions autours d'un apéro

22:00 — Fin

Inscriptions sur le site du NUMA :
https://www.numaparis.com/Evenements/Python-pour-DevOps-Ansible-SaltStack

Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs, qui combine le déploiement de logiciels multi-nœuds, l'exécution des tâches ad-hoc et la gestion de configuration. Ansible gère les différents nœuds par SSH et ne nécessite l'installation d'aucun logiciel supplémentaire. Les modules communiquent avec JSON et la sortie standard et peuvent être écrits dans n'importe quel langage de programmation. Les descriptions réutilisables de systèmes sont exprimées en YAML (via wikipedia)
En savoir plus : http://www.ansible.com/

Saltstack est un environnement libre d'exécution distribué et asynchrone, qui fonctionne sur toutes les plateformes (Unix, MacOS, Windows, embarqué, etc.) avec une empreinte mémoire réduite. Qu'il s'agisse d'exécuter une commande sur plusieurs machines, de définir puis appliquer une configuration système, de récolter les mesures faites par des sondes, de lancer des machines virtuelles ou de gérer un "cloud": Salt a une solution.
En savoir plus : http://www.saltstack.com/

Python est un langage de programmation. Il favorise la programmation impérative structurée et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions. Le langage Python est placé sous une licence libre proche de la licence BSD1 et fonctionne sur la plupart des plates-formes informatiques, des supercalculateurs aux ordinateurs centraux, de Windows à Unix en passant par Linux et Mac OS, avec Java ou encore .NET. Il est conçu pour optimiser la productivité des programmeurs en offrant des outils de haut niveau et une syntaxe simple à utiliser. Il est également apprécié par les pédagogues qui y trouvent un langage où la syntaxe, clairement séparée des mécanismes de bas niveau, permet une initiation plus aisée aux concepts de base de la programmation. (via wikipedia)
En savoir plus : http://python.org

L’AFPy (Association Francophone Python) est une association à but non lucratif dont les objectifs sont la promotion du langage Python et la création d'une communauté autour de cet outil, dans l'esprit des logiciels libres. Cette association est née du regroupement de personnes de la communauté Python et Zope francophone. Elle a pour vocation de s'adresser à tous les utilisateurs francophones.
La promotion du langage Python est faite à travers :
* L'animation d'un site web communautaire ;
* Le soutien aux projets de logiciels libres développés en Python ;
* L'organisation d'évènements nationaux et régionaux ;
* La participation des membres à diverses conférences ;
* La traduction de la littérature Python en français ;
* La création de documentations techniques ;
* Ce que vous y apporterez.
En savoir plus : http://www.afpy.org

Télécharger ce contenu au format Epub

Lire les commentaires

Encore un exemple de code spaghetti : Toyota

Jeudi 6 Mars

Après plusieurs journaux récents concernant des histoires de mauvaises pratiques de code dans des logiciels de sécurité (goto fail pour Apple et goto cleanup pour GnuTLS, divers patchs monolignes erronés), nous avons maintenant une histoire où de mauvaises pratiques de code dans de l'embarqué ont entraîné un accident grave.

Toyota a mis en vente en 2005 sur le marché son modèle Camry, dont le moteur est contrôlé par de l'électronique et du logiciel. Par exemple la pression sur la pédale de frein est détectée par un capteur que le système doit analyser pour commander le freinage.

Un jour lors d'un freinage périlleux le freinage électronique a échoué, entraînant un accident qui a coûté la vie à la conductrice et blessé gravement son amie.

Dans un procès fait à Toyota, deux experts en embarqué ont donné leur avis sur le code source que Toyota avait utilisé dans sa voiture. C'était du code très sale, comme vous pouvez le voir dans la suite de cette dépêche.

NdM : merci à Zarmakuizz pour son journal.

Sommaire Goto ?

Plusieurs journaux récents dénonçaient de mauvaises pratiques de code, en tapant à tort ou à raison sur l'utilisation du goto en C. Voir par exemple ce journal sur une faille chez Apple ou celui sur un patch de GnuTLS.

L'affaire Toyota

Voici maintenant une affaire où les freins d'une Toyota ont refusé de fonctionner à cause d'un code spaghetti.

Résumé

L'article en anglais est très long, ça date du 13 novembre 2013, je vais tenter un résumé :

Jean Bookout et Barbara Schwarz avaient une Toyota Camry de 2005. Le système de freinage est contrôlé par l'électronique du système. Mais voilà qu'un jour Jean Bookout perd le contrôle de sa voiture, la pédale de frein n'a aucun effet sur la vitesse de la voiture. Qu'à cela ne tienne, elle utilise donc le frein à main, ce qui fait une grosse marque de dérapage sur la route mais la vitesse du véhicule ne diminue pas, eeeeeeeet c'est le crash. Barbara Schwarz meurt des blessures, Jean Bookout se retrouve à l'hôpital pendant 5 mois.

Procès

Suite logique, procès à Toyota. Bon, on est aux États-Unis, on ne sait pas si c'est uniquement sur les raisons techniques évoquées plus loin ou aussi par patriotisme que les jurés ont déclaré Toyota coupable dans l'affaire, mais passons ce détail pour nous concentrer sur la suite.

 Mais comment les freins ont pu ne plus marcher ?

Deux experts ont été désignés par l'accusation pour analyser le code source de Toyota et juger par eux-mêmes d'où pouvait provenir la défaillance. Michael Barr est resté 20 mois dans une salle semblable à une chambre d'hôtel, avec des gardes pour s'assurer qu'aucun document ne rentre ou ne sorte de sa salle pendant tout le temps de son analyse. Phillip Koopman est plutôt à l'aise dans le domaine de l'embarqué.

On peut résumer le reste de l'article en « c'est un gros code spaghetti impossible à maintenir, impossible à prédire, impossible à tester, des corruptions de mémoire arrivent trop facilement, etc. » Mais il y a quand même quelques perles :

There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you’re likely to create a new bug in the process. Just because your car has the latest version of the firmware — that is what we call embedded software — doesn’t mean it is safer necessarily than the older one….And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.

Even a Toyota programmer described the engine control application as “spaghetti-like” in an October 2007 document Barr read into his testimony.

Ce qui donnerait en bon françois :

Il y a un grand nombre de fonctions beaucoup trop compliquées. D'après les métriques standards de l'industrie, certaines fonctions sont impossibles à tester, signifiant que leur fonctionnement est tellement compliqué qu'il n'est pas possible de développer une suite de tests fiable ou d'avoir une méthodologie de test pour vérifier tout ce qui se passe à l'intérieur. Certaines sont tellement compliquées qu'on peut les qualifier d'impossibles à maintenir, ce qui veut dire que si vous rentrez dedans pour corriger un bug ou faire un changement, vous êtes assuré de créer un nouveau bug au passage. Ce n'est pas parce que votre voiture a la dernière version d'un _firmware_ (c'est ce qu'on appelle du logiciel embarqué) que c'est nécessairement plus fiable que le _firmware_ plus ancien… Et la conclusion de cela est que les sécurités [employées] sont inappropriées. Les sécurités employées ici contiennent des défauts ou des lacunes. Mais dans l'ensemble, l'architecture de sécurité est un château de cartes. Il est possible d'avoir une majeure partie des sécurités désactivées au moment où le contrôle de l'accélération est perdu. Même un programmeur de chez Toyota a décrit l'application de contrôle du moteur comme « du code spaghetti » dans un document d'octobre 2007 que Barr a cité dans son témoignage. Violation des règles de programmation

La suite de l'article parle de règles de bonne pratique définies par le MISRA pour le développement en C dans l'automobile. Phillip Koopman dit que pour chaque pack de 30 violations de ces règles, on peut s'attendre à 3 bugs mineurs et 1 bug critique en moyenne. Michael Barr a analysé le code en suivant l'édition 2004 de la MISRA (rappel, la voiture date de 2005) et a trouvé… 81 514 violations. D'après les statistiques moyennes, on devrait donc s'attendre à environs 2720 bugs majeurs. Les programmeurs de Toyota ont défini leurs propres règles de bonne conduite et n'ont pas réussi à les respecter. Il y avait aussi plus de 10 000 variables globales, alors que les standards dans les développements de l'automobile réclament le 0 absolu. Le programme superviseur censé détecter si les tâches du moteur tournent toujours était incapable de détecter quoi que ce soit car il se contentait de monitorer le CPU, ce qu'il n'arrivait même pas à faire ! Les codes d'erreurs renvoyés par les tâches étaient complètement ignorés, aucune traçabilité n'était possible.

Code revu par la Nasa

La NASA était censée passer le code en revue, sauf qu'apparemment le code qu'on leur a donné n'était pas le code applicatif final, et des délais trop courts ont empêché les ingénieurs de la NASA de faire leur travail d'inspection. Des mails de Toyota relatent qu'ils ont mis en place des sécurités contre les erreurs de Bit flipping alors que Michael Barr n'a vu absolument aucun contrôle de ce côté-là. La NTHSA, l'entité ayant autorisé la mise sur le marché de la Toyota Camry, n'avait donc pas les informations nécessaires pour savoir que la partie informatique du véhicule était complètement foireuse.

Éclairante démonstration

Michael Barr a dû expliquer à un jury non compétent pourquoi tout ce qu'il a trouvé est un problème, ce qui fait donc d'excellentes ressources pour les étudiants et autres curieux :

[Barr's slides are] long, but well worth a read for anyone interested in understanding more about embedded software systems in automobiles and how not to design one; where NHTSA went wrong: and the unbelievably shaky software at the foundation of Toyota’s electronic architecture.

Soit en français :

[Les diapos de Barr sont] longues, mais méritent la lecture pour quiconque est intéressé pour en savoir plus sur les systèmes embarqués en automobile et comment il ne faut pas en concevoir, où est-ce que la NTHSA a eu tort, et le logiciel incroyablement fragile aux fondations de l'architecture électronique de Toyota. ``̀ L'article conclut sur le fait que Toyota n'aurait donc pas voulu que l'on voit son code source, non pas pour garder secret ses algorithmes, mais plutôt pour cacher le fait que c'est un merdier total. Télécharger ce contenu au format Epub

Lire les commentaires

Un poste de travail Xfce complet avec MLED

Jeudi 6 Mars

Le poste de travail MLED (Microlinux Enterprise Desktop) fournit un poste de travail professionnel robuste et complet, basé sur Slackware Linux et l'environnement de bureau Xfce, avec une multitude d'améliorations. Son rôle est de fournir un environnement de production fonctionnel et fiable qui tourne correctement même sur du vieux matériel aux performances modestes. Il est actuellement utilisé dans quelques mairies, médiathèques, écoles et stations radio du sud de la France.

MLED n'est pas une distribution Linux à part. Le projet consiste en une collection de près de 170 paquets logiciels installés sur un système de base Slackware. À chaque tâche correspond une application judicieusement choisie et proprement intégrée.

Télécharger ce contenu au format Epub

Lire les commentaires

Pages