Author Image RDCH106

Qwant – Recuperando la búsqueda orgánica

posted by under Aplicaciones ,

¿Nunca has tenido la sensación de que Google te muestra lo que quieres ver en vez de lo que has buscado? ¿Cuántas veces has buscado algo o hablado de algo y ves que hasta los anuncios parece que te han oído? ¿Te has fijado lo que pasa cuando ves en un red social, por ejemplo vídeos de "gatitos", cómo de repente te empiezan a recomendar tantos vídeos de gatitos que no podrías terminar de verlos ni en una vida... Incluso cuando quieres prestar tu atención en otra cosa, tu atención es robada por vídeos de gatitos... Sí, los algoritmos de búsqueda y de recomendación tienen vida propia y compiten por tu atención.

¿Te has planteado alguna vez cuando buscas en Google, si realmente te está buscando el mejor resultado de acuerdo a tu búsqueda? ¿O es una búsqueda sesgada por intereses comerciales (mayormente publicitarios), mezclada con contenido que capte tu atención y te retenga? Si usas el buscador de Google, te adelanto que estás en el segundo caso y lo que debería ser una búsqueda de acuerdo a posicionamiento natural u orgánico, resulta que no lo es, siendo algo coyuntural y anecdótico lo que realmente buscas. Esto quiere decir que los resultados mostrados no son los que tú estás buscando, sino los que Google por diversos ajustes en sus algoritmos está seleccionado para ti.

Esto crea lo que se conoce como un efecto burbuja de información y de contenido, los algoritmos de búsqueda y recomendación van a reforzar el tipo de búsquedas que mejor encajen con tu perfil, porque sí, lo que Google busca es hacer perfiles, conocerte mejor, para ofrecer el mejor servicio de publicidad del mundo y eso implica entender qué llama tu atención. Alguno puede pensar que se salva porque navega de manera privada en Chrome, y nada más lejos de la realidad. Chrome es la punta de lanza con la que Google ha copado el mercado de los navegadores y que usa para que su negocio de publicidad esté mejor controlado y sea más prospero.

Tampoco te libras si usas Firefox y usas el buscador de Google. Ni aún navegando en privado, ya que siempre hay elementos que pueden identificarte (aunque Firefox trabaja incansablemente para protegerte de ese rastreo), como la IP desde la que te conectas que puede acotar una zona geográfica, las maravillosas cookies (esas que acabas aceptando porque no puedes decir que no), las cosas que buscas (dónde entras..., qué miras...) ...

⚠️ Recuerda que todo esto no es por la privacidad, que también debería importarte, sino que esto va de la visión sesgada que recibes cuando un buscador como el de Google da los resultados que da cuando haces una búsqueda, los cuales son sesgados y acomodados a tu perfil.

Foto Buscador de Google 2013 obtenida de Principiantes Socialmedia

Todo esto se mezcla con el SEO (Search Engine Optimization) y el SEM (Search Engine Marketing), que en sí constituyen un negocio, en el que al final el que más relevancia tiene suele ser el que más paga… Alguno pensará que es normal, y lo era... Ya que antiguamente Google tenía en el resultado que veías sin hacer scroll, una parte de resultados orgánicos y otra de promocionados. Actualmente voces del sector dicen que toda la primera página, y hasta la décima página de resultados, son resultado convenientemente colocados por Google, ya sea para publicitarte algo o para retener tu atención de una forma u otra. Sobre este tema, puedes encontrar un buen documental en Neflix llamado "El dilema de las redes sociales" .

Qwant una alternativa a Google con sello Europeo 🇪🇺

Qwant es un buscador que se autodefine como "el primer motor de búsqueda europeo, eficiente y ético". Su motor de búsqueda respeta tu privacidad, y esto lo hace ofreciendo una garantía de neutralidad e imparcialidad en la que ofrece los mejores resultados disponibles para tus consultas y nunca intenta adivinar quién eres o qué estás haciendo. Esto hace que toda la web sea visible "sin ninguna discriminación y sin prejuicios". Afirman que sus algoritmos de clasificación "se aplican por igual en todas partes y para todos los usuarios, sin intentar presentar sitios web o esconder otros basados en intereses comerciales, políticos o morales".

Instalación en Firefox 💾

La instalación en Firefox es muy cómoda. Entra en Qwant dale a "Add Qwan to Firefox" y sigue los pasos.

