- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Abonnement payant Replit d'un an
J'ai souscrit un abonnement jusqu'au 1er décembre grâce aux soldes du Black Friday, car je devais essayer un outil de programmation IA.
J'ai choisi ceci parce que je n'ai pas d'ordinateur performant,
- exécution et vérification des résultats dans un navigateur sans avoir besoin d'installer de compilateur ou d'interpréteur localement
- Apprenez la programmation sans vous soucier de la configuration de l'environnement.
- Projet de codage collaboratif. (Je peux partager un lien pour faire du pair programming ensemble) - N'hésitez pas à me contacter si besoin.
- Prototypage et test rapides du code.
- Enseigner le codage aux étudiants de manière interactive.
- Hébergement d'applications Web légères ou d'API.
Je devrais également faire une vidéo à ce sujet. https://replit.com/
Regardons le monde. (Diversité des actualités)
Économie
2024-11-29 (Ven) Morning Routine (Hankyung) : Baisse des taux d'intérêt en Corée de 3,25% à 3,0% / Augmentation des inégalités de revenus, baisse de la consommation / Exosquelette (robot portable) / ETF thématiques à 20% de progression (selon les étrangers)
>> En fin de compte, si les étrangers n'achètent pas, le cours de l'action n'augmentera pas.
Informatique
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 habitudes à adopter pour devenir un bon développeur
>> C'est exactement ce que j'ai ressenti en créant et en maintenant la plateforme de télématique/cluster, mais je n'ai pas pu mettre cela en pratique. Il ne faut pas avoir peur du changement, et en procédant par étapes comme ici, cela devrait être possible.
1. Maintenez vos commits aussi petits que possible, au point de vous demander : « Est-ce que ça suffit ? »
On ne sait jamais quand on aura besoin de revenir sur une modification spécifique. Savoir exactement où se trouve un bug survenu il y a 6 jours et pouvoir revenir à ce commit spécifique sans conflit de fusion complexe procure une grande tranquillité d'esprit. Mon critère est simple : un code qui compile peut être commité.
2. Mettez en pratique le dicton de Kent Beck : « Pour effectuer la modification souhaitée, commencez par simplifier la modification (attention : cela peut être difficile), puis effectuez la modification simplifiée.»
"Pour effectuer la modification souhaitée, commencez par simplifier la modification (attention : cela peut être difficile), puis effectuez la modification simplifiée."
Faites en sorte que plus de la moitié de vos commits soient des refactorisations. Une refactorisation continue consiste à trouver et à appliquer des améliorations réalisables en moins de 10 minutes. Grâce à ces petites améliorations, vous pourrez résoudre les grandes demandes ultérieures par de simples modifications. Les refactorisations à grande échelle doivent être évitées.
3. Tout code est une dette.
Le code non déployé est la dette des dettes. Il faut vérifier si le code fonctionne correctement et s'il ne casse pas d'autres fonctionnalités au minimum. Les tests donnent confiance et le déploiement en production apporte une validation. Les déploiements fréquents peuvent augmenter légèrement les coûts d'hébergement, mais le fait de pouvoir vérifier que la dernière tâche a été une véritable avancée vaut largement la peine. L'un des principes agiles est que « le logiciel fonctionnel est la principale mesure de la progression». Les mots « fonctionnel» et « progression» ont ici une signification essentielle, c'est pourquoi j'ai créé ma propre définition. « Fonctionnel» signifie prêt pour le déploiement, et si un code contribue à une fonctionnalité, c'est une « progression».
4. Demandez-vous si vous êtes en train de tester les fonctionnalités du framework. Si c'est le cas, ne le faites pas.
Le framework a déjà été testé par des personnes bien plus expertes que vous, et vous devez faire confiance au fait que le hook useState() fonctionne comme prévu. Si vous maintenez les composants petits, le framework gère la plupart des tâches essentielles, donc vous n'avez pas besoin de beaucoup de tests. Plus les composants sont gros, plus la complexité augmente, et plus vous devez écrire de tests.
5. Si une fonction particulière ne correspond à aucun endroit, créez un nouveau module (ou une classe ou un composant) et trouvez l'emplacement approprié plus tard.
Il vaut mieux créer une nouvelle structure indépendante que de la forcer à un endroit où elle ne semble pas correspondre. Au pire, le fait de rester un module indépendant n'est pas si mal.
6. Si vous ne savez pas à quoi devrait ressembler une API, écrivez d'abord les tests.
Cela vous oblige à penser du point de vue de votre « client», qui êtes vous-même dans ce cas. Vous pourriez trouver des cas que vous n'auriez pas détectés si vous aviez écrit le code d'abord et les tests ensuite. Il n'est pas nécessaire d'être trop dogmatique avec le TDD, et vous pouvez travailler sur des unités plus grandes (par exemple, écrire plusieurs lignes de code avant que le test ne réussisse). La quantité de code dans un état d'échec n'a pas toujours besoin d'être faible. Si vous savez ce que vous faites, assurez-vous que les principes n'affectent pas votre productivité.
7. Copier-coller est acceptable une fois.
Ne faites pas de deuxième duplication (c'est-à-dire une troisième copie). À ce stade, vous aurez suffisamment d'exemples pour créer une bonne abstraction. Le risque que les implémentations de la même fonctionnalité diffèrent est trop important, il est donc nécessaire d'une intégration. Une paramétrisation quelque peu maladroite est préférable à la mise en œuvre de fonctionnalités similaires plusieurs fois. Si cela se reproduit, il sera plus facile d'améliorer les paramètres que d'intégrer quatre implémentations différentes.
8. La conception est vouée à devenir obsolète.
La refactorisation peut ralentir ce processus, mais vous devrez finalement changer la façon dont cela fonctionne. Ne soyez pas trop affecté lorsque vous devrez abandonner quelque chose que vous chérissiez et dont vous étiez fier autrefois. Vous avez fait de votre mieux à l'époque, et vous n'avez pas à vous blâmer de ne pas l'avoir rendu parfait au point qu'aucun changement ne soit nécessaire. La majeure partie du développement logiciel consiste à modifier le logiciel. Acceptez cela et avancez. Il n'y a pas de conception parfaite, et le changement est au cœur du développement logiciel. Votre capacité à effectuer des changements efficacement détermine vos compétences en tant que développeur.
9. La dette technique peut être classée en trois catégories :
1) les éléments qui entravent les travaux actuels, 2) les éléments qui entraveront les travaux futurs, 3) les éléments qui pourraient entraver les travaux futurs. Toutes les autres classifications sont des sous-ensembles de ces trois catégories. Minimisez le nombre d'éléments de la catégorie #1 et concentrez-vous sur la catégorie #2. Ne vous souciez pas de la catégorie #3.
10. La testabilité est étroitement liée à une bonne conception.
L'impossibilité de tester facilement est un signe qu'il faut modifier la conception. Parfois, il peut s'agir de la conception du test. Par exemple, s'il est difficile de simuler em.getRepository(User).findOneOrFail({id}), il est préférable de séparer cet appel dans une fonction distincte simulable ou d'écrire un utilitaire de test permettant de simuler facilement les méthodes de l'Entity Manager. Si les tests ne sont pas écrits, ce n'est pas parce qu'on ne veut pas les écrire, mais parce qu'ils sont difficiles à écrire.
Commentaires0