DEV Community: Lara Díaz

GOTTA GO FAST!

Lara Díaz — Thu, 28 Nov 2024 19:55:16 +0000

Allá por el año 2005, uno de mis profes de informática nos dijo que la mayoría de los estudiantes abandonan una página si demoraba más de 12 segundos en cargarse. Esto se quedó conmigo por mucho tiempo, pero le empecé a prestar más atención en los últimos 2 años, desde que di la charla de Web Vitals en la WebConf.

Hoy en día, las personas tienen una capacidad de atención extremadamente corta donde necesitamos el acceso a contenido de forma rápida y constante. No solo por la cantidad de contenido sino también por cómo avanzó la tecnología. Debido a esto, los desarrolladores web deben obsesionarse con el rendimiento de la carga inicial de la página. Porque, spoiler alert: cuando tu sitio es lento, tus usuarios se van.

Repasemos un cachito antes de seguir, por si no fueron a la WebConf:
Google usa las métricas de Core Web Vitals para determinar el ranking de tu sitio.

¿Qué son los Core Web Vitals?

Son métricas que miden la experiencia del usuario en términos de velocidad, interactividad y estabilidad visual. Por ejemplo:

LCP (Largest Contentful Paint): Mide cuánto tarda en aparecer lo más importante de la página (como una imagen grande o un título).
FID (First Input Delay): Mide cuánto tarda la página en responder al primer clic o interacción del usuario.
CLS (Cumulative Layout Shift): Mide si los elementos de la página se mueven inesperadamente mientras carga.

Por qué importa el rendimiento

Ahora, ¿por qué debería importarte el rendimiento en el frontend? Bueno, te doy algunas razones rápidas:

Los usuarios odian esperar. Si tu página tarda más de 3 segundos en cargar, más del 50% de las personas se van.
Google también odia la lentitud. Las métricas de Web Vitals son clave para el SEO.
Afecta tu negocio. Un retraso en la carga de la app puede reducir las ventas.

¿Te convencí? Bien. Sigamos.

Optimización de recursos

El primer paso es reducir el tiempo de carga de los recursos.

Imágenes

¿Sabías que las imágenes suelen ser el recurso más pesado en una página? Usa formatos modernos como WebP para ahorrar espacio sin perder calidad, y no cargues todas las imágenes de golpe: aplica lazy loading para que se descarguen solo cuando el usuario las necesita.

Fuentes

¿Te encantan las fuentes personalizadas? A mí también. Pero pueden ser un problema. Limita la cantidad de fuentes que usas, precarga las esenciales, y considera usar fuentes del sistema si es posible.

Videos

Si tienes videos en tu sitio, asegúrate de optimizarlos. Usa placeholders en lugar de cargarlos inmediatamente y, si se puede, mejor incrustarlos desde servicios externos como YouTube.

Técnicas de carga eficiente

Aquí es donde las cosas se ponen interesantes. Hay un montón de formas de mejorar cómo y cuándo se cargan los recursos de tu página.

Supongamos que tenemos el siguiente ejemplo que queremos optimizar:

Code Splitting: divide tu JavaScript en partes más pequeñas y carga solo lo necesario. Por ejemplo, usa un loader que importe los componentes de forma asincrónica, permitiendo que se carguen solo cuando se accede a la ruta.

Lazy Loading: aplica esta técnica a todo lo que puedas: imágenes, scripts, componentes.

Prefetching: carga recursos que el usuario podría necesitar más adelante, antes de que los pida.

Reducción de JavaScript

JavaScript es genial, pero demasiado puede ser un problema. Tree Shaking elimina del código final las partes que no se usan, como funciones o módulos. Utiliza herramientas como Webpack o Rollup para analizar el código y detectar automáticamente lo que realmente se necesita, haciendo que las aplicaciones sean más ligeras y rápidas.
Puede que tu framework ya esté haciendo esto por ti si usas Next o Angular Universal.

Supongamos que tenemos este archivo products.js en la carpeta Utils

Pero en el archivo cart.js solo llamamos dos funciones del archivo products.js

Lo que se buildeara sera solo el codigo utilizado, descartando las funciones que no estamos llamando en cart.js

Caché

Usar el caché del navegador es como darle al usuario un atajo. Configura tus recursos estáticos para que no se descarguen cada vez que alguien visite tu página. Puedes usar el almacenamiento local del navegador (localStorage) o el almacenamiento en memoria para guardar datos como productos, detalles del carrito o páginas cargadas previamente.

