Pour la 44ème semaine de 2016, voici 5 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Dans le Libre : tout automatiser
• L'histoire d'Unicode et son adoption sur le Web
• Nous, les junkies du SaaS
• Rust, un super héros au secours de la bio-informatique ?
• Comment installer et optimiser Apache2 pour les performances

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Dans cette série d’articles consacrés aux usages du Libre et après avoir abordé les principales étapes de la démarche du Libriste pour résoudre un problème (gratter ses propres démangeaisons) par la création puis l’utilisation d’un programme (manger ce que l’on prépare) puis enfin l’automatisation de sa conception et de son déploiement (tout automatiser), nous nous intéresserons à l’une des pratiques les controversées mais aussi des plus efficaces du Logiciel Libre :  la bifurcation (fork en anglais).

Qu’est-ce que la bifurcation et pourquoi s’y intéresser ?

Le bifurcation dans le Logiciel Libre consiste à prendre les sources d’un programme sous licence libre pour créer un nouveau projet indépendant. Si la manœuvre technique en elle-même est le plus souvent assez simple, les motivations et les modalités de réalisation de ladite bifurcation sont nombreuses et les conséquences qu’elle entraîne pour le projet peuvent être importantes. Cette pratique est néanmoins courante et il est important de bien comprendre son rôle dans nos communautés techniques afin de ne pas en avoir peur, de la diaboliser ou pire de nier son rôle ou son efficacité quant elle est bien utilisée.

Les motivations derrière une bifurcation

Les motivations créant le besoin d’une bifurcation sont nombreuses. Pour n’en citer que quelques-unes :

• L’unique mainteneur d’un projet est injoignable
• Un projet accumule des bugs gênants et son mainteneur n’est pas suffisamment réactif ou n’est pas ouvert aux apports d’autres contributeurs
• Des différences de vision quant aux directions d’un projet s’accumulent
• Les points de vue des mainteneurs d’un projet divergent quant à l’ajout d’une fonctionnalité majeure

Et c’est là qu’on commence à sentir l’aspect social qu’entraîne une bifurcation. Car au-delà de la base de code, c’est aussi une communauté existante que la bifurcation va chambouler. Le chambardement est bien sûr très réduit lorsqu’il s’agit d’un projet constitué d’un seul mainteneur, souvent le développeur principal du projet. Mais sur des projets plus larges, une bifurcation peut entraîner le départ de mainteneurs du projet dont vous bifurquez… et donc un appauvrissement des ressources de ce projet. Il s’agit donc d’être sûr que les raisons sont réunies pour réaliser une bifurcation et que les points de vue sont – au moins pour l’instant – irréconciliables.

Un exemple simple vaut souvent mieux qu’un long discours. Je vais donc prendre l’exemple du projet rss2twitter, un outil sous licence MIT codé en Python 2 permettant de transformer les entrées d’un flux RSS en message à destination du réseau social Twitter. Les sources du projet sont présentes sur Github mais le dépôt n’évoluait plus depuis plusieurs années et le mainteneur ne répondait pas aux sollicitations. Le programme fonctionne néanmoins et tenait en quelques centaine de lignes. Souhaitant l’utiliser dans le cadre du Journal du hacker, j’avais donc toutes les raisons nécessaires de ne pas recoder un nouveau projet et de pratiquer une bifurcation pour lancer le nouveau projet Feed2tweet à partir de la base de code de rss2twitter.

Les modalités de la bifurcation

Avant tout, il s’agit de savoir si la licence du logiciel dont vous souhaitez bifurquer autorise cette pratique. Bonne nouvelle, la bifurcation est une des libertés fondamentales du Logiciel Libre, et se retrouve donc dans toutes les licences libres. Les modalités de la bifurcation sont bien souvent définies dans la licence elle-même. Dans les faits, si vous avez communiqué vos motivations aux responsables du projet ou même les avaient rendues publiques, le premier pas est engagé. Une communication auprès de ces mêmes personnes les avertissant de la réalité de la bifurcation permettra que les choses soient claires. À partir de ce moment-là, on distingue en général deux types de bifurcation : amicale et non-amicale.

