Tag: Git

Clonar la Wiki de un proyecto «forkeado» en GitHub

GitHub es una plataforma increíble que hace todo más fácil en la gestión de proyectos versionados con Git. Una de las grandes cosas que tiene GitHub es la de hacer un fork, que es una copia vinculada al repositorio original bajo tu completa administración.

Esta copia no es completa, puesto que no incluye algunas cosas relevantes como la Wiki, que es donde se documenta la información del proyecto. A efectos prácticos la Wiki se comporta exactamente igual que un repositorio gestionado con Git y que se compuesto por ficheros markdown. A mi juicio, el hacer un fork del proyecto debería incluir tanto el repositorio principal del proyecto como el repositorio Wiki del mismo. Quizás en un futuro no muy lejano lo veamos, quién sabe… 😉

Cuando hacemos un fork de un proyecto y vamos a la Wiki nos anima a crear nuestra primera página:

Aunque pudiera parece que al haber una sección Wiki, existe un repositorio, esto no es así. Hasta que no creemos la primera página que suele denominarse «Home», el repositorio de la Wiki no existirá. Si se intenta hacer push al repositorio, seguramente os arroje un error como este:

remote error: access denied or repository not exported

Esto es un error de falta de permisos que puede hacerte perder bastante el tiempo, si no caes en la cuenta que el error no es por falta de permisos, sino por la ausencia de repositorio.

Una vez aclarado el tema basta con darle a «Create the first page«:

Dejaremos tal cual está todo porque sobrescribiremos el contenido, sólo lo hacemos para que se cree el repositorio de la Wiki. Avanzamos hacia abajo y le damos a «Save Page«.

Ahora tenemos nuestra Wiki inicializada con su reapositorio activo:

Una vez llegados a este punto hay dos formas de hacer las cosas. En la primera de ellas, puede que la más fácil, sea hacer un clone del repositorio Wiki del original, hacer otro clone de nuestro repositorio Wiki en el fork, y copiar todos los archivos del repositorio Wiki original al de nuestro fork. De esta forma al hacer commit y luego push en nuestro repositorio, tendremos la Wiki. El mayor problema de este método es que primero vamos a tener un commit inicial y que luego vamos a tener un segundo con toda la Wiki. Esto nos hace perder el versionado que traía consigo el repositorio Wiki del proyecto original.

Otra forma más óptima que nos permite mantener el versionado del repositorio Wiki del proyecto original, es el que paso a describiros a continuación de manera detallada.

Primero hacemos un «git clone» del repositorio Wiki del proyecto original:

git clone url_wiki_original

Una vez clonado añadimos nuestra Wiki del fork como remoto con «git remote» (no usar como «remote_name» el nombre de origin):

git remote add remote_name url_wiki_fork

Ahora con el nuevo remoto añadido podemos hacer un «git push» forzado:

git push remote_name master --force

El parámetro «remote_name» es el mismo que cuando hemos añadido el remote en el paso anterior (el de la Wiki de nuestro fork), la rama es «master» (rama principal pero que puede ser cualquier otra que se quiera), y el parámetro «–force» que sirve para sobrescribir la referencia que tuviese anteriormente de la rama y sobrescribir por la que se manda (cuidado con este parámetro que puede resultar peligroso).

El resultado como podéis ver es la de nuestra Wiki actualizada con la del proyecto original:

Ahora queda un minúsculo detalle y es el «HEAD», la referencia que indica cual es remote y rama por defecto. Por defecto apunta a «origin/master«, que es el remoto de donde se hace el clone. Por esta razón hay que cambiar el «HEAD» para que apunte a nuestro fork como origin y a nuestra rama master. La manera más sencilla es coger y hacernos un «git clone» del repositorio Wiki de nuestro fork y todo listo. 😉

Con este procedimiento ya podéis incluir en vuestros forks la tan preciada y a veces escasa documentación  que se adjunta en los repositorios de los proyectos.

Crear y Eliminar un Submódulo Git de un Proyecto

Una de las formas más eficientes de gestionar la adhesión de subproyectos y librerías en Git, es mediante el uso de submódulos que nos permiten trabajar con ellos dentro de un proyecto, o de manera desacoplada con cada submódulo como si fuera un repositorio Git.

La creación de un submódulo dentro de un proyecto se limita a ejecutar el siguiente comando dentro del directorio deseado en el que se quiera añadir el submódulo, dentro de la raíz del proyecto:

git submodule add http://porject-url

Donde la URL después del comando «add» indica la localización del proyecto Git que queremos montar como submódulo.

