Reprise du message précédent :
Si, mais je sonde ici voir si ya mieux ou plus basique.

Ca me parait hyper lourd quand je vois les examples. pour une simple route, tu te retrouves avec 200 lignes de commentaires.

C'est l'avantage d'utiliser un langage avec plus que trois types, le compilateur peut dériver la documentation automatiquement.

Il n'y a vraiment vraiment aucun rapport entre les deux.

La "doc" générée uniquement sur base des types c'est vraiment pas d'une grande utilité, même dans un langage qui se repose fortement dessus (genre haskell) voir les types d'une fonction ça va pas toujours te dire grand chose dessus. C'est utile, mais pas suffisant.

Le problème du JS c'est surtout qu'historiquement c'est la merde à parser ou pour associer de la doc à des symboles (parce que pre ES6 les modules sont complètement ad-hoc, et tu peux facilement faire des trucs vraiment bizarre, donc les trucs genre visibilité c'est touchy).

Par opposition à ton hypothèse, le Python a des mécanismes de documentation standard qui sont super bien supportés.

Si ta le courage de l'écrire toi-même la doc : https://slatedocs.github.io/slate/
 
Pas autogénéré mais c'est propre

Vu que y'a 0 doc pourquoi pas.

Là je cherche un truc rapide que pour les mecs qui gèrent le front puissent voir certain params sans check le code si jamais je mets pas tout dans insomnia.

Et oui effectivement, le type on s'en branle. J'utilise Typescript et TypeORM donc y'a moyen de faire un truc automatique pour ça si je voulais.
Je veux surtout montrer les params d'une route ou le body à envoyer. Sans devoir check le code à chaque fois.

Js-Doc et Swagger font le taff, mais comme déjà dit, je voulais juste savoir si y'avait moins verbeux ou plus simple.

https://blogs.lexpress.fr/le-boulot [...] -medecins/

 
hugo + markdown avec un theme de doc ?

Pas suffisant... 90% du contenu de ma doc OpenAPI est dérivée directement à partir des types de mes endpoints.
C'est même dans le nom de la bibliothèque que j'utilise.
https://tapir.softwaremill.com/en/latest/
 

Quand tu documentes tes routes et modèles, in fine tu définis bien les types des entrées et sorties, non?

Un talk tout-à-fait passionnant: https://www.youtube.com/watch?v=pL3Yzjk5R4M
 
Malgré les apparences, c'est une conf de dev.

 
Merci

Toutes les “docs” montées comme ça que j’ai pu voir n’en sont que nominalement, produites par des gens qui n’ont aucune envie de documenter quoi que ce soit.

Et bizarrement la lib en question est très très loin de s’arrêter à du listage de types.

Non. La définition des types c’est un élément du sous ensemble de la documentation qu’est la référence. Utile, mais pas toujours nécessaire, et surtout rarement suffisant.

Un .h, c'est pas de la doc.

Avis n°6 du Conseil scientifique COVID-19 (daté du 20 avril, publié le 25), page 16 :

Source : https://solidarites-sante.gouv.fr/I [...] l_2020.pdf
 

 
Ce gouvernement est en roue libre

C'est dommage qu'après la conf de presse de Trump, pleins de scientifiques aient posté des messages pour dire aux gens de ne surtout pas s'injecter des produits nettoyant sous la peau comme proposé par leur cher président. Ca aurait dégagé les plus cons de la planète, de la bonne veille sélection naturelle en somme. A ce niveau là, on pourrait presque les mettre dans les Darwin Awards
Et pourquoi Trump ne teste pas sur lui ses supers idées ?

Ok, je vois, pas de chance T'as déjà utilisé ce famuleux produit de MS qu'est EPM ? C'est MS Project en version client/serveur avec du Sharepoint. A installer, c'est une horreur car c'est un empilement de produits (mssql serveur, project, sharepoint + tout un d'autres trucs) mais il faut bien respecter l'ordre d'install de chaque composant et de version, sinon, ça marche pas (non, y'a pas un setup et c'est bon). Ca fini par tomber en marche, tu sais pas comment t'as fait. Donc, tu pries pour que ça plante pas. Mais, fatalement, au bout de quelques jours, y'a une synchro de planning qui bloque. Faut supprimer tout le projet sur le serveur pour permettre l'upload du planning de la version côté client. Donc, tu perds l'historique. Jamais vu une merde pareil !
 
