Asciidoc for the win !

Il y a quelques temps, j’avais écrit un article expliquant pourquoi les documents Office n’étaient pas de bons livrables. J’y indiquais par ailleurs qu’Asciidoc me semblait une bonne alternative.

Mais un format, ça n’est qu’un format. Une documentation, ça n’est hélas pas qu’un format technique de document. C’est aussi, avant tout, le moyen de raconter l’histoire du logiciel. Et parfois, ça n’est pas facile

A la recherche du bon format

Pas son histoire au sens biographique, mais plus son usage, son architecture, bref, l’ensemble des éléments qui contraignent son code à avoir sa structure. Autrement dit, les éléments qui donnent les réponses aux questions invraissemblables que se posent un développeur.

you_down_wit_opc-yeah_you_know_me

C’est pas que je déteste, c’est que je comprend pas l’histoire

Et ça, que j’écrive ma doc dans Word, en Asciidoc, en LaTeX, la question se pose toujours : pourquoi ces décisions ont été prises.

Heureusement, j’ai découvert il y a quelques temps le format de documentation agile de Simon Brown, qu’il documente dans la doc de Structurizr.

Regardons ensemble le sommaire :

  1. Context
  2. Functional Overview
  3. Quality Attributes
  4. Constraints
  5. Principles
  6. Software Architecture
  7. Code
  8. Data
  9. Infrastructure Architecture
  10. Deployment
  11. Development Environment
  12. Operation and Support
  13. Decision Log

Et maintenant, imaginez ce que ça donne pour votre projet. Tous les aspects sont documentés dans un seul gros document Word. C’est pénible … heureusement, là, asciidoc peut vous aider.

Je vous montre : si votre doc est en asciidoc, vous pouvez faire des include.

Et donc, vous pouvez avoir un dossier de doc qui ressemble un peu à ça

  • monprojet.adoc
  • images/ Vous mettez toutes vos images là-dedans
  • includes Et chacun des chapitres de votre doc est un document séparé dans ce dossier.
    • /00_intro.adoc
    • /01_context.adoc
    • /02_functional_overview.adoc
    • /03_quality_attributes.adoc
    • /04_constraints.adoc
    • /05_principles.adoc
    • /06_software_architecture.adoc
    • /07_code Si vous avez des éléments à détailler, n’hésitez pas à créer des sous-dossiers
      • /un_detail.adoc
    • /07_code.adoc
    • /08_data.adoc
    • /09_infrastructure_architecture.adoc
    • /10_deployment.adoc
    • /11_development_environment.adoc
    • /12_operation_and_support.adoc
    • /13_usage.adoc
    • /14_decision_log.adoc
    • /99_faq.adoc

Du coup, avec tout ça, vous avez une documentation correctement découpée, dans laquelle vous mettez vos diagrammes UML (ou autres) générés avec asciidoctor-diagram, et vous êtes content …

Bon, et puis si vous n’êtes pas contents de ce format, Simon Brown mentionne également le support d’arc42, qui a l’air tout aussi intéressant :

A un détail près.

Parfois, il y a du code que vous voulez voir généré pour le mettre dans la doc.

Par exemple, si vous utilisez le ServiceLoader de Java, savoir quelles classes implémentent une interface sans avoir à chercher dans Eclipse, c’est cool.

Tant qu’à générer la doc, pourquoi ne pas générer la doc ?

Parce qu’en fait, votre doc asciidoc, vous la générez, pas vrai ? Si vous faites du maven, vous utilisez sans doute le maven-asciidoc-plugin. Je vais faire l’hypothèse que vous êtes dans ce cas.

Et dans ce cas, si vous avez besoin d’avoir un morceau de la doc qui dépende plus directement du code, vous pouvez tout à fait … utiliser Groovy pour générer des fichiers asciidoc qui vont bien !

Typiquement, pour mon exemple, j’ai un script Groovy qui a dans son CLASSPATH tous les modules de mon application, et qui à l’aide de reflections recherche les implémentations de l’interface pour générer un tableau Asciidoc les affichant.

Et comme ce script Groovy est lancé grâce à gmaven avant la génération de la doc, cette partie est toujours à jour.

Et pour un projet multimodule ?

Pour l’instant, j’ai juste testé ça une fois, et d’une façon non satisfaisante. Comme j’arrivais sur un projet existant, j’ai simplement ajouté un module doc isolé du reste de l’application.

Je pense que j’aurais eu une doc d’une bien meilleure qualité si j’avais mis la doc dans chaque module avec des includes bien costauds dans la doc du module global (voire même des morceaux complètement générés). Evidement, dans ce genre de cas, la génération de la documentation doit également être documentée …

Donc ça marche bien ?

Oh que oui !

Ecrire de la doc est presque agréable, et les aspects générationnels sont une distraction encore plus agréable. Sans même parler de la fusion de cette doc et des différents diagrammes qui y sont intégrés.