Una vez tengamos el submódulo añadido podemos gestionarlo como si fuera un proyecto Git independiente, moviéndonos hasta la raíz del submódulo, o ejecutar comandos en lote sobre los submódulos de un proyecto.

Si deseas clonar el repositorio e incluir en el clonado los submódulos, deberás hacer un clone recursivo:

git clone --recursive http://porject-url

Donde deberás especificar la URL del proyecto.

Si no realizas el clonado recursivo, del proyecto deberás realizar una inicialización manual de los submódulos:

git submodule init
git submodule update

Por otro, lado, igual que es interesante crear un submódulo dentro del un proyecto, lo es también eliminar un submódulo de un proyecto. Por ejemplo porque queramos moverlo de sitio o porque queramos prescindir de él. Para ello os explicaré la forma de hacerlo borrando el repositorio, que puede servir para conseguir ambos objetivos.

Escontrándonos en la raíz del proyecto que contiene el submódulo que queremos borrar ejecutamos los siguientes comandos:

# Desinicializamos el submódulo de la lista de submódulos
git submodule deinit path/submodule
# Borramos físicamente el directorio del submódulo
git rm path/submodule
# Eliminar cache del árbol de trabajo de Git
git rm --cached path/submodule
# Eliminamos la meta información del submódulo que por alguna razón no borra Git
rm -rf .git/modules/path/submodule

Con las sucesión de comandos detallados, desvincularás totalmente el submódulo deseado y eliminarás los archivos innecesarios.

De esta forma queda cubierta la gestión de submódulos Git en su carácter más esencial, siendo una herramienta muy potente a la hora de gestionar las dependencias de un proyecto, y a la vez facilitando la actualización de las mismas.

Corregir colores ANSI en la consola de Windows 10 tras la actualización Windows Anniversary

La actualización de Windows Aniversario por fin llegó a mi equipo y aunque en general parece ser más robusto y seguro, era imposible no encontrarse con nuevos fallos introducidos a causa de esta enorme actualización. No obstante por la curva de fallos real del software, en cada actualización se introducen nuevos fallos no existentes anteriormente o mal solventados.

curva_fallos_software

Obviamente en esta actualización no iba a ser menos, dado el calado tan ambicioso de la actualización. El fallo que he detectado se corresponde a la interpretación de los colores ANSI de la consola de Windows. Concretamente el problema reside en que no se procesan los códigos ANSI de escape, que antes estaba activado por defecto gracias al flag de la consola ENABLE_VIRTUAL_TERMINAL_PROCESSING.

Esto supone un problema para todas las librerías y códigos de Python que usaban los colores ANSI para cambiar de color la letra y fondo de la consola de manera trasnaprente en todos los sistemas.

Ejemplo de la problemática que se empieza a notar en algunas librerías:

https://github.com/pyreadline/pyreadline/issues/46

Ante este problema se me ocurrieron 2 formas de arreglarlo.

 


Solución 1


cmder-main

La primera pasa por añadir un frontend a la maltrecha consola de comandos de Windows y pensé en Cmder por ser un proyecto que además es portable. De esta forma con un lanzador .BAT/.CMD es posible lanzar sobre Cmder lo que queramos y dejar a un lado la problemática de los colores.

La solución consiste en descargar Cmder en su versión portable y añadir el siguiente .BAT que nos permita lanzar Cmder y ejecutar comandos en su inicio:

@echo off
set CMDER_ROOT=%~dp0
start %CMDER_ROOT%\vendor\conemu-maximus5\ConEmu.exe /icon "%CMDER_ROOT%\cmder.exe" /title Cmder /loadcfgfile "%CMDER_ROOT%\config\ConEmu.xml" /cmd cmd /k "%CMDER_ROOT%\vendor\init.bat cd %CD% && cd .. && %~1"

Este archivo que puedes llamar «cmder.bat» debe estar al mismo nivel de directorio que el ejecutable «Cmder.exe«. En este caso además se asume que Cmder está en una carpeta en la raíz del proyecto y la consola se posiciona en el nivel inmediatamente superior al que se encuentra «cmder.bat» y «Cmder.exe«.

La forma de usar «cmder.bat» asumiendo que está en la carpeta «cmder» sería la siguiente:

start /B cmder.bat "python main.py" ^&^& timeout 5 ^&^& exit

En este caso se lanza un programa en Python, cuyo archivo de ejecución principal es «main.py«. Con el parámetro «/B» se lanza la aplicación sin crear una nueva ventana. Adicionalmente se le indica con «^&^& timeout 5» que la consola espere 5 segundos antes de procesar la salida de la consola gracias a «^&^& exit». El resultado sería algo similar a esto:

cmder-launch

 