SSR, SSG y CSR

Mientras buscamos diversas formas de optimizar el rendimiento, debemos contemplar también tres estrategias: SSR (Server-Side Rendering), SSG (Static Site Generation) y CSR (Client-Side Rendering).

SSR: el servidor genera el HTML completo en el momento en que el usuario visita la página.
Es como un chef que cocina todo a último momento. Si hay muchas órdenes, se puede saturar.
SSG: genera las páginas de HTML durante el tiempo de compilación.
Es como si preparara todo por adelantado para tenerlo listo en cuanto se lo pidan.
CSR: el servidor envía un documento HTML vacío (o casi vacío) al navegador, junto con un montón de JavaScript, que construye la interfaz completa directamente en el navegador.
Es como si te dieran los ingredientes y una receta, y te dijeran: "cocínalo tú mismo".

¿Cuándo usar cada uno?

SSR:

Cuando necesitas datos dinámicos que cambian por usuario (carritos de compra, dashboards, resultados de búsqueda).
Cuando el SEO es fundamental para contenido cambiante.

SSG:

Para sitios con contenido que cambia poco o de forma predecible (blogs, landing pages, documentación), aprovechando la caché para entregar contenido extremadamente rápido.

CSR:

Cuando necesitas una experiencia interactiva, como en dashboards o aplicaciones complejas.
Nota: puede necesitar complementos para mejorar el SEO o reducir el tiempo de carga inicial.

Optimizando llamadas a la API

No solo mejoramos el rendimiento y la interacción desde el front, también debemos prestar atención a cómo nos comunicamos con el back. Optimizar la forma en la que hacemos requests es esencial para mejorar la performance, ya que podemos crear cuellos de botella, incrementar la demora de respuesta y sobrecargar el servidor.

Qué podemos hacer:

Batching: combinar varias solicitudes en una sola. En vez de mandar múltiples requests, agrúpalas en una sola llamada.

Desde el front podemos hacer:

Y desde el back si tenemos acceso y podemos modificarlo:

Caching: guardar datos comunes en memoria/local (como mencionamos antes, pero en este caso cacheamos data en vez de assets).
Lazy loading: cargar datos solo cuando son necesarios, igual que con las imágenes.

Herramientas para medir y mejorar

Ahora que ya sabes qué hacer, necesitas herramientas para saber si estás haciendo las cosas bien. Mis favoritas:

Chrome DevTools: una herramienta esencial para identificar cuellos de botella en el rendimiento de tu sitio. Con su pestaña Performance, puedes analizar qué tareas están tardando más de lo necesario, como la ejecución de scripts o el renderizado de elementos.
Además, Throttling te permite simular condiciones reales como conexiones lentas o dispositivos menos potentes, ideal para diagnosticar problemas en escenarios del mundo real.
Finalmente, Lighthouse no solo te da un puntaje de rendimiento, sino que también ofrece recomendaciones claras y accionables para mejorar métricas clave como LCP, FID y CLS.
WebPageTest: para analizar el tiempo de carga desde diferentes ubicaciones.
UnLighthouse: una herramienta de código abierto que ejecuta informes de Lighthouse en todas las páginas de tu sitio web de manera paralela.

Conclusión

El rendimiento en el frontend no es solo un tema técnico. Si tu sitio no es rápido, pierdes usuarios, dinero y oportunidades. Pero lo bueno es que con pequeños cambios puedes marcar una gran diferencia.

Mi consejo final: no intentes hacer todo a la vez. Empieza con un cambio. Optimiza esas imágenes pesadas o elimina scripts innecesarios.

Optimizando tu día laboral: creando Comandos.

Lara Díaz — Wed, 15 May 2024 16:33:06 +0000

Cuando comenzamos en un proyecto, muchas veces tenemos que levantar varios repos, Docker, bases de datos, etc. y se vuelve bastante tedioso andar escribiendo y abriendo tabs en la terminal.

No sé ustedes, pero más de una vez me quedé dormida el día que tenía que dar una demo y ya se pueden imaginar, tartamudeando medio dormida en inglés mientras trataba de setear todo para poder compartir pantalla.

Y casi como Pepe grillo, lo tenía a Santi diciéndome: “Si te hubieses configurado los aliases, en dos segundos tendrías todo listo.”

Antes de poder explicarles como crear sus propios comandos hay que empezar por el principio y ver algunos conceptos.