Puedes elegir que Qwant sea tu motor de búsqueda por defecto o no, pudiendo cambiar los ajustes en "Opciones > Buscar". 💡 Como consejo adicional decirte que puedes asignar atajos para indicar si usas un buscador u otro en tus búsquedas en la barra del navegador (por ejemplo "q mascandobits" o "@google mascandobits").

💡 También puedes seleccionar el motor de búsqueda desde la barra de búsqueda antes de darle a enter, seleccionado el buscador que quieres usar.

Más ℹ️ información en la ayuda de Firefox.

Móvil 📱

Para Firefox móvil la cosa no es tan cómoda, pero puedes añadir Qwant como motor de búsqueda y si quieres puedes hacerlo buscador predeterminado en "Ajustes > Buscar". Si quieres añadir Qwant como motor de búsqueda, dale a "Añadir buscador > Otro" y rellenas:

  • Nombre: Qwant
  • Cadena de búsqueda a usar: https://www.qwant.com/?l=es&q=%s

Con eso ya puedes usar Qwant desde tu Firefox móvil. Lamentablemente tiene que hacerse así porque la extensión de Qwant no funciona en la versión móvil, como tantas otras que requieren de una actualización para ser usadas en versiones modernas de Firefox.

Instalación en Chrome 💾

La instalación en Chrome también es muy cómoda, aunque nos metemos en la guarida del lobo (a Google no le gusta que el motor de búsqueda en Chrome sea otro al suyo) y tienes sus peros. Entra en Qwant dale a "Add Qwan to Chrome" y sigue los pasos.

Por motivos internos que se desconocen y que no han trascendido, con la extensión de Qwant obligatoriamente tienes que usarlo como motor predeterminado y desactivar la extensión para elegir otro. Seguramente tenga mucho que ver con estos mensajes que te saltan en el navegador, en un amago de rescatar la posición de privilegio del motor de Google en su navegador Chrome:

Entiendo que no es una opción del todo cómoda, pero si quieres tener la posibilidad de elegir motor de búsqueda predeterminado puedes introducirlo manualmente. Google se reserva el hecho de sacarlo en cualquier momento de la lista de motores de búsqueda predeterminados, razón por la que ya ha sido varias veces sancionado por la Unión Europea por abuso de posición dominante. Para ello ve a "Configuración > Buscador > Administrador buscadores". Si quieres añadir Qwant como motor de búsqueda dale a "Añadir" en las sección "Otros buscadores" y rellenas:

Un vez creado aparecerá en la lista que hay debajo de "Otros buscadores", dale a los tres puntos para establecerlo como predeterminado.

⚠️ Si lo quitas como predeterminado desaparecerá de la lista de los navegadores seleccionables y tendrás que volver a hacer este paso de añadirlo como predeterminado.

Ahora veis la razón del comportamiento de la extensión de Qwant. 😎 En cualquier caso, aunque lo quitéis como predeterminado lo podréis seguir usando para buscar si usáis la palabra clave al principio de vuestra búsqueda en la barra de búsqueda de Chrome (por ejemplo "@qwant mascandobits").

Móvil 📱

Para Chrome móvil, siendo Android bastión de Chrome, la cosa está complicada y mucho... Es imposible añadir un nuevo buscador en "Configuración > Buscador", sólo permite elegir entre los que te ofrece y vuelve a reservarse el derecho Google de poner su buscador como buscador predeterminado.

Aún así existe una pequeña opción de usar Qwant como motor de búsqueda predeterminado. Es iniciando sesión con una cuenta de Google en Chrome, en un equipo de sobremesa y habilitar la sincronización, pudiendo así sincronizar extensiones. ¡Muy buena Google!, así puedes controlar la extensión, no se te escapa una 😉😅. Reza el dicho que: "mantengas cerca a tus amigos, pero aún más cerca a tus enemigos".

Tristemente la mejor opción de usar Qwant en Chrome desde un móvil, es estableciendo Qwant como página principal. 😢

Impresiones

Qwant ♥️ Firefox 👌

Llevo ya unos cuantos meses usándolo y estoy encantado con Qwant, lo tengo como motor principal de búsqueda. No lo he sustituido completamente por Google, porque a veces resulta interesante el efecto burbuja de los resultados de sus búsquedas, sobre todo en ámbitos profesionales. No obstante cuando quiero abrir mi mundo, mi herramienta es Qwant sin duda.

Además no debemos olvidar que cotejar varias fuentes es algo básico en nuestra sociedad de la "desinformación". Y un buscador por mucho que nuestras leyes digan que es, o debería ser, un agente neutro, no lo es. Coteja varios resultados de distintos buscadores siempre y no uses sólo uno.

