Github, langages et trahison

Avec un ami nous travaillons actuellement sur un bot IRC en Go (Goxxx).

Quelle ne fut pas ma surprise en constatant qu’après avoir ajouté des fichiers HTML (pour les tests), le projet était désormais considéré par github comme un projet « HTML » au niveau de ses statistiques !
Ce problème peut également se produire sur les dépôt ou sont présents des fichiers/librairies « vendored », développées par des tiers mais inclus au projet pour plus de facilité.

Suite à cette trahison et à quelque recherches sur le web, il y a une solution simple: Il suffit d’ajouter dans le fichier .gitattributes du dépôt une des directives suivante pour les fichiers/patterns à exclure des statistiques :

  • linguist-documentation pour tout se qui se rapporte a la documentation
  • linguist-language pour forcer le langage de certains fichiers à une valeur donnée
  • linguist-vendored pour les fichiers « vendored »

Exemples :

# Traite les fichiers .rb (ruby) comme étant des fichiers Java
*.rb linguist-language=Java

# Ignore les fichiers présents dans le dossier "project-docs" (Considérés comme de la documentation)
project-docs/* linguist-documentation 

# Ignore les fichiers présents dans le dossier "special-vendored-path" (Considérés comme des fichiers "vendored")
special-vendored-path/* linguist-vendored

pour plus d’informations et de détails: https://github.com/github/linguist#overrides

Le HTTPS, ce n’est pas automatique !

Suite aux révélations d’Edward Snowden l’année dernière, on a vu fleurir peu à peu des sites qui proposent un accès en HTTPS. Pour les plus novices d’entre nous, le HTTPS c’est le moyen d’accéder au web de façon chiffrée. En gros, c’est grâce à ça que vous pouvez vous rendre sur Google Facebook les sites Internet sans que de (méchants) gens ne puissent intercepter ce que vous voyez.
Si, à la base, l’idée de proposer un tel accès à un site Internet est louable, j’aimerais tout de même rappeler que le HTTPS, ce n’est pas automatique !
Read More

Naviguez tranquille avec Docker

Depuis quelques mois je vois régulièrement passer des articles parlant de Docker. Au début, je ne comprenais pas trop ce que c’était et je me disais que si c’était si cool que ça, j’en entendrais parler encore. Puis je revois passer, j’ai des besoins, je me renseigne, je DuckDuckGooglise… Bref, ça a l’air cool. Je vais donc essayer de faire un article assez court histoire de vous faire rapidement comprendre pourquoi Docker c’est de la balle.
Read More

Ou l’art de documenter facilement une base de données

#mylife je viens de commencer un nouveau boulot chez La Roue Verte, une entreprise de covoiturage sur Grenoble, qui met à disposition son outil gratuitement pour les particuliers et base son business model sur du SASS avec les entreprises.

Pourquoi je vous raconte ça ? Parce que lorsque l’on commence un nouveau travail, il faut  « rentrer dans la base de code », autrement dit, se familiariser avec le produit. J’ai donc eu la proposition suivante : « On a pas de doc, et ça nous embête, or, quel meilleur moyen de rentrer dans le code que de la rédiger ? Si tu es capable de faire la doc sans faute, c’est que tu as compris comment ça marchait ! ».

Un traitement de texte ? C’est quoi ?

Aussitôt dit, aussitôt fait, me voici à devoir documenter une base de données PostgreSQL, le modèle de notre application. Aucune contrainte sur les outils à utiliser, il faut juste que le rendu final soit un PDF. La solution de facilitée aurait été d’ouvrir LibreOffice Writer et de prendre une à une chaque colonnes de chaque tables en la décrivant. Cela peut sembler fastidieux, mais de toute manière, je n’y échapperai pas. Non, ce qui m’ennuyait dans cette solution, c’était le maintien à jour des données. Si la doc aurait été à jour au moment de sa création, il y avait fort à parier que le fichier texte n’allait pas être modifié par les développeurs lorsqu’ils modifieraient le schéma de la base, que ce soit par oubli, par flemme ou par manque de temps. Or, dès que le document n’est potentiellement plus le reflet exact de la base, même si la différence entre les deux est mineure, il ne devient plus possible de s’y référer, on ne peut pas savoir ce qui est correct de ce qui n’est plus à jour. L’intégralité du document (et ma vingtaine d’heures passées à le rédiger) devient inutile. Une doc pas à jour équivaut à « pas de doc ».

La génération automatique à la rescousse

La solution pour avoir une documentation toujours à jour ? La générer directement depuis le schéma de la base de données. Un coup de DuckDuckGo, et je découvre Autodoc, un outil en ligne de commande à qui on donne simplement l’accès à la base de données, et qui nous extrait des fichiers au format HTML, Dot, Dia et DocBook XML. HTML ? Parfait pour moi ça. Facile à mettre en forme en deux coups de CSS, qui se transformera en une seconde en un PDF grâce au « Imprimer dans un fichier » de Firefox… Je lance la génération.

Toutes les tables sont là, les colonnes aussi, mais aussi les contraintes (clef primaire, clef étrangère, not null, valeur par défaut…) ou encore les fonctions triggers, des statistiques, bref, beaucoup de choses. Les graphiques .dot ne sont pas vraiment exploitables, mais pas grave, ce n’est pas ça qui m’intéresse. Après un coup de CSS pour rendre le résultat moins moche, j’ai maintenant une documentation qui se génère en une commande, et qui est donc toujours à jour par rapport au schéma de la base de données.

C’est une bonne nouvelle, mais les informations contenues dans ce HTML sont finalement assez faibles. Il n’y a rien de plus que ce que je pourrais lire dans le create.sql, certes, sous une forme un peu plus lisible, mais tout de même, ce qui est intéressant, c’est de dire à quoi correspondent chaque table et chaque colonne. Ici, je connais leur type et leurs contraintes, et je peux imaginer ce qu’elles font grâce à leur nom, mais tout de même, ce n’est pas cela que l’on appelle une documentation.

COMMENT ON, THE solution

Après quelques recherches supplémentaires, j’ai donc trouvé la solution idéale pour le moment : COMMENT, qui permet d’ajouter très facilement un commentaire à à peu près tout et n’importe quoi (table, column, constraint, index, database… la liste est longue, vous pouvez la consulter dans la doc). La syntaxe est ultra simple :

COMMENT ON TABLE user IS 'Contient les utilisateurs inscrits dans l''application.'; -- Ajoute un commentaire sur la table "user"
COMMENT ON TABLE user.name IS 'Le nom de l''utilisateur'; -- Ajoute un commentaire sur la colonne name de la table "user"

Un coup de génération, et les commentaires s’affichent dans le .html 🙂

Cerise sur le gâteau, postgresql_autodoc nous permet de choisir le template sur lequel il doit se baser pour génerer la doc. J’ai donc modifié ce fichier pour retirer tout ce qui était inutile, améliorer le design et lui demander d’interpreter le HTML dans les commentaires. Magnifique ! Grâce à des <span class="technique"> et un bout de JavaScript, nous voici maintenant capable de masquer ou afficher en un clic les parties techniques de la documentation, celles qu’on a pas besoin de montrer quand on présente la partie métier de l’application.

Bien sûr, cette solution n’évite pas le fait que si un commentaire n’est pas ajouté ou pas mis à jour lors de la modification du schéma, la doc ne sera pas exactement à jour. Mais comme elle se base sur le schéma pour être généré, on est absolument sûr que toutes les tables et colonnes sont là et avec le bon nom, ce qui est déjà nettement mieux qu’une doc non reliée à la base de données.

Voilà, la mauvaise nouvelle, c’est que la commande COMMENT est spécifique à PostgreSQL et n’est pas dans le standard SQL, mais de toute manière, Postgres est la meilleure DB non ?

Dans les 42 minutes qui suivent l’installation d’Ubuntu

Je viens de me réinstaller (non sans mal) mon Ubuntu, en profitant pour mettre la dernière version, la 13.10. Comme d’habitude, j’ai mon rituel d’après installation. Et comme c’est la mode et que tout le monde le fait, je vais partager avec vous le contenu de mon fameux fichier « TODO after a fresh install »

  1. Installer guake, reconfigurer mes raccourcis clavier, le lancer automatiquement au démarrage
  2. apt-get update && apt-get dist-upgrade
  3. Restaurer les profils firefox et thunderbird. C’est pas trop dur, je les copie de mon disque dur, et je retrouve tous mes onglets ouverts et tous mes mails sans avoir besoin de les retélécharger
  4. Aller sur upubuntu.com et télécharger le dernier kernel. Oui, j’aime être constamment sur le dernier noyau Linux.
  5. Rajouter pcie_aspm=force à la commande de boot dans /etc/default/grub, ça me fait gagner ~20% d’autonomie (puis rebooter :p)
  6. Ouvrir le software updater et activer les dépots Universe (les logiciels proposed et ceux packagés par Canonical)
  7. apt-get update && apt-get dist-upgrade once again, proposed a rajouté plein de choses 🙂
  8. Restaurer tous mes alias depuis mon ancien .bashrc
  9. Désactiver les suggestions amazon dans l’onglet privacy
  10. Installer VLC et le mettre comme lecteur par défaut
  11. Installer gimp
  12. Installer HexChat le paramètrer pour se logguer immédiatement à mes salons favoris sur Freenode et mozilla
  13. sudo fstrim -v / (on commence à avoir bougé beaucoup de choses sur ce SSD, faut trimer !)
  14. Taille des icônes du dash à 32px, retirer tous ces lanceurs qui servent à rien (Amazon, Ubuntu One, LibreOffice, Logithèque) et rajouter ceux qui rocks (Thunderbird, HexChat, Gimp…)
  15. Mettre un fond d’écran qui déchire et ne pas oublier de lui mettre les permissions pour qu’il s’affiche dès la page de login
  16. Paramétrer un peu gedit, couleur sombre, affichage des numéros de ligne, mise en valeur de la ligne et de l’accolade courante…
  17. Restaurer mon dossier de travail sur diaspora 😀 et au passage, mes clefs ssh sur les serveurs…
  18. Mettre à jour le franćais dans les paramètres de langue
  19. Installer wine, directplay avec winetricks, et Age Of Empire 2 😀
  20. Pareil avec Heroes 3, mais la version pour GNU/Linux

Je vais certainement faire des tonnes de choses de plus dans les jours qui suivent, mais là, c’est ce qui me vient à l’esprit après une fresh install 🙂

Comment réorganiser ses comptes de messagerie dans Thunderbird

Thunderbird
Si vous utilisez Thunderbird avec plusieurs comptes de messageries, vous vous êtes sans doute aperçu que ceux-ci sont listés dans le menu de gauche par ordre chronologique de leur création dans Thunderbird. Mais peut-être qu’au fil du temps, l’importance de ces comptes a changé et que vous préféreriez les lister différemment ?

Et bien, même si ce n’est pas faisable depuis l’interface, c’est néanmoins possible !

Il suffit de modifier les deux variables mail.accountmanager.accounts et mail.accountmanager.defaultaccount dans le fichier prefs.js de votre profil Thunderbird.

Commencez par fermer Thunderbird puis ouvrez ce fameux fichier avec votre éditeur de texte préféré. Sous GNU/Linux, il se trouve dans ~/.thunderbird/<your profile>/prefs.js, sous XP dans C:Documents and Settings<your profile>Application DataThunderbirdProfiles****.defaultprefs.js et sous Vista ou 7 dans C:Users<your profile>App DataRoamingThunderbirdProfiles****.defaultprefs.js. <your profile> étant souvent des caractères aléatoires + .default à la fin.

Ensuite, repérez la ligne commençant par user_pref("mail.accountmanager.accounts",. Vous l’avez compris, les comptes listés ensuite sont vos comptes de messageries, avec le numéro correspondant à l’ordre dans lequel ils ont été créés. Il vous suffit de les réordonner comme bon vous semble, par exemple user_pref("mail.accountmanager.accounts", "account2,account3,account1,account4,account5");

Attention ! La variable située juste en dessous permettant de régler le compte par défaut doit être le premier compte de votre liste, dans notre exemple, vous devez aussi modifier user_pref("mail.accountmanager.defaultaccount", "account2");

Enregistrez et relancez Thunderbird, et voilà !

Comment ça marche, la fédération de diaspora* ?

English version below.

Pour rappel, on désigne par « fédération » l’échange des données entre les différentes instances de diaspora* (appelées pods). Il s’agit donc du protocole qui permet aux serveurs de communiquer entre eux.

Avec le travail en cours pour extraire le code s’occupant de la fédération du reste du code de diaspora (oui, ce code devrait devenir une gem à part et donc être utilisable par n’importe quel projet qui veut parler avec diaspora* !), il me semble qu’un petit article de vulgarisation sur la fédération n’est pas de trop. J’ai régulièrement des remarques sur différents points qui m’obligent à réexpliquer un peu comment tout ça marche, alors un joli article à la limite du technique mais compréhensible par tous, ça me semble la solution parfaite, je n’aurai plus qu’à donner ce petit lien… 😀

Alors, comment les serveurs de diaspora* communiquent-ils, pour réussir à faire qu’être inscrit sur n’importe lequel d’entre eux permet (presque) la même chose que si tout le monde était sur le même serveur ? (comment ça, presque, je vous entends dire ? Oui, il y a quelques cas où vous n’aurez pas le même résultat après avoir effectué la même action quand vous êtes sur deux pods différents. Ce billet a justement comme but de vous expliquer pourquoi). Read More

Internet Explorer < 9 et HTML5

Un court billet pour vous faire part d’une astuce que j’ai découvert aujourd’hui et qui va immédiatement m’être indispensable.

Si vous avez un peu joué avec le langage du web, HTML, et notamment sa dernière version, la 5, vous vous êtes sans doute aperçu qu’Internet Explorer avant la version 9 ne connaissait pas les nouvelles balises (article, aside, footer, header, nav, section, time, toussa quoi). En fait, aucun ancien navigateur ne les connait, et c’est bien normal, puisque les navigateurs sont sortis avant la norme. Mais au contraire d’Opera, de Safari et de Firefox, qui, même s’ils ne connaissent pas les balises, les stylent correctement (c’est-à-dire leur applique correctement le CSS), Internet Explorer, lui, les ignore purement et simplement.
Read More

Behat, un framework de tests unitaires pas comme les autres

J’ai récemment découvert Behat et comme je trouve le concept très intéressant, j’ai pensé que quelques informations intéresseraient peut-être nos lecteurs pendant mon initiation à cette nouvelle forme de tests unitaires.

Behat a été créé dans le cadre d’une méthode de développement agile « Behavior Driven Development », je vous recommande la lecture de l’article Wikipédia qui traite du BDD pour plus d’information car comme je ne connais bien le concept, je vais écrire des choses triviales à ce sujet.

L’idée de Behat, qui s’inspire de projets pour d’autres langages (comme Cucumber pour Ruby), est d’écrire des tests en langage naturel. Voici l’exemple de la documentation officielle de Behat (pardonnez le manque de coloration syntaxique, mais le langage n’est pas supporté dans le plugin WordPress) :

Feature: ls
  In order to see the directory structure
  As a UNIX user
  I need to be able to list the current directory's contents

  Scenario:
    Given I am in a directory "test"
      And I have a file named "foo"
      And I have a file named "bar"
     When I run "ls"
     Then I should get:
       """
       bar
       foo
       """

C’est en voyant cet exemple sur Twitter que j’ai découvert Behat, intrigué par cette façon de faire, assez éloignée de la façon de tester avec des outils de type xUnit.

Je vous propose de créer une petite classe PHP et de la tester rapidement pour découvrir Behat.

Read More

De la subtilité de générer du JSON en PHP

J’ai récemment été confronté à un bug dans une application JavaScript au boulot. J’ai mis un certain temps à comprendre car je ne connaissais pas la subtilité dont je vais vous parler. Ne vous attendez pas à des révélations fracassantes ni à des démissions en chaînes, il s’agit d’un tout petit point qui mérite l’attention des développeurs et qui relève autant de la logique et du bon sens que de la connaissance des langages incriminés !

J’utilise un script PHP pour récupérer des données en base de données qui sont ensuite formatées en JSON avant d’être transmises à l’application JavaScript (JS). Il s’agissait d’une collection de couleurs (avec des infos du genre identifiant, code de la couleur et nom de public de la couleur).

Tout fonctionnait bien jusqu’à très récemment (l’application JS permet de dessiner en pixel art) et j’ai donc cherché pourquoi une des fonctionnalités (l’importation d’une image et sa transformation en pixel) ne marchait plus. Après un bon moment de debugging dans le JS, j’ai fini par découvrir que c’était lorsque l’application bouclait sur la collection de couleurs que les problèmes survenaient:

for(var i = 0, acl = availableColors.length; i < acl; i++)

L’instruction « availableColors.length » renvoie  » undefined  » alors que availableColors me montre une collection d’objets JSON. Oui mais non, pas tout à fait. Comme me le fait remarquer un collègue, firebug indique un objet contenant les objets couleurs et non pas un tableau. Or, l’appel à « .length » ne fonctionne que sur les tableaux. C’est l’une des choses sur lesquelles il faut être attentif lorsqu’on travaille sur du JSON généré par PHP. Mais pourquoi diable ?

La réponse se trouvait dans la méthode PHP qui récupère les données dans une BDD : j’ai récemment modifié l’array PHP de sortie en le transformant en array associatif (ironiquement, pour corriger un bug. Merci l’absence de tests ahah). Ce même tableau transformé en JSON par « json_encode » lors de la transmission à la vue. Un petit tour sur la page de la documentation de json_encode m’a permis de réaliser que les array associatifs sont toujours transformés en objet JSON.

Il m’a suffit d’écrire une méthode qui se charge de générer le JSON qui sera envoyé au client.

     /**
      * Returns a JSON string ready to be used by the client
      *
      */
     public static function formatAvailableColorsForClient(array $availableColors)
     {
         return json_encode(array_values($availableColors));
     }

Pour info, la fonction array_values permet de réindexer un tableau.

Et voilà !