DISCLAIMER ESTA CHARLA ESTÁ ORIENTADA A MAC, LINUX O WSL. SORRY WINDOWS

¿Qué es un SHELL?

Un sistema operativo hace uso de programas que se encargan de interpretar los comandos que introduce el usuario en una terminal y realizan las acciones en respuesta. Estos programas se denominan SHELL (Intérprete de Comandos).   
Existen varios tipos, pero los más utilizados son:

Bsh: bourne SHELL
Bash: bourne again SHELL
Zsh: Z SHELL

Los SHELL admiten comandos que pueden ser archivos o funciones ejecutables, por lo que cada usuario puede construir archivos combinando comandos base de Linux, paquetes de npm o ciertas estructuras especiales que le permita ser ejecutados desde una terminal.

Voy a asumir que usan la terminal y conocen algunos de los comandos básicos como ls para listar archivos y carpetas, cd para movernos entre los directorios y rm para borrar archivos o directorios.

PROGRAMACIÓN DEL SHELL

El SHELL puede aceptar no solo órdenes simples, desde la línea de comandos, sino también secuencia de órdenes, grupo de órdenes y órdenes condicionales.
Piensen que un SHELL es como Node, pero en vez de interpretar JavaScript interpreta el lenguaje de comandos.

Permite construir programas y comandos llamados SHELL SCRIPTS que nos dejan automatizar diversas tareas.

Yo uso como SHELL ZSH, que tiene un archivo para configurar que se llama .zshrc. ¿Qué tengo acá, aparte de los comandos? Personal tokens de GitHub, credenciales de mi trabajo, y alguna que otra configuración para el theme de la terminal.

Lo más importante para empezar a escribir comandos es que creemos un archivo, en este caso se va a llamar .ZSH_ALIASES en la misma carpeta donde tenemos el .zshrc que suele estar en la carpeta user. ¿Por qué? Como lo tenemos que llamar en ese archivo, entonces lo vamos a importar escribiendo:

¿Y ahora podemos empezar a escribir, no? Acá me topé con un par de cosas:

En mi proyecto para abrir una de las apps dependo de otra para loguearme. ¿Cómo hago para que se levanten en simultáneo usando la misma tab?
Tenemos distintas versiones de node en cada repo y lo tengo que setear antes de correrlo.
Tengo que levantar Docker porque si no, no tengo data.
¿Cómo quiero que se abra? ¿Todo en una misma tab o quiero que cada proceso se abra en una tab distinta?

Mientras yo me hacía estas preguntas, una vocecita me decía: “Vos no usas todos los containers de Docker, si necesitas ver los logs de uno solo ¿cómo haces?”

Y para que no anden googleando o discutan con Santi en Twitter (o X, ya no tengo idea), 3 horas para encontrar la respuesta, se las doy yo:

Instalar concurrently para poder correr comandos al mismo tiempo compartiendo la misma tab. - ttab - Abre una nueva tab en la terminal (se recomienda en macOS instalarlo con brew).

Ya contenta de que tenía todo listo para arrancar, escribí mi primera función ^^

Navegamos hasta la carpeta, nvm para setear la versión de node, npx para que instale concurrently si no lo encuentra, -k para que corte todos los procesos cuando hacemos ctrl+c y yarn para que levante el proyecto (Nosotros necesitamos levantar dos en simultáneo)

Todo muy lindo, muy lindo hasta que voy a la terminal y veo:

Revisé el archivo, el import, todo y no daba con la tecla de porque no andaba.

Quiero que quede claro que esto fue hecho a propósito para el ejemplo:

Resulta que no le gustan los espacios, así que NO DEJAR ESPACIOS ENTRE EL = Y EL COMANDO DEL ALIAS (Esto no estaba en Google).

Sigamos, con respecto a lo de Docker, se solucionó de la siguiente forma:

Esa -d significa detach. Levanta el container y lo corre en segundo plano dejando que el segundo conteiner que no tiene el -D corra en la ventana de la terminal y podamos leer los logs (que en este caso es lo que me interesaba)

Ya casi terminamos, lo prometo. Ahora como hago para correrlo todo de un solo comando?

ttab -a iTerm2 es un comando predeterminado de ttab para los que tienen iTerm2.

El nombre de la función o funciones que declaramos antes, en este caso la de Docker y la del proyecto que son las que uso día a día. Y ahora sí corro el comando frontendUp, que me levanta en dos tabs distintas cada comando (en una docker y en otra las dos apps)

