Retour d'expérience d'un frontalier français qui travaille à Genève. C'est dommage qu'il ne parle pas du 3ème pilier. Tout le reste est bien.

Tout à fait d'accord ! Ajouter aussi ceci...

Dans les trucs difficiles mais encore tenables / ajustables :

• Votre paire n'a pas les mêmes raccourcis claviers que vous.
• Votre paire n'a pas les mêmes logiciels (IDE) que vous.
• Votre paire utilise un autre type de clavier que vous (eg. QWERTY vs AZERTY).
• Votre paire n'a pas du tout le même niveau que vous.
• Votre paire n'a pas les mêmes goûts / besoins en termes de coloration syntaxique que vous.
• Votre paire a besoin d'un autre niveau de luminosité que vous.
• Votre paire n'a pas besoin de même niveau de zoom que vous (ie. mauvaise vu).

Dans les trucs vraiment durs pour moi :

• Vous êtes une femme et votre paire est un homme... Célibataire... Peu intéressé par son travail mais plus par vous.
• Votre paire se permet des contacts physiques que vous n'auriez jamais eu avec lui sans l'excuse du pair-programming.
• Votre paire n'a pas le même sens de l'hygiène corporelle que vous.

Retour d'expérience d'une équipe d'Amazon Prime sur l'utilisation de Kotlin à la place de Java.

Overall : 75% de devs satisfaits de la transition.

Je me souviens que je disais en 2010 à @Roger quelque chose du type :

La programmation fonctionnelle est un cancer.

Heureusement, dix ans plus tard j'ai quand même un peu changé d'avis sur la question, je dirais aujourd'hui :

La programmation fonctionnelle "pure" est un cancer.

La différence étant que je suis en mesure d'argumenter le ressenti inconscient que j'avais à l'époque. Depuis le bouquin sur les design-patterns du Gang of Four, nous avons eu une pléthore d'autres auteurs qui nous ont expliqué pourquoi il faut toujours dépendre des interfaces et jamais des implémentations. Le problème avec ça, c'est qu'une grande partie des développeurs ne comprennent pas bien ce que sont les implémentations et surtout pourquoi il ne faut pas dépendre d'elles.

En réalité, une implémentation embarque avec elle des attributs (et si un objet n'a pas d'attribut c'est que le développeur a codé en procédurale "pure", il n'a rien encapsulé, ça n'est pas objet du tout mais je m'égare). Le problème avec les implémentations ce sont justement les attributs qui deviennent visibles. Dit autrement nous commençons à devenir dépendant de la structure de données qui nous arrive et non plus d'un ensemble de fonctions (ie. méthodes) que nous pouvons exécuter. D'ailleurs nous sommes tellement dépendant des attributs que même s'ils sont privés, nous allons alors ajouter des getters/setters pour y accéder quand même.

Remonter à l'interface c'est casser ce lien explicite avec la structure de données embarquée dans une classe et alors un changement de structure ou de structure de la structure n'impactera pas le code utilisateur.

Mais alors quel est le problème avec la programmation fonctionnelle "pure" ?
C'est justement qu'elle pousse tous les morceaux de code à dépendre des mêmes structures. Changez la structure à un endroit et vous êtes partis pour changer toutes les fonctions qui s'appuient sur cette structure. Cela engendre fondamentalement un maillage global de tous les pans de code d'une application avec un couplage fort autour de cette ou de ces structures.

La seule condition pour y remédier c'est d'avoir "la bonne structure du premier coup"... lol quoi... Comment prévoir quelles données (et de quels types) nous arriveront demain ?

À l'inverse, retourner des implémentations d'interface autoboxé dans le type de cette interface (c-à-d. les fameux "messages" de la POO) garanti non seulement que les changements de structures n'auront pas d'impact, mais que les changements d'algorithmes non plus (ici "pas d'impact" est à prendre au sens où le contrat d'interfaçage n'est pas rompu et donc que le code continu de compiler).

Pourquoi est-ce que je vous parle de tout ça ?
À cause Rust et de mes quatre semaines d'immersion intense.

