Ces temps-ci, j’ai l’impression de m’être davantage disputé avec des gens qui sont fans d’une stack technique ou d’une architecture donnée et qui parlent comme si c’était la catastrophe si on ne l’adoptait pas, qu’à propos du clean code. Il faut l’appliquer selon le contexte ; j’ai l’impression qu’il n’existe rien de bon à tous les coups.
Les systèmes distribués comme Flink doivent maintenir la HA en conservant 2 à 3 racks, et j’ai l’impression que cela a été garanti en l’intégrant à Kubernetes. Mais au final, il faut aussi réfléchir aux ressources des nœuds workers kube, donc je me demande s’ils ont constitué des nœuds dédiés à Flink uniquement (en cas de forte charge Flink, il semble qu’il puisse y avoir des problèmes de panne des nœuds workers).
Dans cette optique, y a-t-il vraiment un avantage à utiliser Kubernetes ?
De plus, quand on utilise des fonctions de fenêtre dans Flink, les données intermédiaires sont conservées en mémoire pour faire fonctionner les jointures SQL ; du point de vue des compromis, je me demande si Flink est vraiment un bon choix. Le problème énorme qui survient si un SQL + job qui grossit avec le temps finit par tomber...
Moi aussi, dans les cas où une jointure est nécessaire tout en haut de la data source, je me demande comment on pourrait traiter cela au niveau applicatif sans utiliser Flink, en le faisant descendre à l’application.
En y repensant, moi aussi je recommande The Philosophy of Software Design de John aux juniors, mais je n’ai pas particulièrement recommandé Clean Code.
Tout est bien, mais le gros inconvénient, c’est que pour l’acheter depuis la Corée, il faut connaître quelqu’un qui vit à l’étranger...
Apparemment, ils bloquent aussi très strictement les services de réexpédition.
Merci pour cet excellent article. Je souhaite créer en HWP des fichiers générés sur AWS (comme des rapports), mais c’est difficile faute de références suffisantes sur le sujet. Pour le moment, nous utilisons Word. Si vous avez des ressources qui pourraient servir de référence, je vous serais reconnaissant de bien vouloir partager les liens.
L’entraînement de l’IA devrait simplement se concentrer sur les PDF, et pour le hangeul, il vaudrait peut-être mieux faire un bon convertisseur PDF, non ? haha
Comparé à MS Word ou LibreOffice, je trouvais que Hancom Hangeul était bien plus pratique pour créer des documents avec la mise en forme souhaitée. Et pour la diffusion, il suffisait de les exporter en PDF.
Bien sûr, c’est aussi sans doute parce que j’étais plus habitué à Hangeul.
D’après ce que j’avais entendu, le hwpx serait simplement le binaire du hwp réécrit en XML puis empaqueté dans un zip.
Cela dit, au moins, on peut le lire...
Je pense que les livres de développement personnel appliqués au code peuvent convenir aux débutants qui n’ont pas encore de point de vue sur la technique ou les méthodes d’implémentation, mais que leur utilité diminue à mesure que l’expérience s’accumule. Il n’existe pas non plus de vérité absolue valable pour tous les projets et tous les environnements, et il arrive que les généralités ne s’appliquent pas. Comme pour les conseils des livres de développement personnel dans d’autres domaines, il semble préférable de garder une certaine distance, de n’appliquer que les conseils adaptés au contexte et de ne pas les poursuivre aveuglément.
« L'IA ne pourra jamais fonctionner de manière indépendante pour toujours »
Je trouve ce passage marquant.
Ces temps-ci, j’ai l’impression de m’être davantage disputé avec des gens qui sont fans d’une stack technique ou d’une architecture donnée et qui parlent comme si c’était la catastrophe si on ne l’adoptait pas, qu’à propos du clean code. Il faut l’appliquer selon le contexte ; j’ai l’impression qu’il n’existe rien de bon à tous les coups.
Les systèmes distribués comme Flink doivent maintenir la HA en conservant 2 à 3 racks, et j’ai l’impression que cela a été garanti en l’intégrant à Kubernetes. Mais au final, il faut aussi réfléchir aux ressources des nœuds workers kube, donc je me demande s’ils ont constitué des nœuds dédiés à Flink uniquement (en cas de forte charge Flink, il semble qu’il puisse y avoir des problèmes de panne des nœuds workers).
Dans cette optique, y a-t-il vraiment un avantage à utiliser Kubernetes ?
De plus, quand on utilise des fonctions de fenêtre dans Flink, les données intermédiaires sont conservées en mémoire pour faire fonctionner les jointures SQL ; du point de vue des compromis, je me demande si Flink est vraiment un bon choix. Le problème énorme qui survient si un SQL + job qui grossit avec le temps finit par tomber...
Moi aussi, dans les cas où une jointure est nécessaire tout en haut de la data source, je me demande comment on pourrait traiter cela au niveau applicatif sans utiliser Flink, en le faisant descendre à l’application.
Belle discussion.
En y repensant, moi aussi je recommande The Philosophy of Software Design de John aux juniors, mais je n’ai pas particulièrement recommandé Clean Code.
Le billet original a été supprimé. Consultez-le sur la Web Archive
https://web.archive.org/web/20250225151227/…
Waouh, je viens tout juste d’activer l’app GitHub qui fait les revues de PR. Je suis curieux de voir ce que ça donne.
Tout est bien, mais le gros inconvénient, c’est que pour l’acheter depuis la Corée, il faut connaître quelqu’un qui vit à l’étranger...
Apparemment, ils bloquent aussi très strictement les services de réexpédition.
On dit que c’est une reprise quasi à l’identique de docx.
MS avait déjà fait la même chose en passant de doc à docx.
Je pense qu’il est important de ne pas suivre aveuglément n’importe quel titre, mais de bien comprendre le contexte et de l’appliquer.
Hum… je me demande si cela permettra vraiment un développement plus sûr au niveau des types que TS.
2021-02 Présentation du Framework Laptop modulaire
2021-07 Début des livraisons du Framework Laptop et publication des tests
2021-10 Lancement de la marketplace du Framework modulaire
2022-01 Framework, l’ordinateur portable modulaire, publie son firmware en open source
2022-05 Annonce du nouveau Framework Laptop mis à niveau
2022-09 Framework, l’ordinateur portable modulaire, annonce avec Google une édition Chromebook
2024-01 Test du Framework Laptop 16
Hmm, ils ont même réussi à rendre le Chromebook évolutif, mais paradoxalement le desktop, lui, reste assez limité en matière de mise à niveau.
Moi aussi, je pense que c’était un excellent logiciel, au moins jusqu’à la sortie de Hangul 97.
Merci pour cet excellent article. Je souhaite créer en HWP des fichiers générés sur AWS (comme des rapports), mais c’est difficile faute de références suffisantes sur le sujet. Pour le moment, nous utilisons Word. Si vous avez des ressources qui pourraient servir de référence, je vous serais reconnaissant de bien vouloir partager les liens.
L’entraînement de l’IA devrait simplement se concentrer sur les PDF, et pour le hangeul, il vaudrait peut-être mieux faire un bon convertisseur PDF, non ? haha
Comparé à MS Word ou LibreOffice, je trouvais que Hancom Hangeul était bien plus pratique pour créer des documents avec la mise en forme souhaitée. Et pour la diffusion, il suffisait de les exporter en PDF.
Bien sûr, c’est aussi sans doute parce que j’étais plus habitué à Hangeul.
D’après ce que j’avais entendu, le hwpx serait simplement le binaire du hwp réécrit en XML puis empaqueté dans un zip.
Cela dit, au moins, on peut le lire...
Format de fichier de document Han/geul : aperçu de la structure du format HWP
Je pense que les livres de développement personnel appliqués au code peuvent convenir aux débutants qui n’ont pas encore de point de vue sur la technique ou les méthodes d’implémentation, mais que leur utilité diminue à mesure que l’expérience s’accumule. Il n’existe pas non plus de vérité absolue valable pour tous les projets et tous les environnements, et il arrive que les généralités ne s’appliquent pas. Comme pour les conseils des livres de développement personnel dans d’autres domaines, il semble préférable de garder une certaine distance, de n’appliquer que les conseils adaptés au contexte et de ne pas les poursuivre aveuglément.
Il ne faut pas oublier que le clean code n’est pas un objectif, mais un moyen.