En conclusión, si bien me llevó un par de días de investigación, es una buena forma de optimizar el comienzo del día laboral y de paso renegamos con otra cosa que no es JS.

Muchas gracias y vuelva prontos.

Laburanding: como trabajar para afuera

Lara Díaz — Thu, 24 Feb 2022 15:08:15 +0000

Bueno la idea de esta charla surge un poco de mi experiencia trabajando remoto con una empresa de afuera y de comentarios/consejos que fueron saliendo de dailys y charlas con amigos/colegas.
Les voy a hablar de mi experiencia, lo que yo hice y lo que a mi me sirvio, no lo tomen como que es palabra santa 😅
Mi carrera en It comienza en febrero 2020 en una start up de aca de cba donde solo fui a la oficina dos semanas antes de encerrarme en casa, donde me pasé año y medio corriendo, durmiendo poco y ganándome un burn out por no saber parar. A esto sumemosle que me largue a dar clases de programación (gracias docta por el aguante) y conseguí mi primer laburo para USA.

👉Ahora vamos por partes diría Jack:

Como con tan poca experiencia conseguí trabajar para USA?
Esto se dio gracias a una sumatoria de cosas:

Manija -> Tengo la “suerte” que herede la locura de estudiar y sentarme por horas a investigar y leer de mi vieja y eso me permitió aprender bastante en poco tiempo.
Comunidad/amigos: me metí en comunidad donde hice proyectos y fui aprendiendo de pares. Y mis amigos que también me pasaban cosas, me incentivaron y recomendaron para encontrar trabajo. OJO -> esto no quiere decir que solo porque te recomienden, pum encontras el remoto.
Estudio y práctica. A pesar de ya estar trabajando seguir haciendo proyectos propios, me metí en hackatones y el enseñar un curso de programacion me permitió retomar conceptos básicos de javascript y vocabulario técnico que a la hora de las entrevistas es clave( desde mi punto de vista)

Hablemos de trabajo remoto

El trabajo remoto es cada vez más común ya que cada vez más personas quieren tener un horario de trabajo flexible, y “gracias” a la pandemia más empresas se están sumando a esta modalidad.

PROS Y CONTRAS DEL REMOTO

✅ Los horarios y lugares de trabajo flexibles suelen aumentar la productividad y el rendimiento.
✅ Te permite viajar y trabajar desde cualquier parte del mundo y convertirte en un nómada digital, creando tu propio horario de trabajo.
✅ No tenes que viajar al trabajo todos los días y ahorras no solo plata sino también tiempo
❌Mala conexión de internet, muchos ruidos ambiente, una compu no tan buena y sin servicio técnico por parte de la empresa te pueden arruinar el día.
❌Al no tener horarios y un espacio dedicado para trabajar pueden hacer que seamos más propensos que otros a procrastinar, a distraerse fácilmente y no aprovechar el tiempo de manera eficiente

AHORA A LO QUE VINIERON

Lo primero es tener claro qué queremos hacer y en base a eso armar un plan. En mi caso, el remoto es porque quiero viajar y seguir trabajando de lo que me gusta.
Obviamente la suerte juega un papel importante en toda búsqueda, pero estos puntos pueden ayudar a mostrar tus habilidades a los posibles empleadores cuando no tienes tanta experiencia.

Conoce tus puntos débiles

Soy pésima en algoritmos y en varias entrevistas me tocó hacer un challenge técnico donde tenía problemas lógicos, de algoritmos, etc. Si sabemos dónde fallamos podemos mejorarlo.

Aca les dejo algunas páginas donde pueden practicar 😉

Codewars

Codingame

Codility

Repasa conceptos

Si bien sabemos que no vamos día a día recitando conceptos de programación, tener en claro las definiciones nos pueden ayudar muchísimo. No necesariamente tiene que ser con vocabulario ultra técnico pero mientras puedas expresarlo de manera simple o explicárselo a otra persona es suficiente.

Developer Mozilla

JS Tips

Lenguaje JS

Refactoring Guru

Date a conocer

Para mi lo mejor es tener un github donde tengamos proyectos propios copados donde aprendimos y renegamos para mostrar en entrevistas y contar estas anécdotas.

Aparte permite que otros devs de las empresas en donde postulamos puedan ver nuestro código de antemano y muestra nuestro proceso de aprendizaje.

👉 Podés encontrar ideas acá:

Codementor

50 React Projects

