Grâce à cette structure de classification, nous pouvons évaluer quelles stratégies fonctionnent réellement dans notre conception.
Avant de traiter via un wrapper les cas où l’outil « pourrait fournir un ID mais ne le fait pas », il me semble qu’il faut commencer par examiner les 149 cas. Si la réponse contient un ID mais qu’il n’est pas mappé, c’est probablement dû à un problème de convention de nommage des champs (id / _id / resource_id / document_id) ou à une structure imbriquée (result.data.id). Ces 149 cas peuvent être résolus sans modifier l’API, simplement en corrigeant la couche de mapping.
Pour les cas où l’outil « ne peut pas en fournir », l’approche devra sans doute varier selon l’outil.
write_file : avec la combinaison chemin + hash du contenu, on peut détecter si « le même contenu a été écrit deux fois ».
k8s scale : si le nombre cible de replicas est déjà identique à la valeur actuelle, c’est effectivement idempotent — une lecture préalable de l’état permet d’empêcher l’exécution redondante elle-même.
click est différent. Attacher un ID à l’action elle-même n’a pas vraiment de sens ; il semble plus réaliste de comparer des instantanés avant/après pour déterminer si « le changement d’état que ce click cherchait à obtenir s’est déjà produit ».
Ce que nous envisageons en interne, c’est de traiter les outils sous forme de matrice « possibilité de retourner un ID × type de changement d’état » afin de bifurquer vers la stratégie appropriée. Si vous pouvez partager davantage sur les motifs dans lesquels se concentrent ces 149 cas, cela nous aiderait à définir la stratégie de mapping.
Oui ! Le modèle est basé sur la surface standard la plus courante.
En revanche, pour les appartements qui ne disposent pas de cette surface de référence, la prédiction est réalisée à partir de plusieurs surfaces d’échantillon.
J’ai essayé en entrant l’ancien appartement où vivent mes parents...
seul le 33 pyeong s’affiche... pourtant, dans cet immeuble, il y a à la fois des 33 et des 26 pyeong.
Est-ce que seul le 33 pyeong est pris en charge à l’origine ?
Waouh — c’est aussi un service que j’avais envie de créer. Au fait, avec ce genre de crawling, serait-il possible de savoir à combien s’élève à peu près le coût Supabase ?
J’ai oublié de mentionner dans l’article la fonction de partage d’appartements, haha. Je laisse ici, à titre de test, un lien de partage pour Helio City, un grand ensemble très connu.
(Les résultats de prédiction sont à prendre uniquement à titre indicatif ; pour les détails de la modélisation, veuillez consulter le livre blanc !)
Le lien s’ouvre directement sans connexion, donc n’hésitez pas à cliquer pour jeter un œil à l’UI des graphiques. https://app.apt-insights.com/s/apt/9NPumhVmCv
Ah, je venais d’apprendre grâce à cet article qu’il existait peut-être un site coréen de cppreference, et j’étais ravi…
Je vais donc continuer à utiliser le site en anglais comme avant.
Si l’on répartit les 3 197 cas par cause, cela donne ceci.
Aucun champ ID dans la réponse : 2 011 cas (62,9 %)
L’appel a échoué avec une erreur : 1 037 cas (32,4 %)
Un ID est présent dans la réponse, mais notre mapping ne l’a pas capté : 149 cas (4,7 %)
Il y a ici un point que je dois corriger. Vous disiez plus haut que « la plupart des doublons se trouvent dans une zone où le suivi lui-même n’est pas possible », mais 32 % correspondent à des appels qui ont échoué. Comme rien ne s’est produit, il n’y a rien à suivre. Les cas où quelque chose s’est réellement produit mais n’a pas été tracé sont au nombre de 2 011. Cela reste un chiffre important, mais inférieur à 3 197.
Il y avait 24 outils qui ne renvoyaient que succès/échec. Regroupés par type :
Manipulation de navigateur (9) — click, type, navigate, etc. Rien que click représente 719 cas
Système de fichiers (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
Édition de documents (3) — add_paragraph, add_heading, format_text
Cas isolés — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Ces 24 outils se divisent en deux catégories. Je l’ajoute car cela pourrait être utile pour concevoir les specs.
Ceux qui ne peuvent pas fournir d’ID Un clic dans le navigateur ou une modification de fichier ne crée pas, au départ, d’« entité générée ». On ne peut pas vraiment attribuer un ID à un clic. Pour un fichier, le chemin fait office d’identifiant.
Ceux qui pourraient en fournir un, mais ne le font pas github-create_repository en est l’exemple typique. Si un dépôt a été créé, il a évidemment un ID, mais celui-ci n’est pas dans la réponse. emails-send_email a aussi un message ID au niveau SMTP, mais ne le renvoie pas. C’est pareil pour github-fork_repository et excel-write_data_to_excel.
C’est cette seconde catégorie qui peut être corrigée. Si vous ajoutez dans les specs de vos outils internes que « les opérations de création doivent obligatoirement renvoyer l’ID de l’entité », cette distinction pourrait servir de critère pour savoir où l’appliquer.
Les 149 derniers cas relèvent de notre problème de mapping. Ils sont concentrés sur notion database-query (102 cas) et pptx open_presentation (28 cas), deux outils que nous avions volontairement exclus du périmètre, donc ils n’ont pas été détectés. Ce n’est pas un problème de conception d’outil, mais de couverture de notre côté.
Dans la stack que vous exploitez actuellement, les opérations d’écriture se concentrent-elles plutôt dans quelle catégorie ? Ce que nous avons observé vient d’un benchmark, donc la composition des outils doit différer d’un environnement de production réel.
Si l’on peut avancer ne serait-ce que d’un pas par jour, cela suffit.
La production devient plus facile, la validation plus rigoureuse, et nous entrons dans une époque où, au bout du compte, le « choix » devient central. Il est donc d’autant plus important, aujourd’hui, d’avoir le discernement nécessaire pour lire correctement les tendances.
Rien n’égale Ditto Clipboard Manager.
Jeune homme… rendez-moi le prix de mon logement…
J’utilise actuellement l’abonnement mensuel. Comme le coût n’est pas négligeable, je me demande si ce sera viable sur la durée.
Grâce à cette structure de classification, nous pouvons évaluer quelles stratégies fonctionnent réellement dans notre conception.
Avant de traiter via un wrapper les cas où l’outil « pourrait fournir un ID mais ne le fait pas », il me semble qu’il faut commencer par examiner les 149 cas. Si la réponse contient un ID mais qu’il n’est pas mappé, c’est probablement dû à un problème de convention de nommage des champs (
id/_id/resource_id/document_id) ou à une structure imbriquée (result.data.id). Ces 149 cas peuvent être résolus sans modifier l’API, simplement en corrigeant la couche de mapping.Pour les cas où l’outil « ne peut pas en fournir », l’approche devra sans doute varier selon l’outil.
write_file: avec la combinaison chemin + hash du contenu, on peut détecter si « le même contenu a été écrit deux fois ».k8s scale: si le nombre cible de replicas est déjà identique à la valeur actuelle, c’est effectivement idempotent — une lecture préalable de l’état permet d’empêcher l’exécution redondante elle-même.clickest différent. Attacher un ID à l’action elle-même n’a pas vraiment de sens ; il semble plus réaliste de comparer des instantanés avant/après pour déterminer si « le changement d’état que ce click cherchait à obtenir s’est déjà produit ».Ce que nous envisageons en interne, c’est de traiter les outils sous forme de matrice « possibilité de retourner un ID × type de changement d’état » afin de bifurquer vers la stratégie appropriée. Si vous pouvez partager davantage sur les motifs dans lesquels se concentrent ces 149 cas, cela nous aiderait à définir la stratégie de mapping.
Oui ! Le modèle est basé sur la surface standard la plus courante.
En revanche, pour les appartements qui ne disposent pas de cette surface de référence, la prédiction est réalisée à partir de plusieurs surfaces d’échantillon.
J’ai essayé en entrant l’ancien appartement où vivent mes parents...
seul le 33 pyeong s’affiche... pourtant, dans cet immeuble, il y a à la fois des 33 et des 26 pyeong.
Est-ce que seul le 33 pyeong est pris en charge à l’origine ?
Waouh — c’est aussi un service que j’avais envie de créer. Au fait, avec ce genre de crawling, serait-il possible de savoir à combien s’élève à peu près le coût Supabase ?
Les vidéos et les enregistrements sont-ils tous envoyés au serveur ?
J’ai oublié de mentionner dans l’article la fonction de partage d’appartements, haha. Je laisse ici, à titre de test, un lien de partage pour Helio City, un grand ensemble très connu.
(Les résultats de prédiction sont à prendre uniquement à titre indicatif ; pour les détails de la modélisation, veuillez consulter le livre blanc !)
Le lien s’ouvre directement sans connexion, donc n’hésitez pas à cliquer pour jeter un œil à l’UI des graphiques.
https://app.apt-insights.com/s/apt/9NPumhVmCv
Il y a déjà beaucoup d’apps gratuites et c’est facile à faire, donc si c’est une app payante, bof...
Merci pour le signalement. C’est corrigé !!
Le lien vers le livre blanc technique renvoie une erreur 404 !
https://edge.apt-insights.com/v1/public/whitepaper
Ah, je venais d’apprendre grâce à cet article qu’il existait peut-être un site coréen de cppreference, et j’étais ravi…
Je vais donc continuer à utiliser le site en anglais comme avant.
Ah, cela fait longtemps que je n’utilise plus Windows, donc je ne connaissais pas bien. Après vérification, ça a l’air similaire.
Si l’on répartit les 3 197 cas par cause, cela donne ceci.
Aucun champ ID dans la réponse : 2 011 cas (62,9 %)
L’appel a échoué avec une erreur : 1 037 cas (32,4 %)
Un ID est présent dans la réponse, mais notre mapping ne l’a pas capté : 149 cas (4,7 %)
Il y a ici un point que je dois corriger. Vous disiez plus haut que « la plupart des doublons se trouvent dans une zone où le suivi lui-même n’est pas possible », mais 32 % correspondent à des appels qui ont échoué. Comme rien ne s’est produit, il n’y a rien à suivre. Les cas où quelque chose s’est réellement produit mais n’a pas été tracé sont au nombre de 2 011. Cela reste un chiffre important, mais inférieur à 3 197.
Il y avait 24 outils qui ne renvoyaient que succès/échec. Regroupés par type :
Manipulation de navigateur (9) — click, type, navigate, etc. Rien que click représente 719 cas
Système de fichiers (3) — write_file, edit_file, move_file
Kubernetes (4) — scale, create, apply, delete
Édition de documents (3) — add_paragraph, add_heading, format_text
Cas isolés — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Ces 24 outils se divisent en deux catégories. Je l’ajoute car cela pourrait être utile pour concevoir les specs.
Ceux qui ne peuvent pas fournir d’ID Un clic dans le navigateur ou une modification de fichier ne crée pas, au départ, d’« entité générée ». On ne peut pas vraiment attribuer un ID à un clic. Pour un fichier, le chemin fait office d’identifiant.
Ceux qui pourraient en fournir un, mais ne le font pas github-create_repository en est l’exemple typique. Si un dépôt a été créé, il a évidemment un ID, mais celui-ci n’est pas dans la réponse. emails-send_email a aussi un message ID au niveau SMTP, mais ne le renvoie pas. C’est pareil pour github-fork_repository et excel-write_data_to_excel.
C’est cette seconde catégorie qui peut être corrigée. Si vous ajoutez dans les specs de vos outils internes que « les opérations de création doivent obligatoirement renvoyer l’ID de l’entité », cette distinction pourrait servir de critère pour savoir où l’appliquer.
Les 149 derniers cas relèvent de notre problème de mapping. Ils sont concentrés sur notion database-query (102 cas) et pptx open_presentation (28 cas), deux outils que nous avions volontairement exclus du périmètre, donc ils n’ont pas été détectés. Ce n’est pas un problème de conception d’outil, mais de couverture de notre côté.
Dans la stack que vous exploitez actuellement, les opérations d’écriture se concentrent-elles plutôt dans quelle catégorie ? Ce que nous avons observé vient d’un benchmark, donc la composition des outils doit différer d’un environnement de production réel.
La version coréenne ayant été mise à jour pour la dernière fois en 2016, il vaut sans doute mieux consulter l’original
Si l’on peut avancer ne serait-ce que d’un pas par jour, cela suffit.
La production devient plus facile, la validation plus rigoureuse, et nous entrons dans une époque où, au bout du compte, le « choix » devient central. Il est donc d’autant plus important, aujourd’hui, d’avoir le discernement nécessaire pour lire correctement les tendances.
Est-ce similaire à la fonctionnalité native de Windows ? Windows + V
Waouh, avec ça, on n'aura plus à se soucier des trucs du genre jeu de rôle.
Oups, je l’ai corrigé.