Moi, pour mon suivi d'équipe (tâches, imputations/congés/formations, suivi financier par bons de commande, suivi de projets à jalons, croisement livrables attendus/livrables livrés par projet...), j'utilise mon outil Astres (cf ma signature). Je me code ensuite, en fonction du client, le TdB qui se génère automatiquement (du CSV pour injection dans Excel pour les graphiques et tableaux mais ça peut être du pdf dans certains cas). Quand je vois avec quoi bossent les autres Chefs de projet (Excel et la bite et le couteau), j'en pleure pour eux à voir tout le temps qu'ils peuvent perdre!
 
Bon courage à toi.

+1 avec Masklin : ce qui est cool avec une API c'est d'avoir un bon "getting started", une description des flows classiques (des bons exemples) genre cookbook ou FAQ, et sur les méthodes, les limitations / trucs a savoir pour bien utiliser. Bien sûr, les méthodes avec les types sont importantes, mais si t'as que ça ta doc est nulle.
Et surtout, et ça dépend pas de la doc mais du code de l'API elle même, un truc clair et intuitif. A ce propos la plupart des API publiques Google sont vraiment pas fantastiques de ce point de vue (cf l'API drive par example). Par contre le testeur d'API est super pratique.

Quelle surprise. MS Project est une énorme bouse que Microsoft avait rachetée à ses débuts à un autre éditeur. Le problème, c'est qu'il a été conçu pour gérer un seul projet et un seul fichier à la fois, et Microsoft n'a jamais vraiment fait ce qu'il faut pour sortir de ce schéma. MS Projet a évolué à coup de verrues, au lieux d'être revu de fond en comble. Résultat, quand ils ont essayé de passer à du multi projets, ça a été le début d'un grand n'importe quoi. C'est le seul logiciel toutes catégories confondues avec lequel j'ai perdu des travaux entiers de façon irrécupérable. Pour cela, il a fallu que je crée des sous-projets. Dans ce cas-la, tu as un projet master qui regroupe tous les sous-projets. Pour je ne sais plus quelle raison, si je me souviens bien il vaut mieux éviter d'éditer les sous-projets directement, mais seulement à travers le projet master. Ils se retrouvent dans le même dossier, qui de mémoire semble être hard-linké avec des chemins absolus dans le projet master (le tout enregistré dans un fichier binaire, bien sûr). Résultat, si tu déplaces l'un des fichiers de sous projets ailleurs et que tu enregistres le projet master, et bien tu flingues tout.
Tu ne peux pas non plus travailler à plusieurs sur les sous-dossiers sinon ça flingue tout aussi. Du coup j'ai appris à garder toutes les versions intermédiaires avec ce logiciel.  
Microsoft a fini par faire un backend basé sur SQL Server, mais je vois que c'est tout autant la merde. Je crois que la seule solution, c'est une refonte complète du produit.

Je te confirme que sur EPM, quand tu voulais faire un planning regroupant plusieurs projets, il fallait aussi faire un projet master avec toutes le contraintes que tu as évoquées. Le manque de stabilité de ce produit était juste hallucinante ! Et je parle même pas du système de droits d'accès des users, groupes... Si t'étais pas ultra rigoureux et que tu ne t'en tenais pas à mettre les droits que sur les groupes, ben pour savoir qui accédait à quoi en lecture ou écriture, c'était pas la peine    
Au bout de 2-3 ans, on a fini par abandonner EPM. Du reste, il me semble que MS a abandonné cet outil. On va pas le regretter

Ils l'on quand même fait évoluer pendant une bonne douzaine d'années sans jamais résoudre les problèmes de fond. Et bien sûr nulle part la doc ne les mentionnait, parce que Microsoft savait que c'était des bugs jamais résolus.

Déjà, trouver EPM sur le site de MS, c'était pas facile. On peut pas dire qu'ils le mettaient en avant
Pour gérer du multi-projets correctement, y'a quoi au final ?

 
C'est assez marrant il ne parle pas des échecs
- Les U2 abattus
- Le F117 abattu par un couple radar/missile vieux de 30 ans

 

 
Ça me parait un peu gros pour juste quelques pages de docs mais c’est une solution.

Avec le theme qui va bien ça doit se résumer à :

Après ça te genere le site static, t'as qu'a le copier et le mettre où tu veux

