Page de la documentation officielle du framework CSS Bulma expliquant comment personnaliser le thème du framework en passant par les CSS var plutôt que les variables SASS.

Des techniques d'optimisation de la memoire en Java. Pour @Animal

Je cherche à comprendre comment charger le navigateur embarqué de Java FX dans un client lourd. Je ne sais pas si ce projet fonctionne mais ce sera un premier pas vers l'obtention d'un PoC qui marche.

Je suis tombée sur cet autre repo qui a deux avantages :

1. Il va droit au but en affichant un index.html
2. Il s'appuie sur les modules de Java 9+

Je dois refaire du front depuis la semaine dernière et c'est bien moins facile que dans mon souvenir.

Ici, un post sur SOF qui explique comment séparer ses CSS de sorte à limiter les impacts lors des refactos, et faciliter la maintenance et évolutions (e.g. créer des composants multi-thèmes).

Je dois écrire un µ-service en Rust et j'ai cherché pas mal de serveurs web permettant de le faire. Évidemment, la première chose que les moteurs de recherche nous remontent c'est Hyper. Pour faire simple, Hyper est une serveur HTTP 1/2 qui s'appuie sur le pool de threads asychrone Tokio.

Problème, Hyper reste assez bas niveau. Je recherchais donc quelque chose aux performances équivalentes mais bien plus simple d'utilisation et je suis tombée sur Actix qui à l'air de faire le café. Je regrette uniquement la reprise du annotation-driven-bullshit via les macros déclaratives mais en dehors de cela, tout va bien.

Exemple de hello world en Actix / Rust :

use actix_web::{get, web, App, HttpServer, Responder};

#[get("/")]
async fn index() -> impl Responder {
    "Hello, World!"
}

#[get("/{name}")]
async fn hello(name: web::Path<String>) -> impl Responder {
    format!("Hello {}!", &name)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| App::new().service(index).service(hello))
        .bind(("127.0.0.1", 8080))?
        .run()
        .await
}

Article vraiment très bien proposé ici par @Sebsauvage.

On se rapproche très fortement de ce que propose David West dans Object Thinking (livre qui a 20 ans déjà) et Yegor Bugayenko dans Elegant Objects (livre qui doit fêter ses 8/9 ans). Je me permets de compléter la solution de la pratique n° 3.

L'auteur propose d'encapsuler la hauteur dans une entité, ce qui nous donne :

// Primitive contenue dans un objet (aussi appelé Value Object)
class ArticleHeight {
      private value: number;

      constructor(value: number) {
            if (value < 10) {
                 throw new HeightCanNotBeLessThanTen();
            }
            if (value > 100) {
                 throw new HeightCanNotBeGreaterThan100();
            }
            this.value = value;
       }
}

// passage de notre ArticleHeight dans le constructor
class Article {
     private height: ArticleHeight;

     constructor(height: ArticleHeight) {
          this.height = height;
     }
}

// eh voilou !
class AddArticleUsecase {
     execute({ height }) {
          //...
          const article = new Article(new ArticleHeight(height));
          //...
     }
}

Pas moi. Je propose que la classe Article s'attende à recevoir en paramètre une interface Height dont l'une des implémentations possible soit une ArticleHeight mais qui pourrait très bien être une valeur venant d'une BDD au moyen d'une HeightFromBdd (pas le meilleur nom, mais c'est pour représenter l'idée).

Ceci casse le couplage entre deux classes concrètes et subséquemment facilite les mocks/stubs durant les tests dont l'auteur ne parle pas.

Ce qui nous donne

// Primitive contenue dans un objet (aussi appelé Value Object)
interface Height {
       value(): number
}

class ArticleHeight implements Height {
      private value: number;

      constructor(value: number) {
            if (value < 10) {
                 throw new TooShortLength("Un article doit faire au minium 10 lignes");
            }
            if (value > 100) {
                 throw new TooLongLength("Un article ne peut faire plus de 100 lignes");
            }
            this.value = value;
       }

      value(): number {
            return this.value;
      }
}

class Article {
     private height: Height;

     constructor(height: Height) {
          this.height = height;
     }
}

class AddArticleUsecase {
     execute({ height }) {
          //...
          const article = new Article(new ArticleHeight(height));
          //...
     }
}

Et sur le même modèle, si votre classe expose une méthode publique, c'est qu'elle est imposée par une interface, dans tous les autres cas de figure les méthodes qui ne viennent pas d'interfaces doivent être privées.

Ce serait la 10ème règle que j'ajouterais à l'article.

