- Replit – Build apps and sites with AI
- Replit is an AI-powered platform for building professional web apps and websites.
Suscripción paga a replit durante 1 año
He decidido suscribirme hasta el 1 de diciembre debido a la oferta del Black Friday, ya que necesito probar una herramienta de programación con IA.
La razón por la que elegí esta opción es que no tengo un ordenador potente,
- Ejecución y verificación de resultados en el navegador sin necesidad de instalar compiladores o intérpretes localmente.
- Aprenda a programar sin preocuparse por la configuración del entorno.
- Projectos de codificación colaborativos. (Puedo compartir el enlace para programar en parejas) - Si es necesario, cualquiera puede unirse.
- Prototipado y prueba rápidos del código.
- Enseñar codificación a los estudiantes de forma interactiva.
- Alojamiento de aplicaciones web ligeras o API.
Tendré que grabar un vídeo sobre esto en el futuro. https://replit.com/
Mirando el mundo. (Noticias diversas)
Economía
2024-11-29 (Vie) Rutina matutina (Hankyeong) : Corea del Sur baja el tipo de interés de 3.25 a 3.0% / Aumento de la brecha de ingresos, disminución del consumo / X-ble Shoulder (robot portátil) / ETF de acciones de valor al 20% (supuestamente compradas por extranjeros)
>> Al final, si los extranjeros no compran, no hay forma de que suba el precio de las acciones.
IT
- 지금 주목해야 할 ‘생성 AI 소비 트렌드’ TOP 4 | 요즘IT
- 미국의 주요 기업들이 올해 3분기 실적을 발표했습니다. 실적 발표 자리에서 소위 빅테크 기업들은 생성 AI에 대한 투자를 지속할 것임을 예고했습니다. 천문학적인 금액이 쏟아지고 있는 만큼, 생성 AI 산업을 구성하는 트렌드는 빠른 속도로 변화하고 있는데요. 이번 글에서는 지난 8월 안드레센 호로위츠가 발표한 자료를 토대로 사용자들이 실제 어떤 생성 AI 서비스를 사용하고 있는지, 소비 트렌드를 살펴보고자 합니다.
- 코드 작성 시간 절반으로 줄여줄 5가지 개발 툴 | 요즘IT
- 여러분은 매일 코드 작성과 디버깅에 얼마나 많은 시간을 소비하나요? 지금부터 소개해 드릴 AI와 자동화 툴 5가지만 제대로 활용해도 그 시간을 절반으로 줄일 수 있습니다. 개발자의 하루는 해결해야 할 문제로 가득하니까요. 코드 작성을 도와주는 GitHub Copilot부터 코드 품질을 한눈에 개선해 주는 SonarQube까지. 이 툴들은 어떻게 여러분의 개발 생산성과 코드 품질을 끌어올려 줄까요?
10 hábitos que debe seguir para convertirse en un buen desarrollador
>> Justo eso es lo que sentí mientras creaba y mantenía la plataforma de telemática/clúster, pero no pude ponerlo en práctica. No debo temer al cambio, y si lo divido en partes pequeñas como aquí, creo que es posible.
1. Mantenga los commits lo más pequeños posible, hasta el punto de pensar: "¿Puedo hacerlo tan pequeño?"
Nunca se sabe cuándo tendrá que deshacer un cambio específico. Saber la ubicación exacta de un error que ocurrió hace 6 días y poder deshacer solo ese commit sin complejas fusiones conflictivas da una gran tranquilidad. Mi criterio es simple: el código que compila se puede confirmar.
2. Ponga en práctica el dicho de Kent Beck: "Para hacer el cambio que desea, primero haga que ese cambio sea fácil (cuidado: esto puede ser difícil), y luego haga el cambio fácil."
"Para hacer el cambio que desea, primero haga que ese cambio sea fácil (cuidado: esto puede ser difícil), y luego haga el cambio fácil."
Haga que más de la mitad de los commits sean refactorizaciones. La refactorización continua consiste en encontrar y aplicar mejoras que se puedan realizar en menos de 10 minutos. Gracias a estas pequeñas mejoras, cuando se presente una gran solicitud más adelante, podrá resolverla con solo pequeños cambios. Se deben evitar las refactorizaciones a gran escala.
3. Todo el código es deuda.
El código no desplegado es la deuda de las deudas. Debe comprobar si el código funciona correctamente y, como mínimo, si no daña otras funciones. Las pruebas dan confianza y el despliegue de producción proporciona validación. El aumento del coste de alojamiento debido a los despliegues frecuentes puede ser un poco alto, pero merece la pena saber que el último trabajo fue un progreso real. Uno de los principios ágiles dice que "el software que funciona es la medida principal del progreso". Las palabras "funcionamiento" y "progreso" tienen un significado fundamental aquí, así que he establecido mi propia definición. "Funcionamiento" significa un nivel desplegable, y "progreso" es cualquier código que contribuya a una función.
4. Pregúntese si está probando las funciones del framework. Si es así, no lo haga.
El framework ya ha sido probado por personas mucho más profesionales que usted, y debe confiar en que el gancho useState() funciona como se espera. Si mantiene los componentes pequeños, el framework se encarga de la mayoría de las tareas principales, por lo que no se necesitan muchas pruebas. Si los componentes crecen, la complejidad aumenta y debe escribir más pruebas.
5. Si una función en particular no encaja en ningún sitio, cree un nuevo módulo (o clase o componente) y busque el lugar adecuado más tarde.
Es mejor crear una nueva estructura independiente que forzar algo que no encaja. Incluso en el peor de los casos, permanecer como un módulo independiente no es tan malo.
6. Si no sabe qué aspecto debe tener una API, escriba primero la prueba.
Esto le obliga a pensar desde el punto de vista del "cliente", que en este caso es usted mismo. Podrá encontrar casos que no habría encontrado si hubiera escrito el código primero y luego las pruebas. No es necesario ser demasiado dogmático con TDD, y puede trabajar en unidades más grandes (por ejemplo, escribir varias líneas de código antes de que la prueba pase). La cantidad de código en estado de fallo no siempre tiene que ser pequeña. Si sabe lo que está haciendo, asegúrese de que los principios no reduzcan la productividad.
7. Copiar y pegar está bien una vez.
No realice la segunda duplicación (es decir, la tercera copia). En este punto, habrá suficientes ejemplos para crear una buena abstracción. La integración es necesaria porque el riesgo de que las implementaciones de la misma función difieran entre sí es demasiado alto. Una parametrización algo torpe es mejor que implementar una función similar varias veces. Si esta situación vuelve a ocurrir, será más fácil mejorar los parámetros que integrar cuatro implementaciones diferentes.
8. El diseño tiende a quedar obsoleto.
La refactorización puede ralentizarlo, pero al final tendrá que cambiar la forma en que funciona. No se preocupe demasiado cuando tenga que desechar algo que antes apreciaba y del que estaba orgulloso. En su momento hizo todo lo posible y no es necesario que se culpe por no haberlo hecho perfecto hasta el punto de que no necesitara ningún cambio. La mayor parte del desarrollo de software consiste en cambiar el software. Acéptelo y siga adelante. No existe un diseño perfecto, y el cambio es la clave del desarrollo de software. Su capacidad como desarrollador está determinada por la habilidad con la que pueda realizar los cambios.
9. La deuda técnica se puede clasificar en tres categorías:
1) Cosas que interfieren con el trabajo actual, 2) Cosas que interferirán con el trabajo futuro, 3) Cosas que podrían interferir con el trabajo futuro. Todas las demás clasificaciones son subconjuntos de estas tres. Minimice las del #1 y concéntrese en las del #2. No se preocupe por las del #3.
10. La capacidad de prueba está estrechamente relacionada con un buen diseño.
La incapacidad de probar fácilmente es una señal de que debe cambiar el diseño. A veces, ese diseño puede ser el diseño de la prueba. Por ejemplo, si em.getRepository(User).findOneOrFail({id}) es difícil de simular, es aconsejable separar esa llamada en una función separada simulable o escribir una utilidad de prueba que permita simular fácilmente los métodos del administrador de entidades. La razón por la que no se escriben pruebas no es porque no se quieran escribir, sino porque son difíciles de escribir.
Comentarios0