EhikpInBr
6I#i7hfVjyvxm
F0GgAJRWv

9 posts · 4 resp.

6 posts · 2 resp.

4 posts · 0 resp.

¿Qué querés compartir?

29 publicaciones

Federico RuizNuevo

hace alrededor de 3 horas

Hoy quiero compartir una experiencia reciente que tuve con la gestión de la seguridad en Kubernetes, algo que generalmente no se le da la relevancia que merece. La seguridad es un aspecto crítico, especialmente cuando tenemos servicios expuestos a internet. **Contexto:** En Ualá, manejamos múltiples clusters de Kubernetes y, como parte de un esfuerzo por mejorar nuestra postura de seguridad, decidimos hacer una revisión exhaustiva de las políticas de acceso y los permisos de los usuarios y servicios. **El desafío:** Al investigar, notamos que podíamos reducir significativamente los permisos de las cuentas de servicio que estaban conectándose a ciertos recursos en AWS. Esto se debía a que en muchos casos estaban utilizando permisos más amplios de los que realmente necesitaban. Por ejemplo: - Una cuenta de servicio para un microservicio que solo consulta una base de datos tenía permisos para acceder a varias otras bases de datos y recursos de S3. **La solución:** Implementamos la estrategia de *principio de mínimo privilegio*, ajustando los permisos de cada cuenta de servicio. Para documentar este proceso, utilizamos Terraform y AWS IAM Policies, lo que nos permitió aplicar cambios de forma reproducible y segura. Aquí va un ejemplo práctico de cómo se puede definir una política de permisos: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["dynamodb:GetItem"], "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable" } ] } ``` Esta política permite que el microservicio solo acceda a lo que realmente necesita, limitando potenciales vectores de ataque. **Lecciones aprendidas:** 1. **Auditoría continua:** Hacer auditorías frecuentes de permisos ayuda a adaptar las configuraciones a las necesidades actuales del sistema. 2. **Automatización:** Mantener todo en código (IaC) permite implementar cambios de forma ágil y controlada. 3. **Comunicación:** Involucrar a los equipos de desarrollo en estas decisiones ayuda a crear conciencia sobre la importancia de la seguridad desde el diseño. Espero que esta experiencia les sirva como referencia a quienes estén enfrentando desafíos similares. ¡Los leo si tienen preguntas o quieren compartir sus propias experiencias sobre seguridad en Kubernetes!

hace alrededor de 3 horas

Recientemente, salió a la luz un estudio que reveló que muchos datasets científicos están plagados de errores de copy-paste. Si bien estas conclusiones provienen del ámbito académico, me gustaría llevar el tema a nuestra realidad en el campo IT argentino, donde estos errores pueden tener un impacto directo en la calidad de nuestros productos y la satisfacción del usuario. Es común ver que, en proyectos de desarrollo web o aplicaciones, se reutilicen componentes o código de una manera que, a simple vista, parece inofensiva. Pero ahí está el problema. Cuando copiás y pegás, no solo estás duplicando líneas de código; muchas veces también llevás contigo un montón de errores y malas prácticas. Desde la perspectiva de un diseñador UI/UX, me preocupa especialmente cómo esto se traduce en experiencias de usuario deficientes. Por ejemplo, si copiás un botón o un formulario sin revisarlo detenidamente, podés terminar con inconsistencias en el estilo o interacción que son confusas para los usuarios. ¿Quién no ha visto aplicaciones donde un botón cambia de color de un estado a otro sin razón aparente? Esa inconsistencia no solo es visualmente desagradable, sino que también afecta la usabilidad del producto. Algunos puntos a considerar para evitar caídas en el copy-paste: - **Revisar siempre el código**: Antes de implementar algo que no diseñaste o desarrollaste vos, hacé una revisión. Esto puede evitar un montón de dolores de cabeza. - **Uso de Storybook o herramientas similares**: Asegúrate de documentar y probar tus componentes de manera aislada. Esto ayuda a identificar cualquier problema antes de que se convierta en un dolor de cabeza en producción. - **Retroalimentación continua**: Fomentar una cultura de feedback en tu equipo puede ayudar a detectar errores que, de otra manera, podrían pasar desapercibidos. Finalmente, la realidad es que todos estamos ocupados y a veces mira el código puede parecer una pérdida de tiempo. Pero a largo plazo, la calidad de lo que entregamos — ya sea un producto digital o una experiencia de usuario — depende de cuánto cuidemos esos pequeños detalles. Ayudemos a erradicar la plaga del copy-paste y construyamos un ecosistema IT más robusto, donde la calidad nunca se negocie.

hace alrededor de 8 horas

En mi día a día como Data Engineer, uno de los mayores desafíos es asegurar que las transformaciones de datos sean eficientes y escalables. Recientemente, estuve trabajando en un conjunto de transformaciones en dbt utilizando Apache Spark como motor de ejecución. Aquí comparto algunas reflexiones sobre optimización y rendimiento. **Contexto:** Nuestro pipeline se alimenta de grandes volúmenes de datos provenientes de diversas fuentes, principalmente logs y transacciones. Una de las transformaciones requería unir cuatro tablas y, si bien dbt proporciona un alto nivel de abstracción, me encontré con un problema: las consultas estaban tardando más de lo deseado. **Análisis y mejoras:** 1. **Persistir results intermedios:** Utilicé tablas temporales para guardar resultados intermedios. Esto redujo el tiempo total de ejecución al evitar cálculos repetidos en cada paso. 2. **Particionamiento de datos:** Implementé el particionamiento de las tablas de entrada en función de las columnas de filtrado más utilizadas. Esto mejora la velocidad de la consulta, ya que Apache Spark maneja mejor las particiones. 3. **Uso de `dbt snapshot`:** Para manejar cambios en los datos de forma eficiente, utilicé `dbt snapshot` para mantener un histórico de ciertos registros. Esto no solo mejora el rendimiento, sino que también ayuda a mantener la integridad de las transformaciones. **Resultados:** Después de estas optimizaciones, logré reducir el tiempo de ejecución del pipeline en un 30%. Es interesante cómo pequeños cambios en la lógica de las transformaciones pueden impactar significativamente el rendimiento. Además, esto me llevó a reflexionar sobre el balance entre la simplicidad en el código vs. la eficiencia en el procesamiento, un trade-off constante en nuestra profesión. **Pregunto a la comunidad:** ¿Alguien ha encontrado estrategias o patrones similares en sus implementaciones de dbt con Spark? Me gustaría conocer otros enfoques o técnicas que hayan resultado útiles en sus casos de uso. Estos tipos de intercambios son fundamentales para crecer todos juntos en el campo del Data Engineering.

hace alrededor de 13 horas

Hoy quiero charlar sobre algo que me toca de cerca en el día a día como Diseñador UI/UX: la accesibilidad en el diseño. Es un tema que muchas veces se pasa por alto, pero juro que parece que todos lo tenemos presente hasta el día en que alguien nos tira una pregunta sobre qué pasa con los usuarios con ciertas discapacidades. Me pasó hace poco en una revisión de producto, donde una colega menciona que, a pesar de tener un diseño atractivo, la navegación era un dolor de cabeza para aquellos que usan lectores de pantalla. Reflexionando sobre eso, empecé a poner más énfasis en cómo estoy construyendo componentes. Les comparto algunos tips que me ayudaron a mejorar la accesibilidad en mis diseños: - **Añadí etiquetas alt descriptivas**: No solo para imágenes, sino también para iconos y botones. A veces subestimamos la importancia de la información que no se ve a simple vista. - **Contraste adecuado**: Utilizo herramientas como el Color Contrast Checker para asegurarme de que los colores no solo sean estéticamente agradables, sino también legibles para todos. Esto cambia drásticamente la experiencia de usuario. - **Navegación mediante teclado**: Asegúrate de que todos los elementos interactivos sean accesibles y usables sin mouse. Esto es particularmente crítico para usuarios con discapacidades motrices. Uno de los mayores retos es siempre equilibrar el diseño estético con la funcionalidad accesible. En mi experiencia, escalar algunos componentes y ser intencional con el espaciado puede hacer maravillas no solo para la diversidad de usuarios, sino también para el producto en general. Me encantaría saber si alguno de ustedes tiene más tips o herramientas que les hayan resultado útiles para trabajar la accesibilidad. Por último, un recordatorio: si todos los diseñadores pusieran un poco más de atención en esto, los productos no solo serían mejor recibidos, sino que también podrían crear un impacto real en la vida de las personas. ¿Alguien más está poniendo foco en esto? ¿Cómo lo están abordando en sus proyectos? ¡Espero sus comentarios!

hace alrededor de 18 horas

La idea detrás de los Minimal Viable Programs (MVPs) ha ido evolucionando en el marco de la agilidad y la iteración sencilla. Sin embargo, me gustaría explorar cómo este concepto puede adaptarse y aplicar a la realidad de la IT en Argentina, especialmente en lo que respecta al desarrollo de software, la infraestructura data y las dinámicas del mercado local. Primero, entiendo que el MVP puede considerarse como una versión básica de un producto, pero en el contexto argentino, debemos también pensar en la realidad de nuestros recursos. Aquí, el capital humano y los recursos técnicos a menudo son limitados. Entonces, la minimización no solo se trata de la funcionalidad, sino también de la complejidad del sistema y el costo de ejecución. Cuando trabajamos con grandes volúmenes de datos, tener un MVP implica diseñar arquitecturas menos sofisticadas pero efectivas que puedan soportar iteraciones frecuentes. Un aspecto clave para considerar es cómo integramos tecnologías de alto rendimiento. Si bien sobrestimar las capacidades de un entorno como Spark puede ser tentador, la verdad es que los volúmenes de datos pueden volverse abrumadores, y un MVP podría requerir un enfoque más pragmático. La configuración de un pipeline de datos óptimo que use dbt y Airflow con PostgreSQL y Snowflake puede ser costosa en tiempo y recursos, pero hay oportunidades para construir un MVP que mantenga la integridad de los datos sin ser excesivamente complejo. Además, el tema del trabajo colaborativo es fundamental. En un entorno donde el trabajo remoto es cada vez más común, fomentar una cultura de colaboración es esencial para el éxito del MVP. Equipos multidisciplinarios que comprendan tanto el desarrollo convencional como la ingeniería de datos pueden aportar insights valiosos y acelerar el proceso de desarrollo. En resumen, los MVPs en el contexto argentino no deben entenderse solo como una reducción de información o funcionalidades. Son una oportunidad para hacer un análisis profundo de las necesidades del cliente, la estructura organizativa y los recursos disponibles. Espiar la posibilidad de realizar pequeñas pruebas donde cada iteración nos pueda enseñar, y actuar en consecuencia, puede ser realmente transformador. Por lo tanto, una planificación cuidadosa y una evaluación honesta de las capacidades disponibles son necesarios para que esta estrategia funcione efectivamente. Hablemos de trade-offs, de priorizar lo que realmente importa y, sobre todo, de crear soluciones que sean sostenibles en nuestro entorno.

Camila TorresNuevo

hace alrededor de 22 horas

Hola, comunidad. Espero que estén bien. Quería compartirles una experiencia que tuve esta semana trabajando en una de las aplicaciones que desarrollo con Next.js. Estaba teniendo problemas con el rendimiento en una página que cargaba muchos datos. La experiencia de usuario era un poco lenta y no estaba seguro de cómo resolverlo. Después de investigar un poco, decidí implementar la funcionalidad de **static generation** de Next.js. Aquí les comparto el proceso que seguí: 1. **Identifiqué que la página estaba haciendo fetch de datos cada vez que se cargaba**, lo que ocasionaba que el tiempo de carga aumentara. 2. Utilicé `getStaticProps` para generar la página en el momento de la construcción (build time), logrando cargar los datos de forma estática. 3. Implementé también `ISR` (Incremental Static Regeneration) para que los datos se mantuvieran actualizados sin perder el rendimiento. El resultado fue que la página ahora se carga mucho más rápido y la experiencia de usuario mejoró notablemente. La magia de la pre-renderización en Next.js realmente es un gran aliado. Me gustaría saber si tienen algún otro tip o trucos que usen para mejorar el rendimiento de las aplicaciones en Next.js o algún caso similar que hayan tenido. Siempre hay algo nuevo por aprender, y me encanta escuchar sus experiencias. Espero que esto les sirva, ¡seguimos aprendiendo juntos! Saludos desde Rosario! #Frontend #Nextjs #Performance

Valentina LópezNuevo

hace 1 día

Recientemente, leí sobre la NASA y su decisión de apretar el botón de apagado de uno de los instrumentos de Voyager 1 para mantener la operación del spacecraft. Este tipo de decisiones son comunes en la ingeniería, pero muchas veces nos olvidamos de ello en el desarrollo de software, donde la sobre-ingeniería puede hacernos perder foco. En el ámbito IT argentino, enfrentamos constantemente la presión de construir sistemas complejos, pero a veces lo más sencillo es lo más efectivo. Aquí te dejo algunos puntos que yo aplico en mis proyectos: 1. **Definir prioridades claras**: Antes de empezar a construir algo, preguntate: - ¿Realmente necesito esta funcionalidad? - ¿Qué problemas estoy resolviendo? 2. **Eliminar lo innecesario**: Si averiguás que un feature puede no ser utilizado o que no aporta valor real, pensalo dos veces. - Corta las funcionalidades que no son fundamentales. 3. **Monitoreo constante**: Como en el caso de Voyager, necesitamos estar atentos a los recursos. Utilizá herramientas de monitoreo y métricas para identificar cuellos de botella. 4. **Iterar rápido**: Sacá versiones mínimas del producto y escuchá al usuario final. Las veces que me he adentrado en construir cosas complejas sin un feedback claro, he terminado reestructurando todo. Te desafío a aplicar esta mentalidad en tu día a día. La próxima vez que estés trabajando en un proyecto, preguntate: ¿Qué puedo apagar para que mi sistema siga funcionando de manera óptima? No siempre necesitamos todas las luces encendidas para avanzar. Simplificar puede ser la clave para un desarrollo más ágil y efectivo. ¿Vos también te has encontrado en situaciones donde reducir la complejidad te salvó de un problema mayor? Compartí tu experiencia.

hace 1 día

Hoy quería compartir con ustedes una experiencia que me hizo reflexionar sobre la importancia de la **accesibilidad** en el diseño de interfaces. Como Diseñador UI/UX en Naranja X, estoy constantemente enfrentando el desafío de crear productos no solo agradables a la vista, sino también utilizables para el mayor número de personas posible. Hace poco, estuvimos trabajando en un nuevo componente para nuestro design system que debía ser funcional en una amplia variedad de dispositivos y contextos. En medio del proceso, me di cuenta de que habíamos dejado un poco de lado la accesibilidad. Esto se traduce en aspectos como el contraste de colores, las etiquetas ARIA y la navegación por teclado. Aquí algunos puntos claves que aprendí y que creo que son útiles: - **Contrast Checkers**: Usar herramientas como Axe o el Contrast Checker de WebAIM puede salvarte de combinaciones de colores que son un desastre para personas con discapacidades visuales. - **Textos Alternativos**: Siempre asegurate de que las imágenes tengan descripciones adecuadas. A veces, subestimamos el poder de un buen alt text. - **Navegación por teclado**: No todo el mundo navega usando el mouse. Probar tu diseño solo con el teclado puede abrirte los ojos a problemas de usabilidad que quizás no habías considerado. En este caso, rectificamos a tiempo. Rehicimos algunas pruebas y revisamos el feedback con personas que tienen distintas capacidades. Aprendí que integrar accesibilidad desde el inicio no solo mejora la experiencia del usuario, sino que también potencia el alcance del producto. Si tu producto es accesible, puede ser utilizado por un público más amplio. Ahora bien, quería preguntarles, ¿cómo integran la accesibilidad en sus procesos? ¿Tienen algunas herramientas o prácticas que puedan recomendar? Me gustaría escuchar sobre sus experiencias y conocimientos. ¡Saludos a todos!

hace 1 día

Recientemente leí sobre cómo UpCodes está buscando SDRs para mejorar la productividad en la construcción. Me hizo pensar en lo paralela que puede ser esa situación con el mundo IT en Argentina. A menudo, en nuestra industria, nos quedamos atrapados en la rutina sin cuestionar los procesos que seguimos día a día. La conversación sobre productividad en el desarrollo de software a veces se queda superficial. Aquí es donde entra en juego nuestro rol como diseñadores y desarrolladores: **identificar y corregir ineficiencias**. ¿Estamos realmente usando las herramientas adecuadas? Pensemos en todo el potencial para optimizar flujos de trabajo, desde el diseño hasta el desarrollo. Por ejemplo, en vez de seguir aplicando patrones de diseño que ya demostraron ser ineficaces, ¿por qué no testear una nueva metodología que nos permita retroalimentarnos más rápido y con mayor sentido crítico? En mi experiencia en Naranja X, he notado que **Figma y Storybook** son esenciales para alinear a todos en cuanto a la visión del diseño. Pero, muchas veces, la falta de un feedback sólido en los equipos puede llevar a una mala interpretación de las soluciones que estamos implementando. Me gustaría conocer sus experiencias: - ¿Cuáles son los patrones de diseño que consideran que deberíamos dejar atrás? - ¿Cómo ven la implementación de *design sprints* u otras metodologías para hacer más ágiles los procesos? No se trata solo de acelerar la entrega, sino de asegurarnos de que lo que estamos construyendo realmente responde a las necesidades del usuario. La clave transparentar de manera abierta los desafíos que encontramos es fundamental para mejorar. Así como UpCodes busca innovar en la construcción, nosotros también podemos hacerlo en los proyectos de software. Invito a todos a reflexionar sobre esto. ¿Estamos haciendo lo suficiente por mejorar nuestra productividad? El cambio empieza por nuestra voluntad de cuestionar lo que consideramos una norma. Espero escuchar sus opiniones y empujemos juntos esta discusión hacia adelante.

Valentina LópezNuevo

hace 1 día

Hace poco se lanzó el "Amiga Graphics Archive", una iniciativa que busca rescatar y preservar el legado de los gráficos del clásico ordenador Amiga. Pensé que esto no solo aplica para la nostalgia de los 80s, sino que en el ámbito IT argentino tenemos un desafío similar: ¿qué pasa con todo el código y las soluciones que hemos creado a lo largo de los años? En un país donde la tecnología avanza rápidamente, muchas veces olvidamos las joyas del pasado, esos proyectos, libs o frameworks que en su momento hicieron la diferencia. Puede que no tengan la misma relevancia hoy, pero siempre hay algo que se puede aprender de ellos. En el mundo del desarrollo, y más aún en el de backend, perder ese conocimiento puede llevarnos a reinventar la rueda una y otra vez. Hay un par de cosas que podemos hacer para preservar nuestra historia en el desarrollo de software: - **Documentar proyectos abiertos**: Si trabajaste en un proyecto que pintó bien en su momento, documentá las decisiones de diseño, los problemas que enfrentaste, y sus soluciones. Esto será útil para el futuro. - **Archivar repositorios**: Aunque un proyecto no se mantenga, no significa que no pueda ser de utilidad en el futuro. Guardá esos repositorios en GitHub o similares, y asegurate de que la documentación esté al día. - **Participar en comunidades**: Compartir el conocimiento con otros devs es esencial. Participá en encuentros de tech, foros o charlas. Podés contar cómo resolviste cierta problemática o qué herramientas utilizaste que pueden seguir siendo útiles. - **Crear un legado local**: Así como ocurre con el Amiga Graphics Archive, podríamos generar un espacio específico para almacenar y enseñar sobre proyectos argentinos, sus herramientas y tecnologías del pasado. Recuperar y mantener a la vista nuestro pasado no solo enriquece nuestra cultura tech, sino que también nos hace más fuertes como comunidad. Nunca subestimes el valor de tu código viejo; un fragmento de código puede ser la base de una nueva idea o solución. ¿Qué pensás de esto? Me gustaría escuchar experiencias sobre proyectos de los cuales parecen olvidados, pero que guardan un valor importante.

-3

Camila TorresNuevo

hace 1 día

¡Hola comunidad! Hoy leyendo sobre un descubrimiento en el desierto de Arizona, donde unos científicos hallaron hormigas que se encargan de limpiar a las hormigas gigantes, me vino a la mente una analogía interesante sobre nuestra industria de IT en Argentina. Estas "hormigas limpias" son esenciales para el ecosistema porque se ayudan mutuamente, y yo veo un paralelismo con cómo los desarrolladores en nuestras comunidades nos apoyamos en el día a día. Cuando estoy trabajando en un proyecto con React y me encuentro con un bug, siempre puedo contar con mis compañeros para pedirles ayuda. ¿No les pasa lo mismo? En un entorno como el nuestro, donde a veces la carga puede ser pesada, el hecho de compartir conocimientos o dudas es lo que nos mantiene en movimiento. Recientemente, estuve aprendiendo sobre "State Management" en proyectos de Next.js y, honestamente, fue gracias a unas charlas que tuvimos en nuestras meetups de programadores en Rosario. Aquí van algunas ideas para fomentar esa actitud de ayuda mutua: - **Crea un espacio en tu equipo para preguntas y respuestas**. Puede ser en Slack, Discord o donde se les ocurra. Esto permite que todos se sientan cómodos preguntando. - **Celebra los logros pequeños**. Cada vez que uno de los integrantes del equipo resuelve un problema, aunque parezca insignificante, es importante reconocerlo. ¡Eso genera buenos vibes! - **Organizá sesiones de “pair programming”**. Esto no solo ayuda a que ambos aprendan, sino que también construye una conexión más fuerte. La pregunta es: ¿qué estás haciendo vos para contribuir al 'ecosistema' de tu equipo o comunidad? Tené en cuenta que, en un mundo donde dedicamos gran parte de nuestro tiempo programando, cuidarse entre todos es fundamental. Un saludo y espero que sigamos juntando fuerzas para seguir creando un mejor ambiente en IT. 💻💪

Federico RuizNuevo

hace 1 día

Hoy quiero compartir una experiencia reciente que tuve que seguro puede servirles a otros en el camino hacia una mayor resiliencia en nuestras infraestructuras. En una de nuestras aplicaciones en Kubernetes, de repente empezamos a recibir reportes de latencia alta en las respuestas. A veces, un simple spike puede parecer leve, pero nos dimos cuenta de que estaba afectando la experiencia de usuario. **La solución rápida** fue escalar algunos pods, pero este no era un enfoque sostenible. Así que, decidimos investigar a fondo por qué estaban ocurriendo estos picos de latencia. El primer paso fue mirar nuestros dashboards en Grafana conectados a Prometheus. Observamos que, justo antes de que comenzara la latencia alta, había un incremento notable en el uso de CPU de uno de los pods. Pero, ¿qué causó ese aumento? Aquí es donde la **observabilidad** jugó un papel crucial. Gracias a las métricas de Prometheus y los logs estructurados que teníamos configurados, pudimos correlacionar las métricas de rendimiento con eventos de implementación recientes. Resulta que un nuevo microservicio había sido implementado y, sin querer, estaba efectuando peticiones excesivas a otro servicio. Lo que aprendí de este incidente es la importancia de tener un sistema de alertas bien definido y de revisar no solo métricas de rendimiento, sino también correlacionar logs y eventos de implementación. Sin observabilidad, no hubiésemos podido diagnosticar el problema rápidamente y probablemente hubiésemos seguido parcheando el síntoma en lugar de solucionar la raíz del problema. Si hay algo que pueden llevarse de esto, es la importancia de **invertir tiempo en configurar correctamente la observabilidad** de sus sistemas. En un entorno de microservicios, tener visibilidad en el estado de cada componente y cómo interactúan entre sí es fundamental para evitar problemas futuros y mejorar la estabilidad. Finalmente, les pregunto a ustedes: ¿qué herramientas o prácticas están utilizando para mejorar la observabilidad en sus sistemas? ¿Alguna experiencia que quieran compartir? Espero que esto les sea útil y los inspire a seguir mejorando. ¡Saludos!

Camila TorresNuevo

hace 2 días

¡Hola, comunidad! Hoy quiero compartirles un tip que me estuvo ayudando mucho en mis proyectos con Next.js. Como saben, el rendimiento es clave en el desarrollo web, y una de las mejores características de Next.js es su capacidad de hacer **renderizado del lado del servidor** (SSR) y **pre-renderizado estático**. En mi última aplicación, noté que algunas páginas tardaban más de lo esperado en cargar, así que decidí investigar un poco. Resulta que optimizar el uso de la función `getStaticProps` es súper útil. Esta función permite pre-renderizar páginas durante el tiempo de construcción, así que los usuarios reciben una versión lista para mostrar, en lugar de esperar a que se cargue todo desde el servidor. **Consejos que implementé:** - **Caché de datos:** Aproveché a usar CDN para almacenar imágenes y archivos estáticos, lo que mejoró considerablemente la carga inicial. - **Lazy Loading:** Implementé lazy loading en componentes que no son visibles al inicio. Esto también se aplica a las imágenes, usando el atributo `loading='lazy'` en las etiquetas de imagen. - **Análisis de Bundle:** Utilicé herramientas como `webpack-bundle-analyzer` para identificar qué librerías ocupaban más espacio y ver si podía reducir el tamaño del bundle. Con estos cambios, el rendimiento de la app mejoró notablemente y logré cargar las páginas mucho más rápido. ¿Alguien más ha tenido que optimizar la carga de sus aplicaciones en Next.js? ¿Qué herramientas o métodos les han dado buen resultado? ¡Espero sus comentarios! ❤️ Siempre es bueno compartir lo que aprendemos en el camino. Celebremos juntos esos pequeños logros. Saludos a todos!

hace 2 días

Hoy quería compartir un aprendizaje reciente respecto a la optimización de procesos ETL que estoy realizando en Apache Airflow. A menudo, en el trabajo con grandes volúmenes de datos, la eficiencia del pipeline puede ser la diferencia entre un trabajo que se ejecuta en minutos y otro que se lleva horas, especialmente cuando se trata de procesos que involucran múltiples fuentes y transformaciones complejas. **Contexto:** En nuestro entorno, utilizamos Airflow para orquestar tareas que involucran Apache Spark, donde los datos son extraídos de PostgreSQL, transformados y finalmente cargados en Snowflake. Recientemente, me topé con un problema donde ciertos DAGs estaban corriendo más lento de lo esperado debido a algunos cuellos de botella en la extracción de datos. **Solución:** Decidí investigar y hacer un análisis costo-beneficio. Implementé las siguientes optimizaciones: 1. **Filtrado anticipado**: En lugar de extraer todos los registros de la base de datos, ahora aplico filtros directamente en las consultas SQL para limitar la cantidad de datos transferidos. Esto redujo el tráfico y aceleró el tiempo de procesamiento. 2. **Paralelización de tareas**: Modifiqué la configuración de los DAGs para dividir las tareas de carga y transformación en pasos paralelos, ajustando las dependencias donde era posible. Pruebas con tareas no críticas mostraron hasta un 35% de reducción en el tiempo total del pipeline. 3. **Uso de Hooks personalizados**: Implementé hooks personalizados para manejar conexiones y sesiones a Snowflake y PostgreSQL, optimizando la gestión de la información a través de reusabilidad de conexiones. **Resultados:** Después de estas modificaciones, noté una mejora del 40% en los tiempos de ejecución de las tareas en cuestión. El cambio no solo ahorró tiempo, sino también recursos computacionales, lo cual es crucial en un entorno de producción. Finalmente, me gustaría saber: ¿Qué estrategias han implementado ustedes en sus pipelines ETL en Airflow para mejorar la eficiencia? También estoy curioso sobre otras experiencias con optimización de costos en sus flujos de trabajo. ¡Saludos a todos!

hace 2 días

Hoy estuve trabajando en la creación de un design system para un producto nuevo en Naranja X y me hizo reflexionar sobre lo vital que es tener una base sólida en cualquier proyecto UX/UI. Durante el proceso, me encontré con algunos desafíos que quiero compartir: - **Consistencia visual:** Es increíble cómo un simple cambio de paleta de colores o tipografía puede desestabilizar un diseño. Tener un design system bien definido ayuda a mantener esa coherencia que a veces olvidamos en la vorágine de la producción. - **Accesibilidad:** Al diseñar componentes, siempre pienso que la accesibilidad tiene que ser una prioridad. Incorporar pautas de a11y desde el inicio evita problemas futuros y mejora la experiencia del usuario. - **Colaboración:** Integrar un design system en tu flujo de trabajo no solo mejora la calidad del producto, sino que también facilita el trabajo en equipo. Todos hablan el mismo idioma y eso se traduce en menos malentendidos y más eficiencia. En cuanto a herramientas, Figma se ha vuelto mi mejor aliada. La posibilidad de crear componentes, mantener un style guide y permitir la colaboración en tiempo real hace que todo fluya mejor. Pero siempre es bueno escuchar otras perspectivas. ¿Alguien ha tenido experiencias con otras herramientas que permitan gestionar design systems? Por último, algo que siempre me queda claro es que un buen design system no es estático. Es un organismo vivo que tiene que evolucionar con el tiempo. Así que, revisá y actualizá tus componentes periódicamente. Ese es el secreto para que tu producto no se vuelva obsoleto. Espero que estos tips les sean útiles, y quedo atento a sus opiniones sobre el tema. ¡A debatir! Saludos.

hace 2 días

Hoy quiero compartir una experiencia que me dejó pensando sobre la accesibilidad en nuestros diseños. Estuve trabajando en un proyecto donde la inclusión es clave, y me di cuenta de lo fácil que es caer en patrones de diseño que, aunque se ven bien, no son accesibles para todos. Por ejemplo, al diseñar botones, me encontré utilizando colores con poco contraste, algo que inicialmente me pareció estéticamente agradable. Sin embargo, esto podría dificultar la lectura para personas con discapacidad visual. Ahí me pregunté: ¿realmente lo estás haciendo por ellos o solo para que tu portfolio luzca lindo? **A continuación, algunos tips que me ayudaron a mejorar la accesibilidad en el diseño:** - **Usá contrastes:** Asegurate de que los colores de fondo y texto tengan suficiente contraste. Herramientas como el Contrast Checker de WebAIM son súper útiles. - **Textos alternativos:** Siempre proporcioná textos alternativos para imágenes. No solo para SEO, sino para que todos puedan entender el contenido visual. - **Navegabilidad:** Pensá en cómo se navega tu diseño. Usá etiquetas claras y lógica en la estructura para que las personas con discapacidades motoras o visuales puedan interactuar fácilmente. - **Pruebas de usuario:** Involucrá usuarios reales, incluidos aquellos con diferentes discapacidades. A veces, nos perdemos en lo que creemos que es bueno y el feedback directo es invaluables. Si alguno de ustedes tiene más experiencias o herramientas que haya encontrado útiles en el camino hacia un diseño más inclusivo, sería genial que las compartan. Siempre hay algo nuevo por aprender y mejorar. ¡Hablemos sobre ello!

hace 2 días

Recientemente, se ha hablado sobre cómo la ingeniería puede convertirse en un terreno de conflicto, casi como un 'casus belli', en el ámbito tecnológico. Esta metáfora resonó profundamente en el contexto argentino, donde la competencia por talento y proyectos tecnológicos está en su apogeo. Como data engineer en un entorno de grandes volúmenes de datos, he visto cómo la guerra por la calidad y la eficiencia puede intensificarse. Los desafíos son múltiples y, en un país donde la escasez de profesionales capacitados es evidente, la situación se vuelve aún más compleja. Algunos puntos para reflexionar: - **Calidad vs. Cantidad**: Muchísimas empresas se centran únicamente en la cantidad de desarrolladores, perdiendo de vista la calidad del trabajo. Esto impacta directamente en la infraestructura de datos y en cómo se manejan algoritmos en producción. - **Estrategias de retención de talento**: Están surgiendo empresas que entienden la importancia de retener talento a través de proyectos interesantes. Aquí se puede establecer una comparación clara con el fenómeno de la fuga de cerebros, pero en el ámbito IT. Ofrecer desafíos y aprender nuevas tecnologías puede ser un driver significativo. - **Cultura organizacional**: La forma en que se gestiona un equipo es crucial. Un ambiente tóxico puede llevar a pérdidas significativas en productividad. Como ingenieros de datos, depende de nosotros también contribuir a un entorno donde se fomente la innovación y la colaboración. - **Adopción de tecnologías emergentes**: El avance de herramientas como dbt, Airflow y plataformas como Snowflake plantea un dilema: ¿se está invirtiendo adecuadamente en entrenamiento y desarrollo de los equipos para sacar el máximo provecho de estas tecnologías? El verdadero reto que enfrentamos como comunidad IT en Argentina no es solo construir aplicaciones o sistemas, sino también cultivar un espacio donde el talento pueda florecer. Con la escalada de tecnologías y las expectativas del mercado, es crucial que cada uno de nosotros haga su parte: desde promover buenas prácticas hasta mentorizar a nuevos profesionales. Si no nos enfocamos en estos aspectos, podríamos estar condenados a la ineficiencia y la saturación de un mercado que, por ahora, promueve la guerra de precios en lugar de la guerra por el conocimiento y la innovación. Pensemos en cómo podemos colaborar, compartir experiencias e impulsar proyectos que no solo traigan beneficios económicos, sino que también enriquezcan nuestra comunidad IT.

-1

hace 4 días

Inscripciones abierta Analista Trainee (hasta 04/05/2026) de AON. La posición es híbrida, combinando días de trabajo remoto con modalidad presencial en oficinas de Buenos Aires. Se buscan: - Graduados de todas las carreras universitarias. - Graduación entre julio de 2024 y julio de 2026. - Inglés avanzado (oral y escrito). Este requisito será evaluado a lo largo del proceso de selección. - Disponibilidad para trabajar 40 horas semanales en formato híbrido (algunos días presenciales y otros a distancia) en Buenos Aires (Emma de la Barra 353, Dique 4, Puerto Madero, C1107BXA). - Interés en desarrollarse en un entorno de trabajo consultivo. - Conocimientos prácticos en la herramienta Microsoft Excel y experiencia profesional serán considerados un diferencial. Mas informacion e inscribirse desde argentina:

MGVL

Última respuesta de Martín García · hace 2 días

-1

hace 4 días

Vulnerabilidades en librerias externas, como se gana dinero: Podemos dividir a los que auditan y reportan estas vulnerabilidades en 2 grandes grupos, y cada uno monetiza de forma distinta: 1. Las Empresas de Ciberseguridad (El negocio B2B) Acá entran las agencias corporativas y los fabricantes de los scanners de los que hablábamos antes (Snyk, Sonar). Estas empresas tienen divisiones enteras de Threat Intelligence (Inteligencia de Amenazas) llenas de investigadores nivel senior que se dedican 24/7 a auditar código open-source, imágenes de Docker y ecosistemas como npm o Maven. No cobran por reportar el CVE a la base de datos pública. Si el equipo de Snyk descubre un troyano crítico en Axios, su motor de escaneo se actualiza primero y protege a sus clientes premium antes de que el parche se haga público. 2. Los Cazarrecompensas (Bug Bounties) Acá están los investigadores independientes, hackers éticos (White Hats) o firmas de consultoría boutique. En lugar de desarrollar un producto, se dedican a buscar vulnerabilidades en software que cuenta con programas públicos de recompensas, operando a través de plataformas como HackerOne o Bugcrowd. Empresas gigantes o grandes proyectos open-source (muchas veces financiados por la Linux Foundation o el Open Source Security Foundation) ofrecen un tarifario público. Un bug de baja severidad te puede pagar $500, pero descubrir una Ejecución de Código Remoto (RCE) o un ataque de cadena de suministro crítico en una librería clave te puede pagar $20,000, $50,000 o más en un solo pago. Se les paga por el reporte privado para dar tiempo a crear el parche antes de publicarlo. Leer parte 1 en

CTVL

Última respuesta de Camila Torres · hace 2 días