DEV Community: Yosmar Hinestroza

[Boost]

Yosmar Hinestroza — Wed, 27 Aug 2025 12:33:25 +0000

Yosmar Hinestroza

Aug 27 '25

🤖 ChatGPT, Copilot y compañía: ¿aliados o jefes ocultos?

#ai #webdev #programming #javascript

Comments 1

3 min read

🤖 ChatGPT, Copilot y compañía: ¿aliados o jefes ocultos?

Yosmar Hinestroza — Wed, 27 Aug 2025 12:33:06 +0000

Imagínalo: abres tu editor de código, escribes la primera línea… y de pronto Copilot completa el resto. ChatGPT te sugiere soluciones que jamás habías considerado. Y tú te preguntas: “¿sigo siendo yo el programador o solo el que aprieta Enter?” 😅

Las IA se han convertido en esos colegas silenciosos que nunca se cansan y siempre tienen una respuesta lista. Pero, ¿son realmente aliados que potencian nuestro trabajo, o poco a poco se están convirtiendo en jefes invisibles que dictan cómo debemos programar?

1. La entrada triunfal de los copilotos de código

Hoy en día, herramientas como GitHub Copilot, ChatGPT o Tabnine se han vuelto compañeras de teclado para muchos devs. Escribir código ya no es solo tu tarea: tienes una IA sugiriendo líneas, completando funciones e incluso detectando errores.

La pregunta clave: ¿son una ayuda o están tomando el volante?

2. ✅ Los aliados invisibles

Ahorro de tiempo: escribir boilerplate nunca fue tan rápido.
Más productividad: te ayudan a enfocarte en la lógica en lugar de lo repetitivo.
Aprendizaje acelerado: funcionan como “profes” 24/7 que te muestran nuevas formas de resolver problemas.

En otras palabras, son ese compañero que siempre tiene la documentación a mano.

3. ❌ El riesgo de convertirlos en “jefes ocultos”

La línea es delgada: un día usas ChatGPT o Copilot como ayuda rápida, y al siguiente te descubres aceptando cada sugerencia sin cuestionarla.

El peligro está en que la herramienta pase de ser un apoyo a ser quien decide por ti. Cuando dejamos de analizar lo que escribimos y solo confiamos ciegamente en la máquina, el programador corre el riesgo de convertirse en un operador de prompts, perdiendo criterio, creatividad y hasta el sentido crítico que lo hace valioso.

La IA no debería dictar nuestro código, sino acompañarnos en el proceso. Porque, seamos honestos, si dejamos que piense todo por nosotros, ¿en qué momento seguimos siendo desarrolladores y no simples supervisores de autocompletado?

Dependencia excesiva: confiar ciegamente puede hacerte perder habilidades básicas.

Errores invisibles: la IA puede sugerir código incorrecto y, si no lo revisas, se cuela en producción.

Falsa seguridad: sentir que “ya sabes” un tema solo porque la IA te lo resolvió.

4. 🤝 El balance ideal

La clave no está en rechazar estas herramientas ni en rendirles pleitesía, sino en usar su poder sin perder nuestra voz como devs.

El balance ideal es ver a ChatGPT, Copilot y compañía como mentores veloces, no como jefes. Que aceleren tu flujo de trabajo, sí, pero que nunca apaguen tu criterio ni tu estilo.

Preguntarte “¿entiendo lo que estoy pegando en mi código?” debería ser tu brújula.

Si logramos mantener esa conciencia, la IA se convierte en un aliado que potencia nuestra creatividad, en lugar de reemplazarla.

La clave no es rechazarlos ni idolatrarlos, sino usarlos como herramientas estratégicas:

Úsalos para acelerar, no para pensar por ti.
Valida siempre el código como si viniera de un junior que necesita supervisión.
Aprovecha la IA para inspirarte, pero dedica tiempo a reforzar tu criterio y tus fundamentos.

5. 🚀 Conclusión

La IA no vino a reemplazar a los programadores, sino a aumentar sus capacidades. Pero ojo: si no tienes criterio técnico, corres el riesgo de que la máquina pase de ser tu copiloto a tu jefe.

En definitiva: tú decides si tomas el mando o entregas el volante.

Cual Aprender