Solución 2


La segunda solución pasa por añadir un parche en la librería de Python que usa colores ANSI o en su defecto en el «main» de la aplicación. Las líneas de Python que debes añadir para corregir el problema específico de la interpretación de los colores ANSI de la consola de Windows tras la actualización de Windows Aniversario, es la siguiente:

import os
import platform

if os.name == 'nt' and platform.release() == '10' and platform.version() >= '10.0.14393':
    # Fix ANSI color in Windows 10 version 10.0.14393 (Windows Anniversary Update)
    import ctypes
    kernel32 = ctypes.windll.kernel32
    kernel32.SetConsoleMode(kernel32.GetStdHandle(-11), 7)

Gracias a la librería ctype que proporciona tipos de datos compatibles con C, se pueden hacer llamadas a DLLs o librerías compartidas. Esencialmente lo que se hace es habilitar la flag ENABLE_VIRTUAL_TERMINAL_PROCESSING.

De esta forma los colores de la consola pasan de verse así:

ansi_win_before

A verse así:

ansi_win_after

¡Mucho mejor!, ¿no?

Dejo a continuación la referencia al Fix completo publicado en Gist de GitHub:

ANSIColorFix.py

 

Ambas soluciones resuelven la problemática del color ANSI en la consola de Windows tras la actualización Aniversario del sistema. No obstante la primera solución puede ser menos invasiva al no requerir de cambios en el código, pero la segunda es una solución de enfoque más nativo, ofreciendo una solución transparente a los desarrolladores que hacen uso de las librerías afectadas por este problema.

Diaspora* – Una Red Social de Todos y para Todos

Está claro que actualmente la información es poder y dinero, pero mientras el poder está limitado por leyes que marcan las reglas de nuestra sociedad, el dinero y la capacidad de enriquecerse en los modelos económicos capitalistas no está tan limitada, ni legislada.

Modelo actual de las Redes Sociales

Actualmente el modelo de explotación más rentable para el modelo hegemónico basado en la información, es la red social. Existen infinidad de ellas, mayoritariamente de carácter gratuito para la totalidad de su uso, como pueden ser Facebook, Twitter, Google+… Y son precisamente gratuitas, por la contraprestación que reciben ellos por el uso de esas redes sociales, son nuestra información, datos de actividad dentro de la red, preferencias… En este tipo de modelos que aparentemente son gratuitos, debéis recordar que no hay nada gratuito y que si lo es, el producto sois vosotros. En cualquier caso debéis ser consciente de lo qué dais a cambio del uso de este tipo de servicios.

Jail-facebook-twitter

Debéis recordar también que la protección de datos y la transferencia de datos e información en servicios web, como son las redes sociales, varía de acuerda a la legislación a la que se acoja la empresa desde donde opera. Por ejemplo Facebook se atiene a esta máxima y durante la apertura de una cuenta en su acuerdo de confiencialidad aclara que «el contenido que subas y compartas  son de Facebook». Obviamente puedes pedir la retirada de fotos o darte de baja de la red, pero Facebook sólo se limita a dejar de hacer público el contenido, guardánsose los datos, información y perfil obtenido durante el uso de la cuenta (que en muchos casos es suficiente para describir a una persona de manera unívoca).

Recientemente Facebook ejecutaba su giro maestro que le permitirá seguir creciendo, refinanciarse y por consiguiente tener más valor. Esto ha sido gracias a los nuevos términos de la política de privacidad de Whatsapp que permiten compartir tu número de teléfono y conexiones con Facebook. Está claro! Facebook no compró Whatsapp por ser la mejor aplicación que había, sino por sus usuarios, Ahora quiere engrosar sus filas en Facebook que es la empresa matriz que cotiza en bolsa.

Es evidente  que estos modelos de negocio convierten una necesidad de socializar de las personas, en una forma muy rentable de hacer dinero. Se basa en tenernos el mayor tiempo posible dentro de la red para generar más dinero, a costa de la información que desprendemos y así llenarnos de publicidad, colocarnos productos e invadir nuestra privacidad de manera no deseada, o por lo menos no explícitamente consentida. Pero, y si ¿habría otra forma?

social-media-rubik-cube

Diaspora* como Alternativa

Desde hace unos años se ha venido trabajando en lo que se denomina red social distribuida, un modelo que tiene bastante en común con las redes P2P que ofrecen una descentralización del servicio, otorgando poder al usuario y a la comunidad de desarrolladores. La red social más representativa de este paradigma es Diaspora*.