Mais je crois qu’on peut aller encore beaucoup plus loin. Pas directement avec cette technique, mais sans doute en amont, via des graphes.

On pourrait faire encore mieux ?

Je vous donne quelques exemples.

Pour décrire votre applications, vous utilisez en fait plusieurs graphes

  • L’architecture conceptuelle (ou fonctionnelle) décrit comment les composants remplissent les fonctions
  • L’architecture applicative organise ces composants en modules
  • L’architecture technique montre comment ces composants se déploient.

Tout ça est censé être à peu près couvert par Structurizr.

Mais d’autres éléments ne le sont pas : quand je décris une organisation de classe, c’est aussi un graphe. Et un diagramme de séquence pourrait tout à fait être construit à partir du code un peu annoté.

Imaginez que je dispose d’un modèle comme celui de Structurizr, mais enrichi à la fois avec les informations du code (pour produire les différents diagrammes de bas niveau), et pour lequel je puisse générer des diagrammes via une quelconque syntaxe de recherche des noeuds dans un graphe. Je pourrais alors demander facilement des trucs comme

Dessine-moi le diagramme de séquence partant de cette interaction Javascript et incluant les échanges avec le serveur, la base de données, et le composant Java bidule

Et d’un coup, je n’ai plus un simple outil de documentation, mais un outil d’analyse et de compréhension de mon code, que je peux ensuite faire produire un truc que j’ai bien galéré à faire il y a quelques temps :

Fais-moi un diagramme de composant où les classes sont coloriés en fonction de leur dette technique

Bon, c’est une très chouette idée, et je sais à peu près comment l’implémenter … Mais c’est malheureusement encore un projet de plus. Et mon temps est déjà bien rempli.

Jenkins, sers-moi donc un Chtijug !

Nicolas Géraud était venu nous parler des pipelines il y déja deux ans.Est-ce que cette présentation allait être mieux ? En tout cas, elle est bien différente.

Petit point sponsoring de l’IUT sur la taxe d’apprentissage : les entreprises peuvent déclarer des organismes de formation bénéficiaires de leur taxe d’apprentissage. Ca peut avoir une influence sur le budget de ces organismes.

Et c’est parti !

Avec d’abord un petit sondage :

  • qui connait Jenkins ? A main levée, tout le monde dans la salle.
  • qui a déja migré vers Jenkins 2 ? Encore à main levée, pas grand monde.

Jenkins 2

Donc Jenkins 2 … est totalement compatible avec Jenkins 1. Et c’est bien, parce que la montée de version va être simple. Dans l’ensemble, les plugins sont compatibles.

Avec Jenkins 2, il y a aussi de nouveaux sites

  • http://jenkins.io qui est bien plus grand public
  • le project Voltron sert de plugin store avec une chouette présentation. Limite comme le google play store, en fait.

Il y a maintenant au premier démarrage un mot de passe à aller chercher dans les logs de la machine. Ca va permettre de sécuriser le serveur Jenkins avec un admin par défaut. Evidement, on peut toujours avoir un Jenkins non sécurisé, mais il faut le vouloir. Ce qui change pas mal de Jenkins 1 qui, par défaut, n’était pas sécurisé. En bonus, une liste de plugins par défaut est disponible, pour faire une première personnalisation de Jenkins.

Et ensuite, on arrive aux fameux pipeline-as-code.

Pipeline as code

Un job est défini par un Jenkinsfile, écrit dans un DSL Groovy, qu’on peut stocker dans son SCM. L’avantage, c’est aussi de permettre d’utiliser les structures de contrôle de Groovy pour personnaliser le job.

Et ensuite

Il y a tout un tas de nouveaux trucs qui ne vont pas tarder à arriver

BlueOcean (déja disponible en pas beta, mais pas release non plus)

La fameuse nouvelle interface graphique pour Jenkins. Les captures sont très chouettes !

Franchement, l’affichage des pipelines est très chouette. Si j’avais eu ça chez Perigee, j’aurais pu montrer un vraiment très beau pipeline. Le plus incroyable, c’est quand même de pouvoir faire « pousser » un pipeline graphiquement. Il faut voir l’écran pour le croire, je trouve.

Pipeline déclaratif

En bonus, ça permet à des non-développeurs de modifier le build, ce qui n’est pas une si mauvaise idée, puisque le code exécuté est toujours en SCM. En fait, le pipeline généré n’est pas exactement identique à celui qu’un développeur écrirait : c’est un pipeline déclaratif.

D’une façon amusante, le speaker décrit la syntaxe d’un DSL Groovy comme « à mi-chemin entre YAML et Groovy ». Guillaume Laforge et tous ses amis pleurent des larmes de sang en entendant ça. Parce que quand on regarde un DSL Groovy, comme par exemple le MarkupBuilder, on est exactement dans la syntaxe visible à l’écran. Bon, je ne vais pas en vouloir au speaker : il connaît sans doute mieux Jenkins que je connais Groovy.

Back-end storage

