C’est ce que vous aviez dit, mais avec la sortie aujourd’hui de la nouvelle app Codex, la génération d’images est aussi possible ? Dans ce cas, est-ce que c’est également autorisé sur les clients authentifiés via OAuth ?
Une fois le tunnel cf configuré, les logs fail2ban qui s’accumulaient sur les ports 80 et 443 ont complètement disparu, donc je les ai carrément retirés et je n’y ai plus repensé depuis.
J’ai aussi acheté le domaine directement chez Cloudflare et configuré le SSO chez Cloudflare ; si on ne passe pas le SSO, impossible d’utiliser les services, ce qui fait que Cloudflare encaisse toutes les attaques à ma place.
Comme il n’y a que des services que j’utilise seul derrière, cette configuration est largement suffisante à l’usage.
Et si Cloudflare tombe en panne, j’ai décidé d’accepter ce compromis.
Je ressentais une baisse de performances d’Opus 4.6, c’était peut-être parce qu’ils se préparaient à lancer le nouveau modèle.
La magie qui consiste à provoquer une sensation de régression pour augmenter ensuite le niveau de satisfaction...
Les points 3 et 4. Écrire des specs en détail a une profondeur infinie. Ce que je veux dire, c’est qu’il existe un niveau adapté à chaque organisation. Quand on regarde l’histoire de la manière dont les services à succès ont été développés, je crois savoir que dans 99 % des cas, l’essentiel est justement de ne pas mettre trop d’énergie à rédiger des specs de façon parfaitement précise. Il ne faut pas s’y enfermer. Il suffit de voir comment ont été créés Summoners War, Dungeon & Fighter, Zigbang ou Lineage.
À voir, il semble que M. Kim Ho-dong ait déjà subi énormément de stress en 2019. En lisant le texte, on voit qu’il y avait vraiment trop de personnes pénibles et de voyous. (Il y en a probablement encore aujourd’hui ?) https://hamonikr.org/Free_Board/63139
Je suis d’accord aussi. Dans les services, on accorde parfois à la DB une importance plus grande que nécessaire, et il arrive même qu’on investisse excessivement dans la conception, comme si casser la normalisation allait forcément être catastrophique.
Il ne s’agit pas de dire qu’il ne faut pas utiliser de DB, mais plutôt de rafraîchir sa réflexion sur la raison pour laquelle on l’utilise et sur ce qui constitue vraiment le fondement du service.
Au final, l’équilibre reste toujours essentiel.
Oui, en effet. Au début d’une activité, quand il n’y a pas encore beaucoup d’utilisateurs, on peut voir cela comme une simple proposition : ne pas acheter de base de données ni trop compliquer les choses, et aller jusqu’à la stabilisation du service avec de simples E/S de fichiers.
Je pense que c’est un très bon article. En particulier, ce genre de contenu avec des « chiffres » est précieux. À une époque où il est difficile de trouver des développeurs qui ont ne serait-ce qu’une intuition approximative des surcoûts du code que nous écrivons et de la stack technique que nous utilisons, je l’ai lu avec plaisir.
La métaphore me semble pertinente. Mon projet aussi est en pratique constitué uniquement de deux éléments : l’intention de la personne et le snapshot.
Au final, je pensais justement que la voie à suivre pour mon projet consistait à déterminer comment calculer l’intention humaine (par ex. les frappes au clavier, les clics de souris) et comment lui donner un sens.
Le concept est séduisant, mais d’expérience, ce genre de tentatives idéales a rarement été vraiment couronné de succès...
Pour l’instant, j’ai l’impression que Feedly reste le choix le plus sûr, avec en plus de bonnes fonctionnalités d’IA.
Existe-t-il des cas où
sqlitepeut se corrompre ? Je suis curieux. En dehors des déplacements ou suppressions de fichiers anormaux, bien sûr.C’est ce que vous aviez dit, mais avec la sortie aujourd’hui de la nouvelle app Codex, la génération d’images est aussi possible ? Dans ce cas, est-ce que c’est également autorisé sur les clients authentifiés via OAuth ?
On dirait que ce commentaire montre bien l’étroitesse de vue de certains développeurs coréens et le niveau de GeekNews.
Une fois le tunnel cf configuré, les logs fail2ban qui s’accumulaient sur les ports 80 et 443 ont complètement disparu, donc je les ai carrément retirés et je n’y ai plus repensé depuis.
J’ai aussi acheté le domaine directement chez Cloudflare et configuré le SSO chez Cloudflare ; si on ne passe pas le SSO, impossible d’utiliser les services, ce qui fait que Cloudflare encaisse toutes les attaques à ma place.
Comme il n’y a que des services que j’utilise seul derrière, cette configuration est largement suffisante à l’usage.
Et si Cloudflare tombe en panne, j’ai décidé d’accepter ce compromis.
Je ressentais une baisse de performances d’Opus 4.6, c’était peut-être parce qu’ils se préparaient à lancer le nouveau modèle.
La magie qui consiste à provoquer une sensation de régression pour augmenter ensuite le niveau de satisfaction...
Les points 3 et 4. Écrire des specs en détail a une profondeur infinie. Ce que je veux dire, c’est qu’il existe un niveau adapté à chaque organisation. Quand on regarde l’histoire de la manière dont les services à succès ont été développés, je crois savoir que dans 99 % des cas, l’essentiel est justement de ne pas mettre trop d’énergie à rédiger des specs de façon parfaitement précise. Il ne faut pas s’y enfermer. Il suffit de voir comment ont été créés Summoners War, Dungeon & Fighter, Zigbang ou Lineage.
Je suis d’accord. L’agile reste toujours pertinente. On dirait des propos tenus dans le vide par des gens qui n’ont jamais travaillé sur le terrain.
Si SQLite se corrompt, il n’y a plus de solution...
À voir, il semble que M. Kim Ho-dong ait déjà subi énormément de stress en 2019. En lisant le texte, on voit qu’il y avait vraiment trop de personnes pénibles et de voyous. (Il y en a probablement encore aujourd’hui ?)
https://hamonikr.org/Free_Board/63139
Je suis d’accord aussi. Dans les services, on accorde parfois à la DB une importance plus grande que nécessaire, et il arrive même qu’on investisse excessivement dans la conception, comme si casser la normalisation allait forcément être catastrophique.
Il ne s’agit pas de dire qu’il ne faut pas utiliser de DB, mais plutôt de rafraîchir sa réflexion sur la raison pour laquelle on l’utilise et sur ce qui constitue vraiment le fondement du service.
Au final, l’équilibre reste toujours essentiel.
En Corée, l’agile ne sert ni plus ni moins qu’à mettre la pression sur les délais des développeurs.
Oh… c’est sympa. Comme ça n’existait pas jusqu’à présent, je l’utilisais uniquement en version raccourci que j’avais créée moi-même.
Oui, en effet. Au début d’une activité, quand il n’y a pas encore beaucoup d’utilisateurs, on peut voir cela comme une simple proposition : ne pas acheter de base de données ni trop compliquer les choses, et aller jusqu’à la stabilisation du service avec de simples E/S de fichiers.
Les pépites dans les réponses sont en prime.
Je pense que c’est un très bon article. En particulier, ce genre de contenu avec des « chiffres » est précieux. À une époque où il est difficile de trouver des développeurs qui ont ne serait-ce qu’une intuition approximative des surcoûts du code que nous écrivons et de la stack technique que nous utilisons, je l’ai lu avec plaisir.
La métaphore me semble pertinente. Mon projet aussi est en pratique constitué uniquement de deux éléments : l’intention de la personne et le snapshot.
Au final, je pensais justement que la voie à suivre pour mon projet consistait à déterminer comment calculer l’intention humaine (par ex. les frappes au clavier, les clics de souris) et comment lui donner un sens.
J’allais venir écrire un post en voyant la sortie, mais vous l’aviez déjà rédigé.
Je suis curieux de voir quelles seront ses performances.
Le code existant est toujours là, il est donc possible de vérifier directement de quelle implémentation il s’agit.
https://gitlab.com/sebuls/libhwp
Le concept est séduisant, mais d’expérience, ce genre de tentatives idéales a rarement été vraiment couronné de succès...
Pour l’instant, j’ai l’impression que Feedly reste le choix le plus sûr, avec en plus de bonnes fonctionnalités d’IA.
rip