Historia del impresionante resurgir de AMD y de cómo Intel no lo vio venir – Acto1

posted by under Miscellaneous

Para contar esta historia tenemos que empezar desde el principio, y no me refiero al principio cuando AMD en 2006, tras comprobar ATI Technologies, estuvo a punto de sobrepasar a Intel en la famosa guerra de procesadores. Empieza en 2017 con un rediseño de la arquitectura de los procesadores de AMD (bautizada como Zen) y una mejora de los procesos de fabricación que haría que la carrera de prestaciones parase momentáneamente para AMD, para pasar a ser una carrera de precio.

Cuota de mercado de procesadores AMD vs Intel

En pleno 2020 todo se basa en la nube. Eso quiere decir que todas las compañías, desde grandes compañías como Google, Amazon o Facebook hasta compañías más pequeñas necesitan procesar una gran cantidad de datos; y llevan mucho tiempo pidiendo procesadores con más potencia, y sobre todo, que aumente el número de núcleos.

Imaginaros que tienes que montar un centro de datos con 1024 núcleos. Si lo único que tienes son procesadores de cuatro núcleos, vas a necesitar muchísimos procesadores y junto a ellos muchísimas placas base. Aunque desarrolles placas base capaces de soportar dos procesadores, o incluso cuatro, o hasta ocho; vas a necesitar muchísimas placas base y esto es un problema.

Primero por los costes, además de pagar 256 procesadores vas a tener que comprar cientos de placas base, después interconectar todos estos procesadores sin placas base es complicado. Especialmente te van a dar muchos dolores de cabeza las latencias. Al tener tantos procesadores la comunicación entre muchos de ellos va a ser muy lenta y eso va a hacer que tu centro de datos pierda mucha eficiencia y no obtengas el rendimiento que esperarías obtener. Por último el consumo porque cada placa base tiene su chipset además de otros componentes... cada uno de los procesadores también tiene mucho más hardware además de los núcleos. Cada uno tiene su controlador de memoria, su controlador PCI Express... hay muchísimo hardware duplicado que consumirá energía y en un gran centro de datos con miles de procesadores supone muchísimo dinero. Todo sería mucho más sencillo si en vez de necesitar 256 procesadores de cuatro núcleos, pudiéramos montar tan sólo 15 procesadores de 64 núcleos.

Tendríamos mucho mejor rendimiento, tendríamos mayor facilidad para interconectar todos los procesadores, el consumo sería mucho menor, el centro de datos ocuparía muchísimo menos espacio, se generaría menos calor (así que ahorraríamos también el aire acondicionado)... serían todo ventajas.

Por ello se inició la llamada "Guerra de los núcleos" donde AMD e Intel compiten por crear los procesadores más potentes y con mayor número de núcleos posibles.

💡 Para poner en contexto lo que vas a seguir leyendo AMD es un empresa mucho más pequeña que Intel, siendo alrededor de una décima parte AMD frente a lo que es Intel a nivel de empresa en aspectos como número de empleados, facturación, valoración de empresa... según datos obtenidos de Forbes.

El fallo de Intel

Intel se desmarcó en 2008 de AMD gracias a sus procesadores que incluían una arquitectura RingBus con la micro-arquitectura Nehalem, para luego en 2016 hacer una apuesta por una arquitectura Mesh con la micro-arquitectura Skylake.

RingBus vs Mesh

Mientras que RingBush funciona bien para un número no demasiado alto de núcleos, el diseño hacía aguas en la latencia (tiempo en forma de retraso) entre núcleos para su comunicación. Según se aumentaba el número de anillos, o núcleos en los anillos, el incremento de la latencia es lineal. De manera general la latencia máxima en una arquitectura de este tipo es el número de núcleos entre 2.

En el caso de una arquitectura Mesh, además de existir múltiples caminos para ir de un núcleo a otros núcleos, existen más interconexiones que en el modelo RingBush que nos permite evitar congestiones (cuellos de botella) al existir caminos alternativos. El incrementos de núcleos no supone un incremento lineal de la latencia, presentando de manera general una latencia máxima en la arquitectura que es la suma de los lados de la malla menos uno.

Comparativa de latencias entre RingBus y Mesh

Intel encontró la forma de crear procesadores con un gran número de núcleos y un rendimiento óptimo. Sin embargo probablemente debido a que empezaron a desarrollar este tipo de tecnología ( basada en una micro-arquitectura Mesh) desde hace al menos hace una década, Intel cometió un error fatal.

