Author

Muchos que crecieron en la década del 80, o que siendo no tan pequeños tuvieron su primer ordenador durante esos años se acordarán e incluso extrañarán a la querida y famosa Commodore 64. Era una simple computadora de 64 bits con la que prácticamente podías hacer de todo. Sus juegos sencillos y simples (en cuanto a gráficos) eran muy entretenidos y uno podía pasar horas y horas jugando con ellos. Dibujos en dos dimensiones, sin mucha animación, sin mucha definición, e incluso a veces requería que el jugador tuviese un poco de imaginación para lograr comprender qué era lo que representaba hacían las delicias de todo gamer.
Si eres de aquellos, esta app que emula un C64 será una de las mejores que podías tener en tu Smartphone se trata de Manomio y Frodo C64. Estas dos apps, son de las mejores que hay en la app store. Su uso es realmente sencillo y realmente parece que se está utilizando una C64 en un Smartphone. Es decir, utilizamos un ordenador de 64 bits de la década de los 80 en un dispositivo que ni por asomo se podía imaginar una persona de aquellos años. 🙂
A pesar que la tecnología avance y se consigan juegos con muchísimo realismo para aquellos que conocieron los clásicos de la C64 como Commando, Summer Games, Winter Games, Blagger, Wizard of War, Miners, Manic Miners, Underwurldle (no recuerdo bien cómo se escribía), Bruce Lee… no hay juego que se compare con la diversión que estos brindaban. De hecho, más de uno sacrificaría un poco de realismo gráfico para tener algo que entretenga más.

Firefox, el popular navegador de la Fundación Mozilla, lleva en su versión actualizada una importante novedad. Ahora, cuando abrimos una ventana de navegación privada, el navegador lleva habilitado de forma predeterminada un seguimiento sistema de protección que bloquea los elementos que recoge información acerca de nuestra navegación. Lo malo de esto es que probablemente no veas contenido importante que tiene la web. Esto se debe a que está plagado de falsos positivos. Es decir, enciende la alarma sin motivo.
La navegación privada  nos permite para navegar por Internet con la tranquilidad de que nuestro dispositivo no guarda el historial de páginas visitadas o búsquedas, cookies, contraseñas almacenadas o archivos temporales. Si ahora se agrega la nueva característica protección de seguimiento, se evita que las páginas recopilen datos como los patrones de navegación.
Esta característica supuestamente hace que nuestra sesión de navegación sea más segura y privada que antes. Como dijimos antes, no siempre es buena idea ya que hay aplicaciones totalmente buenas que son consideradas como invasivas por Firefox y directamente no muestra nada. Como este es un error que se repite a menudo te recomendamos que desactives la protección de seguimiento. Lo que no te dicen es que ralentiza la navegación. En realidad, solo entorpece nuestras visitas a la web.
Para desactivar esta molesta función puedes hacer clic en el icon que está junto a la barra de direcciones.
Ingresa a:

 Herramientas -> Opciones -> Privacidad -> Desmarca las casillas que corresponden a rastreo: Indicar a los sitios que no le rastreen y Usar protección contra rastreo en ventanas privadas.
Ahora podrás disfrutar de la navegación web sin que Firefox decida qué puedes ver y qué no. Esa decisión la debes tomar tú.
Lo cierto es que esta supuesta mejora en la seguridad no sirve de mucho. No creas que hace que tu navegación sea privada. Siempre tanto las webs como tu proveedor de servicio de internet saben a qué sitios ingresas y la demás información que dejas. Si quieres algo totalmente privado debes contratar una vpn más otras cosas más. Y eso cuesta dinero.

Git es un sistema de gestión de versiones, como SVN o CVS, con algunas características que lo diferencian

Es distribuido. Mientras SVN o CVS, están orientados a tener un repositorio central sobre el que todos modifican, Git esta orientado a que cada cliente tiene su propio repositorio y sincroniza con uno central, o con alguno intermedio o con otro usuario. Esto da mucha flexibilidad a tu flujo de trabajo.
SVN o CVS son sistemas mas maduros que Git, con lo que existen mas clientes para todos los sistemas, y es mas fácil encontrar información concreta sobre estos. Sin embargo gracias al uso de Git para el desarrollo del kernel de Linux, ahora esta empezando a tener cierto auge.

Lo primero es o primero, y en este caso es instalar todas las herramientas necesarias para trabajar con Git, en mi caso trabajo exclusivamente desde la terminal, así que solo tengo que descargar los paquetes principales de la página de Git, dependiendo del sistema operativo en el que trabajemos.

Iniciando el repositorio:

La estructura general de un árbol de repositorios de Git, suele estar compuesta por un numero indeterminado de clientes que gestionan cada uno su propio repositorio, y que en algún momento ponen en común su trabajo con otro repositorio superior y común de Git. Para empezar a trabajar con ese repositorio superior y común, si ya existiera, deberíamos ejecutar algo como:

git clone protocolo://rutadelservidor/rutadelrepositorio

Pongo “protocolo://” por que git puede trabajar tanto con FTP, como con FTTP, como con RSYNC, o con el que yo trabajo normalmente SSH. Una vez ejecutado este comando, tendremos una copia del repositorio superior, o común en nuestro sistema, en la carpeta donde lo hayamos ejecutado, es decir, en nuestro repositorio privado. Se generaran todos los archivos necesarios, tanto los propios del servidor Git, como los archivos del proyecto en el que estemos trabajando.

Modificando el proyecto:

Una vez tenemos los archivos a nuestra disposición, podemos añadir nuevos archivos al proyecto, podemos eliminarlos del proyecto, o bien, cambiar los existentes. Para añadir nuevos ficheros al repositorio debemos ejecutar:

git add nombredelfichero-o-directorio

Para eliminar los archivos, es algo similar:

git rm nombredelfichero-o-directorio

Una vez hemos añadido, eliminado, o modificado un fichero ya existente en el proyecto, podemos ejecutar el comando:

git status

Este comando nos mostrará cuales son los archivos que se han modificado, añadido o eliminado en la carpeta del proyecto, pero que están pendientes de ser grabados en el repositorio privado. Es decir, para guardar en el repositorio privado los cambios, debemos ejecutar algo como:

git commit -a -m “mensaje descriptivo de esta versión que se esta subiendo”

Una vez ejecutado este comando, nuestro repositorio privado debe tener la ultima versión que existe en nuestro sistema de los archivos. Pero siempre hablando de nuestro repositorio privado. Si ahora ejecutáramos un “git status” deberíamos comprobar que no queda nada por actualizar o añadir.

Sincronizando con el repositorio público:

Una vez que tenemos una versión que queremos compartir con el resto de los usuarios del sistema debemos sincronizar con el repositorio público. Ya que es un repositorio público, pueden darse errores, como por ejemplo que dos personas hayan modificado la misma linea del mismo archivo, y Git no sepa con exactitud cual es la correcta. Para evitar esto, el flujo de sincronización es invertido con respecto a lo que seria lo “natural”. Es decir, seria algo como:

Obtengo versión pública -> Soluciono errores de mezclado -> Actualizo versión pública

Para obtener la versión pública, debemos ejecutar algo como:

git pull [alias del repositorio] [nombre de la rama]

Pues eso, podemos configurar para obtener de varios repositorios diferentes, aunque no es lo común. Ademas de obtener de varios repositorios, podemos obtener de varias ramas, dentro de cada repositorio. El tema de las ramas no lo voy a tratar hoy, así que simplemente pensaremos que existe una sola rama que se llama “master”. La rama “master” se crea por defecto en Git. Tanto, la rama por defecto, como el repositorio por defecto pueden configurarse en el archivo de configuración del repositorio de git, de forma que podríamos trabajar simplemente con un “git pull” a secas si lo tenemos todo bien configurado.

Una vez obtenida la información del repositorio público, Git nos alertará en el caso de existir discordancias entre las versiones, y no nos dejara publicar hacia el servidor público hasta que las resolvamos. Una vez resueltas las discordancias, debemos hacer un commit, tal y como explicamos antes, y para terminar y subirlo al servidor público, debemos ejecutar un:

git push [alias del repositorio][nombre de la rama]

Si todo ha ido bien, el servidor público de Git debe tener nuestra versión del proyecto como la ultima versión.

Resumiendo:

El flujo natural de trabajo que yo sigo es el siguiente:

Al iniciar a trabajar: git pull para obtener la ultima versión de todas.
Editas, añades(git add) o eliminas(git rm) los archivos que sean.
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Sincronizas con tu servidor privado con un: git commit -a -m “mensaje”
En el caso de querer actualizar el servidor público:
Obtenemos la ultima version de nuevo: git pull
Resolvemos las incoherencias entre las versiones
Comprobación de que se ha cambiado con un git status, si falta algo por cambiar, volvemos al paso anterior.
Hacemos un commit a nuestro repositorio local
Sincronizamos hacia el servidor público con: git push.

No soy ningún experto en Git, y he obviado muchas cosas, como las ramas (branchs) o mas información sobre la configuración de los repositorios remotos (origenes). Puedes consultar muchísima mas información, y mucho mas correcta y precisa en las páginas de información de Git. Y si observas que cualquier cosa es incorrecta o puede ser explicada de mejor forma, no te cortes y compártelo en los comentarios.