Soyons clair, je trouve que les concepts derrière le langage sont incroyables et ses performances merveilleuses (en tant que dev Java j'ai toujours détesté la JVM rien que pour ce sujet). Par contre le fait que Rust se soit tourné exclusivement vers le fonctionnel et la programmation en "structure-first" à la place de celle en "contract-first" car la majorité des devs ne parviennent pas à penser en objets avec l'encapsulation, cela fait de Rust un langage aussi immaintenable que C mais un peu plus fiable grâce à son meilleur compilateur.

L'API de Rust est digne de celle du C. Par exemple, prenons la méthodes HashMap::keys()de la stdlib de Rust. Celle-ci aurait pu retourner l'implémentation d'un trait Iterator mais non, elle retourne une structure Key qui contient une structureIter qui contient une autre structure base::Iter.

Changez un morceau de la chaîne et préparez-vous à gérer les impacts partout.

En résumé, et après être passée dans l'ordre par Java, OCaml, PHP, C, ASM, Bash, CSH, Python, JavaScript (ES5 à ES7), Anubis, Haskell, Ruby, Groovy, TypeScript, Scala, Go, Kotlin et enfin Rust (ndr. je bidouillais en Rust depuis quelques années), je peux vous assurer que :

1. Rust est techniquement un super langage avec l'un des meilleurs compilateur du marché.
2. Rust a une API aussi pourrie que celle de C, encourageant le couplage et augmentant l'immaintenabilité. Je crois qu'il doit exister un moyen d'outre-passer cela, mais je ne sais pas encore comment faire et ça me fruste pas mal.

Enfin, je sais que certains dev vont être fâchés de lire ce que j'écris alors permettez-moi de vous proposer un test car j'ai le sentiment que si c'est le cas, c'est que vous n'avez jamais pensé en OOP - et donc que vous ne pouvez pas encore comprendre ce que je dis. Il s'agit d'un exercice que @Kysofer a imaginé pour ses entretiens d'embauche afin de savoir si un candidat "expert Java" savait penser et programmer en orienté objet.

Prenez ces deux classes :

class Person {
    private final String name;
    private final String firstName;
    private final int age;

    public Person(String name, String firstName, int age) {
        this.name = name;
        this.firstName = firstName;
        this.age = age;
    }
}

class Car {
    private final String brand;
    private final String name;

    public Car(String brand, String name) {
        this.brand = brand;
        this.name = name;
    }
}

Objectifs :

• Sans violer l'encapsulation, c'est-à-dire sans jamais accéder aux attributs des deux classes depuis l'extérieur de ces deux classes.
• Sans ajouter des getter ou des setter.
• Sans mettre les attributs en public, package ou protected.
• Sans implémenter les algorithmes de conversion à l'intérieur des deux classes elles-mêmes.

=> Écrivez une architecture qui soit capable de convertir en JSON ou en XML ces deux objets.

Indice : Quand on pense en objet, c'est évident, très facile même. Quand on ne pense qu'en procédurale ou son évolution en fonctionnel, cela paraît impossible.

Et dans tout ça je ne compte pas arrêter Rust pour autant mais je fais appel à mes amis pour qu'ils m'aident à trouver une façon "clean" de coder dans ce langage.

Sans blague... Utiliser un des compilateurs les plus difficiles du marché (ici Kotlin) prévient une grande partie des bugs et réduit leur nombre de 33%, le cas présent sur l'application Google Home depuis Que Goole a remplacé le code en Java par Kotlin.

C'est un peu comme si les langages interprétés et sans contrôles ultra-stricts à la compilation étaient moins efficaces... La surprise est totale ! (Ô__Ô) #Kotlin #Rust

Tiens j'entends comme un écho qui dénigrerait Python... Et quelqu'un d'autre qui tousse très fort JS/NodeJS... Vraiment bizarre, allez savoir pourquoi #TrollInsideOuPas

Un REX intéressant sur les microservices.

En même temps, existe-t-il une banque chez qui "il faudrait aller"... Mais bon, se faire tirer son fric par un organisme bancaire (hors période de "crise"), j'avoue c'est pas mal !

Je cite le post :

« Pour gérer les frais de notre ménage, nous avons créé en janvier un compte sur cette banque. @N26FR nous demande de donner quelques informations, que nous avons envoyé, et nous dote rapidement d'une carte et d'un compte. Jusqu'ici tout va bien.

J'y dépose chaque mois à peu près la moitié de mon salaire pour payer mon loyer et mes courses + épargner pour mes vacances. Ces virements sont plus ou moins fixes et à dates fixes également.

Tout va bien jusqu'à tout à l'heure, où je reçois un mail m'informant que "suite à une violation majeure des conditions d'utilisation", mon compte sera clos sans recours et que je dois en retirer mes fonds immédiatement. On ne me dit pas de quelle "violation" il s'agit. La seule chose que le mail précise est qu'il faut que je me rende sur leurs CGU. L'article cité ne mentionne que des conditions d'accès au crédit (que je n'ai pas contracté) et un "changement brutal de situation" (qui n'a pas changé).

Me disant que c'est peut-être une erreur, je me rends vers leur service client, où il m'est signalé que

1. Oui, mon compte va fermer
2. Non, on ne me dira pas pourquoi
   et on me ferme le chat au nez immédiatement.

La banque ne donne aucune info et aucun service capable de nous donner la moindre info n'est accessible. De ce que nous sachions, aucune violation du compte n'a eu lieu. Nous avons juste payé notre loyer et nos courses avec le compte. Le mail nous avertissant que le site allait nous saisir notre argent est arrivé dans les spams, au passage. Sur internet on trouve des gens ayant perdu des 5000€ comme ça.

Donc si vous avez de l'argent sur un compte @N26FR : prenez-le, barrez-vous. Allez chez une banque honnête, celle-ci ne l'est pas.

Pour info cette situation n'est pas personnelle mais concerne apparemment beaucoup de monde : https://www.60millions-mag.com/forum/banque-epargne-credit-f76/banque-n26-probleme-compte-bloque-et-aucunes-informations-t55685.html »

GitLab, le gestionnaire de référentiels Git basé sur le Web et développé par GitLab Inc. a été développé en Ruby on Rails (RoR), un framework web libre écrit en Ruby qui suit le motif de conception modèle-vue-contrôleur (MVC). Les co-fondateurs du projet nous donnent ici les raisons de ce choix. Lorsque Dmitriy Zaporozhets, cofondateur et membre de l'ingénierie, a décidé de construire GitLab, il a choisi de le faire avec Ruby on Rails, bien qu'il travaillait principalement en PHP à cette époque....

L'interview est très drôle aussitôt que l'on n'oublie pas son esprit critique. Je m'explique, le fondateur de Gitlab nous apprend que lui et son associé ont pris Ruby comme langage (alors que lui venait du PHP) et Rails comme framework (parce que ce dernier est très mature, super stable, documenté, toussa). Bref, le mec vante les mérites incroyables de RoR (Ruby On Rails) et des Gems Ruby, en clair que cette stack est juste incroyable...

Sauf qu'il explique après qu'ils ont du recoder une partie du kernel de Gitlab en Go (et aussi en C, de ce que j'ai pu constaté dans le code) car Ruby bah ça rame... La GUI a été recodée en Vue.js à la place de Rail, car RoR n'est pas assez "réactif" et ça rame et d'autres technos encore (NodeJS / Mongo / PHP / Redis lorsque l'on ouvre le capot). D'ailleurs et d'expérience, Gitlab est une des pires technos que je connaisse du point de vue OPS car elle contient bien trop de choses à installer, trop de systèmes de caches à configurer, trop d'utilisateurs Unix à créer, trop de permissions à affecter, etc.

Bon, le gars justifie le fait que ses choix technologiques étaient les meilleurs mais qu'ils ont du tout recoder quand même car RoR n'était pas adapté... Hum hum best choice ever donc pas vrai ? (눈_눈) #Bullshit

Si ce choix avait été le meilleur, rien n'aurait dû être recodé. RoR n'était tout simplement pas le meilleur choix. RoR est très bien pour les petites applications et les prototypes mais ne tient pas la charge. D'ailleurs l'implémentation JRuby (qui tourne sous Java) est plus rapide à l'exécution que l'implémentation d'origine !!! Le créateur de Ruby est bon pour créer un langage mais pas bon pour coder. Et encore, ne pas avoir du multi-thread natif et facile à utiliser en 2019 (typiquement les coroutines de Kotlin ou les async / await de TypeScript) ce devrait être considéré comme trèèèèèès embarrassant.

Pourquoi ce post alors ?

Parce qu'il dégouline de bullshit. Les mecs de Gitlab ont du recoder leur application mais il faut rassurer leurs investisseurs. Ils ont fait des choix discutables en mixant 5 ou 6 langages de programmation au sein du même outil (de ce que j'ai constaté Go, Ruby, C, PHP, JavaScript, SQL et NoSQL - et encore je m'étais arrêté là en 2018 d'où notre choix de Gitea qui avait le mérite d'être consistant même si moins fonctionnel déjà à cette époque).

Et en lisant l'interview, toute la novlangue du type est déployée pour réécrire une histoire technique désastreuse d'un projet commercialement fabuleux. Voilà pourquoi j'écris ce post, pour dénoncer cette réécriture "de vainqueur" qui devrait vous faire réfléchir à deux fois à la direction que prend Gitlab. #TraduisonsLes

Cela fait quelques semaines que je travaille avec les VPS d'OVH mais avant d'aller plus loin, je dois préciser :

• J'ai une offre VPS SSD 3 à 11,99 € HT / mois.
• J'ai aussi souscris à l'offre SNAPSHOT à 2,99 € HT / mois.

Mon retour : l'offre SNAPSHOT d'OVH ne fonctionne absolument pas.

Dans les détails croustillants

• La restauration de mon SNAPSHOT se retrouve systématiquement bloquée.
• L'explication que le support est parvenu à me remonter est que plusieurs robots interviennent dans la restauration mais l'un d'entre-eux foire après un certain nombre de relances en échec.
• OVH n'a jamais identifié le robot incriminé (ni pour eux-même ni pour que je puisse les aiguiller, lors d'un éventuel support suivant).
• Je ne suis pas certaine qu'ils vont investiguer sur la question puisque je suis peut-être la seule à être touchée.
• Ce problème pourrait toucher plusieurs datacenters mais le support n'est pas catégorique sur cette question.
• Quand vous restaurez un SNAPSHOT, celui-ci est automatiquement supprimé, il faut alors veillez à en refaire un aussitôt.
• Quand le support débloque à la main votre SNAPSHOT, l'opération prendre entre 3h (ce coup-là j'avais eu de la chance) et 7h... En moyenne comptez 4h30 avec un service en carafe totalement inexploitable (puisque toutes données enregistrées pendant cette période seront supprimées au moment de la restauration qui interviendra aléatoirement entre H et H+7 #Youpie)...

Solution proposée

• Payer plus cher leur offre Public Cloud... #MêmePasPeur #AuServiceDeTesClients.
• Éclater son gros VPS en plusieurs petits pour gérer ce phénomène d'indisponibilité mais soit même #DemerdenZizisch.
• Passer par les réinitialisation/réinstallation des VPS à la place. L'opération ne prend "que 30 minutes" et on repart totalement de zéro (heureusement il y a Ansible).
  • Attention, à ce moment-là, vous perdrez l'éventuel SNAPSHOT que vous auriez fait #OhhhhhhhhhBahZutAlors.

Mes conseils / avis

• Si un SNAPSHOT vous est indispensable, trouver un autre prestataire qui sache les gérer.
• Faire sans SNAPSHOT.
• AWS si vous n'êtes pas contraint par le RGPD.

J'ai le sentiment qu'OVH vend un produit pas fini (les SNAPSHOT sur OpenStack / KVM) et qu'elle ne maîtrise pas du tout #ImageDeMarque #MenteurMenteur.