Un bel exemple d'exécution parallèle et de résultat synchrone en Kotlin.

@Animal je te recommande cet article pour mieux comprendre le travail que tu feras avec @Milk et @Sigmund.

La documentation expliquant un à un les contrôles applicables par TSlint sur du code Typescript.

Le concept du Test, Commit, Revert (TCR) est sympa.

Comment notre façon de programmer est-elle devenue asynchrone et bloquante ? C'est vrai que je passe mon temps à revenir sur des pull-requests qui ont eu lieu plusieurs jours auparavant ; et c'est dur à chaque fois ! J'aime coder et oublier le code que je viens de coder aussitôt que la PR part. Je n'aime pas qu'on me relance sur un sujet que j'ai fermé car c'est une charge cognitive forte et épuisante et pourtant ce modèle est devenu le modèle "standard".

=> Pour @Chlouchloutte

Via Riduidel

Je vais faire ma mijaurée mais pas grave.

Quand je lis :

L’architecture applicative apporte une réponse à la question suivante :

Comment les éléments fonctionnels sont ils implémentés ? Le COMMENT ?

Cette architecture représente l’implémentation des services fonctionnels sous forme d’éléments applicatifs.

Elle est composée d’éléments applicatifs (ex : composants Java, .net, objets BDD,…). L’architecture applicative représente le premier niveau d’une projection entre une architecture fonctionnelle (et ses services métiers) et des technologies qui vont devoir supporter ces services. Elle est une instanciation de l’architecture fonctionnelle.

et ceci :

L’architecture technique apporte une réponse la question suivante :

Avec quels éléments techniques, les éléments applicatifs sont ils déployés ? Le AVEC QUOI ?

Cette architecture décrit l’infrastructure sur laquelle les éléments applicatifs ont été déployés.

Elle est décomposée en deux couches :

• Une couche de logiciels médiateurs (ou middleware) qui est composée des progiciels : moteurs des bases de données, serveur d’application, serveur web, annuaire LDAP, ordonnanceur, gestionnaires de flux (EAI, ESB, ETL, …), etc.

• Une couche matérielle qui est composée des logiciels de base (systèmes d’exploitation), des serveurs et des réseaux.

Mon petit cerveau de lémurienne fait tilt ! Sur quel critères rationnels, objectifs et argumentés LDAP serait plus du côté de l"architecture technique que du côté de l'architecture applicative ? Même question mais dans l'autre sens pour Java ? Quid des "objets BDD", de l'ordonnanceur, du gestionnaire de flux, ie. un BPM ? Un F5 ? Un load-balancer ?

Bref, la réalité est simple : l'architecture applicative et l'architecture technique constituent le même objet, elle sont la même chose ! Et le choix d'architecture doit être uniquement pris par les équipes produits constituées de développeurs.

Car oui, l'architecture, c'est du code point. Un design orienté micro-service, c'est du code. Le choix de frameworks, c'est du code qui impact du code. Les flux de données, c'est du code sous contrainte.

Les architectes sont dans un délire pluri-décennal consistant à croire que c'est leur compréhension qui part en production, or c'est archi-faux ! Leur position est d'être celle du dirigeant, du leader alors qu'elle devrait se contenir à celle d'un documentaliste ou d'un bibliothécaire #CommentCaCoupBas.

Moins d'architecte & Plus de développeurs => meilleurs logiciels de meilleurs qualité.

Quant à tout ceux qui pensent le contraire, les logiciels les moins fiables sur terre ont des équipes bardées d'architectes (coucou Microchiotte) tandis que ceux qui sont les plus fiables n'ont quasiment que des développeurs (coucou Linux, les logiciels libres & stuff).

Aussi, c'est certes un sophisme que de conclure + d'architectes => + de problèmes car corrélation n'implique pas une causalité, mais ce sera quand même ma conclusion car je n'ai aucun contre-exemple depuis 15 années passées sur le terrain !

Je reporte ici les montants :

• Injure sexiste (en privé) => 1 500 € d'amende
• Injure publique => 12 000 € d'amende
• Injure sexiste publique => 45 000 € d'amende + 1 an de prison
• Propos à connotation sexuelle répétés => 30 000 € d'amende + 2 ans de prison
• Incitation au viol => 45 000 € d'amende + 5 ans de prison

Merci à Caroline De Haas pour l'info !

Pour @Chlouchloutte et @Lenny.

Chlouchloutte et moi discutions aujourd'hui du kata de code consistant à écrire un convertisseur de nombre décimaux en nombre romains. Son comportement est le suivant :

• À partir d'un Integer, je dois pouvoir récupérer sa valeur en écriture romaine sous la forme d'une String.

Comment le coder façon Yegor Bugayenko ?

Il y a deux façons de voir ce problème :

1. Mettre en avant le concept de nombre
2. Mettre en avant le concept de conversion.

1) Représenter d'abord les nombres

Je vais écrire l'interface suivante :

interface Converter {
    fun value():String
}

Et un implémentation :

class IntegerAsRomanNumber(
    private val number:Integer
) : Converter {

    fun value():String {
        // Conversion code
    }
}

