Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2728 connectés 

 
 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  48  49  50  51  52  53
Page Suivante
Page Précédente
Bas de page 
Auteur Sujet :

Redface 2 — PHASE 3 @ BETA §

n°2781574
garath_
Posté le 12-04-2026 à 09:55:02  profilanswer
 

Reprise du message précédent :
Ça me fait penser que je vais commencer un nouveau job sur lequel je ne maîtrise pas la stack techno.
Je crois que je vais me prendre un abonnement Claude pro pour la période d'essai  [:transparency]


---------------
HFR Links Preview | HFR Giphy
mood
Publicité
Posté le 12-04-2026 à 09:55:02  profilanswer
 

n°2781575
XaTriX
Posté le 12-04-2026 à 09:55:42  profilanswer
 

En dev android ?


---------------
````````````````````````````````````````````````````````````
n°2781576
garath_
Posté le 12-04-2026 à 09:57:46  profilanswer
 

Non, middleware embarqué :o


---------------
HFR Links Preview | HFR Giphy
n°2781577
XaTriX
Posté le 12-04-2026 à 09:58:39  profilanswer
 

ok pas du tout hs mais tu peux rester :o
 
@ezzz, tu penses quoi du KMP  ? https://kotlinlang.org/multiplatform/

Message cité 1 fois

---------------
````````````````````````````````````````````````````````````
n°2781578
Je@nb
Kindly give dime
Posté le 12-04-2026 à 10:09:26  profilanswer
 

Drapal

n°2781579
Jileo
Posté le 12-04-2026 à 10:15:34  profilanswer
 

Bonjour  [:gaga drapal]

n°2781581
XaTriX
Posté le 12-04-2026 à 10:49:32  profilanswer
 

Le genre de prompt utilisé pour travailler:  

Spoiler :

# Prompt : Revue d'audit architecture + génération de règles LLM
 
## Contexte
 
Tu travailles sur le repo **ForumHFR/redface2** (`/work/xaat/redface2/`), un projet de spécifications pour un client Android HFR (forum.hardware.fr). Le projet est en phase spec — aucun code applicatif, uniquement des docs (Jekyll + GitHub Pages dans `docs/`).
 