Hasta ahora hemos hablado solo de arquitecturas, sin embargo estos procesadores hay que fabricarlos. ¿Cómo se fabrican? - en obleas.

Una oblea es un círculo de silicio donde unas máquinas literalmente dibujan los procesadores en un proceso llamado fotolitografía. Por cada oblea se pueden crear decenas o incluso cientos de chips, dependiendo del tamaño de los chips. Bien, ¿qué pasa si metemos más núcleos al procesador? Éste se va a hacer más grande y ocupa más espacio, por lo tanto si el procesador es más grande puedes introducir menos procesadores por oblea.

Pero además hay otro problema y es que los transistores que forman los condensadores modernos son muy pequeños y son muy difíciles de imprimir haciendo que sea normal que ciertas zonas de la oblea salgan defectuosas.

Pongamos un ejemplo extremo, imaginemos una oblea con decenas de procesadores pequeñitos y que parte de la oblea sale mal. No hay problema, perderás algunos procesadores pero se sigue consiguiendo decenas de ellos correctos. Sin embargo si estamos produciendo procesadores muy grandes, ese mismo defecto podría cargarse tranquilamente la mitad de los procesadores de la oblea. Por lo tanto cuanto más grande sea el procesador, menos puedes producir. Así que si metes más núcleos, haces tu procesador más grande y por lo tanto puedes producir menos. En vez de producir miles por ahora, sólo puedes producir unos poquitos. Además el coste de fabricación es mucho más alto, haciendo el procesador más caro. Y no sólo eso, la dificultad para imprimir chips tan grandes, también hará que tengas que gastar mucho dinero y tiempo en poner a punto las máquinas que los fabrican, aumentando aún más el precio del procesador.

Entonces aunque Intel tenga una arquitectura que en teoría permite crear procesadores con un número de núcleos muy alto, tenemos un problema. Fabricar esos procesadores es muy complicado... pero bueno, no hay que preocuparse. Por esto porque existe la ley de Moore que dice que cada dos años se duplica el número de transistores en un microprocesador. Desde los años 70 el avance en el mundo la tecnología se ha regido por esta ley, así que no hay de qué preocuparse. Si este año puedo fabricar un procesador de 8 núcleos en 2 años en el mismo espacio, gracias a la mejora en procesos de fabricación, me entran 16, y en otros 2 años me entran 32, y en otros 2 años 64, y luego 128, y luego 256...

Registro de la Ley de Moore

Fabricar los chips no es un problema porque cada año los procesos de fabricación mejoran y los transistores que forman el procesador se pueden imprimir más pequeñitos... y este es el error que cometió Intel.

La mal llamada ley de Moore, que es más bien una observación que una ley, no tiene en cuenta que el silicio tiene un límite donde no podemos hacer los transistores más pequeños porque los electrones se salen de los circuitos y estamos muy cerca de ese límite. Por lo tanto el avance en procesos de fabricación se ha ralentizado.

Pronóstico de la Ley de Moore

El número de transistores en un procesador ya no se duplica cada dos años, de hecho la propia Intel lleva cuatro años atascada en el mismo proceso de fabricación de los 14 nanómetros y van a seguir atascados en él al menos un año más hablando de chips de alto rendimiento. ¿Qué quiere decir esto? Que durante al menos cinco años no han podido aumentar el número de transistores que caben en el mismo espacio y se espera que el avance se ralentice todavía más en los próximos años. Así que eso de que en dos años te van a caber el doble de núcleos en el mismo espacio era cierto hace unos años, pero a día de hoy no lo es, pero bueno... tampoco entremos en pánico porque con procesadores de cuatro núcleos para la gama doméstica y de hasta 10 para las gamas de rendimiento y servidores, salvo alguna excepción de algún procesador que te dé más núcleos, pero fabricamos muy poquitos no hay problema. Son pequeños se venden bien, no hay competencia y el dinero no hace más que entrar, todo controlado 😏. Seguimos así y ya cuando podamos, pues ya meteremos más núcleos, no tenemos ninguna prisa, no hay nada de lo que preocuparse... o sí... 🤔 La tormenta perfecta que hará temblar los cimientos de Intel comienza a formarse.

El primer golpe de efecto de AMD