La bifurcation amicale tend à exploiter une voie qui ne sera pas exploitée dans le futur par le projet amont. Il peut s’agir d’une spécialisation du projet dans un domaine particulier ou de l’introduction d’une modification majeure. On peut prendre l’exemple d’une distribution GNU/Linux et d’une dérivée par exemple spécialisé dans la sécurité et donc beaucoup plus restrictive. Un exemple concret réside dans le moteur du Journal du hacker qui est une bifurcation amicale du moteur du site américain lobste.rs, dont j’ai bifurqué amicalement pour ajouter la gestion d’autres langues dans le moteur car le mainteneur du projet amont n’avait pas le temps de le faire. Il a donc été procédé à une bifurcation amicale afin d’implémenter ces modifications avec comme but de les intégrer plus tard au moteur du projet amont.

La bifurcation non-amicale annonce une rupture dans la continuité du projet. Dorénavant le projet d’origine et sa bifurcation vont évoluer en parallèle, à priori sans plus avoir de liens. La réalité est bien sûr plus complexe, surtout quand des membres du projet d’origine travaillent en parallèle sur les deux projets. Mais en tout cas, la rupture est consommée et rendue public. Les deux projets peuvent évoluer fortement l’un par rapport à l’autre, ou continuer à échanger régulièrement mais en gardant chacun leurs spécificités.

Pour continuer sur mon exemple de Feed2tweet, j’ai largement communiqué autour de la bifurcation et de ses différentes étapes afin d’attirer d’éventuels contributeurs, ce qui a eu pour effet qu’on parle du nouveau projet et en effet d’obtenir quelques contributions et améliorations de la base de code, améliorations toujours bonnes à prendre par rapport à la base de code assez ancienne du projet amont.

Les avantages d’une bifurcation

Bifurquer un projet offre de nombreux avantages par rapport à tenter d’interagir en tant que contributeur au projet d’origine. Parmi les principaux :

• Totale liberté dans la façon de coder et ré-écriture majeure du code possible
• Nouveau leadership au sein du projet
• Possibilité d’introduire rapidement de nouvelles fonctionnalités majeures
• Choix complet de la nouvelle plateforme technique (dépôt de sources, outils de tests, intégration continue, etc)
• Possibilité de critiquer publiquement le projet amont, de montrer les erreurs commises et qu’une alternative est désormais possible
• Changement de la licence si le projet amont utilisait une licence libre très permissive (exemple MIT vers GPL possible)

Donc des arguments à la fois technique et d’organisation. Bien sûr dans le cas d’une bifurcation amicale, certains de ses avantages sont restreints, par à la fois le respect du travail toujours effectué en amont et la volonté d’y introduire certaines fonctionnalités en provenance du projet issu de votre bifurcation.

Pour continuer sur mon exemple de mon projet Feed2tweet, la bifurcation m’a permis à partir d’une base de code de corriger rapidement de nombreux bugs, de rendre modulaire le code, de passer en Python 3 et de changer de licence pour aller vers une licence libre plus restrictive protégeant à mon sens davantage mon travail et celui des futurs contributeurs du projet, en passant de la MIT vers la licence GPLv3, en s’assurant ainsi de ne jamais retrouver légalement mon code dans un logiciel propriétaire, contrairement à ce qui peut arriver lorsqu’on utilise la licence MIT ou BSD.

Les inconvénients d’une bifurcation

Si une bifurcation offre de nombreux avantages et une grande liberté, cette dernière présente néanmoins des inconvénients, qui bien souvent touchent à la fois le projet né de la bifurcation, mais également le projet bifurqué. Parmi ces inconvénients :

• Division des effectifs contribuant à un projet et donc dispersion potentielle des efforts
• Guerre de communication entre les deux projets en cas de bifurcation inamicale pour attirer contributeurs et utilisateurs
• Mauvaise presse et incompréhension des utilisateurs (attaque d’autres communautés, pourquoi le changement de nom, quel est le « bon » projet ?)

Dans l’esprit de membres des communautés du Libre, une bifurcation inamicale est toujours perçue comme à priori comme négative pour les raisons exposées ci-dessus.

La bifurcation comme garde-fou

Nous avons pu voir que les arguments en faveur d’une bifurcation bien effectuée sont nombreux et attirants pour les développeurs d’un projet. Sans faire table rase du passé, la bifurcation va offrir de nombreuses libertés, qu’elles soient organisationnelles ou techniques, permettant de relancer un projet ou d’en créer simplement un nouveau. Évidement elle a aussi de lourds inconvénients, en particulier en terme de visibilité du projet par les actuels et potentiels contributeurs et utilisateurs.