Manifestement, l’objectif est de découpler le fonctionnement de Jenkins et le stockage des configurations d’exécution et des résultats. C’est une chouette idée, mais pas vraiment assistée par les capacités des plugins à écrire eux-mêmes des fichiers.

Donc Jenkins 2, c’est ?

Jenkins 2, c’est mieux, et orienté sur le continuous delivery. Et pas le continuous deployment. Autrement dit, l’équipe de cloudbees ne vise pas trop à utiliser Jenkins pour le déploiement en prod.

Quelques questions

Si les pipelines sont déclaratifs, comme maven ou gradle, pourquoi ne pas réutiliser leur outillage ?

Jenkins est utilisé pour faire le delivery, ce que ne font pas ces outils. En un sens, je comprend cette réponse : le scope fonctionnel est différent, et ce serait assez curieux de dire « on peut faire du gradle pour le déploiement ». Et puis, Cloudbees et Gradle inc ne vont pas fusionner demain.

Mais quand même, en transformant les jobs en bouts de code, je trouve que Cloudbees fait rentrer Jenkins dans une espace de continuum de build qui va de mon poste jusqu’aux artefacts déployables en prod.

Comment se compare l’API de pipeline-as-code et de job-dsl ?

L’inspiration initiale de pipeline-as-code était buildflow, mais ça a vite divergé.

Et la démo

  • Premier truc cool : les plugins installés sont toujours installés à la dernière version.
  • Deuxième truc cool : BlueOcean est déjà disponible comme plugin, et donc installable.
  • Troisième truc cool : le travail d’administrateur Jenkins s’arrête, pour les jobs, à créer les jobs et les connecter à des SCM. Tout le reste vient du Jenkinsfile.

Et donc, on passe à la création du Jenkinsfile. Et là, la structure des DSL Groovy réapparaît vraiment, et c’est bien.

  • Quatrième truc cool : les commandes checkout de SCM utilisent la révision du Jenkinsfilecomme référence. Par conséquent, l’enchaînement d’étapes se passera beaucoup mieux que dans Jenkins 1, puisqu’il n’y aura pas de révision à passer. Par contre, curieusement, le DSL ne semble pas contenir de commande maven, puisque notre speaker exécute les commandes maven via un sh "mvn clean package". Arf … apparement, le plugin exécutant maven est « mauvais ».
  • Cinquième truc cool : l’interface de Jenkins inclut un générateurs de snippets façon vieux wizards qui permet d’apprendre très rapidement le DSL des pipelines.
  • Sixième truc cool : l’affichage des pipelines en cours est vraiment très sympa, avec des logs par noeud du pipeline affichés en temps réel.
  • Septième truc cool : le DSL inclut une notion de stashes, valable uniquement pour la durée du pipeline, qui permet donc de ne pas déployer dans Nexus les artefacts temporaires.
  • Premier truc pas cool : le pipeline est toujours exécuté sur le master. Du coup, la montée en charge pourrait mal se passer.
  • Huitième truc cool : pour les pipelines déclaratifs, il est possible de demander à Jenkins d’analyser la syntaxe.
  • Deuxième truc pas cool : on peut relancer un pipeline à partir d’une étape uniquement dans la version commerciale de Jenkins. C’est moins bien … mais je comprend tout à fait.
  • Neuvième truc cool : il est possible de créer des morceaux de code partagés entre pipelines.
  • Dixième truc cool : les milestones permettent d’éviter de lancer plusieurs builds concurrents sur une ressource critique.

Et si vous voulez voir le Jenkinsfile utilisé pour ce live-coding, il est disponible sur github.

D’autres questions

Comment tester un pipeline ?

Eh bien, on ne peut pas : il faut le lancer dans une instance de Jenkins. Autrement dit, c’est le genre de truc où il faut une instance de test de Jenkins. Et mon collègue me souffle à l’oreille qu’on peut très bien utiliser l’annotation @StaticCompile de Groovy pour vérifier la syntaxe autant que possible (parce que @StaticCompile, sur un DSL, il doit bien s’amuser, tiens).

Conclusion

J’ai quand même hâte de voir les projets passer au moins aux pipelines as code, histoire d’avoir dans mon SCM, à côté de mon pom.xml, le Jenkinsfile qui va bien. Et histoire aussi d’ajouter un peu de Groovy dans tout ça !

Compiler ou tester ?

En fin de cette semaine, une controverse intéressante a eu lieu sur twitter, habilement lancée par cet article de « Uncle » Bob Martin : The Dark Path.

Regardez par exemple cette sélection de tweets sur le sujet :

On peut dire que les avis sont contrastés.

Et comme la meilleure façon de ne laisser aucun doute sur le sujet de ma propre stupidité, laissez-moi vous donner mon avis sur le sujet.

A quoi sert le compilateur ?

Il y a des années, à l’époque du C, le compilateur servait à transformer le code source écrit dans un langage quasiment humainement compréhensible (le C) en un code exécutable par la machine.