Pas testé Docsy (https://www.docsy.dev/docs/) mais ça ressemble à un clone open source d'un outil interne de chez nous qui est très bien pour la doc), https://themes.gohugo.io/dot-hugo-documentation-theme/ semble pas mal aussi.

Je viens de voir un thème spécial documentation d'API : https://themes.gohugo.io/docuapi/ .

il y a des habitués de three.js ici ?

J'ai envie de faire une visionneuse carto adaptée à nos besoin, pour pouvoir par la suite ajouter des particules ou des effets d'éclairage, mais j'ai du mal à comprendre comment je dois gérer mes tuiles en fonction du niveau de zoom.

Je crois que je suis obligé de tuiler , la résolution complète de l'image est de l'ordre de 5k pixels par 5k

Si je comprends bien , je vais bouffer de la mémoire dès que je ferai un chargement de texture, donc je ne dois charger en mémoire que les tuiles visibles, et virer les autres.

Le niveau de zoom va être géré par l'altitude de la camera, et je vais donc devoir définir des "seul" à partir des dequels je masque (ou supprime et decharge de la mémoire ?) les tuiles des niveaux qui ne m'intéressent pas et je charge celles du niveau qui va bien.
En cas de déplacement, c'est plus simple , il suffira de virer les tuiles hors de l'écran et d'ajouter celles qui sont dévenues visibles.

Est ce que j'ai bien compris ?
Est ce qu'il y a des solutions existantes, ou à défaut des mots clé à chercher ?

Je crois qu’il y a un exemple avec une planète où la caméra zoome de l’espace jusqu’au sol.

1M de cas  (Soit le tiers des cas au niveau mondial) dans 2 jours, faut commencer à trouver des moyens alternatifs.

Tu pourrais pas customiser Leaflet plutôt ?

J'ai bossé 90h cette semaine ôO

Tout ça est orthogonal à la documentation des endpoints.
On parlait de générer de la doc Swagger / OpenAPI, dans mon cas c'est fait automatiquement à part pour les champs "description", et "example" (et même ça, en poussant un peu le truc tu peux générer automatiquement des exemples de payload qui sont réalistes, mais c'est souvent plus parlant de créer des vrais exemples).

Les limitations sont aussi documentées par les types des erreurs qu'on retourne.

Une trentaine d'endpoints c'est pas si énorme selon les utilisateurs, peut-être que Kenshineuh a besoin d'expliquer les workflows, mais si pour l'instant il partage un workspace Insomnia, peut-être pas.

Ok, je vais regarder ça, merci

Difficile de greffer des particules des effets de lumière ou des modèles 3d par dessus

Comme je suis en réécriture complète j'essaye de voir s'il y a des opportunités technos a saisir

Nous on utilisait une spec Swagger et un frontend avec https://redocly.github.io/redoc/
Sachant que le frontend du coup c'est un fichier HTML de quelques lignes à faire, le reste est géré par Redoc.

 
Ralentir l'épidémie en supprimant les hôtes du virus ?  

Bonne question. Je n'en sais rien.

WHAT  ?

 
J'ai fais ça pendant 1 mois et demi. La délivrance une fois fini.

Et environ 70h la semaine dernière

Non seulement dans des périodes comme ça je fais des journées de taré (cette semaine j'ai fais grossomodo ~8h minuit tous les jours, sur 6 jours) , mais le pire c'est que même en allant me coucher le soir je ne trouve pas le sommeil...

C'est exactement ça. J'ai terminé hier soir (bon il me reste la doc à faire mais c'est moins urgent) et ça fait tout drôle... J'ai le contrecoup aujourd'hui...

 
Je vais check ça, merci.

 
Bonne nuit, à mercredi alors

 
merci Much, c'est un super talk!!!!
 
j'aime beaucoup les examples sur les compromis faits. Mon plus gros problème quand je devais dealer avec des products owner c'était l'absence de compromis (pixel perfect design et autres merdes)

yo
 
Question du jour : vous avez un produit écrit en Node.js (ou n'importe quel interpréteur), et vous supportez la version minimum de node qui est la version X
Si demain vous dites "on supportera plus X, on va supporter X+1 à la place", pour vous c'est un breaking change (et donc sortie d'une version majeure) ou pas ?
 
(le consensus chez nous penche plutôt vers "oui" parce que ça suppose de faire des installs sur des machines de prod par ex. mais on peut arguer que mettre à jour l'interpréteur fait partie des maintenances normales ne serait-ce que d'un point de vue sécurité...)

oui, si c'est un changement de version majeure de node
non, si c'est un changement de version mineur de note