Yosmar Hinestroza — Fri, 22 Aug 2025 13:08:08 +0000

Frameworks JS: ¿Realmente necesitas aprenderlos todos?

Yosmar Hinestroza ・ Aug 22

#webdev #programming #javascript #devops

Frameworks JS: ¿Realmente necesitas aprenderlos todos?

Yosmar Hinestroza — Fri, 22 Aug 2025 13:07:37 +0000

El mundo JavaScript avanza tan rápido que a veces parece que si no aprendes el framework de moda, te quedas atrás. Hoy es React, ayer fue Angular, mañana será Solid o Qwik. Pero… ¿de verdad necesitas aprenderlos todos para ser un buen programador?

Spoiler: no.

😱 El FOMO Dev (Fear Of Missing Out)

Cada semana en Twitter/X o LinkedIn alguien comparte el “nuevo framework que destronará a React”.
Como dev, sientes que si no lo aprendes, vas a perder oportunidades laborales.
Esta ansiedad genera la falsa idea de que hay que estar en todo, siempre.

🚨 El problema de la moda

Muchas veces un framework se pone de moda porque es “cool”, no porque sea la mejor herramienta para tu proyecto.
Aprenderlos todos no solo es imposible, también desgasta y confunde.
La moda pasa, pero tu tiempo de aprendizaje no vuelve.

✅ Cómo priorizar el aprendizaje

En lugar de intentar aprender todos los frameworks al mismo tiempo, enfócate en lo que realmente te dará valor:

Domina las bases de JavaScript 👉 si entiendes bien el lenguaje, adaptarte a cualquier framework será mucho más fácil.

Aprende según tu contexto 👉 si buscas trabajo, revisa qué tecnologías demandan más en tu región o en las empresas que te interesan.

Profundiza en uno, conoce superficialmente otros 👉 sé especialista en uno (React, Vue o Angular) pero mantén una mirada general de los demás para no quedarte fuera de conversación.

Piensa en tu proyecto personal 👉 si quieres lanzar una app rápida, elige el framework que más se adapte a ese objetivo, aunque no sea el “de moda”.

📌 Recuerda: aprender frameworks no es una carrera de velocidad, sino de resistencia. El verdadero poder está en tener criterio para elegir qué aprender y cuándo.

🧘‍♂️ Reflexión final

El trabajo de un programador no es coleccionar frameworks como si fueran cromos, sino resolver problemas con las herramientas correctas.

No necesitas aprenderlos todos: necesitas criterio para elegir cuándo y cuál usar.

¿Qué es realmente el trabajo de un programador (y qué no)?

Yosmar Hinestroza — Mon, 18 Aug 2025 12:33:11 +0000

Mucha gente cree que ser programador es vivir en la Matrix: pantallas negras llenas de código verde, dedos que vuelan sobre el teclado y soluciones mágicas a cualquier problema.

La realidad es mucho menos hollywoodense y mucho más humana.

Hoy vamos a hablar de lo que sí es y lo que no es el trabajo de un programador.

❌ Lo que NO es el trabajo de un programador

1. No es ser “el chico de los cables”

→ Conectar impresoras, arreglar el WiFi o instalar la impresora de la oficina… eso es soporte técnico, no programación.
(Aunque inevitablemente siempre nos lo piden 😅).

2. No es magia de Matrix

→ No todo es escribir líneas verdes en una pantalla negra al estilo película. Programar es más lógica, paciencia y prueba-error que “hackear la NASA en 5 minutos”.

3. No es adivinar requisitos

→ Si un cliente dice: “Hazme una app como Uber pero diferente” sin dar detalles, no significa que podamos leer la mente. Necesitamos especificaciones, objetivos y comunicación clara.

4. No es escribir código infinito sin parar

→ El trabajo real incluye leer documentación, hacer pruebas, reuniones, planificar, e incluso (sí, aunque duela) lidiar con bugs de otros.

5. No es hacerlo todo solos

→ La programación es colaborativa: se trabaja en equipo, se revisa código y se busca feedback. El “programador lobo solitario” es más mito que realidad.

6. No es trabajar gratis “porque es fácil”

→ Si alguien dice: “Eso en Python son dos líneas”, probablemente no entiende que detrás hay horas de experiencia, investigación y mantenimiento.