En LinkedIn podés crear tu propio perfil en donde pones tu historial laboral, destaques tus habilidades y resumas tus logros y experiencias laborales anteriores.

Una buena forma de destacarse es compartir cualquier artículo que hayas escrito y otros contenidos interesantes e informativos. Participar en Discord junto a otras personas y comunidades también es una buena forma de hacer networking.

Contribuir al código abierto

Al principio cuando no tenemos tanta experiencia puede resultar difícil o incluso que nos de vergüenza meternos en un repositorio de otra persona, pero esto es algo que a muchos recruiters les llama la atención.
Podemos empezar haciendo pequeñas contribuciones, como corregir errores gramaticales y de tipeo o crear/traducir documentación para proyectos que carezcan de ella.
Esto demuestra que sabemos comunicarnos bien y colaborar con otros desarrolladores de forma remota y asíncrona para resolver un problema. Y todo eso es público.

👉 Podés encontrar una guia de como empezar acá:

Github para Open Source

Lara Díaz ・ Oct 15 '20

Gana experiencia trabajando de forma remota

Esto no es cien por ciento necesario pero hacer trabajos freelance ayuda muchísimo a la hora de encontrar trabajo estable como contractor, en comparación con alguien que no tenga esa experiencia y conocimientos.

Workana

Upwork

Freelancer

¿Dónde encontrar empresas que contraten remoto?

Yo siempre le pregunto a mis amigos si en las empresas donde trabajan están contratando y que experiencia tuvieron y con qué stack están trabajando.
También probé otras páginas donde encontrar varias opciones en distintos países, no solo USA.

RemoteOK

We Work Remotly

Angel

Near

Indeed

Todo este post, lo podes encontrar en forma de charla acá:

BeerJS Cba 61

Asi que, si estas recien empezando y queres ganar experiencia o queres hacer el salto a remoto, animate y espero te sirva el post 😁

Inglés en entrevistas? Mirá 👇🏻

Lara Díaz — Fri, 29 Oct 2021 16:49:36 +0000

Este es un pequeño post para entender qué significan los niveles de inglés que aparecen en las búsquedas de IT. Cuando se abre un nuevo puesto de trabajo y quieren contratar a un nuevo desarrollador, el primer filtro es el idioma (inglés). El nivel de inglés que enseñan las escuelas no es suficiente a veces; por lo que es difícil encontrar a alguien que tenga un buen nivel de inglés y habilidades técnicas que no haya ido a una academia/profe particular.

Vamos por partes

El CFRL* es una guía estándar que sirve para medir la comprensión que tiene una persona, de un determinado idioma. Se distinguen en:
Interpretar
Hablar
Escribir

Esta guía se divide en 7 niveles:

Principiante: Se supone que no hay estudios previos de inglés.

A1 (Elemental): Puedes desenvolverte en actividades cotidianas muy limitadas.

A2 (Intermedio bajo): Puedes desenvolverte en actividades cotidianas.Todavía no tienes suficiente conocimiento para enfrentarte solo a algunos problemas, pero puedes manejar interacciones simples.

B1(Intermedio): Puedes hacer un uso eficaz e independiente de la lengua en situaciones familiares. Todavía hay muchos errores y carencias de vocabulario, pero puedes comunicar y comprender mensajes generales en la mayoría de los contextos.

B2(Intermedio Superior): Puedes enfrentarte a tareas sencillas. Te desenvuelves con bastante facilidad en situaciones bastante complejas y exigentes. Hay carencias de vocabulario en situaciones complejas, pero la comunicación se restablece con facilidad.

C1 (Avanzado): Puedes ocuparte de tareas de trabajo complejas. Tienes un excelente dominio del idioma, con fluidez y precisión constantes y bien organizado. Te enfrentas bien a situaciones exigentes y complejas.

C2 (Competencia): Puedes utilizar el idioma con fluidez, precisión y adecuación. Has alcanzado un nivel excepcional de fluidez que se corresponde con el de un hablante nativo.

Así que, si estás empezando tu carrera de desarrollador, o si tienes un tiempo libre, ¡aprende inglés! Espero te sirva el post 😁

HACKTOBERFEST 2022

Lara Díaz — Tue, 05 Oct 2021 14:23:41 +0000

Comienza octubre y lo único que vas a escuchar es “Hacktoberfest”,pero...

¿Qué es Hacktoberfest?

Es un evento anual de un mes durante octubre organizado por Digital Ocean por octavo año consecutivo, que anima a los desarrolladores de cualquier seniority a participar en proyectos de código abierto (Open Source).