// Usage
val number = 123
val romanNumber = IntegerAsRomanNumber(number).value()

2) Représenter d'abord l'action de conversion

Nous conservons l'interface mais en précisant la structure dans le nom de la méthode :

interface Converter {
    fun romanValue():String
}

Et son implémentation :

class Number(
    private val number:Integer
) : Converter {
    fun romanValue():String {
        // Conversion code
    }
}

Vous avez du remarquez que l'implémentation sera la même dans les deux cas et que la seul chose qui diffère sera le "wording". En réalité la première façon est verbeuse mais pratique puisqu'elle nous masque la problématique de conversion au profit de la mise en exergue du nouveau type de la donnée. Ce qui nous permettrait de créer plusieurs convertisseurs nous permettant de passer d'un type à un autre comme suit :

interface Converter<OUTPUT> {
    fun value():OUTPUT
}

Exemple d'utilisation :

val number = 123
val egyptianNumber:String = RomanAsEgyptian(IntegerAsRoman(number)).value()

Et le concept de décoration fait sens à ce moment.

Le titre est put-a-clic mais Timo a toujours cette perspective intéressante lorsqu'il parle de phénomènes de société. Ici, l'enseignement du code à l'école.

Comme certains le savent peut-être, je vais changer la structure juridique de ma société et je me renseigne sur les différents types de sociétés possibles, principalement dans un cadre avec plusieurs associés. Ce soir je découvre les Société en Nom Collectif (SNC).

Pourquoi est-ce que je vous en parle ?
Tout simplement parce que le phrasé du Code Civil expliquant la responsabilité du Gérant d'une SNC est juste à vomir de complexité. Je vous en cite une ligne (bonne soupe) : "1382 du Code Civil : Tout fait quelconque de l'homme qui cause un dommage à autrui oblige celui par la faute duquel il est arrivé à le réparer."

Indigeste n'est-ce pas ? Ponctuation, tournure, sémantique, rien n'est simple. À noter qu'une phrase similaire, toujours en français j'aime-me-caresser-le-pistil mais qui serait déjà plus abordable, donnerait : "Tout auteur d'un dommage causé à autrui doit en réparer le préjudice."

Sachez que le mouvement des #GiletsJaunes revendique justement le RIC (Referendum d'Initiative Citoyenne) et l'une des raisons pour lesquelles cet outil politique est indispensable, c'est qu'il contribuera à l'éclaircissement du droit puisque ce dernier y serait écrit par des "gens simples pour des gens simples".

Dit autrement, le Code Civil actuel, c'est du putain de code Scala obfusqué ! Seule une infime partie de la population kiffant cette merde continue désespérément de défendre une immondice en terme de complexité et de charge cognitive (et je dis cela en adorant Kotlin, Rust et TypeScript hein).

Certaines personnes ont le besoin de se créer une charge mentale, ou plutôt de générer une charge mentale aux autres, pour se sentir plus fortes ou meilleures que leur prochain. Je pense que certains juristes et certains scalaïstes partagent ce triste point commun.

Pour Doudou notamment.

Contrairement à Sebsauvage ici je ne dirai pas que le dev de SQLite soit un "bigot à la con". Le mec a une religion (et donc une opinion religieuse) à laquelle il tient. Parmi l'ensemble des points proposés, je ne me retrouve pas dans la croyance en un Dieu tout puissant, ni en le Christ (que je pense être une fable), ni en la prière, bref ni dans tout ce que le dogme d'une église prodigue ; et quelque soit cette église.

Par contre, pour ce qui est du reste (tu ne tueras point, tu ne seras pas envieux, tu ne blâmeras pas les autres à part toi-même #toussa) j'ai du mal à comprendre en quoi ce sont de "mauvaises valeurs" pour gérer une communauté ou définir un code de conduite.

Sebsauvage, je ne pense pas qu'il faille être anti-religieux à ce point. Je n'apprécie pas la chose d'une manière générale, cependant je ne suis pas comme AstronoGeek - dont j'apprécie l’œuvre - mais qui transpire le narcissisme et le sentiment de supériorité parce que "lui il sait".

En tant qu'agnostique (parce qu'on ne peut démontrer ni l'existence ni l'inexistence de Dieu), je pars du principe qu'une morale qui vise à minimiser la souffrance de l'autre n'est pas fondamentalement une mauvaise morale ; et que comme toute morale, elle peut avoir des faiblesses par endroits #MoraleUtilitariste.

Enfin, au regard du fait que facilement la moitié de l'humanité croit en ce code de conduite, et que les points inscrits par le dev de SQLite ne font apparaître aucun critère de race, de sexe ou de religion (autre que les religions polythéistes - mais bon, il ne doit plus avoir beaucoup de mecs qui croient en Zeus ou en Odin de nos jours hein...), bah ce code de conduite a le mérite de parler au plus grand nombre.

Enfin Sebsauvage, techniquement tu viens de violer ce code de conduit à l'instant même où tu as publier ton commentaire sur ton Shaarli. Aussi, le mec de SQLite a-t-il eu tort ?