7. No es estar disponible 24/7

→ Sí, la tecnología nunca duerme… pero los programadores sí. No significa que seamos el “botón rojo” que resuelve cualquier cosa a las 3 AM.

✅ Lo que SÍ es el trabajo de un programador

1. Resolver problemas con lógica y creatividad

→ Programar no es solo código, es encontrar la mejor forma de resolver un problema usando tecnología.

2. Traducir ideas en soluciones

→ Un programador toma una necesidad (ejemplo: “quiero vender online”) y la convierte en software funcional (una tienda web, una app, un sistema).

3. Leer y entender más de lo que escribe

→ Gran parte del tiempo se va en leer documentación, investigar y entender código previo. Spoiler: programar no es solo “picar código”, es aprender constantemente.

4. Trabajar en equipo (humano + máquina)

→ Se colabora con diseñadores, testers, product managers y hasta con la IA 🤭. La programación moderna no es solitaria, sino un engranaje dentro de un equipo.

5. Prueba y error… mucho error

→ Programar implica fallar, depurar y volver a intentar. Los bugs son parte del proceso, no un accidente raro.

6. Construir con visión a futuro

→ No se trata solo de “que funcione hoy”, sino de escribir código que sea mantenible, escalable y que otros puedan entender después.

7. Estar en aprendizaje constante

→ El mundo tech cambia rápido. Frameworks, lenguajes y metodologías evolucionan, y un programador siempre está aprendiendo para no quedarse atrás.

🤹 Un día real en la vida de un programador podría incluir:

Revisar tickets en Jira o Trello o herramienta asignada.
Debuggear un bug que parecía simple pero se convierte en un jefe final de videojuego.
Escribir un par de líneas de código y luego borrarlas porque “no era por ahí”.
Reír (o llorar) en un daily standup.
Antes Googlear “cómo hacer un for loop en X framework” aunque ya llevas años programando.

Ahora se lo preguntamos todos a la #ai 🤹

🚀 Conclusión

El trabajo de un programador es menos “código mágico” y más constancia, curiosidad y comunicación.

Si lo ves bien, ser programador es como ser detective: sigues pistas, pruebas hipótesis y celebras cuando logras descifrar el misterio.

Lo que definitivamente no es: estar todo el día jugando con la computadora sin sentido.

🏡 Trabajo remoto: 7 trucos para no perder la cabeza

Yosmar Hinestroza — Sat, 16 Aug 2025 13:18:09 +0000

El trabajo remoto llegó para quedarse, pero no todo es tan idílico como suena: trabajar en pijama, con la cama a un metro de distancia y la cocina tentándote cada cinco minutos puede convertirse en una trampa mortal para tu productividad… y tu cordura.

Aquí van 7 trucos para sobrevivir al trabajo remoto sin perder la cabeza (ni el WiFi):

1. 📅 Establece una rutina (aunque no uses pantalones)

La flexibilidad es buena, pero sin horarios claros terminarás trabajando a las 3 a.m. Define horas de inicio, pausas y cierre de jornada. Y sí, ¡ponte algo más que pijama aunque sea arriba de la cintura!

👉 Herramientas que pueden ayudarte a organizar tu tiempo:

Google Calendar → Para organizar bloques de trabajo, recordatorios y hasta pausas para estirar.

Notion → Ideal para crear tu agenda personal con tareas y objetivos diarios.

Trello o Asana → Si trabajas en equipo, te ayudan a visualizar proyectos y deadlines.

Clockify → Para medir en qué gastas realmente tu tiempo (spoiler: TikTok se lleva más de lo que imaginas).

2. 🪑 Ten un espacio de trabajo propio

Tu cama no es tu oficina. Un rincón con una mesa, una silla decente y buena luz ya marcan la diferencia. Separar espacios ayuda a que tu cerebro entienda cuándo es hora de trabajar y cuándo de descansar.

3. ⏰ Domina la técnica Pomodoro (versión “mate y empanada”)

No se trata solo de trabajar duro, sino de trabajar con ritmo.** Divide tu jornada en bloques de 25 a 50 minutos de foco total, seguidos de pausas cortas de 5 a 10 minutos**.
En esos descansos:

Levántate, estira el cuerpo, mira por la ventana (sí, el mundo sigue existiendo).
Tómate un café, un mate o hasta una empanada si el hambre ataca.
Pero lo importante: aléjate de la pantalla. Tus ojos y tu cerebro necesitan ese respiro para rendir mejor.

Si quieres hacerlo aún más pro, prueba apps como Pomofocus o Focus To-Do, que te llevan el conteo y hasta te recuerdan que ya es hora de dejar el teclado y respirar.

4. 🚶‍♂️ Muévete, no eres un mueble

Estiramientos, caminatas o incluso bailar tu canción favorita en medio de la jornada. El sedentarismo remoto es el verdadero enemigo.

5. 🗣️ Mantén contacto humano (aunque sea virtual)

Haz videollamadas, manda un meme a tu equipo o comparte anécdotas. El aislamiento es real, y hablar con la planta no cuenta.

6. 📵 Aprende a desconectar

El trabajo remoto corre el riesgo de convertirse en “trabajo infinito”. Cierra tu laptop al final del día y evita responder correos después del horario laboral. Tu salud mental lo agradecerá.

7. 😎 Crea tu ritual de cierre (sí, como apagar la compu en Matrix)

Tu cerebro necesita una señal clara de que el modo trabajo terminó y ahora empieza el modo vida.
¿Cómo hacerlo? Elige un ritual que te guste:

Salir a caminar para despejarte.
Preparar tu café o té “de premio”.
Cambiarte de ropa (bye pijama, hola persona funcional).
O incluso apagar el PC con música épica de fondo (extra recomendado 🎶).

La idea es simple: darle a tu mente un “switch” mental que marque el fin de la jornada. Créeme, evita que sigas pensando en bugs a las 11 de la noche.

👉 Conclusión:

El trabajo remoto es una maravilla si sabes domarlo. Con disciplina, pequeños rituales y un poco de humor, puedes disfrutar de lo mejor de este estilo de vida sin que te conviertas en un ermitaño digital.

El deploy del viernes a las 5 pm

Yosmar Hinestroza — Thu, 14 Aug 2025 13:24:11 +0000

Hay historias que empiezan bien y terminan mal… y luego están las que empiezan mal y terminan en un correo a todo el equipo con el asunto
“URGENTE: rollback inmediato”.

Sí, hablo de esa decisión cuestionable: hacer un deploy un viernes a las 5 de la tarde.

Todo comenzó con “es un cambio pequeño”

Era viernes, el reloj marcaba las 16:58.
Un compañero, con la confianza de un Jedi, dice:

“Es solo un cambio pequeño, lo subo y me voy.”

Yo, ingenuo, pensé: “Bah, no puede pasar nada… ¿verdad?”
Spoiler: podía pasar mucho.

El despliegue maldito

Se hace el deploy.
Dos minutos después:

Los logs empiezan a llenarse de errores que nunca habíamos visto.
El login deja de funcionar para algunos usuarios.
El servidor, que había sido nuestro amigo toda la semana, empieza a comportarse como si tuviera vida propia.

La cadena de pánico

17:10 → Mensajes urgentes en Slack: “¿Quién tocó producción?”

17:15 → Todos los que ya estaban en la micro, el metro o en un bar, vuelven corriendo (o se conectan desde el celular).

17:20 → El jefe entra en modo supervivencia, pidiendo que “arreglemos lo más rápido posible”.

17:40 → Rollback exitoso, pero no sin sudar más que en una entrevista técnica de Google.

La lección grabada a fuego

Nunca, repito, NUNCA hagas un deploy el viernes a última hora.
No importa si es “solo una línea de código” o “un pequeño fix”.
Si algo sale mal, tu fin de semana quedará oficialmente destruido.

Protocolo anti-desastres

Planifica los deploys temprano en la semana (ideal martes o miércoles).
Ten un rollback claro y probado antes de subir cualquier cambio.
No cedas a la presión del “es rápido”.
Documenta lo que subiste, así no queda todo en el aire.

*💡 Conclusión: *

El deploy del viernes a las 5 pm no es una historia de valentía, es una leyenda de advertencia.

Quien la vive, aprende… o repite y se convierte en el protagonista de la próxima.