Aujourd’hui, quelque soit la plateforme d’exécution (la JVM, la CLR de Microsoft, ou le résultat d’une transformation LLVM), le compilateur fait beaucoup plus de choses : il simplifie, optimise, vérifie le code d’une façon très poussée.

Et à mon avis, c’est l’argument de Romain Guy : si le système de type est suffisamment poussé, il est impossible d’écrire un code qui ne corresponde pas précisément aux souhaits du développeur. Mais à quel prix ? C’est ce que cherche à évaluer Uncle Bob.

Laisser le compilateur vérifier ? ou Tester

Parce que l’avantage des tests sur le compilateur, c’est quand même de laisser le développeur vérifier les choses à sa façon : il écrit l’histoire dans son test, et vérifie les choses comme il le souhaite. Qui plus est, le compilateur est certes capable de vérifier certaines erreurs bas niveau, mais il y a tout un tas de trucs que le compilateur ne sera absolument pas capable de vérifier, et qui nécessiteront des tests.

Alors quoi ?

Heureusement, aujourd’hui, la question est en fait tranchée : les développeurs utilisent les deux, en fonction à la fois du coût d’implémentation de chacun, et de l’expressivité de chacun. Cela dit, je continue à trouver cette question intéressante. Et, à titre personnel, je comprend parfaitement la décision de Kotlin et Swift d’empêcher les références null, même si je préfère une solution plus simple : je n’utilise autant que possible jamais de nullen Java. Et du coup, si NullPointerException il y a, c’est forcément un bug qui nécessitera un test. Est-ce que c’est plus coûteux que d’avoir des <Object>? à déréférencer ? Je n’ai pas l’impression. Mais bien sûr, je peux me tromper.

Ne livrez pas de document Office !

Vous travaillez sur un grand projet … ou un moyen.

Et par exemple, on vous demande de livrer de la doc sur le code, l’architecture. ou des éléments de volumétrie. Et là vous vous dites « je livre un Excel ! » ou « Je livre un Word ! ». Par pitié, ne le faites pas.

Pas parce que c’est moche, lourd, et peu conforme à vos valeurs éthiques de partage.

Mais plutôt parce que les fichiers Office ne sont pas compatibles avec un processus de développement, ou plutôt d’écriture ?

Parce qu’après tout, votre document a bien un cycle d’écriture, non ? Vous avez bien, sous une forme ou une autre, les étapes suivantes

  • Ecriture
  • Relecture
  • Livraison
  • Passage à la version suivante

Si ça vous rappelle le cycle de vie d’artefacts de développement, ça n’est pas un hasard, c’est la même chose.

Et d’un point de vue format, comment faire ?

D’abord, si votre livrable ne bouge plus, c’est que ça n’est pas le même format que celui dans lequel vous écrivez. Typiquement, quand vous livrez un PDF, par exemple, vous ne pouvez pas vraiment le modifier (mis à part hacks visibles).

Ensuite, dans l’idéal, vous cherchez un format qui vous permette de répondre aux critiques habituelles d’Office :

  • Pas de travail collaboratif possible
  • Pas de merge
  • Un outillage de composition de document assez faible

Autrement dit, vous cherchez un format source qui soit vraiment ça : un fichier source que vous pouvez gérer dans votre SCM, sur lequel vous pouvez faire des merge, et enfin que vous pouvez composer (ou compiler) dans votre chaîne de build. Eh bien, ce format existe. En fait, il y en a plusieurs, mais un seul qui marche : Asciidoc.

De nos jours, avec Asciidoctor, vous pouvez compiler votre doc via maven, et la gérer dans votre SCM (je le fais déja). Vous pouvez par ailleurs créer de gros documents en assemblant plusieurs fragments (voir leur fameux tag include). Et, comme vous créez votre doc avec maven, elle est packagée et livrée comme le reste de votre application.

Alors, pourquoi vous continuez à utiliser Office ? Parce que vos utilisateurs le demandent ? En vrai, je ne crois pas que ce soit une bonne raison.

Un chtijug élastique

D’abord, quelques annonces

A 20 € ! Ca va être dur de faire valider la note de frais.

Pour les slides, c’est par là

Elastic, c’est 4 projets open-source :

  • Logstash (malheureusement écrit en JRuby)
  • Beats (alternatives à Logstash en go beaucoup plus simple). il y a FileBeats, NetworkBeats, MetricBeats
  • Elasticsearch (moteur d’indexation et de recherche JSON. Ne loupez pas l’interview de notre speaker chez lescastcodeurs)
  • Kibana (outil de dashboard)

Et un ensemble de solution commerciales appelées génériquement X-Pack

En particulier, graph permet d’éviter le problèmes des supernoeuds dans les graphes (un problème auquel je suis assez sensible, mais je m’éloigne du sujet).
Et prelert va identifier les erreurs « exceptionnelles » grâce à de l’apprentissage.

A quoi sert elasticsearch ?