Digital Ocean fomenta la participación de la comunidad, para que la misma contribuya mediante Pull Requests, participando en eventos y donando a proyectos Open Source.

¿Qué es Open Source?

Es todo código fuente que se pone a disposición del público para su posible modificación y redistribución.
Los proyectos Open Source que se alojan en repositorios públicos, se benefician de las contribuciones realizadas por la comunidad de desarrolladores en general y suelen gestionarse a través de Github.

Si queres conocerlo en detalle, podes ver este vídeo del evento que hicimos con CoDeAr, en el que charlamos del Hacktoberfest 2020 y algunos proyectos Open Source.

¿Cómo participar?

🔹 Inscribite en Hacktoberfest

Podes ver tu progreso de PRs desde tu perfil

🔹 Haz al menos cuatro pull requests (PRs) antes del 31 de octubre en cualquier repositorio/proyecto participante alojado en GitHub.

Podes ver en este post como hacer tu primer PR 😄

Github para Open Source

Lara Díaz ・ Oct 15 '20

🔹 Tus PRs contarán para tu participación en el evento si están en un repositorio con el hashtag(#) hacktoberfest y una vez que hayan sido mergeados, aprobados por un mantenedor, o etiquetados como aceptados.

El objetivo es contribuir de manera responsable y que se eviten
shit pull-requests.

Una vez aprobados todos los PRs tenes la posibilidad de elegir entre dos premios: Una remera de edición limitada o que se plante un árbol en tu nombre.

La remera del 2020

¡¡Feliz contribución!! 👩‍💻👩‍💻

Intro Git and github 💻

Lara Díaz — Tue, 13 Jul 2021 21:23:45 +0000

¿Qué es git y github?

Git es un sistema de control de versiones distribuido que utilizan los desarrolladores de software que contribuyen a un mismo proyecto o software. Básicamente ayuda a los usuarios a rastrear los diferentes cambios realizados en el software por diferentes usuarios.

Github es una plataforma que proporciona alojamiento y control de versiones para su código y cualquiera puede colaborar en cualquier proyecto en todo el mundo.

Cómo empezar a usar Github

Lo primero que tenemos que hacer es configurar el entorno, por lo que necesitamos descargar git. Para cualquier sistema operativo podemos descargarlo aqui

Una vez que hayamos instalado correctamente git, podemos abrir la terminal y escribir el siguiente comando para comprobarlo.

Después de esto podemos ir al sitio web de Github y crear una cuenta si no tenemos.

La cuenta se verá similar a algo como esto:

Configurar git con nombre de usuario y correo electrónico.

Ahora que tenemos Git en el sistema, queremos personalizar el entorno de Git. Sólo es necesario hacer estas cosas una vez; se mantendrán entre actualizaciones. También podemos cambiarlas en cualquier momento volviendo a ejecutar los comandos correspondientes.

Lo primero que debemos hacer cuando instalamos Git es establecer nuestro nombre de usuario y dirección de correo electrónico. Esto es importante porque las confirmaciones de cambios (commits) en Git usan esta información, y es introducida en cada commit que hagamos:

Abrir un terminal/shell:

Si queremos comprobar la configuración, podemos usar el comando git config --list para listar todas las propiedades que Git ha configurado:

Listo! Ya tenes github configurado!

Hay ciertos pasos que debemos seguir para empezar a contribuir en tu trabajo, proyectos propios u Open Source:

Creación de un repositorio.
Fork de un repositorio.
Clone de un repositorio.
Creando commits.
Push código.
Creando una rama(branch).
Creando issues.
Crear un pull request.
Actualizando el contenido del repo.

Creación de un repositorio.

Un repositorio es una carpeta única que contiene los archivos necesarios para el proyecto, podemos decir que es un nombre alternativo para directorio. Para crear un repositorio podemos ver la esquina superior derecha de tu ventana donde tenemos una opción para crear repositorio como se muestra en la imagen de abajo:

Una vez que hayamos hecho click, tendremos que ingresar información sobre el repositorio, como su nombre, si queremos incluir el archivo Readme (archivo de nuestro repositorio en donde podríamos contarle a la comunidad de GitHub de que trata nuestro proyecto.), o incluir algún archivo, etc.

Otra forma de hacerlo es con Git Init

Este comando se usa para crear un nuevo repositorio en Git. Nos crea un repositorio de manera local y lo hará en la carpeta donde estamos posicionados o se le puede pasar [nombre_de_la_carpeta] y creará la carpeta con ese nombre.

Fork de un repositorio.

Un fork es un clon del repo en github y que funciona como un branch del original y es la forma principal por la cual alguien puede proponer cambios a un repositorio que no creo.

Si queremos contribuir en algún proyecto de otra persona, el primer paso es hacer un fork del proyecto para crear una copia de los archivos de ese proyecto en nuestra cuenta de github.

Clone de un repositorio.

Para poder trabajar y modificar un proyecto, el primer paso es descargar los archivos en su PC para ejecutarlos. Este proceso se conoce como clonación de un repo. Debemos abrir la terminal, posicionarnos en la carpeta donde queremos descargar los archivos (Ej: desktop) y ejecutar el siguiente comando:

Hecho esto, tendremos una copia del proyecto en nuestra PC.

Creando commits.

El comando "commit" guardará todos los cambio hechos en la zona de montaje o área de preparación (staging area), junto con una breve descripción del usuario, en un "commit" al repositorio local.

Para agregar el o los archivos al Staging Area vamos a usar el comando add:

Ahora en verde nos indica que tenemos un archivo o mas listos para hacer un commit en nuestro repositorio, hasta que no hagamos un commit nuestros archivos permanecerán en “el limbo” en el estado Ready justo antes de enviar nuestro archivo a nuestros repositorio.

Push código.

Nuestro repositorio local ya tiene nuestros cambios, ahora si queremos enviarlos a nuestro repositorio remoto (ya sea un fork, clone o propio), vamos a usar un comando llamado git push, vamos a empujar nuevos cambios. Podemos hacerlo con el siguiente comando:

Creando una rama(branch).

Como sabemos, cada vez que desarrollamos cualquier software o proyecto, a menudo creamos nuevas features o corregimos un error(fix), por lo que utilizamos ramas para ello.
Las ramas son caminos que puede tomar cualquier desarrollador dentro del proyecto, que agrupan commits y que pueden volver a unirse al camino principal de la aplicación.
Es básicamente una manera de mantener la diferencia en el código original con respecto a la nueva features o fix.

Para comprobar la rama existente en el proyecto podemos escribir el siguiente comando:

Para crear una nueva rama podemos ejecutar el siguiente comando en el terminal:

Para comprobar o cambiar la rama actual puede utilizar el siguiente comando:

Es una buena práctica crear una nueva rama para cada issue creado.

Creando issues.

En la solapa "Issues” los diferentes colaboradores del proyecto pueden remarcar y alertar acerca de diferentes “bugs” o “problemas” dentro del proyecto.
Si queremos trabajar en alguna issue podemos comentar en ese mismo que estamos interesados en trabajar. El administrador del proyecto o los maintainers nos asignarán el issue, y entonces podremos empezar a trabajar en él.

En el caso del Open Source, suele haber una guia para contribuidores que explica el formato preferido de Issues, pull request y commits.

Crear un pull request.

Para que los colaboradores revisen los cambios que hemos hecho y los aprueben en el repositorio original, necesitamos crear una solicitud de revisión o pull request.

Actualizando el contenido del repo.

Al ser git un sistema donde múltiples personas colaboran, puede ser que necesitemos mantener nuestro repositorio local actualizado.
Para ello hay dos maneras en que podemos hacerlo:

Usando git pull.
Usando rebase.

En la opción 1, usamos el siguiente comando:

aquí upstream es la ubicación desde la que necesitamos actualizar el contenido y main es la rama de la que hay que hacer pull.

Para la opción 2, podemos utilizar el siguiente comando:

Rebase es preferible en comparación con pull, ya que pull es una combinación de git fetch y git merge que fusiona los cambios locales con las actualizaciones.

Compartí tu opinión o escribime!
Github
Twitter

“Como C@*+^ … con Git y no romper producción.”

Lara Díaz — Thu, 14 Jan 2021 15:12:17 +0000

Todos alguna vez pusheamos un commit que no era, rompimos todo y sentimos pánico. Por suerte, git nos permite reparar esos errores y volver el tiempo atrás a donde todo funcionaba perfectamente.
Hoy vamos a hablar de CHERRY-PICK un comando que permite elegir uno o más commits de una rama y aplicarla en otra.

¿Cómo usar git cherry-pick?

Lo único que necesitamos es saber el hash del commit específico que queremos aplicar a nuestra rama. ¿Cómo hacemos eso? en la terminal vamos a revisar

Vamos a buscar el hash (número del commit) que acabamos de hacer y lo vamos a anotar en un block. En ese mismo log, buscamos el hash del commit al que queremos traer a nuestra rama.También lo podemos buscar en github/gitlab/
Ahora en la terminal, vamos a escribir:
→ git reset --hard n° commit que necesitamos
→ git checkout tu-rama
→ git cherry-pick n° commit que hicimos --no-commit

¡Y ya podemos volver a trabajar! Aunque no se trata de una de las herramientas más usadas de git, puede resultar muy práctica y nos puede ahorrar mucho tiempo cuando trabajamos en varias ramas.

Github para Open Source

Lara Díaz — Thu, 15 Oct 2020 15:47:14 +0000

Git y Github cumplen un rol importante, no solo para el Software de Código Abierto (Open Source) sino también en la vida cotidiana de desarrolladores y compañías. Pero, entendemos la diferencia entre ambos y cómo funcionan?

Git es un “Distributed Version Control System” (DVSC) que permite observar y controlar los cambios en el código. Es muy usado en proyectos porque es multiplataforma, gratuito, eficiente y fácil de usar. Un sistema de control de versión permite monitorear, revisar y manejar las versiones de nuestro proyecto e incluso revertir errores que pueden ocurrir durante el desarrollo.

Pero, cómo empiezo??? Vamos a ver los comandos principales de un flujo de trabajo con Git:

Para crear un nuevo repositorio

Crear una copia local del repositorio que se está ejecutando

Clona un repositorio remoto

                       Flujo de trabajo

Directorio --> Contiene los archivos
Index --> Zona intermedia.
Main (antes conocido como Master) --> Apunta al último commit realizado.

                         Add y Commit

Para registrar todos los cambios (Index)

Para registrar un solo archivo

Para hacer commit de estos cambios, incluyendolos en el “Main”

                       Envío de cambios

Envía los cambios a tu repositorio remoto (Main o la rama a la que se desee mandar los cambios)

Para conectar tu repositorio local a un repo remoto.

                            Ramas

Son utilizadas para desarrollar funcionalidades aisladas de otras ramas.

Crea tu rama

Cambia a la rama principal

Borra la rama

Para subir la nueva rama y hacerla visible en el repo remoto

Actualiza el repo con los cambios

Fusiona otra rama con la rama activa (Main)

Muestra los cambios en el repo (nuevos, viejos y modificados)

Muestra todos los commits

                  ¿Y entonces qué es Github?

Es una plataforma creada en 2008 que nos permite manejar y almacenar los repositorios de git en la nube. Eso es todo, podes optar por mantener tus proyectos con git localmente, ya que github actúa como intermediario para mantener un backup de git externamente, además de hacer mucho más fácil el colaborar y compartir tus proyectos con otros desarrolladores.

                      ¿Qué es un fork?

Un fork es un mecanismo propio de GitHub que existe por que no todo el mundo puede editar sobre tu repositorio; un fork es un clon del repo en github y que funciona como un branch del original y es la forma principal por la cual alguien puede proponer cambios a un repositorio que no creo.

          ¿Y en qué se diferencia un fork de un clon?

Cuando hacemos un clon de un repositorio, te bajas una copia del mismo a tu máquina. Empiezas a trabajar, haces modificaciones y haces un push. Cuando haces el push estás modificando el repositorio que has clonado.

Cuando haces un fork de un repositorio, se crea un nuevo repositorio en tu cuenta, con una URL diferente (fork). Acto seguido tienes que hacer un clon de esa copia sobre la que empiezas a trabajar de forma que cuando haces push, estás modificando TU COPIA (fork). El repositorio original sigue intacto. El uso más común es el de permitir a los desarrolladores contribuir a un proyecto de forma segura.

                  ¿Qué es un pull request?

El pull request es un pedido de merge, y si bien puede usarse dentro de un mismo repositorio donde la persona que lo crea tiene poder para hacer merge, este es el mecanismo que se usa para mandarlos cambios de un fork al repo original.
El objetivo de los PR es la validación y/o documentación de los cambios, ya que permite pedir review de otras personas o, si es dentro del mismo repo y ni reviewers, se puede usar para documentar por que entran X cambios a master.

  --------------------------------------------------------

Por ahora, esto es lo básico, en la próxima entrada veremos Github CLI en su versión desktop y terminal. Espero les sirva =)