La trampa de querer aprender todo a la vez

Yosmar Hinestroza — Mon, 11 Aug 2025 12:31:34 +0000

Caen en esa trampa de querer dominar React, Vue, Node, Python, Go, Kubernetes, Inteligencia Artificial, blockchain y cocina molecular… todo en el mismo mes.

Entrar al mundo de la programación es como entrar a una tienda de dulces… pero cada dulce es un lenguaje, framework o tecnología nueva.
Quieres probarlo TODO, y rápido.

El problema es que, cuando intentas comerte toda la tienda, terminas con dolor de cabeza… y sin haber disfrutado nada.

Existe el síndrome del “shiny object” Saber Más

En el mundo tech, siempre hay algo nuevo:

Un framework que “reemplazará todo lo anterior”.
Una librería que “te hará programar 10 veces más rápido”.
Un lenguaje que “va a ser el futuro”.

Y claro, como buen curioso, saltas de tutorial en tutorial, de curso en curso… pero al final, no terminas ninguno.

Por qué es un problema

Querer aprender todo al mismo tiempo suena productivo, pero en realidad es una receta para:

Tener conocimientos superficiales de muchas cosas, pero no profundidad en ninguna.
Sentirte frustrado porque sientes que “nunca terminas”.
Perder tiempo re-aprendiendo lo que olvidaste por no practicarlo.

Es como ir al gimnasio y hacer un set de cada máquina sin nunca trabajar un músculo a fondo: no hay progreso real.

La clave: enfoque y profundidad

Si quieres crecer de verdad como desarrollador:

Elige una base sólida (por ejemplo, JavaScript + un framework).
Márcate proyectos concretos para aplicar lo aprendido.
Aprende lo demás poco a poco y según lo vayas necesitando.

La meta no es saber todo, es saber resolver problemas.

Mi experiencia (y fail personal)

En mis primeros años, quise aprender React, Angular, Vue, Node, Python, Django, Laravel… todo en 6 meses.

Resultado: muchos cursos a medias, cero proyectos terminados y una carpeta llena de archivos index.html que no llevan a ninguna parte.

Fue hasta que me enfoqué en un solo stack que empecé a sentirme realmente competente.

💡 Conclusión

En tecnología, la información es infinita… pero tu tiempo y energía no.

Si te enfocas en lo importante ahora, tendrás la base para aprender lo demás más rápido en el futuro.

Recuerda: mejor ser experto en una herramienta que aprendiz eterno de todas.

Cuando el cliente dice: “solo es cambiar un color”

Yosmar Hinestroza — Sat, 09 Aug 2025 15:45:21 +0000

Si eres programador, diseñador o cualquier especie de ser humano que trabaja en tecnología, probablemente hayas escuchado esta frase mágica:

“Oye, es solo cambiar un color… ¿cierto?”

Spoiler: nunca es solo cambiar un color

Déjame contarte la historia de cómo un pequeño ajuste visual se convirtió en una misión imposible digna de Tom Cruise (pero sin la paga de Tom Cruise).

El inicio inocente

Era un día tranquilo. El código compilaba, el café estaba caliente y hasta pensé que saldría temprano.
De repente, el cliente me escribe:

Yosmar, ¿puedes poner el botón en azul? Es solo un cambio rápido, nada del otro mundo.”

Yo, ingenuo, pensé: “Listo, CSS, cambio de hex y seguimos.”
Oh, qué equivocado estaba.

La caída al caos Cambio el color y…

El texto del botón ahora no se ve porque el contraste es pésimo.

El azul no se parece al que el cliente quiere (“Es un azul más feliz, como el del logo de Facebook pero no tanto…”).

En modo oscuro, ese azul se ve como si estuviera roto.

En Android se ve bien, pero en iPhone parece morado.

En la versión antigua del navegador del jefe, ni siquiera aparece el color.

En ese momento entendí que había abierto la Caja de Pandora del diseño.

Las reuniones de “ajustes”

Lo que siguió fueron tres reuniones, quince correos y una cadena de mensajes de WhatsApp con capturas de pantalla de cómo

“el color se ve diferente en mi monitor”.