Ben à faire des recherches floues, où à trier les résultats de recherche selon … un score. Et floue, ça implique de gérer les fautes d’orthographe, les textes approchants, les synonymes, …

Et maintenant, le coeur de la présentation : ingest node

Avec ingest, on peut remplacer l’architecture classique

iyxfbszfiyqhkn3bp4briaqiaupaxelvvas7bogmpowa5ifpxazotebfsoa4r1ixorlc91qnp2o7foom9mtmmmtkjkco3cvfsa5c1vc85kpm5kqwtyzc0g00

par une architecture beaucoup plus simple

iyxfbszfiyqhkn3bp4briaqiaupaxekvvygmbsgc1wsc5ylda5hpag01gjopbpsrk8ihbwkkllvn3y880000

Du coup, le pipeline de transformation Logstash (grok, date, mutate) est remplacé par un équivalent ingest (grok, date, remove). Il y a naturellement tout un tas de plugins (dont la lecture d’attachments avec Tika). Bon, autrement dit, on remplace un ETL par un autre, espérons juste qu’il soit plus performant. Et évidement, on peut créer ses propres plugins.

Il y a quand même un gros intérêt, puisque les pipelines ingest sont utilisables dans la plupart des urls d’appel à Elasticsearch. Et en particulier, dans l’un des trucs les plus balaizes : le reindex. Ce reindex permet la migration facile d’un cluster Elasticsearch d’une vieille version vers une nouvelle. Et ça, ça me paraît vraiment très chouette.

Comme dans n’importe quel ETL, il est possible de définir des failure processors qui vont être utilisés en cas d’échec lors de la série de transformation. On peut les définir par pipeline ou par processeur.

Dans un cluster, (parce que oui, Elasticsearch fonctionne toujours en cluster), il est possible de laisser tous les noeuds faire de l’ingestion, on d’en forcer certains à faire l’ingestion. En prod, d’ailleurs, il vaut mieux séparer les noeuds d’ingestion des noeuds de données.

Et si on regardait un plugin ?

Par exemple, le fameux plugin BANO (déja mentionné chez les castcodeurs). BANO pour base nationale d’adresses, parce que David est fan des adresses postales. Et cette base, ce sont des documents CSV (ou JSON) disponibles chez OpenStreetMap.
Donc David a un plugin qui lui permet de charger dans Elasticsearch la base des adresses, puis d’enrichir les adresses et les localisations GPS en ajoutant la donnée inverse.

Et maintenant, c’est le moment de la démo !

Et franchement, au début, la définition de pipeline d’ingestion est assez facile, et la définition des failure processors est tout aussi facile. J’imagine très bien les interfaces très graphiques faisables là-dessus.
Pour la récupération des données, le fait que ce soit un moteur de recherche fait que des résultats moins pertinents pourront être retournés par les requêtes, mais derrière les résultats les plus pertinents.

Un autre élément intéressant, c’est que la recherche est foutrement rapide : l’ingestion d’une coordonnée GPS avec ajout automatique des adresses (et donc recherche dans l’index des coordonnées) est immédiate (pour autant qu’on puisse le voir). Même si la coordonnée GPS n’est pas exactement la bonne.

Et avec tout ça, et le processor GeoIP, il est par exemple possible d’envoyer un courier à l’adresse donnée lors de la requête HTTP. Ca fout la trouille, hein ?

Au passage, l’un des trucs les plus intéressants selon moi est l’utilisation de JSON pour exprimer les requêtes : le code n’est pas moins clair qu’avec un langage de requête dédié (genre SQL).

Un autre intérêt d’Elasticsearch, c’est qu’il supporte les tâches longues, qu’on peut suivre et gérer (pour par exemple tuer les tâches trop longues).

Non mais, et si on développait vraiment un plugin ?

Eh bien ce serait aussi simple que d’écrire une classe étendant une superclasse abstraite.
Evidement, quand on regarde le code, on voit des choses … curieuses : trouver le point le plus proche en calculant la distance de tous les points, je peux dire que c’est pas le plus efficace (il n’y a pas d’index géographiques ou quadtrees dans Lucene ? Ah si, à priori, avec les bkdtree de Lucene 6).
Dans le même ordre d’idée, déclarer ses plugins en associant une clé à une factory … alors qu’on peut faire du CDI ? C’est pas fameux. mais bon, tout le monde n’est pas censé écrire des plugins.

Conclusion

L’un des plus gros intérêts de cette présentation, c’est de sortir Elasticsearch de son rôle le plus connu de stockage ELK pour bien montrer qu’avant tout, c’est un ETL moderne qu’on sous-utilise volontiers.

Et personnellement, en voyant cette présentation, j’ai eu l’envie un peu folle de resortir mes projets de livestream pour les porter dans une base plus moderne.

Et pour la blague, le premier rang, c’est pratique pour démontrer la présence quand le speaker fait des selfies

Le quidditch, c’est pas si facile

Pour la troisième fois, je me suis lancé dans un des contests de Codingame.

Cette fois-ci, Harry Potter était à l’honneur.