Pourtant et comme vu plus haut, la bifurcation est souvent la seule façon de continuer à faire vivre un projet libre abandonné ou verrouillé par les actuels mainteneurs. Avec de nombreuses entreprises produisant dorénavant des logiciels libres, la bifurcation est le garde-fou assurant la possibilité pour les communautés du Libre de se réapproprier une base de code existante en cas de fermeture de fait du code par non-acceptation des contributions extérieures, base de code à laquelle elle a bien souvent largement participé.

S’il est bien sûr dommage que les mainteneurs et les contributeurs proposant de nouvelles fonctionnalités n’arrivent pas à faire avancer ensemble le projet d’origine dans la bonne direction, la bifurcation représente une issue de secours garantissant un possible renouveau non pas du projet d’origine mais de sa base de code, sous une forme altérée qui prendra peu à peu en tant que nouveau projet une forme propre. Au final, l’utilisateur bénéficiera d’une alternative mise à jour, complétée, certes différente du projet initial qu’il avait connu, mais relancée pour de bon et sorti d’une impasse organisationnelle et technique.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Voici un petit récapitulatif des différents moyens d'utiliser une base de données Redis depuis PHP sous Linux

L'ensemble des tests ont été réalisés sous Fedora 25 mais devrait fonctionner avec RHEL, CentOS ou une autre distribution.

Solution testées:

• Extension redis (voir #1)
• Bibliothèque Predis (voir #2)
• Extension phpiredis (voir #3)
• Bibliothèque Predis avec l'extension phpiredis (voir #4)

 

Pour chaque solution, j'ai utilisé 3 jeux d'essai (lancé une dizaine de fois pour avoir une valeur moyenne)

• connexion et incrément d'une valeur, uniquement pour mesurer le coût de la connexion
• connexion et set / get de 10000 valeurs numériques
• connexion et set / strlen de ~2700 valeurs importantes (l'ensemble des pages de man 1)

1. Extension redis

Composants nécessaires :

• Extension redis
• Paquets RPM: php-pecl-redis

Exemple de code :

connect('127.0.0.1', 6379);
printf("Value = %d\\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\\n", $time);

Résultats :

• Connexion : 0.000299
• Set / get : 0.277000
• Set / strlen : 0.110900

C'est la solution la plus connue est la plus utilisée, j'ai malheureusement de gros doute sur la qualité du code actuel de l'extension.

2. Bibliothèque Predis

Composants nécessaires:

• Bibliothèque Predis
• Paquets RPM: php-nrk-Predis

Exemple de code :

 '127.0.0.1', 'port' => 6379]);
printf("Value = %d\\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\\n", $time);

Résultats :

• Connexion : 0.001890
• Set / get : 0.375500
• Set / strlen : 11.445000

Rien d'étonnant à ce qu'une implémentation pure PHP soit nettement plus lente. C'est évidement le chargement de la bibliothèque qui pénalise la connexion, ensuite l'exécution de requêtes simples (get/set) reste très acceptable.

3. Extension phpiredis

Composants nécessaires:

• Extension phpiredis
• Paquets RPM: php-phpiredis, hiredis

Exemple de code :

Résultats :

Connexion : 0.000241
	
Set / get : 0.288100
	
Set / strlen : 0.105000
Les résultats sont comparables à ceux de l'extension redis.

Il est dommage que cette extension, pourtant ancienne, soit toujours en phase de développement (beta). Le code très simple (~1000 lignes contre ~20000 pour redis), et utiliser la bibliothèque hiredis me semble beaucoup plus sain et maintenable à long terme.

4. Bibliothèque Predis avec l'extension phpiredis

Composants nécessaires:

Bibliothèque Predis
	
Extension phpiredis
	
Paquets RPM: php-nrk-Predis, php-phpiredis, hiredis
Exemple de code :

 '127.0.0.1', 'port' => 6379], ['connections' => ['tcp' => 'Predis\\\\Connection\\\\PhpiredisSocketConnection']]);
printf("Value = %d\\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\\n", $time);

Résultats :