Y ahí recordé la regla de oro: cuando un cliente dice “solo es”, probablemente no lo sea.

La lección aprendida

Ahora, cada vez que escucho esa frase, aplico el protocolo de supervivencia:

Pido ejemplos exactos del color (hex, RGB, o mejor, un diseño en Figma).
Pruebo en todos los entornos antes de enviar el cambio.
Aclaro el alcance: “Si el cambio implica ajustes de contraste o accesibilidad, lo cotizamos aparte.”
Nunca lo hago en viernes (por mi salud mental).

💡 Conclusión

Cambiar un color puede ser tan sencillo como mover un par de valores en el CSS… o tan complejo como reescribir medio sistema de estilos.

Así que, la próxima vez que escuches “solo es cambiar un color”, recuerda que detrás de esa frase se esconde un mundo de variables, pantallas, navegadores y expectativas que no siempre combinan.

Cuando el cliente dice “solo es cambiar un color”…
Terminas actualizando media app, ajustando contrastes, discutiendo si es “azul feliz” o “azul serio” y aprendiendo que, en realidad, nada es solo. 🎨💀

5 trucos para sobrevivir a tu primer trabajo como programador

Yosmar Hinestroza — Fri, 08 Aug 2025 14:33:15 +0000

Empezar tu primer trabajo como programador es como entrar a un juego en modo difícil… pero sin tutorial.

De repente tienes jefes, plazos, reuniones que podrían haber sido un correo y un código que no escribiste pero ahora tienes que arreglar.
Tranquilo, todos hemos pasado por ahí.

Aquí te dejo 5 trucos que pueden salvarte la vida (y la sanidad mental) en esos primeros meses.

1. Aprende a decir “no sé… pero lo investigo”

El error más común de un dev novato es fingir que lo sabe todo. No pasa nada si no tienes la respuesta de inmediato.

Lo que sí pasa es que, si inventas, terminarás con más problemas que líneas de código.
Frase mágica:

“No lo sé todavía, pero puedo revisarlo y darte una respuesta.”
Eso muestra humildad y proactividad al mismo tiempo.

2. Documenta TODO (aunque sea para ti mismo)

Ese comando que usaste para levantar el servidor, el enlace raro que encontraste, la configuración que cambiaste…
Documentarlo te salva cuando, tres semanas después, te preguntes:

“¿Y cómo rayos hice esto?”

Puede ser en Notion, Google Docs o un simple archivo notas.md. Lo importante es que exista.

3. Haz preguntas inteligentes

Está bien preguntar, pero evita soltar un “no funciona” sin contexto.
Antes de ir con tu senior, prepara:

Qué estabas intentando hacer.
Qué error exacto te salió.
Qué intentaste para solucionarlo.

Eso hace que te tomen en serio y que aprendan que no eres un “bot de problemas”.

4. Cuida tu salud mental y física

La vida de programador no es solo código. Si no te cuidas, el burnout llega rápido.

Levántate de la silla cada hora.
Haz algo que no sea mirar pantallas en tus descansos.

> No te lleves el trabajo a la cama (sí, eso incluye abrir el portátil a las 11 pm “solo para revisar algo rápido”).

5. Encuentra un mentor (o un compañero de guerra)

Tener a alguien con más experiencia dispuesto a guiarte es oro puro.
Si no lo tienes, busca apoyo en comunidades online, Discords de programación o grupos de desarrolladores.
Un buen mentor no solo te enseña código, también te ayuda a navegar la política de oficina y los proyectos imposibles.

> 💬 En resumen

Sobrevivir a tu primer trabajo como programador es un equilibrio entre aprender rápido, pedir ayuda de forma inteligente y cuidar tu bienestar.

Si aplicas estos trucos, no solo saldrás vivo… ¡saldrás más fuerte y listo para el siguiente reto!

Envias Correo Electrónicos gratis con Resend Emails

Yosmar Hinestroza — Wed, 08 Jan 2025 04:08:24 +0000

Hola comunidad! en esta ocasión les traigo un pequeño ejemplo para poder crear tu propía API, para envios de Correo Eleéctronico

Todo esto es gracias a RESEND

Video Implementación

Se instalan las diferente Librerías

npm i express bodyParser cors Resend dotenv

Se crea archivo server.js