Los pilares de Diaspora* son seis:

  1. Descentralización: En lugar de tener la información de todo mundo contenida en enormes servidores centrales propiedad de un gran corporación, servidores locales(«pods«) pueden instalarse en cualquier parte del mundo. Tú eliges en qué «pod» registrarte – quizás en un pod local – y conectarte de manera fluida con la comunidad de Diaspora* alrededor del mundo.
  2. Libertad: Puedes ser quien tú quieras en Diaspora*. A diferencia de otras redes, no tienes que usar tu identidad real. Puedes interactuar con quien quieras de la manera que quieras. El único límite es tu imaginación. Diaspora* también es Software Libre, dándote la libertad de usarlo como desees.
  3. Privacidad: En Diaspora* tú eres dueño de tu información. No tienes que renunciar ningún derecho a una corporación o interesés que pudieran utilizarla. ¡Con diaspora*, tus amigos, tus hábitos y lo que compartes es tuyo… no nuestro! Además, tu eliges quién puede ver lo que compartes, por medio de Aspectos.
  4. Aspectos: Diaspora* es pionera en el concepto de aspectos, lo que quiere decir que puedes organizar tus contactos de acuerdo al papel que juegan en tu vida. Esto significa que tú eliges compartir algo sólo con familiares o colegas de trabajo, sabiendo que nadie que no quieras podrá ver lo que publicas.
  5. Características heredadas: Los Hashtags te dan la libertad de etiquetar y seguir tus intereses con facilidad. Puedes llamar la atención de la gente @mencionándola. Volver a compartir las publicaciones que te gustan para que otros puedan disfrutar y comentarlas también. Y mostrar tu aprecio por el trabajo de otras personas con un ♥.
  6. Colaborativo y Open Source: Diaspora* necesita personas que escriban y prueben el código, den la bienvenida y ayuden a los nuevos miembros, instalen y mantengan pods comunitarias, y corran la voz sobre los beneficios de Diaspora* a otros que quieran formar parte. ¿Te gustaría contribuir al proyecto?

Para más información accede a la Fundación de Diaspora*:

https://diasporafoundation.org/about

Adentrarse en Diaspora*

Sabiendo las características y si estás decidido a ser parte de Diaspora*, lo primero que tienes que hacer es elegir tu pod.  Para ello puedes hacerlo de la siguiente lista de pods federados en la red:

https://podupti.me

Como recomendación personal y si no tienes predilección sobre ninguno en especial, te recomiendo:

https://joindiaspora.com

Si quieres sopesar tu elección de acuerdo a datos sobre los distintos pods, puedes obtenerlos en:

https://the-federation.info

Si necesitas más información sobre la elección de tu pod puedes acceder a:

https://wiki.diasporafoundation.org/Choosing_a_pod

En cualquier caso el pod (vaina) donde abraramos nuestra cuenta (semilla), no impide que podamos acceder al contenido generado en otros pods, ni que en un futuro puedas migrar a otro pod si así lo deseas. Con esta metáfora de la diáspora (dispersión), la vaina (núcleos comunitarios) y la semilla (semillas), el proyecto de Diaspora* deja definido metafóricamente su ADN.

Impresiones

Tras unos días de uso de la red social lo primero que llama la atención es que Diaspora* aglutina lo mejor de Facebook y Twitter, pero con el gran detalle de que NO hay publicidad de ningún tipo, ni explícita ni escondida en contenido seleccionado mostrado para tu perfil.

Diaspora_latest

Claramente se apuesta por un empoderamiento de los usuarios y desarrolladores.  Por un lado, en el caso de los usuarios porque pueden elegir cómo y de qué manera quieren mostrar su información , evitando a su vez que la información del perfil del usuario sea substraido por terceras empresas que hagan explotación de los mismos. Por otro lado, los desarrolladores pueden elegir el camino junto a los usuario de manera colaborativa usando plataformas como Loomio, y a su vez cualquier desarrollador puede acceder al código para ejercer todas las libertades del software libre en Github.

Cabe destacar la capacidad de adaptación de la interfaz de Diaspora* a los distintos dispositivos. Particularmente en el caso de la versión móvil,  no hay necesidad de la instalación de una aplicación nativa, aunque también existen aplicaciones nativas para el móvil para quienes lo deseen. En cualquier caso, es la primera red social en la que veo totalmente innecesario el uso de la aplicación nativa. ¡Buen trabajo!

Por último destacar la sección principal de la red social, cuyo contenido va guiado por las etiquetas de nuestro interés que hayamos incluido. Mención especial de la etiqueta #NSFW (Not Safe For Work), que oculta el contenido publicado, hasta que el usuario decida mostrarlo. Una forma de respetar sensibilidades de los potenciales lectores del contenido.