fantastic_bits_ld-compressor-1

Oui, enfin, sans les combats de sorciers

En particulier, le quidditch. Enfin, un quidditch un peu simplifié : seulement deux sorciers, et, surtout, pas de vif d’or. Et heureusement, parce que j’en ai bien bavé pour en arriver à résultat un peu meilleur que la dernière fois, et surtout, cette fois-ci, raisonnablement satisfaisant, vu le temps investi :

score

707 sur 1950 qui passent atteignent le bronze, c’est bien. Mais s’arrêter à la porte de la ligue gold, ça craint.

EDIT : heureusement, une heure plus tard

score_1

Alors, comme la dernière fois, il y a des leçons à retenir.

D’abord, mon code magique qui produit des tests directement à partir du jeu est très pratique, mais nécessite que le code n’utilise jamais de random() sous quelque forme que ce soit. Cela dit, c’est tellement pratique ! regardez mes classes InGameTest, comme par exemple ici

test_generator

Et n’oubliez pas que ça vient directement de l’état du jeu à instant donné !

Ensuite, utiliser le bug tracker de GitHub comme bloc-note, c’est évidement pratique pour me garantir que j’ai traité le sujet efficacement. Et je m’en resservirai.

Enfin, j’avais une première implémentation que je savais boiteuse dès jeudi. Mais, si vous regardez mon historique de commit, vous verrez … rien ! En effet, le code que j’ai mis en place samedi et dimanche n’a pas été placé dans GitHub avant ce soir … Le fameux rush de fin de projet :-). Cela dit, il n’y avait peut-être pas de commits, mais il y avait des tests ! Et j’utilise toujours avec autant de profit mon plugin Maven qui génère le fichier source de codingame. Mais pour en revenir à cette histoire d’implémentation, clairement, il va falloir que je passe plus rapidement à la deuxième implémentation. Je dis deuxième, mais pour Hypersonic, j’ai enchaîné 4 implémentations différentes, donc n’en avoir que deux, c’est déja un net progrès. D’ailleurs, je pense ne pas vraiment pouvoir en faire moins. En effet, mis à part pour les super-tueurs genre Magus, il paraît difficile d’obtenir une première version qui soit à la fois correcte conceptuellement et efficace.

Mais bon, tout ça ne doit pas ôter quelque chose que j’ai écrit sur hypersonic : coder une de ces satanées IA est un sacré challenge, mais aussi un sacré fun. Et pour le coup, le quidditch était très bien grâce à sa complexité.

PS : Bravo à nmahoude :

Utiliser Eclipse derrière un proxy à la con

Vous connaissez les proxy à la con ? C’est une spécialité des grandes boîtes françaises qui ont une vision assez … restrictive … de ce qu’est un « bon » usage d’internet.

Par exemple, j’ai dû il y a peu installer un Eclipse pour me connecter à un serveur Subversion chez un client qui n’autorise pas l’accès à bintray. Pas grave ? Ca dépend.

Par habitude, j’utilise Subclipse. Or, récemment, ils ont changé leur hébergement pour passer .. chez bintray. Du coup, le plugin n’est plus téléchargeable. Heureusement, eclipse est modulaire, et j’ai pu installer Subversive « facilement » : pour installer Subversive, on installe d’abord le plugin, qui télécharge indépendamment les connecteurs sur un site qui a changé. Ca se passe bien sans proxy à la con. En revanche, dans le cas contraire, il faut télécharger l’update site contenant les connecteurs. Et c’est tout aussi merdique (même si, en fait, Subversive semble mieux que Subclipse – au merge dialog près).

Fiddler pour débugger à distance

Vous connaissez Fiddler ? C’est un très bon proxy de débuggage http pour Windows.

Eh bien aujourd’hui, j’ai découvert que je pouvais l’utiliser pour intercepter les requêtes entre un serveur Apache (sur une autre machine) et mon serveur web Java (lui aussi sur une autre machine). Le pire, c’est que ça n’est même pas compliqué.

Il suffit de régler le proxy pour accepter les requêtes distantes

2016-11-04-20_54_19-telerik-fiddler-options

Et de régler le proxy que fiddler utilisera pour recevoir les requêtes pour que ce soit l’autre machine

2016-11-04-20_56_38-telerik-fiddler-options

Et là, les requêtes arriveront bien d’Apache dans Fiddler pour repartir aussi sec vers le serveur.

Très cool.

 

Vite, un chtijug !

Je me demande si je n’ai pas déjà utilisé ce titre …

En attendant, hier soir, c’était chtijug spécial quickies.

HTTPS Everywhere avec let’s encrypt

Le HTTPS c’est mieux pour la confidentialité des utilisateurs. Let’s encrypt est une autorité de certification, dont le client essentiel est certbot.

certbot

Tourne sur n’importe quel Unix (oui oui). Il y a des plugins pour tous les serveurs web, même sur le Raspberry.

Démonstration avec un site Apache