import express from 'express';
import bodyParser from 'body-parser';
import cors from 'cors';
import { Resend } from 'resend';

const app = express();

app.use(cors());
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

console.log(process.env.RESEND_API_KEY);
const PORT = process.env.PORT || 4002;
const resend = new Resend(process.env.RESEND_API_KEY ?? '')

app.get('/', (req, res) => {
    res.send('Hello World');
})

app.post('/send-email',  async (req, res) => {
    try {
        const { from, to, subject, html } = req.body;
        const response = await resend.emails.send({ from, to, subject, html });
        res.status(200).send(response);
      } catch (error) {
        res.status(500).send({ error: 'Failed to send email' });
      }
})



app.listen(PORT, () => {
    console.log(`Server is running on port localhost:${PORT}`);
});

En el archivo package.json editar la siguiente linea

"scripts": {
    "start": "node -r dotenv/config ./src/server.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Mi primera Libreria en NPM

Yosmar Hinestroza — Wed, 08 Jan 2025 03:54:19 +0000

Tabla Componente basada de Material UI.

Es una idea que salió de muchas dificultades que se presentaron en diferentes implementaciones en diferente software

Esta tabla solo ha sido probada usando. React pero puede ser usada en diferentes herramientas

Documentación de Material Table

Material UI

npm i table-component-mui-lib

Documentación NPM

Video implementación

Tabla Referencia

dataSource Datos visibles en la tabla
columns Columna visible en la tabla
isCheckbox Se habilita CheckBox para multiple selección en columnas
isRadioBox Se habilita RadioBox para solo seleccionar un elemento de la columna
selectedData Hooks Data Seleccionada (esto permite usar la data en el componente principal)
setSelectedData Hooks Data para seleccionar data
isPaginate true - false para generar una paginación de la tabla
search Se habilita un textBox para buscar dentro de la tabla
isDowmload Permite habilitar button para descargar archivo excel
_styleColumn Estilo personalizable a las columnas de la tabla
childreButton Botones personalizable en la tabla

Tipo de Datos Columnas

export interface HeadCell {
    disablePadding?: boolean;
    id?: keyof any;
    label?: string;
    numeric?: boolean;
    sort?: boolean;
    width?: number;
  }

Creación de Columna personalizadas

const column: HeadCell[] = [
  {
    id: 'id',
    numeric: false,
    disablePadding: false,
    label: 'ID',
    sort: true
  },
  {
    id: 'name',
    numeric: false,
    disablePadding: false,
    label: 'Name',
    sort: true
  },
  {
    id: 'username',
    numeric: false,
    disablePadding: false,
    label: 'User Name',
    sort: true
  },
  {
    id: 'email',
    numeric: false,
    disablePadding: false,
    label: 'Correo Eléctronico',
    sort: true
  },

]

Ejemplo Componente

`
import { TableComponents, HeadCell } from 'table-component-mui-lib'

     <TableComponents
            dataSource={dataSource ?? []}
            dataSourceExcel={dataTableFields.data ?? []}
            columns={columns ?? []}
            isCheckbox={false}
            isRadioBox={false}
            selectedData={data seleccionada de las columnas}
            setSelectedData={hooks de selección de datos}
            isPaginate
            search
            isDowmload
            initialSelectionNumber={5}
            _styleColumn={{ backgroundColor: `#cdcd`, color: '#000' }}
            childreButton={(row: any) => (
              <Box sx={{ display: 'flex', gap: 1, alignContent: 'center' }}>
                <RadioGroup
                  aria-labelledby='demo-controlled-radio-buttons-group'
                  name='controlled-radio-buttons-group'
                >
                  <FormControlLabel
                    sx={{ ml: 1 }}
                    control={<Radio
                      color='success'
                      checked={boolean}
                      onClick={() => { }}
                             />}
                    onClick={(e: React.ChangeEvent<HTMLInputElement> | any) => {  }} // Guarda los datos de la fila seleccionada}
                    label=''
                  />
                </RadioGroup>
                <IconButton size='medium' sx={{ mr: 1 }}>
                  <Edit
                    style={{ color: #000 }} onClick={() => { }}
                  />
                </IconButton>

              </Box>
            )}
          />
`