En el 2017 AMD resurge de sus cenizas con su nueva arquitectura Zen y planta procesadores de ocho núcleos en la gama doméstica y hasta 32 núcleos en la gama de alto rendimiento y servidores. Intel evidentemente para seguir en el liderato de potencia se ve obligada a responder. Pasa de procesadores de 4 a 8 núcleos en la gama doméstica y el número de núcleos en sus procesadores de alto rendimiento y servidores aumenta hasta 28. Sin embargo durante esta transición el proceso de fabricación se mantiene. Los procesadores siguen fabricándose a 14 nanómetros, esto quiere decir que están fabricando procesadores el doble de grandes, lo cual supone que su producción se reduce a la mitad. Si antes fabricaban 1000 procesadores, pasan a fabricar la mitad, 500. Esto por sí solo ya es un duro golpe para Intel, pero ese golpe llega en el peor momento posible.

Intel se encuentra en medio de la transición de su proceso de fabricación de 14 nanómetros al nuevo proceso de fabricación a 10 nanómetros. Eso quiere decir que algunas de sus líneas de producción a 14 nanómetros se cierran para adaptarlas al nuevo proceso de fabricación como en transiciones anteriores. Se esperaba una transición rápida y sin problemas, al final cabo las fábricas de Intel han sido líderes en eso durante décadas. Son los mejores en esto, pero no esta vez Intel falla. Los 10 nanómetros no funcionan y la producción del nuevo proceso de fabricación no puede comenzar. Se retrasa primero un año, luego dos, luego tres... el proceso de fabricación que estaba inicialmente previsto para 2016 pasa a no estar previsto hasta 2020 2021.

Intel colapsa con su producción diezmada por tener que producir chips más grandes para competir con AMD, y encima con sus fábricas sin poder trabajar a su máxima capacidad. No son capaces de producir chips suficientes, sus procesadores en cuestión de semanas duplican su precio,

Precio PCComponentes de Intel i5 8400

Procesadores que antes estaban en ciento y pico euros, pasan a costar 300 euros. Parte de su gama de procesadores, como los de bajo consumo para tablet, pasan directamente a no estar disponibles porque Intel no tiene capacidad para fabricarlos. Intel intenta buscar ayuda exterior de otras fábricas como las de Samsung o TSMC para que fabrique estos procesadores, pero la situación no mejora. Intel no puede producir suficientes procesadores y el mercado comienza a fijarse en unos mucho más interesantes Ryzen de AMD en los cuales no tienen problemas de producción; por lo que es mucho más sencillo de comprar, más rápido y encima son mucho más baratos.

Intel se encuentran estos momentos en una muy mala situación pero cuando parecía que ya habían tocado fondo... no, todavía quedan unos cuantos pisos más por bajar.

Gestión de dependencias y versionado en Python

posted by under Programación

Cuando programas una de las cosas más importantes para asegurar la compatibilidad y el soporte de una librería, herramienta o programa, es el versionado del mismo.

El versionado sirve para que a nivel interno, el equipo de desarrolladores pueda llevar un control de hitos dentro del desarrollo y a su vez sirve para que otros desarrolladores o usuarios, que usan estas librerías, herramientas o programas, puedan tener un control a la hora de integrarlas o actualizarlas.

Ahora bien, el problema viene a la hora de establecer la significación de dicho número de versión. En Python es normal usar el sistema SemVer, el cual establece tres grupos de números separados por puntos de la forma MAJOR.MINOR.PATCH

  • MAJOR: Se incrementa cuando cuando se realizan cambios incompatibles a nivel de API.
  • MINOR: Se incrementa cuando se añaden funcionalidad de manera retrocompatible.
  • PATCH: Se incrementa cuando se corrigen 🐛 fallos de manera retrocompotible

Es posible que estuvieras familiarizado con este sistema de versionado, pero aún así te recomiendo su lectura completa en https://semver.org.

Teniendo esto claro, vamos a pasar a ver la aplicación práctica que que tiene esto en la gestión de dependencias, donde la generación de paquetes para su distribución en Pipy es donde se marca la diferencia. Podemos ajustar que nuestro paquete maneje las dependencias de acuerdo a criterios de versión de Python, debido a casos como que una librería específica deje de dar soporte a ciertas versiones de Python a partir de cierta versión.

En el caso citado, hay dos opciones directas que son, o retirar soporte a ciertas versiones de Python propagando la restricción de alguna de nuestras dependencias, o controlar las versiones de las dependencias dependiendo de la versión de Python a utilizar. Veamos cómo:

colorama==0.3.7; python_version < '3.4.*'
colorama>=0.3.7; python_version >= '3.4.*'

En este caso definimos en nuestro requirements.txt la condición de que para versiones de Python menores a 3.4.* es necesario usar la versión de colorama 0.3.7, ya que dicha dependencia retira el soporte a versiones inferiores desde esa versión. Para versiones iguales o mayores a 3.4.*, simplemente se exige una versión mayor o igual a 0.3.7. Atención a que siempre se citan los tres grupos de números.

Otras veces puede pasar que cierta versión de una dependencia nos dé problemas y queramos convertirla en una excepción al requerimiento

fake_library>1.6.2,!=1.7.2

En este caso de la librería inventada fake_library exigiría una versión superior a 1.6.2, pero que no sea 1.7.2.

Por último es posible instalar dependencias que sean necesarias para ciertos sistemas operativos. Veamos un ejemplo:

pywin32 >=1.0.*; sys_platform == 'win32'
SistemaValor platform
AIX'aix'
GNU/Linux'linux'
Windows'win32'
Windows/Cygwin'cygwin'
macOS'darwin'

https://docs.python.org/3/library/sys.html#sys.platform

Para el ejemplo se especifica una versión superior o igual a 1.0.* de pywin32 en el caso de encontrarnos en un sistema Windows.

Finalmente es posible que en el setup.py de una librería, herramienta o aplicación, se obligue a contar con unas versión especificas de Python y/o evitar otras:

from setuptools import setup
 
setup(
    name='mypackage',
    packages=['mypackage'],
    version='0.1',
    license='LGPL v3',
    description='A random test lib',
    author='RDCH106',
    author_email='contact@rdch106.hol.es',
    url='https://github.com/RDCH106/mypackage',
    download_url='https://github.com/RDCH106/parallel_foreach_submodule/archive/v0.1.tar.gz',
    keywords='test example develop', 
    python_requires='>=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*', # requerimientos de versión de Python
    classifiers = ['Programming Language :: Python',
                   'Programming Language :: Python :: 2.7',
                   'Programming Language :: Python :: 3.4',
                   'Programming Language :: Python :: 3.5',
                   'Programming Language :: Python :: 3.6',
                   'Programming Language :: Python :: 3.7',
                   'Programming Language :: Python :: 3.8'],
)

En la línea 14 se puede ver que se especifica que se requiere versiones de Python mayores a 2.7, pero que no sean ni 3.0.*, 3.1.*, 3.2.* o 3.3.*.

Todas estas reglas condicionales para la gestión de dependencias quedan reflejadas en las PEP (Python Enhancement Proposal) 345, 440, 496 y 508 principalmente.

Espero que todo esto sirva para evitar caer en el llamado “infierno de las dependencias”, mientras crece tu librería, herramienta o aplicación.

Cómo revisar y probar un Pull Request (PR) en GitHub, GitLab o Gogs

posted by under Programación , ,

Hay gente que a día de hoy sigue sin entender la diferencia entre Git (herramienta de versionado) y GitHub (plataforma para alojar proyectos Git, ahora propiedad de Microsoft). Y mucho menos entiende el valor que aportan plataformas web como son GitHub, GitLab o Gogs, que añaden todo el valor social y de discusión sobre los cambios propuestos por otros desarrolladores o usuarios, permitiendo así el Desarrollo Colaborativo y auge que hoy en día presenta la filosofía de software Open Source.

Siendo así, vamos a aclarar que Git es una estupenda herramienta de versionado y sincronización de código, o cualquier fichero que no sea binario, permitiendo establecer la sucesión cronológica y relacionar los cambios entre sí para una control y revisión del avance de un proyecto.

Pero por otro lado Git solo, es bastante "cojo" por así decirlo. Las personas no nos relacionamos y trabajamos mediante protocolos o herramientas que llevamos instaladas y que nos permitan trabajar en equipo de manera eficaz 🤣. Es aquí donde entran las plataformas web que dan esa capa social que permiten a los desarrolladores y contribuidores al proyecto comunicarse, establecer criterios, marcar pautas, organizarse, revisar secciones de código... En este artículo nos vamos a centrar en el proceso de revisión de aportes de código Pull Request, abreviados y conocidos como PR.

Esquema básico del proceso de revisión:

Antes de empezar vamos a aclarar una serie de términos que creo que es conveniente definir. Lo primero explicar lo que es un Fork, que no es más que un clon de un proyecto cuya propiedad (en términos de administración) es de otro usuario u otra organización, pero permanece relacionado con su proyecto originario del que se hizo fork (normalmente se denomina al proyecto origen upstream). Y luego lo que es un Pull Request (de ahora en adelante PR), que es una petición que se hace al proyecto originario (upstream) para que incluya los cambios que tenemos en una de las ramas de nuestro repositorio "forkeado".

Entre el PR y la aceptación del mismo está lo que se conoce como discusión y revisión de los cambios propuestos. Los procesos de revisión son importantes porque permiten afinar los cambios, corregir metodologías de trabajo, realizar pruebas de integración con plataformas como AppVeyor o TravisCI... Podríamos decir que es el punto en el que se comunican las personas involucradas en la propuesta de PR.

Entrando en el terrenos práctico la discusión se genera en la sección de PR y es donde se produce toda la conversación. Aquí podéis ver un ejemplo:

- https://github.com/RDCH106/pycoinmon/pull/5

Creo bastante evidente como se debate, ya que es como un foro en el que dependiendo de la plataforma (GitHub, GitLab o Gogs...) será más completo o menos.

La pregunta del millón es cómo probamos el código que está en el PR. No se encuentra en una rama del repositorio el PR, realmente se encuentra en la rama del que nos hace el PR (a donde podemos ir para probar los cambios). De hecho lo interesante es que el PR puede ir cambiando, si el autor del PR en su fork, en la rama que usó para el PR, realiza cambios. Es decir, un PR no es un elemento estático sujeto a un commit concreto, sino que es la referencia a una rama del proyecto fork que contiene cambios que el upstream no tiene. El truco reside en que comparten la misma base de código y los cambios del PR son la diferencia entre la rama del proyecto upstream al que se le propone el PR y la rama del proyecto fork que contiene los cambios.

Pero esto es una verdad a medias... y digo a medias porque un PR sí es una rama, realmente es una referencia en el repositorio remoto (donde hacemos pull y push). Y eso es bueno 😁. La referencia entre un fork y su upstream nunca se rompe de manera oficial (existen por ejemplo mecanismos en GitHub para solicitar que un fork de un proyecto deje de estar relacionado con su upstream), por lo que asumiremos que un fork es como un padre y un hijo, pueden no llevarse bien pero eso nunca hará que desaparezca la relación parental padre-hijo. Cada vez que la rama del fork desde la que se hace PR se actualiza, la del proyecto upstream también queda actualizada. Por eso resulta conveniente usar ramas para hacer PR de diferentes features (características) que vamos a desarrollar, ya que así podremos mantener de manera independiente ambos paquetes de trabajo sin que haya interferencias entre ellos, y pudiendo dejar la rama el tiempo que haga falta hasta que finalmente se incluyan los cambios al proyecto upstream.

A causa de lo comentado antes podemos revisar desde la consola las referencias remotas con las que cuenta un proyecto git con el comando "git ls-remote". Voy a usar el proyecto pyCOINMON como ejemplo totalmente práctico:

rdch106@RDCH106 MINGW64 /d/GIT/pycoinmon (develop)
$ git ls-remote
From https://github.com/RDCH106/pycoinmon.git
be75cbb0e449383fd42c9033a8b76c844fcfef17        HEAD
d01ecf133c342f490030b56066ed8ff18b36f124        refs/heads/develop
be75cbb0e449383fd42c9033a8b76c844fcfef17        refs/heads/master
ec9c10b6d88274a1a006ae139856de478876572c        refs/pull/1/head
c0cb91e1776632494a23cf181584c1903516a758        refs/pull/11/head
46f2e6db3d22a4a48dcf3680157c95641123095d        refs/pull/2/head
035e64652c533a569c6b236f54e12aff35ad82b1        refs/pull/3/head
0f08bd644912e7de4a3bc53e3a8d0dbd64d6fc34        refs/pull/4/head
87ef8ca9af3eb5a523d3ef532fccee91aeedcd44        refs/pull/5/head
896d697e846649c7f23b9af3430067451ab5c089        refs/pull/7/head
d57455a8acf719cd3acea623f0759c6e11baada1        refs/pull/7/merge
d6f4c5a4b3e2b0025d74e9feed2609ba50835950        refs/tags/v0.1.0
be413f410cfa23e1f0f2715f2714874a22757b0d        refs/tags/v0.1.0^{}
cdc5e356b6d7f829e83a1b0a25e2a7304844223b        refs/tags/v0.1.4
4b69c059196f1f41bafc4f5970afb8a34817b509        refs/tags/v0.1.4^{}
b5649af39db2738481751f07b6ad59585144dbd0        refs/tags/v0.2.4
c3506ed1289f3dbcddb2db68201a114a9d1cf8b3        refs/tags/v0.2.4^{}
f0c564d2617d42c0fcb3cb842122a214a6021d37        refs/tags/v0.2.6
a3fe8f8b788311c1d4f5ee906cf2a4c70ffac8db        refs/tags/v0.2.6^{}
cea535e4e663531454b437ee8d7976a06e1ae415        refs/tags/v0.2.8
080192d1d7eb33feed6b92df2b389b39592545a6        refs/tags/v0.2.8^{}
9c374d2031a9da655be44e0c79944166cbf99e8a        refs/tags/v0.3.2
f76f78252863d372fde5d6ff197ba7519f7da50b        refs/tags/v0.3.2^{}
cc248bbd64f177a9b6041cad7c269b880c21b355        refs/tags/v0.3.5
fd50d344575e54def4b841221b2b5c2e8a0a74e3        refs/tags/v0.3.5^{}
7727986a93ce65c2deb905fcd92718c43f3e61ca        refs/tags/v0.4.0
aa2df260dc9c1ae9c1aa88ddd7d2498b451bf0fc        refs/tags/v0.4.0^{}
a620d5e379d495c69926d97a33803e91b3c07783        refs/tags/v0.4.4
d0b3fa9ae73a15ff17a47804fbbac80245c028c1        refs/tags/v0.4.4^{}
f12102dfacc530f90600082a97a0533ba862bd2c        refs/tags/v0.4.7
4329b9f5a9782071fe661376225df6d8d6dfa47e        refs/tags/v0.4.7^{}
1d3dbf367ab319f0d9a515c007ff07b90de6ca1c        refs/tags/v0.4.8
d01ecf133c342f490030b56066ed8ff18b36f124        refs/tags/v0.4.8^{}

Nos vamos a centrar por ejemplo en el PR #7 que es uno de los que tenemos abiertos y cuyos cambios supongamos que queremos probar:

Lo que vamos a hacer es traernos los cambios del PR basándonos en su ID (en nuestro caso #7), creando una nueva rama (PR_7) para poder probarlo por separado:

rdch106@RDCH106 MINGW64 /d/GIT/pycoinmon (develop)
$ git fetch origin pull/7/head:PR_7
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Total 10 (delta 7), reused 7 (delta 7), pack-reused 3
Unpacking objects: 100% (10/10), done.
From https://github.com/RDCH106/pycoinmon
 * [new ref]         refs/pull/7/head -> PR_7

Ahora sólo resta hacer un checkout a PR_7:

rdch106@RDCH106 MINGW64 /d/GIT/pycoinmon (develop)
$ git checkout PR_7
Switched to branch 'PR_7'

O hacerlo desde el maravilloso SourceTree el cual os recomiendo como herramienta profesional para la gestión de vuestros repositorios Git locales y remotos (si eres usuario GNU/Linux no me olvido de ti, te recomiendo GitKraken).

A partir de aquí ya es hacer lo que quieras. Puedes probar los cambios, hacer algunas pruebas, hacer un "merge" para incluir los cambios en otra rama o incluso en la propia rama master.

En lo que a mí respecta, recomiendo simplemente probar los cambios y en la zona de discusión que comentaba antes, realizar todas las apreciaciones necesarias y dejar las cosas lo más claras posible, siendo responsabilidad del desarrollador que hizo el PR realizar los cambios para evitar conflictos. Una vez esté todo correcto, también recomiendo realizar el merge desde GitHub, GitLab o Gogs...

Además todo este proceso forma parte del aprendizaje y democratización de los conocimientos, haciendo de cada PR un sitio al que se puede volver para aprender y revisar lo ocurrido gracias a la trazabilidad en la discusión de los cambios.

Personalmente los procesos de revisión es una base estupenda junto al Planning Poker (prueba https://scrumpoker.online), para igualar las habilidades y competencias que permiten acortar divergencias entre las estimaciones de un grupo de desarrollo ante la planificación de las cargas de trabajo. Yo personalmente soy partidario de que el que lanzó la estimación más alta en la partida de poker realice el paquete de trabajo para que baje su estimación y aumenten sus habilidades, gracias a la supervisión (revisión) de quien dio la cifra más baja, que se asume que dio una estimación más ajustada por unas habilidades mayores.