Connexion : 0.001795
	
Set / get : 0.378900
	
Set / strlen : 0.145300
Comme indiqué dans la documentation, la bibliothèque Predis est largement optimisée en utilisant l'extension phpiredis pour les données importantes. Les résultats des tests sont donc très acceptables.

5. Conclusion

À vous de faire votre choix à la lecture des résultats.

J'aurais tendance à privilégier l'extension phpiredis lorsque la vitesse est une priorité absolue, et la bibliothèque Predis pour la beauté du code. Ce couple suivant une rationalisation aussi suivi par d'autres projets (e.g. mongo => mongodb) ou l'extension est réduite au minimum en utilisant une bibliothèque dédiée (ici hiredis) et se charge uniquement de la partie bas niveau, là où les perfornances sont nécessaires, la bibliothèque fournissant la partie haut niveau au développeur.

Je prévois d'aider l'auteur de l'extension phpiredis pour qu'une version soit publié, et si possible sur la forge PECL afin de lui donner la visiblité qu'elle me semble mériter. Alors je soumettrais probablement une revue pour les dépôts officiels de Fedora/EPEL.

 

P.S. le code complet utilisé pour les tests : redis.txt, predis.txt, phpiredis.txt

Original post of Remi Collet.Votez pour ce billet sur Planet Libre.
Articles similaires
Remi Collet : PHP-FPM dans Docker (11/12/2014)
Remi Collet : À propos de libmcrypt et php-mcrypt (07/07/2015)
Remi Collet : Apache HTTP Server et répartiteur de charge vers PHP FPM (17/09/2015)
Remi Collet : Ma station de travail PHP (16/04/2016)
Remi Collet : Microsoft SQL Server depuis PHP (20/09/2016)

Pour nos projets a Epitech on doit de plus en plus travailler la partie conception plutôt que le projet en lui-même. Déjà parce que nos projets se complexifient: On passe d’un simple bash/sh à recoder à un équivalent de Mumble avec un client et un serveur tous les deux multi-plateforme. Et aussi bah… parce que ya pas que le code dans le dév, il faut réfléchir consciencieusement à l’architecture de son projet, aux différents composants que l’on va créer/coder et comment on va lier tout ce bazar.

L’UML

L’un des moyens les plus courant, les plus utilisés, de nos jours c’est l’UML pour Unified Modelling Language. Il faut voir l’UML comme une RFC, une normalisation de la conception de systèmes. Ce n’est pas le nom d’un logiciel, mais d’un protocole à utiliser dans son logiciel ou son bout de papier, pour concevoir son programme.

Avant de vous parler d’ Umbrello, je vais parler un peu plus en détail du fonctionnement de l’UML et comment en faire. Si vous connaissez déjà vous pouvez défiler la page pour voir directement le moment ou je parle d’Umbrello ;) (je mets un petit titre)

En programmation, l’UML est particulièrement adapté lorsqu’on utilise un paradigme Orienté Objet type C++, Java, Python, etc. Mais rien n’empêche de l’utiliser pour d’autres choses! Lorsque l’on conçoit son programme, on passe par une phase d’abstraction. C’est-à-dire que l’on prend les éléments de ce qu’on veut obtenir, et on regarde s’il n’existe pas des caractéristiques communes entre ces éléments.

On va prendre un exemple assez simple pour imager tout ça. Imaginez que vous êtes en train de développer un outil de simulation de téléviseurs, pour avoir une vue 3D, faire des tests, voir le fonctionnement ou n’importe quoi d’autre on s’en fiche. Votre programme permet de représenter des téléviseurs existants.

On peut donc dire qu’on aura beaucoup de types de téléviseurs, avec tout un tas de marques, et de caractéristiques propres à chacun. Mais dans tous les cas ce sont les TV donc on doit pouvoir en déduire un certain nombre de propriétés communes:

• Toutes les TV ont une marque, des haut-parleurs, des câbles, etc.
• Toutes les TV doivent pouvoir s’allumer, s’éteindre, changer de chaine, monter/descendre le volume, etc.
• Toutes les TV ne fonctionnent que selon certains critères, par exemple seulement si la prise est branchée et s’il y a le câble ou l’antenne