Un audit architecture (issue #14) a été réalisé : 26 points identifiés, des propositions détaillées dans un commentaire, puis les corrections appliquées en 3 commits. Tu dois vérifier la qualité de tout ce processus.
 
## Mission
 
### Partie 1 — Vérification de l'audit
 
Compare **systématiquement** ces 3 sources pour chaque point :
 
1. **L'issue #14** : `gh issue view 14 -R ForumHFR/redface2`
2. **Le commentaire de propositions** : `gh api repos/ForumHFR/redface2/issues/14/comments`
3. **Le code actuel** : les fichiers dans `docs/`
 
Pour chaque point (1 à 26), vérifie :
 
- [ ] Le problème identifié dans l'issue est **réel** (pas un faux positif)
- [ ] La proposition dans le commentaire est **cohérente** avec le problème
- [ ] La correction appliquée dans les docs **correspond** à la proposition
- [ ] La correction est **techniquement correcte** (pas d'erreur Kotlin, pas de mermaid cassé, pas d'incohérence avec le reste des docs)
- [ ] La correction **ne casse rien** d'autre dans les specs (effet de bord)
 
Signale :
- Les points où la proposition était bonne mais l'application est incomplète ou divergente
- Les points où la proposition elle-même est discutable (over-engineering, mauvais choix technique, incohérence)
- Les effets de bord non anticipés (un changement dans models.md qui devrait se refléter dans mvi.md mais ne l'est pas, etc.)
- Les incohérences entre fichiers (un champ ajouté dans un fichier mais pas utilisé/référencé dans un autre)
 
### Partie 2 — Évaluation de la démarche
 
Évalue la **qualité du processus** (pas juste le résultat) :
 
1. **L'audit initial** : les 26 points étaient-ils bien priorisés ? Des choses ont-elles été manquées ? Des faux positifs ?
2. **Les propositions** : sont-elles pragmatiques ou over-engineered ? Les alternatives écartées étaient-elles correctement évaluées ?
3. **L'application** : est-ce que le code reflète fidèlement les propositions ? Les commits sont-ils bien découpés et documentés ?
4. **La cohérence globale** : après toutes les modifications, est-ce que l'ensemble des specs forme un tout cohérent, ou y a-t-il des contradictions introduites ?
 
### Partie 3 — Génération de règles LLM
 
À partir de cette expérience (audit → propositions → corrections → review), génère des **règles de travail pour LLM** à inscrire dans le `CLAUDE.md` du repo (ou équivalent). Ces règles doivent couvrir :
 
**Architecture & conception :**
- Comment proposer des changements d'architecture (toujours issue d'abord, jamais en direct)
- Comment évaluer si un changement est over-engineered vs nécessaire
- Quand demander un avis humain vs décider seul
- Comment gérer les dépendances inter-fichiers dans les specs (un changement dans models.md doit être propagé dans mvi.md, architecture.md, etc.)
 
**Qualité du code/specs :**
- Vérifier la cohérence inter-fichiers après chaque modification
- Les exemples de code dans les specs doivent être compilables conceptuellement (types corrects, imports cohérents)
- Les diagrammes mermaid doivent refléter exactement le texte qui les entoure
- Ne jamais utiliser de propriétés/méthodes inexistantes dans les exemples (cf. bug `uri.cat`)
 
**Process d'audit :**
- Comment structurer un audit (sévérité, catégories, format)
- Toujours proposer un fix concret, pas juste signaler le problème
- Toujours vérifier ses propres corrections avant de les pousser (self-review)
- Utiliser un agent reviewer séparé pour la vérification (pas de self-validation)
 
**Attribution & traçabilité :**
- Règles de `Co-Authored-By` avec modèle exact
- Format de commentaire d'issue (qui a demandé, qui a exécuté)
- Commit messages détaillés listant les points d'audit traités
 
**Règles spécifiques au projet :**
- HFR BBCode : `[fixed]` est block-only, jamais inline
- Pas de smileys non vérifiés (`:fleche:`, `:flechd:` n'existent pas)
- Français avec accents dans les docs, anglais dans le code
- `numreponse` est unique par catégorie, pas globalement — la clé est `(cat, numreponse)`
 
Formule ces règles de façon concise, actionnable, et directement intégrable dans un fichier `CLAUDE.md` ou `AGENTS.md`.
 
### Partie 4 — Commentaire de clôture sur l'issue
 
Rédige un commentaire à poster sur l'issue #14 qui :
- Résume ce qui a été fait (3 commits, 26/26 points)
- Liste les fichiers modifiés
- Mentionne les corrections bonus trouvées par la review (Poll, Bookmark, uri.getQueryParameter, :feature:search, etc.)
- Indique les éventuels points restants ou à surveiller
- Pose la question : faut-il fermer l'issue ou la garder ouverte comme référence ?
 
Format : `gh issue comment 14 -R ForumHFR/redface2 --body "..."`
 
Attribution : `> Revue finale par Claude (demandé par @XaaT)`
 
## Contraintes
 
- Lis TOUS les fichiers concernés avant de répondre. Ne devine pas.
- Lis l'issue ET ses commentaires via `gh`.
- Sois critique — le but est de trouver ce qui ne va pas, pas de valider.
- Les règles LLM doivent être testables/vérifiables, pas des platitudes.
- Le commentaire d'issue doit être concis (pas de wall of text).

Message cité 1 fois

---------------
````````````````````````````````````````````````````````````
n°2781583
Tronklou
❤❤ Vrp Bambulab à mi-temps ❤❤
Posté le 12-04-2026 à 10:58:27  profilanswer
 

[:spaydar]


---------------
Victime de girafophobie, mais se soigne.
n°2781584
Dintr-un l​emn
in medio stat virtus
Posté le 12-04-2026 à 11:01:50  profilanswer
 

XaTriX a écrit :

Le genre de prompt utilisé pour travailler:

Spoiler :

# Prompt : Revue d'audit architecture + génération de règles LLM

 

## Contexte

 

Tu travailles sur le repo **ForumHFR/redface2** (`/work/xaat/redface2/`), un projet de spécifications pour un client Android HFR (forum.hardware.fr). Le projet est en phase spec — aucun code applicatif, uniquement des docs (Jekyll + GitHub Pages dans `docs/`).

 

Un audit architecture (issue #14) a été réalisé : 26 points identifiés, des propositions détaillées dans un commentaire, puis les corrections appliquées en 3 commits. Tu dois vérifier la qualité de tout ce processus.

 

## Mission

 

### Partie 1 — Vérification de l'audit

 

Compare **systématiquement** ces 3 sources pour chaque point :

 

1. **L'issue #14** : `gh issue view 14 -R ForumHFR/redface2`
2. **Le commentaire de propositions** : `gh api repos/ForumHFR/redface2/issues/14/comments`
3. **Le code actuel** : les fichiers dans `docs/`

 

Pour chaque point (1 à 26), vérifie :

 

- [ ] Le problème identifié dans l'issue est **réel** (pas un faux positif)
- [ ] La proposition dans le commentaire est **cohérente** avec le problème
- [ ] La correction appliquée dans les docs **correspond** à la proposition
- [ ] La correction est **techniquement correcte** (pas d'erreur Kotlin, pas de mermaid cassé, pas d'incohérence avec le reste des docs)
- [ ] La correction **ne casse rien** d'autre dans les specs (effet de bord)

 

Signale :
- Les points où la proposition était bonne mais l'application est incomplète ou divergente
- Les points où la proposition elle-même est discutable (over-engineering, mauvais choix technique, incohérence)
- Les effets de bord non anticipés (un changement dans models.md qui devrait se refléter dans mvi.md mais ne l'est pas, etc.)
- Les incohérences entre fichiers (un champ ajouté dans un fichier mais pas utilisé/référencé dans un autre)

 

### Partie 2 — Évaluation de la démarche

 

Évalue la **qualité du processus** (pas juste le résultat) :

 

1. **L'audit initial** : les 26 points étaient-ils bien priorisés ? Des choses ont-elles été manquées ? Des faux positifs ?
2. **Les propositions** : sont-elles pragmatiques ou over-engineered ? Les alternatives écartées étaient-elles correctement évaluées ?
3. **L'application** : est-ce que le code reflète fidèlement les propositions ? Les commits sont-ils bien découpés et documentés ?
4. **La cohérence globale** : après toutes les modifications, est-ce que l'ensemble des specs forme un tout cohérent, ou y a-t-il des contradictions introduites ?

 

### Partie 3 — Génération de règles LLM

 

À partir de cette expérience (audit → propositions → corrections → review), génère des **règles de travail pour LLM** à inscrire dans le `CLAUDE.md` du repo (ou équivalent). Ces règles doivent couvrir :

 

**Architecture & conception :**
- Comment proposer des changements d'architecture (toujours issue d'abord, jamais en direct)
- Comment évaluer si un changement est over-engineered vs nécessaire
- Quand demander un avis humain vs décider seul
- Comment gérer les dépendances inter-fichiers dans les specs (un changement dans models.md doit être propagé dans mvi.md, architecture.md, etc.)

 

**Qualité du code/specs :**
- Vérifier la cohérence inter-fichiers après chaque modification
- Les exemples de code dans les specs doivent être compilables conceptuellement (types corrects, imports cohérents)
- Les diagrammes mermaid doivent refléter exactement le texte qui les entoure
- Ne jamais utiliser de propriétés/méthodes inexistantes dans les exemples (cf. bug `uri.cat`)

 

**Process d'audit :**
- Comment structurer un audit (sévérité, catégories, format)
- Toujours proposer un fix concret, pas juste signaler le problème
- Toujours vérifier ses propres corrections avant de les pousser (self-review)
- Utiliser un agent reviewer séparé pour la vérification (pas de self-validation)

 

**Attribution & traçabilité :**
- Règles de `Co-Authored-By` avec modèle exact
- Format de commentaire d'issue (qui a demandé, qui a exécuté)
- Commit messages détaillés listant les points d'audit traités

 

**Règles spécifiques au projet :**
- HFR BBCode : `[fixed]` est block-only, jamais inline
- Pas de smileys non vérifiés (`:fleche:`, `:flechd:` n'existent pas)
- Français avec accents dans les docs, anglais dans le code
- `numreponse` est unique par catégorie, pas globalement — la clé est `(cat, numreponse)`

 

Formule ces règles de façon concise, actionnable, et directement intégrable dans un fichier `CLAUDE.md` ou `AGENTS.md`.

 

### Partie 4 — Commentaire de clôture sur l'issue

 

Rédige un commentaire à poster sur l'issue #14 qui :
- Résume ce qui a été fait (3 commits, 26/26 points)
- Liste les fichiers modifiés
- Mentionne les corrections bonus trouvées par la review (Poll, Bookmark, uri.getQueryParameter, :feature:search, etc.)
- Indique les éventuels points restants ou à surveiller
- Pose la question : faut-il fermer l'issue ou la garder ouverte comme référence ?

 

Format : `gh issue comment 14 -R ForumHFR/redface2 --body "..."`

 

Attribution : `> Revue finale par Claude (demandé par @XaaT)`

 

## Contraintes

 

- Lis TOUS les fichiers concernés avant de répondre. Ne devine pas.
- Lis l'issue ET ses commentaires via `gh`.
- Sois critique — le but est de trouver ce qui ne va pas, pas de valider.
- Les règles LLM doivent être testables/vérifiables, pas des platitudes.
- Le commentaire d'issue doit être concis (pas de wall of text).



Je n'imaginais pas qu'un prompt pouvait être aussi complexe [:wam]

n°2781585
muzah
Bal Musette @ HFR depuis 1997
Posté le 12-04-2026 à 11:06:47  profilanswer
 

Ce sera en licence libre j'espère :O


---------------
un instant monsieur ça-va-chier
mood
Publicité
Posté le 12-04-2026 à 11:06:47  profilanswer
 

n°2781586
muzah
Bal Musette @ HFR depuis 1997
Posté le 12-04-2026 à 11:07:23  profilanswer
 

Ce sera en licence libre j'espère  :O


---------------
un instant monsieur ça-va-chier
n°2781588
XaTriX
Posté le 12-04-2026 à 11:09:52  profilanswer
 

paiement libre mais nécéssaire :o


---------------
````````````````````````````````````````````````````````````
n°2781596
XaTriX
Posté le 12-04-2026 à 11:58:38  profilanswer
 

Specs 0.3.0 sorties : https://forumhfr.github.io/redface2/
Après l'audit #1, son issues, commentaire pour prendre des décisions et les 26 points traités : https://github.com/ForumHFR/redface2/issues/14
 
Maintenant les remarques Corran Horn et on peut avancer sur le choix de la stack !
 


---------------
````````````````````````````````````````````````````````````
n°2781598
XaTriX
Posté le 12-04-2026 à 12:35:52  profilanswer
 

Corran Horn a écrit :


ah oui j'avais pas vu que ça avait été poussé aussi loin la spec :jap:

 

je reste en désaccord pour la DI :o Koin est KMP, peut depuis les dernières versions générer le graphe au compil time et donc plus de crash au runtime.
sinon pour le reste ça a l'air d'être effectivement à l'état de l'art et le schéma d'archi reste assez simple et le MVI qu'il décrit se rapproche techniquement plus de ce que j'appelle un MVVM sur Android mais c'est de la terminologie, tant que l'implem est ok :jap:

 

le truc qui manque, je trouve, c'est vraiment l'approche KMP du projet dans sa globalité. après c'est pas une obligation mais je trouve ça intéressant parce que demain on pourrait faire des applis desktop ou des front webs super facilement par exemple.
un point non abordé également dans la spec c'est la partie TU. imho faut rester sur du JUnit 4, Mockk et Robolectric quand on peut pas mocker nous même les composants android. et faut une couverture de 100% pour les modules "métier" à savoir la partie DB, parsing et les classes de type VM.

 

en tout cas jpense qu'il est sur des bons rails. je sais pas si tu lui as déjà donné à manger le code d'Ayuget mais il y a clairement bcp de choses à reprendre dans la logique de parsing (tous le edge cases de merde, mais jpense ils sont déjà présents dans les TU) et dans la gestion de chargement des pages suivantes/passées (en utilisant un cookie d'un compte anonyme pour pas péter les drapeaux). faudra vraiment que tu challenges l'ia sur cette partie imho

 

Merci pour la review et les retours, c'est exactement pour ça qu'on pousse les specs avant le code :jap:

 

J'ai fait une analyse point par point avec recherches, c'est détaillé dans l'issue #2 : Analyse complète sur GitHub

 

Voici le topo :

 

Koin vs Hilt
T'as raison sur le compile-time safety, le Koin compiler plugin K2 (1.0.0-RC1) règle le problème historique. On garde Hilt pour l'instant (intégration Jetpack native, plus de contributeurs qui connaissent) mais on documente Koin comme alternative viable dans les specs. Si on part KMP un jour, Koin deviendra le choix naturel.

 

KMP
L'idée est bonne mais le bloqueur principal c'est Jsoup : y'a pas d'équivalent KMP mature pour parser du HTML aussi robuste. On a déjà préparé le terrain : le parser et les modèles sont dans des modules purs Kotlin/JVM sans dépendance Android. Le jour où on veut faire du KMP, c'est un refactor de dépendances, pas une réécriture. Mais pour la v1, Android natif.

 

MVI / MVVM
Tu as mis le doigt dessus, c'est de la terminologie. Ce qu'on décrit (StateFlow + sealed interface Intent + Channel Effect) c'est du MVVM + UDF, que certains appellent MVI. Le code est le même. On va clarifier dans les specs pour éviter la confusion.

 

Modules / Clean arch
Now in Android de Google c'est 60+ modules, Pocket Casts c'est 37. Nos 23 sont dans la norme. Mais les 8 modules extension (bookmarks, blacklist, etc.) arrivent en Phase 4, donc en pratique c'est 15 modules pour les Phases 0-3.

 

Tests
100% d'accord, c'était le trou dans les specs. On adopte JUnit 4 + MockK + Robolectric + Turbine (pour les Flow). Couverture 100% sur parser, DB et ViewModels. C'est ajouté dans contributing.md.

 

Code d'Ayuget
Pas encore donné à manger mais c'est prévu. Y'a 10 transformers, 17 fixtures HTML et 13 tests dans Redface v1, c'est une base solide pour les edge cases de parsing HFR. On va reprendre les fixtures comme point de départ pour les tests du parser.

 

Prefetch sans auth
Déjà prévu dans les specs, client OkHttp non authentifié pour le prefetch pour éviter de marquer les drapeaux comme lus :jap:

 

N'hésite pas à commenter directement sur l'issue GitHub si tu veux creuser un point, tout est ouvert.

 

Réponse rédigée par Claude Opus 4.6

Message cité 1 fois
Message édité par XaTriX le 12-04-2026 à 12:37:00

---------------
````````````````````````````````````````````````````````````
n°2781599
antiseptiq​ueIncolore
zzzzzzzzzdjhgdfcjdsc zedufkgkz
Posté le 12-04-2026 à 12:37:01  profilanswer
 

Puisque tu nous demande notre avis et une comparaison avev HFR4droid :o Si le mode compact pouvait être vraiment compact  :o  
En mode non connecté, pas de drapeaux, rien:
https://rehost.diberie.com/Picture/Get/t/505331
https://rehost.diberie.com/Picture/Get/t/505332

Message cité 1 fois
Message édité par antiseptiqueIncolore le 12-04-2026 à 12:38:48

---------------
-------------
n°2781601
XaTriX
Posté le 12-04-2026 à 12:38:00  profilanswer
 

antiseptiqueIncolore a écrit :

Puisque tu nous demande notre avis et une comparaison avev HFR4droid :o Si le mode compact pouvait être vraiment compact  :o  
En mode non connecté, pas de drapeaux, rien:
https://rehost.diberie.com/Picture/Get/t/505331
https://rehost.diberie.com/Picture/Get/t/505332


Faut voir quoi ? :o


---------------
````````````````````````````````````````````````````````````
n°2781604
antiseptiq​ueIncolore
zzzzzzzzzdjhgdfcjdsc zedufkgkz
Posté le 12-04-2026 à 12:38:58  profilanswer
 

Sur HFR4droid, on peut lire beaucoup plus de texte sur chaque ligne


---------------
-------------
n°2781605
XaTriX
Posté le 12-04-2026 à 12:39:24  profilanswer
 

Ok ça peut se faire facilement ça


---------------
````````````````````````````````````````````````````````````
n°2781606
Tronklou
❤❤ Vrp Bambulab à mi-temps ❤❤
Posté le 12-04-2026 à 13:24:50  profilanswer
 

C'est possible d'ajouter des options correspondant a certains scrypt populaires du forum ?
https://forum.hardware.fr/hfr/Discu [...] 6015_1.htm

 

:jap:

Message cité 1 fois

---------------
Victime de girafophobie, mais se soigne.
n°2781607
XaTriX
Posté le 12-04-2026 à 13:26:02  profilanswer
 

Tronklou a écrit :

C'est possible d'ajouter des options correspondant a certains scrypt populaires du forum ?  
https://forum.hardware.fr/hfr/Discu [...] 6015_1.htm
 
 :jap:


https://forumhfr.github.io/redface2/features.html


---------------
````````````````````````````````````````````````````````````
n°2781608
Tronklou
❤❤ Vrp Bambulab à mi-temps ❤❤
Posté le 12-04-2026 à 13:35:33  profilanswer
 

Non mais c'est pour être sûr  :O ( j'ai honte  :sweat:  :fou: )

 

Merci  :jap:


---------------
Victime de girafophobie, mais se soigne.
n°2781609
XaTriX
Posté le 12-04-2026 à 13:36:41  profilanswer
 

:D
On peut discuter de cette liste, si y'a des trucs à rajouter, à virer.. ça reste très préliminaire tout ça


---------------
````````````````````````````````````````````````````````````
n°2781610
Corran Hor​n
lol
Posté le 12-04-2026 à 13:45:18  profilanswer
 

XaTriX a écrit :


 
Merci pour la review et les retours, c'est exactement pour ça qu'on pousse les specs avant le code :jap:
 
J'ai fait une analyse point par point avec recherches, c'est détaillé dans l'issue #2 : Analyse complète sur GitHub
 
Voici le topo :
 
Koin vs Hilt
T'as raison sur le compile-time safety, le Koin compiler plugin K2 (1.0.0-RC1) règle le problème historique. On garde Hilt pour l'instant (intégration Jetpack native, plus de contributeurs qui connaissent) mais on documente Koin comme alternative viable dans les specs. Si on part KMP un jour, Koin deviendra le choix naturel.
 
KMP
L'idée est bonne mais le bloqueur principal c'est Jsoup : y'a pas d'équivalent KMP mature pour parser du HTML aussi robuste. On a déjà préparé le terrain : le parser et les modèles sont dans des modules purs Kotlin/JVM sans dépendance Android. Le jour où on veut faire du KMP, c'est un refactor de dépendances, pas une réécriture. Mais pour la v1, Android natif.
 
MVI / MVVM
Tu as mis le doigt dessus, c'est de la terminologie. Ce qu'on décrit (StateFlow + sealed interface Intent + Channel Effect) c'est du MVVM + UDF, que certains appellent MVI. Le code est le même. On va clarifier dans les specs pour éviter la confusion.
 
Modules / Clean arch
Now in Android de Google c'est 60+ modules, Pocket Casts c'est 37. Nos 23 sont dans la norme. Mais les 8 modules extension (bookmarks, blacklist, etc.) arrivent en Phase 4, donc en pratique c'est 15 modules pour les Phases 0-3.
 
Tests
100% d'accord, c'était le trou dans les specs. On adopte JUnit 4 + MockK + Robolectric + Turbine (pour les Flow). Couverture 100% sur parser, DB et ViewModels. C'est ajouté dans contributing.md.
 
Code d'Ayuget
Pas encore donné à manger mais c'est prévu. Y'a 10 transformers, 17 fixtures HTML et 13 tests dans Redface v1, c'est une base solide pour les edge cases de parsing HFR. On va reprendre les fixtures comme point de départ pour les tests du parser.
 
Prefetch sans auth
Déjà prévu dans les specs, client OkHttp non authentifié pour le prefetch pour éviter de marquer les drapeaux comme lus :jap:
 
N'hésite pas à commenter directement sur l'issue GitHub si tu veux creuser un point, tout est ouvert.
 
Réponse rédigée par Claude Opus 4.6


 
ok je comprends les choix, c'est effectivement assez cohérent. effectivement dommage pour jsoup mais bon on fait une appli pour des nerds de 50 balais, yaura ptet plus besoin de l'appli dans 10ans :o
 
ya juste le nombre de modules où j'ai peur que ce soit ptet over-engineered par rapport à la taille du projet mais rien de franchement problématique, on est plus dans les préférences persos :o
 
je pense que t'as une bonne base de travail, si jamais j'arrive à trouver un peu de temps quand t'auras commencé les premiers modules je pourrais ptet prendre du temps pour faire un peu de revue de code. ça me rappelle un peu le taff pq j'ai aussi fait de la revue chez nous pour un dev back qui s'est mis au KMP full vibe coding :o
tu viens de quelles technos ? pour que j'ai un peu de contexte sur ton bagage
et t'as des tokens par ton taff ou tu paies de ta poche :D ?
 
en tout cas si ya un mcp hfr ça va énormément aider pour les reproductions de bugs et explorations d'edge case. ya aussi un mcp qui marche avec android/adb pour gemini (mais j'imagine qu'il doit exister l'équivalent pour Claude), tu lances un simulateur ou tu branches un device et tu peux lui décrire les bugs à tenter de reproduire.
 
je repense également à un truc, mais ça pourrait être intéressant de mettre en place un système de thème à partir d'un fichier yaml pour que chaque barbu du forum puisse se faire un thème aux petits oignons en passant par les couleurs, les espacements et pourquoi pas des set d'icones. vu que derrière c'est du jetpack compose ça s'intègrera super facilement. perso je m'en fous pour mon usage mais ça pourrait enfin faire migrer les fossiles d'hfr4droid :o

Message cité 2 fois
n°2781613
XaTriX
Posté le 12-04-2026 à 14:34:45  profilanswer
 

Corran Horn a écrit :


 
ok je comprends les choix, c'est effectivement assez cohérent. effectivement dommage pour jsoup mais bon on fait une appli pour des nerds de 50 balais, yaura ptet plus besoin de l'appli dans 10ans :o
 
ya juste le nombre de modules où j'ai peur que ce soit ptet over-engineered par rapport à la taille du projet mais rien de franchement problématique, on est plus dans les préférences persos :o
 
je pense que t'as une bonne base de travail, si jamais j'arrive à trouver un peu de temps quand t'auras commencé les premiers modules je pourrais ptet prendre du temps pour faire un peu de revue de code. ça me rappelle un peu le taff pq j'ai aussi fait de la revue chez nous pour un dev back qui s'est mis au KMP full vibe coding :o
tu viens de quelles technos ? pour que j'ai un peu de contexte sur ton bagage
et t'as des tokens par ton taff ou tu paies de ta poche :D ?
 
en tout cas si ya un mcp hfr ça va énormément aider pour les reproductions de bugs et explorations d'edge case. ya aussi un mcp qui marche avec android/adb pour gemini (mais j'imagine qu'il doit exister l'équivalent pour Claude), tu lances un simulateur ou tu branches un device et tu peux lui décrire les bugs à tenter de reproduire.
 
je repense également à un truc, mais ça pourrait être intéressant de mettre en place un système de thème à partir d'un fichier yaml pour que chaque barbu du forum puisse se faire un thème aux petits oignons en passant par les couleurs, les espacements et pourquoi pas des set d'icones. vu que derrière c'est du jetpack compose ça s'intègrera super facilement. perso je m'en fous pour mon usage mais ça pourrait enfin faire migrer les fossiles d'hfr4droid :o


Pour Jsoup, l'équivalent est Ksoup on dirait, voir la réponse sur l'issue citée. Je sais pas si c'est ultra stable mais c'est noté.
 
Ok pour les modules :o
 
Moi je suis sysadmin/ingé sys/ingé réseau/devops/lead infra, bref j'évolue mais je suis pas un vrai dev. dans ma formation d'ingé j'ai fait de l'algo etc mais pas vraiment de pattern de dev et mon xp sur android est faible mais je maitraise mon claude d'amour [:calimefrog:5]  
 
je paie les abo
 
le mcp hfr est là https://github.com/XaaT/hfr-mcp il avance peinard mais ouais avec un mcp je n sais quoi sui dirige une vm android ou autre, on va pouvoir avoir une boucle de feedback et le laisser faire son taf [:calimefrog:5]  
 
j'sais pas, p'tet pour ton truc de theme yaml, pour partager alors ? parce que sinon des réglages fins pourront faire un truc du genre non ? bref pas fermé de toute façon !
 
j'intègre ta réponse et je le laisse maj les specs avec ce qu'il 'avait déjà prévu avec ton feedback


---------------
````````````````````````````````````````````````````````````
n°2781614
ezzz
23
Posté le 12-04-2026 à 14:41:03  profilanswer
 

XaTriX a écrit :

ok pas du tout hs mais tu peux rester :o
 
@ezzz, tu penses quoi du KMP  ? https://kotlinlang.org/multiplatform/


C’est pas adapté à notre cas je trouve
Si tu pars de 0 avec plein de moyens et que tu veux faire une nouvelle app multiplateforme ok mais perso je suis pas dans ce délire, je suis pas une équipe de 15 devs même avec de l’ia  :o  
Et puis j’ai pas creusé mais je doute que ça soit aussi bien fini qu’une app iOS native avec toutes les spécificités que ça suppose.

Message cité 1 fois

---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk
n°2781615
XaTriX
Posté le 12-04-2026 à 14:43:00  profilanswer
 

https://rehost.diberie.com/Rehost?url=https://forum-images.hardware.fr/icones/message/icon14.gif


---------------
````````````````````````````````````````````````````````````
n°2781618
Corran Hor​n
lol
Posté le 12-04-2026 à 15:05:17  profilanswer
 

ezzz a écrit :


C’est pas adapté à notre cas je trouve
Si tu pars de 0 avec plein de moyens et que tu veux faire une nouvelle app multiplateforme ok mais perso je suis pas dans ce délire, je suis pas une équipe de 15 devs même avec de l’ia  :o
Et puis j’ai pas creusé mais je doute que ça soit aussi bien fini qu’une app iOS native avec toutes les spécificités que ça suppose.


j'avais pas forcément en tête de faire du cross avec iOS. mais si jamais ça t'intéresse, le KMP s'intègre bien dans une codebase iOS quand t'as un module métier (en gros tu t'arrêtes à la couche repository) que t'intègres comme dépendance native dans ton projet. mais t'as tout intérêt à utiliser swift ui et le MVVM iOS derrière pour avoir le meilleur des deux mondes.

 

dans notre cas ça aurait ptet de l'intérêt pour mutualiser la partie query http/parsing, prefs utilisateur et DB mais guère plus.

Message cité 1 fois
Message édité par Corran Horn le 12-04-2026 à 17:00:14
n°2781620
XaTriX
Posté le 12-04-2026 à 15:18:07  profilanswer
 

Maj spec : https://github.com/ForumHFR/redface [...] 03f8132646
 
Bon va falloir faire le tour des fixtures et checker les use cases / edge moisi sur les parser de RF1 et hfr4droid voir l'app ios :o


---------------
````````````````````````````````````````````````````````````
n°2781621
Dintr-un l​emn
in medio stat virtus
Posté le 12-04-2026 à 15:57:47  profilanswer
 

Corran Horn a écrit :

[…] on fait une appli pour des nerds de 50 balais, yaura ptet plus besoin de l'appli dans 10ans :o […]


La violence [:profil horrible:2]

n°2781624
ezzz
23
Posté le 12-04-2026 à 16:53:42  profilanswer
 

surtout que c'est n'imp, y aura des nerds de 60 balais :o


---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk
n°2781625
ezzz
23
Posté le 12-04-2026 à 17:00:22  profilanswer
 

Corran Horn a écrit :


j'avais pas forcément en tête de faire du cross avec iOS mais si jamais le KMP s'intègre bien dans une codebase iOS quand t'as un module métier (en gros tu t'arrêtes à la couche repository) que t'intègres comme dépendance native dans ton projet. mais t'as tout intérêt à utiliser swift ui et le MVVM iOS derrière pour avoir le meilleur des deux mondes.
 
dans notre cas ça aurait ptet de l'intérêt pour mutualiser la partie query http/parsing, prefs utilisateur et DB mais guère plus.


:jap:


---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk
n°2781628
LaRoueEstT​ombee
Hortense ! Pour moi !
Posté le 12-04-2026 à 17:06:23  profilanswer
 
n°2781680
nicko
Posté le 12-04-2026 à 22:13:02  profilanswer
 

Drapal

n°2781683
XaTriX
Posté le 12-04-2026 à 22:22:01  profilanswer
 

Bon bah en cours
 
* développement des skills pour bien dev et s'orga dans le repo
-> plus largement des guidelines pour le dev avec llm
* injection/query-docs à jour prévue avec context7 ou autre, toute la stack est supporté
-> opus 4.6 et codex 5.4 en discutent :o
* 2eme audit des specs/repo
* élargissemetn des fixtures par rapport à rf1 pour couvrir plus large même si on va pas forcémnet utiliser toutes les fonctionnalités, voir dans contributing https://forumhfr.github.io/redface2/contributing
-> j'ai aussi rajouté une vieile doc sur un sdk md.net
* continuer sur les specs "protocole HFR"/données/parsing avant les fonctionnels

Message cité 1 fois

---------------
````````````````````````````````````````````````````````````
n°2781697
kaloskagat​os
Posté le 13-04-2026 à 06:43:48  profilanswer
 

[:kaloskagatos:4]


---------------
« Le hasard, c’est différent de la chance. Parce que la chance, je n'en ai jamais. »
n°2781707
ezzz
23
Posté le 13-04-2026 à 09:16:15  profilanswer
 

Et tu vas faire comment le design UXUI de l’app ?

Message cité 3 fois

---------------
mon flick r - 23 - https://youtu.be/LAr6oAKieHk
n°2781708
bobby8921
Posté le 13-04-2026 à 09:25:29  profilanswer
 

[:maman_de_galles:3]

n°2781710
XaTriX
Posté le 13-04-2026 à 09:49:41  profilanswer
 

ezzz a écrit :

Et tu vas faire comment le design UXUI de l’app ?


Je sais pas trop encore, après n'importe qui peut participer hein :o

 

En discuter avec les LLM déjà, voir des retours de dev Android, regarder les Figma/Stitch et que sais-je, itérer avec les retours HFR, ..
L'UX a déjà commencé avec le back track :o


Message édité par XaTriX le 13-04-2026 à 09:49:57

---------------
````````````````````````````````````````````````````````````
n°2781711
illimp
Posté le 13-04-2026 à 10:00:50  profilanswer
 

[:cerveau drapal]

 

J'y connais rien et ne comprends pas la moitié des mots utilisés sur ce topic ... ça me donne l'impression d'assister à quelque chose d'incroyable :o

Message cité 2 fois
n°2781721
Corran Hor​n
lol
Posté le 13-04-2026 à 11:27:13  profilanswer
 

ezzz a écrit :

Et tu vas faire comment le design UXUI de l’app ?


en suivant les guidelines material 3 je pense qu'on peut s'en sortir même si ça sera pas aux petits oignons

n°2781789
clads92
What is a man ?
Posté le 14-04-2026 à 11:14:51  profilanswer
 

Drap pour la V2 (faut la feature pour choisir la couleur du logo hein red/blue/gold face !)
 
Bon courage pour le projet :

Message cité 2 fois

---------------
NewGame+ ~ Mugen sur Youtube ~ MechDIY (Promo 16%) / Geekbuying
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  48  49  50  51  52  53
Page Suivante
Page Précédente
Haut de page 

Aller à :
Ajouter une réponse
 

Sujets relatifs
Droid2PC : continuité Android vers Mac sans workflow cloud imposéLa "prison" android.....
Passer d’un iPhone 12 à Android : oui mais lequel ?Android va devenir une plateforme fermée au mois de septembre
[Aide] Choix téléphone Android après IOSChoix clavier souris bluetooth pour tablette android
Résolu - Gmail android plus de synchro plus de notificationLinux versus AOSP : android va t-il rester OpenSource éternellement?
Que faire avec un smartphone dont l'OS Android est abandonné ?ANDROID/REDMI/ Xiaomi [RESOLU] Car j'étais résolu
Plus de sujets relatifs à : Redface 2 — PHASE 3 @ BETA §

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.090 secondes

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)