S’ensuit une jolie démonstration avec des poneys en ascii-art. Et tant mieux, parce que certbot a une interface ncurses ! On note tout de suite les problèmes classiques liés à du https : le mixed content (images ou scripts chargés en http, …). Je note également le point « magique » de Let’s Encrypt : obtenir un certificat à la volée, c’est quand même vachement plus rapide que de le réclamer physiquement à un service de sécurité.

Validation du certificat

La partie intéressante de Let’s encrypt, c’est le mode de génération de certificat. Plutôt que d’utiliser la méthode traditionnelle avec échange de mail, ils reposent sur l’exposition d’un challenge en http sur le site pour lequel on veut un certificat. C’est assez malin, car plus facilement automatisable. Et j’imagine que certbot doit pouvoir automatiser ça

Démonstration avec nginx et webroot

Histoire de montrer les capacités de certbot, on refait la démo, mais avec une configuration manuelle, pour nginx.

Intérêt ?

Le certificat est renouvellé automatiquement tous les 90 jours ! Du coup, plus de problème d’expiration. Et ça, pour les noobs de la sécurité comme moi, c’est vraiment cool. Un point important à noter : Let’s encrypt ne fournit que des certificats de classe 1, donc avec une sécurité « moyenne ». Les classes 2 et 3 impliquent des vérifications physiques, qui sont évidement manuelles.

Point bonus : il y a une interface permettant de révoquer les certificats depuis le site de Let’s Encrypt, ce qui provoquera sans doute leur renouvellement automatique.

Ce que la revue de code m’a apporté

Julien commence par nous raconter sa vie de jeune développeur. Et, personnellement, je me reconnais mal là-dedans :

  • la fierté du code produit
  • la propriété du code (c’est le code de Julien)
  • Et enfin, il veut que son code soit beau longtemps

Du coup, ils ont mis en place chez Axa des revues de code avec des rôles identifiés pour limiter les procès en sorcellerie. Malheureusement, j’ai peur que ça ne suffise pas. Du coup, il faut apprendre plusieurs choses (qui, il me semble, font partie de l’expérience du développeur). La première étant évidement de faire preuve de bienveillance envers ses collègues, le fameux « dur avec le code, doux avec les gens ».

Axa consomme environ 5% de son temps à faire de la revue de code. C’est assez peu, vu que ça permet de détecter des bugs (en plus d’assurer une cohérence stylistique des livrables).

A priori, il faut environ 3 mois pour que les revues soient « apaisées ».

A la réflexion, il y a à mon avis quelque chose de complètement biaisé dans le fait que le développeur vienne présenter lui-même son code à un procès en sorcellerie. Il vaudrait sans doute mieux que le code soit défendu par un « avocat » sans que le développeur à l’origine du code puisse être reconnu. Parce que, comme je le dis toujours, le code qui est dans Subversion/Git n’est plus ton code, c’est celui de l’équipe. Et c’est ce qui le rend magiquement sale.

lunrjs

lunrjs est un portage de Lucene pour javascript, utilisé chez Decathlon. Et sur le site de Decathlon, actuellement, quand on change un filtre de recherche, la page est visiblement rechargée (ce qui n’est pas terrible en termes de performances). Un portage, mais un peu restreint, puisqu’on perd par exemple les recherches de termes approchants.

A noter qu’actuellement, le catalogue produits de Decathlon est hébergé en SAAS, ce qui est … osé, je trouve.

Cela dit, je n’ai pas trouvé ça si impressionnant. Parce qu’il existe déja des tonnes d’API javascript pour exploiter le local storage « correctement ». En fait, le seul intérêt de lunrjs, c’est de compléter les recherches disponibles dans Lucene pour les déconnexions, mais je trouve le cas d’utilisation assez rare pour ne pas investir spécifiquement dessus. A mon sens, travailler sur une vraie API client/serveur dans le navigateur permettrait plus facilement d’attaquer ce type de problème. Sauf, bien sûr, si l’objectif du projet est précisément d’étendre Lucene, mais c’est plus de l’ordre du patch que de l’évolution en profondeur.

Cerberus

Donc, cerberus est un outil de test fonctionnel automatique. Des outils comme ça, il y en a … déjà … des tonnes. Alors pourquoi La Redoute s’est lancée dans cette guerre des tranchées ? Comme d’hab, l’hubris (autrement dit « il n’existait pas de solution correspondant à leur besoin »). Cerberus se place donc entre les différentes équipes, pour fournir un référentiel commun. ce qui implique également que les tests puissent être décrits par les fonctionnels ou les développeurs. Et comme un outil comme HPQC, il offre tout un tas de fonctionnalités, comme le support multi-technologies, multi-langues, multi-environnements l’exécution adaptative des tests, la génération de rapports ou l’intégration dans les outils de développement du SI (IC, bug tracker, …).
Bon, j’avoue, j’ai décroché lors de la démo. Parce que vraiment, on est face à de l’outil de test fonctionnel très haut niveau, où les étapes peuvent être effectuées manuellement ou automatiquement. Ce qui ne m’inspire qu’une chose : ces outils ne sont pas faits pour le monde d’aujourd’hui, mais pour les bonnes grosses applications traditionnelles des entreprises qui ont encore des équipes dév, fonctionnelles, test, différentes, et des processus de livraison longs et lourds. Dans ce cadre, j’imagine que ça doit marcher. Mais dans le cadre hyper-mouvant du web de 2016, je ne suis pas sûr que ça bouge assez vite.