Lorsque l’on va représenter ceci, on va avoir une classe dite “abstraite” mère appelé AbstractTV qui va contenir des cases et des fonctions vides pour chacun de ces attributs. Ensuite toutes les autres classes de TV vont découler de celle-ci, elles vont en hériter, et devront donc s’appuyer sur le modèle d’AbstractTV.

Et on peut donc représenter tout ça avec l’UML, je ne vais pas faire un schéma, je vous laisse le soin de trouver des tutos bien mieux que ce que je pourrais faire ;) Comme celui-ci ou celui-là

Umbrello

J’ai découvert donc récemment un logiciel sous KDE pour faire de l’UML rapidement et simplement qui s’appelle… Umbrello (vous l’auriez pas deviné hein?) Je n’ai utilisé pour l’instant que l’outil pour faire des diagrammes de classe, mais bien sûr la plupart des types de diagrammes pour l’UML sont réalisables.

Ce logiciel est en développement et une version mineure sors tous les 4 mois à peu près. Une petite capture pour présenter la bête:

En haut on a la barre d’outils pour faire la plupart des opérations nécessaires: création d’une interface, d’une classe, flèche de composition, d’agrégation, etc. Sur la gauche on a un panneau de détails sur les boites qu’on a crée sous forme d’arborescence et d’autres petits outils que je vous laisserais découvrir ;)

On l’a utilisé tout le long de notre projet de ces deux dernières semaines et nous sommes relativement satisfaits. Il y a deux soucis assez désagréable dans Umbrello que je trouve dommage:

• La molette fait un zoom/dezoom plutôt qu’un défilement vertical/horizontal, et c’est assez contre-intuitif en plus de n’être absolument pas pratique, ni utile puisqu’il y a une petite barre de réglage du zoom en bas à droite largement suffisante.
• Pas de Ctrl-Z ou de Ctrl-Y pour revenir dans l’historique des actions, en fait le seul moyen d’annuler ce qu’on vient de faire consiste soit à refaire manuellement nos mouvements en sens inverse, soit on peut utiliser “l’historique de commandes”, et on clique sur l’état auquel on veut revenir. L’historique est donc déjà implémenté mais pas moyen d’y accéder rapidement comme dans presque n’importe quel logiciel avec des raccourcis clavier.

J’espère qu’il y aura des modifications faites sur ce sujet d’ici les prochaines versions, j’irais jeter un oeil sur leur liste de bugs pour essayer d’en parler. Sinon je vous conseille de l’essayer il est tout de même pratique et support quelques fonctionnalités avancés telles que l’import/export de code vers/depuis l’UML.

Original post of Ilphrin.Votez pour ce billet sur Planet Libre.

Dans un précédent article, je présentais Thunderbook, une extension Mozilla Thunderbird qui permet de créer un livre électronique au format EPUB à partir de messages (licence MPL 2.0). Elle a déjà été téléchargée plus de 1000 fois et le site Mozilla Add-ons (AMO) comptabilise plus de 120 utilisateurs quotidiens.

J’ai profité du long week-end du 11 novembre pour publier une deuxième version (version 0.2). Voici les amélioration apportées :

• Il est maintenant possible d’exporter les messages d’un dossier spécifique (et de ses sous-dossiers). Cette idée d’amélioration avait été approuvée par groov dans un commentaire du précédent article.
• À la fin de la génération, l’extension propose de marquer tous les messages exportés comme lus. Ceci permet d’éviter que des messages soient exportés une nouvelle fois lors d’une seconde génération de livre électronique.
• Le livre électronique généré a été amélioré avec notamment l’ajout d’une page de titre (en l’absence d’une vraie page de couverture, la première page fait généralement office de page de couverture pour les liseuses) ainsi que l’ajout, pour chaque message, de son auteur, de sa date et d’un lien vers le contenu original (surtout pratique pour un article de flux RSS).

La nouvelle version est disponible sur le référentiel de mon compte Bitbucket mais elle est également disponible sur le site Mozilla Add-ons (AMO), où elle a déjà été vérifiée par l’équipe Mozilla. Elle peut donc être installée ou mise à jour directement à partir de Mozilla Thunderbird.

Comme pour la précédente version, n’hésitez pas à me faire part de vos remarques, problèmes ou idées d’amélioration par rapport à cette extension.

Original post of Julien L.Votez pour ce billet sur Planet Libre.