Les observateurs auront aussi remarqué que j'ai changé les exceptions. Il ne vaut pas confondre nom de l'exception et contexte dans lequel une erreur été levée. D'où l'importance d'un message qui exprime la raison d'une erreur et le nom de l'exception qui exprime le type d'erreur remontée.

Edit : la solution ne marche pas. J'en recherche une autre à la place.

Quelque propose

@Inject
@Nullable
private SomeBean someBean;

Je ne sais pas s'il s'agit des Annotations JetBrains ou de la lib JSR de FindBugs.

Si vous êtes sur Java 8 ou plus (rappel, la dernière version LTS est Java 17, si vous êtes encore sous Java 8 / 11 vous êtes en retard) alors vous pouvez remplacer :

@Autowired(required = false)
private SomeBean someBean;

Par ceci :

@Inject
private Optional<SomeBean> someBean;

Le but étant pour moi de sortir plusieurs projets de Spring, il faut donc y aller par petits bouts, en commençant par remplacer les annotations de Spring.

Exemple d'utilisation des tests paramétrés en TestNG avec les DataProvider :

import static org.assertj.core.Asserstions.assertThat;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

public class ExempleTest {
   private PrimeNumberChecker primeNumberChecker = new PrimeNumberChecker();

   @DataProvider(name = "test1")
   static Object[][] primeNumbers() {
      return new Object[][] {{2, true}, {6, false}, {19, true}, {22, false}, {23, true}};
   }

   // This test will run 5 times since we have 5 parameters defined
   @Test(dataProvider = "test1")
   void testPrimeNumberChecker(Integer inputNumber, Boolean expectedResult) {
      assertThat(primeNumberChecker.validate(inputNumber)).isEqualTo(expectedResult);
   }
}

Merci à @Philou qui associe cette hypothèse tirée de la sociologie à la façon tristement commune de gérer les problèmes dans du code.

Si vous codez dans un langage à destination d'une JRE (Kotlin, Java, Scala, Groovy, etc) vous avez sûrement entendu parler de Spring Boot. Pour ce qui ne le connaissent pas, c'est LE framework qui est parti de rien (à l'origine c'était seulement Spring Framework), puis qui a grossi tout doucement depuis 15 ans et est devenu aujourd'hui un mastodonte aussi gros, lourd, pénible et lent à démarrer que l'ancien JEE (avec des Websphere et Weblogic, etc).

Mais en réalité est-ce que c'est mal ?
Pas vraiment, Spring Boot pousse à produire du code en couche avec des singletons présents partout à chaque couche. Ce n'est pas comme cela que l'on écrit du code concis, découplé, court et maintenable, mais ça a le mérite de s'écrire vite, d'être simple pour des débutants et de fonctionner quand même (en tout cas au début). Après c'est un enfer à tester en terme d'écriture et de temps d'exécution mais bon, qui teste encore son code en 2021 ? #Sadness

Alors quel est mon problème ?
Mon problème c'est que parmi l'ensemble des développements actuels auxquels je contribue chez mes clients, ceux-ci sont couplés totalement à Spring Boot. Vous montez de version, vos développements risquent de péter, vous souhaitez quitter Spring Boot pour autre chose de plus rapide comme Quarkus, pas possible les libs ont été codées pour Spring Boot, d'ailleurs pour les utiliser aucune lib ne pourra se charger si vous n'avez pas Spring Boot car seul Spring Boot doit être en mesure de les instancier. #Folie

Et c'est ça mon problème, Java avait supprimé la problématique de nettoyage de la mémoire, Spring Framework avait supprimé la problématique de création des instances et Spring Boot supprime aujourd'hui la notion d'architecture (ce qui n'a pas du tout le même impact puisque ça touche à la capacité d'innover et de faire différemment), or un code propre qui soit fonctionnel et objet requiert la création et la destruction permanente d'instances immutables à cycle de vie ultra court (une action puis poubelle), ce qui est l'antithèse même des singletons omniprésents, paramétrés par AOP (ndr. Aspect Oriented Programming) et poussés par Spring...

En synthèse :
Pour toutes ces raisons, Spring Boot va à mon sens à contre courant des meilleures pratiques de développement connues et reconnues à cette heure parce qu'il préserve les façons de coder d'il y a plus de 20 ans et venant de langages ni objets ni fonctionnels comme le C, pire encore les "développeurs Spring Boot" sont tellement à fond dans Spring Boot qu'ils n'arrivent même plus à penser leurs libs comme des éléments qui puissent s'utiliser en dehors de Spring Boot et c'est ce qui me fait dire que Spring Boot est un contre-choix et une fausse-bonne idée.