Conclusion

Je peux paraître un peu dur avec certains des talks, mais ça n’est pas mon but. Le contenu ne m’a peut-être pas autant intéressé que les orateurs l’auraient souhaité, mais ça n’ôte rien à leur prestation. Les quatre présentations étaient en effet bien préparées, construites, bien organisées. C’est juste que chaque auditeur met ses propres filtres sur les sujets qui lui sont présentés … Bravo encore au chtijug qui arrive toujours à trouver des choses intéressantes à nous présenter (eh oui, ça n’est pas parce que ça ne m’a pas plu que ça n’était ps intéressant).

Vendredi, c’était TakeOffConf

Vous ne connaissez pas la TakeOff ? la conférence la plus barbue au nord de la Seine ? Tant pis pour vous. Par une chance extraordinaire, j’ai pu obtenir une place pour assister aux conférences du Vendredi … Mais du fait d’obligations, je n’ai pu voir que celles du matin. En voici un rapide compte-rendu.

How to rescue tech migrants from Brexit

Un talk « tongue in cheek » expliquant que les anglais allaient fuir leur pays pour venir se réfugier … à Lille. Il recense quelques bonnes habitudes à prendre pour intégrer les nouveaux, comme par exemple trouver un tuteur pour les nouveaux arrivants, faire en sorte de vaincre les problèmes d’I18n/l10n comme par exemple

  • Vaincre la barrière de la langue
  • Les foutus claviers différents

C’était pas mal, et très flatteur pour Lille

Create modern web APIs in minutes

Ca parle d’API Platform, en PHP

Il y a plein de standards de description d’API

  • Swagger
  • JSON-LD (standard W3C), déjà utilisé et compatible web sémantique
  • Schema.org vocabulaire ouvert pour le web, hébergé par le W3C, compatible JSON-LD
  • Hydra
  • RAML

API Platform, donc, permet de développer une API en PHP et supporte tout ça, ainsi que tout un tas de features habituelles comme la pagination, le filtrage, l’auth (JWT, Oauth), le cache, CORS. Bon, je suis un peu passé à côté en bon développeur Java(EE).

Sharing code between web and native mobile apps

Dans le développement mobile, maintenant,

  • Web => Audience
  • Native app => rich experience.

Du coup, les deux sont nécessaires. Et donc NativeScript fournit un truc qui ressemble à ionic pour Angular 2

Le plus gros avantage, c’est qu’avec electron, on peut aller jusqu’aux applications Desktop

Il y a néanmoins un système de distribution curieux avec WebPack et des extensions de fichier selon le canal d’utilisation. mais là, c’est sans doute ma méconnaissance du sujet qui parle.

Let your devices talk to each other

Dans l’IoT, les données sont centralisées (et pas stockées sur les machines). Et c’est galère quand les serveurs tombent en rade. Au contraire, en M2M, les données sont décentralisées. Du coup, pourquoi ne pas utiliser les concepts du second dans le premier ? Par exemple, en laissant les devices se découvrir en P2P. Mais comment se connecter en P2P sur un réseau local ? En utilisant de la discovery (Bonjour, JmDNS, UPnP)

Et que vient faire CouchBase là-dedans ?

Présenter Couchbase Lite ! En ayant une base de données locale synchronisable avec le serveur, on permet plus facilement la déconnexion du serveur. Et la base peut se synchroniser en P2P. Clairement, ça aurait pu me servir il y a des années.

Building a Web API with Hanami

Pas de monkey patching, pas de method_missing … Construit en opposition avec Ruby on Rails, autrement dit. C’est un framework web pour Ruby qui semble assez élégant et conçu autour de concepts très simples. Mais bon, comme pour le PHP, ça ne me touche qu’à moitié.

Elixir a language for the Future

Dans ma mémoire, c’est un framework web basé sur Haskell … mais en fait, c’est un langage pour le futur.

Pour le speaker, le futur est

  • Dynamique
  • Concurrent. Et pour ça, Ericsson a inventé … Erlang !

Du coup, Elixir, c’est

Ruby+Erlang+steroids=Elixir !

Quelques éléments sont bluffants, comme le pattern matching sur les paramètres de méthode. D’autres sont … moins impressionnants, comme l’utilisation de tous les coeurs qui surprend en Ruby, mais vraiment pas en Java.

Et c’est tout ?

Ben oui, c’est tout. le reste du temps, j’étais pris. Cela dit, c’était un chouette moment.